Bug#1007992: libigdgmm12: new version causes segfaults
Control: forwarded -1 https://github.com/intel/gmmlib/issues/95 Dear Debian folks, Am 20.03.22 um 07:07 schrieb Paul Menzel: Control: forward -1 https://github.com/intel/gmmlib/issues/95 I thought it was `forwarded`, but changed after reading the example in *How to report a bug in Debian using reportbug* [2], which turned out to be wrong. […] Kind regards, Paul [2]: https://www.debian.org/Bugs/Reporting.en.html#control
Bug#1007992: libigdgmm12: new version causes segfaults
Control: forward -1 https://github.com/intel/gmmlib/issues/95 Dear Debian folks, Am 20.03.22 um 04:35 schrieb Christoph Anton Mitterer: […] This version breaks e.g. video playback with mpv (also vlc): $ mpv test.mp4 (+) Video --vid=1 (h264 720x300 23.976fps) (+) Audio --aid=1 (aac 2ch 44100Hz) Segmentation fault I am only able to reproduce this with VA-API enabled, that means, when I pass `--hwdec=vaapi` to mpv. Firefox with VA-API enabled crashes too, but not when it’s disabled. Do you have VA-API enabled for mpv? […] I installed *libigdgmm12-dbgsym*, and created the issue #95 *[regression] Terminates with segfault in InitializeGmm/InitContext* upstream [1]. Hopefully, they analyze and fix it quickly. No idea, if it’s possible to revert to an earlier version in Debian sid/unstable until that is fixed. Kind regards, Paul [1]: https://github.com/intel/gmmlib/issues/95
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
Dear Steve, I am sorry for the late reply, as I was on vacation. Am 31.07.20 um 15:22 schrieb Steve McIntyre: On Fri, Jul 31, 2020 at 06:39:20AM +0200, Paul Menzel wrote: Am 31.07.20 um 06:30 schrieb Paul Menzel: Am 30.07.20 um 23:54 schrieb Paul Menzel: Package: grub-pc Version: 2.04-9 Severity: grave On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the package `grub-pc` causes GRUB to fail on next boot and drop into a rescue shell. GRUB loading. Welcome to GRUB! error: symbol 'grub_calloc' not found. grub rescue> It only seems to effects MBR installation. I missed to report, that the system has a separate `/boot` partition and a LUKS encrypted root `/`. Sorry, please scratch that. I remembered incorrectly. It’s just one unencrypted F2FS formatted partition. How many disks do you have on your system, please? *If* you have more than one, there's a potential for grub-install to have not been run to install grub to all the MBRs, and then the BIOS finds an old copy of the GRUB first-stage loader but tries to use newer modules. this mis-match can cause all kinds of problems. :-/ There is only one disk in that laptop. Kind regards, Paul
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
Dear Debian folks, Am 31.07.20 um 06:30 schrieb Paul Menzel: Am 30.07.20 um 23:54 schrieb Paul Menzel: Package: grub-pc Version: 2.04-9 Severity: grave On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the package `grub-pc` causes GRUB to fail on next boot and drop into a rescue shell. GRUB loading. Welcome to GRUB! error: symbol 'grub_calloc' not found. grub rescue> It only seems to effects MBR installation. I missed to report, that the system has a separate `/boot` partition and a LUKS encrypted root `/`. Sorry, please scratch that. I remembered incorrectly. It’s just one unencrypted F2FS formatted partition. Is there a way to boot the system using the rescue shell, or is a live system needed? Sorry for the noise. Kind regards, Paul PS: The Ubuntu report is #1889509 [1]. [1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
Dear Debian folks, Am 30.07.20 um 23:54 schrieb Paul Menzel: Package: grub-pc Version: 2.04-9 Severity: grave On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the package `grub-pc` causes GRUB to fail on next boot and drop into a rescue shell. GRUB loading. Welcome to GRUB! error: symbol 'grub_calloc' not found. grub rescue> It only seems to effects MBR installation. I missed to report, that the system has a separate `/boot` partition and a LUKS encrypted root `/`. Is there a way to boot the system using the rescue shell, or is a live system needed? Kind regards, Paul PS: The Ubuntu report is #1889509 [1]. [1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509
Bug#966575: Acknowledgement (grub-pc: error: symbol `grub_calloc' not found.)
Sehr geehrte Damen und Herren, vielen Dank für Ihre Nachricht, die ich nach dem 9. August 2020 lesen werde. Freundliche Grüße Paul Menzel --- Dear Madam or Sir, Thank you for your message, I am going to read after my return on August 10th, 2020. Kind regards, Paul Menzel
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
Package: grub-pc Version: 2.04-9 Severity: grave Dear Debian folks, On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the package `grub-pc` causes GRUB to fail on next boot and drop into a rescue shell. GRUB loading. Welcome to GRUB! error: symbol 'grub_calloc' not found. grub rescue> It only seems to effects MBR installation. Is there a way to boot the system using the rescue shell, or is a live system needed? Kind regards, Paul PS: The Ubuntu report is #1889509 [1]. [1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509
Bug#932861: boot failure because e2fsprogs should depend on logsave
Dear Debian folks, On 7/24/19 4:37 AM, Ben Caradoc-Davies wrote: > After booting my system with the previous kernel/initramfs, I was > able to install logsave, but also needed to run "update-initramfs -u" > to update the latest initramfs to include logsave before it was able > to boot. If you do not have a previous Linux kernel installed (with an old initramfs image), you can work around the issue by adding `fastboot` to the Linux kernel line in the bootloader [1]. For example, in GRUB you can press the key *e* to edit an entry in the GRUB menu. Then install the package *logsave*, and run `sudo update-initramfs -u` as Ben wrote. Kind regards, Paul [1]: https://sources.debian.org/src/initramfs-tools/0.133/scripts/functions/?hl=398#L363 smime.p7s Description: S/MIME Cryptographic Signature
Bug#931280: gnome-shell: Keyboard layout randomly alternates
Severity: normal On 30.06.19 15:58, Michael Biebl wrote: On Sun, 30 Jun 2019 14:35:47 +0200 Paul Menzel wrote: Package: gnome-shell Version: 3.30.2-9 Severity: serious That feels vastly exaggerated. That aside... Ok, if you say so that it won’t cause data loss. I change it to *normal*. With Debian Sid/unstable with the default GNOME session, that means Wayland is used, and with two keyboard layouts configured (Neo (default), and German) sometimes the keyboard layout changes from Neo to normal German without me pressing the corresponding shortcut. The notification in the GNOME Shell’s top bar also still shows de₁, which is for Deutsch (Neo 2), so it is not changed. Unfortunately I have not figured out, what causes this. My suspicion is that “X.Org applications” like Mozilla Firefox and Thunderbird are involved. Maybe the GDM session running in parallel has something to do with it? No idea. Debugging help is much appreciated. I too have two keyboard layouts configured and this happens to me as well, under GNOME/Xorg and afaics is simply me pressing by accident Windows/Super + Space. This is the shortcut for switching the keyboard layout. I suspect it's the same for you. You can reconfigure the shortcut in gnome-control-center. Go to "Tastatur->Texteingabe->Zur nächsten Quelle wechseln" I am pretty sure, it’s not it, because if I press this shortcut, a popup is shown and the notification in the top bar changes. Kind regards, Paul
Bug#931281: gnome-shell: Session cannot be unlocked when audio dialog for plugged in speaker is active
Package: gnome-shell Version: 3.30.2-9 Severity: serious Dear Debian folks, With Debian Sid/unstable with the default GNOME session, that means Wayland is used, logging in and plugging in speakers/headphone a dialog pops up if this is a headphone, a headset or a microphone. If ignore that dialog for whatever reason and go away and your session is locked by the “screensaver“, and the screen goes dark. Coming back, the session is locked and the dialog is still there. Then you can select the corresponding device, and enter the correct password, but your session is not restored correctly. The top bar is shown with the menu of the last opened application, but the in the background you do *not* see the application but still the image of the lock screen. You can still switch ttys, but I was unable to get back into message. In that situation data might get lost, because you cannot save it, and have to kill the session. Kind regards, Paul -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1 ii gir1.2-accountsservice-1.0 0.6.45-2 ii gir1.2-atspi-2.0 2.30.0-7 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.1-1 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.2-3 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-3 ii gir1.2-gnomedesktop-3.0 3.30.2.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gweather-3.0 3.28.3-1 ii gir1.2-ibus-1.0 1.5.19-4+b1 ii gir1.2-mutter-3 3.30.2-7 ii gir1.2-nm-1.01.14.6-2 ii gir1.2-nma-1.0 1.8.20-1.1 ii gir1.2-pango-1.0 1.42.4-6 ii gir1.2-polkit-1.00.105-25 ii gir1.2-rsvg-2.0 2.44.10-2.1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-upowerglib-1.00.99.10-1 ii gjs 1.54.3-1 ii gnome-backgrounds3.30.0-1 ii gnome-settings-daemon3.30.2-3 ii gnome-shell-common 3.30.2-9 ii gsettings-desktop-schemas3.28.1-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcroco30.6.12-3 ii libecal-1.2-19 3.30.5-1 ii libedataserver-1.2-233.30.5-1 ii libgcr-base-3-1 3.28.1-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-11.58.3-2 ii libgjs0g 1.54.3-1 ii libglib2.0-0 2.58.3-2 ii libglib2.0-bin 2.58.3-2 ii libgstreamer1.0-01.14.4-1 ii libgtk-3-0 3.24.5-1 ii libical3 3.0.5-1 ii libjson-glib-1.0-0 1.4.4-2 ii libmutter-3-03.30.2-7 ii libnm0 1.14.6-2 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpolkit-agent-1-0 0.105-25 ii libpolkit-gobject-1-00.105-25 ii libpulse-mainloop-glib0 12.2-4 ii libpulse012.2-4 ii libsecret-1-00.18.7-1 ii libstartup-notification0 0.12-6 ii libsystemd0 242+git20190613-1 ii libx11-6 2:1.6.7-1 ii libxfixes3 1:5.0.3-1 ii mutter
Bug#931280: gnome-shell: Keyboard layout randomly alternates
Package: gnome-shell Version: 3.30.2-9 Severity: serious Dear Debian folks, With Debian Sid/unstable with the default GNOME session, that means Wayland is used, and with two keyboard layouts configured (Neo (default), and German) sometimes the keyboard layout changes from Neo to normal German without me pressing the corresponding shortcut. The notification in the GNOME Shell’s top bar also still shows de₁, which is for Deutsch (Neo 2), so it is not changed. Unfortunnately I have not figured out, what causes this. My suspicion is that “X.Org applications” like Mozilla Firefox and Thunderbird are involved. Maybe the GDM session running in parallel has something to do with it? No idea. Debugging help is much appreciated. Kind regards, Paul PS: I chose the severity *serious*, because suddenly having a different keyboard layout can cause data loss, when you suddenly press key which for example confirms the deletion of data, despite you thinking you press a different key to abort on the keyboard you currently use. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1 ii gir1.2-accountsservice-1.0 0.6.45-2 ii gir1.2-atspi-2.0 2.30.0-7 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.1-1 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.2-3 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-3 ii gir1.2-gnomedesktop-3.0 3.30.2.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gweather-3.0 3.28.3-1 ii gir1.2-ibus-1.0 1.5.19-4+b1 ii gir1.2-mutter-3 3.30.2-7 ii gir1.2-nm-1.01.14.6-2 ii gir1.2-nma-1.0 1.8.20-1.1 ii gir1.2-pango-1.0 1.42.4-6 ii gir1.2-polkit-1.00.105-25 ii gir1.2-rsvg-2.0 2.44.10-2.1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-upowerglib-1.00.99.10-1 ii gjs 1.54.3-1 ii gnome-backgrounds3.30.0-1 ii gnome-settings-daemon3.30.2-3 ii gnome-shell-common 3.30.2-9 ii gsettings-desktop-schemas3.28.1-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcroco30.6.12-3 ii libecal-1.2-19 3.30.5-1 ii libedataserver-1.2-233.30.5-1 ii libgcr-base-3-1 3.28.1-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-11.58.3-2 ii libgjs0g 1.54.3-1 ii libglib2.0-0 2.58.3-2 ii libglib2.0-bin 2.58.3-2 ii libgstreamer1.0-01.14.4-1 ii libgtk-3-0 3.24.5-1 ii libical3 3.0.5-1 ii libjson-glib-1.0-0 1.4.4-2 ii libmutter-3-03.30.2-7 ii libnm0 1.14.6-2 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpolkit-agent-1-0 0.105-25 ii libpolkit-gobject-1-00.105-25 ii libpulse-mainloop-glib0 12.2-4 ii libpulse012.2-4 ii libsecret-1-00.18.7-1 ii libstartup-notification0 0.12-6 ii libsystemd0 242+git20190613-1 ii libx11-6 2:1.6.7-1 ii libxfixes3
Bug#922020: gnome-shell: Keyboard layout not applied in programs using Xwayland
Package: gnome-shell Version: 3.30.2-3 Severity: grave Dear Debian folks, Since updating the packages on Saturday in Debian Sid/unstable, using GNOME Shell with Wayland, the configure keyboard layout is not applied to programs using XWayland anymore. Examples are Mozilla Firefox, Mozilla Thunderbird and Google Chromium. Using GNOME with X, everything works as expected. As talked about in #debian-gnome, I am using severity *grave*. Kind regards, Paul -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.20.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1 ii gir1.2-accountsservice-1.0 0.6.45-1 ii gir1.2-atspi-2.0 2.30.0-7 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.1-1 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.2-3 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-3 ii gir1.2-gnomedesktop-3.0 3.30.2.1-1 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gweather-3.0 3.28.2-2 ii gir1.2-ibus-1.0 1.5.19-1 ii gir1.2-mutter-3 3.30.2-6 ii gir1.2-nm-1.01.14.4-4 ii gir1.2-nma-1.0 1.8.18-2 ii gir1.2-pango-1.0 1.42.4-6 ii gir1.2-polkit-1.00.105-25 ii gir1.2-rsvg-2.0 2.44.10-1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-upowerglib-1.00.99.9-3 ii gjs 1.54.3-1 ii gnome-backgrounds3.30.0-1 ii gnome-settings-daemon3.30.2-2 ii gnome-shell-common 3.30.2-3 ii gsettings-desktop-schemas3.28.1-1 ii libatk-bridge2.0-0 2.30.0-4 ii libatk1.0-0 2.30.0-2 ii libc62.28-7 ii libcairo21.16.0-2 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcroco30.6.12-3 ii libecal-1.2-19 3.30.5-1 ii libedataserver-1.2-233.30.5-1 ii libgcr-base-3-1 3.28.1-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgirepository-1.0-11.58.3-2 ii libgjs0g 1.54.3-1 ii libglib2.0-0 2.58.3-1 ii libglib2.0-bin 2.58.3-1 ii libgstreamer1.0-01.14.4-1 ii libgtk-3-0 3.24.5-1 ii libical3 3.0.4-3 ii libjson-glib-1.0-0 1.4.4-2 ii libmutter-3-03.30.2-6 ii libnm0 1.14.4-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpolkit-agent-1-0 0.105-25 ii libpolkit-gobject-1-00.105-25 ii libpulse-mainloop-glib0 12.2-3 ii libpulse012.2-3 ii libsecret-1-00.18.7-1 ii libstartup-notification0 0.12-6 ii libsystemd0 240-5 ii libx11-6 2:1.6.7-1 ii libxfixes3 1:5.0.3-1 ii mutter 3.30.2-6 ii python3 3.7.2-1 Versions of packages gnome-shell recommends: ii bolt 0.7-2 ii chrome-gnome-shell10.1-4 ii gdm3 3.30.2-3 ii gkbd-capplet 3.26.0-5 ii gnome-control-center 1:3.30.3-1 ii gnome-user-docs 3.30.2-1 ii iio-sensor-proxy 2.4-2 ii switcheroo-control1.2-2 ii unzip 6.0-22 Versions of packages gnome-shell suggests: pn gir1.2-telepathyglib-0.12 pn gir1.2-telepathylogger-0.2 -- no debconf information
Bug#917234: [initramfs-tools] Unable to detect root device
Dear Ben, Am 30.12.18 um 19:19 schrieb Ben Hutchings: Control: reassign -1 udev Control: forcemerge 917124 -1 Thank you for taking care of the issue. […] Yes, it sounds like this really is the same thing although it was harder for you to recover from. For the record, in hindsight adding the symbolic link would have been enough. /dev/mapper$ sudo ln -s ../dm-0 sda3_crypt Kind regards, Paul
Bug#871631: lilypond-data: Update fails due to problem with symbolic link creation
Package: lilypond-data Version: 2.18.2-8 Severity: serious Dear Debian folks, The update of lilypond-data fails with the message below. ``` lilypond-data (2.18.2-8) wird eingerichtet ... Running mktexlsr /usr/share/texlive/texmf-dist... mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... mktexlsr: Done. ln: die symbolische Verknüpfung 'lilypond/user' konnte nicht angelegt werden: Die Datei existiert bereits dpkg: Fehler beim Bearbeiten des Paketes lilypond-data (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück ``` It says the symbolic link `lilypond/user` couldn’t be created, because the file already exists. Thanks, Paul -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.11.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lilypond depends on: ii ghostscript9.21~dfsg-1 ii libc6 2.24-14 ii libfontconfig1 2.12.3-0.2 ii libfreetype6 2.8-0.2 ii libgcc11:7.1.0-13 ii libglib2.0-0 2.53.4-3 ii libgmp10 2:6.1.2+dfsg-1 ii libltdl7 2.4.6-2 ii libpango-1.0-0 1.40.6-1 ii libpangoft2-1.0-0 1.40.6-1 ii libstdc++6 7.1.0-13 ih lilypond-data 2.18.2-8 ii python 2.7.13-2 Versions of packages lilypond recommends: ii texlive-latex-base 2017.20170808-1 Versions of packages lilypond suggests: ii lilypond-doc 2.18.2-8 -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#789541: abtransfers: Crash after successful money transfer
Dear Patrick, Am Donnerstag, den 25.06.2015, 18:25 +0200 schrieb Patrick Wacker: I'm the upstream author of AB-Transfers. Thank you for your detailed explanations. Thank you for writing AB-Transfers! […] Looking at the “bad” `history.ctx` it’s size is 41 MB (42626560 Bytes) and I think it contains strange characters due to umlauts I put into the “Verwendungszweck” with the middle click as it’s not allowed (for some reason) entering it with the keyboard. During development I had some issues with the German umlauts. Some banks supported it some don't. And also the aqbanking backend sometimes replaced some umlauts with spaces or not readable characters (but a crash did not happened). Therefore I decided to be on the save side and disabled the input of umlauts at abtransfers (didn't blocked/checked copypaste input, my fault). The Berliner Volksbank seems to support it. I guess this is a bug in AqBanking then. Also a size of 41 MB is pretty big, either you using the program for a long time with a lot of transfers or something else is wrong. A normal transfer should occupy around 1.2 KB at the history (34000 transfers needed to reach 41MB). Also looking at `history.ctx` after the crash yesterday, the format seems to be incorrect. The following is missing at the end of the file compared to the file written today. int cycle=0 int executionDay=0 char type=transaction char subType=none char status=none char charge=Nobody char sequenceType=once } #transfer } #transferList } #accountInfo } #accountInfoList A few lines above this missing entries (or directly at the end) of your bad history.ctx file should be a line starting with char purpose=. Could you remember which purpose (with umlauts) do you used? The last line in the “after crash” file is the following (without the closing ). char period=none It’s a transfer from last November. Which is the character that could not be written at the bad history.txt and maybe caused the crash? If I know this I could try to reproduce it here and maybe could fix it. The name of the account has umlauts in it: SG Friedrichshain Grün-Weiß 90 e. V.. Looking at the newly written `history.ctx` with only three transactions, it looks like the umlauts are recoded during each write. (The most recent entry is at the top.) char localName=SG Friedrichshain Gr%C3%BCn Wei%C3%9F char category=JobStatus%3A 5, JobType%3A 16 char localName=SG Friedrichshain Gr%C3%83%C2%BCn Wei%C3%83%C2%9F char category=JobStatus%3A 5, JobType%3A 16 char localName=SG Friedrichshain Gr%C3%83%C2%83%C3%82%C2%BCn Wei%C3%83%C2%83%C3%82%C2%9F char category=JobStatus%3A 5, JobType%3A 16 So with not a big number of transaction, that file gets pretty big as the `localName` lines get bigger after each transaction. In the faulty file the longest line has 12582962 columns. This probably causes the assertion in libgwenhywfar60 4.14.0-1. 3:2015/06/22 08-46-31:gwen(11198):buffer.c: 314: Size is beyond hard limit (1677727416777216) (Is the whole transfer block read in at once?) Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#789541: abtransfers: Crash after successful money transfer
Dear Micha, Am Dienstag, den 23.06.2015, 20:38 +0200 schrieb Micha Lenk: Am 23.06.2015 um 09:00 schrieb Paul Menzel: just a note, that it looks like this problem is reproducible. I did another transaction today and it crashed again after the success dialog appeared. I was unable to click the *Schließen* button. Interesting. I am sorry for leaving out the important information, that I restored `history.ctx` from my backup. Does the crash happen again if you: 1. close all abtransfers instances 2. rename the file /home/paul/Documents/gw90/.abtransfers/history.ctx 3. start abtransfers and try again to transfer money Removing `history.ctx`, the file is recreated after a transaction and AB-Transfers does not crash. Looking at the “bad” `history.ctx` it’s size is 41 MB (42626560 Bytes) and I think it contains strange characters due to umlauts I put into the “Verwendungszweck” with the middle click as it’s not allowed (for some reason) entering it with the keyboard. Also looking at `history.ctx` after the crash yesterday, the format seems to be incorrect. The following is missing at the end of the file compared to the file written today. int cycle=0 int executionDay=0 char type=transaction char subType=none char status=none char charge=Nobody char sequenceType=once } #transfer } #transferList } #accountInfo } #accountInfoList So I guess it’s recreated because the syntax is invalid. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#789541: abtransfers: Crash after successful money transfer
Dear Micha,
Am Montag, den 22.06.2015, 19:47 +0200 schrieb Micha Lenk:
Am 22.06.2015 19:41, schrieb Micha Lenk:
If you still have the core file available, would you mind to
install
the package libgwenhywfar60-dbg
... and also the package libaqbanking35-dbg, please,
and re-run gdb to get some more details about your crash?
This should produce more meaningfull backtraces.
Thread 1 (Thread 0xb59cc740 (LWP 11198)):
#0 0x in __kernel_vsyscall ()
#1 0x in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = optimized out
resultvar = optimized out
pid = -1236488192
selftid = 11198
#2 0x in __GI_abort () at abort.c:89
save_stage = 2
act =
{__sigaction_handler = {sa_handler = 0x93613e6, sa_sigaction =
0x93613e6}, sa_mask = {__val = {142351576, 3076119365, 0, 3077754880,
3077609560, 1, 3218252992, 3077680287, 307761, 3046961184, 1, 1, 0,
3077349376, 3076066471, 3077349376, 3218252964, 3077349420, 3075934372,
3075884692, 154538920, 1, 3076781500, 3056775448, 2870833160, 154538608,
2870833160, 3077349376, 151110856, 3218253052, 2870833160, 3077705760}},
sa_flags = 0, sa_restorer = 0xb6354880 __GI_abort}
sigs = {__val = {32, 0 repeats 31 times}}
#3 0x in GWEN_Buffer_AllocRoom (bf=0x901c4c8, size=2) at buffer.c:278
__PRETTY_FUNCTION__ = GWEN_Buffer_AllocRoom
#4 0x in GWEN_Buffer_AppendByte (bf=0x901c4c8, c=50 '2') at
buffer.c:394
rv = optimized out
__PRETTY_FUNCTION__ = GWEN_Buffer_AppendByte
#5 0x in GWEN_Text_EscapeToBufferTolerant (src=0xac72f42b
\302\202Â\302\203Ã\302\203Â\302\202Ã\302\202Â\302\203Ã\302\203Â\302\203Ã\302\202Â\302\202Ã\302\203Â\302\202Ã\302\202Â\302\203Ã\302\203Â\302\203Ã\302\202Â\302\203Ã\302\203Â\302\202Ã\302\202Â\302\202Ã\302\203Â\302\203Ã\302\202Â\302\202Ã\302\203Â\302\202Ã\302\202Â\302\203Ã\302\203Â\302\203Ã\302\202Â\302\203Ã\302\203Â\302\202Ã\302\202Â\302\203Ã\302\203Â\302\203Ã\302\202Â\302\202Ã\302\203Â\302\202Ã\302\202Â\302\202Ã\302\203Â\302\203Ã\302\202Â\302\203Ã...,
buf=0x901c4c8) at text.c:1449
c = optimized out
x = optimized out
#6 0x in GWEN_DB_WriteGroupToIoLayer (fb=0x9361048, dbflags=284688384,
insert=8, node=optimized out) at dbrw.c:318
numbuffer =
0\000\065\066\062\000\071\065\067\063\000\277\354\250ҿ\354\250ҿ\354\250ҿ\355\250ҿk\251ҿ
bbsize = 1
lastWasVar = 1
#7 0x in GWEN_DB_WriteGroupToIoLayer (fb=0x9361048, dbflags=284688384,
insert=6, node=optimized out) at dbrw.c:246
lastWasVar = 1
#8 0x in GWEN_DB_WriteGroupToIoLayer (fb=0x9361048, dbflags=284688384,
insert=4, node=optimized out) at dbrw.c:246
lastWasVar = 1
#9 0x in GWEN_DB_WriteGroupToIoLayer (fb=0x9361048, dbflags=284688384,
insert=2, node=optimized out) at dbrw.c:246
lastWasVar = 1
#10 0x in GWEN_DB_WriteGroupToIoLayer (fb=0x9361048, dbflags=284688384,
insert=0, node=optimized out) at dbrw.c:246
lastWasVar = 1
#11 0x in GWEN_DB_WriteToIo (node=0x8e93618, sio=0x8982540,
dbflags=284688384) at dbrw.c:516
rv = optimized out
fb = 0x9361048
#12 0x in AH_ImExporterCtxFile_Export (ie=0x89a8848, ctx=0x8e93d50,
sio=0x8982540, params=0x8f7afd0) at ctxfile.c:157
ieh = optimized out
dbData = 0x8e93618
rv = optimized out
__PRETTY_FUNCTION__ = AH_ImExporterCtxFile_Export
#13 0x in AB_ImExporter_Export (ie=0x89a8848, ctx=0x8e93d50,
sio=0x8982540, params=0x8f7afd0) at imexporter.c:136
#14 0x in AB_ImExporter_ExportToFile (ie=0x89a8848, ctx=0x8e93d50,
fname=0x0, dbProfile=0x2bbe) at imexporter.c:239
sio = 0x8982540
__PRETTY_FUNCTION__ = AB_ImExporter_ExportToFile
#15 0x in AB_Banking_ExportToFile (ab=0x88471c0, ctx=0x8e93d50,
exporterName=0x897ce38 ctxfile, profileName=0x8e935f8 default,
fname=0x8f7af28 /home/paul/Documents/gw90/.abtransfers/history.ctx) at
banking_imex.c:274
ie = 0x89a8848
dbProfile = 0x8f7afd0
rv = optimized out
#16 0x080c97f9 in ()
#17 0x08062239 in ()
#18 0x08069909 in ()
#19 0x080f01b9 in ()
#20 0x in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4
#21 0x080f172c in ()
#22 0x08097afa in ()
#23 0x080f12a9 in ()
#24 0x in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4
#25 0x080f1945 in ()
#26 0x080f1b89 in ()
#27 0x080f1cbc in ()
#28 0x in QMetaObject::metacall(QObject*, QMetaObject::Call, int,
void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4
#29 0x in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4
#30 0x in QAbstractButton::clicked(bool) () at
/usr/lib/i386-linux-gnu/libQtGui.so.4
#31 0x in () at
Bug#789541: abtransfers: Crash after successful money transfer
Dear Micha, just a note, that it looks like this problem is reproducible. I did another transaction today and it crashed again after the success dialog appeared. I was unable to click the *Schließen* button. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#789540: abtransfers: History lost after crash
Dear Micha, Am Montag, den 22.06.2015, 19:31 +0200 schrieb Micha Lenk: Am 22.06.2015 08:54, schrieb Paul Menzel: AB-Transfers crashed (I’ll send a separate report for that) and after starting it again, all the data for the history was lost. Thanks for your valuable report. Thank you for the fast reply and your work maintaining this package! Can you please describe a bit more verbose what exact data you refer to with the term the history? What is stored in the history? The history lists all the executed(?) transactions of the past and is stored in `$HOME/.abtransfers`. I even believe that the whole content of the directory `$HOME/.abtransfers` was lost. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#789541: abtransfers: Crash after successful money transfer
Package: abtransfers Version: 0.0.5.0-5 Severity: grave Tags: upstream Justification: causes non-serious data loss Dear Debian folks, AB-Transfers crashed with the following output on the terminal. PARSER - Transfer: Status: 1 (accepted) void MainWindow::onActionSaveAllDataTriggered() saving account and history data 2806 : aqb_AccountInfo(0x88f0e10) 3 : aqb_AccountInfo(0x88f0d78) 106 : aqb_AccountInfo(0x88ef640) 4 : aqb_AccountInfo(0x8901630) 107 : aqb_AccountInfo(0x8900f88) 5 : aqb_AccountInfo(0x88febd0) 2405 : aqb_AccountInfo(0x89002e8) 2767 : aqb_AccountInfo(0x88f0970) static void abt_parser::save_local_ctx(AB_IMEXPORTER_CONTEXT*, const QString, const QString, const QString) ERROR: 1 -- something went wrong on filling the gaps (this is not an serious error) 3:2015/06/22 08-46-31:gwen(11198):buffer.c: 314: Size is beyond hard limit (1677727416777216) [1]+ Abgebrochen (Speicherabzug geschrieben) abtransfers I have the core dump file, but there are no debug symbols available. Core was generated by `abtransfers'. Program terminated with signal SIGABRT, Aborted. #0 0xb770cbe0 in __kernel_vsyscall () (gdb) bt #0 0x in __kernel_vsyscall () #1 0x in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0x in __GI_abort () at abort.c:89 #3 0x in () at /usr/lib/libgwenhywfar.so.60 #4 0x in GWEN_Buffer_AppendByte () at /usr/lib/libgwenhywfar.so.60 #5 0x in GWEN_Text_EscapeToBufferTolerant () at /usr/lib/libgwenhywfar.so.60 #6 0x in () at /usr/lib/libgwenhywfar.so.60 #7 0x in () at /usr/lib/libgwenhywfar.so.60 #8 0x in () at /usr/lib/libgwenhywfar.so.60 #9 0x in () at /usr/lib/libgwenhywfar.so.60 #10 0x in () at /usr/lib/libgwenhywfar.so.60 #11 0x in GWEN_DB_WriteToIo () at /usr/lib/libgwenhywfar.so.60 #12 0x in () at /usr/lib/aqbanking/plugins/35/imexporters/ctxfile.so #13 0x in AB_ImExporter_Export () at /usr/lib/libaqbanking.so.35 #14 0x in AB_ImExporter_ExportToFile () at /usr/lib/libaqbanking.so.35 #15 0x in AB_Banking_ExportToFile () at /usr/lib/libaqbanking.so.35 #16 0x080c97f9 in () #17 0x08062239 in () #18 0x08069909 in () #19 0x080f01b9 in () #20 0x in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4 #21 0x080f172c in () #22 0x08097afa in () #23 0x080f12a9 in () #24 0x in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4 #25 0x080f1945 in () #26 0x080f1b89 in () #27 0x080f1cbc in () #28 0x in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4 #29 0x in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib/i386-linux-gnu/libQtCore.so.4 #30 0x in QAbstractButton::clicked(bool) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #31 0x in () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #32 0x in () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #33 0x in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #34 0x in QWidget::event(QEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #35 0x in QAbstractButton::event(QEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #36 0x in QPushButton::event(QEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #37 0x in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #38 0x in QApplication::notify(QObject*, QEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #39 0x in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib/i386-linux-gnu/libQtCore.so.4 #40 0x in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointerQWidget, bool) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #41 0x in () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #42 0x in QApplication::x11ProcessEvent(_XEvent*) () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #43 0x in () at /usr/lib/i386-linux-gnu/libQtGui.so.4 #44 0x in g_main_context_dispatch (context=optimized out) at /build/glib2.0-ctZcLv/glib2.0-2.44.1/./glib/gmain.c:3122 #45 0x in g_main_context_dispatch (context=0x0) at /build/glib2.0-ctZcLv/glib2.0-2.44.1/./glib/gmain.c:3737 #46 0x in g_main_context_iterate (context=0x87c3ef8, block=6, block@entry=1, dispatch=1, self=optimized out) at
Bug#789540: abtransfers: History lost after crash
Package: abtransfers Version: 0.0.5.0-5 Severity: grave Tags: upstream Justification: causes non-serious data loss Dear Debian folks, AB-Transfers crashed (I’ll send a separate report for that) and after starting it again, all the data for the history was lost. Therefore I am setting the severity to *grave*. Thanks, Paul -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.0.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages abtransfers depends on: ii libaqbanking35 5.6.1beta-1 ii libaqbanking35-plugins 5.6.1beta-1 ii libc6 2.19-18 ii libgcc1 1:5.1.1-11 ii libgwengui-cpp0 4.14.0-1 ii libgwengui-qt4-04.14.0-1 ii libgwenhywfar60 4.14.0-1 ii libqtcore4 4:4.8.7+dfsg-1 ii libqtgui4 4:4.8.7+dfsg-1 ii libstdc++6 5.1.1-11 abtransfers recommends no packages. abtransfers suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#781194: libqt5webkit5: Reproducibly crashes with segfault due to missing checks for `HTMLUnknownElement`
Package: libqt5webkit5 Version: 5.3.2+dfsg-3 Severity: grave Tags: upstream fixed-upstream Justification: causes non-serious data loss Control: affects -1 wkhtmltopdf arora Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-41360 Dear Debian folks, Wkhtmltopdf reproducibly terminates with a segmentation fault in `libqt5webkit5` [1]. (gdb) bt #0 0x in ?? () #1 0x76182ffc in WebCore::JSNodeOwner::isReachableFromOpaqueRoots(JSC::HandleJSC::Unknown, void*, JSC::SlotVisitor) () at ../WTF/wtf/Vector.h:912 #2 0x762e4234 in JSC::WeakBlock::visit (this=0x67cd40, heapRootVisitor=0x7fffe406ecf0) at heap/WeakBlock.cpp:108 #3 0x762f695b in JSC::MarkedSpace::visitWeakSets (this=0x7fffe40e5268, heapRootVisitor=0x7fff6250) at heap/WeakSet.h:104 #4 0x762e92bf in JSC::Heap::markRoots (this=0x7fffe40e5018) at heap/Heap.cpp:569 #5 0x762ed8bf in JSC::Heap::collect (this=0x7fffe40e5018, sweepToggle=3825659120) at heap/Heap.cpp:727 #6 0x7651542a in JSC::DefaultGCActivityCallback::doWork (this=0x67cd40) at runtime/GCActivityCallback.cpp:96 #7 0x762f0917 in JSC::HeapTimer::timerEvent (this=0x7fffe40a11c0) at heap/HeapTimer.cpp:159 #8 0x733a7773 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x743a4f3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #10 0x743aa380 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #11 0x73377f1b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x733ce465 in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x733ce891 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x7030bc5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x7030bf48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7030bffc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x733cf54c in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x0042560c in wkhtmltopdf::ConverterPrivate::convert (this=0x6bfd10) at ../lib/converter.cc:94 #19 0x0042584b in wkhtmltopdf::Converter::convert (this=0x7fff75e0) at ../lib/converter.cc:149 #20 0x0043b288 in main (argc=3, argv=0x7fffebe8) at wkhtmltopdf.cc:187 This is a bug in QtWebKit (QTBUG-41360 [2]) and has been fixed upstream [3]. It’d be great if you applied that patch to the Debian package and get it into Debian Jessie before its release, as this issue has been set to P2 – important upstream and as the crashes might cause non-serious data loss, when Arora crashed while I typed in a message in a Web interface or Wkhtmltopdf, often used by other applications, does not create the PDF. The work-around of installing the package `gstreamer0.10-plugins-base` is not feasible, as the user wastes their time figuring out the cause for the crash – a note in the release notes would be necessary – and there is a patch available. Depending on `gstreamer0.10-plugins-base` would be possible too, but applying the patch seems the better choice. Thanks, Paul [1] https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2259 [2] https://bugreports.qt.io/browse/QTBUG-41360 [3] https://codereview.qt-project.org/#/c/95151 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libqt5webkit5 depends on: ii dpkg 1.17.24 ii libc6 2.19-17 ii libgcc1 1:4.9.2-10 ii libgl1-mesa-glx [libgl1] 10.4.2-2 ii libglib2.0-0 2.42.1-1 ii libgstreamer-plugins-base0.10-0 0.10.36-2 ii libgstreamer0.10-00.10.36-1.5 ii libicu52 52.1-8 ii libjpeg62-turbo 1:1.3.1-8 ii libpng12-01.2.50-2+b2 ii libqt5core5a [qtbase-abi-5-3-2] 5.3.2+dfsg-4+b1 ii libqt5gui55.3.2+dfsg-4+b1 ii libqt5network55.3.2+dfsg-4+b1 ii libqt5opengl5 5.3.2+dfsg-4+b1 ii libqt5printsupport5 5.3.2+dfsg-4+b1 ii libqt5qml5
Bug#780444: Update my email address
Control: submitter -1 ! Dear Debian folks, Unfortunately I submitted that report from the wrong email address. So update it. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#780452: libwebkitgtk-3.0-0: Segfault in `VectorBufferBase` at `../Source/WTF/wtf/Vector.h:330`
Package: libwebkitgtk-3.0-0 Version: 2.4.8-1 Severity: grave Tags: upstream Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=142692 Control: affects -1 evolution Dear Debian folks, Evolution sometimes crashes due to a segmentation fault in libwebkitgtk-3.0.so.0.22.14. evolution[2714]: segfault at bfd27b2c ip b5708819 sp bfd25a20 error 6 in libwebkitgtk-3.0.so.0.22.14[b54b7000+1c5c000] I reported this to the WebKitGTK+ bug tracker as ticket #127474 [1]. Thanks, Paul [1] https://bugs.webkit.org/show_bug.cgi?id=127474 Segfault in `VectorBufferBase` at `../Source/WTF/wtf/Vector.h:330` -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libwebkitgtk-3.0-0 depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-16 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libenchant1c2a 1.6.0-10.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-3 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgl1-mesa-glx [libgl1]10.4.2-2 ii libglib2.0-02.42.1-1 ii libgstreamer-plugins-base1.0-0 1.4.4-2 ii libgstreamer1.0-0 1.4.4-2 ii libgtk-3-0 3.14.5-1 ii libharfbuzz-icu00.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libicu5252.1-7.1 ii libjavascriptcoregtk-3.0-0 2.4.8-1 ii libjpeg62-turbo 1:1.3.1-8 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-0 1.2.50-2+b2 ii libsecret-1-0 0.18-1+b1 ii libsoup2.4-12.48.0-1 ii libsqlite3-03.8.7.4-1 ii libstdc++6 4.9.2-10 ii libwebkitgtk-3.0-common 2.4.8-1 ii libwebp50.4.1-1.2+b2 ii libx11-62:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxfixes3 1:5.0.1-2+b2 ii libxml2 2.9.2+dfsg1-3 ii libxrender1 1:0.9.8-1+b1 ii libxslt1.1 1.1.28-2+b2 ii libxt6 1:1.1.4-1+b1 ii multiarch-support 2.19-16 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages libwebkitgtk-3.0-0 recommends: ii geoclue-2.02.1.10-2 ii gstreamer1.0-plugins-base 1.4.4-2 ii gstreamer1.0-plugins-good 1.4.4-2 libwebkitgtk-3.0-0 suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#780452: libwebkitgtk-3.0-0: Segfault in `VectorBufferBase` at `../Source/WTF/wtf/Vector.h:330`
Dear Debian folks, Am Samstag, den 14.03.2015, 10:00 +0100 schrieb Paul Menzel: […] I reported this to the WebKitGTK+ bug tracker as ticket #127474 [1]. I meant ticket #142692 [2] as denoted in the meta data. Thanks, Paul [2] https://bugs.webkit.org/show_bug.cgi?id=142692 Segfault in `VectorBufferBase` at `../Source/WTF/wtf/Vector.h:330` signature.asc Description: This is a digitally signed message part
Bug#780444: libwebkitgtk-3.0-0: use after free: GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure-ref_count 0' failed
Package: libwebkitgtk-3.0-0 Version: 2.4.8-1 Severity: grave Tags: upstream fixed-upstream Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=127474 Control: affects -1 evolution Dear Debian folks, with Evolution a lot of the following warnings are printed to the terminal. GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure-ref_count 0' failed This was reported upstream in ticket #127474 [1] and has recently been fixed in change set #180141 [2]. It’d be great if you applied that patch to the Debian package, so there is no use after free problem. Thanks, Paul [1] https://bugs.webkit.org/show_bug.cgi?id=127474 [GTK] Loading page into WebView shows g_closure_unref warning [2] http://trac.webkit.org/changeset/180141 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libwebkitgtk-3.0-0 depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-16 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libenchant1c2a 1.6.0-10.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-3 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgl1-mesa-glx [libgl1]10.4.2-2 ii libglib2.0-02.42.1-1 ii libgstreamer-plugins-base1.0-0 1.4.4-2 ii libgstreamer1.0-0 1.4.4-2 ii libgtk-3-0 3.14.5-1 ii libharfbuzz-icu00.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libicu5252.1-7.1 ii libjavascriptcoregtk-3.0-0 2.4.8-1 ii libjpeg62-turbo 1:1.3.1-8 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-0 1.2.50-2+b2 ii libsecret-1-0 0.18-1+b1 ii libsoup2.4-12.48.0-1 ii libsqlite3-03.8.7.4-1 ii libstdc++6 4.9.2-10 ii libwebkitgtk-3.0-common 2.4.8-1 ii libwebp50.4.1-1.2+b2 ii libx11-62:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxfixes3 1:5.0.1-2+b2 ii libxml2 2.9.2+dfsg1-3 ii libxrender1 1:0.9.8-1+b1 ii libxslt1.1 1.1.28-2+b2 ii libxt6 1:1.1.4-1+b1 ii multiarch-support 2.19-16 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages libwebkitgtk-3.0-0 recommends: ii geoclue-2.02.1.10-2 ii gstreamer1.0-plugins-base 1.4.4-2 ii gstreamer1.0-plugins-good 1.4.4-2 libwebkitgtk-3.0-0 suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#773643: initramfs-tools: fsck.* not added to initrd image for mount by UUID or label with type=auto
Control: retitle -1 initramfs-tools: fsck.* not added to initrd image for mount by UUID or label with type=auto Am Montag, den 19.01.2015, 22:30 +0100 schrieb Paul Menzel: Am Montag, den 19.01.2015, 00:52 + schrieb Ben Hutchings: […] On Sun, 2015-01-18 at 23:47 +0100, Paul Menzel wrote: Am Sonntag, den 18.01.2015, 15:12 + schrieb Ben Hutchings: [...] I think I know why this is, but please can you send the fstab line for the root filesystem? Sure. UUID=2b45d72e-7bd8-490f-bd9e-7e5990859148 / auto discard,noatime,commit=600,defaults,errors=remount-ro 0 1 In `/etc/fstab` tabs instead of spaces are used. OK, this is the same as in #766448 and I have a fix for it. Awesome! I’ll try to test that patch this week I can confirm, that your patch fixes the problem. and corrected the title of this bug report. Unfortunately I failed at that. I’ll try again. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#773643: initramfs-tools: fsck.* not added to initrd image (Warning: couldn't identify filesystem type for fsck hook, ignoring.)
Control: title -1 initramfs-tools: fsck.* not added to initrd image (Warning: couldn't identify filesystem type for fsck hook, ignoring.) Am Montag, den 19.01.2015, 00:52 + schrieb Ben Hutchings: […] On Sun, 2015-01-18 at 23:47 +0100, Paul Menzel wrote: Am Sonntag, den 18.01.2015, 15:12 + schrieb Ben Hutchings: [...] I think I know why this is, but please can you send the fstab line for the root filesystem? Sure. UUID=2b45d72e-7bd8-490f-bd9e-7e5990859148 / auto discard,noatime,commit=600,defaults,errors=remount-ro 0 1 In `/etc/fstab` tabs instead of spaces are used. OK, this is the same as in #766448 and I have a fix for it. Awesome! I’ll try to test that patch this week and corrected the title of this bug report. […] Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#770390: Crash with SIGSEGV in `e_alert_response`
Package: evolution Version: 3.12.7-1 Severity: grave Tags: upstream fixed-upstream Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=739605 Dear Debian folks, Evolution crashes frequently with a segmentation fault. Program received signal SIGSEGV, Segmentation fault. 0xb7db5ef3 in e_alert_response (alert=0x891a9e70, response_id=-7) at e-alert.c:945 The issue has been fixed upstream, so it’d be great if the commit c0d144b (Remove alert buttons on the alert bar hide) [1] could be applied to the Debian version or if Evolution 3.12.8 could be included in Debian. Thanks, Paul [1] https://git.gnome.org/browse/evolution/commit/?id=c0d144b -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evolution depends on: ii dbus 1.8.10-1+auth1 ii debconf [debconf-2.0] 1.5.53 ii evolution-common 3.12.7-1 ii evolution-data-server 3.12.7.1-2 ii gnome-icon-theme 3.12.0-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcamel-1.2-493.12.7.1-2 ii libclutter-gtk-1.0-0 1.6.0-1 ii libecal-1.2-16 3.12.7.1-2 ii libedataserver-1.2-18 3.12.7.1-2 ii libevolution 3.12.7-1 ii libglib2.0-0 2.42.1-1 ii libgtk-3-0 3.14.5-1 ii libical1 1.0-1.1 ii libnotify4 0.7.6-2 ii libsoup2.4-1 2.48.0-1 ii libwebkitgtk-3.0-0 2.4.7-2 ii libxml22.9.2+dfsg1-1 ii psmisc 22.21-2 Versions of packages evolution recommends: ii bogofilter 1.2.4+dfsg1-3 ii evolution-plugins 3.12.7-1 ii spamassassin 3.4.0-3 ii yelp 3.14.1-1 Versions of packages evolution suggests: pn evolution-ews none ii evolution-plugins-experimental 3.12.7-1 ii gnupg 1.4.18-4 ii network-manager 0.9.10.0-3 -- debconf information excluded signature.asc Description: This is a digitally signed message part
Bug#762630: radiotray: Segmentation fault after upgrading GLib: Attempt to unlock mutex that was not locked
Control: retitle -1 radiotray: Segmentation fault after upgrading GLib: Attempt to unlock mutex that was not locked Control: forwarded -1 https://bitbucket.org/carlmig/radio-tray/issue/220 Control: tags -1 patch Dear Elías, thank you very much for your quick reply! Am Mittwoch, den 24.09.2014, 12:22 -0500 schrieb Elías Alejandro: Ubuntu seems that reported the same before[0], also attaching a patch[1]. and it was already reported to upstream[2]. Currently I'm using xfce can you please test that patch? just remove gtk.gdk.threads_init() from: src/SysTray.py. That indeed works! Thanks! Do you know if upstream is still active and will issue a new release? If not, it’d be great if you uploaded a new package with this patch applied. The second question is, how to continue as according to the Launchpad report [0] this is a bug in GLib. Thanks, Paul PS: Please make sure to remove the sub...@bugs.debian.org address when replying to the initial report. [0] https://bugs.launchpad.net/ubuntu/+source/radiotray/+bug/1359564 [1] https://launchpadlibrarian.net/183620304/SysTray.patch [2] https://bitbucket.org/carlmig/radio-tray/issue/220/crashed-with-attempt-to-unlock-mutex-that signature.asc Description: This is a digitally signed message part
Bug#762630: radiotray: Segmentation fault after upgrade to GNOME 3.14: Attempt to unlock mutex that was not locked
Package: radiotray Version: 0.7.3-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Debian folks, upgrading GNOME Shell from 3.12.2-3 to 3.13.92-1 (3.14-1) – and the related packages – RadioTray crashes with `SIGABRT`. The core dump file does not help. Core was generated by `/usr/bin/python /usr/bin/radiotray'. Program terminated with signal SIGABRT, Aborted. #0 0xb771dd4c in __kernel_vsyscall () (gdb) t a a bt Thread 1 (LWP 11731): #0 0xb771dd4c in __kernel_vsyscall () #1 0xb74d8267 in ?? () #2 0xb7651000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) The only error message I see is: `Attempt to unlock mutex that was not locked`. Thanks, Paul -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages radiotray depends on: ii gstreamer0.10-plugins-base 0.10.36-2 ii gstreamer0.10-plugins-good 0.10.31-3+nmu4 ii gstreamer0.10-plugins-ugly 0.10.19-2.1 ii python 2.7.8-1 ii python-dbus 1.2.0-2+b3 ii python-glade2 2.24.0-4 ii python-gobject 3.12.2-1 ii python-gst0.10 0.10.22-3 ii python-gtk2 2.24.0-4 ii python-lxml 3.4.0-1 ii python-notify 0.1.1-3 ii python-xdg 0.25-4 radiotray recommends no packages. radiotray suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#753648: network-manager: Connecting to an encrypted WLAN fails with `received an invalid or unencryptable secret`
Package: network-manager Version: 0.9.8.10-4 Severity: grave Justification: renders package unusable Dear Debian folks, after a restart of the system after the upgrade from NetworkManager 0.9.8.10-3 to 0.9.8.10.4, NetworkManager is unable to connect to an encrypted WLAN. `nm-applet` prints the message below to the terminal. ** Message: received an invalid or unencryptable secret Stopping NetworkManager with `sudo service network-manager stop` and using `wpa_supplicant` directly, the system can connect successfully. Thanks, Paul -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager depends on: ii adduser3.113+nmu3 ii dbus 1.8.6-1 ii init-system-helpers1.19 ii isc-dhcp-client4.3.0+dfsg-1 ii libc6 2.19-4 ii libdbus-1-31.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-3 ii libgnutls-deb0-28 3.2.15-2 ii libgudev-1.0-0 204-14 ii libmm-glib01.0.0-5+b1 ii libnl-3-2003.2.24-2 ii libnl-genl-3-200 3.2.24-2 ii libnl-route-3-200 3.2.24-2 ii libnm-glib40.9.8.10-4 ii libnm-util20.9.8.10-4 ii libpam-systemd 204-14 ii libpolkit-gobject-1-0 0.105-6 ii libsoup2.4-1 2.46.0-2 ii libsystemd-daemon0 204-14 ii libsystemd-login0 204-14 ii libuuid1 2.20.1-5.8 ii lsb-base 4.1+Debian13 ii policykit-10.105-6 ii udev 204-14 ii wpasupplicant 1.1-1 Versions of packages network-manager recommends: pn crda none ii dnsmasq-base 2.71-1 ii iptables 1.4.21-2 ii modemmanager 1.0.0-5+b1 ii ppp 2.4.6-2 Versions of packages network-manager suggests: pn avahi-autoipd none -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed [not included] -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#753648: [Pkg-utopia-maintainers] Bug#753648: network-manager: Connecting to an encrypted WLAN fails with `received an invalid or unencryptable secret`
Control: severity -1 normal Am Donnerstag, den 03.07.2014, 23:25 +0200 schrieb Michael Biebl: Am 03.07.2014 23:19, schrieb Paul Menzel: Package: network-manager Version: 0.9.8.10-4 Severity: grave Justification: renders package unusable after a restart of the system after the upgrade from NetworkManager 0.9.8.10-3 to 0.9.8.10.4, NetworkManager is unable to connect to an encrypted WLAN. `nm-applet` prints the message below to the terminal. ** Message: received an invalid or unencryptable secret Stopping NetworkManager with `sudo service network-manager stop` and using `wpa_supplicant` directly, the system can connect successfully. Please send me a debug log of NetworkManager. Instructions are at [1] NetworkManager[2304]: info Auto-activating connection 'MYSSID'. NetworkManager[2304]: info Activation (wlan0) starting connection 'MYSSID' NetworkManager[2304]: info (wlan0): device state change: disconnected - prepare (reason 'none') [30 40 0] NetworkManager[2304]: info NetworkManager state is now CONNECTING NetworkManager[2304]: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager[2304]: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... NetworkManager[2304]: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager[2304]: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. NetworkManager[2304]: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... NetworkManager[2304]: info (wlan0): device state change: prepare - config (reason 'none') [40 50 0] NetworkManager[2304]: info Activation (wlan0/wireless): access point 'MYSSID' has security, but secrets are required. NetworkManager[2304]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] NetworkManager[2304]: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. NetworkManager[2304]: warn No agents were available for this request. NetworkManager[2304]: info (wlan0): device state change: need-auth - failed (reason 'no-secrets') [60 120 7] NetworkManager[2304]: info NetworkManager state is now DISCONNECTED NetworkManager[2304]: info Marking connection 'MYSSID' invalid. NetworkManager[2304]: warn Activation (wlan0) failed for connection 'MYSSID' NetworkManager[2304]: info (wlan0): device state change: failed - disconnected (reason 'none') [120 30 0] NetworkManager[2304]: info (wlan0): deactivating device (reason 'none') [0] Looking at this, it looks like some layer is missing causing the message `warn No agents were available for this request`. Therefore I am downgrading the severity. No idea why it is not available. I’ll check again in the morning. Did you have multiple wpa_supplicant instances running or upgraded any other relevant packages? Not that I know of. Debian Sid/unstable is used and `aptitude update` and `aptitude safe-upgrade` are run daily. How do you store your WPA secrets, system-wide or in gnome-keyring? I am not sure, I guess GNOME Keyring though, as I did not see the passphrase in `/etc/NetworkManager/system-connections/MYSSID`. Thanks, Paul [1] https://wiki.gnome.org/Projects/NetworkManager/Debugging signature.asc Description: This is a digitally signed message part
Bug#746436: evolution-data-server: Unable to read any messages
Dear Jordi, thank you for your reply! Am Donnerstag, den 01.05.2014, 15:32 +0200 schrieb Jordi Mallach: On Wed, Apr 30, 2014 at 01:16:44AM +0200, Paul Menzel wrote: Package: evolution-data-server Version: 3.12.0-1 Severity: grave Tags: upstream Justification: renders package unusable Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=728976 Control: found -1 3.12.1-1 […] upgrading from Evolution Data Server 3.8.5 to 3.12.x it is impossible to read messages. They are not shown. Even building Evolution Data Server from the upstream branch `evolution-data-server-3-12` with the commit below does not help. commit 4615a98c7be1e3f8d23aa8a1c4f43b9d1fb62712 Author: Milan Crha mc...@redhat.com Date: Fri Apr 25 08:33:48 2014 +0200 Remove unused imapx_unmark_folder_subscribed() There are more issues like this reported in the GNOME Bugzilla, so spare Jessie/testing users from the regular Evolution upgrade pain until upstream fixes these issues. Thanks for the report. I wonder if you've tried with both e-d-s _and_ evolution from unstable, ie 3.12.1. There's a ton of bugfixes in there. Yes, I did try Evolution and E-D-S 3.12.0 and 3.12.1. It's interesting we've only got one bug report like this in Debian, I suppose most “mail power users”, i. e. users with over 10 accounts (POP and IMAP) and several hundred thousands of messages and those users probably using Debian Sid/unstable, moved away from Evolution a long time ago and I am the only masochist still using it. You are using Mutt too, if I am not mistaken. :P Point is, it is not surprising, that there are only a few reports as I believe most Evolution users do not know how to submit a bug report and just accept crashes and other flaws. so let's see if we can track it down fast and let eds migrate. I’ll try to help upstream to get these issues fixed, but I strongly believe the migration should wait until at least Evolution Data Server 3.12.2 is released. As you can see in the branch evolution-data-server-3-12 there are several critical fixes in there already. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#746436: evolution-data-server: Unable to read any messages
Package: evolution-data-server Version: 3.12.0-1 Severity: grave Tags: upstream Justification: renders package unusable Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=728976 Control: found -1 3.12.1-1 Dear Debian folks, upgrading from Evolution Data Server 3.8.5 to 3.12.x it is impossible to read messages. They are not shown. Even building Evolution Data Server from the upstream branch `evolution-data-server-3-12` with the commit below does not help. commit 4615a98c7be1e3f8d23aa8a1c4f43b9d1fb62712 Author: Milan Crha mc...@redhat.com Date: Fri Apr 25 08:33:48 2014 +0200 Remove unused imapx_unmark_folder_subscribed() There are more issues like this reported in the GNOME Bugzilla, so spare Jessie/testing users from the regular Evolution upgrade pain until upstream fixes these issues. As a workaround, downgrading the package `evolution-data-server` to the version in Jessie and leaving Evolution at 3.12.1 works for me. The downside is that several other GNOME packages have to be downgraded too. sudo aptitude -t testing install evolution-data-server=3.8.5-3 +b2 Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=728976 signature.asc Description: This is a digitally signed message part
Bug#745794: chromium: Missing build dependency on `libkrb5-dev` causes build errors and preventing Chromium 34 to enter unstable for i386
Package: chromium Version: 34.0.1847.116-2 Severity: grave Dear Debian folks, in Debian Sid/unstable with the architecture i386, Chromium is still at version 33 instead of 34 as for the architecture amd64. This is due to a build error on i386 [1]. g++ '-DV8_DEPRECATION_WARNINGS' '-D_FILE_OFFSET_BITS=64' '-DNO_TCMALLOC' '-DDISABLE_NACL' '-DCHROMIUM_BUILD' '-DUSE_CAIRO=1' '-DUSE_GLIB=1' '-DUSE_DEFAULT_RENDER_THEME=1' '-DUSE_LIBJPEG_TURBO=1' '-DUSE_NSS=1' '-DUSE_X11=1' '-DENABLE_ONE_CLICK_SIGNIN' '-DGTK_DISABLE_SINGLE_INCLUDES=1' '-DUSE_XI2_MT=2' '-DENABLE_REMOTING=1' '-DENABLE_WEBRTC=1' '-DUSE_PROPRIETARY_CODECS' '-DENABLE_PEPPER_CDMS' '-DENABLE_CONFIGURATION_POLICY' '-DENABLE_INPUT_SPEECH' '-DENABLE_NOTIFICATIONS' '-DUSE_UDEV' '-DENABLE_EGLIMAGE=1' '-DENABLE_TASK_MANAGER=1' '-DENABLE_EXTENSIONS=1' '-DENABLE_PLUGIN_INSTALLATION=1' '-DENABLE_PLUGINS=1' '-DENABLE_SESSION_SERVICE=1' '-DENABLE_THEMES=1' '-DENABLE_BACKGROUND=1' '-DENABLE_AUTOMATION=1' '-DENABLE_GOOGLE_NOW=1' '-DCLD_VERSION=2' '-DENABLE_FULL_PRINTING=1' '-DENABLE_PRINTING=1' '-DENABLE_SPELLCHECK=1' '-DENABLE_CAPTIVE_PORTAL_DETECTION=1' '-DENABLE_MANAGED_USERS=1' '-DENABLE_MDNS=1' '-DNET_IMPLEMENTATION' '-DUSE_KERBEROS' '-DDLOPEN_KERBEROS' '-DENABLE_BUILT_IN_DNS' '-DU_USING_ICU_NAMESPACE=0' '-DU_STATIC_IMPLEMENTATION' '-DUSE_GCONF' '-DUSE_GIO' '-D__STDC_CONSTANT_MACROS' '-D__STDC_FORMAT_MACROS' '-DNDEBUG' '-DNVALGRIND' '-DDYNAMIC_ANNOTATIONS_ENABLED=0' '-D_FORTIFY_SOURCE=2' -I. -Isdch/open-vcdiff/src -Ithird_party/icu/source/i18n -Ithird_party/icu/source/common -Ithird_party/zlib -Iout/Release/obj/gen/net -Iout/Release/obj/gen -Inet/third_party/nss/ssl -fstack-protector --param=ssp-buffer-size=4 -pthread -fno-exceptions -fno-strict-aliasing -Wall -Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe -fPIC -Wno-unused-local-typedefs -pthread -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/harfbuzz -pthread -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/nss -I/usr/include/nspr -pthread -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/libdrm -m32 -mmmx -O2 -fno-ident -fdata-sections -ffunction-sections -funwind-tables -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare -MMD -MF out/Release/.deps/out/Release/obj.target/net/net/http/failing_http_transaction_factory.o.d.raw -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o out/Release/obj.target/net/net/http/failing_http_transaction_factory.o net/http/failing_http_transaction_factory.cc g++ '-DV8_DEPRECATION_WARNINGS' '-D_FILE_OFFSET_BITS=64' '-DNO_TCMALLOC' '-DDISABLE_NACL' '-DCHROMIUM_BUILD' '-DUSE_CAIRO=1' '-DUSE_GLIB=1' '-DUSE_DEFAULT_RENDER_THEME=1' '-DUSE_LIBJPEG_TURBO=1' '-DUSE_NSS=1' '-DUSE_X11=1' '-DENABLE_ONE_CLICK_SIGNIN' '-DGTK_DISABLE_SINGLE_INCLUDES=1' '-DUSE_XI2_MT=2' '-DENABLE_REMOTING=1' '-DENABLE_WEBRTC=1' '-DUSE_PROPRIETARY_CODECS' '-DENABLE_PEPPER_CDMS' '-DENABLE_CONFIGURATION_POLICY' '-DENABLE_INPUT_SPEECH' '-DENABLE_NOTIFICATIONS' '-DUSE_UDEV' '-DENABLE_EGLIMAGE=1' '-DENABLE_TASK_MANAGER=1' '-DENABLE_EXTENSIONS=1' '-DENABLE_PLUGIN_INSTALLATION=1' '-DENABLE_PLUGINS=1' '-DENABLE_SESSION_SERVICE=1' '-DENABLE_THEMES=1' '-DENABLE_BACKGROUND=1' '-DENABLE_AUTOMATION=1' '-DENABLE_GOOGLE_NOW=1' '-DCLD_VERSION=2' '-DENABLE_FULL_PRINTING=1' '-DENABLE_PRINTING=1' '-DENABLE_SPELLCHECK=1' '-DENABLE_CAPTIVE_PORTAL_DETECTION=1' '-DENABLE_MANAGED_USERS=1' '-DENABLE_MDNS=1' '-DNET_IMPLEMENTATION' '-DUSE_KERBEROS' '-DDLOPEN_KERBEROS' '-DENABLE_BUILT_IN_DNS' '-DU_USING_ICU_NAMESPACE=0' '-DU_STATIC_IMPLEMENTATION' '-DUSE_GCONF' '-DUSE_GIO' '-D__STDC_CONSTANT_MACROS' '-D__STDC_FORMAT_MACROS' '-DNDEBUG' '-DNVALGRIND' '-DDYNAMIC_ANNOTATIONS_ENABLED=0' '-D_FORTIFY_SOURCE=2' -I. -Isdch/open-vcdiff/src -Ithird_party/icu/source/i18n -Ithird_party/icu/source/common -Ithird_party/zlib -Iout/Release/obj/gen/net -Iout/Release/obj/gen -Inet/third_party/nss/ssl -fstack-protector --param=ssp-buffer-size=4 -pthread -fno-exceptions
Bug#736880: gdm3 does not work in Gnome Flashback mode
Dear Andreas, dear Svante, Am Dienstag, den 28.01.2014, 00:50 +0100 schrieb Andreas Cadhalpun: Hi Svante, On 27.01.2014 22:58, Svante Signell wrote: gdm3 does not work in Gnome Flashback mode, this is the fourth computer showing the problem, forcing me to switch to xfce :( After logging in I have icewaesel present in all workspaces, and iconizing it fails, the screen is filled with lines indicating a movement of the full-screen icewasel to iconized status, but the window stays (showing the transition which never completes. The problem is related to systemd, see below, row 4! I don't use systemd for boot (and never will unless forced). Converting this box to xfce too after submitting this bug report. Thanks for digging out, what the problem is. As your log indicates, this might very well be another problem due to the missing dependency of gnome-settings-daemon on 'systemd-shim | systemd-sysv' [1]. Since you do not want to switch your init system (which would happen, if you installed systemd-sysv), I recommend you to install systemd-shim, which works independently of the init system in use. Please report back, if this fixes the problem. Installing `systemd-shim` indeed fixes this problem on my system with Debian Sid/unstable and an Nvidia graphics card and the Nouveau driver which currently does not support hardware acceleration. Svante, thank you for submitting this report even though you already knew you’ll are going to change to different software. Andreas, thank you for the answer with the solution. Too bad updated packages were not updated yet. Thanks, Paul 1: bugs.debian.org/726763 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726957: initramfs-tools: Please include `ohci-pci` after `ohci-hcd` split to use USB keyboard to enter LUKS password
Package: initramfs-tools Version: 0.114 Severity: critical Justification: breaks the whole system Control: affects -1 linux-image-3.11-1-amd64 Dear Debian folks, upgrading to `linux-image-3.11-1-amd64` I was not able to enter the LUKS password while it works without problems using `linux-image-3.10-3-amd64`. benh told me in #debian-kernel on irc.oftc.net, that it is probably due to the split of the Linux module `ohci-hcd` and the module `ohci-pci` is required in initramfs for using the USB keyboard. It would be awesome if you could add it (also for Debian Backports). I will be able to test the fix on Monday or Tuesday. Thanks, Paul -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 9.4M May 7 2009 /boot/initrd.img-2.6.29-1-amd64 -rw-r--r-- 1 root root 9.3M May 1 2009 /boot/initrd.img-2.6.29-1-amd64.bak -rw-r--r-- 1 root root 9.6M Jun 20 2009 /boot/initrd.img-2.6.29-2-amd64 -rw-r--r-- 1 root root 9.4M May 26 2009 /boot/initrd.img-2.6.29-2-amd64.bak -rw-r--r-- 1 root root 11M Feb 23 2013 /boot/initrd.img-2.6.32-5-686 -rw-r--r-- 1 root root 11M Feb 23 2013 /boot/initrd.img-2.6.32-5-amd64 -rw-r--r-- 1 root root 14M Sep 23 18:00 /boot/initrd.img-3.10-3-686-pae -rw-r--r-- 1 root root 14M Sep 23 19:23 /boot/initrd.img-3.10-3-amd64 -rw-r--r-- 1 root root 26M Oct 19 11:17 /boot/initrd.img-3.10.0+ -rw-r--r--. 1 root root 26M Jun 21 09:27 /boot/initrd.img-3.10.0-rc6+ -rw-r--r--. 1 root root 26M Jun 29 12:15 /boot/initrd.img-3.10.0-rc7+ -rw-r--r-- 1 root root 13M Oct 12 20:30 /boot/initrd.img-3.2.0-4-686-pae -rw-r--r-- 1 root root 13M Oct 12 20:31 /boot/initrd.img-3.2.0-4-amd64 -rw-r--r-- 1 root root 25M Jul 31 2012 /boot/initrd.img-3.5.0+ -rw-r--r-- 1 root root 26M Dec 13 2012 /boot/initrd.img-3.7.0+ -rw-r--r-- 1 root root 26M Dec 21 2012 /boot/initrd.img-3.7.1 -rw-r--r-- 1 root root 26M Jan 25 2013 /boot/initrd.img-3.7.1+ -rw-r--r-- 1 root root 26M May 18 20:06 /boot/initrd.img-3.7.5+ -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.10-3-686-pae root=/dev/mapper/speicher-root ro rdinitrd=/sbin/bootchartd initcall_debug printk.time=y init=/sbin/bootchartd drm_kms_helper.poll=0 drm.debug=0x06 quiet noisapnp console=ttyS0,115200 console=tty0 pcie_aspm=force pcie_aspm.policy=powersave -- resume RESUME=/dev/mapper/speicher-swap -- /proc/filesystems btrfs ext3 fuseblk xfs reiserfs -- lsmod Module Size Used by arc4 12487 2 rt2800usb 17747 0 rt2x00usb 13392 1 rt2800usb rt2800lib 55996 1 rt2800usb rt2x00lib 37589 3 rt2x00usb,rt2800lib,rt2800usb mac80211 309057 3 rt2x00lib,rt2x00usb,rt2800lib cfg80211 264217 2 mac80211,rt2x00lib crc_ccitt 12331 1 rt2800lib rfkill 18706 3 cfg80211 ip6table_filter12492 0 ip6_tables 17022 1 ip6table_filter iptable_filter 12488 0 ip_tables 17010 1 iptable_filter x_tables 18124 4 ip6table_filter,ip_tables,iptable_filter,ip6_tables binfmt_misc12789 1 reiserfs 177128 1 xfs 553122 2 hwmon_vid 12398 0 loop 18067 0 firewire_sbp2 17632 0 firewire_core 39334 1 firewire_sbp2 crc_itu_t 12331 1 firewire_core fuse 61469 1 snd_hda_codec_realtek31992 1 snd_hda_codec_hdmi 31192 1 snd_hda_intel 31021 5 snd_hda_codec 102848 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel snd_hwdep 12939 1 snd_hda_codec snd_pcm_oss36297 0 snd_mixer_oss 17770 1 snd_pcm_oss snd_pcm57885 4 snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel snd_page_alloc 12910 2 snd_pcm,snd_hda_intel snd_seq_midi 12744 0 snd_seq_midi_event 13124 1 snd_seq_midi snd_rawmidi22551 1 snd_seq_midi powernow_k817256 1 snd_seq39569 2 snd_seq_midi_event,snd_seq_midi snd_seq_device 13016 3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer 22217 2 snd_pcm,snd_seq evdev 17266 13 psmouse64900 0 serio_raw 12812 0 i2c_viapro 12480 0 k8temp 12631 0 snd42832 22 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss radeon621535 4 shpchp 26762 0 ttm52618 1 radeon soundcore 12890 1 snd drm_kms_helper 27237 1 radeon drm 165528 6 ttm,drm_kms_helper,radeon processor 27839 1 powernow_k8 i2c_algo_bit 12713 1 radeon i2c_core 19505 5 drm,drm_kms_helper,i2c_algo_bit,i2c_viapro,radeon parport_pc
Bug#725665: closed by Andreas Henriksson andr...@fatal.se (Bug#725665: fixed in nautilus-python 1.1-4)
Dear Andreas, Am Mittwoch, den 09.10.2013, 22:21 + schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the python-nautilus package: #725665: python-nautilus: ImportError: could not import gobject (could not find _PyGObject_API object) It has been closed by Andreas Henriksson andr...@fatal.se. upgrading to python-nautilus 1.1-4 indeed fixed this problem! Thanks a million, Paul signature.asc Description: This is a digitally signed message part
Bug#703539: Upgrade fails with `/etc/grub.d/10_hurd: line 22: /usr/lib/grub/update-grub_lib: No such file or directory`
Package: grub-pc Version: 2.00-13 Severity: grave Justification: renders package unusable Dear Debian folks, upgrading from package grub-pc 1.99-27 to 2.00-13 fails with the following error. $ sudo aptitude install -t experimental grub-pc Die folgenden Pakete werden aktualisiert: grub-common grub-pc grub-pc-bin grub2-common 4 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 993 nicht aktualisiert. 3.112 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 3.642 kB zusätzlich belegt sein. Möchten Sie fortsetzen? [Y/n/?] Holen: 1 http://http.debian.net/debian/ experimental/main grub-pc i386 2.00-13 [169 kB] Holen: 2 http://http.debian.net/debian/ experimental/main grub2-common i386 2.00-13 [116 kB] Holen: 3 http://http.debian.net/debian/ experimental/main grub-pc-bin i386 2.00-13 [800 kB] Holen: 4 http://http.debian.net/debian/ experimental/main grub-common i386 2.00-13 [2.028 kB] 3.112 kB wurden in 12 s heruntergeladen (240 kB/s) Laden der Fehlerberichte ... Erledigt »Found/Fixed«-Informationen werden ausgewertet ... Erledigt Lese Changelogs... Fertig Vorkonfiguration der Pakete ... (Lese Datenbank ... 530982 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Ersetzen von grub-pc 1.99-27 (durch .../grub-pc_2.00-13_i386.deb) ... Ersatz für grub-pc wird entpackt ... Vorbereitung zum Ersetzen von grub-pc-bin 1.99-27 (durch .../grub-pc-bin_2.00-13_i386.deb) ... Ersatz für grub-pc-bin wird entpackt ... Vorbereitung zum Ersetzen von grub2-common 1.99-27 (durch .../grub2-common_2.00-13_i386.deb) ... Ersatz für grub2-common wird entpackt ... Vorbereitung zum Ersetzen von grub-common 1.99-27 (durch .../grub-common_2.00-13_i386.deb) ... Ersatz für grub-common wird entpackt ... Trigger für man-db werden verarbeitet ... Trigger für install-info werden verarbeitet ... grub-common (2.00-13) wird eingerichtet ... Neue Version der Konfigurationsdatei /etc/grub.d/20_linux_xen wird installiert ... Neue Version der Konfigurationsdatei /etc/grub.d/30_os-prober wird installiert ... Neue Version der Konfigurationsdatei /etc/grub.d/00_header wird installiert ... Neue Version der Konfigurationsdatei /etc/grub.d/10_linux wird installiert ... Neue Version der Konfigurationsdatei /etc/grub.d/05_debian_theme wird installiert ... Neue Version der Konfigurationsdatei /etc/grub.d/41_custom wird installiert ... So `10_hurd` is not touched? See below. grub2-common (2.00-13) wird eingerichtet ... grub-pc-bin (2.00-13) wird eingerichtet ... grub-pc (2.00-13) wird eingerichtet ... Neue Version der Konfigurationsdatei /etc/kernel/postinst.d/zz-update-grub wird installiert ... Neue Version der Konfigurationsdatei /etc/kernel/postrm.d/zz-update-grub wird installiert ... grub.cfg wird erstellt … /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen.. The above might be due to a misseing drive in a RAID 1 array. Found background image: .background_cache.png /etc/grub.d/10_hurd: Zeile 22: /usr/lib/grub/update-grub_lib: Datei oder Verzeichnis nicht gefunden Above is the error. dpkg: Fehler beim Bearbeiten von grub-pc (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert
Bug#594753: brasero: Brasero burns corrupted data DVDs.
Dear Vincent, thank you for following up on this report. Am Samstag, den 17.11.2012, 00:56 +0100 schrieb Vincent Lefevre: On 2012-10-12 13:23:20 +0200, Paul Menzel wrote: Am Dienstag, den 20.12.2011, 01:49 +0100 schrieb Vincent Lefevre: I've burnt a data DVD with brasero and got no errors (except that the DEBUG messages in the terminal were inconsistant with the dialog: when a DEBUG message said X %, it was actually X/2 % in the dialog... now, I don't know whether this is related to this bug). But when I want to mount it, I get: mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so [...] I am pretty sure this #688229 [2] which is fixed in Brasero 3.4.1-4. Could you please test these packages? I still get the same mount error with a DVD burnt using brasero 3.4.1-4 if I use the -t udf mount option. Without it, the DVD can be read normally. No such problem when I burn the DVD with growisofs -R -J -udf. The -t udf is necessary with some DVD's, otherwise I get corrupt data and also private directories readable by everyone. So, it should really be supported. LStranger in #lxde told me the same some days ago. Unfortunately I have no clue and do not understand that, as you wrote it works fine *without* -udf. As this is a different issue than the one from the original reporter, could you please submit a separate report for it also describing exactly the steps you are doing to burn the DVD (including what plugins) and attaching the log files created with the following command. $ brasero -g | tee `date +%Y%m%d-%H%M`--brasero.log This is important as looking at Brasero’s source code I thought it is also passing `-udf` to growisofs/genisoimage. We have to find out what command is actually used to compose the image. Unfortunately upstream is not maintained currently, but I hope somebody will step up and provide a fix. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#692317: [solved] dh-autoreconf_clean deletes unrelated files (due to spaces?)
Control: tags 692317 patch
Dear Stefan,
Am Mittwoch, den 07.11.2012, 16:20 +0100 schrieb Stefan Bühler:
I think you're right - the spaces in the filenames lead to problems:
dh_autoreconf_clean uses the perl split function to split the lines
into checksum and filename:
* a comment says the delimiter is comma, which is wrong: there are two
spaces between checksum and filename
* split splits by default at /\s+/ - and returns as many components it finds
Fix it by replacing *both* split calls with:
my ($checksum, $filename) = split(/\s+/, $_, 2);
It uses the same delimiter, but only splits at the first one (returning
at most two parts).
(Also you probably should fix the comment)
thank you for your reply and your great analysis and fix. I paste the
patch below. Julian, you can just save this message and apply it with
`git am --scissors this-message.mbox`.
@Paul: I couldn't completely check whether my fix works, because I
didn't want to install the dependencies.
I tested it by running `debuild clean` which invokes
`dh_autoreconf_clean` and the file was not deleted. Awesome!
Also shallow git clone doesn't work, as it is probably stored as one
index file which gets downloaded completely.
Hmm, strange. I have not much knowledge though as I mostly check out the
whole tree.
Thanks,
Paul
--- 8 8 ---
From f14333020d7b157a8f9fed6c18859656ef56 Mon Sep 17 00:00:00 2001
From: Paul Menzel pm.deb...@googlemail.com
Date: Wed, 7 Nov 2012 16:41:30 +0100
Subject: [PATCH] dh_autoreconf_clean: Fix handling of files with spaces in
their names (Closes: #692317)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
dh_autoreconf_clean uses the perl split function to split the lines
into checksum and filename:
• A comment says the delimiter is comma, which is wrong: there are two
spaces between checksum and filename.
• `split` splits by default at `/\s+/` and returns as many components it
finds
Fix it by replacing *both* split calls with the following.
my ($checksum, $filename) = split(/\s+/, $_, 2)
It uses the same delimiter, but only splits at the first one (returning
at most two parts).
Analysis-and-Fix-by: Stefan Bühler stbueh...@lighttpd.net
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692317#10
Tested-by: Paul Menzel pm.deb...@googlemail.com
Closes: http://bugs.debian.org/692317
---
dh_autoreconf_clean |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dh_autoreconf_clean b/dh_autoreconf_clean
index 8d399d9..8fd9c34 100755
--- a/dh_autoreconf_clean
+++ b/dh_autoreconf_clean
@@ -43,8 +43,8 @@ open(FILE, 'debian/autoreconf.before') or die($!);
while(FILE) {
chomp($_);
-# The delimiter here is a comma
-my ($checksum, $filename) = split;
+# The delimiter here is two spaces
+my ($checksum, $filename) = split(/\s+/, $_, 2);
# Put the key = value pair in the hash
$file{$filename} = $checksum;
}
@@ -56,7 +56,7 @@ open(FILE, 'debian/autoreconf.after') or die($!);
my $ltcheck = ;
while(FILE) {
chomp($_);
-my ($checksum, $filename) = split;
+my ($checksum, $filename) = split(/\s+/, $_, 2);
if ($filename eq /usr/share/libtool/config/ltmain.sh) {
$ltcheck = $checksum;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#692317: dh-autoreconf_clean deletes unrelated files (due to spaces?)
Package: dh-autoreconf Version: 6 Severity: grave Justification: causes non-serious data loss Dear Debian folks, doing $ git clone git://git.gnome.org/evolution # leave out history by adding `--depth 1` $ git checkout gnome-3-4 $ ./autogen.sh $ cd .. $ git svn clone svn://anonscm.debian.org/svn/pkg-evolution/unstable/evolution evolution-debian $ cd evolution $ ln -s ../evolution-debian/debian debian $ dch $ debuild -b -us -uc # just build binary packages the file `mail/mail-autoconfig/gmail.com` is deleted when `dh_autoreconf_clean` is run. The deleted files do not show up when comparing `autoreconf.before` and `autoreconf.after`. $ diff -u debian/autoreconf.before debian/autoreconf.after --- autoreconf.before 2012-11-02 14:48:32.432290260 +0100 +++ autoreconf.after2012-11-02 14:49:22.214684821 +0100 @@ -19,14 +19,14 @@ 4e2c1f37327f97f453319eb72eb5cb36 ./m4/visibility.m4 669ca5165f0efe0c7113051e438a2879 ./m4/wchar_t.m4 2875005749c1989cdec2e53a8af9795f ./m4/xsize.m4 +122529c078565850c5e52a9cf371974d ./m4/intltool.m4 +906048948cfd91807c29f0e81d09a69f ./m4/gtk-doc.m4 +a9ebc12cd611eb9024fc8219f26d00b2 ./m4/gnome-doc-utils.m4 e64c9570dc02541f6d911d282f3cfdb4 ./m4/libtool.m4 67d5ebceaac562ddf0dde4e5cdffbe09 ./m4/ltoptions.m4 bc2f6032c98896249eadb56177c7d357 ./m4/ltsugar.m4 91dd5e1355d100dbdab7d71244ed2625 ./m4/ltversion.m4 47d420a13f9ba4e171772c3e3eee3e63 ./m4/lt~obsolete.m4 -122529c078565850c5e52a9cf371974d ./m4/intltool.m4 -906048948cfd91807c29f0e81d09a69f ./m4/gtk-doc.m4 -a9ebc12cd611eb9024fc8219f26d00b2 ./m4/gnome-doc-utils.m4 432508be059cd84536a9d1ea610ca54b ./m4/Makefile.in 63141118a332dfa04cd26bcf8d7c7173 ./m4/codeset.m4 dab0e2ad4943514530c50faef831db6a ./m4/gettext.m4 @@ -914,6 +914,7 @@ 465182d6d4919f547b642876a1cbf817 ./mail/em-account-editor.h 51a467dbc1abf32e81c014fc7d8642a2 ./mail/em-sync-stream.h 002d4bf5bcae1a7574a8336d9aa71c3a ./mail/e-mail-tag-editor.h +15bef0b9e58ca499cba810d4a20e46d3 ./mail/Makefile.in e0846ac101fdaada8d85bba6f4366b04 ./mail/e-mail-account-manager.c ea1dc9ce879203c9a5c95830aa40e1f3 ./mail/e-mail-migrate.c d3195e091f3d2204deec492d1fd84666 ./mail/e-mail-paned-view.h @@ -954,7 +955,6 @@ 6119c599b1393a791ae776e05bfbbb1d ./mail/Makefile.am d595450a3d664402ad1a8bd530bdcbc3 ./mail/em-config.h f3d2a5d093e1ab29539feeddac51c9e5 ./mail/mail-send-recv.c -15bef0b9e58ca499cba810d4a20e46d3 ./mail/Makefile.in 9b65ec3bd1248cdf05a1a8398588b75b ./mail/mail-send-recv.h d0c0c5f4ed5409ea63f8c334c3d2d03a ./mail/em-format-html-print.h c57610cb21c8d7f955c20b8431ddc31d ./mail/mail-dialogs.ui @@ -1584,6 +1584,7 @@ 5d1299da431fd567a19f07c156046242 ./calendar/gui/e-calendar-view.h efd406335e788b0156f052a148cd3feb ./calendar/gui/ea-cal-view-event.c 43c66438766e304be22ebb858a03686b ./calendar/gui/ea-cal-view-event.h +2ca739faf848c5e9331d9f89c5af1d3b ./calendar/gui/Makefile.in de9e0433e98c99ec6c32bb9f1cbd5885 ./calendar/gui/comp-util.c 52d8e80f050ce80bae6c0b9b0453e836 ./calendar/gui/e-date-time-list.c d88710889e02162a755c1d42ca253d92 ./calendar/gui/e-date-time-list.h @@ -1612,7 +1613,6 @@ a115f51bce06a06a8025274cf2b33fc3 ./calendar/gui/e-memo-list-selector.c d2aae0bb3a92bbba24f9034fb9209dbc ./calendar/gui/e-memo-list-selector.h 5a2250ce3ea0eabbe034fefe184d4bd1 ./calendar/gui/misc.c -2ca739faf848c5e9331d9f89c5af1d3b ./calendar/gui/Makefile.in 17d4bcb0921f4e43c0ca677a27dab2bf ./calendar/gui/e-week-view-main-item.c a49a3b6675f985353aa535ad0ce5b0ce ./calendar/gui/e-week-view-main-item.h 36abe7a0a2bdb5b36ea6ca80ea93dd2d ./calendar/gui/ea-calendar.c @@ -1835,12 +1835,12 @@ 3f695737f8a4bb6b680e5a7f746998a6 ./modules/addressbook/e-book-shell-sidebar.c 05e24dce4a674d7ee5107c6271dff2e8 ./modules/addressbook/e-book-shell-view-private.c 7c741c6a29262a40fb7baddccbb76583 ./modules/addressbook/e-book-shell-view-private.h +5e905e2577c19a03e0560bb587cd8bff ./modules/addressbook/Makefile.in f5f84a6e4a57d49e33df41a69c1eed76 ./modules/addressbook/ldap-config.ui 4b6958843889abc2603a976addd73019 ./modules/addressbook/addressbook-config.h b555d443fca7a31e296c6aec8cce8882 ./modules/addressbook/autocompletion-config.h 67759ec62d152739847afe89a4d57cc8 ./modules/addressbook/e-book-shell-content.c 71bb19e63e8ff5d4df9fd04fc75d4375 ./modules/addressbook/e-book-shell-view-actions.c -5e905e2577c19a03e0560bb587cd8bff
Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Am Donnerstag, den 11.10.2012, 13:34 +0200 schrieb Paul Menzel: Am Donnerstag, den 11.10.2012, 13:31 +0200 schrieb Yves-Alexis Perez: On jeu., 2012-10-11 at 13:00 +0200, Paul Menzel wrote: thank you for verifying this. I wonder though why LightDM cannot use /usr/bin/Xorg while GDM is able to. Did you try (put xserver-command=Xorg in lightdm.conf) ? No, I did not try that. I will try to do so, thanks for the pointer! I did lightdm/lightdm.conf: Try `Xorg` to not need `xserver-xorg` [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688756 --- diff --git a/lightdm/lightdm.conf b/lightdm/lightdm.conf index 264b2bb..ed40001 100644 --- a/lightdm/lightdm.conf +++ b/lightdm/lightdm.conf @@ -55,7 +55,7 @@ # exit-on-failure = True if the daemon should exit if this seat fails # [SeatDefaults] -#xserver-command=X +xserver-command=Xorg #xserver-layout= #xserver-config= xserver-allow-tcp=false and logging out or restarting the system started LightDM up as expected. So I think it is safe to implement that change. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#594753: Issues with Brasero 3.x (was: Cdrtools instead of libburnia)
Dear Debian Brasero 3.x users, I am CCing you all, but just reply to Tsu’s last message. Unfortunately all of your replies are not threaded correctly increasing work for the maintainers and people wanting to help. In the future, it would be awesome if you could follow the guide in the Wiki [1]. Please make sure to always CC all people involved in the bug thread. I am pretty sure for all the people following up here having issues with Brasero 3.x are experiencing bug #688229 [4]. Am Montag, den 10.09.2012, 18:58 +0430 schrieb Tsu Jan: The bug may be related to how Brasero uses libburnia+libisofs. For those with 3.x, it indeed was such a bug [2] and it is fixed now [3][4]. It would be helpful if you could test Brasero 3.4.1-4. Please start it with $ brasero -g | tee `date +%Y%m%d-%H%M`--brasero.log to capture the debugging output too. Debugging logs are important as otherwise nothing can be done about a bug. If you are still experiencing some issue, please submit a new report with the above log attached. […] Thanks, Paul [1] http://wiki.debian.org/BTS/FollowUpOnReports#preview [2] https://bugzilla.gnome.org/show_bug.cgi?id=685983 [3] http://git.gnome.org/browse/brasero/commit/?id=253031b69c5dcbcf079c445ec530afb7ccd9ea82 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229 signature.asc Description: This is a digitally signed message part
Bug#594753: Incorrectly created image file
Dear Nyizsnyik, thank you for following up on the report and sorry for not having answered earlier. It would be great if you could follow the Wiki page [1] on how to follow up on bug reports. Am Donnerstag, den 09.12.2010, 16:50 +0100 schrieb Nyizsnyik Ferenc: The problem also affects data CD projects. The image isn't created correctly in the first place. Are you sure this is the problem for the original reporter too? It is 2097152 bytes long no matter how many files I add to the project (12 MB or 623 MB). So you are *not* using on the fly but write the image to disk beforehand? When I create an image with genisoimage, and then burn that image with Brasero, the CD will be created without problems and it will be readable. Thanks for checking. Brasero version is 2.30.3. I suspect you are seeing upstream bug 630651 [2]. Could you please try the upstream patch? Make sure to also apply the patch for the patch [3]. Testing would be very much appreciated to upload a fixed package for Debian Squeeze. Thanks, Paul [1] http://wiki.debian.org/BTS/FollowUpOnReports [2] https://bugzilla.gnome.org/show_bug.cgi?id=630651 [3] https://bugzilla.gnome.org/show_bug.cgi?id=685983 signature.asc Description: This is a digitally signed message part
Bug#594753: brasero: Brasero burns corrupted data DVDs.
Dear Vincent, thank you for following up on the report. Please make sure in the future to follow the instructions documented in the Debian Wiki [1]. Am Dienstag, den 20.12.2011, 01:49 +0100 schrieb Vincent Lefevre: Package: brasero Version: 3.2.0-3 Followup-For: Bug #594753 I've burnt a data DVD with brasero and got no errors (except that the DEBUG messages in the terminal were inconsistant with the dialog: when a DEBUG message said X %, it was actually X/2 % in the dialog... now, I don't know whether this is related to this bug). But when I want to mount it, I get: mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so and dmesg says: [ 4799.072383] UDF-fs: No anchor found [ 4799.072388] UDF-fs: No partition found (1) DVD's burnt on my old Mac don't have this problem. My machine is a DELL Latitude E6400 with: […] I am pretty sure this #688229 [2] which is fixed in Brasero 3.4.1-4. Could you please test these packages? Thanks, Paul [1] http://wiki.debian.org/BTS/FollowUpOnReports [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229 signature.asc Description: This is a digitally signed message part
Bug#688756: Bug#688756: Bug#688756: Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Dear Yves-Alexis, Am Donnerstag, den 11.10.2012, 12:43 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 16:00 +0200, Yves-Alexis Perez wrote: On mar., 2012-09-25 at 15:44 +0200, Paul Menzel wrote: Please find it attached. Alright, reading the error message again, `/usr/bin/X` is not installed as it is in `xserver-xorg` `lightdm` only recommends. 1. Is that due to that LightDM can also be used from remote? Yes, I think so. 2. Since GDM can start fine without `/usr/bin/X`, LightDM should also be able to? Please proceed as you want with this report. I am sorry for the noise. Well, even though lightdm might not need a hard dependency on xserver-xorg, I think lightdm-gtk-greeter might need it, so I'm keeping it open for now. Ok, X is run by lightdm itself, not the greeter, which has nothing to do with this. Recommends: is enough to cover the most common setups and still allow for more uncommon ones, so closing. thank you for verifying this. I wonder though why LightDM cannot use /usr/bin/Xorg while GDM is able to. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt:
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size) ==
sector_size) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
As already spoilered in my reply to #690207 [1], with the libburn output
patch attached it confirms that half of the bytes are missing.
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature
end of input encountered. Missing: 48709632 bytes
These are around 47 MB and indeed comparing the sizes yields the
following.
$ du -sh folder
94M /home/joey/folder
$ du -sh /tmp/my_emulated_drive
47M /tmp/my_emulated_drive
So all the bugs seem to be the same and Brasero just displays the error
differently or it is not noticeable with smaller amounts that the
progress bar stopped earlier.
I will try to cook up a patch for fixing the loop now.
Thanks,
Paul
[1] http://bugs.debian.org/690207
signature.asc
Description: This is a digitally signed message part
Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Am Donnerstag, den 11.10.2012, 13:31 +0200 schrieb Yves-Alexis Perez: On jeu., 2012-10-11 at 13:00 +0200, Paul Menzel wrote: thank you for verifying this. I wonder though why LightDM cannot use /usr/bin/Xorg while GDM is able to. Did you try (put xserver-command=Xorg in lightdm.conf) ? No, I did not try that. I will try to do so, thanks for the pointer! Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 13:19 +0200 schrieb Paul Menzel:
Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt:
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size)
== sector_size) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
As already spoilered in my reply to #690207 [1], with the libburn output
patch attached it confirms that half of the bytes are missing.
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature
end of input encountered. Missing: 48709632 bytes
These are around 47 MB and indeed comparing the sizes yields the
following.
$ du -sh folder
94M /home/joey/folder
$ du -sh /tmp/my_emulated_drive
47M /tmp/my_emulated_drive
So all the bugs seem to be the same and Brasero just displays the error
differently or it is not noticeable with smaller amounts that the
progress bar stopped earlier.
I will try to cook up a patch for fixing the loop now.
It looks like it is as simple as the following.
diff --git a/plugins/libburnia/burn-libisofs.c
b/plugins/libburnia/burn-libisofs.c
index 3c25224..3919281 100644
--- a/plugins/libburnia/burn-libisofs.c
+++ b/plugins/libburnia/burn-libisofs.c
@@ -199,7 +199,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs
*self)
BRASERO_JOB_LOG (self, Writing to pipe with sector size %i bytes,
sector_size);
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
- while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size)
== sector_size) {
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
I am building it right now.
Thanks,
Paul
[1] http://bugs.debian.org/690207
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 15:06 +0200 schrieb Thomas Schmitt:
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
That helped. After taking some time to figure out that I had not
actually installed the build patched packages, it *worked* indeed!
Brasero even plays a sound on success.
Mounting the image works and just for completeness here is the ISO9660
header(?).
$ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c
1+0 Datensätze ein
1+0 Datensätze aus
2048 Bytes (2,0 kB) kopiert, 0,000105318 s, 19,4 MB/s
000 001 C D 0 0 1 001 \0
020
040 D a t e n - C D
060 / D V D ( 1 1 O k t 1 2 )
100 \0 \0 \0 \0 \0 \0 \0 \0
120 317 271 \0 \0 \0 \0 271 317 \0 \0 \0 \0 \0 \0 \0 \0
140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
160 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 001 001 \0 \0 001
200 \0 \b \b \0 030 \0 \0 \0 \0 \0 \0 030 030 \0 \0 \0
220 \0 \0 \0 \0 \0 \0 \0 031 \0 \0 \0 \0 \0 023 \0
240 \0 \0 \0 \0 \0 023 \0 \b \0 \0 \0 \0 \b \0 p \n
260 \v \r 032 / \0 002 \0 \0 001 \0 \0 001 001 \0 D a
300 t e n - C D / D V D ( 1 1 O
320 k t 1 2 )
340
*
460 B R
500 A S E R O - 3 . 4 . 1
520
*
660 P A
700 U L M E N Z E L
720
*
0001440 2 0 1
0001460 2 1 0 1 1 1 3 2 6 4 7 0 0 \0 2 0
0001500 1 2 1 0 1 1 1 3 2 6 4 7 0 0 \0 \0
0001520 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0001560 \0 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0001600 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0004000
Hmm, it encodes the name in there. To all whistle blowers out there: Do
not use Brasero without configuring beforehand. ;-)
Thomas, I am going to write the commit message now.
Thanks,
Paul
PS: Thomas, reading the libburnia start page [1], I see you take
donations. If some users, benefiting from this patch want to donate
something, I would like the libburnia project to have it. So it would be
great if you could give me the necessary instructions.
[1] http://libburnia-project.org/
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=655601
Control: tags -1 patch
Control: found -1 2.91.93-1
Control: affects -1 brasero
Am Donnerstag, den 11.10.2012, 15:44 +0200 schrieb Paul Menzel:
Am Donnerstag, den 11.10.2012, 15:06 +0200 schrieb Thomas Schmitt:
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
[…]
Thomas, I am going to write the commit message now.
Please find the patch attached.
[…]
Thanks,
Paul
From 17ad074e2ad8e3881afae148594a770f3dd7f228 Mon Sep 17 00:00:00 2001
From: Paul Menzel paulepan...@users.sourceforge.net
Date: Thu, 11 Oct 2012 14:40:06 +0200
Subject: [PATCH] Libburnia plugin: Fix while loop in `brasero_libisofs_write_image_to_fd_thread()` (#655601)
In commit 1b8397ee [1]
commit 1b8397ee252df2d554682ca2d694d5937fbf6e39
Author: Philippe Rouquier bonfire-...@wanadoo.fr
Date: Tue Oct 5 10:10:17 2010 +0200
Fix for #630651 [2] - Basero creating incomplete image (.ISO) files
distributed since Brasero 2.91.1
$ git tag --contains 1b8397ee252df2d554682ca2d694d5937fbf6e39 | sort | head -n 1
BRASERO_2_91_1
a small bug was introduced by forgetting to substitude a command with a newly introduced variable in the loop condition. This broke the loop reading out the data to be written to the disc.
This small error had a huge impacted as writing images on the fly always failed, because only half of the image was written to the disc. Several bug reports exist for this problem and are most likely due to this problem [3][4][5].
Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601.
Creating this patch would not have been possible without the invaluable and quick observations and explanations of Thomas Schmitt from the libburnia project [7]. In the end Michael Biebl from the Debian project stepped up to look into this problem and bisected this problem to the above commit. Thomas Schmitt pointed out the error afterward. A big thanks to both of them and everybody else reporting errors and providing logs!
[1] http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
[2] https://bugzilla.gnome.org/show_bug.cgi?id=630651
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594753
[5] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
[6] https://bugzilla.gnome.org/show_bug.cgi?id=655601
[7] http://libburnia-project.org/
---
plugins/libburnia/burn-libisofs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/libburnia/burn-libisofs.c b/plugins/libburnia/burn-libisofs.c
index 22cb75e..841468a 100644
--- a/plugins/libburnia/burn-libisofs.c
+++ b/plugins/libburnia/burn-libisofs.c
@@ -199,7 +199,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs *self)
BRASERO_JOB_LOG (self, Writing to pipe);
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size);
- while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas, Am Donnerstag, den 11.10.2012, 17:08 +0200 schrieb Thomas Schmitt: Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). you seem right. The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? Since when does libburn return if all data was written or not? I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=655601 signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=685983 Dear Thomas, Am Donnerstag, den 11.10.2012, 17:26 +0200 schrieb Paul Menzel: Am Donnerstag, den 11.10.2012, 17:08 +0200 schrieb Thomas Schmitt: Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). you seem right. The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? Since when does libburn return if all data was written or not? To be sure and keep a little sanity I created a new report upstream [2]. I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. Of course I meant GNOME BTS issue #630651. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=655601 [2] https://bugzilla.gnome.org/show_bug.cgi?id=685983 [3] https://bugzilla.gnome.org/show_bug.cgi?id=630651 signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas, Am Donnerstag, den 11.10.2012, 16:59 +0200 schrieb Thomas Schmitt: 000 001 C D 0 0 1 001 \0 Yes. That is the start of a Primary Volume Descriptor block. Please mount the medium and use diff to compare the files in the image with their originals on hard disk. Just to be sure. (Mounting does not check all blocks in the image for sanity.) `diff folder/ /mnt/folder` does not return any error the burning worked. Hmm, it encodes the name in there. To all whistle blowers out there: Do not use Brasero without configuring beforehand. ;-) (Who told your computer your full name on the first hand ?) ECMA-119 says about that field in the PVD: 8.4.21 Data Preparer Identifier (BP 447 to 574) This field shall specify an identification of the person or other entity which controls the preparation of the data to be recorded on the Volume Group of which the volume is a member. I would rather use it to identify the image generating program. (I do so in xorriso. E.g.: XORRISO-1.2.5 2012.09.15.170346, LIBISOBURN-1.2.5, LIBISOFS-1.2.5, LIBBURN-1.2.5 ) Another bug found. :/ Brasero mentions itself as: 8.4.20 Publisher Identifier (BP 319 to 446) This field shall specify an identification of the user who specified what shall be recorded on the Volume Group of which the volume is a member. I would deem this field more appropriate to rat out Paul Menzel. :)) Very much more appropriate. ;-) Are you doing that in xorriso? mkisofs has a third opinion on that. It advertises itself in: 8.4.22 Application Identifier (BP 575 to 702) This field shall specify an identification of the specification of how the data are recorded on the Volume Group of which the volume is a member. Interesting. Though I know of no such specifications. PS: Thomas, reading the libburnia start page [1], I see you take donations. If some users, benefiting from this patch want to donate something, I would like the libburnia project to have it. So it would be great if you could give me the necessary instructions. If you would like to donate, please mail us: mario.danic [at] gmail [dot] com, Cc: scdbackup [at] gmx [dot] net. I personally can accept donations only by my german bank account. Possibly this is feasible within the EU even with smaller amounts. Our project founder Mario Danic has a paypal account, afaik. I understand he has to pay money for the web hoster. I see. Though I guess it should be made easy for people to donate. Entering an amount and clicking a button would be the best. Though I will tell them to mail you. (They could also sent you some stuff which they can pay easily in an online shop.) Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, Am Sonntag, den 23.09.2012, 16:40 +0200 schrieb Paul Menzel: Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt: […] Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. That really is strange. […] Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. Grrr³ from my side to not understanding anything. ;-) Thanks to Michael Biebl stepping up and looking into it, in #debian-gnome he wrote to have bisected this issue to commit upstream commit 5ff86b48 [1] which supposedly fixes GNOME bug 630651 [2]. Though, judging from this, it looks like the ISO image creation problem then. As this is done on the fly the created ISO image cannot be checked, right? He uploaded packages for testing with one more patch applied [3][4]. I am going to try those as soon as possible. Thanks, Paul [1] http://git.gnome.org/browse/brasero/commit/?id=5ff86b48 [2] https://bugzilla.gnome.org/show_bug.cgi?id=630651 [3] http://people.debian.org/~biebl/brasero/amd64/ [4] http://people.debian.org/~biebl/brasero/i386/ signature.asc Description: This is a digitally signed message part
Bug#688229: 688229: hack to emulate drive (was: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.)
Dear Thomas and other folks,
Am Sonntag, den 23.09.2012, 16:40 +0200 schrieb Paul Menzel:
Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt:
[…]
Is there some way to simulate a burner to find out what happened?
libburn would accept burner addresses like
stdio:/tmp/my_emulated_drive
which would behave like DVD-RAM or DVD+RW. I.e. quite different
from DVD-R or DVD+R. Nevertheless such an emulated drive would
allow to exercise the communications between libisofs and libburn,
as done by Brasero.
I do not know how to make Brasero use such a drive address.
Probably one would have to hack its source.
I will take a look.
And I did and came up with the attached patch. So for anyone wanting to
try it if he can reproduce the problems with this also go ahead.
It seems to even emulate the slow writing speed. ;-)
[…]
Thanks,
Paul
From a95089b51414b86466b0a74d1e91ebaf71f5c5d9 Mon Sep 17 00:00:00 2001
From: Paul Menzel paulepan...@users.sourceforge.net
Date: Wed, 10 Oct 2012 11:09:59 +0200
Subject: [PATCH] burn-libburn-common.c: Use std:/tmp/my_emulated_drive
---
plugins/libburnia/burn-libburn-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/libburnia/burn-libburn-common.c b/plugins/libburnia/burn-libburn-common.c
index 1965b86..ec9ec8b 100644
--- a/plugins/libburnia/burn-libburn-common.c
+++ b/plugins/libburnia/burn-libburn-common.c
@@ -164,7 +164,7 @@ brasero_libburn_common_ctx_new (BraseroJob *job,
/* we just want to scan the drive proposed by drive */
brasero_job_get_device (job, device);
- res = burn_drive_convert_fs_adr (device, libburn_device);
+ res = burn_drive_convert_fs_adr (stdio:/tmp/my_emulated_drive, libburn_device);
g_free (device);
if (res = 0) {
g_set_error (error,
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#688229: 688229: hack to emulate drive
Dear Thomas,
Am Mittwoch, den 10.10.2012, 16:56 +0200 schrieb Thomas Schmitt:
+ res = burn_drive_convert_fs_adr (stdio:/tmp/my_emulated_drive,
libburn_device);
Isn't there a quotation mark missing before the comma ?
Yes, sorry. Forgot to `git commit -a --amend` that error. Otherwise it
would not have compiled.
Thanks,
Paul
From c47007aa04b37e600c8c21620209cd038ca6b42a Mon Sep 17 00:00:00 2001
From: Paul Menzel paulepan...@users.sourceforge.net
Date: Wed, 10 Oct 2012 11:09:59 +0200
Subject: [PATCH] burn-libburn-common.c: Use std:/tmp/my_emulated_drive
A medium has to be put into the burner though, so that Brasero allows you to press the burn button.
---
plugins/libburnia/burn-libburn-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/libburnia/burn-libburn-common.c b/plugins/libburnia/burn-libburn-common.c
index 1965b86..11364bd 100644
--- a/plugins/libburnia/burn-libburn-common.c
+++ b/plugins/libburnia/burn-libburn-common.c
@@ -164,7 +164,7 @@ brasero_libburn_common_ctx_new (BraseroJob *job,
/* we just want to scan the drive proposed by drive */
brasero_job_get_device (job, device);
- res = burn_drive_convert_fs_adr (device, libburn_device);
+ res = burn_drive_convert_fs_adr (stdio:/tmp/my_emulated_drive, libburn_device);
g_free (device);
if (res = 0) {
g_set_error (error,
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Mittwoch, den 10.10.2012, 11:42 +0200 schrieb Thomas Schmitt:
i think i can spot a byte eating problem in
http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
resp. the master-branch commit
http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
-
@@ -200,6 +198,7 @@ brasero_libisofs_write_image_to_fd_thread
(BraseroLibisofs *self)
brasero_job_get_fd_out (BRASERO_JOB (self), fd);
BRASERO_JOB_LOG (self, Writing to pipe);
+ read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size)
== sector_size) {
if (priv-cancel)
break;
-
Variable read_bytes is set by a call of libisofs' resp. libburn's
burn_source.read_xt() which consumes data (one sector ?) into buf.
The call in the while() statement consumes another sector and thus
overwrites the previously read buffer without having done anything else
with that first buffer content.
Further down i see a similar change that looks more plausible
to me:
-
@@ -254,7 +261,8 @@ brasero_libisofs_write_image_to_file_thread
(BraseroLibisofs *self)
priv = BRASERO_LIBISOFS_PRIVATE (self);
brasero_job_start_progress (BRASERO_JOB (self), FALSE);
- while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size)
== sector_size) {
+ read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
-
I will try to make that adaptation tomorrow.
It appears to me that this information is not yet known in
https://bugzilla.gnome.org/show_bug.cgi?id=630651
Feel free to add my technical opinion to that bug report.
I did so right after reading your reply in the morning.
I will try to contact Philippe Rouquier directly on this issue.
We can just CC him and I am doing so now. Sorry Philippe.
Swallowing the first sector is enough to make the image not mountable.
But regrettably a single lost sector does not yet explain the fact
that we find Joliet data at block 16.
The normal layout of an ISO 9660 image with Joliet (and no
El Torito boot equipment) would be
Block 16: ISO (660/ECMA-119 Primary Volume Descriptor
Block 17: Joliet Volume Descriptor (which would not contain
names of payload files like IMG_2428.JPG)
Block 18: Volume Descriptor Set Terminator
libisofs will then pad up to 64 KB and first write the
ISO 9660 + Rock Ridge tree. Several blocks to be expected.
Only then comes the Joliet directory tree with those entries
which we found at block 16.
So we look for a byte eater that swallows at least a few dozen
sectors and not only the first one.
I am also going to print out the sector size. (Or just use GDB.)
Nevertheless, the code pieces, where above change was made,
look much like the place where the emerging damage of an
ISO 9660 image can be watched ... if it is not caused there.
A very good starting point for debugging, i'd say.
Telling from the function names, i would say the change which
i deem bad is in charge for writing to optical media, whereas
the good one is in charge for writing image to a file in hard
disk.
An according difference in success can be found in several
Brasero bug reports of the last years.
Thanks for the terrific analysis. I think we can be optimistic for
tomorrow. I know also got a case where even an error is reported and the
image (with the burner hack) is not mountable.
BraseroBurn: (at burn-job.c:1858) BraseroLibburn called
brasero_job_set_current_action
BraseroBurn: (at burn-libisofs.c:312) BraseroLibisofs Getting out thread
BraseroBurn: (at burn-job.c:1309) BraseroLibisofs called
brasero_job_get_fd_out
BraseroBurn: (at burn-job.c:1071) BraseroLibisofs Finished track
successfully
BraseroBurn: (at burn-task-ctx.c:354) No next track to process
BraseroBurn: (at burn-job.c:862) BraseroLibisofs disconnecting
BraseroLibisofs from BraseroChecksumImage
BraseroBurn: (at burn-job.c:258) BraseroLibisofs deactivating
BraseroBurn: (at burn-job.c:1267) BraseroChecksumImage called
brasero_job_get_current_track
BraseroBurn: (at burn-checksum-image.c:531) BraseroChecksumImage
Setting new checksum (type = 2) 75f26d2175cb8d2a6d3370a2b7aa0164
(file:///tmp/brasero_tmp_JL20LW.md5 before)
BraseroBurn: (at burn-job.c:1071) BraseroChecksumImage Finished track
successfully
BraseroBurn: (at burn-task-ctx.c:354) No next track to process
BraseroBurn: (at burn-job.c:862) BraseroChecksumImage
Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Package: lightdm Version: 1.2.2-3 Severity: serious Justification: Renders package unusable Dear Debian folks, installing `lightdm` it runs, but the greeter does not show up. :/ Only a blinking cursor in the top left corner on VT 7. Somehow the X server is just closed $ sudo more /var/log/Xorg.0.log […] [ 1126.596] (II) UnloadModule: evdev [ 1126.606] Server terminated successfully (0). Closing log file. and LightDM does not find a X server. $ sudo service lightdm start Starting Light Display Manager: lightdm already running. $ sudo more /var/log/lightdm/lightdm.log [+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log [+0.00s] DEBUG: Starting Light Display Manager 1.2.2, UID=0 PID=2644 [+0.00s] DEBUG: Loaded configuration from /etc/lightdm/lightdm.conf [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager [+0.00s] DEBUG: Registered seat module xlocal [+0.00s] DEBUG: Registered seat module xremote [+0.00s] DEBUG: Adding default seat [+0.01s] DEBUG: Starting seat [+0.01s] DEBUG: Starting new display for greeter [+0.01s] DEBUG: Starting local X display [+0.01s] DEBUG: Could not run plymouth --ping: Failed to execute child process plymouth (No such file or directory) [+0.01s] DEBUG: Using VT 7 [+0.01s] DEBUG: Activating VT 7 [+0.01s] DEBUG: Logging to /var/log/lightdm/x-0.log [+0.01s] DEBUG: Can't launch X server X, not found in path [+0.01s] DEBUG: X server stopped [+0.01s] DEBUG: Releasing VT 7 [+0.01s] DEBUG: Display server stopped [+0.01s] DEBUG: Stopping display [+0.01s] DEBUG: Display stopped [+0.01s] DEBUG: Stopping X local seat, failed to start a display [+0.01s] DEBUG: Stopping seat [+0.01s] DEBUG: Seat stopped [+0.01s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+87.81s] DEBUG: Got signal 15 from process 2841 [+87.81s] DEBUG: Caught Terminated signal, shutting down [+87.81s] DEBUG: Stopping display manager [+87.81s] DEBUG: Display manager stopped [+87.81s] DEBUG: Stopping daemon [+87.81s] DEBUG: Exiting with return value 0 There is also *no* `/var/log/lightdm/x-0.log`. Any help would be appreciated. Thanks, Paul -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.5-3.1 ii dbus 1.6.0-1 ii debconf [debconf-2.0] 1.5.46 ii libc6 2.13-35 ii libglib2.0-0 2.32.3-1 ii libpam0g 1.1.3-7.1 ii libxcb11.8.1-1 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter1.1.6-2 Versions of packages lightdm recommends: pn xserver-xorg none Versions of packages lightdm suggests: ii accountsservice 0.6.21-6 -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm signature.asc Description: This is a digitally signed message part
Bug#688756: [Pkg-xfce-devel] Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Am Dienstag, den 25.09.2012, 14:45 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 14:22 +0200, Paul Menzel wrote: Any help would be appreciated. Does X works by itself? Yes, I am sorry. GDM 3 worked before and going back to it works too. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688756: [Pkg-xfce-devel] Bug#688756: Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Am Dienstag, den 25.09.2012, 15:13 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 14:52 +0200, Paul Menzel wrote: Am Dienstag, den 25.09.2012, 14:45 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 14:22 +0200, Paul Menzel wrote: Any help would be appreciated. Does X works by itself? Yes, I am sorry. GDM 3 worked before and going back to it works too. Can you attach the complete logs (/var/log/lightdm/* There was only that `lightdm.log` in there, from which I pasted the content into the message. :/ and /var/log/Xorg.0.log) Sure. I will configure LightDM again, since unfortunately I did not save it, and will send it again. :/ Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688756: [Pkg-xfce-devel] Bug#688756: Bug#688756: lightdm: no greeter: `Can't launch X server X, not found in path`
Am Dienstag, den 25.09.2012, 15:34 +0200 schrieb Paul Menzel: Am Dienstag, den 25.09.2012, 15:28 +0200 schrieb Paul Menzel: Am Dienstag, den 25.09.2012, 15:13 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 14:52 +0200, Paul Menzel wrote: Am Dienstag, den 25.09.2012, 14:45 +0200 schrieb Yves-Alexis Perez: On mar., 2012-09-25 at 14:22 +0200, Paul Menzel wrote: Any help would be appreciated. Does X works by itself? Yes, I am sorry. GDM 3 worked before and going back to it works too. Can you attach the complete logs (/var/log/lightdm/* There was only that `lightdm.log` in there, from which I pasted the content into the message. :/ $ sudo ls -al /var/log/lightdm/ insgesamt 12 drwx--x--x 2 root root 4096 Sep 25 14:00 . drwxr-xr-x 9 root root 4096 Sep 25 15:21 .. -rw--- 1 root root 1151 Sep 25 15:31 lightdm.log and /var/log/Xorg.0.log) Sure. I will configure LightDM again, since unfortunately I did not save it, and will send it again. :/ Please find it attached. Alright, reading the error message again, `/usr/bin/X` is not installed as it is in `xserver-xorg` `lightdm` only recommends. 1. Is that due to that LightDM can also be used from remote? 2. Since GDM can start fine without `/usr/bin/X`, LightDM should also be able to? Please proceed as you want with this report. I am sorry for the noise. At least users will find something on the WWW when searching for the error message. ;-) Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, thank you again for your fast reply. Could you please CC me, since I am not subscribed and need to import your message from the BTS every time. Am Samstag, den 22.09.2012, 12:04 +0200 schrieb Thomas Schmitt: Paul Menzel wrote: $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c ... 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 \f ' This does not look like an ISO 9660 Primary Volume Descriptor but rather like a snippet from a Joliet directory tree. Read as 16 bit characters one can recognize IMG_2428.JPG and IMG_2429.JPG. They are announced to start at blocks 72752 (decimal) and 74132 (decimal). Sizes are 2825286 and 2866752 bytes. ... if i decoded these little endian 32-bit numbers correctly: 0 034 001 \0 IMG_2428.JPG, Location of Extent F 034 + \0 IMG_2428.JPG, Data Length 224 ! 001 \0 IMG_2429.JPG, Location of Extent @ 276 + \0 IMG_2429.JPG, Data Length (The layout of directory records is documented in ECMA-119, 9.1. Joliet deviates from this layout mainly by using 16-bit characters for File Identifier.) Nice find! I really wonder how this could get to block 16 of the medium. Brasero did order libisofs to produce a Joliet tree. But it should be stored several blocks after block 16. Before Joliet there should be volume descriptors and the ISO 9660 + Rock Ridge tree. It is clear that no reader software wants to accept this as ISO 9660 filesystem. Guessing from this single block content, i would expect that a few hundred kilobytes of the image start have not been written onto the medium. Most simple explanation for this would be that they were not transmitted from libisofs to libburn. But i riddle how this could be possible. Is there some way to simulate a burner to find out what happened? […] $ dvd+rw-mediainfo /dev/sr1 The output looks totally normal. Medium is ok. I think I forgot to add that the burner and the same DVD medium were used successfully with for example K3b and I also think xorriso. We have no special indication of any malfunction of burner or medium. There are just not the right bytes stored at the right block addresses. A further test with xorriso would be welcome. Just to be sure. Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / xorriso 1.2.2 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev '/dev/sr1' Media current: DVD-R sequential recording Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 4489m free xorriso : UPDATE : 123 files added in 1 seconds Added to ISO image: directory '/'='/home/joe/test' xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Am Sonntag, den 23.09.2012, 15:29 +0200 schrieb intrigeri: found 617409 3.4.1-3 thanks Dear intrigeri, thank you for following up on this report without breaking threading. ;-) I can reproduce this bug in my up-to-date Wheezy system with Burn the image directly enabled, and I can't if I disable this feature. Interesting. What may I do to help fixing this bug for Wheezy? Is the please try with that patch thing up-to-date for Wheezy's Brasero 3.x? Could you please take a look at #688229 [1]. Maybe you can provide similar information (exact error, log files, …). Thomas helped me quite a lot and maybe we can save him some time. Maybe even open a separate bug report first. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229 signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt: Could you please CC me I will try to remember. :) But maybe you better subscribe by a mail to 688229-subscr...@bugs.debian.org I would like to avoid that, because it also requires confirmation and I think »Reply to all« is easier. But I will do so next time, it happens. Is there some way to simulate a burner to find out what happened? libburn would accept burner addresses like stdio:/tmp/my_emulated_drive which would behave like DVD-RAM or DVD+RW. I.e. quite different from DVD-R or DVD+R. Nevertheless such an emulated drive would allow to exercise the communications between libisofs and libburn, as done by Brasero. I do not know how to make Brasero use such a drive address. Probably one would have to hack its source. I will take a look. Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. That really is strange. I assume you too live in Germany. If so: Would the images on the DVD be non-private enough and would you want to invest 1.45 Euro into a mail stamp in order to send me that DVD-R for closer inspection ? Or do you have 2 GB of internet storage from where i could download a copy of the medium made by dd if=/dev/sr1 bs=2048 of=/tmp/copy_of_dev_sr1 ? I will try to and will contact you again next week. Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. Grrr³ from my side to not understanding anything. ;-) The only thing I noticed, that another DVD drive, the Toshiba DVD-ROM SD-M1712, needed more than 25 seconds to recognize the disc. This might be due to the fact that the medium is still appendable, unlike the one from Brasero. I.e. you could add more files by xorriso or growisofs. How is recognition time with the burner ? In order to get a closed DVD-R, you would have to use command -close on E.g. with the now appendable DVD-R medium $ mkdir ~/test2 $ cp ...a...few...files... ~/test2 $ xorriso -md5 on -dev /dev/sr1 -map ~/test2 /test2 -close on (Note that this run uses command -dev rather than -outdev in order to load the existing directory tree of the image and to merge it with the newly added file tree.) Maybe it will then be recognized faster by the DVD-ROM. Thank you for the detailed explanation. I already gave the DVD away. Maybe I have a chance to look into it again. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, I am sorry for my late reply. Also I am CCing just to be sure. If you get the message twice because you subscribed to the report, please tell me. Am Donnerstag, den 20.09.2012, 22:51 +0200 schrieb Thomas Schmitt: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) It went well, at least as far as libisofs was involved. So this is not the problem with premature end after 50 %. And it is not the riddling CD problem, where Brasero CDs are unreadable, whereas xorriso burned CDs are ok. Great! BraseroLibburn Async SYNCHRONIZE CACHE succeeded after 0.8 seconds ... BraseroLibburn Closing track 01 (absolute track number 1) BraseroLibburn Async CLOSE TRACK SESSION succeeded after 0.4 seconds BraseroLibburn Closing session BraseroLibburn Async CLOSE TRACK SESSION succeeded after 5.3 seconds These messages stem from libburn. They indicate that it saw no severe error message from the drive and that it finished the burn run. I cannot tell, though, how many data were passed through libburn. [ 9103.816252] ISOFS: Unable to identify CD-ROM format. What do you get from dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c With a valid ISO image, the output should begin by 000 001 C D 0 0 1 and consist of up to 128 lines of text. $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c 1+0 Datensätze ein 1+0 Datensätze aus 2048 Bytes (2,0 kB) kopiert, 0,00199071 s, 1,0 MB/s 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 \f ' 200 001 \0 \0 001 ' \f u S - \0 \0 - S u p \t 220 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 240 M \0 G \0 _ \0 2 \0 4 \0 3 \0 0 \0 . \0 260 J \0 P \0 G \0 ; \0 1 \0 \0 267 , 001 \0 300 \0 001 , 267 016 y 037 \0 \0 037 y 016 p \t 023 022 320 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 340 G \0 _ \0 2 \0 4 \0 3 \0 2 \0 . \0 J \0 360 P \0 G \0 ; \0 1 \0 \0 247 0 001 \0 \0 001 400 0 247 340 I \0 \0 I 340 p \t 023 022 1 ! 420 \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 440 _ \0 2 \0 4 \0 3 \0 3 \0 . \0 J \0 P \0 460 G \0 ; \0 1 \0 \0 361 4 001 \0 \0 001 4 361 500 005 G \0 \0 G 005 p \t 023 022 1 ! \0 \0 520 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 _ \0 540 2 \0 4 \0 3 \0 4 \0 . \0 J \0 P \0 G \0 560 ; \0 1 \0 \0 372 8 001 \0 \0 001 8 372 252 020 600 ! \0 \0 ! 020 252 p \t 023 022 1 ! \0 \0 \0 \0 620 001 \0 \0 001 034 \0 I \0 M \0 G \0 _ \0 2 \0 640 4 \0 3 \0 5 \0 . \0 J \0 P \0 G \0 ; \0 660 1 \0 \0 035 = 001 \0 \0 001 = 035 252 261 035 \0 700 \0 035 261 252 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 720 \0 001 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 740 3 \0 7 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 760 \0 324 @ 001 \0 \0 001 @ 324 ; 206 % \0 \0 % 0001000 206 ; p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 0001020 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 3 \0 0001040 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 0001060 205 E 001 \0 \0 001 E 205 M 255 \0 \0255 M 0001100 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 0001120 I \0 M \0 G \0 _ \0 2 \0 4 \0 3 \0 9 \0 0001140 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 [ J 0001160 001 \0 \0 001 J [ 250 P \0 \0 P 250 p \t 0001200 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 0001220 M \0 G \0 _ \0 2 \0 4 \0 4 \0 0 \0 . \0 0001240 J \0 P \0 G \0 ; \0 1 \0 \0 246 N 001 \0 0001260 \0 001 N 246 q K \0 \0 K q p \t 023 022 0001300 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 0001320 G \0 _ \0 2 \0 4 \0 4 \0 1 \0 . \0 J \0 0001340 P \0 G \0 ; \0 1 \0 \0 p S 001 \0 \0 001 0001360 S p 340 034 $ \0 \0 $ 034 340 p \t 023 022 1 ! 0001400 \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 0001420
Bug#670405: ekiga: During start up segfault in `libopal.so.3.10.4`
Dear Berto, Am Sonntag, den 09.09.2012, 14:49 +0200 schrieb Paul Menzel: […] Am Montag, den 09.07.2012, 12:45 +0300 schrieb Alberto Garcia: On Fri, Jul 06, 2012 at 02:23:22PM +0200, Eugen Dedu wrote: Could you please send us the -d 4 output when it crashes? Here it is, tell me if you need something more. Versions I'm using: ekiga 3.2.7-5+b1 libpt2.10.4 2.10.4~dfsg-1 libopal3.10.4 3.10.4~dfsg-3 Looking at this backtrace it seems to be different. The last one segfaults in `ptlib/pstring.h` where the first one segfaults in `libopal3.10.4`. I created a bug 683662 at Ekiga’s upstream GNOME Bugzilla bug tracking system [1], but I realized the two different traces too late and now pasted both traces. We should wait what upstream says to how to deal with these separate issues. it would be great if you could subscribe to the upstream bug report as Eugen actively works on Ekiga and follows up on all reports. (Thanks Eugen!) Berto, it would be awesome if you could test Ekiga from experimental [3][4] and report back if it fixes the issues for you. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=683662 [2] https://bugzilla.gnome.org/show_bug.cgi?id=683662#c4 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685880 signature.asc Description: This is a digitally signed message part
Bug#687026: gnome-shell: No browser icon in dash
Am Montag, den 10.09.2012, 04:34 +0200 schrieb Michael Biebl: severity 687026 serious thanks On 08.09.2012 17:26, Paul Menzel wrote: it looks like by default there is no browser available in the dash of the overview mode. As browsing the Web is an essential activity the current default browser of the user should be added there. Or Epiphany by, which conflicts a little with report #682481 though. Looking at the dependencies of `gnome-shell` it also looks like it does not depend on any browser. Though it also does not depend on Evolution which is in the dash. This was caused by [1]. As it seems, the name of the epiphany .desktop is epiphany.desktop for the version in sid/wheezy. So the entry in favorite-apps is broken. This should be fixed for wheezy, so marking as RC. Talking with mbiebl and Np237 in #debian-gnome on irc.oftc.net, Np237 said that this corresponding change has been made for epiphany-browser, but the updated packages has not yet been uploaded. Thanks, Paul [1] http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/gnome-shell.gsettings-override?revision=35528view=markup signature.asc Description: This is a digitally signed message part
Bug#670405: Segfault in std::lessunsigned int::operator() from /usr/lib/libopal.so.3.10.4 (was: Bug#670405: ekiga: Ekiga crashes on startup)
clone 670405 -1 assign -1 libopal3.10.4 retitle -1 Segfault in std::lessunsigned int::operator() from /usr/lib/libopal.so.3.10.4 affects -1 ekiga severity -1 important quit Dear Gregor, thank you for all your RCBW work! Am Donnerstag, den 23.08.2012, 17:48 +0200 schrieb gregor herrmann: On Fri, 06 Jul 2012 14:23:22 +0200, Eugen Dedu wrote: Could you please send us the -d 4 output when it crashes? Try like this: gdb -- args ekiga -d 4 21|tee log.txt and press of course: thread apply all bt when it crashes ekiga seems to work for me (except for the webcam but whatever). What version of Ekiga did you use? I guess `3.2.7-5+b1`? Please also note that Alberto wrote he can not *always* reproduce it. How often did you start Ekiga? The interesting thing is that I get a segfault at Ctrl-Q / Chat-Quit I clone this report and assign it to libopal as the segmentation fault happens in `/usr/lib/libopal.so.3.10.4`. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#670405: ekiga: During start up segfault in `libopal.so.3.10.4` (was: ekiga: Ekiga crashes on startup)
retitle 670405 ekiga: During start up segfault in `libopal.so.3.10.4` forwarded 670405 https://bugzilla.gnome.org/show_bug.cgi?id=683662 tag 670405 upstream quit Dear Berto, thank you for your follow up! Am Montag, den 09.07.2012, 12:45 +0300 schrieb Alberto Garcia: On Fri, Jul 06, 2012 at 02:23:22PM +0200, Eugen Dedu wrote: Could you please send us the -d 4 output when it crashes? Here it is, tell me if you need something more. Versions I'm using: ekiga 3.2.7-5+b1 libpt2.10.4 2.10.4~dfsg-1 libopal3.10.4 3.10.4~dfsg-3 Looking at this backtrace it seems to be different. The last one segfaults in `ptlib/pstring.h` where the first one segfaults in `libopal3.10.4`. I created a bug 683662 at Ekiga’s upstream GNOME Bugzilla bug tracking system [1], but I realized the two different traces too late and now pasted both traces. We should wait what upstream says to how to deal with these separate issues. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=683662 signature.asc Description: This is a digitally signed message part
Bug#686817: grub-pc: Add option to change keyboard layout
Package: grub-pc Version: 1.99-22.1 Severity: serious Dear Debian folks, in my opinion it should be possible for the user to easily change the keyboard layout for the boot loader. Especially in 2012. So I put the severity to serious as I think this should be solved for Wheezy. As far as my tests and my online search goes, that is currently not possible in Debian [1]. Fedora seems to offer that possibility and GRUB too [2]. Probably #686815 [3] needs to be resolved for that first. Additionally an option should be added to `/etc/default/grub` like discussed on the Talk page in the ArchWiki [2]. GRUB_TERMINAL_INPUT=at_keyboard KEYBOARD_LAYOUT=de Lastly `/etc/grub.d/05_keyboard_layout` needs to be created with insmod keylayouts keymap /boot/grub/$KEYBOARD_LAYOUT.gkb where the last line should ideally be also read from `/etc/default/grub` and `update-grub` should take care of generating the keymap file using `grub-kbdcomp`. If that is not possible a big section should be added to the release notes. Currently Debian Wheezy does not support to easily change the keyboard layout for its default boot loader GRUB 2 (grub-pc). Please read the page should be created in the Debian Wiki on how to do that manually. Please note that when Debian GNU/Linux starts, it uses an initial RAM file system which can set the used keyboard layout for entering for example the LUKS password for encrypted devices. You need to install the package `console-setup` to configure that. Thanks, Paul [1] http://debianforum.de/forum/viewtopic.php?f=12t=116672 [2] https://wiki.archlinux.org/index.php/Talk:GRUB2#Custom_keyboard_layout [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686815 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages grub-common depends on: ii gettext-base0.18.1.1-9 ii libc6 2.13-35 ii libdevmapper1.02.1 2:1.02.74-4 ii libfreetype62.4.9-1 ii libfuse22.9.0-5 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages grub-common recommends: ii os-prober 1.55 Versions of packages grub-common suggests: ii desktop-base 7.0.3 pn grub-emu none pn multiboot-doc none ii xorriso1.2.2-2 -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#685586: evolution: Please package 3.4.4 for Wheezy
Package: evolution Version: 3.4.3-1 Severity: grave Justification: causes non-serious data loss Dear Debian folks, Evolution 3.4.4 was released on August 13th 2012. commit b097a7d4dee51f18fe32722a098076827ec96c69 Author: Matthew Barnes mbar...@redhat.com Date: Sun Aug 12 19:40:51 2012 -0400 NEWS update for 3.4.4 release. diff --git a/NEWS b/NEWS index 6d34b93..d9954f4 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,32 @@ +Evolution 3.4.4 2012-08-13 +-- + +* At some point since Evolution 3.0, detection of when the local mail + storage format needs to be converted from mbox (as used in 2.x) to + Maildir (as used in 3.x) broke. This release fixes the detection. + +Bug Fixes: + Bug 559815 - Empty Reminders editor when opened second time +(Milan Crha) + Bug 617557 - Can close composer while message is sending (Milan Crha) + Bug 653529 - Alarm Notification window events list is too small +(Milan Crha) + Bug 677993 - Remember screen used in previous session (Milan Crha) + Bug 678292 - Due Date does not display in follow-up flag dialogue box +(Milan Crha) + Bug 678304 - Save Draft prevents Evolution's quit (Milan Crha) + Bug 678783 - Crash under e_attachment_set_file_info() (Milan Crha) + Bug 680682 - Segfault after label attempted deletion (Milan Crha) + +Other Changes: + * Trust attachments from ~/.kde and ~/.kde4. (Matthew Barnes) + * Run mbox-to-Maildir conversion before loading modules. + (Matthew Barnes) + +Translations: + Sasi Bhushan Boddepalli (te) + + Evolution 3.4.3 2012-06-18 -- It fixes a segfault, which causes (partly) loss of messages which are being just composed. That should never happen to the mail application which is by far the most used application of an operating system next to the Web browser. Additionally it hopefully fixes Debian report #679347 [1]. Thanks, Paul PS: It looks like Evolution 3.4.3 also contains another segmentation fault I reported upstream today [2]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679347 [2] https://bugzilla.gnome.org/show_bug.cgi?id=682426 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evolution depends on: ii dbus 1.6.2-2 ii debconf [debconf-2.0]1.5.46 ii evolution-common 3.4.3-1 ii evolution-data-server3.4.3-1 ii gconf-service3.2.5-1+build1 ii gconf2 3.2.5-1+build1 ii gnome-icon-theme 3.4.0-2 ii libatk1.0-0 2.4.0-2 ii libc62.13-35 ii libcairo-gobject21.12.2-2 ii libcairo21.12.2-2 ii libcamel-1.2-33 3.4.3-1 ii libclutter-gtk-1.0-0 1.2.0-2 ii libdbus-glib-1-2 0.100-1 ii libebackend-1.2-23.4.3-1 ii libebook-1.2-13 3.4.3-1 ii libecal-1.2-11 3.4.3-1 ii libedataserver-1.2-163.4.3-1 ii libedataserverui-3.0-1 3.4.3-1 ii libenchant1c2a 1.6.0-7 ii libevolution 3.4.3-1 ii libgail-3-0 3.4.2-3 ii libgconf-2-4 3.2.5-1+build1 ii libgdata13 0.12.0-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgtk-3-0 3.4.2-3 ii libgtkhtml-4.0-0 4.4.3-1 ii libgtkhtml-editor-4.0-0 4.4.3-1 ii libgweather-3-0 3.4.1-1+build1 ii libical0 0.48-2 ii libmx-1.0-2 1.4.6-1 ii libnotify4 0.7.5-1 ii libnspr4 2:4.9.2-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3 2:3.13.5-1 ii libnss3-1d 2:3.13.5-1 ii libpango1.0-01.30.0-1 ii libsoup2.4-1 2.38.1-2 ii libsqlite3-0 3.7.13-1 ii libxml2 2.8.0+dfsg1-5 ii psmisc 22.19-1 Versions of packages evolution recommends: ii bogofilter 1.2.2+dfsg1-1+b1 ii evolution-plugins 3.4.3-1 ii evolution-webcal 2.32.0-2+b2 ii spamassassin 3.3.2-4 ii yelp 3.4.2-1 Versions of packages evolution suggests: ii evolution-dbg 3.4.3-1 ii evolution-exchange 3.4.3-2 ii evolution-plugins-experimental 3.4.3-1 ii gnupg
Bug#685588: evolution: Crash: libcamel-1.2: #0 camel_pstring_add (str=str@entry=0x4 Address 0x4 out of bounds, own=own@entry=0) at camel-string-utils.c:170
Package: evolution Version: 3.4.3-1 Severity: grave Justification: causes non-serious data loss Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=682426 Dear Debian folks, while composing a message Evolution 3.4.3 crashed. $ dmesg […] [ 1775.978900] pool[10745]: segfault at 4 ip f6ab09c6 sp e9927e20 error 4 in libcamel-1.2.so.33.0.0[f6a03000+103000] The backtrace can be found in the upstream report I reported [1]. I did not experience any crashes with Evolution 3.2.2 for a long time. Crashes cause data loss, when the user currently composes a message. Auto saving messages and restoring them only helps a little. Crashes should never happen with the most used applications, which I am counting the mail program to. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=682426 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evolution depends on: ii dbus 1.6.2-2 ii debconf [debconf-2.0]1.5.46 ii evolution-common 3.4.3-1 ii evolution-data-server3.4.3-1 ii gconf-service3.2.5-1+build1 ii gconf2 3.2.5-1+build1 ii gnome-icon-theme 3.4.0-2 ii libatk1.0-0 2.4.0-2 ii libc62.13-35 ii libcairo-gobject21.12.2-2 ii libcairo21.12.2-2 ii libcamel-1.2-33 3.4.3-1 ii libclutter-gtk-1.0-0 1.2.0-2 ii libdbus-glib-1-2 0.100-1 ii libebackend-1.2-23.4.3-1 ii libebook-1.2-13 3.4.3-1 ii libecal-1.2-11 3.4.3-1 ii libedataserver-1.2-163.4.3-1 ii libedataserverui-3.0-1 3.4.3-1 ii libenchant1c2a 1.6.0-7 ii libevolution 3.4.3-1 ii libgail-3-0 3.4.2-3 ii libgconf-2-4 3.2.5-1+build1 ii libgdata13 0.12.0-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgtk-3-0 3.4.2-3 ii libgtkhtml-4.0-0 4.4.3-1 ii libgtkhtml-editor-4.0-0 4.4.3-1 ii libgweather-3-0 3.4.1-1+build1 ii libical0 0.48-2 ii libmx-1.0-2 1.4.6-1 ii libnotify4 0.7.5-1 ii libnspr4 2:4.9.2-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3 2:3.13.5-1 ii libnss3-1d 2:3.13.5-1 ii libpango1.0-01.30.0-1 ii libsoup2.4-1 2.38.1-2 ii libsqlite3-0 3.7.13-1 ii libxml2 2.8.0+dfsg1-5 ii psmisc 22.19-1 Versions of packages evolution recommends: ii bogofilter 1.2.2+dfsg1-1+b1 ii evolution-plugins 3.4.3-1 ii evolution-webcal 2.32.0-2+b2 ii spamassassin 3.3.2-4 ii yelp 3.4.2-1 Versions of packages evolution suggests: ii evolution-dbg 3.4.3-1 ii evolution-exchange 3.4.3-2 ii evolution-plugins-experimental 3.4.3-1 ii gnupg 1.4.12-4+b1 ii network-manager 0.9.4.0-5 -- debconf information: evolution/needs_shutdown: evolution/kill_processes: signature.asc Description: This is a digitally signed message part
Bug#682426: cups: filter gs takes several minutes consuming 100 % of CPU
Package: cups Version: 1.5.3-2 Severity: grave Dear Debian folks, printing takes longer than expected. Instead of several seconds to process the job it takes several minutes until the printer starts to print. This seems to be related to Ghostscript. $ more /var/log/cups/error_log […] D [22/Jul/2012:18:13:33 +0200] [Job 1238] Options from the PPD file: D [22/Jul/2012:18:13:33 +0200] [Job 1238] Pondering option 'InputSlot=Default' D [22/Jul/2012:18:13:33 +0200] [Job 1238] Pondering option 'Quality=FromPrintoutMode' D [22/Jul/2012:18:13:33 +0200] [Job 1238] Pondering option 'PageSize=A4' D [22/Jul/2012:18:13:33 +0200] [Job 1238] Pondering option 'PrintoutMode=Draft' D [22/Jul/2012:18:13:33 +0200] [Job 1238] Pondering option 'Duplex=None' D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] [Job 1238] File: STDIN D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] [Job 1238] D [22/Jul/2012:18:13:33 +0200] PID 14271 (/usr/lib/cups/filter/pdftopdf) exited with no errors. D [22/Jul/2012:18:13:33 +0200] [Job 1238] Using image rendering resolution 1200 dpi D [22/Jul/2012:18:13:33 +0200] [Job 1238] Started filter gs (PID 14275) D [22/Jul/2012:18:13:33 +0200] [Job 1238] Started filter pstops (PID 14276) D [22/Jul/2012:18:13:44 +0200] Report: clients=2 D [22/Jul/2012:18:13:44 +0200] Report: jobs=499 D [22/Jul/2012:18:13:44 +0200] Report: jobs-active=1 D [22/Jul/2012:18:13:44 +0200] Report: printers=4 D [22/Jul/2012:18:13:44 +0200] Report: printers-implicit=0 D [22/Jul/2012:18:13:44 +0200] Report: stringpool-string-count=5919 D [22/Jul/2012:18:13:44 +0200] Report: stringpool-alloc-bytes=13760 D [22/Jul/2012:18:13:44 +0200] Report: stringpool-total-bytes=107840 I [22/Jul/2012:18:13:53 +0200] Saving job.cache... […] This does not finish and takes two to three minutes. CPU usage shown by `htop` is 100 %. $ ps aux | grep gs lp 14275 15.0 16.5 571444 557404 ? t18:13 0:39 gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -r1200 -dCompressFonts=false -dNoT3CCITT -c save pop -f /var/spool/cups/tmp/037c0500da6c6 I am marking this bug as serious because printing several documents is not possible anymore and renders this system unusable for this task. This problem was also mentioned by myself in report #662780 [1] but seems to be unrelated, since the reporter of #662780 says it is fixed for him. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662780#34 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.5.0-rc7+ (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cups depends on: ii adduser3.113+nmu3 ii bc 1.06.95-3 ii cups-client1.5.3-2 ii cups-common1.5.3-2 ii cups-filters 1.0.18-2+b1 ii cups-ppdc 1.5.3-2 ii debconf [debconf-2.0] 1.5.45 ii dpkg 1.16.8 ii ghostscript9.05~dfsg-6 ii libavahi-client3 0.6.31-1 ii libavahi-common3 0.6.31-1 ii libc6 2.13-34 ii libcups2 1.5.3-2 ii libcupscgi11.5.3-2 ii libcupsimage2 1.5.3-2 ii libcupsmime1 1.5.3-2 ii libcupsppdc1 1.5.3-2 ii libdbus-1-31.6.2-2 ii libgcc11:4.7.1-5 ii libgnutls262.12.20-1 ii libgssapi-krb5-2 1.10.1+dfsg-1 ii libkrb5-3 1.10.1+dfsg-1 ii libldap-2.4-2 2.4.31-1 ii libpam0g 1.1.3-7.1 ii libpaper1 1.1.24+nmu2 ii libslp11.2.1-9 ii libstdc++6 4.7.1-5 ii libusb-1.0-0 2:1.0.12-2 ii lsb-base 4.1+Debian7 ii poppler-utils 0.18.4-3 ii procps 1:3.3.3-2 ii ssl-cert 1.0.31 Versions of packages cups recommends: ii avahi-daemon 0.6.31-1 ii colord 0.1.21-1 ii foomatic-filters 4.0.17-1 ii ghostscript-cups 9.05~dfsg-6 ii printer-driver-gutenprint 5.2.9-1 Versions of packages cups suggests: ii cups-bsd 1.5.3-2 ii cups-pdf 2.6.1-6 pn foomatic-db-compressed-ppds | foomatic-db none ii hplip
Bug#617409: brasero: Road map (was: Brasero corrupts all blank CD-R when burning)
Dear Thomas, thank you for your effort. Unfortunately no one affected by this problem has replied yet. (Although we should give them some more time to reply. Other things might be more important currently.) Until then I suggest to not bother anymore with that problem. If we do not get anymore replies during the next two weeks, I suggest to split up the Debian bug report. The first one of rpnpif, downgrade the severity to important and mark it as unreproducible as it worked for you. Simon’s answer is probably the other bug about stopping at half time/size which also is dealt with at the Launchpad report. This seems to be an issue with newer versions and that help and more information are needed to fix it. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#617409: Applying George’s patch (was: brasero: Brasero corrupts all blank CD-R when burning)
Dear Thomas, Am Donnerstag, den 05.07.2012, 20:04 +0200 schrieb Thomas Schmitt: George Danchev wrote: Thomas (or anyone else), could you please try brasero on your squeeze box (I currently don't have any burners at reach), Ok, for once ... :)) I will cry on your shoulder if it freezes my good old fvwm display. Actually i avoided trying myself because i do not want to become the maintainer of Brasero. If it is really orphaned, then so be it. true. -- Ok. First what i can do by comfortable harmless ssh: $ su # apt-get source brasero (warns keyblock resource `/root/.gnupg/trustedkeys.gpg': file open error) No need to be root. Only when you install it with `dpkg -i ../*brasero*deb`(?). # apt-get build-dep brasero (Lots of activities) # mv check-child-status debian/patches/ mv: cannot move `check-child-status' to `debian/patches/': No such file or directory I guess you are missing `cd brasero…` you download with the first command. […] Thanks, Paul PS: Somehow the Debian bug report address was not in CC but it was archived [1] anyway. Did you put it in BCC? Anyway, I added it back to the CC list. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 signature.asc Description: This is a digitally signed message part
Bug#617409: [Pkg-libburnia-devel] Bug#617409: Reproducing instructions (was: Applying George’s patch)
Dear George, Am Donnerstag, den 05.07.2012, 21:48 +0200 schrieb George Danchev: On Thursday 05 July 2012 21:14:51 Paul Menzel wrote: Maybe you can also give more punctual instructions where to click on that brasero interface thing so we can re-produce the bug as you do. unfortunately I cannot help with that. Sorry! I just looked at the release critical bug list and picked this one to follow up on. :/ I updated the GNOME [1] and Launchpad reports [2] though to make them aware of your patches and questions and to ask for help. […] Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=655601#c19 [2] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 comment #58 signature.asc Description: This is a digitally signed message part
Bug#617409: Applying patches (was: brasero: Brasero corrupts all blank CD-R when burning)
Dear Thomas, Am Donnerstag, den 05.07.2012, 22:22 +0200 schrieb Thomas Schmitt: […] No need to be root. Only when you install it with `dpkg -i ../*brasero*deb`(?). I should remember. I use that Debian installation mainly for daring experiments. I guess you are missing `cd brasero...` you download with the first command. # find . -name patches ./brasero-2.30.3/debian/patches # cd brasero-2.30.3 # chmod -R ... ; chgrp -R ... # exit $ cd brasero-2.30.3 Well, that's not brasero-2.30.3-2 either. $ ls -lt * */* */*/* */*/*/* */*/*/*/* ... -rw-r--r-- 1 thomas thomas 33109 Jul 5 18:39 src/Makefile.in -rw-r--r-- 1 thomas thomas4942 Nov 6 2010 debian/control -rw-r--r-- 1 thomas thomas 17375 Nov 6 2010 debian/changelog -rw-r--r-- 1 thomas thomas 894 Oct 2 2010 debian/patches/50_checksum.patch -rw-r--r-- 1 thomas thomas 114 Oct 2 2010 debian/patches/series -rw-r--r-- 1 thomas thomas 82332 Sep 5 2010 debian/patches/90_relibtoolize.patch -rw-r--r-- 1 thomas thomas 2343865 Aug 30 2010 ChangeLog ... Looks quite like the one that is installed $ ls -l /usr/bin/brasero -rwxr-xr-x 1 root root 470776 Nov 6 2010 /usr/bin/brasero You can look in `debian/changelog` for the changes applied. The number appended to the upstream version is the Debian packages version, which simply put just relates to changes in the packaging of a program and normally consists of changes in the directory `debian/` of the source package. But ./brasero-2.30.3 seems not built yet. What command next (before patching) ? Command for what? […] So there must be a way to get a bad Brasero by means of Debian and/or Ubuntu. True. Hopefully those users subscribed to the Launchpad report will chime in. But as George put, the problems are about Data projects, that means – as far as I understand – to choose some files from your disk and burn them directly to a CD/DVD medium. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
forwarded 617409 https://bugzilla.gnome.org/show_bug.cgi?id=655601 tags upstream moreinfo quit Dear rpnpif, dear Simon, Am Mittwoch, den 15.02.2012, 00:21 +0100 schrieb Simon Wenner: Here are very similar bug reports in other BTs. Many people are affected: https://bugzilla.gnome.org/show_bug.cgi?id=655601 https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 Simon, thanks for finding these upstream entries. I set the BTS tags accordingly. rpnpif, can you confirm that this is the issue you are seeing? ... and K3B works without any issues. My drive is not broken. Reading the listed reports, it looks like this is an error with the usage of or an error in libburn4 or libisofs6. I am therefore putting the libburnia folks into CC. Maybe they have an idea. rpnpif, Simon, could you try using `xorriso` [1], which also utilizes `libburn4`, to find out if that is a problem with `libburn4`. If it is, the bug needs to be reassigned and marked as affecting `brasero` or `libbrasero-media3-1`. Thanks, Paul PS: Simon, in the future could you please CC people from the bug report since I guess rpnpif after reporting that bug almost a year before your reply does not even know, that you replied. (Of course that could be wrong.) In my opinion the best practice is to do the following. Since you use a MUA/mail program that should work for you easily. Use $ bts show --mbox 617409 from the package `devscripts` to get all the messages in mbox format. Then import this mbox file from ~/.devscripts_cache/bts/ into your mail program from and reply to the appropriate message (reply to all). This keeps threading, saves time and you can quote. To answer to messages you sent, go to your Sent folder and use »Reply to all« on that message. [1] http://packages.debian.org/sid/xorriso signature.asc Description: This is a digitally signed message part
Bug#677667: fglrx crashes with X server 1.12 on 64bit architecture (was: fglrx-driver: xf86OpenConsole: Cannot find a free VT)
retitle 677667 fglrx crashes with X server 1.12 on 64bit architecture quit Am Samstag, den 16.06.2012, 20:54 +0200 schrieb Paul Menzel: […] Also it seems that there is a workaround for that issues in the upstream report [1] involving patching libpciaccess [2]. But I have not tried it yet. I got it finally working by correctly applying the patch from [2] and rebuilding `libpciaccess0` as described in comment 12 [3]. I post the updated comments here. Find out the PCI address(?) of your graphics device. $ lspci # ASRock E350M1 00:01.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9802] […] Then build the package `libpciaccess0`. $ sudo aptitude install devscripts $ sudo aptitude build-dep libpciaccess0 $ debcheckout libpciaccess0 $ cd libpciaccess0 $ # copy http://pastebin.com/swpDj4FD to file `fglrx.patch` $ editor fglrx.patch # change `pci_device_find_by_slot(0, 1, 0, 0)` to `pci_device_find_by_slot(0, 0, 1, 0)` in `src/common_interface.c` and `src/common_io.c` $ patch -p1 fglrx.patch $ dch # add entry to Debian changelog $ git commit -a $ dpkg-buildpackage -us -uc -B $ sudo dpkg -i ../libpciaccess0*.deb Thanks, Paul [1] http://ati.cchtml.com/show_bug.cgi?id=522 [2] http://ati.cchtml.com/show_bug.cgi?id=522#c3 [3] http://ati.cchtml.com/show_bug.cgi?id=522#c12 signature.asc Description: This is a digitally signed message part
Bug#676463: #676463 sysv-rc: complains incorrectly(?) about obsolete init.d scripts for fuse and others
Dear Timo, Am Montag, den 11.06.2012, 16:11 +0300 schrieb Timo Juhani Lindfors: after changing add_problematic package $package left obsolete init.d script behind in /var/lib/dpkg/info/sysv-rc.postinst to add_problematic package $package left obsolete init.d script $initscript behind I get nice, the suggestion worked. ;-) ... info: Checking if it is safe to convert to dependency based boot. Configuring sysv-rc --- Unable to migrate to dependency-based boot system Problems in the boot system exist which are preventing migration to dependency-based boot sequencing: package fuse left obsolete init.d script /etc/init.d/fuse behind, package initscripts left obsolete init.d script /etc/init.d/stop-bootlogd behind, package initscripts left obsolete init.d script /etc/init.d/bootlogd behind, package initscripts left obsolete init.d script /etc/init.d/stop-bootlogd-single behind Please take a look at #653050 [1]. […] Thanks, Paul PS: To get the whole thread do `bts show --mbox 676463`. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 signature.asc Description: This is a digitally signed message part
Bug#676463: #676463 sysv-rc: complains incorrectly(?) about obsolete init.d scripts for fuse and others
Am Montag, den 11.06.2012, 08:57 -0600 schrieb Gordon Haverland: […] Manually deleting smartmontools and smartd from /etc/init.d/ and any *smart* symlinks from /etc/rc[0-6].d/ and then doing a reinstall of smartmontools got rid of the smartmontools problems for sysv-rc. I submitted this as #677095 [1]. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677095 signature.asc Description: This is a digitally signed message part
Bug#676463: me too and more info
Am Freitag, den 08.06.2012, 19:18 -0600 schrieb Gordon Haverland:
On June 8, 2012, Paul Menzel wrote:
Am Freitag, den 08.06.2012, 16:34 -0600 schrieb Gordon Haverland:
On June 8, 2012, Paul Menzel wrote:
thank for the follow up. In the future please add the
addresses of all people who responded in that bug thread
to CC.
Even better, import the messages from the mbox you get with
bts show --mbox 676463
What mbox? I don't get any mboxen.
Did you run the command? `bts` is in package `devscripts`.
Normally mutt opens automatically, but you can exit with `q`
right away. The downloaded mbox (mail box) files is stored
under
`~/.devscripts_cache/bts/`.
I just sent an email with kmail to the bugs address for this
bug.
I know. And I did not receive your message. I had to check the
Web page manually to see if there was an answer.
Sorry, I am not a developer or a Debian maintainer. I've lived
with UNIX since 1984 and computers since 1978. At heart, I am a
FORTRAN programmer, but I've dabbled in lots of stuff. I have
more than enough other stuff to keep me busy, I was just trying to
help. Downloading other mbox to add to my kmail isn't on my list
of things I want to do.
It takes one minute and saves everyone else time. I cannot tell you what
to do with your time. But frankly every one of us even following up on
reports has »more than enough other stuff to keep her/him busy«. And
most of the time it is just a matter if you take the time, which
unfortunately I had to do now.
By the way, if it is quicker you can also download the mbox file of one
message from the »mbox« link on the HTML bug report page. To keep
threading you just need the last one.
and reply to the appropriate message to keep the threading
and ease the life of everyone.
I'm sure if I do that all the time, someone will come along
with something else I am doing wrong.
Nobody has said such things to me yet. I am pretty sure that is
the preferred way.
Over the years, I seldom reply to all. As a general principle,
it seemed to cause more problems than it solved. I will try to do
this with bugreports, but I suspect even there, I will find more
people wondering why I wrote them, than people thanking me for
writing them.
Am Freitag, den 08.06.2012, 21:40 +0100 schrieb Roger Leigh:
On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote:
I have the same packages triggering init script
warnings.
In addition, I get a warning from insserv files about
K20scsi-idle and scsi-idle missing LSB tags and
overrides.
Could you possibly attach a copy of each failing script?
Please find the scripts attached. There seem to be also
three scripts from the `initscripts` package which cause
some problems.
/etc/init.d
/etc/init.d/rmnologin
/etc/init.d/umountnfs.sh
/etc/init.d/umountroot
/etc/init.d/sendsigs
/etc/init.d/single
/etc/init.d/killprocs
/etc/init.d/hostname.sh
/etc/init.d/mountall.sh
/etc/init.d/halt
/etc/init.d/umountfs
/etc/init.d/checkfs.sh
/etc/init.d/mountall-bootclean.sh
/etc/init.d/mountnfs.sh
/etc/init.d/bootlogs
/etc/init.d/mountdevsubfs.sh
/etc/init.d/bootmisc.sh
/etc/init.d/checkroot.sh
/etc/init.d/mountnfs-bootclean.sh
/etc/init.d/skeleton
/etc/init.d/reboot
/etc/init.d/mountoverflowtmp
/etc/init.d/rc.local
/etc/init.d/mtab.sh
/etc/init.d/mountkernfs.sh
/etc/init.d/urandom
Okay, I forced dpkg to install the new initscripts package
with -- force-depends. I now get 3 mystery files from
initscripts causing problems.
I also get these errors with `initscripts` 2.88dsf-22.1
installed. Only `sysv-rc` is currently not configured on this
system.
I looked at all the files from initscripts that install in
init.d/
[…]
Ok, reading the `postinst` script
is_unsafe_to_activate() {
retval=1
# Refuse to convert when there are obsolete init.d scripts left
# behind, as these tend to confuse the boot sequence.
echo info: Checking if it is safe to convert to dependency based
boot. 12
for package in $(dpkg -S $(find /etc/init.d -type f -perm /+x) \
2/dev/null | cut -d: -f1 | sort -u); do
obsolete_initscripts=$(dpkg-query -W -f='${Conffiles}\n'
$package | \
grep 'obsolete$' | grep -o '/etc/init.d/[^ ]\+') || :
if [ $obsolete_initscripts ]; then
for initscript in $obsolete_initscripts; do
if [ -e $initscript
Bug#676463: me too and more info
Gordon, thank for the follow up. In the future please add the addresses of all people who responded in that bug thread to CC. Even better, import the messages from the mbox you get with bts show --mbox 676463 and reply to the appropriate message to keep the threading and ease the life of everyone. Am Freitag, den 08.06.2012, 21:40 +0100 schrieb Roger Leigh: On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote: I have the same packages triggering init script warnings. In addition, I get a warning from insserv files about K20scsi-idle and scsi-idle missing LSB tags and overrides. Could you possibly attach a copy of each failing script? Please find the scripts attached. There seem to be also three scripts from the `initscripts` package which cause some problems. /etc/init.d /etc/init.d/rmnologin /etc/init.d/umountnfs.sh /etc/init.d/umountroot /etc/init.d/sendsigs /etc/init.d/single /etc/init.d/killprocs /etc/init.d/hostname.sh /etc/init.d/mountall.sh /etc/init.d/halt /etc/init.d/umountfs /etc/init.d/checkfs.sh /etc/init.d/mountall-bootclean.sh /etc/init.d/mountnfs.sh /etc/init.d/bootlogs /etc/init.d/mountdevsubfs.sh /etc/init.d/bootmisc.sh /etc/init.d/checkroot.sh /etc/init.d/mountnfs-bootclean.sh /etc/init.d/skeleton /etc/init.d/reboot /etc/init.d/mountoverflowtmp /etc/init.d/rc.local /etc/init.d/mtab.sh /etc/init.d/mountkernfs.sh /etc/init.d/urandom But I do not know which. Thanks, Paul fuse Description: application/shellscript libchipcard-tools Description: application/shellscript smartmontools Description: application/shellscript signature.asc Description: This is a digitally signed message part
Bug#676463: me too and more info
Am Freitag, den 08.06.2012, 16:34 -0600 schrieb Gordon Haverland: On June 8, 2012, Paul Menzel wrote: thank for the follow up. In the future please add the addresses of all people who responded in that bug thread to CC. Even better, import the messages from the mbox you get with bts show --mbox 676463 What mbox? I don't get any mboxen. Did you run the command? `bts` is in package `devscripts`. Normally mutt opens automatically, but you can exit with `q` right away. The downloaded mbox (mail box) files is stored under `~/.devscripts_cache/bts/`. I just sent an email with kmail to the bugs address for this bug. I know. And I did not receive your message. I had to check the Web page manually to see if there was an answer. and reply to the appropriate message to keep the threading and ease the life of everyone. I'm sure if I do that all the time, someone will come along with something else I am doing wrong. Nobody has said such things to me yet. I am pretty sure that is the preferred way. Am Freitag, den 08.06.2012, 21:40 +0100 schrieb Roger Leigh: On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote: I have the same packages triggering init script warnings. In addition, I get a warning from insserv files about K20scsi-idle and scsi-idle missing LSB tags and overrides. Could you possibly attach a copy of each failing script? Please find the scripts attached. There seem to be also three scripts from the `initscripts` package which cause some problems. /etc/init.d /etc/init.d/rmnologin /etc/init.d/umountnfs.sh /etc/init.d/umountroot /etc/init.d/sendsigs /etc/init.d/single /etc/init.d/killprocs /etc/init.d/hostname.sh /etc/init.d/mountall.sh /etc/init.d/halt /etc/init.d/umountfs /etc/init.d/checkfs.sh /etc/init.d/mountall-bootclean.sh /etc/init.d/mountnfs.sh /etc/init.d/bootlogs /etc/init.d/mountdevsubfs.sh /etc/init.d/bootmisc.sh /etc/init.d/checkroot.sh /etc/init.d/mountnfs-bootclean.sh /etc/init.d/skeleton /etc/init.d/reboot /etc/init.d/mountoverflowtmp /etc/init.d/rc.local /etc/init.d/mtab.sh /etc/init.d/mountkernfs.sh /etc/init.d/urandom Okay, I forced dpkg to install the new initscripts package with -- force-depends. I now get 3 mystery files from initscripts causing problems. I also get these errors with `initscripts` 2.88dsf-22.1 installed. Only `sysv-rc` is currently not configured on this system. I looked at all the files from initscripts that install in init.d/ There are 6 files which do not have a last line which starts with a full colon. One that does has : exit 0 There are 6 files where the first executable line is not PATH= There are 6 files where the first non-empty line after ### END INIT INFO line is a comment line. There are 5 or 6 lines in the INIT INFO area, where there is no argument to the field, but there is whitespace after the full colon. I believe two of the files have a tab as the trailing whitespace, the remainder having a single space as the trailing whitespace. I think one file has both (one of each). Interesting. Did you fix these right away (and send patches)? :P Without knowing what your program is looking for, that is all I can guess at. Guess we have to check what the package scripts actually check. Time to get back to writing a presentation on NORM. Whatever NORM is, good luck with your presentation. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#676463: sysv-rc: complains incorrectly(?) about obsolete init.d scripts for fuse and others
Am Donnerstag, den 07.06.2012, 18:57 +0100 schrieb Roger Leigh: severity 676463 serious severity 676520 serious forcemerge 676463 676520 thanks On Thu, Jun 07, 2012 at 09:09:55AM +0200, Paul Menzel wrote: in contrast to earlier versions, with this version installation of `sysv-rc` fails when migration to dependency based boot fails. Additionally it complains about obsolete init.d scripts of packages which were never a problem before and whose init.d scripts do not seem to be obsolete. Previously, sysv-rc gave you two options: legacy bootordering or dependency based bootordering. You could keep the broken scripts and remain with legacy, or you could clean up the scripts and enable dependency bootordering. The change here is that we now require you to migrate to dependency based bootordering, because we will no longer support legacy static ordering. Please have a read through the details in NEWS.Debian: +sysv-rc (2.88dsf-23) experimental; urgency=low + + Dependency based boot ordering is now required. + + Most systems will already be using dependency based boot ordering. + This includes all squeeze and later releases, unless you have taken + deliberate action to disable it. Installations upgraded from etch, + lenny or earlier releases will have enabled dependency based booting + when upgrading to squeeze and later releases. However, it was + previously possible to opt out of migrating to dependency based + booting and retain static boot ordering. This is no longer the case. + + If your system is still using static boot ordering, migrating to + dependency based boot ordering will be performed when sysv-rc is + configured. If this is not possible for any reason, you will have to + correct the problem before upgrading can continue. It will not be + possible to complete the upgrade until insserv is configured. + + The most commonly encountered problem preventing migration is the + presence of obsolete init scripts from removed (but unpurged) + packages. If this is the case, you will be prompted with + instructions detailing how to purge these old packages. + + If you have custom init scripts, please ensure that these have the + correct dependency information in an LSB header so that they will be + run at the correct point in the boot sequence. + + -- Roger Leigh rle...@debian.org Wed, 18 Apr 2012 23:30:37 +0100 sysv-rc (2.88dsf-26) wird eingerichtet ... info: Checking if it is safe to convert to dependency based boot. error: Unable to migrate to dependency based boot sequencing. error: Problems detected: package fuse left obsolete init.d script behind, package initscripts left obsolete init.d script behind, package initscripts left obsolete init.d script behind, package initscripts left obsolete init.d script behind, package libchipcard-tools left obsolete init.d script behind, package smartmontools left obsolete init.d script behind, , package gdm removed but not purged If this is due to the presence of unpurged obsolete initscripts, it is suggested that the following is run to remove them: dpkg --purge fuse initscripts initscripts initscripts libchipcard-tools smartmontools This is wrong; we shouldn't be purging initscripts. Could you possibly let me know which specific files were left behind which were causing problems? We should be able to correct this during the upgrade. Also the other init.d scripts are packaged properly. Yes. The ones causing problems aren't current ones, they are obsolete ones left by removed (but not purged) packages. Purging the packages will remove them, allowing you to continue. As David pointed out in this replies too, the assumptions that the listed packages were removed is incorrect. $ LANG=C aptitude show fuse Package: fuse New: yes State: installed Automatically installed: yes Version: 2.9.0-1 Priority: optional Section: utils Maintainer: Daniel Baumann daniel.baum...@progress-technologies.net Architecture: i386 Uncompressed Size: 177 k Depends: libc6 (= 2.4), libfuse2 (= 2.9.0-1), adduser, mount (= 2.19.1), sed (= 4), udev | makedev Conflicts: fuse-utils ( 2.8.5-2~) Breaks: loop-aes-utils ( 2.16.2-3~) Replaces: fuse-utils Description: Filesystem in Userspace Filesystem in Userspace (FUSE) is a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. It also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations. Homepage: http://fuse.sourceforge.net/ This is also true for `initscripts`, `libchipcard-tools` and `smartmontools`. Ideally, we could do this automatically. I intend to look into whether we can just enable it even
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
fixed 673289 1.0.18-2 quit Dear Fabian, thank you for CCing me. Till, Tobias, please always put the reporter and responders(?) into CC. Otherwise they will (unfortunately) not be notified. Am Montag, den 21.05.2012, 22:57 +0200 schrieb Fabian Greffrath: Tobias, WDYT? Is this patch on texttopdf OK? Looks fine to me. Thanks for finally applying it! Thank you from me too. Perhaps it also fixes bug 673289. I hope so... Let's find it out. Paul, is the crash you reported in #673289 reproducable with cups-filters 1.0.18-2? No it is not. I can no longer reproduce it. lpr -PCUPS-PDF-Printer /tmp/test.txt and CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 user title 1 PageSize=A4 test.txt out.pdf work fine. As a side not Evince has problems displaying the output from CUPS-PDF. The text is not readable. Xpdf displays everything correctly though. So that issue is a separate bug in Evince I guess. I mark this bug as fixed in 1.0.18-2. I am not closing it yet since I do not know if you want it merged with #670055 or not. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
Dear Debian folks, Am Dienstag, den 22.05.2012, 00:18 +0200 schrieb Paul Menzel: fixed 673289 1.0.18-2 quit thank you for CCing me. Till, Tobias, please always put the reporter and responders(?) into CC. Otherwise they will (unfortunately) not be notified. Am Montag, den 21.05.2012, 22:57 +0200 schrieb Fabian Greffrath: Tobias, WDYT? Is this patch on texttopdf OK? Looks fine to me. Thanks for finally applying it! Thank you from me too. Perhaps it also fixes bug 673289. I hope so... Let's find it out. Paul, is the crash you reported in #673289 reproducable with cups-filters 1.0.18-2? No it is not. I can no longer reproduce it. lpr -PCUPS-PDF-Printer /tmp/test.txt and CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 user title 1 PageSize=A4 test.txt out.pdf work fine. As a side not Evince has problems displaying the output from CUPS-PDF. The text is not readable. Xpdf displays everything correctly though. So that issue is a separate bug in Evince I guess. Just more information. This seems to be a CUPS-PDF issue. $ pdffonts CUPS-PDF/test.pdf name type emb sub uni object ID - --- --- --- - [none] Type 3yes no yes 12 0 $ pdffonts /tmp/out.pdf name type emb sub uni object ID - --- --- --- - JMQJEJ+FreeMono CID TrueType yes yes no 11 0 But I think to remember, someone wrote in another bug report that CUPS-PDF is not meant for printing text. Still it is strange that Xpdf works fine. If you gave me a hint where to assign such a report to, I would be very thankful. I mark this bug as fixed in 1.0.18-2. I am not closing it yet since I do not know if you want it merged with #670055 or not. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#660345: fixed in policycoreutils 2.1.10-5
Dear Laurent, Am Donnerstag, den 22.03.2012, 11:08 +0100 schrieb Laurent Bigonville: Le Wed, 21 Mar 2012 11:57:08 +0100, Paul Menzel pm.deb...@googlemail.com a écrit : Am Dienstag, den 20.03.2012, 19:02 + schrieb Laurent Bigonville: I still get this error. $ LANG=C sudo aptitude safe-upgrade [sudo] password for paul: Resolving dependencies... The following partially installed packages will be configured: policycoreutils No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 12 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Setting up policycoreutils (2.1.10-5) ... Sandbox disabled, edit /etc/default/sandbox to enable it update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: error processing policycoreutils (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: policycoreutils E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up policycoreutils (2.1.10-5) ... Sandbox disabled, edit /etc/default/sandbox to enable it update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: error processing policycoreutils (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: policycoreutils Was the package correctly configured before you've try to update it? I've the feeling when looking at the above output, that the old package was half-installed. But this definitely looks like the script from the old version of the package. I've just tried again and it's working for me. It has been failing since I wrote the original report and was never fully configured. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#660345: fixed in policycoreutils 2.1.10-5
Am Donnerstag, den 22.03.2012, 17:53 +0100 schrieb Laurent Bigonville: Le Thu, 22 Mar 2012 17:32:07 +0100, Paul Menzel pm.deb...@googlemail.com a écrit : It has been failing since I wrote the original report and was never fully configured. What is dpkg -l policycoreutils saying? $ LANG=C dpkg -l policycoreutils […] iF policycoreutil 2.1.10-5 SELinux core policy utilities Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#660345: fixed in policycoreutils 2.1.10-5
reopen 660345 found 660345 2.1.10-5 quit Am Dienstag, den 20.03.2012, 19:02 + schrieb Laurent Bigonville: I still get this error. $ LANG=C sudo aptitude safe-upgrade [sudo] password for paul: Resolving dependencies... The following partially installed packages will be configured: policycoreutils No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 12 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Setting up policycoreutils (2.1.10-5) ... Sandbox disabled, edit /etc/default/sandbox to enable it update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: error processing policycoreutils (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: policycoreutils E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up policycoreutils (2.1.10-5) ... Sandbox disabled, edit /etc/default/sandbox to enable it update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: error processing policycoreutils (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: policycoreutils The renaming of the initscript seems to cause this. But I do not know for sure. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#662772: post-inst fails: update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force)
Package: policycoreutils Version: 2.1.10-1 Severity: serious Dear Debian folks, running `sudo aptitude safe-upgrade` the upgrade of `policycoreutils` fails with the following error message. policycoreutils (2.1.10-1) wird eingerichtet ... Neue Version der Konfigurationsdatei /etc/selinux/restorecond.conf wird installiert ... Neue Version der Konfigurationsdatei /etc/init.d/sandbox wird installiert ... Neue Version der Konfigurationsdatei /etc/default/sandbox wird installiert ... update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: Fehler beim Bearbeiten von policycoreutils (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück […] Fehler traten auf beim Bearbeiten von: policycoreutils E: Sub-process /usr/bin/dpkg returned an error code (1) Ein Paket konnte nicht installiert werden. Versuch, dies zu lösen: policycoreutils (2.1.10-1) wird eingerichtet ... update-rc.d: /etc/init.d/policycoreutils exists during rc.d purge (use -f to force) dpkg: Fehler beim Bearbeiten von policycoreutils (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück Fehler traten auf beim Bearbeiten von: policycoreutils Running `sudo aptitude safe-upgrade` again does *not* fix this issue. I am not sure if it is the same issue to the already submitted report #660345. If it is the same issue I am sorry for the duplicate report and ask you to merge both reports. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660345 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages policycoreutils depends on: ii libaudit0 1:1.7.18-1.1 ii libc6 2.13-27 ii libcap2 1:2.22-1 ii libdbus-1-3 1.4.18-1 ii libdbus-glib-1-2 0.98-1 ii libglib2.0-0 2.30.2-6 ii libpam0g 1.1.3-7 ii libpcre3 8.12-4 ii libselinux1 2.1.9-2 ii libsemanage1 2.1.6-2 ii libsepol1 2.1.4-1 ii lsb-base 3.2+Debian29 ii psmisc22.16-1 ii python2.7.2-10 ii python-selinux2.1.9-2 ii python-semanage 2.1.6-2 ii python-sepolgen 1.1.5-1 ii python-support1.0.14 Versions of packages policycoreutils recommends: pn selinux-policy-default none Versions of packages policycoreutils suggests: pn selinux-policy-dev none -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#655760: libcapi20-dev: dependency problems prevent configuration
Package: libcapi20-dev Version: 1:3.9.20060704+dfsg.3-1 Severity: grave Justification: renders package unusable Dear Debian folks, `sudo aptitude safe-upgrade` fails to upgrade `libcapi20-dev` with the following error message. dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libcapi20-dev: libcapi20-dev hängt ab von libcapi20-3 (= 1:3.9.20060704+dfsg.3-1); aber: Version von libcapi20-3 auf dem System ist 1:3.9.20060704+dfsg.2-12. dpkg: Fehler beim Bearbeiten von libcapi20-dev (--configure): Abhängigkeitsprobleme - verbleibt unkonfiguriert I guess some `Conflict` or `Breaks` fields need to be updated too. Thanks, Paul -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcapi20-dev depends on: ii libcapi20-3 1:3.9.20060704+dfsg.2-12 libcapi20-dev recommends no packages. Versions of packages libcapi20-dev suggests: pn isdnutils-doc none -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#648673: gconf2: GConf Error in Emacs, Liferea, Evolution and others (D-BUS error)
retitle 648673 gconf2: Add NEWS entry logout and -in needed after upgrade quit Am Montag, den 14.11.2011, 16:39 +0100 schrieb Vincent Lefevre: On 2011-11-14 15:27:04 +0100, Josselin Mouette wrote: Have you tried logging out and in again? The upgrade cannot, unfortunately, be conducted in a way that lets new applications in a running session work correctly. The problem disappears after logging out and in again. I just confirmed this on my system too. This is the kind of information that the user would like to know (to avoid doing the upgrade at the wrong time and to know that these kinds of errors are expected), possibly before upgrading. Perhaps the NEWS file would be the right place (new entries are displayed by apt-listchanges). If the machine has only one user (who is also the admin), he should see it; otherwise the admin can warn his users. Josselin picked up that idea. Thank you! Thanks, Paul PS: Unfortunately I did not get all responses. To keep threading people could use `bts show --mbox 648673` from package `devscripts` to import the messages from the report and reply explicitly to a message their also ensuring correct threading. signature.asc Description: This is a digitally signed message part
Bug#648673: gconf2: GConf Error in Emacs, Liferea, Evolution and others (D-BUS error)
retitle 648673 GConf Error in Emacs, Liferea, Evolution and others (D-BUS error)
quit
Am Montag, den 14.11.2011, 00:30 +0100 schrieb Vincent Lefevre:
Package: gconf2
Version: 3.2.3-1
Severity: grave
After the gconf2 upgrade, I get the following error when I run Emacs:
GConf Error: Configuration server couldn't be contacted: D-BUS error: Method
GetDefaultDatabase with signature on interface org.gnome.GConf.Server
doesn't exist
There doesn't seem to be any serious problem with Emacs, though.
Ditto with Liferea, but this is more serious, as the configuration
is not read.
Evolution does not find its configuration data either and throws error
messages and starts with the new configuration dialog.
(evolution:9622): evolution-shell-WARNING **: Der Konfigurationsserver
konnte nicht kontaktiert werden: D-BUS-Fehler: Method GetDefaultDatabase with
signature on interface org.gnome.GConf.Server doesn't exist
[…]
(evolution:9622): e-utils-WARNING **: GConf error:
Der Konfigurationsserver konnte nicht kontaktiert werden:
D-BUS-Fehler: Method GetDefaultDatabase with signature on interface
org.gnome.GConf.Server doesn't exist
I hope people have `apt-listbugs` installed. I saw this bug but thought
Evolution will not be affected.
Evince also throws some errors but missing configuration data is not so
grave.
GConf-Fehler: Der Konfigurationsserver konnte nicht kontaktiert werden:
D-BUS-Fehler: Method GetDefaultDatabase with signature on interface
org.gnome.GConf.Server doesn't exist
Luckily downgrading using the following command solved this issue for
me.
$ sudo aptitude install gconf2{,-common}=2.32.4-1 gir1.2-gconf-2.0=2.32.4-1
{gconf-defaults-service,libgconf2-4,libgconf2-dev}=2.32.4-1
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
Bug#648216: Installation failure: update-rc.d: error: start|stop arguments not terminated by .
Package: unattended-upgrades Version: 0.74.1 Severity: grave Justification: renders package unusable Dear Debian folks, running `sudo aptitude safe-upgrade` and upgrading to version 0.74.1 I get the following error. […] Setting up unattended-upgrades (0.74.1) ... Installing new version of config file /etc/apt/apt.conf.d/50unattended-upgrades ... Installing new version of config file /etc/pm/sleep.d/10_unattended-upgrades-hibernate ... Installing new version of config file /etc/init.d/unattended-upgrades ... update-rc.d: error: start|stop arguments not terminated by . usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing unattended-upgrades (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for menu ... configured to not write apport reports Errors were encountered while processing: unattended-upgrades E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up unattended-upgrades (0.74.1) ... update-rc.d: error: start|stop arguments not terminated by . usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing unattended-upgrades (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: unattended-upgrades Thanks, Paul -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages unattended-upgrades depends on: ii apt0.8.15.9 ii apt-utils 0.8.15.9 ii debconf [debconf-2.0] 1.5.41 ii lsb-release3.2-28 ii python 2.7.2-9 ii python-apt 0.8.0 ii ucf3.0025+nmu2 unattended-upgrades recommends no packages. Versions of packages unattended-upgrades suggests: ii bsd-mailx 8.1.2-0.20100314cvs-1 -- debconf information: unattended-upgrades/enable_auto_updates: false signature.asc Description: This is a digitally signed message part
Bug#648216: Installation failure: update-rc.d: error: start|stop arguments not terminated by .
Am Mittwoch, den 09.11.2011, 20:29 +0100 schrieb Michael Vogt: On Wed, Nov 09, 2011 at 06:06:07PM +0100, Paul Menzel wrote: Package: unattended-upgrades Version: 0.74.1 Severity: grave Justification: renders package unusable […] running `sudo aptitude safe-upgrade` and upgrading to version 0.74.1 I get the following error. This should be fixed now. Thanks! I'm a bit puzzled why this happend, it did not happen on my debian-box. What version of update-rc.d do you use? $ dpkg -l sysv-rc ii sysv-rc2.88dsf-13.13 […] Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#646095: midori (libwebkitgtk-1.0-0 1.61-2): symbol lookup error: midori: undefined symbol: webkit_web_view_get_selected_text
Package: midori Version: 0.4.1-1 Severity: grave Justification: renders package unusable Dear Debian folks, Midori does not start anymore after having upgraded to version 1.6.1-2 of `libwebkitgtk-1.0-0` today. Midori had been running before the upgrade. Closing it and starting it again after the upgrade I got the following error. $ midori [1] 4194 midori: symbol lookup error: midori: undefined symbol: webkit_web_view_get_selected_text I hope the fix is as easy as to be recompiled against the new library version or only proper version information in the package metadata have to be setup. Thanks, Paul -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages midori depends on: ii dbus-x111.4.16-1 ii libc6 2.13-21 ii libcairo2 1.10.2-6.1 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libglib2.0-02.28.6-1 ii libgtk2.0-0 2.24.7-1 ii libnotify4 0.7.4-1 ii libpango1.0-0 1.29.4-2 ii libsoup2.4-12.36.0-1 ii libsqlite3-03.7.8-1 ii libunique-1.0-0 1.1.6-2 ii libwebkitgtk-1.0-0 1.6.1-2 ii libx11-62:1.4.4-2 ii libxml2 2.7.8.dfsg-5 ii libxss1 1:1.2.1-2 Versions of packages midori recommends: ii gnome-icon-theme 3.2.1.2-1 midori suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
