Pushed a fix (?) for ACL key location

Pushed a fix (?) for ACL key location

[Christopher Lemmer Webber]

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.

I'm presuming this was expected to change given
ec4c404c0575b340a04b3922fb828ac5417832dd appearing to try to compensate
in the other direction *before* the new "guix" package version was
pushed.

If I made things worse, sorry in advance.  It fixes things here, but I
don't know the full context of what was going on.

 - Chris

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

[Marius Bakke]

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

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

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

Whoops, thanks for correcting my mistake, again.  :-)

> I'm presuming this was expected to change given
> ec4c404c0575b340a04b3922fb828ac5417832dd appearing to try to compensate
> in the other direction *before* the new "guix" package version was
> pushed.

Indeed, there was even a TODO comment about it just above the changed
line, now removed.

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

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

[Jonathan Brielmaier]

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.

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

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

[Marius Bakke]

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

Jonathan Brielmaier <jonathan.brielmaier@web.de> 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?

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

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?

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

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

[zimoun]

Hi Jonathan,

On Sun, 12 Jul 2020 at 13:42, Jonathan Brielmaier <jonathan.brielmaier@web.de> wrote:

> As I ran into all those little errors with `guix pull` this week-end, I
> wonder if we can do better.
>
> 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?

Testing "guix pull" to detect earlier breakage is a recurring topic. :-)
Well, "make as-derivation" or almost equivalently"./pre-inst-env guix
pull -p /tmp/new" are the tools to do so.  But they require some CPU
time, so they are not always done before pushing.  And when it is
pushed, it is too late.

> I find those little errors pretty annoying as they seem to be avoidable
> through technical counter measures...

Even if the CI detects the failure, this will not prevent the end-user
for pulling something broken.  It is because the model: push directly to
master without any CI validation. Something is wrong with this model
when we speak about annoyance by little errors.

The end-user should (only) pull (by default) commits which pass the test
suite *and* where the substitutes are available.

Cheers,
simon

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

[zimoun]

Dear Marius,

On Sun, 12 Jul 2020 at 14:33, Marius Bakke <marius@gnu.org> wrote:

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

If all the patches go to Debuggs (guix-patches) then using the commit
(format-patch --base=auto), the infrastructure could automatically
build, run tests, lint etc. then it eases the job of the reviewer and
the substitutes are available when the end-user pull.  The merge would
be done by hand --as today-- by the committer (pusher) to master.  Well,
Cuirass could track guix-patches instead of tracking master.

The issue of the rebuild-the-world accident could happen.  But it could
also happen now, with the current model.

It is a difficult topic but what is the feedback of such initiatives [1,2]?

1: https://patchwork.cbaines.net/project/guix-patches/list/
2: https://data.guix-patches.cbaines.net/

All the best,
simon

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

[Jonathan Brielmaier]

On 12.07.20 14:33, Marius Bakke wrote:
> Jonathan Brielmaier <jonathan.brielmaier@web.de> 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...