bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen


From: Vivien Kraus
Subject: bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen
Date: Wed, 10 Nov 2021 20:20:38 +0000
User-agent: mu4e 1.6.9; emacs 27.2

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> Am Dienstag, den 09.11.2021, 23:10 +0000 schrieb Vivien Kraus:
>> I fixed a couple of linter errors, and applied guix style to
>> it. However, now the linter complains that we have the "bin" output
>> of glib in something that would be called "glib" and not "glib:bin"…
>> Should we still keep the styled output?
> IIUC that's an issue with the linter or perhaps the implementation of
> short input lists in general.  I've CC'd Ludo as he is the one who
> allowed us to write inputs (list bash sed ...) in the first place,
> perhaps he knows what to do here.  We probably ought to convert this to
> short-style inputs anyway.
Apparently, we shouldn’t apply guix style yet, we will apply it for all
packages at once some day.

>> Subject: [PATCH 1/5] gnu: gnome-tweaks: Use libhandy 1.
> Note, libhandy 0.0 only exists on master (and therefore core-updates),
> because there are packages still using it.  If there's no more users
> post updating gnome-tweaks, it is to be removed!
I tried, but there are 2 problems:
1. I can’t update authenticator (gnu/packages/gnome.scm), because
upstream switched to Rust and I don’t know how to package that;
2. Geary needs it too (and gmime 2, which we could drop the same way),
but it’s a pain to upgrade. I went a long way, but there’s some vala
code that acts on strings as if they were arrays and I don’t know what
happens: maybe a newer vala is required, or the glib string type does
not apply for some reason.

However, I can provide an upgrade for seahorse (and its dependency
gcr). That’s a start, I guess.
:)

>> Subject: [PATCH 2/5] gnu: gnome-tweaks: Set the python path.
> Nice catch, I think this was previously done by a different phase. 
> However...
>> gnu/packages/gnome.scm (gnome-tweaks)[phases]: Also wrap with
>> GUIX_PYTHONPATH.
> Please note the phase and perhaps change its name to reflect what it
> does.
Is the 'wrap-gi-typelib-and-python boring name appropriate?

>> Subject: [PATCH 3/5] gnu: gnome-tweaks: gobject-introspection should
>> be a native input.
> I'm not sure this is the correct move here.  Python uses GI at runtime,
> not natively during build.  If gnome-tweaks requires GI at build time,
> it's to be added as both inputs.
It does not, I’ll drop it.

>> Subject: [PATCH 4/5] gnu: gnome-tweaks: Add bash-minimal as an input
>> to wrap the program.
> Split the long line.  Also perhaps add a comment in the file itself as
> to why this is needed if it's not already obvious from best practises
> in core-updates-frozen.
It’s flagged by the linter, because wrapping a program produces a shell
script that needs to be executed.

>> Subject: [PATCH 5/5] gnu: gnome-tweaks: Style it.
> This should probably done first, particularly if it helps avoid the
> linter complaints you encounter.
I’ve dropped the guix style for the reason above.

> In my personal opinion, 1, 3, 4 and 5 could also be done in a single
> commit, though YMMV.  Also, I'm not active on core-updates-frozen, so
> take everything I said as lexical analysis at best and with sufficient
> amounts of salt.
I’ll wait for more desalinated advice, because lumping commits together
is easier than separating a big one.

Attachment: 0001-gnu-gnome-tweaks-Use-libhandy-1.patch
Description: Use libhandy 1 in gnome-tweaks

Attachment: 0002-gnu-gnome-tweaks-Set-the-python-path.patch
Description: Wrap the python path in gnome-tweaks

Attachment: 0003-gnu-gnome-tweaks-Add-bash-minimal-as-an-input.patch
Description: Depend on bash-minimal to launch the wrapped program

Attachment: 0004-gnu-gcr-Upgrade-to-3.41.0.patch
Description: Upgrade gcr

Attachment: 0005-gnu-seahorse-Upgrade-to-41.0.patch
Description: Upgrade seahorse so that it does not depend on libhandy 0


Vivien

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]