Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Nice find! And yes, I can confirm that it works for me too. Would be great to see these fixes make it into bookworm. - Markus Am 29.03.23 um 17:48 schrieb Mark Hindley: This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me when invoked as pidof $(which vi) Markus, can you confirm that works for you? Since it is a regression since bullseye, it seems a suitable targeted fix to attempt for bookworm. Thanks to everybody. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I did a few more tests of my own and didn't find any other issues.
- Markus
Am 24.03.23 um 15:17 schrieb Jesse Smith:
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch looks good to me. I'm adding it upstream.
Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.
- Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch gets rid of this uninitialised value warning I saw in valgrind:
==4158== Conditional jump or move depends on uninitialised value(s)
==4158==at 0x484748D: strcmp (vg_replace_strmem.c:924)
==4158==by 0x10A64F: pidof (killall5.c:797)
==4158==by 0x10B2EE: main_pidof (killall5.c:1031)
==4158==by 0x109700: main (killall5.c:1108)
==4158== Uninitialised value was created by a heap allocation
==4158==at 0x4840660: malloc (vg_replace_malloc.c:381)
==4158==by 0x10AD51: xmalloc (killall5.c:170)
==4158==by 0x10AD51: readproc (killall5.c:664)
==4158==by 0x10B2A0: main_pidof (killall5.c:1028)
==4158==by 0x109700: main (killall5.c:1108)
I compiled the killall5 binary with:
CFLAGS="-O2 -ggdb" make killall5
Am 23.03.23 um 16:25 schrieb Jesse Smith:
On 2023-03-23 12:04 p.m., Markus Fischer wrote:
I could also reproduce it with emacs. I've used emacs-gtk to avoid the
symlink.
```shell 1
$ emacs-gtk -nw -fn helvetica
```
```shell 2
$ ./pidof emacs-gtk
24727
$ ./pidof $(which emacs-gtk)
$ ls -l $(which emacs-gtk)
-rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk
```
This is interesting. Is there anything else you can share that might
shed light on why this happens while I can't get the same results? You
mentioned you're using two separate shells. Are they with the same user
account? Is there any PID hiding feature of Debian enabled? Does it
still happen if you run "pidof -z $(which emacs-gtk)"?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I could also reproduce it with emacs. I've used emacs-gtk to avoid the symlink. ```shell 1 $ emacs-gtk -nw -fn helvetica ``` ```shell 2 $ ./pidof emacs-gtk 24727 $ ./pidof $(which emacs-gtk) $ ls -l $(which emacs-gtk) -rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk ``` Am 23.03.23 um 15:50 schrieb Jesse Smith: On 2023-03-23 11:36 a.m., Markus Fischer wrote: Alright. Then there is still the issue with gdb, which is no symlink. A full example for that: ```shell 1 $ type gdb gdb is /usr/bin/gdb $ gdb --core=corefile ``` ```shell 2 $ ./pidof gdb 23125 $ ./pidof $(which gdb) $ ls -l $(which gdb) -rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb This one I have not been able to duplicate. Does it happen with any other programs which accept arguments or just gdb?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Alright. Then there is still the issue with gdb, which is no symlink. A full example for that: ```shell 1 $ type gdb gdb is /usr/bin/gdb $ gdb --core=corefile ``` ```shell 2 $ ./pidof gdb 23125 $ ./pidof $(which gdb) $ ls -l $(which gdb) -rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb ``` Am 23.03.23 um 15:25 schrieb Jesse Smith: On 2023-03-23 11:20 a.m., Markus Fischer wrote: ```shell 1 $ type vi vi is /usr/bin/vi $ vi ``` ```shell 2 $ cd ~/src/sysvinit-upstream/src/ $ ls -l pidof lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5 $ ./pidof vi 21945 $ ./pidof $(which vi) $ ls -l $(which vi) lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> /etc/alternatives/vi $ ls -l /etc/alternatives/vi lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> /usr/bin/vim.tiny $ ls -l /usr/bin/vim.tiny -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny Okay, yes, this makes sense. The symbolic links are making multiple jumps so it won't work. This is expected behaviour because there is no executable running called /usr/bin/vi or /etc/alternatives/vi. Running "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't follow aliases or symbolic links with multiple hops and different names.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
```shell 1 $ type vi vi is /usr/bin/vi $ vi ``` ```shell 2 $ cd ~/src/sysvinit-upstream/src/ $ ls -l pidof lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5 $ ./pidof vi 21945 $ ./pidof $(which vi) $ ls -l $(which vi) lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> /etc/alternatives/vi $ ls -l /etc/alternatives/vi lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> /usr/bin/vim.tiny $ ls -l /usr/bin/vim.tiny -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny ``` Am 23.03.23 um 15:03 schrieb Jesse Smith: Could you give a full example of pidof not detecting the vi process? I did all my testing as a regular user and both regular executables and symlinks are showing up in pidof process listings. With and without arguments. The only thing I can think of which would throw this off would be if the program being run was an alias. For example, if "vi" was an alias to "vim" rather than a symlink. On 2023-03-23 3:38 a.m., Markus Fischer wrote: I can confirm Mark's observation that "pidof $(which vi)" still does not work, at least when vi is running as normal user. However, when I run vi as root both pidof 3.06 and 3.07 work as expected. Also my 2nd issue (which might have gone unnoticed because I didn't cc anybody) is still open. I'm going to paste it here again: I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected. I also noticed that as with vi above, when gdb was run as root "pidof $(which gdb)" works as expected with both 3.06 and 3.07. - Markus Am 22.03.23 um 16:38 schrieb Jesse Smith: On 2023-03-22 8:31 a.m., Mark Hindley wrote: Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. However, on Debian Bullseye the behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? I made a fix for this and have pushed it to the 3.07 branch of the SysV init repository. I'll publish a new version in a couple of days with this fix. There were some other changes to killall5 which are also in the queue, so this will fix a few issues. Would be great to have someone check the updated pidof and report if it's working okay for them too. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I can confirm Mark's observation that "pidof $(which vi)" still does not work, at least when vi is running as normal user. However, when I run vi as root both pidof 3.06 and 3.07 work as expected. Also my 2nd issue (which might have gone unnoticed because I didn't cc anybody) is still open. I'm going to paste it here again: I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected. I also noticed that as with vi above, when gdb was run as root "pidof $(which gdb)" works as expected with both 3.06 and 3.07. - Markus Am 22.03.23 um 16:38 schrieb Jesse Smith: On 2023-03-22 8:31 a.m., Mark Hindley wrote: Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. However, on Debian Bullseye the behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? I made a fix for this and have pushed it to the 3.07 branch of the SysV init repository. I'll publish a new version in a couple of days with this fix. There were some other changes to killall5 which are also in the queue, so this will fix a few issues. Would be great to have someone check the updated pidof and report if it's working okay for them too. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). However, on Debian Bullseye the behaviour is as I expected it. Steps to reproduce: * start vi * in another shell run "pidof vi" and "pidof $(which vi)" Result: The first pidof invocation correctly returns a pid but the second invocation does not. Expected result: Both invocations of pidof should return a pid. -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 6.1.0-6-686-pae (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sysvinit-utils depends on: ii libc6 2.36-8 sysvinit-utils recommends no packages. sysvinit-utils suggests no packages. -- no debconf information
Bug#829531: icedove: Icedove closes abruptly
Package: icedove Version: 1:45.1.0-1~deb8u1 Followup-For: Bug #829531 Dear Maintainer, * What led up to the situation? Crash (segfault). * What exactly did you do (or not do) that was effective (or ineffective)? Changing folders, deleting mails or icedove simply waiting in background. * What was the outcome of this action? Unperdictable crashes... * What outcome did you expect instead? Normal function Attached is a gdb.log (crash while doing nothing...) Markus Fischer -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.4+b1 ii fontconfig2.11.0-6.3 ii libasound21.0.28-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18+deb8u4 ii libcairo2 1.14.0-2.1+deb8u1 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-2 ii libffi6 3.1-2+b2 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+deb8u5 ii libglib2.0-0 2.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libhunspell-1.3-0 1.3.3-3 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpixman-1-0 0.32.6-3 ii libstartup-notification0 0.12-4 ii libstdc++64.9.2-10 ii libx11-6 2:1.6.2-3 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxrender1 1:0.9.8-1+b1 ii libxt61:1.1.4-1+b1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii hunspell-de-at [hunspell-dictionary] 20131206-5 ii hunspell-de-ch [hunspell-dictionary] 20131206-5 ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii iceowl-extension 1:45.1.0-1~deb8u1 ii myspell-de-de [myspell-dictionary]20131206-5 Versions of packages icedove suggests: ii fonts-lyx 2.1.2-2 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2 MOZILLA_FIVE_HOME=/usr/lib/icedove LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove DISPLAY=:0.0 DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove LIBRARY_PATH= SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove LIBPATH=/usr/lib/icedove:/usr/lib/icedove ADDON_PATH= MOZ_PROGRAM=/usr/lib/icedove/icedove-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger= moz_debugger_args= /usr/bin/gdb --args /usr/lib/icedove/icedove-bin GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done. done. (gdb) run Starting program: /usr/lib/icedove/icedove-bin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe7f23700 (LWP 12552)] [Thread 0x7fffe7f23700 (LWP 12552) exited] (icedove:12547): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (icedove-bin:12547): Gdk-WARNING **: locale not supported by C library [New Thread 0x7fffe7f23700 (LWP 12554)] [New Thread 0x7fffe0bff700 (LWP 12555)] [New Thread 0x77fee700 (LWP 12556)] [New Thread 0x7fffe03fe700 (LWP 12557)] [New Thread 0x7fffdf8ff700 (LWP 12558)] [New Thread 0x7fffdf6fe700 (LWP 12559)] [New Thread 0x7fffdf4fd700 (LWP 12560)] [New Thread 0x7fffdf2fc700 (LWP 12561)] [New Thread 0x7fffdf0fb700 (LWP 12562)] [New Thread 0x7fffdeefa700 (LWP 12563)] [New Thread 0
Bug#615160: dbmail: imap daemon sends ')\r\n' after message
Package: dbmail Version: 2.2.11-1+b1 Severity: important Under certain circumstances the imap server sends ')\r\n' after messages which confuses some clients. This was fixed in 2.2.17 , see http://dbmail.org/mantis/view.php?id=849 . I experiences this problem with imapcopy which lead to missing messages during the transfer, here's the imapcopy output: reading message 695Skipped: )\r\nA092E OK Completed\r\n reading message 778Skipped: )\r\nA0A27 OK Completed\r\n reading message 805Skipped: )\r\nA0A78 OK Completed\r\n reading message 921Skipped: )\r\nA0BD4 OK Completed\r\n reading message 966Skipped: )\r\nA0C5B OK Completed\r\n reading message 968Skipped: )\r\nA0C61 OK Completed\r\n reading message 1064Skipped: )\r\nA0D81 OK Completed\r\n reading message 1102Skipped: )\r\nA0DF3 OK Completed\r\n -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-vserver-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dbmail depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgmime-2.0-2a 2.2.25-2 MIME library ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries ii libsieve2-1 2.2.6-1 a library for parsing, sorting and ii libsqlite3-03.7.3-1 SQLite 3 shared library ii ucf 3.0025+nmu1 Update Configuration File: preserv ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dbmail recommends no packages. Versions of packages dbmail suggests: ii dbmail-mysql 2.2.11-1+b1 MySQL module for Dbmail pn sqlite3 none (no description available) -- debconf information: dbmail/dbmail/pass: (password omitted) dbmail/ldap/bind_pw: (password omitted) dbmail/start_imapd: dbmail/dbmail/host: dbmail/ldap/field_cid: dbmail/dbmail/postmaster: postmaster@ dbmail/ldap/base_dn: dbmail/do_debconf: dbmail/start_lmtpd: dbmail/ldap/port: dbmail/ldap/hostname: dbmail/dbmail/user: dbmail/start_pop3d: dbmail/dbmail/authdriver: sql dbmail/ldap/bind_anonymous: dbmail/ldap/bind_dn: dbmail/ldap/field_uid: dbmail/start_sieve: dbmail/dbmail/db: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606308: clamd segfaults immediately after launch too
Same problem here, I've had set Bytecode to Paranoid which made the daemon crash. I've now set it to TrustSigned and clamav-daemon runs again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604962: citadel-server: Migration tool ctdlmigrate not included in the package
Package: citadel-server Version: 7.83-2 Severity: important Dear citadel maintainers, I need to migrate my citadel database from my current computer system to another. For that purpose, I'd like to use the migration tool ctdlmigrate which is mentioned on http://www.citadel.org/doku.php/faq:systemadmin:how_do_i_move_citadel_to_another_host?s=ctdlmigrate . Unfortunately, this tool seems not to be included in the Debian packages for squeeze. Could you please change that situation? Regards, Markus -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages citadel-server depends on: ii adduser 3.112add and remove users and groups ebconf [debconf-2.0] 1.5.36 Debian configuration management sy ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcitadel2 7.83-1 Citadel toolbox ii libcurl37.21.0-1 Multi-protocol file transfer libra ii libdb4.84.8.30-2 Berkeley v4.8 Database Libraries [ ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libical00.44-3 iCalendar library implementation i ii libldap-2.4-2 2.4.23-6 OpenLDAP libraries ii libncurses5 5.7+20100313-4 shared libraries for terminal hand ii libpam0g1.1.1-6.1Pluggable Authentication Modules l ii libsieve2-1 2.2.6-1 a library for parsing, sorting and ii libssl0.9.8 0.9.8o-3 SSL shared libraries ii openssl 0.9.8o-3 Secure Socket Layer (SSL) binary a ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages citadel-server recommends: ii db4.6-util4.6.21-16 Berkeley v4.6 Database Utilities ii shared-mime-info 0.71-3 FreeDesktop.org shared MIME databa Versions of packages citadel-server suggests: ii citadel-mta [mail-transport-a 7.83-2 complete and feature-rich groupwar -- Configuration Files: /etc/citadel/mail.aliases changed: bbs,room_aide root,room_aide Auto,room_aide postmaster,room_aide abuse,room_aide mailer-daemon,postmaster nobody,room_aide hostmaster,room_aide usenet,room_aide news,room_aide webmaster,room_aide www,room_aide ftp,room_aide noc,room_aide security,room_aide /etc/citadel/messages/aideopt [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/aideopt' /etc/citadel/messages/changepw [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/changepw' /etc/citadel/messages/dotopt [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/dotopt' /etc/citadel/messages/entermsg [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/entermsg' /etc/citadel/messages/entopt [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/entopt' /etc/citadel/messages/goodbye [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/goodbye' /etc/citadel/messages/hello [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/hello' /etc/citadel/messages/help [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/help' /etc/citadel/messages/mainmenu [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/mainmenu' /etc/citadel/messages/newuser [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/newuser' /etc/citadel/messages/readopt [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/readopt' /etc/citadel/messages/register [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/register' /etc/citadel/messages/roomaccess [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/roomaccess' /etc/citadel/messages/unlisted [Errno 13] Keine Berechtigung: u'/etc/citadel/messages/unlisted' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553580: dpkg: Unable to alter IO priority when running inside a vserver
Package: dpkg Version: 1.15.4.1 Severity: normal When running inside a vserver, the capability to alter the IO priority may not be available. Currently, due the daily cron job configuration, I get an email from the system every day: -8-- Subject: Cron r...@testing01 test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) /etc/cron.daily/man-db: start-stop-daemon: Unable to alter IO priority to mask 24583 (Operation not permitted) run-parts: /etc/cron.daily/man-db exited with return code 2 -8-- I cannot find a way to disable this specific message thus I think that's a bug. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 7.4-2 The GNU core utilities ii libc6 2.9-25 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.23.1 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502214: vnc4server asks for password even when -SecurityTypes None used
Hi, Ola Lundqvist wrote: Where is this option described? On Tue, Oct 14, 2008 at 05:15:57PM +0200, Markus Fischer wrote: Upon the first launch, vnc4server with the option '-SecurityTypes None' still asks for a password, even though I specified no authentication to be used. vnc4server passes unknown options down to Xvnc, however in this case it should be aware of it, see this code: The vnc4server man page says In addition to the options listed below, any unrecognised options will be passed to Xvnc - see the Xvnc man page, or Xvnc -help for details. The Xvnc man page says -SecurityTypes sec-types Specify which security schemes to use separated by commas. At present only None and VncAuth are supported. The default is VncAuth - note that if you want a server which does not require a password, you must set this parameter to None. regards, - Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502214: vnc4server asks for password even when -SecurityTypes None used
Package: vnc4server
Version: 4.1.1+X4.3.0-30
Severity: normal
Upon the first launch, vnc4server with the option '-SecurityTypes None'
still asks for a password, even though I specified no authentication to
be used.
vnc4server passes unknown options down to Xvnc, however in this case it
should be aware of it, see this code:
188 ($z,$z,$mode) = stat($vncUserDir/passwd);
189 if (!(-e $vncUserDir/passwd) || ($mode 077)) {
190 warn \nYou will require a password to access your desktops.\n\n;
191 system(vncpasswd $vncUserDir/passwd);
192 if (($? 8) != 0) {
193 exit 1;
194 }
195 }
The parameter '-SecurityTypes None' should be recognized and no password
should be asked for.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.19-vs2.2.0.7-netdoktor3-nd-vserv-bigmem4 (SMP w/4 CPU
cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages vnc4server depends on:
ii libc6 2.7-13GNU C Library: Shared libraries
ii libgcc11:4.3.1-9 GCC support library
ii libice62:1.0.4-1 X11 Inter-Client Exchange library
ii libsm6 2:1.0.3-2 X11 Session Management library
ii libstdc++6 4.3.1-9 The GNU Standard C++ Library v3
ii libx11-6 2:1.1.4-2 X11 client-side library
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension
ii x11-common 1:7.3+16 X Window System (X.Org) infrastruc
ii xbase-clients 1:7.3+17 miscellaneous X clients - metapack
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages vnc4server recommends:
ii xfonts-base 1:1.0.0-5 standard fonts for X
Versions of packages vnc4server suggests:
pn vnc-java none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500304: munin-node: plugins tomcat_* don't create graph
Package: munin-node
Version: 1.2.6-5
Severity: normal
Tags: patch
When activating the plugins tomcat_access, tomcat_threads and
tomcat_volume, they don't report any values for graphing.
That happens because the script expects the following XML structure in
the status output:
connectorhttp80requestInforequestCount
when in fact on my systems (seens this on three) it is
connectorhttp-80requestInforequestCount
Note the dash to separate http and the real port number.
--- tomcat_access.debian2008-09-27 08:13:57.0 +0200
+++ tomcat_access 2008-09-27 08:13:32.0 +0200
@@ -86,8 +86,8 @@
my $response = $ua-request(HTTP::Request-new('GET',$url));
my $xml = $xs-XMLin($response-content);
-if($xml-{'connector'}-{'http'.$PORT}-{'requestInfo'}-{'requestCount'}) {
-print accesses.value .
$xml-{'connector'}-{'http'.$PORT}-{'requestInfo'}-{'requestCount'} . \n;
+if($xml-{'connector'}-{'http-'.$PORT}-{'requestInfo'}-{'requestCount'}) {
+print accesses.value .
$xml-{'connector'}-{'http-'.$PORT}-{'requestInfo'}-{'requestCount'} . \n;
} else {
print accesses.value U\n;
}
This applies to all the mentioned scripts above. tomcat_jvm isn't
affects because it doesn't use the port for any metrics.
The installed tomcat version is:
ii tomcat5.5 5.5.26-3Servlet and JSP engine
ii tomcat5.5-admin 5.5.26-3Java Servlet engine -- admin..
ii tomcat5.5-webapps 5.5.26-3Java Servlet engine --
documentation..
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.19-vs2.2.0.7-netdoktor3-nd-vserv-bigmem4 (SMP w/4 CPU
cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages munin-node depends on:
ii adduser 3.108add and remove users and groups
ii gawk1:3.1.5.dfsg-4.1 GNU awk, a pattern scanning and pr
ii libnet-server-perl 0.97-1 An extensible, general perl server
ii lsb-base3.2-12 Linux Standard Base 3.2 init scrip
ii perl5.10.0-11Larry Wall's Practical Extraction
ii procps 1:3.2.7-8/proc file system utilities
Versions of packages munin-node recommends:
ii libnet-snmp-perl 5.2.0-1Script SNMP connections
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464074: Problem solved with php 5.2.5-2 and libtidy-0.99-0 20080116cvs-2
After I upgraded to the latest version in testing it doesn't crash anymore. thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465562: php5-syck falsly hits php's memory_limit with simple data
Package: php5-syck
Version: 0.55+svn270-1
Severity: grave
Justification: renders package unusable
When trying to to syck_dump() a simple data structure, PHPs memory_limit is hit
immediately. The data being dumped doesn't warrant hitting the memory limit and
the limit is already at 128M on my system.
I've tested the same code with the syck version from
http://pecl.php.net/package/syck and it works.
$ cat test
a:2:{s:7:traffic;a:1:{i:2007;a:1:{i:7;a:1:{s:2:01;a:1:{s:2:07;i:463293;s:4:sha1;a:1:{s:40:56b44b92aae1d66eefd1ed1d8c55d627421b6e26;b:1;}}
$ php -r '$a = unserialize(file_get_contents(test)); var_dump($a);
syck_dump($a);'
array(2) {
[traffic]=
array(1) {
[2007]=
array(1) {
[7]=
array(1) {
[01]=
array(1) {
[07]=
int(463293)
}
}
}
}
[sha1]=
array(1) {
[56b44b92aae1d66eefd1ed1d8c55d627421b6e26]=
bool(true)
}
}
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 176001744 bytes) in Command line code on line 1
Call Stack:
0.0001 51572 1. {main}() Command line code:0
0.0003 54036 2. syck_dump() Command line code:1
[EMAIL PROTECTED]:~/src/php$ sudo dpkg --purge php5-syck
(Reading database ... 39871 files and directories currently installed.)
Removing php5-syck ...
Purging configuration files for php5-syck ...
[EMAIL PROTECTED]:~/src/php$ sudo pecl install syck-beta
downloading syck-0.9.2.tgz ...
Starting to download syck-0.9.2.tgz (11,339 bytes)
.done: 11,339 bytes
3 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
building in /var/tmp/pear-build-root/syck-0.9.2
[...]
Build process completed successfully
Installing '/usr/lib/php5/20060613+lfs/syck.so'
install ok: channel://pecl.php.net/syck-0.9.2
configuration option php_ini is not set to php.ini location
You should add extension=syck.so to php.ini
[EMAIL PROTECTED]:~/src/php$ php -d extension=syck.so -r '$a =
unserialize(file_get_contents(test)); var_dump($a); var_dump(syck_dump($a));'
array(2) {
[traffic]=
array(1) {
[2007]=
array(1) {
[7]=
array(1) {
[01]=
array(1) {
[07]=
int(463293)
}
}
}
}
[sha1]=
array(1) {
[56b44b92aae1d66eefd1ed1d8c55d627421b6e26]=
bool(true)
}
}
string(159) --- %YAML:1.0
? traffic
:
? 2007
:
? 7
:
? 01
: {07: 463293}
? sha1
: {56b44b92aae1d66eefd1ed1d8c55d627421b6e26: true}
sincerely,
- Markus
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.21.6-vs2.2.0.1-netdoktor2-nd-vserv-bigmem4 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages php5-syck depends on:
ii libapache2-mod-php5 [phpapi-2 5.2.4-2+b1 server-side, HTML-embedded scripti
ii libc6 2.7-6 GNU C Library: Shared libraries
ii php5-cli [phpapi-20060613+lfs 5.2.4-2+b1 command-line interpreter for the p
php5-syck recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464074: php5-tidy: Memory limited exceeded always with tidy_parse_string()
Package: php5-tidy
Version: 5.2.4-2+b1
Severity: normal
I initially reported this as #463872 but it was suggested this may be a
php5-tidy bug.
When used within PHP, the allowed memory size from PHP is exceeded every time:
$ /usr/bin/php -r 'tidy_parse_string();'
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 141264868 bytes) in Command line code on line 1
Call Stack:
0.0153 50764 1. {main}() Command line code:0
0.0304 50764 2. tidy_parse_string() Command line code:1
When using the libtidy-0.99-0 binary from the 20051018-1 package, it works.
However, when I compile a clean 5.2.4 or 5.2.5 release from php.net, it also
works with the 20080116cvs-2 version of libtidy-0.99-0. It seems somewhere
something went wrong during the php5-tidy compilation phase (or so).
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages php5-tidy depends on:
ii libapache2-mod-php5 [phpap 5.2.4-2+b1server-side, HTML-embedded scripti
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libtidy-0.99-0 20080116cvs-2 HTML syntax checker and reformatte
ii php5-cli [phpapi-20060613+ 5.2.4-2+b1command-line interpreter for the p
ii php5-common5.2.4-2+b1Common files for packages built fr
php5-tidy recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: (no subject)
I think this sounds very reasonable. I don't know why the debian PHP5 package version crashes, because when I compile 5.2.4 and 5.2.5 from clean php.net from source, the tidy extension works. The PHP package tidy version exhibits this problem reproduceable on different machines for me. Should this file against PHP instead? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: (no subject)
I reported it against php5-tidy as #464074 which now contains a more simplified reproducable example. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464087: swatch: the mail addresses= configuration option requires \@ but this is not documented
Package: swatch Version: 3.2.1-1 Severity: normal This is the exactly the same problem as described in #197042. I tried replying to #197042 but only got Recipient: [EMAIL PROTECTED] Reason:unknown user Using mail [EMAIL PROTECTED] does not work correctly, mail [EMAIL PROTECTED] is needed. This is not documented in the manpage or other documentation. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21.6-vs2.2.0.1-netdoktor2-nd-vserv-bigmem4 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages swatch depends on: ii libdate-calc-perl 5.4-5 Perl library for accessing dates ii libdate-manip-perl5.48-2 a perl library for manipulating da ii libfile-tail-perl 0.99.3-2 File::Tail perl module ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii perl [libtime-hires-perl] 5.8.8-12 Larry Wall's Practical Extraction swatch recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: libtidy-0.99-0: Exceeds allowed memory size when used with php5-tidy 5.2.4-2+b1
Package: libtidy-0.99-0
Version: 20080116cvs-2
Severity: grave
Justification: renders package unusable
When used within PHP, the allowed memory size from PHP is exceeded:
[EMAIL PROTECTED]:~/src$ cat debian-5.2.4-tidy-crash.php
?php
$sHtml = HTML
html
body
h1test/h1
/body
/html
HTML;
$oTidy = tidy_parse_string($sHtml);
[EMAIL PROTECTED]:~/src$ /usr/bin/php debian-5.2.4-tidy-crash.php
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 141265660 bytes) in /home/mfischer/src/debian-5.2.4-tidy-crash.php on
line 9
Call Stack:
0.0003 51896 1. {main}()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:0
0.0003 52048 2. tidy_parse_string()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:9
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'unknown')
The reason I'm filing this against the libtidy-0.99-0 package is that this does
not happen with libtidy-0.99-0=20051018-1 .
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libtidy-0.99-0 depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
libtidy-0.99-0 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463872: libtidy-0.99-0: Exceeds allowed memory size when used with php5-tidy 5.2.4-2+b1
Hello,
I'm not sure if you looked at this example exactly.
The memory limit is set to 128M and tidy cannot parse a few lines of HTML with
it? To me, this is an error. And it works in the same environment with the
older libtidy. I was lucky I could verify this because I had another machine
still with a 20051018-1 .so binary - works.
thanks,
- Markus
Jason Thomas wrote:
Why don't you just increase your max memory in php. libtidy is now 2
years newer. most likely its going to use more memory.
On Sun, 2008-02-03 at 22:54 +0100, Markus Fischer wrote:
Package: libtidy-0.99-0
Version: 20080116cvs-2
Severity: grave
Justification: renders package unusable
When used within PHP, the allowed memory size from PHP is exceeded:
[EMAIL PROTECTED]:~/src$ cat debian-5.2.4-tidy-crash.php
?php
$sHtml = HTML
html
body
h1test/h1
/body
/html
HTML;
$oTidy = tidy_parse_string($sHtml);
[EMAIL PROTECTED]:~/src$ /usr/bin/php debian-5.2.4-tidy-crash.php
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 141265660 bytes) in /home/mfischer/src/debian-5.2.4-tidy-crash.php on
line 9
Call Stack:
0.0003 51896 1. {main}()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:0
0.0003 52048 2. tidy_parse_string()
/home/mfischer/src/debian-5.2.4-tidy-crash.php:9
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'unknown')
The reason I'm filing this against the libtidy-0.99-0 package is that this does
not happen with libtidy-0.99-0=20051018-1 .
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libtidy-0.99-0 depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
libtidy-0.99-0 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454803: php5: Unable to build pdo_sqlite standlone because php_pdo_driver.h cannot be found (but is there)
Package: php5 Version: 5.2.3-1+lenny1 Severity: wishlist Currently the pdo_sqlite extension cannot be built standalone because the header file php_pdo_driver.h cannot be found although it's there. See the example (the directory pdo_sqlite is directly copied from a prestine 5.2.5 source directory): [EMAIL PROTECTED]:~/isrc/php/pdo_sqlite$ phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519 ./[EMAIL PROTECTED]:~/isrc/php/pdo_sqlite$ ./configure --help|less [EMAIL PROTECTED]:~/isrc/php/pdo_sqlite$ ./configure checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for a sed that does not truncate output... /bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc and cc understand -c and -o together... yes checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for PHP prefix... /usr checking for PHP includes... -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -I/usr/include/php5/ext/date/lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 checking for PHP extension directory... /usr/lib/php5/20060613+lfs checking for PHP installed headers prefix... /usr/include/php5 checking for re2c... re2c checking for re2c version... 0.12.1 (ok) checking for gawk... no checking for nawk... nawk checking if nawk is broken... no checking for sqlite 3 support for PDO... yes, shared checking for PDO includes... checking for PDO includes... configure: error: Cannot find php_pdo_driver.h. [EMAIL PROTECTED]:~/isrc/php/pdo_sqlite$ The file is available at /usr/include/php5/ext/pdo/php_pdo_driver.h . The check inside configure looks like this: if test -f $abs_srcdir/include/php/ext/pdo/php_pdo_driver.h; then pdo_inc_path=$abs_srcdir/ext elif test -f $abs_srcdir/ext/pdo/php_pdo_driver.h; then pdo_inc_path=$abs_srcdir/ext elif test -f $prefix/include/php/ext/pdo/php_pdo_driver.h; then pdo_inc_path=$prefix/include/php/ext fi In my case $abs_srcdir is set to /home/markus/isrc/php/pdo_sqlite . When I symlink ext inside pdo_sqlite to ln -s /usr/include/php5/ext it works. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21.6-vs2.2.0.1-netdoktor2-nd-vserv-bigmem4 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages php5 depends on: ii libapache2-mod-php5 5.2.3-1+lenny1 server-side, HTML-embedded scripti ii php5-common 5.2.3-1+lenny1 Common files for packages built fr php5 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450574: Does not read /usr/share/vim/addons/ but /var/lib/vim/addons/
Package: vim Version: 1:7.0-122+1etch3 Severity: normal The directory /usr/share/vim/addons/ is never considered by vim to be parsed upon starting. Using strace I discovered that only /var/lib/vim/addons/ is considered. It seems /usr/share/vim/addons/ is either obsolete or /var/lib/vim/addons/ should be a symlink to /usr/share/vim/addons/ . -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21.6-vs2.2.0.1-netdoktor2-nd-vserv-bigmem4 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages vim depends on: ii libacl1 2.2.41-1 Access control list shared library ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libgpmg11.19.6-25General Purpose Mouse - shared lib ii libncurses5 5.6+20071013-1 Shared libraries for terminal hand ii vim-common 1:7.0-122+1etch3 Vi IMproved - Common files ii vim-runtime 1:7.0-122+1etch3 Vi IMproved - Runtime files vim recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433688: puppet: --help switch doesn't work
Package: puppet Version: 0.20.1-1 Severity: important The help switch doesn't work on any of the executeables in the puppet/puppetmaster package. This is the output I get: mngr01:~# puppet --help /usr/bin/puppet:103: undefined method `feature' for Puppet:Module (NoMethodError) from /usr/lib/ruby/1.8/getoptlong.rb:613:in `each' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `loop' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `each' from /usr/bin/puppet:97 mngr01:~# puppetd --help /usr/sbin/puppetd:219: undefined method `feature' for Puppet:Module (NoMethodError) from /usr/lib/ruby/1.8/getoptlong.rb:613:in `each' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `loop' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `each' from /usr/sbin/puppetd:194 mngr01:~# puppetmasterd --help /usr/sbin/puppetmasterd:131: undefined method `feature' for Puppet:Module (NoMethodError) from /usr/lib/ruby/1.8/getoptlong.rb:613:in `each' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `loop' from /usr/lib/ruby/1.8/getoptlong.rb:610:in `each' from /usr/sbin/puppetmasterd:124 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21.6-vs2.2.0.1-netdoktor2-nd-vserv-bigmem4 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages puppet depends on: ii adduser3.102 Add and remove users and groups ii facter 1.3.5-1 a library for retrieving facts fro ii libopenssl-ruby1.0.0+ruby1.8.2-1 OpenSSL interface for Ruby ii libxmlrpc-ruby 1.8.2-1 XML-RPC support for Ruby ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip ii ruby 1.8.2-1 An interpreter of object-oriented Versions of packages puppet recommends: ii rdoc 1.8.2-1Generate documentation from ruby s -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387076: SSH authorization with pam/winbind also doesn't work
Package: winbind Version: 3.0.23c-1 Followup-For: Bug #387076 Additionally I detected that SSH pam/winbind authorization also didn't worked. The identified binary which caused the problem was: /lib/security/pam_winbind.so -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages winbind depends on: ii adduser 3.97 Add and remove users and groups ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libcomerr2 1.39-1 common error description library ii libkrb531.4.4-1 MIT Kerberos runtime libraries ii libldap22.1.30-13+b1 OpenLDAP libraries ii libpam0g0.79-3.1 Pluggable Authentication Modules l ii libpopt01.10-2 lib for parsing cmdline parameters ii lsb-base3.1-15 Linux Standard Base 3.1 init scrip ii samba-common3.0.23c-1Samba common files used by both th winbind recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387076: samba: User authorization doesn't work anymore after upgrade
Package: samba Version: 3.0.23c-1 Followup-For: Bug #387076 I'm having the same problem as reported above. I'm having pam/winbindd querying our DC but after upgrading to 23c-1 it failed. Luckily I've (sub)versionied my complete debian installation and I was able to track down which files are really involved in the problem. /lib/libnss_winbind.so.2 /usr/sbin/smbd /usr/sbin/winbindd If any of these binary files is from the 23c-1 version, authorizing users over pam/winbindd doesn't work anymore. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages samba depends on: ii debconf [debconf-2.0] 1.5.3Debian configuration management sy ii libacl1 2.2.41-1 Access control list shared library ii libattr12.4.32-1 Extended attribute shared library ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libcomerr2 1.39-1 common error description library ii libcupsys2 1.2.2-2 Common UNIX Printing System(tm) - ii libgnutls13 1.4.4-1 the GNU TLS library - runtime libr ii libkrb531.4.4-1 MIT Kerberos runtime libraries ii libldap22.1.30-13+b1 OpenLDAP libraries ii libpam-modules 0.79-3.1 Pluggable Authentication Modules f ii libpam-runtime 0.79-3.1 Runtime support for the PAM librar ii libpam0g0.79-3.1 Pluggable Authentication Modules l ii libpopt01.10-2 lib for parsing cmdline parameters ii logrotate 3.7.1-3 Log rotation utility ii lsb-base3.1-15 Linux Standard Base 3.1 init scrip ii netbase 4.25 Basic TCP/IP networking system ii procps 1:3.2.7-2/proc file system utilities ii samba-common3.0.23c-1Samba common files used by both th ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages samba recommends: ii smbldap-tools 0.9.2-3Scripts to manage Unix and Samba a -- debconf information: samba/nmbd_from_inetd: samba/run_mode: daemons samba/log_files_moved: samba/tdbsam: false samba/generate_smbpasswd: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387076: SSH authorization with pam/winbind also doesn't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek wrote: On Sat, Sep 16, 2006 at 09:05:53PM +0200, Markus Fischer wrote: Package: winbind Version: 3.0.23c-1 Followup-For: Bug #387076 Additionally I detected that SSH pam/winbind authorization also didn't worked. The identified binary which caused the problem was: /lib/security/pam_winbind.so What does this have to do with the report that the 'valid users' option is no longer being honored? Sorry, my fault. For me it was all related to the same problem. I think what I really observed was a not-working binary library and not a not-working configuration option, because various parts broke at the same time, all related to authenticate users over winbind. - - Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDLoq1nS0RcInK9ARAlJPAKCyCqLNqWj3anULnomrpd+qcX+G6ACfRlWR TYWiWhis5//1YjmFmJe9iuU= =BG3s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324318: phpmyadmin: More than three configurations gives Notices and Warnings and breaks
Package: phpmyadmin Version: 4:2.6.2-3sarge1 Followup-For: Bug #324318 When I give a fourth configuration block, I get the following warnings when I choose this configuration in the select: Notice: Undefined index: controluser in /usr/share/phpmyadmin/libraries/common.lib.php on line 1232 Notice: Undefined index: compress in /usr/share/phpmyadmin/libraries/dbi/mysql.dbi.lib.php on line 51 Notice: Undefined index: compress in /usr/share/phpmyadmin/libraries/dbi/mysql.dbi.lib.php on line 51 Warning: Cannot modify header information - headers already sent by (output started at /usr/share/phpmyadmin/libraries/common.lib.php:1232) in /usr/share/phpmyadmin/libraries/select_theme.lib.php on line 98 Warning: Cannot modify header information - headers already sent by (output started at /usr/share/phpmyadmin/libraries/common.lib.php:1232) in /usr/share/phpmyadmin/index.php on line 55 I swapped the configuration (e.g. second with fourth) and it was the same problem: the fourth didn't work, though the second did. So I assumed it's not a problem with the configuration itself. Actually, every configuration block after the third gives this problems when selecting from the select. - Markus -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.29-nc2 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages phpmyadmin depends on: ii apache [httpd]1.3.33-6sarge1 versatile, high-performance HTTP s ii apache2-mpm-prefork [http 2.0.54-5 traditional model for Apache2 ii debconf 1.4.30.13 Debian configuration management sy ii php4 4:4.3.10-16server-side, HTML-embedded scripti ii php4-mysql4:4.3.10-16MySQL module for php4 ii ucf 1.17 Update Configuration File: preserv -- debconf information: * phpmyadmin/reconfigure-webserver: apache * phpmyadmin/restart-webserver: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302135: php4: phpversion() reports debian specific version, breaks code which assumes php versioning
Package: php4 Version: 4:4.3.10-9 Severity: important phpversion() reports '4.3.10-9' which breaks any code in the world which checks e.g. for '4.3.10' (happens with DB_DataObject which works around a bug in 4.3.10). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.29-nc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages php4 depends on: ii libapache-mod-php44:4.3.10-9 server-side, HTML-embedded scripti ii php4-common 4:4.3.10-9 Common files for packages built fr -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
