Re: On raw strings in commit field

[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 the other hand, we also want a recently pulled Guix
> to have a reasonably recent "v1.2.3" if it claims to have "1.2.3". [...]

I think here lies the crux of the disagreement.  As far as I understand,
Guix doesn't intend to support the notion that one version string could
represent two different actual versions of a program throughout time.

Rather, I think, the reason Guix keeps both the tag and commit ref is
simply that the tag could disappear from the repo.  (In my experience,
that's easy to do by accident when you clone a repo and push it to a
new location.  You have to fetch and push the tags explicitly.)

If a tag ever *was* changed to point to a different commit, meaning that
the same version string now represents a different actual version, then
I think Guix would give that version a new name, such as "1.2.3-new" or
whatever.  I don't know if this ever actually happened, but I think this
is how Guix would probably want to deal with it if it does.  Having one
string represent two different actual versions is just really terrible
and I don't see Guix ever supporting such a practice.


[tangent follows]

(A software developer might argue that two different commits actually
are the same version of the software, say for instance because only a
minor change in the build system or README file or such was made, i.e.
files that are considered "not part of the end-product," but in Guix
land I think we wouldn't let that fare.  Maybe an exception would be
made if it was proven that the actual package produced by Guix from
both commits will always be bit-identical.  Even then, better not.)


P.S. I hope I'm actually helping to add clarity to the thread instead
of more confusion by adding my voice.  I was just skimming the ML,
found this thread interesting, and thought I might be able to add
clarity, because it seemed a little confusing. :-)

-- 
Taylan

Re: Organising Guix Days

[adriano]

Il giorno gio, 30/12/2021 alle 09.53 +0700, Blake Shaw ha scritto:
> 
> Hi folks,
> 
> Regarding the presentation I'm putting together on the Guile
> Documentation, while I have enough material right now to send out a
> basic presentation that covers what I believe to be the dominant,
> glaring issues of the composition and organization of the docs as
> well
> as how I would go about restructuring them if everyone agrees with
> the
> proposed edits, I'm also starting to uncover some more nuanced
> issues with some of the pedagogical folly that appears throughout the
> text, and so a few more weeks would probably result in a more
> comprehensive study.
> 
> So I was thinking, in that case, should I just make the presentation
> for
> Guix Days? That way it could also be presented at a time when other,
> perhaps related projects and issues are coming to the fore.
> 

I'd say:

if it's not too much hassle for you, prepare the "reduced" version for
the Guix Days

In such version, you could just hint that there's more to come

As for the more nuanced version, you could take your time and do it
when you feel it's ready 

I can't wait <3

Thanks !

Re: On raw strings in commit field

[Liliana Marie Prikler]

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 will find the intersection of this discussion.
> 
> Honestly I am lost in the middle of somewhere between affine space
> and Cantor’s diagonal argument. ;-)
To shorten it, we currently have the following problem: We can specify
the commit field by tag, which is not robust, by raw commit which is
confusing and can be misleading, or by let-bound commit with a special
version field, which is still confusing if we're at an epsilon revision
(epsilon meaning nothing changed since release and we're not expecting
change), but beats the first option in robustness and the second in
readability at the cost of having a funky version field.  I am arguing
that we should go with either option one or three, but never two.

> I agree with this statement:
> 
>     >> SWH records the “history of the history”.  It can tell you
> what the
>     >> tag pointed to at the time of a specific snapshot.
>     This just reiterates my point of Guix not trying hard enough with
>     fallbacks.
> 
> and in my views, the path to robustify the fallback is via more
> immutable content-address and intrinsic values and less mutable
> broken string as URL+tag.  Obviously, 1) all is not white or black
> and many things are grey as always and 2) we have to deal with this
> broken world of URL+tag, thus I hope we will improve the fallback SWH
> through various snapshots instead of considering only the last one.
> 
> However consider that SWH is an archive, not a forge or a mirror.  It
> means that SWH ingests this or that only every X months.  Therefore,
> you have no guarantee that the snapshots represents the complete
> history of history.
> 
> For sure, upstream can remove some commits between two ingestions. 
> But, most of the time, commits (history) are kept and the bad
> practise is to just move the pointer (tag) from one commit to
> another.
To be fair, you raise a good point with SWH not being infallible, so we
might want to have fallbacks that work regardless of it.  That being
said, we don't support git-mirrors yet either, do we?

> > I'mma quote Ludo for a change.
> 
> 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.  Even flatpak has this
>     policy.  :-)
> 
>   https://github.com/flathub/flathub/wiki/App-Requirements
... 

Fine, I'mma quote flathub for a change.
> When building from a git tag, both the tag name and the commit id
> should be specified, like so:
> 
>"tag": "1.0.4",
>"commit": "cdfb19b90587bc0c44404fae30c139f9ec1cca5c"
It's almost as though they know a commit without a tag has no intrinsic
meaning.  Also, I'm pretty sure flatpak could care less about hashes if
asked to (unlike Guix, which requires you provide one to be granted
network access), so the optional by means other than policy SHA-1 hash
here is not comparable to the required SHA-256 hash we always have.

Also, even if we do decide to sacrifice readability for the greater
reproducibility, I think this approach is especially hostile to the
future reader in the very case it is concerned about.  For all they
know, this particular Guix package of version "1.0.4" could have had
cosmetic changes applied, which were not at all cosmetic, but rather a
downgrade to 0.1.4.

Cheers

Re: On raw strings in commit field

[Liliana Marie Prikler]

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 assertion should be our top priority.
> 
> For purposes of Guix's core goal of enabling software to be reliably
> reproduced in the future, the most important property to preserve is
> that 'Guix "1.2.3"' should remain forever immutable.
> 
> An obvious corollary is that if upstream mutates the meaning of
> 'upstream "v1.2.3"' over time, then the equation above will become
> false.  That would be an unfortunate result of upstream's actions, but
> it's exactly what _needs_ to happen to enable Guix to be reliably
> reproducible.
> 
> If I perform an experiment with Guix "1.2.3" and publish the results,
> and someone later wishes to reproduce those results, they will want
> precisely the same 'Guix "1.2.3"' that was used to perform the original
> experiment, and not whatever version of the software upstream is now
> calling "v1.2.3".
I agree with you so far, though with some nuance.  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 recent "v1.2.3" if it claims to have "1.2.3".  So
we have two proposals at odds with each other, with only the origin-
hash to determine which interpretation to prioritize.

> 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.  This reasoning presupposes that we have to ensure
that the package still points to the same commit if the tag changes,
which itself presupposes that the tag does change.  However, if we are
always talking about more than one possible "1.2.3" (with the included
future tag that we have yet to witness), we lose the basis by which we
currently assign "1.2.3" as the version (instead of using git-version,
as we expect it won't be "1.2.3" at some future point).  This scheme
only makes sense when it doesn't make sense and when it doesn't make
sense it makes sense.

> 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 something that we can use to fetch the archived source
> from SWH.  There's simply no hope to make that work, unless we can
> convince SWH to maintain a secondary index of their content based on
> NAR-encoded source trees, which seems unlikely.
As pointed out elsewhere, SWH keeps a history of the tags that we could
look up until one matches, and there'd also be the option to keep a
secondary index ourselves (or have a third party do it).

> On the other hand, if we refer to git _commit hashes_, then it *is*
> feasible for us to fetch the archived source from SWH, regardless of
> what upstream has done to its tags in the meantime.
> 
> For that reason alone, I think that the way Ricardo wrote the
> guile-aiscm package definition is clearly the right approach, given
> Guix's longstanding goals.
To me, it rather sounds like a workaround for longstanding bugs [1, 2].
And then again it rests on the assumption that upstream does awful
things to their tags which makes no sense when it makes sense.

> > On the note of fallbacks, we do also have the issue that Guix fails
> > on the first download that does not match the hash instead of e.g.
> > continuing to SWH to fetch an archive of the old tag (as well as
> > other fallback-related issues, also including the "Tricking Peer
> > Review" thread).
> 
> That's a bug that can, and should, be fixed.  The existence of that
> bug might temporarily prevent us from enjoying the benefits of
> Ricardo's approach, but that's not an argument for adopting practices
> that push us farther from our core goals.
> 
> What do you think?
Which bug are you talking about?  "Tricking Peer Review" or the
fallback thing?  If it's the fallback thing, then that's an enabler for
Ricardo's approach, since as you pointed out the commit will still be
fetched correctly from SWH (if not from the main repo itself). 
Insufficient fallbacks are what make it painful to refer to moving
commit tags by tag, since our SWH lookup currently breaks when it
doesn't need to.  Having sufficient fallbacks would mean that we could
use git tags as we did before even in those cases, since the SWH (or
other) fallback would kick in and give us the historical version
matching our origin-hash.

Now, "Tricking Peer Review" is a harder thing to circumvent.  We would
need to issue a warning, preferably a big one if fallbacks do kick in
unintended, i.e. particularly outside of time-machine.

Cheers

[1] https://issues.guix.gnu.org/28659
[2] 

Re: On raw strings in commit field

[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 will
find the intersection of this discussion.

Honestly I am lost in the middle of somewhere between affine space and
Cantor’s diagonal argument. ;-)


I agree with this statement:

>> SWH records the “history of the history”.  It can tell you what the
>> tag pointed to at the time of a specific snapshot.
This just reiterates my point of Guix not trying hard enough with
fallbacks.

and in my views, the path to robustify the fallback is via more
immutable content-address and intrinsic values and less mutable broken
string as URL+tag.  Obviously, 1) all is not white or black and many
things are grey as always and 2) we have to deal with this broken world
of URL+tag, thus I hope we will improve the fallback SWH through various
snapshots instead of considering only the last one.

However consider that SWH is an archive, not a forge or a mirror.  It
means that SWH ingests this or that only every X months.  Therefore, you
have no guarantee that the snapshots represents the complete history of
history.

For sure, upstream can remove some commits between two ingestions.  But,
most of the time, commits (history) are kept and the bad practise is to
just move the pointer (tag) from one commit to another.


> I'mma quote Ludo for a change.

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.  Even flatpak has this
policy.  :-)

  https://github.com/flathub/flathub/wiki/App-Requirements




Cheers,
simon

Re: On raw strings in commit field

[Liliana Marie Prikler]

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 equivalence I am using here is the same as in the
> > statement "5 ≡ 2 mod 3", wherein the ≡ symbol is ironically called
> > IDENTICAL TO in Unicode despite being used very differently in
> > mathematics.  Perhaps there is a language barrier here; in German
> > we read that as "5 is equivalent to 2 modulo 3" and logic
> > equivalence functions similarly.
> 
> I do not understand against what you are arguing so I skip it. :-)
I was under the impression that you and I used the word "equivalent"
differently, so I wanted to clear that up.

> > For the record, one could argue that I should have used that symbol
> > for comparing Guix "1.2.3" to upstream "v1.2.3" because they are in
> > fact not equal, only equivalent, but that's besides the point.  The
> > point is, with an upstream behaving as we want upstreams to behave
> > (not just git ones, url-fetch suffers from the same issue with
> > moving tarballs for instance), you can substitute one for the other
> > without a change in meaning; both will fetch the same commit.
> 
> If I understand you correctly:
> 
>  - Guix "1.2.3" means the field ’version’
>  - upstream “v1.2.3” means the upstream tag used by the field
> ’commit’ of ’git-reference’.
> 
> and yes it is strongly expected that these both fields matches. :-)
Well, at least we agree on something.

> But it is irrelevant, IMHO, to your initial message «commit tags are
> in principle mutable and hence can not be relied on when fetching
> sources.  I do have a few issues with that explanation».  It is
> fortunate and not robust that ’commit’ matches ’version’ via upstream
> ’tag’.
It is in fact very relevant to the issue at hand.  In principle,
versioned URLs are not robust, hence we can't have a single package
using url-fetch.  A statement like that is obviously silly, not just
because tarballs that are updated in-place are exceedingly rare, but
also because they violate how we think about versions.  The same holds
for git, with the difference being that we no longer generate a URL
from the version, but a tag.  If that tag can't serve as bridge here,
the version field loses the meaning it had from the strong expectation
that the two of them match.

> Because how ’commit’ and ’tag’ are defined is different.
> 
> I cannot tell it differently than: Git commit depends only on the
> content, although ’tag’ not.
> 
> Version (or tag) is convenient names for humans.  It is easier to
> tell version 0.23.1 than
> 09rdbcr8dinzijyx9h940ann91yjlbg0fangx365llhvy354n840.  And we can
> deduce that 0.22.3 is older than 0.23.1, when it is impossible for
> commits.
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].

> If you prefer to keep the frame: «you can substitute one for the
> other without a change in meaning», then, for what my opinion is
> worth on that matter, my probably wrong understanding of your words
> is that perhaps you are missing a point about content-addressability.
To be fair, I did not consider content-addressability here, because my
main concern is natural intelligence based verification.  

> > > From the content to the hash, three keys: 1) how to serialize and
> > > 2) how to hash and 3) how to represent the hash.  For #1, Git
> > > uses their own serializer and Guix, inheriting from Nix, uses
> > > another (Nar); although the difference is minor.  For #2, Git
> > > uses by default SHA-1 as hash function, although Guix uses SHA-
> > > 256.  And for #3, Git uses hexadecimal format and Guix uses nix-
> > > base32.
> 
> [...]
> 
> > > To make it explicit, the checksum hash of ’git-reference’ could
> > > be removed because it is somehow redundant with the commit hash.
> > > Obviously, it cannot because security reason (SHA-1 is considered
> > > as weak).
> > 
> > The other way also works.  If Git used a secure hashing function
> > such as SHA-256 (or SHA-512 or Keccak) and Guix supported that
> > hash, we could generate a git hash from the Guix hash (assuming
> > also we allow the origin serializer to be configured, which would
> > be required either way).
> 
> Yes somehow.  To be on the same wavelength, we need to be precise
> when we speak about hash here because hash means:
> 
>  - serializer: how to deal with all the bits making the full content
>    (files, folder, tree, etc.)
>  - hashing function
>  - format
> 
> So yes, on principles, instead of NAR + SHA-256 + Nix-base32, the
> Guix project could have chosen Git + SHA-1 + Hex, or Git + SHA-512 +
> Base64 or any other combinations.
> 
> (I think this choice inherited from Nix is rooted in daemon
> implementations and 

Re: Guix Documentation Meetup

[adriano]

Il giorno dom, 12/12/2021 alle 21.50 -0600, Katherine Cox-Buday ha
scritto:



> - In geiser, run =,a thing-i-want-to-look-for= (this is supposedly an
> apropos
>   command that is supposed to search symbols for you). The command
> returns
>   nothing. I realize I have to import the module implementing the
> thing I'm
>   looking for first, thus defeating the purpose.

about this, I want to report an example

scheme@(guile-user)> (help tail)
Did not find any object named `tail'
scheme@(guile-user)> 


BUT


scheme@(guile-user)> (help "tail") <-- notice the quotation marks !
Documentation found for:
(language cps): $ktail
(language tree-il): seq-tail
(language tree-il): abort-tail
(guile): list-tail
(guile): make-struct/no-tail
(srfi srfi-1): find-tail
(system vm assembler): emit-tail-call-label
(system vm assembler): emit-tail-call
(system vm assembler): emit-tail-pointer-ref/immediate
(ice-9 vlist): vlist-tail

`$ktail' is an object in the (language cps) module.

- Variable: $ktail


`seq-tail' is a procedure in the (language tree-il) module.

- Variable: seq-tail


`abort-tail' is a procedure in the (language tree-il) module.

- Variable: abort-tail


`list-tail' is a procedure in the (guile) module.

- Function: list-tail _ _
 - Scheme Procedure: list-tail lst k
 
 
  Return the "tail" of LST beginning with its Kth element.  The
first
  element of the list is considered to be element 0.
 
  `list-tail' and `list-cdr-ref' are identical.  It may help to
think
  of `list-cdr-ref' as accessing the Kth cdr of the list, or
  returning the results of cdring K times down LST.



`make-struct/no-tail' is a procedure in the (guile) module.

- Function: make-struct/no-tail _ .  _
 - Scheme Procedure: make-struct/no-tail vtable .  init
  Create a new structure.
 
  VTABLE must be a vtable structure (see Vtables).
 
  The INIT1, ... are optional arguments describing how
successive
  fields of the structure should be initialized.  Note that
hidden
  fields (those with protection 'h') have to be manually set.
 
  If fewer optional arguments than initializable fields are
supplied,
  fields of type 'p' get default value #f while fields of type
'u'
  are initialized to 0.



`find-tail' is a procedure in the (srfi srfi-1) module.

- Function: find-tail pred lst
 Return the first pair of LST whose CAR satisfies the predicate
 PRED, or return `#f' if no such element is found.



`emit-tail-call-label' is a procedure in the (system vm assembler)
module.

- Function: emit-tail-call-label asm t-ff72ee5a3696d21-378b


`emit-tail-call' is a procedure in the (system vm assembler) module.

- Function: emit-tail-call asm


`emit-tail-pointer-ref/immediate' is a procedure in the (system vm
assembler) module.

- Function: emit-tail-pointer-ref/immediate asm t-ff72ee5a3696d21-3ac6
t-ff72ee5a3696d21-3ac7 t-ff72ee5a3696d21-3ac8


`vlist-tail' is a procedure in the (ice-9 vlist) module.

- Function: vlist-tail vlist
 Return the tail of VLIST.


That is, help with the quotation marks reports about things even if
they're in namespaces you haven't imported yet !


I'm confused about the difference between help withouth and with the
quotation marks

In fact

scheme@(guile-user)> ,a tail
(guile): list-tail  #
(guile): make-struct/no-tail#


apropos does find at least something, but

scheme@(guile-user)> (help tail)
Did not find any object named `tail'


help with no quotation marks finds nothing !

Why is this so ?

I can't fathom that ¯\_(ツ)_/¯

And I can't even remember how I discovered this behaviour

I remember I was quite puzzled when I did

This is hidden and arbitrary

But it IS like that !

So maybe this little trick can make your sessions a bit less
frustrating !

"tail" was just a silly example I was able to come up with

I'd be curious to try with some of your things :-)

Bye
Adriano

Updating old blog posts?

[Leo Famulari]

I updated a section of the cookbook so that it was still useful after
some changes in Guix:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c7d74a9bccfc1b1274fc8754a6e78bb6887c7fea

There was also a blog post made from this cookbook recipe:

https://guix.gnu.org/en/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/

Should we update it too?

Re: Guix Package Search API Server

[Sai Karthik]

I have observed that debian provides a similar api 
https://sources.debian.org/doc/api/


On 30/12/21 23:23, zimoun wrote:

Hi,

On Thu, 30 Dec 2021 at 22:33, Sai Karthik  wrote:


Nice! I didn't knew about this earlier. Does hpc.guix.info exposes API ?


I do not know.

Unrelated naive question, what is the aim to have an API for packages?


Cheers,
simon


--
https://kskarthik.gitlab.io/


OpenPGP_0xF5B9A961BF6EAF0E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Guix Package Search API Server

[zimoun]

Hi,

On Thu, 30 Dec 2021 at 22:33, Sai Karthik  wrote:

> Nice! I didn't knew about this earlier. Does hpc.guix.info exposes API ?

I do not know.

Unrelated naive question, what is the aim to have an API for packages?


Cheers,
simon

Re: Guix Package Search API Server

[Sai Karthik]

Nice! I didn't knew about this earlier. Does hpc.guix.info exposes API ?

On 30/12/21 19:50, zimoun wrote:

Hi,

On Thu, 30 Dec 2021 at 15:50, Sai Karthik  wrote:

Hello everyone!, I was unable to find any API for querying guix package
info on official guix website. So, I have created a very simple REST API
server for searching/querying package info in Javascript. It parses the
package info from https://guix.gnu.org/packages.json file & returns the
results.


Maybe you could be interested by .  Or by




Cheers,
simon


--
https://kskarthik.gitlab.io/


OpenPGP_0xF5B9A961BF6EAF0E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Guix Package Search API Server

[zimoun]

Hi,

On Thu, 30 Dec 2021 at 15:50, Sai Karthik  wrote:
> Hello everyone!, I was unable to find any API for querying guix package 
> info on official guix website. So, I have created a very simple REST API 
> server for searching/querying package info in Javascript. It parses the 
> package info from https://guix.gnu.org/packages.json file & returns the 
> results.

Maybe you could be interested by .  Or by




Cheers,
simon

Re: On raw strings in commit field

[zimoun]

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 something that we can use to fetch the archived source
> from SWH.  There's simply no hope to make that work, unless we can
> convince SWH to maintain a secondary index of their content based on
> NAR-encoded source trees, which seems unlikely.

Yes, that’s the core point. :-)

Basically, url+tag can work with the SWH API.  But SWH stores
snapshots so it is not always straightforward.


> On the other hand, if we refer to git _commit hashes_, then it *is*
> feasible for us to fetch the archived source from SWH, regardless of
> what upstream has done to its tags in the meantime.

Well, IMHO, the main point of the story is how to content-address, i.e.,
using which method.

SWH promotes their own encoding named ’swhid’ (basically, it looks
similar to Git commit).  Many other address types are around.

It had been discussed to maintain this secondary index via a Disarchive
database – potentially bridging from our SHA-256 to other addressing
hash.  One issue is that the package definition is not self consistent
and requires this external service.  On the other hand, we cannot
predict the future and who could tell which content-address systems will
be still there?  ;-)

This content-address is not an easy topic. :-)


Cheers,
simon

Re: On raw strings in commit field

[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 equivalence I am using here is the same as in the
> statement "5 ≡ 2 mod 3", wherein the ≡ symbol is ironically called
> IDENTICAL TO in Unicode despite being used very differently in
> mathematics.  Perhaps there is a language barrier here; in German we
> read that as "5 is equivalent to 2 modulo 3" and logic equivalence
> functions similarly.

I do not understand against what you are arguing so I skip it. :-)


> For the record, one could argue that I should have used that symbol for
> comparing Guix "1.2.3" to upstream "v1.2.3" because they are in fact
> not equal, only equivalent, but that's besides the point.  The point
> is, with an upstream behaving as we want upstreams to behave (not just
> git ones, url-fetch suffers from the same issue with moving tarballs
> for instance), you can substitute one for the other without a change in
> meaning; both will fetch the same commit.

If I understand you correctly:

 - Guix "1.2.3" means the field ’version’
 - upstream “v1.2.3” means the upstream tag used by the field ’commit’
   of ’git-reference’.

and yes it is strongly expected that these both fields matches. :-) But
it is irrelevant, IMHO, to your initial message «commit tags are in
principle mutable and hence can not be relied on when fetching sources.
I do have a few issues with that explanation».  It is fortunate and not
robust that ’commit’ matches ’version’ via upstream ’tag’.

Because how ’commit’ and ’tag’ are defined is different.

I cannot tell it differently than: Git commit depends only on the
content, although ’tag’ not.

Version (or tag) is convenient names for humans.  It is easier to tell
version 0.23.1 than
09rdbcr8dinzijyx9h940ann91yjlbg0fangx365llhvy354n840.  And we can deduce
that 0.22.3 is older than 0.23.1, when it is impossible for commits.


If you prefer to keep the frame: «you can substitute one for the other
without a change in meaning», then, for what my opinion is worth on that
matter, my probably wrong understanding of your words is that perhaps
you are missing a point about content-addressability.


>> From the content to the hash, three keys: 1) how to serialize and 2)
>> how to hash and 3) how to represent the hash.  For #1, Git uses their
>> own serializer and Guix, inheriting from Nix, uses another (Nar);
>> although the difference is minor.  For #2, Git uses by default SHA-1 as
>> hash function, although Guix uses SHA-256.  And for #3, Git uses
>> hexadecimal format and Guix uses nix-base32.

[...]

>> To make it explicit, the checksum hash of ’git-reference’ could be
>> removed because it is somehow redundant with the commit hash.
>> Obviously, it cannot because security reason (SHA-1 is considered as
>> weak).
>
> The other way also works.  If Git used a secure hashing function such
> as SHA-256 (or SHA-512 or Keccak) and Guix supported that hash, we
> could generate a git hash from the Guix hash (assuming also we allow
> the origin serializer to be configured, which would be required either
> way).

Yes somehow.  To be on the same wavelength, we need to be precise when
we speak about hash here because hash means:

 - serializer: how to deal with all the bits making the full content
   (files, folder, tree, etc.)
 - hashing function
 - format

So yes, on principles, instead of NAR + SHA-256 + Nix-base32, the Guix
project could have chosen Git + SHA-1 + Hex, or Git + SHA-512 + Base64
or any other combinations.

(I think this choice inherited from Nix is rooted in daemon
implementations and another triplet would have been more changes when
starting Guix, I guess.)

However, knowing only the final Guix checksum hash (NAR + SHA-256 +
Nix-base32), say 09rdbcr8dinzijyx9h940ann91yjlbg0fangx365llhvy354n840,
you can easily replace by any other formats (Hex or Base64), but it is
not straightforward to compute the Git commit hash (here
c78b91edb7c17c6fbf3b294452f44e91d75e3c67) from this Guix checksum hash,
because the serializer NAR and Git have minor differences, and mainly
because one uses SHA-256 and the other SHA-1 – and it is generally not
possible to convert the hash from one hashing function to another
hashing function.


To make it short, my point is: a) a Git commit hash owns the same
properties as any checksum hash and b) a string tag is obviously not a
checksum.



> I don't know too much about Disarchive here, so please enlighten me. 
> If it used a pair of origin file name + hash, whether or not the git-
> reference uses tags would be irrelevant, no?  Do we have to take values
> from the uri field?

I am not sure to understand the questions.  Maybe the thread starting
here is worth:



Otherwise, could you explain more what you have in mind?


>> To me, robustness means make a map from intrinsic 

Guix Package Search API Server

[Sai Karthik]

Hello everyone!, I was unable to find any API for querying guix package 
info on official guix website. So, I have created a very simple REST API 
server for searching/querying package info in Javascript. It parses the 
package info from https://guix.gnu.org/packages.json file & returns the 
results.


It currently uses Deno runtime to execute. I have just started learning 
guile, So, i will try to recreate this in guile as well, Once i am 
confident :)


Project URL:  https://gitlab.com/kskarthik/guix-packages-api

I have documented it's usage too. Feel free to explore it & let me know 
your thoughts!


--
https://kskarthik.gitlab.io/


OpenPGP_0xF5B9A961BF6EAF0E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature