Bug#1037289: reportbug: EMAIL environment variable does not work

2023-06-11 Thread Stephane Bortzmeyer
On Sun, Jun 11, 2023 at 01:44:57AM -0400,
 Sandro Tosi  wrote 
 a message of 31 lines which said:

> your reportbug configuration file contains the address
> steph...@sources.org, which reportbug diligently uses. If you want to
> have use a different email address, either remove that config line or
> update it.
> 
> Working as intended, closing.

It does not seem that the man page explains that --email on the
command-line overrides ~/.reportbugrc but environment variables do
not.

May be a word about these priorities, somewhere?



Bug#1037289: reportbug: EMAIL environment variable does not work

2023-06-10 Thread Stephane Bortzmeyer
Package: reportbug
Version: 12.0.0
Severity: minor

Dear Maintainer,

The man page says "REPORTBUGEMAIL, DEBEMAIL, EMAIL
  Email address to use as your from address (in this order). If no 
environment variable exists, the default is taken
  from your user name and /etc/mailname." but EMAIL does
not work:

% env |grep MAIL
EMAIL=steph...@bortzmeyer.org

% reportbug whois
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Stephane Bortzmeyer ' as your from address.


--email on the command-line does work.

-- Package-specific info:
** Environment settings:
EDITOR="emacs"
PAGER="more"
INTERFACE="text"

** /home/stephane/.reportbugrc:
reportbug_version "7.6.0"
mode standard
ui text
email "steph...@sources.org"

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.96 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt2.6.0
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.82
pn  debsums 
pn  dlocate 
ii  emacs-bin-common1:28.2+1-15
ii  file1:5.44-3
ii  gnupg   2.2.40-1.1
ii  postfix [mail-transport-agent]  3.7.5-2
pn  python3-urwid   
pn  reportbug-gtk   
pn  xdg-utils   

Versions of packages python3-reportbug depends on:
ii  apt2.6.0
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information



Bug#1037288: whois: .ga now has a whois server

2023-06-10 Thread Stephane Bortzmeyer
Package: whois
Version: 5.5.17
Severity: minor

Dear Maintainer,

% whois nic.ga
This TLD has no whois server, but you can access the whois database at
http://www.my.ga/en/whois.html

There is now one (since 4 june):

% whois -h whois.nic.ga nic.ga

Domain ID: DOM4931-GA
Nom de domaine:nic.ga
Date de création:  2023-06-05T00:00:00Z
Date d'expiration: 2024-06-05T00:00:00Z
Registrar: Registry Operations
Statut:actif

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.96 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages whois depends on:
ii  libc6  2.36-9
ii  libcrypt1  1:4.4.33-2
ii  libidn2-0  2.3.3-1+b1

whois recommends no packages.

whois suggests no packages.

-- no debconf information


Bug#1023280: Info received ([Pkg-nagios-devel] Bug#1023280: monitoring-plugins-basic: check_disk always segfaults)

2022-11-23 Thread Stephane Bortzmeyer
On Thu, Nov 03, 2022 at 05:51:08PM +,
 Debian Bug Tracking System  wrote 
 a message of 22 lines which said:

> Your message has been sent to the package maintainer(s):
>  Debian Nagios Maintainer Group 

Compiling the future 2.3.2-2 from its git repository indeed solved the
problem.



Bug#1023280: [Pkg-nagios-devel] Bug#1023280: monitoring-plugins-basic: check_disk always segfaults

2022-11-03 Thread Stephane Bortzmeyer
On Thu, Nov 03, 2022 at 10:46:29AM +0100,
 Jan Wagner  wrote 
 a message of 21 lines which said:

> I'm unable to reproduce this on bullseye/amd64

As you've seen, it's on ARM so it may be ARM-specific.



Bug#1023280: monitoring-plugins-basic: check_disk always segfaults

2022-11-01 Thread Stephane Bortzmeyer
Package: monitoring-plugins-basic
Version: 2.3.2-1
Severity: important

Dear Maintainer,

% /usr/lib/nagios/plugins/check_disk -w 10 -c 5
zsh: segmentation fault  /usr/lib/nagios/plugins/check_disk -w 10 -c 5

With strace:

% strace /usr/lib/nagios/plugins/check_disk -w 10 -c 5 
execve("/usr/lib/nagios/plugins/check_disk", 
["/usr/lib/nagios/plugins/check_di"..., "-w", "10", "-c", "5"], 0xbead77b0 /* 
52 vars */) = 0
brk(NULL)   = 0x1c1f000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40094000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=54650, ...}) = 0
mmap2(NULL, 54650, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40096000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0i\344\1\0004\0\0\0"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0755, stx_size=1123124, ...}) = 0
mmap2(NULL, 1287060, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400a8000
mmap2(0x400b, 1221524, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x400b
munmap(0x400a8000, 32768)   = 0
munmap(0x401db000, 29588)   = 0
mprotect(0x401ba000, 81920, PROT_NONE)  = 0
mmap2(0x401ce000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10e000) = 0x401ce000
mmap2(0x401d1000, 37780, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401d1000
close(3)= 0
set_tls(0x400952e0) = 0
set_tid_address(0x40094e48) = 751
set_robust_list(0x40094e4c, 12) = 0
rseq(0x400952c0, 0x20, 0, 0xe7f5def3)   = -1 ENOSYS (Function not implemented)
mprotect(0x401ce000, 8192, PROT_READ)   = 0
mprotect(0x43f000, 4096, PROT_READ) = 0
mprotect(0x400a6000, 4096, PROT_READ)   = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
munmap(0x40096000, 54650)   = 0
getrandom("\x66\xa6\x04\xbb", 4, GRND_NONBLOCK) = 4
brk(NULL)   = 0x1c1f000
brk(0x1c4)  = 0x1c4
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=3709744, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401db000
mmap2(NULL, 2592768, PROT_READ, MAP_PRIVATE, 3, 0x6f000) = 0x403db000
mmap2(NULL, 8192, PROT_READ, MAP_PRIVATE, 3, 0x338000) = 0x40096000
close(3)= 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=2996, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)   = 0
close(3)= 0
openat(AT_FDCWD, "/usr/lib/locale/en_GB.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_GB.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_GB/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
openat(AT_FDCWD, "/etc/mtab", O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0
read(3, "/dev/sda1 / ext4 rw,relatime 0 0"..., 1024) = 1024
read(3, "x=1024 0 0\ndevpts /dev/lxc/tty3 "..., 1024) = 639
read(3, "", 1024)   = 0
close(3)= 0
statx(AT_FDCWD, "/", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, 
stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
uname({sysname="Linux", nodename="jadis", ...}) = 0
statfs64("/", 88, 0xbee04308)   = 0
--- SIGSEGV 

Bug#1021110: whois.nic.fr is NOT a RIPE server

2022-10-10 Thread Stephane Bortzmeyer
On Mon, Oct 03, 2022 at 04:00:26PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 12 lines which said:

> > Maybe AFNIC could accept again the parameter for a few years while we 
> > wait for this change to percolate to the whole Linux world?
> 
> Yes. Awaiting deployment.

Done so the whois client works again (but, still, I let the bug open
because the server actually does not handle options).



Bug#1021110: whois.nic.fr is NOT a RIPE server

2022-10-03 Thread Stephane Bortzmeyer
On Sun, Oct 02, 2022 at 12:28:28PM +0200,
 Marco d'Itri  wrote 
 a message of 33 lines which said:

> Maybe AFNIC could accept again the parameter for a few years while we 
> wait for this change to percolate to the whole Linux world?

Yes. Awaiting deployment.

PS : whois -h whois.nic.fr. (dot at the end) works. It's great as a
workaround but it seems to indicate that the matching of names to the
list of RIPE-compatible servers is imperfect.



Bug#1021110: whois.nic.fr is NOT a RIPE server

2022-10-02 Thread Stephane Bortzmeyer
Package: whois
Version: 5.5.13
Severity: important
Tags: patch upstream

"whois bortzmeyer.fr" yields NOT_FOUND (but the domain exists). This
is because whois, wrongly, adds a "-V Md5.5.13" at the beginning of
the query, that the server does not understand. The root cause is that
whois.nic.fr is not a RIPE server.

--- data.h~ 2020-01-23 10:08:31.0 +0100
+++ data.h  2022-10-02 10:38:57.599839912 +0200
@@ -9,7 +9,6 @@
 "whois.apnic.net",
 "whois.afrinic.net",
 "rr.arin.net", /* does not accept the old syntax */
-"whois.nic.fr",
 "rr.level3.net",   /* 3.0.0a13 */
 "rr.ntt.net",
 "whois.tcinet.ru",


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.292 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages whois depends on:
ii  libc6  2.33-7
ii  libcrypt1  1:4.4.28-1
ii  libidn2-0  2.3.2-2

whois recommends no packages.

whois suggests no packages.

-- no debconf information



Bug#1008650: python3-unbound: Cannot install because of Python dependencies

2022-03-30 Thread Stephane Bortzmeyer
Package: python3-unbound
Version: 1.13.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

% sudo apt install python3-unbound
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-unbound : Depends: python3 (< 3.10) but 3.10.4-1 is to be installed
E: Unable to correct problems, you have held broken packages.

Indeed, Python version on sid is:

% python3 --version
Python 3.10.4

But:

% apt-cache show python3-unbound
Package: python3-unbound
Source: unbound
Version: 1.13.1-1
Installed-Size: 394
Maintainer: unbound packagers 
Architecture: armhf
Depends: python3 (<< 3.10), python3 (>= 3.9~), python3:any, libc6 (>= 2.28), 
libunbound8 (>= 1.9.0)
...

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.269 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-unbound depends on:
ii  libc62.33-7
ii  libunbound8  1.13.1-1
ii  python3  3.10.4-1

python3-unbound recommends no packages.

python3-unbound suggests no packages.



Bug#994040: "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI

2021-09-10 Thread Stephane Bortzmeyer
Package: libapache2-mod-wsgi-py3
Version: 4.7.1-3+b1
Severity: normal

Dear Maintainer,

Since upgrading to bullseye, a WSGI script which imports psycopg2
fails sometimes (randomly?) with:

[Sun Aug 29 17:54:07.215719 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] mod_wsgi (pid=7705): Exception occurred processing WSGI script 
'/var/www/wsgis-bortzmeyer/ni.py'.
[Sun Aug 29 17:54:07.215893 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] Traceback (most recent call last):
[Sun Aug 29 17:54:07.215967 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774]   File "/var/www/wsgis-bortzmeyer/ni.py", line 11, in 
[Sun Aug 29 17:54:07.216000 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] import psycopg2
[Sun Aug 29 17:54:07.216026 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774]   File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", 
line 51, in 
[Sun Aug 29 17:54:07.216051 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] from psycopg2._psycopg import ( # noqa
[Sun Aug 29 17:54:07.216087 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] SystemError: initialization of _psycopg raised unreported 
exception

psycopg2 on the same machine always work when ran outside of WSGI.

Setting WSGIApplicationGroup %{GLOBAL} in the configuration cures the
problem.

I checked that there is only one Python (the Debian package) on the
machine.

A similar case is reported in 
.

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

Kernel: Linux 5.13.4-x86_64-linode146 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-wsgi-py3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.48-3.1+deb11u1
ii  libc6   2.31-13
ii  libpython3.93.9.2-1
ii  python3 3.9.2-3

libapache2-mod-wsgi-py3 recommends no packages.

libapache2-mod-wsgi-py3 suggests no packages.

-- no debconf information



Bug#988512: CAcert still distributes the old certificate

2021-06-01 Thread Stephane Bortzmeyer
Unfortunately, on the "Root Certificate" page of the CAcert website
, it is still the old and
expired certificate which is distributed.

The new one is only found at .



Bug#985259: urlview: Add support for Gemini URLs

2021-03-15 Thread Stephane Bortzmeyer
Package: urlview
Version: 0.9-21
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

Gemini is a system to access information on the Internet. A competitor of the
Web for some use cases. It is described at https://gemini.circumlunar.space/
Gemini uses URLs.

The patch in the configuration files allow urlview to access Gemini URLs. At
the present time, there is in sid only one Gemini client, the Emacs mode
Elpher. In the mean time, I added two common clients in the configuration file.
I assume that the integration of my patch will have to wait for these clients
to be packaged?



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

Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages urlview depends on:
ii  libc6   2.28-10
ii  libncurses6 6.1+20181013-2+deb10u2
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  sensible-utils  0.0.12

Versions of packages urlview recommends:
ii  firefox-esr [www-browser]  78.7.0esr-1~deb10u1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  w3m [www-browser]  0.5.3-37

Versions of packages urlview suggests:
ii  mutt   1.10.1-2.1+deb10u5
ii  ncftp  2:3.2.5-2.1
ii  wget   1.20.1-1.1

-- Configuration Files:
/etc/urlview/system.urlview changed:
REGEXP (((http|https|ftp|gopher|gemini)|mailto):(//)?[^ 
<>"\t]*|(www|ftp)[0-9]?\.[-a-z0-9.]+)[^ .,;\t\n\r<">\):]?[^, <>"\t]*[^ 
.,;\t\n\r<">\):]
COMMAND /etc/urlview/url_handler.sh

/etc/urlview/url_handler.sh changed:
http_prgs="/usr/bin/sensible-browser:PW /usr/bin/sensible-browser:XT 
/usr/bin/galeon:PW /usr/bin/konqueror:PW /usr/bin/mozilla:PW /usr/bin/lynx:XT 
/usr/bin/w3m:XT /usr/bin/links:XT"
https_prgs=$http_prgs
mailto_prgs="/usr/bin/mutt:VT /usr/bin/elm:VT /usr/bin/alpine:VT 
/usr/bin/pine:VT /usr/bin/mail:VT"
gopher_prgs="/usr/bin/gopher:XT /usr/bin/lynx:XT"
gemini_prgs="/usr/local/bin/lagrange:XW /usr/bin/amfora:XT"
ftp_prgs="/usr/bin/ncftp:XT /usr/bin/lftp:XT $http_prgs"
file_prgs="/usr/bin/wget:XT /usr/bin/snarf:XT"
XTERM=/usr/bin/x-terminal-emulator
function getprg()
{
local ele tag prog
for ele in $*
do
tag=${ele##*:}
prog=${ele%%:*}
if [ -x $prog ]; then
case $tag in
PW) [ -n "$DISPLAY" ] && echo "P:$prog" && return 0
;;
XW)
[ -n "$DISPLAY" ] && echo "X:$prog" && return 0
;;
XT)
[ -n "$DISPLAY" ] && [ -x "$XTERM" ] && \
echo "X:$XTERM -e $prog" && return 0
echo "$prog" && return 0
;;
VT)
echo "$prog" && return 0
;;
esac
fi
done
}
url=$1; shift
type=${url%%:*}
if [ "$url" = "$type" ]; then
type=${url%%.*}
case $type in
www|web|www[1-9])
type=http
;;
esac
url=$type://$url
fi
if [ "$type" = "ftp" ]; then
filename=${url##*/}
if [ $filename ]; then
echo "Is \"$filename\" a file? (y/N)";
read x
case $x in 
y|Y)
type=file
;;
*)
;;
esac
fi
fi
case $type in
https)
prg=`getprg $https_prgs`
;;
http)
prg=`getprg $http_prgs`
;;
ftp)
prg=`getprg $ftp_prgs`
;;
mailto)
prg=`getprg $mailto_prgs`
;;
gopher)
prg=`getprg $gopher_prgs`
;;
gemini)
prg=`getprg $gemini_prgs`
;;
file)
prg=`getprg $file_prgs`
;;
*)
echo "Unknown URL type.  Please report URL and viewer to"
echo "urlv...@packages.debian.org."
echo -n "Press enter to continue.."; read x
exit
;;
esac
if [ -n "$prg" ]; then
   if [ "${prg%:*}" = "P" ]; then
nohup ${prg#*:} $url 2>/dev/null 1>/dev/null &
   elif [ "${prg%:*}" = "X" ]; then
${prg#*:} $url 2>/dev/null &
   else
$prg $url
   fi
fi


-- no debconf information



Bug#960701: [Pkg-nagios-devel] Bug#960701: php-icinga: Uncaught ErrorException \Icinga\Web\ViewStream::stream_set_option is not implemented!

2020-05-16 Thread Stephane Bortzmeyer
On Fri, May 15, 2020 at 06:44:56PM +0200,
 Sebastiaan Couwenberg  wrote 
 a message of 16 lines which said:

> icingaweb2 (2.8.0~rc1-1~exp1) works fine on my unstable test VM.

Tested and it works. So, the sid version is broken but the
experimental one works. Thanks.

> You need icingaweb 2.8.0 from experimental for php7.4 support, and you
> need to upgrade all icingaweb2 packages from experimental, not only
> php-icinga.

Fair enough. But may be php-icinga should depend on icingaweb2 >= 2.8
in that case, no?



Bug#960701: php-icinga: Uncaught ErrorException \Icinga\Web\ViewStream::stream_set_option is not implemented!

2020-05-15 Thread Stephane Bortzmeyer
Package: php-icinga
Version: 2.7.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

I had a working Icinga Web setup. nginx as a frontend, redirecting to
Icinga:

location ~ ^/icingaweb2/index\.php(.*)$ {
fastcgi_pass unix:/var/run/php/php-fpm.sock;
  fastcgi_index index.php;
include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME /usr/share/icingaweb2/public/index.php;
fastcgi_param ICINGAWEB_CONFIGDIR /etc/icingaweb2;
  fastcgi_param REMOTE_USER $remote_user;
  }

location ~ ^/icingaweb2(.+)? {
  alias /usr/share/icingaweb2/public;
index index.php;
  try_files $1 $uri $uri/ /icingaweb2/index.php$is_args$args;
  }
}


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I just upgraded my "sid" machine. Trying to access the Icinga Web page
of my installation no longer works.

   * What was the outcome of this action?

In the browser (Firefox), just this message:

Fatal error: Uncaught ErrorException: Uncaught ErrorException: include(): 
\Icinga\Web\ViewStream::stream_set_option is not implemented! in 
/usr/share/php/Icinga/Web/View.php:262 Stack trace: #0 
/usr/share/php/Icinga/Web/View.php(262): 
Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}() #1 
/usr/share/php/Icinga/Web/View.php(262): include() #2 
/usr/share/icingaweb2/library/vendor/Zend/View/Abstract.php(877): 
Icinga\Web\View->_run() #3 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(904):
 Zend_View_Abstract->render() #4 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(925):
 Zend_Controller_Action_Helper_ViewRenderer->renderScript() #5 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(964):
 Zend_Controller_Action_Helper_ViewRenderer->render() #6 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker.php(272):
 Zend_Controller_Action_Helper_ViewRenderer->postDispatch() #7 /usr/share/icin 
in /usr/share/icingaweb2/library/vendor/Zend/Controller/Plugin/Broker.php on 
line 259

   * What outcome did you expect instead?

Ordinary Icinga Web page.


I also tried with the package in experimental,
php-icinga_2.8.0~rc1-1~exp2_all.deb. I got a different problem: the
CSS does not load and nginx logs:

2020/05/15 14:33:17 [error] 21559#21559: *65 FastCGI sent in stderr: "PHP 
message: PHP Fatal error:  Uncaught ErrorException: file_get_contents(): 
Filename cannot be empty in /usr/share/php/Icinga/Web/LessCompiler.php:172
Stack trace:
#0 [internal function]: 
Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}()
#1 /usr/share/php/Icinga/Web/LessCompiler.php(172): file_get_contents()
#2 /usr/share/php/Icinga/Web/StyleSheet.php(172): 
Icinga\Web\LessCompiler->render()
#3 /usr/share/php/Icinga/Web/StyleSheet.php(210): 
Icinga\Web\StyleSheet->render()
#4 /usr/share/php/Icinga/Application/webrouter.php(61): 
Icinga\Web\StyleSheet::send()
#5 /usr/share/icingaweb2/public/index.php(4): require_once('/usr/share/php/...')
#6 {main}
  thrown in /usr/share/php/Icinga/Web/LessCompiler.php on line 172" while 
reading response header from upstream, client: 192.168.2.1, server: _, request: 
"GET /icingaweb2/css/icinga.min.css HTTP/2.0", upstream: 
"fastcgi://unix:/var/run/php/php-fpm.sock:", host: "icinga2.nic.example", 
referrer: "https://icinga2.nic.example/icingaweb2/dashboard;
2020/05/15 14:33:17 [error] 21559#21559: *65 FastCGI sent in stderr: "PHP 
message: PHP Fatal error:  Uncaught ErrorException: 
file_get_contents(/usr/share/icingaweb2/public/js/icinga/behavior/modal.js): 
failed to open stream: No such file or directory in 
/usr/share/php/Icinga/Web/JavaScript.php:126
Stack trace:
#0 [internal function]: 
Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}()
#1 /usr/share/php/Icinga/Web/JavaScript.php(126): file_get_contents()
#2 /usr/share/php/Icinga/Web/JavaScript.php(50): Icinga\Web\JavaScript::send()
#3 /usr/share/php/Icinga/Application/webrouter.php(69): 
Icinga\Web\JavaScript::sendMinified()
#4 /usr/share/icingaweb2/public/index.php(4): require_once('/usr/share/php/...')
#5 {main}
  thrown in /usr/share/php/Icinga/Web/JavaScript.php on line 126" while reading 
response header from upstream, client: 192.168.2.1, server: _, request: "GET 
/icingaweb2/js/icinga.min.js HTTP/2.0", upstream: 
"fastcgi://unix:/var/run/php/php-fpm.sock:", host: "icinga2.nic.example", 
referrer: "https://icinga2.nic.example/icingaweb2/dashboard;


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.199-a890a5a94ebb621f8f1720c24d12fef1-0 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages 

Bug#865636: nagios-nrpe-server: Sample config files not found

2017-06-23 Thread Stephane Bortzmeyer
Package: nagios-nrpe-server
Version: 3.0.1-3
Severity: minor

Dear Maintainer,

/usr/share/doc/nagios-nrpe-server/README.md.gz says "Sample config
files for the NRPE daemon are located in the `sample-config/`
subdirectory."

But this subdirectory is not shipped with the Debian package. (It is
distributed in the upstream source.)

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

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

Versions of packages nagios-nrpe-server depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libssl1.0.2  1.0.2l-2
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20161125

Versions of packages nagios-nrpe-server recommends:
ii  monitoring-plugins2.2-3
ii  monitoring-plugins-basic  2.2-3

Versions of packages nagios-nrpe-server suggests:
pn  xinetd | inetd  

-- Configuration Files:
/etc/default/nagios-nrpe-server changed [not included]
/etc/nagios/nrpe.cfg changed [not included]

-- no debconf information



Bug#863646: [Pkg-nagios-devel] Bug#863646: nagios-nrpe-plugin: corrupted size vs. prev_size

2017-05-29 Thread Stephane Bortzmeyer
On Mon, May 29, 2017 at 08:36:25PM +0200,
 Sebastiaan Couwenberg  wrote 
 a message of 23 lines which said:

> > CHECK_NRPE: Error - Could not complete SSL handshake with 
> > 2605:4500:2:245b:483a:663a:623a:633a: 1
> 
> Have you configured SSL,

It worked before (before I upgraded to 3.0.1, the version in
unstable), so it is probably not one of the usual SSL problems. tshark
shows that the server indeed sends back a:

Secure Sockets Layer
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)

> and specifically read the NEWS entry about the incompatibility
> between versions?

/usr/share/doc/nagios-nrpe-plugin/NEWS.Debian.gz has nothing about
3.1. The entry about 3.0 seems to say that there is zero chance it
will work between Debian unstable and stable :-(



Bug#863646: [Pkg-nagios-devel] Bug#863646: nagios-nrpe-plugin: corrupted size vs. prev_size

2017-05-29 Thread Stephane Bortzmeyer
On Mon, May 29, 2017 at 08:04:29PM +0200,
 Sebastiaan Couwenberg  wrote 
 a message of 25 lines which said:

> Can you reproduce the problem with 3.1.1 from experimental?

No, 3.1.1 makes this specific problem disappear but it does not work
either:

% /usr/lib/nagios/plugins/check_nrpe -H ada.bortzmeyer.org  
   
CHECK_NRPE: Error - Could not complete SSL handshake with 
2605:4500:2:245b:483a:663a:623a:633a: 1



Bug#863646: nagios-nrpe-plugin: corrupted size vs. prev_size

2017-05-29 Thread Stephane Bortzmeyer
Package: nagios-nrpe-plugin
Version: 3.0.1-3
Severity: important

Dear Maintainer,

% /usr/lib/nagios/plugins/check_nrpe -H ada.bortzmeyer.org
*** Error in `/usr/lib/nagios/plugins/check_nrpe': corrupted size
vs. prev_size: 0x800c6ae8 ***
zsh: abort  /usr/lib/nagios/plugins/check_nrpe -H
ada.bortzmeyer.org

This seems to indicate a bad use of memory allocation (malloc hardened
produces this message).

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf
 (armv7l)

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

Versions of packages nagios-nrpe-plugin depends on:
ii  libc62.24-11
ii  libssl1.0.2  1.0.2l-1

nagios-nrpe-plugin recommends no packages.

nagios-nrpe-plugin suggests no packages.

-- no debconf information



Bug#863102: epubcheck: exec format error

2017-05-21 Thread Stephane Bortzmeyer
Package: epubcheck
Version: 4.0.1-2
Severity: important

%  epubcheck 
zsh: exec format error: epubcheck

I assume that, in one way or the other, a non-ARM executable is
embedded in the package.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf
 (armv7l)

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

Versions of packages epubcheck depends on:
ii  jarwrapper0.59
ii  libcommons-compress-java  1.13-1
ii  libguava-java 19.0-1
ii  libjackson-json-java  1.9.2-8
ii  libjing-java  20131210+dfsg+1-6
ii  libsac-java   1.3+dfsg-2
ii  libsaxonhe-java   9.5.1.1+dfsg-2

epubcheck recommends no packages.

epubcheck suggests no packages.

-- no debconf information



Bug#835210: May be using the Grafana Debian package for help?

2017-05-08 Thread Stephane Bortzmeyer
Dmitry said "I'm not sure if I can make it happen as Grafana became
very difficult to package". Well, upstream provides Debian packages so
they probably can be used to unstuck this very old issue.

http://docs.grafana.org/installation/debian/#apt-repository



Bug#840516: patterns are deprecated

2017-05-08 Thread Stephane Bortzmeyer
There are several reasons why graphite-web does not work with Django
1.10 (the current version in sid). One of them is that it uses the
"patterns" variable:

Traceback (most recent call last):
  File "/usr/bin/graphite-manage", line 15, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 367, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 359, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
294, in run_from_argv
self.execute(*args, **cmd_options)
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
342, in execute
self.check()
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
374, in check
include_deployment_checks=include_deployment_checks,
  File 
"/usr/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", 
line 62, in _run_checks
issues.extend(super(Command, self)._run_checks(**kwargs))
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
361, in _run_checks
return checks.run_checks(**kwargs)
  File "/usr/lib/python2.7/dist-packages/django/core/checks/registry.py", line 
81, in run_checks
new_errors = check(app_configs=app_configs)
  File "/usr/lib/python2.7/dist-packages/django/core/checks/urls.py", line 14, 
in check_url_config
return check_resolver(resolver)
  File "/usr/lib/python2.7/dist-packages/django/core/checks/urls.py", line 24, 
in check_resolver
for pattern in resolver.url_patterns:
  File "/usr/lib/python2.7/dist-packages/django/utils/functional.py", line 35, 
in __get__
res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/lib/python2.7/dist-packages/django/urls/resolvers.py", line 313, 
in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "/usr/lib/python2.7/dist-packages/django/utils/functional.py", line 35, 
in __get__
res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/lib/python2.7/dist-packages/django/urls/resolvers.py", line 306, 
in urlconf_module
return import_module(self.urlconf_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/graphite/urls.py", line 29, in 
urlpatterns = patterns('',
NameError: name 'patterns' is not defined


Which has been removed from Django in 1.9:

https://docs.djangoproject.com/en/1.9/ref/urls/#patterns



Bug#862084: graphite-web: Stupid version number testing as string

2017-05-08 Thread Stephane Bortzmeyer
Package: graphite-web
Version: 0.9.15+debian-2
Severity: important

Dear Maintainer,

/usr/share/graphite-web/graphite.wsgi contains a really stupid version
test:

if django.get_version() >= "1.7":

Testing a version number as a string DOES NOT WORK. Since Django 1.10,
this test yields false. The correct test uses numbers
(django.VERSION), not strings (django.get_version).

% python
>>> import django
>>> django.get_version()
'1.10.7'
>>> django.VERSION
(1, 10, 7, u'final', 0)

>>> django.get_version() >= "1.7"
False
>>> django.get_version() >= "1.1"
True
>>> django.get_version() >= "1.2"
False
>>> django.VERSION > (1, 7)
True

This is one of the reasons behind bug #840516


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf
 (armv7l)

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

Versions of packages graphite-web depends on:
ii  adduser3.115
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  python-cairo   1.8.8-2.2
ii  python-django  1:1.10.7-1
ii  python-django-tagging  1:0.4.5-1
ii  python-pyparsing   2.1.10+dfsg1-1
ii  python-simplejson  3.10.0-1
ii  python-tz  2016.7-0.3
ii  python-whisper 0.9.15-1
pn  python:any 

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  0.9.15-1
ii  libapache2-mod-wsgi  4.5.11-1
pn  python-ldap  
pn  python-memcache  
pn  python-mysqldb   

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- no debconf information



Bug#843263: Workaround works, why is it not applied yet???

2017-05-07 Thread Stephane Bortzmeyer
I can confirm that the workaround coming from Miek Gieben works
fine. Why is it not applied, several months after???



Bug#857578: knot-resolver: The package should not override blindly the config of trust anchors

2017-03-12 Thread Stephane Bortzmeyer
Package: knot-resolver
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

I tried an alternative root and therefore set up trust_anchors.config
to use the key of this alternative root.

But, by default, the daemon is launched with
--keyfile=/usr/share/dns/root.key and therefore uses the IANA key ->
SERVFAIL

I edited /etc/default/kresd, and fixed the problem, but I do not see
why there are two configuration files, /etc/knot-resolver/kresd.conf
and /etc/default/kresd. IMHO, the choices made by the sysadmin in
/etc/knot-resolver/kresd.conf should be respected.

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

Kernel: Linux 4.8.3-x86_64-linode76 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages knot-resolver depends on:
ii  adduser3.115
ii  dns-root-data  2015052300+h+1
ii  libc6  2.24-9
ii  libdnssec2 2.4.0-3
ii  libgnutls303.5.8-3
ii  libhiredis0.13 0.13.3-2
ii  libknot5   2.4.0-3
ii  liblmdb0   0.9.18-5
ii  libluajit-5.1-22.0.4+dfsg-1+b1
ii  libmemcached11 1.0.18-4.1
ii  libmemcachedutil2  1.0.18-4.1
ii  libnettle6 3.3-1+b1
ii  libsystemd0232-18
ii  libuv1 1.9.1-3
ii  libzscanner1   2.4.0-3
ii  lua-sec0.6-3
ii  lua-socket 3.0~rc1+git+ac3201d-3

Versions of packages knot-resolver recommends:
ii  knot-resolver-module-http  1.2.0-1

knot-resolver suggests no packages.

-- Configuration Files:
/etc/default/kresd changed:
KRESD_ARGS="--config=/etc/knot-resolver/kresd.conf --verbose --forks=1 
/run/knot-resolver/cache"
DAEMON_ARGS="--addr=127.0.0.1#53 --addr=::1#53 $KRESD_ARGS"

/etc/knot-resolver/kresd.conf changed:
-- -*- mode: lua -*-
modules = {
   'hints' -- Add other modules, if necessary
   }
net = { '127.0.0.1' }
-- Knot uses a specific format for the hints so we cannot use the official Yeti 
hints file.
hints.root({
   ['bii.dns-lab.net.'] = '240c:f:1:22::6',
   ['yeti-ns.tisf.net.'] = '2001:559:8000::6',
   ['yeti-ns.wide.ad.jp.'] = '2001:200:1d9::35',
   ['yeti-ns.as59715.net.'] = '2a02:cdc5:9715:0:185:5:203:53',
 ['dahu1.yeti.eu.org.'] = 
'2001:4b98:dc2:45:216:3eff:fe4b:8c5b',
   ['ns-yeti.bondis.org.'] = 
'2a02:2810:0:405::250',
 ['yeti-ns.ix.ru.'] = 
'2001:6d0:6d06::53',
   ['yeti.bofh.priv.at.'] = 
'2a01:4f8:161:6106:1::10',
 
['yeti.ipv6.ernet.in.'] = '2001:e30:1c1e:1::333',
   
['yeti-dns01.dnsworkshop.org.'] = '2001:1608:10:167:32e::53',
 
['yeti-ns.conit.co.'] = '2607:ff28:2:10::47:a010',
   
['yeti.aquaray.com.'] = '2a02:ec0:200::1',

 ['dahu2.yeti.eu.org.'] = '2001:67c:217c:6::2',

   ['yeti-ns.switch.ch.'] = '2001:620:0:ff::29'
})
trust_anchors.config('/etc/knot-resolver/yeti-root.key')


-- no debconf information



Bug#857082: /usr/bin/stubby: does not start: Could not bind on given addresses: No such file or directory

2017-03-07 Thread Stephane Bortzmeyer
Package: getdns-utils
Version: 1.1.0~a2-1
Severity: normal
File: /usr/bin/stubby

Dear Maintainer,

%  sudo stubby @145.100.185.16 -L
error: Could not bind on given addresses: No such file or directory

On another machine, where I compiled myself from upstream, the same
command works and gives the expected result (stubby runs ans listens
to DNS requests).

It is not a problem with already bound addresses, nothing listens on
127.0.0.1:53:

% sudo lsof -i:53
%

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

Kernel: Linux 4.8.3-x86_64-linode76 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages getdns-utils depends on:
ii  libc62.24-9
ii  libgetdns1   1.1.0~a2-1
ii  libidn11 1.33-1
ii  libssl1.11.1.0e-1
ii  libunbound2  1.6.0-3

getdns-utils recommends no packages.

getdns-utils suggests no packages.

-- no debconf information



Bug#851757: Worse with the new version

2017-01-27 Thread Stephane Bortzmeyer
On Fri, Jan 27, 2017 at 03:31:28PM +0100,
 Stephane Bortzmeyer <steph...@sources.org> wrote 
 a message of 19 lines which said:

> I just dist-upgraded, and despite the fact that nagios-nrpe-plugin
> stayed at 3.0.1-3, it is even worse. It now segfaults in all the
> cases.

I've found a new workaround (it came from upstream bug #63
<https://github.com/NagiosEnterprises/nrpe/issues/63>): change the
cipher list:

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example  -c 'check_disks' 

zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
my.server.example -c 'check_disks'

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example -L 'MEDIUM' -c 
'check_disks'   
 
DISK OK - free space: / 6124 MB (32% inode=79%);| /=12962MB;16100;18113;0;20126

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example -L 'HIGH' -c 
'check_disks'   
 
zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
my.server.example -L 'HIGH' -c 

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example -L 'HIGH:!MD5' -c 
'check_disks'   
 
zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
my.server.example -L 'HIGH:!MD5' -c 

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example -L 'HIGH:MEDIUM' -c 
'check_disks'   
 
zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
my.server.example -L 'HIGH:MEDIUM' -c 

% /usr/lib/nagios/plugins/check_nrpe -H my.server.example -L 'MEDIUM:!MD5:!RC4' 
-c 'check_disks'  
DISK OK - free space: / 6124 MB (32% inode=79%);| /=12962MB;16100;18113;0;20126



Bug#851757: Worse with the new version

2017-01-27 Thread Stephane Bortzmeyer
On Fri, Jan 27, 2017 at 03:31:28PM +0100,
 Stephane Bortzmeyer <steph...@sources.org> wrote 
 a message of 19 lines which said:

> Program received signal SIGILL, Illegal instruction.

This one was spurious (and it is documented in the OpenSSL FAQ
<https://www.openssl.org/docs/faq.html#PROG17>). The real signal
(SIGSEGV, as indicated in the original bug report) is here:

(gdb) handle SIGILL nostop
SignalStop  Print   Pass to program Description
SIGILLNoYes Yes Illegal instruction

(gdb)  run  -H my.host.example -6 -c 'check_disks'  
Starting program: /usr/lib/nagios/plugins/check_nrpe -H my.host.example -6 -c 
'check_disks'

Program received signal SIGILL, Illegal instruction.


Program received signal SIGSEGV, Segmentation fault.
0xb6d96926 in _int_free (av=0xb6e307a4 , p=0x7f5910f0, have_lock=0) 
at malloc.c:4049
4049malloc.c: No such file or directory.
(gdb) 
(gdb) where
#0  0xb6d96926 in _int_free (av=0xb6e307a4 , p=0x7f5910f0, 
have_lock=0)
at malloc.c:4049
#1  0xb6e99472 in CRYPTO_free () from 
/usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
#2  0xb6ebdc04 in BN_clear_free () from 
/usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)



Bug#851757: Worse with the new version

2017-01-27 Thread Stephane Bortzmeyer
I just dist-upgraded, and despite the fact that nagios-nrpe-plugin
stayed at 3.0.1-3, it is even worse. It now segfaults in all the
cases.

gdb seems to indicate the problem is in the crypto code (but many
other programs use OpenSSL on this machine):

Program received signal SIGILL, Illegal instruction.
0xb6e9ace8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
(gdb) where
#0  0xb6e9ace8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
#1  0xb6e98670 in OPENSSL_cpuid_setup () from 
/usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2
#2  0xb6fe2af4 in call_init (l=, argc=argc@entry=6, 
argv=argv@entry=0xbefffa24, 
env=env@entry=0xbefffa40) at dl-init.c:72
#3  0xb6fe2bce in call_init (env=, argv=, 
argc=, 
l=) at dl-init.c:30
#4  _dl_init (main_map=0xb6fff958, argc=6, argv=0xbefffa24, env=0xbefffa40) at 
dl-init.c:120
#5  0xb6fd7a44 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)



Bug#851757: [Pkg-nagios-devel] Bug#851757: nagios-nrpe-plugin: Segmentation fault when specifying the host with an IP address

2017-01-19 Thread Stephane Bortzmeyer
On Wed, Jan 18, 2017 at 10:52:46PM +0100,
 Sebastiaan Couwenberg  wrote 
 a message of 31 lines which said:

> Running check_nrpe on Debian unstable and checking a Debian jessie and
> Debian unstable host works fine on my test system both with a bash & zsh
> shell.
> 
> How can I reproduce the issue?

Which architecture? Mine was ARM, as indicated in the bug report.



Bug#484575: Related bug?

2017-01-18 Thread Stephane Bortzmeyer
Yes, IPv6 works fine for me, too, but see also #851757 which may be related.



Bug#851758: Possible duplicate

2017-01-18 Thread Stephane Bortzmeyer
I see now that it may be a duplicate of #843860



Bug#851758: emacs: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory

2017-01-18 Thread Stephane Bortzmeyer
Package: emacs
Version: 46.1
Severity: important

Dear Maintainer,

% emacs TODO
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such 
file or directory

Apparently, there is a missing dependency. If install libgl1-mesa-glx,
everything works.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs24  24.5+1-7.1+b1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information



Bug#851757: nagios-nrpe-plugin: Segmentation fault when specifying the host with an IP address

2017-01-18 Thread Stephane Bortzmeyer
Package: nagios-nrpe-plugin
Version: 3.0.1-3
Severity: important

Dear Maintainer,

% /usr/lib/nagios/plugins/check_nrpe -H 198.0.2.153  -c 'check_disks' 
zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 198.0.2.153 -c 
'check_disks'

% /usr/lib/nagios/plugins/check_nrpe -H my.machine.example -c 'check_disks'  
zsh: segmentation fault  /usr/lib/nagios/plugins/check_nrpe -H 
my.machine.example -c 'check_disks'

But if I use -4 or -6, and a host name, everything works:

% /usr/lib/nagios/plugins/check_nrpe -H my.machine.example -6 -c 'check_disks'  
DISK OK - free space: / 6113 MB (32% inode=79%);| /=12973MB;16100;18113;0;20126


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nagios-nrpe-plugin depends on:
ii  libc62.24-9
ii  libssl1.0.2  1.0.2j-5

nagios-nrpe-plugin recommends no packages.

nagios-nrpe-plugin suggests no packages.

-- no debconf information



Bug#849577: stubby also

2016-12-30 Thread Stephane Bortzmeyer
Note that stubby has the same bug:

% stubby @2001:4b98:dc2:43:216:3eff:fea9:41a -L -z 127.0.0.1:8053 
Could not convert "2001:4b98:dc2:43:216:3eff:fea9:41a" to an IP dict: A helper 
function was supposed to return a certain type for an item, but the wrong type 
was given.
Could not convert "127.0.0.1:8053" to an IP dict: A helper function was 
supposed to return a certain type for an item, but the wrong type was given.

Again, no problem is I use upstream code (from the git repos):

% src/tools/stubby  @2001:4b98:dc2:43:216:3eff:fea9:41a -L -z 127.0.0.1:8053

(and then it works)



Bug#849577: Works upstream

2016-12-30 Thread Stephane Bortzmeyer
The bug does not seem to be upstream, with today upstream git
repository, it works:

% src/test/getdns_query  @2001:4b98:dc2:43:216:3eff:fea9:41a -s 
www.bortzmeyer.org 
SYNC response:
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": ,
...



Bug#849577: getdns-utils: Cannot send queries to an IPv6 server

2016-12-28 Thread Stephane Bortzmeyer
Package: getdns-utils
Version: 1.1.0~a2-1
Severity: normal

Dear Maintainer,

No syntax seems to work:

% getdns_query  @2001:4b98:dc2:43:216:3eff:fea9:41a -s www.bortzmeyer.org
Could not convert "2001:4b98:dc2:43:216:3eff:fea9:41a" to an IP dict:
A helper function was supposed to return a certain type for an item,
but the wrong type was given.

All done.


% getdns_query  @\[2001:4b98:dc2:43:216:3eff:fea9:41a\] -s www.bortzmeyer.org
Could not convert "[2001:4b98:dc2:43:216:3eff:fea9:41a]" to an IP
dict: A helper function was supposed to return a certain type for an
item, but the wrong type was given.

All done.


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

Kernel: Linux 4.8.3-x86_64-linode76 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages getdns-utils depends on:
ii  libc62.24-8
ii  libgetdns1   1.1.0~a2-1
ii  libidn11 1.33-1
ii  libssl1.11.1.0c-2
ii  libunbound2  1.5.10-3

getdns-utils recommends no packages.

getdns-utils suggests no packages.

-- no debconf information



Bug#849576: getdns-utils: Error messages are really too poor

2016-12-28 Thread Stephane Bortzmeyer
Package: getdns-utils
Version: 1.1.0~a2-1
Severity: minor

Dear Maintainer,

I know that getdns_query is a demonstrator of getdns, and is not
intended to be a replacement for DNS clients like dig. Nevertheless, I
think that the error messages are really too poor to be usable:

Non-existing server, TLS:

% getdns_query  @192.0.2.1 -s  -l L www.bortzmeyer.org
An error occurred: 1 'Generic error'

All done.

Non-existing server, plain:

% getdns_query  @192.0.2.1 -s  www.bortzmeyer.org

SYNC response:
{
  "answer_type": GETDNS_NAMETYPE_DNS,
"canonical_name": ,
  "replies_full": [],
"replies_tree": [],
  "status": GETDNS_RESPSTATUS_ALL_TIMEOUT
  }
  Response code was: GOOD. Status was: All queries for the
  name timed out

All done.


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

Kernel: Linux 4.8.3-x86_64-linode76 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages getdns-utils depends on:
ii  libc62.24-8
ii  libgetdns1   1.1.0~a2-1
ii  libidn11 1.33-1
ii  libssl1.11.1.0c-2
ii  libunbound2  1.5.10-3

getdns-utils recommends no packages.

getdns-utils suggests no packages.

-- no debconf information



Bug#841496: knot-resolver: error /usr/lib/knot-resolver/kres.lua:24: support libknot not found

2016-10-21 Thread Stephane Bortzmeyer
Package: knot-resolver
Version: 1.1.1-2
Severity: important

Dear Maintainer,

% sudo /usr/sbin/kresd -v
[system] error /usr/lib/knot-resolver/kres.lua:24: support libknot not found
[system] worker failed: No such file or directory

(Same thing without -v)

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

Kernel: Linux 4.6.5-x86_64-linode71 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages knot-resolver depends on:
ii  dns-root-data  2015052300+h+1
ii  libc6  2.24-3
ii  libdnssec2 2.3.1-1
ii  libgnutls303.5.5-2
ii  libhiredis0.13 0.13.3-2
ii  libknot4   2.3.1-1
ii  liblmdb0   0.9.18-4
ii  libluajit-5.1-22.0.4+dfsg-1
ii  libmemcached11 1.0.18-4.1
ii  libmemcachedutil2  1.0.18-4.1
ii  libnettle6 3.3-1
ii  libsystemd0231-9
ii  libuv1 1.9.1-1
ii  libzscanner1   2.3.1-1
ii  lua-sec0.5.1-1
ii  lua-socket 3.0~rc1+git+321c0c9-1

Versions of packages knot-resolver recommends:
ii  knot-resolver-module-http  1.1.1-2

knot-resolver suggests no packages.

-- Configuration Files:
/etc/knot-resolver/kresd.conf changed [not included]

-- no debconf information



Bug#829557: One more confirmation

2016-07-08 Thread Stephane Bortzmeyer
Running stretch, I confirm that the problem still exists today (after
a dist-upgrade).

Installing dbus-user-session AND REBOOTING cured it.

ii  liblightdm-gobject-1-01.18.2-1 
amd64simple display manager (gobject library)
ii  lightdm   1.18.2-1 
amd64simple display manager
ii  dbus  1.10.8-1 
amd64simple interprocess messaging system (daemon and utilities)
ii  dbus-user-session 1.10.8-1 
all  simple interprocess messaging system (systemd --user integration)
ii  dbus-x11  1.10.8-1 
amd64simple interprocess messaging system (X11 deps)



Bug#818930: knot-resolver: trust_anchors.config does not check its argument

2016-03-21 Thread Stephane Bortzmeyer
Package: knot-resolver
Version: 1.0.0~beta3-1
Severity: normal

Dear Maintainer,

When calling:

trust_anchors.config('/etc/knot-resolver/yeti-root.key')

I discovered that Knot does not check that the file exists. If it
doesn't, there is no error and no warning, but Knot falls back to a
root anchor bootstrapped

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

Kernel: Linux 4.1.5-x86_64-linode61 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages knot-resolver depends on:
ii  dns-root-data2015052300+h+1
ii  init-system-helpers  1.29
ii  libc62.22-3
ii  libdnssec0   2.1.1-1
ii  libgeoip11.6.9-1
ii  libhiredis0.13   0.13.3-2
ii  libjs-d3 3.5.16-1
ii  libjs-jquery 1.11.3+dfsg-4
ii  libknot1 2.1.1-1
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libuv1   1.8.0-1
ii  libzscanner0 2.1.1-1
ii  lua-sec  0.5.1-1
ii  lua-socket   3.0~rc1+git+321c0c9-1

knot-resolver recommends no packages.

knot-resolver suggests no packages.

-- Configuration Files:
/etc/knot-resolver/kresd.conf changed [not included]

-- no debconf information



Bug#817894: What about RFC 7671?

2016-03-11 Thread Stephane Bortzmeyer
Is it even a good idea to test the subject name when the Certificate
Usage is DANE-EE? RFC 7671 says, in its section 5.1, to ignore all the
checks such as expiration date and subject name.



Bug#817894: hash-slinger: tlsa --verify sends a spurious warning when the cert has a wildcard

2016-03-11 Thread Stephane Bortzmeyer
Package: hash-slinger
Version: 2.6-1
Severity: minor

% tlsa --verify rdap.nic.alsace
WARNING: Name on the certificate (Subject: 
/serialNumber=bzF6gBWp0uI4sLILv6rqnFaJXglK01CP/OU=GT64370990/OU=See 
www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - 
RapidSSL(R)/CN=*.nic.alsace, SubjectAltName: DNS:*.nic.alsace, DNS:nic.alsace) 
doesn't match requested hostname (rdap.nic.alsace).
Caution: name on the cert does not match hostname
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record

IMHO, the WARNING is spurious: the cert has a wildcard and therefore
the name *does* match.

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages hash-slinger depends on:
ii  ca-certificates20160104
ii  dns-root-data  2015052300+h+1
ii  libpython2.7-stdlib [python-argparse]  2.7.11-3
ii  openssh-client 1:7.1p2-2
ii  python 2.7.11-1
ii  python-dnspython   1.12.0-1
ii  python-gnupg   0.3.8-2
ii  python-ipaddr  2.1.11-2
ii  python-m2crypto0.22.6~rc4-1
ii  python-unbound 1.5.7-1

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information



Bug#790679: hash-slinger: Should not use DLV by default

2015-06-30 Thread Stephane Bortzmeyer
Package: hash-slinger
Version: 2.5-1
Severity: normal

Dear Maintainer,

DLV is on the road to deprecation https://dlv.isc.org/ and therefore
must not be used by default.


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

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

Versions of packages hash-slinger depends on:
ii  libpython2.7-stdlib [python-argparse]  2.7.9-2
ii  openssh-client 1:6.7p1-5
ii  python 2.7.9-1
ii  python-dnspython   1.12.0-1
ii  python-gnupg   0.3.6-1
ii  python-ipaddr  2.1.11-2
ii  python-m2crypto0.21.1-3
ii  python-unbound 1.4.22-3

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information


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



Bug#787629: echoping: New homepage at Github

2015-06-03 Thread Stephane Bortzmeyer
Package: echoping
Version: 6.0.2-8
Severity: minor

Dear Maintainer,

The code left SourceForge, for obvious reasons
http://arstechnica.com/information-technology/2015/06/sourceforge-locked-in-projects-of-fleeing-users-cashed-in-on-malvertising/
The new homepage is http://bortzmeyer.github.io/echoping/

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages echoping depends on:
ii  libc6  2.19-18
ii  libgnutls-deb0-28  3.3.8-6
ii  libidn11   1.29-1+b2
ii  libldap-2.4-2  2.4.40+dfsg-1
ii  libpopt0   1.16-10
ii  libpq5 9.4.2-0+deb8u1

echoping recommends no packages.

echoping suggests no packages.

-- no debconf information


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



Bug#642357: Still present for jessie

2015-04-24 Thread Stephane Bortzmeyer
The bug seems still present in jessie today (mod-gnutls 0.5.10).

I did not find a mention of reporting upstream so here it is done:

https://mod.gnutls.org/ticket/98

This is critical since it affects Tor hidden services, for instance
(in that case, Apache sees all connections going through Tor at
localhost)

(The upstream ticket tracker is mostly full of spam so I wonder if the
project is still alive.)


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



Bug#754960: Still present in jessie

2015-04-24 Thread Stephane Bortzmeyer
As of today, jessie still has the problem.
GnuTLS 2.12.23 and 0.5.10
That makes two serious security bugs against libapache2-mod-gnutls
(#642357 and this one).

There was a conversation on ServerFault
http://serverfault.com/a/606176/2253 which mentions a version 0.6
which never occurred.


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



Bug#765831: nsd: systemd cannot start nsd if dynamic interface and binding to a specific IP

2014-10-18 Thread Stephane Bortzmeyer
Package: nsd
Version: 4.1.0-1
Severity: normal

Dear Maintainer,

Since I moved to Debian jessie which forces the usage of systemd,
NSD no longer starts when the machine boots. However, if I log in
immediately, and issue a systemctl start nsd, it starts fine.

Otherwise, I get the message:

% sudo systemctl status -l nsd
...
Oct 18 13:48:19 mononoke.bortzmeyer.org nsd[2799]: [2014-10-18
13:48:19.151] nsd[2799]: error: can't bind udp socket: Cannot assign requested 
address

Several workarounds:

* define the interface as static instead of dhcp (it's possible at
  Linode)
* stop binding NSD to a specific interface

However, none is perfectly satisfying. The right solution would be to
fix the race condition between the network and NSD.

Using a Web search engine, you can find reports of people saying that
changing the interface from allow-hotplug to auto worked for them, but
it didn't for me.

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

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

Versions of packages nsd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  libc6  2.19-11
ii  libevent-2.0-5 2.0.21-stable-1.1
ii  libssl1.0.01.0.1i-2
ii  lsb-base   4.1+Debian13

nsd recommends no packages.

nsd suggests no packages.

-- Configuration Files:
/etc/nsd/nsd.conf changed [not included]

-- debconf information excluded


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



Bug#765831: Editing the nsd.service

2014-10-18 Thread Stephane Bortzmeyer
Someone suggested to modify the nsd.service file this way:

Wants=network-online.target
After=network-online.target

But it did not help.


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



Bug#737540: nsd: Huge rate of query drop with IPv6

2014-02-03 Thread Stephane Bortzmeyer
Package: nsd
Version: 4.0.0-5
Severity: important

Dear Maintainer,

By default, NSD 4 on Linux uses the new recvmmsg() system call, which
is broken for IPv6 (huge packet loss). See
https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html
and
https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001785.html. NSD
should be configured with --disable-recvmmsg

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

Kernel: Linux 3.12.6-x86_64-linode36 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nsd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  libevent-2.0-5 2.0.21-stable-1
ii  libssl1.0.01.0.1f-1
ii  lsb-base   4.1+Debian12

nsd recommends no packages.

nsd suggests no packages.

-- Configuration Files:
/etc/nsd/nsd.conf changed [not included]

-- debconf information excluded


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



Bug#724063: efingerd: Security risk with the default shell scripts

2013-09-23 Thread Stephane Bortzmeyer
On Mon, Sep 23, 2013 at 05:37:47PM +0200,
 Radovan Garabik gara...@kassiopeia.juls.savba.sk wrote 
 a message of 55 lines which said:

 The $2 is in quotes, and anyway it is invoked via execl(3), so I
 cannot find a way how to subvert the script - that is not to say I
 do not believe this is a real risk, I just do not see an obvious way
 how to exploit it.

No, I do not have an exploit, I was just concerned. May be I've just
read too many PHP scripts but it seems to me you're tempting the
devil.


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



Bug#661693: dblatex: Per-cent in URLs are not escaped

2012-05-09 Thread Stephane Bortzmeyer
On Sat, May 05, 2012 at 12:22:42PM +0200,
 Andreas Hoenen andr...@hoenen-terstappen.de wrote 
 a message of 81 lines which said:

 I have just tried to reproduce your problem without effect, 

Indeed, I cannot reproduce the problem any more on wheezy. 



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



Bug#661693: dblatex: Per-cent in URLs are not escaped

2012-02-29 Thread Stephane Bortzmeyer
Package: dblatex
Version: 0.3.2-2
Severity: normal


When the Docbook source uses an URL with per-cents:

ulink 
url=http://technet.microsoft.com/en-us/library/dd197418%28v=ws.10%29.aspx;la
description du paramètre NameServer/ulink

dblatex translates it without escaping the % signs:

la description du paramètre 
NameServer\footnote{\url{http://technet.microsoft.com/en-us/library/dd197418%28v=ws.10%29.aspx}{}}

And of course, LaTeX complains afterwards.

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

Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dblatex depends on:
ii  docbook-xml   4.5-7
ii  python2.7.2-10
ii  python-apt0.8.0
ii  texlive   2009-15
ii  texlive-bibtex-extra  2009-10
ii  texlive-extra-utils   2009-10
ii  texlive-latex-extra   2009-10
ii  texlive-math-extra2009-10
ii  xsltproc  1.1.26-8

Versions of packages dblatex recommends:
ii  libxml2-utils  2.7.8.dfsg-7

Versions of packages dblatex suggests:
ii  docbook4.5-4
ii  ghostscript9.04~dfsg-3
ii  gv [pdf-viewer]1:3.7.3-1
ii  imagemagick8:6.6.9.7-5+b2
ii  latex-cjk-all  none
ii  lmodern2.004.1-3.1
ii  opensp 1.5.2-10
ii  texlive-lang-cyrillic  2009-3
ii  texlive-xetex  2009-15
ii  transfig   1:3.2.5.d-1
ii  xpdf [pdf-viewer]  3.02-21

-- no debconf information



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



Bug#659761: ldnsutils: drill does not use IPv6 resolvers by default

2012-02-13 Thread Stephane Bortzmeyer
Package: ldnsutils
Version: 1.6.12-1
Severity: normal

Dear Maintainer,

Unlike dig, when the first line of /etc/resolv.conf is IPv6, drill
ignores it and goes to the first IPv4 line.

You have to force IPv6 usage with -6. Inconsistent with dig and not
conformant to resolv.conf(5).

% grep nameserver /etc/resolv.conf
nameserver ::1
nameserver 192.134.4.162
nameserver 192.134.4.163

% drill MX gmail.com
...
;; SERVER: 192.134.4.162

% dig MX gmail.com
...
;; SERVER: ::1#53(::1)

% drill -6 MX gmail.com  
...
;; SERVER: ::1


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

Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages ldnsutils depends on:
ii  libc62.13-26
ii  libldns1 1.6.12-1
ii  libpcap0.8   1.2.1-1
ii  libssl1.0.0  1.0.0g-1

ldnsutils recommends no packages.

ldnsutils suggests no packages.

-- no debconf information



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



Bug#659761: ldnsutils: drill does not use IPv6 resolvers by default

2012-02-13 Thread Stephane Bortzmeyer
On Mon, Feb 13, 2012 at 06:06:40PM +0100,
 Ond?ej Surý ond...@sury.org wrote 
 a message of 36 lines which said:

 why report here and not upstream?

Since drill works fine when explicitely instructed to use IPv6, I
assumed it was a Debian compilation with the wrong compile-time
options.




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



Bug#630790: RFC now published, the bug is more and more a problem

2012-02-04 Thread Stephane Bortzmeyer
The RFC on the use of RFC3779-certificates in the RPKI (Resource
Public Key Infrastructrure) have been published (RFC 6487 for the
format of certificates). So, the problem is even more serious now.



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



Bug#652570: shorewall6: Spurious ICMP not permitted in an IPv6 configuration

2011-12-18 Thread Stephane Bortzmeyer
Package: shorewall6
Version: 4.4.11.6-1
Severity: normal


Despite what the documentation says, the keyword icmp (or a variant
such as icmp6 or icmpv6) is not recognized in rules:

   ERROR: ICMP not permitted in an IPv6 configuration : /etc/shorewall6/rules 
(line 462)

You have to use the numeric value of the protocol, 58.

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

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages shorewall6 depends on:
ii  debconf [debconf-2.0] 1.5.36.1   Debian configuration management sy
ii  iproute   20100519-3 networking and traffic control too
ii  iptables  1.4.8-3administration tools for packet fi
ii  libio-socket-inet6-perl   2.65-1.1   Object interface for AF_INET6 doma
ii  shorewall 4.4.11.6-3 Shoreline Firewall, netfilter conf

shorewall6 recommends no packages.

Versions of packages shorewall6 suggests:
ii  linux-image-2.6.32-5-686 [lin 2.6.32-39  Linux 2.6.32 for modern PCs
ii  make  3.81-8 An utility for Directing compilati
pn  shorewall-doc none (no description available)

-- Configuration Files:
/etc/default/shorewall6 changed:
startup=1
OPTIONS=


-- debconf information:
  shorewall6/major_release:
  shorewall6/dont_restart:
  shorewall6/invalid_config:



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



Bug#630790: Really needed for the soon-to-come RPKI

2011-10-10 Thread Stephane Bortzmeyer
It is really important to address this issue. The RFCs on the RPKI are
currently in the RFC editor queue
http://www.rfc-editor.org/queue.html#draft-ietf-sidr-res-certs,
meaning they will be published in a few weeks. Everyone is busy
learning about the RPKI (workshops, tutorials, etc, see
http://www.ripe.net/lir-services/resource-management/certification)
and its deployment already started (the RPKI certificates are already
publcially distributed by the Regional Internet Registries
rsync://rpki.ripe.net/repository).




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



Bug#642692: /usr/bin/oowriter: Crashes when opening a Bibliography database

2011-09-24 Thread Stephane Bortzmeyer
Package: openoffice.org-writer
Version: 1:3.2.1-11+squeeze3
Severity: normal
File: /usr/bin/oowriter


Selecting Tools - Bibliography database crashes OpenOffice (reliably,
whatever document is opened, even a new and empty one).

The program prints:

 terminate called after throwing an instance of 
'com::sun::star::loader::CannotActivateFactoryException'

I've seen bugs #528795 and #527910 but they're supposed to be closed
and I'm not sure they're related.

The machine is an ordinary squeeze (no mix of versions).
% java -version
java version 1.6.0_18
OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~squeeze1)
OpenJDK Server VM (build 14.0-b16, mixed mode)

I'm not able to get a backtrace. I've installed openoffice.org-dbg
but:

% gdb /usr/lib/openoffice/program/soffice.bin
GNU gdb (GDB) 7.0.1-debian
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.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/lib/openoffice/program/soffice.bin...Reading symbols 
from /usr/lib/debug/usr/lib/openoffice/program/soffice.bin...done.
(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/lib/openoffice/program/soffice.bin 
[Thread debugging using libthread_db enabled]
[New Thread 0x434c3b70 (LWP 32459)]
[New Thread 0x44b75b70 (LWP 32460)]
[New Thread 0x44d76b70 (LWP 32461)]
terminate called after throwing an instance of 
'com::sun::star::uno::RuntimeException'

Program received signal SIGABRT, Aborted.
0x4001d424 in __kernel_vsyscall ()
(gdb) 

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

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages openoffice.org-writer depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libicu44  4.4.1-7International Components for Unico
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3
ii  libstlport4.6 4.6.2-7STLport C++ class library
ii  libwpd8c2a0.8.14-1   Library for handling WordPerfect d
ii  libwps-0.1-1  0.1.2-1Works text file format import filt
ii  openoffice.or 1:3.2.1-11+squeeze3office productivity suite -- share
ii  openoffice.or 1:3.2.1-11+squeeze3office productivity suite -- arch-
ii  ure   1.6.1+OOo3.2.1-11+squeeze3 OpenOffice.org UNO runtime environ
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages openoffice.org-writer recommends:
ii  gcj-4.4-jre [java5 4.4.5-2   Java runtime environment using GIJ
ii  gcj-jre [java5-run 4:4.4.5-1 Java runtime environment using GIJ
ii  openjdk-6-jre [jav 6b18-1.8.7-2~squeeze1 OpenJDK Java runtime, using Hotspo
ii  openoffice.org-ema 1:3.2.1-11+squeeze3   office productivity suite -- email
ii  openoffice.org-fil 1:3.2.1-11+squeeze3   office productivity suite -- legac
ii  openoffice.org-jav 1:3.2.1-11+squeeze3   office productivity suite -- arch-
ii  openoffice.org-mat 1:3.2.1-11+squeeze3   office productivity suite -- equat

Versions of packages openoffice.org-writer suggests:
pn  openoffice.org-base   none (no description available)
pn  openoffice.org-gcjnone (no description available)

Versions of packages openoffice.org-core depends on:
ii  fontconfig2.8.0-2.1  generic font configuration library
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-6   The Cairo 2D vector graphics libra
ii  libcurl3-gnut 7.21.0-2   Multi-protocol file transfer libra
ii  libdb4.8  4.8.30-2   Berkeley v4.8 Database Libraries [
ii  libexpat1 2.0.1-7XML parsing C library - runtime li
ii  libfreetype6  2.4.2-2.1  FreeType 2 font engine, shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libgraphite3  1:2.3.1-0.2SILGraphite - a smart font rende
ii  libgstreamer- 0.10.30-1  GStreamer libraries from the base
ii  libgstreamer0 0.10.30-1  Core GStreamer libraries and eleme
ii  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface 
ii  libhunspell-1 1.2.11-1   spell checker and morphological an
ii  libhyphen02.5-1  

Bug#642692: /usr/bin/oowriter: Crashes when opening a Bibliography database

2011-09-24 Thread Stephane Bortzmeyer
On Sat, Sep 24, 2011 at 07:28:25PM +0200,
 Rene Engelhard r...@debian.org wrote 
 a message of 27 lines which said:

 There we go. Install -base,

It works, thanks.



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



Bug#628385: jparse: Exit code always zero

2011-05-28 Thread Stephane Bortzmeyer
Package: jparse
Version: 1.4.0-3
Severity: normal

When you feed jparse with an invalid JSON file, the return code is zero.

The syntax error is detected:

Analyzing toto.json ...Error.

JAULA Exception(Error detected during syntax analysis) : Unexpected symbol ':'  
...

But the exit code is not set properly:

% echo $? 
0


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

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages jparse depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libjaula1 1.4.0-3JSON parser/writer library for C++
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3

jparse recommends no packages.

jparse suggests no packages.

-- no debconf information



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



Bug#626345: The Ubuntu package seems fine

2011-05-13 Thread Stephane Bortzmeyer
http://packages.ubuntu.com/km/natty/python-dnspython

It installs flawlessly on a Debian squeeze and seems to work.




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



Bug#626345: python-dnspython: Upstream version 1.9 is out and has several DNSSEC improvments

2011-05-11 Thread Stephane Bortzmeyer
Package: python-dnspython
Version: 1.8.0-1
Severity: normal


sid has still 1.8 but 1.9 is out and includes several things that many DNSSEC 
fans will use (like the key_id method).

Ubuntu already has 1.9.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-dnspython depends on:
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
ii  python-support  1.0.10   automated rebuilding support for P

python-dnspython recommends no packages.

python-dnspython suggests no packages.

-- no debconf information



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



Bug#620342: stun: Homepage is no longer the right one

2011-04-01 Thread Stephane Bortzmeyer
Package: stun
Version: 0.96.dfsg-5
Severity: minor


Description says:

  Homepage: http://www.vovida.org/applications/downloads/stun/

but the page is empty:

There is currently no text in this page, you can search for this page title in 
other pages or edit this page. 

I was not able to find the right one.

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

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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



Bug#606808: Security analysis

2010-12-22 Thread Stephane Bortzmeyer
I've just committed your patch to echoping and it seems to work but I
wonder why it was reported as a security risk. I do not immediately
see why.


signature.asc
Description: Digital signature


Bug#599169: zonecheck: New upstream release 3.0.3

2010-10-05 Thread Stephane Bortzmeyer
Package: zonecheck
Version: 3.0.2-1
Severity: minor


New 3.0.3 fixes two annoying bugs (domains which were rejected when
they should have been accepted).

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages zonecheck depends on:
ii  iputils-ping3:20100418-2 Tools to test the reachability of 
ii  libdns-ruby 1.49-1   Ruby DNS client library (dummy pac
ii  ruby4.5  An interpreter of object-oriented 

Versions of packages zonecheck recommends:
ii  libopenssl-ruby   4.4OpenSSL interface for Ruby

zonecheck suggests no packages.

-- no debconf information



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



Bug#587419: zonecheck: New release 3.0.1

2010-06-28 Thread Stephane Bortzmeyer
Package: zonecheck
Version: 3.0.1-0.99
Severity: minor


Among the important things, 3.0.1 fixes two problems with the CGI
interface, which made DNSSEC reports quite painful.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages zonecheck depends on:
ii  iputils-ping3:20071127-1 Tools to test the reachability of 
ii  libdns-ruby 1.47-0.99Ruby DNS client library (dummy pac
ii  ruby4.2  An interpreter of object-oriented 

Versions of packages zonecheck recommends:
ii  libopenssl-ruby   4.2OpenSSL interface for Ruby

zonecheck suggests no packages.

-- no debconf information



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



Bug#586790: zonecheck: Version 3 is out

2010-06-22 Thread Stephane Bortzmeyer
Package: zonecheck
Version: 2.1.1-0.99
Severity: wishlist


Version 3 is now available at http://www.zonecheck.fr/. It includes
DNSSEC tests.

From a packaging point of view, do note that Zonecheck now depends on
DNSruby, a library which does not seem to be available as a Debian
package, only as a Ruby gem. I don't know what is the best way:
package DNSruby or install the gem in the Zonecheck package
installation script?

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages zonecheck depends on:
ii  iputils-ping3:20071127-1 Tools to test the reachability of 
ii  ruby4.2  An interpreter of object-oriented 

zonecheck recommends no packages.

zonecheck suggests no packages.

-- no debconf information



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



Bug#586790: dnsruby in Debian

2010-06-22 Thread Stephane Bortzmeyer
I was wrong, there is a libdns-ruby package in squeeze. So, the
following debian/control seems to work:

Package: zonecheck
Architecture: all
Depends: ruby (= 1.8), iputils-ping, rubygems, libdns-ruby (= 1.47)
Recommends: libopenssl-ruby
Description: A DNS configuration checker 
 The DNS is a critical resource for every network application, so it
 is quite important to ensure that a zone or domain name is correctly
 configured in the DNS.
 ZoneCheck is intended to help solving misconfigurations or
 inconsistencies usually revealed by an increase in the latency of the
 application, up to the output of unexpected/inconsistant results.
 This package is the command-line version.
 http://www.zonecheck.fr/

The rubygems dependency is because Zonecheck tests it at startup,
which may be useless. If you think so, please fill in a bug upstream
at https://savannah.nongnu.org/bugs/?group=zonecheck. The OpenSSL
dependency is because, without it, you have almost no DNSSEC test.

(Also, version 3 addresses most and may be all of the bugs that
required a Debian-specific patch)



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



Bug#583290: zonecheck: XSS security bug in the CGI

2010-05-26 Thread Stephane Bortzmeyer
Package: zonecheck
Version: 2.0.4-13
Severity: grave
Tags: security
Justification: user security hole


There is XSS security bug in Zonecheck cgi up to version 2.1.0. Fixed
upstream in 2.1.1. 

The patch is simple and can probably be backported: 
http://cvs.savannah.gnu.org/viewvc/zonecheck/zc/publisher/html.rb?root=zonecheckr1=1.79r2=1.80

The bug has already been exploited in the wild:
http://www.xssed.com/mirror/61096/

The upstream bug report: https://savannah.nongnu.org/bugs/?29967

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages zonecheck depends on:
ii  iputils-ping3:20071127-1 Tools to test the reachability of 
ii  ruby4.2  An interpreter of object-oriented 

zonecheck recommends no packages.

zonecheck suggests no packages.

-- no debconf information



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



Bug#569566: zonecheck: Version 2.1.0 is out

2010-02-12 Thread Stephane Bortzmeyer
Package: zonecheck
Version: 2.0.4+cvs20081105-1
Severity: wishlist


There is an official new release, 2.1.0, which fixes several bugs.

http://www.zonecheck.fr/
http://www.zonecheck.fr/download/src/zonecheck-2.1.0.tgz

The Debian packaging still works, minus the patch for root
nameservers, which is obsolete.

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

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages zonecheck depends on:
ii  iputils-ping3:20071127-2 Tools to test the reachability of 
ii  ruby4.2  An interpreter of object-oriented 

zonecheck recommends no packages.

zonecheck suggests no packages.

-- no debconf information



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



Bug#545985: Possible implementation

2009-09-17 Thread Stephane Bortzmeyer
No warranty, of course, use at will.
diff -ru pcaputils-0.8/doc/pcapdump.docbook pcaputils-AFNIC/doc/pcapdump.docbook
--- pcaputils-0.8/doc/pcapdump.docbook	2009-05-10 01:10:01.0 +0200
+++ pcaputils-AFNIC/doc/pcapdump.docbook	2009-09-17 14:48:58.0 +0200
@@ -101,6 +101,14 @@
   /varlistentry
 
   varlistentry
+termoption-k /optionreplaceablecommand/replaceable/term
+listitem
+	paraWhen closing the pcap capture file, runs the replaceablecommandreplaceable, with
+	the file name as an argument./para
+/listitem
+  /varlistentry
+
+  varlistentry
 termoption-C /optionreplaceableconfig file/replaceable/term
 listitem
   paraFile to read configuration variables from. Instead of passing configuration through the command line, a file can be used to specify values for the optionbpf/option, optiondevice/option, optionfilefmt/option, optiongroup/option, optioninterval/option, optionmode/option, optionowner/option, optionpromisc/option, and optionsnaplen/option options (not all need to be specified; defaults will be used otherwise). See /usr/share/doc/pcaputils/examples/pcapdump/eth0 for an example./para
diff -ru pcaputils-0.8/src/pcapdump.c pcaputils-AFNIC/src/pcapdump.c
--- pcaputils-0.8/src/pcapdump.c	2009-05-10 01:10:01.0 +0200
+++ pcaputils-AFNIC/src/pcapdump.c	2009-09-17 14:40:47.0 +0200
@@ -61,6 +61,7 @@
 	{ 'g', group, CONFIG_STR, {}, root,  output file owning group },
 	{ 'm', mode,  CONFIG_OCT, {}, 0600,  output file mode },
 	{ 't', interval,  CONFIG_DEC, {}, 86400, output file rotation interval },
+	{ 'k', kick,   CONFIG_STR, {}, NULL,program to kick in after file rotation },
 	{ 'T', duration,	CONFIG_DEC, {}, NULL,capture duration in seconds },
 	{ 'c', count, CONFIG_DEC, {}, NULL,packet count limit },
 	{ 'H', headersonly,   CONFIG_BOOL,{}, 0, dump headers only },
@@ -174,6 +175,7 @@
 	pa.dev = cfgopt_get_str_dup(cfg, device);
 	pa.bpf_string = cfgopt_get_str_dup(cfg, bpf);
 	pcapdump_filefmt = cfgopt_get_str_dup(cfg, filefmt);
+	pa.kickin = cfgopt_get_str_dup(cfg, kick);
 
 	pa.promisc = cfgopt_get_bool(cfg, promisc);
 	pa.snaplen = cfgopt_get_num(cfg, snaplen);
@@ -294,8 +296,9 @@
 }
 
 static void reset_dump(void){
-	if(pa.dumper)
-		pcapnet_close_dump(pa);
+if(pa.dumper) {
+	  pcapnet_close_dump(pa);
+	}
 	char *fname;
 	CALLOC(fname, FNAME_MAXLEN);
 
@@ -315,6 +318,7 @@
 		cfgopt_get_str(cfg, owner),
 		cfgopt_get_str(cfg, group)
 	);
+	pa.fname_out = fname;
 	pcapnet_init_dumpfd(pa, fd);
 	DEBUG(opened %s, fname);
 }
diff -ru pcaputils-0.8/util/pcapnet.c pcaputils-AFNIC/util/pcapnet.c
--- pcaputils-0.8/util/pcapnet.c	2009-05-10 01:10:01.0 +0200
+++ pcaputils-AFNIC/util/pcapnet.c	2009-09-17 14:41:52.0 +0200
@@ -39,6 +39,8 @@
 #include pcapnet.h
 #include util.h
 
+#define KICKIN_MAXLEN 1024
+
 /* functions */
 
 void pcapnet_load_cfg(pcap_args_t *pa, cfgopt_t *cfg){
@@ -409,12 +411,28 @@
 }
 
 void pcapnet_close_dump(pcap_args_t *pa){
+char *cmd = malloc(KICKIN_MAXLEN);
+	char *dump_name;
 	if(pa-dumper){
-		if(pa-fname_out)
+	  if(pa-fname_out) {
 			DEBUG(closing pcap file %s, pa-fname_out);
-		pcap_dump_flush(pa-dumper);
-		pcap_dump_close(pa-dumper);
-		pa-dumper = NULL;
+			dump_name = strdup(pa-fname_out);
+	  }
+	  else {
+		ERROR(Unknown capture file for the kick-in option);
+	  }
+	  pcap_dump_flush(pa-dumper);
+	  pcap_dump_close(pa-dumper);
+	  pa-dumper = NULL;
+	  if (pa-kickin != NULL) {
+		if (snprintf(cmd, KICKIN_MAXLEN, %s %s , pa-kickin, dump_name) = 0){
+		  ERROR(cannot create the command to kick in);
+		}
+		DEBUG(running \%s\, cmd);
+		system(cmd);
+		free(cmd);
+		free(dump_name);
+	  }
 	}
 }
 
diff -ru pcaputils-0.8/util/pcapnet.h pcaputils-AFNIC/util/pcapnet.h
--- pcaputils-0.8/util/pcapnet.h	2009-05-10 01:10:01.0 +0200
+++ pcaputils-AFNIC/util/pcapnet.h	2009-09-17 14:48:37.0 +0200
@@ -71,6 +71,7 @@
 	int snaplen;
 	int to_ms;
 	pcap_dumper_t *dumper;
+	char *kickin;
 	pcap_t *handle;
 	pcap_t *handle_out;
 } pcap_args_t;


Bug#545985: pcaputils: IWBN to have an option to run a program after file rotation in pcapdump

2009-09-10 Thread Stephane Bortzmeyer
Package: pcaputils
Version: 0.8-1
Severity: wishlist


It would be nice to have an option of pcapdump to run a given program
after the file rotation, with the name of the file being passed as a
parameter to the program.

I suggest to name the option -k (to kick in, I presume), after the
similar option of dnscap. I quote dnscap's man page:

 -k cmd  After each dump file specified by -w is closed, this command
 will be executed in a nonblocking subprocess with the file
 name as its one argument.  It's expected that this command
 will be a shell script that submits the finished file to a
 batch processing analytics system.  Note that without -k, the
 program will exit at the first output closure due to -c or
 -t.

Security note: pcapdump typically runs as root. Either we need another
option, to switch to another user before running the program, or we
simply decide that root, being a Big Boy, checks the program before
running pcapdump -k.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages pcaputils depends on:
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libjudydebian11.0.5-1C library for creating and accessi
ii  libpcap0.81.0.0-2system interface for user-level pa

pcaputils recommends no packages.

pcaputils suggests no packages.

-- no debconf information



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



Bug#543500: MkProg: hmake: the compiler 'ghc' is not known.

2009-08-25 Thread Stephane Bortzmeyer
Package: hat
Version: 2.05+rerolled-7
Severity: minor


The man page says:

   -ghc   Use the Glasgow ghc Haskell compiler.

But the program fails:

% hmake -ghc -hat  Andouille.hs 
MkProg: hmake: the compiler 'ghc' is not known.

Stop - hmake dependency error.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages hat depends on:
ii  libc62.9-23  GNU C Library: Shared libraries
ii  libghc6-hat-dev  2.05+rerolled-7 Haskell source-level tracer librar
ii  libglib2.0-0 2.20.4-1The GLib library of C routines
ii  libgmp3c22:4.3.1+dfsg-3  Multiprecision arithmetic library
ii  libreadline5 5.2-5   GNU readline and history libraries
ii  xterm244-2   X terminal emulator

Versions of packages hat recommends:
ii  hmake 3.13-0.1   The Haskell Make System

hat suggests no packages.

-- no debconf information



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



Bug#529820: Your patch has been committed

2009-06-30 Thread Stephane Bortzmeyer
r426 in the upstream Subversion. It seems to work, thanks, but I have
to test it for the old systems where gnutls does not use pkgconfig.



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



Bug#529920: 0.28.4-2 confirmed working on amd64

2009-06-09 Thread Stephane Bortzmeyer
On an Opteron/amd64 machine, after upgrading to squeeze, I had the same bug.

Compiling 0.28.4-2 from sources in sid solved the issue.

Stock Linux kernel from squeeze.

% uname -a
Linux jezabel 2.6.26-2-amd64 #1 SMP Wed May 13 15:37:46 UTC 2009 x86_64 
GNU/Linux

% gcc --version
gcc (Debian 4.3.3-10) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.




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



Bug#530497: etckeeper: Spurious error message when git is not installed

2009-05-25 Thread Stephane Bortzmeyer
Package: etckeeper
Version: 0.36
Severity: minor


% sudo aptitude install etckeeper   
...
Get:1 http://debian.ens-cachan.fr sid/main etckeeper 0.36 [28.7kB]
Fetched 28.7kB in 0s (513kB/s)   
Preconfiguring packages ...
Selecting previously deselected package etckeeper.
(Reading database ... 55549 files and directories currently installed.)
Unpacking etckeeper (from .../etckeeper_0.36_all.deb) ...
Processing triggers for man-db ...
Setting up etckeeper (0.36) ...
/etc/etckeeper/init.d/40vcs-init: line 5: git: command not found
etckeeper init failed; run it by hand

AFAIK, etckeeper can run with other VCS than git. That's probably why
it does not Depends: on git. But, in that case, it should not complain
that git is missing.

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

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages etckeeper depends on:
ii  darcs 2.2.0-1a distributed, interactive, smart 
ii  debconf [debconf-2.0] 1.5.26 Debian configuration management sy

Versions of packages etckeeper recommends:
ii  cron  3.0pl1-106 process scheduling daemon

etckeeper suggests no packages.

-- debconf information:
  etckeeper/commit_failed:
  etckeeper/purge: true



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



Bug#530534: iputils-tracepath: tracepath6 -n: Resolver Error 0 (no error)

2009-05-25 Thread Stephane Bortzmeyer
Package: iputils-tracepath
Version: 3:20071127-1
Severity: normal


% tracepath6 -n www.ietf.org 
getaddrinfo: Resolver Error 0 (no error)


Same thing for every other target. Without -n, it works fine.

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

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages iputils-tracepath depends on:
ii  libc6 2.9-12 GNU C Library: Shared libraries

iputils-tracepath recommends no packages.

Versions of packages iputils-tracepath suggests:
ii  traceroute2.0.12-2   Traces the route taken by packets 

-- no debconf information



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



Bug#524981: xmldiff: IndexError when comparing two files which have namespaces

2009-04-21 Thread Stephane Bortzmeyer
Package: xmldiff
Version: 0.6.8-4
Severity: normal


% xmldiff example.xml example1.xml
[append-first, /,
Traceback (most recent call last):
  File /usr/bin/xmldiff, line 4, in module
main.run()
  File /usr/lib/python2.5/site-packages/xmldiff/main.py, line 255, in run
encoding, html)
  File /usr/lib/python2.5/site-packages/xmldiff/main.py, line 117, in 
process_files
strategy.process_trees(tree1, tree2)
  File /usr/lib/python2.5/site-packages/xmldiff/fmes.py, line 104, in 
process_trees
self._formatter.end()
  File /usr/lib/python2.5/site-packages/xmldiff/format.py, line 80, in end
self.format_action(action)
  File /usr/lib/python2.5/site-packages/xmldiff/format.py, line 105, in 
format_action
xml_print(action[A_N2])
  File /usr/lib/python2.5/site-packages/xmldiff/objects.py, line 180, in 
xml_print
_xml_print_internal_format(node, indent, stream)
  File /usr/lib/python2.5/site-packages/xmldiff/objects.py, line 191, in 
_xml_print_internal_format
n[N_CHILDS][0][N_VALUE])
IndexError: list index out of range

The first file is:

% cat example.xml
ns1:foo xmlns:ns1=http://foo.com/foo;
ns1:barHello/ns1:bar
/ns1:foo

The second:

% cat example1.xml
foo xmlns=http://foo.com/foo;
barHello/bar
/foo

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

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages xmldiff depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  python2.5.2-3An interactive high-level object-o
ii  python-central0.6.8  register and build utility for Pyt

xmldiff recommends no packages.

Versions of packages xmldiff suggests:
pn  python-psyco  none (no description available)
pn  xmldiff-xmlrevnone (no description available)

-- no debconf information



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



Bug#524453: ack-grep: --type-add not recognized when in .ackrc file?

2009-04-17 Thread Stephane Bortzmeyer
Package: ack-grep
Version: 1.80-1
Severity: normal


I can use --type-add from the command line:

% ack-grep --type-add docbook=.db  --docbook glossary 
ack-grep: --type-add: Type docbook does not exist, creating with .db ...
Formations/bhubaneshwar/mail/mail.db
25:glossary id=glossary
54:/glossary

AFNIC/NIC-generique/HOWTO/HOWTO.db
776:  glossary id=glossary
883:  /glossary

...

But, if I put the same option in my ~/.ackrc file, it fails:

~ % cat .ackrc
--type-add docbook=.db


~ % ack-grep --docbook glossary
Unknown option: type-add docbook
Unknown option: docbook
ack-grep: See ack --help or ack --man for options.


Other options, in .ackrc, are recognized without problems.


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

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages ack-grep depends on:
ii  libfile-next-perl 1.02-1 File-finding iterator
ii  perl  5.10.0-19  Larry Wall's Practical Extraction 

ack-grep recommends no packages.

ack-grep suggests no packages.

-- no debconf information



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



Bug#521158: pcaputils: Wrong description in pcappick man page

2009-03-25 Thread Stephane Bortzmeyer
Package: pcaputils
Version: 0.7-1
Severity: minor


pcappick(1) says:

DESCRIPTION
   pcappick  filters  an input pcap file based on a file containing IP ad-
   dresses to be matched.

Which does not fit the summary in the NAME section. I believe there
was an incorrect copy-and-paste of pcapip(1).

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

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages pcaputils depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libjudydebian11.0.5-1C library for creating and accessi
ii  libpcap0.80.9.8-5system interface for user-level pa

pcaputils recommends no packages.

pcaputils suggests no packages.

-- no debconf information



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



Bug#520995: Files to reproduce the bug and a workaround

2009-03-25 Thread Stephane Bortzmeyer
The two attached files allow to reproduce the bug easily. The XSLT
stylesheet no-decl.xsl works fine with xsltproc and Sablotron (no XML
declaration is produced), while it fails with test-nodecl.py.

A workaround I use is to use the children attribute:

html_results = html_style.applyStylesheet(xml_document, None)
# html_results contain the erroneous XML declaration
html_results_ok = html_results.children
# html_results_ok does NOT contain the erroneous XML declaration


no-decl.xsl
Description: XML document
import libxml2
import libxslt

xml = ac33/cText/a

styledoc = libxml2.parseFile(no-decl.xsl)
style = libxslt.parseStylesheetDoc(styledoc)
doc = libxml2.parseMemory(xml, len(xml)) # Raises libxml2.parserError if not well-formed
result = style.applyStylesheet(doc, None)
i = 0
for node in result:
print \n%i (%s)  %s\n % (i, node.name, node)
i = i + 1
print result.children


Bug#520995: python-libxslt1: Does not honor xsl:output omit-xml-declaration=yes/

2009-03-24 Thread Stephane Bortzmeyer
Package: python-libxslt1
Version: 1.1.24-2
Severity: normal


When a XSLT stylesheet includes:

  xsl:output omit-xml-declaration=yes/

libxslt still includes the XML declaration :-(

Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
[GCC 4.3.2] on linux2
...
 import libxml2
 import libxslt
 xml_document = libxml2.parseFile(traceroute.xml)
 html_styledoc = libxml2.parseFile(snippet-traceroute2html.xsl)
 html_style = libxslt.parseStylesheetDoc(html_styledoc)
 html_results = html_style.applyStylesheet(xml_document, None)
 print html_results
?xml version=1.0?
div xmlns=http://www.w3.org/1999/xhtml; class=traceroute-root
...

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

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-libxslt1 depends on:
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libxslt1.1 1.1.24-2  XSLT processing library - runtime 
ii  python 2.5.2-3   An interactive high-level object-o
ii  python-libxml2 2.6.32.dfsg-5 Python bindings for the GNOME XML 
ii  python-support 0.8.4 automated rebuilding support for P

python-libxslt1 recommends no packages.

python-libxslt1 suggests no packages.

-- no debconf information



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



Bug#520995: [xml/sgml-pkgs] Bug#520995: python-libxslt1: Does not honor xsl:output omit-xml-declaration=yes/

2009-03-24 Thread Stephane Bortzmeyer
On Tue, Mar 24, 2009 at 10:19:31AM +0100,
 Mike Hommey m...@glandium.org wrote 
 a message of 15 lines which said:

  libxslt still includes the XML declaration :-(
 
 What about xsltproc your.xsl your.xml ?

works fine:

% xsltproc snippet-traceroute2html.xsl traceroute.xml
div xmlns=http://www.w3.org/1999/xhtml; class=traceroute-root
h2Traceroute: Test to www.enst.fr/h2
...



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



Bug#511326: pcaputils: Typo in man page of pcapdump

2009-01-09 Thread Stephane Bortzmeyer
Package: pcaputils
Version: 0.7-1
Severity: minor

 
man page pcapdump(1) says:

See  /usr/share/doc/pcaputils/examples/eth0 for an example.

But the actual file is /usr/share/doc/pcaputils/examples/pcapdump/eth0


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

Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages pcaputils depends on:
ii  libc6 2.7-16 GNU C Library: Shared libraries
ii  libjudydebian11.0.5-1C library for creating and accessi
ii  libpcap0.80.9.8-5system interface for user-level pa

pcaputils recommends no packages.

pcaputils suggests no packages.

-- no debconf information



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



Bug#408096: Bug still present, and quite annoying

2008-12-02 Thread Stephane Bortzmeyer
I confirm that the bug is still there in lenny and that it is not
minor. We recently experienced an IPv6 outage and, during the problem,
our whois server was not available at all from IPv6-enabled Debian
machines:

% whois -h whois.nic.fr toto.fr 
Timeout.




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



Bug#505437: tinyca: No way to create a private key without password

2008-11-12 Thread Stephane Bortzmeyer
Package: tinyca
Version: 0.7.5-2
Severity: wishlist


There is apparently no way to generate a private key without a
password? This is common for Internet servers, where you want the
server to be able to start without someone sitting at the console.

It works with OpenSSL but TinyCA always tell me I must provide a password :-(

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

Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages tinyca depends on:
ii  libgtk2-perl  1:1.190-1  Perl interface to the 2.x series o
ii  liblocale-gettext-perl1.05-4 Using libc functions for internati
ii  openssl   0.9.8g-13  Secure Socket Layer (SSL) binary a

Versions of packages tinyca recommends:
ii  zip   2.32-1 Archiver for .zip files

tinyca suggests no packages.

-- no debconf information



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



Bug#454380: Workaround with symbolic links

2008-11-12 Thread Stephane Bortzmeyer
In the mean time, I worked around the bug by using a symbolic link
from ~/.TinyCA to the real location.



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



Bug#505434: tinyca: Does not escape special characters when calling OpenSSL

2008-11-12 Thread Stephane Bortzmeyer
Package: tinyca
Version: 0.7.5-2
Severity: normal


My departement is RD (Research and Development) and TinyCA apparently
calls OpenSSL without bothering to escape the special
characters. Creation of the CA then fails:

DEBUG call: /usr/bin/openssl req -new -keyform PEM -outform PEM -passin 
env:SSLPASS -config /home/bortzmeyer/.TinyCA/RD/openssl.cnf -out 
/home/bortzmeyer/.TinyCA/RD/cacert.req -key 
/home/bortzmeyer/.TinyCA/RD/cacert.key -sha1
DEBUG: add to dn: FR
DEBUG: add to dn: Ile-de-France
DEBUG: add to dn: Saint-Quentin-en-Yvelines
DEBUG: add to dn: AFNIC
DEBUG: add to dn: RD
DEBUG: add to dn: AFNIC Research  Development 
DEBUG: add to dn: [EMAIL PROTECTED]
DEBUG: add to dn: 
DEBUG: add to dn: 
DEBUG return: /usr/bin/openssl req -new -keyform PEM -outform PEM -passin 
env:SSLPASS -config /home/bortzmeyer/.TinyCA/RD/openssl.cnf -out 
/home/bortzmeyer/.TinyCA/RD/cacert.req -key 
/home/bortzmeyer/.TinyCA/RD/cacert.key -sha1

sh: D/openssl.cnf: No such file or directory
sh: D/cacert.req: No such file or directory
sh: D/cacert.key: No such file or directory
error on line -1 of /home/bortzmeyer/.TinyCA/R
1779:error:02001002:system library:fopen:No such file or 
directory:bss_file.c:122:fopen('/home/bortzmeyer/.TinyCA/R','rb')


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

Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages tinyca depends on:
ii  libgtk2-perl  1:1.190-1  Perl interface to the 2.x series o
ii  liblocale-gettext-perl1.05-4 Using libc functions for internati
ii  openssl   0.9.8g-13  Secure Socket Layer (SSL) binary a

Versions of packages tinyca recommends:
ii  zip   2.32-1 Archiver for .zip files

tinyca suggests no packages.

-- no debconf information



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



Bug#486543: Last version of audacious-plugins and still the bug

2008-07-16 Thread Stephane Bortzmeyer
[Message sent to several bugs because they seem the same.]

I just aptitude update  aptitude install audacious audacious-plugins
my testing machine and I still get the same bug.

Package: audacious
Architecture: i386
Version: 1.5.1-1

Package: audacious-plugins
Architecture: i386
Version: 1.5.0-2

Under gdb, I get:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40c79640 (LWP 17152)]
0x080abdc4 in ?? ()
(gdb) list
No symbol table is loaded.  Use the file command.
(gdb) where
#0  0x080abdc4 in ?? ()
#1  0x4136019c in ?? () from /usr/lib/audacious/Input/madplug.so
#2  0x08068980 in ?? ()
#3  0xbfd6cf58 in ?? ()
#4  0x080acb98 in ?? ()
#5  0xbfd6cf56 in ?? ()
#6  0x0002 in ?? ()
#7  0x0001 in ?? ()
#8  0x0008 in ?? ()
#9  0x085c3918 in ?? ()
#10 0x42da4ef8 in ?? ()
#11 0xbfd6cf58 in ?? ()
#12 0x080689bf in ?? ()
#13 0x4136019c in ?? () from /usr/lib/audacious/Input/madplug.so
#14 0x08068980 in ?? ()
#15 0xbfd6d0d8 in ?? ()
#16 0x4135dcc1 in ?? () from /usr/lib/audacious/Input/madplug.so
#17 0x085e18c0 in ?? ()
#18 0x0008 in ?? ()
#19 0x in ?? ()



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



Bug#487929: emacs21: Random endless loops over gettimeofday and setitimer

2008-06-25 Thread Stephane Bortzmeyer
Package: emacs21
Version: 21.4a+1-5.4
Severity: normal


About once a day (and I do not know how to reproduce it at will),
Emacs starts an endless loop, not refreshing its screen and not
accepting requests.

kill is useless, I must kill -KILL, losing text :-(

ps shows:

stephane 11128  0.0  0.2  12176  7752 pts/7S10:26   0:00 emacs 
/home/stephane/Mail/compose/mutt-ludwigVII-1000-11103-1 --eval (setq 
backup-inhibited t) --funcall=post-mode --funcall=turn-on-auto-fill

When it occurs, strace shows:

--- SIGALRM (Alarm clock) @ 0 (0) ---
gettimeofday({1214382705, 259392}, NULL) = 0
gettimeofday({1214382705, 259441}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, NULL) = 0
sigreturn() = ? (mask now [IO])
futex(0xb7cd5140, FUTEX_WAIT, 2, NULL)  = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock) @ 0 (0) ---
gettimeofday({1214382705, 267439}, NULL) = 0
gettimeofday({1214382705, 267487}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, NULL) = 0
sigreturn() = ? (mask now [IO])
futex(0xb7cd5140, FUTEX_WAIT, 2, NULL)  = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock) @ 0 (0) ---
gettimeofday({1214382705, 275483}, NULL) = 0
gettimeofday({1214382705, 275531}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, NULL) = 0
sigreturn() = ? (mask now [IO])
futex(0xb7cd5140, FUTEX_WAIT, 2, NULL)  = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock) @ 0 (0) ---
gettimeofday({1214382705, 283531}, NULL) = 0
gettimeofday({1214382705, 283579}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, NULL) = 0
sigreturn() = ? (mask now [IO])
futex(0xb7cd5140, FUTEX_WAIT, 2, NULL)  = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock) @ 0 (0) ---
gettimeofday({1214382705, 291698}, NULL) = 0
gettimeofday({1214382705, 291747}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 1000}}, NULL) = 0
sigreturn() = ? (mask now [IO])

I am not sure how to use gdb to report anything useful. If I attach
gdb to emacs, all I get is:

(gdb) where
#0  0xb7fd1410 in ?? ()
#1  0xbf98b44c in ?? ()
#2  0x0002 in ?? ()
#3  0x in ?? ()

[Tested as an X window only. It seems to appear only when run from
mutt, the actual command line is in the ps output above.]

I use the same setup for many years and the problem appeared only with lenny.

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

Kernel: Linux 2.6.18-6-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages emacs21 depends on:
ii  emacs21-bin-common 21.4a+1-5.4   The GNU Emacs editor's shared, arc
ii  libc6  2.7-10GNU C Library: Shared libraries
ii  libgif44.1.6-4   library for GIF images (library)
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libjpeg62  6b-14 The Independent JPEG Group's JPEG 
ii  libncurses55.6+20080308-1Shared libraries for terminal hand
ii  libpng12-0 1.2.27-1  PNG library - runtime
ii  libsm6 2:1.0.3-1+b1  X11 Session Management library
ii  libtiff4   3.8.2-10  Tag Image File Format (TIFF) libra
ii  libx11-6   2:1.1.4-2 X11 client-side library
ii  libxext6   2:1.0.4-1 X11 miscellaneous extension librar
ii  libxmu62:1.0.4-1 X11 miscellaneous utility library
ii  libxpm41:3.5.7-1 X11 pixmap library
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii  xaw3dg 1.5+E-15  Xaw3d widget set
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

emacs21 recommends no packages.

-- no debconf information



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



Bug#487929: emacs21: Random endless loops over gettimeofday and setitimer

2008-06-25 Thread Stephane Bortzmeyer
On Wed, Jun 25, 2008 at 12:32:17PM +0200,
 Sven Joachim [EMAIL PROTECTED] wrote 
 a message of 50 lines which said:

 forcemerge 278382 487929

I'm not sure it is exactly the same. #278382 is quite old and my bug
appeared only in lenny.

 But probably you'd be waisting your time, bugs in emacs21 will very
 likely not get fixed anymore.  Please switch to emacs22

Done, we'll see.



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



Bug#484688: monshow --full does not show anything more

2008-06-06 Thread Stephane Bortzmeyer
On Fri, Jun 06, 2008 at 08:50:17AM +0200,
 Dario Minnucci (midget) [EMAIL PROTECTED] wrote 
 a message of 23 lines which said:

 Do you have any service configured in your /etc/mon/mon.cf file?

No, I use mon.cf.m4 (which worked before).
 
 The only way I could get an empty output like yours is using the
 default /etc/mon/mon.cf provided by a fresh installation.

OK, got it, I add to change the /etc/default/mon (which worked with
sarge) to:

# Deamon options
DAEMON_OPTS=-M -f -c /etc/mon/mon.cf.m4

Strange but now it works. Thanks for the help.



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



Bug#484688: monshow --full does not show anything more

2008-06-05 Thread Stephane Bortzmeyer
Package: mon
Version: 0.99.2-12
Severity: normal


The man page says:

   --full Instead of showing only failed services, show all services no 
matter the state.

And, indeed, it worked with sarge. But, with lenny:

~ % monshow 

 server: localhost
   time: Thu Jun  5 17:25:07 2008
  state: scheduler running

All systems OK

~ % monshow --full

 server: localhost
   time: Thu Jun  5 17:25:11 2008
  state: scheduler running

All systems OK


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

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages mon depends on:
ii  adduser   3.107  add and remove users and groups
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libmon-perl   0.11-4 mon Perl modules for clients and s
ii  libtime-period-perl   1.20-8 Perl library for testing if a time
ii  perl [libtime-hires-perl] 5.10.0-10  Larry Wall's Practical Extraction 

Versions of packages mon recommends:
ii  fping   2.4b2-to-ipv6-15 sends ICMP ECHO_REQUEST packets to
ii  libauthen-pam-perl  0.16-1.1+b1  Perl interface to PAM library
ii  libfilesys-diskspace-pe 0.05-11  fetch filesystem size and usage in
ii  libnet-dns-perl 0.63-1+b1Perform DNS queries from a Perl sc
ii  libnet-ldap-perl1:0.34-1.1   A Client interface to LDAP servers
ii  libnet-telnet-perl  3.03-3   Script telnetable connections
ii  libsnmp-perl5.4.1~dfsg-7+b1  SNMP (Simple Network Management Pr
ii  libstatistics-descripti 2.6-5Perl module for basic descriptive 
ii  perl-modules [libnet-pe 5.10.0-10Core Perl modules

-- no debconf information



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



Bug#481411: Bug reported upstream

2008-05-23 Thread Stephane Bortzmeyer
I did not notice so, but it has already been reported upstream:

https://savannah.gnu.org/bugs/index.php?18882

Without any result, alas.




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



Bug#481411: Portable bug

2008-05-16 Thread Stephane Bortzmeyer
I have been able to reproduce the bug on Gentoo and FreeBSD, so it it
probably an upstream bug.




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



Bug#481411: A screen started with -d -m silently ignores -X exec

2008-05-15 Thread Stephane Bortzmeyer
Package: screen
Version: 4.0.3-0.3+b1
Severity: normal


When I create a screen with -d -m, sending a -X exec is silently :-(
ignored.

If there is at least one cycle of attach / detach, the -X exec works.

I do not find it documented and it is annoying if I want to run a
screen unattended at startup. At the very least, the -X exec should
send an error message.

How to reproduce:

% screen -d -m
% screen -X exec yes
% screen -r
[yes was not executed]

% screen -d -m  
% screen -r
Control-A D
[detached]
% screen -X exec yes
% screen -r 
[This time, yes is running]

[My machine is an etch but I tested that sid has exactly the same issue.]

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

Versions of packages screen depends on:
ii  base-passwd3.5.11Debian base system master password
ii  debconf [debconf-2.0]  1.5.11etch1   Debian configuration management sy
ii  libc6  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libncursesw5   5.5-5 Shared libraries for terminal hand
ii  libpam0g   0.79-5Pluggable Authentication Modules l
ii  passwd 1:4.0.18.1-7  change and administer password and

screen recommends no packages.

-- debconf information:
  screen/old_upgrade_prompt: false



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



Bug#475969: Info received (May be an issue with the guest OS)

2008-04-15 Thread Stephane Bortzmeyer
close 475969
thanks

After more test, I confirm, this was a problem with the guest
OS. Remaking it from scratch solved the problem. Sorry for the false
alarm.




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



Bug#476000: The issue was with the guest OS, not with kvm

2008-04-15 Thread Stephane Bortzmeyer
close 476000
thanks

After more test, I confirm, this was a problem with the guest
OS. Remaking it from scratch solved the problem. Sorry for the false
alarm.





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



Bug#475529: darcs push|pull with ssh stops silently

2008-04-14 Thread Stephane Bortzmeyer
On Fri, Apr 11, 2008 at 05:05:14PM +0200,
 Julien Cristau [EMAIL PROTECTED] wrote 
 a message of 16 lines which said:

 Apparently it's --no-ssh-cm.

Same problem, even after 'aptitude dist-upgrade' this morning.

% darcs pull --no-ssh-cm 
%

(There *are* patches to pull.)



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



  1   2   >