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

New community wide idea pool
by Levente Polyak 11 Nov '22

11 Nov '22

Hello everyone, Several times in the past I was thinking about a better and more central way to keep track of ideas and suggestions. We've encountered multiple times that good ideas got lost because we never properly kept track of them and only recognized after coming up with the very same idea much later. I'd like to address this issue and setup an actual community-wide place for this [0]. The GitLab repository is an incubating idea pool useful to keep track of early stage suggestions and brainstorming before they get picked up and implemented eventually. We will use an issue template [1] and various labels to classify ideas with rough t-shirt sized estimates. This will help volunteers to look out for ideas they would be interesting to invest time on. Cheers, Levente [0] https://gitlab.archlinux.org/archlinux/ideas [1] https://gitlab.archlinux.org/archlinux/ideas/-/blob/main/.gitlab/issue_temp…

2 2

Realtime kernels moved to [extra]
by David Runge 05 Nov '22

05 Nov '22

Hi all, today I have moved the realtime kernels to [extra]: https://archlinux.org/packages/extra/x86_64/linux-rt/ https://archlinux.org/packages/extra/x86_64/linux-rt-lts/ I have been maintaining these kernels in the AUR via a custom repository [1] for a couple of years now and believe that quit a few people actually make use of them (in various contexts). The effort to get the realtime kernel patchset [2] merged in its entirety has been going on for about 15 years already and the patchset is shrinking with every kernel release. In the future users will be able to configur the kernel build without a separate patchset. That all being as it is, historically there have been two repositories tracking the ongoing work: One for the work on the most recent Linux versions, while the other tracks all LTS branches that are supported. I am intending to follow both the most recent and the highest LTS version, while consolidating with core/linux and core/linux-lts wherever it makes sense. For that purpose we have moved the kernel repositories (with distribution specific patches), mirroring their respective upstream to: https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt-lts This allows for easy collaboration and cherry-picking of patches (which I do currently already for linux-rt, using core/linux) and my hopes are, that the knowlegde in our developer and packager team grows in how to configure kernel builds and maintain the packages. The https://gitlab.archlinux.org/archlinux/packaging/upstream/ group location is meant for all projects that have to maintain custom patches on top of what upstream does (that is also why shadow lives there currently). In case there are developers or package maintainers interested in collaborating on the builds and maintenance of the kernels, please reach out! Best, David [1] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ [2] https://wiki.archlinux.org/title/Realtime_kernel_patchset -- https://sleepmap.de

1 0

Arch Linux in October 2022
by Levente Polyak 02 Nov '22

02 Nov '22

## mkinitcpio mkinitcpio v32 has been released [0] which adds support for zst compressed firmware for future kernel versions as well as various fixes and adjustments. ## pacman pacman 6.0.2 has been released [1] which fixes multiple issues with debug packages. On top pacman-key has been adjusted to do a single gpg trustdb check instead of one after each key revocation. Furthermore various fixes have been added related to clang lto, reproducible packages containing sparse files and other fixes. ## python-bootstrap To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. In the future we want to rely on python-bootstrap [2] to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow. Not all initially required packages are defined yet, but a first attempt at bootstrapping has been completed [3]. ## OpenSSL 3 The OpenSSL 3 rebuild started with the latest version 3.0.7 which will hopefully land soon in the [testing] repository. [0] https://github.com/archlinux/mkinitcpio/releases/tag/v32 [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/v6.0.2 [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 01 Nov '22

01 Nov '22

Alright, I have updated openssl-1.1 (the one in staging) to the latest version and both include libprovides now. In addition to this openssl-1.1 provides openssl=1.1.1 On Tue, Nov 1, 2022 at 7:01 PM Luna Jernberg <droidbittin(a)gmail.com> wrote: > > 1.1.1r is just bugfixes and no critical security fix as in the 3.0x series > > On Tue, Nov 1, 2022 at 6:57 PM David Runge <dave(a)sleepmap.de> wrote: > > > > On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote: > > > I updated to 3.0.7 in staging. I had libprovides in my branch. Do you > > > guys think this might be handy to define versioned dependencies when > > > we have potentially three different openssl verions to maintain? > > > > > > provides=('libcrypto.so' 'libssl.so') > > > > Always a fan! Please add! :) > > > > > At the same time 1.1.1s was released which mainly fixes a regression > > > from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to > > > release that 1.1.1 update in the meantime? > > > > If it is not critical, maybe better to let the openssl 3 rebuild roll > > through. > > > > Best, > > David > > > > -- > > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com

1 0

Bootstrapping Python
by Jelle van der Waa 01 Nov '22

01 Nov '22

Hey All, Yesterday we had a successful meeting [1] on bootstrapping Python. For those who might wonder what this is about: To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. Filipe has created a project to tackle this issue, it uses python-installer to temporarily create wheels for setuptools, pep517, installer and other packages. [2] These can then be packaged using a PKGBUILD [3] and replace the existing python-setuptools package temporarily to build the "real" python-setuptools. Bootstrapping these tools will be a multiple stage bootstrap (and assumes an already available interpreter package such as python 3.11): 1. Build python-bootstrap 2. Build python-setuptools and co. (without tests) 3. Build all makedepends and depends of the bootstrapped packages (without tests) 4. Build "real" packages (those that have been bootstrapped) and replace the initial bootstrapped packages with them (without tests). 5. Build the ecosystem using the available packages (without tests) 6. Rebuild the ecosystem with tests In the future we want to rely on python-bootstrap to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow there. Not all initially required packages are defined yet, but a first attempt at bootstrapping can be found in a custom repository already [4]. This has been a quick PoC, we still need to put in a lot of work to get this to work out of the box - Get a full bootstrap working using python-bootstrap - Figure out how we deal with sphinx being a build requirement of python-installer/builder blocking bootstrapping - Figure out how to bootstrap setuptools - Create a script to determine the bootstrap order (using our repository database) - Better tooling for creating custom repositories / devtools chroots for these rebuilds - Automatically update python-bootstrap's git submodules to the repository version - Add documentation about the entire process If you have time to help testing and developing, please come join us in #archlinux-python on libera.chat. [1] https://md.archlinux.org/s/rBZYhg_fE# [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/blob/PKGBUILD/PKG… [4] https://pkgbuild.com/~jelle/python3.11/

1 0

Git submodules in PKGBUILDs are broken as of git 2.38.1 update
by Orhun Parmaksiz 27 Oct '22

27 Oct '22

Hey! As of git 2.38.1 [0], the handling of submodules in PKGBUILDS is broken due to CVE-2022-39253 [1]. This situation affects the packages that use the following command for updating the submodules: > git submodule update This will result in "fatal: transport 'file' not allowed" error since the value of `protocol.file.allow` is changed to be "user" by default. It means that `file://` clones are considered unsafe by default. Currently, there are two possible fixes available: 1. git -c protocol.file.allow=always submodule update 2. git submodule--helper update The latter seems to be an internal command which does not have any public facing documentation whereas the former option is more explicit. There is a related bug report [2] and a TODO list draft [3] for updating the affected packages. I will be updating the VCS guidelines [4] to use the first proposed solution if it all looks good. [0] https://lore.kernel.org/lkml/xmqq4jw1uku5.fsf@gitster.g/ [1] https://www.cve.org/CVERecord?id=CVE-2022-39253 [2] https://bugs.archlinux.org/task/76255 [3] https://md.archlinux.org/YVwV_wIKQfG5obcNLNlCjg [4] https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules Let's make some gains, Orhun

2 1

mkinitcpio and arch-install-scripts hackathon 22nd of October
by Morten Linderud 21 Oct '22

21 Oct '22

Yo, On the 22nd of October (tomorrow) there is going to be a small hackathon on minitcpio and arch-install-scripts! mkinitcpio needs some love before a new release can be made, the goal would also be to work on the open pull-requests before moving the project too our Gitlab instance. https://github.com/archlinux/mkinitcpio/ The current ideas is to do scope out a bugfix release and then a larger release, and we would love some help to do that. Beyond that we want to look at improving the general status of the systemd hooks in mkinitcpio, there are several projects that implements parts of this better than mkinitcpio and it would be neat to figure out how we should work on that. For ideas see issue 121 in the repo; https://github.com/archlinux/mkinitcpio/issues/121 I'm also maintaining arch-install-scripts but that is mostly out of necessity :) I'd love to find a new maintainer for the project, so any ideas or issues can also be worked on tomorrow! https://github.com/archlinux/arch-install-scripts This is a great opportunity for new people to get involved with some Arch project development :) The only requirement is to not be afraid to dive into bash/ash scripts. Join `#archlinux-projects` on the libera.chat network or through matrix if you are interested :)! -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

git 2.38.0: Change in `git archive` output
by kpcyrd 16 Oct '22

16 Oct '22

hello, multiple people in Arch Linux noticed the output of our `git archive` command doesn't match the tarball served by github anymore. First I suspected an update in our gzip package until I found this line in the git 2.38.0 release notes: > * Teach "git archive" to (optionally and then by default) avoid > spawning an external "gzip" process when creating ".tar.gz" (and > ".tgz") archives. I've then found this commit that could be considered a breaking change in `git archive`: https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710 I don't know if there's some kind of gzip standard that could be used to align the git internal gzip implementation with gnu gzip. I'm not saying this is necessarily a bug or regression but it makes it harder to reproduce github tar balls from a git repository. Just sharing what I've debugged. :) cheers, kpcyrd

1 0

Public release: updlockfiles 0.1.0
by kpcyrd 16 Oct '22

16 Oct '22

ohai! I released a new tool called updlockfiles that attempts to help manage dependency lockfiles like Cargo.lock, composer.lock, go.mod and friends. Hopefully this helps with reproducible builds in Arch Linux, but also if you want to manage your own downstream lockfile to override vulnerable dependencies. Announcement blog post: https://vulns.xyz/2022/10/updlockfiles/ Repository: https://github.com/kpcyrd/updlockfiles cheers, kpcyrd

1 0

Arch Linux software projects: Request for participation
by David Runge 16 Oct '22

16 Oct '22

Hi all, we have recently cleaned up parts of the developer wiki a bit and moved the list of internal projects to a more prominent location: https://wiki.archlinux.org/title/Getting_involved#Software_projects As you can see, we have quite a few projects and some of them would be happy about more participation from members of the Arch Linux staff as well as users. Help in fixing and extending the software is much appreciated, but testing and opening tickets that describe flaws or usability problems are equally important! If you are familiar with writing documentation, Ash, Bash, C, JavaScript, Python, or Rust and always wanted to get involved with one of the Arch Linux projects: Look no further! :) As mentioned in the wiki, we have a central mailing list [1] and IRC channel [2] for discussing most of the projects (unless they provide other means of communication). We hope to spark people's enthusiasm, as healthy projects ensure a flexible distribution and allow us to tackle larger goals (e.g. move to a git based workflow for packaging, effortlessly providing several architectures, automating our infrastructure and releases, etc.). Best, David [1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.or… [2] ircs://irc.libera.chat/archlinux-projects -- https://sleepmap.de

1 0