Bug#994030: man-db: error while loading shared libraries: libmandb-2.9.4.so

[BERTRAND Joël]

Thanks a lot for your answer.

I have added "network," in the three sections of
/etc/apparmor.d/usr.bin.man and man runs now as expected.

Best regards,

JB

Bug#994030: man-db: error while loading shared libraries: libmandb-2.9.4.so

[BERTRAND Joël]

Package: man-db
Version: 2.9.4-2
Severity: important

Dear Maintainer,

Since a few days (if I remember since I have upgraded my workstation
to last testing release), man aborts with folloging message:

Root hilbert:[~] > man man
man: error while loading shared libraries: libmandb-2.9.4.so: cannot open 
shared object file: Permission denied

This workstation is a diskless workstation. Rootfs is exported by a NetBSD
server.

strace shows that man binary tries to open libmandb-2.9.4.so in
following directories:
- /usr/lib/man-db/tls/haswell/x86_64/
- /usr/lib/man-db/tls/haswell/
- /usr/lib/man-db/tls/x86_64/
- /usr/lib/man-db/tls/
- /usr/lib/man-db/haswell/x86_64/
- /usr/lib/man-db/haswell/
- /usr/lib/man-db/x86_64/
- /usr/lib/man-db/
- /lib/x86_64-linux-gnu/tls/haswell/x86_64/
- /lib/x86_64-linux-gnu/tls/haswell/
- /lib/x86_64-linux-gnu/tls/x86_64/
- /lib/x86_64-linux-gnu/tls/
- /lib/x86_64-linux-gnu/haswell/x86_64/
- /lib/x86_64-linux-gnu/haswell/
- /lib/x86_64-linux-gnu/x86_64/
- /lib/x86_64-linux-gnu/
- /usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/
- /usr/lib/x86_64-linux-gnu/tls/haswell/
- /usr/lib/x86_64-linux-gnu/tls/x86_64/
- /usr/lib/x86_64-linux-gnu/tls/
- /usr/lib/x86_64-linux-gnu/haswell/x86_64/
- /usr/lib/x86_64-linux-gnu/haswell/
- /usr/lib/x86_64-linux-gnu/x86_64/
- /usr/lib/x86_64-linux-gnu/
- /lib/tls/haswell/x86_64/
- /lib/tls/haswell/
- /lib/tls/x86_64/
- /lib/tls/
- /lib/haswell/x86_64/
- /lib/haswell/
- /lib/x86_64/
- /lib/
- /usr/lib/tls/haswell/x86_64/
- /usr/lib/tls/haswell/
- /usr/lib/tls/x86_64/
- /usr/lib/tls/
- /usr/lib/haswell/x86_64/
- /usr/lib/haswell/
- /usr/lib/x86_64/
- /usr/lib/

libmandb-2.9.4.so is in my case in /usr/lib/man-db/ and libmandb-2.9.4.so and
seems to be a dynamic library:
Root hilbert:[/usr/lib] > ls -al /usr/lib/man-db/libmandb-2.9.4.so
-rw-r--r-- 1 root root 30712 19 févr.  2021 /usr/lib/man-db/libmandb-2.9.4.so
Root hilbert:[/usr/lib] > file /usr/lib/man-db/libmandb-2.9.4.so
/usr/lib/man-db/libmandb-2.9.4.so: ELF 64-bit LSB shared object, x86-64, 
version 1 (SYSV), dynamically linked, 
BuildID[sha1]=c20b1c94193b241e4e17834335605b9d68db1632, stripped

I have tried to force library preload with:
Root hilbert:[~] > LD_PRELOAD=/usr/lib/man-db/libmandb-2.9.4.so man man
ERROR: ld.so: object '/usr/lib/man-db/libmandb-2.9.4.so' from LD_PRELOAD cannot 
be preloaded (cannot open shared object file): ignored.
man: error while loading shared libraries: libmandb-2.9.4.so: cannot open 
shared object file: Permission denied

Help will be welcome.

Best regards,

JB

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

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

Versions of packages man-db depends on:
ii  bsdextrautils  2.37.2-1
ii  bsdmainutils   12.1.7+nmu3
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  groff-base 1.22.4-6
ii  libc6  2.31-17
ii  libgdbm6   1.20-1
ii  libpipeline1   1.5.3-1
ii  libseccomp22.5.1-1
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   3.0.3-2
ii  chromium [www-browser] 90.0.4430.212-1
ii  firefox-mozilla-build [www-browser]92.0-0ubuntu1
pn  groff  
ii  konqueror [www-browser]4:21.08.0-1
ii  less   551-2
ii  seamonkey-mozilla-build [www-browser]  2.53.9-0ubuntu1

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

Bug#961028: hplip: No scanner found: SANE cannot load the hpaio backend

[BERTRAND Joël]

Hello,

Same constatation here with a LaserJet CM2320. I haven't found a 
solution

Best regards,

JB

Bug#926928: fetchmail: Server CommonName mismatch

[BERTRAND Joël]

Thanks for your answer.

I have replaced pop.nerim.fr by pop.nerim.net and it works as expected.
This configuration worked fine with pop.nerim.fr for a very long time
until last upgrade of feetchmail.

Best regards,

JB

Bug#926928: fetchmail: Server CommonName mismatch

[BERTRAND Joël]

Package: fetchmail
Version: 6.4.0~beta4-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I use ferchmail for a while and I have seen in syslog that fetchmail
returns errors:

fetchmail: Loaded OpenSSL library 0x1010102f newer than headers 0x1010101f, 
trying to continue.
fetchmail: SSL verify callback depth 0: preverify_ok == 0, err = 62, Hostname 
mismatch
fetchmail: Server certificate:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: RapidSSL RSA CA 2018
fetchmail: Subject CommonName: *.nerim.net
fetchmail: Subject Alternative Name: *.nerim.net
fetchmail: Subject Alternative Name: nerim.net
fetchmail: Server CommonName mismatch: *.nerim.net != pop.nerim.fr
fetchmail: pop.nerim.fr key fingerprint: 
D8:9B:28:28:4C:DF:07:5E:BC:87:6C:11:7C:A1:8E:BE
fetchmail: Server certificate verification error: Hostname mismatch
fetchmail: OpenSSL reported: error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed
fetchmail: pop.nerim.fr: upgrade to TLS failed.

and, of course, fetchmail stops transaction.

I haven't find a solution to fix this issue.

Best regards,

JB

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.1
ii  libc6 2.28-8
ii  libcom-err2   1.44.5-1
ii  libgssapi-krb5-2  1.17-2
ii  libk5crypto3  1.17-2
ii  libkrb5-3 1.17-2
ii  libssl1.1 1.1.1b-1
ii  lsb-base  10.2019031300

Versions of packages fetchmail recommends:
ii  ca-certificates  20190110

Versions of packages fetchmail suggests:
pn  fetchmailconf
pn  resolvconf   
ii  sendmail-bin [mail-transport-agent]  8.15.2-12

-- Configuration Files:
/etc/default/fetchmail [Errno 13] Permission non accordée: 
'/etc/default/fetchmail'
/etc/init.d/fetchmail changed [not included]

-- no debconf information

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gabriel Filion a écrit :
> On 2019-03-26 2:43 p.m., Gabriel Filion wrote:
>> Did you recently upgrade smokeping? if so what version were you
>> using before? (maybe check your dpkg logs for signs of upgrade of
>> the smokeping package)
> 
> I just thought of something else: if you were using the 2.7.3-1
> package previously, it's possible that the service was running as
> root (which was fixed in -2 so that it would run as
> "smokeping:smokeping")
> 
> maybe check ownership of the /run/smokeping directory to see if it
> is owned by root. If it is, then rmdir the directory before
> restarting the service.
> 
> There might be other files owned by root, too. Check out files in 
> smokeping's data directory, /var/lib/smokeping/. if anything in
> there is owned by root, run a chown -R smokeping:smokeping -- but
> make sure to avoid squashing the group on /var/lib/smokeping/__cgi
> and anything inside : they should be owned by smokeping but have
> their group set to www-data and the __cgi directory should have the
> group sticky bit set (e.g. mode 2775)

Unfortunately, all files required by smokeping are owned by smokeping
user.

Best regards,

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAlyafX4ACgkQOAfo0lKQ
8+cb5g//ax8e4ukzmq7lBwSZLWlZ84CleFWGz+8SdjqH9CE8nPiUE18l+gl/3CLJ
FZlpTfdvZ9YIhl5/sE02/nv7aBIGqLhH7arclXyltOFerlOX4WiHHVkiOjW6Fgjt
1KrXjhM3YlBvUr7DOvEMAgV/p1z0XKH81VFi7cV6NXY1IVR2pM1+44zj4JZau36r
cjMojrnahQZN3wEkS1edl6OLStwKBAaWzlgrhE8nH/U+dKZ0XfqzkE9f4ANS6fgQ
EBd3sOeglYePvDh1Xy1n3ZvRAyIP8VXacV9+9hAPLkMBsY9LZXIeO1w2pwDTAFad
9e6hZfkdX99PHagAfRfcDpnhrH4wBa81d+uPzE4rQt7LknEYW5qT5IMOCad1zFmq
zdbV3B2hfmeXu09jXwwNm6mpo6l9cFPPIkCxEMW9UQbYgvWRbsiBf8yXugdCm67j
5awffUXu+1TzVIjWgTxRdz/qPUN9O9oQFvnuesfvbEjPBLqief9d5puhi7IE+o6/
PdsAZH+4ia5fB8+DM/tu4MomaQwjRVlQmjNZ5ES54eVmd3IsdUl9A4atKIJhOZpK
aDuorXY3tlouR0AQSodXVw9WDKe9j4CY73XIOmf52NRKp38Q923qoTVGtPULHgv4
IQ2VPVAgj8+8icZyN8Zc52ukGdlEmzr/1o+ySdeph8r6uqVoEC0=
=9CBl
-END PGP SIGNATURE-

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gabriel Filion a écrit :
> Hi Bertrand,

Hello,

> e.g. the file is in /run/smokeping and systemd is able to use it
> to restart the servce.

In my case, systemd doesn't create /run/smokeping.

> Did you recently upgrade smokeping? if so what version were you
> using before? (maybe check your dpkg logs for signs of upgrade of
> the smokeping package)

Yes, I have.

- -> 2019-03-17 03:26:38 upgrade smokeping:all 2.7.2-3 2.7.3-2

> Do you have an override in place for the smokeping.service systemd
> unit? "service smokeping status" will show you if there is an
> override in place. e.g. it would look similar to this:
> 
> root@debian-10-amd64:~# service smokeping status ●
> smokeping.service - Latency Logging and Graphing System Loaded:
> loaded (/lib/systemd/system/smokeping.service; enabled; vendor
> preset: enabled) Drop-In: /etc/systemd/system/smokeping.service.d 
> └─slave_mode.conf

Root rayleigh:[/var/log] > service smokeping status
● smokeping.service - Latency Logging and Graphing System
   Loaded: loaded (/lib/systemd/system/smokeping.service; enabled;
vendor preset: enabled)
   Active: failed (Result: timeout) since Sun 2019-03-24 18:06:51 CET;
2 days ago
 Docs: man:smokeping(1)
   file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf

Warning: Journal has been rotated since unit was started. Log output
is incomplete or unavailable.

Best regards,

JKB

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAlyafNcACgkQOAfo0lKQ
8+f8eQ/+M+YgJT50Uu3+2b9n926Vz0o4oU8egqPRga1eTVoip5PxJZU7nmrEiJCO
bNsEgIFNTQfyWDsCMCsPBJmzC9c3JmgOwxaTmPyHTSJEGS1s1uztg+62k3dE7ynO
SYd2INd7ybopg8IQaJr6rJAP261pVKDhd5L1Lafa5wXna1JkNuMa8fuDl92vh+uq
zj6fCsEh5F3UrI0TEmoLDmImKRTnkrQuhn1KpCyiiZSnziRRT37oNRgR859ZX8sh
+yl2HKjtZ9XKZuVyIAldKNA2qUOEXOjEmnHUsyeuzlQeXxnkMzv4yLp0X7aJQbWk
ZQ9QLgX6Wi7POKSddeq1FysLNtIv3PXMaYire/pUyayd5ZVOQBeWVrKv0V8WUNkJ
TKFSi3l0qM7o5MeLkslTg/JsPpkKBpenjOSMn/zmUzLXmi3Pr9bOZKh1bYLpmh6f
Ezxb+OlzQsLfBtKkRGE9UIv/duUVWhPziaNWpSDL2RpAjtCYLO0bbI+dXLE2WFnS
EupDYt2TQx8yFF8SjF360IsD2Yee0+zmgbiKqgxDcqX79Bj/10ztwYFRM0L9Lz3C
sTjj8Rgb/yXYgEOUIGOGasmIqrX+0IXnzR3F8gGnrzKMTb2Ps/AzABbdMzbv5EPD
PRtlvE3Le3k1AL/CqKXzyKjmacym2uPikU7lcU47SxzQR5j2EkU=
=jDwr
-END PGP SIGNATURE-

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[BERTRAND Joël]

Package: smokeping
Version: 2.7.3-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I have restarted a server last sunday and I have seen that smokeping doesn't
start anymore.

In systemd config file, smokeping is launched with --pid-dir=/run/smokeping and
systemd complains about non existent pid file.

I have tried to launch smokeping in command line :
[~] > /usr/sbin/smokeping --pid-dpid-dir=/run/smokepingir=/run/smokeping

and pid file is created in... /run and not in /run/smokeping, that confuses
systemd.

Best regards,

JB

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

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

Versions of packages smokeping depends on:
ii  adduser  3.118
ii  debianutils  4.8.6.1
ii  fping4.2-1
ii  libcgi-fast-perl 1:2.13-1
ii  libconfig-grammar-perl   1.12-2
ii  libdigest-hmac-perl  1.03+dfsg-2
ii  libjs-cropper1.2.2-1
ii  libjs-prototype  1.7.1-3
ii  libjs-scriptaculous  1.9.0-2
ii  librrds-perl 1.7.1-1
ii  libsnmp-session-perl 1.14~git20130523.186a005-4
ii  liburi-perl  1.76-1
ii  libwww-perl  6.36-1
ii  lsb-base 10.2019031300
ii  perl 5.28.1-4
ii  sendmail-bin [mail-transport-agent]  8.15.2-12
ii  ucf  3.0038+nmu1

Versions of packages smokeping recommends:
ii  apache2 [httpd-cgi]  2.4.38-2
ii  dnsutils 1:9.11.5.P4+dfsg-1
ii  echoping 6.0.2-10
ii  libsocket6-perl  0.29-1+b1

Versions of packages smokeping suggests:
pn  curl   
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.060-3
ii  libnet-dns-perl1.19-1
pn  libnet-ldap-perl   
ii  libnet-telnet-perl 3.04-1
ii  openssh-client 1:7.9p1-9

-- Configuration Files:
/etc/smokeping/basepage.html changed [not included]
/etc/smokeping/config.d/Alerts changed [not included]
/etc/smokeping/config.d/General changed [not included]
/etc/smokeping/config.d/Presentation changed [not included]
/etc/smokeping/config.d/Probes changed [not included]
/etc/smokeping/config.d/Slaves changed [not included]
/etc/smokeping/config.d/Targets changed [not included]
/etc/smokeping/config.d/pathnames changed [not included]
/etc/smokeping/smokemail changed [not included]
/etc/smokeping/smokeping_secrets [Errno 13] Permission non accordée: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[BERTRAND Joël]

Kurt Roeckx a écrit :
> On Sat, Nov 10, 2018 at 08:17:19PM +0100, BERTRAND Joël wrote:
>> Kurt Roeckx a écrit :
>>> On Thu, Nov 08, 2018 at 06:36:52PM +0100, Kurt Roeckx wrote:
>>>> On Thu, Nov 08, 2018 at 06:10:29PM +0100, BERTRAND Joël wrote:
>>>>> Kurt Roeckx a écrit :
>>>>>> On Wed, Nov 07, 2018 at 11:21:44AM +0100, BERTRAND Joël wrote:
>>>>>>> Nov  7 09:17:31 rayleigh sm-mta[10148]: ruleset=try_tls, 
>>>>>>> arg1=smtp-in.orange.fr, relay=smtp-in.orange.fr, reject=550 5.7.1 
>>>>>>> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
>>>>>>> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: 
>>>>>>> to=, delay=23:52:05, xdelay=00:00:01, mailer=esmtp, 
>>>>>>> pri=77460547, relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, 
>>>>>>> stat=Service unavailable
>>>>>>
>>>>>> That server only seems to support TLS 1.0.
>>>>>>
>>>>>> Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
>>>>>>
>>>>>> Anyway, I suggest you file a bug against sendmail to override the
>>>>>> defaults.
>>>>>
>>>>>   I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
>>>>> workarounds without any success.
>>>>
>>>> And you restarted sendmail after changing /etc/ssl/openssl.cfg?
>>>
>>> Any update on this?
>>
>>  Of course, I have updated /etc/ssl/openssl.cfg with suggestions in NEWS
>> file and restarted sendmail without success.
> 
> All I can say is that if I change both values to the value from
> NEWS, I can connect to it, otherwise I can't.

I have changed _both_ values and I cannot connect to orange.fr or
hotmail.com with sendmail. If I use stable package, sendmail runs as
expected.

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[BERTRAND Joël]

Kurt Roeckx a écrit :
> On Thu, Nov 08, 2018 at 06:36:52PM +0100, Kurt Roeckx wrote:
>> On Thu, Nov 08, 2018 at 06:10:29PM +0100, BERTRAND Joël wrote:
>>> Kurt Roeckx a écrit :
>>>> On Wed, Nov 07, 2018 at 11:21:44AM +0100, BERTRAND Joël wrote:
>>>>> Nov  7 09:17:31 rayleigh sm-mta[10148]: ruleset=try_tls, 
>>>>> arg1=smtp-in.orange.fr, relay=smtp-in.orange.fr, reject=550 5.7.1 
>>>>> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
>>>>> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: 
>>>>> to=, delay=23:52:05, xdelay=00:00:01, mailer=esmtp, 
>>>>> pri=77460547, relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, 
>>>>> stat=Service unavailable
>>>>
>>>> That server only seems to support TLS 1.0.
>>>>
>>>> Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
>>>>
>>>> Anyway, I suggest you file a bug against sendmail to override the
>>>> defaults.
>>>
>>> I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
>>> workarounds without any success.
>>
>> And you restarted sendmail after changing /etc/ssl/openssl.cfg?
> 
> Any update on this?

Of course, I have updated /etc/ssl/openssl.cfg with suggestions in NEWS
file and restarted sendmail without success.

JKB

Bug#913129: [Pkg-openssl-devel] Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[BERTRAND Joël]

Kurt Roeckx a écrit :
> On Wed, Nov 07, 2018 at 11:21:44AM +0100, BERTRAND Joël wrote:
>> Nov  7 09:17:31 rayleigh sm-mta[10148]: ruleset=try_tls, 
>> arg1=smtp-in.orange.fr, relay=smtp-in.orange.fr, reject=550 5.7.1 
>> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
>> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: to=, 
>> delay=23:52:05, xdelay=00:00:01, mailer=esmtp, pri=77460547, 
>> relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, stat=Service unavailable
> 
> That server only seems to support TLS 1.0.
> 
> Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
> 
> Anyway, I suggest you file a bug against sendmail to override the
> defaults.

I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
workarounds without any success. It's not a sendmail's bug but a
regression of debian's openssl.

Regards,

JKB

Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[BERTRAND Joël]

Package: openssl
Version: 1.1.1-2
Severity: important

Dear Maintainer,

Last saturday, I have upgraded my testing server. This server acts as a mail
server running sendmail.

With stable openssl package, my server ran fine. With new package, sendmail
returns the obvious message :

dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed

I have removed TLS from SMTP configuration (Try_TLS: NO in /etc/mail/access) but
some MX requires TLS and I'm unable to send message to several MX. For rexample
orange.fr :

Nov  7 09:17:31 rayleigh sm-mta[10148]: ruleset=try_tls, 
arg1=smtp-in.orange.fr, relay=smtp-in.orange.fr, reject=550 5.7.1 
... do not try TLS with smtp-in.orange.fr [80.12.242.9]
Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: to=, 
delay=23:52:05, xdelay=00:00:01, mailer=esmtp, pri=77460547, 
relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, stat=Service unavailable

Second constatation : I use a patch (from sendmail 8.16) that allow sendmail to
automatically disable TLS when 4.7.0 error occurs.

With stable openssl, when sendmail tries to send message, SMTP always receives :
... dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed.

With testing package, sendmail randomly receives :
... dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed
or
... dsn=4.0.0, stat=Deferred

Of course, I have read openssl installation instructions, but I haven't
found any workaround.

If I downgrade openssl to openssl_1.1.0f-3+deb9u2_amd64.deb, sendmail 
runs
as expected.

Best regards,

JKB

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

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

Versions of packages openssl depends on:
ii  libc6  2.27-8
ii  libssl1.1  1.1.1-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20170717

-- no debconf information

Bug#906436: 906436: nis: /etc/init.d/nis doesn't start ypbind, thus ypwhich timeouts

[BERTRAND Joël]

Michael Biebl a écrit :
> On 8/21/18 16:50, Nuno Oliveira wrote:
>> Michael, please update the /etc/default/nis in your package
>> accordingly:  host:~> diff /etc/default/nis
>> /etc/default/nis.orig 28,29c28 < #YPBINDARGS=-no-dbus <
>> YPBINDARGS= ---
>>> YPBINDARGS=-no-dbus
>> 
>> 
>> For me this solves the problem with the client. I will update the
>> server later and report any problems.
> 
> This sounds like a reasonable explanation, thanks Nuno for
> investigating ths. While technically, nis is not "my package", I
> can make a follow-up upload which updates /etc/default/nis
> accordingly.
> 
> Bertrand, Thomas, can you confirm that removing "--no-dbus" fixes
> the issue for you as well?
> 
> Michael
> 

I confirm this patch fixes ypbind issue on my workstation.

Thanks a lot,

JB

Bug#906436: nis: /etc/init.d/nis doesn't start ypbind, thus ypwhich timeouts

[BERTRAND Joël]

Package: nis
Version: 3.17.1-2
Severity: important

Dear Maintainer,

I use a NetBSD NIS server for a long time. This servers acts as a NIS server
(master) and some workstations use it (Linux, FreeBSD...).

I have noticed this evening that my Debian Buster was unable to use this server
anymore.

When I start nis, I obtain in log :
Aug 17 17:20:08 hilbert systemd[1]: Starting LSB: Start NIS client and server 
daemons
Aug 17 17:20:20 hilbert nis[3775]: Starting NIS services: ypbindbinding to YP 
server...failed (backgrounded).
Aug 17 17:20:20 hilbert nis[3775]: .

I think that /etc/init.d/nis script tries to use ypwhich before starting
ypbind. Thus, ypwhich returns :

root@hilbert:~# LANG=C ypwhich
ypwhich: Can't communicate with ypbind

If I manually start ypbind with ypbind -d -broadcast, I obtain :
root@hilbert:~# ypbind -d -broadcast
4388: add_server() domain: systella.fr, broadcast
4388: [Welcome to ypbind-mt, version 1.38]

4388: ping interval is 20 seconds

4388: rebind interval is 900 seconds

4390: do_broadcast() for domain 'systella.fr' is called
4390: Answer for domain 'systella.fr' from server 'legendre.systella.fr'
4390: leave do_broadcast() for domain 'systella.fr'
4388: ypbindproc_domain_2_svc (systella.fr)
4388: Pinging all active servers.
4388: YPBINDPROC_DOMAIN: server '192.168.10.128', port 754
4388: Status: YPBIND_SUCC_VAL
4390: Pinging all active servers.
4390: Pinging all active servers.

and ypwhich runs as expected :

hilbert:[~] > LANG=C ypwhich
legendre.systella.fr
hilbert:[~] >

Best regards,

JB

-- Package-specific info:

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

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

Versions of packages nis depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  hostname   3.20
ii  libc6  2.27-5
ii  libgdbm5   1.14.1-6+b1
ii  libsystemd0239-7
ii  lsb-base   9.20170808
ii  make   4.2.1-1.2
ii  netbase5.4
ii  rpcbind [portmap]  0.2.3-0.6

nis recommends no packages.

Versions of packages nis suggests:
pn  nscd  

-- debconf information:
* nis/domain: systella.fr

Bug#905457: munin: general protection fault

[BERTRAND Joël]

Lars Kruse a écrit :
> Hello Bertrand,
> 
> 
> Am Sun, 5 Aug 2018 10:01:58 +0200
> schrieb BERTRAND Joël :
> 
>> Yesterday, after my bug report, I have done a apt dist-upgrade and this
>> message disappears. Very strange, perl and munin were not upgraded.
> 
> What a pity - this issue looked mysteriously interesting :)
> 
> I fail to have an idea, which kind of magic could have pushed this error
> message line to your log.
> 
> Let's agree on closing this bug as "unreproducible" and hoping for the monster
> to never return again?
Of course, you can close this bug.

JKB

Bug#905457: munin: general protection fault

[BERTRAND Joël]

Lars Kruse a écrit :
> Package: munin
> Followup-For: Bug #905457
> 
> Hello Bertrand,

Hello Lars,

> On Sat, 04 Aug 2018 22:35:54 +0200, BERTRAND Joël wrote,
> 
>> I don't understand why perl tries to run /usr/sbin/munin, there is no
>> such script nor executable.
> 
> indeed there is no such file shipped in any munin package.
> 
> I just tried to reproduce this issue on a fresh and up-to-date buster
> system. But I failed to find this log message here on my host.
> 
> I could only imagine the following two sources of this log messages
> (both of which feel equally unlikely):
> 1) a locally installed munin plugin

I don't have this kind of plugins.

> 2) a cron-job that is not related to the packaged "munin-cron"
> 
> For 1) you could take a look at /etc/munin/plugins/ and check for
> non-packaged plugins.
> For 2) you could temporarily disable the "munin-cron" cron job and check
> whether the mysterious log message still appears.
> 
> Or maybe you have a different idea how to trace the origin of this
> message?

Yesterday, after my bug report, I have done a apt dist-upgrade and this
message disappears. Very strange, perl and munin were not upgraded.

Best regards,

JB

Bug#905457: munin: general protection fault

[BERTRAND Joël]

Package: munin
Version: 2.0.37-2
Severity: important

Dear Maintainer,

I run debian testing (buster) and since a few days, munin doesn't run as
expected. In syslog, I have a lot of :

Aug  4 22:35:01 rayleigh CRON[11229]: (munin) CMD (if [ -x /usr/bin/munin-cron 
]; then /usr/bin/munin-cron; fi > /dev/null 2>&1)
Aug  4 22:35:02 rayleigh kernel: [986015.327521] traps: /usr/sbin/munin[11238] 
general protection ip:559e936f2282 sp:71816870 error:0 in 
perl[559e93627000+1f8000]
Aug

I don't understand why perl tries to run /usr/sbin/munin, there is no such
script nor executable.

Best regards,

JB

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages munin depends on:
ii  cron [cron-daemon]3.0pl1-130
ii  fonts-dejavu-core 2.37-1
ii  libdate-manip-perl6.72-1
pn  libdigest-md5-perl
ii  libfile-copy-recursive-perl   0.44-1
ii  libhtml-template-perl 2.97-1
ii  libio-socket-inet6-perl   2.72-2
ii  liblog-log4perl-perl  1.49-1
ii  libperl5.22 [libtime-hires-perl]  5.22.2-5
ii  libperl5.24 [libtime-hires-perl]  5.24.1-7
ii  librrds-perl  1.7.0-1+b2
pn  libstorable-perl  
ii  liburi-perl   1.74-1
ii  lsb-base  9.20170808
ii  munin-common  2.0.37-2
ii  perl [libtime-hires-perl] 5.26.2-6
ii  rrdtool   1.7.0-1+b2
ii  systemd-sysv  239-7

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.13-1
ii  munin-doc 2.0.37-2
ii  munin-node2.0.37-2

Versions of packages munin suggests:
iu  apache2 [httpd]2.4.34-1
ii  elinks [www-browser]   0.12~pre6-13
ii  firefox [www-browser]  61.0.1-1
ii  iceape [www-browser]   2.7.12-1+b1
ii  konqueror [www-browser]4:18.04.0-1
pn  libapache2-mod-fcgid   
ii  libnet-ssleay-perl 1.85-1
ii  links [www-browser]2.16-1
ii  lynx [www-browser] 2.8.9rel.1-1
ii  seamonkey-mozilla-build [www-browser]  2.49.3-0ubuntu1
ii  w3m [www-browser]  0.5.3-36+b1

-- Configuration Files:
/etc/cron.d/munin changed:
MAILTO=root
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; 
fi > /dev/null 2>&1
14 10 * * * munin if [ -x /usr/share/munin/munin-limits ]; then 
/usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi

/etc/munin/munin.conf changed:
dbdir   /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir  /var/run/munin
tmpldir /etc/munin/templates
staticdir /etc/munin/static
cgitmpdir /var/lib/munin/cgi-tmp
includedir /etc/munin/munin-conf.d
graph_period second
graph_strategy cron
munin_cgi_graph_jobs 6
html_strategy cron
[rayleigh.systella.fr]
address 127.0.0.1
use_node_name yes
[legendre.systella.fr]
address 192.168.1.2
use_node_name yes
[pythagore.systella.fr]
address 192.168.10.102
use_node_name yes
[cervantes.systella.net]
address 192.168.2.5
use_node_name yes


-- no debconf information

Bug#904214: zoneminder: After last zoneminder upgrade, it doesn't start anymore

[BERTRAND Joël]

Package: zoneminder
Version: 1.30.4+dfsg1-4
Severity: important

Dear Maintainer,

I use Zoneminder for a long time. My first installation was a clean installation
without debian package as zoneminder wasn't packaged, but since debian team
has provided deb package, I use it.

Thus I have reinstall my zoneminder server with debian Buster. This server
ran without any trouble during several months. Last week, I have done a
dist-upgrade and I have seen that zoneminder was upgraded.

I have rebooted my server this afternoon and zoneminder refuses to start.

Logs :
2018-07-21 20:03:05.330840 zmwatch  4680 INF Restarting capture daemon for Rue, 
shared data not valid zmwatch.pl
2018-07-21 20:03:05.329790 zmwatch  4680 ERR Memory map file 
'/dev/shm/zm.mmap.2' does not exist. zmc might not be running. zmwatch.pl
2018-07-21 20:02:49.239550 zmdc  4634 ERR 'zma -m 2' exited abnormally, exit 
status 255 zmdc.pl
2018-07-21 20:02:49.236504 undef  4708 ERR Attempt to fetch boolean value for 
ZM_WEB_EVENT_DISK_SPACE, actual type is string. Try running 'zmupdate.pl -f' to 
reload config. zm_config.cpp 204
2018-07-21 20:02:49.230420 zmdc  4634 ERR 'zmc -d /dev/video0' exited 
abnormally, exit status 255 zmdc.pl
2018-07-21 20:02:49.227190 undef  4707 ERR Attempt to fetch boolean value for 
ZM_WEB_EVENT_DISK_SPACE, actual type is string. Try running 'zmupdate.pl -f' to 
reload config. zm_config.cpp 204
2018-07-21 20:02:49.029600 zmdc  4708 INF 'zma -m 2' started at 18/07/21 
20:02:49 zmdc.pl
2018-07-21 20:02:49.028660 zmdc  4634 INF 'zma -m 2' starting at 18/07/21 
20:02:49, pid = 4708 zmdc.pl
2018-07-21 20:02:49.025030 zmdc  4634 INF Starting pending process, zma -m 2 
zmdc.pl
2018-07-21 20:02:49.023730 zmdc  4707 INF 'zmc -d /dev/video0' started at 
18/07/21 20:02:49 zmdc.pl
2018-07-21 20:02:49.023720 zmdc  4634 INF 'zmc -d /dev/video0' starting at 
18/07/21 20:02:49, pid = 4707 zmdc.pl
2018-07-21 20:02:49.018660 zmdc  4634 INF Starting pending process, zmc -d 
/dev/video0 zmdc.pl
2018-07-21 20:02:39.205110 zmdc  4634 ERR 'zma -m 2' exited abnormally, exit 
status 255 zmdc.pl
2018-07-21 20:02:39.201951 undef  4705 ERR Attempt to fetch boolean value for 
ZM_WEB_EVENT_DISK_SPACE, actual type is string. Try running 'zmupdate.pl -f' to 
reload config. zm_config.cpp 204
2018-07-21 20:02:39.198070 zmdc  4634 ERR 'zmc -d /dev/video0' exited 
abnormally, exit status 255 zmdc.pl
2018-07-21 20:02:39.194731 undef  4704 ERR Attempt to fetch boolean value for 
ZM_WEB_EVENT_DISK_SPACE, actual type is string. Try running 'zmupdate.pl -f' to 
reload config. zm_config.cpp 204

Shared memory segment is not created as zmc -d /dev/video0 aborts without
any message (maybe 'Attempt to fetch boolean value for ZM_WEB_EVENT_DISK_SPACE'
is related to this bug but I'm not sure, I have tried to modify this parameter
without success).

Faulty package is 1.30.4+dfsg1-4. On a second server that runs Debian/Buster
and zoneminder 1.30.4+dfsg-2+b2, I haven't this kind of trouble.

Best regards,

JB

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

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

Versions of packages zoneminder depends on:
ii  cakephp 2.10.11-2
ii  fonts-glewlwyd  1.4.4-3
ii  javascript-common   11
ii  libarchive-zip-perl 1.60-1
ii  libavcodec577:3.4.3-1
ii  libavformat57   7:3.4.3-1
ii  libavutil55 7:3.4.3-1
ii  libc6   2.27-3
ii  libclass-std-fast-perl  0.0.8-2
ii  libcurl3-gnutls 7.60.0-2
ii  libdata-dump-perl   1.23-1
ii  libdate-manip-perl  6.72-1
ii  libdbd-mysql-perl   4.046-1
ii  libdevice-serialport-perl   1.04-3+b5
pn  libdigest-sha-perl  
ii  libgcc1 1:8.1.0-10
ii  libgcrypt20 1.8.3-1
ii  libgnutls-openssl27 3.5.18-1
ii  libimage-info-perl  1.41-1
ii  libio-socket-multicast-perl 1.12-2+b4
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libjson-any-perl1.39-1
ii  libmariadbclient18  1:10.1.29-6+b1
ii  libmime-lite-perl   3.030-2
ii  libmime-tools-perl  5.509-1
ii  libnet-sftp-foreign-perl1.89+dfsg-1
ii  

Bug#897123: linux-image-4.15.0-3-amd64: Diskless workstation regularly stalls with 4.15 kernel

[BERTRAND Joël]

A precision I have forgotten. I have filled a bug against kernel as
nfs's packages haven't been upgraded when this bug was triggered.

Only one workaround : use nolock mount option.

Best regards,

JKB

Bug#897123: linux-image-4.15.0-3-amd64: Diskless workstation regularly stalls with 4.15 kernel

[BERTRAND Joël]

Package: src:linux
Version: 4.15.17-1
Severity: important

Dear Maintainer,

I use some diskless workstations for a long time without any specific trouble.
Since I have installed 4.15 kernel from debian testing, my main workstation
regularly stalls. In syslog, I have a lot of :

Apr 28 18:51:53 hilbert kernel: [287335.545559] xs_tcp_setup_socket: connect 
returned unhandled error -107
Apr 28 18:51:55 hilbert kernel: [287337.057907] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:52:07 hilbert kernel: [287349.418038] lockd: server 192.168.10.128 OK
Apr 28 18:52:16 hilbert kernel: [287358.042284] lockd: server 192.168.10.128 OK
Apr 28 18:52:35 hilbert kernel: [287377.715081] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:53:10 hilbert kernel: [287412.071680] lockd: server 192.168.10.128 OK
Apr 28 18:53:10 hilbert kernel: [287412.072447] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:53:10 hilbert kernel: [287412.323525] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:53:33 hilbert kernel: [287435.567724] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:53:37 hilbert kernel: [287439.864192] lockd: server 192.168.10.128 
not responding, still trying
Apr 28 18:54:03 hilbert kernel: [287465.336821] lockd: server 192.168.10.128 OK
Apr 28 18:54:09 hilbert kernel: [287471.648970] lockd: server 192.168.10.128 OK

nfsstats returns :
hilbert:[~] > nfsstat -m
/ from 192.168.10.128:/srv/hilbert
 Flags: 
rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.10.128

/home from 192.168.10.128:/home
 Flags: 
rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.10.128,mountvers=3,mountport=1020,mountproto=tcp,local_lock=none,addr=192.168.10.128

Of course, server's configuration has not changed. This server runs NetBSD 8 and
I haven't seen any NFS malfunction with kernel 4.14. Of course, all other
clients running Linux (arm kernel 4.9, x86 kernel 4.14 or FreeBSD 11.1) run as
expected without any trouble.

Best regards,

JKB

-- Package-specific info:
** Version:
Linux version 4.15.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-16)) #1 SMP Debian 4.15.17-1 (2018-04-19)

** Command line:
BOOT_IMAGE=pxelinux.cfg/vmlinuz-4.15.0-3-amd64-hilbert root=/dev/nfs 
initrd=pxelinux.cfg/initrd.img-4.15.0-3-amd64-hilbert 
nfsroot=192.168.10.128:/srv/hilbert ip=dhcp rw

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[285673.025753] xs_tcp_setup_socket: connect returned unhandled error -107
[285857.121396] lockd: server 192.168.10.128 not responding, still trying
[285857.373345] lockd: server 192.168.10.128 not responding, still trying
[285858.641114] lockd: server 192.168.10.128 not responding, still trying
[285866.965630] lockd: server 192.168.10.128 not responding, still trying
[285868.225678] lockd: server 192.168.10.128 not responding, still trying
[285938.011610] lockd: server 192.168.10.128 OK
[285939.019589] lockd: server 192.168.10.128 OK
[285947.627997] lockd: server 192.168.10.128 OK
[285949.139779] lockd: server 192.168.10.128 OK
[285956.528084] lockd: server 192.168.10.128 OK
[286860.226436] xs_tcp_setup_socket: connect returned unhandled error -107
[286958.020204] lockd: server 192.168.10.128 not responding, still trying
[286961.808706] lockd: server 192.168.10.128 not responding, still trying
[286971.148954] lockd: server 192.168.10.128 OK
[286994.873491] lockd: server 192.168.10.128 not responding, still trying
[287048.118707] lockd: server 192.168.10.128 not responding, still trying
[287082.463590] lockd: server 192.168.10.128 not responding, still trying
[287116.776538] lockd: server 192.168.10.128 OK
[287117.784429] lockd: server 192.168.10.128 OK
[287118.820500] lockd: server 192.168.10.128 OK
[287126.152638] lockd: server 192.168.10.128 OK
[287250.911579] lockd: server 192.168.10.128 not responding, still trying
[287251.919620] lockd: server 192.168.10.128 not responding, still trying
[287264.540008] lockd: server 192.168.10.128 OK
[287264.540141] xs_tcp_setup_socket: connect returned unhandled error -107
[287275.144907] lockd: server 192.168.10.128 OK
[287335.545548] lockd: server 192.168.10.128 not responding, still trying
[287335.545559] xs_tcp_setup_socket: connect returned unhandled error -107
[287337.057907] lockd: server 192.168.10.128 not responding, still trying
[287349.418038] lockd: server 192.168.10.128 OK
[287358.042284] lockd: server 192.168.10.128 OK
[287377.715081] lockd: server 192.168.10.128 not responding, still trying
[287408.271051] lockd: server 192.168.10.128 not responding, still trying
[287412.071680] lockd: server 192.168.10.128 OK
[287412.072447] lockd: server 192.168.10.128 not responding, still trying
[287412.323525] lockd: server 192.168.10.128 not responding, still trying

Bug#895868: munin-cron: Fontconfig error: failed reading config file

[BERTRAND Joël]

Same bug here. I've only found a quick an dirty workaround:

*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then
/usr/bin/munin-cron; fi > /dev/null 2>&1

Regards,

JKB

Bug#873065: postfix: Some mails refused since libssl1.1_1.1.0f-4_amd64.deb

[BERTRAND Joël]

Hello,

Same constatation with sendmail and libssl1.1_1.1.0f-5.

	Looking at tls1_2_default.patch from Debian's openssl, the only thing 
that needs to be done is to override this change:


@@ -2372,7 +2372,10 @@ SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth)
 goto err;

 ret->method = meth;
-ret->min_proto_version = 0;
+if (meth->version == TLS_ANY_VERSION)
+ret->min_proto_version = TLS1_2_VERSION;
+else
+ret->min_proto_version = 0;
 ret->max_proto_version = 0;
 ret->session_cache_mode = SSL_SESS_CACHE_SERVER;
 ret->session_cache_size = SSL_SESSION_CACHE_MAX_SIZE_DEFAULT;

	I consider this bug should be grave or critical as for a mail server 
(for example), ingoing mails can be refused without any bounce.


Best regards,

JKB

Bug#847498: sendmail: Cron sends mail every 20 minutes

[BERTRAND Joël]

Salvatore Bonaccorso a écrit :

Hi

On Thu, Dec 08, 2016 at 08:33:24PM +0100, BERTRAND Joël wrote:

Package: sendmail
Version: 8.15.2-7
Severity: normal

Dear Maintainer,

I have upgraded sendmail/testing and now every 20 minutes, cron sends mail with
following object :

Cron <smmsp@rayleigh> test -x /etc/init.d/sendmail && test -x
/usr/share/sendmail/sendmail && test -x /usr/lib/sm.bin/sendmail &&
/usr/share/sendmail/sendmail cron-msp

su : doit être lancé à partir d'un terminal

In english : "su : must be launch from a terminal".

I suppose /etc/cron.d/sendmail is faulty, but I haven't seen any error.


If I'm not completely wrong, I think this regression should be fixed
in the 8.15.2-8 upload (done today). Can you try to update to that
version to confirm?


Hi,

I have tried 8.15.2-8 and this regression seems to be fixed.

Thanks,

JKB

Bug#847498: sendmail: Cron sends mail every 20 minutes

[BERTRAND Joël]

Package: sendmail
Version: 8.15.2-7
Severity: normal

Dear Maintainer,

I have upgraded sendmail/testing and now every 20 minutes, cron sends mail with 
following object :

Cron  test -x /etc/init.d/sendmail && test -x
/usr/share/sendmail/sendmail && test -x /usr/lib/sm.bin/sendmail &&
/usr/share/sendmail/sendmail cron-msp

su : doit être lancé à partir d'un terminal

In english : "su : must be launch from a terminal".

I suppose /etc/cron.d/sendmail is faulty, but I haven't seen any error.

Best regards,

JB

ls -alR /etc/mail:
/etc/mail:
total 448
drwxr-sr-x   7 smmta smmsp4096 Dec  8 19:45 .
drwxr-xr-x 267 root  root20480 Dec  8 19:50 ..
-rwxr-xr--   1 root  smmsp   12382 Dec  8 19:45 Makefile
-rw---   1 root  smmsp  69 Dec  8 19:45 access
-rw-r-   1 smmta smmsp   12288 Dec  8 19:45 access.db
-rw-r--r--   1 root  root  156 May  9  2006 address.resolve
-rw-r--r--   1 root  root  281 Nov  3  2010 address.resolve.dpkg-dist
lrwxrwxrwx   1 root  mlocate10 Jan 12  2012 aliases -> ../aliases
-rw-r-   1 smmta smmsp   12288 Dec  8 19:46 aliases.db
-rw-r--r--   1 root  smmsp4031 May  8  2010 aliases.orig
-rw-r--r--   1 root  root 3727 Dec  8 19:45 databases
-rw-r-   1 smmta smmsp  52 Nov 26  2004 default-auth-info
-rw-r--r--   1 root  smmsp9327 Nov  2 19:36 greylist.conf
-rw-r--r--   1 root  smmsp8366 May  9  2006 greylist.conf.orig
-rw-r--r--   1 root  root 5659 Mar  2  2016 helpfile
-rw-r--r--   1 root  smmsp  44 Nov 22  2013 local-host-names
drwxr-sr-x   2 smmta smmsp4096 Oct 13 10:52 m4
-rw-r--r--   1 root  smmsp   0 Dec 11  2007 mailertable
-rw-r-   1 root  smmsp   12288 Dec  8 19:45 mailertable.db
-rw-r--r--   1 root  smmsp2475 Jun  1  2013 milter-greylist.m4
drwxr-xr-x   2 root  root 4096 Dec  8 19:45 peers
-rw-r--r--   1 root  smmsp  34 Jul 15  2014 relay-domains
drwxr-xr-x   2 smmta smmsp4096 Apr 21  2016 sasl
-rw-r--r--   1 root  smmsp   66379 Dec  8 19:45 sendmail.cf
-rw-r--r--   1 root  root66380 Dec  8 19:45 sendmail.cf.old
-rw-r--r--   1 root  root1 Dec  8 19:45 sendmail.conf
-rw-r--r--   1 root  smmsp3599 Dec  8 19:45 sendmail.mc
-rw-r--r--   1 root  smmsp4775 May  9  2006 sendmail.mc.old
-rw-r--r--   1 root  root  149 Jan 15  2001 service.switch
-rw-r--r--   1 root  root  180 Jan 15  2001 service.switch-nodns
drwxr-sr-x   2 smmta smmsp4096 Dec 17  2006 smrsh
lrwxrwxrwx   1 root  root   15 Jan 12  2012 spamassassin -> ../spamassassin
-rw-r--r--   1 root  smmsp   44527 Dec  8 19:45 submit.cf
-rw-r--r--   1 root  root44528 Dec  8 19:45 submit.cf.old
-rw-r--r--   1 root  smmsp2288 Dec  8 19:45 submit.mc
drwxr-xr-x   2 smmta smmsp4096 Feb 15  2015 tls
-rw-r--r--   1 root  root0 May  9  2006 trusted-users
-rw-r--r--   1 root  smmsp  68 Jul 30  2014 virtuserdomains
-rw-r--r--   1 root  smmsp 207 Jul 30  2014 virtusertable
-rw-r-   1 root  smmsp   12288 Dec  8 19:45 virtusertable.db

/etc/mail/m4:
total 16
drwxr-sr-x 2 smmta smmsp 4096 Oct 13 10:52 .
drwxr-sr-x 7 smmta smmsp 4096 Dec  8 19:45 ..
-rw-r--r-- 1 root  root   789 Sep  5  2008 clamav-milter.m4
-rw-r- 1 root  smmsp  800 Apr 26  2008 dialup.m4
-rw-r- 1 root  smmsp0 Dec 13  2003 provider.m4

/etc/mail/peers:
total 12
drwxr-xr-x 2 root  root  4096 Dec  8 19:45 .
drwxr-sr-x 7 smmta smmsp 4096 Dec  8 19:45 ..
-rw-r--r-- 1 root  root   328 Dec  9  2006 provider

/etc/mail/sasl:
total 16
drwxr-xr-x 2 smmta smmsp 4096 Apr 21  2016 .
drwxr-sr-x 7 smmta smmsp 4096 Dec  8 19:45 ..
-rw-r- 1 smmta smmsp  694 Mar 18  2010 Sendmail.conf.2
-rwxr--r-- 1 root  root  3653 Dec  8 19:45 sasl.m4

/etc/mail/smrsh:
total 8
drwxr-sr-x 2 smmta smmsp 4096 Dec 17  2006 .
drwxr-sr-x 7 smmta smmsp 4096 Dec  8 19:45 ..
lrwxrwxrwx 1 root  root26 Jan 12  2012 mail.local -> 
/usr/lib/sm.bin/mail.local
lrwxrwxrwx 1 root  root29 Jan 12  2012 mailman -> 
/var/lib/mailman/mail/mailman
lrwxrwxrwx 1 root  root17 Jan 12  2012 procmail -> /usr/bin/procmail
lrwxrwxrwx 1 root  root17 Jan 12  2012 vacation -> /usr/bin/vacation

/etc/mail/tls:
total 48
drwxr-xr-x 2 smmta smmsp 4096 Feb 15  2015 .
drwxr-sr-x 7 smmta smmsp 4096 Dec  8 19:45 ..
-rw-r--r-- 1 root  root 7 Dec 13  2003 no_prompt
-rw--- 1 root  root  1191 Apr 26  2008 sendmail-client.cfg
-rw-r--r-- 1 root  smmsp 1253 Mar 21  2009 sendmail-client.crt
-rw--- 1 root  root  1025 Mar 21  2009 sendmail-client.csr
-rw-r- 1 root  smmsp 1675 Mar 21  2009 sendmail-common.key
-rw-r- 1 root  smmsp 1582 Mar 21  2009 sendmail-common.prm
-rw--- 1 root  root  1191 Apr 26  2008 sendmail-server.cfg
-rw-r--r-- 1 root  smmsp 1253 Mar 21  2009 sendmail-server.crt
-rw--- 1 root  root  1025 Mar 21  2009 sendmail-server.csr
-rwxr--r-- 1 root  root  3268 Dec  8 19:45 starttls.m4

sendmail.conf:
DAEMON_NETMODE="Static";
DAEMON_NETIF="eth1";
DAEMON_MODE="Daemon";
DAEMON_PARMS="";
DAEMON_HOSTSTATS="Yes";

Bug#807258: Fixed

[BERTRAND Joël]

I have downgraded sendmail to 8.14.4 (built from debian/stable sources) 
and sendmail runs as expected. Please remove faulty package or apply 
last sendmail patches that fix this known issue.


Best regards,

JKB

Bug#807258: Fixed

[BERTRAND Joël]

Marcus Schopen a écrit :

Hi,

Am Mittwoch, den 09.12.2015, 12:57 +0100 schrieb BERTRAND Joël:

I have downgraded sendmail to 8.14.4 (built from debian/stable sources)
and sendmail runs as expected. Please remove faulty package or apply
last sendmail patches that fix this known issue.


Have you posted it on the milter-greylist mailinglist too? I think
Emmanuel Dreyfus would be interested.

Cheers
Marcus


Yes, I have.

Regards,

JKB

Bug#807258: Logged transaction

[BERTRAND Joël]

250-rayleigh.systella.fr Hello mta.partenaire.viadeo.com 
[136.147.180.10], pleased to meet you

250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH NTLM PLAIN LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

10:25:15.695375 IP mta.partenaire.viadeo.com.39783 > 
rayleigh.systella.fr.smtp: Flags [P.], seq 33:181, ack 471, win 131, 
options [nop,nop,TS val 704029822 ecr 312631110], length 148: SMTP: MAIL 
FROM: 
BODY=8BITMIME

EP@.-..
.g...>.._4.RM..
)..~.._FMAIL 
FROM: 
BODY=8BITMIME

RCPT TO:
DATA

10:25:15.733941 IP rayleigh.systella.fr.smtp > 
mta.partenaire.viadeo.com.39783: Flags [.], ack 181, win 234, options 
[nop,nop,TS val 312631148 ecr 704029822], length 0

E..4.l@.@.e
...g_4.R.>.G.z.
.._l)..~
10:25:16.471353 IP rayleigh.systella.fr.smtp > 
mta.partenaire.viadeo.com.39783: Flags [P.], seq 471:706, ack 181, win 
234, options [nop,nop,TS val 312631332 ecr 704029822], length 235: SMTP: 
250 2.1.0 
... 
Sender ok

Em@.@.d#...
...g_4.R.>.G...
..`$)..~250 2.1.0 
... 
Sender ok
550 ... 451 4.7.1 Greylisting in 
action, please come back in 00:10:00

503 5.0.0 Need RCPT (recipient)

I don't understand following line :
550 ... 451 4.7.1 Greylisting in 
action, please come back in 00:10:00


Why 550 and 451 on the _same_ line ?

Best regards,

JKB

Bug#807258: For information

[BERTRAND Joël]

JKB  wrote:

>   I have a sendmail server (8.15.2) running debian linux, 
spamassasin,

>   clamav and milter-greylist (4.4.3 and I have tried 4.5.16). This
>   configuration ran like a charm until last sendmail upgrade.

So what are the changes in that "last sendmail upgrade"?
Is that an official sendmail version or something patched by the "vendor"?

If it is based on a 8.16.0 snapshot then maybe a version before .6
was used? There was a problem in one of those:

  sendmail snapshot 8.16.0.6 is available for testing. It fixes a
  regression in 8.16 which could generate bogus SMTP replies in some
  cases (and even with a 5xy error instead of 4xy).

Bug#807258: sendmail: Strange DSN code returned by sendmail with greylisting

[BERTRAND Joël]

Source: sendmail
Version: 8.15.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I use for a long time a sendmail configuration with debian clamav and
spamassassin milters and a customized milter greylist (same sources that
debian's milter but with some different compilation options).

I have checked in greylist-milter sources and milter returns 451 4.7.1 DSN by
default. My configuration ran like a charm for a very long time.

I have recently upgraded my mail server and I have seen that last sendmail seems
to change DSN code. For example, I have tried to send a message from an external
SMTP server. It receives :

550 ... 451 4.7.1 Greylisting in action, please come 
back later

I don't understand why milter-greylist returns 451 and why sendmail changes this
error to 550 since last sendmail upgrade.

I have checked sendmail.cf file and I haven't found what could change this DSN
code.

I don't know how investigate.

Regards,

JKB

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

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

Bug#747478: mutt: TLS authentification returns tls_socket_read (An unexpected TLS packet was received.)

[BERTRAND Joël]

Package: mutt
Version: 1.5.23-1
Severity: normal

Dear Maintainer,

I use mutt for a long time without any trouble on an IMAP server running
courier-imap-ssl (and of course courier-authdaemon and courier-authlib).

This IMAP server runs fine and I can use seamonkey-mail, squirrelmail,
roundcube and some other MUA without any difficulties. Since a recent mutt
upgrade, I cannot use mutt as during authentification phase, it return :

tls_socket_read (An unexpected TLS packet was received.)

and authentification aborts. I don't have specific configuration and my IMAP
server configuration hasn't been modified.

-- Package-specific info:
Mutt 1.5.23 (2014-03-12)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 3.13-1-amd64 (x86_64)
ncurses: ncurses 5.9.20140118 (compiled with 5.9)
libidn: 1.28 (compiled with 1.28)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16' 
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.8 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-a!
 bi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-16) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 
'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL=/usr/sbin/sendmail
MAILPATH=/var/mail
PKGDATADIR=/usr/share/mutt
SYSCONFDIR=/etc
EXECSHELL=/bin/sh
MIXMASTER=mixmaster
To contact the developers, please mail to mutt-...@mutt.org.
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/xtitles.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features-old/patch-1.5.4.vk.pgp_verbose_mime.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-specific/document_debian_defaults.patch
debian-specific/assumed_charset-compat.patch
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.patch
misc/gpg.rc-paths.patch
misc/smime.rc.patch

Bug#724609: Same constatation, but...

[BERTRAND Joël]

Hello,

	I have seen the same bug, but I'm not sure that it is related to kernel 
upgrade. Indeed, if I reboots my Lenovo Edge E325 with 3.10-2 kernel, 
wmbattery only indicates 0.


Regards,

JB


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

Bug#641146: openttd: Swapped colors on sparc64

[BERTRAND Joël]

Matthijs Kooijman a écrit :

Hi Joël,

a while ago you reported a color problem with OpenTTD on your sparc64.
Some palette-related fixes that made things work on my sparc64 with 8bit
video were included in the 1.3.0 OpenTTD release, which was recently
uploaded to experimental.

Could you test the OpenTTD version in experimental and report if it
fixes the problems you were seeing?


	I will try as soon as possible. I have halted my sparc due to some 
kernel instabilities (3.2 is not stable on all sun4u I have).


Regards,

JKB


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

Bug#695130: Openmotif

[BERTRAND Joël]

Hello,

	I've seen that openmotif was orphaned. I can try to package new 
openmotif library (released in LGPL) as a cdesktopenenv prerequisite.


Regards,

JB


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

Bug#695802: uswsusp: s2disk doesn't work on Lenovo Thinkpad Edge E325

[BERTRAND Joël]

Rodolfo García Peñas (kix) wrote:

On 2012-12-12 21:02, JKB wrote:

Package: uswsusp
Version: 1.0+20110509-3
Severity: important

Dear Maintainer,

I use s2ram/s2disk for a long time without trouble. I have installed
debian/testing on a new laptop (Lenovo Thinkpad Edge E325).
If s2ram runs fine, s2disk doesn't. When I launch s2disk, s2disk
starts but system hangs without message in syslog.
Point of the 'i' of Thinkpad is flashing and I have to disconnect
power to reboot.

I have tried some different configuration (/etc/uswsusp.conf) without
any success.

Best regards,

JKB


Hi,

I had some troubles with some new kernel versions. Did you update the
kernel image too? Could you try the previous version of uswsusp with
your current kernel?


	Today, I use 3.2.0-4 debian kernel. Which version of uswsusp should be 
used with this kernel ?


Regards,

JKB


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

Bug#695802: uswsusp: s2disk doesn't work on Lenovo Thinkpad Edge E325

[BERTRAND Joël]

Rodolfo García Peñas (kix) wrote:

On 2012-12-13 12:27, BERTRAND Joël wrote:

Rodolfo García Peñas (kix) wrote:

On 2012-12-12 21:02, JKB wrote:

Package: uswsusp
Version: 1.0+20110509-3
Severity: important

Dear Maintainer,

I use s2ram/s2disk for a long time without trouble. I have installed
debian/testing on a new laptop (Lenovo Thinkpad Edge E325).
If s2ram runs fine, s2disk doesn't. When I launch s2disk, s2disk
starts but system hangs without message in syslog.
Point of the 'i' of Thinkpad is flashing and I have to disconnect
power to reboot.

I have tried some different configuration (/etc/uswsusp.conf) without
any success.

Best regards,

JKB


Hi,

I had some troubles with some new kernel versions. Did you update the
kernel image too? Could you try the previous version of uswsusp with
your current kernel?


Today, I use 3.2.0-4 debian kernel. Which version of uswsusp should
be used with this kernel ?

Regards,

JKB


Hi,

sorry, I didn't explain right. uswsusp should be used with ANY kernel
version, but, I had some problems with some kernel versions. Perhaps
some new kernels have some issues with the suspend process.

For this reason, if you can check different kernel versions with
different uswsusp versions, we can test if the problem is in the uswsusp
package or in the linux-image package.


	Just a remark. The same kernel with the same uswsusp run fine on my 
Toshiba P200.


Regards,

JKB


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

Bug#653766: Patch

[BERTRAND Joël]

Please add 'su root list' to each logrotate sections in 
/etc/logrotate.d/mailman :


/var/log/mailman/vette /var/log/mailman/error /var/log/mailman/bounce {
su root list
weekly
missingok
create 0664 list list
rotate 4
compress
delaycompress
sharedscripts
postrotate
[ -f '/var/run/mailman/mailman.pid' ]  
/usr/lib/mailman/bin/mailmanctl -q reopen || exit 0

endscript
}

/var/log/mailman/mischief {
su root list
monthly
missingok
create 0664 list www-data
rotate 4
compress
delaycompress
sharedscripts
postrotate
[ -f '/var/run/mailman/mailman.pid' ]  
/usr/lib/mailman/bin/mailmanctl -q reopen || exit 0

endscript
}

/var/log/mailman/digest {
su root list
monthly
missingok
create 0664 list list
rotate 4
compress
delaycompress
sharedscripts
postrotate
[ -f '/var/run/mailman/mailman.pid' ]  
/usr/lib/mailman/bin/mailmanctl -q reopen || exit 0

endscript
}


/var/log/mailman/subscribe /var/log/mailman/post {
su root list
monthly
missingok
create 0664 list list
rotate 12
compress
delaycompress
sharedscripts
postrotate
[ -f '/var/run/mailman/mailman.pid' ]  
/usr/lib/mailman/bin/mailmanctl -q reopen || exit 0

endscript
}

/var/log/mailman/qrunner /var/log/mailman/fromusenet 
/var/log/mailman/locks /var/log/mailman/smtp /var/log/mailman/smtp-failure {

su root list
daily
missingok
create 0664 list list
rotate 7
compress
delaycompress
sharedscripts
postrotate
[ -f '/var/run/mailman/mailman.pid' ]  
/usr/lib/mailman/bin/mailmanctl -q reopen || exit 0

endscript
}

Regards,

JKB



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

Bug#641146: openttd: Swapped colors on sparc64

[BERTRAND Joël]

Package: openttd
Version: 1.1.2-1
Severity: normal

Dear Maintainer,

On sparc64, openttd colors are swapped (green is green, but red seems to be
replaced by blue and blue by red). I think there is an endianess trouble in
openttd.

Regards,

JB

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

Kernel: Linux 2.6.36.2 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openttd depends on:
ii  libc62.13-18  
ii  libfontconfig1   2.8.0-3  
ii  libfreetype6 2.4.6-2  
ii  libgcc1  1:4.6.1-4
ii  libicu44 4.4.2-2  
ii  liblzma2 5.1.1alpha+20110809-2
ii  liblzo2-22.05-2   
ii  libpng12-0   1.2.46-3 
ii  libsdl1.2debian  1.2.14-6.4   
ii  libstdc++6   4.6.1-4  
ii  openttd-data 1.1.2-1  
ii  zlib1g   1:1.2.3.4.dfsg-3 

Versions of packages openttd recommends:
ii  openttd-opengfx  0.3.5-1 
ii  openttd-openmsx  0.3.1-1 
ii  timidity 2.13.2-39+b1
ii  x11-utils7.6+3   

Versions of packages openttd suggests:
pn  openttd-opensfx  none

-- 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#623127: Using gv closes X session

[BERTRAND Joël]

Cyril Brulebois a écrit :

Hi,

BERTRAND Joëlm...@systella.fr  (18/04/2011):

Section Files
 FontPathunix/:7100


please try getting rid of that.


If I remove xfs from xorg.conf, X doesn't crash anymore.

Regards,

JKB



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

Bug#623127: Using gv closes X session

[BERTRAND Joël]

Bernhard R. Link a écrit :

* BERTRAND Benedictem...@systella.fr  [110417 17:33]:

When I try to launch gv, X session (xfce, gnome, windowmaker) aborts.
This bug occurs even if gv is launched without any argument from command line.
I'm unable to obtain more information in log files.


I think it is very unlikely that this can happen without at least a
bug in other components. I guess most likely is the Xserver crashing.

Is there anything at the end of /var/log/Xorg.0.log (or rather
/var/log/Xorg.0.log.old once a new X xserver is started?)

Does ~/.xsession-errors show messages related to this?


In .xsessions-errors, I have :

/usr/bin/wmaker(catchXError(startup.c:177)): warning: internal X error: 
RenderBadPicture (invalid Picture parameter)

Request code: 149
Request minor code: 7
Resource ID: 0x8000b6
Error serial: 69290

/usr/bin/wmaker(catchXError(startup.c:177)): warning: internal X error: 
RenderBadPicture (invalid Picture parameter)

Request code: 149
Request minor code: 7
Resource ID: 0x8000b6
Error serial: 274468

/usr/bin/wmaker(catchXError(startup.c:177)): warning: internal X error: 
RenderBadPicture (invalid Picture parameter)

Request code: 149
Request minor code: 7
Resource ID: 0x8000b6
Error serial: 274819

but I'm not sure that my problem is related to these messages as I have 
tested with other windowmanagers.


In Xorg.log.0.old, I found :

Backtrace:
[3432424.172] 0: /usr/bin/X (0x1+0x66088) [0x76088]
[3432424.172] 1: /lib/libpthread.so.0 (0xf7e24000+0x11158) [0xf7e35158]
[3432424.172] 2: /usr/bin/X (ProcessWorkQueue+0x34) [0x5a614]
[3432424.172] 3: /usr/bin/X (WaitForSomething+0xc0) [0x78be0]
[3432424.172] 4: /usr/bin/X (0x1+0x272a4) [0x372a4]
[3432424.172] 5: /usr/bin/X (0x1+0x1f6ec) [0x2f6ec]
[3432424.173] 6: /lib/libc.so.6 (__libc_start_main+0x10c) [0xf7ab064c]
[3432424.173] 7: /usr/bin/X (_start+0x2c) [0x2f10c]
[3432424.173] Segmentation fault at address (nil)
[3432424.173]
Fatal server error:
[3432424.173] Caught signal 11 (Segmentation fault). Server aborting
[3432424.173]
[3432424.173]
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.

My xorg.conf contains:

Section Files
FontPathunix/:7100
FontPath/usr/share/fonts/X11/misc
FontPath/usr/X11R6/lib/X11/fonts/misc
FontPath/usr/share/fonts/X11/cyrillic
FontPath/usr/X11R6/lib/X11/fonts/cyrillic
FontPath/usr/share/fonts/X11/100dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/share/fonts/X11/75dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/share/fonts/X11/Type1
FontPath/usr/X11R6/lib/X11/fonts/Type1
FontPath/usr/share/fonts/X11/100dpi
FontPath/usr/X11R6/lib/X11/fonts/100dpi
FontPath/usr/share/fonts/X11/75dpi
FontPath/usr/X11R6/lib/X11/fonts/75dpi
# path to defoma fonts
FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection
Section Module
Loadi2c
Loadbitmap
Loadddc
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadvbe
Loadcfb
Loadcfb32
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  CoreKeyboard
Option  XkbRules  xorg
Option  XkbModel  pc105
Option  XkbLayout fr
Option  XkbVariantlatin9
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  Emulate3Buttons   true
EndSection

Section Device
Identifier  Sun XVR 500
Driver  glint
Option  UseFBDev  true
EndSection

Section Device
Identifier  Creator 3D
Driver  sunffb
Option  UseFBDev  false
EndSection

Section Monitor
Identifier  �~Icran générique
Option  DPMS
HorizSync   28-64
VertRefresh 43-60
EndSection

Section Screen
Identifier  Default Screen
Device  Creator 3D
Monitor �~Icran générique
DefaultDepth24
SubSection Display
Depth   1
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   4
Modes   1280x1024 800x600
EndSubSection

Bug#623127: Using gv closes X session

[BERTRAND Joël]

Bernhard R. Link a écrit :

reportbug -b -s followup -S normal -p xorg  log



Subject: followup

Package: xorg
Version: 1:7.6+6
Severity: normal



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Apr  3  2009 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1869576 Mar 26 18:42 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--

Xorg X server configuration file status:

-rw-r--r-- 1 root root 3189 Jul 24  2009 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type man /etc/X11/xorg.conf at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section Files
FontPathunix/:7100
FontPath/usr/share/fonts/X11/misc
FontPath/usr/X11R6/lib/X11/fonts/misc
FontPath/usr/share/fonts/X11/cyrillic
FontPath/usr/X11R6/lib/X11/fonts/cyrillic
FontPath/usr/share/fonts/X11/100dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/share/fonts/X11/75dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/share/fonts/X11/Type1
FontPath/usr/X11R6/lib/X11/fonts/Type1
FontPath/usr/share/fonts/X11/100dpi
FontPath/usr/X11R6/lib/X11/fonts/100dpi
FontPath/usr/share/fonts/X11/75dpi
FontPath/usr/X11R6/lib/X11/fonts/75dpi
# path to defoma fonts
FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection

Section Module
Loadi2c
Loadbitmap
Loadddc
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadvbe
Loadcfb
Loadcfb32
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  CoreKeyboard
Option  XkbRules  xorg
Option  XkbModel  pc105
Option  XkbLayout fr
Option  XkbVariantlatin9
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  Emulate3Buttons   true
EndSection

Section Device
Identifier  Sun XVR 500
Driver  glint
Option  UseFBDev  true
EndSection

Section Device
Identifier  Creator 3D
Driver  sunffb
Option  UseFBDev  false
EndSection

Section Monitor
Identifier  cran gnrique
Option  DPMS
HorizSync   28-64
VertRefresh 43-60
EndSection

Section Screen
Identifier  Default Screen
Device  Creator 3D
Monitor cran gnrique
DefaultDepth24
SubSection Display
Depth   1
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   4
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   8
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   15
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   16
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   24
Modes   1280x1024 800x600
EndSubSection
SubSection Display
Depth   32
Modes   1280x1024 800x600
EndSubSection
EndSection

Section ServerLayout
Identifier  Default Layout
Screen  Default Screen
InputDevice Generic Keyboard
InputDevice Configured Mouse
EndSection

Section DRI
Mode0666
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 2.6.36.2 (root@rayleigh) (gcc version 4.4.5 (Debian 
4.4.5-8) ) #1 SMP Sun Jan 2 11:50:13 CET 2011


Xorg X server log files on system:
--
-rw-r--r-- 1 root root 14672 Apr 18 14:55 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[3432426.261]
X.Org X Server 1.9.5
Release Date: 2011-03-17
[3432426.261] X Protocol Version 11, Revision 0
[3432426.261] Build Operating System: Linux 2.6.32-bpo.5-sparc64-smp 
sparc Debian
[3432426.261] 

Bug#595977: [jim...@gmail.com: Re: [...@systella.fr: Bug#595977: /usr/bin/ooffice: *** glibc detected *** /usr/lib/openoffice/program/soffice.bin: double free or corruption]]

[BERTRAND Joël]

Rene Engelhard a écrit :

On Fri, Sep 10, 2010 at 01:50:22PM +0200, Rene Engelhard wrote:

ok, we have no upstream sparc porter anymore ;-(
But can you try the workaround described in the Ubuntu *shudders* forum 
*shudders*?


ping? Can you try it?

I could add that hackaround. I am not sure I'll get it past the
release team, which needs to review *every* change in the freeze we're at,
but it's better than random crahses...

(I don't have sparc available to test)


I have tried. It seems to be a good workaround. I don't see error 
anymore.

Regards,

BB



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

Bug#595977: /usr/bin/ooffice: *** glibc detected *** /usr/lib/openoffice/program/soffice.bin: double free or corruption

[BERTRAND Joël]

Rene Engelhard a écrit :

reassign 595977 openoffice.org
thanks

On Tue, Sep 07, 2010 at 08:50:03PM +0200, BERTRAND Benedicte wrote:

Package: openoffice.org-common
Version: 1:3.2.1-6
Severity: important
File: /usr/bin/ooffice


and umm, no, someone using a non-mainstream arch on a development system
should KNOW that -common CANNOT be at fault as it's binary-indep stuff and 
ooffice just a script.


Sure...


Even openoffice.org would be better at core; though directly filing this
where soffice.bin is (-core) would be even better (though soffice.bin
100% doesn't crash itself when you use OOo for whatever and that crashes;
your description is far too blurry to know *when* it crashes)


I know, but OOo _randomly_ crashes. Today, it crashes :
- when I try to print from oocalc or try to obtain a preview 
(reproductible);

- when I try to open a .doc file;
- when I fill a oocalc folder.

	I haven't find relation between these crashes, only double free 
corruption.


Regards,

JKB



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

Bug#595977: /usr/bin/ooffice: *** glibc detected *** /usr/lib/openoffice/program/soffice.bin: double free or corruption

[BERTRAND Joël]

Rene Engelhard a écrit :

Hi,

On Tue, Sep 07, 2010 at 08:50:03PM +0200, BERTRAND Benedicte wrote:

I'm trying tu use Openoffice on a Blade 2000 (sparc64/smp).
I have upgraded my squeeze (dist-upgrade) the last sunday. Since upgrade,



From what? 1:3.2.1-5 (In that case I don't see a change inside OOo itself

which can explain the difference)? And what else did get upgraded beside Ooo?


OOo 3.1, but I don't remember exact version.

JKB



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

Bug#591512: Bus error (sparc64) when iceape/iceweasel tries to open http://www.persee.fr/web/guest/home

[BERTRAND Joël]

Mike Hommey a écrit :

On Wed, Aug 04, 2010 at 10:09:12PM +0200, BERTRAND Joël wrote:

Mike Hommey a écrit :

On Tue, Aug 03, 2010 at 07:28:04PM +0200, BERTRAND Benedictem...@systella.fr  
 wrote:

Package: iceweasel
Version: 3.5.10-1
Severity: important


Hello,

I use iceape/iceweasel on a sparc64 workstation and I'm unable to
use iceape or iceweasel to navigate on http://www.persee.fr/web/guest/home.
If I try to click on 'scientific journals' (red button), both iceape and
iceweasel crash with a bus error. Of course, all test have been done without
any plugins.

I have tried to debug with iceape-dbg without any success.


Did you try the instructions from /usr/share/bug/iceweasel/presubj ?


Nope, I have tried with iceape-dbg.


Could you try going in about:config, filter on jit and disable both
prefs that will show up and try again see if it gets better?


	Jit is disabled because I have to disable it to successfully build 
seamonkey.


about:buildconfig returns :
--enable-application=suite 
--prefix=/export/home/bertrand/seamonkey/install 
--with-default-mozilla-five-home=/export/home/bertrand/seamonkey/install 
--enable-default-toolkit=cairo-gtk2 --enable-pango --enable-system-cairo 
--with-system-jpeg --with-system-zlib --with-system-nspr 
--with-system-nss --enable-svg --enable-mathml --disable-pedantic 
--disable-long-long-warning --enable-gnomevfs --enable-gnomeui 
--disable-tests --disable-mochitest --disable-debug --enable-canvas 
--enable-extensions=default,-venkman,-inspector --disable-installer 
--disable-updater --disable-javaxpcom --disable-elf-dynstr-gc 
--enable-system-hunspell --disable-crashreporter --enable-system-sqlite 
--disable-strip --disable-install-strip --enable-startup-notification 
--enable-crypto --host=sparc-linux-gnu --enable-application=suite 
--disable-debug --enable-optimize --disable-jit 
--enable-application=../suite --disable-official-branding 
--with-branding=../suite/branding/nightly --disable-debug 
--enable-optimize --cache-file=.././config.cache 
--srcdir=../../comm-1.9.1/mozilla


	Nevertheless, there are three jit references in config page. I've 
disabled these options without any result. Seamonkey always crashes.


Regards,

JKB



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

Bug#591512: Bus error (sparc64) when iceape/iceweasel tries to open http://www.persee.fr/web/guest/home

[BERTRAND Joël]

Mike Hommey a écrit :

On Fri, Aug 06, 2010 at 10:09:38AM +0200, BERTRAND Joël wrote:

Jit is disabled because I have to disable it to successfully build
seamonkey.


It would be interesting to file an upstream bug with the build error
message (and giving me the bug number).


I have: please note Bug 585033

JKB



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

Bug#591512: [Bug 585033] [sparc] Bus error in [@ read_tag_XYZType] function

[BERTRAND Joël]

bugzilla-dae...@mozilla.org a écrit :

Do not reply to this email.  You can add comments to this bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=585033

Jeff Muizelaar [:jrmuizel]jmuizel...@mozilla.com  changed:

What|Removed |Added

  CC||jmuizel...@mozilla.com

--- Comment #1 from Jeff Muizelaar [:jrmuizel]jmuizel...@mozilla.com  
2010-08-06 08:01:25 PDT ---
This seems like it could be a dup of bug 504766. Can you try with a browser
that has the fix to 504766.


This patch seems to fix sigbus error. Please apply.

Thanks a lot,

JKB




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

Bug#589040: snmpd: subprocess installed post-installation script returned error exit status 20

[BERTRAND Joël]

Package: snmpd
Version: 5.4.3~dfsg-1
Severity: normal


Hello,

This BR is NOT similar to #482041.

Configuration of snmpd aborts with :

Root rayleigh:[/lib/modules/2.6.34.1]  dpkg --configure -a
Setting up snmpd (5.4.3~dfsg-1) ...
make: Entering directory `/var/yp'
make[1]: Entering directory `/var/yp/systella.fr'
Updating netid.byname...
make[1]: Leaving directory `/var/yp/systella.fr'
make: Leaving directory `/var/yp'
make: Entering directory `/var/yp'
make[1]: Entering directory `/var/yp/systella.fr'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating netid.byname...
Updating master.passwd.byname...
Updating master.passwd.byuid...
Updating shadow.byname...
make[1]: Leaving directory `/var/yp/systella.fr'
make: Leaving directory `/var/yp'
...
Updating master.passwd.byuid...
Updating shadow.byname...
make[1]: Leaving directory `/var/yp/systella.fr'
make: Leaving directory `/var/yp'
dpkg: error processing snmpd (--configure):
 subprocess installed post-installation script returned error exit status 20
Errors were encountered while processing: snmpd
Root rayleigh:[/lib/modules/2.6.34.1]  

I can start snmpd by /etc/init.d/snmpd start and snmpd seems to work but
snmpd package stays unconfigured for dpkg.

Regards,

JKB

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

Kernel: Linux 2.6.34.1 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages snmpd depends on:
ii  adduser 3.112add and remove users and groups
ii  debconf [debconf-2.0]   1.5.32   Debian configuration management sy
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libsnmp15   5.4.3~dfsg-1 SNMP (Simple Network Management Pr
ii  libwrap07.6.q-19 Wietse Venema's TCP wrappers libra
ii  lsb-base3.2-23.1 Linux Standard Base 3.2 init scrip

snmpd recommends no packages.

snmpd suggests no packages.

-- Configuration Files:
/etc/snmp/snmpd.conf changed:
com2sec readonly 127.0.0.1 public
group MyROSystem v1paranoid
group MyROSystem v2c   paranoid
group MyROSystem usm   paranoid
group MyROGroup v1 readonly
group MyROGroup v2creadonly
group MyROGroup usmreadonly
group MyRWGroup v1 readwrite
group MyRWGroup v2creadwrite
group MyRWGroup usmreadwrite
view allincluded  .1   80
view system included  .iso.org.dod.internet.mgmt.mib-2.system
access MyROSystem  any   noauthexact  system none   none
access MyROGroup   any   noauthexact  allnone   none
access MyRWGroup   any   noauthexact  allallnone


-- debconf information:
  snmpd/upgradefrom521:



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

Bug#522632: libglib2.0-0: SIGBUG in g_utf16_to_utf8

[BERTRAND Joël]

Package: libglib2.0-0
Version: 2.20.0-2
Severity: grave
Justification: renders package unusable


Hello,

I'm trying to build seamonkey 1.1.15 from sources (I don't like 
iceweasel,
I prefered iceape, and note that iceweasel hangs with a SIGBUS too).

I have fixed some misalignments in seamonkey sources (specially in
nsTextFrame.cpp). Now, when I launch seamonkey, I obtain a beautiful SIGBUS that
comes from libglib :

rayleigh:[~/seamonkey]  seamonkey
installing flashblock
/usr/local/lib/seamonkey-1.1.15/run-mozilla.sh: line 131: 25943 Erreur du bus
(core dumped) $prog ${1+$@}
rayleigh:[~/seamonkey]  gdb /usr/local/lib/seamonkey-1.1.15/seamonkey-bin
core.25943 
GNU gdb 6.8-debian
Copyright (C) 2008 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 sparc-linux-gnu...
...
Core was generated by `/usr/local/lib/seamonkey-1.1.15/seamonkey-bin'.
Program terminated with signal 10, Bus error.
[New process 25943]
[New process 25972]
[New process 25950]
[New process 25946]
[New process 25949]
#0  0xf7470040 in g_utf16_to_utf8 () from /usr/lib/libglib-2.0.so.0
(gdb) backtrace
#0  0xf7470040 in g_utf16_to_utf8 () from /usr/lib/libglib-2.0.so.0
#1  0x0c96 in ?? ()
#2  0x0c96 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

I have tried to investigate without any success, but I'm pretty sure 
that
this bug doesn't come from seamonkey itself.

Regards,

JKB

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: sparc (sparc64)

Kernel: Linux 2.6.27.21 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libglib2.0-0 depends on:
ii  libc6 2.9-4  GNU C Library: Shared libraries
ii  libpcre3  7.8-2  Perl 5 Compatible Regular Expressi
ii  libselinux1   2.0.71-1   SELinux shared libraries

Versions of packages libglib2.0-0 recommends:
pn  libglib2.0-data   none (no description available)
ii  shared-mime-info  0.30-2 FreeDesktop.org shared MIME databa

libglib2.0-0 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#485525: Same bug with 2.2.9-2

[BERTRAND Joël]

Stefan Fritsch a écrit :

Hi Joel,


Hello Stephan,

can you tell if the errors started after you did some upgrade (e.g. 
apache or subversion)? Have they just started or have they occured 
for some weeks now? 


I don't know, but a month ago, my SVN repository worked fine.

If the errors are not new, you could try to rebuild the subversion 
packages and replace libsvn1 and libapache2-svn with the rebuilt 
versions. Rebuilding the same versions could help because the 
libapr1-dev that was used to build 1.4.6dfsg1-4 in Debian 
exported -DFORTIFY_SOURCE in apr-config, while the current 
libapr1-dev (1.2.12-4) does not do that anymore.


I shall try.

Regards,

JKB



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

Bug#485525: Same bug with 2.2.9-2

[BERTRAND Joël]

Stefan Fritsch a écrit :

Hi Joel,

can you tell if the errors started after you did some upgrade (e.g. 
apache or subversion)? Have they just started or have they occured 
for some weeks now? 

If the errors are not new, you could try to rebuild the subversion 
packages and replace libsvn1 and libapache2-svn with the rebuilt 
versions. Rebuilding the same versions could help because the 
libapr1-dev that was used to build 1.4.6dfsg1-4 in Debian 
exported -DFORTIFY_SOURCE in apr-config, while the current 
libapr1-dev (1.2.12-4) does not do that anymore.


OK, I have tried, but dpkg-buildpackage returns an error :

/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/perl/native/t/8lockmy 
variable $acc masks earlier declaration in same scope at 
/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/perl/native/t/8lock.t 
line 39.

/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/pe/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/perl/native/t/8lockok
All tests successful, 7 subtests skipped.
Files=10, Tests=173, 19 wallclock secs (10.29 cusr +  0.88 csys = 11.17 CPU)
make[2]: quittant le répertoire « 
/export/home/bertrand/packages/subversion-1.4.6dfsg1/BUILD/subversion/bindings/swig/perl/native 
»
/usr/bin/make -C BUILD check-swig-rb CLEANUP=true LC_ALL=C 
LD_LIBRARY_PATH=/export/home/bertrand/packages/subversion-1.4.6dfsg1/BUILD/subversion/tests/.libs
make[2]: entrant dans le répertoire « 
/export/home/bertrand/packages/subversion-1.4.6dfsg1/BUILD »
cd 
/import/home/bertrand/packages/subversion-1.4.6dfsg1/BUILD/subversion/bindings/swig/ruby; 
\
  /usr/bin/ruby1.8 -I 
/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/ruby 
\


/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/ruby/test/run-test.rb 
\

--verbose=normal
/export/home/bertrand/packages/subversion-1.4.6dfsg1/subversion/bindings/swig/ruby/test/run-test.rb:18: 
uninitialized constant Locale::ALL (NameError)

make[2]: *** [check-swig-rb] Erreur 1
make[2]: quittant le répertoire « 
/export/home/bertrand/packages/subversion-1.4.6dfsg1/BUILD »

make[1]: *** [check-swig-rb] Erreur 2
make[1]: quittant le répertoire « 
/export/home/bertrand/packages/subversion-1.4.6dfsg1 »

make: *** [debian/stamp-build-arch] Erreur 2

Any idea ?

Regards,

JKB



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

Bug#485525: Same bug with 2.2.9-2

[BERTRAND Joël]

Hello,

I have exactly hesame bug with

Root rayleigh:[~]  dpkg-query -l apache2* | grep ^ii
ii  apache2 2.2.9-2 
Apache HTTP Server metapackage
ii  apache2-mpm-prefork 2.2.9-2 
Apache HTTP Server - traditional non-threade
ii  apache2-utils   2.2.9-2 
utility programs for webservers
ii  apache2.2-common2.2.9-2 
Apache HTTP Server common files

Root rayleigh:[~] 

I have install a SVN repository over https. Sometimes it works, 
sometimes it does not :


rayleigh:[~/jcollab/svn]  svn --username bertrand --password  
co https://rayleigh.systella.fr/svn/pc30/branches/PC30-prod-1.0/

Révision 397 extraite.
rayleigh:[~/jcollab/svn]  svn --username bertrand --password  
co https://rayleigh.systella.fr/svn/pc30/branches/PC30-prod-1.0/

svn: Échec de la requête PROPFIND sur '/svn/pc30/branches/PC30-prod-1.0'
svn: PROPFIND de '/svn/pc30/branches/PC30-prod-1.0': Could not send 
request body: SSL socket write failed (https://rayleigh.systella.fr)


Each time request fails, apache2 writes in log :
== error.log ==
[Wed Jul 02 13:41:03 2008] [notice] child pid 18654 exit signal Bus 
error (10)


Regards,

JKB




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

Bug#454052: daily.inc

[BERTRAND Joël]

Stephen Gran wrote:

Oh, and if both of you could make the contents of /var/lib/clamav
available somehow (tarball mailed to the bug report, available for
download somewhere, etc) that would be very helpful.


	Stephen, I only have daily.inc. Required tarbal is available at 
http://www.systella.fr/~bertrand/clamav.tar.gz (66,45 MB !). It will be 
available until this evening (18h00 CET).


Regards,

JKB



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

Bug#454052: Segfault in libclamav2 (phishingScan)

[BERTRAND Joël]

Package: libclamav2
Version: 0.91.2-3 0.91.2-4

Hello,

	I have seen a segfault in libclamav2 when I turn on 
PhishingSignatures flag on a sparc64/smp (U80). I have run clamd with 
debug options in gdb :


LibClamAV debug: blobClose: recovered 8180 bytes from 8192
LibClamAV debug: blobClose: recovered 8183 bytes from 8192
LibClamAV debug: blobClose: recovered 8183 bytes from 8192
LibClamAV debug: blobClose: recovered 8156 bytes from 8192
LibClamAV debug: blobClose: recovered 8156 bytes from 8192
LibClamAV debug: getHrefs: html_normalise_mem returned
LibClamAV debug: Phishcheck: href with no contents?
LibClamAV debug: Phishcheck:Checking url 
http://home.edt02.net/emc/emchV4c/?c=18
   cliquant 
ici6369-0-49344-531291651-0-0-0-0-nadege.teixeira%atpc30.fr-en
LibClamAV debug: Phishing: looking up in whitelist: 
http://home.edt02.net/emc/em

chV4c/?c=18860-49343-28165-1-96369-0-49344-531291651-0-0-0-0-nadege.teixeira�pc3
0.fr:encliquantici; host-only:0
LibClamAV debug: Looking up in regex_list: 
http://home.edt02.net/emc/emchV4c/?c=

18860-49343-28165-1-96369-0-49344-531291651-0-0-0-0-nadege.teixeira�pc30.fr:encl
iquantici/

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7877b90 (LWP 1991)]
0xf7f8527c in regex_list_match () from /usr/lib/libclamav.so.2
(gdb) up
#1  0xf7f835b8 in whitelist_match () from /usr/lib/libclamav.so.2
(gdb) up
#2  0xf7f82adc in phishingScan () from /usr/lib/libclamav.so.2
(gdb) up
#3  0xf7f3f57c in ?? () from /usr/lib/libclamav.so.2
(gdb) up
#4  0xf7f3f57c in ?? () from /usr/lib/libclamav.so.2
(gdb) up
Initial frame selected; you cannot go up.
(gdb) quit

My clamd.conf :

LocalSocket /var/run/clamav/clamd.sock
FixStaleSocket true
User defang
AllowSupplementaryGroups true
ScanMail true
ScanArchive true
ArchiveMaxRecursion 5
ArchiveMaxFiles 1000
ArchiveMaxFileSize 10M
ArchiveMaxCompressionRatio 250
ArchiveLimitMemoryUsage false
ArchiveBlockEncrypted false
MaxDirectoryRecursion 15
FollowDirectorySymlinks false
FollowFileSymlinks false
ReadTimeout 120
MaxThreads 12
MaxConnectionQueueLength 30
StreamMaxLength 10M
LogSyslog true
LogFacility LOG_LOCAL6
LogClean false
LogVerbose true
PidFile /var/run/clamav/clamd.pid
DatabaseDirectory /var/lib/clamav/
TemporaryDirectory /tmp
SelfCheck 1800
Foreground true
Debug true
ScanPE true
ScanOLE2 true
ScanHTML true
DetectBrokenExecutables false
MailFollowURLs false
ArchiveBlockMax false
ExitOnOOM false
LeaveTemporaryFiles false
AlgorithmicDetection true
ScanELF true
NodalCoreAcceleration false
IdleTimeout 30
MailMaxRecursion 64
PhishingSignatures false
LogFile /var/log/clamav/clamav.log
LogTime true
LogFileUnlock false
LogFileMaxSize 0

Regards,

JKB

Bug#454052: Segfault in libclamav2 (phishingScan)

[BERTRAND Joël]

Stephen Gran wrote:

This one time, at band camp, BERTRAND Joël said:

Hello,

	I have seen a segfault in libclamav2 when I turn on 
PhishingSignatures flag on a sparc64/smp (U80). I have run clamd with 
debug options in gdb :


Oddly enough, I just got another report of this on IRC.  Can you send
a core file?  Or perhaps install clamav-dbg and get a backtrace with
symbols?


	I cannot (it's a mail server and I cannot stop service...). I have 
tried to obtain a core without any success (even in foreground). But if 
I add :


PhishingScanURLs true
PhishingRestrictedScan true
PhishingAlwaysBlockSSLMismatch true
PhishingAlwaysBlockCloak true

libclamav2 runs without any trouble.

JKB

Bug#450573: OpenOffice cannot open file over NFS

[BERTRAND Joël]

Package: openoffice.org
Version: 2.2.1-10
Arch: powerpc32, sparc
Severity: important

Hello,

	I use a NFS server (sparc64) and some clients (sparc64, powerpc32). All 
home directories are on NFS server. With OpenOffice 2.2.1-8, all clients 
can open files over NFS. With 2.2.1-10, OpenOffice freezes.


	All server and clients run uptodate debian/testing. NFS works fine, and 
I can open all files when OpenOffice directly runs on server.


Any idea ?

Regards,

JKB



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

Bug#431746: #431746,xserver-xorg: Xinerama active, but = 0 screens?

[BERTRAND Joël]

Brice Goglin a écrit :

BERTRAND Joël wrote:

I have tested some configurations to isolate parameters :

1/ sparc32/smp SS20 + CG14 - bug (I haven't tested with CG6 because
my test workstation has no empty Sbus). I have a ZX framebuffer (leo)
in a SS5, but ZX framebuffer support is totaly broken in 2.6.x kernels;
2/ sparc64/smp U60 (UPA/PCI) + Creator3D - bug;
3/ sparc64/smp U2 (UPA/Sbus) + Creator3D - bug;
4/ i386 + prosavage8 - no bug;
5/ i386 + Radeon Mobility 9200 (AGP) - no bug.

All configurations are up to date (debian testing).

I don't know if this bug is sparc32/64 specific, but I only see
this bug on sparc32 and sparc64, never on i386.


By the way, the same behavior has been reported in bug #432256.


It is the same bug. gdm does not work, xscreensaver too...


Which xserver-xorg-core and drivers are you using on all these machines?


Sparc64/sparc32:
Root fermat:[~]  dpkg -l | grep xserver
ii  xserver-xorg  1:7.2-5 
the X.Org X server
ii  xserver-xorg-core 2:1.3.0.0.dfsg-6 
X.Org X server -- core server
ii  xserver-xorg-video-suncg141:1.1.0-2 
X.Org X server -- Sun CG14 display driver
ii  xserver-xorg-video-sunffb 1:1.1.0-2 
X.Org X server -- Sun FFB display driver


i386:
Root cauchy:[~]  dpkg -l | grep xserver
ii  xserver-xorg 1:7.2-5 the 
X.Org X server
ii  xserver-xorg-core2:1.3.0.0.dfsg-6 
X.Org X server -- core server
ii  xserver-xorg-video-savage1:2.1.2-5 
X.Org X server -- Savage display driver


Regards,

JKB

Bug#399862: Xorg 7.1 on CG14 (sparc32)

[BERTRAND Joël]

Brice Goglin a écrit :

On Tue, Jun 05, 2007 at 10:15:13AM +0200, BERTRAND Joël wrote:

Several months ago, you reported a bug to the Debian BTS regarding Xorg
not working anymore on your cg14 board. The bug was expected to be fixed
soon. Did you reproduce this problem recently? With latest
xserver-xorg-core and drivers?
	I haven't tested with xfs since my bug report and I don't have time 
	to test (my SS20 is only used to test 2.6 kernels and I don't have stable 
kernel enough to test Xorg or to make a apt-get upgrade). I have added 
this test to my TODO list ;-)


Hi,

Did you have a chance to test this?


Yes, I have.

	Configuration : SS20 with dual SM71, 2.6.22-rc7 smp kernel (with only 
one SMP related bug on sparc32 ;-) ), CG14 ([EMAIL PROTECTED]), 
debian/testing up to date.


	1/ X works fine (but I have to add /dev/tty0 in udev configuration 
script because udev does'nt create tty0 !) with xfs ;
	2/ gdm does not run (same bug than sparc64, XineramaIsActive always 
returns True even if Xinerama is not active).


Regards,

JKB

Bug#399862: Xorg 7.1 on CG14 (sparc32)

[BERTRAND Joël]

Brice Goglin a écrit :

BERTRAND Joël wrote:

Yes, I have.

Configuration : SS20 with dual SM71, 2.6.22-rc7 smp kernel (with
only one SMP related bug on sparc32 ;-) ), CG14 ([EMAIL PROTECTED]),
debian/testing up to date.

1/ X works fine (but I have to add /dev/tty0 in udev configuration
script because udev does'nt create tty0 !) with xfs ;
2/ gdm does not run (same bug than sparc64, XineramaIsActive
always returns True even if Xinerama is not active).


So, if I understand correctly, #399862 can be closed


	Yes, #399862 can be closed. I have token some time to test because 2.6 
kernels are not stable on sparc32 (even without SMP due to a lack in ESP 
SCSI driver)...



while #431746
occurs on multiple machines?


I have tested some configurations to isolate parameters :

1/ sparc32/smp SS20 + CG14 - bug (I haven't tested with CG6 because my 
test workstation has no empty Sbus). I have a ZX framebuffer (leo) in a 
SS5, but ZX framebuffer support is totaly broken in 2.6.x kernels;

2/ sparc64/smp U60 (UPA/PCI) + Creator3D - bug;
3/ sparc64/smp U2 (UPA/Sbus) + Creator3D - bug;
4/ i386 + prosavage8 - no bug;
5/ i386 + Radeon Mobility 9200 (AGP) - no bug.

All configurations are up to date (debian testing).

	I don't know if this bug is sparc32/64 specific, but I only see this 
bug on sparc32 and sparc64, never on i386.


Regards,

JKB

Bug#431746: #431746,xserver-xorg: Xinerama active, but = 0 screens?

[BERTRAND Joël]

Brice Goglin a écrit :

retitle 431746 Xorg/sparc: Xinerama active, but = 0 screens?
thank you


You're welcome.


BERTRAND Joël wrote:

I have tested some configurations to isolate parameters :

1/ sparc32/smp SS20 + CG14 - bug (I haven't tested with CG6 because
my test workstation has no empty Sbus). I have a ZX framebuffer (leo)
in a SS5, but ZX framebuffer support is totaly broken in 2.6.x kernels;
2/ sparc64/smp U60 (UPA/PCI) + Creator3D - bug;
3/ sparc64/smp U2 (UPA/Sbus) + Creator3D - bug;
4/ i386 + prosavage8 - no bug;
5/ i386 + Radeon Mobility 9200 (AGP) - no bug.

All configurations are up to date (debian testing).

I don't know if this bug is sparc32/64 specific, but I only see
this bug on sparc32 and sparc64, never on i386.


Unfortunately, I don't have access to any machine like this.


	If you want, I can open an account on a U2 (dual UltraSPARC II/300 MHz 
with 2 GB and a Creator3D fb).



You said earlier:
All program that test Xinerama crash because XineramaIsActive returns
TRUE _and_ XineramaQueryScreens returns a NULL pointer and a number of
screens =0. Maybe the bug is in XineramaQueryScreens ?

So I guess the next step would be to check the return values of these
functions on your i386 machines?


	Maybe, but I don't have decent i386 to rebuild xorg from scratch (only 
K6-III/400 with 256 MB, other i386 are laptop, and I cannot use it to test).



Then, it will probably be a good time
to forward the bug upstream (unless you want to rebuild the server with
some debugging printf to find out what's going on in the internal
functions).


I can, if that can help you.


By the way, when you say = 0, do you mean  0 ?


No, = 0. This message comes from /var/log/syslog and is returned by 
gdm.

Regards,

JKB

Bug#431746: xserver-xorg: Xinerama active, but = 0 screens?

[BERTRAND Joël]

Brice Goglin a écrit :

reassign 431746 xserver-xorg-core
found 431746 2:1.3.0.0.dfsg-6
thank you



BERTRAND Joël wrote:

Since my last upgrade, I cannot use X anymore on all my sparc64. All use
Creator3D framebuffer and I'm not sure that this trouble occurs with
another framebuffer. I never see this bug on i386, but I don't know
if it comes from framebuffer driver or if it is sparc64 specific.
  


When you say I cannot use X anymore, do you just mean Xinerama
programs as explained below? Or is the whole X broken?


Only Xinerama, but all programs that call XineramaIsActive crash.


All program that test Xinerama crash because XineramaIsActive returns 
TRUE
_and_ XineramaQueryScreens returns a NULL pointer and a number of screens 
=
0. Maybe the bug is in XineramaQueryScreens ?
  


Might be related to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406692 (Xinerama info
reported incorrectly to clients)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421449 (xinerama
extension reported even when disabled)


Maybe related to 421449.

Regards,

JKB

Bug#431746: xserver-xorg: Xinerama active, but = 0 screens?

[BERTRAND Joël]

Package: xserver-xorg
Version: 1:7.2-5
Severity: important


Hello,

Since my last upgrade, I cannot use X anymore on all my sparc64. All use
Creator3D framebuffer and I'm not sure that this trouble occurs with
another framebuffer. I never see this bug on i386, but I don't know
if it comes from framebuffer driver or if it is sparc64 specific.

All program that test Xinerama crash because XineramaIsActive returns 
TRUE
_and_ XineramaQueryScreens returns a NULL pointer and a number of 
screens =
0. Maybe the bug is in XineramaQueryScreens ?

Regards,

JKB

-- Package-specific info:
Contents of /var/lib/x11/X.roster:
xserver-xorg

/etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum.

X server symlink status:
lrwxrwxrwx 1 root root 13 2006-12-17 19:12 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1805072 2007-06-01 21:45 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:

/etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2976 2007-07-02 19:46 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type man /etc/X11/xorg.conf at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section Files
FontPathunix/:7100
FontPath/usr/share/fonts/X11/misc
FontPath/usr/X11R6/lib/X11/fonts/misc
FontPath/usr/share/fonts/X11/cyrillic
FontPath/usr/X11R6/lib/X11/fonts/cyrillic
FontPath/usr/share/fonts/X11/100dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/share/fonts/X11/75dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/share/fonts/X11/Type1
FontPath/usr/X11R6/lib/X11/fonts/Type1
FontPath/usr/share/fonts/X11/100dpi
FontPath/usr/X11R6/lib/X11/fonts/100dpi
FontPath/usr/share/fonts/X11/75dpi
FontPath/usr/X11R6/lib/X11/fonts/75dpi
# path to defoma fonts
FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection

Section Module
Loadi2c
Loadbitmap
Loadddc
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadvbe
Loadcfb
Loadcfb32
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  CoreKeyboard
Option  XkbRules  xorg
Option  XkbModel  pc105
Option  XkbLayout fr
Option  XkbVariantlatin9
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  Emulate3Buttons   true
EndSection

Section Device
Identifier  Carte vido gnrique
Driver  sunffb
Option  UseFBDev  true
EndSection

Section Monitor
Identifier  cran gnrique
Option  DPMS
HorizSync   28-64
VertRefresh 43-60
EndSection

Section Screen
Identifier  Default Screen
Device  Carte vido gnrique
Monitor cran gnrique
DefaultDepth24
SubSection Display
Depth   1
Modes   1280x1024
EndSubSection
SubSection Display
Depth   4
Modes   1280x1024
EndSubSection
SubSection Display
Depth   8
Modes   1280x1024
EndSubSection
SubSection Display
Depth   15
Modes   1280x1024
EndSubSection
SubSection Display
Depth   16
Modes   1280x1024
EndSubSection
SubSection Display
Depth   24
Modes   1280x1024
EndSubSection
EndSection

Section ServerLayout
Identifier   

Bug#430984: pthreads issue with libc6

[BERTRAND Joël]

Aurelien Jarno a écrit :

On Thu, Jun 28, 2007 at 07:22:51PM +0200, BERTRAND Joël wrote:

Package: libc6
Version: 2.5-9
Arch: sparc64

^^^
huh?? Is it really sparc64?


Why ?


Severity: important

Hello,

	I have seen a lot of troubles with all programs that use threads on 
	a Sun U80/smp running debian testing.


	clamd, bind, milter-greylist, mimedefang, fail2ban and a lot of 
	other multithreaded programs stop with dead lock. They don't die, but 
remain in sleep state (mutex trouble ?). This trouble appear when I have 
installed libc6 2.5-9. Kernel is 2.6.20.11.




With glibc 2.5, the threading library has switched to NPTL on sparc, 
which has triggered a lot of kernel bugs. This is likely the case here.


Please try to update your kernel to 2.6.21 (or 2.6.22-rc) and see if it
helps.


2.6.21.5 sounds to have fixed these bugs.

Regards,

JKB

Bug#430984: pthreads issue with libc6

[BERTRAND Joël]

Aurelien Jarno a écrit :

On Thu, Jun 28, 2007 at 07:22:51PM +0200, BERTRAND Joël wrote:

Package: libc6
Version: 2.5-9
Arch: sparc64

^^^
huh?? Is it really sparc64?


Severity: important

Hello,

	I have seen a lot of troubles with all programs that use threads on 
	a Sun U80/smp running debian testing.


	clamd, bind, milter-greylist, mimedefang, fail2ban and a lot of 
	other multithreaded programs stop with dead lock. They don't die, but 
remain in sleep state (mutex trouble ?). This trouble appear when I have 
installed libc6 2.5-9. Kernel is 2.6.20.11.




With glibc 2.5, the threading library has switched to NPTL on sparc, 
which has triggered a lot of kernel bugs. This is likely the case here.


Please try to update your kernel to 2.6.21 (or 2.6.22-rc) and see if it
helps.


	I have tested with 2.6.21.5. It seems to run longer than with 
2.6.20.11, but I can see the same troubles... I will test tomorrow with 
2.6.22-rc7.


JKB

Bug#430984: pthreads issue with libc6

[BERTRAND Joël]

Package: libc6
Version: 2.5-9
Arch: sparc64
Severity: important

Hello,

	I have seen a lot of troubles with all programs that use threads on a 
Sun U80/smp running debian testing.


	clamd, bind, milter-greylist, mimedefang, fail2ban and a lot of other 
multithreaded programs stop with dead lock. They don't die, but remain 
in sleep state (mutex trouble ?). This trouble appear when I have 
installed libc6 2.5-9. Kernel is 2.6.20.11.


Regards,

JKB


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

Bug#428675: New tests

[BERTRAND Joël]

Hello,

	Bind9 hangs too. Sometimes, it hangs without any message and I have to 
restart it. All bind9 threads are alive, but they don't answer to DNS 
queries...


Regards,

JKB


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

Bug#428675: Timeout on clamd.sock

[BERTRAND Joël]

Package: clamav-daemon
Version: 0.90.1 and 0.90.3
Kernel: 2.6.20.11
libc6: 2.5
system: debian testing (up to date)

Hello,

	I have installed a long time ago 
sendmail/mimedefang/spamassassin/clamav-daemon as mail server on a Sparc 
Ultra80 (4 processors). The last week, I have made a dist-upgrade. libc6 
was upgraded to 2.5 and clamav-daemon to 0.90.1. I have tried 0.90.3 too 
without success.


	Since this upgrade, clamd randomly refuses any connection on its socket 
any mimedefang aborts. If I remove clamd configuration on mimedefang, it 
works fine. clamd can run without any trouble three or four hours, but 
when it starts to refuse connection, I have found only one solution, 
restart clamd.


	I don't see anything in log files. You will find an example of an 
aborted transaction:


Jun 13 14:19:46 kant mimedefang.pl[1537]: l5DCIT4D001108: Timeout 
reading from clamd daemon at /var/run/clamav/clamd.sock
Jun 13 14:19:46 kant mimedefang.pl[1537]: Problem running virus scanner: 
code=999, category=cannot-execute, action=tempfail
Jun 13 14:19:46 kant mimedefang.pl[1537]: filter: l5DCIT4D001108: 
tempfail=1
Jun 13 14:19:46 kant mimedefang-multiplexor[6101]: stats 1181737186.064 
EndFilter slave=1 nslaves=5 nbusy=4 numRequests=8
Jun 13 14:19:46 kant mimedefang[6117]: l5DCIT4D001108: Tempfailing 
because filter instructed us to
Jun 13 14:19:46 kant sm-mta[1108]: l5DCIT4D001108: Milter: data, 
reject=451 4.3.0 Problem running virus-scanner
Jun 13 14:19:46 kant sm-mta[1108]: l5DCIT4D001108: to=[EMAIL PROTECTED], 
delay=00:01:11, pri=1846240, stat=Problem running virus-scanner


	When clamd refuses connections, it is not dead and I see a lot of clamd 
threads with ps -eLf in sleep state.


	I use a second sparc U60 a test server with the same configuration. I 
haven't made any dist-upgrade process on this station when I have seen 
this trouble and this U60 works fine with the same mimedefang version, a 
0.90.1 clamd and a 2.3.6.ds1-13 libc6.


Any idea ?

Regards,

JKB


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

Bug#428675: New tests

[BERTRAND Joël]

Hello,

	I have rebuilt clamav-0.90.3 from sources and 0.91rc1. Last one works 
better (less CPU load), but hangs too after a random time. I suspect a 
mutex trouble (maybe the new pthread lib or libc is responsible of this 
trouble).


	If I replace clamd by clamscan, my mail server works fine. With 
clamdscan (or directly with clamd), it randomly hangs when some clamd 
threads are running.


Regards,

JKB


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

Bug#399862: Xorg 7.1 on CG14 (sparc32)

[BERTRAND Joël]

Brice Goglin a écrit :

Hi,

Several months ago, you reported a bug to the Debian BTS regarding Xorg
not working anymore on your cg14 board. The bug was expected to be fixed
soon. Did you reproduce this problem recently? With latest
xserver-xorg-core and drivers?


	I haven't tested with xfs since my bug report and I don't have time to 
test (my SS20 is only used to test 2.6 kernels and I don't have stable 
kernel enough to test Xorg or to make a apt-get upgrade). I have added 
this test to my TODO list ;-)


Regards,

JKB

Bug#423151: hpoj on sparc64

[BERTRAND Joël]

Package: hpoj
Version: 0.91-12

Hello,

	I'm trying to use a HP PSC 1315 on a sparc64 server (Ultra60/SMP). This 
all-in-one printer can print without any trouble but I cannot use it to 
scan documents. From a i386 laptop running debian (with the same 
configuration), it works fine.


ptal-init setup doesn't find any scanner :

...

Probe for USB-connected devices ([y]/n)?

--

Press Enter alone to continue, or if you would like to add a
JetDirect-connected device, then enter its dotted-decimal
IP address or hostname here ---

...

Any idea ?

Regards,

JKB


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

Bug#420193: [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

Bertrand, feel free to try this patch on your sparc64; as I said, it
works fine here (at least as long as nothing goes wrong ;), but better
keep your finger on the scanner's power button just in case. Tell us
how it goes.


Hello,

I have tried on my U2. This patch works fine for me.


That's a saturday afternoon well spent.


;-)

Thanks,

JKB

Bug#420193: [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

BERTRAND Joël [EMAIL PROTECTED] wrote:

Hi,


Bertrand, feel free to try this patch on your sparc64; as I said, it
works fine here (at least as long as nothing goes wrong ;), but better
keep your finger on the scanner's power button just in case. Tell us
how it goes.

I have tried on my U2. This patch works fine for me.


Great. How's the scan speed ?


I don't see any difference...

Regards,

JKB

Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

BERTRAND Joël [EMAIL PROTECTED] wrote:


Hello Julien,


The Linux SG3 interface does not work properly when a 32bit app is
talking to a 64bit kernel.

Maybe. But with 2.6.20.3 kernel, on the same sparc, I can use
this scanner (with libsane that comes with sarge), but system is not
stable. I don't see any diff on sg driver between 2.6.20.3 and
2.6.21-rc7.


Have you diffed the 2 libsane versions yet ? (the backend you're using
+ common code in sanei/ for a start)


	I have made some test with a U1E (same system, many IOMMU patched 
kernels from 2.6.19 to 2.6.20.7, libsane from 1.0.14 to 1.0.18). I 
cannot use this scanner. It is not detected by sane-find-scanner. But 
I'm sure I have used this one on my U2. Question is 'how' ?


	I have made another test with a USB scanner on an U60 (kernel 2.6.20.4) 
with a PCI USB2 adapter. It is not detected, and if I force its 
detection, I receive some ioctl32 errors. On a SS20, this scanner works 
fine, thus your conclusion is right, it's a trouble between 32 bits wide 
userland and 64 bits wide kernel...


Regards,

JKB

Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

BERTRAND Joël [EMAIL PROTECTED] wrote:


I use a Snapscan 1236s with xsane on an i386 (K6-III/400, 256 MB,
Adaptec 2940U, kernel 2.6.20.1) without any trouble. If I use the same
scanner on an U2 (2xUltraSPARC-II/296 MHz, 2 GB, Happymeal-ESP, kernel
2.6.21-rc7), sane-find-scanner does not find any scanner but this
scanner is shown in /proc/scsi/scsi. Both stations run lenny.


OK after a quick check, this was discussed back in january 2003.


I have seen this archive.


The Linux SG3 interface does not work properly when a 32bit app is
talking to a 64bit kernel.


	Maybe. But with 2.6.20.3 kernel, on the same sparc, I can use this 
scanner (with libsane that comes with sarge), but system is not stable. 
I don't see any diff on sg driver between 2.6.20.3 and 2.6.21-rc7.



You can either:
 - try to do a 64bit build of sane-backends
 - try to use the old SG interface, if still exists/works

Unfortunately, both options are unfit for Debian; 64bit binaries would
require to rebuild all the dependency chain, and using the old SG
interface won't last long :/


Thus, any issue or workaround ?

Regards,

JKB

Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

BERTRAND Joël [EMAIL PROTECTED] wrote:

Hi,


The Linux SG3 interface does not work properly when a 32bit app is
talking to a 64bit kernel.

Maybe. But with 2.6.20.3 kernel, on the same sparc, I can use
this scanner (with libsane that comes with sarge), but system is not
stable. I don't see any diff on sg driver between 2.6.20.3 and
2.6.21-rc7.


Have you diffed the 2 libsane versions yet ? (the backend you're using
+ common code in sanei/ for a start)


	No, I don't, because I have to find a couple libsane/kernel that works 
on sparc64 and another that doesn't work, and I cannot reboot my U2 only 
to make test.



You can either:
 - try to do a 64bit build of sane-backends
 - try to use the old SG interface, if still exists/works

Unfortunately, both options are unfit for Debian; 64bit binaries would
require to rebuild all the dependency chain, and using the old SG
interface won't last long :/

Thus, any issue or workaround ?


No, not at the moment, I'm afraid. Can you try to run the libsane
version from sarge on the sparc and see if it still works ?


	I have tried, but without success. I have tried 1.0.14, 1.0.16 and 
1.0.18. Maybe, like mysql-server bug on sparc64, trouble comes from 
glibc or dark side of kernel itself...


Regards,

JKB

Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Julien BLACHE a écrit :

BERTRAND Joël [EMAIL PROTECTED] wrote:

Hi,


Hello,


Have you diffed the 2 libsane versions yet ? (the backend you're using
+ common code in sanei/ for a start)

No, I don't, because I have to find a couple libsane/kernel
that works on sparc64 and another that doesn't work, and I cannot
reboot my U2 only to make test.


No, I meant looking at the code in both SANE versions and see if
there's anything that rings a bell in the diff.


I shall check sources this evening.


No, not at the moment, I'm afraid. Can you try to run the libsane
version from sarge on the sparc and see if it still works ?

I have tried, but without success. I have tried 1.0.14, 1.0.16
and 1.0.18. Maybe, like mysql-server bug on sparc64, trouble comes
from glibc or dark side of kernel itself...


Ouch! So libsane from sarge works on an older kernel, and doesn't work
on the newer one ?


	Yes. I have check kernel sources (sg tree) and the last change was made 
in 2006...


JKB

Bug#420193: libsane on sparc64 with SCSI scanner

[BERTRAND Joël]

Package: libsane
Version: 1.0.18-6

I use a Snapscan 1236s with xsane on an i386 (K6-III/400, 256 MB, 
Adaptec 2940U, kernel 2.6.20.1) without any trouble. If I use the same 
scanner on an U2 (2xUltraSPARC-II/296 MHz, 2 GB, Happymeal-ESP, kernel 
2.6.21-rc7), sane-find-scanner does not find any scanner but this 
scanner is shown in /proc/scsi/scsi. Both stations run lenny.


I have used this scanner in the same configuration (but with an older 
release of sane) on this U2 without trouble. I cannot test with the same 
kernel on the sparc (because kernel is unstable before 2.6.21-rc7 due to 
an IOMMU/Sbus bug), and I cannot reboot my K6 because it makes some 
complex computations... Thus, I don't know if the trouble comes from 
libsane or sg kernel module...


Regards,

JKB


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

Bug#334339: Major bug in mysql build (all versions since 4.1)

[BERTRAND Joël]

Daniel Smolik a écrit :

BERTRAND Joël napsal(a):

Frans Pop a écrit :


tags 334339 - wontfix
thanks

On Sunday 25 March 2007 20:02, BERTRAND Joël wrote:


See bug #334339 (wontfix).



IMO the wontfix tag is not correct. There should at least be an 
explanation by the maintainer _why_ he considers this an issue that 
is does not need to be fixed.
Removing the tag as it was added without any justification. AFAICT 
this is a real issue that should be solved.



I aggree.

Bug was reported to mysql dev without success because dev have 
said that is a gcc-4.0 bug, not a mysql bug.



Yes, but the gcc maintainers have said that the bug there has been fixed
long ago. Unfortunately they don't say in which version.



has been fixed ? I have tried to build mysql with _all_ gcc 
release between 3.3 and 4.1 without any success. Where have you seen 
that this bug was fixed ?



Maybe, but I think it is not very difficult to fix the configure.in
script to avoid this bug.



I have no idea about that and no idea how that would affect other 
architectures. Anyway, It is now probably too late to fix this for Etch.



I have no idea too. In a first time, I suspected a 32 bits wide 
userland and a 64 bits kernel... Maybe a trouble with gcc include on 
sparc architectures.


Regards,

JKB



Hi,
could you tell me if this bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413471
reported by me is the same as bug you reported ?


Yes, I think. But to be sure, you have to apply my workaround.

Regards,

JKB

Bug#334339: Major bug in mysql build (all versions since 4.1)

[BERTRAND Joël]

Frans Pop a écrit :

tags 334339 - wontfix
thanks

On Sunday 25 March 2007 20:02, BERTRAND Joël wrote:

See bug #334339 (wontfix).


IMO the wontfix tag is not correct. There should at least be an 
explanation by the maintainer _why_ he considers this an issue that is 
does not need to be fixed.
Removing the tag as it was added without any justification. AFAICT this is 
a real issue that should be solved.


I aggree.

	Bug was reported to mysql dev without 
success because dev have said that is a gcc-4.0 bug, not a mysql bug.


Yes, but the gcc maintainers have said that the bug there has been fixed
long ago. Unfortunately they don't say in which version.


	has been fixed ? I have tried to build mysql with _all_ gcc release 
between 3.3 and 4.1 without any success. Where have you seen that this 
bug was fixed ?



Maybe, but I think it is not very difficult to fix the configure.in
script to avoid this bug.


I have no idea about that and no idea how that would affect other 
architectures. Anyway, It is now probably too late to fix this for Etch.


	I have no idea too. In a first time, I suspected a 32 bits wide 
userland and a 64 bits kernel... Maybe a trouble with gcc include on 
sparc architectures.


Regards,

JKB

Bug#394047: udev and sparc64 (kernel 2.9.19.1, testing release)

[BERTRAND Joël]

Marco d'Itri a écrit :

On Dec 19, BERTRAND Joël [EMAIL PROTECTED] wrote:

	I can see the same trouble I cannot solve. If I delete 
/etc/udev/rules.d/z25_persistent-net.rules, I can reboot the workstation 
with all network interfaces. If I don't delete this file, one of these 
are renamed. Is there a workaround ?

Hard to tell since you did not report the content of the file. Please
do. It could be caused by a buggy driver.
Anyway, you can always disable this by deleting the
z45_persistent-net-generator.rules alias.


	I cannot copy this file because I delete it with a script in /etc/rc2.d 
(it was rewritten during the boot process). The only difference I have 
seen between a functional script and mine is the name of the interface : 
eth0_rename and not eth0. I have seen the same mistake on a SS20 with 
two Lance interface. Note that I have three ethernet interface on the 
same workstations, two hme and a 3com and the trouble only seems to come 
on a workstation that has two interfaces that use the same driver.


Regards,

JKB

Bug#394047: udev and sparc64 (kernel 2.9.19.1, testing release)

[BERTRAND Joël]

Hello,

	I can see the same trouble I cannot solve. If I delete 
/etc/udev/rules.d/z25_persistent-net.rules, I can reboot the workstation 
with all network interfaces. If I don't delete this file, one of these 
are renamed. Is there a workaround ?


Regards,

JKB


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

Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

[BERTRAND Joël]

Jurij Smakov a écrit :

Hi Joel,


Hello Jurij,

Sorry, I cannot reproduce the behavior you are describing. I have a 
SS20 box, running sid with Debian's linux-image-2.6.18-3-sparc32 
(version 2.6.18-6) kernel:


	I don't try with debian package, only with official linux kernel. I 
have tested the 2.6.19 but sunlance doesn't work for me in a SS20 that 
runs with two sunlance (eth0/1)and one hme (eth2) interfaces... I don't 
know the difference between the debian and official kernels.



debian:~# uname -a
Linux debian 2.6.18-3-sparc32 #1 Fri Nov 24 16:10:16 GMT 2006 sparc GNU/Linux
debian:~# cat /proc/version 
Linux version 2.6.18-3-sparc32 (Debian 2.6.18-6) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 Fri Nov 
24 16:10:16 GMT 2006
debian:~# cat /proc/cpuinfo 
cpu : ROSS HyperSparc RT625 or RT626

fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
prom: 2.25
type: sun4m
ncpus probed: 2
ncpus active: 1
CPU0Bogo: 133.12
CPU0ClkTck  : 13300
MMU type: ROSS HyperSparc
contexts: 4096
nocache total   : 2252800
nocache used: 492800

To stress-test dpkg I've just ran 'apt-get install kde' on an unstable 
system. That a pretty big update:


Is your kernel SMP ? Do you use HIGHMEM ?


[..]
0 upgraded, 400 newly installed, 0 to remove and 2 not upgraded.
Need to get 242MB of archives.
After unpacking 678MB of additional disk space will be used.

and it completed without any problems. I also do not recall having any 
problems with dpkg recently. 


What OBP version do you have in these machines?


	I have a 2.25 from Sun in one, a 2.25R from ROSS in another one and a 
2.25W (?) from an HyperSTATION in the third one. Tested modules are 
single and dual RT-626 with a VSIMM (4 and 8MB) and 448 MB. I think it 
is not an hardware trouble because all configurations I have tried 
return exactly the same error. Hardware of the main station I use for 
tests are validated with Solaris9 and without any trouble during several 
days (but I cannot use three or four CPU with Solaris9 without having 
Watchdog reset!, all combinaisons with more than two CPU are not 
stable. Same results on the three stations. If I have time, I shall try 
to install a Solaris 2.7...).


ISTR that to run 
latest HyperSPARC CPUs from Ross you need either 2.25 from Sun, or 
2.25R from Ross. If you are running anything lower, I suggest you try 
to upgrade your firmware, see http://www.sunshack.org/data/bootroms.html

for details.


	Maybe this trouble is related to the trouble I see with two 
SuperSPARC's (Oops in readv_pipe). I don't know...


Regards,

JKB

Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

[BERTRAND Joël]

Guillem Jover a écrit :

Hi,

On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:


Package: dpkg
Version: 1.13.24
Architecture: sparc
Severity: grave




I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
dpkg because it craches with a random error when it tries to configure
the package (it cannot read the configuration script due to a data
corruption. Sometimes, an EOF in the middle of the script...).

I have tested dpkg on three SS20 that perfectly work with SuperSPARC
and with four different HyperSPARC modules, and with and without HIGHMEM.

Results : in all configurations (with and without HIGHMEM), dpkg
crashes with HyperSPARC and works with SuperSPARC. I don't understand
this memory corruption because the workstations work fine in all
configurations I have tested ! Kernels are 2.6.18.x.



Given that this happens when changing the CPU, and that this does not
happen anywhere else, I'd say it's a hw or kernel problem. Also given
the mails[0] in debian-sparc about past state of HyperSparc support I
would say this is not related to dpkg, and the bug would need closing
or to be reassigned. But I've CCed debian-sparc for comments.

[0] http://lists.debian.org/debian-sparc/2006/04/msg3.html
http://lists.debian.org/debian-sparc/2006/04/msg00018.html
http://lists.debian.org/debian-sparc/2006/06/msg00030.html


	I know these mails and I have contributed to the sparc32 smp support 
(and ESP module debug). Today, the ESP works fine (since 2.6.18) and the 
HyperSPARC support seems to works too. Only on trouble with a 2.6.18 
kernel with pipes() :


Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
dereference

Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-context = 5058
Nov 23 14:26:48 hilbert kernel: tsk-{mm,active_mm}-pgd = fc12d000
Nov 23 14:26:48 hilbert kernel:   \|/  \|/
Nov 23 14:26:48 hilbert kernel:   @'/ ,. \`@
Nov 23 14:26:48 hilbert kernel:   /_| \__/ |_\
Nov 23 14:26:48 hilbert kernel:  \__U_/
Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
Nov 23 14:26:48 hilbert kernel: PSR: 40c2 PC: f008bd8c NPC: f008bd90 
Y: Not tainted

Nov 23 14:26:48 hilbert kernel: PC: pipe_readv+0xac/0x440
Nov 23 14:26:48 hilbert kernel: %%G: 1000 fbbfea14  003c 
0030  fbbfea00 73635f6c  f93be000 
Nov 23 14:26:48 hilbert kernel: %%O: f0a0d900 f0a0d900  fcffb000 
63616368  6536345f 70616765  f93bfd88 f008c030

Nov 23 14:26:48 hilbert kernel: RPC: pipe_readv+0x350/0x440
Nov 23 14:26:48 hilbert kernel: %%L:    fbbfea50 
fbbfea00   fcffc000  0001 0001
Nov 23 14:26:48 hilbert kernel: %%I: f93bfe60 0003  f93bfe60 
1800  fcffb000   f93bfe00 f008c140

Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
syscall_is_too_hard+0x3c/0x40

Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98

	But whit bug is very strange, it only occurs with dpkg. It is not a 
material failure because I can see it with all couple off HyperSPARC, 
memory and motherboard. And I cannot see any trace in the logs. All 
daemons, all programs I use work fine on the same station.


Regards,

JKB

Bug#400278: fail2ban does not start with /etc/init.d/fail2ban start but with fail2ban-client start

[BERTRAND Joël]

Yaroslav Halchenko a écrit :

indeed strange... unfortunately it would be impossible for me to try it
myself - no sparc around


I can open a ssh access to one on mine ;-)


could you please boost verbosity in fail2ban.conf (or override it in
fail2ba.local) and then send me along fail2ban.log (if it has anything
in) and output of
sh -x /etc/init.d/fail2ban start


Now, loglevel=4 in /etc/fail2ban/fail2ban.conf
hilbert:/etc/fail2ban# sh -x /etc/init.d/fail2ban  start
+ PATH=/usr/sbin:/usr/bin:/sbin:/bin
+ DESC='authentication failure monitor'
+ NAME=fail2ban
+ DAEMON=/usr/bin/fail2ban-client
+ SOCKFILE=/tmp/fail2ban.sock
+ SCRIPTNAME=/etc/init.d/fail2ban
+ '[' -x /usr/bin/fail2ban-client ']'
+ '[' -r /etc/default/fail2ban ']'
+ . /etc/default/fail2ban
++ FAIL2BAN_OPTS=
+ DAEMON_ARGS=
+ '[' -f /etc/default/rcS ']'
+ . /etc/default/rcS
++ TMPTIME=0
++ SULOGIN=no
++ DELAYLOGIN=no
++ UTC=yes
++ VERBOSE=yes
++ FSCKFIX=no
+ . /lib/lsb/init-functions
++ '[' -e /etc/lsb-base-logging.sh ']'
++ true
+ case $1 in
+ '[' yes '!=' no ']'
+ log_daemon_msg 'Starting authentication failure monitor' fail2ban
+ '[' -z 'Starting authentication failure monitor' ']'
+ '[' -z fail2ban ']'
+ echo -n 'Starting authentication failure monitor: fail2ban'
Starting authentication failure monitor: fail2ban+ do_start
+ do_status
+ /usr/bin/fail2ban-client status
+ case $? in
+ return 0
+ return 1
+ '[' yes '!=' no ']'
+ log_end_msg_wrapper 0 2
+ '[' 0 -lt 2 ']'
+ value=0
+ log_end_msg 0
+ '[' -z 0 ']'
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' FANCYTTY = 0 ']'
+ '[' xxterm '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ FANCYTTY=1
+ true
++ /usr/bin/tput setaf 1
+ RED=''
++ /usr/bin/tput op
+ NORMAL=''
+ '[' 0 -eq 0 ']'
+ echo .
.
+ return 0
+ :
hilbert:/etc/fail2ban# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
hilbert:/etc/fail2ban#

But if I run :

hilbert:/etc/fail2ban# sh -x /etc/init.d/fail2ban reload
+ PATH=/usr/sbin:/usr/bin:/sbin:/bin
+ DESC='authentication failure monitor'
+ NAME=fail2ban
+ DAEMON=/usr/bin/fail2ban-client
+ SOCKFILE=/tmp/fail2ban.sock
+ SCRIPTNAME=/etc/init.d/fail2ban
+ '[' -x /usr/bin/fail2ban-client ']'
+ '[' -r /etc/default/fail2ban ']'
+ . /etc/default/fail2ban
++ FAIL2BAN_OPTS=
+ DAEMON_ARGS=
+ '[' -f /etc/default/rcS ']'
+ . /etc/default/rcS
++ TMPTIME=0
++ SULOGIN=no
++ DELAYLOGIN=no
++ UTC=yes
++ VERBOSE=yes
++ FSCKFIX=no
+ . /lib/lsb/init-functions
++ '[' -e /etc/lsb-base-logging.sh ']'
++ true
+ case $1 in
+ log_daemon_msg 'Reloading authentication failure monitor' fail2ban
+ '[' -z 'Reloading authentication failure monitor' ']'
+ '[' -z fail2ban ']'
+ echo -n 'Reloading authentication failure monitor: fail2ban'
Reloading authentication failure monitor: fail2ban+ do_reload
+ /usr/bin/fail2ban-client reload
+ return 0
+ log_end_msg 0
+ '[' -z 0 ']'
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' FANCYTTY = 0 ']'
+ '[' xxterm '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ FANCYTTY=1
+ true
++ /usr/bin/tput setaf 1
+ RED=''
++ /usr/bin/tput op
+ NORMAL=''
+ '[' 0 -eq 0 ']'
+ echo .
.
+ return 0
+ :
hilbert:/etc/fail2ban# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination
fail2ban-ssh  tcp  --  anywhere anywheretcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT 0--  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain fail2ban-ssh (1 references)
target prot opt source   destination
DROP   0--  webwonderworld.net   anywhere
RETURN 0--  anywhere anywhere
hilbert:/etc/fail2ban#


Thank you!


You're welcome. And if you have any idea...

Regards,

JKB

Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

[BERTRAND Joël]

Package: dpkg
Version: 1.13.24
Architecture: sparc
Severity: grave

Hello,

	I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB of 
memory (thus, HIGHMEM is used). On these workstations, dpkg works fine. 
If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use 
dpkg because it craches with a random error when it tries to configure 
the package (it cannot read the configuration script due to a data 
corruption. Sometimes, an EOF in the middle of the script...).


	I have tested dpkg on three SS20 that perfectly work with SuperSPARC 
and with four different HyperSPARC modules, and with and without HIGHMEM.


	Results : in all configurations (with and without HIGHMEM), dpkg 
crashes with HyperSPARC and works with SuperSPARC. I don't understand 
this memory corruption because the workstations work fine in all 
configurations I have tested ! Kernels are 2.6.18.x.


Any idea ?

Regards,

JKB


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

Bug#400278: fail2ban does not start with /etc/init.d/fail2ban start but with fail2ban-client start

[BERTRAND Joël]

Package: fail2ban
Version: 0.7.4-3

Hello,

	I see a strange 'feature' on a SparcSTATION 20 running debian/testing 
(Linux hilbert 2.6.18.2 #4 SMP Wed Nov 15 17:09:47 CET 2006 sparc 
GNU/Linux).


	fail2ban cannot be launched by /etc/init.d/fail2ban start, but if I try 
to launch fail2ban with fail2ban-client start, it works. I have tried to 
debug the init.d script, but it seems to be good.


On sparc64, i386, amd64, I never see this trouble. Any idea ?

Regards,

JKB



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

Bug#399862: Xorg 7.1 on CG14 (sparc32)

[BERTRAND Joël]

Jurij Smakov a écrit :

On Wed, Nov 22, 2006 at 03:29:09PM +0100, BERTRAND Joël wrote:


Package: xorg
Version: 1:7.1.0-6

Hello,

	I use a SparcSTATION 20 with a CG14 framebuffer (8MB). I used Xorg 
	7.0 without any trouble and I have upgraded Xorg to 7.1 yesterday.
Since this upgrade, I cannot use Xorg. When I try to start Xorg, one of 
my CPU is locked by Xorg process :



Looks like you are hitting bug #394465. As a workaround, try removing 
'unix/:7100' from your font path. The bug is fixed in the svn, and the 
fixed server is going to be uploaded some time this week.


	This morning (2006/11/23), I have downloaded the last xorg package from 
testing release. Same problem, but with your workaround, I can start 
Xorg server.


Thanks,

JKB

Bug#334339: Bug solved (workaround found)

[BERTRAND Joël]

Hello,

	I have tried to build some mysql releases to test. If I build with a 
modified config.h in which I undefine :


HAVE_GETHOSTBYNAME_R and HAVE_GETHOSTBYNAME_R_GLIBC2_STYLE,

mysql client (32 bits) works fine.

Regards,

JKB




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

Bug#399862: Xorg 7.1 on CG14 (sparc32)

[BERTRAND Joël]

Package: xorg
Version: 1:7.1.0-6

Hello,

	I use a SparcSTATION 20 with a CG14 framebuffer (8MB). I used Xorg 7.0 
without any trouble and I have upgraded Xorg to 7.1 yesterday.
Since this upgrade, I cannot use Xorg. When I try to start Xorg, one of 
my CPU is locked by Xorg process :


Tasks:  91 total,   3 running,  88 sleeping,   0 stopped,   0 zombie
Cpu0  : 99.7%us,  0.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu2  : 75.8%us, 22.9%sy,  0.0%ni,  1.3%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st

Mem:445512k total,   381548k used,63964k free,31700k buffers
Swap:   781112k total,0k used,   781112k free,   305392k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  P COMMAND 

 5884 root  25   0 17708 5588 2904 R  100  1.3   2:23.07 0 Xorg 

 6060 bertrand  25   0 10020 4252 2004 R   44  1.0   0:01.39 2 cc1 

 5007 bertrand  16   0  2720 1220  940 R4  0.3   0:52.10 2 top 

 6059 bertrand  20   0  3392  724  636 S2  0.2   0:00.06 2 gcc-4.1 



screen and keyboard are locked (but I can access to this SS20 by ssh).

My xorg.conf:
Section Files
   FontPathunix/:7100# local font server
EndSection
Section InputDevice
Identifier  Generic Keyboard
Driver  keyboard
Option  CoreKeyboard
Option  XkbRules  xfree86
Option  XkbModel  pc102
Option  XkbLayout fr
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  Emulate3Buttons   true
Option  ZAxisMapping  4 5
EndSection

Section Device
Identifier  Carte vidéo générique
Driver  suncg14
#   Driver  suncg6
Option  UseFBDev  true
Option  DPMS  true
EndSection

Section Monitor
Identifier  Écran générique
Option  DPMS
HorizSync   30-65
VertRefresh 50-75
EndSection

Section Screen
Identifier  Default Screen
Device  Carte vidéo générique
Monitor Écran générique
DefaultDepth32
#   DefaultDepth8
SubSection Display
Depth   1
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
SubSection Display
Depth   4
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
SubSection Display
Depth   8
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
SubSection Display
Depth   15
Modes   1280x1024 1280x960 1280x800 
1152x864

SubSection Display
Depth   16
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
SubSection Display
Depth   24
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
SubSection Display
Depth   32
Modes   1280x1024 1280x960 1280x800 
1152x864

EndSubSection
EndSection

Section ServerLayout
Identifier  Default Layout
Screen  Default Screen
InputDevice Generic Keyboard
InputDevice Configured Mouse
EndSection

Section DRI
Mode0666
EndSection

THe obtained /var/log/Xorg.0.log is :

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux hilbert 2.6.18.2 #4 SMP Wed Nov 15 
17:09:47 CET 2006 sparc

Build Date: 07 July 2006
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Wed Nov 22 15:00:04 2006
(==) Using config file: /etc/X11/xorg.conf
(==) ServerLayout Default Layout
(**) |--Screen Default Screen (0)
(**) |   |--Monitor Écran générique
(**) |   |--Device Carte vidéo générique
(**) |--Input Device Generic Keyboard
(**) Option XkbRules xfree86
(**) XKB: rules: xfree86
(**) Option XkbModel pc102
(**) XKB: model: pc102
(**) Option XkbLayout fr
(**) XKB: layout: fr
(==) Keyboard: CustomKeycode disabled
(**) |--Input Device Configured Mouse
(**) FontPath set to:
unix/:7100,
/usr/share/fonts/X11/misc,

Bug#363344: initramfs-tools and HyperSPARC processor

[BERTRAND Joël]

Package: initramfs-tools
Version: 0.59b
Severity: grave
Arch: sparc

It is impossible to build a ramfs image on a HyperSPARC 
workstation. I have try to install etch/sparc on a SS20 that runs with 
four HyperSPARC processors. When it boots, system hangs when it tries to 
load the ramfs image. If I replace HyperSPARC by SuperSPARC-II, I can 
restart the workstation without any trouble. I have tested some 
configurations and some differents sparc32 CPU's. The only combinaison 
that fails is ramfs created by initramfs-tools with HyperSPARC.


Regards,

JKB


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

Bug#363344: initramfs-tools and HyperSPARC processor

[BERTRAND Joël]

maximilian attems a écrit :

severity 363344 important
tags 363344 moreinfo
thanks

cher bertrand,

On Tue, Apr 18, 2006 at 06:04:08PM +0200, BERTRAND Joël wrote:


Package: initramfs-tools
Version: 0.59b
Severity: grave
Arch: sparc



hmm it may be serious, but for now i go for important.
anyway you omitted lots of information.


Yes, I know ;-)

   It is impossible to build a ramfs image on a HyperSPARC 
workstation.


	I have done a mistake... I cannot use a ramfs image (I don't make ramfs 
images to boot my SS20).



please post the error when trying to build the initramfs?


	I cannot post any error because HyperSPARC is not stable enough with 
2.6 kernel. I only use kernels from debian repository or kernel in deb 
package I use for tests : 
http://www.wooyd.org/debian/kernels/linux-image-2.6.16-1-sparc32_2.6.16-6_sparc.deb


I have try to install etch/sparc on a SS20 that runs with 
four HyperSPARC processors. When it boots, system hangs when it tries to 
load the ramfs image.



please post the relevant messages.
are you dropped into a console?


	No. Only a panic message with bad magic number when kernel tries to 
mount ramfs image.


are your devices created? 
If I replace HyperSPARC by SuperSPARC-II, I can 
restart the workstation without any trouble. I have tested some 
configurations and some differents sparc32 CPU's. The only combinaison 
that fails is ramfs created by initramfs-tools with HyperSPARC.


trave11er notified me of some sparc trouble,
but from aboves bug report i have no idea where they could come from.


	For these tests, I have installed two SuperSPARC-II in place of ROSS 
modules. I use a patched kernel (ESP and SMP patches):


hilbert:~# uname -a
Linux hilbert 2.6.17-rc1-patch-smp #4 SMP Tue Apr 18 16:34:12 CEST 2006 
sparc GNU/Linux

hilbert:~# cat /proc/cpuinfo
cpu : Texas Instruments, Inc. - SuperSparc-(II)
fpu : SuperSparc on-chip FPU
promlib : Version 3 Revision 2
prom: 2.25
type: sun4m
ncpus probed: 2
ncpus active: 2
Cpu0Bogo: 75.16
Cpu2Bogo: 75.16
MMU type: TI Viking/MXCC
contexts: 65536
nocache total   : 5242880
nocache used: 1277440
State:
CPU0: online
CPU2: online
hilbert:~#


does fstype work?


No, it does not... fstype is a sparcv9 executable !

hilbert:~# file /usr/lib/klibc/bin/fstype
/usr/lib/klibc/bin/fstype: ELF 64-bit MSB executable, SPARC V9, version 
1 (SYSV), statically linked (uses shared libs), stripped


	Even I kindly ask my SuperSPARC's, I think they cannot understand what 
they have to do...


	When I have installed initramfs-tools, I have installed the following 
packagesl:


- busybox (1.01-4)
- libklibc (1.2.4-1)
- klibc-utils (1.2.4-1)
- libvolume-id0 (0.089-1)
- udev (0.089-1)
- initramfs-tools (0.59b)


please post output of:
/usr/lib/klibc/bin/fstype  /dev/sda1 # please use your real root
cat /proc/cmdline


hilbert:~# cat /proc/cmdline
root=/dev/md1 ro md=1,/dev/sdb4,/dev/sda4


lsmod


hilbert:~# lsmod
Module  Size  Used by
sg 33216  4
sr_mod 16680  0
cdrom  4  1 sr_mod
sunlance   15024  0
openprom8560  0
openpromfs 17840  1
softdog 6644  0
hilbert:~#

Don't forget kernel panics before it starts init.


merci beacoup pour vos explications.
sinon il m'est impossible de savoir ce qui ce passe.

sincèrement


Amicalement,

JKB

Bug#339590: Clamav-milter 0.88-4

[BERTRAND Joël]

Hello,

	The last clamav-milter (0.88-4) is dying too on all my Sparc64 
(U60-smp, U1, U420-smp).


Regards,

JKB


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

Bug#339590: clamav-milter dies after email scanning (sparc64)

[BERTRAND Joël]

Stephen Gran a écrit :

This one time, at band camp, BERTRAND Joël said:


Package: clamav-milter
Version: 0.87.1-1
(debian testing on sparc64)

	I have installed clamav-milter on a UltraSPARC 1E server (with 
	sendmail MTA). Before 0.86 release, it worked fine. With 0.87 and now 
0.87.1, it scans (or starts to scan) the first email given by sendmail and 
it dies without any error message.


	I have the same release of clamav-milter on several i386 servers, 
	and the i386 binaries work fine.


Regards,


Can you debug this a bit?  stack trace, strace, run foreground with debug
turned on, etc?  I'm afraid you haven't given me much to go on.


	 I have tried... I have tried on another workstation (Sun U60-SMP). 
Same result. I have no idea about this trouble.


I have started clamav-milter with :

Root kant:[/var/run/clamav]  clamav-milter --max-children=10 -ol -D 
/var/run/clamav/clamav-milter.ctl


and the so-obtained log output is :
Wed Jan 25 19:47:56 2006 - /tmp/clamav-db6fc9e5561a1f14/msg.7tljy2: OK
Wed Jan 25 19:59:42 2006 - No stats for Database check - forcing reload
Wed Jan 25 19:59:42 2006 - Reading databases from /var/lib/clamav/
Wed Jan 25 19:59:55 2006 - Database correctly reloaded (42505 viruses)
LibClamAV debug: watchdog sleeps
LibClamAV debug: Started: ClamAV version 0.88, clamav-milter version 0.87
LibClamAV debug: watchdog wakes
LibClamAV debug: Stat()ing files in /var/lib/clamav/
LibClamAV debug: Database has not changed
LibClamAV debug: watchdog sleeps
LibClamAV debug: watchdog wakes
LibClamAV debug: Stat()ing files in /var/lib/clamav/
LibClamAV debug: Database has not changed
LibClamAV debug: watchdog sleeps
LibClamAV debug: watchdog wakes
LibClamAV debug: Stat()ing files in /var/lib/clamav/
LibClamAV debug: Database has not changed
LibClamAV debug: watchdog sleeps
LibClamAV debug: clamfi_envfrom: [EMAIL PROTECTED]
LibClamAV debug: n_children = 1
LibClamAV debug: clamfi_abort
LibClamAV debug: clamfi_cleanup
LibClamAV debug: clamfi_free
LibClamAV debug: clamfi_free: n_children = 1
LibClamAV debug: clamav-milter is idle
LibClamAV debug: n_children = 0
LibClamAV debug: clamfi_free returns
LibClamAV debug: clamfi_abort returns
LibClamAV debug: watchdog wakes
LibClamAV debug: Stat()ing files in /var/lib/clamav/
LibClamAV debug: Database has not changed
LibClamAV debug: watchdog sleeps
LibClamAV debug: clamfi_close
LibClamAV debug: clamfi_envfrom: [EMAIL PROTECTED]
LibClamAV debug: n_children = 1
LibClamAV debug: clamfi_envrcpt: [EMAIL PROTECTED]
LibClamAV debug: Saving message to 
/tmp/clamav-34e7138aca68c17c/msg.SydMv9 to scan later

LibClamAV debug: connect2clamd: serverNumber = 0
LibClamAV debug: isWhitelisted [EMAIL PROTECTED]
LibClamAV debug: clamfi_eom
LibClamAV debug: Recognized Raw mail file
LibClamAV debug: Starting cli_scanmail(), mrec == 1, arec == 0
LibClamAV debug: in mbox()
LibClamAV debug: parseEmailFile
LibClamAV debug: parseEmailFile: check 'Received: by clamav-milter' 
contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'From: 
[EMAIL PROTECTED]' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'To: [EMAIL PROTECTED]' 
contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'Received: from bohr.systella.fr 
(bohr.systella.fr [213.41.140.153])' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'by rayleigh.systella.fr 
(8.13.5/8.13.5/Debian-3) with ESMTP id k0PJSYr7027661' contMarker 0 
fullline 0x(nil)
LibClamAV debug: parseEmailFile: check '(version=TLSv1/SSLv3 
cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)' contMarker 0 fullline 
0x(nil)
LibClamAV debug: parseEmailFile: check 'for [EMAIL PROTECTED]; 
Wed, 25

Jan 2006 20:28:35 +0100' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'Received: from bohr.systella.fr 
(localhost [127.0.0.1])' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'by bohr.systella.fr 
(8.13.5/8.13.5/Debian-3) with ESMTP id k0PJSVn7004911' contMarker 0 
fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'for [EMAIL PROTECTED]; 
Wed, 25 Jan 2006 20:28:31 +0100' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'Received: (from 
[EMAIL PROTECTED])' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'by bohr.systella.fr 
(8.13.5/8.13.5/Submit) id k0PJSV6x004908' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'for [EMAIL PROTECTED]; 
Wed, 25 Jan 2006 20:28:31 +0100' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'Date: Wed, 25 Jan 2006 20:28:31 
+0100' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'From: BERTRAND Joël 
[EMAIL PROTECTED]' contMarker 0 fullline 0x(nil)
LibClamAV debug: parseEmailFile: check 'Message-Id: 
[EMAIL PROTECTED]' contMarker 0 fullline 
0x(nil)
LibClamAV debug: parseEmailFile: check 'To: [EMAIL PROTECTED]' contMarker 
0 fullline 0x(nil

Bug#334339: Good news

[BERTRAND Joël]

Hello,

I have rebuilt clamav 0.87.1 from sources :
Root kant:[~/clamav/clamav-0.87.1]  ./configure --prefix=/usr/local 
--enable-milter --disable-clamav --enable-debug

and it works now. I use gcc 4.0.2.

Regards,

JKB


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

Bug#334339: News from mysql.com

[BERTRAND Joël]

Christian Hammers a écrit :

Hello Joel


Hello Christian,


On 2005-10-25 BERTRAND Joël wrote:


I have received from mysql.com :

This is not first time that we see 32-bit calls failing on 64-bit 
system. But you can check it out by manually changing config.h, 
specifically:


#define HAVE_GETHOSTBYNAME_R 1
#define HAVE_GETHOSTBYNAME_R_GLIBC2_STYLE 1

Try undefining both and re-run complete make.

I shall try.



Did you try? Any news?


	I have tried with the official sources (mysql-4.1.15) that come from 
www.mysql.com web page.


if g++ -DMYSQL_SERVER 
-DDEFAULT_MYSQL_HOME=\/export/home/bertrand/mysql\ 
-DDATADIR=\/export/home/bertrand/mysql/var\ 
-DSHAREDIR=\/export/home/bertrand/mysql/share/mysql\ -DHAVE_CONFIG_H 
-I. -I. -I.. -I../innobase/include -I../include -I../include -I../regex 
-I. -O3 -DDBUG_OFF-fno-implicit-templates -fno-exceptions 
-fno-rtti -MT sql_analyse.o -MD -MP -MF .deps/sql_analyse.Tpo -c -o 
sql_analyse.o sql_analyse.cc; \
then mv -f .deps/sql_analyse.Tpo .deps/sql_analyse.Po; else rm -f 
.deps/sql_analyse.Tpo; exit 1; fi

sql_analyse.cc: In member function 'virtual void field_longlong::add()':
sql_analyse.cc:506: internal compiler error: in invert_exp_1, at jump.c:1719
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.0/README.Bugs.
make[4]: *** [sql_analyse.o] Erreur 1
make[4]: quittant le répertoire « 
/export/home/bertrand/mysql/mysql-4.1.15/sql »

make[3]: *** [all-recursive] Erreur 1
make[3]: quittant le répertoire « 
/export/home/bertrand/mysql/mysql-4.1.15/sql »

make[2]: *** [all] Erreur 2
make[2]: quittant le répertoire « 
/export/home/bertrand/mysql/mysql-4.1.15/sql »

make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /export/home/bertrand/mysql/mysql-4.1.15 »
make: *** [all] Erreur 2
kant:[~/mysql/mysql-4.1.15] 

	This bug comes from g++-4.0. I have compiled this source with g++-3.3. 
I have tried to connect to my server and the connection can be established :


kant:[~/mysql/mysql-4.1.15/client]  ./mysql -uroot -p -halain
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 103 to server version: 4.1.14-Debian_6-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql

Best regards,

JKB

Bug#339590: clamav-milter dies after email scanning (sparc64)

[BERTRAND Joël]

Package: clamav-milter
Version: 0.87.1-1
(debian testing on sparc64)

	I have installed clamav-milter on a UltraSPARC 1E server (with sendmail 
MTA). Before 0.86 release, it worked fine. With 0.87 and now 0.87.1, it 
scans (or starts to scan) the first email given by sendmail and it dies 
without any error message.


	I have the same release of clamav-milter on several i386 servers, and 
the i386 binaries work fine.


Regards,

JKB


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

Bug#334339: News from mysql.com

[BERTRAND Joël]

Hello,

I have received from mysql.com :

This is not first time that we see 32-bit calls failing on 64-bit 
system. But you can check it out by manually changing config.h, 
specifically:


#define HAVE_GETHOSTBYNAME_R 1
#define HAVE_GETHOSTBYNAME_R_GLIBC2_STYLE 1

Try undefining both and re-run complete make.

I shall try.

Regards,

JKB
--
Dr. BERTRAND Joël
SYSTELLA S.A.R.L., La Sudrie 19130 VIGNOLS, FRANCE
Tél.: +33 (0)6 16 01 80 60
http://www.systella.fr

Bug#334339: mysql-client: Unable to connect a i386-mysql server from an UltraSPARC client (bus error)

[BERTRAND Joël]

Package: mysql-client
Version: 4.1.14-6
Severity: important


Hello,

I have upgraded two workstations the last sunday. All stations
run Debian/Testing.

The first one is an UltraSPARC 1E (sun4u with 2.6.10 official
linux kernel patched with iptables ROUTE target). The second one
is an official debian system (debian kernel 2.6.8) on i386
(Pentium IV).

I have installed a mysql server on i386 and sparc64.

If I work on the sparc64, I can access to the local mysql
server. From the i386, I can locally use the mysql server.
From a external i386, I can reach the both mysql server. But,
if I try to access to the i386 mysql server from the Sparc64
workstation, mysql client returns a bus error.

strace returns:

open(/etc/host.conf, O_RDONLY)= 4
fstat64(4, {st_dev=makedev(8, 1), st_ino=32620, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=8192, st_blocks=8,
st_size=26, st_atime=2005/10/17-11:55:38, st_mtime=1995/09/26-05:20:44,
st_ctime=2003/12/14-13:31:48}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7001c000
read(4, order hosts,bind\nmulti on\n, 8192) = 26
read(4, , 8192)   = 0
close(4)= 0
munmap(0x7001c000, 8192)= 0
open(/etc/hosts, O_RDONLY)= 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_dev=makedev(8, 1), st_ino=32710, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=8192, st_blocks=8,
st_size=407, st_atime=2005/10/17-11:55:38, st_mtime=2005/10/17-09:45:58,
st_ctime=2005/10/17-09:45:59}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7001c000
read(4, 127.0.0.1\tlocalhost\n192.168.254, 8192) = 407
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
kant:[~]  

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: sparc (sparc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages mysql-client depends on:
ii  mysql-client-4.1  4.1.14-6   mysql database client binaries

mysql-client recommends no packages.

-- no debconf information


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

Bug#334339: mysql-client: Unable to connect a i386-mysql server from an UltraSPARC client (bus error)

[BERTRAND Joël]

Christian Hammers a écrit :

Hello

On 2005-10-17 BERTRAND Joël wrote:


If I work on the sparc64, I can access to the local mysql
server. From the i386, I can locally use the mysql server.
From a external i386, I can reach the both mysql server. But,
if I try to access to the i386 mysql server from the Sparc64
workstation, mysql client returns a bus error.

strace returns:


Please give me some more debugging information:


Of course. All informations come from the Sparc64 workstation.


 cat /etc/host.conf


Root kant:[~]  cat /etc/host.conf
order hosts,bind
multi on


 cat /etc/hosts


Root kant:[~]  cat /etc/hosts
127.0.0.1   localhost
192.168.254.1   kant.astelys.fr kant

# Comment réparer les conneries de Monsieur Free !
82.229.72.155   deu95-1-82-229-72-155.fbx.proxad.net

# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


 ldd /usr/bin/mysql


Root kant:[~]  ldd /usr/bin/mysql
libreadline.so.5 = /lib/libreadline.so.5 (0x7003)
libncurses.so.5 = /lib/libncurses.so.5 (0x70074000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x700d)
libmysqlclient.so.14 = /usr/lib/libmysqlclient.so.14 (0x701b8000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x702e8000)
libnsl.so.1 = /lib/libnsl.so.1 (0x70328000)
libz.so.1 = /usr/lib/libz.so.1 (0x7035)
libm.so.6 = /lib/libm.so.6 (0x70374000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x70408000)
libc.so.6 = /lib/libc.so.6 (0x70424000)
libdl.so.2 = /lib/libdl.so.2 (0x7055c000)
/lib/ld-linux.so.2 (0x7000)


 host name of i386 host


Root kant:[~]  host alain
alain.astelys.fr has address 192.168.0.130


 ltrace output instead of strace output


	There is no ltrace on debian/sparc. I have downloaded the tarball and 
built ltrace (with link from sparc to sparc64 in 
~/ltrace-0.3.36/sysdeps/linux-gnu). I hope my ltrace is a regular ltrace...


Root kant:[~/ltrace-0.3.36]  ./ltrace mysql -uroot -p -halain
__libc_start_main(104328, 4, 0xedc4, 113424, 113544 unfinished ...
_init(0, 0, 0, 0, 0 unfinished ...
... __libc_start_main resumed )= 0x7002ccb0
__cxa_atexit(93436, 0, 192928, 0, 0) = 0
__cxa_atexit(93372, 0, 192928, 0, 0) = 0
__cxa_atexit(91020, 0, 192928, 0x7002ce64, 0)= 0
get_defaults_files(4, 0xedc4, 0xecf4, 0xecf0, 0) = 4
my_init(4, 0xedc4, 0xecf4, 0xecf0, 0) = 0
getenv(124928, 0xedc4, 0xecf4, 0xecf0, 0) = 0
my_strdup(124944, 16, 0xecf4, 0xecf0, 0) = 221264
my_strdup(221264, 16, 0xecf4, 0xecf0, 0) = 221280
getenv(124952, 8, 0xecf4, 0xecf0, 0) = 0
isatty(0, 8, 0xecf4, 0xecf0, 0)  = 1
isatty(1, 8, 0xecf4, 0xecf0, 0)  = 1
load_defaults(120552, 193784, 0xed44, 0xed48, 0) = 0
mysql_get_parameters(0, 221832, 0xed44, 0xed48, 0) = 0x7020dc6c
getenv(124960, 221832, 0xed44, 0xed48, 0) = 0
getenv(124952, 221832, 0xed44, 0xed48, 0) = 0
strcpy(207728, 203584, 0xed44, 0xed48, 0) = 207728
handle_options(0xece8, 0xecec, 193800, 81648, 0x7472feff) = 0
strcmp(114008, 0x701f9ac0, 676, 2800, 206848)= 0
get_tty_password(0, 0x701f9ac8, 0x1010101, 0x80808080, 0x6e31Enter 
password:

) = 221512
mysql_server_init(1, 0xecdc, 198088, 0x80808080, 0x6e31) = 0
my_malloc(520, 16, 0, 0, 0)  = 225136
breakpointed at 0x2ec74 (?)
my_malloc(12, 48, 0, 0, 0)   = 221616
init_alloc_root(199440, 8192, 0, 0, 0)   = 199440
init_alloc_root(199400, 16384, 0, 0x80808080, 0x6e31) = 199400
memset(198344, 0, 952, 0x80808080, 0x6e31)   = 198344
mysql_init(198344, 0, 0, 0, 0)   = 198344
mysql_real_connect(198344, 221368, 221352, 221512, 0 unfinished ...
--- SIGBUS (Bus error) ---
+++ killed by SIGBUS +++
Root kant:[~/ltrace-0.3.36] 

Regards,

JKB

Bug#334339: mysql-client: Unable to connect a i386-mysql server from an UltraSPARC client (bus error)

[BERTRAND Joël]

Christian Hammers a écrit :

forwarded 334339 http://bugs.mysql.com/bug.php?id=14080
tags 334339 + upstream
thanks


Hello

I forwarded the bug to MySQL as I don't know how to help here.

bye,

-christian-


	Thank you. I have seen. Some new informations required by the support 
of mysql:


Root kant:[/usr/lib]  file libmysqlclient.so.14.0.0
libmysqlclient.so.14.0.0: ELF 32-bit MSB shared object, SPARC, version 1 
(SYSV), stripped

Root kant:[/usr/lib]  uname -a
Linux kant 2.6.10 #6 Mon Feb 21 14:56:15 CET 2005 sparc64 GNU/Linux

I have launched gdb on the so-obtained core:

Root kant:[/usr/lib]  gdb /usr/bin/mysql core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as sparc-linux...(no debugging symbols found)
Using host libthread_db library /lib/libthread_db.so.1.

Core was generated by `mysql -uroot -p -halain'.
Program terminated with signal 10, Bus error.
Reading symbols from /lib/libreadline.so.5...(no debugging symbols 
found)...done.

Loaded symbols for /lib/libreadline.so.5
Reading symbols from /lib/libncurses.so.5...(no debugging symbols 
found)...done.

Loaded symbols for /lib/libncurses.so.5
Reading symbols from /usr/lib/libstdc++.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /usr/lib/libmysqlclient.so.14...(no debugging 
symbols found)...done.

Loaded symbols for /usr/lib/libmysqlclient.so.14
Reading symbols from /lib/libcrypt.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols 
found)...done.

Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x705779cc in _nss_files_endhostent ()
   from /lib/libnss_files.so.2
(gdb) bt
#0  0x705779cc in _nss_files_endhostent () from /lib/libnss_files.so.2
#1  0x70577fcc in _nss_files_gethostbyname_r () from /lib/libnss_files.so.2
#2  0x70500274 in gethostbyname_r () from /lib/libc.so.6
#3  0x701db898 in my_gethostbyname_r () from /usr/lib/libmysqlclient.so.14
#4  0x701f3c8c in mysql_real_connect () from /usr/lib/libmysqlclient.so.14
#5  0x00015068 in mysql_store_result_for_lazy ()
#6  0x00019b04 in main ()
(gdb)

Regards,

JKB