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

News Draft: Incoming changes in JDK / JRE packages may require manual intervention
by Leonidas Spyropoulos 12 Oct '23

12 Oct '23

We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: if users have both JDK and JRE installed the can manually install the JDK with pacman -Sy jdk-openjdk and this remove the JRE related packages. if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don’t support modules. -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

Incoming changes in JDK /JRE packages
by Leonidas Spyropoulos 09 Oct '23

09 Oct '23

Hello, We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: - if users have both JDK and JRE installed the can manually install the JDK with `pacman -Sy jdk-openjdk` and this remove the JRE related packages. - if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. - If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don't support modules. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

RFC Final Comment Period: Add -Wl,-z,pack-relative-relocs
by Jan Alexander Steffens (heftig) 25 Sep '23

25 Sep '23

An RFC has now entered its 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/23 Please visit the above link for discussion. Summary: Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

2 1

News Draft: Default password hashing algorithm changed to yescrypt
by David Runge 20 Sep '23

20 Sep '23

Hi all, with shadow 4.14.0 I introduced some changes to default password hashing algorithms and would like to post the following on the website once the relevant packages (filesystem, pambase, shadow) move to [core]: ```markdown With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/) and [PAM](https://wiki.archlinux.org/title/PAM) honors the chosen `ENCRYPT_METHOD` in /etc/login.defs. While this should not require any direct user intervention, do note that since we now fully integrate with PAM the `YESCRYPT_COST_FACTOR` setting in `/etc/login.defs` is currently without effect, until [PAM implements reading its value](https://github.com/linux-pam/linux-pam/issues/607). If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is needed, it can be set using the `rounds` option of the [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in /etc/pam.d/system-auth). Furthermore, additional changes in the filesystem (>= `2023.09.18`) and pambase (>= `20230918`) packages now ensure [umask](https://man.archlinux.org/man/umask.1p) being set centrally in /etc/login.defs instead of /etc/profile. ``` Best, David -- https://sleepmap.de

1 2

Bug Day
by Jelle van der Waa 17 Sep '23

17 Sep '23

Hey All, I'd like to propose that we have a bug weekend on 1-3 September to clean up our bug tracker before we fully migrate it to Gitlab. We already have less issues then before! [1] But getting the number of issues to be migrated down would be a good thing and make our users happy :-) There is a list of "easy" of fail to build from source and issues with patches. [2] [3] Most of the coordination should happen on #archlinux-bugs on libera.chat. [1] https://dashboards.archlinux.org/d/c9a9b812-a067-4534-96bf-c21ba7a0c47d/fly… [2] https://bugs.archlinux.org/index.php?string=FTBFS&project=0 [3] https://bugs.archlinux.org/index.php?string=&project=0&opened=loqs Greetings, Jelle van der Waa

2 4

News Draft: ppp >= 2.5.0-1 update may require manual intervention
by Felix Yan 14 Sep '23

14 Sep '23

As you may or may not have noticed, both `ppp` and `rp-pppoe` package used to ship a `rp-pppoe.so` and they are not 100% compatible. Back in 2021, ppp 2.4.9 starts to rename its own copy of `rp-pppoe.so` to `pppoe.so`. As of `ppp 2.5.0`, upstream decided to remove the `rp-pppoe.so` symlink and thus broke configurations with the old name. If you still have the old ppp package's `rp-pppoe.so` configured somewhere (likely in /etc/ppp/peers/), please update it to use just `pppoe.so`. Configurations with the same plugin from the `rp-pppoe` package (using full path like /usr/lib/rp-pppoe/rp-pppoe.so) are not affected. -- Regards, Felix Yan

3 3

Arch Linux in August 2023
by Levente Polyak 10 Sep '23

10 Sep '23

## Staff We would like to welcome Tomaz Canabrava (tcanabrava) as part of the Arch Linux Package Maintainer team. ## AURWeb In [AURWeb v6.2.7][0], we primarily focused on bug fixes while revamping Prometheus metrics. We introduced new measures like request tracking and cache-hit/miss ratios for search queries, enhancing our ability to make development decisions and aiding the AUR moderation team in identifying trends. Collaborating with the DevOps team, we introduced a CI/CD feature called [Review Apps][1]. This feature enables us to create virtual machines running AURWeb for each merge request, facilitating change showcases, manual testing, and involving a wider audience for performance, stress-testing, and UI verification. ## RFC We [proposed and accepted an RFC][2] to define the default of not using `PyPI` for Python package sources and only use the platform if there is no other alternative. You can find more details about [this RFC][2] on GitLab. By making this change, we ensure to have a more reliable and less cumbersome default. ## Trademark Policy We've [relocated our Trademark Policy][3] from the Developer area of the ArchWiki to the [service-agreements GitLab repository][4], which is published at [`terms.archlinux.org`][5]. This move centralizes all legal documents, ensuring consistent collaboration across our service agreement materials. [0]: https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.7 [1]: https://docs.gitlab.com/ee/ci/review_apps/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 [3]: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… [4]: https://gitlab.archlinux.org/archlinux/service-agreements/ [5]: https://terms.archlinux.org/docs/trademark-policy/

1 0

RFC: Add -Wl,-z,pack-relative-relocs
by Jan Alexander Steffens (heftig) 03 Sep '23

03 Sep '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/23 Please visit the above link for discussion. Summary: Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

1 0

zlib-ng
by Jelle van der Waa 28 Aug '23

28 Aug '23

Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx

1 0

News Draft: ansible-core >= 2.15.3-1 update may require manual intervention
by Robin Candau 17 Aug '23

17 Aug '23

# ansible-core >= 2.15.3-1 update may require manual intervention As of ansible-core version `2.15.3`, upstream moved documentations and examples to a separated [dedicated repository](https://github.com/ansible/ansible-documentation) (see the [related changelogs](https://github.com/ansible/ansible/blob/v2.15.3/changelogs/CHAN…). This means that, starting from version `2.15.3` the `ansible-core` package will stop shipping documentations and a default configuration example under `/etc/ansible/ansible.cfg`. Regarding the documentation, it is available online: <https://docs.ansible.com/> As for the configuration file, as explained in the [wiki](https://wiki.archlinux.org/title/Ansible#Configuration), a base config can be generated with the following command: ```sh ansible-config init --disabled > ansible.cfg ``` After updating from ansible-core <= `2.15.2-1` to >= `2.15.3-1`, everyone using a global Ansible configuration file stored under `/etc/ansible/ansible.cfg` will have their configuration saved as a `pacsave` file. To re-instore it, run the following command: ```sh mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg ``` -- Regards, Robin Candau / Antiz

1 2