Re: GNOME in Guix

[Leo Prikler]

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