Bug#949395: Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option

[Carnë Draug]

Hi Simon

This is embarassing but I found now what was the issue.  There is one
package that I installed some months ago that was not from Debian
repos and for some reason it installs /lib/libusb.  It's not even a
deb file which is why dpkg-query does not know about it.

The package in question is xiAPI, from ximea, a company for microscope
cameras https://www.ximea.com/support/wiki/apis/xiAPI .  Without the
whole working from home thing, I would have never have installed on my
computer.

I'm very sorry for the noise.  Thank you for the help, it was the
process of answering your questions, and searching for other libs that
dpkg did not know about, that made me remember this.

David

Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option

[Carnë Draug]

On Thu, 22 Oct 2020 at 21:47, Simon McVittie  wrote:
>
> On Thu, 22 Oct 2020 at 19:14:54 +0100, David Miguel Susano Pinto wrote:
>> gnome-boxes does not start.  Trying from command line, issues this error:
>>
>> $ gnome-boxes
>> gnome-boxes: symbol lookup error: 
>> /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: 
>> libusb_set_option
>>
>> Similar issue when starting qemu:
>>
>> $ qemu-system-x86_64
>> qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined 
>> symbol: libusb_set_option
>
> It starts fine on a Debian 10 system for me. According to
> /var/lib/dpkg/info/libusb-1.0-0:amd64.symbols, that symbol has been provided
> by libusb-1.0-0 since version 2:1.0.22, which you have.
>
> Do you have an older version of libusb-1.0.so.0 somewhere in the library
> search path, perhaps in /usr/local/lib?

I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0"
(provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which
seems to be what is loaded:

$ ldd /usr/bin/gnome-boxes | grep usb
libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x7f49d1393000)
libusbredirhost.so.1 =>
/usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7f49c88fb000)
libusbredirparser.so.1 =>
/usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7f49c88f00

Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker
cache), makes it load the right libusb:

$ ldd /usr/bin/gnome-boxes | grep usb
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0
(0x7fc22ff71000)
libusbredirhost.so.1 =>
/usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7fc2274b3000)
libusbredirparser.so.1 =>
/usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7fc2274a8000)

And gnome-boxes now works properly.

The thing is, I have no idea where this /lib/libusb came from.  I'm
pretty sure I didn't install anything other than debs from the
official debian repos.  dpkg-query also does not know which package
installed it:

$ dpkg-query -S /lib/libusb-1.0.so.0.1.0
dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0

I have one other Debian machine which has the same file.  Any clues
where that file came from and what it may be used for?

Thank you
David

Bug#971264: Acknowledgement (mediawiki: ParseError after 1.27.7-1~deb9u4 upgrade (blame patch for User::pingLimiter))

[Carnë Draug]

On Mon, 28 Sep 2020 08:30:55 -0400, Roberto C. Sánchez wrote:
> On Mon, Sep 28, 2020 at 01:24:09PM +0100, carandraug wrote:
>>
>> Dear Maintainer,
>>
>> After the update to 1.27.7-1~deb9u4 (from 1.27.7-1~deb9u3), the mediawiki 
>> site
>> errors in all pages with:
>>
>> Exception encountered, of type "ParseError"
>>
> Thanks for the report.  An update to fix this is being prepared and
> should be published later today.

I just upgraded to deb9~5 and I can confirm it has fixed the issue.  Thank you

Bug#929506: gbrowse FTBFS: tests fail

[Carnë Draug]

On Tue, 9 Jul 2019 at 16:56, Andreas Tille  wrote:
>
> Hi Carnė,
>
> On Tue, Jul 09, 2019 at 04:53:31PM +0100, Carnė Draug wrote:
> > On Tue, 9 Jul 2019 at 10:33, Andreas Tille  wrote:
> > >
> > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz
> >
> > I have checked the output from that link and it's getting a lot of
> > "Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to
> > install the Bio::DB::SeqFeature::Store module)" and another for
> > Bio::DB::GFF.
> >
> > These module used to be part of the BioPerl distribution but has been
> > moved out to their own distribution, both of which have already been
> > released.
> >
> > Their distributions are:
> >
> >   Bio-DB-SeqFeature [1,2]
> >   Bio-DB-GFF [3,4]
> >
> > [1] https://github.com/bioperl/Bio-DB-SeqFeature/
> > [2] https://metacpan.org/release/Bio-DB-SeqFeature
> > [3] https://github.com/bioperl/Bio-DB-GFF/
> > [4] https://metacpan.org/release/Bio-DB-GFF
>
> Thanks for analysing this issue.  Do you volunteer to create these
> packages?

Hi Andreas

I'm sorry but I won't be able to take over those packages.

I don't expect there to be anything specially tricky about them
though, they're pretty standard perl distributions.  Both of them have
both perl 5 modules and programs which might need to split into two
debian packages.  Here's some notes from my side (I helped preparing
the bioperl releases):

* Bio-DB-SeqFeature is depependent on Bio-DB-GFF (I have this on my
  personal notes but I'm looking at the code now and I think this is
  incorrect).

* Bio-DB-GFF is dependent on Bio-DB-BioFetch.  Bio-DB-BioFetch is also
  not packaged in Debian.

Let me know if there's issues I may be able to help with.

Bug#929506: gbrowse FTBFS: tests fail

[Carnë Draug]

On Tue, 9 Jul 2019 at 10:33, Andreas Tille  wrote:
>
> Hi Carnė,
>
> I have not checked but I could imagine that this issue is somehow
> connected to the the new upstream version of bioperl.  Since you
> intended to to restructure the bioperl packages I think this is a good
> point in time.  Since you are way more involved in bioperl than I I'd be
> more than happy if you do this fully according to your own opinion.
> Please let me know if you need any help.
> [...]
> This is also observed by reproducible builds using pbuilder:
>
> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz

I have checked the output from that link and it's getting a lot of
"Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to
install the Bio::DB::SeqFeature::Store module)" and another for
Bio::DB::GFF.

These module used to be part of the BioPerl distribution but has been
moved out to their own distribution, both of which have already been
released.

Their distributions are:

  Bio-DB-SeqFeature [1,2]
  Bio-DB-GFF [3,4]

[1] https://github.com/bioperl/Bio-DB-SeqFeature/
[2] https://metacpan.org/release/Bio-DB-SeqFeature
[3] https://github.com/bioperl/Bio-DB-GFF/
[4] https://metacpan.org/release/Bio-DB-GFF

Bug#921495: Bioperl 1.7.4 should not migrate to Buster

[Carnë Draug]

On Mon, 11 Feb 2019 at 15:47, Andreas Tille  wrote:
>
> On Mon, Feb 11, 2019 at 03:32:47PM +, Carnë Draug wrote:
> >
> > Well, all those regressions are because they can't install bioperl
> > which is their dependency.  There is no issue on themselves or in
> > upstream bioperl.  The issue is that Debian's bioperl claims to have
> > recommend dependency on bioperl-run which does not actually exist in
> > upstream anymore.
>
> OK.
>
> > > Thus I admit I see no real profit in upgrading bioperl-run at this
> > > release stage.  We could upload to experimental (Carnė, I'm explicitly
> > > encouraging you to do so if you have some interest in it).  I for
> > > myself have currently more important things on my desk since this
> > > becomes important for my only after Buster release.
> >
> > I'm not interested on bioperl-run either.  But can you remove the
> > current bioperl from sid which is causing all those issues on the
> > other packages?
>
> There is no easy way to remove a package from sid.  The only way would
> be to upload version 1.7.2 with an epoch (1:1.7.2).  Since epochs are
> ugly I would like to avoid this.  If it hurds anybody to much we might
> consider uploading bioperl-run as well.  Since it probably needs a
> versioned depends ob bioperl 1.7.4 it should not migrate to testing as
> well.  But since all these regressions are only in sid I see no real
> harm (except Ubuntu might fetch from unstable and will end up with
> broken bioperl stuff.
>
> What do you think?

All packages that depend on bioperl are being affected by this.  The
current situation is a bit awkward because packaging and testing in
sid fails even though it would be fine in testing.  This will cause
issues for new releases of such packages and for false positives in
Debian's ci.

If you do make a new bioperl-run release, you can drop the following
dependencies:

  bowtie
  bwa
  maq
  paml
  t-coffee

but should add this new one (already packaged):

  libbio-tools-run-alignment-clustalw

David

Bug#921495: Bioperl 1.7.4 should not migrate to Buster

[Carnë Draug]

On Mon, 11 Feb 2019 at 14:06, Andreas Tille  wrote:
>
> Hi Carnė,
>
> On Mon, Feb 11, 2019 at 12:59:45PM +, Carnė Draug wrote:
> > On Wed, 6 Feb 2019 at 14:06, Andreas Tille  wrote:
> > > This is what I've though about: Removing the files from bioperl-run
> > > (which would be 1.7.2-5 then)
> >
> > Upstream has released BioPerl-Run 1.7.3 which fixes this conflict
> > issue.  If someone could prepare that release that would be nice.
>
> Thanks a lot for this hint.
>
> > Like BioPerl 1.7.3, this new release of BioPerl-Run removed multiple
> > modules and so, probably not suitable for migration to Buster during
> > this transition freeze period.
>
> This is demonstrated very well here:
>
> https://tracker.debian.org/pkg/bioperl
>
> Lots of packages (not only bioperl-run) are broken by the new version.

Well, all those regressions are because they can't install bioperl
which is their dependency.  There is no issue on themselves or in
upstream bioperl.  The issue is that Debian's bioperl claims to have
recommend dependency on bioperl-run which does not actually exist in
upstream anymore.

> Thus I admit I see no real profit in upgrading bioperl-run at this
> release stage.  We could upload to experimental (Carnė, I'm explicitly
> encouraging you to do so if you have some interest in it).  I for
> myself have currently more important things on my desk since this
> becomes important for my only after Buster release.

I'm not interested on bioperl-run either.  But can you remove the
current bioperl from sid which is causing all those issues on the
other packages?

Thank you
David

Bug#921495: libbio-perl-perl: Package not upgradable, file conflicts.

[Carnë Draug]

On Wed, 6 Feb 2019 at 14:06, Andreas Tille  wrote:
> On Wed, Feb 06, 2019 at 01:18:26PM +, Carnė Draug wrote:
> > I guess the fix for this is to have in bioperl's d/control:
> >
> > Breaks: libbio-perl-run-perl (<< 1.7.3)
> >
> > It would be nice if upstream did a new release of bioperl-run soon
> > without those modules.  I have prepared the upstream repository and
> > have requested them to make a release but I don't know when it will
> > happen.
> >
> > Alternatively, you could remove those files in Debian and have a
> > bioperl-run version 1.7.2-4.
>
> This is what I've though about: Removing the files from bioperl-run
> (which would be 1.7.2-5 then)

Upstream has released BioPerl-Run 1.7.3 which fixes this conflict
issue.  If someone could prepare that release that would be nice.

Like BioPerl 1.7.3, this new release of BioPerl-Run removed multiple
modules and so, probably not suitable for migration to Buster during
this transition freeze period.

Bug#921495: libbio-perl-perl: Package not upgradable, file conflicts.

[Carnë Draug]

On Wed, 6 Feb 2019 at 10:57, Andreas Tille  wrote:
>
> Control: tags -1 help
>
> Hi David,
>
> as far as I know you are involved into bioperl and might be the most
> competent person for this problem.  I've found the following competing
> filed in bioperl and bioperl-run:
>
>
> bioperl-run(master) $ find . -name "Analysis.pm" -o -name "AnalysisFactory.pm"
> ./lib/Bio/Tools/Run/AnalysisFactory.pm
> ./lib/Bio/Tools/Run/Analysis.pm
>
> bioperl(master) $ find . -name "Analysis.pm" -o -name "AnalysisFactory.pm"
> ./lib/Bio/Tools/Run/AnalysisFactory.pm
> ./lib/Bio/Tools/Run/Analysis.pm
>
>
> Any suggestion how to deal with this sensibly?  I would expect some
> soonish release of bioperl-run which does not contain these files any
> more, but you might know better.

This is by design and is mentioned on the release Changes file:

* The following modules are new in the BioPerl distribution.  They
  have been previously released in the BioPerl-Run distribution.
  This will enable smaller distributions that provide a
  Bio::Tool::Run interface, to be only dependent on the BioPerl
  distribution instead of the whole (very large) BioPerl-Run:

  Bio::Tools::Run::Analysis
  Bio::Tools::Run::AnalysisFactory
  Bio::Tools::Run::Phylo::PhyloBase
  Bio::Tools::Run::WrapperBase
  Bio::Tools::Run::WrapperBase::CommandExts

I guess the fix for this is to have in bioperl's d/control:

Breaks: libbio-perl-run-perl (<< 1.7.3)

It would be nice if upstream did a new release of bioperl-run soon
without those modules.  I have prepared the upstream repository and
have requested them to make a release but I don't know when it will
happen.

Alternatively, you could remove those files in Debian and have a
bioperl-run version 1.7.2-4.  This might be better if upstream takes a
long time to make the paired bioperl-run release.  The reason why I
think this might be better is related to the reason why the modules
changed distribution which comes with a bit of history.

BioPerl used to be a single distribution with a lot of modules.  It
was very difficult to maintain, install, and release.  So the plan is
to split into smaller distributions of related modules.  This is the
plan for the 1.7 series of BioPerl releases.

The first split was BioPerl-Run.  This included all the modules to to
run external programs which were among the most difficult to install
and test.  But with all of them in a single distribution, if you
wanted one of those modules, you still needed to install them all.
Then, smaller distributions were made out of BioPerl-Run such as
Bio-Tools-Phylo-PAML and Bio-Tools-Run-Alignment-Clustalw.  But these
were still dependent on BioPerl-Run because the abstract base classes
required by them.

In theory, someone should have made all the small distributions of
BioPerl-Run and leave it only with the abstract base classes.  In
practice, it's like no one in upstream cares about BioPerl-Run.  So
those classes were moved back to BioPerl which means that the
individual *-Run-* distributions can be installed without the whole
BioPerl-Run.

Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP

[Carnë Draug]

On Fri, 1 Feb 2019 at 14:20, Andreas Tille  wrote:
>
> Hi,
>
> I tried to have a look at the issue caused by t-coffee 12 which became
> visible in the smoke test of libbio-tools-run-alignment-tcoffee-perl.
> Liubov had checked it before and filed an issue upstream[1] but at my
> side the test to reproduce the bug does not fail.

The t-coffee tests fail on their own.  I don't know why you can't
reproduce it.  See the results for the latest failure:


https://ci.debian.net/data/autopkgtest/unstable/amd64/t/t-coffee/1817091/log.gz

of for the previous runs:

https://ci.debian.net/packages/t/t-coffee/unstable/amd64/

> I wonder if someone
> from the Perl team would be able to iron out the actual t-coffee call
> that causes the coredump.  If we would have some
>
>t-coffee options / args
>  --> COREDUMP
>
> we could start to run this through gdb.  If I do not get any help of
> this kind I have no idea to hunt this down.
>

The results from the last autopkgtests show that it's this command
that fails:

t_coffee -aln sproteases_small.cw_aln sproteases_small.muscle \
sproteases_small.tc_aln -outfile combined_aln.aln

The test script is part of t-coffee:


https://salsa.debian.org/med-team/t-coffee/blob/master/debian/tests/run-unit-test

If the command on its own does not fail, maybe it needs to
be ran in series after the others?

Maybe not related, but something odd that I noticed is that the '='
does not appear in the log of the test suite.  While the test script
has:

-outfile=combined_aln.aln

The logs only show:

-outfile combined_aln.aln

Bug#917143: this is a t-coffee issue only, not libbio-tools-run-alignment-tcoffee-perl

[Carnë Draug]

I have reassigned this to t-coffee only.  The package
libbio-tools-run-alignment-tcoffee-perl is just a perl wrapper to the
t-coffee program, and it's t-coffee that is failing on its own.

t-coffee's own autopkgtest fails since 12.00.fb08c2-1.  See

https://ci.debian.net/packages/t/t-coffee/unstable/amd64/

Bug#883981: not a bug, this is debian specific configuration needed?

[Carnë Draug]

I went through the javadoc options looking for some way to configure
this.

I'm thinking that the way to fix this is to have a doclet (a java
class that configures how the javadocs are created) for the debian
docs.  I have no experience doing this, but going through the docs
this seems to be what would be needed.

Bug#883981: debian packages built with javadoc from openjdk >=9 include copies of javascript and css

[Carnë Draug]

This issue was originally reported with openjdk-9 but it also happens
with openjdk-10 and 11.  The initial bug report refers to jquery.js
only but with openjdk-11 it also includes jquery-ui.js, jquery-ui.css
and their minimised versions.  With openjdk-10 there was also jszip
and jszip-utils.

There's a thread on the debian-java mailing list about the issue [1]

David

[1] https://lists.debian.org/debian-java/2018/06/msg00020.html

Bug#904753: python3-wxgtk4.0: wx.glcanvas.GLCanvas causes segfault

[Carnë Draug]

On 27 July 2018 at 15:32, Scott Talbert  wrote:
> On Fri, 27 Jul 2018, David Miguel Susano Pinto wrote:
>
>> The GLCanvas class from wx causes a segfault.  This bug was not
>> present in Debian Jessie, and is also not present when installing
>> directly from upstream (although I have not yet managed to do it in
>> Debian).
>
>
> Are you running on Wayland by chance?

Seems like it.

$ loginctl show-session 2 -p Type
Type=wayland

I didn't even knew about it, this seems to be the default since I
never changed it.

Bug#790196: Rasmol needs severe contribution to stay in Debian

[Carnë Draug]

On 3 July 2018 at 14:59, Andreas Tille  wrote:
> Hi,
>
> the bug log of #790196[1] shows that rasmol in its current state will
> not be distributable with Buster.  Upstream is dead so if we want to
> keep it in Debian we have the option:
>
>1) Port it to Gtk+ 3 (see porting guide [2])
>2) Find a Gtk+ 2 replacement for libvte
>3) Give up and remove this package from Debian
>
> Since option 3 would be a shame for a package with quite some users[3]
> (at least in the field of scientific software) I'm hereby making some
> noise about this.  My recent upload updates metadata (Salsa migration),
> fixed all other bugs and most of the lintian issues.
>
> I'd be really happy if someone could spent some time into this
>
>   Andreas.
>
>
> [1] https://bugs.debian.org/790196
> [2] https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html
> [3] https://qa.debian.org/popcon.php?package=rasmol

Maybe option 3 is not that bad.  Debian also packages pymol which is
used even more [4] so it's not like rasmol users will be left without an
alternative.

David

[4] https://qa.debian.org/popcon.php?package=pymol

Bug#871660: ITP: fairsim -- ImageJ plugin for SIM reconstruction

[Carnë Draug]

On 10 August 2017 at 15:28, Yanhao Mo <yanha...@gmail.com> wrote:
> Maybe your name listed at the Owner field using wrong encoding. because
> it's showing "=?utf-8?q?Carn=C3=AB_Draug?=". Is it correct?

It is not.  The name should be Carnë Draug.  It was automatically picked
by reportbug from DEBFULLNAME though.  Not sure if it's a bug somewhere.

Carnë

Bug#876374: ITP: libdist-zilla-plugin-modulebuildtiny-fallback-perl -- Dist::Zilla plugin that generates a Build.PL with fallback on Module::Build

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug <carandraug+...@gmail.com>

* Package name: libdist-zilla-plugin-modulebuildtiny-fallback-perl
  Version : 0.025
  Upstream Author : Karen Etheridge <et...@cpan.org>
* URL : 
https://metacpan.org/release/Dist-Zilla-Plugin-ModuleBuildTiny-Fallback
* License : perl 5
  Programming Lang: Perl
  Description : Dist::Zilla plugin that generates a Build.PL with fallback 
on Module::Build

 Dist::Zilla::Plugin::ModuleBuildTiny::Fallback is a Dist::Zilla
 plugin that provides a Build.PL in your distribution that attempts to
 use Module::Build::Tiny when available, falling back to Module::Build
 when it is missing and printing a warning about it.
 .
 This is useful when your distribution is installing on an older perl
 (before approximately 5.10.1) with a toolchain that has not been
 updated, where configure_requires metadata is not understood and
 respected -- or where Build.PL is being run manually without the user
 having read and understood the contents of META.yml or META.json.

Bug#876292: ITP: libdist-zilla-plugin-makemaker-fallback-perl -- Dist::Zilla plugin that generates a Makefile.PL with deprecation warnings

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: = Carnë Draug <carandraug+...@gmail.com>

* Package name: libdist-zilla-plugin-makemaker-fallback-perl
  Version : 0.023
  Upstream Author : Karen Etheridge <et...@cpan.org>
* URL : 
https://metacpan.org/release/Dist-Zilla-Plugin-MakeMaker-Fallback
* License : perl 5
  Programming Lang: Perl
  Description : Dist::Zilla plugin that generates a Makefile.PL with 
deprecation warnings

 Dist::Zilla::Plugin::MakerMaker::Fallback is a Dist::Zilla plugin
 that will generate a Makefile.PL as fallback to a Build.PL.  The
 Makefile.PL will issue a warning about using a legacy toolchain,
 since modern tools will default to Build.PL.

Bug#876289: ITP: libdist-zilla-plugin-makemaker-awesome-perl -- Dist::Zilla plugin with more options than [MakeMaker]

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug <carandraug+...@gmail.com>

* Package name: libdist-zilla-plugin-makemaker-awesome-perl
  Version : 0.38
  Upstream Author : Karen Etheridge <et...@cpan.org>
* URL : 
https://metacpan.org/release/Dist-Zilla-Plugin-MakeMaker-Awesome
* License : perl 5
  Programming Lang: Perl
  Description : Dist::Zilla plugin with more options than [MakeMaker]

 Dist::Zilla::Plugin::MakeMaker::Awesome is a Dist::Zilla plugin that
 generates a Makefile.PL making use of ExtUtils::MakeMaker.  It is
 similar to the Dist::Zilla::Plugin::MakeMaker, and is actually a
 subclass of it, but provides several options to run custom code on
 the generated Makefile.PL.

Bug#876287: ITP: libdist-zilla-plugin-modulebuildtiny-perl -- Dist::Zilla plugin to create a Build.PL that uses Module::Build::Tiny

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug <carandraug+...@gmail.com>

* Package name: libdist-zilla-plugin-modulebuildtiny-perl
  Version : 0.015
  Upstream Author : Leon Timmermans <faw...@gmail.com>
* URL : 
https://metacpan.org/release/Dist-Zilla-Plugin-ModuleBuildTiny
* License : perl 5
  Programming Lang: Perl
  Description : Dist::Zilla plugin to create a Build.PL that uses 
Module::Build::Tiny

Dist::Zilla::Plugin::ModuleBuildTiny is a Dist::Zilla plugin to create
a Build.PL file that makes use of Module::Build::Tiny.  It provides an
alternative to Dist::Zilla::Plugin::ModuleBuild which would create a
Build.PL files that makes use of Module::Build as the underlying build
system.

Bug#876273: ITP: libdist-zilla-plugin-checkbin-perl -- Dist::Zilla plugin for checking command at build time

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug <carandraug+...@gmail.com>

* Package name: libdist-zilla-plugin-checkbin-perl
  Version : 0.007
  Upstream Author : Karen Etheridge <et...@cpan.org>
* URL : https://metacpan.org/release/Dist-Zilla-Plugin-CheckBin
* License : Perl_5
  Programming Lang: Perl
  Description : Dist::Zilla plugin for checking command at build time

Dist::Zilla::Plugin::CheckBin is a Dist::Zilla plugin that modifies
the Makefile.PL or Build.PL in your distribution to contain a
Devel::CheckBin call, that asserts that a particular command is
available. If it is not available, the program exits with a status of
zero, which on a CPAN Testers machine will result in a NA result.

Bug#874800: lintian: wish a lintian check for javadoc links

[Carnë Draug]

Package: lintian
Version: 2.5.50.4
Severity: wishlist

Packages of java libraries are often paired with *-doc packages
which include the matching javadoc.  This javadocs have links to
the javadocs of external referenced classes.  On the wild wild
internet, this usually links to the docs website of the package
that implements this external class but this is configurable.  In
Debian, these are configured to link to the javadocs of the local
filesystem.

However, it's very easy to misconfigure the links and would be
nice if lintian could identify this issue.  Two problems may
happen if these are misconfigured:

  1) links are not created

  2) links get created automatically to some website on the
 internet.  This is the case with maven --- a common build
 system for java projects --- which automatically guesses the
 links even in the absence of internet connection during the
 build.

However, I am unsure on how best to test this.  As far as I know,
there is no file listing the used external classes.  For the case
where links are created to external websites, the only method I
can see is to parse the html for href that end
in "?is-external=true" and check if they are an http link.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  file  1:5.30-1+deb9u1
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.24
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1-3+deb9u1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-1
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-3+deb9u1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#873211: lintian: does not warn about .class binaries

[Carnë Draug]

On 25 August 2017 at 16:20, Chris Lamb  wrote:
> Hi Carnë,
>
>> While improving the packaging of a Debian package, I found that the
>> source release included .class files
>
> I guess we should be explicit about the problem we are trying to
> solve here; ie. which of:
>
> a) That upstream ships .class files to begin with (which I worry and
> suspect might be rather common in Java packages?)
>
> b) We ship binary packages with .class files. This is not only quite
> common from a quick grep, but it's not that much different from shipping
> a .jar, surely?
>
> c) We don't recompile whatever .class files end up in the binary,
> potentially meaning we are missing the source, etc.
>
> :)
>

Hi Chris

The problem I'm reporting is c), the files are not recompiled.

In the case where I found this issue (imagej package), the debian
binary release included the class files as compiled by upstream.  The
supposed source is available but 1) their build system is configure to
skip those class files during compilation and simply and just copy
them for the jar file, and 2) they are dependent on MacOS java
extensions and so can't even be built in the first place.

This is not a bug report against the imagej package, I have already
fixed this issue there [1], which is why I didn't go into details.  It
would just be nice if lintian could have caught this before since
apparently this has been an issue on this package for a very long
time.

Also, sicne you mention that b) is common, the java policy [2] states
that class files should be packaged inside a jar file so I guess it
shouldn't be common so maybe it should be checked for by lintian too?

Thank you
Carnë

[1] 
https://anonscm.debian.org/cgit/debian-med/imagej.git/tree/debian/patches/drop-mac-plugins.patch
[2] https://www.debian.org/doc/packaging-manuals/java-policy/c50.html

Bug#873211: lintian: does not warn about .class binaries

[Carnë Draug]

Package: lintian
Version: 2.5.50.4
Severity: normal

Dear Maintainer,

While improving the packaging of a Debian package, I found that the
source release included .class files (pre compiled java files).  Those
.class files were also part of the upstream release.  These upstream
compiled files were also included in the binary release.

While running lintian, I saw no warning about their presence.  This
can be reproduced with the imagej package 1.51i+dfsg-2 or older.

Best Regards,
Carnë

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  file  1:5.30-1
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.24
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1-3+deb9u1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-1
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-3+deb9u1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#655420: ITP: jtransforms -- A multithreaded FFT library written in pure Java

[Carnë Draug]

On 20 August 2017 at 17:57, Ghislain Vaillant  wrote:
> On 20/08/17 15:25, Andreas Tille wrote:>
>>
>> please consider packaging this in either Debian Science or pkg-java
>> team.
>
>
> I'd recommend the Java Team for this one and read Markus' tutorial for maven
> [1] before debianizing. The source package should be named
> libjtransforms-java.
>
> [1]
> http://collab.debian.net/portal/planet-debian/markus-koschany-pdfsam-how-to-upgrade-a-maven-application-for-debian
>
> Ghis

Hi everyone

I have already packaged it for pkg-java team.  See
https://github.com/carandraug/debian-libjtransforms-java

If you want to try it, it is dependent on JLargeArrays which I have
also packaged.  See
https://github.com/carandraug/debian-libjlargearrays-java

I am packaging this because they are dependencies of fairsim [2] which
I have already started to package.

None of these are uploaded because pkg-java team prefers I finish
packaging fairsim first and then upload all three at same time.

Carnë

[2] http://fairsim.github.io/

Bug#871660: ITP: fairsim -- ImageJ plugin for SIM reconstruction

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: fairsim
  Version : 1.2.0
  Upstream Author : Marcel Müller 
* URL : https://fairsim.github.io/
* License : GPL-2+
  Programming Lang: Java
  Description : ImageJ plugin for SIM reconstruction

Structured Illumination Microscopy (SIM) is a super resolution
microscopy technique.  Widefield images with varying illumination
patterns are acquired and then reconstructed with increased
spatial resolution.  fairSIM implements the reconstruction
algorithm by Gustaffson and Heintzmann.

Bug#655420: ITP: jtransforms -- A multithreaded FFT library written in pure Java

[Carnë Draug]

Package: wnpp
Followup-For: Bug #655420
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

Bug#868330: ITP: libalgorithm-svm-perl -- bindings for the libsvm Support Vector Machine library

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libalgorithm-svm-perl
  Version : 0.13
  Upstream Author : Matthew Laird 
* URL : https://metacpan.org/release/Algorithm-SVM
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : bindings for the libsvm Support Vector Machine library

 Algorithm::SVM implements a Support Vector Machine for Perl. Support Vector
 Machines provide a method for creating classifcation functions from a set of
 labeled training data, from which predictions can be made for subsequent data
 sets.

This is package is mainly abandoned upstream but is a dependency
(currently vendorized) of psortb for debian-med.

Bug#868234: googletest: please provide libgtest (now enabled by upstream)

[Carnë Draug]

Package: googletest
Version: 1.8.0-6
Severity: normal

Dear Maintainer,

googletest recommended against a system-wide installation of gtest and
disabled the install target on their build system.  While it seems
they maintain this odd recommendation, they have backtracked on
disabling the installation and since version 1.8 have added install
rules for cmake.

Despite the upstream recommended best practice that each project
should build gtest from source, it would be nice if the shared
libraries were also provided by Debian.  This would enable Debian to
build packages that follow the more common approach of having libgtest
available.  Also, providing a libgtest package would not exclude
continuing to have the sources in the googletest package for projects
that do want to build it from source.

The reason for my request is that I am now packaging a series of
packages into Debian that make use of gtest and they expect to find
one available in the system.  It seems a bit silly having to build it
again for each of them, not to mention patching their build system to
use local sources instead.

CentOS 6 (gtest 1.5), CentOS 7 (gtest 1.6), Fedora 26 (gtest 1.7), and
FreeBSD 10.3 and 11.0 (gtest 1.7), all provide libtest too despite
upstream recommendation.

I get that upstream has its own opinion on how things should be done,
I can patch projects to build googletest so it builds in Debian, and I
understand how the current Debian packages follows upstream
recommendation.  However, I think it's easy to understand how someone
might disagree with upstream, and it would only make Debian better if
a shared library would also be provided for such projects.

Thank you
Carnë

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages googletest depends on:
ii  python  2.7.13-2

googletest recommends no packages.

googletest suggests no packages.

-- no debconf information

Bug#867920: ITP: libjlargearrays-java -- Java library for one dimensional arrays up to 2^63 elements

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libjlargearrays-java
  Version : 1.6
  Upstream Author : Piotr Wendykier 
* URL : https://gitlab.com/ICM-VisLab/JLargeArrays
* License : BSD-2-Clause
  Programming Lang: Java
  Description : Java library for one dimensional arrays up to 2^63 elements

Current implementations of Java Virtual Machines allow the creation of
one-dimensional arrays of length smaller than 2^31 elements.
JLargeArrays addresses the problem of maximal size of one-dimensional
Java arrays providing classes that can store up to 2^63 primitive
elements.

JLargeArrays provides the abstract class for primitive types, as well
as the non abstract classes for Number classes, String, bit values,
complex numbers, and objects.  It also supports subarrays.

This package is a common dependency on scientific java software where
the 2^31 number of elements is a common issue.

Bug#866748: ITP: libome-common -- C++ library providing common functionality to other OME C++ projects

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug <carandraug+...@gmail.com>

* Package name: libome-common
  Version : 5.4.0
  Upstream Author : Open Microscopy Environment 
<ome-us...@lists.openmicroscopy.org.uk>
* URL : https://www.openmicroscopy.org/site/products/ome-files-cpp
* License : BSD-2-Clause
  Programming Lang: C++
  Description : C++ library providing common and portability functionality 
for all OME C++ components

OME Common is a standalone C++ library required by other OME C++
projects for common functionality which is not readily available from
the C++ Standard Library.  This includes basic portability functions,
to wrapping other libraries to make them usable with Modern C++
programming practices.

It serves a similar purpose to the OME formats-common Java library,
with some shared functionality, though for the most part they are
quite different.

---

This package is a basic dependency for ome-files, the C++ implementation
of a writer of the OME model.

I plan to maintain it as part of my day to day job.  I believe that
the debian-med packaging team to be a goof fit though as the follow
up on this package is the rest of the ome packages, starting with
ome-files, then bioformats, then omero to provide a complete suite
for management of biological microscopy data.

Bug#862352: RFP: libsystem-info-perl -- package·to·obtain·basic·system·information

[Carnë Draug]

Package: wnpp
Severity: wishlist

* Package name: libsystem-info-perl
  Version : 0.054
  Upstream Author : H.Merijn·Brand·
* URL : https://metacpan.org/release/System-Info
* License : Artistic·or·GPL-1+
  Programming Lang: Perl
  Description : package·to·obtain·basic·system·information

System::Info·tries·to·present·system-related·information,·like·number   


of·CPUs,·architecture,·OS,·and·release·related·information·in·a 


system-independent·way.··This·releases·the·user·of·thos·module·of·the   


need·to·know·if·the·information·comes·from·Windows,·Linux,·HP-UX,   


AIX,·Solaris,·Irix,·or·VMS,·and·if·the·architecture·is·i386,·x64,   


pa-risc2,·or·arm.

Bug#778917: texlive-latex-extra: missing dependency - textgreek.sty requires lgrenc.def (texlive-lang-greek)

[Carnë Draug]

Package: texlive-latex-extra
Version: 2016.20170123-5
Followup-For: Bug #778917

On 21 Feb 2015 21:01:04 +0100, Hilmar Preuße wrote:
> On 21.02.2015 20:18, carandraug wrote:
>
> Hi,
>
>> The Tex textgreek package is part of the texlive-latex-extra debian package.
>> This Tex package depends on lgrenc.def which in Debian, is part of the Debian
>> texlive-lang-greek package.  This package should then be listed as a
>> dependency for texlive-latex-extra but it is not.
>
> Hmm. texlive-latex-extra has size of 33MB. texlive-lang-greek has a size 
> of 88MB. Forcing users to download and install 88MB just for a def file 
> having a size of 37KB won't make us friends.
> Norbert, could you discuss this w/ upstream. Maybe moving the 
> "greek-fontenc" TeX package to an extra TeX Live package?
>
> Hilmar

This issue is still present on Debian Stretch.  It was not a problem
on Wheezy because lgrenc.def was part of texlive-latex-base.

I understand trying to avoid the 88MB dependency but at the moment
that means that the textgreek package in texlive-latex-extra is
broken which I would arguee is worse.

Carnë

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.90-1
ii  tex-common 6.06
ii  texlive-base   2016.20170123-5
ii  texlive-binaries   2016.20160513.41080.dfsg-2
ii  texlive-latex-recommended  2016.20170123-5
ii  texlive-pictures   2016.20170123-5

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2016.20170123-5
ii  texlive-generic-extra  2016.20170123-5
ii  texlive-latex-extra-doc2016.20170123-5

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.21-1
ii  libspreadsheet-parseexcel-perl  0.6500-1
ii  python-pygments 2.2.0+dfsg-1

Versions of packages tex-common depends on:
ii  dpkg  1.18.23
ii  ucf   3.0036

Versions of packages tex-common suggests:
ii  debhelper  10.2.5

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.06
ii  texlive-binaries  2016.20160513.41080.dfsg-2

-- no debconf information

Bug#856532: Error: Can't locate object method "get_user"

[Carnë Draug]

On 3 March 2017 at 18:09, gregor herrmann  wrote:
> On Thu, 02 Mar 2017 22:22:01 +0100, gregor herrmann wrote:
>
>> > == dh-make-perl 0.93 ==
>> > Trying /PATH/TO/MODULE/DISTRIBUTION/Dn-Role-v0.1/../Dn-Role-v0.1.tar 
>> > .gz... found!
>> > Using META.json
>> > Found: Dn-Role 0.1 (libdn-role-perl arch=all)
>> > Can't locate object method "get_user" via package 
>> > "DhMakePerl::Command::make" at 
>> > /usr/share/perl5/DhMakePerl/Command/Packaging.pm line 130.
>
>> Carnë, this seems to be a side effect of
>> 23b15bd799ee7e7f9394119a98bdef510424be3d.
>> Could you take a look please? (I'm not sure what the best fix would
>> be that fits your refactoring.)
>
> How about this change?
>
> diff --git a/lib/DhMakePerl/Command/Packaging.pm 
> b/lib/DhMakePerl/Command/Packaging.pm
> index 690740a..c54942b 100644
> --- a/lib/DhMakePerl/Command/Packaging.pm
> +++ b/lib/DhMakePerl/Command/Packaging.pm
> @@ -119,6 +119,12 @@ sub makefile_pl {
>  return $self->main_file('Makefile.PL');
>  }
>
> +sub get_user {
> +my $self = shift;
> +my $user = $ENV{LOGNAME} || $ENV{USER};
> +return $user;
> +}
> +
>  sub get_email {
>  my $self = shift;
>  my $email = $self->cfg->email;
> @@ -138,7 +144,7 @@ sub get_name {
>  my $self = shift;
>
>  my $name;
> -my $user = $ENV{LOGNAME} || $ENV{USER};
> +my $user = $self->get_user;
>  my $pwnam = getpwuid($<);
>  die "Cannot determine current user\n" unless $pwnam;
>  if ( defined $ENV{DEBFULLNAME} ) {
>
>
> An alternative would be to drop the non-existing get_user() call from
> get_email() and use
> my $user = $ENV{LOGNAME} || $ENV{USER};
> $email = $user ...
> there; but this duplicates the user setting.

The new function get_user that you proposed sounds good to me.  I
pushed that change.  Sorry for causing this silly bug.

https://anonscm.debian.org/cgit/pkg-perl/packages/dh-make-perl.git/commit/?id=c8fb32794a028597cc1543d84f5728f4c32f

Carnë

Bug#854046: dh-make-perl: Incorrect dependencies created from List::Util

[Carnë Draug]

Package: dh-make-perl
Version: 0.93
Severity: normal

dh-make-perl creates this weird dependency line if there is
a dependency on List::Util:

 libperl5.24:amd64 (>= 1.45) | libscalar-list-utils-perl (>= 1.45) | perl-base 
(>= 1.45)

I believe the dependency on perl >= 1.45 is actually a reference to
libscalar-list-utils-perl.  I have noticed this when packaging like:

dh-make-perl --pkg-perl --cpan 
Dist::Zilla::Role::PluginBundle::PluginRemover

which should be enough to replicate the issue.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-make-perl depends on:
ii  debhelper  10.2.3
ii  dpkg-dev   1.18.18
ii  fakeroot   1.21-3.1
ii  libapt-pkg-perl0.1.30
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.34-1
ii  libconfig-ini-perl 1:0.025-1
ii  libdebian-source-perl  0.92
ii  libdpkg-perl   1.18.18
ii  libemail-address-perl  1.908-1
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.21-1
ii  liblist-moreutils-perl 0.416-1+b1
ii  libmodule-depends-perl 0.16-3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libsoftware-license-perl   0.103012-1
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libyaml-libyaml-perl   0.63-2
ii  libyaml-perl   1.21-1
ii  make   4.1-9
ii  perl   5.24.1-1
ii  perl-modules-5.22 [libcpan-meta-perl]  5.22.2-1
ii  perl-modules-5.24 [libcpan-meta-perl]  5.24.1-1

Versions of packages dh-make-perl recommends:
ii  apt   1.4~beta4
ii  apt-file  3.1.4
ii  git   1:2.11.0-2
ii  libdpkg-parse-perl0.03-1
ii  libmodule-build-perl  0.422000-1
ii  pristine-tar  1.37

dh-make-perl suggests no packages.

-- no debconf information

Bug#853984: ITP: libdist-zilla-role-pluginbundle-config-slicer-perl -- Dist::Zilla plugin to pass portions of bundle config to its plugins

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-role-pluginbundle-config-slicer-perl
  Version : 0.201
  Upstream Author : Randy Stauner 
* URL : https://metacpan.org/release/Dist-Zilla-Config-Slicer
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Dist::Zilla plugin to pass portions of bundle config to its 
plugins

Dist::Zilla::Role::PluginBundle::Config::Slicer enables a Dist::Zilla
plugin bundle to accept configuration customizations for the plugins
it will load and merge them transparently.

Bug#853983: ITP: libdist-zilla-role-pluginbundle-pluginremover-perl -- Dist::Zilla plugin to add '-remove' functionality to a bundle

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-role-pluginbundle-pluginremover-perl
  Version : 0.104
  Upstream Author : Randy Stauner 
* URL : 
https://metacpan.org/release/Dist-Zilla-Role-PluginBundle-PluginRemover
* License : Artistics or GPL-1+
  Programming Lang: Perl
  Description : Dist::Zilla plugin to add '-remove' functionality to a 
bundle

Dist::Zilla::Role::PluginBundle::PluginRemover enables Dist::Zilla
plugin bundles to automatically remove any plugins specified by the
-remove attribute.  This is similar to the @Filter plugin but with
less typing.

Bug#853982: ITP: libconfig-mvp-slicer-perl -- Extract embedded plugin config from parent config

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libconfig-mvp-slicer-perl
  Version : 0.302
  Upstream Author : Randy Stauner 
* URL : https://metacpan.org/release/Config-MVP-Slicer
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Extract embedded plugin config from parent config

Config::MVP::Slicer can be used to extract embedded configurations
for other plugins out of larger (parent) configurations.  An example
where this can be useful is plugin bundles (see
Config::MVP::Assembler::WithBundles).  A bundle loads other plugins
with a default configuration that works most of the time, but
sometimes you wish you could customize the configuration for one of
those plugins without having to remove the plugin from the bundle and
re-specify it separately.

Bug#853229: ITP: libdist-zilla-plugin-readmefrompod-perl -- Dist::Zilla plugin to generate a README from Pod

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-plugin-readmefrompod-perl
  Version : 0.35
  Upstream Author : Fayland Lam 
* URL : https://metacpan.org/release/Dist-Zilla-Plugin-ReadmeFromPod
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Dist::Zilla plugin to generate a README from Pod

Dist::Zilla::Plugin::ReadmeFromPod is a Dist::Zilla plugin that
generates a README from a specific module using Pod::Readme.  It
supports the conversion to "html", "pod", "markdown" and "rtf"
formats.

Bug#853217: ITP: libpod-weaver-section-legal-complicated-perl -- Pod::Weaver plugin for Pod sections of authors, copyright holders, and licenses

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= <carandraug+...@gmail.com>

* Package name: libpod-weaver-section-legal-complicated-perl
  Version : 1.21
  Upstream Author : Carnë Draug <cdr...@cpan.org>
* URL : 
https://metacpan.org/release/Pod-Weaver-Section-Legal-Complicated
* License : GPL-3+
  Programming Lang: Perl
  Description : Pod::Weaver plugin for Pod sections of authors, copyright 
holders, and licenses

Pod::Weaver::Section::Legal::Complicated is a Pod::Weaver plugin to
create Pod sections listing authors, copyright owners, and licenses
of each module in the distribution.  It is targeted at distributions
with a large number of modules and where different module may have
different authos, copyright holders, and licenses.  It does so by
parsing individual modules and looking for specific comments.

Bug#853215: ITP: libpod-weaver-section-contributors-perl -- Pod::Weaver plugin for a section listing contributors

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-section-contributors-perl
  Version : 0.009
  Upstream Author : Keedi Kim 
* URL : https://metacpan.org/release/Pod-Weaver-Section-Contributors
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod::Weaver plugin for a section listing contributors

Pod::Weaver::Section::Contributors provides a Pod::Weaver plugin to
generate a section listing modules contributors.  These can be named
on the source of individual modules as well as on the pod weaver and
dist zilla configuration files.

Bug#853212: ITP: libpod-weaver-plugin-ensureuniquesections-perl -- Pod::Weaver plugin to check for duplicate Pod section headers

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-plugin-ensureuniquesections-perl
  Version : 0.163250
  Upstream Author : Ryan C. Thompson 
* URL : 
https://metacpan.org/release/Pod-Weaver-Plugin-EnsureUniqueSections
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod::Weaver plugin to check for duplicate Pod section 
headers

Pod::Weaver::Plugin::EnsureUniqueSections is a Pod::Weaver plugin to
ensure that the Pod after weaving has no duplicate top-level section
headers.  This can help you if you are converting from writing all
your own POD to generating it with Pod::Weaver.  If you begin
generating a section with Pod::Weaver but you forget to delete the
manually written section of the same name, this plugin will warn you.

Bug#853191: ITP: libpod-weaver-section-generatesection-perl -- Pod::Weaver plugin

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= <carandraug+...@gmail.com>

* Package name: libpod-weaver-section-generatesection-perl
  Version : 1.02
  Upstream Author : Carnë Draug <carandraug+...@gmail.com>
* URL : 
https://metacpan.org/release/Pod-Weaver-Section-GenerateSection
* License : GPL-3+
  Programming Lang: Perl
  Description : Pod::Weaver plugin to add Pod sections from a template text.

Pod::Weaver::Section::GenerateSection provides a Pod::Weaver plugin
to introduce a Pod section in the distribution modules.  This section
is generated from a template text where multiple variables can be
expanded to the values in the distribution metadata.

Bug#853190: ITP: libpod-elemental-transformer-list-perl -- Pod transformer to convert :lists sections to standard Pod lists

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-elemental-transformer-list-perl
  Version : 0.102000
  Upstream Author : Ricardo SIGNES 
* URL : https://metacpan.org/release/Pod-Elemental-Transformer-List
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod transformer to convert :lists sections to standard Pod 
lists

Pod::Elemental::Transformer::List is a transformer for a
Pod::Elemental::Document which produces traditional Pod5 lists
(=over / =item / =item / =back) from an alternative more compact
syntax.

Bug#852848: dh-make-perl: fix Repository in d/upstream/metadata for github projects

[Carnë Draug]

Package: dh-make-perl
Version: 0.92
Severity: normal
Tags: patch

The Respository URL in d/upstream/metadata should use https and not
git but dh-make-perl does not identify this issue.  The attached
patch identifies this and fixes it for github (I am unsure if the fix
can be generalized for any host but I guess it is possible for a host
to support git:// and not http://).  It also automatically fill a
missing Repository-Browse for github.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-make-perl depends on:
ii  debhelper  10.2.3
ii  dpkg-dev   1.18.18
ii  fakeroot   1.21-3
ii  libapt-pkg-perl0.1.30
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.34-1
ii  libconfig-ini-perl 1:0.025-1
ii  libdebian-source-perl  0.92
ii  libdpkg-perl   1.18.18
ii  libemail-address-perl  1.908-1
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.21-1
ii  liblist-moreutils-perl 0.416-1+b1
ii  libmodule-depends-perl 0.16-3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libsoftware-license-perl   0.103012-1
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libyaml-libyaml-perl   0.63-2
ii  libyaml-perl   1.21-1
ii  make   4.1-9
ii  perl   5.24.1~rc4-1
ii  perl-modules-5.22 [libcpan-meta-perl]  5.22.2-1
ii  perl-modules-5.24 [libcpan-meta-perl]  5.24.1~rc4-1

Versions of packages dh-make-perl recommends:
ii  apt   1.4~beta3
ii  apt-file  3.1.3
ii  git   1:2.11.0-2
ii  libdpkg-parse-perl0.03-1
ii  libmodule-build-perl  0.422000-1
ii  pristine-tar  1.37

dh-make-perl suggests no packages.

-- no debconf information
From 8627d079c027584d2edb3ee2e0293d4b412fa697 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carn=C3=AB=20Draug?= <carandraug+...@gmail.com>
Date: Fri, 27 Jan 2017 19:46:25 +
Subject: [PATCH] Fix github Repository* on d/upstream/metadata (git://, and no
 Browser)

* DhMakePerl::Command::Packaging (create_upstream_metadata):
automatically fix Repository with git protocol and missing
Repository-Browse when host is github.
---
 debian/changelog|  6 +-
 lib/DhMakePerl/Command/Packaging.pm | 28 
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f74f951..3233a5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,10 @@
 dh-make-perl (0.94) UNRELEASED; urgency=medium
 
-  * 
+  [ Carnë Draug ]
+  * DhMakePerl::Command::Packaging (create_upstream_metadata):
+automatically fix Repository with git protocol and missing
+Repository-Browse when host is github.  Done to support further
+logic on automatic fixes.
 
  -- gregor herrmann <gre...@debian.org>  Thu, 26 Jan 2017 20:29:31 +0100
 
diff --git a/lib/DhMakePerl/Command/Packaging.pm 
b/lib/DhMakePerl/Command/Packaging.pm
index 690740a..69b19db 100644
--- a/lib/DhMakePerl/Command/Packaging.pm
+++ b/lib/DhMakePerl/Command/Packaging.pm
@@ -1641,6 +1641,34 @@ sub create_upstream_metadata {
 $upstream{"Repository"}= $meta->{resources}->{repository}->{url};
 $upstream{"Repository-Browse"} = $meta->{resources}->{repository}->{web};
 
+if (defined $upstream{"Repository"}) {
+my $fix_browse = ! defined $upstream{"Repository-Browse"};
+
+my $url_parser = qr|(?:([^:/?\#]+):)? # protocol
+(?://([^/?\#]*))? # domain name
+([^?\#]*) # path
+(?:\?([^\#]*))?   # query
+(?:\#(.*))?   # fragment
+   |x;
+
+my ($protocol, $domain, $path, $query, $fragment)
+= $upstream{"Repository"} =~ $url_parser;
+
+my $host = {
+'github.com' => 'github',
+}->{$domain};
+
+if ($host eq "github") {
+if ($protocol eq "git") {
+$upstream{"Repository"} = "https://$domain$path;;
+}
+if ($fix_browse) {
+$path =~ s/\.git$//;
+$upstream{"Repository-Browse"} = "https://$d

Bug#852810: ITP: libdist-zilla-plugin-autometaresources-perl -- Dist::Zilla plugin to reduce MetaResources

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-plugin-autometaresources-perl
  Version : 1.21
  Upstream Author : Alex J. G. Burzyński 
* URL : 
https://metacpan.org/release/Dist-Zilla-Plugin-AutoMetaResources
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Dist::Zilla plugin to reduce duplication on MetaResources

Dist::Zilla::Plugin::AutoMetaResources is a Dist::Zilla MetaProvider
plugin that simplifies the addition of bugtracker and repository
"resources" to the distribution metadata.

Bug#852004: RFP for bioperl's Bio-EUtilities

[Carnë Draug]

On 27 January 2017 at 12:03, Andreas Tille  wrote:
> [dropped debian-perl list from CC]
>
> Hi Carnė,
>
> On Thu, Jan 26, 2017 at 06:12:41PM +, Carnė Draug wrote:
>> I have attached a git patch which adds a quilt patch to the repos.
>> This change inlines the DTDs in the xml files and pdebuild now
>> succeeds.
>>
>> If this change fixes it for debian, we can apply it upstream.
>
> The package builds with this patch and I have commited it to Git.
>
> Please note also commit 164117cc7c49036cf19dbab04e75f8e83db2dbdd which
> fixes the spelling of some text I've copied from your description.
>
> Please let me know whether I should wait for you fixing this upstream or
> whether I should upload with the current patch.
>

Please upload with the current patch.  We are currently fixing this
upstream [1] but it might take a while.  The reason is that while
fixing this we noticed there is no code to reproduce the xml files
used in the test suite (they are saved queries to e-utils).  I would
rather fix the whole issue with a script that downloads new xml and
inlines the DTDs than further distancing the xml in the repos from the
real e-utils replies.

> Thanks for your helpful contribution (I admit its not clear to me
> why you initially said you are not comfortable with the Debian
> packaging - providing a quilt patch is somehow quite close to
> beeing able to maintain the package ;-) )
>

When I wrote the email I wasn't comfortable.  I then spent all week at
work setting up my system and learning the Debian maintainer tools
with help from the pkg-perl team.

Carnë

[1] https://github.com/bioperl/Bio-EUtilities/issues/6

Bug#852797: ITP: libtest-mojibake-perl -- module to check source for encoding misbehavior

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libtest-mojibake-perl
  Version : 1.1
  Upstream Author : Stanislaw Pusep 
* URL : https://metacpan.org/release/Test-Mojibake
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to check source for encoding misbehavior

Many modern text editors automatically save files using UTF-8
encoding, however, perl interpreter does not expects it by default.
Whereas this does not represent a big deal on (most) backend-oriented
programs, Web framework (Catalyst, Mojolicious) based applications
will suffer of so-called Mojibake (lit. "unintelligible sequence of
characters").

Test::Mojibake lets you check for inconsistencies in source and
documentation encoding, and report its results in a standard
Test::Simple fashion.

Bug#852795: ITP: libdist-zilla-plugin-mojibaketests-perl -- Dist::Zilla plugin that provides author tests for source encoding

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-plugin-mojibaketests-perl
  Version : 0.8
  Upstream Author : Stanislaw Pusep 
* URL : https://metacpan.org/release/Dist-Zilla-Plugin-MojibakeTests
* License : Artistic or GPL+1
  Programming Lang: Perl
  Description : Dist::Zilla plugin that provides author tests for source 
encoding

Dist::Zilla::Plugin::MojibakeTests is a Dist::Zilla plugin that
provides a standard Test::Mojibake author test which checks for
inconsistencies in source and documentation encoding.

Bug#852004: RFP for bioperl's Bio-EUtilities

[Carnë Draug]

I have attached a git patch which adds a quilt patch to the repos.
This change inlines the DTDs in the xml files and pdebuild now
succeeds.

If this change fixes it for debian, we can apply it upstream.

Carnë
From 38a2038d0da47f6ac6b853b20b2934260257381d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carn=C3=AB=20Draug?= 
Date: Thu, 26 Jan 2017 18:01:49 +
Subject: [PATCH] Inline DTDs on XML files required for testsuite so no
 internet is necessary

---
 debian/patches/inline-DTDs-on-testsuite | 948 
 debian/patches/series   |   1 +
 2 files changed, 949 insertions(+)
 create mode 100644 debian/patches/inline-DTDs-on-testsuite
 create mode 100644 debian/patches/series

diff --git a/debian/patches/inline-DTDs-on-testsuite b/debian/patches/inline-DTDs-on-testsuite
new file mode 100644
index 000..589c51c
--- /dev/null
+++ b/debian/patches/inline-DTDs-on-testsuite
@@ -0,0 +1,948 @@
+Index: libbio-eutilities-perl/t/data/eutils/egquery.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/egquery.xml
 libbio-eutilities-perl/t/data/eutils/egquery.xml
+@@ -1,11 +1,21 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/egquery.dtd;>
+-
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+-
+ 
+ 
+ Notch AND Mus musculus
+Index: libbio-eutilities-perl/t/data/eutils/einfo.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/einfo.xml
 libbio-eutilities-perl/t/data/eutils/einfo.xml
+@@ -1,5 +1,35 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eInfo_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	pubmed
+Index: libbio-eutilities-perl/t/data/eutils/einfo_dbs.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/einfo_dbs.xml
 libbio-eutilities-perl/t/data/eutils/einfo_dbs.xml
+@@ -1,5 +1,35 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eInfo_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	pubmed
+Index: libbio-eutilities-perl/t/data/eutils/elink_acheck.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_acheck.xml
 libbio-eutilities-perl/t/data/eutils/elink_acheck.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_acheck_corr.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_acheck_corr.xml
 libbio-eutilities-perl/t/data/eutils/elink_acheck_corr.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_dball.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_dball.xml
 libbio-eutilities-perl/t/data/eutils/elink_dball.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_lcheck.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_lcheck.xml
 libbio-eutilities-perl/t/data/eutils/elink_lcheck.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_lcheck_corr.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_lcheck_corr.xml
 libbio-eutilities-perl/t/data/eutils/elink_lcheck_corr.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_llinks.xml
+===
+--- libbio-eutilities-perl.orig/t/data/eutils/elink_llinks.xml
 libbio-eutilities-perl/t/data/eutils/elink_llinks.xml
+@@ -1,5 +1,34 @@
+-
+-http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eLink_020511.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++]>
+ 
+ 
+ 	protein
+Index: libbio-eutilities-perl/t/data/eutils/elink_llinks_corr.xml

Bug#852004:

[Carnë Draug]

On 23 January 2017 at 22:45, gregor herrmann  wrote:
> On Mon, 23 Jan 2017 22:45:24 +0100, Andreas Tille wrote:
>
>> > The first is from a missing dependency (Bio::ASN1::EntrezGene),
>> > which is really optional (the comp test should skip that
>> > directory). The other is from XML::Simple, which is unusual; I’m
>> > wondering whether the underlying XML parser is checking the XML
>> > schema for the test reports. Any idea what the specific XML::SAX
>> > backend parser module used was?
>>
>> Sorry, I've sended a wrong version of the log with missing
>> Build-Depends.  Please check again.
>
> The tests fail for me as well, in a chroot with networking firewalled
> off.
>
> The errors are slightly different, probably because I have http_proxy
> set:
>
> http error : Operation in progress
> XML::Simple called at 
> /build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
> # Looks like your test exited with 255 before it could output anything.
> t/egquery.t .
> 1..18
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 18/18 subtests
>
> etc. for all t/e*.t tests
>
> /*
> With http_proxy unset I get:
>
> http error : Unknown IO error
> http error : connection refused
> XML::Simple called at 
> /build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
> # Looks like your test exited with 255 before it could output anything.
> t/egquery.t .
> 1..18
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 18/18 subtests
>
> */
>
> Anyway, it's quite clear that the tests try to access the internet
> which is forbidden by Debian policy (regardless of the fact if the
> fail gracefully or not), so they have to be skipped.
>
> [...]
> Of course an upstream fix, e.g. skipping tests if
> $ENV{NETWORK_TESTING} is not set etc., would be nicer.

I have managed to replicate the issue and found that it indeed comes
from XML::Simple (which Bio::EUtilities uses to parse the cml files)
and because it tries to connect to www.ncbi.nlm.nih.gov where the DTD
is.  I setup pbuilder with a hook to drop me on the chroot where the
tests were failing to investigate as described.

The only change I did was installing iptables (I guess there must
another way to block connections but I don't know how)

Everything works fine at the start in the chroot:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
# perl -MXML::Simple -e 'XMLin("t/data/eutils/egquery.xml"); print
"hello\n"'
hello
# perl -Ilib -I. t/egquery.t
1..18
[...]

After blocking connections to www.ncbi.nlm.nih.gov, things fail:

# iptables -A INPUT -s 130.14.29.110 -j DROP
# perl -MXML::Simple -e 'XMLin("t/data/eutils/egquery.xml"); print
"hello\n"'
http error : Operation in progress
http error : unreachable network
XML::Simple called at -e line 1.
# perl -Ilib -I. t/egquery.t
1..18
http error : Operation in progress
http error : unreachable network
XML::Simple called at lib/Bio/Tools/EUtilities.pm line 140.
# Looks like your test exited with 255 before it could output anything.

And dropping the iptables rule rescues the behaviour:

# perl -MXML::Simple -e 'XMLin("t/data/eutils/egquery.xml"); print
"hello\n"'
hello
# perl -Ilib -I. t/egquery.t
1..18
ok 1 - get_db
[...]

Blocking the connection but removing the DOCTYPE line from the xml
file also fixes it:

# iptables -A INPUT -s 130.14.29.110 -j DROP
# grep -n DOCTYPE t/data/eutils/egquery.xml
2:http://www.ncbi.nlm.nih.gov/entrez/query/DTD/egquery.dtd;>
# sed -ie '2d' t/data/eutils/egquery.xml
# perl -MXML::Simple -e 'XMLin("t/data/eutils/egquery.xml"); print
"hello\n"'
hello

As upstream I could inline the DTD to avoid this.  I would prefer to
avoid have them as author only tests since that would cause them to be
skipped by CPAN testers.  Any opinions?

Carnë

Bug#852618: ITP: libdist-zilla-plugin-test-compile-perl -- common tests to check syntax of your modules, using only core modules

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-plugin-test-compile-perl
  Version : 2.056
  Upstream Author : Karen Etheridge 
* URL : https://metacpan.org/release/Dist-Zilla-Plugin-Test-Compile
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : common tests to check syntax of your modules, using only 
core modules

Dist::Zilla::Plugin::Test::Compile is a Dist::Zilla plugin that runs
at the gather files (Dist::Zilla::Role::FileGatherer) stage, and
creates a test for correct perl file compilation only dependent on
core modules.

This test finds all modules and scripts in your distribution and try
to compile them one by one. This means it's a bit slower than loading
them all at once but it will catch more errors.

Bug#852467: ITP: libmoosex-types-email-perl -- Email address validation type constraints for Moose.

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libmoosex-types-email-perl
  Version : 0.007
  Upstream Author : Tomas Doran (t0m) 

Bug#852004: RFP for bioperl's Bio-EUtilities

[Carnë Draug]

On 24 January 2017 at 07:26, Andreas Tille  wrote:
> Hi Gregor,
>
> On Mon, Jan 23, 2017 at 11:45:29PM +0100, gregor herrmann wrote:
>>
>> The tests fail for me as well, in a chroot with networking firewalled
>> off.
>>
>> The errors are slightly different, probably because I have http_proxy
>> set:
>>
>> http error : Operation in progress
>> XML::Simple called at 
>> /build/libbio-eutilities-perl-1.75/blib/lib/Bio/Tools/EUtilities.pm line 140.
>> # Looks like your test exited with 255 before it could output anything.
>> t/egquery.t .
>> 1..18
>> Dubious, test returned 255 (wstat 65280, 0xff00)
>> Failed 18/18 subtests
>>
>> etc. for all t/e*.t tests
>>
>> /*
>> With http_proxy unset I get:
>
> Thanks for verifying this.
>
>> Anyway, it's quite clear that the tests try to access the internet
>> which is forbidden by Debian policy (regardless of the fact if the
>> fail gracefully or not), so they have to be skipped.
>>
>> Andreas, you already know the trick with debian/tests/pkg-perl/smoke-skip
>> and using the file in debian/rules as well to disable tests during
>> build + autopkgtest. If you don't run okg-perl-autopkgtests, you can
>> use:
>
> Yes, I know.  I simply have forwarded the issue upstream since the RFP
> came from upstream and I considered it more sensible if they provide
> some means to exclude http access directly in their code.
>
>> Of course an upstream fix, e.g. skipping tests if
>> $ENV{NETWORK_TESTING} is not set etc., would be nicer.
>
> Exactly. :-)

I will fix this upstream.  I am learning what I can about debian
packaging at the moment (with pkg-perl) by trying to release some
packages that are needed by bioperl developers (bug #852467).  I am
hoping that allow me to follow this better.

>
>> (Hm, is this the package that was discussed on #debian-perl on IRC
>> earlier yesterday? :))
>
> May be - I'm usually not on IRC ...
>

Yes, this is that package.  I asked there about what was pkg-perl
preferred method to handle network tests [1].

Carnë

[1] https://lists.debian.org/debian-med/2017/01/msg00114.html

Bug#852332: dh-make-perl: DEBFULLNAME and DEBEMAIL should be used with git

[Carnë Draug]

On 24 January 2017 at 14:19, Carnë Draug <carandraug+...@gmail.com> wrote:
> Package: dh-make-perl
> Version: 0.92
> Followup-For: Bug #852332
>
> On 24 January 2017 at 13:15, gregor herrmann <gre...@debian.org> wrote:
>> On Tue, 24 Jan 2017 12:55:10 +, Dominic Hargreaves wrote:
>>
>>> > @@ -777,7 +777,7 @@ sub git_add_debian {
>>> >
>>> >  my $git = Git->repository( $self->main_dir );
>>> >  $git->command( 'add', 'debian' );
>>> > -$git->command( 'commit', '-m',
>>> > +$git->command( 'commit', '--author', $self->get_developer, '-m',
>>> >  "Initial packaging by dh-make-perl $VERSION" );
>>> >  $git->command(
>>> >  qw( remote add origin ),
>>>
>>> This will indeed create commits with the email and name specified, but
>>> the committer address will not be overridden which is probably confusing.
>>
>> Ack.
>> Maybe setting GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL via
>> environment variables would work?
>
> There are options to git, not to git commit.  One can use:
>
> git commit -c "user.name=Foo" -c "user.email=Bar" ...
>
> Which would mean changing DhMakePerl::Command::Packaging to have
> get_email and get_name (which would then also be used by
> get_developer).  I have attached a new patch that does that.
>

That should have been:

git -c "user.name=Foo" -c "user.email=Bar" commit ...

In the mean time, I have noticed that the commits done automatically
by pristine-tar also need consideration.  Since pristine-tar does not
provide an option to set author, I used %ENV variables in that case.
I have attached a new patch.

Carnë
From 1a477bd83d2d6137c2f184bafd4aa759b64feef5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carn=C3=AB=20Draug?= <carandraug+...@gmail.com>
Date: Tue, 24 Jan 2017 15:50:02 +
Subject: [PATCH] DhMakePerl::Command::make: use author and email information
 for git commits.

DhMakePerl::Command::make (git_import_upstream__init_debian): use
email and author from dh-make-perl on git commits.
(git_add_debian): idem, but also define the required variables when
calling pristine-tar because pristine-tar does not have options to
support it.

DhMakePerl::Command::Packaging (get_name, get_email): two new methods
to retrieve only email and name because git handles them separate.

Closes: #852332
---
 Changes |  6 ++
 lib/DhMakePerl/Command/Packaging.pm | 36 +++-
 lib/DhMakePerl/Command/make.pm  | 22 +-
 3 files changed, 46 insertions(+), 18 deletions(-)

diff --git a/Changes b/Changes
index 9c47553..590adeb 100644
--- a/Changes
+++ b/Changes
@@ -1,4 +1,10 @@
 0.93 (201x-xx-xx)
+  [ Carnë Draug ]
+  * Use dh-make-perl email and name information for git commits,
+including git commits done by pristine-tar.
+(Closes: #852332)
+  * DhMakePerl::Command::Packaging: add two new methods: get_email
+and get_name.
 
 0.92 (2016-09-20)
 
diff --git a/lib/DhMakePerl/Command/Packaging.pm b/lib/DhMakePerl/Command/Packaging.pm
index d759b66..e560abd 100644
--- a/lib/DhMakePerl/Command/Packaging.pm
+++ b/lib/DhMakePerl/Command/Packaging.pm
@@ -119,14 +119,27 @@ sub makefile_pl {
 return $self->main_file('Makefile.PL');
 }
 
-sub get_developer {
+sub get_email {
 my $self = shift;
-
 my $email = $self->cfg->email;
 
-my ( $user, $pwnam, $name, $mailh );
-$user = $ENV{LOGNAME} || $ENV{USER};
-$pwnam = getpwuid($<);
+$email ||= ( $ENV{DEBEMAIL} || $ENV{EMAIL} );
+unless ($email) {
+	my $mailh;
+chomp( $mailh = `cat /etc/mailname` );
+$email = $self->get_user . '@' . $mailh;
+}
+
+$email =~ s/^(.*)\s+<(.*)>$/$2/;
+return $email;
+}
+
+sub get_name {
+my $self = shift;
+
+my $name;
+my $user = $ENV{LOGNAME} || $ENV{USER};
+my $pwnam = getpwuid($<);
 die "Cannot determine current user\n" unless $pwnam;
 if ( defined $ENV{DEBFULLNAME} ) {
 $name = $ENV{DEBFULLNAME};
@@ -137,15 +150,12 @@ sub get_developer {
 }
 $user ||= $pwnam->name;
 $name ||= $user;
-$email ||= ( $ENV{DEBEMAIL} || $ENV{EMAIL} );
-unless ($email) {
-chomp( $mailh = `cat /etc/mailname` );
-$email = $user . '@' . $mailh;
-}
-
-$email =~ s/^(.*)\s+<(.*)>$/$2/;
+return $name;
+}
 
-return "$name <$email>";
+sub get_developer {
+my $self = shift;
+return $self->get_name . " <" . $self->get_email . ">";
 }
 
 sub fill_maintainer {
diff --git a/lib/DhMakePerl/Command/make.pm b/lib/DhMakePerl/Command/make.pm
index 31db889..8cbfd8e 100644
--- a/lib/DhMakePerl/Command/make.pm
+

Bug#852332: dh-make-perl: DEBFULLNAME and DEBEMAIL should be used with git

[Carnë Draug]

Package: dh-make-perl
Version: 0.92
Followup-For: Bug #852332

On 24 January 2017 at 13:15, gregor herrmann <gre...@debian.org> wrote:
> On Tue, 24 Jan 2017 12:55:10 +, Dominic Hargreaves wrote:
>
>> > @@ -777,7 +777,7 @@ sub git_add_debian {
>> >
>> >  my $git = Git->repository( $self->main_dir );
>> >  $git->command( 'add', 'debian' );
>> > -$git->command( 'commit', '-m',
>> > +$git->command( 'commit', '--author', $self->get_developer, '-m',
>> >  "Initial packaging by dh-make-perl $VERSION" );
>> >  $git->command(
>> >  qw( remote add origin ),
>>
>> This will indeed create commits with the email and name specified, but
>> the committer address will not be overridden which is probably confusing.
>
> Ack.
> Maybe setting GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL via
> environment variables would work?

There are options to git, not to git commit.  One can use:

git commit -c "user.name=Foo" -c "user.email=Bar" ...

Which would mean changing DhMakePerl::Command::Packaging to have
get_email and get_name (which would then also be used by
get_developer).  I have attached a new patch that does that.

Carnë
From 941e701f86cb754594789aa5231416f4eb8a3a61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carn=C3=AB=20Draug?= <carandraug+...@gmail.com>
Date: Tue, 24 Jan 2017 14:15:15 +
Subject: [PATCH] DhMakePerl::Command::make: use author and email information
 for git commits.

DhMakePerl::Command::Packaging (get_name, get_email): two new methods
to retrieve only email and name because git handles them separate.

Closes: #852332
---
 Changes |  5 +
 lib/DhMakePerl/Command/Packaging.pm | 36 +++-
 lib/DhMakePerl/Command/make.pm  | 10 +++---
 3 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/Changes b/Changes
index 9c47553..4c952ec 100644
--- a/Changes
+++ b/Changes
@@ -1,4 +1,9 @@
 0.93 (201x-xx-xx)
+  [ Carnë Draug ]
+  * Use dh-make-perl email and name information for git commits.
+(Closes: #852332)
+  * DhMakePerl::Command::Packaging: add two new methods: get_email
+and get_name.
 
 0.92 (2016-09-20)
 
diff --git a/lib/DhMakePerl/Command/Packaging.pm 
b/lib/DhMakePerl/Command/Packaging.pm
index d759b66..e560abd 100644
--- a/lib/DhMakePerl/Command/Packaging.pm
+++ b/lib/DhMakePerl/Command/Packaging.pm
@@ -119,14 +119,27 @@ sub makefile_pl {
 return $self->main_file('Makefile.PL');
 }
 
-sub get_developer {
+sub get_email {
 my $self = shift;
-
 my $email = $self->cfg->email;
 
-my ( $user, $pwnam, $name, $mailh );
-$user = $ENV{LOGNAME} || $ENV{USER};
-$pwnam = getpwuid($<);
+$email ||= ( $ENV{DEBEMAIL} || $ENV{EMAIL} );
+unless ($email) {
+   my $mailh;
+chomp( $mailh = `cat /etc/mailname` );
+$email = $self->get_user . '@' . $mailh;
+}
+
+$email =~ s/^(.*)\s+<(.*)>$/$2/;
+return $email;
+}
+
+sub get_name {
+my $self = shift;
+
+my $name;
+my $user = $ENV{LOGNAME} || $ENV{USER};
+my $pwnam = getpwuid($<);
 die "Cannot determine current user\n" unless $pwnam;
 if ( defined $ENV{DEBFULLNAME} ) {
 $name = $ENV{DEBFULLNAME};
@@ -137,15 +150,12 @@ sub get_developer {
 }
 $user ||= $pwnam->name;
 $name ||= $user;
-$email ||= ( $ENV{DEBEMAIL} || $ENV{EMAIL} );
-unless ($email) {
-chomp( $mailh = `cat /etc/mailname` );
-$email = $user . '@' . $mailh;
-}
-
-$email =~ s/^(.*)\s+<(.*)>$/$2/;
+return $name;
+}
 
-return "$name <$email>";
+sub get_developer {
+my $self = shift;
+return $self->get_name . " <" . $self->get_email . ">";
 }
 
 sub fill_maintainer {
diff --git a/lib/DhMakePerl/Command/make.pm b/lib/DhMakePerl/Command/make.pm
index 31db889..dae325b 100644
--- a/lib/DhMakePerl/Command/make.pm
+++ b/lib/DhMakePerl/Command/make.pm
@@ -744,11 +744,13 @@ sub git_import_upstream__init_debian {
 $self->reset_git_environment();
 
 Git::command( 'init', $self->main_dir );
+my @git_config = ( '-c', 'user.name="' . $self->get_name . '"',
+   '-c', 'user.email="' . $self->get_email . '"');
 
 my $git = Git->repository( $self->main_dir );
 $git->command( qw(symbolic-ref HEAD refs/heads/upstream) );
 $git->command( 'add', '.' );
-$git->command( 'commit', '-m',
+$git->command( 'commit', @git_config, '-m',
   "Import original source of "
 . $self->perlname . ' '
 . $self->version );
@@ -762,7 +764,7 @@ sub git_import_upstream__init_debian {
   # debian/ directory from the working tree; git has the history, so I 
don't
 

Bug#852332: dh-make-perl: DEBFULLNAME and DEBEMAIL should be used with git

[Carnë Draug]

Package: dh-make-perl
Version: 0.92
Followup-For: Bug #852332

I have attached a git patch that fixes the issue.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-make-perl depends on:
ii  debhelper  10.2.3
ii  dpkg-dev   1.18.18
ii  fakeroot   1.21-3
ii  libapt-pkg-perl0.1.30
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.34-1
ii  libconfig-ini-perl 1:0.025-1
ii  libdebian-source-perl  0.92
ii  libdpkg-perl   1.18.18
ii  libemail-address-perl  1.908-1
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.21-1
ii  liblist-moreutils-perl 0.416-1+b1
ii  libmodule-depends-perl 0.16-3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libsoftware-license-perl   0.103012-1
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libyaml-libyaml-perl   0.63-2
ii  libyaml-perl   1.21-1
ii  make   4.1-9
ii  perl   5.24.1~rc4-1
ii  perl-modules-5.22 [libcpan-meta-perl]  5.22.2-1
ii  perl-modules-5.24 [libcpan-meta-perl]  5.24.1~rc4-1

Versions of packages dh-make-perl recommends:
ii  apt   1.4~beta3
ii  apt-file  3.1.3
ii  git   1:2.11.0-2
ii  libdpkg-parse-perl0.03-1
ii  libmodule-build-perl  0.422000-1
ii  pristine-tar  1.37

dh-make-perl suggests no packages.

-- no debconf information
From b8284e9dce8cfd31ee060c79ba8f2175eedf7212 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carn=C3=AB=20Draug?= <carandraug+...@gmail.com>
Date: Tue, 24 Jan 2017 12:06:48 +
Subject: [PATCH] DhMakePerl::Command::make: use author and email information
 for git commits.

Closes: #852332
---
 Changes| 3 +++
 lib/DhMakePerl/Command/make.pm | 6 +++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Changes b/Changes
index 9c47553..8c5e37f 100644
--- a/Changes
+++ b/Changes
@@ -1,4 +1,7 @@
 0.93 (201x-xx-xx)
+  [ Carnë Draug ]
+  * Use dh-make-perl email and name information for git commits.
+(Closes: #852332)
 
 0.92 (2016-09-20)
 
diff --git a/lib/DhMakePerl/Command/make.pm b/lib/DhMakePerl/Command/make.pm
index 31db889..4cde1da 100644
--- a/lib/DhMakePerl/Command/make.pm
+++ b/lib/DhMakePerl/Command/make.pm
@@ -748,7 +748,7 @@ sub git_import_upstream__init_debian {
 my $git = Git->repository( $self->main_dir );
 $git->command( qw(symbolic-ref HEAD refs/heads/upstream) );
 $git->command( 'add', '.' );
-$git->command( 'commit', '-m',
+$git->command( 'commit', '--author', $self->get_developer, '-m',
   "Import original source of "
 . $self->perlname . ' '
 . $self->version );
@@ -762,7 +762,7 @@ sub git_import_upstream__init_debian {
   # debian/ directory from the working tree; git has the history, so I 
don't
   # need the debian.bak
   $git->command( 'rm', '-r', $self->debian_dir );
-  $git->command( 'commit', '-m',
+  $git->command( 'commit', '--author', $self->get_developer, '-m',
  'Removed debian directory embedded in upstream source' );
 }
 }
@@ -777,7 +777,7 @@ sub git_add_debian {
 
 my $git = Git->repository( $self->main_dir );
 $git->command( 'add', 'debian' );
-$git->command( 'commit', '-m',
+$git->command( 'commit', '--author', $self->get_developer, '-m',
 "Initial packaging by dh-make-perl $VERSION" );
 $git->command(
 qw( remote add origin ),
-- 
2.11.0

Bug#852332: dh-make-perl: DEBFULLNAME and DEBEMAIL should be used with git

[Carnë Draug]

Package: dh-make-perl
Version: 0.92
Severity: wishlist

dh-make-perl recognizes the DEBFULLNAME and DEBEMAIL environment
variables.  However, those are not used as author or email when making
git commits which then defaults to username and hostname.

Since dh-make-perl already recognizes variables that set that value,
it would make sense for them to also be used for the git commits.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-make-perl depends on:
ii  debhelper  10.2.3
ii  dpkg-dev   1.18.18
ii  fakeroot   1.21-3
ii  libapt-pkg-perl0.1.30
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.34-1
ii  libconfig-ini-perl 1:0.025-1
ii  libdebian-source-perl  0.92
ii  libdpkg-perl   1.18.18
ii  libemail-address-perl  1.908-1
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.21-1
ii  liblist-moreutils-perl 0.416-1+b1
ii  libmodule-depends-perl 0.16-3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libsoftware-license-perl   0.103012-1
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libyaml-libyaml-perl   0.63-2
ii  libyaml-perl   1.21-1
ii  make   4.1-9
ii  perl   5.24.1~rc4-1
ii  perl-modules-5.22 [libcpan-meta-perl]  5.22.2-1
ii  perl-modules-5.24 [libcpan-meta-perl]  5.24.1~rc4-1

Versions of packages dh-make-perl recommends:
ii  apt   1.4~beta3
ii  apt-file  3.1.3
ii  git   1:2.11.0-2
ii  libdpkg-parse-perl0.03-1
ii  libmodule-build-perl  0.422000-1
ii  pristine-tar  1.37

dh-make-perl suggests no packages.

-- no debconf information

Bug#852004: RFP fpr bioperl's Bio-EUtilities

[Carnë Draug]

On 23 January 2017 at 12:40, Andreas Tille  wrote:
> Hi Carnė,
>
> On Fri, Jan 20, 2017 at 05:44:00PM +, Carnė Draug wrote:
>> I have filled a RFP (bug # 852004) for bioperl's Bio-EUtilities
>> package [1].  Unlike Bio-Coordinate, which was split from bioperl and
>> was recently packaged in Debian, Bio-EUtilities development started
>> already after bioperl commenced its splitting.
>>
>> I was wondering if it was possible for the debian-med team to package
>> it.  While I am not a debian maintainer, I am one of the
>> Bio-EUtilities developers, have an interest on seeing it packaged in
>> Debian, and I'm willing to support it upstream.
>
> I have commited some initial packaging to
>
>https://anonscm.debian.org/git/debian-med/libbio-eutilities-perl.git
>
> This build fails due to the failure of several tests - as far as I can
> see due to the attempt to access the internet.  It would help if you
> could provide an option: "Just do all tests than can be done offline"
> since the Debian packaging process needs to run fully offline.
>
> Kind regards
>
>  Andreas.

I have asked on #debian-perl if there was any standard method or
debian preferred method to skip those tests and apparently there is
none.  But there are some suggestions that seem to be common and
acceptable to the Debian.

1. check for an environment variable that defines whether network
tests should be skipped.  Some variables used in Debian are
NO_NETWORK, NOINTERNET, TEST_INTERNET, and NETWORK_TESTING.  See for
example discussion on debian bug #764868 [1]

2. mock EUtilities using Test::LWP::UserAgent.  This is probably the
most involved but probably the technically most correct way.  It has
the problem of not failing if upstream service ever changes (but maybe
if that happens and only the testsuite notices, then this whole module
is not needed).

3. move all tests from t/ to xt/ so that they are only ran at release
time by the package author "since obviously if the author isn't
running their own tests before releasing, you already have a bigger
problem"

Note that the test must not even attempt network access [2] so
skipping the test because a ping to the entrez servers fails is also
not allowed.

I'm CC'ing Chris Fields (also developer on Bio-EUtilities) to discuss
what would Debian and upstream prefer.

Carnë

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764868
[2] https://www.debian.org/doc/debian-policy/

Bug#852004: RFP: libbio-eutilities-perl -- bioperl interface to the Entrez Programming Utilities (E-utilities)

[Carnë Draug]

Package: wnpp
Severity: wishlist

* Package name: libbio-eutilities-perl
  Version : 1.75
  Upstream Author : bioperl project 
* URL : https://metacpan.org/release/Bio-EUtilities
* License : Perl
  Programming Lang: Perl
  Description : BioPerl interface to the Entrez Programming Utilities 
(E-utilities)

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.  This
package provides a programatic interface to NCBI's Entrez Programming
Utilities commonly refered to as E-utilities.  Namely, it provides the
Bio::DB::EUtilities and Bio::Tools::EUtilities perl modules.

Entrez is a federated search engine at the National Center for
Biotechnology Information (NCBI) for a large number of databases
covering a variety of biomedical data, including nucleotide and
protein sequences, gene records, three-dimensional molecular
structures, and the biomedical literature.  E-utilities are a set of
eight server-side programs that provide a stable interface into the
Entrez query and database system at the National Center for
Biotechnology Information (NCBI).

Bug#826048: Faulty CMake file impairs compiling against GDCM

[Carnë Draug]

On 17 October 2016 at 14:40, Mathieu Malaterre <ma...@debian.org> wrote:
> On Mon, Oct 17, 2016 at 3:19 PM, Carnë Draug <carandr...@octave.org> wrote:
>> On 17 October 2016 at 07:40, Mathieu Malaterre <ma...@debian.org> wrote:
>>> Control: tags -1 moreinfo
>>>
>>> On Fri, Oct 14, 2016 at 5:29 PM, Carne Draug <carandr...@octave.org> wrote:
>>>> Package: libgdcm2-dev
>>>> Version: 2.6.6-1
>>>> Followup-For: Bug #826048
>>>>
>>>> I'm not 100% sure if this is the same issue I'm having but I think
>>>> so, so I' commenting here instead of opening a new one.
>>>>
>>>> The following was working fine in Debian Wheezy and returned the
>>>> expected lib flags:
>>>>
>>>> cmake --find-package \
>>>>   -DNAME=GDCM \
>>>>   -DCOMPILER_ID=GNU \
>>>>   -DLANGUAGE=CXX \
>>>>   -DMODE=LINK
>>>
>>> Does it work if you change into -DMODE=COMPILE ?
>>
>> Yes. Getting the compile flags works fine:
>>
>> $ cmake --find-package \
>> -DNAME=GDCM \
>> -DCOMPILER_ID=GNU \
>> -DLANGUAGE=CXX \
>> -DMODE=COMPILE
>> -I/usr/include/gdcm-2.6
>>
>> $ cmake --find-package \
>> -DNAME=GDCM \
>> -DCOMPILER_ID=GNU \
>> -DLANGUAGE=CXX \
>> -DMODE=LINK
>>
>>
>> The last command, -DMODE=LINK, simply returns an empty line.
>
> Well it is in fact returning an empty string, so I would not consider
> this a bug. As far as I understand the link line for GDCM should not
> add anything. In the past (previous cmake version) it used to return
> "-rdynamic". That does not seems required anymore.
>
> GDCM libs are installed in the default path, so your linker should be
> able to find them without tweaking the link line.
>

I could swear that in Wheezy this also returned all the multiple -lgdcm*
but after I checked I was wrong.  Indeed it only returned -rdynamic.

Thank you for the attention and apologies for all the noise.

Bug#826048: Faulty CMake file impairs compiling against GDCM

[Carnë Draug]

On 17 October 2016 at 07:40, Mathieu Malaterre  wrote:
> Control: tags -1 moreinfo
>
> On Fri, Oct 14, 2016 at 5:29 PM, Carne Draug  wrote:
>> Package: libgdcm2-dev
>> Version: 2.6.6-1
>> Followup-For: Bug #826048
>>
>> I'm not 100% sure if this is the same issue I'm having but I think
>> so, so I' commenting here instead of opening a new one.
>>
>> The following was working fine in Debian Wheezy and returned the
>> expected lib flags:
>>
>> cmake --find-package \
>>   -DNAME=GDCM \
>>   -DCOMPILER_ID=GNU \
>>   -DLANGUAGE=CXX \
>>   -DMODE=LINK
>
> Does it work if you change into -DMODE=COMPILE ?

Yes. Getting the compile flags works fine:

$ cmake --find-package \
-DNAME=GDCM \
-DCOMPILER_ID=GNU \
-DLANGUAGE=CXX \
-DMODE=COMPILE
-I/usr/include/gdcm-2.6

$ cmake --find-package \
-DNAME=GDCM \
-DCOMPILER_ID=GNU \
-DLANGUAGE=CXX \
-DMODE=LINK


The last command, -DMODE=LINK, simply returns an empty line.

Bug#833940: octave-nan includes its own version of libsvm -- not dynamically linked to libsvm

[Carnë Draug]

Package: octave-nan
Version: 3.0.2-1

The octave-nan package includes the matlab libsvm toolbox which is an
interface to the C++ library libsvm [1].  libsvm is already package in
Debian [2] but the octave-nan package seems statically linked with the
outdated version of libsvm that is distributed with the octave nan
package.

[1] https://www.csie.ntu.edu.tw/~cjlin/libsvm/
[2] https://packages.debian.org/sid/libsvm3

Bug#777383: ITP: python-serpent -- Serpent is a simple serialization python library based on ast.literal_eval

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: Carnë Draug carandraug+...@gmail.com

* Package name: python-serpent
  Version : 1.8
  Upstream Author : Irmen de Jong
* URL : https://github.com/irmen/Serpent
* License : MIT
  Programming Lang: Python
  Description : Serpent is a simple serialization python library based on 
ast.literal_eval

Serpent provides ast.literal_eval() compatible object tree serialization.  It 
serializes an
object tree into bytes (utf-8 encoded string) that can be decoded and then 
passed as-is to
ast.literal_eval() to rebuild it as the original object tree.  As such it is 
safe to send
serpent data to other machines over the network for instance (because only 
'safe' literals
are encoded).

Why is this package relevant?  This is a dependency of Pyro4 (see debian bug 
#745437)

How do you pan to maintain it? It is a single source file (serpent.py) so I 
hope it will
not be too much work.  This would also be my first package and seems like a 
good choice for
it.  A mentor would be appreciated.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557879: graphicsmagick: please build with --with-quantum-depth=16

[Carnë Draug]

It's been almost 5 years since this bug was reported, it's a blocker
for other two bugs, it has a patch (it's a 1 line change on the
Makefile), and even the upstream maintainer has pitched in saying that
the build should be changed has proposed.

Could the package maintainer please please please, at least comment on this?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557879: graphicsmagick: please build with --with-quantum-depth=16

[Carnë Draug]

On 1 September 2014 12:24, László Böszörményi (GCS) g...@debian.org wrote:
 Hi Carnë,

 On Mon, Sep 1, 2014 at 12:48 PM, Carnë Draug carandr...@octave.org wrote:
 It's been almost 5 years since this bug was reported, it's a blocker
 for other two bugs, it has a patch (it's a 1 line change on the
 Makefile), and even the upstream maintainer has pitched in saying that
 the build should be changed has proposed.

 Could the package maintainer please please please, at least comment on this?
  I'm the current maintainer, but I came late in the package life. Yes,
 changing the quantum depth is just a switch for the configure script.
 On the other hand, it changes at least two important aspect of the
 programs using graphicsmagick.
 The first one is the in-memory usage of graphics handling. It will
 double the memory needed for the unpacked (ie, don't compare it with
 the on-disk size of the image) pictures. Yes, newer architectures like
 PPC64 will have several gigabytes of RAM to handle this. But on older
 architectures like armel/armhf it may render the package itself and
 related ones to useless because of memory issues.

This proposal is only to increase it to 16 which is a compromise.
People with such limited machines (in need of quantum-depth=8), and
people with such specialized data (in need of quantum-depth=32) would
have to build it themselves. Making everyone happy is not possible
(well, there's a new GM features which would allow to have 3 separate
packages, one for each configuration but that may be more trouble) but
it would seem that 16 bit, would make the most people, and the typical
user, happier.

I would guess that older systems are probably dealing with smaller
images, where doubling the image on size will be a small increase. But
to sacrifice all the users that need 16 (and that's not me, I need 32)
to save the ones that need 8, seems unfair.

 The second one is can the dependent packages handle the changed
 in-memory representation of the image? Who can test those in every
 aspect at least on two architectures (little- and big-endian one)?
 Fixes may be necessary for those and if their upstream is busy with
 other things, the packages may be broken for a long time.
 I can do a limited quick test on amd64, but the Release-Team will be
 in position to allow this change or not.

At least Fedora (and Fedora-based distros), and Arch linux have been
using quantum-depth 16. If there's any problems they should have
appeared there as well (and hopefully have already been fixed). Even
the upstream recommendation is to use 16, so dependent packages should
at least be aware and prepared to have GM built with different
options. And when using GM, one usually is abstracted from that, I'd
be surprised if they have hardcoded somewhere a limitation for
specific depth.

In Octave we recommend users to rebuild everything from source using
16 (or 32 for special cases), so at least the Octave package has
already been well tested for this change.

Finally, the only way to be sure is to actual test. I see no reason to
think there will be any problem with this change but that's why this
will first go into unstable, and then into testing. It is best if this
change goes in soon, well before the Jessie freeze (November 5th) so
that there's plenty of time to find any possible problem.

Please consider this change. Thank you,

Carnë


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#533233: avahi-autoipd should not overwrite route when other interfaces are configured

[Carnë Draug]

Hi

I'm facing the same problem on my new machine. The default
configuration makes it lose the internet connection soon after
startup.

Here's exactly what happens. The system has two interfaces, eth0 and
wlan0. Without an ethernet cable connected (standard since this is a
laptop), the wlan0 interfaces gets an IP address quickly from dhcp and
becomes the default route. Slightly after this (around 1 minute),
avahi seems to timeout after being unable to get an IP address for
eth0 (there's no cable after all) and gets an APIPA address for eth0
(and eth0:avahi) which then becomes the default route. But why is an
interface that is down even being added to the route? And why is it
stealing the default route from the properly configured interfaces?

Bringing eth0 down fixes it only temporarily. A few minutes after
running 'ifconfig eth0 down', that interface comes up again
automatically and becoming the default route (wrong). I have fixed
tis temporarily by commenting all the eth0 lines in
/etc/network/interfaces

Also, it appears that there's other people facing the same issue
(besides me and the two other that reported this first). This thread
[1] on the debian forums is likely to be the same bug.

Carnë

[1] http://forums.debian.net/viewtopic.php?f=5t=116275#p547803


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758384: avahi-daemon: eth0:avahi interface created although it's disconnected

[Carnë Draug]

After more digging on what was causing this, I found that this is
actually a duplicate of the bug #533233 on avahi-autoipd. Could
someone please close it as duplicate?

Thank you,
Carnë


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557879: graphicsmagick: please build with --with-quantum-depth=16

[Carnë Draug]

This change would be really nice. It is is holding back bugs on other
projects, it is an upstream recommendation, and it's as easy as adding
–with-quantum-depth=16 to the debian/rules file. Why hasn't been
done yet?

It pretty much makes Octave useless for Image analysis and is forcing
the users to not only build GM themselves, but also build Octave
itself. It has reached the level where Octave documentation needs to
give instructions to rebuild GM from source on Debian based systems.

Carnë


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751290: openjdk-7-jre-headless: javax.swing.JDialog has no button to close window

[Carnë Draug]

Package: openjdk-7-jre-headless
Version: 7u55-2.4.7-2
Severity: normal

Dear Maintainer,

several java applications have dialog windows whose window X button to close
it has disappeared. When the window itself does not have ok and cancel
buttons, there's no way to close it. Talking with upstream projects, this
seems to be unique to openjdk and cannot be duplicated with Oracle's Java
in Debian.

For an example, please try the following beanshell script which will create
such window:

 jdialog = new javax.swing.JDialog(null, Hello Swing);
 jdialog.setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
 jdialog.setSize(300, 100);
 jdialog.setVisible(true);

There should be an X button on the window somewhere to close it. Apparently
is also not a Gnome problem since another report [1] says that it happened
when upgrading Fedora with Gnome 3.8 to 3.10. I am still using Gnome 3.8
therefore must be OpenJDK.

Unfortunately, my knowledge of java is minimal, and most of this information
was passed on to me from upstream projects whith such windows.

Carnë

[1] https://mail.gnome.org/archives/gnome-list/2014-January/msg1.html


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500,
'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openjdk-7-jre-headless depends on:
ii  ca-certificates-java  20140324
ii  java-common   0.52
ii  libc6 2.19-1
ii  libcups2  1.7.2-3
ii  libfontconfig12.11.0-5
ii  libfreetype6  2.5.2-1
ii  libgcc1   1:4.9.0-5
ii  libglib2.0-0  2.40.0-3
ii  libjpeg8  8d-2
ii  libkrb5-3 1.12.1+dfsg-1
ii  liblcms2-22.6-1
ii  libnss3   2:3.16-1
ii  libpcsclite1  1.8.11-3
ii  libstdc++64.9.0-5
ii  multiarch-support 2.19-1
ii  tzdata-java   2014d-1
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages openjdk-7-jre-headless recommends:
ii  icedtea-7-jre-jamvm  7u55-2.4.7-2

Versions of packages openjdk-7-jre-headless suggests:
ii  fonts-dejavu-extra 2.34-1
pn  fonts-indicnone
pn  fonts-ipafont-gothic   none
pn  fonts-ipafont-mincho   none
ii  libnss-mdns0.10-6
pn  sun-java6-fontsnone
pn  ttf-wqy-microhei | ttf-wqy-zenhei  none

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked

[Carnë Draug]

On 20 April 2014 02:35, David Smith sidic...@gmail.com wrote:
 On 04/19/2014 08:26 PM, David Smith wrote:

 Can you please check Tools - Preferences - Browser - Browser
 And naturally I forgot to mention that the Default Browser listed in
 Liferea refers *SPECIFICALLY* to the Gnome desktop default browser..
 ie: It would require the desktop-file-utils package to be installed.
 That's why we go with the x-www-browser option as the default for
 liferea in Debian as the x-www-browser is automatically updated by dpkg
 while the Default Gnome desktop browser is not automatically updated
 since it's a user config that you set in Gnome.  If you have Default
 Browser listed there, it might be a user configuration that's left over
 from a previous version and you're just going to have to change it to
 x-www-browser or something else.

Indeed, I have upgraded from Debian Wheezy and kept the same home directory.

Changing the browser from Default browser to x-www-browser as you
mentioned fixed the problem. However, my default browser is Iceweasel,
and Gnome is configured to use Iceweasel as default. Going to
Settings  Details  Default applications  Web I have Iceweasel
selected there. I would expect this default to be used.

Carnë


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked

[Carnë Draug]

Package: liferea
Version: 1.10.8-1
Followup-For: Bug #666145

Dear maintainer,

The original report and all comments are related to the version in
Debian Wheezy (currently stable). This comment is just to report
the issue is still present in Jessie with liferea version 1.10.8.

Carnë Draug


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages liferea depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gir1.2-gtk-3.0   3.12.0-4
ii  gir1.2-peas-1.0  1.8.1-1
ii  libatk1.0-0  2.12.0-1
ii  libc62.18-4
ii  libcairo21.12.16-2
ii  libgdk-pixbuf2.0-0   2.30.6-1
ii  libgirepository-1.0-11.40.0-2
ii  libglib2.0-0 2.40.0-2
ii  libgtk-3-0   3.12.0-4
ii  libindicate5 0.6.92-2
ii  libjson-glib-1.0-0   1.0.0-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.3-1
ii  libpeas-1.0-01.8.1-1
ii  libsoup2.4-1 2.46.0-2
ii  libsqlite3-0 3.8.4.1-1
ii  libwebkitgtk-3.0-0   2.2.6-1
ii  libxml2  2.9.1+dfsg1-3
ii  libxslt1.1   1.1.28-2
ii  liferea-data 1.10.8-1
ii  python-gi3.10.2-2+b1
pn  python:any   none

Versions of packages liferea recommends:
ii  dbus 1.8.0-3
ii  dbus-x11 1.8.0-3
ii  gir1.2-gnomekeyring-1.0  3.4.1-1
ii  gnome-icon-theme 3.12.0-1
ii  gnome-keyring3.8.2-2+b1
ii  steadyflow   0.2.0-1

Versions of packages liferea suggests:
pn  network-manager  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726287: gnome-shell: Network support broken with GNOME 3.8.4 update

[Carnë Draug]

Hi

fresh install of Jessie and it is also not fixed for me. I have the
mentioned dependency libpam-systemd version 204-8 installed.

When I open the Network configuration in the settings menu, I get the
mentioned error The system network services are not compatible with
this version.

Carnë


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726960: units: exit of value of units --version is non 0

[Carnë Draug]

Package: units
Version: 1.88
Severity: normal

Dear Maintainer,

the exit value of units --version is 3 instead of 0 (as should be for
success). Check the following:

$ units --version
GNU Units version 1.88
with readline, units database in /usr/share/misc/units.dat
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Units comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Units
under the terms of the GNU General Public License.

$ echo $?
3

I'm trying to use units --version in a script to check if units is installed
in the system when I faced with this problem. I found this quite non-standard.
I would expect it to return 0 .



-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#625210: metacity: Always on top option does not persist after changing workspace

[Carnë Draug]

Package: metacity
Version: 1:2.30.1-3
Severity: normal

After selecting the option Always on top and move to another workspace, when
coming back to the previous workspace, the Always on top option is turned
back off. This doesn't happen with all programs, for me it happens only with
some java programs such as ImageJ and the omero clients (these last ones are
not in the debian repositories).

This bug doesn't appear when using compiz so I believe it to be on metacity.

Here's how to replicate the problem
1 - start ImageJ
2 - right click on the ImageJ bar and select always on top
3 - select another window and place it behind the ImageJ
4 - move to another workspace (Ctr+Alt+right arrow)
5 - go back to previous workspace (Ctr+Alt+Left arrow)
6 - notice that the other window is now on top of the ImageJ window and that
the ImageJ window soesn't have the Always on top option selected anymore



-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages metacity depends on:
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libcanberra-gtk0   0.24-1Gtk+ helper for playing widget eve
ii  libcanberra0   0.24-1a simple abstract interface for pl
ii  libgconf2-42.28.1-6  GNOME configuration database syste
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface
ii  libgtop2-7 2.28.1-1  gtop system monitoring library (sh
ii  libice62:1.0.6-2 X11 Inter-Client Exchange library
ii  libmetacity-private0   1:2.30.1-3library for the Metacity window ma
ii  libpango1.0-0  1.28.3-1+squeeze2 Layout and rendering of internatio
ii  libsm6 2:1.1.1-1 X11 Session Management library
ii  libstartup-notificatio 0.10-1library for program launch feedbac
ii  libx11-6   2:1.3.3-4 X11 client-side library
ii  libxcomposite1 1:0.4.2-1 X11 Composite extension library
ii  libxcursor11:1.1.10-2X cursor management library
ii  libxdamage11:1.1.3-1 X11 damaged region extension libra
ii  libxext6   2:1.1.2-1 X11 miscellaneous extension librar
ii  libxfixes3 1:4.0.5-1 X11 miscellaneous 'fixes' extensio
ii  libxinerama1   2:1.1-3   X11 Xinerama extension library
ii  libxrandr2 2:1.3.0-3 X11 RandR extension library
ii  libxrender11:0.9.6-1 X Rendering Extension client libra
ii  metacity-common1:2.30.1-3shared files for the Metacity wind
ii  zenity 2.30.0-1  Display graphical dialog boxes fro

Versions of packages metacity recommends:
ii  gnome-session [x-session-mana 2.30.2-3   The GNOME Session Manager - GNOME

Versions of packages metacity suggests:
ii  gnome-control-center  1:2.30.1-2 utilities to configure the GNOME d
ii  gnome-themes  2.30.2-1   official themes for the GNOME desk
ii  xdg-user-dirs 0.13-2 tool to manage well known user dir

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623244: RFP: omero-clients -- Clients to connect to the omero server

[Carnë Draug]

Package: omero-clients
Severity: whishlist

The omero server is a database for images, aimed primarly to
microscope images. There's 3 main clients to connect to the server
(omero.insight, omero.importer and omero.editor) all working together
to import images into the database (importer), browse and edit the
server (insight) and to create and attach experimental methods to
images (editor). While packaging the server is probably a more
difficult thing which only few users will need, the clients are needed
by many more people.

This is the link to download the latest version (4.2.2)
http://cvs.openmicroscopy.org.uk/snapshots/omero/OMERO.clients-Beta4.2.2.linux.zip
and this page lists all downloads
http://www.openmicroscopy.org/site/support/omero4/downloads

All clients are released under GPL v2

Carnë Draug



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#596985: teeworlds-server: no service script on init.d

[Carnë Draug]

Package: teeworlds-server
Version: 0.5.2-2
Severity: wishlist

This package does not install a service script on /etc/init.d as is usual for
other services. It also has no default configuration server configuration on
/etc/teeworlds. It would be nice if these were already available.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#589818: ensembl-core -- Ensembl core Perl API

[Carnë Draug]

Hi Steffen

the new version came out this month but I haven't managed to package it yet.

This is my first attempt at packaging something and I'm a bit
confused. I was wondering if you could give help me on this one. I've
found a lot of free (as in freedom) software that I need but is not
packaged yet. I don't mind packaging and maintaining them but I don't
know where to start (documentation for new maintainers guide is more
directed for simpler packages).

Hope to hear from you soon. Thanks in advance,
Carnë



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#576776: allow umount by UUID

[Carnë Draug]

I'm also interested in this functionality. It is still not present in
version 2.17.2-3.1 of util-linux

Example:

##Line of fstab
UUID=f6d4ad9e-f0d4-44ff-b878-a75f817e3d50 /mnt/backup ext4
rw,suid,dev,noexec,noauto,nouser,async 0 2

## mount works fine
$ mount UUID=f6d4ad9e-f0d4-44ff-b878-a75f817e3d50

## umount gives error
$ umount UUID=f6d4ad9e-f0d4-44ff-b878-a75f817e3d50
umount: UUID=f6d4ad9e-f0d4-44ff-b878-a75f817e3d50: not found



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#557879: graphicsmagick: please build with --with-quantum-depth=16

[Carnë Draug]

Hi

I can't open and analyse 16-bit images. Please build with
quantum-depth=16. Octave can't open them as it uses graphicsmagick and
for scientific equipment, 16-bit images are a must. Thanks in advance,

Carnë Draug



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592647: libgtksourceview2.0-common: Improvement of the octave.lang file

[Carnë Draug]

Package: libgtksourceview2.0-common
Version: 2.10.3-1
Severity: minor
Tags: patch

I found that the language file for the octave language is a bit poor so I
decided to make some improvements. I'm attaching the new octave.lang file.

I got some input from one of the octave developers and original developer of
octave.lang file when doing it ( http://tinyurl.com/ygr8yj3 ) and testing from
some ubuntu users ( http://tinyurl.com/yzdks6l ).

I've also sent it to the gtksourceview developers (filed a bug report in
bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=613378) but they have
keep silent for some months now. Hopefully you'll get it upstream or at least
for the debian community.

Here's the list of changes I made

* comments and continuation line
  * ... is now identified as a continuation line character
  * comments after the continuation line character do not disrupt it
  * continuation lines characters are ignored if they are between
single quotes

* shebang line
  * now it's defined by the default configuration as being such instead
of just another comment

* block comments
  * added #{ and #} to the list of possibilities for block comments
  * highlights correctly when block comments are nested

* operators
  * now are highlighted (not only simple arithmetic operators, this
includes element by element, transpose operator, autoincrement, assignment and
logical operators)

* functions
  * added a bunch of functions (got some input for one of the octave
developers to avoid problems picking functions that may be removed from octave
to avoid problems in the future)
  * just to make it look pretty I mixed some very similar functions
into one such as (a)?sin(d|h)?
  * removed 'ans' from the list of functions and highlighted it as a
variable

* metadata
  * changed default for line comment from % back to #

* pkg as preprocessor
  * if pkg is not called 'like a function' (i.e. pkg (load,..)) it's
highlighted as preprocessor (in similarity to the 'use' function in Perl)

* constants/functions
  * functions such as Inf, pi, NaN which can be called with no
arguments to return a constant value, are highlighted as constants in those
situations but still as functions if followed by opening parenthesis

* data types
  * the function handle character '@' is now highlighted

* true/false as functions
  * are highlighted as boolean unless followed by opening parenthesis,
in which case are highlighted as functions

* keywords
  * added the keywords, persistent, replot, static, varargin, varargout
  * removed the keywords assert, nargin, nargout and moved them to be
highlighted as functions

* strings
  * added a printf regexp that should identify its formatting (copied
it from the C.lang file)
  * added an escape regexp that should escape only some stuff, not
whatever is right after an \ (also copied it from the C.lang file)



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


octave.lang
Description: Binary data

Bug#592647: libgtksourceview2.0-common: Improvement of the octave.lang file

[Carnë Draug]

I actually sent the original octave.lang instead of the improved
version. I'm so embarassed. I attached the right file this time. Sorry
about the mistake.

Carnë Draug


octave.lang
Description: Binary data

Bug#592381: imagej: refuses to close unless everything is saved before

[Carnë Draug]

Package: imagej
Version: 1.44c-2
Severity: important

If a imaged is modified and not saved it is not possible to close imageJ. A
window appears asking if we want to save the changes. It doesn't matter which
button is pressed, the changes are not saved and it is no longer possible to
close imageJ (java process must be killed to do so).

How to duplicate:
1 - Start ImageJ
2 - Open a sample image (blobs (keyboard shortcut Ctrl+Shift+B))
3 - Make a change to the image (process - smooth (Ctrl+Shift+S))
4 - Try to close imageJ (File - Quit). A window should appear with the text
Save changes to blobs.gif?. It doesn't matter which one is selected, imageJ
doesn't quit. Other attempts to quit ImageJ do not show this window.

Other notes:
* If quitting imageJ after using only the paintbrush or pencil tool, doesn't
make the message appear but does quit imageJ.
* If instead of trying to close imageJ, the window with the image is closed,
the same happens. However, further attempts to close the window makes the
message appear again (in contrast with quitting imageJ where the message only
appears the first time further attempts have no effect whatsoever)

Workarounds:
 Kill the process
 Save the modified image



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagej depends on:
ii  openjdk-6-jre 6b18-1.8-1 OpenJDK Java runtime, using Hotspo

imagej recommends no packages.

Versions of packages imagej suggests:
ii  gcj-jre-headless [java-virtua 4:4.4.4-2  Java runtime environment using GIJ

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#589818: ITP: ensembl-core -- Ensembl core Perl API

[Carnë Draug]

Package: wnpp
Owner: Carnë Draug carandraug...@gmail.com
Severity: wishlist

*** Please type your report below this line ***

* Package name: ensembl-core
  Version : 58
  Upstream Author : Ensembl developers team ensembl-...@ebi.ac.uk
* URL : http://www.ensembl.org/info/docs/api/core/index.html
* License : Other, see
http://www.ensembl.org/info/about/code_licence.html
  Programming Lang: Perl
  Description : Ensembl Core is a Perl API to access the Ensembl Core
databases. It is useful to automate the extraction of particular data, to
customize Ensembl to fulfil a particular purpose, or to store additional data
in Ensembl.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#589177: gmail-notify: Unable to connect. Error Login appears to be invalid

[Carnë Draug]

Package: gmail-notify
Version: 1.6.1.1-1
Severity: important

I am unable to use gmail-notify. I receive the error Login appears to be
invalid. I am certain that the password and username are correct. I tried
it
with another account and received the same error.

It shouldn't be related to the problem but I am behind a firewall and using
a
proxy. The proxy is correctly set up (172.16.7.73:8080).



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gmail-notify depends on:
ii  python 2.6.5-5   An interactive high-level
object-o
ii  python-central 0.6.14+nmu2   register and build utility for
Pyt
ii  python-eggtrayicon 2.25.3-4.1+b3 Python module to display icons
in
ii  python-gtk22.17.0-2  Python bindings for the GTK+
widge

Versions of packages gmail-notify recommends:
ii  epiphany-browser [www-browser 2.30.2-2   Intuitive GNOME web browser
ii  iceweasel [www-browser]   3.5.10-1   Web browser based on Firefox
ii  w3m [www-browser] 0.5.2-5WWW browsable pager with
excellent

gmail-notify suggests no packages.

-- no debconf information

Bug#588798: imagej: fails to find JVM on fresh install

[Carnë Draug]

Package: imagej
Version: 1.44c-1
Justification: renders package unusable
Severity: grave

Fresh install of imageJ doesn't start. When started from a terminal returns
the
error

carandr...@altar:~$ imagej
/usr/bin/imagej: line 32: /usr/sbin/update-java-alternatives: No such file
or
directory
Open other images in this ImageJ panel as follows:
  imagej -p 1 image1 [image2 ... imageN]

No JVM found to run ImageJ
Please apt-get install a JVM to run ImageJ or
set JAVA_HOME if it's not a JVM from a Debian Package.


Problem is solved after installing openjdk-6-jre.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagej depends on:
ii  gcj-4.4-jre [java2-runtime]   4.4.4-6Java runtime environment using
GIJ
ii  gcj-jre [java2-runtime]   4:4.4.4-2  Java runtime environment using
GIJ

imagej recommends no packages.

Versions of packages imagej suggests:
ii  gcj-jre-headless [java-virtua 4:4.4.4-2  Java runtime environment using
GIJ

-- no debconf information

Bug#588561: referencer: unable to see library properties. Error on loading of glade file

[Carnë Draug]

Package: referencer
Version: 1.1.6-1+b2
Severity: normal

Choosing Properties on the menu Library returns an error.
Keyboard shortcut is Ctr+P and gives the same error

Error is:

Exception: Failed to load glade file `'
The operation underway was: executing UI action

I have another computer with Debian and same version of the package and get
exactly the same error.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages referencer depends on:
ii  libboost-regex1.42.01.42.0-3 regular expression library for
C++
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared
lib
ii  libgcc1 1:4.4.4-6GCC support library
ii  libgconfmm-2.6-1c2  2.28.0-1 C++ wrappers for GConf (shared
lib
ii  libglademm-2.4-1c2a 2.6.7-2  C++ wrappers for libglade2
(shared
ii  libglib2.0-02.24.1-1 The GLib library of C routines
ii  libglibmm-2.4-1c2a  2.24.2-1 C++ wrapper for the GLib
toolkit (
ii  libgnome-vfsmm-2.6-1c2a 2.26.0-1 C++ wrappers for GnomeVFS
(shared
ii  libgnomemm-2.6-1c2  2.30.0-1 C++ wrappers for libgnome
(shared
ii  libgnomeuimm-2.6-1c2a   2.28.0-1 C++ wrappers for libgnomeui
(share
ii  libgtk2.0-0 2.20.1-1 The GTK+ graphical user
interface
ii  libgtkmm-2.4-1c2a   1:2.20.3-1   C++ wrappers for GTK+ (shared
libr
ii  libpangomm-1.4-12.26.2-1 C++ Wrapper for pango (shared
libr
ii  libpoppler-glib40.12.4-1 PDF rendering library
(GLib-based
ii  libpython2.62.6.5+20100630-2 Shared Python runtime library
(ver
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for
C++
ii  libstdc++6  4.4.4-6  The GNU Standard C++ Library v3

referencer recommends no packages.

referencer suggests no packages.

-- no debconf information