Hi,
Am Donnerstag, dem 06.01.2022 um 05:38 -0500 schrieb Mark H Weaver:
> > From here on, I will assume that each individual push action is
> > finite as you did, but I don't think that using communications of
> > finite length are a helpful building block here.
>
> Really? You don't think commu
Hi Liliana,
Liliana Marie Prikler writes:
> it ought to have been comparatively easy to infer that I was talking
> about push actions (plural) as sequences, not as individual push
> actions like you've used for your proof.
It makes no difference, because the set of push actions is closed under
s
Am Mittwoch, dem 05.01.2022 um 04:28 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Earlier, I wrote:
> > Sorry, but this is not even close to a valid argument that the set
> > of possible push actions to a Git repo is uncountable. In fact,
> > it's quite easy to prove that the set is countable.
Hi Liliana,
Earlier, I wrote:
> Sorry, but this is not even close to a valid argument that the set of
> possible push actions to a Git repo is uncountable. In fact, it's quite
> easy to prove that the set is countable. Any mathematician will know this.
I suppose I should give a proof. I'll giv
Hi Liliana,
Liliana Marie Prikler writes:
> Am Montag, dem 03.01.2022 um 18:14 -0500 schrieb Mark H Weaver:
>>
>> > If you are talking specifically about the uncountability of real
>> > numbers, that'd be quite deep down (as in an uncountability of push
>> > actions to a particular Git repo, pa
Am Montag, dem 03.01.2022 um 18:14 -0500 schrieb Mark H Weaver:
>
> > If you are talking specifically about the uncountability of real
> > numbers, that'd be quite deep down (as in an uncountability of push
> > actions to a particular Git repo, particularly if we also allow
> > reinitialization).
Hi Liliana,
On Tue, 4 Jan 2022 at 20:45, Liliana Marie Prikler
wrote:
> I don't think there's anything to see here. Believe it or not, but
> you've so far been boiling my water multiple times only to then throw
> it into my face as I attempt to put the rice in. Admittedly, that's a
> little fr
Hi simon,
> Please re-read all your answers and mines. I hope you will see where
> you were incorrect.
I don't think there's anything to see here. Believe it or not, but
you've so far been boiling my water multiple times only to then throw
it into my face as I attempt to put the rice in. Admitt
Hi Liliana,
On Tue, 04 Jan 2022 at 09:51, zimoun wrote:
> On Tue, 04 Jan 2022 at 06:23, Liliana Marie Prikler
> wrote:
>
>>> The content can be one file, some files, folders, etc. or Git
>>> objects as Git commit object or Git tree object or whatever.
>>> Therefore, Git commit hash only depen
On Tue, 04 Jan 2022 at 06:23, Liliana Marie Prikler
wrote:
>> The content can be one file, some files, folders, etc. or Git
>> objects as Git commit object or Git tree object or whatever.
>> Therefore, Git commit hash only depends on the content itself, i.e.,
>> Git commit object; as explain
Hi simon,
Am Dienstag, dem 04.01.2022 um 00:00 +0100 schrieb zimoun:
> [...]
>
> You are saying what I predicted you will say :-) ; here I quote
> myself:
>
> The statement «Git commit hashes do not just depend on the
> content» is wrong. [...]
>
> Sorry, I used meta-content in
Hi Liliana,
Liliana Marie Prikler writes:
> Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver:
>> Hi Liliana,
>>
>> Liliana Marie Prikler writes:
>>
>> > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver:
>> > > Liliana Marie Prikler writes:
>> > > > > Where is th
Hi Liliana,
On Mon, 03 Jan 2022 at 21:19, Liliana Marie Prikler
wrote:
> That's not the case I'm making here. The case I'm making is that Git
> considers some content content, which Guix does not consider content.
> If I push the same file to two branches, once with the commit message
> "Hello
Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Liliana Marie Prikler writes:
>
> > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver:
> > > Liliana Marie Prikler writes:
> > > > > Where is the Cantor-style diagonalization argument that you
> > >
Am Montag, dem 03.01.2022 um 20:07 +0100 schrieb zimoun:
> This is somehow intrinsic* because public-inbox uses Message-ID as URL.
> Therefore, using emacs-notmuch, you just have to search for
> id:86y243kdoo@gmail.com for instance.
>
> *intrinsic: no it is not intrinsic but self-contained. :-
Hi Liliana,
On Mon, 03 Jan 2022 at 19:13, Liliana Marie Prikler
wrote:
> Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun:
>> On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler
>> wrote:
>>
>> > > The statement still appears to me wrong because Git commit hash
>> > > only depends on th
Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun:
> Hi Liliana,
>
> On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler
> wrote:
>
> > > The statement still appears to me wrong because Git commit hash
> > > only depends on the content itself.
> >
> > If you define content through the NAR
On 2022-01-03, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> How about using the output of git describe, which can unambigously
>> include the most relevent tag, the number of commits since that tag, and
>> the commit hash:
>>
>> $ git describe --long --abbrev=41
>> v1.3.0-13278-g60
Hello,
Vagrant Cascadian skribis:
> How about using the output of git describe, which can unambigously
> include the most relevent tag, the number of commits since that tag, and
> the commit hash:
>
> $ git describe --long --abbrev=41
> v1.3.0-13278-g60661adfb8ffa28e1acfcfea27c6cc2fc70f88fe
Hello!
Timothy Sample skribis:
> If you want a concrete example to think through, there’s ‘eclib’. Our
> package says it’s version “20190909”, but that’s not what upstream calls
> version “20190909”. It looks like when we packaged ‘eclib’, that tag
> pointed to commit 19e7e3e74268bf78bd9a1c4ba
Hi Liliana,
On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler
wrote:
>> The statement still appears to me wrong because Git commit hash only
>> depends on the content itself.
>
> If you define content through the NAR hash used by Guix, I'm pretty
> sure vanity commits invalidate that statemen
Hey,
Liliana Marie Prikler writes:
> Since you are our expert on preservation, would you mind if I ask you
> for some estimates on how painful it is to track down such commits in
> general, if it could be made easier were you to record tag → commit
> (alternatively file-name x sha256 → SWHID) ma
Hi Liliana,
Liliana Marie Prikler writes:
> Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver:
>> Liliana Marie Prikler writes:
>>
>> > > Where is the Cantor-style diagonalization argument that you spoke
>> > > of?
>> > You skipped over it, read again. The key point is that you'
Hi Simon,
Am Sonntag, dem 02.01.2022 um 20:30 +0100 schrieb zimoun:
> Last on this point, using ’git-version’ and commit or tag to define
> Guix version (the field ’version’) is not related to the issue of
> referring by tag or commit in ’uri’ field. That’s not the same
> level.
Look at the title
Hi Mark, Liliana, all,
On Sat, 01 Jan 2022 at 15:37, Mark H Weaver wrote:
>>> Where is the Cantor-style diagonalization argument that you spoke of?
>>
>> You skipped over it, read again. The key point is that you're
>> referencing the thing you think will be invalidated to create your
>> scheme
Hi Mark,
Am Sonntag, dem 02.01.2022 um 07:25 -0500 schrieb Mark H Weaver:
> Repeating myself: our difficulties understanding each other on this
> point might be due a translation issue. Earlier, you wrote:
>
> > And here I disagree. This reasoning presupposes that we have to
> > ensure that the
Hi Liliana,
Liliana Marie Prikler writes:
> Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver:
>> Hi Liliana,
>>
>> Liliana Marie Prikler writes:
>>
>> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
>> > > I disagree with the last line above. What makes you
[0]
https://cdn.quotesgram.com/img/31/40/532049644-676813c5150a0168ad089c40202f742e.jpg
On +2022-01-01 12:12:33 +0100, Liliana Marie Prikler wrote:
> Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
> > I disagree with the last line above. What makes you think that I'm
> > pre
Hi,
Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Liliana Marie Prikler writes:
>
> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
> > > I disagree with the last line above. What makes you think that
> > > I'm presupposing that the tag d
Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver:
> Liliana Marie Prikler writes:
>
> > > Where is the Cantor-style diagonalization argument that you spoke
> > > of?
> > You skipped over it, read again. The key point is that you're
> > referencing the thing you think will be inval
Liliana Marie Prikler writes:
>> Where is the Cantor-style diagonalization argument that you spoke of?
> You skipped over it, read again. The key point is that you're
> referencing the thing you think will be invalidated to create your
> scheme.
I've carefully read your message at least 4 times
Hi Liliana,
Liliana Marie Prikler writes:
> Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
>> I disagree with the last line above. What makes you think that I'm
>> presupposing that the tag does change?
>>
>> There's a difference between "presupposing that the tag does change
Hi Timothy,
Am Samstag, dem 01.01.2022 um 12:45 -0500 schrieb Timothy Sample:
> If you want a concrete example to think through, there’s ‘eclib’.
> Our package says it’s version “20190909”, but that’s not what
> upstream calls version “20190909”. It looks like when we packaged
> ‘eclib’, that ta
Hi all,
Liliana Marie Prikler writes:
> Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
>
>> If upstream later indicates that version "1.2.3" is now commit YYZ, I
>> don't think that invalidates our basis for continuing to associate
>> version "1.2.3" with commit XYZ. The afore
Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
> I disagree with the last line above. What makes you think that I'm
> presupposing that the tag does change?
>
> There's a difference between "presupposing that the tag does change"
> and "not assuming that the tag will not change"
> Where is the Cantor-style diagonalization argument that you spoke of?
You skipped over it, read again. The key point is that you're
referencing the thing you think will be invalidated to create your
scheme.
Hi Liliana,
Liliana Marie Prikler writes:
> Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver:
>> Hi Liliana,
>>
>> Liliana Marie Prikler writes:
>> > In my personal opinion, the version+raw commit style can be
>> > discredited using Cantor's diagonal argument.
>>
>> You've ment
Hi Liliana,
Liliana Marie Prikler writes:
> Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver:
[...]
>> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package
>> is the right way to ensure that it can be reliably reproduced in the
>> future.
> And here I disagree.
Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Liliana Marie Prikler writes:
> > In my personal opinion, the version+raw commit style can be
> > discredited using Cantor's diagonal argument.
>
> You've mentioned Cantor's diagonalization argument at least twice
Am Freitag, dem 31.12.2021 um 18:56 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Liliana Marie Prikler writes:
>
> > Git commit hashes do not just depend on the content. They also
> > depend on how much effort you put into solving a proof of work
> > challenge that won't ever earn you crypto
Hi Liliana,
Liliana Marie Prikler writes:
> Git commit hashes do not just depend on the content. They also depend
> on how much effort you put into solving a proof of work challenge that
> won't ever earn you crypto coins [1].
My knowledge of git is admittedly not that strong, but my understan
Hi Liliana,
Liliana Marie Prikler writes:
> In my personal opinion, the version+raw commit style can be discredited
> using Cantor's diagonal argument.
You've mentioned Cantor's diagonalization argument at least twice in
this thread so far, but although I'm familiar with that kind of argument
fo
Hi,
Am Freitag, dem 31.12.2021 um 18:21 +0100 schrieb zimoun:
> Redundancy adds one kind of robustness: resilience. [...] However
> this assumes all the redundant nodes of the web of nets will be still
> up, at least enough to have this… robustness. Me too, I hope Guix
> will be popular and al
On 2021-12-28, Liliana Marie Prikler wrote:
> Consider a package being added or updated in Guix. At the time of
> commit, we have the tag v1.2.3 pointing towards commit deadbeef. We
> therefore create a guix package with version "1.2.3" pointing to said
> commit (either directly or indirectly).
Hi,
On Fri, 31 Dec 2021 at 16:19, Liliana Marie Prikler
wrote:
> You're also missing the part in which it currently relies on a single
> server to do all this, but there are plans to move it out to multiple
> ones, i.e. adding fallbacks/redundancy to your fallback mechanism,
> which for the rec
Hi,
Am Freitag, dem 31.12.2021 um 14:15 +0100 schrieb zimoun:
> [...]
> Version is also Guix specific. Sometimes, we patch; for security
> reasons, for fixing a bug, for quickly backporting something, for
> removing non-free bits, for unbundling stuff, for making work with
> the rest of Guix pack
Am Freitag, dem 31.12.2021 um 13:31 +0100 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > Particularly here, you're used to raw commit hashes, so you no
> > longer feel the need to add a comment explaining that it
> > corresponds to a given tag, which others (such as myself, your
Hi all,
On Fri, 31 Dec 2021 at 10:31, Ricardo Wurmus wrote:
> I have no strong feelings for or against any of the proposed options. I
> think that using raw commits might not be great for our tooling because
> we’re not reusing an existing version string and would need to remember
> to update t
Liliana Marie Prikler writes:
> Particularly here, you're used to raw commit hashes, so you no longer
> feel the need to add a comment explaining that it corresponds to a
> given tag, which others (such as myself, your past self and possibly
> your future self) would need at least until they th
Hi Ricardo,
Am Freitag, dem 31.12.2021 um 10:31 +0100 schrieb Ricardo Wurmus:
> In the past I’ve also added a comment above the raw commit, stating
> that it corresponds to the given version.
>
> I have no strong feelings for or against any of the proposed
> options. I think that using raw commi
Hi,
Am Freitag, dem 31.12.2021 um 08:57 +0100 schrieb Taylan Kammer:
> On 31.12.2021 04:15, Liliana Marie Prikler wrote:
> > [...] Obviously,
> > when travelling back in time, we want Guix' "1.2.3" to be whatever
> > it was by that point, but on th
Liliana Marie Prikler writes:
>> And for completeness, let quote Ludo again from the same thread. :-)
>>
>> No, I think we should consider always referring to commits
>> instead of tags. It’s annoying from a readability viewpoint,
>> but it would ensure reproducibility
On 31.12.2021 04:15, Liliana Marie Prikler wrote:
> [...] Obviously, when
> travelling back in time, we want Guix' "1.2.3" to be whatever it was by
> that point, but on the other hand, we also want a recently pulled Guix
> to have a reasonably recen
Hi,
Am Freitag, dem 31.12.2021 um 02:23 +0100 schrieb zimoun:
> Hi Liliana,
>
> I have read all your emails a couple of times and I am sorry I am
> still missing what you are raising. Because I feel we are failing to
> explain each other, that’s fine, it happens sometimes :-) I hope
> others wil
Hi Mark,
Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver:
> Hi Liliana,
>
> Liliana Marie Prikler writes:
> > It should be noted, that in the case of moving or deleted tags, the
> > assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds.
>
> Agreed, but I don't think that a
Hi Liliana,
I have read all your emails a couple of times and I am sorry I am still
missing what you are raising. Because I feel we are failing to explain
each other, that’s fine, it happens sometimes :-) I hope others will
find the intersection of this discussion.
Honestly I am lost in the midd
Am Donnerstag, dem 30.12.2021 um 13:43 +0100 schrieb zimoun:
> Hi Liliana,
>
> On Wed, 29 Dec 2021 at 21:25, Liliana Marie Prikler
> wrote:
> > Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun:
> > > On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler
> > > wrote:
>
> > The notion of e
Hi Mark,
On Wed, 29 Dec 2021 at 20:13, Mark H Weaver wrote:
> Guix packages that refer to git _tags_ may cease to be reproducible in
> the future if upstream mutates or removes those tags, and it's simply
> not feasible to transform our SHA256 hashes (of the NAR-encoded source
> checkout) into s
Hi Liliana,
On Wed, 29 Dec 2021 at 21:25, Liliana Marie Prikler
wrote:
> Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun:
>> On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler
>> wrote:
> The notion of equivalence I am using here is the same as in the
> statement "5 ≡ 2 mod 3", wher
Hi Liliana,
Liliana Marie Prikler writes:
> It should be noted, that in the case of moving or deleted tags, the
> assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds.
Agreed, but I don't think that assertion should be our top priority.
For purposes of Guix's core goal of enabling softwar
Hi,
Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun:
> Hi,
>
> On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler
> wrote:
>
> > Consider a package being added or updated in Guix. At the time of
> > commit, we have the tag v1.2.3 pointing towards commit deadbeef. We
> > therefore c
Hi,
On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler
wrote:
> Consider a package being added or updated in Guix. At the time of
> commit, we have the tag v1.2.3 pointing towards commit deadbeef. We
> therefore create a guix package with version "1.2.3" pointing to said
> commit (either dir
Hi Guix,
when Ricardo recently added guile-aiscm to Guix, I was confused that
both the version field of the package and the commit field of the git-
reference used in its origin. It turns out, that this is a rare
pattern observed in less than 200 packages currently in Guix. The
reason to do so
63 matches
Mail list logo
