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))
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))
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))
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))
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))
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))
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
Thanks to Sascha for his bug fixing - but we should do more (Was: Strengthening team by fixing other members bugs)
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
Re: Strengthening team by fixing other members bugs
Hi folks, Sascha did a great job in fixing more than one bug per week. Anybody else??? Kind regards Andreas. On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote: > Hi Andreas, > > [...] > > It would be great if everybody who considers a member of the Debian Med > > team (even if not very active until now) would try to fix one bug per > > week. > > 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? > > Cheers > Sascha > > > -- > 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. > > -- http://fam-tille.de
Re: Strengthening team by fixing other members bugs
On Mon, Apr 04, 2016 at 10:12:51AM +0100, Ghislain Vaillant wrote: > >last week I had the idea to declare April as a month of fixing bugs in > >Debian Med packages. While about eight monthes are left until we the > >freeze for Jessie will start we should constatly make sure that our > >packages are free of bugs and are distributable all the time. I think > >it makes perfectly sense if everybody would look into bugs of packages > >he has not yet touched. This would increase the number of people > >looking for packages and in most cases you can learn something new. > > I would add that, alongside fixing bugs, we should ensure all our > packages have some sort of CI testing going on, when applicable. https://wiki.debian.org/SummerOfCode2016/Projects#SummerOfCode2016.2FProjects.2FBioToolsTesting.Continuous_Integration_for_all_biological_applications_inside_Debian :-) > >Kind regards and have fun fixing bugs > > > > Andreas. > > > >[1] https://bugs.debian.org/debian-med-packag...@lists.alioth.debian.org > > Assuming someone has got a fix for a bug concerning a package he or she > does not personally maintain, how do you think this someone should > proceed? Push directly to the debian-branch? Yes. I'd consider any team member equal. Everybody should feel free to push to master and also to add the own ID to Uploaders if this should be no one term contribution. > To a temporary branch, and give > the official DM an opportunity to review? I'm perfectly fine if any DD uploads a fixed package as team upload. I'm also fine if DMs are requesting upload permissions - otherwise we are using the usual sponsering procedure. > I know yourself and myself have done this directly for each other's > packages in the past (which I am fine with), but it may be not to > everyone's taste. I did in the past in the same manner as suggested above for more than 100 Debian Med packages and never have stepped on anybodies toes by doing so. I even team-hijacked packages that were de-facto orphaned (xmedcon, python-hl7) in the same manner and not even the non-team maintainers raised their voice (I'm not sure whether they noticed it despite they've got at least two warning mails). IMHO we should push for more action if action is needed rather than assuming different taste of people who might have several reasons for beeing silent / inactive. I hereby actively declare that if you find my ID in Uploaders field or in d/changelog you can always fix bugs in these packages, upgrade to new upstream or enhance the package in some other way I'm really happy that I do not need to do this myself. Please do so if in doubt! If you are unsure upload to DELAYED/x but usually I observe VCS mails anyway and will insist when observing some unwanted change. Kind regards Andreas. -- http://fam-tille.de
Re: Strengthening team by fixing other members bugs
On 04/04/16 09:14, Andreas Tille wrote: Hi, last week I had the idea to declare April as a month of fixing bugs in Debian Med packages. While about eight monthes are left until we the freeze for Jessie will start we should constatly make sure that our packages are free of bugs and are distributable all the time. I think it makes perfectly sense if everybody would look into bugs of packages he has not yet touched. This would increase the number of people looking for packages and in most cases you can learn something new. I would add that, alongside fixing bugs, we should ensure all our packages have some sort of CI testing going on, when applicable. It would be great if everybody who considers a member of the Debian Med team (even if not very active until now) would try to fix one bug per week. If you have problems finding target bugs simply seek our teams bug page[1]. Kind regards and have fun fixing bugs Andreas. [1] https://bugs.debian.org/debian-med-packag...@lists.alioth.debian.org Assuming someone has got a fix for a bug concerning a package he or she does not personally maintain, how do you think this someone should proceed? Push directly to the debian-branch? To a temporary branch, and give the official DM an opportunity to review? I know yourself and myself have done this directly for each other's packages in the past (which I am fine with), but it may be not to everyone's taste. Ghis
Re: Strengthening team by fixing other members bugs
On Mon, Apr 04, 2016 at 09:52:27AM +0100, Sascha Steinbiss wrote: > > It would be great if everybody who considers a member of the Debian Med > > team (even if not very active until now) would try to fix one bug per > > week. > > 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? There is no point to create a separate branch to fix a bug. Just commit a fix and follow the usual sponsering procedure (or ask for upload permissions if you consider working on the package in the future). Kind regards Andreas. -- http://fam-tille.de
Re: Strengthening team by fixing other members bugs
Hi Andreas, [...] > It would be great if everybody who considers a member of the Debian Med > team (even if not very active until now) would try to fix one bug per > week. 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? Cheers Sascha -- 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.
Strengthening team by fixing other members bugs
Hi, last week I had the idea to declare April as a month of fixing bugs in Debian Med packages. While about eight monthes are left until we the freeze for Jessie will start we should constatly make sure that our packages are free of bugs and are distributable all the time. I think it makes perfectly sense if everybody would look into bugs of packages he has not yet touched. This would increase the number of people looking for packages and in most cases you can learn something new. It would be great if everybody who considers a member of the Debian Med team (even if not very active until now) would try to fix one bug per week. If you have problems finding target bugs simply seek our teams bug page[1]. Kind regards and have fun fixing bugs Andreas. [1] https://bugs.debian.org/debian-med-packag...@lists.alioth.debian.org -- http://fam-tille.de
