From nobody at parabola.nu Mon Mar 7 14:00:42 2022 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 07 Mar 2022 14:00:42 -0000 Subject: [Dev] Orphan Libre package [qt5-styleplugins] marked out-of-date Message-ID: <20220307140042.3710382.93988@winston.parabola.nu> leopold at fajtak.at wants to notify you that the following packages may be out-of-date: * qt5-styleplugins 5.0.0.20170311-32 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/qt5-styleplugins/ * qt5-styleplugins-debug 5.0.0.20170311-32 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/qt5-styleplugins-debug/ The user provided the following additional text: qt5-base 5.15.3 has been released and breaks a dependency for this package. From nobody at parabola.nu Thu Mar 10 00:04:38 2022 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 10 Mar 2022 00:04:38 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20220310000438.3710383.42619@winston.parabola.nu> eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:97.0.2-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ The user provided the following additional text: Firefox source code has been updated to the version 98. As main change, the file downloading behavior has been changed to directly save to default download folder, skipping the dialog of open the file or just download. Options like "always ask" will be reset after upgrade to version 98. Also, there's new tools for DevTools inspector. For more detailed info, please follow the next link: https://www.mozilla.org/en-US/firefox/98.0/releasenotes/ Thanks. From bill-auger at peers.community Sun Mar 13 09:13:55 2022 From: bill-auger at peers.community (bill-auger) Date: Sun, 13 Mar 2022 05:13:55 -0400 Subject: [Dev] rename iceweasel user profile directory from 'firefox' to 'iceweasel' Message-ID: <20220313051355.73e8cf1b@parabola.localdomain> this has been nagging me for some time - while fixing BR #3196, i decided to address it finally the rationale for this change is that, prior to this change, if another 'firefox' is installed in addition to iceweasel, both applications would share a profile, which is not very sane behavior. i added code to the PKGBUILD which should handle the change gracefully and transparently to the user - i do not expect it to cause any problems; but i wanted to get some opinions about it - that code could be removed after a reasonable deprecation period it difficult to know why this was not done way back when; but there is probably no technical reason to avoid doing so - does anyone know of one? i assume that the original rationale was that debian iceweasel did not change it - however, debian probably did not change it, because their iceweasel did not differ much from upstream (and 'iceweasel' was replacing their existing 'firefox') - our does though; and it is only asking for problems, if another 'firefox' is installed, especially if they are different versions for example, currently, if a profile is created/used by a firefox of vN, and later accessed by a firefox of vN-1, the application will not start, unless the user elects to create a new profile - i found a switch to disable that behavior; but it makes more sense to use a dedicated profile for 'iceweasel', to ensure that it is not used/shared with any other 'firefox' variant the original rationale may have also been to ease with migration from arch - the change i added to the PKGBUILD handles that case also (when `which firefox`, the profile is copied instead of moved) From bill-auger at peers.community Sun Mar 13 09:53:31 2022 From: bill-auger at peers.community (bill-auger) Date: Sun, 13 Mar 2022 05:53:31 -0400 Subject: [Dev] rename iceweasel user profile directory from 'firefox' to 'iceweasel' In-Reply-To: <20220313051355.73e8cf1b@parabola.localdomain> References: <20220313051355.73e8cf1b@parabola.localdomain> Message-ID: <20220313055331.134c18af@parabola.localdomain> On Sun, 13 Mar 2022 05:13:55 -0400 bill-auger wrote: > the original rationale may have also been to ease with migration > from arch - the change i added to the PKGBUILD handles that case > also (when `which firefox`, the profile is copied instead of > moved) derp - just realized that would never be the case - by the time 'iceweasel' is installed, 'firefox' has (most likely) been removed by 'your-freedom' From bill-auger at peers.community Tue Mar 15 11:10:21 2022 From: bill-auger at peers.community (bill-auger) Date: Tue, 15 Mar 2022 07:10:21 -0400 Subject: [Dev] iceweasel 98 Message-ID: <20220315071021.7c8dc65d@parabola.localdomain> ive re-worked the patches for iceweasel 98 - it is compiling and runs well - however, multimedia playback has problems; so i will not release binaries yet some websites (eg: youtube) work as expected - others have garbled audio - others will not start at all it could be related to ffmpeg; but its not obvious - the arch package (many of them) now requires a special 'ffmpeg4.4' package - the latest 'ffmpeg' v5 is apparently not well-supported OTOH, there could be is a parabola lib somewhere in the mix, which needs rebuilding - the v97 in the libre has no such problem - curiously though, that was built against the new ffmpeg 2:5.0-5-x86_64 (the one that arch's v98 is avoiding for some reason) - but when i re-built v97 a few days later, i saw similar multimedia problems as v98 has the renaming of the profile directory went well - i also addressed some minor GUI/ branding bugs, such as BR #3196 - however, a new one appeared - the new-tab page somehow has two conflicting logos on it - they both seem to be occupying the same allotted area, which previously shown one full-sized logo, and both have scaled down to fit side-by-side also, duckduckgo is showing me most results in what appears to be russian From pagure at pagure.io Thu Mar 17 17:57:48 2022 From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=) Date: Thu, 17 Mar 2022 17:57:48 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2340=3A_libre/iceweasel=3A_97?= =?utf-8?q?=2E0?= In-Reply-To: Message-ID: grizzlyuser closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel: 97.0 `` https://pagure.io/abslibre/pull-request/40 From pagure at pagure.io Thu Mar 17 18:00:00 2022 From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=) Date: Thu, 17 Mar 2022 18:00:00 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2341=3A_libre/iceweasel_98=2E?= =?utf-8?b?MC4x?= Message-ID: grizzlyuser opened a new pull-request against the project: `abslibre` that you are following: `` libre/iceweasel 98.0.1 `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/41 From bill-auger at peers.community Fri Mar 18 06:39:27 2022 From: bill-auger at peers.community (bill-auger) Date: Fri, 18 Mar 2022 02:39:27 -0400 Subject: [Dev] Fw: iceweasel 98 Message-ID: <20220318023927.66ccd85f@parabola.localdomain> Begin forwarded message: Date: Thu, 17 Mar 2022 20:13:52 +0000 From: grizzlyuser To: bill-auger Subject: Re: [Dev] iceweasel 98 Sorry I didn't see your message before pushing commits to Pagure. I've updated it to 98.0.1, but without your branding changes, and had no problem with multimedia. However I didn't test it much, just opened GNU website and tried to play the video from the top of the page. I just merged whatever changes Arch Linux had (including ffmpeg4.4) and updated / added some new FSDG-related patching. So it looks like ffmpeg4.4 is there for a reason. Had a quick look at your branding changes, and they look good, thank you! From bill-auger at peers.community Fri Mar 18 06:48:28 2022 From: bill-auger at peers.community (bill-auger) Date: Fri, 18 Mar 2022 02:48:28 -0400 Subject: [Dev] iceweasel 98 In-Reply-To: <20220318023927.66ccd85f@parabola.localdomain> References: <20220318023927.66ccd85f@parabola.localdomain> Message-ID: <20220318024828.48637577@parabola.localdomain> the video on the gnu.org home page plays correctly for me too - youtube also - could you try these: on this site, the video plays; but the sound is garbled: https://www.adultswim.com/streams/rick-and-morty on this site, the video page loads but is empty: https://pluto.tv/en/live-tv/the-bob-ross-channel this site is perhaps using one of those cloudflare-like gatekeeper services - i could not even find a video to test - regardless of the URL (even the home page), it redirects to a 500 page: https://therokuchannel.roku.com i compared the difference between the .BUILDINFO in the 97.0.2 in libre (which has no media problems) and the one i compiled a few days later (which has the same media problems as 98) - the only one which popped out at me was 'libvpx' (the VP9 codec) - however, when i compiled v98 against the same 'libvpx' as the libre package, it had the same problems IIRC, i first tried compiling v97.0.2 against the new (old) 'ffmpeg4.4' (the one arch is using, to avoid ffmpeg v5) - although the working package was compiled against ffmpeg v5 - it was worth a try; but there was no change - 'ffmpeg' and 'libvpx' are the most likely culprits (and the only obvious ones); so the available trouble-shooting options are dwindling i am compiling 97.0.2 now, against the previous 'libvpx' - if it has the same problem, i will put it in libre-testing; and i will compile again, with _all_ of the same packages which were installed when the package in libre was compiled in summary: iceweasel 97.0.2 (libvpx=1.11.0-1, ffmpeg=5) -> no problems iceweasel 97.0.2 (libvpx=1.11.0-2, ffmpeg=5) -> media playback problems iceweasel 97.0.2 (libvpx=1.11.0-2, ffmpeg=4.4) -> media playback problems iceweasel 98.0 (libvpx=1.11.0-1, ffmpeg=4.4) -> media playback problems iceweasel 98.0 (libvpx=1.11.0-2, ffmpeg=4.4) -> media playback problems this is the diff between the working published package (97.0.2-1.parabola1) and the problematic on (97.0.2-1.parabola2): $ Untar() { tar xf $1 .BUILDINFO --to-stdout ; } diff <(Untar pkgs/iceweasel-1\:97.0.2-1.parabola1-x86_64.pkg.tar.zst) \ <(Untar pkgs/iceweasel-1\:97.0.2-1.parabola2-x86_64.pkg.tar.zst) 4c4 < pkgver = 1:97.0.2-1.parabola1 --- > pkgver = 1:97.0.2-1.parabola2 6c6 < pkgbuild_sha256sum = 08c77cf2df98458921b4c14337101d9b2402d9c266daf3dd3fb58b68a684f575 --- > pkgbuild_sha256sum = 8de9fee1f603ebe03098376c386f629ffed07bfc57f0bbcc74a807c56a4b96b0 8c8 < builddate = 1646705959 --- > builddate = 1647083243 35c35 < installed = archlinux32-keyring-20220131-1.1.parabola1-any --- > installed = archlinux32-keyring-20220209-1.0-any 63c63 < installed = curl-7.81.0-3-x86_64 --- > installed = curl-7.82.0-1-x86_64 76c76 < installed = fakeroot-1.27-1-x86_64 --- > installed = fakeroot-1.28-1-x86_64 102c102 < installed = gpgme-1.17.0-2-x86_64 --- > installed = gpgme-1.17.1-1-x86_64 112c112 < installed = harfbuzz-4.0.0-1-x86_64 --- > installed = harfbuzz-4.0.1-1-x86_64 214c214 < installed = libvpx-1.11.0-1-x86_64 --- > installed = libvpx-1.11.0-2-x86_64 312c312 < installed = sudo-1.9.9-2-x86_64 --- > installed = sudo-1.9.10-1-x86_64 336c336 < installed = vulkan-icd-loader-1.2.203-1-x86_64 --- > installed = vulkan-icd-loader-1.3.207-1-x86_64 From bill-auger at peers.community Fri Mar 18 07:29:01 2022 From: bill-auger at peers.community (bill-auger) Date: Fri, 18 Mar 2022 03:29:01 -0400 Subject: [Dev] iceweasel 98 In-Reply-To: <20220318024828.48637577@parabola.localdomain> References: <20220318023927.66ccd85f@parabola.localdomain> <20220318024828.48637577@parabola.localdomain> Message-ID: <20220318032901.1c664c10@parabola.localdomain> ok there may be two mysteries here all of the videos i linked in the previous message play correctly in the freshly-compiled iceweasel 97.0.2 with libvpx=1.11.0-1 (the same as the package in libre) - so 'libvpx' was the culprit in that case; and so there is no point in publishing it that does not explain why v98 with libvpx=1.11.0-1 has exactly the same set of problems though; unless it should be compiled against ffmpeg v5 - but if that is even possible, its not clear why arch avoided doing so From grizzlyuser at protonmail.com Fri Mar 18 20:31:41 2022 From: grizzlyuser at protonmail.com (grizzlyuser) Date: Fri, 18 Mar 2022 20:31:41 +0000 Subject: [Dev] iceweasel 98 In-Reply-To: <20220318024828.48637577@parabola.localdomain> References: <20220318023927.66ccd85f@parabola.localdomain> <20220318024828.48637577@parabola.localdomain> Message-ID: I couldn't watch videos by any of 3 links you've provided. The first and the third seem to require JS for playback, which I don't have enabled for most websites, and the second simply said the service is not available in my region. I did however click through a couple of videos on https://yewtu.be and they played just fine. From bill-auger at peers.community Thu Mar 24 10:47:34 2022 From: bill-auger at peers.community (bill-auger) Date: Thu, 24 Mar 2022 06:47:34 -0400 Subject: [Dev] summary of the chromium/electtron/webengine controversy Message-ID: <20220324064734.6876e667@parabola.localdomain> several people have asked about this since 'jami-gnome' was removed from arch - this post is for the sake of a shared "TLDR" reference the chromium web browser is on the "List of software that does not respect the Free System Distribution Guidelines" wiki page[1] - the presence of any software on that list, prevents any distro from being endorsed by the FSF, if it distributes any of the software on that list, without applying an accepted liberation procedure; and puts the ongoing endorsement in jeopardy for any distro which later accepts any of them un-treated - currently, the only accepted liberation procedure for chromuim is: "use icecat" as far as i have been able to determine, this issue affects all web browsers derived from chromium, simply because no one from any of the popular forks i have looked at (such as ungoogled-chromium and iridium) has claimed to address any licensing issues (those projects address only privacy issues) - also, this issue most likely affects all software which includes, or is derived from chromium, qt-webengine, or electron the suspicions surrounding the chromium browser began (AFAICT), within the first week of the release of the *nix port, back in 2009 - the original discussion on the gnu-linux-libre list spanned over two months[2] and was discussed again on several occasions over the years[3][4][5][6][7][8][9]; and a stack of issues has accumulated on the parabola bug tracker[10] from 2009 through to 2012 there was much activity by the chromium team to address these concerns[11]; and then activity petered out - the issue was never officially closed, however the most important factor, which will determine the likelihood of this controversy ever being resolved, is whether the focus is placed on chromium, qt5-webengine, or electron - chromium is an absurdly enormous code-base; and there are not enough people who are willing to do that work - some have tried[12]; but it is probably never going to be completed satisfactorily - electron seems to a hopeless cause for distros[8]; so the only reasonable project to consider, is qt5-webengine - that is fortunate, because qt5-webengine is used by hundreds of programs, making it the one of the three with the greatest impact on distros, by far - to focus on chromium would require orders of magnitude more work, only for that one extra program finally though, even after a satisfying licensing audit of webengine is completed, the code-base would still need to be reconciled with the "ungoogled" treatments, to address any remaining privacy concerns the most recent discussion is a post to the FSDG mailing list[13] from Andreas Grapentin (a parabola team member), who has volunteered to coordinate the effort, once there are some volunteers [1]: https://www.libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser [2] "Status of google chrome and chromium" https://lists.gnu.org/archive/html/gnu-linux-libre/2009-12/msg00000.html [3]: "chromium not free?" https://lists.gnu.org/archive/html/gnu-linux-libre/2011-10/msg00000.html [4]: "Time to recheck Chromium?" https://lists.gnu.org/archive/html/gnu-linux-libre/2012-03/msg00028.html [5]: "QTWebengine is nonfree" https://lists.gnu.org/archive/html/gnu-linux-libre/2017-01/msg00000.html [6]: "QTWebengine is nonfree" https://lists.parabola.nu/pipermail/dev/2017-January/004673.html [7]: "FSF opinion on chromium, QtWebEngine, electron" https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html [8]: "FSF opinion on chromium, QtWebEngine, electron" https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html [9]: "DSFG in perpetuity" https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-04/msg00000.html [10]: "QTWebgine embeds "entire Chromium platform"" https://labs.parabola.nu/issues/1167 [11]: https://bugs.chromium.org/p/chromium/issues/detail?id=28291 [12]: the FSD review of chromium https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1 [13]: "I am starting a review into whether QtWebEngine is free software" https://lists.nongnu.org/archive/html/gnu-linux-libre/2019-04/msg00000.html From bill-auger at peers.community Thu Mar 24 11:22:02 2022 From: bill-auger at peers.community (bill-auger) Date: Thu, 24 Mar 2022 07:22:02 -0400 Subject: [Dev] summary of the chromium/electtron/webengine controversy In-Reply-To: <20220324064734.6876e667@parabola.localdomain> References: <20220324064734.6876e667@parabola.localdomain> Message-ID: <20220324072202.4994ac1b@parabola.localdomain> forgive the "qt5-webengine" typo - the post was cobbled together from several others i have written in the past - this year, it is "qt6-webengine" - next year, it may be "qt7-webengine"; but the "qt" and the version numbers are not germane to this discussion From nobody at parabola.nu Sun Mar 27 20:45:44 2022 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 27 Mar 2022 20:45:44 -0000 Subject: [Dev] Orphan Pcr package [i2p] marked out-of-date Message-ID: <20220327204544.3710385.25278@winston.parabola.nu> cyberdevilnl at protonmail.com wants to notify you that the following packages may be out-of-date: * i2p 1.6.1-1 [pcr] (armv7h): https://parabolagnulinux.org/packages/pcr/armv7h/i2p/ * i2p 1.6.1-1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/i2p/ * i2p 1.6.1-1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/i2p/ The user provided the following additional text: 1.7.0 is available. From nobody at parabola.nu Mon Mar 28 02:32:48 2022 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 28 Mar 2022 02:32:48 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20220328023248.3710385.87827@winston.parabola.nu> eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:98.0-1.parabola7 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ The user provided the following additional text: Firefox source code has been updated to the version 98.0.2 The main changes are bugfixes to the session history access and addons functionality. For more information about that changes, please follow the link below: https://www.mozilla.org/en-US/firefox/98.0.2/releasenotes/ Thanks. From GNUtoo at cyberdimension.org Mon Mar 28 21:25:03 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Mon, 28 Mar 2022 23:25:03 +0200 Subject: [Dev] Migrating Parabola infrastructure from the old server to newtron Message-ID: <20220328232503.561885c1@primarylaptop.localdomain> Hi, I've some questions on the server(s) configuration management. Background information: ----------------------- Since updates are not done for a while on Winston, after some discussions on IRC with Bill Auger, I understood that the current plan was to migrate all the services to Newtron (the new server) instead of trying to fix the situation on Winston. I've started looking into it last week, and I tried to migrate a very simple service (the package redirection service that is done by an nginx configuration file). While doing that I found out a bit how it worked on Winston: - All the files in /etc/ are handled by etckeeper in an almost completely automatic way: files are committed automatically after package installation, at regular interval, etc, and the git repository contains very few commits made by humans. - Part of the files in /etc/ and/or in other parts of the system comes from packages that come from a [config] repository. These packages are generated from a configuration management tool named holo. We currently use a patched version of holo[1]. I think that having the configuration files that are not tied to specific hardware or IP addresses inside packages is a really good idea: it avoids the overlap between package management and configuration management, and it also enables everybody to install the packages and simplify testing and deployment: People can more easily test the packages, generate VM images with the packages, etc. I've started looking into holo but I've not yet managed to understand the full picture yet, so I've some questions on why or how it was done. Questions: ---------- - What is the license of the packages? Is there a way to at least get the configuration files under a free license? There are also scripts like common.sh that lack licenses. Also I didn't found the sources of the files used to generate the package repository, so I would also be interested in that. - Why do we need a configuration management tool to generate the packages? Would migrating the packages generated by holo to more standard PKGBUILDS inside abslibre in a separate config repository be a good idea? So far I found several advantages in doing that: - It would make the packages less obscure: developers that already know how to contribute changes to packages will also be able to contribute changes to the configuration of the Parabola servers in this way. - It will also result in having the configuration mirrored by all the Parabola mirrors so they will be backed up, so if the Parabola main server is destroyed we would for sure find mirrors with that configuration, and the packages will also be signed. - It will also be easier to that configuration in the official Parabola servers, and since it's easier we could also test it more easily in virtual machines or different servers. Contributors could also test things more easily. Because of that I've started working on migrating the packages to abslibre in a branch[2]. I think that I'll end up converting it to more standard packages if the active Parabola developers are OK with that. My changes on Newtron: ---------------------- I've also started added etckeeper for the changes that are very specific to Newtron, like the hostname. I've done it in a completely non-automatic way: none of the commits were made automatically and all the commit messages were written by humans (me). This enables to track changes more easily. I probably need to write a script to generate .etckeeper automatically though from the permissions of the files being tracked, while still enabling humans to override the permissions somehow (for instance to disable a script with chmod -x). As etckeeper wasn't used before that, It's also relatively easy to remove etckeeper and restart from scratch in the same way it was done before if needed. References: ----------- [1]http://holocm.org [2]https://git.parabola.nu/abslibre.git/log/?h=config-repository Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From GNUtoo at cyberdimension.org Mon Mar 28 22:07:56 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 29 Mar 2022 00:07:56 +0200 Subject: [Dev] summary of the chromium/electtron/webengine controversy In-Reply-To: <20220324064734.6876e667@parabola.localdomain> References: <20220324064734.6876e667@parabola.localdomain> Message-ID: <20220329000756.6ebf692b@primarylaptop.localdomain> On Thu, 24 Mar 2022 06:47:34 -0400 bill-auger wrote: > several people have asked about this since 'jami-gnome' was > removed from arch - this post is for the sake of a shared "TLDR" > reference Thanks a lot for the reference. I really hope that at some point we will be able to really know the license of chrome/chromium based source code to solve this for good and/or bury chrome/chromium for good and have compatible API and/or other browsers backends instead. > the chromium web browser is on the "List of software that does > not respect the Free System Distribution Guidelines" wiki > page[1] - the presence of any software on that list, prevents > any distro from being endorsed by the FSF, if it distributes any > of the software on that list, without applying an accepted > liberation procedure; and puts the ongoing endorsement in > jeopardy for any distro which later accepts any of them > un-treated - currently, the only accepted liberation procedure > for chromuim is: "use icecat" The issue with that page is that it's not well maintained. Some information there seem really old and many packages are probably missing. We probably need people to help with that. > as far as i have been able to determine, this issue affects all > web browsers derived from chromium, simply because no one from > any of the popular forks i have looked at (such as > ungoogled-chromium and iridium) has claimed to address any > licensing issues (those projects address only privacy issues) - > also, this issue most likely affects all software which > includes, or is derived from chromium, qt-webengine, or electron That also doesn't seem very relevant by itself: if the issue is fixed upstream, browsers will probably not mention that they did address licensing issues. However as I understand it's really hard to know if it's fixed upstream or not given the huge amount of code and repositories. Android has a similar issue, so we probably need to collaborate in fixing that type of issues in some ways. As I understand, in both cases the build system doesn't have any package definitions and the build outputs aren't packaged in any ways. Instead all the source code is checked out in the same directory and everything is built from that. Though Android somehow generates a license list that is available in the settings. For Replicant 11 I've started making a quick and dirty script to find out the licenses of each repository but I need to improve it, try license scanners, etc. I also plan to document these tools in the libreplanet wiki at some point. When making packages, we really need to indicate the license under which the package is, and different distributions probably dealt with that more or less strictly in the past depending on the distribution. For instance Debian has a reputation of being strict and of finding and removing nonfree software from within packages they have in their main repository. So we can often find information there on new nonfree software being added to various projects. Finding nonfree code is probably also related to the will to do it and also the huge amount of Debian developers compared to other distributions (that we lack in Parabola for instance). I really wonder how distributions dealt with code of unknown licenses in the past. Did they simply remove the packages if the license was unknown. Are there situations in the past where the distribution wasn't under pressure of having something important not working? Do we have precedents where most distributions removed software because of mess like that? I recall that at some point we removed some OpenGL headers in Gnewsense and that at the end the FSF managed to make the author of these headers relicense them under free software. Could we somehow build pressure to have Google make sure that the code is at least legal to redistribute in ways that we can check? > some have tried[12]; but it is > probably never going to be completed satisfactorily - electron > seems to a hopeless cause for distros[8]; so the only reasonable > project to consider, is qt5-webengine - that is fortunate, > because qt5-webengine is used by hundreds of programs, making it > the one of the three with the greatest impact on distros, by far > - to focus on chromium would require orders of magnitude more > work, only for that one extra program We also need to take into account the maintenance of the license checks. We probably don't have enough time and people to review some source code based on chromium for each releases of that code. The ideal situation would be to have that software packaged as it is usually done: by having 1 package per dependency. But here that would probably mean packaging several hundreds or thousands of projects just for a browser that isn't even desirable. And these packages would also need to be maintained. Another option would be to somehow automatize the license checks with license scanners. I also wonder if we can somehow force Google to do that work? Like if there is a lawsuit for instance, would there be a way where it would be up to google to tell us the license and show to us (for instance in a document that shows the correspondence between licenses and files) that they didn't violate any free software license? Also did someone already try to work with upstream to somehow force upstream to put in place a process (similar to process in distributions) where the license are reviewed and licensing information is updated? Or did someone already discussed with upstream about the possibility of doing that? Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From GNUtoo at cyberdimension.org Mon Mar 28 22:47:54 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 29 Mar 2022 00:47:54 +0200 Subject: [Dev] PKGBUILD for gmnisrv In-Reply-To: <20211202142239.0be91f85@parabola.localdomain> References: <20211202170355.3e0a3c30@firemail.cc> <20211202142239.0be91f85@parabola.localdomain> Message-ID: <20220329004754.5513b604@primarylaptop.localdomain> On Thu, 2 Dec 2021 14:22:39 -0500 bill-auger wrote: > there is a package in pcr-testing - could ppl try it, and verify > that it works properly > > i am not impressed with the licensing of this code-base - i see > no indication of the license, other than a GPL file itself - > unlike a permissive license, it is not sufficient to simply drop > a GPL file into a codebase - it must explicitly associated with > some files, somehow - so strictly, i beleive that it is not > licensed at all; because the author reserves the claim that it > was not intended to apply to all portions of the code; because > no part of the codebase states any exceptions to standard > copyright - it just so happens to include a GPL file, for > reasons unknown by any receiver - though it is a petty detail > (the author very likely intended to license it GPL3), parabola > probably should not accept the code-base, as it is The GPL HOWTO[1] has the following explanation for having copyright headers and/or a statement in the README in addition of the COPYING file: > The purpose of a free software license is to give certain rights to > all users of a program. If it is not clear what rights you have given > them, that defeats the purpose. Our practices are designed to avoid > any uncertainty. > > If a program has a copy of a license FOO alongside the source files, > but doesn't have an explicit statement that ?This program is released > under license FOO,? that leaves room for uncertainty about whether > the license FOO applies to the code of that program. So as bill-auger stated, the way to go here is to send a patch upstream to add the license in the README and/or in the headers. That should be relatively easy to do. Then we could simply wait for a new release or add the few patches between the last release and when the license has been clarified. References: ----------- [1]https://www.gnu.org/licenses/gpl-howto.html Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Tue Mar 29 20:01:01 2022 From: bill-auger at peers.community (bill-auger) Date: Tue, 29 Mar 2022 16:01:01 -0400 Subject: [Dev] summary of the chromium/electtron/webengine controversy In-Reply-To: <20220329000756.6ebf692b@primarylaptop.localdomain> References: <20220324064734.6876e667@parabola.localdomain> <20220329000756.6ebf692b@primarylaptop.localdomain> Message-ID: <20220329160101.4fb72f4d@parabola.localdomain> FWIW, my intention was not to re-kindle discussion of "what to do about chromium?" - that should happen in the context of the FSDG - this was mainly because of jami-gnome being removed from arch - several people were curious about the details - i consider the present question for parabola to be: "what to do about jami?" From bill-auger at peers.community Tue Mar 29 21:03:00 2022 From: bill-auger at peers.community (bill-auger) Date: Tue, 29 Mar 2022 17:03:00 -0400 Subject: [Dev] summary of the chromium/electtron/webengine controversy In-Reply-To: <20220329160101.4fb72f4d@parabola.localdomain> References: <20220324064734.6876e667@parabola.localdomain> <20220329000756.6ebf692b@primarylaptop.localdomain> <20220329160101.4fb72f4d@parabola.localdomain> Message-ID: <20220329170300.30926b93@parabola.localdomain> On Tue, 29 Mar 2022 16:01:01 -0400 bill-auger wrote: > "what to do about jami?" i suppose i should have answered that for the mailing list - the answer is not elusive - it has been discussed on the parabola bug tracker since 9 months ago, when jami-qt first appeared in arch, and i invited a jami dev into the conversation, hoping to avoid this eventuality - i also discussed it at length this week in the #jami IRC channel the simplest thing to do for now, is to adopt jami-gnome into PCR, and use it for as long as it is viable, or until the jami devs allow the QT port to be un-googled webengine is used only to offer a popup web page preview, when the mouse passes over a URL in chat - a feature which horrifies privacy-conscious people (ironically IMHO, because those people are jami's target audience) - many people, especially in the libre community, consider any such feature to be a privacy risk - it is too easy to accidentally pass the mouse over one of those URLs - simply moving the mouse, may expose the user to an IP leak, unsavory images, and so on IMHO, that is a completely useless feature - the preview has no interaction, and is so small, that the text is illegible - the only useful information it presents, is whether or not the remote server is responding (but you know, eye-candy, yay!) - if that is all it is used for, the fix should be relatively simple (a few hours tops, to patch-out the web preview feature and re-package it); but i will not be the one to do it quassel has the same feature; and i had to address it when quassel started using webengine - however the quassel developers, fully recognizing that it was an unnecessary feature, which many people would not want at all, made it optional - quassel allows webengine to be replaced by webkit for that feature, or for the feature to be compiled-out entirely IIRC, it does not even need a compile-time option to disable it - if webengine is not found at build time, it falls-back on webkit; and if webkit is not found at build time, the build simply does not compile that feature (in that case IIRC, the runtime checkbox is either not present, or can not be toggled to the "ON" state) - i could be remembering wrong; probably becaue it was so easy to accomplish if all dev teams were so considerate as quassel (ie: "in-tune" with their user-base), very few of the #1167 sub-tasks would have remained open for very long WRT chromium, as far as i am concerned, the fact that the original upstream bug report is still open after 13 years, is enough reason to assume that it has licensing issues, which will never be resolved, nor even identified upstream forgive me if i seem uninterested in discussing it more - i was completely fed-up with discussing this issue three years ago - today, it is ancient history to me - an ugly period from my past, when i wasted a lot of time, and engaged in some rather unfriendly and unproductive disagreements - personally, i would prefer to forget it if the FSDG recommendation is ever to be changed, it will need to be done by people who care about both of ...: A) whether those programs are included in FSDG distros _and_ B) whether inclusion can be justified/reconciled with the FSDG some people care about A, and some care about B; but no one who cares about both has yet volunteered - im not sure of any such person exists i am definitely not in the 'A' group - quassel is the only program i use, which has ever been affected by this; and it was fixed easily - in any case, we have no shortage of IRC clients to choose from - AFAIAC, jami is the only one of the lot, which has any unique value to parabola; so my motivation is very low - life's too short - i have moved on :) From GNUtoo at cyberdimension.org Wed Mar 30 17:26:14 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Wed, 30 Mar 2022 19:26:14 +0200 Subject: [Dev] summary of the chromium/electtron/webengine controversy In-Reply-To: <20220329170300.30926b93@parabola.localdomain> References: <20220324064734.6876e667@parabola.localdomain> <20220329000756.6ebf692b@primarylaptop.localdomain> <20220329160101.4fb72f4d@parabola.localdomain> <20220329170300.30926b93@parabola.localdomain> Message-ID: <20220330192614.305cfe64@primarylaptop.localdomain> On Tue, 29 Mar 2022 17:03:00 -0400 bill-auger wrote: > webengine is used only to offer a popup web page preview, when > the mouse passes over a URL in chat - a feature which horrifies > privacy-conscious people (ironically IMHO, because those people > are jami's target audience) - many people, especially in the > libre community, consider any such feature to be a privacy risk > - it is too easy to accidentally pass the mouse over one of > those URLs - simply moving the mouse, may expose the user to an > IP leak, unsavory images, and so on That is ultra dangerous and probably not FSDG compliant, and it probably violates several privacy laws. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Thu Mar 31 02:13:21 2022 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 30 Mar 2022 20:13:21 -0600 Subject: [Dev] Migrating Parabola infrastructure from the old server to newtron In-Reply-To: <20220328232503.561885c1@primarylaptop.localdomain> References: <20220328232503.561885c1@primarylaptop.localdomain> Message-ID: <87r16ij2da.wl-lukeshu@lukeshu.com> On Mon, 28 Mar 2022 15:25:03 -0600, Denis 'GNUtoo' Carikli wrote: > - Part of the files in /etc/ and/or in other parts of the system comes > from packages that come from a [config] repository. These packages > are generated from a configuration management tool named holo. We > currently use a patched version of holo[1]. Ugg, you're reminding me that I didn't just go AWOL from Parabola, I went AWOL from Holo. I/we should definitely endeavor to get those patches upstream. (I ended up becaming a significant contributor to Holo, but only after I'd already started using it on my Parabola boxes.) > Questions: > ---------- > - What is the license of the packages? Is there a way to at least get > the configuration files under a free license? There are also scripts > like common.sh that lack licenses. Also I didn't found the > sources of the files used to generate the package repository, so I > would also be interested in that. It's https://git.parabola.nu/server/config.git/ I'm the only committer to that repo, but I'm not sure it's accurate to say that I'm the only author--it started out as me "documenting" what was already there on the servers. Also, I don't recall quite what the status of this was, but what I was working toward is that https://wiki.parabola.nu/Hacking:Servers be generated entirely from running `./doc` in that repo. I think it was pretty close, at least for the winston.parabola.nu section. I forget if I ever set up a post-push Git hook for config.git that had it `cd /srv/config.parabola.nu && ./build` or if I manually SSH'ed in and did that whenenver I pushed. Anyway, as far as I am concerned my contribution to config.git is public domain. > - Why do we need a configuration management tool to generate the > packages? Would migrating the packages generated by holo to more > standard PKGBUILDS inside abslibre in a separate config repository be > a good idea? So far I found several advantages in doing that: We aren't using `holo-build`; just the core of Holo--they *are* standard PKGBUILDs. Well, they `source common.sh` which is a few shell functions that I found useful for writing config-oriented PKGBUILDs. Aside: config.git's `./build` script uses `art`; `art` isn't anything terribly special, it's just a tool for conveniently building all of the packages in a directory and sticking them in a pacman repo (it understands not just vanilla PKGBUILDs, but also `holo-build` files, but we don't care about `holo-build` files). So what Holo does for us is provide a pacman post-install hook that gives us a way to patch files owned by other packages. For example, we want to configure the `/etc/collectd.conf` file, but that's owned by the `collectd` package. So `config-parabola-base-collectd.PKGBUILD` instead of including an `/etc/collectd.conf` file which would conflict, includes a `/usr/share/holo/files/10-config-parabola-base-collectd/etc/collectd.conf.holoscript` which is a shell script that takes the stock collectd.conf on stdin and uses sed and awk to emit our modifications to it on stdout. > - It would make the packages less obscure: developers that already > know how to contribute changes to packages will also be able to > contribute changes to the configuration of the Parabola servers in > this way. That should generally still bet true; just that they're in config.git instead of abslibre.git. > - It will also result in having the configuration mirrored by all > the Parabola mirrors so they will be backed up, so if the Parabola > main server is destroyed we would for sure find mirrors with that > configuration, and the packages will also be signed. 1. The *are* included in https://winston.parabola.nu/backup/ (are the backups still encrypted to my GPG key? :grimmace:) 2. And also mirroring config.git should be sufficient for backing these things up. -- Happy hacking, ~ Luke Shumaker From bill-auger at peers.community Thu Mar 31 23:47:09 2022 From: bill-auger at peers.community (bill-auger) Date: Thu, 31 Mar 2022 19:47:09 -0400 Subject: [Dev] Migrating Parabola infrastructure from the old server to newtron In-Reply-To: <87r16ij2da.wl-lukeshu@lukeshu.com> References: <20220328232503.561885c1@primarylaptop.localdomain> <87r16ij2da.wl-lukeshu@lukeshu.com> Message-ID: <20220331194709.04ce363b@parabola.localdomain> On Wed, 30 Mar 2022 20:13:21 -0600 Luke wrote: > 1. The *are* included in https://winston.parabola.nu/backup/ > 2. And also mirroring config.git should be sufficient i think gnutoo's intention is less about backup of live data; but to codify the initial server setup and config, and make it reproducible ("winston in a can") - for that, there are several relevant tools running on winston - i believe gnutoo was asking about holo; because its use was the least understood for example, those backups are generated by duplicity; which i did not bother to mention in our IRC discussion - among those backups is the /etc directory - but in addition to those scheduled backups, etckeeper is also tracking /etc - i suppose because it offers more fine-grained rollback - but the etckeeper store appears to be only local to etckeeper (not under ~/git) - etckeeper supports pushing to a remote repo; but none is defined the last bit is not so important; but as a matter or replicating winston, i suppose that etckeeper and it's store should be included in that "configuration management" laundry list