bug#67651: [gnome-team] What should we do with the "gnome" package?

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Vivien Kraus via Bug reports for GNU Guix]

Dear guix,

On the one hand, we have this list of packages:
https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions

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

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Hi Vivien,

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
> 
> 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? 
No.

> What should we do about the comments dividing the propagated-
> inputs into categories? Where do these categories come from? 
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].
 
> Should we preserve them? How do we know which package goes to which
> category?
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.

> 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?
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/

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Tue, Dec 05, 2023 at 09:55:56PM +0100, Vivien Kraus via Bug reports for GNU Guix wrote:
> Dear guix,
>
> 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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
For the record, we have a new 44 release:
https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.7/versions

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!

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Vivien Kraus via Bug reports for GNU Guix]

Dear Guix,

Le dimanche 07 janvier 2024 à 17:53 +0100, Liliana Marie Prikler a
écrit :
> 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:
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.

> #core:calls:44.2:
(as said on IRC, I believe we have Calls already on gnome-team)

> core:font-abattis-cantarell:0.303.1:
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.

> core:epiphany:44.7:
We now have it, thank you!

> #core:gnome-logs:43.0:
The day elogind supports the journald API, we will be delighted to have
it (also see https://issues.guix.gnu.org/67338 ).

> #core:gnome-software:44.5:
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.

> #core:gnome-tour:44.0:
That’s Rust, unfortunately.

> 
> 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 :)
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.

> 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

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.
https://labo.planete-kraus.eu/email-key-rotation.git/tree/README.org

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Am Dienstag, dem 09.01.2024 um 12:10 +0100 schrieb Vivien Kraus:
> Dear Guix,
> 
> [...]
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.

> > 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 :)
> 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.
With "the gnome package" I mean the gnome metapackage that made you
raise this issue.

> > 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
> 
> 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.
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

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Vivien Kraus via Bug reports for GNU Guix]

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