bug#67608: qtbase fails to build on i686

[Efraim Flashner]

On Sun, Dec 03, 2023 at 06:42:10PM -0500, Maxim Cournoyer wrote:
> John Kehayias  writes:
> 
> > Hi Maxim,
> >
> > On Sun, Dec 03, 2023 at 01:32 PM, Maxim Cournoyer wrote:
> >
> >> Hi,
> >>
> >> After recent mesa/xorg upgrades, qtbase fails to build on i686, per
> >> .
> >
> > I saw this when I was working on the mesa-updates branch, but I didn't
> > think it was a new failure. I looked back just now and even going to
> > July or further back I don't see any successful builds of qtbase-6.*
> > on i686-linux. The most recent version has the same failures as this
> > log, pre-mesa-updates. Looked like a previous version of qtbase-6 had
> > a different failure though.
> 
> Indeed.  I wonder why Cuirass flagged the failure as a new one.

Maybe it was mixing up qtbase@5 and qtbase@6 for determining if it had
successfully built before?

> [...]
> 
> > As for the actual cause, I don't have a clue. There was a failure
> > cause by an update on that branch, which I had fixed in
> > aee3c5a894fddf88810f18fa8880b423b078b3fa (from libxkbcommon update).
> >
> > Was there a version of qtbase-6 that builds on i686?
> 
> OK.  I don't seem to find one looking at CI.  We should probably report
> this upstream if it hasn't already been.

I found it broken when I was going through a big rebuild and I believe
it tracked it down to the -DFEATURE_xxx=OFF flags that we've been
carrying since qt-4.  Once I removed them i686 stopped trying to use
128-bit numbers and compiled successfully.  As a comparison, Debian
doesn't use those flags.

I've closed the bug since it now builds, but feel free to re-open it if
we want to revisit removing the flags or anything.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux

[Efraim Flashner]

On Wed, Nov 29, 2023 at 03:55:15PM -0500, Leo Famulari wrote:
> I see that ci.guix.gnu.org's builders seem to run out of memory while
> building kernel headers for i686-linux:
> 
> --
> xz: (stdin): Cannot allocate memory
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: 
> /gnu/store/536ifp75wv8i1kb1k0szv7zd57ygpg0n-linux-libre-6.5.13-guix.tar.xz: 
> Wrote only 2048 of 10240 bytes
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: Child returned 
> status 1
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: Error is not 
> recoverable: exiting now
> --
> 
> https://ci.guix.gnu.org/build/2736161/details

This looks like more of the too-many-cores while decompressing tarballs
issues we've had in the past on i686-linux.  Can we change that phase to
use a maximum of 4 cores or would that cause everything to rebuild?

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67608: qtbase fails to build on i686

[Maxim Cournoyer]

Hello,

Efraim Flashner  writes:

[...]

> I found it broken when I was going through a big rebuild and I believe
> it tracked it down to the -DFEATURE_xxx=OFF flags that we've been
> carrying since qt-4.  Once I removed them i686 stopped trying to use
> 128-bit numbers and compiled successfully.  As a comparison, Debian
> doesn't use those flags.
>
> I've closed the bug since it now builds, but feel free to re-open it if
> we want to revisit removing the flags or anything.

Excellent, thank you!

-- 
Thanks,
Maxim

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Ludovic Courtès]

Hi,

Nils Landt  skribis:

> I use guix home for almost everything, but I have installed glibc-locales in 
> my "regular" guix (just by running guix package install glibc-locales).
> Now, running guix package --upgrade fails with:
> guix package: error: package glibc-locales@2.37 does not support x86_64-linux

Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.

The problem was that glibc-locales@2.37 is marked as supported for
i586-gnu only (that’s GNU/Hurd).

The workaround on GNU/Linux would have been to run:

  guix install glibc-locales@2.35

but of course, hard to guess given the error message.

Thanks,
Ludo’.

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