Arch-dev-public February 2023

arch-dev-public@lists.archlinux.org

13 participants
12 discussions

Orphan keenerd packages
by Jelle van der Waa 14 Mar '23

14 Mar '23

Hey all, All of these packages have no maintainer and are not required by anything. they should either find a new maintainer or be dropped: * armagetronad * bbe * bochs (gtk2.. ideally dropped) * bwm-ng * calc * cataclysm-dda-tiles and cataclysm-dda * cpuburn * curseofwar * dietlibc * dina-font * emelfm2 (gtk2 so will be dropped) * epdfview (gtk2) * ps_mem * pinfo * pcb * pacmatic (usefulish?) * pacgraph (useful!) * ngircd * nethogs * multitail * mg * memconf * mathomatic * lwm * keynav * jwm * hiawatha * hd-idle * gprolog * gnu-apl * gftp (gtk2) * gerbv * galculator * freedroid * fbv * fbgrab * fbdump * python-blessings I might have missed a few, but those will shown up when we drop the package/keenerd relationship in Archweb. As usual packages will be dropped after ~ 2 weeks. Greetings, Jelle

3 3

Cython packages need rebuild on all Python interpreter updates
by Filipe Laíns 01 Mar '23

01 Mar '23

Hi, It has recently come to my attention that Cython uses CPython's private API, which is unstable, see [1]. From https://docs.python.org/3/c-api/stable.html: > Names prefixed by an underscore, such as _Py_InternalState, are private API > that can change without notice even in patch releases. Meaning that packages that ship Cython modules are dependent on the interpreter version, and need to be rebuilt on all python release updates, including patch releases. [1] https://github.com/cython/cython/issues/5275 Cheers, Filipe Laíns

1 1

RFC Final Comment Period: Increase _FORTIFY_SOURCE level to 3
by Levente Polyak 27 Feb '23

27 Feb '23

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/17 Please visit the above link for discussion. Summary: Adjust packaging CFLAGS from -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=3 for better fortification coverage Cheers, Levente

1 0

Arch Linux in January 2023
by Levente Polyak 27 Feb '23

27 Feb '23

## Git packaging sources We have announced the state of the art of the Git packaging migration to `arch-dev-public` [0] including a first item on our distro roadmap to track the remaining effort [1]. We have prepared most of the necessary settings, configurations and the corresponding machine for the new test environment for the Git package workflow. The test phase is expected to start at the beginning of February. ## base-devel We have implemented the `base-devel` and `multilib-devel` meta-package orthogonal to our already existing `base` meta-package [2][3]. Lately we added `debugedit` to `base-devel` in order to provide debug packages via makepkg. This lead to a couple of followup issues with installations missing the new package as changes in a package group are not automatically reflected on system upgrades. ## RFC We are formalizing an RFC [4] to increase `_FORTIFY_SOURCE` level to 3 in our default build flags. For a long time, we have been using `-D_FORTIFY_SOURCE=2` to detect C memory management problems at build time. Recently, glibc (2.34) added `_FORTIFY_SOURCE=3` to add extra checking. This has been supported in clang for some time, and is now available in GCC with the release of version 12. The gains are enhanced buffer size detection and better fortification coverage. ## Staff We would like to welcome Robin Candau (Antiz) among the Arch Linux Package Maintainers [5]. Due to extended inactivity, Kyle Keen (keenerd) has been removed from the Arch Linux Package Maintainers [6]. We would like to express our gratitude to Kyle for many years of packaging work. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [1] https://gitlab.archlinux.org/groups/archlinux/-/epics/7 [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [3] https://archlinux.org/news/switch-to-the-base-devel-meta-package-requires-m… [4] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17/ [5] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [6] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t…

1 0

Call for participation: Git packaging POC 🚀🎉
by Morten Linderud 21 Feb '23

21 Feb '23

Hi everyone! Levente and I have been busy preparing a test environment for the new git package workflow, which is going to replace the svn repository. To test the new git package setup install `devtools-git-poc` from the [community] repository and use the new `pkgctl` utility. Please check each time if there is a new upgrade before playing around. The goal of the testing is to figure out UX issues, bugs and larger issues that would need to be dealt with before a git migration can happen. It's therefor very important that people sit down and play around with the tools :) Support and feedback will be dealt with in the #archlinux-projects channel. Report bugs in GitLab with the following additional information: - devtools-git-poc package version - full PKGBUILD or pkg repo including the Git hash - terminal input and output The workflow should be the following: Basic setup ----------- ### setup packager Make sure your personal `makepkg.conf` contains your packager identity and gpg key. ### authenticate to gitlab pkgctl auth maintain existing packages -------------------------- ### clone an existing package pkgctl repo clone existing-package ### build a package pkgctl build ### release a package pkgctl release pkgctl db update ### combined UX The last three steps can also be expressed as: pkgctl build --release --db-update ### rebuild into staging vim PKGBUILD pkgctl build --staging pkgctl release --staging pkgctl db update This can be completely condensed by: pkgctl build --rebuild --staging --release --db-update maintain new packages --------------------- ### create a new package repo without history pkgctl repo create new-pkgbase pkgctl repo clone new-pkgbase ### add existing AUR repo cd packagerepo pkgctl repo create pkgctl repo configure ### first official build/release Specify the target repo on first run, as the tool can't know it's destination automatically yet pkgctl build --repo extra pkgctl release --repo extra --db-update --- The packages are uploaded into a test group here: https://gitlab.archlinux.org/bot-test/packages This test also includes junior developer and junior packagers. They can only push packages into staging and testing, and not release into the stable repositories. We currently have a couple of people with these permissions to try and figure out issues on that part of the setup. If anyone is interested helping out on this please reach out on the #archlinux-projects IRC channel on Libera. Background on the changes can be found here: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… Cheers!

4 4

Automate adding library provides
by Balló György 14 Feb '23

14 Feb '23

Hi all, I looked various packages in the [core] repository to check if they specify their external shared libraries in provides=(). I opened several task on Flyspray [1], but it was turned out that still many packages don't specify them. It was turned out also that adding these libraries to provides=() can be easily automated in makepkg, so we don't actually need to add these entries manually. Allan already implemented it [2] for the next pacman release, but in an incompatible way, he changed the naming e.g. from 'libglib-2.0.so=0-64' to 'lib:libglib-2.0.so.0'. I think we should decide if we want to keep the current naming schema, or deprecate it and switch to the new one, and then make a migration plan. Switching to the new naming schema will be more complicated. == Keep the current naming schema == In this case we can simply add and enable a new option for makepkg to add shared libraries to provides=() automatically during build, and then mass remove the existing *.so entries from provides=() in every packages. Dependencies are no need to be updated, since we keep the current naming schema. == Use the new naming schema == In this case we have to keep the existing *.so entries in provides=() for a while, because removing them would cause missing dependencies in other packages. 1. We have to add and enable a new option for makepkg to add shared libraries to provides=() automatically, following the new naming schema. 2. We also have to update each package manually to replace *.so entries in depends=(), and adapt changes to automate library dependencies (see below). 3. Once all dependent packages are updated, we can remove the *.so entries from provides=(), and rely on the new naming schema entirely. == Automate library dependencies == Allan's implementation will also add library dependencies to packages automatically. I think we should enable adding libraries to provides=(), but disable adding libraries to depends=() by default, because the latter needs manual changes in each PKGBUILD. It does not support to mark dependencies optional yet, but I sent a merge request [3] to make it possible via a new optbinaries=() entry in PKGBUILD. This feature is completely optional if we keep the existing naming schema. But if the new naming schema adopted, there is no easy way to avoid it, because the new name will contain the major version of the library, so manually specified library entries in depends=() would need to be updated manually on each soname bump. What are your opinions? Which naming schema we should follow? Is there any other issues? [1] https://bugs.archlinux.org/index.php?string=Add+libraries+to+provides%3D%28… [2] https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/th… [3] https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/58 -- György Balló Package Maintainer / Trusted User

1 0

PyTorch with ROCm in [community]
by Torsten Keßler 12 Feb '23

12 Feb '23

Hi! I'm excited to announce that the full ROCm stack moved from [testing] to [community] today. To celebrate this, PyTorch packages with ROCm support are now in [community]! A simple code to check if the ROCm backend works on your machine is if torch.cuda.is_available() and torch.version.hip: d = torch.device('cuda') a = torch.rand(1, 2).to(d) print(a + 0) print("TESTS PASSED!") else: print("ROCm not supported with PyTorch installation") After you installed python-pytorch-rocm or the optimized python-pytorch-opt-rocm from [community], save the code snippet as rocm.py and run python rocm.py The output should be similar to tensor([[0.9949, 0.5596]], device='cuda:0') TESTS PASSED! Cheers, Torsten

1 0

[News draft] Switch to the base-devel meta-package requires manual intervention
by Robin Candau 10 Feb '23

10 Feb '23

Hi everyone, People that installed the base-devel group-package (before it became a meta-package) won't get the actual "base-devel" package itself installed on their machine until they explicitly (re-)install it. This may cause some regressions. For instance, since the "base-devel" package isn't /listed as/ installed on the system, pacman won't prevent users to remove packages it depends on. I draft a news about this, don't hesitate to give me your thoughts :) --- # Switch to the base-devel meta-package requires manual intervention The `base-devel` group-package has recently been replaced by a meta-package of the same name. People that had the `base-devel` group-package installed (meaning people that installed `base-devel` before February 2nd) have to explicitly re-install it to get the new `base-devel` package installed on their system: ``` pacman -Syu base-devel ``` -- Regards, Robin Candau

1 0

Arch Linux in December 2022
by Levente Polyak 08 Feb '23

08 Feb '23

## The wiki went dark 🌗 Thanks to the effort of Blake Wilson in completing the process [0][1] previously attempted [2] by killertofus to add Extension:DarkMode [3], it's lights out for ArchWiki! All you creatures of the dark can now click on "Dark mode" in the user menu to experience the soothing darkness. The preference is stored in the database, so it is only remembered for logged-in users and sadly there is no `prefers-color-scheme` support. Persistent people can probably find some ways to append a `usedarkmode=1` query parameter to wiki URLs. ## Decommission patchwork We have decommissioned patchwork.archlinux.org and replaced it with a static copy. As announced on the mailing list [4] pacman has been migrated to gitlab and there is no real use for patchwork left. A static copy is kept around for the time being to avoid link rot [5]. ## Debug packages by default We have enabled the debug package option globally in devtools [6]. Any subsequently built packages will package debug symbols by default. Currently the debug packages are only exposed via debuginfod and will be exposed to our mirrors in the future. ## Git packaging sources A huge amount of time has went into the ongoing development and iteration of the new `pkgctl` tooling [7]. We are currently focusing on stability and a fluent user experience. Some work has been started to be able to provide a proof of concept environment in January. ## The state of ruby After a few month of trying to de-vendor the ruby 3.0 stdlib gems we have decided to stop the effort as we ran into more problems and ruby itself highly recommends to not do this. This also means that with the de-vendored setup we would get no support from upstream for any issues we have with the ruby interpreter. We have now started to update ruby to 3.1 and will proceed afterwards with 3.2. [0] https://github.com/archlinux/archwiki/pull/63 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/664 [2] https://github.com/archlinux/archwiki/pull/59 [3] https://www.mediawiki.org/wiki/Extension:DarkMode [4] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [5] https://gitlab.archlinux.org/archlinux/patchwork-archive [6] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/123 [7] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/126

1 0

glibc 2.37 release
by Frederik Schwan 04 Feb '23

04 Feb '23

Glibc 2.37 is about to be released to [testing]. Please be aware that any package that links against the 2.37 libc has to stay in testing for as long as glibc stays there. Otherwise breakage will be imminent. Best regards, Frederik

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public February 2023