Re: core-updates freeze

[Timothy Sample]

Hi Marius,

Marius Bakke  writes:

> Timothy Sample  writes:
>
>> From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
>> From: Timothy Sample 
>> Date: Tue, 16 Jul 2019 10:04:58 -0400
>> Subject: [PATCH] system: Write the timezone to /etc/timezone.
>>
>> * gnu/system.scm (operating-system-etc-service): Write the operating
>> system timezone to /etc/timezone.
>>
>> Fixes .
>> ---
>>  gnu/system.scm | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/gnu/system.scm b/gnu/system.scm
>> index 01be1243fe..75ac0632bb 100644
>> --- a/gnu/system.scm
>> +++ b/gnu/system.scm
>> @@ -716,6 +716,7 @@ fi\n")))
>> ;; to certain networks.  Some discussion at
>> ;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
>> ("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
>> +   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
>> ("localtime" ,(file-append tzdata "/share/zoneinfo/"
>>(operating-system-timezone os)))
>> ("sudoers" ,(operating-system-sudoers-file os))
>> -- 
>> 2.22.0
>>
>>
>> Thoughts?
>
> Looks good to me.  Perhaps leave a comment that Glib uses this file to
> figure out the current timezone?

Pushed with a comment about GLib that references this discussion.

> Though I notice Debian 10 creates /etc/timezone too, so maybe we just
> missed a FHS update somewhere.

I looked at FHS 3.0, which is the latest one I could find, and it didn’t
say anything.  Searching around, the file has been around for a long
time.  It used to be mentioned in the systemd documentation, but now the
docs talk about /etc/localtime being a symlink instead [1].  According
to a Qt comment [2], Debian used to do what we are doing now until
Jessie, then it made /etc/localtime a symlink (I presume they kept
/etc/timezone for compatibility).  All in all, it looks like a lot of
other projects are moving away from /etc/timezone, so maybe we bet on
the wrong horse, so to speak.  It looks like Flatpack has started using
it recently, though [3].  Either way, it should be easy enough to adapt
if projects drop support for /etc/timezone.

[1] 
https://github.com/systemd/systemd/commit/608da9e9b56be83ac394ea7a19cbdacab94f6642
[2] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=110e49c9cecca34dfacad33d19e04612cc2671b2
[3] https://github.com/flatpak/flatpak/issues/2190

-- Tim

Re: core-updates freeze

[Marius Bakke]

Timothy Sample  writes:

> Hi,
>
> Kei Kebreau  writes:
>
>> Marius Bakke  writes:
>>
>>> I'm not sure what we should do about it.  Thoughts?
>>>
>>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>>> Alternatively, you could make /etc/localtime a symbolic link to
>>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>>> reboot.
>>
>> I can confirm that both of these methods work, so crude work-arounds
>> include
>>
>>   1.  Setting the system's configured time zone in /etc/timezone
>
> This is my vote for two reasons.  First, it seems more elegant.  If I
> want to know the timezone name, I should look it up directly, and not
> chase symlinks around looking for some canonical timezone file.  I think
> this is the closest thing to a “standard way to get the name of the
> system timezone”  (here,
> “standard” means “well, I guess at least Gentoo does it”).  Second, it
> is a one-liner for us:
>
> From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
> From: Timothy Sample 
> Date: Tue, 16 Jul 2019 10:04:58 -0400
> Subject: [PATCH] system: Write the timezone to /etc/timezone.
>
> * gnu/system.scm (operating-system-etc-service): Write the operating
> system timezone to /etc/timezone.
>
> Fixes .
> ---
>  gnu/system.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index 01be1243fe..75ac0632bb 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -716,6 +716,7 @@ fi\n")))
> ;; to certain networks.  Some discussion at
> ;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
> ("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
> +   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
> ("localtime" ,(file-append tzdata "/share/zoneinfo/"
>(operating-system-timezone os)))
> ("sudoers" ,(operating-system-sudoers-file os))
> -- 
> 2.22.0
>
>
> Thoughts?

Looks good to me.  Perhaps leave a comment that Glib uses this file to
figure out the current timezone?

Though I notice Debian 10 creates /etc/timezone too, so maybe we just
missed a FHS update somewhere.


signature.asc
Description: PGP signature

Re: core-updates freeze

[Timothy Sample]

Hi,

Kei Kebreau  writes:

> Marius Bakke  writes:
>
>> I'm not sure what we should do about it.  Thoughts?
>>
>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>> Alternatively, you could make /etc/localtime a symbolic link to
>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>> reboot.
>
> I can confirm that both of these methods work, so crude work-arounds
> include
>
>   1.  Setting the system's configured time zone in /etc/timezone

This is my vote for two reasons.  First, it seems more elegant.  If I
want to know the timezone name, I should look it up directly, and not
chase symlinks around looking for some canonical timezone file.  I think
this is the closest thing to a “standard way to get the name of the
system timezone”  (here,
“standard” means “well, I guess at least Gentoo does it”).  Second, it
is a one-liner for us:

>From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
From: Timothy Sample 
Date: Tue, 16 Jul 2019 10:04:58 -0400
Subject: [PATCH] system: Write the timezone to /etc/timezone.

* gnu/system.scm (operating-system-etc-service): Write the operating
system timezone to /etc/timezone.

Fixes .
---
 gnu/system.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/system.scm b/gnu/system.scm
index 01be1243fe..75ac0632bb 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -716,6 +716,7 @@ fi\n")))
;; to certain networks.  Some discussion at
;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
+   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
("localtime" ,(file-append tzdata "/share/zoneinfo/"
   (operating-system-timezone os)))
("sudoers" ,(operating-system-sudoers-file os))
-- 
2.22.0


Thoughts?


-- Tim

Re: core-updates freeze

[Kei Kebreau]

Kei Kebreau  writes:

> Marius Bakke  writes:
>
>> Kei Kebreau  writes:
>>
>>> Ludovic Courtès  writes:
>>>
 Hello!

 Marius Bakke  skribis:

> The core-updates branch is now (almost!) ready for prime time.

 Yay!

> This is turning out to be one of the biggest merges ever[*], currently
> representing 433 commits from 15 people, with commits dating back to
> September last year(!).

 Ouch!  This is both impressive and… frightening.  :-)

> Some of the highlights from this branch include:
>
> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
> * GCC7 is now the default compiler
> * The 'CMake' package comes with full documentation
> * OpenSSL 1.1 is now the default 'openssl' package
> * GNOME 3.30
> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...

 Exciting!

> To give everyone a little time to brush up any last-minute patches, as
> well as let the CI catch up with 'master' and 'staging', I suggest we
> set a final date for starting the full CI build on *July 9th*, i.e six
> days from now.  At which point the branch becomes bugfix-only, no new
> updates or features.
>
> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
> which comes with desirable security and OpenSSL 1.1 compatibility fixes.

 July 9th is now behind us, where are we?  I’m currently running:

   guix pull --branch=core-updates -p /tmp/core-updates

 so I can give it a shot with my profile and my system.

 Is there anything people should pay attention to, or any specific tests
 we should make?

 Thank you!

 Ludo’.
>>>
>>> I must say, the GNOME 3.30 changes haven't been pushed to core-updates
>>> yet.  There were a number of issues with the updated GNOME desktop as I
>>> last built it.  For example, the displayed time was incorrect, and the
>>> "night light" feature didn't work.  Other issues included failing tests
>>> that I couldn't figure out and just disabled to get the building to
>>> finish.
>>
>> I think many of the failing tests should be fixed with commit
>> ee46474d54a661e87cd501c3fde6e572b3423a60.
>>
>
> Some recent core-updates commits (possibly including this one) fixed at
> least one package's tests.  I'll re-enable a few others and see where
> that leads.
>
>> Wrt the time zone issue, it appears recent Glib refuses to function if
>> /etc/localtime is not a symbolic link, reminiscent of 
>> :
>>
>> https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/glib/gtimezone.c#L443
>>
>> I'm not sure what we should do about it.  Thoughts?
>>
>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>> Alternatively, you could make /etc/localtime a symbolic link to
>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>> reboot.
>
> I can confirm that both of these methods work, so crude work-arounds
> include
>
>   1.  Setting the system's configured time zone in /etc/timezone
>   2.  Making /etc/localtime a symbolic link to the correct tzdata files
>   3.  Patching glib to read from /etc/localtime if it is a symlink or a
>   file
>
> There are some other issues that I run into immediately, such as an
> Emacs that fails to start when run under X.org (error log attached) and
> a Gnome Control Center that crashes almost immediately after running.
> Any ideas what may be going on here?  I've attached error logs for
> both.
>

The locale issues went away when I updated my profile that was still
based on glibc version 2.28.  Still investigating other issues.

> Thanks,
> Kei


signature.asc
Description: PGP signature

Re: core-updates freeze

[Kei Kebreau]

Marius Bakke  writes:

> Kei Kebreau  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Hello!
>>>
>>> Marius Bakke  skribis:
>>>
 The core-updates branch is now (almost!) ready for prime time.
>>>
>>> Yay!
>>>
 This is turning out to be one of the biggest merges ever[*], currently
 representing 433 commits from 15 people, with commits dating back to
 September last year(!).
>>>
>>> Ouch!  This is both impressive and… frightening.  :-)
>>>
 Some of the highlights from this branch include:

 * jannekes long-awaited new reduced binary seeds for i686 and x86_64
 * GCC7 is now the default compiler
 * The 'CMake' package comes with full documentation
 * OpenSSL 1.1 is now the default 'openssl' package
 * GNOME 3.30
 * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>>>
>>> Exciting!
>>>
 To give everyone a little time to brush up any last-minute patches, as
 well as let the CI catch up with 'master' and 'staging', I suggest we
 set a final date for starting the full CI build on *July 9th*, i.e six
 days from now.  At which point the branch becomes bugfix-only, no new
 updates or features.

 July 9th incidentally gives us just enough time to get Python 3.7.4 too,
 which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>>>
>>> July 9th is now behind us, where are we?  I’m currently running:
>>>
>>>   guix pull --branch=core-updates -p /tmp/core-updates
>>>
>>> so I can give it a shot with my profile and my system.
>>>
>>> Is there anything people should pay attention to, or any specific tests
>>> we should make?
>>>
>>> Thank you!
>>>
>>> Ludo’.
>>
>> I must say, the GNOME 3.30 changes haven't been pushed to core-updates
>> yet.  There were a number of issues with the updated GNOME desktop as I
>> last built it.  For example, the displayed time was incorrect, and the
>> "night light" feature didn't work.  Other issues included failing tests
>> that I couldn't figure out and just disabled to get the building to
>> finish.
>
> I think many of the failing tests should be fixed with commit
> ee46474d54a661e87cd501c3fde6e572b3423a60.
>

Some recent core-updates commits (possibly including this one) fixed at
least one package's tests.  I'll re-enable a few others and see where
that leads.

> Wrt the time zone issue, it appears recent Glib refuses to function if
> /etc/localtime is not a symbolic link, reminiscent of 
> :
>
> https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/glib/gtimezone.c#L443
>
> I'm not sure what we should do about it.  Thoughts?
>
> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
> Alternatively, you could make /etc/localtime a symbolic link to
> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
> reboot.

I can confirm that both of these methods work, so crude work-arounds
include

  1.  Setting the system's configured time zone in /etc/timezone
  2.  Making /etc/localtime a symbolic link to the correct tzdata files
  3.  Patching glib to read from /etc/localtime if it is a symlink or a
  file

There are some other issues that I run into immediately, such as an
Emacs that fails to start when run under X.org (error log attached) and
a Gnome Control Center that crashes almost immediately after running.
Any ideas what may be going on here?  I've attached error logs for
both.

Thanks,
Kei

/gnu/store/z2nfaaya7spyji777xn9af9zf5zc6c9k-emacs-26.2/bin/emacs-26.2: 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libm.so.6: version 
`GLIBC_2.29' not found (required by 
/gnu/store/rnck7i21ir6ghvbldk31v0gdyb77g8f6-librsvg-2.40.20/lib/librsvg-2.so.2)
#0  0x7638d8a1 in free ()
   from /gnu/store/n0zcbqrv8fmhgmi6k6mg57kvy19wfdzz-glibc-2.29/lib/libc.so.6
#1  0x77ecf1a5 in g_unix_mount_free ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#2  0x00481020 in get_primary_disc_info_start ()
#3  0x00481c93 in cc_info_overview_panel_init ()
#4  0x77de1603 in g_type_create_instance ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#5  0x77dc20a8 in g_object_new_internal ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#6  0x77dc3e00 in g_object_new_valist ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#7  0x77dc415c in g_object_new ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#8  0x00459e6b in set_active_panel_from_id.isra ()
#9  0x77dbf561 in g_cclosure_marshal_VOID__STRINGv ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#10 0x77dbcd86 in _g_closure_invoke_va ()
   from 
/gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#11 0x77dd8856 in

Re: core-updates freeze

[Marius Bakke]

Kei Kebreau  writes:

> Ludovic Courtès  writes:
>
>> Hello!
>>
>> Marius Bakke  skribis:
>>
>>> The core-updates branch is now (almost!) ready for prime time.
>>
>> Yay!
>>
>>> This is turning out to be one of the biggest merges ever[*], currently
>>> representing 433 commits from 15 people, with commits dating back to
>>> September last year(!).
>>
>> Ouch!  This is both impressive and… frightening.  :-)
>>
>>> Some of the highlights from this branch include:
>>>
>>> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
>>> * GCC7 is now the default compiler
>>> * The 'CMake' package comes with full documentation
>>> * OpenSSL 1.1 is now the default 'openssl' package
>>> * GNOME 3.30
>>> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>>
>> Exciting!
>>
>>> To give everyone a little time to brush up any last-minute patches, as
>>> well as let the CI catch up with 'master' and 'staging', I suggest we
>>> set a final date for starting the full CI build on *July 9th*, i.e six
>>> days from now.  At which point the branch becomes bugfix-only, no new
>>> updates or features.
>>>
>>> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
>>> which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>>
>> July 9th is now behind us, where are we?  I’m currently running:
>>
>>   guix pull --branch=core-updates -p /tmp/core-updates
>>
>> so I can give it a shot with my profile and my system.
>>
>> Is there anything people should pay attention to, or any specific tests
>> we should make?
>>
>> Thank you!
>>
>> Ludo’.
>
> I must say, the GNOME 3.30 changes haven't been pushed to core-updates
> yet.  There were a number of issues with the updated GNOME desktop as I
> last built it.  For example, the displayed time was incorrect, and the
> "night light" feature didn't work.  Other issues included failing tests
> that I couldn't figure out and just disabled to get the building to
> finish.

I think many of the failing tests should be fixed with commit
ee46474d54a661e87cd501c3fde6e572b3423a60.

Wrt the time zone issue, it appears recent Glib refuses to function if
/etc/localtime is not a symbolic link, reminiscent of 
:

https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/glib/gtimezone.c#L443

I'm not sure what we should do about it.  Thoughts?

Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
Alternatively, you could make /etc/localtime a symbolic link to
$tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
reboot.


signature.asc
Description: PGP signature

Re: core-updates freeze

[Kei Kebreau]

Ludovic Courtès  writes:

> Hello!
>
> Marius Bakke  skribis:
>
>> The core-updates branch is now (almost!) ready for prime time.
>
> Yay!
>
>> This is turning out to be one of the biggest merges ever[*], currently
>> representing 433 commits from 15 people, with commits dating back to
>> September last year(!).
>
> Ouch!  This is both impressive and… frightening.  :-)
>
>> Some of the highlights from this branch include:
>>
>> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
>> * GCC7 is now the default compiler
>> * The 'CMake' package comes with full documentation
>> * OpenSSL 1.1 is now the default 'openssl' package
>> * GNOME 3.30
>> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...
>
> Exciting!
>
>> To give everyone a little time to brush up any last-minute patches, as
>> well as let the CI catch up with 'master' and 'staging', I suggest we
>> set a final date for starting the full CI build on *July 9th*, i.e six
>> days from now.  At which point the branch becomes bugfix-only, no new
>> updates or features.
>>
>> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
>> which comes with desirable security and OpenSSL 1.1 compatibility fixes.
>
> July 9th is now behind us, where are we?  I’m currently running:
>
>   guix pull --branch=core-updates -p /tmp/core-updates
>
> so I can give it a shot with my profile and my system.
>
> Is there anything people should pay attention to, or any specific tests
> we should make?
>
> Thank you!
>
> Ludo’.

I must say, the GNOME 3.30 changes haven't been pushed to core-updates
yet.  There were a number of issues with the updated GNOME desktop as I
last built it.  For example, the displayed time was incorrect, and the
"night light" feature didn't work.  Other issues included failing tests
that I couldn't figure out and just disabled to get the building to
finish.

If people would like to see my progress, I can send a patch series to
the guix-patches list, but working on this alone has been a slow process
thanks to the long rebuilds that come from working on this branch.  I'd
rather not push a partially-working GNOME, but I also don't want to
hinder the merging of core-updates, so please let me know what course of
action is preferred here.

Thanks,
Kei

Re: core-updates freeze

[Ludovic Courtès]

Hello!

Marius Bakke  skribis:

> The core-updates branch is now (almost!) ready for prime time.

Yay!

> This is turning out to be one of the biggest merges ever[*], currently
> representing 433 commits from 15 people, with commits dating back to
> September last year(!).

Ouch!  This is both impressive and… frightening.  :-)

> Some of the highlights from this branch include:
>
> * jannekes long-awaited new reduced binary seeds for i686 and x86_64
> * GCC7 is now the default compiler
> * The 'CMake' package comes with full documentation
> * OpenSSL 1.1 is now the default 'openssl' package
> * GNOME 3.30
> * glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...

Exciting!

> To give everyone a little time to brush up any last-minute patches, as
> well as let the CI catch up with 'master' and 'staging', I suggest we
> set a final date for starting the full CI build on *July 9th*, i.e six
> days from now.  At which point the branch becomes bugfix-only, no new
> updates or features.
>
> July 9th incidentally gives us just enough time to get Python 3.7.4 too,
> which comes with desirable security and OpenSSL 1.1 compatibility fixes.

July 9th is now behind us, where are we?  I’m currently running:

  guix pull --branch=core-updates -p /tmp/core-updates

so I can give it a shot with my profile and my system.

Is there anything people should pay attention to, or any specific tests
we should make?

Thank you!

Ludo’.

core-updates freeze

[Marius Bakke]

Guix,

The core-updates branch is now (almost!) ready for prime time.

This is turning out to be one of the biggest merges ever[*], currently
representing 433 commits from 15 people, with commits dating back to
September last year(!).

Some of the highlights from this branch include:

* jannekes long-awaited new reduced binary seeds for i686 and x86_64
* GCC7 is now the default compiler
* The 'CMake' package comes with full documentation
* OpenSSL 1.1 is now the default 'openssl' package
* GNOME 3.30
* glibc 2.29, binutils 2.32, gettext 0.20, bash 5.0.7, gawk 5.0.1, ...

To give everyone a little time to brush up any last-minute patches, as
well as let the CI catch up with 'master' and 'staging', I suggest we
set a final date for starting the full CI build on *July 9th*, i.e six
days from now.  At which point the branch becomes bugfix-only, no new
updates or features.

July 9th incidentally gives us just enough time to get Python 3.7.4 too,
which comes with desirable security and OpenSSL 1.1 compatibility fixes.

Thoughts?

[*] counting only merges to 'master'


signature.asc
Description: PGP signature

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Andreas Enge  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’.

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=0x5e68, mask=0x0) at pixman-fast-path.c:2191
2191t0 = ((sr << 16) & 0x00FF) | ((sg << 8) & 0xFF00) |
(gdb) bt
#0  fast_fetch_r5g6b5 (iter=0x5e68, 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) & 0x00FF) | ((sg << 8) & 0xFF00) |
 (sb & 0xFF) | 0xFF00;

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]

l...@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!

[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]

l...@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 ) and Hydra will
soon start rebuilding the ‘core’ package subset.

Ludo’.

‘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’.