Standardize on running autoreconf in prepare()
Hi All, After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V. Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream. Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports. As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc. [1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/...
On 25/02/26 09:53PM, Jelle van der Waa wrote:
Hi All,
Heyhey,
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
Sounds like a good idea, +1 from me!
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
[1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/...
Cheers, chris
On 2/26/25 11:53 PM, gromit wrote:
On 25/02/26 09:53PM, Jelle van der Waa wrote:
Hi All,
Heyhey,
Hey
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
Sounds like a good idea, +1 from me!
Sounds like a good one to me as well, +1
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
[1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/...
Cheers, chris
-- Regards, Robin Candau / Antiz
+1 from me Doing the `autoreconf -fiv` dance in basically all of my packages for quite a while. We should standardize this. Every now and then some upstreams can't be easily regenerated, but imo this is arguably an upstream bug that should be resolved. Cheers Levente
On 2025-02-26 21:53:50 (+0100), Jelle van der Waa wrote:
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Yes, this is generally a good idea and usually works withouot issue. Exceptions can't easily be detected though as we currently expect base-devel to be installed and not autotools specifically. However, they usually include: - projects with ancient and custom autotools (looking at you ncurses 👀) - projects where `configure` is actually not autotools (looking at you qemu 👀)
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
That's also what RFC0046[1] is about in consequence. When not relying on custom source tarballs, autoreconf (or some custom bootstrap script like autogen.sh) usually must be run.
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
That would also be great and I think should be developed and maintained by us in a dedicated project, together with the custom `arch-meson` and any future cmake presets[2]. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46 [2] https://gitlab.archlinux.org/archlinux/ideas/-/issues/15 -- https://sleepmap.de
On Wed, Feb 26, 2025 at 09:53:50PM +0100, Jelle van der Waa wrote:
Hi All,
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
[1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/...
+1
Am 26.02.25 um 21:53 schrieb Jelle van der Waa:
Hi All,
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
[1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/...
+ 1 from me too. -- Tobias Powalowski Arch Linux Developer (tpowa) https://www.archlinux.org tpowa@archlinux.org Archboot Developer https://archboot.com St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info@st-martin-apo.de
On Wed, 2025-02-26 at 21:53 +0100, Jelle van der Waa wrote:
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
+1 If autoreconf fails, then it's usually due to missing m4 macros, which indicates either a missing makedependency which contains that macro, or a custom directory needs to be specified by the AC_CONFIG_MACRO_DIR variable [1] within configure.ac which can be fixed by a one-line patch. [2] [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/Input.h... [2] https://github.com/notroj/neon/pull/153/files
participants (8)
-
Balló György
-
David Runge
-
Frederik Schwan
-
gromit
-
Jelle van der Waa
-
Levente Polyak
-
Robin Candau
-
Tobias Powalowski