Re: [MoM] mmseqs2
Hi Shayan
On Wed, Jul 17, 2019 at 01:33:13PM +0100, Shayan Doust wrote:
> Firstly Andreas, I saw your commit earlier this morning - thanks. I may
> have forgotten to unstash something and push, oops :-)
:-)
> As you can see, autopkgtest works. I'm using some generated binaries
> that CMake generates. Some binaries do not work, as they either fail
> with some segmentation / SEGSEGV fault or some of the paths are
> hard-coded and not dynamic. Probably the best course of action would be
> to inform upstream or just patch up the src files, though I think the
> pre-existing tests cover a wide spectrum of the software anyways.
I have not checked the source but its not unusual that you need to
change some pathes inside the code to pass the test suite. However,
segmentation / SEGSEGV fault does not sound nice - at least some
error handling should be done in the code.
> I have contacted upstream again regarding the documentation. If they
> make the documentation src available in the tarball in due course of
> time before the upload, I'll certainly include it. For now, I may go
> down the gamble route and see if ftp masters will accept it as your
> suggestion below. It's good to know for future cases like this too.
> Would you say utilising debian/missing-sources to be possible in this case?
That would be an option.
> We are inching closer to an upload I feel.
+1
> Hopefully the current
> mmseqs2.install is satisfactory in your opinion. I could not move the
> test binaries to /usr/share/mmseqs2 as I think they are certainly not
> needed for the program to function, and lintian will of course complain
> about some arch-dependent-file-in-usr-share, so hopefully this is an OK
> judgement.
If these binaries might have any use the proper dir would be
/usr/lib/mmseqs2
You can either do the move by patching CMakeLists.txt or you can do
override_dh_install:
dh_install
mv ... # move around stuff
> I will push the copyright file too later today.
Good.
Thanks for your work on this
Andreas.
> Best regards,
> Shayan Doust
>
> On 16/07/2019 14:42, Andreas Tille wrote:
> > 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: