core-updates freeze

core-updates freeze

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

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'

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates freeze

[Ludovic Courtès]

Hello!

Marius Bakke <mbakke@fastmail.com> 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’.

Re: core-updates freeze

[Kei Kebreau]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Marius Bakke <mbakke@fastmail.com> 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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

Kei Kebreau <kkebreau@posteo.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello!
>>
>> Marius Bakke <mbakke@fastmail.com> 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://issues.guix.gnu.org/issue/35746>:

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates freeze

[Kei Kebreau]

[-- Attachment #1.1: Type: text/plain, Size: 3632 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Kei Kebreau <kkebreau@posteo.net> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Marius Bakke <mbakke@fastmail.com> 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://issues.guix.gnu.org/issue/35746>:
>
> 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


[-- Attachment #1.2: emacs-error-message.log --]
[-- Type: text/plain, Size: 265 bytes --]

/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)

[-- Attachment #1.3: gnome-control-center-backtrace.log --]
[-- Type: text/plain, Size: 4063 bytes --]

#0  0x00007ffff638d8a1 in free ()
   from /gnu/store/n0zcbqrv8fmhgmi6k6mg57kvy19wfdzz-glibc-2.29/lib/libc.so.6
#1  0x00007ffff7ecf1a5 in g_unix_mount_free ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#2  0x0000000000481020 in get_primary_disc_info_start ()
#3  0x0000000000481c93 in cc_info_overview_panel_init ()
#4  0x00007ffff7de1603 in g_type_create_instance ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#5  0x00007ffff7dc20a8 in g_object_new_internal ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#6  0x00007ffff7dc3e00 in g_object_new_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#7  0x00007ffff7dc415c in g_object_new ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#8  0x0000000000459e6b in set_active_panel_from_id.isra ()
#9  0x00007ffff7dbf561 in g_cclosure_marshal_VOID__STRINGv ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#10 0x00007ffff7dbcd86 in _g_closure_invoke_va ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#11 0x00007ffff7dd8856 in g_signal_emit_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#12 0x00007ffff7dd8f32 in g_signal_emit ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#13 0x00000000004587fb in row_activated_cb ()
#14 0x00007ffff7dbfb15 in g_cclosure_marshal_VOID__OBJECTv ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#15 0x00007ffff7dbcd86 in _g_closure_invoke_va ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#16 0x00007ffff7dd8856 in g_signal_emit_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#17 0x00007ffff7dd8f32 in g_signal_emit ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#18 0x00007ffff7dbcd86 in _g_closure_invoke_va ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#19 0x00007ffff7dd8856 in g_signal_emit_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#20 0x00007ffff7dd93e2 in g_signal_emit_by_name ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#21 0x0000000000458d5c in cc_panel_list_set_active_panel ()
#22 0x000000000045a87f in cc_window_constructed ()
#23 0x00007ffff7dc2250 in g_object_new_internal ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#24 0x00007ffff7dc3e00 in g_object_new_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#25 0x00007ffff7dc415c in g_object_new ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#26 0x000000000045aba2 in cc_window_new ()
#27 0x0000000000455504 in cc_application_startup ()
#28 0x00007ffff7dbcb4d in g_closure_invoke ()
.0.so.0
#29 0x00007ffff7dcfdde in signal_emit_unlocked_R ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#30 0x00007ffff7dd8575 in g_signal_emit_valist ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#31 0x00007ffff7dd8f32 in g_signal_emit ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgobject-2.0.so.0
#32 0x00007ffff7ed96a2 in g_application_register ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#33 0x00007ffff7ed9a55 in g_application_real_local_command_line ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#34 0x00007ffff7ed9d96 in g_application_run ()
   from /gnu/store/dgypzsgha0i6xq657ijgwawlpaaqagck-glib-2.60.5/lib/libgio-2.0.so.0
#35 0x0000000000454bff in main ()

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: core-updates freeze

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

Kei Kebreau <kkebreau@posteo.net> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Kei Kebreau <kkebreau@posteo.net> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hello!
>>>>
>>>> Marius Bakke <mbakke@fastmail.com> 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://issues.guix.gnu.org/issue/35746>:
>>
>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: core-updates freeze

[Timothy Sample]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Hi,

Kei Kebreau <kkebreau@posteo.net> writes:

> Marius Bakke <mbakke@fastmail.com> 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” <https://issues.guix.gnu.org/issue/35746#9> (here,
“standard” means “well, I guess at least Gentoo does it”).  Second, it
is a one-liner for us:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: the patch --]
[-- Type: text/x-patch, Size: 1050 bytes --]

From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
From: Timothy Sample <samplet@ngyro.com>
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 <https://bugs.gnu.org/35746>.
---
 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


[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


Thoughts?


-- Tim

Re: core-updates freeze

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi,
>
> Kei Kebreau <kkebreau@posteo.net> writes:
>
>> Marius Bakke <mbakke@fastmail.com> 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” <https://issues.guix.gnu.org/issue/35746#9> (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 <samplet@ngyro.com>
> 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 <https://bugs.gnu.org/35746>.
> ---
>  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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates freeze

[Timothy Sample]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Timothy Sample <samplet@ngyro.com> writes:
>
>> From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
>> From: Timothy Sample <samplet@ngyro.com>
>> 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 <https://bugs.gnu.org/35746>.
>> ---
>>  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

core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

Guix,

The 'core-updates' branch is ready for testing!  This is a very early
stage, so many substitutes are missing.  Consider yourself warned ;-)

I have compiled a summary of the changes below.  The package updates are
too numerous to list here; try `git shortlog -n master..core-updates`
for the scoop.

We are still waiting for armhf to catch up on the CI, as well as
<https://issues.guix.info/issue/36535> before starting the full
rebuild.  I will send another email when that happens, along with a
status update.

* Build system changes
** 'python-build-system' runs tests after installing the package,
   instead of in between the 'build' and 'install' phases, to improve
   reproducibility.
** 'python-build-system' does not wrap already-wrapped executables.
** 'python-build-system' has a (python-version ...) procedure that
   returns the major+minor version of a given python package.
** 'meson-build-system' produces optimized binaries with debugging
   symbols by default, similar to 'cmake-build-system'.
** 'meson-build-system' no longer attempts to run Autotools bootstrap
   scripts.
** 'gnu-build-system' (and those inheriting from it) has deterministic
   behavior in some corner cases (<https://issues.guix.info/35387).
** gnu-build-system copies license files to all outputs instead of just
   "out".  It now also works for out-of-source builds.
** (guix build utils) has a new 'wrap-script' procedure that replaces
   the shebang in scripts in a language-aware manner, as an alternative
   to the shell wrapper created by 'wrap-program'.
** (invoke ...) from the same module now reports errors in a
   human-friendly way, instead displaying a long stack trace.
** There is also a new (invoke/quiet ...) that swallows program output,
   unless it fails.  The return value is unspecified.

* Toolchain changes
** On i686 and x86_64, the "binary seeds" at the root of the dependency
   graph no longer includes GCC, glibc, and binutils.  Instead they are
   built from source using a new GNU Mes based toolchain, reducing the
   set of trusted bootstrap binaries from ~250MiB to ~130MiB.
** GCC 7 became the default compiler.  Consequently, C_INCLUDE_PATH and
   CPLUS_INCLUDE_PATH are no longer set in the build environment.
   Packages that rely on those variables or their CROSS_ counterparts
   will need to be adjusted to use {CROSS_,}CPATH instead.
** GNU/Hurd no longer uses a special glibc variant.
** Guile was updated to 2.2.6, and libgc to 7.6.12.
** Linux-Libre headers was updated to 4.19.57.
** Glibc was updated to 2.29.
** Binutils was updated to 2.32.
** coreutils was updated to 8.31.
** Bash was updated to 5.0.7.
** Grep 3.3, Gawk 5.0.1, Gettext 0.20.1, diffutils 3.7, Bison 3.4.1, ...

Other noteworthy changes:
** GNOME was updated to 3.30.
** OpenSSL 1.1.1 is the default 'openssl' package.
** Many packages were migrated to use Python 3 instead of Python 2.
** cURL and GNU SASL use MIT Kerberos instead of GNU Security Services.
** Python 2 builds reproducibly.
** Python (2 & 3) no longer uses a bundled copy of Expat.
** CMake was updated 3.14.5.
** CMake comes with documentation, too.
** Perl was updated to 5.30.0.
** Python was updated to 3.7.4.
** Boost was updated to 1.70.0.
** SQLite was updated to 3.28.0.
** Pytest was updated to 4.4.2.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Ludovic Courtès]

Hello!

Marius Bakke <mbakke@fastmail.com> skribis:

> The 'core-updates' branch is ready for testing!  This is a very early
> stage, so many substitutes are missing.  Consider yourself warned ;-)

Yay!

> ** GNU/Hurd no longer uses a special glibc variant.

That’s the case since the previous ‘core-updates’ merge.  :-)

At any rate, thanks for the news items, it’s great to rediscover what’s
actually been done months ago!

Ludo’.

Re: core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> The 'core-updates' branch is ready for testing!  This is a very early
>> stage, so many substitutes are missing.  Consider yourself warned ;-)
>
> Yay!
>
>> ** GNU/Hurd no longer uses a special glibc variant.
>
> That’s the case since the previous ‘core-updates’ merge.  :-)

Whoops!

There is another important change that I forgot to list as well: glibc
no longer provides Sun/ONC RPC support, so many packages need to migrate
to 'libtirpc' and/or 'rpcsvc-proto'.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

I've sent a few patches to fix a couple of build issues on the
core-updates branch [1][2].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36641
2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36643

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

Hello Guix!

The 'core-updates' branch is now in a "feature freeze" after a long ...
thawing period.  That means that there will be no more world rebuilding
changes apart from bug fixes[*].

It is expected to start the full rebuild in a few days once the
bootstrap is complete on AArch64 and ARMv7, which are unfortunately
lacking in compute power at the moment (side note: if you have hardware
to spare, consider donating!).

The branch currently represents 676 commits by 26 people.  Some
highlights from this round:

* Guix runs natively on GNU/Hurd.
* Guix System can be cross-compiled for foreign architectures.
* The distribution is built with Guile 3.0.
* GNOME 3.34 (on a separate branch, will get merged shortly).

Significant package updates:

* glibc 2.31
* Python 3.8.2
* Ruby 2.6.5
* TeX Live 2019

Other changes that may require adjusting third-party channels:

* "libjpeg" has been deprecated in favor of "libjpeg-turbo".
* "util-linux" gained a "lib" output for significant size savings.
* Build systems now set C_INCLUDE_PATH and CPLUS_INCLUDE_PATH instead of
  CPATH.
* Any package that uses libcurl now respects SSL_CERT_DIR and
  SSL_CERT_FILE.

Thanks to everyone who contributed to this branch.  Let the rebuilds
begin!

[*] There are problems with OpenSSL 1.1.1e and we might take on 1.1.1f
if it is released before the full rebuild starts:
https://mta.openssl.org/pipermail/openssl-project/2020-March/001919.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Marius Bakke writes:

> The branch currently represents 676 commits by 26 people.  Some
> highlights from this round:
>
> * Guix runs natively on GNU/Hurd.
> * Guix System can be cross-compiled for foreign architectures.
> * The distribution is built with Guile 3.0.
> * GNOME 3.34 (on a separate branch, will get merged shortly).

These are exciting changes!  Let's also not forget:

 * for x86 and x86_64: another reduction of the bootstrap binary seed by
roughly %0%, to ~60MB!

> Thanks to everyone who contributed to this branch.  Let the rebuilds
> begin!

\o/

Thanks,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Marius Bakke writes:
>
>> The branch currently represents 676 commits by 26 people.  Some
>> highlights from this round:
>>
>> * Guix runs natively on GNU/Hurd.
>> * Guix System can be cross-compiled for foreign architectures.
>> * The distribution is built with Guile 3.0.
>> * GNOME 3.34 (on a separate branch, will get merged shortly).
>
> These are exciting changes!  Let's also not forget:
>
>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
> roughly %0%, to ~60MB!

I knew I was forgetting something important!  Thanks for the reminder.

For those unaware, this means that the set of trusted binaries at the
root of the package graph from which everything else derives is only 60
MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
glibc!

For more information, see jannekes blog post:

https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Marius Bakke writes:

> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
>> Marius Bakke writes:
>>
>>> The branch currently represents 676 commits by 26 people.  Some
>>> highlights from this round:
>>>
>>> * Guix runs natively on GNU/Hurd.
>>> * Guix System can be cross-compiled for foreign architectures.
>>> * The distribution is built with Guile 3.0.
>>> * GNOME 3.34 (on a separate branch, will get merged shortly).
>>
>> These are exciting changes!  Let's also not forget:
>>
>>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
>> roughly %0%, to ~60MB!
>
> I knew I was forgetting something important!  Thanks for the reminder.

:-)

> For those unaware, this means that the set of trusted binaries at the
> root of the package graph from which everything else derives is only 60
> MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
> glibc!

> For more information, see jannekes blog post:
>
> https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html

For the record...it's even better: The GCC, binutils and glibc
removal mentioned above is already in master; so our next release will
bootstrap from ~135MB like blog post mentions!

The Core-updates bootstrap (code named "Scheme-only bootstrap") removes

  Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.

and replaces them with Gash and Gash-Utils!

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

>> For those unaware, this means that the set of trusted binaries at the
>> root of the package graph from which everything else derives is only 60
>> MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
>> glibc!
>
>> For more information, see jannekes blog post:
>>
>> https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html
>
> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

Oh my, that's just incredible, I did not think we were there already!

Thanks for the update.  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

That’s worth a second blog post!  :-)

Ludo’.

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>>
>>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>>
>> and replaces them with Gash and Gash-Utils!
>
> That’s worth a second blog post!  :-)

Yes, let's do that when core-updates is merged into master!  "someone"
is still struggling a bit with the documentation anyway.  ;-)

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> These are exciting changes!  Let's also not forget:
>
>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
> roughly %0%, to ~60MB!

%0%? :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Pierre Neidhardt writes:

> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
>> These are exciting changes!  Let's also not forget:
>>
>>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
>> roughly %0%, to ~60MB!
>
> %0%? :p

Hah -- should have been yeah, 50%!

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
list for those of you who’ll be around.  :-)

The last things I wanted to push for ‘core-updates’ were a reproducible
Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
or all of the aarch64 patches, depending on their status (should not be
a blocker IMO).

So, here’s a plan:

  • Once Efraim has pushed some of the aarch64 patches, do another
    evaluation of the “core” package set for that branch, and check for
    anything wrong.  From there on, forbid full-rebuild changes.

  • Once the “core” subset builds correctly on all the supported
    platforms (those that Hydra supports), merge ‘master’.  Maybe update
    a couple of things like GnuTLS while we’re at it.  From there on
    forbid non-trivial changes.

  • Build all the packages.  (To do that, someone with access to Hydra
    must change the “subset” argument to “all” in the config of the
    ‘core-updates’ jobset.)

  • Fix things.

  • Once most regressions have been addressed and most binaries are
    available, merge ‘core-updates’ into ‘master’.

How does that sound?

Thanks,
Ludo’.

core-updates frozen!

[Leo Famulari]

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
>     evaluation of the “core” package set for that branch, and check for
>     anything wrong.  From there on, forbid full-rebuild changes.

Let's freeze core-updates and try to build it. No more rebuild the world
changes except to fix breakage.

>   • Once the “core” subset builds correctly on all the supported
>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>     a couple of things like GnuTLS while we’re at it.  From there on
>     forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)
> 
>   • Fix things.
> 
>   • Once most regressions have been addressed and most binaries are
>     available, merge ‘core-updates’ into ‘master’.
> 
> How does that sound?
> 
> Thanks,
> Ludo’.
> 

Re: core-updates frozen!

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> > So, here’s a plan:
> > 
> >   • Once Efraim has pushed some of the aarch64 patches, do another
> >     evaluation of the “core” package set for that branch, and check for
> >     anything wrong.  From there on, forbid full-rebuild changes.
> 
> Let's freeze core-updates and try to build it. No more rebuild the world
> changes except to fix breakage.

Once these changes are pushed, I'll start a new evaluation:

http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html

Please, no more rebuild the world changes except to fix breakage in the
core packages.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
>> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> > So, here’s a plan:
>> > 
>> >   • Once Efraim has pushed some of the aarch64 patches, do another
>> >     evaluation of the “core” package set for that branch, and check for
>> >     anything wrong.  From there on, forbid full-rebuild changes.
>> 
>> Let's freeze core-updates and try to build it. No more rebuild the world
>> changes except to fix breakage.
>
> Once these changes are pushed, I'll start a new evaluation:
>
> http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>
> Please, no more rebuild the world changes except to fix breakage in the
> core packages.

xorg-server@1.19.2 was *just* released[0] and contains some important
bug fixes (notably CVE-2017-2624).

[0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

AFAICT it has not been built yet on Hydra since it's not part of the
"core" package set. Is it okay to push?

Unfortunately I have not been able to backport the fix to 1.18.4.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Once these changes are pushed, I'll start a new evaluation:
> >
> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
> >
> > Please, no more rebuild the world changes except to fix breakage in the
> > core packages.
> 
> xorg-server@1.19.2 was *just* released[0] and contains some important
> bug fixes (notably CVE-2017-2624).
> 
> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

It looks like a relatively small set of changes.

> AFAICT it has not been built yet on Hydra since it's not part of the
> "core" package set. Is it okay to push?

xorg-server is not a core package, so I guess it's fine. I'll do the
update when pushing the libgd changes from the thread linked above.

I've been reconfiguring my GuixSD system on core-updates, so I've fixed
and then suffered breakage in a few non-core packages so far :)

At some arbitrary point we have to stop changing the branch and just
build it. Newer important updates will have to be grafted.

> Unfortunately I have not been able to backport the fix to 1.18.4.

Okay, hopefully we can figure it out or copy from another distro.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: core-updates frozen!

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Once these changes are pushed, I'll start a new evaluation:
>> >
>> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>> >
>> > Please, no more rebuild the world changes except to fix breakage in the
>> > core packages.
>> 
>> xorg-server@1.19.2 was *just* released[0] and contains some important
>> bug fixes (notably CVE-2017-2624).
>> 
>> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html
>
> It looks like a relatively small set of changes.
>
>> AFAICT it has not been built yet on Hydra since it's not part of the
>> "core" package set. Is it okay to push?
>
> xorg-server is not a core package, so I guess it's fine. I'll do the
> update when pushing the libgd changes from the thread linked above.

Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
that requires running `autoreconf`. See:

https://lists.x.org/archives/xorg-announce/2017-March/002780.html

> I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> and then suffered breakage in a few non-core packages so far :)

Wow, nice :)

> At some arbitrary point we have to stop changing the branch and just
> build it. Newer important updates will have to be grafted.

Agreed. Let's do a full evaluation once Hydra settles down and then
*really* freeze it ;)

>> Unfortunately I have not been able to backport the fix to 1.18.4.
>
> Okay, hopefully we can figure it out or copy from another distro.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: core-updates frozen!

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Fri, Mar 03, 2017 at 07:33:52PM +0100, Marius Bakke wrote:
> Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
> that requires running `autoreconf`. See:
> 
> https://lists.x.org/archives/xorg-announce/2017-March/002780.html

Ooookay :)

> > I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> > and then suffered breakage in a few non-core packages so far :)
> 
> Wow, nice :)

Note that I haven't succeeded yet. But I did reach the build of GRUB,
which failed to build.

> > At some arbitrary point we have to stop changing the branch and just
> > build it. Newer important updates will have to be grafted.
> 
> Agreed. Let's do a full evaluation once Hydra settles down and then
> *really* freeze it ;)

Okay, but Hydra may never settle down!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]