Arch-dev-public November 2022

arch-dev-public@lists.archlinux.org

15 participants
13 discussions

Need help testing pacman 6.0.2 debug packages
by Morten Linderud 15 Jan '23

15 Jan '23

Yo! With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously. https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1 This should resolve several issues we have had with the existing debug packages and I want people to test this support. Please recreate your build chroots and/or reinstall base-devel locally. Enable debug in a diverse set of packages you maintain. And help validate the current assumptions: * Debug packages for Rust, Go* and Julia should work * Weird /build directories should not exist * We should have header files * The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}` You can list them easily with `bsdtar -tf *.pkg.tar.zst` Note pacman is currently in [testing]. In the case for Go we need to disable compressed dwarf headers with `-ldflags=-compressdwarf=false`. It should be the case for any binaries with these headers as well. They can be recognized with the weird "DWARF version 0 unhandled" error string during stripping. Please report back if things look good, or you are looking at weird debug package structures :) If everything looks fine I intend to write an RFC for blanket enabling debug packages in devtools! -- Morten Linderud PGP: 9C02FF419FECBE16

6 14

RFC for using standard SPDX license expressions in PKGBUILDs
by arch＠serebit.com 06 Jan '23

06 Jan '23

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

2 1

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 15 Dec '22

15 Dec '22

Hi Jelle, (also forwarding to dev-public) definitely yes, OpenSSL 3.0 is on my wish list! :-) I did not want to jump on it at day one though. Even the last minor updates were quite painful and we still have packages requiring version 1.0 and are still not compatible with 1.1. While they claim that most packages should work with a recompile, it would be nice to actually know which packages are not compatible. This should help whether we need another compatibility package are would be able to just replace openssl 1.1 with version 3. I know about foutrelis' awesome rebuilder script, but I wonder if we have something similar that I just could run for half a day to get an idea which package would break and which wont? Like a dry run that wont commit anything. If no such thing exists yet, I might have a look myself. Greetings, Pierre On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote: > > Hi Pierre, > > Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens > to have already started. > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > Greetings, > > Jelle -- Pierre Schmitz, https://pierre-schmitz.com

10 19

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

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public November 2022