Bug#1007813: Newer LIBSVM breaks mdp

[Tiziano Zito]

Reported upstream:

https://github.com/mdp-toolkit/mdp-toolkit/issues/93

On Thu 17 Mar, 15:19 +0100, Tiziano Zito  wrote:

Hey,

thanks for reporting this!

I think this has been addressed upstream already in May 2020:

https://github.com/mdp-toolkit/mdp-toolkit/commit/e8020f1a4fd5567034ec375bf6fd60510eed32ef

We need to wait for a new upstream release of MDP for this commit to be 
available in a released version that we can import in Debian...

Ciao!
Tiziano

On Thu 17 Mar, 10:21 +0100, Christian Kastner  wrote:

Source: mdp
Version: 3.6-1.1
Severity: important

LIBSVM 3.25, now in experimental, moved the Python modules
svm, svmutil from the global namespace to a libsvm
package. Imports in mdp must be changed accordingly:

 from svm import *  ->  from libsvm.svm import *
 from svmutil import *  ->  from libsvm.svmutil import *

I plan to upload LIBSVM 3.25 to unstable in a month or two.

Bug#1007813: Newer LIBSVM breaks mdp

[Tiziano Zito]

Hey,

thanks for reporting this!

I think this has been addressed upstream already in May 2020:

https://github.com/mdp-toolkit/mdp-toolkit/commit/e8020f1a4fd5567034ec375bf6fd60510eed32ef

We need to wait for a new upstream release of MDP for this commit to be 
available in a released version that we can import in Debian...

Ciao!
Tiziano

On Thu 17 Mar, 10:21 +0100, Christian Kastner  wrote:

Source: mdp
Version: 3.6-1.1
Severity: important

LIBSVM 3.25, now in experimental, moved the Python modules
svm, svmutil from the global namespace to a libsvm
package. Imports in mdp must be changed accordingly:

  from svm import *  ->  from libsvm.svm import *
  from svmutil import *  ->  from libsvm.svmutil import *

I plan to upload LIBSVM 3.25 to unstable in a month or two.

Bug#958114: can not use because commonutil can not be imported

[Tiziano Zito]

Hi Christian,


I eventually filed an issue with the PyPI maintainer on GitHub [1] with
a request for them to resolve this with upstream directly, as that
seemed to be the most appropriate course of action.


Thanks for reporting the issue. Should I open a sister-issue on libsvm upstream 
GitHub repo?
https://github.com/cjlin1/libsvm/issues

Maybe both upstreams need a bit of a push here ;-)


In the meantime, to get python3-libsvm working again, the immediate fix
will be to merge communutil into svmutil [2], with I'm afraid is the one
not compatible with the new python3-mdp you were preparing.
[...]


Yes, that was my plan anyway. I am quite close to python3-mdp upstream anyway, 
so I'll make sure to patch mdp and help to get out a new release that works in 
both situations. Thanks for taking care of patching libsvm: without your fix 
there was no way to use libsvm in Python 3 by using the Debian package ;-)


Sorry I don't have better news.


Oh no, that's quite a good news instead.: now I can patch python3-mdp and 
reinstate libsvm support. I owe you a couple of beers or what ever other drinks 
you may prefer instead ;-)

Tiziano

Bug#958114: can not use because commonutil can not be imported

[Tiziano Zito]

On Thu 23 Apr, 22:46 +0200, Christian Kastner  wrote:

Upstream is actually creating a libsvm namespace. When installing
libsvm using pip, the package layout is the following:

libsvm
├── __init__.py
├── commonutil.py
├── svm.py
└── svmutil.py


While that would solve the namespace problem, it appears to me that the
PyPI package is not maintained by upstream, but by a third party. In
support of that suspicion is the fact that upstream's documentation
(also shipped in our Python package as README) does not use this namespace.

So our choices seem to be:
 (1) upstream changes the namespace to libsvm
 (2) we stick with commonutil
 (3) we rename commonutil
 (4) we patch svmutil by merging in commonutil (which itself is brief)

(1) would be the cleanest solution, but would have to be coordinated
with upstream, which might take a while, and theoretically could be met
with rejection.

(2) is out of the question for me. (3) is simple but confusing.

(4) is probably the simplest solution, and is what happens in practice
anyway. If one checks svmutil (the only consumer of commonutil), it
imports everything of commonutil into its own namespace.


I'll give this some more thought, but the solution will probably be
implement (4), and ping upstream about (1) for some future release.


Well, even if (4) seems the most pragmatic approach, I think there are still 
some problems with it. In particular, software depending on libsvm3 would have 
to support the Debian-specific way of importing the library, along with the PyPI 
version. Assume your library/software is using libsvm. If libsvm has been 
installed with the Debian package, then the correct import is:


import svmutil

if libsvm has been installed with pip, then the correct import is:

import libsvm.svmutil as svmutil

I encountered this problem while updating the python3-mdp package, so the use 
case is pretty concrete. So maybe, before implementing (4), it would be nice to 
ask upstream their opinion about this mess (option (1))?


In general I think that the more consistency the better, so in case of doubts 
I would say that Debian should follow PyPI, or otherwise Debian or the end user 
would have to patch any script/library using libsvm if they want it to be 
portable…



Best regards,
Tiziano

Bug#958114: can not use because commonutil can not be imported

[Tiziano Zito]

On Fri 24 Apr, 12:24 +0200, Christian Kastner  wrote:

I have to disagree on that. I'd agree if PyPI were hosting the official
version, but this appears to be provided by a third party. This
unofficial version already conflicts with upstream, so future conflicts
and issues cannot be ruled out. What it the third party deviates even
more, or the maintainer loses interest and lets this version go stale?

It's not inconceivable to rely on a third party for bindings (I myself
do that for libfann, for example), but in caes of doubt, I believe we
need to follow upstream.

In any case, the official version has certainly seen far more widespread
use than the PyPI version (the former being around for a decade, the
latter for a few months), so we need to be aware that changing this
might break a lot of existing code out there...


I understand. In an ideal world, upstream would just take cover PyPI packaging 
and the whole mess would be over... But you are also right that the official 
version has been around far longer than the very young PyPI port...


[sorry for not putting BTS in CC. I will bounce my emails to BTS right now so 
that this discussion doesn't get lost.


Thanks!
Tiziano

Bug#958114: can not use because commonutil can not be imported

[Tiziano Zito]

Package: python3-libsvm
Version: 3.24+ds-3
Severity: important

Hi!

The libsvm package has changed interface and can not be used anymore. With the 
python3-libsvm package from sid the following happens:

python3 -c 'import svmutil'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/svmutil.py", line 8, in 
from commonutil import *
ModuleNotFoundError: No module named 'commonutil'

I think that python3-libsvm should use the same Python package structure as 
upstream. The Debian package pushes svm.py and svmutil.py directly into 
/usr/lib/python3/dist-packages . In the Debian package the file commonutil.py 
is 
missing (it is available in the source package):

$ ls libsvm-3.24+ds/python
Makefile  README  commonutil.py  svm.py  svmutil.py

Putting commonutil.py directly under /usr/lib/python3/dist-packages would be 
a bad idea, I think, because of possible name clashes. Upstream is actually 
creating a libsvm namespace. When installing libsvm using pip, the package 
layout is the following:

libsvm
├── __init__.py
├── commonutil.py
├── svm.py
└── svmutil.py

As it stands now, I think the python3-libsvm package is unusable...

Thanks for your work!
Tiziano


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_USER, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-libsvm depends on:
ii  libsvm3  3.24+ds-3
ii  python3  3.8.2-3

python3-libsvm recommends no packages.

python3-libsvm suggests no packages.

-- no debconf information

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Tiziano Zito]

Hi!

I have the same issue. Not sure the problem is with the kernel package though, 
because even purging and/or reinstalling linux-image-4.18.0-3 fails (see 
below). Any suggestion which package may be responsible? The problem started 
after a dist-upgrade on Dec 24...

Thanks!
Tiziano

# aptitude purge linux-image-4.18.0-3-amd64
The following packages will be REMOVED:
 linux-image-4.18.0-3-amd64{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 258 MB will be freed.
Do you want to continue? [Y/n/?] Y
(Reading database ... 420270 files and directories currently installed.)
Removing linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.19.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-1-amd64
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postrm.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--remove):
installed linux-image-4.18.0-3-amd64 package post-removal script subprocess 
returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

# aptitude reinstall linux-image-4.18.0-3-amd64
The following packages will be REINSTALLED:
 linux-image-4.18.0-3-amd64
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.
Need to get 0 B/45.7 MB of archives. After unpacking 0 B will be used.
(Reading database ... 416025 files and directories currently installed.)
Preparing to unpack .../linux-image-4.18.0-3-amd64_4.18.20-2_amd64.deb ...
Unpacking linux-image-4.18.0-3-amd64 (4.18.20-2) over (4.18.20-2) ...
Setting up linux-image-4.18.0-3-amd64 (4.18.20-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.18.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.18.0-3-amd64
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.18.0-3-amd64 cannot be found.
Please install the linux-headers-4.18.0-3-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64
cryptsetup: ERROR: Couldn't resolve device /dev/mapper/CRYPT-ROOT
cryptsetup: WARNING: Couldn't determine root device
Warning: couldn't identify filesystem type for fsck hook, ignoring.
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/CRYPT-ROOT'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.18.0-3-amd64 (--configure):
installed linux-image-4.18.0-3-amd64 package post-installation script 
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-4.18.0-3-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#911768: [pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Tiziano Zito]

On Thu 25 Oct, 11:02 -0400, Daniel Kahn Gillmor  wrote:

On Thu 2018-10-25 13:03:12 +0200, Tiziano Zito wrote:

It has nothing to do with pinentry. Given that I have a system with almost
identical setup without dbus-user-session where everything works, and given that
installing dbus-user-session in the affected system fixed the issue, I started
digging deeper.


I'm glad to hear that installing dbus-user-session fixed the issue.  I'm
inclined to make dbus-user-session a hard Depends: of pinentry-gnome3
instead of a Recommends: to avoid future problems like this.  What would
you think of that change?


I think it's probably a good idea, but, as I said, I have a setup where it works 
without dbus-user-session, so it is indeed not strictly required.



For the record, in case in the future anyone hits the same problem: The only
difference between the affected system and the working one was that the affected
system starts nfs-kernel-server.service on boot. This was not only delaying the
boot process (whish is somewhat expected) but additionaly the order changed in
which systemd services were started, resulting in a different order than the one
in the working system. I couldn't pin down exactly what service was the
problematic one, but disabling the nfs-kernel-server.service fixed the pinentry
issue...


this is strange to me, because i think nfs-kernel-server.service is a
system service, and gpg-agent.{service,socket} (from the gpg-agent
package) and dbus.{service,socket} (from the dbus-user-session package)
are user services -- they shouldn't have any direct interaction, and
they're actually managed by entirely different systemd instances.


I was puzzled as you are. I think the issue is probably deeper than that, in the 
sense that it could be that the nfs-kernel-service was delayed by something 
else. But there is a connection between the dbus service and nfs-kernel-server. 
On my system at least I see this:


# systemctl list-dependencies --before nfs-kernel-server.service
nfs-kernel-server.service
● ├─rpc-statd-notify.service
● └─remote-fs-pre.target
●   ├─remote-fs.target
●   │ ├─acpi-support.service
●   │ ├─cpufrequtils.service
●   │ ├─cron.service
●   │ ├─gpm.service
●   │ ├─libvirtd.service
●   │ ├─loadcpufreq.service
●   │ └─systemd-user-sessions.service
●   └─shutdown.target

Isn't systemd-user-sessions used when the user starts a X session? If 
I understand it correctly, when the users starts a X session, a dbus-daemon is 
launched for her. Could it be that the dbus-daemon couldn't start because it was 
waiting for nfs-kernel-server, but gpg-agent, being started by systemd directly, 
got started too soon?


As I said, that's total speculation, and I am not really up for fiddling with 
the system to reproduce the bug again. We both spent too much time with this 
problem, which is probably due to my very special setup.



At any rate, i'm glad to hear that dbus-user-session fixed the issue for
you!  do you have any reason that you don't want to just leave it
installed?


Oh, no reason more than "why should I install one additional package when on 
another almost identical system it works even without?". Not a very compelling 
reason, I agree :)))


Thank you for your patience ;)

Tiziano

Bug#911768: [pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Tiziano Zito]

Hi Daniel,

On Wed 24 Oct, 18:15 -0400, Daniel Kahn Gillmor  wrote:

Versions of packages pinentry-gnome3 recommends:
pn  dbus-user-session  


can you try installing dbus-user-session, then log out and log back in
and let me know whether it works in that case?


after some hours of debugging, I found the culprit.

It has nothing to do with pinentry. Given that I have a system with almost 
identical setup without dbus-user-session where everything works, and given that 
installing dbus-user-session in the affected system fixed the issue, I started 
digging deeper.


For the record, in case in the future anyone hits the same problem: The only 
difference between the affected system and the working one was that the affected 
system starts nfs-kernel-server.service on boot. This was not only delaying the 
boot process (whish is somewhat expected) but additionaly the order changed in 
which systemd services were started, resulting in a different order than the one 
in the working system. I couldn't pin down exactly what service was the 
problematic one, but disabling the nfs-kernel-server.service fixed the pinentry 
issue...


Given that installing dbus-user-session fixed the issue independent of 
nfs-kernel-server being enabled or not, I assume that the problem may be due to 
gpg-agent starting *before* dbus in the non dbus-user-session scenario, but I am 
only guessing.


You can close the bug as not-a-bug, I'd say.

Thanks!
Tiziano

Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Tiziano Zito]

Package: pinentry-gnome3
Version: 1.1.0-1+b1
Severity: serious

Hi!

pinentry-gnome3 (but also pinentry-gtk-2) does not open a window anymore to ask 
for a passphrase. If run from terminal it shows:

No Gcr System Prompter available, falling back to curses
OK Pleased to meet you

It was working fine since years. Of the packages pinentry-gnome3 depends on, I 
have only upgraded recently libgpg-error0,  libncursesw6, libtinfo6.
Even downgrading libgpg-error0 to 1.32-1 does not fix the issue.

I am clueless, but willing to help to find the culprit...

Ciao!
Tiziano

PS: not sure it is relevant, but I am not running GNOME, I use fvwm instead. 
Dbus is running.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pinentry-gnome3 depends on:
ii  gcr  3.28.0-1
ii  libassuan0   2.5.1-2
ii  libc62.27-6
ii  libgcr-base-3-1  3.28.0-1
ii  libglib2.0-0 2.58.1-2
ii  libgpg-error01.32-3
ii  libncursesw6 6.1+20181013-1
ii  libsecret-1-00.18.6-3
ii  libtinfo66.1+20181013-1

Versions of packages pinentry-gnome3 recommends:
pn  dbus-user-session  

Versions of packages pinentry-gnome3 suggests:
ii  pinentry-doc  1.1.0-1

-- no debconf information

Bug#893116: neomutt fails to decode RFC2047-encoded headers

[Tiziano Zito]

Package: neomutt
Version: 20180323+dfsg.1-1+b1
Followup-For: Bug #893116

The bug has been reported https://github.com/neomutt/neomutt/issues/1189 and 
meanwhile fixed https://github.com/neomutt/neomutt/pull/1190 upstream, so this 
bug can be closed when the next neomutt release gets uploaded to Debian.

Bug#893116: neomutt fails to decode RFC2047-encoded headers

[Tiziano Zito]

Package: neomutt
Version: 20180223+dfsg.1-1
Severity: normal

Since version 20180223+dfsg.1-1 (previous 20171215+dfsg.1-1 works fine) neomutt 
fails to properly decode headers encoded following RFC2047. For example, an 
email with Subject header:

 Subject: =?UTF-8?Q?Sicherheitsl=C3=BCcke in praktisch allen IT-Systemen?=

should be shown in the message index and in the pager as:

 Subject: Sicherheitslücke in praktisch allen IT-Systemen

The encoded version is shown instead. Version 20171215+dfsg.1-1 works fine, and 
the current mutt package 1.9.4-3 works also, so it must be something in the new 
version of neomutt. By reading the RFC I am not sure that such headers are 
actually standard conform, but they were working fine until now, so...

Thanks!

Tiziano


-- Package-specific info:
NeoMutt 20180223
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type `neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type `neomutt -vv' for details.

System: Linux 4.15.0-1-amd64 (x86_64)
ncurses: ncurses 6.1.20180127 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-5' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-5) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --libexecdir=/usr/lib --with-mailpath=/var/mail 
--enable-fcntl --gpgme --lua --notmuch --with-ui --gnutls --gss --idn 
--mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-OU3e7A/neomutt-20180223+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3  -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo 
  +gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta 
  +mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color 
  +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages neomutt depends on:
ii  libc6 2.27-2
ii  libcom-err2   1.44.0-1
ii  libgnutls30   3.5.18-1
ii  libgpgme111.10.0-2
ii  libgssapi-krb5-2  1.16-2
ii  libidn11  1.33-2.1
ii  libk5crypto3  1.16-2
ii  libkrb5-3 1.16-2
ii  liblu

Bug#851941: since version 2:1.19.1-1 xserver-xorg-legacy ignores settings in Xwrapper.config

[Tiziano Zito]

Can you try with 2:1.19.1-4 ? There was a regression in the Xorg.wrap 
permissions.


Yes, thank you! With version  2:1.19.1-4 the problem is gone!

Thank you again!
Tiziano

Bug#851941: since version 2:1.19.1-1 xserver-xorg-legacy ignores settings in Xwrapper.config

[Tiziano Zito]

Package: xserver-xorg-legacy
Version: 2:1.19.0-3
Severity: important

Starting from version 2:1.19.1-1 the settings in Xwrapper.config are ignored.

In a system with systemd, I start the Xserver from /etc/rc.local with:

su -l myusername -c 'exec startx -- vt4 >> /tmp/xsession-errors 2>&1'

i.e. X is started from a user which is not logged in a console. This 
simulates the "autologin" feature of some display managers. No display 
manager is installed on this machine.

Until version 2:1.19.0-3 this works like a charm if /etc/X11/Xwrapper.config 
contains:

needs_root_rights=yes
allowed_users=anybody

Starting from 2:1.19.1-1, X does not start anymore and fails with:

[63.770] (EE)
Fatal server error:
[63.773] (EE) xf86OpenConsole: Cannot open virtual console 
4 (Permission denied)
[63.774] (EE)
[63.776] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[63.782] (EE) Please also check the log file at 
"/home/tiziano/.local/share/xorg/Xorg.0.log" for additional information.
[63.784] (EE)
[63.785] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
[63.785] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
[63.785] (EE) Server terminated with error (1). Closing log file.

If I login in the console, I can start X with "startx", but I can not 
start on a different console from that I am logged into, i.e. 
"startx -- vt4" fails with the same error.

I don't see anything in the package changelog that would explain the problem.

Reverting to 2:1.19.0-3 fixes the problem.

Thanks!
Tiziano

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

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

Versions of packages xserver-xorg-legacy depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libaudit1  1:2.6.7-1
ii  libc6  2.24-9
pn  xserver-common 

xserver-xorg-legacy recommends no packages.

xserver-xorg-legacy suggests no packages.

-- debconf information:
  xserver-xorg-legacy/xwrapper/actual_allowed_users: anybody
  xserver-xorg-legacy/xwrapper/allowed_users: Anybody

Bug#811479: boot fails in "run-init -n ..."

[Tiziano Zito]

Hi, 

Same problem here after upgrading to 0.121. System does not boot anymore 
and gets stuck at initramfs prompt after "run-init: opening console: No 
such file or directory" error. 

The 0.122~a.test packages made my system bootable again too. Like 
Florent, I had to rescue the system by booting with a temporary live-cd, 
and installing within a chroot.


Ciao,
Tiziano

Bug#771658: unblock: python3-mdp/3.3-2

[Tiziano Zito]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python3-mdp

This version is the same as of python-mdp in the unblock request #771649.
While it does not fix any bug (the FTBFS #768675 is a python2-only
bug as as python3-sklearn is not in Debian yet), it would be better
to have the python2 and python3 versions of the package to be
identical. Thanks! 

unblock python3-mdp/3.3-2

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

Kernel: Linux 3.17-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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#771649: unblock: python-mdp/3.3-2

[Tiziano Zito]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-mdp

This version fixes FTBFS #768675. The fixes are cherry-picked from
upstream git repository. Every single commit has been incorporated
as a quilt patch. Two other bugs are fixed which were reported on
upstream user mailinglist: "Fix inclusion of CSS data in bimdp" and
"run tests from within a corresponding tests directory to work
around new py.test conftest.py autodiscovery features in python-pytest 
version 2.6.3". Documentation-only fixes are also included. The
Debian changelog entry explains everything:

  * New upstream git snapshot
- resolves FTBFS by a workaround of faulty unicode encoding in
  sklearn docstrings (Closes: #768675). The corresponding
  commits in upstream git are the quilt patches:
  changeset_af5294f0b78ea5b20e4c1c23fc55a4bdaa0749c9.diff
  changeset_4fc2b74375701dcabde0e3368841ce31a52c4529.diff
  changeset_324cb9b963a7e9d1bb22b5934eaa9f17974f5b11.diff
- Documentation fixes. The corresponding commits in upstream
  git are the quilt patches:
  changeset_f4a84b7186289027410abe116f5487f800869be2.diff
  changeset_4d05f0adafcc770277f36d30894a5c6aefe8a58b.diff
  changeset_2b1048b980748366dd6439317fccc99f728056a7.diff
  changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff
- Fix inclusion of CSS data in bimdp. The corresponding commit
  in upstream git is the quilt patch:
  changeset_4ec2f2940fda4f4fec9db184dbb1b93053040159.diff
  * debian/rules
   - run tests from within a corresponding tests directory to work around
 new py.test conftest.py autodiscovery features in python-pytest 
 version 2.6.3

Src debdiff
diff -Nru mdp-3.3/debian/changelog mdp-3.3/debian/changelog
--- mdp-3.3/debian/changelog2012-09-30 09:09:35.0 +0200
+++ mdp-3.3/debian/changelog2014-11-28 16:45:30.0 +0100
@@ -1,3 +1,29 @@
+mdp (3.3-2) unstable; urgency=low
+
+  * New upstream git snapshot
+- resolves FTBFS by a workaround of faulty unicode encoding in
+  sklearn docstrings (Closes: #768675). The corresponding
+  commits in upstream git are the quilt patches:
+  changeset_af5294f0b78ea5b20e4c1c23fc55a4bdaa0749c9.diff
+  changeset_4fc2b74375701dcabde0e3368841ce31a52c4529.diff
+  changeset_324cb9b963a7e9d1bb22b5934eaa9f17974f5b11.diff
+- Documentation fixes. The corresponding commits in upstream
+  git are the quilt patches:
+  changeset_f4a84b7186289027410abe116f5487f800869be2.diff
+  changeset_4d05f0adafcc770277f36d30894a5c6aefe8a58b.diff
+  changeset_2b1048b980748366dd6439317fccc99f728056a7.diff
+  changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff
+- Fix inclusion of CSS data in bimdp. The corresponding commit
+  in upstream git is the quilt patch:
+  changeset_4ec2f2940fda4f4fec9db184dbb1b93053040159.diff
+  * debian/rules
+   - run tests from within a corresponding tests directory to work around
+ new py.test conftest.py autodiscovery features in python-pytest 
+ version 2.6.3
+  * Upload sponsored by Yaroslav Halchenko
+
+ -- Tiziano Zito   Wed, 12 Nov 2014 15:53:57 +0100
+
 mdp (3.3-1) unstable; urgency=low
 
   * New upstream bug-fix release
diff -Nru 
mdp-3.3/debian/patches/changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff 
mdp-3.3/debian/patches/changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff
--- 
mdp-3.3/debian/patches/changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff  
1970-01-01 01:00:00.0 +0100
+++ 
mdp-3.3/debian/patches/changeset_17202a65f7608e550c52953ef4026cf8fe623c16.diff  
2014-11-28 16:45:30.0 +0100
@@ -0,0 +1,54 @@
+From: Niko Wilbert 
+Subject: DOC: some small updates and fixes in docstrings and comments
+
+Index: mdp-toolkit/bimdp/__init__.py
+===
+--- mdp-toolkit.orig/bimdp/__init__.py
 mdp-toolkit/bimdp/__init__.py
+@@ -42,11 +42,6 @@ This is described in more detail in the
+ 
+ ### T O D O ###
+ 
+-# - optional 
+-
+-# TODO: maybe also allow target==EXIT_TARGET during training
+-# would have to modify _train_node_single_phase
+-
+ # TODO: add a target seperator that does not remove the key. Could use
+ #-> remove key
+ #--> remove one '-' on entry
+@@ -70,7 +65,7 @@ This is described in more detail in the
+ #is in place.
+ 
+ # TODO: Implement more internal checks for node output result?
+-#Check that last element is not None? Use assume?
++#Check that last element is not None?
+ 
+ # TODO: implement switchlayer, a layer where each column represents a 
different
+ #target, so the target value determines which nodes are used
+Index: mdp-toolkit/bimdp/binode.py
+===
+--- mdp-toolkit.orig/bimdp/binode.py
 mdp-toolkit/bimdp/b

Bug#770171: sshd jail fails when system solely relies on systemd journal for logging

[Tiziano Zito]

Package: fail2ban
Version: 0.9.1-1
Severity: important

Dear Maintainer,

when a system is configured to use the systemd journal as the
sole logging system, i.e. when none of the packages provided by
system-log-daemon are installed, the default sshd jail does not work.

When logging in the system is done by using the systemd journal, the
file /var/log/auth.log is not used anymore. While  fail2ban 0.9
can use the systemd journal for matching offending log entries, the
Debian package comes with a "backend = auto" statement that
effectively disables matching against entries in the journal. As the
log files in /var/log are not updated anymore, fail2ban becomes
useless.

In order to have the sshd jail to work correctly I had to:

1. install python3-systemd, which is right now only suggested by
   fail2ban, but given that systemd is going to be default in jessy
   it should probably become a Depends

2. activate the systemd backend by adding 
   [DEFAULT]
   backend = systemd
   to the jail.d/defaults-debian.conf file

3. modify filter.d/sshd.conf to use the correct name of the sshd
   systemd unit in Debian, which is ssh.service and not
   sshd.service:
   [Init]
   journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd

I did not find a way to perform 3 in a way that is robust against future
upgrades of the fail2ban package...

With the above mentioned modifications in place fail2ban correctly
bans abusive hosts. I am not sure if syslog-ng or rsyslog are still
going to be installed by default in jessy (probably yes?), but
I would assume that a number of people would want to solely rely on
the systemd journal, as otherwise logging gets duplicated and would
be unhappy to discover that fail2ban has not been working for months
(like it happened to me ;).

I don't know if fail2ban should use the systemd backend by default,
but the steps needed to make it work that way should be at least
mentioned in NEWS.Debian or README.Debian *and* the sshd filter
should use the correct name of the systemd unit [maybe all filters
should be checked for wrong systemd unit names?].

As a side note, do you think that package systemd should Provide
system-log-daemon? Is this worth filing a bug against systemd?

Ciao,
Tiziano

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fail2ban depends on:
ii  init-system-helpers  1.21
ii  lsb-base 4.1+Debian13+nmu1
ii  python3  3.4.2-1
pn  python3:any  

Versions of packages fail2ban recommends:
ii  iptables   1.4.21-2+b1
pn  python3-pyinotify  
ii  whois  5.2.2

Versions of packages fail2ban suggests:
pn  mailx  
ii  python3-systemd215-6
pn  system-log-daemon  

-- Configuration Files:
/etc/fail2ban/filter.d/sshd.conf changed:
[INCLUDES]
before = common.conf
[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication 
(?:failure|error) for .* from ( via \S+)?\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying 
authentication module for .* from \s*$
^%(__prefix_line)sFailed \S+ for .*? from (?: port \d*)?(?: 
ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client 
user ".*", client host ".*")?))?\s*$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$
^%(__prefix_line)sUser .+ from  not allowed because not 
listed in AllowUsers\s*$
^%(__prefix_line)sUser .+ from  not allowed because listed in 
DenyUsers\s*$
^%(__prefix_line)sUser .+ from  not allowed because not in 
any group\s*$
^%(__prefix_line)srefused connect from \S+ \(\)\s*$
^%(__prefix_line)sReceived disconnect from : 3: \S+: Auth 
fail$
^%(__prefix_line)sUser .+ from  not allowed because a group 
is listed in DenyGroups\s*$
^%(__prefix_line)sUser .+ from  not allowed because none of 
user's groups are listed in AllowGroups\s*$
^(?P<__prefix>%(__prefix_line)s)User .+ not allowed because account 
is locked(?P=__prefix)(?:error: )?Received disconnect from : 
11: .+ \[preauth\]$
^(?P<__prefix>%(__prefix_line)s)Disconnecting: Too many 
authentication failures for .+? \[preauth\](?P=__prefix)(?:error: 
)?Connection closed by  \[preauth\]$
^(?P<__prefix>%(__prefix_line)s)Connection from  port \d+(?: 
on \S+ port \d+)?(?P=__prefix)Disconnecting: Too many authentication 
failures for .+? \[preauth\]$
ignoreregex = 
[Init]
maxlines = 10
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd

/etc/fail2ban/jail.d/defaults-debian.conf changed:
[DEFAULT]
backend = systemd
[sshd]
enabled = tru

Bug#768675: mdp: FTBFS in jessie: tests failures

[Tiziano Zito]

Hi Andrey!

On Wed 12 Nov, 23:05, Andrey Rahmatullin  wrote:
> The failing docstring indeed contains U+2013 EN DASH, it is taken from
> /usr/lib/python2.7/dist-packages/sklearn/feature_extraction/text.py
> (package python-sklearn). In jessie (0.14.1-3) it says "Transform a count
> matrix to a normalized tf or tf–idf representation" when in sid (0.15.2-3)
> it contains a normal ASCII hyphen instead, so this FTBFS is jessie-only.
> The solution is probably to fix bimdp/nodes/autogen.py in mdp to support
> non-ASCII docstrings.

thank you for diagnosing the problem. A fix is actually already
available upstream since August 2013 (!). An updated mdp package for
jessy is ready and will be uploaded as soon as the Uploader finds
the time to do it :)

Thanks,
Tiziano


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

Bug#691346: mfi in 9.1

[Tiziano Zito]

On Wed 15 Jan, 11:12, Robert Millan  wrote:
> On Mon, Nov 12, 2012 at 01:56:38PM +0100, Mathieu Simon wrote:
> > G'day
> > 
> > Actually FreBSD 9.1 will contain update 'mfi' driver code which
> > largely expands the support for MegaRAID drivers. (confirmed witha
> > 9.1-RC3 media)
> > It might be interesting for you to boo a native FreeBSD ISO of
> > this version to see if your controller is recognized by this mfi module.
> > (use "pciconf -lvb | grep mfi" and "mfiutil show adapter" to check)
> 
> Tiziano, did you try with 9.1 kernel as suggested? Actually, you could
> try 10.0~rc from unstable, it might give better results.
> 
> Please let us know if it works for you.

Hi, 

sorry for not following up on this sooner. Last year I decided to go
the FreeBSD route and updated the kernel module as specified on the
LSI website. It worked fine.
The upgrade to 9.1 brought the new mfi module, which indeed supports
the controller, so from kernel 9.1 onwards there is no need to
compile any additional module. 

The server is now running a 9.2-RELEASE kernel and everything works
fine. As the server is in production I can not really test a
Debian+kfreebsd installation, but I have no reason to think that it
would make any difference, so for me the bug can be closed :)

Thanks for pinging me about this!
Tiziano


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

Bug#691754: LSI MegaRAID

[Tiziano Zito]

Hi!

> Considering this seems to affect a very limited number of hardware I
> don't think it actually classifies as critical for kfreebsd after
> all.

I don't know how many SystemX servers IBM has sold in the last 6
months, but most of them mount this or other LSI cards based on the
same LSI MegaRAID SAS 2208 chip. So it may be a quite significant
amount of hardware...

> However, FreeBSD 9.0-stable ships a newer driver from LSI (maybe it's
> the same as the new mrsas driver mentioned in LSI's KB article?).
> 
> http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps.c?view=log
> 
> I guess this driver is being used with FreeBSD at Netflix (they claim to
> use MPT2 controllers for their new CDN) and/or at Yahoo!;  note that
> scottl reviewed many of the fixes in the changelog:
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068129.html
> 
> That suggests it would be technically possible to use the newer driver
> with kFreeBSD 9.0, but the diff would be large, and maybe not the sort
> of thing that could be introduced this late in the freeze for Wheezy?

I can not confirm that those are the same drivers. Comparing the
sources of the drivers shipped by LSI with that:

> http://svnweb.freebsd.org/base/releng/9.1/sys/dev/mps/mps.c?view=log

seems to indicate that they don't have anything to do with each
other. Maybe same chip but different card with different API? Or
maybe just a lot of refactoring... no idea.

Anyway, I managed to successfully install FreeBSD-9.0-RELEASE
following the instructions here (pages 26-35):
http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/80-00163-01_RevG.pdf

The sources and the pre-compiled module can be found here:
http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/MR_FreeBSD_DRIVER_2208-v05.504.05.00.tgz

As I was installing a stock kernel, for me it boiled down to just
copying the pre-compiled module mrsas.ko to /boot/kernel and add the following
two lines to /boot/loader.conf:
mfi_load="NO"
mrsas_load="YES"

So, all in all, for kfreebsd it would be a patch of 5524 lines, but
all concentrated in a single directory for a module that was not
present in kfreebsd before, so the probability of breaking something
else along the way seems pretty small. And, the module sources are
BSD licensed, so no problems with that either ;)

Ciao,
Tiziano


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

Bug#691346: kfreebsd-amd64 fails to install on LSI MegaRAID SAS 2208

[Tiziano Zito]

Package: installation-reports
Severity: critical
Tags: d-i

-- Package-specific info:

Boot method: CD
Image version: debian-wheezy-DI-b3-kfreebsd-amd64-netinst.iso
Date: 201210241200

Machine: IBM System x3650 M4
Partitions: no partitions

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

On this server the LSI RAID controller LSI MegaRAID SAS 2208/ServeRAID M5110e
is installed. I tried installing kfreebsd-amd64 on it from CD. The
installer GRUB menu works (see attachment boot.png), but right after
that the FreeBSD kernel hangs during boot with an error (see
attachment error.png). After 10/20 seconds another error line gets
printed -- something about hard resetting something -- but it was
too fast for me to take a screenshot, and the system reboots. 
On the very same machine I was able to install the standard 
debian-wheezy-DI-b3-amd64-netinst.iso without any problem. 

On LSI website I found this:
http://kb.lsi.com/KnowledgebaseArticle16687.aspx
which seems to indicate that FreeBSD 9.0 ships an obsolete kernel
module for this controller, and they suggest a procedure how to create
a FreeBSD 9.0 installer with an updated module. My knowledge of
FreeBSD are a bit too limited for me to seriously think about
recompile the kernel and injecting some additional modules, but
maybe someone in the kfreebsd debian team knows how to do it?

I now have the machine up and running with linux debian amd64, so I
can make any needed additional hardware info -- as linux sees it --
available. I can also make the remote control console accessible to
more knowledgeable people for debugging.

Thanks,
Tiziano

PS: I did not know what severity to set, I thought that complete
install failures qualifies for "critical", but please downgrade it
if needed.
<><>

Bug#689606: unblock: mdp/3.3-1

[Tiziano Zito]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mdp

Dear Release Team,

mdp/3.3-1 fixes two FTBFS bugs -- #687408 and #689027 -- and enables
full use of python-sklearn 0.11.0 version now in wheezy -- only
versions up to 0.10 were supported until now -- see #689028.

All changes in the attached debdiff are related to the above
mentioned problems. The relatively long diff for the file CHANGES
can be safely ignored, most of those changes are already present in
mdp/3.2+git78-g7db3c50 currently in wheezy. A number of hunks
are whitespace-only changes introduced by the new python-mode in
emacs: upstream didn't feel like rebasing a public github repo just
to expunge them.

The package features a quite extensive unittests battery which is
run at build time. It passes successfully even across different
Debian and Ubuntu releases (tested on the NeuroDebian buildbots).
This gives me enough confidence to ask for the package to be
released with wheezy.

Please allow mdp/3.3-1 in testing.

Thanks,

Tiziano Zito

unblock mdp/3.3-1

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mdp-3.2+git78-g7db3c50/CHANGES mdp-3.3/CHANGES
--- mdp-3.2+git78-g7db3c50/CHANGES	2012-04-05 16:01:52.0 +0200
+++ mdp-3.3/CHANGES	2012-09-28 14:48:39.0 +0200
@@ -1,3 +1,148 @@
+MDP-3.3:
+2012-09-19: FIX: fix error in automatic testing for MultinomialNB.
+2012-09-19: ERF: make sklearn nodes automatic testing more robust The previous
+solution was actually ignoring the special definitions in NODES.
+
+2012-09-19: FIX: disable pp support if server can not start Being able to
+import pp is not enough to be sure that pp works. For example in a
+low memory situation, the following can happen:
+
+>>> import pp
+>>> server = pp.Server()
+[...] OSError: [Errno 12] Cannot allocate memory
+
+This fix just disables pp support if the server can not be
+started.
+
+2012-06-18: FIX: Fix wrapping of sklearn 0.11 classifiers
+2012-04-17: FIX: make test_SFA2Node even more robust
+2012-04-16: FIX: make FastICANode test more robust
+2012-04-16: FIX: make test_SFA2Node more robust
+2012-04-05: FIX: fix pp_tests when run multiple times. pp tests were failing
+when run twice in a row. hugly work-around, but it seems to
+work...
+
+2012-04-05: FIX: fixed broken test_reload. test_reload was failing when called
+twice in a row.
+
+2012-04-05: FIX: fix random seed tests. The tests were failing when called
+twice in a row:
+>>> import mdp
+>>> mdp.test()
+>>> mdp.test() the first call was working, the second one was
+giving failures.
+
+2012-04-01: ERF: added tests for learning of bias parameters
+2012-03-26: FIX: replace third remaing test for pp_monkeypatch_dirname 
+Hopefully this will fix test suite failures.
+
+2012-03-22: FIX: Decrease the noise level in the DiscreteHopfieldClassifier.
+2012-03-22: FIX: honor MDP_DISABLE_SHOGUN env variable
+2012-03-19: FIX: fix left-over directories from testing pp. I do not know why,
+but this simple change fixes the leftover directories problem when
+testig with python-pp and pp monkey-patching. It should have
+worked even as it was before, but apparently some race condition 
+happens.
+
+2012-03-06: FIX: fix determinant of random rotation matrix determinant sign
+was wrong if dimensions of rotation matrix were odd. Thanks to
+Philip DeBoer. Actual Fix.
+
+2012-03-06: FIX: fix determinant of random rotation matrix determinant sign
+was wrong if dimensions of rotation matrix were odd. Thanks to
+Philip DeBoer. Failing Test.
+
+2012-02-13: ENH: remove duplicated and overly verbose code
+2012-02-13: FIX: remove FastICA stabilization from tests
+2012-02-13: FIX: remove unused parameter stabilization in FastICA.
+2012-01-19: NEW: added new sklearn algorithms wrapping We now wrap 93 sklearn
+algorithms!
+
+2012-01-19: FIX: fix another imcompatibility with sklearn 0.10 Although
+EllipticEnvelop is derived from sklearn.base.ClassifierMixin, it
+is not a classifier. It is actually a "predictor". Added a check 
+in the sklearn wrappers.
+
+2012-01-19: FIX: fix sklearn wrappers for version 0.10 New sklearn version
+introduces classifiers and predictors mixin classes that do not
+have a 'fit' method

Bug#689028: some sklearn wrappers fail when python-sklearn 0.11 is installed

[Tiziano Zito]

Package: python-mdp
Version: 3.2+git78-g7db3c50-3
Severity: important
Tags: upstream

Reported upstream:
http://sourceforge.net/mailarchive/message.php?msg_id=29700933
and
https://github.com/mdp-toolkit/mdp-toolkit/issues/2


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-mdp depends on:
ii  python2.7.3-2
ii  python-numpy  1:1.6.2-1
ii  python2.6 2.6.8-0.2
ii  python2.7 2.7.3-5

Versions of packages python-mdp recommends:
ii  python-joblib   0.6.5-1~nd+1
ii  python-libsvm   3.12-1
ii  python-pp   1.6.2-1
ii  python-scipy0.10.1+dfsg1-4
ii  python-sklearn  0.12.0-1~nd+1

Versions of packages python-mdp suggests:
ii  python-py  1.4.9-1
ii  shogun-python-modular  1.1.0-6

-- 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#689027: MDP fails to import if pp server can not start

[Tiziano Zito]

Package: python-mdp
Version: 3.2+git78-g7db3c50-3
Severity: grave
Tags: upstream

As reported by Yaroslav Halchenko, mdp fails to import if python-pp
is installed but pp server fails to start. This can happen if the
machine is low on memory for example.

The bug is grave because mdp FTBFS ona buildbot with low memory: the
tests run at build-time will fail.

Original bug report:

was trying to build pymvpa documentation and that failed miserably due
to

  File "/usr/lib/pymodules/python2.7/sphinx/ext/autodoc.py", line 321, in 
import_object
__import__(self.modname)
  File "/home/yoh/proj/pymvpa/pymvpa/mvpa2/mappers/lle.py", line 21, in 
from mvpa2.mappers.mdp_adaptor import MDPNodeMapper
  File "/home/yoh/proj/pymvpa/pymvpa/mvpa2/mappers/mdp_adaptor.py", line 18, in 

import mdp
  File "/usr/lib/python2.7/dist-packages/mdp/__init__.py", line 124, in 
configuration.set_configuration()
  File "/usr/lib/python2.7/dist-packages/mdp/configuration.py", line 330, in 
set_configuration
if _pp_needs_monkeypatching():
  File "/usr/lib/python2.7/dist-packages/mdp/configuration.py", line 292, in 
_pp_needs_monkeypatching
server = pp.Server()
  File "/usr/lib/pymodules/python2.7/pp.py", line 340, in __init__
self.set_ncpus(ncpus)
  File "/usr/lib/pymodules/python2.7/pp.py", line 504, in set_ncpus
range(ncpus - len(self.__workers))])
  File "/usr/lib/pymodules/python2.7/pp.py", line 140, in __init__
self.start()
  File "/usr/lib/pymodules/python2.7/pp.py", line 146, in start
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1143, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-mdp depends on:
ii  python2.7.3-2
ii  python-numpy  1:1.6.2-1
ii  python2.6 2.6.8-0.2
ii  python2.7 2.7.3-5

Versions of packages python-mdp recommends:
ii  python-joblib   0.6.5-1~nd+1
ii  python-libsvm   3.12-1
ii  python-pp   1.6.2-1
ii  python-scipy0.10.1+dfsg1-4
ii  python-sklearn  0.12.0-1~nd+1

Versions of packages python-mdp suggests:
ii  python-py  1.4.9-1
ii  shogun-python-modular  1.1.0-6

-- 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#687408: mdp: FTBFS: test failed

[Tiziano Zito]

Hi,

those tests sometimes fail because there is some randomness involved.
They test the convergence of some algorithms, and sometimes the get
stuck in local optima.
The fix is to test the package during build with a fixed random seed, so that
we only get "real" failing tests: if the fixed random seed no test is failing
on the maintainer machine, no test should fail on the buildbots.

I already implemented the fix, and will try to find  a sponsor to upload the
fixed package in the next days...

Thank you,
Tiziano

On Sat, Sep 22, 2012 at 8:20 PM, David Prévot  wrote:
> On Fri, Sep 21, 2012 at 07:00:04PM -0400, David Prévot wrote:
>> Control: tags -1 unreproducible
>>
>> On Wed, Sep 12, 2012 at 03:16:42PM +0200, Lucas Nussbaum wrote:
>> > Source: mdp
>> > Version: 3.2+git78-g7db3c50-3
>> > Severity: serious
>> > Tags: wheezy sid
>> > User: debian...@lists.debian.org
>> > Usertags: qa-ftbfs-20120912 qa-ftbfs
>> > Justification: FTBFS in wheezy on amd64
>>
>> Hi,
>>
>> I was able to reproduce the bug on Wheezy yesterday night, but not
>> today. I couldn't find any relevant package that migrated in the mean
>> time, so not closing this bug without confirmation or enlightenment.
>
> Attached build log and diff against the failed one. Please note that I
> tried to rebuild it several time, and it failed twice so far, with
> another failed test (FastICA, end of log attached) for the second
> failure (didn't keep the log of the first one). Don't know how to
> reproduce the issue “for sure”, but maybe the unreproducible tag should
> be removed.
>
> Regards
>
> David
>
>


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

Bug#684463: condor fails to install if condor user already exists

[Tiziano Zito]

Perfect!

If the LDAP account is a normal account, installation fails as
expected with:

ERROR: Condor cannot run under unlocked non-system account 'condor'
dpkg: error processing condor (--configure):
[...]

If the LDAP account is a locked account, installation is successful
and a warning is issued:

WARNING: Condor will be running under an existing non-system user account 
'condor'.

I tested it on a production machine and everything is fine.
Deployment on the whole cluster is happening tomorrow, as soon as
the German neurodebian mirror as catches up with the US one.

Thanks a bunch!
Tiziano

On Wed 22 Aug, 13:47, Michael Hanke wrote:
> On Wed, Aug 22, 2012 at 08:38:15AM +0200, Tiziano Zito wrote:
> > Hi Michael,
> > 
> > any chance that you can upload somewhere (maybe on nd archives) a
> > backport for squeeze? All production systems I have right now run
> > squeeze. 
> 
> Binary packages for squeeze have been uploaded to NeuroDebian.
> 
> HTH,
> 
> Michael
> 
> -- 
> Michael Hanke
> http://mih.voxindeserto.de


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

Bug#684463: condor fails to install if condor user already exists

[Tiziano Zito]

Hi Michael,

any chance that you can upload somewhere (maybe on nd archives) a
backport for squeeze? All production systems I have right now run
squeeze. 

Thanks,
Tiziano

On Tue 21 Aug, 21:04, Michael Hanke wrote:
> On Tue, Aug 14, 2012 at 10:30:00AM +0200, Tiziano Zito wrote:
> > Thanks, it's great it got solved so fast :)
> 
> I have just uploaded 7.8.2~dfsg.1-2 to experimental. It has all the
> bugfix that have accumulated so far. Tiziano, could you please check
> whether the package works with you setup now. Once I have your
> (positive) feedback, I'll try to request a freeze exception...
> 
> Thanks,
> 
> Michael
> 
> -- 
> Michael Hanke
> http://mih.voxindeserto.de


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

Bug#684463: condor fails to install if condor user already exists

[Tiziano Zito]

> diff --git a/debian/condor.postinst b/debian/condor.postinst
> index 91ac8a5..0156b7c 100755
> --- a/debian/condor.postinst
> +++ b/debian/condor.postinst
> @@ -164,8 +164,24 @@ case "$1" in
>  configure)
>  # according to 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833#119
>  # this should always work
> -adduser --system --group --gecos "$condor_gecos" --home $condor_home 
> \
> ---disabled-password --disabled-login $condor_user --quiet
> +if ! adduser --system --group --gecos "$condor_gecos" --home 
> $condor_home \
> +--disabled-password --disabled-login $condor_user --quiet ; 
> then
> +# the only time where it would fail, is when there is an existing
> +# non-system 'condor' user. This could happen e.g. in a 
> heterogenous
> +# Condor pool (various OSes) where the adminstrative Condor user
> +# comes from LDAP and the home dir is shared across machines. 
> This
> +# is a supported deployment scenario for Condor (see installation
> +# manual section 3.2)
> +# the only problem is the possibility to conflict with an actual
> +# "human" user with the same name, so only proceed when the
> +# respective user is locked down
> +SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
> +if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
> +echo "WARNING: Condor will be running under an existing 
> non-system user account 'condor'."
> +else
> +exit 1
> +fi
> +fi

This seems OK to me. One last thing may be that instead of 'exit 1'
you could have:

echo "ERROR: Condor can not run under unlocked non-system account 'condor'" 1>&2
exit 1

so that people know why it is failing. It would be better also to
devnull the output of adduser, otherwise you'll get spurious error
messages:

if ! adduser --system --group --gecos "$condor_gecos" --home $condor_home \
   --disabled-password --disabled-login $condor_user --quiet 2>/dev/null; 
then

Thanks, it's great it got solved so fast :)

Tiziano


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

Bug#684463: [Neurodebian-devel] condor fails to install if condor user already exists

[Tiziano Zito]

> severity 684463 normal

thank you!

> However, it would be much nicer if we could find a way to deal with this
> scenario without having to use debconf. Maybe we could try to check the
> validity of the requirements: there is a 'condor' user and it can't be
> used to log in. If there is a reliable way to verify this in the case
> that adduser --system fails (and the user comes from LDAP, or whatever
> other possible auth method), we could maybe issue a warning message and
> proceed without manual approval. Opinions?

What about this in condor.postinst::

SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
   # condor user exists and it is a locked user 
else
   adduser --system ...
fi

getent gets is info from the nss libraries, so it is independent of
auth method.

So no need to use new dpkg questions. Could this warrant a freeze
exception?

Ciao,
Tiziano


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

Bug#684463: [Neurodebian-devel] condor fails to install if condor user already exists

[Tiziano Zito]

Hi!

On Sat 11 Aug, 20:59, Michael Hanke wrote:
> Regarding the actual bug. This issue came up in the early days of this
> packaging. It essentially happens mostly for people upgrading from
> existing Condor deployments. While I can't say much about the necessity
> to have a Condor user in LDAP. I'm pretty sure that the Debian packages
> cannot work with a non-system user. There are all kinds of problems, but
> one of them is that the package can't assume that any user named
> 'condor' is also one that is available for Condor's operations. If a
> normal user 'condor' exists, IMHO failing is the only option. Otherwise
> that user would have access to Condor's runtime data (job payload, ...),
> but we would not know whether there is an actual (human) 'condor' user.
> 
> The system user that the condor package creates is a dedicated one -- no
> login, no shell access.
> 

I think the current behaviour deviates from upstream in a significant and
gratuitous way, making it much harder to deploy on top of an
existing condor installation. And, it makes harder or impossible to
use a perfectly valid configuration.

The condor installation manual in chapter 3.2.2

states that:

"""
5. Will you have a Unix user named condor, and will its home directory be 
shared?

To simplify installation of Condor, create a Unix user named condor on all
machines in the pool. The Condor daemons will create files (such as the log
files) owned by this user, and the home directory can be used to specify the
location of files and directories needed by Condor. The home directory of this
user can either be shared among all machines in your pool, or could be a
separate home directory on the local partition of each machine. Both approaches
have advantages and disadvantages. Having the directories centralized can make
administration easier, but also concentrates the resource usage such that you
potentially need a lot of space for a single shared home directory. See the
section below on machine-specific directories for more details.

Note that the user condor must not be an account into which a person can
log in. If a person can log in as user condor, it permits a major security
breach, in that the user condor could submit jobs that run as any other user,
providing complete access to the user's data by the jobs. A standard way of not
allowing log in to an account on Unix platforms is to enter an invalid shell in
the password file.

If you choose not to create a user named condor, then you must specify
either via the CONDOR_IDS environment variable or the CONDOR_IDS config file
setting which uid.gid pair should be used for the ownership of various Condor
files. See section 3.6.13 on UIDs in Condor on page [*] in the Administrator's
Manual for details. 
"""

The only requirement is that there is a user condor on all machines.
If the condor user's home directory is to be shared, which is a
perfectly valid configuration, the user account creation procedure
in the debian package is not going to work, because the probability
of getting the same uid and gid on all nodes are pretty low. NFS
sharing of the home directory becomes impossible.  For security
reasons it is important that the condor user does not correspond to
someone who can log in, which has nothing to do with the user uid
being < 1000 (which is the default in adduser.conf for "system"
accounts). 

> If you see a way that is both secure and satisfies your needs, please
> let me know. Otherwise, I think Evgeni is right: move 'condor' out of
> LDAP and solve email issues with alternative means.

I think that in condor.postinst the call to adduser should be
followed by a check: 

1. if adduser failed, i.e. there is already a
   condor user and it is not a "system" account, then prompt the user
   to ask if they really want to use the existing account.
1a. if they want to use it, everything is fine
1b. if not, fail

> For now I am downgrading this bug to 'wishlist' and tag it with
> 'wontfix' until a more viable solution is found.

Well, I think that "wishlist" is a bit unfair, given that it breaks on
upgrade and makes it impossible to use the debian package on a
cluster where other condor clients are not debian systems and use
the valid configuration of sharing home with NFS and non-system
condor account.

Ciao,
Tiziano


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

Bug#684463: condor fails to install if condor user already exists

[Tiziano Zito]

> > > Package: condor
> > > Version: 7.8.1~dfsg.1-1~nd12.04+1
> > 
> > Where does this version come from?
> > Debian has 7.8.1~dfsg.1-2 in Wheezy and Sid.
> 
> It seems to come from http://neuro.debian.net and to be a backport of 
> 7.8.1~dfsg.1-1.

Sorry for not mentioning it, I quickly checked on two different
machines, but both were using the neuro.debian repos... 

> It has the very same postinst script as the Debian version and it should 
> really not fail. Unless the user is not a system user.
> 
> Is your condor user a regular LDAP user?

Yes, it has  UID > 1000 as suggested by pam_ldap. Why should the
condor user be a "system" user? for one, it requires a valid email
address if you want email sent by condor not being tagged as SPAM by
overzealous SPAM filters. And if you use LDAP for authentication you
typically use it for email too, so the condor user naturally fits as
a non-system LDAP user. Couldn't this check be lifted altogether, or
at least give the possibility to set UID and GID of the condor user
on installation? 

Thank you for your quick reply!

Tiziano


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

Bug#684463: condor fails to install if condor user already exists

[Tiziano Zito]

Package: condor
Version: 7.8.1~dfsg.1-1~nd12.04+1
Severity: grave
Justification: renders package unusable

Hi!

when I try to install condor on a machine where the condor user already exists 
(either
because the machine uses LDAP authentication and condor user is in
LDAP or because I am just re-installing or upgrading condor), the
configuration step fails with:

Setting up condor (7.8.1~dfsg.1-1~nd60+1) ...
adduser: The user `condor' already exists. Exiting.
dpkg: error processing condor (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
Errors were encountered while processing:
 condor
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up condor (7.8.1~dfsg.1-1~nd60+1) ...
adduser: The user `condor' already exists. Exiting.
dpkg: error processing condor (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 condor

I am somehow unsure what is happening, because I have this also on a
machine where condor is already installed and working, but:

hamxxx ~ # dpkg-reconfigure condor
/usr/sbin/dpkg-reconfigure: condor is broken or not fully installed
hamxxx ~ # condor_q
-- Submitter: hamxxx : <172.29.xxx.xxx:40590> : hamxxx
 ID  OWNERSUBMITTED RUN_TIME ST PRI SIZE CMD
2586.0   xxx 8/9  15:50   0+05:36:39 R  0   43.9 bash_lc_var_5 2586
2586.1   xxx 8/9  15:50   0+05:36:39 R  0   43.9 bash_lc_var_5 2586
[...]

this happens on squeeze, wheezy and ubuntu precise...

am I doing something wrong?

thank you,
tiziano

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise')
Architecture: amd64 (x86_64)

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

Versions of packages condor depends on:
ii  adduser 3.113ubuntu2
ii  debconf [debconf-2.0]   1.5.42ubuntu1
ii  libc6   2.15-0ubuntu10
ii  libclassad3 7.8.1~dfsg.1-1~nd12.04+1
ii  libcomerr2  1.42-1ubuntu2
ii  libcurl37.22.0-3ubuntu4
ii  libdate-manip-perl  6.25-1
ii  libexpat1   2.0.1-7.2ubuntu1
ii  libgcc1 1:4.6.3-1ubuntu5
ii  libglobus-common0   14.5-1
ii  libglobus-ftp-control1  4.2-1
ii  libglobus-gass-transfer27.1-1
ii  libglobus-gram-client3  12.3-2
ii  libglobus-gsi-credential1   5.1-1
ii  libglobus-gsi-proxy-core0   6.1-1
ii  libglobus-gsi-sysconfig15.1-1
ii  libglobus-gss-assist3   8.1-1
ii  libglobus-gssapi-gsi4   10.2-1
ii  libglobus-io3   9.2-1
ii  libglobus-rsl2  9.1-2
ii  libglobus-xio0  3.2-1
ii  libgsoap1   2.8.4-2
ii  libk5crypto31.10+dfsg~beta1-2ubuntu0.3
ii  libkrb5-3   1.10+dfsg~beta1-2ubuntu0.3
ii  libldap-2.4-2   2.4.28-1.1ubuntu4.1
ii  libpcre38.12-4
ii  libssl1.0.0 1.0.1-4ubuntu5.3
ii  libstdc++6  4.6.3-1ubuntu5
ii  libuuid12.20.1-1ubuntu3
ii  libvirt00.9.8-2ubuntu17.3
ii  neurodebian-popularity-contest  0.28~nd12.04+1
ii  perl5.14.2-6ubuntu2
ii  python  2.7.3-0ubuntu2

Versions of packages condor recommends:
ii  dmtcp  1.2.5-1~nd12.04+1

Versions of packages condor suggests:
pn  coop-computing-tools  

-- debconf information excluded


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

Bug#645584: Please support python3

[Tiziano Zito]

Package: python-mdp
Version: 3.2-1
Followup-For: Bug #645584

python-mdp depends on python-numpy. As soon as Python 3 package is 
available for python-numpy, I can try to prepare a Python 3 package
for python-mdp.

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

Best,
Tiziano

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

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

Versions of packages python-mdp depends on:
ii  python2.7.2-9
ii  python-numpy  1:1.5.1-3
ii  python2.6 2.6.7-4
ii  python2.7 2.7.2-12

Versions of packages python-mdp recommends:
ii  python-joblib  0.6.0~b3-1
ii  python-libsvm  3.1-1
ii  python-pp  1.6.1-1
ii  python-scikits-learn   
ii  python-scipy   0.9.0+dfsg1-1+b2
ii  shogun-python-modular  1.1.0-1

Versions of packages python-mdp suggests:
ii  python-py  1.3.4-2



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

Bug#521617: tls is broken in version 0.6.8

[Tiziano Zito]

Package: libnss-ldapd
Version: 0.6.8
Severity: normal

I can confirm that the bug is more serious that just "tls_reqcert never"
not working. We have here an openldap server with a self-signed
certificate. Lenny clients with version 0.6.7 connect using tls
without any problem. The relevant part of the nss-ldapd.conf file reads:
ssl  start_tls
tls_checkpeer yes
tls_cacertfile  /etc/ssl/certs/bccnca.pem

On a sid client with version 0.6.8 "ssl start_tls" does not work.
The relevant part of the nss-ldapd.conf file reads:
ssl  start_tls
tls_reqcert demand
tls_cacertfile  /etc/ssl/certs/bccnca.pem

A debug session looking up a valid user on a working lenny client:
nslcd: DEBUG: add_uri(ldap://ldap1)
nslcd: DEBUG: add_uri(ldap://ldap2)
nslcd: /etc/nss-ldapd.conf:30: option tls_checkpeer is currently untested 
(please report any successes)
nslcd: /etc/nss-ldapd.conf:31: option tls_cacertfile is currently untested 
(please report any successes)
nslcd: version 0.6.7 starting
nslcd: DEBUG: unlink() of /var/run/nslcd/socket failed (ignored): No such file 
or directory
nslcd: DEBUG: setgroups(0,NULL) done
nslcd: DEBUG: setgid(120) done
nslcd: DEBUG: setuid(113) done
nslcd: accepting connections
nslcd: [8b4567] DEBUG: connection from pid=12401 uid=0 gid=0
nslcd: [8b4567] DEBUG: nslcd_passwd_byname(tiziano)
nslcd: [8b4567] DEBUG: myldap_search(base="dc=bccn-berlin,dc=de", 
filter="(&(objectClass=posixAccount)(uid=tiziano))")
nslcd: [8b4567] DEBUG: simple anonymous bind to ldap://ldap1
nslcd: [8b4567] connected to LDAP server ldap://ldap1
nslcd: [8b4567] DEBUG: ldap_result(): end of results
nslcd: [7b23c6] DEBUG: connection from pid=12401 uid=0 gid=0
nslcd: [7b23c6] DEBUG: nslcd_passwd_byuid(2061)
[...]


A debug session looking up the same user on the broken sid client with tls 
enabled:
nslcd: DEBUG: add_uri(ldap://ldap1)
nslcd: DEBUG: add_uri(ldap://ldap2)
nslcd: /etc/nss-ldapd.conf:30: option tls_reqcert is currently untested (please 
report any successes)
nslcd: /etc/nss-ldapd.conf:31: option tls_cacertfile is currently untested 
(please report any successes)
nslcd: version 0.6.8 starting
nslcd: DEBUG: unlink() of /var/run/nslcd/socket failed (ignored): No such file 
or directory
nslcd: DEBUG: setgroups(0,NULL) done
nslcd: DEBUG: setgid(122) done
nslcd: DEBUG: setuid(112) done
nslcd: accepting connections
nslcd: [8b4567] DEBUG: connection from pid=22112 uid=0 gid=0
nslcd: [8b4567] DEBUG: nslcd_passwd_byname(tiziano)
nslcd: [8b4567] DEBUG: myldap_search(base="dc=bccn-berlin,dc=de", 
filter="(&(objectClass=posixAccount)(uid=tiziano))")
nslcd: [8b4567] ldap_start_tls_s() failed: Connect error: No such file or 
directory
nslcd: [8b4567] failed to bind to LDAP server ldap://ldap1: Connect error: No 
such file or directory
nslcd: [8b4567] ldap_start_tls_s() failed: Connect error: Success
nslcd: [8b4567] failed to bind to LDAP server ldap://ldap2: Connect error: 
Success
nslcd: [8b4567] no available LDAP server found, sleeping 1 seconds
nslcd: [8b4567] no available LDAP server found
[...]

A debug session looking up the same user on the same broken sid client this 
time with tls disabled:
nslcd: DEBUG: add_uri(ldap://ldap1)
nslcd: DEBUG: add_uri(ldap://ldap2)
nslcd: version 0.6.8 starting
nslcd: DEBUG: unlink() of /var/run/nslcd/socket failed (ignored): No such file o
r directory
nslcd: DEBUG: setgroups(0,NULL) done
nslcd: DEBUG: setgid(122) done
nslcd: DEBUG: setuid(112) done
nslcd: accepting connections
nslcd: [8b4567] DEBUG: connection from pid=22121 uid=0 gid=0
nslcd: [8b4567] DEBUG: nslcd_passwd_byname(tiziano)
nslcd: [8b4567] DEBUG: myldap_search(base="dc=bccn-berlin,dc=de", filter="(&(obj
ectClass=posixAccount)(uid=tiziano))")
nslcd: [8b4567] DEBUG: simple anonymous bind to ldap://ldap1
nslcd: [8b4567] connected to LDAP server ldap://ldap1
nslcd: [8b4567] DEBUG: ldap_result(): end of results
nslcd: [7b23c6] DEBUG: connection from pid=22121 uid=0 gid=0
nslcd: [7b23c6] DEBUG: nslcd_passwd_byuid(2061)
[...]


If more info is needed, I'm happy to assist: we need to use TLS (LAN network
can not be trusted).

ciao,
tiziano

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libnss-ldapd depends on:
ii  adduser  3.110   add and remove users and groups
ii  debconf [debconf-2.0 1.5.26  Debian configuration management sy
ii  libc62.9-7   GNU C Library: Shared libraries
ii  libgssapi-krb5-2 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - k
ii  libldap-2.4-22.4.15-1.1  OpenLDAP libraries
ii  libsasl2-2   2.1.22.dfsg1-23 Cyrus SASL - authentication abstra

Versions of packages libnss-ldapd recommends:
ii  libpam-ldap   184-8  Pluggable Authentication Mod

Bug#498229: Typo in /usr/lib/python2.5/site-packages/matplotlib/axes3d.py

[Tiziano Zito]

Package: python-matplotlib
Version: 0.98.1-1
Severity: minor

Hi, in the package python-matplotlib I've just hit a typo in
/usr/share/pyshared/matplotlib/axes3d.py:

raise NotImplmentedError('axes3d is not supported in matplotlib-0.98.
You may want to try the 0.91.x maintenance branch')

should read "NotImplementedError" instead of "NotImplmentedError".
To reproduce just try:

>>> from matplotlib import axes3d
Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python2.5/site-packages/matplotlib/axes3d.py", line
1, in 
   raise NotImplmentedError('axes3d is not supported in
matplotlib-0.98.  You may want to try the 0.91.x maintenance branch')
NameError: name 'NotImplmentedError' is not defined
>>>

not such a big deal, the import should fail with NotImplementedError
instead of NameError.

thank you!
tiziano

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

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-matplotlib depends on:
ii  dvipng 1.11-1convert DVI files to PNG graphics
ii  libatk1.0-01.22.0-1  The ATK accessibility toolkit
ii  libc6  2.7-13GNU C Library: Shared libraries
ii  libcairo2  1.6.4-6   The Cairo 2D vector graphics libra
ii  libfreetype6   2.3.7-2   FreeType 2 font engine, shared lib
ii  libgcc11:4.3.1-9 GCC support library
ii  libglib2.0-0   2.16.5-1  The GLib library of C routines
ii  libgtk2.0-02.12.11-3 The GTK+ graphical user interface 
ii  libpango1.0-0  1.20.5-1  Layout and rendering of internatio
ii  libpng12-0 1.2.27-1  PNG library - runtime
ii  libstdc++6 4.3.1-9   The GNU Standard C++ Library v3
ii  python 2.5.2-2   An interactive high-level object-o
ii  python-cairo   1.4.12-1.1Python bindings for the Cairo vect
ii  python-central 0.6.8 register and build utility for Pyt
ii  python-configobj   4.5.2-1   a simple but powerful config file 
ii  python-dateutil1.4-1 powerful extensions to the standar
ii  python-dev 2.5.2-2   Header files and a static library 
ii  python-enthought-trait 2.0.5-1   Manifest typing and reactive progr
ii  python-excelerator 0.6.3a-3.1module for reading/writing Excel s
ii  python-glade2  2.12.1-6  GTK+ bindings: Glade support
ii  python-gobject 2.14.2-1  Python bindings for the GObject li
ii  python-gtk22.12.1-6  Python bindings for the GTK+ widge
ii  python-matplotlib-data 0.98.1-1  Python based plotting system (data
ii  python-numpy   1:1.1.0-3 Numerical Python adds a fast array
ii  python-pyparsing   1.5.0-1   Python parsing module
ii  python-qt3 3.17.4-1  Qt3 bindings for Python
ii  python-qt4 4.4.2-4   Python bindings for Qt4
ii  python-tk  2.5.2-1   Tkinter - Writing Tk applications 
ii  python-tz  2008c-2   Python version of the Olson timezo
ii  python-wxgtk2.62.6.3.2.2-2   wxWidgets Cross-platform C++ GUI t
ii  tcl8.4 8.4.19-2  Tcl (the Tool Command Language) v8
ii  tk8.4  8.4.19-2  Tk toolkit for Tcl and X11, v8.4 -
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

python-matplotlib recommends no packages.

Versions of packages python-matplotlib suggests:
ii  ipython0.8.4-1   enhanced interactive Python shell
pn  python-matplotlib-doc  (no description available)
ii  texlive-extra-utils2007.dfsg.2-3 TeX Live: TeX auxiliary programs
ii  texlive-latex-extra2007.dfsg.3-2 TeX Live: LaTeX supplementary pack

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489253: Fw: should numpy be built with atlas?

[Tiziano Zito]

Hi Ondrej, 

> $ ./test_atlas.py
> Using ATLAS:
> 0.53141283989
> $ wajig remove atlas3-base libatlas3gf-base
> $ ./test_atlas.py
> Using ATLAS:
> 1.64572000504
> 
> So it seems to work, even though the difference is not so big.

the difference is not so big because the package contains a
_dotblas.so file. When you remove the ATLAS libs, it simply uses the
available lapack+blas routines, which are slower then ATLAS but
still not so bad. If you build the package without the patch and
without using ATLAS, not _dotblas.so file is present, and the slow
down is much higher:

$ aptitude search ~i~natlas
i   libatlas3gf-sse2- Automatically Tuned Linear Algebra Softwar
$ ldd /usr/lib/python2.5/site-packages/numpy/core/_dotblas.so 
linux-gate.so.1 =>  (0xe000)
libblas.so.3gf => /usr/lib/sse2/atlas/libblas.so.3gf (0xb79b6000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7904000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb78dd000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb78d)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7775000)
/lib/ld-linux.so.2 (0x8000)
$ python test_atlas.py 
Using ATLAS:
0.539413928986
$ aptitude purge libatlas3gf-sse2
$ python test_atlas.py 
Using ATLAS:
1.90855002403
$ ldd /usr/lib/python2.5/site-packages/numpy/core/_dotblas.so
linux-gate.so.1 =>  (0xe000)
libblas.so.3gf => /usr/lib/libblas.so.3gf (0xb7f6)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7eae000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7e87000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e7a000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d1f000)
/lib/ld-linux.so.2 (0x8000)
$ mv /usr/lib/python2.5/site-packages/numpy/core/_dotblas.so 
/usr/lib/python2.5/site-packages/numpy/core/_dotblas.so.bak
$ python test_atlas.py 
No ATLAS:
7.52080416679

bye, 
tiziano






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489253: should numpy be built with atlas?

[Tiziano Zito]

On 7/8/08, Matthias Klose <[EMAIL PROTECTED]> wrote:
>  thanks for the update. Looking at the blas package, I see that the
>  cblas library is included in libblas3.  So it looks like the numpy
>  check is wrong, testing for a package name, and not for a
>  feature. This seems to explain why it did work in etch, and this
>  should be fixed in python-numpy.

Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed
seems to do the trick. Feel free to test the attached patch, generated
against the python-numpy source package in sid. On my system it
generates a numpy package with a _dotblas.so file correctly linked to
lapack libs. If ATLAS is then installed, the ATLAS libraries are used
instead.
Ondrej: if the patch works, would you report it upstream?

have a nice day!
tiziano


atlas.patch
Description: Binary data

Bug#476641: gkrellm: /proc/acpi Battery Interface Deprecated in 2.6.24, Must Use sysfs

[Tiziano Zito]

Hi! This bug is still present after last kernel upgrade to
linux-image-2.6.25-2 . Any chances to get this patch applied
upstream before lenny freeze?

thank you!
tiziano





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489253: python-numpy: enable ATLAS support?

[Tiziano Zito]

> Hi Tiziano!
> 
> Thanks for the bug report. Do you suggest this patch?
> 
> [...]
> 
> Unfortunately, I am not an expert in blas/lapack/atlas, I only
> remember there were some problems with that. The package compiles and
> seems to work fine, tests run. However, for example the generated
> dependencies of the resulting binary package are wrong:
> 
> Depends: python (<< 2.6), python (>= 2.4), python-central (>= 0.6.7),
> libc6 (>= 2.7-1)
> 
> so it doesn't seem to pickup atlas correctly. Maybe there are some
> other problems too.
> 
> Would you be willing to look at this? If so, please join DPMT, so that
> you can edit the package and then feel free to fix it. If you prepare
> the package, so that it's ready for upload, I'll upload it.

Hi Ondrej, I'll request to join the DPMT, but in the meanwhile this
patch created a perfectly running python-numpy package with ATLAS
support and right dependencies:
Depends: python (<< 2.6), python (>= 2.4), python-central (>=0.6.7), 
 libatlas3gf-base | libatlas.so.3gf, libc6 (>= 2.7-1),
 libgcc1 (>= 1:4.1.1), libgfortran3 (>= 4.3), liblapack3gf |
 liblapack.so.3gf | libatlas3gf-base

$ svn di

Index: debian/control
===
--- debian/control  (revision 5836)
+++ debian/control  (working copy)
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Python Modules Team <[EMAIL PROTECTED]>
 Uploaders: Marco Presi (Zufus) <[EMAIL PROTECTED]>, Alexandre Fayolle <[EMAIL 
PROTECTED]>, José Fonseca <[EMAIL PROTECTED]>, Matthias Klose <[EMAIL 
PROTECTED]>, Ondrej Certik <[EMAIL PROTECTED]>, Kumar Appaiah <[EMAIL 
PROTECTED]>
-Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, 
python-central (>= 0.6), gfortran (>= 4:4.2), libblas-dev [!arm !m68k], 
liblapack-dev [!arm !m68k], debhelper (>= 5.0.38), patchutils, python-docutils, 
libfftw3-dev
+Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, 
python-central (>= 0.6), gfortran (>= 4:4.2), libblas-dev [!arm !m68k], 
liblapack-dev [!arm !m68k], libatlas-base-dev [!arm !m68k] | libatlas-sse-dev 
[!arm !m68k] | libatlas-sse2-dev [!arm !m68k] | libatlas-3dnow-dev [!arm 
!m68k],debhelper (>= 5.0.38), patchutils, python-docutils, libfftw3-dev
 Build-Conflicts: atlas3-base-dev
 XS-Python-Version: >= 2.3
 Standards-Version: 3.8.0
Index: debian/patches/series
===
--- debian/patches/series   (revision 5836)
+++ debian/patches/series   (working copy)
@@ -1,2 +1 @@
 01_fix_man_hyphens.patch
-02_dontuse_lapack.diff

Hope that helps,
tiziano




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489253: python-numpy: enable ATLAS support?

[Tiziano Zito]

Package: python-numpy
Version: 1:1.1.0-1
Severity: normal

dear maintainers,
python-numpy is currently built without ATLAS support.

Among other things this implies very slow matrix multiplication.
ATLAS support was dropped during the gfortran transition (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784+ ).

Dropping the 02_dontuse_lapack.diff patch and build-depend
on atlas should re-enable ATLAS support. 
The reason for dropping ATLAS support was that ATLAS had not completed 
the gfortran transition yet. This issue seems to be solved now:
http://buildd.debian.org/~jeroen/status/package.php?p=atlas

Thank you!

tiziano

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

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-numpy depends on:
ii  libatlas3gf-base [liblapack.s 3.6.0-21.5 Automatically Tuned Linear Algebra
ii  libatlas3gf-sse2 [liblapack.s 3.6.0-21.5 Automatically Tuned Linear Algebra
ii  libblas3gf [libblas.so.3gf]   1.2-1.6Basic Linear Algebra Subroutines 3
ii  libc6 2.7-12 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.1-4  GCC support library
ii  libgfortran3  4.3.1-4Runtime library for GNU Fortran ap
ii  liblapack3gf [liblapack.so.3g 3.1.1-0.4  library of linear algebra routines
ii  python2.5.2-1An interactive high-level object-o
ii  python-central0.6.7  register and build utility for Pyt

python-numpy recommends no packages.

-- no debconf information





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405870: wake on lan broken

[Tiziano Zito]

Package: sysvinit
Version: 2.86.ds1-38
Followup-For: Bug #405870

Wake on LAN does not work here (Broadcom Corporation NetXtreme
BCM5754 ethernet controller). ethtool reports that wake on lan is
enabled
$ ethtool eth0
...
Supports Wake-on: g
Wake-on: d

I suspect the issue is related to what reported in bug #405870.
Wake on lan is enabled in the BIOS. If I shutdown the machine
manually from the grub menu (i.e.  before starting the OS), the
network card correctly remains active (LED flashing). On the other
hand, if I shutdown using halt, poweroff or shutdown commands, the
network card is switched off, even if I set NETDOWN=no in
/etc/default/halt , thus making WOL impossible. The original bug
report seems to be quite old, any progress on this? Do I understand
it correctly that the only workaround at the moment is recompiling
"halt" from upstream source?

thank you,
tiziano



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)

Versions of packages sysvinit depends on:
ii  initscripts 2.86.ds1-38  Scripts for initializing and shutt
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libselinux1 1.32-3   SELinux shared libraries
ii  libsepol1   1.14-2   Security Enhanced Linux policy lib
ii  sysv-rc 2.86.ds1-38  System-V-like runlevel change mech
ii  sysvinit-utils  2.86.ds1-38  System-V-like utilities

sysvinit recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#402733: a2ps: segmentation fault

[Tiziano Zito]

Package: a2ps
Version: 1:4.13b.dfsg.1-1
Severity: grave
Justification: renders package unusable


a2ps segfaults when run without arguments, as well as when given an
output file. Step to reproduce:
- simply run "a2ps"
- try: echo "test" | a2ps -o test.ps

The package is at the moment not usable. 

Thank you for looking inot this!

Tiziano

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)

Versions of packages a2ps depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libpaper11.1.21  Library for handling paper charact

Versions of packages a2ps recommends:
ii  bzip2 1.0.3-6high-quality block-sorting file co
ii  cupsys-bsd [lpr]  1.2.7-1Common UNIX Printing System(tm) - 
ii  cupsys-client 1.2.7-1Common UNIX Printing System(tm) - 
ii  psutils   1.17-24A collection of PostScript documen
pn  wdiff  (no description available)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]