[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pushed a fix (?) for ACL key location

From: Jonathan Brielmaier
Subject: Re: Pushed a fix (?) for ACL key location
Date: Sun, 12 Jul 2020 18:27:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.9.0

On 12.07.20 14:33, Marius Bakke wrote:
> Jonathan Brielmaier <> writes:
>> On 12.07.20 03:44, Christopher Lemmer Webber wrote:
>>> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
>>> of Guix, and it looks like it wasn't possible to build new systems from
>>> that because the filename for the "Berlin ACL key" changed.  (Or at
>>> least, I couldn't run "guix system vm".)
>>> I pushed out a "fix" for this.  I hope it's ok.
>> Thanks for the fix.
>> As I ran into all those little errors with `guix pull` this week-end, I
>> wonder if we can do better.
> This particular change broke 'guix system', not 'guix pull'.  Which is
> equally bad of course, but a different kind of beast entirely.
> Are you referring to something else?

It started with d283bb960f927dd5f7bb8b96bc697221e4e8ad39 and it could be
`guix system` which failed. Then it's a different case, because testing
`guix system` is working, is more difficult.

>> So maybe some pre-checkin CI which tests that a commit/commit series
>> doesn't break `guix pull`. What do you think? Is this doable?
>> I find those little errors pretty annoying as they seem to be avoidable
>> through technical counter measures...
> One possible solution that has been discussed before is to have the CI
> continously merge master to a 'stable' branch when lights are green.
> There are quite a few challenges to solve with that approach though.
> We could make the pre-push hook run 'guix pull' and 'guix system build'
> but it will quickly get annoying.  A server-side hook for the same would
> be less annoying, but would have a hard time if someone accidentally
> pushes a full rebuild.

That's a point. So my idea was to do it at least for all changes of Guix
itself. Like updating the guix package, new po files, Makefile changes
etc. I think this could lead to quite an improvement.

> In practice there will always be problems that cannot be caught in an
> automated way.  I hope such breakages are rare, but from your message it
> sounds like there were many problems just this week-end?

I counted two or three this week-end connected with the renaming of the
public key of the berlin build farm, so a "trivial" change...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]