From: Jonathan Brielmaier <jonathan.brielmaier@web.de>
To: Marius Bakke <marius@gnu.org>, guix-devel@gnu.org
Subject: Re: Pushed a fix (?) for ACL key location
Date: Sun, 12 Jul 2020 18:27:34 +0200 [thread overview]
Message-ID: <bb647a6d-72ef-f00a-9f2a-776210c29d8b@web.de> (raw)
In-Reply-To: <87y2noc3qn.fsf@gnu.org>
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...
next prev parent reply other threads:[~2020-07-12 16:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-12 1:44 Pushed a fix (?) for ACL key location Christopher Lemmer Webber
2020-07-12 11:14 ` Marius Bakke
2020-07-12 11:42 ` Jonathan Brielmaier
2020-07-12 12:33 ` Marius Bakke
2020-07-12 14:21 ` zimoun
2020-07-12 16:27 ` Jonathan Brielmaier [this message]
2020-07-12 13:57 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb647a6d-72ef-f00a-9f2a-776210c29d8b@web.de \
--to=jonathan.brielmaier@web.de \
--cc=guix-devel@gnu.org \
--cc=marius@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).