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

[arch-dev-public] Missing bugtracker assignment emails
by Morten Linderud 16 Dec '19

16 Dec '19

Yo! Andreas Radke has done an impressive amount of bug assignments the past week. But it looks like the assignment emails themselves are not sent correctly and you might not have noticed this. Please look over your bug assignments on the tracker in case you haven't taken a look in a while :) Happy holidays! -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

[arch-dev-public] Proposal: Build a ruleset for new packages and package quality
by Christian Rebischke 13 Dec '19

13 Dec '19

Hello everybody, Due to a longer discussion around alpha and beta packages in our repositories in IRC yesterday, I would like to start a hopefully more constructive discussion around this topic on the ML. Short summary for everybody what happened: I wanted to get caddy2.0.0-beta into [community], people started discussing that we don't ship betas in our repositories and I should either wait or ship the stable caddy v1 release. I don't want to start this discussion around caddy again (I will wait for a stable release). What I want to accomplish with this mail is: 1. find a consensus on rules which packages we allow in our repositories and which don't. 2. find a consensus on rules on violating our rules regarding package requirements. (e.g. What happens when TU/Dev XY violates our package requirements? what is the punishment?) 3. revive the discussion around better PKGBUILD quality (see also Eli's thread about PKGBUILD quality on arch-tu: https://lists.archlinux.org/private/arch-tu/2019-November/000083.html) 4. I would like to have this rules written down somewhere, either in the TU bylaws (in dev bylaws if this exists) or in a new format like "community bylaws" (maybe we could combine this with the question about a new leader). 5. What do we do with the existing beta and alpha packages? Are they granted asylum? Or do we remove them, to be consistent? extra libmspack 1:0.10.1alpha-2 extra qt5-webkit 5.212.0alpha3-6 community d-containers 0.8.0alpha.19-1 extra frozen-bubble 2.2.1beta1-14 extra hddtemp 0.3.beta15.53-1 extra libcaca 0.99.beta19-2 extra tsocks 1.8beta5-8 community hydrogen 1.0.0beta1-1 community lablgtk3 3.0.beta6-2 community modclean 3.0.0beta.1-1 community sdedit 4.2beta8-1 community sniffit 0.3.7.beta-17 community vbindiff 3.0_beta5-1 community wqy-microhei 0.2.0_beta-9 community wqy-microhei-lite 0.2.0_beta-9 6. How do we define stable packages? beta or alpha is just a human made word. I've seen devs who said their "1.0" version is unstable and shouldn't be used in production. Should such a software get packaged? And what about projects who use semantic versioning (the devs said so), but they have a 0.* prefix release? 7. Another topic is a rule about "touching packages of others". In the #archlinux-tu channel we came to the conclusion that TUs or devs should ask the package maintainer before touching another devs/TUs package, how do we want to handle this? Is this the consensus, or are touches without prior question allowed? What do we do if somebody violates our rules? etc 8. A few guys in the IRC pointed me to this guidelines in our wiki: Note: This page is only editable with Wiki-Admin/Dev Permission. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versio… My questions to this guidelines: 8.1. under which consensus where this rules defined? Are these rules the result of a developer vote? of a leader decision? Or are they made up by a few persons without consensus. 8.2 I can't find any list about punishments for violations of these rules. 8.3 There is no documentation about our alpha and beta packages. I see that there are exceptions for alpha and betas, but it's not clear for me how these exceptions apply to the packages we have in our repositories. This needs to be documented, otherwise every person could push an alpha package and just 'claim' that one of those exceptions apply for the package and if nobody checks this claim, the package will be in the repository. 9. Do we consider packages, that are build from the latest git tag, as alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' 10. Do we need to ask software developers in the future if they consider their project stable? It's not clear which versioning schema the devs use, some consider their 0.1 release as unstable, some consider it as stable. Is semantic versioning applied? Do they follow a different schema? 11. What do we do when a package is stable, but the API is unstable? Is the whole package considered unstable? The current guidelines are not clear about APIs, but many users use Arch Linux for software development and maybe rely on stable APIs. Disclaimer: I don't know how we want to find concensus yet (TUs have a transparent vote process, but devs don't have an equivalent for this), therefore I hope for a "final decision" of our still-leader aaron. This topic doesn't need to be decided this year. I am fine with reviving this thread in January or late replies in January. Best regards, Chris

6 6

[arch-dev-public] Qt 5.14 in [testing]
by Antonio Rojas 12 Dec '19

12 Dec '19

The usual reminder that, due to Qt's ABI versioning, everything built against 5.14 will have to wait in [testing] until Qt itself moves.

1 0

[arch-dev-public] Orphaning crypto++
by Baptiste Jonglez 11 Dec '19

11 Dec '19

Hi, I plan to orphan crypto++ [1] soon: I don't maintain any package that depends on it anymore, and it's becoming annoying to maintain. For instance, there was a significant security issue on July 2019 [2], and 5 months later there is still no upstream release even though a patch is available [3]. I just patched the Arch package but it raises the question of whether we want to have such a crypto library in our repositories. Here are the packages that currently depend on crypto++: - amule - clementine - kvazaar - rbutil - ceph (makedepends) If nobody steps up to adopt it before December 20th, I will drop it to the AUR. In that case, I will send a reminder to find a solution for the above packages. Thanks, Baptiste [1] https://www.archlinux.org/packages/community/x86_64/crypto++/ [2] https://security.archlinux.org/CVE-2019-14318 [3] https://github.com/weidai11/cryptopp/issues/869

2 2

[arch-dev-public] Orphaning dkim-proxy
by Archange 04 Dec '19

04 Dec '19

Hi, I’ve orphaned dkim-proxy since I no longer use it (opensmtpd added support for filters recently, and they are the new recommended way of doing DKIM signing/verification, deprecating the use of dkim-proxy). If someone want to adopt it please let me know, else I’ll just drop it to the AUR in ~1 week. Regards, Bruno/Archange

1 0

[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