Successfully running GNOME on core-updates + staging

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

Re: Successfully running GNOME on core-updates + staging

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

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

Re: Successfully running GNOME on core-updates + staging

[Marius Bakke]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Mark,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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.

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

Re: Successfully running GNOME on core-updates + staging

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Mark,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> 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.

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

Re: Successfully running GNOME on core-updates + staging

[Efraim Flashner]

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

On Wed, Apr 25, 2018 at 02:14:04PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Marius Bakke <mbakke@fastmail.com> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Hi Mark,
> >>
> >> Mark H Weaver <mhw@netris.org> skribis:
> >>
> >>> 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.
> 
> > 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.

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

Starting 'core-updates'

[Marius Bakke]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hi Mark,
>>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> 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.

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

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

Re: Starting 'core-updates'

[Leo Famulari]

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

On Tue, May 01, 2018 at 04:12:42PM +0200, Marius Bakke wrote:
> 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.

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

Re: Starting 'core-updates'

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> On Tue, May 01, 2018 at 04:12:42PM +0200, Marius Bakke wrote:
>> 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

Re: Starting 'core-updates'

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

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

Re: Starting 'core-updates'

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> 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