From wael at waelk.tech Thu Dec 1 13:57:54 2022 From: wael at waelk.tech (Wael Karram) Date: Thu, 01 Dec 2022 15:57:54 +0200 Subject: [Dev] [PATCH][PKGBUILD] Packaging OpenSMTPd-extras script Message-ID: <4221e2694579dd3e191ea603080cc4a7f5ed0072.camel@waelk.tech> Hello, I've attached a patch for the PKGBUILD for opensmtpd-extras. These are a bunch of useful extra scripts and programs useful in conjunction with a running OpenSMTPd server. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-PKGBUILD-for-opensmtpd-extra.patch Type: text/x-patch Size: 2672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From wael at waelk.tech Mon Dec 5 17:08:39 2022 From: wael at waelk.tech (Wael Karram) Date: Mon, 05 Dec 2022 19:08:39 +0200 Subject: [Dev] [PKGBUILD][PCR] wlr-randr Message-ID: <3dcd7dba3be2da33ff5ffe88626704786fa9d28a.camel@waelk.tech> Hello, I've attached a PKGBUILD for wlr-randr to be used in conjunction with any wayland-based compositor utilising wl-roots. This is basically similar in scope to xrandr utils. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Packaging-wlr-randr.patch Type: text/x-patch Size: 1623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From pagure at pagure.io Tue Dec 13 18:42:10 2022 From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=) Date: Tue, 13 Dec 2022 18:42:10 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2366=3A_libre/iceweasel=3A_up?= =?utf-8?q?date_to_108=2E0__upstream_updates?= 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: update to 108.0 upstream updates `` https://pagure.io/abslibre/pull-request/66 From pagure at pagure.io Tue Dec 13 18:43:28 2022 From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=) Date: Tue, 13 Dec 2022 18:43:28 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2367=3A_libre/iceweasel=3A_10?= =?utf-8?q?8=2E0_upstream_updates?= Message-ID: grizzlyuser opened a new pull-request against the project: `abslibre` that you are following: `` libre/iceweasel: 108.0 upstream updates `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/67 From wael at waelk.tech Wed Dec 14 11:25:58 2022 From: wael at waelk.tech (Wael Karram) Date: Wed, 14 Dec 2022 13:25:58 +0200 Subject: [Dev] [PATCH][PKGBUILD][PACKAGING_REQUEST] yambar - X11 and wayland WM bar written in C Message-ID: <0aa756903b259409062eb488b247cfd473309a54.camel@waelk.tech> Hello, I've attached the PKGBUILD patch, not changed much from AUR except adding targets for i686 and armv7h. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-PKGBUILD-for-yambar-an-X11-and-wayland-native-.patch Type: text/x-patch Size: 1909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From wael at waelk.tech Sat Dec 17 10:10:44 2022 From: wael at waelk.tech (Wael Karram) Date: Sat, 17 Dec 2022 12:10:44 +0200 Subject: [Dev] libreboot-utils, moving forward. Message-ID: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> Hello, Seeing as libreboot isn't strictly FSDG-compliant anymore, and since we were using it as a deblobbed coreboot downstream to build the binaries (all of which are still free software) in libreboot-utils; should we simply do a git checkout of the free parts on the build (and that way side-step the blobs - as they are in a separate directory). Does that seem like a reasonable solution? P.S.: This (20221214) release is still a testing release, but better be ready for the stable release coming after it. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From GNUtoo at cyberdimension.org Sun Dec 18 00:42:14 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Sun, 18 Dec 2022 01:42:14 +0100 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> Message-ID: <20221218014214.4cb80d5e@primary_laptop> On Sat, 17 Dec 2022 12:10:44 +0200 Wael Karram wrote: > Hello, Hi, > Seeing as libreboot isn't strictly FSDG-compliant anymore, and since > we were using it as a deblobbed coreboot downstream to build the > binaries (all of which are still free software) in libreboot-utils; > should we simply do a git checkout of the free parts on the build > (and that way side-step the blobs - as they are in a separate > directory). > > Does that seem like a reasonable solution? That is probably not sufficient, if I recall well, some of the files libreboot removes have nonfree software in them. Since that nonfree software will not be removed anymore, we won't be able to use the newer tarballs. I'm already in discussion with other people to continue a libre version of Libreboot. Personally I need that to update the u-boot packages in Parabola, so it's quite urgent for me. Another issue with the tools is that Leah's Libreboot dropped support for some of the boards it supported before like the KGPE D16. And the tools probably work fine with the previous release of Libreboot. So the issue here is that ideally the tools should also be tested against the older release as well because of that. Parabola has a KGPE-D16 so it might be easy to do some quick tests. 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 wael at waelk.tech Sun Dec 18 11:19:57 2022 From: wael at waelk.tech (Wael Karram) Date: Sun, 18 Dec 2022 13:19:57 +0200 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221218014214.4cb80d5e@primary_laptop> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> Message-ID: On Sun, 2022-12-18 at 01:42 +0100, Denis 'GNUtoo' Carikli wrote: > > > Seeing as libreboot isn't strictly FSDG-compliant anymore, and since > > we were using it as a deblobbed coreboot downstream to build the > > binaries (all of which are still free software) in libreboot-utils; > > should we simply do a git checkout of the free parts on the build > > (and that way side-step the blobs - as they are in a separate > > directory). > > > > Does that seem like a reasonable solution? > That is probably not sufficient, if I recall well, some of the files > libreboot removes have nonfree software in them. Since that nonfree > software will not be removed anymore, we won't be able to use the newer > tarballs. Pertaining to the issue of non-free software, it is mainly support blobs and microcode - the tools coming from upstream coreboot as still the same as before. Hence deblobbing and scrubbing the problematic parts isn't hard at all (though it does raise the question of just using upstream coreboot instead anyhow). > I'm already in discussion with other people to continue a libre > version of Libreboot. Personally I need that to update the u-boot > packages in Parabola, so it's quite urgent for me. As for uboot, I am not quite sure what the solution would be - possibly looking at the deblobbing scripts from earlier releases? > Another issue with the tools is that Leah's Libreboot dropped support > for some of the boards it supported before like the KGPE D16. And the > tools probably work fine with the previous release of Libreboot. So the > issue here is that ideally the tools should also be tested against the > older release as well because of that. > > Parabola has a KGPE-D16 so it might be easy to do some quick tests. > > Denis. At least when it comes to the tools strictly on their own; they should generally be release-agnostic, as even on boards that were dropped they should work still (most of them should really work with just about any computer, they're accessing low-level interfaces). -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From nobody at parabola.nu Tue Dec 20 02:09:58 2022 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 20 Dec 2022 02:09:58 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20221220020958.3710385.93693@winston.parabola.nu> eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:107.0.1-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/iceweasel/ * iceweasel 1:107.0.1-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ * iceweasel 1:107.0.1-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 108.0.1. The main feature is the usage of Efficiency Mode for background tabs. Also, the Process Manager now haves a new keyboard shortcut [Shift + Esc]. And the first security update fixes the search engine reset issue. For more information, please go to the following websites: https://www.mozilla.org/en-US/firefox/108.0/releasenotes/ https://www.mozilla.org/en-US/firefox/108.0.1/releasenotes/ Thanks. From GNUtoo at cyberdimension.org Tue Dec 20 06:37:46 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 20 Dec 2022 07:37:46 +0100 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> Message-ID: <20221220073746.36f47727@primary_laptop> On Sun, 18 Dec 2022 13:19:57 +0200 Wael Karram wrote: > On Sun, 2022-12-18 at 01:42 +0100, Denis 'GNUtoo' Carikli wrote: > > > > > Seeing as libreboot isn't strictly FSDG-compliant anymore, and > > > since we were using it as a deblobbed coreboot downstream to > > > build the binaries (all of which are still free software) in > > > libreboot-utils; should we simply do a git checkout of the free > > > parts on the build (and that way side-step the blobs - as they > > > are in a separate directory). > > > > > > Does that seem like a reasonable solution? > > That is probably not sufficient, if I recall well, some of the files > > libreboot removes have nonfree software in them. Since that nonfree > > software will not be removed anymore, we won't be able to use the > > newer tarballs. > Pertaining to the issue of non-free software, it is mainly support > blobs and microcode - the tools coming from upstream coreboot as > still the same as before. Hence deblobbing and scrubbing the > problematic parts isn't hard at all (though it does raise the > question of just using upstream coreboot instead anyhow). The advantage of having a project like Libreboot is that any non-Android distribution can very easily reuse the released tarballs. So if we'd want to add nvramtool in Guix for instance, the libreboot tarballs could be reused. > > I'm already in discussion with other people to continue a libre > > version of Libreboot. Personally I need that to update the u-boot > > packages in Parabola, so it's quite urgent for me. > As for uboot, I am not quite sure what the solution would be - > possibly looking at the deblobbing scripts from earlier releases? I was the de-facto maintainer for the u-boot part in Libreboot. So once the project is setup, I'd just to continue maintaining that part like I did before: I'd push the patch that Leah refused because it deblobbed more u-boot and make a new tarball release. My patch also had issues with reproducible builds, but that's not ultra urgent to fix, so I'll try to find the time to fix that later on. > > Another issue with the tools is that Leah's Libreboot dropped > > support for some of the boards it supported before like the KGPE > > D16. And the tools probably work fine with the previous release of > > Libreboot. So the issue here is that ideally the tools should also > > be tested against the older release as well because of that. > > > > Parabola has a KGPE-D16 so it might be easy to do some quick tests. > > > > Denis. > At least when it comes to the tools strictly on their own; they > should generally be release-agnostic, as even on boards that were > dropped they should work still (most of them should really work with > just about any computer, they're accessing low-level interfaces). Most of them are indeed. I was more concerned about tools like cbmem or nvramtool that have to interact with Coreboot somehow. As far as I know Coreboot doesn't have guarantee that it won't change the interfaces, so it's probably best to at least do a quick test on the Parabola's D16. I have access to it at least (I'm not sure who else does though). The test can probably even done after the packages have been released but it's good to do it to avoid bad surprises. 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 felicien at gnu.org Wed Dec 21 09:35:36 2022 From: felicien at gnu.org (=?utf-8?B?RsOpbGljaWVu?=) Date: Wed, 21 Dec 2022 10:35:36 +0100 Subject: [Dev] browserpass* shouldn't be blacklisted Message-ID: <20221221093536.kyyxlaagfu35lajc@Tuerie> Hi people, I was surprised this morning to read that your-freedom and browserpass (a browser extension for password manager) were in conflict. blacklist.txt says "[uses-nonfree] depends on blacklisted 'firefox'" which is wrong. https://archlinux.org/packages/community/x86_64/browserpass/ > PKGBUILD: > license=('ISC') > depends=('gnupg') > makedepends=('go' 'git') > optdepends=('browserpass-chromium: Chromium extension for Browserpass' > 'browserpass-firefox: Firefox extension for Browserpass') browserpass-firefox works well with Abrowser, it could be renamed. Would you update your-freedom / blacklist.txt? Or tell me how to make the changes myself? Thanks for your work Happy hacking -- ?F?licien Pillot 2C7C ACC0 FBDB ADBA E7BC 50D9 043C D143 6C87 9372 felicien at gnu.org - felicien.pillot at riseup.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wael at waelk.tech Wed Dec 21 10:49:01 2022 From: wael at waelk.tech (Wael Karram) Date: Wed, 21 Dec 2022 12:49:01 +0200 Subject: [Dev] [PATCH] Add fwupd-efi to blacklist Message-ID: <86cbbc1738ba76e6fefa897c99ba636032ae2a2b.camel@waelk.tech> Hello, Today I've noticed issue #3270 opened by gap over 8 months ago on the tracker. And indeed fwupd-efi is available in the repos even though it is mainly used to install non-free system and hardware firmware. I've attached a patch to blacklist it. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-fwupd-efi-to-blacklist.patch Type: text/x-patch Size: 1198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Wed Dec 21 17:09:58 2022 From: bill-auger at peers.community (bill-auger) Date: Wed, 21 Dec 2022 12:09:58 -0500 Subject: [Dev] [PATCH] Add fwupd-efi to blacklist In-Reply-To: <86cbbc1738ba76e6fefa897c99ba636032ae2a2b.camel@waelk.tech> References: <86cbbc1738ba76e6fefa897c99ba636032ae2a2b.camel@waelk.tech> Message-ID: <20221221120958.3158ce23@parabola.localdomain> done From bill-auger at peers.community Wed Dec 21 17:24:14 2022 From: bill-auger at peers.community (bill-auger) Date: Wed, 21 Dec 2022 12:24:14 -0500 Subject: [Dev] browserpass* shouldn't be blacklisted In-Reply-To: <20221221093536.kyyxlaagfu35lajc@Tuerie> References: <20221221093536.kyyxlaagfu35lajc@Tuerie> Message-ID: <20221221122414.5664d1f8@parabola.localdomain> ok lets investigate this $ grep browserpass /code/blacklist/blacklist.txt browserpass-chromium::parabola:1167:[uses-nonfree] depends on blacklisted 'chromium' browserpass-firefox::parabola:2164:[uses-nonfree] depends on blacklisted 'firefox' browserpass::parabola:2164:[uses-nonfree] depends on blacklisted 'firefox' so '2164' indicates that this is documented/discussed on ticket #2164 https://labs.parabola.nu/issues/2164 the ticket is still open - there are multiple plans suggested - the one that i favor (iceweasel provides 'firefox') is nearly ready to be published - it would allow 'browserpass-firefox' to be re-instated as-is is probably fine on it's own; but it's only clients in the parabola repos are browserpass-chromium and browserpass-firefox, both of which are blacklisted > browserpass-firefox works well with Abrowser, it could be renamed. ok but parabola hase no 'abrowser' package' - though it would probably work with iceweasel and icecat also - that would require new packages to be created: 'iceweasel-browserpass' and 'icecat-browserpass' From bill-auger at peers.community Wed Dec 21 17:41:15 2022 From: bill-auger at peers.community (bill-auger) Date: Wed, 21 Dec 2022 12:41:15 -0500 Subject: [Dev] [BREAKAGE][OPENSSL][FDE] OpenSSL3 deprecation of whirlpool breaking FDE on Libreboot In-Reply-To: <22ae5f9976d424fe27a29cff6214b57116dbbd72.camel@waelk.tech> References: <22ae5f9976d424fe27a29cff6214b57116dbbd72.camel@waelk.tech> Message-ID: <20221221124115.5a668669@parabola.localdomain> IIRC, whirlpool "legacy" support has been restored now though? From GNUtoo at cyberdimension.org Thu Dec 22 04:34:26 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Thu, 22 Dec 2022 05:34:26 +0100 Subject: [Dev] Criteria beyond FSDG compliance for Parabola and third party repositories? Message-ID: <20221222053426.0ba5c22d@primary_laptop> Hi, There has already been extensive discussion on third party repositories used by Parabola in the bug #1035[1], but I think it would be a good idea to separate the discussion about a policy and the actual work being done (for instance to remove pip, rubygems, etc). The FSDG[2] has the following: > Nor should the distribution refer to third-party repositories that > are not committed to only including free software; even if they only > have free software today, that may not be true tomorrow. Programs in > the system should not suggest installing nonfree plugins, > documentation, and so on. So there is work in progress (that is tracked in the bug #1035 and in other bugs) to either fix or remove software that use repositories that have no commitments to include only free software. The question is if Parabola should add policies that go further than that or not. As I understand Parabola already has these additional policies: - The FSDG allows non-functional data (like game data for instance) under nonfree licenses if the license enable to copy and redistribute for commercial and non-commercial purposes. Parabola instead requires free licenses for non-functional data as well. I've no idea what the policy of other FSDG compliant distribution is with that. - The packages needs to be built from source. Arch Linux often include binary files for Java programs in its packages for instance. Parabola has to remove or replace them with versions built from source. - ARM computers officially supported by Parabola need to have some documentation in the Parabola wiki and to be able to boot with free software that is provided by Parabola (so if an ARM computer has a nonfree bootloader, it won't be supported officially). I am also unsure if Parabola also has a rule that requires to have very precise licensing information or not[7]? For instance if a software has a given license (like the "expat license") but brings a lot of dependencies under other licenses, do we need to list all the licenses in a way that is maintainable (for instance list what is covered by what license, like bsd-2-clause for this project, bsd 3-clauses for this file, this modified X11 license for that file, etc). For examples of distributions where it's not the case, both Replicant[4] and Guix[5] allow less precise licensing information. Other FSDG compliant distributions also have their set of policies which differ. For instance unlike Parabola, Trisquel and PureOS probably have rules requiring to recompile package from the upstream distribution. Guix probably forbids cyclic dependencies (all the compilers are bootstrapped, sometimes from binaries though), where in Parabola gcc depends on gcc. Replicant requires the supported devices to have a removable battery and to have an isolated modem to prevent the modem from being able to take full control of the device. If for instance we decide in Parabola that all the third-party repositories should follow the same rules than Parabola, then we will probably end up having to remove all the software that is configured to use third party repositories, or at least disable the repositories. The good side is that all software installed through Parabola will adhere to the same set of criteria, so if we make the criteria clear, users will have more consistency. Though we might have to remove packages like "guix" (it needs to be updated though), "guix-installer" (it's trivial to update), "debootstrap" (it can install Trisquel, PureOS, and older distributions like Gnewsense), and maybe software like "gnome-box" too if it can still download FSDG compliant distributions (it's currently broken on x86_64 so I could not check). We also have packages that makes it possible to install Hyperbola GNU/Linux (hyperbola-archlinux-keyring hyperbola-keyring hyperbola-mirrorlist hyperbola-pacstrap-config). For browser addons, Parabola builds them so users won't be affected. Another option would be to stick to the FSDG for third party repositories and somehow inform users that different FSDG compliant distributions have different policies (for instance by documenting that on the Libreplanet wiki, and mentioning it in the Parabola wiki[6]). Parabola has a document that explains what users should expect of it[6], so in any case we can explain users what Parabola protects against and what it doesn't protect against. For instance, in a lot of cases Parabola will run nonfree software without asking users about it, but it will not ship nonfree software. Personally I would prefer if we keep FSDG compliant repositories as I joined Parabola to work on packages like debootstrap, and a big part of my work was in this area. The result is that Parabola x86_64 is probably the FSDG compliant distribution that can install the biggest number of other FSDG compliant distributions[3] (through programs like debootstrap, pacstrap, Guix commands, etc). In all these cases, the signatures are checked, so users don't take unnecessary security risks when installing another distribution or package manager with these tools. Though at the end of the day I also need some clarity on the actual and future policies of Parabola to know in which areas It's a good idea to spend my time on, and in which cases a Parabola package needs to be removed and/or replaced. So whatever decision is taken, I think that the outcome will be beneficial anyway. And at the end of the day I can still do that work in other distributions like Guix (though it would require more work to bring in pacstrap and so on) if Parabola doesn't want that kind of work. References: ----------- [1]https://labs.parabola.nu/issues/1035 [2]https://www.gnu.org/distros/free-system-distribution-guidelines.html [3]https://libreplanet.org/wiki/Group:Software/research/CrossDistroBootstrap [4]The Android build system doesn't use package definition, so the license of each component is in its git source code, so it's a mess. There has been various attempt to fix it though, but it's not as urgent as other things like fixing an FSDG compliance bug on Replicant 6.0 or making the new Replicant version usable. [5]Matterbridge was added to Guix knowing that it bundled about 500 dependencies that weren't in Guix. I've checked most of them on an older version of matterbridge but not all of them and so far I didn't find any nonfree software, so it's probably OK. [6]https://wiki.parabola.nu/How_does_Parabola_protects_users_against_nonfree_software [7]I've looked at Chromium in the blacklist repository, and apparently it's blacklisted because it "links to proprietary plugins" and has "unattended phone-home queries" and is "not entirely built from sources". So since something like "not precise enough license" isn't mentioned, I'm unsure about the status of a policy like 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 wael at waelk.tech Thu Dec 22 09:04:43 2022 From: wael at waelk.tech (Wael Karram) Date: Thu, 22 Dec 2022 11:04:43 +0200 Subject: [Dev] [BREAKAGE][OPENSSL][FDE] OpenSSL3 deprecation of whirlpool breaking FDE on Libreboot In-Reply-To: <20221221124115.5a668669@parabola.localdomain> References: <22ae5f9976d424fe27a29cff6214b57116dbbd72.camel@waelk.tech> <20221221124115.5a668669@parabola.localdomain> Message-ID: On Wed, 2022-12-21 at 12:41 -0500, bill-auger wrote: > IIRC, whirlpool "legacy" support has been restored now though? Yes, indeed, openssl1.1 is what solved it. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Thu Dec 22 22:08:52 2022 From: bill-auger at peers.community (bill-auger) Date: Thu, 22 Dec 2022 17:08:52 -0500 Subject: [Dev] Criteria beyond FSDG compliance for Parabola and third party repositories? In-Reply-To: <20221222053426.0ba5c22d@primary_laptop> References: <20221222053426.0ba5c22d@primary_laptop> Message-ID: <20221222170852.434f22d5@parabola.localdomain> On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > The question is if Parabola should add policies that go further i am generally on-board with that - i suggested a policy review and revisions about a year ago On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > I am also unsure if Parabola also has a rule that requires to have very > precise licensing information or not[7]? only the PKGBUILD license=() array - i think that should reference licenses of _whatever_ is in the parabola source package (*-src.tar.xz) On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > unlike Parabola, Trisquel and PureOS probably > have rules requiring to recompile package from the upstream > distribution. im pretty sure that Trisquel and PureOS are both > %90 packages imported from their respective upstereams, same as parabola another point comes to mind though - as distros near 100% "reproducible", the motivation and value of rebuilds changes, from avoiding to trust the upstream via redundant effort, to a verification of the upstream package globally, across all debian downstreams On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > If for instance we decide in Parabola that all the third-party > repositories should follow the same rules than Parabola, then we will > probably end up having to remove all the software that is configured to > use third party repositories, or at least disable the repositories. luckily, the abrupt ejection of pip and rubygems has cause minimal damage - the remaining others are much less popular On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > Parabola has a document that explains what users should expect of > it[6], so in any case we can explain users what Parabola protects > against and what it doesn't protect against. > > [6]https://wiki.parabola.nu/How_does_Parabola_protects_users_against_nonfree_software maybe freemor will like to look that over and/or improve or expand that article - freemor has been the most adamant about that aspect of parabola - explaining the rather low limitations, to how any distro can protect its users, especially debunking the common security paranoia support questions (such as: each user must define a "threat model" and be somewhat vigilant - the distro can not do that those things for everyone) not to mention that that parabola as a power-user distro, does not really want protect the user from oneself - i think myself and freemor agree, the "take-home message" should be "Parabola protects users primarily, by teaching them how to protect themselves, and providing clean tools and a clean base environment in which to do so" parabola users even need to know how to protect themselves against parabola (learn about makepkg, keep a liveISO and learn about pacstrap, etc) - there are no guarantees from parabola or any upstream - this month has been a specially wild ride - parabola has been broken in 3-4 rather serious ways this month - probably every parabola user hit at least one snag this month over-all, some "Parabola 101" primer would be helpful - eg: to update the obsolete "beginners guide" - ie: "what parabola can do for users" is a much shorter list and is less important than "what parabola users can (and must) do each for oneself" On Thu, 22 Dec 2022 05:34:26 +0100 Denis wrote: > Personally I would prefer if we keep FSDG compliant repositories the difficulty is in how to determine which repos are FSDG compliant repositories, when none of them have that as a goal - the haskell repo strive to be OSI-compliant - that is perhaps close enough - but i expect a very short list in the end: * debian * guix * haskell * hyperbola * pureos * trisquel that could be the complete list already From bill-auger at peers.community Fri Dec 23 00:41:23 2022 From: bill-auger at peers.community (bill-auger) Date: Thu, 22 Dec 2022 19:41:23 -0500 Subject: [Dev] Criteria beyond FSDG compliance for Parabola and third party repositories? In-Reply-To: <20221222170852.434f22d5@parabola.localdomain> References: <20221222053426.0ba5c22d@primary_laptop> <20221222170852.434f22d5@parabola.localdomain> Message-ID: <20221222194123.26b42cb5@parabola.localdomain> On Thu, 22 Dec 2022 17:08:52 -0500 bill-auger wrote: > "Parabola > protects users primarily, by teaching them how to protect > themselves, and providing clean tools and a clean base > environment in which to do so" with the caveat: ... but some of those tools may be sharp! - we like 'em that way! From GNUtoo at cyberdimension.org Fri Dec 23 08:53:55 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Fri, 23 Dec 2022 09:53:55 +0100 Subject: [Dev] Users vs distro responsability, Was: Criteria beyond FSDG compliance for Parabola and third party repositories? In-Reply-To: <20221222170852.434f22d5@parabola.localdomain> References: <20221222053426.0ba5c22d@primary_laptop> <20221222170852.434f22d5@parabola.localdomain> Message-ID: <20221223095355.399e147b@primary_laptop> On Thu, 22 Dec 2022 17:08:52 -0500 bill-auger wrote: > not to mention that that parabola as a power-user distro, does > not really want protect the user from oneself - i think myself > and freemor agree, the "take-home message" should be "Parabola > protects users primarily, by teaching them how to protect > themselves, and providing clean tools and a clean base > environment in which to do so" I've another point of view on that which probably ends up with more or less the same result. Basically for me it's more about finding ways that can work: - For instance, it would be almost impossible for individual users to take a non-FSDG compliant distribution (like Gentoo or Arch Linux for instance) and manage to use it in an FSDG compliant way. If they try to do that they would basically have to do the same work than other FSDG compliant distribution do, and given the amount of work, it's probably not doable by a single person completely alone. So here we do need collaboration, and so having certified distributions where people can report FSDG compliance issues and also participate to help fix them can more or less work (with the caveat that things aren't perfect, but we can at least work to improve the situation). - In another hand we cannot make an alternate internet with FSDG versions of everything, so here teaching users that they are on their own is better. So I think there is a bit of both, some things are best done in the distribution, some are best done through education, other through certification (like RYF), and it's often a good idea when trying to fix a problem to see where work to fix it need to happen. And in many cases we need to combine multiple things (like certification + distribution work + education) to make it manageable for people. > maybe freemor will like to look that over and/or improve or > expand that article - freemor has been the most adamant about > that aspect of parabola - explaining the rather low limitations, > to how any distro can protect its users, especially debunking > the common security paranoia support questions (such as: each > user must define a "threat model" and be somewhat vigilant - the > distro can not do that those things for everyone) Part of it is probably due to the fact that we do not have an infinite number of contributors with an infinite amount of time, and part of it is also because security is very subjective. Here too, the distribution could decide which part of the security it's responsible for and which part it's not by educating users. For instance: - Some security solutions are transparent to most users, like compilation flags such as -fstack-protector-strong. So if these security solutions are lightweight enough, a distribution can decide to be a little more slow in exchange for more security against some classes of attacks. And generally speaking free software contributors can contribute in that area. Distributions also do similar tradeoffs for other cases anyway (like use zstd vs xz for packages). - Some security solutions have other tradeoffs than speed vs security, and there it does really require a threat model for each users or at least for classes of users. For instance, Parabola could add support for some boot integrity protection on some ARM devices (like the USB armory for instance), but the downside is that the user could be locked out of their own devices if they loose the key signing the bootloader for instance. So we can't take a decision like that for our users if the distribution is meant to be general purpose enough. Another example would be to have a public computer without passwords at a location where multiple people live and trust each other, and enable anyone to fix things when there are problems. So having a way to disable passwords can also be useful there. Another example is that "users shound't write passwords on paper" works best for companies and not necessarily for individuals that can in some cases rely on the safety of the places they live in. And here the distribution is not involved in that. For all these cases, user education (if you enable boot integrity protection you'll most likely break your device) + good documentation (how to disable passwords) can work + some light threat modeling (what happens if my computer is stolen?) can probably work for many situations. > parabola users even need to know how to protect themselves > against parabola (learn about makepkg, keep a liveISO and learn > about pacstrap, etc) - there are no guarantees from parabola or > any upstream - this month has been a specially wild ride - > parabola has been broken in 3-4 rather serious ways this month - > probably every parabola user hit at least one snag this month > > over-all, some "Parabola 101" primer would be helpful - eg: to > update the obsolete "beginners guide" - ie: "what parabola can > do for users" is a much shorter list and is less important than > "what parabola users can (and must) do each for oneself" What about [[Parabola survival guide]]? - It would tell how to reinstall Parabola in case something goes wrong. It would also have advise for different use cases, like for people that don't want to use liveISO we'd advise to have more than one Parabola installation on the computer. We'd could also add tips for installing pacman-static etc there. - It would also tell what the users need to know about to stay safe (like update often). - It would point to other articles for more in depth knowledge. The article [[How does Parabola protects users against nonfree software]] is more for potential users to understand what Parabola protects against, and for end users, and also for contributors (like bug reporters and people sending PKGBUILDs or patches) to understand what is and isn't a bug. For instance if a given person has this article in mind, she might not send a bugreport anymore about removing all the web browsers because Facebook isn't a free network service, or for removing software interacting with iphones because the iphone (technically another computer) runs nonfree software. Some users might be able to survive using Parabola without knowing how it protects them against nonfree software, but they'd absolutely need to know how to repair it, how to keep the system updated, etc. So having both separate, and maybe use a tiny subset of [[How does Parabola protects users against nonfree software]] in [[Parabola survival guide]] might work best. 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 Fri Dec 23 09:05:16 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Fri, 23 Dec 2022 10:05:16 +0100 Subject: [Dev] Criteria beyond FSDG compliance for Parabola and third party repositories? In-Reply-To: <20221222170852.434f22d5@parabola.localdomain> References: <20221222053426.0ba5c22d@primary_laptop> <20221222170852.434f22d5@parabola.localdomain> Message-ID: <20221223100516.5465e384@primary_laptop> On Thu, 22 Dec 2022 17:08:52 -0500 bill-auger wrote: > the difficulty is in how to determine which repos are FSDG > compliant repositories, when none of them have that as a goal - > the haskell repo strive to be OSI-compliant - that is perhaps > close enough - but i expect a very short list in the end: > > * debian > * guix > * haskell > * hyperbola > * pureos > * trisquel > > that could be the complete list already That simplifies things a lot. Thanks a lot. Personally I often end up having to use multiple FSDG compliant distributions for a reason or another[1] while contributing to free software projects, so I also want to enable other people to relatively easily use all these distributions if they already use one FSDG compliant distribution. References: ----------- [1]Like deploying infrastructure (Trisquel), building Replicant (Specific Trisquel versions), building projects in containers for making it easier for contributors (guix), running automatic tests (guix), working with Replicant images (Parabola), etc. 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 felicien at gnu.org Fri Dec 23 17:03:30 2022 From: felicien at gnu.org (=?utf-8?B?RsOpbGljaWVu?=) Date: Fri, 23 Dec 2022 18:03:30 +0100 Subject: [Dev] browserpass* shouldn't be blacklisted In-Reply-To: <20221221122414.5664d1f8@parabola.localdomain> References: <20221221093536.kyyxlaagfu35lajc@Tuerie> <20221221122414.5664d1f8@parabola.localdomain> Message-ID: <20221223170330.ypxmgrurarnplcik@Tuerie> On Wed, Dec 21, 2022 at 12:24:14PM -0500, bill-auger wrote: > so '2164' indicates that this is documented/discussed on ticket #2164 > https://labs.parabola.nu/issues/2164 Oh, thank you for explaining. > the one that i favor (iceweasel provides 'firefox') is nearly ready > to be published - it would allow 'browserpass-firefox' to be > re-instated as-is Perfect then. > > browserpass-firefox works well with Abrowser, it could be renamed. > > ok but parabola hase no 'abrowser' package' - though it would > probably work with iceweasel and icecat also - that would require > new packages to be created Yes that's what I meant (I mixed up Trisquel and Parabola sorry), so it works with Iceweasel. Just need to modify the path, or ln -s /usr/lib/{firefox,iceweasel}/browser/extensions/browserpass at maximbaz.com.xpi) Maybe I will do the work if I take the time to read the docs. Have a nice year-end -- ?F?licien Pillot 2C7C ACC0 FBDB ADBA E7BC 50D9 043C D143 6C87 9372 felicien at gnu.org - felicien.pillot at riseup.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bill-auger at peers.community Fri Dec 23 19:39:00 2022 From: bill-auger at peers.community (bill-auger) Date: Fri, 23 Dec 2022 14:39:00 -0500 Subject: [Dev] browserpass* shouldn't be blacklisted In-Reply-To: <20221223170330.ypxmgrurarnplcik@Tuerie> References: <20221221093536.kyyxlaagfu35lajc@Tuerie> <20221221122414.5664d1f8@parabola.localdomain> <20221223170330.ypxmgrurarnplcik@Tuerie> Message-ID: <20221223143900.2fbcae4e@parabola.localdomain> thanks - help is always appreciated it is not a simple problem - i suspect that neither a symlink nor hard-link would work - the problem is that if 'firefox' is installed during migration from another arch to parabola, 'iceweasel' will replace 'firefox'; but the arch firefox extensions would remain installed under /usr/lib/firefox/ it is not yet clear if the plan is feasible, nor if the full combination of conflicts/replaces/provides, behaves as i suppose this plan is ripe for exposing and creating bugs - eg: if any add-on running under iceweasel stores config to ~/.mozilla/firefox, that add-on may be borked the build already migrates ~/.mozilla/firefox to ~/.mozilla/iceweasel; but it was intended to be temporary - it may need to be adopted permanently to leave that symlink behind after migration over-all, it may be tricky to allow other (user-installed) firefox variants to co-exist, without shared/conflicting configuration, some trivial but fatal mis-configurations, like a confused $MOZ_APP_NAME env var, etc however if it works, the larger benefit would be that all, or most currently packaged (and blacklisted) arch packages, could be dropped from the blacklist at once, and all would "just work" From bill-auger at peers.community Sat Dec 24 16:55:34 2022 From: bill-auger at peers.community (bill-auger) Date: Sat, 24 Dec 2022 11:55:34 -0500 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221218014214.4cb80d5e@primary_laptop> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> Message-ID: <20221224115534.289a64f3@parabola.localdomain> On Sun, 18 Dec 2022 01:42:14 +0100 Denis wrote: > Since that nonfree > software will not be removed anymore, we won't be able to use the newer > tarballs. > > I'm already in discussion with other people to continue a libre > version of Libreboot. that could be a mksource PKGBUILD - parabola could provide a pre-cleaned source-ball; but those patches would be carried and maintained forever, so that solution is essentially soft-forking libreboot > for some of the boards it supported before like the KGPE D16. ok, now i am more convinced that the new libreboot direction is not well aligned with parabola - AFAIK, the D8 and D16 are the only powerful servers which can boot the original no-blobs libreboot; and these are libreboot's only significant targets besides thinkpads - if such important targets are no longer supported, i would be inclined to put the entire project into maintenance-mode, rather than shifting the meaning of "libre" to accommodate the ever-worsening lost cause that is x86 - does libreboot support any other than x86? - maybe it's day has passed, and it is just not needed any more put another way, it just seems that x86 precludes "moving forward" in a libre direction - to me, "moving forward" means looking away from x86 toward ARM, RISCV, and POWER9 - at least those arches are trending toward libre-friendly, rather than away From GNUtoo at cyberdimension.org Sun Dec 25 22:01:51 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Sun, 25 Dec 2022 23:01:51 +0100 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221224115534.289a64f3@parabola.localdomain> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> Message-ID: <20221225230151.15c06130@primary_laptop> On Sat, 24 Dec 2022 11:55:34 -0500 bill-auger wrote: > On Sun, 18 Dec 2022 01:42:14 +0100 Denis wrote: > > Since that nonfree > > software will not be removed anymore, we won't be able to use the > > newer tarballs. > > > > I'm already in discussion with other people to continue a libre > > version of Libreboot. > > that could be a mksource PKGBUILD - parabola could provide a > pre-cleaned source-ball; but those patches would be carried and > maintained forever, so that solution is essentially soft-forking > libreboot Why not continuing to maintain our FSDG compliant version of Libreboot instead? I'm already in discussion with people to do exactly that. It might take a bit of time since we're setting up infrastructure and so on (some stuff is still missing, we need a space for releases for instance). We'll announce it officially as soon as we can accept and review contributions. The (old) Libreboot code works already. And it enables cross distribution collaboration too, so I don't see why we need to reinvent the wheel here. Leah's Libreboot won't do anymore the deblob work for us, and distributions need deblobbed Coreboot tarballs. So instead of doing the deblob inside the distribution, I think it makes more sense to do it in an upstream project to have to do it only once. This works well for projects like linux-libre, and the work on distributions side is minimal. For instance for u-boot I'm not going to go fix every FSDG compliant distribution out there but I can provide something easy to reuse, especially when most of the work is done already. If recent coreboot deblobbed tarballs are needed, we could do something similar than with u-boot-libre and add a script (in libreboot) that deblobs each coreboot releases as well and we'd release the script, the blob list and cleaned up tarballs. This way this deblob code could also be reused by our FSDG compliant Libreboot version and everyone will benefit without having to reinvent the wheel for each distribution. And if new files containing blobs need to be deleted, we could simply add them to our version of libreboot, and do a release and just have the distribution bump the package revisions. This system is already in place for u-boot in Parabola, so we have a real example that we can look at. > > for some of the boards it supported before like the KGPE D16. > > ok, now i am more convinced that the new libreboot direction is > not well aligned with parabola We don't need to follow Leah's decisions, we can simply maintain our own version of Libreboot. I'm in discussion with people to do exactly that. So it's just a matter of time until we can announce things and start accepting contributions. > - AFAIK, the D8 and D16 are the > only powerful servers which can boot the original no-blobs > libreboot; and these are libreboot's only significant targets > besides thinkpads - if such important targets are no longer > supported, i would be inclined to put the entire project into > maintenance-mode, rather than shifting the meaning of "libre" to > accommodate the ever-worsening lost cause that is x86 - does > libreboot support any other than x86? - maybe it's day has > passed, and it is just not needed any more We have plans to continue supporting all of these. We might need help with testing though. > put another way, it just seems that x86 precludes "moving > forward" in a libre direction - to me, "moving forward" means > looking away from x86 toward ARM, RISCV, and POWER9 - at least > those arches are trending toward libre-friendly, rather than away We need both: we need more people working towards ARM (32 and 64bit), powerpc 64bit little endian and RISCV 64bit. But we also need to continue supporting x86 computers at least until the alternatives manage to be almost as usable as x86 computers. Right now there is no drop-in replacement for the Libreboot compatible Thinkpads. All the non-x86 laptops I've reviewed could still be used by some users but there is usually some drawbacks that prevents more general usage. For instance: - The novena is pretty close: it could have 4GiB of RAM, it has a SATA port and an mPCIe port, so users could add big storage and ath9k compatible WiFi cards. 3 versions were produced: - One was a single board computer (SBC) - One was a transportable computer with a battery, but without any integrated keyboard - The third one costed a fortune (maybe it was close to 5000$ at the time if I remember well) and the integrated keyboard is wireless (not great for security or privacy). And this laptop isn't produced anymore. - The olimex TERES-I has only 2GiB of RAM, and the internal WiFi / Bluetooth don't work with free software. So you need to use ath9k_htc compatible cards that are big or have poor range and don't support 5GHz. And ath9k compatible cards don't have these issues but they don't work on the TERES-I because there is no mPCIe port. The TERES-I also has no SATA so you end up having to use a 16GiB internal eMMC and a microSD card. It at least boot with free software and most of the hardware (beside WiFi/Bluetooth) works. The Pinebook is probably somewhat similar. - The Pinebook PRO also boots with free software, and it has 4GiB of RAM. It also supports NVMe SSDs but this means that the firmware of these SSD probably have access to your RAM (through DMA) and can therefor take control of the whole system. If you don't use that you end up having to use microSD and the internal eMMC again. Though you could in theory use the MVNe port with an ath9k instead with an adapter, but I'm unsure if you can buy that adapter or if you need to make it yourself. The connector for the external display also doesn't work with free software, so you can't use that laptop to do presentations. - The mnt reform is unusable right now as it requires nonfree software to boot. FSDG distribution won't ship that software and AFAIK nobody is working to reverse engineer it. - There was also a project to create a powerPC (64bit little endian) netbook, but it will rely on an external GPU that requires nonfree software to work. And so far I know no external GPUs that work with free software (ATI/AMD and Nvidia GPUs all require nonfree software that is run by the Linux kernel: they have nonfree bytecode in the video BIOS that is picked up and run by the nouveau, radeon, or amdgpu drivers). So unless someone designs a display controller and manage to get it to people, that won't work for laptop usage. In addition, many people also use the tor-browser without installing any addons (the tor-browser points to an addon repository which also has nonfree software), so this is lacking for ARM/PowerPC and RISCV on GNU/Linux. Replicant (and probably LibreCMC and proteanos) require x86 computers to build them. So we still need something that works for people in the meantime, so we have to keep supporting x86 computers. Using ARM/PowerPC 64bit little endian/RISCV 64bit computers for home servers for instance is probably much more easy. So we could try to work on that and get the software on pair with x86. If good WiFi cards aren't available it's also possible to use a libreCMC compatible WiFi access point in bridge mode to add WiFi access point to a server. Some use cases (virtualization) might not be on pair with x86 yet (due to software support, the lack of RAM, etc), but containers might work though (if there is enough RAM). For people that don't use the tor-browser, it might also be possible to use some of these computers as desktop computers and see what use cases are covered and what uses cases are not covered. There is a big unknown until we try for real and report our success / failures. 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 Sun Dec 25 22:27:59 2022 From: bill-auger at peers.community (bill-auger) Date: Sun, 25 Dec 2022 17:27:59 -0500 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221225230151.15c06130@primary_laptop> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> <20221225230151.15c06130@primary_laptop> Message-ID: <20221225172759.70543b67@parabola.localdomain> On Sun, 25 Dec 2022 23:01:51 +0100 Denis wrote: > > that could be a mksource PKGBUILD - parabola could provide a > > pre-cleaned source-ball; but those patches would be carried and > > maintained forever, so that solution is essentially soft-forking > Why not continuing to maintain our FSDG compliant version of Libreboot the difference being either to freeze the version (as you are suggesting?), or (as i was suggesting) to "liberate" the latest upstream libreboot and re-apply/rebase a patch-set routinely onto new libreboot upstream releases (i suppose the fork could be named 'libreboot-libre') From wael at waelk.tech Mon Dec 26 07:12:41 2022 From: wael at waelk.tech (Wael Karram) Date: Mon, 26 Dec 2022 09:12:41 +0200 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221224115534.289a64f3@parabola.localdomain> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> Message-ID: <17c05fd7942d2b43ff6de6ad20ba3682a3df168f.camel@waelk.tech> On Sat, 2022-12-24 at 11:55 -0500, bill-auger wrote: > On Sun, 18 Dec 2022 01:42:14 +0100 Denis wrote: > > Since that nonfree > > software will not be removed anymore, we won't be able to use the newer > > tarballs. > > > > I'm already in discussion with other people to continue a libre > > version of Libreboot. > > that could be a mksource PKGBUILD - parabola could provide a > pre-cleaned source-ball; but those patches would be carried and > maintained forever, so that solution is essentially soft-forking > libreboot > > > for some of the boards it supported before like the KGPE D16. > > ok, now i am more convinced that the new libreboot direction is > not well aligned with parabola - AFAIK, the D8 and D16 are the > only powerful servers which can boot the original no-blobs > libreboot; and these are libreboot's only significant targets > besides thinkpads - if such important targets are no longer > supported, i would be inclined to put the entire project into > maintenance-mode, rather than shifting the meaning of "libre" to > accommodate the ever-worsening lost cause that is x86 - does > libreboot support any other than x86? - maybe it's day has > passed, and it is just not needed any more > > put another way, it just seems that x86 precludes "moving > forward" in a libre direction - to me, "moving forward" means > looking away from x86 toward ARM, RISCV, and POWER9 - at least > those arches are trending toward libre-friendly, rather than away Specifically about D8 and D16 I know that the issue is upstream dropping support. https://mail.coreboot.org/pipermail/coreboot/2018-April/086618.html Here is some of the discussion on that. I presume someone can fork off of Coreboot and maintain it if that hardware is needed, and maybe that fork can be merged back into upsteam. But at least since 2018 these boards have been dropped. Since Libreboot didn't have a stable release since 2016 - the latest release(s) had these boards vanish. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From GNUtoo at cyberdimension.org Tue Dec 27 16:48:07 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 27 Dec 2022 17:48:07 +0100 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221225172759.70543b67@parabola.localdomain> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> <20221225230151.15c06130@primary_laptop> <20221225172759.70543b67@parabola.localdomain> Message-ID: <20221227174807.7cc94dfa@primary_laptop> On Sun, 25 Dec 2022 17:27:59 -0500 bill-auger wrote: > On Sun, 25 Dec 2022 23:01:51 +0100 Denis wrote: > > > that could be a mksource PKGBUILD - parabola could provide a > > > pre-cleaned source-ball; but those patches would be carried and > > > maintained forever, so that solution is essentially soft-forking > > Why not continuing to maintain our FSDG compliant version of > > Libreboot > > the difference being either to freeze the version (as you are > suggesting?), or (as i was suggesting) to "liberate" the latest > upstream libreboot and re-apply/rebase a patch-set routinely > onto new libreboot upstream releases (i suppose the fork could > be named 'libreboot-libre') I'm suggesting to continue the Libreboot development, starting from the point right before it started introducing problematic changes. I've already some repositories setup for that but we still need to work out how to accept contributions. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From GNUtoo at cyberdimension.org Tue Dec 27 16:50:19 2022 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 27 Dec 2022 17:50:19 +0100 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <17c05fd7942d2b43ff6de6ad20ba3682a3df168f.camel@waelk.tech> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> <17c05fd7942d2b43ff6de6ad20ba3682a3df168f.camel@waelk.tech> Message-ID: <20221227175019.0750eb25@primary_laptop> On Mon, 26 Dec 2022 09:12:41 +0200 Wael Karram wrote: > On Sat, 2022-12-24 at 11:55 -0500, bill-auger wrote: > > On Sun, 18 Dec 2022 01:42:14 +0100 Denis wrote: > > > Since that nonfree > > > software will not be removed anymore, we won't be able to use the > > > newer tarballs. > > > > > > I'm already in discussion with other people to continue a libre > > > version of Libreboot. > > > > that could be a mksource PKGBUILD - parabola could provide a > > pre-cleaned source-ball; but those patches would be carried and > > maintained forever, so that solution is essentially soft-forking > > libreboot > > > > > for some of the boards it supported before like the KGPE D16. > > > > ok, now i am more convinced that the new libreboot direction is > > not well aligned with parabola - AFAIK, the D8 and D16 are the > > only powerful servers which can boot the original no-blobs > > libreboot; and these are libreboot's only significant targets > > besides thinkpads - if such important targets are no longer > > supported, i would be inclined to put the entire project into > > maintenance-mode, rather than shifting the meaning of "libre" to > > accommodate the ever-worsening lost cause that is x86 - does > > libreboot support any other than x86? - maybe it's day has > > passed, and it is just not needed any more > > > > put another way, it just seems that x86 precludes "moving > > forward" in a libre direction - to me, "moving forward" means > > looking away from x86 toward ARM, RISCV, and POWER9 - at least > > those arches are trending toward libre-friendly, rather than away > > Specifically about D8 and D16 I know that the issue is upstream > dropping support. > https://mail.coreboot.org/pipermail/coreboot/2018-April/086618.html > Here is some of the discussion on that. > I presume someone can fork off of Coreboot and maintain it if that > hardware is needed, and maybe that fork can be merged back into > upsteam. But at least since 2018 these boards have been dropped. > Since Libreboot didn't have a stable release since 2016 - the latest > release(s) had these boards vanish. An association already applied for NLnet funding to bring that mainboard back into Coreboot. We don't know yet if that funding will be accepted or not. Libreboot also has the infrastructure to use different coreboot versions or patches for different computers. So for instance the payloads and so on can at least be updated. 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 wael at waelk.tech Wed Dec 28 07:50:30 2022 From: wael at waelk.tech (Wael Karram) Date: Wed, 28 Dec 2022 09:50:30 +0200 Subject: [Dev] libreboot-utils, moving forward. In-Reply-To: <20221227174807.7cc94dfa@primary_laptop> References: <1e29f14a5a4692fbffcaa15d1bad2af2bca9c761.camel@waelk.tech> <20221218014214.4cb80d5e@primary_laptop> <20221224115534.289a64f3@parabola.localdomain> <20221225230151.15c06130@primary_laptop> <20221225172759.70543b67@parabola.localdomain> <20221227174807.7cc94dfa@primary_laptop> Message-ID: <8952c8f79c4fd0297059591cf6b1503f80e70a45.camel@waelk.tech> On Tue, 2022-12-27 at 17:48 +0100, Denis 'GNUtoo' Carikli wrote: > On Sun, 25 Dec 2022 17:27:59 -0500 > bill-auger wrote: > > > On Sun, 25 Dec 2022 23:01:51 +0100 Denis wrote: > > > > that could be a mksource PKGBUILD - parabola could provide a > > > > pre-cleaned source-ball; but those patches would be carried and > > > > maintained forever, so that solution is essentially soft-forking > > > Why not continuing to maintain our FSDG compliant version of > > > Libreboot > > > > the difference being either to freeze the version (as you are > > suggesting?), or (as i was suggesting) to "liberate" the latest > > upstream libreboot and re-apply/rebase a patch-set routinely > > onto new libreboot upstream releases (i suppose the fork could > > be named 'libreboot-libre') > I'm suggesting to continue the Libreboot development, starting from the > point right before it started introducing problematic changes. > > I've already some repositories setup for that but we still need to work > out how to accept contributions. > > Denis. Why not rebase on each release instead of a hard-fork? At least for the foreseeable future it seems to be the easier path, since the new policy only adds absolutely necessary blobs and no more. Thus on machines like the T400 we can just patch some small parts in the code to work-around issues that were being solved in the microcode (much like libreboot did before), and the newer machines that *require* microcode/blobs can be dropped altogether. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: