Hi Kei, Kei Kebreau <kkebr...@posteo.net> writes: > Miguel Arruga Vivas <rosen644...@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