diff mbox series

[bug#54232,1/2] gnu: python-daemon: Use the git repo as source instead of pypi.

Message ID 20220303141929.6981-1-attila@lendvai.name
State Accepted
Headers show
Series [bug#54232,1/2] gnu: python-daemon: Use the git repo as source instead of pypi. | expand

Commit Message

Attila Lendvai March 3, 2022, 2:19 p.m. UTC
---

err... either i got confused, or someone (or was that me?) injected a
substitute* to get rid of the problematic call, so the tests work.

either way, this patch now reduces to the following: converting
the source to come from the git repo instead of pypi.

if that is not desirable, then feel free to close it.

and sorry for the noise!

 gnu/packages/python-xyz.scm | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

Comments

M March 3, 2022, 2:30 p.m. UTC | #1
Attila Lendvai schreef op do 03-03-2022 om 15:19 [+0100]:
>      (source
>       (origin
> -       (method url-fetch)
> -       (uri (pypi-uri "python-daemon" version))
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://pagure.io/python-daemon.git")
> +             (commit (string-append "release/" version))))
> +       (file-name (git-file-name name version))
>         (sha256
> -        (base32
> -         "1bxfn2bq56sd4w0nm9mqy8y0905m7fc8vmhnjxlrf49vcbqr7adx"))))
> +        (base32 "1ysynb1m9vsww2nmhcypkk08xwifc3gw5yq10h1a1i11yn27w4y6"))))

I'm not opposed to building things from version control more often
(it makes things like "--with-commit" work more often).  However,
this seems more a change to discuss at guix-devel@.

Also, how does this address the test failure?  The pypi and git are at
the same version. Did upstream adjust the 'release/2.3.0' tag in place
or something?

Greetings,
Maxime.
Attila Lendvai March 3, 2022, 2:42 p.m. UTC | #2
> Also, how does this address the test failure? The pypi and git are at
> the same version. Did upstream adjust the 'release/2.3.0' tag in place
> or something?

sorry for not being clear enough! sending this patch was essentially a mistake: the tests do work fine.

probably i have added the disabling of the test prior to the SUBSTITUTE* (that
is basically a backport of the fix commit in upstream), and when i rebased some
pending changes, then i mistakenly included the now irrelevant disabling.

feel free to apply or reject this as you see fit. it's not important for me to
build from git, even though i also find it better. probably the software
heritage archives also work better with git.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“A man goes to a foreign country and kills somebody who's not aggressing against him; in a Hawaiian shirt he's a criminal, in a green costume he's a hero who gets a parade and a pension. So that, as a culture, we remain in a state of moral insanity. To point out these contradictions to people in society is to be labeled insane. This is how insane society remains, that anybody who points out logical opposites in the most essential human topic of ethics, is considered to be insane.”
	— Stefan Molyneux (1966–)
M March 3, 2022, 2:46 p.m. UTC | #3
Attila Lendvai schreef op do 03-03-2022 om 14:42 [+0000]:
> > Also, how does this address the test failure? The pypi and git are
> > at
> > the same version. Did upstream adjust the 'release/2.3.0' tag in
> > place
> > or something?
> 
> sorry for not being clear enough! sending this patch was essentially
> a mistake: the tests do work fine.
> 
> probably i have added the disabling of the test prior to the
> SUBSTITUTE* (that
> is basically a backport of the fix commit in upstream), and when i
> rebased some
> pending changes, then i mistakenly included the now irrelevant
> disabling.
> 
> feel free to apply or reject this as you see fit. it's not important
> for me to build from git, even though i also find it better. probably
> the software heritage archives also work better with git.

They do support tarballs to some degree, and disarchive to some degree
compensates for mismatches.  I don't know how well this works in
practice.

Anyway, I'm closing for now, but if it is discussed on guix-devel@ with
a positive conclusion, feel free to reopen.

Greetings,
Maxime.
Simon Tournier March 3, 2022, 11:48 p.m. UTC | #4
Hi Maxime and Attila,

On Thu, 03 Mar 2022 at 15:46, Maxime Devos <maximedevos@telenet.be> wrote:

>> feel free to apply or reject this as you see fit. it's not important
>> for me to build from git, even though i also find it better. probably
>> the software heritage archives also work better with git.
>
> They do support tarballs to some degree, and disarchive to some degree
> compensates for mismatches.  I don't know how well this works in
> practice.

FYI, a quick picture on how it works. :-)

For source using ’git-fetch’, archival on Software Heritage (SWH) is
done using :

    guix lint -c archival <pkg>

and if later the URL for the repository is unavailable, then Guix
automatically sends a cooking requests to SWH and fetch from it there.
Basically the machinery works.  The failure are issues on SWH side or
not enough information on Guix side (see lengthy thread tag vs commit
hash for details of one typical issue :-))

For source using ’url-fetch’, archival on SWH is done via:

    http://guix.gnu.org/sources.json

The file is periodically builds on Guix side and periodically ingested
by SWH.  It lists all the “tarball“ URL locations for one Guix revision.

To keep it short, a tarball contains content (say source code itself)
and meta (say compression level or others).  SWH only preserves content
and drops meta.  Therefore, later it is not possible to rebuild from
their SWH data the exact same tarball and thus checksum mismatches.

The workaround is Disarchive.  It stores this ’meta’ in the database:

    http://disarchive.guix.gnu.org/

and thus using both (content from SWH and meta from Disarchive), the
exact same tarball is rebuilt.  This Disarchive database is periodically
updated by CI Cuirass.

If later the source URL is down, then Guix automatically sends a request
to SWH and Disarchive database ending by reassembling the both elements
of the required tarball.

Basically, the machinery works too.  Not all compression format are
supported.  Among other many other details.

(Note we name Disarchive both the tools to disassemble / reassemble and
also the database; where it can be misleading, sometimes. :-))


The plan is to have a better story for all.

Hope that helps and spread the word. ;-)

Cheers,
simon

PS: I have not talked about ’hg-fetch’ or ’svn-fetch’. ;-)
diff mbox series

Patch

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index c05502388e..c49cb97122 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -4163,11 +4163,13 @@  (define-public python-daemon
     (version "2.3.0")
     (source
      (origin
-       (method url-fetch)
-       (uri (pypi-uri "python-daemon" version))
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://pagure.io/python-daemon.git")
+             (commit (string-append "release/" version))))
+       (file-name (git-file-name name version))
        (sha256
-        (base32
-         "1bxfn2bq56sd4w0nm9mqy8y0905m7fc8vmhnjxlrf49vcbqr7adx"))))
+        (base32 "1ysynb1m9vsww2nmhcypkk08xwifc3gw5yq10h1a1i11yn27w4y6"))))
     (build-system python-build-system)
     (arguments
      `(#:phases