From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kei Kebreau Subject: Re: 'core-updates' Q4 2019 Date: Fri, 22 Nov 2019 21:11:51 -0500 Message-ID: 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> <87y2wtx5b6.fsf@posteo.net> <20191108015824.6fa80912@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:37983) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iYKu0-00066O-Ri for guix-devel@gnu.org; Fri, 22 Nov 2019 21:12:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iYKtz-0002iu-CY for guix-devel@gnu.org; Fri, 22 Nov 2019 21:12:00 -0500 Received: from mout01.posteo.de ([185.67.36.65]:49089) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iYKty-0002iU-Q4 for guix-devel@gnu.org; Fri, 22 Nov 2019 21:11:59 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id B993016005F for ; Sat, 23 Nov 2019 03:11:55 +0100 (CET) In-Reply-To: <20191108015824.6fa80912@gmail.com> 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 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