[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Thomas Petazzoni]

Build statistics for 2014-06-08
===============================

        success : 93 
       failures : 11 
       timeouts : 0  
          TOTAL : 104

Classification of failures by reason
====================================

                  libbsd-0.6.0 | 2 
                 mesa3d-10.2.1 | 2 
rpi-userland-4855a45b118cb7... | 1 
           xapp_bdftopcf-1.0.4 | 1 
tvheadend-0ebca1b3dbb6a18d8... | 1 
faifa-aa0b5f90b89a9fd153313... | 1 
                   systemd-213 | 1 
              cosmo-14.03.04-1 | 1 
                  weston-1.5.0 | 1 

Detail of failures
===================

    xtensa |               cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/511193d2c43ced35fada333c8b2d13a7f096fb10/
      bfin | faifa-aa0b5f90b89a9fd153313... | NOK | http://autobuild.buildroot.net/results/0aa518705be3d8809dff1a5d40be946d9d26a131/
      i486 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/e949d8fabeeecc74bd1c324c516e0b4938c99dbc/
    x86_64 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/d3e1b70fb91571efacbe32af2cd12d055508f5ac/
  mips64el |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/0ee234e4557cbdf14aaa8f1a95156845c0dfe05a/
       arm |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/43c491a8875bba4b4eed13950346422d52841bf5/
       arm | rpi-userland-4855a45b118cb7... | NOK | http://autobuild.buildroot.net/results/6f36ad6a78d9c0e204d617ec6d15e7b577542c28/
       arm |                    systemd-213 | NOK | http://autobuild.buildroot.net/results/1524d346fa17749e2ae62e063b9cfdd0de95c76a/
       sh4 | tvheadend-0ebca1b3dbb6a18d8... | NOK | http://autobuild.buildroot.net/results/2278a078af5cc2e9f36661ad11e70b7692481266/
    mipsel |                   weston-1.5.0 | NOK | http://autobuild.buildroot.net/results/4e996c65f5b33d4518b0596d9c7076083d491a52/
microblazeel |            xapp_bdftopcf-1.0.4 | NOK | http://autobuild.buildroot.net/results/061ef838681d8cbfa34c579c05d1460df0e7ae38/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Yann E. MORIN]

Thomas, All,

Here's a quick analysis of the build failures.

On 2014-06-09 08:30 +0200, Thomas Petazzoni spake thusly:
>     xtensa |               cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/511193d2c43ced35fada333c8b2d13a7f096fb10/

Did something change in the luarocks infra ?
    gzip: cosmo-14.03.04.tar.gz: not in gzip format
    tar: This does not look like a tar archive
    tar: Exiting with failure status due to previous errors

Fran?ois ?

>       bfin | faifa-aa0b5f90b89a9fd153313... | NOK | http://autobuild.buildroot.net/results/0aa518705be3d8809dff1a5d40be946d9d26a131/

    fatal: Not a git repository (or any of the parent directories): .git
    fatal: Not a git repository (or any of the parent directories): .git
    make[1]: Entering directory
    `/home/test/test/1/output/build/faifa-aa0b5f90b89a9fd1533137b68ebf85f5437aba53'
    /home/test/test/1/output/host/usr/bin/bfin-linux-uclibc-gcc -DLINUX
    -DGIT_REV="\"-\"" -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
    -D_FILE_OFFSET_BITS=64  -pipe -Os  -Wall -Wno-unused-result -fPIC -c
    main.c
    cc1: error: unrecognized command line option "-Wno-unused-result"

Maxime is on it.

>       i486 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/e949d8fabeeecc74bd1c324c516e0b4938c99dbc/
>     x86_64 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/d3e1b70fb91571efacbe32af2cd12d055508f5ac/

Does not build with uClibc.
I'm on it.

>   mips64el |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/0ee234e4557cbdf14aaa8f1a95156845c0dfe05a/
>        arm |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/43c491a8875bba4b4eed13950346422d52841bf5/

Needs udev:
    checking for LIBUDEV... no
    configure: error: libudev-dev required for building DRI

Bernd, we need to revisit your libudev patch. ;-)

>        arm | rpi-userland-4855a45b118cb7... | NOK | http://autobuild.buildroot.net/results/6f36ad6a78d9c0e204d617ec6d15e7b577542c28/

Should be fixed by the recent cleanup from Samuel.

>        arm |                    systemd-213 | NOK | http://autobuild.buildroot.net/results/1524d346fa17749e2ae62e063b9cfdd0de95c76a/

Needs gcrypt?
    configure.ac:616: warning: macro 'AM_PATH_LIBGCRYPT' not found in library
    configure.ac:48: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
    configure.ac:616: error: possibly undefined macro: AM_PATH_LIBGCRYPT

Eric ?

>        sh4 | tvheadend-0ebca1b3dbb6a18d8... | NOK | http://autobuild.buildroot.net/results/2278a078af5cc2e9f36661ad11e70b7692481266/

No clear error:
    CC              tvheadend
    /home/test/test/1/output/host/usr/sh4-buildroot-linux-uclibc/sysroot/usr//lib/libcrypto.so:
    warning: gethostbyname is obsolescent, use getnameinfo() instead.
    make[1]: *** [/home/test/test/1/output/build/tvheadend-0ebca1b3dbb6a18d8adcf66a32b5922ce769b9b5/data/dvb-scan/.stamp]
    Error 1

I'm on it...

>     mipsel |                   weston-1.5.0 | NOK | http://autobuild.buildroot.net/results/4e996c65f5b33d4518b0596d9c7076083d491a52/

My removal of the libxkbcommon seems to cause some issues:
    checking for CLIENT... no
    configure: error: Package requirements (wayland-client cairo >= 1.10.0 xkbcommon wayland-cursor) were not met:

    Package xkbcommon was not found in the pkg-config search path.
    Perhaps you should add the directory containing `xkbcommon.pc'
    to the PKG_CONFIG_PATH environment variable
    No package 'xkbcommon' found

I'm on it.

> microblazeel |            xapp_bdftopcf-1.0.4 | NOK | http://autobuild.buildroot.net/results/061ef838681d8cbfa34c579c05d1460df0e7ae38/

No idea:
    make[3]: Entering directory `/home/test/test/3/output/build/xapp_bdftopcf-1.0.4'
      CC     bdftopcf.o
      CCLD   bdftopcf
    /home/test/test/3/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `serverGeneration'
    collect2: error: ld returned 1 exit status

Bernd ?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Thomas Petazzoni]

Dear Yann E. MORIN,

Thanks for the analysis!

On Mon, 9 Jun 2014 12:07:09 +0200, Yann E. MORIN wrote:

> >   mips64el |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/0ee234e4557cbdf14aaa8f1a95156845c0dfe05a/
> >        arm |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/43c491a8875bba4b4eed13950346422d52841bf5/
> 
> Needs udev:
>     checking for LIBUDEV... no
>     configure: error: libudev-dev required for building DRI
> 
> Bernd, we need to revisit your libudev patch. ;-)

Shouldn't instead mesa3d depend on eudev || systemd, using
BR2_PACKAGE_HAS_UDEV ?

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Yann E. MORIN]

Thomas, All,

On 2014-06-09 12:11 +0200, Thomas Petazzoni spake thusly:
> Dear Yann E. MORIN,
> 
> Thanks for the analysis!
> 
> On Mon, 9 Jun 2014 12:07:09 +0200, Yann E. MORIN wrote:
> 
> > >   mips64el |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/0ee234e4557cbdf14aaa8f1a95156845c0dfe05a/
> > >        arm |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/43c491a8875bba4b4eed13950346422d52841bf5/
> > 
> > Needs udev:
> >     checking for LIBUDEV... no
> >     configure: error: libudev-dev required for building DRI
> > 
> > Bernd, we need to revisit your libudev patch. ;-)
> 
> Shouldn't instead mesa3d depend on eudev || systemd, using
> BR2_PACKAGE_HAS_UDEV ?

That's what we should do to start with.

But in the end, having libudev would be nice, too, since quite a few
pckages need only the lib and not the full udev stuff. That's the case
for libcec and weston, for example.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[François Perrad]

2014-06-09 12:07 GMT+02:00 Yann E. MORIN <yann.morin.1998@free.fr>:
> Thomas, All,
>
> Here's a quick analysis of the build failures.
>
> On 2014-06-09 08:30 +0200, Thomas Petazzoni spake thusly:
>>     xtensa |               cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/511193d2c43ced35fada333c8b2d13a7f096fb10/
>
> Did something change in the luarocks infra ?
>     gzip: cosmo-14.03.04.tar.gz: not in gzip format
>     tar: This does not look like a tar archive
>     tar: Exiting with failure status due to previous errors
>
> Fran?ois ?

No change with luarocks infra, just a problem with a rock.
I've notified this problem to the LuaRocks mailing list,
see http://sourceforge.net/p/luarocks/mailman/message/32431219/

Fran?ois

>
>>       bfin | faifa-aa0b5f90b89a9fd153313... | NOK | http://autobuild.buildroot.net/results/0aa518705be3d8809dff1a5d40be946d9d26a131/
>
>     fatal: Not a git repository (or any of the parent directories): .git
>     fatal: Not a git repository (or any of the parent directories): .git
>     make[1]: Entering directory
>     `/home/test/test/1/output/build/faifa-aa0b5f90b89a9fd1533137b68ebf85f5437aba53'
>     /home/test/test/1/output/host/usr/bin/bfin-linux-uclibc-gcc -DLINUX
>     -DGIT_REV="\"-\"" -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>     -D_FILE_OFFSET_BITS=64  -pipe -Os  -Wall -Wno-unused-result -fPIC -c
>     main.c
>     cc1: error: unrecognized command line option "-Wno-unused-result"
>
> Maxime is on it.
>
>>       i486 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/e949d8fabeeecc74bd1c324c516e0b4938c99dbc/
>>     x86_64 |                   libbsd-0.6.0 | NOK | http://autobuild.buildroot.net/results/d3e1b70fb91571efacbe32af2cd12d055508f5ac/
>
> Does not build with uClibc.
> I'm on it.
>
>>   mips64el |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/0ee234e4557cbdf14aaa8f1a95156845c0dfe05a/
>>        arm |                  mesa3d-10.2.1 | NOK | http://autobuild.buildroot.net/results/43c491a8875bba4b4eed13950346422d52841bf5/
>
> Needs udev:
>     checking for LIBUDEV... no
>     configure: error: libudev-dev required for building DRI
>
> Bernd, we need to revisit your libudev patch. ;-)
>
>>        arm | rpi-userland-4855a45b118cb7... | NOK | http://autobuild.buildroot.net/results/6f36ad6a78d9c0e204d617ec6d15e7b577542c28/
>
> Should be fixed by the recent cleanup from Samuel.
>
>>        arm |                    systemd-213 | NOK | http://autobuild.buildroot.net/results/1524d346fa17749e2ae62e063b9cfdd0de95c76a/
>
> Needs gcrypt?
>     configure.ac:616: warning: macro 'AM_PATH_LIBGCRYPT' not found in library
>     configure.ac:48: error: possibly undefined macro: AC_MSG_ERROR
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
>     configure.ac:616: error: possibly undefined macro: AM_PATH_LIBGCRYPT
>
> Eric ?
>
>>        sh4 | tvheadend-0ebca1b3dbb6a18d8... | NOK | http://autobuild.buildroot.net/results/2278a078af5cc2e9f36661ad11e70b7692481266/
>
> No clear error:
>     CC              tvheadend
>     /home/test/test/1/output/host/usr/sh4-buildroot-linux-uclibc/sysroot/usr//lib/libcrypto.so:
>     warning: gethostbyname is obsolescent, use getnameinfo() instead.
>     make[1]: *** [/home/test/test/1/output/build/tvheadend-0ebca1b3dbb6a18d8adcf66a32b5922ce769b9b5/data/dvb-scan/.stamp]
>     Error 1
>
> I'm on it...
>
>>     mipsel |                   weston-1.5.0 | NOK | http://autobuild.buildroot.net/results/4e996c65f5b33d4518b0596d9c7076083d491a52/
>
> My removal of the libxkbcommon seems to cause some issues:
>     checking for CLIENT... no
>     configure: error: Package requirements (wayland-client cairo >= 1.10.0 xkbcommon wayland-cursor) were not met:
>
>     Package xkbcommon was not found in the pkg-config search path.
>     Perhaps you should add the directory containing `xkbcommon.pc'
>     to the PKG_CONFIG_PATH environment variable
>     No package 'xkbcommon' found
>
> I'm on it.
>
>> microblazeel |            xapp_bdftopcf-1.0.4 | NOK | http://autobuild.buildroot.net/results/061ef838681d8cbfa34c579c05d1460df0e7ae38/
>
> No idea:
>     make[3]: Entering directory `/home/test/test/3/output/build/xapp_bdftopcf-1.0.4'
>       CC     bdftopcf.o
>       CCLD   bdftopcf
>     /home/test/test/3/output/host/usr/microblazeel-buildroot-linux-gnu/sysroot/usr/lib/libXfont.so: undefined reference to `serverGeneration'
>     collect2: error: ld returned 1 exit status
>
> Bernd ?
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Yann E. MORIN]

Fran?ois, All,

On 2014-06-09 14:04 +0200, Fran?ois Perrad spake thusly:
> 2014-06-09 12:07 GMT+02:00 Yann E. MORIN <yann.morin.1998@free.fr>:
> > On 2014-06-09 08:30 +0200, Thomas Petazzoni spake thusly:
> >>     xtensa |               cosmo-14.03.04-1 | NOK | http://autobuild.buildroot.net/results/511193d2c43ced35fada333c8b2d13a7f096fb10/
> >
> > Did something change in the luarocks infra ?
> >     gzip: cosmo-14.03.04.tar.gz: not in gzip format
> >     tar: This does not look like a tar archive
> >     tar: Exiting with failure status due to previous errors
> >
> > Fran?ois ?
> 
> No change with luarocks infra, just a problem with a rock.
> I've notified this problem to the LuaRocks mailing list,
> see http://sourceforge.net/p/luarocks/mailman/message/32431219/

OK, good. Thanks for the feedback! :-)

Should we do something special in the meantime, like disabling cosmo in
the menuconfig?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Eric Le Bihan]

Hi!
On Mon, Jun 09, 2014 at 08:30:10AM +0200, Thomas Petazzoni wrote:

>        arm |                    systemd-213 | NOK | http://autobuild.buildroot.net/results/1524d346fa17749e2ae62e063b9cfdd0de95c76a/
>

D'Oh! AM_PATH_LIBGCRYPT comes haunting us again!

This problem spawned a discussion in the past [1], and was temporarily solved,
as the call to autoreconf was removed [2].

Let's see:

- systemd upstream says gcrypt is a dependency, but will remove the m4 macro if gcrypt
  moves to pkg-config [3].
- gcrypt upstream does not like pkg-config [4].
- Some other embedded distros have patched gcrypt to provide support for
  pkg-config [5] [6].
- OpenEmbedded added gcrypt as dependency [7].
- We are stuck with autoreconf, as it is needed to solve the `ln --relative`
  issue via a patch, which will not be accepted by upstream [8].

Adding libgcrypt as a dependency is a no-go, as the end user gets some
unneedded stuff in its target rootfs. So we're left with the solution of
adding libgcrypt.m4 to m4 directory of systemd. Though this solution was
considered "temporary", can it now be accepted as "definitive"? [9]

Best regards,
ELB

[1] http://lists.busybox.net/pipermail/buildroot/2013-September/077768.html
[2] http://git.buildroot.net/buildroot/commit/?id=34291708d077e5626453378df133a683c9606bef
[3] http://lists.freedesktop.org/archives/systemd-bugs/2012-September/000161.html
[4] http://lists.gnupg.org/pipermail/gcrypt-devel/2007-February/001109.html
[5] http://git.yoctoproject.org/cgit/cgit.cgi/poky/plain/meta/recipes-support/libgcrypt/files/add-pkgconfig-support.patch
[6] http://git.overlays.gentoo.org/gitweb/?p=proj/embedded-cross.git;a=blob;f=dev-libs/libgcrypt/files/libgcrypt-pkgconfig-support.patch
[7] http://git.yoctoproject.org/cgit/cgit.cgi/poky/plain/meta/recipes-core/systemd/systemd_213.bb
[8] https://www.mail-archive.com/systemd-devel at lists.freedesktop.org/msg18966.html
[9] http://lists.busybox.net/pipermail/buildroot/2013-September/078232.html

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Thomas Petazzoni]

Dear Eric Le Bihan,

On Mon, 9 Jun 2014 23:10:36 +0200, Eric Le Bihan wrote:

> - We are stuck with autoreconf, as it is needed to solve the `ln --relative`
>   issue via a patch, which will not be accepted by upstream [8].

If we're stuck with autoreconf due to a patch that will not be accepted
upstream, then I would suggest that we move away from autoreconf, and
turn this patch into something that changes Makefile.in and configure
directly, with a good explanation in the patch description.

Hopefully, ln implementations in distributions will be upgraded, and at
some time, we'll be able to drop the patch.

The drawback with this solution is that if we want to create/backport
other systemd patches that require autoreconf, then we're screwed. So
maybe carrying our copy of libgcrypt.m4 as a patch in systemd sources is
the easiest solution here.

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

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Eric Le Bihan]

Hi!
On Wed, Jun 11, 2014 at 10:56:53AM +0200, Thomas Petazzoni wrote:
> Dear Eric Le Bihan,
>
> On Mon, 9 Jun 2014 23:10:36 +0200, Eric Le Bihan wrote:
>
> > - We are stuck with autoreconf, as it is needed to solve the `ln --relative`
> >   issue via a patch, which will not be accepted by upstream [8].
>
> If we're stuck with autoreconf due to a patch that will not be accepted
> upstream, then I would suggest that we move away from autoreconf, and
> turn this patch into something that changes Makefile.in and configure
> directly, with a good explanation in the patch description.
>
> Hopefully, ln implementations in distributions will be upgraded, and at
> some time, we'll be able to drop the patch.
Maybe there will be a backport of coreutils for Debian Wheezy ;-)
>
> The drawback with this solution is that if we want to create/backport
> other systemd patches that require autoreconf, then we're screwed. So
> maybe carrying our copy of libgcrypt.m4 as a patch in systemd sources is
> the easiest solution here.
I think this is the more future-proof solution. I'll post a patch implementing
this.

Best regards,
ELB

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Yann E. MORIN]

Eric, All,

On 2014-06-11 23:04 +0200, Eric Le Bihan spake thusly:
> On Wed, Jun 11, 2014 at 10:56:53AM +0200, Thomas Petazzoni wrote:
> > On Mon, 9 Jun 2014 23:10:36 +0200, Eric Le Bihan wrote:
> > > - We are stuck with autoreconf, as it is needed to solve the `ln --relative`
> > >   issue via a patch, which will not be accepted by upstream [8].
> >
> > If we're stuck with autoreconf due to a patch that will not be accepted
> > upstream, then I would suggest that we move away from autoreconf, and
> > turn this patch into something that changes Makefile.in and configure
> > directly, with a good explanation in the patch description.
> >
> > Hopefully, ln implementations in distributions will be upgraded, and at
> > some time, we'll be able to drop the patch.
> Maybe there will be a backport of coreutils for Debian Wheezy ;-)
> >
> > The drawback with this solution is that if we want to create/backport
> > other systemd patches that require autoreconf, then we're screwed. So
> > maybe carrying our copy of libgcrypt.m4 as a patch in systemd sources is
> > the easiest solution here.
> I think this is the more future-proof solution. I'll post a patch implementing
> this.

Can we just use the ln wrapper as suggested in the referenced thread?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Eric Le Bihan]

Hi!
On Wed, Jun 11, 2014 at 11:13:03PM +0200, Yann E. MORIN wrote:
> Eric, All,
>
> On 2014-06-11 23:04 +0200, Eric Le Bihan spake thusly:
> > On Wed, Jun 11, 2014 at 10:56:53AM +0200, Thomas Petazzoni wrote:
> > > On Mon, 9 Jun 2014 23:10:36 +0200, Eric Le Bihan wrote:
> > > > - We are stuck with autoreconf, as it is needed to solve the `ln --relative`
> > > >   issue via a patch, which will not be accepted by upstream [8].
> > >
> > > If we're stuck with autoreconf due to a patch that will not be accepted
> > > upstream, then I would suggest that we move away from autoreconf, and
> > > turn this patch into something that changes Makefile.in and configure
> > > directly, with a good explanation in the patch description.
> > >
> > > Hopefully, ln implementations in distributions will be upgraded, and at
> > > some time, we'll be able to drop the patch.
> > Maybe there will be a backport of coreutils for Debian Wheezy ;-)
> > >
> > > The drawback with this solution is that if we want to create/backport
> > > other systemd patches that require autoreconf, then we're screwed. So
> > > maybe carrying our copy of libgcrypt.m4 as a patch in systemd sources is
> > > the easiest solution here.
> > I think this is the more future-proof solution. I'll post a patch implementing
> > this.
>
> Can we just use the ln wrapper as suggested in the referenced thread?
Should it be provided by the systemd package or should we create a new one?
Are there other packages that require such wrappers?

Best regards,
ELB

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Yann E. MORIN]

Eric, Thomas, Peter, All,

Thomas, Peter, you input is requested, below...

On 2014-06-11 23:47 +0200, Eric Le Bihan spake thusly:
> On Wed, Jun 11, 2014 at 11:13:03PM +0200, Yann E. MORIN wrote:
> > On 2014-06-11 23:04 +0200, Eric Le Bihan spake thusly:
> > > On Wed, Jun 11, 2014 at 10:56:53AM +0200, Thomas Petazzoni wrote:
> > > > On Mon, 9 Jun 2014 23:10:36 +0200, Eric Le Bihan wrote:
> > > > > - We are stuck with autoreconf, as it is needed to solve the `ln --relative`
> > > > >   issue via a patch, which will not be accepted by upstream [8].
> > > >
> > > > If we're stuck with autoreconf due to a patch that will not be accepted
> > > > upstream, then I would suggest that we move away from autoreconf, and
> > > > turn this patch into something that changes Makefile.in and configure
> > > > directly, with a good explanation in the patch description.
> > > >
> > > > Hopefully, ln implementations in distributions will be upgraded, and at
> > > > some time, we'll be able to drop the patch.
> > > Maybe there will be a backport of coreutils for Debian Wheezy ;-)
> > > >
> > > > The drawback with this solution is that if we want to create/backport
> > > > other systemd patches that require autoreconf, then we're screwed. So
> > > > maybe carrying our copy of libgcrypt.m4 as a patch in systemd sources is
> > > > the easiest solution here.
> > > I think this is the more future-proof solution. I'll post a patch implementing
> > > this.
> >
> > Can we just use the ln wrapper as suggested in the referenced thread?
>
> Should it be provided by the systemd package or should we create a new one?
> Are there other packages that require such wrappers?

I think if we go that route, we should just bundle it in Buildroot, and
always install it.

After all, all this wrapper does is look for --relative in the
arguments, and if found, emulates it; otherwise, it just calls to the
real ln.

Sounds reasonable to me (although I did not look too closely if the
script was entirely correct.)

But I'd like input from Thomas and Peter on that one.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-06-08

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 11 Jun 2014 23:54:25 +0200, Yann E. MORIN wrote:

> > Should it be provided by the systemd package or should we create a new one?
> > Are there other packages that require such wrappers?
> 
> I think if we go that route, we should just bundle it in Buildroot, and
> always install it.
> 
> After all, all this wrapper does is look for --relative in the
> arguments, and if found, emulates it; otherwise, it just calls to the
> real ln.
> 
> Sounds reasonable to me (although I did not look too closely if the
> script was entirely correct.)
> 
> But I'd like input from Thomas and Peter on that one.

Well, I'm not sure I want to include a wrapper that will wrap *all* ln
calls, just for the sake of fixing one package. I probably prefer to
patch that package only.

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