[gnome-team] What should we do with the "gnome" package?

Dear guix,

On the one hand, we have this list of packages:

On the other hand, we have the propagated-inputs of the gnome package.

Should we update the latter so that it contains everything from the

former? What should we do about the comments dividing the propagated-

inputs into categories? Where do these categories come from? Should we

preserve them? How do we know which package goes to which category?

The gnome package disables eog on 32-bit machines because it depends on

librsvg-next. It seems a bit outdated to me, as most of gnome won’t

work on 32-bit machines, not only eog. Should we try and find which

ones work on 32-bit systems?

Best regards,

Vivien

Hi Vivien,

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:

No.

The categories are roughly inferred from a previous categorisation of

GNOME Apps. It is a little arcane and should probably be updated to

reflect https://apps.gnome.org/de/#core (roughly). Note that we'll

still be using the Core Apps from GNOME 44, which are listed in [1].

We should try to update them and better keep with upstream terms. I

think it also makes sense to split the gnome meta-package into multiple

meta packages and adjust the gnome-desktop service accordingly. For

one, we do need a gnome-shell-meta that has everything required to get

a running gnome-shell, even without any of the other core applications.

Then, gnome-core-main, gnome-core-mobile and gnome-core-tools could

hold the main, mobile and developer tools in the core apps

respectively.

Seeing how GNOME 45 deprecates eog in favour of loupe, yet another

bootstrap and build system nightmare, we should anyhow look into what's

buildable on 32-bit machines and offer suitable replacements. I'm very

much a proponent of reducing the amount of software on our GNOME stack,

not piling yet another heap of checksums onto it and calling dependency

management done.

Cheers

[1] https://blogs.gnome.org/mcatanzaro/2023/05/10/gnome-core-apps-update/

On Tue, Dec 05, 2023 at 09:55:56PM +0100, Vivien Kraus via Bug reports for GNU Guix wrote:

One option would be to wrap everything in 'supported-package?' and

append everything together. Then if something depends on the newer

librsvg and that isn't supported on that architecture it will just be

skipped.

Something to keep in mind though is the rust-team branch adds support

for cross-building rust, so you could end up with a different set of

packages depending on cross-building.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:

For the record, we have a new 44 release:

I've summarised our TODOs below: Each commented line (preceded by #)

denotes a package that doesn't exist on the gnome-team branch yet.

core:atkmm:2.28.3:

#core:calls:44.2:

core:font-abattis-cantarell:0.303.1:

core:epiphany:44.7:

#core:gnome-logs:43.0:

#core:gnome-software:44.5:

#core:gnome-tour:44.0:

I think we should settle on what to do with the gnome package soon to

not stall the branch even further. We can already start working

towards GNOME 46 after the merge :)

There is some gnome-adjacent software (particularly extensions, I don't

want all of them to break like they did the last time and the time

before) to have a look at as well before the merge, but it looks like a

nice road ahead.

We can do this!

Dear Guix,

Le dimanche 07 janvier 2024 à 17:53 +0100, Liliana Marie Prikler a

écrit :

Oops, I missed that one. Sorry. I checked the list by comparing our

versions to those of the list, but of course, our version of "atkmm" is

reported as 2.36.2, so I did not think further. 

The git log shows various documentation update, build system updates,

and documentation updates between 2.28.1 and 2.28.3.

(as said on IRC, I believe we have Calls already on gnome-team)

I don’t know where this 0.303.1 tag comes from, I can’t see it. It’s

neither a tag nor a gitlab release. There has only been translation

updates for the appstream metadata since our commit.

We now have it, thank you!

The day elogind supports the journald API, we will be delighted to have

it (also see https://issues.guix.gnu.org/67338).

I thought it was pointless to package it, but see

https://issues.guix.gnu.org/68228: it is claimed that we can use it to

install flatpaks.

That’s Rust, unfortunately.

In my opinion, we should have atkmm:2.28.3, but I see atkmm-2.28 being

used as a propagated-inputs for gtkmm-3, and gtkmm-3 is an input for

inkscape. That’s a world rebuild…

For Cantarell fonts, maybe we should point to the latest commit? That’s

another world rebuild though, and for very little gain as of now.

I’m not sure a flatpak-only gnome software is a hard requirement. It

would be most confusing. Gnome-tour is nice, but I think we can live

without it until we figure out this “rust” stuff.

You mean, the gnome-shell-extension-* in (gnu packages gnome-xyz)? I

don’t use them (I was told they were frequently broken so I never

bothered to try them!) so I’m not sure I can reliably tell whether they

work correctly.

Best regards,

Vivien

P.S. After a brief period of not being able to send an e-mail, this is

the first I send with my new email-key-rotation-service-type! I hope it

travels safely to your inbox.

Am Dienstag, dem 09.01.2024 um 12:10 +0100 schrieb Vivien Kraus:

I know that a bunch of packages have reasons not to exist in Guix, I

simply wanted to point out that we don't have them.

With "the gnome package" I mean the gnome metapackage that made you

raise this issue.

They tend to get broken with each gnome update, but I'm here to change

that. Testing them is actually quite simple: construct a guix system

vm with a gnome that has all the extensions, run it, then enable all of

them one by one in the GUI. If there's a version incompatibility, you

will notice.

Cheers

This is being worked on at https://issues.guix.gnu.org/68716