[Buildroot] Samba4 build issue

[Buildroot] Samba4 build issue

[Thomas Petazzoni]

Hello Gustavo,

A build issue is affecting Samba 4, apparently on many
architectures/toolchains:

   http://autobuild.buildroot.org/?reason=samba4-4.1.13

The error message seems to be more or less always the same:

/home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/xattr.h:32:3: error: expected identifier before numeric constant
   XATTR_CREATE = 1, /* set value, fail if attr already exists.  */
   ^

Is this some new kernel headers dependency? Dependency on the attr
package?

If you could have a look, it would be great.

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Samba4 build issue

[Gustavo Zacarias]

On 11/01/2014 07:39 PM, Thomas Petazzoni wrote:

> Hello Gustavo,
> 
> A build issue is affecting Samba 4, apparently on many
> architectures/toolchains:
> 
>    http://autobuild.buildroot.org/?reason=samba4-4.1.13
> 
> The error message seems to be more or less always the same:
> 
> /home/peko/autobuild/instance-2/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/xattr.h:32:3: error: expected identifier before numeric constant
>    XATTR_CREATE = 1, /* set value, fail if attr already exists.  */
>    ^
> 
> Is this some new kernel headers dependency? Dependency on the attr
> package?
> 
> If you could have a look, it would be great.

No, it's a bump from an autodep that's breaking havoc.
Blame 57280c2f244500ac6616377b3b8eab458c1ead23.
The release is all kinds of wrong apparently, even 2.23 breaks and more
horribly than 2.24.
So let's just roll back to 2.22 until a detailed analysis can take place
to fix it.
Regards.

[Buildroot] Samba4 build issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sat, 01 Nov 2014 21:16:25 -0300, Gustavo Zacarias wrote:

> > Is this some new kernel headers dependency? Dependency on the attr
> > package?
> > 
> > If you could have a look, it would be great.
> 
> No, it's a bump from an autodep that's breaking havoc.
> Blame 57280c2f244500ac6616377b3b8eab458c1ead23.
> The release is all kinds of wrong apparently, even 2.23 breaks and more
> horribly than 2.24.
> So let's just roll back to 2.22 until a detailed analysis can take place
> to fix it.

Ok, so it's libcap causing issues. Have those issues reported upstream?
While reverting to an older version libcap being an acceptable
temporary workaround, it's not going to be nice on the long run;

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Samba4 build issue

[Gustavo Zacarias]

On 11/02/2014 06:38 AM, Thomas Petazzoni wrote:

> Ok, so it's libcap causing issues. Have those issues reported upstream?
> While reverting to an older version libcap being an acceptable
> temporary workaround, it's not going to be nice on the long run;

They're fixed, revised patch sent.
Let's just hope it doesn't break other stuff.
Regards.

[Buildroot] Samba4 build issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 02 Nov 2014 09:51:11 -0300, Gustavo Zacarias wrote:
> On 11/02/2014 06:38 AM, Thomas Petazzoni wrote:
> 
> > Ok, so it's libcap causing issues. Have those issues reported upstream?
> > While reverting to an older version libcap being an acceptable
> > temporary workaround, it's not going to be nice on the long run;
> 
> They're fixed, revised patch sent.
> Let's just hope it doesn't break other stuff.

Great, thanks for having worked on this.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Samba4 build issue

[Gustavo Zacarias]

On 11/04/2014 04:26 AM, Thomas Petazzoni wrote:

> Dear Gustavo Zacarias,
> 
> On Sun, 02 Nov 2014 09:51:11 -0300, Gustavo Zacarias wrote:
>> On 11/02/2014 06:38 AM, Thomas Petazzoni wrote:
>>
>>> Ok, so it's libcap causing issues. Have those issues reported upstream?
>>> While reverting to an older version libcap being an acceptable
>>> temporary workaround, it's not going to be nice on the long run;
>>
>> They're fixed, revised patch sent.
>> Let's just hope it doesn't break other stuff.
> 
> Great, thanks for having worked on this.

D'oh!
http://autobuild.buildroot.net/results/992/9928a251e5cfcf6e574a447221e938135eeb69f9/build-end.log
Seems the new libcap version requires 3.1+ kernel headers.
I'm not a big fan of those ppc toolchains since they're old, but what's
the linux headers baseline we're looking for?

Mandatory use of libcap:
cdrkit - ouch
lxc - probably not that much
squid - probably not that much
systemd - irrelevant, needs newer headers by itself

We could propagate the headers dep, it's just that it will look silly on
cdrkit.
Opinions?

Regards.

[Buildroot] Samba4 build issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 04 Nov 2014 11:01:54 -0300, Gustavo Zacarias wrote:

> D'oh!
> http://autobuild.buildroot.net/results/992/9928a251e5cfcf6e574a447221e938135eeb69f9/build-end.log
> Seems the new libcap version requires 3.1+ kernel headers.
> I'm not a big fan of those ppc toolchains since they're old, but what's
> the linux headers baseline we're looking for?

There was a patch from Bernd, a759931c9b0cb4337dc30fd35d03ce123271c5a4,
which made libcap depend on headers >= 3.7. But I reverted it in
d5146f4b53d926c13a47215ac514e43b2c66b9ac, because Bernd's analysis was
not correct, and libcap did not depend on kernel headers >= 3.7.

Are you sure 3.1 is really the correct starting point? Here is what I
wrote at the time:

""""
 * First, the XATTR_NAME_CAPS was *not* introduced in kernel 3.7 has
   claimed by the commit log. The kernel commit
   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/xattr.h?id=607ca46e97a1b6594b29647d98a32d545c24bdff
   pointed by the commit log as the one introducing XATTR_NAME_CAPS
   was badly interpreted. This commit is the one where the userspace
   side of the kernel headers was separated from the kernel side of
   the kernel headers (before we had only <linux/foo.h>, now we have
   <linux/foo.h> and <uapi/linux/foo.h>). In reality, XATTR_CAP_NAMES
   has been defined in <linux/xattr.h> since commit
   af4f136056c984b0aa67feed7d3170b958370b2f which was merged in
   2.6.36. And before that, the definition was anyway present in
   <linux/capability.h>. XATTR_NAME_CAPS was originally introduced in
   b53767719b6cd8789392ea3e7e2eb7b8906898f0, which was merged in
   kernel 2.6.24.
""""

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Samba4 build issue

[Gustavo Zacarias]

On 11/04/2014 03:20 PM, Thomas Petazzoni wrote:

> There was a patch from Bernd, a759931c9b0cb4337dc30fd35d03ce123271c5a4,
> which made libcap depend on headers >= 3.7. But I reverted it in
> d5146f4b53d926c13a47215ac514e43b2c66b9ac, because Bernd's analysis was
> not correct, and libcap did not depend on kernel headers >= 3.7.
> 
> Are you sure 3.1 is really the correct starting point? Here is what I
> wrote at the time:

Yes, true, the definition moved to another header from 2.6.35 -> 2.6.36
The failure seems to affect only the 2011 cs lite ppc toolchain.
Even though it's based on 2.6.38 headers something bad was done to it:

freescale-2011.03 $ find . -type f -exec grep --with-filename
XATTR_NAME_CAPS {} \; -> nothing (yes i did '-name *.h' first but to my
amazement nothing returned so i went all-out).

So as a POC i've built a 2.6.35.14-based basic toolchain with libcap
enabled and everything went fine.

My professional opinion is that the codesourcery powerpc 2011.03
toolchain is messed up.
So we either blacklist it or do users a favor and just deprecate/remove it.
Regards.

[Buildroot] Samba4 build issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 04 Nov 2014 15:54:59 -0300, Gustavo Zacarias wrote:

> Yes, true, the definition moved to another header from 2.6.35 -> 2.6.36
> The failure seems to affect only the 2011 cs lite ppc toolchain.
> Even though it's based on 2.6.38 headers something bad was done to it:
> 
> freescale-2011.03 $ find . -type f -exec grep --with-filename
> XATTR_NAME_CAPS {} \; -> nothing (yes i did '-name *.h' first but to my
> amazement nothing returned so i went all-out).
> 
> So as a POC i've built a 2.6.35.14-based basic toolchain with libcap
> enabled and everything went fine.
> 
> My professional opinion is that the codesourcery powerpc 2011.03
> toolchain is messed up.
> So we either blacklist it or do users a favor and just deprecate/remove it.

I'm fine with deprecating/removing this CS toolchain. However, I'd like
to have in order set of toolchains at least one toolchain without "old"
kernel headers, so that we keep testing the case of old kernel headers
in the autobuilders.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com