- Arch-dev-public - lists.archlinux.org

Updating ruby package guideline to only build gems and extensions once
by Andreas 'Segaja' Schleifer 29 Nov '22

29 Nov '22

Hello, in July David (dvzrv), Tim (bastelfreak) and I had a jitsi session in which we reworked the old ruby packaging guidelines [1] to make it more reflecting the current wishes and standards we already used when packaging ruby (like building from source, adding tests, ...). After it was pubslihed Felix (felixonmars) approached us and mentioned that there is a flaw in our logic as gems and extensions are now build twice. Once in the build() step which is then used for testing and once in the package() step. Recently Felix found a way to only build the gem and possible extensions once and use them for both testing and packaging. To reflect these changes I would propose that we update our ruby package guidelines with the new way that Felix found. I took the liberty of updating them on my personal space [2]. If there is no objection, then I would like to push the changes to the main page. Best regards Andreas [1] https://wiki.archlinux.org/title/Ruby_package_guidelines [2] https://wiki.archlinux.org/title/User:Segaja/Ruby_package_guidelines

3 4

Virtual package naming
by Jan Alexander Steffens (heftig) 29 Nov '22

29 Nov '22

Hello list, We're planning to make PipeWire the default PulseAudio sound server, and for that we need to change some dependencies around. Notably, we want a virtual "pulseaudio server" package that is fulfilled by both pipewire-pulse and pulseaudio, with preference for the former. However, we weren't sure what to name it. We don't seem to have a consistent naming scheme for virtual packages besides soprovides (libfoo.so). Most virtual packages look like normal ones (e.g. java-runtime, d-compiler). Some packages use SCREAMING-KEBAB-CASE to clearly separate "virtual" from "normal" dependencies (e.g. WIREGUARD-MODULE), which makes their weirdness (pacman -Si fails) less surprising. I'm not sure that's a pattern we want to continue, but I still would like a consistent scheme. Looking forward to your input, Jan

4 3

Away for a while
by Konstantin Gizdov 25 Nov '22

25 Nov '22

Hi all, I've not taken a break since officially joining the Arch team long ago. With the pressure of taking care of my newborn and the holidays approaching, it is time for a long one. I plan to be away until Jan 2023. I've finished all my relevant urgent Todos and updated the packages that have the most impact. That should give some buffer and allow people to react while I'm gone. I won't be entirely offline, but I won't be easily reachable or have time to spend on Arch. Only for quick questions. Most of my packages have co-maintainers, so that should not be a big problem overall. If you need me urgently, feel free to contact me on my Telegram or Matrix. All the best, happy holidays and a joyful new year to all! -- Regards, Konstantin

1 0

Dropping qtwebkit
by Antonio Rojas 21 Nov '22

21 Nov '22

Hi, Qtwebkit has been unmaintained for a long time (last release from annulen's fork was almost 3 years ago) and is plagued with security issues by now. Most consumers are either dead upstream, of they use it to provide optional functionality that can be disabled at build time. I propose to drop it from our repos, together with all packages which use it non-optionally. Other distros such as Opensuse and Gentoo have done it already. 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.

4 6

Archiving all package sources
by Jelle van der Waa 17 Nov '22

17 Nov '22

Hey all, For packaging we now rely on external parties to keep the source code hosted which can be a problem and some packagers want to search through all our packages code. [1] Currently we already archive sources using `sourceballs` on repos.archlinux.org for GPL licensed packages, this is limited to a subset of all packages and done after the fact (A timer which runs every 8 hours and part of dbscripts). sourceballs calls `makepkg --nocolor --allsource --ignorearch --skippgpcheck`. This can be a problem as it runs after the package has been committed and it other network issues which might occur specific to the server. (ie. source cannot be downloaded where server is hosted) To make this more robust, when committing a package using communitypkg or equivalent we also rsync the sources to a location on repos.archlinux.org (Gemini). This means the sources are consistent, and this opens the ability to implement a fallback or to change devtools to look at our sources archive when building a package. That would benefit reproducible builds as well and automated rebuilds. Searching through our source code would be a next nice to have, most solutions such as sourcegraph/hound require a Git repository. [3] [4] So maybe we can hack up a repository which just git adds all directories and keeps one git commit? That should probably be not too much of a waste. But the first proposal is to first archive all our code in a way it can be consumed by a search solution. Questions: * How do we deal with archiving patches, PKGBUILD's etc. for GPL compliance (just save it next to the code?) * How do we determine when sources can be removed / cleaned up (we can't store things forever). DBscripts hooks? * Do we have enough disk space for archiving? $ du -hs 111G /srv/ftp/sources/ [jelle@gemini ~]$ df -h / Filesystem Size Used Avail Use% Mounted on /dev/sdb2 19T 6.3T 12T 35% / [1] https://gitlab.archlinux.org/archlinux/ideas/-/issues/2 [2] https://sources.archlinux.org/sources/ [3] https://github.com/sourcegraph/sourcegraph [4] https://github.com/hound-search/hound/

5 5

New community wide idea pool
by Levente Polyak 11 Nov '22

11 Nov '22

Hello everyone, Several times in the past I was thinking about a better and more central way to keep track of ideas and suggestions. We've encountered multiple times that good ideas got lost because we never properly kept track of them and only recognized after coming up with the very same idea much later. I'd like to address this issue and setup an actual community-wide place for this [0]. The GitLab repository is an incubating idea pool useful to keep track of early stage suggestions and brainstorming before they get picked up and implemented eventually. We will use an issue template [1] and various labels to classify ideas with rough t-shirt sized estimates. This will help volunteers to look out for ideas they would be interesting to invest time on. Cheers, Levente [0] https://gitlab.archlinux.org/archlinux/ideas [1] https://gitlab.archlinux.org/archlinux/ideas/-/blob/main/.gitlab/issue_temp…

2 2

Realtime kernels moved to [extra]
by David Runge 05 Nov '22

05 Nov '22

Hi all, today I have moved the realtime kernels to [extra]: https://archlinux.org/packages/extra/x86_64/linux-rt/ https://archlinux.org/packages/extra/x86_64/linux-rt-lts/ I have been maintaining these kernels in the AUR via a custom repository [1] for a couple of years now and believe that quit a few people actually make use of them (in various contexts). The effort to get the realtime kernel patchset [2] merged in its entirety has been going on for about 15 years already and the patchset is shrinking with every kernel release. In the future users will be able to configur the kernel build without a separate patchset. That all being as it is, historically there have been two repositories tracking the ongoing work: One for the work on the most recent Linux versions, while the other tracks all LTS branches that are supported. I am intending to follow both the most recent and the highest LTS version, while consolidating with core/linux and core/linux-lts wherever it makes sense. For that purpose we have moved the kernel repositories (with distribution specific patches), mirroring their respective upstream to: https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt-lts This allows for easy collaboration and cherry-picking of patches (which I do currently already for linux-rt, using core/linux) and my hopes are, that the knowlegde in our developer and packager team grows in how to configure kernel builds and maintain the packages. The https://gitlab.archlinux.org/archlinux/packaging/upstream/ group location is meant for all projects that have to maintain custom patches on top of what upstream does (that is also why shadow lives there currently). In case there are developers or package maintainers interested in collaborating on the builds and maintenance of the kernels, please reach out! Best, David [1] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ [2] https://wiki.archlinux.org/title/Realtime_kernel_patchset -- https://sleepmap.de

1 0

Arch Linux in October 2022
by Levente Polyak 02 Nov '22

02 Nov '22

## mkinitcpio mkinitcpio v32 has been released [0] which adds support for zst compressed firmware for future kernel versions as well as various fixes and adjustments. ## pacman pacman 6.0.2 has been released [1] which fixes multiple issues with debug packages. On top pacman-key has been adjusted to do a single gpg trustdb check instead of one after each key revocation. Furthermore various fixes have been added related to clang lto, reproducible packages containing sparse files and other fixes. ## python-bootstrap To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. In the future we want to rely on python-bootstrap [2] to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow. Not all initially required packages are defined yet, but a first attempt at bootstrapping has been completed [3]. ## OpenSSL 3 The OpenSSL 3 rebuild started with the latest version 3.0.7 which will hopefully land soon in the [testing] repository. [0] https://github.com/archlinux/mkinitcpio/releases/tag/v32 [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/v6.0.2 [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 01 Nov '22

01 Nov '22

Alright, I have updated openssl-1.1 (the one in staging) to the latest version and both include libprovides now. In addition to this openssl-1.1 provides openssl=1.1.1 On Tue, Nov 1, 2022 at 7:01 PM Luna Jernberg <droidbittin(a)gmail.com> wrote: > > 1.1.1r is just bugfixes and no critical security fix as in the 3.0x series > > On Tue, Nov 1, 2022 at 6:57 PM David Runge <dave(a)sleepmap.de> wrote: > > > > On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote: > > > I updated to 3.0.7 in staging. I had libprovides in my branch. Do you > > > guys think this might be handy to define versioned dependencies when > > > we have potentially three different openssl verions to maintain? > > > > > > provides=('libcrypto.so' 'libssl.so') > > > > Always a fan! Please add! :) > > > > > At the same time 1.1.1s was released which mainly fixes a regression > > > from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to > > > release that 1.1.1 update in the meantime? > > > > If it is not critical, maybe better to let the openssl 3 rebuild roll > > through. > > > > Best, > > David > > > > -- > > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com

1 0

Bootstrapping Python
by Jelle van der Waa 01 Nov '22

01 Nov '22

Hey All, Yesterday we had a successful meeting [1] on bootstrapping Python. For those who might wonder what this is about: To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. Filipe has created a project to tackle this issue, it uses python-installer to temporarily create wheels for setuptools, pep517, installer and other packages. [2] These can then be packaged using a PKGBUILD [3] and replace the existing python-setuptools package temporarily to build the "real" python-setuptools. Bootstrapping these tools will be a multiple stage bootstrap (and assumes an already available interpreter package such as python 3.11): 1. Build python-bootstrap 2. Build python-setuptools and co. (without tests) 3. Build all makedepends and depends of the bootstrapped packages (without tests) 4. Build "real" packages (those that have been bootstrapped) and replace the initial bootstrapped packages with them (without tests). 5. Build the ecosystem using the available packages (without tests) 6. Rebuild the ecosystem with tests In the future we want to rely on python-bootstrap to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow there. Not all initially required packages are defined yet, but a first attempt at bootstrapping can be found in a custom repository already [4]. This has been a quick PoC, we still need to put in a lot of work to get this to work out of the box - Get a full bootstrap working using python-bootstrap - Figure out how we deal with sphinx being a build requirement of python-installer/builder blocking bootstrapping - Figure out how to bootstrap setuptools - Create a script to determine the bootstrap order (using our repository database) - Better tooling for creating custom repositories / devtools chroots for these rebuilds - Automatically update python-bootstrap's git submodules to the repository version - Add documentation about the entire process If you have time to help testing and developing, please come join us in #archlinux-python on libera.chat. [1] https://md.archlinux.org/s/rBZYhg_fE# [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/blob/PKGBUILD/PKG… [4] https://pkgbuild.com/~jelle/python3.11/

1 0