Bug#823287: selinux-basics: System cannot boot with SELinux enabled after upgrade

[Jonathan Yu]

On Tue, May 3, 2016 at 10:10 AM, Laurent Bigonville 
wrote:
>
>
> Do you have a policy installed on your machine?
>

I do not - I was unable to install the latest selinux-policy-default
package from unstable due to dependency problems that I was unable to
resolve.

The following packages have unmet dependencies:
 selinux-policy-default : Depends: policycoreutils (>= 2.2.1) but it is not
going to be installed
 udev : Depends: libblkid1 (>= 2.19.1) but it is not going to be installed
Depends: adduser but it is not going to be installed
Depends: util-linux (>= 2.27.1)
Depends: procps


> The policy package currently in unstable is not compatible with the new
> userspace and needs to be adjusted, see bug #805492.
>

Ah, it does look like the same problem. However, I expected some sort of
safeguard that would prevent me from breaking my system -- i.e. a check in
selinux-activate that ensured that a policy was available, if that is
required to boot. Making my system unbootable is not desired behaviour.


> I've unfortunately not a lot of time for this. That means that if you want
> to use SELinux in debian, you'll have to compile/build your own policy.
>

I can understand that. I have some experience with Debian packaging, but
little with SELinux or advanced things like maintainer scripts, however I'd
be happy to spend a few weekends hacking on this if you can give me some
direction. I'll read through #805492 this weekend and come back to you with
questions.

Thanks again for all your contributions to Debian :)

Bug#823287: selinux-basics: System cannot boot with SELinux enabled after upgrade

[Jonathan Yu]

Package: selinux-basics
Version: 0.5.4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Thank you for your work bringing SELinux to Debian!

I regret that my knowledge of both SELinux and systemd is limited, so I do not
know what diagnostics to collect or how to collect it.  That said, I can
reproduce this problem at will, and I'm happy to collect whatever diagnostics
you need.

   * What led up to the situation?

I upgraded my system doing full-upgrade. My system is mainly 'testing' with
some packages coming from 'unstable' (I tried updating to the newer
selinux-utils in unstable, but to no avail).

Unfortunately there are not much diagnostics provided during boot, and I
could not find any trace of the failed boots in journalctl or in files
in /var/log, presumably because the problems occurred at such an early
stage of boot. I checked /var/log/syslog, but did not find much informative.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Removing the "selinux=1 security=selinux" flags from grub allowed me to boot.
I then used "selinux-activate disabled" to disable SELinux while we sort
these issues out.

I also tried running "selinux-activate disabled" and re-activating it again,
as it seems to do something with restorecond on first boot after activation.
Unfortunately this did not change anything :(

   * What outcome did you expect instead?

I expected that my system could continue booting. I've never had significant
issues with Debian upgrades (thanks to careful maintainers like you :) and
guess that there must be something strange about the way my system is
configured.

There was some interesting-looking output in /var/log/audit; here's a
section:

May  2 20:31:38 theory systemd[1]: Listening on CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Listening on D-Bus System Message Bus Socket.
May  2 20:31:38 theory systemd[1]: apt-daily.timer: Adding 7h 21min 31.345143s 
random time.
May  2 20:31:38 theory systemd[1]: Started Daily apt activities.
May  2 20:31:38 theory systemd[1]: Started Daily Cleanup of Temporary 
Directories.
May  2 20:31:38 theory systemd[1]: Reached target Timers.
May  2 20:31:38 theory systemd[1]: Started CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Reached target Paths.
May  2 20:31:38 theory systemd[1]: Listening on Virtual machine lock manager 
socket.
May  2 20:31:38 theory systemd[1]: Listening on mpd.socket.
May  2 20:31:38 theory systemd[1]: Listening on Virtual machine log manager 
socket.
May  2 20:31:38 theory systemd[1]: Reached target Sockets.
May  2 20:31:38 theory systemd[1]: Reached target Basic System.
May  2 20:31:38 theory systemd[1]: Started Run anacron jobs.
May  2 20:31:38 theory systemd[1]: Starting Accounts Service...
May  2 20:31:38 theory systemd[1]: Starting IIO Sensor Proxy service...
May  2 20:31:38 theory systemd[1]: Starting Restore /etc/resolv.conf if the 
system crashed before the ppp link was shut down...
May  2 20:31:38 theory systemd[1]: Starting Thermal Daemon Service...
May  2 20:31:38 theory systemd[1]: Starting Modem Manager...
May  2 20:31:38 theory systemd[1]: Started CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Started D-Bus System Message Bus.
May  2 20:31:38 theory ModemManager[1176]:   ModemManager (version 
1.4.14) starting in system bus...
May  2 20:31:38 theory dbus-daemon[1183]: Failed to start message bus: Failed 
to open "/etc/selinux/default/contexts/dbus_contexts": No such file or directory
May  2 20:31:38 theory systemd-udevd[823]: Process '/usr/sbin/alsactl -E 
HOME=/run/alsa restore 2' failed with exit code 99.
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.thermald': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.ModemManager1': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'net.hadess.SensorProxy': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.NetworkManager': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.login1': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.Accounts': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to activation signal: 
Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to register name: Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to set up API bus: Connection timed 
out
May  2 20:31:38 theory systemd[1]: Starting Network Manager...
May  2 20:31:38 theory systemd[1]: Starting LSB: Start the GNUstep distributed 
object mapper...
May  2 20:31:38 theory systemd[1]: Started Regular background program 
processing 

Bug#707528: libvideo-fourcc-info-perl: FTBFS: gpg: fatal: can't create directory `/sbuild-nonexistent/.gnupg': No such file or directory

[Jonathan Yu]

These errors are very strange indeed. I would suggest either disabling the
tests or removing this package (I have no strong feeling either way). I
could do the same in the upstream version (or pass co-maintainership to
someone else), but I guess it would be good to know what caused this
breakage in the first place...

Bug#636133: Replace libgtk2-mozembed-perl with libgtk2-webkit-perl?

[Jonathan Yu]

Hi all,

In August 2011, gregor mentioned that we could attempt to replace
libgtk2-mozembed-perl (which is currently FTBFS) with libgtk2-webkit-perl,
which was never uploaded (since being packaged in 2009). I am wondering if
there are comments as to whether we could solve BTS#636133 by replacing
libgtk2-mozembed-perl with libgtk2-webkit-perl (there is only one reverse
dependency of libgtk2-mozembed-perl, and it looks like it could use
libgtk2-webkit-perl instead).

Should we pursue this avenue, or does anyone know of a reason we shouldn't
bother?

I have not yet attempted to build libgtk2-webkit-perl nor test it against
the mentioned reverse dependency, gmusicbrowser. But it looks like we have
little choice but to remove libgtk2-mozembed-perl, as it is obsoleted by
upstream (per Chris Butler's comment).

Cheers,

Jonathan

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636133

Bug#655710: libdevel-ebug-perl: Failing tests t/finished.t

[Jonathan Yu]

I've been investigating this today, and it appears that the debugger is now
faulty (I am still not sure whether it is related to the bug report filed
regarding the changes in YAML).

Running the yaml.pl script manually (turning on warnings for good measure),
we get the following output:

 perl -w yaml.pl
---
'/foo/foo- hate': bz
---
'/foo/foo- hate': bz

If we comment out this (the fourth) line in yaml.pl

#print YAML::Dump (YAML::Load (YAML::Dump ($hash)));

we get only one output:

---
'/foo/foo- hate': bz

So, obviously all four lines are being correctly executed when running
yaml.pl directly.

If we un-comment that line (return it back to its original state) and run
the test by executing the debugger manually:

(sid)root@aven:/tmp/libdevel-ebug-perl# perl bin/ebug --backend perl
bin/ebug_backend_perl t/yaml.pl
* Welcome to Devel::ebug 0.52
main(t/yaml.pl#3):
my $hash = { '/foo/foo- hate' = 'bz' };
ebug: n
main(t/yaml.pl#4):
print YAML::Dump ($hash);
ebug: n
ebug: Program finished. Enter 'restart' or 'q'

The program finishes and the debugger does not show that it has executed
the last line in yaml.pl. Thus, the test fails - since we expected another
line to be executed (the YAML Dump/Load/Dump operation).

It is difficult to isolate the cause of this, though that B::Deparse bug
seems promising. I have not done enough spelunking into the internals of
Devel::ebug to say.

Of course, perl's built-in debugger does not seem to suffer from this
problem:

 perl -d -w t/yaml.pl

Loading DB routines from perl5db.pl version 1.33
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(t/yaml.pl:3):my $hash = { '/foo/foo- hate' = 'bz' };
  DB1 n
main::(t/yaml.pl:4):print YAML::Dump ($hash);
  DB1 n
---
'/foo/foo- hate': bz
main::(t/yaml.pl:5):print YAML::Dump (YAML::Load (YAML::Dump ($hash)));
  DB1 n
---
'/foo/foo- hate': bz
Debugged program terminated.  Use q to quit or R to restart,
  use o inhibit_exit to avoid stopping after program termination,
  h q, h R or h o to get additional info.
  DB1

I don't believe anything there has changed, so I am not sure why
Devel::ebug is broken.

Cheers,

Jonathan

Bug#636133: libgtk2-mozembed-perl: FTBFS: gdkconfig.h: No such file or directory

[Jonathan Yu]

Hi,

I have successfully reproduced this issue in a sid chroot, and
subsequently confirmed that this issue (the immediate issue, but not
the FTBFS) can be fixed by rebuilding libgtk2-perl:

[ XS xs/GtkMozEmbed.xs ]
[ CC xs/GtkMozEmbed.c ]
In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from /usr/lib/perl5/Gtk2/Install/gtk2perl.h:29,
 from ./gtkmozembed2perl.h:28,
 from xs/GtkMozEmbed.xs:21:
/usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h:
No such file or directory
compilation terminated.
make[1]: *** [xs/GtkMozEmbed.o] Error 1
make[1]: Leaving directory `/root/libgtk2-mozembed-perl'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

After rebuilding and installing the rebuilt version:

(Reading database ... 26678 files and directories currently installed.)
Preparing to replace libgtk2-perl 2:1.223-1+b1 (using
.../libgtk2-perl_1.223-2_i386.deb) ...
Unpacking replacement libgtk2-perl ...
Setting up libgtk2-perl (2:1.223-2) ...

(this version came out of the pkg-perl git)

[ XS xs/GtkMozEmbed.xs ]
[ CC xs/GtkMozEmbed.c ]
In file included from xs/GtkMozEmbed.xs:21:0:
./gtkmozembed2perl.h:34:25: fatal error: gtkmozembed.h: No such file
or directory
compilation terminated.
make[1]: *** [xs/GtkMozEmbed.o] Error 1
make[1]: Leaving directory `/root/libgtk2-mozembed-perl'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

It looks like the gtkmozembed.h file is no longer available anywhere.
There are a few results from apt-file, but the newest version of
xulrunner (now in sid) is xulrunner-5.0, which does not seem to
provide this file.

apt-file says:

icedove-dev: /usr/include/icedove/gtkmozembed.h
kompozer-dev: /usr/include/kompozer/gtkembedmoz/gtkmozembed.h
xulrunner-dev: /usr/include/xulrunner-1.9.1/unstable/gtkmozembed.h

I think that this package will only be able to build if you restrict
it to build with the previous version of xulrunner...

Cheers,

Jonathan



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

Bug#635668: libdbd-odbc-perl: package may be built with incorrect pointer size on 64-bit systems

[Jonathan Yu]

Package: libdbd-odbc-perl
Severity: grave
Tags: security
Justification: user security hole


Because of changes that Microsoft made to the ODBC specification, the previously
32-bit binary protocol now supports 64-bit values on systems that support it 
(e.g.
on amd64 and possibly the ia64 architectures).

During build time, DBD::ODBC probes for a utility called odbc_config, which, 
like
pkg-config, is intended to provide developers with the compiler flags used to 
build
unixODBC itself. However, because this is not included with Debian's unixODBC 
(it
is not installed into any of the unixodbc binary packages), it is not possible 
to
tell whether the package should be compiled assuming 32-bit or 64-bit data 
types.

When the odbc_config cannot be found (since it is not available in Debian), the
macro SIZEOF_LONG is not defined, so DBD::ODBC assumes that unixODBC was built
with 32-bit-long SQLLEN and SQLULEN.

This raises a potential security issue because unixODBC could write 64-bit 
values
into buffers that are only 32-bits large (DBD::ODBC having provided 32-bit-long
buffers based on the assumption of SQLLEN and SQLULEN being 32-bits).

This issue is explained at length on the blog of the DBD::ODBC upstream 
developer:
http://www.martin-evans.me.uk/node/116

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

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



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

Bug#634397: libjavascript-perl: FTBFS: jslock.h:221:1: error: unknown type name 'namespace'

[Jonathan Yu]

I am able to reproduce this issue on my sid chroot. From a quick
glance at the error messages, it looks like the header files include
C++ code (namespace, new), which is unexpected when trying to link
with it in C-land...

Cheers,

Jonathan

On Mon, Jul 18, 2011 at 6:02 PM, Lucas Nussbaum
lu...@lucas-nussbaum.net wrote:
 Source: libjavascript-perl
 Version: 1.16-3
 Severity: serious
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20110718 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:
 cc -c  -I/usr/include/nspr/ -I/usr/include/mozjs/ -D_REENTRANT -D_GNU_SOURCE 
 -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -DMOZILLA_1_8_BRANCH=1   
 -DVERSION=\1.16\ -DXS_VERSION=\1.16\ -fPIC -I/usr/lib/perl/5.12/CORE   
 JavaScript.c
 In file included from /usr/include/mozjs/jsapi.h:48:0,
                  from JavaScript_Env.h:12,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/js-config.h:50:0: warning: JS_THREADSAFE redefined 
 [enabled by default]
 JavaScript_Env.h:8:0: note: this is the location of the previous definition
 In file included from /usr/include/mozjs/jsobj.h:56:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jslock.h:221:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jslock.h:221:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jsobj.h:57:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jsvalue.h: In function 'JSDOUBLE_IS_INT32':
 /usr/include/mozjs/jsvalue.h:111:16: error: 'false' undeclared (first use in 
 this function)
 /usr/include/mozjs/jsvalue.h:111:16: note: each undeclared identifier is 
 reported only once for each function it appears in
 /usr/include/mozjs/jsvalue.h:112:24: error: expected expression before 
 'int32_t'
 /usr/include/mozjs/jsvalue.h: At top level:
 /usr/include/mozjs/jsvalue.h:241:1: error: conflicting types for 
 'MAGIC_TO_JSVAL_IMPL'
 /usr/include/mozjs/jsvalue.h:233:1: note: previous definition of 
 'MAGIC_TO_JSVAL_IMPL' was here
 /usr/include/mozjs/jsvalue.h:324:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jsvalue.h:324:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jstl.h:43:0,
                  from /usr/include/mozjs/jsvector.h:44,
                  from /usr/include/mozjs/jsobj.h:58,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jsbit.h:255:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jsbit.h:255:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jsvector.h:44:0,
                  from /usr/include/mozjs/jsobj.h:58,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jstl.h:47:15: fatal error: new: No such file or directory
 compilation terminated.
 make[2]: *** [JavaScript.o] Error 1

 The full build log is available from:
   
 http://people.debian.org/~lucas/logs/2011/07/18/libjavascript-perl_1.16-3_lsid64.buildlog

 A list of current common problems and possible solutions is available at
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.

 --
 | Lucas Nussbaum
 | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
 | jabber: lu...@nussbaum.fr             GPG: 1024D/023B3F4F |



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-perl-maintainers




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

Bug#603250: Removal of libfile-temp-perl

[Jonathan Yu]

To whoever might stumble upon this bug,

I looked into it quickly and it looks like libmodule-pluggable-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.

Cheers,

Jonathan



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

Bug#603249: Removal of libfile-temp-perl

[Jonathan Yu]

To whoever might stumble upon this bug,

I looked into it quickly and it looks like libfile-temp-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.

Cheers,

Jonathan



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

Bug#615963: libvendorlib-perl: tilde expansion tests failing

[Jonathan Yu]

Damyan,

I was initially unable to reproduce the issue because sbuild by
default does mount /home inside the chroot.

However, Salvatore told me via IRC that the buildd's are configured in
such a way that they do not have a writable home.

I don't know whether this is an issue with sbuild (though we can
certainly do some sort of hack to get around this issue) or a problem
with the way buildd's are set up.

However, I guess it's preferred if packages being built don't write
junk to /home anyway...

Cheers,

Jonathan



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

Bug#615963: cannot reproduce: tilde expansion tests failing

[Jonathan Yu]

tag 615963 unreproducible
severity 615963 important
thanks

Hello,

I cannot reproduce this issue on my system -- downgrading to important.

Here is the build log:
aven'jon(~/pkg-perl/trunk/libvendorlib-perl) build
Copying package data to temporary build area...
Downloading latest upstream version...
libvendorlib-perl: Version (0.10) available on remote site:
  http://search.cpan.org/CPAN/authors/id/R/RK/RKITOVER/vendorlib-0.10.tar.gz
  (local version is 0.10)
libvendorlib-perl: Successfully downloaded updated package vendorlib-0.10.tar.gz
and symlinked libvendorlib-perl_0.10.orig.tar.gz to it
Building source package...
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package libvendorlib-perl
dpkg-buildpackage: source version 0.10-1
dpkg-buildpackage: source changed by Nicholas Bamber nicho...@periapt.co.uk
 dpkg-source --before-build build
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b build
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building libvendorlib-perl using existing
./libvendorlib-perl_0.10.orig.tar.gz
dpkg-source: info: building libvendorlib-perl in
libvendorlib-perl_0.10-1.debian.tar.gz
dpkg-source: info: building libvendorlib-perl in libvendorlib-perl_0.10-1.dsc
 dpkg-genchanges -S ../libvendorlib-perl_0.10-1_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build build
dpkg-buildpackage: full upload (original source is included)
Building package using sbuild (unstable)...
sbuild (Debian sbuild) 0.60.8 (12 Dec 2010) on aven.local

+--+
¦ libvendorlib-perl 0.10-1 (i386)01 Mar 2011 21:19 ¦
+--+

Package: libvendorlib-perl
Version: 0.10-1
Source Version: 0.10-1
Architecture: i386
E: 80apt-get-update: Ign http://localhost unstable InRelease
E: 80apt-get-update: Get:1 http://localhost unstable Release.gpg [835 B]
E: 80apt-get-update: Get:2 http://localhost unstable Release [146 kB]
E: 80apt-get-update: Get:3 http://localhost unstable/main i386
Packages/DiffIndex [2038 B]
E: 80apt-get-update: Get:4 http://localhost unstable/main
TranslationIndex [2232 B]
E: 80apt-get-update: Get:5 http://localhost unstable/main i386
2011-03-01-1412.05.pdiff [13.3 kB]
E: 80apt-get-update: Get:6 http://localhost unstable/main i386
2011-03-01-1412.05.pdiff [13.3 kB]
E: 80apt-get-update: Get:7 http://localhost unstable/main i386
2011-03-01-2011.01.pdiff [9777 B]
E: 80apt-get-update: Get:8 http://localhost unstable/main i386
2011-03-01-2011.01.pdiff [9777 B]
E: 80apt-get-update: Fetched 175 kB in 58s (2997 B/s)
Ign http://localhost unstable InRelease
Hit http://localhost unstable Release.gpg
Hit http://localhost unstable Release
Hit http://localhost unstable/main i386 Packages/DiffIndex
Hit http://localhost unstable/main TranslationIndex
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
¦ Fetch source files   ¦
+--+


Local sources
-

libvendorlib-perl_0.10-1.dsc exists in /tmp/tmp.xnTx3NkSRz; copying to chroot

Check arch
--


+--+
¦ Install core build dependencies (internal resolver)  ¦
+--+

Build-Depends: build-essential, fakeroot
Checking for already installed dependencies...
build-essential: already installed (11.5)
fakeroot: already installed (1.14.5-2)
Checking for dependency conflicts...
Installing positive dependencies:
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Removing negative dependencies:
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Checking correctness of dependencies...
Cannot open 
/var/lib/schroot/mount/sid-4bbe2c8d-49cf-4f3f-900a-9f84086fcc34/sid/etc/lsb-release:
No such file or directory

+--+
¦ Install libvendorlib-perl build dependencies (internal 

Bug#603737: Should libwww-myspace-perl be removed?

[Jonathan Yu]

block 603737 by 614067
thanks

To all interested parties:

I have requested that this package be removed from the archive. Please
see BTS#614067 for details.

This bug can be closed once 614067 is resolved.

Cheers,

Jonathan



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

Bug#613187: xs/SceneQuery.xs:28: error: cannot convert [..]

[Jonathan Yu]

Dominic,

It looks like the dependencies might've changed recently...
who-uploads for both libogre-dev and libgtk2.0-dev give me nothing,
however:

 libgtk2.0-dev | 2.20.1-2 | squeeze | amd64, armel,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc,
s390, sparc
 libgtk2.0-dev | 2.20.1-2 | wheezy  | amd64, armel,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc,
s390, sparc
 libgtk2.0-dev | 2.20.1-2 | sid | alpha, amd64,
armel, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386,
mips, mipsel, powerpc, s390, sparc

All versions are the same across the suites.

 libogre-dev | 1.6.4.dfsg1-1 | squeeze | amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 libogre-dev | 1.6.4.dfsg1-1 | wheezy  | amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 libogre-dev | 1.6.4.dfsg1-1 | sid | armel, mips
 libogre-dev | 1.7.1-1   | sid | alpha, amd64, hppa,
hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mipsel, powerpc,
s390, sparc

It looks like libogre-dev was upgraded recently enough to not have
migrated to testing yet.

The upstream changelog for libogre-perl (new version is 0.50) has:

0.50 2010-12-14 | support Ogre = 1.7.2
- dropping support for versions of Ogre before 1.7.2 (released 2010-11-03)
- removed Readonly (optional) dependence (for one example)
- ported to 1.7.2

So perhaps this fix also makes Ogre work with libogre-dev = 1.7.1?

At this point, it looks like Ogre may not support 1.7.1, and the new
version doesn't support the existing libogre-dev (not tested by me yet
though, just based on the changelog entry). A bit of a tricky
situation indeed.

Cheers,

Jonathan

On Sun, Feb 13, 2011 at 8:18 AM, Dominic Hargreaves d...@earth.li wrote:
 Package: libogre-perl
 Version: 0.40-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)

 This package failed to build on sid i386 today:

 g++ -c  -pthread -I/usr/include/OGRE   -pthread -I/usr/include/gtk-2.0 
 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo 
 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 
 -I/usr/include/libpng12 -I/usr/include/libdrm   -Wno-write-strings -O2 -g   
 -DVERSION=\0.40\ -DXS_VERSION=\0.40\ -fPIC -I/usr/lib/perl/5.10/CORE  
 -DPERLOGRE_HAS_GTK2 Ogre.c
 xs/SceneQuery.xs: In function 'void 
 XS_Ogre__SceneQuery_getSupportedWorldFragmentTypes(PerlInterpreter*, CV*)':
 xs/SceneQuery.xs:28: error: cannot convert 'const 
 std::setOgre::SceneQuery::WorldFragmentType, 
 std::lessOgre::SceneQuery::WorldFragmentType, 
 Ogre::STLAllocatorOgre::SceneQuery::WorldFragmentType, 
 Ogre::CategorisedAllocPolicy(Ogre::MemoryCategory)0u  *' to 'const 
 std::setOgre::SceneQuery::WorldFragmentType, 
 std::lessOgre::SceneQuery::WorldFragmentType, 
 std::allocatorOgre::SceneQuery::WorldFragmentType *' in initialization
 Ogre.c: In function 'void 
 XS_Ogre__Root__setCurrentSceneManager(PerlInterpreter*, CV*)':
 Ogre.c:14683: error: 'class Ogre::Root' has no member named 
 '_setCurrentSceneManager'
 xs/ResourceGroupManager.xs: In function 'void 
 XS_Ogre__ResourceGroupManager_DEFAULT_RESOURCE_GROUP_NAME(PerlInterpreter*, 
 CV*)':
 xs/ResourceGroupManager.xs:28: error: 'BOOTSTRAP_RESOURCE_GROUP_NAME' is not 
 a member of 'Ogre::ResourceGroupManager'
 xs/RenderSystem.xs: In function 'void 
 XS_Ogre__RenderSystem_bindGpuProgramParameters(PerlInterpreter*, CV*)':
 xs/RenderSystem.xs:123: error: no matching function for call to 
 'Ogre::RenderSystem::bindGpuProgramParameters(Ogre::GpuProgramType, 
 Ogre::GpuProgramParametersSharedPtr)'
 /usr/include/OGRE/OgreRenderSystem.h:1103: note: candidates are: virtual void 
 Ogre::RenderSystem::bindGpuProgramParameters(Ogre::GpuProgramType, 
 Ogre::GpuProgramParametersSharedPtr, Ogre::uint16)
 xs/Node.xs: In function 'void XS_Ogre__Node_getMaterial(PerlInterpreter*, 
 CV*)':
 xs/Node.xs:320: error: 'class Ogre::Node' has no member named 'getMaterial'
 Ogre.c: In function 'void XS_Ogre__Node_getRenderOperation(PerlInterpreter*, 
 CV*)':
 Ogre.c:30052: error: 'class Ogre::Node' has no member named 
 'getRenderOperation'
 Ogre.c: In function 'void 
 XS_Ogre__MovableObject_detatchFromParent(PerlInterpreter*, CV*)':
 Ogre.c:30567: error: 'class Ogre::MovableObject' has no member named 
 'detatchFromParent'
 Ogre.c: In function 'void 
 XS_Ogre__Mesh_getLodIndexSquaredDepth(PerlInterpreter*, CV*)':
 Ogre.c:32217: error: 'class Ogre::Mesh' has no member named 
 'getLodIndexSquaredDepth'
 Ogre.c: In function 'void 
 XS_Ogre__Material_getLodIndexSquaredDepth(PerlInterpreter*, CV*)':
 Ogre.c:35427: error: 'class Ogre::Material' has no member named 
 'getLodIndexSquaredDepth'
 Ogre.c: In function 'void 
 XS_Ogre__GpuProgram_setSurfaceAndPassLightStates(PerlInterpreter*, 

Bug#591974: Looks like we should drop libmojomojo-perl for squeeze

[Jonathan Yu]

Hi,

We've spoken to the upstream maintainers, who say that removing the
offending swfupload parts should be okay.

I'll spend some time (hopefully tonight) repacking to remove those
parts. My only concern was that swfupload should be made available in
non-free prior to the removal of those parts from libmojomojo-perl,
and the RFP for swfupload is still outstanding.

I'm not sure how to best proceed. I can certainly remove the swfupload
stuff from libmojomojo-perl, which will close that RC bug, but it
opens another wishlist bug since it's not possible to easily install
the full libmojomojo-perl as per upstream (i.e. MojoMojo +
swfupload).

See: http://lists.debian.org/debian-wnpp/2010/11/msg00070.html (RFP #602253)

Your advice would be greatly appreciated.

Cheers,

Jonathan

On Thu, Nov 25, 2010 at 6:32 AM, Alexander Reichle-Schmehl
toli...@debian.org wrote:
 Hi David!

 * David Bremner brem...@unb.ca [101113 21:58]:

 So I would say not quite yet for removal, but if nothing starts moving
 in the next week or so I would not oppose removal.

 I was looking through open RC bugs and stumbled over this one.  I was
 wondering, if you can report any progress on this bug?


 Best Regards,
  Alexander




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

Bug#551926: [Python-modules-team] Bug#551926: cannot be installed together with pip or pip-python

[Jonathan Yu]

Hi,

On Sat, May 8, 2010 at 4:51 AM, Sandro Tosi mo...@debian.org wrote:
 I think the issue has been open for long enough without clear consensus.
 Hence all packages should rename their /usr/bin/pip to something else and
 document the difference vs upstream in README.Debian.

 BTW, finding new names is hard, but choosing a 3 letter acronym is a
 recipe for problems...

I don't want to keep beating this dead horse, but the position from
the Perl community is that:
1. We picked the name 'pip' first (the release of Perl's pip precedes
Python's pip)
2. The author of Python's pip was informed of the naming conflict on his blog
3. The author chose to ignore it

And now we're in this mess. So, either the author is a jerk, or he
just didn't think anyone would be installing both on the same system.
But as we have the 'pip' package name, I think it is fair we get the
'pip' script name.

I see no reason for Perl's pip to have to change its name, simply
because the author of Python's pip chose a name which was already in
use by someone else, and because the author was already informed that
something like this might happen, and chose to proceed anyway.

 of course I'm s little biased on this, but I'm attending Pycon italia
 and 2 talks (over the 4 given by know) already provide explicit
 references to pip and also about how to use it (that's as simple as
 pip install module).

What happens if someone releases a script called 'sh' and wants to
install it to /usr/bin/sh? Despite being informed that obviously it
conflicts with peoples' shells. I consider this a similar problem, but
on a much smaller scale (obviously Perl's pip is not as popular as
sh), but the point is still valid.

 would be another source of frustration for the python community
 willing to use debian (and that community is already being harmed
 several times).

Rather than cripple Perl's pip, if it's really not in use by anyone, I
think we should just remove the pip package and let Python take over
the name and /usr/bin path. But if it is in use, then given the author
of the Python script had advance warning, I think the Python
community effectively did this harm to themselves.

I do not think it is unreasonable to think of script names the same as
module names, as: on a first-come, first-served basis -- it is the
responsibility of each author to do a search to make sure they are not
picking the same names as anyone else. Not only did he fail to do
adequate research, he failed to predict this would happen and change
the name accordingly.

In summary: if we do not need the Perl version, remove it. If we need
the Perl version, its name should stay as 'pip'. This decision should
be made irrespective of Python's pip, because Perl's pip came first
(so I think it deserves that privilege).

Cheers,

Jonathan



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

Bug#577045: libmodern-perl-perl vs libmodern-perl

[Jonathan Yu]

On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler ivan-deb...@420.am wrote:
 Originally I had uploaded libmodern-perl-perl by accident and was
 surprised it made it through NEW.  I was planning on asking for removal
 (and for libmodern-perl to be renamed to or Provide:
 libmodern-perl-perl).

 However it seems that David Moreno da...@debian.org may be MIA-ish?
 (The most recent activity I can find is an upload of libxml-treepp-perl
 on 2009-08-26?)

 So I am considering just running with libmodern-perl-perl (via pkg-perl
 svn) and asking for libmodern-perl's removal.

 Any objections?
I fully agree with this course of action, as long as you're careful
that reverse dependencies of libmodern-perl are identified and fixed.
Otherwise, we can also provide a temporary dummy package, but I think
getting the reverse dependencies fixed should be our priority.

 --
 _ivan


 --
 To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20100418181800.gc13...@420.am





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

Bug#577045: libmodern-perl-perl vs libmodern-perl

[Jonathan Yu]

On Sun, Apr 18, 2010 at 3:00 PM, Ivan Kohler ivan-deb...@420.am wrote:
 On Sun, Apr 18, 2010 at 02:42:08PM -0400, Jonathan Yu wrote:
 On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler ivan-deb...@420.am wrote:
  So I am considering just running with libmodern-perl-perl (via pkg-perl
  svn) and asking for libmodern-perl's removal.
 
 I fully agree with this course of action, as long as you're careful
 that reverse dependencies of libmodern-perl are identified and fixed.
 Otherwise, we can also provide a temporary dummy package, but I think
 getting the reverse dependencies fixed should be our priority.

 There are no reverse deps.  I'm guessing Replaces: libmodern-perl
 should be sufficient for unstable/testing folks that have
 libmodern-perl installed?
I believe it both Replaces libmodern-perl (that means files in
libmodern-perl-perl overwrite ones in libmodern-perl) and Provides
libmodern-perl (ie, a virtual package). Depending on what is needed,
transitional empty binary packages may be needed as well. But if there
are no reverse deps we don't need to bother with any of that, simply
removing libmodern-perl should be good..

 --
 _ivan


 --
 To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20100418190036.gd13...@420.am





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

Bug#569920: libcairo-perl: fails to load with new libdirectfb

[Jonathan Yu]

Package: libcairo-perl
Severity: grave
Justification: renders package unusable


This package seems to be unusable with the newest version of
libdirectfb.

Building Graphics::Primitive::Driver::Cairo yielded the following
test output (see libgraphics-primitive-driver-cairo-perl in the
Debian Perl Group repository):

t/00-load.t  
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
Can't load '/usr/lib/perl5/auto/Cairo/Cairo.so' for module Cairo: 
libdirectfb-1.2.so.0: cannot open shared object file: No such file or directory 
at /usr/lib/perl/5.10/DynaLoader.pm line 193.
 at 
/build/jon-libgraphics-primitive-driver-cairo-perl_0.43-1-i386-o6cS9N/libgraphics-primitive-driver-cairo-perl-0.43/blib/lib/Graphics/Primitive/Driver/Cairo.pm
 line 5
Compilation failed in require at 
/build/jon-libgraphics-primitive-driver-cairo-perl_0.43-1-i386-o6cS9N/libgraphics-primitive-driver-cairo-perl-0.43/blib/lib/Graphics/Primitive/Driver/Cairo.pm
 line 5.
BEGIN failed--compilation aborted at 
/build/jon-libgraphics-primitive-driver-cairo-perl_0.43-1-i386-o6cS9N/libgraphics-primitive-driver-cairo-perl-0.43/blib/lib/Graphics/Primitive/Driver/Cairo.pm
 line 5.
Compilation failed in require at t/10-complex-border.t line 7.
BEGIN failed--compilation aborted at t/10-complex-border.t line 7.

Inspecting the package in a chroot, a different API version of
libdirectfb is now installed. I'm not sure how to proceed here,
except perhaps conflict with the newer version or rebuild.

A rebuild of the Cairo bindings (libcairo-perl) should fix it,
but moving forward, I'd like to investigate a more robust and
resilient system (that won't result in breakages whenever a
new version of libdirectfb is uploaded).

After installing libcairo-perl (including directfb which is one
of the dependencies), the following files are put in /usr/lib:
  # ls /usr/lib/libdirectfb*
  /usr/lib/libdirectfb-1.2.so.9  /usr/lib/libdirectfb-1.2.so.9.0.1

The same error happens trying to load Cairo:
  # perl -MCairo -e1
  Can't load '/usr/lib/perl5/auto/Cairo/Cairo.so' for module Cairo: 
libdirectfb-1.2.so.0: cannot open shared object file: No such file or directory 
at /usr/lib/perl/5.10/DynaLoader.pm line 193. at -e line 0
  Compilation failed in require.
  BEGIN failed--compilation aborted.

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

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100215033007.27900.39796.report...@nemesis.jagerman.com

Bug#564384: libpoe-component-ikc-perl: FTBFS: tests hang

[Jonathan Yu]

On Tue, Feb 9, 2010 at 3:08 AM, Damyan Ivanov d...@debian.org wrote:
 -=| Jonathan Yu, Mon, Feb 08, 2010 at 07:49:16PM -0500 |=-
 It looks like the best way to fix this issue is to add a
 HAS_INTERNET (or perhaps in this case, HAS_LOCALHOST or HAS_NETWORK)
 style flag to disable tests unless it is known that localhost is
 available.

 localhost should be available on buildds, no? We already build-depend
 on netbase.
I guess it could be available, but firewalled via iptables for some reason?

 On Sat, Jan 9, 2010 at 5:38 AM, Lucas Nussbaum
 lu...@lucas-nussbaum.net wrote:
  Source: libpoe-component-ikc-perl
  Version: 0.2200-1
  Severity: serious
  User: debian...@lists.debian.org
  Usertags: qa-ftbfs-2010-01-08 qa-ftbfs
  Justification: FTBFS on amd64
 
  t/30_local.t .. ok
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
  E: Caught signal 'Terminated': terminating immediately
  make: *** [build-stamp] Terminated
  make[1]: *** wait: No child processes.  Stop.
  make[1]: *** Waiting for unfinished jobs
  make[1]: *** wait: No child processes.  Stop.
  Build killed with signal TERM after 60 minutes of inactivity
  
  Build finished at 20100108-2153
 
  The full build log is available from:
    
  http://people.debian.org/~lucas/logs/2010-01-08/libpoe-component-ikc-perl_0.2200-1_lsid64.buildlog

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQIcBAEBCAAGBQJLcRfgAAoJEOQbTFV/DYC+l9QP/RUxGRx4ahefajZOkkz7IDuU
 3UE8SvFsuc7O2EJLd/JPkC9VfqmOvFZkrKle0WDIDLGTEEfQdYawrrBGZRub9XPf
 i+2/+TtT5dXnHWDC6tlK8DnPvVJbd+7HURLftbiFp9zQwoBMYgsdgFA7CNTBp8BR
 oK7zVVtxS+B00JLRavvsfBa0Kqi7eDtr/bZyJ5jT/Q9TJFtuwfNmr3+lUqHfmWCv
 eu9KfzhHj9IH4Ip8VByX6EFpDkzs907R0J2EVrYP6RBhYhWlZnDLQ7yqHB55wSG7
 cletSBVHwGwEat7jDqnVlCP0QsQVnf0mAJZqY1aEPcaDmeN4V2Aaeau1cJXifEPj
 l8KSaku+qx1+q43WOBD07IvSGqYW7HjUpy4NpetFOICJDcJCKWO85uju/M3CFA3G
 LpWGpl62za6bkJe6Nhan8wfsgfVkERB8HIN2Xm9gazZMu+fjRAE/59bVYL18v8tX
 ZQlVrOWI5ACnauEd5IYtOG1CxDtWIanIE47e+CvFqGM82W4BN+cF8zNKEwDDBV25
 w15Oci93xLD66Q0Rrd+Sf+xtfd02sPNGC9d+yRulijDY1ApZqt/HMkOBYQ+gFAqr
 2jpYpAJZ3aXSoRPTh1c4i9ocEKssHXiG7E3TguohnlTpTnwJMOcB2EB8vzkMIm3k
 /2xAi7jRMM9GWB+xcfi5
 =+3Cy
 -END PGP SIGNATURE-





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

Bug#564384: libpoe-component-ikc-perl: FTBFS: tests hang

[Jonathan Yu]

Hi Lucas,

Thanks for the bug report.

It looks like the best way to fix this issue is to add a
HAS_INTERNET (or perhaps in this case, HAS_LOCALHOST or HAS_NETWORK)
style flag to disable tests unless it is known that localhost is
available.

Cheers,

Jonathan

On Sat, Jan 9, 2010 at 5:38 AM, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
 Source: libpoe-component-ikc-perl
 Version: 0.2200-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-2010-01-08 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:
 make[1]: Entering directory 
 `/build/user-libpoe-component-ikc-perl_0.2200-1-amd64-BjYwvY/libpoe-component-ikc-perl-0.2200'
 PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e 
 test_harness(0, 'blib/lib', 'blib/arch') t/*.t
 t/00_compile.t  ok
 t/01_pod.t  ok
 t/02_pod_coverage.t ... ok
 t/05_perl_freezer.t ... ok
 t/05_specifier.t .. ok
 t/10_server_client.t .. ok
 t/20_clientlite.t . ok
 t/30_local.t .. ok
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 Timeout connecting to localhost:43282 at t/31_concurrency.t line 296.
 E: Caught signal 'Terminated': terminating immediately
 make: *** [build-stamp] Terminated
 make[1]: *** wait: No child processes.  Stop.
 make[1]: *** Waiting for unfinished jobs
 make[1]: *** wait: No child processes.  Stop.
 Build killed with signal TERM after 60 minutes of inactivity
 
 Build finished at 20100108-2153

 The full build log is available from:
   
 http://people.debian.org/~lucas/logs/2010-01-08/libpoe-component-ikc-perl_0.2200-1_lsid64.buildlog

 A list of current common problems and possible solutions is available at
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.

 --
 | Lucas Nussbaum
 | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
 | jabber: lu...@nussbaum.fr             GPG: 1024D/023B3F4F |



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers



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

Bug#566587: FTBFS: tests fail

[Jonathan Yu]

Hi all:

I have confirmed this bug with sbuild/schroot + amd64. As with
Salvatore, I did not have the issue with x86.

I'm hesitant to apply gregoa's patch because it seems like it might
have problems where machines *cannot* left-shift 62 bits... If the
register is only 32-bits wide (as with i386 on older machines), then
this may result in data falling off the end (and $low4bytes will be
zeroed out).

I think we can look into something with the Config module, which will
tell us various info that perl -V tells us, such as:
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678

If we can confirm gregor's fix works when intsize=4, longsize=4,
ptrsize=4 (ie, older 32-bit only processors) then we can consider
that. Otherwise, I'd prefer to use $Config to determine information
about the architecture and select the appropriate bit twiddling.

(Better yet, it seems like there should be an upstream module that
does this sort of thing, like keep only X bits of data or
something...)

Cheers,

Jonathan



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

Bug#562347: Coat::Persistent and Net::Google::Code FTBFS

[Jonathan Yu]

Lucas,

Thanks for these reports. Unfortunately, both of these have new
versions (which may or may not fix these FTBFS), except they are
themselves failing to build (which is why I haven't uploaded them
yet).

Now that this affects packages currently in the repository, we'll
prioritize them and look closer and trying to get them to build.

Cheers,

Jonathan



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

Bug#559770: RM: libwordpress-xmlrpc-perl/testing -- ROM; Based on recent source changes, we believe the quality of code is poor.

[Jonathan Yu]

Here are some reasons why:

1. We discussed this in the ITP for libleocharre-perl [0]; the whole
idea of the LEOCHARRE:: modules is flawed in many ways, and also
exports random symbols to the 'main' namespace with no way of stopping
it from doing so.

2. The overhead involved with patching in the needed LEOCHARRE::
features is probably going to be big in the long term

3. There is a critical security issue due to inclusion of WordPress' XMLRPC [1]

4. Low popcon score

5. Not in stable (only unstable and testing)

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559524
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559770
[2] http://qa.debian.org/popcon.php?package=libwordpress-xmlrpc-perl



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

Bug#559770: libwordpress-xmlrpc-perl embeds wordpress' xmlrpc

[Jonathan Yu]

Hi:

Thank you for your bug report.

It should be noted that this module is destined for removal from
unstable and testing due to some new dependencies (LEOCHARRE::
modules) which we would rather not package. The code quality of those
files was questionable (such as dumping random things into the main
namespace), and the consensus amongst the group was that removal of
Wordpress-XMLRPC was the best option.

Given that this module is not yet in stable, I'm not sure whether we
should spend the time investigating this -- the package
libwordpress-xmlrpc-perl will be removed from testing and unstable
some time this week, probably over the next few days unless
significant objections are raised and a suitable solution is
discovered.

For discussion of the removal, please see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559524

This would seem to be the final nail in the coffin for this package.

Cheers,

Jonathan



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

Bug#551926: bug #551926: python-pip and pip: error when trying to install together

[Jonathan Yu]

Hi:

[Cc'ing Adam Kennedy since I'm not sure if he's subscribed to debian-devel]

Since Adam mentions that Perl's pip predates Python's pip by a
significant margin, I think we should close this issue by renaming
Python's installer back to pyinstall. It doesn't seem fair for someone
who came on the scene later (who didn't do the appropriate research,
and who, when prompted with the problem, decided to proceed with pip
anyway) to be able to usurp the namespace from Perl.

I'd personally object to renaming Perl's pip to anything else given
these issues.

An alternative arrangement I'd be open to is:
/usr/bin/pip points to a sh script, which tells the user that `pip'
has been renamed to perl-pip and python-pip in Debian. This way,
neither pip gets the /usr/bin/pip name. However, I'm not sure about
how to do this (I guess it'd need to be handled like the dual-life
Perl modules are, via divert and all that...). Again, I don't think
it's fair for Perl's pip to lose `pip' just because some other author
is a jerk (even if Python's pip just so happened to be packaged
first).

Cheers,

Jonathan

On Sun, Nov 29, 2009 at 8:01 PM, Adam Kennedy
adamkennedybac...@gmail.com wrote:
 http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/

 The Perl package predates the Python one by several years.

 The author was made aware of the clash well before it was shipped to
 Debian and chose to continue anyway.

 Adam K

 2009/11/30 Tim Retout t...@retout.co.uk:
 [Resending to the *actual* debian-devel address. :) D'oh.]

 According to Debian Policy 10.1 [*], when two binaries have different
 functionality but the same name, this should be reported to the
 debian-devel mailing list.

 [*] http://www.debian.org/doc/debian-policy/ch-files.html#s10.1

 In this case, 'pip' and 'python-pip' both ship /usr/bin/pip, but one is
 for Perl and one is for Python. The 'python-pip' package has precedence
 in Debian (and indeed, is the only one in testing), so I propose that
 the Perl pip package must pick a pseudonym for its program.

 My first suggestion is 'pip-perl', so that it's still possible to find
 via tab-completion on 'pip'.  Better ideas welcomed, otherwise I'll make
 the change in a few days.

 This isn't ideal for having the same name for the Perl pip on all
 platforms, I know - but until we fix this, there will be a serious bug
 on 'pip', and it will not be released with Debian.

 Regards,

 --
 Tim Retout t...@retout.co.uk




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





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

Bug#556538: libclass-xsaccessor-perl: tries to overwrite file on upgrade

[Jonathan Yu]

Hi:

Recommended resolution: remove libclass-xsaccessor-array-perl from
unstable (and thus testing). It does not exist in stable or oldstable.

On Mon, Nov 16, 2009 at 11:20 AM, gregor herrmann gre...@debian.org wrote:
 Package: libclass-xsaccessor-perl
 Version: 1.05-1
 Severity: serious
 Justification: upgrade fails

I believe this is because Class::XSAccessor::Array no longer exists
upstream as its own package.

A search for it shows:

Class::XSAccessor
Generate fast XS accessors without runtime compilation
Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

Class::XSAccessor::Heavy
Guts you don't care about
Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

Class::XSAccessor::Array
Generate fast XS accessors without runtime compilation
Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

http://search.cpan.org/search?m=alln=100query=class-xsaccessor

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 The upgrade from 1.02-1 to 1.05-1 fails with:

 Preparing to replace libclass-xsaccessor-perl 1.02-1 (using 
 .../libclass-xsaccessor-perl_1.05-1_i386.deb) ...
 Unpacking replacement libclass-xsaccessor-perl ...
 dpkg: error processing 
 /var/cache/apt/archives/libclass-xsaccessor-perl_1.05-1_i386.deb (--unpack):
  trying to overwrite '/usr/lib/perl5/Class/XSAccessor/Array.pm', which is 
 also in package libclass-xsaccessor-array-perl 0:1.02-1

 Cheers,
 gregor

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

 Kernel: Linux 2.6.31.200910290028
 Locale: LANG=C, lc_ctype=de...@euro (charmap=ISO-8859-15)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages libclass-xsaccessor-perl depends on:
 ii  libc6                         2.10.1-7   GNU C Library: Shared libraries
 ii  perl                          5.10.1-7   Larry Wall's Practical Extraction
 ii  perl-base [perlapi-5.10.0]    5.10.1-7   minimal Perl system

 libclass-xsaccessor-perl recommends no packages.

 libclass-xsaccessor-perl suggests no packages.

 - -- no debconf information

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAksBe3gACgkQOzKYnQDzz+QWsACgwTHsYtNxtjxQ4eEJkVWpB5Le
 /jIAn33KSCgj6GUdL7d1iYx7tn0jQ0pU
 =xO7j
 -END PGP SIGNATURE-



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#556538: libclass-xsaccessor-perl: tries to overwrite file on upgrade

[Jonathan Yu]

On Tue, Nov 17, 2009 at 8:59 PM, Jonathan Yu jonathan.i...@gmail.com wrote:
 Hi:

 Recommended resolution: remove libclass-xsaccessor-array-perl from
 unstable (and thus testing). It does not exist in stable or oldstable.

 On Mon, Nov 16, 2009 at 11:20 AM, gregor herrmann gre...@debian.org wrote:
 Package: libclass-xsaccessor-perl
 Version: 1.05-1
 Severity: serious
 Justification: upgrade fails

 I believe this is because Class::XSAccessor::Array no longer exists
 upstream as its own package.

 A search for it shows:

 Class::XSAccessor
 Generate fast XS accessors without runtime compilation
 Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

 Class::XSAccessor::Heavy
 Guts you don't care about
 Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

 Class::XSAccessor::Array
 Generate fast XS accessors without runtime compilation
 Class-XSAccessor-1.05* (2 Reviews) - 15 Nov 2009 - Steffen Müller

 http://search.cpan.org/search?m=alln=100query=class-xsaccessor

I just checked the reverse dependencies too

 apt-cache rdepends libclass-xsaccessor-array-perl
libclass-xsaccessor-array-perl
Reverse Depends:
  padre

So we'll need to add a Provides for now too.

padre has depends on: libclass-xsaccessor-perl (= 1.02),
libclass-xsaccessor-array-perl (= 1.02)

I'm not sure if this means we need a dummy
libclass-xsaccessor-array-perl package for transitional purposes.

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 The upgrade from 1.02-1 to 1.05-1 fails with:

 Preparing to replace libclass-xsaccessor-perl 1.02-1 (using 
 .../libclass-xsaccessor-perl_1.05-1_i386.deb) ...
 Unpacking replacement libclass-xsaccessor-perl ...
 dpkg: error processing 
 /var/cache/apt/archives/libclass-xsaccessor-perl_1.05-1_i386.deb (--unpack):
  trying to overwrite '/usr/lib/perl5/Class/XSAccessor/Array.pm', which is 
 also in package libclass-xsaccessor-array-perl 0:1.02-1

 Cheers,
 gregor

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

 Kernel: Linux 2.6.31.200910290028
 Locale: LANG=C, lc_ctype=de...@euro (charmap=ISO-8859-15)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages libclass-xsaccessor-perl depends on:
 ii  libc6                         2.10.1-7   GNU C Library: Shared libraries
 ii  perl                          5.10.1-7   Larry Wall's Practical 
 Extraction
 ii  perl-base [perlapi-5.10.0]    5.10.1-7   minimal Perl system

 libclass-xsaccessor-perl recommends no packages.

 libclass-xsaccessor-perl suggests no packages.

 - -- no debconf information

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAksBe3gACgkQOzKYnQDzz+QWsACgwTHsYtNxtjxQ4eEJkVWpB5Le
 /jIAn33KSCgj6GUdL7d1iYx7tn0jQ0pU
 =xO7j
 -END PGP SIGNATURE-



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers





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

Bug#533938: libpoex-role-sessioninstantiation-perl: FTBFS: tests failed

[Jonathan Yu]

On Tue, Sep 22, 2009 at 5:46 AM, Niko Tyni nt...@debian.org wrote:
 On Tue, Sep 01, 2009 at 09:13:35PM +0200, gregor herrmann wrote:
 On Tue, 01 Sep 2009 12:57:12 +0300, Damyan Ivanov wrote:

   The new upstream release 0.092280-1 doesn't FTBFS anymore.
   At the moment it waits for the new (build) dependency
   libpoex-types-perl (ITP: #543255, already in NEW).
  libpoex-types-perl was ACCEPTED, but libpoex-role-sessioninstantiation-perl
  still fails the tests here:

 Yeah, happens now here too.

 FWIW, the version of libpoex-role-sessioninstantiation-perl currently
 in the pkg-perl SVN repository (0.092460-1) fails its tests with
 libpoex-types-perl 0.091420-1 but passes with the latests upstream
 version 0.092460.

 Therefore updating libpoex-types-perl and
 libpoex-role-sessioninstantiation-perl to their latest upstream versions
 should be enough to solve this bug.
Thanks Niko. I've been sitting on the libpoe-perl package for awhile
because I wasn't sure how to deal with the split (it went from a
monolithic package to having loops in separate packages). I am working
on getting those uploaded, at which point the new libpoe-perl will be
available, and the new libpoex-types-perl can be uploaded.
 --
 Niko Tyni   nt...@debian.org



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#547631: Bug#547628: Bug#547631: Bug#547628: libclass-accessor-perl: breaks lintian

[Jonathan Yu]

On Mon, Sep 21, 2009 at 10:41 AM, gregor herrmann gre...@debian.org wrote:
 On Mon, 21 Sep 2009 13:46:37 +0300, Niko Tyni wrote:

  JFTR: #547631 and #547628 address the same problem.
 Lintian::Output uses multiple inheritance, and Class::Accessor introduced
 an import subroutine in 0.34 that wins over Exporter::import().
 I'm attaching a patch for lintian that should fix this.

 Cool, thanks a lot!

 Not sure if Class::Accessor actually did anything wrong here.

 It's also my impression that this is supposed to be fixed on the
 lintian side.
Agreed.

 For libclass-accessor-perl I've been thinking about adding
 Breaks: lintian (= 2.2.16~)
 to keep the package away from not-yet-upgraded systems before lintian
 gets upgraded.
I would disagree with the idea of coupling a (seemingly) unrelated
package with something else like lintian -- I'm not sure if this
version of class-accessor also breaks other packages which should be
noted by Breaks, but for which a bug report has not yet been filed.

However, this does seem like an appropriate solution, at least in the
case of such a popular package as lintian. I fear that other packages
that exhibit similar behaviour may be missed, however, if they are
less popular. I'm guessing we'd really have no way of knowing without
a full rebuild of everything.

I apologize for not noting these issues in a NEWS file, so perhaps we
should do that as well, so that users of DarkPAN or GreyPAN packages
that depend on this behaviour (and also those of less popular packages
for which we have not yet received FTBFS bugs) will know what
happened, too.

 /*
 lintian is at 2.2.15 now, and
 2.2.15 = 2.2.16~ = 2.2.16
 */

 Does that sound helpful?

 Cheers,
 gregor
 --
  .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
  : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
  `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Nguyên Lê: Mangustao

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAkq3kH0ACgkQOzKYnQDzz+SwBwCdFojjTSrmwyHEsyHg7xPmm1bC
 Xf8AmgMWiZ1fIPQcroknLbbvUg3UIek5
 =Hnwv
 -END PGP SIGNATURE-

 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#544659: libfilehandle-unget-perl: Broken maintainer address

[Jonathan Yu]

Hi Joerg:

On Wed, Sep 2, 2009 at 3:23 AM, Joerg Jaspertjo...@debian.org wrote:
 Package: libfilehandle-unget-perl
 Severity: serious

  jaw...@cpan.org
    SMTP error from remote mail server after RCPT TO:jaw...@cpan.org:
    host cpan.mx.develooper.com [207.171.7.216]: 550 the lights are out, no 
 such recipient (sf)

Thanks for the note. I actually discovered this issue yesterday and
made the appropriate changes on the CPAN server to fix it, but I guess
it took awhile for the information to propagate to the correct server.

I just sent myself a test mail and it seems to be working correctly now.

I apologize for the inconvenience, please verify that it's working
from your end (send me a test mail to jaw...@cpan.org) and then I'll
close this bug.

Thanks again.

Cheers,

Jonathan


 --
 bye, Joerg
 Free beer is something that I am never going to drink and free speech is
 something that people are never going to be allowed to. ;)

 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#538274: libmodule-cpants-analyse-perl: Missing runtime dependency on Software::LicenseUtils

[Jonathan Yu]

Package: libmodule-cpants-analyse-perl
Version: latest unstable
Severity: grave
Justification: renders package unusable


Running a Kwalitee t est using Module::CPANTS causes this error:
t/01kwalitee.t .. cannot load Module::CPANTS::Kwalitee::Files: Can't locate 
Software/LicenseUtils.pm in @INC (@INC contains: 
/home/jon/cpan/Video-FourCC-Info/blib/lib 
/home/jon/cpan/Video-FourCC-Info/blib/arch /etc/perl /usr/local/lib/perl/5.10.0 
/usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 
/usr/share/perl/5.10 /usr/local/lib/site_perl .) at 
/usr/share/perl5/Module/CPANTS/Kwalitee/Files.pm line 10.

However it's not covered in the upstream module's tests, that's why it doesn't 
trigger an FTBFS. It's an upstream bug (due to an incomplete testsuite and 
missing dependency in META.yml. It should be noted that this bug might have 
been found more easily if the test modules weren't removed, though that was 
necessary due to noncompliance with DFSG.

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

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#521969: libdbd-pg-perl: FTBFS: Perl::Critic errors

[Jonathan Yu]

Perl::Critic is an author test. Sometimes authors may write tests that
are broken and not bother to fix them, because they're run only by
authors. Likely the author saw those failures while building and chose
to ignore them for one reason or another. A fix would be to provide a
perlcriticrc file which can explicitly exclude those tests, but that's
all we can do. the problem is, really, upstream.

If the test is disabled it should build fine, and not really harm
program functionality. I'm not sure of the specifics of writing DBD
drivers, so perhaps those class names are required by the particular
driver interface.

Still, I recommend just packaging the module and skipping that test.
It would be simple to add a plan skip all to the top...

On Tue, Mar 31, 2009 at 12:04 PM, gregor herrmann gre...@debian.org wrote:
 tags 521969 + confirmed
 forwarded 521969 http://rt.cpan.org/Public/Bug/Display.html?id=44704
 thanks

 On Mon, 30 Mar 2009 17:53:43 -0700, Daniel Schepler wrote:

 Package: libdbd-pg-perl
 Version: 2.11.7-1
 Severity: serious

 From my pbuilder build log:

 ...
 t/99_perlcritic.#
 # File: Pg.pm (line 157)
 # Vio: Package DBD::Pg::dr does not start with a upper case letter
 # Policy: NamingConventions::Capitalization
 # Source: package DBD::Pg::dr;

 Thanks, the tests still fail with 2.12.0.
 I've forwarded the bug upstream and I'll turn off the Perl::Critic
 tests in debian/rules for the time being.

 Cheers,
 gregor
 --
  .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
  : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
  `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Eagles

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iEYEARECAAYFAknSPxcACgkQOzKYnQDzz䡵ည୒䯅ꮴ㴖Ṳ䢹慴ᦴ�
 L48AoPVh0drvqkaVbGNhsj8HgxHoujGH
 =FAni
 -END PGP SIGNATURE-

 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#521969: libdbd-pg-perl: FTBFS: Perl::Critic errors

[Jonathan Yu]

Hi:

These seem like changes which should be proposed on the RT upstream.

After being unmaintained for many months, it's now starting to get
some support and teams have been put together to take over the
project. So I encourage you to submit patches or bug reports upstream
so they can get fixed. It's nothing serious (just perlcritic
failures)... Shouldn't affect program operation but would be useful to
fix for future releases.

Cheers,

Jonathan

On Mon, Mar 30, 2009 at 8:53 PM, Daniel Schepler
schep...@math.berkeley.edu wrote:
 Package: libdbd-pg-perl
 Version: 2.11.7-1
 Severity: serious

 From my pbuilder build log:

 ...
 t/99_perlcritic.#
 # File: Pg.pm (line 157)
 # Vio: Package DBD::Pg::dr does not start with a upper case letter
 # Policy: NamingConventions::Capitalization
 # Source: package DBD::Pg::dr;
 #
 #
 # File: Pg.pm (line 235)
 # Vio: Package DBD::Pg::db does not start with a upper case letter
 # Policy: NamingConventions::Capitalization
 # Source: package DBD::Pg::db;
 ...
 # File: t/dbdpg_test_setup.pl (line 528)
 # Vio: Reused variable name in lexical scope: $SQL
 # Policy: Variables::ProhibitReusedNames
 # Source: my $SQL = q{
 #

 #   Failed test 'Failed Perl::Critic tests for file t/dbdpg_test_setup.pl: 
 4'
 #   at t/99_perlcritic.t line 235.
 # Looks like you failed 8 tests of 434.
 dubious
        Test returned status 8 (wstat 2048, 0x800)
 DIED. FAILED tests 411-412, 418-419, 425, 428, 430, 433
        Failed 8/434 tests, 98.16% okay
 t/99_podok
 t/99_spellcheck.skipped
        all skipped: Set the environment variable TEST_SPELL to enable this 
 test
 t/99_yaml...ok
 t/99cleanup.Removing test database directory
 ok
        1/1 skipped: various reasons
 Failed Test       Stat Wstat Total Fail  List of Failed
 ---
 t/99_perlcritic.t    8  2048   434    8  411-412 418-419 425 428 430 433
 13 tests and 1 subtest skipped.
 Failed 1/19 test scripts. 8/576 subtests failed.
 Files=19, Tests=576, 33 wallclock secs (32.34 cusr +  0.46 csys = 32.80 CPU)
 Failed 1/19 test programs. 8/576 subtests failed.
 make[1]: *** [test_dynamic] Error 255
 make[1]: Leaving directory `/tmp/buildd/libdbd-pg-perl-2.11.7'
 dh_auto_test: make returned exit code 2
 make: *** [build-stamp] Error 1
 dpkg-buildpackage: failure: debian/rules build gave error exit status 2
 --
 Daniel Schepler




 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




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

Bug#521969: libdbd-pg-perl: FTBFS: Perl::Critic errors

[Jonathan Yu]

My apologies, for some reason I confused this with DBD::SQLite. But
the fact remains that these changes should be proposed upstream,
UNLESS they are either caused by debian patches, or if they are Debian
specific, or if the maintainer just sucks at updating the module.

I'm not sure about the specifics of these, but I'd encourage you to
post something to the RT and get back to us if there is no activity

On Mon, Mar 30, 2009 at 9:30 PM, Jonathan Yu jonathan.i...@gmail.com wrote:
 Hi:

 These seem like changes which should be proposed on the RT upstream.

 After being unmaintained for many months, it's now starting to get
 some support and teams have been put together to take over the
 project. So I encourage you to submit patches or bug reports upstream
 so they can get fixed. It's nothing serious (just perlcritic
 failures)... Shouldn't affect program operation but would be useful to
 fix for future releases.

 Cheers,

 Jonathan

 On Mon, Mar 30, 2009 at 8:53 PM, Daniel Schepler
 schep...@math.berkeley.edu wrote:
 Package: libdbd-pg-perl
 Version: 2.11.7-1
 Severity: serious

 From my pbuilder build log:

 ...
 t/99_perlcritic.#
 # File: Pg.pm (line 157)
 # Vio: Package DBD::Pg::dr does not start with a upper case letter
 # Policy: NamingConventions::Capitalization
 # Source: package DBD::Pg::dr;
 #
 #
 # File: Pg.pm (line 235)
 # Vio: Package DBD::Pg::db does not start with a upper case letter
 # Policy: NamingConventions::Capitalization
 # Source: package DBD::Pg::db;
 ...
 # File: t/dbdpg_test_setup.pl (line 528)
 # Vio: Reused variable name in lexical scope: $SQL
 # Policy: Variables::ProhibitReusedNames
 # Source: my $SQL = q{
 #

 #   Failed test 'Failed Perl::Critic tests for file t/dbdpg_test_setup.pl: 
 4'
 #   at t/99_perlcritic.t line 235.
 # Looks like you failed 8 tests of 434.
 dubious
        Test returned status 8 (wstat 2048, 0x800)
 DIED. FAILED tests 411-412, 418-419, 425, 428, 430, 433
        Failed 8/434 tests, 98.16% okay
 t/99_podok
 t/99_spellcheck.skipped
        all skipped: Set the environment variable TEST_SPELL to enable this 
 test
 t/99_yaml...ok
 t/99cleanup.Removing test database directory
 ok
        1/1 skipped: various reasons
 Failed Test       Stat Wstat Total Fail  List of Failed
 ---
 t/99_perlcritic.t    8  2048   434    8  411-412 418-419 425 428 430 433
 13 tests and 1 subtest skipped.
 Failed 1/19 test scripts. 8/576 subtests failed.
 Files=19, Tests=576, 33 wallclock secs (32.34 cusr +  0.46 csys = 32.80 CPU)
 Failed 1/19 test programs. 8/576 subtests failed.
 make[1]: *** [test_dynamic] Error 255
 make[1]: Leaving directory `/tmp/buildd/libdbd-pg-perl-2.11.7'
 dh_auto_test: make returned exit code 2
 make: *** [build-stamp] Error 1
 dpkg-buildpackage: failure: debian/rules build gave error exit status 2
 --
 Daniel Schepler




 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers





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