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

[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] Looking for an Arch ISO maintainer
by Jelle van der Waa 30 Mar '20

30 Mar '20

Hi all, Gerardo has stepped down as Arch ISO maintainer, which makes archiso unmaintained. I've asked Pierres if he was interested in maintaining the project and he is willing to do bug fixes when required but no major maintenance. Which means that we are looking for a new maintainer :-) To be completely honest, I am not sure what maintenance archiso requires but there are a few things I would love to see: - Proper CI / automated testing of the archiso - Reproducible archiso (patches on the mailing list) [1] - Support secure boot [2] - Accessibility improvements (patches available on the mailing list) [3] Please reply if you are interested in becoming an archiso maintainer, so far Alad has shown interested. [1] https://bugs.archlinux.org/task/63683?project=6 [2] https://bugs.archlinux.org/task/53864?project=6 [3] https://bugs.archlinux.org/task/63166?project=6 -- Jelle van der Waa

6 9

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

[arch-dev-public] Absent until next week
by Eli Schwartz 27 Jan '20

27 Jan '20

Due to a family wedding, I will be gone for a week, until late Monday Feb. 3 or Tuesday Feb. 4. I won't have internet other than limited mobile data, but can still be contacted via email/IRC, which I shall check semi-regularly. Sorry for the late notice. :) Feel free to update anything that needs updating while I'm gone. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Package openvpn in [core]?
by Christian Hesse 27 Jan '20

27 Jan '20

Hello everybody, currently the package openvpn is located in our [core] repository and it's like that since the beginning of time. [0] Following a discussion on IRC and our definition for official repositories [1] we think there is no reason to have it there. Thus I would like to move it (and its dependency pkcs11-helper) to [extra]. If you have any concern please raise your hand now! [0] https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/openvpn&… [1] https://wiki.archlinux.org/index.php/Official_repositories#core -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

3 3

[arch-dev-public] FOSDEM Dinner 2020
by Morten Linderud 21 Jan '20

21 Jan '20

Yo! Last year at FOSDEM we held a dinner with 15 people, some members from the Arch team and some users that wanted to join. It was a great event and people had a nice dinner with some nice chats afterwards on various pubs. For this year I plan to do the same with some changes. First of all, we are going to be holding it on saturday around 18:00 - 19:00 as opposed to friday. This is to ensure people are able to arrive friday evening, AND keep their phones after their dinner. I'm still looking for mine :/ To make it managable I'll cap the attendees to around 15 people. Priority for members of the Arch team (developers, trusted users and support staff). Any free spots after this can be taken by anyone interested :). Send an email *offlist* so I have some ability to keep track and inform you about further booking details. The users requesting spots will get a headsup the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) --- I have again CC'ed arch-dev-public since I don't actually know how many people watch arch-events (hinthint subscribe!). Sorry for the noise, and please do tell me if we are better off not cross-posting emails like these :) -- Morten Linderud PGP: 9C02FF419FECBE16

2 3

[arch-dev-public] rsync & bundled zlib
by Christian Hesse 16 Jan '20

16 Jan '20

Hello everybody, to date we ship rsync with bundled zlib to keep compatibility with rsync up to version 3.1.0 and it's old-style --compress option. This is no longer required with rsync 3.1.1, which was released on 2014-06-22 - nearly six years ago! The bundled zlib carries some security issues, so time to act - one way or another. Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern to finally drop bundled zlib and use system zlib? I would suggest to post a news item, feel free to give thoughts and feedback. --- >8 --- rsync compatibility Our `rsync` package was shipped with bundled `zlib` to provide compatibility with old-style `--compress` option up to version 3.1.0. Version 3.1.1 was released on 2014-06-22 and is shipped by all major distributions now. So we decided to finally drop the bundled library and ship a package with system `zlib`. Go and blame those running old versions if you encounter errors with `rsync 3.1.3-3`. --- >8 --- [0] https://packages.debian.org/de/jessie/rsync -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

4 5

[arch-dev-public] Guidelines for news posting
by Sven-Hendrik Haase 16 Jan '20

16 Jan '20

Hi all, in light of recent events, we had a little get-together in #archlinux-staff to hack on an initial suggestion on guidelines for news posting. If we can agree on these, they should be added on the news posting page on archweb (and perhaps somewhere on the wiki). The draft we came up with is this: Every news post needs to have a corresponding draft submitted to arch-dev-public and wait for feedback for at least 24 hours unless: 1. it is urgent (and would be too late after 24 hours) 2. it is a simple --overwrite rule, or 3. there are strong reasons for the team member posting the draft to believe that it should not be visible to the public before it is announced. In this third case, the draft should be submitted to the staff(a)lists.archlinux.org ML instead. Happy to hear about feedback. Cheers, Sven

2 3

[arch-dev-public] Todos for language specific rebuilds
by Christian Rebischke 13 Jan '20

13 Jan '20

Hi everybody, I would like to propose that we create todos for rebuilds of language specific packages. We had two major rebuilds in the last months: python3.8 and ruby2.7. Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain: * More people help rebuilding the packages. * Every maintainer gets informed about the rebuild. * Maintainers have the possibility to test the packages. If tools exist for creating todos, I would like to ask the persons with such tools to make them available for everybody (if not already happened). Greetings, shibumi

6 7

Re: [arch-dev-public] Todos for language specific rebuilds
by Anatol Pomozov 12 Jan '20

12 Jan '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On 2020-01-12 at 00:04, arch-dev-public(a)archlinux.org wrote: > On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public wrote: > > Hi everybody, > > > > I would like to propose that we create todos for rebuilds of language > > specific packages. > > > > We had two major rebuilds in the last months: python3.8 and ruby2.7. > > > > Can we agree that we create a todo before such rebuilds? > > The advantages outweigh the disadvantages. We would gain: > > > > * More people help rebuilding the packages.' > > What help is needed? If this is just about having more people sed the > pkgrel variable with "$pkgrel + 1", then try to build it, more people > doesn't actually help. We have automated rebuilders which are very > capable in this regard. > > > * Every maintainer gets informed about the rebuild. > > I agree with you that this is indeed a problem, and I would like to > propose a pretty simple solution. Let's post on arch-dev-public to give > people a heads-up. > > This means even if your package failed to be detected for rebuilding and > would never appear on any TODO, you as a maintainer know that it > happened and can manually rebuild your package. > > > * Maintainers have the possibility to test the packages. > > At least for the python rebuilds, the process of rebuilding the > ecosystem is long and painfully drawn out, *because* packages with > failing testsuites cannot be rebuilt automatically and go onto a TODO > list of broken packages. > > Given this thread started because we just rebuilt ruby, can I assume > that PKGBUILDs for ruby packages are in the general habit of not > containing check() functions for running unittests? Either because > upstream does not have unittests or because they are not being run? > > If packages have upstream unittests but don't run them, then the > maintainer of the package has been derelict in his or her duty. > > If packages do NOT have upstream unittests, then this is unfortunate, > and I don't currently have an answer for what we should do. :( > > > If tools exist for creating todos, I would like to ask the persons with > > such tools to make them available for everybody (if not already > > happened). > > It's a website submission form that expects you to write some > explanatory message, then fill in a newline-separated list of pkgnames. > Any rebuilder must by definition have the latter, even if that rebuilder > is "I scrolled through archweb and did it all manually by flipping back > and forth between my terminal and my browser". > > No "tool for creating todos" need exist. Ask instead about tools for > enumerating language dependencies. > > ... > > For python, it's pretty simple. > > pkgfile -d '/usr/lib/python3.8/' > > For ruby, it's also pretty simple: > > pkgfile -d '/usr/lib/ruby/' Here are the instructions that I used to find the ruby packages https://gist.github.com/anatol/670a2768a97789d6a96b33010b7fedca -----BEGIN PGP SIGNATURE----- Version: FlowCrypt 7.4.2 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCgAGBQJeGmgKAAoJELAoVO11Pg8fwTsQAJtOyNvia5wXkkTsdjrQ LLkLRw2EF79mMbJa+zN6/H7m/lJAIdZKXFjWmhar3lt+52d0J+7+WHPrqHH0 151hpuJ6SJpceGDkzbfIST9/i+++HcUB6a9vDcJPEx8RqYQFMPH/4JxGndCR Dg7bi2f9PzmYsv9KkZ6JsJ13Z/jRfiVozGf0J9b+xi79Z5Y5RMM91Q2hp8gR 6HFRw+S8+0j5P+1MlDlSSjPmflvC3wsYDRqcDZuaXtArmqb1BiGAK6s6d4aQ L11LQSdP8clgYfGPJpk4U37SDSyrkTaBM5yWQLPaKVB7DY2Z81OGd3Z34tMj QWsh/LZjgqtEOl+WkGcF2ykSa+mjpdyxrttotDh6Mwwa+7YFNxWMQiSO8Hmd Z1iI3SCzIhQ33t/3raE0MDSJM8nEQwwrkyI2nr0C2BFUEIwMkiRkcLr3KDwf MQI3Q9X3A0Fo5xwzWcEEjbJjwjGz9fzPcDh0JeOUs/e9Ck1TL/n4qwqhPeUr kJFrrzEAD6YcXCTdbudHFnbmrdDd0wdTpb2SAYZuKWhYusEMWn1oxDK6TnLe 5ufVTXP9uQyG5xoEUX95L4S0GAGqJ6jU9dY+B1TTfRZg+bG6nq+FdpverzHB WVN9opo7WqL8sE1fifViBbWo20KV0BCv3vUyFFBYkCLVcoIWgeeLHFZUegmr p/nl =4pkk -----END PGP SIGNATURE-----

1 0