Re: [MoM] mmseqs2
Hi Shayan,
On Tue, Jul 16, 2019 at 01:28:27PM +0100, Shayan Doust wrote:
> > Now you are facing the not so fun since non-technical part of
> > Debian packaging. ;-)
>
> Admittedly it wasn't the best part of packaging :-)
;-)
> I have also contacted upstream regarding the PDF[1] source and have
> received the following:
>
> > We have a script in the wiki called make-pdf.sh
> >
> > git clone https://github.com/soedinglab/MMseqs2.wiki.git
> > .pandoc/make-pdf.sh
> >
> > It turns the wiki into a latex file with the following command.
> >
> > cat Home.md \
> > | sed '1,/<!--- TOC END -->/d' \
> > | cat .pandoc/meta.yaml - \
> > | pandoc \
> > --from=markdown \
> > -o userguide.pdf \
> > --template=.pandoc/eisvogel.tex \
> > --toc
> >
> > Maybe it is possible to use the markdown (Home.md) as source for the PDF?
>
> What would be the course of action with this? Should upstream push files
> of PDF sources (LaTeX) or could I just apply some patch to include these
> (LaTeX) or could we simply just use the markdown file?
There is probably no right or wrong option. Probably the files Home.md,
.pandoc/meta.yaml and .pandoc/eisvogel.tex are used to reproduce the
PDF. If you could convince upstream to include all what is needed into
the next downloadable tarball version this would be possibly the
cleanest solution. May be its possible to download Home.md somewhere
put it into debian/userguide/Home.md and add the code above as script
which might convince ftpmaster that it is no binary without source and
leave the source tarball as is. If you want to try this and see what
ftpmaster will respond its may be another lesson to learn. The easiest
(=coward) way is to simply remove the PDF once your are removing stuff
anyway and link to the online version (as I said before). I admit I
went this way frequently since I consider my spare time to valuable to
run discussion circles whether / in what form the documentation is OK
(and I'm not pround about this way to deal with this problem).
On the other hand I never got an e-mail from a user saying something
like "Thank you for doing the effort to include that nice PDF" - so may
be everything is OK even without the PDF.
Hope this is enough information to find the solution you would prefer
Andreas.
> [1]: https://mmseqs.com/latest/userguide.pdf
>
> On 15/07/2019 21:52, Andreas Tille wrote:
> > Hi Shayan,
> >
> > On Mon, Jul 15, 2019 at 09:02:45PM +0100, Shayan Doust wrote:
> >> Well, it looks like the software compiles successfully and builds into a
> >> deb package.
> >
> > Very good!
> >
> >> Now, just a slight confusion within the debian/copyright file. Below is
> >> the current file that is incomplete.
> >>
> >>> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> >>> Upstream-Name: mmseqs2
> >>> Source: https://github.com/soedinglab/MMseqs2
> >>> Files-Excluded: lib/gzstream
> >>> Comment: The system-wide library (libgzstream-dev) supersedes that of the gzstream in lib/
> >>>
> >>> Files: lib/zstd/*
> >>> Copyright: 2016-present Yann Collet, Facebook, Inc.
> >>> License: GPLv2
> >
> > zstd is also packaged. You can strip these files and Build-Depend
> > libzstd-dev. There is no need to specify a copyright paragraph for
> > removed files.
> >
> >>> Files: debian/*
> >>> Copyright: 2019 Shayan Doust <hello@shayandoust.me>
> >>> License: GPLv3
> >>
> >> The issue I have is that, for instance, the library "cacode" falls under
> >> public domain. What would be written on the license file, if anything?
> >
> > Here is an example:
> >
> > https://salsa.debian.org/med-team/ncbi-tools6/blob/master/debian/copyright
> >
> >> Some of the years and contact information are missing on the copyright
> >> lines, as I don't have an idea as to when the license was instantiated /
> >> library was written and as to what contact email the author has. Would
> >> that be an issue in this state?
> >
> > To be honest: I "invent" something a year that sounds probable. IMHO
> > this is some appropriate procedure to avoid serious software archeology.
> >
> >> Also, looking at the headers of "alp", it seems to be licensed as
> >> "United States Government Work". As this doesn't seem to reflect a
> >> distinctive license, what is the approach for this?
> >
> > I'd take the "PUBLIC DOMAIN NOTICE" as a good reason to declare it
> > as public domain. Add the paragraph as Comment.
> >
> >> Last thing, the "Files: data/*, examples/*, quinci/*, src/*, util/*,
> >> *.yml, *.md, *.txt, Dockerfile" line. I wasn't sure as to leave it as a
> >> wildcard "*" or use this means as I do not know what the licensing
> >> standpoint of something like this with multiple licenses due to
> >> libraries is.
> >
> > The "Files: *" on top catches all files. Than you list exceptions.
> > If you have no better clue for data/* etc. it can be assumed that
> > it is covered by "Files: *".
> >
> > Now you are facing the not so fun since non-technical part of
> > Debian packaging. ;-)
> >
> > Kind regards and thanks for your work on this
> >
> > Andreas.
> >
> >
>
--
http://fam-tille.de
Reply to: