Hi,
On Mon, 03 Feb 2025 at 17:41, Nicolas Graves wrote:
> What difference do you make between both? This is indeed an extension ;)
Ah cool! I’ve overlooked. :-)
Cheers,
simon
On 2025-02-03 16:43, Simon Tournier wrote:
> Hi,
>
> On Fri, 17 Jan 2025 at 22:44, Nicolas Graves wrote:
>
>> I recently started a guix extension to help manage complexities of
>> maintaining guix soft-forks.
>
> [...]
>
>
>> https://git.sr.ht/~ngraves/guix-stack
>
> Oh cool! This appears to me
Hi,
On Fri, 17 Jan 2025 at 22:44, Nicolas Graves wrote:
> I recently started a guix extension to help manage complexities of
> maintaining guix soft-forks.
[...]
> https://git.sr.ht/~ngraves/guix-stack
Oh cool! This appears to me the right direction. Instead of yet
another subcommand, I th
Hi,
On Thu, 16 Jan 2025 at 15:34, Liliana Marie Prikler
wrote:
> lfam: that's interesting that there is really a merge
> commit, for example if I remember right, the core updates merge few
> months ago happened by directly appending the commits instead of a
> merge commit
> Yes, there
Hi Guix,
A small update - I've implemented a `guix fork` command that should
solve this issue. I opened a new issue for it rather than spamming both
guix-devel and help-guix with patches:
https://lists.gnu.org/archive/html/guix-patches/2025-01/msg02847.html
And here is a link to v1.5 of the same
Am Donnerstag, dem 16.01.2025 um 17:29 + schrieb 45mg:
> Yeah, I know I can. My point is that people who use remote forks
> shouldn't have to rely on a trusted third party. We've figured out a
> way for upstream Guix not to have to, now let's try to extend that to
> forks.
Well, the same way al
Hi Nicolas!
Nicolas Graves writes:
> A lightly-related comment :
>
> I recently started a guix extension to help manage complexities of
> maintaining guix soft-forks. I haven't advertised it yet, and I'm fine
> authenticating locally for now. I mainly focus on reproducibility of
> patches sent
On 2025-01-16 15:34, Liliana Marie Prikler wrote:
>> The complexity is due to the requirements of not bumping the channel
>> introduction (to avoid the increased attack surface from having to
>> keep obtaining the updated one, as I discussed earlier), keeping fork
>> history intact (to avoid force
Liliana Marie Prikler writes:
>> All of these things discussed in this thread are technically
>> possible. But I think that we all agree that the friction involved,
>> compared to just using my own fork with the patch applied, is much
>> larger, at least in my opinion.
> Yes, we can agree that t
Saturanya Rahjane de Lasca writes:
>> Again, not disputing that things work fine for people with commit
>> access. Perhaps that is part of why this issue hasn't been addressed
>> before :P
> You may call us privileged – and yes, we are – but that doesn't change
> the fact that weakening security
Am Donnerstag, dem 16.01.2025 um 15:39 +0100 schrieb Tomas Volf:
> Liliana Marie Prikler writes:
>
> > [..]
> >
> > > Then there is anything modifying any of the guix commands.
> > > #74832 is over month old, and as far as I know, I am not able to
> > > fix guix-copy from a channel. #72928 too
henticate both upstream and fork
>> commits. If you can think of a simpler method that meets these
>> requirements, I'd love to hear it.
> Guix committers are more than happy to use work trees and rebases,
> which simplify this a lot – again, it's as simple as pull,
>
Liliana Marie Prikler writes:
> [..]
>
>> Then there is anything modifying any of the guix commands. #74832 is
>> over month old, and as far as I know, I am not able to fix guix-copy
>> from a channel. #72928 took over a month to merge, and again, not
>> sure how to patch guix-describe from a c
Am Donnerstag, dem 16.01.2025 um 13:10 + schrieb 45mg:
> As the 'Authenticate Your Git Checkouts'
> blog post [9] pointed out, we wouldn't need `guix git authenticate`
> if we were willing to delegate our security to a trusted third party,
> like all the open source projects that sport those "f
Ricardo Wurmus writes:
> Liliana Marie Prikler writes:
>
>>> This has the slight issue that I can no longer easily answer a
>>> question "is this commit in my fork", since I cannot search by the
>>> commit hash. I admit it is not a question I need to answer often
>>> (last time was on 21st of Oc
Start of forwarded message
Date: Wed, 15 Jan 2025 17:15:44 +
To: 45mg <45mg.wri...@gmail.com>
From: Attila Lendvai
Cc: Felix Lechner , Tomas Volf <~@wolfsden.cz>,
help-guix@gnu.org, guix-de...@gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
Liliana Marie Prikler writes:
[...]
> You can roll your own service definitions, but it does become harder
> when you want to keep all changes to that service from master as well.
> But `(use-modules (my-channel services nftables))` should pull that
> nftables code :)
[...]
>> Then there is an
Hi Liliana,
Liliana Marie Prikler writes:
> Hi,
>
> Am Mittwoch, dem 15.01.2025 um 15:48 + schrieb 45mg:
>> The idea of authentication is that once you trust the channel
>> introduction, you can be sure that everything you pull after that is
>> authentic. The introduction only needs to be tr
Liliana Marie Prikler writes:
>> This has the slight issue that I can no longer easily answer a
>> question "is this commit in my fork", since I cannot search by the
>> commit hash. I admit it is not a question I need to answer often
>> (last time was on 21st of October, CVE-2024-52867).
> You co
Am Donnerstag, dem 16.01.2025 um 00:01 +0100 schrieb Tomas Volf:
> Liliana Marie Prikler writes:
>
> > I think you're making this more complicated than it needs to be.
> > checkout, authenticate, rebase*, merge* ought to have you covered.
> >
> > * you can authenticate after these if you're par
Liliana Marie Prikler writes:
> I think you're making this more complicated than it needs to be.
> checkout, authenticate, rebase*, merge* ought to have you covered.
>
> * you can authenticate after these if you're paranoid
>
>> We could create a script to do all the steps for us, but if and wh
Hi,
Am Mittwoch, dem 15.01.2025 um 15:48 + schrieb 45mg:
> The idea of authentication is that once you trust the channel
> introduction, you can be sure that everything you pull after that is
> authentic. The introduction only needs to be trusted once. If you're
> bumping the introduction ever
i haven't read the entire thread [sorry], but with that in mind here's how i'm
solving this:
i have various branches where i keep my not-yet-merged work. i also have a
script that creates/overwrites a branch (called 'attila', starting at the tag
'attila-baseline') and cherry picks everything in
Hi Liliana!
Liliana Marie Prikler writes:
> For most use cases, this is a non-issue. Assuming you are a single
> committer to your fork, you can always rebase your changes on top of
> Guix (if you're willing to bump the introductory commit)
The idea of authentication is that once you trust the
Am Dienstag, dem 14.01.2025 um 04:21 + schrieb 45mg:
> --8<---cut here---start->8---
> When authenticating merge commits, intersection of authorized keys
> from all parents is used. That is fine in Guix proper, since all
> involved commits are under the contr
Drat, I should have used X-Debbugs-CC to CC Guix-Devel, etc., rather
than the regular CC line, in my previous mail.
The Debbugs address for this bug is 75...@debbugs.gnu.org. Please send
any replies there.
Hi Guix,
First of all, please spare me a few paragraphs to explain why I'm CC'ing
guix-devel on this bug report (I promise it's a good reason this time!).
Introduction
As has been mentioned many, MANY times on these lists, patch review is
erratic in Guix, and patches can be neglecte
27 matches
Mail list logo
