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#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#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
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_i
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#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#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#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#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#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 Description: Tighten FreeBSD system name check not to match kFreeBSD Author: Modestas Vainius 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#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 signature.asc Description: This is a digitally signed message part.
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 signature.asc Description: This is a digitally signed message part.
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 diff -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 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 +Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729545 +Origin: vendor +Last-Update: 2013-11-17 + +--- libmtp-
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 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 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/b
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
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#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#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: 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 2>&1 | 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#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#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#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 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 (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 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=) 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=, 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=, size=4096, bop=0x7fffe3bf6b30, virtualp=0x7fffe3bf6b38, intel=) at ../../src/i965_video.c:392 #5 0x7f9fceffe420 in I965DisplayVideoTextured (scrn=0x7f9fd39c7e80, adaptor_priv=, id=, dstRegion=0x7f9fd8013c80, width=, height=, 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=, drw_x=, drw_y=, src_w=624, src_h=352, drw_w=884, drw_h=499, id=842094169, buf=0x7f9fc9aca000 '\020' ..., width=624, height=352, sync=1, clipBoxes=0x7fffe3bf6da0, data=0x7f9fd5542f90, drawable=0x7f9fd8240380) at ../../src/intel_video.c:1579 #7 0x7f9fd30599ce in xf86XVPutImage (client=, pDraw=0x7f9fd8240380, pPort=0x7f9fd5543d10, pGC=, src_x=, src_y=, src_w=624, src_h=352, drw_x=0, drw_y=23, drw_w=884, drw_h=499, format=0x7f9fd5543a90, data=0x7f9fc9aca000 '\020' ..., 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=, envp=) 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 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 commit e4b60f29609e9993dc7268993da509530862aa78 Author: Chris Wilson 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 commit 902ee661f1864aaf8325621085f6a1b5a6a3673a Author: Dave Airlie Date: Mon Dec 5 21:24:48 2011 + test/radeon: add missing files for dist commit 5c5332bbc38ff25c06081ac53a15ad583ad4cbc4 Author: Chris Wilson 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 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 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=vlc&arch=kfreebsd- i386&ver=1.1.10-1%2Bb1&stamp=1309445176 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635724#35 -- Modestas Vainius 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 -config.cmake files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake//, /usr/lib/cmake// or /usr/share/cmake// 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 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 -config.cmake files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake//, /usr/lib/cmake// or /usr/share/cmake// 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 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 -config.cmake files to /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}/cmake//, /usr/lib/cmake// or /usr/share/cmake// 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 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-workspace&arch=mips&ver=4%3A4.6.5-1&stamp=1311462730 https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspace&arch=mipsel&ver=4%3A4.6.5-2&stamp=1311720152 https://buildd.debian.org/status/fetch.php?pkg=kdesdk&arch=mips&ver=4%3A4.6.5-1&stamp=1311500965 https://buildd.debian.org/status/fetch.php?pkg=kdesdk&arch=mipsel&ver=4%3A4.6.5-1&stamp=1311328518 https://buildd.debian.org/status/fetch.php?pkg=kdebase&arch=mips&ver=4%3A4.6.5-1&stamp=1311458085 https://buildd.debian.org/status/fetch.php?pkg=kdebase&arch=mips&ver=4%3A4.6.5-1&stamp=1311256019 * binutils_2.21.52.20110707-1 https://buildd.debian.org/status/fetch.php?pkg=kdebase-workspace&arch=mips&ver=4%3A4.6.5-1&stamp=1311092775 https://buildd.debian.org/status/fetch.php?pkg=kdebase&arch=mips&ver=4%3A4.6.5-1&stamp=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-workspace&arch=mips&ver=4%3A4.6.5-1&stamp=1311492656 https://buildd.debian.org/status/fetch.php?pkg=kdebase&arch=mips&ver=4%3A4.6.5-1&stamp=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 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 ), 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 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 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.
, {}, {}, > (cls,)) > ImportError: No module named kpushbutton > kcmshell(21320)/python (plugin): Failed to import module > kcmshell(21320)/kcontrol KCModuleLoader::loadModule: This module has no > valid entry symbol at all. The reason could be that it's still using > K_EXPORT_COMPONENT_FACTORY with a custom X-KDE-FactoryName which is not > supported anymore mschmitt@adrastea:~$ Apparently this is because python-qt4 still uses python-support while python- kde4 >= 4:4.6.80 uses dh_python2. Notably: # ln -s /usr/lib/python2.6/dist-packages/PyQt4/uic/widget-plugins/kde4.py /var/lib/python-support/python2.6/PyQt4/uic/widget-plugins/ # ln -s /usr/lib/python2.6/dist-packages/PyQt4/uic/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 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 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 (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 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- x11&arch=armel&ver=4%3A4.7.3-4&stamp=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 signature.asc Description: This is a digitally signed message part.
Bug#631652: kdm crashes on start in kdm_greet
okenizer::notifyFinished (this=0x1ebeda0, finishedObj=) at ../../khtml/html/htmltokenizer.cpp:2136 #27 0x7fc9dc58cb3f in khtml::CachedScript::checkNotify (this=0x1f71d30) at ../../khtml/misc/loader.cpp:397 #28 0x7fc9dc58cd2c in khtml::CachedScript::data (this=0x1f71d30, buffer=, eof=) at ../../khtml/misc/loader.cpp:389 #29 0x7fc9dc58e80b in khtml::Loader::slotFinished (this=0x1d6d3d0, job=0x1fa48c0) at ../../khtml/misc/loader.cpp:1262 #30 0x7fc9dc58ed63 in khtml::Loader::qt_metacall (this=0x1d6d3d0, _c=QMetaObject::InvokeMetaMethod, _id=, _a=0x7fffd5c1cde0) at ./loader.moc:141 #31 0x7fc9f264211a in QMetaObject::activate (sender=0x1fa48c0, m=, local_signal_index=, argv=0x7fffd5c1cde0) at kernel/qobject.cpp:3278 #32 0x7fc9f2aa6992 in KJob::result (this=, _t1=0x1fa48c0) at ./kjob.moc:194 #33 0x7fc9f2aa69d0 in KJob::emitResult (this=0x1fa48c0) at ../../kdecore/jobs/kjob.cpp:312 #34 0x7fc9f3800204 in KIO::SimpleJob::slotFinished (this=0x1fa48c0) at ../../kio/kio/job.cpp:525 #35 0x7fc9f3809a02 in KIO::TransferJob::slotFinished (this=0x1fa48c0) at ../../kio/kio/job.cpp:1113 #36 0x7fc9f3806451 in KIO::TransferJob::qt_metacall (this=0x1fa48c0, _c=QMetaObject::InvokeMetaMethod, _id=, _a=0x7fffd5c1d1c0) at ./jobclasses.moc:367 #37 0x7fc9f264211a in QMetaObject::activate (sender=0x1f3f970, m=, local_signal_index=, argv=0x0) at kernel/qobject.cpp:3278 #38 0x7fc9f38aa6f1 in KIO::SlaveInterface::dispatch (this=, _cmd=104, rawdata=...) at ../../kio/kio/slaveinterface.cpp:173 #39 0x7fc9f38a75a5 in KIO::SlaveInterface::dispatch (this=) at ../../kio/kio/slaveinterface.cpp:89 #40 0x7fc9f389aebe in KIO::Slave::gotInput (this=0x1f3f970) at ../../kio/kio/slave.cpp:348 #41 0x7fc9f389b50c in KIO::Slave::qt_metacall (this=0x1f3f970, _c=QMetaObject::InvokeMetaMethod, _id=, _a=0x7fffd5c1d5e0) at ./slave.moc:82 #42 0x7fc9f264211a in QMetaObject::activate (sender=0x1f478f0, m=, local_signal_index=, argv=0x0) at kernel/qobject.cpp:3278 #43 0x7fc9f37d1047 in dequeue (this=0x1f4d3e0) at ../../kio/kio/connection.cpp:82 #44 KIO::ConnectionPrivate::dequeue (this=0x1f4d3e0) at ../../kio/kio/connection.cpp:71 #45 0x7fc9f37d10ed in KIO::Connection::qt_metacall (this=0x1f478f0, _c=QMetaObject::InvokeMetaMethod, _id=, _a=0x3124710) at ./connection.moc:79 #46 0x7fc9f2645cca in QObject::event (this=0x1f478f0, e=) at kernel/qobject.cpp:1217 #47 0x7fc9f176f784 in notify_helper (this=0x18b64d0, receiver=0x1f478f0, e=0x2e3b420) at kernel/qapplication.cpp:4467 #48 QApplicationPrivate::notify_helper (this=0x18b64d0, receiver=0x1f478f0, e=0x2e3b420) at kernel/qapplication.cpp:4439 #49 0x7fc9f1774611 in QApplication::notify (this=0x7fffd5c1e180, receiver=0x1f478f0, e=0x2e3b420) at kernel/qapplication.cpp:4346 #50 0x7fc9f309a4f6 in KApplication::notify (this=0x7fffd5c1e180, receiver=0x1f478f0, event=0x2e3b420) at ../../kdeui/kernel/kapplication.cpp:311 #51 0x7fc9f262f5bc in QCoreApplication::notifyInternal (this=0x7fffd5c1e180, receiver=0x1f478f0, event=0x2e3b420) at kernel/qcoreapplication.cpp:731 #52 0x7fc9f2632978 in sendEvent (receiver=0x0, event_type=0, data=0x1885860) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215 #53 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x1885860) at kernel/qcoreapplication.cpp:1372 #54 0x7fc9f2659c63 in sendPostedEvents (s=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220 #55 postEventSourceDispatch (s=) at kernel/qeventdispatcher_glib.cpp:277 #56 0x7fc9ed7854a3 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #57 0x7fc9ed785c80 in ?? () from /lib/libglib-2.0.so.0 #58 0x7fc9ed785f1d in g_main_context_iteration () from /lib/libglib-2.0.so.0 #59 0x7fc9f265a0bf in QEventDispatcherGlib::processEvents (this=0x1886f50, flags=) at kernel/qeventdispatcher_glib.cpp:422 #60 0x7fc9f181375e in QGuiEventDispatcherGlib::processEvents (this=, flags=) at kernel/qguieventdispatcher_glib.cpp:204 #61 0x7fc9f262e7c2 in QEventLoop::processEvents (this=, flags=...) at kernel/qeventloop.cpp:149 #62 0x7fc9f262e9bf in QEventLoop::exec (this=0x7fffd5c1dfd0, flags=...) at kernel/qeventloop.cpp:201 #63 0x7fc9f2632b67 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008 #64 0x7fc9f4ecfd32 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_konqueror.so #65 0x7fc9f4ab4ead in __libc_start_main (main=, argc=, ubp_av=, init=, fini=, rtld_fini=, stack_end=0x7fffd5c1ea08) at libc-start.c:228 #66 0x00400691 in _start () -- Modestas Vainius 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 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 Liedes 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#605452: [Pkg-kde-extras] Bug#605452: fixed in digikam 2:1.9.0-3
Hello, On penktadienis 10 Birželis 2011 12:39:42 Dirk Pankonin wrote: > Hi, > > the official debian squeeze site offers for digikam the package version > digikam (2:1.2.0-7). I have also the same problem as described in the bug > and I want to suggest to offer the version 2:1.9.0-3 as the official > version for debian squeeze (maybe in the backport path). I tried to > install the packages from the recommended ftp site with aptitude but I got > error messages because of package version dependencies. I don't want to > switch to the unstable release to get the digikam package run and I'm not > willing to ride an installing version dependency orgy. It is not possible. Later digikam needs newer KDE. However, squeeze proper or squeeze-backports will not get newer KDE. Sorry. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.
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 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 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 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 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 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 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 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 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 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 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 signature.asc Description: This is a digitally signed message part.
Bug#625707: kdebindings: FTBFS: conversion from 'void' to non-scalar type 'QList >' 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 'QList >' requested > > Full build log is here: > https://buildd.debian.org/status/fetch.php?pkg=kdebindings&arch=amd64&ver=4 > %3A4.4.5-5%2Bb1&stamp=1304559565 kdebindings should no longer FTBFS with libphonon-dev (>= 4:4.6.0really4.5.0-3). Add Dep-Wait if needed. -- Modestas Vainius 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 signature.asc Description: This is a digitally signed message part.
Bug#625825: Fixed in gcc-4.6.0-7, please revert the work around
Hello, On sekmadienis 08 Gegužė 2011 03:45:11 Matthias Klose wrote: > Fixed in gcc-4.6.0-7, please revert the work around. Thanks for the info. I'm going to fix this bug by build depending on g++-4.6 (>= 4.6.0-7~) [armel] and breaking g++-4.6 (<< 4.6.0-7~) [armel] instead. P.S. 4.6.0-7 is still not in archive though. Any ETA for upload? -- Modestas Vainius 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 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=kde4libs&arch=armel&ver=4%3A4.4.5-5&stamp=1304545515 [2] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02245.html -- Modestas Vainius 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= optimized out>, consider_profiling=0) > at ../sysdeps/sparc/sparc32/dl-machine.h:402 > #2 elf_dynamic_do_rela (scope=0xf7ff4b98, reloc_mode= out>, consider_profiling=0) at do-rel.h:120 > #3 _dl_relocate_object (scope=0xf7ff4b98, reloc_mode= out>, consider_profiling=0) at dl-reloc.c:268 > #4 0xf7fcd7c0 in dl_main (phdr=, phnum= optimized out>, user_entry=, > auxv=) at rtld.c:2265 > #5 0xf7fdffa4 in _dl_sysdep_start (start_argptr=, > dl_main=0xf7fcc244 ) 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 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 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=kde4libs&arch=kfreebsd-i386&ver=4%3A4.6.2-1&stamp=1304164739 [2] https://buildd.debian.org/status/fetch.php?pkg=akonadi&arch=kfreebsd-amd64&ver=1.3.1-4&stamp=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 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 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 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 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 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 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 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 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 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 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 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 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 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 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(QList&) 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 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 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 : > > 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 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 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 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 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 i
Bug#603354: closed by Colin Watson (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 signature.asc Description: This is a digitally signed message part.
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 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 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 signature.asc Description: This is a digitally signed message part.
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=) 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=, argv=) 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 kmouth (no description available) pn speech-dispatcher-festival | (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#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 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.. UPDATE: If I recreate the array without a name, it works fine. --Ian. - From 9a91ef772cb72856704b89ff83c9db71196081c1 Mon Sep 17 00:00:00 2001 From: Modestas Vainius Date: Mon, 6 Dec 2010 12:05:34 +0200 Subject: [PATCH] dmraid-active: handle the case DDF1 virtual drive has a name. Further improve dmraid-activate DDF1 awk snippet to handle the case when virtual drive (VD) has a human-readable name. In that case, dmraid will use that name instead of the VD GUID when generating a device for the respective raid subset. Since human-readable names might contain spaces, make appropriate (but ugly looking) tweaks to IFS variable as needed. We can't use `while read` since that would fork a new shell and make global variables unavailable for activate_array(). --- debian/dmraid-activate | 113 +-- 1 files changed, 89 insertions(+), 24 deletions(-) diff --git a/debian/dmraid-activate b/debian/dmraid-activate index 7e73473..f420289 100644 --- a/debian/dmraid-activate +++ b/debian/dmraid-activate @@ -116,13 +116,18 @@ log_error() 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 @@ function section_begins(name) 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 = "&quo
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 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 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 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 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 "\" /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 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
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 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 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 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 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 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 signature.asc Description: This is a digitally signed message part.