Bug#1071519: apt: "--solver 3.0" does not want to upgrade some packages

[Gabor Gombas]

On Tue, May 21, 2024 at 11:47:13AM +0200, Julian Andres Klode wrote:

> If you can do so, please use -o Dir::Log::Solver=
> to specify a file to dump the solver request to, and then compress and
> attach it to the bug report (it might need --solver internal if you
> default to 3.0, I need to check and eventually fix solver logging for
> 3.0 still).

I've, tried that, but no luck (different package this time):

# apt install -t unstable --mark-auto --solver 3.0 -o 
Dir::Log::Solver=/tmp/solver.edsp cd-paranoia
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 124
# ls -l /tmp/solver.edsp
ls: cannot access '/tmp/solver.edsp': No such file or directory

The good news is, --mark-auto really seems to be the trigger.

> It could also be that the reason is the --mark-auto. This marks the
> request to install that specific version as automatic presumably,

Well, that's what the documentation says, but that's not how it works
according to my experience. In real life, what "--mark-auto" appears to
mean is "do not touch the auto/manual status of the package, leave it as
it was before". And that's _EXACTLY_ what I want 90% of the time when I
run "apt install", so I tend to always use this flag. I rarely install
new packages which I would also want to keep, but I do install versions
of random packages from unstable on a daily basis to see what's coming -
and I don't want those to be marked as manually installed.

Actually, if I mess up the command (e.g. I forgot the "-t unsable")
option and apt finds that the package is already up to date, then apt
still marks the package as manually installed even if "--mark-auto" was
used - now that is annoying.

There really should be a better way to say "if a package is already
installed and I just want to upgrade it, then under no circumstances
change it from auto-installed to manual or vice versa". Otherwise,
eveything gets marked as manually installed over time, and "apt
autoremove" becomes pretty much useless.

Regards,
Gabor

Bug#831908: syslog-ng-mod-journal: Upgrading to 3.7.3-1 caused all of the existing systemd journal to be dumped into syslog

[Gabor Gombas]

Package: syslog-ng-mod-journal
Version: 3.7.3-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Upgrading syslog-ng-core.

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

apt upgrade -t unstable

   * What was the outcome of this action?

The _entire_ systemd journal (several months) were dumped into syslog.

   * What outcome did you expect instead?

No such stupidity...

More seriously, from dpkg log it can be seen when syslog-ng was upgraded:

2016-07-20 07:57:02 install syslog-ng-mod-journal:amd64  3.7.3-1
2016-07-20 07:57:02 status half-installed syslog-ng-mod-journal:amd64 3.7.3-1
2016-07-20 07:57:02 status triggers-pending syslog-ng-core:amd64 3.5.6-2.1+b3
2016-07-20 07:57:02 status half-installed syslog-ng-mod-journal:amd64 3.7.3-1
2016-07-20 07:57:02 status unpacked syslog-ng-mod-journal:amd64 3.7.3-1
2016-07-20 07:57:02 status unpacked syslog-ng-mod-journal:amd64 3.7.3-1
2016-07-20 07:57:02 upgrade syslog-ng-core:amd64 3.5.6-2.1+b3 3.7.3-1
2016-07-20 07:57:02 status half-configured syslog-ng-core:amd64 3.5.6-2.1+b3
2016-07-20 07:57:02 status unpacked syslog-ng-core:amd64 3.5.6-2.1+b3
2016-07-20 07:57:02 status half-installed syslog-ng-core:amd64 3.5.6-2.1+b3
2016-07-20 07:57:03 status half-installed syslog-ng-core:amd64 3.5.6-2.1+b3
2016-07-20 07:57:03 status unpacked syslog-ng-core:amd64 3.7.3-1
2016-07-20 07:57:03 status unpacked syslog-ng-core:amd64 3.7.3-1

/var/log/syslog:

Jul 20 07:57:36 host syslog-ng[2221]: syslog-ng shutting down; version='3.5.6'
Jul 20 07:57:36 host systemd[1]: Stopping System Logger Daemon...
Jul 20 07:57:37 host syslog-ng[25569]: syslog-ng starting up; version='3.7.3'
Jul 20 07:57:37 host syslog-ng[25569]: Syslog connection established; fd='13', 
server='AF_INET(192.168.0.10:601)', local='AF_INET(0.0.0.0:0)'
--- fine so far... but: ---
Oct 15 19:44:20 host systemd-journal[271]: Runtime journal (/run/log/journal/) 
is currently using 8.0M.
Maximum allowed usage is set to 157.4M.
Leaving at least 236.1M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.4M.
Oct 15 19:44:20 host systemd-journal[271]: Runtime journal (/run/log/journal/) 
is currently using 8.0M.
Maximum allowed usage is set to 157.4M.
Leaving at least 236.1M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.4M.

Yup, that's the beginning of the systemd journal:

# journalctl | head
-- Logs begin at Thu 2015-10-15 19:44:20 CEST, end at Wed 2016-07-20 20:09:22 
CEST. --
Oct 15 19:44:20 host systemd-journal[271]: Runtime journal (/run/log/journal/) 
is currently using 8.0M.
 Maximum allowed usage is set to 
157.4M.
 Leaving at least 236.1M free (of 
currently available 1.5G of space).
 Enforced usage limit is thus 
157.4M.
Oct 15 19:44:20 host systemd-journal[271]: Runtime journal (/run/log/journal/) 
is currently using 8.0M.
 Maximum allowed usage is set to 
157.4M.
 Leaving at least 236.1M free (of 
currently available 1.5G of space).
 Enforced usage limit is thus 
157.4M.

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


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

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

Versions of packages syslog-ng-mod-journal depends on:
ii  libc6 2.23-2
ii  libsystemd0   230-7
ii  syslog-ng-core [syslog-ng-abi-3.7-0]  3.7.3-1

Versions of packages syslog-ng-mod-journal recommends:
ii  systemd  230-7

syslog-ng-mod-journal suggests no packages.

-- no debconf information

Bug#801247: pinentry-gnome3: No PIN dialog

[Gabor Gombas]

Package: pinentry-gnome3
Version: 0.9.6-2
Severity: normal


Hi,

I'm using a Yubikey Neo to hold my ssh key. When
/etc/alternatives/pinentry points to pinentry-gnome3 (the default), then
I get no PIN dialog, and ssh fails. If I use update-alternatives to make
/etc/alternatives/pinentry to point to pinentry-gtk-2, and call ssh,
then the PIN dialog shows up as expected, and everything works fine. I'm
using Cinnamon, not Gnome, if that counts.

Gabor

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

Kernel: Linux 4.2.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pinentry-gnome3 depends on:
ii  gcr  3.16.0-1
ii  libassuan0   2.3.0-1
ii  libc62.19-22
ii  libgcr-base-3-1  3.16.0-1
ii  libglib2.0-0 2.46.0-2
ii  libgpg-error01.20-1
ii  libgtk-3-0   3.18.0-4
ii  libncursesw5 6.0+20150810-1
ii  libsecret-1-00.18.3-1
ii  libtinfo56.0+20150810-1

pinentry-gnome3 recommends no packages.

Versions of packages pinentry-gnome3 suggests:
pn  pinentry-doc  

-- no debconf information

Bug#571771: Couldn't configure pre-depend ... probably a dependency cycle

[Gabor Gombas]

On Sun, Mar 07, 2010 at 11:00:45PM +0100, Rene Engelhard wrote:

> And dist-upgrade (or full-upgrade I think is what aptitude calls it)?

"apt-get dist-upgrade", "aptitude dist-upgrade" and "aptitude
full-upgrade" all give the same error as "safe-upgrade".

> Who said that safe-upgrade will work in all dependency cases?

"apt-get dist-upgrade" and "aptitude dist-upgrade" also want to do
crazy things from time to time... IMHO giving an explicit list of
packages to "apt-get install" is still the most reliable way to upgrade,
but this is getting off topic.

Gabor



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

Bug#567468: domainname

[Gabor Gombas]

Hi,

IMHO you are confused: /proc/sys/kernel/domainname is the NIS domain name
and has nothing to do with DNS; in fact, the NIS domain can be different
from the DNS domain. Thus your script is doubly wrong: on a NIS system
hostnames are normally not qualified so you cannot obtain the NIS domain
from the host name, and on a non-NIS system the NIS domainname should
remain unset even if the hostname is qualified.

Also, mdadm currently works fine with custom-built kernels having no
initramfs at all. Why break that? It would be much nicer to patch mdadm
to try to read /etc/hostname directly if gethostname() returns an empty
string.

Regarding to the issue Marco raised: in fact it is quite common to
install a machine on an internal network where it gets some random name
from DHCP, and rename it when it is ready to be put at it's intended
location. When you do not have physical access to the final location
then finding out that the machine no longer boots with the new name may
be painful.

Gabor



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

Bug#503999: memory corruption due to use-after-free

[Gabor Gombas]

Hi,

On Thu, Jan 28, 2010 at 06:38:09PM +0100, Domenico Andreoli wrote:

> could you please check current curl 7.19.7-1 package agains this bug?

I no longer has access to the BOINC client farm where this bug was found
but the latest BOINC + libcurl from sid about a month ago (on an
otherwise mostly lenny system) run stable without crashes.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#565130: [php-maint] Bug#565130: libapache2-mod-php5: Upgrading fails

[Gabor Gombas]

Hi,

On Wed, Jan 13, 2010 at 09:55:52AM +0100, Ondřej Surý wrote:

> cp  /usr/share/php5/php.ini-production  /usr/share/php5/php.ini-dist
> dpkg --configure -a
> 
> meanwhile to make your php5 installation not broken again...

That worked, thanks.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#564566: libkadm5clnt7: SONAME conflict with Heimdal

[Gabor Gombas]

On Sun, Jan 10, 2010 at 10:44:11AM -0500, Sam Hartman wrote:

> I'll add a conflicts for now.  Are you running into a case where you'd
> actually like to have both libraries installed at the same time?

I'd only like to use the Heimdal version, but some -dev packages depend
on libkrb5-dev which in turn explicitely depends on libkadm5clnt7, so I
can't get rid of it.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#564020: [Pkg-libvirt-maintainers] Bug#564020: libvirt-bin: libvirtd segfaults at startup

[Gabor Gombas]

On Thu, Jan 07, 2010 at 11:18:03AM +0100, Guido Günther wrote:

> Could you check if the attached patch help?

Yes it does help. Thanks.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#564020: [Pkg-libvirt-maintainers] Bug#564020: libvirt-bin: libvirtd segfaults at startup

[Gabor Gombas]

On Thu, Jan 07, 2010 at 11:18:03AM +0100, Guido Günther wrote:

> Could you check if the attached patch help?

Btw. could you add "--without-esx --without-libssh2" to debian/rules
until the official packages start to use them?

Otherwise the packages built locally will depend on libcurl3 and libssh2
if the resp. -dev packages are installed. When the resulting packages
are installed on a "mostly lenny with a pinch of sid" system, APT is not
able to figure out the dependencies.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#559298: [Pkg-libvirt-maintainers] Bug#559298: virt-manager: problems with multiple windows

[Gabor Gombas]

On Tue, Dec 08, 2009 at 06:32:38PM +0100, Guido Günther wrote:

> This might be caused by nc calls needing a "-q 0" argument. Could you
> try adding these, it would involve adding this to libvirt in
> src/remote/remote_driver.c as well as virt-manager in
> src/virtManager/console.py (the later one only for console usage).

That indeed seems to do the trick. See below for the patches I've used.

Gabor

diff -u -r libvirt-0.7.5/src/remote/remote_driver.c 
libvirt-0.7.5.new/src/remote/remote_driver.c
--- libvirt-0.7.5/src/remote/remote_driver.c2009-12-22 17:45:39.0 
+0100
+++ libvirt-0.7.5.new/src/remote/remote_driver.c2010-01-08 
09:59:38.219846339 +0100
@@ -730,7 +730,7 @@
 }
 
 case trans_ssh: {
-int j, nr_args = 6;
+int j, nr_args = 8;
 
 if (username) nr_args += 2; /* For -l username */
 if (no_tty) nr_args += 5;   /* For -T -o BatchMode=yes -e none */
@@ -764,6 +764,8 @@
 }
 cmd_argv[j++] = strdup (priv->hostname);
 cmd_argv[j++] = strdup (netcat ? netcat : "nc");
+cmd_argv[j++] = strdup ("-q");
+cmd_argv[j++] = strdup ("0");
 cmd_argv[j++] = strdup ("-U");
 cmd_argv[j++] = strdup (sockname ? sockname :
 (flags & VIR_CONNECT_RO

diff -u -r virt-manager-0.8.2/src/virtManager/console.py 
virt-manager-0.8.2.new/src/virtManager/console.py
--- virt-manager-0.8.2/src/virtManager/console.py   2009-12-14 
23:40:30.0 +0100
+++ virt-manager-0.8.2.new/src/virtManager/console.py   2010-01-08 
09:16:08.723346250 +0100
@@ -506,7 +506,7 @@
 if username:
 argv += ['-l', username]
 
-argv += [ server, "nc", vncaddr, str(vncport) ]
+argv += [ server, "nc", "-q", "0", vncaddr, str(vncport) ]
 
 logging.debug("Creating SSH tunnel: %s" % argv)
 
-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#564020: libvirt-bin: libvirtd segfaults at startup

[Gabor Gombas]

Package: libvirt-bin
Version: 0.7.5-2
Severity: important


Hi,

# gdb /usr/sbin/libvirtd 
GNU gdb (GDB) 7.0-debian
Copyright (C) 2009 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/libvirtd...Reading symbols from 
/usr/lib/debug/usr/sbin/libvirtd...done.
(no debugging symbols found)...done.
(gdb) set arg -l
(gdb) r
Starting program: /usr/sbin/libvirtd -l
[Thread debugging using libthread_db enabled]
[New Thread 0x71dd3910 (LWP 5326)]
[New Thread 0x715d2910 (LWP 5327)]
[New Thread 0x70dd1910 (LWP 5328)]
[New Thread 0x7fffebfff910 (LWP 5329)]
[New Thread 0x7fffeb7fe910 (LWP 5330)]
[New Thread 0x7fffeaffd910 (LWP 5331)]
08:34:42.043: error : udevSetupSystemDev:1409 : Failed to get udev device for 
syspath '/sys/devices/virtual/dmi/id'

08:34:42.044: error : virStateInitialize:890 : Initialization of (null) state 
driver failed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x71dd3910 (LWP 5326)]
0x0047c08f in udevEventHandleCallback (watch=4, fd=15, events=4, 
data=0x0)
at node_device/node_device_udev.c:1345
1345node_device/node_device_udev.c: No such file or directory.
in node_device/node_device_udev.c
(gdb)

The host runs Xen, and mostly lenny. The node libvirtd complains about above
does not exist in sysfs.

Gabor

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

Kernel: Linux 2.6.26-2-xen-amd64 (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 libvirt-bin depends on:
ii  adduser   3.110  add and remove users and groups
ii  hal   0.5.14-1   Hardware Abstraction Layer
ii  libavahi-client3  0.6.23-3lenny1 Avahi client library
ii  libavahi-common3  0.6.23-3lenny1 Avahi common library
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libcap-ng00.6.2-3+b1 Development and header files for l
ii  libdevmapper1.02. 2:1.02.27-4The Linux Kernel Device Mapper use
ii  libgcrypt11   1.4.4-6LGPL Crypto library - runtime libr
ii  libgnutls26   2.8.5-2the GNU TLS library - runtime libr
ii  libparted1.8-12   1.8.8.git.2009.07.19-5 The GNU Parted disk partitioning s
ii  libpciaccess0 0.10.3-1   Generic PCI access library for X
ii  libreadline6  6.0-5  GNU readline and history libraries
ii  libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra
ii  libudev0  149-2  libudev shared library
ii  libuuid1  2.16.2-0   Universally Unique ID library
ii  libvirt0  0.7.5-2library for interfacing with diffe
ii  libxenstore3.03.2.1-2Xenstore communications library fo
ii  libxml2   2.7.6.dfsg-1   GNOME XML library
ii  logrotate 3.7.1-5Log rotation utility

Versions of packages libvirt-bin recommends:
ii  bridge-utils  1.4-5  Utilities for configuring the Linu
pn  dnsmasq-base   (no description available)
ii  iptables  1.4.2-6administration tools for packet fi
ii  netcat-openbsd1.89-3 TCP/IP swiss army knife
pn  qemu   (no description available)

Versions of packages libvirt-bin suggests:
pn  policykit-1(no description available)

-- no debconf information



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

Bug#562780: where is /etc/hosts supposed to come from?

[Gabor Gombas]

On Mon, Dec 28, 2009 at 03:52:44AM +0100, Marco d'Itri wrote:

> Considering that any non-trivial server needs to send email out, having
> a working FQDN configured is not "obsolete".

Anything mail related must use /etc/mailname if it needs something that
can be translated to an IP address.

> Your solution to #562780 is broken anyway, /etc/hostname can (and
> actually should) be a FQDN.

No. /etc/hostname has _nothing_ to do with networking. People
historically was lazy to do the proper interface/address enumeration(*)
and instead pretended that /etc/hostname is something resolvable, but it
is simply not true. It may be made to work in some really simple
configurations (read: the host has just a single static IP address), but
it cannot work in any serious server configuration having multiple
interfaces and every interface having multiple addresses.

Anything that uses "fqdn -f" today should really do the following:

L := empty list
loop I for all configured interfaces
loop P for all supported network protocols
loop A for all addresses on I of protocol P
append getnameinfo(A) to L
remove duplicates from L

Gabor

(*) mostly because doing this enumeration in a portable way is a PITA

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#561106: [Pkg-utopia-maintainers] Bug#561106: consolekit: console-kit-daemo segfaults at startup

[Gabor Gombas]

On Mon, Dec 14, 2009 at 05:45:30PM +0100, Michael Biebl wrote:
> Gábor Gombás wrote:
> 
> > console-kit-daemon[9909]: WARNING: Unable to load seats from file 
> > /etc/ConsoleKit/seats.d/.svn: Not a regular file
> 
> I heard of this issue before and I think it is related to the fact that you 
> have
> etc-in-svn, and ck tries to read "garbage" files from the .svn directory.
> 
> Can you confirm that this issue does not happen if you remove the .svn
> subdirectories?

Yes, I've just moved /etc/ConsoleKit/seats.d/.svn away and
console-kit-daemon started just fine.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#559298: [Pkg-libvirt-maintainers] Bug#559298: virt-manager: problems with multiple windows

[Gabor Gombas]

On Mon, Dec 07, 2009 at 09:41:25PM +0100, Guido Günther wrote:

> Is this still an issue with 0.8.1?

Yes. Actually it got worse (or just more reliable): I now managed to
hang virt-manager by opening/closing just a single VM window. Summary:

- VM #1 runs Linux (all the other VMs run Windows). Opening/closing just
  this VM causes virt-manager to hang reliably. 

- If I open multiple windows and then close them in the exact reverse
  order, then there is no hang.

- If close windows in any other order, then virt-manager hangs. That is,
  if I open 3 windows and close the second, it hangs.

  AFAIR 0.8.0 hung only when closing the window that was opened first;
  opening/closing subsequent windows did not cause problems as long as
  the first window was alive. OTOH 0.8.0 crashed sometimes instead,
  which 0.8.1 did not do so far.

- Even if I close all the windows in the "right" order and exit
  virt-manager normally, the ssh process to the remote machine remains
  there in the background.

- Even if I kill this ssh process, on the remote node an "nc -U
  /var/run/libvirt/libvirt-sock" process remains alive. Not sure if this
  is really a problem or not; at least killing these processes and
  trying again does not change anything.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#535008: configure_networking: support BOOTIF variable set by pxelinux

[Gabor Gombas]

Hi,

Mee too! It'd be really nice to have this integrated.

To add something constructive, mdadm, and lvm2 scripts already use sed
without checking for it or making sure that it is available, so the use
of sed should not be a problem. cryptsetup also uses sed but it at least
forces "BUSYBOX=y". IMHO it should be enough to document that "BOOT=nfs"
requires "BUSYBOX=y".

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#551158: Libc6: exim4 Segfault in libc-2.7.so

[Gabor Gombas]

Hi,

On Tue, Oct 27, 2009 at 06:21:24AM +0100, Fabio Rosciano wrote:

> thanks for helping out.
> Here it is, I can't see anything funny:

[...]

Yes, the logs are pretty much the same as when I did the upgrade, except
I did not have libc6-dev-i386 installed and I went to 2.10.1-1 from
2.9-27.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#551158: Libc6: exim4 Segfault in libc-2.7.so

[Gabor Gombas]

On Mon, Oct 26, 2009 at 09:02:22AM +0100, Fabio Rosciano wrote:
> On Mon, 2009-10-26 at 08:10 +0100, Aurelien Jarno wrote:
> 
> > Do you have the list of packages that have been upgraded?
> 
> I wish I did, but as soon as debconf asked "would you like to upgrade
> libc6 now?" and I answered "yes", the system became completely unusable.

Do you have /var/log/dpkg.log? Even if it does not contain the action
that failed first, the lines before the failure may show if packages
were being installed in an unexpected order.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#551831: cupt: Incorrectly upgrades libc6, breaking the system

[Gabor Gombas]

On Wed, Oct 21, 2009 at 12:01:51PM +0300, Eugene V. Lyubimkin wrote:

> However, this is another side of already archived
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543365 (ironically, reported
> by you too). On i386 we have the issue: libc6-i686 strictly Pre-Depends on
> libc6 (= ...), and whatever package from this two cupt tries to upgrade first,
> the pre-dependency will be broken.
> 
> Let me try to add libc maintainers to the loop to know the correct upgrade 
> path.

Hmm. "remove old libc6-i686, upgrade libc6, install new libc6-i686"
seems to be a sequence where the Pre-Depends never breaks. Since
libc6-i686 is not needed for the system to function properly, removing
it temporarily is not a problem. Now the question is can it be
generalized to other packages?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#550099: readahead: re-runs profile at every boot

[Gabor Gombas]

On Thu, Oct 08, 2009 at 07:55:32PM +0200, Petter Reinholdtsen wrote:

> This sound like a bug.  The trigger was intended to only trigger when
> a new package affecting the boot system is installed, and I guess you
> do not do that every day.

No, but IMHO that's not how the trigger works. The trigger is activated
even if existing files under /etc/init.d change, not just when new files
are added or old files are deleted. I see there is also a trigger for
/lib/modules and I did test a couple of kernel versions lately. It may
have been a busier than average period, but it is a Sid box meant for
development/experimenting after all...

> Is the file /etc/readahead/profile-once removed once the profiling is
> done?  It should be removed during a profiled boot.

That works.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#524098: xserver-xorg: dependency on console-setup broke keyboard settings

[Gabor Gombas]

Hi,

On Tue, Sep 15, 2009 at 12:34:33AM +0300, Valery V. Vorotyntsev wrote:

> I've upgraded xserver-xorg (I run `testing'). It came with new dependencies
> (hal, console-setup) and made my keyboard hardly usable. I was lucky enough
> to find Gabor's bug report (thanks, Gabor!). I've commented out contents of
> /usr/share/hal/fdi/policy/10osvendor/debian-x11-keymap.fdi and restarted hal
> and gdm; now my keyboard is working properly.

Editing the file is not that good since you have to repeat it after
every upgrade. Diverting the file (see dpkg-divert) is better, just
make sure the new name does not have a .fdi extension.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 -



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

Bug#545179: libc6: postinst must run "telinit u"

[Gabor Gombas]

On Mon, Sep 07, 2009 at 10:46:34AM +0200, Bastian Blank wrote:

> > I really can't explain you why the behaviour is still the same.
> 
> The mentioned bug shows a different problem.

I suspect that the referenced bug report was made with "/" being ext2,
while nowadays ext3 is the default. If I'm right, then the automatic
journal replay prevents fsck from complaining.

Hmm, I've found the logs of the first boot after the last libc upgrade:

dpkg.log fragment:

2009-08-31 21:36:58 status installed libc6 2.9-26

messages.log indicates the machine was shut down properly:

Aug 31 21:41:09 twister shutdown[20750]: shutting down for system halt
Aug 31 21:41:16 twister kernel: Kernel logging (proc) stopped.
Aug 31 21:41:16 twister kernel: Kernel log daemon terminating.
Aug 31 21:41:26 twister exiting on signal 15

kernel.log of the next boot:

Sep  1 07:11:31 twister kernel: [4.286170] EXT3-fs: INFO: recovery required 
on readonly filesystem.
Sep  1 07:11:31 twister kernel: [4.286272] EXT3-fs: write access will be 
enabled during recovery.
Sep  1 07:11:31 twister kernel: [4.480816] kjournald starting.  Commit 
interval 5 seconds
Sep  1 07:11:31 twister kernel: [4.480934] EXT3-fs: md0: orphan cleanup on 
readonly fs
Sep  1 07:11:31 twister kernel: [4.481039] ext3_orphan_cleanup: deleting 
unreferenced inode 658
Sep  1 07:11:31 twister kernel: [4.481076] ext3_orphan_cleanup: deleting 
unreferenced inode 529
Sep  1 07:11:31 twister kernel: [4.490777] ext3_orphan_cleanup: deleting 
unreferenced inode 527
Sep  1 07:11:31 twister kernel: [4.625170] EXT3-fs: md0: 3 orphan inodes 
deleted
Sep  1 07:11:31 twister kernel: [4.625272] EXT3-fs: recovery complete.
Sep  1 07:11:31 twister kernel: [4.628012] EXT3-fs: mounted filesystem with 
ordered data mode.
Sep  1 07:11:31 twister kernel: [4.628130] VFS: Mounted root (ext3 
filesystem) readonly on device 9:0.

So it's now the kernel that complains about the unclean shutdown
instead of fsck, but the issue seems to be very much the same.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#476184: For the grub maintainers II

[Gabor Gombas]

On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:

> Robert filed already after the upload of grub-legacy a RC bug so it
> doestn't migrate after the usual 10 days to testing.
> 
> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> does because of 491872
> So if anyone want to help that we Recommend it again, then help the
> os-prober maintainers to fix that bug.

I don't know the specifics, but wouldn't it be possible for os-prober to
create its own private mount name space (see clone(2), CLONE_NEWNS),
and do the probing inside that name space? That way the desktop
environments would not be able to intercept it.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#429243: stopped working, SSH stopped logging failures!

[Gabor Gombas]

On Wed, Sep 02, 2009 at 02:30:11PM +0100, Colin Watson wrote:

> > Maybe a better option would be to let rsyslog automatically create the
> > directory for the socket if it is missing?
> 
> If it created the socket itself as well, then that might do the job.
> We'd need to make sure permissions were consistent.

IMHO there are three cases to consider:

- A package wants to specify a location that is supposed to be
  non-volatile. In this case the directory is owned by the package,
  and there is no need to auto-create. This is the case for e.g.
  postfix.

- A package wants to specify a location that is (probably) volatile. In
  this case the package already has to have code to create the directory
  and fix the permissions if needed. This is the case for openssh.

- The sysadmin wants to add an extra listener location.

For the first two cases, it's not really the job of rsyslog etc. to get
the permissions right, so always using root:root & mode 755 is enough.
For the last case, being able to specify the default owner/permissions
in the syslog config. file would be nice, but it is not in the scope of
this bug report.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#429243: stopped working, SSH stopped logging failures!

[Gabor Gombas]

On Wed, Sep 02, 2009 at 12:07:58PM +0200, Rainer Gerhards wrote:

> Some time ago, Michael and I briefly discussed the possibility that
> rsyslogd would defer some of its configuration statements to solve such
> split situations. Actually, what we discussed was more complex, but I
> wonder if a somewhat simpler solution might solve a practical need: What
> if we could instruct the socket listener to defer getting activated by
> some (fixed, but configurable) period. Something along the lines of
> 
> $IMUXSockDelayListen 60
> 
> to delay listening by 60 seconds after startup. I think I could quickly
> implement such a functionality (in v4-devel) if and only if the delay
> applies to all sockets. Not sure if that constraints renders the idea
> unusable.

That would mean losing logs in the first 1 minute after boot. If that's
tolerable, then it would be much easier to just modify the order of the
init scripts, and start ssh _before_ the syslog daemon. That way the
amount of lost logs is much smaller.

Maybe a better option would be to let rsyslog automatically create the
directory for the socket if it is missing?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#543496: [php-maint] Bug#543496: php5-gd: segmentation fault in phpinfo()

[Gabor Gombas]

On Tue, Aug 25, 2009 at 02:27:02PM +0200, Ondřej Surý wrote:
> Hi Gábor,
> 
> can you try this patch?
> 
> diff --git a/ext/gd/libgd/gd_compat.c b/ext/gd/libgd/gd_compat.c
> index bba6234..473ea20 100644
> --- a/ext/gd/libgd/gd_compat.c
> +++ b/ext/gd/libgd/gd_compat.c
> @@ -14,7 +14,7 @@ int gdJpegGetVersionInt()
>   return JPEG_LIB_VERSION;
>  }
> 
> -int gdJpegGetVersionString()
> +const char * gdJpegGetVersionString()
>  {
>   switch(JPEG_LIB_VERSION) {
>   case 62:
> diff --git a/ext/gd/libgd/gd_compat.h b/ext/gd/libgd/gd_compat.h
> index 022d0a8..c084a00 100644
> --- a/ext/gd/libgd/gd_compat.h
> +++ b/ext/gd/libgd/gd_compat.h
> @@ -8,7 +8,7 @@
>  #endif
> 
>  const char * gdPngGetVersionString();
> -int gdJpegGetVersionString();
> +const char * gdJpegGetVersionString();
>  int gdJpegGetVersionInt();
>  int overflow2(int a, int b);
> 
> It's ok, just to copy ext/gd outside php source tree, install
> php5-dev, run phpize && configure && make && make install

Actually I needed "./configure --with-jpeg-dir --with-png-dir
--with-zlib-dir --with-xpm-dir --with-freetype-dir --with-t1lib" because
./configure did not find the libraries otherwise, but after that the
patch seems to work fine. Thanks.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#524098: xserver-xorg: dependency on console-setup broke keyboard settings

[Gabor Gombas]

On Fri, Apr 17, 2009 at 09:50:55AM +0200, Julien Cristau wrote:

> i expect that whatever's in /etc (configuration) overrides whatever's
> in /usr (defaults), yes.

My confiuration in /etc does override 10-keymap.fdi, but that's not what
causing the problem. The problem comes from the fact that the settings
in /etc and debian-x11-keymap.fdi do _not_ conflict and therefore there
is nothing to override:

- in /etc, I say "set input.xkb.layout to X when keyboard Y is found"
- debian-x11-keymap.fdi says "run debian-setup-keyboard whenever a
  keyboard is found"

The two requests are orthogonal, so HAL obeys both. It just happens that
debian-setup-keyboard then blows the configuration that has been set in
/etc. But since HAL has not the slightest idea what
debian-setup-keyboard will do, it cannot possibly prevent that.

> > Yes you can. You can request the HAL maintainers to disable that script
> > (IMHO the directory is called "OS vendor" for a reason), and then depend
> > on the corrected HAL version.
> > 
> sigh.  that would still mean a change in hal first, wouldn't it?

Not sure, just diverting
/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi should also work.
Just be careful that it also contains a callout to hal-setup-keymap and
I have't got a clue what that command does.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#524098: xserver-xorg: dependency on console-setup broke keyboard settings

[Gabor Gombas]

On Thu, Apr 16, 2009 at 07:15:03PM +0200, Julien Cristau wrote:

> > Yes, that works (at least lshal now returns the correct values; I have
> > long-running jobs so I can't log out to test if X receives them). From
> > what little I understand from HAL, the call to debian-setup-keyboard
> > happens _after_ procesing the .fdi files, so it will always overwrite
> > any custom configuration unconditionally.
> > 
> that still sounds like a hal bug to me.

I don't think so. You specify in a config file that it should run a
script that updates the configuration, but you expect that script to run
_before_ parsing the config files?

> 
> > You should probably not only check for the existence of the input.xkb.*
> > keys, but also that all keys still have the default value. Probably you
> > should remove the xkb-specific part from
> > /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi, and
> 
> that's shipped by hal, so xserver-xorg can't do anything about that.

Yes you can. You can request the HAL maintainers to disable that script
(IMHO the directory is called "OS vendor" for a reason), and then depend
on the corrected HAL version.

> > debian-setup-keyboard should only set the input.xkb.* properties if they
> > are _all_ empty (otherwise it would be difficult to distinguish the
> > "layout is US by default" and the "layout has been explicitely set to
> > US" cases).
> > 
> i don't think debian-setup-keyboard can distinguish between 'layout set
> by hal's 10-keymap.fdi' and 'layout set by the user's config' currently.

I've just described how you can do it in my previous mail.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#524098: xserver-xorg: dependency on console-setup broke keyboard settings

[Gabor Gombas]

reassign 524098 xserver-xorg
thanks

On Tue, Apr 14, 2009 at 10:46:24PM +0200, Brice Goglin wrote:

> In the meantime, you can trying moving away
> /usr/share/hal/fdi/policy/10osvendor/debian-x11-keymap.fdi

Yes, that works (at least lshal now returns the correct values; I have
long-running jobs so I can't log out to test if X receives them). From
what little I understand from HAL, the call to debian-setup-keyboard
happens _after_ procesing the .fdi files, so it will always overwrite
any custom configuration unconditionally.

You should probably not only check for the existence of the input.xkb.*
keys, but also that all keys still have the default value. Probably you
should remove the xkb-specific part from
/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi, and
debian-setup-keyboard should only set the input.xkb.* properties if they
are _all_ empty (otherwise it would be difficult to distinguish the
"layout is US by default" and the "layout has been explicitely set to
US" cases).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454147: Stuck bootlogd causes kernel crash

[Gabor Gombas]

clone 454147 -1
reassign -1 linux-image-2.6.26-1-xen-amd64
retitle -1 Stuck bootlogd causes kernel crash
thanks

Hi,

After upgrading some Xen domUs from the 2.6.18 etch kernel to the lenny
kernel, I got hit by bug #454147, but so far only when the dom0 kernel
is also from lenny. Moreover, if I do not kill the runaway bootlogd
process, then after about a day the domU crashes quite reliably. I now
managed to capture the OOPS:

Feb 17 02:10:18 host kernel: [60252.521849] [ cut here ]
Feb 17 02:10:19 host kernel: [60252.521868] kernel BUG at 
drivers/char/tty_io.c:811!
Feb 17 02:10:19 host kernel: [60252.521874] invalid opcode:  [1] SMP 
Feb 17 02:10:19 host kernel: [60252.521881] CPU 0 
Feb 17 02:10:19 host kernel: [60252.521886] Modules linked in: ipv6 evdev ext3 
jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod thermal_sys
Feb 17 02:10:19 host kernel: [60252.521909] Pid: 896, comm: bootlogd Not 
tainted 2.6.26-1-xen-amd64 #1
Feb 17 02:10:19 host kernel: [60252.521915] RIP: e030:[]  
[] tty_ldisc_put+0x34/0x5e
Feb 17 02:10:19 host kernel: [60252.521933] RSP: e02b:8800016e1e18  EFLAGS: 
00010046
Feb 17 02:10:19 host kernel: [60252.521939] RAX:  RBX: 
 RCX: 
Feb 17 02:10:19 host kernel: [60252.521945] RDX:  RSI: 
880001d0fb00 RDI: 806000a4
Feb 17 02:10:19 host kernel: [60252.521952] RBP:  R08: 
805081a1 R09: 88000207e000
Feb 17 02:10:19 host kernel: [60252.521958] R10: 88000ec9c980 R11: 
0003 R12: 
Feb 17 02:10:19 host kernel: [60252.521965] R13:  R14: 
 R15: 88e98a80
Feb 17 02:10:19 host kernel: [60252.521974] FS:  7fd23107a6e0() 
GS:80539000() knlGS:
Feb 17 02:10:19 host kernel: [60252.521983] CS:  e033 DS:  ES: 
Feb 17 02:10:19 host kernel: [60252.521989] DR0:  DR1: 
 DR2: 
Feb 17 02:10:19 host kernel: [60252.521995] DR3:  DR6: 
0ff0 DR7: 0400
Feb 17 02:10:19 host kernel: [60252.522003] Process bootlogd (pid: 896, 
threadinfo 8800016e, task 88000e1d9780)
Feb 17 02:10:19 host kernel: [60252.522011] Stack:  88e98a80 
88000ec9c800  8035cad0
Feb 17 02:10:19 host kernel: [60252.522024]  000c39082430  
00020003 80436597
Feb 17 02:10:19 host kernel: [60252.522035]  0003 88000fc16080 
88000fc16080 88000f95a7d0
Feb 17 02:10:19 host kernel: [60252.522044] Call Trace:
Feb 17 02:10:19 host kernel: [60252.522053]  [] 
release_dev+0x546/0x5ce
Feb 17 02:10:19 host kernel: [60252.522061]  [] 
tty_release+0x11/0x1a
Feb 17 02:10:19 host kernel: [60252.522069]  [] 
__fput+0xa1/0x16b
Feb 17 02:10:19 host kernel: [60252.522076]  [] 
filp_close+0x5d/0x65
Feb 17 02:10:19 host kernel: [60252.522082]  [] 
sys_close+0xa5/0x109
Feb 17 02:10:19 host kernel: [60252.522090]  [] 
system_call+0x68/0x6d
Feb 17 02:10:19 host kernel: [60252.522096]  [] 
system_call+0x0/0x6d
Feb 17 02:10:19 host kernel: [60252.522102] 
Feb 17 02:10:19 host kernel: [60252.522106] 
Feb 17 02:10:19 host kernel: [60252.522110] Code: ff 11 76 04 0f 0b eb fe 48 c7 
c7 a4 00 60 80 e8 ec c0 0d 00 48 89 c5 48 63 c3 48 69 d0 90 00 00 00 8b 82 48 
01 60 80 85 c0 75 04 <0f> 0b eb fe 48 8b ba 40 01 60 80 ff c8 89 82 48 01 60 80 
e8 c3 

After logging the OOPS the domU becomes unresponsive both on the console
and over the network.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#514578: libgnutls26: LDAP STARTTLS is broken

[Gabor Gombas]

On Mon, Feb 09, 2009 at 01:40:59PM +0100, Simon Josefsson wrote:

> Please provide output from:
> 
> gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert

Here it is:

|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[8a6c0b8]: Sending extension CERT_TYPE
|<2>| EXT[8a6c0b8]: Sending extension SERVER_NAME
|<3>| HSK[8a6c0b8]: CLIENT HELLO was send [132 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8a6c0b8]: Sending Packet[0] Handshake(22) with length: 132
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 137 bytes to 4.
|<7>| WRITE: wrote 137 bytes to 4. Left 0 bytes. Total 137 bytes.
|<7>|  - 16 03 02 00 84 01 00 00 80 03 02 49 90 4e 7f 0b 
|<7>| 0001 - bc b1 4e bf e1 12 b4 1f 73 3d 1a ab ba e9 2e 8f 
|<7>| 0002 - a9 36 54 d0 4e 13 41 5f a4 25 a7 00 00 34 00 33 
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
|<7>| 0004 - 00 13 00 66 00 90 00 91 00 8f 00 8e 00 2f 00 41 
|<7>| 0005 - 00 35 00 84 00 0a 00 05 00 04 00 8c 00 8d 00 8b 
|<7>| 0006 - 00 8a 01 00 00 23 00 09 00 03 02 00 01 00 00 00 
|<7>| 0007 - 18 00 16 00 00 13 64 69 72 65 63 74 6f 72 79 2e 
|<7>| 0008 - 73 7a 74 61 6b 69 2e 68 75 
|<4>| REC[8a6c0b8]: Sent Packet[1] Handshake(22) with length: 137
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>|  - 16 03 01 07 aa 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8a6c0b8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8a6c0b8]: Received Packet[0] Handshake(22) with length: 1962
|<7>| READ: Got 1962 bytes from 4
|<7>| READ: read 1962 bytes from 4
|<7>|  - 02 00 00 46 03 01 00 17 79 81 1c fd e7 bb ef a4 
|<7>| 0001 - ca d7 82 58 6d 37 6a 05 f2 cd 4a c3 d8 95 c8 fe 
|<7>| 0002 - d5 9b 69 32 28 97 20 7c 46 79 c2 d3 6f 14 95 a5 
|<7>| 0003 - 84 72 2c 57 51 06 5a 4c 51 46 e7 00 bc 0a 13 b2 
|<7>| 0004 - a4 ab 33 67 e1 7b b5 00 04 00 0b 00 07 58 00 07 
|<7>| 0005 - 55 00 03 a1 30 82 03 9d 30 82 03 06 a0 03 02 01 
|<7>| 0006 - 02 02 01 3e 30 0d 06 09 2a 86 48 86 f7 0d 01 01 
|<7>| 0007 - 04 05 00 30 81 9b 31 0b 30 09 06 03 55 04 06 13 
|<7>| 0008 - 02 48 55 31 11 30 0f 06 03 55 04 08 13 08 42 75 
|<7>| 0009 - 64 61 70 65 73 74 31 11 30 0f 06 03 55 04 07 13 
|<7>| 000a - 08 42 75 64 61 70 65 73 74 31 13 30 11 06 03 55 
|<7>| 000b - 04 0a 13 0a 4d 54 41 20 53 5a 54 41 4b 49 31 0d 
|<7>| 000c - 30 0b 06 03 55 04 0b 13 04 49 54 41 4b 31 1e 30 
|<7>| 000d - 1c 06 03 55 04 03 13 15 43 65 72 74 69 66 69 63 
|<7>| 000e - 61 74 65 20 41 75 74 68 6f 72 69 74 79 31 22 30 
|<7>| 000f - 20 06 09 2a 86 48 86 f7 0d 01 09 01 16 13 73 79 
|<7>| 0010 - 73 2d 61 64 6d 69 6e 40 73 7a 74 61 6b 69 2e 68 
|<7>| 0011 -

Bug#488273: linux-image-2.6.25-2-amd64: Hangs on a Dell Poweredge 850

[Gabor Gombas]

On Sat, Dec 27, 2008 at 02:44:21PM +0100, Moritz Muehlenhoff wrote:

> Does this error still occur with more recent kernel versions?

No idea, all our Dells are now running Mandriva with a 2.6.18-based Xen
kernel, and there is no chance in the near future to try Debian on them
again. I've had other affected machines but they were/are running
vanilla kernels, not Debian provided ones. On these other machines, the
bug has been fixed in 2.6.27 upstream.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC

[Gabor Gombas]

On Fri, Dec 26, 2008 at 06:49:05PM +0100, Moritz Muehlenhoff wrote:

> Does this error still occur with more recent kernel versions?

I've tried once during the christmas holidays with 2.6.26 and it worked,
so the bug can be closed.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#506221: Acknowledgement (xserver-xorg-video-intel: server crash)

[Gabor Gombas]

Hi,

The kernel logs in the original report were from the wrong boot, these
are the ones corresponding to the crash:

Nov 19 14:07:49 boogie kernel: [  207.154936] [drm] Initialized drm 1.1.0 
20060810
Nov 19 14:07:50 boogie kernel: [  207.237253] pci :00:02.0: PCI INT A -> 
GSI 16 (level, low) -> IRQ 16
Nov 19 14:07:50 boogie kernel: [  207.237267] pci :00:02.0: setting latency 
timer to 64
Nov 19 14:07:50 boogie kernel: [  207.237448] [drm] Initialized i915 1.6.0 
20060119 on minor 0
Nov 19 14:07:52 boogie kernel: [  210.402737] set status page addr 0x00033000
Nov 19 14:07:53 boogie kernel: [  211.261957] Xorg:3874 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:07:53 boogie kernel: [  211.261976] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:07:56 boogie kernel: [  214.297070] Xorg:3874 freeing invalid memtype 
d000-e000
Nov 19 14:08:00 boogie kernel: [  218.376895] ioctl32(Xorg:4560): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ffee7da8) on /var/log/Xorg.0.log
Nov 19 14:08:00 boogie kernel: [  218.413101] ioctl32(Xorg:4560): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ffee7ee8) on /var/log/Xorg.0.log
Nov 19 14:08:01 boogie kernel: [  219.700675] set status page addr 0x00033000
Nov 19 14:08:01 boogie kernel: [  219.740887] Xorg:4560 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:08:01 boogie kernel: [  219.740905] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:08:02 boogie kernel: [  220.026942] Xorg:4560 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:08:02 boogie kernel: [  220.026960] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:08:02 boogie kernel: [  220.030144] Xorg:4866 freeing invalid memtype 
d000-e000
Nov 19 14:08:02 boogie kernel: [  220.301936] Xorg:4560 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:08:02 boogie kernel: [  220.301956] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:08:02 boogie kernel: [  220.305298] Xorg:4910 freeing invalid memtype 
d000-e000
Nov 19 14:08:02 boogie kernel: [  220.393629] Xorg:4560 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:08:02 boogie kernel: [  220.393648] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:08:02 boogie kernel: [  220.396915] Xorg:4912 freeing invalid memtype 
d000-e000
Nov 19 14:08:02 boogie kernel: [  220.481725] Xorg:4560 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:08:02 boogie kernel: [  220.481744] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:08:02 boogie kernel: [  220.484706] Xorg:4914 freeing invalid memtype 
d000-e000
Nov 19 14:11:53 boogie kernel: [  451.715561] [drm:drm_update_drawable_info] 
*ERROR* Failed to copy cliprects from userspace
Nov 19 14:11:56 boogie kernel: [  454.732034] [drm:i915_wait_irq] *ERROR* EBUSY 
-- rec: 2 emitted: 5
Nov 19 14:23:56 boogie kernel: [ 1174.660621] Xorg:4560 freeing invalid memtype 
d000-e000
Nov 19 14:23:58 boogie kernel: [ 1176.460322] ioctl32(Xorg:6498): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ff7fd6c8) on /var/log/Xorg.0.log
Nov 19 14:23:58 boogie kernel: [ 1176.496491] ioctl32(Xorg:6498): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ff7fd808) on /var/log/Xorg.0.log
Nov 19 14:23:59 boogie kernel: [ 1177.571387] set status page addr 0x00033000
Nov 19 14:23:59 boogie kernel: [ 1177.615722] Xorg:6498 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:23:59 boogie kernel: [ 1177.615740] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:24:02 boogie kernel: [ 1180.076294] Xorg:6498 freeing invalid memtype 
d000-e000
Nov 19 14:24:07 boogie kernel: [ 1185.262682] ioctl32(Xorg:6513): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ff839708) on /var/log/Xorg.0.log
Nov 19 14:24:07 boogie kernel: [ 1185.298945] ioctl32(Xorg:6513): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ff839848) on /var/log/Xorg.0.log
Nov 19 14:24:08 boogie kernel: [ 1186.290967] set status page addr 0x00033000
Nov 19 14:24:08 boogie kernel: [ 1186.329569] Xorg:6513 conflicting memory 
types d000-e000 write-combining<->uncached-minus
Nov 19 14:24:08 boogie kernel: [ 1186.329587] reserve_memtype failed 
0xd000-0xe000, track write-combining, req write-combining
Nov 19 14:24:10 boogie kernel: [ 1188.773301] Xorg:6513 freeing invalid memtype 
d000-e000
Nov 19 14:24:15 boogie kernel: [ 1193.347721] ioctl32(Xorg:6534): Unknown cmd 
fd(0) cmd(40086408){t:'d';sz:8} arg(ffdbac88) on 

Bug#504607: snort: spams syslog since the last security update

[Gabor Gombas]

Package: snort-pgsql
Version: 2.7.0-19+lenny1
Severity: normal


Hi,

Since upgrading to 2.7.0-19+lenny1, snort spams syslog with messages like:

Nov  5 16:39:20 host snort[13133]: ˆ²–m(1838592624) ==> The ttl_limit option 
will be ignored, and Use of the ttl_limit option will be deprecated in a future 
release
Nov  5 16:39:20 host snort[13133]: @²–m(1838592624) ==> The ttl_limit option 
will be ignored, and Use of the ttl_limit option will be deprecated in a future 
release
Nov  5 16:39:20 host snort[13133]: @²–m(1838592648) ==> The ttl_limit option 
will be ignored, and Use of the ttl_limit option will be deprecated in a future 
release
Nov  5 16:39:20 host snort[13133]: X²–m(1838592648) ==> The ttl_limit option 
will be ignored, and Use of the ttl_limit option will be deprecated in a future 
release

snort.conf mentions the ttl_limit option only in comments, so I have no idea
why does it complain. Also note the garbage at the beginning of the log
messages.

Gabor

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

Kernel: Linux 2.6.22-3-amd64 (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 snort-pgsql depends on:
ii  adduser3.110 add and remove users and groups
ii  debconf [debconf-2.0]  1.5.22Debian configuration management sy
ii  libc6  2.7-15GNU C Library: Shared libraries
ii  libgcrypt111.4.1-1   LGPL Crypto library - runtime libr
ii  libgnutls262.4.2-1   the GNU TLS library - runtime libr
ii  libgpg-error0  1.4-2 library for common error values an
ii  libltdl3   1.5.26-4  A system independent dlopen wrappe
ii  libpcap0.8 0.9.8-5   system interface for user-level pa
ii  libpcre3   7.6-2.1   Perl 5 Compatible Regular Expressi
ii  libpq5 8.3.4-2   PostgreSQL C client library
ii  libprelude20.9.18.1-1Hybrid Intrusion Detection System 
ii  libtasn1-3 1.4-1 Manage ASN.1 structures (runtime)
ii  logrotate  3.7.1-5   Log rotation utility
ii  snort-common   2.7.0-19+lenny1   flexible Network Intrusion Detecti
ii  snort-common-libraries 2.7.0-19+lenny1   flexible Network Intrusion Detecti
ii  snort-rules-default2.7.0-19+lenny1   flexible Network Intrusion Detecti
ii  syslog-ng [system-log- 2.0.9-4   Next generation logging daemon
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages snort-pgsql recommends:
ii  iproute   20080725-2 networking and traffic control too

Versions of packages snort-pgsql suggests:
ii  snort-doc2.7.0-19+lenny1 Documentation for the Snort IDS [d

-- debconf information excluded



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

Bug#503999: memory corruption in libcurl

[Gabor Gombas]

reassign 503999 libcurl3 7.18.2-5
severity 503999 important
retitle 503999 libcurl3: memory corruption due to use-after-free
thanks

Hi,

Running boinc-client under valgrind shows that the bug is likely to be
in libcurl:

==29933== Invalid write of size 8
==29933==at 0x56071A8: multi_runsingle (multi.c:907)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933==  Address 0x8d642f0 is 0 bytes inside a block of size 1,384 free'd
==29933==at 0x4C20B6E: free (vg_replace_malloc.c:323)
==29933==by 0x55F3017: Curl_disconnect (url.c:2216)
==29933==by 0x55F5001: CreateConnection (url.c:2506)
==29933==by 0x55F513A: Curl_connect (url.c:4350)
==29933==by 0x56076A4: multi_runsingle (multi.c:926)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933== 
==29933== Invalid read of size 8
==29933==at 0x560724D: multi_runsingle (multi.c:1334)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933==  Address 0x8d645b8 is 712 bytes inside a block of size 1,384 free'd
==29933==at 0x4C20B6E: free (vg_replace_malloc.c:323)
==29933==by 0x55F3017: Curl_disconnect (url.c:2216)
==29933==by 0x55F5001: CreateConnection (url.c:2506)
==29933==by 0x55F513A: Curl_connect (url.c:4350)
==29933==by 0x56076A4: multi_runsingle (multi.c:926)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933== 
==29933== Invalid read of size 8
==29933==at 0x55F2CE7: Curl_removeHandleFromPipeline (url.c:2279)
==29933==by 0x5607258: multi_runsingle (multi.c:1334)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933==  Address 0x8ee1a08 is 0 bytes inside a block of size 32 free'd
==29933==at 0x4C20B6E: free (vg_replace_malloc.c:323)
==29933==by 0x55F2EC1: conn_free (url.c:2125)
==29933==by 0x55F3017: Curl_disconnect (url.c:2216)
==29933==by 0x55F5001: CreateConnection (url.c:2506)
==29933==by 0x55F513A: Curl_connect (url.c:4350)
==29933==by 0x56076A4: multi_runsingle (multi.c:926)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933== 
==29933== Invalid read of size 1
==29933==at 0x5606FFB: checkPendPipeline (multi.c:1976)
==29933==by 0x5607261: multi_runsingle (multi.c:1337)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop() (main.C:473)
==29933==by 0x5FEA1A5: (below main) (in /lib/libc-2.7.so)
==29933==  Address 0x8d645aa is 698 bytes inside a block of size 1,384 free'd
==29933==at 0x4C20B6E: free (vg_replace_malloc.c:323)
==29933==by 0x55F3017: Curl_disconnect (url.c:2216)
==29933==by 0x55F5001: CreateConnection (url.c:2506)
==29933==by 0x55F513A: Curl_connect (url.c:4350)
==29933==by 0x56076A4: multi_runsingle (multi.c:926)
==29933==by 0x5607D4A: curl_multi_perform (multi.c:1460)
==29933==by 0x43A606: HTTP_OP_SET::got_select(FDSET_GROUP&, double) 
(http_curl.C:912)
==29933==by 0x4133FE: CLIENT_STATE::do_io_or_sleep(double) 
(client_state.C:417)
==29933==by 0x43D03C: boinc_main_loop(

Bug#496967: general: System completely blocks any input

[Gabor Gombas]

On Mon, Sep 01, 2008 at 09:04:35PM +0200, Frank Küster wrote:

> Although I personally feal the bug is super-duper-hyper-grave, I leave
> the judgement to the linux maintainers.

FYI: I've tried 2.6.27-rc5 and it is up for more than 15 hours now.
That's far more than 2.6.25/26 ever managed on this box (2.6.24 is rock
solid).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#485747: bind9: fails to start due to capability problems

[Gabor Gombas]

Hi,

I've rebuilt the bind9 package to use libcap2 instead of the
hand-crafted syscall invocation and that made the problem go away. So
adding libcap2-dev to the Build-Depends: should be enough to fix this
bug.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#485747: bind9: fails to start due to capability problems

[Gabor Gombas]

Hi,

I did some investigation. strace bind9 ends with this:

capset(0x20071026, 0, 
{CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
 
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
 0}) = -1 EINVAL (Invalid argument)
futex(0x38bf04f5c0, 0x81 /* FUTEX_??? */, 2147483647) = 0
write(2, "named: ", 7)  = 7
write(2, "syscall(capset) failed: Invalid "..., 111) = 111
write(2, "\n", 1)   = 1
exit_group(1)   = ?

If I try to emulate the above using 

capsh 
--caps='cap_dac_read_search,cap_setgid,cap_setuid,cap_net_bind_service,cap_sys_chroot,cap_sys_resource=ep'
 -- -c uname

strace gives this:

capset(0x19980330, 0, 
{CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
 
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
 0}) = 0

The passed capability list is the same, so the problem seems to lie in
the first argument of capset() that strace does not decode.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#483397: iceweasel: latest xulrunner update leaves iceweasel broken

[Gabor Gombas]

On Thu, May 29, 2008 at 12:48:50AM -0400, Eric Dorland wrote:
> * Gábor Gombás ([EMAIL PROTECTED]) wrote:
> > Package: iceweasel
> > Version: 3.0~b5-4
> > Severity: grave
> > Justification: renders package unusable
> > 
> > 
> > Hi,
> > 
> > After upgrading xulrunner-1.9 I get the following when I want to run
> > iceweasel:
> > 
> > $ iceweasel 
> > Error: Platform version '1.9' is not compatible with
> > minVersion >= 1.9b5
> > maxVersion <= 1.9b5
> 
> Did you upgrade to iceweasel 3.0rc1?

No, as it is not in the archive:

# apt-get update
[...]
# apt-cache policy iceweasel
iceweasel:
  Installed: 3.0~b5-4
  Candidate: 3.0~b5-4
  Version table:
 *** 3.0~b5-4 0
101 http://ftp.hu.debian.org experimental/main Packages
101 http://ftp.fi.debian.org experimental/main Packages
100 /var/lib/dpkg/status
 2.0.0.14-2 0
500 http://ftp.hu.debian.org lenny/main Packages
990 http://ftp.hu.debian.org unstable/main Packages
990 http://ftp.fi.debian.org unstable/main Packages
 2.0.0.12-0etch1 0
500 http://ftp.hu.debian.org etch/main Packages

Anyway, if iceweasel depends on the exact xulrunner version and not just
"anything recent enough", shouldn't that be reflected in the package
dependencies?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#481181: openssh-blacklist: There should be a description how to obtain/generate the blacklist for non-default key lengths

[Gabor Gombas]

On Wed, May 14, 2008 at 05:36:53PM +0100, Colin Watson wrote:

> The problem here is that the package gets inconveniently large ... this
> has to fit on CDs that include openssh-server.
> 
> Perhaps openssh-blacklist-extra or something would work.

For a start putting the extra blacklist on the web and adding a pointer
to README.Debian would be nice.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#481181: openssh-blacklist: There should be a description how to obtain/generate the blacklist for non-default key lengths

[Gabor Gombas]

On Wed, May 14, 2008 at 01:38:33PM +0100, Colin Watson wrote:
> On Wed, May 14, 2008 at 01:47:35PM +0200, Gábor Gombás wrote:
> > The package only contains a blacklist for 2048-bit RSA keys. There
> > should be a description how to obtain/generate the blacklist for other
> > key lengths.
> 
> That's called "exploit code", and I'm not willing to give it out yet,
> sorry.

Could you then at least provide blacklists for other commonly used key
sizes, like 1024, 1536, 3072 and 4096?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#474294: RFH: Chrony goes into endless loop on x86_64

[Gabor Gombas]

On Thu, Apr 24, 2008 at 02:21:39PM -0500, John Hasler wrote:
> Gabor writes:
> > That will be difficult since sometimes the bug does not hit for weeks and
> > then suddenly chrony starts to loop all the time.
> 
> Are you saying that you have seen the bug?

Yes, see bug #447011. In fact, #474294 is a duplicate of #447011...

> > So I'd say go ahead and upload the new version to unstable, and if there
> > are no new occurances of the bug for 1-2 months then you can close it.
> 
> Which would probably result in Chrony being removed from Lenny.

Well, then someone should start debugging it. The gdb trace sent by
Goshwin is quite promising. If UTI_NormaliseTimeval() is called with
x->tv_usec being a very large value (say LONG_MAX), that would clearly
explain the hang, and it would also explain why i386 does not seem to be
affected even if it is just as buggy as amd64: on i386, the while {}
loops execute at most 2147 times which is basically unnoticable, while
on amd64 that can be 2^32 times more.

So, IMHO turning the two while {} loops in UTI_NormaliseTimeval() into
divide/remainder operations should fix the hang. However, it still needs
investigation _why_ UTI_NormaliseTimeval() is being called with such a
bad time value, as it may be a result of a more severe bug like memory
corruption. Maybe upstream could help here.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -



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

Bug#470514: evolution: "Birthdays & anniversaries" unreliable and causes hang

[Gabor Gombas]

Package: evolution
Version: 2.12.3-1.1
Severity: normal


Hi,

The "Birthdays & Anniversaries" calendar seems to have some issues.

- Sometimes it works - I have no idea what does it like or does not
  like...
- Sometimes it shows just a tiny fraction of all entries. With the
  number of contacts I have, there should be about 2-3 birthday entries
  every day, but sometimes it only shows 1-2 per week.
- If I turn off the "Birthdays & Anniversaries" calendar and then I try
  to turn it on again, the GUI often hangs (the window is no longer
  updated, and it does not react when I want to close the window with
  the mouse).

This issue is not new, I remember having it for at least half a year or
even more, but so far I was lazy to report.

Gabor

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

Kernel: Linux 2.6.24.3 (SMP w/2 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 evolution depends on:
ii  dbus1.1.20-1 simple interprocess messaging syst
ii  evolution-common2.12.3-1.1   architecture independent files for
ii  evolution-data-serv 1.12.3-1 evolution database backend server
ii  gconf2  2.22.0-1 GNOME configuration database syste
ii  gnome-icon-theme2.20.0-1 GNOME Desktop icon theme
ii  gtkhtml3.14 3.16.1-1 HTML rendering/editing library - b
ii  libart-2.0-22.3.20-1 Library of functions for 2D graphi
ii  libatk1.0-0 1.20.0-1 The ATK accessibility toolkit
ii  libbonobo2-02.21.90-1Bonobo CORBA interfaces library
ii  libbonoboui2-0  2.21.90-1The Bonobo UI library
ii  libc6   2.7-9GNU C Library: Shared libraries
ii  libcairo2   1.4.14-1 The Cairo 2D vector graphics libra
ii  libcamel1.2-10  1.12.3-1 The Evolution MIME message handlin
ii  libdbus-1-3 1.1.20-1 simple interprocess messaging syst
ii  libdbus-glib-1-20.74-1   simple interprocess messaging syst
ii  libebook1.2-9   1.12.3-1 Client library for evolution addre
ii  libecal1.2-71.12.3-1 Client library for evolution calen
ii  libedataserver1.2-9 1.12.3-1 Utility library for evolution data
ii  libedataserverui1.2 1.12.3-1 GUI utility library for evolution 
ii  libegroupwise1.2-13 1.12.3-1 Client library for accessing group
ii  libexchange-storage 1.12.3-1 Backend library for evolution cale
ii  libfontconfig1  2.5.0-2  generic font configuration library
ii  libfreetype62.3.5-1+b1   FreeType 2 font engine, shared lib
ii  libgconf2-4 2.22.0-1 GNOME configuration database syste
ii  libglade2-0 1:2.6.2-1library to load .glade files at ru
ii  libglib2.0-02.16.1-1 The GLib library of C routines
ii  libgnome-pilot2 2.0.15-2.1   Support libraries for gnome-pilot
ii  libgnome2-0 2.20.1.1-1   The GNOME 2 library - runtime file
ii  libgnomecanvas2-0   2.20.1.1-1   A powerful object-oriented display
ii  libgnomeui-02.20.1.1-1   The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0  1:2.22.0-1   GNOME Virtual File System (runtime
ii  libgtk2.0-0 2.12.8-1 The GTK+ graphical user interface 
ii  libgtkhtml3.14-19   3.16.1-1 HTML rendering/editing library - r
ii  libhal1 0.5.10+git20080301-1 Hardware Abstraction Layer - share
ii  libice6 2:1.0.4-1X11 Inter-Client Exchange library
ii  libldap-2.4-2   2.4.7-6.1OpenLDAP libraries
ii  libnm-glib0 0.6.5-5  network management framework (GLib
ii  libnotify1 [libnoti 0.4.4-3  sends desktop notifications to a n
ii  libnspr4-0d 4.7.0-2  NetScape Portable Runtime Library
ii  libnss3-1d  3.12.0~beta2-1   Network Security Service libraries
ii  liborbit2   1:2.14.10-0.1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0   1.20.0-1 Layout and rendering of internatio
ii  libpisock9  0.12.3-4 library for communicating with a P
ii  libpisync1  0.12.3-4 synchronization library for PalmOS
ii  libpng12-0  1.2.15~beta5-3   PNG library - runtime
ii  libpopt01.10-3   lib for parsing cmdline parameters
ii  libsm6  2:1.0.3-1+b1 X11 Session Management library
ii  libsoup2.2-82.2.105-4an HTTP library implementation in 
ii  libx11-62:1.1.4-1X11 client-side library
ii  libxcursor1 1:1.1.9-1

Bug#459762: sasl2-bin: postinst hangs

[Gabor Gombas]

Package: sasl2-bin
Version: 2.1.22.dfsg1-17
Severity: normal


Hi,

sasl2-bin's postinst hangs indefinitely after it has started saslauthd:

[...]
root  5794  0.0  0.1   8164  1816 pts/5S 2007   0:00
  |   \_ su -
root  5796  0.0  0.1   4912  1436 pts/5S 2007   0:00
  |   \_ -su
root 32745  0.9  2.0  25968 20916 pts/5S+   16:11   0:01
  |   \_ apt-get install sasl2-bin
root   529  0.1  0.7  10608  7348 pts/10   Ss+  16:11   0:00
  |   \_ /usr/bin/dpkg --status-fd 29 --configure db4.6-util 
sasl2-bin
root   530  0.5  1.3  17888 13804 pts/10   S+   16:11   0:00
  |   \_ /usr/bin/perl -w /usr/share/debconf/frontend 
/var/lib/dpkg/info/sasl2-bin.postinst configure 2.1.22.dfsg1-16
root   586  0.0  0.0  0 0 pts/10   Z+   16:11   0:00
  |   \_ [sasl2-bin.posti] 
[...]
root   644  0.0  0.0   8124   708 ?Ss   16:11   0:00 
/usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root   656  0.0  0.0   8124   440 ?S16:11   0:00  \_ 
/usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root   657  0.0  0.0   8124   324 ?S16:11   0:00  \_ 
/usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root   658  0.0  0.0   8124   324 ?S16:11   0:00  \_ 
/usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root   661  0.0  0.0   8124   324 ?S16:11   0:00  \_ 
/usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5

If I interrupt apt by pressing Ctrl+C and re-run "apt-get install
sasl2-bin", then I get:

Starting SASL Authentication Daemon: saslauthd (already running).

and the package is configured properly.

I remember having this problems with previous versions of sasl2-bin as
well but I've been too lazy to report it so far.

Gabor

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

Kernel: Linux 2.6.22.6 (SMP w/2 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 sasl2-bin depends on:
ii  db4.6-util4.6.21-5   Berkeley v4.6 Database Utilities
ii  debconf [debconf-2.0] 1.5.17 Debian configuration management sy
ii  libc6 2.7-5  GNU C Library: Shared libraries
ii  libcomerr21.40.4-1   common error description library
ii  libdb4.6  4.6.21-5   Berkeley v4.6 Database Libraries [
ii  libkrb53  1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries
ii  libldap2  2.1.30.dfsg-13.5   OpenLDAP libraries
ii  libpam0g  0.99.7.1-5 Pluggable Authentication Modules l
ii  libsasl2-22.1.22.dfsg1-17Cyrus SASL - authentication abstra
ii  libssl0.9.8   0.9.8g-3   SSL shared libraries
ii  lsb-base  3.1-24 Linux Standard Base 3.1 init scrip

sasl2-bin recommends no packages.

-- debconf information:
* cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
  cyrus-sasl2/purge-sasldb2: false
  cyrus-sasl2/upgrade-sasldb2-failed:
* sasl2-bin/saslauthd_method: kerberos5
  cyrus-sasl2/upgrade-sasldb2-backup-failed:



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

Bug#458081: apache2: Dies with floating point exception

[Gabor Gombas]

On Sun, Dec 30, 2007 at 01:21:34PM +0100, Stefan Fritsch wrote:

> I suspect that this is actually a bug in a php extension. Can you 
> please follow the instructions at
> 
> http://svn.debian.org/wsvn/pkg-apache/trunk/apache2/README.backtrace?op=file&rev=0&sc=0
> 
> to create a backtrace? (Ignore the apache2-dbg package because it does 
> not exist in etch.)

I've already enabled coredumping when I sent the original bug report.
Since then there was a single SIGFPE crash that did not produce a core
dump, and a second one, now SIGSEGV, that indeed looks like a PHP
bug (backtrace below). It may be that there are actually two bugs...

Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.
#0  0x2ae2bc0fa49e in zif_preg_grep () from 
/usr/lib/apache2/modules/libphp5.so
(gdb) bt full
#0  0x2ae2bc0fa49e in zif_preg_grep () from 
/usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#1  0x2ae2bc2f6227 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#2  0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#3  0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#4  0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#5  0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#6  0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#7  0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#8  0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#9  0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#10 0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#11 0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#12 0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#13 0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#14 0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#15 0x2ae2bc2f5cf0 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#16 0x2ae2bc2e5c43 in execute () from /usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#17 0x2ae2bc2c8ca9 in zend_execute_scripts () from 
/usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#18 0x2ae2bc289468 in php_execute_script () from 
/usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#19 0x2ae2bc3462b3 in php_ap2_register_hook () from 
/usr/lib/apache2/modules/libphp5.so
No symbol table info available.
#20 0x00432cf9 in ap_run_handler ()
No symbol table info available.
#21 0x00435e72 in ap_invoke_handler ()
No symbol table info available.
#22 0x00441fe8 in ap_process_request ()
No symbol table info available.
#23 0x0043f4cc in ap_register_input_filter ()
No symbol table info available.
#24 0x00439851 in ap_run_process_connection ()
No symbol table info available.
#25 0x00445961 in ap_graceful_stop_signalled ()
No symbol table info available.
#26 0x00445bd4 in ap_graceful_stop_signalled ()
No symbol table info available.
#27 0x00446476 in ap_mpm_run ()
No symbol table info available.
#28 0x00420e70 in main ()
No symbol table info available.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#458085: apache2.2-common: wrong permissions on /var/lock/apache2

[Gabor Gombas]

Hi,

On Sat, Dec 29, 2007 at 02:41:03AM +0100, Stefan Fritsch wrote:

> It was a bit unfortunate that the line had to be introduced in a 
> stable point release and caused a behaviour change, but it was 
> necessary to fix a different bug.

You could at least test for the existence of /var/lock/apache2 and
create it only if it's missing. If /var/lock/apache2 already exists just
leave it alone and do not change its ownership.

> This is quite fragile (because of includes, etc.) and we don't want to 
> do that. But it would make sense to either add a comment in 
> apache.conf that /etc/init.d/apache2 needs to be changed as well, or 
> to set the user via an envvar that can be used in both apache2.conf 
> and the init script.

If the initscript does not unconditionally change the permissions on
/var/lock/apache2 then I'm fine with a comment in apache.conf.

OTOH it could be nice to have an "apachectl dump" command that dumps
the parsed apache configuration so scripting would be easier...

Gabor



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

Bug#458085: apache2.2-common: wrong permissions on /var/lock/apache2

[Gabor Gombas]

Package: apache2.2-common
Version: 2.2.3-4+etch3
Severity: important


Hi,

/etc/init.d/apache2 contains an unconditional

install -d -o www-data /var/lock/apache2

If apache is configured to run under a different user than www-data (and
thus /var/lock/apache2 owned by this user), then this

- overrides permissions set by the administrator, which is IMHO
  a policy violation

- makes /var/lock/apache2 unwritable by apache

The init script must parse /etc/apache2/apache.conf and use the "User"
setting from there.

Gabor

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

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.3-4+etch3 utility programs for webservers
ii  libmagic1  4.17-5etch3   File type determination library us
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  mime-support   3.39-1MIME files 'mime.types' & 'mailcap
ii  net-tools  1.60-17   The NET-3 networking toolkit
ii  procps 1:3.2.7-3 /proc file system utilities

apache2.2-common recommends no packages.

-- no debconf information



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

Bug#458081: apache2: Dies with floating point exception

[Gabor Gombas]

Package: apache2-mpm-prefork
Version: 2.2.3-4+etch3
Severity: important


Hi,

Two days ago apache2 started crashing with this error message:

[Fri Dec 28 13:29:49 2007] [notice] child pid 12318 exit signal Floating point 
exception (8)

The kernel log also contains:

Dec 28 13:29:49 host kernel: apache2[12318] trap divide error rip:2ae061b2abe1 
rsp:7fff4d18a5d0 error:0

There are 3 distinct "rip" values out of ~30 such messages logged so far.
When the crashes started, we were still running 2.2.3-4+etch1. There are
several apache instances running on this machine but only one (that
serves webmail using Horde/Imp) crashes.

Gabor

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

Versions of packages apache2-mpm-prefork depends on:
ii  apa 2.2.3-4+etch3Next generation, scalable, extenda
ii  lib 1.2.7-8.2The Apache Portable Runtime Librar
ii  lib 1.2.7+dfsg-2 The Apache Portable Runtime Utilit
ii  lib 2.3.6.ds1-13etch4GNU C Library: Shared libraries
ii  lib 4.4.20-8 Berkeley v4.4 Database Libraries [
ii  lib 1.95.8-3.4   XML parsing C library - runtime li
ii  lib 2.1.30-13.3  OpenLDAP libraries
ii  lib 6.7+7.4-2Perl 5 Compatible Regular Expressi
ii  lib 8.1.9-0etch2 PostgreSQL C client library
ii  lib 3.3.8-1.1SQLite 3 shared library
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 universally unique id library

apache2-mpm-prefork recommends no packages.

-- no debconf information



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

Bug#457353: gdome2-xslt: should not be a Debian-native package

[Gabor Gombas]

On Thu, Dec 27, 2007 at 10:18:38AM -0800, Russ Allbery wrote:

> I don't think this is horribly relevant to what we're discussing, namely
> how to go about packaging software for inclusion in Debian.  Generating
> upstream-provided packages that don't meet Debian Policy and therefore
> won't be included in Debian but which are useful for some users is
> certainly of interest to some, but it seems rather off-topic for
> debian-devel.  We're focused on including software in Debian rather than
> creating problems like one sees in the Red Hat world where there are
> random RPMs scattered hither and yon all over the net that may or may not
> work together.

Well, this was in response to "having debian/ in upstream release is
harmful" opinions. You're right that the best thing would be to have
everything packaged officially, but in reality sometimes that just does
not work out, for various reasons:

- Having to work with unreleased development snapshots because the
  official release does not yet have some critical (for me) feature
- Maintainer not uploading new upstream versions for a long time
- Official package lacking some feature due to legal reasons that may be
  important for Debian as an organization but not for me as an
  individual

In these cases upstream help for creating a Debian package is really
nice as it saves me time. Of course it can be expected that the
upstream-provided packaging does not play nice together with official
Debian packages but as long as having to install unofficial packages is
the exception rather the norm I'm willing to pay that price.

> > There is also the method e.g. nut upstream uses that can be viewed as a
> > compromise: they put the upstream-provided packaging info into a
> > subdirectory (packaging/debian), so it does not conflict with the
> > distro-provided packaging.
> 
> This, of course, is ideal from a Debian packaging perspective.  It would
> be nice if more upstreams who feel like they *really* want to provide
> packaging files for Debian would use a strategy like this.

Maybe it should be described somewhere on www.debian.org why is this the
preferred method. I suspect most upstreams providing their own packaging
simply do not even aware that it may cause problems for distro makers.

> My experience, though, with maintainer-provided Debian packaging files
> except for the special case where the Debian and upstream maintainer are
> the same person is very poor.  The Debian packaging often hasn't been
> updated, doesn't reflect the current version of the package, may be
> written for some ancient release of Debian and sometimes won't work with
> unstable, and often has dependencies that reflect whatever the last person
> to touch it had sitting around on their system.  They maintain their
> Debian packaging about as well as they maintain their RPM spec files, but
> Debian puts more effort into integration and transitions and sloppy
> packaging is far more apparent than it is in the messy RPM universe.

In general I agree with you. However in my experience fixing the
upstream-provided packaging to the point when I'm able to build an
installable .deb is just 1-2 minutes, much less than having to create
debian/ from scratch. Yes, it is a hack, it may not be perfect (or it
may even be completely buggy from a packaging POV), but it saves _me_
time and that's what counts.

Maybe the webpage proposed above should also mention that binary
packages built using the upstream-provided packaging scripts should not
be put on the web, so it is less likely that people unaware of the
possible risks download & use them.

(Btw. I'm quite aware of the "RPM hell" problem. We're running
Scientific Linux on our grid nodes, and every gLite upgrade - even just
to update the CA certificates - tends to break the system in new and
exciting ways...)

> In most cases, the Debian packaging files end up just confusing users and
> the upstream maintainer would be better off deleting them and letting the
> Debian packager do their job.

In an ideal world, maybe. But until then they are useful.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#457353: gdome2-xslt: should not be a Debian-native package

[Gabor Gombas]

On Thu, Dec 27, 2007 at 05:04:17PM +0100, Vincent Danjean wrote:

> Gabor Gombas wrote:
> > You seem to make the mistake to think that the debian/ directory
> > provided by upstream is there to help the distro maintainer.
> [false assumptions]

Huh? I, as a user, routinely use upstream-provided debian/ directory to
create packages for some software (most frequently mplayer). So those are
not assumptions but facts.

And as a user, I can say that if e.g. the debian mplayer maintainer
considers the upstream-provided debian/ directory inconvenient, I
couldn't care less. If the upstream-provided packaging is not perfect or
does not fully follow Debian guidelines - I do not care, as long as it
_works_.

>   I remove the upstream debian/ directory because the program that
> create the diff.gz (dpkg-deb ?) does not record *removal* of files [1].
> It only record changes. And I need to remove some files...
>   A workaround can be to add 'rm debian/' in the 'clean' and 'configure'
> target of debian/rules but I think it is a lot clearer with a new
> upstream tarball without debian/ directory.

Then why not just do the unpacking of the upstream tarball from
debian/rules? That way you can use the unaltered upstream tarball yet
the .diff.gz will contain just your version of debian/.

There is also the method e.g. nut upstream uses that can be viewed as a
compromise: they put the upstream-provided packaging info into a
subdirectory (packaging/debian), so it does not conflict with the
distro-provided packaging.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -



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

Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC

[Gabor Gombas]

On Tue, Dec 25, 2007 at 11:30:32PM +0100, maximilian attems wrote:

> please report back if aboves fixes it.

Ok, but it may take 1-2 weeks when I'm next near that machine.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -



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

Bug#457353: gdome2-xslt: should not be a Debian-native package

[Gabor Gombas]

On Wed, Dec 26, 2007 at 03:16:36PM +0100, Vincent Danjean wrote:

>   I can tell you that this is not a easy way to cleanly package these
> softwares. I did not talk to upstream yet because I would like to present
> them new clean packages. Nevertheless, for now, I need to recreate a
> X.Y.Z+debian.1.orig.tar.gz without the debian/ directory so it is more
> difficult for a user to check that the orig.tar.gz has the same software
> as in the upstream site.

Why repack? The .diff.gz ought to be enough to describe the changes
under the debian/ directory. Even if you re-do the packaging from
scratch so looking at the diff itself is not very useful, it would still
accurately represent the changes made to the original sources.

Admittedly I've never tried to re-package something that already come
with a debian/ directory so if some tool barfs when the .orig.tar.gz
already contains a debian/ directory, then that tool should be fixed
instead of requiring to recreate the .orig.tar.gz.

>   More generally, having a tar.gz without debian/ makes easier to create
> the debian package. Some people say they are also the debian maintainer. But
> are they also the Ubuntu maintainer ? the knoppix maintainer ? the backport
> maintainer ? ...

You seem to make the mistake to think that the debian/ directory
provided by upstream is there to help the distro maintainer. I think
this is not true. The upstream-provided debian/ directory is often for
_users_ who just want to download the latest-and-greatest version or
CVS/SVN/...  snapshot and install it "The Debian Way". There are a lot
of packages where official Debian uploads take a lot of time due to
either technical or political reasons or just due to lack of time from
the official maintainer, so I think it's quite nice if upstream wants to
make users' life easier.

If you want to improve the Debian packaging included in the upstream
sources, that's great, go ahead and submit patches. But insisting on
removing the debian/ directory upstream IMHO goes against the Social
Contract that rates users' interests higher than maintainer convenience.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#457353: gdome2-xslt: should not be a Debian-native package

[Gabor Gombas]

On Wed, Dec 26, 2007 at 04:32:39PM +, Neil Williams wrote:

In general, you seem to rant about a lot of things that may make sense
on their own, but they do not seem to have _anything_ to do with a
package being Debian-native or not. More specifically, you try to imply
that a package being versioned Debian native _must_ mean that it is
unportable and buggy.

> That's not the point. It hinders sharing the code. I'm not unaware of
> the issues here, I'm upstream for many of my Debian packages and only a
> few are native. I make double uploads because it helps people package my
> upstream code for Fedora and SuSE and I believe that free software
> should never hinder the sharing of code. Releasing code with the debian/
> directory intact, just complicates the work for other distros.

Why? Is it really a problem to just ignore the debian/ directory when
writing a .spec file? Lots of upstream packages ship directories that do
not contain anything related to the build, why would the debian/
directory be any different?

> How does that look to other upstream teams developing on Fedora? "Oh,
> we'll hack together some rubbish in debian/ since they put useless .spec
> files in their upstream code."

So you think a Debian-native package should contain an useless .spec
file? Otherwise I do not understand what do you want to say.

> > > How are they to know whether the latest native version is Debian
> > > specific or contains useful "upstream" improvements?
> > 
> > By reading debian/changelog -- that's what it's for!
> 
> So they have to download the new *debian* version just to see what has
> changed when if it was an SF project they could see that the Debian
> release is of no interest to them as they have the .orig.tar.gz. Why
> should people wanting to use your code have to watch (and understand)
> Debian practices to package your POSIX code for a different
> distribution? What about forcing others to make repeated (useless)
> downloads and wasting their time reading Debian webpages / changelogs,
> trying to pick out what they want from the Debian stuff they don't? The
> package can be used outside Debian - why should someone outside Debian
> need to read debian/changelog in the first place!

That already happens when an upstream release contains a fix for
AIX/Solaris/HP-UX/(horrible dictu)Windows. You _do_ have to download the
upstream source or check the upstream website to see if the change is
relevant for Linux or not. How is this any different?

> If the code is not dependent on Debian itself, why should someone from
> another distribution even need to know about how Debian works just
> because upstream happens to be a DD?

Why would they? _You_ insist that they shold know about the Debian
packaging, but they can just completely ignore it and write a .spec file
(or whatever) from scratch just if the debian/ directory would not even
exist.

> Write portable code in the first place and help others. What's wrong
> with that?

What has portability to do with a package being versioned Debian-native
or not?

> Some native packages even 'make install' directly into debian/tmp/ - how
> unfriendly is that?!

You continuously mix normal software/packaging bugs with being versioned
Debian native or not. In my experiences some software (esp. ones that do
_not_ use autoconf but try to invent their own build system) are a real
PITA to install in the way I want, even if their authors never have even
seen a Debian machine. So I don't buy your argument that this attitude
has _any_ relation with being Debian-native or not.

> It's about reuse of code, it is about sharing code and about not
> thinking of Fedora et al as "competition" or a "burden" but as
> colleagues, even friends - people who help us from time to time and who
> should get some help in return.

Er, how does an "rm -rf debian/" command in an (according to you)
distinct upstream release improves code sharing or reusing?!? If
anything it makes life of other packagers harder because they can't peek
for hints about how Debian handles things...

> Would you read the rpm webpage logs to try to work out whether you need
> to package a Fedora update?

AFAIR some packages regularily took patches from RedHat/Fedora when
their upstream went missing and the RedHat/Fedora release became the de
facto upstream. So yes, this happened and undoubtedly will happen in the
future too.

And of course it can also happen in the other direction too when some
other distro decides to import some hunks from Debian's .diff.gz - the
package does not need to be Debian-native in this case either, yet that
other distro would have to follow every new upload in Debian.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". T

Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC

[Gabor Gombas]

On Fri, Dec 07, 2007 at 11:15:00AM +0100, maximilian attems wrote:

> please try newer, unstalbe has 2.6.23-1 that installs just fine in
> testing.

I've tested now 2.6.23-2 and the bug is still present, but only when
powering on the machine. After a reboot (or when booting Windows before
Linux) the network card is visible again.

The reason seems to be the same as before: after power-on, the PCI
bridge at 00:1e.0 is disabled, but after a reboot it gets enabled.

2.6.20 still works fine even right after a power-on.

dmesg of both after a cold start and after reboot are below.

dmesg after cold start:
===

Linux version 2.6.23-1-686 (Debian 2.6.23-2) ([EMAIL PROTECTED]) (gcc version 
4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #1 SMP Fri Dec 21 13:57:07 UTC 
2007
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e8000 - 0010 (reserved)
 BIOS-e820: 0010 - 1ff3 (usable)
 BIOS-e820: 1ff3 - 1ff4 (ACPI data)
 BIOS-e820: 1ff4 - 1fff (ACPI NVS)
 BIOS-e820: 1fff - 2000 (reserved)
 BIOS-e820: ffba - 0001 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 130864) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   130864
  HighMem130864 ->   130864
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   130864
On node 0 totalpages: 130864
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 990 pages used for memmap
  Normal zone: 125778 pages, LIFO batch:31
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F9E70, 0014 (r0 ACPIAM)
ACPI: RSDT 1FF3, 0030 (r1 A M I  OEMRSDT   2000424 MSFT   97)
ACPI: FACP 1FF30200, 0081 (r2 A M I  OEMFACP   2000424 MSFT   97)
ACPI: DSDT 1FF303F0, 3779 (r1  P4PSS P4PSS023   23 INTL  2002026)
ACPI: FACS 1FF4, 0040
ACPI: APIC 1FF30390, 005C (r1 A M I  OEMAPIC   2000424 MSFT   97)
ACPI: OEMB 1FF40040, 003F (r1 A M I  OEMBIOS   2000424 MSFT   97)
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 3000 (gap: 2000:dfba)
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000e8000
swsusp: Registered nosave memory region: 000e8000 - 0010
Built 1 zonelists in Zone order.  Total pages: 129842
Kernel command line: root=/dev/hda7 ro 
mapped APIC to b000 (fee0)
mapped IOAPIC to a000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2793.185 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 508652k/523456k available (1721k kernel code, 14244k reserved, 672k 
data, 240k init, 0k highmem)
virtual kernel memory layout:
fixmap  : 0xfff4c000 - 0xf000   ( 716 kB)
pkmap   : 0xff80 - 0xffc0   (4096 kB)
vmalloc : 0xe080 - 0xff7fe000   ( 495 MB)
lowmem  : 0xc000 - 0xdff3   ( 511 MB)
  .init : 0xc035d000 - 0xc0399000   ( 240 kB)
  .data : 0xc02ae7cd - 0xc03568c4   ( 672 kB)
  .text : 0xc010 - 0xc02ae7cd   (1721 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5590.68 BogoMIPS (lpj=11181368)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff    4400 
  
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff   b080 4400 
  
Intel machine check architecture supporte

Bug#457592: gnome-control-center: Volume control shortcuts are not effective after logout/login

[Gabor Gombas]

Package: gnome-control-center
Version: 1:2.20.1-2
Severity: normal


Hi,

I've a problem with volume control using keyboard shortcuts. Steps to
reproduce:

- Open "Keyboard Shortcuts" and assign
  XF86AudioLowerVolume/XF86AudioRaiseVolume to "Volume down"/"Volume up"

  After this step if I press one of the keys the volume changes
  accordingly.

- Log out & log back in

  At this point the volume control keys no longer work. When pressing
  volume up/down, xev shows just normal keypress events, no grabs:

KeyPress event, serial 32, synthetic NO, window 0x341,
root 0x5e, subw 0x0, time 9106069, (86,119), root:(90,955),
state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), 
same_screen YES,
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x341,
root 0x5e, subw 0x0, time 9106172, (86,119), root:(90,955),
state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), 
same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

- Open "Keyboard Shortcuts" again. It shows that
  XF86AudioLowerVolume/XF86AudioRaiseVolume is still assigned to "Volume
  down"/"Volume up"

- Re-assign the very same keysyms to "Volume down"/"Volume up", and the
  keys start to work again. xev now correctly shows the grab events on
  keypress:

FocusOut event, serial 29, synthetic NO, window 0x341,
mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 29, synthetic NO, window 0x341,
mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 29, synthetic NO, window 0x341,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 29, synthetic NO, window 0x0,
keys:  4294967212 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0 
  
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

First I thought that some component of GNOME is not started on login,
but I see no change in the process list after I (re-)activate the
shortcuts in the "Keyboard Shortcuts" dialog.

Gabor

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

Kernel: Linux 2.6.23.9
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 gnome-control-center depends on:
ii  capplets-data 1:2.20.1-2 configuration applets for GNOME 2 
ii  desktop-file-util 0.13-2 Utilities for .desktop files
ii  gnome-desktop-dat 2.20.2-1   Common files for GNOME 2 desktop a
ii  gnome-icon-theme  2.20.0-1   GNOME Desktop icon theme
ii  gnome-menus   2.20.2-1   an implementation of the freedeskt
ii  libart-2.0-2  2.3.19-3   Library of functions for 2D graphi
ii  libatk1.0-0   1.20.0-1   The ATK accessibility toolkit
ii  libbonobo2-0  2.20.2-1   Bonobo CORBA interfaces library
ii  libbonoboui2-02.20.0-1   The Bonobo UI library
ii  libc6 2.7-5  GNU C Library: Shared libraries
ii  libcairo2 1.4.12-1   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.1.2-1simple interprocess messaging syst
ii  libdbus-glib-1-2  0.74-1 simple interprocess messaging syst
ii  libebook1.2-9 1.12.2-1   Client library for evolution addre
ii  libesd-alsa0 [lib 0.2.36-3   Enlightened Sound Daemon (ALSA) - 
ii  libfontconfig12.5.0-2generic font configuration library
ii  libfreetype6  2.3.5-1+b1 FreeType 2 font engine, shared lib
ii  libgconf2-4   2.20.1-2   GNOME configuration database syste
ii  libglade2-0   1:2.6.2-1  library to load .glade files at ru
ii  libglib2.0-0  2.14.4-2   The GLib library of C routines
ii  libgnome-desktop- 2.20.2-1   Utility library for loading .deskt
ii  libgnome-menu22.20.2-1   an implementation of the freedeskt
ii  libgnome-window-s 1:2.20.1-2 Utility library for getting window
ii  libgnome2-0   2.20.1.1-1 The GNOME 2 library - runtime file
ii  libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display
ii  libgnomekbd1  2.20.0-1   GNOME library to manage keyboard c
ii  libgnomekbdui12.20.0-1   User interface library for libgnom
ii  libgnomeui-0  2.20.1.1-1 The GNOME 2 libraries (User Interf
ii  libgnomevfs2-01:2.20.1-1 GNOME Virtual File System (runtime
ii  libgstreamer-plug 0.10.15-4  GStreamer libraries from the "base
ii  libgstreamer0.10- 0.10.15-3  Core GStreamer libraries and eleme
ii  libgtk2.0-0   2.12.3-2   The GTK+ graphical user i

Bug#456520: mozilla-venkman: Insecure /tmp usage

[Gabor Gombas]

Package: mozilla-venkman
Version: 0.9.87.2-1
Severity: critical
Tags: security
Justification: root security hole


Hi,

mozilla-venkman.preinst contains:

#! /bin/sh

find . -maxdepth 1 -mindepth 1 > /tmp/fin

Just do an "ln -s /etc/shadow /bin/fin" as any user before
installing the package, and watch the fireworks.

Btw. why the heck does the preinst script need to dump the contents of
the root directory to a file that is never used?

Gabor


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

Kernel: Linux 2.6.22.6 (SMP w/2 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 mozilla-venkman depends on:
ii  iceweasel 2.0.0.11-1 lightweight web browser based on M

mozilla-venkman recommends no packages.

-- no debconf information



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

Bug#454768: liferea: crashes with SIGFPE

[Gabor Gombas]

On Tue, Dec 11, 2007 at 02:46:59PM +0100, Nico Golde wrote:

> I did not forget it, it was attached by the one who replied 
> to this bug before me :)

Hmm, that mail did not reach me for some reason. Anyways, I've extracted
the patch from the BTS and I can confirm that if fixes the problem on
i386. Will check amd64 in the evening.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454768: liferea: crashes with SIGFPE

[Gabor Gombas]

On Tue, Dec 11, 2007 at 07:38:43AM +0100, Nico Golde wrote:

> Since I can not reproduce the failure, Gabor can you test 
> this patch?

It seems you forgot the patch... Btw, I've just tested on a different
machine, this time i386 (updated to sid as the time of this mail) but
basically the same configuration, and it shows the same problem.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454768: liferea: crashes with SIGFPE

[Gabor Gombas]

On Mon, Dec 10, 2007 at 05:37:32PM +0100, Nico Golde wrote:

> [...] 
> I doubt this is really caused by the patch fixing the 
> security issue as cairo does nothing else compared without 
> the patch apart from checking what is passed to the memory 
> function. Did you check this is fixed if you downgrade 
> libcairo to the version before the fix?

Yes, verified: after

apt-get install libcairo2=1.4.10-1+b2 libcairo2-dev=1.4.10-1+b2

(ie. the version from lenny) both iceweasel and liferea shows "The
Register" correctly. Upgrading to libcairo2 1.4.10-1.2 makes the text
disappear again in both liferea and iceweasel.

> This is especially 
> curious because I can not reproduce this with
> iceweasel 2.0.0.11-1 and libcairo2 1.4.10-1.2 on 
> http://www.theregister.co.uk/2007/12/10/storage_and_servers_2007_in_review/

Which arcitecture did you test? I'm running amd64.

ii  iceweasel  2.0.0.11-1
ii  liferea1.4.9-1

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454768: liferea: crashes with SIGFPE

[Gabor Gombas]

reopen 454768
retitle 454768 Invisible text in liferea & iceweasel
thanks

On Fri, Dec 07, 2007 at 08:07:34PM +0100, Nico Golde wrote:

> Thank you for the report, I reassigned your bug to libcairo 
> as it seems to be the same problem as described in #454702.
> I mailed the cairo guys if they see the reason. Ubuntu 
> currently has the same patch without crashes and different 
> people looking at the patch also didn't see a problem. I 
> hope this gets fixed soon.

Well, after the latest libcairo update liferea and iceweasel do no
longer crash, but the bug fix does not seem to be complete as now there
is a new symptom: opening http://www.theregister.co.uk in iceweasel or
opening any article in liferea (sample URL:
http://www.theregister.co.uk/2007/12/10/storage_and_servers_2007_in_review/)
show pages with most of the text missing.

If I select the empty area where the article's text should be with the
mouse and cut & paste it into a terminal window, the text appears there.
But in iceweasel and liferea, the text is invisible.

Btw. not all the text is invisible, some keywords in the atricle's
categorization still show up. Screenshots are available at
http://boogie.lpds.sztaki.hu/~gombasg/bug/liferea.png and
http://boogie.lpds.sztaki.hu/~gombasg/bug/iceweasel.png .

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC

[Gabor Gombas]

On Fri, Dec 07, 2007 at 11:15:00AM +0100, maximilian attems wrote:

> please try newer, unstalbe has 2.6.23-1 that installs just fine in
> testing.

Well, I'm actually using unstable, but linux-image-2.6-686 still pulled
2.6.22. Next time I'll try 2.6.23 but I'll not be near that machine for
approx. 2 weeks.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC

[Gabor Gombas]

Package: linux-image-2.6.22-3-686
Version: 2.6.22-6
Severity: normal


Hi,

After upgrading to linux-image-2.6.22-3, networking no longer works. In
fact, lspci does no longer show the network card at all.
linux-image-2.6.20-1 (version 2.6.20-3) works fine. dmesg and lspci for
both versions are below; I think the most significant part is this
change in dmesg:

 PCI: Bridge: :00:1e.0
-  IO window: d000-dfff
-  MEM window: fea0-feaf
+  IO window: disabled.
+  MEM window: disabled.
   PREFETCH window: disabled.

The network card (driven by 8139too) is behind that bridge...
The MB is an Asus P4P800S/SE.

Gabor

lspci -vvnn with 2.6.20-3:
==

00:00.0 Host bridge [0600]: Intel Corporation 82865G/PE/P DRAM 
Controller/Host-Hub Interface [8086:2570] (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device [1043:8110]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation 82865G/PE/P PCI to AGP Controller 
[8086:2571] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #1 [8086:24d2] (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC 
Interface Bridge [8086:24d0] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 

02:05.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:8109]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation 82865G/PE/P PCI to AGP Controller 
[8086:2571] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #1 [8086:24d2] (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC 
Interface Bridge [8086:24d0] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 

dmesg of 2.6.20-1:
==

Linux version 2.6.20-1-686 (Debian 2.6.20-3) ([EMAIL PROTECTED]) (gcc version 
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Apr 24 21:52:11 UTC 
2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009fc00 end: 
0009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009fc00 size: 0400 end: 
000a type: 2
copy_e820_map() start: 000e8000 size: 00018000 end: 
0010 type: 2
copy_e820_map() start: 0010 size: 1fe3 end: 
1ff3 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 1ff3 size: 0001 end: 
1ff4 type: 3
copy_e820_map() start: 1ff4 size: 000b end: 
1fff type: 4
copy_e820_map() start: 1fff size: 0001 end: 
2000 type: 2
copy_e820_map() start: ffba size: 0046 end: 
0001 type: 2
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e

Bug#445861: HAL daemon exited with return code 1

[Gabor Gombas]

Hi,

This bug seems to take an annoyingly long time to fix, so I tried to run
"hald --daemon=no --verbose=yes" under valgrind and I got:

==9630== Invalid read of size 1
==9630==at 0x4A07AC4: strcmp (mc_replace_strmem.c:341)
==9630==by 0x4C2E68D: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2E955: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2E350: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2E578: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C35D5D: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C35E22: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C3608C: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C1498D: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C13B7A: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C13D9B: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C13325: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2B92E: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2C80E: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==by 0x4C2D0AA: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==  Address 0x4F0D228 is 0 bytes inside a block of size 5 free'd
==9630==at 0x4A0682B: free (vg_replace_malloc.c:233)

I don't know if this is _the_ reason why hald quits but at least it is
clearly a use-after-free bug and it should be easy to catch if someone
recompiles hal & libdbus with full debug info and runs hald under
valgrind again - I don't have the time right now.

iF  hal0.5.10-3  Hardware 
Abstraction Layer
ii  libdbus-1-31.1.2-1   simple 
interprocess messaging system

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -



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

Bug#447011: chronyd stalls with 100% CPU usage

[Gabor Gombas]

Package: chrony
Version: 1.21z-5
Severity: normal


Hi,

Sometimes chronyd starts using 100% CPU time. This happens 1-5 seconds
after the /etc/ppp/ip-up.d/chrony script marked the sources online. In
this state chronyd does not accept any new chronyc commands (chronyc
just hangs indefinitely). In fact, using strace shows that chronyd is not
performing any system calls, so it is spinning in some internal
function.

The problem is not 100% reproducible but it seems to happen more
frequently with some time sources than with others. For example,  having
84.2.40.31 (ntp.t-online.hu) in chrony.conf show this problem rather
frequently now but AFAIR last week it mostly worked OK.

Stopping/restarting chronyd sometimes fixes the problem, sometimes it
starts spinning again.

I also observed the bug on servers running etch, but not frequently
(they were configured to use pool.ntp.org so it may depend on what
servers did they happen to use).

There is nothing interesting in syslog; a couple of times I tried
running "chronyd -d" but then I could never reproduce the bug - so the
bug may also be in the logging code and not related to the time
sources...

Gabor

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

Kernel: Linux 2.6.22.6
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 chrony depends on:
ii  libc6 2.6.1-5GNU C Library: Shared libraries
ii  libncurses5   5.6+20071006-1 Shared libraries for terminal hand
ii  libreadline5  5.2-3  GNU readline and history libraries
ii  ucf   3.003  Update Configuration File: preserv

chrony recommends no packages.

-- no debconf information



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

Bug#440113: gotmail: Page doesn't contain any form action field

[Gabor Gombas]

Package: gotmail
Version: 0.9.0-1
Followup-For: Bug #440113


Hi,

A patch is available at

http://sourceforge.net/tracker/?func=detail&atid=615989&aid=1777163&group_id=96810

It works for me.

Gabor

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

Kernel: Linux 2.6.22.1 (SMP w/2 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 gotmail depends on:
ii  curl   7.16.4-5  Get a file from an HTTP, HTTPS or 
ii  liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin
ii  perl   5.8.8-7   Larry Wall's Practical Extraction 
ii  perl-modules [libnet-perl] 5.8.8-7   Core Perl modules

gotmail recommends no packages.

-- no debconf information


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

Bug#440074: libpam0g upgrade kills the X session

[Gabor Gombas]

On Thu, Aug 30, 2007 at 08:02:06AM -0700, Steve Langasek wrote:

> Yes, just not in the short time frame demanded by the bug that this code was
> introduced to address.  The next upload will also include an improved
> (shortened) debconf question.

Ok, thanks!

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 -


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

Bug#440074: libpam0g upgrade kills the X session

[Gabor Gombas]

On Wed, Aug 29, 2007 at 02:20:55PM -0700, Steve Langasek wrote:

> First of all, the libpam0g package is doing exactly what it says it's going
> to, complete with a special warning that running this under gdm will kill
> your X session.

Ok, the second time I read the full text and you're right :-) But when
you output a full page of text then I think there will be many users who
- just like me - will read only the beginning and the end. Would it be
possible to shorten the text? The service-restart question in libc has
only half the length, and therefore it is much easier to read.

The detailed explanation can go to NEWS.Debian.

> Second, gdm does *nothing* different when given a "restart" command than it
> does when you pass a "start" and "stop" command separately.  The special
> "postponed" restart is possible only with the "reload" command, which is
> completely non-standard behavior.

You're right again, I misremembered the action name. I only remembered
seeing the "Scheduling reload..." text on gdm upgrades, and I guessed
that it was the 'restart' action that did that.

> But, having been brought to my attention, the fix will be included in -4 by
> special-casing gdm.

Thanks!

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -


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

Bug#440074: libpam0g upgrade kills the X session

[Gabor Gombas]

Package: libpam0g
Version: 0.99.7.1-3
Severity: important


Hi, 

Upgrading libpam0g just killed my X session. It listed 'gdm' among the
services to restart, which I accpted since I knew that gdm was safe to
restart since gdm postpones the 'restart' action until I log out.

But it turns out that libpam0g does _NOT_ use the 'restart' method, but
instead tries to do a manual 'stop'/'start' sequence, which is just
plain WRONG. Please stop that!

Gabor

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

Kernel: Linux 2.6.22.1 (SMP w/2 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 libpam0g depends on:
ii  libc6 2.6.1-1+b1 GNU C Library: Shared libraries
ii  libpam-runtime0.99.7.1-3 Runtime support for the PAM librar

libpam0g recommends no packages.

-- debconf information:
* libpam0g/restart-services: squid saslauthd postgresql-8.2 gdm cupsys cron atd
  libpam0g/restart-failed:


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

Bug#439935: alternatives: rename.ul is not compatible with prename

[Gabor Gombas]

Package: util-linux
Version: 2.13-1
Severity: normal


Hi,

Before the recent util-linux uploads, perl has registered the
/usr/bin/rename alternative, pointing to prename. The latest util-linux
also registers rename.ul as a /usr/bin/rename alternative.

The trouble is that these two implementations are completely
incompatible even for the most simple usage. Therefore the alternative
does not make any sense, as there is no way they can be used instead of
each other.

So util-linux should either not ship it's rename implementation at all,
or the util-linux implementation should be renamed and should _not_ be
registered as an alternative for /usr/bin/rename.

Gabor

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

Kernel: Linux 2.6.22.1 (SMP w/2 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 util-linux depends on:
ii  libc6   2.6.1-1+b1   GNU C Library: Shared libraries
ii  libncurses5 5.6+20070825-1   Shared libraries for terminal hand
ii  libselinux1 2.0.15-2+b1  SELinux shared libraries
ii  libslang2   2.0.7-3  The S-Lang programming library - r
ii  libuuid11.40.2-1 universally unique id library
ii  lsb-base3.1-24   Linux Standard Base 3.1 init scrip
ii  tzdata  2007g-1  time zone and daylight-saving time
ii  zlib1g  1:1.2.3.3.dfsg-5 compression library - runtime

util-linux recommends no packages.

-- no debconf information


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

Bug#439931: grep: Enormous slowdown on AMD64

[Gabor Gombas]

Package: grep
Version: 2.5.3~dfsg-1
Severity: important


Hi,

After upgrading grep to 2.5.3~dfsg-1:

$ time grep '^foo b' bar >/dev/null

real0m34.745s
user0m34.522s
sys 0m0.032s

While in a 32-bit chroot on the same machine, same package version, same
input file:

$ time grep '^foo b' bar >/dev/null

real0m0.123s
user0m0.120s
sys 0m0.000s

Both cases are cache-hot representative values of multiple measurements.
The file searched is a ~30 MiB textfile. Up until yesterday the 64-bit
version was a little faster... IMHO this nearly 300x slowdown makes 'grep'
practically unusable for any serious work on AMD64.

Gabor

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22.1
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 grep depends on:
ii  libc6 2.6.1-1GNU C Library: Shared libraries

grep recommends no packages.

-- no debconf information


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

Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch

[Gabor Gombas]

On Thu, Aug 23, 2007 at 09:34:27AM +0200, Ondřej Surý wrote:

> So package gets compiled against lidb4.5-dev headers and -ldb-4.4
> libraries.

Yes, I also realized that I got the versioning wrong (I somehow thought
it linked to a version higher than the -dev package, but of course the
opposite is still possible for exactly the same reason).

> It will be fixed in 2.3.9-1 release.

Thanks. Be careful that 2.3.9 already seems to check for BDB 4.6 too.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch

[Gabor Gombas]

On Tue, Aug 21, 2007 at 10:25:58PM +0200, Ondřej Surý wrote:

> So question is where did you get that source code which you sent patch
> for?

Oh, the patch is from the set I used for Cyrus builds at some other
place; actually it's against a post-2.3.8 CVS version. I forget to check
the sources of the Debian package.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch

[Gabor Gombas]

On Tue, Aug 21, 2007 at 01:55:56PM +0200, Ondřej Surý wrote:

> Now I see.  You're right.  But where did db-4.5 come from?  2.3.8-1
> source from experimental doesn't have it, 2.3.8-1 source from subversion
> doesn't have it.  Is this your local modification?

I have no idea. Maybe some other unrelated software on the buildd needed
it. I've done no local modifications, I've installed the official
packages:

apt-cache policy cyrus-imapd-2.3
cyrus-imapd-2.3:
  Installed: 2.3.8-1
  Candidate: 2.3.8-1
  Version table:
 *** 2.3.8-1 0
101 http://ftp.hu.debian.org experimental/main Packages
101 http://ftp.fi.debian.org experimental/main Packages
100 /home/gombasg/tmp/debian/x86_64/status

> Correct fix is either fix berkdb.m4 macro to use information
> from /usr/include/db.h (DB_VERSION_MAJOR and DB_VERSION_MINOR) or just
> by using:
> 
> Build-Conflict: libdb4.5
> Build-Depends: libdb4.4-dev
> 
> Which of course needs to be modified each time new libdb4.x is released.

libdb4.6 is already in the archive but Cyrus 2.3.9 does not yet test for
it. I think adding some way to configure to explicitely ask for the BDB
version to use would be the best solution.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch

[Gabor Gombas]

On Sun, Aug 19, 2007 at 08:07:39PM +0200, Ondřej Surý wrote:

> Correct fix would be to find why it didn't find libdb4.4.

The reason is in the comment of the proposed patch. Every libdbX.Y
Debian package installs the library as /usr/lib/libdb-X.Y.so, because
that's the SONAME of the Berkeley DB 4.x libraries. The libdbX.Y-dev
package however installs the /usr/lib/libdb.so symlink that points to
the DB version the -dev package belongs to. That means you _can_ link to
any BDB version if you use an explicit DB name (like the Cyrus configure
script does) even when the -dev package is not present or if the -dev
package belongs to a different library version.

So, if you happen to have _any_ libdbX.Y package installed that has a
version higher than the -dev package (example: you have all libdb4.4,
libdb4.4-dev, and libdb4.5 installed) then the Cyrus configuration
snippet will find the highest library version (4.5 in this case, since
the linker will find the /usr/lib/libdb-4.5.so library), and not the
version of the -dev package. And that will cause the version mismatch.

The reason why this problem do not occur with other packages is that
almost every other library (including the 3.x series of BDB) uses a
SONAME of the form libfoo.so.X.Y.Z, i.e. the SONAME does not end in
".so".

> Could you supply more information about your build environment?  Include
> at least list of libdb*-dev packages installed.

I used the Debian-provided packages, so you should check the
experimental buildds. I know nothing about them. However I noticed this
problem during personal builds long before there was a Debian package
available. Just install both libdb4.4-dev and libdb4.5 and see what
happens.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch

[Gabor Gombas]

Package: cyrus-imapd-2.3
Version: 2.3.8-1
Severity: grave
Tags: patch
Justification: renders package unusable


Hi,

On AMD64, all daemons and database tools die complaining that they were
compiled against db-4.4 headers but were linked against db-4.5. For
local Cyrus builds I have used the following patch (autoreconf is needed
after applying):

--- cmulocal/berkdb.m4.orig 2007-02-13 16:44:00.0 +0100
+++ cmulocal/berkdb.m4  2007-08-14 14:53:42.0 +0200
@@ -213,7 +213,8 @@
fi
 
saved_LIBS=$LIBS
-for dbname in db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 
db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 
db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db
+   # On Debian, /usr/lib/libdb.so points to the version corresponding to 
the -dev package, so test that first
+for dbname in db db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 
db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 
db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3
   do
LIBS="$saved_LIBS -l$dbname"
AC_TRY_LINK([#include ],

Gabor

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

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#421095: Detects a non-existing monitor on the non-existing secondary head

[Gabor Gombas]

On Sat, Aug 11, 2007 at 06:28:56PM +0200, Brice Goglin wrote:

> If the bug is still there with 6.6.193-1 (in experimental), I'll forward
> on the upstream bugzilla so that it gets attention before driver 6.7 is
> released.

6.6.3:

(II) RADEON(0): I2C bus "DDC" initialized.
(II) RADEON(0): Legacy BIOS detected
(II) RADEON(0): Connector0: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 3, Detected Type: 1
(II) RADEON(0): EDID data from the display on port 1 --
(II) RADEON(0): Manufacturer: HWP  Model: 13c8  Serial#: 
(II) RADEON(0): Year: 2002  Week: 8
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
(II) RADEON(0): Sync:  Separate  Composite
(II) RADEON(0): Max H-Image Size [cm]: horiz.: 34  vert.: 27
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.630 redY: 0.330   greenX: 0.300 greenY: 0.600
(II) RADEON(0): blueX: 0.149 blueY: 0.100   whiteX: 0.310 whiteY: 0.330
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported Future Video Modes:
(II) RADEON(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  359 x 287 mm
(II) RADEON(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 
h_border: 0
(II) RADEON(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 
v_border: 0
(II) RADEON(0): Ranges: V min: 56  V max: 75 Hz, H min: 31  H max: 80 kHz, 
PixClock max 130 MHz
(II) RADEON(0): Monitor name: hp L1720
(II) RADEON(0): Serial No: XXX
(II) RADEON(0): EDID (in hex):
(II) RADEON(0): 000022f0c81358e33d01
(II) RADEON(0): 080c01036c221b78ea6e66a1544c9926
(II) RADEON(0): 194f54a56b0081800101010101010101
(II) RADEON(0): 010101010101302a009851002a403070
(II) RADEON(0): 1300671f111e00fd00384b1f
(II) RADEON(0): 500d000a20202020202000fc0068
(II) RADEON(0): 70204c313732300a2020202000ff
(II) RADEON(0): 005457323038313132310ae6
(II) RADEON(0): 
(II) RADEON(0): Primary:
 Monitor   -- CRT
 Connector -- VGA
 DAC Type  -- Primary
 TMDS Type -- NONE
 DDC Type  -- VGA_DDC
(II) RADEON(0): Secondary:
 Monitor   -- NONE
 Connector -- None
 DAC Type  -- Unknown
 TMDS Type -- NONE
 DDC Type  -- NONE

6.6.193:

(II) RADEON(0): I2C bus "DDC" initialized.
(II) RADEON(0): Legacy BIOS detected
(II) RADEON(0): Connector0: DDCType-0, DACType--1, TMDSType--1, ConnectorType-0
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 3, Detected Type: 1
(II) RADEON(0): EDID data from the display on 1st port --
(II) RADEON(0): Manufacturer: HWP  Model: 13c8  Serial#: 
(II) RADEON(0): Year: 2002  Week: 8
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
(II) RADEON(0): Sync:  Separate  Composite
(II) RADEON(0): Max H-Image Size [cm]: horiz.: 34  vert.: 27
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.630 redY: 0.330   greenX: 0.300 greenY: 0.600
(II) RADEON(0): blueX: 0.149 blueY: 0.100   whiteX: 0.310 whiteY: 0.330
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): [EMAIL PROTECTED]
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported Future Video Modes:
(II) RADEON(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  359 x 287 mm
(II) RADEON(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 
h_border: 0
(II) RADEON(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 
v_border: 0
(II) RADEON(0): Ranges: V min: 56  V max: 75 Hz, H min: 31  H max: 80 kHz, 
PixClock max 130 MHz
(II) RADEON(0): Monitor name: hp L1720
(II) RADEON(0): Serial No: XXX
(II) RADEON(0): EDID (in hex):
(II) R

Bug#434374: libsuitesparse: depends on non-free libparmetis3.1

[Gabor Gombas]

Package: libsuitesparse
Version: 3.0.0-4
Severity: serious
Justification: Policy 2.2.1


$ apt-cache show libsuitesparse
[...]
Depends: [...], libparmetis3.1
[...]
$ apt-cache show libparmetis3.1
[...]
Section: non-free/libs
[...]

Gabor

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

Kernel: Linux 2.6.21.5 (SMP w/2 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 libsuitesparse depends on:
ii  lapack3 [liblapack.so.3] 3.0.2531a-6 library of linear algebra routines
ii  libc62.6-2   GNU C Library: Shared libraries
ii  libparmetis3.1   3.1-7   Parallel Graph Partitioning and Sp
ii  refblas3 [libblas.so.3]  1.2-8   Basic Linear Algebra Subroutines 3

libsuitesparse recommends no packages.

-- no debconf information


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

Bug#421095: Detects a non-existing monitor on the non-existing secondary head

[Gabor Gombas]

On Sun, Jun 24, 2007 at 02:18:43AM +0200, Brice Goglin wrote:

> Does this problem with the ATI driver detecting a non-existing monitor
> on the non-existing second head still occur? Could you try with
> xserver-xorg-video-ati 1:6.6.192-1 currently in experimental?

I've already tried it some time ago and the bug is still there.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#425050: initramfs-tools: Ask if we should update all initramfses

[Gabor Gombas]

On Fri, May 18, 2007 at 09:26:25PM +0200, Tim Dijkstra wrote:

> Come on. `useless debconf proliferation'? The question has medium
> priority. I can also make it an configration option somewhere and use
> that, but it was just a convenient why to get info from a user.

I'd also say a debconf question is overkill. People who understand what
the option means can edit a config file by hand.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#423408: vblade drops discovery packets

[Gabor Gombas]

Package: vblade
Version: 14-1
Severity: normal
Tags: patch


Hi,

I tried to set up AoE but it did not work. tshark showed that the
packets generated as a result of 'aoe-discover' was received on the NIC,
and strace showed that vblade read() them, but nothing happened, there
was no response. Checking the source revealed that vblade simply drops
packets with length less than 60, but the "AoE Query Config Information
Request" packets had length 56 (the remote end is the AoE driver from
linux-image-2.6.18-4-amd64 2.6.18.dfsg.1-12etch1).

The following patch made AoE work for me:

--- aoe.c.orig  2006-11-20 18:48:05.0 +0100
+++ aoe.c   2007-05-11 16:49:07.0 +0200
@@ -202,7 +202,7 @@
perror("read network");
exit(1);
}
-   if (n < 60)
+   if (n < 56)
continue;
p = (Aoehdr *) buf;
if (ntohs(p->type) != 0x88a2)

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

Kernel: Linux 2.6.20.9 (SMP w/2 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 vblade depends on:
ii  libc6 2.5-7  GNU C Library: Shared libraries

vblade recommends no packages.

-- no debconf information


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

Bug#422008: xserver-xorg-core: running 'xvinfo' crashes the server

[Gabor Gombas]

On Thu, May 03, 2007 at 12:03:47AM +0200, Brice Goglin wrote:

> I can't reproduce this here on a Radeon X300. Could you try with a
> simple xorg.conf (or even with no xorg.conf at all to use the default
> config)? You have lots of options in your current xorg.conf, it would be
> good to see if any of them causes the problem.

Yep, those options accumulated over the years. However this was a good
tip: I started disabling them, and disabling the loading of the "v4l"
module made the segfault go away.

> This 6.6.99 could be the previous 6.6.3-5 which has been in experimental
> about a month ago. It was a daily snapshot, probably less stable than
> both 6.6.3 and 6.6.191.

Yes it's 6.6.3-5; 6.6.191 is not available for amd64:

xserver-xorg-video-ati:
  Installed: 1:6.6.3-5
  Candidate: 1:6.6.3-5
  Version table:
 *** 1:6.6.3-5 0
101 http://ftp.hu.debian.org experimental/main Packages
101 http://ftp.fi.debian.org experimental/main Packages
100 /home/gombasg/tmp/debian/x86_64/status
 1:6.6.3-2 0
500 http://ftp.hu.debian.org etch/main Packages
500 http://ftp.fi.debian.org etch/main Packages
990 http://ftp.hu.debian.org sid/main Packages
990 http://ftp.fi.debian.org sid/main Packages

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -


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

Bug#420721: xserver-xorg-video-ati: crash in power management code

[Gabor Gombas]

On Fri, Apr 27, 2007 at 11:54:35AM +0200, Julien Cristau wrote:

> if you could rebuild the ati driver with debugging symbols, and get a
> full backtrace with gdb, it would be of great help.  See [0] and [1] for
> information on how to do that.

I've rebuilt the ATI driver as shown on the wiki and I have the
xserver-xorg-core-dbg package installed, but the backtrace is useless:

Program received signal SIGSEGV, Segmentation fault.
0xb7ceb4bf in ?? ()
(gdb) bt
#0  0xb7ceb4bf in ?? ()
#1  0x082098b8 in ?? ()
#2  0x00039c9f in ?? ()
#3  0x081f8518 in ?? ()
#4  0xb7d07958 in ?? ()
#5  0x08209ed8 in ?? ()
#6  0x082098b8 in ?? ()
#7  0xbfff4128 in ?? ()
#8  0xb7ceb832 in ?? ()
#9  0x082098b8 in ?? ()
#10 0x0001 in ?? ()
#11 0x in ?? ()
(gdb)

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#420721: xserver-xorg-video-ati: crash in power management code

[Gabor Gombas]

On Thu, Apr 26, 2007 at 06:15:30PM +0200, Julien Cristau wrote:

> Thanks, this has independently been reported upstream today.  Marking
> the bug as forwarded.

Thanks.

> > An other minor bug is that the Radeon driver now thinks that I have two
> > monitors when in fact I only have one. I _think_ X.org 7.1 correctly
> > recognized that there is no second head (this card has only a single
> > analog VGA connector) but I have no logs left to verify that.
> > 
> I see you reported this as #421095, right?

Yes.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
 Laboratory of Parallel and Distributed Systems
 Address   : H-1132 Budapest Victor Hugo u. 18-22. Hungary
 Phone/Fax : +36 1 329-78-64 (secretary)
 W3: http://www.lpds.sztaki.hu
 -

Bug#420721: Monitor detection

[Gabor Gombas]

clone 420721 -1
retitle -1 Detects a non-existing monitor on the non-existing secondary head
thanks

Ok, going back to 6.6.3-2 from unstable I can confirm that it correctly
detects that I have no second monitor:

(II) RADEON(0): Primary:
 Monitor   -- CRT
 Connector -- VGA
 DAC Type  -- Primary
 TMDS Type -- NONE
 DDC Type  -- VGA_DDC
(II) RADEON(0): Secondary:
 Monitor   -- NONE
 Connector -- None
 DAC Type  -- Unknown
 TMDS Type -- NONE
 DDC Type  -- NONE

So this is also a regression in 6.6.191-1.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#324900: nscd: umount /var fails (unclean shutdowns)

[Gabor Gombas]

On Wed, Apr 25, 2007 at 09:35:04PM +0200, Pierre HABOUZIT wrote:

>   I have the same "problem" but as it concerns a file that will be
> deleted anyway, it's not critical, and there is nothing that we can do
> (except code rc not to use bash I guess).

It may be useful to have some way (like an environment variable) that
would forbid using nscd even if it is running.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Bug#379810: saslauthd memory leak with PAM

[Gabor Gombas]

Hi,

I got annoyed by saslauthd consuming more than 2Gig of RAM so I started
looking into this issue. My findings:

- The leak does NOT happen on successful authentication. I sent 50
  valid auth. requests to saslauthd and its memory usage did not
  increase.

- I sent just a couple of invalid authentication requests and
  saslauthd's memory usage started to climb. So this is a trivially
  exploitable remote DoS (send a large amount of bad passwords to any
  sasl-using service and wait until the OOM killer kicks in and renders
  your box useless).

- The leak is NOT related to libpam-mysql, it happens with the plain
  pam_unix module as well.

- When using just pam_unix, valgrind gives the following trace segment:

==17824== 68 bytes in 17 blocks are definitely lost in loss record 7 of 7
==17824==at 0x40064B0: malloc (vg_replace_malloc.c:149)
==17824==by 0x425AAF12: (within /lib/ld-2.5.so)
==17824==by 0x425AC5B4: (within /lib/ld-2.5.so)
==17824==by 0x425B6450: (within /lib/ld-2.5.so)
==17824==by 0x425B2401: (within /lib/ld-2.5.so)
==17824==by 0x425B5E9D: (within /lib/ld-2.5.so)
==17824==by 0x42709C2C: (within /lib/i686/cmov/libdl-2.5.so)
==17824==by 0x425B2401: (within /lib/ld-2.5.so)
==17824==by 0x4270A2AB: (within /lib/i686/cmov/libdl-2.5.so)
==17824==by 0x42709B60: dlopen (in /lib/i686/cmov/libdl-2.5.so)
==17824==by 0x4352838F: (within /lib/libpam.so.0.79)
==17824==by 0x4352852B: (within /lib/libpam.so.0.79)
==17824==by 0x435292F3: _pam_init_handlers (in /lib/libpam.so.0.79)
==17824==by 0x4352726E: pam_start (in /lib/libpam.so.0.79)
==17824==by 0x804B1F4: auth_pam (auth_pam.c:207)

The number of lost blocks equals to the invalid authentication requests
I sent to saslauthd. This seems to suggest that something forgets to
clean up when an authentication request fails.

The amount of leaked memory seems to be dependent on the PAM module
being used. pam_unix seems to be the 'nicest'; with libpam_mysql, I get
about 60 KiB of memory lost for every failed authentication attempt,
according to 'ps' output.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#315370: mutt: Segfault when fetching mails with header_cache set

[Gabor Gombas]

On Thu, Mar 08, 2007 at 08:03:09PM +0100, Christoph Berg wrote:

> sorry for the late followup - can you still reproduce this bug with
> recent mutt packages?

I've not seen it in a while. But that does not neccessarily mean
anything as this bug was quite hard to trigger and it always required a
special mailbox state; any external changes to the mailbox (like the
arrival of a new message) made the SIGSEGV go away. I do not know what
the triggering factor is/was and I could not willingly reproduce the bug
even with known-bad mutt versions.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Bug#413744: glibc - uses more than one cpu without asking

[Gabor Gombas]

On Tue, Mar 06, 2007 at 11:25:14PM +0100, Bastian Blank wrote:

> One of the s390 buildds, lxdebian, have two cpus online but is only
> allowed to use one full. This is followed by a make call without -j.

IMHO such policies should be enforced by binding the whole buildd to a
single CPU by using tools like taskset or schedtool.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#412989: What is available at early userspace?

[Gabor Gombas]

On Fri, Mar 02, 2007 at 12:24:07AM +0300, Nikita V. Youshchenko wrote:

> The issue I'm talking about (lots of error messages while udev init.d 
> script is running) happens in the current sequential boot procedure.

If you're using a 2.6 kernel and udev then the boot procedure is _NOT_
sequential any more. There are some hacks in place to look more or less
like it was still sequential, but it fundamentally isn't. Even the
udevsettle call in /etc/init.d/udev is just "best effort".

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#412989: udev startup script prints a lot of errors when ldap is used

[Gabor Gombas]

On Thu, Mar 01, 2007 at 10:54:19PM +0300, Nikita V. Youshchenko wrote:

> So a *fix* for this issue could be only inside udev package.
> In all other places, only workarounds are possible.
> And these workarounds do have the following drawbacks.
> 
> - if base-passwd will be used as workaround location, this will create a 
> situation when changes to default udev configuration files, introducing 
> references to new groups or removing references to old ones, will cause 
> need of base-files update - which is increased complexity and will cause 
> out-of-sync situations;

My opinion is quite the opposite. Decisions like "all scanners should be
owned by the 'scanner' group" are distro-wide policy, and udev is just
one of the possible implementors of such policy. So the policy should
not be in udev (anyone can write an udev replacement any day). In fact,
MAKEDEV _should_ use the same group on a static /dev; how do you want to
enforce that? (Yes, I realize that MAKEDEV does not have the same amount
of information and therefore can not make such fine-grained decisions as
udev).

Also, on my system the udev configuration references 17 groups of which
12 is already present in /usr/share/base-passwd/group.master. I do not
see any reason not to add the remaining 5 and be done with it.

On the other hand, a rule like "the default udev configuration must not
reference any groups not provided by base-passwd" seems quite
reasonable.

> Also, it is unclear what udevd is going to do with non-resolved groups. 
> Likely it will create devices with invalid ownership. Won't that introduce 
> breakage at unexpected moments? E.g. if a package that actually uses 
> device (and creates a group if it does no exist) will be installed and 
> used before next reboot.

How is that different from MAKEDEV creating the node with bad ownership
on a static /dev?

> From the other hand, fix at udev level is relatively easy.
> It just should extract a list of referenced groups (and probably users) 
> from config files at build time (not at install time, because the talk is 
> only groups referenced in default configs), and add several lines to 
> postinst to create these groups if they don't exist.

That would be HORRIBLE. We should _NOT_ create any groups
unconditionally just because udev upstream likes them. New groups are
needed only if there are real users of them and udev is _not_ an user.
So udev must not be the entity deciding whether a group should be
created or not; it should first be discussed with the users, then added
to base-passwd and after that it can be used by udev. It's not like
we're going to add random new groups every other day...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#412831: LD_ASSUME_KERNEL=2.2.5 denies to load libc6 version 2.5-0exp3

[Gabor Gombas]

On Wed, Feb 28, 2007 at 02:02:52PM +0100, Achim Gaedke wrote:

> I could not find out whether it is intended to fail, but now I am convinced, 
> it should not.

Yes it should.

> LD_ASSUME_KERNEL=2.4 also fails, LD_ASSUME_KERNEL=2.6 works...

LD_ASSUME_KERNEL=2.2 or 2.4 requests the use of LinuxThreads instead of
NPTL, but LinuxThreads is no longer supported by glibc.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#411148: sasl2-bin: "/etc/init.d/saslauthd {stop|restart}" kills instances in unrelated chroots

[Gabor Gombas]

Package: sasl2-bin
Version: 2.1.22.dfsg1-8
Severity: important


Hi,

/etc/init.d/saslauthd does not seem to honour the pidfile, and when
invoked with the "stop" or "restart" arguments in a chroot, it kills
unrelated saslauthd instances running in other chroots. This is quite
painful as it renders unrelated services running in those chroots
unusable.

This _may_ be considered a bug in start-stop-daemon (it really should
refuse to touch processes running outside the chroot where
start-stop-daemon was invoked in); if you think so, then please re-assign
the bug accordingly.

Gabor

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages sasl2-bin depends on:
ii  libc62.5-0exp3   GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library
ii  libdb4.2 4.2.52+dfsg-1   Berkeley v4.2 Database Libraries [
ii  libkrb53 1.4.4-6 MIT Kerberos runtime libraries
ii  libldap2 2.1.30-13.2 OpenLDAP libraries
ii  libpam0g 0.79-4  Pluggable Authentication Modules l
ii  libsasl2 2.1.22.dfsg1-8  Authentication abstraction library
ii  libssl0. 0.9.8c-4SSL shared libraries
ii  lsb-base 3.1-23  Linux Standard Base 3.1 init scrip

sasl2-bin recommends no packages.

-- debconf information excluded


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

Bug#410339: fwbuilder dies with 'Segmentation Fault' if rule installation fails

[Gabor Gombas]

Package: fwbuilder
Version: 2.1.8-1
Severity: normal


Hi,

When I select 'Rules/Install' from the menu (using the built-in ssh
installer), but the ssh daemon on the firewall does not let me in (e.g.
only public key authentication is allowed but I forgot to add my key to
ssh-agent), then fwbuilder dies with 'Segmentation Fault'.

Gabor

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages fwbuilder depends on:
ii  fwbuilder-common2.1.8-1  Firewall administration tool GUI (
ii  fwbuilder-linux [fwbuil 2.1.8-1  Firewall Builder policy compiler(s
ii  libc6   2.5-0exp3GNU C Library: Shared libraries
ii  libfwbuilder7   2.1.8-1  Firewall Builder API library
ii  libgcc1 1:4.2-20070105-1 GCC support library
ii  libqt3-mt   3:3.3.7-3Qt GUI Library (Threaded runtime v
ii  libsnmp95.2.3-7  NET SNMP (Simple Network Managemen
ii  libssl0.9.8 0.9.8c-4 SSL shared libraries
ii  libstdc++6  4.2-20070105-1   The GNU Standard C++ Library v3
ii  libwrap07.6.dbs-12   Wietse Venema's TCP wrappers libra
ii  libx11-62:1.1-2  X11 client-side library
ii  libxext61:1.0.1-2X11 miscellaneous extension librar
ii  libxml2 2.6.27.dfsg-1GNOME XML library
ii  libxslt1.1  1.1.19-1 XSLT processing library - runtime 

fwbuilder recommends no packages.

-- no debconf information


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

Bug#410131: libc6: running "mount / -o remount" gives glibc double-free

[Gabor Gombas]

On Thu, Feb 08, 2007 at 11:48:09AM +0100, Pierre Habouzit wrote:

>   well what is strange is that when I do (painfully) an unstripped mount
> build, the problem disappears, which in my experience usually is a sign
> of stack smashing in the program, I'd rather think the problem is in
> mount.

If you already done a debug build you should try to run mount under
valgrind. With a little luck it will show where the bug is.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#330105: libc6-dev: __FD_SETSIZE equals to 1024 is too small

[Gabor Gombas]

On Tue, Feb 06, 2007 at 12:49:24AM +0100, Pierre Habouzit wrote:

>   TTBOMK __FD_SETSIZE is only used for fd_set's (so select, FD_* macros,
> ...), and redefining it won't work (I tried already in another life)
> without recompiling the libc at least -- if not the kernel too, I'm less
> sure about that one -- and that would be obvioulsy binary incompatible
> with the rest of the linuxes around the globe :)

"Just" libc and everything that uses select - basically you have to
rebuild the whole archive.

AFAIK sys_select() in the kernel can handle arbitrary large number of
file descriptiors, so one option is not to use glibc's select() wrapper
but do your own. But a much better approach (both maintainability and
performance wise) is to use epoll().

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#360064: mesa-utils: glxgears is broken

[Gabor Gombas]

Hi,

On Thu, Jan 25, 2007 at 09:57:38AM +0100, Brice Goglin wrote:

> Apart from the missing documentation, did you reproduce these problem
> recently? If not, I will close this bug in the next weeks.

I've just tried and could not reproduce the bug, so it can be closed.
Thanks.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Bug#406215: heimdal-kdc: Fix multi-database mode

[Gabor Gombas]

Package: heimdal-kdc
Version: 0.7.2.dfsg.1-8
Severity: wishlist
Tags: patch


Hi,

The following two patches are required if one wants a single
kdc/kadmind/kpasswdd process to serve multiple realms using multiple
database definitions in kdc.conf. Without these patches kdc/kadmind
parses the second database definition incorrectly, and kpasswdd always
uses the first database regardless of the realm it was asked to handle.

I've been using these pathces for several months now. Severity is
'wishlist' since there does not seem to be that many people who needs
this feature. The patches were also submitted upstream, but a new 0.7
release seems unlikely.

Gabor

--- lib/krb5/config_file.c.orig 2004-09-30 13:22:48.0 +0200
+++ lib/krb5/config_file.c  2006-05-05 11:23:06.0 +0200
@@ -102,6 +102,26 @@
 return *q;
 }
 
+static krb5_config_section *
+get_new_entry(krb5_config_section **parent, const char *name, int type)
+{
+krb5_config_section **q;
+
+for(q = parent; *q != NULL; q = &(*q)->next)
+   /* Nothing */;
+*q = calloc(1, sizeof(**q));
+if(*q == NULL)
+   return NULL;
+(*q)->name = strdup(name);
+(*q)->type = type;
+if((*q)->name == NULL) {
+   free(*q);
+   *q = NULL;
+   return NULL;
+}
+return *q;
+}
+
 /*
  * Parse a section:
  *
@@ -212,7 +232,7 @@
++p;
 *p2 = '\0';
 if (*p == '{') {
-   tmp = get_entry(parent, p1, krb5_config_list);
+   tmp = get_new_entry(parent, p1, krb5_config_list);
if (tmp == NULL) {
*error_message = "out of memory";
return KRB5_CONFIG_BADFORMAT;
--- kpasswd/kpasswdd.c.orig 2005-04-22 13:03:11.0 +0200
+++ kpasswd/kpasswdd.c  2006-05-05 15:39:36.0 +0200
@@ -334,6 +334,9 @@
goto out;
 }
 
+conf.realm = principal->realm;
+conf.mask |= KADM5_CONFIG_REALM;
+
 ret = kadm5_init_with_password_ctx(context, 
   admin,
   NULL,


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages heimdal-kdc depends on:
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  heimdal-clients   0.7.2.dfsg.1-8 Clients for Heimdal Kerberos
ii  krb5-config   1.12   Configuration files for Kerberos V
ii  libasn1-6-heimdal 0.7.2.dfsg.1-8 Libraries for Heimdal Kerberos
ii  libc6 2.5-0exp3  GNU C Library: Shared libraries
ii  libdb4.2  4.2.52+dfsg-1  Berkeley v4.2 Database Libraries [
ii  libhdb7-heimdal   0.7.2.dfsg.1-8 Libraries for Heimdal Kerberos
ii  libkadm5srv7-heimdal  0.7.2.dfsg.1-8 Libraries for Heimdal Kerberos
ii  libkrb5-17-heimdal0.7.2.dfsg.1-8 Libraries for Heimdal Kerberos
ii  libldap2  2.1.30-13.2OpenLDAP libraries
ii  libroken16-heimdal0.7.2.dfsg.1-8 Libraries for Heimdal Kerberos
ii  libssl0.9.8   0.9.8c-4   SSL shared libraries
ii  logrotate 3.7.1-3Log rotation utility
ii  netbase   4.28   Basic TCP/IP networking system

heimdal-kdc recommends no packages.

-- debconf information excluded


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

Bug#398901: pkg-config: pkg.m4: PKG_CONFIG_PATH should be marked as precious

[Gabor Gombas]

Package: pkg-config
Version: 0.21-1
Severity: normal


Hi,

/usr/share/aclocal/pkg.m4 should mark the PKG_CONFIG_PATH environment
variable as 'precious'. Rationale: if the same library is installed at
multiple locations (say, a normal version in a system location and a
devalopment version under my home directory), and during the build of
some software using such a library automake re-runs configure (because
e.g. configure.ac was changed) with a different PKG_CONFIG_PATH (because
e.g. I'm working in a different window), then I'm suddenly using the
wrong version of the library and I get all kinds of misterious failures.

Therefore PKG_CONFIG_PATH (and maybe PKG_CONFIG_LIBDIR) should be marked
as precious by using AC_ARG_VAR(), just like it is done for PKG_CONFIG.

Gabor

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages pkg-config depends on:
ii  libc6 2.5-0exp3  GNU C Library: Shared libraries

pkg-config recommends no packages.

-- no debconf information


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

Bug#398354: tetex-bin: pdflatex segfaults

[Gabor Gombas]

On Mon, Nov 13, 2006 at 07:20:27PM +0100, Hilmar Preusse wrote:

> svn-book.pdf is the SVN book. Do I need a special pdf file to cause
> the fault? Which options did you use?

AFAIR I used "pdfnup --nup 2x1 --outfile /tmp/t.pdf article.pdf". The
article was from a not-yet-published journal; I think it can be
downloaded from Springer so if you have a Springer subscription I can
look up the link, but I fear I'm not allowed to forward the article.
'pdfinfo' says:

Title:
Subject:
Keywords:
Author:
Creator:Springer
Producer:   SPI Publisher Services
CreationDate:   Wed May 31 21:21:25 2006
ModDate:Wed May 31 23:07:07 2006
Tagged: no
Pages:  22
Encrypted:  no
Page size:  552.756 x 737.008 pts
File size:  556742 bytes
Optimized:  yes
PDF version:1.3

> Weird. pdfLaTeX when be called from the command line directly works,
> right?

Just typing 'pdflatex' and then pressing 'Ctrl+D' works.

> > ii  libpoppler0c2   0.5.0-1  PDF rendering library
> > 
> The version of libpoppler0c2 in unstable is actually 0.4.5-5. Does
> downgrading to the official version solve your problem?

I think 0.5.0-1 was installed from experimental. I did not test/check
sid but a clean etch chroot does work without a problem. On AMD64 with
the same library versions (including libpoppler) there is no SIGSEGV,
just typing 'pdflatex' works, but the same pdfnup command still gives

/usr/bin/pdflatex: symbol lookup error: /usr/bin/pdflatex: undefined symbol: 
_ZN6PDFDocC1EP9GooStringS1_S1_

immediately, even without valgrind.

Feel free to reassign the bug if you think it is a fault of libpoppler.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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