unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: help-guix@gnu.org, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>,
	help-guix <help-guix@gnu.org>
Subject: Re: Package definition hash calculation
Date: Sat, 09 Jul 2022 13:44:24 +0200	[thread overview]
Message-ID: <764ABCE7-B46B-49A7-8C6F-0892BAA8C48B@lepiller.eu> (raw)
In-Reply-To: <54cbdaf2-f1ef-7490-7c2a-05f63edf7d56@posteo.de>

When you use guix download, or url-fetch, the hash is computed over the entire file, whether it's a tarball that contains other files or whatever else doesn't matter. You can't exclude files from inside the tarball. It's just the checksum of the file.

What you describes sounds like you're downloading a tarball that's generated from your master instead of a particular commit. So everytime you push a change to guix.scm, it's a new commit and a different tar.gz (different checksum). So you're always chasing after the correct checksum, which won't work.

So you can have a guix.scm in your repo, but it can't refer to a generated tarball from master. Instead, you could make it refer to master and not have to provide a hash like so:

(source (git-checkout (url "https://…")))

No more chasing afcer master :)

On July 9, 2022 1:09:27 PM GMT+02:00, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
>Hello Guix users!
>
>I feel a bit stupid to ask about this topic again, however, to me it is not really clear, what I need to do, when calculating the hash of a package, so that I can write it in the package definition.
>
>I have a project (https://notabug.org/ZelphirKaltstahl/guile-fslib), which I have packaged before, but that was already a year ago or so, and I forgot the precise process involving the hashes.
>
>I have the following questions:
>
>(1) When I edit the `guix.scm` file and change the hash in there, make a tarball release on notabug, and then run `guix download <tarball of release>`, I get a new hash. If I edit the guix.scm file again and repeat the process, I get a new hash … endless loop of getting a new hash and changing the file accordingly. My guess is, that this is, because `guix download` does not exclude the `guix.scm` file. I would have to manually make a `tar.gz` and upload that as a release to notabug and then reference that. – Is this correct?
>
>(2) I guess I should be using `guix hash --exclude-vcs --serializer=nar --format=??? .` instead, since my package definition makes use of the `git-fetch` method of fetching the package. I had totally forgotten about this, until I searched in old e-mails, reading old replies to previous questions I asked on this mailing list. I think it could be made clearer in the docs, which command to use in which case. However, now I am not sure which `--format=` I should use. I would guess `base32`, because in my package definition it says `(sha256 (base32 "..."))`. Is this correct? Or is the default fine?
>
>(3) What is the recommended way to update a package's source code and then "in one go" calculate the hash, update the `guix.scm` and make a proper release, which only has the appropriate files in the tarball?
>
>(4) Should a release tarball contain a `guix.scm` package definition? (My guess is not, since the hash in that file changes and that would change the tarball. Maybe I am overlooking things/magic though.)
>
>I am feeling like I am stuck in what should be a simple process, because I still have some points that are unclear to me. I try updating my guide to packaging a pure Guile package when I learn new things, so that I can read up next time I want to make a release or a new package, but a few things are still missing or unclear.
>
>Thank you for all your help!
>
>Best regards,
>Zelphir
>
>-- 
>repositories: https://notabug.org/ZelphirKaltstahl
>
>

  reply	other threads:[~2022-07-09 12:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-09 11:09 Package definition hash calculation Zelphir Kaltstahl
2022-07-09 11:44 ` Julien Lepiller [this message]
2022-07-11  9:19   ` Zelphir Kaltstahl
2022-07-11 10:18     ` Julien Lepiller
2022-07-12 11:14       ` Zelphir Kaltstahl

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=764ABCE7-B46B-49A7-8C6F-0892BAA8C48B@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=help-guix@gnu.org \
    --cc=zelphirkaltstahl@posteo.de \
    /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.
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).