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

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

[arch-dev-public] Upcoming PHP 8.1 update
by Pierre Schmitz 25 Apr '22

25 Apr '22

Hi all, a little heads up as it takes longer than expected. I'll start the PHP 8.1 update and the required rebuilds soon. I noticed some unexpected incompatibilities and I'd like to look into these first. I'll also evaluate if we could drop the php7 packages at the same time. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

7 28

[arch-dev-public] Starting x86_64_v3 port
by Allan McRae 08 Feb '22

08 Feb '22

Hi all, You may remember long in the past we discussed adding an x86_64_v3 port. From memory, pkgstats shows this will benefit ~2/3 (or 3/4?) of our users! So lets get this underway! Apart from tooling (devtools/dbscripts), we need to make some decisions. My plan is to seed the x86_64_v3 repos with x86_64 packages and then they get replaced as updates/rebuilds happen (potentially supplemented with a rebuild party). Pacman 6.0 can handle this. This is not a perfectly clean new port, but is substantially less of a burden than releasing a pure x86_64_v3 port. Our .BUILDINFO files do record the package architecture, so this mixture should not affect (e.g.) our reproducible builds etc. The decision to be made is who will package for this repo? I think these are the options: A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build server will help those without x86_64_v3 machines. B) we recruit some packagers to build the x86_64_v3 packages. C) Some combination of A+B. My understanding is our x86_64 port started with B, then C, then A. I think with our build infrastructure now, we can start with A, but that is more of a burden for packagers. I doubt it will be much of a burden as x86_64_v3 specific build issues are unlikely. Is there any particular objection to requiring packagers upload both architectures? Allan

14 27

[arch-dev-public] [RFC] archweb nvchecker integration
by Jelle van der Waa 07 Feb '22

07 Feb '22

We’ve wanted automatic flagging packages out of date for a while and currently every packager has to come up with it’s own solution. Let’s solve this centralized by integrating nvchecker into archweb. nvchecker is a program which can monitor versions upstreams, github, pypi, haskell, crates.io or custom provided for updates. Various packagers already use nvchecker in some form. [1] The idea is that every package in svn has a .NVCHECKER file (linux/trunk/.NVCHECKER) which contains the package specific settings i.e.: [go] source = “github” github = “golang/go” prefix = “go” use_max_tag = true exclude_regex = “.(release|weekly|rc|alpha|beta).” Archweb will have a systemd service which regularly goes through the pkgbases, check if the file exists, runs nvchecker and if required flags the package out of date automatically. For Github sources a token is required so we can do 5000 requests per hour, Arch Linux already has a Github account so this is no issue. Felix already has a script which converts a subset of packages to nvchecker. This could be extended to apply to more packages. [2] The question is if anyone object to checking these small .NVCHECKER files into our svn repository. If there are no real objections, I'll start implementing this functionality into archweb in two weeks. [1] https://nvchecker.readthedocs.io/en/latest/usage.html#check-crates-io [2] https://github.com/felixonmars/archlinux-futils/blob/master/arch-to-nvcheck… Greetings, Jelle van der Waa

12 17

[arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 05 Feb '22

05 Feb '22

I'm very happy to announce that debug packages in Arch Linux has been deployed :) This work began after FOSDEM 2020 and was announced in November 2020. However because of time constraints it took quite a while before we managed to deploy it. Currently we have a debuginfod service which is capable of delivering source listings and debug symbols to users with gdb, delve and other debuggers. This can be enabled by installing the `debuginfod` package and setting the environment variable `DEBUGINFOD_URLS="https://debuginfod.archlinux.org"`. The `debuginfod` package is also going to be providing this variable :) The debug package repositories themself are not publicly accessible nor distributed to our mirrors. This is because there is a general concern around the repository size increase. The goal is to take a look at distributing them and/or making them accessible in the future. Packages are being rebuilt for debug symbols where deemed needed by the packager and I suspect we should have a discussion around enabling the debug option by default or not. However see the section below around creating debug packages as there are some caveats of the current approach. I have added some links to the work that has been done to accomplish all of this at the bottom of this email. For general information about the instance one can look at the service itself: https://debuginfod.archlinux.org/ Previous emails on this topic: * https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.… * https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030583.… # archlinux.org news announcement Suggestion for the news announcement on archweb. I'll post it in a day or two unless there are any objections. Subject: Debug packages and debuginfod We are very happy to announce that debug packages are now available in Arch Linux. Debug symbols and source listing are provided through our debuginfod instance which can be utilized by debuggers such as gdb and delve. In the future we are planning to make these repositories public on our mirrors. For more information on this please visit the [archwiki](https://wiki.archlinux.org/title/Debuginfod) article, Or the debuginfod service. https://debuginfod.archlinux.org/ # Creating debug packages Currently with pacman 6.0.1-3 debug package only works on C/C++ projects. This is mostly because pacman utilizes a fairly ugly awk hack to extract sources and if it encounters a binary from Go or Rust (as an example) it is simply unable to deal with them and produces invalid packages. This is fixed with a patch i wrote which replaces the AWK hack with debugedit. https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd11d9becda721… Until this patch is backported, or a pacman release is done, I would advise us to not build debug packages for anything that isn't using gcc/clangd. Saying that, I'm unsure how we should be documenting debug packages across our distro. They probably belong in package guidelines sections of each package, or we make a common wiki page for this. Generally Rust needs a environment variable and Golang needs a bit of work to disable decompressed DWARF headers. We can probably work something out as we go along, currently I think we should try enable debug packages on our [core] packages. When we have pacman with the above patch I can try compile a list of available methods to get debug packages from Rust, Go and other languages. Obviously I'd need some help with that :) Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 # infrastructure https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168 # dbscripts https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/33 # devtools https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/78

6 9

[arch-dev-public] arch-repo-management walkthrough 2022-02-02 19:00 CET (UTC+01:00)
by David Runge 03 Feb '22

03 Feb '22

Hi all, given recent topics for build automation and work on internal projects I would like to announce a code walkthrough for arch-repo-management [1]. I would like to give an overview of the scope of the project, its current features and which features I would like to see implemented (some of which are still in a discussion phase). I will try to add a few more tickets beforehand to track open features and to outline them better. This way I hope that it becomes easier for interested people to follow up on them. The meeting will take place on Jitsi https://meet.jit.si/20220202-arch-repo-management on 2022-02-02 starting around 19:00 CET (UTC+01:00). Any changes to the date and/or location will be announced in this mail thread. Best, David [1] https://gitlab.archlinux.org/archlinux/arch-repo-management/ -- https://sleepmap.de

4 7

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:59:34PM +0100, sL1pKn07 SpinFlo wrote: > El dom, 30 ene 2022 a las 20:54, Morten Linderud (<foxboron(a)archlinux.org>) > escribió: > > > On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > > > hi > > > > > > thanks for the work! > > > > Thanks! > > > > > one question. This thing works, for example, if I build one of the > > packages > > > with debug package in the arch debuginfod site with my custom flag for > > > disable an option/feature. the debug package stored in the debuginfod > > site > > > still works? or i need to create a debug package locally? > > > > The buildid would be different so our debuginfo won't work with your > > packages. > > > > You can check with: readelf -n /bin/ls | grep -A4 build.id > > > > > If I need to build a local debug package and I want to use it > > > with debuginfod, is it possible add the link of the custom debuginfod > > site > > > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? > > > > Yes, space is the seperator. See > > https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES > > > > You can also add a file under /etc/debuginfod/*.urls like we did with our > > `debuginfod` package. > > > > -- > > Morten Linderud > > PGP: 9C02FF419FECBE16 > > > > Hi > > thanks for the reply > > is here documented the file/directory structure of debuginfod "repo"? > > greetings I recommend reading the documentation frankly. debuginfod just recursively scans a set of directories which is polling our package repositories. The implementation is linked in the email. https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168/… -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > hi > > thanks for the work! Thanks! > one question. This thing works, for example, if I build one of the packages > with debug package in the arch debuginfod site with my custom flag for > disable an option/feature. the debug package stored in the debuginfod site > still works? or i need to create a debug package locally? The buildid would be different so our debuginfo won't work with your packages. You can check with: readelf -n /bin/ls | grep -A4 build.id > If I need to build a local debug package and I want to use it > with debuginfod, is it possible add the link of the custom debuginfod site > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? Yes, space is the seperator. See https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES You can also add a file under /etc/debuginfod/*.urls like we did with our `debuginfod` package. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Signing enclave
by Kristian Klausen 29 Jan '22

29 Jan '22

Hi all The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling. A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today. The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing). Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed [1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure Best regards Kristian Klausen

3 2

[arch-dev-public] packager key revokation
by Andrzej Giniewicz 27 Jan '22

27 Jan '22

Hi all, my away time got longer than I expected (announced October 2020). Due to pandemic I still have no access to my Arch machine. I will get back access to it mid July, so this is not a resignation from my TU role! This notice is due to revocation of Bartłomiej Piotrowski's main key. Together with David Runge we decided, that best approach would be to remove my current key, and add a new one when I have access to my Arch machine. We will transfer the trust to a new key then. Hope to get back to packaging stuff soon, I have a lot of ideas I want to try and being stuck with Windows laptop from work is getting on my nerves. See you soon! Cheers, Andrzej Giniewicz (giniu).

4 3