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