Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Andreas Tille
Hi Kevin,

On Fri, Jul 22, 2016 at 11:15:12PM +1000, Kevin Murray wrote:
> 
> Andreas/Michael may remember differently, but from memory we will have:
> 
> - SeqAn 1.x in src:seqan -> seqan-dev (only, no apps)
> - SeqAn 2.x in src:seqan2 -> libseqan2-dev  and seqan-apps (and one day -doc)

Ahhh, this somehow shades light in my weak memory.  Makes sense and if we
are lucky the gcc-6 issue does not affect the seqan(1)-dev part.
 
> So yes, I agree with you. Seqan 1.x (i.e. src:seqan) should be made to build
> correctly and not get booted from testing (and git should be reverted such 
> that
> it contains only 1.x). Especially while the likes of bowtie & tophat rely upon
> them. (Though for smaller tools, providing patches to get them to build with
> seqan 2.x shouldn't be monumentally difficult and should be qulte
> upstream-able).

ACK for the plan in general.  What about the sequence for realisation.
Should we may be try to reate libseqan1-dev (and droping seqan1-apps)
soon?  When writing it:  Should we may be keep the name seqan for
version 2 and specify the number one only on the old version?

Thanks for your insight.

Kind regards

  Andreas. 

-- 
http://fam-tille.de



Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Kevin Murray
Hi Sascha,


On 13:40 22/07, Sascha Steinbiss wrote:
> Hi all,
> 
> [...]
> > #811841 seqan: FTBFS with GCC 6: no match for
> > 
> > - refers to v1.4, AFAIK version 2.0 is already in the archive, so this
> > one should probably me closed. 
> 
> I don't think it is [1]. Anyway, AFAICS SeqAn 2.0 is intended to go into
> a separate package seqan2 instead? Some of the recent mails here on this
> list seem to indicate that?
> The seqan repo in Git has 2.0 already merged into master but not
> uploaded yet. Can anybody clarify please?
> 
> If there is going to be a new repo for seqan2 because of API changes I
> think it might be worth fixing the GCC6 FTBFS in the 'old' (1.4) seqan
> package to make sure that important tools depending on 1.4 (such as
> bowtie, tophat, ...) stay in testing.
> What do you think?
> 
> Thanks
> Sascha
> 
> [1] https://packages.debian.org/source/unstable/seqan


Andreas/Michael may remember differently, but from memory we will have:

- SeqAn 1.x in src:seqan -> seqan-dev (only, no apps)
- SeqAn 2.x in src:seqan2 -> libseqan2-dev  and seqan-apps (and one day -doc)

So yes, I agree with you. Seqan 1.x (i.e. src:seqan) should be made to build
correctly and not get booted from testing (and git should be reverted such that
it contains only 1.x). Especially while the likes of bowtie & tophat rely upon
them. (Though for smaller tools, providing patches to get them to build with
seqan 2.x shouldn't be monumentally difficult and should be qulte
upstream-able).

Cheers,
K

---
Kevin Murray
0xA4B4EE6A



Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Sascha Steinbiss
Hi all,

[...]
> #811841 seqan: FTBFS with GCC 6: no match for
> 
> - refers to v1.4, AFAIK version 2.0 is already in the archive, so this
> one should probably me closed. 

I don't think it is [1]. Anyway, AFAICS SeqAn 2.0 is intended to go into
a separate package seqan2 instead? Some of the recent mails here on this
list seem to indicate that?
The seqan repo in Git has 2.0 already merged into master but not
uploaded yet. Can anybody clarify please?

If there is going to be a new repo for seqan2 because of API changes I
think it might be worth fixing the GCC6 FTBFS in the 'old' (1.4) seqan
package to make sure that important tools depending on 1.4 (such as
bowtie, tophat, ...) stay in testing.
What do you think?

Thanks
Sascha

[1] https://packages.debian.org/source/unstable/seqan

>>
>> So anybody with some gcc-6 skills or those who want to ask on Debian
>> Mentors list for help which usually receives helpful responses quite
>> quickly is invited to work on our bugs.
>>
>> Kind regards
>>
>>   Andreas.
>>
>> On Wed, May 04, 2016 at 08:33:08AM +0200, Andreas Tille wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote:


 Sure, I will see what I can do. How do you propose we as DMs
 communicate
 the changes -- just push a new branch in git and ping the list?
>>> Sascha, thanks for your good work on several bugs - without
>>> counting it
>>> was more than one per week.  If others might come up with this rate
>>> we
>>> could be quite safe for the release.  But its no time to relax and
>>> more
>>> bug fixers would be really great.  Specifically newcomers could
>>> gather
>>> some packaging skills by triaging bugs in existing packages.
>>>
>>> Kind regards
>>>
>>>   Andreas.
>>>
>>> -- 
>>> http://fam-tille.de
>>>
>>>
> 


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 



Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Andreas Tille
Hi Gert,

thanks for your gcc-6 fixing effort and the status update.

On Fri, Jul 22, 2016 at 01:59:57PM +0200, Gert Wollny wrote:
> The current list of open gcc-6 bugs is this [1], I had a look at most
> of them already.

I'd say there is a "new set" of gcc 6 errors:

#831100 [S|  |  ] [src:conquest-dicom-server] conquest-dicom-server: FTBFS with 
GCC 6: cpp_type_traits.h:212:12: error: redefinition of 'struct 
std::__is_integer'
#831105 [S|  |  ] [src:pbdagcon] pbdagcon: FTBFS with GCC 6: cstdlib:75:25: 
fatal error: stdlib.h: No such file or directory
#831110 [S|  |  ] [src:trinityrnaseq] trinityrnaseq: FTBFS with GCC 6: 
./aligns/KmerAlignCore.cc:6:34: fatal error: aligns/KmerAlignCore.h: No such 
file or directory
#831115 [S|  |  ] [src:hhsuite] hhsuite: FTBFS with GCC 6: util.C:58:26: error: 
'float log2(float)' conflicts with a previous declaration
#831126 [S|  |  ] [src:vxl] vxl: FTBFS with GCC 6: vcl_compiler.h:127:4: error: 
#error "Dunno about this gcc"
#831131 [S|  |  ] [src:vsearch] vsearch: FTBFS with GCC 6: maps.cc:485:3: 
error: narrowing conversion of '128' from 'int' to 'char' inside { } 
[-Wnarrowing]
#831138 [S|  |  ] [src:snap-aligner] snap-aligner: FTBFS with GCC 6: 
tuple:851:29: error: expected primary-expression before '.' token
#831171 [S|  |  ] [src:proftmb] proftmb: FTBFS with GCC 6: proftmb.cpp:166:47: 
error: no match for 'operator<<' (operand types are 'std::basic_ostream' 
and 'std::ostringstream {aka std::__cxx11::basic_ostringstream}')
#831188 [S|  |  ] [src:libgenome] libgenome: FTBFS with GCC 6: gnDefs.cpp:8:20: 
error: 'int64 abs(int64)' conflicts with a previous declaration
#831208 [S|  |  ] [src:dindel] dindel: FTBFS with GCC 6: DInDel.hpp:145:229: 
error: template argument 1 is invalid

These are not on your list and are filed in a later effort - I'm
not sure why they are not tagged properly.

> Some comments: 
> 
> #811841 seqan: FTBFS with GCC 6: no match for
> 
> - refers to v1.4, AFAIK version 2.0 is already in the archive, so this
> one should probably me closed. 

Well, 2.x is not in the archive but Kevin is working on it.
 
> #816569 mrs: FTBFS with GCC 6: was not declared in this scope
> 
>  - is waiting for boost compiled with gcc-6 (i.e. c++11) 

OK.
 
> #811702 librg-blast-parser-perl 
> 
>  - not sure what to make of it, it also has the user-tag gcc-6-macro 
>    which might point to a conflict between a newly defined macro and 
>    a function.

Thanks for looking into it.

> #811859  berkeley-express
> 
>   - requires static_cast on the shared pointer 

Thanks for looking into it.
 
> #811866 hyphy
> 
>   - Closed upstream? 

I'll apply the fix from upstream and will care for this.

> #811893 swarm-cluster
> 
>   - Needs knowledge with inline assembler 

Any volunteer to ask on debian-ment...@lists.debian.org for further
input?
 
> #812031 prime-phylo
> 
>   - could be worked around by forcing to -std=c++98 in the maintainer 
>     cxxflags (probably be best solution, because the use of constexpr 
>     might require forcing c++11, and upstream might not yet want 
>     that).

I might try this.
 
> I think I'll look into #811702 and #811859  the next few days. 

So with the exception of  #811893 swarm-cluster  this looks good for the
"old" set of gcc-6 errors[1] but the new ones seem to be pending.

Any takers?

Kind regards

   Andreas.

 
> [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-pack
> ag...@lists.alioth.debian.org;tag=ftbfs-gcc-6;users=debian-
> g...@lists.debian.org
> 
> 
> > 
> > So anybody with some gcc-6 skills or those who want to ask on Debian
> > Mentors list for help which usually receives helpful responses quite
> > quickly is invited to work on our bugs.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > On Wed, May 04, 2016 at 08:33:08AM +0200, Andreas Tille wrote:
> > > 
> > > Hi,
> > > 
> > > On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote:
> > > > 
> > > > 
> > > > Sure, I will see what I can do. How do you propose we as DMs
> > > > communicate
> > > > the changes -- just push a new branch in git and ping the list?
> > > Sascha, thanks for your good work on several bugs - without
> > > counting it
> > > was more than one per week.  If others might come up with this rate
> > > we
> > > could be quite safe for the release.  But its no time to relax and
> > > more
> > > bug fixers would be really great.  Specifically newcomers could
> > > gather
> > > some packaging skills by triaging bugs in existing packages.
> > > 
> > > Kind regards
> > > 
> > >   Andreas.
> > > 
> > > -- 
> > > http://fam-tille.de
> > > 
> > > 
> 
> 

-- 
http://fam-tille.de



Re: Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Gert Wollny
Hello all, 

Am Freitag, den 22.07.2016, 13:29 +0200 schrieb Andreas Tille:
> Hi folks,
> 
> But we need to do more specifically the gcc-6 bugs are quite a
> blocker.  I'd like to re-generate metapackages soon.  It would be not
> nice if these would not miss the gcc-6 affected losses we currently
> have (or will have soon).

The current list of open gcc-6 bugs is this [1], I had a look at most
of them already. Some comments: 

#811841 seqan: FTBFS with GCC 6: no match for

- refers to v1.4, AFAIK version 2.0 is already in the archive, so this
one should probably me closed. 

#816569 mrs: FTBFS with GCC 6: was not declared in this scope

 - is waiting for boost compiled with gcc-6 (i.e. c++11) 

#811702 librg-blast-parser-perl 

 - not sure what to make of it, it also has the user-tag gcc-6-macro 
   which might point to a conflict between a newly defined macro and 
   a function.

#811859  berkeley-express

  - requires static_cast on the shared pointer 

#811866 hyphy

  - Closed upstream? 

#811893 swarm-cluster

  - Needs knowledge with inline assembler 

#812031 prime-phylo

  - could be worked around by forcing to -std=c++98 in the maintainer 
    cxxflags (probably be best solution, because the use of constexpr 
    might require forcing c++11, and upstream might not yet want 
    that).

I think I'll look into #811702 and #811859  the next few days. 

Best, 
Gert 


[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-pack
ag...@lists.alioth.debian.org;tag=ftbfs-gcc-6;users=debian-
g...@lists.debian.org


> 
> So anybody with some gcc-6 skills or those who want to ask on Debian
> Mentors list for help which usually receives helpful responses quite
> quickly is invited to work on our bugs.
> 
> Kind regards
> 
>   Andreas.
> 
> On Wed, May 04, 2016 at 08:33:08AM +0200, Andreas Tille wrote:
> > 
> > Hi,
> > 
> > On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote:
> > > 
> > > 
> > > Sure, I will see what I can do. How do you propose we as DMs
> > > communicate
> > > the changes -- just push a new branch in git and ping the list?
> > Sascha, thanks for your good work on several bugs - without
> > counting it
> > was more than one per week.  If others might come up with this rate
> > we
> > could be quite safe for the release.  But its no time to relax and
> > more
> > bug fixers would be really great.  Specifically newcomers could
> > gather
> > some packaging skills by triaging bugs in existing packages.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 



Thanks to Gert and Sascha - other please keep on fixing bugs (Was: Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs))

2016-07-22 Thread Andreas Tille
Hi folks,

Gert and Sascha did a lot of bug fixing recently.  But we need to do
more specifically the gcc-6 bugs are quite a blocker.  I'd like to
re-generate metapackages soon.  It would be not nice if these would not
miss the gcc-6 affected losses we currently have (or will have soon).

So anybody with some gcc-6 skills or those who want to ask on Debian
Mentors list for help which usually receives helpful responses quite
quickly is invited to work on our bugs.

Kind regards

  Andreas.

On Wed, May 04, 2016 at 08:33:08AM +0200, Andreas Tille wrote:
> Hi,
> 
> On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote:
> > 
> > Sure, I will see what I can do. How do you propose we as DMs communicate
> > the changes -- just push a new branch in git and ping the list?
> 
> Sascha, thanks for your good work on several bugs - without counting it
> was more than one per week.  If others might come up with this rate we
> could be quite safe for the release.  But its no time to relax and more
> bug fixers would be really great.  Specifically newcomers could gather
> some packaging skills by triaging bugs in existing packages.
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de