Successfully running GNOME on core-updates + staging

[Mark H Weaver]

Hello Guix,

I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.

My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.

So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

What do you think?

Mark

[Ludovic Courtès]

Hi Mark,

Post by Mark H Weaver
I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.
My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.
So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’
that Marius reported a few days ago, which I’m looking into right now.
I don’t expect the fix(es) to trigger a full rebuild.

If Marius and others don’t object, I’d say go for it!

Thanks,
Ludo’.

[Marius Bakke]

Post by Ludovic Courtès
Hi Mark,

Post by Mark H Weaver
I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.
My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.
So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’
that Marius reported a few days ago, which I’m looking into right now.
I don’t expect the fix(es) to trigger a full rebuild.
If Marius and others don’t object, I’d say go for it!

No objections from me. However I do have a bunch of fairly innocent
updates in my queue, such as SQLite, Glib and CMake. It's also tempting
to get rid of that Perl graft. Is it too late for such changes?

Hydra will be busy for a couple of days with 'master' and 'staging', so
there's little use in starting it immediately.

[Ludovic Courtès]

Hello,

Post by Marius Bakke

Post by Ludovic Courtès
Hi Mark,

Post by Mark H Weaver
I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.
My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.
So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’
that Marius reported a few days ago, which I’m looking into right now.
I don’t expect the fix(es) to trigger a full rebuild.
If Marius and others don’t object, I’d say go for it!

No objections from me. However I do have a bunch of fairly innocent
updates in my queue, such as SQLite, Glib and CMake. It's also tempting
to get rid of that Perl graft. Is it too late for such changes?

I think it’s OK for sqlite/glib/cmake, but changing Perl would further
delay things, which perhaps is not desirable.

Post by Marius Bakke
Hydra will be busy for a couple of days with 'master' and 'staging', so
there's little use in starting it immediately.

It took me a couple of days to reply :-), so maybe we can start the
evaluation now?

We can also get berlin to build all of ‘core-updates’ if we want.

Thanks,
Ludo’.

[Efraim Flashner]

Post by Ludovic Courtès
Hello,

Post by Marius Bakke

Post by Ludovic Courtès
Hi Mark,

Post by Mark H Weaver
I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.
My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.
So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’
that Marius reported a few days ago, which I’m looking into right now.
I don’t expect the fix(es) to trigger a full rebuild.
If Marius and others don’t object, I’d say go for it!

No objections from me. However I do have a bunch of fairly innocent
updates in my queue, such as SQLite, Glib and CMake. It's also tempting
to get rid of that Perl graft. Is it too late for such changes?

I think it’s OK for sqlite/glib/cmake, but changing Perl would further
delay things, which perhaps is not desirable.

Post by Marius Bakke
Hydra will be busy for a couple of days with 'master' and 'staging', so
there's little use in starting it immediately.

It took me a couple of days to reply :-), so maybe we can start the
evaluation now?
We can also get berlin to build all of ‘core-updates’ if we want.
Thanks,
Ludo’.

Perl should be straight forward, considering it would've been a normal
graft except for the version string part. Unless you're refering to
starting the rebuilds further down the tree.

[Marius Bakke]

Post by Ludovic Courtès
Hello,

Post by Marius Bakke

Post by Ludovic Courtès
Hi Mark,

Post by Mark H Weaver
I've successfully updated my x86_64 GuixSD system to my private branch
based on 'core-updates' with recent 'master' and 'staging' merged into
it. This system includes a full GNOME desktop environment plus a few
programs based on Qt. It all works quite well.
My branch includes a few draft fixes and workarounds that I haven't yet
pushed, but nothing that would require many rebuilds to update later.
So, I think it might be time to ask Hydra to build all of core-updates,
after staging is merged into it.

I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’
that Marius reported a few days ago, which I’m looking into right now.
I don’t expect the fix(es) to trigger a full rebuild.
If Marius and others don’t object, I’d say go for it!

No objections from me. However I do have a bunch of fairly innocent
updates in my queue, such as SQLite, Glib and CMake. It's also tempting
to get rid of that Perl graft. Is it too late for such changes?

I think it’s OK for sqlite/glib/cmake, but changing Perl would further
delay things, which perhaps is not desirable.

I was running a bit late with my patches and pushed them to a separate
branch before noticing the 'rhash' update on 'master'. Now there have
been a couple of world-rebuilding commits on the 'core-updates-next'
branch since, so I wonder how to move forward.

* Start 'core-updates' as-is.
* Pick all updates from the -next branch that won't rebuild the world
(that is everything apart from "xz" and "file").
* Take all the -next commits, remove the Perl graft, and do a new 'core'
evaluation.

Any preferences? Due to the "rhash" update, I suppose we can take
anything from -next that depends on CMake also with option #1.

Post by Ludovic Courtès

Post by Marius Bakke
Hydra will be busy for a couple of days with 'master' and 'staging', so
there's little use in starting it immediately.

It took me a couple of days to reply :-), so maybe we can start the
evaluation now?

Let's get this rolling as soon as the current Hydra queue clears!

[Leo Famulari]

Post by Marius Bakke
I was running a bit late with my patches and pushed them to a separate
branch before noticing the 'rhash' update on 'master'. Now there have
been a couple of world-rebuilding commits on the 'core-updates-next'
branch since, so I wonder how to move forward.
* Start 'core-updates' as-is.
* Pick all updates from the -next branch that won't rebuild the world
(that is everything apart from "xz" and "file").
* Take all the -next commits, remove the Perl graft, and do a new 'core'
evaluation.
Any preferences? Due to the "rhash" update, I suppose we can take
anything from -next that depends on CMake also with option #1.

I haven't been paying attention this cycle. But if anyone has, then I
think it's best to do option 1 along with the rhash, since most of the
bug-fixing work will still be valid.

[Mark H Weaver]

Post by Leo Famulari

Post by Marius Bakke
I was running a bit late with my patches and pushed them to a separate
branch before noticing the 'rhash' update on 'master'. Now there have
been a couple of world-rebuilding commits on the 'core-updates-next'
branch since, so I wonder how to move forward.
* Start 'core-updates' as-is.
* Pick all updates from the -next branch that won't rebuild the world
(that is everything apart from "xz" and "file").
* Take all the -next commits, remove the Perl graft, and do a new 'core'
evaluation.
Any preferences? Due to the "rhash" update, I suppose we can take
anything from -next that depends on CMake also with option #1.

I haven't been paying attention this cycle. But if anyone has, then I
think it's best to do option 1 along with the rhash, since most of the
bug-fixing work will still be valid.

I agree. I've been running core-updates for a long time now. It works.

The 'rhash' update has forced a great deal of rebuilding on it (my X200
has been rebuilding all night, and is still going), but I do not expect
that it will cause any new problems. The further updates on -next might
very well cause more bugs that need to be investigated and fixed.

The reason that I moved my own systems so agressively to core-updates
this cycle is because I no longer trust that grafting works properly on
'master', and so security flaws might not be fully addressed there. I'm
disappointed that there have been so many delays since then, and I'd
prefer not to add any more.

What do you think?

Mark

[Ludovic Courtès]

Post by Mark H Weaver
The reason that I moved my own systems so agressively to core-updates
this cycle is because I no longer trust that grafting works properly on
'master', and so security flaws might not be fully addressed there. I'm
disappointed that there have been so many delays since then, and I'd
prefer not to add any more.

I agree, let’s not delay things further.

So option #1 + rhash, so be it! When you’ve done that Marius, I’m happy
to get ‘core-updates’ built on berlin.

Besides, what makes you think grafting doesn’t work properly on master?

Thanks,
Ludo’.

[Mark H Weaver]

Hi Ludovic,

Post by Ludovic Courtès
Besides, what makes you think grafting doesn’t work properly on master?

Because of bug 30820: the default GCC on our master branch sometimes
incorporates string literals containing store references directly into
the generated x86 code, broken up into 8-byte chunks within immediate
load instructions, which cannot be rewritten by our grafting code. This
issue was fixed on core-updates only. The fix fundamentally requires a
full rebuild, so it cannot be done on master.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30820#51

Mark