unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Successfully running GNOME on core-updates + staging
@ 2018-04-21  7:54 Mark H Weaver
  2018-04-22 19:55 ` Ludovic Courtès
  0 siblings, 1 reply; 10+ messages in thread
From: Mark H Weaver @ 2018-04-21  7:54 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Successfully running GNOME on core-updates + staging
  2018-04-21  7:54 Successfully running GNOME on core-updates + staging Mark H Weaver
@ 2018-04-22 19:55 ` Ludovic Courtès
  2018-04-23 18:13   ` Marius Bakke
  0 siblings, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2018-04-22 19:55 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Successfully running GNOME on core-updates + staging
  2018-04-22 19:55 ` Ludovic Courtès
@ 2018-04-23 18:13   ` Marius Bakke
  2018-04-25 12:14     ` Ludovic Courtès
  0 siblings, 1 reply; 10+ messages in thread
From: Marius Bakke @ 2018-04-23 18:13 UTC (permalink / raw)
  To: Ludovic Courtès, Mark H Weaver; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Successfully running GNOME on core-updates + staging
  2018-04-23 18:13   ` Marius Bakke
@ 2018-04-25 12:14     ` Ludovic Courtès
  2018-04-25 13:23       ` Efraim Flashner
  2018-05-01 14:12       ` Starting 'core-updates' Marius Bakke
  0 siblings, 2 replies; 10+ messages in thread
From: Ludovic Courtès @ 2018-04-25 12:14 UTC (permalink / raw)
  To: Marius Bakke; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Successfully running GNOME on core-updates + staging
  2018-04-25 12:14     ` Ludovic Courtès
@ 2018-04-25 13:23       ` Efraim Flashner
  2018-05-01 14:12       ` Starting 'core-updates' Marius Bakke
  1 sibling, 0 replies; 10+ messages in thread
From: Efraim Flashner @ 2018-04-25 13:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Starting 'core-updates'
  2018-04-25 12:14     ` Ludovic Courtès
  2018-04-25 13:23       ` Efraim Flashner
@ 2018-05-01 14:12       ` Marius Bakke
  2018-05-01 14:23         ` Leo Famulari
  1 sibling, 1 reply; 10+ messages in thread
From: Marius Bakke @ 2018-05-01 14:12 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Starting 'core-updates'
  2018-05-01 14:12       ` Starting 'core-updates' Marius Bakke
@ 2018-05-01 14:23         ` Leo Famulari
  2018-05-01 18:23           ` Mark H Weaver
  0 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2018-05-01 14:23 UTC (permalink / raw)
  To: Marius Bakke; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Starting 'core-updates'
  2018-05-01 14:23         ` Leo Famulari
@ 2018-05-01 18:23           ` Mark H Weaver
  2018-05-01 20:46             ` Ludovic Courtès
  0 siblings, 1 reply; 10+ messages in thread
From: Mark H Weaver @ 2018-05-01 18:23 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Starting 'core-updates'
  2018-05-01 18:23           ` Mark H Weaver
@ 2018-05-01 20:46             ` Ludovic Courtès
  2018-05-01 21:21               ` Mark H Weaver
  0 siblings, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2018-05-01 20:46 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Starting 'core-updates'
  2018-05-01 20:46             ` Ludovic Courtès
@ 2018-05-01 21:21               ` Mark H Weaver
  0 siblings, 0 replies; 10+ messages in thread
From: Mark H Weaver @ 2018-05-01 21:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-05-01 21:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-04-21  7:54 Successfully running GNOME on core-updates + staging Mark H Weaver
2018-04-22 19:55 ` Ludovic Courtès
2018-04-23 18:13   ` Marius Bakke
2018-04-25 12:14     ` Ludovic Courtès
2018-04-25 13:23       ` Efraim Flashner
2018-05-01 14:12       ` Starting 'core-updates' Marius Bakke
2018-05-01 14:23         ` Leo Famulari
2018-05-01 18:23           ` Mark H Weaver
2018-05-01 20:46             ` Ludovic Courtès
2018-05-01 21:21               ` Mark H Weaver

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).