Hello Andreas, > Architecture: any-amd64 any-ppc64 any-ia64 arm64 mips64el alpha > sparc64 Ah, that's great. Thanks. > I'm not sure whether I understand the question. Any copyright > information belongs to debian/copyright in the given format. It's difficult to phrase. I believe he was referring as to why copyright entries for libraries such as OpenMP template library or blast2lca[1] were not added by me. These libraries are apparently used, and according to him, they have been directly implemented and spread across the codebase and not simply put I think an easier way to phrase it is that some of these [1] are not in lib/ and have probably been directly mixed in with the source code. In either case, I probably should add them to copyright file. I think I need to revise on my copyright depiction skills :) Best Regards, Shayan Doust [1]: https://github.com/soedinglab/mmseqs2/wiki#external-libraries-used-in-mmseqs2 On 23/07/2019 03:47, Andreas Tille wrote: > Hi Shayan, > > On Mon, Jul 22, 2019 at 10:56:29PM +0100, Shayan Doust wrote: >> I have received an email from another MMseqs2 developer with some >> information and proposed changes. >> >> Firstly, it came to my attention that MMseqs2 was developed with 64-bit >> systems in mind and may break when using x86, as within the code, there >> is the assumption that sizeof(size_t) == 8. Would changing arch=any to >> strictly match that of amd64 or x86_64 be an issue? > > I'd recommend something like > > Architecture: any-amd64 any-ppc64 any-ia64 arm64 mips64el alpha sparc64 > > (if there is no simple way to enable 32bit). > >> I was also informed of a regression / test suite[1] which seems to be >> nice. Maybe I will end up completely replacing the current test unit to >> use this instead of my patched one. > > I'm fine with any enhancement you intend to implement. > >> There were a few licensing issues which I will rectify. MMseqs2 uses >> source files that are adapted from these projects[2] and are spread all >> around the codebase. Should I include these into the copyright file or >> not, as I am not sure as to how much these have been adapted or look >> different. > > I'm not sure whether I understand the question. Any copyright information > belongs to debian/copyright in the given format. > > Thanks again for your repeated work it > > Andreas. > > >> [1]: https://bitbucket.org/martin_steinegger/mmseqs-benchmark/src/master/ >> [2]: >> https://github.com/soedinglab/mmseqs2/wiki#external-libraries-used-in-mmseqs2 >> >> On 22/07/2019 13:02, Shayan Doust wrote: >>> Hello again, >>> >>> I Should have combined this with the previous email. >>> >>>> In any case we can just backport what is available in Debian testing. >>>> If a package has landed there (we will see when ftpmaster will accept >>>> the current package and what upstream will be released at that time) >>>> we can ask whether this is a sensible target for backporting. >>> >>> Sounds good. I guess the best way to tell is to keep an eye on this [1]. >>> >>>> I admit I'm very positively impressed by your energy. You are the >>>> most productive MoM student and you have obviously a lot of fun to >>>> challenge the learning curve with an extreme speed. I like this a >>>> lot! >>> >>> Thanks :) ! I hate giving a bad impression and not getting anything >>> done, so this is great to hear. Once I'm into something, I don't really >>> lose interest nor sustainability. >>> >>>> I'm *very* lazy with life chat techniques. I think most of the time >>>> these drain more time than they give you. I'm fine with appointments >>>> to meet in IRC and I will do my best. When beeing at DebConf I even >>>> have a IRC window open. But I prefer mail for serious information >>>> since its archived and you can seek in it. But if others are fine >>>> with IRC this channel is not restricted to automatic messages at all. >>> >>> Ahh alright. Sometimes a realtime communication can be good for any >>> virtual meetings where lots of communication are to be thrown or >>> anything that doesn't really need a long term archive. >>> >>> Also Andrius: >>> >>>> Great! The upstream should be very grafetul to you for hunting these >>>> problems down. It would be best if they could incorporate your >>>> patches. >>> >>> :). I assume their tests were quickly made and rough - not intended for >>> any test suites. I don't remember if they even use any CI. I doubt it, >>> but it's good that it's all pretty much fixed. >>> >>>> This should not be a problem. You may look around to find someone in >>>> your region via db.debian.org. Other option would be to check the >>>> database each time you have a conference or vacation somewhere. This >>>> is how I got my signatures :) >>> >>> Ahh that's great, thanks! I'll keep an eye on anything that is >>> relatively close once I move out in under a month. >>> >>> Best regards, >>> Shayan Doust >>> >>> [1]: https://ftp-master.debian.org/new.html >>> >>> On 22/07/2019 10:27, Andreas Tille wrote: >>>> Hi again, >>>> >>>> On Mon, Jul 22, 2019 at 01:50:44AM +0100, Shayan Doust wrote: >>>>> Just more of a closing email. >>>>> >>>>>> I backport on request only. >>>>> >>>>> Ahh. That's great to know. I think the upstream developer(s) *might* be >>>>> interested, but it's too early to even tell what release they'd want. >>>> >>>> In any case we can just backport what is available in Debian testing. >>>> If a package has landed there (we will see when ftpmaster will accept >>>> the current package and what upstream will be released at that time) we >>>> can ask whether this is a sensible target for backporting. >>>> >>>>> I've rectified the test binaries by patching. I have excluded taxonomy >>>>> for the sole reason that taxonomy requires the software to download >>>>> roughly 20 GB of compressed data from the internet, and as a result use >>>>> a lot more space when it self decompresses as well as processing power. >>>> >>>> Everything can be included into the next upload once the package in new >>>> was accepted. Its hard to predict when this will be. We have seen >>>> periods of days, weeks and monthes. Waiting for your work to become >>>> effective is some of the patience draining things in Debian sometimes. >>>> >>>>> Seems like with this package completion, I'm on a hunt to find something >>>>> to do now. >>>> >>>> I admit I'm very positively impressed by your energy. You are the most >>>> productive MoM student and you have obviously a lot of fun to challenge >>>> the learning curve with an extreme speed. I like this a lot! >>>> >>>>> Additionally, I have been lurking in the debian med irc with znc and >>>>> haven't seen any activity. Does this irc channel get used, or is it more >>>>> of an informational channel of monitoring med-team commits? >>>> >>>> I'm *very* lazy with life chat techniques. I think most of the time >>>> these drain more time than they give you. I'm fine with appointments >>>> to meet in IRC and I will do my best. When beeing at DebConf I even >>>> have a IRC window open. But I prefer mail for serious information >>>> since its archived and you can seek in it. But if others are fine >>>> with IRC this channel is not restricted to automatic messages at all. >>>> >>>> Thanks again >>>> >>>> Andreas. >>>> >>>>> Best regards, >>>>> Shayan Doust >>>>> >>>>> On 21/07/2019 00:00, Andreas Tille wrote: >>>>>> Hi Shayan, >>>>>> >>>>>> On Sat, Jul 20, 2019 at 11:14:24PM +0100, Shayan Doust wrote: >>>>>>> Thank you for the upload! :-) >>>>>> >>>>>> Ahhhhh! Great! >>>>>> >>>>>>> Quick question. Would it be worth the effort backporting, or is that >>>>>>> usually based on factors like demand and interest from users, >>>>>>> developers, etc? >>>>>> >>>>>> I backport on request only. >>>>>> >>>>>>> Additionally, I've managed to fix one of the few tests which I was >>>>>>> initially unable to include within the unit test. It takes a bit of >>>>>>> effort to run valgrind and to try figure out where SIGSEGV was tripped. >>>>>>> My aim is to have maximum functionality testing coverage with this very >>>>>>> soon. >>>>>> >>>>>> Very cool! >>>>>> >>>>>>> This package was hugely beneficial in learning. I've been in touch with >>>>>>> the upstream developer and have learned about their periodic releases, >>>>>>> etc... which means that I can focus on keeping upstream happy by >>>>>>> incorporating future releases within the package. >>>>>>> >>>>>>>> I am amazed by your speed and quality - two packages in twenty days! I >>>>>>>> hope to see you becoming independent Debian developer soon. >>>>>>> >>>>>>> Sadly, I'm right before entering university so I'm still young and >>>>>>> travelling for key signing / etc is not a viable option yet. I won't be >>>>>>> surprised if I was the youngest in the team :-) >>>>>> >>>>>> The younger the better. ;-) >>>>>> >>>>>>> Many thanks to you and Andreas for your efforts, >>>>>>> Shayan Doust >>>>>> >>>>>> I love to support newcomers as best as possible. >>>>>> >>>>>> Kind regards >>>>>> >>>>>> Andreas. >>>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature