Re: [arch-dev-public] [arch-devops] New Archive Mirrors available
On Thu, 2020-12-17 at 21:57 +0100, Jelle van der Waa wrote: > I am happy to announce that thanks to Kake/PIA sponsoring us dedicated > servers, we now have three new Arch Linux Archive servers available at: > > https://america.archive.pkgbuild.com/ > https://europe.archive.pkgbuild.com/ > https://asia.archive.pkgbuild.com/ > Great! Thanks you and Kake/PIA. Regards, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
[arch-dev-public] Dropping arptables/ebtables
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 signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention
On Sat, 2020-10-24 at 00:07 +0200, Jan Alexander Steffens wrote: > On Wed, Oct 21, 2020 at 3:20 AM Sébastien Luttringer via > arch-dev-public wrote: > > Was libtraceevent 5.9 never in [community-testing]? No, like every release. > > Next time, please release the affected package to [*testing] together > with the draft. Sure, I didn't know that rule. It's written somewhere or well known habit? Regards, signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] mailman3/hyperkitty/postorius in the repos now
On Sun, 2020-02-02 at 17:48 +0100, David Runge wrote: > > Everyone, feel invited to install and test the applications and propose > fixes and expansions to the documentation (or packages) as needed. > Hello, Great! So happy you moved forward. I'll test your work with my building co-owner mailing list. For the record, the new mailman (3.x) ecosystem is split into several components (with different git and version), while the current version (2.x) has all in one scm. I remember you planned to name the package against the components names. Why did you named mailman-core to mailman3? As soon as we don't require mailman 2.x on our infra, I plan to move mailman to AUR. Cheers, signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
On Sat, 2020-01-04 at 13:08 +1000, Allan McRae via arch-dev-public wrote: > On 4/1/20 12:47 pm, Sébastien Luttringer via arch-dev-public wrote: > > One unfortunate consequence could be to have packages rely on it to make > > dependencies shorter, and make us pull cups or cronie. > > What?! That is like saying one unfortunate consequence of pamcan hooks > is that packages can have no files and just download and compile the > source in a hook. It is a ridiculous consideration. > Your extreme example seems, indeed, a ridiculous use of hooks. I hadn't realized that adding posix as a dependency on a package will be as extreme and ridiculous as the example that you have just gave. My mistake. Regards, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
On Fri, 2020-01-03 at 11:11 -0500, Eli Schwartz via arch-dev-public wrote: > On 1/3/20 10:48 AM, Sébastien Luttringer wrote: > > On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote: > > > ... > > > > > > Thoughts? > > > > I would argue that POSIX is a standard which people actually care about, > and LSB is a standard which no one cares about. I agree that few people are interested in LSB. I think it's barely the same for POSIX. Our scripts are not written POSIX compatible (i.e they rely on more tools than the standard). Do you still know people writing POSIX compatible scripts nowadays (students excluded)? The GNU Operating System (our core rely on it) have disagreements with POSIX and are de-facto non-POSIX (e.g df). I'm not able to tell you something in Arch that rely on POSIX.2 (Shell and Utilities). What make you think people care about this standard? I'm not opposed to add a posix metapackage. I'm just very reserved about its usefulness. One unfortunate consequence could be to have packages rely on it to make dependencies shorter, and make us pull cups or cronie. Cheers, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote: > ... > > Thoughts? Posix is an old standard which fail to make a common ground to Unix systems. If we think user needs meta packages to install their Arch, is the Linux Standard Base more relevant to us? Cheers, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
On Mon, 2019-11-11 at 15:41 -0500, Eli Schwartz via arch-dev-public wrote: > On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote: > As I said above, the documentation for kernel-install is pretty clear on > its expected usage. It's a one-stop shop, it executes mkinitcpio or > whatever other plugin you've installed for generating an initramfs, and > it's totally 100% independent of the mkinitcpio hook. Hi Eli, Let me first agree on the clarity of kernel-install documentation. Its goal is well summed in the man page NAME section: "Add and remove kernel and initramfs images to and from /boot. > ... > > Also, yes, kernel-install mandates the use of systemd-boot. No, kernel-install doesn't mandate use of systemd-boot. It's a modular framework to make your machine bootable. The default plugin, install kernel for systemd-boot which is different. Since 2014, I use kernel-install[1] to manage kernel upgrades on over than 300 Arch servers. There is regular Arch kernels, custom versioned kernels, some are booted with grub (uefi or not) others with systemd-boot. > Meanwhile, mkinitcpio's presets and the kernel file which was > historically installed by the linux package install directly to: > > /boot/vmlinuz-linux > /boot/initramfs-linux.img An Arch plugin of few lines could easily put the files in our historical location. This are just examples [2][3]. > Under no circumstances can we unilaterally remove mkinitcpio presets and > switch to kernel-install without a mandatory manual intervention for all > (or most) archlinux users. We can easily switch to kernel-install, without user intervention, as it was done with pacman hooks. Switching from mkinitcpio is another topic. kernel-install runs a collection of scripts (hooks), with the systemd overriding logic. There is no huge difference with the pacman hooks, except the logic is cross distro, provided by systemd, and not tied to pacman. Improvements can be shared. What it makes me prefer systemd kernel-install than pacman hooks logic. Regards, [1] https://git.seblu.net/archlinux/kernel-install-poc/ [2] https://git.seblu.net/archlinux/kernel-install-poc/blob/master/90-loaderentry-compat.install [3] https://git.seblu.net/archlinux/kernel-install-poc/blob/master/50-mkinitcpio-compat.install -- Sébastien Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
On Sun, 2019-11-10 at 18:41 -0300, Giancarlo Razzolini via arch-dev-public wrote: > 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] Hello, Nice to see that moving forward. It is a smart to move pacman installed kernel out of /boot. Why do you rely on mkinitcpio (or later dracut) to install them in /boot instead of the systemd kernel-install logic? Regards, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] new archweb release
On Wed, 2019-09-11 at 21:37 +0200, Jelle van der Waa wrote: > > - When enough signoffs are reached, archweb automatically sends a mail > to the packager that the package has reached the target signoffs! If > this is too spammy we can consider a "daily" report. > So useful feature ! Thanks. Regards, -- Sébastien Luttringer signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Proposal for a new organisation structure
On Sun, 2019-06-02 at 05:55 +0200, Christian Rebischke via arch-dev-public wrote: > On Sun, Jun 02, 2019 at 01:07:12PM +1000, Allan McRae wrote: > > On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote: > > > 1. Simplified repositories > > > Currently we have [core], [extra] and [community]. These > > > threerepositories are there, because they have grown to this structure > > > overtime. At the moment I don't see any real meaning for the split of > > > [core]and [extra]. So one suggestion would be to either: - merge [extra] > > > and [core] > > > > I stopped reading here. If you don't understand the difference > > between[core] and [extra], you should ask. Particularly before proposing > > theremoval of [core]. > > Allan > > Hi Allan,I didn't propose the removal of [core], I proposed a discussion > aroundthe current repository and organisation structure. Merging [core] > and[extra] is just one of many ideas. If you have something to say, pleasedo > so and don't keep your secret. I would be glad if you could share it. > chris Hello, [core] packages must land in [testing] and receive signoffs before reaching [core].In other words, packages in [core] must receive positive feedback before a wider diffusion.This introduce a latency to lower the risk of base components breaking. So, before merging [core] and [extra] we should have a way to flag packages which requires signoffs. Secretly, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part
