build failures on rawhide [PATCH]

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Fri Aug 22 02:24:29 UTC 2014


On Thu, Aug 21, 2014 at 11:10:54AM -0500, Jerry Vonau wrote:
> > On August 21, 2014 at 9:21 AM Kevin Fenzi <kevin at scrye.com> wrote:
> > On Thu, 21 Aug 2014 04:09:02 +0200
> > Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> wrote:
> >
> > > On Wed, Aug 20, 2014 at 08:33:55PM -0500, Jerry Vonau wrote:
> > > > Hi All:
> > > >
> > > > I'd like to point out that there are images/livecd's that are
> > > > failing to build for rawhide[1]. With the change
> > > > in /etc/resolv.conf handling the builds are now failing with
> > > > "IOError: [Errno 2] No such file or directory:
> > > > '/var/tmp/imgcreate-ChCMoB/install_root/etc/resolv.conf'" Looking
> > > > the code in python-ingcreate[3] it appears that /etc/resolv.conf is
> > > > opened, permissions changed, then closed. Think the sequence should
> > > > be open, close, change permissions, or can that block of code go
> > > > away? At any rate patch to reverse the order.
> > > >
> > > > diff --git a/imgcreate/kickstart.py b/imgcreate/kickstart.py
> > > > index aef3ef2..b87fd59 100644
> > > > --- a/imgcreate/kickstart.py
> > > > +++ b/imgcreate/kickstart.py
> > > > @@ -441,8 +441,8 @@ class SelinuxConfig(KickstartConfig):
> > > >          for fn in ("/etc/resolv.conf",):
> > > >              path = self.path(fn)
> > > >              f = file(path, "w+")
> > > > -            os.chmod(path, 0644)
> > > >              f.close()
> > > > +            os.chmod(path, 0644)
> > > The order does not matter here.
> >
> > These failures sound like perhaps
> > https://bugzilla.redhat.com/show_bug.cgi?id=1116651
> > again?
Most likely.

> > Did the revert for f21 get re-enabled in rawhide?
Yes, it got disabled when systemd-216 was uploaded.

I'll reapply the patch for now, since we have bigger fish to fry before
the release, but it would be great to sort this out at some point.
(Actually the patch was mostly broken, because systemd-resolved runs
unprivileged, so creating a symlink in /etc obviously fails... So I
dropped the part to create the symlink, and the patch now only removes
the tmpfiles lines to create the symlink. This means that the symlink
has to be created by hand which I guess is a lesser evil.)

Zbyszek

> If /etc/resolv.conf is now a symlink, should the above block of code go
> away altogether?
> That is what seems to be holding up the builds..


More information about the devel mailing list