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

[arch-dev-public] Dropping arptables/ebtables
by Sébastien Luttringer 13 Apr '21

13 Apr '21

Hello, I would like stop maintaining arptables and ebtables and drop them in [unsupported]. The future in the linux kernel is clearly nftables and keeping them in the repository present is of little interest these days. ebtables is still an hard dependency on others packages, but the iptables-nft package ship a remplacement based on nftables. I have not tested the compatibility, so if someone think it's not possible, please let me know. If you have spare time, I suggest you take a look at the nftable package and become a master in nft-fu. It is much more convenient and efficient than the iptables / ipset / ebtables / arptables solution. For the less enthusiastic about the command line, firewalld has an nftables backend. Regards, Sébastien "Seblu" Luttringer

2 2

[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] Arch Linux in GSOC 2021
by Konstantin Gizdov 01 Feb '21

01 Feb '21

Hi all! Last year Arch Linux applied to be a mentoring organisation in the Google Summer of Code program. There were quite a few cool projects and lots of keen people. Unfortunately, we were not selected. However, I was hoping people are excited about trying again this year as well. I have already been contacted by a couple of people who saw the GSOC page on the Dev Wiki and are showing quite some interest. I presume, if we advertise we will get a lot of interested people. GSOC application period starts on January 29, 2021 for mentoring organisations and closes on February 19, 2021. We should make sure we satisfy the requirements [1]: 1. Mentor organisations must run an active open source or free software project. 2. Have produced and released software under an OSI approved license [2]. 3. Must not be based in a country currently embargoed by the United States. I think we do fall into those categories and I would suggest this year we start preparing a bit earlier to improve our chances. Let's try and coordinate an effort. Maybe start with the people keen on mentoring and collation of prospective project ideas. [1] - https://summerofcode.withgoogle.com/get-started/ [2] - https://opensource.org/licenses -- Regards, Konstantin

3 3

[arch-dev-public] Decommissioning dragon and upgrading to new box
by Sven-Hendrik Haase 30 Jan '21

30 Jan '21

Hey everyone, A new sponsorship term for dragon (our build server for those who weirdly enough don't know) was coming up and as the box was getting pretty slow for 2021 I felt perhaps we should also try for an upgrade. Anyway so Hetzner kindly agreed to give us a sponsorship deal for a bigger box which is roughly twice as fast as dragon. It'll be called "mir" and will be made available in the next few days. dragon is scheduled to be decommissioned on the 19th of January. Since nobody is supposed to be storing any data on dragon, we won't be performing a home directory transfer. Still, if there's any data you care about on dragon, please back it up until the 19th. Have fun with the new box! Cheers, Sven

1 2

[arch-dev-public] Chromium losing Sync support on March 15
by Evangelos Foutras 28 Jan '21

28 Jan '21

It looks like Sync will only work with official Chrome starting two months from now. [1] It is understandable to some extend, perhaps to guard against malicious applications using unofficial (non-Chrome) API keys and tricking users to log into their account. This argument doesn't hold much ground in the context of trusted builds like our chromium package, but I doubt Google would bother to work with us (i.e.: each individual Linux distro) on this to find a workable solution going forward. This is intended as a heads-up; I am not sure what we're going to do yet. [1] https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

16 33

[arch-dev-public] build.archlinux.org now available
by Sven-Hendrik Haase 26 Jan '21

26 Jan '21

Hello all, A new bigger and badder build box is now available to all packagers at build.archlinux.org. home dirs (but not .cache) have been transferred to the new box from dragon and all users should have access. The new box, as previously mentioned, is roughly twice as fast as dragon and has enough memory and storage to handle some load. dragon is scheduled to be decommissioned on the 31st of January so you still have some time to check whether everything was properly transferred. Have fun! Sven

3 3

Re: [arch-dev-public] News draft: PHP 8.0 is available
by Pierre Schmitz 26 Jan '21

26 Jan '21

Thanks for the ihint. I'll use "suffix" instead. (I did a brief research about the difference between postfix and suffix; I can't say I fully understand it :-)) 'll also add a note about the modules that are available for php7 as well as users might need to manually install them. I'll probably post this tomorrow or the day after. Greetings, Pierre On Mon, Jan 25, 2021 at 8:19 PM Chester Wisniewski <chetw(a)zuzax.com> wrote: > > I would recommend changing "postfix" to suffix. Postfix is a package, suffix works better in English. > > Chester > > -----Original Message----- > From: Pierre Schmitz via arch-dev-public <arch-dev-public(a)lists.archlinux.org> > Reply-To: Public mailing list for Arch Linux development <arch-dev-public(a)lists.archlinux.org> > To: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> > Cc: Pierre Schmitz <pierre(a)archlinux.de> > Subject: [arch-dev-public] News draft: PHP 8.0 is available > Date: Mon, 25 Jan 2021 19:04:51 +0100 > > Hi all, > > I'd like to move the PHP 8 rebuild to [extra] soon. Here is a little > news draft to mainly inform users about the new php7 package for > legacy software: > > --- > The php package has been updated to version 8.0(1). Please refer to > the upstream migration guide(2). As some applications are not > compatible with PHP 8 yet we provide a php7 package which can be > installed alongside version 8. Packages that depend on PHP reflect > this update and will require php7 if needed. You might need to update > your configuration accordingly. PHP 7 binaries and configuration have > the "7" postfix: > * /usr/bin/php -> /usr/bin/php7 > * /etc/php -> /etc/php7 > * /usr/bin/php-fpm -> /usr/bin/php-fpm7 > * /usr/lib/systemd/system/php-fpm.service -> > /usr/lib/systemd/system/php-fpm7.service > * /run/php-fpm -> /run/php-fpm7 > Note that support for php7 will be limited and likely be dropped in > about a year(3) depending on how soon the majority of applications > will be compatible with version 8. > --- > 1) https://www.php.net/releases/8.0/en.php > 2) https://www.php.net/manual/en/migration80.php > 3) https://www.php.net/supported-versions.php > > Let me know if I should add or change anything. > > Greetings, > > Pierre >

1 0

[arch-dev-public] News draft: PHP 8.0 is available
by Pierre Schmitz 25 Jan '21

25 Jan '21

Hi all, I'd like to move the PHP 8 rebuild to [extra] soon. Here is a little news draft to mainly inform users about the new php7 package for legacy software: --- The php package has been updated to version 8.0(1). Please refer to the upstream migration guide(2). As some applications are not compatible with PHP 8 yet we provide a php7 package which can be installed alongside version 8. Packages that depend on PHP reflect this update and will require php7 if needed. You might need to update your configuration accordingly. PHP 7 binaries and configuration have the "7" postfix: * /usr/bin/php -> /usr/bin/php7 * /etc/php -> /etc/php7 * /usr/bin/php-fpm -> /usr/bin/php-fpm7 * /usr/lib/systemd/system/php-fpm.service -> /usr/lib/systemd/system/php-fpm7.service * /run/php-fpm -> /run/php-fpm7 Note that support for php7 will be limited and likely be dropped in about a year(3) depending on how soon the majority of applications will be compatible with version 8. --- 1) https://www.php.net/releases/8.0/en.php 2) https://www.php.net/manual/en/migration80.php 3) https://www.php.net/supported-versions.php Let me know if I should add or change anything. Greetings, Pierre

1 0

[arch-dev-public] Goodbye
by Bartłomiej Piotrowski 23 Jan '21

23 Jan '21

Hi everyone, I'm stepping down as a developer. It's been mostly fantastic ride for the last 10 years but it's clear to me now that for better or worse it's far from the project I initially joined. Thank you and good luck with everything, Bart

11 10

[arch-dev-public] State of PHP 8 update
by Pierre Schmitz 23 Jan '21

23 Jan '21

Hi all, as people start asking me when to expect PHP 8 packages in our repos, here is a quick update: * For those who seek adventure, I'll already have version 8 in my unofficial repo * A lot of the libraries I tested do not work with PHP 8 yet. E.g. Doctrine, Elastic-Search, ... * Software that was written for PHP 5 and was never properly ported to 7 will not work; e.g. FluxBB we use for our Forums * Updating software to work with PHP 8 is quite easy though and I expect way less issues than the back in the days when we transitioned from 5 to 7 * A lot of developers use Arch, therefor I would like to provide PHP 8 as soon as possible which in turn should speed up the migration or everybody * I will check if we could provide php7 packages alongside version 8 so people can start developing for 9 but still are able to run some apps with 7. PHP 7 will be supported by upstream for almost 2 years: https://www.php.net/supported-versions.php I'll keep you updated. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

1 5