xattr.h wonkiness
Hi, would a simple patchl ike this to misc/sys/xattr.h be
acceptable? This showed up in a failure to build (of at least
qemu, and aiui lots of other pkgs) after merging a new libcap2
where sys/capability.h #included linux/xattr.h. It's being
worked around by patching libcap2 to #include sys/xattr.h
first, but presumably this will cause other breakages.
thanks,
-serge
=
diff -Nru eglibc-2.19/debian/changelog eglibc-2.19/debian/changelog
--- eglibc-2.19/debian/changelog2014-02-21 07:09:22.0 +
+++ eglibc-2.19/debian/changelog2014-02-21 23:33:08.0 +
@@ -1,3 +1,10 @@
+eglibc (2.19-0ubuntu2) trusty; urgency=medium
+
+ * debian/patches/dont-redefine-xattr: fix compilations where linux/xattr.h
+ends up included before sys/xattr.h.
+
+ -- Serge Hallyn Fri, 21 Feb 2014 23:31:58 +
+
eglibc (2.19-0ubuntu1) trusty; urgency=medium
* Merge with unreleased 2.19 from Debian experimental, remaining changes:
diff -Nru eglibc-2.19/debian/patches/dont-redefine-xattr
eglibc-2.19/debian/patches/dont-redefine-xattr
--- eglibc-2.19/debian/patches/dont-redefine-xattr 1970-01-01
00:00:00.0 +
+++ eglibc-2.19/debian/patches/dont-redefine-xattr 2014-02-21
23:31:53.0 +
@@ -0,0 +1,25 @@
+Description: don't define XATTR_CREATE in an enum if it is already defined
+ Otherwise if linux/xattr.h gets included before sys/xattr.h, compilation
+ will fail.
+Author: Serge Hallyn
+
+Index: eglibc-2.19/misc/sys/xattr.h
+===
+--- eglibc-2.19.orig/misc/sys/xattr.h 2014-01-03 17:51:28.0 +
eglibc-2.19/misc/sys/xattr.h 2014-02-21 23:29:43.141367811 +
+@@ -26,6 +26,7 @@
+
+ /* The following constants should be used for the fifth parameter of
+`*setxattr'. */
++#ifndef XATTR_CREATE
+ enum
+ {
+ XATTR_CREATE = 1, /* set value, fail if attr already exists. */
+@@ -33,6 +34,7 @@
+ XATTR_REPLACE = 2 /* set value, fail if attr does not exist. */
+ #define XATTR_REPLACE XATTR_REPLACE
+ };
++#endif
+
+ /* Set the attribute NAME of the file pointed to by PATH to VALUE (which
+is SIZE bytes long). Return 0 on success, -1 for errors. */
diff -Nru eglibc-2.19/debian/patches/series eglibc-2.19/debian/patches/series
--- eglibc-2.19/debian/patches/series 2014-02-20 09:37:10.0 +
+++ eglibc-2.19/debian/patches/series 2014-02-21 23:29:29.0 +
@@ -230,3 +230,4 @@
ubuntu/local-disable-nscd-netgroup-caching.diff
ubuntu/submitted-no-sprintf-pre-truncate.diff
ubuntu/submitted-no-stack-backtrace.diff
+dont-redefine-xattr
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221234206.GA26198@sergelap
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn wrote: > > Hi, would a simple patchl ike this to misc/sys/xattr.h be > > acceptable? This showed up in a failure to build (of at least > > qemu, and aiui lots of other pkgs) after merging a new libcap2 > > where sys/capability.h #included linux/xattr.h. It's being > > worked around by patching libcap2 to #include sys/xattr.h > > first, but presumably this will cause other breakages. > > Please follow the accepted practice for fixing coordination between > userspace and Linux kernel headers. > > Upstream glibc and the Linux kernel have already worked out a > mechanical solution to this problem, and we need people to work out > the patches and post them upstream. > > The solution is to coordinate the conflicting headers following this template: > https://sourceware.org/glibc/wiki/Synchronizing_Headers Thanks for the information. I tested the two patches at http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they seem to do the right thing. I'll send them out if they look ok. thanks, -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306230616.GA31170@ac100
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> wrote: > >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> > acceptable? This showed up in a failure to build (of at least > >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> > where sys/capability.h #included linux/xattr.h. It's being > >> > worked around by patching libcap2 to #include sys/xattr.h > >> > first, but presumably this will cause other breakages. > >> > >> Please follow the accepted practice for fixing coordination between > >> userspace and Linux kernel headers. > >> > >> Upstream glibc and the Linux kernel have already worked out a > >> mechanical solution to this problem, and we need people to work out > >> the patches and post them upstream. > >> > >> The solution is to coordinate the conflicting headers following this > >> template: > >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > > > > Thanks for the information. I tested the two patches at > > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > > seem to do the right thing. I'll send them out if they look ok. > > Let me warn you that the glibc patch won't get accepted as-is. > > You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > > Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html Yeah I had noticed that that patch (part of the linux part of which was reverted :) used __USE_KERNEL_*, but I didn't see where that was defined, and https://sourceware.org/glibc/wiki/Synchronizing_Headers specifically said to use #if !__UAPI*. No biggie, if I'm otherwise on the right track, I'll change that before submitting. thanks, -serge > See how we adjust a Linux-specific header to define an OS-agnostic > variable to use in the OS-agnostic code e.g. __USE_FOO. > > Cheers, > Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307032253.GA4605@sergelap
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> wrote: > >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> > acceptable? This showed up in a failure to build (of at least > >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> > where sys/capability.h #included linux/xattr.h. It's being > >> > worked around by patching libcap2 to #include sys/xattr.h > >> > first, but presumably this will cause other breakages. > >> > >> Please follow the accepted practice for fixing coordination between > >> userspace and Linux kernel headers. > >> > >> Upstream glibc and the Linux kernel have already worked out a > >> mechanical solution to this problem, and we need people to work out > >> the patches and post them upstream. > >> > >> The solution is to coordinate the conflicting headers following this > >> template: > >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > > > > Thanks for the information. I tested the two patches at > > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > > seem to do the right thing. I'll send them out if they look ok. > > Let me warn you that the glibc patch won't get accepted as-is. > > You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > > Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html > > See how we adjust a Linux-specific header to define an OS-agnostic > variable to use in the OS-agnostic code e.g. __USE_FOO. There isn't currently a bits/xattr.h file. Would it be preferred that I create one, or that I just set __USE_KERNEL_XATTR_DEFS in the linux kernel header? -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307053111.GA17475@sergelap
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Fri, Mar 7, 2014 at 12:31 AM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn > >> wrote: > >> > Quoting Carlos O'Donell (car...@systemhalted.org): > >> >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> >> wrote: > >> >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> >> > acceptable? This showed up in a failure to build (of at least > >> >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> >> > where sys/capability.h #included linux/xattr.h. It's being > >> >> > worked around by patching libcap2 to #include sys/xattr.h > >> >> > first, but presumably this will cause other breakages. > >> >> > >> >> Please follow the accepted practice for fixing coordination between > >> >> userspace and Linux kernel headers. > >> >> > >> >> Upstream glibc and the Linux kernel have already worked out a > >> >> mechanical solution to this problem, and we need people to work out > >> >> the patches and post them upstream. > >> >> > >> >> The solution is to coordinate the conflicting headers following this > >> >> template: > >> >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > >> > > >> > Thanks for the information. I tested the two patches at > >> > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > >> > seem to do the right thing. I'll send them out if they look ok. > >> > >> Let me warn you that the glibc patch won't get accepted as-is. > >> > >> You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > >> > >> Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html > >> > >> See how we adjust a Linux-specific header to define an OS-agnostic > >> variable to use in the OS-agnostic code e.g. __USE_FOO. > > > > There isn't currently a bits/xattr.h file. Would it be preferred that > > I create one, or that I just set __USE_KERNEL_XATTR_DEFS in the > > linux kernel header? > > I don't know, you'll have to take a stab at an implementation and see > what upstream likes. > > I haven't reviewed this thoroughly so I can't comment yet. Ah ok, thanks. I'll just start with the kernel patch then, with the define in there. thanks, -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307055128.GA20460@sergelap
