Arch-dev-public June 2020

arch-dev-public@lists.archlinux.org

15 participants
9 discussions

[arch-dev-public] Mkinitcpio replacement with Dracut
by Giancarlo Razzolini 19 Feb '21

19 Feb '21

Hi All, Recently, Dave announced his intention to step down as mkinitcpio maintainer. I have been handling a few things on it, made some small changes to our mkinitcpio-busybox [0], closed a few old bugs, while also made sure some of the other bug reports are still valid. [1] I have been testing a few patches to mkinitcpio for a while to fix those bugs, but last week Dave and I had a discussion on IRC and we agreed that we could spend better time contributing somewhere else than keeping working with mkinitcpio. Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils [2] uses very old code. Even though ipconfig works, it has several drawbacks compared to using more modern tools. Not to mention that we have two use cases for mkinitcpio, which are base and systemd enabled initramfs. Even though we use by default our base enabled initramfs, we have to support systemd related issues and we have to keep developing our systemd hooks. I have been looking into dracut for some time now, I copied some stuff from them on a few of my own scripts and they also have an actual test suite, that we currently can't use on Arch, but I plan to change that. With this in mind, I have packaged dracut for Arch and put it on Extra [3]. I have been using a dracut initramfs for a while now to boot my encrypted partition. Surprisingly, I only had to create a small patch to one of the dm-crypt module scripts [4] In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will probably have to keep both packages on our repos for a long time, but once we are confident it's a good fit, we can replace mkinitcpio on our iso and base, so new installs get dracut by default. Please, drop in your comments as well. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… [1] https://bugs.archlinux.org/index.php?string=mkinitcpio&project=0 [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/ [3] https://www.archlinux.org/packages/extra/x86_64/dracut/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Cha…

4 7

[arch-dev-public] Abandoning all my vim-* plugin packages
by Sven-Hendrik Haase 13 Jul '20

13 Jul '20

I've started using a vim plugin manager and don't use my packages anymore. They need a new home. Please show these packages some love: * vim-a * vim-colorsamplerpack * vim-doxygentoolkit * vim-guicolorscheme * vim-minibufexpl * vim-omnicppcomplete * vim-project * vim-taglist * vim-vcscommand * vim-workspace The packages are pretty low maintenance but I'd prefer if someone who actually uses them maintained them. Anything that's not taken within 2 weeks will be dropped to AUR.

1 1

[arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
by Frederik Schwan 02 Jul '20

02 Jul '20

We received a Feature Request today to remove fontconfig and xorg-mkfontscale dependencies from our font packages according to our own font packaging guidelines [0]. I discussed with Eli on #archlinux-bugs and we think it's a no-brainer but before creating a TODO we'd like to ask for your opinions first. Thank you [0] https://bugs.archlinux.org/task/66012

7 18

[arch-dev-public] repos.archlinux.org has been migrated to a new server
by Jelle van der Waa 26 Jun '20

26 Jun '20

Hi all, repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now on a new server which has plenty of diskspace for us to continue packaging for a while (16T free). Some important notes: The ssh hostkeys changed for repos.archlinux.org which means if you use archco/communityco this will fail without a useful error. So take care of your .ssh/known_hosts. The ssh host keys for gemini/repos.archlinux.org are: # gemini.archlinux.org 1024 SHA256:F1Corf6i2U72yub+CIzzGHLOMVKVnjALh1YHM8gBjxE root(a)gemini.archlinux.org (DSA) 256 SHA256:If51DkTftUpDAFz65totgDfTd/ddu/2w/RBZIHtY74U root(a)gemini.archlinux.org (ECDSA) 256 SHA256:wUrJYf9+zOpIEUQ3ndgarK0PjzPICa1frmu7mpL4e14 root(a)gemini.archlinux.org (ED25519) 3072 SHA256:Rltnuln3bjsHJwVbys/LnYCj7hO6srPoa15JP8QhmlQ root(a)gemini.archlinux.org (RSA) https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ss… https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ss… If anything unexpected happens please either mail arch-devops(a)lists.archlinux.org or #archlinux-devops on irc. Greetings, Jelle

3 5

[arch-dev-public] Thursday 25th June 14:00 UTC repos.archlinux.org migration
by Jelle van der Waa 23 Jun '20

23 Jun '20

Hi al, On Thursday 25th June at 14:00 UTC work will begin on migrating the following services to a new machine: * repos.archlinux.org * svn.archlinux.org * Arch mirror infrastructure This will impact all packaging and svn activities as those services are not available during the migration period. The services will be migrated to a new server as diskspace is running low on the current server, the migration is expected to take at least four hours. When the migration is successfully completed an email will be send that the services are available and packaging can resume. TLDR: No packaging can be done on the 25th of June starting at 14:00 UTC till the migration is done. Greetings, Jelle

1 0

Re: [arch-dev-public] SDR package naming
by Filipe Laíns 05 Jun '20

05 Jun '20

Hi all, I want to bring up two issues relating Kyle Keen's packages. I tried to contact him and got an initial reply but I have not heard from him since. It has been almost 4 months and I have sent him 3 different followup emails. Since it was not super urgent I let a pretty significant amount of time pass but I would like to have this resolved. Here are the two issues I seek resolution: 1) Rename libuhd to uhd UHD[1] is the upstream name. The software is pretty well known by that name. I have only ever seen it being addressed as libuhd when talking about the library it provides specifically, but even then UHD is the standard. It also provides some tools alongside the library. Following the Arch philosophy I think the package should be named "uhd". 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks The GNURadio ecosystem has a pretty well established prefix for GNURadio blocks, which is gr-. Similarly to the previous issue, I have never seen them being refereed as gnuradio-something. The upstream names are gr-something. The gnuradio- prefix might seem to make things more clear to new users, and even then I have my doubts, but it definitely makes things more confusing for actual users of the project. Previewing some counter-arguments to this, as I have discussed it with people previously. This is totally different than, for eg., the python ecosystem where we use the python- prefix. The gr- is given by the upstream and is the *de facto* naming scheme for the project. If you don't agree with the use of the gr- prefix, I think that variation of the name should *at least* be present in provides. These might seem like nitpicks, but I do very much care about them and I believe they should be corrected. You can find my attempt at communication with Kyle below. I am very conflicted about this, but I think before I end the email I should note that Kyle is packaging and he appears to have replied to other team member(s). I am not sure if I have done something wrong or behaved in an improper manner. I don't think I did, but if that's the case please let me know. [1] https://github.com/EttusResearch/uhd [2] https://github.com/gnuradio Cheers, Filipe Laíns On Thu, 2020-02-06 at 09:42 +0000, Filipe Laíns wrote: > On Wed, 2020-02-05 at 23:21 -0500, keenerd wrote: > > Sometimes my automatic email filing puts things in the wrong place, > > but searching across all folders finds no emails from you about this. > > How did you try to contact me before? > > > > UHD I am ambivalent on. However several other distros also call it > > "libuhd" and it is a library after all. > > > > Gnuradio vs gr I don't agree with. A project needs to be very notable > > for a two-letter naming convention. Python, for example, is > > sufficient. Internally the Gnuradio project uses "gr" because, well, > > they type it hundreds of times every day. Outside of their project, > > it is less helpful and more confusing. > > > > There are several people deeply involved with Gnuradio who are also > > Arch users. I more or less started packaging Gnuradio for them, and > > their input was instrumental in making our packages the way they are. > > They've never raised any of these issues. > > > > You did not provide any reasoning for why you think changes are necessary? > > > > -Kyle > > > > On 2/4/20, Filipe Laíns <lains(a)archlinux.org> wrote: > > > Hey Kyle, > > > > > > I think I have contacted out about this already but without much > > > success. I would like to adjust the names of some SDR packages. I > > > believe `libuhd` should be called `uhd` and packages that > > > provide GNU > > > Radio blocks should be named `gr-name` instead of `gnuradio-name` > > > (this > > > affects `gnuradio-{fcdproplus,iqbal,osmosdr}`). > > > > > > Can we adjust the naming? What do you think? > > > > > > Thank you, > > > Filipe Laíns > > > > > Sorry, my bad. > > Regarding uhd, that's what Debian does, not us. uhd is the upstream > name and we should honor it. If you want examples just look at [1], > from a quick browse I wasn't able to find any instances of packages > where we add the lib prefix. > > Regarding GNU Radio blocks, it more of a grey area so I understand and > respect your position. My reasoning is that the gr- prefix comes from > the upstream, and AFAIK everybody else on earth uses it. When I started > using Arch it was a bit confusing why the packages had different names, > especially for a distribution that tries to keep as close to the > upstream as possible. Do you think it would make sense to ask the GNU > Radio guys what they think? Either way, it's ultimately your call. > But if you don't want to rename it could we add the gr- prefixed name > to provides/conflicts? > > Just some other unrelated things, I am bringing a few more SDR packages > to Arch. I just pushed the necessary bits for Adalm-Pluto support, I am > working on srsLTE (actually, almost finished, just waiting for some > replies from the upstream) and I want to get some misc GNU Radio > blocks. If you want to co-maintain something just drop an email or > contact me on irc. Also, I currently own a LimeSDR, Adalm-Pluto, HackRF > and rtl-sdr, so if you need any testing please let me know :) > > [1] https://www.archlinux.org/packages/?q=library > > Thank you, > Filipe Laíns

3 5

[arch-dev-public] Disowning the Kea DHCP server package
by Baptiste Jonglez 05 Jun '20

05 Jun '20

Hi, I don't use Kea on Arch anymore, and I don't have the time and energy to maintain it in [community]. It's currently stuck at 1.5.0. Kea 1.6 came out 9 months ago, but it moved some files around and would require extensive testing to make sure everything still works as expected. If somebody is interested in maintaining it, please adopt the package, otherwise I will move it to the AUR this summer. FYI, it has a quite low usage according to pkgstats: https://pkgstats.archlinux.de/packages#query=kea Baptiste

2 2

[arch-dev-public] Transparency report May 2020
by Levente Polyak 03 Jun '20

03 Jun '20

# Transparency report May 2020 ## Staff ### TU addition We are happy to welcome Frederik aka freswa among the Trusted Users [0]. Some of you may already know him as one of our bug wranglers where he joined forces in February 2020. ## Packaging ### Go The Go package guidelines [1] have been overhauled and in conjunction the go-pie package has been removed [2]. The major difference is a new set of CGO/GOFLAGS that ensure all our distro flags are respected appropriately, leading to Go binaries with RELRO, PIE and fortify hardening. A to-do list to reflect these changes is pending. ### CMake The CMake package guidelines [3] have been created which describe some important bits to consider when packaging software using cmake. Most notably appropriate release type option that may otherwise have undesired effects, removal of non required RPATH usage as well as some convenience options to build in subdirectories without manually creating them. As CMake still does not respect CPPFLAGS itself, which results in fortify hardening being ignored, a temporary patch [4] has been added to circumvent this misbehavior, a to-do list to reflect these changes is pending. ## Reproducible builds You may have noticed a couple of large rebuilds that occurred recently. These fixed issues of non-reproducible file ordering with old versions of makepkg. This and other hard work by the team improving our tooling and fixing packaging issues has resulted in 96% of [core] being reproducible, and 90% of [extra]. You can see the status of which packages are reproducible here [5]. A full progress report can be found on the corresponding thread [6] on arch-dev-public. We have set up a fleet of three rebuilderd [7] runners to continuously test our distributed repository packages and populate our status page [8]. Some integration into archweb to indicate the current reproducibility status is planned. ## Infrastructure ### GitLab We're in the process of switching our Git hosting from our custom cgit instance to GitLab! We created https://gitlab.archlinux.org [9] and have started moving some projects. We'll continue moving projects onto GitLab and will then get rid of our cgit instance. Users can currently not collaborate with us on GitLab as we still need to get some monitoring in place to make sure we can keep a close eye on usages to ward off abuse. However, we're planning on doing this soon and then we'll open up GitLab to everyone. Finally you can collaborate on Arch like it's 2020! We're also going to use GitLab for other things such as bug tracker (instead of Flyspray), Kanban board (instead of Kanboard), and service desk (for GDPR requests and such). ### Single-sign-on/Keycloak Arch operates many different services - all of which with their own login systems and account databases. This is not ideal from a security and convenience standpoint. We'd like to enforce the same security requirements for all users while also allowing everyone to use the same account to log in to all of our services. It'll also finally allow you to use 2-factor authentication for all Arch services. We still have a long way to go here in terms of integrating all services via SAML/OIDC and figuring out how to let users continue using their old accounts. ### SVN to Git migration The git migration plans have been picked up again, and started working towards a proof-of-concept implementation [9]. This would allow packagers to avoid the SVN mono repository and manage each package as a separate git repository, and facilitate some modernization of our current tooling. More information about the plans and implementation will hit the [arch-dev-public] list in the upcoming week. ## Projects ### Archiso The archiso project has been moved [10] to Arch Linux' GitLab instance [11]. Furthermore over the past weeks smaller and larger fixes found their way into the repository. In the future all merge requests and releases will be handled via GitLab. CI integration and more elaborate test suites are still being developed to ensure a more robust setup for our monthly release images and any custom use cases. ### Pacman Initial support for parallel downloads landed in the pacman [12] code base, requiring large changes to the codebase. Many patches providing the finishing to this feature have been submitted. Once the code churn around this feature request has slowed, we will make a beta release for wider testing. Additionally, one obscure area of non-reproducility in packages was discovered through the Arch Linux reproducible builds effort, and subsequently fixed in makepkg. Furthermore, the move from using autotools to meson for the pacman build system was completed. Discussion is ongoing on moving the pacman codebase to the Arch Linux GitLab instance, with initial CI setup being added to the codebase. ## SPI For the upcoming SPI annual report 2019, a section about some of Arch Linux achievements has been assembled to represent our project. A link to the report will be distributed once it's available. [0] https://lists.archlinux.org/pipermail/aur-general/2020-May/035734.html [1] https://wiki.archlinux.org/index.php/Go_package_guidelines [2] https://lists.archlinux.org/pipermail/arch-dev-public/2020-March/029898.html [3] https://wiki.archlinux.org/index.php/CMake_package_guidelines [4] https://git.archlinux.org/svntogit/packages.git/commit/trunk/cmake-cppflags… [5] https://reproducible.archlinux.org/ [6] https://lists.archlinux.org/pipermail/arch-dev-public/2020-May/029981.html [7] https://github.com/kpcyrd/rebuilderd [8] https://reproducible.archlinux.org/ [9] https://github.com/Foxboron/dbscripts/commits/morten/git-support [10] https://lists.archlinux.org/pipermail/arch-releng/2020-May/003963.html [11] https://gitlab.archlinux.org/archlinux/archiso [12] https://git.archlinux.org/pacman.git/commit/?id=6a331af27fe6dc7842725d067fd…

2 1

[arch-dev-public] HEADS UP: Qt 5.15 in [testing]
by Antonio Rojas 03 Jun '20

03 Jun '20

The latest (and last) Qt 5 release is now in [testing]. This is the usual reminder that any package compiled against it must stay in [testing] until Qt itself moves.

4 6

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public June 2020