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

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

Announcing whatcanidofor.archlinux.org
by Daniel M. Capella 04 Feb '23

04 Feb '23

Glad to finally announce a new contribution landing page for Arch Linux: https://whatcanidofor.archlinux.org It's a modern take on the asknot family, see the README for more details: https://gitlab.archlinux.org/archlinux/neoasknot/-/blob/main/README.md The Arch Linux theme and navbar we all know and love /will/ be implemented, don't you worry, and maybe even a search bar: https://gitlab.archlinux.org/archlinux/neoasknot/-/issues -- Best, Daniel <https://danielcapella.com>

1 0

Re: ROCm in [community]
by Torsten Keßler 29 Jan '23

29 Jan '23

Hi Sefa, thank you very much for your interest in the ROCm stack. I've just added ROCm meta packages to [community-testing], see [1] for a complete list. For instance, if you would like to use the full stack, install rocm-hip-sdk. Best! Torsten [1] https://docs.amd.com/bundle/ROCm-Installation-Guide-v5.4.2/page/Meta-packag… On 06.01.23 13:08, Sefa Eyeoglu wrote: > Hi Torsten, > > thanks a lot for your work! I am here to ask if it's planned to create > a group for these packages. That would make it a lot easier to install > all of the (currently available) toolchain at once. > > Best, > Sefa > > > On Fri, 2022-12-23 at 16:20 +0100, Torsten Keßler wrote: >> Hi all! >> >> I'm excited to announce that basic ROCm support was added to >> [community-testing] yesterday! >> >> What is ROCm? >> ROCm is AMD's open source framework for GPU programming. It comprises >> an >> OpenCL implementation, HIP (AMD's CUDA) and OpenMP offloading. >> >> Which GPUs are supported? >> Official support is limited, see [1]. >> >> Which parts were added to [community-testing]? >> The low level components (rocminfo, rocm-smi-lib), the OpenCL runtime >> (rocm-opencl-runtime) and the HIP runtime / compiler (hip-runtime- >> amd). >> >> How can I use it? >> Install (hip-runtime-amd rocm-smi-lib rocm-opencl-runtime) to use all >> currently available packages. First check if the amdgpu kernel module >> is >> loaded and add your login user to the video and render groups. Run >> /opt/rocm/bin/rocminfo to validate that the HSA runtime correctly >> detects your hardware. You can also check the output of clinfo for >> OpenCL support. >> >> Use case: blender >> First, install hip-runtime-amd and add /opt/rocm/bin to PATH. Open >> blender, go to Edit -> Preferences and select "HIP" in "System / >> Cycles >> Render Devices". Open your favorite scene and select "GPU compute" in >> "Render Properties". You can monitor the GPU load with >> >> watch -n.1 rocm-smi >> >> if you've installed rocm-smi-lib. >> >> What's next? >> Add the ROCm math libraries (rocblas, rocsparse, rocfft, ..) that are >> needed for Machine Learning and many other applications. >> >> Best! >> Torsten >> >> [1] >> https://docs.amd.com/bundle/Hardware_and_Software_Reference_Guide/page/Hard…

1 0

FOSDEM 2023 Dinner
by Morten Linderud 26 Jan '23

26 Jan '23

Yo! The previous years at FOSDEM we have held a dinner with around 15-20 people. Some maintainers from Arch, and some users that wanted to join. It has been great events and with FOSDEM 2023 happening I thought it was a good idea to do it again :) The dinner will be held Saturday, 4th of February, around 20:00. The dinner is sponsored by the Arch and should cover a drink and a main course. We will cap the attendees to 20 people. Priority for members of the Arch team (developers, trusted users and support staff). Any free spots after this can be taken by anyone interested. Send me an email *offlist* if you want to attend. The users requesting spots will get a heads up the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) I also plan to announce a pub closer to the FOSDEM weekend, so anyone unable to join the dinner can still come and grab a drink with the rest of us. Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 1