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

Future of libdepends and libprovides
by Balló György 09 Mar '24

09 Mar '24

Hi all, Since the support for libdepends and libprovides has been removed from the recently released pacman 6.1, [1] we need to do something before adopting it to Arch Linux. Many our packages rely on libdepends and libprovides, and if makepkg would not fill the soname version and architecture, those dependencies would be broken. I mentioned this one year ago, but no further discussions happened. [2] In short term, we should revert this commit [3] at distribution level to avoid breakages. In long term, we have to decide via RFC what to do with libdepends and libprovides. We could probably make a slow, manual transition to the new 'autodeps' feature in pacman, but it still does not support optional autodeps, [4] which means that would be impossible to mark any binary deps as optional. [1] https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0 [2] https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux… [3] https://gitlab.archlinux.org/pacman/pacman/-/commit/354a300cd26bb1c7e655147… [4] https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/58 -- György Balló Package Maintainer

2 1

RFC: Allow all staff to create RFCs
by Kristian Klausen 05 Mar '24

05 Mar '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 Please visit the above link for discussion. Summary: Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

1 0

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Mar '24

03 Mar '24

Hi, Currently we have a lot of our mkinitcpio hooks in several packages which has never been consolidated. This makes it confusing where stuff belong and what is provided where, and I really want to consolidate everything. It would help keeping up the development of the hooks, patch everything and ultimately write a test suite for mkinitcpio. I also have long term plans on moving the default hooks from busybox to systemd, but this will happen at a later point. Initially I really want to move the hooks from `cryptsetup` and `systemd`: * encrypt and sd-encrypt from core/cryptsetup * systemd and udev from core/systemd We could maybe consider a few other hooks from [core] depending on peoples opinion? We are missing a good networking hook for systemd, and that should preferably be solved at some point. A list of possibly other relevant mkinitcpio stuff: Hook Package * btrfs btrfs-progs * dmraid dmraid * mdadm mdadm * mdadm_udev mdadm * lvm2 lvm2 * sd-lvm2 lvm2 * net mkinitcpio-nfs-utils * netconf mkinitcpio-netconf # Migration It's unclear to me how we should best move these hooks. We would need to merge them upstream into `mkinitcpio` first, then remove them from the packages. Is a news item is enough for this? Or do we want to include a couple of package constraints to ensure people are accidentally removing their hooks? What are peoples opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

5 10

Announcing pacquery
by Jelle van der Waa 03 Mar '24

03 Mar '24

Hi all, One of the things I've been missing for a long time is the ability to easily query package information. Pacman -S --print-format lacks some options and more importantly does not support json output. I've had a small rust utility locally which helped a lot with getting ready for the pacman rebuild. This weekend I spend some time refining it and releasing it to the repos as pacquery. An example, finding all packages which have make/check/depends on python-tomli [jelle@natrium][~/projects/pacquery]%pacquery python-tomli | jq -r '.[].required_by | join(" ")' python-flake8-black python-ipdb python-setuptools-gettext python-setuptools python-responses python-tomli-w python-fsspec sip mdformat repod mypy autopep8 python-diff-cover python-pep621 python-versioningit python-pylint python-pdm-pep517 python-sphinx-theme-builder python-pytest-cov towncrier python-isort Note that this tool uses the syncdb's so these need to be up to date and it defaults to core,extra,multilib. Greetings, Jelle van der Waa

1 0

GHC 9.2.8 enters [extra-testing]
by Felix Yan 26 Feb '24

26 Feb '24

Hi all, The long delayed GHC 9.2.x updates have been done and moved to [extra-testing]. There are a few notable changes regarding our GHC packaging: - Codegen backend has been switched back to NCG for multiple reasons: = GHC doesn't support latest LLVM and was using llvm14 in Arch. This adds up to our maintenance burden of LLVM. (IIRC LLVM 15 support was fixed only recently.) = LLVM backend actually generates slower code. We have evaluated the changes during the past years and noticed as large as 50% slower results in some benchmarks. I also got similar information from other distribution people. = LLVM backend sometimes deadlocks on compile-time. I hit this from time to time and it's not easy to reproduce reliably. (There are similar issues that are always reproducible, but got fixed already.) All `--ghc-option=-fllvm` has been removed from PKGBUILDs during the rebuild. - Build system of GHC itself has been switched to Hadrian. - Some obsolete packages have been retired from the distribution, and will be removed once the batch enters [extra]: haskell-bytestring-show haskell-random-source haskell-brittany haskell-hls-brittany-plugin haskell-hls-tactics-plugin haskell-hls-haddock-comments-plugin A lot of thanks to @Vekhir who helped me a lot for preparing this so that it's done much earlier and smoother than I expected :) As always, please report any issues and have fun! -- Regards, Felix Yan

1 0

RFC: Distribution Developer Manual
by Levente Polyak 24 Feb '24

24 Feb '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/21 Please visit the above link for discussion. Summary: This RFC proposes the migration of Arch Linux's operational distro specifications from existing ArchWiki and other sources to a dedicated GitLab Developer Manual repository. The intention is to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. This change aims to centralize and enhance the efficiency of specification management while preserving the integrity of the community-contributed content in the Wiki. This request for comments is superseding `RFC-0005 <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/5>`_ by extending its scope to handle all distro specifications coherently instead of handling a single sub section (packaging guidelines) differently to others.

1 0

Arch Linux in January 2024
by Levente Polyak 13 Feb '24

13 Feb '24

## Staff We would like to welcome [Vladimir LAVALLADE (Erus Iluvatar)][0] to their new role as ArchWiki Administrator. ## Infrastructure The DevOps team has recently provisioned a new EPYC 9454P build server for Arch Linux packaging. This high-performance server is meant to streamline the packaging process, ensuring more efficient building of resource hungry package builds. ## mkinitcpio mkinitcpio [v37.2][1] and [v37.3][2] have been released. These releases include numerous bug fixes, such as patches addressing inflated initramfs sizes and resolving issues with kernel images located in non-standard locations. ## RFC An [RFC has been proposed][3] to add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. Additionally, an [RFC has been proposed][4] to define new mirror administration routines and mirror requirements. This RFC outlines the requirements, definitions and guidelines surrounding not only becoming but also maintaining and decommissioning a mirror. ## Packaging ### Firefox The [firefox][5] and [firefox-developer-edition][6] packages have been updated to include regular debug packages. As part of this update, symbols are no longer submitted to Mozilla at the end of the build process. Instead, [Mozilla retrieves all symbols from our end][7]. This change enables local debugging of Firefox while still allowing the submission of useful crash reports to Mozilla and leveraging their profiling service. ### Statistics In this month, we've successfully rolled out 11068 package updates addressing various enhancements and rebuilds, including 2777 package upgrades. Additionally, we've received 204 new package issues, while resolving a total of 258 issues. [0]: https://wiki.archlinux.org/title/ArchWiki:News#2024/01/07_-_New_administrat… [1]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v37… [2]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v37… [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26 [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29/diffs [5]: https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/commit/… [6]: https://gitlab.archlinux.org/archlinux/packaging/packages/firefox-developer… [7]: https://github.com/mozilla/symbol-scrapers/pull/41

1 0

dropping opera
by Ike Devolder 07 Feb '24

07 Feb '24

Hi, Since I have not really used opera for years, I'm finally going to drop it from the repo's. If someone wants it, feel free to adopt it. Else I will drop it to AUR in 2 weeks. --Ike

1 1

RFC Final Comment Period: Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
by Morten Linderud 06 Feb '24

06 Feb '24

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/26 Please visit the above link for the discussion. Summary: Add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. -- Morten Linderud PGP: 9C02FF419FECBE16

1 2

Forensic tool release: archlinux-userland-fs-cmp (reproducible pre-compiled binary available)
by kpcyrd 31 Jan '24

31 Jan '24

hello, I released a tool recently that I'd like to share with this list: https://github.com/kpcyrd/archlinux-userland-fs-cmp It's supposed to be used from a rescue image (any Linux) with an Arch install mounted to e.g. /mnt. It does the following: - Open /mnt/var/lib/pacman and extract the list of (allegedly) installed packages. - Instead of trusting the `mtree` files from the mounted file system, the %NAME% and %VERSION% values from the `desc` files are used to start a download stream from archive.archlinux.org. - From the download stream it's decompressing and inspecting the content on-the-fly, since the .MTREE file is near the beginning of the package we can abort the remaining package download after the mtree has been received (saving a lot of time and traffic). - All files in /mnt that are part of a package are hashed and compared with the sha256 hashes in the MTREE files downloaded from the archive. - Finally, it's printing a report of all files that either mismatched or are not a part of any package. This can be redirected to a file using the -o flag. At no point is any file from the mounted filesystem eval'd or otherwise executed. Parsers are written in a memory safe language. Although it's integrating with pacman, the integration with archive.archlinux.org makes this Arch Linux specific, files from AUR, Manjaro or SteamOS packages are all going to be flagged for manual inspection. The authenticity of the .MTREE files is assumed through the https connection they are downloaded from (which is supposed to be sufficient for the use-case it's built for). The release page on github has a pre-compiled, statically linked binary that can trivially be reproduced from source code. The dependency tree is documented in Cargo.lock, the build environment is documented in repro-env.lock. The binary has been tested to be working correctly on a Debian bookworm installer busybox rescue shell. There's a gif in the README showing how the tool looks like in action. --- I also printed reproducible builds stickers with a new and unique design that I'm planning to hand out at FOSDEM (along with some 37c3 leftovers), if you have read this far, feel free to ask me about stickers if you see me there. The print cost geht auf mein Nacken. cheers, kpcyrd

1 0