Re: Fasta3 is non-free just because of some Smith Waterman implementation (Was: Please choose a free license for fasta3 components)
Hi Andreas, Regarding "Alex has once contacted upstream" note the sad news from https://cryptogenomicon.org/2019/03/11/farrars-striped-simd-smith-waterman/ Kind regards, Erik On Mon, Aug 19, 2019 at 10:06 PM Andreas Tille wrote: > > Hi Steffen, > > you have uploaded fasta3. When I wanted to upgrade to latest upstream I > realised that it is in non-free just because of two files implementing a > Smith Waterman algorithm. Alex has once contacted upstream as you can > see on our SoftwareLiberation page[1]. At least the wiki page does not > state any response. > > I wonder whether you might try to ping upstream or possibly use libssw > or libsmithwaterman as a replacement. > > Kind regards > > Andreas. > > [1] https://wiki.debian.org/DebianMed/SoftwareLiberation > > -- > http://fam-tille.de >
Re: [Debian-med-packaging] Bug#934600: gffread in cufflinks seems to be the same codebase but older
On 8/20/19 7:16 AM, Andreas Tille wrote: > Hi Alexandre, > > it looks as if the gffread code in cufflinks would be the > same code base but the code in gffread source seems to be > more recent. What do you think? > > Kind regards > > Andreas. > > - Forwarded message from Debian testing autoremoval watch > - > > Date: Tue, 20 Aug 2019 04:39:04 + > From: Debian testing autoremoval watch > To: cuffli...@packages.debian.org > Subject: cufflinks is marked for autoremoval from testing > > cufflinks 2.2.1+dfsg.1-3 is marked for autoremoval from testing on 2019-09-10 > > It is affected by these RC bugs: > 934600: cufflinks,gffread: both ship /usr/bin/gffread > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > - End forwarded message - > Hi Andreas, I wasn't aware of gffread as a separate project. If it is a successor of cufflink's gffread we can stop shipping gffread with cufflinks package and add gffread package into Suggested for cufflinks. I'll wait for some clarifications from the upstream and modify the cufflinks package accordingly. https://github.com/gpertea/gffread/issues/40 Best regards, Alex
[Help] libgtextutils: ftbfs with GCC-9
Control: tags -1 help
Hi,
any hint how to deal with
...
g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
-Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror -DDEBUG
-g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
test_text_reader.cpp: In function 'int main()':
test_text_reader.cpp:48:9: error: ambiguous overload for 'operator=' (operand
types are 'std::string' {aka 'std::__cxx11::basic_string'} and
'TextLineReader')
48 | line = reader ; //second line - with implicit conversion to std::string
| ^~
In file included from /usr/include/c++/9/string:55,
from /usr/include/c++/9/bits/locale_classes.h:40,
from /usr/include/c++/9/bits/ios_base.h:41,
from /usr/include/c++/9/ios:42,
from /usr/include/c++/9/ostream:38,
from /usr/include/c++/9/iostream:39,
from test_text_reader.cpp:19:
/usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]'
665 | operator=(const basic_string& __str)
| ^~~~
/usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]'
732 | operator=(basic_string&& __str)
| ^~~~
make[3]: *** [Makefile:781: test_text_reader.o] Error 1
Kind regards
Andreas.
--
http://fam-tille.de
Re: Fasta3 is non-free just because of some Smith Waterman implementation (Was: Please choose a free license for fasta3 components)
That is truly sad, indeed. Many thanks go to his widow and to Prof. Eddy for caring. It is also an opportunity to think about how we as a community can grow. A donation box for instance would never be enough to feed the kids, but it would be something like a nice gesture about work and his creator not being forgotten. We should possibly bring this up at our next Sprint. Thank for this pointer, Erik. Steffen On 20.08.19 11:07, Erik Sjölund wrote: Hi Andreas, Regarding "Alex has once contacted upstream" note the sad news from https://cryptogenomicon.org/2019/03/11/farrars-striped-simd-smith-waterman/ Kind regards, Erik On Mon, Aug 19, 2019 at 10:06 PM Andreas Tille wrote: Hi Steffen, you have uploaded fasta3. When I wanted to upgrade to latest upstream I realised that it is in non-free just because of two files implementing a Smith Waterman algorithm. Alex has once contacted upstream as you can see on our SoftwareLiberation page[1]. At least the wiki page does not state any response. I wonder whether you might try to ping upstream or possibly use libssw or libsmithwaterman as a replacement. Kind regards Andreas. [1] https://wiki.debian.org/DebianMed/SoftwareLiberation -- http://fam-tille.de
Re: [Debian-med-packaging] Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
On 8/20/19 1:24 PM, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> any hint how to deal with
this is a test file. In test, there is explicit conversion to string:
line = reader.line_string() ; //first line - with explicit method to get
the string
which works fine as expected
In gcc 9 bug, it is implicit conversion that fails. Seems due some c++
11 updates on operators, but I am not an expert on this kind of stuff.
As this is only a test, and there is a way to get the result as a string
(as first test above test with explicit method), I wonder if we could
not simply patch to remove those lines:
line = reader ; //second line - with implicit conversion to
std::string
ASSERT( line == "second line" ) ;
Further test may also complain (using implicit too):
istream &is2 ( reader ) ; // fourth line - with implicit
conversion to std::istream
However, as it is a library, implicit conversion may fail on other tools
linking with this lib Best of course would be to get a fix for this
assignement operator
Olivier
>
>
> ...
> g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
> -Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror
> -DDEBUG -g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
> test_text_reader.cpp: In function 'int main()':
> test_text_reader.cpp:48:9: error: ambiguous overload for 'operator=' (operand
> types are 'std::string' {aka 'std::__cxx11::basic_string'} and
> 'TextLineReader')
>48 | line = reader ; //second line - with implicit conversion to
> std::string
> | ^~
> In file included from /usr/include/c++/9/string:55,
> from /usr/include/c++/9/bits/locale_classes.h:40,
> from /usr/include/c++/9/bits/ios_base.h:41,
> from /usr/include/c++/9/ios:42,
> from /usr/include/c++/9/ostream:38,
> from /usr/include/c++/9/iostream:39,
> from test_text_reader.cpp:19:
> /usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
> _Traits = std::char_traits; _Alloc = std::allocator]'
> 665 | operator=(const basic_string& __str)
> | ^~~~
> /usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
> [with _CharT = char; _Traits = std::char_traits; _Alloc =
> std::allocator]'
> 732 | operator=(basic_string&& __str)
> | ^~~~
> make[3]: *** [Makefile:781: test_text_reader.o] Error 1
>
>
> Kind regards
>
> Andreas.
>
>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
Hi Olivier,
I'm just forwarding this to Debian Mentors list to get a wider audience.
I'd prefer a fix over simply removing the test ...
Thanks for your analysis anyway
Andreas.
On Tue, Aug 20, 2019 at 03:36:48PM +0200, Olivier Sallou wrote:
>
> On 8/20/19 1:24 PM, Andreas Tille wrote:
> > Control: tags -1 help
> >
> > Hi,
> >
> > any hint how to deal with
>
>
> this is a test file. In test, there is explicit conversion to string:
>
> line = reader.line_string() ; //first line - with explicit method to get
> the string
>
> which works fine as expected
>
> In gcc 9 bug, it is implicit conversion that fails. Seems due some c++
> 11 updates on operators, but I am not an expert on this kind of stuff.
>
> As this is only a test, and there is a way to get the result as a string
> (as first test above test with explicit method), I wonder if we could
> not simply patch to remove those lines:
>
>
> line = reader ; //second line - with implicit conversion to
> std::string
> ASSERT( line == "second line" ) ;
>
> Further test may also complain (using implicit too):
>
> istream &is2 ( reader ) ; // fourth line - with implicit
> conversion to std::istream
>
>
> However, as it is a library, implicit conversion may fail on other tools
> linking with this lib Best of course would be to get a fix for this
> assignement operator
>
> Olivier
>
> >
> >
> > ...
> > g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g
> > -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
> > -Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror
> > -DDEBUG -g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
> > test_text_reader.cpp: In function 'int main()':
> > test_text_reader.cpp:48:9: error: ambiguous overload for 'operator='
> > (operand types are 'std::string' {aka 'std::__cxx11::basic_string'}
> > and 'TextLineReader')
> >48 | line = reader ; //second line - with implicit conversion to
> > std::string
> > | ^~
> > In file included from /usr/include/c++/9/string:55,
> > from /usr/include/c++/9/bits/locale_classes.h:40,
> > from /usr/include/c++/9/bits/ios_base.h:41,
> > from /usr/include/c++/9/ios:42,
> > from /usr/include/c++/9/ostream:38,
> > from /usr/include/c++/9/iostream:39,
> > from test_text_reader.cpp:19:
> > /usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
> > 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> > std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
> > std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
> > _Traits = std::char_traits; _Alloc = std::allocator]'
> > 665 | operator=(const basic_string& __str)
> > | ^~~~
> > /usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
> > 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> > std::__cxx11::basic_string<_CharT, _Traits,
> > _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
> > [with _CharT = char; _Traits = std::char_traits; _Alloc =
> > std::allocator]'
> > 732 | operator=(basic_string&& __str)
> > | ^~~~
> > make[3]: *** [Makefile:781: test_text_reader.o] Error 1
> >
> >
> > Kind regards
> >
> > Andreas.
> >
> >
> --
> Olivier Sallou
> Univ Rennes, Inria, CNRS, IRISA
> Irisa, Campus de Beaulieu
> F-35042 RENNES - FRANCE
> Tel: 02.99.84.71.95
>
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>
>
>
--
http://fam-tille.de
Re: [Debian-med-packaging] Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
On 8/20/19 3:41 PM, Andreas Tille wrote:
> Hi Olivier,
>
> I'm just forwarding this to Debian Mentors list to get a wider audience.
> I'd prefer a fix over simply removing the test ...
commenting in text_line_reader.h:
// operator const std::string& () const { return
line_string() ; }
do the job and test pass
but I would prefer a c++ friend to acknowledge this It works but I
do not if there are side effects
Olivier
>
> Thanks for your analysis anyway
>
> Andreas.
>
> On Tue, Aug 20, 2019 at 03:36:48PM +0200, Olivier Sallou wrote:
>> On 8/20/19 1:24 PM, Andreas Tille wrote:
>>> Control: tags -1 help
>>>
>>> Hi,
>>>
>>> any hint how to deal with
>>
>> this is a test file. In test, there is explicit conversion to string:
>>
>> line = reader.line_string() ; //first line - with explicit method to get
>> the string
>>
>> which works fine as expected
>>
>> In gcc 9 bug, it is implicit conversion that fails. Seems due some c++
>> 11 updates on operators, but I am not an expert on this kind of stuff.
>>
>> As this is only a test, and there is a way to get the result as a string
>> (as first test above test with explicit method), I wonder if we could
>> not simply patch to remove those lines:
>>
>>
>> line = reader ; //second line - with implicit conversion to
>> std::string
>> ASSERT( line == "second line" ) ;
>>
>> Further test may also complain (using implicit too):
>>
>> istream &is2 ( reader ) ; // fourth line - with implicit
>> conversion to std::istream
>>
>>
>> However, as it is a library, implicit conversion may fail on other tools
>> linking with this lib Best of course would be to get a fix for this
>> assignement operator
>>
>> Olivier
>>
>>>
>>> ...
>>> g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g
>>> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
>>> -Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror
>>> -DDEBUG -g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
>>> test_text_reader.cpp: In function 'int main()':
>>> test_text_reader.cpp:48:9: error: ambiguous overload for 'operator='
>>> (operand types are 'std::string' {aka 'std::__cxx11::basic_string'}
>>> and 'TextLineReader')
>>>48 | line = reader ; //second line - with implicit conversion to
>>> std::string
>>> | ^~
>>> In file included from /usr/include/c++/9/string:55,
>>> from /usr/include/c++/9/bits/locale_classes.h:40,
>>> from /usr/include/c++/9/bits/ios_base.h:41,
>>> from /usr/include/c++/9/ios:42,
>>> from /usr/include/c++/9/ostream:38,
>>> from /usr/include/c++/9/iostream:39,
>>> from test_text_reader.cpp:19:
>>> /usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
>>> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
>>> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
>>> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
>>> _Traits = std::char_traits; _Alloc = std::allocator]'
>>> 665 | operator=(const basic_string& __str)
>>> | ^~~~
>>> /usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
>>> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
>>> std::__cxx11::basic_string<_CharT, _Traits,
>>> _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
>>> [with _CharT = char; _Traits = std::char_traits; _Alloc =
>>> std::allocator]'
>>> 732 | operator=(basic_string&& __str)
>>> | ^~~~
>>> make[3]: *** [Makefile:781: test_text_reader.o] Error 1
>>>
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
>>>
>> --
>> Olivier Sallou
>> Univ Rennes, Inria, CNRS, IRISA
>> Irisa, Campus de Beaulieu
>> F-35042 RENNES - FRANCE
>> Tel: 02.99.84.71.95
>>
>> gpg key id: 4096R/326D8438 (keyring.debian.org)
>> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>>
>>
>>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: [MoM] FAST progress (was Re: [MoM] fast: Add further dependencies to enable chroot / cowbuilder to build)
Hi Shayan, On Tue, Aug 20, 2019 at 07:14:33PM +0100, Shayan Doust wrote: > > Welcome back :). :-) > I've probably checked gatb-core at least a dozen times before you sent > this to me. I just never checked debian/patch as I didn't think this was > some cmake thing :). Talked to upstream and they will take care of > soversion within the next release and package update, but for now I just > added this as a patch. Cool! > > ...In this case the dynamic lib is added but you get the idea how to > > add a static one from this patch... > > Thank you. This is done. > > If you have time, do you mind just checking fast package for me? There > are still a few things I need to do with libfast-dev as I haven't done > this yet. Where should *.a go? Should this go under > /usr/lib/-linux-gnu? Yes. I'll have a look and may be I'll turn this into a d-shlibs call. Thank you have an example. > I know this can be set accordingly in > debian/rules but I have seen *.a both in /usr/lib and > /usr/lib/-linux-gnu. Same for *.so. The latter is the modern (=multiarch) one. /usr/lib is just a left over by not so properly maintaines packages. > I also see > rc-version-greater-than-expected-version, presumably from how upstream > brands the version. Should this be ignored or can this be safely rectified? You need to use opts="uversionmangle=s/-rc/~rc/" in debian/watch and use ~rc in d/changelog. The rationale is that '~' sorts lower with `dpkg --compare-versions`. So if upstream is issuing a real release it is in correct alphabethic sequence and considered a higher version if you drop ~rc (or ~beta or whatever upstream might invent to mark a pre-release). > Additionally, productivity will start to decrease for only a few weeks > to a month as I prepare to move out and into university accommodation. May be we finalise this package in the next days. I'll have a look and might finish it if you don't mind. Thanks for your great work Andreas. > On 19/08/2019 07:39, Andreas Tille wrote: > > Hi Shayan, > > > > On Sun, Aug 18, 2019 at 05:53:01PM +0100, Shayan Doust wrote: > >> Hello, > >> > >> Please disregard the previous email entirely just to save you time from > >> writing, as I have finally figured things out. > > > > I'm slowly recovering from last week need to cope with some backlog. > > Thus saving my time is pretty welcome. ;-) > > > >> fast should contain only executable binaries which in this case are > >> openigt fast client and server binaries. > > > > Yes. > > > >> libfastSOVERSION should contain the shared / *.so only although grepping > >> libFAST.so, there is no soversion. Is this libfast0 then? > > > > Several upstreams do not know about SOVERSION and once you contact them > > you could try to talk about this as well. If upstream does not set a > > soversion we should do this. In gatb-core you can find a simple example: > > > > > > https://salsa.debian.org/med-team/gatb-core/blob/master/debian/patches/set_soversion.patch > > > > Yes, 0 is a good choice here and we need to bump the SOVERSION once > > upstream might change the ABI (which frequently happens without any > > notice - you see we are at version 2 in gatb-core meanwhile). > > > >> libfast-dev contains only the header files and the static library (*.a). > >> I realised this can be done with the ar tool. Is it sensible to traverse > >> the build directory and add all object files to archive to create a > >> libfast.a? > > > > There is no need for manual intervention with ar. CMake can do this > > easily. Once we have used gatb-core as an example we might stick to > > this one: > > > > > > https://salsa.debian.org/med-team/gatb-core/blob/master/debian/patches/dynamic_lib.patch > > > > In this case the dynamic lib is added but you get the idea how to > > add a static one from this patch. > > > >> I will now just slightly modify the existing debian/ files to > >> accommodate these changes. > >> > >> Additionally, I will stick to modifying fast so I will not need the > >> additional CL header files, so the dependency is now just opencl. I will > >> talk to upstream about this. > > > > If this approach will work out that sounds like a good alternative > > which was missing in my list. > > > >> Many thanks & hopefully this isn't an inconvenience, > > > > Definitely not. Its a pleasure to see you growing into way more > > complex packages. > > > > Kind regards > > > >Andreas. > > > >> Shayan Doust > >> > >> > >> Forwarded Message > >> Subject: Re: [MoM] Re: fast: Add further dependencies to enable chroot / > >> cowbuilder to build > >> Resent-Date: Sat, 17 Aug 2019 13:16:24 + (UTC) > >> Resent-From: debian-med@lists.debian.org > >> Date: Sat, 17 Aug 2019 14:16:05 +0100 > >> From: Shayan Doust > >> To: debian-med@lists.debian.org > >> > >> Hello Andreas, > >> > >> Many thanks for taking the time to reply. > >> > >> Just a few side comments for whenever you next have the free time
