On Monday, October 18th, 2021 at 7:40 AM, Ludovic Courtès
wrote:
> Hi Ryan,
> How would we define “bad” though?
A definition isn't necessary, this can be an "I know it when I see it" thing.
If we have an oops or discover an issue, and say oh darn that lives in the repo
forever now, we'd be ab
Jan Nieuwenhuizen writes:
> Arun Isaac writes:
>
> Hello,
>
>>> My suggestion is simple: remove the added layer of complexity introduced
>>> by the .exwm file; don't force a default Exwm config on the user.
>>
>> I think I agree with you now. I checked, and exwm indeed does not run
>> when emacs
Hello,
Thiago Jung Bauermann skribis:
> I’ve been thinking lately that Guix {sh,c}ould have a new ’release-signing-
> keys’ field in the package record which would list the keys that are known
> to sign official releases of the package. Then Guix would check the tarball/
> git commit/git tag wh
Hi Ryan,
Ryan Prior skribis:
> I've suggested this before and this seems like a good time to bring it
> up again: can we create a database of known "bad" Guix commit hashes,
> and make time-machine fetch the list and warn before it'll visit one
> of those hashes? This would resolve the land-mine
Moin!
Liliana Marie Prikler skribis:
> Am Freitag, den 15.10.2021, 20:54 +0200 schrieb Ludovic Courtès:
[...]
>> It’s nothing new, it’s what I do when I want to test the download
>> fallbacks (see also ‘GUIX_DOWNLOAD_FALLBACK_TEST’ in commit
>> c4a7aa82e25503133a1bd33148d17968c899a5f5). Still
