[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Carlos Santos]

> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> To: "DATACOM" <casantos@datacom.com.br>
> Sent: Friday, August 31, 2018 3:00:16 AM
> Subject: [autobuild.buildroot.net] Your build results for 2018-08-30

> Hello,
> 
> This is the list of Buildroot build failures that occured on
> 2018-08-30, and for which you are a registered architecture developer
> or package developer. Please help us improving the quality of
> Buildroot by investigating those build failures and sending patches to
> fix them. Thanks!
> 
> Results for the 'next' branch
> =============================
> 
> Build failures related to your packages:
> 
>         arm |              util-linux-2.32.1 |
>         http://autobuild.buildroot.net/results/c8e34d661098e96e3f627d7c022fdcf3efa40805
> 
> --
> http://autobuild.buildroot.net

I'm still unable to reproduce these "SELinux selected but libselinux
not found or too old" errors.

:-(

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?Marched towards the enemy, spear upright, armed with the certainty
that only the ignorant can have.? ? Epitaph of a volunteer

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Matthew Weber]

Carlos,

On Sun, Sep 2, 2018 at 2:56 PM Carlos Santos <casantos@datacom.com.br> wrote:
>
> > From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> > To: "DATACOM" <casantos@datacom.com.br>
> > Sent: Friday, August 31, 2018 3:00:16 AM
> > Subject: [autobuild.buildroot.net] Your build results for 2018-08-30
>
> > Hello,
> >
> > This is the list of Buildroot build failures that occured on
> > 2018-08-30, and for which you are a registered architecture developer
> > or package developer. Please help us improving the quality of
> > Buildroot by investigating those build failures and sending patches to
> > fix them. Thanks!
> >
> > Results for the 'next' branch
> > =============================
> >
> > Build failures related to your packages:
> >
> >         arm |              util-linux-2.32.1 |
> >         http://autobuild.buildroot.net/results/c8e34d661098e96e3f627d7c022fdcf3efa40805
> >
> > --
> > http://autobuild.buildroot.net
>
> I'm still unable to reproduce these "SELinux selected but libselinux
> not found or too old" errors.

I haven't dug to much, was there a bump of util-linux in "next"?
Maybe if it's using pkgconfig for that test, the latest libselinux
bump isn't updating its pkgconfig entry or the version its at is not
compatible now?

Could be the test is checking the local system too....  I'll see if I
can reproduce but all my machines have selinux.

Matt

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Matthew Weber]

All,

On Mon, Sep 3, 2018 at 10:29 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> Carlos,
>
> On Sun, Sep 2, 2018 at 2:56 PM Carlos Santos <casantos@datacom.com.br> wrote:
> >
> > > From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> > > To: "DATACOM" <casantos@datacom.com.br>
> > > Sent: Friday, August 31, 2018 3:00:16 AM
> > > Subject: [autobuild.buildroot.net] Your build results for 2018-08-30
> >
> > > Hello,
> > >
> > > This is the list of Buildroot build failures that occured on
> > > 2018-08-30, and for which you are a registered architecture developer
> > > or package developer. Please help us improving the quality of
> > > Buildroot by investigating those build failures and sending patches to
> > > fix them. Thanks!
> > >
> > > Results for the 'next' branch
> > > =============================
> > >
> > > Build failures related to your packages:
> > >
> > >         arm |              util-linux-2.32.1 |
> > >         http://autobuild.buildroot.net/results/c8e34d661098e96e3f627d7c022fdcf3efa40805
> > >
> > > --
> > > http://autobuild.buildroot.net
> >
> > I'm still unable to reproduce these "SELinux selected but libselinux
> > not found or too old" errors.
>
> I haven't dug to much, was there a bump of util-linux in "next"?
> Maybe if it's using pkgconfig for that test, the latest libselinux
> bump isn't updating its pkgconfig entry or the version its at is not
> compatible now?
>
> Could be the test is checking the local system too....  I'll see if I
> can reproduce but all my machines have selinux.
>

Figured it out, the python3 bump and the addition of the python uuid
dependency on util-linux, created a circular dependency making
libselinux and util-linux build out of order.
(6e7e733f3bb)

Adam, would you mind taking a look to see if there is another option
for that new dependency?  Maybe conditionally enabling that uuid
option only when util-linux is selected?

Matt

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Thomas Petazzoni]

Hello,

On Mon, 3 Sep 2018 14:49:24 -0500, Matthew Weber wrote:

> Figured it out, the python3 bump and the addition of the python uuid
> dependency on util-linux, created a circular dependency making
> libselinux and util-linux build out of order.
> (6e7e733f3bb)

So, if I get it right, the circular dependency is:

 util-linux -> libselinux -> python3 -> util-linux

But wait, I realize that there is worse, with the Python libuuid thing,
we have the following circular dependency as well:

 util-linux -> python3 -> util-linux

So that last one we can fix by introducing python-util-linux, as I was
suggesting to also solve the BlueZ related circular:

  http://lists.busybox.net/pipermail/buildroot/2018-August/229558.html

But that first one is different, because it won't be solved by moving
the util-linux Python bindings to a separate package. To solve:

 util-linux -> libselinux -> python3 -> util-linux

then we need to create python-libselinux, which will build/install the
python bindings of libselinux. This way util-linux -> libselinux will
not pull in a python3 dependency. This should be doable, because
libselinux has separate make targets for building/installing the python
bindings.

These circular dependencies are annoying.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Arnout Vandecappelle]

On 04/09/2018 11:45, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 3 Sep 2018 14:49:24 -0500, Matthew Weber wrote:
> 
>> Figured it out, the python3 bump and the addition of the python uuid
>> dependency on util-linux, created a circular dependency making
>> libselinux and util-linux build out of order.
>> (6e7e733f3bb)
> 
> So, if I get it right, the circular dependency is:
> 
>  util-linux -> libselinux -> python3 -> util-linux
> 
> But wait, I realize that there is worse, with the Python libuuid thing,
> we have the following circular dependency as well:
> 
>  util-linux -> python3 -> util-linux
> 
> So that last one we can fix by introducing python-util-linux, as I was
> suggesting to also solve the BlueZ related circular:
> 
>   http://lists.busybox.net/pipermail/buildroot/2018-August/229558.html
> 
> But that first one is different, because it won't be solved by moving
> the util-linux Python bindings to a separate package. To solve:
> 
>  util-linux -> libselinux -> python3 -> util-linux
> 
> then we need to create python-libselinux, which will build/install the
> python bindings of libselinux. This way util-linux -> libselinux will
> not pull in a python3 dependency. This should be doable, because
> libselinux has separate make targets for building/installing the python
> bindings.
> 
> These circular dependencies are annoying.

 I checked how Fedora solves it. They don't - the spec file for python3 has a
BuildRequires of libuuid-devel, and util-linux has a BuildRequires of
python3-devel. I guess it's no longer possible to bootstrap Fedora from source...

 So what does gentoo do? They simply don't have a dependency on util-linux in
the python3.7.0.ebuild. Indeed, it turns out that the _uuid module is entirely
optional. It is only used to access the uuid_generate_time_safe() function, but
the uuid.py module can also get this function through ctypes (i.e. dlopen()). So
perhaps a simpler solution is to just remove the build-time python3 ->
util-linux dependency? Runtime is still needed to support the dlopen path.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Thomas Petazzoni]

Hello,

On Wed, 5 Sep 2018 00:43:32 +0200, Arnout Vandecappelle wrote:

>  So what does gentoo do? They simply don't have a dependency on util-linux in
> the python3.7.0.ebuild. Indeed, it turns out that the _uuid module is entirely
> optional. It is only used to access the uuid_generate_time_safe() function, but
> the uuid.py module can also get this function through ctypes (i.e. dlopen()). So
> perhaps a simpler solution is to just remove the build-time python3 ->
> util-linux dependency? Runtime is still needed to support the dlopen path.

Aaah, seems like a very good idea. This would solve all the circular
dependencies we're seeing, with essentially no additional complexity.

The only downside is that the python3 util-linux support would not work
in static-linking scenarios, because in such cases dlopen() is not
available. But python3 anyway has "depends on !BR2_STATIC_LIBS", so
we're good :-)

Adam: could you look at implementing this solution, and do a runtime
check that the uuid-related feature of Python 3 are working as
expected ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your build results for 2018-08-30

[Thomas Petazzoni]

Hello,

On Wed, 5 Sep 2018 00:43:32 +0200, Arnout Vandecappelle wrote:

>  So what does gentoo do? They simply don't have a dependency on util-linux in
> the python3.7.0.ebuild. Indeed, it turns out that the _uuid module is entirely
> optional. It is only used to access the uuid_generate_time_safe() function, but
> the uuid.py module can also get this function through ctypes (i.e. dlopen()). So
> perhaps a simpler solution is to just remove the build-time python3 ->
> util-linux dependency? Runtime is still needed to support the dlopen path.

So I just tested this and for some reason, ctypes doesn't seem to work.
The Lib/uuid.py code looks like this:

        for libname in _libnames:
            try:
                lib = ctypes.CDLL(ctypes.util.find_library(libname))
            except Exception:                           # pragma: nocover
                continue
            # Try to find the safe variety first.
            if hasattr(lib, 'uuid_generate_time_safe'):
		[...]
            elif hasattr(lib, 'uuid_generate_time'):    # pragma: nocover
		[...]

On the target, I have:

# python
Python 3.7.0 (default, Sep 18 2018, 23:23:41) 
[GCC 4.9.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes.util
>>> lib = ctypes.CDLL(ctypes.util.find_library("uuid"))
>>> lib
<CDLL 'None', handle 76f17178@0x76b37eb0>
>>> hasattr(lib, 'uuid_generate_time_safe')
False
>>> hasattr(lib, 'uuid_generate_time')
False

Even though libuuid does provide those symbols:

     9: 00001a18     4 FUNC    GLOBAL DEFAULT   10 uuid_generate_time@@UUID_1.0
    56: 00001a1c     4 FUNC    GLOBAL DEFAULT   10 uuid_generate_time_safe@@UUID_2.20

But uuid.uuid1() does work:

# python -c "import uuid; print(uuid.uuid1())"
60fa6f9e-bb8c-11e8-b77b-525400123456

But stracing this process, I don't see the libuuid.so library being
opened, however, I see that Python tries to call gcc and ld, apparently
because that's what ctypes.find_library does
(https://docs.python.org/3/library/ctypes.html#finding-shared-libraries).

So perhaps the pure Python uuid module can do without a working
libuuid. At this point, it's 23:48, and I'm tired, so I stopped the
investigation here.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com