Re: [MoM] mmseqs2
On Thu, Jul 18, 2019 at 04:53:54PM +0100, Shayan Doust wrote:
> > 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.
>
> Yep. I may modify the code and ensure there is dynamic pathing. Error
> handling apart from the current exit signals should not really be
> needed: a good program should not have any segmentation faults. Maybe
> the fault is caused with the pathing issue, I'm not sure as I haven't
> analysed source yet but I certainly will.
Sounds good so far for your plan to fix the pathes. Otherwise I think
a good program should not SIGSEGV if some file is not found but do proper
error handling and exit with "File not found" instead.
> >> 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.
>
> Thanks. I am still waiting for upstream to respond back, however I have
> placed the necessary files within debian/missing-sources. What should I
> do with the images folder. The images are used within the PDF itself,
> however I cannot simply put this folder in debian/missing-sources
> because dpkg will then complain that there are modified or unnecessary
> binaries (I cannot remember the exact error message). Should I just
> simply exclude this?
No, simply declare these in
debian/source/include-binaries
> I have also done some more cleanups. Instead of patching CMake, I've
> just cp some data files that CMake never moved, that a couple of test
> binaries need. Admittingly, I am fairly weak when it comes to writing
> the copyright file, so I'm still not sure if there are things missing or
> if something needs to be described in some other way. How far from
> completion would you say I am at this stage?
I'm about to travel to DebConf today and will be offline for 24h (or
longer). May be somebody else can check or I'll do that later. You
will finally her from ftpmaster if something is missing. ;-)
> > Thanks for your work on this
> Thank you for your time to review.
I'd like to repeat that I'm super happy that we have a new active
member in the Debian Med team.
Kind regards
Andreas.
> Best Regards,
> Shayan Doust
>
> On 17/07/2019 15:42, Andreas Tille wrote:
> > 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: