Hello, 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 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? We are inching closer to an upload I feel. 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. I will push the copyright file too later today. 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. >>> >>> >> > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature