With the release to PHP 8.2 I will introduce a new set of packages to
solve most of the issues with PHP updates. There are two valid
requirements: On one hand people need the latest version to use its
features or to develop new applications. And on the other hand users
want to run third party applications that might not yet be compatible
with the latest PHP runtime. I'll make the following changes to
support both use cases while still keeping the rolling release model:
The php package we already provide will be updated to 8.2 and be kept
up-to-date with the latest upstream releases. php7 packages will be
removed as this version is end-of-life and will no longer receive
security updates.
A new set of php-legacy packages will be introduced which always
provide the oldest version actively supported by upstream*. This
version is usually one year behind the latest release, but still
receives bug and security fixes. It will be possible to install and
use this version alongside the latest php packages. The binaries and
configuration path will have a suffix named "-legacy", which will
require configuration changes if you want to switch between legacy and
non-legacy versions. In contrast to e.g. the php7 package, this
version will also follow a rolling release model and will receive
minor and even major updates.
In the end this would result in the following release schedule:
php:
currently 8.1
soon 8.2
December 2023: 8.3
php-legacy:
currently: 8.1
December 2023: 8.2 (upstream provides security updates till
December 2024; so we have some room to postpone when issues arise.)
I will provide a news item once all these changes are ready for the
stable repositories.
For packaging:
I'll take care of the module rebuilds. Most modules are already
compatible or at least have patches. Similar to php7 I'll make use of
split packages to build a module for both PHP branches. One exception
is the uwsgi plugin which is known for being a less active project.
For now it would only be possible to provide it for php-legacy.
Application packages might use the virtual php-interpreter dependency
which provides the minor version. As stated above switching between
legacy and non-legacy versions will require user interaction. For some
packages that are known for almost never being compatible with latest
PHP versions, it might be easier to depend on php-legay right away.
Greetings,
Pierre
*) https://www.php.net/supported-versions.php
--
Pierre Schmitz, https://pierre-schmitz.com
Yo!
With the release of pacman 6.0.2 we have now support for debug packages through
`debugedit` as opposed to the awk hack used previously.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1
This should resolve several issues we have had with the existing debug packages
and I want people to test this support.
Please recreate your build chroots and/or reinstall base-devel locally. Enable
debug in a diverse set of packages you maintain. And help validate the current
assumptions:
* Debug packages for Rust, Go* and Julia should work
* Weird /build directories should not exist
* We should have header files
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
You can list them easily with `bsdtar -tf *.pkg.tar.zst`
Note pacman is currently in [testing].
In the case for Go we need to disable compressed dwarf headers with `-ldflags=-compressdwarf=false`.
It should be the case for any binaries with these headers as well. They can be
recognized with the weird "DWARF version 0 unhandled" error string during
stripping.
Please report back if things look good, or you are looking at weird debug
package structures :)
If everything looks fine I intend to write an RFC for blanket enabling debug
packages in devtools!
--
Morten Linderud
PGP: 9C02FF419FECBE16
Hello all!
I've opened an RFC for transitioning the license field in PKGBUILDs from our existing format to the SPDX license expression specification. This is my first RFC, and I want to thank Foxboron for his help with the process so far. You can find the MR here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16
Please visit the above link for discussion.
Best,
Campbell
Yo,
Arch has been hosting a patchwork instance for many years and the time has come
to retire this service. Most project has been moving to Gitlab, with pacman
moving at the end of this year, and there is no real use for this anymore to my
knowledge.
https://patchwork.archlinux.org/
Project maintainers should take a look over the projects and collect up any
patch links they want to work on in the future. I have posted a small script on
the pacman issue if people want to pull old patches from the mailing list.
https://gitlab.archlinux.org/pacman/pacman/-/issues/1#note_83181
The EOL date is 1st of January 2023.
We will probably make a static archive of patchwork as a backup incase we need
it, but this probably won't be hosted anywhere.
https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/487
--
Morten Linderud
PGP: 9C02FF419FECBE16
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…
The older Arch developers may remember vaguely how Arch has introduced
[1] and migrated to systemd [2] becoming the new and only supported init
system. Back in these days we had some developers in our team being part
of upstream systemd developers. Not much discussion happened about
supporting any alternative init system. Other alternative init systems
have become niche in Arch and faded out over time.
Nowadays systemd has become much more than a plain init system
and plans to grow further. This may leadd to problems from a user and
system administrator perspective once you are hit by some bug. Systemd
as a whole thing doesn't care about the Unix philosophy to do only one
thing but well.
Many and often highly skilled users left and leave Arch therefor or
choose some different distribution or an Arch fork because there's no
init choice in Arch Linux.
I suggest to fix this lack of init choice/alternative. I'd like to
implement it into the official Arch Linux repos allowing to choose
some different init replacement. We can either just add a 2nd init
system in the most simple way or allow real init-freedom[3] offering
full choice and leave it up to be further filled by the community.
Arch Linux could take advantage of this bringing back some lost parts
of the community. With more choice and better portability Arch could
become a better base for porting to new architectures. And freedom and
alternatives is always good in the open source world. The clear
drawback would become some added complexity allowing to choose either
systemd or its replacement parts and to make all of them to work with
existing packages especially daemon services.
I'm willing to do most of the packaging implementations when a majority
of the team think it's good idea and worth the effort. It's a rather
huge effort and imho not a task for some personal custom repo as it may
affect devtools, infrastructure and maybe more of our core distro.
If you want to check how some init choice can be implemented I suggest
to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks
first. These are all rather small projects but we being the mother and
true Arch community should have the resources to implement it in a
proper way without any major drawbacks.
PS: Please leave out all emotions about hating or loving systemd. I'm
trying to do so as well.
-Andy
[1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux…
[2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux…
[3]https://www.devuan.org/os/init-freedom
[4]https://wiki.parabola.nu/Repositories#nonsystemd
[5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial
[6]https://wiki.artixlinux.org/Main/Installation
[6]
While preparing updates to our PHP packages I think it's now time to
retire the abandoned imap package:
https://archlinux.org/packages/extra/x86_64/imap/
The last upstream version was from 2007 and the upstream website is
gone for many years now. I doubt anyone actually uses the imap server;
its main use is probably to compile the php-imap extension (which also
might get removed by upstream in the future). Redhat and Fedora
removed the library last year. Therefore I'd like to remove imap,
c-client and php-imap. php-imap is currently optionally required by
nextcloud and postfixadmin; likely to authenticate against a third
party IMAP server.
Greetings,
Pierre
--
Pierre Schmitz, https://pierre-schmitz.com
Hi Jelle, (also forwarding to dev-public)
definitely yes, OpenSSL 3.0 is on my wish list! :-)
I did not want to jump on it at day one though. Even the last minor
updates were quite painful and we still have packages requiring
version 1.0 and are still not compatible with 1.1.
While they claim that most packages should work with a recompile, it
would be nice to actually know which packages are not compatible. This
should help whether we need another compatibility package are would be
able to just replace openssl 1.1 with version 3.
I know about foutrelis' awesome rebuilder script, but I wonder if we
have something similar that I just could run for half a day to get an
idea which package would break and which wont? Like a dry run that
wont commit anything. If no such thing exists yet, I might have a look
myself.
Greetings,
Pierre
On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote:
>
> Hi Pierre,
>
> Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens
> to have already started.
>
> https://fedoraproject.org/wiki/Changes/OpenSSL3.0
>
> Greetings,
>
> Jelle
--
Pierre Schmitz, https://pierre-schmitz.com
I have noticed freswa has bumped BerkeleyDB to
v6 (again) and started pushing rebuilds to staging repo.
Arch Linux had made this update already in August 2013 and
discussions lead us to revert this back quickly:
https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…
Here you can find some thoughts why 3rd party applications may not be
legally compatible to use the AGPLv3 licensed BDB v6:
https://lwn.net/Articles/557820/https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
It's pretty questionable if someone is allowed to build and
redistribute packages against the newly AGPLv3 licensed BDB version
without checking and probably changing related application licenses.
But I'm not a lawyer. Most major Linux distributions still stick with
BDB v5 therefore. So we did back then in 2013 until now. Some
distributions have added v6 along v5 and only use it carefully when
upstream projects declare their license AGPLv3 compatible to be usable
with later BDB versions.
Two major concerns I have here:
1) No public discussion happened here or somewhere else before such a
major change. The packager will have known there's something special
with such a long flagged package in core. All major changes affecting
the core repo should really go through some discussion before they
happen.
2) I've immediately raised my concerns pinging freswa at IRC and only
see today the rebuilds went ahead and keep going on.
That's not how our team should deal such maybe critical step. I don't
want to imagine Arch spending all funded money for some curt fights we
could easily avoid here.
Please start some public discussion why this change happened and why
the concerns of other distributions and our own developers are not
worth to take a small break to think about it again.
-Andy