[bug#55703] [PATCH] Update minetest

[Vivien Kraus]

Hello,

Le dimanche 29 mai 2022 à 18:39 +0200, Liliana Marie Prikler a écrit :
> 
> > +    (source
> > +     (origin
> > +       (inherit (package-source irrlicht))
> > +       (method git-fetch)
> > +       (uri (git-reference
> > +             (url "https://github.com/minetest/irrlicht";)
> > +             (commit version)))
> > +       (sha256
> > +        (base32
> > +         "1jxk1x0f60n8lrz8a6x62aj2pqg0qnbajsld3lqncvwsfbi0xjx1"))
> > +       (patches '())
> > +       (snippet '(begin #t))))
> Instead of inheriting and blanking patches and snippet, you could
> simply not inherit.
That is simpler, yes.

> 
> > +    (arguments
> > +     `(#:tests? #f))
> As with Irrlicht itself, you should write out "; no check target"
Yes.

> 
> > > > * gnu/packages/minetest.scm (minetest-basic-materials): Update to
> > > > 2022-03-28 (commet 9d55f991…).
> > > > [snippet]: Make sound_api_core a dependency, not a submodule.
> > > Again doing two things at once.  I think it'd be wiser to first do
> > > the updates, then add minetest-sound-core, then add the snippets. 
> > > WDYT?
> > 
> > minetest-sound-core is introduced as a submodule for the
> > basic_materials update.  So the code for it is not present at all. 
> > If
> > I first update basic_materials, then the tests will fail because it
> > can’t find sound_core. Do you mean that I should first try to respect
> > the will of the author and add it as a submodule (I don’t know how to
> > do that) and then take it out as a separate package?
> Hmm, perhaps I was confused by the commit message.  If changes to the
> package are necessary for the bump, it makes sense to do them in the
> same commit as you did, but the wording would imply that it was
> previously a submodule, which perhaps through strange git magic is no
> longer available in the source (because it has been externalized).
I rewrote the comment and linked to the basic_material issue mentioned
by Maxime elsewhere in the thread: 

https://github.com/mt-mods/basic_materials/issues/4
> 
> > > ² As pointed out by Maxime elsewhere in the mailing list,
> > > Minetest packages usually have flaky tags in their forges, so
> > > someone needs to look closer at whether this is going to break in
> > > the future.
> > 
> > Yes. Mesecons was using version numbers and then the latest tag is
> > a
> > date. Given that it’s April 1st, maybe there’s something funny
> > occuring here, but the changes around that day looked reasonable to
> > my untrained eye. However, one thing I didn’t notice at first was
> > the
> > drop of the + in the license. Sorry.
> I'm not sure whether that's the right version to bump to, sorry. 
> According to ContentDB the latest release is
> 27c3c515b49af91c1dbc427f31a820722854eb24, but that's untagged in git;
> I
> suggest either making a git-version and adding an appropriate comment
> or contacting upstream for clarification.
Obviously yes that’s the commit to use.

So now the v3 looks like this. What do you think?

Vivien

v3-0001-gnu-minetest-Add-irrlicht-for-minetest.patch
Description: Text Data

v3-0002-gnu-minetest-Update-to-5.5.1.patch
Description: Text Data

v3-0003-gnu-minetest-Add-minetest-sound-api-core.patch
Description: Text Data

v3-0004-gnu-minetest-basic-materials-Update-to-2022-03-28.patch
Description: Text Data

v3-0005-gnu-minetest-homedecor-modpack-Update-to-2022-05-.patch
Description: Text Data

v3-0006-gnu-minetest-mesecons-Update-to-2022-04-01.patch
Description: Text Data

v3-0007-gnu-minetest-mineclone-Update-to-0.75.0.patch
Description: Text Data

v3-0008-gnu-minetest-technic-Update-to-2022-02-06.patch
Description: Text Data

v3-0009-gnu-minetest-advtrains-Update-to-2.4.1.patch
Description: Text Data