From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kei Kebreau Subject: Re: 'core-updates' Q4 2019 Date: Tue, 05 Nov 2019 18:38:05 -0500 Message-ID: <87y2wtx5b6.fsf@posteo.net> References: <87sgo252cq.fsf@devup.no> <878sprf1zk.fsf@posteo.net> <87ftjxd30v.fsf@gnu.org> <874l0ag5kv.fsf@posteo.net> <87tv8a0x8u.fsf@devup.no> <87v9snnlto.fsf@posteo.net> <87wod02714.fsf@ngyro.com> <87o8ycgkma.fsf@posteo.net> <875zk3ui5p.fsf@posteo.net> <20191104203646.4181f4ca@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35587) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS8Or-0004fj-SR for guix-devel@gnu.org; Tue, 05 Nov 2019 18:38:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iS8Oq-0000n8-72 for guix-devel@gnu.org; Tue, 05 Nov 2019 18:38:13 -0500 Received: from mout02.posteo.de ([185.67.36.66]:44219) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iS8Op-0000jJ-Iq for guix-devel@gnu.org; Tue, 05 Nov 2019 18:38:12 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id D8A4E2400E6 for ; Wed, 6 Nov 2019 00:38:08 +0100 (CET) In-Reply-To: <20191104203646.4181f4ca@gmail.com> (Miguel Arruga Vivas's message of "Mon, 4 Nov 2019 20:37:59 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Miguel Arruga Vivas Cc: guix-devel@gnu.org Miguel Arruga Vivas writes: > Hi Kei, > > Kei Kebreau 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