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

[arch-dev-public] News draft: sorting old password hashes
by Christian Hesse 06 Jun '21

06 Jun '21

Hello everybody, old password hashes like MD5 are no longer accepted by recent libxcrypt. On next login user may be enforced to update password. To make sure nobody is worried I would like to add install message and news post: --- >8 --- Starting with libxcrypt 4.4.21 weak password hashes are no longer accepted. If you still have one in your shadow file do not worry if you are enforced to update your password on next login. --- >8 --- -- 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] Transitioning out my master key
by Allan McRae 06 Jun '21

06 Jun '21

It is time for my master key to be retired. That can not happen any time soon, as revoking my key means ~25% of packagers will not be able to validly sign packages... For now, I will no longer be signing new packager keys with my master key. I am unlikely to revoke signatures for people who retire from packaging either. Allan

3 2

[arch-dev-public] retracting libxcrypt 4.4.22-1 from [testing]
by Christian Hesse 06 Jun '21

06 Jun '21

Hello everybody, the testing package libxcrypt 4.4.22-1 was reported to be bad... Andreas was forced to change his password on login, which resulted in him being locked out of his system. We are trying to clarify... So I removed libxcrypt from [testing] for the time being. -- 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);}

1 1

[arch-dev-public] TIER 0 Mirror Access for All
by Jelle van der Waa 03 Jun '21

03 Jun '21

Hi All, For everyone with the correct role (Developers, Trusted Users or Support Staff) the tier 0 mirror is available for usage to get the absolute latest packages. The authentication is done with a basic auth which pacman supports and a token has to be generated in archweb to be able to use the mirror. [1] Note that the mirror is mostly useful for rebuilds or when you require the absolute latest packages the server is located in Germany so might not be ideal for everyone. [1] https://archlinux.org/devel/tier0mirror/ Greetings, Jelle van der Waa

1 0

[arch-dev-public] New Arch Linux Developer: Jonas Witschel (diabonas)
by Levente Polyak 15 May '21

15 May '21

I would like to welcome Jonas Witschel (diabonas) among the Arch Linux Developers. Jonas has been a Trusted User since 2019 and lately joined the Arch Linux Security Team. We wish you good luck and joy with your new responsibilities within Arch Linux! cheers, Levente

3 3

[arch-dev-public] GCC 11 and new toolchain on [testing]
by Giancarlo Razzolini 14 May '21

14 May '21

Hi, GCC 11 and a new toolchain rebuild has lended on [testing]. So, until it's moved, if you build anything that uses gcc against testing, it'll have to wait and be moved together. Also, if you guys notice any issues, let me know. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] gnupg 2.3.1-1 pulled from [testing]
by Morten Linderud 11 May '21

11 May '21

Yo! It seems like gnupg 2.3.1-1 was built and pushed to [testing] briefly before being removed. The reason from the removal is because there are changes to how gnupg verifies signatures that depends on the key UIDs being properly signed. In the case of my key, "foxboron(a)archlinux.org" is of marginal trust while "morten(a)linderud.pw" is fully trusted. Since packages are signed with "--sender foxboron(a)archlinux.org" gnupg cares about this trust level starting from 2.3.0-1. This results in failing signature checks if you have this package and attempt to fetch packages signed by me. Related issue: https://dev.gnupg.org/T4735 Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch? To testers: The best course of action is to downgrade the gnupg package to 2.2.27-1 from the package archive or your local package cache. https://archive.archlinux.org/packages/g/gnupg/ <sidenote> gnupg is terrible :) </sidenote> -- Morten Linderud PGP: 9C02FF419FECBE16

4 6

[arch-dev-public] Spring cleanup '21
by Antonio Rojas 11 May '21

11 May '21

It's been over a year since our last package cleanup and orphans keep piling up. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you'd like to keep in the repos. If you are not a dev and would like to adopt some orphan in [extra], reply here or ping me on IRC and I'll move it. I'll start dropping the remaining packages to AUR in about 10 days.

6 8

[arch-dev-public] Disowning ruby packages
by Felix Yan 09 May '21

09 May '21

Hi All, I am disowning most of my ruby packages since I don't use any of them nowadays. Please consider adopting the following ones as they are now orphans: ruby-cairo ruby-faraday-middleware ruby-ffi ruby-multi_json ruby-power_assert ruby-test-unit -- Regards, Felix Yan

1 0

[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

[arch-dev-public] On holiday for the next 2 weeks
by Eli Schwartz 24 Mar '21

24 Mar '21

It's that time of year again, the Passover holiday, so I'll be irregularly available or simply offline for days at a time until April 6 or thereabouts. I'll try to catch up with messages when I get a chance (expect delays!), but I'll be getting very little actual work done. Please feel free to bump my packages for me. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Looking for co-maintainers
by Balló György 21 Mar '21

21 Mar '21

Hi all, Recently I have less interest in keeping my packages up to date. So I'm looking for co-maintainers for my packages [1], especially for the following ones, which are most frequenly updated: - blueberry - converseen - coolreader - deja-dup - drawing - eolie - featherpad - flowblade - gnome-boxes - gnome-initial-setup - gnome-passwordsafe - gpodder - gpxsee - gst-editing-services - mailnag - openbve - osinfo-db - photoflare - python-owslib - python-pykeepass - qgis - rssguard - synfig - tupitube - xarchiver Please let me know if you are interested in adopting any of them. [1] https://archlinux.org/packages/?maintainer=bgyorgy Thanks, György Balló Trusted User

1 0

[arch-dev-public] Arch Linux partners with Nitrokey to equip its staff with USB keys
by Levente Polyak 16 Mar '21

16 Mar '21

We are happy to announce that Arch Linux has partnered with Nitrokey [0] to equip its staff with free Nitrokey devices. We will use the Nitrokey devices to store cryptographic keys for signing of git commits, emails and software packages, GnuPG keys, and SSH accounts. Thanks to the Nitrokey’s discount and the Arch Linux funds, each Arch Linux staff is eligible to receive one free Nitrokey Pro 2 or hopefully soon the new Nitrokey 3. To receive their Nitrokey, eligible staff will need to register with their @archlinux.org email address at the dedicated order form. Further instructions about this process will be sent to our staff. A Nitrokey Guide will be made available on the Arch Linux Wiki with FAQ & instructions for integrating Nitrokeys into our workflow. Nitrokey Pro 2 provides strong reliable hardware encryption. It has open source firmware, is open hardware and can help you to: sign Git commits; decrypt emails and files; secure server access; and protect accounts against identity theft via two-factor authentication (one-time passwords). Furthermore, the new Nitrokey 3 will support additional features like FIDO. Nitrokey is a German IT security company committed to open source hardware and software. Nitrokey develops and produces USB keys for data encryption, email encryption (PGP/GPG, S/MIME), and secure account logins (SSH, two-factor authentication via OTP and FIDO). Besides their hardware products they offer services, consulting and help you with concept, development and certification of your specific security solutions. Nitrokey is proud to support Arch Linux in further securing its infrastructure and contributing to a secure open source Linux ecosystem. [0] https://www.nitrokey.com/

1 0

[arch-dev-public] Tracking different CPU architectures with pkgstats
by Pierre Schmitz 16 Mar '21

16 Mar '21

Hi all, while reading Allan's RFC about increasing Arch's CPU requirements(*) I had the idea to start tracking the different x86_64 architecture level using pkgstats. I am sure whether to drop support for old CPUs is not a matter of "if" but "when"; similar as it was with i686. Therefore it should help to have a rough estimate about which CPUs our users have and how the numbers develop over time. While I am at it, I'd like to also support different ARM architectures provided by archlinuxarm.org (or maybe even i486/i686 by archlinux32.org) There is a small catch though and the reason I am asking for your opinion: While we will know how many users use which architecture, all package usage data will be aggregated regardless of architecture. This means for a given package we cannot tell how often it is used on a specific architecture compared to others. I do not think that this would matter for most packages though. Greetings, Pierre *) https://gitlab.archlinux.org/archlinux/rfcs/-/blob/c5ee0eb715a01c6cd10aa5a9…

4 7

[arch-dev-public] Killing python2 v3...v4...v5
by Morten Linderud 15 Mar '21

15 Mar '21

Yo! As people know python2 has been unsupported for a year and we current have ~170 python2 packages in our repositories. Currently the removal has been fairly slow and done a bit ad-hoc. There has been a todo list but the follow up to that has not really been great and I think it's reasonable for us to try and fix the remaining packages to the best of our abilities. Thus I'm proposing a game plan! 1) Todo list for removal of all python2 checkdepends in packages 2) Remove free python2 packages 3) Remove packages with python3 equivalents 4) Remove unported and unsupported packages depending on python2 Clearly this is ambitious and there are going to be exceptions, but it would be great to have most of this work done within the next couple of months. The exceptions are largely going to be anything still using python2 for their build system dependencies. This is a fine compromise as this should leave us with a minimal set of packages to take care of. Rest of the problematic packages can be found on a handy list with what fedora is working on: https://fedora.portingdb.xyz/ If there are no objections I'll start preparing the needed todo lists and figure out the uneeded python2 packages. Should probably update the long-standing python2 removal todo as well. https://archlinux.org/todo/conversion-of-programs-that-use-python-2-to-pyth… Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

4 5

[arch-dev-public] RFC: Provide an x86_64_v3 microarchitecture level port
by Allan McRae 14 Mar '21

14 Mar '21

Hi all, A "new" RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Summary: This RFC is proposing adding an x86_64_v3 port in Arch Linux. Assuming SSE4 and AVX2 (and others) while compiling will provide greater out-of-the-box performance in Arch Linux. This is a rework of the previous RFC regarding bumping the baseline to x86-64-v2. The comments on that RFC indicated that providing multiple architectures would be the preferred approach. While implementation details are do not necessarily needed to accept the RFC, devtools is set up for handling both architectures as a relic of the i686 days. There are a couple of pacman considerations needed around the "Architecture" configure option. Your friendly pacman dev will likely add the ability to have people install packages from multiple architectures, so people using x86_64_v3 can still use x86_64 packages when needed (e.g. user supplied repos that only build for one architecture). There will need to be further discussions about autobuilding vs packages uploading two variants, vs a team keeping x86_64_v3 in sync with the main port (or a combination of all of the above!). Again, just flagging the full implementation details are in progress. The RFC is just about whether this is the approach we should take. Please visit the above link for discussion. Allan

1 0

[arch-dev-public] RFC: Use x86_64-v2 architecture
by Allan McRae 12 Mar '21

12 Mar '21

Hi all, A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs: CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 Please visit the above link for discussion. Allan

8 29

[arch-dev-public] RFC Final Comment Period: Enable LTO by default
by Allan McRae 12 Mar '21

12 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/4 Please visit the above link for discussion. Summary: Enable LTO by default in our packages. In the interests of a fair discussion, I will highlight the disadvantage that was brought up during the initial discussion period: The use of LTO can cause the memory usage of GBD to markedly increase. It can also make debugging more difficult due to inlining across build units. Interestingly, the increased memory usage was bought up due to packages that already use LTO in their build system! But should be a consideration for larger pieces of software. Note that this RFC can not be implemented until pacman-6.0 is release (which may or may not be a while away), unless a couple of small patches are backported by the package maintainer. It may be worth timing this RFC and the buildflags one to occur at the same time.

1 0

[arch-dev-public] FC Final Comment Period: Buildflag updates
by Allan McRae 12 Mar '21

12 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/3 Please visit the above link for discussion. Summary: Update the buildflags in makepkg.conf to: #CPPFLAGS="" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" DEBUG_CFLAGS="-g -fvar-tracking-assignments"

1 0

[arch-dev-public] glew-wayland
by Alexander F Rødseth 09 Mar '21

09 Mar '21

Hi, I'm planning to move glew-wayland to AUR, ref: https://bugs.archlinux.org/task/56025 -- Sincerely, Alexander F Rødseth / xyproto

1 0

[arch-dev-public] RFC: Build using LTO by default
by Allan McRae 04 Mar '21

04 Mar '21

Hi, When pacman-6.0 is release, makepkg will provide the option to build packages using Link Time Optimisation (LTO) by default. This provides smaller, faster executables/DSOs, and improves GCC diagnostics. SUSE saw an average 5% decrease in binary size. In short, makepkg.conf will have: OPTIONS=(.... lto) When enabled, makepkg with add -flto to CFLAGS/CXXFLAGS The use of LTO can be disabled as needed in a PKGBUILD: options=('!lto') For full details and to comment, see: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/4 Allan

1 0

[arch-dev-public] RFC: Buildflag updates
by Allan McRae 04 Mar '21

04 Mar '21

Hi, Now we have had some controversy... lets look at some easier RFCs! The first is about additions to build flags. Specifically, our makepkg.conf would look like: #CPPFLAGS="" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" DEBUG_CFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments" For full details and to discuss the changes, please look at: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/3 Allan

1 0

[arch-dev-public] RFC: Using RFCs
by David Runge 02 Mar '21

02 Mar '21

Dear staff, I have begun work on a Request for Comment (RFC) process for Arch Linux and I am excited to now be able to open the first RFC... to introduce "Using RFCs" :) A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 Please visit the above link for discussion. Summary: A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment. Best, David P.S.: To all staff members, that do not have an SSO account yet, please get in touch with Sven-Hendrik Haase <svenstaro(a)archlinux.org> to be signed up and be able to participate in the discussion. -- https://sleepmap.de

5 10

[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] News draft: Moving to Zstandard images by default on mkinitcpio
by Giancarlo Razzolini 17 Feb '21

17 Feb '21

Hi Guys, So, mkinitcpio-30 (on [testing]), uses zstd by default for initramfs images, since all our kernels now support it. I plan to move mkinitcpio in the next 24-48 hours but, since I anticipate some people holding back 5.4 kernels, I want to send the following news announcement (here [0] is the md I'm using, so feel free to help there): ---- All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing]. If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf COMPRESSION to use one of the compressors supported, like gzip, otherwise you *will not* be able to boot images generated by mkinitcpio. Regards, Giancarlo Razzolini [0] https://md.archlinux.org/zh8Ac75qQPSieS8ftGBkIg

3 4

[arch-dev-public] hardlink in util-linux
by Christian Hesse 17 Feb '21

17 Feb '21

Hello everybody, upstream util-linux replaced the current implementation of hardlink (which we do not ship) with Debian's [0]. For util-linux 2.37 I plan to package the hardlink executable and set provides, conflicts and replaces on hardlink package. Any objections? [0] https://github.com/karelzak/util-linux/commit/2180ecc81b5f7635adbe541201064… -- 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 2

[arch-dev-public] New archweb release
by Jelle van der Waa 14 Feb '21

14 Feb '21

Hi All, A new archweb release has been deployed on archlinux.org which features a new user facing change in the todolist functionality. When creating a todolist it's now possible to specify the "kind" of todolist either a "rebuild" or "task". A "rebuild" should be used for rebuilds as usual, a task for for basically everything which isn't a rebuild and usually doesn't go through [staging] etc. for example [1]. In the future archweb will be able to show the move commands for when a rebuild todolist is complete and there is work being done on detecting overlapping rebuilds. Another minor change which is not visible yet, is the importing of the rebuilderd build_id so in the future the non reproducible dashboard will have links to diffoscope/build log output. [1] https://archlinux.org/todo/remove-svn-propset/ Greetings, Jelle van der Waa

2 1

[arch-dev-public] strip command of binutils 2.36 changes ownership in fakeroot 1.25.3
by Levente Polyak 10 Feb '21

10 Feb '21

Hi all, We were recently made aware by a bug report [1] that when the strip executable from binutils 2.36-3 in [core] is run within a fakeroot, it does not keep the correct file ownership during stripping, but indiscriminately assigns ownership to root:root instead. This causes issues with executables that make use of setuid, setgid or capabilities and should be owned by a user other than root. The incorrect ownership in combination with these attributes could lead to a potential local privilege escalation. The issue is caused by the fact that binutils 2.36-3 is compiled using glibc 2.33, thus using a new syscall that fakeroot does not intercept correctly [2]. Following the bug report, pacman was patched [3] to correctly handle file ownership during stripping itself, instead of relying on binutils to restore the correct ownership. Additionally, all packages built with binutils 2.36 were scanned for usage of setuid, setgid or capabilities (either during packaging or using an install script). A small number of packages was found, but these turned out to be false positives or operated on files that are already supposed to be owned by root anyway. We conclude that users were not exposed to any vulnerable packages affected by this issue [4]. Note that the fix to pacman only covers the stripping process run automatically by pacman. If strip is run inside a PKGBUILD, either manually or as part of a build system like qmake [5], file ownership will still be set to root:root. Please double-check all your packages to see whether they execute strip on files that should not be owned by root. Since it is unclear when fakeroot will be updated to work with glibc 2.33, permissions will have to be fixed manually after running strip by an appropriate chown call in this case. Note however that generally strip should not be run inside a PKGBUILD at all as it breaks creating debug packages, and should be disabled if run by default by the build system. [1] https://bugs.archlinux.org/task/69584 [2] https://sourceware.org/pipermail/binutils/2021-February/115252.html [3] https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9… [4] https://md.archlinux.org/TAiOYgKzQl-1cJxDaQlB_g [5] https://github.com/archlinux/svntogit-packages/commit/138105f29cb29d7b7ebdf… Greetings, Arch Linux Security Team

1 0

[arch-dev-public] Celebrating the 1000th Arch Linux Security Advisory
by Levente Polyak 08 Feb '21

08 Feb '21

It has been a long ride since our first Arch Linux Security Advisory released in September 2014 [0], but we are proudly announcing our 1000th published advisory [1]. In early days, the user RbN started some efforts [2] to track issues in the ArchWiki. The journey of our team began with a call for help by our long-time developer Allan McRae [3], which -- as a joint effort of Remi Gacogne (rgacogne) and Levente Polyak (anthraxx) [4] -- lead to the founding of the structured effort known today as the Arch Linux Security Team. Without doubt the work and analysis is challenging and the overall workload massive. During our ongoing journey we have grown quite a lot and are happy to welcome Christian Rebischke (shibumi), Jelle van der Waa (jelle), Santiago Torres (sangy), Morten Linderud (Foxboron), Andrea Denisse Gómez (denisse) and Jonas Witschel (diabonas) to our team. Together we are able to offer a strong and successful security team that is continuously expanding and re-evaluating capacities to cover a broader area of our distro. In December 2016 during the annual Chaos Communication Congress, we released our central security tracker [5] to streamline our vulnerability tracking and mitigation workflow. The tracker replaces the ArchWiki page which was used previously for this purpose. For further details on our adventure, we would like to invite you to watch the Arch Conf 2020 talk "Rolling your own security team for fun and no profit at all" [6]. Because a healthy team is not just about technology, but also about the people behind it, we have met in a Jitsi video conference to celebrate this awesome achievement and to chink glasses :-) Sincerely, Your Security Team [0] https://lists.archlinux.org/pipermail/arch-security/2014-September/000097.h… [1] https://lists.archlinux.org/pipermail/arch-security/2021-January/001719.html [2] https://lists.archlinux.org/pipermail/arch-security/2014-March/000012.html [3] https://lists.archlinux.org/pipermail/arch-dev-public/2014-March/025952.html [4] https://lists.archlinux.org/pipermail/arch-security/2014-September/000098.h… [5] https://security.archlinux.org [6] https://media.ccc.de/v/arch-conf-online-2020-6394-rolling-your-own-security…

1 0

[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] News draft: Chromium losing Sync support in early March
by Evangelos Foutras 01 Feb '21

01 Feb '21

I would like to post this in ~48 hours from now. Review and corrections are welcome. :) ---- Google has [announced](https://blog.chromium.org/2021/01/limiting-private-api-availabil… that they are going to block everything but Chrome from accessing Google features (like Chrome sync) starting on March 15. This decision by Google is going to affect Arch's `chromium` package a bit earlier, on March 2, when Chromium 89 gets released. We know for sure that **data syncing** will stop working (passwords, bookmarks, etc.). Other features such as **geolocation** or **enhanced spell check** might continue to function for a bit longer. Extensions integrating with **Google Drive** are likely to be affected as well. After this change is implemented, we will be able to better evaluate the usefulness of Chromium builds with reduced functionality. It is not yet clear if Chromium will continue to be a viable browser for us to package, but we are trying to minimize the disruption to users. Other distros such as openSUSE and Fedora have already removed the soon-to-be-limited API keys from their Chromium 88 packages. Fedora's [advisory](https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5) provides a great deal of perspective on this and I also found this Hackaday [post](https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux… to be quite informative.

1 0

[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

[arch-dev-public] [signoff] [extra] postfix 3.5.9-1
by David Runge 22 Jan '21

22 Jan '21

Hi! I have just upgraded postfix to 3.5.9. The package has been split to allow specific installations based on requirements while not pulling in all of the backends at once: postfix postfix-cdb postfix-ldap postfix-lmdb postfix-mysql postfix-pcre postfix-pgsql postfix-sqlite Please do test the integration of the split-out optional dependencies with postfix to see whether everything still works as expected. Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Archinstall in [extra]
by Giancarlo Razzolini 22 Jan '21

22 Jan '21

Fellow Archers, As you might have noticed, archinstall[0] has been added to the [extra] repository. Over the past months we have been discussing the potential addition of an installer to our installation medium internally with our staff. Dave mentioned archinstall in his archiso talk during Arch Conf[1], outlining why we think it might be a good fit for a non default TUI based installer for Arch. To make it easier for contributors to find and fix bugs when testing archinstall, before it is added to the installation medium as a package, we have added it to the repositories for ease of use. Please note, that only installations done using the official installation guide are supported[2]. Installations done using archinstall are *unsupported* by our support staff until further notice. Any issues with installations based on archinstall should be reported to upstream directly[3]. This might change in the future, and users will be informed accordingly. Happy testing! [0] https://github.com/Torxed/archinstall [1] https://youtu.be/prsVk9iaclM?t=1436 [2] https://wiki.archlinux.org/index.php/Installation_guide [3] https://github.com/Torxed/archinstall/issues

1 0

[arch-dev-public] News draft: Manual pages indexing service
by Sven-Hendrik Haase 13 Jan '21

13 Jan '21

Hey all, lahwaacz made a service for collecting and displaying manpages from our packages that we now operate at man.archlinux.org. I believe this is news-post worthy. --- Title: man.archlinux.org is live We are happy to announce our newest public service: A manual pages indexing site at [man.archlinux.org](https://man.archlinux.org) that publishes all man pages of all our packages and allows you to [search](https://man.archlinux.org/search) and [browse](https://man.archlinux.org/listing) them. Check out, for example, the [man page of tar](https://man.archlinux.org/man/core/tar/tar.1.en). You can also find a link to this service in our sidebar. Thanks to Wiki Admin [lahwaacz](https://wiki.archlinux.org/index.php/User:Lahwaacz) for developing [archmanweb](https://gitlab.archlinux.org/archlinux/archmanweb) for this purpose. While there are other man page indexing sites out there, it is our hope that publishing man pages that match the version of our released packages makes Arch more accessible and that it improves our documentation even further. --- Thoughts? Cheers, Sven

3 4

[arch-dev-public] News draft: Archlinux mailing list id changes
by Frederik Schwan 29 Dec '20

29 Dec '20

Hey all, below is the news item I would like to post. We had to change some mailing list ids which used to be @archlinux.org to @lists.archlinux.org to mitigate anti spam issues. Sending to @archlinux.org still works as usual though. ``` Due to issues with our anti spam measures, we had to migrate those mailing lists, that were sent from @archlinux.org before to the @lists.archlinux.org domain. Submission to the mailing list is not affected and still works with @archlinux.org. Mails get redirected automagically. The only change that may need to be considered on your side are filters and rules matching the From or List-id header which changed accordingly. ``` If you have improvement suggestions, please let me know! Best regards, Frederik

2 1

[arch-dev-public] Apollo decommission
by Giancarlo Razzolini 29 Dec '20

29 Dec '20

Hi All, All the services that were hosted on apollo were moved to their own VPS'es or were removed. We plan to fully decommission the server on the 31th. If anyone knows any reason not to, please, let us know. We'll keep backups of it for a couple of months, after it's gone. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] Patchwork migration
by Giancarlo Razzolini 23 Dec '20

23 Dec '20

Hi All, As part of the apollo deprecation effort that's ongoing, we are now migrating patchwork to its own machine. Eventually it *might* be entirely deprecated in favor of gitlab, but we should keep it running for now. The migration will happen tomorrow around 1PM UTC, if there aren't any issues. As part of this effort, patchwork has also been migrated to version 3.0.0. Regards, Giancarlo Razzolini

1 1

[arch-dev-public] Wiki migration
by Giancarlo Razzolini 21 Dec '20

21 Dec '20

Hi All, We are going to migrate the wiki to a new VPS as well. The migration will happen tomorrow, 21, around 6PM UTC. If there's any issue, the migration will be pushed to 22, same time. I expect the migration to take around 1 hour, but it can be faster than that. During that time, the wiki will be under maintenance. Regards, Giancarlo Razzolini

1 1

[arch-dev-public] Orphaned packages from arcanis
by Morten Linderud 20 Dec '20

20 Dec '20

Yo! As a followup from the recent TU removal, I have composed a list of orphaned packages from arcanis. Please write back if you adopt anything else I'll drop packages into the AUR after some time has passed. As of now there are no package resigning that needs to be done. $ pkgsearch -m arcanis -l 1 | cleanup-list.py - Orphans required by maintained packages: - eric: arcanis: eric-i18n-en, eric-i18n-es, eric-i18n-de - g15daemon: idevolder: lcdproc - mftrace: arcanis: lilypond dvzrv: lilypond Unneeded orphans: canorus eric-i18n julius libasl libg15 libg15render libmatio libmmtf pdfsam pychecker pymol python-biopython python-pmw scala voxforge-am-julius Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

5 5

[arch-dev-public] Archweb migration
by Giancarlo Razzolini 18 Dec '20

18 Dec '20

Hi All, Continuing with the efforts to migrate each service to their own, separate VPS, we are now going to migrate archweb (our site). The tentative date for migration is tomorrow, 17, with a backup date this Friday, 18, around 6PM UTC. The site will be in maintenance mode and the service that updates the packages on archweb's database will be stopped on gemini. I expect the migration to last around 2 hours, but it might be faster than that. Also, we're changing the current redirection, which is to redirect anything to www.archlinux.org, to instead redirect anything to just archlinux.org. There's no rush to update any links, since we'll keep the redirections indefinitely. Regards, Giancarlo Razzolini

2 3

[arch-dev-public] New Archive Mirrors available
by Jelle van der Waa 18 Dec '20

18 Dec '20

Hi All, 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/ The servers have 3 x 9.1 TiB disks and have similar capacity to our canonical archive. Greetings, Jelle van der Waa

2 1

[arch-dev-public] away until next year
by David Runge 14 Dec '20

14 Dec '20

Hi all, from tomorrow on I'll be on holidays until early next year. While I will check my mails I won't necessarily be in places with good network connection. If anything comes up, feel free to bump my packages. I hope you all have a relaxing rest of the year. Stay healthy! Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Boost 1.74 Rebuilds
by Jelle van der Waa 07 Dec '20

07 Dec '20

Hi all, We've started the Boost rebuilds with automated builds in [staging], if required a todolist will be created for the failing builds. Please don't schedule any rebuilds which conflict with boost. Hopefully packages will arrive in [testing] before the end of the week :) Greetings, Jelle

2 2

[arch-dev-public] [RFC] Debug packages and debuginfod
by Morten Linderud 01 Dec '20

01 Dec '20

Give me cake, or give me debug symbols. - Some comedian, probably. Yo! For quite a few years people has wanted debug packages, but there has never really been any progress towards them. Pacman got support almost 10 years ago, and Allan wrote a POC for dbscripts in 2015[1]. In recent years this has largely been a discussion how large such a repository would become, and how to distribute it. But since we don't have any numbers things have more or less stalled with things being discussed, but never worked on. Dropping an imaginary 100 GB on some poor mirror hosts doesn't seem quite right. However, things has been been progressing for the better when it comes to the distribution of debug symbols that can hopefully make this entire process easier for us. debuginfod has been introduced into elfutils which allows a standardized API for fetching remote debug symbols [2]. Eli and I have have been chatting a little with upstream since February to ensure we could get our package format supported. This was fairly straight forward with an example package from us and things have been working nicely. Patches in elfutils: https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=499129e77aa88b947… https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=0245c6ed65a80bceb… https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=ad09e791320d13149… We have been distributing debuginfod since 0.178-1 and debuginfod support came to gdb with the 10.1 release, which is why I'm picking up on this now :) We did some testing with the debuginfod support with Stapelberg during the summer, and it works fairly well [3]. Eli has also started writing up the support for splitting out the debug packages into a separate pool [4]. I have since merged some of Elis dbscripts patches to the POC git migration server to test things. The idea is to allow uploads of debug packages to repos.a.o into a separate package pool, have a public reachable debuginfod and then consider if we want/need debug package distribution. We can then check the new mirror requirements, and give a clear heads up to any potential mirror admin while providing debug packages. I think this is a reasonable compromise for everyone. OpenSUSE already has one such server as an example [5]. There isn't any one way we have to progress on this, but my proposed timeline is as follows: - Add a debuginfod role to the infrastructure repository. - Test and deploy the dbscripts support for debug packages. - Add support to devtools for uploading debug packages. - Announce debuginfod support. - Discuss how to distribute the packages. I anticipate we can start a new discussion for the last point as I think there is some issues we should think about in terms of archiving debug packages and so on. Is there any questions, concerns or suggestions for this proposed implementation? If anyone is interested trying out debug packages and debuginfod, on the POC git migration server, please do poke me! -- Morten Linderud PGP: 9C02FF419FECBE16 [1]: https://lists.archlinux.org/pipermail/arch-projects/2015-August/004301.html [2]: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-el… [3]: https://twitter.com/zekjur/status/1268626664814247939 [4]: https://github.com/eli-schwartz/dbscripts/commits/wip/debug [5]: https://debuginfod.opensuse.org/

2 2

[arch-dev-public] Add active Python versions to the repos
by Filipe Laíns 26 Nov '20

26 Nov '20

Hi all, I want to propose adding all active Python versions to [community], not just the latest one. This would only entail adding the interpreter itself, no other packages. Having access to interpreters for older active versions is really helpful for Python developers. This allows them to easily run test suites against older versions. It is very common for developers to maintain software against a couple major releases. Tools like tox or nox are able to automate testing against multiple Python versions, just needing the interpreter. The current active Python releases are: - 3.9 - 3.8 - 3.7 - 3.6 - 2.7 The list can be found here[1]. So, I propose introducing 2 new packages: - python3.7 - python3.6 And when we update the python package to 3.9: - python3.8 Does anyone have any big issue with this? What are your thoughts? [1] https://www.python.org/downloads/ Cheers, Filipe Laíns

9 22

[arch-dev-public] Python 3.9 enters the testing repos
by Evangelos Foutras 26 Nov '20

26 Nov '20

We'll probably want to keep it in testing for a week or two. Please don't add new Python packages during this time. Many thanks to everyone who helped with the build failures. 🥰

1 0

[arch-dev-public] Split openssl package
by Pierre Schmitz 22 Nov '20

22 Nov '20

Hi all, there is a new set of openssl packages in testing that are split into openssl, openssl-doc and openssl-perl. See https://bugs.archlinux.org/task/54887 As most users just need the library the perl dependency can be dropped. Summing up: Before: openssl: depends on Perl; size: 3.6 MiB (7.31 MiB) After: openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB) openssl-perl: depends on Perl openssl-doc: size: 1.82 MiB We actually talked about this at ArchConf last year. Splitting the package was the easy part, but dropping the Perl dependency means that any package up the tree that depends on openssl needs to be checked if it actually needs Perl itself. Thanks to everybody who did the hard work here! PS: Do you think we should post a news item about this change? Most people won't need to worry about this, but those few who need the perl scripts need to install the separate package. Greetings, Pierre

2 3

Re: [arch-dev-public] Add active Python versions to the repos
by Filipe Laíns 21 Nov '20

21 Nov '20

On Sat, 2020-11-21 at 07:51 -0700, Zach Himsel wrote: > What would determine what the "default" python be? The latest? > > > -- > Zach Himsel > mailto://zach@himsel.net > http://zach.himsel.net Yep, that would stay exactly as it is right now. We would only additionally provide interpreters (and interpreters only!) for the older Python versions. Cheers, Filipe Laíns

1 0

[arch-dev-public] [xorg-server] from testing repo may need manual intervention
by Andreas Radke 19 Nov '20

19 Nov '20

We've started to build xorg-server packages form stable git branch again to pull pending bug fixes and an uncertain release date. A minor git package version numbering issue may prevent automatic future updates. In case you have already installed version 1.20.9+21+g5c400cae1-1 from testing repo today please run pacman -Syuu to receive a fixed version 1.20.9.r21.g5c400cae1-2. -Andy

1 0

[arch-dev-public] Python 3.9 rebuilds
by Evangelos Foutras 15 Nov '20

15 Nov '20

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.9. Please avoid adding new Python packages and starting other rebuilds during this time. Some PKGBUILDs were modified in /trunk to use the Python 3.9 site-packages path (among other tweaks). Building those against Python 3.8 might fail or produce incorrect packages. The affected packages are listed in the following two commits and care should be taken when updating them while the Python rebuild is ongoing. https://lists.archlinux.org/pipermail/arch-commits/2020-November/843783.html https://lists.archlinux.org/pipermail/arch-commits/2020-November/843784.html

2 2

[arch-dev-public] [signoff] [extra] postfix-3.5.8-1
by David Runge 11 Nov '20

11 Nov '20

Hi all! I recently upgraded the postfix package and made quite a few adjustments (e.g. using tmpfiles.d instead of a 1000 line POSIX shell script, splitting shared libraries and applying mild hardening on the postfix.service). As for many setups postfix is probably rather mission-critical it would be excellent to get some signoffs on it. Specifically it would be good to test setups in which postfix is not handling virtual mailbox setups, but is using unix user setups (due to the changes introduced to the service file). Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Pam lockout
by Tobias Powalowski 06 Nov '20

06 Nov '20

Hi guys, https://bugs.archlinux.org/task/67644 I second Levente's post of it's a configuration issue that needs to be addressed by user and not by the package itself. Typing 3 times wrong password is a sane default imho. Any other opinions out there? Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 6

[arch-dev-public] Orion retirement
by Jelle van der Waa 02 Nov '20

02 Nov '20

Hi All, Our dedicated server orion (used to host repos.archlinux.org/mail.archlinux.org) has been cancelled which means it will be no longer accessible in 30 days. If you have anything of value in your home directory, please copy it before the 10th of November as then the server will be completely wiped. As the DNS entry is already gone you'll need to login into 88.198.91.70 We do have backups of this server, but do not wish to query them on demand if not required :) Greetings, Jelle

1 0

[arch-dev-public] Arch Conf 2020 videoes
by Morten Linderud 01 Nov '20

01 Nov '20

Yo! I'd like to just point out to people that we have uploaded the talks to media.ccc.de :) https://media.ccc.de/c/arch-conf-2020 Youtube Playlist: https://www.youtube.com/playlist?list=PL3tfdJ8q1zXRFu6QPELCaIwU3BIzauUJi It went a bit quicker then expected so I'll do a httpdir drop with slides, music, written Q&A and any misc stuff that was used for the production of the conference sometime later this week. I'll also announce it properly on the conference webpage and to our speakers! I recommend everyone to go watch the keynote talk of the conference if you didn't catch it. The surprise from day 2 has also been added :) https://media.ccc.de/v/arch-conf-online-2020-6379-arch-linux-past-present-a… Have a good week<3 -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] archlinux/base docker image will no longer be updated
by Pierre Schmitz 01 Nov '20

01 Nov '20

Hi all, as the archlinux/base image has been replaced by https://hub.docker.com/repository/docker/archlinux/archlinux I'll no longer manually build this image alongside the ISO image release. I guess it would be best to remove the repository so people will not silently keep using an outdated image. Greetings, Pierre

2 1

[arch-dev-public] News draft: Accessibility features added to installation media
by David Runge 01 Nov '20

01 Nov '20

Hey all, below is the news item I would like to post once the installation medium is released some time tomorrow: ``` We are very happy to announce that accessibility features have been added to our installation medium with [archiso v49](https://gitlab.archlinux.org/archlinux/archiso/-/tags/v49). From release 2020.11.01 onwards these are available via the 2nd boot loader menu item. Many thanks go to Alexander Epaneshnikov who integrated the features from the [TalkinArch](https://wiki.archlinux.org/index.php/TalkingArch) project into archiso's releng profile, which is used for creating the installation medium. Note: The bootloader timeouts have been set to 15s to allow blind users to select the menu item as the bootloaders themselves do not offer accessibility features. The timeout is stopped as soon as e.g. an arrow key is pressed. ``` If you have improvement suggestions, please let me know! Best, David -- https://sleepmap.de

3 2

[arch-dev-public] archiso v49 with new features
by David Runge 30 Oct '20

30 Oct '20

Hey all! So, there are some exciting news for the upcoming archiso release! Maybe some of you have followed the presentations during Arch Conf 2020. I did one on archiso. The upcoming v49 will include accessibility features for blind and visually impaired, making it possible to install Arch Linux with the help of auditory feedback. Not only the resulting ISO itself has accessibility support now, but also the script to test a built image locally - run_archiso (via an option flag). Many thanks go to Alexander Epaneshnikov for spending the time to integrate his efforts from the talking-arch project into our builtin releng profile! Additionally, the use of build.sh scripts per profile has been removed. This is due to the fact that archiso has moved to (mostly) declarative profiles, which makes creating profiles less complicated (as now only mkarchiso is required to build a profile). There are still a few outstanding rough edges, but most of those are already tracked and I believe we have arrived at a pretty decent state by now. Many thanks go to nl6720 for a lot of brainstorming, implementing, breaking and fixing! :) If this mail reads like a changelog, then well, it is because I don't have a changelog in the project yet! ;-) Apart from that I thought it might be worthwhile to write a news item about it after the next ISO has been released and share the above two changes on the website. What do you think? Best, David -- https://sleepmap.de

3 2

[arch-dev-public] New version of the pkgstats client
by Pierre Schmitz 27 Oct '20

27 Oct '20

Hi all, I just released the initial version of a new pkgstats package. As it now requires different arguments (e.g. it does no longer submit the list when run with no arguments) it is technically a BC break; therefore version 3. For most users who simply install it to enable the weekly submission of packages no intervention is needed. The command now supports displaying statistics right from the terminal. E.g. pierre@skynet ~> pkgstats show go nodejs nodejs 65.26 go 61.34 For more information see the integrated help; I also wrote a quick post at https://pierre-schmitz.com/pkgstats-version-3-lookup-package-statistics-fro… Greetings, Pierre

2 3

Re: [arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention
by Jan Alexander Steffens 26 Oct '20

26 Oct '20

On Mon, Oct 26, 2020 at 2:16 PM Sébastien Luttringer <seblu(a)seblu.net> wrote: > On Sat, 2020-10-24 at 23:27 +0200, Sébastien Luttringer wrote: > > > > Sure, I didn't know that rule. It's written somewhere or well known habit? > > > Jan? Sorry; I don't think it's written down anywhere; it's just what I did last time. It helps us (and users of [*testing], who are encouraged to subscribe to arch-dev-public) make sure that the draft is actually correct.

1 0

[arch-dev-public] Mail server migration
by Jelle van der Waa 24 Oct '20

24 Oct '20

Hi All, Tomorrow we will migrate the mail server starting at Saturday the 24th October (tomorrow) on 12:00 GMT. The migration should take around four hours, but could take longer. This migration affects everything which sends email, so not only your @archlinux.org address but also the bbs, AUR, etc. The reason is why we migrate the mail server, the current server costs us ~ 40-60 euro / month (dedicated server) and we will be moving to a VPS which is around ~ 3 euro / month. Greetings, Jelle

2 2

[arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention
by Sébastien Luttringer 24 Oct '20

24 Oct '20

The libtraceevent package prior to version 5.9-1 was missing a soname link. This has been fixed in 5.9-1, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get any of these errors libtraceevent: /usr/lib/libtraceevent.so.1 exists in filesystem when updating, use pacman -Syu --overwrite usr/lib/libtraceevent.so.1 to perform the upgrade. Sébastien "Seblu" Luttringer

2 2

[arch-dev-public] SVN to Git Migration work and POC
by Morten Linderud 21 Oct '20

21 Oct '20

We are moving to git! Hopefully...maybe...someday! This has been a change that has been discussed for years, but progress has been stalled because of different reasons. I decided to pick it up and work on getting devtools and dbscripts up to speed. It's important to note that nothing is changing in the very-near future, and there is still A LOT left to be figured out. This email is intended for the ones that wish to help out testing the current point of concept and come forward with thoughts and ideas. # tl;dr A quick summary of the technical changes so far: - Each package is it's own git repository located under a packages group on gitlab - Consolidated the dbscript distinction between "community" and "packages" into "packages" The git repostitories still keep the namespaces "community" for TUs, and "packages" for developers. - devtools creates .SRCINFO files upon commit - devtools creates signed tags in the package repository - Git tags has a seperate version scheme from pacman because git has limitations - pacman version: 1:1.2.3-1 - git tag: release-1-1.2.3-1 # Testing ## Gitlab Access We have gotten a gitlab instance running where we can create repositories. To help testing svn2git migration you need to access this instance. All accounts from team-members should have been created already, and all you need to do is to reset the password with your archweb email. https://gitlab.archlinux.org If you don't get any emails, you should contact devops. Important to note that I need to add you to the `package-test` group on gitlab if you wish to test the tooling. Please reply to me offlist, or poke me on `#archlinux-projects`. ## SVN Repository to Git conversion Anthraxx, with the great help of Ismael, has rewritten the original `gitsvn2git` bash script to a nice python tool to help us convert git2svn packages into standalone git repositories. When following the instructions below you can make your own packages or play around with the script with your current packages. https://github.com/anthraxx/arch-svn-package-to-git ## WIP Repository Currently there is a POC server running dbscripts on svn2gittest.archlinux.org. This server is provisioned by the devops team, with me being the administrator. Install the WIP devtools package from my repository: https://pkgbuild.com/~foxboron/repos/devtools/ It should live alongside the current devtools package and only provide the WIP tooling with git support. - Ensure you can ssh into svn2gittest.archlinux.org - The box has been deployed with our archusers ansible role and should contain the same users as orion - Navigate the package-tests project; https://gitlab.archlinux.org/packages-test - Create a repository in either packages or community. - You can use any package you want. Any consistency checks in the WIP repository has been removed and shouldn't interfer with any packages you push. - Work with the package as normal. - When you commit the changes use: `git-extrapkg` for packages under `packages-test/packages` `git-communitypkg` for packages under `packages-test/community` - When you have uploaded the package: ssh svn2gittest.archlinux.org "/packages/db-update" Note: The dbscripts tooling has been consolidated. There is not need for `/community/db-update` If there are any bugs, please poke me in #archlinux-projects The technical overview is currently being worked on in on in the archwiki: https://wiki.archlinux.org/index.php/User:Foxboron/GitMigration Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] rfc: reflector and providing pacman-mirrorlist
by Xyne 20 Oct '20

20 Oct '20

Hi all, There's an open ticket to have the reflector package provide "pacman-mirrorlist" so that users can remove the latter: https://bugs.archlinux.org/task/67653#comment193375 The problem is that the package does not include a mirrorlist and it will only create one if the user starts the provided service, which is entirely optional (I do not use it, for example). The dependency is thus not satisfied without user intervention. I'm inclined to leave it as is (no provides) rather than risk broken pacman dependencies because a user forgot to run the service, but I'm still weighing the pros and cons. Does anyone here have an opinion or a suggestion of how to handle this elegantly? Regards, Xyne

2 2

[arch-dev-public] News draft: nvidia 455.28 is incompatible with linux >= 5.9
by Sven-Hendrik Haase 19 Oct '20

19 Oct '20

nvidia is currently partially incompatible with linux >= 5.9 [1][2]. While graphics should work fine, CUDA and OpenCL are broken. Users who've already upgraded and need those features are advised to switch to the linux-lts kernel for the time being. [1] https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-l… [2] https://bugs.archlinux.org/task/68312

2 1

Re: [arch-dev-public] Packages added to todo list 'Remove libjpeg from depends/makedepends/optdepends and use shared object dependency'
by Evangelos Foutras 19 Oct '20

19 Oct '20

David, following the concerns raised on IRC [1], is this todo getting canceled? [1] no prior discussion, library with stable soname, prioritization and scalability of adding sodeps to more packages

2 1

[arch-dev-public] Packages up for adoption
by Bartłomiej Piotrowski 15 Oct '20

15 Oct '20

Hi, Due to lack of free time, I've orphaned some packages I don't want to think about: bash bash-completion chrome-gnome-shell expat gdbm libcap libffi libunistring libusb networkmanager-fortisslvpn ncurses openfortivpn readline texinfo wpa_supplicant I've also disowned some packages I've been co-maintaining with other packagers but that's not so interesting. Bart

4 3

[arch-dev-public] Autumn extra cleaning
by Sven-Hendrik Haase 12 Oct '20

12 Oct '20

Hey everyone, It was suggested as part of this year's spring cleanup of [community] that we should be have a cleanup in [core]/[extra] and move packages downwards into [community]. This round only concerns [extra] packages. Devs that want the packages in [extra], please adopt packages, and TUs can notify which packages they are interested to maintain in [community] Orphaned packages in [extra]: a2ps aalib abook adwaita-icon-theme (Jan can you just take this?) antlr2 antlr4 arch-install-scripts asp aspell-es bzflag c-ares chromaprint cln cmark convertlit cvs cvsps davfs2 dcraw enca expac fakechroot farstream fastjar font-bh-ttf freetds fvwm geeqie giblib gifsicle gnugo gperftools graphene gsfonts gstreamer gtksourceview4 gts gupnp-igd gv hddtemp hunspell-fr hunspell-it hunspell-ro hyphen-fr hyphen-it icewm id3lib ifplugd ispell java-activation-gnu java-bcel java-commons-net1 java-gnumail java-hamcrest java-inetlib java-jdepend java-jline java-jsch java-resolver java-rhino joe jpegexiforient junit leveldb libatomic_ops libkate liblqr libmilter libmng libnet libnice libnma libofa libots libpano13 libspiro libstroke libtiger libtommath libuninameslist libusb-compat lua51 lua52 m17n-db mercurial mtools munin munin-node mysql-python mythes-fr mythes-it mythes-ro nawk netpbm npapi-sdk nss-mdns ocamlbuild opencore-amr perl-http-daemon pkgfile (I suggest we just drop this in favor of pacman -F) potrace psiconv python2-cairo python2-numpy python2-ordered-set python2-setuptools rcs rhino rhino-javadoc screen shared-color-targets snappy snarf swt tcl telepathy-farstream telepathy-idle telepathy-salut time tinycdb tk ttf-junicode ttf-linux-libertine uim usbmuxd vcdimager vim-spell (and its 50 split packages) w3c-mathml2 x11-ssh-askpass x11vnc xalan-java xerces2-java xine-lib xine-ui xmltoman xorg-font-util xorg-xfontsel xorg-xlsfonts xournalpp yajl Thanks to Morten for ghostwriting this. ;) Cheers, Sven

18 31

[arch-dev-public] Congrats to the Arch Conf Team
by Allan McRae 12 Oct '20

12 Oct '20

A big shout out to the Arch Conf Team! This weekend's conference was nothing short of awesome. It pulled together very well, particularly given the short organisation period and it being the first one run online. The recorded talks followed by live Q&A worked very well, and I enjoyed the live commentary by the community either on IRC or twitch. Looking forward to next year! :) Allan

2 1

[arch-dev-public] News draft: ghostpcl>=9.53.2-2 and ghostxps>=9.53.2-2 updates require manual intervention
by Jan Alexander Steffens 27 Sep '20

27 Sep '20

The ghostpcl and ghostxps packages prior to version 9.53.2-2 were missing a soname link each. This has been fixed in 9.53.2-2, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get any of these errors ghostpcl: /usr/lib/libgpcl6.so.9 exists in filesystem ghostxps: /usr/lib/libgxps.so.9 exists in filesystem when updating, use pacman -Syu --overwrite /usr/lib/libgpcl6.so.9,/usr/lib/libgxps.so.9 to perform the upgrade.

1 0

Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
by Morten Linderud 23 Sep '20

23 Sep '20

On Wed, Sep 23, 2020 at 11:01:33AM -0400, Santiago Torres-Arias wrote: > > > I think it's pretty clear from the drop down on the right (it also lets > > > me choose my local TZ)... > > > > What :D I don't see any drop downs 🙃 > > > > I'll add a link to https://everytimezone.com/ regardless to make it easier after > > an offlist suggestion from Stapelberg. > > Ok, the more the merrier, but am I crazy for seeing this? (ss attached). > > -Santiago We sorta deduced on IRC that this is probably shown when you are outside of the conference timezone. Which is a tiny bit non-obvious :) But I'll add the timezone link regardless so people in UTC+2/CEST don't ask. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
by Morten Linderud 23 Sep '20

23 Sep '20

On Wed, Sep 23, 2020 at 09:38:31AM -0400, Santiago Torres wrote: > On Wed, Sep 23, 2020 at 02:48:59PM +0200, Morten Linderud via arch-dev-public wrote: > > On Wed, Sep 23, 2020 at 11:43:16AM +0200, Morten Linderud wrote: > > > On Mon, Sep 21, 2020 at 11:56:43PM +0200, Morten Linderud wrote: > > > > > > > > On the 10th and 11th of October there is going to be an online edition of Arch > > > > Conf. The conference is going to have presentations from the Arch team along > > > > with community submitted presentations and lightning talks. > > > > > > > > We are proud to announce the first revision of the schedule! > > > > > > > > ${LINK_TO_SCHEDULE} > > > > > > > > Updates and additional information can be found on the conference page: > > > > https://conf.archlinux.org > > > > > > > > See you there! > > > > > > https://pretalx.com/arch-conf-online-2020/talk/ > > > > I'll add a note about the timezone for the conference is CEST/UTC+2 > > (Europe/Oslo) as it's not clear from the schedule. Unsure if it's any good way > > to have this note somewhere on the schedule page itself. > > > I think it's pretty clear from the drop down on the right (it also lets > me choose my local TZ)... What :D I don't see any drop downs 🙃 I'll add a link to https://everytimezone.com/ regardless to make it easier after an offlist suggestion from Stapelberg. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] News draft: Arch Conf 2020 schedule
by Morten Linderud 23 Sep '20

23 Sep '20

Yo! I'd like to poste a news item about the schedule for Arch Conf. I reckon the front page has better reach then the planet RSS feeds. Currently waiting for the last of the talks to be confirmed before posting. 8<<<<< On the 10th and 11th of October there is going to be an online edition of Arch Conf. The conference is going to have presentations from the Arch team along with community submitted presentations and lightning talks. We are proud to announce the first revision of the schedule! ${LINK_TO_SCHEDULE} Updates and additional information can be found on the conference page: https://conf.archlinux.org See you there! >>>>>8 Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 2

[arch-dev-public] Orphaning packages/ request for co-maintainership
by David Runge 19 Sep '20

19 Sep '20

Hi all, I'm orphaning the following packages as I don't use them and/or took them over from someone who is now not a team member anymore: # [extra] ddrescue easytag (can be moved to [community]) # [community] autorandr cacti flac123 flyspray gmm gpa grub-customizer libircclient libmusicxml libopenshot libopenshot-audio libquicktime marsyas minitube nfoview nomacs openshot plowshare pound smplayer-skins smtube wiiuse zopfli The above [community] packages (if possible) will be moved to the AUR if no maintainers are found until 2020-09-28. Additionally I have many packages that I'd be happy to find co-maintainers for. If packages that you are interested in co-maintaining are not in the list below (e.g. all the pro-audio stuff) just let me know - the list would have gotten too long otherwise :P # [extra] raptor rasqal redland scons # [community] hyperkitty irker mailman3 mailman3-hyperkitty postorius qtile quodlibet radicale slimit sigal solfege subdownloader tmuxp tuna waf Best, David -- https://sleepmap.de

4 4

[arch-dev-public] Call for Participation - Arch Conf 2020 Online
by Morten Linderud 18 Sep '20

18 Sep '20

Hello everyone! We are super excited to announce that the Arch Linux Conference 2020 is going to be held online on the 10th and 11th of October. The CFP has been published and everyone is free to submit talks and lightning talks from today until the 18th of September. If you have other ideas please do reach out! https://pretalx.com/arch-conf-online-2020/cfp # Pre-recorded talks All talks should be pre-recorded and sent to the team by the video submission deadline. You will be notified if the talk has been accepted shortly after the submission deadline has passed. # Important Dates * Conference date: 10th - 11th of October * Submission deadline: 18th of September * Video submission deadline: 5th of October # Streaming Streaming details are going to be published through September as there is still some more planning required for this part :) # Contributing We are still going to hold regular meetings over mumble and general planning in #archlinux-conf @ freenode until the conference starts in October. If you want to get involved and help out please do reach out and join the meeting :) Cheers from the Conference Team!

1 2

[arch-dev-public] Kanboard Deprecation
by Frederik Schwan 14 Sep '20

14 Sep '20

Hi people, as part of our ongoing unification of Arch services in order to ease operational overhead, DevOps would like to move the kanboard service to the GitLab instance [0]. GitLab has a comparable feature in the form of issue boards [1]. The current kanboard isn't getting used much and we'd like to focus our efforts. See below for an overview of the usage lately: Board Owner lowest "days in this column" Infrastructure Florian 513 Bug todos Eli -empty- Reproducible Arch Linux Bartłomiej 629 Archweb Jelle 489 dbscripts Eli 660 Security Team Jelle 445 Conf Jelle 377 Packaging David 393 General Bartłomiej 239 Docker Image Santiago 244 We are not interested in flat out deleting everything and realize that there might still be important information there somewhere. Please have a look at the boards and check if there's anything you know needs to be migrated. At a quick glance, many issues are simply out of date and superseded or already done. If necessary, please migrate the board to GitLab or feel free to create a DevOps ticket [2] so that we can handle the migration. We seek to finish the migration by October 31st. Cheers, Frederik [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/16 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/boards [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues

1 0

[arch-dev-public] Away on vacation until 25th September
by Thore Bödecker 11 Sep '20

11 Sep '20

Hi, just wanted to give a quick notification that I will be mostly away from the digital world until 2020-09-25. I might sporadically check my mails or pop briefly into IRC, but not engage actively in other duties like packaging. Feel free to bump any of my packages in the mean time, just be advised that both the consul and the ceph package do need some work again and might not even rebuild in their current version against our current repo. I just haven't had time to deal with that yet. Cheers, Thore -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6

1 0

[arch-dev-public] News draft: Bug wrangling day
by Frederik Schwan 06 Sep '20

06 Sep '20

Hi people, given the large amount of open bugs, I'd like to invite all users to help out with an official announcement. ----> Kill Arch Bugs: Help us on the 13th of September! We would like to hold a bug wrangling day on the 13th of September to reduce the large amount of open tickets. If you cannot take part in the bug wrangling day, then feel free to help us any time before that event. How? Please review all bugs that were reported by you and check if they are still valid. Please request a task closure on the bug tracker if the task may be closed. Otherwise please provide further information so that we can continue to work on the bug. We cannot fix bugs without your feedback. Questions? Join us at #archlinux-bugs channel on irc.freenode.net during 13th of September. As we life in different timezones not all devs and bug wranglers will be available at the same time, but feel free to report your issues to any dev available. Also please check your mailboxes that may contain notifications about comments made on your tickets <---- Parts of this news are derived from this post: https://bbs.archlinux.org/viewtopic.php?id=31568 Cheers, Frederik

2 1

[arch-dev-public] Bug tracker migration
by Frederik Schwan 30 Aug '20

30 Aug '20

Hi folks, I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab instance. TLDR: - Bug wrangling day on the 13th of September; see 1) - Flyspray will be read-only after we rewrite the Archweb URLs - new bug tracker -> Gitlab 1) I'd like to hold a bug wrangling day, where our goal is to close as many bugs as possible. Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately I can't offer any cookies that day :/ Rules: a) Bug with no reply for at least 6 months which has been submitted for a different version than the current one in the repos shall be closed with a message that a reopen request may be filled if this issue is still present. b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps. 2) Afterwards we will point the bug tracker links in the Archweb to the new location and opening new tickets in Flyspray will be disabled. The project structure of the future Gitlab bug tracker will be discussed in a seperate mail and is not part of this mail(thread). 3) When enough tickets are closed or when $DevOps is tired enough of Flyspray, we'll migrate the rest of the tickets to Gitlab. We seek to keep Flyspray as a static homepage to allow the reference in the new bug tracker to old tickets and to keep the integrity of search engine results. Please make sure you all have a working account at our Gitlab instance. Cheers, Frederik

5 7

[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
by Evangelos Foutras 25 Aug '20

25 Aug '20

I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring. What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?

5 5

[arch-dev-public] Ciao
by Gaetan Bisson 20 Aug '20

20 Aug '20

Dear all, I've joined the Arch team in 2010 and spent a decade as a developer; it's been a great privilege to be a part of such an awesome community and also a lot of fun. However I felt the ten-year mark was a good opportunity for me to move on since I recognize the majority's views on the future of the distro have of late steadily been diverging from mine. And thus I hereby resign my position of Arch Linux Developer. All the best in your future endeavors! -- Gaetan

3 3

[arch-dev-public] Holidays 2020-08-20 -- 2020-09-01
by David Runge 18 Aug '20

18 Aug '20

Hey all, I will be on holidays between 2020-08-20 and 2020-09-01 and very likely not be able to do packaging. Feel free to bump my packages. Note, that audacity would require a lot of work.. so only get on to that one if you're really up for it :-P Juce is another such candidate (but also because it currently makes the build for iempluginsuite fail). Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Mail server migration
by Giancarlo Razzolini 14 Aug '20

14 Aug '20

Hi Guys, Continuing with our migration efforts, we're now going to migrate the last running service on orion which is the mail server and all the software related to it. This is also getting migrated to a VPS [0]. We plan on making this as transparent as possible, so all the mailboxes, sieve filters and .forward files and anything else mail related will be copied from the home directions each user has on orion. We also plan on syncing /etc/shadow, to make sure all the passwords remain the same. However, the SSH Host keys will also be changed on the process. These keys will be documented beforehand on [1] as well as sent to this thread. SSH access will only be used for password changing and for putting/editing .forward files and/or sieve filters. Eventually the mail server will not support SSH access anymore, as we plan on transitioning authentication to keycloak in the future. But for foreseeable future, things won't change. Also, with this change, since mail is the last thing on orion, that machine will be decommissioned. So, please, everyone make sure that you don't have anything on your home directory that you wish to keep. We'll take a backup, but the only things getting moved to the new mail server are mail related files. There's no date yet for both the migration and for orion's decommissioning, but the mail migration will happen next week, and orion's decommission following that and provided the mail migration is successful. There will be a period of time where the pop and imap services will be unavailable, as well as sending emails. We plan on not disrupting the incoming of emails, and I'll sync the queue between the machines, to avoid any lost email, while the DNS records are changing. Regards, Giancarlo Razzolini [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/92 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ss…

1 0

[arch-dev-public] Anatol is inactive due to situation in Belarus
by Anatol Pomozov 14 Aug '20

14 Aug '20

Hello folks My name is Anatol Pomozov and I am an Arch Linux developer. I've been quiet for a couple of weeks now and will probably stay away from my Arch Linux/pacman (+bcc:pacman-dev@) duties for a bit more. Please feel free to take care of my packages if it's needed. The reason for this decision is a situation that happens in my home country. I am a belarusian. My home country, my beautiful Belarus is essentially taken hostage by a usurpator Lukashenko. He has been "ruling" the country for 26 years already. Lukashenko cancelled results of the last election (where he took ~10% of votes) and declared that he is going to stay in power for another 5 years. All his political opponents were put into a jail or hiding from him abroad. Anyone who demands fair elections is terrorized by his personal army. Many people are tortured in jail. You can see what happens in Belarus in these clips https://www.youtube.com/watch?v=XG3D6881AXY https://www.youtube.com/watch?v=-6tCGnM0xiQ https://www.youtube.com/watch?v=E0VLjQvCxcc I live abroad and I am safe now. But my parents and relatives are in Belarus and they were essentially taken hostage by the Lukashenko's government. The last few weeks were stressful for me and I want to focus on my extended family as much as possible. I understand that Arch maillist might not be the place for political statements but this is something personal and something important for me. There is no place for such violence and there is no place for dictators in Europe of the 21st century. Please support Belarusian people in their fight against the usurpator. Talk to your governor/mayor/deputy/..., ask them to contact Belarusian government to stop the violence. Talk to the press, explain to them what is going on in Belarus right now. Anything that brings peace to Belarus will be helpful. Thank you. Жыве Беларусь!

2 1

[arch-dev-public] Online Arch Linux Conference
by Morten Linderud 11 Aug '20

11 Aug '20

Yo! Because of COVID-19 I assume most people have had some conference plans cancelled this year. FroSCon has had an Arch Linux devroom the past years, but as we are not meeting physically I guess that isn't happening either. Thus I want to try rally some people and have an online Arch Linux conference/devroom. There are not any major ambitions really. This can be a few hours an evening, or a weekend event. We will see what we figure out :) # Ideas Some of the ideas I have had so far is as roughly: * Team Q&A * Talks/presentations * team member and the wider community * Interactive streams * See how packagers do their work? * Arch Linux installation speedruns(?) * Workshops? Feel free to email me offlist, or poke me on other platforms, if you have other great ideas that could work! # Organization To organize we would need some help and might need some roles filled. This is a shortlist of the ones I can come up with. But I'm sure there are more tasks and roles needed: * Art-work/graphics * Help figuring out streaming * Planning and handling CFP There is no requirement to be on the Arch team to contribute. If you think you have anything to contribute, please do come talk with me! Need every help one can get :) # Meeting Below is a suggested meeting date for interested parties to attend. I'm unsure if it's going to be mumble or purely text based. Date of meeting: 4th of August 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 IRC: #archlinux-conf @ freenode Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 3

[arch-dev-public] Use detached package signatures by default
by Anatol Pomozov 10 Aug '20

10 Aug '20

TLDR; let’s start using detached package signatures to make system updates faster. Hi folks, Some time ago there was a discussion at IRC where someone (Allan maybe?) proposed to stop using embedded PGP signatures in favor of detached signature files. I would like to bring this idea here and quantify it with some numbers. Here is a bit of technical details on this topic. Pacman has the ability to verify authenticity of package files with PGP signatures. PGP signatures add protection against undesired package modifications by a third-party and it improves security aspects of the package management. This feature can be configured per repository and the official Arch Linux repos have it enabled. Package signatures have been used by Arch Linux successfully for a couple of years now. Package signatures are stored as a part of a pacman database file (it is called “embedded signatures”). One issue with embedded signatures is that they represent a quite large chunk of database file. What is worse, a PGP signature is high-entropy data and does not compress well. I was mildly shocked to learn how much of the *.db files signatures consume. I ran experiments and repackaged extra, community databases without PGP data. For uncompressed “extra” repository size drops to 83% of its original size (though uncompressed size is not that interesting). Arch uses GZIP compressed database and in this case removing signatures reduces the “extra” database to 36.8% of its original size. To emphasize it one more time - removing PGP signatures makes this repo only 1/3 of its original size. The change is even more dramatic in case of “zstd -19” compression where the final database file is only 31% of its original size. For community.db the numbers are: uncompressed file gets 79.8% of its original size, “gzip -9” gets 33.4%, and with “zstd -19” it gets 27.51% of its original size. A database gets modified with every package update. Users need to re-download the databases where 2/3 of it are package signatures that are used only when a specific package is installed. An alternative to embedded signatures are detached signatures. These are signatures stored in a separate file next to the package itself (in a <pkg>.sig file to be specific). Instead of downloading *all* signatures every time a database is updated, detached signatures are downloaded only when a specific package is installed/updated. If Arch could switch to this model then database files become 3 times smaller that saves users bandwidth and system update time. I looked through pacman code and most components have detached signatures support already. Most of the places have a logic like this: if(pkg->embedded_sig) { use(pkg->embedded_sig) } else { sig = load_detached_sig(pkg) use(sig) } I found only 2 places where pacman does not fallback to a detached signature: 1) Keyring key check. Pacman was using embedded signatures only. This has been fixed in pacman’s commit b01bcc7d3d680 and it will be available in pacman version 6.x 2) dump_pkg_full() that dump package information. If a package uses detached signatures only then it prints “None”. I think this is fine as this function displays database entries and it does not affect the package verification process. I disabled the embedded signatures at my testing machine to use detached signatures only and things look great so far. ‘pacman --debug’ confirms that detached signatures are correctly downloaded and used to verify the package content. Given this information I would like to propose to stop using embedded signatures and move to detached signatures by default. This will require pacman 6.x or as alternative backport the fix(es) to 5.x branch. It will help to make system updates even faster, something that me and many other Arch users really love.

5 7

[arch-dev-public] Stepping down from DevOps
by Florian Pritz 01 Aug '20

01 Aug '20

Hi, As you have probably noticed, my involvement in DevOps tasks has dwindled in recent months. I have given away a few tasks to others already, but since I hardly use my root access any more, I think it is finally time to officially open up the spot and let someone else take over. Back when we started the DevOps team nearly 5 years ago (good god, time flies), Allan asked me if I wanted to lead the "infrastructure team" (old name). I am glad that I have never needed to use the team leader hat since we could discuss pretty much every problem and reach an agreement. Given that things have worked so well in the past, I'm inclined to simply discontinue the (unused) team leader hat. Considering how little, well, actually not at all, I have used the hat, most people are probably not even aware of it, so this feel like the most logical choice. I think having a core team of active people that discuss the issues and then come to an agreement has worked well in the past and it is something worth keeping. I'm still amazed by what you guys accomplished over the last year and I hope that making space and letting others join will only allow the team to be even more awesome! All that said, please disable my root access and remove me from the various infrastructure/devops/root related email aliases and services (kanboard and gitlab come to mind). Please do keep me on the mirrors(a)archlinux.org alias for now though since I still handle mirror related requests. I also see that I am the only one on the dmarc-reports@ alias. If nobody is interested in the reports, please remove the relevant line from the DMARC DNS entry in the archlinux.org zone. Also, please remove my email address from the explicit hetzner contact list. If you think of anything else that I forgot, please disable it or, if in doubt, feel free to ask on IRC if I still need it. Thanks for the journey! Florian

1 0

[arch-dev-public] AUR migration
by Giancarlo Razzolini 28 Jul '20

28 Jul '20

Hi All, In continuing with the improvements being done to our infrastructure, we're planning to migrate the AUR to another machine. This means that, during the migration, there *will* be downtime of the whole AUR. I expect the migration to take around two hours and happen either tomorrow (Friday) or on Saturday, depending on availability. Regards, Giancarlo Razzolini

7 15

[arch-dev-public] Orphaning signing-party and dependencies
by Archange 27 Jul '20

27 Jul '20

Hi there, I’ve never went far into using signing-party, and do not have time to maintain it anymore. Thus, I’m going to orphan it as well as its dependencies (nothing else requires them), and move them to the AUR unless someone steps in to maintain them within ~two weeks. The full packages list: libmd perl-data-perl perl-gnupg-interface perl-moox-handlesvia perl-moox-late perl-strictures perl-type-tiny qprint signing-party Regards, Bruno/Archange

1 0

[arch-dev-public] News draft: AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Hi guys, Given that the SSH host keys were changed during the AUR migration, and, due to the fact that not everyone will see this on the home page for the AUR or on aur-general, I propose the following news draft: ----> AUR migration: New SSH Host keys Due to the fact the AUR was migrated to a new server, the SSH HostKeys used to pushed packages were changed in the process. These are the new keys fingerprints: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 They can also be found on the AUR home page when not logged in. <---- Given this is somewhat urgent and the migration was done on Friday, I'll not wait the full 24 hours before posting this, but I'll probably post this by the end of the day, today, instead. Let me know if anyone has any objections. Regards, Giancarlo Razzolini

2 1

Re: [arch-dev-public] [aur-general] AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Em julho 27, 2020 9:35 Henry-Joseph Audéoud escreveu: > On 24/07/2020 21:24, Giancarlo Razzolini via aur-general wrote: >> The migration is almost done. Since we are moving to a new machine, it will >> have new host keys. They are: >> >> Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 >> ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 >> RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > You swapped the fingerprints of keys ECDSA and RSA. From my computer, I > get that fingerprints (and Ricardo Band has the same for ECDSA): > > ED25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 > ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 > Yes, this is correct. The configuration is with the keys swapped. I'm going to fix it and also create a news post about this. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] loop device in container
by Tobias Powalowski 18 Jul '20

18 Jul '20

Hi guys, is it possible to get loop devices working in a container? I need this in archboot script. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[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] help wanted / IPP based printing/scanning
by Andreas Radke 13 Jul '20

13 Jul '20

There's some major effort going on to move from driver based scanning and printing to driverless scanning and printing both based on IPP specifications offered by newer devices. While IPP based printing is already there for some time and usable with cups+cups-filters [1] there's more work going on recently for IPP based scanning lately. There are a few projects we should probably support and add to our repos. I'm thinking about adding Sane-airscan [2][3] to extra. There's also a new ipp-usb proxy to allow IPP protocol access with USB connected printers and scanner as well [4][5]. I've prepared a simple package here of this one. Sadly my own printer is has a broken IPP implementation and thus can't be used with driverless printing [6]. My scanner is an old extra devices with plain usb connection. Both devices keep working well and I have no plan to replace them. So I cannot test anything of the new IPP stuff. If there's desire to have the new IPP stack fully available form our repos I can do the packaging because it's heavily related to recent multidevices and openprinting.org projects. But any help is welcome and I would prefer someone to become a backup and co-maintainer. If somebody has interest to help out here and maybe owns a modern IPP based multidevice please drop me a line. If nobody steps up or complains I plan to add sane-airscan and ipp-usb and maybe more if needed. -Andy [1] https://wiki.debian.org/CUPSDriverlessPrinting [2] https://github.com/alexpevzner/sane-airscan [3] https://aur.archlinux.org/packages/sane-airscan/ [4] https://github.com/OpenPrinting/ipp-usb [5] https://lists.debian.org/debian-printing/2020/07/msg00000.html [6] https://github.com/apple/cups/issues/5693

2 1

[arch-dev-public] [PATCH 1/2] makepkg.conf: Change default compression to .zst (fast)
by Jan Alexander Steffens (heftig) 10 Jul '20

10 Jul '20

From: "Jan Alexander Steffens (heftig)" <heftig(a)archlinux.org> Most people create packages from the AUR for local installation. This allows these packages to be created more quickly. --- PKGBUILD | 2 +- makepkg.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/PKGBUILD b/PKGBUILD index 8566270..846a970 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -27,7 +27,7 @@ source=(https://sources.archlinux.org/other/pacman/$pkgname-$pkgver.tar.gz{… sha256sums=('bb201a9f2fb53c28d011f661d50028efce6eef2c1d2a36728bdd0130189349a0' 'SKIP' '3353f363088c73f1f86a890547c0f87c7473e5caf43bbbc768c2e9a7397f2aa2' - '9c769f13c09a6f24c393a9762474eded2f269d8966e7764d9160d62232a7919b') + 'd113252f97f019a13541237a4f4c7fbe9ffd0c3e71ecd7cd8d5d227b378819ab') build() { diff --git a/makepkg.conf b/makepkg.conf index d8bf59e..a277503 100644 --- a/makepkg.conf +++ b/makepkg.conf @@ -132,7 +132,7 @@ DBGSRCDIR="/usr/src/debug" COMPRESSGZ=(gzip -c -f -n) COMPRESSBZ2=(bzip2 -c -f) COMPRESSXZ=(xz -c -z -) -COMPRESSZST=(zstd -c -z -q -) +COMPRESSZST=(zstd -c -T0 -) COMPRESSLRZ=(lrzip -q) COMPRESSLZO=(lzop -q) COMPRESSZ=(compress -c -f) -- 2.27.0

3 4

[arch-dev-public] Reproducible Builds July Update
by Jelle van der Waa 10 Jul '20

10 Jul '20

Hi All, A lot of work has been put into getting Arch packages 100% reproducible, the [community] repository has been added to the rebuilderd instance on reproducible.archlinux.org. As of now [community] is 60% reproducible and packages with file ordering issues have been rebuild and are about to be moved to [community] which will hopefully increase the reproducible package percentage! Archweb now imports the rebuilderd status into it's database so, you are now able to your reproducible package issues. [1] In your Archweb profile, it's possible to get an email notifications when packages change from reproducible to unreproducible. [2] As of now, the software which rebuilds our packages store no logs/diffs of the unreproducible packages. To get a diff: 1) Retrieve the package 2) run "repro -d $pkg" Or when a package is freshly build: $ repro -ndf $pkg To rebuild the newly build package. For some package groups there are "structural" issues such as KDE packages, packages with JAR files and Haskell packages see the wiki for those issues. [3] For Haskell packages, a filesystem/perl bug has to resolved. [4] [1] https://www.archlinux.org/devel/reports/non-reproducible-packages/$username/ [2] https://www.archlinux.org/devel/profile/ [3] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status [4] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status Greetings, Jelle

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] moving bridge-utils to [extra]
by Christian Hesse 02 Jul '20

02 Jul '20

Hello everybody, with the release of bridge-utils v1.7 the utility has been deprecated in favor of iproute2 which supports even more features. I would like to move it from [core] to [extra] if nobody raises concerns. https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git… -- 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);}

1 0

[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

[arch-dev-public] Reproducible builds progress report #3
by Allan McRae 30 May '20

30 May '20

Hi all, A quick updated on the progress of 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 [1]. The remaining packages to fix in [core] are dnssec-anchors, linux, linux-lts, nss and perl. With the possible exception of perl, these are in the "hard" basket. There is plans on how to fix the kernel packages, but that will require some time to sort out. We would be happy for more people to help out so we can get [core] to 100% reproducible. We have investigated some of the packages in [extra] that fail to reproduce here [2]. Note that there are quite a few packages that currently "Failed to build from source" (FTBFS) - it would be very helpful for the reproducible builds team if their maintainers can help fix the packages. You can also use the CI of Arch packages run by Debian to get an overview what the issue is with these packages and see many other packages that are currently failing to build [3]. We also need help to investigate and fix the packages that fail to reproduce that we have not investigated as of yet. There are two easy to use tools to attempt to reproduce a package - "makerepropkg" from devtools and "repro" from the archlinux-repro package. Once these have rebuilt a package, you can use the "diffoscope" tool to look at the differences. Jump in the #archlinux-reproducible IRC channel if you want help interpreting the output, or you could just link to a copy of it in the wiki. [1] https://reproducible.archlinux.org/ [2] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status [3] https://tests.reproducible-builds.org/archlinux/extra.html

3 2

[arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
by Morten Linderud 18 May '20

18 May '20

# Introduction To enable PIE compilation, we have relied on a patched version of the go compiler which has been distributed as `go-pie` since around 2017. However, full RELRO support for go binaries has been a bit back and forth the past years. With some thing working, and other things don't. With the release of Go 1.11 there was support for a general `GOFLAGS` variable that lets us pass flags directly to the compiler. This email details what these flags should be going forward. # Flags Expected environment variables in PKGBUILDs: export CGO_LDFLAGS="$LDFLAGS" export GOFLAGS="-buildmode=pie -trimpath -mod=vendor -modcacherw" Explanation: * `CGO_LDFLAGS` passes the proper `LDFLAGS` to the linker. This should enable full RELRO when used in conjunction with `GOFLAGS`. * `-buildmode=pie` is the proper way to enable PIE and replaces the `go-pie` patch. * `-trimpath` this is to achieve reproducible builds and remove PWD from the binary. * `-modcacherw` modules are downloaded to `$GOPATH/pkg/mod` and by default have the permissions 444 for god knows why. If we want to run `makepkg -c` or `git clean` we won't have the correct permissions. This is probably not a big problem for repository packages, but it's a nice addition so they work as expected. Notice that `-mod=vendor` is also added to `GOFLAGS`. This will make sure we are using the vendored dependencies in the project. If they are not present, please ensure they are downloaded in the `prepare` function: prepare(){ cd $pkgname-$pkgver go mod vendor } If the project is *not* using Go 1.11 modules, missing `go.mod` and/or `go.sum` in the project root, then disable it with `export GO111MODULE=off` and continue with symlink hacks. Some upstreams override these values for strange reasons in their `Makefile` and build systems. You *need* to read over them and ensure this does not happen! # Pacman Clearly we shouldn't have to specify this in every PKGBUILD, so I have been playing with a `pacman` patch that passes all of the variables. However I have been struggling with debug support and figuring out that part of the flags, so nothing have been upstreamed yet. However this is only applicable to around 126 packages, so I guess it's fine? ¯\_(ツ)_/¯ # In conclusion... If there are no objections to the New Way Of Doing Things™, I'll be updating the package guidelines within the next week or two and drop the `go-pie` package containing the patch. For the sake of compatibility, the `go` package will contain a `replaces=('go-pie')`. I also expect people packaging go packages to follow the guidelines! -- Morten Linderud PGP: 9C02FF419FECBE16

6 22

[arch-dev-public] GitLab switchover and SSO migration
by Sven-Hendrik Haase 17 May '20

17 May '20

Hi everyone, As some of you know, we've been toying with two ideas for a while: Arch-wide centralized user management as well as using GitLab to consolidate some of our current services. The overall goal is manifold. In no particular order, the goals are to - make Arch more contributor friendly - provide more modern tools for ourselves - enable more automation - make Arch services more secure - make team management activities less error-prone and more streamlined These two topics (SSO + Gitlab) are a bit intertwined because we wanted to have SSO on GitLab before starting off with that so we'd have a properly validated user base to work with going forward. Also, GitLab seemed like a good first service for SSO due to it having good support for that. After looking at various solutions, we eventually settled on Keycloak since it seemed like a modern, well-maintained, and secure piece of software. It allows us to enable logins for services via OpenID Connect and SAML which is likely the best coverage we could hope for. It also allows us to connect other social login providers such as github.com and gitlab.com and it supports Recaptcha, 2FA, and WebAuthn out of the box. The idea is to eventually transition all our online service as well as SSH keys to Keycloak to ease on-/offboarding and make it less error-prone. As for GitLab, a few months back, we applied for a GitLab Ultimate license in their open-source program [0] and we received one [1]. It's an official program that many other open-source projects benefit from as well and we think it's safe to assume that it'll continue being a thing for the foreseeable future. We have to renew our license yearly. The current license we have has support for 1000 seats but we can likely get more seats if we need them. Our general path is: 1) Transition as many staff-only services to Keycloak as possible. We looked at our current services and put up a table on the wiki that shows support per service [2]. Some of the services that we operate are deprecated or have functionality that is also provided by GitLab. In our current understanding, this concerns Flyspray, Kanboard, and Patchwork. Of those, Kanboard and some of the Flyspray projects will be our first targets to transition to GitLab. We'll continue using Flyspray for the time being for package bugs but will discontinue its use for all non-packaging bugs. The reason for this is that how we manage our bugs for packages is somewhat intertwined with the svn2git migration which is yet to be done and might dictate a different repo structure than what we would come up with currently and we don't want to block on this. This was also discussed in a recent DevOps meeting [3]. 2) We'd like to get rid of our own cgit instance at git.archlinux.org and transition our git hosting into GitLab. AUR git access will stay as it is due to its special shell magic. 3) Eventually, after an internal testing phase of at least a few weeks, we'll want to open Keycloak and GitLab up for outside contributors. We know of the abuse potential and the potential moderation problems and have to make sure to set proper limits and set up monitoring before opening this up. 4) Connect remaining services like BBS and wiki to SSO. In 1) we only mentioned staff-only services because those are less problematic. However, in the future, we'd also like to enable our remaining services to connect to Keycloak. We tried hard to come up with a good source of users to import into Keycloak so that we could seed that database with a solid user base but sadly it appears that there is no trusted source of users that we can rely on. Potential candidates were the wiki, BBS, AUR but we ruled them all out in their current state as none of them have always had email verification and so we can't trust those emails to be the sole source of truth. In order to still allow users to keep their old contributions in cases where they can prove their identity via email, we'll build a new small web application that allows them to connect their new Keycloak identity to their other identities. For now, we seeded the Keycloak database with the only known-good source of trusted emails: Staff from Archweb. We'd like to make heavy use of GitLab CI for running automatic tests and release automation. We're aware that the implication of eventually allowing non-staff users to come in will result in untrusted code being run on our CI. This is fine by itself but security-wise would prevent us from creating trusted releases on the same CI runners. We currently have two sponsored bare-metal GitLab CI runners that we plan on using for running untrusted code. We'll get a new bare-metal box from Hetzner for trusted releases that will only run on hand-picked pipelines that only a select few of us can push to. Bare metal runners also allow us to test and build VM images and such which isn't usually possible on most VPS. On more goal we had is automatic github.com mirroring in some fashion. We looked at creating a two-way github.com <-> GitLab mirror but that setup can break easily in the case of force pushes and race conditions and also would have us looking at both places for pull requests. It seems simpler to us for the time being to have one-way mirroring from our GitLab to github.com only and then allow github.com users to easily collaborate on our GitLab via github.com social login. It's a little bit more hassle for the users than collaborating directly on github.com but it's a lot less hassle for us so it's perhaps the best compromise. These changes will affect all of you in some way but we'll try to make it as painless as possible. As we progress, we'll send concise emails with instructions on what to do. I'm sure that we missed a few details here and there but I'm still convinced that this is a change for the better across the board, even if we don't immediately get everything right. Sorry for the long mail. All of this has been a long time in the making and has been the subject of at least four hackathons with many hours spent in-between. It was a ton of work but I'm happy that we're finally at a stage where we can present something tangible with a plan of attack. Cheers, Sven and the DevOps team [0] https://gitlab.com/gitlab-com/marketing/community-relations/gitlab-oss [1] https://gitlab.com/gitlab-com/marketing/community-relations/gitlab-oss/-/co… [2] https://wiki.archlinux.org/index.php/DeveloperWiki:SSOMigration [3] https://wiki.archlinux.org/index.php/DeveloperWiki:DevopsMeetings/2020-05-06

3 5

[arch-dev-public] Reproducible builds progress report #2 and package rebuilders
by Morten Linderud 05 May '20

05 May '20

Yo! Most should be familiar with the reproducible builds efforts going on in Arch Linux. The goal is to figure out how to make our packages reproducible, which can let users verify that our packages are a product of the PKGBUILD we upload and the source we claim it uses [1]. Last status update was in November [2]! Allan wrote about our attempts at manually reproducing core packages to find mistakes in them. This went fairly well and we managed to reproduce a great deal of packages [3]. The progress since then has been great. Jelle went to Marrakesh for the annual Reproducible Builds summit [4]. Improvements to the tooling have also been made. Most notably kpcyrd has written rebuilderd which was announced on the reproducible builds mailing list last week [5]. rebuilderd aims to be a general package rebuilder, supporting multiple distros with Arch being the first supported one. Rebuilderd allows anyone to easily create package rebuilders to reproduce distributed packages [6]. It currently utilizes `repro` for the reproduction itself [7]. As of writing this we have managed to reproduce 86%-90% of the `[core]` repository across 2-3 rebuilders! One of the rebuilders currently running is our own rebuilder [8]! The current setup runs with 3 worker boxes: * repro1.pkgbuild.com - Arch * repro2.pkgbuild.com - Arch * repro3.pkgbuild.com - Debian 10 One can also find a list of rebuilders currently running on the wiki [9]. A usecase for these rebuilders is to check the packages on your system is currently verified with one or more rebuilders. kpcyrd wrote ismyarchverifiedyet to check this [10]. It should be noted that everything is very much a work in progress. Just because a package is listed as bad doesn't mean it's unreproducible. It might be tooling bugs or other issues. However, if you want to take a look at it you can do so with `repro`, or `makerepropkg` in devtools[11]. Cheers from the Reproducible Builds Team! Sources: [1]: https://reproducible-builds.org/ [2]: https://lists.archlinux.org/pipermail/arch-dev-public/2019-November/029721.… [3]: https://wiki.archlinux.org/index.php/DeveloperWiki:ReproduciblePackages [4]: https://reproducible-builds.org/events/Marrakesh2019/ [5]: https://lists.reproducible-builds.org/pipermail/rb-general/2020-April/00190… [6]: https://github.com/kpcyrd/rebuilderd [7]: https://github.com/archlinux/archlinux-repro [8]: https://reproducible.archlinux.org/ [9]: https://wiki.archlinux.org/index.php/Package_rebuilders [10]: https://github.com/kpcyrd/ismyarchverifiedyet [11]: https://git.archlinux.org/devtools.git/tree/makerepropkg.in -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
by Alexander F Rødseth 01 May '20

01 May '20

Hello, It's time for the semi-yearly package cleanup of [community] packages, as is tradition. I have gathered a list of "unneeded orphans" in [community] (packages that currently has no maintainer, and no other package depends on them) from the excellent list on our web page. TUs and Devs, please adopt, if you're interested: adapta-kde - Adapta theme for KDE Plasma 5 agg - High Quality Rendering Engine for C++ aide - A file integrity checker and intrusion detection program. arch - A modern and remarkable revision control system. arc-kde - Arc theme for KDE Plasma 5 aspell-it - Italian dictionary for aspell aspell-ru - Russian dictionary for aspell bar - A script for showing progress bars. bomberclone - Clone of the game Atomic Bomberman cellwriter - A grid-entry natural handwriting input panel. curseofwar - Fast-paced RTS/Action game with ncurses interface dcfldd - DCFL (DoD Computer Forensics Lab) dd replacement with hashing dumb-a4 - IT, XM, S3M and MOD player library (for Allegro 4) easystroke - Use mouse gestures to initiate commands and hotkeys. eclipse-cpp - Highly extensible IDE for C++ eclipse-java - Highly extensible IDE for Java eclipse-javascript - Highly extensible IDE for JavaScript eclipse-jee - Highly extensible IDE for JEE eclipse-php - Highly extensible IDE for PHP eclipse-rust - Highly extensible IDE for Rust esmtp - An easy SMTP forwarder. gimp-dbp - David's batch processor for the GIMP gimp-plugin-fblur - Makes out of focus with luminosity and depth gimp-plugin-lqr - Plugin for The GIMP providing Liquid Rescale gimp-plugin-wavelet-denoise - Tool to reduce noise in each channel of an image separately gimp-refocus - A sharpen plugin for gimp using FIR Wiener filtering glide - Dependency management and vendoring for Go projects glitz - OpenGL image compositing library gnunet-gtk - A frontend for GNUnet gtk-theme-switch2 - Gtk2 theme switcher gvmd - greenbone-vulnerability-manager gvm-tools - greenbone-vulnerability-manager tools ifuse - A fuse filesystem to access the contents of an iPhone or iPod Touch iverilog - Icarus Verilog compiler and simulation tool javasqlite - Java wrapper including a basic JDBC driver for the SQLite 2/3 database engine matrix-appservice-irc - Node.js IRC bridge for Matrix minbif - An IRC gateway to IM networks that uses libpurple. mod_wsgi - Python WSGI adapter module for Apache monica - Monitor calibration tool mythes-pl - Polish thesaurus ode - High performance library for simulating rigid body dynamics openvas - Vulnerability scanning Daemon pinta - Drawing/editing program modeled after Paint.NET. It's goal is to provide a simplified alternative to GIMP for casual users processing - Programming environment for creating images, animations and interactions projectm-pulseaudio - Music visualizer which uses 3D accelerated iterative image based rendering (pulseaudio) projectm-sdl - Music visualizer which uses 3D accelerated iterative image based rendering (sdl) python2-pyxmpp - Python XMPP and Jabber implementation based on libxml2 python-pyinsane - Python library to access and use image scanners qtspim - New user interface for spim, a MIPS simulator. rdiff-backup - A utility for local/remote mirroring and incremental backups. remacs - Emacs with parts of it written in Rust steghide - Embeds a message in a file by replacing some of the least significant bits surf - A simple web browser based on WebKit/GTK+. tabbed - Simple generic tabbed fronted to xembed aware applications. transset-df - A patched version of X.Org's transset with added functionality. tuxpaint-config - Tux Paint configuration tool uncrustify - A source code beautifier vim-jellybeans - Colorful, dark color scheme, inspired by ir_black and twilight vim-ultisnips - TextMate-style snippets for Vim. wren - Small, fast, class-based concurrent scripting language xautomation - Controls X from the command line and does "visual scraping". xbindkeys - Launch shell commands with your keyboard or your mouse under X zapcc - C++ compiler based on Clang, but significantly faster zeal - An offline API documentation browser I'll wait two weeks before adding them to AUR, running both `db-remove` and `svn rm` on the unmaintained packages. PS. If unmaintained orphans in [core] could be moved to [extra], and unmaintained orphans in [extra] could be moved to [community], that could be a nice "trickle down" effect and would be an appreciated cleanup as well, but that is just my opinion. To quote our newly elected leader, in connection with the previous spring cleaning: > Cleanup is always good > > - Levente Polyak -- Best regards, Alexander F. Rødseth / xyproto

6 6

[arch-dev-public] Dropping pangox-compat
by Jan de Groot 28 Apr '20

28 Apr '20

Hello, I would like to drop pangox-compat. Reasons: 1. it does not compile with pango 1.44 2. the current compiled package links fine, but does not render any text when used with pango 1.44 3. upstream has archived the source and doesn't support it anymore 4. People care about 1. but not about 2. -> library only exists because software links to it So far we have only a few packages depending on it: - gtkglext (direct dependency, gdk_gl_font_use_pango_font* functions, removed in git master) - gtkmathview (direct dependency, libraries linking to it not used by abiword) - gambas3-gb-gtk-opengl (pulled in through gtkglext, no further relations) Todo: - patch gtkglext to remove API depending on pangox-compat, already packaged, not uploaded yet - drop gtkmathview parts that depend on pangox-compat (Abiword needs the libxml2 module, nothing else) - rebuild gambas3 (is in staging for ICU rebuild now) Any objections?

2 1

[arch-dev-public] moving dhcpcd to [extra]?
by Antonio Rojas 22 Apr '20

22 Apr '20

Is there any reason to keep dhcpcd in [core]? It's only an optional dependency of netctl in [core], it currently lacks an active maintainer, it doesn't seem to be much used (given the slow pace of signoffs), and there's already a basic dhcp tool in [core] (networkd). Any objections to move it to [extra]?

4 3

[arch-dev-public] qemu-arch-extra, ovmf, edk2
by David Runge 20 Apr '20

20 Apr '20

Hi all, Over the weekend I worked on getting archiso into a more reproducible state by building edk2's UEFI Shell from scratch so we can include it into the iso instead of downloading it. I realized, that the current ovmf [1] package basically uses the same toolchain (edk2), so I created a split package for them [2]. When looking at the included qemu firmware configuration files [3], I wondered why these are there and tried to get around using them by placing symlinks into the qemu directory (/usr/share/qemu) as qemu already provides configuratino files for edk2 based ovmf pointing at its own data directory. Only afterwards I realized, that the files mentioned in the qemu firmware configuration files (/usr/share/firmware/*.json) actually target the firmware blobs packaged with qemu-arch-extra (after Anatol was trying out the package and ran into file conflicts :-/). Long story short: While a separate package (e.g. edk2-ovmf) gives us more flexibility over **how** to create those firmwares, allows for signing of secure boot firmwares in the future, staying on top of edk2 releases and allows other applications that are unaware of those files below /usr/share/qemu to use them (some, such as lxd seem to default to /usr/share/OVMF for historical reasons), it is unclear to me whether qemu configuration files should or need to be still created for it (similar to the ones found in the current ovmf package). Any insights would be much appreciated! Best, David [1] https://www.archlinux.org/packages/extra/any/ovmf/ [2] https://www.archlinux.org/packages/testing/any/edk2/ [3] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/ovmf -- https://sleepmap.de

1 0

[arch-dev-public] Packages spring cleanup!
by Jelle van der Waa 20 Apr '20

20 Apr '20

Hi all, I'm going to disown some packages as I no longer actively use them and I want to shift focus into my on other Arch roles: ettercap openttd-opensfx openttd-opengfx rdesktop tesseract tesseract-* tidy unshield vim-pastie vim-align pstreams pdf2djvu bonnie++ gsmartcontrol leptonica jbigkit pbpst ccd2iso chromium-bsu fsarchiver dot2tex If packages need to be moved to [community] for you to be able to adopt them, please say so. Greetings, Jelle

4 3

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
by Morten Linderud 20 Apr '20

20 Apr '20

On Mon, Apr 20, 2020 at 09:05:27AM +0300, Christoph Gysin wrote: > On Mon, Apr 20, 2020 at 1:32 AM Morten Linderud via arch-dev-public < > arch-dev-public(a)archlinux.org> wrote: > > > https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines > > > > In the fist example, you set both: > > CGO_LDFLAGS=$LDFLAGS > > and pass: > > -ldflags "-extldflags ${LDFLAGS}" > > Yet in the example PKGBUILD, only the former? If you read the example: # *or alternatively* you can define some of these flags from the CLI options" > Also, maybe it would be nice to have an example how to add additional > ldflags correctly without overwriting LDFLAGS, e.g. passing: > > -ldflags "-X my.package.Version=$pkgver" The goal of the page is not to teach you how the go compiler works, but I'll consider it. Thanks -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Yet another missing solink announcement
by Antonio Rojas 13 Apr '20

13 Apr '20

The zn_poly package prior to version 0.9.2-2 was missing a soname link. This has been fixed in 0.9.2-2, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get an error zn_poly: /usr/lib/libzn_poly-0.9.so exists in filesystem when updating, use pacman -Syu --overwrite usr/lib/libzn_poly-0.9.so to perform the upgrade.

1 0

[arch-dev-public] News draft: nss>=3.51.1-1 and lib32-nss>=3.51.1-1 updates require manual intervention
by Jan Alexander Steffens 09 Apr '20

09 Apr '20

The nss and lib32-nss packages prior to version 3.51.1-1 were missing a soname link each. This has been fixed in 3.51.1-1, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get any of these errors nss: /usr/lib/p11-kit-trust.so exists in filesystem lib32-nss: /usr/lib32/p11-kit-trust.so exists in filesystem when updating, use pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so to perform the upgrade.

2 1

[arch-dev-public] Away on holiday for the next 2 weeks
by Eli Schwartz 06 Apr '20

06 Apr '20

I've been only sporadically available the last few days, as some people may have noticed, and I will be mostly inaccessible until after Passover[1] / the 19th. It's been very hectic here recently, and ugh, it is so frustrating to get ready for a major holiday in the middle of a pandemic. :( We have still done basically no shopping because my brother was sick so we were in quarantine. Fortunately he's feeling a lot better now and everyone else is fine, so we get to be even *busier*. \o/ I don't anticipate much other than routine updates for my packages; feel free to update anything that is needed. There are already a few updates I haven't had time to handle yet. Note to jelle: If/when calibre gets a new release it will probably need a new rapydscript-ng release, if so, ask upstream for one. -- Eli Schwartz Bug Wrangler and Trusted User [1] https://en.wikipedia.org/wiki/Passover

2 1

[arch-dev-public] TexLive 2020 packages
by Rémy Oudompheng 02 Apr '20

02 Apr '20

Hello, TexLive 2020 is frozen upstream and will be officially released in the coming days. Packages have been uploaded to [testing] and [community-testing] (for biber). Please let me know if you encounter issues with these. Regards, Rémy.

1 0

[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] Discussion - Increasing our CPU requirements
by Allan McRae 30 Mar '20

30 Mar '20

Remember when Arch Linux was optimized out of the box. We have the blazingly fast i686 port while other distros hung out in i386 land. Those were the days where the idea of Arch being fast started. Now it has degraded to stuff of legend. Now, x86_64 is old. We should continue to push forward and add further optimization. Reasonable optimizations to consider: AVX2 FMA SSE4.2 AVX2 is Intel Haswell and newer or AMD Ryzen and newer. This CPUs released 2013 to 2015. So 5 - 7 years old. Discuss.

9 16

Re: [arch-dev-public] Discussion - Increasing our CPU requirements
by Allan McRae 29 Mar '20

29 Mar '20

On 29/3/20 9:27 pm, Amish wrote: > Also if I am not wrong Arch philosophy talks only about latest software > and no where there is mention of latest hardware being a compulsion. It used to. One of the original selling points was i686 optimization. Then we got lazy, and stopped innovating. A

1 0

[arch-dev-public] News draft: hplip 3.20.3-2 update requires manual intervention
by Andreas Radke 18 Mar '20

18 Mar '20

News draft - https://bugs.archlinux.org/task/61329 The hplip package prior to version 3.20.3-2 was missing the compiled python modules. This has been fixed in 3.20.3-2, so the upgrade will need to overwrite the untracked pyc files created. If you get errors like these hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in filesystem ...many more... when updating, use pacman -Suy --overwrite /usr/share/hplip/\* to perform the upgrade. -Andy

2 1

[arch-dev-public] Proposal to remove PyGTK
by Balló György 17 Mar '20

17 Mar '20

Hi all, I would propose to remove PyGTK from the official repositories. PyGTK was used to create GTK2 applications in python2. It's deprecated and unmaintained since 2011 in favor of PyGObject, and does not receive any fixes since then. The following packages are in progress to be ported from PyGTK to PyGObject, but not released yet: - diffuse: a fork with python3 support is in progress: https://github.com/MightyCreak/diffuse - gimp: GTK3/python3 port is very slow, python extensions support can be disabled with the --disable-python switch - ibus-sunpinyin: python3 port was merged - mcomix: a fork with python3 support is available: https://github.com/multiSnow/mcomix3 - nmap: python3 port of ndiff is available, zenmap is not ported yet (can be disabled with --without-ndiff --without-zenmap switches): https://github.com/nmap/nmap/pull/1807 - nicotine+: python3 port is in progress: https://github.com/Nicotine-Plus/nicotine-plus/pull/106 The following packages were not ported yet and have inactive upstream: - gutenpy: last released in 2006 - ibus-googlepinyin: last released in 2012 - pyneighborhood: last released in 2011 - wifi-radar: last released in 2015 Any objections? -- György Balló Trusted User

4 3

Re: [arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 11 Mar '20

11 Mar '20

On Sun, 23 Feb 2020 at 13:57, Sven-Hendrik Haase <sh(a)lutzhaase.com> wrote: > On Wed, 18 Jul 2018 at 01:40, Sven-Hendrik Haase <sh(a)lutzhaase.com> wrote: > >> 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. >> > > This is still a problem. Somebody please over the fricken 390xx packages. > Since I was unable to trick anyone into maintaining these packages despite the best attempts, I'll be dropping them to AUR soon.

1 1

[arch-dev-public] News draft: firewalld>=0.8.1-2 update requires manual intervention
by Jan Alexander Steffens 29 Feb '20

29 Feb '20

The firewalld package prior to version 0.8.1-2 was missing the compiled python modules. This has been fixed in 0.8.1-2, so the upgrade will need to overwrite the untracked pyc files created. If you get errors like these firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/__init__.cpython-38.pyc exists in filesystem firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/client.cpython-38.pyc exists in filesystem firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/dbus_utils.cpython-38.pyc exists in filesystem ...many more... when updating, use pacman -Suy --overwrite /usr/lib/python3.8/site-packages/firewall/\* to perform the upgrade.

2 1

[arch-dev-public] "date" C++ library packaging
by Brett Cornwall 24 Feb '20

24 Feb '20

I made the silly mistake of posting first to [arch-general]. Sorry! On 2020-02-13 09:24, Morten Linderud wrote: >On Thu, Feb 13, 2020 at 12:09:27AM -0800, Brett Cornwall via arch-general wrote: >> Waybar [1] just had an update where it pulled in a project called "date" >> [2]. I'm hesitant to package this under the name "date" since GNU coreutils >> shares a binary with that name. But this isn't a totally obscure library. >> >> Should I persuade upstream to change the name? Should I package it under >> another name? Or should I lay claim to the unused "date" package name and go >> on with my life? > >"chrono-date" could maybe work as an alternative name? > >I'm unsure why this is in [arch-general] and not [arch-dev-public] :) On 2020-02-13 02:24, David C. Rankin wrote: >And with the note that much of Howard Hinnant's date/time library is being >incorporated into the next C++ standard. Quite a feather in anyone's cap. Does anyone have any strong opinions?

2 1

[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] Potential removal of Chromium in ~2 months
by Evangelos Foutras 22 Feb '20

22 Feb '20

Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1] When I created these API keys back in 2013, there was a semi-official effort by the Chrome Team to support distro builds of Chromium in regard to accessing Google APIs; a few minor hiccups along the way were quickly resolved. I feel this arrangement is starting to fall apart (in spite of some upstream Chrome developers' best efforts). To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me. To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality. [1] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/Z…

3 5

[arch-dev-public] Vacationing
by David Runge 21 Feb '20

21 Feb '20

Hi all, I'll be out until Wednesday (2020-02-26) in a location with likely very limited internet access and will not be updating packages. If there are any urgent updates required, of course feel free to do them! In the case of libgit2 rebuilds, I got stuck on ruby-rugged, as a subset of the integration tests fail with the new version of libgit2 (and a different subset with the current version of libgit2). I will not be touching this until then. Again: If the upgrade proves to be urgent, feel free to spend time on this. Thanks! :) Best, David -- https://sleepmap.de

1 0

[arch-dev-public] planet.archlinux.org news proposal
by Jelle van der Waa 20 Feb '20

20 Feb '20

Hi, The new planet.archlinux.org has a different implementation and RSS feed url. I've added fallback urls for two variants of the RSS feed but would like users to switch to the new url so a news post seemed appropriate. News proposal below: # Planet Arch Linux migration The software behind planet.archlinux.org was implemented in Python 2 and no longer maintained upstream. This functionality has now been implemented in archlinux.org's archweb backend which is actively maintained by offers a slightly different experience. The most notable change is the offered feeds and the feed location. Archweb only offers an Atom feed which is located at https://archlinux.org/feeds/planet.

2 1

[arch-dev-public] Archweb update
by Jelle van der Waa 17 Feb '20

17 Feb '20

Hi, A new archweb has been deployed with the following notable changes: * Implement planet functionality for archweb, to replace planet.archlinux.org which is Python 2 and not going to be ported. Every user on archweb can configure the website and website_rss urls in their profile which will be shown on planet after a systemd service pulls the RSS feeds in. [1] [2] Note that the implementation is a bit different from a normal planet, since only a limited amount of text is saved in archweb and the HTML is "purified" using python-bleach. It is mostly aimed at aggregating our feeds. * Add new RSS feeds for stable / non stable repos [3] Note that soon planet.archlinux.org will point to archweb and the old planet will die. [1] https://www.archlinux.org/devel/profile/ [2] https://www.archlinux.org/planet/ [3] https://www.archlinux.org/feeds/

2 2

[arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
by Gaetan Bisson 17 Feb '20

17 Feb '20

Dear all, I'd like to post the following news item within the hour. ======== Title: sshd needs restarting after upgrading to openssh-8.2p1 Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`. ======== I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution... Cheers. -- Gaetan

3 8

[arch-dev-public] Archweb update
by Jelle van der Waa 13 Feb '20

13 Feb '20

Hi, A new archweb has been deployed with the following notable changes: * Implement planet functionality for archweb, to replace planet.archlinux.org which is Python 2 and not going to be ported. Every user on archweb can configure the website and website_rss urls in their profile which will be shown on planet after a systemd service pulls the RSS feeds in. [1] [2] Note that the implementation is a bit different from a normal planet, since only a limited amount of text is saved in archweb and the HTML is "purified" using python-bleach. It is mostly aimed at aggregating our feeds. * Add new RSS feeds for stable / non stable repos [3] Note that soon planet.archlinux.org will point to archweb and the old planet will die. [1] https://www.archlinux.org/devel/profile/ [2] https://www.archlinux.org/planet/ [3] https://www.archlinux.org/feeds/

1 0

[arch-dev-public] Making package signing keys available in our WKD
by Jonas Witschel 04 Feb '20

04 Feb '20

Hi everybody, since version 5.2 pacman supports downloading the package signing keys from our newly implemented Web Key Directory (WKD) [1]. Since the key server network that we are currently relying on for this purpose is not in a very healthy state any more [2], it seems like a good time to store all PGP keys in our WKD to be independent of the key servers. This will require an update of some the existing keys: keys in the WKD are looked up by email address, so you need to have an user ID with an @archlinux.org email address on your PGP key to make use of our existing WKD (or set up a WKD on your own server in case you are using a custom domain for your email address). I you don't have an @archlinux.org email address yet, you can talk to the Devops team e.g. using the #archlinux-devops IRC channel to get on set up. To see if your key is already in our WKD, please visit [3]. If all three columns are green, you are all set, otherwise you need to take one of the following actions: - If the "Has @archlinux.org UID" column is "No", you need to add an additional UID to your PGP key: $ gpg --edit-key YOURKEY adduid save $ gpg --send-keys YOURKEY - If the "Uses @archlinux.org email for packaging" column is "No", you need to set the PACKAGER variable in your makepkg.conf to use your (newly created) @archlinux.org UID. Please double-check the configuration of all the machines you use to build packages since the packager email address is used for the key lookup in pacman. - If the "@archlinux.org UID is fully trusted" column is "No", your key already has the required format, but the UID needs to be signed by at least three master key holders. You do not need to do anything right now (apart from maybe changing the PACKAGER variable as described in the previous bullet point). In order to make it easier for the master key holders to sign all the new UIDs, it would be great if everybody could add the new UID to their key within the next two months. I will then collect all the new and currently untrusted UIDs and submit them to the key holders for batch signing. If there are any questions on adding the new UID or adjusting the packager variable, please do not hesitate to contact me. Cheers, Jonas [1] https://bugs.archlinux.org/task/63171 [2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f [3] https://wiki.archlinux.org/index.php/User:Diabonas/WKD_support_by_developer…

1 0

[arch-dev-public] Replacing bzr with breezy
by Maxime Gauduin 04 Feb '20

04 Feb '20

Hi folks, As you may know bzr is python2 only, and most distros [0] [1] are switching over to a drop-in replacement fork named breezy [2]. The latest version just added python 3.8 support, so I pushed a package to [extra] [3]. I propose we add a symlink from bzr to brz in the breezy package, and conflict with/replace the bzr package so we can drop bzr, bzr- fastimport and python2-fastimport (fastimport is built in breezy) and leave in a world with three less python2 packages. Any objection? [0] https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883146 [2] https://www.breezy-vcs.org/ [3] https://www.archlinux.org/packages/extra/x86_64/breezy/ Cheers, -- Maxime

2 2

[arch-dev-public] mailman3/hyperkitty/postorius in the repos now
by David Runge 03 Feb '20

03 Feb '20

Hey all! I'm just on my way home from FOSDEM - train time, mail time ;-) I've spent the last weeks bringing the mailman3 ecosystem(!) to [community] and [community-testing] (~56 packages). Today I've added wiki pages for mailman3 [1] (it will replace the current mailman page once it's done by moving that to be 'mailman2' and eventually deleting it), hyperkitty [2] and postorius [3]. I've done initial integration tests with mailman3, hyperkitty and postorius and they "should just work"(TM). Before moving all the stuff to [community] and replacing the wiki page, it would be great to get some further integration testing with actual mail servers (note the expansion macro [4] in the mailman article) and importing of mailman2 data [5] [6] going. Any help is very much appreciated, as the switch requires quite the data migration and configuration changes for e.g. our own lists (the archives of some of them are pretty large). Additionally, the hosting aspects of both Hyperkitty and Postorius need some expansion as well (e.g. for Apache setups and for proper subdomain setups). Everyone, feel invited to install and test the applications and propose fixes and expansions to the documentation (or packages) as needed. Best, David [1] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman [2] https://wiki.archlinux.org/index.php/Hyperkitty [3] https://wiki.archlinux.org/index.php/Postorius [4] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Integrate_with… [5] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Migrate_from_m… [6] https://wiki.archlinux.org/index.php/Hyperkitty#Importing_mailman2_archives -- https://sleepmap.de

3 3

[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

[arch-dev-public] Adding a "posix" metapackage
by Eli Schwartz 09 Jan '20

09 Jan '20

After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress. I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes... One of the advantages of having this metapackage is that someone can, while installing arch, `pacman -S posix-user-portability` and get essentially everything one would expect to have available on a unix-like platform, most notably, the interesting parts of the base group that no longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed. I've only included XCU for now, because the system interfaces and headers are a bit out of scope for me to package and replace in the event that they'd be missing anything... and also because I'm mainly interested in the POSIX toolset itself. That being said, I'd certainly be open to suggested improvements, should anyone have recommendations for expanding the scope. Thoughts? For reference, here is my PKGBUILD: https://paste.xinu.at/m-XoggqFGE/ And reproduced here: # Maintainer: Eli Schwartz <eschwartz(a)archlinux.org> # The list of utilities can be found at # https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html # Not all utilities are required: if the synopsis is boxed up and annotated # with a code, it is only needed for that code. Examples: user portability, # XSI, Software Development, C Development. Some of these groups were # implemented here too, though almost certainly the only important ones are UP # and XSI. pkgbase=posix pkgname=('posix' 'posix-xsi' 'posix-user-portability' 'posix-c-development' 'posix-software-development') pkgver=2017 pkgrel=1 pkgdesc="metapackage providing the POSIX shell and utilities (XCU)" arch=('any') url="https://pubs.opengroup.org/onlinepubs/9699919799/" depends=('at' # at batch 'awk' 'coreutils' # basename cat chgrp chmod chown cksum comm cp csplit cut date dd df dirname # du echo env expand expr false fold head id join ln logname ls mkdir mkfifo # mv nice nohup od paste pathchk pr printf pwd rm rmdir sleep sort split stty # tail tee test touch tr true tsort tty uname unexpand uniq unlink wc who 'bc' 'diffutils' # cmp diff 'cronie' # crontab 'ed' 'file' 'findutils' # find xargs 'glibc' # gencat getconf iconv locale localedef 'grep' 'util-linux' # kill logger mesg newgrp renice write 'cups' # lp -- sorry! 'm4' 's-nail' # mailx 'man-db' # man 'patch' 'pax' 'procps-ng' # ps 'sed' 'sh' 'binutils' # strings 'ncurses' # tabs tput # 'time' # is a shell builtin too 'sharutils' # uudecode uuencode ) package_posix() { : } package_posix-xsi() { pkgdesc+=": X/Open System Interfaces" depends=('posix' 'util-linux' # cal ipcrm ipcs kill 'ncompress' # compress 'coreutils' # df link nl od 'psmisc' # fuser 'procps-ng' # ps 'ncurses' # tabs 'gzip' # uncompress (but not compress...) zcat 'uucp' # uucp uustat uux # missing: cflow cxref # missing SCCS: admin delta get prs rmdel sact sccs unget val what ) install=xsi.install } package_posix-user-portability() { pkgdesc+=": User Portability Utilities" depends=('posix' 'vi' # ex vi 'util-linux' # more 'inetutils' # talk ) } package_posix-c-development() { pkgdesc+=": C-Language Development Utilities" depends=('posix' 'gcc' # c99 'flex' # lex 'bison' # yacc ) } package_posix-software-development() { pkgdesc+=": Software Development" depends=('posix' 'binutils' # ar nm strip 'ctags' 'make' ) } # xsi.install post_install() { cat << '__EOF__' warning: XSI compliance is not 100% complete, not all tools are packaged. - The SCCS development tools are not available, but may be obtained from the AUR in the event you believe anyone still uses it. - The cflow package can likewise be obtained from the AUR. - A cxref package may need to be created, if there are interested parties. __EOF__ } -- Eli Schwartz Bug Wrangler and Trusted User

5 10

[arch-dev-public] Killing Python 2 (v2)
by Jelle van der Waa 07 Jan '20

07 Jan '20

Hi All, 2020 happened and Python 2 is very much still alive, even worse there will be an update in April. However we should actively strive to get rid of Python 2 before it. Some upstreams are (still) working on porting to Python 3 such as Kodi, inkscape, mercurial and many more but for packages with dead upstreams and being unrequired I propose we remove them. For packages still providing python2 functionality such as vim and others I propose we remove python2 support to actively to discourage people using it. Dropping non-ported python2 packages: * rox - python2, dead and GTK2 * wifite - upstream dead * shedskin - python2 specific, won't be updated * jmc - dead upstream * pydb - python debugger (python2 specific) * pyrex - dead upstream * mcomix - dead upstream * singularity - dead upstream * pathological - dead upstream * armagetronad - dead upstream, optional dep can be removed * ming - no python2 compatibility * ipcheck - dead upstream * mediaproxy - dead upstream * wicd/wicd-gtk - dead upstream, better alternatives available * sgmltools-lite - dead upstream # Remove python2 support * pycharm-community-edition - remove python2 support * vim - remove python2 support * graphviz - remove python2 bindings or update to python3 * notmuch - switch to python3 bindings * libproxy - remove python2 bindings * many others! Greetings, Jelle van der Waa

8 12

Re: [arch-dev-public] Restricting ability to post news items
by Gaetan Bisson 06 Jan '20

06 Jan '20

[2020-01-06 16:48:48 -0300] Giancarlo Razzolini: > I'm moving this to staff@, please stop replying on a-d-p. Doing dirty laundry > in public is not necessary. And I'm moving this back to arch-dev-public because most staff aren't concerned with posting news items. Besides, there's nothing secret about this and I don't believe in hiding policy discussions out of the public eye. > For making that argument, you must first demonstrate that the news *wasn't* > used responsibly or there was any abuse of any kind. My reply was only to your suggestion that "everything should be written down". For clarity, let me recall how the conversation went: - Allan: Do we really need to write down everything? - Giancarlo: Yes, we do. - Me: No, we don't. As you can see I expressed no opinion on whether the latest news item was responsible. But since you ask, I think that question is moot since it's already been posted. However I deeply deplore that it was not discussed beforehand on arch-dev-public first. > Also, you're implying that this particular news entry wasn't thought through, > when in fact I can preset mounts of evidence to the contrary. Just a look at the > logs for #archlinux-tu for the 3th and 4th will tell you that. I don't have access to #archlinux-tu. Even if I did, I would not have been constantly monitoring the channel during the 3th and the 4th. What I don't understand is why you don't advocate the use of a medium of communication that encompasses both devs and TUs and allows people in different timezones or with different schedules to contribute. > If we are going to start *punishing* people, you damn right we *need* > guidelines for it. I strongly disagree. We don't need rules and we don't need punishments. We just entrust staff members with powers and expect them to use said powers responsibly. If they don't, we discuss on a case-by-case basis whether to strip them of the power they abused. Cheers. -- Gaetan

1 0

[arch-dev-public] Restricting ability to post news items
by Allan McRae 06 Jan '20

06 Jan '20

Hi all, Following the roll out of the base metapackage, and its poorly written news post, we agreed that all new posts should have a draft posted to arch-dev-public. There was a potential exclusion for trivial --overwrite posts [1]. This was followed for the Xorg update. It was not followed for the zstd update. Given people have shown an inability to follow simple instructions, I am proposing a restriction on the ability to make news posts. This can either be a bulk restriction now, or just removing anybody who does not follow the rule from ever making a news post again. Allan [1] and why have we had so many missing library symlinks lately... surely checkpkg detects all the missing symlinks compared to previous packages.

7 11

[arch-dev-public] cleanup dead Xorg packages
by Andreas Radke 06 Jan '20

06 Jan '20

I've created a bug[1] to follow a long overdue Xorg cleanup to drop legacy and dead code from our packages. This will require fixing makedepends in a 2nd step. I will do the most work over the next days/weeks. This all didn't fit well into a single ToDo list. If you find more really dead Xorg packages add it please to the bug tracker with a link to its removal. Use the mailing list for further discussion if needed when you think a certain feature isn't widely used and should be dropped as well. -Andy [1] https://bugs.archlinux.org/task/64892

10 17

Re: [arch-dev-public] Killing Python 2 (v2)
by Giancarlo Razzolini 02 Jan '20

02 Jan '20

Em janeiro 2, 2020 14:10 Brett Cornwall escreveu: > On 2020-01-02 13:43, Giancarlo Razzolini via arch-dev-public wrote: > > Er, the first end-of-life was five years ago and was then extended to > 2020 to help accommodate the transition. I think a five-year grace > period was long enough already... > While I agree with that, it doesn't change the fact that having python2 lint and syntax checking tools will *still* be helpful in the foreseeable future. There are lots of reasons, educational ones, proprietary legacy code ones, etc. Let's not throw the baby out with the water. Just saying, if there's an opportunity to keep linters and syntax checkers/highlighters that don't necessarily require python2, it's not doing any *real* harm, provided they still are maintained projects. Will we eventually remove those as well? Sure. But the ability to read python2 code properly is independent of the ability to *run* python2 code. They are separate things. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] Disowned python/flask packages
by Antonio Rojas 01 Jan '20

01 Jan '20

They were dependencies of the obsolete sage-notebook and I no longer need them: python-flask-autoindex python-flask-silk python-flask-oldsessions python-flask-babel python-speaklater I will drop the ones that are not needed by anything to AUR if nobody adopts them in a week.

1 0

[arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org
by Sven-Hendrik Haase 01 Jan '20

01 Jan '20

Hi all, I set up a new Hetzner VPS that is going to become our new homedir/public_html server available to all TUs and Devs like soyuz was. We decided to decommission soyuz and put the public_html stuff on its own server for security reasons, to cut costs, and so that we can compartmentalize further. The server uses a Hetzner Cloud Volume which we can scale if we want but for now, it's 100GiB of zstd-compressed btrfs. If possible, we'd like to keep it at this size for the time being. You can host your own repos there if you want and that's fine. Please talk to us beforehand if you see yourself exhausting the volume with what you want to do. If you had stuff hosted in the public_html of soyuz, I'd ask you to transfer stuff over to the new box which is already reachable at the names pkgbuild.com (you'll get an SSH error because of this) and homedir.archlinux.org. Please check if you can throw away some old stuff/junk that you might not necessarily need on the new server. This new box is *not for building*. That's what dragon is for. Please only put documents/files onto the new pkgbuild.com that you actually want people to be able to access publicly. The box has no building facilities and you get no sudo'd commands. soyuz is going to be decommissioned no sooner than 2020-01-01 but do not expect it to hang around for long after that. We will not transfer any files for you from soyuz. In other words: All data not explicitly transferred by you will be destroyed after 2020-01-01. Please bring up any problems you might have with this new server on the arch-devops list or IRC (#archlinux-devops). Enjoy, Sven

2 3

[arch-dev-public] zstd rollout complete
by Robin Broda 01 Jan '20

01 Jan '20

Hello everyone, We have just tested and released everything necessary for zstd packages in our repos. Right now, the updated devtools is still in [testing], but our preliminary testing shows that nothing immediately combusted on release, so I'm confident. Once it has left testing, packages built with devtools will automatically use zstd with the correct options. There is no intervention necessary, this should be an essentially transparent process. Happy packaging and greetings from 36c3. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

4 3

[arch-dev-public] RFC: (devtools) Changing default compression method to zstd
by Robin Broda 31 Dec '19

31 Dec '19

Hello all, in the past few weeks, some TUs and Developers have compared different compression algorithms to potentially replace the default compression method used in devtools. The current method is `xz -c -z -` which is single-threaded and rather slow, so we are looking to replace it with something faster. Multithreaded xz has come up in the past, and was quickly dismissed due to edge cases that would end up with packages being unreproducible on different machines - namely, xz -T0 -- the method that automatically determines the amount of threads -- produces different results when the amount of cores in a system is == 1: $ taskset -c 1 xz -c -z - -T0 < test > test.xz && sha256sum test.xz fe95a1af78304ae4be508e071f6697296e52b625fba95fca5622757779633d90 test.xz $ taskset -c 1,2 xz -c -z - -T0 < test > test.xz && sha256sum test.xz 3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99 test.xz $ taskset -c 1,2,3 xz -c -z - -T0 < test > test.xz && sha256sum test.xz 3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99 test.xz With this mail, i propose to switch to `zstd` instead (https://github.com/facebook/zstd) zstd does *not* exhibit this issue, and anthraxx has asked for some clarifications (https://github.com/facebook/zstd/issues/999#issuecomment-474114799) - just in case. The response is that zstd is generally friendly to reproducible builds. After some testing with heftig, I ran some additional benchmarks on our new build host 'dragon' to determine the appropriate compression level. Here are the results: (sorry for the wide mail :b) Compressor Package Name Size (MiB) Comp. Size (MiB) Ratio Time (mm:ss) Max. RSS in MiB Decomp. Time (mm:ss) Decomp. RSS in MiB xz -c -z - cuda 3038,58 1316,93 43,34% 19:03.44 95,32 1:19.74 10,18 zstd -c -T0 -18 - cuda 3038,58 1375,41 45,26% 01:12.50 2648,93 0:04.46 10,70 zstd -c -T0 -19 - cuda 3038,58 1371,94 45,15% 01:34.13 3401,67 0:04.47 10,73 zstd -c -T0 -20 - cuda 3038,58 1371,94 45,15% 01:34.34 3416,90 0:04.46 10,79 zstd -c -T0 -21 - cuda 3038,58 1371,94 45,15% 01:31.60 3414,14 0:04.46 10,79 xz -c -z - gcc 135,54 33,11 24,43% 00:54.54 95,34 0:02.59 10,11 zstd -c -T0 -18 - gcc 135,54 35,87 26,47% 00:12.37 419,23 0:00.23 10,77 zstd -c -T0 -19 - gcc 135,54 35,66 26,31% 00:15.76 578,99 0:00.24 10,66 zstd -c -T0 -20 - gcc 135,54 35,66 26,31% 00:16.36 579,11 0:00.25 10,75 zstd -c -T0 -21 - gcc 135,54 35,66 26,31% 00:16.18 579,01 0:00.25 10,46 xz -c -z - go 484,10 122,10 25,22% 03:19.11 95,35 0:08.78 10,16 zstd -c -T0 -18 - go 484,10 132,69 27,41% 00:15.40 1402,99 0:00.80 10,80 zstd -c -T0 -19 - go 484,10 131,84 27,23% 00:19.74 1914,07 0:00.79 10,78 zstd -c -T0 -20 - go 484,10 131,84 27,23% 00:20.19 1914,11 0:00.77 10,72 zstd -c -T0 -21 - go 484,10 131,84 27,23% 00:20.08 1914,09 0:00.79 10,78 xz -c -z - intellij-idea-community-edition 772,46 384,37 49,76% 04:53.01 95,31 0:28.69 10,18 zstd -c -T0 -18 - intellij-idea-community-edition 772,46 392,44 50,80% 00:27.10 2341,02 0:00.91 10,63 zstd -c -T0 -19 - intellij-idea-community-edition 772,46 391,04 50,62% 00:37.09 3107,97 0:00.93 10,47 zstd -c -T0 -20 - intellij-idea-community-edition 772,46 391,04 50,62% 00:34.43 3107,87 0:00.93 10,70 zstd -c -T0 -21 - intellij-idea-community-edition 772,46 391,04 50,62% 00:35.45 3104,94 0:00.94 10,64 xz -c -z - linux 80,15 70,66 88,17% 00:31.27 95,35 0:03.85 10,11 zstd -c -T0 -18 - linux 80,15 70,22 87,62% 00:07.48 299,30 0:00.05 10,64 zstd -c -T0 -19 - linux 80,15 70,18 87,56% 00:09.32 395,32 0:00.05 10,72 zstd -c -T0 -20 - linux 80,15 70,18 87,56% 00:08.88 395,23 0:00.06 10,57 zstd -c -T0 -21 - linux 80,15 70,18 87,56% 00:08.91 395,28 0:00.05 10,71 xz -c -z - linux-headers 103,85 17,02 16,39% 00:42.24 95,35 0:01.45 10,15 zstd -c -T0 -18 - linux-headers 103,85 18,92 18,22% 00:12.68 320,98 0:00.16 10,74 zstd -c -T0 -19 - linux-headers 103,85 18,88 18,18% 00:16.36 448,98 0:00.17 10,63 zstd -c -T0 -20 - linux-headers 103,85 18,88 18,18% 00:16.26 448,99 0:00.16 10,77 zstd -c -T0 -21 - linux-headers 103,85 18,88 18,18% 00:16.39 448,97 0:00.16 10,72 xz -c -z - tensorflow 303,10 55,58 18,34% 01:59.56 95,40 0:04.78 10,27 zstd -c -T0 -18 - tensorflow 303,10 61,83 20,40% 00:15.99 856,98 0:00.47 10,64 zstd -c -T0 -19 - tensorflow 303,10 61,49 20,29% 00:21.01 1176,74 0:00.50 10,68 zstd -c -T0 -20 - tensorflow 303,10 61,49 20,29% 00:21.11 1176,88 0:00.49 10,64 zstd -c -T0 -21 - tensorflow 303,10 61,49 20,29% 00:21.16 1176,89 0:00.50 10,67 This seems to conclude that the ideal zstd level would be `-18`, as anything higher than that has a steep incline in memory usage during compression for negligible gains. We're, however, looking at a minimal increase in package size most of the time. I would consider that a minimal increase only, and a tradeoff we can make - given the incredibly fast decompression. So, TL;DR, the benefits of `zstd -c -T0 -18 -` over `xz -c -z -` are: - Massive speed gain in compression - Massive speed gain in decompression - Stable, reproducible multithreading The speed gain in decompression substantially increases pacman's package installation speed. While the trade-offs would be: - Minimal increase in compressed package size - Increase in memory usage during compression The required changeset is, i think: PKGEXT='.pkg.tar.zst' COMPRESSZST=(zstd -c -T0 -18 -) This change requires a new pacman release, as as of writing this, zstd support is in master but hasn't landed in a release yet. Judging by recent IRC chats in -tu and -devops, I think that many TUs and Devs already think this is a good move. This mail is a general proposal to gather opinions on this change and hopefully clear up any misunderstandings or questions regarding this change, before the actual patch is sent. Regards, Rob (coderobe)

14 34

[arch-dev-public] Python 2 modules
by Allan McRae 17 Dec '19

17 Dec '19

Hi all, Python 2 reaches End of Life on 2020-01-01. We currently have >950 python2 modules in the repos. A lot of these are not used by any other package in the repositories. I think we should work towards removing them. Leaving only python2 modules that are really required by other software, highlights what needs worked on to port to python3. Note Fedora is doing a similar removal for F30: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal What are opinions on this? Should I make a TODO list? Below is a list of python2 modules that are a dependency for any other package. I did not check makedepends and I did not check recursively to build this list. python2-acme python2-antlr2 python2-anyjson python2-anytree python2-apache-libcloud python2-apispec python2-argcomplete python2-argon2_cffi python2-argparse python2-args python2-arrow python2-aspectlib python2-astor python2-atspi python2-aubio python2-audit python2-augeas python2-autobahn python2-autopep8 python2-backports.lzma python2-basemap python2-betamax-matchers python2-betamax-serializers python2-binary-memcached python2-biopython python2-bitvector python2-blist python2-blosc python2-bluepy python2-bottle python2-bottleneck python2-braintree python2-breathe python2-bsddb python2-btchip python2-btrees python2-cached-property python2-caja python2-cchardet python2-celery python2-chai python2-chameleon python2-characteristic python2-cjkwrap python2-click-log python2-click-threading python2-cloudflare python2-cmarkgfm python2-colander python2-colorclass python2-configargparse python2-construct python2-couchdb python2-cram python2-crayons python2-cryptography-vectors python2-cson python2-cssselect2 python2-cssutils python2-cx_freeze python2-d2to1 python2-daemon python2-daemonize python2-datrie python2-ddt python2-digitalocean python2-discid python2-distutils-extra python2-django python2-dnslib python2-dockerpty python2-docopt python2-docs python2-doublex-expects python2-dpcontracts python2-dropbox python2-editdistance python2-egenix-mx-base python2-elasticsearch-curator python2-email-validator python2-envisage python2-eric python2-ethtool python2-evdev python2-exam python2-exiv2 python2-eyed3 python2-factory-boy python2-fastpbkdf2 python2-faulthandler python2-flake8-blind-except python2-flake8-debugger python2-flaky python2-flask-gravatar python2-flask-htmlmin python2-flask-jwt python2-flask-mail python2-flask-migrate python2-flask-paranoid python2-flask-restful python2-flask-security python2-flask-socketio python2-flask-talisman python2-flask-wtf python2-flexmock python2-flickrapi python2-flup python2-fonttools python2-foolscap python2-fpconst python2-freezegun python2-fs python2-funcy python2-furl python2-fxa python2-gasp python2-gcp-devrel-py-tools python2-gdal python2-gdata python2-genshi python2-genty python2-geoip python2-gevent-websocket python2-gflags python2-gitpython python2-gnupg python2-gnupginterface python2-gnuplot python2-gpgme python2-grequests python2-gtkspellcheck python2-gudev python2-h2 python2-h5py python2-h5py-openmpi python2-hacking python2-harparser python2-helper python2-hexdump python2-hglib python2-httpretty python2-hunter python2-hypothesis python2-i3-py python2-ibm-db-sa python2-icalendar python2-igraph python2-importlib_resources python2-inet_diag python2-invoke python2-iocapture python2-ipdb python2-irc python2-isomd5sum python2-iwlib python2-jieba python2-js2py python2-jsbeautifier python2-json-logger python2-jsonrpclib-pelix python2-kaitaistruct python2-kajiki python2-kaptan python2-keybinder2 python2-keyrings-alt python2-keyutils python2-kitchen python2-kivy python2-klein python2-langdetect python2-language-server python2-lark-parser python2-levenshtein python2-libappindicator python2-libarchive-c python2-libforensic1394 python2-librabbitmq python2-libtmux python2-linux-procfs python2-llfuse python2-logbook python2-logilab-common python2-lttngust python2-m2r python2-magic python2-mamba python2-manhole python2-manuel python2-marisa python2-marshmallow python2-memcached python2-mimerender python2-mockito python2-mongoengine python2-mongomock python2-mpd2 python2-munkres python2-musicbrainz2 python2-mygpoclient python2-mysql-connector python2-nbxmpp python2-ndg-httpsclient python2-neovim python2-netcdf4 python2-netcdf4-openmpi python2-nine python2-nltk python2-nose2 python2-nose-cover3 python2-nose-exclude python2-nose-fixes python2-nose-randomly python2-nose-show-skipped python2-nosexcover python2-oauth2client python2-objgraph python2-olefile python2-openapi-spec-validator python2-openpyxl python2-openstackclient python2-oslo-concurrency python2-oslo-log python2-oslosphinx python2-oslotest python2-ovirt-engine-sdk python2-owslib python2-pacparser python2-pam python2-pandas-datareader python2-pandocfilters python2-parse python2-parsedatetime python2-parsel python2-paste python2-pastedeploy python2-pbkdf2 python2-pdoc python2-peewee python2-perf python2-periphery python2-phonenumbers python2-piexif python2-pifpaf python2-pigar python2-pint python2-pipenv python2-pkgconfig python2-planout python2-plop python2-pmw python2-podcastparser python2-polib python2-poppler python2-positional python2-poster python2-prance python2-prctl python2-pretend python2-priority python2-process-tests python2-profilestats python2-progressbar python2-prometheus_client python2-psycopg2 python2-ptrace python2-pudb python2-pyaes python2-pyalsa python2-pyamf python2-pyaml python2-pyaudio python2-pybluez python2-pychm python2-pycontracts python2-pycosat python2-pycountry python2-pycuda python2-pydbus python2-pydns python2-pydocstyle python2-pydot python2-pyelftools python2-pyftpdlib python2-pygal python2-pygeoip python2-pygit2 python2-pygithub python2-pyglet python2-pygpgme python2-pygraphviz python2-pyicu python2-pyliblo python2-pylibmc python2-pylons-sphinx-themes python2-pymediainfo python2-pynamecheap python2-pynormaliz python2-pyodbc python2-pyopencl python2-pyotp python2-pyqtwebengine python2-pyquery python2-pyro python2-pyrss2gen python2-pyrtf python2-pysaml2 python2-pysendfile python2-pyserial python2-pysimplesoap python2-pysmbc python2-pysnmp python2-pysrt python2-pystemmer python2-pyswip python2-pytables python2-pytddmon python2-pytest-benchmark python2-pytest-cov python2-pytest-django python2-pytest-expect python2-pytest-flake8 python2-pytest-httpbin python2-pytest-isort python2-pytest-localserver python2-pytest-mock python2-pytest-randomly python2-pytest-relaxed python2-pytest-rerunfailures python2-pytest-runner python2-pytest-sugar python2-pytest-timeout python2-pytest-twisted python2-pytest-virtualenv python2-pytest-xdist python2-pytest-xprocess python2-pythondialog python2-pyudev python2-pyusb python2-pywinrm python2-pyxrootd python2-qiniu python2-qpid-proton python2-qrcode python2-qrencode python2-queuelib python2-rangehttpserver python2-rawkit python2-rdflib python2-recommonmark python2-redis python2-rednose python2-repoze.profile python2-requests-credssp python2-requests-file python2-requests-ftp python2-requests-hawk python2-requests-kerberos python2-requests-mock python2-requests-ntlm python2-responses python2-restkit python2-rethinkdb python2-ropper python2-rply python2-rst2pdf python2-salsa20 python2-scapy python2-schedutils python2-scikit-learn python2-scour python2-scripttest python2-scrypt python2-seaborn python2-selenium python2-semantic-version python2-send2trash python2-serpent python2-service_identity python2-setuptools-git python2-setuptools-markdown python2-setuptools-scm python2-shapely python2-signedjson python2-simplebayes python2-snakefood python2-soappy python2-socketio python2-sortedcontainers python2-sparqlwrapper python2-sphinxcontrib-bibtex python2-sphinxcontrib-newsfeed python2-sphinx-testing python2-split python2-sshtunnel python2-statsmodels python2-stopit python2-structlog python2-subunit2sql python2-suds python2-sure python2-swiftclient python2-sword python2-sybil python2-tabulate python2-tagpy python2-tarantool python2-tblib python2-tenacity python2-terminado python2-terminaltables python2-testfixtures python2-testrepository python2-testresources python2-texttable python2-tftpy python2-tlsh python2-toposort python2-tox python2-traitsui python2-transaction python2-treq python2-trustme python2-tweepy python2-twine python2-typogrify python2-ukpostcodeparser python2-uncertainties python2-unicorn python2-unittest-mixins python2-unittest-xml-reporting python2-urwidtrees python2-vcrpy python2-vcversioner python2-venusian python2-vobject python2-webcolors python2-webpy python2-whatever python2-whelk python2-whitenoise python2-wikipedia python2-wsaccel python2-wsgi-intercept python2-wsgiproxy2 python2-wsproto python2-xapp python2-xlrd python2-xlsxwriter python2-xlwt python2-xpybutil python2-yapf python2-yara python2-z3 python2-zbar python2-zconfig python2-zope-annotation python2-zope-configuration python2-zope-copy python2-zope-security python2-zope-testing python2-zope.testing python2-zope-testrunner

5 6

[arch-dev-public] Missing bugtracker assignment emails
by Morten Linderud 16 Dec '19

16 Dec '19

Yo! Andreas Radke has done an impressive amount of bug assignments the past week. But it looks like the assignment emails themselves are not sent correctly and you might not have noticed this. Please look over your bug assignments on the tracker in case you haven't taken a look in a while :) Happy holidays! -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

[arch-dev-public] Proposal: Build a ruleset for new packages and package quality
by Christian Rebischke 12 Dec '19

12 Dec '19

Hello everybody, Due to a longer discussion around alpha and beta packages in our repositories in IRC yesterday, I would like to start a hopefully more constructive discussion around this topic on the ML. Short summary for everybody what happened: I wanted to get caddy2.0.0-beta into [community], people started discussing that we don't ship betas in our repositories and I should either wait or ship the stable caddy v1 release. I don't want to start this discussion around caddy again (I will wait for a stable release). What I want to accomplish with this mail is: 1. find a consensus on rules which packages we allow in our repositories and which don't. 2. find a consensus on rules on violating our rules regarding package requirements. (e.g. What happens when TU/Dev XY violates our package requirements? what is the punishment?) 3. revive the discussion around better PKGBUILD quality (see also Eli's thread about PKGBUILD quality on arch-tu: https://lists.archlinux.org/private/arch-tu/2019-November/000083.html) 4. I would like to have this rules written down somewhere, either in the TU bylaws (in dev bylaws if this exists) or in a new format like "community bylaws" (maybe we could combine this with the question about a new leader). 5. What do we do with the existing beta and alpha packages? Are they granted asylum? Or do we remove them, to be consistent? extra libmspack 1:0.10.1alpha-2 extra qt5-webkit 5.212.0alpha3-6 community d-containers 0.8.0alpha.19-1 extra frozen-bubble 2.2.1beta1-14 extra hddtemp 0.3.beta15.53-1 extra libcaca 0.99.beta19-2 extra tsocks 1.8beta5-8 community hydrogen 1.0.0beta1-1 community lablgtk3 3.0.beta6-2 community modclean 3.0.0beta.1-1 community sdedit 4.2beta8-1 community sniffit 0.3.7.beta-17 community vbindiff 3.0_beta5-1 community wqy-microhei 0.2.0_beta-9 community wqy-microhei-lite 0.2.0_beta-9 6. How do we define stable packages? beta or alpha is just a human made word. I've seen devs who said their "1.0" version is unstable and shouldn't be used in production. Should such a software get packaged? And what about projects who use semantic versioning (the devs said so), but they have a 0.* prefix release? 7. Another topic is a rule about "touching packages of others". In the #archlinux-tu channel we came to the conclusion that TUs or devs should ask the package maintainer before touching another devs/TUs package, how do we want to handle this? Is this the consensus, or are touches without prior question allowed? What do we do if somebody violates our rules? etc 8. A few guys in the IRC pointed me to this guidelines in our wiki: Note: This page is only editable with Wiki-Admin/Dev Permission. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versio… My questions to this guidelines: 8.1. under which consensus where this rules defined? Are these rules the result of a developer vote? of a leader decision? Or are they made up by a few persons without consensus. 8.2 I can't find any list about punishments for violations of these rules. 8.3 There is no documentation about our alpha and beta packages. I see that there are exceptions for alpha and betas, but it's not clear for me how these exceptions apply to the packages we have in our repositories. This needs to be documented, otherwise every person could push an alpha package and just 'claim' that one of those exceptions apply for the package and if nobody checks this claim, the package will be in the repository. 9. Do we consider packages, that are build from the latest git tag, as alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' 10. Do we need to ask software developers in the future if they consider their project stable? It's not clear which versioning schema the devs use, some consider their 0.1 release as unstable, some consider it as stable. Is semantic versioning applied? Do they follow a different schema? 11. What do we do when a package is stable, but the API is unstable? Is the whole package considered unstable? The current guidelines are not clear about APIs, but many users use Arch Linux for software development and maybe rely on stable APIs. Disclaimer: I don't know how we want to find concensus yet (TUs have a transparent vote process, but devs don't have an equivalent for this), therefore I hope for a "final decision" of our still-leader aaron. This topic doesn't need to be decided this year. I am fine with reviving this thread in January or late replies in January. Best regards, Chris

6 6

[arch-dev-public] Qt 5.14 in [testing]
by Antonio Rojas 12 Dec '19

12 Dec '19

The usual reminder that, due to Qt's ABI versioning, everything built against 5.14 will have to wait in [testing] until Qt itself moves.

1 0

[arch-dev-public] Orphaning crypto++
by Baptiste Jonglez 11 Dec '19

11 Dec '19

Hi, I plan to orphan crypto++ [1] soon: I don't maintain any package that depends on it anymore, and it's becoming annoying to maintain. For instance, there was a significant security issue on July 2019 [2], and 5 months later there is still no upstream release even though a patch is available [3]. I just patched the Arch package but it raises the question of whether we want to have such a crypto library in our repositories. Here are the packages that currently depend on crypto++: - amule - clementine - kvazaar - rbutil - ceph (makedepends) If nobody steps up to adopt it before December 20th, I will drop it to the AUR. In that case, I will send a reminder to find a solution for the above packages. Thanks, Baptiste [1] https://www.archlinux.org/packages/community/x86_64/crypto++/ [2] https://security.archlinux.org/CVE-2019-14318 [3] https://github.com/weidai11/cryptopp/issues/869

2 2

[arch-dev-public] Orphaning dkim-proxy
by Archange 03 Dec '19

03 Dec '19

Hi, I’ve orphaned dkim-proxy since I no longer use it (opensmtpd added support for filters recently, and they are the new recommended way of doing DKIM signing/verification, deprecating the use of dkim-proxy). If someone want to adopt it please let me know, else I’ll just drop it to the AUR in ~1 week. Regards, Bruno/Archange

1 0

[arch-dev-public] Flyspray migration to a VPS
by Giancarlo Razzolini 01 Dec '19

01 Dec '19

Hi All, If everything goes well, I'll be moving flyspray (bugs.archlinux.org) to a VPS later today. In fact, the VPS already has a copy of our flyspray instance, I'll just make a final dump and take a last copy of the attachments and make the move. So, expect it to be unavailable for some time later today. I expect to start working on this at around 16-17 UTC and the downtime should be around one hour, plus the time it takes for the DNS changes to propagate. Regards, Giancarlo Razzolini

1 1

[arch-dev-public] Dropping OpenVAS/GVM
by Christian Rebischke 28 Nov '19

28 Nov '19

Hi, I plan to drop the vulnerability management tool "openvas" (Greenbone Vulnerability Manager). I stopped using the software and it gets more and more tedious (due to breaking changes and bad testing at upstream). Moreover I really think that there are better solutions right now (for example cloudflare/flan) Anyone interested in adopting it? Best regards, chris

1 0

[arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
by Allan McRae 20 Nov '19

20 Nov '19

Hi all, As you may know, we have had people busy looking at what it takes to make our packages reproducible. There has been a lot of progress there lately. Our reproducible builds team (along with the wider reproducible builds community) has been building our packages in different environments to test how stable the builds are [1]. The good news is that >80% of our packages could be built twice in varying environments and give the exact same result. However, that is only part of the picture. Ideally, we want people to be able to take one of our packages and rebuild it exactly. With the release of pacman-5.2, packages record a lot more information about their build environment. That means we can reconstruct a package's build chroot, and then rebuild it. There are two tools in the works to do this. One by Morton (Foxboron) [2] and one by Eli [3]. Note that both tools need more testing to be ready for a wider release and currently require some manual editing to run. The good news is, we have at least 10 packages that can be precisely reproduced using both these tools [4]! This means you can take one of these tools and rebuild a package from the repos, and get the exact same package out of it. This is an amazing effort - well done to the team! To keep this momentum going, it would be great to rebuild every package in [core] using makepkg from pacman-5.2+. That way we can test which packages are actually reproducible and work towards fixing those that are not. So be prepared for almost the entire repo to hit [testing] soon, and get your sign-off shoes on! Again, a huge congrats to our reproducible builds team. This has been a massive amount of work! Allan [1] https://tests.reproducible-builds.org/archlinux/archlinux.html [2] https://github.com/archlinux/archlinux-repro [3] https://github.com/eli-schwartz/devtools/blob/reproducible/makerepropkg.in [4] https://wiki.archlinux.org/index.php/DeveloperWiki:ReproduciblePackages

6 7

Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org
by Sven-Hendrik Haase 18 Nov '19

18 Nov '19

On Mon, 18 Nov 2019 at 09:00, Konstantin Gizdov <arch(a)kge.pw> wrote: > Sounds good. One question - where do we move our email aliases? > Not quite sure what you mean. All email is still being handled by apollo unless I'm mistaken and soyuz had more duties than I thought. In the latter case, we should migrate that to apollo. Could anyone shed some light on this?

2 1

[arch-dev-public] New kernel packages and mkinitcpio hooks
by Giancarlo Razzolini 12 Nov '19

12 Nov '19

Hi All, As most of you have noticed already, the kernel packages had some recent changes where they do not install the kernel to /boot, as well as they do not have any kmod [0] nor mkinitcpio hooks anymore. Neither they do install mkinitcpio presets [1]. 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] Kernels and presets are not installed and generated by mkinitcpio alpm hooks and scripts. All kernels that have a pkgbase entry file [3] will be processed by these scripts. We have changed all our officials kernels. Also, kernel removals are handled by mkinitcpio as well. We want to make the boot process more flexible, while also keeping it backwards compatible by default. There are a few changes I have planned for the next mkinitcpio release [4] that will help even further to achieve this. I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and also create a simple configuration file for each kernel. Right now dracut does not conflict with mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side note, I have been using it for the past 8 months without any issues. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kmo… [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lin… [2] https://github.com/archlinux/mkinitcpio/pull/7 [3] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lin… [4] https://github.com/archlinux/mkinitcpio/issues

3 6

Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
by Giancarlo Razzolini 11 Nov '19

11 Nov '19

Em novembro 11, 2019 16:18 Gaël PORTAY escreveu: > Hi Giancarlo, > > On Sun, Nov 10, 2019 at 06:41:38PM -0300, Giancarlo Razzolini via arch-dev-public wrote: >> >> I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and >> also create a simple configuration file for each kernel. Right now dracut does not conflict with >> mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm >> writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might >> eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side >> note, I have been using it for the past 8 months without any issues. > > Do you have commited your hooks somewhere? I would like to have a look > to them and probably to test them. > They should land on the dracut package itself sometime this week, or start of the next week. I might commit them to svn before that, so probably keep an eye on the dracut package git repository, but I make no promises. There will probably be some default dracut configuration as well. And each kernel might end up having two dracut.d configuration files, one for each image (regular and fallback), created from a preset, in a similar way mkinitcpio does it now. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] Adding package (lib32-)-amdvlk in extra (and testing)
by Laurent Carlier 10 Nov '19

10 Nov '19

I would like to add these packages in the official repositories. It's a good alternative to vulkan-radeon packages, well maintained upstream and offer a good compromise with new gfx card released.

2 1

[arch-dev-public] Python 3.8 rebuilds
by Evangelos Foutras 31 Oct '19

31 Oct '19

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. Please avoid adding new Python packages and starting other rebuilds during this time.

1 1

[arch-dev-public] xf86-input-keyboard dropped
by Andreas Radke 30 Oct '19

30 Oct '19

This Xorg input driver package shouldn't be used under Linux systems anymore. It has been removed from our repos. Use either xf86-input-libinput or xf86-input-evdev driver package. https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/merge_reques… -Andy

1 0

[arch-dev-public] Using SPDX License list as identifiers
by Jerome Leclanche 28 Oct '19

28 Oct '19

Hi This just came up on IRC. Thoughts on using the SPDX license list as valid license identifiers for all packages? https://spdx.org/licenses/ Most of the identifiers would change but we would have a consistent and much larger, externally-maintained list to choose from. It would also be a little more accurate; eg. the SPDX allows for distinctions such as "LGPL-3.0-or-later" vs. "LGPL-3.0-only". We could retain the current identifiers as symlinks. J. Leclanche

5 6

[arch-dev-public] Information about the base meta-package
by Levente Polyak 15 Oct '19

15 Oct '19

Q: Why has this been implemented so suddenly? A: That's a good question, while we have discussed this topic multiple times in the past and also issued a concrete proposal to arch-dev- public (plus its follow-up summary) no further steps were taken to get something testable. However, during arch-conf in Berlin, the general enthusiasm and acceleration of the group was so strong, that we have warp-10 driven this task. We acknowledge that this could have been handled more carefully, but in the spirit of arch-conf please excuse us and bear with us. For instance, we could have noticed during a test phase the consequences of not having systemd- sysvcompat. For the time being, we have added it to the base package as the implications were not explicitly desired and discussed beforehand, however that topic will be covered in a follow-up. Q: Why has the group been superseded by a meta-package? A: The difference with the new base package is that this defines the level at which we tell you, you have modified your system sufficiently that you break it, you bought it -- it is your responsibility to debug issues caused by your overriding basic assumptions of the system. This has theoretically already been the case before this change as packages in the old `base` group were expected to be installed by a lot of packages. On the other hand, it has never explicitly been stated that this indeed is a requirement. The consequence is that packages may potentially misbehave or fail to properly install. Following this reasoning, it's a very natural choice to use a meta- package. It allows us to reflect changes (additions or removals) in the required package set straight on user installs with the next system upgrade which allows preserving the consistency of those assumptions. A simple example would be the systemd package, no matter what use-case you have (like a tiny container) we assume you must have systemd installed as its being relied on (sysusers, tmpdirs, etc.). Q: Why has it been shrunk down and doesn't contain $package anymore? A: The base meta-package is meant to be the lowest common denominator across different use-cases like desktop usage, bare-metal server or container runtime and therefore defines the foundation people can build their desired environment upon. The old base group did not just contain too many unnecessary packages for us to reasonably be able to call it the lowest common denominator, it was also inconsistent (for example it shipped reiserfsprogs but not btrfs-progs). After reflecting on all of the feedback so far, it also became quite clear that the old base group was kind of misused as a poor man's installer. There is nothing wrong with such a use case per se, but if there is a desire to solve this on our side, we should find the optimal solution instead of just sticking to some legacy. Be it an actual installer, something like a base-extras group, or nothing at all, it is out of scope here, but we should look into it separately -- so maybe its a bit of xkcd#1172. Q: Why couldn't we just add a new package and leave the base group as it was? A: The primary reason is that base (as the name indicates) shall be the minimal foundation and denominator of different use-cases. If we would introduce anything other than 'base' to fulfill this job, like base-system, base-minimal, base-foundation, or whatever one could come up with, it wouldn't get the point across as clearly as the name 'base' itself. The historic knowledge is mostly responsible for our bias here, but it is clearly easier to grasp the intention compared to the difference between having `base` and `base-minimal`. Q: Should we update the dependencies of our packages to depend on base instead of on its members? A: Nothing has changed in that regard and there is no strict rule for do or don't yet. This is in general more related to the topic of transitive dependencies which needs to be discussed eventually. My recommendation is to just keep the members that are a first-level dependency because there is absolutely no point in making every single package in the universe depend on the base meta-package. However, it can be correct, clean and useful to list your first-level dependencies explicitly instead of not at all. Q: What happens next, are there any plans? A: The most important part was getting this abstract out to provide information and aid in resolving some of the confusion. The next steps will include multiple follow-up topics to iterate over and decide case by case -- for example how we want to handle systemd- sysvcompat and other topics that emerged. cheers

2 1

Re: [arch-dev-public] Packages added to todo list 'protobuf 3.9 rebuild'
by Lukas Fleischer 06 Oct '19

06 Oct '19

On Thu, 03 Oct 2019 at 12:27:45, Arch Website Notification wrote: > Todo list information: > Name: protobuf 3.9 rebuild > URL: https://www.archlinux.org/todo/protobuf-39-rebuild/ > Creator: Lukas Fleischer > Description: > Please rebuild affected packages and move them to > [staging]/[community-staging]. Since there's some overlap with the boost rebuild, we should probably wait until boost leaves [staging]. I temporarily removed protobuf from [staging] just to be safe.

1 2

[arch-dev-public] Retiring as a Trusted User
by Florian Pritz 02 Oct '19

02 Oct '19

Hi, I no longer have the time necessary to properly handle actual TU duties so I am retiring my TU hat. I will still continue maintaining some packages I have in [community] via my developer hat. That said, I'd like to orphan some of them too. If anyone is interested in taking over one of these packages (and its dependencies), please feel free to adopt it and tell me so that I can orphan it. asciidoc filezilla libfilezilla gcolor2 gmrun obconf openbox openshot libopenshot libopenshot-audio pydf slock tipp10 vimpager xplc zim Florian

6 6

[arch-dev-public] Dropping packages to AUR
by Alad Wenter 27 Sep '19

27 Sep '19

Hi, As I no longer use them, I will drop the following packages to AUR unless someone is interested in picking them up: * hashdeep * libclastfm * pragha * python-i3-py * python-pygraphviz * usbview * youtube-viewer The following packages are dependencies of existing packages, and could equally use a new maintainer: * glyr (optional dependency for abcde) If you are interested in any of the above packages, please let me know in a reasonable time period (say, two weeks.) Cheers, Alad

3 3

[arch-dev-public] A contrib repository
by Morten Linderud 12 Sep '19

12 Sep '19

There is a *lot* of small tools people have written over the years that resides in bin/ directories which could be useful for more people. We also have several such tools on soyuz, where sogrep was added to devtools this week. I have been thinking it could be great to have a simple `contrib` repository where every team member has commit access. This could work as a staging area for tools we would like to promote to `devtools` later on. We could maybe sort this into directories for its purpose: * packaging * security * devops * testing * bugwrangler * misc Tools that can be added here is the `ch` scripts from Bluewind, and the pkg-* tools eli has created. I also have some tools to look for pkgname in archweb, check them out from svn and check them against a nvchecker file. This would hopefully give us a space where we can experiment with new maintainer tools in a collaborative manner. I'd love to hear some feedback or thoughs on this! -- Morten Linderud PGP: 9C02FF419FECBE16

8 14

[arch-dev-public] new archweb release
by Jelle van der Waa 11 Sep '19

11 Sep '19

Hi all, A new archweb release has been deployed on our server, with a couple of notable changes: - Signoff status has been moved up in the Developer Dashboard for more attention - 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. In the future release, I aim to improve onboarding of testers and further investigate where the lack of signoffs comes from. So far it seems we have around ~ 18 "active" testers.

3 2

[arch-dev-public] Semi-away till 2019
by Bartłomiej Piotrowski 06 Sep '19

06 Sep '19

Hi all, As I have free time shortage lately, I think it's fair to officially say I will be in semi-away mode till 2019. I will try my best to keep up with uncomplicated pkgver bumps for packages I maintain on my own and make sure all keys are properly signed, but that's all I can promise. It also means I'm unable to give toolchain attention it deserves. Please poke me somewhere if you happen to be interested in co-maintaining it. My responses on IRC or via e-mail may be also delayed so take that into account before kicking me out. Bartłomiej

4 4

[arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
by Eli Schwartz 04 Sep '19

04 Sep '19

QtWebEngine supports spellchecking: https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker However, they have helpfully decided (steered by upstream chromium) to *not* use hunspell dictionaries, and instead to use... hunspell dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as ".bdic" files, because this is supposedly "more efficiently read by chromium". (Actually QtWebEngine's spell-checking infrastructure is entirely willing to read dictionaries in /usr/bin/qtwebengine_dictionaries before looking in /usr/share because clearly they've put great thought into how this is all supposed to work on a conceptual design level especially for distro packaging.) So I have a program -- pageedit -- which just added spellchecking support via qtwebengine in the latest release, and I would like to support that. And I don't want to see people being personally responsible for installing their own stuff in /usr/share. While I'm at it, Morten (Foxboron) pointed out to me that qutebrowser also supports spellchecking, and it currently provides a user script which downloads preconverted dictionaries from chromium's git repository into $HOME/.local/share/qutebrowser/ ... because there's apparently no guidance or precedent for actually distributing these dictionaries. (In fact, currently only Fedora seems to make these dictionaries available to users.) It's possible to convert them yourself, using the qwebengine_convert_dict tool shipped in the qt5-webengine package. I think it would be nice if users were able to obtain these dictionaries properly, but I'm not positive what the best way would be. Ideas: - Ship a pacman hook to convert whatever the user has installed, implemented via the following libalpm script and hooks: https://paste.xinu.at/m-ydTjU/ - make every hunspell-* package makedepend on qt5-webengine and produce those dictionaries - same thing but also make split packages for basically a tiny data file - force users to install an out of date AUR package not kept in sync with hunspell-* (this one is just a joke) The advantage of a hook is that users with webengine installed automatically get magic google-approved dictionaries corresponding to the hunspell dictionaries they have installed. The advantage of modifying each hunspell-* package is saving about 0.38 seconds per file at installation time, plus users don't have weird untracked files in some cloistered dir in /usr/ The advantage of doing anything other than possibility #3 is "avoid adding another 34 packages to the repositories, which users need to manually install in addition to the other dictionaries they explicitly installed". ... Prior art: Fedora uses rpm post-install filetriggers: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qt5-qtwebe… Gentoo has a proposal for a package that runs the conversion tool on each file the user has installed in /usr/share/hunspell/ and packages the results. ... Thoughts on the best way forward to make these dictionaries available on Arch Linux? -- Eli Schwartz Bug Wrangler and Trusted User

5 8

[arch-dev-public] deepin-kwin removed from [community-testing]
by Felix Yan 03 Sep '19

03 Sep '19

There are multiple major issues with the new version 5.0.0, and upstream doesn't yet have figured them out after a month. Currently it would be better to stick with 0.1.0. -- Regards, Felix Yan

1 0

[arch-dev-public] Wiki Update in progress
by Pierre Schmitz 01 Sep '19

01 Sep '19

Hi there, I triggered a Wiki update. Unfortunately the update script is running longer than expected. So pages appear to be empty. Greetings, Pierre

2 4

[arch-dev-public] Speaking of OCaml: willing to orphan merlin + deps
by Bruno Pagani 20 Aug '19

20 Aug '19

Hi there, I’m riding on the train of OCaml e-mails to announce that I’m going to orphan merlin (OCaml smart auto-completion for emacs/vim) and its dependency tree as I’m no longer using any of those and don’t expect to use them again: – cppo – dune – menhir – merlin – ocaml-biniou – ocaml-easy-format – ocaml-yojson Note that merlin was recently upgraded to 3.3.2 by Jürgen (thanks for that), but rather than using Opam the new dependency should be added to the repo if someone is willing to maintain this stack. I had started with menhir, but some other were required IIRC. Please let me know if you are interested, adopt them and I’ll disown right after. Else, I’ll drop all of them to the AUR in ~1 week. Regards, Bruno/Archange

2 2

[arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
by Jürgen Hötzel 16 Aug '19

16 Aug '19

Hi, Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. But some well known packages depend on this preprocessor. E.g. :Haxe, lablgtk2 (therefore also: Unison and Coq). I don't see that these projects will be migrated to camlp5 or ppx in the near future. Therefore there are only 2 options from my point of view: 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. 2. removal of Haxe, lablgtk2, Unison and Coq. I prefer 1. What do you think? Same issue discussed on Debian Bug Tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722

3 3

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
by Eli Schwartz 13 Aug '19

13 Aug '19

On August 13, 2019 5:17:27 AM EDT, Florian Bruhin <me(a)the-compiler.org> wrote: > Hey, > > My $0.02 as qutebrowser maintainer (off-list because I can't send to > arch-dev-public): Forwarded back to a-d-p with inline comments. :) > On Mon, Aug 12, 2019 at 07:50:44PM -0400, Eli Schwartz via > arch-dev-public wrote: > > QtWebEngine supports spellchecking: > > https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker > > > > However, they have helpfully decided (steered by upstream chromium) > to > > *not* use hunspell dictionaries, and instead to use... hunspell > > dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as > > ".bdic" files, because this is supposedly "more efficiently read by > > chromium". > > The actual spell checking is implemented inside Chromium, all > QtWebEngine does > with the dictionaries is passing them to Chromium. I don't think > they're happy > with bdic files either, but the alternatives aren't really an option > (completely reimplementing spell checking support by patching their > copy of > Chromium, with a lot of added friction each time they want to update > their > Chromium snapshot). > > So it pretty much boils down to "blame Google/Chromium" ;) Yeah, but I still wanna blame them for npt patching it for the purpose of integrating well. :p > > (Actually QtWebEngine's spell-checking infrastructure is entirely > > willing to read dictionaries in /usr/bin/qtwebengine_dictionaries > before > > looking in /usr/share because clearly they've put great thought into > how > > this is all supposed to work on a conceptual design level especially > for > > distro packaging.) > > Agreed this doesn't make much sense for Linux distributions. It > happens because > it looks next to the executable, which probably *does* make a lot of > sense for > Windows, macOS, embedded scenarios, bundled apps, etc. It doesn't help > much for > distributions, but it also doesn't hurt. > > > So I have a program -- pageedit -- which just added spellchecking > > support via qtwebengine in the latest release, and I would like to > > support that. And I don't want to see people being personally > > responsible for installing their own stuff in /usr/share. While I'm > at > > it, Morten (Foxboron) pointed out to me that qutebrowser also > supports > > spellchecking, and it currently provides a user script which > downloads > > preconverted dictionaries from chromium's git repository into > > $HOME/.local/share/qutebrowser/ ... because there's apparently no > > guidance or precedent for actually distributing these dictionaries. > (In > > fact, currently only Fedora seems to make these dictionaries > available > > to users.) > > Oh, I didn't know Fedora packages them! I opened a qutebrowser issue > too: > https://github.com/qutebrowser/qutebrowser/issues/4966 > > > It's possible to convert them yourself, using the > > qwebengine_convert_dict tool shipped in the qt5-webengine package. I > > think it would be nice if users were able to obtain these > dictionaries > > properly, but I'm not positive what the best way would be. Ideas: > > > > - Ship a pacman hook to convert whatever the user has installed, > > implemented via the following libalpm script and hooks: > > https://paste.xinu.at/m-ydTjU/ > > - make every hunspell-* package makedepend on qt5-webengine and > produce > > those dictionaries > > - same thing but also make split packages for basically a tiny data > file > > - force users to install an out of date AUR package not kept in sync > > with hunspell-* (this one is just a joke) > > > > The advantage of a hook is that users with webengine installed > > automatically get magic google-approved dictionaries corresponding > to > > the hunspell dictionaries they have installed. > > > > The advantage of modifying each hunspell-* package is saving about > 0.38 > > seconds per file at installation time, plus users don't have weird > > untracked files in some cloistered dir in /usr/ > > > > The advantage of doing anything other than possibility #3 is "avoid > > adding another 34 packages to the repositories, which users need to > > manually install in addition to the other dictionaries they > explicitly > > installed". > > Depending on how big those dictionaries are, they all could be in a > single > qt5-webengine-dicts package? Though I guess they aren't much smaller > than the > hunspell ones, and there probably was a reason those were split. Well, they are different source code with different versions, so I see no gain or practical way to implement a combined hunspell package. A combined webengine dicts package would need to makedepend on all hunspell dict packages, then get updated for any hunspell dict update. > On Tue, Aug 13, 2019 at 09:22:39AM +0200, Jan Alexander Steffens via > arch-dev-public wrote: > > On Tue, Aug 13, 2019 at 9:04 AM Bartłomiej Piotrowski via > arch-dev-public < > > arch-dev-public(a)archlinux.org> wrote: > > > I'd go with updating all packages to ship the converted files. > > > Cluttering /usr with untracked files doesn't sound good. > > > > Yeah, I agree. I think we should package convert_dict from the > Chromium > > sources as a new package to makedepend on. > > I'm assuming those are compatible to each other? It does seem like it > from the > sources: > > https://github.com/qt/qtwebengine/blob/v5.13.0/src/tools/qwebengine_convert… > https://github.com/qt/qtwebengine-chromium/blob/75-based/chromium/chrome/to… > > > Assuming that WebEngine will not be the only consumer of .bdic > > dictionaries, how about putting them in /usr/share/bdic, and then > either > > patching sources to use that dir or linking whatever engine-specific > > dictionaries there? > > > > We could also put them with the other dictionaries into > > /usr/share/hunspell, assuming that won't cause problems. > > I guess Qt wouldn't be opposed to a change (for Qt 5.14 I guess) > adding one of > those paths. > > Maybe the Chromium package could load them as well from there? > > Florian I have no idea at all what chromium does do right now! -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
by Jürgen Hötzel 13 Aug '19

13 Aug '19

Hi, Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. But some well known packages depend on this preprocessor. E.g. :Haxe, lablgtk2 (therefore also: Unison and Coq). I don't see that these projects will be migrated to camlp5 or ppx in the near future. Therefore there are only 2 options from my point of view: 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. 2. removal of Haxe, lablgtk2, Unison and Coq. I prefer 1. What do you think? Same issue discussed on Debian Bug Tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722

2 2

[arch-dev-public] I will be away this week
by Filipe Laíns 08 Aug '19

08 Aug '19

Hi, I will be away this week. I understand some of you have questions specifically about the new discord packages. Feel free to take any action that you feel necessary, delete, modify, etc..., just document that (email, irc or etc). Thabk you, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

2 1

[arch-dev-public] New ideas for notifying users about (minor) changes
by Christian Rebischke 30 Jul '19

30 Jul '19

Hello everybody, I got assigned to this issue here: https://bugs.archlinux.org/task/62823 The users would like to have a notice in pre/post install/upgrade notifications via pacman .install files. I am not a fan of spamming such news via pacman and I think the installation/upgrade process should be clean of such messages, but I don't have access to the news tool on our website as well. So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. It would be super awesome if we would have a tool such like `archnews <packagename>` to retrieve NEWS about a certain package from an endpoint. This endpoint should be controllable by every maintainer (devs and TUs included). I discussed this with coderobe a bit and we came to different solutions: Solution 1: a NEWS file inside of the package repository: -------------------------------------------------------- A maintainer could upload a `NEWS` file into the package repository and then a client could grab this information directly via downloading the file from: https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=package… Pro: + every maintainer could control this NEWS file easily via our current tools. + It's easy to download the NEWS files (we can expect new tools from the community) Con: - We bloat our repository Solution 2: commit messages as NEWS ------------------------------------ The maintainer could/should put such news into the latest commit message. Pro: + no extra file + using existing infrastructure + one workflow Con: - I need an actual change in the repository to create a new NEWS object (If we have a look on my example with strongswan, I would need to add something in the PKGBUILD to make a new commit to make a new NEWS object) - It's more difficult to get with tools. The user needs to checkout the repository (in solution 1 it can be just a curl call) Solution 3: A webapp on news.archlinux.org with a fancy UI ----------------------------------------------------------- This solution would be the most work. We could have a new webapp (such like our security tracker) just for NEWS objects. Every maintainer should have access to their assigned packages. Pro: + Fancy + Easy to use + API endpoints Con: - A lot of work ------------------------------------------------------------- I would go for solution 1. What would be interesting to know for me: 1. Do you think that we actually *need* such a tool? 2. Would you use such a tool/workflow? 3. Do you have other/better ideas? I hope for an interesting constructive discussion. Best regards chris [1] https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet#Gentoo_Monthly_Newsletter_.…

6 10