From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id j0JBBCZeoV8mOwAA0tVLHw (envelope-from ) for ; Tue, 03 Nov 2020 13:41:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GIJSOyVeoV9VewAAbx9fmQ (envelope-from ) for ; Tue, 03 Nov 2020 13:41:57 +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 A51B59401CD for ; Tue, 3 Nov 2020 13:41:57 +0000 (UTC) Received: from localhost ([::1]:36328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZwZQ-0005Bi-IZ for larch@yhetil.org; Tue, 03 Nov 2020 08:41:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZwZE-00059Y-VW for guix-devel@gnu.org; Tue, 03 Nov 2020 08:41:45 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:5438) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZwZA-0004DZ-AI; Tue, 03 Nov 2020 08:41:43 -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 4CQWCc5V8Pz3x5f; Tue, 3 Nov 2020 14:41:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1604410893; bh=NRCYn3oL7sKHYAhDmWZ5yzR80V/EKzHWI6X6nuVAQq8=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=EhrBqy4Dy+cJ+6UQ668vs6aDDGYgPc7YU2CLPR/NMsxAU1alBMM6XCkZVn6UbDa42 PGT/W4rPjyvo/zbIEIdbregdFeC3NV52AgZNh8emmQ874zb2EYjLk0LdH5a2LUmO6L 6SFhbKOAT3BhSf4xEsKdUK8SNI9TGRgx9lmO+b0A= Message-ID: <898d3e29025888a0d218ddf8b468a676ece2490f.camel@student.tugraz.at> Subject: Re: GNOME in Guix From: Leo Prikler To: Danny Milosavljevic Date: Tue, 03 Nov 2020 14:41:31 +0100 In-Reply-To: <20201103101430.711ce21a@scratchpost.org> References: <9324ae97b8c1c2452386154d56922558b8274812.camel@student.tugraz.at> <20201103101430.711ce21a@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/03 08:41:35 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=fail (headers rsa verify failed) header.d=tugraz.at header.s=mailrelay header.b=EhrBqy4D; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); 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: 0.09 X-TUID: ohFKn+SGyig0 Hi Danny, Am Dienstag, den 03.11.2020, 10:14 +0100 schrieb Danny Milosavljevic: > I've now gotten guile-gi to work okay for me, too. That is great to hear. > For me, there were many reasons why it didn't work before--some of > them follow: > > (1) I originally built guile-gi from source using > > guix environment --pure guile-gi --ad-hoc guile autoconf automake > gettext texinfo > > (2) I originally used the following to run guix-gui > > guix environment -l ${HOME}/src/guile-gi/guile-gi-dannym/guile- > gi/guix.scm --preserve=XAUTHORITY --preserve=DISPLAY -- > preserve=G_MESSAGES_DEBUG --ad-hoc guile gdk-pixbuf adwaita-icon- > theme shared-mime-info guix gtk+ guile-readline -- ${HOME}/src/guile- > gi/guile-gi-dannym/guile-gi/tools/uninstalled-env guix repl -L . > "$@" > > (3) gobject-introspection refers to cairo-gobject, but does not embed > the store path to it (it would cause a cycle). There was (an old) > cairo-gobject in my user profile, which was picked up > > (4) Additionally (in parallel), gtk+ in guix environment refers to a > newer gtk than I had in my profile. Furthermore, guix environment > entries depend on glib-with-documentation and similar. > > Adding "--pure" to my "guix environment" invocation DID NOT fix the > problem. Apologize my rudeness, but that is a very arcane incantation ;) >From what I can see (2) on its own should trigger Guile-GI#96, as you execute it from a build environment without --no-grafts. Not saying (3) and (4) had no influence, but pure environments should mitigate them. > In any case, using > > guix environment --pure -l guix.scm --preserve=XAUTHORITY -- > preserve=DISPLAY --preserve=G_MESSAGES_DEBUG --ad-hoc guile adwaita- > icon-theme shared-mime-info guix guile-readline -- guix repl -L . > "$@" > > (note: "-l guix.scm") > > seems to have fixed most of the problems. > (There is no automated diagnostic--so who knows whether it did fix > them for real?) What diagnostic would you want here? > I rate the development experience on Guix in this case at about -15 > of 10 points :P > > The following bad diagnostics conspired: > > (1) guix environment --pure picked up TWO different glib. Even > though both > packages are named the same ("glib") and one is hidden and one is not > hidden and > both were used in the environment anyway, no warning was emitted. > That is very bad! Is that really the problem at hand? I don't see glib explicitly mentioned here, so you should not build glib-with-documentation here. Adding glib to one of your --ad-hoc "chains" should yield a different profile. > (2) Even though GNOME does not like having two different gobjects > loaded, it did > so anyway and caused difficult-to-diagnose problems. > gobject-introspection is not built such that it dlopens libraries in > a way > that if there are duplicate global symbols, it fails. Therefore, > there was not > even a failure caused at dlopen time. Additionally, there was no > high-level > failure being caused at any point. It just did the wrong things and > continued > running until eventually crashing because of a low-level failure > (memory > allocation, runtime C glib type checking etc). What is the meaning of "doesn't like" here? Is it explicitly discouraged, poorly supported, work in progress, ...? > Before all this, I know that weird things like that could happen so I > tried > using something like > > guix environment --ad-hoc pkg1 pkg2 -e '(@ (gnu packages foo) > pkg3)' pkg4 > > in the very beginning--and that didn't work either because this way > of using > "-e" is not supported. Is this perhaps an ordering problem? $ guix environment --ad-hoc -e '(@ (gnu packages glib) glib)' seems to be building something. > > 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. > > guile-gi seems to think that it's their fault--but I > disagree. Changing it > in guile-gi would fix nothing, because gobject-introspection does the > exact > same thing. In fact, let me tell them again. > > This was both my fault, and guix's fault for being VERY obtuse. I don't think looking for someone to blame is particularly useful. It also looks as if you are discussing different things there. Your issue there and here is using Guile-GI as a dependency, but theirs is the development of Guile-GI itself on one hand and which use cases they want to support on the other. On your side it appears as though your use case is already well-supported by the library (because it is?) and only Guix is interfering by mixing up inputs. On their side, there exists the question of whether they can (and want) to support more than that. > > They also mention, that you should still be able to prototype your > > application by using "--no-grafts" for the development environment. > > If I pass --no-grafts, I cannot read any letters anymore (they are > boxes). > See attachment. So I cannot use that. Also, it is unsafe to do > that. Grafts > are there for a reason, namely security updates. Not having full font support sounds like an issue, I can understand that. Regarding the safety aspect, I don't think that's what they're going for. They might be thinking, that "--pure --no-grafts" is close enough to what you'd get inside `guix build`, so that you don't have to use `guix build` for debugging. > > Do you still encounter Guile-GI#96 after packaging? > > I've not finished packaging it yet (I tried--but that's pretty > difficult, > too! Help wanted--see README and guix.scm in the guix-gui repo). I'll see what I can do to help, but the only thing I can see are "FIXME" strings in guix.scm. The README even suggests to run `guix build`. > > Sure, but that's only if either of them ends up using a different > > version. > > It's easy for this to happen. I did not go out of my way to make it > happen--quite the opposite. One could disagree about that based on the workflow you've posted here ;) Jokes aside, the Guile-GI devs seem to be hitting a similar issue, but as they write, it appears to mainly affect their own development environments (i.e. exactly the thing that hurts you the most as a developer). There is potentially a discrepancy between `guix build` and `guix environment`. > > > 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. > > It is good to know that guix guarantees to only have one libgobject > (i.e. "glib" package derivation) in this case. > I therefore withdraw the propagated-input proposal. I'm not sure, how hard this guarantee is, but the same grafting operation should be applied to all packages. Having a look at Guile-GI specifically, ldd `guix build guile-gi` has the following: libgobject-2.0.so.0 => /gnu/store/xa1vfhfc42x655hi7vxqmbyvwldnz7r0- glib-2.62.6/lib/libgobject-2.0.so.0 You should recognize that hash by now ;) > > [having two different libgobject in the same process] should not be > > the case > > for Guix' GNOME stack apart from [bootstrapping] > > When using guix environment, it is easy for this to happen in Guix's > GNOME. > > Grafting, different glib-with-or-without-documentation packages and > propagated > inputs in profiles propagating cairo-gobject into my user profile > (not to > mention stuff in the SYSTEM profile) and guix environment being > obtuse not only make this possible, but make it a regular occurence > when using guix environment. I think the first step in fixing this > is actually automatically diagnosing this problem, which Guix (and > gobject-introspection) do not do right now. You can eliminate a huge array of those issues by using pure environments. What remains is the gobject-introspection glib, that is differently grafted from plain glib for no apparent reason. (This might actually be a bug in Guix). With or without documentation is an issue if you specify glib at the command line, but not when you build an environment from guix.scm. Perhaps glib should get the gcc- toolchain treatment. > As it is now, often there are two different libgobjects being loaded > at the same > time, and those register their types in the respective type > registry. Depending > on who talks to which registry, they get different actual > implementers back. > > Which registry you talk to also determines whether you will get "the > type > doesn't exist" back or not (which is how it should be (!), and fine > if people > talked to the correct respective registry--which they don't). > > So the current (and maybe perpetual) state is that GNOME does not > support this > (and they really don't need to support it), so somebody (possibly > gobject-introspection) should be catching it, if necessary at > runtime. > They don't. I'm not sure whether they must specifically enforce one and only one type registry or whether those can be made to coexist. You should probably talk to gobject-introspection about this. > > > 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. > > (1) This would make it extremely easy to find problems like this now. > > So it's relevant in the sense of it could have spared both me and the > guile-gi > devs a LOT of time. It would also make it extremely easy to shoot yourself in the foot, thereby costing you even more time. It's like shooting flies with a cannon. Sure, you might kill some bugs, but you can just as well tear down castle walls with that. > (2) It would make it possible to find problems of this kind in the > future. > I do not want to keep fixing the same thing over and over again. I > want there > to be an automated check in place so if there are problems, they are > automatically detected. > In this case I want dlopen to fail in this case and not be able to > load a > second libgobject in the first place--neither directly nor > indirectly. I think this is something, that should be solved at the application level, not lower. > (Evidently, programs and *GNOME's own libraries* are not designed for > the > alternative of two libgobject libraries loaded in the same process > --so > gobject-introspection should not allow it in the first place) I'm not sure how sane loading another version of GObject is in other GI implementations. > > 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. > > I don't want to maintain data structure marshallers that add no value > to > anything. One of the touted advantages of using guix as a package > manager > is that you don't need to do that anymore--you just use guile as a > general-purpose programming language and not keep manually > translating back > and forth between different incompatible environments, with all the > impedance mismatch, slowness, different semantics, protocol > versioning and > bugs that that entails. Fair enough. > Using gtk on guile also already makes me sometimes force a square peg > into a > round hole--that should be enough. I know what you mean, GObject is not very functional in its programming style. > > [expose guix via dbus] > > You should keep in mind for this approach: impedance mismatch, > slowness, > different semantics, protocol versioning, and bugs in dbus (the > latter > of which I also regularily experience in guix--dbus bus hangs etc). > > The advantages you listed of better and easier privilege checking are > valid, though. > > (In addition, I don't want a hard dependency to gtk+ in the guix > package manager. > But that can be avoided in other ways, too). > > I should note that I'm on regular guix master with no custom patches. > If I do patches, it's always in a ./pre-inst-env, never on the system > I use. My suggestion was not to change Guix in-place, but to write a piece of software, that interacts with Guix on the one hand (via REPL/Scheme bindings) and DBus on the other. But yeah, given that that's not really simpler than writing your Gtk frontend in Scheme, let's stick to that for now. > The following is historical and not current anymore: > > $ guix environment --pure -l ${HOME}/src/guile-gi/guile-gi/guix.scm > --preserve=XAUTHORITY --preserve=DISPLAY --preserve=G_MESSAGES_DEBUG > --ad-hoc guile gdk-pixbuf adwaita-icon-theme shared-mime-info guix > gtk+ guile-readline -- ${HOME}/src/guile-gi/guile- > gi/tools/uninstalled-env guix repl -L . guix-gui.in > > (see "run" in repository below) > (note: I do not preserve any GI environment variables) > > using > https://gitlab.com/daym/guix-gui/-/tree/002e931232c818f9100b5ea622a52bd6b20b9a0e > > and > https://github.com/spk121/guile-gi/commit/b454a99b65f927e947faab17d25bd3499829c1b4 > as guile-gi > I incessantly encounter this: > Frequent runtime problems at different points in time while > the program is running, that has been traced (in an automated way) to > two > different libgobject being used at the same time. I don't think I can help you with that here, but if you have something usable for debugging, like a stack trace, it might be worth to ask around Guile-GI (assuming it is not just a repetition of their #96). Regards, Leo