RFC for using standard SPDX license expressions in PKGBUILDs
Hello all! I've opened an RFC for transitioning the license field in PKGBUILDs from our existing format to the SPDX license expression specification. This is my first RFC, and I want to thank Foxboron for his help with the process so far. You can find the MR here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16 Please visit the above link for discussion. Best, Campbell publickey - arch@serebit.com - 0x35A1812B.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Archiving all package sources
On 2022-11-13 21:17:29 (+0100), Jelle van der Waa wrote: > https://sources.archlinux.org/sources/$pkgbase/whatever.tar.gz > > They are versioned, example: > > -rw-r--r-- 1 sourceballs sourceballs 49M May 22 13:42 > zynaddsubfx-3.0.6-3.src.tar.gz > So I never said I wanted the archive in a Git repo, it might be > required for search but that's the next step. So for now binary > sources are just as normal as source tarballs. I see. I guess I misunderstood this, as you brought up the search tooling (which is super helpful btw and I often use your hound to search for things in PKGBUILDs). > I am not sure if this fits into repod and should. However, I'm happy > to discuss it in the next meeting, when is it? As mentioned in my last mail, the source tarball consumption feature is pretty much on the backburner at the moment. However, if we indeed have our build infrastructure/ build tooling generate the source tarballs in the future, we'll eventually want to tackle consumption of these artifacts I guess. Exposing the source tarballs of the current repository packages (as outlined in your examples above) could easily be a configurable thing (like many other features [1]). The next meeting is next week Wednesday [2]. Best, David [1] https://repod.archlinux.page/repod/man/repod_conf.html [2] https://lists.archlinux.org/archives/list/arch-proje...@lists.archlinux.org/thread/BQFBH33YG3IDPFZKU3ERTITUB6GE3ZLD/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: Dropping qtwebkit
El miércoles, 9 de noviembre de 2022 17:34:44 (CET) Antonio Rojas escribió: > If there are no objections, I will open a todo list to disable the > dependency in all packages where it's possible, and otherwise drop them. This turned out to be less problematic than expected. Many of the dependants already support webengine via configure switches or upstream patches and could be ported, others weren't really using it and just had a leftover dependency. After porting all these and removing the dependency where it was optional, these are the remaining users: acetoneiso2: last release 12 years ago, was never officially ported to Qt5 quiterss: no porting efforts have been started https://github.com/QuiteRSS/quiterss/issues/909 smtube: our announcement triggered some work to port it to webengine, but doesn't seem it will be finished any time soon https://github.com/smplayer-dev/smtube/pull/21 swift-im: dead for 4 years wkhtmltopdf: pretty much dead https://github.com/wkhtmltopdf/wkhtmltopdf/issues/5160 Any objections to dropping all of them?
Re: Dropping qtwebkit
Le jeudi 17 novembre 2022, 20:07:01 CET Antonio Rojas a écrit : > El miércoles, 9 de noviembre de 2022 17:34:44 (CET) Antonio Rojas escribió: > > If there are no objections, I will open a todo list to disable the > > dependency in all packages where it's possible, and otherwise drop them. > This turned out to be less problematic than expected. Many of the dependants > already support webengine via configure switches or upstream patches and > could be ported, others weren't really using it and just had a leftover > dependency. After porting all these and removing the dependency where it > was optional, these are the remaining users: > > acetoneiso2: last release 12 years ago, was never officially ported to Qt5 Can be safely dropped > quiterss: no porting efforts have been started > https://github.com/QuiteRSS/quiterss/issues/909 smtube: our announcement > triggered some work to port it to webengine, but doesn't seem it will be > finished any time soon https://github.com/smplayer-dev/smtube/pull/21 > swift-im: dead for 4 years > wkhtmltopdf: pretty much dead > https://github.com/wkhtmltopdf/wkhtmltopdf/issues/5160 > > Any objections to dropping all of them? ++ signature.asc Description: This is a digitally signed message part.