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

New checks for SPDX license identifiers with namcap >= 3.5.0
by David Runge 14 Jan '24

14 Jan '24

Hi all! With RFC0016 [1] we have worked out a way to reason about SPDX license identifiers [2] in the context of PKGBUILDs and packages. Over the past months I have worked on the licenses package [3], as well as namcap [4] to create the integration for all packagers. This mail serves as a refresher and general overview of what this means for packagers. TL;DR: Namcap now emits more specific error messages and there are probably a few things in this mail that you will want to learn about! :) To be able to be more specific in the below text, I will use this mini-glossary to explain what some words refer to: * *known* licenses and exceptions - Licenses and license exceptions *known* to SPDX (i.e. they are in the lists [2][5]). * *unknown* licenses and exceptions - Licenses and license exceptions *not known* to SPDX (i.e. they are *not* in the lists [2][5]). License identifiers prefixed with "LicenseRef-" are not considered. * *common* licenses and exceptions - Licenses and license exceptions that are packaged in the context of the licenses package [3] and can be shared *commonly*. * *uncommon* licenses and exceptions - Licenses and license exceptions that are *known*, but are *not common* (i.e. they are in the lists [2][5] but not in the licenses package [3]). License identifiers prefixed with "LicenseRef-" are always considered *uncommon*. For packagers a few things change when it comes to handling license information for packages. * It is encouraged to have a look at the list of *known* license identifiers [2] and exceptions [5] to familiarize yourself with how identifiers look like. The *common* licenses can be found in /usr/share/licenses/spdx/ and the *common* license exceptions in /usr/share/licenses/spdx/exceptions/. * The `license` array in PKGBUILDs should now start to contain valid SPDX license identifiers [2][5] or custom license identifiers, that are prefixed with "LicenseRef-" (e.g. "LicenseRef-Custom-License-1.0"). To keep complex scenarios maintainable and readable, each entry in the `license` array may be interpreted as being concatenated by the `AND` license expression [6]. * We now distinguish between various versions of some identifiers (e.g. previously we were okay with simple identifiers such as "GPL3" but now we have "GPL-3.0-only" and "GPL-3.0-or-later", which are separate from one another). If you are unsure about what applies, either contact upstream or reach out over mail, IRC, Matrix to ask other packagers. * If in doubt, rather be more specific than less specific! * To aide in documenting copyright and attribution, many upstreams rely on SPDX License IDs [7], which are added as comments at the top of each source file. These often help a great deal in figuring out which specific licenses apply and help in finding out whether there are any license files missing. To help you with figuring things out, namcap gained a few more features with > 3.5.0 (although some issues had to be ironed out up until 3.5.2 and I seriously hope I didn't introduce even more bugs ;-)). Please remember that namcap does not take away the work of investigating and providing the correct license identifiers for you! * Namcap now emits errors on all *unknown* license identifiers [2] and license exceptions [5]. * Namcap now lists all *uncommon* licenses and license exceptions while providing an overview about how many license files it found for the amount of *uncommon* identifiers (each *uncommon* identifier requires a separate file). * Namcap now emits errors with suggestions on formatting issues of license expressions (e.g. `MIT and Apache-2.0` -> `MIT AND Apache-2.0`). * Namcap now emits errors on license strings that can not be parsed. * Namcap now emits errors when the license directory is a symlink to a location in another package, that is not in `depends`. * Namcap now emits errors when the license directory is a symlink to a location in another package and license files are missing for *uncommon* identifiers. * Namcap now emits warnings if it detects symlinks for the license directory or single license files to another package. This is done because it is *very* cumbersome and error-prone to detect files in other packages reliably (e.g. those could in turn be symlinks to non-existent files, etc.). It is encouraged to package license files per package! Symlinks in the same package are fine! I hope this summary was not too overwhelming and will help you to get through the licensing jungle! Please do note, that the Arch Wiki section on license identifiers in the PKGBUILD article [8] still needs to be adapted. If there are any questions, please reach out! Many thanks to everyone who worked on the RFC and helped with testing the implementation! Best, David [1] https://rfc.archlinux.page/0016-spdx-license-identifiers/ [2] https://spdx.org/licenses/ [3] https://archlinux.org/packages/core/any/licenses/ [4] https://gitlab.archlinux.org/pacman/namcap/ [5] https://spdx.org/licenses/exceptions-index.html [6] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ [7] https://spdx.dev/learn/handling-license-info/ [8] https://wiki.archlinux.org/title/PKGBUILD#license -- https://sleepmap.de

1 0

RFC: Mirror Definition
by Anton Hvornum 09 Jan '24

09 Jan '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 Please visit the above link for discussion. Summary: Before this proposal, there were a lack of requirements and definition of what a mirror is within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirror.

1 0

Making dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 05 Jan '24

05 Jan '24

The following change just entered our testing repositories: We are making dbus-broker our default implementation of D-Bus, for improved performance, reliability and integration with systemd. For the foreseeable future we will still support the use of dbus-daemon, the previous implementation. Pacman will ask you whether to install dbus-broker-units or dbus-daemon-units. We recommend picking the default. For a more detailed rationale, please see RFC 25 at https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25.

1 0

freerdp dropped from [extra-testing]
by David Runge 02 Jan '24

02 Jan '24

Hi all! I just dropped freerdp from [extra-testing], as I moved it there erroneously. Freerdp > 3 is currently *not* compatible with most dependents. I will try to figure out whether a freerdp2 package is feasible in the coming days. Patching the dependents is of course also an option, however most upstreams seem to not have progressed sufficiently on the topic yet. Best, David -- https://sleepmap.de

1 0

RFC Final Comment Period: Make dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 16 Dec '23

16 Dec '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/25 Please visit the above link for discussion. Summary: Make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations.

1 0

RFC: Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
by Morten Linderud 16 Dec '23

16 Dec '23

A new RFC (request for comments) have been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26#note_149849 Please visit the above link for 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. I'm sponsoring this on behalf of Daan De Meyer. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Stepping down as Python maintainer
by Felix Yan 13 Dec '23

13 Dec '23

Hello, For the past ten years (and several days) I have been the guy maintaining Python itself and some libraries in Arch. It's been a long journey and I learned a lot from it. I was a web back-end developer back then, and I used Arch as the base OS of our company's servers and system-wide Python packages as the runtime. The server and website are still running today, but I am no longer developing Python very frequently these days. Plus, Python's type-hinting has been a headache for me for years and lowered my interest in contributing to upstream projects a lot. In the past, the large cross-minor-version Python rebuilds were done with either Evangelos' rebuilder or my own island solution. I understand Arch's striving to improve bus factor and formalizing process, so I am making room for others to try on the 3.11 and 3.12 rebuilds. As Jelle has progressed a lot now, I feel it's approaching the right time for me to step down as the Python maintainer. I will be disowning many of my no longer used Python module packages in the following days, so that they could find a better maintainer either in the Arch team, or later in the AUR if they are going to be dropped. Please also consider adopting the main python package and let me know :) -- Regards, Felix Yan

1 0

Arch Linux in November 2023
by Levente Polyak 12 Dec '23

12 Dec '23

## Arch Summit 2023 The Arch Summit took place in Hamburg, Germany, on November 4th and 5th, bringing together Arch Linux staff and invited guests. The summit provided an opportunity for the staff to connect, socialize, and delve into discussions regarding various aspects of our distro. A range of topics were explored including but not limited to infrastructure and mirror management, rebuilders for packages, signing enclave, mkinitcpio, packaging tooling improvements, and community building. Reports on these discussions will be published later. A special thanks to "adesso SE" for generously sponsoring the event, offering an excellent venue and catering support. ## Bug migration We are happy to announce that the migration from Flyspray to GitLab is complete. 🥳 Bug reports and Merge Requests for packages or Arch Linux projects can now be found on GitLab. For more details, check out the [related Arch Linux news post][0]. ## Testing Team To join the [Arch Testing Team][1], simply drop an email to `arch-testing-accounts(a)archlinux.org`. This transitions the process to a [team-based][2] approach that not only speeds up the account setup process but also provides a more collaborative environment through the GitLab service desk. If you're keen on diving into contributing to Arch Linux, joining the Arch Testing Team is a fantastic way to kickstart your involvement. 🚀 ## bugbuddy [Bugbuddy v0.2.0][3] has undergone significant updates, including the periodic refresh of maintainer and staff data from ArchWeb, ensuring the automatic reflection of package orphaning and adoption. Additionally, package maintainers can now opt-in to be assigned to unconfirmed issues for their packages. Furthermore, default labels for severity and priority have been added, and merge requests have been streamlined with automatic assignment to package maintainers. ## mkinitcpio mkinitcpio v37 has been released. Notable changes include the `consolefont` hook now using the kbd project's `setfont`, resolving past issues. Furthermore, the `autodetect` hook introduced a workaround for a race condition with `udevadm settle` and includes all possibly needed modules as an alternative fallback, preventing incomplete initramfs images and potential unbootable systems. Check out the [mkinitcpio v37 release announcement][4] for more details and additional changes. ## dbscripts Recent updates enhance atomicity by consolidating a unit of work and implementing robust error handling. Concurrency issues have been resolved by replacing outdated locking code with a modern, convenient API, and adopting less error-prone locking through flock. These changes collectively address various scenarios that previously resulted in inconsistencies between operations and had the potential to corrupt the repository state. ## alpm-types alpm-types has been released in version 0.4.0 introducing various smaller fixes and improvements. More information can be found in the [changelog][5]. ## Pacman Pacman is in the final stages of [preparing its next major release][6], version [7.0.0][7]. Additionally, collaborative efforts with an external auditor for the audit of the package manager and libalpm have been initiated. Stay tuned for more information and announcements around this exciting development in the near future. [0]: https://archlinux.org/news/bugtracker-migration-to-gitlab-completed/ [1]: https://wiki.archlinux.org/title/Arch_Testing_Team [2]: https://gitlab.archlinux.org/groups/archlinux/teams/testing/admins/-/group_… [3]: https://gitlab.archlinux.org/archlinux/bugbuddy/-/releases/v0.2.0 [4]: https://lists.archlinux.org/hyperkitty/list/arch-projects@lists.archlinux.o… [5]: https://gitlab.archlinux.org/archlinux/alpm/alpm-types/-/blob/0.4.0/CHANGEL… [6]: https://lists.archlinux.org/hyperkitty/list/pacman-dev@lists.archlinux.org/… [7]: https://gitlab.archlinux.org/pacman/pacman/-/milestones/1

1 0

phoc phosh phosh-mobile-settings dropped from [testing]
by Jelle van der Waa 11 Dec '23

11 Dec '23

Hi all, I pushed 0.34 of phosh to [testing] but it sadly does not start on my x86 tablet, so I've pulled it out of testing until that is fixed. Greetings, Jelle

1 1

Arch Linux in October 2023
by Levente Polyak 10 Dec '23

10 Dec '23

## Staff We would like to welcome [Christian Heusel (gromit)][0] to the Arch Linux DevOps team, expanding his responsibilities. ## bugbuddy The initial version of [Bugbuddy][1], our GitLab bug bot, has been introduced. This tool assigns package maintainers to confirmed GitLab issues in the packaging group. Notably, the code has undergone substantial improvement, now operating as a daemon process that can promptly respond to GitLab webhook calls. ## dbscripts The `db-remove` command has been streamlined, eliminating the need to pass an `arch` parameter by adding automatic resolution. Moreover, the `db-update` command now properly checks staged packages against staging/testing, addressing a loophole that previously caused state inconsistencies. Additionally we've enhanced the development process by parallelizing test execution, massively reducing unit testing duration. ## RFC In late 2021, an [RFC was proposed][2] to rename the `Trusted User` role to `Package Maintainer`, aligning it with the role's evolving nature within the Arch staff. The RFC, voted positively in late 2022, has now resulted in the successful renaming across various Arch resources, including the [Packaging Bylaws][3], [ArchWeb][4], [AURWeb][5], [ArchWiki][6], and the "[What can I do for Arch Linux?][7]" page. ## ArchWiki The [ArchWiki has been updated to MediaWiki 1.40][8], necessitating adjustments to the ArchLinux extension due to upstream changes in the Vector 2022 skin. This has prompted consideration of [switching to the Timeless skin][9]. Additionally, there has been a switch from PNG to SVG images in the wiki for article status templates and statistic histograms. The wiki now features the addition of [Extension:Thanks][10] and [Extension:DiscussionTools][11], offering users a streamlined way to express gratitude and heavily simplifying discussions on talk pages. ## ArchISO The ISO now provides a `/boot/grub/loopback.cfg` file which GRUB and Super GRUB2 Disk users can use to boot the ISO file without needing to manually specify the kernel, initrd and kernel command line parameters. Documentation on utilizing the `loopback.cfg` file is available both [upstream][12] and on [ArchWiki][13]. [0]: https://lists.archlinux.org/hyperkitty/list/arch-devops@lists.archlinux.org… [1]: https://gitlab.archlinux.org/archlinux/bugbuddy/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 [3]: https://gitlab.archlinux.org/archlinux/package-maintainer-bylaws/-/merge_re… [4]: https://github.com/archlinux/archweb/pull/478 [5]: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/755 [6]: https://wiki.archlinux.org/index.php?title=ArchWiki_talk:Requests&oldid=790… [7]: https://gitlab.archlinux.org/archlinux/neoasknot/-/merge_requests/84 [8]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/747 [9]: https://github.com/archlinux/archwiki/pull/71 [10]: https://www.mediawiki.org/wiki/Extension:Thanks [11]: https://www.mediawiki.org/wiki/Extension:DiscussionTools [12]: https://www.supergrubdisk.org/wiki/Loopback.cfg [13]: https://wiki.archlinux.org/title/Multiboot_USB_drive#Arch_Linux_monthly_rel…

1 0