Re: [Dev] New tier 1 mirror server The Netherlands
Hello again, I'm afraid I won't be able to add your mirror myself, but that doesn't mean it won't be added eventually. Some of the newer devs want to perform some more in-depth checks before adding new mirrors, so be patient. Regards -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C Jami: isacdaavid2 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] New tier 1 mirror server The Netherlands
Hi, You wrote to the right list and mirrors are very much welcome all the time. Thanks for setting another one up. I will let it hang out with the rest of the mirror kids in brief... Stay tuned. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C Jami: isacdaavid2___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] outdated repos
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?
>
> REPOLAST UPDATED
>
> alarm 2018-10-08
> cross 2012-01-23
> gnome-unstable 2014-10-03
> java2017-02-14
> kde-unstable2014-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
signature.asc
Description: This is a digitally signed message part
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Bad Cheese
Brett Gilio a écrit : Is there any way we can make gnome-control-center /not/ depend on cheese? How many of us actually use that dreaded application on a regular basis? this is a technical question for upstream. parabola does not repackage gnome-control-center (there are no FSDG issues with it AFAIK). my guess is that cheese is depended upon by the user accounts module (taking photos and adding them to user profiles). greetings. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] submitting my SSH key
Brett Gilio wrote : Would this be an appropriate time to refresh my keyring, then? Or should I wait? every time is the right time for refreshing the keyring. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Unblacklisted Mesa
I disagree, I don't believe the collection of workarounds in /etc/drirc to be a freedom problem. It isn't *trying* to load them (like Linux might with non-free blobs). The user won't be confused in to thinking something is wrong if the non-free thing isn't installed. My shamelessly detached ass will just chime in to say, the lesser the burden on you, the better. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [PATCH] libretools: fix i686 gpg signature failures
Luke Shumaker wrote : Two questions: 1. If there's an arch=(any) package that exists in ALARM and in archlinux32, but not in archlinux, do we import it? yes, all else being equal (i.e. no blacklisting). (Do any such packages exist?) idk. 2. If yes, which one wins? i686 or ARM? the one to come first. all 4 keyrings are required by all 3 pacmans in any case. i don't know whether both could make it to our package cache under the adequate concurrency conditions. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [PATCH] libretools: fix i686 gpg signature failures
Luke Shumaker wrote: On Tue, 20 Mar 2018 16:51:49 -0400, Andreas Grapentin wrote: archlinux32 is building their own arch=(any) packages, which means they can't share the same cachedir as the x86_64 built -any packages. This patch adds a separate cachedir for each CARCH in librechroot, which should solve the signature issues we have seen in libremakepkg. But we don't import arch=(any) packages from archlinux32 anymore, do we? Actually, I don't think we import arch=(any) packages from ALARM anymore either. right, unless it's an original package. more precisely, Arch's arch=(any) packages may override existing ALARM or Arch32 pkgnames -- they are given priority and all architectures are meant to use archlinux-keyring. i don't expect this scenario to surface often in practice, since both ALARM and Arch32 follow Arch, not the other way around. on the other hand, ALARM and Arch32's arch=(any) packages aren't allowed to override Arch's arch=(any) stuff, nor each other's. this is the relevant code: https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n124 https://git.parabola.nu/packages/dbscripts.git/tree/db-import-pkg?id=78fd5a0ca15cedc369ffd6c8035fd573ca253d76#n304 -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
[Dev] Test
this is a mailman test. ignore this message -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] GNU Cash broken and gone from repositories?
bill-auger wrote : i am still confused - what exactly are you suggesting that parabola should do? you say that the version you want is 2.4.x but archlinux has stopped packaging it. Bill, i think you misread his comment. it didn't sound like a suggestion or request to me. rather, he was explaining why GNU Cash disappeared from Arch in the first place. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] problems with replacements for blacklisted packages
Megver83 wrote : let's say we blacklist linux and linux-docs/linux-headers are automatically blacklisted. All right up to there, but where do we specify that linux-headers' replacement is linux-libre-headers? (same for -docs) in the PKGBUILD, as is currently done. the idea is to get rid of replacement info in blacklist.txt, and allow your-freedom to query the repos to know what it should and shouldn't conflict with. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] problems with replacements for blacklisted packages
Luke Shumaker wrote : I wrote a little pyalpm script for finding blacklist replacements (as in the second column in blacklist.txt). cool. i'm eager to compare it against the one i wrote for libreblacklist using expac.[1][] i'm hoping that we will move forward with the idea sketched in [2][]. from your observations it seems that yours is doing more than just finding replacements, like delving into pkgbase and splits, and checking for accompanying provides=(). I'll be polishing it up and committing it soon, but it did identify a few problems/concerns. - unrar is replaced by both libre/unar and pcr/gna-unrar. libre/unar should drop the replaces=(unrar) line, and pcr/gna-unrar should be moved to libre. you packaged pcr/gna-unrar :) - tensorflow has several other versions that are not blacklisted: tensorflow-opt and tensorflow-opt-cuda. I think that this is an argument toward prioritizing switching to pkgbase-based blacklisting. sounds practical from a your-freedom perspective, but it will require that dbscripts learns how to expand pkgbase for a given Arch package, or something like that. i'm thinking of the import script specifically: there's one entry per pkgname in the databases, and pkgbase only exists as metadata IIRC. keeping the specificity might be more practical in the end. - b43-fwcutter is not replaced by, but is provided by libre/b43-tools. For one, I am flabbergasted that whatever freedom issues b43-fwcutter has aren't also issues with b43-tools. Secondly, b43-tools should probably replaces=(b43-fwcutter), or be renamed to b43-fwcutter. i'm scratching my head over this too. their respective PKGBUILDs aren't like each other, but where does b43-tools even come from? it's not in the AUR. [1]: https://git.parabola.nu/packages/libretools.git/commit/?h=isacdaavid&id=313d1ee619363eca0b8b0742a2d58c9ce18877fd [2]: https://lists.parabola.nu/pipermail/dev/2017-October/005936.html -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Repo mirror
bill-auger wrote : > it should be said though, as i have noted elsewhere, that in most > typical cases the parabola mirrors never get hit well, that assumes most users never change the default setting. > if the redirector is the first mirror to try it directs to arch > servers and the speed is very slow (by todays standards) - for me > typically about 200kb/s should i read that as kilobits...?, because i'm getting several tens of times that speed, although i must admit i normally use my own, mirror for obvious testing reasons. > do the parabola mirrors carry all of the upstream packages also? yes, unless excluded by mirror owners. > perhaps it is time to stop redirecting to arch or have 2 redirectors - > a new high priority one that redirects only to parabola mirrors and > the existing redirector moved down to a lower priority i think the whole point of going with that order was to offload repo.parabola.nu first of all, but also our mirrors, which aren't that numerous. i like the idea of leveraging Arch. if speed is the concern then we can think of going with faster ones (shouldn't be too hard to change). surely there must be many. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Repo mirror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message jeweet wrote : > Hi guys, > > I have a mirror up and running on https://jeweet.net/repo/parabola. that's some sleek mirror! i'm also a bit shocked to learn that the repo consumes almost 200 GiB nowadays. > Currently it has a 30mbit bandwith limit (this can be more in the > future, I don't know what amount of traffic to expect). this is megabits _per second_, right? i don't have an estimate, but i can tell it will be very much welcome among users. the more bandwidth gets added to the pool, the merrier. > If it fits the public interest in this way, can I offer it to be on > the list of mirrors on the wiki? adding it as we speak. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAlo4fJkACgkQM0ZuEux7 qUOunhAAmTI3vOltW6K/c4puqdkDa2pkPYIChrFf5GfEydgckPD8rn9A35GQ2zQ4 POenE12Yoo5lXBk7g4qYwMGVsLEXbYxQqCRb5tX9rOz30TZ/oDDy/Vs0eW/SKk6x /JbrK7blYXPr5FQtHwvQZeVXMuyihdphsc6qrqMTU9rjeFP7CnoRuKTVIvjZ5Dwr T63BH7rrye/r7n1lMnI5DCS+AdrMhRkPDUnQmnGZIuIEDxO9VTs7VoPAR6FiVBOY eKxvNas9vQjDDQjSix4JYWbXU11didnnWyVZ/D8P7BvsATVhIOjRXFOM1x2cx6Sd 96YjWdTHXeRiCHqliDLy8dktWbJjb3gkHLsWUuu9fKCLXmWgDA4ZbhQZK12rZkKG 344cU5wfcjRLsuaHEZbi6ZOQqpmE+RJ2Rre571yrWLdfpDvG/AtC/1NGVdYlb0yw ZypGZRXq5RN7+5JVJXb/JxB+aG1LD9n7fqbcHxTmz+SBCwthMJcmsmIALcURJCb5 C/FMM6Ui2iWnlz9rNEES6LDhR0OEtnARkl3xHF5WIG9v5zGrR+LsHQIyZU1pA7Ws hGu9bCJifYK309rkV6kO9h0mmscoFpL8X0ektS7F+AOx1d+G+ppP6NC/EIwDfJey gKerkLMpRJbwpqSrqDVA+o0L34HjPrMX0eaNuM4HzPdaSH6wNB0= =ky5E -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
[Dev] [dbscripts]: Arch Linux 32 support [annoucement]. ABS' future [RFC]
hi, i've been working over the last few days on getting dbscripts to import i686 packages from archlinux32.org. this resulted on a single script (db-import-pkg) shared by our 3 upstream providers, with common routines from the previous separate scripts modularised, de-duplicated and (briefly) documented. armv7h and i686 will also stop duplicating arch=(any) packages first obtained from Arch proper. that's it for the cursory announcement/overview of the impending dbscripts release, which probably affects no one but our server. on a related topic, we no longer have a (working) tool to retrieve sources per package. Arch's [deprecation of ABS][] also spelled the end of Parabola's dbscripts program that dealt with populating our own ABS-like tree. because .src tarballs are completely lacking from ALARM and Arch32, it's clear to me that the only way forward is to pull from VC systems themselves and cook one full Parabola source tree from there. that is, one per upstream/architecture, overriding with customized PKGBUILDs. but what about the client? what are your views regarding fixing and continuing abs vs adopting and adapting the newer --and apparently more complex-- [asp][]? [deprecation of ABS]: https://www.archlinux.org/news/deprecation-of-abs/ [asp]: https://github.com/falconindy/asp -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] EOMA68 card
Megver83 wrote : ummm, just got the email after various days :S nobody was around to approve it. SohKa isn't subscribed. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Install media releng / I made some changes
bill-auger wrote : Luke Shumaker wrote: In my view, there are 3 install classes of install images: [...] - ARM images (we don't currently make these, and we totally should) i agree that an ARM installer is a good idea - ARM devices are only going to get more popular - many come with some OS pre-installed (typically berry-flavored) but today it is generally non-trivial to replace it safely absolutely, this has been a huge omission from our part. i would be interested to know how this would play out... - whether there's a point in mastering an ISO image or just making a tarball of the filesystem. - what packages to include. install ISO-like environment? just the base group? booloaders?. - whether we want to blow up that release matrix by a factor of the number of devices. - finally, what the interplay between ARM releases and x86 releases would be. there's at least one unofficial image out there[1]. not to mention that some EOMA68 cards will come out with Parabola -- sooner or later -- which reminds me of the need to package LKCL's version of uboot for it. [1]: https://wiki.parabola.nu/ARM_Installation_Guide#BeagleBone_Black_2 -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Public Money >> Public Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message Andreas Grapentin wrote : > I also would like to see parabola represented as supporter of this > open letter. so do i, even though i'm not entirely sure how we would go about this (beyond reaching a consensus beforehand), and whether much would be gained from adding a smallish and loosely grouped project like ours. otherwise, all the power to this. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAlnz8OUACgkQM0ZuEux7 qUMvdBAAq9AUk4gFAgIRPFn7X2gpqjObLIYGYE8vV5ZijPx3ii4uE2cUALaKeKyy O+TujWkNcUZxXX852rtoSkHa1Bmkz+aTJ/Gnf4HGPFeONX0qip93VnnxwAtmyBIT JFJi9Mghh9fwXOKQewnF08mS5fLb6mlaRBxEq4Wj3r/e3tYh081YmoB6kj8UeK9O OxQ3b5Wcu4EOqjUG8iUN3icbZzOVyPP7J0CJIGBwzGMuIdh9wTRzHLMRTPLds6oN AyyI/RdRrSwcy9scQCoTqn90NxjbT5fL3u6gyXTBDUOd4SrEpBdZCr17YftFEee6 MIEFkj2oeG3c2310EpvHychv8CmLMNwJ1rQncG9G+tvq6QQOhFzoEc2euIvsvK7l rAbdbq9sVZiVNSciVYWt3Y+cqttKgbOzThwVoonTLKMB1aO9gSvTVFqMX4Zt2ngM 9RpEdk9MwBPukSFFSFL8WtNC4tYMbSAtTbTW8/izl9WEtrDdftmxOcere0HvrJIi wlXKtr/RGEY24rz8VDvvgR/qOgzI3JpPvdH8qTHrRMH35zHEV7HZwxPZDRrVluvf Ng9n0bLLpvR/n281ZCE0N3FJyrfuuCmy6HtYHgULPD89oo4sQYjwCis8eDQ4aZ6l FaU7R2AbfoPDDJLiYZdQPzVhMm4pQBcpzT17XS1XRora9+rrSG8= =KNne -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] I say goodbye to Parabola
Hi guys, after a few days thinking about it and for personal reasons, i've decided to say Goodbye. Lately I'm going through economic crises. But that's not the problem. I will spend more time with my family and friends for now. I will work full time on other business matters. I will continue to support the Free Software movement, and in the liberation of cyberspace from where on the planet. Without more, regards and thanks for all, -- Jesús Eduardo | Developer The Free Software movement is lucky to have you in. You will be missed in Parabola heckyel. I sincerely reserve the best of my wishes for you and your family. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Ring: c8ba5620e080bef9470efb314c257304ff9480f5 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C <https://isacdaavid.info/donate> ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] feedback for Parabola beta ISOs
Megver83 wrote : Hi all, I've written a new: https://www.parabola.nu/news/new-openrc-and-lxde-isos/ i'm not an openrc user, but i can only say yay!, kudos. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [RFC] blacklist/your-freedom conflicts/replaces stragegy
Luke Shumaker wrote : now I'm questioning more of the premise. Does it even need the libre-replacement, or does it just need a boolean of whether another package has that name or provides that name? Wouldn't that better be served by querying the repos than by manually keeping a .txt file in sync with them? i see. not only does your-freedom not need that info; it's not even accurately duplicated, as I'll show next... What if we edited a simpler file that didn't have replacement info, and had a program that output a file more like the current blacklist.txt? a better `libreblacklist get-rep` in other words. `pacman -Ssq "^arch-pkg$"` will return all providers, but miss replacements. expac is perfectly suited at providing that information however. i've been using an awk script in conjunction with it, and comparing to `libreblacklist get-rep` to fix some sore thumbs. i'm sharing the less obvious ones so that everyone has a chance to comment before i go on fixing them: apache-ant-doc:apache-ant# no package replaces/provides it archey3:paraboley# same. fix pcr/paraboley-git archiso:parabolaiso # BUG? actual rep is parabolaiso-git firefox: # needs no explanation firefox-i18n-be: # add to iceweasel-l10n/PKGBUILD firefox-i18n-csb:# add to iceweasel-l10n/PKGBUILD firefox-i18n-*: # same as firefox font-bh-ttf:font-bh-ttf # no replacement/provider font-misc-meltho:font-misc-meltho# no rep. Arch moved to xorg-fonts-misc glsof:glsof # no rep. linux-hardened:linux-libre-grsec # superseded by linux-libre-hardened linux-hardened-headers:linux-libre-grsec-headers # see above linux-hardened-docs:linux-libre-grsec-docs # see above luxblend25:blender-addon-luxrender # in abslibre but missing from repos nltk-data:nltk-data # no rep. nvidia-304xx-utils: # BUG?, replaced by mesa-vanilla nvidia-340xx-utils: # see above nvidia-cg-toolkit: # BUG?, replaced by mesa-libgl-vanilla nvidia-utils:# see above opencl-nvidia: # BUG? replaced by opencl-mesa-vanilla opencl-nvidia-304xx: # see above opencl-nvidia-340xx: # see above unarj:arj# arj doesn't explicitly say so of course there are many other discrepancies where blacklist.txt lists less replacements than there actually are. it takes expac and awk less than a second to spit all the repo metadata, reorder it by replaced/provided package and find the hundreds of arch-pkgs (or any target list for that matter); so i don't think we would gain anything by duplicating some of the expac functionality in, say, a libalpm binary. libretools already depends on expac, so maybe this could be the basis for a renewed and more versatile `libreblacklist get-rep`. i'm still planning to make that trivial fix for `get-reason` btw... got lost in boring shit last week. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [epiphany] marked out-of-date
jm.100b...@gmail.com wants to notify you that the following packages may be out-of-date: * epiphany 3.24.3-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/epiphany/ * epiphany 3.24.3-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/epiphany/ The user provided the following additional text: GNOME 3.26 Has been released on September 13, 2017. https://www.gnome.org/news/2017/09/gnome-3-26-released/ pump your breaks. 3.26 hasn't even made it out of [Gnome-Unstable] in Arch. rebuilding epiphany now would only cause trouble. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [RFC] blacklist/your-freedom conflicts/replaces stragegy
Luke Shumaker wrote :
If a user wants to
install firefox and iceweasel side-by-side, the conflict should be
happening with your-freedom->firefox, not iceweasel->firefox. Another
example is if a user wants to install linux and linux-libre
side-by-side.
What we need is a way of specifying in blacklist.txt whether
parabola-replacement provides=/conflicts=(arch-package)
agreed 100%
So, the remaining question is: What should the syntax in blacklist.txt
look like
obviously it would have an extra field (i'm calling it CONFLICT) that
allows for only 2 options. their meanings could be specified in a
number of equivalent ways, so i'm not deeply worried about those.
syntax-wise though, because CONFLICT is _necessary_ only in the
context of libre-replacement, it's easy to imagine something like the
following:
1.
original-package:[libre-replacement:CONFLICT]:[ref]:[id]:short-description
however the variable-length format could complicate things too
much for programs parsing blacklist.txt, such as libreblacklist.
2. this could be avoided by explicitly distinguishing
[libre-replacementCONFLICT] from top-level fields:
original-package:[libre-replacement+CONFLICT]:[ref]:[id]:short-description
3. finally, we can always keep CONFLICT and libre-replacement each on
its own top-level field...
original-package:[libre-replacement]:[CONFLICT]:[ref]:[id]:short-description
...and be prepared to deal with errors like:
flashplugin::ALREADY_CONFLICTED:::nonfree package with no
replacement
and [what] programs will need updated to deal with it?
libreblacklist is the elephant in the room. ideally all other programs
would restrict themselves to this interface. your-freedom & co. still
_need_ to parse blacklist.txt directly nonetheless:
conflicts=($(
< blacklist-${_gitver}.txt \
libreblacklist normalize |
cut -d: -f1,2 |
sed -n 's/:$//p' |
sort -u
))
i can't think of any other after you changed dbscripts to use
libreblacklist.
by the way, libreblacklist should be advertised more prominently on
the wiki to average users. it's much more elegant and discoverable
than blacklist.git. also, would you accept a patch to add a
get-ref/get-url function? have you noticed that get-reason doesn't
quite do what it says?:
$ libreblacklist |& grep get-reason
get-reasonPrints only the reason field of the blacklist line(s)
$ libreblacklist cat | libreblacklist get-reason | tail -n 1
parabola:1457:[semifree] recommends unfree projects from same author
--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Tox:
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] update your-freedom not to reject firefox
bill-auger wrote : if you really wanted to change the name but preserve the art [...] the point was to change the artwork with an easy-to-deploy hack. i'd still prefer to see the name actually changed. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] My wiki account not in "emailconfirmed" group
Megver83 wrote: Strange, I still cannot modify pages which require to be in that group, and I still appear like not being part of it. apparently "emailconfirmed" and "Autoconfirmed users" are excluded from the groups whose membership one is allowed to manipulate from MediaWiki itself. i just added you to the "bots" group. with that, all 4 rights granted to "Autoconfirmed users" (editsemiprotected, autoconfirmed) and "emailconfirmed" (edit, upload) should be already covered by other groups you're in. have you tried different email addresses? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] My wiki account not in "emailconfirmed" group
Megver83 wrote: Could any of the sysadmins manually add me to such group, please? done -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] update your-freedom not to reject firefox
bill-auger wrote: just FYI - i will add that there is another distinct 'iceweasel' maintained by the 'connochaetos' indeed. parabola's iceweasel derived from connochaetos': https://www.parabola.nu/news/iceweasel-libre/ -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] request for shell/git access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message we would be foolish not to accept such a big contribution. if Parabola is going to keep offering a graphical installer it better is a properly-maintained one. the kind of users who can work around the issues with the current image probably use the CLI installer anyway. besides, you've been hanging around here, there and everywhere for some time already. how far are you into building the new ISO? i could set up your account over the weekend, in the absence of objections. you could send us your profile in the meantime according to these [examples](https://git.parabola.nu/hackers.git/tree/users/1029.yml) bill-auger said: > i seem to remember oaken-source needed to touch multiple servers to > post a new release (FTP site, the downloads wiki page) so it is not > clear which specific access i should be asking for this would grant you ssh access to both servers (proton.parabola.nu, winston.parabola.nu) using your personal account as specified in your profile, plus access to r...@winston.parabola.nu (a.k.a. r...@repo.parabola.nu) and g...@winston.parabola.nu (a.k.a. g...@git.parabola.nu). the latter is used to push commits, whereas repo runs dbscripts and has write access to everything being served in the main mirror, including the ISOs. changing the wiki will be trivial in comparison. > ideally, i would like to be able to build the ISOs on the server where > they would be hosted rather than building locally and uploading sounds plausible... using your personal winston account then moving things to their final destination with repo. or maybe using repo all along, with care. how did oaken-source and Emulatorman do it? > also there are many open issues on the bug tracker related to this > (some are years old) so perhaps i could be permitted me to curate > those same observation as with the wiki. first things first. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAlmvcpAACgkQM0ZuEux7 qUM2+xAA151vxeElqSlDSPuprHjPcd2Ct8yhXy2wj8p7vOR8edYOcgXTXB15W6OY w/hkJT5tIQafH3vIlfyjKPL/tkwYYwUc2TITclRIgkEPtqVejXzVT2PYBPOpbb++ S1ZvV6Wh6cCxgkR/PyngV2gmJ01SfAxLbYXskuEDKov54eYLSW6YliWMiNS0/TGn iExxYA4QfVyz9KJeCWQoRIf+MGKYRrEwxLatxhn3ftExNGVqKSETxkqN7654iJGD jJIcskM2IgJAiK4fS5k556aUfbC+nnOywpWFW5x+SmpeKY79icidPaM/spwn6EjK cH73GtjSELH1v/u65T1lU7bw+h5NDiTbHgXaQQZUaxg0RgwL9OCTmTO/ROek14y8 yUnHmK0J0Br7MmTQlfM78SgJ//0VqbVnAzczd5rkf6hyoucIGtD64PcYGipSnCMF rkJ+mq4eT6028vZ5yELRQGZLPbV2AhvgtTihg1WLRV5w4vOk3yjfGmZE8xJR59IE aVs5tT/WyvL5ZR7NRUVxDnwcYvnZ/AIKpfHI0b9AZ8OcNdGoY4HX0jI006XX4rSN Rmv28wvVjBa21c8BBuuvfm8Wypcm8C1xFovdwGUjGWAx1DRbaNnkfwdIw6cL0H4X NqbUWxpXyq6Uh1FuSZc4UDQA6WGcYvn3MQYwsOLYoSC3LhwNV90= =eIdG -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] VN Mirror - Freedif.org - Scheduled upgrade
Karibu wrote : Hello, The VN mirror, mirror.freedif.org, will have a scheduled upgrade the 30th August. I will move facility and move from 100M to 1G connection! If all goes well, the mirror will be back the 31st August. I will inform you of the success or not of the upgrade. Karibu ok, thanks for the info Karibu. i'll send a copy to the dev list. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Cleaning up [pcr]
Isaac David : looking at libredbdiff i'm noticing that some packages in [libre] used to replace things which no longer exist in Arch proper (i.e. non-AUR), and serve no other purpose for Parabola as far as i can tell. vestiges from a previous age: javacc jquery jquery-ui psi spacefm usermin webmin xbmc-pvr-addons-lts xchat weigh in if you think there's any reason they shouldn't be disposed of (in abslibre as well), or if you would like to see them moved to [pcr] gone -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Cleaning up [pcr]
The [pcr] repository has many packages that haven't been upgraded for ages, however, they are not marked as outdated. Some of those unused packages are not even compiled (they are only in the abslibre) looking at libredbdiff i'm noticing that some packages in [libre] used to replace things which no longer exist in Arch proper (i.e. non-AUR), and serve no other purpose for Parabola as far as i can tell. vestiges from a previous age: javacc jquery jquery-ui psi spacefm usermin webmin xbmc-pvr-addons-lts xchat weigh in if you think there's any reason they shouldn't be disposed of (in abslibre as well), or if you would like to see them moved to [pcr] -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [kio] marked out-of-date
thanks once again. this is my joint response and confirmation that the following packages have been updated from your patches: - icecat-noscript - iceweasel-noscript - icecat-ublock-origin - iceweasel-ublock-origin (i just learned we replace adblock-plus) - khotkeys - kinfocenter - kio (waiting for ALARM to release kconfig 5.36 to build for armv7h) did i miss any? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Parabola as an option for Purism Librem laptops
Mladen Pejaković : I'm experienced Arch/Parabola user and have already tested both basic and Mate ISOs, everything simply works. :) We will think whether we will offer just basic system or the Mate live session. the Mate ISO is outdated and kinda broken iirc. you probably want to avoid it for the time being. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] outdated 'nonprism' gnome-settings-daemon
Robert Alessi : Since this update, things are getting better on my laptop too: gnome seemingly starts, but ends up with a blank screen. Nothing is frozen though for gvim which is set to pop up my reminders shows up as expected—but with no decorations. Guake also works, but that's about it. so you could get past gdm, right? i tried to reproduce with a full dive into [nonprism] (`pacman -Syyuu your-privacy`) instead of just replacing the 2 packages, but in my case i was greeted with a borked gdm which didn't show anything apart from the pointer. I tried the standard version of gnome-settings-daemon which is in extra/ and I can tell that everything works with it. which pulled geoclue2 as dep, right? i don't know how similar our experiences are, but this bit right here would also make sense to mine. i'll explain... some other gnome packages in [nonprism] (e.g. empathy, evolution-data-server, gnome-weather, grilo-plugins) require need some attention. But they do not cause this issue in conjunction with gnome-settings-daemon, do they? apparently not. i uninstalled them in full, one by one, and at no point did gdm work. doesn't imply they aren't required in updated form, but here comes the interesting part: i put 'em back, then i restored the stuff that your-privacy originally conflicted with, one at a time. _i could recover gnome when geoclue2 was present_, no need for extra/gnome-settings-daemon. could you try this combination? this would mean there's another dependency on geoclue2 we must get rid of, somewhere. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] outdated 'nonprism' gnome-settings-daemon
Robert Alessi : Hi, Is there any progress on this? For the time being, staying out of prism also means staying out of gnome... :( Robert On Fri, May 12, 2017 at 06:16:37PM +0200, Robert Alessi wrote: Hi Devs, Since the update of gnome to v3.24.2, I can't any longer log into gnome, nor can I use gdm. Since I use the 'nonprism' repository, I guess the culprit may be the 'nonprism' gnome-settings-daemon version which is still at v3.22.1. Can anybody look into this issue? Many thanks in anticipation! Robert updated gnome-online-accounts and gnome-settings-daemon to their respective latest versions. my own test of them went smooth. some other gnome packages in [nonprism] (e.g. empathy, evolution-data-server, gnome-weather, grilo-plugins) require need some attention. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [kio] marked out-of-date
jc_gargma: I've attached a git format-patch to update kio to 5.35.0 all good with your contributions thus far, thank you for them. are you familiar with building packages with libretools? maybe we should let you upgrade them yourself. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] OpenRC groups - Was: linux-libre is not part of the base group anymore
Reg wrote: Bill Auger wrote: i also noticed this week when working on the calamares installer that 'linux-libre' package separately to complete a fresh install - this is in the base group would be superfluous for every other use case reasonable though as there several kernels to choose from so the one the kernel is not in the 'base' group - i had to require the This makes sense. If this is the approach we want to keep, the installation guide should also be updated accordingly. i hesitate to change the meaning of the base group from what it means on Arch, which also provides more than one kernel. but if you go ahead with this, make sure to search the wiki for every instance of pacstrap usage. the implications extend beyond one installation guide. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [okular] marked out-of-date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message jc_gargma wrote: > I've attached an updated PKGBUILD for 17.04.2 thank you, the new version is up. was it ok to attribute this to "jc "? if you are working with git on abslibre and don't want me to make the decision for you then consider sending a patch produced with `git format-patch` -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAlk8zRUACgkQM0ZuEux7 qUPKIRAAjh2cVQ2RJ1WmNS+/DLJfHQAvWXE69K94ZhnLTl7NLYkub8vFBWkk7Ssf v+BBhRaWqptKowLu2KrNK3ohbOksCWWr9DnwW+MwaqpgNzvaoJ85AbMhMaz2+35b Av1QEnlMps55Heflibbjqc7kti2t8iZeEzXjcwVvumfnMjundB4ZB5E57mdFLUoc CKkxFna3QNoj3yaSbC4KS2ZY8T2N2LxdPeKlV2vUApMDnyQ3GbwnRKs8dTQiQ045 zJhRFM6DCTB5Xwd99TNhtgWmt9k1uVSVBHWmEBiOx1cer9tohXiElCBT2TW+ZQjG jLRvdP7aLW/ittxTDfseaUnLNbCQ7VF7TKwX6RxojlAzx0DarA2LhNoL000/bINn 36BZXLXScPsQn+BR7rNqLVGJLFevkQT+EHBM4I9kGoAxWSXbchiSLRrnHuE2CORS qnfOS4dkHSOrxrGheeNKPFnW5V+IUR2tVvVHcTpm0jztmTbi3+MdHbiN6kkh+qvj 7oyCI7vz+8k/gSUdCa9/YRQ9p2qZ1IzBvZVWw6ppc22sMw5jTPaVI0Y2/W89ykR4 6IuS9vt0nC292C5l2lNMZl/4D/26vnuG7BeSgzl54SfUIuzXcVi8yQoZvH+z7SQx G2X6Eia0YHSScFqumvD6+CiZR049Sj4NWjEMuZBPx4YOM3xrXMY= =Oodo -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [Assist] linux-libre is not part of the base group anymore
Reg wrote:
I was installing Parabola on a new computer today and noticed that
the linux-libre package is not included in the base group anymore.
I suppose that's not intended, so I thought I'd report it.
you are right.
the problem seems to be that the groups=() definition is now only
evaluated if [ "${pkgbase}" = "linux" ], instead of the former
[ "${pkgbase}" = "linux-libre" ]
also, base-openrc was taken out of the groups. was that on purpose?
--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Tox:
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [RFC] [libretools] To --armor or --no-armor package signatures?
jc_gargma wrote : Armored is also useful for posting on forums and other places where attaching of raw files is limited. i think outside gpg's use case specifying an extra plaintext representation would often be overkill. you can always rely on something like base64 or ascii85 to code binaries and printable text back and forth. hash your binary before and after a base64 roundtrip and call it a day. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Mirror changes
pacman-mirrorlist 20170503-1.parabola1 is out oops! not until now do I realize I never released it from my staging dir. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Is it possible to compile multiple packages at the same time with libremakepkg?
Megver83 wrote: Isaac David wrote: if so, I don't think you would gain much from having many packages compile at the same time, given that all of your cores are already in use for the longest time. But it is possible? I think so, and you don't need a new libretools to achieve it imo. just create a second chroot with librechroot (use the -n flag to distinguish them by name), launch separate parallel libremakepkg instances in each of them (-n flag again), and measure time spent vs two libremakepkg instances run in series. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [RFC] Splitting abslibre.git into branches
Luke Shumaker: What do you guys think about splitting abslibre.it so that each package is on its own branch, instead of having all of them side-by-side on the same branch? There would be no 'master' branch. out of curiosity, what are the perceived advantages? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Is it possible to compile multiple packages at the same time with libremakepkg?
yes, I can attest that compiling that many kernels every few weeks is pure madness and bad for your electricity bills :) do you have the -j MAKEFLAG equal the number of cores in your /etc/makepkg.conf? if so, I don't think you would gain much from having many packages compile at the same time, given that all of your cores are already in use for the longest time. I can even imagine it resulting in increased total compilation time because of extra amounts of context switching, cache misses, who knows, don't take my word for it. as for ARM, we should investigate using a full cross-toolchain (or a partial, non-linking cross-compiler on x86 + distcc running on a native system like ALARM does[^1]) as a way to make the most of faster x86 hardware. there are caveats nonetheless compared to either libretools+qemu or native libretools on ARM. namely, no support for it in libretools and a different assortment of failing packages. assuming there's enough RAM to finish the compilation, native is the best when it comes to the amount of packages that can be successfully compiled. the same may be true of a native farm + distcc, but I have never tried such a thing. [^1]: https://archlinuxarm.org/wiki/Distcc_Cross-Compiling ^ I used to follow this method before moving to qemu (for the extra packages that wouldn't compile) -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
[Dev] Algorithm-Diff's License
Hello Tye, I write you as a maintainer of the Parabola GNU/Linux-libre distro, hoping that you'll be able to clarify a licensing question for us regarding the Perl package Algorithm-Diff. We noticed the following files in version 1.1903 don't mention any license, which coupled with the lack of global copyright info left us wondering whether it's safe to assume that these follow the same terms as Perl itself, (like the rest of files): - htmldiff.pl - lib/Algorithm/DiffOld.pm - t/base.t - t/oo.t What's their status? Anything else we should know about this package's license? Thanks in advance, -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Blacklist zeitgeist in your-privacy-blacklist
Josh Branning wrote: It basically keeps a log of all of the users actions in the form of an sqllite3 database. where do you draw the line between this kind of desktop log and the plethora of traditional-ish system logs? should we also blacklist journaling filesystems? storing useful information is something that lots of programs are expected to do. I sense a misunderstanding in the purpose of `your-privacy`. afaict, `your-privacy` is designed to shun packages that exfiltrate information to third parties (internet companies for example), but zeitgeist only makes the information it collects locally-available (correct me if I'm wrong, I don't use it myself). Deleting the package can cause problems for gnome-desktop users though,... ...It is worth noting that this affects all gnome desktops, and ubuntu and it's derivatives. I don't think so. I'm a GNOME user and I have never been asked to install zeitgeist. I think this could be a problem for other GNOME-based desktops though. I'm thinking of Elementary and Unity. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Librerelease doesn't work?
Le sam. 20 mai 2017 à 8:07, Joseph Graham a écrit : I built new pacman2pacman, librestaged it to pcr and librereleased it, but it's still stuck on version 1.5.4-1. It should be 1.5.6-3 now. Logs: [...] ==> ERROR: Package pcr/pacman2pacman-1.5.4-1-any.pkg.tar.xz already exists in another repository multiple versions of this package are present in your staging directory on the server. I don't think db-update can handle all at once. try deleting the old ones and then repo@repo $ STAGING=~/staging/joseph/staging db-update -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] licenses package has outdated links
Le jeu. 18 mai 2017 à 14:27, Megver83 a écrit : the MPL Andreas Grapentin: do you mean the MPL or the ruby license? On Thu, May 18, 2017 at 06:08:00PM +, Megver83 wrote: Andreas, can you make a list of all packages with this license? why though? we literally just need to wait for Arch to fix the `licenses` package and make sure ours builds cleanly. gosh, do I hate top-posting. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] licenses package has outdated links
Le mer. 17 mai 2017 à 8:18, Dima Ursu a écrit : The licenses package has and outdated link to MPL, which returns 404. The correct link is now - https://www.mozilla.org/media/MPL/1.1/index.txt this is better directed at Arch: https://bugs.archlinux.org/task/49174 Also, the checksum for the ruby license is failing. our fault, I would say. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Icedove-52.1 going up to [libre-testing] soon - Was: Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date
Le mer. 10 mai 2017 à 7:09, Andreas Grapentin a écrit :
Following the discussion below, I built the latest thunderbird
release
(52.1.0) and rebranded it to icedove, and ported many freedom issue
patches from iceweasel over.
The build is running now for i686 and x86_64 and I will push the
packages later, first to [libre-testing] - would anybody be
inclined to
test them? I'm not an icedove user myself, and might miss some
subtle
flaws, hence I don't want to push to [libre] immediately.
the build is done and looks good at first glance. any volunteers for
some initial tests?
I'm CC'ing the user who flagged it.
any opinions on the epoch bump? I am particularily unsure about this.
I see no need for it, given that the new pkgver-pkgrel isn't a
downgrade.
but then again, I don't get why epoch was introduced in ice{weasel,dove}
in the first place (I wasn't around back then), so I could be missing
something.
--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Why is db-import-archlinuxarm disabled?
Le mar. 9 mai 2017 à 9:03, Megver83 a écrit :
Why?
prevent dependency drift and breakage between outdated Parabola
packages and ALARM packages back when I was taking care of it.
Who can enable it, please?
you can, anyone with repo access can:
EDITOR=${your-favorite-editor} crontab -e
uncomment and wait. I recommend that it not be done unless [libre]
is in good shape.
--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date
Le lun. 8 mai 2017 à 16:13, Andreas Grapentin a écrit : The change I am proposing is not away from iceweasel to something else, but away from debian iceweasel to parabola iceweasel, using the latest sources from upstream, and not the debian repos. The same does probably apply to iceape and icedove. In fact, if this proposal is approved, I will start to work on upgrading icedove, since the version gap there is the greatest (45.8 => 52.1) +1 -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date
Le lun. 8 mai 2017 à 3:47, Andreas Grapentin a écrit : why are we tracking debian firefox instead of the original firefox? Now that debian has discontinued iceweasel and we need to maintain the branding patches ourselves anyway, what is barring us from following the original firefox releases, and remove one level of indirection? don't quote me on this, but I think Emulatorman consciously stuck to iceweasel after Debian returned to vanilla firefox in order to avoid coming up with our own rebranding. keep in mind that Mozilla never amended their policy to allow _all_ redistributors to bear the firefox trademark; the deal was between Mozilla and Debian alone. they could still come after us for taking default settings and the addons page apart, since our version of firefox is arguably less standard than either Debian's or Arch's. that said, you might be right that just using `--disable-official-branding` would be easier if Debian has dropped iceweasel completely now. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] libretools 20170505 release announcement
Le lun. 8 mai 2017 à 12:24, Megver83 a écrit : Oh, I'm not really an expert on this. This is the output: $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-8dKkICdg1HKh/agent.22997; export SSH_AUTH_SOCK; SSH_AGENT_PID=22998; export SSH_AGENT_PID; echo Agent pid 22998; you need to eval that and then add a key. it's all here: https://wiki.archlinux.org/index.php/SSH_keys#SSH_agents some desktops will make it even more automatic and transparent. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Mirror changes
pacman-mirrorlist 20170503-1.parabola1 is out, the update had already been taken care of on the website. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] the future of arm support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message Le lun. 24 avril 2017 à 17:01, Bill Auger a écrit : > it should be addressed that the status and future of the arm port are > completely in the air at the moment they are, but probably not for the reasons you might think. the website paused reporting on updates to arm on Feb 04, but they had been arriving smoothly behind the scenes until a couple weeks ago, when I lost the ability to compile on a half-decent machine. I've been slowly trying to regain ground, pushing some overdue packages as I write, but it's become clear that my laptop can't keep up with the task. adding to the grievance, I no longer use any arm devices. maybe it's time for others to step in? > i had to note that the EOMA68 libre-tea card are promised to ship with > parabola pre-installed so it would be reasonable to support arm even > if only for that device this is what frightens me the most, the idea of hundreds of users being greeted with a distro that was already dead by the time they receive their devices. I even bought a card, but if the port can't be maintained so be it. maybe I will be able to revive the effort using that very EOMA68 card, supposing that won't be much more unpleasant than doing qemu on the build machine I used to use. also, not that you asked but, I would refuse to receive Parabola-sponsored hardware after seeing all the recent hassle; although I wouldn't mind being invited to use a hypothetical build server under other hackers' responsibility. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAlj+0cQACgkQM0ZuEux7 qUNeKQ//fIP+EMmwl/Z/vu6ByFmL7aL1j/1QRXkWYmMjUwQJ8cg4bKsVEL8S9kqC Qi8OT1ewaGvhB+wRIUSh8qbt6RtDvck7waJA/UkFDB7hbWsLIZ5spZBqKd5XoU0m DrqmslwQ3iNArkh1t0mAVuBURjNLXfTp9WDaIxKa7BCC0OBuQFTbyMyZs0lsmcb0 cqEzWSwmq01ANF1dIgwZ17ZbHw2/NMJt0cZeT0mCSRM2ixSYpCYlKOQKfgw9Jw/f aSpwVg8dY6pqMbLVWw/yKgCgW4SXrDqjoRfEB8BPWb7jR1hiA42xvVzDfOdrjCGD 2S9VONyXijUMjoI7eNrDqxBfdxHGEZqmGsi5LaN/vIPQGRlPrwk+nxnmq9AfXMlK G8jHdqeuEKofq++2lCISKbbNpyocuRQeWhIn3em8QR02PQpgKtvV67orr7JNuCuh blAuvNQxaiu7Z+e+2xLtWUOAKY3Y67goiZ2dLbviblMZYLIVV/LWE4BXgddIgOri 6fYQCNkK8/gZWzuMhLQsxGLDwxMsiOEYHAXzOzRUu8n3FrnFfTc4qo0Jp08Lq38t x1qjdgXkqa0SNeKcReFUKlgkwk5i2d0GP/7U7s3eI+KZBVl4LtHfVFVEsqqZOwbq bLLTf3ED6fKJp7UqH4yHj0OEUfbPh4i3YkLe5cg7V3piupupNbg= =kI64 -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] My SSH key is untrusted?
Le ven. 21 avril 2017 à 12:03, Megver83 a écrit : our public keys (from ~/.ssh/id_*.pub) have to appear in the ~/.ssh/autorized_keys file from the server that's the common scenario, however I'm afraid it doesn't apply here. sshd on winston is configured to read public keys directly from hackers.git. whatever the case, only lukeshu can fix it. let's wait for him. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] My SSH key is untrusted?
you are not alone; ovruni and I also get rejected from both servers. probably a hackers.git problem? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [Packagers] We have to distribute the maintenance of hacker fellows' packages
Megver83 requested on irc that somebody else made the list. this one contains all the split packages in Parabola-only repos (e.g. libre, nonprism, pcr) except for mips64el ones. some packages are repeated because they are built by different people for different architectures, so this is rather a list of unique packager+pkgname combinations. numbers may look more daunting than they really are because of the base-package/split-package distinction, but they should give us a sense of the proportion of work that needs to be done. $ cut -d ' ' -f 1,2 packagers.txt | sort | uniq -c | sort -n 1 Jorge Lopez 2 Drtan Samos 2 Guest One 3 Michał Masłowski 3 Unknown Packager 5 Jorge Araya 6 Charles Roth 8 aurelien DESBRIERES 11 Esteban Carnevale 15 Aurélien Desbrières 22 Aurélien DESBRIÈRES 33 David P. 40 Aurelien DESBRIERES 41 Nicolás Reynolds 64 Luke R. 84 Luke Shumaker 129 Márcio Silva 238 Isaac David 495 Omar Vega 807 André Silva also, don't forget to factor in other tasks like maintaining the ISOs -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 André Silva libre/tokyocabinet André Silva pcr/bamf2 André Silva pcr/cambozola André Silva pcr/d0_blind_id-git André Silva pcr/frame André Silva pcr/geis André Silva pcr/ginn André Silva pcr/grail André Silva pcr/lilo André Silva pcr/mini18n-git André Silva pcr/multiwatch André Silva pcr/nexuiz André Silva pcr/nexuiz-data André Silva pcr/pmount André Silva pcr/python2-pycha André Silva pcr/supermodel André Silva pcr/timekpr André Silva cross/armv7l-unknown-linux-gnueabihf-binutils André Silva cross/armv7l-unknown-linux-gnueabihf-gcc André Silva kernels/linux-libre-apparmor André Silva kernels/linux-libre-apparmor-docs André Silva kernels/linux-libre-apparmor-headers André Silva kernels/linux-libre-audit André Silva kernels/linux-libre-audit-docs André Silva kernels/linux-libre-audit-headers André Silva kernels/linux-libre-grsec-knock André Silva kernels/linux-libre-grsec-knock-docs André Silva kernels/linux-libre-grsec-knock-headers André Silva kernels/linux-libre-grsec-xen André Silva kernels/linux-libre-grsec-xen-docs André Silva kernels/linux-libre-grsec-xen-headers André Silva kernels/linux-libre-knock André Silva kernels/linux-libre-knock-docs André Silva kernels/linux-libre-knock-headers André Silva kernels/linux-libre-lts-apparmor André Silva kernels/linux-libre-lts-apparmor-docs André Silva kernels/linux-libre-lts-apparmor-headers André Silva kernels/linux-libre-lts-knock André Silva kernels/linux-libre-lts-knock-docs André Silva kernels/linux-libre-lts-knock-headers André Silva kernels/linux-libre-nand André Silva kernels/linux-libre-nand-docs André Silva kernels/linux-libre-nand-headers André Silva kernels/linux-libre-pae André Silva kernels/linux-libre-pae-docs André Silva kernels/linux-libre-pae-headers André Silva kernels/linux-libre-rt André Silva kernels/linux-libre-rt-docs André Silva kernels/linux-libre-rt-headers André Silva kernels/linux-libre-xen André Silva kernels/linux-libre-xen-docs André Silva kernels/linux-libre-xen-headers André Silva libre/abiword André Silva libre/abs André Silva libre/abuse André Silva libre/acpi_call André Silva libre/acpi_call-lts André Silva libre/angband André Silva libre/ark André Silva libre/arrayfire André Silva libre/ath9k-htc-firmware André Silva libre/audex André Silva libre/audio-convert André Silva libre/avidemux-cli André Silva libre/avidemux-qt André Silva libre/b43-tools André Silva libre/bbswitch André Silva libre/bbswitch-dkms André Silva libre/bbswitch-lts André Silva libre/bfgminer André Silva libre/bibletime André Silva libre/binfmt-qemu-static André Silva libre/bitlbee André Silva libre/blender André Silva libre/blender-addon-gimp André Silva libre/blender-addon-povray André Silva libre/bogofilter André Silva libre/calibre André Silva libre/cbootimage André Silva libre/clamav André Silva libre/clementine André Silva libre/cool-retro-term André Silva libre/cuneiform André Silva libre/debootstrap André Silva libre/distcc-nozeroconf André Silva libre/doublecmd-gtk2 André Silva libre/doublecmd-qt André Silva libre/dub André Silva libre/dvdrip André Silva libre/ecasound André Silva libre/engrampa André Silva libre/epiphany André Silva libre/faenza-icon-theme André Silva libre/faience-icon-theme André Silva libre/file-roller André Silva libre/filesystem André Silva libre/glib2-static André Silva libre/gnome-boxes André Silva libre/gnormalize André Silva libre/grub André Silva libre/gst-plugins-bad André Silva libre/gvim André Silva libre/hardinfo André Silva libre/hashcat André Silva libre/hex-a-hop Andr
Re: [Dev] An issue that could end up with Parabola
Le ven. 14 avril 2017 à 8:22, fauno a écrit : i'm fed up with the behaviour of the likes of emulatorman, g4jc, isaacdavid... calling rms over to defend them was an awesome move. I cringed when I saw this thread, please stop putting words in everyone's mouth. the fact that you won't even attribute it properly speaks mountains of your malice, resentment and conspiratorial thinking. I'm losing whatever confidence I had left for you. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Some doubts about Parabola's donations
Le sam. 8 avril 2017 à 5:26, Tiberiu-Cezar Tehnoetic a écrit : On 08.04.2017 01:58, Isaac David wrote: ergo the call for considering cancelling the agreement. So you admit this is what it was all about with the original post: Showing dissatisfaction with Ceata's performance as fiscal sponsor, for Parabola hackers to decide "canceling the agreement" since fauno was not in accord with your faction. Throw as much dirt towards Ceata to force the decision. if by "original post" you mean this thread's OP, then no, you are reading between lines. as a matter of fact, Emulatorman, Gaming4JC and coadde wanted to part ways with your organisation, peacefully and transparently, and I echoed their wish for a more agile donations system. I challenge those who have accused any of us of slandering you or your organisation to support their claims. all of us knew we couldn't take that decision for either party in the agreement. it was the all-too-brief consultation with fauno and subsequent disagreement that led Emulatorman to reconsider his position and thus begin this thread. you should feel bad for accusing him, without merit, of smearing you or forcing you into anything. he was merely posing you sincere accountability questions. Well, I understood that and made things easy for you. I on behalf of Ceata have canceled the agreement. I and my organization don't need this. fine, so you admit you took that decision freely, and that Ceata doing this was one of the the normal pathways for the agreement to dissolve. cognitive dissonance is such a capricious prick, isn't it? I can't argue with Ceata wanting to take the first step as soon as you became aware of the disagreement. nobody can. your decision does happen to coincide with what the aforementioned Parabola hackers wanted; so be it. those who feel mad at the dissolution have no reason to blame some hackers for merely wanting it to happen, nor can they blame Ceata for exercising their right to dissolve it, regardless of whatever consensus could have been formed on Parabola's side. I wish you were sincere 12h ago too, when you claimed: On 08.04.2017 00:13, Isaac David wrote: just as obscure is Tiberiu's apologetic reaction to Emulatorman's very polite OP. tl;dr version: Emulatorman: hey Tiberiu!, we have some doubts about the accounting file Tiberiu: I know you are dissatisfied, Ceata says goodbye. ...gee, I wonder who could have maligned him in the dark to pull out before wider discussion took place. you'll see, both things are true. I truly suspect fauno gave you his lopsided rundown in private before you replied to this thread, *and* the aforementioned people wanted to bring the idea of dissolving the agreement to this list (that was one of the ancillary purposes of writing the pad after all), which sooner or later would have taken us to asking Parabola's representative before Ceata for input. it's not that difficult to understand. This was never supposed to be a discussion. because you say so, am I right? I have already presented all of you with the pad at riseup, timeline and all. (I don't know why it wasn't brought up earlier, before speculation and flaming ran amok). what do you have to offer? And about this: On 08.04.2017 00:13, Isaac David wrote: in any case, the contents of our devilish conspiracy were always meant to reach the lists, so observers deserve better than listening to your *recollection of events*. here's the thing: https://pad.riseup.net/p/TYGrGEaO6Twt/timeslider every coup needs a plan to try give the action legitimacy, right? I'm sure that this is not the only talk you had behind everyone's backs. And what is this g4jc: RIP Ceata, Emulatorman: #rip-ceata, coadde: rip-ceata. Do you really hate Ceata that much? RIP = Death. Is this your goodbye wish to Ceata? Have you named your communication channel #rip-ceata? You are so low... hang on for a second, I'm reaching out for my tinfoil hat... done! sure, it couldn't have meant that they wanted to bring forth the proposal of parting ways with Ceata amicably in order to reshape money influx with some new ideas they had been working on, as they wrote multiple times on the pad: Since we have Ceata issues to use our money (It should be discussed... * Propose cancel Ceata services... in fact #rip-ceata was codename for buying a tombstone for Tiberiu. I would be watching my back if I were you! -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Some doubts about Parabola's donations
Le ven. 7 avril 2017 à 16:37, hellekin a écrit : How comes adhocracy and consensus went to shit when it came to handling money? well, no consensus was required to cancel the agreement, and I fail to see how either of those concepts applied to donations and their handling. Blaming Ceata for that who are you citing exactly? when they only performed as they said nobody claimed they didn't. the claim was that they couldn't do nearly as much as some hackers wanted from them. ergo the call for considering cancelling the agreement. now you have to find another one within 2 months (good luck with that) https://git.parabola.nu/~~historic/ceata-agreement.git/tree/Parabola+Ceata_Agreement.markdown section 7.c, "Termination Without a Fiscal Sponsor Successor" simply says funds stay frozen until a new sponsor is found. 60 days is the grace period between notification and actual cancellation. there's nothing in the terms per se to worry about. I only hope the Parabola community can survive your selfish brat behavior. I hope you aren't implying that some of our most active contributors are selfish brats for the sin of wanting to actually benefit from donations. that would be on a whole new level of nonsense. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Some doubts about Parabola's donations
Le jeu. 6 avril 2017 à 12:51, fauno a écrit : then i'm invited to a tox channel where i read some people basically think ceata and tct are keeping the money for themselves and their task is to recover it, given their "unwillingness" to make expenses on our behalf, which i found ridiculous. i mention it looks like a coup, since it's a secret meeting to form a consensus out of reach from the whole community. did anyone mention FUD? Beware the sarcasm in my reply... so they wanted to form a consensus that wasn't a real consensus, how would that even work fauno? on what universe does a coup consist of organizing around making Parabola development more lively and sustainable for more developers, then writing a pad whereby interested hackers brainstorm their ideas to be posted for public opinion? perhaps Mr. Adhocracy wanted us to ask him for his blessing before we got into a pad. also, this wouldn't have been the first time things are put together in "private" group conversations and collaboration pads before they reach the mailing lists, but whatever, welcome to coup #437 everybody! others have told you already how much of a stretch this is, but apparently your mind is made up. you would rather double-down on your first impressions (which by the way you never bothered to confirm with us on the channels you were invited to afaict... let's talk about silence and one-sided conclusions there!). just as obscure is Tiberiu's apologetic reaction to Emulatorman's very polite OP. tl;dr version: Emulatorman: hey Tiberiu!, we have some doubts about the accounting file Tiberiu: I know you are dissatisfied, Ceata says goodbye. ...gee, I wonder who could have maligned him in the dark to pull out before wider discussion took place. in any case, the contents of our devilish conspiracy were always meant to reach the lists, so observers deserve better than listening to your *recollection of events*. here's the thing: https://pad.riseup.net/p/TYGrGEaO6Twt/timeslider yes, some hackers expressed deep dissatisfaction with the donations system, citing how slow and difficult it is to deal with, and because it practically prevents those who would like to make a buck out of Parabola development from ever seeing a donor. hopefully this won't be a problem anymore. i sustain this even if it offended them. with all respect, as someone who was barely involved in this affair, I deride your reaction not as offensive but paranoic. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [Packaging] Error when compiling in clean ARMv7h chroot
Le jeu. 6 avril 2017 à 9:30, Megver83 a écrit : if I compile it in an ARMv7h machine, would it work? it should since the bug comes from QEMU. what Emulatorman suggests would allow you to create a new chroot so that you can build other packages, but given that the error is also triggered while building dagpkg you are out of luck building it with current QEMU, except maybe by making some changes. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [Packaging] Error when compiling in clean ARMv7h chroot
5 avril 2017 à 18:39, Megver83: hi devs, I'm having an issue when trying to compile dpkg with libretools for armv7h (I'm using a x86 machine). I couldn't find anything useful to solve this, I send you the log. it's not particular to dpkg, this needs to be sorted out in QEMU https://labs.parabola.nu/issues/1234 -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] DDNS + parabola.nu sub-domain for our build server
Le ven. 24 mars 2017 à 23:29, André Silva: Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for our build server, since we can configure it to upload directly to winston. Using DDNS on a build server may expose my local area network, which isn't good for security. what about starting the builds themselves? will it also read the TODO list from another server? do we want more than ssh on that server? one option would be asking that machine to open a reverse ssh tunnel to winston or proton (I will use proton in this example): ssh -f -N -T -R $BURNER_PROTON_PORT:localhost:$PORT_IN_BUILD_SERVER \ -i $KEYFILE_TO_PROTON -p $USUAL_PORT_TO_PROTON \ $BUILD_USER@proton $BUILD_USER and its corresponding $KEYFILE_TO_PROTON would have to be set up in advance. then any user at proton with the ability to `ssh -p $BURNER_PROTON_PORT localhost` would begin to negotiate a connection to the build server; which, at your option, could use hackers.git and the bulk of the login infraestructure being used in winston to spare the need for more credentials. more generally and conveniently, one would: ssh -p $BURNER_PROTON_PORT -i $KEYFILE_TO_BUILD_SERVER \ $SOME_USER_ON_BUILD_SERVER@proton to jump straight to the build server from anywhere, via proton behind the scenes. of course any form of ssh access to the build server would give a select few a free pass to its LAN. you could try to isolate the server to a second LAN daisy-chained to the main one. it only takes an extra router. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Fwd: Re: Article: Chromium's subtle freedom flaws
I think _little_ or _much_ evidence aren't the right quantifiers to approach this issue. a single piece of evidence would suffice, whether for Chromium or any other software. also, we should be cautious not to redefine things in order to spare their faults; that would simply beg the question of whether software foo is guilty of bar or not. along those lines, was the upcoming article even supposed to touch on Qt-WebEngine? I'm also increasingly convinced that future claims would make us an enormous favor if they mentioned the scope of their charges. we have been saying "Chromium" to mean a number of things: (a) the Chromium project source code repository, (b) the idealization of a generic Chromium binary, (c) the versions of Chromium shipped by different distros, (d) some sort of library/dependency derived from (a) used by projects like Qt-WebEngine and Electron. it's perfectly possible for Debian's or Fedora's version of Chromium to be free and dandy while the others are non-free, or any other such combination. as far as I can tell from the couple times I have stared at Debian's version of Chromium, **there are no non-free files there**, nor I could find indication of confusingly-licensed files in the aforementioned lintian report. the minified javascript seems to be free. also, it's my understanding from [0] that the non-free plugins are nowhere to be found in (a). ([1] suggests differently, but I'm suspicious of it). so is it fair to say Chromium is free? I think so **for Debian's**, even if it's just a rubber stamp. I also know Debian is pruning many things from (a) but that doesn't prove anything. should distros like Parabola start shipping Chromium right away? no. As Nicolás said, there's more to it than mere files and their licenses (I'm putting privacy concerns aside for a moment): recommending non-free software (or silently downloading non-free modules for that matter), missing source code for the minified javascript. in my estimation, accepting any of these caveats would make Parabola go against the Free System Distribution Guidelines.[2] recommending non-free software is the very reason why Firefox isn't shipped in Parabola either. should Parabola remove Qt-WebEngine, Electron, etc? determining what pieces are going into all the different projects isn't trivial for someone who isn't remotely familiar with the Chromium project. I think the next logical step for me is to learn what Debian is stripping away from (a) plus their build flags, check against (a) itself, then try to compare to projects like Qt-WebEngine and infer from there. For now all I can do is go on a case-by-case basis. for instance, I found instructions for installing Widevine in Electron[2]; which I think are enough to warrant blacklisting. Were that issue addressed in a [libre] package, I would try to look for minified javascript leaking into Electron, or any other such problems. I haven't looked into Qt-WebEngine but other devs have. they could add their own rationale to this thread. [0]: http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000408.html [1]: https://raw.githubusercontent.com/electron/electron/787bc8570382e98c4f204abff05b2af122e5a422/docs/tutorial/using-widevine-cdm-plugin.md [2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] lzo2 virtual package gone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need gpg to verify this message Louis Bettens: > Hey everyone, > > Apologies for coming out of the blue like that, but I encountered a > trivial bug introduced by the last release of lzo while toying with Xen. > > This seems to be due to > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lzo&id=eb70476e9442d349f3c353e91631c0e713781c07, > but despite the fact that this commit is 1yo, it was dormant until Arch > released lzo 2.10-1. > > Attached patch seems to fix it, hope it's of use to you. I haven't done > any tests on that, but I assume it's safe. thank you, your commit was pushed. new tinc-pre and xen releases are in the oven. did you know those were the only 2 packages still depending on lzo2 ? if so, I'm curious as to how you found them when lzo2 was already gone from the package databases. old database backups?, querying package metadata for everything in [libre], [pcr], etc? I had to add a dummy lzo2 to a throw-away repo database before I could point pacman to it and run `pacman -Sii lzo2` -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEONM+8pp2kRNDV2SHM0ZuEux7qUMFAljIWKYACgkQM0ZuEux7 qUP6iBAApPW3/VvVKliILGv3gVQ3nYPnuUkFfYikEUIOsLCSMarZ6I7RPyQTQeXx BX5F+DTT2P1gp8KfDDTqlLonfEQv4ha0tkGLhGv/PCuSxkSZdt/lezX/xSGRKE88 7WxFw6m1Gx6eOrGBvrUIYkf9nX3HlPXK5TQ9bvPt3hDnuk+DWCW8mZW8vIAom118 GU6+ACxuAlP4xjzD9jub28EXktYciag5rZI8SIzfmZUAXsMwwdGuzFn9YQBgmnd1 Oq5ZHhww/KfdCuxwJn6ToMzaQQ7C6DptG0Blgo5b7lFrk7P5BqnEh8dD3ievIN2Q Q5ylkGKs8qAZg9gtPX36pgyXP98e4pi2AizGXd1PJ0GPo9vyRGKG4OjpkD9RaR4V kVUYylUxM3v/NJWFS4LhQf6BXIoG24EGYHHK/HF9A5ywMSLooe1RTD97kpqKTNcN G7TmQoAu7wQIUpXlcaiWLoaiUEKBXcXXllo95oOGZGaaFi1tCP4BDs9qbs0VUTw2 WTKEzIBJ6+VDXdqkUKGLzAD0bagETENyvgrwNKxdtnN2rAzzrE+eDA+dMkwMwaKH yLyPM5Ehwh4BPawAO0K/fWDgEXPxT9EA1HW62jV3B6NFJledXHDShuiijMuhnZg4 ud9SaK9IH8WtHbeVnn1KhD6FWgLsecyzf2WHXKTvqqiQ7xY2s6o= =54UB -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Pubkey for packaging
added to hackers.git, for everyone's information -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Mirror needed in Asia?
Le lun. 6 févr. 2017 à 5:34, Dudumomo a écrit : I am now rsyincing Parabola from Yandex mirror (to avoid overloading the main one) many thanks!, it has been added to the list. our website also performs some statistics on mirrors: https://www.parabola.nu/mirrors/status/ The mirror (HTTP only) is available here: https://mirror.freedif.org/Parabola/ you meant https only, right? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [Maintenance] We had downtime.
Le mer. 1 févr. 2017 à 1:47, Luke Shumaker a écrit : I upgraded Proton. It was supposed to be simple. It wasn't. Rough timeline ( timezone: EST (UTC-05) ): - 23:00:00-ish Both labs and the mailing lists went down, but I only realize that labs is down. - 00:00:00-ish I get labs back up. - 00:55:30 Proton goes down for reboot. - 00:57:45 Proton is back up. - 01:00:00-ish I realize that the mailing lists went down. - 03:35:00-ish I get the mailing lists back up. So, - labs.parabola.nu was down for about 1 hour. - lists.parabola.nu was down for about 4.5 hours. - Everything on proton was down for about 3 minutes (parabola.nu, labs.parabola.nu, lists.parabola.nu, redirector.parabola.nu, and www.parabola.nu). Also, parabolaweb-reporead-inotify.service was restarted at around 21:00 GMT (UTC 0) today (2017-02-02). -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Future of i686
Le jeu. 26 janv. 2017 à 2:50, André Silva a écrit : On 01/25/2017 11:13 PM, Luke Shumaker wrote: Arch just announced that they are phasing out i686 support, and expect to have it totally dropped in November. https://www.archlinux.org/news/phasing-out-i686-support/ Do we want to keep i686 alive past that in Parabola? On one hand, i686 is increasingly obscure. On the other hand, I'd hate to have to stop using my X60 tablet. It's a problem for me since my server is a i686 machine too :S I echo your sentiments. somebody on irc correctly pointed out that some of the i945 thinkpads were sold with core 2 duo, as opposed to core duo, cpus. those are 64-bit, and it should be possible to buy a used chipset and upgrade for cheap. that said, I wouldn't like to turn the back on the wealth of Libreboot-capable i686 machines out there. i686 is kinda mainstream in our circles. With recent discussions of recompiling packages from Arch, and not using their binaries, perhaps keeping i686 alive will be less effort in November than it might be today. +1 With recent discussions about security issues from Arch [0], i think is the time to begin build our distro from scratch with autobuilder or/and a build server (Arch ARM does it to maintain their packages). Could we use winston for it? How's the builder server going [1]? [0]:https://lists.parabola.nu/pipermail/dev/2017-January/004678.html [1]:https://lists.parabola.nu/pipermail/dev/2016-November/004594.html judging from [here] it looks as though some Arch devs really want to see a community effort happen to keep i686 alive beyond November: [here]: https://lists.archlinux.org/pipermail/arch-dev-public/2017-January/thread.html#28666 I have joined the channels Arch has dedicated to the continuation of an unofficial i686 port; they were given in the announcement. irc is rather hollow, but some comments of regret already sparked on the mailing list. No tangible plans so far, though. it would also be nice to patrol the Arch forums. the idea is that we could latch on to, or even join this port; and that would keep Parabola i686 alive with minimal effort. I find building all packages from scratch and automated builds very attractive in the long run, for a number of reasons; not the least of which is not running into broken applications after Arch upgrades a library. I think Winston is a bit overpowered for what it's trusted with right now, but also underpowered so as to build *all* packages with whatever is left from 4 GiB of ram. regarding the build servers that were offered to us, I'm afraid we might have let M.E.W. go away. On the other hand, I brought the topic to Dezponia a couple times after that, and (s)he expects to flesh the last details out soon after FOSDEM. that machine is gonna be a freedom-loving monster; this is the way to go. (s)he has had trouble sourcing the SSDs. maybe we could destine some funds towards completing that server if necessary? -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Website Maintenance
Le mar. 17 janv. 2017 à 14:22, Luke Shumaker a écrit : - www.parabola.nu/packages is not updating since migrating. The solution is to either move www to Winston, or to expose Proton's PostgreSQL to the network (either the Internet, or lvpn (Proton is on lvpn, Winston is currently not) and have reporead run on Winston, talking over the network to Proton's PostgreSQL. There are plans to turn Proton into a proper mirror. No change is necessary if we don't mind waiting between rsync runs to see changes reflected on the web. I vest my support towards this idea in anticipation to a hypothetical discussion. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [libreplanet-discuss] QTWebengine is nonfree
Le lun. 9 janv. 2017 à 15:24, Hanno Böck a écrit : I've read through the entire thread now and tried to follow the links, yet I can't find any evidence for the claim that chromium is nonfree. It could very well be free by now, but only if you are willing to overlook the fact that it's not actually being built from sources. The chromium repository still distributes and uses some object code, instead of the original free libraries. We learned that from the aforementioned ungoogled-chromium patchset. Following [1] I also found otherwise-free javascript that only seems to exist in minified form in the Chromium "source" tree.[2] (Ironically, that page requires nonfree javascript to load, but you could clone the repo and follow the same directory structure). I must say most files reported on [1] are false positives; so it's not indicative of how bad the situation really is. Issues regarding to privacy are imho orthogonal to the free software state of an application, but they shouldn't pose any blocker to using the rendering engine. Orthogonal yet absolutely important, because QtWebEngine is said to contain *all* of Chromium, not just the Blink engine. Even if the freedom problems were fixed soon (they could be), we would still need to worry about Qt (and therefore KDE) possibly subjecting their users to the well-documented Google tracking. Chromium would become one of those rare cases of free software that is also spyware. I'd also want to note that there are good reasons why people want to move from webkit to the chrome rendering engine. Many applications using webkit have been stuck with unfixed security vulnerabilities in the past. The chromium engine is well maintained and generally at the forefront when it comes to security and features in the web. While software freedom is important, it's by far not the only issue that is important when it comes to software ethics. I buy into the unfixed vulnerabilities argument, but the rest is what I would actually deem not only orthogonal, but also irrelevant to the ethical discussion. [1]: https://lintian.debian.org/maintainer/pkg-chromium-ma...@lists.alioth.debian.org.html#chromium-browser[2]: https://cs.chromium.org/chromium/src/third_party/catapult/tracing/third_party/d3/d3.min.js -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Mirror needed in Asia?
Le mar. 29 nov. 2016 à 21:34, Dudumomo a écrit : Hi there, I'm the mirror admin of mirror.freedif.org and I host some projects like Tails, Antergos, etc.. I have some spare bandwidth and space and would be pleased to support your project if needed. The server is based in Vietnam (Ho Chi Minh City) on a 100M connection. If interested, please let me know which server I should rsync and if anything special. Thank you Hi Kari, new mirrors are always appreciated. The whole repo (https://repo.parabola.nu/?noredirect) is taking 127 GB at this moment, but it could peak to as high as 150 (worst case scenario under our current server partitioning), so provision for some extra space if you plan to include everything in your rsync line. In addition to the main server's rsync socket[1] I'm aware of Yandex tier-1 Parabola mirror also offering rsync[2]. The latter is pretty reliable and probably the closest to your location. I don't have much of an opinion about [1], bar my recollections about other mirror maintainers and sysadmins complaining about bandwidth issues. I wish they weighed in before you decide to sync from [1]. If you don't really care what tier your mirror ends up being in, then go with [2] by all means. I think Yandex could safely host more rsyncers. Also, write back with the following information once/if your mirror is ready, to have it added to pacman-mirrorlist and the website: Location: Ho Chi Minh City, Vietnam ? Responsible: some name and email, your GPG fingerprint if available Work hours: Tier (rather, your upstream): Available URLs and protocol information: Any extra notes: [1]: rsync://repo.parabola.nu:875/repos/ [2]: rsync://mirror.yandex.ru:873/mirrors/parabola/ Thanks -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Parabola GNU/Linux-Libre + GNU Calamares installer
Le mer. 30 nov. 2016 à 9:31, Joan-Artur Torras a écrit : Here you can find all the information about “GNU Calamares framework”: [...] And since Calamares in under GNU license Let the control freak inside me clear this up a little bit. This software is new to me, but I can tell it's not a GNU package and its authors don't call it "GNU Calamares" either --quite understandably-- so there's no merit in calling it that way. In case anyone wonders, that doesn't mean Calamares is bad for Parabola or the free software movement; on the contrary. There's a difference between simply using one of the free software licenses offered by GNU (like the nice GPLv3 used by Calamares) and being a package under the official GNU umbrella. All the best -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] No longer receiving mailing list emails
Le lun. 28 nov. 2016 à 16:31, jc_gargma a écrit : Hi. I find myself no longer receiving any emails from the dev@lists.parabola.nu (and ass...@lists.parabola.nu) mailing list(s). I've spoken with my email host, and they haven't received any emails from your domain in a week. I would like to ask if emails sent to me are being bounced, or if there is any other known issues. Thank you for your time. -jc By the time you read this you will have noticed the problem is gone. The issue was on Parabola's side and affected all subscribers. We didn't see this message on time though, precisely because all outgoing email was being retained. In any way, thanks for reaching to us. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] missing libraries
Le mar. 8 nov. 2016 à 15:16, Quiliro Ordonez a écrit : $ blender blender: error while loading shared libraries: libboost_locale.so.1.61.0: cannot open shared object file: No such file or directory [cesar@pc ~]$ Some similar problem has 0AD. Hi Quiliro. A rebuild (blender 17:2.78.agit1.e8299c8-2.parabola2) has been pushed to solve this issue. Mirrors could take some time to reflect the update. 0ad is a different kind of beast because [Community] packages come _as is_ from Arch, so we shouldn't have to update it. I will take a look at it anyway. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [due 2016-10-10]; donations thank you list
Le lun. 3 oct. 2016 à 15:32, fauno a écrit : * Just put the person's name on the thank you list instead of a mention per donation but it wouldn't really mitigate targeted spam if the cost of creating and disposing names is low, would it? I could use a different name every time. Which of the currently accepted systems allow named donors to do this? (Maybe this is not an issue practically speaking). On the other hand some legit donations are driven by recognition, to be blunt. Collapsing records by donor may have an impact on the motivations of some future donors. One plausible solution is to track a donor's name along his/her total contribution and last time of contrubution. I don't think it would place an extra burden on you since that information is already being managed *per donation*. Donors would still risk having their contributions misattributed to a homonym, though. * Keep accounting separately, on an adequate file (a gnu cash file attached to the wiki for transparency). I think separating the "thank you" list from the directions on how to contribute may do some good regardless of medium (distinct wiki pages vs file attachment) and the contents' format (full donations vs grouping by name). However I don't see much of a difference TBH. * Set a minimum donation for appearing on the thank you list (perhaps 10 USD or equivalent? just to fend off publicity) I believe this is a good idea considering the record. With a sample size of 39, the average donation is at ~84 USD as of now (all currencies weighed in). In terms of spreadness, there're only 2 donations below 10 USD or equivalent ---one is close to it, the other is a complete outlier---. Also a generous anon is heavily biasing that average upwards with a 2 BTC contribution, so 84 USD is way too high, but I think we've got a handle to expect future donors not to be alienated by a reasonable minimum quantity. -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [consensus] Features vs. Privacy in nonprism repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Le lun. 3 oct. 2016 à 18:30, Luke a écrit : > - So this puts the nonprism projects at a crossroads. Do we want to favour accessibility and "features" over "privacy"? > > From my personal opinion, nonprism should provide security and privacy by default. Users can choose to opt-out of nonprism if they wish. This is easily done by A) not using nonprism, or B) using about:config and/or user.js to override the settings. > Meanwhile, some users have questioned why nonprism is not on by default[5], and I think this is a valid point from a security standpoint. Users may be using Parabola under the impression they are experiencing the safest possible defaults, and this is currently not the case. [...] > Now that everyone is aware of the issues, please discuss. I do not feel [nonprism] should become "privacy-lite" and libre become "no protection at all". > > Luke Agreed. I'm for having those `nonprism` packages respect the spirit of the repo they belong to, even if that means breaking websites that could undermine user privacy. That's exactly what using `nonprism` entails. The moment you start making concessions the moment better informed users of `nonprism` will complain that hardening isn't nearly as good as it could be. Maybe this is a failure of communication from our part, but I can't think of a simpler and more instructive solution than that post-install notice. Users won't even need to know in advance what they are doing as they activate the repo --- and I say it with some regret ---. I'm also for keeping default Parabola as Arch-like an experience as permitted by the social contract. Translation: I'd rather keep `nonprism` opt-in. - -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 Tox: 0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX8zPzAAoJEDNGbhLse6lDvI4P/1m+ZZDoDsTzcGlaYmdwot5t xkXTdNFZqPpxc58+aXqfeJfr3W3n9gI+6Ot+43GPCDE1nmtLxLZEOGkPX6FSKm9M 344ljEMaodEJ4f83UwlEayVNjHjNsGP3EeoeH6plg4F98wnNcNkp43AwoVtM4FUD zqEQa4rPP6bNoPxqnpBJWPtZj5to1lcSvHlK7jQpSPGM7P5Lf59nWlua+HDMXX4Z ChmTofGk4d0lpjCoIpijuY+Ro8bI/9J+ZEQbNvGbgC6wleUlkk7FKCxIs2OqipMj tD8D7QQEWdGh3rtnJwXxb7RHGMxpBLeRJeOGM6T4DgfzDV8wMLVPotFPINQPFDnX jCE5MkvmT3NYCEkHcBelLillu2LmVzT+eL9ae7cnI2VRt576pq9HNz2J8p5uiWbJ 9MKsq8eYrZYiOJ4dcDn0wEYRx9E9pGYhfLKMkr7RrGuuN8hwSyrwBVLLSh4KxBf/ WHN9viToINx2QBkCMJExA+nm8+ZrfNgogMLF1bUuJ2lrSrjCXbD4gC0TJkru0BFB Bj4iCJcO+mnA33fJqCK2gzmPmNpU6qNHb+1sUaNdowUb8FJaAqbPARWcHHQZ3pVN guEGAGUhbCO7gUSlv3KJcpQ0ZWvM5wCRRXh5GGMz+TvVE2eg84/KIKVBcy/hEVGF YLpprMzGDdEmjCKm4j37 =XBno -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] ARM port updates and RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Le dim. 28 août 2016 à 22:07, Isaac David a écrit : > As promised, I've made a tiny change to the way ARM packages > are imported, in order to keep noise down at > maintenance@lists. It turns out that Arch ARM is using sort > of corrupt .files databases (some entries are missing > signature fields in the desc files). This causes the inotify > service endowed with tracking changes to databases to crash > upon encountering the first corrupt package, and package > contents aren't being filled in in parabolaweb as a result. > Then when an agent tries to access > https://www.parabola.nu/packages/core/armv7h/acl/files (for > instance), django serves an error. [...] > The downside for building > our own databases from scratch is that the script takes > longer to complete. [...] > PD: I don't know if landing the change will automatically > fix package descriptions for all old broken ARM packages. > We may have to repopulate parabolaweb. Here's a quick follow-up for anyone keeping an eye on this issue: Changes were landed in a new dbscripts release and deployed in the server from there; they worked as expected, including the slowdown. Fixing already-corrupt package descriptions did require us to repopulate parabolaweb's armv7h packages, but everything has been smooth sailing ever since. - -- Isaac David GPG: 38D33EF29A7691134357648733466E12EC7BA943 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX2JYIAAoJEDNGbhLse6lDRpgP/A3nrYOh2BFi1O6BQAMWFZBN Xke1SuX3AyEDbX28kg2IwW4VcWlvjIHswEdxR+/vDd4AFPUgKPAYCjUbA+XC5BMm 5zbj/kVMahAJte3HLIfXlz2jogfTEKob41IaCwJSstGTE/G1oyN4igZJBQd/OSO4 qELg2Sw+c5OTWnQSH74yW8BYiyHYwrkfaBzZISqNqabLfR29xTJfS5vMXIa2MIBu Bx7bi6R7Y2aKeRSGFM7x/Ne8Cyh7JKNeK3PDwG+2MGz+rKKW0cauZWBlhxmBBhnY vUe/PeHnt3QuuDsM956FJi9AoVrYepIk5q8vHZQHrkYBEqaf6gt5rX/WBskhwceJ TrN9bC+uNm2xKTzAFYw5bnVioSP4OsqbpNJDM7ihLktzrPMrYN1GOVXiB+fCrWuv vOg7V6MPPyVTXhF2wZGgdnRFeUuoz5dhuW/g7cXTt8c9Kj748VRc6tDOBf2ACa8S WcGBwNoQFzgkgXQPdOrk7EPWrHuP0H8T5KkYQLXjdsK7ZFKuOxeG9SxYEd66PeTp SlPdGfsDa9qC9XoF3MNYbD/pZAhZAzYLZWTnPF7qNwbKrDrstvbuhesxbvuMFO1W o4sjYlzbAlHaBatv49qM3x+lrmawmpvezMdVhGPwIhVsK7d4O0THHFaMnQzdCkos +LrVXNQS50ug0J/h8IX/ =NTcs -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
[Dev] ARM port updates and RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 As promised, I've made a tiny change to the way ARM packages are imported, in order to keep noise down at maintenance@lists. It turns out that Arch ARM is using sort of corrupt .files databases (some entries are missing signature fields in the desc files). This causes the inotify service endowed with tracking changes to databases to crash upon encountering the first corrupt package, and package contents aren't being filled in in parabolaweb as a result. Then when an agent tries to access https://www.parabola.nu/packages/core/armv7h/acl/files (for instance), django serves an error. I didn't merge changes to master yet; they live on a separate branch[1]. A second commit fixes an unrelated low-severity bug in the import scripts that was discovered while working on this. They have been tested on a separate dbscripts+parabolaweb setup[2]. The downside for building our own databases from scratch is that the script takes longer to complete. I welcome alternative solutions and criticisms. I have this feeling that the next item on the list would be constructing import whitelists from x86 packages (hopefully excluding 'any' packages) plus a few essential packages unique to Arch ARM, because those databases are not in good shape. There are some packages that Arch (x86) removed months ago that we still take from Arch ARM. (Yet another issue to inform to them). We can always blacklist nonfree packages as we spot them, regardless of their origin; but maybe we should stick to a single baseline. That would be x86. I worry about losing practical control over our ability to keep Parabola free if we just let packages arrive amok. What do you think? PD: I don't know if landing the change will automatically fix package descriptions for all old broken ARM packages. We may have to repopulate parabolaweb. [1] https://git.parabola.nu/packages/dbscripts.git/?h=isacdaavid/isacdaavid [2] http://178.62.204.135:8000/packages/core/armv7h/acl/files/ - -- isacdaavid GPG: 38D33EF29A7691134357648733466E12EC7BA943 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXw6ZWAAoJEDNGbhLse6lDWF4P/1LLrGWoY1tU0HlzYT35NVzS 9UenoyRIfUW0tcA8vFTqVs3v3+qJMD3+9UfEX05QVyhHzSRBC3lDVO0Pc82uUf1U reY79JVe6324U0cPS3MwqAxPfTja4QrQotOrDor6Sj3+qpcDsJ5iiVP2Abz97MZv GOAaet9k1TQ7dQ9A+njvdbVXPyQ+Lxg3DPom6qLYvuUHIVlC4XmY/Kubi7TuVmzr PNBuNZ5rWLl16hUVZXaCG7BcohUaxaVjD04tXn6t9BsGn56rVbNTQRL6jLBMtlhg XV34aFgXhmC4mCkpyrOj0zwE559VGavzAK7mW0IxafAoGgB24zYPpoenZRPmcLiM 29OTmekPFWz/4DR4yLxdbxRA5tum17/y3xe1DaOy1nPj91t7WLSbStOVCm30ohR3 7ypH4KzxNdk0lJFq/fqqK8iEJbLfnu88vI+CMb7dxry+l3uKiqemszXzPdeKq4QA YkpucC0ka8ld1fDKj1JqAFy90yLKrU4iatR8hcmBFNs+Q7WkcfXXyeg2eiNc2EP0 H2F+buqjUoDZXx8/XUJ947FyLB70JD3Pr23qGyacqhUVMlyM3KzqW7u56XNxVMkj y0b0gv+5HIrjBUe8h7hlYwXEyFgnOZQocU0uF50GdISTCdBMTWOdQHhA8HacnotH D2UmArm2JUR+C/e+pK1Z =lqtd -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Misleading information in EOMA68 news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OK, this sounds like consensus. We have made enough of a fuss over this little thing, https://pad.partidopirata.com.ar/p/parabola-eoma/timeslider#429 is now live. Adonay took care of the last concerns raised by Paul after revision 310. I decided not to touch on the licensing of hardware design files at all, so as to not speculate either way. I would love to see those released in the future, but future-proofing the reliability of this information is more important. The link will still contain the phrase "libre hardware"; I would not like to break it. Thanks all. - -- isacdaavid -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXvnxCAAoJEDNGbhLse6lDf7UQAN6ba9ilW2506CmeLq2L+hzB xKHMRUZKqLF6oLBtHLWpHBtxPBx/Ut106txGaBaco4BE3ITprokeY6d7AXSulpae BvhPW3f9JUHiT6pXsC/HouasbFmk55lEDBYTk1q0VLgdHBkkP9zM9c0qBWGJiFvR orfeg4ITsvbdzLRa9HvMBlf1PtXXL8P7WeJbn0sfMoL7ReqDwzGAj5QHBgMgJ0qw cm2oYqaBmQK7rTueZ6wN/BmP+M4ujU92J8U5QhV1aXzvHKJLmfl8cz0kXzY9Hkrl DYxhKsK7nuFLVb50x/ZL03rkA24riigj4scUmKLf7bKPhcqi/rDirCfIwglGOaGf LJlKsSilbMue+IK3xkUB/ZyFRFXhdRNJWd3PS9EPg1si5KcFLfd3O13hKoxOaHeB vqxbajUNWwgw/NC8+NEVSMR1+TTLUqxSBrMfHuDcRiuESCEoZHnHfmQ5LdHWpM0u 1kgCin6HN85bKpB9x5GJLnb4adpT0qWmPbdlmiBoPWIge3jS7m0jahpo8mEr/h2E +9QZkeVvXY+sNcOEid1zx2qSM5CsSOuQgXN9aac8InyEMbenN+eaF36sNU8WWbZ9 gciBatngyJgRcebqxZMZQDklUV2RA1ITCcMf6OcQi9CMjPFiqalpcjGxvqLpbz5n hGNWpkn4zgGTjPoqC9Qg =q2gb -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [PATCH abslibre] pacman: Get architecture from CARCH instead of auto
Le mar. 23 août 2016 à 4:51, Paul Kocialkowski a écrit : Also, I don't see what problem can arise from this, as it was suggested at: https://labs.parabola.nu/issues/1039 ALARM also hardcodes "armv7h" in the distributed pacman.conf, so there's no specific reason it would cause a problem when migrating. (Or am I perhaps missing something here ?) You should read it as: "Using armv7l as the architecture name in pacman is the KISS solution, but it would cause problems with migrating, etc." instead of "Hardcoding armv7h would cause problems with migrating, etc." ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Misleading information in EOMA68 news
Le mer. 17 août 2016 à 14:16, Isaac David a écrit : I have copied the full Markdown text to a collaborative pad: https://pad.partidopirata.com.ar/p/parabola-eoma Everyone can join and help revise it there, or bring it to this thread plus your changes and comments. either not too many people showed up or it didn't take too many changes to get the wording right. the campaign is almost over but i think this is still worth tightening up, even if just for posterity. if nobody objects to, over the next couple days i'm going to add what is currently on the pad. i'm cc'ing koz, emulatorman and adfeno because they were involved in the drafting of the original news item, if memory serves me right. -- isacdaavid ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [PATCH abslibre] pacman: Get architecture from CARCH instead of auto
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Paul, This was bug https://labs.parabola.nu/issues/1039, thanks for reminding me of it. Were you able to test this configuration? Behind the scenes ALARM (should I say AGLARM?) is also doing some extra sed magic to substitute @CARCH@ with a hard-coded value at build time; so I can almost tell there's no way of using 'auto' or anything equivalent under AGLARM. Pacman does use the value of uname -m with 'auto' though, which raises the question: how did AGLARM come about giving the architecture this name? The hack makes sense for them, because they chose to use a single pacman.conf template for all the architectures they maintain; but we have multiple files, like Arch does, in abslibre and therefore can afford just hard-coding "armv7h" in there. That's exactly what I did. All the best. - --isacdaavid -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXt7A5AAoJEDNGbhLse6lD9fMP/iUS05mSZeNQ+P0okhMMg64j 6hah+ltDUMSeeP1mIl8jaWBsbAnSbd5GFv5eyfMBT1xWpd+YLzbUiAMibWFIBYBL 8aujOEwsFIlBgUBmiRqRPklicjX1WpfEiehF2i//zg6cKoz2/0LG60MiDxlLVPXk 5AZDnSRmVqewlP6GZAy14absv3KcZL2swxq58mZr/b2KZCX0ic82BPpIw8RanoJs 89Lf2ebvNk/PgF1371dXGRafyBnnaLpbhlZDday9b+kNUK7M68wnRZ9dvHqqHT+h TLRkGs8EQ4qkr31f+32YtZDfNqUW185BXc3IyHX5m3QTy+a+ssl1ODFAu2Sc+0tu taNxbCKYtVTXgB6jIX3WaGiQSKdqwGZscsWZaYpIA2pzSyo/Yu4fYnVuPBKQRyHg kOTty+SOPn5n6/QgQuVc73TTsskOt5BPHMyIpWbT0YqVpcarYgbCIuobfJGWT6EL qT/IX7Vst/PHO0s0zS6ex3S5TSiJB+omut0jUgadT8DVMTPZE7y+qKhw5DSXX4RL VqDMPRbic8IOArrC7rDSv3snYPcRreUpX+PIuIcNeJEqN49pYTSjGPGAbZxQeD1P 4CxAQndf8TF6h2M/czkTGfMI22gG0v7gIEZ5xlF8pjof0NW2yKHmfrcbrBoigTc3 mn4+BHMEV7JY8dMyn3tj =jHkV -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Misleading information in EOMA68 news
Le mer. 17 août 2016 à 13:25, Paul Kocialkowski a écrit : Okay so we should try to come up with suggestions for each sentence that I quoted in the first email, that don't use "freedom-friendly" since the consensus is to avoid that term. Any propositions? I have copied the full Markdown text to a collaborative pad: https://pad.partidopirata.com.ar/p/parabola-eoma LibreJS users will notice some scripts are blocked, but it is OK to accept them, they are free like the rest of Etherpad. Everyone can join and help revise it there, or bring it to this thread plus your changes and comments. -- isacdaavid ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [consensus][due: 2016-08-18] change mailman admins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Le jeu. 4 août 2016 à 8:31, fauno a écrit : >hey! i've been mailman admin for a long time and i receive blocked >messages all the time, but i don't have the time myself to decide wether >to approbe them or not, or make necessary changes. > >can someone else volunteer? ideally it should be three persons and none >of them doing anything else for parabola (i'll block emulatorman, coadde >and lukeshu for instance :P) what does it take to moderate a mailing list? I'm not familiar with mailman. Also, what is considered an acceptable response time to approve/reject mails? >this last month i've been trying out rspamd+rmilter and it works really >well. i uploaded them to abslibre/pcr but i don't have a working chroot >to package them. I dared to package them, look them up ;) PD to everyone: I'll also use the occasion to apologise for all the arm-related noise hitting maintenance@lists as of lately. Right now I'm testing a small change to db-import-archlinuxarm that will put an end to those nasty errors; seems to work under my dbscripts+parabolaweb installation. I'll bring your attention back soon, here or at labs, to let you review my solution. - -- isacdaavid -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXsAGTAAoJEDNGbhLse6lDRmIQAIuYRiplizlZXMgSyk917CH3 DjZqbPd8jJ9DuvBMBacfgW8d9748+xnXzfg5KGcZE4J4lg/fPzp4pSQ7ummy4BOY 36AsRZZX6hCCKF55ZdWRFW/0e59HQSqHL62MMEjcCgwdvyOekD+kAVhruIec+oxZ hBn4U8uNs820dRilbKZvdIaTWSDDiRfhwn4yaRfY0GgoqxawCVkbwMrYy0INmHBk q7UxHyy/tUQn4kbOeqVq4DVfIRcm3KzUi6+X7CltdF71loa6A7rVOt6eEC9Az/qP CDH05VmrGbnLZ+RmhfkTZ2jEjPc89zgZDq0x8mkjEQM4FL/Sq7TMDncz+UdbVoeM +gE8UfokPnvoLNd/L5KpLliR0HAIH+Hd9Wg5oRglB2ick9tND4wd4/BpYoMit0E+ nb2gU15dIJ9aQUOBVRUvrdrNO8EHwdjTHEjSPnUCRhHkL4Sxm3+HBXv7Yu+aKXUz Wzf+k/A8NZq5yYwuor9awzTcCoXiw1AcCCUYQFIM6OhnV3Re+Gtu2ibGjZZdBboW DRpju5Z5vLN1Q3W1fyr4mCnKSLOp7Y1N3K7ZRa83agiHCoq21jvc3odH7gUfyrn2 5o3VCMxJEhaOHljA2ot1gOa0Bay7Rlv/QFR+mcaHq6GO+NU8qGd3Z4pvYT7mHd2S 7UdoTEiHYNW6YpPjEJio =slXz -END PGP SIGNATURE- ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] Packages missing on repo?
In addition to Luke's remarks, when using redirector.parabola.nu it's a good idea to have it repeated a few times in a row in your mirrorlist. This is to increase the chances that redirector.parabola.nu will take you to a different Arch mirror that happens to contain the package you requested. Last time I checked there were 10 different Arch mirrors available to redirector.parabola.nu, cycled at the rate of one per second. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [FYI] changes to [repo] HTTP
Now that was a long trail! Thank you for your tireless work Luke. I was wondering, where does that all leave my pseudo-mirror? If I understand your PHP handler correctly my mirror does not figure in repomirror's pool (rightly so because the redirect process could loop indefinitely or something). Do you recommend that I keep caching results from repo using ?noredirect, use repomirror to distribute the load, or move to an entirely different tier-1 mirror? -- isacdaavid ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] fbturbo xorg driver up and running on eoma68-a20 computer card
I pushed a proper package called xf86-video-fbturbo-git to the [pcr] repository. Give it a try. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [consensus][due: 2016-06-24]: New version for Main Page (Parabola Wiki)
Le dim. 19 juin 2016 à 19:37, André Silva a
écrit :
On 06/19/2016 08:51 PM, coadde wrote:
On 06/19/2016 09:31 AM, Florencia Diaz wrote:
It is my proposal for Main page:
TEXT
Welcome to the Parabola wiki!
For a list of articles in this wiki check the Table of Contents.
What is Parabola?
Parabola is a Free Software and Free Culture project aiming to
provide a
fully Free as in freedom GNU/Linux distribution called Parabola
GNU/Linux-libre. It is based on the packages of the Arch (the
GNU/Linux
distribution) and possibly other Arch-based systems, with packages
optimized for i686, x86_64, and armv7h CPUs. Parabola aims to keep
its
package and management tools simple. The primary goal is to give
the
user complete control over their system with 100% Free Software
and Free
Culture. Parabola GNU/Linux-libre is listed by the Free Software
Foundation as a fully Free Software distribution.
Development is focused on a balance of simplicity, elegance,
code-correctness and bleeding edge Free Software.
Its lightweight and simple design makes it easy to extend and mold
into
whatever kind of system you're building.
You can find us on #parabola or mailing list.
General documentation
The Installation Guide will walk you through the process of
downloading
an ISO from our Repositories and installing Parabola
GNU/Linux-libre on
your system. We have separate installation instructions for the
MIPS
(discontinued) and ARM v7 architectures.
If you are running the GNU/Linux distribution of Arch, migrating to
Parabola GNU/Linux-libre is as simple as reconfiguring pacman to
use its
repositories. See the Migration guides for x86 and ARM v7
architectures
for instructions.
Be sure to take a look at the Parabola Social Contract, it guides
us in
all we do.
FAQ
Our frequently asked questions is to provide answers to questions
often
asked by users who moved to Parabola GNU/Linux-libre from the
GNU/Linux
distribution of Arch and other nonfree GNU/Linux ones. It discusses
issues caused by making the system completely Free. For
explanation on
technical details of the system look at Arch FAQ.
###
Source for Parabola Wiki
###
{{i18n|Main_Page}} __NOTOC__ __NOEDITSECTION__
Welcome to the '''[https://parabola.nu Parabola] wiki'''!
For a list of articles in this wiki check the [[Table of
Contents]].
== What is '''Parabola'''? ==
'''Parabola''' is a
'''[https://www.gnu.org/philosophy/free-sw.html Free
Software]''' and '''[http://freedomdefined.org/Definition Free
Culture]
project aiming to provide a fully Free as in freedom GNU/Linux
distribution called '''Parabola GNU/Linux-libre'''. It is based on
the
packages of the [http://archlinux.org Arch (the GNU/Linux
distribution)]
and possibly other Arch-based systems, with packages optimized for
i686,
x86_64, and armv7h CPUs. Parabola aims to keep its package and
management tools simple. The primary goal is to give the user
complete
control over their system with 100% Free Software and Free Culture.
'''Parabola GNU/Linux-libre''' is listed by the
[http://www.fsf.org/
Free Software Foundation] as a fully Free Software distribution.
Development is focused on a balance of simplicity, elegance,
code-correctness and bleeding edge Free Software.
Its lightweight and simple design makes it easy to extend and mold
into
whatever kind of system you're building.
You can find us on {{irc}} or
[http://lists.parabola.nu/mailman/listinfo
mailing list].
=== General documentation ===
The [[Installation Guide]] will walk you through the process of
downloading an ISO from our [[Repositories]] and installing
Parabola
GNU/Linux-libre on your system. We have separate installation
instructions for the [[MIPS Installation|MIPS]]
([https://www.parabola.nu/news/parabola-support-for-mips64el-discontinued/
discontinued]) and [[ARM Installation Guide|ARM v7]] architectures.
If you are running the GNU/Linux distribution of Arch, migrating to
Parabola GNU/Linux-libre is as simple as reconfiguring pacman to
use its
repositories. See the Migration guides for [[Migration From Arch
(the
GNU/Linux distribution)|x86]] and [[Migration from Arch ARM (the
GNU/Linux distribution)|ARM v7]] for instructions.
Be sure to take a look at the [[Parabola Social Contract]], it
guides us
in all we do.
=== FAQ ===
Our [[FAQ|frequently asked questions]] is to provide answers to
questions often asked by users who moved to Parabola
GNU/Linux-libre
from the GNU/Linux distribution of Arch and other nonfree GNU/Linux
ones. It discusses issues caused by making the system completely
Free.
For explanation on t
Re: [Dev] status of icecat for armv7h?
Le dim. 19 juin 2016 à 13:42, Isaac David a écrit : For other armv7h packages that don't need modifications to comply with our free software policies there's also the possibility that they are being pulled from Arch ARM without paying attention to the existence of dependencies that do need intervention, effectively making them look broken on the website. However there aren't many such packages, simply because we have most of the [libre] repo covered. I must clarify they are actually broken, not just according to the website. Pacman won't find the dependencies because we haven't built them yet. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] status of icecat for armv7h?
Le dim. 19 juin 2016 à 8:57, Luke Kenneth Casson Leighton a écrit : [please cc me on replies as i subscribe "nomail" to lists, thanks] folks hi what's the status of icecat for armv7h? it's not listed as an available package for installation, although a ton of stuff that *depends* on it is, such as all the language packs, the ublock plugin etc. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 Greetings Luke, Neither Icecat nor our free version of Iceweasel is available for armv7h. I have tried several times and at some point I managed to build iceweasel, but it soon became out of date and had to be removed from the repos after dependencies stopped being satisfiable. Firefox has a very sensitive buildprocess to say the least. The language packs and plugins are architecture-agnostic; other Parabola package maintainers build them for x86 regardless of our luck with armv7h. This is why you see them listed on the website. For other armv7h packages that don't need modifications to comply with our free software policies there's also the possibility that they are being pulled from Arch ARM without paying attention to the existence of dependencies that do need intervention, effectively making them look broken on the website. However there aren't many such packages, simply because we have most of the [libre] repo covered. This bug report[1] documents our experiences building Icecat and Iceweasel and also contains some necessary patches, should anyone be interested in taking up the baton. For this matter I think user Jookia on IRC is worth reaching to, because if I recall correctly he has natively compiled modern Firefox or a similar derivative for armv7h in the past. Finally I should mention there's no shortage of web browsers for armv7h in our repos. Any browser packaged for x86 other than Icecat/Iceweasel we also have for armv7h, including Iceape (based on Seamonkey). I have tested none of them though. [1]: https://labs.parabola.nu/issues/896 ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le mer. 15 juin 2016 à 22:15, Josh Branning a écrit : I generally take issue with these exceptions, were they in the old version of the Social Contract? Apparently not, here is the history: https://wiki.parabola.nu/index.php?title=Parabola_Social_Contract&action=history Also, are there any instances where these exceptions have already been included in the distribution? Yes, probably for as long as Parabola has been around. The documentation included with many GNU packages is an example of it. Well, to be fair it's only parts of their documentation, but those materials don't permit modification nonetheless. Reflecting this fact in the social contract is an improvement although it may have met some expectations with surprise, precisely because it will stop producing false expectations. This is not to imply the situation may not change in the future. Also, the wording is confusing (perhaps contradictory), namely "All documentation and cultural works included in products of the Parabola project are Free Culture, with the exceptions of" and "All documentation and cultural works created by or for Parabola are Free Culture, with no exceptions." I don't have issues interpreting it. In-house projects are libre without exceptions. Imported projects are subject to the exceptions. At the end of the day all software, fonts, sounds and images in Parabola meet both the FSDG and the Definition of Free Cultural Works as far as I can tell. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [GNU-linux-libre] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le mar. 14 juin 2016 à 22:16, Isaac David a écrit : essentially the same Luke Shumaker's latest version I mean "same as Luke Shumaker's" ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le mar. 14 juin 2016 à 21:09, coadde a écrit : I would give you my proposal based on opinions made by all users in these days here, what do you think guys? Besides adding a link to http://www.gnu.org/licenses/license-list.html#OpinionLicenses and not explicitly mentioning license texts and the GFDL with invariants sections as exceptions to point 2, this version is essentially the same Luke Shumaker's latest version in git. Isn't it? I'm OK with any of these two, but I prefer the mention to license texts. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [libreplanet-discuss] Fwd: Re: [GNU-linux-libre] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le mar. 14 juin 2016 à 8:58, Adonay Felipe Nogueira a écrit : Unless I'm really blind right know (which happens some times), I can't see how the requirements of the Definition of Free Cultural Works are present in the Universal Declaration of Human Rights. Julie never mentioned the UDHR. There's a difference between what each of us thinks human rights should be and what the living document put forth by the UN says. I for one am dissatisfied with articles 16.3, 22, 23.3, 25, 26 (especially 26.3); the wording of 11.1; and finally 27.2, which looks like a vague loophole for further "intellectual property" lobbying and stands in opposition to 27.1 (the one about sharing you mentioned) and the goals of both the Free Software and Free Culture movements. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [libreplanet-discuss] [GNU-linux-libre] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le ven. 10 juin 2016 à 20:18, concernedfoss...@teknik.io a écrit : Arch linux is steadily becoming Systemd/Linux rather than GNU/Linux as systemd gradually, inevitably, rewrites all the various little utilities in it's image. Why does it do this? Why so you can use them (and increasingly other free software projects which now do things the "systemd way") through Serialized Inter Process Communications, which is the very reason for systemd's existance. What does this allow: essentially "linking" GPL'd code by proprietary code because now it's just opening a socket, not actually linking in the compiling sence. Please don't support Systemd/Linux. The GNU/Linux we all used to know and used to have before the hostile takeover of every single big distro by RedHat sock-puppets was much, much, better. GNU/Linux is dying, being killed. You'll need to use the AGPL for everything now soon if you want what you used to have under the GPL. What a jump! This is not the right thread to get your replies, maybe you want to start a new one. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
Re: [Dev] [GNU-linux-libre] [consensus][due: 2016-06-13]: New version for Parabola Social Contract
Le jeu. 9 juin 2016 à 18:54, Luke a écrit : On 06/09/2016 07:46 PM, André Silva wrote: On 06/09/2016 08:08 PM, Riley Baird wrote: What about "Arch (the GNU/Linux distribution)"? +1 I agree with your suggestion because it solves this issue for the Social Contract. If FSF and Arch Team is ok with calling it that, I think it is a good compromise. That way people will know it is the GNU/Linux distro named Arch and avoid the entire naming controversy to begin with. Indeed they use the term "GNU/Linux" to describe their work in a number of places, including the About page and the Forums listing. Sadly, they are not consistent about it and they drop the "GNU" part but not the "Linux" from the actual name of their distribution. That's the name that gets stuck in people's heads. I wouldn't worry about upsetting the Arch developers if Parabola trimmed down the official name of their distro (lots of people do) or if Parabola added the a mention to GNU. I would guess most of them usually pick their terms based on pragmatism or social inertia. They are not ethically invested and wouldn't give a lot of thought to our choices anyway. ___ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev
