Re: build failures on rawhide [PATCH]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 21, 2014 at 11:10:54AM -0500, Jerry Vonau wrote:
> > On August 21, 2014 at 9:21 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> > On Thu, 21 Aug 2014 04:09:02 +0200
> > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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..
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux