Hello, 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 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. 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. Best regards, Shayan Doust [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