Megver83 wrote:

Try building linux-libre from another one and delete parabola-i686.

yes, that is always a last resort option - i have needed to destroy the chroot a few times lately - and not only the working chroot, but the entire read-only replica like:

  # librechroot -n default delete
  # librechroot -n i686 delete
  # rn -rf /var/lib/archbuild/default
  # rn -rf /var/lib/archbuild/i686

I've tried again with linux-libre and I've the same issue:

 |    DEPMOD  4.20.6-gnu-1
 |    -> Installing hooks...
 |  /startdir/PKGBUILD: line 466: /startdir/linux.install.pkg: Read-only file system
 |  ==> ERROR: A failure occurred in package_linux-libre().
 |      Aborting...
==> Copying log and package files out of the chroot...

I didn't rebuild the chroot since my last try yesterday with linux-libre_x86-64 though.

this behavior is a more general problem, and can also be observed when building any package that relies on the pkgver() function to update the PKGBUILD. it appears that for some reason, the build processes in the chroot have lost write permissions to the files in /startdir.

this might be a recent change to our build toolchain, I distinctly remember this working before.

• once with makepkg so it updates the PKGBUILD
• once with libremakepkg after having updated the PKGBUILD

• Add a function to makepkg so it would update the PKGBUILD?
• Enable the chroot to modify the PKGBUILD and copy it back to the directory in abslibre?
• don't care about the changes made to PKGBUILD or other files in abslibre?

bill-auger: No, that PKGBUILD doesn't work -- the install= must be global OR in the package() function. Furthermore, makepkg installs it relative to $startdir, not $srcdir -- so you can declare it during package to ./hello.install, but when makepkg reads it, it sees it as "$startdir/./hello.install", so you're still using the unmodified version.

And if you try using install="${srcdir}/hello.install", makepkg will error out because it is not permitted to use an install file that isn't in startdir.

There's really only one solution, and that is, use a read/write mounted startdir. This fixes both the linux packages which modify the install file, and packages which use pkgver() and modify the PKGBUILD.

eli was referring to my suggestion of including the the install hook file in the sources() array then modifying it the prepare() stage - i deleted the suggestion at the same time eli was commenting, because it does not actually work

the log message for the commit that introduced this change indicates that it was necessary for some reason - i think it would be hasty to revert this until we know what the trade-off would be

"- We mount the temporary directory containing the extracted source package files read-only,
     to be sure that makepkg doesn't modify the PKGBUILD. This is necessary because
     --holdver only disables pkgver() if it's a VCS package."

right now, i think the only packages that are broken by this are the kernels - there is a single command that requires a writable /startdir, and it does not appear to have any value whatsoever - all that it does is write the 'pkgbase' into the .install script - 'pkgbase' will never change, so that could be hard-coded into the .install script anyways

megver says he did not see this problem because his chroots use openrc/nonsystemd - apparently the read-only mount only relates to systemd-nspawn - dunno if that is a bug or a feature

bill-auger wrote:

megver says he did not see this problem because his chroots use openrc/nonsystemd - apparently the read-only mount only relates to systemd-nspawn - dunno if that is a bug or a feature

I'm using https://www.parabola.nu/packages/nonsystemd/x86_64/libretools/ to build packages. Yesterday I built linux-libre-hardened and -pae successfully without having to do any extra arrangements. So please, do not (yet) do things like this (or at least with kernels)

i made that change mainly to make the point clear that it served no purpose - it was a code smell - the only effect of reverting that change now, would be to make the package not able to build with the standard tools - anything like that is an indication that something is not well thought out and should be discussed

maybe that is how arch does it, but the goal of staying close to arch, does not mean we need to do any useless things they do - the change that broke these packages was already a deviation from arch, and a more drastic one - this change is completely benign - even if we reverted the change that made the /startdir read-only as gnutoo suggested, there would still be no justification for reverting this change - it is more of a curiosity why that ugly hack was there in the first place

It's not an ugly hack. It is a curious appendage designed to be useful in the sole case where some user wants to create a custom kernel.

Your "(NOTE: hard-coded into linux.install)" is quite missing the point of why any of that exists in the libre/linux-libre or upstream core/linux PKGBUILDs at all -- it is now no longer possible to simply change the pkgbase and generate a forked custom kernel, so you should either revert the change, or do one better and strip out the rest of the workarounds intended solely for custom kernel derivations.

i wonder if thats why i could not publish the first kernels i built - i originally did change the pkgbase intentionally, so that i would not replace any existing kernels; but the packages were rejected with "this package was not built in a chroot"

maybe that was not related, im not sure - it was confusing and i was in a rush, and i tried several crazy hacks to get it out; but that was the original reason i pushed the changes i made to the PKGBUILDs

i noticed that libremakepkg has options to control mounting ro or
rw - maybe that was intended to be the solution all along

-w <PATH[:INSIDE_PATH[:OPTIONS]]>     Bind mount a file or
directory, read/write
-r <PATH[:INSIDE_PATH[:OPTIONS]]>     Bind mount a file or
directory, read-only

There is a real issue where pkgver() isn't getting evaluated before the sourceball is created, which then causes problems with the read-only $startdir. But: the PKGBUILD should be doing it's work in $srcdir, not $startdir.

However, I would tend to be of the opinion that "work" should happen in $srcdir. Would using an absolute path to the modified script not work?

  sed "$subst" "$startdir/$install" > "$srcdir/$install.pkg" 
  true && install=$srcdir/$install.pkg

no i tried that - see eli's comment # 14 https://labs.parabola.nu/issues/2141#note-14

gnutoo reverted the change that originally spurred this BR with a temporary patch in abslibre

https://git.parabola.nu/abslibre.git/tree/libre/libretools/0001-libremakepkg-rw-startdir.patch

Several packages require a read-write startdir:
- Some packages have a pkgver that is computed dynamically through a pkgver function. This is the case for many packages using git repositories. At the end of the package build, the pkgver is automatically updated in the PKGBUILD, however, without that fix that fails with libremakepkg as the PKGBUILD was set read-only.
- Some packages like linux-libre are modifying the install= script. This is done by creating a temporary install script in the startdir that is then modified with sed. Once this is done that install script is then dynamically selected. As this also require to have read-write access to the startdir to be read-write it fails to build the package if it's not the case.

In both cases it's possible to modify the PKGBUILDs to workaround the issue, however the Arch Linux distribution has a read-write startdir, and modifying each affected packages would significatively increase the cost (in time and efforts) of maintaining Parabola.

there has not been any problems with that yet, although lukeshu indicated that problem that the change was intended to solve will turn up someday - maybe this issue is fixed? - only time will tell :)

A few things

• The rationale for mksource() being separate from prepare() is that sourceballs should never contain nonfree code--if they do, then we're distributing nonfree code, which FSDG says we're not allowed to do (even if our PKGBUILD build script immediately deletes it).

• I generally think that it's a bug if a package needs to write to $startdir. In every instance I've seen, it either makes it so that the same package can't be rebuilt from the sourceball we publish (bad!), or is accommodating using date instead of git tags/hashes. That said, I recognize that we only have finite hours in the day, and that it may not be feasible to fix all such packages.

So, in v20240221, I've adjusted it to mount $startdir read-only by default, but added a -W flag as an escape hatch, the same as we have the -N escape hatch for networking. https://git.parabola.nu/packages/libretools.git/commit/?id=63d3993a320ee03c20da05d0e04ddbd3cc800335

thats a fine solution - as i remember the original debate, there was only one package that used a trick like that - it was linux-libre IIRC and IIRC it does not do that anymore - so since some years ago, AFAIK there are not PKGBUILDs which would make use of a writable startdir anyways - so the CLI option is great (for emergency use only)

just as a side note, it is a similar/parallel situation to the -N option - AFAIK, the keyring package was the only one which required the -N option; and i changed that - so it is also reserved now only for emergency use