Re: 'core-updates' Q4 2019

[Miguel Arruga Vivas]

Hi Kei,

 Kei Kebreau <address@hidden> writes:
> Miguel Arruga Vivas <address@hidden> 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