On Sat, Aug 15, 2020 at 9:47 AM Fabio Valentini decathorpe@gmail.com wrote:
On Sat, Aug 15, 2020 at 5:30 PM Paul Howarth paul@city-fan.org wrote:
On Sat, 15 Aug 2020 16:28:47 +0200 Fabio Valentini decathorpe@gmail.com wrote:
- autoreconf fails because %build needs a newer shell (protobuf):
/usr/bin/autoconf: This script requires a shell more modern than all /usr/bin/autoconf: the shells that I found on your system. /usr/bin/autoconf: Please tell bug-autoconf@gnu.org about your system, /usr/bin/autoconf: including any error possibly output before this /usr/bin/autoconf: message. Then install a modern shell, or manually run /usr/bin/autoconf: the script under such a shell if you do have one. autoreconf: /usr/bin/autoconf failed with exit status: 1
- shell not executing stuff in backticks `command foo` but returns
empty string (tonto): `build-classpath foo` # this doesn't work?
I'm getting the sinking feeling that RPM scriptlets are broken? Do they get run in the wrong shell? sh instead of bash maybe?
I'm grasping at straws here, but all those build failures are starting to be really disruptive to the work that I'm actually trying to do ...
I had an issue with a configure script wanting a more modern shell. I tried running mock with --isolation-simple and it stopped complaining. Maybe that would help you too?
Paul.
It does! Running mock with --isolation=simple works around the issue. Looks like the glibc 2.32.9000 snapshot broke systemd-nspawn based chroots with this change:
- Linux: Use faccessat2 to implement faccessat (bug 18683)
Anyone know if Anaconda chroots are nspawn based? I ask because I'm tracking a bug that only happens when a qemu-kvm VM uses io=io_uring instead of threads; but consistently it isn't triggered until the installation transitions from rsync phase to the chroot phase. Once in the chroot, it implodes. Could be entirely unrelated things but... :D