Bug#1054654: Acknowledgement (Tries to use LWP::Debug::trace which is long gone from libwww-perl)

[Sven Hartge]

Hello,

I misinterpreted the error.

LWP::Debug::trace() still exists, but one needs to explicitly add

use LWP::Debug;

to the code to be able to use it. 

Either way, the code is still very old, broken in the default state, 
LWP::Debug only exists for legacy code and should not be used anymore (as 
per its own dicumentation) and a working alternative exists for 
LWP::Protocol::http::SocketUnix exists, my suggestion and the graveness of 
this bug is still valid.

Grüße,
Sven.

Bug#1054654: Tries to use LWP::Debug::trace which is long gone from libwww-perl

[Sven Hartge]

Package: liblwp-protocol-http-socketunix-perl
Version: 0.02-4
Severity: grave
Tags: upstream

Hi!

The module has been broken for a long long time, it tries to
unconditionally use LWP::Debug::trace which has been remove from LWP.

The attached reproducer shows the problem.

There is a forked and working version in
LWP::Protocol::http::SocketUnixAlt, I suggest packaging that and
removing liblwp-protocol-http-socketunix-perl from Debian.

Grüße,
Sven.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages liblwp-protocol-http-socketunix-perl depends on:
ii  libwww-perl  6.72-1
ii  perl 5.36.0-9

liblwp-protocol-http-socketunix-perl recommends no packages.

liblwp-protocol-http-socketunix-perl suggests no packages.

-- debconf-show failed
#!/usr/bin/perl

use strict;
use warnings;
use LWP;
use HTTP::Request;
use LWP::Protocol::http::SocketUnix;

LWP::Protocol::implementor( http => 'LWP::Protocol::http::SocketUnix' );

my $ua  = LWP::UserAgent->new();

my $req = HTTP::Request->new(
"GET" => "http:/run/some-socket-somewhere-does-not-matter/"
);  

my $res = $ua->request($req);
print $res->content;

Bug#1000229: binary package is missing /usr/sbin/memlockd

[Sven Hartge]

Package: memlockd
Version: 1.3-2
Severity: grave

Hello!

The subject says it all: The package is missing the binary:

,
| oweh@ds9:~$ dpkg -L memlockd
| /.
| /etc
| /etc/default
| /etc/init.d
| /etc/init.d/memlockd
| /etc/memlockd.d
| /lib
| /lib/systemd
| /lib/systemd/system
| /lib/systemd/system/memlockd.service
| /usr
| /usr/sbin
| /usr/share
| /usr/share/doc
| /usr/share/doc/memlockd
| /usr/share/doc/memlockd/changelog.Debian.gz
| /usr/share/doc/memlockd/changelog.gz
| /usr/share/doc/memlockd/copyright
| /usr/share/man
| /usr/share/man/man8
| /etc/memlockd.cfg
| /etc/default/memlockd
`

Interestingly, when I rebuild the 1.3-2 source package locally, I get a
DEB with the daemon in it:

,
| oweh@ds9:/tmp/test$ ls -l from_archive/ rebuild/
| from_archive/:
| total 8
| -rw-r--r-- 1 oweh oweh 5732 13. Nov 16:27 memlockd_1.3-2_amd64.deb
|
| rebuild/:
| total 16
| -rw-r--r-- 1 oweh oweh 13432 19. Nov 22:58 memlockd_1.3-2_amd64.deb
`

,
| oweh@ds9:/tmp/test$ debdiff from_archive/memlockd_1.3-2_amd64.deb 
rebuild/memlockd_1.3-2_amd64.deb
| [The following lists of changes regard files as different if they have
| different names, permissions or owners.]
|
| Files in second .deb but not in first
| -
| -rw-r--r--  root/root   /etc/default/memlockd
| -rw-r--r--  root/root   /etc/memlockd.cfg
| -rw-r--r--  root/root   /usr/share/man/man8/memlockd.8.gz
| -rwxr-xr-x  root/root   /usr/sbin/memlockd
|
| Files in first .deb but not in second
| -
| -rw-r--r--  root/root   /usr/share/doc/memlockd/changelog.gz
|
| Control files: lines which differ (wdiff format)
| 
| Installed-Size: [-31-] {+56+}
`

The buildlog from the buildd also confirms the missing binary: 
https://buildd.debian.org/status/fetch.php?pkg=memlockd=amd64=1.3-2=1636816430=0

Weird.

Grüße,
Sven.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages memlockd depends on:
ii  adduser  3.118

memlockd recommends no packages.

memlockd suggests no packages.

-- debconf-show failed

Bug#997139: bacula: FTBFS: configure: error: cannot find required auxiliary files: config.rpath mkinstalldirs config.guess config.sub ltmain.sh install-sh

[Sven Hartge]

Um 21:04 Uhr am 23.10.21 schrieb Lucas Nussbaum:

> Relevant part (hopefully):
> > touch src/qt-console/tray-monitor/.libs/bacula-tray-monitor
> > chmod 755 src/qt-console/tray-monitor/.libs/bacula-tray-monitor
> > dh_auto_configure -- --enable-smartalloc --with-tcp-wrappers --with-openssl 
> > --with-libiconv-prefix=/usr/include --with-readline=/usr/include/readline 
> > --disable-conio --with-libintl-prefix=/usr/include 
> > --docdir=\${prefix}/share/doc/bacula-common 
> > --htmldir=\${prefix}/share/doc/bacula-common/html 
> > --libdir=\${prefix}/lib/bacula --enable-batch-insert --enable-ipv6 
> > --with-dir-password=XXX_DIRPASSWORD_XXX 
> > --with-fd-password=XXX_FDPASSWORD_XXX --with-sd-password=XXX_SDPASSWORD_XXX 
> > --with-mon-dir-password=XXX_MONDIRPASSWORD_XXX 
> > --with-mon-fd-password=XXX_MONFDPASSWORD_XXX 
> > --with-mon-sd-password=XXX_MONSDPASSWORD_XXX --with-db-name=XXX_DBNAME_XXX 
> > --with-db-user=XXX_DBUSER_XXX --with-db-password=XXX_DBPASSWORD_XXX 
> > --with-hostname=localhost --config-cache 
> > --with-archivedir=/nonexistant/path/to/file/archive/dir 
> > --sysconfdir=/etc/bacula --with-scriptdir=/etc/bacula/scripts 
> > --sharedstatedir=/var/lib/bacula --localstatedir=/var/lib/bacula 
> > --with-logdir=/var/log/bacula --with-pid-dir=/run/bacula 
 --with-smtp-host=localhost --with-working-dir=/var/lib/bacula 
--with-subsys-dir=/run/lock --with-dump-email=root --with-job-email=root 
--with-mysql --with-postgresql --with-sqlite3 --enable-bat --with-x 
--disable-s3 --with-systemd=/lib/systemd/system
> > ./configure --build=x86_64-linux-gnu --prefix=/usr 
> > --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
> > --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
> > --disable-option-checking --disable-silent-rules 
> > --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
> > --disable-maintainer-mode --disable-dependency-tracking --enable-smartalloc 
> > --with-tcp-wrappers --with-openssl --with-libiconv-prefix=/usr/include 
> > --with-readline=/usr/include/readline --disable-conio 
> > --with-libintl-prefix=/usr/include 
> > --docdir=\${prefix}/share/doc/bacula-common 
> > --htmldir=\${prefix}/share/doc/bacula-common/html 
> > --libdir=\${prefix}/lib/bacula --enable-batch-insert --enable-ipv6 
> > --with-dir-password=XXX_DIRPASSWORD_XXX 
> > --with-fd-password=XXX_FDPASSWORD_XXX --with-sd-password=XXX_SDPASSWORD_XXX 
> > --with-mon-dir-password=XXX_MONDIRPASSWORD_XXX 
> > --with-mon-fd-password=XXX_MONFDPASSWORD_XXX 
> > --with-mon-sd-password=XXX_MONSDPASSWORD_XXX --with-db-name=XXX_DBNAME_XXX 
> > --with-db-user=XXX_D
 BUSER_XXX --with-db-password=XXX_DBPASSWORD_XXX --with-hostname=localhost 
--config-cache --with-archivedir=/nonexistant/path/to/file/archive/dir 
--sysconfdir=/etc/bacula --with-scriptdir=/etc/bacula/scripts 
--sharedstatedir=/var/lib/bacula --localstatedir=/var/lib/bacula 
--with-logdir=/var/log/bacula --with-pid-dir=/run/bacula 
--with-smtp-host=localhost --with-working-dir=/var/lib/bacula 
--with-subsys-dir=/run/lock --with-dump-email=root --with-job-email=root 
--with-mysql --with-postgresql --with-sqlite3 --enable-bat --with-x 
--disable-s3 --with-systemd=/lib/systemd/system
> > configure: creating cache config.cache
> > configure: error: cannot find required auxiliary files: config.rpath 
> > mkinstalldirs config.guess config.sub ltmain.sh install-sh
> > tail -v -n \+0 config.log

Interesting.

I think this may be an autoconf2.71 problem or a dh problem

Debugging the generated configure script, I see that it tries to look in 
the wrong place for the "autoconf/" directory when searching for the 
auxiliary files:

+ case $as_dir in
+ as_dir=/autoconf/
+ as_found=:
+ printf '%s\n' 'configure:3618:  trying /autoconf/'
+ ac_aux_dir_found=yes
+ ac_install_sh=
+ for ac_aux in $ac_aux_files
+ test xconfig.rpath = xinstall-sh
+ test -f /autoconf/config.rpath
+ ac_aux_dir_found=no
+ :

Obviously, "/autoconf/config.rpath" cannot exist.

Looking at the code in the generated configure script:

 3595 # Locations in which to look for auxiliary files.
 3596 ac_aux_dir_candidates="${BUILD_DIR}/autoconf"

it looks like $BUILD_DIR is empty, and when looking at the trace again, it 
sure is:

+ ac_aux_dir_candidates=/autoconf

Comparing the old (supplied with the source) configure script and the 
newly autoreconf'd one, it looks like BUILD_DIR is defined too late.

The old one has this

 3159 BUILD_DIR=`pwd`
 3160 cd ..
 3161 TOP_DIR=`pwd`
 3162 cd ${BUILD_DIR}

and only after that is BUILD_DIR used.

The new one uses BUILD_DIR earlier

 3595 # Locations in which to look for auxiliary files.
 3596 ac_aux_dir_candidates="${BUILD_DIR}/autoconf"

and the defintion is later

 3760 BUILD_DIR=`pwd`
 3761 cd ..
 3762 TOP_DIR=`pwd`
 3763 cd ${BUILD_DIR}

When I manually copy that code block above line 3596 then the configure 
script starts to work again.

BUILD_DIR comes from autoconf/configure.in:

  13 BUILD_DIR=`pwd`
  14 cd ..
  15 

Bug#979984: breaks on check with "NameError: name 'get_binary_stdin' is not defined"

[Sven Hartge]

Package: pyzor
Version: 1:1.0.0-5
Severity: grave

Hi!

The fix for https://bugs.debian.org/923077 seems to have introduced a
serious regressing, causing pyzor to stop working on check:

~$ pyzor check < testmail
Traceback (most recent call last):
  File "/usr/bin/pyzor", line 411, in 
main()
  File "/usr/bin/pyzor", line 152, in main
if not dispatch(client, servers, config):
  File "/usr/bin/pyzor", line 240, in check
for digested in get_input_handler(style):
  File "/usr/bin/pyzor", line 177, in _get_input_msg
msg = email.message_from_bytes(get_binary_stdin().read())
NameError: name 'get_binary_stdin' is not defined

The fix from
https://github.com/SpamExperts/pyzor/commit/6332a429ed415187599ecce7d8a169ee19f0bbe5
is not enough, as the code from
https://github.com/SpamExperts/pyzor/commit/67b471dd168db9468548aef3ffadca9554164ac0
implementing this function is needed for it to work.

Gentoo carries the same fix at
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=300f46c1c52cc79238e88dba28241a6e78525966

Grüße,
Sven.

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pyzor depends on:
ii  python3  3.9.1-1

pyzor recommends no packages.

Versions of packages pyzor suggests:
pn  pyzor-doc  

-- debconf-show failed

Bug#979853: fp-compiler-3.2.0: does not install: postinst: line 68: --slave: command not found

[Sven Hartge]

Package: fp-compiler-3.2.0
Version: 3.2.0+dfsg-9
Severity: grave
Justification: renders package unusable

Hi!

During postinst the following happens:

Setting up fp-compiler-3.2.0:amd64 (3.2.0+dfsg-9) ...
Saved old "fpc-3.2.0.cfg" to "fpc-3.2.0.bak"
/var/lib/dpkg/info/fp-compiler-3.2.0:amd64.postinst: line 68: --slave: command 
not found

Reason: Line 67 misses the \ at the end for the continuation line to
work.

Grüße
Sven.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (400, 'testing'), (100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.10.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages fp-compiler-3.2.0 depends on:
ii  binutils   2.35.1-7
ii  debconf [debconf-2.0]  1.5.74
ii  fp-units-rtl-3.2.0 3.2.0+dfsg-9
ii  libc6  2.31-9

Versions of packages fp-compiler-3.2.0 recommends:
ii  fp-utils-3.2.0  3.2.0+dfsg-9

Versions of packages fp-compiler-3.2.0 suggests:
pn  fp-docs-3.2.0  

-- debconf information excluded

Bug#975376: Fails to build with Linux 5.9.9 because of change in ip_route_me_harder()

[Sven Hartge]

Package: xtables-addons-dkms
Version: 3.11-1
Severity: grave

Hi!

Kernel 5.9.9 changes ip_route_me_harder() with commit
46d6c5ae953cc0be38efd0e469284df7c4328cf8 causing a build failure for
xtables-addons-dkms:

,
| In file included from 
/usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245,
|  from 
/var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:20:
| /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:74: 
note: expected ‘struct sk_buff *’ but argument is of type ‘unsigned int’
|19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct 
sk_buff *skb, unsigned addr_type);
|   |  
^~~
| /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:125:6: error: 
too few arguments to function ‘ip_route_me_harder’
|   125 |  if (ip_route_me_harder(net, nskb, addr_type))
|   |  ^~
| In file included from 
/usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245,
|  from 
/var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:20:
| /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:5: 
note: declared here
|19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct 
sk_buff *skb, unsigned addr_type);
|   | ^~
| /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c: In function 
‘echo_tg4’:
| /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:195:39: error: 
passing argument 2 of ‘ip_route_me_harder’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
|   195 |  if (ip_route_me_harder(par_net(par), newskb, RTN_UNSPEC) != 0)
|   |   ^~
|   |   |
|   |   struct sk_buff *
| In file included from 
/usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245,
|  from 
/var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:16:
| /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:54: 
note: expected ‘struct sock *’ but argument is of type ‘struct sk_buff *’
|19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct 
sk_buff *skb, unsigned addr_type);
|   | ~^~
| /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:195:6: error: 
too few arguments to function ‘ip_route_me_harder’
|   195 |  if (ip_route_me_harder(par_net(par), newskb, RTN_UNSPEC) != 0)
|   |  ^~
| In file included from 
/usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245,
|  from 
/var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:16:
| /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:5: 
note: declared here
|19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct 
sk_buff *skb, unsigned addr_type);
|   | ^~
`

This has been fixed upstream with 3.12 and 3.13 respectively.

Grüße,
Sven.

Bug#972455: Does not compile for Linux 5.9

[Sven Hartge]

On 18.10.20 22:50, Axel Beckert wrote:


That's strange. Works fine for me. Tested on sid amd64 as well:


I tested this on a different system with 5.9 and got the same result and 
identical make.log.


But, and here it becomes strange: It does work on a third system of mine.

Question now is: What is different and/or broken on the first two 
systems? It seems there are some old or broken header files floating around.



Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU threads)


As with your setup, I haven't rebooted into it yet. Kernel
5.7.0-2-amd64 running here, though, but that _should_ not make a
difference. (That was the kernel which needed that other fix in that
upload as it still needs to be compiled with gcc-9.)


It does not. The second system was rebooted to 5.9.


Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE


That's is likely because of the unsigned out-of-tree ipt_NETFLOW. :-)


Yes, also wireguard (needed in 5.2) and some xtables-addons. But this 
does not matter for compiling the module.



This all looks a lot like https://github.com/aabc/ipt-netflow/issues/152


Yes. Interesting.

But, see above, I seem to have contaminated systems. Something strange 
is going on.


You can reduce the severity to minor for now. As soon as I find how in 
what way two of my systems differ and why, I will update (and quite 
possibly close) the bug.


Grüße,
Sven.

Bug#972455: Does not compile for Linux 5.9

[Sven Hartge]

Package: iptables-netflow-dkms
Version: 2.5.1-1
Severity: grave

Hi!

It seems adfc6318 was not enough to be compatible with Linux 5.9, as
compilation breaks for me with the following log:

---8<--

DKMS make.log for ipt-netflow-2.5.1 for kernel 5.9.0-1-amd64 (x86_64)
Sun 18 Oct 2020 08:10:48 PM CEST
./gen_compat_def > compat_def.h
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h
Test struct timeval linux/ktime.h
Test struct proc_ops linux/proc_fs.h
Test symbol synchronize_sched linux/rcupdate.h
Compiling for kernel 5.9.1
make -C /lib/modules/5.9.0-1-amd64/build 
M=/var/lib/dkms/ipt-netflow/2.5.1/build modules CONFIG_DEBUG_INFO=y
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[1]: Entering directory '/usr/src/linux-headers-5.9.0-1-amd64'
  CC [M]  /var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.o
In file included from /var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:76:
/var/lib/dkms/ipt-netflow/2.5.1/build/compat.h:709:43: warning: ‘struct 
timeval’ declared inside parameter list will not be visible outside of this 
definition or declaration
  709 | static inline void do_gettimeofday(struct timeval *tv)
  |   ^~~
/var/lib/dkms/ipt-netflow/2.5.1/build/compat.h: In function ‘do_gettimeofday’:
/var/lib/dkms/ipt-netflow/2.5.1/build/compat.h:713:4: error: invalid use of 
undefined type ‘struct timeval’
  713 |  tv->tv_sec = ts64.tv_sec;
  |^~
/var/lib/dkms/ipt-netflow/2.5.1/build/compat.h:714:4: error: invalid use of 
undefined type ‘struct timeval’
  714 |  tv->tv_usec = ts64.tv_nsec/1000;
  |^~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c: In function ‘nf_seq_show’:
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:755:39: warning: format 
‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type 
‘s64’ {aka ‘long long int’} [-Wformat=]
  755 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  | ~~^
  |   |
  |   long unsigned int
  | %llu
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:755:54: warning: format 
‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type 
‘s64’ {aka ‘long long int’} [-Wformat=]
  755 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  |~~^
  |  |
  |  long unsigned int
  |%llu
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:759:39: warning: format 
‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type 
‘s64’ {aka ‘long long int’} [-Wformat=]
  759 |seq_printf(seq, " Flows selected %lu.", 
atomic64_read(_selected));
  | ~~^
  |   |
  |   long unsigned int
  | %llu
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c: In function 
‘netflow_export_pdu_v5’:
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2652:17: error: storage 
size of ‘tv’ isn’t known
 2652 |  struct timeval tv;
  | ^~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2652:17: warning: unused 
variable ‘tv’ [-Wunused-variable]
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c: In function 
‘netflow_export_pdu_v9’:
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2736:17: error: storage 
size of ‘tv’ isn’t known
 2736 |  struct timeval tv;
  | ^~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2736:17: warning: unused 
variable ‘tv’ [-Wunused-variable]
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c: In function 
‘netflow_export_pdu_ipfix’:
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2770:17: error: storage 
size of ‘tv’ isn’t known
 2770 |  struct timeval tv;
  | ^~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:2770:17: warning: unused 
variable ‘tv’ [-Wunused-variable]
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c: In function 
‘timeout_rate_j’:
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:3677:10: error: variable 
‘tv’ has initializer but incomplete type
 3677 |   struct timeval tv = { .tv_sec = timeout_rate * 60, .tv_usec = 0 };
  |  ^~~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:3677:26: error: ‘struct 
timeval’ has no member named ‘tv_sec’
 3677 |   struct timeval tv = { .tv_sec = timeout_rate * 60, .tv_usec = 0 };
  |  ^~
/var/lib/dkms/ipt-netflow/2.5.1/build/ipt_NETFLOW.c:3677:35: warning: excess 
elements in struct initializer
 3677 |   struct timeval tv = { .tv_sec = timeout_rate * 

Bug#972454: Does not build with Linux 5.9, but new compatible release available upstream

[Sven Hartge]

Package: xtables-addons-dkms
Version: 3.9-1
Severity: grave
Tags: patch

Hello!

As the subject says: The current version 3.9 does not build with Linux
5.9, but a new upstream release is available.

I created a MR in Salsa correcting this:

https://salsa.debian.org/debian/xtables-addons/-/merge_requests/1

It contains the following changes:

 New upstream release, compatible with Linux 5.9
 
 * Update watch file to new release location
   Releases can now be downloaded from https://inai.de/files/xtables-addons/
 * Disable patches integrated upstream
 * Also install xt_geoip_fetch script and man page

Grüße,
Sven.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xtables-addons-dkms depends on:
ii  dkms   2.8.3-4
ii  make   4.3-4
ii  xtables-addons-common  3.11-0.0~sh.1

Versions of packages xtables-addons-dkms recommends:
pn  linux-headers  

xtables-addons-dkms suggests no packages.

-- debconf-show failed

Bug#954736: Upgrade to 9.16.1-1 causes dhcpd to die with SIGABRT

[Sven Hartge]

On 22.03.20 19:07, Sven Hartge wrote:

> Interestingly, isc-dhcp-server 4.4.1 does not even compile against the
> current 9.16 libs from Sid right now. Something is very broken here.

I have to correct that part. It seems my checkout from Salsa was wrong,
as recompiling the source package works.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#954736: Upgrade to 9.16.1-1 causes dhcpd to die with SIGABRT

[Sven Hartge]

Package: bind9
Version: 1:9.16.1-2
Severity: critical
Justification: breaks unrelated packages

Hi!

The recent upgrade from 1:9.11.16+dfsg-2 to 1:9.16.1-1 causes
isc-dhcp-server to die upon start with SIGABRT, creating the following
backtrace:

8<
GNU gdb (Debian 9.1-2) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/dhcpd...
Reading symbols from 
/usr/lib/debug/.build-id/ed/444f0630db7a22e134b6492994fb9e5481c253.debug...
[New LWP 3946312]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `dhcpd -t'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 4, 223338299409, 0, 0, 139816691506048, 262160, 
139816690240512, 0, 15, 257, 5501063141756457984, 1, 44, 4294967295, 
4294967295}}
pid = 
tid = 
ret = 
#1  0x7f299c21a55b in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x30, sa_sigaction = 0x30}, 
sa_mask = {__val = {139816691747131, 139816692083696, 4398046511104, 17, 
139816692083456, 
  94694505873952, 139816693949594, 924, 48, 0, 139816691767231, 
94694505873952, 5501063141756457984, 94694505873952, 1, 0}}, sa_flags = 0, 
  sa_restorer = 0x561fc7fa88e0 }
sigs = {__val = {32, 0 }}
#2  0x7f299c3da3ff in isc_assertion_failed (file=file@entry=0x7f299c421e9b 
"../../../lib/isc/hash.c", line=line@entry=217, 
type=type@entry=isc_assertiontype_require, 
cond=cond@entry=0x7f299c42047a "mctx != ((void *)0)") at 
../../../lib/isc/assertions.c:52
No locals.
#3  0x7f299c3df6fa in isc_hash_create (mctx=, 
entropy=entropy@entry=0x0, limit=limit@entry=255) at ../../../lib/isc/hash.c:225
result = 0
#4  0x7f299c4b36bf in initialize () at ../../../lib/dns/lib.c:91
result = 
result = 
#5  dns_lib_init () at ../../../lib/dns/lib.c:127
result = 
#6  0x561fc7f3b498 in dhcp_context_create (flags=1, local4=0x0, local6=0x0) 
at isclib.c:171
result = 
#7  0x561fc7eb6f17 in main (argc=2, argv=0x7ffd9f040a18) at dhcpd.c:404
fd = 
i = 
status = 
ent = 
s = 
cftest = 0
lftest = 0
pid = 
pbuf = 
"\006\t\004\237\375\177\000\000\265\311)\234)\177\000\000\000\000\000"
daemon = 
dfd = {-1, -1}
quiet = 0
server = 0x0
result = 
seed = 
ip = 
parse = 0xc2
lose = 0
have_dhcpd_conf = 0
have_dhcpd_db = 0
have_dhcpd_pid = 0
local_family_set = 0
traceinfile = 0x0
traceoutfile = 0x0
set_user = 0x0
set_group = 0x0
set_chroot = 0x0
8<

I needed to downgrade quite many library packages out of the whole ISC
library ecosystem back down to the ones in testing to be able to start
dhcpd again:

2020-03-22 18:52:14 upgrade libbind9-161:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:52:15 upgrade libisccfg163:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:52:16 upgrade libirs161:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:52:46 upgrade bind9-libs:amd64 1:9.16.1-2 1:9.16.1-1
2020-03-22 18:52:50 upgrade libisccc161:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:52:51 upgrade libisc1105:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:54:10 upgrade liblwres161:amd64 1:9.11.17+dfsg-2 1:9.11.16+dfsg-2
2020-03-22 18:57:05 upgrade libirs-export161:amd64 1:9.11.17+dfsg-2 
1:9.11.16+dfsg-2
2020-03-22 18:58:18 upgrade libisc-export1105:amd64 1:9.11.17+dfsg-2 
1:9.11.16+dfsg-2
2020-03-22 19:02:22 upgrade libisccfg-export163-dbgsym:amd64 1:9.11.17+dfsg-2 
1:9.11.16+dfsg-2
2020-03-22 19:02:26 upgrade libisccfg-export163:amd64 1:9.11.17+dfsg-2 
1:9.11.16+dfsg-2

Interestingly, isc-dhcp-server 4.4.1 does not even compile against the
current 9.16 libs from Sid right now. Something is very broken here.

Grüße,
Sven.

-- System Information:
Debian 

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Sven Hartge]

On 16.04.19 15:12, Vincent Lefevre wrote:

> access("/var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d/60-latin.conf", R_OK) = > 0
> stat("/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d/60-latin.conf",
>  0x7ffc35e33b50) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, 
> "/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d/60-latin.conf",
>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> writev(2, [{iov_base="free(): double free detected in "..., iov_len=40}, 
> {iov_base="\n", iov_len=1}], 2) = 41

My uneducated guess is, the problem is here. See how the prefix
"/var/tmp/mkinitramfs_0BRFs9/" is applied twice, somehow?

I think this bug should be reassigned to fontconfig, with plymouth being
affected by it.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Sven Hartge]

On 16.04.19 14:32, Vincent Lefevre wrote:
> On 2019-04-16 01:53:03 +0200, Sven Hartge wrote:
>> Try running the following commands as root:
>>
>> mkdir -p /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
>> cp -a /etc/fonts/fonts.conf /var/tmp/mkinitramfs_0BRFs9/etc/fonts
>> cp -rL /etc/fonts/conf.d/60-latin.conf 
>> /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
>> mkdir -p /var/tmp/mkinitramfs_0BRFs9/var/cache/fontconfig
>> mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/local/share/fonts
>> mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
>> cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf 
>> /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
>> cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 
>> /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
>> fc-cache -v -s -y /var/tmp/mkinitramfs_0BRFs9
> 
> [...]
> # fc-cache -v -s -y /var/tmp/mkinitramfs_0BRFs9
> free(): double free detected in tcache 2
> Aborted

Interesting. Care to run it with strace to see exactly where it barfs?

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Sven Hartge]

Um 01:35 Uhr am 16.04.19 schrieb Vincent Lefevre:
> On 2019-04-15 23:07:02 +0200, Sven Hartge wrote:

>> Could you add "set -x" to the top of
>> /usr/share/initramfs-tools/hooks/plymouth to get a clear picture where
>> exactly the hook fails?
 
> It is also fc-cache that is failing:

> + mkdir -p /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
> + cp -a /etc/fonts/fonts.conf /var/tmp/mkinitramfs_0BRFs9/etc/fonts
> + cp -rL /etc/fonts/conf.d/60-latin.conf 
> /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
> + mkdir -p /var/tmp/mkinitramfs_0BRFs9/var/cache/fontconfig
> + mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/local/share/fonts
> + [ -e /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf ]
> + mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
> + cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf 
> /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
> + cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 
> /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
> + fc-cache -s -y /var/tmp/mkinitramfs_0BRFs9
> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 134.
> 
> 134 corresponds to SIGABRT, which is not a normal termination
> (even in case of error). Thus I would assume that it is a bug
> in fc-cache.

Try running the following commands as root:

mkdir -p /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
cp -a /etc/fonts/fonts.conf /var/tmp/mkinitramfs_0BRFs9/etc/fonts
cp -rL /etc/fonts/conf.d/60-latin.conf 
/var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
mkdir -p /var/tmp/mkinitramfs_0BRFs9/var/cache/fontconfig
mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/local/share/fonts
mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf 
/var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 
/var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
fc-cache -v -s -y /var/tmp/mkinitramfs_0BRFs9

It uses the same commands from the bash trace, but added "-v" to the
fc-cache call, to exactly see what it is choking on. This got me to
/usr/X11R6/lib/X11 in my case (which just shows how old the installation
on my workstation is).

If this is inconclusive, add "strace -f" to the fc-cache call, maybe even
gdb, if you know how to use it.

Sidenote here: something is very brittle about fc-cache. I had to debug
and fix more fc-cache and fontconfig issues in the last years using Debian
Sid than I had other issues.

Grüße,
Sven.

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Sven Hartge]

On Mon, 15 Apr 2019 18:10:18 +0200 Vincent Lefevre 
wrote:

> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Setting up initramfs-tools (0.133) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools (0.133) ...
> update-initramfs: Generating /boot/initrd.img-4.19.0-4-amd64
> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 134.
> update-initramfs: failed for /boot/initrd.img-4.19.0-4-amd64 with 134.
> dpkg: error processing package initramfs-tools (--configure):
>  installed initramfs-tools package post-installation script subprocess 
> returned error exit status 134
> Errors were encountered while processing:
>  initramfs-tools

I see the same here.

In my case the reason was fc-cache was failing because of a very very
old directory /usr/X11R6/lib/X11 containing old left over fonts.

After removal of /usr/X11R6/lib/X11 the installation of plymouth and
update-initramfs started to work again.

I've archived the directory in case someone wants to play with it and
its contents.

Could you add "set -x" to the top of
/usr/share/initramfs-tools/hooks/plymouth to get a clear picture where
exactly the hook fails?

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

Package: atop
Version: 2.4.0-1
Severity: grave

Hello!

After the update tpo 2.4.0-1 atop does not start anymore for me.
TL;DR: 

existing file /var/log/atop/atop_20190120 has incompatible header
(created by version 2.3 - current version 2.4)

Here the whole debugging session:

server:~# systemctl start atop; systemctl status atop; sleep 2; systemctl 
status atop
● atop.service - Atop advanced performance monitor
   Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Sun 2019-01-20 19:08:50 CET; 11ms ago
 Docs: man:atop(1)
 Main PID: 550488 (atop.daily)
Tasks: 5 (limit: 4691)
   Memory: 1.5M
   CGroup: /system.slice/atop.service
   ├─550488 /bin/bash /usr/share/atop/atop.daily
   ├─550491 ps -p 547913
   └─550492 grep atop$
● atop.service - Atop advanced performance monitor
   Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Sun 2019-01-20 19:08:50 CET; 1s ago
 Docs: man:atop(1)
  Process: 550488 ExecStart=/usr/share/atop/atop.daily (code=exited, status=7)
 Main PID: 550488 (code=exited, status=7)

As one can see, the unit starts /usr/share/atop/atop.daily but no daemon
remains at the end.

Even when running the shell script directly, nothing happens:

server:~# ps auwwwx | grep [a]top; rm /run/atop.pid; bash -x 
/usr/share/atop/atop.daily; sleep 5; ps auwwwx | grep [a]top
user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
/usr/bin/python3 /usr/bin/reportbug atop
user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim -c 
:6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa
+ LOGOPTS=-R
+ LOGINTERVAL=600
+ LOGGENERATIONS=28
+ DEFAULTSFILE=/etc/default/atop
+ '[' -e /etc/default/atop ']'
+ . /etc/default/atop
+ case "$LOGGENERATIONS" in
++ date +%Y%m%d
+ CURDAY=20190120
+ LOGPATH=/var/log/atop
+ BINPATH=/usr/bin
+ PIDFILE=/run/atop.pid
+ '[' -e /run/atop.pid ']'
+ sleep 3
+ echo 555663
+ exec /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
+ find /var/log/atop -name 'atop_*' -mtime +28 -exec rm '{}' ';'
user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
/usr/bin/python3 /usr/bin/reportbug atop
user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim -c 
:6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa

(You can see the open reportbug where I type this in right now.)

Running atop directly shows the problem:

server:~# /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
existing file /var/log/atop/atop_20190120 has incompatible header
(created by version 2.3 - current version 2.4)

Deleting all files in /var/log/atop/ makes it work again.

Side not: the error message does *not* appear in the journal nor the syslog.

Grüße,
Sven.

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

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

Versions of packages atop depends on:
ii  libc62.28-5
ii  libncurses6  6.1+20181013-1
ii  libtinfo66.1+20181013-1
ii  lsb-base 10.2018112800
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages atop recommends:
ii  cron [cron-daemon]  3.0pl1-130

atop suggests no packages.

-- debconf-show failed

Bug#893844: borgbackup: upgrade of python3-msgpack creates version conflict

[Sven Hartge]

On 23.03.2018 11:03, Gianfranco Costamagna wrote:

> I don't know what broke it, but seems not a borgbackup issue?

This was

 https://github.com/borgbackup/borg/issues/3515
 "DistributionNotFound error with msgpack-python 0.5.0 installed"

and also

  https://github.com/msgpack/msgpack-python/issues/268
  "package rename issues with msgpack 0.5.0"

Looks like a borg *and* msgpack issue to me.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#871229: /usr/sbin/update-grub: running update-grub segment faults

[Sven Hartge]

On Wed, 28 Feb 2018 22:37:41 +0100 Martin Zobel-Helas 
wrote:

> I get segfaults when running update-grub on my Lenovo Thinkpad x270
> running Debian unstable from today.

I see the same on my Dell Precision 7520.

> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/sbin/grub-probe --device /dev/nvme0n1p1 
> --target=hints_string'.
> Program terminated with signal SIGSEGV, Segmentation fault.

Interesting thing is: we both use a NVME-SSD on an AMD64 system.

My other systems, one 32bit-on-AMD64 on normal SATA disks and one pure
AMD64 on normal SATA disks works without segfault, only the NVME one
shows problems.

Grüße,
Sven.





signature.asc
Description: OpenPGP digital signature

Bug#889073: Permission denied on /run/munin/munin-node.pid

[Sven Hartge]

Hello!

Just for your information:

This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889144 and
https://github.com/systemd/systemd/issues/8085

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#889144: stricter PIDfile handling breaks several daemons

[Sven Hartge]

On Sun, 4 Feb 2018 15:41:37 + Simon Kelley 
wrote:

> With my dnsmasq maintainer hat on, the current arrangement looks like this.
> 
> 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup
> 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops
> root, so is root:root
> 3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can
> unlink the pidfile at shutdown, after it has dropped root and is running
> as 'dnsmasq'

Does dnsmasq need a PIDfile when running under systemd? Can't it just
not double fork, stay in the foreground using a Type=simple systemd unit?

That way the whole problem could be avoided all together.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#889144: stricter PIDfile handling breaks several daemons

[Sven Hartge]

On 04.02.2018 17:25, Michael Biebl wrote:
> Am 03.02.2018 um 14:35 schrieb Sven Hartge:
>> Um 14:00 Uhr am 03.02.18 schrieb Michael Biebl:

>>> The alternative afaics would be, that the daemon writes the pid file as
>>> munin:munin then (or ulog:ulog for the above case).
>>
>> No, this would open a potential DoS vector.
>>
>> Image an attacker gaining access to the munin user. He would then be able
>> to write any PID to the PIDfile and the init system would kill the other
>> process when the munin-node service is stopped/restarted.
>>
> 
> I don't think this applies to systemd though. If the process id listed
> in the pid file is not found in the service cgroup, systemd should not
> kill the process listed in the pid file. I suspect that MainPID will not
> be properly set and systemd will complain about it.

But it applies to SysV-Init. If the init-script does not use
start-stop-daemon correctly to check if the PID in the PIDfile belongs
to the executable to be killed or if the init-script uses some other
method of killing the daemon, it might easily kill a different program.

I know, this is not systemds concern whether other init implementations
behave correctly, but if you change the behaviour of a program because
of a behaviour change in systemd and then break other init systems or
increase the insecurity when used with other init systems because of
this, it will fall back negatively on systemd.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#889144: stricter PIDfile handling breaks several daemons

[Sven Hartge]

Um 14:00 Uhr am 03.02.18 schrieb Michael Biebl:
> Am 03.02.2018 um 13:27 schrieb Sven Hartge:
>> Um 03:02 Uhr am 03.02.18 schrieb Michael Biebl:

>>> Does munin-node have the same mismatch?
 
>> It has:

>> But, as you can see, the directory is also used by the munin-updater
>> which is run as user "munin" so you can't make the directory owned by
>> root.
 
> The alternative afaics would be, that the daemon writes the pid file as
> munin:munin then (or ulog:ulog for the above case).

No, this would open a potential DoS vector.

Image an attacker gaining access to the munin user. He would then be able
to write any PID to the PIDfile and the init system would kill the other
process when the munin-node service is stopped/restarted.

See https://security-tracker.debian.org/tracker/CVE-2017-14610 for
example.

Acknowleged, this is a a bit unlikely issue, but I don't think it would be
wise to propagate it further.

Also looking at the bigger picture here: This change in systemd, while
with security in mind, changes the way PIDfiles have been handled for the
last ... forever.

Debian packages one might be able to fix but what about all the other 3rd
party packages and locally written code out there? It is susceptible to
break upon upgrade to Buster and who will be blamed (again)? systemd of
course, "breaking all the things again".

Grüße,
Sven.

Bug#889144: stricter PIDfile handling breaks several daemons

[Sven Hartge]

Um 03:02 Uhr am 03.02.18 schrieb Michael Biebl:

> Am 02.02.2018 um 20:07 schrieb Sven Hartge:

>> ulogd2 drops its priviliges on its own. It needs to start as root to
>> connect to the netlink sockets.
 
> So, ulogd2 creates a directory /run/ulog which is owned by ulog:ulog but
> then creates the pid file /run/ulog/ulog.pid owned by root:root.

Yes.

> I assume if you overwrite /usr/lib/tmpfiles.d/ulogd2.conf by creating a
> /etc/tmpfiles.d/ulogd2.conf containing
> 
> d /run/ulog 0755 root root - -
> 
> ulogd2 will start properly.

It does. But there must be a reason for the directory to be owned by
ulog:ulog, no? What consequences does it have changing it? It may work for
my simple setup but then break again for other people.

> I assume, ulogd2 should either ensure the pidfile is owned ulog:ulog or
> change the run directory to match the permissions of the pid file.
> 
> Does munin-node have the same mismatch?

It has:

,
| ds9:/run/munin# ls -al
| total 8
| drwxr-xr-x  2 munin root80 Feb  3 13:15 .
| drwxr-xr-x 55 root  root  1880 Feb  3 02:57 ..
| -rw-r--r--  1 munin munin7 Feb  3 13:15 
munin-feds.ath.cx-skuld.feds.ath.cx.lock
| -rw-r--r--  1 munin munin7 Feb  3 13:15 
munin-svenhartge.de-www.svenhartge.de.lock
`

But, as you can see, the directory is also used by the munin-updater
which is run as user "munin" so you can't make the directory owned by
root.

S°

Bug#873921: python3.5_3.5.4-3 breaks borgbackup: undefined symbol: PyFPE_jbuf

[Sven Hartge]

Package: borgbackup
Version: 1.0.11-3
Severity: grave

Hi!

I am reporting this bug against borgbackup, because I am not sure if the
bug is in python3.5 or borgbackup just needs to be binNMUd. Please
reassign as you see fit.

The upload of python3.5 (3.5.4-3) disables the fpectl extension and
breaks borgbackup:

$ borg
Traceback (most recent call last):
  File "/usr/bin/borg", line 11, in 
load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 
from .helpers import Error, location_validator, archivename_validator, 
format_line, format_time, format_file_size, \
  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 
from . import crypto
ImportError: 
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-i386-linux-gnu.so: 
undefined symbol: PyFPE_jbuf

Grüße,
Sven.

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

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

Versions of packages borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libc6  2.24-17
ii  liblz4-1   0.0~r131-2+b1
pn  libssl1.1  
ii  python33.5.3-3
ii  python3-llfuse 1.2+dfsg-1+b1
ii  python3-msgpack0.4.8-1+b1
ii  python3-pkg-resources  36.2.7-2

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- debconf-show failed

Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.

[Sven Hartge]

On 07.01.2017 21:24, Julian Andres Klode wrote:
> On Sat, Jan 07, 2017 at 09:15:15PM +0100, Sven Hartge wrote:
>> On Mon, 26 Dec 2016 14:40:05 +0100 (CET) <34tg...@tutanota.com> wrote:
>>
>>> I use Debian 8 64bit with GNOME installed with standard install
>>> procedure from netinstall and using tasksel. This occured to me the
>>> second time. First time was a year ago, I reinstalled Debian then and
>>> a year after this happens again. Both occurences were on Debian 8,
>>> stable at the time.
>>
>> I have seen this as well and know under which circumstances this happens:
>>
>> a) backports repository is enabled in source.list (obviously)
>> b) "apt update" is run and all normal repositories fail to download or
>> are invalid
>>
>> When this happens, apt will happily upgrade all packages where a
>> backported version exists to that version.
> 
> This should not happen. The old repository state should be used, and thus
> the pinning should not change. 

That's what I thought as well.

> That said, maybe that only works right in 1.1 and newer, I don't
> really know.

I have definitely seen this in Jessie, maybe even Wheezy (memory a bit
fuzzy in that regard).

I run apticron on all our servers (~250) and it happened about once a
month that one (a different one every time) of the server prompted to
upgrade all packages to their backports-version.

But after switching from httpredir.debian.org to deb.debian.org this
problem did not occur again, so far at least.

But there is absolutely something problematic with the version in Jessie
where it is possible to trigger the behavior from this bug report.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.

[Sven Hartge]

On Mon, 26 Dec 2016 14:40:05 +0100 (CET) <34tg...@tutanota.com> wrote:

> I use Debian 8 64bit with GNOME installed with standard install
> procedure from netinstall and using tasksel. This occured to me the
> second time. First time was a year ago, I reinstalled Debian then and
> a year after this happens again. Both occurences were on Debian 8,
> stable at the time.

I have seen this as well and know under which circumstances this happens:

a) backports repository is enabled in source.list (obviously)
b) "apt update" is run and all normal repositories fail to download or
are invalid

When this happens, apt will happily upgrade all packages where a
backported version exists to that version.

Why?

Because of the pin value of a package in such a case. For example:

# apt-cache policy exim4
exim4:
  Installed: 4.84.2-2+deb8u2
  Candidate: 4.84.2-2+deb8u2
  Version table:
 4.88~RC6-2~bpo8+1 0
100 http://deb.debian.org/debian/ jessie-backports/main amd64
Packages
 *** 4.84.2-2+deb8u2 0
500 http://deb.debian.org/debian-security/ jessie/updates/main
amd64 Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 4.84.2-2+deb8u1 0
500 http://deb.debian.org/debian/ jessie/main amd64 Packages

The backports pacakges has a value of 100 as has the installed package.
The package from the normal repository is at 500 and thus the candidate.

If the normal repositories fail to download and are invalid the
backported package and the installed package both are the only
candidates left (and are both at the same pin value) and because the
backported package has a higher version it is installed.

Workaround:

Have more than one mirror configured so that the chance is higher that
at least one is valid.

Grüße,
Sven.

Bug#843838: [pkg-bacula-devel] Bug#843838: Bug#843838: Bug#843838: Fail to access config file

[Sven Hartge]

On 10.11.2016 18:51, Jörg Frings-Fürst wrote:

> I guess that the error is the wrong group.

Of course, this is obvious.

> But the error comes not from use rsync without --numeric-ids.
> I don't use rsync, I have moved the hard disk with dd.
> 
> But also I have no idea from where the dirmngr comes.

I also have no idea, but I find it very suspicious that every group that
should be "bacula" is "dirmngr" on your system, as if someone/something
changed /etc/group or replaced it with a one not belonging to the system.

> A note:
> 
> If you change "the way the daemons are started" please check and change
> the required user/group.

I tested this change on several systems, some newly installed Sid, some
upgraded from Jessie, some even upgraded from Squeeze and older.

Every sane system had the correct groups and users for /etc/bacula/*.

The only change for permissions and owners was needed for
/etc/bacula/bacula-sd.conf and this is done in bacula-sd.postinst.

In my opinion this problem is not a bug in the bacula package but your
system was broken to begin with and this change just exposed it.

You need to find out who or what made the changes to /etc/group as more
problems may linger.

I personally also don't see an obligation for Debian packages to check
every possible angle an administrator could have manually broken their
system and try to work around this, but YMMV.

Just broadly changing and overwriting every permission in /etc/bacula/
is also wrong, as the administrator might have made working changes
which we don't want to destroy.

Grüße,
Sven.





signature.asc
Description: OpenPGP digital signature

Bug#843838: [pkg-bacula-devel] Bug#843838: Bug#843838: Fail to access config file

[Sven Hartge]

On 10.11.2016 16:41, Jörg Frings-Fürst wrote:
> Am Donnerstag, den 10.11.2016, 09:25 +0100 schrieb Sven Hartge:

>> Was the system in question at some time in the past cloned/copied via
>> rsync (without using --numeric-ids) or any other method while having
>> been bootet from a rescue medium like GRML or Knoppix?

> One year ago I have move the system 1:1 (tested) to a new hardrive. 
> And the error occurred after the last update.

The error is triggered by a change in the way the daemons are started,
as indicated in the changelog, but the core error is the wrong group
(dirmngr != bacula) on your system.

I really think this happened during your system move (it happened to me
as well in the past, forgot to add --numeric-ids to rsync) but you did
not notice it, because most users either matched or the programs don't
care about them, because they are started as root.

I guess if you check other dynamic system users (meaning users created
by packaging scripts and not hardcoded into base-passwd) and groups you
will still find additional mismatches somewhere in /etc and other places.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#843838: [pkg-bacula-devel] Bug#843838: Fail to access config file

[Sven Hartge]

On 10.11.2016 08:05, Jörg Frings-Fürst wrote:

> # ls -l /etc/bacula/
> insgesamt 104
> -rw-r- 1 root   dirmngr 9343 Feb 20  2016 bacula-dir.conf
> -rw-r- 1 root   bacula  9156 Aug 18 14:12 bacula-dir.conf.dist
> -rw-r- 1 root   dirmngr 1024 Sep 29  2013 bacula-fd.conf

This looks highly suspicious and reminds me of something that happened
to me in the past:

Was the system in question at some time in the past cloned/copied via
rsync (without using --numeric-ids) or any other method while having
been bootet from a rescue medium like GRML or Knoppix?

It seems the numerical UID in the rootfs got messed up.

Could you also please provide the output of

ls -ln /etc/bacula
getent group dirmngr
getent group bacula

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#832357: [pkg-bacula-devel] Bug#832357: bacula-director-*: fails to upgrade from 'sid' - trying to overwrite /etc/init.d/bacula-director

[Sven Hartge]

On 24.07.2016 16:44, Andreas Beckmann wrote:

> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
> It installed fine in 'sid', then the upgrade to 'experimental' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

Yes, this is my fault and already fixed in GIT and will be fixed in the
archive with the next upload to experimental.

Grüße,
Sven.





signature.asc
Description: OpenPGP digital signature

Bug#818551: golang-golang-x-tools: provides same file '/usr/bin/bundle' as ruby-bundler

[Sven Hartge]

Package: golang-golang-x-tools
Version: 1:0.0~git20160315.0.f42ec61-1
Severity: serious
Justification: Policy 10.1

Hi!

The subject says it all:

The following packages will be upgraded: 
  golang-golang-x-tools 
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/14.8 MB of archives. After unpacking 15.9 MB will be used.
Do you want to continue? [Y/n/?] 
(Reading database ... 746195 files and directories currently installed.)
Preparing to unpack 
.../golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb ...
Unpacking golang-golang-x-tools (1:0.0~git20160315.0.f42ec61-1) over 
(1:0.0~git20151026.0.0f9d71c-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb
 (--unpack):
 trying to overwrite '/usr/bin/bundle', which is also in package ruby-bundler 
1.11.2-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 
/var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Grüße,
Sven

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (400, 'testing'), 
(100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages golang-golang-x-tools depends on:
ii  golang-golang-x-tools-dev  1:0.0~git20160315.0.f42ec61-1
ii  libc6  2.22-3

golang-golang-x-tools recommends no packages.

golang-golang-x-tools suggests no packages.

-- no debconf information

Bug#818036: "kpartx does not ship multipathd.service but tries to start/stop that service" not fixed in 0.5.0+git1.656f8865-7

[Sven Hartge]

On 16.03.2016 09:33, Ritesh Raj Sarraf wrote:
> On Tue, 2016-03-15 at 23:35 +0530, Ritesh Raj Sarraf wrote:

>> Okay! I'd agree on the last statement. :-)
>> I'll fix it soon.
>>
>> For others who get hit, Sven has mentioned the workaround in this bug
>> report.
> 
> Can you test the attached .deb package ?

Yes, this works for me:

/tmp/d# dpkg -i kpartx_0.5.0+git1.656f8865-8_amd64.deb
(Reading database ... 739417 files and directories currently installed.)
Preparing to unpack kpartx_0.5.0+git1.656f8865-8_amd64.deb ...
Failed to stop multipathd.service: Unit multipathd.service not loaded.
dpkg: warning: subprocess old pre-removal script returned error exit
status 5
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK
Unpacking kpartx (0.5.0+git1.656f8865-8) over (0.5.0+git1.656f8865-6) ...
Setting up kpartx (0.5.0+git1.656f8865-8) ...
Processing triggers for man-db (2.7.5-1) ...

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#818036: "kpartx does not ship multipathd.service but tries to start/stop that service" not fixed in 0.5.0+git1.656f8865-7

[Sven Hartge]

On Tue, 15 Mar 2016 22:28:49 +0530 Ritesh Raj Sarraf  wrote:

> If you upgrade from -5 to -7, you shouldn't be hitting this problem. I
> thought about handling the breakage, but that would touch files outside
> , which I'm not keen on. 
> 
> And Unstable is supposed to have breakages.

Sorry, but I find this unacceptable. Sure, Unstable can have breakages,
but is not supposed to have one. You cannot just ignore one upgrade path
because it is inconvenient for you.

The -6 package has been release to mirrors and has been installed on
systems, so you have to provide a clean upgrade path to the next package
and not just walk away saying "upgrade from -6 to -7 are not supported"
and leave the user to manually put the package into a working state again.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#818036: "kpartx does not ship multipathd.service but tries to start/stop that service" not fixed in 0.5.0+git1.656f8865-7

[Sven Hartge]

On 15.03.2016 18:16, Ritesh Raj Sarraf wrote:

> I am not walking away. The failure is 2 folds. If you got hit by -6, on
> your machine the (broken) maintainer script gets installed, which you'll
> have to manually remove.

No, I do not. It is your job as package maintainer to clean this up. You
broke it, you fix it.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#813339: isc-dhcp-server: Update to 4.3.3-7 today makes isc-dhcp-server unable to work

[Sven Hartge]

On Tue, 16 Feb 2016 23:10:33 +0100 Pierre Ynard  wrote:

> Thank you for your efforts to fix most of the issues with the
> initscript.

There is one other issue with the init-script:

The config option points to the same config file:

DHCPDv4_CONF=${DHCPDv4_CONF:-/etc/dhcp/dhcpd.conf}
DHCPDv6_CONF=${DHCPDv6_CONF:-/etc/dhcp/dhcpd.conf}

This will not work, both config files have a different syntax and have
to be different.

I propose /etc/dhcp/dhcp6.conf as name for the IPv6 config file.

(The same error is made in /etc/default/isc-dhcp-server.)

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#805738: wrong dependency on python-acme

[Sven Hartge]

On Sat, 21 Nov 2015 21:56:50 +0100 Sven Hartge <s...@svenhartge.de> wrote:

> The following packages have unmet dependencies:
>  python-letsencrypt : Depends: python-acme (= 0.0.0.dev20151114) but 
> 0.0.0.dev20151114-1 is to be installed
> E: Unable to correct problems, you have held broken packages.

The new upload also depends on a non-existing version of python-acme and
is uninstallable:

Package: python-letsencrypt
Version: 0.0.0.dev20151123-1
Installed-Size: 375
Maintainer: Debian Let's Encrypt <letsencrypt-de...@lists.alioth.debian.org>
Architecture: all
Depends: python-acme (= 0.0.0.dev20151123)
^^^!

The real version of python-acme is 0.0.0.dev20151123-1.

You cannot use "python-acme (= ${source:Upstream-Version})" as a version
to depend on as this lacks the Debian part of the package version.

If you really want to lock this package and python-acme very tightly you
either hard-code the needed version or build them from the same source
and can _then_ use "ython-acme (= ${binary:Version}) to get the
dependencies right.

Grüße,
Sven.

Bug#805738: wrong dependency on python-acme

[Sven Hartge]

On Sat, 21 Nov 2015 21:56:50 +0100 Sven Hartge <s...@svenhartge.de> wrote:

> In trying to fix #805185 you added a dependency on

This is of course bug #805186

Grüße,
Sven.

Bug#805738: wrong dependency on python-acme

[Sven Hartge]

Package: python-letsencrypt
Version: 0.0.0.dev20151114-3
Severity: serious

Hi!

In trying to fix #805185 you added a dependency on

  python-acme (= ${source:Upstream-Version})

to the python-letsencrypt package, but this prohibits the installation
of that package:

The following packages have unmet dependencies:
 python-letsencrypt : Depends: python-acme (= 0.0.0.dev20151114) but 
0.0.0.dev20151114-1 is to be installed
E: Unable to correct problems, you have held broken packages.

I think the dependency should look like this:

  python-acme (>= ${source:Upstream-Version})
   ^!

I am no expert on dpkg-substvars or the Debian policy concerning that matter,
but a local rebuild of python-letsencrypt with that change allows the
package to install correctly. 

As far as I can see, using a >= relation is the only way to ensure that the
python-acme package is at least the same version as the python-letsencrypt
packge.

But this may/will break, if python-acme is upgraded to a higher version
before python-letsencrypt. So you'd need somthing like

  python-acme (>= ${source:Upstream-Version}), python-acme ( <= 
${binary:Version}) 

so that the version of the python-acme package is at least the same upstream
version but not higher than the version of python-letsencrypt.

This will of course break if the version of python-acme is increased
to a higher Debian release (for example -4 while python-letsencrypt
is still at -3) than python-letsencrypt.

I guess one cannot automatically express such a strict inter-package
dependency if the involved packages are not built from the same
source package. It seems the only viable solution is to manually
specify the correct python-acme version.

Grüße,
Sven.

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

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

Versions of packages python-letsencrypt depends on:
ii  python-acme0.0.0.dev20151114-1
ii  python-configargparse  0.10.0-1
ii  python-configobj   5.0.6-2
ii  python-cryptography1.1-1+b1
ii  python-dialog  3.3.0-1
ii  python-mock1.3.0-2.1
ii  python-openssl 0.15.1-2
ii  python-parsedatetime   1.4-1
ii  python-pkg-resources   18.4-2
ii  python-psutil  2.2.1-3+b1
ii  python-requests2.8.1-1
ii  python-rfc3339 1.0-2
ii  python-six 1.10.0-1
ii  python-tz  2012c+dfsg-0.1
ii  python-zope.component  4.2.2-1
ii  python-zope.interface  4.1.3-1
pn  python:any 

Versions of packages python-letsencrypt recommends:
ii  letsencrypt  0.0.0.dev20151114-3

python-letsencrypt suggests no packages.

-- debconf-show failed

Bug#799734: missing dependency on libfile-slurp-perl

[Sven Hartge]

Package: needrestart
Version: 2.3-1
Severity: grave

Hi!

Subject says it all: needrestart needs libfile-slurp-perl but does not depend
on it, resulting in an error:

Can't locate File/Slurp.pm in @INC (you may need to install the File::Slurp 
module) (@INC contains: /etc/perl 
/usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 
/usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 
/usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 
/usr/local/lib/site_perl .) at /usr/sbin/needrestart line 30.
BEGIN failed--compilation aborted at /usr/sbin/needrestart line 30.

Grüße,
Sven.

-- Package-specific info:
needrestart output:
Your outdated processes:
bash[3605, 5129, 3607, 25048, 3608, 11987, 3606, 16470], pkt-sudo[16681], 
top[7355]

checkrestart output:


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

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

Versions of packages needrestart depends on:
ii  dpkg   1.18.3
ii  libmodule-find-perl0.12-1
ii  libmodule-scandeps-perl1.19-1
ii  libproc-processtable-perl  0.53-1
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.33-1
ii  perl   5.20.2-6

needrestart recommends no packages.

Versions of packages needrestart suggests:
pn  needrestart-session | libnotify-bin  

-- Configuration Files:
/etc/needrestart/notify.d/200-write changed [not included]
/etc/needrestart/notify.d/600-mail changed [not included]

-- debconf-show failed

Bug#772703: postinst fails because of wrong path to 90-sieve-extprograms.conf

[Sven Hartge]

Package: dovecot-sieve
Version: 1:2.2.13-9
Severity: grave

Hi!

The postinst of the dovecot-sieve package searches for 90-sieve-extprograms.conf
in the wrong place:

Setting up dovecot-sieve (1:2.2.13-9) ...
Error: The new file /usr/share/dovecot/90-sieve-extprograms.conf does not exist!
dpkg: error processing package dovecot-sieve (--configure):
 subprocess installed post-installation script returned error exit status 1

Obvious Fix:

--- dovecot-2.2.13/debian/dovecot-sieve.postinst2014-12-09 
12:18:44.0 +0100
+++ dovecot-2.2.13/debian/dovecot-sieve.postinst2014-12-10 
11:02:37.0 +0100
@@ -4,7 +4,7 @@
 
 if [ $1 = configure ]; then
   CONFFILES=conf.d/90-sieve.conf \
-  90-sieve-extprograms.conf
+  conf.d/90-sieve-extprograms.conf
 
   for conffile in $CONFFILES ; do
 # Tell ucf that the file in /usr/share/dovecot is the latest

Grüße,
Sven.

-- Package-specific info:

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

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

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.2.13-9
ii  libc6 2.19-13
ii  ucf   3.0030

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.2.13-9
pn  dovecot-dbgnone
pn  dovecot-devnone
pn  dovecot-gssapi none
ii  dovecot-imapd  1:2.2.13-9
pn  dovecot-ldap   none
pn  dovecot-lmtpd  none
iu  dovecot-managesieved   1:2.2.13-9
pn  dovecot-mysql  none
pn  dovecot-pgsql  none
pn  dovecot-pop3d  none
ih  dovecot-sieve  1:2.2.13-9
pn  dovecot-sqlite none

-- debconf-show failed


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

Bug#765871: does not start with new openssl version

[Sven Hartge]

Package: freeradius
Version: 2.2.5+dfsg-0.1
Severity: grave

Hi!

After the recent upgrade of openssl, freeradius does not start anymore.
freeradius -X results in the following message:

libssl version mismatch.  Built with: 1000109f   Linked: 100010af

After recompiling the package everything is fine again, so a simple BinNMU 
should be enough 
to fix this bug.

Grüße,
Sven.

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

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

Versions of packages freeradius depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20140927
ii  freeradius-common  2.2.5+dfsg-0.1
ii  libc6  2.19-11
ii  libfreeradius2 2.2.5+dfsg-0.1
ii  libgdbm3   1.8.3-13
ii  libltdl7   2.4.2-1.11
ii  libpam0g   1.1.8-3.1
ii  libperl5.205.20.1-1
ii  libpython2.7   2.7.8-10
ii  libssl1.0.01.0.1j-1
ii  lsb-base   4.1+Debian13
ii  ssl-cert   1.0.35

Versions of packages freeradius recommends:
ii  freeradius-utils  2.2.5+dfsg-0.1

Versions of packages freeradius suggests:
pn  freeradius-krb5none
pn  freeradius-ldapnone
pn  freeradius-mysql   none
pn  freeradius-postgresql  none

-- Configuration Files:
/etc/freeradius/acct_users [Errno 13] Permission denied: 
u'/etc/freeradius/acct_users'
/etc/freeradius/attrs [Errno 13] Permission denied: u'/etc/freeradius/attrs'
/etc/freeradius/attrs.access_challenge [Errno 13] Permission denied: 
u'/etc/freeradius/attrs.access_challenge'
/etc/freeradius/attrs.access_reject [Errno 13] Permission denied: 
u'/etc/freeradius/attrs.access_reject'
/etc/freeradius/attrs.accounting_response [Errno 13] Permission denied: 
u'/etc/freeradius/attrs.accounting_response'
/etc/freeradius/attrs.pre-proxy [Errno 13] Permission denied: 
u'/etc/freeradius/attrs.pre-proxy'
/etc/freeradius/clients.conf [Errno 13] Permission denied: 
u'/etc/freeradius/clients.conf'
/etc/freeradius/eap.conf [Errno 13] Permission denied: 
u'/etc/freeradius/eap.conf'
/etc/freeradius/experimental.conf [Errno 13] Permission denied: 
u'/etc/freeradius/experimental.conf'
/etc/freeradius/hints [Errno 13] Permission denied: u'/etc/freeradius/hints'
/etc/freeradius/huntgroups [Errno 13] Permission denied: 
u'/etc/freeradius/huntgroups'
/etc/freeradius/ldap.attrmap [Errno 13] Permission denied: 
u'/etc/freeradius/ldap.attrmap'
/etc/freeradius/policy.conf [Errno 13] Permission denied: 
u'/etc/freeradius/policy.conf'
/etc/freeradius/policy.txt [Errno 13] Permission denied: 
u'/etc/freeradius/policy.txt'
/etc/freeradius/preproxy_users [Errno 13] Permission denied: 
u'/etc/freeradius/preproxy_users'
/etc/freeradius/proxy.conf [Errno 13] Permission denied: 
u'/etc/freeradius/proxy.conf'
/etc/freeradius/sites-available/default changed [not included]
/etc/freeradius/sites-available/inner-tunnel changed [not included]
/etc/freeradius/sql.conf [Errno 13] Permission denied: 
u'/etc/freeradius/sql.conf'
/etc/freeradius/users changed [not included]

-- debconf-show failed


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

Bug#757605: fixed in freerdp 1.1.0~git20140921.1.440916e+dfsg1-1

[Sven Hartge]

On Tue, 23 Sep 2014 12:00:12 + Mike Gabriel sunwea...@debian.org
wrote:
 Source: freerdp
 Source-Version: 1.1.0~git20140921.1.440916e+dfsg1-1
 
 We believe that the bug you reported is fixed in the latest version of
 freerdp, which is due to be installed in the Debian FTP archive.


Umm, how does this fix this bug?

Now remmina-plugin-rdp isn't even installable because libfreerdp1 is no
longer installable (but still in the archive). And doesn't the new split
packages still only provide the 1.1-library while remmina needs the 1.0 one?

In all fairness, I don't consider this bug closed.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#757605: fixed in freerdp 1.1.0~git20140921.1.440916e+dfsg1-1

[Sven Hartge]

On 24.09.2014 10:20, Mike Gabriel wrote:

 In a private post you mentioned that current remmina-master is
 completely broken and the remmina-gtk3 branch still uses the old
 freerdp-1.0 cmake rules (this seems easy to fix, actually).

Yes, see here:
https://github.com/FreeRDP/Remmina/blob/gtk3/cmake/FindFREERDP.cmake

[...]
find_library(FREERDP_LIBRARY NAMES freerdp
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_CLIENT_LIBRARY NAMES freerdp-client
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})
[...]

The master branch uses the correct rules:
https://github.com/FreeRDP/Remmina/blob/master/cmake/FindFREERDP.cmake

[...]
find_library(FREERDP_LIBRARY NAMES freerdp-core
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_GDI_LIBRARY NAMES freerdp-gdi
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_LOCALE_LIBRARY NAMES freerdp-locale
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_RAIL_LIBRARY NAMES freerdp-rail
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_CODEC_LIBRARY NAMES freerdp-codec
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

find_library(FREERDP_CLIENT_LIBRARY NAMES freerdp-client
HINTS ${PC_FREERDP_LIBDIR} ${PC_FREERDP_LIBRARY_DIRS})

[...]

I tried fixing this bus blindly copying the cmake file from the master
branch to the gtk3 branch and recompile. This then finds the libraries
fine but fails with some (to me unfixable) errors during compilatio later.

People knowing about remmina, freerdp and gtk3 should be able to figure
it out, I hope.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#757605: libfreerdp1: changes to soname cause remmina RDP plugin to fail

[Sven Hartge]

On 05.09.2014 16:00, Julien Cristau wrote:
 On Mon, Aug 11, 2014 at 22:14:06 +, Mike Gabriel wrote:
 
 I guess, the approach needs to be:

   (a) provide proper shared libs packages for each libfreerdp-* and
 libwinpr-* shared lib
   (b) make remmina et al. use generic .so files (libfreerdp-*.so).

 Furthermore, we need to check with Remmina upstream about compatibility [1].

 If those strategies fail, I will provide a libfreerdp-1-0 src:package that
 provides the required libfreerdp-*.so.1.0 files.

 I don't think shipping multiple copies of freerdp is a workable
 solution.  This bug needs to be fixed ASAP, and FWIW I think the easiest
 way to do that is to go back to older freerdp.

Problem with going back is: there are already packages which have been
built using the new GIT-based version and depend on features introduced
with that.

In the current state you cannot win , no matter what direction you move in.

If you go back you break those packages (like vlc) again (which will
need a sourceful upload to be fixed, as far as I can see) or you move
forward and resolve the remaining breakage, mainly in remmina.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#748673: chromium-browser: FTBFS, missing protobuf-compiler Build-Depends

[Sven Hartge]

James McCoy write:

 The latest experimental upload didn't include protobuf-compiler in
 Build-Depends, so the buildd build failed[0].

 [0]:
https://buildd.debian.org/status/fetch.php?pkg=chromium-browserarch=i386ver=35.0.1916.99-1stamp=1400365223

Also missing:
gperf
bison
ninja-build

And gcc-4.9 from experimental so linking doesn't fail with memory
exhaustion.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#747135: chromium: FTBFS on i386 due to 32bit linker

[Sven Hartge]

Hi!

I just tested this by adding

 gcc (= 4:4.9.0-2exp2),
 g++ (= 4:4.9.0-2exp2),

to the build-deps and rebuilding inside cowbuilder. With gcc-4.9
chromium is finally able to be linked:

  LINK(target) out/Release/chrome: Finished
  touch out/Release/obj.target/chrome/chrome.stamp
make[1]: Leaving directory '/tmp/buildd/chromium-browser-34.0.1847.137/src'
touch debian/stamp-makefile-build

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#745794: chromium FTBFS on i386 leaves users w/o security support

[Sven Hartge]

 The reporter of bug #745794[1] suggested that it's enough to add the 
 proper build-dependency on libkrb5-dev.  Is this correct, or are there 
 other problems that make finding a fix difficult?

(FYI: I am no DD, just a normal user.)

I tried to rebuild chromium in a pristine Sid chroot with pbuilder, 
resulting in this error from ld:

/usr/bin/ld.gold: fatal error: out/Release/chrome: mmap: failed to allocate 
2237530592 bytes for output file: Cannot allocate memory

The system I am compiling chromium on has 32GB of physical memory and 16GB 
of swap space, none of which were full in any way.

It seems the linker, being a 32bit application, trips over the 3GB memory 
limit for 32bit applications.

This kind of error can be found quite regular in the bug tracker for 
chromium, the advise was always something like man, gotta use a 64bit 
linker, dude!

I wonder how one should do this in a buildd environment.

Grüße,
Sven.


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

Bug#728529: libselinux1: causes ld.so error in smartctl/smartd

[Sven Hartge]

Package: libselinux1
Version: 2.2-1
Severity: critical
Justification: breaks unrelated software

Hi!

The recent upgrade auf libselinux1 to version 2.2-1 in unstable causes
smartctl and smartd to fail with the following message:

system:~# smartctl
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: 
Assertion `needed != ((void *)0)' failed!

Downgrading libselinux1 to 2.1.13-3 solves the problem.

So far only smartctl/smartd is affected, but since this bug affects an
unrelated package, the severity of critical seems correct.

Please also see and maybe merge bug #728507 against smartmontools.

Grüße,
Sven.

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

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


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

Bug#676598: libwine-bin: trying to overwrite '/usr/share/man/man1/regedit.1.gz', which is also in package wine-bin 1.4-3

[Sven Hartge]

Package: libwine-bin
Version: 1.4-4
Severity: serious
Justification: does not upgrade

Hi Wine Maintainers,

during the upgrade from 1.4-3 to 1.4-4 the following happens:

Preparing to replace libwine-bin:i386 1.4-3 (using 
.../libwine-bin_1.4-4_i386.deb) ...
Unpacking replacement libwine-bin:i386 ...
dpkg: error processing /var/cache/apt/archives/libwine-bin_1.4-4_i386.deb 
(--unpack):
 trying to overwrite '/usr/share/man/man1/regedit.1.gz', which is also in 
package wine-bin 1.4-3

Grüße,
Sven.

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

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

Versions of packages libwine-bin depends on:
ii  libc62.13-33
ii  libncurses5  5.9-8
ii  libtinfo55.9-8
ii  libwine  1.4-4

libwine-bin recommends no packages.

libwine-bin suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: package libwine-bin is not installed



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

Bug#676432: wine-bin: fails to upgrade: update-alternatives: error: alternative link /usr/share/man/de.UTF-8/man1/wine.1.gz is already managed by wine.1.de.UTF-8.gz (slave of wine).

[Sven Hartge]

Package: wine-bin
Version: 1.4-3
Severity: serious
Justification: fails to upgrade

Hi Wine Maintainers,

during upgrade to 1.4-3 on Sid the following happens:

Setting up wine-bin (1.4-3) ...
update-alternatives: error: alternative link 
/usr/share/man/de.UTF-8/man1/wine.1.gz is already managed by wine.1.de.UTF-8.gz 
(slave of wine).
dpkg: error processing wine-bin (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of wine:
 wine depends on wine-bin (= 1.4-3); however:
  Package wine-bin is not configured yet.
dpkg: error processing wine (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 wine-bin
 wine


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'experimental'), (400, 'testing'), (300, 
'stable')
Architecture: i386 (x86_64)

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

Versions of packages wine-bin depends on:
ii  libc6  2.13-33
ii  libwine-bin1.4-3
ii  libwine-gecko-1.4  1.4+dfsg-1
ii  x11-utils  7.7~1
ii  xbase-clients  1:7.6+13

wine-bin recommends no packages.

Versions of packages wine-bin suggests:
ii  libwine-gl 1.4-3
ii  libwine-print  1.4-3

Versions of packages libwine depends on:
ii  debconf [debconf-2.0]  1.5.43
ii  libc6  2.13-33
ii  libfreetype6   2.4.9-1
ii  libhal10.5.14-8
ii  libice62:1.0.8-2
ii  libjpeg8   8d-1
ii  libmpg123-01.14.2-1
ii  libpng12-0 1.2.49-1
ii  libsm6 2:1.2.1-2
ii  libssl1.0.01.0.1c-1
ii  libx11-6   2:1.4.99.901-2
ii  libxcursor11:1.1.13-1
ii  libxext6   2:1.3.1-2
ii  libxi6 2:1.6.1-1
ii  libxinerama1   2:1.1.2-1
ii  libxml22.8.0+dfsg1-3
ii  libxrandr2 2:1.3.2-2
ii  libxrender11:0.9.7-1
ii  zlib1g 1:1.2.7.dfsg-11

Versions of packages libwine recommends:
ii  fonts-liberation [ttf-liberation]  1.07.2-2
ii  libgsm11.0.13-4
ii  libwine-alsa   1.4-3
ii  libwine-gl 1.4-3
ii  ttf-liberation 1.07.2-2

Versions of packages libwine suggests:
ii  libwine-cms  1.4-3
ii  libwine-gphoto2  1.4-3
ii  libwine-ldap 1.4-3
ii  libwine-openal   1.4-3
ii  libwine-print1.4-3
ii  libwine-sane 1.4-3
ii  wine-doc 1.0.0-1

-- no debconf information



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

Bug#674832: FTBFS: xattr test fails if /tmp on tmpfs

[Sven Hartge]

Package: obnam
Version: 0.29-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi Lars,

during a rebuild of obnam I stumbled upon the following error:

FAIL: xattr-change-only: stderr diff:   
--- /dev/null   2012-05-27 23:23:24.651956320 +0200
+++ tests/xattr-change-only.stderr-actual   2012-05-28 05:33:43.0 
+0200
@@ -0,0 +1 @@
+setfattr: /tmp/tmp1RwkB9/data/data/foo: Operation not supported

FAIL: xattr-change-only: got exit code 1, expected 0
40/42 tests OK, 2 failures
ERROR: Command '['cmdtest', 'tests']' returned non-zero exit status 1

/tmp is on tmpfs on this system and tmpfs does not support user_xattr.  The
same will happen to any build system, where the FS for /tmp does not have
user_xattr support or the FS is mounted without this option (which seems to be
the case for all Debian buildds, since obnam-0.26 was the last release
successfully build).

I had to move the tmp-dir to a different directory using $TMP and $TMPDIR
to be able to complete the build.

Grüße,
Sven.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'experimental'), (400, 'testing'), (300, 
'stable')
Architecture: i386 (x86_64)

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

Versions of packages obnam depends on:
ii  libc6 2.13-32
ii  python2.7.2-10
ii  python-cliapp 0.29-1
ii  python-larch  1.20120527-1
ii  python-paramiko   1.7.7.1-2
ii  python-tracing0.6-2
ii  python-ttystatus  0.18-1
ii  python2.6 2.6.7-4
ii  python2.7 2.7.3~rc2-2.1

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information



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

Bug#674834: FTBFS: test convert5to6 fails on FS w/o nanosecond resolution

[Sven Hartge]

Package: obnam
Version: 0.26-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi Lars,

during a rebuild of obnam I discovered the following error:

on a filesystem without nanosecond resolution the convert5to6 test
fails:

---8--

FAIL: convert5to6: stdout diff:  
--- /dev/null   2009-03-24 13:37:39.0 +
+++ tests/convert5to6.stdout-actual 2012-05-28 04:13:25.0 +
@@ -0,0 +1,41 @@
+--- data.summain   2012-05-06 16:43:10.0 +
 restored.summain   2012-05-28 04:13:25.0 +
+@@ -1,33 +1,33 @@
+ Name: data
+-Mtime: 2012-04-29 18:45:44.050349637 +
++Mtime: 2012-04-29 18:45:44.0 +
+ Mode: 40775
+ Ino: 1
+ Dev: 1
+ Nlink: 3
+ 
+ Name: data/0
+-Mtime: 2012-04-29 18:45:44.050349637 +
++Mtime: 2012-04-29 18:45:44.0 +
+ Mode: 40775
+ Ino: 2
+ Dev: 1
+ Nlink: 3
+ 
+ Name: data/0/0
+-Mtime: 2012-04-29 18:45:44.050349637 +
++Mtime: 2012-04-29 18:45:44.0 +
+ Mode: 40775
+ Ino: 3
+ Dev: 1
+ Nlink: 3
+ 
+ Name: data/0/0/0
+-Mtime: 2012-04-29 18:45:44.050349637 +
++Mtime: 2012-04-29 18:45:44.0 +
+ Mode: 40775
+ Ino: 4
+ Dev: 1
+ Nlink: 2
+ 
+ Name: data/0/0/0/0
+-Mtime: 2012-04-29 18:45:44.050349637 +
++Mtime: 2012-04-29 18:45:44.0 +
+ Mode: 100664
+ Ino: 5
+ Dev: 1

FAIL: convert5to6: got exit code 1, expected 0

---8--

This took some time for me to debug since I first thought this was
cowbuilders fault, but by comparing my build system to a different one
I discovered the lack of support for nanosecond timestamps because it
still uses ext3.

Recompiling obnam on a newer system with ext4 allows the build to succeed
(after working around #674832).

After looking through the build logs it is apparent most buildds don't support
nanosecond timestamps either.

Grüße,
Sven.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'experimental'), (400, 'testing'), (300, 
'stable')
Architecture: i386 (x86_64)

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

Versions of packages obnam depends on:
ii  libc6 2.13-32
ii  python2.7.2-10
ii  python-cliapp 0.29-1
ii  python-larch  1.20120527-1
ii  python-paramiko   1.7.7.1-2
ii  python-tracing0.6-2
ii  python-ttystatus  0.18-1
ii  python2.6 2.6.7-4
ii  python2.7 2.7.3~rc2-2.1

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information



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

Bug#617763: possible fix... regarding #629207, #629310, #631284, #617763

[Sven Hartge]

Michael Schmitt tcwardr...@gmail.com wrote:

 I had a brief conversation about that issue with a develeoper of compiz 
 on IRC (#compiz@freenode):
 
 14:54:12 maniac103 you can cite: 'A simple recompile of the 
 compiz(-gnome) package should be sufficient to get things in order again'
 
 He could confirm the bug, tried to compile with some debugging 
 statements added and all of a sudden it worked again.
 
 15:05:54 maniac103 TCW: I compile with debug symbols, but it was 
 consistently broken with the old binary and consistently working with 
 the new one
 
 So basically, a fresh re-compile, and all should work again.

I tested this and recompiled compiz in a clean pbuilder chroot with the
latest metacity and everything is fine again.

So a simple BinNMU of compiz should really resolve this problem for now.

And I think compiz-gtk needs a stricter dependency on the exact metacity
version it was compiled with since it uses some internal symbols and has
to stay locked to that specific version.

Grüße,
Sven.




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

Bug#601768: does not configure during upgrade

[Sven Hartge]

Package: isdnutils-base
Version: 1:3.9.20060704+dfsg.2-5
Severity: grave

Hi.

During upgrade and configure, the following happens:

Setting up isdnutils-base (1:3.9.20060704+dfsg.2-5) ...
dpkg: error processing isdnutils-base (--configure):
 subprocess installed post-installation script returned error exit status 30
dpkg: dependency problems prevent configuration of isdnlog:
 isdnlog depends on isdnutils-base (= 1:3.9.20060704+dfsg.2-5); however:
  Package isdnutils-base is not configured yet.
dpkg: error processing isdnlog (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of isdnvboxserver:
 isdnvboxserver depends on isdnutils-base (= 1:3.9.20060704+dfsg.2-5); however:
  Package isdnutils-base is not configured yet.
dpkg: error processing isdnvboxserver (--configure):
 dependency problems - leaving unconfigured
 isdnutils-base
 isdnlog
 isdnvboxserver

This is the same as bug 554537. 

Maybe reopen that old one and merge these two bugs?

Grüße,
Sven.

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

Kernel: Linux 2.6.32.3-221
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages isdnutils-base depends on:
ii  debconf [debconf-2.0] 1.5.36 Debian configuration management sy
ii  libc6 2.11.2-6   Embedded GNU C Library: Shared lib
ii  libncurses5   5.7+20100313-4 shared libraries for terminal hand
ii  lsb-base  3.2-26 Linux Standard Base 3.2 init scrip
ii  makedev   2.3.1-89   creates device files in /dev
ii  udev  164-1  /dev/ and hotplug management daemo

isdnutils-base recommends no packages.

Versions of packages isdnutils-base suggests:
pn  ipppdnone  (no description available)
pn  isdnlog  none  (no description available)
pn  isdnutils-docnone  (no description available)
pn  isdnutils-xtools none  (no description available)
ii  isdnvboxclient   1:3.9.20060704+dfsg.2-5 ISDN utilities - answering machine
pn  isdnvboxserver   none  (no description available)

-- debconf-show failed



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

Bug#594379: haveged: FTBFS: Architecture mismatch on rd. Requires v9|v9a|v9b; requested architecture is sparclite.

[Sven Hartge]

On 17.10.2010 00:20, intrigeri wrote:
 Sven Hartge wrote (13 Sep 2010 23:21:35 GMT) :
 Steve Kostecke said:
 Jakub Wilk said:
 
 haveged failed to build from source on sparc[0]:
 
 haveged only supports x86 and amd64.
 
 This is not completely true. The code should still support SPARC (and
 ia64 and ppc), but the Debian SPARC port has a 32bit (aka sparclite)
 userland (with a 64bit kernel) and haveged wants to use an assembler
 instruction only available in v9 aka 64bit mode:
 
 Some bits of 0.9-3 fix a pretty annoying bug (#565755), so I'd
 really like a fixed package to go into Squeeze.
 
 OTOH, even if breaking it for Sparc while fixing it for three other
 architectures could seem reasonable, we may be able to do better... if
 people with Sparc knowledge speak up.

I revived my SunFire v240, installed an up-to-date Sid on it and tried
to reproduce this bug. But I am no longer able to get the mentioned
error with the current gcc-4.4 from Sid.

haveged compiles, links and runs in both 32bit and 64bit (-m64) mode.
A quick check with the included crypto tests also shows no apparent
error in the resulting binaries.

I believe this bug will vanish if the dependency on gcc-4.3 is removed.
On i386/amd64 haveged will have to get compiled using -O0, because of
the segfault still occurring on these archs.

Grüße,
Sven.



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

Bug#594379: haveged: FTBFS: Architecture mismatch on rd. Requires v9|v9a|v9b; requested architecture is sparclite.

[Sven Hartge]

Steve Kostecke said:
 Jakub Wilk said:

haveged failed to build from source on sparc[0]:

haveged only supports x86 and amd64.

This is not completely true. The code should still support SPARC (and
ia64 and ppc), but the Debian SPARC port has a 32bit (aka sparclite)
userland (with a 64bit kernel) and haveged wants to use an assembler
instruction only available in v9 aka 64bit mode:

#ifdef HAVE_ISA_SPARC
#define ARCH sparc
#define HARDCLOCK(x) ASM(rd %%tick, %0:=r(x):r(x))
#endif

I don't know, if it is possible to compile 64bit userland applications
in Debians SPARC-Port and I am not able to verify this at the present
moment, since my Sun v240 is currently out of order.

Grüße,
Sven.



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

Bug#563427: fails since installation of bash-4.1

[Sven Hartge]

Package: localepurge
Version: 0.6.1
Severity: grave

Hi.

Since the installation of bash-4.1 on my system, localepurge does not work any 
more:

,
| :/root # bash --version
| GNU bash, version 4.1.0(1)-release (i486-pc-linux-gnu)
| Copyright (C) 2009 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
|
| This is free software; you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
|
| :/root # localepurge -d
| + '[' -d = --help ']'
| + '[' -d = -h ']'
| + (( true = 1 ))
| + (( false = 0 ))
|
| :/root #
`

On another system, which has not yet been upgraded to bash-4.1, localepurge 
works as intended:

,
| r...@:~# bash --version
| GNU bash, version 4.0.33(1)-release (i486-pc-linux-gnu)
| Copyright (C) 2009 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
|
| This is free software; you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
| r...@:~# localepurge -d
| + '[' -d = --help ']'
| + '[' -d = -h ']'
| + (( true = 1 ))
| + (( false = 0 ))
| + (( VERBOSE = false ))
| + (( DONTBOTHERNEWLOCALE = false ))
| + (( SHOWFREEDSPACE = false ))
| + (( MANDELETE = false ))
| + (( globaltot = 0 ))
| + fgrep --quiet --line-regexp DONTBOTHERNEWLOCALE /etc/locale.nopurge
| + (( DONTBOTHERNEWLOCALE = true ))
| + fgrep --quiet --line-regexp SHOWFREEDSPACE /etc/locale.nopurge
| + (( SHOWFREEDSPACE = true ))
| + fgrep --quiet --line-regexp MANDELETE /etc/locale.nopurge
| + (( MANDELETE = true ))
| + fgrep --quiet --line-regexp VERBOSE /etc/locale.nopurge
| + '[' -d = -verbose ']'
| + '[' -d = -v ']'
| [ and so on ]
`

Reverting the first system back to bash-4.0 (from testing) resolves the
problem, localepurge works again:

,
| :/root # bash --version
| GNU bash, version 4.0.33(1)-release (i486-pc-linux-gnu)
| Copyright (C) 2009 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
|
| This is free software; you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
|
| :/root # localepurge -d
| + '[' -d = --help ']'
| + '[' -d = -h ']'
| + (( true = 1 ))
| + (( false = 0 ))
| + (( VERBOSE = false ))
| + (( DONTBOTHERNEWLOCALE = false ))
| + (( SHOWFREEDSPACE = false ))
| + (( MANDELETE = false ))
| + (( globaltot = 0 ))
| + fgrep --quiet --line-regexp DONTBOTHERNEWLOCALE /etc/locale.nopurge
| + (( DONTBOTHERNEWLOCALE = true ))
| + fgrep --quiet --line-regexp SHOWFREEDSPACE /etc/locale.nopurge
| + (( SHOWFREEDSPACE = true ))
| + fgrep --quiet --line-regexp MANDELETE /etc/locale.nopurge
| + (( MANDELETE = true ))
| + fgrep --quiet --line-regexp VERBOSE /etc/locale.nopurge
| + '[' -d = -verbose ']'
| + '[' -d = -v ']'
| + '[' '' = -verbose ']'
| + '[' '' = -v ']'
| [ and so on ]
`

Justification for the severity: The bug makes the package in question unusable
by most or all users.

I am not sure, if this is a genuine localepurge bug or a bug in bash-4.1, but
since localepurge is the only package which has been broken on my system, I am
filing the bug against localepurge and not bash.

Grüße,
Sven.

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

Kernel: Linux 2.6.31.6-220
Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii  locales   2.10.2-2   GNU C Library: National Language (
ii  locales-all [locales] 2.10.2-2   GNU C Library: Precompiled locale 
ii  procps1:3.2.8-2  /proc file system utilities
ii  ucf   3.0025 Update Configuration File: preserv

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit none (no description available)
pn  debfoster none (no description available)
ii  deborphan 1.7.28 program that can find unused packa

-- debconf-show failed



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

Bug#554537: postinst failes with exit status 30

[Sven Hartge]

Christian Perrier wrote:

 At first glance, it seems that replacing all db_input foo/bar by
 db_input foo/bar || true (in isdnutils-base.config, for instance)
 could be what makes things work *without* set +e. Untested, though

Some other packages have been bitten by this recently (but I can't
remember the name) and the suggested fix was the same as the one you
suggested.

So I'd say: go ahead, can't become any worse.

Grüße,
Sven.





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

Bug#542810: [Bacula-devel] Sqlite3 and autoincrement

[Sven Hartge]

Kern Sibbald wrote:
 On Monday 24 August 2009 02:17:29 Sven Hartge wrote:
 Kern Sibbald wrote:

 Based on the information you provided below, I have reopened the bug
 report and posted my suggested fix.  Sorry that I missed the fact that
 the Bacula developers added the offending AUTOINCREMENT.  I would
 appreciate a confirmation to the bug report whether or not my suggested
 fix works.
 I will be able to test these fixes this Monday.

 But since I came to the same conclusion WRT sed as you did (see
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542810#10), I am
 positive this should work as intended.

 OK, thanks. Good luck with the testing.

I manually converted a sqlite2 database into a sqlite3 database using
the following command:

sqlite /var/lib/bacula/bacula.db .dump | sed 's/ INTEGER UNSIGNED
AUTOINCREMENT,/ INTEGER,/' | sqlite3 /tmp/bacula-test.db

Then I tested a SQL command like the one bacula would use to insert a
file into the Filename table:

[...]
2303708|1250979390.27316_0.ds9:2,
2303709|1250964997.6658_0.ds9:2,
2303710|1250961605.29727_0.ds9:2,S
2303711|wireshark-common.templates
2303712|wireshark-common.postrm
2303713|wireshark-common.config
sqlite insert into Filename (name) VALUES ('asdfghjkl');
sqlite select * from Filename where name like 'asdfghjkl';
2303714|asdfghjkl

As you can see, it gets added correctly with autoincremented FilenameId.

Grüße,
Sven.



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

Bug#542810: [Bacula-devel] Sqlite3 and autoincrement

[Sven Hartge]

Sven Hartge wrote:
 Kern Sibbald wrote:
 
 Based on the information you provided below, I have reopened the bug report 
 and posted my suggested fix.  Sorry that I missed the fact that the Bacula 
 developers added the offending AUTOINCREMENT.  I would appreciate a 
 confirmation to the bug report whether or not my suggested fix works.
 
 I will be able to test these fixes this Monday.
 
 But since I came to the same conclusion WRT sed as you did (see
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542810#10), I am
 positive this should work as intended.

I can confirm this to be working.

I rolled my own bacula Debian packages based on the ones from John,
incorporated the updates and fixes from this thread, held my breath and
updated my system.

There where some minor, packaging related problems but the sqlite
upgrade went fine and a test backup and restore have shown no problems
or errors so far.

Grüße,
Sven.



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

Bug#542810: [Bacula-devel] Sqlite3 and autoincrement

[Sven Hartge]

Kern Sibbald wrote:

 Based on the information you provided below, I have reopened the bug report 
 and posted my suggested fix.  Sorry that I missed the fact that the Bacula 
 developers added the offending AUTOINCREMENT.  I would appreciate a 
 confirmation to the bug report whether or not my suggested fix works.

I will be able to test these fixes this Monday.

But since I came to the same conclusion WRT sed as you did (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542810#10), I am
positive this should work as intended.

Grüße,
Sven.




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

Bug#542810: update from sqlite2 will fail because of AUTOINCREMENT in table definition

[Sven Hartge]

Package: bacula-director-sqlite3
Version: 3.0.2-1
Severity: serious

Hello.

During the update from a previous sqlite2-base director, the postinst runs the
following command:

sqlite $DB .dump | sqlite3 $DB.sqlite3

This will fail on older installations of bacula-director-sqlite, because the
database may contain table schemas like the following:

CREATE TABLE Filename (
  FilenameId INTEGER UNSIGNED AUTOINCREMENT,
  Name TEXT DEFAULT ,
  PRIMARY KEY(FilenameId) 
  );

Problem is, sqlite3 does not understand AUTOINCREMENT in this way, this keyword
is only allowed alongside a PRIMARY KEY statement. Besides, every integer
primary key will autoincrement without this keyword, as per 
http://sqlite.org/faq.html#q1

I suggest using a statement like this in the postinst of 
bacula-director-sqlite3:

   sqlite $DB .dump | sed 's/ AUTOINCREMENT,/,/' | sqlite3 $DB.sqlite3

This will eliminate the unwanted AUTOINCREMENT and the resulting database dump
will be the same as a newly created bacula sqlite3 database:

CREATE TABLE Filename (
  FilenameId INTEGER UNSIGNED,
  Name TEXT DEFAULT ,
  PRIMARY KEY(FilenameId)
  );


But: testing revealed the FilenameId column will not autoincrement despite it
being the primary key for this table. This sees more like a bug to be
discussed with upstream. From my reading of the source and my tests with
sqlite3, the currect table schema should not be working.

The (to me) correct schema of this table should be:

CREATE TABLE Filename (
  FilenameId INTEGER PRIMARY KEY AUTOINCREMENT,
  Name TEXT DEFAULT ,
  );


So far, I am unsure what to do.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.1-217
Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages bacula-director-sqlite3 depends on:
ii  bacula-director-common2.4.4-1+b1 network backup, recovery and verif
ii  debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libgcc1   1:4.4.1-2  GCC support library
ii  libsqlite3-0  3.6.17-2   SQLite 3 shared library
ii  libstdc++64.4.1-2The GNU Standard C++ Library v3
ii  libwrap0  7.6.q-18   Wietse Venema's TCP wrappers libra
ii  python2.4 2.4.6-2An interactive high-level object-o
ii  sqlite3   3.6.17-2   A command line interface for SQLit

bacula-director-sqlite3 recommends no packages.

bacula-director-sqlite3 suggests no packages.



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

Bug#542810: update from sqlite2 will fail because of AUTOINCREMENT in table definition

[Sven Hartge]

Addendum:

After further experimentation I discovered the following facts.

Given a schema like this, 'x' _will_ autoincrement on insert:

CREATE TABLE t1 ( 
  x INTEGER, 
  name TEXT DEFAULT , 
  PRIMARY KEY(x)
);

Give a schema like this, with added UNSIGNED after INTEGER, 'x' *will 
not* autoincrement on insert:

CREATE TABLE t1 ( 
  x INTEGER UNSIGNED, 
  name TEXT DEFAULT , 
  PRIMARY KEY(x)
);


Considering this discovery, the sqlite - sqlite3 upgrade command should 
be:

   sqlite $DB .dump |\
   sed 's/ INTEGER UNSIGNED AUTOINCREMENT,/ INTEGER,/' |\
   sqlite3 $DB.sqlite3

This should be safe, since the only columns with AUTOINCREMENT added are 
INTEGER and all are also PRIMARY KEYs:

ds9:/var/lib/bacula # sqlite bacula.db .schema  | grep AUTOINCREMENT
   BaseId INTEGER UNSIGNED AUTOINCREMENT,
   ClientId INTEGER UNSIGNED AUTOINCREMENT,
   FileId INTEGER UNSIGNED AUTOINCREMENT,
   FileSetId INTEGER UNSIGNED AUTOINCREMENT,
   FilenameId INTEGER UNSIGNED AUTOINCREMENT,
   PathId INTEGER UNSIGNED AUTOINCREMENT,
   UnsavedId INTEGER UNSIGNED AUTOINCREMENT,

ds9:/var/lib/bacula # sqlite bacula.db .schema  | grep PRIMARY KEY
   PRIMARY KEY(BaseId)
   PRIMARY KEY (MediaId)
   PRIMARY KEY(ClientId)
   PRIMARY KEY (Counter)
   PRIMARY KEY(DeviceId)
   PRIMARY KEY(FileId) 
   PRIMARY KEY(FileSetId)
  PRIMARY KEY(FilenameId) 
   PRIMARY KEY(JobId)
   PRIMARY KEY(JobMediaId) 
   PRIMARY KEY(LocationId)
   PRIMARY KEY(LocLogId)
   PRIMARY KEY(LogId) 
   PRIMARY KEY(MediaId)
   PRIMARY KEY(MediaTypeId)
   PRIMARY KEY (TableName)
   PRIMARY KEY(PathId) 
   PRIMARY KEY (PoolId)
   PRIMARY KEY (JobStatus)
   PRIMARY KEY(StorageId)
   PRIMARY KEY (UnsavedId)



Grüße,
Sven



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

Bug#542810: update from sqlite2 will fail because of AUTOINCREMENT in table definition

[Sven Hartge]

John Goerzen wrote:

 Thanks for the report.  I am initially unsure what to do about it
 either, and have opened an upstream report at the above URL.

http://bugs.bacula.org/view.php?id=1351

Quote from Kern Sibbald:

| Converting from SQLite2 to SQLite3 is easy. You simply export or
| dump the SQLite2 database to an ASCII file (example in the default
| Bacula catalog backup script) then import it using SQLite3 (see
| comments at the bottom of the Bacula catalog backup script)

This is incorrect.

Try to create a table with the following schema in sqlite3:

CREATE TABLE Filename (
  FilenameId INTEGER UNSIGNED AUTOINCREMENT,
  Name TEXT DEFAULT ,
  PRIMARY KEY(FilenameId)
  );

o...@ds9:/home/oweh  sqlite3 /tmp/test-db.db
SQLite version 3.6.17
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite CREATE TABLE Filename (
   ...   FilenameId INTEGER UNSIGNED AUTOINCREMENT,
   ...   Name TEXT DEFAULT ,
   ...   PRIMARY KEY(FilenameId)
   ...   );
SQL error: near AUTOINCREMENT: syntax error
sqlite

Only if I remove the UNSIGNED AUTOINCREMENT the table will be
syntactically correct _and_ behave in the correct and intended way.

Grüße,
Sven.



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

Bug#542810: [Fwd: [bacula 0001351]: SQLite tables lack autoincrement -- also implications for upgrades from SQLite 2]

[Sven Hartge]

John Goerzen wrote:
 
 I am curious, then, where the AUTOINCREMENT came from, and which
 specific older Bacula version you think it may have been in?

I really don't know. But I never manually altered the database.

But, look here:

o...@hild:~/apt/bacula-2.4.4/updatedb$ grep AUTOINCREMENT *
update_sqlite3_tables_8_to_9:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite3_tables_8_to_9:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite3_tables_9_to_10:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5:   PoolId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5:   PoolId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_5_to_6:   FileSetId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_5_to_6:   FileSetId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_5_to_6:   JobMediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_5_to_6:   JobMediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_5_to_6:   BaseId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_6_to_7:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_6_to_7:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_6_to_7:   PoolId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_6_to_7:   PoolId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_6_to_7:   BaseId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_7_to_8:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_7_to_8:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_8_to_9:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_8_to_9:   MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_9_to_10:   MediaId INTEGER UNSIGNED AUTOINCREMENT,

So there _are_ places, where AUTOINCREMENT gets added to the database.

Grüße,
Sven.



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

Bug#520499: lsb-base upgrade breaks init scripts at least of gdm

[Sven Hartge]

Pablo López Martín wrote:

 Its a bug in /lib/lsb/init-functions
 start_daemon function in /lib/lsb/init-functions has a bug in 3.2-21.

 I changed:

 args=--start --chdir '$PWD' --nicelevel $nice --quiet --oknodo

 to:

 args=--start --chdir $PWD --nicelevel $nice --quiet --oknodo

 and it works. Attaching the patch.

Yes, this works, but breaks horribly if there are any whitespace 
characters inside $PWD because you forgot to quote the  inside the 
already -enclosed string.

Untested:

args=--start --chdir \$PWD\ --nicelevel $nice --quiet --oknodo 

Grüße,
Sven.



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

Bug#487761: Re postinst overwrites /etc/imapproxy.conf with empty file

[Sven Hartge]

José Luis Tallón wrote:

 I have produced a fixed version. Please test it so that we can
 double-check before having this uploaded.

Looks fine to me.

Grüße,
Sven.



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

Bug#487761: postinst overwrites /etc/imapproxy.conf with empty file

[Sven Hartge]

Um 10:59 Uhr am 24.06.08 schrieb José Luis Tallón:

 Which PERL version are you using?
 (i.e. what does perl -version say)

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

perl:
  Installed: 5.10.0-11
  Candidate: 5.10.0-11
  Version table:


Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/



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

Bug#487761: Re postinst overwrites /etc/imapproxy.conf with empty file

[Sven Hartge]

Um 03:04 Uhr am 24.06.08 schrieb José Luis Tallón:

 I have been unable to reproduce this bug in my preliminar testing.
 Would you mind giving me some more details ?

 Any additional information you can provide to nail this bug down
 will be wellcome.

Now I tried to install imapproxy on a server which never ever before had 
this package installed, so no leftover files or debconf entries are to be 
found. But:

Setting up imapproxy (1.2.6-3) ...
Can't open imapproxy.conf: No such file or directory at - line 8.
Starting IMAP proxy: /etc/init.d/imapproxy: line 47:  5272 Segmentation fault   
   start-stop-daemon
 --start --quiet --pidfile=$PIDFILE --exec $DAEMON -- $ARGS
invoke-rc.d: initscript imapproxy, action start failed.
dpkg: error processing imapproxy (--configure):
 subprocess post-installation script returned error exit status 139
Errors were encountered while processing:
 imapproxy

And again imapproxy.conf is empty:

[EMAIL PROTECTED]:/etc# ls -al imapproxy.conf 
-rw-r--r-- 1 root root 0 24. Jun 11:41 imapproxy.conf

During installation I get only asked on debconf question about the ip to
listen on (with localhost being the default).

Grüße,
Sven

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/



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

Bug#487761: postinst overwrites /etc/imapproxy.conf with empty file

[Sven Hartge]

Package: imapproxy
Version: 1.2.6-3
Severity: critical

The postinst overwrote my working /etc/imapproxy.conf with an empty file
and thus causes the daemon to fail to start and consequentially all
applications using the proxy.

ds9:/etc # ls -al imapproxy.conf 
-rw-r--r-- 1 root root 4121 Jun 24 00:36 imapproxy.conf
ds9:/etc # dpkg --configure -a
Setting up imapproxy (1.2.6-3) ...
Starting IMAP proxy: /etc/init.d/imapproxy: line 47:  1351 Segmentation fault   
   (core dumped) start-stop-daemon --start --quiet --pidfile=$PIDFILE --exec 
$DAEMON -- $ARGS
invoke-rc.d: initscript imapproxy, action start failed.
dpkg: error processing imapproxy (--configure):
 subprocess post-installation script returned error exit status 139
Errors were encountered while processing:
 imapproxy
ds9:/etc # ls -al imapproxy.conf
-rw-r--r-- 1 root root 0 Jun 24 00:36 imapproxy.conf


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

Kernel: Linux 2.6.25-206
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages imapproxy depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  libc6 2.7-12 GNU C Library: Shared libraries
ii  libncurses5   5.6+20080614-1 Shared libraries for terminal hand
ii  libssl0.9.8   0.9.8g-10.1SSL shared libraries
ii  libwrap0  7.6.q-15   Wietse Venema's TCP wrappers libra
ii  lsb-base  3.2-12 Linux Standard Base 3.2 init scrip

imapproxy recommends no packages.

-- debconf-show failed



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

Bug#487761: Re postinst overwrites /etc/imapproxy.conf with empty file

[Sven Hartge]

Here is a -x version of the postinst.

Setting up imapproxy (1.2.6-3) ...
+ '[' -e /usr/share/debconf/confmodule ']'
+ . /usr/share/debconf/confmodule
++ '[' '!' '' ']'
++ PERL_DL_NONLAZY=1
++ export PERL_DL_NONLAZY
++ '[' '' ']'
++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/imapproxy.postinst 
configure ''
+ '[' -e /usr/share/debconf/confmodule ']'
+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ '[' '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
+ db_version 2.0
+ _db_cmd 'VERSION 2.0'
+ IFS=' '
+ printf '%s\n' 'VERSION 2.0'
+ IFS='
'
+ read -r _db_internal_line
+ RET=2.0
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ set -e
+ DESTFILE=/etc/imapproxy.conf
+ CFGFILE=imapproxy.conf
+ PARAMS='server_hostname proc_username proc_groupname chroot_directory 
listen_port'
+ server_hostname=localhost
+ proc_username=nobody
+ proc_groupname=nogroup
+ chroot_directory=/var/lib/imapproxy/chroot
+ listen_port=143
+ case $1 in
+ '[' -e /usr/share/debconf/confmodule ']'
+ db_get imapproxy/imap-server
+ _db_cmd 'GET imapproxy/imap-server'
+ IFS=' '
+ printf '%s\n' 'GET imapproxy/imap-server'
+ IFS='
'
+ read -r _db_internal_line
+ RET=localhost
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ server_hostname=localhost
+ '[' localhost = localhost ']'
+ listen_port=1143
+ test -f /etc/imapproxy.conf
++ tempfile
+ TMPFILE=/tmp/fileHeEd0K
+ mv /etc/imapproxy.conf /tmp/fileHeEd0K
+ export PARAMS
+ export server_hostname proc_username proc_groupname chroot_directory 
listen_port
+ /usr/bin/perl - /etc/imapproxy.conf imapproxy.conf
+ '[' '!' -f /var/lib/imapproxy/chroot/etc/localtime ']'
+ for p in '$PARAMS' PARAMS
+ export server_hostname=
+ server_hostname=
+ for p in '$PARAMS' PARAMS
+ export proc_username=
+ proc_username=
+ for p in '$PARAMS' PARAMS
+ export proc_groupname=
+ proc_groupname=
+ for p in '$PARAMS' PARAMS
+ export chroot_directory=
+ chroot_directory=
+ for p in '$PARAMS' PARAMS
+ export listen_port=
+ listen_port=
+ for p in '$PARAMS' PARAMS
+ export PARAMS=
+ PARAMS=
+ rm -f /tmp/fileHeEd0K
+ '[' -e /usr/share/debconf/confmodule ']'
+ db_stop
+ echo STOP
+ '[' -x /etc/init.d/imapproxy ']'
+ update-rc.d imapproxy defaults 98
++ which invoke-rc.d
+ '[' -x /usr/sbin/invoke-rc.d ']'
+ invoke-rc.d imapproxy start
Starting IMAP proxy: /etc/init.d/imapproxy: line 47:  3920 Segmentation fault   
   (core dumped) start-stop-daemon --start --quiet --pidfile=$PIDFILE --exec 
$DAEMON -- $ARGS
invoke-rc.d: initscript imapproxy, action start failed.
+ exit 139
dpkg: error processing imapproxy (--configure):
 subprocess post-installation script returned error exit status 139
Errors were encountered while processing:
 imapproxy




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

Bug#470485: fuse-utils fail to configure

[Sven Hartge]

found 470485 2.7.3-2
quit

I'm sorry, but the bug is still there:

E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up fuse-utils (2.7.3-2) ...
creating fuse group...
udev active, devices will be created in /dev/.static/dev/
chgrp: cannot access `/dev/fuse': No such file or directory
dpkg: error processing fuse-utils (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 fuse-utils

This code is still wrong:

  if grep -qE '^udev /dev' /proc/mounts; then
udev=1
  elif [ -d /dev/.udevdb/ -o -d /dev/.udev/ ]; then
udev=0
  fi


It should read udev=1 in the elif clause.

Why don't you simplify the test and just use the following?

if [ -d /dev/.udev/ ]; then
# Udev is active, nothing to do.
echo udev active, skipping device node creation.
else
# Call makedev and fix perms
cd /dev; MAKEDEV fuse
chgrp fuse /dev/fuse
fi

As far as I know, /dev/.udev is guaranteed to be present while udev is 
active. No need to grep /proc/mounts or anything else.

Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Bug#448253: azureus: uninstallable in Sid, missing libswt-gtk-3.3-java

[Sven Hartge]

Package: azureus
Version: 3.0.3.4-1
Severity: grave
Justification: renders package unusable

Azureus is uninstallable in Sid:

azureus: Depends: libswt-gtk-3.3-java which is a virtual package.

This also causes an additional FTBFS bug.

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

Kernel: Linux 2.6.23.1-302 (PREEMPT)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash



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

Bug#397691: librrd2 memory leak in 1.2.15

[Sven Hartge]

Um 00:36 Uhr am 27.11.06 schrieb Josip Rodin:
 On Thu, Nov 16, 2006 at 03:48:40PM +0100, Sven Hartge wrote:

 Can you perhaps provide a configuration (and by that I mean the 
 RRD::graph invocation) and a .rrd data file that makes librrd2 
 explode?

  If you want, I can privately provide a tar of /var/lib/munin and 
 /etc/munin.
 
 Okay, send it over to my address. How large is it?

About 7.5MB as gzipped tar, 58M uncompressed.

S°

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Bug#397691: causes munin-graph to consume all memory

[Sven Hartge]

Package: librrds-perl
Version: 1.2.15-0.1
Severity: critical

Since the upgrade from 1.2.11-0.6 to 1.2.15-0.1 munin-graph consumes
all memory and swap on my system, causing the system to be unusable
until the OOM killer fires and hopefully kills the offending processes.

Since munin-graph is run every 5 minutes, the whole system is in a
constant state of trashing and recovering again, which justifies the
severity.

Reverting to 1.2.11-0.6 fixes the problem, munin-graph is back to normal
behavior.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-cks1-198
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages librrds-perl depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  librrd2  1.2.15-0.1  Time-series data storage and displ
ii  perl 5.8.8-6.1   Larry Wall's Practical Extraction 
ii  perl-base [perlapi-5.8.8]5.8.8-6.1   The Pathologically Eclectic Rubbis

librrds-perl recommends no packages.

-- debconf-show failed


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

Bug#385012: init-script does not work if /usr is on a different filesystem

[Sven Hartge]

Um 21:32 Uhr am 12.09.06 schrieb Craig Small:
 On Tue, Aug 29, 2006 at 04:13:48PM +0200, Bas Zoetekouw wrote:

 That's not correct.  Although /usr/bin/which exists, it's a symlink to
 /bin/which, which _is_ available when /etc/init.d/procps is run

 As is mine:
 ls -l /usr/bin/which
 lrwxrwxrwx 1 root root 10 2006-07-24 16:42 /usr/bin/which - /bin/which
 
 It appears in debianutils, mine is 2.16.2
 
 We really need some more information about why this fails.

It was really my fault, a combination of a procps backport to Sarge (where 
which is in /usr/bin) and a to quick and wrong investigation fonr by me.

So to make this clear: There is _NO_ bug in the Sid procps package, just 
in the backported one, which needs a different init-script which does not 
rely on which, because in Sarge which is not available at the time the 
init script is run.

I already closed the bug as soon as I realized my error.

Sorry for the noise and trouble.

S°

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Bug#385012: init-script does not work if /usr is on a different filesystem

[Sven Hartge]

Bas Zoetekouw wrote:

 That's not correct.  Although /usr/bin/which exists, it's a symlink to
 /bin/which, which _is_ available when /etc/init.d/procps is run

Yes, correct. This bug is totally bogus (and totally my fault for not
researching correctly), because this only exists if using a backported
package to Sarge (where which is only in /usr/bin).

I am very sorry for the noise I made, I will take my business with this
problem back to the backports.org mailinglist.

Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Achtung, neue Mail-Adresse: [EMAIL PROTECTED]


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

Bug#385012: init-script does not work if /usr is on a different filesystem

[Sven Hartge]

Package: procps
Version: 1:3.2.7-1
Severity: serious

/etc/init.d/procps is using which (located at /usr/bin/which) at a
time where /usr is not mounted.

This causes the init-script to fail and leaves /etc/sysctl.conf
unprocessed.

The severity is justified by the fact that /etc/sysctl.conf is the
preferred way to set networking parameters (like forwarding etc.) in Etch,
which breaks if one is using this version of procps.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-cks1-198
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages procps depends on:
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii  libncurses5  5.5-2   Shared libraries for terminal hand

Versions of packages procps recommends:
ii  psmisc22.3-1 Utilities that use the proc filesy

-- debconf-show failed


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

Bug#379859: rxvt-unicode: depends on libgcc1 (= 1:4.2-20060707) from experimental, uninstallable in Sid

[Sven Hartge]

Package: rxvt-unicode
Version: 7.8-1
Severity: grave
Justification: renders package unusable

The package is build with gcc4.2 from experimental and thus depends on
libgcc1 from experimental which causes it to be uninstallable in Sid:

 rxvt-unicode: Depends: libgcc1 (= 1:4.2-20060707) but 1:4.1.1-9 is  installed.


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

Bug#373856: python2.4-minimal: Install/Upgrade fails: TypeError: unindexable object

[Sven Hartge]

Package: python2.4-minimal
Version: 2.4.3-7
Severity: grave
Justification: renders package unusable

During configuration the following happens:

Setting up python2.4-minimal (2.4.3-7) ...
Traceback (most recent call last):
  File /usr/bin/pycentral, line 1365, in ?
main()
  File /usr/bin/pycentral, line 1359, in main
rv = action.run(global_options)
  File /usr/bin/pycentral, line 892, in run
pkg.set_default_runtime_from_version_info()
  File /usr/bin/pycentral, line 575, in set_default_runtime_from_version_info
self.default_runtime = get_runtime_for_version(versions[0])
TypeError: unindexable object
dpkg: error processing python2.4-minimal (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of python2.4:
 python2.4 depends on python2.4-minimal (= 2.4.3-7); however:
  Package python2.4-minimal is not configured yet.
dpkg: error processing python2.4 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python2.4-minimal
 python2.4


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-beyond4-272
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages python2.4-minimal depends on:
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
ii  python-central0.4.16 register and build utility for Pyt
ii  zlib1g1:1.2.3-11 compression library - runtime

python2.4-minimal recommends no packages.

-- no debconf information


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

Bug#373676: python-imaging: Error in configure: __main__.PyCentralError: package has no field Python-Version

[Sven Hartge]

Package: python-imaging
Version: 1.1.5-8
Severity: grave
Justification: renders package unusable

During setup of python-imaging the following happens:

Setting up python-imaging (1.1.5-8) ...
Traceback (most recent call last):
  File /usr/bin/pycentral, line 1314, in ?
main()
  File /usr/bin/pycentral, line 1308, in main
rv = action.run(global_options)
  File /usr/bin/pycentral, line 858, in run
pkg.read_version_info()
  File /usr/bin/pycentral, line 551, in read_version_info
raise PyCentralError, package has no field Python-Version
__main__.PyCentralError: package has no field Python-Version
dpkg: error processing python-imaging (--configure):
 subprocess post-installation script returned error exit status 1


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-beyond4-272
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages python-imaging depends on:
ii  mime-support  3.36-1 MIME files 'mime.types'  'mailcap
ii  python-central0.4.15 register and build utility for Pyt

python-imaging recommends no packages.

-- no debconf information


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

Bug#366896: closed by José Luis Tallón [EMAIL PROTECTED] (Couriergraph 0.25 solves this bug)

[Sven Hartge]

Um 05:48 Uhr am 18.05.06 schrieb Debian Bug Tracking System:

 The versioned depends was on purpose.

Why? To break the package? 

The version in question should have _never_ been uploaded to unstable.
Why did you intentionally upload a *broken* version to unstable?

What purpose does such a package have other than hosing with everyones 
system?

IMHO unstable does *not* mean Place To Dump Broken Crap.

Grüße,
Sven.

Bug#366896: Uninstallable in Unstable due to broken versioned dependency on librrds-perl

[Sven Hartge]

Package: couriergraph
Version: 0.24-2
Severity: grave

The recent upload to unstable declares a versioned dependency on
librrds-perl (= 1.1) which cannot be satisfied in Sid (or Etch=.

The changelog for this version lists

  * Incompatibility with rrdtool1.2 has to wait until next version

but your upload just made everything worse, now the package is broken in
multiple ways and doesn't even install.

I don't think depending on an unavailable version of a package as fix
is the right thing to do and I am not able to understand in what way
your upload was meant to fix anything.


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

Bug#362049: libxfixes3: XFixesSetCursorName (no such operation)

[Sven Hartge]

Hi.

I don't think this to be a bug of gtk-engines-industrial, because the same 
error occurs, if you for example use the whiteglass theme, which is a 
part of xlibs-data.

The original submitter fixed this by removing gtk-engines-industrial, 
because then the same thing happens as with my changes to the gconf-tree: 
Gnome falls back to the default builtin cursor theme, which works without 
problems.

So to me this indeed looks like a bug somewhere inside X.

Grüße,
S°

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Achtung, neue Mail-Adresse: [EMAIL PROTECTED]

Bug#362049: libxfixes3: XFixesSetCursorName (no such operation)

[Sven Hartge]

Hello.

If you are a Gnome user, you can try this workaround:

Open your ~/.gconf/%gconf-tree.xml and locate the following entry:

  entry name=cursor_theme mtime=1144799098 type=string
 stringvalueX/stringvalue
  /entry

Most users will have Industrial in there. Just change it to something 
else, like shown above.

If you still use the split XML tree, the entry is inside
~/.gconf/desktop/gnome/peripherals/mouse/%gconf.xml

This change reverts your cursor style to the plain old X11 one, but stops 
the constant errors. At least for me, so far.

Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Achtung, neue Mail-Adresse: [EMAIL PROTECTED]

Bug#362049: libxfixes3: XFixesSetCursorName (no such operation)

[Sven Hartge]

Um 02:23 Uhr am 12.04.06 schrieb Sven Hartge:

 Open your ~/.gconf/%gconf-tree.xml and locate the following entry:
 
   entry name=cursor_theme mtime=1144799098 type=string
  stringvalueX/stringvalue
   /entry
 
 Most users will have Industrial in there. Just change it to something 
 else, like shown above.

Using gconftool is easier and works at once, no need to logout and login 
again.

gconftool-2 -s /desktop/gnome/peripherals/mouse/cursor_theme -t string X

Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Achtung, neue Mail-Adresse: [EMAIL PROTECTED]

Bug#354771: avahi-daemon: missing dependency on libavahi-core3

[Sven Hartge]

Package: avahi-daemon
Version: 0.6.8-1
Severity: grave
Justification: renders package unusable


avahi-daemon links to libavahi-core.so.4 from libavahi-core3, but does
not depend on it, thus causing the daemon to fail.

[EMAIL PROTECTED]:~$ ldd /usr/sbin/avahi-daemon
linux-gate.so.1 =  (0xe000)
libavahi-common.so.3 = /usr/lib/libavahi-common.so.3 (0xa7f92000)
libavahi-core.so.4 = not found
libdaemon.so.0 = /usr/lib/libdaemon.so.0 (0xa7f8b000)
libexpat.so.1 = /usr/lib/libexpat.so.1 (0x420b1000)
libcap.so.1 = /lib/libcap.so.1 (0xa7f87000)
libdbus-1.so.2 = /usr/lib/libdbus-1.so.2 (0xa7f57000)
libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xa7f53000)
libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xa7e1b000)
libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xa7e07000)
libnsl.so.1 = /lib/tls/i686/cmov/libnsl.so.1 (0xa7df1000)
/lib/ld-linux.so.2 (0xa7fbd000)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-ck3-263
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages avahi-daemon depends on:
ii  adduser   3.84   Add and remove users and groups
ii  dbus  0.61-2 simple interprocess messaging syst
ii  libavahi-common3  0.6.8-1Avahi common library
ii  libc6 2.3.6-2GNU C Library: Shared libraries an
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libdaemon00.10-1 lightweight C library for daemons
ii  libdbus-1-2   0.61-2 simple interprocess messaging syst
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li

Versions of packages avahi-daemon recommends:
ii  libnss-mdns   0.7-1  NSS module for Multicast DNS name 

-- no debconf information


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

Bug#303057: slapd goes into endless sched_yield() loop

[Sven Hartge]

Um 02:29 Uhr am 16.04.05 schrieb Steve Langasek:

 #txn_checkpoint 128 15  1
 set_cachesize   0   2524288000
 set_lk_max_objects  10
 set_lk_max_locks10
 #
 set_lk_max_lockers  10
 #
 set_lg_regionmax1048576
 set_lg_max  8388608
 set_lg_bsize2097152
 set_lg_dir  /var/lib/ldap/logs/
 #set_lk_detect DB_LOCK_DEFAULT
 set_tmp_dir /tmp/
 #set_flags DB_TXN_NOSYNC
 #set_flags DB_TXN_NOT_DURABLE
 
 Note the enormous amount of possible locks, lockers and lockable objects. 
 So far, only increasing this amount seems to be the way to circumvent the 
 dreaded sched_yield()-loop.

 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2030;selectid=2030;usearchives=1
 (Note how old this bug report to the OpenLDAP ITS is.)
 
 The last follow-up in that ITS points to 
 http://www.sleepycat.com/docs/ref/lock/max.html, which gives 
 guidelines about how to tune the number of available locks and lockers.  
 Is this what you did?

Correct. But since I desperately needed the databases (after all, this are 
my production LDAP servers), I upped the number to this very high value, 
so they would hold up in an case, without me manualle rebuilding the 
database every 6 to 12 hours.

I am about to lower this to 1, since 10 is just to high for my 
workload, consuming to much memory.

 Has the database held up under stress after making these changes?

Yes, after the changes, I experienced no more lookups or database 
corruptions.
 
 I'm not sure how useful it is to set a fixed number of lockers by 
 default, since the optimal value depends on usage statistics; but 
 bumping from 1000 to 5000 doesn't seem like it can hurt much.

1000 seems to low in most cases, at least my experience show this.

But: I still consider it a grave bug for db4.2, if running out of lockers 
corrupts the database. And I consider it a bug in slapd, if it runs into a 
busy-waiting loop, if something inside the database went wrong.

Grüße,
Sven.

-- 
Sven Hartge -- professioneller Unix-Geek und alltime Nerd
Meine Gedanken im Netz: http://sven.formvision.de/blog/

Bug#303057: slapd goes into endless sched_yield() loop

[Sven Hartge]

Um 23:56 Uhr am 11.04.05 schrieb Sven Hartge:

[Sorry for spamming this bug report, but I _really_ need to get this going 
*fast*.]

 My last change is
 
   set_lk_max_lockers  10
 
 which was still default and seems to be to _real_ culprit, as per 
 ITS#2030:
 
 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2030;selectid=2030;usearchives=1
 (Note how old this bug report to the OpenLDAP ITS is.)

After torturing my setup with different scripts and trying to to rebuild 
the normal workload, I am confident, after having run

  watch -n1 -d db4.2_stat -c

for some time in parallel, the sched_yield() loop occurs, because the 
bdb-backend runs out of lockers. At least this is what I get from ITS#2030 
and from various other resources (mostly documentation from Sleepycat).

So I suggest for the package to create a DB_CONFIG with _at least_ 5000 
lockers, locks and lock objects. The default of 1000 is just to low and 
will get exploitet in no time by even a little database.

(Don't close this bug yet, further observation has to happen.)

Grüße,
Sven.


-- 
Sven Hartge -- professioneller Unix-Geek und alltime Nerd
Meine Gedanken im Netz: http://sven.formvision.de/blog/

Bug#296079: conflict: /etc/ipsec.conf already used by openswan

[Sven Hartge]

Package: ipsec-tools
Version: 1:0.5-2
Severity: grave
Justification: renders package unusable


Unpacking replacement ipsec-tools ...
dpkg: error processing
/var/cache/apt/archives/ipsec-tools_1%3a0.5-2_i386.deb (--unpack):
 trying to overwrite `/etc/ipsec.conf', which is also in package  openswan

Since openswan depends on ipsec-tools, this problem renders the
combination of ipsec-tools and openswan uninstallable.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-deb-25
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages ipsec-tools depends on:
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libreadline55.0-10   GNU readline and history libraries

-- no debconf information


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