Uploaders orphaning packages / Conda (Was: Bug#921382: kineticstools: autopkgtest needs update for new version of h5py)
Hi Afif, please lets move this to the list I guess it is fine to quote your non-privat text here. On Tue, Feb 05, 2019 at 01:03:26AM -0500, Afif Elghraoui wrote: > > The > problem is I'm not sure how filing an RFA or orphaning a package works > within a team. I think what I should have done in the beginning is send > out a message on the debian-med list asking for someone to take over and > then formally orphan/remove the ones that didn't get adopted. You could start with removing yourself as Uploader which is a clear sign that you will not work on this any more. I might consider adding myself to make sure we have at least one uploader in the team. I do not see any reason to remove packages that are functional and not RC buggy (over several releases). > > I remember you > > said you are not using these any more but the same is true for me - I > > never ever used any of those packages and I spent a lot of time on these > > anyway> I wonder whether you might be able to become active and deal > > with the issues on the packages where you are in the Uploaders field. > > I don't think you should spend time on the packages you have no interest > in, either. What means "interest"? If it is I should not spend time on packages I'm not using for my own work I can leave Debian Med since I'm not using a single one. As a Debian maintainer I want to provide a useful system for my colleagues and the motivation to maintain also packages that are not used here is to possibly attract even more people to join the effort. This attraction of people has worked to some extend (way better than in other teams but admittedly I was hoping for more active contributors). > What I would be willing to do is file for removal of the > packages where I'm listed as the sole uploader. I do not think that we should remove packages with some popcon users that are not RC buggy. > Even if I was still using the packages, it is much less motivating to > maintainer Debian packages for scientific software than something > vendor-neutral and user-installable like conda, which has become very > popular in bioinformatics. In fact, all these PacBio packages that I had > created for Debian are now packaged in conda by upstream itself. Honestly, I think the conda-hype has some positive effects also for our packaging. I realised that upstreams learned that release tags are a good idea, responding to issues of packagers is more frequent and so on. IMHO software that is fit for Conda packaging has increased chances to be not hard to package for Debian as well. I do not see Conda as a pure competitor to our efforts since there are also different areas where the different packaging efforts are differently suited. However, by all means we should force the effort to package the Conda tools themselves in any case. Kind regards Andreas. -- http://fam-tille.de
Re: Third party code inside Ugene
Hi Andreas,
I did the following:
1. git clone https://github.com/ugeneunipro/ugene.git ugene_deb
2. removed zlib from ~/ugene_deb/src/libs_3rd_party
3. export UGENE_USE_BUNDLED_ZLIB=0
4. qmake -r
5. make
Could you please try to do the same steps?
Thank you,
Yuliya
On 02/01/2019 06:10 PM, Andreas Tille wrote:
Hi again,
I took the time and re-added
src/libs_3rdparty/zlib/zlib.pr[io]
and tried to set the variable below. Unfortunately it does not work with
removed zlib code:
...
cd src/libs_3rdparty/zlib/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile
/build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib/zlib.pro 'QMAKE_CFLAGS_RELEASE=-g -O2
-fdebug-prefix-map=/build/ugene-1.31.1+dfsg1=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2
-fdebug-prefix-map=/build/ugene-1.31.1+dfsg1=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2
-fdebug-prefix-map=/build/ugene-1.31.1+dfsg1=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2
-fdebug-prefix-map=/build/ugene-1.31.1+dfsg1=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_LFLAGS_RELEASE=-Wl,-z,relro
-Wl,-z,now' 'QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now' QMAKE_STRIP=: PREFIX=/usr
QMAKE_CFLAGS_ISYSTEM= QMAKE_CXXFLAGS_ISYSTEM= UGENE_WITHOUT_NON_FREE=1
UGENE_LRELEASE=lrelease-qt5 UGENE_LUPDATE=lupdate-qt5 UGENE_USE_BUNDLED_ZLIB=1 ) &&
make -f Makefile
WARNING: Failure to find: src/adler32.c
WARNING: Failure to find: src/compress.c
WARNING: Failure to find: src/crc32.c
WARNING: Failure to find: src/deflate.c
WARNING: Failure to find: src/gzio.c
WARNING: Failure to find: src/infback.c
WARNING: Failure to find: src/inffast.c
WARNING: Failure to find: src/inflate.c
WARNING: Failure to find: src/inftrees.c
WARNING: Failure to find: src/minigzip.c
WARNING: Failure to find: src/trees.c
WARNING: Failure to find: src/uncompr.c
WARNING: Failure to find: src/zutil.c
WARNING: Failure to find: src/crc32.h
WARNING: Failure to find: src/deflate.h
WARNING: Failure to find: src/inffast.h
WARNING: Failure to find: src/inffixed.h
WARNING: Failure to find: src/inflate.h
WARNING: Failure to find: src/inftrees.h
WARNING: Failure to find: src/trees.h
WARNING: Failure to find: src/zconf.h
WARNING: Failure to find: src/zlib.h
WARNING: Failure to find: src/zutil.h
WARNING: Failure to find: src/adler32.c
WARNING: Failure to find: src/compress.c
WARNING: Failure to find: src/crc32.c
WARNING: Failure to find: src/deflate.c
WARNING: Failure to find: src/gzio.c
WARNING: Failure to find: src/infback.c
WARNING: Failure to find: src/inffast.c
WARNING: Failure to find: src/inflate.c
WARNING: Failure to find: src/inftrees.c
WARNING: Failure to find: src/minigzip.c
WARNING: Failure to find: src/trees.c
WARNING: Failure to find: src/uncompr.c
WARNING: Failure to find: src/zutil.c
WARNING: Failure to find: src/crc32.h
WARNING: Failure to find: src/deflate.h
WARNING: Failure to find: src/inffast.h
WARNING: Failure to find: src/inffixed.h
WARNING: Failure to find: src/inflate.h
WARNING: Failure to find: src/inftrees.h
WARNING: Failure to find: src/trees.h
WARNING: Failure to find: src/zconf.h
WARNING: Failure to find: src/zlib.h
WARNING: Failure to find: src/zutil.h
make[2]: Entering directory '/build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib'
make -f Makefile.Release
make[3]: Entering directory '/build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib'
make[3]: *** No rule to make target 'src/adler32.c', needed by
'_tmp/obj/release/adler32.o'. Stop.
make[3]: Leaving directory '/build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib'
make[2]: *** [Makefile:40: release] Error 2
...
Kind regards
Andreas.
On Fri, Feb 01, 2019 at 08:15:29AM +0700, Yuliya Algaer wrote:
Hi Andreas,
Lets start with zlib first: it is easier that way we do not use any custom
flags, renaming and even have initial support to use system library first.
Check this code from ugene_globals.pri:
# By default, UGENE uses bundled zlib on Windows (libs_3rdparty/zlib) and OS
version on Linux.
# To use bundled version on any platform set UGENE_USE_BUNDLED_ZLIB = 1
defineTest( use_bundled_zlib ) {
contains( UGENE_USE_BUNDLED_ZLIB, 1 ) : return (true)
contains( UGENE_USE_BUNDLED_ZLIB, 0 ) : return (false)
win32 {
return (true)
}
return (false)
}
This way you can switch to the system library: bundled sources will not be
used at all.
So the next steps for Debian packaging could be:
1) Switch from CMake to qmake build. This is how we build UGENE for
production.
2) Try to build it with no bundled zlib. If it works you can completely
remove zlib folder from UGENE sources for Debian and add zlib-dev as the
required dependency.
About Phylip: this is plugin, so it can easily removed from the build &
source
Re: Bug#917143: t-coffee autopkgtest regression
On Mon, Feb 04, 2019 at 07:35:12PM +0100, Liubov Chuprikova wrote: > > > > Excellent! I think we need some goblet for the most active Outreachy / > > GSoC remainer (=beeing most active after the internship endet) and you > > are my favourite candidate for this praise! ;-) > > Ahah, thank you, Andreas! You are welcome. > > In any case you deserve a $DRINK at dinner on our sprint for your > > activity. > > Yehey! It happened that I had missed the opportunity to get a $drink in > September [1], so I am happy to get it now! :-) That's not missed. You get two (at least) ;-) See you Andreas. > [1] https://lists.debian.org/debian-med/2018/09/msg0.html -- http://fam-tille.de
Re: Bug#917143: t-coffee autopkgtest regression
On Mon, 4 Feb 2019 at 11:32, Andreas Tille wrote: > On Mon, Feb 04, 2019 at 11:05:36AM +0100, Liubov Chuprikova wrote: > > > > I have just pushed a fix of this! The problem was with two processes > > competing for the same temporary file, as the tempfile names were defined > > static. > > Excellent! I think we need some goblet for the most active Outreachy / > GSoC remainer (=beeing most active after the internship endet) and you > are my favourite candidate for this praise! ;-) > Ahah, thank you, Andreas! > In any case you deserve a $DRINK at dinner on our sprint for your > activity. > Yehey! It happened that I had missed the opportunity to get a $drink in September [1], so I am happy to get it now! :-) __ Liubov [1] https://lists.debian.org/debian-med/2018/09/msg0.html
Re: Bug#917143: t-coffee autopkgtest regression
On Mon, Feb 04, 2019 at 11:05:36AM +0100, Liubov Chuprikova wrote: > > I have just pushed a fix of this! The problem was with two processes > competing for the same temporary file, as the tempfile names were defined > static. Excellent! I think we need some goblet for the most active Outreachy / GSoC remainer (=beeing most active after the internship endet) and you are my favourite candidate for this praise! ;-) In any case you deserve a $DRINK at dinner on our sprint for your activity. Thanks a lot Andreas. -- http://fam-tille.de
Re: Bug#917143: t-coffee autopkgtest regression
Hi Andreas, On Sun, 27 Jan 2019 at 16:23, Andreas Tille wrote: > Control: tags -1 help upstream > Control: forwarded -1 https://github.com/cbcrg/tcoffee/issues/13 > > Hi Liubov, > > On Sun, Jan 27, 2019 at 04:06:51PM +0100, Liubov Chuprikova wrote: > > I was trying to figure out the reason for the failure but without any > > success. It appeared that the error is reproducible with the upstream's > > source version, so I have just opened an issue [1] to inform the upstream > > about this bug. > > > > [1] https://github.com/cbcrg/tcoffee/issues/13 > > Thanks a lot, > > Andreas. > I have just pushed a fix of this! The problem was with two processes competing for the same temporary file, as the tempfile names were defined static. With regards, Liubov
