Bug#911067: chromium: Conflict with chrome-gnome-shell /etc/chromium
Hello, 2018 m. spalio 15 d., pirmadienis 16:11:38 EEST Patrick Franz rašė: > > > > dpkg: erreur de traitement de l'archive /var/cache/apt/archives/ > > chromium_70.0.3538.54-2_amd64.deb (--unpack) : > > tentative de remplacement du répertoire « /etc/chromium » dans le > > paquet chrome-gnome-shell 10.1-1 avec un élément de type différent > > In my case, it conflicts with plasma-browser-integration, but I think > it's the same error: > > dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/ > chromium_70.0.3538.54-2_amd64.deb (--unpack): > Versuch, Verzeichnis »/etc/chromium« in Paket plasma-browser- > integration 5.13.5-1 mit Nichtverzeichnis zu überschreiben > > > Essentially it says, that it tries to override /etc/chromium in the > package plasma-browser-integration with a "non-directory". Since they ship native message hosts which are configured via /etc/chromium/ native-messaging-hosts/*.json according to https://developer.chrome.com/apps/ nativeMessaging I guess the change should be reverted as other location would conflict with official documentation ...
Bug#802886: vlc: QT Interface wont full screen or renders only a small portion of the video
Control: tags -1 upstream Hello, Šeštadienis 24 Spalis 2015 11:34:11 rašė: > When using the QT interface in VLC, I can no longer doubleclick a video and > full screen it. When playing a video parts of it are masked off/cropped . > So only a small area approximatly 530x290 is visable. I've disabled overlay > with no effect. Resizing the video into the small visable area is the only > way to see the entire video uncropped. > > If I however run the command cvlc the video the full size and > have no issue fullscreening the video. It seems that the issue might be > with QT, but I am unsure how to figure out what the offending package > maybe. This was caused by upgrade from Qt 5.4 to 5.5. It is either vlc [1] or Qt 5.5 [2] issue (latter being more likely). I leave it up to maintainer to decide whether to reassign. However, from a user POV, vlc is basically unusable for video with this bug in place. There are two bugs here though: 1) double-click not working for full-screening. Can be worked around by setting QT_XCB_NO_XI2_MOUSE=1 when starting vlc [3]: $ QT_XCB_NO_XI2_MOUSE=1 vlc 2) video is only partially visible. Not aware of any workarounds yet. [1] https://trac.videolan.org/vlc/ticket/15663 [2] https://bugreports.qt.io/browse/QTBUG-48321 [3] https://trac.videolan.org/vlc/ticket/15663#comment:3 -- Modestas Vainius <modes...@vainius.eu>
Bug#802908: requires python3-gi to run
Package: caffeine Version: 2.8.3-1 Severity: serious Hello, caffeine uses modules from python3-gi and needs them to run (see below): Traceback (most recent call last): File "/usr/bin/caffeine", line 25, in from gi.repository import GObject, Gtk, GLib -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages caffeine depends on: ii gir1.2-appindicator3-0.1 0.4.92-3.1 ii gir1.2-gtk-3.03.18.2-1 ii libnet-dbus-perl 1.1.0-3 ii perl 5.20.2-6 ii python3 3.4.3-7 ii python3-pkg-resources 18.4-1 ii python3-xlib 0.14+20091101-5 pn python3:any caffeine recommends no packages. caffeine suggests no packages. -- no debconf information
Bug#741342: /usr/sbin/update-grub: update-grub writes root=UUID= to grub.cfg for LVM2, renders machine unbootable
Package: grub2-common
Version: 2.02~beta2-7
Severity: critical
File: /usr/sbin/update-grub
Justification: breaks the whole system
Hello,
update-grub writes root=UUID=xx for LVM2 volumes to kernel command line.
This renders the system unbootable since it is not supported as far as I can
tell.
Hence, if I replace root=UUID=af89a290-9c6f-4039-8d5c-95aa75654776 with
root=/dev/mapper/mdxinventi-root, the system boots fine.
P.S. It appears that 2.02~beta2-7 has been uploaded to unstable even if
the changelog indicates that it was targeted to experimental.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/mdxinventi-root / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot ext2 rw,relatime 0 0
/dev/mapper/mdxinventi-home /home ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-ST9500423AS_5WR0GXYW
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
else
set default=0
fi
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set
root='lvmid/nqfp4d-BOkJ-OIVj-Uigv-ysEo-NOTR-8Xy1pJ/0TBnxh-eEPl-YGJO-6Q4E-9MRF-6qic-fIRzyl'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/nqfp4d-BOkJ-OIVj-Uigv-ysEo-NOTR-8Xy1pJ/0TBnxh-eEPl-YGJO-6Q4E-9MRF-6qic-fIRzyl'
af89a290-9c6f-4039-8d5c-95aa75654776
else
search --no-floppy --fs-uuid --set=root af89a290-9c6f-4039-8d5c-95aa75654776
fi
font=/usr/share/grub/unicode.pf2
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=lt_LT
insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
set timeout=-1
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod lvm
insmod ext2
set
root='lvmid/nqfp4d-BOkJ-OIVj-Uigv-ysEo-NOTR-8Xy1pJ/0TBnxh-eEPl-YGJO-6Q4E-9MRF-6qic-fIRzyl'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/nqfp4d-BOkJ-OIVj-Uigv-ysEo-NOTR-8Xy1pJ/0TBnxh-eEPl-YGJO-6Q4E-9MRF-6qic-fIRzyl'
af89a290-9c6f-4039-8d5c-95aa75654776
else
search --no-floppy --fs-uuid --set=root af89a290-9c6f-4039-8d5c-95aa75654776
fi
insmod png
if background_image /usr/share/images/desktop-base/joy-grub.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-af89a290-9c6f-4039-8d5c-95aa75654776' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'
77b9f482-78cc-4625-885e-1d6489b84fc1
else
search --no-floppy --fs-uuid --set=root
77b9f482-78cc-4625-885e-1d6489b84fc1
fi
echo'Loading Linux 3.13-1-amd64 ...'
linux /vmlinuz-3.13-1-amd64
root=UUID=af89a290-9c6f-4039-8d5c-95aa75654776 ro splash quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-3.13-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
Bug#732342: samba-libs: hdb_samba4.so broken
Package: samba-libs Version: 2:4.0.13+dfsg-1 Severity: serious Hello, as far as I can tell, all samba = 2:4.0.12+dfsg-1 versions have broken hdb_samba4.so. I.e. samba-tool domain exportkeytab SEGFAULTs and I'm able to remotely crash samba daemon process with some simple msktutil magic. I was not able to get proper a backtrace from 4.0.13 version (corrupted stack) but e.g. `samba -M single -i -d 10` dies right after UDP packet from msktutil is received (just after Starting GENSEC mechanism krb5 is printed in the output). I guess that 26_heimdal_compat patch is incomplete or broken but I cannot confirm that. Downgrading samba to 4.0.11 and heimdal to 1.6~git20120403+dfsg1-2 makes it work again. Tested on up-to-date testing. signature.asc Description: This is a digitally signed message part.
Bug#732344: samba-libs: hdb_samba4.so: too loose dependency on heimdal
Package: samba-libs Version: 2:4.0.13+dfsg-1 Severity: serious Hello, as far as I can tell, hdb_samba4.so built against heimdal 1.6~git20131117+dfsg-3 can no longer work with heimdal 1.6~git20120403+dfsg1-2 due to bumped plugin interface version. However, samba-libs dependencies do not indicate this requirement (heimdal = 1.4.0+git20110226 there only) As a result, partial upgrades are possible. What is more, I think it may not be enough to bump heimdal dep to the latest version. Actually, you should ensure that older samba-libs does not get used with newer (i.e. with bumped plugin interface) heimdal. Probably this would be best achieved by heimdal exporting its plugin interface version (as virtual package) via shlibs/symbols so all plugins could pick it up automagically (provided there is a symbol in heimdal all plugins will use). So I'm CC'ing heimdal maintainers as well. signature.asc Description: This is a digitally signed message part.
Bug#731089: cmake: changes to libfreetype6-dev break FindPackage(Freetype)
Hello, Sekmadienis 15 Gruodis 2013 11:54:36 Cyril Brulebois rašė: I've uploaded the fixed package to DELAYED/2. Please tell me if I should reschedule it to a different DELAYED queue. Please delay this NMU by another 2 days. I plan to look at this related stuff soon but if I don't make it, your NMU will be good enough. signature.asc Description: This is a digitally signed message part.
Bug#726341: ideviceinstaller: FTBFS against libimobildevice 1.1.5
Hello, Antradienis 19 Lapkritis 2013 20:24:36 Andreas Metzler rašė: Šeštadienis 09 Lapkritis 2013 09:29:29 rašė: This FTBFS is now happening in sid, so bumping this to serious. This is currently stalling the libimobildevice transition. Could you NMU ideviceinstaller in unstable? It seems to have built fine on all arches in experimental. Hello, I can, but I will not be able to this week. I expect it would take until monday 26th. Ok, I have some time so I will do it today then. signature.asc Description: This is a digitally signed message part.
Bug#729545: libmtp-dev dependency issue on kfreebsd
Control: reassign -1 libgphot2-2-dev 2.4.14-2.3 Hello, Sekmadienis 17 Lapkritis 2013 19:17:31 Markus Koschany rašė: I prepared the last NMU for libgphoto2 because we ran into a similar issue with sane-backends back then. I agree that libmtp-dev needs to be fixed too. However I also think that the dependency on libusbx/libusb2 can be dropped completely from libgphot2-2-dev because the reason for that, described in #407108, no longer holds true. See also http://bugs.debian.org/717914, that libgphoto2-2-dev should not depend on libusb-1.0-0-dev anymore. Looks like you are right: libusb-1.0-0-dev should be dropped from libgphot2-2- dev depends. I will prepare a NMU. signature.asc Description: This is a digitally signed message part.
Bug#729806: A full build of libmtp fails on non-Linux
Source: libmtp Version: 1.1.6-20-g1b9f164-1 Severity: serious Hello, it seems that a full build of libmtp can only be done on Linux. That's because libmtp-common contains Linux-only file(s): /usr/share/hal/fdi/information/20thirdparty/20-libmtp9.fdi /lib/udev/rules.d/69-libmtp.rules (probably) which libmtp build system does not install on non-Linux OSes. For example, the attached build.log file contains full build FTBFS on kfreebsd-amd64. -- Modestas Vainius mo...@debian.org dpkg-buildpackage: source package libmtp dpkg-buildpackage: source version 1.1.6-20-g1b9f164-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Alessio Treglia ales...@debian.org dpkg-source --before-build libmtp-1.1.6-20-g1b9f164 dpkg-buildpackage: host architecture kfreebsd-amd64 fakeroot debian/rules clean dh clean --with autoreconf dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' rm -f mtp-tools.1 debian/libmtp9.docs debian/libmtp9.install debian/libmtp9.preinst debian/libmtp9.postinst 20-libmtp9.fdi # Restore original file test ! -e src/gphoto2-endian.h-orig \ || mv src/gphoto2-endian.h-orig src/gphoto2-endian.h dh_auto_clean make[1]: Leaving directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' debian/rules override_dh_autoreconf_clean make[1]: Entering directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' rm -rf config.rpath dh_autoreconf_clean make[1]: Leaving directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' dh_clean dpkg-source -b libmtp-1.1.6-20-g1b9f164 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building libmtp using existing ./libmtp_1.1.6-20-g1b9f164.orig.tar.gz dpkg-source: info: building libmtp in libmtp_1.1.6-20-g1b9f164-1.debian.tar.gz dpkg-source: info: building libmtp in libmtp_1.1.6-20-g1b9f164-1.dsc debian/rules build dh build --with autoreconf dh_testdir debian/rules override_dh_autoreconf make[1]: Entering directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' cp /usr/share/gnulib/build-aux/config.rpath . dh_autoreconf libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:10: installing './compile' configure.ac:13: installing './config.guess' configure.ac:13: installing './config.sub' configure.ac:5: installing './install-sh' configure.ac:5: installing './missing' examples/Makefile.am: installing './depcomp' make[1]: Leaving directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' debian/rules override_dh_auto_configure make[1]: Entering directory `/home/modax/ftbfs/libmtp-1.1.6-20-g1b9f164' sed s/@SOVERSION@/9/g debian/libmtp.docs.in debian/libmtp9.docs sed s/@SOVERSION@/9/g debian/libmtp.install.in debian/libmtp9.install sed s/@SOVERSION@/9/g debian/libmtp.preinst.in debian/libmtp9.preinst sed s/@SOVERSION@/9/g debian/libmtp.postinst.in debian/libmtp9.postinst # Save file modified by configure ( test -e src/gphoto2-endian.h-orig -o ! \( -e src/gphoto2-endian.h \) ) \ || cp src/gphoto2-endian.h src/gphoto2-endian.h-orig dh_auto_configure -- --enable-static=no --enable-doxygen configure: WARNING: unrecognized options: --disable-maintainer-mode checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking whether ln -s works... yes checking build system type... x86_64-pc-kfreebsd-gnu checking host system type... x86_64-pc-kfreebsd-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length
Bug#729545: libmtp-dev dependency issue on kfreebsd
Control: reassign -1 libmtp-dev 1.1.6-20-g1b9f164-1
Hello,
Ketvirtadienis 14 Lapkritis 2013 03:12:20 rašė:
Package: libgphoto2-2-dev
Version: 2.4.14-2.3
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Control: block 725951 by -1
Hi,
The recent change to the libusb dependency of libgphoto2-2-dev created
an odd problem on kfreebsd when trying to build gvfs:
https://buildd.debian.org/status/package.php?p=gvfs
gvfs build-depends on:
- libgphoto2-2-dev (= 2.4.0)
libgphoto2-2-dev depends on:
- libusb-1.0-0-dev | --virtual-libusb-1.0-0-dev
gvfs build-depends on:
- libmtp-dev (= 1.1.0)
libmtp-dev depends on:
- libusb-dev
libusb2-dev conflicts with:
- libusb-dev
kfreebsd has its own libusb-dev different from the implementations
available on linux.
I wouldn't be so sure that libgphoto2 is the one which needs to be fixed. In
my opinion, here libmtp-dev does the wrong thing. libusb-1.0 home page[1]
says:
-
FreeBSD 8 and above include a FreeBSD-specific reimplementation of the
libusb-1.0 API, so your applications will probably work there too. The source
code for this library can be found here.
-
Having in mind that libusb-0.1 is deprecated, it seems that the whole libusb*
packaging structure (i.e. libusb-1.0-0-dev virtual package on kFreeBSD) in
Debian is meant to establish that libusbx should be used on Linux while
libusb2 from freebsd-libs should be used on kFreeBSD. I might be wrong so I'm
also CC'ing libusbx and kFreeBSD maintainers. I will reassign the bug back to
libgphoto2-2-dev if that's the case.
So the attached patch once applied against libmtp would also solve the
problem. I have verified that resulting libmtp actually builds on both
kfreebsd-amd64/sid and linux-amd64/sid. I haven't checked that it works on
kfreebsd-amd64 though but very likely it is safe to assume that it would.
[1] http://www.libusb.org/wiki/libusb-1.0
--
Modestas Vainius mo...@debian.orgdiff -Nru libmtp-1.1.6-20-g1b9f164/debian/changelog libmtp-1.1.6-20-g1b9f164/debian/changelog
--- libmtp-1.1.6-20-g1b9f164/debian/changelog 2013-08-23 11:22:41.0 +0300
+++ libmtp-1.1.6-20-g1b9f164/debian/changelog 2013-11-17 18:04:40.0 +0200
@@ -1,3 +1,9 @@
+libmtp (1.1.6-20-g1b9f164-1.1) UNRELEASED; urgency=low
+
+ * Build against libusb2 on kfreebsd-any. (Closes: #729545)
+
+ -- Modestas Vainius mo...@debian.org Sun, 17 Nov 2013 14:37:35 +
+
libmtp (1.1.6-20-g1b9f164-1) unstable; urgency=low
* New upstream release.
diff -Nru libmtp-1.1.6-20-g1b9f164/debian/control libmtp-1.1.6-20-g1b9f164/debian/control
--- libmtp-1.1.6-20-g1b9f164/debian/control 2013-08-23 11:21:28.0 +0300
+++ libmtp-1.1.6-20-g1b9f164/debian/control 2013-11-17 18:04:40.0 +0200
@@ -13,8 +13,8 @@
dpkg-dev (= 1.13.19),
gnulib,
libgcrypt11-dev,
- libusb-1.0-0-dev [linux-any],
- libusb-dev [!linux-any],
+ libusb-1.0-0-dev [!hurd-i386],
+ libusb-dev [hurd-i386],
lsb-release,
pkg-config,
xsltproc
@@ -96,8 +96,8 @@
Architecture: any
Depends:
libmtp9 (= ${binary:Version}),
- libusb-1.0-0-dev [linux-any],
- libusb-dev [!linux-any],
+ libusb-1.0-0-dev [!hurd-i386],
+ libusb-dev [hurd-i386],
${misc:Depends}
Multi-Arch: same
Description: Media Transfer Protocol (MTP) development files
diff -Nru libmtp-1.1.6-20-g1b9f164/debian/control.in libmtp-1.1.6-20-g1b9f164/debian/control.in
--- libmtp-1.1.6-20-g1b9f164/debian/control.in 2013-08-23 11:20:52.0 +0300
+++ libmtp-1.1.6-20-g1b9f164/debian/control.in 2013-11-17 18:20:37.0 +0200
@@ -13,8 +13,8 @@
dpkg-dev (= 1.13.19),
gnulib,
libgcrypt11-dev,
- libusb-1.0-0-dev [linux-any],
- libusb-dev [!linux-any],
+ libusb-1.0-0-dev [!hurd-i386],
+ libusb-dev [hurd-i386],
lsb-release,
pkg-config,
xsltproc
@@ -96,8 +96,8 @@
Architecture: any
Depends:
libmtp@SOVERSION@ (= ${binary:Version}),
- libusb-1.0-0-dev [linux-any],
- libusb-dev [!linux-any],
+ libusb-1.0-0-dev [!hurd-i386],
+ libusb-dev [hurd-i386],
${misc:Depends}
Multi-Arch: same
Description: Media Transfer Protocol (MTP) development files
diff -Nru libmtp-1.1.6-20-g1b9f164/debian/patches/kfreebsd_libusb2.patch libmtp-1.1.6-20-g1b9f164/debian/patches/kfreebsd_libusb2.patch
--- libmtp-1.1.6-20-g1b9f164/debian/patches/kfreebsd_libusb2.patch 1970-01-01 03:00:00.0 +0300
+++ libmtp-1.1.6-20-g1b9f164/debian/patches/kfreebsd_libusb2.patch 2013-11-17 18:04:40.0 +0200
@@ -0,0 +1,17 @@
+Description: Make libmtp built against libusb2-dev on kFreeBSD
+Author: Modestas Vainius mo...@debian.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729545
+Origin: vendor
+Last-Update: 2013-11-17
+
+--- libmtp-1.1.6-20-g1b9f164.orig/src/libusb-glue.h
libmtp-1.1.6-20-g1b9f164/src/libusb-glue.h
+@@ -32,7 +32,7 @@
+
+ #include ptp.h
+ #ifdef HAVE_LIBUSB1
Bug#726341: ideviceinstaller: FTBFS against libimobildevice 1.1.5
Hello Andreas, Šeštadienis 09 Lapkritis 2013 09:29:29 rašė: This FTBFS is now happening in sid, so bumping this to serious. This is currently stalling the libimobildevice transition. Could you NMU ideviceinstaller in unstable? It seems to have built fine on all arches in experimental. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#729545: libmtp-dev dependency issue on kfreebsd
Control: forcemerge -1 729249 Sekmadienis 17 Lapkritis 2013 17:56:12 Aurelien Jarno rašė: On Sun, Nov 17, 2013 at 06:27:54PM +0200, Modestas Vainius wrote: Control: reassign -1 libmtp-dev 1.1.6-20-g1b9f164-1 Hello, Ketvirtadienis 14 Lapkritis 2013 03:12:20 rašė: Package: libgphoto2-2-dev Version: 2.4.14-2.3 Severity: serious Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd Control: block 725951 by -1 Hi, The recent change to the libusb dependency of libgphoto2-2-dev created an odd problem on kfreebsd when trying to build gvfs: https://buildd.debian.org/status/package.php?p=gvfs gvfs build-depends on: - libgphoto2-2-dev (= 2.4.0) libgphoto2-2-dev depends on: - libusb-1.0-0-dev | --virtual-libusb-1.0-0-dev gvfs build-depends on: - libmtp-dev (= 1.1.0) libmtp-dev depends on: - libusb-dev libusb2-dev conflicts with: - libusb-dev kfreebsd has its own libusb-dev different from the implementations available on linux. I wouldn't be so sure that libgphoto2 is the one which needs to be fixed. In my opinion, here libmtp-dev does the wrong thing. libusb-1.0 home page[1] says: -- --- FreeBSD 8 and above include a FreeBSD-specific reimplementation of the libusb-1.0 API, so your applications will probably work there too. The source code for this library can be found here. -- --- Having in mind that libusb-0.1 is deprecated, it seems that the whole libusb* packaging structure (i.e. libusb-1.0-0-dev virtual package on kFreeBSD) in Debian is meant to establish that libusbx should be used on Linux while libusb2 from freebsd-libs should be used on kFreeBSD. I might be wrong so I'm also CC'ing libusbx and kFreeBSD maintainers. I will reassign the bug back to libgphoto2-2-dev if that's the case. This is exactly what I suggested in bug #729249. Hello, ok, let's merge them then. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#729239: clementine: FTBFS on kfreebsd-*: /usr/bin/ld: cannot find -lexecinfo
Control: tags -1 patch
Hello,
Sekmadienis 10 Lapkritis 2013 18:20:30 rašė:
Thanks for solving the problem with libimobiledevice; it is much
appreicated. Unfortunately, it seems that the new version of
clementine FTBFS on kfreebsd-{i386,amd64}:
Linking CXX executable ../../clementine-tagreader
cd
/«BUILDDIR»/clementine-1.2.0+dfsg/obj-x86_64-kfreebsd-gnu/ext/clementine-ta
greader /usr/bin/cmake -E cmake_link_script
CMakeFiles/clementine-tagreader.dir/link.txt --verbose=1 /usr/bin/c++
-DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT --std=c++0x -U__STRICT_ANSI__
-O2 -g -DNDEBUG -Wl,-z,relro
CMakeFiles/clementine-tagreader.dir/main.cpp.o
CMakeFiles/clementine-tagreader.dir/tagreaderworker.cpp.o
CMakeFiles/clementine-tagreader.dir/qrc_data.cxx.o -o
../../clementine-tagreader -ltag -lQtCore -lQtNetwork
../libclementine-common/liblibclementine-common.a
../libclementine-tagreader/liblibclementine-tagreader.a -lexecinfo
../libclementine-common/liblibclementine-common.a -lprotobuf -ltag
-lpthread /usr/bin/ld: cannot find -lexecinfo
collect2: error: ld returned 1 exit status
make[4]: *** [clementine-tagreader] Error 1
[...]
Sadly, this failure is preventing us from benefiting from your
libimobiledevice fix (as clementine cannot migrate to testing while it
has out of date binaries on kfreebsd).
The attached patch is sufficient to fix this bug (tested).
--
Modestas Vainius mo...@debian.orgDescription: Tighten FreeBSD system name check not to match kFreeBSD
Author: Modestas Vainius mo...@debian.org
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729239
Origin: vendor
Last-Update: 2013-11-17
CMAKE_SYSTEM_NAME on GNU/kFreeBSD is kFreeBSD so we cannot use MATCHES
(regexp) operation here.
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1287,7 +1287,7 @@ if (UNIX AND NOT APPLE)
# they end up getting ignored. This appends them to the very end of the link
# line, ensuring they're always used.
find_package(X11)
- if (${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
+ if (${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
target_link_libraries(clementine_lib ${X11_X11_LIB})
else ()
target_link_libraries(clementine_lib ${X11_X11_LIB} ${CMAKE_DL_LIBS})
@@ -1320,9 +1320,9 @@ add_executable(clementine
main.cpp
)
-if (${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
+if (${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
target_link_libraries(clementine execinfo)
-endif (${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
+endif (${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
target_link_libraries(clementine
clementine_lib
--- a/ext/clementine-tagreader/CMakeLists.txt
+++ b/ext/clementine-tagreader/CMakeLists.txt
@@ -33,11 +33,11 @@ target_link_libraries(clementine-tagread
libclementine-tagreader
)
-if(${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
+if(${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
target_link_libraries(clementine-tagreader
execinfo
)
-endif(${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
+endif(${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
if(APPLE)
target_link_libraries(clementine-tagreader
signature.asc
Description: This is a digitally signed message part.
Bug#710920: [Pkg-kde-extras] Bug#710920: Bug#710920: amarok: GREPME MySQLe query failed! (2000) on init
Hello, 2013.06.11 11:38, Olivier Aubert rašė: Should this bug really be marked as fixed? This renders it quite difficult to find through the standard Debian BTS. I had the issue, and my first reflex is to check the BTS - I did not find any info about it so I turned to google, which luckily gave me the #710920 reference. It is marked as a duplicate of #710877, which is displayed by the BTS but with a less specific subject, so it is harder to pinpoint. Could there be a possibility of enhancing the visibility of #710920 at least as long as the faulty package is still in testing? amarok 2.7.1 has just migrated to testing so the problem is no longer relevant. I do agree, however, that BTS quite hides bugs which are only relavant to testing but it is as it is. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710705: [Pkg-kde-extras] Bug#710705: amarok: FTBFS (cp: cannot stat 'debian/tmp/usr/lib/kde4/amarok_context_applet_similarArtists.so': No such file or directory)
Hello, I'm aware of the failure and I will upload a new upstream release soon which fixes this. This mini-transition (liblastfm, amarok, clementine) was coordinated. Šeštadienis 01 Birželis 2013 19:17:14 Adam D. Barratt rašė: Source: amarok Version: 2.6.0-1 Severity: serious Tags: jessie sid Hi, amarok FTBFS when rebuilt against liblastfm1 (on at least amd64 and kfreebsd-amd64). From the amd64 build log: make[1]: Entering directory `/«PKGBUILDDIR»' dh_install cp: cannot stat 'debian/tmp/usr/lib/kde4/amarok_context_applet_similarArtists.so': No such file or directory dh_install: cp -a debian/tmp/usr/lib/kde4/amarok_context_applet_similarArtists.so debian/amarok//usr/lib/kde4/ returned exit code 1 make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 Full logs available via https://buildd.debian.org/status/package.php?p=amarok Regards, Adam ___ pkg-kde-extras mailing list pkg-kde-ext...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras signature.asc Description: This is a digitally signed message part.
Bug#708928: regression from 3.20-4: cannot connect to some gateways
Package: openconnect Version: 4.99-2 Severity: grave Tags: upstream Hello, I'm no longer able to connect to the gateway (which address I can't reveal) with 4.99-2 while it was possible with 3.20-4 shipped in wheezy (downgrading to that version in current sid helps as well). Currently I get: # openconnect -v https://gwaddress.example.com/ Attempting to connect to server xx.xx.xx.xx:443 SSL negotiation with gwaddress.example.com Connected to HTTPS on gwaddress.example.com POST https://gwaddress.example.com/ Failed to read from SSL socket: A TLS packet with unexpected length was received. Error fetching HTTPS response GET https://gwaddress.example.com/ Failed to write to SSL socket: The specified session has been invalidated for some reason. Failed to obtain WebVPN cookie I.e. I even don't get to the phase where I should enter username/password. On the contrary, with 3.20 I get: # openconnect -v https://gwadddress.example.com/ Attempting to connect to xx.xxx.xx.xx:443 SSL negotiation with gwadddress.example.com Matched DNS altname 'gwadddress.example.com' Connected to HTTPS on gwadddress.example.com GET https://gwadddress.example.com/ Got HTTP response: HTTP/1.1 303 See Other Content-Type: text/html Content-Length: 0 Location: https://gwadddress.example.com:443/webvpn.html Set-Cookie: webvpncontext=00@webvpn; path=/ Connection: Keep-Alive HTTP body length: (0) GET https://gwadddress.example.com/webvpn.html Got HTTP response: HTTP/1.1 200 OK Cache-Control: max-age=0 Content-Type: text/html Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/ Set-Cookie: webvpncontext=00@webvpn; path=/ X-Transcend-Version: 1 Content-Length: 473 Connection: close HTTP body length: (473) Fixed options give Please enter your username and password. USERNAME: What is more, I tested 5.00 and saw no improvement. P.S. I know this bug is lacking information but I will try to provide something more definitive later. Feel free to ask. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openconnect depends on: ii libc62.17-3 ii libgnutls26 2.12.23-4 ii liboath0 2.0.2-2 ii libopenconnect2 5.00-0mdx1 ii libproxy00.3.1-6 ii libssl1.0.0 1.0.1e-2 ii libxml2 2.8.0+dfsg1-7+nmu1 ii vpnc-scripts 0.1~git20120602-2 ii zlib1g 1:1.2.8.dfsg-1 openconnect recommends no packages. openconnect suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708928: regression from 3.20-4: cannot connect to some gateways
Hello, Sekmadienis 19 Gegužė 2013 16:01:24 Modestas Vainius rašė: I'm no longer able to connect to the gateway (which address I can't reveal) with 4.99-2 while it was possible with 3.20-4 shipped in wheezy (downgrading to that version in current sid helps as well). Currently I get: # openconnect -v https://gwaddress.example.com/ Attempting to connect to server xx.xx.xx.xx:443 SSL negotiation with gwaddress.example.com Connected to HTTPS on gwaddress.example.com POST https://gwaddress.example.com/ Failed to read from SSL socket: A TLS packet with unexpected length was received. Error fetching HTTPS response GET https://gwaddress.example.com/ Failed to write to SSL socket: The specified session has been invalidated for some reason. Failed to obtain WebVPN cookie I.e. I even don't get to the phase where I should enter username/password. more info: I have built 5.00 against OpenSSL. That didn't help either: # openconnect --no-cert-check -v https://gwaddress.example.com/ Attempting to connect to server xx.xx.xx.xx:443 SSL negotiation with gwaddress.example.com Matched DNS altname 'gwaddress.example.com' Connected to HTTPS on gwaddress.example.com POST https://gwaddress.example.com/ Failed to read from SSL socket Error fetching HTTPS response GET https://gwaddress.example.com/ Failed to read from SSL socket Error fetching HTTPS response Failed to obtain WebVPN cookie So it seems to be a bug in the codebase rather than GnuTLS issue. signature.asc Description: This is a digitally signed message part.
Bug#681121: [Pkg-kde-extras] Bug#681121: Bug#681121: amarok: attempts to upgrade MySQL database on every application start
Control: severity -1 normal Control: title -1 amarok database is stuck at version 7 (amarok 2.2.0) Control: tags -1 upstream Hello, On Thursday 12 July 2012 15:02:44 Ira Rice wrote: 020 A C K soh nul nul nul nul soh nul dc1 nul ~ nl D B 4341014b000100110afe4244 040 _ V E R S I O N bel nul nul nul soh nul nak nul 565f524549534e4f000700010015 It seems that your database is at version 7 (which is amarok 2.2.0) while current version is 14. Apparently, amarok has not fully succeeded in updating the database since then... So each time amarok starts, it runs (or not) 7 upgrade scripts some of which have already been completed probably. Since the code does not appear to have a sence of database transactions (as far as I can tell anyway, I might be wrong), your database might already be in inconsistent state. Therefore, I strongly recommend to backup and purge database, then start from scratch (and export playlists/other data to external files beforehand). Alternatively you could run: $ amarok --debug --nofork 21 | tee amarok-debug.log wait for amarok to start, close it and then attach amarok-debug.log. What is more, take notice of which statement amarok gets stuck at if any. However, I doubt this will take us far since the only way to fix your dabatase is to hack it manually. I'm marking this bug as normal since 2.2.0 has never been in stable (first version in stable is 2.4.3) and iirc, 2.3 series had some nasty bugs which might have led to this state after all. signature.asc Description: This is a digitally signed message part.
Bug#662103: Pausing and resuming in Amarok changes volume to 100%
Hello, On Wednesday 08 August 2012 13:57:24 Robert Keevil wrote: reopen 662103 thanks Hi, Just to confirm that the problem still exists with the 0.5.0+14.g382da0d-2 version. Please retest with 0.6.0-1. It will hit unstable soon. signature.asc Description: This is a digitally signed message part.
Bug#681121: [Pkg-kde-extras] Bug#681121: amarok: attempts to upgrade MySQL database on every application start
Hello, On Tuesday 10 July 2012 13:07:23 Ira Rice wrote: In the NEWS file for 2.6~beta1, it mentioned that for smaller playlists, there would be a few minute delay while it updated the database format. There is no NEWS file in amarok packaging. You are probably referring to changelog.gz Anyway, could you exactly quote the changelog entry you are referring to? However, I have a larger database (4600+ tracks in a playlist, with more on disk), and this takes more along the lines of 1 1/2 to 2 hours, where it then doesn't give any obvious indication that it is then doing anything (but which I can verify that it's upgrading the tables through MySQL Workbench). Can you paste what $ cat ~/.kde/share/apps/amarok/mysqle/amarok/admin.MYD | od -a -x returns? You may get more help by reporting the bug to https://bugs.kde.org though. signature.asc Description: This is a digitally signed message part.
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
Hello, On Thursday 12 July 2012 20:47:59 Nicholas Breen wrote: On Wed, Jul 11, 2012 at 03:44:22PM -0400, Brad King wrote: This should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8720aa04 Ideally we should add a test for this case but I have no time now. We'll include the fix in the next 2.8.9 rc. Thank you very much for tracking down the bug. Modestas, do you think it's worth applying that patch to the cmake package and requesting a freeze exception from the RMs? The plan is to ship Wheezy with cmake 2.8.9 final. I have uploaded 2.8.9-rc1 this early in order to catch the auto-freeze-exception train and minimize diff. 2.8.9-rc1 - 2.8.9 will only contain bug fixes anyway. I'm not sure if it affects any other packages in the archive, but I cannot find any other outright failures in this batch of FTBFS bugs that date from after the 2.8.9-rc1 upload, so it might well be just this one case. Feel free to reassign/clone this bug to cmake. Otherwise I'll hash out a workaround for gromacs to keep it from getting removed as RC-buggy. I will upload 2.8.9-rc2 to unstable once its released (which should not take long). signature.asc Description: This is a digitally signed message part.
Bug#679789: trying to overwrite '/usr/share/doc/kde/HTML/en/konqueror/format-font-size-less.png', which is also in package kdebase-data 4:4.6.5-1
Hello, On Thursday 05 July 2012 22:28:36 K L wrote: What's the status of the bug? My system cannot do upgrade anymore. Is there a way to revert back or allow me upgrade again? We have to wait a bit. Anyway: dpkg --force-overwrite -i /var/cache/apt/archives/konqueror_4%3a4.8.4-1_i386.deb signature.asc Description: This is a digitally signed message part.
Bug#679582: [Pkg-kde-extras] Bug#679582: amarok: doesn't start since about two or three days ago
severity 679582 important retitle 679582 amarok crashes on startup if playlist is corrupt (current.xspf) thanks Hello, On Friday 29 June 2012 23:44:33 Toni Mueller wrote: Since a few days, amarok does not want to start anymore. Before that, it played just fine. This is what I get at startup: ... Thread 1 (Thread 0xafbf6720 (LWP 25195)): [KCrash Handler] #7 Playlist::TrackNavigator::queueIds (this=0x9c8b460, ids=...) at ../../src/playlist/navigators/TrackNavigator.cpp:61 #8 0xb6c0b6be in Playlist::TrackNavigator::queueId (this=0x9c8b460, id=0) at ../../src/playlist/navigators/TrackNavigator.cpp:51 #9 0xb6b7fa4c in Playlist::Actions::queue (this=0x9bda4f8, rows=...) at ../../src/playlist/PlaylistActions.cpp:400 #10 0xb6b83314 in Playlist::Actions::restoreDefaultPlaylist (this=0x0) at ../../src/playlist/PlaylistActions.cpp:514 #11 0xb6b837da in Playlist::Actions::init (this=this@entry=0x9bda4f8) at ../../src/playlist/PlaylistActions.cpp:94 #12 0xb6b83848 in Playlist::Actions::instance () at ../../src/playlist/PlaylistActions.cpp:59 #13 0xb6b83884 in The::playlistActions () at ../../src/playlist/PlaylistActions.cpp:534 #14 0xb6f111d0 in MainWindow::createActions (this=0x99e0d18) at ../../src/MainWindow.cpp:697 #15 0xb6f1bb4b in MainWindow::MainWindow (this=0x99e0d18) at ../../src/MainWindow.cpp:145 #16 0xb6ef3414 in App::continueInit (this=0xbfcfd7bc) at ../../src/App.cpp:545 #17 0xb6ef4da8 in App::App (this=0xbfcfd7bc) at ../../src/App.cpp:185 #18 0x08050028 in main (argc=1, argv=0xbfcfd8b4) at ../../src/main.cpp:301 It seems Amarok current playlist [1] has become corrupt on your system. See these upstream bugs [2][3] how to fix that. Nevertheless, I believe that amarok should not crash in that case so this is still a bug, however, a non release-critical one. [1] $HOME/.kde/share/apps/amarok/current.xspf [2] https://bugs.kde.org/show_bug.cgi?id=302607 [3] https://bugs.kde.org/show_bug.cgi?id=302650 signature.asc Description: This is a digitally signed message part.
Bug#656098: amarok: Crashes on track selection with Xine backend
reassign 656098 phonon-backend-xine
tags 656098 wheezy sid
close 656098 4:4.6.0really4.4.4-4+rm
thanks
Hello,
On pirmadienis 16 Sausis 2012 14:52:43 Raj Mathur wrote:
Package: amarok
Version: 2.5.0-1
Severity: grave
Justification: renders package unusable
Amarok crashes when selecting a track by double-clicking. This only
happens with the Xine back-end. Also, the Xine back-end doesn't output
any sound.
Xine backend has been removed from archive:
http://packages.qa.debian.org/p/phonon-backend-xine/news/20120124T163915Z.html
It's working with VLC back-end, but sound volume is too low and there's no
equaliser.
You can also try phonon-backend-gstreamer. Both phonon-backend-{gstreamer,vlc}
have no equalizer though.
--
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#651316: libdrm-intel1: X.org crashes when I try to play a video
Hello, On sekmadienis 11 Gruodis 2011 03:07:34 Cyril Brulebois wrote: tag 651316 - patch fixed-upstream thanks Hi, Modestas Vainius mo...@debian.org (10/12/2011): tags 651316 patch fixed-upstream thanks please don't do that. There are several bugs here, plenty of reporters, at least 3 involved packages, and different causes. That's enough of a mess. I had the same problem. The backtrace of X crashes was: […] I upgraded libdrm to the master branch as of writing ( dd9a5b4f7fb07c78db4e7481bedca1b981030e3f ) and the problem is gone now. I suggest pulling the relevant patches into the debian package as the problem is pretty serious. I was not able to get any video to play due this crash. With latest master (libdrm+xxvintel) and patched libva, crashes seem to be gone, but playback is still failing, at least on a machine of mine. With latest libdrm master (and released xxvintel), I'm still getting crashes, possibly with an extra kernel bug, so I'm keeping this bug open with no tag for now. If X crashes on me with libdrm master, I will let you know. Yet for now, it is rock solid: no crashes and playback is fine so it's kind of relief for me. This is on a 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) [ 2481.678] (II) intel(0): Integrated Graphics Chipset: Intel(R) Clarkdale [ 2481.678] (--) intel(0): Chipset: Clarkdale Linux mdxdesktop 3.1.0-1-amd64 #1 SMP Tue Nov 29 13:47:12 UTC 2011 x86_64 GNU/Linux -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#651316: libdrm-intel1: X.org crashes when I try to play a video
tags 651316 patch fixed-upstream thanks Hello, On penktadienis 09 Gruodis 2011 19:50:48 Pedro Antonio Neves wrote: After installing the patched versions of libva and xserver-xorg-video-intel_2.17.0-1+kibi1 I'm still unable to play video files. The windows show up but they're black. I had the same problem. The backtrace of X crashes was: (gdb) bt #0 0x7f9fd101b405 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f9fd101e680 in *__GI_abort () at abort.c:92 #2 0x7f9fd10145b1 in *__GI___assert_fail (assertion=0x7f9fceddb7a7 bo_gem-map_count == 0, file=optimized out, line=1016, function=0x7f9fceddbe70 drm_intel_gem_bo_map) at assert.c:81 #3 0x7f9fcedd8b10 in drm_intel_gem_bo_map (bo=0x7f9fd8010b90, write_enable=1) at ../../intel/intel_bufmgr_gem.c:1016 #4 0x7f9fceffcac3 in intel_alloc_and_map (name=optimized out, size=4096, bop=0x7fffe3bf6b30, virtualp=0x7fffe3bf6b38, intel=optimized out) at ../../src/i965_video.c:392 #5 0x7f9fceffe420 in I965DisplayVideoTextured (scrn=0x7f9fd39c7e80, adaptor_priv=optimized out, id=optimized out, dstRegion=0x7f9fd8013c80, width=optimized out, height=optimized out, video_pitch=312, video_pitch2=624, src_w=624, src_h=352, drw_w=884, drw_h=499, pixmap=0x7f9fd816d8f0) at ../../src/i965_video.c:1301 #6 0x7f9fceff57de in I830PutImageTextured (scrn=0x7f9fd39c7e80, src_x=0, src_y=optimized out, drw_x=optimized out, drw_y=optimized out, src_w=624, src_h=352, drw_w=884, drw_h=499, id=842094169, buf=0x7f9fc9aca000 '\020' repeats 200 times..., width=624, height=352, sync=1, clipBoxes=0x7fffe3bf6da0, data=0x7f9fd5542f90, drawable=0x7f9fd8240380) at ../../src/intel_video.c:1579 #7 0x7f9fd30599ce in xf86XVPutImage (client=optimized out, pDraw=0x7f9fd8240380, pPort=0x7f9fd5543d10, pGC=optimized out, src_x=optimized out, src_y=optimized out, src_w=624, src_h=352, drw_x=0, drw_y=23, drw_w=884, drw_h=499, format=0x7f9fd5543a90, data=0x7f9fc9aca000 '\020' repeats 200 times..., sync=1, width=624, height=352) at ../../../../hw/xfree86/common/xf86xv.c:1865 #8 0x7f9fd00f1e02 in ProcXvShmPutImage (client=0x7f9fd8240740) at ../../Xext/xvdisp.c:1091 #9 0x7f9fd3004fc9 in Dispatch () at ../../dix/dispatch.c:432 #10 0x7f9fd2ff422a in main (argc=8, argv=optimized out, envp=optimized out) at ../../dix/main.c:287 (gdb) q I upgraded libdrm to the master branch as of writing ( dd9a5b4f7fb07c78db4e7481bedca1b981030e3f ) and the problem is gone now. $ git log 2.4.28..master | cat commit dd9a5b4f7fb07c78db4e7481bedca1b981030e3f Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Dec 6 13:12:37 2011 + intel: Evict cached VMA in order to make room for new mappings As the max number of VMA mappings is a hard per-process limit, we need to include the number of currently active mappings when evicting in order to make room for a new mmap. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk commit e4b60f29609e9993dc7268993da509530862aa78 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Dec 5 21:29:05 2011 + intel: Add an interface to limit vma caching There is a per-process limit on the number of vma that the process can keep open, so we cannot keep an unlimited cache of unused vma's (besides keeping track of all those vma in the kernel adds considerable overhead). However, in order to work around inefficiencies in the kernel it is beneficial to reuse the vma, so keep a MRU cache of vma. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk commit 902ee661f1864aaf8325621085f6a1b5a6a3673a Author: Dave Airlie airl...@redhat.com Date: Mon Dec 5 21:24:48 2011 + test/radeon: add missing files for dist commit 5c5332bbc38ff25c06081ac53a15ad583ad4cbc4 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Dec 5 10:39:49 2011 + intel: Clean up mmaps on freeing the buffer As a precautionary measure munmap on buffer free so that we never leak the vma. Also include a warning during debugging. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I suggest pulling the relevant patches into the debian package as the problem is pretty serious. I was not able to get any video to play due this crash. signature.asc Description: This is a digitally signed message part.
Bug#640214: cmake sets the default optimization level to -O3
Hello,
On trečiadienis 07 Rugsėjis 2011 15:07:21 Matthias Klose wrote:
On 09/04/2011 08:17 AM, Modestas Vainius wrote:
Debian packages should use RelWithDebInfo [1] CMAKE_BUILD_TYPE if they
want settings compatible with Debian Policy out-of-the-box. However,
neither Release [2] nor RelWithDebInfo [1] are defaults while empty
build type [3] is THE default. So cmake makes absolutely NO decision on
behalf of maintainer. Environment variables C(XX)FLAGS are still
effective with empty build type so the process (including noopt
handling) can be exactly the same as with autoconf. Closing as invalid.
[1] set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT -O2 -g)
[2] set(CMAKE_${lang}_FLAGS_RELEASE_INIT -O2 -DNDEBUG)
[3] set(CMAKE_${lang}_FLAGS_INIT )
Now setting RelWithDebInfo has the effect that the CFLAGS set in the
environment are ignored/overwritten with the hard coded flags. Is this
really intended?
DEB_CFLAGS_APPEND=-O3 -D__DEBIAN_FOO__ DH_VERBOSE=1 dpkg-buildpackage ...
[...]
gcc ... -g -O2 -O3 -D__DEBIAN_FOO__ -w -O2 -g
Do not set any build type if you don't want cmake messing with CFLAGS. Simple
as that.
Imagine build type as a user-friendly name for a certain collection of build
flags. If you don't want this, don't set it.
--
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#635724: vlc: FTBFS (kfreebsd-i386) Segmentation fault (core dumped) ../bin/vlc-cache-gen .
Hello, On trečiadienis 03 Rugpjūtis 2011 00:04:34 Reinhard Tartler wrote: reassign 635724 libqt4-gui,vlc stop On Tue, Aug 02, 2011 at 20:14:21 (CEST), Rémi Denis-Courmont wrote: Hello, [...] I rather suspect the debug information are corrupted by compiler optimizations at this point. Otherwise, DeleteModule() would crash before module_Unload() gets to invoke dlclose(), as it dereferences p_module. To me, it looks more like Qt4 has (yet another) bug in its static object destructors, which makes it crash dlclose(). VLC may be the only application dlopen()'ing -a shared object that links with- Qt4. And if it's not, it might still well be the only one that does so during as part of its build process. Sounds plausible to me. Qt4 maintainers, could you please comment on this? I don't see how Qt4 can be at fault here. vlc 1.1.10-1+b1 [1] has built fine with libqt4-dev 4:4.7.3-4. Current qt4-x11 4:4.7.3-5 do not have such changes which could have caused this. So I suspect changes in the toolchain or broken gcc which was used to compile qt4-x11 4:4.7.3-5 with. By the way, the backtrace from [2] is not very useful since it was generated without libqt4- dbg installed. [1] https://buildd.debian.org/status/fetch.php?pkg=vlcarch=kfreebsd- i386ver=1.1.10-1%2Bb1stamp=1309445176 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635724#35 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#635980: 3rd party packages should not install modules to /usr/share/cmake-2.8/Modules
Package: libclaw-dev
Version: 1.6.1-4
Severity: serious
User: cm...@packages.debian.org
Usertags: 3rdparty-modules-in-cmake-root
Hello,
Your package ships a cmake module in /usr/share/cmake-2.8/Modules/, namely:
/usr/share/cmake-2.8/Modules/FindCLAW.cmake
Third party packages should NOT install custom modules to CMAKE_ROOT directory
because it is strictly for use by cmake itself and its path is subject to
change without any notice (e.g. when CMake 2.10 is released).
You should replace Find* module with package configuration file(s). Read more
about them at [1] and [2]. It is recommended to install package-config.cmake
files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake/package/,
/usr/lib/cmake/package/ or /usr/share/cmake/package/ as needed. Support
for ${CMAKE_LIBRARY_ARCHITECTURE} was introduced in cmake 2.8.5, the rest
requires cmake 2.6.3.
[1]
http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files
[2] http://cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
(scroll to Config mode)
--
Debian CMake maintainer,
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#635981: 3rd party packages should not install modules to /usr/share/cmake-2.8/Modules
Package: libpackagekit-qt2-dev
Version: 0.6.15-1
Severity: serious
User: cm...@packages.debian.org
Usertags: 3rdparty-modules-in-cmake-root
Hello,
Your package ships a cmake module in /usr/share/cmake-2.8/Modules/, namely:
usr/share/cmake-2.8/Modules/FindPackageKitQt2.cmake
Third party packages should NOT install custom modules to CMAKE_ROOT directory
because it is strictly for use by cmake itself and its path is subject to
change without any notice (e.g. when CMake 2.10 is released).
You should replace Find* module with package configuration file(s). Read more
about them at [1] and [2]. It is recommended to install package-config.cmake
files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake/package/,
/usr/lib/cmake/package/ or /usr/share/cmake/package/ as needed. Support
for ${CMAKE_LIBRARY_ARCHITECTURE} was introduced in cmake 2.8.5, the rest
requires cmake 2.6.3.
[1]
http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files
[2] http://cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
(scroll to Config mode)
--
Debian CMake maintainer,
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#635982: 3rd party packages should not install modules to /usr/share/cmake-2.8/Modules
Package: libwt-dev
Version: 3.1.10-1
Severity: serious
User: cm...@packages.debian.org
Usertags: 3rdparty-modules-in-cmake-root
Hello,
Your package ships a cmake module in /usr/share/cmake-2.8/Modules/, namely:
/usr/share/cmake-2.8/Modules/FindWt.cmake
Third party packages should NOT install custom modules to CMAKE_ROOT directory
because it is strictly for use by cmake itself and its path is subject to
change without any notice (e.g. when CMake 2.10 is released).
You should replace Find* module with package configuration file(s). Read more
about them at [1] and [2]. It is recommended to install package-config.cmake
files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake/package/,
/usr/lib/cmake/package/ or /usr/share/cmake/package/ as needed. Support
for ${CMAKE_LIBRARY_ARCHITECTURE} was introduced in cmake 2.8.5, the rest
requires cmake 2.6.3.
[1]
http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files
[2] http://cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
(scroll to Config mode)
--
Debian CMake maintainer,
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#635554: kmail: Kmail does not download messages from the main IMAP folder
reassign 635554 kdepimlibs-kio-plugins severity 635554 important tags 635554 moreinfo thanks Hello, On trečiadienis 27 Liepa 2011 01:30:38 Noel David Torres Taño wrote: Package: kmail Version: 4:4.4.11.1+l10n-1 Severity: grave Justification: renders package unusable This is not grave since something still works. Too bad it chokes on the inbox folder though. When did this problem start happening? When downloading the new messages list from the main, upper folder of an IMAP account, or when trying to Check Mail, kmail does not show any new message and fires an error: Error al recuperar mensajes. El proceso para el protocolo imap://localhost terminó inesperadamente. Detalles Terminación inesperada del programa Terminación inesperada del programa El programa de su equipo que proporciona acceso al protocolo imap://localhost ha terminado inesperadamente. Detalles de la solicitud: URL: (desconocido) Fecha y hora: Martes, 26 de Julio de 2011 23:07 Información adicional: imap://localhost Causas posibles: Lo más probable es que haya sido ocasionado por un error en el programa. Por favor, considere enviar un informe de fallos como se detalla más abajo. Soluciones posibles: Blah blah blah That is: the kio_imap process died unexpectedly. The server is OK, as I've tried with Evolution and it has a lot of messages Kmail has not shown me. There are gigs of available disk and memory, so it is not that kind of problem. Problem does not arise when clicking on a child folder, just on the principal or when checking for new mail. Install kdepimlibs-dbg, attach gdb to the running kio_imap4 kioslave process (gdb -p process id), send backtrace [1] here. Also check ~/.xsession-errors [1] http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#635592: [regression] Assertion failure in emit_inc_line_addr at ../../gas/dwarf2dbg.c line 926. on mips(el)
Package: binutils Version: 2.21.52.20110707-1 Severity: serious Justifaction: causes other packages to FTBFS on mips/mipsel Hello, It seems that binutils has regressed on mipsel and mips. The failure is like: /tmp/cce8vszV.s: Assembler messages: /tmp/cce8vszV.s: Internal error! Assertion failure in emit_inc_line_addr at ../../gas/dwarf2dbg.c line 926. Please report this bug. Regression was probably introduced in binutils_2.21.52.20110703-1 since that release includes big gas related changes. However, I can't confirm that since none of buildds use it anymore so lets assume that regression was introduced in binutils_2.21.52.20110707-1. Logs of some failures are below: * binutils_2.21.53.20110720-1: https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspacearch=mipsver=4%3A4.6.5-1stamp=1311462730 https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspacearch=mipselver=4%3A4.6.5-2stamp=1311720152 https://buildd.debian.org/status/fetch.php?pkg=kdesdkarch=mipsver=4%3A4.6.5-1stamp=1311500965 https://buildd.debian.org/status/fetch.php?pkg=kdesdkarch=mipselver=4%3A4.6.5-1stamp=1311328518 https://buildd.debian.org/status/fetch.php?pkg=kdebasearch=mipsver=4%3A4.6.5-1stamp=1311458085 https://buildd.debian.org/status/fetch.php?pkg=kdebasearch=mipsver=4%3A4.6.5-1stamp=1311256019 * binutils_2.21.52.20110707-1 https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspacearch=mipsver=4%3A4.6.5-1stamp=1311092775 https://buildd.debian.org/status/fetch.php?pkg=kdebasearch=mipsver=4%3A4.6.5-1stamp=1311076807 The same packages succeed if they get built with binutils_2.21.52.20110606-2: https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspacearch=mipsver=4%3A4.6.5-1stamp=1311492656 https://buildd.debian.org/status/fetch.php?pkg=kdebasearch=mipsver=4%3A4.6.5-1stamp=1311466122 There seem to have been some changes to the gas/mips* area in the upstream VCS repository. Maybe you should try to package a new upstream snapshot. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#631652: libqtgui4: psi can't be used with tray icon + crash PKIMonitor from Alladin
notfound 631652 4:4.6.3-4+squeeze1 close 631652 4:4.7.3-4 thanks Hello, On penktadienis 22 Liepa 2011 12:12:44 stanislav@gmail.com wrote: Package: libqtgui4 Version: 4:4.6.3-4+squeeze1 Severity: normal psi from repository does not create tray icon, but can be disappeared from taskbar in gnome PKIMonitor (Alladin eToken software gui from external source) crash with syslog message: Jul 22 13:27:34 stas-it kernel: [1798890.786743] PKIMonitor[2950]: segfault at 730072 ip b6be38d1 sp bfbc15b0 error 4 in libQtGui.so.4.6.3[b6a38000+a78000] DO NOT report another unrelated problem into existing bug. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#633499: system-config-printer-kde: kcontrol KCModuleLoader::loadModule: This module has no valid entry symbol at all.
/pykdeuic4.py /var/lib/python-support/python2.6/PyQt4/uic fixes the problem. So the root cause of this bug is the same as in #633000. I.e. python does not bother looking in /usr/lib/python2.6/dist-packages/PyQt4/ (where it would find needed uic/widget-plugins/kde4.py) because PyQt4 directory already exists in /var/lib/python-support/python2.6/ It seems that transition to dh_python2 is not that painless as advertised... I'm not sure where to reassign this bug... -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#633499: Confirm
Hello, On pirmadienis 11 Liepa 2011 20:03:44 M. wrote: I confirm this bug with the exact same error. It is also _grave_ as I can't print AT ALL on my kde installation. http://localhost:631/ -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#629815: Bug#632406: FTBFS: configure fails, missing 'gdcmConfigure.h'
tags 631497 fixed-upstream pending confirmed thanks Hello, On pirmadienis 04 Liepa 2011 16:52:20 Andreas Tille wrote: On Mon, Jul 04, 2011 at 03:05:30PM +0200, Cyril Brulebois wrote: tag 632406 patch thanks Philipp Kern pk...@debian.org (04/07/2011): so this would potentially block the upcoming poppler transition. We are unable to rebuild gdcm due to bug #632406 Here's a *NASTY* patch which makes gdcm build again. Please let me know if you want my NMUing it, and when. I can not speak for the medical imaging experts who usually care for this package. However, considering that this issue is blocking other packages I would consider it apropriate to issue a 0-day NMU. In case other changes are needed we might fix this in another upload. Thanks for your work on this FYI, this is a cmake bug (#631497) which will be fixed in 2.8.5 final to be released really soon. Otherwise (max. 3 days from now) I will patch cmake myself. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#632602: libQtOpenGL.so.4 (libqt4-opengl) broke ABI on armel due to switch to OpenGL ES
Package: libqt4-opengl Version: 4:4.7.3-2 Severity: serious Hello, libQtOpenGL.so.4 (libqt4-opengl package) broke ABI in 4:4.7.3-2 on armel [1]. This was caused by switch to OpenGL ES. In particular: - _ZN10QGLContext12chooseVisualEv@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# _ZN10QGLContext12chooseVisualEv@Base 4:4.7.2 QGLContext::chooseVisual() is a _virtual_ protected method in a public class. Changes to vtable mean that potentially old QGLContext using code might just crash without any notice. OpenGL ES switch must be handled by renaming the package on armel and doing a proper transition. The only option I see now is revert of the switch and binNMUs of all libqt4-opengl rdepends which were rebuilt between 4:4.7.3-2 (2011-06-17) and by the time revert is uploaded. [1] https://buildd.debian.org/status/fetch.php?pkg=qt4- x11arch=armelver=4%3A4.7.3-4stamp=1309152136 --- debian/libqt4-opengl.symbols (libqt4-opengl_4:4.7.3-4_armel) +++ dpkg-gensymbolso2ZSfW 2011-06-27 04:33:19.0 + @@ -6,6 +6,7 @@ _Z22qt_gl_transfer_contextPK10QGLContext@Base 4:4.6.2 _Z22qt_set_gl_library_nameRK7QString@Base 4:4.5.3 _Z26qt_destroy_gl_share_widgetv@Base 4:4.7.1 + _Z33qt_resolve_eglimage_gl_extensionsP10QGLContext@Base 4:4.7.3-4 (arch=ia64 mips mipsel sparc)_Z8qWarningv@Base 4:4.7.2 _ZN10QByteArrayD1Ev@Base 4:4.5.3 (arch=!ia64 !mips !mipsel !sparc)_ZN10QByteArrayD2Ev@Base 4:4.7.2 @@ -20,7 +21,7 @@ _ZN10QGLContext11drawTextureERK6QRectFjj@Base 4:4.5.3 _ZN10QGLContext11drawTextureERK7QPointFjj@Base 4:4.5.3 _ZN10QGLContext11makeCurrentEv@Base 4:4.5.3 - _ZN10QGLContext12chooseVisualEv@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# _ZN10QGLContext12chooseVisualEv@Base 4:4.7.2 _ZN10QGLContext13chooseContextEPKS_@Base 4:4.5.3 _ZN10QGLContext13deleteTextureEj@Base 4:4.5.3 _ZN10QGLContext14currentContextEv@Base 4:4.5.3 @@ -34,7 +35,7 @@ _ZN10QGLContext8setValidEb@Base 4:4.5.3 _ZN10QGLContext9setDeviceEP12QPaintDevice@Base 4:4.5.3 _ZN10QGLContext9setFormatERK9QGLFormat@Base 4:4.5.3 - _ZN10QGLContext9tryVisualERK9QGLFormati@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# _ZN10QGLContext9tryVisualERK9QGLFormati@Base 4:4.7.2 _ZN10QGLContextC1ERK9QGLFormat@Base 4:4.5.3 _ZN10QGLContextC1ERK9QGLFormatP12QPaintDevice@Base 4:4.5.3 _ZN10QGLContextC2ERK9QGLFormat@Base 4:4.5.3 @@ -114,9 +115,9 @@ _ZN14QGLSignalProxyD0Ev@Base 4:4.6.1 _ZN14QGLSignalProxyD1Ev@Base 4:4.6.1 (arch=!ia64 !mips !mipsel !sparc)_ZN14QGLSignalProxyD2Ev@Base 4:4.7.2 - _ZN14QPaintEngineEx12pixmapFilterEiPK13QPixmapFilter@Base 4:4.6.1 - _ZN14QPaintEngineEx17endNativePaintingEv@Base 4:4.6.1 - _ZN14QPaintEngineEx19beginNativePaintingEv@Base 4:4.6.1 +#MISSING: 4:4.7.3-4# _ZN14QPaintEngineEx12pixmapFilterEiPK13QPixmapFilter@Base 4:4.6.1 +#MISSING: 4:4.7.3-4# _ZN14QPaintEngineEx17endNativePaintingEv@Base 4:4.6.1 +#MISSING: 4:4.7.3-4# _ZN14QPaintEngineEx19beginNativePaintingEv@Base 4:4.6.1 _ZN14QPaintEngineEx4syncEv@Base 4:4.6.1 (optional=external|arch=sparc)_ZN15QBasicAtomicInt3refEv@Base 4:4.5.3 (optional=external|arch=sparc)_ZN15QBasicAtomicInt5derefEv@Base 4:4.5.3 @@ -445,8 +446,8 @@ (arch=!ia64 !mips !mipsel !sparc)_ZN6QDebugD2Ev@Base 4:4.7.2 _ZN7QStringD1Ev@Base 4:4.5.3 (arch=!ia64 !mips !mipsel !sparc)_ZN7QStringD2Ev@Base 4:4.7.2 - (optional=external)_ZN8QPolygonD1Ev@Base 4:4.7.2 - (optional=external)_ZN8QPolygonD2Ev@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# (optional=external)_ZN8QPolygonD1Ev@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# (optional=external)_ZN8QPolygonD2Ev@Base 4:4.7.2 (optional=external)_ZN9QBitArrayD1Ev@Base 4:4.7.2 (optional=external)_ZN9QBitArrayD2Ev@Base 4:4.7.2 _ZN9QGLBuffer15setUsagePatternENS_12UsagePatternE@Base 4:4.7.0~beta1 @@ -578,7 +579,7 @@ _ZN9QGLWidgetD0Ev@Base 4:4.5.3 _ZN9QGLWidgetD1Ev@Base 4:4.5.3 _ZN9QGLWidgetD2Ev@Base 4:4.5.3 - (optional=external)_ZN9QHashData8willGrowEv@Base 4:4.7.2 +#MISSING: 4:4.7.3-4# (optional=external)_ZN9QHashData8willGrowEv@Base 4:4.7.2 (optional=external)_ZN9QPolygonFD1Ev@Base 4:4.7.2 (optional=external)_ZN9QPolygonFD2Ev@Base 4:4.7.2 _ZNK10QGLContext10colorIndexERK6QColor@Base 4:4.5.3 -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#631652: kdm crashes on start in kdm_greet
in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_konqueror.so #65 0x7fc9f4ab4ead in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffd5c1ea08) at libc-start.c:228 #66 0x00400691 in _start () -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#629815: Bug#630167: Bug#629815: No rule to make target `/usr/lib/libdl.so'
close 630167 2.8.4+dfsg.1-5
thanks
Hello,
On ketvirtadienis 23 Birželis 2011 14:20:59 Andreas Tille wrote:
I tried to rebuild gofigure2 (which is affected by #629815) now I do
not get the
No rule to make target `/usr/lib/libdl.so', needed by
`lib/libvtkRenderingAddOn2.so.0.8'
any more but rather
No rule to make target `/usr/lib/libXt.so', needed by
`lib/libPoissonReconstruction.so.0.8'
$ grep -rn -e '/usr/lib/libXt.so' /usr/lib/vtk-5.6/
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:76: SET(vtkRendering_LIB_DEPENDS
general;vtkGraphics;general;vtkImaging;general;vtkIO;general;vtkftgl;general;QtGui;general;QtCore;general;/usr/lib/libgl2ps.so;general;/usr/lib/libz.so;general;/usr/lib/libpng.so;general;/usr/lib/libz.so;general;/usr/lib/libGL.so;general;/usr/lib/libXt.so;general;X11;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:186: SET(vtkRendering_LIB_DEPENDS
vtkGraphics;vtkImaging;vtkIO;vtkftgl;QtGui;QtCore;/usr/lib/libgl2ps.so;/usr/lib/libz.so;/usr/lib/libpng.so;/usr/lib/libz.so;/usr/lib/libGL.so;/usr/lib/libXt.so;X11;)
$ grep -rn -e '/usr/lib/libdl.so' /usr/lib/vtk-5.6/
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:5: SET(Cosmo_LIB_DEPENDS
general;vtksys;general;vtkCommon;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-
rte.so;general;/usr/lib/openmpi/lib/libopen-
pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:6: SET(MapReduceMPI_LIB_DEPENDS
general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-
rte.so;general;/usr/lib/openmpi/lib/libopen-
pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:9: SET(VPIC_LIB_DEPENDS
general;vtksys;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-
rte.so;general;/usr/lib/openmpi/lib/libopen-
pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:115: SET(Cosmo_LIB_DEPENDS
vtksys;vtkCommon;/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-
rte.so;/usr/lib/openmpi/lib/libopen-
pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:116: SET(MapReduceMPI_LIB_DEPENDS
/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-
rte.so;/usr/lib/openmpi/lib/libopen-
pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;)
/usr/lib/vtk-5.6/VTKLibraryDepends.cmake:119: SET(VPIC_LIB_DEPENDS
vtksys;/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-
rte.so;/usr/lib/openmpi/lib/libopen-
pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;)
$ dpkg -S VTKLibraryDepends.cmake
libvtk5-dev: /usr/lib/vtk-5.6/VTKLibraryDepends.cmake
$ dpkg -l libvtk5-dev | grep ii
ii libvtk5-dev5.6.1-6 VTK header files for building C++ code
So you can reassign your bug where it belongs (libvtk5-dev). Unfortunately, VTK
has one of the most hackish (and outdated in places) cmake code. Good luck
fixing it.
and thus I assume my action to reopen #630167 (which is unfortunately
not properly documented in the bug log) was not the right thing to do.
Yes, it was not the right thing to do because:
1) the bug is not related to your problem. It was about kfreebsd and armel
while your package fails on all arches.
2) I had no clue what happened because original explanation didn't say
much at all. I have no idea how you managed to reopen it in such a cryptic
way.
Similarly I can confirm that when trying to build ginkgocadx I do not
run any more in the missing libdl.so but rather into
No rule to make target `/lib/libwrap.so.0', needed by
`src/cadxcore/libCADxCore.so.2.4.1.1'
which somehow smells like libwrap0 is guilty for the problem. I admit
that this multiarch stuff is above my horizon and I hope that somebody
might be able to clarify what might be the correct way of action now.
Always grep the source before blaming something else :-)
$ grep -rn '/lib/libwrap.so.0' .
./src/cadxcore/CMakeLists.txt:171: TARGET_LINK_LIBRARIES(${PROJECT_NAME}
dcmdsig oflog
/lib/libwrap.so.0)
--
Modestas Vainius mo...@debian.org
signature.asc
Description: This is a digitally signed message part.
Bug#630917: qt4-linguist-tools: trying to overwrite '/usr/bin/lupdate-qt4', which is also in package libqt4-dev 4:4.7.3-1
Hello, 2011.06.20 15:23, Fathi Boudra rašė: Hi, On Sat, Jun 18, 2011 at 6:30 PM, Sami Liedesslie...@cc.hut.fi wrote: Package: qt4-linguist-tools Version: 4:4.7.3-2 Severity: serious It seems qt4-linguist-tools needs a Conflicts: against older libqt4-dev: The upgrade happened smoothly for me. Conflicts isn't needed. See Debian Policy 7.6.1 paragraph and current control: Breaks: libqt4-dev ( 4.7.3-2) Replaces: libqt4-dev ( 4.7.3-2) Epoch... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629668: kdebase-runtime: FTBFS: fish.cpp:370: undefined reference to `openpty'
reassign 629668 cmake 2.8.4+dfsg.1-2 close 629668 2.8.4+dfsg.1-3 forcemerge 618932 629668 reassign 629669 cmake 2.8.4+dfsg.1-2 close 629669 2.8.4+dfsg.1-3 forcemerge 618932 629669 thanks Hello, On trečiadienis 08 Birželis 2011 17:12:45 Didier Raboud wrote: Source: kdebase-runtime Version: 4:4.6.3-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110607 qa-ftbfs Justification: FTBFS on amd64 CMakeFiles/kio_fish.dir/fish.o: In function `open_pty_pair': /«BUILDDIR»/kdebase-runtime-4.6.3/obj-x86_64-linux-gnu/kioslave/fish/../. ./../kioslave/fish/fish.cpp:370: undefined reference to `openpty' collect2: ld returned 1 exit status Source: kdebase-workspace Version: 4:4.6.3-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110607 qa-ftbfs Justification: FTBFS on amd64 -DKDE_UIC_H_FILE:FILEPATH=/«BUILDDIR»/kdebase-workspace-4.6.3/obj-x86_64 -linux-gnu/kwin/kcmkwin/kwinscreenedges/ui_main.h -DKDE_UIC_BASENAME:STRING=main -P /usr/share/kde4/apps/cmake/modules/kde4uic.cmake CMakeFiles/kwineffects.dir/kwinglutils_funcs.o: In function `getProcAddress': /«BUILDDIR»/kdebase-workspace-4.6.3/obj-x86_64-linux-gnu/kwin/lib/../../ ../kwin/lib/kwinglutils_funcs.cpp:125: undefined reference to `dlsym' collect2: ld returned 1 exit status Both fixed by cmake 2.8.4+dfsg.1-3. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#629432: Upgrade to kde4libs 4:4.6.3-3 breaks kdm
tags 629432 unreproducible thanks Hello, On pirmadienis 06 Birželis 2011 20:33:35 Peter Karbaliotis wrote: Package: kde4libs Version: 4:4.6.3-3 Severity: grave Tags: sid Justification: renders package unusable After upgrading my system to version 4:4.6.3-3 of kde4libs packages, kdm failed to start properly, leaving a blank screen with blinking cursor. There were no error messages in either /var/log/Xorg.0.log or /var/log/kdm.log. Downgrading to 4:4.6.3-2 fixed the problem. There were no changes in kde4libs that could have caused this. What's more, I can't reproduce. So please try again. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#629197: amarok: xine backend: Output Device Preference list only contains Jack
reassign 629197 phonon-backend-xine 4:4.6.0really4.4.4-3 severity 629197 important thanks Hello, On šeštadienis 04 Birželis 2011 16:20:47 Stuart Pook wrote: Package: amarok Version: 2.4.1-2 Severity: grave Justification: renders package unusable I did an apt-get upgrade and now amarok no longer works. I use the xine backend, xine works fine, but in amarok the Output Device Preference for the 'Music' Category list only contains lots of empty lines and then Jack Audio Connection Kit. I don't use jack so I cannot listen to any music. I get this dialog after clicking on Setting-Configure Amarok, Playback-Configure Phonon, then Device Preferences. It is some kind of misconguration. Anyway, try phonon-backend-vlc or phonon- backend-gstreamer. xine backend is no longer recommended. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#618120: plasma-widget-adjustableclock: FTBFS: /build/user-plasma-widget-adjustableclock_2.2-1-amd64-NLDnY1/plasma-widget-adjustableclock-2.2/obj-x86_64-linux-gnu/applet/ui_appearance.h:30:29: fata
Hello Davi, On sekmadienis 13 Kovas 2011 19:44:44 Lucas Nussbaum wrote: Source: plasma-widget-adjustableclock Version: 2.2-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110313 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. #618120 [1] RC bug has been open for nearly 3 months already. Now it blocks KDE SC 4.6 transition to testing. As maintainer of the package, it is your duty to fix packaging bugs, esp. if they are release-critical ones. However, it does not appear that you would have done anything about this bug for 3 months. The truth is it is not acceptable for plasma-widget-adjustableclock to block KDE SC 4.6 transition. As your previous sponsor, I will NMU the package on Sunday unless you get back to me with proper maintainer upload until then. You know where to find me (mail or IRC). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618120 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#627445: /usr/bin/qtconfig-qt4: qt4-qtconfig causes X crash
reassign 627445 xserver-xorg-core thanks Hello, On penktadienis 20 Gegužė 2011 20:13:17 gpe92 wrote: Package: qt4-qtconfig Version: 4:4.7.3-1 Severity: grave File: /usr/bin/qtconfig-qt4 Justification: renders package unusable In qt4-stconfig when I click on a popup menu like 'Select GUI Style', X crashes. Userspace applications should never crash X server. It's not qt4-qtconfig problem. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#627175: amarok: Amarok crashes the Sawfish session
reassign 627175 sawfish thanks Hello, On trečiadienis 18 Gegužė 2011 15:32:30 Nicolas Patrois wrote: Package: amarok Version: 2.4.0-2 Severity: grave Justification: renders package unusable Since the last update (yesterday, 17/05/2011) and the installation of the latest kernel (2.6.38-2-686-bigmem), Amarok crashes the Sawfish session, but when I click on a scrollbar. Note that launching XMMS (the very old one that is still installed) has the same effect. Sawfish just crashes and returns to GDM. I suspect a library bug. And you report this against amarok? Uch. Anyway, reassigning where it belongs. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#627175: amarok: Amarok crashes the Sawfish session
Hello, On trečiadienis 18 Gegužė 2011 22:46:07 nicolas.patr...@gmail.com wrote: Le 18/05/2011 21:32:37, Modestas Vainius a écrit : reassign 627175 sawfish No, it's not only a Sawfish bug: all the applications are in a crashy mood, more or less. nicolas patrois That's definitely not an amarok bug. Amarok (begin a KDE app) has barely anything to do with sawfish (gnome). -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#612675: libkio5: KTar class have broken UTF-8 support(longlink)
tags 612675 pending confirmed owner 612675 ! thanks Hello, On šeštadienis 14 Gegužė 2011 14:44:48 Ibragimov Rinat wrote: Well, ok, but that still does not explain why you cast one check to (unsigned char) leaving others untouched. QByteArray::operator[] also returns a _signed_ char. So what makes you think those chars will always be = 127 ? Um, yes, you're right. I missed code that reads tar files. There must be (unsigned char) cast too. There are also another uses of buffer as signed char, for checksum fields, but those bytes may contain only ' ', numbers, and '\0'. All of them lower than 128, so no casting is required. But maybe I should add them for consistency. You don't need to worry about this anymore. Fix is pending but might take some time to actually get into archive. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#612675: Re[2]: Bug#612675: libkio5: KTar class have broken UTF-8 support(longlink)
Hello, On pirmadienis 09 Gegužė 2011 13:24:51 Ibragimov Rinat wrote: Can you point to some of those checks? I've looked through the code again and found nothing related to QString. There are only some of them related to QByteArray. But why do you think QByteArray checks are not affected? Because QByteArray is intended to store raw bytes [1], Basically, QByteArray is a wrapper class on top of char*. For example, QString::toUtf8() returns QByteArray as well. while QString stores charactes which may be wider than 8-bit. Current implementation uses 16-bit QChars [2]. Well, ok, but that still does not explain why you cast one check to (unsigned char) leaving others untouched. QByteArray::operator[] also returns a _signed_ char. So what makes you think those chars will always be = 127 ? -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#612675: libkio5: KTar class have broken UTF-8 support(longlink)
Hello, On pirmadienis 09 Gegužė 2011 11:19:23 Ibragimov Rinat wrote: What I'm concerned about is that your patch may not be complete. There are more similar checks in ktar.cpp. As I absolutely have no idea how tar works, this will take time to handle properly (or hopefully upstream responds in the meantime). Thanks for forwarding the bug. Can you point to some of those checks? I've looked through the code again and found nothing related to QString. There are only some of them related to QByteArray. But why do you think QByteArray checks are not affected? -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#626045: cmake segfaults on sparc
reopen 626045 reassign 626045 libc6 2.13-1 forcemerge 625607 626045 affects 625607 + src:dwarves-dfsg src:aspcud src:awesome thanks Hello, On sekmadienis 08 Gegužė 2011 13:57:06 Julien Cristau wrote: On Sun, May 8, 2011 at 11:36:07 +0200, Luca Falavigna wrote: Source: cmake Version: 2.8.4+dfsg.1-2 Severity: serious cmake segfaults on sparc architecture. Dupe of 625607. Wouldn't merging have been better? :) -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#625707: kdebindings: FTBFS: conversion from 'void' to non-scalar type 'QListQPairQByteArray, QString ' requested
reassign 625707 libphonon-dev 4:4.6.0really4.5.0-1 close 625707 4:4.6.0really4.5.0-3 affects 625707 src:kdebindings thanks Hello, On ketvirtadienis 05 Gegužė 2011 12:13:12 Jakub Wilk wrote: kdebindings no longer builds from source: | [ 38%] Building CXX object smoke/phonon/CMakeFiles/smokephonon.dir/x_10.o | cd smoke/phonon /usr/bin/c++ -Dsmokephonon_EXPORTS -D_BSD_SOURCE | -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII | -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -DSMOKE_BUILDING | -DGCC_VISIBILITY -Wall -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi | -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith | -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new | -fno-common -Woverloaded-virtual -fno-threadsafe-statics | -fvisibility=hidden -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG | -fPIC -I. -I../../../smoke/phonon -I../../.. -I../.. -I../../../smoke | -I/usr/include/KDE -I/usr/include/qt4/phonon | -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml | -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtUiTools | -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg | -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools | -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtOpenGL | -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp | -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDBus | -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui | -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt | -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -D_GNU_SOURCE | -D_LARGEFILE64_SOURCE -o CMakeFiles/smokephonon.dir/x_10.o -c x_10.cpp | x_10.cpp: In static member function 'static void | __smokephonon::x_Phonon::x_1(Smoke::Stack)': x_10.cpp:1372:58: warning: | 'void Phonon::registerMetaTypes()' is deprecated (declared at | /usr/include/qt4/phonon/objectdescription.h:349) | [-Wdeprecated-declarations] x_10.cpp:1372:76: warning: 'void | Phonon::registerMetaTypes()' is deprecated (declared at | /usr/include/qt4/phonon/objectdescription.h:349) | [-Wdeprecated-declarations] x_10.cpp:1372:76: error: conversion from | 'void' to non-scalar type 'QListQPairQByteArray, QString ' requested Full build log is here: https://buildd.debian.org/status/fetch.php?pkg=kdebindingsarch=amd64ver=4 %3A4.4.5-5%2Bb1stamp=1304559565 kdebindings should no longer FTBFS with libphonon-dev (= 4:4.6.0really4.5.0-3). Add Dep-Wait if needed. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#612675: libkio5: KTar class have broken UTF-8 support(longlink)
Hello, On trečiadienis 04 Gegužė 2011 11:40:43 Ibragimov Rinat wrote: This though is not totally clear to me. On the major architectures, char is signed, so I would assume that a chksum error in this area should have hit a lot of people already? Given that int is signed by default I wonder if this is the proper approach and it shouldn't rather be cast to signed char (signedness of char varies across the different architectures). The error only occurs when file name have characters with codes larger than 128. All ASCII have codes lower than 127, so in that case there is no difference. UTF-8 uses most significant bit as flag, so some charactes have codes larger than 128. I'll explain with example: int check = 32; check += buffer[j]; assume buffer[0]==128, i.e. 0x80. When one adds signed char 0x80 to an integer, signed char extents to a signed integer and becomes 0xff80. It is not 0x80, as one may expect. But if all file names are in english, no one can face the bug. Out of curiosity, you filed this from an i386 system. Did you maybe copy around the backup from/to any architcture including arm, armel, powerpc or s390? Were they somehow involved in the assumingly checksum error of yours? The thing behind the question is: If we fix the calculation in the direction that you propose, this would break backups done now on the architectures that do have char signed by default because it would result in a different checksum. No, unfortunately I don't have access to architectures other than amd64 and i386. What I'm concerned about is that your patch may not be complete. There are more similar checks in ktar.cpp. As I absolutely have no idea how tar works, this will take time to handle properly (or hopefully upstream responds in the meantime). Thanks for forwarding the bug. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#625937: kdevelop: crash when opening source file
reassign 625937 kdelibs5-plugins 4:4.6.2-1 retitle 625937 kdevelop 4.1.x or earlier does not work with KDE SC 4.6 affects 625937 kdevelop thanks Hello, On šeštadienis 07 Gegužė 2011 10:42:10 Salvo Tomaselli wrote: kdevelop crashes when i try to open a .c file, but it is fine with .txt files and so on. That problem makes it useless... ii kdebase-runtime 4:4.6.2-1 runtime components from the offici ii kdevelop-data 4:4.0.1-1 data files for the KDevelop IDE ii kdevplatform1-libs1.0.1-1shared libraries for the KDevelop ii lcov 1.9-2 Summarise Code coverage informatio ii libc6 2.13-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-6 GCC support library ii libkdecore5 4:4.6.2-1 KDE Platform Core Library ii libkdeui5 4:4.6.2-1 KDE Platform User Interface Librar ii libkio5 4:4.6.2-1 Network-enabled File Management Li ii libkparts44:4.6.2-1 Framework for the KDE Platform Gra ii libktexteditor4 4:4.6.2-1 KTextEditor interfaces for the KDE ii libprocessui4a 4:4.6.2-2 library for ksysguard process user ii libqt4-dbus 4:4.7.2-4 Qt 4 D-Bus module ii libqt4-help 4:4.7.2-4 Qt 4 help module ii libqt4-network4:4.7.2-4 Qt 4 network module ii libqt4-script 4:4.7.2-4 Qt 4 script module ii libqt4-webkit 4:4.7.2-4 transitional package for Qt 4 WebK ii libqtcore44:4.7.2-4 Qt 4 core module ii libqtgui4 4:4.7.2-4 Qt 4 GUI module ii libstdc++64.6.0-6The GNU Standard C++ Library v3 ii libsublime1 1.0.1-1an user interface library ii libthreadweaver4 4:4.6.2-1 ThreadWeaver Library for the KDE P kdevelop 4.1.x or earlier is known not to work with KDE SC 4.6 or later due to removed kate interfaces in kde4libs [1]. Therefore, you can only wait until your other bug (#625938) is fixed. [1] http://techbase.kde.org/KDevelop4/Compatibility -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#625825: Some qatomic_arm.h inline functions do not compile with = g++ 4.5 on arm
Package: libqt4-dev Version: 4:4.7.2-4 Severity: serious Forwarded: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/675347 Owner: mo...@debian.org File: /usr/include/qt4/QtCore/qatomic_arm.h Tags: wheezy sid Justification: makes other packages to FTBFS on armel with gcc 4.6 Hello, some QBasicAtomicInt functions do not build on armel with g++ 4.6 (Debian's g++-4.5 seems to work), for example QBasicAtomicInt::fetchAndStoreOrdered() [1]. While according to the Ubuntu report this one is forwarded to, the bug probably is in the gcc itself (broken -fstrict-volatile-bitfields handling in some cases), gcc upstream did not fix it in 4.6 despite efforts of Ubuntu people [2]. This issue will trigger many Qt based packages to FTBFS (like kde4libs [1]) because offending code is inlined in the headers. So we need a solution quick and fast, either in gcc or Qt (or both). I'm going to work on Qt solution and already have an idea how to fix this problem (a hack). [1] https://buildd.debian.org/status/fetch.php?pkg=kde4libsarch=armelver=4%3A4.4.5-5stamp=1304545515 [2] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02245.html -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#625607: Backtrace…
reassign 625607 libc6 2.13-1 affects 625607 cmake thanks Hello, On trečiadienis 04 Gegužė 2011 17:13:44 Didier Raboud wrote: Program received signal SIGSEGV, Segmentation fault. 0xf7b72bc4 in ?? () (gdb) bt #0 0xf7b72bc4 in ?? () #1 0xf7fd66c8 in elf_machine_rela (scope=0xf7ff4b98, reloc_mode=value optimized out, consider_profiling=0) at ../sysdeps/sparc/sparc32/dl-machine.h:402 #2 elf_dynamic_do_rela (scope=0xf7ff4b98, reloc_mode=value optimized out, consider_profiling=0) at do-rel.h:120 #3 _dl_relocate_object (scope=0xf7ff4b98, reloc_mode=value optimized out, consider_profiling=0) at dl-reloc.c:268 #4 0xf7fcd7c0 in dl_main (phdr=value optimized out, phnum=value optimized out, user_entry=value optimized out, auxv=value optimized out) at rtld.c:2265 #5 0xf7fdffa4 in _dl_sysdep_start (start_argptr=value optimized out, dl_main=0xf7fcc244 dl_main) at ../elf/dl-sysdep.c:244 #6 0xf7fcaa60 in _dl_start_final (arg=0xd890, info=0xd5b0) at rtld.c:341 #7 0xf7fcad8c in _dl_start (arg=0xd890) at rtld.c:569 #8 0xf7fca26c in _start () from /lib/ld-linux.so.2 #9 0xf7fca26c in _start () from /lib/ld-linux.so.2 Backtrace stopped: previous frame identical to this frame (corrupt stack?) This appears to be a bug in libc6 2.13: $ /usr/bin/cmake Segmentation fault $ dpkg -l libc6 cmake | grep ^ii ii cmake 2.8.4+dfsg.1-2 a cross-platform, open-source make system ii libc6 2.13-2 Embedded GNU C Library: Shared libraries $ wget http://ftp.de.debian.org/debian/pool/main/e/eglibc/libc6_2.11.2-11_sparc.deb $ dpkg-deb -x libc6_2.11.2-11_sparc.deb libc-2.11.2 # The latter is needed because libldap-2.4 in sid depends on libc6 2.13 $ wget http://ftp.de.debian.org/debian/pool/main/o/openldap/libldap-2.4-2_2.4.23-7_sparc.deb $ dpkg-deb -x libldap-2.4-2_2.4.23-7_sparc.deb libc-2.11.2 $ LD_LIBRARY_PATH=libc-2.11.2/lib:libc-2.11.2/usr/lib/ libc-2.11.2/lib/ld-linux.so.2 /usr/bin/cmake ... works ... $ LD_LIBRARY_PATH=libc-2.11.2/usr/lib/ libc-2.11.2/lib/ld-linux.so.2 /usr/bin/cmake Segmentation fault -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#624679: 4.7 regression: QProcess::waitForFinished() is broken on kfreebsd
Hello, On šeštadienis 30 Balandis 2011 17:47:39 Modestas Vainius wrote: Package: libqtcore4 Version: 4:4.7.2-3 Severity: grave Hello, QProcess::waitForFinished(timeout) with timeout 0 (however, big enough) seems to return false when the process has not finished yet (leaving QProcess::state() in QProcess::Running). However, QProcess::waitForFinished(-1) works fine. This appears to be a regression in 4.7 (4.6.3 works fine). The bug triggers quite a few random FTBFSes like [1], [2]. This happens because Qt on kfreebsd is compiled without monotonic clock support [1] (or at least Qt thinks so). select() is interrupted by SIGCHLD [2] and then qt_safe_select() code kicks in with its bogus calculation of timeout during EINT [3] (basically, no monotonic clock - you're screwed). Such fragileness is a bug by itself, I don't care about too much at moment as _POSIX_MONOTONIC_CLOCK is defined [4] so something is wrong with Qt checks. [1] QElapsedTimer::isMonotonic() returns 0 [2] 55109 minifail RET write 24/0x18 55109 minifail CALL gettimeofday(0x7fffe3b0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL gettimeofday(0x7fffe3a0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL gettimeofday(0x7fffe2e0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL select(0x14,0x7fffe470,0x7fffe3f0,0,0x7fffe350) 55109 minifail RET select 1 55109 minifail CALL ioctl(0xd,0x4004667f ,0x7fffe34c) 55109 minifail RET ioctl 0 55109 minifail CALL close(0xd) 55109 minifail RET close 0 55109 minifail CALL gettimeofday(0x7fffe3a0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL gettimeofday(0x7fffe2e0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL select(0x14,0x7fffe470,0x7fffe3f0,0,0x7fffe350) 55109 minifail RET select 1 55109 minifail CALL ioctl(0xf,0x4004667f ,0x7fffe34c) 55109 minifail RET ioctl 0 55109 minifail CALL close(0xf) 55109 minifail RET close 0 55109 minifail CALL gettimeofday(0x7fffe3a0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL gettimeofday(0x7fffe2e0,0) 55109 minifail RET gettimeofday 0 55109 minifail CALL select(0x14,0x7fffe470,0x7fffe3f0,0,0x7fffe350) 55109 minifail RET select -1 errno 4 Interrupted system call 55109 minifail PSIG SIGCHLD caught handler=0x8017b51a0 mask=0x8000 code=0x0 55109 minifail CALL write(0x6,0x800a49a0a,0x1) 55109 minifail GIO fd 6 wrote 1 byte \0 55109 minifail RET write 1 55109 minifail CALL sigreturn(0x7fffdeb0) 55109 minifail RET sigreturn JUSTRETURN 55109 minifail CALL break(0x645000) 55109 minifail RET break 0 55109 minifail CALL break(0x641000) 55109 minifail RET break 0 55109 minifail CALL write(0x2,0x7fffbcb0,0x34) 55109 minifail GIO fd 2 wrote 52 bytes exit code=0, exitcode=0, state=2, error=2. Aborting [3] http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/kernel/qcore_unix.cpp#line91 [4] /usr/include/bits/posix_opt.h:156:#define _POSIX_MONOTONIC_CLOCK 200809L -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#624679: 4.7 regression: QProcess::waitForFinished() is broken on kfreebsd
Package: libqtcore4 Version: 4:4.7.2-3 Severity: grave Hello, QProcess::waitForFinished(timeout) with timeout 0 (however, big enough) seems to return false when the process has not finished yet (leaving QProcess::state() in QProcess::Running). However, QProcess::waitForFinished(-1) works fine. This appears to be a regression in 4.7 (4.6.3 works fine). The bug triggers quite a few random FTBFSes like [1], [2]. [1] https://buildd.debian.org/status/fetch.php?pkg=kde4libsarch=kfreebsd-i386ver=4%3A4.6.2-1stamp=1304164739 [2] https://buildd.debian.org/status/fetch.php?pkg=akonadiarch=kfreebsd-amd64ver=1.3.1-4stamp=1304159335 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.2-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqtcore4 depends on: ii libc0.1 2.11.2-13Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-6GCC support library ii libglib2.0-02.28.6-1 The GLib library of C routines ii libstdc++6 4.6.0-6 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libqtcore4 recommends no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623739: [kde-window-manager] Kwin crashes on startup
close 623739 4:4.4.5-8 reassign 623739 kdebase-workspace-bin,kde-window-manager forcemerge 623492 623739 thanks Hello, On penktadienis 22 Balandis 2011 18:55:27 MeLON wrote: Package: kde-window-manager Version: 4:4.4.5-8 Severity: serious --- Please enter the report below this line. --- After the last update KDE session didn't come up. The kwin process crashed (along with it's company needed to bring up the session: kded, plasma-desktop etc. but i would'n know how to trace it properly to attach to bug report). Happens every time. Kde programs run in a diffrent environment (lxde) run fine. Anyway, here is a sample gdb output: There is no need to report duplicates. Upgrade to 4:4.4.5-9 once it is available in the repositories. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#622986: kmail: KMail crashes right after login
forwarded 622986 https://bugs.kde.org/show_bug.cgi?id=184324 tags 622986 upstream thanks Hello, On šeštadienis 16 Balandis 2011 14:24:33 Andras Veres-Szentkiralyi wrote: Package: kmail Version: 4:4.4.7-3 Severity: grave Justification: renders package unusable Since today, KMail crashes right after logging in (e.g. if I provide incorrect credentials, it notifies me and crashes right afterwards). Even the main window doesn't show up, KCrash appears right after the authentication window. I attached a backtrace with the appropriate debug packages installed. Please refer to the upstream bug above. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#621013: impossible to handle collection after upgrading to amarok 2.4
Hello, On Tuesday 05 April 2011 23:00:36 Emmanuel Anne wrote: Package: amarok Version: 2.4.0-2 Severity: grave Justification: causes non-serious data loss Well collection appears with only 1 track (but unreadable) from the start, even trying a full rescan makes no difference. Upgraded to 2.4.1-beta from experimental to try, got the same error with more details, it complains mysqle init failed, error 2000. Downgrading to the old 2.3 version fixes the problem, so I reverted to 2.3 for now. (I just reinstalled 2.4 to send the bug report). Run: $ amarok --nofork --debug and attach output -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#620807: libqt4-svg: symbol lookup error: /usr/lib/libQtSvg.so.4: undefined symbol
severity 620807 grave tags 620807 moreinfo thanks Hello, On Monday 04 April 2011 13:22:42 Johannes Willkomm wrote: Package: libqt4-svg Version: 4:4.7.2-3 Severity: critical Tags: d-i Justification: breaks unrelated software After upgrading libqt4-svg: libqt4-svg:amd64 (4.6.3-4, 4.7.2-3) I get the following error when starting kmail or kwalletmanager: symbol lookup error: /usr/lib/libQtSvg.so.4: undefined symbol: _ZN20QGraphicsItemPrivate20focusScopeItemChangeEb Please paste the output of: $ ldd /usr/lib/libQtSvg.so.4 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#615159: nepomulkservices consume too many memory
severity 615159 normal thanks Hello, On šeštadienis 26 Vasaris 2011 09:06:47 philippe wrote: Package: kdebase-runtime Version: 4:4.4.5-1 Severity: grave Tags: squeeze I have reboot the pc, launch kde, eclipse. I leave le pc idle 10 hours. When I reuse it, the system was usuable, I launch the system-monitor, I see that one of the 2 nepomukservices is consuming more than 950 Mo of the 2Go memory. So with swapping it was usable. I have stop the service indexing. I did not see any other option to control these services: limit the memory may be a good option. May be there a memory leak ? Turn off nepomuk or strigi (automatic file indexing). -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#614202: failed to remove `/usr/share/doc/cmake'
Hello, On sekmadienis 20 Vasaris 2011 13:01:26 Christian Marillat wrote: Setting up cmake (2.8.3-4) ... rmdir: failed to remove `/usr/share/doc/cmake': Not a directory dpkg: error processing cmake (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: cmake Which cmake version did you have before? Did you force upgrade or something like that? -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#614202: failed to remove `/usr/share/doc/cmake'
Hello, On sekmadienis 20 Vasaris 2011 13:53:45 Christian Marillat wrote: Modestas Vainius mo...@debian.org writes: [...] Which cmake version did you have before? Did you force upgrade or something like that? No force option. But I can't do 'apt-get dist-upgrade' for now as some packages are removed. I did an 'apt-get install cmake-data' with others packages. Then cmake has been removed. Then I installed cmake again and the install fail. Yeah, this is weird. dpkg is not supposed to automatically replace directory (/usr/share/doc/cmake) with a symlink on upgrades (see #404850). That's why I had to add that postinst. So I still do not understand how you ran into your current situation. The best is to test if /usr/share/doc/cmake is really a directory in the postinst. Yeah, I will do that. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#613522: [akregator] Please use upstream metakit
severity 613522 wishlist tags 613522 wontfix unblock 590147 by 613522 thanks Hello, On antradienis 15 Vasaris 2011 15:11:24 Bastien ROUCARIES wrote: Package: akregator Version: 4:4.4.7-3 Severity: serious Please use separate source for metakit. Serious because it is code duplication, lead to dataloss and moreover package is outdated. Your reasons for serious are just wrong. There is NO metakit source package in Debian so there is NO dublication. What is more, metakit library is hopelessly outdated upstream (2007 is the latest release date) and there is no proof that new version would fix current akregator problems. Actually, the metakit lib that is currently embedded in the akregator (2.4.9.5), has no interesting changes in comparison with the current metakit stable release (2.4.9.7) (yes, I have actually checked). So please do not exagerate bug severities based on pure guesses. You could have saved some valuable time for everybody. Future is akonadi-based akregator and, obviously, we are not interested in maintaining a dead library just for the sake of it. Moreover, unless you can actually confirm the fix for 590147, do not add false information to the BTS. P.S. Users should never set serious severity unless they can pin point Debian policy violation. You obviously failed to do so in this case. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#613075: kmix: Doesn't start
severity 613075 important thanks Hello, On šeštadienis 12 Vasaris 2011 18:55:50 kakadu wrote: Package: kmix Version: 4:4.4.5-1 Severity: grave Justification: renders package unusable I can start kmix. I can't see it in my tint2 tray kmix target is KDE desktop. The fact that tray icon does not appear in $random desktop environment is not a grave bug: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. but an important one (at best): a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. What is more, that might as well be tint2 bug. Test kmix under something more mature (e.g. icewm or similar). -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#609255: KDE upgrading
Hello, On trečiadienis 12 Sausis 2011 17:10:33 Francesco P. Lovergine wrote: On Wed, Jan 12, 2011 at 03:44:31PM +0100, Julien Cristau wrote: On Wed, Jan 12, 2011 at 14:34:12 +0100, Francesco P. Lovergine wrote: I'm afraid I'm a bit concerned about this metapackage stuff. Why weren't the metapackages from lenny kept around to help upgrades, with kde and kde-core depending e.g. on the new kde-standard metapackage? Francesco, care to share details of your upgrade? What packages were installed pre-upgrade, log from apt, …? I could provide a long dpkg log, but I upgraded with more rounds of apt-get due to some intermediate failures (not kde related), the whole workflow is quite not easy to be understood. That log would be useless then. Both apt and aptitude do many stupid decisions when it comes to recovering from dpkg failures. Demonstrate problems with clean upgrade (or at least only with KDE related failures), then we could actually try to fix those problems. Btw, I tested upgrades on the system which had the whole KDE 3.5 installed by 'kde' metapackage a couple of months ago. The end result was NOT that bad. IIRC, some not so much significant stuff from kdemultimedia or kdeedu got autoremoved wrongly but that's acceptable. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#609255: KDE upgrading
Hello, On trečiadienis 12 Sausis 2011 16:44:31 Julien Cristau wrote: I'm afraid I'm a bit concerned about this metapackage stuff. Why weren't the metapackages from lenny kept around to help upgrades, with kde and kde-core depending e.g. on the new kde-standard metapackage? No. First of all, what was the situation in Lenny: 1) kde [1] was a metapackage which depended on a bunch of other metapackages (i.e. the whole KDE). The list includes kde-core. 2) kde-core [2] is a metapackage which depended on 3 other metapackages (including kdebase metapackage, see below). Now what happended in Squeeze: 1) kde mepackage got removed. You might consider kde-full [3] metapackage as a rough equivalent of the old kde metapackage, yet it's not entirely true. `aptitude install kde` no longer works in Squeeze. 2) kde-core got removed. kde-plasma-desktop is a new rough equivalent of kde- core metapackage. `aptitude install kde-core` no longer works in Squeeze. 3) However, we have still kept kdebase metapackage in Squeeze [4]. As you see, it depends on kde-plasma-desktop. So basically the transitional metapackage for kde-core is there. But ... ... transitional metapackages for metapackages only delay the inevitable to the next Debian release, they do not solve anything. If I understand correctly, that was one of the problems DEP6 [5] was supposed to solve. Unfortunately, it has been REJECTED. In short, auto status is very damaging for normal packages pulled via metapackages. Suppose the user installed the whole KDE with `aptitude install kde`. So now the whole KDE got auto-installed status except the metapackage itself. As soon as any KDE component is removed, kde metapackage has to be removed and then the rest of KDE is also subject to autoremove. kdeaddons (KDE 3) is no longer in KDE 4. So kde metapackage will have to be removed upon upgrade to Squeeze potentially autoremoving part of KDE which are not pulled in by kde-plasma-desktop (kept back by transitional kdebase). What's more, kdebase Recommends kde-standard so default setup (with autorecommends ON) should even stay at kde-standard level. Yet aptitude/lenny will most probably keep more packages due to bugs in marking some auto- installed as manually installed under the hood. `apt-get autoremove` is not default behaviour anyway, yet it could be considered as posing some problem [6]. If we kept kde metapackage, the problem would simply be delayed to Wheezy. IMHO, it's much better to do disruptive changes now when major upstream KDE upgrade is happening. FWIW, kde metapackage name was a too obvious choice. Yet the package used to pull so much useless stuff that barely anybody needed. We dropped and replaced it with the names that force a user to actually choose what (s)he wants (or at least think about it). There is no good reason to keep legacy 'kde' metapackage around for another 2 years because then it would still remain the 'default' choice by users rather than conscious choice between kde-standard and kde-full or even kde-plasma-desktop. [1] http://packages.debian.org/lenny/kde [2] http://packages.debian.org/lenny/kde-core [3] FWIW, I consider kde-standard to be successor of kde metapackage even if it installs much fewer packages. [4] http://packages.debian.org/squeeze/kdebase [5] http://dep.debian.net/deps/dep6/ [6] http://people.skolelinux.org/~pere/debian-upgrade-testing/test-20101213- lenny-squeeze-kde-summary.txt -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#605777: workaround for backspace key deletes forwards on the kFreeBSD console
Hello, On pirmadienis 10 Sausis 2011 13:27:51 Petr Salinger wrote: The change for freebsd-utils will be some new script like kbdcontrol -d | sed ... | kbdcontrol -l kbdcontrol -f 61 ESC[3~ TERM=cons25-debian Attached is the mentioned script. It have to be run directly on console or by sh keymap-policy.sh /dev/console The keymap is altered system wide, i.e. on all virtual consoles. And you have to manually set TERM=cons25-debian aftewards. The (current) reset back is /etc/init.d/kbdcontrol start kbdcontrol -F TERM=cons25 Please could you test whether it work with your native national keymap as expected ? It works fine. Both shell and vim behave as I expect now. The expected installed (and running) packages versions are: freebsd-utils 8.1-3.1 kfreebsd-8 8.1+dfsg-7.1 ncurses 5.7+20100313-5 RFC part: The integration should be into /etc/init.d/kbdcontrol, by adding two targets, like keymap-native and keymap-debian. May be it can be run even semi-automatically, by detecting whether the /etc/inittab uses cons25 or cons25-debian and noop or alter keymap. Yes, I like the latter (auto detection) part. Another solution could be a debconf question in kbdcontrol (though it might be too late for this). What's more, I think this issue (with short instructions whatever the final integration part ends up being) warrants a note in release notes. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#609447: Undeclared dependency on python-pkg-resources
Package: python-xattr Version: 0.4-5 Severity: serious Tags: squeeze sid $ xattr -l file Traceback (most recent call last): File /usr/bin/xattr, line 5, in module from pkg_resources import load_entry_point ImportError: No module named pkg_resources The issue affects unstable version (0.6-1) as well. P.S. What is more, the lack of #592860 [1] fix in testing also drives me nuts. It's hard to use xattr as command line utility with the latter bug unfixed. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592860 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (1001, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-xattr depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii python 2.6.6-3+squeeze4 interactive high-level object- orie ii python-support 1.0.10 automated rebuilding support for P python-xattr recommends no packages. python-xattr suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#609103: Needs vlc-nox in order to be usable
Package: phonon-backend-vlc Version: 0.2.0-1 Severity: serious Hello, phonon-backend-vlc does not work without vlc-nox (i.e. vlc plugins in it): $ amarok [0x25e06f0] main libvlc error: No modules were found, refusing to start. Check that you properly gave a module path with --plugin-path. libvlc exception: bool Phonon::VLC::scanDevices(QListPhonon::VLC::DeviceInfo) Probing for v4l2 devices KCrash: Application 'amarok' crashing... -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages phonon-backend-vlc depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-10 GCC support library ii libphonon4 4:4.6.0really4.4.3-1 the core library of the Phonon mul ii libqt4-dbus 4:4.6.3-4Qt 4 D-Bus module ii libqtcore4 4:4.6.3-4Qt 4 core module ii libqtgui4 4:4.6.3-4Qt 4 GUI module ii libstdc++6 4.4.5-10 The GNU Standard C++ Library v3 ii libv4l-00.8.1-2 Collection of video4linux support ii libvlc5 1.1.3-1squeeze1 multimedia player and streamer lib ii libvlccore4 1.1.3-1squeeze1 base library for VLC and its modul phonon-backend-vlc recommends no packages. phonon-backend-vlc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605065: Bug#605777: Bug#607662: Bug#605777: Bug#607662: ncurses-base: backspace key deletes forwards on the kFreeBSD console
Hello, On trečiadienis 05 Sausis 2011 00:09:21 Adam D. Barratt wrote: On Wed, 2010-12-29 at 20:07 +0100, Sven Joachim wrote: On 2010-12-29 00:36 +0100, Adam D. Barratt wrote: On Mon, 2010-12-27 at 20:44 +0100, Sven Joachim wrote: On 2010-12-27 19:51 +0100, Petr Salinger wrote: So best option for now seems be to prevent freebsd-utils 8.1-3 from entering testing and a new upload of kfreebsd-8. For the record, freebsd-utils 8.1-3 will migrate in three days if not hindered. [...] I have added the proposed patch for the cons25-debian terminfo entry to ncurses git¹. Once this is in unstable, the kFreeBSD people may choose to implement any of the suggested solutions. That's now happened; thanks. Is the ncurses change suitable for migration in its own right, or does it need an associated change on the kFreeBSD side still? Huh, looks like kfreebsd kernel change was reverted [1]. [1] http://lists.debian.org/e1pa9a9-00028v...@franck.debian.org -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#608467: kmail: Content of messages is not displayed although subjects are visible
severity 608467 important thanks Hello, On penktadienis 31 Gruodis 2010 09:27:52 Norbert Schmitz wrote: Package: kmail Version: 4:4.4.7-2 Severity: grave Justification: renders package unusable When using kmail to display IMAP mails the content of the mail is not visible although the subjects are listed an can be selected. This might happen if your Internet connection is flacky. kio_imap4 is known not to recover if your Internet connection was cut for some time (e.g. TCP problems). You have to restart kio_imap4 like close kmail $ killall kio_imap4 (wait until all kio_imap4 processes die, maybe even use $ killall -9 kio_imap4) start kmail ps aux displays many lines in the form norbert 6420 0.0 1.0 98604 33524 ?S08:24 0:00 kdeinit4: kio_imap4 [kdeinit] imaps local:/tmp/ksocket-norbert/klauncherMT4252.slave-socket local:/tmp/ksocket-norbert/kontactFa5061.slave-socket norbert 6434 0.1 1.0 98128 32712 ?S08:25 0:00 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-norbert/klauncherMT4252.slave-socket local:/tmp/ksocket-norbert/kontactag5061.slave-socket That's normal. This bug makes it completely impossible to read mails which renders it unusable for me. What about other mail clients? FWIW, I'm writing this answer from kmail connected to my account via IMAP. So the bug does not everyone and I'm pretty sure the problem is the one I described above. Marking appropriately. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#605065: Bug#607662: ncurses-base: backspace key deletes forwards on the kFreeBSD console
Hello, On pirmadienis 27 Gruodis 2010 19:52:06 Robert Millan wrote: 2010/12/27 Petr Salinger petr.salin...@seznam.cz: I see two basic options: [...] And there is a third option, mixture of both above. [...] There's a fourth option: backporting TEKEN_XTERM from 9-current. Actually, I really like the latter option (I don't know how difficult it would be though). -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#605065: Bug#607662: ncurses-base: backspace key deletes forwards on the kFreeBSD console
Hello, On antradienis 21 Gruodis 2010 09:24:35 Petr Salinger wrote: The changes to the kFreeBSD console and the kbdcontrol package (see #605065 and #605777) need to be accompanied by changing the cons25 terminfo entry accordingly, otherwise ncurses-based programs severely misbehave. You really can't just unilaterally change the cons25 terminfo entry. If this proposed change is implemented, people running stock FreeBSD will have their consoles broken if they log into a Debian system. If kFreeBSD needs different settings than the stock cons25 entry, it needs to create and use a different TERM type. Yes, changing cons25 terminfo entry is no option. The creating of completely new terminfo entry is also no option, as it means the new entry would be unknown on all other systems. Moreover it would need changes to some other packages, at least sysvinit. I (as reporter of the original bug #605777) think that BSD team and release managers should decide what's the best way to go for Squeeze. However, if the decision is to ignore this for Squeeze, #605777 should stay open at its current severity (tagged as squeeze-ignore). Speaking with my DD hat on, the biggest practical problem I see here is that I am forced to support kfreebsd while kfreebsd doesn't exactly welcome me with arms open. Having backspace and delete keys broken is big deal and has a great impact on my efficiency. However, now I know that X environment does not suffer from this problem so there is some light at the end of tunnel. As a temporary workaround, I would suggest (if it's possible) creating a new optional userspace keymap (maybe called US Debian or something) which would be the same as standard kfbsd kernel keymap expect assign proper actions to backspace and delete keys. Obviously, this keymap might have some bad side- effects (hence it wouldn't be default) but at least users would have a choice. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#607513: Rolled back to previous Backup
severity 607513 normal
tags 607513 moreinfo
thanks
Hello,
On sekmadienis 19 Gruodis 2010 14:26:29 Debian wrote:
I rolled back to my previous Backup from 06.12.2010 now.
Now it works - there is no fun without compositing ...
Here are the packages that would be updated:
Regardless if it is fun or not, compositing is NOT essential for KDE to work.
Please report bugs with proper severity next time.
Die folgenden NEUEN Pakete werden zusätzlich installiert:
libdns69{a} libisc62{a} libisccfg62{a}
Die folgenden Pakete werden ENTFERNT:
libisccfg60{u}
Die folgenden Pakete werden aktualisiert:
bind9-host deborphan desktop-base dnsutils grub-common grub-pc host
ia32-libs isc-dhcp-client isc-dhcp-common iso-codes kaboom kbd
kdelibs-bin kdelibs5-data kdelibs5-plugins kdepimlibs-kio-plugins
kdoctools kopete libakonadi-contact4 libakonadi-kabc4
libakonadi-kcal4 libakonadi-kde4 libakonadi-kmime4 libasyncns0
libbind9-60 libgpgme++2 libgssapi-krb5-2 libgssrpc4 libisccc60
libk5crypto3 libkabc4 libkadm5clnt-mit7 libkadm5srv-mit7 libkcal4
libkdb5-4 libkde3support4 libkdecore5 libkdesu5 libkdeui5
libkdewebkit5 libkdnssd4 libkfile4 libkholidays4 libkhtml5 libkimap4
libkimproxy4 libkio5 libkjsapi4 libkjsembed4 libkldap4
libkmediaplayer4 libkmime4 libknewstuff2-4 libknewstuff3-4
libknotifyconfig4 libkntlm4 libkontactinterface4 libkopete4 libkparts4
libkpimidentities4 libkpimtextedit4 libkpimutils4 libkpty4 libkrb5-3
libkrb5support0 libkresources4 libkrosscore4 libktexteditor4
libktnef4 libkunitconversion4 libkutils4 libloudmouth1-0 liblwres60
libmailtransport4 libmicroblog4 libnepomuk4 libnepomukquery4a
libnm-glib-vpn1 libnm-glib2 libnm-util1 libplasma3 libqgpgme1 libsane
libservlet2.5-java libsmbclient libsolid4 libssl0.9.8
libsyndication4 libthreadweaver4 libwbclient0 libwebkit-1.0-2
libwebkit-1.0-common linux-base linux-headers-2.6.32-5-amd64
linux-headers-2.6.32-5-common linux-image-2.6.32-5-amd64
linux-libc-dev man-db network-manager openssl opera python python-minimal
rsyslog samba-common samba-common-bin sane-utils smbclient tasksel
tasksel-data wpasupplicant xserver-common xserver-xorg-core
Die folgenden Pakete werden EMPFOHLEN, aber NICHT installiert:
firmware-linux-free
114 Pakete aktualisiert, 3 zusätzlich installiert, 1 werden entfernt und
0 nicht aktualisiert.
Muss 172 MB an Archiven herunterladen. Nach dem Entpacken werden 10,3 MB
frei werden.
I will not do any further updates until i know which package has killed
compositing.
Well, depending on the versions you upgraded from you will probably need to
install firmware-linux-free and/or firmware-linux-nonfree. Or you proprietary
drivers broke, or whatever ... I don't think this might have anything to do
with KDE.
--
Modestas Vainius modes...@vainius.eu
signature.asc
Description: This is a digitally signed message part.
Bug#603354: closed by Colin Watson cjwat...@debian.org (Bug#603354: fixed in grub2 1.99~20101122-1)
Hello, On šeštadienis 18 Gruodis 2010 19:14:43 Colin Watson wrote: Seriously, can I at least get an explanation why a trivial two line patch cannot get to Squeeze? It's not that people upgrade their servers very early in the distro development process but it's the only segment where some kind of RAID is very common. So it's logical that such issues come to bright light only now. If you're consciously limiting a set of hardware where supposedly universal OS could be used by not applying an obvious (!) trivial (!) straightforward (!) patch, you should at least give a good explanation. Actually I just have far too much e-mail and forgot about it. Sorry! I'm preparing an upload at the moment and will include this, although it will be subject to release team approval. Thank you. That's great news. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#603319: Fwd: Problems with DDF1 support in dmraid-activate
tags 603319 pending
thanks
Hello,
On pirmadienis 06 Gruodis 2010 20:59:52 Modestas Vainius wrote:
Like previously [2], feel free to do a maintainer upload or I will NMU in
two weeks from now.
Two weeks is almost up. I have just uploaded dmraid 1.0.0.rc16-4.1 NMU to
DELAYED/2-day.
NMU diff is attached. You may also pull my NMU changes directly from my git
repository.
$ git pull git://git.debian.org/users/modax/dmraid.git master:master
--
Modestas Vainius mo...@debian.org
diff -u dmraid-1.0.0.rc16/debian/dmraid-activate dmraid-1.0.0.rc16/debian/dmraid-activate
--- dmraid-1.0.0.rc16/debian/dmraid-activate
+++ dmraid-1.0.0.rc16/debian/dmraid-activate
@@ -116,13 +116,18 @@
fi
}
-ddf1_virtual_drive_guids()
+ddf1_virtual_drive_names()
{
- ddf1_awk_script=$(cat 'EOF'
+ ddf1_awk_script=$(cat 'EOF'
BEGIN {
section =
disk_ref =
guid_i = 0
+
+# Heximal to decimal conversion array
+for (i = 0; i = 9; i++) hex2dec[i] = i
+hex2dec[a] = 10; hex2dec[b] = 11; hex2dec[c] = 12
+hex2dec[e] = 13; hex2dec[d] = 14; hex2dec[f] = 15;
}
function section_begins(name)
@@ -132,6 +137,42 @@
drive_map = 0
}
+function extract_vd_guid(line, g)
+{
+g = substr(line, match(line,/\[[0-9a-f ]+\]$/)+1, RLENGTH-2)
+gsub(/ /, , g)
+# IF LSI, do timestamp substitution to get persistent name, see
+# 19_ddf1_lsi_persistent_name.patch
+if (g ~ /^4c5349/)
+g = substr(g, 1, 32) 47114711 substr(g, 41)
+return g
+}
+
+function extract_vd_name(line, hex, n, max, i, d1, d2, sed)
+{
+n = tolower(substr(line, match(line,/\[[0-9a-f ]+\]$/)+1, RLENGTH-2))
+max = split(n, hex, / /)
+
+if (max = 0 || hex[0] == 00) return
+
+# Convert name from hex to string (16 bytes)
+n =
+for (i = 1; i = max; i++) {
+d1 = hex2dec[substr(hex[i], 1, 1)]
+d2 = hex2dec[substr(hex[i], 2, 1)]
+if ((d1 + d2) == 0) break
+n = n sprintf(%c, d1 * 16 + d2)
+}
+# Shell-escape single quotes in the name
+gsub(/'/,'\\'', n)
+# Finally strip non-graph chars from the end of the string
+# mawk does not support character classes. Use sed.
+sed = echo ' n ' | sed 's/[^[:graph:]]\+$//'
+sed | getline n
+close(sed)
+return n
+}
+
{
if (!/^0x/ / at /) {
# Section begins
@@ -140,31 +181,45 @@
disk_ref = $3
sub(/^0x/, , disk_ref)
} else if (disk_ref) {
-if (section == Virtual Drive Config Record /^0x008 guid:/) {
-vd_guid = substr($0, match($0,/\[[0-9a-f ]+\]$/)+1, RLENGTH-2)
-gsub(/ /, , vd_guid)
-# IF LSI, do timestamp substitution to get persistent name, see
-# 19_ddf1_lsi_persistent_name.patch
-if (vd_guid ~ /^4c5349/)
-vd_guid = substr(vd_guid, 1, 32) 47114711 substr(vd_guid, 41)
-} else if (drive_map) {
-# 0: 4BCBB980 @ 0
-if ($2 == disk_ref) {
-guids[guid_i] = vd_guid
-guid_i++
+# We need to parse 'Virtual Drive' sections in order to extract VD
+# names
+if (section == Virtual Drive) {
+if (/^0x000 guid:/) {
+vd_guid = extract_vd_guid($0)
+} else if (/^0x030 name:/) {
+vd_name = extract_vd_name($0)
+if (vd_name)
+vd_names[vd_guid] = vd_name
+}
+} else if (section == Virtual Drive Config Record) {
+if (/^0x008 guid:/) {
+vd_guid = extract_vd_guid($0)
+} else if (drive_map) {
+# 0: 4BCBB980 @ 0
+if ($2 == disk_ref) {
+guids[guid_i] = vd_guid
+guid_i++
+}
+} else if (vd_guid) {
+drive_map = /^Drive map:/
}
-} else if (vd_guid) {
-drive_map = /^Drive map:/
}
}
}
END {
-# Print discovered virtual drive GUIDs which belong to this physical drive
-for (guid in guids)
-print guids[guid]
+# Print discovered virtual drive names (or GUIDs) which belong to this
+# physical drive
+for (guid_i in guids) {
+guid = guids[guid_i]
+if (guid in vd_names) {
+print vd_names[guid]
+} else {
+print guid
+}
+}
}
EOF
-)
+)
dmraid -i -n $1 | awk $ddf1_awk_script
}
@@ -193,6 +248,9 @@
exit 0
fi
+newline=
+
+
case $Raid_Name in
isw_*)
# We need a special case for isw arrays, since it is possible to have several
@@ -208,13 +266,20 @@
;;
.ddf1_disks)
# Dummy name for the main DDF1 group. Needs special handling to
- # find RAID subsets for this physical drive
- Ddf1_guids=`ddf1_virtual_drive_guids /dev/$Node_Name`
+ # find RAID subsets (name or GUID) for this physical drive
+ Ddf1_names=`ddf1_virtual_drive_names /dev/$Node_Name`
- for ddf1_guid in $Ddf1_guids
+ # Returned names might contain
Bug#606238: OBJECTION
Hello, On sekmadienis 12 Gruodis 2010 07:30:24 Hideki Yamane wrote: If k3b version 2 is sufficiently stable, why isn't it part of the backports? FWIW, k3b 2 cannot be backported because it's based on KDE 4 Platform which is way too outdated in lenny. # And if I'm not serious - I would just leave bug reports away ;) I bought DVD media to check this bug, at least. You did well, no need to leave anything. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#606238: [Pkg-kde-extras] Bug#606238: OBJECTION
Hello, On penktadienis 10 Gruodis 2010 19:07:32 Peter Hombach wrote: I object to the just upgrade to squeeze and be silent approach. Squeeze is not the stable distribution yet, and one should not be forced to go to testing. If k3b version 2 is sufficiently stable, why isn't it part of the backports? I kindly ask to take bug reports more seriously. We are very serious. The bug is fixed 2.0.0 and it's appropriately noted. The rest is up to you entirely. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#606371: kopete: Kopete freezes immediately when opening opening settings dialog (TV-card present in system)
Hello, On trečiadienis 08 Gruodis 2010 21:02:10 Andreas Jacob wrote: When I try to open the kopete settings dialog, and the dialog pops up, kopete freezes immediately. I've searched upstream for a similar bug and found someone: http://bugs.kde.org/show_bug.cgi?id=241507 . As in descriped in the upstream bugreport I have a TV card in my computer (Hauppauge). Here ist the relevant output of lspci: 01:01.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 01:01.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) 01:01.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 01:01.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) And here is the output, when starting kopete from the command line: libv4l2: error dequeuing buf: Eingabe-/Ausgabefehler VIDIOC_DQBUF error 5, Eingabe-/Ausgabefehler libv4l2: error dequeuing buf: Eingabe-/Ausgabefehler VIDIOC_DQBUF error 5, Eingabe-/Ausgabefehler Eingabe-/Ausgabefehler is german for input/output error. As seen in the resolved upstream bug message, the error should have been fixed upstream some month ago. May be it's a regression of that bug? As an additional note: in my apt sources.list I use the debian-multimedia repository. Would you mind explaining why you chose grave severity for this bug? Misconfigured TV cards like yours are not that common at all and settings dialog is not renders package unusable. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#603319: Fwd: Problems with DDF1 support in dmraid-activate
reopen 603319 found 603319 1.0.0.rc16-4 tags 603319 patch thanks Hello, It has come to my attention (refer to forwarded messages below) that my previous patch was not complete. It only supported the case when DDF1 virtual drive (VD) had no custom human-readable name assigned to it. However, dmraid- active would fail to bring up all named VDs because dmraid will use that name in place of GUID [1] to generate a device identifier. I attach a patch against dmraid-activate in 1.0.0.rc16-4 which should fix this problem and refer to device by either name or GUID using the same logic as dmraid would. Like previously [2], feel free to do a maintainer upload or I will NMU in two weeks from now. P.S. Severity is still RC because we dealing with regressions from Lenny here and dmraid is somewhat critical package once one chooses to use it. [1] See 1.0.0.rc16/lib/format/ddf/ddf1.c:687 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603319#19 -- Forwarded Message -- Subject: Problems with DDF1 support in dmraid-activate Date: pirmadienis 06 Gruodis 2010, 01:20:17 From: Ian R. Justman To: Modestas Vainius mo...@debian.org Hello, there. I am working on a machine I have which uses DDF1 metadata for the array I have created on two drives. The machine is a SuperMicro H8DI3+-F with an AMD SP5100 (server version of SB700) southbridge which uses the ahci driver. It has an Adaptec Embedded RAID BIOS. In this case, the array has two WDC 750GB drives in a RAID 1 configuration. When I created the array using the BIOS configuration utility, it asked for a name, so I gave it one, in this case, Fucked, and then initialized that array. When I bring up whatever arrays are attached, I see the following: r...@haruhi:~# dmraid -ay RAID set ddf1_Fucked was activated r...@haruhi:~# ls /dev/mapper control ddf1_Fucked I can then run whatever partitioning program I wish on /dev/mapper/ddf1_Fucked and create whatever partitions I need. However, the modified activation script you furnished for Debian (I'm running Ubuntu which removed your code in the package they uploaded for Natty) does not activate that array on my system. Here's a dump from one of the constituent devices: r...@haruhi:~# dmraid -i -n /dev/sdb /dev/sdb (ddf1): DDF1 anchor at 1465149167 with tables in little-endian format. DDF1 Header at 0x1618660 0x000 signature:0xDE11DE11 0x004 crc: 0xE001B35B 0x008 guid: De.CDe...g..j.. [44 65 c6 16 02 10 92 43 44 6 5 c6 16 c0 67 c6 16 3c 6a c6 16 ff ff ff ff] 0x020 rev: 02.00.00 [30 32 2e 30 30 2e 30 30] 0x028 seqnum: -1 0x02c timestamp:0x 0x030 open: 0xFF 0x031 foreign: 0xFF 0x032 grouping: 0xFF 0x060 primary header: 1465149156 0x068 secondary header: 18446744073709551615 0x070 header type: 0x0 0x074 workspace len:32768 0x078 workspace lba:1465116388 0x080 max pd: 15 0x082 max vd: 4 0x084 max part: 1 0x086 vd_config len:2 0x088 max_primary_elts: 65535 0x0c0 adapter_offset: 1 0x0c4 adapter_len: 1 0x0c8 pd_offset:2 0x0cc pd_len: 2 0x0d0 vd_offset:4 0x0d4 vd_len: 1 0x0d8 config_offset:5 0x0dc config_len: 4 0x0e0 disk_data_offset: 9 0x0e4 disk_data_len:1 0x0e8 badblock_offset: -1 0x0ec badblock_len: 0 0x0f0 diag_offset: -1 0x0f4 diag_len: 0 0x0f8 vendor_offset:10 0x0fc vendor_len: 1 DDF1 Header at 0x16188d0 0x000 signature:0xDE11DE11 0x004 crc: 0x6B8C351E 0x008 guid: De.CDe...g..j.. [44 65 c6 16 02 10 92 43 44 6 5 c6 16 c0 67 c6 16 3c 6a c6 16 ff ff ff ff] 0x020 rev: 02.00.00 [30 32 2e 30 30 2e 30 30] 0x028 seqnum: -1 0x02c timestamp:0x 0x030 open: 0xFF 0x031 foreign: 0xFF 0x032 grouping: 0xFF 0x060 primary header: 1465149156 0x068 secondary header: 18446744073709551615 0x070 header type: 0x1 0x074 workspace len:32768 0x078 workspace lba:1465116388 0x080 max pd: 15 0x082 max vd: 4 0x084 max part: 1 0x086 vd_config len:2 0x088 max_primary_elts: 65535 0x0c0 adapter_offset: 1 0x0c4 adapter_len: 1 0x0c8 pd_offset:2 0x0cc pd_len: 2 0x0d0 vd_offset:4 0x0d4 vd_len: 1 0x0d8 config_offset:5 0x0dc config_len: 4 0x0e0 disk_data_offset: 9 0x0e4 disk_data_len:1 0x0e8 badblock_offset: -1 0x0ec badblock_len: 0 0x0f0 diag_offset: -1 0x0f4 diag_len: 0 0x0f8 vendor_offset:10 0x0fc vendor_len: 1 Adapter Data at 0x1618ae0 0x000 signature:0xAD11 0x004 crc: 0xAC230C36 0x008 guid: De...g..j...l..ADPT [44 65 c6 16 c0 67 c6 16 3c 6 a c6 16 b8 6c c6 16 41 44 50 54 ff
Bug#606166: kttsd crashes on startup when started without configured talkers
Package: kttsd Version: 4:4.4.5-2 Severity: grave Tags: patch pending confirmed Hello, kttsd crashes on startup where there is no talkers registered in the config file (fresh start). Backtrace is below. Thanks to Valerio Passini for reporting it on the debian-kde mailing list. Application: kttsd (kttsd), signal: Segmentation fault [KCrash Handler] #5 TalkerCode::getTalkerCode (this=0x0) at ../../../kttsd/libkttsd/talkercode.cpp:118 #6 0x00412756 in TalkerMgr::userDefaultTalker (this=value optimized out) at ../../../kttsd/kttsd/talkermgr.cpp:338 #7 0x0040a8d4 in Speaker::init (this=0x14491c0) at ../../../kttsd/kttsd/speaker.cpp:269 #8 0x00408eb1 in KSpeech::initializeSpeaker (this=0x145f260) at ../../../kttsd/kttsd/kspeech.cpp:500 #9 0x00409ba8 in KSpeech::ready (this=0x145f260) at ../../../kttsd/kttsd/kspeech.cpp:479 #10 0x00409e36 in KSpeech::init (this=0x145f260) at ../../../kttsd/kttsd/kspeech.cpp:437 #11 0x004078f6 in main (argc=value optimized out, argv=value optimized out) at ../../../kttsd/kttsd/main.cpp:72 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kttsd depends on: ii kdebase-runtime 4:4.4.5-1 runtime components from the offici ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libkde3support4 4:4.4.5-2 the KDE 3 Support Library for the ii libkdecore5 4:4.4.5-2 the KDE Platform Core Library ii libkdeui5 4:4.4.5-2 the KDE Platform User Interface Li ii libkio5 4:4.4.5-2 the Network-enabled File Managemen ii libqt4-dbus 4:4.7.1-1 Qt 4 D-Bus module ii libqt4-xml4:4.7.1-1 Qt 4 XML module ii libqtcore44:4.7.1-1 Qt 4 core module ii libqtgui4 4:4.7.1-1 Qt 4 GUI module ii libspeechd2 0.7-6 Speech Dispatcher: Shared librarie ii libstdc++64.4.5-10 The GNU Standard C++ Library v3 ii speech-dispatcher 0.7-6 Common interface to speech synthes Versions of packages kttsd recommends: pn kmouthnone (no description available) pn speech-dispatcher-festival | none (no description available) kttsd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590147: Upgrade
Hello, On pirmadienis 29 Lapkritis 2010 10:21:13 Bastien ROUCARIES wrote: . However, there is no information how and when akregator fails to write correct archive file or otherwise corrupts it. I agree also with this part. But it is a second bug Should I duplicate the bug ? No. The two are from my point of view RC No, the first part is not RC because: 1) it is rare enough 2) there is no data loss involved There is no info about the 2nd part and according to upstream, the bug has been there since etch (!!!) meaning two debian stable releases already have it. However, the debian bug has only been reported recently. This tells a lot about commodity of this bug. You may argue as much as you want but probability of this getting fixed is nearly 0% since it has not been fixed for many years and there is obvious lack of information. What is more, metakit has no future. Once akregrator is rewriten based on akonadi, this will go away. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#590147: Upgrade
tags 590147 help thanks Hello, On antradienis 09 Lapkritis 2010 11:23:53 Bastien ROUCARIES wrote: But now there are too many variables. To make things worse, akregator developement isn't very active upstream. I have not the skills to debug this bug, but they are some file that coul allow youy to reproduce it at http://bugs.kde.org/attachment.cgi?id=48011 All that stuff in bug report is useless because both this debian bug and upstream bug deal with consequences. When you see this crash and backtrace, the archive file had already been cut short and the data had already been lost. akregator is simply unable to read corrupt archive file on startup and rather than handling this condition gracefully, it crashes. However, there is no information how and when akregator fails to write correct archive file or otherwise corrupts it. So basically this bug is impossible to fix without a reliable way to reproduce it from the start to finish. During my 2 years of using akregator, I have never had this problem so there is not much I can do. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#603319: dmraid-activate (silently) fails to active RAID1 array
tags 603319 pending
thanks
Hello,
On sekmadienis 14 Lapkritis 2010 16:03:56 Modestas Vainius wrote:
I wrote an awk based program which extracts RAID subsets from the native
log of the physical drive (dmraid -i -n /dev/sda). I will test it in the
next few days and I will send a patch for dmraid-activate if it works.
Special casing is obviously not optimal but changing behaviour of
/sbin/dmraid at this point would be worse imho.
I have confirmed that my solution works. The proposed NMU diff is attached. As
you see, it should not affect anything else but DDF1 RAID disks. Unless you
tell me otherwise or fix this bug in maintainer upload, I will NMU the package
in approx. 2 weeks. I will ping you once again after uploading to DELAYED/2.
--
Modestas Vainius mo...@debian.org
diff -u dmraid-1.0.0.rc16/debian/changelog dmraid-1.0.0.rc16/debian/changelog
--- dmraid-1.0.0.rc16/debian/changelog
+++ dmraid-1.0.0.rc16/debian/changelog
@@ -1,3 +1,13 @@
+dmraid (1.0.0.rc16-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Make dmraid-activate work with DDF1 arrays by special-casing their
+handling. (Closes: #603319) Similar to ISW case, there do not seem to be a
+way for getting raid subsets for the physical drive except parsing native
+log.
+
+ -- Modestas Vainius mo...@debian.org Sun, 14 Nov 2010 15:44:01 +0200
+
dmraid (1.0.0.rc16-3) unstable; urgency=low
* [3bea125] debian/patches/20_fix_isw_sectors_calculation.patch: Fix
diff -u dmraid-1.0.0.rc16/debian/dmraid-activate dmraid-1.0.0.rc16/debian/dmraid-activate
--- dmraid-1.0.0.rc16/debian/dmraid-activate
+++ dmraid-1.0.0.rc16/debian/dmraid-activate
@@ -116,6 +116,58 @@
fi
}
+ddf1_virtual_drive_guids()
+{
+ ddf1_awk_script=$(cat 'EOF'
+BEGIN {
+section =
+disk_ref =
+guid_i = 0
+}
+
+function section_begins(name)
+{
+section = name
+vd_guid =
+drive_map = 0
+}
+
+{
+if (!/^0x/ / at /) {
+# Section begins
+section_begins(substr($0, 1, match($0, / at /)-1))
+} else if (section == Disk Data /^0x020 reference:[ \t]*[0-9A-Fx]+/) {
+disk_ref = $3
+sub(/^0x/, , disk_ref)
+} else if (disk_ref) {
+if (section == Virtual Drive Config Record /^0x008 guid:/) {
+vd_guid = substr($0, match($0,/\[[0-9a-f ]+\]$/)+1, RLENGTH-2)
+gsub(/ /, , vd_guid)
+# IF LSI, do timestamp substitution to get persistent name, see
+# 19_ddf1_lsi_persistent_name.patch
+if (vd_guid ~ /^4c5349/)
+vd_guid = substr(vd_guid, 1, 32) 47114711 substr(vd_guid, 41)
+} else if (drive_map) {
+# 0: 4BCBB980 @ 0
+if ($2 == disk_ref) {
+guids[guid_i] = vd_guid
+guid_i++
+}
+} else if (vd_guid) {
+drive_map = /^Drive map:/
+}
+}
+}
+END {
+# Print discovered virtual drive GUIDs which belong to this physical drive
+for (guid in guids)
+print guids[guid]
+}
+EOF
+)
+ dmraid -i -n $1 | awk $ddf1_awk_script
+}
+
if grep -qs \nodmraid\ /proc/cmdline; then
log_warning dmraid disabled by boot option
exit 0
@@ -141,10 +193,10 @@
exit 0
fi
-# We need a special case for isw arrays, since it is possible to have several
-# subsets of a RAID group, of varying RAID types.
case $Raid_Name in
isw_*)
+ # We need a special case for isw arrays, since it is possible to have several
+ # subsets of a RAID group, of varying RAID types.
Isw_Group_Name=$Raid_Name
Isw_Subsets=$(dmraid -i -n /dev/$Node_Name | grep volume | sed 's/.*volume: *\(.*\)$/\1/')
@@ -154,6 +206,17 @@
done
break
;;
+ .ddf1_disks)
+ # Dummy name for the main DDF1 group. Needs special handling to
+ # find RAID subsets for this physical drive
+ Ddf1_guids=`ddf1_virtual_drive_guids /dev/$Node_Name`
+
+ for ddf1_guid in $Ddf1_guids
+ do
+ activate_array ddf1_${ddf1_guid}
+ done
+ break
+ ;;
*)
activate_array $Raid_Name
break
signature.asc
Description: This is a digitally signed message part.
Bug#603319: dmraid-activate (silently) fails to active RAID1 array
retitle 603319 dmraid-activate does not handle DDF1-based disks properly thanks Hello, apparently, this problem is strictly related to DDF1 format. dmraid-activate needs special handling for it because /sbin/dmraid binary provides no way to extract names of DDF1 RAID subsets for the particular physical device. `dmraid -r` returns only the top group .ddf1_disks [1] which is useless because `dmraid -s` refuses to work with it [2] (contrary to dmraid 1.0.0.rc14 where this works) [1] # dmraid -r /dev/sda /dev/sda: ddf1, .ddf1_disks, GROUP, ok, 486326272 sectors, data@ 0 [2] # dmraid -s .ddf1_disks ERROR: ddf1: wrong # of devices in RAID set ddf1_4c534920202020201055471147110a28 [1/2] on /dev/sdb ERROR: ddf1: wrong # of devices in RAID set ddf1_4c534920202020201055471147110a28 [1/2] on /dev/sda ERROR: either the required RAID set not found or more options required no raid sets and with names: .ddf1_disks I wrote an awk based program which extracts RAID subsets from the native log of the physical drive (dmraid -i -n /dev/sda). I will test it in the next few days and I will send a patch for dmraid-activate if it works. Special casing is obviously not optimal but changing behaviour of /sbin/dmraid at this point would be worse imho. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#603319: dmraid-activate (silently) fails to active RAID1 array
Package: dmraid Version: 1.0.0.rc16-3 Severity: grave Hello, after upgrading from lenny to squeeze, I lost my DMRAID array (raid1). Since my root partition is on DMRAID+LVM, LVM automatically picked up /dev/sdb as PV desynching it from /dev/sda both disks. It was a pure luck I noticed this problem... Since it is not possible to start DMRAID after LVM (/ has already been brought up by initramfs) , kernel kept complaining with bogus ambiguous error messages when I manually ran `dmraid -ay`. This mislead me so I blamed dmraid binary at first and wasted some time debugging it. However, later I discovered that dmraid-activate is at fault here. It looks like dmraid-activate just does nothing and it does not show any error messages. So I added: dmraid -i -ay to the bottom of /usr/share/initramfs-tools/scripts/local-top/dmraid, rebuilt initramfs and my RAID1 array was activated just fine on the next reboot. RAID metadata format is ddf1 and hardware is: RAID bus controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA RAID Controller (rev 01) (by LSI). Therefore, this combination is affected by 19_ddf1_lsi_persistent_name.patch. The reasons I filed this bug as RC are: 1) It's a regression from lenny. 1.0.0.rc14-7/lenny worked just fine with this hardware. What's more, 1.0.0.rc14-7 works fine when installed on Squeeze system. 2) Technically, this failure might leave system unbootable (which sometimes could be considered a better option then the following). 3) It may eventually lead to data loss as it is not recommended to access disks (/dev/sda and /dev/sdb) directly. Bad effects are not predictable. -- Package-specific info: --- dmraid -r -vvv output WARN: locking /var/lock/dmraid/.lock NOTICE: /dev/sdb: asr discovering NOTICE: /dev/sdb: ddf1discovering NOTICE: /dev/sdb: ddf1 metadata discovered NOTICE: /dev/sdb: hpt37x discovering NOTICE: /dev/sdb: hpt45x discovering NOTICE: /dev/sdb: isw discovering NOTICE: /dev/sdb: jmicron discovering NOTICE: /dev/sdb: lsi discovering NOTICE: /dev/sdb: nvidia discovering NOTICE: /dev/sdb: pdc discovering NOTICE: /dev/sdb: sil discovering NOTICE: /dev/sdb: via discovering NOTICE: /dev/sda: asr discovering NOTICE: /dev/sda: ddf1discovering NOTICE: /dev/sda: ddf1 metadata discovered NOTICE: /dev/sda: hpt37x discovering NOTICE: /dev/sda: hpt45x discovering NOTICE: /dev/sda: isw discovering NOTICE: /dev/sda: jmicron discovering NOTICE: /dev/sda: lsi discovering NOTICE: /dev/sda: nvidia discovering NOTICE: /dev/sda: pdc discovering NOTICE: /dev/sda: sil discovering NOTICE: /dev/sda: via discovering INFO: RAID devices discovered: /dev/sdb: ddf1, .ddf1_disks, GROUP, ok, 486326272 sectors, data@ 0 /dev/sda: ddf1, .ddf1_disks, GROUP, ok, 486326272 sectors, data@ 0 WARN: unlocking /var/lock/dmraid/.lock --- dmraid -s -vv output NOTICE: /dev/sdb: asr discovering NOTICE: /dev/sdb: ddf1discovering NOTICE: /dev/sdb: ddf1 metadata discovered NOTICE: /dev/sdb: hpt37x discovering NOTICE: /dev/sdb: hpt45x discovering NOTICE: /dev/sdb: isw discovering NOTICE: /dev/sdb: jmicron discovering NOTICE: /dev/sdb: lsi discovering NOTICE: /dev/sdb: nvidia discovering NOTICE: /dev/sdb: pdc discovering NOTICE: /dev/sdb: sil discovering NOTICE: /dev/sdb: via discovering NOTICE: /dev/sda: asr discovering NOTICE: /dev/sda: ddf1discovering NOTICE: /dev/sda: ddf1 metadata discovered NOTICE: /dev/sda: hpt37x discovering NOTICE: /dev/sda: hpt45x discovering NOTICE: /dev/sda: isw discovering NOTICE: /dev/sda: jmicron discovering NOTICE: /dev/sda: lsi discovering NOTICE: /dev/sda: nvidia discovering NOTICE: /dev/sda: pdc discovering NOTICE: /dev/sda: sil discovering NOTICE: /dev/sda: via discovering NOTICE: added /dev/sdb to RAID set .ddf1_disks NOTICE: added /dev/sda to RAID set .ddf1_disks *** Group superset .ddf1_disks -- Active Subset name : ddf1_4c534920202020201055471147110a28 size : 486326272 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 --- /proc/partitions: major minor #blocks name 80 244198584 sda 81 297171 sda1 82 242862637 sda2 8 16 244198584 sdb 8 17 297171 sdb1 8 18 242862637 sdb2 2540 243163136 dm-0 2541 297171 dm-1 2542 242862637 dm-2 2543 14680064 dm-3 2544 31457280 dm-4 25454194304 dm-5 2546 15728640 dm-6 2547 41943040 dm-7 --- initrd.img-2.6.32-5-amd64: 57189 blocks lib/modules/2.6.32-5-amd64/kernel/drivers/md/dm-region-hash.ko lib/modules/2.6.32-5-amd64/kernel/drivers/md/dm-mirror.ko lib/modules/2.6.32-5-amd64/kernel/drivers/md/dm-snapshot.ko lib/modules/2.6.32-5-amd64/kernel/drivers/md/dm-mod.ko lib/modules/2.6.32-5-amd64/kernel/drivers/md/dm-log.ko --- /proc/modules: dm_mirror 10923 1 - Live 0xa01bb000 dm_region_hash 6680 1 dm_mirror,
Bug#586540: kdm on initial start at kfreebsd bootup does not allow keyboard input
tags 586540 - help owner 586540 ! thanks Hello, On sekmadienis 07 Lapkritis 2010 10:50:01 Petr Salinger wrote: The easiest solution for now is to alter ServerArgsLocal at least on GNU/kFreeBSD in /etc/kde4/kdm/kdmrc to ServerArgsLocal=vt7 -br -nolisten tcp It's very likely that this change would break Start new session feature of KDE which works fine at the moment. While I could live with having it broken on kFreeBSD, that's definitely not acceptable for Linux where this problem does not manifest itself. The bug we are facing here is that kdm starts on vt2 when it's not supposed to even bother with VTs below 7. ServerVTs=-7 setting in /etc/kde4/kdm/kdmrc takes care of it (on Linux). However, apparently ServerVTs does not work on kfbsd for some reason (nor it's present in default kdmrc). Finding that reason would be the real fix and I will look into it later today/tomorrow. It could be as easy as #define which does not cover kfbsd (I hope). Given it looks like it is not so easy, would be possible to upload new package with ServerArgsLocal=vt7 -br -nolisten tcp on GNU/kFreeBSD. It would workaround the bug for squeeze now, the VT switching can be implemented later. I have a hackish patch ready on VM (iirc it is usable). Just I don't have time to do more testing and proper upload right now. But I will get to it eventually, don't worry. Unfortunately, kdm state on kfsbd is not that good overall. Restart/shutdown does not work from KDE sessions, kdm restarts whether it's not supposed to. I planned to look into this as well but I got distracted by kfbsd keyboard layout issues and eventually got overloaded with work. So this bug will have to wait a bit. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#586540: kdm on initial start at kfreebsd bootup does not allow keyboard input
Hello, On sekmadienis 24 Spalis 2010 13:15:29 Robert Millan wrote: This suggests HAVE_VTS macro is not being set. Maybe this helps? --- kdm/backend/greet.h~2008-01-04 23:55:44.0 + +++ kdm/backend/greet.h 2010-10-24 10:13:45.0 + @@ -53,10 +53,8 @@ # define USE_SYSLOG #endif -#ifdef __linux__ /* This needs to be run-time configurable, additionally. */ # define HAVE_VTS -#endif #define DEBUG_CORE 0x01 #define DEBUG_CONFIG 0x02 Yes, but it's not that simple. The code needs porting which I'm trying to do at the moment. But kfreebsd keyboard layout does not want to be friends with me :) -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#586540: kdm on initial start at kfreebsd bootup does not allow keyboard input
Hello, On ketvirtadienis 21 Spalis 2010 14:17:03 Julien Cristau wrote: On Thu, Oct 21, 2010 at 10:57:08 +0200, Petr Salinger wrote: The easiest solution for now is to alter ServerArgsLocal at least on GNU/kFreeBSD in /etc/kde4/kdm/kdmrc to ServerArgsLocal=vt7 -br -nolisten tcp That should be done on linux as well imo. It's very likely that this change would break Start new session feature of KDE which works fine at the moment. While I could live with having it broken on kFreeBSD, that's definitely not acceptable for Linux where this problem does not manifest itself. The bug we are facing here is that kdm starts on vt2 when it's not supposed to even bother with VTs below 7. ServerVTs=-7 setting in /etc/kde4/kdm/kdmrc takes care of it (on Linux). However, apparently ServerVTs does not work on kfbsd for some reason (nor it's present in default kdmrc). Finding that reason would be the real fix and I will look into it later today/tomorrow. It could be as easy as #define which does not cover kfbsd (I hope). -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#590147: Akregator is unusable crash at each start
Hello, On trečiadienis 20 Spalis 2010 11:11:03 Bastien ROUCARIES wrote: No this bug occurs after an upgrade. Upgrade from what version? I could start agregator after deleting all my archive... So crash each time or loss all archive. This supports my assumption that the problem is cache corruption. It is for me release critical ask to kde teams but for me it is release critical. If I could reproduce it, I would agree it's RC. But now there are too many variables. To make things worse, akregator developement isn't very active upstream. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#590147: Akregator is unusable crash at each start
Hello, On šeštadienis 04 Rugsėjis 2010 15:05:44 Bastien ROUCARIES wrote: severity 590147 serious forwarded 590147 https://bugs.kde.org/show_bug.cgi?id=250162 I get a backtrace and forwarded to upstream. Akregator is unusable so increase to serious. Can we both agree that this bug is not release-critical? Many users including me can start akregator fine. You probably ran into some kind of cache corruption issue here. It should be rare and many users will never see it hence it does not qualify as grave or serious, imho. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#599224: libqt4-dbus package does not depend on the dbus library
Package: libqt4-dbus Version: 4:4.6.3-1 Severity: serious Hello, libqt4-dbus dlopens dbus library hence it does not get libdbus-1-3 dependency via shlibs. So either a manual dependency must be added or libQtDBus should link with libdbus-1 properly. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqt4-dbus depends on: ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-1 GCC support library ii libqt4-xml4:4.6.3-2 Qt 4 XML module ii libqtcore44:4.6.3-2 Qt 4 core module ii libstdc++64.4.5-1The GNU Standard C++ Library v3 libqt4-dbus recommends no packages. libqt4-dbus suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597635: plasma-widgets-workspace: Device notifier configuration dialog freezes desktop
severity 597635 normal retitle 597635 Device notifier configuration dialog should be modaless thanks Hello, On antradienis 21 Rugsėjis 2010 18:26:00 Braun Gábor wrote: Package: plasma-widgets-workspace Version: 4:4.4.5-3 Severity: critical Justification: breaks the whole system 1) I right-click on the device notifier icon on the panel and select Beállítások (Settings) from the menu. 2) I select the second icon from the top in the left pane: Eszközműveletek (Actions) 3) Now in the right, I see actions like Megnyitás a fájlkezelővel (open with file manager). I select an action and click on the middle button Szerkesztés (Edit) below. Yes, so a new dialog opens which is modal. By definition, a modal dialog absorbs all input from the other dialogs or GUI widgets which the same application has opened. Unfortunately, in this case, the app opening this modal dialog is a main KDE plasma shell (plasma-desktop) so the dialog blocks it, i.e. your whole desktop. At this point, the desktop darkens and the items on the desktop (panels, widgets on the desktop etc) become unresponsive. No switching to minimized window, no logout, KDE menu unavailable. Only the window manager actions remain: eg moving/resizing windows, using the icons on windows, switching to another displayed window. Yes, the only unresponsive application is plasma-desktop. Too bad it happens to manage the whole KDE desktop. A new dialog appears where one can edit the actions. By closing the dialog, the desktop returns to normal color and the widgets are responsive again. Yes, that's what happens when modal dialog is closed. The parent application starts reacting to input events as usual. But if I minimize the dialog window, I don't see any way to return, so I am stuck with a hardly usable desktop. It is not true. You can use Alt+Tab. Alt+Tab is served by window manager. In my opinion, making the desktop widgets unresponsive is a critical bug because they are essential for using the system (starting applications, logging out, switching between applications etc). I would like to stress one thing here - you willingly minimized the dialog when the rest of the desktop was darkened. So you as a user did a mistake but you still have a way out of it (Alt+Tab). Therefore, this bug is by no way critical as it does not affect anywhere majority of users nor it's consequences are severe. Actually, it is a usability issue so it is merely of normal severity. Generally, I would call it minor but I agree that your arguments against modal dialogs hold in this case. Users may run into such corner cases by accident. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#597333: python-kde4: reference to 'python-sip4': error in version: invalid character in version number
forcemerge 567528 597333 thanks Hello, On šeštadienis 18 Rugsėjis 2010 21:22:56 Jean-Christophe Dubacq wrote: Package: python-kde4 Version: 4:4.3.4-1+b1 Severity: normal When doing any operation with apt-get, I get the following warning: warning, in file '/var/lib/dpkg/available' around line 186640 package 'python-kde4': 'Depends' field, reference to 'python-sip4': error in version: invalid character in version number You are using an ancient version. This bug was fixed long ago. Please upgrade. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#589133:
Hello, On trečiadienis 15 Rugsėjis 2010 08:08:22 Abhishek Dasgupta wrote: xdg-email works quite fine here. It opens Epiphany and then mutt with the selected address. Are you using KDE? It does not look like it from the software you mentioned (Epiphany). -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
