[bug#52977] [PATCH 0/6] Update some minetest packages

[bug#52977] [PATCH 0/6] Update some minetest packages

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

Hi,

This patch series updates some minetest packages.
They were made with 'guix refresh -u -t minetest', using the 'git-
fetch' updater from <https://issues.guix.gnu.org/50072#24>.

Checklist:
  * [x] version, commit and sha256/base32 updated
  * [x] it builds: ./pre-inst-env guix build minetest-homedecor-modpack
minetest-unified-inventory minetest-mobs-animal minetest-mobs minetest-
basic-materials minetest-technic --rounds=2
  * [x] linter is satisfied: ./pre-inst-env guix lint minetest-
homedecor-modpack minetest-unified-inventory minetest-mobs-animal
minetest-mobs minetest-basic-materials minetest-technic
  * [x] source code diff reasonable

    minetest-technic: some small documentation and code changes
    minetest-basic-materials: new subdirectory '.github'.
    minetest-mobs: some code changes, updated translations
    minetest-mobs-animal: Some code changes (chickens are different
now?)
    minetest-unified-inventory: Lots of code changes, some
documentation changes, updated translations and images
    minetest-homedecor-modpack: Some code changes.
  * [x] Minetest doesn't crash
    ./pre-inst-env guix shell --pure minetest-homedecor-modpack
minetest-unified-inventory minetest-mobs-animal minetest-mobs minetest-
basic-materials minetest-technic minetest -- minetest
    Create world with all mods enabled.
    + [x] Inventory mode appears to work
    + [x] spawning chickens appears to work
    + [x] rotating blocks from homedecor works

A TODO for the git-fetch updater:
  * [ ] following redirects (to avoid mixed case -> lower case changes
and .git suffixes in GitHub URLs)
  * [ ] Support (let ((commit ...) (revision ...)) [...]) so more
packages can be updated automatically

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#52977] [PATCH 1/6] gnu: minetest-basic-materials: Update to 2021-12-26.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-basic-materials): Update to 2021-12-26.
---
 gnu/packages/minetest.scm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index f48addf247..1987fd1f2c 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -212,15 +212,15 @@ as swords and tools made of different materials.  It also adds copper rails.")
   (package
     (name "minetest-basic-materials")
     ;; Upstream uses dates as version numbers.
-    (version "2021-01-30")
+    (version "2021-12-26")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
-             (url "https://gitlab.com/VanessaE/basic_materials.git")
-             (commit "e72665b2ed98d7be115779a32d35e6d9ffa231bd")))
+             (url "https://github.com/mt-mods/basic_materials")
+             (commit "0893974b054a2191b5e2d5447ee4fc73f9c35f6a")))
        (sha256
-        (base32 "0v6l3lrjgshy4sccjhfhmfxc3gk0cdy73qb02i9wd2vw506v5asx"))
+        (base32 "0p4nnfsjv7284zmgr781zkyjbp049wp1jy1l7n585zzj181ns57p"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (propagated-inputs

base-commit: 9708681f1a9f221ae6cad64625ba8309b6742653
prerequisite-patch-id: 75ea02ee1380264d8513ca38ee82bc05936e88ea
prerequisite-patch-id: d3cced6fb5ff8fab4859873c2cf11a945aac6869
prerequisite-patch-id: ab72bad504c2df472d539b6a8205fed9c89416ab
prerequisite-patch-id: 858533be85606e876a49cca173c970067c49c380
-- 
2.30.2

[bug#52977] [PATCH 2/6] gnu: minetest-homedecor-modpack: Update to 2021-12-26.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-homedecor-modpack): Update to 2021-12-26.
---
 gnu/packages/minetest.scm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index 1987fd1f2c..86863d4c04 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -299,15 +299,15 @@ special items, intending to make an interesting adventure.")
     (name "minetest-homedecor-modpack")
     ;; Upstream doesn't tag releases, so use the release title from
     ;; ContentDB as version.
-    (version "2021-03-27-1")
+    (version "2021-12-26")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
-             (url "https://gitlab.com/VanessaE/homedecor_modpack")
-             (commit "9ffe2b7d691133e1a067546574fbe7364fd02f32")))
+             (url "https://github.com/mt-mods/homedecor_modpack")
+             (commit "a8fceb249d63f081855cfba1fbd6e2aa86365224")))
        (sha256
-        (base32 "1lfajqvc2adf9hqskghky4arccqzpjw4i9a01hv4qcckvivm04ag"))
+        (base32 "1lqcycgkykd86853jjr50m1qv2as2dlqf52gbds4mhiafslnp9mi"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (propagated-inputs
-- 
2.30.2

[bug#52977] [PATCH 3/6] gnu: minetest-mobs: Update to 2021-12-12.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-mobs): Update to 2021-12-12.
---
 gnu/packages/minetest.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index 86863d4c04..1b02bdef63 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -389,15 +389,15 @@ closely as the engine allows.")
     (name "minetest-mobs")
     ;; Upstream does not tag release, so use the ContentDB release
     ;; title instead.
-    (version "2021-07-22")
+    (version "2021-12-12")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
              (url "https://notabug.org/TenPlus1/mobs_redo")
-             (commit "9f46182bb4b1a390f9a140bc2b443f3cda702332")))
+             (commit "6a4a02f3fbf1038c69e72aaafa52a1e7d6106da8")))
        (sha256
-        (base32 "026kqjis4lipgskjivb3jh9ris3iz80vy2q1jvgxhxmfghjjzp4j"))
+        (base32 "0vgv7jpm9v3dwq4l9jxdd5z14yq164w8kin1d05jfv3ck4hwlwvr"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (home-page (minetest-topic 9917))
-- 
2.30.2

[bug#52977] [PATCH 4/6] gnu: minetest-mobs-animal: Update to 2021-11-14.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-mobs-animal): Update to 2021-11-14.
---
 gnu/packages/minetest.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index 1b02bdef63..ab8db4f971 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -418,15 +418,15 @@ add some mobs, a mod like e.g. @code{mobs_animal} provided by the
     (name "minetest-mobs-animal")
     ;; Upstream does not use version numbers, so use the release title
     ;; from ContentDB instead;
-    (version "2021-07-24")
+    (version "2021-11-14")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
              (url "https://notabug.org/TenPlus1/mobs_animal")
-             (commit "c2fa3e300c79c7dd80b6fe91a8b5082bb6b3d934")))
+             (commit "3e15456bce7779aa0dc09a8890f7b5180c1ac771")))
        (sha256
-        (base32 "1j719f079ia9vjxrmjrcj8s6jvaz5kgs1r4dh66z8ql6s70kx7vh"))
+        (base32 "08686mj3jh8fsziqp878jpaj5267s4n6i86dr1gnxyxbsrjraqpn"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (propagated-inputs
-- 
2.30.2

[bug#52977] [PATCH 5/6] gnu: minetest-technic: Update to 2021-09-11.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-technic): Update to 2021-09-11.
---
 gnu/packages/minetest.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index ab8db4f971..739a2523e6 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -476,15 +476,15 @@ breakers simulate a player punching a node.")
     (name "minetest-technic")
     ;; Upstream doesn't keep version numbers, so use the release
     ;; date on ContentDB instead.
-    (version "2021-04-15")
+    (version "2021-09-11")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
              (url "https://github.com/minetest-mods/technic")
-             (commit "1c219487d3f4dd03c01ff9aa1f298c7c18c7e189")))
+             (commit "140701c99efb60d81bf63c9a9087720b21c414ca")))
        (sha256
-        (base32 "1k9hdgzp7jnhsk6rgrlrv1lr5xrmh8ln4wv6r25v6f0fwbyj57sf"))
+        (base32 "1fkhcv8sg3kxfadc2jnfdw6bxxkkkcczsh4bf62rgwwmv2ky7zrx"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (propagated-inputs
-- 
2.30.2

[bug#52977] [PATCH 6/6] gnu: minetest-unified-inventory: Update to 2021-12-26.

[Maxime Devos]

* gnu/packages/minetest.scm (minetest-unified-inventory): Update to 2021-12-26.
---
 gnu/packages/minetest.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/minetest.scm b/gnu/packages/minetest.scm
index 739a2523e6..c431942473 100644
--- a/gnu/packages/minetest.scm
+++ b/gnu/packages/minetest.scm
@@ -618,15 +618,15 @@ for general colour handling.")
     (name "minetest-unified-inventory")
     ;; Upstream doesn't keep version numbers, so use the release title
     ;; on ContentDB instead.
-    (version "2021-03-25-1")
+    (version "2021-12-26")
     (source
      (origin
        (method git-fetch)
        (uri (git-reference
              (url "https://github.com/minetest-mods/unified_inventory")
-             (commit "c044f5e3b08f0c68ab028d757b2fa63d9a1b0370")))
+             (commit "d6688872c84417d2f61d6f5e607aea39d78920aa")))
        (sha256
-        (base32 "198g945gzbfl0kps46gwjw0c601l3b3wvn4c7dw8manskri1jr4g"))
+        (base32 "1rlw96s2yyxdbz0h9byayyx9nsbqdr4ric91w0k3dkjr71aj8a3b"))
        (file-name (git-file-name name version))))
     (build-system minetest-mod-build-system)
     (home-page (minetest-topic 12767))
-- 
2.30.2

bug#52977: [PATCH 0/6] Update some minetest packages

[Ludovic Courtès]

Hey Maxime,

Welcome back!  ;-)

Maxime Devos <maximedevos@telenet.be> skribis:

> This patch series updates some minetest packages.
> They were made with 'guix refresh -u -t minetest', using the 'git-
> fetch' updater from <https://issues.guix.gnu.org/50072#24>.

Oh nice.

> Checklist:
>   * [x] version, commit and sha256/base32 updated
>   * [x] it builds: ./pre-inst-env guix build minetest-homedecor-modpack
> minetest-unified-inventory minetest-mobs-animal minetest-mobs minetest-
> basic-materials minetest-technic --rounds=2
>   * [x] linter is satisfied: ./pre-inst-env guix lint minetest-
> homedecor-modpack minetest-unified-inventory minetest-mobs-animal
> minetest-mobs minetest-basic-materials minetest-technic
>   * [x] source code diff reasonable
>
>     minetest-technic: some small documentation and code changes
>     minetest-basic-materials: new subdirectory '.github'.
>     minetest-mobs: some code changes, updated translations
>     minetest-mobs-animal: Some code changes (chickens are different
> now?)
>     minetest-unified-inventory: Lots of code changes, some
> documentation changes, updated translations and images
>     minetest-homedecor-modpack: Some code changes.
>   * [x] Minetest doesn't crash
>     ./pre-inst-env guix shell --pure minetest-homedecor-modpack
> minetest-unified-inventory minetest-mobs-animal minetest-mobs minetest-
> basic-materials minetest-technic minetest -- minetest
>     Create world with all mods enabled.
>     + [x] Inventory mode appears to work
>     + [x] spawning chickens appears to work
>     + [x] rotating blocks from homedecor works

Neat.  I applied them all.

> A TODO for the git-fetch updater:
>   * [ ] following redirects (to avoid mixed case -> lower case changes
> and .git suffixes in GitHub URLs)
>   * [ ] Support (let ((commit ...) (revision ...)) [...]) so more
> packages can be updated automatically

Hmm wasn’t it the reason we introduced ‘package-definition-location’?

Thanks!

Ludo’.

[bug#52977] [PATCH 0/6] Update some minetest packages

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Ludovic Courtès schreef op wo 05-01-2022 om 23:30 [+0100]:
> > A TODO for the git-fetch updater:
> >    * [ ] following redirects (to avoid mixed case -> lower case
> > changes
> > and .git suffixes in GitHub URLs)
> >    * [ ] Support (let ((commit ...) (revision ...)) [...]) so more
> > packages can be updated automatically
> 
> Hmm wasn’t it the reason we introduced ‘package-definition-location’?

Yes, but it has been a while ago so I preferred to not overcomplicate
the patch series more.  There's also the complication that
(revision ...) might need to be incremented. Yet another complication:
minetest mods can have two separate version schemes: the
‘release titles’ on content.minetest.net, and the version they use in
forum posts or git repos.  For minetest-ethereal, they are different,
and worse, the latest version on content.minetest.net doesn't have a
corresponding version on the forum.

Hopefully there's some kind of solution, and presumably
package-definition-location will be part of that solution,
but it will probably be messy.

Or maybe the solution is to ask upstream nicely to give every release
a version number and switch to ContentDB release titles if they
disagree.

Anyway, I'd prefer to leave these complications for future patches.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#52977] [PATCH 0/6] Update some minetest packages

[Liliana Marie Prikler]

Hi,

Am Donnerstag, dem 06.01.2022 um 00:18 +0100 schrieb Maxime Devos:
> Yes, but it has been a while ago so I preferred to not overcomplicate
> the patch series more.  There's also the complication that
> (revision ...) might need to be incremented. Yet another
> complication:
> minetest mods can have two separate version schemes: the
> ‘release titles’ on content.minetest.net, and the version they use in
> forum posts or git repos.  For minetest-ethereal, they are different,
> and worse, the latest version on content.minetest.net doesn't have a
> corresponding version on the forum.
If I recall correctly, this was also a point of debate in the initial
series that added the importer.  Can we establish an ordering/heuristic
here?  E.g. "if we have git tags use those, otherwise use contentdb",
"always use contentdb" or "always use whatever was edited most
recently"?

[bug#52977] [PATCH 0/6] Update some minetest packages

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

Hi,

Liliana Marie Prikler schreef op do 06-01-2022 om 01:52 [+0100]:
> > [...]
> If I recall correctly, this was also a point of debate in the initial
> series that added the importer.  Can we establish an ordering/heuristic
> here?  E.g. "if we have git tags use those, otherwise use contentdb",
> "always use contentdb" or "always use whatever was edited most
> recently"?

Keep in mind that the minetest importer doesn't know about git tag
-- the only interaction it has with git is cloning repositories
and checking out commits by the commit id provided by ContentDB.
I'm assuming you're referring to the generic-git updater here,
or a hypothetical minetest updater that has been modified to
interact with git tags.

* Problem with using git tags: git tags sometimes disappear.
  E.g., in minetest-ethereal, there's currently a tag
  2021-04-06 and 2021-09-23, but there's no tag for 2021-07-28
  (the version currently in guix).

  This could be resolved by including the commit instead of the
  tag in the package definition, and still searching for the git tag,
  but as I understand it, there have been some objections to including
  the commit in the package definition
(https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00259.html).

  Even then, there's another problem: sometimes releases are made
  without a corresponding git tag.  E.g., on ContentDB there's a
  version 2022-01-05 but there's no 2022-01-05 tag in the git
  repository.

  That could be resolved by ‘always use contentdb for minetest
  packages’ or ‘always use whatever was edited most recently’.

* Problem with ‘whatever was edited most recently’: AFAIK git tags
  don't carry that information. Though the commit time/modification
  time in the commit it points to might be a decent approximation
  in practice.

  ContentDB has some information on when a release was released
  (release_date, see https://content.minetest.net/help/api/).

  I suppose this could work, though there's a slight problem:

  The version scheme in guix would occassionally switch between x.y.z
  and YYYY-MM-DD, which would confuse the ‘these packages have been
  upgraded’ logic.

I suppose the best option would be to always use the version from
ContentDB (*), because the exact versioning scheme used doesn't matter
much, as long as it remains consistent over time, and just using
ContentDB is convenient.

(*) Unless it isn't on ContentDB of course, though all minetest
packages currently in Guix are on ContentDB.

Additionally, if the forum versions / git tags / contentdb releases
are inconsistent (e.g. the forum and git tags are x.y.z and the
releases are YYYY-MM-DD), we could inform upstream that guix uses the
release titles because otherwise things become complicated for guix, so
if upstream doesn't want that, they need to use x.y.z in their release
titles as well

Does that seem reasonable to you? I could write a patch to that effect.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#52977] [PATCH 0/6] Update some minetest packages

[Liliana Marie Prikler]

Hi,

Am Donnerstag, dem 06.01.2022 um 09:33 +0000 schrieb Maxime Devos:
> Hi,
> 
> Liliana Marie Prikler schreef op do 06-01-2022 om 01:52 [+0100]:
> > > [...]
> > If I recall correctly, this was also a point of debate in the initial
> > series that added the importer.  Can we establish an
> > ordering/heuristic here?  E.g. "if we have git tags use those,
> > otherwise use contentdb", "always use contentdb" or "always use
> > whatever was edited most recently"?
> 
> Keep in mind that the minetest importer doesn't know about git tag
> -- the only interaction it has with git is cloning repositories
> and checking out commits by the commit id provided by ContentDB.
> I'm assuming you're referring to the generic-git updater here,
> or a hypothetical minetest updater that has been modified to
> interact with git tags.
Ahh, sure, but imho it could try to make a best effort guess.  E.g. if
git tags are named like Minetest releases and exist in equal count,
assume a mapping from one to the other.  However if I recall correctly
there was a ContentDB policy to only tag once, which makes the mapping
from ContentDB version to git commit unique.  Do I remember correctly?

> * Problem with using git tags: git tags sometimes disappear.
>   E.g., in minetest-ethereal, there's currently a tag
>   2021-04-06 and 2021-09-23, but there's no tag for 2021-07-28
>   (the version currently in guix).
> 
>   This could be resolved by including the commit instead of the
>   tag in the package definition, and still searching for the git tag,
>   but as I understand it, there have been some objections to
>   including the commit in the package definition
> (https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00259.html).
Thanks for linking my thread :)

I do cite minetest.scm as an exception there, since your comments make
very clear what you're doing and why.  However, my actual intent is
blown way out of proportion, which has led to a lot of confusion on all
sides and a rather long discussion.

To clarify it here, I am trying to avoid the following pattern:

  (package 
    (name "hello")
    (version "1.0")
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit "abcdef...")))
        [...]))
    [...])

while encouraging both

  (package 
    (name "hello")
    (version "1.0")
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit (version->git-tag version))))
        [...]))
    [...])

and

  (package 
    (name "hello")
    (version (git-version "1.0" revision commit))
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit commit)))
        [...]))
    [...])

In the latter, revision and commit are let-bound as per Guix'
standards.  Now if you say "minetest mod packages are generally
unreliable, git-version everywhere", that is completely fine by me.

>   Even then, there's another problem: sometimes releases are made
>   without a corresponding git tag.  E.g., on ContentDB there's a
>   version 2022-01-05 but there's no 2022-01-05 tag in the git
>   repository.
> 
>   That could be resolved by ‘always use contentdb for minetest
>   packages’ or ‘always use whatever was edited most recently’.
> 
> * Problem with ‘whatever was edited most recently’: AFAIK git tags
>   don't carry that information. Though the commit time/modification
>   time in the commit it points to might be a decent approximation
>   in practice.
> 
>   ContentDB has some information on when a release was released
>   (release_date, see https://content.minetest.net/help/api/).
> 
>   I suppose this could work, though there's a slight problem:
> 
>   The version scheme in guix would occassionally switch between x.y.z
>   and YYYY-MM-DD, which would confuse the ‘these packages have been
>   upgraded’ logic.
Does ContentDB always use CalVer or are the repo owners in control of
the tags?  If there's a SemVer/CalVer conflict, I would say doing 
(latest-semver)-(calver)-commit would probably be acceptable.  At least
I hope none of these mods release twice daily.

> I suppose the best option would be to always use the version from
> ContentDB (*), because the exact versioning scheme used doesn't
> matter much, as long as it remains consistent over time, and just
> using ContentDB is convenient.
> 
> (*) Unless it isn't on ContentDB of course, though all minetest
> packages currently in Guix are on ContentDB.
If a package was used outside of ContentDB, that's not ContentDB's
requirement, is it?  Now perhaps there is an issue if the contentdb
updater relies on the minetest-mod-build-system being used to determine
that its suitable, rather than something else.

> Additionally, if the forum versions / git tags / contentdb releases
> are inconsistent (e.g. the forum and git tags are x.y.z and the
> releases are YYYY-MM-DD), we could inform upstream that guix uses the
> release titles because otherwise things become complicated for guix,
> so if upstream doesn't want that, they need to use x.y.z in their
> release titles as well
> 
> Does that seem reasonable to you? I could write a patch to that
> effect.
Poking upstream maintainers sounds fun, but before making a hard
decisions, perhaps we should reach out to them and ask what they
consider the most reliable.  If it's a wild mess, we could also use
package-properties with an assumed default of "release title = git tag
= forum post", e.g. (upstream-versioning . forum-post), (upstream-
versioning . contentdb) and (upstream-versioning . git-version) to
indicate who's right in case of a mismatch.

WDYT?

[bug#52977] [PATCH 0/6] Update some minetest packages

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op wo 05-01-2022 om 23:30 [+0100]:
>> > A TODO for the git-fetch updater:
>> >    * [ ] following redirects (to avoid mixed case -> lower case
>> > changes
>> > and .git suffixes in GitHub URLs)
>> >    * [ ] Support (let ((commit ...) (revision ...)) [...]) so more
>> > packages can be updated automatically
>> 
>> Hmm wasn’t it the reason we introduced ‘package-definition-location’?
>
> Yes, but it has been a while ago so I preferred to not overcomplicate
> the patch series more.

OK, I thought we more or less had a solution in place back then and just
missed ‘package-definition-location’.

I think we could do something along these lines:

  (edit-expression
    (location->source-properties (package-definition-location p))
    (lambda (str)
      ;; substitute commit ID in STR
      …))

But yes, let’s keep that for a subsequent patch.

Thanks,
Ludo’.

[bug#52977] [PATCH 0/6] Update some minetest packages

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Ludovic Courtès schreef op di 11-01-2022 om 13:53 [+0100]:
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Ludovic Courtès schreef op wo 05-01-2022 om 23:30 [+0100]:
> > > > A TODO for the git-fetch updater:
> > > >    * [ ] following redirects (to avoid mixed case -> lower case
> > > > changes
> > > > and .git suffixes in GitHub URLs)
> > > >    * [ ] Support (let ((commit ...) (revision ...)) [...]) so more
> > > > packages can be updated automatically
> > > 
> > > Hmm wasn’t it the reason we introduced ‘package-definition-location’?
> > 
> > Yes, but it has been a while ago so I preferred to not overcomplicate
> > the patch series more.
> 
> OK, I thought we more or less had a solution in place back then and just
> missed ‘package-definition-location’.
> 
> I think we could do something along these lines:
> 
>   (edit-expression
>     (location->source-properties (package-definition-location p))
>     (lambda (str)
>       ;; substitute commit ID in STR
>       …))
>
> But yes, let’s keep that for a subsequent patch.


See <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53144>,
in particular the new 'latest-git' updater.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#52977] [PATCH 0/6] Update some minetest packages

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Ludovic Courtès schreef op wo 05-01-2022 om 23:30 [+0100]:
> Hey Maxime,
> 
> Welcome back!  ;-)
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > This patch series updates some minetest packages.
> > They were made with 'guix refresh -u -t minetest', using the 'git-
> > fetch' updater from <https://issues.guix.gnu.org/50072#24>
> > 

btw I left a sneek message on #guix with information on where v5
can be found, apparently it didn't make it onto issues.guix.gnu.org
somehow.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]