Bug#1012016: file size comparison

[Erik Thiele]

as already reported, the filesize of poi-ooxml-schemas-4.0.1.jar is
obviously a problem:


Debian GNU/Linux 10 (buster):
libapache-poi-java 4.0.1-1
root@xxx:/usr/share/java# 
-rw-r--r-- 1 root root 1757334 Jan 21  2019 poi-ooxml-4.0.1.jar
-rw-r--r-- 1 root root 7855345 Jan 21  2019 poi-ooxml-schemas-4.0.1.jar


Debian GNU/Linux 12 (bookworm):
libapache-poi-java 4.0.1-4
root@yyy:/usr/share/java#
-rw-r--r-- 1 root root 1757319 16. Mai 2022 poi-ooxml-4.0.1.jar
-rw-r--r-- 1 root root   99850 16. Mai 2022 poi-ooxml-schemas-4.0.1.jar



for a workaround, i have replaced these two files by their old
versions. I also had to replace xmlbeans-4.0.0 by xmlbeans-3.0.2. Then
it worked.

this means it is not enough to replace poi-ooxml-schemas-4.0.1 but also
poi-ooxml-4.0.1 and xmlbeans... maybe this helps anybody - at least to
work around.


cu
Erik

Bug#1012016: apache poi XSSFWorkbook complete fail

[Erik Thiele]

when upgrading to debian bookworm I found a problem that is probably
related to this bugreport here and I got no idea on how to workaround.
I created this minimal testcase:

cat >problem.java <(XSSFWorkbook.java:263)
at 
org.apache.poi.xssf.usermodel.XSSFWorkbook.(XSSFWorkbook.java:257)
at 
org.apache.poi.xssf.usermodel.XSSFWorkbook.(XSSFWorkbook.java:245)
at problem.main(problem.java:6)
Caused by: java.lang.ClassNotFoundException: 
org.apache.xmlbeans.metadata.system.s036263A03D2D3FD117889707DB51207A.TypeSystemHolder
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
... 7 more



it does not reach debugpoint 3.

does anybody know how I can workaround here?
The complete XSSFWorkbook system in apachepoi is not working.


cu
Erik

Bug#1051667: wrong hour in timestamp. random variations.

[Erik Thiele]

Package: zsync
Version: 0.6.2-5


on a client host do:

echo hello > original.txt
zsyncmake original.txt 
copy original.txt and original.txt.zsync to webserver

on the webserver:
ls -l original.txt*
-rw-r--r-- 1 root root   6 Sep 11 08:14 original.txt
-rw-r--r-- 1 root root 193 Sep 11 08:14 original.txt.zsync
(see the hour of the timestamp being 08)

now on client in a new empty directory:

zsync http://www/original.txt.zsync
ls -l
-rw--- 1 root root 6 11. Sep 07:14 original.txt
(see the hour of the timestamp is 07 and not 08)

rm original.txt
zsync http://www/original.txt.zsync
ls -l
-rw--- 1 root root 6 11. Sep 06:14 original.txt
(see the hour of the timestamp is 06 and not 08)

if you repeat again and again, the hour will be 07 or 06 at random!
very strange. by the way, 08 would be the correct number, but that one
is never chosen.

my webserver is debian 10 buster, apache2.

but the client is debian 12 bookworm

cat /etc/timezone on both client and webserver is
Europe/Berlin




Best Regards,
Erik Thiele

Bug#1024707: aa-disable fails if HOMEDIRS is used as tunable

[Erik Thiele]

Package: apparmor-utils
Version: 2.13.2-10

# cat /etc/debian_version 
10.13

# cat /etc/apparmor.d/tunables/home.d/yyy
@{HOMEDIRS}+=/home/global/


systemctl reload apparmor
# works as expected and also enables the modified HOMEDIRS stuff.


# aa-disable usr.bin.thunderbird
ERROR: Values added to a non-existing variable
@{HOMEDIRS}: /home/global/ in tunables/home.d/yyy

and it will not disable the profile.
aa-enforce also won't work.

it seems like the normal apparmor system works with HOMEDIRS correctly
but the apparmor-utils don't.

this may be linked to
https://bugs.launchpad.net/apparmor/+bug/1331856



cya
Erik

Bug#1004951: Not displaying attachments that contain a slash (/) in their name

[Erik Thiele]

Package: thunderbird
Version: 1:91.5.0-2~deb10u1

Thunderbird is not displaying attachments that contain a slash (/) in
their name. There is also no error message.


Steps to reproduce:

- Open thunderbird to send yourself an email with an attachment, for
  example a PDF file. it is called "doc.pdf" in this example here.

- Click on the received email. Click on the attachment and see that it
  correctly opens.

- Now right click on the received mail in the mail list and do "save
  as". save the email with filename "working.eml"

- quit thunderbird.

- in a shell go in the directory where working.eml is saved and do:
  thunderbird working.eml
  You will see thunderbird starting, opening the mail. click on the
  attachment and see it opens.
  quit thundebird again.

- copy working.eml to not_working.eml
  open a text editor on not_working.eml

now search for this:

Content-Type: application/pdf; name="doc.pdf"
Content-Disposition: attachment; filename="doc.pdf"
Content-Transfer-Encoding: base64

add slashes at the same position in both filenames like this:

Content-Type: application/pdf; name="do/c.pdf"
Content-Disposition: attachment; filename="do/c.pdf"
Content-Transfer-Encoding: base64

save the file.

- now do
  thunderbird not_working.eml
  the email opens, you see the attachment named "do/c.pdf"
  you can click the attachment, but nothing opens.
  no error message, just nothing happens.
  but you can right click the attachment and save it.
  notice that thunderbird wants to save with "do-c.pdf", so it replaced
  the slash (/) by a minus (-).
  you can check that the saved file correctly matches the original file.

As you see something is wrong when receiving attachments that contain a
slash (/) in their name.

When you investigate thunderbird with strace like this:

strace - thunderbird working.eml 2>strace_working.txt
then click on the attachment and quit thunderbird

then do

strace - thunderbird not_working.eml 2>strace_not_working.txt
then click on the attachment and quit thunderbird

then do:
grep pdf strace_working.txt |grep open
you will see:
[pid 17250] openat(AT_FDCWD, "/tmp/doc.pdf", O_WRONLY|O_CREAT...

compare this to:
grep pdf strace_not_working.txt |grep open
you will see no try of even saving the attachment.




The way I created the not-working email with a text editor may seem
the source of the problem, but it isn't. I regularly get emails with
slashes in attachment names. I simply did not find a way to create such
an email with commandline tools. All seem to dislike slashes in
attachment names. But since I am regularly receiving this kind of
emails in real life, there must be some (non-unix?) mail program
creating such (bad) attachments.




cu
Erik

Bug#987722: Segmentation fault at address 0x0 in 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5645ba71bb39]

[Erik Thiele]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1

lspci sais:
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev 
a2)


sometimes after some days, but again and again the Xserver crashes.
this is seen in the Xorg.log:

[627670.969] (EE) 
[627670.989] (EE) Backtrace:
[627671.046] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5645ba71bb39]
[627671.047] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7ff8193d877f]
[627671.242] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x250ae0) [0x7ff817b6bff0]
[627671.243] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x27239a) [0x7ff817bafe4a]
[627671.245] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x35f1e3) [0x7ff817d89d43]
[627671.246] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x27384f) [0x7ff817bb26bf]
[627671.247] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x273c62) [0x7ff817bb3312]
[627671.260] (EE) 7: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0x10619) [0x7ff8183cee39]
[627671.262] (EE) 8: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0xc9dc) [0x7ff8183c75ec]
[627671.263] (EE) 9: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0xccb7) [0x7ff8183c7d47]
[627671.263] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_finish+0xcf4) [0x7ff8183adca4]
[627671.264] (EE) 11: /usr/lib/xorg/Xorg (miCopyRegion+0x96) [0x5645ba6f9586]
[627671.264] (EE) 12: /usr/lib/xorg/Xorg (miDoCopy+0x476) [0x5645ba6f9c76]
[627671.265] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_finish+0x1870) [0x7ff8183af430]
[627671.266] (EE) 14: /usr/lib/xorg/Xorg (DamageRegionAppend+0x3726) 
[0x5645ba6a3846]
[627671.266] (EE) 15: /usr/lib/xorg/Xorg (SendGraphicsExpose+0x4ff) 
[0x5645ba5b8a9f]
[627671.267] (EE) 16: /usr/lib/xorg/Xorg (SendErrorToClient+0x35e) 
[0x5645ba5bc9fe]
[627671.267] (EE) 17: /usr/lib/xorg/Xorg (InitFonts+0x3b6) [0x5645ba5c09c6]
[627671.268] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) 
[0x7ff81922709b]
[627671.268] (EE) 19: /usr/lib/xorg/Xorg (_start+0x2a) [0x5645ba5aa67a]
[627671.268] (EE) 
[627671.268] (EE) Segmentation fault at address 0x0
[627671.268] (EE) 
Fatal server error:
[627671.269] (EE) Caught signal 11 (Segmentation fault). Server aborting
[627671.269] (EE) 
[627671.277] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[627671.277] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[627671.277] (EE) 
[627671.278] (II) AIGLX: Suspending AIGLX clients for VT switch
[627671.319] (EE) Server terminated with error (1). Closing log file.



cu
erik

Bug#939542: I made a typo.

[Erik Thiele]

sorry, in my original mail you read:

aduser@seclag:~$ export =/tmp/krb5cc_30100
# 30100 is the uid of user "user2"

correct would be:

aduser@seclag:~$ export KRB5CCNAME=/tmp/krb5cc_30100
# 30100 is the uid of user "user2"

Bug#939542: denial of service and possible other security implications by giving wrong kerberos ticket cache file to other users.

[Erik Thiele]

Package: libpam-winbind
Version: 2:4.5.16+dfsg-1+deb9u2
Severity: important

I am using a samba 4 as active directory domain controller in a basic
configuration as defined in the official samba 4 wiki. I added two
users:

root@seclag:/etc# id aduser
uid=30106(aduser) gid=30099(domain users) Gruppen=30099(domain
users),70002(BUILTIN\users)

root@seclag:/etc# id user2
uid=30100(user2) gid=30099(domain users) Gruppen=30099(domain
users),70002(BUILTIN\users)

the only computer added to the active directory is the linux machine
"seclag". It uses a basic libpam-winbind based configuration without
any changes to the default pam stack configuration. using
libpam-winbind is suggested by the official samba4 wiki.

in /etc/pam.d/common-auth we find:
auth[success=1 default=ignore]  pam_winbind.so krb5_auth
krb5_ccache_type=FILE cached_login try_first_pass

this pam line is responsible for creating the file /tmp/krb5cc_30100 if
the user "user2" with uid 30100 is logging in on the console. this can
be shown by replacing krb5_ccache_type=FILE above with
krb5_ccache_type=FILE:/tmp/mydebug_%u because if you do so, the system
is creating /tmp/mydebug_30100 instead.

see:

user2@seclag:~$ klist
Ticket cache: FILE:/tmp/mydebug_30100  <-- here!
Default principal: us...@xx.mydomain.de

let's revert back to using the normal /tmp/krb5cc_* system as is
configured by default. the example above was just to show that
pam_winbind is responsible for creating the problematic situation shown
in the following:

let's login as user "adtest" with uid 30106:

aduser@seclag:~$ klist
Ticket cache: FILE:/tmp/krb5cc_30106
Default principal: adu...@xx.mydomain.de

see, the default principal is just fine. we have the right kerberos key
installed. now let's create a fake ticket cache for user2:

aduser@seclag:~$ export =/tmp/krb5cc_30100
# 30100 is the uid of user "user2"

aduser@seclag:~$ kinit aduser  
Password for adu...@xx.mydomain.de: 
aduser@seclag:~$ klist
Ticket cache: FILE:/tmp/krb5cc_30100
Default principal: adu...@xx.mydomain.de

ok we now created a new ticket cache with our key inside. all right.
now logout and login as user "user2":

user2@seclag:~$ klist
klist: Credentials cache permissions incorrect
(filename: /tmp/krb5cc_30100)

ok so user "aduser" created a denial of service situation for user
"user2"! let's see if we can do more bad things. log in as user
"aduser" again:

aduser@seclag:~$ chmod 666 /tmp/krb5cc_30100 

now try again as user "user2":

user2@seclag:~$ klist
Ticket cache: FILE:/tmp/krb5cc_30100
Default principal: adu...@xx.mydomain.de

 see? user "user2" now has the kerberos key of user "aduser"
installed. The system is silently taking the keys someone else has
installed!

I am not quite sure how to fix this correctly, but:

pam_winbind certainly must not simply take an existing file which is
owned by an other user! it must instead remove that file and create it
correctly (but take care of race conditions!). the other alternative
would be to just fail, but then a user can deny service of other users
simply by creating /tmp/krb5cc_UID_OF_OTHER_USER. so the correct
solution is to remove that file and create it correctly. thereby
correctly taking care of possible symlink attacks and other bad stuff.
removing the file may be complicated if another user created a
directory with that name.

I am unsure what kind of bad things can be done due to this bug. but on
our site every user can do a denial of service against all other system
users (which have not logged on since cleaning of /tmp) with this
command:

for a in $(seq 3 30200); do touch /tmp/krb5cc_$a; done

denial of service is only relevant to kerberos. thus if a user does a
kerberized cifs mount then it will not work. the other parts of the
system which do not depend on a valid kerberos ticket will work of
course.

an alternative would be to specify KEYRING as krb5_ccache_type but I
can't get it to work. cat /proc/keys always stays empty. no matter if i
use KEYRING or FILE. but in the KEYRING case, klist still
uses /tmp/krb5cc_30100 because the environment variable KRB5CCNAME is
unset for some reason when using KEYRING. i think the KEYRING
implementation in pam_winbind is broken?

cya
erik

Bug#923567: strong vote against deleting cluster on package purge

[Erik Thiele]

Package: postgresql
Version: 9.6+181+deb9u2

I am creating this bugreport because of a mishap that now has happened
twice to me and I think it does not actually have to happen and maybe
the behavior of the package should be changed.

1) At home I once tried a document management system for my private
home paper work. It worked great until I did a debian upgrade of the
server. Everything worked fine and I also --purge all removed
packages. Then all of sudden the database was gone. After noticing that
I should not have --purge the old version of postgresql I found out
that I had no backups. Since then I work with paper again. Of course it
is my fault, but ...

2) Yesterday at work I did a massive upgrade of all kinds of virtual
machines at the same time. A lot of different services like mail,
fileserver, etc. So again I ran into the pitfall that purging old
packages deletes my postgresql cluster. Of course I have backups but
the work of one day is lost and all employees are very happy of course.
Yes I know it is my fault, but ...


Here are the arguments I have against cleaning up the actual cluster
files when --purge postgresql

a) Compare postgresql to samba or nfs-kernel-server. When purging these
packages, the files on the filesystem which the server was serving will
certainly not be removed. But on postgresql they are.

b) What is worse? Having files not owned by a corresponding package
in /var/lib/postgresql or losing a complete database on system upgrade?

c) Compare this to for example ruby gems. When doing gem install xxx as
root, you will get files in /var/lib/gems/version/... Now when
upgrading the system you will get a new ruby version and when
installing gems, a new version directory will be built. The old one
just stays there and nobody ever deletes it. Especially not the old
ruby packages when you --purge them.



I am sure I am not the only one who fell in this --purge trap. To say
it again, of course it is my own fault, but still I think that the
package should not delete the cluster on --purge. Please rethink that
decision.



Thanks
Erik

Bug#913553: debian-security Translation-en 500 fail to download

[Erik Thiele]

Package: apt-cacher-ng
Version: 2-2

Without changing anything at the configuration for the last half year
or so I detected that debian-security downloading does not work anymore
with apt-cacher-ng.

my configuration is:

internet -> squid -> apt-cacher-ng -> apt-get

(yes apt-cacher-ng is downloading via squid, not internet direct)

for testing I use the machine which runs the squid and the
apt-cacher-ng and there on this machine i do local apt-get to reduce
problem complexity, but with other networked machines the results are
the same. This is how i test:

systemctl stop apt-cacher-ng.service
cd /var/lib/apt/lists
rm -rf *
cd /var/cache/apt-cacher-ng
rm -rf *
cat /etc/apt/apt.conf.d/99yyyProxy
Acquire::http::Proxy "http://localhost:3142;;  # this is apt-cacher-ng
systemctl start apt-cacher-ng.service
LANG=C apt-get update
--> lots of output. only the relevant part is shown:

Err:8 http://security.debian.org/debian-security stretch/updates/main
Translation-en 500  Invalid header

E: Failed to fetch
http://security.debian.org/debian-security/dists/stretch/updates/main/i18n/Translation-en
500  Invalid header

E: Some index files failed to download. They have
been ignored, or old ones used instead.

OK so now i do the exact same thing again but replace the port number
3142 by 3128 which is my squid port.

and now it works without any problems.

I do not know how to debug. what i know, is that the above URL

http://security.debian.org/debian-security/dists/stretch/updates/main/i18n/Translation-en

does not exist. if you download instead:

http://security.debian.org/debian-security/dists/stretch/updates/main/i18n/Translation-en.bz2

then it works.

maybe the problem is somewhat related to that.

as a quick fix I switched my complete server farms and client pools
back to direct squid and deactivated apt-cacher-ng. But of course that
is not really a fix :-)


cya

Erik

-- 
Erik Thiele

Bug#906795: vlc does also not work with same error message

[Erik Thiele]

vlc film.mp4
VLC media player 3.0.3 Vetinari (revision 3.0.3-1-0-gc2bb759264)
[55d8f3d4b1d0] main libvlc: Running vlc with the default interface.
 Use 'cvlc' to use vlc without interface. Gdk-Message: vlc: Fatal IO
 error 2 (No such file or directory) on X server :50.

I got no idea how to debug this. any ideas?

when doing the same with 'ssh -X', it works fine.

Bug#895498: openvpn fails permanently because it is started too early on system boot and network interface is not (completely) up

[Erik Thiele]

Package: openvpn
Version: 2.4.0-6+deb9u2

when booting the system, systemctl shows openvpn as failed. in the
openvpn logs I find:

TCP/UDP: Socket bind failed on local address
[AF_INET]192.168.90.1:1194: Cannot assign requested address

but in /etc/network/interfaces I have:

auto jacktrunk.13
iface jacktrunk.13 inet static
  address 192.168.90.1
  netmask 255.255.255.0

when restarting openvpn via sysctl restart, everything works fine. So
the network interface is not yet up when openvpn tries to bind to it.
As a workaround I patched:

/lib/systemd/system# diff -u openvpn\@.service~ openvpn\@.service
--- openvpn@.service~   2017-07-18 22:15:17.0 +0200
+++ openvpn@.service2018-04-11 17:39:37.759664731 +0200
@@ -20,6 +20,9 @@
 LimitNPROC=10
 DeviceAllow=/dev/null rw
 DeviceAllow=/dev/net/tun rw
+Restart=on-failure
+RestartSec=10
 
 [Install]
 WantedBy=multi-user.target

Now when rebooting everything works. Checking the logs I find, that the
first try fails as above, and then 10 seconds later the startup is
retried and everything works fine.

I know this is a hack. But maybe it is not possible to arrange systemd
to to the correct ordering in all use cases and a retry every 10 seconds
could be a more robust solution. Dunno.


Best Regards
Erik

Bug#839897: debugging info

[Erik Thiele]

hi

I managed to debug:

#apt-get source rdesktop
#cd rdesktop-1.8.3
#debuild -b -uc -us

then simply run the ./rdesktop binary in that directory.
in order to debug I did 

#./configure --prefix=/home/global/erik/localinst/rdesktop
 --with-debug  --with-debug-kbd   --with-debug-rdp5
 --with-debug-clipboard  --with-debug-sound  --with-debug-channel
 --with-debug-seamless--with-debug-smartcard   --with-debug-credssp

# make clean
# make

then run ./rdesktop in kdbg to find the segmentation fault at this
line in ssl.c:

algor = X509_PUBKEY_get0_param(NULL, NULL, 0, , key);

according to the documentation that is wrong because the return value
is 0 or 1 depending of if the function worked or made error. the return
value is NOT a pointer! the compiler also issues a warning here:

ssl.c: In function ‘rdssl_cert_to_rkey’:
ssl.c:154:8: warning: assignment makes pointer from integer without a
cast [-Wint-conversion] algor = X509_PUBKEY_get0_param(NULL, NULL, 0,
, key); ^

also see that algor is passed as a pointer in order for the function to
manipulate it. it is completely wrong to assign algor from the return
value!

so i replaced the code by this:
DEBUG_RDP5(("Now running patched code\n"));
if ( ! X509_PUBKEY_get0_param(NULL, NULL, 0, , key)) {
error("X509_PUBKEY_get0_param failed\n");
return NULL;
}

(yes I missed freeing up resources before returning)


now I ran rdesktop and it does not crash but also does not work:
# ./rdesktop xpcrash > foo 2>&1
# cat foo  (snipped info marked as SNIPPED)


Autoselected keyboard map de
Failed to negotiate protocol, retrying with plain RDP.
ERROR: Failed to extract public key from certificate
ERROR: send: Die Verbindung wurde vom Kommunikationspartner
zurückgesetzt RDP depth: 24, display depth: 24, display bpp: 32, X
server BE: 0, host BE: 0 Adding translation, keysym=0xffe2,
scancode=0x36, modifiers=0x0 Adding translation, keysym=0xffe1,
scancode=0x2a, modifiers=0x0 Adding translation, keysym=0xffea,
scancode=0xb8, modifiers=0x0 Adding translation, keysym=0xff7e,
SNIPPED LOT OF SCANCODE STUFF
scancode=0x11, modifiers=0x2 Adding translation, keysym=0x65,
scancode=0x12, modifiers=0x0 Adding translation, keysym=0x45,
scancode=0x12, modifiers=0x2 Adding sequence for keysym (0xe8, egrave)
-> 0xfe50, 0x65, Adding sequence for keysym (0xc8, Egrave) -> 0xfe50,
0x45, Adding sequence for keysym (0xe9, eacute) -> 0xfe51, 0x65, 
Adding sequence for keysym (0xc9, Eacute) -> 0xfe51, 0x45, 
Adding sequence for keysym (0xea, ecircumflex) -> 0xfe52, 0x65, 
Adding sequence for keysym (0xca, Ecircumflex) -> 0xfe52, 0x45, 
Adding sequence for keysym (0xeb, ediaeresis) -> 0xfe57, 0x65, 
SNIPPED MANY ADDING SEQUENCE AND ADDING TRANSLATION STUFF
Adding translation, keysym=0xb7, scancode=0x34, modifiers=0x4
Adding translation, keysym=0xf7, scancode=0x34, modifiers=0x6
Adding translation, keysym=0x2d, scancode=0x35, modifiers=0x0
Adding translation, keysym=0x5f, scancode=0x35, modifiers=0x2
Adding translation, keysym=0xfe60, scancode=0x35, modifiers=0x4
Adding translation, keysym=0xfe56, scancode=0x35, modifiers=0x6
server bpp 24 client bpp 32 depth 24
g_num_channels is 4
Requesting channel cliprdr
Requesting channel rdpsnd
Requesting channel snddbg
Requesting channel rdpdr
Server RDP version is 4
We're going for the RDP5-style encryption
Ignored certs left: 6
Ignored Certificate length is 1046
cert #6 (ignored):
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c1:00:SNIPPED CENSORED SERIAL NUMBER
Algorithm: md5WithRSAEncryption Issuer: OU=Copyright (c)
1997 Microsoft Corp., OU=Microsoft Corporation, CN=Microsoft
Root Authority Validity Not Before: Jan 10 07:00:00 1997 GMT
Not After : Dec 31 07:00:00 2020 GMT
Subject: OU=Copyright (c) 1997 Microsoft Corp., OU=Microsoft
Corporation, CN=Microsoft Root Authority Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a9:02:bd:c1:70:e6:3b:f2:4e:1b:28:9f:97:78:
SNIPPED MODULUS DETAIL
ca:bc:f0:08:a3:22:30:b3:06:85:c9:b3:20:77:13:
85:df
Exponent: 65537 (0x10001)
X509v3 extensions:
2.5.29.1: 
0[.p.ir.#Q~..Mr0p1+0)..U..."Copyright (c) 1997
Microsoft Corp.1.0...UMicrosoft Corporation1!0...UMicrosoft
Root Authority..<<...>.c..@ Signature Algorithm:
md5WithRSAEncryption
95:e8:0b:c0:8d:f3:97:18:35:ed:b8:01:24:d8:77:11:f3:5c:
SNIPPED HEX DATA
a2:8c:d3:d5:54:3f:46:cd:1c:55:a6:70:db:12:3a:87:93:75: 9f:a7:d2:a0
Ignored certs left: 5 Ignored Certificate length is 1269
cert #5 (ignored):
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
eb:aa:SNIPPED SERIAL NUMBER
Signature Algorithm: md5WithRSAEncryption
Issuer: OU=Copyright (c) 1997 

Bug#839897: segmentation fault confirmed contacting w2k3 server.

[Erik Thiele]

after upgrading from jessie to stretch I cannot contact my w2k3
terminalserver via rdesktop anymore:

# dpkg -l rdesktop
ii  rdesktop   1.8.3-2+b1   amd64
# rdesktop w2k3hostname
Autoselected keyboard map de
Failed to negotiate protocol, retrying with plain RDP.
Speicherzugriffsfehler <-- german for segmentation fault

if i downgrade only the rdesktop package back to the jessie version it
works again:

# dpkg -l rdesktop
ii  rdesktop   1.8.2-3+deb8 amd64
# rdesktop w2k3hostname
Autoselected keyboard map de
Failed to negotiate protocol, retrying with plain RDP.
WARNING: Remote desktop does not support colour depth 24; falling back
to 16
   works.


I tried to compile rdesktop to run a debugger but I don't manage to get
the compilation running. it uses opaque struct BIGNUM directly
without pointer and some x509 stuff where I absolutly do not understand
how this should compile. So I am unsure how to help debugging here.

cya
erik

Bug#857169: furter investigation

[Erik Thiele]

In order to make systemd know, when openvpn is REALLY started,
I modified /lib/systemd/system/openvpn@.service as follows:

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service

[Service]
Type=notify
NotifyAccess=all
ExecStart=/usr/sbin/openvpn --status /run/openvpn/%i.status 10 --cd 
/etc/openvpn --config /etc/openvpn/%i.conf --up "/etc/openvpn/notifyhelper.sh 
${NOTIFY_SOCKET}"
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

EOF

(Probably NotifyAccess=exec can also work, this has not been tested.
that must be tried later when everything else works)

I created /etc/openvpn/notifyhelper.sh executable as follows:

#!/bin/bash
set -e
NOTIFY_SOCKET="$1" /bin/systemd-notify --ready --pid=$PPID

EOF

NOTIFY_SOCKET variable must be passed to the notifyhelper script as
shown above because openvpn cleans it from the environment and then
systemd-notify cannot contact systemd.

The system works almost.

But there are two major problems:

Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 do_ifconfig, 
tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip link set dev 
tun0 up mtu 1500 
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip addr add dev 
tun0 local 192.100.100.5 peer 192.100.100.1
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 
/etc/openvpn/notifyhelper.sh /run/systemd/notify tun0 1500 1542 192.100.100.5 
192.100.100.1 init 
Mär 09 08:53:47 m2 systemd[1]: Started OpenVPN connection to client. <<< this 
is what notifyhelper.sh does!
Mär 09 08:53:47 m2 systemd[1]: Mounting /home... 
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip route del 
0.0.0.0/0
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 /sbin/ip route add 
0.0.0.0/0 via 192.100.100.1 
Mär 09 08:53:47 m2 openvpn[664]: Thu Mar  9 08:53:47 2017 Initialization 
Sequence Completed

as you see from the journalctl excerpt above,
some routes are set AFTER notifyhelper.sh gets called.
so we have an order problem here.
I do not find a way to specify that notifyhelper.sh must be called VERY LAST.
if I read my logs longer i see that mounting /home fails because the routes 
have not been set...

Second major problem:

Mär 09 08:53:44 m2 openvpn[664]: Thu Mar  9 08:53:44 2017 Multiple --up scripts 
defined. The previously configured script is overridden.

In my case this leads to the problem that /etc/openvpn/update-resolv-conf
does not get called which is specified from my /etc/openvpn/client.conf file.


Conclusion:

It does not seem to be easy to make openvpn call some script at the very end
without interfering with the way the user thinks its own config file works
(i.e. the user has his own --up calls there.)



The clean way would be to have openvpn call systemctl sd_notify(...READY=1)
at the absolute end of initialization. upstream someone?


meanwhile I will continue by writing a custom systemd service
which waits until openvpn is ready by doing dns lookups and or pings.
then i will add the neccessary dependencies to make my boot work.
But for now I will give up on the idea of doing it the right way.


cya
erik

Bug#857169: cannot write systemd nfs mount service which runs after openvpn is really up, because systemd openvpn unit goes into started state too early

[Erik Thiele]

Package: openvpn
Version: 2.3.4-5+deb8

I am doing this in /etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
openvpn client

which will bring me up the systemd openvpn@client.service service on
boot.

I want to mount an nfs export on boot which is only reachable over vpn.
since nameserver resolution is not working before vpn is up, the
mounting fails if started too early.

I know I can use /etc/fstab to dynamically create a mount unit for
systemd, but in order to investigate my problem I created no fstab
entry but instead created this one manually:

root@m2:/etc/systemd/system# cat home.mount
[Unit]
After=openvpn@client.service

[Mount]
What=nfs.my.lan:/home
Where=/home
Type=nfs
Options=nolock,nosuid,nodev,nfsvers=3

[Install]
WantedBy=openvpn@client.service

This makes sure that the mounting takes place after the vpn is really
up. Then I systemctl enable home.mount

After that I reboot and investigate journalctl afterwards (only the
interesting entries are shown here):

Mär 08 15:11:35 m2 systemd[1]: Starting OpenVPN connection to client...
Mär 08 15:11:36 m2 systemd[1]: Started OpenVPN connection to client.
Mär 08 15:11:36 m2 systemd[1]: Mounting /home...
Mär 08 15:11:36 m2 systemd[1]: Failed to mount /home.
Mär 08 15:11:50 m2 ovpn-client[678]: Initialization Sequence Completed

As you see, the openvpn@client.service is in started state before
openvpn is reporting initialization sequence completed. for this
reason /home is mounted too early and fails.

Is it somehow possible to write
the /lib/systemd/system/openvpn@.service in a way that it reports
started only after initialization sequence is really completed?

(maybe openvpn can somehow write a temporary file when really finished
which systemd then tries to load to say yes we are really started, but
that one is just an idea...)

this bug report might be related to #681961.

cya
erik

Bug#857169: discussion thread found

[Erik Thiele]

i found a discussion of this here:

https://bbs.archlinux.org/viewtopic.php?id=166304

Bug#855215: libstatgrab error

[Erik Thiele]

Package: bwm-ng
Version: 0.6-3.1+b1

I am running amd64.
cat /etc/debian_version 
8.7
system is fully updated.

ii  libstatgrab9   0.90-1.2 amd64

start bwm-ng. it displays networking statistics. press the 'n'
key and it sais "libstatgrab error!" and terminates.

I got no clue how to debug.


cya
erik

Bug#847935: test report

[Erik Thiele]

Fabian Greffrath wrote:

> Erik,
> 
> Jason Crain wrote:
> > I could be wrong about how poppler's build system works, but I
> > think the way the cairo backend is linked, you might need an updated
> > libpoppler-glib instead of libpoppler.
> 
> could you please repeat the tests with this package additionally
> installed:
> 
> https://people.debian.org/~fabian/jessie/libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb


Sorry for the delay.

- I checked that my system is updated. debian_version is 8.7. 
- first I checked that atril correctly displayed the micro sign.
- I installed fonts-texgyre
- I verified that atril does NOT display the micro sign.
- I installed libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb from the
  link above. (md5 92f922b20537ab48da1d08920c75cd24) via dpkg -i.
- atril does now still correctly display the micro sign!

so as far as I can interpret the situation, your changes seem to fix
the problem


cya!
erik

Bug#847935: test report

[Erik Thiele]

hi

I reinstalled fonts-texgyre

then I installed your package:

ii libpoppler46:amd64 0.26.5-2+deb8u1.1 amd64

then I found out that neither atril not evince is linking against
libpoppler by running ldd on those binaries. Some of my own software
links against libpoppler and there i find your library. maybe evince is
somehow loading libpoppler at runtime. or it does not use libpoppler!

anyway. running atril or evince does not show the micro sign.


cya
erik

Bug#847935: [Pkg-fonts-devel] Bug#847935: Bug#847935: Bug#847935: Bug#847935: MICRO sign does not show

[Erik Thiele]

Am Thu, 12 Jan 2017 16:32:53 +0100
schrieb Fabian Greffrath :

> Well, strange! I was just going to reproduce this issue on my own
> testing/unstable system, but -- although I am using the fonts from
> fonts-texgyre as substitutes for the base fonts -- I am not able to
> reproduce this bug.
> 
> Well, there are 22 revisions between the poppler versions in stable
> and testing, so I assume the bug has been fixed in between (it has
> not been fixed in the fonts-texgyre package between stable and
> testing, I have checked that).
> 
> So, not sure what to do with this bug report then...

well. since the problem as you found out seems not to exist on
testing/unstable the remaining question is about what to do on stable.

hm. i think not many people have fonts-texgyre installed on stable.
otherwise this bug would be triggered by a lot of people maybe. So one
could argue this is an important bug if fonts-texgyre is installed, and
no bug if that package is not installed. I do not know what debian
policy says about such a problem regarding the possible fixes on
stable :-) I think poppler cannot be fixed on stable. maybe
fonts-texgyre could be removed from stable or the "wrong" font removed
from fonts-texgyre or added with different name and README.Debian sais
due to bug xxx you have to rename it manually to use that font. Hm.
Simply doing nothing is also not optimal. As for me the system worked
fine and one day I installed fonts-texgyre probably due to a maximum
tex installation and then suddenly many things broke regarding the micro
sign. Dunno.

Bug#847935: [Pkg-fonts-devel] Bug#847935: MICRO sign does not show

[Erik Thiele]

Am Wed, 28 Dec 2016 09:10:16 +0100
schrieb Fabian Greffrath <fab...@debian.org>:

> Am Montag, den 12.12.2016, 15:04 +0100 schrieb Erik Thiele:
> > I have no idea if this bug is assigned to the correct package
> > though.
> 
> What makes you believe that the fonts from fonts-freefont-ttf are used
> to render text that is supposed to be set in Helvetica or Times in
> PDFs ? Usually, the fonts from the gsfonts package are used for that.

I have no clue really. I also do not know how to find out which font is
used. I only found that our workers preview PDF files and instead of
4µm they read 4m which is 4 meters instead of 4 micrometers. Thats
pretty bad...

Please someone find out where the problem is and reassign the bug
appropriately.

Thank you

Erik

Bug#828721: data corruption on ssh remote

[Erik Thiele]

Package: attic
Version: 0.13-1

I attached a test script to this report. get root and do

cd /root
mkdir delme
cd delme
attic init mystore

now edit the script and configure it for local REPO and singletask.
run it, it will work.

now edit the script and configure it for local REPO and parallel.
run it, it will work.

now edit the script and configure it for remote REPO and singletask.
run it, it will work.

now edit the script and configure it for remote REPO and parallel.
run it, it will FAIL with tons of message like these:

attic: /usr/bin/xdg-screensaver: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'
attic: /usr/bin/xmodmap: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'
attic: /usr/bin/xmore: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'
attic: /usr/bin/xosview: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'
attic: /usr/bin/xpmtoppm: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'
attic: /usr/bin/xprop: [Errno 17] File exists:
'/root/.cache/attic/e6cb8c3a09fcd0a6737eae8ddfe53e685ab46a31a6e39d72b40e69d3143ecfdc/txn.tmp'

and other message aswell.

the used filesystem type is ext3 with noatime mount option.

the script seems unable to produce data corruption, because
attic check mystore
does not show problems. but anyway you see that backing up your data
does not work.

but in my real world scenario where i tried to backup all my servers on
a central attic repository i did not only have failed backups but also
the repository got corrupted on every night (backups run at night) -
which made the system completely unusable.

this is the result then:

backuphost:/backups/attic# attic check .
Starting repository check...
Error reading segment 0
Error reading segment 1
Error reading segment 2
Error reading segment 3
Error reading segment 4
Error reading segment 5
Error reading segment 6
Error reading segment 7
Error reading segment 8
Error reading segment 9
... and so on.

no, the harddisc or filesystem is not corrupt, it is really the
repository itself.


I think there should be some kind of warning to administrators not to
use attic via ssh although that might be the main usage scenario...


erik


foo.sh
Description: application/shellscript

Bug#827901: caja-sendto does not pass any parameters to mailer, so send to mail does not work at all

[Erik Thiele]

> > I set severity to grave as debian documentation sais i should mark
> > as grave when the package in question is unusable or mostly so.
> 
> Does the package work *not_at_all* or does it break other packages? Or
> is it just one functionality which is not working properly?
> 
> If it's just the latter, then this bug report should not be marked as
> "grave". Tagging a bug with severity "grave" has ramifications which
> can include the removal of the package from the archives and I'm not
> sure if that's what you intended.
> 
> Please do not file a bug report with severity of "grave" until you
> fully understand what the ramifications are and what the purpose of
> tagging it as "grave" is. Tagging it as "normal" is enough for 99% of
> the cases unless this issue is actually serious, e.g. a vulnerability
> with a working exploit.
> 
> Just tagging the bug as "grave" does not automatically make people fix
> the issue faster. The severity is readjusted by the maintainers anyway
> when doing triaging.

well. Actually I just
read from https://www.debian.org/Bugs/Developer#severities
grave
makes the package in question unusable or mostly so,...

and I think that caja-sendto is probably most of the time used to send
files by mail, and since that feature does not work, i thought grave
would be correct.

sorry if I chose the wrong severity.



erik

Bug#827901: caja-sendto does not pass any parameters to mailer, so send to mail does not work at all

[Erik Thiele]

Package: caja-sendto
Version: 1.8.0-3
Severity: grave

this report is about the feature of caja to send files by email when
caja-sendto package is installed. therefore you right click on a file
in caja and say sendto. then you choose email and enter a mail address.

I set severity to grave as debian documentation sais i should mark as
grave when the package in question is unusable or mostly so. since the
main task of caja-sendto is send files by mail, I hope grave is the
right severity, also I think that right click on a file to send it by
email is an important major feature of the mate desktop.

i am using the mate desktop and created a new system user to make sure,
that all configuration is clean.

to see error messages, i use the console instead of right click on a
file:

from the console i do:
#caja-sendto bla-2.png 
Init caja burn plugin
Init pidgin plugin
Init gajim plugin
Init email client plugin
Init removable-devices plugin
** Message: Mailer type: 0
** Message: Command: icedove

^^ you see Command: icedove without any parameters.

i can switch the system default mailer to claws-mail and get:

#caja-sendto bla-2.png 
Init caja burn plugin
Init pidgin plugin
Init gajim plugin
Init email client plugin
Init removable-devices plugin
** Message: Mailer type: 3
** Message: Command: claws-mail

^^ again you see there are no parameters passed to claws-mail.

so in both cases the mailer will open but not compose an email and also
not append the attachments.

also you see in the icedove case that icedove is not recognized as
icedove (it should be mailer type 4, see emailclient.c in the
sourcecode). this is because debian calls it icedove and caja-send
checks for "thunder".

i appended a patch to this report which fixes both issues:

- icedove is recognized as thunderbird (mailer type 4) correctly.

- mailer opens compose window and attachments are appended.



cu
erik--- /home/global/erik/compiling/ori/caja-extensions-1.8.0/sendto/plugins/emailclient/emailclient.c	2014-03-01 13:13:18.0 +0100
+++ emailclient.c	2016-06-22 11:37:48.0 +0200
@@ -95,23 +95,20 @@
 		/* Find what the default mailer is */
 		if (strstr (mail_cmd, "balsa"))
 			type = MAILER_BALSA;
-		else if (strstr (mail_cmd, "thunder") || strstr (mail_cmd, "seamonkey")) {
-			char **strv;
-
+		else if (strstr (mail_cmd, "thunder") || strstr (mail_cmd, "seamonkey")
+			 || strstr(mail_cmd, "icedove") )
 			type = MAILER_THUNDERBIRD;
-
-			/* Thunderbird sucks, see
-			 * https://bugzilla.gnome.org/show_bug.cgi?id=614222 */
-			strv = g_strsplit (mail_cmd, " ", -1);
-			g_free (mail_cmd);
-			mail_cmd = g_strdup_printf ("%s %%s", strv[0]);
-			g_strfreev (strv);
-		} else if (strstr (mail_cmd, "sylpheed") || strstr (mail_cmd, "claws"))
+		else if (strstr (mail_cmd, "sylpheed") || strstr (mail_cmd, "claws"))
 			type = MAILER_SYLPHEED;
 		else if (strstr (mail_cmd, "anjal"))
 			type = MAILER_EVO;
 	}
-
+	
+	char **strv = g_strsplit (mail_cmd, " ", -1);
+	g_free (mail_cmd);
+	mail_cmd = g_strdup_printf ("%s %%s", strv[0]);
+	g_strfreev (strv);
+	
 	if (mail_cmd == NULL)
 		return FALSE;
 

Bug#827889: formatting information shown on screen but not formatting

[Erik Thiele]

Package: gwakeonlan
Version: 0.5.1-1

LANG=C gwakeonlan
--> all OK
press the + button and see first line of window in bold letters.

LANG=de_DE.UTF-8 gwakeonlan
-->
/usr/bin/gwakeonlan:435: GtkWarning: Failed to set text from markup due
to error parsing markup: Fehler in Zeile 1, Zeichen 73: Element
»markup« wurde geschlossen, aber das derzeit offene Element ist »b«
builder.add_from_file(__searchPath('ui', '%s.glade' % APP_NAME))

press the + button and see first line of window
shown as "Rechnername und die MACAdresse eingeben"

there are probably the / missing in the closing tags.

cu
erik

Bug#820855: crashes when compiled with -D_GLIBCXX_DEBUG

[Erik Thiele]

Package: libsigc++-2.0-0c2a
Version: 2.2.10-0.2

erik@host:~/sigcpp_bug$ cat bug.cpp
#include 
#include 

using namespace std;
using namespace sigc;

class sigtester : public sigc::trackable {
public:
  sigtester();
  void myslot();
  signal0 mysig;
};

sigtester::sigtester()
{ cout << "sigtester::sigtester\n"; }

void sigtester::myslot()
{ cout << "sigtester::myslot\n"; }

void globalSlot()
{ cout << "globalSlot\n"; }

int main(int, char *[])
{
  sigtester st;
  cout << "first test starts\n";
  st.mysig.connect(sigc::mem_fun(, ::myslot));
  cout << "first test passed\n";

  signal0 thesig;
  cout << "second test starts\n";
  thesig.connect(sigc::ptr_fun());
  cout << "second test passed\n";

  return 0;
}

erik@host:~/sigcpp_bug$: g++ -g -Wall -Werror -D_GLIBCXX_DEBUG \
  $(pkg-config --cflags sigc++-2.0) \
  $(pkg-config --libs sigc++-2.0) bug.cpp -o will_crash

erik@host:~/sigcpp_bug$ g++ -g -Wall -Werror \
  $(pkg-config --cflags sigc++-2.0) \
  $(pkg-config --libs sigc++-2.0) bug.cpp -o will_work

erik@host:~/sigcpp_bug$ ./will_work 
sigtester::sigtester
first test starts
first test passed
second test starts
second test passed
erik@host:~/sigcpp_bug$ ./will_crash 
sigtester::sigtester
first test starts
Segmentation fault

erik@host:~/sigcpp_bug$ gdb ./will_crash 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
 This is free software: you are free
to change and redistribute it. There is NO WARRANTY, to the extent
permitted by law.  Type "show copying" and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/global/erik/sigcpp_bug/will_crash...done.
(gdb) run
Starting program: /home/global/erik/sigcpp_bug/will_crash 
sigtester::sigtester
first test starts

Program received signal SIGSEGV, Segmentation fault.
0xb7f723bd in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0xb7f723bd in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1  0xb7f7246a in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#2  0xb7f7267c in __gnu_debug::_Safe_iterator_base::_M_detach() ()
from /usr/lib/i386-linux-gnu/libstdc++.so.6 #3  0x0804937b in
__gnu_debug::_Safe_iterator_base::~_Safe_iterator_base
(this=0xb66c, __in_chrg=)
at /usr/include/c++/4.7/debug/safe_base.h:105 #4  0x08049489 in
__gnu_debug::_Safe_iterator
>::~_Safe_iterator (this=0xb66c, __in_chrg=)
>at /usr/include/c++/4.7/debug/safe_iterator.h:118 #5  0x080496d6 in
>sigc::signal0::connect (this=0xb6ac, slot_=...)
>at /usr/include/sigc++-2.0/sigc++/signal.h:2661 #6  0x08049091 in main
>() at bug.cpp:33 (gdb) 

this bug can also be reproduced on package version 2.4.0-1 on debian
jessie.

The problem is, that because of the bug I cannot use _GLIBCXX_DEBUG for
a large project where even only a small part of it uses libsigc++.

Also I am not sure if the problem is libsigc++ or the debugging feature
of libc.


cya
erik

Bug#814989: gdm3 remote crashable if xdmcp enabled (denial of service)

[Erik Thiele]

Package: gdm3
Version: 3.4.1-8


Architecture i386.

have this in daemon.conf:
[xdmcp]
Enable=True


now on a machine somewhere remote in the network do:
Xephyr :10 -query HOST_WITH_GDM3_RUNNING -terminate -nolisten tcp

now on HOST_WITH_GDM3_RUNNING you see this in syslog:
(of course there are errors that he cannot connect because of -nolisten tcp. 
but he should not crash:)

Feb 17 11:55:05 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:05 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:06 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:06 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:07 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:07 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:07 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:07 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:08 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:08 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:08 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:08 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:09 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:09 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:09 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:09 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:09 goofy gdm-simple-slave[5491]: WARNING: Unable to connect to 
display after 10 tries - bailing out
Feb 17 11:55:10 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:10 goofy gdm3[3503]: WARNING: GdmXdmcpDisplayFactory: Failed to 
look up session ID 11760611
Feb 17 11:55:10 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:11 goofy gdm-simple-slave[5493]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:11 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:11 goofy gdm-simple-slave[5493]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:11 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:11 goofy gdm-simple-slave[5492]: WARNING: Unable to connect to 
display after 10 tries - bailing out
Feb 17 11:55:12 goofy gdm[5494]: *** START 
**
Feb 17 11:55:12 goofy gdm-simple-slave[5493]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:12 goofy gdm[5494]: [Thread debugging using libthread_db enabled]
Feb 17 11:55:12 goofy gdm[5494]: Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Feb 17 11:55:12 goofy gdm[5494]: [New Thread 0xb6da7b70 (LWP 3640)]
Feb 17 11:55:12 goofy gdm-simple-slave[5493]: WARNING: Unable to connect to 
display 127.0.0.1:10
Feb 17 11:55:13 goofy gdm[5494]: 0xb773a428 in __kernel_vsyscall ()
Feb 17 11:55:13 goofy gdm[5494]: #0  0xb773a428 in __kernel_vsyscall ()
Feb 17 11:55:13 goofy gdm[5494]: #1  0xb722e21b in waitpid () at 
../sysdeps/unix/syscall-template.S:82
Feb 17 11:55:13 goofy gdm[5494]: #2  0x08061402 in ?? ()
Feb 17 11:55:13 goofy gdm[5494]: #3  0x08061809 in ?? ()
Feb 17 11:55:13 goofy gdm[5494]: #4  
Feb 17 11:55:13 goofy gdm[5494]: #5  0x08055d1a in ?? ()
Feb 17 11:55:13 goofy gdm[5494]: #6  0xb72cc1f2 in ?? () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
Feb 17 11:55:13 goofy gdm[5494]: #7  0xb72ce6d3 in g_main_context_dispatch () 
from /lib/i386-linux-gnu/libglib-2.0.so.0
Feb 17 11:55:13 goofy gdm[5494]: #8  0xb72cea70 in ?? () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
Feb 17 11:55:13 goofy gdm[5494]: #9  0xb72ceecb in g_main_loop_run () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
Feb 17 11:55:13 goofy gdm[5494]: #10 0x0804d45f in ?? ()
Feb 17 11:55:13 goofy gdm[5494]: #11 0xb70cee46 in __libc_start_main 
(main=0x804cdd0, argc=1, ubp_av=0xbfadfaf4, init=0x8062ad0, fini=0x8062ac0, 
rtld_fini=0xb7749560, stack_end=0xbfadfaec) at libc-start.c:244
Feb 17 11:55:13 goofy gdm[5494]: #12 0x0804d7c1 in ?? ()
Feb 17 11:55:13 goofy gdm[5494]: 
Feb 17 11:55:13 goofy gdm[5494]: Thread 2 (Thread 0xb6da7b70 (LWP 3640)):
Feb 17 11:55:13 goofy gdm[5494]: #0  0xb773a428 in __kernel_vsyscall ()
Feb 17 11:55:13 goofy gdm[5494]: No symbol table info available.
Feb 17 11:55:13 goofy gdm[5494]: #1  0xb71841c6 in *__GI___poll 
(fds=0xb721bff4, nfds=1, timeout=-1) at 

Bug#758711: other example files triggering the bug

[Erik Thiele]

lsof | egrep 'delete|DEL|path inode'
on my system shows lots of these entries:

samba 2513root  mem   REG 254,32
10400 146566 /usr/lib/x86_64-linux-gnu/samba/ldb/subtree_delete.so
samba 2513root  mem   REG 254,32
10424 146609 /usr/lib/x86_64-linux-gnu/samba/ldb/show_deleted.so

i am running a samba4 active directory server from the
debian package sernet-samba-libs from sernet (distributor of samba4
debian packages).

running checkrestart wants me to restart samba over and over again,
even after a reboot of the machine. this probably is because of the
word delete in the filename of the library file above.


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

Bug#679543: Detailed xev analysis

[Erik Thiele]

in the following reports I always leave out lines like these to save
sceen space:
root 0x377, subw 0x0, time 1027512667, (515,302), root:(519,358),
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False


xev on local X11 session. Pressing Up and Right keys on arrow keypad
(not numeric keypad):

KeyPress event, serial 35, synthetic NO, window 0x461,
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES,


xev on vnc4server 4.1.1+X4.3.0-37.1, xvnc4viewer 4.1.1+X4.3.0, pressing
same keys again:

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,


xev on local X11 session pressing super+Up and super+Right on arrow
keypad (not numeric keypad). i checked that it is really super+Up by
verifying that it automatically maximizes the window. this way you do
not see the key events in xev. To actually see the keys in xev I
reconfigured my gnome keyboard settings to not use super+Up anymore.
this is the result:

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,


xev on vnc4server 4.1.1+X4.3.0-37.1, xvnc4viewer 4.1.1+X4.3.0, pressing
same keys again (with super):

KeyPress event, serial 33, synthetic NO, window 0x321,
state 0x0, keycode 255 (keysym 0xffeb, Super_L), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 255 (keysym 0xffeb, Super_L), same_screen YES,



analysis of results:

keycodes on local X11 and vnc are different.

keysym on local X11 and vnc are the same.

see the difference on the Super_L keypress.  keycode is 255 on vnc!. is
255 a legal keycode? it somehow looks like -1.

running gnome keyboard settings on local x11 i can enter new key
sequences consisting of super+anything. when trying to do so on vnc,
once you press the super key, Super L will be displayed as key. this
means super is not seen as a modifier. it is instead seen as a final
key just like hitting a normal alphabetic key.

running xmodmap on x11 local:
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift   Shift_L (0x32),  Shift_R (0x3e)
lockCaps_Lock (0x42)
control Control_L (0x25),  Control_R (0x69)
mod1Alt_L (0x40),  Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3  
mod4Super_L (0x85),  Super_R (0x86),  Super_L (0xce),
Hyper_L(0xcf)
mod5ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)


running xmodmap on vnc:
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift   Shift_L (0x32),  Shift_R (0x3e)
lock  
control Control_L (0x25),  Control_R (0x6d)
mod1Alt_L (0x40),  Alt_R (0x71)
mod2  
mod3  
mod4  
mod5


see that there is no Super stuff on xmodmap vnc.

i am not an expert in vnc/x11/keyboard stuff.

For now i simply disable Super-Up/Down in gnome keyboard settings as
suggested in the bugreport, but still i do not understand, why gnome
thinks the user presses super 

Bug#744177: JBIG and JBIG2 files are not detected

[Erik Thiele]

hi

 Yes, that needs attention. Do you have more public information about
 the file format? I only found the jbigkit sources so far and couldn't
 figure out the details so far.



JBIG:
http://www.jpeg.org/jbig/index.html
no real information seems to be available here.
but jbigkit sources could be interesting.

JBIG2:
http://www.jpeg.org/jbig/jbigpt2.html
here you can find a PDF file.
jbig2dec sources could be interesting in the links section.

wikipedia gives some hints also:
http://de.wikipedia.org/wiki/JBIG

there you find information about the appropriate ISO/IEC or ITU-T specs
but I guess these are not freely available for download.


I do not know further information.


Erik


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

Bug#744177: JBIG and JBIG2 files are not detected

[Erik Thiele]

Package: libmagic1
Version: 5.11-2+deb7u3

### first lets create a demo image.
bash$ cat source_ascii.pbm EOF
P1
20 10
00010011001110000010100011
100110001111011100110001000000
000111110001101100010010
EOF

### convert it to binary pbm because the other tools don't like ascii
### input.
bash$ pgmtopbm source_ascii.pbm  source.pbm

### please install jbigkit-bin 2.0-2+deb7u1
### lets create JBIG and JBIG2 files from our original image:
bash$ pbmtojbg source.pbm  comp.jbg
bash$ pbmtojbg85 source.pbm  comp.jbg85

### try to display these images.
### gimp fails on both, but imageMagick can display one of them:
bash$ display comp.jbg  # display from ImageMagick. works!
bash$ display comp.jbg85  # does not detect image format :-(

### lets now convert the JBIG images back to original:
bash$ jbgtopbm comp.jbg | pgmtopbm  back.pbm
bash$ jbgtopbm comp.jbg85 | pgmtopbm  back85.pbm

### now compare original to decompressed images
bash$ md5sum *|sort
  you see that back85.pbm, back.pbm, source.pbm are equal.

so compression and decompression of jbg and jbg85 are working.
they even do for larger source images.

I was thinking about replacing TIFF-G4 compressed images by JBIG or
JBIG2 compressed images because they have much better compression ratio,
but as images are stored as files, it is necessary that the filetype is
detected by libmagic.

and here is the bug / wishlist:

bash$ file *
back85.pbm:   Netpbm PBM rawbits image data -- OK
back.pbm: Netpbm PBM rawbits image data -- OK
comp.jbg: MS Windows icon resource  -- wrong!
comp.jbg85:   MS Windows icon resource  -- wrong!
source_ascii.pbm: Netpbm PBM image, ASCII text-- OK
source.pbm:   Netpbm PBM rawbits image data -- OK


cu
erik


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

Bug#624509: does only send CR LF . instead of CR LF . CR LF on end of smtp transfer

[Erik Thiele]

Hello Carsten,

Am Sun, 21 Jul 2013 10:32:25 +0200
schrieb Carsten Schoenert c.schoen...@t-online.de:

 On Fri, Apr 29, 2011 at 08:55:32AM +0200, Erik Thiele wrote:
  Package: icedove
  Version: 3.0.11-1+squeeze1
  ...
 
 sounds strange. What about that error with recent versions? Can you
 please recheck that bahaviour?
 What mail server you are working with?
 
 If you need some help in debugging there hopefully some useful info in
 the wiki [1].
 I think this is no Debian specific problem so maybe there is a already
 open bug in the Mozilla Bugzilla [2]. If you find a opened bug for
 that (or you are willing open up a new bug) please provide the URI to
 it so we can link this together.
 
 [1] https://wiki.debian.org/Icedove#Debugging
 [2] https://bugzilla.mozilla.org/

I did not have this problem for a long time now. Probably it was
somehow fixed. It's strange that I was the only person to get into this
trouble. Probably you should close this bug then.


Regards
Erik


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

Bug#716939: file / show history, not working.

[Erik Thiele]

Package: clusterssh
Version: 4.01.01-4

hi

start cssh from a terminal
click File
click show history

now see this on the calling terminal:

Tk::Error: Can't call method config on an undefined value
at /usr/share/perl5/App/ClusterSSH.pm line 418. Tk callback
for .#menu.#menu#file Tk::__ANON__ at /usr/lib/perl5/Tk.pm line 251
 Tk::Menu::Invoke at /usr/lib/perl5/Tk/Menu.pm line 532
 ButtonRelease
 (command bound to event)


cu
erik


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

Bug#710897: having this every day

[Erik Thiele]

this annoying bug drives me mad for years now.

googling for it finds many many pages. some of them:
launchpad: #436035
debian bug: #587370
debian bug: #590107

some also mention that they get daily emails of this kind from their
backup scripts. Well just like me. In my installation it is about 15
emails each day and it really makes me mad. It would be great to
have a backported fix for squeeze here.


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

Bug#632710: cupsd[1299]: segfault at 0 ip b74d3440 sp bfeb9d18 error 4 in libc-2.11.2.so[b7460000+140000]

[Erik Thiele]

hi


I am still running squeeze (updated of course) on the printserver. But
this problem is not in my active knowledge, which means that it has not
occured for a long time. Maybe it is somehow fixed :-)


cu
erik


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

Bug#457777: no password prompt...

[Erik Thiele]

Hi

am using an updated squeeze system:
gnome-screensaver 3.4.1-1


xrandr -q sais:

Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y
axis) 376mm x 301mm 1280x1024  60.0*+   75.0  
   1152x864   75.0  
   1024x768   75.1 75.0 60.0  
   832x62474.6  
   800x60075.0 60.3  
   640x48075.0 60.0  
   720x40070.1  



I am using LTSP (linux terminal server project) and on some terminal
clients (seems to depend on video hardware type) i have the problem
that screensaver graphics work (animations and such) and when i try to
relogin, no prompt appears. I can however blindly type the password and
it works.

at the moment when i press Return, you shortly see the password window
flicker (at least its gray widget background), but only very short. it
disappears at once since a correct password has been entered.

XDMCP is used here.


This behaviour is extremly annoying to our users and i get regular calls
on the phone that the screen is black again!. then i go and do a
killall gnome-screensaver to make things work again.


It seems that this bug in gnome-screensaver can be triggered by certain
hardware / xserver configs.

when i login by XDMCP not via my LTSP terminal, but by a Xephyr session
from a normal PC, then everything works, i.e. a password prompt is
displayed.


***

i want to emphasize this:

in exactly the same setup (XDMCP, same user, same application server)

you get a working situation with Xephyr from a normal linux PC

or a not-working situation with several (but not all!) LTSP clients



cya
Erik


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

Bug#688286: Port missing in INI file - null pointer return from dbopen without message or error

[Erik Thiele]

Package: freetds-dev
Version: 0.91-1

hi

on debian squeeze i used freetds-dev in version 0.82-7. the code below 
did work and did not need a Port entry in the INI file.


After switching to wheezy (freetds-dev version 0.91-1) i had to do some 
recompilation from source of the library with debugging information and 
stepped into it with the debugger and found out, that when there is no 
Port Entry in the INI File, dbopen will just return a null pointer 
without doing any error or message. i think that behaviour is not so 
good. after adding a Port entry in the INI File, the system works again.


so two problems here:

1) i now need a Port entry in the ini file as opposed to the last version.

2) if i don't have a Port entry, i will get no useful information. just 
generic failure.


point 1) can be seen as a feature and not bug. but point 2) is bad.


the database i want to connect to is some ms-sql server on tcp port 1433.
here's what i do:

   if (dbinit() != SUCCEED) throw_dbfatalerror(CODEPOS dbinit failed);
  dberrhandle(err_handler); -- err_handler won't ever get called!
  dbmsghandle(msg_handler); -- msg_handler won't ever get called!

  LOGINREC *login = dblogin();

  if (DBSETLCHARSET(login, iso_1) != SUCCEED) 
throw_dbfatalerror(DBSETLCHARSET failed);
  if (DBSETLUSER(login, myusername) != SUCCEED) 
throw_dbfatalerror(DBSETLUSER failed);
  if (DBSETLPWD(login, mypassword) != SUCCEED) 
throw_dbfatalerror(DBSETLPWD failed);
  if (DBSETLAPP(login, myappname) != SUCCEED) 
throw_dbfatalerror(DBSETLAPP failed);


DBPROCESS *foo = dbopen(login.get(), yyydbfreetds);
foo is now a null pointer!

the contents of /etc/freetds.conf are:
[yyydbfreetds]
host = myhostname
port = 1433
tds version = 8.0


if you leave out the port line, problematic behaviour will be as 
described above.




cya
erik


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

Bug#688015: memory leak data update

[Erik Thiele]

hello,

i may update my memory log for reference:

2012-09-17 11,7% VIRT=63852 RES=60316 SHR=1888
2012-09-18 14,6% VIRT=84760 RES=74952 SHR=1884
2012-09-21 22,4% VIRT=117M RES=112M SHR=1892

i'm sorry I will probably not find time right now to do more debugging. 
so meanwhile this bug will just be for reference if other people 
experience the same problem...



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

Bug#628393: deleting slow

[Erik Thiele]

hello.

when inserting characters into the edited buffer by keyboard repeat, 
i.e. something like: KKK, then it goes fast. 
but if i then try to backspace delete these with keyboard repeat, it 
will not go as fast as being typed. the cursor will not run smoothly and 
also about half that fast maybe. also deleting with C-d goes slowly. 
Also i think that scrolling goes somewhat slower. The overall feeling is 
a little bit delayed. Don't know.


after switching to emacs-lucid the problems are completely gone and 
emacs is usable again.


i have a debian wheezy installation on i386.

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 
210] (rev a2)


erik@goofy:~$ dpkg -l *nvidi*|grep ^i  (clipped long lines)
ii  glx-alternative-nvidia0.2.2
ii  libgl1-nvidia-alternatives302.17-3
ii  libgl1-nvidia-glx:i386302.17-3
ii  libglx-nvidia-alternatives302.17-3
ii  nvidia-alternative302.17-3
ii  nvidia-detect 302.17-3
ii  nvidia-glx302.17-3
ii  nvidia-installer-cleanup  20120630+3
ii  nvidia-kernel-3.2.0-3-rt-686-pae  302.17+2+3+3.2.23-1
ii  nvidia-kernel-common  20120630+3
ii  nvidia-kernel-dkms302.17-3
ii  nvidia-kernel-rt-686-pae  302.17+2
ii  nvidia-settings   302.17-2
ii  nvidia-support20120630+3
ii  nvidia-vdpau-driver:i386  302.17-3
ii  nvidia-xconfig302.17-2
ii  xserver-xorg-video-nvidia 302.17-3
erik@goofy:~$ uname -a
Linux goofy 3.2.0-3-rt-686-pae #1 SMP PREEMPT RT Mon Jul 23 05:49:20 UTC 
2012 i686 GNU/Linux


ii  linux-image-3.2.0-3-rt-686-pae3.2.23-1


cya
erik


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

Bug#688015: memory leak

[Erik Thiele]

Package: fetchmail
Version: 6.3.18-2

/etc/fetchmailrc:

set daemon 30
set syslog
set no bouncemail
set no spambounce
set no softbounce

poll pop.myprovider.de proto pop3 user myusern...@mypublicdomain.de pass
MYSECRETPASS smtphost mail.myinternaldomain.lan smtpname
myusern...@myinternaldomain.lan fetchall

END OF /etc/fetchmailrc

the poll line above is repeated another 13 times with different usernames.

ps axuw|grep fetchmail

105910  0.0 14.5  84756 74956 ?Ss   Sep13   6:31
/usr/bin/fetchmail --bad-header accept -f /etc/fetchmailrc --pidfile
/var/run/fetchmail/fetchmail.pid --syslog

as can be seen, fetchmail is running as daemon. It has been manually
started on September 13, because the old instance was killed because of
kernel OOM (out of memory) kill. see:

Sep 12 07:03:50 mail kernel: [8986062.350113] fetchmail invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 12 07:03:50 mail kernel: [8986062.350117] fetchmail cpuset=/
mems_allowed=0
Sep 12 07:03:50 mail kernel: [8986062.350119] Pid: 1444, comm: fetchmail
Not tainted 2.6.32-5-686 #1
Sep 12 07:03:50 mail kernel: [8986062.350121] Call Trace:
Sep 12 07:03:50 mail kernel: [8986062.350127]  [c1089a78] ?
oom_kill_process+0x60/0x201
Sep 12 07:03:50 mail kernel: [8986062.350130]  [c1089ff5] ?
__out_of_memory+0xf4/0x107
Sep 12 07:03:50 mail kernel: [8986062.350132]  [c108a062] ?
out_of_memory+0x5a/0x7c
Sep 12 07:03:50 mail kernel: [8986062.350135]  [c108c90d] ?
__alloc_pages_nodemask+0x3ef/0x4d9
Sep 12 07:03:50 mail kernel: [8986062.350138]  [c108dced] ?
__do_page_cache_readahead+0x98/0x16b
Sep 12 07:03:50 mail kernel: [8986062.350140]  [c108ddd4] ?
ra_submit+0x14/0x18
Sep 12 07:03:50 mail kernel: [8986062.350142]  [c1088392] ?
filemap_fault+0x16d/0x2e6
Sep 12 07:03:50 mail kernel: [8986062.350144]  [c109a0b2] ?
__do_fault+0x47/0x3b1
Sep 12 07:03:50 mail kernel: [8986062.350147]  [c109c076] ?
handle_mm_fault+0x48f/0x959
Sep 12 07:03:50 mail kernel: [8986062.350150]  [c126dfa6] ?
schedule+0x78f/0x7dc
Sep 12 07:03:50 mail kernel: [8986062.350153]  [c1270d90] ?
do_page_fault+0x2f1/0x307
Sep 12 07:03:50 mail kernel: [8986062.350155]  [c1270a9f] ?
do_page_fault+0x0/0x307
Sep 12 07:03:50 mail kernel: [8986062.350157]  [c126f2f3] ?
error_code+0x73/0x78

so I started a memory log:

2012-09-17 11,7% VIRT=63852 RES=60316 SHR=1888
2012-09-18 14,6% VIRT=84760 RES=74952 SHR=1884

so again it seems to run until oom death.

the machine is a virtual machine with 512MB ram + 1GB swap:

erik@mail:~$ free
 total   used   free sharedbuffers cached
Mem:514728 503600  11128  0  81100 237232
-/+ buffers/cache: 185268 329460
Swap:  1048568   20801046488


how can I further supply information on this issue? It is a production
machine, but maybe I can somehow help find the cause of the issue
anyway? Or is that memory leakage a known issue?


cya
Erik


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

Bug#688015: [pkg-fetchmail-maint] Bug#688015: memory leak

[Erik Thiele]

Am 18.09.2012 12:53, schrieb Nico Golde:
 Hi,
 * Erik Thiele erik.thi...@thiele-hydraulik.de [2012-09-18 09:48]:
 [...] 
 how can I further supply information on this issue? It is a production
 machine, but maybe I can somehow help find the cause of the issue
 anyway? Or is that memory leakage a known issue?
 
 This is not known to me at least. Unfortunately the logs don't show that 
 fetchmail had memory issues. The kernel randomly starts killing processes 
 (depending on your policy) if no memory can be allocated anymore.
 Could you log the virtual memory usage of specifically fetchmail?

at the end of my report you see daily logs of last two days of fetchmail
memory consumption. i will continue to log that log to see if it further
increases.

actually the kernel killed many (174) processes until it finally killed
fetchmail, then there where no more oom kills left. since fetchmail is
the last to be killed, i suggest that fetchmail was the problem.

i found that the system is running sar and after examining the data, i
found out that the used memory kind of linearly increases over time,
until the mega oom-killer burst mentioned above when suddenly all memory
was free again.

there was only one single kill of fetchmail. i am quite sure that
fetchmail must be the process that used all system memory here.

 Also, it may be interesting to see what running fetchmail with valgrind on 
 your end produces. Can you test that?

does this mean take debian source package, recompile with debug flags,
run under valgrind and terminate after two days with valgrind option
show-reachable or so and send you that output then? or is there an
easier way? Please consider it's a production system on a non-IT company
which should just run...


cya
erik


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

Bug#597504: Remote autologin is neccessary

[Erik Thiele]

Hello,

I read in this thread, that remote autologin is not useful. In my
installation I have about 20 client computers running LTSP (so they
become remote X terminals). all clients do autologin to a central server
and run specific software depending on their hostname. each computer is
next to a mechanic production machine and needs to display the
informations for that machine.

my gdm conf sais:

[daemon]
TimedLoginEnable=true
TimedLoginDelay=1
TimedLogin=/etc/gdm/autologinchooser.sh|


and the autologinchooser.sh script reads:

#!/bin/bash

set -e

if [ ${DISPLAY/:*/} == 192.168.30.72 ]; then
echo fox
exit 0
elif [ ${DISPLAY/:*/} == 192.168.30.94 ]; then
echo brown
exit 0
 and so on.
fi
exit 1


I think remote autologin is a very important feature.

thanks!
erik



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

Bug#666042: autologin works. but when logging out, there will be no more autologin.

[Erik Thiele]

Package: gdm3
Version: 3.0.4-4

hello,

my gdm3 is configured for autologin like this:

/etc/gdm3/daemon.conf:
[daemon]
#AutomaticLoginEnable = false
#AutomaticLogin =
TimedLoginEnable=true
TimedLogin=fox
TimedLoginDelay=1
[security]
[xdmcp]
[greeter]
[chooser]
[debug]

Now when i start gdm3, an autologin will happen and the user fox will
automatically log in after 1 second timeout. But when fox logs out,
the normal gdm login screen will appear and there will be no more
automatic login.

as this is a kiosk type application, there will always be users who log
out...

i found the idea for this workaround on the internet:

cat /etc/gdm3/PostSession/Default
#!/bin/bash

( /etc/init.d/gdm3 stop ; sleep 5; /etc/init.d/gdm3 start) /dev/null
/dev/null 2/dev/null 
disown

exit 0

that workaround is nice if there is only one local autologin user. but
if at the same time there are other open sessions for example over XDMCP
then of course it is not nice, if all sessions are killed each time the
local user logs off. So this work around really is only a work around. A
real fix should be made.



Thanks!
Erik



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

Bug#460600: bug also triggers on sending attachments

[Erik Thiele]

hello,

today it happened that we sent 4 different emails with some 5 megabyte
size attachment. (a 20mb zip that had been split to 5 mb parts so that
the receiving side won't discard the emails).

first we put them all into send later mode. then we sent all outgoing
mails at once. two of the 4 emails had truncated attachments.

the broken emails were also stored in the sent-folder (which is also on
imap). what i mean is that not only have broken emails been sent, but
these broken emails have also been stored brokenly in the sent-folder.

unfortunately we did not check if they were already broken while being
stored in the send-later folder.

after having a bad phone call from the receiver of the mails, we took
the wrong mails, selected open as new, deleted the attachment,
re-added the attachment and clicked on send. then it worked.

unfortunately it will be hard to reproduce.

the important thing to point out here, is that the problem not only
occurs on downloading attachments, it somehow also appears on sending
email with attachments.

cya
erik



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

Bug#460600: Reproducible

[Erik Thiele]

hi

just want to report that this problem continues to exist and existed for
a quite long time now. I don't remember when I first encountered it though.

icedove   3.0.11-1+squeeze4

I also use imap here. we have our own dovecot server running in LAN.
dovecot-imapd1:1.2.15-7

I can confirm that restarting icedove usually fixes the problem. but you
can also just try to download again and then it might also work.

I cannot find out, under what circumstances the problem appears. But on
every attachment I download, I check twice that the file is not truncated.

Again and again this problem hits some of our users. Maybe there is a
way to debug, but I haven't found one yet. The bug is extremly annoying...


cu
Erik



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

Bug#632710: cupsd[1299]: segfault at 0 ip b74d3440 sp bfeb9d18 error 4 in libc-2.11.2.so[b7460000+140000]

[Erik Thiele]

Package: cups
Version: 1.4.4-7

after long running, and at a time where probably no print job is
running, because it is before work hours, cups suddenly segfaulted
without leaving a trace in any of its logs. but i found this in my syslog:

Jul  5 06:25:32 joe kernel: [853885.282133] cupsd[1299]: segfault at 0
ip b74d3440 sp bfeb9d18 error 4 in libc-2.11.2.so[b746+14]

i'm sorry, i don't know how to map that address to lines in code.


some more informations:

Linux joe 2.6.32-5-686 #1 SMP Wed May 18 07:08:50 UTC 2011 i686 GNU/Linux

lrwxrwxrwx 1 root root 14 20. Apr 09:59 /lib/libc.so.6 - libc-2.11.2.so

ii  libc6   2.11.2-10  Embedded GNU C Library: Shared libraries


erik@joe:~$ reportbug -q --template -T none -s none -S normal -b
--list-cc none -q cups

*** manually reduced output followes ***

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

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

Versions of packages cups depends on:
ii  adduser 3.112+nmu2   add and remove users and groups
ii  bc  1.06.95-2The GNU bc arbitrary
precision cal
ii  cups-client 1.4.4-7  Common UNIX Printing
System(tm) -
ii  cups-common 1.4.4-7  Common UNIX Printing
System(tm) -
ii  cups-ppdc   1.4.4-7  Common UNIX Printing
System(tm) -
ii  debconf [debconf-2. 1.5.36.1 Debian configuration
management sy
ii  ghostscript 8.71~dfsg2-9 The GPL Ghostscript
PostScript/PDF
ii  libavahi-client30.6.27-2+squeeze1Avahi client library
ii  libavahi-common30.6.27-2+squeeze1Avahi common library
ii  libc6   2.11.2-10Embedded GNU C Library:
Shared lib
ii  libcups21.4.4-7  Common UNIX Printing
System(tm) -
ii  libcupscgi1 1.4.4-7  Common UNIX Printing
System(tm) -
ii  libcupsdriver1  1.4.4-7  Common UNIX Printing
System(tm) -
ii  libcupsimage2   1.4.4-7  Common UNIX Printing
System(tm) -
ii  libcupsmime11.4.4-7  Common UNIX Printing
System(tm) -
ii  libcupsppdc11.4.4-7  Common UNIX Printing
System(tm) -
ii  libdbus-1-3 1.2.24-4+squeeze1simple interprocess
messaging syst
ii  libgcc1 1:4.4.5-8GCC support library
ii  libgnutls26 2.8.6-1  the GNU TLS library -
runtime libr
ii  libgssapi-krb5-21.8.3+dfsg-4squeeze1 MIT Kerberos runtime
libraries - k
ii  libijs-0.35 0.35-7   IJS raster image transport
protoco
ii  libkrb5-3   1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries
ii  libldap-2.4-2   2.4.23-7.2   OpenLDAP libraries
ii  libpam0g1.1.1-6.1Pluggable Authentication
Modules l
ii  libpaper1   1.1.24   library for handling paper
charact
ii  libpoppler5 0.12.4-1.2   PDF rendering library
ii  libslp1 1.2.1-7.8OpenSLP libraries
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libusb-0.1-42:0.1.12-16  userspace USB programming
library
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2
init scrip
ii  poppler-utils   0.12.4-1.2   PDF utilitites (based on
libpopple
ii  procps  1:3.2.8-9/proc file system utilities
ii  ssl-cert1.0.28   simple debconf wrapper for
OpenSSL
ii  ttf-freefont20090104-7   Freefont Serif, Sans and
Mono True
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages cups recommends:
ii  cups-driver-gutenprint  5.2.6-1  printer drivers for CUPS
ii  foomatic-filters4.0.5-6  OpenPrinting printer
support - fil
ii  ghostscript-cups8.71~dfsg2-9 The GPL Ghostscript
PostScript/PDF

Versions of packages cups suggests:
ii  cups-bsd  1.4.4-7Common UNIX Printing
System(tm) -
pn  cups-pdf  none (no description available)
ii  foomatic-db   20100630-1 OpenPrinting printer
support - dat
ii  hplip 3.10.6-2   HP Linux Printing and
Imaging Syst
pn  smbclient none (no description available)
ii  udev  164-3  /dev/ and hotplug
management daemo
pn  xpdf-korean | xpdf-japanese | none (no description available)

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, lpd, parallel, scsi, serial, socket, usb, snmp, dnssd



cu
Erik



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

Bug#630042: fixed

[Erik Thiele]

Thank you very much! Fix came in by regular security update.
I vote for closing the report.

cu
Erik



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

Bug#630676: fails on smbfs mount

[Erik Thiele]

Package: xdiskusage
Version: 1.48-10

i mount a share with smbfs:

root# mount //winxpost/c\$ -ousername=Administrator -t smbfs /mnt
Password:

then i run xdiskusage as root

i click on /mnt and it displays a error box with an exclamation mark
containing the message:
/mnt: Value too large for defined datatype

it offers a close button, which i click and no disk analysis is done, i
am in main menu again.

if i run xdiskusage in ltrace, the following snipped shows the moment
there i click on /mnt:

_ZN9Fl_Window5flushEv(0x84480a8, 0, 0, 0, 0) = 48
_ZN9Fl_Window5flushEv(0x84480a8, 0, 0, 0, 0) = 48
_ZN9Fl_Window5flushEv(0x84480a8, 0, 0, 0, 0) = 48
_ZNK10Fl_Browser5valueEv(0x84481e0, 0xb78280d4, 683780, 0xb781a000,
0xb7821454) = 26
__xstat(3, /mnt, 0xbfaa65f0)   = -1
__errno_location()   = 0xb732da78
strerror(75) = Value too large for
defined data...
_Z8fl_alertPKcz(0x804e4f3, 0x8448c58, 0xb76bf360, 79, 0 unfinished ...
_ZN9Fl_Window4showEv(0x84b5948, 0x84c9448, 0, 90, 23) = 0xb78c3e18
_ZN9Fl_Window5flushEv(0x84480a8, -1, 0xb78fdff4, 1024, 0x84b5948) = 48
_ZN9Fl_Window5flushEv(0x84b5948, 0, 0, 0, 0) = 157
_ZN9Fl_Window5flushEv(0x84b5948, 0, 0, 0, 0) = 157



cu
erik



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

Bug#630042: [Tiff] bug in G4 encoder.

[Erik Thiele]

hello,

this email goes to the debian bug 630042 and to the tiff mailinglist
people. the tiff mailinglist people helped to find the problem. thanks
for that.



first we use the debian version (which is based on libtiff 3.9.4) to
compress the original g3 to g4. it works without errors:

neu$ tiffcp -c g4 gimpcrop.g3.tiff debian_g4.tiff


now lets convert it back with the debian version. this gives a lot of
errors and produces a corrupted image:

neu$ tiffcp -c g3 debian_g4.tiff debian_g3.tiff

Fax4Decode: debian_g4.tiff: Bad code word at line 17 of strip 9 (x 0).
Fax4Decode: Warning, debian_g4.tiff: Premature EOL at line 17 of strip 9
(got 0, expected 4519).
Fax4Decode: Warning, debian_g4.tiff: Line length mismatch at line 44 of
strip 9 (got 4520, expected 4519).
Fax4Decode: Warning, debian_g4.tiff: Line length mismatch at line 53 of
strip 9 (got 4574, expected 4519).
Fax4Decode: Warning, debian_g4.tiff: Premature EOL at line 63 of strip 9
(got 72, expected 4519).




i can try the same steps with my own compiled original 3.9.4 tiff
library. they work without errors:

neu$ /home/global/erik/localinst/tiff-3.9.4/bin/tiffcp -c g4
gimpcrop.g3.tiff 3.9.4_g4.tiff

neu$ /home/global/erik/localinst/tiff-3.9.4/bin/tiffcp -c g3
3.9.4_g4.tiff 3.9.4_g3.tiff




as an additional test I try if the debian g4 image is corrupted by
converting it to g3 using the own compiled 3.9.4 tiff library. the
resulting image is not corrupted:

neu$ /home/global/erik/localinst/tiff-3.9.4/bin/tiffcp -c g3
debian_g4.tiff imm.tiff


if i check for duplicates it all seems to be reasonable:

neu$ md5sum *tiff |sort
5ccf6a9ecffbb1bb786a4d533842ef5c  3.9.4_g3.tiff (original)
5ccf6a9ecffbb1bb786a4d533842ef5c  gimpcrop.g3.tiff  (original)
5ccf6a9ecffbb1bb786a4d533842ef5c  imm.tiff  (original)
e9e0c41b94a32bfd620be39c3c2894c7  3.9.4_g4.tiff (good G4)
e9e0c41b94a32bfd620be39c3c2894c7  debian_g4.tiff(good G4)
f2226fb5a0f7a223368789b0bdd88a51  debian_g3.tiff(bad G3)



so to sum it all up:

the debian tiff library is based on the original 3.9.4 (i hope :-) ).
the original 3.9.4 is working.
the debian version is not working.

the not working debian version can create correct G4 images.

the not working debian version can not decode some G4 images.



so if my analysis is not wrong, it would now be up to the debian
maintainer to fix the problem?


cu  thanks!
erik



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

Bug#630042: pixel errors on G4 encoder

[Erik Thiele]

Package: libtiff4
Version: 3.9.4-5+squeeze2


there somehow is a bug in the encoding of COMPRESSION_CCITTFAX4.

it creates corrupted files that can still be partly loaded but contain
image errors.

i trapped into the problem using own coded software but created a
reproduction procedure for using the gimp as an example.

steps to reproduce:

use debian squeeze. gimp version 2.6.10-1, but does probably not matter.
i guess only the libtiff4 version matters.

load the file gimpcrop.g3.tiff (attached to this bugreport) with the
gimp. just do file save as and choose the name mytest.tiff. then
choose G4 compression and save!

you should get a file with the exactly same content than in
gimpcrop.g4.tiff

if you try to load this new file with imagemagick (type display
gimpcrop.g4.tiff or your own mytest.tiff picture...), you will get:

display: gimpcrop.g4.tiff: Bad code word at line 17 of strip 9 (x 0).
`Fax4Decode' @ warning/tiff.c/TIFFErrors/493.
display: gimpcrop.g4.tiff: Premature EOL at line 17 of strip 9 (got 0,
expected 4519). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703.
display: gimpcrop.g4.tiff: Line length mismatch at line 44 of strip 9
(got 4520, expected 4519). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703.
display: gimpcrop.g4.tiff: Line length mismatch at line 53 of strip 9
(got 4574, expected 4519). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703.
display: gimpcrop.g4.tiff: Premature EOL at line 63 of strip 9 (got 72,
expected 4519). `Fax4Decode' @ warning/tiff.c/TIFFWarnings/703.

also you can load the picture with the gimp. same errors. the image will
have a black strip from left to right which should not be there also it
has other errors.


the bug should be easy to reproduce.

thanks
Erik
attachment: gimpcrop.g3.tiffattachment: gimpcrop.g4.tiff

Bug#630042: much quicker way to reproduce

[Erik Thiele]

hi

actually there is a much easier way to reproduce:


bughunt$ tiffcp -c g4 gimpcrop.g3.tiff out.tiff
bughunt$ tiffcp out.tiff lala.tiff
Fax4Decode: out.tiff: Bad code word at line 17 of strip 9 (x 0).
Fax4Decode: Warning, out.tiff: Premature EOL at line 17 of strip 9 (got
0, expected 4519).
Fax4Decode: Warning, out.tiff: Line length mismatch at line 44 of strip
9 (got 4520, expected 4519).
Fax4Decode: Warning, out.tiff: Line length mismatch at line 53 of strip
9 (got 4574, expected 4519).
Fax4Decode: Warning, out.tiff: Premature EOL at line 63 of strip 9 (got
72, expected 4519).
bughunt$




cya
erik



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

Bug#624509: does only send CR LF . instead of CR LF . CR LF on end of smtp transfer

[Erik Thiele]

Package: icedove
Version: 3.0.11-1+squeeze1

i just had an email that has two attachments. message size as reported
in SMTP traffic was roughly about a megabyte. i tried to send it by smtp
the usual way. i tried to restart icedove and each time it behaved
exactly the same way. unfortunately i erased that message now. this is
what happened:

sending the message starts and the progress meter stops at 99%.

when running wireshark and analyzing the TCP traffic, i see that at the
end of the message, icedove sends CR LF . but then does not send
another CR LF as requested by the server. for that reason the server
waits for more data to come. some time later icedove stops with smtp
timeout.

there must be a bug in icedove that makes it stop after the CR LF .
and not send the additional CR LF after that. i'm sorry i cannot give
more debugging information here.

when analyzing TCP traffic of working SMTP sends from icedove it always
sends CR LF . CR LF and then the server responds as expected.


cu
erik



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

Bug#482176: system crash - no nfs mount.

[Erik Thiele]

hi.

after a system crash one of my hosts did not mount nfs anymore.

after some investigation i found out, that /var/run/mountnfs is an
existing empty directory which should be deleted on bootup.

i wanted to report as debian bug and found it already being open.
why is /var/run not completely wiped on boot?


thanks
Erik



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

Bug#577849: not reporting error exit code on trying to stamp postscript input

[Erik Thiele]

Package: pdftk
Version: 1.41-3

echo hi | mpage -1o  input.ps
ps2pdf input.ps input.pdf
echo ho | mpage -1o  stamp.ps

pdftk input.pdf stamp stamp.ps output lala.pdf  echo 
yo   


Error: Failed to open stamp PDF file:
  stamp.ps
  No output created.
yo


^^ see it displayed yo because it did not return an error exit code 
even though an error occured.

that's bad if you try to write scripts...


now i try to just convert ps to pdf:

pdftk input.ps output lala.pdf  echo yo
Error: Failed to open PDF file:
  input.ps
Errors encountered.  No output created.
Done.  Input errors, so no output created.

^^ see, it does not display yo because it correctly reported error 
exit code.




so to sum it up: the bug is that pdftk does not report error code if it 
cannot open stamp input file.



cu
erik



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

Bug#536057: /usr/share/doc/gqview/README compressed as README.gz thus not found by help/about/credits dialog

[Erik Thiele]

Package: gqview
Version: 2.0.4-4

Help / About / Credits:

Unable to load:
/usr/share/doc/gqview/README

because it is compressed as README.gz




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

Bug#497671: Workarounds

[Erik Thiele]

Hello,

Mark Adams had the idea to modify mime.convs to remove the pstops 
program as follows:


comment out:
#application/postscript application/vnd.cups-postscript 66 pstops

replace by:
application/postscript application/vnd.cups-postscript 0 -


now it is possible to print from windows on a3 or a4 paper, which is 
selectable in the windows cups driver.



i hope this helps to debug.
meanwhile i played back my old etch server backup :-)


cya!
erik

--
Erik Thiele

Firma
Horst Thiele Maschinenbau-Hydraulische Geraete GmbH
Im Kampfrad 2 - 74196 Neuenstadt
Tel.: 07139/4801-19
Fax.: 07139/4801-29
email: erik.thi...@thiele-hydraulik.de
Internet: http://www.thiele-hydraulik.de/
Registergericht: Amtsgericht Stuttgart
Handelsregisternummer: HRB 101971

Geschäftsführer:
Dipl.-Ing. (FH) Horst Thiele - FH Nürnberg
Dipl.-Ing. Ewald Thiele - TU Stuttgart




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

Bug#497671: problem still exists

[Erik Thiele]

hello,

i just upgraded our central cups printserver machine from etch to lenny 
and ever since i cannot set page size from windows clients anymore. it 
always prints a4. how can i debug this problem? i find strange that 
nobody replied to this bug yet. maybe it should be marked important 
again? are there so few people with printers that support more than one 
page size and use this printers from windows over samba?



i'd like to do debugging, but i don'T find a starting point

thx
erik



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

Bug#508771: zless wrong output on zero sized files

[Erik Thiele]

Package: gzip
Version: 1.3.5-15


rm foobar
touch foobar
gzip foobar
zless foobar.gz
foobar.gz may be a binary file.  See it anyway?
y
^_8B^H^H^PFEe...@^cfoobar^@^...@^@^...@^@^...@^@^...@^@^@
foobar.gz (END)



cya
erik



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

Bug#491146: workaround

[Erik Thiele]

i modified my /etc/magic as follows to have a workaround for the problem until 
it gets fixed in debian. otherwise our custom software does not work anymore 
because it uses libmagic to determine filetypes :-)


# Magic local data for file(1) command.
# Insert here your local magic data. Format is described in magic(5).

0 string \x89PNG\x0d PNG image



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

Bug#491146: workaround

[Erik Thiele]

you should add another line below...

# Magic local data for file(1) command.
# Insert here your local magic data. Format is described in magic(5).

0 string \x89PNG\x0d PNG image
!:mime image/png



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

Bug#495322: [pkg-boost-devel] Bug#495322: strange error :-) please edit subject

[Erik Thiele]

Am Samstag, 16. August 2008 16:08:15 schrieb Steve M. Robbins:
 On Sat, Aug 16, 2008 at 10:29:47AM +0200, Erik Thiele wrote:
 Note that Boost 1.34.1 is the old version of Boost.  Version 1.35 is
 packaged for Debian, and Boost 1.36 was recently released (Debian
 packages are in progress).

 This code compiles without warnings using libboost-date-time1.35-dev.

pn  libboost-date-time-dev   keine   (keine 
Beschreibung vorhanden)
rc  libboost-date-time1.33.1 1.33.1-10 set of 
date-time libraries based on generic
rc  libboost-date-time1.34.1 1.34.1-11 set of 
date-time libraries based on generic
ii  libboost-date-time1.35-dev   1.35.0-5  set of 
date-time libraries based on generic
ii  libboost-date-time1.35.0 1.35.0-5  set of 
date-time libraries based on generic
ii  g++4:4.3.1-2  The GNU C++ compiler

this is my versions. and i get the presented results. i checked it again.


cya
erik



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

Bug#495322: strange error :-) please edit subject

[Erik Thiele]

Package: libboost-date-time-dev
Version: 1.34.1-11


cat  foo.cpp EOF
#include boost/date_time/posix_time/ptime.hpp

void foo(boost::posix_time::ptime x)
{
  x.date();
}
EOF

g++ -Wall -Werror -O2 -c foo.cpp
cc1plus: warnings being treated as errors
/usr/include/boost/date_time/constrained_value.hpp: In function ‘void 
foo(boost::posix_time::ptime)’:
/usr/include/boost/date_time/constrained_value.hpp:64: 
error: 
‘year.boost::gregorian::greg_year::anonymous.boost::CV::constrained_valueboost::CV::simple_exception_policyshort
 
unsigned int, 1400u, 1u, boost::gregorian::bad_year ::value_’ may be 
used uninitialized in this function
/usr/include/boost/date_time/gregorian_calendar.ipp:122: 
note: 
‘year.boost::gregorian::greg_year::anonymous.boost::CV::constrained_valueboost::CV::simple_exception_policyshort
 
unsigned int, 1400u, 1u, boost::gregorian::bad_year ::value_’ was 
declared here



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

Bug#493059: nfs with more than 16 groups. --manage-gids

[Erik Thiele]

Package: nfs-kernel-server
Version: 1.0.10-6+etch.1
Severity: Wishlist

Hi,

The NFS protocol cannot transfer more than 16 groups which a user is member 
of. so when you have some directories that you can only access as member of a 
special group and you are in more than 16 groups, then access to that 
directories will not be granted.

This is extremly hard to debug. I had this problem myself for several years 
now and worked around it by running applications by ssh -X on servers instead 
of on clients.

The last days i wrote several debugging programs and finally found out, that 
depending on the amount of groups i am in, access will be granted or not. 
then suddenly i found information on the internet. there users said they also 
had such problems for years. some even claim they switched back to 
windows :-)

The problem here definitly is that there is no information. you don't even 
find anything in nfs manpages or in configuration files.

i think it is pretty common to be member of more than 16 groups today.

It should be noted, that the problem exists in all versions of nfs, also in 
nfs4. i tested it.

The only chance to get away with that problem is to add the --manage-gids 
option or -g to rpc.mountd. then it works - again in all nfs versions. also 
nfs4.

I would say that option should be the default, but i found a debian bug report 
saying that then mac os x hangs on mounting that share. that should be 
checked.

So my wish is:

1) the kernel (i don't know if client or server) MUST put some error message 
in the syslog like nfs client: can only transfer 16 member groups. dropping 
some groups. expect random failures. Add --manage-gids to rpc.mountd or so. 
Just a hint that there is something going wrong and what to google for! 
instead you are left alone without any kind of information at all. that's 
really bad!

2) --manage-gids should be default option

3) nfs in debian-etch should also support --manage-gids, not just in debian 
lenny.


cya!
erik



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

Bug#477999: screen script startx checks for XFCFG variable in wrong way.

[Erik Thiele]

Package: ltsp-server
Version: 5.0.40~bzr20080319-1

/opt/ltsp/i386/usr/share/ltsp/screen.d/startx:

# If XFCFG is defined then attempt to use it instead of autoconfiguration
if [ -e ${XFCFG} ]; then
XF_ARGS=$XF_ARGS -config ${XFCFG}
fi

this code is wrong. it adds -config without anything behind it, if XFCFG is 
unset. thus i get a X calling line like this:

X -query 192.168.1.1 -config -terminate vt11 :10.0

obviously either -config must be gone or the filename of a configfile has to 
be passed.

this code would probably work better:


# If XFCFG is defined then attempt to use it instead of autoconfiguration
if [ -z ${XFCFG} ]; then
true
else
if [ -e ${XFCFG} ]; then
XF_ARGS=$XF_ARGS -config ${XFCFG}
fi
fi


thx
cya
erik



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

Bug#473888: cups does not print multi file jobs remotely

[Erik Thiele]

Package: cupsys
Version: 1.2.7-4etch3
Severity: Important

Severity is important, because Key functionality is not working is set in 
the corresponding CUPS bug tracking system. see below.


echo first file | mpage  first.ps
echo second file | mpage  second.ps

on a machine that is running cups locally and the printers are attached 
locally, you can do:

lp first.ps second.ps

and both files get printed.


but let's say you have 2 machines. Both are running cups. they are connected 
by browsing. the server machine has the printer attached locally. now on the 
client you do

lp first.ps second.ps

just nothing happens. he sais that a job is created, but nothing happens.
if instead you do

lp first.ps
lp second.ps

then both get printed correctly.

the same issue applies if you print your jobs with kprinter from the kde 
project and probably all other cups printing interfaces.

on this page (CUPS STR #2673) you see a report about that problem.
http://www.cups.org/str.php?L2673

the things described there show exactly the same phenomenon. also the logfile 
they show there closely matches the one i have. the IPP backend gets not even 
started.



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

Bug#443280: wrong path specified in manpage

[Erik Thiele]

Package: mpage
Version: 2.5.4-2

/usr/share/man/man1/mpage.1.gz

sais that /usr/share/mpage is the mpage library directory twice in the 
manpage. there should be encoding files stored there it sais.

but the directory /usr/share/mpage is empty

instead /usr/lib/mpage is filled with the files in question.

either files should be moved, or documentation corrected



thx for all the work

cya
erik



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

Bug#443280: codepages are not found

[Erik Thiele]

sorry, it's not just a bug in the manpage, but also in the installation. see:

[EMAIL PROTECTED]:/tmp$ mpage -CISO-8859.1  /dev/null /dev/null
/usr/share/mpage/ISO-8859.1: No such file or directory
[EMAIL PROTECTED]:/tmp$ mpage -C../../../usr/lib/mpage/ISO-8859.1  /dev/null 
/dev/null
[EMAIL PROTECTED]:/tmp$   

cya
erik



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

Bug#438205: race condition: kdeprint sometimes fails on printing jobs which are removed after kdeprint exits

[Erik Thiele]

Package: kdeprint
Version: 3.5.5a.dfsg.1-6

i have a shellscript:

#!/bin/sh
create-pdf a0.pdf
create-pdf a1.pdf
create-pdf a2.pdf
create-pdf a3.pdf
create-pdf a4.pdf
create-pdf a5.pdf
create-pdf a6.pdf
create-pdf a7.pdf
create-pdf a8.pdf
create-pdf a9.pdf
kprinter a0.pdf a1.pdf a2.pdf a3.pdf a4.pdf a5.pdf a6.pdf a7.pdf a8.pdf a9.pdf
rm a0.pdf a1.pdf a2.pdf a3.pdf a4.pdf a5.pdf a6.pdf a7.pdf a8.pdf a9.pdf

the user selects a cups printer in the dialog and prints the files.
normally this works. (did it about 30 times now)

and now suddenly a messagebox appeared:

KNotify:
cupsdoprint failed...
do not find file a0.pdf

when i check the existence of a0.pdf i find that it is gone in the moment this 
popup appears.

this means that kprinter exits BEFORE a0.pdf was read.

that is a race condition and IMHO should be fixed, because this kind of script 
is not unusual. every temporary print job is printed like this, for example: 
i am using some c++ program to create pdf stock report files and print them 
by a user configurable program like lpr or kprinter. when that user 
configurable printing program exits, the c++ program immediately removes the 
temporary pdfs from harddisk again of course. i really think this should work 
reliably. otherwise one would have to arrange for a timer which deletes the 
temporary files after 10 seconds - which in itself is again a race 
condition...

cya!
erik

-- 
Erik Thiele


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

Bug#435323: invalid option --mbox to clamscan

[Erik Thiele]

Package: kmail
Version: 3.5.5.dfsg.1-6
Severity: important

package clamav in version 0.90.1-3etch4 contains the program clamscan
package kmail contains program kmail_clamav.sh

if you configure kmail to scan incoming email for viruses, it automatically 
adds filter rules for clamav by using the kmail_clamav.sh script.

kmail_clamav.sh calls clamscan with the --mbox option in case there is no 
clamd running. the --mbox option does not exist though.

please remove --mbox option



thx
cya
erik


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

Bug#435325: silently letting viruses through in case clamd is not (yet) running

[Erik Thiele]

Package: kmail
Version: 3.5.5.dfsg.1-6
Severity: important

package clamav-daemon  in version 0.90.1-3etch4 contains program clamdscan
package kmail contains program kmail_clamav.sh

if you configure kmail to scan incoming email for viruses, it automatically 
adds filter rules for clamav by using the kmail_clamav.sh script.

when clamd is starting, it takes about 3 minutes until it is running.

so when a typical user starts his computer, loggs in to KDE, starts kmail, 
receives email, then all viruses silently pass through because 
kmail_clamav.sh just sais X-Virus-Flag: No in case clamdscan fails. and 
clamdscan fails in case clamd is not yet running. clamd is not yet running 
because it takes 3 minutes on each first start.

i think it is a fundamental problem with kmail filter scripts that they cannot 
report errors. if you add output to stderr in a kmail filter script and then 
return a error code, if you check the filter log in kmail, you see that the 
filter failed. but if you do not check the log, the filter just silently 
fails.

but it also is not a solution to change kmail_clamav.sh so that if anything 
fails it always adds X-Virus-Flag: Yes.

maybe kmail_clamav.sh should add a big header to the email saying that the 
virus check failed and it is unsure if this email contains a virus or not.


but the current behaviour of just silently passing unchecked data is not 
really good...



thx
cya
erik


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

Bug#408219: [pkg-ntp-maintainers] Bug#408219: ntpd giving up on eth0 before it is initialized

[Erik Thiele]

Am Dienstag, 10. April 2007 22:27 schrieben Sie:
 Erik Thiele wrote:
  the problem now is that the dhclient sets networking parameters after
  ntpd has already started. dhclient won't restart ntpd because
  configuration hasn't changed.

 So what is the actual problem?  ntp.conf.dhcp is not created, or it
 doesn't contain the right information, or ntpd is not restarted?

ntpd is not restarted is the problem.


  this way ntpd will fail on the ip
  adress because the ethernet is down.

 Why would the ethernet be down after calling dhclient?  An why is that
 ntpd's fault?

the ethernet was down before dhclient. ntpd decided that the ntp host is down, 
and will not rethink this decission just because the ethernet gets up at some 
point in time.


1)  from a former run i have correct data in ntpd.conf.dhcp

2)  ntpd is running, but networking is not yet brought up, dhcp requests are 
not yet replied by the server.

3) ntpd thus tries to contact my old ntp.my.lan server, and finds out that 
this does not work. it now decides that the server is broken.

4) dhclient activates networking and finds out that ntpd.conf.dhcp is not 
changed, so he does not restart ntpd

5) but ntpd has already decided that the ethernet does not work and will never 
rethink it's decission and stay in this mode forever:

ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
 wo.x.lan .INIT.  16 --   6400.0000.000   0.000

6) i manually restart ntpd and it instantly works.


 if the configuration file ntpd.conf.dhcp has not changed on dhcp 
startup, then anyway ntpd has to be restarted because the actual difference 
between before and after dhclient run is that before the ethernet is down and 
the host unreachable, and afterwards the ethernet is up and the host is 
reachable.



cya
erik


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

Bug#416355: inconsistent behaviour regarding .lock extension

[Erik Thiele]

Package: lockfile-progs
Version: 0.1.10

the program lockfile-create automatically adds the .lock extension to the 
supplied filename. but it does not talk about that in its manpage.

the C function lockfile_create does NOT add a .lock extension.

(the program dotlockfile does NOT add .lock extension and even explicitly sais 
this in its manpage.)


I had bad experiences which made me find this bug:

i wrote a C program which locks a directory using a lockfile. in order to be 
consistent i wanted to use some library and found liblockfile.

then i wrote a shellscript which should interact with the C-program. it must 
also lock the directory with the same lockfile of course. so i found 
lockfile-progs and expected it to have the same behaviour as the c function 
it uses. and bang there was the problem:

lockfile_create(foobar,10,0); - creates foobar
lockfile-create foobar - creates foobar.lock


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

Bug#408218: somehow loosing valid dhcp adress on ethernet interface

[Erik Thiele]

Package: avahi-daemon
Version: 0.6.15-2

i have a problem. it dissappears when i deinstall avahi-daemon, and it 
reappears when i install avahi-daemon. i am currently running updated debian 
etch distribution.

directly after booting the system, i see that the ethernet network interface 
is badly configured. i can repair the situation by doing
/etc/init.d/networking stop ; /etc/init.d/networking start
OR
ifdown eth0 ; ifup eth0
OR
dhclient eth0
OR
deinstall avahi-daemon and reboot system

you see in my pasted files below, that the dhclient gets the right adress, but 
somehow it must get deleted again in a strange way.



cya
erik



CONTENT OF FILE _etc_network_interfaces FOLLOWS

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

CONTENT OF FILE ifconfig FOLLOWS

eth0  Protokoll:Ethernet  Hardware Adresse 00:13:8F:11:E8:3C  
  inet Adresse:169.254.48.28  Bcast:169.254.255.255  Maske:255.255.0.0
^^HERE WRONG ADRESS!
  inet6 Adresse: fe80::213:8fff:fe11:e83c/64 
Gültigkeitsbereich:Verbindung
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1026 errors:0 dropped:0 overruns:0 frame:0
  TX packets:389 errors:0 dropped:0 overruns:0 carrier:0
  Kollisionen:0 Sendewarteschlangenlänge:1000 
  RX bytes:141672 (138.3 KiB)  TX bytes:33817 (33.0 KiB)
  Interrupt:185 Basisadresse:0xd400 

loProtokoll:Lokale Schleife  
  inet Adresse:127.0.0.1  Maske:255.0.0.0
  inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:74 errors:0 dropped:0 overruns:0 frame:0
  TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
  Kollisionen:0 Sendewarteschlangenlänge:0 
  RX bytes:5936 (5.7 KiB)  TX bytes:5936 (5.7 KiB)

CONTENT OF FILE ip_a FOLLOWS

1: lo: LOOPBACK,UP,1 mtu 16436 qdisc noqueue 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:13:8f:11:e8:3c brd ff:ff:ff:ff:ff:ff
inet 169.254.48.28/16 brd 169.254.255.255 scope global eth0
^ ALSO WRONG ADRESS
inet6 fe80::213:8fff:fe11:e83c/64 scope link 
   valid_lft forever preferred_lft forever
3: sit0: NOARP mtu 1480 qdisc noop 
link/sit 0.0.0.0 brd 0.0.0.0

CONTENT OF FILE ip_r FOLLOWS

169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.48.28 
^^ ALSO WRONG ADRESS

CONTENT OF FILE _var_log_boot FOLLOWS
(yes i activated bootlogd)

Wed Jan 24 07:39:28 2007: .
Wed Jan 24 07:39:28 2007: Activating swap...done.
Wed Jan 24 07:39:28 2007: Checking root file system...fsck 1.40-WIP 
(14-Nov-2006)
Wed Jan 24 07:39:28 2007: Filesystem seems mounted read-only. Skipping journal 
replay.
Wed Jan 24 07:39:28 2007: Checking internal tree..finished
Wed Jan 24 07:39:28 2007: Reiserfs super block in block 16 on 0x303 of format 
3.6 with standard journal
Wed Jan 24 07:39:28 2007: Blocks (total/free): 18189596/3030221 by 4096 bytes
Wed Jan 24 07:39:28 2007: Filesystem is clean
Wed Jan 24 07:39:28 2007: Reiserfs super block in block 16 on 0x303 of format 
3.6 with standard journal
Wed Jan 24 07:39:28 2007: Blocks (total/free): 18189596/3030221 by 4096 bytes
Wed Jan 24 07:39:28 2007: Filesystem is clean
Wed Jan 24 07:39:28 2007: done.
Wed Jan 24 07:39:28 2007: Setting the system clock again..
Wed Jan 24 07:39:29 2007: Cleaning up ifupdown
Wed Jan 24 07:39:29 2007: Loading kernel modules...done.
Wed Jan 24 07:39:29 2007: Loading device-mapper support.
Wed Jan 24 07:39:29 2007: Checking file systems...fsck 1.40-WIP (14-Nov-2006)
Wed Jan 24 07:39:29 2007: /dev/hda1: clean, 33/124928 files, 37375/497980 
blocks
Wed Jan 24 07:39:29 2007: done.
Wed Jan 24 07:39:29 2007: Setting kernel variables...done.
Wed Jan 24 07:39:29 2007: Mounting local filesystems...done.
Wed Jan 24 07:39:29 2007: Activating swapfile swap...done.
Wed Jan 24 07:39:29 2007: Setting up networking
Wed Jan 24 07:39:29 2007: Configuring network interfaces...Internet Systems 
Consortium DHCP Client V3.0.4
Wed Jan 24 07:39:30 2007: Copyright 2004-2006 Internet Systems Consortium.
Wed Jan 24 07:39:30 2007: All rights reserved.
Wed Jan 24 07:39:30 2007: For info, please visit http://www.isc.org/sw/dhcp/
Wed Jan 24 07:39:30 2007: 
Wed Jan 24 07:39:31 2007: Listening on LPF/eth0/00:13:8f:11:e8:3c
Wed Jan 24 07:39:31 2007: Sending on   LPF/eth0/00:13:8f:11:e8:3c
Wed Jan 24 07:39:31 2007: Sending on   Socket/fallback
Wed Jan 24 07:39:33 2007: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 
interval 5
Wed Jan 24 07:39:33 2007: DHCPOFFER from 192.168.30.9
Wed Jan 24 07:39:33 2007: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Wed Jan 24 07:39:33 2007: DHCPACK from 192.168.30.9
Wed Jan 24 07:39:33 2007: bound to 192.168.30.62 -- renewal in 17883 seconds.

Bug#408219: ntpd giving up on eth0 before it is initialized

[Erik Thiele]

Package: ntp
Version: 4.2.2.p4+dfsg-1

my ethernet is configured via dhcp:

goofy:/etc# cat network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

i added
request ntp-servers;
to /etc/dhcp3/dhclient.conf

so that ntpd.conf.dhcp gets created. see bug #407667.

the problem now is that the dhclient sets networking parameters after ntpd has 
already started. dhclient won't restart ntpd because configuration hasn't 
changed. this way ntpd will fail on the ip adress because the ethernet is 
down. it will remain like this forever:

ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
 wo.x.lan .INIT.  16 --   6400.0000.000   0.000

if i restart ntpd it will work.


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

Bug#408218: installed packages

[Erik Thiele]

the state of installed packages remained the same all over my tests. the only 
thing i did was purge and reinstall and purge the avahi-daemon package.

~$ dpkg -l zeroconf
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: 
GROSS=schlecht)
||/ Name   VersionBeschreibung
+++-==-==-
un  zeroconf   keine(keine Beschreibung vorhanden)

~$ dpkg -l *avahi*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: 
GROSS=schlecht)
||/ Name   VersionBeschreibung
+++-==-==-
un  avahi-autoipd  keine(keine Beschreibung vorhanden)
pn  avahi-daemon   keine(keine Beschreibung vorhanden)
ii  libavahi-clien 0.6.15-2   Avahi client library
ii  libavahi-commo 0.6.15-2   Avahi common data files
un  libavahi-commo keine(keine Beschreibung vorhanden)
ii  libavahi-commo 0.6.15-2   Avahi common library
ii  libavahi-compa 0.6.15-2   Avahi Howl compatibility library
ii  libavahi-compa 0.6.15-2   Avahi Apple Bonjour compatibility library
un  libavahi-core3 keine(keine Beschreibung vorhanden)
rc  libavahi-core4 0.6.15-2   Avahi's embeddable mDNS/DNS-SD library
ii  libavahi-glib1 0.6.15-2   Avahi glib integration library
ii  libavahi-qt3-1 0.6.15-2   Avahi Qt3 integration library

Bug#407667: dhclient not requesting ntp-servers by default

[Erik Thiele]

Package: dhcp3-client
Version: 3.0.4-12

when i install the ntp package, it creates

/etc/dhcp3/dhclient-enter-hooks.d/ntp

that script works well, but dhclient by default does not request the
ntp servers list. so the script will do nothing.

problem can be fixed without side effects, if the following is changed
in /etc/dhcp3/dhclient.conf:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope, interface-mtu,
ntp-servers;   ---!!!


cya  thanks for all the work
erik


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

Bug#407408: /etc/samba/dhcp.conf only created on change of wins server, but not initially

[Erik Thiele]

Package: samba
Version: 3.0.23d-2+b1

The file /etc/samba/dhcp.conf is included from your smb.conf file to
get the wins server by DHCP. This is done by the
script /etc/dhcp3/dhclient-enter-hooks.d/samba. There are three issues
with this script:

1) when i CHANGE the netbios-name-servers in my dhcp server and then
do a ifdown and ifup to launch dhclient, then the script creates the
samba dhcp.conf file correctly. but if i run my system for some time
and then decide to install the samba package, the dhclient script will
NOT create the dhcp.conf file, because no change in
netbios-name-servers has occured since the last run of dhclient.


2) when first creating the file /etc/samba/dhcp.conf, the script prints
the error message: 

sed: can't read /etc/samba/dhcp.conf: No such file or directory

Maybe a message like creating dhcp.conf from scratch because it is
missing or even no message at all would be better.


3) in case of a change in /etc/samba/dhcp.conf, the script should let
the samba server reload its configuration files, otherwise the change
is ignored by the samba server.



cya  thx for all the work
erik


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

Bug#398419: manpage of kernel-img.conf is missing

[Erik Thiele]

Package: grub
Version: 0.97-19

manpage of update-grub sais that i should read
the manpage of kernel-img.conf. but that one does not exist.


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

Bug#398420: get_password function not found

[Erik Thiele]

Package: reportbug
Version: 3.30

Connecting to smtp.deleted.com via SMTP...
Traceback (most recent call last):
  File /usr/bin/reportbug, line 1745, in ?
main()
  File /usr/bin/reportbug, line 777, in main
return iface.user_interface()
  File /usr/bin/reportbug, line 1736, in user_interface
smtphost, self.options.smtpuser, self.options.smtppasswd, 
self.options.paranoid)
  File /usr/share/reportbug/reportbug_submit.py, line 366, in send_report
smtppasswd = ui.get_password(
AttributeError: 'module' object has no attribute 'get_password'

in configuration i said, that i don't have local email system.
i specified smtp server of my provider and also
i specified my username, but no password since it did not ask.

when reportbug offers to send the report, the shown error message appears.

i use that python-urwid interface.


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