Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
Hi Charles, Small (but needed) correction: It’s CPAN, CRAN is for R. I have both a new Bio-Graphics and a test BioPerl-Run up on CPAN, but it looks like there was one additional missing dependency (DB_File) with Bio::Graphics, which I am adding. There are some odd versioning issues with Bio::Graphics that I’m also attempting to reconcile, but the distribution seems to show up fine in CPAN. chris On 12/16/16, 6:57 AM, "Charles Plessy" wrote: >Hello everybody, and thanks Carnë for the quick answer ! > >Le Fri, Dec 16, 2016 at 01:06:35PM +0100, Andreas Tille a écrit : >> >> On Fri, Dec 16, 2016 at 11:38:02AM +, Carnë Draug wrote: >> >> > For example, there is now >> > bio-biblio, bio-eutilities, and bio-coordinates which were previously part >> > of bioperl itself. The core bioperl is now the bioperl-live distribution. >> >> I guess we could document this in README.Debian since I personally do >> not see a reason to rename the Debian package from bioperl to >> bioperl-live. Do you think keeping the old name would be confusing for >> insiders? > >At the moment, the bioperl Debian source package produces two binary packages: >"libbio-perl-perl" provides the libary itself and "bioperl" provides the >command-line utilities. As long as on CRAN BioPerl is not renamed >bioperl-live, I think that there is no need to rename the packages. In any >case, I think that it is good to keep a "bioperl" binary package to install the >command-line utilities and pull the BioPerl libraries by dependency. > >> > There is at least one very important fix on the new bioperl which fixes >> > the connection to the NCBI servers (although the fix is simple enough >> > that could be backported). >> >> A backport of this fix would be helpful if we really decide to revert >> the upgrade. > >Indeed, if we can just cherry pick patches from GitHub, it would be good to >apply them in Debian. Can somebody suggest a list of commits ? > >> My original proposal: >> >>1. Revert the version bump of bioperl and upload the old version >> with an epoch (1:1.6.924-6). >>2. Upload 1.7.1-2 to experimental >>3. Solve all issues with BioPerl 1.7.x after Stretch release. >>4. Backport 1.7.x to Stretch once issues are solved. >> >> Keeping bioperl 1.7.1 and rather drop other packages: >> >>1. Keep bioperl 1.7.1 >>2. Drop gbrowse and bioperl-run from Stretch >>3. Check all rdepends of bioperl whether they work with 1.7.1: >>4. Package as many as the needed tools as we might be able to. > >I think that, so close to the Debian stable release, and since some BioPerl >components have not been released upstream, the original proposal is wiser. >Debian stable releases last multiple years, so even bioperl 1.7.1 will become >old eventually. Therefore, I recommend to aim at stability; let's use the >stable backports once the 1.7.x ecosystem has taken shape. > >It would help a lot if the new BioPerl modules were released on CRAN. Debian >has an amazingly productive Perl team, equipped with many helper tools to >facilitate packaging, but the main paradigm is to get released sources from >CRAN. If we need to rely on the head of the master branch of GitHub >repositories, it will be much harder to ensure consistency, because we can not >make a package update for every commit. > >Have a nice day, > >Charles > >-- >Charles Plessy >Debian Med packaging team, >http://www.debian.org/devel/debian-med >Tsurumi, Kanagawa, Japan
Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
BTW, [1] here was: https://github.com/sanger-pathogens/Roary/issues/196 Cheers Sascha > On 17 Dec 2016, at 23:28, Sascha Steinbiss wrote: > > Hi all, > > thanks for checking these. > >>> roary >> >> Build, however when trying to simulate the test suite via >> >> cd t/data/genbank_gbff >> roary -f out *.gff >> >> Please cite Roary if you use any of the results it produces: >> Andrew J. Page, Carla A. Cummins, Martin Hunt, Vanessa K. Wong, Sandra >> Reuter, Matthew T. G. Holden, Maria Fookes, Daniel Falush, Jacqueline A. >> Keane, Julian Parkhill, >> "Roary: Rapid large-scale prokaryote pan genome analysis", >> Bioinformatics, 2015 Nov 15;31(22):3691-3693 >> doi: http://doi.org/10.1093/bioinformatics/btv421 >> Pubmed: 26198102 >> >> Use of uninitialized value in require at >> /usr/lib/x86_64-linux-gnu/perl/5.24/Encode.pm line 61. >> >> >> This does not look good even if it does not look related to BioPerl. > > In fact, it doesn’t look related to Roary either. It’s apparently a missing > Encode/ConfigLocal.pm in the coded provided by libencode-perl, but not a > fatal issue here as it doesn’t seem to impact the result or performance of > Roary. It’s been reported before [1] and I will let upstream know that the > warning is back. Not a blocker AFAICS. > > Cheers > Sascha
Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
Hi all, thanks for checking these. >> roary > > Build, however when trying to simulate the test suite via > > cd t/data/genbank_gbff > roary -f out *.gff > > Please cite Roary if you use any of the results it produces: >Andrew J. Page, Carla A. Cummins, Martin Hunt, Vanessa K. Wong, Sandra > Reuter, Matthew T. G. Holden, Maria Fookes, Daniel Falush, Jacqueline A. > Keane, Julian Parkhill, >"Roary: Rapid large-scale prokaryote pan genome analysis", > Bioinformatics, 2015 Nov 15;31(22):3691-3693 >doi: http://doi.org/10.1093/bioinformatics/btv421 >Pubmed: 26198102 > > Use of uninitialized value in require at > /usr/lib/x86_64-linux-gnu/perl/5.24/Encode.pm line 61. > > > This does not look good even if it does not look related to BioPerl. In fact, it doesn’t look related to Roary either. It’s apparently a missing Encode/ConfigLocal.pm in the coded provided by libencode-perl, but not a fatal issue here as it doesn’t seem to impact the result or performance of Roary. It’s been reported before [1] and I will let upstream know that the warning is back. Not a blocker AFAICS. Cheers Sascha
Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
Hi, I checked all rdepends of BioPerl. In summary there are no real new BioPerl related issues (Sascha, could you please check roary - see below). On Fri, Dec 16, 2016 at 01:06:35PM +0100, Andreas Tille wrote: > > $ apt-cache rdepends bioperl | grep "^ " | sort | uniq | grep -v -e > alien-hunter -e libbio-perl-perl -e med- > arb Not tested yet (non-free) > bioperl-run Works with patch, Test suite runs at Build time > gbrowse Fails - help is urgently needed: ... syntax error at /home/andreas/debian-maintain/alioth/debian-med_git/build-area/gbrowse-2.54+dfsg/t/../lib/Bio/Graphics/Browser2/DataSource.pm line 963, near "$ENV\" syntax error at /home/andreas/debian-maintain/alioth/debian-med_git/build-area/gbrowse-2.54+dfsg/t/../lib/Bio/Graphics/Browser2/DataSource.pm line 963, near "''}" Global symbol "$self" requires explicit package name (did you forget to declare "my $self"?) at /home/andreas/debian-maintain/alioth/debian-med_git/build-area/gbrowse-2.54+dfsg/t/../lib/Bio/Graphics/Browser2/DataSource.pm line 971, line 192. Global symbol "$symbolic_db_name" requires explicit package name (did you forget to declare "my $symbolic_db_name"?) at /home/andreas/debian-maintain/alioth/debian-med_git/build-area/gbrowse-2.54+dfsg/t/../lib/Bio/Graphics/Browser2/DataSource.pm line 971, line 192. Global symbol "$length" requires explicit package name (did you forget to declare "my $length"?) at /home/andreas/debian-maintain/alioth/debian-med_git/build-area/gbrowse-2.54+dfsg/t/.. ... > iva Build + Testsuite OK. > libbio-graphics-perl Builds when using libbio-coordinate-perl #848509 > libchado-perl Build + Testsuite OK. > libgo-perl Build + Testsuite OK. > libtfbs-perl Build + Testsuite OK. > ncbi-epcr Builds > predictprotein Builds > roary Build, however when trying to simulate the test suite via cd t/data/genbank_gbff roary -f out *.gff Please cite Roary if you use any of the results it produces: Andrew J. Page, Carla A. Cummins, Martin Hunt, Vanessa K. Wong, Sandra Reuter, Matthew T. G. Holden, Maria Fookes, Daniel Falush, Jacqueline A. Keane, Julian Parkhill, "Roary: Rapid large-scale prokaryote pan genome analysis", Bioinformatics, 2015 Nov 15;31(22):3691-3693 doi: http://doi.org/10.1093/bioinformatics/btv421 Pubmed: 26198102 Use of uninitialized value in require at /usr/lib/x86_64-linux-gnu/perl/5.24/Encode.pm line 61. This does not look good even if it does not look related to BioPerl. > velvetoptimiser Builds So as far as I can see if we can solve the gbrowse issue the migration to 1.7.1 seems possible. What do you think? Kind regards Andreas. -- http://fam-tille.de
Bug#848509: ITP: libbio-coordinate-perl -- BioPerl modules for working with biological coordinates
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libbio-coordinate-perl Version : 1.7.1 Upstream Author : Heikki Lehvaslaiho * URL : http://search.cpan.org/dist/Bio-Coordinate/ * License : Perl Programming Lang: Perl Description : BioPerl modules for working with biological coordinates The Bioperl project is a coordinated effort to collect computational methods routinely used in bioinformatics into a set of standard CPAN-style, well-documented, and freely available Perl modules. . Since BioPerl version 1.7 several modules where split into separate projects. This package provides the Bio::Coordinate module for working with biological coordinates. Remark: Due to the the refactoring of BioPerl which has split out several modules the package libbio-graphics-perl does not build from source any more (see #848105). I have verified that this build issue can be fixed if libbio-coordinate-perl is available. The package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/libbio-coordinate-perl.git
Bug#848497: src:biomaj: New upstream version available
Package: src:biomaj Severity: normal Hi, the watch file of our biomaj package points to http://biomaj.gforge.inria.fr/download.php but I realised that there is a complete rewrite available at PyPi https://pypi.python.org/pypi/biomaj I think we should switch to the new version but I'll leave the decision for the switch to Olivier who has insider knowledge about this package. Kind regards Andreas. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: [MoM] deepnano getting info from maintainer
Hi Çağrı, On Sat, Dec 17, 2016 at 08:06:00AM +0300, Çağrı ULAŞ wrote: > > I push some changes for deepnano. Used a few poretools data for the > deepnano-data because poretools use pybuild for packaging. When I create > new package in control file (for split packaging) poretools package created > with empty package. I dont want to change the way this package builded. > Didn't find any useful example for python split packaging. Any ideas? > Currently, this way test passed. I didn't use dch for now. What should I do > next? I'll have a look later. As Afif wrote the data package is prepared and there is no real need to duplicate those larger data sets. Just a remerk: You commited a dir debian/deepnano to the Git repository. These files should not be commited since these are results of a build process. Moreover I'm a bit worried that you are not using gbp + pbuilder as recommended in the Debian policy document. Please make sure that you at least know how to do this since you should in any case once in a while check building in a pbuilder chroot. I'll report later once I checked the test using poretools data. Kind regards Andreas. -- http://fam-tille.de
Re: [MoM] deepnano getting info from maintainer
Hi, Çağrı, على الجمعـة 16 كانون الأول 2016 21:06، كتب Çağrı ULAŞ: > I push some changes for deepnano. Used a few poretools data for the > deepnano-data because poretools use pybuild for packaging. When I create > new package in control file (for split packaging) poretools package > created with empty package. I dont want to change the way this package > builded. Didn't find any useful example for python split packaging. Any > ideas? I just made this change and will upload poretools with a data package shortly. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
