From megver83 at hyperbola.info Fri Nov 1 18:15:22 2019 From: megver83 at hyperbola.info (Megver83) Date: Fri, 01 Nov 2019 15:15:22 -0300 Subject: [Dev] [armv7h] DO NOT update to mkinitcpio v27 yet Message-ID: New mkinitcpio v27 introduces some changes that may lead to unwanted issues in armv7h. In x86_64 and i686 it doesn't, but newer kernel versions may require you to reinstall mkinitcpio. Im working in a patch for making it work in armv7h, but it may take some time. I'll possibly make an announcement in the news about this, with more detail. Sorry for not explaning this problem too deeply, but I'm working hard to get the solution as soon as possible. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From andreas at grapentin.org Tue Nov 5 22:28:36 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Tue, 5 Nov 2019 23:28:36 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting Message-ID: <20191105222836.GA86715@parabola-pocket.localdomain> Hi, As you know, a good chunk of the infrastructure that makes parabola is currently hosted on a virtual machine called winston, which is generously provided by the hosting provider 1984. We used to have proton as well, but when that died, the things that it hosted were migrated over to winston. It's come to our attention that this machine is currently struggling to cope with the load it has to bear, as is evident by the fact that it is as of this writing at ~70% swap utilization, and requires more and more frequent reboots just to keep our basic infrastructure operational. As you can probably imagine, this is not a healthy mode of operation for a distribution, and is something that is eating a bunch of hacker time to keep on top of. These developments have prompted freemor, bill-auger and me to keep an eye open for other hosting options that would maybe give our services and bit more breathing room, and maybe some space to grow and expand. bill-auger had floated the idea to get in touch with the people over at vikings (vikings.net) -- in CC -- who offer (among other things) hosting services on exclusively libre-friendly server hardware, which would be perfect for parabola. We did already have a brief chat with their team to figure out what their available hosting options are, and now we need to discuss amongs ourselves what sort of infrastructure we want going forwards. I think it would make sense to start by listing all the services that the new infrastructure should host, and estimating from there what sort of physical or virtual machine or machines we need, and how we distribute the services. Off the top of my head, these are the services that I know we run: - webserver for parabola.nu, including - wiki - main website - git repositories - issue tracker (redmine?) - forum - Tier 0 package repositories - repo importer - mailman But I'm probably missing a bunch of things. This is where I'd like someone more experienced with our infrastructure to step in and explain what we have and need. I would suggest we start maintaining this information in the wiki as well, assuming no such article exists already. This might come in handy down the line. My hunch as a Software Engineer and Architect would be that it could make sense to partition these services in two, or maybe three VMs, just to have a more fine-grained control over fault tolerance and recovery in case something does go belly-up, and to be able to separate the critical from the non-critical infrastructure. But this is something we need to discuss down the line, if we have a clear idea about our service landscape. While we do this, I would also suggest we take another look at which part of our infrastructure could and / or should be converted to packages, instead of unaccounted for files. We could conceivably add a separate undocumented repo for server-only packages. And while we're at that, I would also like to take a gander at automatic provisioners, such as ansible, that would allow us to describe our server roles and then automatically deploy them as needed, to have a self-documenting deployment of our services. But first, let's complete the list of services that parabola needs to function, and figure out how we want to partition these and what sort of resources they need. Everything beyond that is still far away. :) I have to say; I am personally very excited to see these changes unfold. I believe that parabola is currently at a place where we need to stabilize our infrastructure and establish ourselves as a serious distribution. And a collaboration with vikings could be a great chance to take a leap toward that direction. However, I also appreciate that parabola is an adhocracy, and that each of you has their own unique views on these issues and options. If you have any concerns about these developments, please bring them to our attention as well. I'm looking forwards to everyones input. Best, Andreas oaken-source -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From bill-auger at peers.community Wed Nov 6 12:09:03 2019 From: bill-auger at peers.community (bill-auger) Date: Wed, 6 Nov 2019 07:09:03 -0500 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191105222836.GA86715@parabola-pocket.localdomain> References: <20191105222836.GA86715@parabola-pocket.localdomain> Message-ID: <20191106070903.3e3412df@parabola> On Tue, 5 Nov 2019 23:28:36 +0100 Andreas wrote: > I would suggest we start maintaining > this information in the wiki as well there are dedicated wiki pages for the servers, with each server having its own sub-article - they have not been updated though, since everything from proton was moved to winston https://wiki.parabola.nu/Hacking:Servers i have added a revised list of services to the wiki for the purpose of this discussion, so that it can be further revised https://wiki.parabola.nu/Hacking:Servers/In-Progress-2019-11 on that list, i sorted the services primarily as essential/non-essential to suggest that all essential services remain on winston, with backup instances on another box ready for emergency use - all those labeled as "essential" have been on on winston all along, while the web and non-essentials were split between proton and winston - the web and non-essential services are the ones we should consider partitioning across other boxes - the web services especially are the ones most likely to go crazy with resource usage, and the most likely to be hassled by bots lukeshu explained to me that the separation between proton and winston was such that all clients of mysql were on one box and all clients of pg were on the other - when we migrated everything to winston, lukeshu was leery that mixing these could cause performance problems i do hope that lukeshu chimes in on this discussion - more than anyone, he has been the main architect of the parabola infrastructure, and is still the one who is most familiar with it's subtleties and quirks On Tue, 5 Nov 2019 23:28:36 +0100 Andreas wrote: > which part of our infrastructure could and / or should be > converted to packages, instead of unaccounted for files. AFAIK there is very little running on winston that is not published publicly already - most of the web services are not packages because they were forked from arch or the upstream as git repos; and our patches are in that form - i think mailman and cgit are the only web services that are managed by pacman - most internal services are pacman packages, and most of the custom tools are packaged from code in the git repos On Tue, 5 Nov 2019 23:28:36 +0100 Andreas wrote: > like to take a gander at automatic provisioners, such as > ansible, a while back lukeshu put some things under the holo configuration management system - that probably the part of the system that i know the least about; but it presumably does a similar job as ansible - also, etckeeper is managing arbitrary configuration files; and the git repo manages it's own metadata via git hooks in a similar way as etckeeper does From theova at bluewin.ch Wed Nov 6 16:03:37 2019 From: theova at bluewin.ch (theova) Date: Wed, 6 Nov 2019 17:03:37 +0100 Subject: [Dev] [Nonprism/gnome-online-accounts] Upgrade to 3.34.1 Message-ID: <20191106160337.ukdcesldjtx5vgez@RainbowWarrior.localdomain> Hello, The following PKGBUILD will upgrade [nonprism/gnome-online-accounts] to version 3.34.1. Changelog: - bumb pkgver and _commit Tested on 64 bit, built on 64, 32 and arm. -------------- next part -------------- # $Id$ # Contributor (Arch): Ionut Biru # Contributor: Andreas Grapentin # Contributor: M?rcio Silva # Contributor: Isaac David # Contributor: Theova # parabola changes and rationale: # - removed support for possibly unsafe protocols pkgname=gnome-online-accounts pkgver=3.34.1 pkgrel=1 pkgrel+=.nonprism1 pkgdesc="Single sign-on framework for GNOME" pkgdesc+=", without support for unsafe and dangerous for privacy protocols" url="https://wiki.gnome.org/Projects/GnomeOnlineAccounts" arch=(x86_64) arch+=(i686 armv7h) license=(LGPL) depends=(webkit2gtk json-glib libnotify rest libsecret krb5 gcr) makedepends=(gobject-introspection gtk-doc vala git meson) optdepends=('gvfs-goa: Virtual file systems, e.g. OwnCloud') _commit=a57487846b75dccd7a272f8682d647766ce222cd # tags/3.34.1^0 source=("git+https://gitlab.gnome.org/GNOME/gnome-online-accounts.git#commit=$_commit") sha256sums=('SKIP') pkgver() { cd $pkgname git describe --tags | sed 's/-/+/g' } prepare() { cd $pkgname } build() { arch-meson $pkgname build \ -D lastfm=false \ -D media_server=true \ -D gtk_doc=true \ -D man=true \ -D inspector=true \ -D exchange=false \ -D facebook=false \ -D flickr=false \ -D google=false \ -D pocket=false \ -D windows_live=false \ -D foursquare=false ninja -C build } check() { meson test -C build --print-errorlogs } package() { DESTDIR="$pkgdir" meson install -C build } # vim:set ts=2 sw=2 et: From theova at bluewin.ch Wed Nov 6 16:03:56 2019 From: theova at bluewin.ch (theova) Date: Wed, 6 Nov 2019 17:03:56 +0100 Subject: [Dev] [nonprism/gnome-settings-daemon] Upgrade to v3.34.1 Message-ID: <20191106160356.j7mcrh4u3o5uwnxa@RainbowWarrior.localdomain> Hello, The following PKGBUILD will upgrade [nonprism/gnome-online-accounts] to version 3.34.1. Changelog: - bumb pkgver and _commit - Add gcr as dependency (as upstream does) - Add libmm-glib as dependency (implicit dependency in geocode in upstream). Tested on 64 bit, built on 32 bit and arm. -------------- next part -------------- # Maintainer (Arch): Jan Alexander Steffens (heftig) # Contributor (Hyperbola): Andr? Silva # Contributor: Andreas Grapentin # Contributor: Isaac David # Contributor: Omar Vega Ramos # parabola changes and rationale: # - removed geoclue2 support pkgname=gnome-settings-daemon pkgver=3.34.1 pkgrel=1 pkgrel+=.nonprism1 pkgdesc="GNOME Settings Daemon, without geoclue2 support" url="https://gitlab.gnome.org/GNOME/gnome-settings-daemon" arch=(x86_64) arch+=(i686 armv7h) license=(GPL) depends=(dconf gnome-desktop gsettings-desktop-schemas libcanberra-pulse libnotify systemd-libs libwacom pulseaudio pulseaudio-alsa upower librsvg libgweather geocode-glib nss libgudev gtk3-print-backends libnm) makedepends=(xf86-input-wacom libxslt docbook-xsl python git meson) checkdepends=(python-gobject python-dbusmock) groups=(gnome) _commit=57114085a09e86968e0a0261392c6866352f35fd # tags/GNOME_SETTINGS_DAEMON_3_32_1^0 source=("git+https://gitlab.gnome.org/GNOME/gnome-settings-daemon.git#commit=$_commit" "git+https://gitlab.gnome.org/GNOME/libgnome-volume-control.git" nonprism.patch) sha256sums=('SKIP' 'SKIP' '6619205eb1e4d87caeb8e1673d6c80acf4d30f15ae91c5f6cb728a2e5674bf65') pkgver() { cd $pkgname git describe --tags | sed 's/^GNOME_SETTINGS_DAEMON_//;s/_/./g;s/-/+/g' } prepare() { cd $pkgname git submodule init git config --local submodule.subprojects/gvc.url "$srcdir/libgnome-volume-control" git submodule update patch -p1 -i $srcdir/nonprism.patch } build() { arch-meson $pkgname build ninja -C build } check() { meson test -C build } package() { DESTDIR="$pkgdir" meson install -C build } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bill-auger at peers.community Wed Nov 6 16:03:10 2019 From: bill-auger at peers.community (bill-auger) Date: Wed, 6 Nov 2019 11:03:10 -0500 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191106070903.3e3412df@parabola> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191106070903.3e3412df@parabola> Message-ID: <20191106110304.1e77e381@parabola> On Wed, 6 Nov 2019 07:09:03 -0500 bill-auger wrote: > the git repo manages it's > own metadata via git hooks scratch - thats probably a cron task From bill-auger at peers.community Thu Nov 7 13:30:36 2019 From: bill-auger at peers.community (bill-auger) Date: Thu, 7 Nov 2019 08:30:36 -0500 Subject: [Dev] outdated repos Message-ID: <20191107083036.63bdaef4@parabola> re: https://labs.parabola.nu/issues/2540 while going over the repos in pacman.conf and the wiki, i noticed several repos that are not in the pacman.conf's - these have not seen any attention in years - are any of these useful anymore? - should we delete them? REPO LAST UPDATED ---------------------------- alarm 2018-10-08 cross 2012-01-23 gnome-unstable 2014-10-03 java 2017-02-14 kde-unstable 2014-10-03 From eschwartz at archlinux.org Thu Nov 7 14:55:01 2019 From: eschwartz at archlinux.org (Eli Schwartz) Date: Thu, 7 Nov 2019 09:55:01 -0500 Subject: [Dev] outdated repos In-Reply-To: <20191107083036.63bdaef4@parabola> References: <20191107083036.63bdaef4@parabola> Message-ID: <7c7968b0-8bad-014f-0aec-1dc8a33c409e@archlinux.org> On 11/7/19 8:30 AM, bill-auger wrote: > re: https://labs.parabola.nu/issues/2540 > > while going over the repos in pacman.conf and the wiki, i noticed > several repos that are not in the pacman.conf's - these have not > seen any attention in years - are any of these useful anymore? - > should we delete them? > > REPO LAST UPDATED > ---------------------------- > alarm 2018-10-08 > cross 2012-01-23 > gnome-unstable 2014-10-03 > java 2017-02-14 > kde-unstable 2014-10-03 kde-unstable and gnome-unstable are synced directly from archlinux. The date of e.g. the directory https://repo.parabola.nu/kde-unstable/ may be from 2014, but the date of https://repo.parabola.nu/kde-unstable/os/x86_64/kde-unstable.db.tar.gz is a couple days ago... it currently contains qt 5.14 betas as well as some kde components which are rebuilt against it. See: https://wiki.archlinux.org/index.php/Official_repositories#kde-unstable -- Eli Schwartz Bug Wrangler and Trusted User -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1601 bytes Desc: OpenPGP digital signature URL: From isacdaavid at isacdaavid.info Sun Nov 10 22:49:51 2019 From: isacdaavid at isacdaavid.info (Isaac David) Date: Sun, 10 Nov 2019 16:49:51 -0600 Subject: [Dev] outdated repos In-Reply-To: <20191107083036.63bdaef4@parabola> References: <20191107083036.63bdaef4@parabola> Message-ID: <6332f17246787ebd58998e8d5c4cd13f44c9a5a9.camel@isacdaavid.info> On Thu, 2019-11-07 at 08:30 -0500, bill-auger wrote: > re: https://labs.parabola.nu/issues/2540 > > while going over the repos in pacman.conf and the wiki, i noticed > several repos that are not in the pacman.conf's - these have not > seen any attention in years - are any of these useful anymore? - > should we delete them? > > REPO LAST UPDATED > ---------------------------- > alarm 2018-10-08 > cross 2012-01-23 > gnome-unstable 2014-10-03 > java 2017-02-14 > kde-unstable 2014-10-03 cross and java are (were?) documented on the wiki, as in this old version: https://wiki.parabola.nu/index.php?title=Repositories&oldid=17655 back then, ovruni was well-acquainted with the java repo and its purpose. as for cross, my hunch is that no one is using it nowadays, and removing it might be a good idea. i think i may have created alarm during the addition of ARM support. this is were Archlinux ARM places some important packages of their own[1], and {core,extra,community} packages we import from them could depend on them. i have forgotten and departed enough to be unable to tell whether this matters anymore. cheerful hacking [1]: https://github.com/archlinuxarm/PKGBUILDs -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E8 16F0C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From grizzlyuser at protonmail.com Mon Nov 11 08:53:22 2019 From: grizzlyuser at protonmail.com (grizzlyuser) Date: Mon, 11 Nov 2019 08:53:22 +0000 Subject: [Dev] Packages with PDF files embedding non-free fonts In-Reply-To: <0AF4Iq5mVg3A7Gh86NdUF2gIZTQdi6BS0jbsHI2GtQQrCOq263KLfgIHDjJkAfuloL7rDcE7LpQKKWA2UP-Rfo3jBBG1nEoFoS1RthSuv4U=@protonmail.com> References: <0AF4Iq5mVg3A7Gh86NdUF2gIZTQdi6BS0jbsHI2GtQQrCOq263KLfgIHDjJkAfuloL7rDcE7LpQKKWA2UP-Rfo3jBBG1nEoFoS1RthSuv4U=@protonmail.com> Message-ID: Does anybody have any thoughts on that? I wonder what are the best next steps to do with this issue, if it's an issue indeed. From andreas at grapentin.org Mon Nov 11 09:31:34 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Mon, 11 Nov 2019 10:31:34 +0100 Subject: [Dev] Packages with PDF files embedding non-free fonts In-Reply-To: References: <0AF4Iq5mVg3A7Gh86NdUF2gIZTQdi6BS0jbsHI2GtQQrCOq263KLfgIHDjJkAfuloL7rDcE7LpQKKWA2UP-Rfo3jBBG1nEoFoS1RthSuv4U=@protonmail.com> Message-ID: <20191111093134.GA49042@parabola-pocket.localdomain> Hi, I've created a ticket on our issue tracker where we can discuss this further, and to keep track of it: https://labs.parabola.nu/issues/2544 Best, Andreas (oaken-source) On Mon, Nov 11, 2019 at 08:53:22AM +0000, grizzlyuser wrote: > Does anybody have any thoughts on that? I wonder what are the best next steps to do with this issue, if it's an issue indeed. > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From lovell.joshyyy at gmail.com Mon Nov 11 15:56:13 2019 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Mon, 11 Nov 2019 15:56:13 +0000 Subject: [Dev] Fwd: Re: Packages with PDF files embedding non-free fonts In-Reply-To: References: Message-ID: Forwarded, as hit reply instead of reply all, Apologies. -------- Forwarded Message -------- Subject: Re: [Dev] Packages with PDF files embedding non-free fonts Date: Mon, 11 Nov 2019 15:54:06 +0000 From: Josh Branning To: apologies For those who don't already know, wine provides some libre replacement fonts ... I'm guessing they would be very similar ... https://source.winehq.org/git/wine.git/tree/HEAD:/fonts Josh On 11/11/19 09:31, Andreas Grapentin wrote: > > Hi, > > I've created a ticket on our issue tracker where we can discuss this > further, and to keep track of it: > https://labs.parabola.nu/issues/2544 > > Best, > Andreas (oaken-source) > > > On Mon, Nov 11, 2019 at 08:53:22AM +0000, grizzlyuser wrote: >> Does anybody have any thoughts on that? I wonder what are the best next steps to do with this issue, if it's an issue indeed. >> _______________________________________________ >> Dev mailing list >> Dev at lists.parabola.nu >> https://lists.parabola.nu/mailman/listinfo/dev > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From beebe at math.utah.edu Mon Nov 11 16:43:27 2019 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 11 Nov 2019 09:43:27 -0700 Subject: [Dev] Packages with PDF files embedding non-free fonts In-Reply-To: Message-ID: List member grizzlyuser writes about the question of PDF files in Parabola distributions that contain nonfree fonts: >> Does anybody have any thoughts on that? I wonder what are the best >> next steps to do with this issue, if it's an issue indeed. Font licenses vary by vendor. My recollection is that Adobe permits licensed fonts to be freely used in PDF files posted to the Web, as long as the fonts are subsetted, so that it is not possible to recover a complete working font from decoding of the PDF file. I also recall licenses from Bitstream and Mergenthaler/Linotype that did not permit posting of PDFs. However, my reading of those licenses was several years ago, and licenses may have since changed, especially in view of the wide, and likely uncontrollable, font license violation on the Web of PDF files that use system fonts. What this boils down to probably is that we have to examine each PDF file, extract a list of its fonts (e.g., Adobe Acrobat Reader can display that list with the menu path File -> Document Properties -> Fonts --- there ought to be a command-line tool to do that, but I don't recall finding one), and then from the long font names, like "Arial-BoldItalicMT", attempt to figure out the vendor, and track down the applicable license. Noted font designer Chuck Bigelow wrote in 1986 about font licensing issues: Notes on typeface protection TUGboat 7(3) 146--151 October 1986 https://tug.org/TUGboat/tb07-3/tb16bigelow.pdf Incidentally, Chuck is hosting the TeX User Group 2020 conference next summer at the University of Rochester in NY State. The date has not yet been set, but TUG's annual meetings are traditionally in late July or early August when they are held in the northern hemisphere. Documents that are typeset with TeX (pdftex, pdflatex, luatex, xetex, ...) using fonts from the TeX Live distributions do not have license problems, but those programs permit users to employ system fonts as well, and those in turn may have restricted licenses. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From bill-auger at peers.community Mon Nov 11 23:06:41 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 11 Nov 2019 18:06:41 -0500 Subject: [Dev] arch replaced the 'base' package group with a leaner 'base' meta-package In-Reply-To: <20191030210529.349b77ba@primarylaptop.localdomain> References: <20191028113916.53184849@parabola> <20191030210529.349b77ba@primarylaptop.localdomain> Message-ID: <20191111180537.73f5d57f@parabola> re: adding a 'base-extras' meta-package - i made a list of the diffs package in the base group, not in the new base meta-package: > cryptsetup > device-mapper > dhcpcd > e2fsprogs > inetutils > jfsutils > logrotate > lvm2 > man-db > mdadm > nano > netctl > pacman-mirrorlist > perl > reiserfsprogs > s-nail > sysfsutils > texinfo > usbutils > vi > xfsprogs > your-system-sanity packages in the new base meta-package, not in the base group: < coreutils < file < filesystem < grep < gzip < licenses < sed < systemd-libudev < systemd-sysvcompat < systemd-udev < tar < xz From bill-auger at peers.community Tue Nov 12 02:32:07 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 11 Nov 2019 21:32:07 -0500 Subject: [Dev] arch replaced the 'base' package group with a leaner 'base' meta-package In-Reply-To: <20191111180537.73f5d57f@parabola> References: <20191028113916.53184849@parabola> <20191030210529.349b77ba@primarylaptop.localdomain> <20191111180537.73f5d57f@parabola> Message-ID: <20191111213207.3050be8b@parabola> re: why are we discussing adding a base-extra metapackage / group? Isn't that something upstream should be doing? i think they are discussing it - my reason to propose it now is that currently, `pacstrap base` no longer installs a working system - even if we fix the init-system conflicts, one still must `pacstrap base linux-libre` at the bare minimum to get a working system (and a boot-loader too) - in order to get an equivalent system as what the base group once installed, that pacstrap command would need to include all of the packages in my previous post if thats the way it is going to be then the documentation could be updated; but it would be quite ugly indeed - my interest is raising this topic now, is that i also need to add that mess to calamares and parabolaiso; and if this is a temporary situation (if arch does add a 'base-extras' package), then i will need to revert that anyways - so much simpler to add a 'base-extras' package now - it would be a harmless optional thing, so i dont see any reason not to do it - even if it helps only the installers - the thing to discuss is what packages should go in it probably a better name would be 'parabola-full' or something similar - i would also like to add a 'parabola-desktop' for the same reason - as it is now, i am maintaining the package lists for the installers in three different places; which is kinda tedious to manage - those are: the package lists for what goes on the various live systems, the package lists for the ncurses installers, and the package lists for calamares - it would be very good to consolidate those; and a good way to manage that is with meta-packages + 'provides' From megver83 at hyperbola.info Tue Nov 12 02:48:16 2019 From: megver83 at hyperbola.info (Megver83) Date: Mon, 11 Nov 2019 23:48:16 -0300 Subject: [Dev] arch replaced the 'base' package group with a leaner 'base' meta-package In-Reply-To: <20191111213207.3050be8b@parabola> References: <20191028113916.53184849@parabola> <20191030210529.349b77ba@primarylaptop.localdomain> <20191111180537.73f5d57f@parabola> <20191111213207.3050be8b@parabola> Message-ID: <17f236a6d8ade5ff95915164d4ab509ee9295fe3.camel@hyperbola.info> El lun, 11-11-2019 a las 21:32 -0500, bill-auger escribi?: > re: > why are we discussing adding a base-extra > metapackage / group? Isn't that something upstream should be > doing? > > i think they are discussing it - my reason to propose it now is > that currently, `pacstrap base` no longer installs a working > system - even if we fix the init-system conflicts, one still must > `pacstrap base linux-libre` at the bare minimum to get a working > system (and a boot-loader too) - in order to get an equivalent > system as what the base group once installed, that pacstrap > command would need to include all of the packages in my previous > post > > if thats the way it is going to be then the documentation could > be updated; but it would be quite ugly indeed - my interest is > raising this topic now, is that i also need to add that mess to > calamares and parabolaiso; and if this is a temporary situation > (if arch does add a 'base-extras' package), then i will need to > revert that anyways - so much simpler to add a 'base-extras' > package now - it would be a harmless optional thing, so i dont > see any reason not to do it - even if it helps only the > installers - the thing to discuss is what packages should go in > it > > probably a better name would be 'parabola-full' or something > similar - i would also like to add a 'parabola-desktop' for the > same reason - as it is now, i am maintaining the package lists > for the installers in three different places; which is kinda > tedious to manage - those are: the package lists for what goes > on the various live systems, the package lists for the ncurses > installers, and the package lists for calamares - it would be > very good to consolidate those; and a good way to manage that is > with meta-packages + 'provides' > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev I would wait to see what upstream does, but things like parabola- desktop (which Arch isn't likely to get sth. like that) could be added without problem. I saw some archiso commits and they had to update their package lists because of this new base metapackage thing, so maybe base-extras would not kill anyone, I feel like this new adoption of base metapkg with less pkgs that the ex base group gives users more flexibility in terms of which pkgs they want to install. For example, nano was in base group, but what about ppl who doesn't use it? it doesn't really belong to a very base installation, and here is my favorite part: you want it? then install it yourself, and that's the Arch philosophy, *do it yourself* From bill-auger at peers.community Sat Nov 16 18:55:43 2019 From: bill-auger at peers.community (bill-auger) Date: Sat, 16 Nov 2019 13:55:43 -0500 Subject: [Dev] Packages with PDF files embedding non-free fonts In-Reply-To: References: <0AF4Iq5mVg3A7Gh86NdUF2gIZTQdi6BS0jbsHI2GtQQrCOq263KLfgIHDjJkAfuloL7rDcE7LpQKKWA2UP-Rfo3jBBG1nEoFoS1RthSuv4U=@protonmail.com> Message-ID: <20191116135543.2d268d83@parabola> On Mon, 11 Nov 2019 08:53:22 +0000 grizzlyuser wrote: > what are the > best next steps to do with this issue, if it's an issue > indeed. problems that affect all FSDG distro are best discussed on the FSDG mailing list - i can suggest raising the issue on that list so see if or how other distros handle the situation https://lists.nongnu.org/mailman/listinfo/gnu-linux-libre From andreas at grapentin.org Sun Nov 17 00:26:19 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Sun, 17 Nov 2019 01:26:19 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191105222836.GA86715@parabola-pocket.localdomain> References: <20191105222836.GA86715@parabola-pocket.localdomain> Message-ID: <20191117002619.GA69197@parabola-pocket.localdomain> Hi, it's been almost two weeks since the first announcement was made, and I believe we have now a good understanding of our infrastructure and our hosting needs, and are ready to move forward. We have discussed internally, and have come to the conclusion that a good course of action could be to keep winston running, but start migrating some of the essential services off it one by one, streamlining their deplopment in the process. To get started, we are currently looking at getting a single VPS, with specs comparable to, or slightly improved upon, the specs of winston itself. Winston currently has: - (nominally) about 4GiB of RAM. we believe that 4GiB is currently the lower bound of what our services need to function. Winston is currently struggling with RAM, but this seems to be mainly because he's not having the nominal amount actually available for use. To get some room to breathe, we're hoping for an upgrade here towards the region of 6 or 8GiB of ram, mainly to make sure the machine doesn't need to swap as much as it does now. - 4 QEMU virtual CPUS @ 2.2GhZ winston is never really computationally busy. iirc, vikings is allowing only for 1 CPU VPS's (please correct me if I'm wrong) so we're not looking for an upgrade here. Realistically, anything that's not a potato should be sufficient to deal with our workload. - 500GiB of storage storage is getting a bit tight. We are planning to extend our repos to more architectures, chiefly ppc64le and riscv64, and we would not be able to host all the built packages due to limited storage capacity. Ideally, we would like to see an extended capacity of at least 1TiB here, in order to work towards our medium-term goals. Even more storage would allow us to move forward with other projects, such as providing a source packgaes repository, or maintaining a larger archive of older packages. But we can discuss these separately once the respective projects move forward. - virtually unlimited network traffic as far as I know, winston is not limited in terms of network traffic. And we do incur a LOT of network traffic. The order of magnitude should be somewhere in the single-digit TiB's per month, although it's hard to be sure since we don't have a monitoring in place. Most of this traffic is because of a growing number of busily syncing parabola mirrors, and we could cut that down by better structuring our network of mirrors, and giving that more of a hierarchy instead of having everyone pull from the root. We should talk to the vikings people here, what sort of traffic is allowed on their network, to get a feeling how much we need to cut down here. Also, we should start putting better traffic monitoring in place. So much for the rationale. In summary, we believe that we currently need a single VPS with: - a single core - at least 8GiB of RAM - at least 1TiB of storage - a reasonable agreement on traffic limits If I have missed or forgot anything, let me know. Otherwise, we should probably get the vikings people in the loop and discuss next steps! Best, Andreas (oaken-source) On Tue, Nov 05, 2019 at 11:28:36PM +0100, Andreas Grapentin wrote: > > Hi, > > As you know, a good chunk of the infrastructure that makes parabola is > currently hosted on a virtual machine called winston, which is > generously provided by the hosting provider 1984. We used to have proton > as well, but when that died, the things that it hosted were migrated > over to winston. > > It's come to our attention that this machine is currently struggling to > cope with the load it has to bear, as is evident by the fact that it is > as of this writing at ~70% swap utilization, and requires more and more > frequent reboots just to keep our basic infrastructure operational. As > you can probably imagine, this is not a healthy mode of operation for a > distribution, and is something that is eating a bunch of hacker time to > keep on top of. > > These developments have prompted freemor, bill-auger and me to keep an > eye open for other hosting options that would maybe give our services > and bit more breathing room, and maybe some space to grow and expand. > > bill-auger had floated the idea to get in touch with the people over at > vikings (vikings.net) -- in CC -- who offer (among other things) hosting > services on exclusively libre-friendly server hardware, which would be > perfect for parabola. We did already have a brief chat with their team > to figure out what their available hosting options are, and now we need > to discuss amongs ourselves what sort of infrastructure we want going > forwards. > > I think it would make sense to start by listing all the services that > the new infrastructure should host, and estimating from there what sort > of physical or virtual machine or machines we need, and how we > distribute the services. > > Off the top of my head, these are the services that I know we run: > > - webserver for parabola.nu, including > - wiki > - main website > - git repositories > - issue tracker (redmine?) > - forum > - Tier 0 package repositories > - repo importer > - mailman > > But I'm probably missing a bunch of things. This is where I'd like > someone more experienced with our infrastructure to step in and explain > what we have and need. I would suggest we start maintaining this > information in the wiki as well, assuming no such article exists > already. This might come in handy down the line. > > My hunch as a Software Engineer and Architect would be that it could > make sense to partition these services in two, or maybe three VMs, just > to have a more fine-grained control over fault tolerance and recovery in > case something does go belly-up, and to be able to separate the critical > from the non-critical infrastructure. But this is something we need to > discuss down the line, if we have a clear idea about our service > landscape. > > While we do this, I would also suggest we take another look at which > part of our infrastructure could and / or should be converted to > packages, instead of unaccounted for files. We could conceivably add a > separate undocumented repo for server-only packages. And while we're at > that, I would also like to take a gander at automatic provisioners, such > as ansible, that would allow us to describe our server roles and then > automatically deploy them as needed, to have a self-documenting > deployment of our services. > > But first, let's complete the list of services that parabola needs to > function, and figure out how we want to partition these and what sort of > resources they need. Everything beyond that is still far away. :) > > > I have to say; I am personally very excited to see these changes unfold. > I believe that parabola is currently at a place where we need to > stabilize our infrastructure and establish ourselves as a serious > distribution. And a collaboration with vikings could be a great chance > to take a leap toward that direction. > > However, I also appreciate that parabola is an adhocracy, and that each > of you has their own unique views on these issues and options. If you > have any concerns about these developments, please bring them to our > attention as well. > > I'm looking forwards to everyones input. > > Best, > Andreas > > oaken-source > > > > -- > > ------------------------------------------------------------------------------ > my GPG Public Key: https://files.grapentin.org/.gpg/public.key > ------------------------------------------------------------------------------ > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From megver83 at hyperbola.info Sun Nov 17 01:49:16 2019 From: megver83 at hyperbola.info (Megver83) Date: Sat, 16 Nov 2019 22:49:16 -0300 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191117002619.GA69197@parabola-pocket.localdomain> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> Message-ID: El dom, 17-11-2019 a las 01:26 +0100, Andreas Grapentin escribi?: > Hi, > > it's been almost two weeks since the first announcement was made, and > I > believe we have now a good understanding of our infrastructure and > our > hosting needs, and are ready to move forward. > > We have discussed internally, and have come to the conclusion that a > good course of action could be to keep winston running, but start > migrating some of the essential services off it one by one, > streamlining > their deplopment in the process. > > To get started, we are currently looking at getting a single VPS, > with > specs comparable to, or slightly improved upon, the specs of winston > itself. > > Winston currently has: > > - (nominally) about 4GiB of RAM. > > we believe that 4GiB is currently the lower bound of what our > services need to function. Winston is currently struggling with > RAM, > but this seems to be mainly because he's not having the nominal > amount actually available for use. > > To get some room to breathe, we're hoping for an upgrade here > towards > the region of 6 or 8GiB of ram, mainly to make sure the machine > doesn't need to swap as much as it does now. > +1 > - 4 QEMU virtual CPUS @ 2.2GhZ > > winston is never really computationally busy. iirc, vikings is > allowing only for 1 CPU VPS's (please correct me if I'm wrong) so > we're not looking for an upgrade here. Realistically, anything > that's > not a potato should be sufficient to deal with our workload. > +1 > - 500GiB of storage > > storage is getting a bit tight. We are planning to extend our > repos > to more architectures, chiefly ppc64le and riscv64, and we would > not > be able to host all the built packages due to limited storage > capacity. Regarding the ppc64le and riscv64 ports, we have to discuss that because we need more people for this *unless* we set up a functional autobuilder for all our packages in a very capable machine (mainly because there are some *very heavy* software). We can create a git repo for modified PKGBUILDs like Arch32 and ALARM do, but for testing these in real hardware (because IMO it's useless to waste time in porting to architectures that are only going to be used in VMs or emulators) we need testers (could be some Parabola devs with this hardware or very collaborative users that own it). Plus, some packages won't cross- compile using qemu (like libretools does with armv7h), which is sth. that has happened to me with some armv7 pkgs, so I build them in my Banana Pi and works. Idk how will we do for ppc64le, because the TALOS II is too expensive, but there are other PPC computers (I'm digging a bit about them, I already know the discontinued PowerMacs from Apple but I want to find something more) > > Ideally, we would like to see an extended capacity of at least > 1TiB > here, in order to work towards our medium-term goals. Even more > storage would allow us to move forward with other projects, such > as > providing a source packgaes repository, or maintaining a larger > archive of older packages. But we can discuss these separately > once > the respective projects move forward. > - virtually unlimited network traffic > > as far as I know, winston is not limited in terms of network > traffic. > And we do incur a LOT of network traffic. The order of magnitude > should be somewhere in the single-digit TiB's per month, although > it's hard to be sure since we don't have a monitoring in place. > > Most of this traffic is because of a growing number of busily > syncing > parabola mirrors, and we could cut that down by better structuring > our network of mirrors, and giving that more of a hierarchy > instead > of having everyone pull from the root. > > We should talk to the vikings people here, what sort of traffic is > allowed on their network, to get a feeling how much we need to cut > down here. Also, we should start putting better traffic monitoring > in > place. > > So much for the rationale. In summary, we believe that we currently > need > a single VPS with: > > - a single core > - at least 8GiB of RAM > - at least 1TiB of storage > - a reasonable agreement on traffic limits > > If I have missed or forgot anything, let me know. Otherwise, we > should > probably get the vikings people in the loop and discuss next steps! > > Best, > Andreas (oaken-source) > > > > On Tue, Nov 05, 2019 at 11:28:36PM +0100, Andreas Grapentin wrote: > > Hi, > > > > As you know, a good chunk of the infrastructure that makes parabola > > is > > currently hosted on a virtual machine called winston, which is > > generously provided by the hosting provider 1984. We used to have > > proton > > as well, but when that died, the things that it hosted were > > migrated > > over to winston. > > > > It's come to our attention that this machine is currently > > struggling to > > cope with the load it has to bear, as is evident by the fact that > > it is > > as of this writing at ~70% swap utilization, and requires more and > > more > > frequent reboots just to keep our basic infrastructure operational. > > As > > you can probably imagine, this is not a healthy mode of operation > > for a > > distribution, and is something that is eating a bunch of hacker > > time to > > keep on top of. > > > > These developments have prompted freemor, bill-auger and me to keep > > an > > eye open for other hosting options that would maybe give our > > services > > and bit more breathing room, and maybe some space to grow and > > expand. > > > > bill-auger had floated the idea to get in touch with the people > > over at > > vikings (vikings.net) -- in CC -- who offer (among other things) > > hosting > > services on exclusively libre-friendly server hardware, which would > > be > > perfect for parabola. We did already have a brief chat with their > > team > > to figure out what their available hosting options are, and now we > > need > > to discuss amongs ourselves what sort of infrastructure we want > > going > > forwards. > > > > I think it would make sense to start by listing all the services > > that > > the new infrastructure should host, and estimating from there what > > sort > > of physical or virtual machine or machines we need, and how we > > distribute the services. > > > > Off the top of my head, these are the services that I know we run: > > > > - webserver for parabola.nu, including > > - wiki > > - main website > > - git repositories > > - issue tracker (redmine?) > > - forum > > - Tier 0 package repositories > > - repo importer > > - mailman > > > > But I'm probably missing a bunch of things. This is where I'd like > > someone more experienced with our infrastructure to step in and > > explain > > what we have and need. I would suggest we start maintaining this > > information in the wiki as well, assuming no such article exists > > already. This might come in handy down the line. > > > > My hunch as a Software Engineer and Architect would be that it > > could > > make sense to partition these services in two, or maybe three VMs, > > just > > to have a more fine-grained control over fault tolerance and > > recovery in > > case something does go belly-up, and to be able to separate the > > critical > > from the non-critical infrastructure. But this is something we need > > to > > discuss down the line, if we have a clear idea about our service > > landscape. > > > > While we do this, I would also suggest we take another look at > > which > > part of our infrastructure could and / or should be converted to > > packages, instead of unaccounted for files. We could conceivably > > add a > > separate undocumented repo for server-only packages. And while > > we're at > > that, I would also like to take a gander at automatic provisioners, > > such > > as ansible, that would allow us to describe our server roles and > > then > > automatically deploy them as needed, to have a self-documenting > > deployment of our services. > > > > But first, let's complete the list of services that parabola needs > > to > > function, and figure out how we want to partition these and what > > sort of > > resources they need. Everything beyond that is still far away. :) > > > > > > I have to say; I am personally very excited to see these changes > > unfold. > > I believe that parabola is currently at a place where we need to > > stabilize our infrastructure and establish ourselves as a serious > > distribution. And a collaboration with vikings could be a great > > chance > > to take a leap toward that direction. > > > > However, I also appreciate that parabola is an adhocracy, and that > > each > > of you has their own unique views on these issues and options. If > > you > > have any concerns about these developments, please bring them to > > our > > attention as well. > > > > I'm looking forwards to everyones input. > > > > Best, > > Andreas > > > > oaken-source > > > > > > > > -- > > > > ----------------------------------------------------------------- > > ------------- > > my GPG Public Key: > > https://files.grapentin.org/.gpg/public.key > > ----------------------------------------------------------------- > > ------------- > > > > _______________________________________________ > > Dev mailing list > > Dev at lists.parabola.nu > > https://lists.parabola.nu/mailman/listinfo/dev > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Sun Nov 17 02:45:37 2019 From: bill-auger at peers.community (bill-auger) Date: Sat, 16 Nov 2019 21:45:37 -0500 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191117002619.GA69197@parabola-pocket.localdomain> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> Message-ID: <20191116214537.7ce3871f@parabola> the bandwidth requirements are surely the most difficult to put a figure on; though we do have some degree of flexibility in that area, at least for the near future - bandwidth is also the most costly expense; so it does require the most judicious attention - with no changes to the current mirrors and stratification, i would guesstimate that actual increase in bandwidth demand, above what we are using now, will probably be roughly 2-3 TiB's per month - thats based on something lukeshu told me about two years ago - my memory is a bit fuzzy on the exact numbers; but i do know that we had fewer mirrors at that time - we should probably contact 1984, to see if we can get a better estimate of this year's usage there are a few ways that we can partition bandwidth usage, if the constraints become too tight, though none are without caveats if all of the web services were moved to a new server and winston were reserved exclusively for in-bound publishing and hosting of the up-to-date package repos as the only tier0, that would lower the bandwidth requirements for the new server greatly, at least in the short-term - a very modest bandwidth server could handle the much lighter web and email traffic, plus the presumably low demand for sources and repos of recently-outdated packages for the rare emergency downgrade situations - if all web services were on one server though, that would be the one with the large memory requirement that arrangement would also free a lot of disk space on winston - probably just enough to fit five complete arches of up-to-date packages; with winston remaining at its current limits of both bandwidth and disk space any way we dice it though, the addition of two new ports will nearly double parabola's total bandwidth requirement, probably to beyond the generosity of any single host sponsor; so we may need to re-organize mirrors into tiers anyways, or to split the tier0 repos across multiple servers, if the new server affords bandwidth on par with what winston is handling now - though the latter would complicate libretools and/or the rsync mirroring protocol - on the other hand, the former would increase the load on whichever mirrors that would agree to become tier1 - i have no prediction at the moment regarding which, if any can handle the extra load From bill-auger at peers.community Sun Nov 17 03:25:50 2019 From: bill-auger at peers.community (bill-auger) Date: Sat, 16 Nov 2019 22:25:50 -0500 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> Message-ID: <20191116222550.4d70a795@parabola> i dont think supporting older PPC CPUs is on the roadmap - those would probably need to be separate ports; and the last arch-like system (now defunct) was for PPC6 - there was a large gap there that oaken-source and ebrasca had to leap over to get to POWER9 the talos has dropped in price significantly recently though, and it was just RYF-certified last week, so we really should do our best to support it - i agree that one of us should probably have access to one - as you pointed out, that may even be necessary - in the worst case scenario, maybe we can entice ebrasca to dedicate a piece of his for testing purposes, or for building finicky packages as will be the case for any small manufacturer of new libre-design hardware, early adopters are the most important factor for its success, and i think the only options now for POWER9 are debian and opensuse - it will surely be a lot of work; but parabola is well-tooled for the task of porting and already has bootable prototypes for both POWER9 and RISC-V - i dont think that any other FSDG distros are working on either of those ports, or even proposing to do so; but at least one should exist From andreas at grapentin.org Sun Nov 17 07:29:24 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Sun, 17 Nov 2019 08:29:24 +0100 Subject: [Dev] Advancing ppc64le and riscv64 (Was: Let's talk about Infrastructure and Hosting) In-Reply-To: References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> Message-ID: <20191117072924.GA71401@parabola-pocket.localdomain> Hi, On Sat, Nov 16, 2019 at 10:49:16PM -0300, Megver83 wrote: > El dom, 17-11-2019 a las 01:26 +0100, Andreas Grapentin escribi?: > > - 500GiB of storage > > > > storage is getting a bit tight. We are planning to extend our > > repos > > to more architectures, chiefly ppc64le and riscv64, and we would > > not > > be able to host all the built packages due to limited storage > > capacity. > > Regarding the ppc64le and riscv64 ports, we have to discuss that > because we need more people for this *unless* we set up a functional > autobuilder for all our packages in a very capable machine (mainly > because there are some *very heavy* software). We can create a git repo > for modified PKGBUILDs like Arch32 and ALARM do, but for testing these > in real hardware (because IMO it's useless to waste time in porting to > architectures that are only going to be used in VMs or emulators) we > need testers (could be some Parabola devs with this hardware or very > collaborative users that own it). Plus, some packages won't cross- > compile using qemu (like libretools does with armv7h), which is sth. > that has happened to me with some armv7 pkgs, so I build them in my > Banana Pi and works. > > Idk how will we do for ppc64le, because the TALOS II is too expensive, > but there are other PPC computers (I'm digging a bit about them, I > already know the discontinued PowerMacs from Apple but I want to find > something more) I agree that this development needs real, powerful hardware. That is why I have applied for funding from nlnet and am hoping to be able to purchase a Talos machine as well as two HiFive boards by the end of the year. If that happens, I will put some time into a smarter autobuilder. But this is something that's not due to happen before spring 2020. -A -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nobody at parabola.nu Sun Nov 17 14:15:16 2019 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 17 Nov 2019 14:15:16 -0000 Subject: [Dev] Orphan Libre package [texlive-fontsextra] marked out-of-date Message-ID: <20191117141516.1168.99921@winston.parabola.nu> theova at member.fsf.org wants to notify you that the following packages may be out-of-date: * texlive-fontsextra 2018.49197-1.par1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/texlive-fontsextra/ * texlive-fontsextra 2018.49197-1.par1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/texlive-fontsextra/ * texlive-fontsextra 2018.49197-1.par1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/texlive-fontsextra/ The user provided the following additional text: Version 2019.52580-1 is in Arch's [extra]. From hello at vikings.net Sun Nov 17 08:26:28 2019 From: hello at vikings.net (Vikings GmbH) Date: Sun, 17 Nov 2019 09:26:28 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191117002619.GA69197@parabola-pocket.localdomain> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> Message-ID: <20191117092628.001c5bd3@balder.lan> On Sun, 17 Nov 2019 01:26:19 +0100 Andreas Grapentin wrote: > > Hi, > > it's been almost two weeks since the first announcement was made, and > I believe we have now a good understanding of our infrastructure and > our hosting needs, and are ready to move forward. > > We have discussed internally, and have come to the conclusion that a > good course of action could be to keep winston running, but start > migrating some of the essential services off it one by one, > streamlining their deplopment in the process. > > To get started, we are currently looking at getting a single VPS, with > specs comparable to, or slightly improved upon, the specs of winston > itself. > > Winston currently has: > > - (nominally) about 4GiB of RAM. > > we believe that 4GiB is currently the lower bound of what our > services need to function. Winston is currently struggling with > RAM, but this seems to be mainly because he's not having the nominal > amount actually available for use. > > To get some room to breathe, we're hoping for an upgrade here > towards the region of 6 or 8GiB of ram, mainly to make sure the > machine doesn't need to swap as much as it does now. > > - 4 QEMU virtual CPUS @ 2.2GhZ > > winston is never really computationally busy. iirc, vikings is > allowing only for 1 CPU VPS's (please correct me if I'm wrong) so Wrong :) Vikings can do anything between 1 and 32 CPUs. When we say "CPU" we refer to the physical core and not some over-subscribed, mass-hosting shenanigans. > we're not looking for an upgrade here. Realistically, anything > that's not a potato should be sufficient to deal with our workload. > > - 500GiB of storage > > storage is getting a bit tight. We are planning to extend our repos > to more architectures, chiefly ppc64le and riscv64, and we would > not be able to host all the built packages due to limited storage > capacity. > > Ideally, we would like to see an extended capacity of at least 1TiB > here, in order to work towards our medium-term goals. Even more > storage would allow us to move forward with other projects, such as > providing a source packgaes repository, or maintaining a larger > archive of older packages. But we can discuss these separately once > the respective projects move forward. > > - virtually unlimited network traffic > > as far as I know, winston is not limited in terms of network > traffic. And we do incur a LOT of network traffic. The order of > magnitude should be somewhere in the single-digit TiB's per month, > although it's hard to be sure since we don't have a monitoring in > place. > > Most of this traffic is because of a growing number of busily > syncing parabola mirrors, and we could cut that down by better > structuring our network of mirrors, and giving that more of a > hierarchy instead of having everyone pull from the root. > > We should talk to the vikings people here, what sort of traffic is > allowed on their network, to get a feeling how much we need to cut > down here. Also, we should start putting better traffic monitoring > in place. > > So much for the rationale. In summary, we believe that we currently > need a single VPS with: > > - a single core > - at least 8GiB of RAM > - at least 1TiB of storage > - a reasonable agreement on traffic limits > > If I have missed or forgot anything, let me know. Otherwise, we should > probably get the vikings people in the loop and discuss next steps! > > Best, > Andreas (oaken-source) > > > > On Tue, Nov 05, 2019 at 11:28:36PM +0100, Andreas Grapentin wrote: > > > > Hi, > > > > As you know, a good chunk of the infrastructure that makes parabola > > is currently hosted on a virtual machine called winston, which is > > generously provided by the hosting provider 1984. We used to have > > proton as well, but when that died, the things that it hosted were > > migrated over to winston. > > > > It's come to our attention that this machine is currently > > struggling to cope with the load it has to bear, as is evident by > > the fact that it is as of this writing at ~70% swap utilization, > > and requires more and more frequent reboots just to keep our basic > > infrastructure operational. As you can probably imagine, this is > > not a healthy mode of operation for a distribution, and is > > something that is eating a bunch of hacker time to keep on top of. > > > > These developments have prompted freemor, bill-auger and me to keep > > an eye open for other hosting options that would maybe give our > > services and bit more breathing room, and maybe some space to grow > > and expand. > > > > bill-auger had floated the idea to get in touch with the people > > over at vikings (vikings.net) -- in CC -- who offer (among other > > things) hosting services on exclusively libre-friendly server > > hardware, which would be perfect for parabola. We did already have > > a brief chat with their team to figure out what their available > > hosting options are, and now we need to discuss amongs ourselves > > what sort of infrastructure we want going forwards. > > > > I think it would make sense to start by listing all the services > > that the new infrastructure should host, and estimating from there > > what sort of physical or virtual machine or machines we need, and > > how we distribute the services. > > > > Off the top of my head, these are the services that I know we run: > > > > - webserver for parabola.nu, including > > - wiki > > - main website > > - git repositories > > - issue tracker (redmine?) > > - forum > > - Tier 0 package repositories > > - repo importer > > - mailman > > > > But I'm probably missing a bunch of things. This is where I'd like > > someone more experienced with our infrastructure to step in and > > explain what we have and need. I would suggest we start maintaining > > this information in the wiki as well, assuming no such article > > exists already. This might come in handy down the line. > > > > My hunch as a Software Engineer and Architect would be that it could > > make sense to partition these services in two, or maybe three VMs, > > just to have a more fine-grained control over fault tolerance and > > recovery in case something does go belly-up, and to be able to > > separate the critical from the non-critical infrastructure. But > > this is something we need to discuss down the line, if we have a > > clear idea about our service landscape. > > > > While we do this, I would also suggest we take another look at which > > part of our infrastructure could and / or should be converted to > > packages, instead of unaccounted for files. We could conceivably > > add a separate undocumented repo for server-only packages. And > > while we're at that, I would also like to take a gander at > > automatic provisioners, such as ansible, that would allow us to > > describe our server roles and then automatically deploy them as > > needed, to have a self-documenting deployment of our services. > > > > But first, let's complete the list of services that parabola needs > > to function, and figure out how we want to partition these and what > > sort of resources they need. Everything beyond that is still far > > away. :) > > > > > > I have to say; I am personally very excited to see these changes > > unfold. I believe that parabola is currently at a place where we > > need to stabilize our infrastructure and establish ourselves as a > > serious distribution. And a collaboration with vikings could be a > > great chance to take a leap toward that direction. > > > > However, I also appreciate that parabola is an adhocracy, and that > > each of you has their own unique views on these issues and options. > > If you have any concerns about these developments, please bring > > them to our attention as well. > > > > I'm looking forwards to everyones input. > > > > Best, > > Andreas > > > > oaken-source -- Best regards/Mit freundlichen Gr??en/Cordialement/Met vriendelijke groet The Vikings Team Web: https://www.vikings.net/ Store: https://store.vikings.net/ Phone: +49 69 247 54 91 0 Fax: +49 69 247 50 339 Follow us on Mastodon: https://social.vikings.net/@vikings Follow us on Twitter: https://twitter.com/vikingslibre Vikings GmbH Sauerackerweg 14, 60529 Frankfurt/Main, Germany Register Court: AG Frankfurt am Main Register No.: HR B 84497, CEO: Thomas Umbach Tax Office: Frankfurt am Main, VATIN: DE254094338 GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hello at vikings.net Sun Nov 17 08:43:05 2019 From: hello at vikings.net (Vikings GmbH) Date: Sun, 17 Nov 2019 09:43:05 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191116222550.4d70a795@parabola> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> <20191116222550.4d70a795@parabola> Message-ID: <20191117094305.4bc600c3@balder.lan> On Sat, 16 Nov 2019 22:25:50 -0500 bill-auger wrote: > i dont think supporting older PPC CPUs is on the roadmap - > those would probably need to be separate ports; and the last > arch-like system (now defunct) was for PPC6 - there was a large > gap there that oaken-source and ebrasca had to leap over to get > to POWER9 > > the talos has dropped in price significantly recently though, > and it was just RYF-certified last week, so we really should do > our best to support it - i agree that one of us should probably > have access to one - as you pointed out, that may even be > necessary - in the worst case scenario, maybe we can entice > ebrasca to dedicate a piece of his for testing purposes, or for > building finicky packages I'd like to suggest to tell Raptor Computing Systems that you'd like to port Parabola GNU/Linux to PPC and make them aware of your plans; they usually support things like that strongly from what we've seen so far. They might even provide you with a machine that is either significantly reduced in price, free of charge or perhaps as a loaner. Vikings would be the last to not chime in with space and infrastructure to host such a machine with the potential outcome that Parabola will be ported. > > as will be the case for any small manufacturer of new > libre-design hardware, early adopters are the most important > factor for its success, and i think the only options now for > POWER9 are debian and opensuse - it will surely be a lot > of work; but parabola is well-tooled for the task of porting and > already has bootable prototypes for both POWER9 and RISC-V - i > dont think that any other FSDG distros are working on either of > those ports, or even proposing to do so; but at least one should > exist The distro choices for PPC are very limited at present, the more it would be welcomed to improve the situation from our POV. -- Best regards/Mit freundlichen Gr??en/Cordialement/Met vriendelijke groet The Vikings Team Web: https://www.vikings.net/ Store: https://store.vikings.net/ Phone: +49 69 247 54 91 0 Fax: +49 69 247 50 339 Follow us on Mastodon: https://social.vikings.net/@vikings Follow us on Twitter: https://twitter.com/vikingslibre Vikings GmbH Sauerackerweg 14, 60529 Frankfurt/Main, Germany Register Court: AG Frankfurt am Main Register No.: HR B 84497, CEO: Thomas Umbach Tax Office: Frankfurt am Main, VATIN: DE254094338 GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andreas at grapentin.org Sun Nov 17 16:03:12 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Sun, 17 Nov 2019 17:03:12 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191117094305.4bc600c3@balder.lan> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> <20191116222550.4d70a795@parabola> <20191117094305.4bc600c3@balder.lan> Message-ID: <20191117160312.GA78989@parabola-pocket.localdomain> On Sun, Nov 17, 2019 at 09:43:05AM +0100, Vikings GmbH wrote: > On Sat, 16 Nov 2019 22:25:50 -0500 > bill-auger wrote: > > > i dont think supporting older PPC CPUs is on the roadmap - > > those would probably need to be separate ports; and the last > > arch-like system (now defunct) was for PPC6 - there was a large > > gap there that oaken-source and ebrasca had to leap over to get > > to POWER9 > > > > the talos has dropped in price significantly recently though, > > and it was just RYF-certified last week, so we really should do > > our best to support it - i agree that one of us should probably > > have access to one - as you pointed out, that may even be > > necessary - in the worst case scenario, maybe we can entice > > ebrasca to dedicate a piece of his for testing purposes, or for > > building finicky packages > > I'd like to suggest to tell Raptor Computing Systems that you'd like > to port Parabola GNU/Linux to PPC and make them aware of your plans; > they usually support things like that strongly from what we've seen so > far. They might even provide you with a machine that is either > significantly reduced in price, free of charge or perhaps as a loaner. > Vikings would be the last to not chime in with space and infrastructure > to host such a machine with the potential outcome that Parabola will be > ported. This would be an ideal outcome for us -- a Talos Server unit located in your shared hosting space. Thanks for the suggestion, I will write a mail to Raptor immediately to enquire about this. Thanks! -A -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From freemor at freemor.ca Mon Nov 18 02:29:39 2019 From: freemor at freemor.ca (Freemor) Date: Sun, 17 Nov 2019 22:29:39 -0400 Subject: [Dev] Creating a neutered geoclue for [nonprism] Message-ID: <20191118022939.GO4906@freemor.ca> Because privacy is important to me I try to keep my fingers into the [nonprism] pot. In doing that I'm noticing another qt-webengine situation starting to unfold. Which is the ever creeping inclusion of geoclue into different projects. Tho it can be disabled by killing the systemd or initd service that run it. I strongly feel creating a neutered version that either fails to return any location (preferable) or returns a benign location (like south pole, Middle of the Pacific Ocean, etc) is preferable as it would 1.) Give a safe drop in replacement. (Won't rat you out even if it is accidentally enabled). 2.) Sends a clear message showing that we think the default behaviour is broken and requires fixing. 3.) Doing the work to create a build recipe for a neutered geoclue will server to show people that such is possible. And also serve to make it easier for other RYF distros to benefit from our (by which I mean mostly my, unless other feel heavily motivated to join in) work on neutering it. There are Several build flags that can be tweaked to disable functionality. This is where I plan to start also creating a custom geoclue.conf. And then if necessary patching the source kill any remaining leaks. Basically do what ever we can to turn geoclue into the "location service" equiv of /bin/false. I've already started on the PKGBUILD with every relevant build flag set to false. I'll build that and do some testing. Then take a look at creating the custom geoclue.conf Regards, Freemmor Ps Because this failed to send the first time I now have a version of geoclue that seems to fail spectacularly at finding any location. More Testing needed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Mon Nov 18 02:58:28 2019 From: bill-auger at peers.community (bill-auger) Date: Sun, 17 Nov 2019 21:58:28 -0500 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191118022939.GO4906@freemor.ca> References: <20191118022939.GO4906@freemor.ca> Message-ID: <20191117215828.70a202cd@parabola> aka: 'no-clue' i found this suggested trick on the inter-webs: https://unix.stackexchange.com/questions/224487/uninstall-geoclue-from-debian From freemor at freemor.ca Mon Nov 18 12:03:36 2019 From: freemor at freemor.ca (Freemor) Date: Mon, 18 Nov 2019 08:03:36 -0400 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191117215828.70a202cd@parabola> References: <20191118022939.GO4906@freemor.ca> <20191117215828.70a202cd@parabola> Message-ID: <20191118120336.GP4906@freemor.ca> On Sun, Nov 17, 2019 at 09:58:28PM -0500, bill-auger wrote: > aka: 'no-clue' > > i found this suggested trick on the inter-webs: > > https://unix.stackexchange.com/questions/224487/uninstall-geoclue-from-debian I'll keep that link around for future reference. My concern is some poorly written stuff might error out if it cant find the DBus service. Also there may be other ways to enquire using the geoclue Library and I want those blocked too if they exist. The "mask" option is interesting I'll have to read up on that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Mon Nov 18 14:27:24 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 18 Nov 2019 09:27:24 -0500 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191118120336.GP4906@freemor.ca> References: <20191118022939.GO4906@freemor.ca> <20191117215828.70a202cd@parabola> <20191118120336.GP4906@freemor.ca> Message-ID: <20191118092724.1346813e@parabola> just a little mini-rant to make it clear to everyone that geoclue is about 1% of the perceived problem - pacman shows this relatively small number of clients: empathy gnome-clocks gnome-initial-setup gnome-maps gnome-settings-daemon gnome-weather pantheon-calendar qreator redshift viking xdg-desktop-portal FWIW, geoclue is just the favored freedesktop abstraction and is adopted mainly by gnome, as it pretty clear from that dependents list - there are countless goelocation services though, that require nothing but a generic HTTP client; and surely the majority of applications that have such a feature use a leaner zero-dependency method - the calamares implementation for example, is basically as simple as this: $ curl https://geoip.kde.org/v1/ubiquity to address the situation fundamentally, the only real solution is to educate people on how to observe their network traffic, steps to resolves each IP to some identifiable service, and steps to block requests to unidentified IPs - the dowse tool from dyne.org is intended to simplify that - i havent tried it myself; but i expect it begins with extremely limited internet access, until one learns to manage the whitelist/blacklist, or however it works - of course, like freedom-box, even such well-intentioned, semi-user-friendly tools have the typical adoption problem of convincing people to hack their router, and/or operate their own services surely. none of that was particularly enlightening to freemor - i just wanted to put it out there for the sake of full disclosure - theres only so much that a distro can reasonably do on behalf of its users - beyond that, folks who want more computing freedom and privacy will need to take their machines into their own hands, to some non-trivial degree From bill-auger at peers.community Mon Nov 18 14:56:23 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 18 Nov 2019 09:56:23 -0500 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191118092724.1346813e@parabola> References: <20191118022939.GO4906@freemor.ca> <20191117215828.70a202cd@parabola> <20191118120336.GP4906@freemor.ca> <20191118092724.1346813e@parabola> Message-ID: <20191118095623.35e52eda@parabola> i cant help but to credit calamares as a shining example of an application that addresses such "anti-features", which some people would like and others would not, by giving the end-user maximal control over the program - everything that can possibly be deferred until run-time is configurable by the user via simple YAML files - not only is the geo-location feature not a hard-dependency; it is not even a compile-time option - each user can easily enable/disable it regardless of how calamares was compiled, or define a custom service provider, before launching the program - users can even disable the entire locale module, or any others, as they please; and the program would run happily to completion, only leaving the target system without the locale set From freemor at freemor.ca Mon Nov 18 15:55:32 2019 From: freemor at freemor.ca (Freemor) Date: Mon, 18 Nov 2019 11:55:32 -0400 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191118092724.1346813e@parabola> References: <20191118022939.GO4906@freemor.ca> <20191117215828.70a202cd@parabola> <20191118120336.GP4906@freemor.ca> <20191118092724.1346813e@parabola> Message-ID: <20191118155532.GQ4906@freemor.ca> On Mon, Nov 18, 2019 at 09:27:24AM -0500, bill-auger wrote: [Snip] > surely. none of that was particularly enlightening to freemor - > i just wanted to put it out there for the sake of full disclosure > - theres only so much that a distro can reasonably do on behalf > of its users - beyond that, folks who want more computing freedom > and privacy will need to take their machines into their own > hands, to some non-trivial degree Excellent point. And yes nothing new there for me but definitely worth mentioning. I'm certainly not trying to save the world here. And I'm a big proponent of people taking personal responsibility for their privacy. I'm just seeing geoclue finding it's way into more and more (mostly gnome) things and wanted a way to fix that, that doesn't involve fixing each separate program. but things like Browsers have their own and there are things like the geoip lookup DBs. But there are several packages in nonprism that one of the main reasons they are there is to remove geoclue support nonprism/webkit2gtk for example. So, in I can neuter geoclue. The we can loose all the "Remove geoclue support" builds. Even just webkit2gtk would make this worth while as it is one of the fairly large builds while geoclue is a tiny one. If we can fix 5 things with 1 rebuild then to me that seems the saner approach. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From theova at bluewin.ch Tue Nov 19 10:41:57 2019 From: theova at bluewin.ch (theova) Date: Tue, 19 Nov 2019 11:41:57 +0100 Subject: [Dev] Creating a neutered geoclue for [nonprism] In-Reply-To: <20191118155532.GQ4906@freemor.ca> References: <20191118022939.GO4906@freemor.ca> <20191117215828.70a202cd@parabola> <20191118120336.GP4906@freemor.ca> <20191118092724.1346813e@parabola> <20191118155532.GQ4906@freemor.ca> Message-ID: <20191119104157.5yum7tts6xfypi5p@RainbowWarrior.localdomain> I support the idea as it seems to simplify things by equal privacy. Returning a fix location has already been discussed on the geoclue bug tracker, see: - https://gitlab.freedesktop.org/geoclue/geoclue/issues/51 - https://gitlab.freedesktop.org/geoclue/geoclue/issues/93 and in gnome-control-center - https://gitlab.gnome.org/GNOME/gnome-control-center/issues/323 Altough, I don't think it is not implemented yet. We should take care that faking geoclues position does not lead to undesired behaviour, e.g. wrong time, nightlight turning on in the morning, ... I'm not sure how geoclues position is used for such services. Returning NaN may probably help in those cases. Freemor schrieb am Mon, 18. Nov 19 11:55: >On Mon, Nov 18, 2019 at 09:27:24AM -0500, bill-auger wrote: >[Snip] >> surely. none of that was particularly enlightening to freemor - >> i just wanted to put it out there for the sake of full disclosure >> - theres only so much that a distro can reasonably do on behalf >> of its users - beyond that, folks who want more computing freedom >> and privacy will need to take their machines into their own >> hands, to some non-trivial degree > >Excellent point. And yes nothing new there for me but definitely worth >mentioning. I'm certainly not trying to save the world here. And I'm a >big proponent of people taking personal responsibility for their privacy. > >I'm just seeing geoclue finding it's way into more and more (mostly gnome) >things and wanted a way to fix that, that doesn't involve fixing each separate >program. > >but things like Browsers have their own and there are things like the geoip >lookup DBs. > >But there are several packages in nonprism that one of the main reasons they >are there is to remove geoclue support nonprism/webkit2gtk for example. So, in >I can neuter geoclue. The we can loose all the "Remove geoclue support" builds. >Even just webkit2gtk would make this worth while as it is one of the fairly >large builds while geoclue is a tiny one. If we can fix 5 things with 1 rebuild >then to me that seems the saner approach. > > > > >_______________________________________________ >Dev mailing list >Dev at lists.parabola.nu >https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nobody at parabola.nu Tue Nov 19 14:38:43 2019 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 19 Nov 2019 14:38:43 -0000 Subject: [Dev] Orphan Libre package [reflector] marked out-of-date Message-ID: <20191119143843.1168.18237@winston.parabola.nu> grizzlyuser at protonmail.com wants to notify you that the following packages may be out-of-date: * reflector 2019.10-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/reflector/ * reflector 2019.10-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/reflector/ * reflector 2019.10-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/reflector/ The user provided the following additional text: Thank you for maintaining this package! Arch Linux rebuilt their package with commit "Python 3.8 rebuild" It looks like without the rebuild, reflector won't launch, printing the message "No module named Reflector". From ebrasca at librepanther.com Tue Nov 19 23:24:02 2019 From: ebrasca at librepanther.com (Bruno Cichon) Date: Wed, 20 Nov 2019 00:24:02 +0100 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <20191117160312.GA78989@parabola-pocket.localdomain> (Andreas Grapentin's message of "Sun, 17 Nov 2019 17:03:12 +0100") References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> <20191116222550.4d70a795@parabola> <20191117094305.4bc600c3@balder.lan> <20191117160312.GA78989@parabola-pocket.localdomain> Message-ID: <87imnfe9gt.fsf@librepanther.com> I can help. How much cores and RAM do you like to get? Can it be lxc container? (Have in mind sometimes I need to restart it) I have write with to Raptor Computing Systems about Parabola GNU/Linux-libre incomplete port. Andreas Grapentin writes: > On Sun, Nov 17, 2019 at 09:43:05AM +0100, Vikings GmbH wrote: >> On Sat, 16 Nov 2019 22:25:50 -0500 >> bill-auger wrote: >> >> > i dont think supporting older PPC CPUs is on the roadmap - >> > those would probably need to be separate ports; and the last >> > arch-like system (now defunct) was for PPC6 - there was a large >> > gap there that oaken-source and ebrasca had to leap over to get >> > to POWER9 >> > >> > the talos has dropped in price significantly recently though, >> > and it was just RYF-certified last week, so we really should do >> > our best to support it - i agree that one of us should probably >> > have access to one - as you pointed out, that may even be >> > necessary - in the worst case scenario, maybe we can entice >> > ebrasca to dedicate a piece of his for testing purposes, or for >> > building finicky packages >> >> I'd like to suggest to tell Raptor Computing Systems that you'd like >> to port Parabola GNU/Linux to PPC and make them aware of your plans; >> they usually support things like that strongly from what we've seen so >> far. They might even provide you with a machine that is either >> significantly reduced in price, free of charge or perhaps as a loaner. >> Vikings would be the last to not chime in with space and infrastructure >> to host such a machine with the potential outcome that Parabola will be >> ported. > > This would be an ideal outcome for us -- a Talos Server unit located in > your shared hosting space. Thanks for the suggestion, I will write a > mail to Raptor immediately to enquire about this. > > Thanks! > -A From bill-auger at peers.community Tue Nov 19 23:40:51 2019 From: bill-auger at peers.community (bill-auger) Date: Tue, 19 Nov 2019 18:40:51 -0500 Subject: [Dev] Let's talk about Infrastructure and Hosting In-Reply-To: <87imnfe9gt.fsf@librepanther.com> References: <20191105222836.GA86715@parabola-pocket.localdomain> <20191117002619.GA69197@parabola-pocket.localdomain> <20191116222550.4d70a795@parabola> <20191117094305.4bc600c3@balder.lan> <20191117160312.GA78989@parabola-pocket.localdomain> <87imnfe9gt.fsf@librepanther.com> Message-ID: <20191119184051.4aa4acab@parabola> good to see you ebrasca - this thread is actually a different topic than the POWER9 port - this one is about a getting a new public server to replace proton - most of the messages in this thread have been CC'ed to the admin at vikings.net the idea we had about POWER9 was more of as build box to complete the porting - thats not to say that the deal is settled or that we counld not use another public server; but they were different ideas, for different uses From ebrasca at librepanther.com Wed Nov 20 13:25:20 2019 From: ebrasca at librepanther.com (Bruno Cichon) Date: Wed, 20 Nov 2019 14:25:20 +0100 Subject: [Dev] Parabola lxc image Message-ID: <87y2wan0hr.fsf@librepanther.com> I have created lxc parabola image for ppc64le. From GNUtoo at cyberdimension.org Thu Nov 21 00:24:18 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Thu, 21 Nov 2019 01:24:18 +0100 Subject: [Dev] Parabola lxc image In-Reply-To: <87y2wan0hr.fsf@librepanther.com> References: <87y2wan0hr.fsf@librepanther.com> Message-ID: <20191121012418.454703cc@primarylaptop.localdomain> Hi, On Wed, 20 Nov 2019 14:25:20 +0100 Bruno Cichon wrote: > I have created lxc parabola image for ppc64le. Does mkinitcpio works ? What is still missing to boot Parabola on a ppc64le machine? Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ebrasca at librepanther.com Thu Nov 21 00:41:22 2019 From: ebrasca at librepanther.com (Bruno Cichon) Date: Thu, 21 Nov 2019 01:41:22 +0100 Subject: [Dev] Parabola lxc image In-Reply-To: <20191121012418.454703cc@primarylaptop.localdomain> (Denis Carikli's message of "Thu, 21 Nov 2019 01:24:18 +0100") References: <87y2wan0hr.fsf@librepanther.com> <20191121012418.454703cc@primarylaptop.localdomain> Message-ID: <87lfsanjrh.fsf@librepanther.com> I have run Parabola directly on TalosII some time ago. Denis 'GNUtoo' Carikli writes: > Hi, > > On Wed, 20 Nov 2019 14:25:20 +0100 > Bruno Cichon wrote: >> I have created lxc parabola image for ppc64le. > > Does mkinitcpio works ? > What is still missing to boot Parabola on a ppc64le machine? > > Denis. > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev From andreas at grapentin.org Thu Nov 21 07:54:04 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Thu, 21 Nov 2019 08:54:04 +0100 Subject: [Dev] Parabola lxc image In-Reply-To: <87lfsanjrh.fsf@librepanther.com> References: <87y2wan0hr.fsf@librepanther.com> <20191121012418.454703cc@primarylaptop.localdomain> <87lfsanjrh.fsf@librepanther.com> Message-ID: <20191121075404.GA138577@parabola-pocket.localdomain> The real cool news is that we can use that container to further work on the ppc64le port. This is a huge step and will allow us to really get going with this. So keep an eye open for updates :) -A On Thu, Nov 21, 2019 at 01:41:22AM +0100, Bruno Cichon wrote: > > I have run Parabola directly on TalosII some time ago. > > Denis 'GNUtoo' Carikli writes: > > > Hi, > > > > On Wed, 20 Nov 2019 14:25:20 +0100 > > Bruno Cichon wrote: > >> I have created lxc parabola image for ppc64le. > > > > Does mkinitcpio works ? > > What is still missing to boot Parabola on a ppc64le machine? > > > > Denis. > > > > _______________________________________________ > > Dev mailing list > > Dev at lists.parabola.nu > > https://lists.parabola.nu/mailman/listinfo/dev > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From GNUtoo at cyberdimension.org Thu Nov 21 13:04:49 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Thu, 21 Nov 2019 14:04:49 +0100 Subject: [Dev] Parabola lxc image In-Reply-To: <87lfsanjrh.fsf@librepanther.com> References: <87y2wan0hr.fsf@librepanther.com> <20191121012418.454703cc@primarylaptop.localdomain> <87lfsanjrh.fsf@librepanther.com> Message-ID: <20191121140449.70072218@primarylaptop.localdomain> On Thu, 21 Nov 2019 01:41:22 +0100 Bruno Cichon wrote: > I have run Parabola directly on TalosII some time ago. Is there a very high level installation procedure? Something like that would be enough for many advanced users: - ssh into the bmc (with a pointer to a wiki page explaining how to set that up) - get the serial console (there is a script for that, probably obmc-something) - put a debian netinstall on an usb stick - start the computer (there is also a script for that, probably obmc-util or something like that) - install debian - download a (prefferibly signed) Parabola tarball, verify the signature and extract it - chroot into it and use pacstrap to do the installation I've no idea if the above works as I've no Talos/Blackbird. But something like that should be enough to be able to at least get Parabola running to build package and prepare a rootfs that could be installed directly without using debian or other non-fsdg distros. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Thu Nov 21 19:00:53 2019 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 21 Nov 2019 19:00:53 -0000 Subject: [Dev] Orphan Libre package [openmw] marked out-of-date Message-ID: <20191121190053.1168.45463@winston.parabola.nu> nicodimonaco at protonmail.com wants to notify you that the following packages may be out-of-date: * openmw 0.45.0-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/openmw/ * openmw 0.45.0-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/openmw/ * openmw-debug 0.45.0-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/openmw-debug/ * openmw-debug 0.45.0-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/openmw-debug/ The user provided the following additional text: Greetings! Latest version on Arch repos is 0.45.0-4, I believe. Version 0.45.0-1 still depends on openscenegraph34, which makes it unresolvable and not possible to install. Thanks in advance. https://bugs.archlinux.org/task/64369 From freemor at freemor.ca Sat Nov 23 14:47:53 2019 From: freemor at freemor.ca (Freemor) Date: Sat, 23 Nov 2019 10:47:53 -0400 Subject: [Dev] The Theova Question Message-ID: <20191123144753.GA12079@freemor.ca> Sorry bout the subject.. It was just to 1950s/60s SF sounding to pass up. But to the matter at hand. Theova has been around for a fair while. Shows a strong interest in Parabola. Has filed excellent BRs and provided not only solid PKGBUILDs but then updates to those PKGBUILDS. He/she/they has demonstrated a considered and level approach to things and a willingness to take input from others. I think it may be time to consider giving Theova the bump to Parabola hackerdom. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Sat Nov 23 17:04:56 2019 From: bill-auger at peers.community (bill-auger) Date: Sat, 23 Nov 2019 12:04:56 -0500 Subject: [Dev] The Theova Question In-Reply-To: <20191123144753.GA12079@freemor.ca> References: <20191123144753.GA12079@freemor.ca> Message-ID: <20191123120456.53e07a5b@parabola> i had the same thought recently too - grizzlyuser has also been very helpful From theova at bluewin.ch Mon Nov 25 07:28:02 2019 From: theova at bluewin.ch (theova) Date: Mon, 25 Nov 2019 08:28:02 +0100 Subject: [Dev] The Theova Question In-Reply-To: <20191123120456.53e07a5b@parabola> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> Message-ID: <20191125072802.hraa5ap6guvymsks@RainbowWarrior.localdomain> Hi, I feel very glad that you discuss this. Indeed, I would be very motivated to become an "official Parabola Hacker". Nevertheless I will still have questions and will need your help. I also understand if I need to wait a little longer. bill-auger schrieb am Sat, 23. Nov 19 12:04: >i had the same thought recently too - grizzlyuser has also been >very helpful >_______________________________________________ >Dev mailing list >Dev at lists.parabola.nu >https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From theova at bluewin.ch Mon Nov 25 08:35:59 2019 From: theova at bluewin.ch (theova) Date: Mon, 25 Nov 2019 09:35:59 +0100 Subject: [Dev] [libre/qutebrowser] Update to v1.8.2 Message-ID: <20191125083559.gwvtwdh4idjc4hpa@RainbowWarrior.localdomain> The following patch upgrades qutebrowser to version 1.8.2. I tested it in x86_64 and built it successfully on armv7h. The built on i686 failed: File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in | from pyparsing import stringStart, stringEnd, originalTextFor, ParseException | ModuleNotFoundError: No module named 'pyparsing I guess this is due to syncronisation issues caused by python 3.8. Nevertheless, the architecture needed for this package is "any". --- libre/qutebrowser/PKGBUILD | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/libre/qutebrowser/PKGBUILD b/libre/qutebrowser/PKGBUILD index c12b4ef66..f405aee44 100644 --- a/libre/qutebrowser/PKGBUILD +++ b/libre/qutebrowser/PKGBUILD @@ -9,9 +9,9 @@ # - set webkit backend as default pkgname=qutebrowser -pkgver=1.8.1 +pkgver=1.8.2 pkgrel=1 -pkgrel+=.par2 +pkgrel+=.par1 pkgdesc="A keyboard-driven, vim-like browser based on PyQt5 and QtWebKit" pkgdesc+=", without nonfree qt5-webengine recommendation" arch=("any") @@ -31,7 +31,7 @@ source=("https://github.com/qutebrowser/qutebrowser/releases/download/v$pkgver/q "https://github.com/qutebrowser/qutebrowser/releases/download/v$pkgver/qutebrowser-$pkgver.tar.gz.asc" "webkit-warning.patch") validpgpkeys=("E04E560002401B8EF0E76F0A916EB0C8FD55A072") # Florian Bruhin -sha256sums=('dcf6eb63fc2430ac28ee40e2a236391adb7cdbe7debf4cbe53e0d12ff8726e32' +sha256sums=('baf01c47095428ca95ddd796598efd5419aee6b34c08ecdb98c12c796f6b5471' 'SKIP' '8509032254715a09d807ac5901657e66d0d0780e47bbe2b06f634d7b7c9792d0') @@ -47,8 +47,7 @@ build() { # make sure webkit is the default backend sed -i 's/webengine/webkit/' qutebrowser/config/configdata.yml - a2x -f manpage doc/qutebrowser.1.asciidoc - python setup.py build + make -f misc/Makefile all } package() { -- 2.24.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andreas at grapentin.org Mon Nov 25 09:31:52 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Mon, 25 Nov 2019 10:31:52 +0100 Subject: [Dev] The Theova Question In-Reply-To: <20191125072802.hraa5ap6guvymsks@RainbowWarrior.localdomain> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125072802.hraa5ap6guvymsks@RainbowWarrior.localdomain> Message-ID: <20191125093152.GA232884@parabola-pocket.localdomain> I'm always in favor of giving people fancy hats. If it were up to me, I'd say welcome to the team :) Best Andreas (oaken-source) On Mon, Nov 25, 2019 at 08:28:02AM +0100, theova wrote: > Hi, > > I feel very glad that you discuss this. > > Indeed, I would be very motivated to become an "official Parabola > Hacker". Nevertheless I will still have questions and will need your > help. > > I also understand if I need to wait a little longer. > > > bill-auger schrieb am Sat, 23. Nov 19 12:04: > > i had the same thought recently too - grizzlyuser has also been > > very helpful > > _______________________________________________ > > Dev mailing list > > Dev at lists.parabola.nu > > https://lists.parabola.nu/mailman/listinfo/dev > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From grizzlyuser at protonmail.com Mon Nov 25 11:55:11 2019 From: grizzlyuser at protonmail.com (grizzlyuser) Date: Mon, 25 Nov 2019 11:55:11 +0000 Subject: [Dev] The Theova Question In-Reply-To: <20191123120456.53e07a5b@parabola> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> Message-ID: On Saturday, November 23, 2019 7:04 PM, bill-auger wrote: > i had the same thought recently too - grizzlyuser has also been > very helpful It's very pleasant to see myself mentioned in this thread! Seing dedication of Parabola hackers to the project inspired me to do my small contributions. I'd be happy to be more involved. However I'm not sure if it'd be appropriate for me to package anything, because my laptop contains Intel Management Engine. It's not clear if there's any practical need for IME to mess with built binaries / packages. Although manufacturer (Dell) claims ME is disabled in my configuration, intelmetool utility says otherwise, and I haven't yet taken the risk of bricking my only computer by using me_cleaner to neutralize IME. From andreas at grapentin.org Mon Nov 25 12:10:59 2019 From: andreas at grapentin.org (Andreas Grapentin) Date: Mon, 25 Nov 2019 13:10:59 +0100 Subject: [Dev] The Theova Question In-Reply-To: References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> Message-ID: <20191125121059.GA237774@parabola-pocket.localdomain> If you don't trust your machine to build release packages, that's fine. It quite clearly doesn't prohibit you from contributing like you have already been doing, by providing patches and updates, which are then built on other machines. The change would just mean you provide these patches in a more official position as a member of the team, and we can mark your contributions as such by having you be the one to commit them to the repository, and/or signing off the commits. -A On Mon, Nov 25, 2019 at 11:55:11AM +0000, grizzlyuser wrote: > On Saturday, November 23, 2019 7:04 PM, bill-auger > wrote: > > > i had the same thought recently too - grizzlyuser has also been > > very helpful > > It's very pleasant to see myself mentioned in this thread! Seing > dedication of Parabola hackers to the project inspired me to do > my small contributions. I'd be happy to be more involved. > > However I'm not sure if it'd be appropriate for me to package > anything, because my laptop contains Intel Management Engine. > It's not clear if there's any practical need for IME to mess > with built binaries / packages. Although manufacturer (Dell) > claims ME is disabled in my configuration, intelmetool utility > says otherwise, and I haven't yet taken the risk of bricking my > only computer by using me_cleaner to neutralize IME. > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From freemor at freemor.ca Mon Nov 25 12:21:06 2019 From: freemor at freemor.ca (Freemor) Date: Mon, 25 Nov 2019 08:21:06 -0400 Subject: [Dev] The Theova Question In-Reply-To: References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> Message-ID: <20191125122106.GB12079@freemor.ca> On Mon, Nov 25, 2019 at 11:55:11AM +0000, grizzlyuser wrote: > On Saturday, November 23, 2019 7:04 PM, bill-auger > wrote: > > > i had the same thought recently too - grizzlyuser has also been > > very helpful > > It's very pleasant to see myself mentioned in this thread! Seing > dedication of Parabola hackers to the project inspired me to do > my small contributions. I'd be happy to be more involved. > > However I'm not sure if it'd be appropriate for me to package > anything, because my laptop contains Intel Management Engine. > It's not clear if there's any practical need for IME to mess > with built binaries / packages. Although manufacturer (Dell) > claims ME is disabled in my configuration, intelmetool utility > says otherwise, and I haven't yet taken the risk of bricking my > only computer by using me_cleaner to neutralize IME. The IME is a local concern and not a remote one. Someone would have to be on your local network segment to Futz with the machine and that is only if you are using one of the "blessed" NICs (like the built in Ethernet or wifi). We also have a build host "Beefcake" that you could build things on if you are still worried. A lot has been made of the IME because of its ring -3 ness But any maliciousness is theoretical at best (bugginess has been proven. But no one has found code that would do thing all on its own). And as I said above to use it as a backdoor someone has to directly access the machine or be on the same network segment (LAN) while you are using one of the Blessed NICs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From freemor at freemor.ca Mon Nov 25 13:14:22 2019 From: freemor at freemor.ca (Freemor) Date: Mon, 25 Nov 2019 09:14:22 -0400 Subject: [Dev] The Theova Question In-Reply-To: <20191125093152.GA232884@parabola-pocket.localdomain> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125072802.hraa5ap6guvymsks@RainbowWarrior.localdomain> <20191125093152.GA232884@parabola-pocket.localdomain> Message-ID: <20191125131422.GC12079@freemor.ca> On Mon, Nov 25, 2019 at 10:31:52AM +0100, Andreas Grapentin wrote: > > I'm always in favor of giving people fancy hats. > > If it were up to me, I'd say welcome to the team :) > > Best > Andreas (oaken-source) > Well With Us 3 devs on board I'd say give this another day or 2 and if no one objects we promote both of them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Mon Nov 25 22:40:42 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 25 Nov 2019 17:40:42 -0500 Subject: [Dev] [libre/qutebrowser] Update to v1.8.2 In-Reply-To: <20191125083559.gwvtwdh4idjc4hpa@RainbowWarrior.localdomain> References: <20191125083559.gwvtwdh4idjc4hpa@RainbowWarrior.localdomain> Message-ID: <20191125174042.05affe1d@parabola> On Mon, 25 Nov 2019 09:35:59 +0100 theova wrote: > I guess this is due to syncronisation issues caused by python > 3.8. > Nevertheless, the architecture needed for this package is > "any". to build this on i686 today, you would probably need to enable the [testing] repo, where python 3.8 is 'any' arch packages can be troublesome in that way, because all of the parabola ports do not always roll at the same speed - to put this package in [libre] today as an 'any' package, would presumably make it broken on i686 systems for that reason, troublesome ones are built separately for each arch. although ideally, they would be built for 'any' so i have modified the 'qutebrowser' package in that way, and pinned its 'python' dependency to the current version per arch - v1.8.2 is on [libre] now for x86_64 and armv7h - i686 will need to wait until python 3.8 is released from [testing] From bill-auger at peers.community Tue Nov 26 01:13:56 2019 From: bill-auger at peers.community (bill-auger) Date: Mon, 25 Nov 2019 20:13:56 -0500 Subject: [Dev] The Theova Question In-Reply-To: <20191125122106.GB12079@freemor.ca> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125122106.GB12079@freemor.ca> Message-ID: <20191125201356.0e03f5f6@parabola> i just wanted to point out that neither building packages, nor having any prior coding/compiling experience are essential; though regarding any software project, people generally do have the opposite impression and are reluctant to get involved though this may not be true for every free software project; one of the main goals of parabola, beyond merely providing a fully-libre operating system, is to teach people how to exercise control of their own computing, by making practical use of software freedom - although that is the consensus opinion of the parabola devs (and based on discussions i have had with some of the most senior team members such as aurelien, that has always been so), it is not actually expressed anywhere formally - ive suggested revising the "social contract" into more of a conventional "mission statement", rather than a list of promises - in that form, it could be amended to include "advancing computer literacy" as a stated goal it would be quite alright for someone with little or no special experience to join the team - we would be more than happy to teach the specific skills that one would need to move onto more advanced tasks - one could start off with bug triaging for example, and most of the skills necessary for maintaining packages and documentation, would be acquired in time, as a matter of course even for someone who was not interested in coding at all, there are several ways that one could be considered as a full member of the team, that would not require any programming or sysadmin skills - the most important factor justifying the formal induction procedure, would be the demonstration of one's long-term dedication to the project, rather than a fleeting interest, which is often seen it is merely coincidental that in the past, parabola devs have been inducted on the merits of their prior technical contributions - it is a marvelous testament to the relatively high skill-level of the parabola team as a whole, that we can do so much with so few hands; but that necessarily leaves some important, albeit less technically demanding tasks unattended, such as documentation, aesthetics/UX, and triaging bugs on the lesser-used DEs theova, for example, started by updating out-dated wiki articles - that is a valuable contribution on it's own - one could join the parabola team if only for the dedication to maintaining the wiki; or any other special tasks such as artwork, or community relations such as moderating the forum, publishing news releases, and fielding/mediating questions from reddit and the fediverse - it is in practice, more fruitful to have non-technical people attending to those tasks - the most technically-skilled people generally approach those tasks from too high of an abstraction level, which is actually sub-optimal From GNUtoo at cyberdimension.org Tue Nov 26 08:15:47 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 26 Nov 2019 09:15:47 +0100 Subject: [Dev] Management Engine, Was: The Theova Question In-Reply-To: <20191125122106.GB12079@freemor.ca> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125122106.GB12079@freemor.ca> Message-ID: <20191126091547.086ee1af@primarylaptop.localdomain> On Mon, 25 Nov 2019 08:21:06 -0400 Freemor wrote: > The IME is a local concern and not a remote one. Someone would have > to be on your local network segment to Futz with the machine and that > is only if you are using one of the "blessed" NICs (like the built in > Ethernet or wifi). [...] > And as I said above to use it as a backdoor someone has to directly > access the machine or be on the same network segment (LAN) while you > are using one of the Blessed NICs That depends on several things: - AMT is typically found on computers for business but not on computers for consumers. The downside of laptops for consumers is that the display is often glossy, which is not fit for spending too much hours in front of it[1]. So many people doing work (including free software work) with computers end up with it. - AMT enables to remotely administrate a computer with VNC and through the Internet[2]. - To work it needs an Internet connection on one of the compatible interfaces such as: - The built-in Intel Ethernet interface - The built-in Intel WiFi card - A compatible cellular network modem[2]. So it would be a good idea to check: - if the computer is a laptop that has already been configured by a company's sysadmin. That may occur too if the laptop has been bought second hand. - if the laptop has a SIM card and/or a cellular network modem. > A lot has been made of the IME because of its ring -3 ness But any > maliciousness is theoretical at best (bugginess has been proven. But > no one has found code that would do thing all on its own). Beside the fact that it's designed to remove users control over their computers, which is enough to be a very serious attack on users freedom, I think we should rather shift the narrative on things like that: Weather it does or does not have a backdoor is not very irrelevant. Instead as part of the free software community, we should require from the manufacturers and/or software projects like Libreboot or Replicant that are dealing with things like that some serious proof or indication that it cannot attack users or does not have any backdoors: - In the case of Libreboot computers with an Intel GM45 chipset, the Management engine OS has been completely erased[3]. So while it's not perfect, as it has a ROM[3] you still have a way bigger assurance than if there was an OS running in it. In contrast, Intel cannot give us any proof to us that the Management Engine OS has no backdoor: We cannot review the source code and run the version we reviewed. - All the smartphones and tablets currently supported by Replicant have either a modem that is isolated, or no modem. Again here it's not perfect as the bootloader is nonfree on all currently supported devices, but we get way better assurances as for instance the microphone is controlled by free software, whereas in some older smartphones like the HTC Dream, the microphone was controlled by nonfree software. References: ----------- [1]https://en.wikipedia.org/wiki/Glossy_display#Adverse_health_effects [2]https://www.intel.com/content/dam/doc/white-paper/digital-signage-vpro-amt-3g-paper.pdf [3]The Management Engine OS is located on the same flash chip(s) that stores the BIOS/EFI/UEFI. That flash chip has several partitions, and the Management Engine OS is on one of its partitions. The Management Engine has a rom which loads that OS from its flash partition. With Libreboot on computers with the GM45 chipset, the flash partition table is configured to tell the Management Engine that there is no OS to load, and that's sufficient to have a functional computer. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From GNUtoo at cyberdimension.org Tue Nov 26 08:28:48 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 26 Nov 2019 09:28:48 +0100 Subject: [Dev] The Theova Question In-Reply-To: <20191125201356.0e03f5f6@parabola> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125122106.GB12079@freemor.ca> <20191125201356.0e03f5f6@parabola> Message-ID: <20191126092848.7203d511@primarylaptop.localdomain> On Mon, 25 Nov 2019 20:13:56 -0500 bill-auger wrote: > i just wanted to point out that neither building packages, nor > having any prior coding/compiling experience are essential; > though regarding any software project, people generally do have > the opposite impression and are reluctant to get involved I also wanted to point out that it's also possible to help with packaging without knowing the programming languages used in the software you are packaging. Knowing such programming languages is required to fix bugs inside the software being packaged, or to port forward some of the patches made by the distribution, however people doing packages does not always need to do that in the software they try to package. In that case it's best to either try to get some help or try to package another software. This is not uncommon: in most free and open source projects, many contributors are not able to do everything, to fix every bug, or to understand all the source code. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From freemor at freemor.ca Tue Nov 26 12:29:29 2019 From: freemor at freemor.ca (Freemor) Date: Tue, 26 Nov 2019 08:29:29 -0400 Subject: [Dev] Management Engine, Was: The Theova Question In-Reply-To: <20191126091547.086ee1af@primarylaptop.localdomain> References: <20191123144753.GA12079@freemor.ca> <20191123120456.53e07a5b@parabola> <20191125122106.GB12079@freemor.ca> <20191126091547.086ee1af@primarylaptop.localdomain> Message-ID: <20191126122929.GD12079@freemor.ca> On Tue, Nov 26, 2019 at 09:15:47AM +0100, Denis 'GNUtoo' Carikli wrote: > On Mon, 25 Nov 2019 08:21:06 -0400 > Freemor wrote: [Snip] > That depends on several things: > - AMT is typically found on computers for business but not on computers > for consumers. The downside of laptops for consumers is that the > display is often glossy, which is not fit for spending too much > hours in front of it[1]. So many people doing work (including free > software work) with computers end up with it. > - AMT enables to remotely administrate a computer with VNC and through > the Internet[2]. > - To work it needs an Internet connection on one of the compatible > interfaces such as: > - The built-in Intel Ethernet interface > - The built-in Intel WiFi card > - A compatible cellular network modem[2]. You're right I forgot about the cellular modem. But again removing the blessed wifi card and cell modem (if not built into the Wifi card) mitigates that issue. > > So it would be a good idea to check: > - if the computer is a laptop that has already been configured by a > company's sysadmin. That may occur too if the laptop has been bought > second hand. > - if the laptop has a SIM card and/or a cellular network modem. Yes the second hand thing is an issue as in that case the AMT may be fully provisioned. > > > A lot has been made of the IME because of its ring -3 ness But any > > maliciousness is theoretical at best (bugginess has been proven. But > > no one has found code that would do thing all on its own). > Beside the fact that it's designed to remove users control over their > computers, which is enough to be a very serious attack on users > freedom, I think we should rather shift the narrative on things like > that: Weather it does or does not have a backdoor is not very > irrelevant. > > Instead as part of the free software community, we should require from > the manufacturers and/or software projects like Libreboot or Replicant > that are dealing with things like that some serious proof or indication > that it cannot attack users or does not have any backdoors: > - In the case of Libreboot computers with an Intel GM45 chipset, the > Management engine OS has been completely erased[3]. So while it's not > perfect, as it has a ROM[3] you still have a way bigger assurance than > if there was an OS running in it. > In contrast, Intel cannot give us any proof to us that the Management > Engine OS has no backdoor: We cannot review the source code and run > the version we reviewed. > - All the smartphones and tablets currently supported by Replicant have > either a modem that is isolated, or no modem. Again here it's not > perfect as the bootloader is nonfree on all currently supported > devices, but we get way better assurances as for instance the > microphone is controlled by free software, whereas in some older > smartphones like the HTC Dream, the microphone was controlled by > nonfree software. Completely agree. I wasn't trying to say "Pffff.. IME is fine, who cares". I'm Just trying to keep things in the proper perspective. I think that due to some bad coverage same people may be more freaked about about the IME then is really necessary. But yes. This crap should not be included in every machine. At best it should be an add on module that Corporations can have added in if they wanted and second hand users could then remove if they didn't. As for "smart" phones and Tablets I've completely given up on those for the foreseeable future as they are just a wasteland of non-free and non-freeable crap. (not to mention way way over priced for the hardware you're actually getting, non-serviceable, non-replaceable batteries, etc.) People really need to stop buying that crap so them makers of it get the message But getting people interested in things like a nice EOMA board is not an easy sell. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nobody at parabola.nu Tue Nov 26 19:06:02 2019 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 26 Nov 2019 19:06:02 -0000 Subject: [Dev] Orphan Libre package [blender] marked out-of-date Message-ID: <20191126190602.1165.52077@winston.parabola.nu> a.reviewer1234 at yahoo.com wants to notify you that the following packages may be out-of-date: * blender 17:2.80-7.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/blender/ The user provided the following additional text: Blender 2.81 has been recently released. I would like to help out with packaging Blender in future. I should do some research, but is the non-free CUDA (and now OptiX) support easily removed; is it in a single directory, or a specified part of some other directories? If not, should we ask the Blender devs to segregate the non-free support into a single, specified directory? That comment alone probably drove some Blender devs crazy. :) Please feel free to email me. Thanks. From anarcobuda at disroot.org Tue Nov 26 21:06:08 2019 From: anarcobuda at disroot.org (anarcobuda) Date: Tue, 26 Nov 2019 18:06:08 -0300 Subject: [Dev] ParabolaWiki installation guide Message-ID: <4767f4739e256d1c155d817b99c97d0efd2066e7.camel@disroot.org> i've been doing some work on our wiki, mainly the installation guide, to improve readability and to update some information we ascribe to the 'arch way', since we use basically an arch-based system, and there's no reason why our installation guide should be different than the archwiki's one. however, we also openly provide an openrc version of parabola, and that means we can't pragmatically copy and paste archwiki's installation guide, since it'd be only useful for systemd users. in that sense, i'm asking for opinions on how to organize this and i came up with two possibilities so far 1. do a step-by-step guide for openrc and another for systemd this would mean there would be a main page for pre-installation and two pages for installation, one for openrc and another for systemd. this seems to be the easiest to do, since it only requires two extra pages 2. do a step-by-step guide for both, in one page with the help of links this would mean one page that would branch out on other pages for instance, a page section that says "configure your network" and it'd link to another page that details how to configure your network for openrc and systemd in different sections this seems more work-consuming, but it'd be neater what do you think? From GNUtoo at cyberdimension.org Tue Nov 26 21:23:37 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 26 Nov 2019 22:23:37 +0100 Subject: [Dev] ParabolaWiki installation guide In-Reply-To: <4767f4739e256d1c155d817b99c97d0efd2066e7.camel@disroot.org> References: <4767f4739e256d1c155d817b99c97d0efd2066e7.camel@disroot.org> Message-ID: <20191126222337.02eefdbf@primarylaptop.localdomain> On Tue, 26 Nov 2019 18:06:08 -0300 anarcobuda wrote: > i've been doing some work on our wiki, mainly the installation guide, > to improve readability and to update some information > > we ascribe to the 'arch way', since we use basically an arch-based > system, and there's no reason why our installation guide should be > different than the archwiki's one. Here some of the differences I saw: - On ARM we don't provide device specific installation procedure. Instead the installation procedure is more generic. - I'm unsure if Arch also has graphical installation. > 1. do a step-by-step guide for openrc and another for systemd > this would mean there would be a main page for pre-installation and > two pages for installation, one for openrc and another for systemd. > this seems to be the easiest to do, since it only requires two extra > pages This requires more maintenance but it's probably easier for users. > 2. do a step-by-step guide for both, in one page with the help of > links this would mean one page that would branch out on other pages > for instance, a page section that says "configure your network" and > it'd link to another page that details how to configure your network > for openrc and systemd in different sections > this seems more work-consuming, but it'd be neater This requires less maintenance but is a bit harder for users. Personally I've been working in Replicant to switch from the first option to the second one as one page per device was too much. I didn't find any ideal solution yet, as better technical solutions do exist, such as generating a page specific to the user use case without repeating the content, but that typically makes it harder for users to contribute to the instructions. Though it can produce better quality instructions if people send patches to be reviewed on a mailing list. It's probably also possible to do it in Mediawiki through templates but again that also makes it harder to contribute to the wiki. So the solution probably depends on who wants to contribute and if contributors can manage to maintain 2 or more versions of the same text. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Wed Nov 27 04:29:00 2019 From: bill-auger at peers.community (bill-auger) Date: Tue, 26 Nov 2019 23:29:00 -0500 Subject: [Dev] ParabolaWiki installation guide In-Reply-To: <20191126222337.02eefdbf@primarylaptop.localdomain> References: <4767f4739e256d1c155d817b99c97d0efd2066e7.camel@disroot.org> <20191126222337.02eefdbf@primarylaptop.localdomain> Message-ID: <20191126232900.437af826@parabola> all i can say for certain about the install guide now, it that it is in a state of flux because if the new 'base' meta-package there are actually tree different install guides now - that alone is confusing - we have not discussed it much; bit the tendency seems to be toward one unified page and deleting the other two - the main install guide now is essentially complete for either systemd or openrc - that was not so just a few months ago - for openrc, one needed to jump around between two articles and important steps were often missed as it is now, i dont think its too confusing - 95% of the procedure is the same for either - there are only 2 (?) sub-sections that differ depending on the initsystem - plus, the latest goal is to normalize the base install process; by moving all packages that are related to openrc into the [nonsystemd] repo exclusively, all with identical names to their systemd analogs - in that way, the install procedure would be even more similar much of the confusion now is due to the package names and conflicts with providers of elogind, libsystemd and other init-specific essentials - for example, ideally one would only need to enable [nonsystemd] and pacman -Syyuu to migrate from systemd to openrc; or disable [nonsystemd] and pacman -Syyuu to migrate from openrc to systemd From freemor at freemor.ca Wed Nov 27 16:27:46 2019 From: freemor at freemor.ca (Freemor) Date: Wed, 27 Nov 2019 12:27:46 -0400 Subject: [Dev] providing libre sources without breaking the server (maybe) Message-ID: <20191127162746.GH12079@freemor.ca> Some arguments have been provided to me that provide more clarity on the cleaned source question. I'm now feeling like this is a required (By the GPL) thing. Two options come to mind. Hacking pacman/libretools to roll the source tarball after prepare(). Thus providing Cleaned sources. or As source under the GPL can be provided upon request. Some server side automation that would run makepkg -o on any pakcages pushed to abslibre and roll the src dir into a tarball (cleaned source) which it makes available on the Parabola.nu web server. Of course Trimming old sources so we aren't trying to store 40 years of sources. Option 2 would save build time. Provide cleaned sources and dodge the question of distributing the liberation PKGBUILDs as part of the source. Nothing would be hidden. PKGBUILDs would live in abslibre as they do now but there'd be a directory of clean source tarballs on the server. Beefcake could probably do the Makepkg -o 'ing and rolling and then rsync the sources into place. Probably signing then with an autobuilder type key. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From freemor at freemor.ca Wed Nov 27 16:39:00 2019 From: freemor at freemor.ca (Freemor) Date: Wed, 27 Nov 2019 12:39:00 -0400 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191127162746.GH12079@freemor.ca> References: <20191127162746.GH12079@freemor.ca> Message-ID: <20191127163900.GI12079@freemor.ca> On Wed, Nov 27, 2019 at 12:27:46PM -0400, Freemor wrote: > Option 2 would save build time. Provide cleaned sources and dodge the question > of distributing the liberation PKGBUILDs as part of the source. > > Nothing would be hidden. PKGBUILDs would live in abslibre as they do now but > there'd be a directory of clean source tarballs on the server. Beefcake could > probably do the Makepkg -o 'ing and rolling and then rsync the sources > into place. Probably signing then with an autobuilder type key. Just realized that option 2 has the problem of not including any of the special instructions in Build() so there would need to be some way to include that info. Question is how to do that without making life overly complicated. (a.k.a convoluted PKGBUILDs that try to do both. Perhaps the automation could export build() to a parabola_Install.txt Hmmm... (and apologies to posting to my own post) Ps I'll see if I can hack up a sensible clean source roller over the next couple of days. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From freemor at freemor.ca Wed Nov 27 20:03:07 2019 From: freemor at freemor.ca (Freemor) Date: Wed, 27 Nov 2019 16:03:07 -0400 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191127163900.GI12079@freemor.ca> References: <20191127162746.GH12079@freemor.ca> <20191127163900.GI12079@freemor.ca> Message-ID: <20191127200307.GK12079@freemor.ca> Committed initial work on the script under ssh://git at git.parabola.nu:1863/~git/~freemor/tools.git as clean_source_export Feel free to pull, examine, tweak, etc. Planned next step is to look at hos bill is spotting pushes for pbot and use that to make it autofire on the needed directories. Locally on my machine first. Then if all goes well on the server. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Thu Nov 28 17:38:19 2019 From: bill-auger at peers.community (bill-auger) Date: Thu, 28 Nov 2019 12:38:19 -0500 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191127200307.GK12079@freemor.ca> References: <20191127162746.GH12079@freemor.ca> <20191127163900.GI12079@freemor.ca> <20191127200307.GK12079@freemor.ca> Message-ID: <20191128123819.24421830@parabola> the thing is, IIRC we concluded that the mksource() function (probably) already accomplishes everything youve described, except that it is not working as intended, and was not used for every libre package - publishing pre-cleaned source-balls may satisfy the GPL; but they would be incompatible with makepkg, because most libre PKGBUILDs expect to download and patch the upstream sources i dont think we can avoid either modifying makepkg, or modifying every libre PKGBUILD, or fixing mksource(), or some combination of those - otherwise, makepkg could not make use those source-balls because the prepare() function would be prone to fail patching the pre-patched sources - mksource() seems to be the chosen solution because it avoids modifying makepkg, and the code is already in place, but apparently broken somehow the path of least resistance is probably just to study exactly how mksource() was intended to work, and fix it - then, over time, ensure that every libre package has a mksource() still, the standard makepkg would not recognize mksource(); but that probably was the intention From bill-auger at peers.community Thu Nov 28 18:12:27 2019 From: bill-auger at peers.community (bill-auger) Date: Thu, 28 Nov 2019 13:12:27 -0500 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191128123819.24421830@parabola> References: <20191127162746.GH12079@freemor.ca> <20191127163900.GI12079@freemor.ca> <20191127200307.GK12079@freemor.ca> <20191128123819.24421830@parabola> Message-ID: <20191128131227.34ccd258@parabola> and there are other good reasons to figure out how mksource() works firstly, it is sitting there now doing nothing but being confsing, and if it is not used, it should be deleted, which would require studying it anyways to make sure removing it doesnt break anything but more importantly, libremakepkg creates a source-ball for every package and librerelease uploads it to the server some of those source-balls are >500MB because they include the VCS history those source-balls are currently not used for anything, which is nothing but wasted time, bandwidth, and disk space- having git re-make them upon pushes to abslibre would not change that - it would make them completely redundant though, using even more disk space From freemor at freemor.ca Thu Nov 28 19:38:07 2019 From: freemor at freemor.ca (Freemor) Date: Thu, 28 Nov 2019 15:38:07 -0400 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191128131227.34ccd258@parabola> References: <20191127162746.GH12079@freemor.ca> <20191127163900.GI12079@freemor.ca> <20191127200307.GK12079@freemor.ca> <20191128123819.24421830@parabola> <20191128131227.34ccd258@parabola> Message-ID: <20191128193806.GM12079@freemor.ca> On Thu, Nov 28, 2019 at 01:12:27PM -0500, bill-auger wrote: > and there are other good reasons to figure out how mksource() > works > > firstly, it is sitting there now doing nothing but being > confsing, and if it is not used, it should be deleted, which > would require studying it anyways to make sure removing it > doesnt break anything > > but more importantly, libremakepkg creates a source-ball for > every package and librerelease uploads it to the server > some of those source-balls are >500MB because they include the > VCS history > > those source-balls are currently not used for anything, which > is nothing but wasted time, bandwidth, and disk space- having > git re-make them upon pushes to abslibre would not change that - > it would make them completely redundant though, using even more > disk space My hope with my little experiment is to hopefully: 1. Have a path for taking the nonstandard stuff out of the PKGBUILDS 2. Stop rolling source at build time. 3. Have the script smart enough to only roll sources that we change (as that is required by the GPL) There are a lot of packages where we just toggle a build option or two i.e. to disable geolocation or some other anti feature or unwanted protocol. as we do not alter those sources we (IIUC) don't need to publish the soucre, upstream will do. This could save us a fair bit of space/bandwidth. 4. Have the script smart enough to only roll a new tarball if the source or patches actually change i.e. don't reroll just because we rebuilt against a new poppler or ICU. 5. Provide non-PKGBUILD build instructions. So someone that downloads the source can build it manually without the PKGBUILD. This skips that source tarball having any nasty reference to unclean upstream stuff. The reality is that on an Archlinux like system 90% of people are gong to go right to the PKGBUILDs. I see no problem with that. The GPL compels us to provide the modified source for binaries we distribute (Hmm.. If this is not a requirement of the FSDGs then perhaps the script could also only roll GPL licensed things. Or GPL + other licenses with similar clauses) But back to what I was saying. Due at least to the GPL we need to provide the modified sources (even though almost no-one will look at it) So I'm looking to satisfy that requirement. In a way that lets our PKGBUILDs and build tools be as close to Upstream as possible in their syntax and functioning. (Yes, I know that doesn't really apply to libretools) but I'll assume that you get my meaning. I'm certainly open to taking another look at the mksource() thing. But since that currently rolls before prepare it is not in compliance with the "providing the modified source" thing. So, basically I want to streamline and standardize the build side. Reduce the # of source packages we host/roll to the required minimum (again since 90% of people are just gonna use the PKGUILDS). And have it "just work" in the sense that there are no extra steps which a maintainer might miss or stumble over. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From freemor at freemor.ca Fri Nov 29 02:25:35 2019 From: freemor at freemor.ca (Freemor) Date: Thu, 28 Nov 2019 22:25:35 -0400 Subject: [Dev] providing libre sources without breaking the server (maybe) In-Reply-To: <20191128193806.GM12079@freemor.ca> References: <20191127162746.GH12079@freemor.ca> <20191127163900.GI12079@freemor.ca> <20191127200307.GK12079@freemor.ca> <20191128123819.24421830@parabola> <20191128131227.34ccd258@parabola> <20191128193806.GM12079@freemor.ca> Message-ID: <20191129022535.GN12079@freemor.ca> Since the mksource() isn't quite functioning as it should perhaps I'm not fully up to speed. how many of the above (previous post) points would it hit if functioning as intended? No sense re-inventing the wheel if the one we got just needs the dust blown off. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: