From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QAY7JDsPoF+maAAA0tVLHw (envelope-from ) for ; Mon, 02 Nov 2020 13:52:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id uHcoIDsPoF9/egAA1q6Kng (envelope-from ) for ; Mon, 02 Nov 2020 13:52:59 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3E8FF9404D3 for ; Mon, 2 Nov 2020 13:52:59 +0000 (UTC) Received: from localhost ([::1]:48954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZaGY-00011h-7I for larch@yhetil.org; Mon, 02 Nov 2020 08:52:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZaFY-0000Fh-Aq for guix-devel@gnu.org; Mon, 02 Nov 2020 08:51:56 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:63351) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZaFU-000342-RU for guix-devel@gnu.org; Mon, 02 Nov 2020 08:51:55 -0500 Received: from nijino.local (217-149-162-161.nat.highway.telekom.at [217.149.162.161]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4CPvTq10ZKz1LWpP; Mon, 2 Nov 2020 14:51:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4CPvTq10ZKz1LWpP DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1604325103; bh=EuzKiDjoE7jaYArS65ah7B7rax+RnoLf8DoJSO9vERU=; h=Subject:From:To:Cc:Date:In-Reply-To:From; b=iHo0ovcbFrzhVpkj22SI8AkP6dMPp8tPcQNLuoa5fVd6DC72yz9gMkYqzHwI16ve4 wKdkR70my8cdJqZPCwnTpanhDd5bI5Q1RVf1JBlX/xBVjM3AOyv0nKLEAxGToI3h3l K2VQtRy0ck1Za8vcKRcD11iWzHh7ndQT2wbstUmg= Message-ID: <9324ae97b8c1c2452386154d56922558b8274812.camel@student.tugraz.at> Subject: GNOME in Guix From: Leo Prikler To: dannym@scratchpost.org Date: Mon, 02 Nov 2020 14:51:42 +0100 In-Reply-To: 20201102111731.772e4f7a@scratchpost.org Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/02 08:51:45 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=iHo0ovcb; dmarc=pass (policy=none) header.from=student.tugraz.at; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: AfyMdXYb1+ce Hi Danny, Am Montag, den 02.11.2020, 11:17 +0100 schrieb Danny Milosavljevic: > Hi, > > On Mon, 02 Nov 2020 08:44:29 +0100 > Pierre Neidhardt wrote: > > > Danny Milosavljevic writes: > > > Not much more works yet because I've hit this (design) bug in > Guix and/or > > > GNOME: > > > > > > * https://github.com/spk121/guile-gi/issues/96 > > > > Have you tried g-golf? The Nomad browser uses it, it may not > suffer > > from the aforementioned issue. > > Thoughts on that? > > It really depends on what you mean. If it also uses gobject- > introspection, it > will have the same problem. As much as I rant about nomad in IRC now and then, it is still a rather sophisticated program, and as a user I have not yet encountered any problem similar in effect to what is described here. The bugs I do encounter whenever I try it out for my own amusement are much rather due to g-golf and emacsy being in rather early stages of development and therefore not feature-complete. I am not sure, whether the Nomad devs have encountered a problem similar to Guile-GI#96 (I myself am not one), but the Guile-GI devs speculate, that the problem is somewhat specific to their implementation. They also mention, that you should still be able to prototype your application by using "--no-grafts" for the development environment. Do you still encounter Guile-GI#96 after packaging? If so, you might want to explain your situation upstream, so that they can better help you. > Even gobject-introspection links to glib internally, then registers a > class in > that, THEN opens (potentially another) glib at runtime using dlopen > in the same > address same. > I'm pretty sure that GNOME is not designed for that. If you then use > the > dlopened glib to use the first-mentioned class, good luck with that. > > The only reason it didn't fall onto the head of users of other > distributions > is because those don't support internal dependencies of packages at > all--so > you always have to update all in lockstep. So the following can only > happen > in Guix: > > If a library A has an input Q, and library B has the same input Q, > and you > use A and B in your program, and then you (guix-) update just B to > use Q' > (for example a newer version of Q) and recompile your program, then > you have > both Q and Q' in your process address space! > > Q is an internal dependency of A, and by coincidence it's an internal > dependency of B, too. Just because the internal dependency of B > changed > shouldn't change the internal depenency of A--that's what "internal" > means. Sure, but that's only if either of them ends up using a different version. That should not be the case for Guix' GNOME stack apart from some bootstrap shenanigans, that don't really matter at the point of application packages. In order to make use of any GI in Guix, you need - the GI bindings (one of python-gobject, g-golf, guile-gi, gjs, etc.), - *and* the packages of the libraries themselves as inputs to your package. So the resulting graph for your package will always be complete and should only contain one relevant package per library. And yes, you can totally do that on other distros as well. (One way to do so would be to use Guix on them ;D) It's just that users typically shy away from installing conflicting versions of the same package, whereas Guix will happily allow them to coexist and go out of its way to deal with potential issues arising from that. > I think that the gobject type registry does not consider that it can > happen > to have to classes with the same class name, registered in respective > internal dependencies. The objects of the internal dependency > shouldn't > be available to the outside program in the first place. Yes it does, or at least you can check, whether a type of that name is already registered and bail. You could even do so in Guile-GI as you are instantiating the types, but I doubt upstream devs want to bail when they encounter a reserved type. > That means actually we should propagate a lot of GNOME inputs, which > means > in practice what a regular user has in his profile will be very much > like > in other distributions, and internal dependencies will become a weird > corner > feature nobody uses. No, it does not. It perhaps means, that we might want to take care of GI_TYPELIB_PATH in glib-or-gtk-build-system. It at least would make sense to add logic dealing with gobject-introspection to glib-or-gtk- wrap, which could then be reused in other build systems as well. Packages, be they GNOME or not, should be dynamically linked, so that Guix can correctly graft them. Assuming correct grafting, the library loaded from GI_TYPELIB_PATH should be the same as the library loaded internally with the build setup I discussed earlier. > Does anyone know how to make dlopen fail on duplicate global > variables? No, but I don't think that is too relevant here. See my earlier point on how it *is* possible to handle this with the methods GLib provides. Am Donnerstag, den 29.10.2020, 20:34 +0100 schrieb Danny Milosavljevic: > Or I could just use Gtk in C and use popen("guix ..."). You're probably joking, but you should know, that I had moderate success passing around just data from Guile to Gtk while not using g- golf or guile-gi. You could either do all your conversions in C like I did back then or declare your own data models as C structs and then fill them from guile using e.g. guile-bytestructures. Obviously, it would be nicer if one could program the GUI itself in Guile, but you are free to make the choices you feel are fitting. A slightly more elaborate approach would be to try and expose Guix over DBUS (this would require guile bindings to dbus, that afaik don't exist outside of projects that want to happily marry Guile and GNOME). Once that is written, you could again write your GUI in any language. Using DBUS would probably also enable you to get fine-grained control over when to grant administrative privileges for `guix system`. Regards, Leo