Arch-dev-public

arch-dev-public@lists.archlinux.org

9 participants
9647 discussions

squashfs-tools 4.6 dropped from testing
by David Runge 20 Mar '23

20 Mar '23

Hi all, squashfs-tools 4.6 has been dropped from testing due to a regression [1]. Please make sure to downgrade. Best, David [1] https://bugs.archlinux.org/task/77914 -- https://sleepmap.de

1 0

Arch Linux in February 2023
by Levente Polyak 18 Mar '23

18 Mar '23

## Git packaging sources All major workflow and usability requirements for the `pkgctl` tooling have been finished and a experimental `devtools-git-poc` package has been put into the repositories. Furthermore the proof of concept sandbox environment has been set up and rolled out to anyone interested in testing. In the current phase we will collect feedback to catch bugs and further usability improvements [0]. We are still very eagerly seeking for more testers. ## what can I do for Arch Linux Our new contributor website https://whatcanidofor.archlinux.org has been announced [1]. We would like to express gratitude towards the current, past as well as initial contributors for getting the ball on the road. There have been some changes since the announcement, including the Arch navbar more or less being implemented and a decent amount of work in general. ## FOSDEM 2023 A lot of arch staff has visited FOSDEM 2023 in Brussels, where we exchanged ideas, hacked on projects and participated in the open-source conference shenanigans. Overall it was a great event that yet again improved our team spirit. Foxboron held a talk at FOSDEM [2], he showcased how Arch Linux implemented support for debug packages in 2022, the improvement that was made to the pacman package manager, the infrastructure changes that were needed and how debug packages are distributed through debuginfod. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://fosdem.org/2023/schedule/event/debug_packages/

1 0

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

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

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

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public