Bug#878935: libbpfcc needs a way to ensure the current kernel's headers are installed
On Wed, 2017-10-18 at 13:02 +0100, Ben Hutchings wrote:
> > Please comment on bug #877925 [4] and/or #878922 [3] regarding on how
> > to solve the "this package needs the current kernel's headers
> > installed" problem!
>
> You cannot use package dependencies to do this. It has to be a run-
> time check.
Ok, that's what I figured. Is there at least a solution to the "if the
user has the standard, most recent, Debian kernel running, make sure
the corresponding headers are installed" problem? I.e. something like
Ubuntu's "linux-{image,headers}-generic" packages?
Best regards
Alexander Kurtz
signature.asc
Description: This is a digitally signed message part
Bug#878935: libbpfcc needs a way to ensure the current kernel's headers are installed
Hi! (Applications linked against) libbpfcc will dynamically compile and load C source code into eBPF byte code at runtime and load the result into the kernel for various purposes (e.g. socket filtering, tracing, etc.). For this to work, it needs the kernel headers of the *currently running kernel* [0,1]. Therefore, the maintainer of libbpfcc in Debian added a corresponding dependency [2] which unfortunately breaks everything but amd64 [3] and does also not quite fix the original bug [4]. Please comment on bug #877925 [4] and/or #878922 [3] regarding on how to solve the "this package needs the current kernel's headers installed" problem! Best regards Alexander Kurtz [0] https://github.com/iovisor/bcc/issues/397 [1] https://github.com/iovisor/bcc/issues/743 [2] https://anonscm.debian.org/git/collab-maint/bpfcc.git/commit/?id=f73049e48fd98dd01d4475f88f6b490e6a1b34bb [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878935 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925 signature.asc Description: This is a digitally signed message part
Bug#878935: Unsatisfiable dependencies on !amd64
Package: libbpfcc
Version: 0.3.0-3
Severity: serious
Justification: Makes the package uninstallable on most architectures
Hi!
As [0] shows, libbpfcc has unsatisfiable dependencies on everything but
amd64. This is because [1] is inherently wrong, "linux-headers-amd64"
is of course only available on amd64, the other architectures have
their own meta-packages [2]. Unfortunately there is (AFAIK) no good way
to properly solve the "this package needs the current kernel headers
installed" problem in Debian because
1. There are no (real or virtual) "linux-{image,headers}-
generic" packages (like in Ubuntu [3,4]) which have the same name on
all architectures.
2. Even if there were such packages, there's no guarantee that "linux-
headers-generic" would point to the headers matching the *currently
running* kernel (which is what libbcc needs). In fact, with partial
upgrades, migrations from unstable to testing, upgraded-but-not-yet-
rebooted machines, etc., it is quite likely that libbpfcc will be
broken even if all its dependencies are fulfilled.
I therefore ask you to
1. Revert [1].
2. Reopen [5] and put a note regarding the requirements of the kernel
headers in README.Debian and/or the package description.
3. Talk to the Debian Linux maintainers to find a proper solution to
this problem. It's probably not going to be easy, but these kinds of
problems really deserve to be fixed properly.
Yes, this sucks. I have run into #877925 myself and also thought that
this should be simply solvable with a dependency. Oh, well, at least
you may take comfort in the fact that others [6] have also run into
this problem... ;-)
Best regards
Alexander Kurtz
[0] https://tracker.debian.org/pkg/bpfcc
[1]
https://anonscm.debian.org/git/collab-maint/bpfcc.git/commit/?id=f73049e48fd98dd01d4475f88f6b490e6a1b34bb
[2] https://packages.debian.org/source/sid/linux
[3] https://packages.ubuntu.com/artful/linux-image-generic
[4] https://packages.ubuntu.com/artful/linux-headers-generic
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925
[6] https://anonscm.debian.org/git/pkg-dkms/dkms.git/tree/debian/control#n24
signature.asc
Description: This is a digitally signed message part
Bug#878922: libbpfcc-dev does not depend on libbpfcc
On Tue, 2017-10-17 at 23:43 +0545, Ritesh Raj Sarraf wrote: > After installing the libbpfcc package manually, does it build proper ? Yes. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#878922: libbpfcc-dev does not depend on libbpfcc
Package: libbpfcc-dev
Version: 0.3.0-3
Severity: serious
Justification: Policy violation
Hi!
Debian Policy, section 8.4 ("Development files") [0] says:
Installing the development package must result in installation
of all the development files necessary for compiling programs
against that shared library.
However, libbpfcc-dev does not depend on libbpfcc. This makes
compilation fail, for example like this:
root@riga:~/alfwrapper# make
cc -std=gnu11 -Iinclude -O2 -Wall -Wextra -Werror --output='alfwrapper'
src/alfwrapper.c lib/bcc.c lib/die.c lib/env.c lib/pid.c lib/string.c
lib/cleanup.c lib/path.c lib/fd.c lib/parse.c lib/argv.c lib/socket.c -lbcc
/usr/bin/ld: cannot find -lbcc
collect2: error: ld returned 1 exit status
Makefile:9: recipe for target 'alfwrapper' failed
make: *** [alfwrapper] Error 1
root@riga:~/alfwrapper#
Please fix this by making libbpfcc-dev depend on libbpfcc.
Best regards
Alexander Kurtz
[0] https://www.debian.org/doc/debian-policy/#development-files
signature.asc
Description: This is a digitally signed message part
Bug#875826: epiphany-browser: typing in URL bar lags a lot, preventing correct typing
Hi! On Thu, 2017-09-14 at 22:44 +0200, Matteo F. Vescovi wrote: > I've noticed that, since 3.25.9x version uploaded to experimental suite > for testing purposes in Debian archives, epiphany-browser has an > annoying issue related to bad lags while typing web addresses in the URL > bar. I have experienced this bug too after upgrading to epiphany-browser 3.25.92-1 from experimental; the address bar was basically unusable since you had to type blindly or wait for several seconds for your input to show up. However, for a few days now, I haven't had this problem anymore. Do you still experience this bug? If not, would you mind closing the bug since it currently blocks migration to testing. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#854911: dbus fails to start on package installation on very minimal systems
Control: severity -1 normal Hi! Thanks for your quick reply! I tried to make this bug reproducible and eventually succeeded: The crucial point was, that the package installation must happen *before* systemd considers the system fully booted, i.e. by installing the package inside "/etc/rc.local". This means: 1. This is certainly a corner case, so I have downgraded the severity to "normal". 2. Depending on what our expectations on systemd are, this might be no bug at all. 3. If it is a bug, it is probably not in the dbus package, but rather in the init-system-helpers or systemd package. If you (or the systemd maintainers) are interested, you can reproduce this bug with the attached script: Just run it as root and you should eventually get a login prompt. Login as root (no password required) and run "systemctl status dbus". The output should look like this: root@shepard:~# systemctl status dbus ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2017-02-12 00:17:56 CET; 3min 29s ago Docs: man:dbus-daemon(1) Main PID: 192 (code=exited, status=1/FAILURE) Feb 12 00:17:56 shepard systemd[1]: Started D-Bus System Message Bus. Feb 12 00:17:56 shepard dbus-daemon[192]: Failed to start message bus: No socket received. Feb 12 00:17:56 shepard systemd[1]: dbus.service: Main process exited, code=exited, status=1/FAILURE Feb 12 00:17:56 shepard systemd[1]: dbus.service: Unit entered failed state. Feb 12 00:17:56 shepard systemd[1]: dbus.service: Failed with result 'exit-code'. root@shepard:~# However, please also feel free to simply close this as NOTABUG. Thanks again for your quick reply! Best regards Alexander Kurtz reproduce-854911.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part
Bug#854911: dbus fails to start on package installation on very minimal systems
-activation Feb 11 20:22:28 localhost systemd[1]: Started D-Bus System Message Bus. ● dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (/lib/systemd/system/dbus.socket; static; vendor preset: enabled) Active: active (running) since Sat 2017-02-11 20:22:28 UTC; 9s ago Listen: /var/run/dbus/system_bus_socket (Stream) Feb 11 20:22:28 localhost systemd[1]: Listening on D-Bus System Message Bus Socket. I *think* this might be a race condition between systemd learning about dbus.socket and dbus.service being started by the postinst. Any thoughts? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service
Package: puppet Severity: critical Tags: security Justification: Potentially opens up a new security hole Hi! In the old days, users wanting the puppet binaries but not the puppet daemon would install the puppet-common but not the puppet package [0]. This changed when puppet 4.5 was uploaded to Debian, now the puppet package contained the binaries and the puppet-agent package contained the service [1]. This transition was done properly, as the new service packages would not be installed by default. However, now somebody decided, that it's a good idea to drop the puppet-agent package and move the service file back to the puppet package [1]. This is bad, very, very bad. Here's why: 1. As of today, there is no apparently no package shipping only the binaries but not the service files. 2. I have quite a few systems where I occasionally run puppet manually, but which should never run puppet automatically. 3. Those systems began to look for a puppet master at the default server address "puppet" recently as the new package version got installed. 4. As a result, anybody with control over DNS could have responded and potentially taken over those systems. Please understand that your change made my and potentially other people's system vulnerable without even telling them about it. I urge you strongly to revert this change! Best regards Alexander Kurtz [0] https://packages.debian.org/source/jessie/puppet [1] https://tracker.debian.org/news/771535 [2] https://tracker.debian.org/news/833773 signature.asc Description: This is a digitally signed message part
Bug#851893: The availability of update-grub does not imply that GRUB is used
Hi! On Thu, 2017-01-19 at 22:05 +0100, Aurélien COUDERC wrote: > Thank you for your detailed bug report and analysis. > This looks a lot like #843727 [0] to me, although not for the same use case. > > Would you care to test 9.0.1, already in sid that should fix this problem ? > The following change was done : > 208: update-grub || echo "Updating grub failed, report success anyway!" I am sorry, I had not noticed bug #843727. However, I believe this change is not a correct solution, because: a) "On Error Resume Next" is (in general) not a good idea. b) It is still a GRUB-specific solution. People use a whole bunch of different bootloaders to start Debian, GRUB is just one of them. c) It will cause really subtle bugs under some circumstances. Let me explain c): Assume that a user has the grub-pc package installed and GRUB is installed to /boot normally. At one point, the user decides to remove the grub-pc package (and only that) and use a different bootloader. Everything works, but the files under /boot/grub are of course still there. Now your package comes along and runs update-grub which happily modifies /boot/grub even though the user explicitly removed the GRUB automation package. > I'll merge the 2 bugs after confirmation that it works for you. I agree that your changes fixes the immediate problem. But I really think there are two fundamental issues with desktop-base calling the update script of one specific bootloader: (1) It's surprising to the user (and the maintainers of other packages) (2) It will only work with GRUB > If you know of a better and robust way to detect if grub is being > used, advice is welcome. There is a better way, dpkg triggers [0-3]. There's even a corresponding bug in GRUB about it [4]. However, nobody really seems to care, so not much progress has been made. Maybe you could talk to the GRUB maintainers and convince them to add a "interest update-grub" trigger in the grub-pc and grub-efi packages. Then GRUB's postinst would run the update-grub script and all your postinst would do, is issue a "dpkg-trigger update-grub" call. Of course, it would be even better to find a generic solution for all bootloaders (e.g. a generic "update-bootloader" trigger), but I believe that it's too late in the release cycle for this. What do you think? Best regards Alexander Kurtz [0] https://manpages.debian.org/jessie/dpkg-dev/deb-triggers.5.en.html [1] https://manpages.debian.org/jessie/dpkg/dpkg-trigger.1.en.html [2] http://eric.van-der-vlist.com/blog/owark/473/ [3] https://wiki.debian.org/DpkgTriggers [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481542 signature.asc Description: This is a digitally signed message part
Bug#851893: The availability of update-grub does not imply that GRUB is used
Package: desktop-base Version: 9.0.0 Severity: serious Justification: Package fails to install because of this Hi! People who want to have the GRUB binaries installed (for example to create VM images with GRUB), but don't want to use GRUB as their bootloader will (in the case of classic PCs) have the grub-pc-bin [0] and grub2-common [1] packages installed, but not the grub-pc [2] package as this contains the scripts for the automatic installation. This works fine, but unfortunately, desktop-base's postinst contains the following code: 202 # Apply GRUB background update into /boot 203 if which update-grub > /dev/null ; then 204 # Ensure the background image file has actually been written to disc 205 # before updating. 206 sync 207 update-grub 208 fi Since update-grub is shipped by the grub2-common package (see [3]), this test is wrong. The fact that update-grub is available does not imply that the system uses GRUB to boot. Since update-grub will obviously fail to run if GRUB is not installed to /boot, this bug causes desktop-base's postinst to fail, making the package uninstallable on such systems. Best regards Alexander Kurtz [0] https://packages.debian.org/sid/grub-pc-bin [1] https://packages.debian.org/sid/grub2-common [2] https://packages.debian.org/sid/grub-pc [3] https://packages.debian.org/sid/amd64/grub2-common/filelist signature.asc Description: This is a digitally signed message part
Bug#846944: Installing libnss-resolve before libnss-mdns breaks mDNS name resolution
Package: libnss-resolve Version: 232-6 Severity: serious Justification: Breaks another package Hi! A freshly installed Debian Stretch system will have a /etc/nsswitch.conf like this (see libc-bin's postinst and/or /usr/share/libc-bin/nsswitch.conf): # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat group: compat shadow: compat gshadow:files hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis Installing libnss-resolve makes these changes: --- nsswitch.conf 2016-12-04 15:16:42.701978711 +0100 +++ /etc/nsswitch.conf 2016-12-04 15:16:51.965961200 +0100 @@ -9,7 +9,7 @@ shadow: compat gshadow:files -hosts: files dns +hosts: files resolve [!UNAVAIL=return] dns networks: files protocols: db files If the user then installs for example the "gnome" meta package, libnss-mdns and libnss-myhostname will be installed as well because of these dependencies/recommendations: gnome -> avahi-daemon -> libnss-mdns gnome -> gnome-core -> gnome-control-center -> libnss-myhostname This results in the following hosts line: hosts: files resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return] dns myhostname However, because of the "[!UNAVAIL=return]" introduced with [0], nothing after "resolve" will actually be tried. This is mostly harmless, since "resolve" provides a superset of "dns" and "myhostname", but it breaks mDNS as resolved currently does not resolve mDNS names like "foo.local". Please note, that a) This bug depends on the order of package installations. Installing libnss-resolve *AFTER* everything else will avoid the problem. b) I think the rationale for the change made in [0] is sound, so simply reverting the change is not a solution. IMHO the best solution would be to a) Activate the mDNS support in resolved [1] if possible. b) Talk to the GNOME/Avahi maintainers and make them recommend libnss- resolve instead of the others c) Eventually remove libnss-mdns and libnss-myhostname from Debian as both aren't really maintained anymore and have been superseded by libnss-resolve. Best regard Alexander Kurtz [0] https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=5e0095416366eb86590d6e31242097ded5201b3a [1] https://github.com/systemd/systemd/blob/master/src/resolve/resolved-mdns.c signature.asc Description: This is a digitally signed message part
Bug#835094: APT fails to install packages which conflict with an installed package when APT::Get::Purge=true is used
Package: src:apt Version: 1.3~rc1,1.3~rc2 Severity: serious Hi! APT fails to install packages if: 1. The package to be installed conflicts with an already installed package, and 2. the installed package is a dependency of another installed package, and 3. non-interactive mode is requested via DEBIAN_FRONTEND=noninteractive, and 4. the configuration item "APT::Get::Purge" is set to "true". I noticed this when installing dracut and systemd-cron via puppet (which uses DEBIAN_FRONTEND=noninteractive [0]), replacing the default initramfs-tools and cron packages. I prefer APT::Get::Purge=true and have configured it in /etc/apt/apt.conf as documented [1]. Fortunately I was able to reproduce the failure in a clean sid chroot (see the attached the log files). Here is an excerpt from dracut.log: root@shepard:~# debootstrap sid /tmp/chroot1 [...] root@shepard:~# DEBIAN_FRONTEND=noninteractive chroot /tmp/chroot1 apt-get install --yes --option APT::Get::Purge=true linux-image-amd64 Reading package lists... Done [...] root@shepard:~# DEBIAN_FRONTEND=noninteractive chroot /tmp/chroot1 apt-get install --yes --option APT::Get::Purge=true dracut Reading package lists... Done [...] dpkg: dependency problems prevent removal of initramfs-tools: linux-image-4.6.0-1-amd64 depends on initramfs-tools (>= 0.110~) | linux-initramfs-tool; however: Package initramfs-tools is to be removed. Package linux-initramfs-tool is not installed. Package dracut which provides linux-initramfs-tool is not configured yet. Package initramfs-tools which provides linux-initramfs-tool is to be removed. linux-image-4.6.0-1-amd64 depends on initramfs-tools (>= 0.110~) | linux-initramfs-tool; however: Package initramfs-tools is to be removed. Package linux-initramfs-tool is not installed. Package dracut which provides linux-initramfs-tool is not configured yet. Package initramfs-tools which provides linux-initramfs-tool is to be removed. dpkg: error processing package initramfs-tools (--purge): dependency problems - not removing Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) root@shepard:~# I've chosen Severity: serious because this used to work previously and is now breaking the installation of multiple packages. However, please feel free to change the severity if appropriate! Best regards Alexander Kurtz [0] https://github.com/puppetlabs/puppet/blob/4.5.2/lib/puppet/provider/package/apt.rb#L19 [1] apt-get(8), apt.conf(5)root@shepard:~# debootstrap sid /tmp/chroot1 I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: libaudit-common libaudit1 libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20 libgpg-error0 libncursesw5 libsemanage-common libsemanage1 libsystemd0 libudev1 libustr-1.0-1 I: Found additional base dependencies: dmsetup gnupg-agent libapparmor1 libassuan0 libbsd0 libcap2 libcap2-bin libcryptsetup4 libdevmapper1.02.1 libdns-export162 libelf1 libfastjson4 libffi6 libgmp10 libgnutls30 libhogweed4 libicu57 libidn11 libip4tc0 libip6tc0 libiptc0 libisc-export160 libjson-c3 libksba8 liblocale-gettext-perl liblognorm5 liblz4-1 libmnl0 libnetfilter-conntrack3 libnettle6 libnfnetlink0 libnpth0 libp11-kit0 libpsl5 libseccomp2 libsqlite3-0 libtasn1-6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl pinentry-curses I: Checking component main on http://httpredir.debian.org/debian... I: Retrieving libacl1 2.2.52-3 I: Validating libacl1 2.2.52-3 I: Retrieving adduser 3.115 I: Validating adduser 3.115 I: Retrieving libapparmor1 2.10.95-4 I: Validating libapparmor1 2.10.95-4 I: Retrieving apt 1.3~rc2 I: Validating apt 1.3~rc2 I: Retrieving apt-utils 1.3~rc2 I: Validating apt-utils 1.3~rc2 I: Retrieving libapt-inst2.0 1.3~rc2 I: Validating libapt-inst2.0 1.3~rc2 I: Retrieving libapt-pkg5.0 1.3~rc2 I: Validating libapt-pkg5.0 1.3~rc2 I: Retrieving libattr1 1:2.4.47-2 I: Validating libattr1 1:2.4.47-2 I: Retrieving libaudit-common 1:2.6.6-1 I: Validating libaudit-common 1:2.6.6-1 I: Retrieving libaudit1 1:2.6.6-1 I: Validating libaudit1 1:2.6.6-1 I: Retrieving base-files 9.6 I: Validating base-files 9.6 I: Retrieving base-passwd 3.5.40 I: Validating base-passwd 3.5.40 I: Retrieving bash 4.3-15 I: Validating bash 4.3-15 I: Retrieving libdns-export162 1:9.10.3.dfsg.P4-10.1 I: Validating libdns-export162 1:9.10.3.dfsg.P4-10.1 I: Retrieving libisc-export160 1:9.10.3.dfsg.P4-10.1 I: Validating
Bug#834757: Breaks between gnupg1 and gnupg currently break bootstrapping of stretch
Package: gnupg1 Version: 1.4.20-7 Severity: serious Hi! Testing currently has this: [0] [1] gnupg => 1.4.20-6 gnupg1 => 1.4.20-7 Those versions are incompatible. [2] However, gnupg1 still has Priority: important [3] which means debootstrap will install it per default. Since the gnupg package is also installed because of some dependencies, this currently breaks bootstrapping stretch. I have attached a full log of a failed debootstrap, but you should be able to easily reproduce this by trying to debootstrap stretch. Best regards Alexander Kurtz [0] https://tracker.debian.org/pkg/gnupg [1] https://tracker.debian.org/pkg/gnupg1 [2] https://anonscm.debian.org/cgit/pkg-gnupg/gnupg1.git/tree/debian/control?h=debian/1.4.20-7#n38 [3] https://anonscm.debian.org/cgit/pkg-gnupg/gnupg1.git/tree/debian/control?h=debian/1.4.20-7#n3root@shepard:~# debootstrap stretch /tmp/chroot I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: libaudit-common libaudit1 libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20 libgpg-error0 libncursesw5 libsemanage-common libsemanage1 libsystemd0 libudev1 libustr-1.0-1 I: Found additional base dependencies: dmsetup libapparmor1 libbsd0 libcap2 libcap2-bin libcryptsetup4 libdevmapper1.02.1 libdns-export162 libffi6 libgmp10 libgnutls30 libhogweed4 libicu57 libidn11 libip4tc0 libip6tc0 libiptc0 libisc-export160 libjson-c3 liblocale-gettext-perl liblz4-1 libmnl0 libnetfilter-conntrack3 libnettle6 libnfnetlink0 libp11-kit0 libpsl5 libseccomp2 libtasn1-6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl I: Checking component main on http://httpredir.debian.org/debian... I: Retrieving libacl1 2.2.52-3 I: Validating libacl1 2.2.52-3 I: Retrieving adduser 3.115 I: Validating adduser 3.115 I: Retrieving libapparmor1 2.10.95-4 I: Validating libapparmor1 2.10.95-4 I: Retrieving apt 1.3~rc1 I: Validating apt 1.3~rc1 I: Retrieving apt-utils 1.3~rc1 I: Validating apt-utils 1.3~rc1 I: Retrieving libapt-inst2.0 1.3~rc1 I: Validating libapt-inst2.0 1.3~rc1 I: Retrieving libapt-pkg5.0 1.3~rc1 I: Validating libapt-pkg5.0 1.3~rc1 I: Retrieving libattr1 1:2.4.47-2 I: Validating libattr1 1:2.4.47-2 I: Retrieving libaudit-common 1:2.6.5-1 I: Validating libaudit-common 1:2.6.5-1 I: Retrieving libaudit1 1:2.6.5-1 I: Validating libaudit1 1:2.6.5-1 I: Retrieving base-files 9.6 I: Validating base-files 9.6 I: Retrieving base-passwd 3.5.39 I: Validating base-passwd 3.5.39 I: Retrieving bash 4.3-15 I: Validating bash 4.3-15 I: Retrieving libdns-export162 1:9.10.3.dfsg.P4-10.1 I: Validating libdns-export162 1:9.10.3.dfsg.P4-10.1 I: Retrieving libisc-export160 1:9.10.3.dfsg.P4-10.1 I: Validating libisc-export160 1:9.10.3.dfsg.P4-10.1 I: Retrieving blends-tasks 0.6.93 I: Validating blends-tasks 0.6.93 I: Retrieving libboost-iostreams1.60.0 1.60.0+dfsg-6+b1 I: Validating libboost-iostreams1.60.0 1.60.0+dfsg-6+b1 I: Retrieving bsdmainutils 9.0.10 I: Validating bsdmainutils 9.0.10 I: Retrieving libbz2-1.0 1.0.6-8 I: Validating libbz2-1.0 1.0.6-8 I: Retrieving libdebconfclient0 0.215 I: Validating libdebconfclient0 0.215 I: Retrieving coreutils 8.25-2 I: Validating coreutils 8.25-2 I: Retrieving cpio 2.11+dfsg-5 I: Validating cpio 2.11+dfsg-5 I: Retrieving cron 3.0pl1-128 I: Validating cron 3.0pl1-128 I: Retrieving libcryptsetup4 2:1.7.0-2 I: Validating libcryptsetup4 2:1.7.0-2 I: Retrieving dash 0.5.8-2.3 I: Validating dash 0.5.8-2.3 I: Retrieving libdb5.3 5.3.28-12 I: Validating libdb5.3 5.3.28-12 I: Retrieving debconf 1.5.59 I: Validating debconf 1.5.59 I: Retrieving debconf-i18n 1.5.59 I: Validating debconf-i18n 1.5.59 I: Retrieving debian-archive-keyring 2014.3 I: Validating debian-archive-keyring 2014.3 I: Retrieving debianutils 4.8 I: Validating debianutils 4.8 I: Retrieving diffutils 1:3.3-3 I: Validating diffutils 1:3.3-3 I: Retrieving dmidecode 3.0-3 I: Validating dmidecode 3.0-3 I: Retrieving dpkg 1.18.10 I: Validating dpkg 1.18.10 I: Retrieving e2fslibs 1.43.1-1 I: Validating e2fslibs 1.43.1-1 I: Retrieving e2fsprogs 1.43.1-1 I: Validating e2fsprogs 1.43.1-1 I: Retrieving libcomerr2 1.43.1-1 I: Validating libcomerr2 1.43.1-1 I: Retrieving libss2 1.43.1-1 I: Validating libss2 1.43.1-1 I: Retrieving findutils 4.6.0+git+20160703-2 I: Validating findutils 4.6.0+git+20160703-2 I: Retrieving gcc-4.9-base 4.9.3-14 I: Validating gcc-4.9-base 4.9.3-14 I: Retrieving gcc-5-base 5.4.1-1 I: Validating gcc-5-base 5.4.1-1 I: Retrieving gcc-6-base 6.1.1-11 I: Validating gcc-6-base 6.1.1-11 I: Retrieving libgcc1 1:6.1.1-11 I: Validating libgcc1 1:6.1.1-11 I: Retrieving libstdc++6 6.1.1-11 I: Validating libstdc++6 6.1.1-11 I: Retrieving libgdbm3 1.8.3-14 I: Validating libgdbm3 1.8.
Bug#797003: libical 1.0.1-0.1 has broken its ABI (again)
Hi, evolution-data-server 3.16.5-1 (which was uploaded *after* libical 1.0.1-0.1 [0] [1] and therefore already built with the newer version) migrated to testing yesterday [2], followed by evolution itself today. Upgrading evolution and evolution-data-server therefore makes the calendar functionality work correctly again, just like last time [3]. I have also taken a closer look at the diff between libical 1.0-1.3 and 1.0.1-0.1 [4] and libicals ABI specification [5] and now *think* that it does actually ship a stable ABI and the break we have experienced is simply the result of the transition from the previous, unstable ABI (which Debian changed again to make the build reproducible [6]) to the new stable ABI. Please also see [7] in regard to that. This means, that this bug (#797003) is actually not a bug, but rather a symptom of a bugfix and the actual bug is the missing transition [8] for libical. It might be worth checking the other reverse dependencies of libical, since there's a good chance most of them have already been rebuilt with the new version because of the GCC 5 transition. With any luck, both this bug and the transition bug can be closed without any further action. Adding the ABI check you proposed [9] is probably still a *very* good idea, as is making the build reproducible [A], but this can be done in a regular upload. Best regards Alexander Kurtz [0] https://tracker.debian.org/news/705666 [1] https://tracker.debian.org/news/708081 [2] https://tracker.debian.org/news/710550 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766454#31 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=1.0-1.3-to-1.0.1-0.1.diff;att=1;bug=797003;msg=5 [5] https://github.com/libical/libical/tree/master/design-data [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916#32 [8] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797074 [9] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797074#17 [A] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796360 signature.asc Description: This is a digitally signed message part
Bug#797003: libical 1.0.1-0.1 has broken its ABI (again)
Hi, On Mon, 2015-09-07 at 13:00 +0200, Andreas Henriksson wrote: > I think we won't touch the soname, since we usually try to not > deviate from what upstream uses but only change the package > name and add conflicts against old package name... > (This solves packaged software upgrades, but leaves self-compiled > binaries out in the cold.) > Same as was done last time the ABI broke in similar way. This seems very reasonable. Do you agree with my assessment, that libical *is* actually ABI-stable now and should not break compatibility in future versions, even if new entries are added to the various enums? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#797003: libical 1.0.1-0.1 has broken its ABI (again)
Hi, On Mon, 2015-09-07 at 12:16 +0200, Andreas Henriksson wrote: > Yes, everything built after/against the new libical will pick up > the new ABI and work (only) with the new version. > In debian we try to support partial upgrades though (eg. mixtures > of stable and testing), so this is still considered a bug even if we > rebuild all reverse dependencies of libical. I see. > Yes upstream seems to think so, that's what fooled me into believing > the update was safe. It doesn't seem to be true though. > Every time new header files are generated there's a risk of ABI > breakage since something new might have been added to the source > database which will get *sorted* during header/enum generation which > means the new addition might get added to the middle (rather then the > end, which would have been perferctly fine,) of the enum breaking ABI > for everything in the enum after the new addition. > > This was actually caught when the sorting patch was first introduced > see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916#27 Isn't the explicit assignment of (stable) numeric values to the symbolic constants done in [0] also supposed to prevent exactly that? The generated enums might have new entries in the middle, but the *numeric* values of the old entries should still be the same. IIRC the ordering in enums only matters if the corresponding numerical values are not (all) set explicitly, but automatically set by the compiler. > Since we support partial upgrades, the broken ABI is still a bug > and needs a transition. Agreed, but from what I can tell, a SONAME bump (along with the corresponding transition) is all that's required, there should be no changes necessary to the actual code. Best regards Alexander Kurtz [0] https://github.com/libical/libical/tree/master/design-data signature.asc Description: This is a digitally signed message part
Bug#797003: libical 1.0.1-0.1 has broken its ABI (again)
Package: libical-dev
Version: 1.0.1-0.1
Severity: serious
Hi,
it seems that the latest upload of libical (1.0.1-0.1) has broken its
ABI yet again. Please see the attached diff (generated using
snapshots.debian.org [0]) for a comparison of the contents of
/usr/include/ between version 1.0-1.3 and 1.0.1-0.1.
This has happened in the past already: See #773916 [1] and its merged
bug reports for a description of the problem and the resulting effects.
For me, this results (again) in evolution (and gnome-shell) displaying
recurring events without end making the calendar functionality unusable
(even more than last time, since evolution simply crashes now). YMMV.
I don't understand the underlying issue well enough to write a patch,
but having a close look at the two patches which were dropped according
to the changelog [2] as well as #796360 [3] seems like a good start. In
the end, this will probably mean uploading a fixed version with a
different SONAME again and starting the corresponding transition.
Best regards
Alexander Kurtz
[0] http://snapshot.debian.org/archive/debian/20150825T214917Z/pool/mai
n/libi/libical/
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916
[2] https://tracker.debian.org/news/705666
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796360diff -Naur libical-dev_1.0-1.3_amd64/usr/include/ical.h libical-dev_1.0.1-0.1_amd64/usr/include/ical.h
--- libical-dev_1.0-1.3_amd64/usr/include/ical.h 2015-01-03 14:58:53.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/ical.h 2014-10-09 17:07:05.0 +0200
@@ -4,7 +4,7 @@
CREATOR: ajc 2008-sep-01
(C) COPYRIGHT 2008 by Art Cancro
- http://freeassociation.sourceforge.net
+ http://libical.github.io/libical/
This program is free software; you can redistribute it and/or modify
it under the terms of either:
diff -Naur libical-dev_1.0-1.3_amd64/usr/include/libical/icalcomponent.h libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalcomponent.h
--- libical-dev_1.0-1.3_amd64/usr/include/libical/icalcomponent.h 2015-01-03 14:58:53.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalcomponent.h 2014-10-09 17:07:05.0 +0200
@@ -281,5 +281,8 @@
icalcomponent* icalcomponent_new_xdaylight(void);
icalcomponent* icalcomponent_new_vagenda(void);
icalcomponent* icalcomponent_new_vquery(void);
+icalcomponent* icalcomponent_new_vavailability(void);
+icalcomponent* icalcomponent_new_xavailable(void);
+icalcomponent* icalcomponent_new_vpoll(void);
#endif /* !ICALCOMPONENT_H */
diff -Naur libical-dev_1.0-1.3_amd64/usr/include/libical/icalderivedparameter.h libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalderivedparameter.h
--- libical-dev_1.0-1.3_amd64/usr/include/libical/icalderivedparameter.h 2015-01-03 14:59:18.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalderivedparameter.h 2015-08-19 19:28:06.0 +0200
@@ -60,15 +60,18 @@
ICAL_MEMBER_PARAMETER = 18,
ICAL_OPTIONS_PARAMETER = 19,
ICAL_PARTSTAT_PARAMETER = 20,
+ICAL_PUBLICCOMMENT_PARAMETER = 37,
ICAL_RANGE_PARAMETER = 21,
ICAL_RELATED_PARAMETER = 22,
ICAL_RELTYPE_PARAMETER = 23,
+ICAL_RESPONSE_PARAMETER = 38,
ICAL_ROLE_PARAMETER = 24,
ICAL_RSVP_PARAMETER = 25,
ICAL_SCHEDULEAGENT_PARAMETER = 34,
ICAL_SCHEDULEFORCESEND_PARAMETER = 35,
ICAL_SCHEDULESTATUS_PARAMETER = 36,
ICAL_SENTBY_PARAMETER = 26,
+ICAL_STAYINFORMED_PARAMETER = 39,
ICAL_TZID_PARAMETER = 27,
ICAL_VALUE_PARAMETER = 28,
ICAL_X_PARAMETER = 29,
@@ -157,7 +160,8 @@
ICAL_RELTYPE_PARENT = 20047,
ICAL_RELTYPE_CHILD = 20048,
ICAL_RELTYPE_SIBLING = 20049,
-ICAL_RELTYPE_NONE = 20050
+ICAL_RELTYPE_NONE = 20050,
+ICAL_RELTYPE_POLL = 20107
} icalparameter_reltype;
typedef enum icalparameter_role {
@@ -190,6 +194,13 @@
ICAL_SCHEDULEFORCESEND_NONE = 20068
} icalparameter_scheduleforcesend;
+typedef enum icalparameter_stayinformed {
+ICAL_STAYINFORMED_X = 20108,
+ICAL_STAYINFORMED_TRUE = 20109,
+ICAL_STAYINFORMED_FALSE = 20110,
+ICAL_STAYINFORMED_NONE = 20111
+} icalparameter_stayinformed;
+
typedef enum icalparameter_value {
ICAL_VALUE_X = 20069,
ICAL_VALUE_BINARY = 20070,
@@ -237,7 +248,7 @@
ICAL_XLICERRORTYPE_NONE = 20106
} icalparameter_xlicerrortype;
-#define ICALPARAMETER_LAST_ENUM 20107
+#define ICALPARAMETER_LAST_ENUM 20112
/* ACTIONPARAM */
icalparameter* icalparameter_new_actionparam(icalparameter_action v);
@@ -344,6 +355,11 @@
icalparameter_partstat icalparameter_get_partstat(const icalparameter* value);
void icalparameter_set_partstat(icalparameter* value, icalparameter_partstat v);
+/* PUBLIC-COMMENT */
+icalparameter* icalparameter_new_publiccomment(const char* v);
+const char* icalparameter_get_publiccomment(const icalparameter* value);
+void icalparameter_set_publiccomment(icalparameter* value, const char* v);
+
/* RANGE */
icalparameter
Bug#755807: CUPS listens on *all* interfaces per default when installed on machines using systemd
Hi! On Thu, 2014-07-24 at 22:06 +0200, Didier 'OdyX' Raboud wrote: For the record, I disagree with the severity and the security tag, but will focus on fixing this bug. :) Thanks! I suppose the severity might have been a little overrated, but I get a bit nervous when one of my desktop machines suddenly shows up on one of my regular nmap runs. Anyway, cups 1.7.4-4 just migrated to testing and I can happily report that everything now works as intended both on new installations and on upgrades. Thank you very much for your work! Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#755807: CUPS listens on *all* interfaces per default when installed on machines using systemd
Package: cups-daemon Version: 1.7.4-1 Severity: serious Justification: Information leak and possible security vulnerability Tags: security Hi, installing (not upgrading!) the cups-daemon package on a machine using systemd as PID 1 creates the /etc/cups/cupsd-systemd-listen.conf file like this: [Socket] # This file was generated by CUPS and _WILL_ be deleted or overwritten by it! # It has to be kept in sync with the Port and Listen stanzas in /etc/cups/cupsd.conf # It is by default symlinked as cups-listen.conf in the # /etc/systemd/system/cups.socket.d/ directory. Remove the symlink # and write your own file there if you don't want this. See systemd.socket(5). # Matches the default 'Listen localhost:631' from cupsd.conf.default ListenStream=0.0.0.0:631 ListenStream=[::]:631 As this file gets symlinked from the /etc/systemd/system/cups.socket.d/ directory, this means that systemd will listen on *all* interfaces and hand the incoming connections to CUPS. Admittedly, CUPS still enforces it's own access limitations set in /etc/cups/cupsd.conf, but only after initially accepting the connection. It will then respond with a HTTP 403 (Forbidden) error page, confirming that there is indeed a CUPS daemon running and leaking (at least) its version number and the system locale. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#755807: CUPS listens on *all* interfaces per default when installed on machines using systemd
Hi, After looking over cups-daemon's preinst script which generates the cupsd-systemd-listen.conf file, I think I found the problem(s): 1 #!/bin/sh 2 3 set -e 4 5 6 case $1 in 7 install|upgrade) 8 if dpkg --compare-versions $2 le 1.6.1 [ -e /etc/cups/cupsd.conf ]; then 9 # Move cupsd.conf away as it becomes a non-conffile 10 mv /etc/cups/cupsd.conf /etc/cups/cupsd.conf.conffile-bak 11 fi 12 13 # If file doesn't exist or if it has two conflicting stanzas 14 if [ ! -f /etc/cups/cupsd-systemd-listen.conf ] || \ 15 ( grep -q '^ListenStream=0.0.0.0:' /etc/cups/cupsd-systemd-listen.conf 2/dev/null \ 16 grep -q '^ListenStream=127.0.0.1:' /etc/cups/cupsd-systemd-listen.conf 2/dev/null ) ;\ 17 then This is problem #1. This means that /etc/cups/cupsd-systemd-listen.conf will not regenerated if it already exists unless there are conflicting stanzas. While this is generally a good idea for configuration files, it also means that an incorrect file will never be corrected. 18 mkdir -p /etc/cups 19 cat /etc/cups/cupsd-systemd-listen.conf EOF 20 [Socket] 21 # This file was generated by CUPS and _WILL_ be deleted or overwritten by it! 22 # It has to be kept in sync with the Port and Listen stanzas in /etc/cups/cupsd.conf 23 # It is by default symlinked as cups-listen.conf in the 24 # /etc/systemd/system/cups.socket.d/ directory. Remove the symlink 25 # and write your own file there if you don't want this. See systemd.socket(5). 26 EOF 27 if [ -e /etc/cups/cupsd.conf ]; then This is problem #2. This means, that the /etc/cups/cupsd.conf file will only be parsed if it exists. However, this is the *pre*inst script, meaning that this check will always fail on new installations since the package isn't unpacked yet when this runs. [0] 28 if grep -q '^\s*Port' /etc/cups/cupsd.conf 2/dev/null; then 29 localport=`grep '^\s*Port' /etc/cups/cupsd.conf | head -n1 | sed -e 's/.*Port \([[:digit:]]*\)$/\1/'` 30 cat /etc/cups/cupsd-systemd-listen.conf EOF 31 # Matches 'Port $localport' from cupsd.conf 32 ListenStream=0.0.0.0:$localport 33 ListenStream=[::]:$localport 34 EOF 35 elif grep -q '^\s*Listen localhost:' /etc/cups/cupsd.conf 2/dev/null; then 36 localport=`grep '^\s*Listen localhost:' /etc/cups/cupsd.conf | head -n1 | sed -e 's/.*localhost\:\([[:digit:]]*\)$/\1/'` 37 cat /etc/cups/cupsd-systemd-listen.conf EOF 38 # Matches 'Listen localhost:$localport' from cupsd.conf 39 ListenStream=127.0.0.1:$localport 40 ListenStream=[::1]:$localport 41 EOF 42 fi 43 else 44 cat /etc/cups/cupsd-systemd-listen.conf EOF 45 # Matches the default 'Listen localhost:631' from cupsd.conf.default 46 ListenStream=0.0.0.0:631 47 ListenStream=[::]:631 This is problem #3. This means that CUPS will listen on all interfaces even though the comment directly above says exactly the opposite. This looks a lot like a simple typo. 48 EOF 49 fi 50 fi 51 esac 52 53 # Automatically added by dh_installdeb 54 dpkg-maintscript-helper rm_conffile /etc/cups/cupsd.conf.default 1.7.1-3~ -- $@ 55 # End automatically added section 56 # Automatically added by dh_installdeb 57 dpkg-maintscript-helper rm_conffile /etc/default/cups 1.7.1-6~ -- $@ 58 # End automatically added section 59 # Automatically added by dh_installdeb 60 dpkg-maintscript-helper mv_conffile /etc/pam.d/cups-daemon /etc/pam.d/cups 1.7.3-2~ -- $@ 61 # End automatically added section 62 63 64 exit 0 The result is, that because of problem #2, /etc/cups/cupsd.conf will never actually be parsed on new installations. Instead the incorrect fallback configuration will be used (problem #3). And because of problem #1, this will never be corrected, even when the package is updated or reinstalled. Best regards Alexander Kurtz [0] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html signature.asc Description: This is a digitally signed message part
Bug#736472: Missing dependency on GCC
Package: ghc Version: 7.6.3-6 Severity: serious Justification: Makes the package unusable Hi, installing the ghc package without the gcc package results in this: $ cat test.hs main :: IO () main = putStrLn Hello World $ ghc test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: could not execute: /usr/bin/gcc $ echo $? 1 $ ghci test.hs GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. ghc: could not execute: /usr/bin/gcc $ echo $? 1 $ This problem can be trivially fixed by installing the gcc package. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#680684: libaugeas-ruby depends on libaugeas-ruby1.8 but ruby 1.9 is the default now
Package: libaugeas-ruby Version: 0.4.1-1 Severity: grave Justification: Package doesn't fulfill its main purpose Hi, the package description says: This is a dependency package which depends on Debian's default Ruby version (currently 1.8.x). However, since 2012-06-03/2012-06-14 ruby 1.9 is the default ruby version in both unstable and testing: http://packages.qa.debian.org/r/ruby-defaults/news/20120603T212352Z.html http://packages.qa.debian.org/r/ruby-defaults/news/20120614T163924Z.html Please update the dependency and the description. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#680688: puppet-common depends on libaugeas-ruby1.8 but ruby 1.9 is the default now
Package: puppet-common Version: 2.7.17-1 Severity: grave Justification: Won't parse any manifests using the built-in augeas resource Hi, since 2012-06-03/2012-06-14 ruby 1.9 is the default ruby version in both unstable and testing: http://packages.qa.debian.org/r/ruby-defaults/news/20120603T212352Z.html http://packages.qa.debian.org/r/ruby-defaults/news/20120614T163924Z.html Newly installed system will therefore have ruby 1.9 installed by default. However, puppet-common still depends on libaugeas-ruby1.8. This means that puppet will choke on manifests using the built-in augeas resource: $ sudo puppet agent --test [...] err: Could not find a suitable provider for augeas notice: Finished catalog run in 0.69 seconds $ Installing libaugeas-ruby1.9.1 fixes the problem. A quick solution would therefore be to change the dependency to libaugeas-ruby1.9.1. However, I think the cleaner approach would be to wait for #680684[0] to be fixed and to change the dependency to libaugeas-ruby. Best regards Alexander Kurtz PS: You should probably check the other dependencies too: puppet-common also depends on libshadow-ruby1.8 and suggests librrd-ruby1.8. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680684 signature.asc Description: This is a digitally signed message part
Bug#674668: Starting Evolution often crashes the GNOME session
Package: gnome-shell Version: 3.2.2.1-4 Severity: grave Justification: Entire session crashes; can cause serious data loss Hi, for about a week now, I've had sudden crashes of the GNOME session, i.e. the X session terminates (killing all running programs in the process) and I'm back at the login screen. These crashes have always happened directly after starting Evolution from gnome-shell's dash. I first suspected a video driver bug, but now I've seen seen these crashes on two machines (both with an up-to-date 64-bit Debian testing) with different video cards. When trying to reproduce this behavior, I discovered that I could reliably crash the session simply by starting and closing Evolution repeatedly (on average about 10 times). I've attached two .xsession-errors files from such crashes (line #42 from file #2 seems to be particularly interesting). Unfortunately there have been no messages in the dmesg output. Please tell me if you need anything else to reproduce and/or debug this problem. Best regards Alexander Kurtz /etc/gdm3/Xsession: Beginning session setup... localuser:alexander being added to access control list GNOME_KEYRING_CONTROL=/tmp/keyring-jlPmrU GPG_AGENT_INFO=/tmp/keyring-jlPmrU/gpg:0:1 GNOME_KEYRING_CONTROL=/tmp/keyring-jlPmrU GPG_AGENT_INFO=/tmp/keyring-jlPmrU/gpg:0:1 GNOME_KEYRING_CONTROL=/tmp/keyring-jlPmrU GPG_AGENT_INFO=/tmp/keyring-jlPmrU/gpg:0:1 GNOME_KEYRING_CONTROL=/tmp/keyring-jlPmrU GPG_AGENT_INFO=/tmp/keyring-jlPmrU/gpg:0:1 SSH_AUTH_SOCK=/tmp/keyring-jlPmrU/ssh (gnome-settings-daemon:29250): keybindings-plugin-WARNING **: Key binding (hamster-applet) is incomplete Initializing tracker-store... Tracker-Message: Setting up monitor for changes to config file:'/home/alexander/.config/tracker/tracker-store.cfg' Tracker-Message: Setting up monitor for changes to config file:'/home/alexander/.config/tracker/tracker-store.cfg' Starting log: File:'/home/alexander/.local/share/tracker/tracker-store.log' Initializing tracker-miner-fs... Tracker-Message: Setting up monitor for changes to config file:'/home/alexander/.config/tracker/tracker-miner-fs.cfg' Starting log: File:'/home/alexander/.local/share/tracker/tracker-miner-fs.log' (tracker-miner-fs:29304): Tracker-WARNING **: Couldn't properly parse desktop file 'file:///usr/share/applications/brasero-nautilus.desktop': 'Desktop file doesn't contain type' ** (nm-applet:29306): WARNING **: _nm_remote_settings_ensure_inited: (NMRemoteSettings) error initializing: Launch helper exited with unknown return code 1 ** (nm-applet:29306): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: Launch helper exited with unknown return code 1 ** Message: applet now removed from the notification area Window manager warning: Log level 16: Could not initialize NMClient /org/freedesktop/NetworkManager: Launch helper exited with unknown return code 1 Window manager warning: Log level 16: _nm_remote_settings_ensure_inited: (NMRemoteSettings) error initializing: Launch helper exited with unknown return code 1 ** (nm-applet:29306): WARNING **: fetch_connections_done: error fetching connections: (25) Launch helper exited with unknown return code 1. ** (nm-applet:29306): WARNING **: Failed to register as an agent: (25) Launch helper exited with unknown return code 1 ** Message: applet now embedded in the notification area Window manager warning: Log level 16: fetch_connections_done: error fetching connections: (25) Launch helper exited with unknown return code 1. unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 ** (evolution:29438): CRITICAL **: categories_icon_theme_hack: assertion `filename != NULL *filename != '\0'' failed (evolution:29438): evolution-network-manager-WARNING **: network_manager_query_state: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (gnome-shell:29293): Clutter-CRITICAL **: clutter_actor_iter_next: assertion `ri-age == ri-root-priv-age' failed (gnome-shell:29293): Clutter-CRITICAL **: clutter_actor_iter_next: assertion `ri-age == ri-root-priv-age' failed unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 unhandled event type: 33 BrlAPI exception: Invalid parameter on Write request of size 26 (66 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00) You may wish to add the -ldebug option to the brltty command line in order to get additional information in the system log (evolution:29438): GLib-GObject-WARNING **: g_object_weak_unref: couldn't find weak ref 0x7f19238e8da0(0xbbb5c0) Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus
Bug#674668: Starting Evolution often crashes the GNOME session
Hi, I've just upgraded gnome-shell and evolution to version 3.4.1-1 and 3.4.2-1 (both from experimental). Unfortunately the crashes still occur. What's interesting though, is that the crash actually seems to happen in the X-Server. I found this in /var/log/Xorg.0.log.old: [ 51714.050] [ 51714.050] Backtrace: [ 51714.051] 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x7ff5cac0c796] [ 51714.051] 1: /usr/bin/Xorg (0x7ff5caa8e000+0x1822b9) [0x7ff5cac102b9] [ 51714.051] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff5c9db6000+0xf030) [0x7ff5c9dc5030] [ 51714.051] 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7ff5c8ac1000+0x383128) [0x7ff5c8e44128] [ 51714.051] [ 51714.051] Segmentation fault at address 0x7ff5c8e44128 [ 51714.051] Fatal server error: [ 51714.051] Caught signal 11 (Segmentation fault). Server aborting [ 51714.051] [ 51714.051] Any ideas? Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#619723: brasero: diff for NMU version 3.2.0-3.1
Hi everybody, On Sat, 2012-03-03 at 20:49 +, Simon McVittie wrote: The analysis and patch from Tanguy look correct, so I've prepared an NMU for brasero (versioned as 3.2.0-3.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. I can confirm that your patch (which is based on Tanguy Ortolo's patch) does indeed fix the problem. I was able to successfully burn the test case[0] which I submitted last year[1]. Thank you very much! On Sun, 2012-03-04 at 00:33 +0100, Michael Biebl wrote: Thanks for the patch. Do you know if it has been forwarded upstream? Tanguy Ortolo has forwarded[2] this bug and his patch on 2011-11-24 to GNOME's bugzilla[3]. Unfortunately upstream has not yet responded. Best regards Alexander Kurtz [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=testcase.tar.xz;att=1;bug=619723 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619723#23 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=56;bug=619723 [3] https://bugzilla.gnome.org/show_bug.cgi?id=664756 signature.asc Description: This is a digitally signed message part
Bug#649384: gnash creates world-readable cookies under /tmp
Package: gnash Version: 0.8.10~git20111001-1 Tags: security Severity: critical Justification: Introduces a new security hole Hi, after watching videos on YouTube I found this in /tmp: $ ls -l /tmp/gnash* -rw-r--r-- 1 alexander alexander 329 Nov 20 15:22 /tmp/gnash-cookies.31032 $ Please note that the file is world-readable. This enables things like: $ sudo -u nobody cat /tmp/gnash-cookies.31032 Set-Cookie: use_hitbox=72c46ff6cbcdb7c5585c36411b6b334edAEw Set-Cookie: VISITOR_INFO1_LIVE=WEbeevRfDNo Set-Cookie: recently_watched_video_id_list=885d7cf2658d586fc1bef37a995ce29cWwEAAABzCwAAAHV3SFIwM1pHd1k4 Set-Cookie: GEO=0bf89ff87b12d82d91e10ddf1da36d95cwszREVUmagnTskNGQ== Set-Cookie: PREF=f1=4000fv=10.1.999 $ Since gnash is installed per default and also starts playing as soon as flash content is detected, this can be a serious security/privacy issue on multi-user systems. Gnash should either use $HOME for storing cookies or create them with sane permissions (0600). Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#649384: gnash creates world-readable cookies under /tmp
retitle 649384 gnash creates world-readable cookies under /tmp with predictable filenames thanks On Sun, 2011-11-20 at 18:01 +0100, Gabriele Giacone wrote: tags 649384 fixed-upstream thanks On Sun, Nov 20, 2011 at 03:39:36PM +0100, Alexander Kurtz wrote: or create them with sane permissions (0600). http://git.savannah.gnu.org/gitweb/?p=gnash.git;a=commitdiff;h=fa481c116e65ccf9137c7ddc8abc3cf05dc12f55 I don't think this fixes the underlying problem: An attacker would still be able to read the cookie if he managed to win the race-condition and opens the file before the chmod(). If you agree, please remove the fixed-upstream tag. Furthermore, I took a quick look at the code and noticed this: 1105 gnash::log_debug(The Cookie for %s is %s, url, ncookie); 1106 std::ofstream cookiefile; 1107 std::stringstream ss; 1108 ss /tmp/gnash-cookies. getpid(); 1109 1110 cookiefile.open(ss.str().c_str(), std::ios::out | std::ios::trunc); chmod (ss.str().c_str(), 0600); I might be wrong, but I very strongly suspect a possible symlink attack here which would enable an attacker to overwrite arbitrary files and (with your patch) change their permissions. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#649384: gnash creates world-readable cookies under /tmp
On Sun, 2011-11-20 at 21:12 +0100, Francesco Poli wrote: I would add the following consideration: why does gnash create cookies at all? Good question. Could someone please tell me where is the option to disable cookies? I think there should be one, but I seem to be unable to find it... I configured this via the gnash GUI: $ grep -i sol ~/.gnashpluginrc set solReadOnly true set solLocalDomain false set SOLSafeDir /home/alexander/.gnash/SharedObjects $ Hope this helps! Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#649384: gnash creates world-readable cookies under /tmp
On Sun, 2011-11-20 at 21:43 +0100, Francesco Poli wrote: And did gnash stop creating cookies in /tmp after that configuration change? Nope. Also, does it refrain from creating cookies in your ~/.gnash/SharedObjects directory? Yes. It still created some subdirectories, but no actual cookies. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#645427: Stopped locking the screen when closing the laptop lid
On Sat, 2011-10-15 at 12:21 -0700, Josh Triplett wrote: I upgraded gnome-screensaver, and it stopped locking the screen when I close the lid of my laptop. It now only locks if I explicitly lock the screen (ctrl-alt-L), or after some timeout (on the order of 5-15 minutes, ). I just read the whole bug log and noticed that nobody seemed to be really sure what actually caused the bug. While bumping the dependency on gnome-session-bin certainly didn't hurt, I suspect that the real cause is actually #647358[0] which was recently fixed, so maybe you could give it another try. Hope this helps Alexander Kurt [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647358 signature.asc Description: This is a digitally signed message part
Bug#645427: Stopped locking the screen when closing the laptop lid
Thank you for merging the bugs. Please note that the workaround is no longer necessary since g-p-m has been patched meanwhile[0]. Part of the fix was also to add a dependency on gnome-screensaver (= 3.0). This should avoid partial upgrades. Best regards Alexander Kurtz PS: Maybe you could keep an eye open, I'm quite sure we'll see further duplicates of #647358. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647358#10 signature.asc Description: This is a digitally signed message part
Bug#647358: g-p-m doesn't lock the screen on lid-close because it uses an obsolete GConf key
Package: gnome-power-manager Version: 3.0.2-2 Severity: critical Justification: Introduces a new security hole Tags: fixed-upstream patch security Hi, the user can decide whether to lock his laptop on lid-close under System Settings - Screen - Lock - On/Off which sets org.gnome.desktop.screensaver.lock-enabled (GSettings), buth g-p-m still uses /apps/gnome-screensaver/lock_enabled (GConf): This query always fails and the screen is not locked on lid-close. A good workaround is to manually re-create the old configuration key: gconftool-2 --type boolean --set /apps/gnome-screensaver/lock_enabled true This bug has been reported[0] and fixed upstream[1]. Please add this patch in order to make laptops with GNOME 3 more secure. Best regards Alexander Kurtz [0] https://bugzilla.gnome.org/show_bug.cgi?id=650464 [1] http://git.gnome.org/browse/gnome-power-manager/commit/?id=312066e7514586eb830950dae7c089f4a9f13135 signature.asc Description: This is a digitally signed message part
Bug#625606: upower: resets block-device tunings on startup
On Sun, 2011-10-30 at 19:09 +0100, Alexander Kurtz wrote: The end result is that the network card which actually should respond to every kind of WOL-event (pumbg) only responds to Magic-Packet (g) while all the other cards which should respond to nothing actually respond to Magic-Packets. Not really what I wanted... Ok, now things get really funny ;-) '/usr/sbin/pm-suspend' a.k.a. '/usr/lib/pm-utils/bin/pm-action' calls 'run_hooks sleep $ACTION $METHOD' right before suspending. This leads to '/usr/lib/pm-utils/sleep.d/00powersave suspend' being called, which in turn calls - you've guessed it - 'pm-powersave false'. As written before this screws up WOL. So, even if I somehow manage to set my custom WOL options without somebody else overwriting them immediately, they will be overwritten again just before suspending. Is that intended? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#618046: batmon.app: FTBFS: BatteryModel.m:308: undefined reference to `assert'
On Sun, 2011-03-13 at 17:58 +0100, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Since both #618046 and #618077 have been fixed for some time now and the affected packages build fine[1][2], I'd like to close these bugs in a few days. Any objections? Best regards Alexander Kurtz [1] https://buildd.debian.org/status/package.php?p=etoile [2] https://buildd.debian.org/status/package.php?p=batmon.app signature.asc Description: This is a digitally signed message part
Bug#510027: pavucontrol_0.9.7-1(sparc/experimental): FTBFS: undefined reference to `AO_store_full_emulation'
On Sun, 2008-12-28 at 20:15 +0100, Frank Lichtenheld wrote: your package failed to build from source. Since #510027 has been fixed for some time now and the affected package builds fine[1], I'd like to close this bug in a few days. Any objections? Best regards Alexander Kurtz [0] https://buildd.debian.org/status/package.php?p=pavucontrol signature.asc Description: This is a digitally signed message part
Bug#596351: ohai fails with: to_json: source sequence is illegal/malformed
Hi everybody,
AFAICT ohai works fine nowadays:
$ getent passwd 1000
alexander:x:1000:1000:Alexander' Kurtz£:/home/alexander:/bin/bash
$ ohai
{
[...]
platform: debian
}
$
Chris Butler suggested[1] that this commit to ruby-json might be a fix:
https://github.com/flori/json/commit/dd06e48aa414674f52e81f9cdc7836b6456c04f8
This commit seems to be included in the latest version of ruby-json:
$ grep --recursive --context=3 'def benchmark_generator_ascii'
ruby-json-1.5.3/
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb-
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb- alias
reset_benchmark_generator_pretty generic_reset_method
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb-
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb: def
benchmark_generator_ascii
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb-@result =
JSON.generate(@big, :ascii_only = true)
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb- end
ruby-json-1.5.3/benchmarks/generator2_benchmark.rb-
--
ruby-json-1.5.3/benchmarks/generator_benchmark.rb-
ruby-json-1.5.3/benchmarks/generator_benchmark.rb- alias
reset_benchmark_generator_pretty generic_reset_method
ruby-json-1.5.3/benchmarks/generator_benchmark.rb-
ruby-json-1.5.3/benchmarks/generator_benchmark.rb: def
benchmark_generator_ascii
ruby-json-1.5.3/benchmarks/generator_benchmark.rb-@result =
JSON.generate(@big, :ascii_only = true)
ruby-json-1.5.3/benchmarks/generator_benchmark.rb- end
ruby-json-1.5.3/benchmarks/generator_benchmark.rb-
$
Unless somebody tells me otherwise, I'm going to reassign this bug to
ruby-json and close it with the appropriate version in a few days.
Best regards
Alexander Kurtz
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596351#50
signature.asc
Description: This is a digitally signed message part
Bug#620649: depends on nonexisting zeitgeist-datahub
fixed 620649 0.8.1-1 thanks Hi, it seems the BTS can't handle a bug being closed in another package. [1] This bug therefore still prevents migration to testing. [2][3] Since zeitgeist-datahub is now available in unstable[4], I'm marking this as fixed in the latest version of zeitgeist. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620649#20 [2] http://release.debian.org/migration/testing.pl?package=zeitgeist [3] http://packages.qa.debian.org/z/zeitgeist.html [4] http://packages.debian.org/sid/zeitgeist-datahub signature.asc Description: This is a digitally signed message part
Bug#631187: Kernel panics when removing external hard drive
On Wed, 2011-07-13 at 22:03 +1000, Linh Nguyen wrote: Hello Alexander, How are you? I came across your post http://lists.debian.org/debian-kernel/2011/06/msg00580.html detailing similar issue as to what I am experiencing. Every time I unmount a portable HDD (normal USB sticks are fine), i get a kernel panic the the power/level is deprecated; use power/control instead error message. Despite my extensive googling, i've not been able to find a solution. I was wondering whether or not you have solved your issue. Cheers. :) Sincerely, L Sorry, I've got no solution either. Since this is kind of a low-priority bug for me, I'm fine with manually unmounting (using umount or some GUI) my external drive before removing it. My current plan is to wait for 3.0 and then maybe do a git bisect if it's not fixed by then. However, you should check out the Debian bug report[1], the Ubuntu bug report[2] and the upstream bug report[3], maybe you'll find something there. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631187 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793796 [3] https://bugzilla.kernel.org/show_bug.cgi?id=38842 signature.asc Description: This is a digitally signed message part
Bug#631187: Kernel panics when removing external hard drive
On Fri, 2011-07-08 at 04:30 +0100, Ben Hutchings wrote: Alexander, please test the new package version. I just tested 2.6.39-3 from sid and 3.0.0~rc6-1~experimental.1 from experimental. Unfortunately both reliably panic when safely removing my external hard drive. 2.6.38-5 (still) works fine. Seems like it's time for me to do a git bisect, or do you any other ideas? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#613592: /sbin/fdisk: Can't create at sector 63
On Tue, 2011-06-28 at 14:05 +0200, Olaf van der Spek wrote:
True, but deleting and recreating was advised in a number of how to's.
Yeah, fdisk is kind of limited, see below.
Isn't it kind of silly to have so many tools that try to do the same thing?
GNU parted has way more features than {c,s,}fdisk will probably ever
have; the most popular being perhaps support for a lot of different
partition layouts[1] including the future standard GPT. And it can
actually resize partitions...
It wasn't clear to me at all what DOS-compatibility meant, so I had no
idea that'd allow me to create a partition at sector 63.
Basically DOS-compatible means aligning partitions to cylinder
boundaries, since DOS requires that. And since the default is 63
sectors/track this means that the first partition normally starts at
sector 63, i.e. at the beginning of the second cylinder.
Hope this makes the situation more clear! Tell me if you're still having
problems with fdisk!
Best regards
Alexander Kurtz
[1] http://www.gnu.org/software/parted/manual/parted.html#mklabel
signature.asc
Description: This is a digitally signed message part
Bug#613592: /sbin/fdisk: Can't create at sector 63
On Wed, 2011-06-29 at 18:24 +0200, Olaf van der Spek wrote: So what's the advantage of c/sfdisk? Well, it's smaller, has fewer dependencies and is installed on almost every system. And since most administrators are familiar with it and it is more than sufficient for most of the common tasks, there is no reason not to keep it... Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#620649: depends on nonexisting zeitgeist-datahub
On Sun, 2011-04-03 at 12:42 +0200, Siegfried Gevatter wrote: zeitgeist-datahub has been moved to a separate source package (which is still in NEW). zeitgeist-datahub has been accepted in experimental meanwhile: http://packages.qa.debian.org/z/zeitgeist-datahub/news/20110410T130444Z.html If there are no serious issues, maybe you could consider uploading zeitgeist-datahub to unstable, so this bug can be closed. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#631187: Kernel panics when removing external hard drive
On Wed, 2011-06-22 at 03:40 +0100, Ben Hutchings wrote: Which version of GNOME is this? 2.30.2. Apart from the newer kernel, this is a pure Squeeze system. The panic message shows there was an earlier kernel warning; please can you provide that. Thanks to netconsole (a really great tool!) I was able to so. The attached kernel log starts right before I plug the drive in. Surprisingly the kernel didn't crash the first time, but after trying again, everything went as expected (see lines 17 and 35). Please note that I replaced the drive's serial number. Best regards Alexander Kurtz [ 1420.016231] usb 1-3: new high speed USB device number 6 using ehci_hcd [ 1420.150838] usb 1-3: New USB device found, idVendor=1058, idProduct=1010 [ 1420.150867] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1420.150891] usb 1-3: Product: External HDD [ 1420.150900] usb 1-3: Manufacturer: Western Digital [ 1420.150914] usb 1-3: SerialNumber: XX [ 1420.152513] scsi7 : usb-storage 1-3:1.0 [ 1421.154225] scsi 7:0:0:0: Direct-Access WD 2500BEV External 1.75 PQ: 0 ANSI: 4 [ 1421.158259] sd 7:0:0:0: [sdc] 488397168 512-byte logical blocks: (250 GB/232 GiB) [ 1421.159053] sd 7:0:0:0: [sdc] Write Protect is off [ 1421.159069] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 1421.159080] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 1421.161796] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 1421.179973] sdc: sdc1 [ 1421.182628] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 1421.182657] sd 7:0:0:0: [sdc] Attached SCSI disk [ 1454.865926] WARNING! power/level is deprecated; use power/control instead [ 1454.944178] usb 1-3: USB disconnect, device number 6 [ 1477.564219] usb 1-2: new high speed USB device number 7 using ehci_hcd [ 1477.698789] usb 1-2: New USB device found, idVendor=1058, idProduct=1010 [ 1477.698817] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1477.698841] usb 1-2: Product: External HDD [ 1477.698850] usb 1-2: Manufacturer: Western Digital [ 1477.698867] usb 1-2: SerialNumber: XX [ 1477.700552] scsi8 : usb-storage 1-2:1.0 [ 1478.702244] scsi 8:0:0:0: Direct-Access WD 2500BEV External 1.75 PQ: 0 ANSI: 4 [ 1478.705375] sd 8:0:0:0: [sdc] 488397168 512-byte logical blocks: (250 GB/232 GiB) [ 1478.705994] sd 8:0:0:0: [sdc] Write Protect is off [ 1478.706023] sd 8:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 1478.706035] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 1478.708338] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 1478.725489] sdc: sdc1 [ 1478.728353] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 1478.728383] sd 8:0:0:0: [sdc] Attached SCSI disk [ 1491.693027] BUG: unable to handle kernel NULL pointer dereference at 0048 [ 1491.693229] IP: [8118b2e3] elv_completed_request+0x38/0x47 [ 1491.693380] PGD 1b7f16067 [ 1491.693435] Buffer I/O error on device sdc1, logical block 61048968 [ 1491.693448] Buffer I/O error on device sdc1, logical block 61048968 [ 1491.693486] Buffer I/O error on device sdc1, logical block 61048992 [ 1491.693494] Buffer I/O error on device sdc1, logical block 61048992 [ 1491.693510] Buffer I/O error on device sdc1, logical block 61048998 [ 1491.693517] Buffer I/O error on device sdc1, logical block 61048998 [ 1491.693554] Buffer I/O error on device sdc1, logical block 61048999 [ 1491.693567] Buffer I/O error on device sdc1, logical block 0 [ 1491.693578] Buffer I/O error on device sdc1, logical block 0 [ 1491.693590] Buffer I/O error on device sdc1, logical block 256 [ 1491.694599] PUD 1b7f23067 PMD 0 [ 1491.694689] Oops: [#1] SMP [ 1491.694777] last sysfs file: /sys/devices/pci:00/:00:12.2/usb1/1-2/power/autosuspend [ 1491.694945] CPU 1 [ 1491.694991] Modules linked in: netconsole configfs parport_pc ppdev lp parport bridge stp bnep rfcomm bluetooth powernow_k8 mperf cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative binfmt_misc fuse snd_hda_codec_hdmi joydev snd_hda_codec_conexant radeon arc4 ecb ttm drm_kms_helper snd_hda_intel thinkpad_acpi rtl8192ce drm snd_hda_codec rtl8192c_common snd_hwdep i2c_algo_bit rtlwifi snd_pcm snd_seq snd_seq_device mac80211 snd_timer snd cfg80211 i2c_piix4 shpchp soundcore tpm_tis tpm psmouse tpm_bios snd_page_alloc wmi nvram k10temp rfkill pcspkr pci_hotplug i2c_core evdev serio_raw battery video ac edac_core power_supply edac_mce_amd button processor ext4 mbcache jbd2 crc16 sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod sd_mod usb_storage crc_t10dif uas ahci libahci ohci_hcd libata ehci_hcd r8169 thermal scsi_mod usbcore mii thermal_sys [last unloaded: configfs] [ 1491.696825] [ 1491.696825] Pid: 10, comm: ksoftirqd/1 Tainted: GW2.6.39-2-amd64 #1
Bug#624569: closed by Tzafrir Cohen tzaf...@debian.org (Bug#624569: fixed in asterisk 1:1.8.4-1)
Hi, asterisk still can't be built on sparc (still missing libsrtp0-dev) and now also FTBFS on mips, powerpc and s390, see here: https://buildd.debian.org/status/package.php?p=asterisk Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#561593: background image config/handling (plus password handling)
On Wed, 2011-05-04 at 13:28 +0200, deb...@x.ray.net wrote: sorry, spamassassin problem over here, it seems to have been broken on the occasion that support was dropped (mailserver is etch) - i found about your mail just now. Security support for etch was discontinued in February 2010... yes, the first part was about setting menucolors in case of a background image - just as the provided patch suggests to fix it. Unfortunately that patch isn't perfect, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608283#26 Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#624569: FTBFS because of missing build-dependencies
Package: src:asterisk Version: 1:1.8.3.3-1 Severity: serious Hi, asterisk currently FTBFS on the hurd, kfreebsd-amd64/-i386 and sparc because of missing build-dependencies[1]. The missing packages are libtonezone-dev (src:dahdi-tools) and libsrtp0-dev (src:srpt). Since it seems unlikely that these packages get fixed soon[2][3], you should consider building asterisk without these libraries or temporarily removing asterisk from the affected architectures via [4]. This is especially important since the latest asterisk fixes some security issues (DSA 2225[5]) but won't be able to migrate to testing any time soon in the current state. Please don't hesitate to reassign this bug to the buggy libraries if you think it's appropriate. Best regards Alexander Kurtz [1] https://buildd.debian.org/status/package.php?p=asterisk [2] https://buildd.debian.org/status/package.php?p=dahdi-tools [3] https://buildd.debian.org/status/package.php?p=srtp [4] https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific [5] http://www.debian.org/security/2011/dsa-2225 signature.asc Description: This is a digitally signed message part
Bug#599095: schroedinger: Generates a 500M build log
Hi, what are the chances of #599095 being fixed soon? This bug currently blocks VLC[1][2] from migrating to testing which would fix some important security issues[3][4] (DSA 2211-1 [5]). Best regards Alexander Kurtz [1] http://release.debian.org/migration/testing.pl?package=vlc [2] https://buildd.debian.org/status/package.php?p=vlc [3] http://security-tracker.debian.org/tracker/CVE-2010-3275 [4] http://security-tracker.debian.org/tracker/CVE-2010-3276 [5] http://lists.debian.org/debian-security-announce/2011/msg00080.html signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
Am Montag, den 04.04.2011, 10:54 +0200 schrieb Emilio Pozuelo Monfort: I already fixed this in svn. I'll upload it when pango migrates unless Julien thinks we should really fix this before that happens. Perfect, thank you! But won't this bug block pango from migrating? If so, don't hesitate to lower the severity! BTW: While searching for the relevant commit[1] I saw that you moved pango1.0 experimental branch to unstable[2], but I think you forgot to update the Vcs-* fields, see [3]. Best regards Alexander Kurtz [1] http://svn.debian.org/viewsvn/pkg-gnome?view=revrevision=27121 [2] http://svn.debian.org/viewsvn/pkg-gnome?view=revrevision=27092 [3] http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/pango1.0/debian/control?revision=27092view=markuppathrev=27092 signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
Am Montag, den 04.04.2011, 11:37 +0200 schrieb Emilio Pozuelo Monfort: Pretty sure I did in a later commit. Yes you did[1]. Sorry for the noise. Best regards Alexander Kurtz [1] http://svn.debian.org/viewsvn/pkg-gnome?view=revrevision=27112 signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
reopen 616577 forcemerge 616577 619771 thanks Am Montag, den 14.03.2011, 16:23 +0100 schrieb Alexander Kurtz: Am Sonntag, den 13.03.2011, 21:35 + schrieb Emilio Pozuelo Monfort: Yes, I know. See e.g. #609565 for a similar case. Downgrades are not supported, so in that case you get to fix it. Alright then. It seems like there *are* actually other causes for this bug: I agree with Michael Bienia[1] that the actual bug was probably in some old version which failed to do the transition properly. Together with Julien Cristau's comment[2] on the issue this sounds like a pretty good explanation. Meanwhile quite a few people[3][4] experienced this bug, so please apply my patch[5] now. Ubuntu has already applied it[6]. Best regards Alexander Kurtz [1] https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/703230/comments/9 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616577#27 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619771 [4] https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/703230 [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616577#20 [6] https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/703230/comments/8 signature.asc Description: This is a digitally signed message part
Bug#619858: vlc FTBFS because of incorrect build-dependency
Package: vlc Version: 1.1.8-1 Severity: serious Justification: FTBFS Hi, vlc 1.1.8-1 currently FTBFS on hppa, s390 and sparc because of a wrong build-dependency[1]. The log files[2][3][4] all contain this: checking for THEORA... yes checking for DIRAC... yes checking for SCHROEDINGER... no configure: error: Library schroedinger-1.0 = 1.0.10 needed for schroedinger was not found make[1]: *** [override_dh_auto_configure] Error 1 make[1]: Leaving directory `/build/buildd-vlc_1.1.8-1-hppa-UUvoDW/vlc-1.1.8' make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 However, vlc 1.1.8-1 currently only depends on libschroedinger-dev (=1.0.7). You should probably update the build-dependencies. Although bumping the bumping the build-dependencies would probably be the correct solution, it won't solve the problem completely, see [5]. Best regards Alexander Kurtz [1] https://buildd.debian.org/status/package.php?p=vlc [2] https://buildd.debian.org/fetch.cgi?pkg=vlcarch=hppaver=1.1.8-1stamp=1301109058file=logas=raw [3] https://buildd.debian.org/fetch.cgi?pkg=vlcarch=s390ver=1.1.8-1stamp=1301077844file=logas=raw [4] https://buildd.debian.org/fetch.cgi?pkg=vlcarch=sparcver=1.1.8-1stamp=1301013257file=logas=raw [5] https://buildd.debian.org/status/package.php?p=schroedinger signature.asc Description: This is a digitally signed message part
Bug#590961: Make the relationship of #580873, #580874 and #590961 more clear
affects 580873 brasero affects 590961 brasero block 580874 by 580873 block 580874 by 590961 thanks Hi, I recently got aware of the fact that there seems to be a lot of confusion on the net regarding optical disc burning with Brasero in Debian/Ubuntu because of #580873, #580874 and #590961. This has lead to a lot of bug reports[1-6] which are most likely duplicates of #580874 and even to Ubuntu disabling Brasero's plugin version check completely for lucid[7] and maverick[8]. IMHO this is not necessary and backporting the fix for #590961 would have been the better solution. Hopyfully this mail makes the situation more clear. If not, don't hesitate to ask! Best regards Alexander Kurtz [1] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/695269 [2] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/695275 [3] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/682329 [4] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/566784 [5] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/605603 [6] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/529696 [7] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/529696/comments/169 [8] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/529696/comments/170 signature.asc Description: This is a digitally signed message part
Bug#561593: background image config/handling (plus password handling)
Hi, if I understand you correctly, you are searching for a way to set custom menu colors, right? That would be #608283[1]. I'm working on that, but it will need some time. Or did you want something else? Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608283 signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
Am Dienstag, den 08.03.2011, 11:27 +0100 schrieb Julien Cristau: It seems like dpkg won't overwrite a directory with a symlink (bug?) so No, not bug. So my patch[1] should be the correct solution in this situation, right? Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616577#20 signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
Am Sonntag, den 13.03.2011, 19:16 + schrieb Emilio Pozuelo Monfort: No. Your system was messed up since you didn't have a symlink there (as you should). I'm tempted to close this bug. I don't know why *I* had a directory instead of a symbolic link, but I can think of at least one not very unlikely way: Imagine you install pango 1.28.3-4, then go back to an earlier version and re-upgrade some time later: You would be screwed. Since there is absolutely no downside in checking ones assumptions (i.e. /usr/share/doc/libpango1.0-0 being a symlink), I think you should re-consider applying the patch. However, it's your decision; feel free to close the bug if you want to. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
tags 616577 + patch thanks Hi, I have written and successfully tested the attached patch. If there are no objections, I suggest applying it to the next upload. Best regards Alexander Kurtz diff -Naur pango1.0-1.28.3.orig/debian/changelog pango1.0-1.28.3/debian/changelog --- pango1.0-1.28.3.orig/debian/changelog 2011-01-13 00:04:25.0 +0100 +++ pango1.0-1.28.3/debian/changelog 2011-03-06 14:52:04.818002938 +0100 @@ -1,3 +1,10 @@ +pango1.0 (1.28.3-4.1) experimental; urgency=low + * Non-maintainer upload + * preinst: Check if /usr/share/doc/libpango1.0-0 actually is a symlink before +attempting to remove it. Closes: #616577. + + -- Alexander Kurtz kurtz.a...@googlemail.com Sun, 06 Mar 2011 13:48:33 +0100 + pango1.0 (1.28.3-4) experimental; urgency=low * Switch to source format 3.0 (quilt). diff -Naur pango1.0-1.28.3.orig/debian/libpango1.0-0.preinst pango1.0-1.28.3/debian/libpango1.0-0.preinst --- pango1.0-1.28.3.orig/debian/libpango1.0-0.preinst 2011-01-11 02:26:22.0 +0100 +++ pango1.0-1.28.3/debian/libpango1.0-0.preinst 2011-03-06 14:54:29.290308829 +0100 @@ -2,7 +2,11 @@ set -e if [ $1 = upgrade ] dpkg --compare-versions $2 lt-nl 1.28.3-4; then -rm -f /usr/share/doc/libpango1.0-0 +# Check if /usr/share/doc/libpango1.0-0 actually is a symlink before +# attempting to remove it. Closes: #616577. +if [ -L /usr/share/doc/libpango1.0-0 ]; then +rm -f /usr/share/doc/libpango1.0-0 +fi fi #DEBHELPER# signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
Package: libpango1.0-0 Version: 1.28.3-4 Severity: serious Justification: Fails to install Hi, upgrading libpango1.0-0 from 1.28.3-1+squeeze2 (Squeeze) to 1.28.3-4 (experimental) fails: $ sudo apt-get install libpango1.0-0=1.28.3-4 Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libxcb-render-util0 libpango1.0-common Use 'apt-get autoremove' to remove them. Suggested packages: ttf-japanese-gothic ttf-japanese-mincho ttf-thryomanes ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp ttf-arphic-gkai00mp ttf-arphic-bkai00mp The following packages will be upgraded: libpango1.0-0 1 upgraded, 0 newly installed, 0 to remove and 847 not upgraded. 34 not fully installed or removed. Need to get 0 B/409 kB of archives. After this operation, 131 kB of additional disk space will be used. (Reading database ... 207505 files and directories currently installed.) Preparing to replace libpango1.0-0 1.28.3-1+squeeze2 (using .../libpango1.0-0_1.28.3-4_i386.deb) ... rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory dpkg: error processing /var/cache/apt/archives/libpango1.0-0_1.28.3-4_i386.deb (--unpack): subprocess new pre-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: /var/cache/apt/archives/libpango1.0-0_1.28.3-4_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) $ Looking at the pre-installation script reveals this: $ cat libpango1.0-0_1.28.3-4_amd64/DEBIAN/preinst #!/bin/sh set -e if [ $1 = upgrade ] dpkg --compare-versions $2 lt-nl 1.28.3-4; then rm -f /usr/share/doc/libpango1.0-0 fi $ It seems that rm is missing the -r option. After manually removing the directory everything works fine: $ sudo rmdir /usr/share/doc/libpango1.0-0 $ Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
I investigated this further after realizing that on my other machine `/usr/share/doc/libpango1.0-0' is a symlink to `libpango1.0-common'. I first tried to re-install the old versions: $ sudo dpkg -i libpango1.0-0_1.28.3-1+squeeze2_i386.deb libpango1.0-common_1.28.3-1+squeeze2_all.deb [...] $ file /usr/share/doc/libpango* /usr/share/doc/libpango-perl: directory /usr/share/doc/libpango1.0-0: directory /usr/share/doc/libpango1.0-common: directory /usr/share/doc/libpangomm-1.4-1: directory $ I then removed the directory and re-installed: signature.asc Description: This is a digitally signed message part
Bug#616577: Upgrading libpango1.0-0 fails: rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory
[ My last mail got cropped for some reason, here it is again ] I investigated this further after realizing that on my other machine `/usr/share/doc/libpango1.0-0' is a symlink to `libpango1.0-common'. I first tried to re-install the old versions: $ sudo dpkg -i libpango1.0-0_1.28.3-1+squeeze2_i386.deb libpango1.0-common_1.28.3-1+squeeze2_all.deb [...] $ file /usr/share/doc/libpango* /usr/share/doc/libpango-perl: directory /usr/share/doc/libpango1.0-0: directory /usr/share/doc/libpango1.0-common: directory /usr/share/doc/libpangomm-1.4-1: directory $ I then removed the directory and re-installed: $ sudo rmdir -v /usr/share/doc/libpango1.0-0 rmdir: removing directory, `/usr/share/doc/libpango1.0-0' $ sudo dpkg -i libpango1.0-0_1.28.3-1+squeeze2_i386.deb libpango1.0-common_1.28.3-1+squeeze2_all.deb [...] $ file /usr/share/doc/libpango* /usr/share/doc/libpango-perl: directory /usr/share/doc/libpango1.0-0: symbolic link to `libpango1.0-common' /usr/share/doc/libpango1.0-common: directory /usr/share/doc/libpangomm-1.4-1: directory $ I then removed the symlink, created a directory and re-installed: $ sudo rm -v /usr/share/doc/libpango1.0-0 removed `/usr/share/doc/libpango1.0-0' $ sudo mkdir -v /usr/share/doc/libpango1.0-0 mkdir: created directory `/usr/share/doc/libpango1.0-0' $ sudo dpkg -i libpango1.0-0_1.28.3-1+squeeze2_i386.deb libpango1.0-common_1.28.3-1+squeeze2_all.deb [...] $ sudo file /usr/share/doc/libpango* /usr/share/doc/libpango-perl: directory /usr/share/doc/libpango1.0-0: directory /usr/share/doc/libpango1.0-common: directory /usr/share/doc/libpangomm-1.4-1: directory $ It seems like dpkg won't overwrite a directory with a symlink (bug?) so if /usr/share/doc/libpango1.0-0 has ever been a directory on your machine, installing the latest libpango will fail. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#536376: tagging 536376
Hi, Am Samstag, den 12.02.2011, 21:00 +0100 schrieb Albin Tonnerre: tags 536376 + pending thanks Any news on this? Some way I can help? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#614785: Found too in oldstable/lenny?
Hi everybody, Am Mittwoch, den 23.02.2011, 16:13 +0100 schrieb Michael Biebl: A fixed package has been uploaded to unstable and stable-security (squeeze). First the good news: I can confirm that upgrading *all* avahi packages to 0.6.28-4 fixes the problem (only upgrading avahi-daemon does not!). Am Donnerstag, den 24.02.2011, 13:27 +0100 schrieb Salvatore Bonaccorso: I can reproduce this too on lenny, can someone confirm that? Up to date lenny system with avahi-daemon 0.6.23-3lenny2. Now the bad news: The Debian security tracker[1] says: [lenny] - avahi not-affected (Vulnerable code not present, introduced in 0.6.25) That's wrong: Looking at the source code reveals this: $ cat avahi-0.6.23/debian/patches/15_CVE-2010-2244.patch --- a/avahi-core/socket.c +++ avahi-0.6.23/avahi-core/socket.c @@ -652,6 +652,10 @@ AvahiDnsPacket *avahi_recv_dns_packet_ipv4( goto fail; } +/* corrupt packets have zero size */ +if (!ms) +goto fail; + p = avahi_dns_packet_new(ms + AVAHI_DNS_PACKET_EXTRA_SIZE); io.iov_base = AVAHI_DNS_PACKET_DATA(p); @@ -805,6 +809,10 @@ AvahiDnsPacket *avahi_recv_dns_packet_ipv6( goto fail; } +/* corrupt packets have zero size */ +if (!ms) +goto fail; + p = avahi_dns_packet_new(ms + AVAHI_DNS_PACKET_EXTRA_SIZE); io.iov_base = AVAHI_DNS_PACKET_DATA(p); $ So, the code which introduced this vulnerability (CVE-2011-1002[1]) was actually added[2] when fixing another vulnerability (CVE-2010-2244[3]). As a consequence, lenny IS indeed vulnerable and needs to be fixed too. Best regards and thank you very much for your work! Alexander Kurtz [1] http://security-tracker.debian.org/tracker/CVE-2011-1002 [2] http://packages.qa.debian.org/a/avahi/news/20100805T140231Z.html [3] http://security-tracker.debian.org/tracker/CVE-2010-2244 signature.asc Description: This is a digitally signed message part
Bug#614785: Found too in oldstable/lenny?
Am Donnerstag, den 24.02.2011, 15:57 +0100 schrieb Michael Biebl: But you are right, the security tracker should be updated http://svn.debian.org/wsvn/secure-testing/?rev=16247 Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#614785: avahi-daemon uses 100% of cpu when scanned with nmap (DoS possible?)
Package: avahi-daemon Version: 0.6.27-2 Tags: security Severity: critical Justification: Introduces possible denial-of-service scenario. Hi, when I scan my server from another machine on the network using nmap, I get this: # nmap -sU -p5353 192.168.2.2 Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-23 13:15 CET Interesting ports on 192.168.2.2: PORT STATE SERVICE 5353/udp open|filtered zeroconf MAC Address: XX:XX:XX:XX:XX:XX (Netgear) Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds # As soon as the scan starts, avahi-daemon on the server starts running amok, top shows this: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5535 avahi 20 0 33884 1600 1280 R 100 0.0 2:28.47 avahi-daemon Restarting avahi-daemon is not possible: # /etc/init.d/avahi-daemon restart Restarting Avahi mDNS/DNS-SD Daemon: avahi-daemonFailed to kill daemon: Timer expired . # Simply terminating the process doesn't work either: # ps -Af | grep avahi-daemon avahi 5535 1 87 13:14 ?00:04:43 avahi-daemon: running [server.local] avahi 5536 5535 0 13:14 ?00:00:00 avahi-daemon: chroot helper root 5610 5581 0 13:20 pts/200:00:00 grep avahi-daemon # kill 5535 # ps -Af | grep avahi-daemon avahi 5535 1 88 13:14 ?00:05:02 avahi-daemon: running [server.local] avahi 5536 5535 0 13:14 ?00:00:00 avahi-daemon: chroot helper root 5614 5581 0 13:20 pts/200:00:00 grep avahi-daemon # Forcibly killing the process works: # kill -9 5535 # ps -Af | grep avahi-daemon root 5629 5581 0 13:23 pts/200:00:00 grep avahi-daemon # I don't know what kind of data nmap sends when scanning for open UDP ports, but it definitely shouldn't cause avahi-daemon to run amok. Please note that I have not changed the Avahi configuration in any way, so you should be able to reproduce this easily. Please tell me if you need any more information! Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#614785: [Pkg-utopia-maintainers] Bug#614785: avahi-daemon uses 100% of cpu when scanned with nmap (DoS possible?)
Am Mittwoch, den 23.02.2011, 13:58 +0100 schrieb Michael Biebl: I was able to reproduce this problem on a squeeze system, but not on unstable. Can you confirm that? Negative, I tried upgrading avahi-daemon and libavahi-* to the sid versions (0.6.28-3) but the problem is still there. However, I haven't tried a complete upgrade to sid, so the problem may very well be in some third-party package which is fixed in sid. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#536376: [Pkg-e-devel] Bug#536376: evas: Not suitable for testing yet
Hi, Am Sonntag, den 08.08.2010, 23:31 +0200 schrieb Albin Tonnerre: Given that Testing just got frozen, I guess it'll have to wait. By the time Squeeze releases, things should have gotten closer to a release, and I'll reconsider letting it go into testing. Well, Squeeze will release in a few days[1] and the Enlightement developers just released Evas 1.0.0[2]. It would really be great if you could upload the new version and close this bug! Best regards Alexander Kurtz [1] http://lists.debian.org/debian-devel-announce/2011/01/msg3.html [2] http://www.enlightenment.org/?p=news/showl=ennews_id=28 signature.asc Description: This is a digitally signed message part
Bug#605705: FYI: Possible duplicates of #605705
Am Dienstag, den 14.12.2010, 19:19 + schrieb Alexander Kurtz: I just noticed that the following bugs look very similar to this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495282 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495616 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500134 I merged those with #608283[1]. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550984 That's a bug in desktop-base which was fixed in version 6.0.0 [2]. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561593 I merged that one with this bug report (#605705[3]) Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608283 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550984#31 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605705 signature.asc Description: This is a digitally signed message part
Bug#608519: grub-pc: 05_debian_theme assumes background image was copied from an installed desktop-base
severity 608519 important tag 608519 confirmed wontfix thanks Hi, Am Freitag, den 31.12.2010, 19:39 + schrieb Brian Potkin: I have a machine running unstable. The background image is moreblue-orbit-grub.png which is in /boot/grub. The image was copied from desktop-base but the package itself has never been installed on the system and, due to space restrictions, never will be. The recent upgrade has deleted moreblue-orbit-grub.png and made it impossible for it to be used when in /boot/grub. Basically, you can have any image in that location provided it isn't moreblue-orbit-grub or debian-blueish-wallpaper-640x48! Unfortunately I can't think of any way to fix this. 05_debian_theme is already comparing filenames AND checksums to make sure it doesn't delete user-generated files. I was also thinking about comparing the timestamps so that problems like yours could be avoided, however if you take a look at the old postinst code... # /boot/grub/ has more chances of being accessible by GRUB if test -e /boot/grub/grub.cfg ; then for i in /usr/share/grub/unicode.pf2 /usr/share/images/desktop-base/moreblue-orbit-grub.png ; do if test -e $i ; then cp $i /boot/grub/ fi done fi ... you'll see that `cp' was used without the `-a' switch, so timestamps were not preserved. Therefore I don't think there is any way to determine whether that file was put there by you or GRUB's postinst. That was the bad news. However, there is also good news: a) 05_debian_theme compares both filename and checksum. If you rename the file to something like `my_custom_background.png' everything should work just fine. b) The code which cleans up old background images shouldn't be necessary any more if you had at least the squeeze version installed. I'm therefore planning to remove that code at some point after squeeze's release. The patch is already written, I'm just waiting for the mail from debian-annou...@d.o ;-) I hope this helps! Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#607427: libopensc: protect for possible buffer overflows from rogue cards.
Package: libopensc2 Version: 0.11.4-5+lenny1 Tags: security Severity: critical Hi, a buffer overflow vulnerability was detected in libopensc. For details please see this press article (German: [1], English: [2]) and the detailed report[3] including a proof-of-concept by MWR InfoSecurity[4]. The OpenSC developers have released a patch which should fix this vulnerability[5]. If Debian isn't affected by this vulnerability or if it has already been fixed, please don't hesitate to downgrade or close this bug. Best regards Alexander Kurtz [1] http://www.heise.de/security/meldung/Wenn-die-Smartcard-den-Rechner-rootet-1154599.html [2] http://www.h-online.com/open/news/item/When-a-smart-card-can-root-your-computer-1154829.html [3] http://labs.mwrinfosecurity.com/files/Advisories/mwri_opensc-get-serial-buffer-overflow_2010-12-13.pdf [4] http://www.mwrinfosecurity.com/index.php [5] https://www.opensc-project.org/opensc/changeset/4913 signature.asc Description: This is a digitally signed message part
Bug#604472: firmware-b43-installer but after reboot I got a black screen!
Am Dienstag, den 23.11.2010, 12:08 +0100 schrieb k k: Hi, Alexander Kurtz I Just installed proprietary STA driver it works but not as good as the b43, it disconnects me. I'll reinstall my system and try out the latest kernel. Thank u! You don't have to reinstall, you can just add deb http://ftp.debian.org/debian/ experimental main to your /etc/apt/sources.list and then execute this: apt-get update apt-get -t experimental install linux-image-2.6.36-trunk-686 If your system is currently unable to boot, you can try adding nolapic and/or acpi=off to the kernel parameters when booting. This will deactivate your wifi. This is a valid workaround, but no longtime solution since this breaks (amongst others) SMP. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#604472: firmware-b43-installer but after reboot I got a black screen!
Am Donnerstag, den 25.11.2010, 16:59 +0100 schrieb k k: Hi Alexander, Thank u it worked, the expermimental kernel has fixed it! So will this bug be fixed in the current kernel perhaps patch? Thank u! Hopefully yes. I'll reassign this bug to linux-2.6. Let's see what the kernel maintainers say. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#604472: b43/ssb driver causes some laptops to freeze during boot
reassign 604472 linux-2.6 retitle 604472 b43/ssb driver causes some laptops to freeze during boot severity 604472 serious tags 604472 patch upstream fixed-upstream forwarded 604472 https://bugzilla.kernel.org/show_bug.cgi?id=14716 thanks Dear kernel maintainers, There is a known bug[1] in the linux kernel which causes some laptops (for example the HP Compaq 615) to freeze during boot (screen turns black, machine doesn't react on anything). The problem has been located in the b43/ssb driver and has been fixed[2] some time ago. As a workaround, one can use the proprietary wifi driver[3] (I'm doing so on my HP Compaq 615) or start the kernel with nolapic and/or acpi=off (disables wifi completely, but also SMP). The people currently seeing this bug include myself and k k kade...@gmail.com, who has recently filed this bug report against firmware-b43-installer and who was able to confirm[4] that the latest linux kernel from experimental fixes the problem. It would be great if the upstream patch could be backported and included in the squeeze kernel! If you'd like, I can test the patched version first. Many thanks for your work and with best regards Alexander Kurtz [1] https://bugzilla.kernel.org/show_bug.cgi?id=14716 [2] http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commit;h=9d1ac34ec3a67713308ae0883c3359c557f14d17 [3] http://packages.debian.org/squeeze/broadcom-sta-source [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604472#20 signature.asc Description: This is a digitally signed message part
Bug#604472: firmware-b43-installer but after reboot I got a black screen!
Hi, This might be a known kernel bug[1] which got fixed recently. The problem is somewhere in the b43/ssb driver, which won't get activated until you install the necessary firmware files. Could you try the latest linux kernel from experimental? I'm having this problem (black screen, machine freezes during boot) on one of my notebooks (HP Compaq 615). I'm using the proprietary driver[2] as a workaround for the time being. That works w/o problems. Best regards Alexander Kurtz [1] https://bugzilla.kernel.org/show_bug.cgi?id=14716 (currently broken) [2] http://packages.debian.org/squeeze/broadcom-sta-source signature.asc Description: This is a digitally signed message part
Bug#582342: Let's try to figure out bug #582342 finally
Hi, your Debian bug #582342[2] has been on my todo list for quite some time now - let's try to finally figure this out! I do have a similar setup, with / on a luks-encrypted raid6 and /boot on raid1, the only difference seems to be that I'm still using MBR while you've already switched to GPT. Since my setup works fine I'm confident that we will be able to solve your problem together! First let's make sure I get the facts right: * You've filed bug #582177[1] against initramfs-tools and #582342[2] against grub-pc * For both bugs you are apparently the only one who experiences them * the main symptom of these bugs is that your system doesn't boot anymore Everything correct so far? Then I have some questions: * Does your system still have problems booting? * If so, what problems *exactly* do you have? I've been reading both bug reports but have been unable to determine in what stage your system fails to boot. So * do you get to the GRUB screen * do the kernel and the initramfs get loaded by GRUB * do the kernel and the initramfs boot correctly I need the exact error messages to help you. A screenshot might also be a good idea. * I'd like to merge #582177[1] and #582342[2] so that we can focus on one bug report instead of spreading the information across multiple bugs. Overall this seems to be just one problem and we can always unmerge them later if necessary. Any objections? * You mentioned that your problems have disappeared and then reappeared after some hardware rearrangements: * Do you remember what you did exactly? * Can you make the problem disappear/reappear again? * Are you sure that it's not some HW/BIOS issue? * What method/steps do you currently use to boot your system? * Does it help if you run dpkg-reconfigure grub-pc when your system is up and reinstall grub to every harddrive to want to boot off? * Does it help if you run update-initramfs -u when your system is up to make sure you have a clean initramfs? * Is your squeeze system up-to-date? There have been quite some bugfixes recently which might affect your system, for example mdadm bug #583917[3] and friends. So, that's all I can think of right now - I'm looking forward to reading your detailed answers! Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582177 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582342 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583917 signature.asc Description: This is a digitally signed message part
Bug#599306: manpages-de 0.6-1 should conflict/break manpages-de-dev = 0.5-5 and vice versa
Package: manpages-de
Version: 0.6-1
Severity: serious
Hi,
the unattended upgrade failed today with this error message:
2010-10-06 12:51:13,135 INFO Initial blacklisted packages:
2010-10-06 12:51:13,136 INFO Starting unattended upgrades script
2010-10-06 12:51:13,136 INFO Allowed origins are: [('Debian', 'stable'),
('Debian', 'squeeze-security'), ('Debian', 'testing'),
('volatile.debian.org', 'stable')]
2010-10-06 12:51:26,202 INFO Packages that are upgraded: libasound2
libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 manpages-de manpages-de-dev
2010-10-06 12:51:26,202 INFO Writing dpkg log to
'/var/log/unattended-upgrades/unattended-upgrades-dpkg_2010-10-06_12:51:26.202429.log'
2010-10-06 12:51:37,769 ERROR Installing the upgrades failed!
2010-10-06 12:51:37,770 ERROR error message: 'E:Sub-process /usr/bin/dpkg
returned an error code (1)'
2010-10-06 12:51:37,770 ERROR dpkg returned a error! See
'/var/log/unattended-upgrades/unattended-upgrades-dpkg_2010-10-06_12:51:26.202429.log'
for details
The detailed log file is attached. After running apt-get dist-upgrade
manually again, everything worked perfectly and manpages-de 0.6-1 was
installed without a problem, because there were no conflicting files
anymore now that manpages-de-dev had been updated.
I'm filing this as serious because this could break upgrades from lenny
to squeeze. Don't hesitate to downgrade/close if you think it's
appropriate!
Best regards
Alexander Kurtz
(Reading database ... 186529 files and directories currently installed.)
Preparing to replace libasound2 1.0.23-1 (using .../libasound2_1.0.23-2_amd64.deb) ...
Unpacking replacement libasound2 ...
Preparing to replace libdrm2 2.4.18-6 (using .../libdrm2_2.4.21-1~squeeze3_amd64.deb) ...
Unpacking replacement libdrm2 ...
Preparing to replace libdrm-intel1 2.4.18-6 (using .../libdrm-intel1_2.4.21-1~squeeze3_amd64.deb) ...
Unpacking replacement libdrm-intel1 ...
Preparing to replace libdrm-nouveau1 2.4.18-6 (using .../libdrm-nouveau1_2.4.21-1~squeeze3_amd64.deb) ...
Unpacking replacement libdrm-nouveau1 ...
Preparing to replace libdrm-radeon1 2.4.18-6 (using .../libdrm-radeon1_2.4.21-1~squeeze3_amd64.deb) ...
Unpacking replacement libdrm-radeon1 ...
Preparing to replace manpages-de 0.5-5 (using .../manpages-de_0.6-1_all.deb) ...
Unpacking replacement manpages-de ...
dpkg: error processing /var/cache/apt/archives/manpages-de_0.6-1_all.deb (--unpack):
trying to overwrite '/usr/share/man/de/man2/intro.2.gz', which is also in package manpages-de-dev 0.5-5
configured to not write apport reports
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Preparing to replace manpages-de-dev 0.5-5 (using .../manpages-de-dev_0.6-1_all.deb) ...
Unpacking replacement manpages-de-dev ...
Processing triggers for man-db ...
Errors were encountered while processing:
/var/cache/apt/archives/manpages-de_0.6-1_all.deb
signature.asc
Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
So after all this was just mdadm bug #583917 combined with the fact that you used to wrong name (compared to /etc/cryptsetup) when unlocking the crypto device manually. This of course caused the cryptsetup initramfs hook to break when recreating the initramfs. As a consequence, your cryptroot didn't get unlocked during early boot stage. Correct? Best regards Alexander Kurtz PS: You should revert /etc/cryptab to the state it had before all the debugging (i.e. with UUID=). You should also revert the change you made to the cryptsetup initramfs hook, for example like this: apt-get --reinstall install cryptsetup signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
reassign 594472 mdadm forcemerge 583917 594472 thanks Hi Toni, Everybody else's problems were definitely caused[1][2] by mdadm bug #583917[3]. Could you try upgrading to mdadm 3.1.4 (has reached squeeze already), regenerate your initramfs and report whether this solves your booting problems? If your system doesn't currently boot at all, please see my former mail[4] for instructions. When doing so, please make sure that you use the right names (compared to /etc/crypttab) when unlocking your crypto devices. Not doing so was why Andreas could still not boot after upgrading mdadm[5]. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#119 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#199 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583917 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#164 [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#204 signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Now we are getting somewhere! Here's what I suspect to be the problem: Am Montag, den 20.09.2010, 09:59 +0200 schrieb Andreas von Heydwolff: * What exactly do you have to do to boot your system manually after being thrown to a rescue shell (precise commands)? # cryptsetup luksOpen /dev/md1 vg-md1dm0 That is wrong. According to your /etc/crypttab[1] the cleartext device for /dev/md1 is md1_crypt not vg-md1md0. The line should therefore look like this: cryptsetup luksOpen /dev/md1 md1_crypt If you use the wrong command this is what happens: * The LVM you set up manually (which contains your root fs) will use /dev/mapper/vg-md1dm0 as its physical volume. * When the initramfs is regenerated, the cryptsetup hooks searches for vg-md1dm0 in /etc/crypttab as this contains the PV for the LV on which the root fs of the currently running system is. Since there is of course no such entry you get those error messages and your crypto devices don't get unlocked before the root fs is mounted. * Since cryptsetup therefore thinks that /dev/md1 is just a normal encrypted volume, it will unlock it together with /dev/md2 (your /home) during normal boot. That's why why you have to enter /dev/md1's passphrase again and why you also have /dev/mapper/md1_crypt which (of course) has the same UUID as /dev/mapper/vg-md1md0. That's what I think (manual creation). And without specifying the vg I receive the error message that no volume groups are found That's because you didn't scan the devices. Use vgscan vgchange -ay Note that you don't need to enter the LVM shell for that. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#169 signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Hi Andreas, let's try to keep this short, this bug report is already long enough: Am Samstag, den 18.09.2010, 01:38 +0200 schrieb Andreas von Heydwolff: ii cryptsetup2:1.1.3-3 ii lvm2 2.02.66-3 ii mdadm 3.1.4-1+8efb9d1 Good. # update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64 ... and nothing else as output. Even better. the initramfs came up but I got ALERT! /dev/mapper/vg--md1dm0-slash does not exist and ls -l /dev/dm* was empty, ls -l /dev/mapper showed only /dev/mapper/control Not so good. Ok, let me summarize: * You did have[1] the problem that was caused by mdadm bug #583917[2]. However, after upgrading to mdadm 3.1.4 that is solved. * You did have[3] some issue with cryptsetups initramfs hook. However, for some reason that is gone now. * You do still have the problem that for some reason your root file system is not correctly mounted during initramfs stage. Everything correct so far? If so we can focus on tackling the last point! Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#44 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583917 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#124 signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Am Samstag, den 18.09.2010, 23:04 +0200 schrieb Andreas von Heydwolff: It is gone because I replaced in line 185 of /usr/share/initramfs-tools/hooks/cryptroot echo cryptsetup: WARNING: invalid line in /etc/crypttab - $opt 2 with echo cryptsetup: WARNING: invalid line in /etc/crypttab - $opt (target=$target, extraopts=$extraopts, @=$@) as you suggested. When I revert to the old line I again get this situation: # update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64 cryptsetup: WARNING: invalid line in /etc/crypttab - cryptsetup: WARNING: invalid line in /etc/crypttab - Ehm... I suggested to change that line for *diagnosing only*. The fix was that apparently you forgot the 2 part at the end, therefore the output is not redirected to stderr. Please re-read my old mail. * You do still have the problem that for some reason your root file system is not correctly mounted during initramfs stage. Yes Questions: * What exactly fails at booting during the initramfs stage? Do the raid devices get assembled correctly? Do the crypto devices get unlocked? What about LVM? In short: What works, what doesn't? * What exactly do you have to do to boot your system manually after being thrown to a rescue shell (precise commands)? * The double-UUID-problem: What is /dev/mapper/vg-md1dm0? Do somehow manually create it when booting the system by hand? What happens if you use *only* vgscan; vgchange -ay to activate all logical volumes? Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#159 signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Hi, I think a little more information would be helpful. IMHO your problem can be divided into three parts. Let's discuss them separately: 1. Just for the record: You do have mdadm 3.1.4-1+8efb9d1 installed (it should migrate to squeeze today[1])? Am Freitag, den 17.09.2010, 01:38 +0200 schrieb Andreas von Heydwolff: Hm. All three variants yielded the same result: # update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64 cryptsetup: WARNING: invalid line in /etc/crypttab - cryptsetup: WARNING: invalid line in /etc/crypttab - 2. Ok I really want to know why this error message appears. This is the relevant code: $ sed -n '179,187p' /usr/share/initramfs-tools/hooks/cryptroot opt=$( grep ^$target\b /etc/crypttab | head -1 | sed 's/[[:space:]]\+/ /g' ) source=$( echo $opt | cut -d -f2 ) key=$( echo $opt | cut -d -f3 ) rootopts=$( echo $opt | cut -d -f4- ) if [ -z $opt ] || [ -z $source ] || [ -z $key ] || [ -z $rootopts ]; then echo cryptsetup: WARNING: invalid line in /etc/crypttab - $opt 2 return 1 fi Looking at your error message, I guess $opt is empty (which would also make the other variables empty). That can only happen if the grep which is supposed to fill $opt returns nothing. Can you * append the complete output of + ls -l /dev/mapper + mount + cat /etc/fstab + cat /etc/crypttab * temporarily change line 185 of /usr/share/initramfs-tools/hooks/cryptroot like this for more information: echo cryptsetup: WARNING: invalid line in /etc/crypttab - $opt (target=$target, extraopts=$extraopts, @=$@) 2 * run update-initramfs -u with the modified hook and send me the output? Then I followed this previously mentioned error message: # update-grub Generating grub.cfg ... Found background image: moreblue-orbit-grub.png Found linux image: /boot/vmlinuz-2.6.32-5-amd64 Found initrd image: /boot/initrd.img-2.6.32-5-amd64 Found duplicate PV c1Evvwvx3ZfBwDWRyhhI0nY864wtPZ3o: using /dev/dm-11 not /dev/dm-0 Found Debian GNU/Linux (squeeze/sid) on /dev/sda2 [my rescue system] done # blkid | grep Evv /dev/mapper/md1_crypt: UUID=c1Evvw-vx3Z-fBwD-WRyh-hI0n-Y864-wtPZ3o TYPE=LVM2_member /dev/mapper/vg-md1dm0: UUID=c1Evvw-vx3Z-fBwD-WRyh-hI0n-Y864-wtPZ3o TYPE=LVM2_member # l /dev/mapper/ insgesamt 0 crw--- 1 root root 10, 59 14. Sep 20:59 control lrwxrwxrwx 1 root root 8 14. Sep 20:59 md1_crypt - ../dm-11 lrwxrwxrwx 1 root root 8 14. Sep 20:59 md2_crypt - ../dm-12 lrwxrwxrwx 1 root root 7 14. Sep 20:53 vg-md1dm0 - ../dm-0 Perhaps this is the source of confusion? Identical UUIDs for the encrypted RAID1 pv and the vg that emerges when the pv has been unlocked with cryptsetup? This is the configuration on the running system on which md1_crypt and the vg had been unlocked and started manually. Do I have to remove one symlink, either to dm-0 or to dm-11 in order to create a functioning initramdisk? I had to unlock md1_crypt twice, once from within busybox and once after exiting lvm and busybox. 3. I don't know much about LVM. I tend to think that the identical UUIDs might actually be correct - but I may be wrong here. It would be very helpful if you could give a short overview over your block devices and how the work together (a drawing would be great). Please include everything from the physical disks, physical and logical partitions, RAID, LVM, CRYPTO up to the FS level. Please also include the UUIDs in this. Finally the complete output of `blkid' would be great. Please excuse me if I'm asking for information you have already provided - the bug report is just quite long by now and I might have missed it. If this is the case, just tell me. Best regards Alexander Kurtz [1] http://release.debian.org/migration/testing.pl?package=mdadm signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade: proposal for solution
Hi everybody, I spent the last hour re-reading the entire bug report, testing the new mdadm version and testing a way to restore the system using a live CD. Here's what I found: * I am really sure that this is not a GRUB bug. You all get to the initramfs. That's where problems start. GRUB is innocent here. * I am quite sure now that you all have been bitten by mdadm bug #583917[1] and friends. The symptoms are quite unique (loads of /sys/devices/virtual/block/md0 messages and high/endless disk activity). Look here[2] for a good explanation of what happens. This bug was fixed in mdadm 3.1.4-1+8efb9d1 which just migrated to testing/squeeze[3]. I verified that with this version my system boots fine, even without the workaround[4]. So the important part is how to get your systems back online. Here's what you can do, if your system is still not booting (you might want to print this out): 1. Get the current Debian Live CD[5] 32 bit: http://cdimage.debian.org/cdimage/squeeze_live_alpha2/i386/iso-hybrid/debian-live-60alpha2-i386-standard.iso 64 bit: http://cdimage.debian.org/cdimage/squeeze_live_alpha2/amd64/iso-hybrid/debian-live-60alpha2-amd64-standard.iso burn it to a CD/DVD or write it to a USB drive using dd (if your machine can boot from USB) and boot the live system (note that you'll get a US keyboard layout first, this[6] might be helpful) 2. Get root and install the required tools sudo su apt-get update apt-get install console-data cryptsetup less lvm2 mdadm 3. Configure the keyboard layout (if necessary) dpkg-reconfigure console-data 4. Start your RAID arrays if not yet done. See man mdadm. 5. Start your LVM VGs (if any). See man lvm. 6. Load the dm_crypt kernel module using modprobe dm_crypt and open your crypto devices (see man cryptsetup), e.g. cryptsetup luksOpen /dev/mapper/lv0 root By now all your systems block devices should be available and useable. 7. Mount your system to /mnt, e.g. mount /dev/mapper/root /mnt mount /dev/md0 /mnt/boot ... 8. Bind-mount the virtual file systems: mount -o bind /dev /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc/mnt/proc mount -o bind /sys /mnt/sys 9. Chroot into your main system chroot /mnt 10. Update the required tools apt-get update apt-get install cryptsetup lvm2 mdadm Ensure that you have mdadm v3.1.4: mdadm --version 11. Check your mdadm configuration /usr/share/mdadm/mkconf If the output seems sane, write it to disk /usr/share/mdadm/mkconf /etc/mdadm/mdadm.conf 12. Carefully check whether the contents of /etc/fstab and /etc/crypttab are correct and up to date. 13. On my system mdadm didn't create the necessary links under /dev/md/. Check if they are *all* there ls -l /dev/md/ If some links are missing, create them manually, e.g. ln -s /dev/md0 /dev/md/0 See the mdadm.conf you just generated for the exact names. 14. Now you should be able to recreate the initramfs and update grub update-initramfs -u update-grub This should work now without any errors. 15. Exit the chroot and reboot exit init 6 16. Check if your system boots now. If so, then run update-initramfs -u update-grub again from the main system and reboot one last time. I hope that you'll be able to repair your systems with that. Please report any success or failure (Which part of the above fails? What error messages are shown?)! Hope this helps! Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583917 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585015#45 [3] http://release.debian.org/migration/testing.pl?package=mdadm [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594418#25 [5] http://live.debian.net/ [6] http://upload.wikimedia.org/wikipedia/commons/5/51/KB_United_States-NoAltGr.svg signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Am Dienstag, den 14.09.2010, 21:28 +0200 schrieb Andreas von Heydwolff: My /etc/crypttab reads md1_crypt UUID=3a10eb55-2dd8-4846-97e5-74649abf234f none luks md2_crypt UUID=e78a6bea-cafb-41a7-89e9-03e999b38d6c none luks Just some thoughts: What happens if you * try `/dev/disk/by-uuid/' instead of `UUID=' * try the raw devices (presumably /dev/md1 and /dev/md2) * try the symlinks to the devices (presumably /dev/md/1 and /dev/md/2) (note that you *might* need the new mdadm version for that to work) I remember trying the `UUID=' way myself some time ago and that didn't work, however `/dev/disk/by-uuid/' did. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Am Dienstag, den 14.09.2010, 23:01 +0200 schrieb Toni Mueller: since I really need my machine now, I didn't yet dare to reboot. I also don't understand the issue too well, but simply want to contribute my data for comparison. Explanation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585015#45 I guess that this 'Generating udev events...' messages comes from mdadm's postinst? No, it comes from the init script (/etc/init.d/mdadm-raid). Mine looks like this: $ cat /etc/crypttab md1_crypt /dev/md1 none luks $ That looks ok to me. I can't confirm this one: # pvscan PV /dev/dm-0 VG ev0 lvm2 [931.32 GiB / 0free] Total: 1 [931.32 GiB] / in use: 1 [931.32 GiB] / in no VG: 0 [0 ] # I think, you should really try whether upgrading mdadm to version 3.1.4-1+8efb9d1 helps. You may want to rebuild the initramfs manually (run `update-initramfs -u' as root) to _ensure_ that you are actually using the new mdadm. You may also want to update grub (run `update-grub' as root) to _ensure_ that you are actually using the new initramfs. Best regards Alexander Kurtz PS: Having a Live-CD/USB at hand is always useful if things break. Have a look at http://live.debian.net/ . Ubuntu should also work. signature.asc Description: This is a digitally signed message part
Bug#596698: webkit 1.2.4-1 FTBFS on mipsel
Source: webkit Version: 1.2.4-1 Severity: serious Hi, webkit 1.2.4-1 FTBFS on mipsel[1] with this error: [...] /bin/mkdir -p ./.deps/DerivedSources CXXLD libJavaScriptCore.la CXXLD TestNetscapePlugin/libtestnetscapeplugin.la CXXLD Programs/jsc CXXLD libwebkit-1.0.la CCLD Programs/minidom collect2: ld terminated with signal 9 [Killed] make[2]: *** [libwebkit-1.0.la] Error 1 make[2]: Leaving directory `/build/buildd-webkit_1.2.4-1-mipsel-BevWyR/webkit-1.2.4/build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-webkit_1.2.4-1-mipsel-BevWyR/webkit-1.2.4/build' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 [...] The full build log is available at [2]. This blocks the migration to testing[3] which would fix some security issues[4]. Best regards Alexander Kurtz [1] https://buildd.debian.org/status/package.php?p=webkit [2] https://buildd.debian.org/fetch.cgi?pkg=webkitarch=mipselver=1.2.4-1stamp=1283821607file=logas=raw [3] http://release.debian.org/migration/testing.pl?package=webkit [4] http://packages.debian.org/changelogs/pool/main/w/webkit/webkit_1.2.4-1/changelog signature.asc Description: This is a digitally signed message part
Bug#594472: grub-pc: scary messages and very long boot time after upgrade
Am Donnerstag, den 26.08.2010, 11:07 +0200 schrieb Toni Mueller: After several (5?) minutes where the machine didn't do anything I was able to see, the screen was suddenly flushed with a large number of messages like: /sys/devices/virtual/block/md0 (10715) /sys/devices/virtual/block/md1 (10716) /sys/devices/virtual/block/md0 (10717) /sys/devices/virtual/block/md1 (10718) /sys/devices/virtual/block/md0 (10719) /sys/devices/virtual/block/md1 (10720) /sys/devices/virtual/block/md0 (10721) Unlocking the disk /dev/md1 (md1_crypt) Enter the passphrase: Am Samstag, den 28.08.2010, 23:58 +0200 schrieb Andreas v. Heydwolff: Then I tried to boot, GRUB came up, the mds were started, and /sys/devices/virtual/block/md0 (numbers in the high 5000s here) scrolled by for all 3 arrays. The passphrase was entered and the machine just remained stuck with the single server case hdd activity light on all the time, both with a regular boot and a rescue mode boot, so I never got past the passphrase promt. Am Sonntag, den 29.08.2010, 02:35 +0200 schrieb Agustin Martin: May this be related to #583917, mdadm: long delay (6-200 minutes) during boot (root device detection) after upgrade on RAID/LVM/LUKS setup? Am Samstag, den 04.09.2010, 04:22 +0100 schrieb Darren: upgrading to mdadm 3.1.4-1+8efb9d1 from sid solved my boot problems. That is for both, the VM I set up for testing, as well as my base PC. Both are booting fine now. This *might* indeed be a duplicate of #594418: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594418 Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#589836: mdadm: breaks initramfs on fresh (chroot) installation
Am Montag, den 16.08.2010, 07:27 +0200 schrieb martin f krafft: Thanks. FYI, I plan to push 3.1.3 soon and will try to get a release exception for that too. The current git version appears to be missing the fix for this bug: http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/initramfs/hook Just ignore me if I'm wrong... Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#594418: confirming that 3.0.3-2 is not affected by #594418
Hi, after adding deb http://snapshot.debian.org/archive/debian/20100824T210238Z/ squeeze main to my `sources.list' and downgrading mdadm to version 3.0.3-2 I can now confirm that this version is not affected by the bug (booting works without any problems). Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#594418: /sbin/mdadm --detail --export $tempnode seems to be the culprit
Hi,
after a little trial-and-error I now know that (for me) this is the
difference between a non-bootable system (for symptoms see my initial
mail) and a bootable one:
$ diff -u 3.1.2-2.1/lib/udev/rules.d/64-md-raid.rules
/lib/udev/rules.d/64-md-raid.rules
--- 3.1.2-2.1/lib/udev/rules.d/64-md-raid.rules 2010-08-25
23:30:07.814576367 +0200
+++ /lib/udev/rules.d/64-md-raid.rules 2010-08-25 23:47:46.300056953
+0200
@@ -21,7 +21,7 @@
ATTR{md/array_state}==|clear|inactive, GOTO=md_end
LABEL=md_ignore_state
-IMPORT{program}=/sbin/mdadm --detail --export $tempnode
+#IMPORT{program}=/sbin/mdadm --detail --export $tempnode
ENV{DEVTYPE}==disk, ENV{MD_NAME}==?*,
SYMLINK+=disk/by-id/md-name-$env{MD_NAME}, OPTIONS+=string_escape=replace
ENV{DEVTYPE}==disk, ENV{MD_UUID}==?*,
SYMLINK+=disk/by-id/md-uuid-$env{MD_UUID}
ENV{DEVTYPE}==disk, ENV{MD_DEVNAME}==?*,
SYMLINK+=md/$env{MD_DEVNAME}
This seems logical since:
a) There were no changes to /lib/udev/rules.d/64-md-raid.rules
between 3.0.3-2 and 3.1.2-2.1:
$ md5sum 3.0.3-2/lib/udev/rules.d/64-md-raid.rules
3.1.2-2.1/lib/udev/rules.d/64-md-raid.rules
4a574fcd059040d33ea18a8aa605a184
3.0.3-2/lib/udev/rules.d/64-md-raid.rules
4a574fcd059040d33ea18a8aa605a184
3.1.2-2.1/lib/udev/rules.d/64-md-raid.rules
However the older version works fine, see my previous mail. So it
makes sense that line causing the problems is the one actually
calling the (changed) mdadm binary.
b) This command is what I saw in `top', see `screen7.jpg' from my
initial mail.
Any thoughts on this?
Alexander Kurtz
signature.asc
Description: This is a digitally signed message part
Bug#594418: Confirming that adding `mkdir -p /lib/init/rw' fixes the problem
Am Donnerstag, den 26.08.2010, 07:57 +1000 schrieb Neil Brown: I'm fairly sure this is a known bug which is fixed in 3.1.3 which has just been released in Debian (I think). Unfortunately that has not happened yet[1]. If you repeat your experiment with init=/bin/sh, and mkdir -p /lib/init/rw before starting udev, I think you will find that it works better. Yes this actually fixes the problem. I am using this as a workaround now until 3.1.3 is available in Debian: $ diff -u /usr/share/initramfs-tools/scripts/local-top/mdadm /etc/initramfs-tools/scripts/local-top/mdadm --- /usr/share/initramfs-tools/scripts/local-top/mdadm 2010-08-14 17:34:00.0 +0200 +++ /etc/initramfs-tools/scripts/local-top/mdadm2010-08-26 00:41:11.307448188 +0200 @@ -1,4 +1,5 @@ #!/bin/sh +mkdir -p /lib/init/rw # # Copyright © 2006-2008 Martin F. Krafft madd...@debian.org # based on the scripts in the initramfs-tools package. Thank you very much for your help! Alexander Kurtz [1] http://packages.debian.org/search?keywords=mdadm signature.asc Description: This is a digitally signed message part
Bug#591215: warzone2100: version 2.3.4 fixes remaining issues
Hi, warzone2100 2.3.4 fixes some remaining issues[1]. However, I am not reopening this bug since 2.3.3 won't migrate to testing anyway due to the freeze[2]. Best regards Alexander Kurtz [1] http://wz2100.net/news/6163 [2] http://packages.qa.debian.org/w/warzone2100.html signature.asc Description: This is a digitally signed message part
Bug#591366: ufraw depends on libexiv2-4
Hmmm, on my system ufraw works fine... probably because it doesn't link against libexiv2.so.4 but against libexiv2.so.9: $ ldd /usr/bin/ufraw | grep exiv libexiv2.so.9 = /usr/lib/libexiv2.so.9 (0x7f9ba2d17000) This seems to match the packages dependencies[1]. Looking at [2] I just saw that the only ufraw version currently in squeeze which is depending on libexiv2-4 is the m68k version (that arch isn't supported anymore AFAIK). So could you make sure that you haven't accidentally missed some updates? Or are you using m68k? ;-) I'm asking this because your kernel version suggests that your system isn't up to date. If that doesn't help, please provide the output of these commands: dpkg -l ufraw ldd /usr/bin/ufraw apt-cache showpkg ufraw Please also mention if you're using any third-party repositories (your sources.list would be helpful in that case). Best regards Alexander Kurtz [1] http://packages.debian.org/squeeze/ufraw [2] http://packages.debian.org/sid/ufraw signature.asc Description: This is a digitally signed message part
Bug#591215: warzone 2.3.2 has serious issues, should not migrate to testing, wait for 2.3.3
Package: warzone2100 Severity: serious Version: 2.3.2-1 Hi, according to upstream warzone 2.3.2 has serious issues[1], they therefore recommend to use 2.3.1 until 2.3.3 is out. This bug blocks 2.3.2 from migrating to testing. Please feel free to close this bug if you think it is appropriate. Best regards Alexander Kurtz [1] http://wz2100.net/news/6047 signature.asc Description: This is a digitally signed message part
Bug#591232: network-manager uninstall should not deactivate network
fixed 591232 0.8.0.999-1 tag 591232 confirmed severity 591232 important thanks Hi, I investigated this problem in a VM. Here's what I found: Test time | Network-Manager Version | Network connection is configured by | | /etc/network/interfaces | Network-Manager +-+-+ after install | 0.6.6-3 (lenny) | connection is recreated | connection is recreated after remove| 0.6.6-3 (lenny) | connection is down | connection is down after install | 0.8.0.999-1 (squeeze) | connection is untouched | connection is recreated after remove| 0.8.0.999-1 (squeeze) | connection is untouched | connection is untouched So my conclusions are: a) Network-Manager does indeed have the described bug (connection down after removal). b) The connection is also down after removal even if it was configured manually. c) a) and b) only apply to the version in lenny, the NM version in squeeze seems to behave in a sensible way d) The package description clearly says that Network Manager is intended only for the desktop use-case, and is not intended for usage on servers Therefore you should expect things to break if you have it installed on a server. If you want to install Gnome on your server do a standard (non-graphical) install and then use apt-get install gnome network-manager- This will install gnome without NM. I have changed the bug report according to the above. If you or the maintainer think that is wrong, feel free to revert the changes. Best regards Alexander signature.asc Description: This is a digitally signed message part
Bug#590961: libao4: Please raise suggestions to depencies, breaks other software otherwise
Package: libao4 Version: 1.0.0-4 Severity: serious Justification: Breaks other software Hi, since version 2.30 brasero[1] (a graphical burning program) explicitly checks the versions of the third-party tools it is using[2]; among these is cdrdao[3] (Disk-At-Once recorder). Normally this looks like this: $ cdrdao version | sed 's/^/STDIN:/g' Cdrdao version 1.2.3 - (C) Andreas Mueller andr...@daneb.de (As you can see everything goes to stderr) Now if libaudio2[4] is not installed it looks like this: $ cdrdao version | sed 's/^/STDIN:/g' ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libnas.so = dlopen() failed Cdrdao version 1.2.3 - (C) Andreas Mueller andr...@daneb.de This is because /usr/lib/ao/plugins-4/libnas.so links against libaudio.so.2 which is provided by libaudio2. As a consequence brasero can't parse the cdrdao version string anymore (see [5]) and thus fails to recognize it correctly which results in audio disc creation being disabled. Now most users won't see this error because some other package pulled in libaudio2, but if not, unrelated things like brasero will break. This problem is not limited to libaudio2 but also affects the other suggestions. If I install cdrdao in a fresh chroot set up by debootstrap I get this: $ cdrdao version | sed 's/^/STDIN:/g' ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libalsa.so = dlopen() failed ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libnas.so = dlopen() failed ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libpulse.so = dlopen() failed ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libesd.so = dlopen() failed Cdrdao version 1.2.3 - (C) Andreas Mueller andr...@daneb.de Note that not only software packaged in Debian might parse such version strings but also local programs, scripts, etc. We should therefore prevent this error messages from screwing up things by preventing them from being printed at all. And that can only happen by changing libao4's suggestions[6] to depencies. Best Regards Alexander Kurtz [1] http://packages.debian.org/sid/brasero [2] http://git.gnome.org/browse/brasero/commit/?id=62bda5dab82ddba07b0d1af3af333860a97d39c3 [3] http://packages.debian.org/sid/cdrdao [4] http://packages.debian.org/sid/libaudio2 [5] http://git.gnome.org/browse/brasero/diff/plugins/cdrdao/burn-cdrdao.c?id=62bda5dab82ddba07b0d1af3af333860a97d39c3 [6] http://packages.debian.org/sid/libao4 signature.asc Description: This is a digitally signed message part
Bug#590393: icu: FTBFS: /usr/bin/install: cannot stat `doc/html/*.gif': No such file or directory
tags 590393 patch thanks Hi, building seems to fail because there simply aren't any .gif files generated. After applying the attached patch, the package builds successfully. Best Regards Alexander Kurtz Description: fix FTBFS because of missing .gif files, there simply aren't any. Author: Alexander Kurtz kurtz.a...@googlemail.com Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590393 diff -Naur icu-4.4.1.orig/source/Makefile.in icu-4.4.1/source/Makefile.in --- icu-4.4.1.orig/source/Makefile.in 2010-04-28 17:28:54.0 +0200 +++ icu-4.4.1/source/Makefile.in 2010-07-28 22:50:45.056353070 +0200 @@ -18,7 +18,7 @@ docsubdir = $(PACKAGE)$(ICULIBDASHSUFFIX)/html docsubsrchdir = $(docsubdir)/search docfilesdir = doc/html -docfiles = $(docfilesdir)/*.gif $(docfilesdir)/*.png $(docfilesdir)/*.html $(docfilesdir)/*.css $(docfilesdir)/*.tag $(docfilesdir)/installdox +docfiles = $(docfilesdir)/*.png $(docfilesdir)/*.html $(docfilesdir)/*.css $(docfilesdir)/*.tag $(docfilesdir)/installdox docsrchdir = $(docfilesdir)/search docsrchfiles = $(docsrchdir)/* signature.asc Description: This is a digitally signed message part
Bug#536376: evas: Not suitable for testing yet
Hi, Am Donnerstag, den 09.07.2009, 16:17 +0200 schrieb Albin Tonnerre: Package: evas Version: 0.9.9.061-1 Severity: serious The Evas API is changing frequently, and it would be better to wait until it's a bit more stable until it goes into testing. Since it's been over a year now I'd like to ask whether the above is still true? Or do you think that evas is `stable enough' nowadays, so that it could migrate to testing? The reason I'd love to see evas in squeeze is this super-sexy media-center called enna[1] which is blocked by this bug. Thank you for your work! Alexander Kurtz [1] http://enna.geexbox.org/ [2] http://release.debian.org/migration/testing.pl?package=enna
Bug#582342: Godel and inconsistency; never will know...; system with RAID and CRYPTO
Am Dienstag, den 06.07.2010, 23:12 -0400 schrieb crop...@acm.org: The problem with grub and my system abruptly disappeared; for whatever reason it has something to do with the MPTSAS driver, the SATA_NV driver, or the bios on my system. Tinkering with my sata DVD writers vanquished the problem! [...] Computer POSTs. Grub menu appears. Select 2.6.32-5-amd64 and voila... the machine boots without a problem. Grub bug # 582342 seems to be no more...!?! Any further questions or comments? Otherwise, I will be bidding adieu. Can this bug report be closed then? Best Regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#520189: nspluginwrapper does not work on kernel 2.6.26: Please downgrade severity
Ari Pollak wrote: Read my earlier message. There is no minimum kernel requirement of 2.6.27 or higher for squeeze, and you can't just declare a kernel dependency and hope the user isn't running a lower kernel version. You're right, but if this bug apparently only affects older kernels, it should therefore be declared `important' (a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone, see [1]) instead of `serious'. Yes nspluginwrapper might be broken under rare circumstances, but right now, nspluginwrapper isn't available for anyone using squeeze because this bug blocks the migration[2]. I just don't see why that is the better alternative. What makes the situation worse, is that Adobe stopped Flash support for amd64 today[3], which leaves amd64 users with this choices: a) no flash (don't mention gnash - it's beta quality) b) use older Flash version (0-day vulnerability known) c) use nspluginwrapper I think c) is the best solution under these circumstances, so I kindly ask you or the maintainer to lower the severity, if there are no good reasons against doing so. Best Regards Alexander Kurtz [1] http://www.debian.org/Bugs/Developer.en.html#severities [2] http://release.debian.org/migration/testing.pl?package=nspluginwrapper [2] http://labs.adobe.com/technologies/flashplayer10/64bit.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
