From bill-auger at peers.community Sun Jun 4 21:13:48 2023 From: bill-auger at peers.community (bill-auger) Date: Sun, 4 Jun 2023 17:13:48 -0400 Subject: [Dev] Packaging Issue, libjaylink In-Reply-To: References: Message-ID: <20230604171348.5113e6ca@parabola.localdomain> just FYI those interested, it was just a temporary problem while merging community packages into extra From nobody at parabola.nu Tue Jun 6 17:35:23 2023 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 06 Jun 2023 17:35:23 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20230606173523.2851826.3247@winston.parabola.nu> eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:113.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 114. The following changes are: 1.- Bookmark search via bookmarks menu. 2.- Search History option now can restrict searches. 3.- FIDO2/WebAuthn support through USB function enabled. 3.- DNS over HTTPS function now is avariable through Privacy and Security section in Settings. For more information about the recent changes, please go to the link below: >> https://www.mozilla.org/en-US/firefox/114.0/releasenotes/ Thanks. From pagure at pagure.io Wed Jun 7 04:28:43 2023 From: pagure at pagure.io (=?utf-8?q?bill-auger?=) Date: Wed, 7 Jun 2023 04:28:43 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2372=3A_libre=3A_=5Biceweasel?= =?utf-8?q?=5D_Update_to_113=2E0_with_upstream_changes?= In-Reply-To: Message-ID: billauger commented on the pull-request: `libre: [iceweasel] Update to 113.0 with upstream changes` that you are following: `` just to comment on that - because of that 'python-pydantic' hack, the PKGBUILD in this commit does not compile at all, since python 3.11 replaced 3.10 - we really need to resolve that problem with the vendored 'python-typing-extensions' requiring such an old 'python-pydantic' - otherwise, we will need to rebuild the old 'python-pydantic' against python 3.11, and package it separately to support iceweasel `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/72 From pagure at pagure.io Wed Jun 7 04:30:50 2023 From: pagure at pagure.io (=?utf-8?q?bill-auger?=) Date: Wed, 7 Jun 2023 04:30:50 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2372=3A_libre=3A_=5Biceweasel?= =?utf-8?q?=5D_Update_to_113=2E0_with_upstream_changes?= In-Reply-To: Message-ID: billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre: [iceweasel] Update to 113.0 with upstream changes `` https://pagure.io/abslibre/pull-request/72 From bill-auger at peers.community Wed Jun 7 10:16:31 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 7 Jun 2023 06:16:31 -0400 Subject: [Dev] iceweasel 114.0 In-Reply-To: References: Message-ID: <20230607061631.302bf554@parabola.localdomain> i tried v114 today - the patches will need re-working > applying 9001-FSDG-sync-remote-settings-with-local-dump.patch error: > services/settings/Utils.jsm: No such file or directory error: > services/settings/Utils.jsm: No such file or directory error: > services/settings/Utils.jsm: No such file or directory From bill-auger at peers.community Wed Jun 7 16:44:46 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 7 Jun 2023 12:44:46 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> Message-ID: <20230607124446.5f1bc0e3@parabola.localdomain> i am mostly wondering, why should this conflict with 'extra/flashrom' - because of file conflicts, sure; but are both needed? - is 'extra/flashrom' still desirable? or undesirable, or redundant? - is rustiness it's only problem? some notes about the PKGBUILD: the PKGBUILD builds from VCS, and does not specify a commit, only a tag, which makes it not reproducible - most likely, that could be changed; but we prefer to avoid VCS sources whenever possible anyways - i found that the upstream VCS can generate tarballs; so i tried changing the source to the tarball (also eliminating the 'git' makedepends) - you probably would not have found that tarball - i did not see it on their website - i simply guessed the filename, and it is available in that form however, the tarball is not reproducible either - every download yields a different file - i devised an ugly way to verify the VCS files; but i would discuss this with the arch packager and/or the upstream - ideally, try to convince the upstream to fix their git service; so that it generates reproducible tarballs - as a last resort, try to convince the arch packager to specify the commit hash at the tag, at least - that is how i see it done in most arch PKGBUILDs built from VCS, like: _commit=0123456789 # <- this is tag 'v1.2.3' they do it that way; because git tags are not stable - the "is" above could become "was" at any time - the PKGBUILD may still verify the (new) signature; but it is not truly checking the integrity of the sources, as a tarball checksum does a reminder: never put "# Maintainer (Parabola):" - simply "# Maintainer:" and use lowercase for # Maintainer (aur): - that has no meaning currently; but i have been normalizing all of these, so that th From pagure at pagure.io Wed Jun 7 20:52:21 2023 From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=) Date: Wed, 7 Jun 2023 20:52:21 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2373=3A_libre/iceweasel=3A_11?= =?utf-8?b?NC4w?= Message-ID: grizzlyuser opened a new pull-request against the project: `abslibre` that you are following: `` libre/iceweasel: 114.0 `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/73 From wael at waelk.tech Thu Jun 8 02:28:40 2023 From: wael at waelk.tech (Wael Karram) Date: Thu, 08 Jun 2023 05:28:40 +0300 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <20230607124446.5f1bc0e3@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> Message-ID: <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> On Wed, 2023-06-07 at 12:44 -0400, bill-auger wrote: > i am mostly wondering, why should this conflict with 'extra/flashrom' - > because > of file conflicts, sure; but are both needed? - is 'extra/flashrom' still > desirable? or undesirable, or redundant? - is rustiness it's only problem? > > some notes about the PKGBUILD: > > the PKGBUILD builds from VCS, and does not specify a commit, only a tag, which > makes it not reproducible - most likely, that could be changed; but we prefer > to > avoid VCS sources whenever possible anyways - i found that the upstream VCS > can generate tarballs; so i tried changing the source to the tarball (also > eliminating the 'git' makedepends) - you probably would not have found that > tarball - i did not see it on their website - i simply guessed the filename, > and it is available in that form > > however, the tarball is not reproducible either - every download yields a > different file - i devised an ugly way to verify the VCS files; but i would > discuss this with the arch packager and/or the upstream - ideally, try to > convince the upstream to fix their git service; so that it generates > reproducible tarballs - as a last resort, try to convince the arch packager to > specify the commit hash at the tag, at least - that is how i see it done in > most arch PKGBUILDs built from VCS, like: > > ? _commit=0123456789 # <- this is tag 'v1.2.3' > > they do it that way; because git tags are not stable - the "is" above could > become "was" at any time - the PKGBUILD may still verify the (new) signature; > but it is not truly checking the integrity of the sources, as a tarball > checksum does > > a reminder: never put "# Maintainer (Parabola):" - simply "# Maintainer:" and > use lowercase for # Maintainer (aur): - that has no meaning currently; but i > have been normalizing all of these, so that th > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev As to why it should conflict with "vanilla" flashrom, because it is a fork thereof and they share a lot of the core code and files - that I think that is pretty obvious. Rust was just one example of one of the issues and why this fork exists, as it is happening now, most of the new development and work towards board support is being done on flashrom-stable (don't let the name mislead you, it is a much more active project), and in general since it is under the wings of Coreboot it has more eyes on the code and much better support - especially with Coreboot developers that are reverse-engineering a lot of boards and chips, that knowledge gets contributed in directly. As for the rest, I've added the fixes you told me about - the 'patches' file is just one file with both of the patches (that I've added separately). In any case, I'll also be contacting Nico Huber, being also the maintainer of the AUR PKGBUILD. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-PKGBUILD-for-flashrom-stable-a-Coreboot-mainta.patch Type: text/x-patch Size: 1862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-fixed-maintainer-attribution-clarified-reasons-for-p.patch Type: text/x-patch Size: 2328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patches Type: application/mbox Size: 4191 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 Thu Jun 8 09:59:22 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 8 Jun 2023 05:59:22 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> Message-ID: <20230608055922.324011f4@parabola.localdomain> On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > As to why it should conflict with "vanilla" flashrom, because it is a fork > thereof and they share a lot of the core code and files - that I think that is > pretty obvious. yes, i admitted that is obvious - but are both needed? - if they are duplicates, or if the new one supersedes the existing one, we should remove the one in [extra] - otherwise, we (you) should write a new wiki article, explaining why there are two packages of the same software, and why someone may prefer to use one or the other - so, i am asking those questions now - by conflicting with the extra package, it is suggesting that both packages should be available - so why keep two? - why are you not suggesting to remove the one in [extra] instead? On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > As for the rest, I've added the fixes you told me about - the 'patches' file is > just one file with both of the patches (that I've added separately). > In any case, I'll also be contacting Nico Huber, being also the maintainer of > the AUR PKGBUILD. i was not asking you to do anything differently to the PKGBUILD - in that case, i would have shown you my version, which is good enough for now - my main suggestion was to ask the upstream why there are no stable tarballs from IRC: > I've applied the changes to flashrom-stable, it now builds from tarballs > I've also clarified the reasons for packaging it (not just hte lack of rust, > but also a better supportive development environment in the Coreboot tree) if it is objectively "better", then there is no reason to keep the one in extra - but in that case, that suggests firstly, before doing _any_ of this, to contact the arch packager of the 'flashrom' package, and suggest to change the upstream source to the objectively "better" one - if accepted, then neither of us would need to do anything more - but perhaps the arch packager would have a valid argument against doing so - i am trying to determine now, what that objection might be (ie: what reason is there for parabola to keep both packages?) i was not asking you to build it from a tarball, in this case - that was only the general guideline - i already tried that - the tarball is not reproducible, so i abandoned that approach - if you ask the upstream "why do you not release stable tarballs?", that may be their answer: "because our VCS does not generate tarballs reproducibly" - that is all i was suggesting: to find out why i had to jump through such hoops, in order to make the source package reproducible - is yours? - try deleting the upstream tarball and running makepkg again - i think you will see that the checksum always fails sometimes building from a tarball is not possible (IMHO, this is that case); but in those cases, the package should be highly desirable to justify bending the rules about reproducibility and VCS builds, or else that software is best rejected, if the upstream will never publish tarball releases - over-all, that is what i was trying to determine * does it justify bending the rules? * can the upstream be convinced to do stable releases? * does it suggest removing the extra package? * can the arch packager be convinced to switch to the new upstream? From bill-auger at peers.community Thu Jun 8 11:26:00 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 8 Jun 2023 07:26:00 -0400 Subject: [Dev] [PATCH] remove pcr/gajim-plugin-omemo In-Reply-To: <6b9c79b7-c82b-b83c-c5ea-d5e1f5e2de63@riseup.net> References: <6b9c79b7-c82b-b83c-c5ea-d5e1f5e2de63@riseup.net> Message-ID: <20230608072600.18a06a76@parabola.localdomain> merged - ty From wael at waelk.tech Thu Jun 8 11:46:01 2023 From: wael at waelk.tech (Wael Karram) Date: Thu, 08 Jun 2023 14:46:01 +0300 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <20230608055922.324011f4@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> Message-ID: <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> On Thu, 2023-06-08 at 05:59 -0400, bill-auger wrote: > On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > > As to why it should conflict with "vanilla" flashrom, because it is a fork > > thereof and they share a lot of the core code and files - that I think that > > is > > pretty obvious. > > yes, i admitted that is obvious - but are both needed? - if they are > duplicates, or if the new one supersedes the existing one, we should remove > the one in [extra] - otherwise, we (you) should write a new wiki article, > explaining why there are two packages of the same software, and why someone > may > prefer to use one or the other - so, i am asking those questions now - by > conflicting with the extra package, it is suggesting that both packages should > be available - so why keep two? - why are you not suggesting to remove the one > in [extra] instead? I'll be quite honest, I just didn't think about it. As far as I see it, it is preferable to replace flashrom with flashrom-stable, and not because of just rust (although that would mean being simpler and lighter to build). Mostly because of being part of Coreboot and getting more development and support (as is already the case, flashrom-stable supports more target flashers and chips already), and also because the main developer from flashrom is actually now the one behind flashrom-stable (Nico Huber). > > On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > > As for the rest, I've added the fixes you told me about - the 'patches' file > > is > > just one file with both of the patches (that I've added separately). > > In any case, I'll also be contacting Nico Huber, being also the maintainer > > of > > the AUR PKGBUILD. > > i was not asking you to do anything differently to the PKGBUILD - in that > case, > i would have shown you my version, which is good enough for now - my main > suggestion was to ask the upstream why there are no stable tarballs From what I could gather 1.1 is the "stable", I suppose some of the "instability "/quick pace is because of improvements that were stuck upstream and now are possible because of less bureaucracy. > > from IRC: > > I've applied the changes to flashrom-stable, it now builds from > > tarballs > > ?????? I've also clarified the reasons for packaging it (not just hte lack > > of rust, > > ?????? but also a better supportive development environment in the Coreboot > > tree) > > if it is objectively "better", then there is no reason to keep the one in > extra - but in that case, that suggests firstly, before doing _any_ of this, > to contact the arch packager of the 'flashrom' package, and suggest to change > the upstream source to the objectively "better" one - if accepted, then > neither > of us would need to do anything more - but perhaps the arch packager would > have > a valid argument against doing so - i am trying to determine now, what that > objection might be (ie: what reason is there for parabola to keep both > packages?) I haven't checked with the Arch packager, but I don't think they'll be replacing it any time soon - as that version is still technically the "official" flashrom. Should I still try to ask anyhow? > i was not asking you to build it from a tarball, in this case - that > was only the general guideline - i already tried that - the tarball is not > reproducible, so i abandoned that approach - if you ask the upstream "why do > you not release stable tarballs?", that may be their answer: "because our VCS > does not generate tarballs reproducibly" - that is all i was suggesting: to > find out why i had to jump through such hoops, in order to make the source > package reproducible - is yours? - try deleting the upstream tarball and > running makepkg again - i think you will see that the checksum always fails > > sometimes building from a tarball is not possible (IMHO, this is that case); > but in those cases, the package should be highly desirable to justify bending > the rules about reproducibility and VCS builds, or else that software is best > rejected, if the upstream will never publish tarball releases - over-all, that > is what i was trying to determine > I just tested twice, with the two patches I sent applied it does compile fine time after time, the tarball is version-specific and stable so long you're pulling the same file. > * does it justify bending the rules? > * can the upstream be convinced to do stable releases? > * does it suggest removing the extra package? > * can the arch packager be convinced to switch to the new upstream? > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Thu Jun 8 12:02:15 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 8 Jun 2023 08:02:15 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> Message-ID: <20230608080215.25927263@parabola.localdomain> On Thu, 08 Jun 2023 14:46:01 +0300 Wael wrote: > I haven't checked with the Arch packager, but I don't think they'll be replacing > it any time soon - as that version is still technically the "official" flashrom. > Should I still try to ask anyhow? sure, i would try - if you could convince arch to adopt it, we could drop this discussion altogether, and have one less package to maintain - i was nearly successful doing the same for 'cowsay' last month On Thu, 08 Jun 2023 14:46:01 +0300 Wael wrote: > From what I could gather 1.1 is the "stable", I suppose some of the "instability > "/quick pace is because of improvements that were stuck upstream and now are > possible because of less bureaucracy. > > I just tested twice, with the two patches I sent applied it does compile fine > time after time, the tarball is version-specific and stable so long you're > pulling the same file. by "stable" i meant "deterministic" - i was not able to download the same file twice, using the same URL i will check again - maybe my brain was broken - which URL are you using? - can you send your revised PKGBUILD From wael at waelk.tech Thu Jun 8 12:09:17 2023 From: wael at waelk.tech (Wael Karram) Date: Thu, 08 Jun 2023 15:09:17 +0300 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <20230608080215.25927263@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230608080215.25927263@parabola.localdomain> Message-ID: On Thu, 2023-06-08 at 08:02 -0400, bill-auger wrote: > On Thu, 08 Jun 2023 14:46:01 +0300 Wael wrote: > > I haven't checked with the Arch packager, but I don't think they'll be > > replacing > > it any time soon - as that version is still technically the "official" > > flashrom. > > Should I still try to ask anyhow? > > sure, i would try - if you could convince arch to adopt it, we could drop this > discussion altogether, and have one less package to maintain - i was nearly > successful doing the same for 'cowsay' last month I'll check with the flashrom packager upstream and report back. > On Thu, 08 Jun 2023 14:46:01 +0300 Wael wrote: > > From what I could gather 1.1 is the "stable", I suppose some of the > > "instability > > "/quick pace is because of improvements that were stuck upstream and now are > > possible because of less bureaucracy. > > > > I just tested twice, with the two patches I sent applied it does compile > > fine > > time after time, the tarball is version-specific and stable so long you're > > pulling the same file. > > by "stable" i meant "deterministic" - i was not able to download the same > file twice, using the same URL > > i will check again - maybe my brain was broken - which URL are you using? - > can > you send your revised PKGBUILD I've attached the PKGBUILD whole (maybe I've screwed the patches up), this is the one that is working for me. > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- # Maintainer (aur): Nico Huber # Maintainer: Wael Karram # Parabola Changes and Rationale: # This package exists as an alternative to the rust-ridden flashrom. # Most of the newer development is happening in this branch too, as part of Coreboot. # Change of compilation targets to what is relevant for Parabola. pkgname="flashrom-stable" pkgdesc="Flashrom is a utility which can be used to detect, read, erase, or write BIOS chips (DIP, PLCC, SPI)." pkgver=1.1 pkgrel=1 url="https://review.coreboot.org/plugins/gitiles/flashrom-stable" license=('GPL') source=("https://download.flashrom.org/flashrom-stable/releases/flashrom-stable-v${pkgver}.tar.bz2" "https://download.flashrom.org/flashrom-stable/releases/flashrom-stable-v${pkgver}.tar.bz2.asc") validpgpkeys=('2853079C9C66AB7E82C64966A5C163B7E557CAEB') # Nico Huber - GPG sha256sums=('8f7a5cefcb59be9994464031af5fea8e073b58e51b2b312155fecdd8298f1141' 'SKIP') depends=('pciutils' 'libusb' 'libftdi' 'libjaylink' 'libgpiod') makedepends=('make') optdepends=("dmidecode: for SMBIOS/DMI table decoder support") conflicts=("flashrom") arch=('armv7h' 'i686' 'x86_64') build() { cd "${srcdir}/${pkgname}-v${pkgver}" make } package() { cd "${srcdir}/${pkgname}-v${pkgver}" install -d "${pkgdir}/usr/bin" install -d "${pkgdir}/usr/man/man8" install -m 0755 flashrom "${pkgdir}/usr/bin/" install -m 0644 flashrom.8 "${pkgdir}/usr/man/man8/" install -m 0755 util/ich_descriptors_tool/ich_descriptors_tool "${pkgdir}/usr/bin/" } -------------- 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 Fri Jun 9 01:15:57 2023 From: pagure at pagure.io (=?utf-8?q?bill-auger?=) Date: Fri, 9 Jun 2023 01:15:57 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2373=3A_libre/iceweasel=3A_11?= =?utf-8?b?NC4w?= In-Reply-To: Message-ID: billauger commented on the pull-request: `libre/iceweasel: 114.0` that you are following: `` looks good - thanks - it was an easy build for all arches this time `` To reply, visit the link below or just reply to this email https://pagure.io/abslibre/pull-request/73 From pagure at pagure.io Fri Jun 9 01:16:06 2023 From: pagure at pagure.io (=?utf-8?q?bill-auger?=) Date: Fri, 9 Jun 2023 01:16:06 +0000 (GMT) Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2373=3A_libre/iceweasel=3A_11?= =?utf-8?b?NC4w?= In-Reply-To: Message-ID: billauger closed without merging a pull-request against the project: `abslibre` that you are following. Closed pull-request: `` libre/iceweasel: 114.0 `` https://pagure.io/abslibre/pull-request/73 From bill-auger at peers.community Fri Jun 9 02:31:22 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 8 Jun 2023 22:31:22 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230608080215.25927263@parabola.localdomain> Message-ID: <20230608223122.0d928a0f@parabola.localdomain> ok great - so you found a signed tarball - i did not see one one other advice i forgot to mention: 'make' should not be in makedepends; because it is assumed to be installed per 'base-devel' from the arch guidelines: > The package base-devel is assumed to be already installed when building > with makepkg. Dependencies of this package should not be included in > makedepends array. From bill-auger at peers.community Fri Jun 9 03:59:54 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 8 Jun 2023 23:59:54 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230608080215.25927263@parabola.localdomain> Message-ID: <20230608235954.18d6f14f@parabola.localdomain> i copied most of this discussion to the bug tracker, so to have a reference for the blacklist entry https://labs.parabola.nu/issues/3493 From nobody at parabola.nu Fri Jun 9 17:36:42 2023 From: nobody at parabola.nu (Parabola Website Notification) Date: Fri, 09 Jun 2023 17:36:42 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20230609173642.2851826.83126@winston.parabola.nu> eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date: * iceweasel 1:114.0-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ * iceweasel 1:114.0-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 114.0.1. The main bugfix is related to a crash during the start. For more information, please follow the link below: https://bugzilla.mozilla.org/show_bug.cgi?id=1837201&_gl=1*1bkyq3n*_ga*MTUwMDI0MTMyMy4xNjg2MDcyNTUz*_ga_MQ7767QQQW*MTY4NjMzMjAyNy4yLjEuMTY4NjMzMjA0MC4wLjAuMA.. Thanks. From bill-auger at peers.community Fri Jun 9 19:40:59 2023 From: bill-auger at peers.community (bill-auger) Date: Fri, 9 Jun 2023 15:40:59 -0400 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date In-Reply-To: <20230609173642.2851826.83126@winston.parabola.nu> References: <20230609173642.2851826.83126@winston.parabola.nu> Message-ID: <20230609154059.6efa2d7e@parabola.localdomain> lol sry, but i must politely decline - IMHO, even one new mozilla per month is too often i just published v114 yesterday - it was released upstream only 3 days ago - the ARM package just finished compiling a few hours ago - mozilla's release cycle has become ludicrous sry mozilla, you need to spend more time on each release - software that requires bug fixes three days after release, is obviously not very well-made From wael at waelk.tech Tue Jun 13 08:56:34 2023 From: wael at waelk.tech (Wael Karram) Date: Tue, 13 Jun 2023 11:56:34 +0300 Subject: [Dev] [PACKAGING REQUEST][NGIRCD] Returning ngircd Message-ID: Hello, Seems that upstream Arch Linux dropped ngircd to the AUR after the merge between the community and extra repositories. I've repackaged it based on the AUR package and would like to inquire if it can be carried by Parabola - I've also added targets for i686 and armv7h in case those upstreams drop it soon. This specific patch has it packaged with compilation against openssl, I'm also open to making and maintaining a separate gnutls one if there is enough interest. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Packaged-ngircd-up-to-replace-the-package-that-was-r.patch Type: text/x-patch Size: 2493 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 Tue Jun 13 08:59:32 2023 From: wael at waelk.tech (Wael Karram) Date: Tue, 13 Jun 2023 11:59:32 +0300 Subject: [Dev] [PACKAGING REQUEST][NGIRCD] Returning ngircd In-Reply-To: References: Message-ID: <769cebbfb0e8cf9667c750379fac99fe18e7df68.camel@waelk.tech> On Tue, 2023-06-13 at 11:56 +0300, Wael Karram wrote: > Hello, > Seems that upstream Arch Linux dropped ngircd to the AUR after the merge > between > the community and extra repositories. > I've repackaged it based on the AUR package and would like to inquire if it > can > be carried by Parabola - I've also added targets for i686 and armv7h in case > those upstreams drop it soon. > > This specific patch has it packaged with compilation against openssl, I'm also > open to making and maintaining a separate gnutls one if there is enough > interest. > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev My apologies as I've just noticed that the previously attached files had a typo, I've reattached the fixed patches. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Packaged-ngircd-up-to-replace-the-package-that-was-r.patch Type: text/x-patch Size: 2493 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 GNUtoo at cyberdimension.org Tue Jun 13 15:52:02 2023 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 13 Jun 2023 17:52:02 +0200 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> Message-ID: <20230613175152.49c78b78@primary_laptop> On Thu, 08 Jun 2023 14:46:01 +0300 Wael Karram wrote: > As far as I see it, it is preferable to replace flashrom with > flashrom-stable, and not because of just rust (although that would > mean being simpler and lighter to build). I've looked at the release notes of flashrom 1.3 and I've also installed flashrom-stable and flashrom-stable is at least missing the following features: - I2C support - Write protection support So for these reasons it might be great to have both. Though it would require someone to package flashrom 1.3. Also I don't think we need to necessarily convince upstream to switch to flashrom-stable but we could probably tell them that it exists and that it's easier to package and have them make their choice. If they manage to package flashrom 1.3 we'd then get both. Also both flashrom and flashrom-stable seem to be developed under the same project and infrastructure (releases are on the same server), so it doesn't look like the usual forks of projects from Coreboot (like with memtest86+ and similar projects). It might be interesting to have more information about the relationship between both projects (I didn't find any official text describing that) for the package description. I've tried to look rapidly but I didn't find any infos. For instance there is a Flashrom-stable/1.1 page on flashrom wiki but even on Flashrom-stable/1.0 which seems to be the first release ("The 1.0 release comprise about 300 patches [...] on top of flashrom v1.2.1") there is no information about that. The source code of the 1.0 and 1.1 releases also don't seem to have any mention of flashrom-stable beside for the bugreport address and the git URL, and for when printing the flashrom version. So if you came across that information somewhere it might be interesting. If you didn't, then we could try to explain why flashrom-stable is relevant ourselves in the pkgdesc. The Flashrom-stable/1.0 wiki page has the following: "We skipped invasive patches so hopefully it will still build on all platforms where flashrom v1.2 built". - pkgdesc="Flashrom is a utility which can be used to detect, read, erase, or write BIOS chips (DIP, PLCC, SPI)." + pkgdesc="Flashrom is a utility which can be used to detect, read, erase, or write BIOS chips (DIP, PLCC, SPI). This flashrom-stalbe version doesn't require rust, so it is easier to build and it still builds fine on the same platforms supported by flashrom v1.2" Also DIP and PLCC are chip packages / formats, so it could probably be improved to "FWH, LPC, Parallel, SPI" which are the protocols supported. This mistake seems to come from the flashrom-git aur package that was probably used as a base for the flashrom-stable aur package. As for the chip package / formats, flashrom doesn't have to care about them as it's more a hardware thing, so we can omit them completely. It's a bit like if a laptop has a strange USB 2.0 connector, the software would not be able to see the difference. 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 Wed Jun 14 00:03:39 2023 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Wed, 14 Jun 2023 02:03:39 +0200 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <20230613175152.49c78b78@primary_laptop> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> Message-ID: <20230614020339.2c2ac2cf@primary_laptop> On Tue, 13 Jun 2023 17:52:02 +0200 Denis 'GNUtoo' Carikli wrote: > The Flashrom-stable/1.0 wiki page has the following: "We skipped > invasive patches so hopefully it will still build on all platforms > where flashrom v1.2 built". I forgot to add here, "so if nobody founds any better information, we could do something like that": > - pkgdesc="Flashrom is a utility which can be used to detect, read, > erase, or write BIOS chips (DIP, PLCC, SPI)." > + pkgdesc="Flashrom is a utility which can be used to detect, read, > erase, or write BIOS chips (DIP, PLCC, SPI). This > flashrom-stalbe version doesn't require rust, so it is easier to > build and it still builds fine on the same platforms supported by > flashrom v1.2" Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Wed Jun 14 02:10:13 2023 From: bill-auger at peers.community (bill-auger) Date: Tue, 13 Jun 2023 22:10:13 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230613175152.49c78b78@primary_laptop> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> Message-ID: <20230613221013.3d7e7db5@parabola.localdomain> i have intended to raise this general issue someday - this seems like a fine opportunity On Tue, 13 Jun 2023 17:52:02 +0200 Denis wrote: > we could try to explain why > flashrom-stable is relevant ourselves in the pkgdesc. > > - pkgdesc="Flashrom is a utility which can be used to detect, read, > erase, or write BIOS chips (DIP, PLCC, SPI)." > + pkgdesc="Flashrom is a utility which can be used to detect, read, > erase, or write BIOS chips (DIP, PLCC, SPI). This > flashrom-stalbe version doesn't require rust, so it is easier to > build and it still builds fine on the same platforms supported by > flashrom v1.2" that extra information (how we build it, or why) is not relevant to users of the binary package - there should not be such detail in the pkgdesc - pkgdesc is intended to be very brief (one line in a shell) for `pacman -Ss` - wael added those rationales to the PKGBUILD already to be pedantic though, that proposed pkgdesc conflicts with the arch guidelines for two reasons: > This is recommended to be 80 characters or less > and should not include the package name in a self-referencing way in the past, parabola packagers have added or changed pkgdesc to include details of "why do we rebuild it?" like: ", without webengine" ", without Twitter support" ", without YouTube support", - pkgdesc is to describe what the program can do for you - it should not be relevant to mention what the program does _not_ do - for example, if the package can be built without webengine and still serves its primary purpose, then webengine is obviously not an important feature - so why bother mentioning its presence or absence? i have been deleting those when i come across them, if only for the sake of a cleaner diff - however, most pkgdesc in nonprism include the "what it does not do" details; and i have left those in tact - most packages in nonprism are duplicates (not replacements) of another package in the system which "_do_ do that" - for nonprism, it does make sense to distinguish them somehow; but i dont think those details are documented anywhere else as it stands, flashrom-stable will not be a duplicate though - we decided that flashrom-stable can replace flashrom instead - maybe that needs more discussion - there is an open redmine ticket for flashrom now, which is the blacklist reference; so we should move further discussion of flashrom to redmine if anyone is interested, those "how and why" details can be found in the blacklist and related bug reports - in the case of flashrom-stable, it is also in the PKGBUILD - in general, i would not modify pkgdesc unless its wording conflicts with the FSDG, eg: "A snake game for Linux", or if the parabola modification make the upstream description incorrect, like things in nonprism - eg: "a client for gnu-social and twitter" would obviously be incorrect if twitter support was removed; but if the upstream pkgdesc was simply "a client for social websites", i would not see any reason to change it to: "a client for social websites, except for twitter", which has been the convention - thats "TMI" (too much information) From bill-auger at peers.community Wed Jun 14 02:21:34 2023 From: bill-auger at peers.community (bill-auger) Date: Tue, 13 Jun 2023 22:21:34 -0400 Subject: [Dev] [PACKAGING REQUEST][PATCH] Flashrom-Stable, Flashrom fork in Coreboot In-Reply-To: <20230613175152.49c78b78@primary_laptop> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> Message-ID: <20230613222134.5792ef9e@parabola.localdomain> i escalated the issue of flashrom to a bug report, and copied the relevant discussion from the mailing list to a redmine ticket - that is the blacklist reference now; so we should move further discussion of flashrom to redmine https://labs.parabola.nu/issues/3493 i did that because as it stands, we decided that flashrom-stable would not be a duplicate package, but can replace flashrom instead - maybe that needs more discussion if one of them (and only one of them) is deficient, then we should probably ignore the deficient one, regardless of its maintenance benefits - if both are deficient (in terms of features) in some way, then maybe we should carry both, or decide which one has the most desirable feature-set generally, such decision should benefit users - concerns such as "it is too rusty" or "it is a PITA to maintain" do not affect the user; so those should be secondary concerns, not a deciding factor, unless the decision would not affect the user From GNUtoo at cyberdimension.org Wed Jun 14 05:04:55 2023 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Wed, 14 Jun 2023 07:04:55 +0200 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230613221013.3d7e7db5@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> Message-ID: <20230614070455.3ee49b3a@primary_laptop> On Tue, 13 Jun 2023 22:10:13 -0400 bill-auger wrote: > that extra information (how we build it, or why) is not relevant to > users of the binary package - there should not be such detail in the > pkgdesc - pkgdesc is intended to be very brief (one line in a shell) > for `pacman -Ss` - wael added those rationales to the PKGBUILD already Good point. Anyway the user already knows that it's being rebuilt because it's in libre/ so that should be sufficient. Else we'd end up telling that we rebuild GRUB because of branding and at the end we might end up with all the ChangeLog inside the pkgdesc for some packages. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Wed Jun 14 10:21:11 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 14 Jun 2023 06:21:11 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614070455.3ee49b3a@primary_laptop> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> Message-ID: <20230614062111.086b5ee7@parabola.localdomain> at some point, they started adding standard comments "Parabola changes and rationales:" to libre PKGBUILDs - IMHO, that is the best place to document the changes and rationales; so they are always "at your fingertips" - otherwise you need to refer to the blacklist, then follow it's reference to a bug report (which still does not exist for all) even if the PKGBUILD needs 100 lines of comments, as a few have now, that still seems to be the best place to document all of the changes and each rationale - i have been adding those "Parabola changes and rationales:" every time i see a PKGBUILD without one in libre, or nonprism - there were some that i needed to deduce from the diff against arch; because it was not documented anywhere else also, in the PKGBUILD they are always "in your face", reminding the maintainer to re-evaluate the rationales from time to time, rather than simply tweaking the changes, only to make it build one more time - the day may come when that work is no longer necessary From bill-auger at peers.community Wed Jun 14 10:34:28 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 14 Jun 2023 06:34:28 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614062111.086b5ee7@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> Message-ID: <20230614063428.59b927a8@parabola.localdomain> On Wed, 14 Jun 2023 06:21:11 -0400 bill-auger wrote: > even if the PKGBUILD needs 100 lines of comments, as a few have now, that > still seems to be the best place to document all of the changes and each > rationale o/c i meant in addition the the blacklist reference bug reports - but the bug reports are rarely a joy to read; but the PKGBUILD comments could be concise From wael at waelk.tech Wed Jun 14 12:52:48 2023 From: wael at waelk.tech (Wael Karram) Date: Wed, 14 Jun 2023 15:52:48 +0300 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614063428.59b927a8@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> Message-ID: On Wed, 2023-06-14 at 06:34 -0400, bill-auger wrote: > On Wed, 14 Jun 2023 06:21:11 -0400 bill-auger wrote: > > even if the PKGBUILD needs 100 lines of comments, as a few have now, that > > still seems to be the best place to document all of the changes and each > > rationale > > o/c i meant in addition the the blacklist reference bug reports - but the bug > reports are rarely a joy to read; but the PKGBUILD comments could be concise > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev The idea from it is that flashrom-stable is as the name implies just more stable for the most part while also focusing on good support on what it currently offers - as opposed to the upstream which prioritizes (breaking) changes. It actually might still be relevant to offer both, as while they overlap in some of the functionality - yet there are enough differences between them to merit a split I think. -- Kind Regards, Wael Karram, TeapotChat NetOP. -------------- 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 Jun 14 13:10:03 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 14 Jun 2023 09:10:03 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> Message-ID: <20230614091003.79ad576a@parabola.localdomain> On Wed, 14 Jun 2023 15:52:48 +0300 Wael wrote: > The idea from it is that flashrom-stable is as the name implies just more stable > for the most part while also focusing on good support on what it currently > offers - as opposed to the upstream which prioritizes (breaking) changes. ok but my point is, to have two duplicate packages, the pkgdesc should not be identical - but that difference is not worth mentioning in the pkgdesc; because it is not relevant to the binary package, nor any user's decision of which package to install On Wed, 14 Jun 2023 15:52:48 +0300 Wael wrote: > It actually might still be relevant to offer both, as while they overlap in some > of the functionality - yet there are enough differences between them to merit a > split I think. ok, so can we describe those notable differences in a very few words? if so, what would those words be? is say, "stable version" meaningful enough to influence a user's decision? would we also need to re-package 'flashrom' to change its pkgdesc? From wael at waelk.tech Wed Jun 14 13:32:18 2023 From: wael at waelk.tech (Wael Karram) Date: Wed, 14 Jun 2023 16:32:18 +0300 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614091003.79ad576a@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> <20230614091003.79ad576a@parabola.localdomain> Message-ID: <18f63349464538e3e2b702bc0af83c6bcaca088e.camel@waelk.tech> On Wed, 2023-06-14 at 09:10 -0400, bill-auger wrote: > On Wed, 14 Jun 2023 15:52:48 +0300 Wael wrote: > > The idea from it is that flashrom-stable is as the name implies just more > > stable > > for the most part while also focusing on good support on what it currently > > offers - as opposed to the upstream which prioritizes (breaking) changes. > > ok but my point is, to have two duplicate packages, the pkgdesc should not be > identical - but that difference is not worth mentioning in the pkgdesc; > because > it is not relevant to the binary package, nor any user's decision of which > package to install > > > On Wed, 14 Jun 2023 15:52:48 +0300 Wael wrote: > > It actually might still be relevant to offer both, as while they overlap in > > some > > of the functionality - yet there are enough differences between them to > > merit a > > split I think. > > ok, so can we describe those notable differences in a very few words? > > if so, what would those words be? > > is say, "stable version" meaningful enough to influence a user's decision? > > would we also need to re-package 'flashrom' to change its pkgdesc? > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev I think the answer is yes to both, for the most part it ought to be more stable. -- 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 Wed Jun 14 13:42:21 2023 From: bill-auger at peers.community (bill-auger) Date: Wed, 14 Jun 2023 09:42:21 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <18f63349464538e3e2b702bc0af83c6bcaca088e.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> <20230614091003.79ad576a@parabola.localdomain> <18f63349464538e3e2b702bc0af83c6bcaca088e.camel@waelk.tech> Message-ID: <20230614094221.3167c1c3@parabola.localdomain> On Wed, 14 Jun 2023 16:32:18 +0300 Wael wrote: > I think the answer is yes to both, for the most part it ought to be more stable. note that "stable" does not mean "it wont explode" - as a guide to the user, that could only mean "my pacman will not upgrade it as often" - are we certain that even that is true? - i suppose that is what the upstream means by it (but who knows) - if the "stable" branch releases just as often as the original "non-stable" branch, than "stable" is quite meaningless From wael at waelk.tech Wed Jun 14 13:45:44 2023 From: wael at waelk.tech (Wael Karram) Date: Wed, 14 Jun 2023 16:45:44 +0300 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614094221.3167c1c3@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> <20230614091003.79ad576a@parabola.localdomain> <18f63349464538e3e2b702bc0af83c6bcaca088e.camel@waelk.tech> <20230614094221.3167c1c3@parabola.localdomain> Message-ID: <97550a8a5ca7baf18ba72dc56c7edfbc6e92975a.camel@waelk.tech> On Wed, 2023-06-14 at 09:42 -0400, bill-auger wrote: > On Wed, 14 Jun 2023 16:32:18 +0300 Wael wrote: > > I think the answer is yes to both, for the most part it ought to be more > > stable. > > note that "stable" does not mean "it wont explode" - as a guide to the user, > that could only mean "my pacman will not upgrade it as often" - are we certain > that even that is true? - i suppose that is what the upstream means by it (but > who knows) - if the "stable" branch releases just as often as the original > "non-stable" branch, than "stable" is quite meaningless Stable in terms of internal architecture - so indeed less likely to explode. -- 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 Jun 15 10:18:18 2023 From: bill-auger at peers.community (bill-auger) Date: Thu, 15 Jun 2023 06:18:18 -0400 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <97550a8a5ca7baf18ba72dc56c7edfbc6e92975a.camel@waelk.tech> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> <20230614091003.79ad576a@parabola.localdomain> <18f63349464538e3e2b702bc0af83c6bcaca088e.camel@waelk.tech> <20230614094221.3167c1c3@parabola.localdomain> <97550a8a5ca7baf18ba72dc56c7edfbc6e92975a.camel@waelk.tech> Message-ID: <20230615061818.7c5218eb@parabola.localdomain> On Wed, 14 Jun 2023 16:45:44 +0300 Wael wrote: > Stable in terms of internal architecture - so indeed less likely to explode. that is a mis-use of that term - i would want to describe it to parabola users more accurately perhaps "robust version" captures the intention better? - but frankly, that sounds like nonsense to me - it implies that the arch version is not robust - if that were true, we should definitely remove the "likely to explode" version, so it does not brick anyone's hardware i must assume that only you are misunderstanding the term; and the upstream meant that it releases less often, or will have fewer API- or ABI-breaking changes, or a similar conventional meaning of "stable" to bring back flashrom, flashrom-atable would need to be re-packaged anyways; because i set flashrom-atable to replace flashrom - so we may as well get the descriptions right first From dev at lists.parabola.nu Mon Jun 19 06:11:59 2023 From: dev at lists.parabola.nu (Parabola GNU/Linux-libre: Recent news updates: bill auger) Date: Mon, 19 Jun 2023 06:11:59 -0000 Subject: [Dev] [dev] OpenBLAS >= 0.3.23-2 update requires manual intervention Message-ID: <20230619061159.2851828.76391@winston.parabola.nu> >From Arch: The openblas package prior to version 0.3.23-2 doesn&#x27;t ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc. The default BLAS implementation will be used for most packages like NumPy or R. Please install &quot;blas-openblas&quot; and &quot;blas64-openblas&quot; to make OpenBLAS the default BLAS implementation, just like the old behavior. Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation: error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency &#x27;blas&#x27; required by cblas :: installing openblas (0.3.23-2) breaks dependency &#x27;blas&#x27; required by lapack Please append your preferred default BLAS implementation to the regular -Syu command line to get around it. For example: # pacman -Syu blas-openblas or # pacman -Syu blas URL: /news/openblas-0323-2-update-requires-manual-intervention/ From nobody at parabola.nu Thu Jun 22 14:17:26 2023 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 22 Jun 2023 14:17:26 -0000 Subject: [Dev] Orphan nonsystemd package [libnm] marked out-of-date Message-ID: <20230622141726.2851828.34145@winston.parabola.nu> kwopleq at proton.me wants to notify you that the following packages may be out-of-date: The user provided the following additional text: nonsystemd/libnm package could be upgraded by removing systemd-libs from dependencies From wael at waelk.tech Tue Jun 27 07:52:37 2023 From: wael at waelk.tech (Wael Karram) Date: Tue, 27 Jun 2023 10:52:37 +0300 Subject: [Dev] [PKGBUILD][PATCH][UPDATE] Prosody Modules 0.12.3 Message-ID: Hello, I've attached a patch for updating prosody-modules. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-Prosody-Modules.patch Type: text/x-patch Size: 1147 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 GNUtoo at cyberdimension.org Tue Jun 27 08:48:32 2023 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Tue, 27 Jun 2023 10:48:32 +0200 Subject: [Dev] the case for terse 'pkgdesc' In-Reply-To: <20230614091003.79ad576a@parabola.localdomain> References: <308330f0fe99990df9fbd714d4ecc8f560eb0385.camel@waelk.tech> <20230607124446.5f1bc0e3@parabola.localdomain> <4bedbed69bad004e7f49081fddf48484ed35eb64.camel@waelk.tech> <20230608055922.324011f4@parabola.localdomain> <74668973450988e6e5b877ff140a9fa79cb35812.camel@waelk.tech> <20230613175152.49c78b78@primary_laptop> <20230613221013.3d7e7db5@parabola.localdomain> <20230614070455.3ee49b3a@primary_laptop> <20230614062111.086b5ee7@parabola.localdomain> <20230614063428.59b927a8@parabola.localdomain> <20230614091003.79ad576a@parabola.localdomain> Message-ID: <20230627104832.4468fc27@primary_laptop> On Wed, 14 Jun 2023 09:10:03 -0400 bill-auger wrote: > ok, so can we describe those notable differences in a very few words? flashrom-stable: Flashrom is a utility which can be used to detect, read, erase, or write BIOS chips (FHW, LPC, SPI, Parallel). (latest) flashrom: Flashrom is a utility which can be used to detect, read, erase, write, write-protect or write-unprotect BIOS chips (FHW, I2C, LPC, SPI, Parallel). 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 Tue Jun 27 08:57:00 2023 From: wael at waelk.tech (Wael Karram) Date: Tue, 27 Jun 2023 11:57:00 +0300 Subject: [Dev] [PATCH][UPDATE] GNU Unifont Message-ID: <41da2db7965ef0987128360291d0371800f14a4e.camel@waelk.tech> Hello, I've attached a patch to update unifont from 15.0.01 to 15.0.06. -- Kind Regards, Wael Karram. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Updated-unifont-to-version-15.0.06.patch Type: text/x-patch Size: 1182 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: