Bug#1043023: libgdbm6:amd64: /usr/lib/x86_64-linux-gnu/libgdbm.so.6 in Debian bullseye uses huge amount of memory

2023-08-04 Thread Marc Schaefer
Package: libgdbm6
Version: 1.19-2
Severity: important

Dear Maintainer,

I run a few DBM-intensive applications. They manipulate huge DBMs, but
they work usually like a charm:

15168 mojolic+  20   0   90.8g 156260   5460 S   0.0   3.0   0:00.30 
known_passwords
15159 mojolic+  20   0   16.6g  63260   6572 S   0.0   1.2   0:00.15 
usenet-fr.pl

(as you can see they allocate a lot of virtual memory but do not really make 
use of it)

They usually startup in a few seconds and are very fast when started. They are
written in Perl in the Mojolicious framework, I use perlbrew.

I just migrated from buster to bullseye and it no longer works at all. The
script never complete opening of the DBMs, and uses insanely huge amount of
memory (not only virtual).

This is the same with the buster-compiled perl-5.36.1-2023-05-14 or with the
bullseye just recompiled perl-5.38.0-2023-08-04.

However, there is a simple work-around:

   export LD_LIBRARY_PATH=/home/mojolicious/tmp-libs

where this directory contains:

lrwxrwxrwx  1 rootroot23 Mar 12  2019 libgdbm_compat.so -> 
libgdbm_compat.so.4.0.0
lrwxrwxrwx  1 rootroot23 Mar 12  2019 libgdbm_compat.so.4 
-> libgdbm_compat.so.4.0.0
-rw-r--r--  1 rootroot 14104 Mar 12  2019 
libgdbm_compat.so.4.0.0.O1
lrwxrwxrwx  1 rootroot16 Mar 12  2019 libgdbm.so -> 
libgdbm.so.6.0.0
lrwxrwxrwx  1 rootroot16 Mar 12  2019 libgdbm.so.6 -> 
libgdbm.so.6.0.0
-rw-r--r--  1 rootroot 63512 Mar 12  2019 libgdbm.so.6.0.0

As you can see, just overriding libgdbm.so.6.0.0 through LD_LIBRARY_PATH with
the buster version of the library is enough (I have tested that renaming
libgdbm_compat.so.4.0.0 to libgdbm_compat.so.4.0.0.O1 still fixes the problem,
but renaming libgdbm.so.6.0.0 to libgdbm.so.6.0.0.O1 makes the problem
reappear). The issue seems to be in the libgdbm6 package, very specifically in
libgdbm.so.6.0.0.

With the work-around, things seem then to work again like a charm.

As an additional note, there seems to have been an issue like this with Fedora:

   https://github.com/Perl/perl5/issues/18884

They seem to have a patch for GDBM as it is not linked to Perl in any way:

   https://github.com/Perl/perl5/issues/18884#issuecomment-860437280

Could you look into this?

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

Kernel: Linux 4.19.0-25-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libgdbm6:amd64 depends on:
ii  libc6  2.31-13+deb11u6

libgdbm6:amd64 recommends no packages.

Versions of packages libgdbm6:amd64 suggests:
pn  gdbm-l10n  

-- no debconf information



Bug#1011413: inn2: nnrpd as distributed does not support $modify_headers, recompiled does

2023-01-29 Thread Marc Schaefer
You can close this bug indeed! Forgot to tell you that it works ok on bullseye.

28 janv. 2023 23:15:24 Marco d'Itri :

> On May 24, Marco d'Itri  wrote:
> 
>>> Package: inn2
>>> Version: 2.6.3-1+deb10u2
>> Sorry, I have no plans to spend time debugging oldstable but please let
>> me know if this affects stable too.
> Can you reproduce this on a modern system?
> 
> -- 
> ciao,
> Marco



Bug#1011413: inn2: nnrpd as distributed does not support $modify_headers, recompiled does

2022-05-22 Thread Marc SCHAEFER
Package: inn2
Version: 2.6.3-1+deb10u2
Severity: normal

Dear Maintainer,

I do this in my /etc/news/filter/filter_nnrpd.pl's filter_post:

   $modify_headers = 1;
   $hdr{'X-test'} = "42";

   return "";

However,

   - with stock INN2 package, the X-test header does not get added
   - doing apt-get source inn2 then dpkg-buildpackage -us -uc, then
 starting under news the generated /debian/inn2/usr/lib/news/bin/nnrpd -p 
42119 -D
 I can POST an article which will get the X-test header added

So, maybe there is some bizarre compatibility problem with my Perl installation 
and INN2?
I however just have normal i386 debian buster, except this change:

$ diff ./inn2-2.6.3/debian/inn2/usr/share/perl5/INN/Config.pm 
/usr/share/perl5/INN/Config.pm
123c123
< our $gpg = '/usr/bin/gpg1';
---
> our $gpg = '/usr/bin/gpg';
125c125
< our $pgp = '/usr/bin/pgp';
---
> our $pgp = '';

Thank you for any idea.

Have a nice sunday.

-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 4.19.0-20-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages inn2 depends on:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1
ii  inn2-inews  2.6.3-1+deb10u2
ii  libc6   2.28-10+deb10u1
ii  libdb5.35.3.28+dfsg1-0.5
ii  libmime-tools-perl  5.509-1
ii  libpam0g1.3.1-5
ii  libperl5.28 5.28.1-6+deb10u1
ii  libsasl2-2  2.1.27+dfsg-1+deb10u2
ii  libssl1.1   1.1.1n-0+deb10u2
ii  lsb-base10.2019051400
ii  perl5.28.1-6+deb10u1
ii  perl-base [perlapi-5.28.1]  5.28.1-6+deb10u1
ii  postfix [mail-transport-agent]  3.4.14-0+deb10u1
ii  procps  2:3.3.15-2
ii  time1.7-25.1+b1
ii  zlib1g  1:1.2.11.dfsg-1+deb10u1

inn2 recommends no packages.

Versions of packages inn2 suggests:
ii  gnupg1  1.4.23-1
ii  libgd-perl  2.71-2
ii  libkrb5-3   1.17-3+deb10u3
ii  wget1.20.1-1.1

-- Configuration Files:
/etc/init.d/inn2 changed [not included]
/etc/logcheck/ignore.d.server/inn2 [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/inn2'
/etc/logcheck/violations.ignore.d/inn2 [Errno 13] Permission denied: 
'/etc/logcheck/violations.ignore.d/inn2'
/etc/news/control.ctl changed [not included]
/etc/news/expire.ctl changed [not included]
/etc/news/filter/filter_innd.pl changed [not included]
/etc/news/filter/filter_nnrpd.pl changed [not included]
/etc/news/incoming.conf changed [not included]
/etc/news/innfeed.conf changed [not included]
/etc/news/newsfeeds changed [not included]
/etc/news/nocem.ctl changed [not included]
/etc/news/readers.conf changed [not included]
/etc/news/subscriptions changed [not included]

-- debconf information:
  inn2/preinst-upgrade1: false
  inn2/preinst-upgrade-largefiles: false
  inn2/postinst-cannot-start:

-- debsums errors found:
debsums: changed file /usr/share/perl5/INN/Config.pm (from inn2 package)



Bug#1009751: onak's keyd uses 100% CPU

2022-04-16 Thread Marc SCHAEFER
Package: onak
Version: 0.5.0-1
Severity: important

Dear Maintainer,

on a buster system, keyd uses 100% CPU:

onak 30318 98.6  0.0   8864  4884 ?Rs   08:04   5:39 /usr/sbin/keyd 
-f

vz15:~# strace -p 30318 2>&1 | head -20
strace: Process 30318 attached
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])
accept(3, 0xffee6d8c, [110])= -1 EINVAL (Invalid argument)
_newselect(4, [3], NULL, NULL, NULL)= 1 (in [3])

This is in a LXC container running also on a buster host kernel 4.19.0-17-amd64.

Any idea what I should try?

Thank you.

-- System Information:
Debian Release: 10.12
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-20-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages onak depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10+deb10u1
ii  libcurl3-gnutls  7.64.0-4+deb10u2
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libnettle6   3.4.1-1+deb10u1
ii  libsystemd0  241-7~deb10u8
ii  perl 5.28.1-6+deb10u1

Versions of packages onak recommends:
ii  apache2 [httpd]  2.4.38-3+deb10u7

Versions of packages onak suggests:
pn  db-util  

-- no debconf information



Bug#980858: iputils-ping: ping handles link-local addresses in a too smart way

2021-01-25 Thread Marc SCHAEFER
On Mon, Jan 25, 2021 at 08:51:32AM -0800, Noah Meyerhans wrote:
> > It is incompatible with telnet and all other utilities I tried, which means
> > that debugging with ping now is moot.
> 
> It does not invalidate ping's usefulness for debugging.  When you
> specify a scope explicitly, it is respected.  This is exactly the
> behavior you need when debugging.

I meant:

you configure some service to access [fe80::1]:80

it does not work

you debug with ping fe80::1

it works.

Ok, you ponder. Hmm.  Maybe you think to use

   telnet fe80::1 80

and then you see it does not work and you pat yourself and add %eth1

With pre-buster behaviour, you immediately see the problem with ping.

> Right.  A scope is required in order to fully specify the address.
> That's clear enough.  However, there's nothing in there that forbids a
> client from choosing a scope based on routing rules or some other
> mechanism when a scope isn't explicitly provided by the user.

getaddrinfo(3) does not: it returns a zero scope id, most programs use
getaddrinfo(3) without any additional setting of the scope ID, unlike
ping.

Anyway, if you don't think this is a bug, no matter for me. I know now that
ping does not work like most programs with addresses that requires a
scope ID.

And it is now documented on bugs.debian.org if it needs to be.



Bug#980858: iputils-ping: ping handles link-local addresses in a too smart way

2021-01-25 Thread Marc SCHAEFER
On Sat, Jan 23, 2021 at 10:04:00AM -0800, Noah Meyerhans wrote:
> https://github.com/iputils/iputils/pull/100

Interesting. They interpret the fact that link-local works as expected as
`broken', and fixed it.

> I agree that this is the normal way of fully specifying a link-local
> address.  However, rfc 4291 does not prohibit inferring the scope based
> on routing tables, as far as I can tell, so I'm not sure that ping's
> behavior is outright wrong.

It is incompatible with telnet and all other utilities I tried, which means
that debugging with ping now is moot.

> If you can find text in the standards that indicates that ping is
> actually behaving incorrectly, then I'm very happy to raise this issue

Reading RFC-4291 [1], 2.5.6 (link-local addresses) and RFC-4007 [2] 6,
Zones Indices:

   Because the same non-global address may be in use in more than one
   zone of the same scope (e.g., the use of link-local address fe80::1
   in two separate physical links) and a node may have interfaces
   attached to different zones of the same scope (e.g., a router
   normally has multiple interfaces attached to different links), a node
   *requires* an internal means to identify to which zone a non-global
   address belongs.  This is accomplished by assigning, within the node,
   a distinct "zone index" to each zone of the same scope to which that
   node is attached, and by allowing all internal uses of an address to
   be qualified by a zone index.



Bug#980858: iputils-ping: ping handles link-local addresses in a too smart way

2021-01-23 Thread Marc SCHAEFER
Package: iputils-ping
Version: 3:20180629-2+deb10u1
Severity: wishlist

Dear Maintainer,

This is puzzling: 

  $ telnet fe80::1
   Trying fe80::1...
   telnet: Unable to connect to remote host: Invalid argument
   [ normal behaviour with link-local addresses ]

   schaefer@reliand:~$ telnet -6 fe80::1%eth1
   Trying fe80::1%eth1...
   [also ok: no error, NDP requests sent]

but:

   $ ping6 fe80::1
   PING fe80::1(fe80::1) 56 data bytes
   From fe80::9e8e:99ff:fe3c:5523%eth0: icmp_seq=1 Destination unreachable: 
Address unreachable

Link-local addresses are ambiguous: they lack the scope ID, unless you specify
the scope with a postfix %iface_name or %iface_id. So why does ping try to
guess which interface is used?

That's the only way it should work:

   $ ping6 fe80::1%eth1
   PING fe80::1%eth0(fe80::1%eth1) 56 data bytes

(or with the -I option).

The manpage says:
   -I interface
   interface is either an address, or an interface name. If interface
   is an address, it sets source address to specified interface
   address. If interface in an interface name, it sets source
   interface to specified interface. NOTE: For IPv6, when doing ping
   to a link-local scope address, link specification (by the
   '%'-notation in destination, or by this option) can be used but it
   is *no longer* required.

And yes, that wrong behaviour is new in buster (correct behaviour in stretch or
jessie).  Maybe that changes was upstream and not intentional (could be linked
to other types of non routed v6 addresses), but it is still puzzling.

There is a lot of of code in ping6_common.c that, if device is unset and
getaddrinfo(3) returns a zero scope ID, tries to probe a scope ID. I do not see
why ping should do that.

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iputils-ping depends on:
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libidn2-0   2.0.5-1+deb10u1
ii  libnettle6  3.4.1-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-2

iputils-ping suggests no packages.

-- no debconf information



Bug#970494: mailman: patch for French translation

2020-09-17 Thread Marc SCHAEFER
Package: mailman
Version: 1:2.1.29-1+deb10u1
Severity: minor

Dear Maintainer,

diff -uP /var/lib/mailman/messages/fr/LC_MESSAGES/mailman.po.distrib 
/var/lib/mailman/messages/fr/LC_MESSAGES/mailman.po
--- /var/lib/mailman/messages/fr/LC_MESSAGES/mailman.po.distrib 2020-04-24 
16:27:05.0 +0200
+++ /var/lib/mailman/messages/fr/LC_MESSAGES/mailman.po 2020-09-17 
10:33:21.478339614 +0200
@@ -8610,7 +8610,7 @@
 
 #: Mailman/Handlers/Emergency.py:30 Mailman/Handlers/Hold.py:58
 msgid "Your message was deemed inappropriate by the moderator."
-msgstr "Le modérateur à jugé votre message inapproprié."
+msgstr "Le modérateur a jugé votre message inapproprié."
 
 #: Mailman/Handlers/Hold.py:53
 msgid "Sender is explicitly forbidden"

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mailman depends on:
ii  apache2 [httpd]2.4.38-3+deb10u4
ii  cron [cron-daemon] 3.0pl1-134+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  logrotate  3.14.0-4
ii  lsb-base   10.2019051400
ii  python 2.7.16-1
pn  python-dnspython   
ii  ucf3.0038+nmu1

Versions of packages mailman recommends:
ii  postfix [mail-transport-agent]  3.4.14-0+deb10u1

Versions of packages mailman suggests:
pn  listadmin  
ii  lynx   2.8.9rel.1-3
pn  mailman3-full  
ii  spamassassin   3.4.2-1+deb10u2

-- Configuration Files:
/etc/logrotate.d/mailman changed [not included]

-- debconf information:
  mailman/gate_news: false
* mailman/create_site_list:
* mailman/queue_files_present: continue regardless
* mailman/used_languages: de en es fr it
* mailman/default_server_language: en
* mailman/site_languages: it, fr, es, de, en


Bug#969625: marco: Garbled window icons and window titles

2020-09-06 Thread Marc SCHAEFER
Package: marco
Version: 1.20.3-1
Severity: minor

Dear Maintainer,

old X11 utilities seem to have garbled window titles icon (grayed
out?), see capture here:

   https://login.alphanet.ch/~schaefer/tmp/garbled-window-icons-mate-buster.png

In addition, modern utilities such as Firefox have garbled titles
when resized to a small size with a long title, see capture here:

   
https://login.alphanet.ch/~schaefer/tmp/garbled-small-windows-title-mate-buster.png

This is independent of work-around in bug report Bug#969624.

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages marco depends on:
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtop-2.0-112.38.0-4
ii  libice6   2:1.0.9-2
ii  libmarco-private1 1.20.3-1
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  libsm62:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  marco-common  1.20.3-1
ii  mate-desktop-common   1.20.4-2
ii  zenity3.30.0-2

marco recommends no packages.

marco suggests no packages.

-- no debconf information



Bug#969624: marco: No old X11 utilities window titles

2020-09-06 Thread Marc SCHAEFER
Package: marco
Version: 1.20.3-1
Severity: normal

Dear Maintainer,

Old X11 utilities have no titles with marco, under system locale

LC_CTYPE=fr_CH.iso-8859-1
LC_COLLATE=fr_CH.iso-8859-1

Work-around (assuming both locales where generated):

# dpkg-divert --rename marco
# cat > /usr/bin/marco <

Bug#966919: irssi: non utf-8 locale input line shows utf-8 characters

2020-08-03 Thread Marc SCHAEFER
Package: irssi
Version: 1.2.0-2cril0
Severity: normal

Dear Maintainer,

Actually the report is done against the locally patched version already

Here is the patch debian/patches/99-non-utf8-locale-bad-edit-line-671

Description: Fixes UTF-8-in-latin1 display in the input line if locale non utf8
 With a non UTF-8 locale, the edit line on the bottom will display UTF-8
 characters encoded in Latin-1.

 See https://github.com/irssi/irssi/issues/1018.
 .
 irssi (1.2.0-2cril.0) unstable; urgency=medium
 .
   [ Marc Schaefer ]
   * apply patch https://github.com/irssi/irssi/issues/1018
Author: Marc Schaefer 
Origin: https://github.com/irssi/irssi/issues/1018
Bug: https://github.com/irssi/irssi/issues/1018
Last-Update: 2020-08-03

--- irssi-1.2.0.orig/src/fe-text/gui-entry.c
+++ irssi-1.2.0/src/fe-text/gui-entry.c
@@ -381,8 +381,14 @@ static void gui_entry_draw_from(GUI_ENTR
 
if (entry->hidden)
 g_string_append_c(str, ' ');
-   else if (unichar_isprint(c))
-   g_string_append_unichar(str, c);
+   else if (unichar_isprint(c)) {
+   if (entry->utf8) {
+   g_string_append_unichar(str, c);
+   }
+   else {
+   g_string_append_c(str, c);
+   }
+   }
else {
g_string_append_c(str, 4);
g_string_append_c(str, FORMAT_STYLE_REVERSE);



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages irssi depends on:
ii  libc6   2.28-10
ii  libglib2.0-02.58.3-2+deb10u2
ii  libperl5.28 5.28.1-6+deb10u1
ii  libssl1.1   1.1.1d-0+deb10u3
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  perl5.28.1-6+deb10u1
ii  perl-base [perlapi-5.28.1]  5.28.1-6+deb10u1

irssi recommends no packages.

Versions of packages irssi suggests:
pn  irssi-scripts  

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

-- no debconf information



Bug#965138: Unable to disable decoded IDN output in host

2020-07-31 Thread Marc SCHAEFER
On Tue, Jul 28, 2020 at 04:56:20PM +0200, Bernhard Schmidt wrote:
> Not sure whether we can backport this easily. The +noidnout suggestion
> is definitely bogus, that's dig style.

At least for me, I have a work-around in place.

Thank you and have a nice day.



Bug#965138: Unable to disable decoded IDN output in host

2020-07-16 Thread Marc SCHAEFER
Package: bind9-host
Version: 1:9.11.5.P4+dfsg-5.1+deb10u1
Severity: normal

Dear Maintainer,

Since buster, it seems that host insists in outputing a decoded version
of IDN domain names, and if the locale does not support it, it fails:

   schaefer@virtual:~$ env LC_CTYPE=C host xn--linux-neuchtel-lhb.ch
   host: Cannot represent 'xn--linux-neuchtel-lhb.ch.' in the current locale 
(string encoding error), use +noidnout or a different locale

However, the suggested option +nodinout does not work.

Then the manpage says:

> IDN SUPPORT
>If host has been built with IDN (internationalized domain name) 
> support, it can accept and display non-ASCII domain names.  host 
> appropriately converts character encoding of domain
>name before sending a request to DNS server or displaying a reply from 
> the server. If you'd like to turn off the IDN support for some reason, 
> defines the IDN_DISABLE environment
>variable. The IDN support is disabled if the variable is set when host 
> runs.

However:

   schaefer@virtual:~$ env LC_CTYPE=C IDN_DISABLE=1 host 
xn--linux-neuchtel-lhb.ch localhost  
   host: Cannot represent 'xn--linux-neuchtel-lhb.ch.' in the current locale 
(string encoding error), use +noidnout or a different locale

the only partial workaround I know is to change the locale, e.g.:

schaefer@virtual:~$ env LC_CTYPE=fr_CH.iso-8859-1 IDN_DISABLE=1 host 
xn--linux-neuchtel-lhb.ch localhost

But then you don't get the xn-- but you get the diacrictic version in the 
specified locale:

   linux-neuchâtel.ch has address 46.140.72.222

it would be nice to have a working way of disabling this new host behaviour.

Have a nice day.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bind9-host depends on:
ii  libbind9-161  1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libc6 2.28-10
ii  libcap2   1:2.25-2
ii  libcom-err2   1.44.5-1+deb10u3
ii  libdns11041:9.11.5.P4+dfsg-5.1+deb10u1
ii  libfstrm0 0.4.0-1
ii  libgeoip1 1.6.12-1
ii  libgssapi-krb5-2  1.17-3
ii  libidn2-0 2.0.5-1+deb10u1
ii  libisc11001:9.11.5.P4+dfsg-5.1+deb10u1
ii  libisccfg163  1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libjson-c30.12.1+ds-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  liblmdb0  0.9.22-1
ii  liblwres161   1:9.11.5.P4+dfsg-5.1+deb10u1
ii  libprotobuf-c11.3.1-1+b1
ii  libssl1.1 1.1.1d-0+deb10u3
ii  libxml2   2.9.4+dfsg1-7+b3

bind9-host recommends no packages.

bind9-host suggests no packages.

-- no debconf information



Bug#873816: bug is fixed in buster

2019-08-09 Thread Marc SCHAEFER
Hello,

that bug is fixed in buster BTW.



Bug#873816: texlive-base: Fonts handling broken in dvips?

2019-08-07 Thread Marc SCHAEFER
Hello,

Thank you for your support.

I still use jessie, intend to upgrade to buster soon.

On Wed, Aug 07, 2019 at 02:40:04PM +0200, Hilmar Preuße wrote:
> regenerated the ps file and noticed that everthing look now. Are you
> still able to reproduce the issue. If yes, please send:

Yes, the ps file still has the "fi" ligature missing, and the
font look ugly. DVI and PDF are ok.

> 1. grep cmssbx17 /var/lib/texmf/fonts/map/dvips/updmap/psfonts.map

cmssbx17 cmssbx17  2. Output of dvips run.

dvips demo.dvi
This is dvips(k) 5.994 Copyright 2014 Radical Eye Software (www.radicaleye.com)
' TeX output 2019.08.07:1532' -> demo.ps

. 



[1] 

> INPUT
> /home/schaefer/.texlive2016/texmf-var/fonts/tfm/public/sauter/cmssbx17.tfm
> INPUT
> /home/schaefer/.texlive2016/texmf-var/fonts/tfm/public/sauter/cmssbx17.tfm

~/.texlive2016 doesn't exist, but .texmf-var does.

If I remove this directory and retry, the problem in the .ps remains:

mv ~/.texmf-var ~/.texmf-var.OLD
latex demo.tex && dvips demo.dvi -o demo.ps && pdflatex demo.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2015/dev/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./demo.tex
LaTeX2e <2014/05/01>
Babel <3.9l> and hyphenation patterns for 79 languages loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
schaefer@reliand:/tmp/tt$ latex demo.tex && dvips demo.dvi -o demo.ps && 
pdflatex demo.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2015/dev/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./demo.tex
LaTeX2e <2014/05/01>
Babel <3.9l> and hyphenation patterns for 79 languages loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo))
kpathsea: Running mktextfm cmssbx17
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
input cmssbx17
This is METAFONT, Version 2.7182818 (TeX Live 2015/dev/Debian) (preloaded 
base=mf)


kpathsea: Running mktexmf cmssbx17
mf: /home/schaefer/.texmf-var/fonts/source/public/sauter/cmssbx17.mf: 
successfully generated.
(/home/schaefer/.texmf-var/fonts/source/public/sauter/cmssbx17.mf
(/usr/share/texlive/texmf-dist/fonts/source/public/sauter/b-cmssbx.mf
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/cmbase.mf)
(/usr/share/texlive/texmf-dist/fonts/source/public/sauter/c-cmssbx.mf)
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/roman.mf
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romanu.mf [65] [66]
[67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81]
[82] [83] [84] [85] [86] [87] [88] [89] [90])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romanl.mf [97] [98]
[99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111]
[112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/greeku.mf [0] [1]
[2] [3] [4] [5] [6] [7] [8] [9] [10])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romand.mf [48] [49]
[50] [51] [52] [53] [54] [55] [56] [57])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romanp.mf [36] [38]
[63] [62]) (/usr/share/texlive/texmf-dist/fonts/source/public/cm/romspl.mf
[16] [17] [25] [26] [27] [28])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romspu.mf [29] [30]
[31]) (/usr/share/texlive/texmf-dist/fonts/source/public/cm/punct.mf [33]
[60] [35] [37] [39] [40] [41] [42] [43] [44] [46] [47] [58] [59] [61] [64]
[91] [93] [96]) (/usr/share/texlive/texmf-dist/fonts/source/public/cm/accent.mf
[18] [19] [20] [21] [22] [23] [24] [32] [94] [95] [125] [126] [127])
(/usr/share/texlive/texmf-dist/fonts/source/public/cm/romlig.mf [11] [12]
[13] [14] [15]) (/usr/share/texlive/texmf-dist/fonts/source/public/cm/comlig.mf
[34] [45] [92] [123] [124]) ) ) )
Font metrics written on cmssbx17.tfm.
Output written on cmssbx17.600gf (128 characters, 36804 bytes).
Transcript written on cmssbx17.log.
mktextfm: /home/schaefer/.texmf-var/fonts/tfm/public/sauter/cmssbx17.tfm: 
successfully generated.

kpathsea: Running mktextfm cmssbx17
mktextfm: /home/schaefer/.texmf-var/fonts/tfm/public/sauter/cmssbx17.tfm 
already exists.

No file demo.aux.
[1] (./demo.aux) )
Output written on demo.dvi (1 page, 388 bytes).
Transcript written on demo.log.
This is dvips(k) 5.994 Copyright 2014 Radical Eye Software (www.radicaleye.com)
' TeX output 2019.08.07:1538' -> demo.ps

. 



[1] 
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2015/dev/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./demo.tex
LaTeX2e <2014/05/01>
Babel <3.9l> and hyphenation patterns for 79 languages loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class

Bug#933273: nullmailer logcheck rules no longer work

2019-07-30 Thread Marc SCHAEFER
On Tue, Jul 30, 2019 at 03:27:08PM -0300, David Bremner wrote:
> Jul 28 22:12:08 rocinante nullmailer-send[30788]: From:  to: 
> 
> 
> That doesn't seem to be specific to my configuration, but I thought I
> should check before adding another regex. Do you not have such lines? Do
> you actually want them in the logcheck output?

Yes I have those, but countrary to the other lines which are quite generic,
I found it useful to have those. I am filtering per from/to in local
rules, not nullmailer rules.

Now, if you want to filter them too, no problem for me.

Here is the whole picture that I am running for a few days on a few systems
without any output:

#/etc/logcheck/ignore.d.server/nullmailer
nullmailer-send\[[0-9]+\]: Rescanning queue\.
nullmailer-send\[[0-9]+\]: Trigger pulled\.
nullmailer-send\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
nullmailer-send\[[0-9]+\]: Starting delivery: host: .+ protocol: [a-z]+ file: 
[0-9\.]+
nullmailer-send\[[0-9]+\]: Sent file\.
nullmailer-send\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
nullmailer-send\[[0-9]+\]: smtp: Succeeded:
nullmailer-send\[[0-9]+\]: Message-Id: <.+>

You may however want to be more specific on the above rules (prefixing ^\w{3} [ 
:0-9]{11} [._[:alnum:]-]+ nullmailer)

And this is my local rule:

#/etc/logcheck/ignore.d.server/local
nullmailer-send\[[0-9]+\]: From: <(root|logcheck)@falken.alphanet.ch> to: 




Bug#933273: nullmailer logcheck rules no longer work

2019-07-28 Thread Marc SCHAEFER
Package: nullmailer
Version: 1:2.2-3

In buster, nullmailer now seems to report as nullmailer-send in syslog:

   Jul 28 08:02:08 falken nullmailer-send[586]: Trigger pulled.
   Jul 28 08:02:08 falken nullmailer-send[586]: Rescanning queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery, 1 message(s) 
in queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery: [ ... ]

thus

   sed --in-place 's/nullmailer/nullmailer-send/' 
/etc/logcheck/ignore.d.server/nullmailer

is required (and maybe everywhere else).

Also some more lines needs filtering (e.g. Message-Id: <.+>) and the order in 
Starting delivery
changed.

Here is the diff that works for me (using ignore.d.server):

--- /tmp/nullmailer.ORIG2019-07-28 19:07:10.497156131 +0200
+++ /etc/logcheck/ignore.d.server/nullmailer2019-07-28 15:06:22.544887446 
+0200
@@ -1,7 +1,8 @@
-nullmailer\[[0-9]+\]: Rescanning queue\.
-nullmailer\[[0-9]+\]: Trigger pulled\.
-nullmailer\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
-nullmailer\[[0-9]+\]: Starting delivery: protocol: [a-z]+ host: .+ file: 
[0-9\.]+
-nullmailer\[[0-9]+\]: Sent file\.
-nullmailer\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
-nullmailer\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Rescanning queue\.
+nullmailer-send\[[0-9]+\]: Trigger pulled\.
+nullmailer-send\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
+nullmailer-send\[[0-9]+\]: Starting delivery: host: .+ protocol: [a-z]+ file: 
[0-9\.]+
+nullmailer-send\[[0-9]+\]: Sent file\.
+nullmailer-send\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
+nullmailer-send\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Message-Id: <.+>



Bug#879490: clamav-testfiles wrong result

2017-10-22 Thread Marc SCHAEFER
Package: clamav
Version: 0.99.2+dfsg-0+deb7u3
Severity: minor

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

With Debian jessie, one of the test files is identified wrongly;
which has absolutely no impact on the package's functionnality.

$ bin/test_clamdscan.sh 
34c34
< /usr/share/clamav-testfiles/clam-pespin.exe: Clamav.Test.File-6 FOUND
---
> /usr/share/clamav-testfiles/clam-pespin.exe: Win.Trojan.Sality-90234 FOUND

$ cat bin/test_clamdscan.sh 
#! /bin/bash

clamdscan /usr/share/clamav-testfiles/* \
   | egrep -v '^Time: ' \
   | diff <(cat <<"EOF"
/usr/share/clamav-testfiles/clam.7z: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.arj: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-aspack.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.bin-be.cpio: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.bin-le.cpio: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.bz2.zip: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.cab: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam_cache_emax.tgz: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.chm: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.d64.zip: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.ea05.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.ea06.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.exe.binhex: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.exe.bz2: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.exe.html: OK
/usr/share/clamav-testfiles/clam.exe.mbox.base64: OK
/usr/share/clamav-testfiles/clam.exe.mbox.uu: OK
/usr/share/clamav-testfiles/clam.exe.rtf: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.exe.szdd: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-fsg.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.impl.zip: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam_IScab_ext.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam_IScab_int.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam_ISmsi_ext.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam_ISmsi_int.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.mail: OK
/usr/share/clamav-testfiles/clam-mew.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.newc.cpio: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-nsis.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.odc.cpio: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.ole.doc: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.pdf: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-pespin.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-petite.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.ppt: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.sis: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.tar.gz: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.tnef: OK
/usr/share/clamav-testfiles/clam-upack.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-upx.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-v2.rar: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-v3.rar: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-wwpack.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam-yc.exe: Clamav.Test.File-6 FOUND
/usr/share/clamav-testfiles/clam.zip: Clamav.Test.File-6 FOUND

--- SCAN SUMMARY ---
Infected files: 41
EOF
) -

*** End of the template - remove these lines ***


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
StatsHostID = "auto"
StatsEnabled disabled
StatsPEDisabled = "yes"
StatsTimeout = "10"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory = "/tmp"
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "despam"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "104857600"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "3"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = 

Bug#873816: texlive-base: Fonts handling broken in dvips?

2017-08-31 Thread Marc SCHAEFER
Hello,

thank you for your reply:
> You didn't provide neither the log file nor the .fls file of  
>   latex -recorder test.tex

You can find the whole result here:

https://www.alphanet.ch/~schaefer/tmp/debian-latex-font-bug.tar.gz

> Please install
>   texlive-full
> and retry.

I did, cleaned, retried, and it has still the same issue in
the dvips generated postscript file.



Bug#873816: texlive-base: Fonts handling broken in dvips?

2017-08-31 Thread Marc SCHAEFER
Package: texlive-base
Version: 2016.20170123-5
Severity: normal

Dear Maintainer,

The following LaTeX file:

   \documentclass[12pt,a4paper]{article}
   \font\testing=cmssbx17 scaled 2500
   \font\testingb=cmssbx17 scaled 1500
   \font\testingt=cmss17 scaled 800
   \begin{document}
   \testing{first{\testingb{second}}third}\\
   \testingt{fourth}
   \end{document}

was working correctly with Debian wheezy LTS, for DVI, PS (via dvips)
and PDF (via pdflatex):

   latex demo.tex && dvips demo.dvi -o demo.ps && pdflatex demo.tex
   xdvi demo.dvi; gv demo.ps; gv demo.pdf

With jessie and stretch, the problem is a corrupted PS file which does
not contain the word "first" completely, and in addition with a
wrong font (looking like courier).

Maybe the psfonts.map file is wrong?

Thank you to look into this.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH.U
TF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libpaper-utils 1.1.24+nmu5
ii  tex-common 6.06
ii  texlive-binaries   2016.20160513.41080.dfsg-2
ii  ucf3.0036
ii  xdg-utils  1.1.1-1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-3

Versions of packages texlive-base suggests:
ii  atril [postscript-viewer]1.16.1-2+deb9u1
ii  ghostscript [postscript-viewer]  9.20~dfsg-3.2
ii  gv [postscript-viewer]   1:3.7.4-1+b1
pn  perl-tk  
pn  xpdf-reader | pdf-viewer 

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

Versions of packages tex-common suggests:
ii  debhelper  10.2.5

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

-- debconf information:
  texlive-base/texconfig_ignorant:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi



Bug#818798: courier-imap fails STARTTLS; courier-imap-ssl works

2016-03-20 Thread Marc Schaefer
Package: courier-imap
Version: 4.15-1.6
Severity: normal

Dear Maintainer,

a fresh jessie install had a funny issue:

   - openssl s_client -starttls imap -connect server:imap
 fails with a `140376675755688:error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:340:' error

where

   -  openssl s_client  -connect server:imaps
  works

Same bizarre issue with POP3/POP3S.

Fixed with:
   cd /etc/courier
   mv dhparams.pem dhparams.pem.ORIG
   openssl dhparam -out dhparams.pem 2048
   service courier-pop restart

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages courier-imap depends on:
ii  courier-authlib 0.66.1-1+b1
ii  courier-base0.73.1-1.6
ii  debconf 1.5.56
ii  libc6   2.19-18+deb8u3
ii  libgamin0 [libfam0] 0.1.10-4.1
ii  libgdbm31.8.3-13.1
ii  postfix [mail-transport-agent]  2.11.3-1

courier-imap recommends no packages.

Versions of packages courier-imap suggests:
pn  courier-doc   
ii  courier-imap-ssl  4.15-1.6
pn  imap-client   

-- Configuration Files:
/etc/courier/imapd changed:
ADDRESS=0
PORT=143
MAXDAEMONS=150
MAXPERIP=40
PIDFILE=/var/run/courier/imapd.pid
TCPDOPTS="-nodnslookup -noidentlookup"
LOGGEROPTS="-name=imapd"
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT 
THREAD=REFERENCES SORT QUOTA IDLE"
IMAP_KEYWORDS=1
IMAP_ACL=1
IMAP_CAPABILITY_ORIG="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 
AUTH=CRAM-SHA256 IDLE"
IMAP_PROXY=0
IMAP_PROXY_FOREIGN=0
IMAP_IDLE_TIMEOUT=60
IMAP_MAILBOX_SANITY_CHECK=1
IMAP_CAPABILITY_TLS="$IMAP_CAPABILITY AUTH=PLAIN"
IMAP_CAPABILITY_TLS_ORIG="$IMAP_CAPABILITY_ORIG AUTH=PLAIN"
IMAP_DISABLETHREADSORT=0
IMAP_CHECK_ALL_FOLDERS=0
IMAP_OBSOLETE_CLIENT=0
IMAP_UMASK=022
IMAP_ULIMITD=131072
IMAP_USELOCKS=1
IMAP_SHAREDINDEXFILE=/etc/courier/shared/index
IMAP_ENHANCEDIDLE=0
IMAP_TRASHFOLDERNAME=Trash
IMAP_EMPTYTRASH=Trash:7
IMAP_MOVE_EXPUNGE_TO_TRASH=0
SENDMAIL=/usr/sbin/sendmail
HEADERFROM=X-IMAP-Sender
IMAPDSTART=YES
MAILDIRPATH=Maildir

-- no debconf information



Bug#816211: linux-image-3.16.0-0.bpo.4-amd64: /dev/sr? access is not parallel

2016-02-28 Thread Marc SCHAEFER
Package: src:linux
Version: 3.16.7-ckt20-1+deb8u3~bpo70+1
Severity: normal

Dear Maintainer,

There was a regression in the Linux kernel which made the I/Os to
sr devices (especially when ejecting or writing to DVD-Rs) synchronous
(non parallel).

If you write to a few DVD writes simultaneously, a 5-7x performance
degradation will occur.

You can reproduce the bug easily with:
   for i in /dev/sr?; do (eject $i&); done

If the drives do not open (almost) simultaneously but sequentially, the
bug is present.

Reference: 
http://linux-scsi.vger.kernel.narkive.com/JLvupYok/patch-scsi-sr-fix-multi-drive-performance-by-using-per-device-mutexes

I adapted a patch for that version below and successfully tested it.

-- Package-specific info:
** Version:
Linux version 3.16.0-0.bpo.4-amd64 (debian-ker...@lists.debian.org) (gcc 
version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3~bpo70+1 
(2016-01-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-0.bpo.4-amd64 root=/dev/mapper/vg1-root ro quiet

--- drivers/scsi/sr.c   2015-11-18 11:08:46.0 +0100
+++ drivers/scsi/sr.c.NEW   2016-02-28 19:51:54.957158326 +0100
@@ -76,7 +76,6 @@
 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
 CDC_MRW|CDC_MRW_W|CDC_RAM)

-static DEFINE_MUTEX(sr_mutex);
 static int sr_probe(struct device *);
 static int sr_remove(struct device *);
 static int sr_init_command(struct scsi_cmnd *SCpnt);
@@ -520,24 +519,24 @@
struct scsi_cd *cd;
int ret = -ENXIO;

-   mutex_lock(_mutex);
cd = scsi_cd_get(bdev->bd_disk);
if (cd) {
+mutex_lock(>lock);
ret = cdrom_open(>cdi, bdev, mode);
+mutex_unlock(>lock);
if (ret)
scsi_cd_put(cd);
}
-   mutex_unlock(_mutex);
return ret;
 }

 static void sr_block_release(struct gendisk *disk, fmode_t mode)
 {
struct scsi_cd *cd = scsi_cd(disk);
-   mutex_lock(_mutex);
+   mutex_lock(>lock);
cdrom_release(>cdi, mode);
+   mutex_unlock(>lock);
scsi_cd_put(cd);
-   mutex_unlock(_mutex);
 }

 static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned 
cmd,
@@ -548,7 +547,7 @@
void __user *argp = (void __user *)arg;
int ret;

-   mutex_lock(_mutex);
+   mutex_lock(>lock);

/*
 * Send SCSI addressing ioctls directly to mid level, send other
@@ -578,7 +577,7 @@
ret = scsi_ioctl(sdev, cmd, argp);

 out:
-   mutex_unlock(_mutex);
+   mutex_unlock(>lock);
return ret;
 }

@@ -673,6 +672,8 @@
if (!disk)
goto fail_free;

+   mutex_init(>lock);
+
spin_lock(_index_lock);
minor = find_first_zero_bit(sr_index_bits, SR_DISKS);
if (minor == SR_DISKS) {
@@ -742,6 +743,7 @@

 fail_put:
put_disk(disk);
+   mutex_destroy(>lock);
 fail_free:
kfree(cd);
 fail:
@@ -978,6 +980,8 @@

put_disk(disk);

+   mutex_destroy(>lock);
+
kfree(cd);
 }

--- drivers/scsi/sr.h   2015-11-18 11:08:46.0 +0100
+++ drivers/scsi/sr.h.NEW   2016-02-28 19:45:26.533162171 +0100
@@ -19,6 +19,7 @@

 #include 
 #include 
+#include 

 #define MAX_RETRIES3
 #define SR_TIMEOUT (30 * HZ)
@@ -49,6 +50,7 @@
bool ignore_get_event:1;/* GET_EVENT is unreliable, use TUR */

struct cdrom_device_info cdi;
+   struct mutex lock;
/* We hold gendisk and scsi_device references on probe and use
 * the refs on this kref to decide when to release them */
struct kref kref;



Bug#787249: [Pkg-clamav-devel] Bug#787249: clamav-daemon: clamdscan scans less than clamscan; worsened in latest release

2015-05-30 Thread Marc SCHAEFER
On Sat, May 30, 2015 at 03:06:33PM +0200, Andreas Cadhalpun wrote:
 However, I can't reproduce these other cases.

Not a problem, most of them would be removed by the first stage of
my antispam (white list on magic types).

  /usr/share/clamav-testfiles/clam-v2.rar: OK
  /usr/share/clamav-testfiles/clam-v3.rar: OK
 
 For these two to be detected, one has to install libclamunrar6 from non-free.

Right.

 Set this to 20 and restart clamav-daemon. Then clam_cache_emax.tgz should
 be detected.
 
 Can you confirm this?

Yes, it now works.

Thank you.


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



Bug#787249: clamav-daemon: clamdscan scans less than clamscan; worsened in latest release

2015-05-30 Thread Marc SCHAEFER
Package: clamav-daemon
Version: 0.98.7+dfsg-0+deb6u2
Severity: normal


Hi,

since the last clamav-daemon LTS update, clamdscan gets one test less than
clamscan:

despam@shakotay:~$ bin/test_clamdscan.sh 
8c8
 /usr/share/clamav-testfiles/clam_cache_emax.tgz: OK
---
 /usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND
49c49
 Infected files: 38
---
 Infected files: 39

despam@shakotay:~$ clamscan /usr/share/clamav-testfiles/clam_cache_emax.tgz
/usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND

However, the problem already existed in previous releases, because my
test script contains a lot of OKs. It just got worse by one case.

Could this be due to some PATH issue in the daemon, not finding some
archivers ?

#! /bin/bash

clamdscan /usr/share/clamav-testfiles/* \
   | egrep -v '^Time: ' \
   | diff - (cat EOF
/usr/share/clamav-testfiles/clam.7z: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.arj: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-aspack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-be.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bin-le.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.bz2.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.cab: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_cache_emax.tgz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.chm: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.d64.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea05.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ea06.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.binhex: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.bz2: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.html: OK
/usr/share/clamav-testfiles/clam.exe.mbox.base64: OK
/usr/share/clamav-testfiles/clam.exe.mbox.uu: OK
/usr/share/clamav-testfiles/clam.exe.rtf: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.exe.szdd: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-fsg.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.impl.zip: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_IScab_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_ext.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam_ISmsi_int.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.mail: OK
/usr/share/clamav-testfiles/clam-mew.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.newc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-nsis.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.odc.cpio: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ole.doc: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.pdf: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-pespin.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-petite.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.ppt: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.sis: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tar.gz: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.tnef: OK
/usr/share/clamav-testfiles/clam-upack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-upx.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-v2.rar: OK
/usr/share/clamav-testfiles/clam-v3.rar: OK
/usr/share/clamav-testfiles/clam-wwpack.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam-yc.exe: ClamAV-Test-File FOUND
/usr/share/clamav-testfiles/clam.zip: ClamAV-Test-File FOUND

--- SCAN SUMMARY ---
Infected files: 39
EOF
)

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = /var/log/clamav/clamav.log
StatsHostID = auto
StatsEnabled disabled
StatsPEDisabled = yes
StatsTimeout = 10
LogFileUnlock disabled
LogFileMaxSize = 4294967295
LogTime = yes
LogClean disabled
LogSyslog = yes
LogFacility = LOG_LOCAL6
LogVerbose disabled
LogRotate = yes
ExtendedDetectionInfo = yes
PidFile = /var/run/clamav/clamd.pid
TemporaryDirectory = /tmp
DatabaseDirectory = /var/lib/clamav
OfficialDatabaseOnly disabled
LocalSocket = /var/run/clamav/clamd.ctl
LocalSocketGroup = despam
LocalSocketMode = 666
FixStaleSocket = yes
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = 15
StreamMaxLength = 104857600
StreamMinPort = 1024
StreamMaxPort = 2048
MaxThreads = 3
ReadTimeout = 180
CommandReadTimeout = 5
SendBufTimeout = 200
MaxQueue = 100
IdleTimeout = 30
ExcludePath disabled
MaxDirectoryRecursion = 15
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = yes
SelfCheck = 3600
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = yes
Foreground disabled
Debug 

Bug#758692: munin-node timeouts and leads to partial graphs

2014-08-20 Thread Marc SCHAEFER
Package: munin-node
Version: 2.0.6-4+deb7u2
Severity: important

Dear Maintainer,

When running big munin installations, with sometimes some services
timeouting, the resulting graphs are partial: munin aborts from the
point of error.

Upstream has fixed that already, at least in their bug-tracking.
I have not checked if non stable contains those fixes. This might
be useful anyway.

There are two fixes:

   1. create a new global timeout option
   2. make sure the normal timeout is really passed to the script

I have applied those fixes with diversions to my stable system.
This seems to fix the problem with no other impact.


Change to config /etc/munin/munin-node.conf:

timeout 200
global_timeout 900


--- /usr/share/perl5/Munin/Node/Server.pm.distrib   2013-11-12 
23:12:59.0 +0100
+++ /usr/share/perl5/Munin/Node/Server.pm   2014-08-19 18:30:19.916699076 
+0200
@@ -132,7 +132,9 @@
 
 # catch and report any system errors in a clean way.
 eval {
-$timed_out = !do_with_timeout($services-{timeout}, sub {
+# 
http://munin-monitoring.org/changeset/d2f9ce0cc14efd02cbab0ff1c736e0764104d771/munin
+my $global_timeout = $config-{global_timeout} || (60 * 15); # 
Defaults to 15 min. Should be enough 
+$timed_out = !do_with_timeout($global_timeout, sub {
 while (defined ($line = _net_read($session))) {
 chomp $line;
if (! _process_command_line($session, $line)) {


--- /usr/sbin/munin-node.distrib2013-11-12 23:12:59.0 +0100
+++ /usr/sbin/munin-node2014-08-19 18:30:53.404260493 +0200
-@@ -64,11 +64,13 @@
 
 $paranoia = $config-{paranoia} if defined $config-{paranoia};
 
+# http://munin-monitoring.org/ticket/1258
 my $services = Munin::Node::Service-new(
 servicedir = $servicedir,
 defuser= $config-{defuser},
 defgroup   = $config-{defgroup},
 pidebug= $PIDEBUG,
+timeout= $config-{timeout},
 );
 
 $config-reinitialize({



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.iso-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages munin-node depends on:
ii  adduser 3.113+nmu3
ii  gawk1:4.0.1+dfsg-2.1
ii  libnet-server-perl  2.006-1+deb7u1
ii  lsb-base4.1+Debian8+deb7u1
ii  munin-common2.0.6-4+deb7u2
ii  munin-plugins-core  2.0.6-4+deb7u2
ii  perl5.14.2-21+deb7u1
ii  procps  1:3.3.3-3

Versions of packages munin-node recommends:
ii  libnet-snmp-perl 6.0.1-2
ii  munin-plugins-extra  2.0.6-4+deb7u2

Versions of packages munin-node suggests:
ii  acpi  1.6-1
pn  ethtool   none
ii  hdparm9.39-1+b1
pn  libcache-cache-perl   none
pn  libcrypt-ssleay-perl  none
pn  libdbd-mysql-perl none
pn  libdbd-pg-perlnone
pn  liblwp-useragent-determined-perl  none
pn  libnet-irc-perl   none
pn  libtext-csv-xs-perl   none
ii  libwww-perl   6.04-1
pn  libxml-simple-perlnone
ii  lm-sensors1:3.3.2-2+deb7u1
ii  logtail   1.3.15
ii  munin 2.0.6-4+deb7u2
pn  munin-plugins-javanone
pn  mysql-client  none
ii  net-tools 1.60-24.2
ii  python2.7.3-4+deb7u1
pn  ruby  none
ii  smartmontools 5.41+svn3365-1

-- 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#614085: #614085 tar --compare fails

2013-08-14 Thread Marc SCHAEFER
Hello,

this furiously resembles to:
   https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1043028
or
   http://www.mail-archive.com/bug-tar@gnu.org/msg03446.html

I just downloaded tar_1.26+dfsg-6 source, applied the patch below and
attached and the problem seems fixed.

schaefer@reliand:~/PORTED/tar-1.26+dfsg-6/tar-1.26+dfsg$ wget -O - 
http://git.savannah.gnu.org/cgit/tar.git/patch/?id=d88b2a613f4b1a5554e8c34c8f75b91abff5f0e9
 | patch -p1
--2013-08-14 20:15:37--  
http://git.savannah.gnu.org/cgit/tar.git/patch/?id=d88b2a613f4b1a5554e8c34c8f75b91abff5f0e9
Resolving git.savannah.gnu.org... 140.186.70.72
Connecting to git.savannah.gnu.org|140.186.70.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `STDOUT'

[ =   ] 4,327   --.-K/s   in 0s  

2013-08-14 20:15:37 (167 MB/s) - written to stdout [4327]

patching file src/common.h
Hunk #1 succeeded at 522 (offset -2 lines).
patching file src/compare.c
patching file src/incremen.c

Have a nice debconf .. and busker's festival.


‹õÈRtar-d88b2a613f4b1a5554e8c34c8f75b91abff5f0e9.patchWÛnÛ8}®¾bڇÀŽmU¾%¶Ó]4É¢@ëmÒÅ
  ”DÙldR $'i›ßR²%Û  ŠK$çz83^jµ‚h2
ì¤?ŒGAŸÇ㟄ÃQ8‰OÇÁ´Ï‚8ÇŸÂg%áO¡
ž73?x^ß¹D13\ÒþWê§|`·*ŽáÍB³‡÷Y¸J/܂½sÎYÎgp]ð.ôÇ0WkÐïCߛ'³á:ηøÁÃ|—âTÊ5ËêV1ôzk®EüBB¨äB†féNäK\LD–ó¨'d¨ùŠËœ%Žs
™_‡jµRÒ]B+L8Ó~$4jPúÁÏYðöæüR­rå–,•7|ž).p·ªR¦9±EŽý¨X¥È‰Ô×ì–ƒT   ™s
¹‚,×E˜;9
Ïr–ûBÆ
XL/
rÀuJ‘–ˆŸDžA¹ŽËt¸k2âVY’ÌºR$¶€ùk• D¤þ@dýq^¯ç;B¹9°×
è‚ÆÐ2â÷0   'ýE®¦qz¸—ÞÉhD¢vøN§³+ãý{è£î   tèu
8±V‚Âøä2ß
-‹4;Îòö™dˆ“ŸCé½OCÜ%³Â%Ópœ] T«@zZhù‰cÕAØ EkVÿëc̒¨ÀI
E7tŽ_ãÂ!PË šãÖÁépp2e®ÛŸŒ17ÙAXKŽ®å;O»Ãtè=2ÐV¸„«´  
ëB}´x4x4[âôêU:ítš“‡¤èwà—ÐÐRYqÌõ-G|MÛÇ×ð3SJ$iæÏǸ`„u@Ęb\óØ(C
mÂe£ÚEÂ}ÉVXoŽ6Ümx‰ÒÑö} hNïݳL@Ï/û²ü\k©àí[¸˜¹˜_·ÞÃuÇ´|Ö
«:iSyû¬R“ŒWBQ™Ò(µ¤=,öÑ©$›¡…|㭛ᛯKœ›…tÛÀýÌѐ·d²ž¨G{6¶É´scSD¨Ù L;Ö]“i-
¶h£§*6jŽÛ¨z~óéÓYEŠuH
dE`ÄâҖŽ.˜Òbá×ö•è|ÍYäÇ  [dí­D4%¾1f½ Pº¡¦ï
gimÜÄƊÑDãv×BºËkÖKЃ†zã8  /ŒÑx©5ŒœÒ½]b†bÉ[d3œšç…
–ôýhÅ?Z4ø_;JilË\ihCÈ5z5Wõf/fËåîŽ9mJ!ÍS¥   9šá2䇪~ëՇÊ`KûªÝÜ͆
º§Õv©5¤OèÙI%ãº
+#»‰gÙaÃËE_*•VïsÝ;¤û•™Šýht‚Çggt2°§¨©Ë«ÉžüUµ¶äPï6K¸qd…©¹÷%¿Ïý 
Qá­ÏbêV6û·D+­2ðĻҔ‡ù’ƒ¡‡˜ºÊ5 W°æt4ÖO'dý¸?ªY¿k!=!ÃÄû{~sýïՅ~óùêüã×Ym  
  
‡´4«èúI¨*a´5O1“@Í©|›úl)KÆr.À½¼%ˆL‡3ôL‡ƒ[41N½%k¸÷Ï__策ׯëæ0†Ýw¡mWì3]˜±¦¶
,1•s1,ÍÖàVÑ­Øh«’ø¥±¾‘ÂfF`ßiÚo^jq°3Q¶/x¡ÆAìº'Ó0ˆÆÓýö¥Æ²í_j“¦ñ
nôŒlXhê«°¦   ±=ē¯ÍçšÝQ—®í2Eiï- 
–þý„Ë®!µÿ4®òÎôNç¹FÐ阣¬l\¶õó8JùÚ  ظKØ
°dÙÒ7Â÷)ÎöYWgÀ_#3BbÓ¤¶ìS‚žÚ»ñ¾Tˆ‹@ÃÏM5獓ÝÖ`£§Fm£R¯µ 
§€Þœì¸núè˜AÞT8!oñÞ$ñ²µU‚ɈÿäÊvnþ×ç‹.‚°rÌ)U\«ËÐùÅw#‘IìT´™ÿ8ÿÒµ—Èùå7\ŠLÂÉ
…q·äXÜ4Þ¿ðÒ@¬DSÊ%a—_næç5¦
Ã'[¸åÁ)U¸áhlk€Ty²zŸc²ê¥ÅŠg)aE_ÝMÞBk7BLÅøý{/r[b{•Ü”óØåZÀ¤’èLb{¬–¬¼^I™¡Ð¶9Fÿ”~CjøÐþ££Ê֌ë|ϕîv³
=÷x¡U!*áe½ÂKlHÅjí¹S×sÎïahç

Bug#658183: Not reproductible

2012-02-06 Thread Marc SCHAEFER
The problem disappears after a few restarts of the VZ, so don't
bother.





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



Bug#658183: linux-image-2.6.32-5-openvz-amd64: Incorrect load average within OpenVZ VE

2012-01-31 Thread Marc SCHAEFER
Package: linux-2.6
Version: 2.6.32-41
Severity: minor


Hi,

since the upgrade to this kernel a few hours ago, I am experiencing strange
loadaverage output in two VEs. One has almost 1.0 and the other 3.0, although
the host system has 0.30. Those VEs are not at all busy, their load hasn't
changed and they used to report correct information for the last month on the
previous kernel.

It looks that the VEs where the load is wrong are the VE running oldstable
(lenny).

-- Package-specific info:
** Version:
Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-41) (b...@decadent.org.uk) 
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 17:49:19 UTC 2012

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-openvz-amd64 root=/dev/mapper/vg1-root ro 
quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 1703   
board_vendor: ASUSTeK Computer INC.
board_name: M4A89GTD-PRO/USB3
board_version: Rev 1.xx

** Loaded modules:
Module  Size  Used by
xt_mac   979  10 
ip6t_LOG4618  3 
ext3  106678  1 
jbd37269  1 ext3
vzethdev7301  0 
vznetdev   17967  10 
simfs   3087  5 
vzrst 110398  0 
vzcpt  97106  0 
vzdquota   35158  5 [permanent]
vzmon  16317  9 vzethdev,vznetdev,vzrst,vzcpt
vzdev   1824  4 vzethdev,vznetdev,vzdquota,vzmon
xt_length   1164  0 
xt_hl   1313  0 
xt_tcpmss   1401  0 
xt_TCPMSS   2935  0 
xt_multiport2267  0 
xt_dscp 1805  0 
tun12395  4 
dahdi_echocan_oslec 1426  2 
echo3408  1 dahdi_echocan_oslec
powernow_k810978  1 
cpufreq_userspace   1992  0 
cpufreq_stats   2740  0 
cpufreq_conservative 5162  0 
cpufreq_powersave902  0 
vzevent 1723  1 
fuse   51710  11 
xt_MARK 1929  5 
xt_mark 1463  2 
xt_CONNMARK 2214  2 
iptable_mangle  2881  1 
ip6table_filter 2448  1 
ip6_tables 15283  2 ip6t_LOG,ip6table_filter
nf_nat_ftp  2047  0 
nf_conntrack_ftp5537  1 nf_nat_ftp
xt_state1303  234 
xt_limit1782  2 
ipt_REJECT  1953  1 
ipt_LOG 4758  1 
xt_tcpudp   2319  319 
8021q  17902  0 
garp5050  1 8021q
stp 1440  1 garp
iptable_nat 4363  1 
nf_nat 13546  2 nf_nat_ftp,iptable_nat
nf_conntrack_ipv4  10143  239 iptable_nat,nf_nat
nf_conntrack   47155  7 
xt_CONNMARK,nf_nat_ftp,nf_conntrack_ftp,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4  1155  1 nf_conntrack_ipv4
iptable_filter  2322  1 
ip_tables  14123  3 iptable_mangle,iptable_nat,iptable_filter
x_tables   13213  19 
xt_mac,ip6t_LOG,xt_length,xt_hl,xt_tcpmss,xt_TCPMSS,xt_multiport,xt_dscp,xt_MARK,xt_mark,xt_CONNMARK,ip6_tables,xt_state,xt_limit,ipt_REJECT,ipt_LOG,xt_tcpudp,iptable_nat,ip_tables
loop   11751  0 
firewire_sbp2  11514  0 
firewire_core  36864  1 firewire_sbp2
crc_itu_t   1307  1 firewire_core
radeon574956  0 
snd_hda_codec_atihdmi 2251  1 
ttm39954  1 radeon
drm_kms_helper 20369  1 radeon
snd_hda_intel  20035  0 
snd_hda_codec  54244  2 snd_hda_codec_atihdmi,snd_hda_intel
drm   142327  3 radeon,ttm,drm_kms_helper
snd_hwdep   5396  1 snd_hda_codec
snd_pcm60503  2 snd_hda_intel,snd_hda_codec
snd_timer  15614  1 snd_pcm
snd46574  5 
snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
pl2303 13992  2 
i2c_piix4   8328  0 
i2c_algo_bit4209  1 radeon
soundcore   4598  1 snd
pcspkr  1699  0 
evdev   7368  3 
usbserial  27692  5 pl2303
asus_atk01107686  0 
usblp   9587  0 
k10temp 2715  0 
zaphfc 13425  3 
edac_core  29245  0 
edac_mce_amd6433  0 
i2c_core   15819  5 radeon,drm_kms_helper,drm,i2c_piix4,i2c_algo_bit
snd_page_alloc  6265  2 snd_hda_intel,snd_pcm
dahdi 188217  8 dahdi_echocan_oslec,zaphfc
shpchp 26248  0 
pci_hotplug21603  1 shpchp
wmi 4323  0 
processor  2  7 powernow_k8
crc_ccitt   1323  1 dahdi
button  

Bug#576191: tomcat5.5: /etc/init.d/tomat5.5 stop fails to stop

2010-04-01 Thread Marc SCHAEFER
Package: tomcat5.5
Version: 5.5.26-5
Severity: normal

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

Hi,

sometimes

   /etc/init.d/tomcat5.5 stop

doesn't kill jsvc.  A manual killall jsvc is not enough, you need to
use killall -9 jsvc.

Changing the /etc/init.d/tomcat5.5 script should be done with caution
because of the `set -e' at the top of the file.


-- 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/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages tomcat5.5 depends on:
ii  adduser  3.110   add and remove users and groups
ii  jsvc 1.0.2~svn20061127-9 wrapper to launch Java application
ii  libecj-java  3.3.0+0728-9Eclipse Java compiler (library)
ii  libtomcat5.5-java5.5.26-5Java Servlet engine -- core librar
ii  sun-java5-jre [java2 1.5.0-17-0.1Sun Java(TM) Runtime Environment (

tomcat5.5 recommends no packages.

Versions of packages tomcat5.5 suggests:
pn  libapache2-mod-jk   none   (no description available)
ii  sun-java5-jre [java-virtual 1.5.0-17-0.1 Sun Java(TM) Runtime Environment (
ii  tomcat5.5-admin 5.5.26-5 Java Servlet engine -- admin  man
ii  tomcat5.5-webapps   5.5.26-5 Java Servlet engine -- documentati

-- 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#570628: samba: long share names worked with etch, fail with lenny

2010-02-20 Thread Marc SCHAEFER
Package: samba
Version: 2:3.2.5-4lenny8
Severity: normal

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

In etch, I had a /etc/samba/smb.conf's share named tomcat55-webapps.
Unfortunately, I had to rename it to tomcat55-web for the share to
continue working in lenny with a XP pro Version 2002 SP 3 client.

smbclient doesn't care, it works in both cases.

-- 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/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages samba depends on:
ii  adduser 3.110add and remove users and groups
ii  debconf [debcon 1.5.24   Debian configuration management sy
ii  libacl1 2.2.47-2 Access control list shared library
ii  libattr11:2.4.43-2   Extended attribute shared library
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries
ii  libcomerr2  1.41.3-1 common error description library
ii  libcups21.3.8-1+lenny7   Common UNIX Printing System(tm) - 
ii  libgnutls26 2.4.2-6+lenny2   the GNU TLS library - runtime libr
ii  libkrb531.6.dfsg.4~beta1-5lenny2 MIT Kerberos runtime libraries
ii  libldap-2.4-2   2.4.11-1+lenny1  OpenLDAP libraries
ii  libpam-modules  1.0.1-5+lenny1   Pluggable Authentication Modules f
ii  libpam-runtime  1.0.1-5+lenny1   Runtime support for the PAM librar
ii  libpam0g1.0.1-5+lenny1   Pluggable Authentication Modules l
ii  libpopt01.14-4   lib for parsing cmdline parameters
ii  libtalloc1  1.2.0~git20080616-1  hierarchical pool based memory all
ii  libwbclient02:3.2.5-4lenny8  client library for interfacing wit
ii  logrotate   3.7.1-5  Log rotation utility
ii  lsb-base3.2-20   Linux Standard Base 3.2 init scrip
ii  procps  1:3.2.7-11   /proc file system utilities
ii  samba-common2:3.2.5-4lenny8  Samba common files used by both th
ii  update-inetd4.31 inetd configuration file updater
ii  zlib1g  1:1.2.3.3.dfsg-12compression library - runtime

samba recommends no packages.

Versions of packages samba suggests:
pn  ldb-tools   none   (no description available)
ii  openbsd-inetd [inet-superse 0.20080125-2 The OpenBSD Internet Superserver
pn  smbldap-tools   none   (no description available)

-- debconf information:
  samba/run_mode: daemons
  samba/tdbsam: false
  samba/generate_smbpasswd: true




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



Bug#558677: --exclude documented in info coreutils cp but not available in program

2009-11-29 Thread Marc SCHAEFER
Package: coreutils
Version: 6.10-6
Severity: wishlist


schae...@virtual:~$ info coreutils cp
   `--exclude=PATTERN'
 When recursing, skip subdirectories or files matching PATTERN.
 For example, `du --exclude='*.o'' excludes files whose names end
 in `.o'.

schae...@virtual:~$ cp --exclude=BLAH . /tmp
cp: unrecognized option `--exclude=BLAH'
Try `cp --help' for more information.

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

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

Versions of packages coreutils depends on:
ii  libacl1   2.2.47-2   Access control list shared library
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libselinux1   2.0.65-5   SELinux shared libraries

coreutils recommends no packages.

coreutils 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#558677: --exclude documented in info coreutils cp but not available in program

2009-11-29 Thread Marc SCHAEFER
On Sun, Nov 29, 2009 at 01:46:26PM -0700, Bob Proulx wrote:
 Uhm...  The coreutils 'cp invocation' node does not include a
 --exclude option description in 6.10 in Lenny.  The above shows up
 in the 'du invocation' node.  Could it be that you are looking at the
 wrong documentation?  I think so.

Yes, I was.

Sorry for this stupid mistake.

Meanwhile I have implemented what I required with:

  (cd $THE_DEST  find . \( -path ./scratch/news/archive -prune \) -o \( -path 
./scratch/news/articles -prune \) -o -print0 | cpio --quiet --link -0 -pd 
$THE_DEST_LINK)

aka a cp -al with excludes

Thank you for your prompt response.




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



Bug#512831: closed by Michael Stone mst...@debian.org (Re: coreutils: cp refuses to hardlink a specific file, with a strange error message)

2009-09-03 Thread Marc SCHAEFER
Hi,

bugs happens also on lenny (--- using the etch kernel).  The filesystem
is regularly e2fsck'd and no error happens in dmesg.

I will presumably soon upgrade to the lenny kernel and see what happens.



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



Bug#532118: transproxy: Crashes on strftime(3) on amd64 when logging enabled

2009-06-06 Thread Marc SCHAEFER
Package: transproxy
Version: 1.5-1
Severity: important


If enabling logging (-l /tmp/blah), it will crash at every request with 
a SIGSEGV.  Fix is simply to add a #include time.h just after the 
sys/time.h line.

Note that the compilation also produces quite a few signedness issues.

-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18+openvz
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1)

Versions of packages transproxy depends on:
ii  libc6  2.3.6.ds1-13etch9 GNU C Library: Shared libraries
ii  libwrap0   7.6.dbs-13Wietse Venema's TCP wrappers libra

transproxy recommends 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#512831: coreutils: cp refuses to hardlink a specific file, with a strange error message

2009-01-24 Thread Marc SCHAEFER
Package: coreutils
Version: 5.97-5.3
Severity: important


Really funny things happening:

virtual:~# mount | grep /backup
/dev/sdc1 on /backup type ext3 (ro)
127.0.0.1:/backup/vz/104 on /var/lib/vz/root/104/backup type nfs 
(ro,soft,nolock,port=2049,mountport=2049,noudp,tcp,addr=127.0.0.1)
virtual:~# uname -a
Linux virtual 2.6.18+openvz #1 SMP Sun Mar 23 19:15:17 CET 2008 x86_64 
GNU/Linux
mount /backup -o remount,rw; cp -al /backup/vz/104/backup.0 
/backup/vz/104/backup.TEST; mount /backup -o remount,ro
cp: cannot create hard link 
`/backup/vz/104/backup.TEST/scratch/news/articles/fr/comp/developpement/agl/windev/63260'
 
to 
`/backup/vz/104/backup.TEST/scratch/news/articles/fr/comp/developpement/agl/windev/63260':
 
No such file or directory

Yes, that file is missing on the copy.
Thus I can hardlink it by hand:

virtual:~# mount /backup -o remount,rw; cp -al 
/backup/vz/104/backup.0/scratch/news/articles/fr/comp/developpement/agl/windev/63260
 
/backup/vz/104/backup.TEST/scratch/news/articles/fr/comp/developpement/agl/windev/63260;
 
mount /backup -o remount,ro

and this is reproductible *each time*. Note the bizarre error message 
above (hardlinking over itself).

Do it once more:


virtual:~# mount /backup -o remount,rw; cp -al /backup/vz/104/backup.0 
/backup/vz/104/backup.TEST2; mount /backup -o remount,ro
cp: cannot create hard link 
`/backup/vz/104/backup.TEST2/scratch/news/articles/fr/comp/developpement/agl/windev/63260'
 
to 
`/backup/vz/104/backup.TEST2/scratch/news/articles/fr/comp/developpement/agl/windev/63260':
 
No such file or directory

look at the file more carefully:

virtual:~# ls -lai 
/backup/vz/104/backup.0/scratch/news/articles/fr/comp/developpement/agl/windev/63260
14354482 -rw-rw-r-- 9 news news 1877 Jan 21 11:13 
/backup/vz/104/backup.0/scratch/news/articles/fr/comp/developpement/agl/windev/63260

virtual:~# lsattr 
/backup/vz/104/backup.0/scratch/news/articles/fr/comp/developpement/agl/windev/63260
-- 
/backup/vz/104/backup.0/scratch/news/articles/fr/comp/developpement/agl/windev/63260

If I remove that file and start the cp -al over to a new destination, 
the error disappears.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18+openvz
Locale: LANG=C, LC_CTYPE=fr_CH.ISO-8859-1 (charmap=ISO-8859-1)

Versions of packages coreutils depends on:
ii  libacl12.2.41-1  Access control list shared library
ii  libc6  2.3.6.ds1-13etch8 GNU C Library: Shared libraries
ii  libselinux11.32-3SELinux shared libraries

coreutils recommends 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#506397: /usr/sbin/ammt: Most runs syslog reports task ammt blocked for more than 120 seconds

2008-11-21 Thread Marc SCHAEFER
On Fri, Nov 21, 2008 at 02:42:02AM -0500, Daniel Dickinson wrote:
 Pretty much every run I get messages like the following:

AFAIK it's because mtio operations are done in D state (uninterruptible
sleep).

And except for mtio operations which may last more than two minutes,
nothing in the usual kernel operation will last that long.

Solutions:
   - either fix mtio to be interruptible (which may well cause problems
 because e.g. SCSI reselection might happen later)
   - use the proposed work-around
   - ignore those messages in your logcheck.




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



Bug#497514: Races

2008-09-04 Thread Marc SCHAEFER
Hi,

*IF* POSIX or general use mandates that chmod(2) should not change
ctime if no change really occurs, this should be fixed in the
Linux kernel itself.

Fixing it in user space in the chmod(1) utility is wrong, because it
could introduce user-space race conditions.

For example:
   timestamp 1: perm is 0500
   timestamp 2: perm is 0700
   timestamp 3: perm is 0500

we would expect c_time to be timestamp 3 at the end of this flow.

Now imagine that you have two processes. Process one wants to set
perm to 0500, process 2 to 0700.  Imagine it works as follows:

   process 1  process 2
   stats file, gets perm 500
  stats files, get perm 0500
  set permissions to 0700, ctime changes


   set perm, no real change,
   so don't do anything

WRONG! permission is 0700!

(one could argue that the overall result is undefined if the two
processes are scheduled in parallel anyway; however there seem to be
something wrong in the user-space semantic here anyway)

(in general, any I check manually, then I set method is wrong,
 unless it is done atomically, which is not the case for user space
 and can only be guaranteed with kernel locks with currently used
 Linux kernels)




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



Bug#399997: blocksize problem

2007-03-25 Thread Marc SCHAEFER
On Thu, Mar 22, 2007 at 09:46:39AM +0100, Adolf Markus Berthold wrote:
 This is a blocksize problem. I had the same problem with
 package version 2.5.1p1-2.1 and a HP DAT72 usb drive.

What about specifying `mt -f /dev/nst0 setblk 512' in a pre-script
before backup ?

The default is AFAIK 0, which means `take the I/O size provided by 
size of write(2) as block size'.

Using 512 means it will work with any block size which is a multiple of
512. It may be a little less efficient than full-blown block sizes but
it will also help with the absence of padding (tar pads at least 10240
bytes by default).



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



Bug#390848: apache: expire returns doubled headers

2006-10-03 Thread Marc SCHAEFER
Package: apache
Version: 1.3.33-6sarge3
Severity: minor


Hi,

using something like:

Directory /home/twiki/public_html/bin
 Options +ExecCGI FollowSymLinks
 SetHandler cgi-script
 Order Allow,Deny
 Allow from all
 Deny from env=anonymous_spider

 # Disable caching in client!  Else issues when editing the same
 # document without the t=EPOCH hack which doesn't work with
 # static files!
 # Requires mod_expire
 #(see
 #http://httpd.apache.org/docs/1.3/mod/mod_expires.html)
 ExpiresActive On
 ExpiresDefault now
/Directory

I get the following strange output (using w3m's =; Firefox 1.5 reports
no expiry at all):

HTTP/1.1 200 OK
Date: Mon, 18 Sep 2006 22:09:24 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_ssl/2.8.22 OpenSSL/0.9.7e 
mod_perl/
Cache-control: max-age=86400
Expires: Tue, 19 Sep 2006 22:09:29 GMT
Cache-Control: max-age=0
Expires: Mon, 18 Sep 2006 22:09:24 GMT
Last-Modified: Mon, 18 Sep 2006 22:09:29 GMT
Content-length: 15469
Connection: close
Content-Type: text/html; charset=iso-8859-15

Basically, the Cache-control and Expires: headers are doubled.

What should I do to fix this ?

I would really like the client to not cache the data for those URLs.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.33-pre2shakotay+2.4.33pre2+patch+route+vserver+vs1.2.10
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1)

Versions of packages apache depends on:
ii  apache-common 1.3.33-6sarge3 support files for all Apache webse
ii  debconf   1.4.30.13  Debian configuration management sy
ii  dpkg  1.10.28Package maintenance system for Deb
ii  libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an
ii  libdb4.2  4.2.52-18  Berkeley v4.2 Database Libraries [
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libmagic1 4.12-1 File type determination library us
ii  logrotate 3.7-5  Log rotation utility
ii  mime-support  3.28-1 MIME files 'mime.types'  'mailcap
ii  perl  5.8.4-8sarge5  Larry Wall's Practical Extraction 

-- debconf information:
* apache/enable-suexec: true
  apache/server-name: shakotay.alphanet.ch
  apache/document-root: /data/www
  apache/server-port: 80
  apache/init: true
  apache/server-admin: [EMAIL PROTECTED]


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



Bug#372876: lynx doesn't remove /tmp/XXX* temp directory on STDOUT close

2006-06-12 Thread Marc SCHAEFER
Package: lynx
Version: 2.8.5-2sarge2
Severity: normal


To reproduce:

   - install apache from sarge
   - make sure there are enough servers started
   - do /usr/bin/apachectl status

you will observe a temporary directory in /tmp.

Running this regularly will clutter /tmp with temporary directories upto
someone cannot really create any files there (too many links).

Other way to reproduce:

   lynx -dump http://some-big-stuff | (dd bs=1 count=1)

(ie ensure lynx sees the closed filedes)

Work-around for apachectl: something like, line 154:

   $LYNX $STATUSURL | (awk ' /process$/ { print; exit } { print } '; cat  
/dev/null)

This was reported for woody as of #298836 but is still there in sarge,
unfortunately.  A work-around patch for apachectl is there.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.33-pre2shakotay+2.4.33pre2+patch+route+vserver+vs1.2.10
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1)

Versions of packages lynx depends on:
ii  libbz2-1.01.0.2-7high-quality block-sorting file co
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii  libgnutls11   1.0.16-13.2GNU TLS library - runtime library
ii  libncursesw5  5.4-4  Shared libraries for terminal hand
ii  zlib1g1:1.2.2-4.sarge.2  compression library - runtime

-- no debconf information


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



Bug#369915: mailman: VERP bounce probes active where they shouldn't

2006-06-02 Thread Marc SCHAEFER
Package: mailman
Version: 2.1.5-8sarge2
Severity: minor


I am running a Mailman from Debian stable (2.1.5-8sarge2), and I
experimented the following issue:

  - even if disabled in Defaults.py and not enabled in mm_cfg.py,
VERP seems to be activated from time to time. I am guessing it is
activated only when something already bounced on a user (?).
Most mail sent out don't have the VERP (user=host+id) stuff at all
as Sender:, and when they have something it's a cookie:

   [EMAIL PROTECTED]

Mark SAPIRO answered that in 2.1.5, VERP *bounce probes* cannot be
disabled.

Fixing the bug implies applying the patch:

   Modify Mailman/Bouncer.py to either implement mm_cfg.VERP_PROBES or
   just remove VERP probes all together. See
   
http://svn.sourceforge.net/viewcvs.cgi/mailman/branches/Release_2_1-maint/mailman/Mailman/Bouncer.py?r1=7147r2=7190

The bug will only show itself if the local MDA is unable to send to
Mailman when the address contains a +. Most modern MDA will see a + as
a subaddress and thus the bug won't be seen.

In my config, + cannot be used for that purpose. My work-around was to
modify this in mm_cfg.py:

   VERP_PROBE_FORMAT = '%(bounces)s=%(token)s'
   VERP_PROBE_REGEXP = r'^(?Pbounces[^+]+?)\=(?Ptoken[EMAIL PROTECTED])@.*$'

and use = as subaddress separator






-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.33-pre2shakotay+2.4.33pre2+patch+route+vserver+vs1.2.10
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1)

Versions of packages mailman depends on:
ii  apache [httpd]1.3.33-6sarge1 versatile, high-performance HTTP s
ii  cron  3.0pl1-86  management of regular background p
ii  debconf   1.4.30.13  Debian configuration management sy
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii  logrotate 3.7-5  Log rotation utility
ii  postfix [mail-transpo 2.1.5-9A high-performance mail transport 
ii  pwgen 2.03-1 Automatic Password generation
ii  python2.3.5-2An interactive high-level object-o
ii  ucf   1.17   Update Configuration File: preserv

-- debconf information:
* mailman/site_languages: fr, en
* mailman/used_languages: en fr
* mailman/create_site_list:
* mailman/queue_files_present:
* mailman/default_server_language: en
  mailman/gate_news: false


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



Bug#321062: gedit: Can only print to lp

2005-08-03 Thread Marc SCHAEFER
Package: gedit
Version: 2.8.3-4sarge1
Severity: normal


Hi,

I haven't yet investigated this a lot, but this is what I see:

   You can't specify a printer in gedit: strace shows
   it always execs lpr -Plp

   If you specify custom command in a script, it says:
  ** (gedit:8563): WARNING **: Opening '/tmp/bla.sh' for output failed

I find it a bit strange that this bug is in this package ... maybe you
have a clue ?  We didn't see this bug until we upgraded the package a
few days ago (however, we may have had a very old gedit version).

Print system is lprng.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1) (ignored: LC_ALL set to 
fr_CH)

Versions of packages gedit depends on:
ii  gconf2 2.8.1-6   GNOME configuration database syste
ii  gedit-common   2.8.3-4sarge1 light-weight text editor support f
ii  libart-2.0-2   2.3.17-1  Library of functions for 2D graphi
ii  libaspell150.60.2+20050121-2 The GNU Aspell spell-checker runti
ii  libatk1.0-01.8.0-4   The ATK accessibility toolkit
ii  libbonobo2-0   2.8.1-2   Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.8.1-2   The Bonobo UI library
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libeel2-2  2.8.2-1   Eazel Extensions Library (for GNOM
ii  libgail-common 1.8.4-1   GNOME Accessibility Implementation
ii  libgail17  1.8.4-1   GNOME Accessibility Implementation
ii  libgconf2-42.8.1-6   GNOME configuration database syste
ii  libglade2-01:2.4.2-2 library to load .glade files at ru
ii  libglib2.0-0   2.6.4-1   The GLib library of C routines
ii  libgnome2-02.8.1-2   The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.8.0-1   A powerful object-oriented display
ii  libgnomeprint2.2-0 2.8.2-1   The GNOME 2.2 print architecture -
ii  libgnomeprintui2.2-0   2.8.2-2   GNOME 2.2 print architecture User 
ii  libgnomeui-0   2.8.1-3   The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 2.8.4-4   The GNOME virtual file-system libr
ii  libgtk2.0-02.6.4-3   The GTK+ graphical user interface 
ii  libgtksourceview1.0-0  1.2.0-1   shared libraries for the GTK+ synt
ii  libice64.3.0.dfsg.1-14   Inter-Client Exchange library
ii  liborbit2  1:2.12.2-1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.8.1-1   Layout and rendering of internatio
ii  libpopt0   1.7-5 lib for parsing cmdline parameters
ii  libsm6 4.3.0.dfsg.1-14   X Window System Session Management
ii  libxml22.6.16-7  GNOME XML library
ii  scrollkeeper   0.3.14-10 A free electronic cataloging syste
ii  xlibs  4.3.0.dfsg.1-14   X Keyboard Extension (XKB) configu
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information


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



Bug#320402: postgresql: postmaster.pid file not deleted at boot; crash means no restart

2005-07-28 Thread Marc SCHAEFER
Package: postgresql
Version: 7.4.7-6sarge1
Severity: minor


If your machine restarts in an uncontrolled way, /var/run is deleted,
but /var/lib/postgres/data/postmaster.pid is not. PostgreSQL will refuse
to start at the next boot even if it could recover from its journal.


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1)

Versions of packages postgresql depends on:
ii  adduser  3.63Add and remove users and groups
ii  debconf [debconf 1.4.30.13   Debian configuration management sy
ii  debianutils  2.8.4   Miscellaneous utilities specific t
ii  dpkg 1.10.28 Package maintenance system for Deb
ii  libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii  libcomerr2   1.37-2sarge1common error description library
ii  libkrb53 1.3.6-2sarge2   MIT Kerberos runtime libraries
ii  libpam0g 0.76-22 Pluggable Authentication Modules l
ii  libperl5.8   5.8.4-8 Shared Perl library
ii  libpq3   7.4.7-6sarge1   PostgreSQL C client library
ii  libreadline4 4.3-11  GNU readline and history libraries
ii  libssl0.9.7  0.9.7e-3SSL shared libraries
ii  mailx1:8.1.2-0.20040524cvs-4 A simple mail user agent
ii  postgresql-clien 7.4.7-6sarge1   front-end programs for PostgreSQL
ii  procps   1:3.2.1-2   The /proc file system utilities
ii  python2.32.3.5-3 An interactive high-level object-o
ii  ucf  1.17Update Configuration File: preserv
ii  zlib1g   1:1.2.2-4.sarge.2   compression library - runtime

-- debconf information:
* postgresql/upgrade/preserve_location: /var/lib/postgres/preserve
* postgresql/settings/day_month_order: European
* postgresql/upgrade/policy: true
  postgresql/enable_lang: true
  postgresql/very_old_version_warning: true
* postgresql/upgrade/dump_location: /var/lib/postgres/
  postgresql/convert-pg_hba.conf: true
  postgresql/initdb/location: /var/lib/postgres/data
* postgresql/settings/locale: fr_CH.iso88591
* postgresql/purge_data_too: false


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



Bug#298836: apachectl: remaining temporary directories with long status page

2005-03-10 Thread Marc SCHAEFER
Package: apache
Version: 1.3.26-0woody6.cril0
Severity: minor
Tags: patch

Hi,

with a long status page, such as 15 kilobytes, the result of starting

   /usr/sbin/apachectl status

is that spurious (empty) temporary directories remain in /tmp.

The problem is because apachectl status starts lynx -dump, which creates
and normally removes a temporary directory. However, when there is much
data sent by lynx to stdout to a pipe to apachectl, the current
apachectl implementation breaks the pipe in the middle, killing lynx.

Here is a work-around to ignore spurious lynx data instead of abruptly
closing the pipe:

--- /usr/sbin/apachectl.ORIGThu Mar 10 10:29:35 2005
+++ /usr/sbin/apachectl Thu Mar 10 10:32:19 2005
@@ -136,7 +136,18 @@
fi
;;
 status)
-   $LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '
+# Work-around for lynx killed because of broken pipe; doesn't
+   # remove the /tmp/.. (6 chars) directory.
+   $LYNX $STATUSURL | awk 'BEGIN { has_finished = 0; }
+   /process$/ { if (!has_finished) {
+   print;
+   has_finished = 1;
+}
+  }
+   { if (!has_finished) {
+ print;
+ }
+   } '
;;
 fullstatus)
$LYNX $STATUSURL

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux defian 2.4.21 #1 Tue Apr 20 15:30:51 MEST 2004 i686
Locale: LANG=C, LC_CTYPE=fr_CH

Versions of packages apache depends on:
ii  apache-common   1.3.26-0woody6.cril0 Support files for all Apache webse
ii  dpkg1.9.21   Package maintenance system for Deb
ii  libc6   2.2.5-11.8   GNU C Library: Shared libraries an
ii  libdb2  2:2.7.7.0-7  The Berkeley database routines (ru
ii  libexpat1   1.95.2-6 XML parsing C library - runtime li
ii  logrotate   3.5.9-8  Log rotation utility
ii  mime-support3.18-1.3 MIME files 'mime.types'  'mailcap
ii  perl5.6.1-8.8Larry Wall's Practical Extraction 
ii  perl [perl5]5.6.1-8.8Larry Wall's Practical Extraction 



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



Bug#292730: installation-reports: install ok; SiS900 Ethernet hack for MAC addr

2005-01-29 Thread Marc SCHAEFER
Package: installation-reports
Severity: important


Apparently, the 2.4.27 kernel in RC2 (at least)  and also 2.4.27-2-k7 
has a faulty sis900 driver which is unable to extract the MAC address 
from the NVRAM.

   eth0: SiS 900 PCI Fast Ethernet at 0xd400, IRQ 19, ff:ff:ff:ff:ff:ff.

This means that the installation is difficult with CDs (no net access) 
or impossible (netinst CD in my case).

A temporary work-around exists:

   beast1:/home/schaefer# cat /etc/rcS.d/S39macaddress 
   #! /bin/sh

   case $1 in
  start) echo Setting up buggy MAC address for now ...
 ifconfig eth0 hw ether 00:00:00:00:00:42;;
   esac

(don't forget to chmod a+rx /etc/rcS.d/S39macaddress and reboot)

However obviously the :42 here is a bad choice.  AFAIK there was a 
discussion and a patch in linux-kernel haven't tried it yet.

Notably people with an K7S41GX or similar from ASrock motherboard will 
experience this issue.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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