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

Orphaning packages
by Tobias Powalowski 14 Mar '23

14 Mar '23

Hi guys, early spring cleanup on my adopted packages: - b43-fwcutter - dmraid (not maintained upstream anymore) - facile - edac-utils - mp3splt - mp3wrap - libmp3splt - libksba - libiscsi - libifp - libraw1394 - linux-atm - mdadm - testdisk - xinetd - Samba stack: I would be really really happy, if someone, who also is using this piece of software would adopt it. Volunteers please go ahead. - samba - smbclilent - libwbclient - iniparser - ldb - tdb - tevent Thanks. greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot

1 0

Dependencies from pkg-config files
by Balló György 06 Mar '23

06 Mar '23

Hi all, I implemented a new rule for namcap [1] to check if dependencies from pkg-config .pc files are satisfied. These are used by the 'pkg-config - -cflags --libs <library name>' command to set the appropriate CFLAGS and LDFAGS when building any dependent (direct and indirect) packages. If any of dependencies specified in 'Requires' or 'Requires.private' fields are missing, pkg-config throws an error. These dependencies are mostly covered by link-level dependencies, but there are some exceptions. Some packages already aware about this (e.g. glib2 -> libsysprof-capture; libx11 -> xorgproto), so we only need to fix a few others. I checked 590 core packages, and I found 13 packages with missing dependencies. [2] I propose the following solutions: - Some missing dependencies (gobject-introspection, systemd, util- linux) are caused because the pkg-config files are packaged separately from the libraries. This shouldn't happen in our distribution, because we don't split development packages. pkg-config files and the related header files should be in the same package where the library is found. - Some packages depend on specific header or data files (xorgproto, wayland-protocols) without linked library in it. Sometimes just a struct is needed from a header file in another package (libxi -> libxfixes). [3] Sometimes a library is used by dlopen() instead of linking (libepoxy -> libglvnd). [4] These should be added as dependencies if defined in a pkg-config file. - If you are sure that the dependency is unnecessarily, then contact with upstream. If no objections, I'll open tasks in Flyspray for these issues. [1] https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/28 [2] https://md.archlinux.org/s/iXr206Xb1 [3] https://gitlab.freedesktop.org/xorg/lib/libxi/-/blob/08431d0684f9a1edf199f6… [4] https://github.com/anholt/libepoxy/blob/8db879f810e2dbc63824c43c17eeea0d3db… #L547-L559 -- Balló György Package Maintainer / Trusted User

4 10

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

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