‘core-updates’ freeze approaching!

‘core-updates’ freeze approaching!

[Ludovic Courtès]

Hi there!

We’ve been pushing a number a fixes, improvements, and package upgrades
in the ‘core-updates’ branch.

I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
building all of it within a day or two.  Any objections?

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
> building all of it within a day or two.  Any objections?

I’ve just pushed a patch to skip the Coreutils test that was causing
intermittent failures (see <http://bugs.gnu.org/21460>) and Hydra will
soon start rebuilding the ‘core’ package subset.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
reverting the libtasn1 upgrade, Hydra is now building all of
‘core-updates’:

  http://hydra.gnu.org/jobset/gnu/core-updates

Please keep an eye on it so we can fix breakage as quickly as possible.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
> reverting the libtasn1 upgrade, Hydra is now building all of
> ‘core-updates’:
>
>   http://hydra.gnu.org/jobset/gnu/core-updates
>
> Please keep an eye on it so we can fix breakage as quickly as possible.

The main (only?) remaining blocker now is pixman, where a test segfaults
on i686:

  https://bugs.freedesktop.org/show_bug.cgi?id=92027

I would not be comfortable just skipping tests since this seems to be a
genuine bug.

If someone else familiar with C could look into it, that’d be great.  To
reproduce it, run (on x86_64 or i686):

  ./pre-inst-env guix build pixman -s i686-linux

on a ‘core-updates’ checkout.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Andreas Enge]

On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>   https://bugs.freedesktop.org/show_bug.cgi?id=92027

The segfault and the valgrind issue happen in different files, so they
do not seem to be related.

The code before the line where gdb places the error:
Program received signal SIGSEGV, Segmentation fault.
fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191
2191		t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
(gdb) bt
#0  fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191

is the following:
    while ((w -= 2) >= 0)
    {
        uint32_t sr, sb, sg, t0, t1;
        uint32_t s = *(const uint32_t *)src;
        src += 2;
        sr = (s >> 8) & 0x00F800F8;
        sb = (s << 3) & 0x00F800F8;
        sg = (s >> 3) & 0x00FC00FC;
        sr |= sr >> 5;
        sb |= sb >> 5;
        sg |= sg >> 6;
        t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
             (sb & 0xFF) | 0xFF000000;

This looks perfectly safe; all treated variables are scalars, so the result
may be wrong, but cannot cause a segfault. A problem with optimisation in gcc?
Or gdb giving a wrong line number? Since pointers are dereferenced before and
after that line.

I also tried to cd into /tmp/nix-build-..., source the environment variables
and run "make check"; then all tests pass (but the build is for i686-linux
on an x86_64-machine, so maybe this does not mean much outside the guix build
container?).

Andreas

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>>   https://bugs.freedesktop.org/show_bug.cgi?id=92027
>
> The segfault and the valgrind issue happen in different files, so they
> do not seem to be related.

[...]

> I also tried to cd into /tmp/nix-build-..., source the environment variables
> and run "make check"; then all tests pass (but the build is for i686-linux
> on an x86_64-machine, so maybe this does not mean much outside the guix build
> container?).

With the patch applied (the patch I attached to the above bug report),
the problem indeed vanishes when outside of the build container, like
you describe.

Without the patch the problem is 100% reproducible both inside and
outside of the build container.

Ludo’.

‘core-updates’ merged!

[Ludovic Courtès]

Hi!

At last ‘core-updates’ is merged!

This brings:

  • Security fixes in icu4c (CVE-2014-6585 and CVE-2015-1270.)

  • libc 2.22–make sure to read
    <https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html>
    before you upgrade!

  • New ‘install-file’ procedure in (guix build utils); consider using
    it where appropriate.

  • Patched tarballs are produced in a deterministic fashion (file
    ordering and time stamps.)

  • The closure size of openssl, curl, libtiff, libx11, libxt has been
    reduced.

  • ‘glib-or-gtk-build-system’ no longer generates icon-theme.cache
    since this is handled during profile generation.  This avoids
    collisions.

  • ‘glibc’ no longer provides bin/bash.

  • Many upgrades.

Ludo’.

Substitutes available for ARM!

[Ludovic Courtès]

Mark notes that I forgot another important thing that comes with the
merge: Substitutes for armhf-linux are now available!  If you have a
Novena or some other ARMv7 machine, enjoy!  :-)

Ludo’.