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

[arch-dev-public] Deprecating systemd-swap
by Felix Yan 09 May '21

09 May '21

As per suggested by upstream [1], systemd-swap is now deprecated and will be removed from [community] in the following days. zram-generator has been added to [community] as the suggested alternative. [1] https://github.com/Nefelim4ag/systemd-swap#users-should-migrate-to-systemdz… -- Regards, Felix Yan

1 0

[arch-dev-public] Barthalion's orphan packages
by Jelle van der Waa 09 May '21

09 May '21

Hi, I've removed Barthalion as maintainer from the last packages in archweb, these packages are now orphan and would like a new maintainer. If any of the packages need to be moved to the [community] please ask :) * libnss_nis * rpcsvc-proto * dejagnu * xdg-dbus-proxy * flatpak * flatpak-builder * xdg-desktop-portal * xdg-desktop-portal-gtk Greetings, Jelle

2 1

Re: [arch-dev-public] Spring cleanup '21
by Antonio Rojas 08 May '21

08 May '21

El miércoles, 28 de abril de 2021 22:26:13 (CEST), Santiago Torres-Arias via arch-dev-public escribió: > Unless there be dragons, I could happily pick up munin and > procinfo-ng... Since nobody objected, I moved procinfo-ng to [community], please adopt (and munin too) I dropped all remaining ones to AUR, except for: - dictionaries - these are low-maintenance and it's convenient to have them in the official repos. I moved all the orphan ones to [community] though, so TUs can maintain them. - asp - since it's an Arch project, I guess we want to keep it? - icewm - seems rather popular

1 0

[arch-dev-public] Call for organisers for an online conference
by Jelle van der Waa 03 May '21

03 May '21

Hi All, Last year we had an amazing event organised by Foxboron, dvzrv and many other volunteers. For this year Foxboron and dvzrv have decided to not organise an event and rather focus on planning an in-person event for 2022. For an online event to happen in 2021, a new team has to be formed to organise the event. Foxboron and dvzrv are willing to assist in helping out with the how to organize the event. The workload depends a bit on the intended scale. But a few months with bi-weekly meetings gets you there. The current discussion channel is #archlinux-conf. Please reach out if you are interested in organizing the event :) Cheers!

1 0

[arch-dev-public] archlinux.org update
by Jelle van der Waa 01 May '21

01 May '21

Hi All, Today I've updated archlinux.org with some interesting changes for packagers. Two new reports have been added: * A new report which includes all required orphan packages in our repositories. [1] * A new report which which includes all orphan non reproducible packages [2] The non reproducible packages dashboard now includes links to the build log and diffoscope output of the packages. Which should help fixing those packages. Lastly archweb now parses the links databases which exists in our repository. So as alternative to 'sogrep' curl -s "https://archlinux.org/packages/sonames?name=libwebsockets.so" | jq '.[].pkgname' "kismet" "libwebsockets" "ardour" "csound" "mosquitto" "kismet" "libwebsockets" This is still a bit alpha-ish as there seems to be some issues with updating the data. [4] Feedback is welcome, as I just realized it shows packages for all repositories so some people might want a filter on "stable" or "testing" or "staging" repositories. Finally what sonames the package requires is shown in the package detail page [6] [1] https://archlinux.org/devel/reports/required-orphan/ [2] https://archlinux.org/devel/reports/orphan-non-reproducible-packages/ [3] https://archlinux.org/devel/reports/non-reproducible-packages/jelle/ [4] https://github.com/archlinux/archweb/issues/342 [5] https://archlinux.org/packages/extra/x86_64/libwebsockets/ [6] https://archlinux.org/packages/extra/x86_64/libwebsockets/ Greeting, Jelle van der Waa

4 3

Re: [arch-dev-public] Spring cleanup '21
by Antonio Rojas 29 Apr '21

29 Apr '21

> Unless there be dragons, I could happily pick up munin and > procinfo-ng... Moved munin. procinfo-ng is in [core], I'll give people a few days to raise objections against moving it out (hopefully joined by an offer to maintain it).

1 0

[arch-dev-public] archlinux-tools group
by Jelle van der Waa 25 Apr '21

25 Apr '21

Hi All, I've introduced a new group "archlinux-tools" for arch-rebuild-order and orhun will add it to arch-repro-status. I'm planning to add arch-signoff, and ask Fox to add archlinux-contrib as well. The idea is that Arch Linux related tools which benefit packaging get added to the archlinux-tools group. P.S. check out arch-repro-status, it's an awesome tool to inspect your non-reproducible packages! Greetings, Jelle van der Waa

3 3

[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] Dropping packages to AUR
by alad 09 Apr '21

09 Apr '21

Hi, As I no longer use them, I will drop the following packages to AUR unless someone picks them up: * deadbeef * mit-scheme * mksh * python-kitchen * qjournalctl * diffstat * rtv * xkcdpass The following packages are dependencies of existing packages, and could equally use a new maintainer: * diffstat (dependency for quilt) Cheers, Alad

1 1

[arch-dev-public] RFC Final Comment Period: Provide a x86_64_v3 microarchitecture level port
by Allan McRae 25 Mar '21

25 Mar '21

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Please visit the above link for discussion. (Note much discussion in that link is relevant for the prior proposal of using x86-64-v2 as a baseline.) Summary: Provide a x86_64_v3 microarchitecture level port Build packages for both --march=x86-64 and --march=x86-64-v3. Assuming SSE4 and AVX2 (and others) while compiling will provide greater out-of-the-box performance in Arch Linux. Note, the exact implementation of this change is not discussed in the RFC. I'm of the opinion that RFCs are about ideas, so do not always need to go into full implementation details. However, to provide packages for two architectures we could (1) have packagers build both, (2) bring in packagers to keep the architectures in sync, (3) have a bot do it automatically. I'd guess a combination of 1+2 initially, and add 3 once we get the signing enclave running. Or 3 could be done with a variant of the rebuild system where jobs spawn out to available build machines. Also, we need both gcc-11 and clang-12 to be released to provide support for the x86-64-v3 variant. And support for enabling multiple architectures in pacman needs to be implemented (though we do have a 9 year old patch that did that!). So this will not happen overnight.

1 0