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

[arch-dev-public] Flyspray migration to a VPS
by Giancarlo Razzolini 01 Dec '19

01 Dec '19

Hi All, If everything goes well, I'll be moving flyspray (bugs.archlinux.org) to a VPS later today. In fact, the VPS already has a copy of our flyspray instance, I'll just make a final dump and take a last copy of the attachments and make the move. So, expect it to be unavailable for some time later today. I expect to start working on this at around 16-17 UTC and the downtime should be around one hour, plus the time it takes for the DNS changes to propagate. Regards, Giancarlo Razzolini

1 1

[arch-dev-public] Dropping OpenVAS/GVM
by Christian Rebischke 28 Nov '19

28 Nov '19

Hi, I plan to drop the vulnerability management tool "openvas" (Greenbone Vulnerability Manager). I stopped using the software and it gets more and more tedious (due to breaking changes and bad testing at upstream). Moreover I really think that there are better solutions right now (for example cloudflare/flan) Anyone interested in adopting it? Best regards, chris

1 0

[arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
by Allan McRae 20 Nov '19

20 Nov '19

Hi all, As you may know, we have had people busy looking at what it takes to make our packages reproducible. There has been a lot of progress there lately. Our reproducible builds team (along with the wider reproducible builds community) has been building our packages in different environments to test how stable the builds are [1]. The good news is that >80% of our packages could be built twice in varying environments and give the exact same result. However, that is only part of the picture. Ideally, we want people to be able to take one of our packages and rebuild it exactly. With the release of pacman-5.2, packages record a lot more information about their build environment. That means we can reconstruct a package's build chroot, and then rebuild it. There are two tools in the works to do this. One by Morton (Foxboron) [2] and one by Eli [3]. Note that both tools need more testing to be ready for a wider release and currently require some manual editing to run. The good news is, we have at least 10 packages that can be precisely reproduced using both these tools [4]! This means you can take one of these tools and rebuild a package from the repos, and get the exact same package out of it. This is an amazing effort - well done to the team! To keep this momentum going, it would be great to rebuild every package in [core] using makepkg from pacman-5.2+. That way we can test which packages are actually reproducible and work towards fixing those that are not. So be prepared for almost the entire repo to hit [testing] soon, and get your sign-off shoes on! Again, a huge congrats to our reproducible builds team. This has been a massive amount of work! Allan [1] https://tests.reproducible-builds.org/archlinux/archlinux.html [2] https://github.com/archlinux/archlinux-repro [3] https://github.com/eli-schwartz/devtools/blob/reproducible/makerepropkg.in [4] https://wiki.archlinux.org/index.php/DeveloperWiki:ReproduciblePackages

6 7

Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org
by Sven-Hendrik Haase 18 Nov '19

18 Nov '19

On Mon, 18 Nov 2019 at 09:00, Konstantin Gizdov <arch(a)kge.pw> wrote: > Sounds good. One question - where do we move our email aliases? > Not quite sure what you mean. All email is still being handled by apollo unless I'm mistaken and soyuz had more duties than I thought. In the latter case, we should migrate that to apollo. Could anyone shed some light on this?

2 1

[arch-dev-public] New kernel packages and mkinitcpio hooks
by Giancarlo Razzolini 12 Nov '19

12 Nov '19

Hi All, As most of you have noticed already, the kernel packages had some recent changes where they do not install the kernel to /boot, as well as they do not have any kmod [0] nor mkinitcpio hooks anymore. Neither they do install mkinitcpio presets [1]. These changes were made after a lot of discussions between myself, Jen and the maintainers of the other kernels as well. We have spent a lot of time to arrive at this current format. [2] Kernels and presets are not installed and generated by mkinitcpio alpm hooks and scripts. All kernels that have a pkgbase entry file [3] will be processed by these scripts. We have changed all our officials kernels. Also, kernel removals are handled by mkinitcpio as well. We want to make the boot process more flexible, while also keeping it backwards compatible by default. There are a few changes I have planned for the next mkinitcpio release [4] that will help even further to achieve this. I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and also create a simple configuration file for each kernel. Right now dracut does not conflict with mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side note, I have been using it for the past 8 months without any issues. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kmo… [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lin… [2] https://github.com/archlinux/mkinitcpio/pull/7 [3] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lin… [4] https://github.com/archlinux/mkinitcpio/issues

3 6

Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
by Giancarlo Razzolini 11 Nov '19

11 Nov '19

Em novembro 11, 2019 16:18 Gaël PORTAY escreveu: > Hi Giancarlo, > > On Sun, Nov 10, 2019 at 06:41:38PM -0300, Giancarlo Razzolini via arch-dev-public wrote: >> >> I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and >> also create a simple configuration file for each kernel. Right now dracut does not conflict with >> mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm >> writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might >> eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side >> note, I have been using it for the past 8 months without any issues. > > Do you have commited your hooks somewhere? I would like to have a look > to them and probably to test them. > They should land on the dracut package itself sometime this week, or start of the next week. I might commit them to svn before that, so probably keep an eye on the dracut package git repository, but I make no promises. There will probably be some default dracut configuration as well. And each kernel might end up having two dracut.d configuration files, one for each image (regular and fallback), created from a preset, in a similar way mkinitcpio does it now. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] Adding package (lib32-)-amdvlk in extra (and testing)
by Laurent Carlier 10 Nov '19

10 Nov '19

I would like to add these packages in the official repositories. It's a good alternative to vulkan-radeon packages, well maintained upstream and offer a good compromise with new gfx card released.

2 1

[arch-dev-public] Python 3.8 rebuilds
by Evangelos Foutras 31 Oct '19

31 Oct '19

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. Please avoid adding new Python packages and starting other rebuilds during this time.

1 1

[arch-dev-public] xf86-input-keyboard dropped
by Andreas Radke 30 Oct '19

30 Oct '19

This Xorg input driver package shouldn't be used under Linux systems anymore. It has been removed from our repos. Use either xf86-input-libinput or xf86-input-evdev driver package. https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/merge_reques… -Andy

1 0

[arch-dev-public] Using SPDX License list as identifiers
by Jerome Leclanche 28 Oct '19

28 Oct '19

Hi This just came up on IRC. Thoughts on using the SPDX license list as valid license identifiers for all packages? https://spdx.org/licenses/ Most of the identifiers would change but we would have a consistent and much larger, externally-maintained list to choose from. It would also be a little more accurate; eg. the SPDX allows for distinctions such as "LGPL-3.0-or-later" vs. "LGPL-3.0-only". We could retain the current identifiers as symlinks. J. Leclanche

5 6