Re: 'core-updates' Q4 2019

[Kei Kebreau]

Miguel Arruga Vivas <address@hidden> writes:

> Hi Kei,
>
> Kei Kebreau <address@hidden> 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