Re: Standardize on running autoreconf in prepare()
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 signature.asc Description: PGP signature
Re: Standardize on running autoreconf in prepare()
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/riscv64.patch +1 signature.asc Description: PGP signature
Re: Standardize on running autoreconf in prepare()
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/riscv64.patch + 1 from me too. -- Tobias Powalowski Arch Linux Developer (tpowa) https://www.archlinux.org tp...@archlinux.org Archboot Developer https://archboot.com St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de i...@st-martin-apo.de
Re: Standardize on running autoreconf in prepare()
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.html#index-AC_005fCONFIG_005fMACRO_005fDIR-1 [2] https://github.com/notroj/neon/pull/153/files signature.asc Description: This is a digitally signed message part
