Bug 868409

Created attachment 630216 [details]
Mock root log for SSSD

Hi,

any updates here? This is effectively blocking us from building new SSSD builds in rawhide. I'd have to disable the libnl support to work around the bug.

The easiest thing here would be to add a small patch to the libnl-1 patch that removes the redefinition from the netlink-kernel.h file and add a build dependency requiring the new kernel that fails.

reassigning to libnl per tgr's comment #3

So, basically libnl-1.1 is really old.  I mean, upstream libnl is already on 3.2.10.  Maybe it should be updated.

Anyway, here is what is happening:

The uapi rework moved the userspace portions of <linux/netlink.h> under a new header guard:

#ifndef _UAPI__LINUX_NETLINK_H
#define _UAPI__LINUX_NETLINK_H

That is literally the only difference:

[jwboyer@zod kernel]$ diff -Nup /usr/include/linux/netlink.h netlink.h 
--- /usr/include/linux/netlink.h	2012-10-08 13:41:19.000000000 -0400
+++ netlink.h	2012-10-30 09:53:52.264784878 -0400
@@ -1,5 +1,5 @@
-#ifndef __LINUX_NETLINK_H
-#define __LINUX_NETLINK_H
+#ifndef _UAPI__LINUX_NETLINK_H
+#define _UAPI__LINUX_NETLINK_H
 
 #include <linux/socket.h> /* for __kernel_sa_family_t */
 #include <linux/types.h>
@@ -150,4 +150,4 @@ struct nlattr {
 #define NLA_HDRLEN		((int) NLA_ALIGN(sizeof(struct nlattr)))
 
 
-#endif	/* __LINUX_NETLINK_H */
+#endif /* _UAPI__LINUX_NETLINK_H */

Now, libnl-1.1 seems to want to be clever and it provides /usr/include/netlink/netlink-kernel.h which seems to be some kind of stale copy of the in-kernel header.  Why it does this, I have no idea.  Probably because it's old.

Because of the header guard change, it seems to be getting these redefinition errors.  There really isn't much to be done here except to either patch the libnl netlink-kernel.h file for the new guard, or patch the kernel.  We're not going to patch the kernel.

It should be noted that libnl stopped using netlink/netlink-kernel.h 2 years ago with this commit:

https://github.com/tgraf/libnl/commit/82fe78582045d29d3b9a5bd2f5b233814bd23c23

This boils down to an old package carrying around a stale copy of in-kernel headers.  It should be fixed in that package.

(In reply to comment #3)
> The easiest thing here would be to add a small patch to the libnl-1 patch
> that removes the redefinition from the netlink-kernel.h file and add a build
> dependency requiring the new kernel that fails.

Seems we had a mid-air collision :).

Easiest, sure.  I don't see why libnl can't be updated in rawhide though.

(In reply to comment #5)
> So, basically libnl-1.1 is really old.  I mean, upstream libnl is already on
> 3.2.10.  Maybe it should be updated.

Except the APIs are not compatible, so there needs to be a -compat package to allow packages that use libnl (such as the SSSD) to transition.

(In reply to comment #5)
> Now, libnl-1.1 seems to want to be clever and it provides
> /usr/include/netlink/netlink-kernel.h which seems to be some kind of stale
> copy of the in-kernel header.  Why it does this, I have no idea.  Probably
> because it's old.

Because back then it was the proper way to do it because the kernel headers provided by user space differed for almost every distribution.

> Because of the header guard change, it seems to be getting these
> redefinition errors.  There really isn't much to be done here except to
> either patch the libnl netlink-kernel.h file for the new guard, or patch the
> kernel.  We're not going to patch the kernel.

Fixing the libnl1 package is definitely the correct thing to do. Simply get rid of netlink-kernel.h. Relying on linux/netlink.h is fine now.

> It should be noted that libnl stopped using netlink/netlink-kernel.h 2 years
> ago with this commit:
> 
> https://github.com/tgraf/libnl/commit/
> 82fe78582045d29d3b9a5bd2f5b233814bd23c23
> 
> This boils down to an old package carrying around a stale copy of in-kernel
> headers.  It should be fixed in that package.

It's true that libnl3 no longer uses netlink-kernel.h but libnl 1.1 still does and since libnl 1.1 is no longer maintained it will not be fixed upstream.

I suggest to add a small patch to remove the stale header copies and use the new UAPI headers.

(In reply to comment #7)
> (In reply to comment #5)
> > So, basically libnl-1.1 is really old.  I mean, upstream libnl is already on
> > 3.2.10.  Maybe it should be updated.
> 
> Except the APIs are not compatible, so there needs to be a -compat package
> to allow packages that use libnl (such as the SSSD) to transition.

libnl3 is already in Fedora so we can just remove libnl1 as soon as all dependencies have been removed.

It's really not a good idea to still use libnl1, it is no longer maintained and does not see any bugfixes and I have little interest to do so, especially because converting code from libnl1 to libnl3 is usually a relatively simple task.

Part of the reason that SSSD hasn't made the switch to libnl3 is that it needs to support RHEL5 and RHEL6 as well as Fedora. Neither of those OSes currently support libnl3 (and won't ever). So it's a fair amount of ifdefs to get things working and up until now there was no real reason to make the effort.

(In reply to comment #9)
> It's really not a good idea to still use libnl1, it is no longer maintained
> and does not see any bugfixes and I have little interest to do so,
> especially because converting code from libnl1 to libnl3 is usually a
> relatively simple task.

Not that I disagree with the general message, but I really think that when an incompatible library is introduced to Fedora, there should be
a) a loud announcement on the -devel (or one of the announce) lists
b) a compat package to ease the migration path

Providing these two might speed up the migration to libnl3 as it makes clear to the maintainer that libnl1 is no longer a viable option.

(In reply to comment #10)
> Part of the reason that SSSD hasn't made the switch to libnl3 is that it
> needs to support RHEL5 and RHEL6 as well as Fedora. Neither of those OSes
> currently support libnl3 (and won't ever). So it's a fair amount of ifdefs
> to get things working and up until now there was no real reason to make the
> effort.

Understood but I don't see a reason why RHEL5 and RHEL6 can't be shipping libnl3 as well. Both versions of the library can be installed in parallel. Obviously applications can't link to both version at the same time but that seems like a manageable problem. Not sure why you rule out this possibility.

(In reply to comment #11)
> Not that I disagree with the general message, but I really think that when
> an incompatible library is introduced to Fedora, there should be
> a) a loud announcement on the -devel (or one of the announce) lists

Sure, no objection to that.

> b) a compat package to ease the migration path
> 
> Providing these two might speed up the migration to libnl3 as it makes clear
> to the maintainer that libnl1 is no longer a viable option.

What would a compat package gain us that keeping libnl1 around as long as needed can't? All I can see is that it brings libnl3 bugfixes to libnl1 users which gives them one more reason to postpone the switch again.

(In reply to comment #12)
> > 
> > Providing these two might speed up the migration to libnl3 as it makes clear
> > to the maintainer that libnl1 is no longer a viable option.
> 
> What would a compat package gain us that keeping libnl1 around as long as
> needed can't? All I can see is that it brings libnl3 bugfixes to libnl1
> users which gives them one more reason to postpone the switch again.

Well, the above announcement could have said that the -compat package would only be maintained for a single Fedora release lifetime, giving it a limited and definitive TTL :-)

Also, if a package suddendly starts requiring a -compat package instead of a "regular" version, that's usually a sign that a change needs to be made.

That said, I've bumped the ticket that was tracking the conversion to libnl3 in the SSSD to be discussed again on our weekly triage meeting.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days