systemd stopped building on rawhide


systemd rawhide builds started failing in koji [1]:

In file included from src/shared/firewall-util.c:23:0:
/usr/include/linux/if.h:71:2: error: redeclaration of enumerator 'IFF_UP'
IFF_UP = 1<<0, /* sysfs */
/usr/include/net/if.h:44:5: note: previous definition of 'IFF_UP' was here
IFF_UP = 0x1, /* Interface is up. */
/usr/include/linux/if.h:72:2: error: redeclaration of enumerator 'IFF_BROADCAST'
IFF_BROADCAST = 1<<1, /* __volatile__ */
/usr/include/net/if.h:46:5: note: previous definition of 'IFF_BROADCAST' was here
IFF_BROADCAST = 0x2, /* Broadcast address valid. */

$ rpm -qf /usr/include/linux/if.h /usr/include/net/if.h

Have there been any changes to these packages in regards to the include files?

[1] <a href="" title=""></a>



Re: systemd stopped building on rawhide

By Jan Synacek at 02/09/2016 - 04:22

Jan Synáček < ... at redhat dot com> writes:

Also note that systemd failed during the mass rebuild because of the
same problem, which is really sad. What is even more sad is the line
that has been added into the changelog. It says "Rebuilt for <f24>",
which is simply not true.

Re: systemd stopped building on rawhide

By Peter Robinson at 02/09/2016 - 04:26

Funnily enough the change log is added before it's checked in to git
so currently is not true but when the problem is fixed, as it has to
be, it will be true. Right or wrong adding the changelog is the in
spec file happens before the build.

Re: systemd stopped building on rawhide

By Matthew Miller at 02/09/2016 - 04:30

On Tue, Feb 09, 2016 at 08:26:16AM +0000, Peter Robinson wrote:
I guess we could change the message to "Update spec file for mass
rebuild" or something. But it doesn't seem very important to me.

Re: systemd stopped building on rawhide

By Lennart Poettering at 02/02/2016 - 07:49

Can't say I am surprised by this. THe kernel header linux/if.h is really messy
here and conflicts with glibc's net/if.h header. It's really fragile,
and unless you pull them in a very specific order won't work.

In systemd we ended up replicating quite a bit of these headers so
that we can safely include them, but this doesn't help if the kernel
and glibc API conflict lines change...

I figure the glibc and kernel uapi folks really should figure out who
provides which API so that one can actually use them without
headaches. And other than that it would already be a good start to at
least not break the API so that the fragile inclusion order based
work-around we have in userspace tools doesn't break...