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

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

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