On Sat, Aug 15, 2020 at 9:47 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Sat, Aug 15, 2020 at 5:30 PM Paul Howarth <paul(a)city-fan.org> wrote:
>
> On Sat, 15 Aug 2020 16:28:47 +0200
> Fabio Valentini <decathorpe(a)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(a)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
--
Chris Murphy