unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Vagrant Cascadian <vagrant@debian.org>, 63435@debbugs.gnu.org
Cc: iyzsong@envs.net
Subject: [bug#63435] Add vcmi 1.2.1 to games.scm
Date: Fri, 12 May 2023 22:53:28 +0200	[thread overview]
Message-ID: <8e04176d6691bdc0996fb473b56ead31be954123.camel@gmail.com> (raw)
In-Reply-To: <87wn1em5ti.fsf@wireframe>

Am Donnerstag, dem 11.05.2023 um 23:17 -0700 schrieb Vagrant Cascadian:
> On 2023-05-12, Liliana Marie Prikler wrote:
> > Am Donnerstag, dem 11.05.2023 um 16:07 -0700 schrieb Vagrant
> > Cascadian:
> > 
> > > +(define-public vcmi
> > > +  (package
> > > +    (name "vcmi")
> > > +    (version "1.2.1")
> > > +    (source (origin
> > > +              (method git-fetch)
> > > +              (uri (git-reference
> > > +                    (url "https://github.com/vcmi/vcmi")
> > > +                    (commit version)
> > > +                    (recursive? #t)))
> > Can we do without the recursive checkout?
> 
> There is one component still used with the recursive
> checkout. ... AI/Fuzzy* I think? I do not know if it could be built
> independently, but I have not seriously looked into it.
fuzzylite can be taken from the system which is the preferred approach.

> 
> If tests were enabled, the googletest stuff might be needed; it was a
> bit unclear to me if the googletest packaged in guix could
> work. Regardless, tests are disabled upstream... so if there is a way
> to only download one and not the other, I guess that would save some
> bandwith.
> 
> I *think* those are the only two things pulled in.
Not that it matters if we aren't building tests, but googletest can and
should be unbundled.  There's a fair number of packages already setting
a precedent.

> > > +              (file-name (git-file-name name version))
> > > +              (sha256
> > > +               (base32
> > > +               
> > > "1nx3i078cxkak2ci514pf4pgi5269mp08njynsg35pin4yp3fn0p"))
> > > +              (patches (search-patches "vcmi-disable-privacy-
> > > breach.patch"))))
> > IIRC the reproducible builds patch is still missing, right?
> 
> The Debian package implements building man pages and documentation
> outside of the upstream build system...
> 
> It did not seem worth patching something that was not used to build
> anything... the reproducible builds patch(es) only apply to
> documentation which is not part of the upstream build process, so I
> left it out of this iteration.
> 
> That said...
> 
> Building vcmimanual.tex appears to be a one-liner, pulling in some
> tex related dependencies:
> 
>  
> https://salsa.debian.org/games-team/vcmi/-/blob/master/debian/rules#L56
> 
> And generating manpages used help2man and some templates debian
> ships:
> 
>  
> https://salsa.debian.org/games-team/vcmi/-/blob/master/debian/rules#L46-48
> 
> Not sure if the manpages are worth the effort, or if the manual is
> worth the larger dependency tree...
Fair enough, if it can be left without, let's do without (unless you
really want to build the manpage).  Alternatively, you can pull the
inputs in, but phrase the (build-documentation ...) phase in a way that
those inputs can be dropped if someone values their disk space.

> > > +    (native-inputs (list boost
> > Guix style is, like, a suggestion that can be wrong.  You are
> > allowed
> > to fight it when the result of doing so is demonstrably better.
> 
> I get that ... but I also like just being able to run guix style and
> not having to make those judgement calls. Because other things guix
> style may change that are a good idea and it is really difficult to
> pick and choose which things to revert and which to keep over time...
> 
> There are some things I think guix style does wrong(in particular, I
> always prefer one input per line to make diffs easier to read), but I
> do not hold strong opinions on guile coding style and just prefer to
> concede to guix style and bear with the results.
> 
> I am also not strongly opinionated (it goes both ways, I guess!)...
> so for clarity, are you saying you would prefer:
> 
>   (native-inputs
>     (list
>       boost
>       ...
> or:
> 
>   (native-inputs
>     (list boost
>           ...
> 
> or something else?
The latter.  If it ever comes to needing (list on its own line you
better have a good explanation for that or fix your comments so that
they don't go overboard.


Cheers




  reply	other threads:[~2023-05-12 20:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11  5:43 [bug#63435] Add vcmi 1.2.1 to games.scm Vagrant Cascadian
2023-05-11 17:17 ` Liliana Marie Prikler
2023-05-11 21:48   ` Vagrant Cascadian
2023-05-11 23:07     ` Vagrant Cascadian
2023-05-12  1:47       ` Liliana Marie Prikler
2023-05-12  6:17         ` Vagrant Cascadian
2023-05-12 20:53           ` Liliana Marie Prikler [this message]
2023-05-13  1:33             ` Vagrant Cascadian
2023-05-13  1:35               ` Vagrant Cascadian
2023-05-13  6:16                 ` Liliana Marie Prikler
2023-05-14 19:52                   ` Vagrant Cascadian
2023-05-15 18:31                     ` Liliana Marie Prikler
2023-05-15 19:07                       ` Vagrant Cascadian
2023-07-03  2:50                       ` Vagrant Cascadian
2023-07-09  5:36                         ` bug#63435: " Liliana Marie Prikler
2023-05-13  6:12               ` [bug#63435] " Liliana Marie Prikler
2023-05-14 19:50                 ` Vagrant Cascadian

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=8e04176d6691bdc0996fb473b56ead31be954123.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=63435@debbugs.gnu.org \
    --cc=iyzsong@envs.net \
    --cc=vagrant@debian.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).