'core-updates' Q4 2019

'core-updates' Q4 2019

[Marius Bakke]

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

Guix,

As you know, the "quarterly" core-updates rebuild took almost a full
year this previous cycle.  There are already 35 commits on the
'core-updates-next' branch, and I've heard rumors of a GNOME 3.32 branch
lurking somewhere.

To prevent this work from rotting away, I propose that we start the
branch as early as next month.  With luck, users will be able to
cross-compile Guix System for arbitrary toys come December ;-)

Thoughts?

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

Re: 'core-updates' Q4 2019

[Mathieu Othacehe]

Hey Marius,

> To prevent this work from rotting away, I propose that we start the
> branch as early as next month.  With luck, users will be able to
> cross-compile Guix System for arbitrary toys come December ;-)
>
> Thoughts?

Seems like a good plan :)

Mathieu

Re: 'core-updates' Q4 2019

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> To prevent this work from rotting away, I propose that we start the
>> branch as early as next month.  With luck, users will be able to
>> cross-compile Guix System for arbitrary toys come December ;-)
>>
>> Thoughts?

Let’s do that!

> Seems like a good plan :)

Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to
‘core-updates’ if nobody’s done it yet.

Let’s get the ball rolling!

Ludo’.

Re: 'core-updates' Q4 2019

[Mathieu Othacehe]

Hey Ludo,

> Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to
> ‘core-updates’ if nobody’s done it yet.

Done! We have a new core-updates branch open.

Mathieu

Re: 'core-updates' Q4 2019

[Svante Signell]

On Thu, 2019-10-10 at 16:32 +0200, Ludovic Courtès wrote:
> Hi!
> 
> Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to
> ‘core-updates’ if nobody’s done it yet.
> 
> Let’s get the ball rolling!

What's the status of the GNU/Hurd port with this core-updates release,
better or worse?

Re: 'core-updates' Q4 2019

[Ludovic Courtès]

Hi,

Svante Signell <svante.signell@gmail.com> skribis:

> On Thu, 2019-10-10 at 16:32 +0200, Ludovic Courtès wrote:
>> Hi!
>> 
>> Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to
>> ‘core-updates’ if nobody’s done it yet.
>> 
>> Let’s get the ball rolling!
>
> What's the status of the GNU/Hurd port with this core-updates release,
> better or worse?

It’s most likely unchanged.

Thanks,
Ludo’.

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Guix,
>
> As you know, the "quarterly" core-updates rebuild took almost a full
> year this previous cycle.  There are already 35 commits on the
> 'core-updates-next' branch, and I've heard rumors of a GNOME 3.32 branch
> lurking somewhere.
>
> To prevent this work from rotting away, I propose that we start the
> branch as early as next month.  With luck, users will be able to
> cross-compile Guix System for arbitrary toys come December ;-)
>
> Thoughts?

Hi Marius,

I have the GNOME 3.32 branch! I'm building it on top of the new
core-updates as you read this message. If everything still builds, I'll
immediately send my changes to the guix-patches mailing list for review
and testing.

Thanks,
Kei

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

Re: 'core-updates' Q4 2019

[Ludovic Courtès]

Hello Kei,

Kei Kebreau <kkebreau@posteo.net> skribis:

> I have the GNOME 3.32 branch! I'm building it on top of the new
> core-updates as you read this message. If everything still builds, I'll
> immediately send my changes to the guix-patches mailing list for review
> and testing.

Shouldn’t you instead base it on ‘master’ or ‘staging’?

That may allow us to merge it more quickly, especially if these are only
GNOME-related changes.

Thanks for working on it!

Ludo’.

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

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

> Hello Kei,
>
> Kei Kebreau <kkebreau@posteo.net> skribis:
>
>> I have the GNOME 3.32 branch! I'm building it on top of the new
>> core-updates as you read this message. If everything still builds, I'll
>> immediately send my changes to the guix-patches mailing list for review
>> and testing.
>
> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>
> That may allow us to merge it more quickly, especially if these are only
> GNOME-related changes.
>
> Thanks for working on it!
>
> Ludo’.

Hi Ludovic,

Taken individually, most changes on the GNOME 3.32 branch could be
pushed to master without too much trouble. The only issues are big changes like
upgrading Vala. The following changes would cause a large number of
rebuilds:

At least 300 rebuilds: python-pygobject, gtk+

At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
python-check-manifest, python-anytree

I'll minimize the changes, isolate what I can, and submit the results
for review as time allows!

Thanks,
Kei

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

Re: 'core-updates' Q4 2019

[Marius Bakke]

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

Kei Kebreau <kkebreau@posteo.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Kei,
>>
>> Kei Kebreau <kkebreau@posteo.net> skribis:
>>
>>> I have the GNOME 3.32 branch! I'm building it on top of the new
>>> core-updates as you read this message. If everything still builds, I'll
>>> immediately send my changes to the guix-patches mailing list for review
>>> and testing.
>>
>> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>>
>> That may allow us to merge it more quickly, especially if these are only
>> GNOME-related changes.
>>
>> Thanks for working on it!
>>
>> Ludo’.
>
> Hi Ludovic,
>
> Taken individually, most changes on the GNOME 3.32 branch could be
> pushed to master without too much trouble. The only issues are big changes like
> upgrading Vala. The following changes would cause a large number of
> rebuilds:
>
> At least 300 rebuilds: python-pygobject, gtk+
>
> At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
> python-check-manifest, python-anytree
>
> I'll minimize the changes, isolate what I can, and submit the results
> for review as time allows!

Thanks!  Sounds like something we can handle in a 'staging' cycle.

By the way, GNOME 3.34 is out, and 3.36 is slated for March.  So I think
we will finally be able to catch up with GNOME again soon...

(let's focus on 3.32 first though ;-))

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

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Kei Kebreau <kkebreau@posteo.net> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello Kei,
>>>
>>> Kei Kebreau <kkebreau@posteo.net> skribis:
>>>
>>>> I have the GNOME 3.32 branch! I'm building it on top of the new
>>>> core-updates as you read this message. If everything still builds, I'll
>>>> immediately send my changes to the guix-patches mailing list for review
>>>> and testing.
>>>
>>> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>>>
>>> That may allow us to merge it more quickly, especially if these are only
>>> GNOME-related changes.
>>>
>>> Thanks for working on it!
>>>
>>> Ludo’.
>>
>> Hi Ludovic,
>>
>> Taken individually, most changes on the GNOME 3.32 branch could be
>> pushed to master without too much trouble. The only issues are big
>> changes like
>> upgrading Vala. The following changes would cause a large number of
>> rebuilds:
>>
>> At least 300 rebuilds: python-pygobject, gtk+
>>
>> At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
>> python-check-manifest, python-anytree
>>
>> I'll minimize the changes, isolate what I can, and submit the results
>> for review as time allows!
>
> Thanks!  Sounds like something we can handle in a 'staging' cycle.
>
> By the way, GNOME 3.34 is out, and 3.36 is slated for March.  So I think
> we will finally be able to catch up with GNOME again soon...
>
> (let's focus on 3.32 first though ;-))

I have news! The good part is that I got 54 packages to build on top of
master. The bad part is that when I try to use the resulting packages as
my system configuration, my computer gets stuck in tty1, and attempting
to switch to Xorg on tty7 leaves my screen frozen though the system is
still responsive.

Anyone want to see the 54 patches and possibly help me root around for
the issue?

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

Re: 'core-updates' Q4 2019

[Ricardo Wurmus]

Kei Kebreau <kkebreau@posteo.net> writes:

> I have news! The good part is that I got 54 packages to build on top of
> master. The bad part is that when I try to use the resulting packages as
> my system configuration, my computer gets stuck in tty1, and attempting
> to switch to Xorg on tty7 leaves my screen frozen though the system is
> still responsive.

Have you tried removing /var/lib/gdm and the contents of your user
account’s .local/share/gnome* directories?

-- 
Ricardo

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Kei Kebreau <kkebreau@posteo.net> writes:
>
>> I have news! The good part is that I got 54 packages to build on top of
>> master. The bad part is that when I try to use the resulting packages as
>> my system configuration, my computer gets stuck in tty1, and attempting
>> to switch to Xorg on tty7 leaves my screen frozen though the system is
>> still responsive.
>
> Have you tried removing /var/lib/gdm and the contents of your user
> account’s .local/share/gnome* directories?

I just did, and now tty7 simply shows a copy of tty1 rather than
irreversibly freezing my screen. What files are in /var/lib/gdm and
$HOME/.local/share/gnome that would have such an effect?

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

Re: 'core-updates' Q4 2019

[Ricardo Wurmus]

Kei Kebreau <kkebreau@posteo.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Kei Kebreau <kkebreau@posteo.net> writes:
>>
>>> I have news! The good part is that I got 54 packages to build on top of
>>> master. The bad part is that when I try to use the resulting packages as
>>> my system configuration, my computer gets stuck in tty1, and attempting
>>> to switch to Xorg on tty7 leaves my screen frozen though the system is
>>> still responsive.
>>
>> Have you tried removing /var/lib/gdm and the contents of your user
>> account’s .local/share/gnome* directories?
>
> I just did, and now tty7 simply shows a copy of tty1 rather than
> irreversibly freezing my screen. What files are in /var/lib/gdm and
> $HOME/.local/share/gnome that would have such an effect?

~/.local/share/gnome-shell/application_state is a common problem.  It
contains some state that different versions of GNOME seem to be choking
on.  There are some other files like ~/.cache/gnome* that might affect
GNOME and prevent starting after upgrades.  It’s frustrating.

/var/lib/gdm is the home directory of the gdm account, and it too can
accumulate state.  In my opinion /var/lib/gdm should always be recreated
on every boot.

--
Ricardo

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi Kei,

Kei Kebreau <kkebreau@posteo.net> writes:

> Anyone want to see the 54 patches and possibly help me root around for
> the issue?

I would love to take a look at it!  I’ve been a little tied up, but I
should have some time tomorrow or the next day.  I think it would be
easiest to push it to some world-readable Git repository rather than
post all 54 patches here, but I can work with whatever suits you.


-- Tim

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

Timothy Sample <samplet@ngyro.com> writes:

> Hi Kei,
>
> Kei Kebreau <kkebreau@posteo.net> writes:
>
>> Anyone want to see the 54 patches and possibly help me root around for
>> the issue?
>
> I would love to take a look at it!  I’ve been a little tied up, but I
> should have some time tomorrow or the next day.  I think it would be
> easiest to push it to some world-readable Git repository rather than
> post all 54 patches here, but I can work with whatever suits you.
>
>
> -- Tim

I've pushed my changes to the following repository for anyone who wants
to take a look:

https://notabug.org/kei/guix-gnome-updates

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

Re: 'core-updates' Q4 2019

[pelzflorian (Florian Pelz)]

On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote:
> I've pushed my changes to the following repository for anyone who wants
> to take a look:
> 
> https://notabug.org/kei/guix-gnome-updates

I tried reproducing your failure but webkitgtk failed to build.

make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
[ 98%] Built target gtkdoc
make -f Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build.make Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/depend
make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
cd /tmp/guix-build-webkitgtk-2.26.1.drv-0/build && /gnu/store/iz9500ssxcqlyr74hg1jq10ycrh42yq1-cmake-minimal-3.15.1/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-webkitgtk-2.26.1.drv-0/webkitgtk-2.26.1 /tmp/guix-build-webkitgtk-2.26.1.drv-0/webkitgtk-2.26.1/Source/WebKit /tmp/guix-build-webkitgtk-2.26.1.drv-0/build /tmp/guix-build-webkitgtk-2.26.1.drv-0/build/Source/WebKit /tmp/guix-build-webkitgtk-2.26.1.drv-0/build/Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/DependInfo.cmake --color=
Scanning dependencies of target WebKit2WebExtension-4-gir
make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
make -f Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build.make Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build
make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
make[2]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed by 'WebKit2-4.0.gir'.  Stop.
make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:1403: Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/all] Error 2
make[1]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build'
make: *** [Makefile:155: all] Error 2
command "make" "-j" "1" failed with status 2

I will try again later hoping it is non-deterministic.

Regards,
Florian

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi Kei and Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote:
>> I've pushed my changes to the following repository for anyone who wants
>> to take a look:
>> 
>> https://notabug.org/kei/guix-gnome-updates
>
> I tried reproducing your failure but webkitgtk failed to build.
>
> [...]
>
> I will try again later hoping it is non-deterministic.

I was able to to build WebKitGTK, but ran into trouble later.  The
trouble seems to be file system corruption on my system, so I will fix
that tonight, but I may not get a chance to test this promptly.

I’ll report back if I have good luck with fsck and am able to do more
testing.  :)


-- Tim

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi again,

Timothy Sample <samplet@ngyro.com> writes:

> I’ll report back if I have good luck with fsck and am able to do more
> testing.  :)

I was able to build everything and start testing.  To use “guix system
vm” I had to disable tests in QEMU due to a failure.  I did not
investigate it.

This turned up in the logs [1]:

    (.gnome-shell-real:317): GLib-GIO-ERROR **: 03:50:44.482:
        Settings schema 'org.gnome.mutter' is not installed.

It was followed by a warning that “org.gnome.Shell.desktop” was killed.
This is the same message mentioned in the comment explaining disabled
tests in the “mutter” package.

There’s a “glib-or-gtk?” flag for the Meson build system.  Setting it to
“#t” in the “mutter” package makes GDM and GNOME work in a VM.  It
compiles the schemas and wraps Mutter so that it knows where they are.
It does nothing for the tests, though.  However, from the log of an
older Mutter build [2], it looks like the tests were not being run
correctly under Autotools anyway (it looks like not a single test is
actually run).

Hope that helps!


-- Tim

[1] It’s not obvious, but if you edit the GDM configuration file
generation code in “gnu/services/xorg.scm”, you can enable debug output
for GDM.  The debug output is usually extremely helpful!

[2] https://ci.guix.gnu.org/log/q0gkbynj35qp522bi8sf98kzwrsyy037-mutter-3.30.2

Re: 'core-updates' Q4 2019

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 11:07:06PM -0400, Timothy Sample wrote:
> There’s a “glib-or-gtk?” flag for the Meson build system.  Setting it to
> “#t” in the “mutter” package makes GDM and GNOME work in a VM.

Thank you for investigating, I suppose this fixes your issue.
webkitgtk failed again for me the same way, so I will not test and
just wait for substitutes.  I am not interested in investigating my
error.

Regards,
Florian

Re: 'core-updates' Q4 2019

[Kei Kebreau]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On Tue, Oct 22, 2019 at 11:07:06PM -0400, Timothy Sample wrote:
>> There’s a “glib-or-gtk?” flag for the Meson build system.  Setting it to
>> “#t” in the “mutter” package makes GDM and GNOME work in a VM.
>
> Thank you for investigating, I suppose this fixes your issue.
> webkitgtk failed again for me the same way, so I will not test and
> just wait for substitutes.  I am not interested in investigating my
> error.
>
> Regards,
> Florian

With some of the changes mentioned in this email thread, I'm able to
build and log in to GNOME desktop! I've force pushed (sorry!) the
changes to my NotABug git repository today.

Re: 'core-updates' Q4 2019

[Marius Bakke]

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

Timothy Sample <samplet@ngyro.com> writes:

> [1] It’s not obvious, but if you edit the GDM configuration file
> generation code in “gnu/services/xorg.scm”, you can enable debug output
> for GDM.  The debug output is usually extremely helpful!

Could that be exposed as a toggle in the service configuration?

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

Re: 'core-updates' Q4 2019

[Timothy Sample]

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

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Timothy Sample <samplet@ngyro.com> writes:
>
>> [1] It’s not obvious, but if you edit the GDM configuration file
>> generation code in “gnu/services/xorg.scm”, you can enable debug output
>> for GDM.  The debug output is usually extremely helpful!
>
> Could that be exposed as a toggle in the service configuration?

Indeed!  It’s been on my list for ages.  Thanks for the nudge.  ;)

How about the attached patch?  I can confirm that it works, but would
like a second opinion on the name, since it is annoying to change later.


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

From b3e577799c2dfabb2bed00b9f3715144155c2c43 Mon Sep 17 00:00:00 2001
From: Timothy Sample <samplet@ngyro.com>
Date: Wed, 23 Oct 2019 21:57:52 -0400
Subject: [PATCH] services: gdm: Add 'debug?' configuration field.

* gnu/services/xorg.scm (<gdm-configuration>)[debug?]: New field.
(gdm-configuration-file): Use it.
---
 gnu/services/xorg.scm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 1d55e388a1..9c84f7413f 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -835,6 +835,7 @@ the GNOME desktop environment.")
   (allow-empty-passwords? gdm-configuration-allow-empty-passwords? (default #t))
   (auto-login? gdm-configuration-auto-login? (default #f))
   (dbus-daemon gdm-configuration-dbus-daemon (default dbus-daemon-wrapper))
+  (debug? gdm-configuration-debug? (default #f))
   (default-user gdm-configuration-default-user (default #f))
   (gnome-shell-assets gdm-configuration-gnome-shell-assets
                       (default (list adwaita-icon-theme font-cantarell)))
@@ -866,7 +867,9 @@ the GNOME desktop environment.")
                    "WaylandEnable=false\n"
                    "\n"
                    "[debug]\n"
-                   "#Enable=true\n"
+                   "Enable=" (if (gdm-configuration-debug? config)
+                                 "true"
+                                 "false") "\n"
                    "\n"
                    "[security]\n"
                    "#DisallowTCP=true\n"
-- 
2.23.0


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


Thanks!


-- Tim

Re: 'core-updates' Q4 2019

[Marius Bakke]

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

Timothy Sample <samplet@ngyro.com> writes:

> Hi Marius,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Timothy Sample <samplet@ngyro.com> writes:
>>
>>> [1] It’s not obvious, but if you edit the GDM configuration file
>>> generation code in “gnu/services/xorg.scm”, you can enable debug output
>>> for GDM.  The debug output is usually extremely helpful!
>>
>> Could that be exposed as a toggle in the service configuration?
>
> Indeed!  It’s been on my list for ages.  Thanks for the nudge.  ;)

Cool!  Glad to be of service.  :-)

> How about the attached patch?  I can confirm that it works, but would
> like a second opinion on the name, since it is annoying to change later.

LGTM.  It needs a corresponding entry in doc/guix.texi though.

Thank you!

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

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> LGTM.  It needs a corresponding entry in doc/guix.texi though.

Pushed with an update to the docs.  Thanks for the suggestion and
review!


-- Tim

Re: 'core-updates' Q4 2019

[Kei Kebreau]

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

Kei Kebreau <kkebreau@posteo.net> writes:

> Timothy Sample <samplet@ngyro.com> writes:
>
>> Hi Kei,
>>
>> Kei Kebreau <kkebreau@posteo.net> writes:
>>
>>> Anyone want to see the 54 patches and possibly help me root around for
>>> the issue?
>>
>> I would love to take a look at it!  I’ve been a little tied up, but I
>> should have some time tomorrow or the next day.  I think it would be
>> easiest to push it to some world-readable Git repository rather than
>> post all 54 patches here, but I can work with whatever suits you.
>>
>>
>> -- Tim
>
> I've pushed my changes to the following repository for anyone who wants
> to take a look:
>
> https://notabug.org/kei/guix-gnome-updates

Update: Please check out the new wip-gnome-updates branch of the Guix
git repository for continued updates.  The contents of the notabug.org
link given above will be changed to a notice that says to do this.

Thanks,
Kei

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

Re: 'core-updates' Q4 2019

[Miguel Arruga Vivas]

Hi Kei,

Kei Kebreau <kkebreau@posteo.net> writes:
> Update: Please check out the new wip-gnome-updates branch of the Guix
> git repository for continued updates.  The contents of the notabug.org
> link given above will be changed to a notice that says to do this.

Thank you very much for this huge effort.  I've been playing with the
branch and I have a working system, both X11 with GDM and Wayland with
SDDM (I haven't tried hard enough to set up gdm with wayland as only a
change to gdm-configuration doesn't seem to have any effect) and your
branch works great on my machine, do you still have the issue during
boot?  I haven't found any (new) problem on the applications I've
tested (x86_64, normal use with almost all of the gnome applications,
not the games though.)

Nevertheless, I've been reading the patches and I have a couple of
comments about them:

 - The patch for libdazzle only changes the xorg-server, as it already
   is at version 3.33.90 in master.  It still makes sense as a patch,
   but the title indicates a version downgrade.

 - The patch for gedit contains a reference to libgd, wouldn't it be
   clearer for the reader/updater to have it defined in a let over the
   package definition and use the name in native-inputs?

 - Is there any reason to not patch-out the gtk-icon-update-cache
   invocations?  If I understand it correctly, this is performed at
   profile level, so makes no sense creating a cache at package level,
   isn't it? The patches for quadrapassel, gnome-klotski, ghex,
   gnome-sudoku, gnome-mines, five-or-more and gedit contain references
   to it.  Maybe creating a package like xorg-server-for-tests
   (perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would
   help in the long term.

As a final comment, the gnome release cycle and the amount of packages
involved is quite big, so again, thank you.

Happy hacking!
Miguel

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Miguel Arruga Vivas <rosen644835@gmail.com> writes:

> Hi Kei,
>
> Kei Kebreau <kkebreau@posteo.net> writes:
>> Update: Please check out the new wip-gnome-updates branch of the Guix
>> git repository for continued updates.  The contents of the notabug.org
>> link given above will be changed to a notice that says to do this.
>
> Thank you very much for this huge effort.  I've been playing with the
> branch and I have a working system, both X11 with GDM and Wayland with
> SDDM (I haven't tried hard enough to set up gdm with wayland as only a
> change to gdm-configuration doesn't seem to have any effect) and your
> branch works great on my machine, do you still have the issue during
> boot?  I haven't found any (new) problem on the applications I've
> tested (x86_64, normal use with almost all of the gnome applications,
> not the games though.)
>

Boot and login worked properly for me after I cleared the contents of my
/var/lib/gdm directory (if it's unclear why that directory matters, see
https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html for
a quick overview).

> Nevertheless, I've been reading the patches and I have a couple of
> comments about them:
>
>  - The patch for libdazzle only changes the xorg-server, as it already
>    is at version 3.33.90 in master.  It still makes sense as a patch,
>    but the title indicates a version downgrade.
>

Good catch!  I'd correct this commit message, but I don't know what the
rules are for rewriting commit history on Guix WIP branches.  For now
I'll note your comment and leave the message alone.

>  - The patch for gedit contains a reference to libgd, wouldn't it be
>    clearer for the reader/updater to have it defined in a let over the
>    package definition and use the name in native-inputs?
>

I'm not sure.  I don't know if there is an explicit convention for
packaging software that is distributed like this, and the examples of
this in the code base (that I've seen, at least) define the third-party
library the way I've done it here.  I'm open to change on this point
though.

>  - Is there any reason to not patch-out the gtk-icon-update-cache
>    invocations?  If I understand it correctly, this is performed at
>    profile level, so makes no sense creating a cache at package level,
>    isn't it? The patches for quadrapassel, gnome-klotski, ghex,
>    gnome-sudoku, gnome-mines, five-or-more and gedit contain references
>    to it.  Maybe creating a package like xorg-server-for-tests
>    (perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would
>    help in the long term.
>

I don't think such a reason exists.  I could add changes that substitute
calls to "gtk-icon-update-cache" with "true" for these packages, but I
agree that a better solution may be possible.  Perhaps not a package;
maybe a new 'patch-gtk-icon-update-cache' phase in the relevant build
systems?

> As a final comment, the gnome release cycle and the amount of packages
> involved is quite big, so again, thank you.
>
> Happy hacking!
> Miguel

Thanks Miguel!  This comment and review means a lot!
Kei

Re: 'core-updates' Q4 2019

[Leo Famulari]

On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote:
> >  - The patch for libdazzle only changes the xorg-server, as it already
> >    is at version 3.33.90 in master.  It still makes sense as a patch,
> >    but the title indicates a version downgrade.
> >
> 
> Good catch!  I'd correct this commit message, but I don't know what the
> rules are for rewriting commit history on Guix WIP branches.  For now
> I'll note your comment and leave the message alone.

You can feel free to rewrite history completely on the WIP branches,
including commit messages.

Re: 'core-updates' Q4 2019

[Kei Kebreau]

On Wed, 2019-11-06 at 12:46 -0500, Leo Famulari wrote:
> On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote:
> > >  - The patch for libdazzle only changes the xorg-server, as it
> > > already
> > >    is at version 3.33.90 in master.  It still makes sense as a
> > > patch,
> > >    but the title indicates a version downgrade.
> > > 
> > 
> > Good catch!  I'd correct this commit message, but I don't know what
> > the
> > rules are for rewriting commit history on Guix WIP branches.  For
> > now
> > I'll note your comment and leave the message alone.
> 
> You can feel free to rewrite history completely on the WIP branches,
> including commit messages.

`git push --force-with-lease` doesn't seem to work on the WIP branch.
This is a good thing in general, but how do I rewrite history? Do I
just delete the remote WIP branch and recreate a new one with the
appropriate changes?

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi Kei,

Kei Kebreau <kkebreau@posteo.net> writes:

> `git push --force-with-lease` doesn't seem to work on the WIP branch.
> This is a good thing in general, but how do I rewrite history? Do I
> just delete the remote WIP branch and recreate a new one with the
> appropriate changes?

Yup!  This is what I do for “wip-haskell-updates” and what I’ve seen
others do before.


-- Tim

Re: 'core-updates' Q4 2019

[Miguel Arruga Vivas]

Hi Kei,

 Kei Kebreau <kkebreau@posteo.net> writes:
> Miguel Arruga Vivas <rosen644835@gmail.com> writes:
> Boot and login worked properly for me after I cleared the contents of
> my /var/lib/gdm directory (if it's unclear why that directory
> matters, see
> https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html
> for a quick overview).

Great pointer, thank you, and good that it's solved.

> >  - The patch for gedit contains a reference to libgd, wouldn't it be
> >    clearer for the reader/updater to have it defined in a let over
> > the package definition and use the name in native-inputs?
> >  
> 
> I'm not sure.  I don't know if there is an explicit convention for
> packaging software that is distributed like this, and the examples of
> this in the code base (that I've seen, at least) define the
> third-party library the way I've done it here.  I'm open to change on
> this point though.

This actually should have been an open question, as I have a patch on
libosinfo, related with gnome-boxes (patches coming soon) and it
doesn't feel right for me having usb.ids and pci.ids hidden there, so
I've put another origin needed (osinfo-db) out there.

> >  - Is there any reason to not patch-out the gtk-icon-update-cache
> >    invocations?  If I understand it correctly, this is performed at
> >    profile level, so makes no sense creating a cache at package
> > level, isn't it? The patches for quadrapassel, gnome-klotski, ghex,
> >    gnome-sudoku, gnome-mines, five-or-more and gedit contain
> > references to it.  Maybe creating a package like
> > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to
> > "true" from coreutils would help in the long term.
> >  
> 
> I don't think such a reason exists.  I could add changes that
> substitute calls to "gtk-icon-update-cache" with "true" for these
> packages, but I agree that a better solution may be possible.
> Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache'
> phase in the relevant build systems?

Some of these packages already have phases for it on master.  I rebased
your branch onto it (1a9df94cec..fb936351d3), I had to solve two merge
conflicts: devhelp and totem.

devhelp's patch has only a trivial conflict, as there was no arguments
parameter before.  OTOH, I did not check as much as I should totem's
last day, as now I have one question here: Who kills the Xvfb server
on display :1 after the tests?  I see it's a common idiom, but I don't
get why shouldn't the daemon treat it like from any other process and
wait for it to reach completion (other than technical means, I mean).
This could be a great place for a #:xorg-for-tests?, should I try?

> > As a final comment, the gnome release cycle and the amount of
> > packages involved is quite big, so again, thank you.
> >
> > Happy hacking!
> > Miguel  
> 
> Thanks Miguel!  This comment and review means a lot!
> Kei

Thank you too

Best regards,
Miguel

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Hello again Miguel,

I apologize for the delay.  My semester at university is becoming
busier as final exams get closer!

On Fri, 2019-11-08 at 01:58 +0100, Miguel Arruga Vivas wrote:
> Hi Kei,
...
> > >  - The patch for gedit contains a reference to libgd, wouldn't it
> > > be
> > >    clearer for the reader/updater to have it defined in a let
> > > over
> > > the package definition and use the name in native-inputs?
> > >  
> > 
> > I'm not sure.  I don't know if there is an explicit convention for
> > packaging software that is distributed like this, and the examples
> > of
> > this in the code base (that I've seen, at least) define the
> > third-party library the way I've done it here.  I'm open to change
> > on
> > this point though.
> 
> This actually should have been an open question, as I have a patch on
> libosinfo, related with gnome-boxes (patches coming soon) and it
> doesn't feel right for me having usb.ids and pci.ids hidden there, so
> I've put another origin needed (osinfo-db) out there.
> 

After some thought, I believe it is clearer to someone reading the
package to see the origin object defined in the "native-inputs" field
rather than a let over the whole package.  The extra "let" adds a layer
of indirection in reading the code that I'm not sure pays off.  Also,
such a bound variable could be accessed both directly and through the
"native-inputs" field, so that could be confusing as well.

> > >  - Is there any reason to not patch-out the gtk-icon-update-cache
> > >    invocations?  If I understand it correctly, this is performed
> > > at
> > >    profile level, so makes no sense creating a cache at package
> > > level, isn't it? The patches for quadrapassel, gnome-klotski,
> > > ghex,
> > >    gnome-sudoku, gnome-mines, five-or-more and gedit contain
> > > references to it.  Maybe creating a package like
> > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to
> > > "true" from coreutils would help in the long term.
> > >  
> > 
> > I don't think such a reason exists.  I could add changes that
> > substitute calls to "gtk-icon-update-cache" with "true" for these
> > packages, but I agree that a better solution may be possible.
> > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache'
> > phase in the relevant build systems?
> 
> Some of these packages already have phases for it on master.  I
> rebased
> your branch onto it (1a9df94cec..fb936351d3), I had to solve two
> merge
> conflicts: devhelp and totem.
> 
> devhelp's patch has only a trivial conflict, as there was no
> arguments
> parameter before.  OTOH, I did not check as much as I should totem's
> last day, as now I have one question here: Who kills the Xvfb server
> on display :1 after the tests?  I see it's a common idiom, but I
> don't
> get why shouldn't the daemon treat it like from any other process and
> wait for it to reach completion (other than technical means, I mean).
> This could be a great place for a #:xorg-for-tests?, should I try?
> 

I really like the idea of an #:xorg-for-tests? flag!  If you can
attempt a patch, I'll do my best to help.

> > > As a final comment, the gnome release cycle and the amount of
> > > packages involved is quite big, so again, thank you.
> > > 
> > > Happy hacking!
> > > Miguel  
> > 
> > Thanks Miguel!  This comment and review means a lot!
> > Kei
> 
> Thank you too
> 
> Best regards,
> Miguel