Bug#734003: linux-image-3.13-rc6-amd64: Display manager fails to start, Intel graphics driver not loaded/used, brightness conrtols reversed
I have not experienced either of these issues with the 3.14 kernel image. Brightness controls work as they should and the display manager loads just fine. Thank you for your reply though. On 2014-05-08 9:24 PM, Matteo Cypriani wrote: Hi Alex, On Thu, 02 Jan 2014 19:33:04 -0500, Alex Vanderpol karash...@gmail.com wrote: Package: src:linux Version: 3.13~rc6-1~exp1 Severity: important Dear Maintainer, This package (version 3.13~rc6-1~exp1) is exhibiting some symptoms that lead me to believe it's buggy, namely: 1: My display manager (GDM) fails to start when the system finishes booting. 2: The Intel graphics driver does not appear to be loaded/used (possibly the reason for #1). Instead, the driver Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) is used. 3: For some reason, the brightness controls end up reversed (trying to lower the brightness raises it, and vice-versa), causing my display to be turned off rather than turned up to full brightness when the system finishes booting (possibly also related to #2). Did you try reproducing this with Linux 3.14? For your #3, you should try passing i915.invert_brightness=1 to the kernel when booting (press E in Grub and add this at the end of the linux line), it should solve the problem. I've read somewhere that if your machine requires this you should report it, but I don't remember where so. Hope this helps, Matteo --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734003: linux-image-3.13-rc6-amd64: Display manager fails to start, Intel graphics driver not loaded/used, brightness conrtols reversed
Package: src:linux Version: 3.13~rc6-1~exp1 Severity: important Dear Maintainer, This package (version 3.13~rc6-1~exp1) is exhibiting some symptoms that lead me to believe it's buggy, namely: 1: My display manager (GDM) fails to start when the system finishes booting. 2: The Intel graphics driver does not appear to be loaded/used (possibly the reason for #1). Instead, the driver Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) is used. 3: For some reason, the brightness controls end up reversed (trying to lower the brightness raises it, and vice-versa), causing my display to be turned off rather than turned up to full brightness when the system finishes booting (possibly also related to #2). If you could please look into these matters, I would be ever so grateful. For the time being, I shall continue to run the 3.12 kernel, which does not experience these issues. -- Package-specific info: ** Version: Linux version 3.13-rc6-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.13~rc6-1~exp1 (2013-12-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.13-rc6-amd64 root=UUID=376d5c13-85a6-476a-aa9e-1be9dc19d808 ro quiet splash ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [ 10.182746] systemd[1]: Starting udev Control Socket. [ 10.182842] systemd[1]: Listening on udev Control Socket. [ 10.182930] systemd[1]: Starting udev Coldplug all Devices... [ 10.183809] systemd[1]: Starting Arbitrary Executable File Formats File System Automount Point. [ 10.184038] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 10.184637] systemd[1]: Started Set Up Additional Binary Formats. [ 10.184655] systemd[1]: Starting Encrypted Volumes. [ 10.184722] systemd[1]: Reached target Encrypted Volumes. [ 10.225326] systemd[1]: Starting Apply Kernel Variables... [ 10.226160] systemd[1]: Expecting device dev-disk-by\x2duuid-360e320b\x2d691a\x2d4e31\x2dbcfb\x2d47b1059d7864.device... [ 10.226255] systemd[1]: Starting File System Check on Root Device... [ 10.227037] systemd[1]: Expecting device dev-disk-by\x2duuid-5405f114\x2de615\x2d4140\x2d8331\x2d6428d0b806d2.device... [ 10.227118] systemd[1]: Expecting device dev-disk-by\x2duuid-62eef65d\x2d32c0\x2d4c66\x2d81eb\x2dbcc97262b00a.device... [ 10.574194] fuse init (API version 7.22) [ 11.362490] loop: module loaded [ 11.475392] systemd-udevd[259]: starting version 204 [ 13.684148] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 14.206514] cfg80211: Calling CRDA to update world regulatory domain [ 14.221595] ACPI: AC Adapter [ACAD] (off-line) [ 14.231365] ACPI: Battery Slot [BAT1] (battery present) [ 14.403692] ACPI Warning: 0x0428-0x042f SystemIO conflicts with Region \PMBA 1 (20131115/utaddress-251) [ 14.403703] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.403710] ACPI Warning: 0x0530-0x053f SystemIO conflicts with Region \GPIO 1 (20131115/utaddress-251) [ 14.403716] ACPI Warning: 0x0530-0x053f SystemIO conflicts with Region \_SB_.PCI0.LPC_.GPIO 2 (20131115/utaddress-251) [ 14.403722] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.403725] ACPI Warning: 0x0500-0x052f SystemIO conflicts with Region \_SB_.PCI0.LPC_.GPIO 1 (20131115/utaddress-251) [ 14.403731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.403733] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 14.502991] Monitor-Mwait will be used to enter C-1 state [ 14.503003] Monitor-Mwait will be used to enter C-2 state [ 14.503008] tsc: Marking TSC unstable due to TSC halts in idle [ 14.503017] ACPI: acpi_idle registered with cpuidle [ 14.503254] Switched to clocksource hpet [ 14.516545] input: PC Speaker as /devices/platform/pcspkr/input/input12 [ 14.641617] i801_smbus :00:1f.3: SMBus using PCI Interrupt [ 14.668314] Intel(R) Wireless WiFi driver for Linux, in-tree: [ 14.668319] Copyright(c) 2003-2013 Intel Corporation [ 14.668520] iwlwifi :02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 14.668706] iwlwifi :02:00.0: irq 44 for MSI/MSI-X [ 14.746313] acerhdf: Acer Aspire One Fan driver, v.0.5.26 [ 14.944354] systemd-udevd[317]: renamed network interface eth0 to eth1 [ 15.101133] acer_wmi: Acer Laptop ACPI-WMI Extras [ 15.105763] acer_wmi: Function bitmap for Communication Device: 0x10 [ 15.105771] acer_wmi: Brightness must be controlled by acpi video driver [ 15.106072] input: Acer BMA150 accelerometer as /devices/virtual/input/input13 [ 15.109883] iwlwifi :02:00.0: firmware: direct-loading firmware iwlwifi-1000-5.ucode [ 15.110112] iwlwifi :02:00.0: loaded firmware version 39.31.5.1 build 35138
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line [ 0.000000] to dmesg file
On 2013-10-25 4:02 AM, John Wright wrote: On Sun, Oct 20, 2013 at 10:25:31PM -0400, Alex Vanderpol wrote: Unfortunately I no longer have any of those crash dumps available to send you anything, I had sent what I had gotten to the kernel maintainers previously in an attempt to track down the cause of the crashing, which I don't believe was ever figured out exactly but was ultimate fixed in a later kernel version. I don't know if they would still happen to have it on hand or not, though. For what it's worth, there never was a vmcore file created any time I did get a dump, instead I always got two separate files, one which is the main core dump and one which is supposed to be the dmesg log dump which unfortunately was never actually able to be dumped (the issue I filed this bug report about). If the end result is supposed to be one vmcore file, I suspect the inability of makedumpfile to dump the kernel dmesg log prohibited it from combining the two files into one file. It's always two separate files. They are not meant to be combined - the dmesg dump is just intended for convenience (you can just read the file as text instead of opening a dump with crash). Using the 'log' command from within crash was ultimately useless as well, as the kernel log wasn't dumped, therefore there wasn't any log for crash to open. This issue was with kernel 3.11-rc4-amd64 in its stock configuration. Not a Debian package? I'm not sure what you mean when you say stock configuration. Do you mean you ran 'make defconfig' to generate the kernel .config? What I meant was that it was the kernel image as supplied in the Debian repos, without any custom changes of any sort made. I'm sorry if I confused you, the correct terminology for some things eludes me at times. I hope what information I am able to give you proves to be at least somewhat useful. I'm not really sure what you saw. :-/ I'll see if I can reproduce anything with linux-image-3.11-1-amd64_3.11.5-1_amd64 when I have some free time (I lost the VM I use for testing this stuff). It's possible there was a short-lived bug in the kernel itself, causing some corrupt representation of its log buffer. I am quite sorry I can't be of any real help here. If I had thought they might be necessary at all for this particular bug I would have held onto what I got from the crash dumps, but once the bug I was having with the kernel was resolved with a later kernel version, and since I'd already sent a copy of what I got to the kernel maintainers prior to the newer release, I didn't think I needed them anymore and removed them as part of my routine cleanup. It is quite possible that, as the kernel in question was an RC build, this issue may have been just one more kink that was ultimately smoothed out in the later builds, along with whatever was causing the kernel to crash on me whenever Folding@Home tried to resume its current work unit. Digging back to one of my messages on the kernel bug I filed at the time, I mentioned to the kernel maintainers that: When I run the 'log' command within crash I get this message: log: WARNING: log buf data structure(s) have changed and of course, the separate log dump file issue this bug is about. The first message in the kernel bug thread when I ran into this problem with makedumpfile is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719277#65 if you want to have a look, I don't know if there's anything that might be useful there as it wasn't long after that I filed this bug. On 2013-10-20 10:29 PM, John Wright wrote: Hi Alex, On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: Package: makedumpfile Version: 1.5.4-1 Severity: grave Justification: renders package unusable Dear Maintainer, There seems to be a serious issue with makedumpfile that causes it to fail to dump the kernel log when collecting crash dump information. Instead, the program continues to run indefinitely, continually appending the line [ 0.00] to the file as it seems to attempt to dump the log, which, if left alone for any considerable length of time, can rapidly result in a very large, entirely useless dmesg dump file. I have been trying to collect crash dump information for a crash that's triggered whenever Folding@Home's FahCore_a4 attempts to resume an in-progress work unit, however, every crash dump I've collected has had this problem. The main dump file seems to be dumped without a problem (though crash identifies it as a partial dump, possibly due to the kernel log being dumped into a separate file). I hope you can look into this issue and hopefully it can be sorted out soon. Sorry for the long delay in my response. This seems like a serious but not actually grave issue, since the core dump does actually exist (even though you have to interrupt the dmesg extraction). crash identifies the dump as a partial dump because we explicitly ignore zero pages and userspace pages. Within crash
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line [ 0.000000] to dmesg file
Unfortunately I no longer have any of those crash dumps available to send you anything, I had sent what I had gotten to the kernel maintainers previously in an attempt to track down the cause of the crashing, which I don't believe was ever figured out exactly but was ultimate fixed in a later kernel version. I don't know if they would still happen to have it on hand or not, though. For what it's worth, there never was a vmcore file created any time I did get a dump, instead I always got two separate files, one which is the main core dump and one which is supposed to be the dmesg log dump which unfortunately was never actually able to be dumped (the issue I filed this bug report about). If the end result is supposed to be one vmcore file, I suspect the inability of makedumpfile to dump the kernel dmesg log prohibited it from combining the two files into one file. Using the 'log' command from within crash was ultimately useless as well, as the kernel log wasn't dumped, therefore there wasn't any log for crash to open. This issue was with kernel 3.11-rc4-amd64 in its stock configuration. I hope what information I am able to give you proves to be at least somewhat useful. On 2013-10-20 10:29 PM, John Wright wrote: Hi Alex, On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: Package: makedumpfile Version: 1.5.4-1 Severity: grave Justification: renders package unusable Dear Maintainer, There seems to be a serious issue with makedumpfile that causes it to fail to dump the kernel log when collecting crash dump information. Instead, the program continues to run indefinitely, continually appending the line [ 0.00] to the file as it seems to attempt to dump the log, which, if left alone for any considerable length of time, can rapidly result in a very large, entirely useless dmesg dump file. I have been trying to collect crash dump information for a crash that's triggered whenever Folding@Home's FahCore_a4 attempts to resume an in-progress work unit, however, every crash dump I've collected has had this problem. The main dump file seems to be dumped without a problem (though crash identifies it as a partial dump, possibly due to the kernel log being dumped into a separate file). I hope you can look into this issue and hopefully it can be sorted out soon. Sorry for the long delay in my response. This seems like a serious but not actually grave issue, since the core dump does actually exist (even though you have to interrupt the dmesg extraction). crash identifies the dump as a partial dump because we explicitly ignore zero pages and userspace pages. Within crash, you should be able to use the 'log' command to get the most recent log messages before the crash...assuming crash doesn't break in the same way makedumpfile does. I will try to reproduce this, but I worry the problem might be somewhat specific either to your crash or some other part of your configuration. Would you feel comfortable making the vmcore available to me? It would also help to know the exact kernel version, and access to a dbg package if it's not a stock kernel. Sorry for the issue and thanks for the report! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725760: gnome-shell: Network status icon no longer displayed in top bar
Package: gnome-shell Version: 3.8.4-2 Severity: normal Dear Maintainer, Just want to inform you that the current version of GNOME Shell (3.8.4-2) no longer displays the network status icon in the top bar. If you could please fix that so the network status icon is displayed again, that would be great. Right now the only way to connect to a new network or check the network connectivity status is through the Network control center applet, which is rather inconvenient versus using the status icon. For now, I am going to downgrade GNOME Shell to version 3.8.4-1, since that version still correctly displays the network status icon. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing'), (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.16.1-1 ii evolution-data-server3.8.5-2 ii gdm3 3.8.4-1 ii gir1.2-accountsservice-1.0 0.6.34-2 ii gir1.2-caribou-1.0 0.4.12-1 ii gir1.2-clutter-1.0 1.14.4-3 ii gir1.2-freedesktop 1.36.0-2+b1 ii gir1.2-gcr-3 3.8.2-4 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.36.0-2+b1 ii gir1.2-gmenu-3.0 3.8.0-2 ii gir1.2-gnomebluetooth-1.03.8.1-2 ii gir1.2-gnomedesktop-3.0 3.8.4-1 ii gir1.2-gtk-3.0 3.8.4-1 ii gir1.2-ibus-1.0 1.5.3-7 ii gir1.2-mutter-3.03.8.3-1 ii gir1.2-networkmanager-1.00.9.8.0-5 ii gir1.2-nmgtk-1.0 0.9.8.4-1 ii gir1.2-pango-1.0 1.32.5-5+b1 ii gir1.2-polkit-1.00.112-1 ii gir1.2-soup-2.4 2.42.2-6 ii gir1.2-telepathyglib-0.120.22.0-1 ii gir1.2-telepathylogger-0.2 0.8.0-2 ii gir1.2-upowerglib-1.00.9.21-3 ii gjs 1.36.1-2 ii gnome-bluetooth 3.8.1-2 ii gnome-icon-theme-symbolic3.8.2.2-2 ii gnome-settings-daemon3.8.5-1 ii gnome-shell-common 3.8.4-2 ii gnome-themes-standard3.8.4-1 ii gsettings-desktop-schemas3.8.0-1 ii libatk-bridge2.0-0 2.10.0-2 ii libatk1.0-0 2.10.0-2 ii libc62.17-93 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcamel-1.2-43 3.8.5-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libclutter-1.0-0 1.14.4-3 ii libcogl-pango12 1.14.0-3 ii libcogl121.14.0-3 ii libcroco30.6.8-2 ii libecal-1.2-15 3.8.5-2 ii libedataserver-1.2-173.8.5-2 ii libegl1-mesa [libegl1-x11] 9.2.1-1 ii libgck-1-0 3.8.2-4 ii libgcr-base-3-1 3.8.2-4 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libgirepository-1.0-11.36.0-2+b1 ii libgjs0c [libgjs0-libmozjs185-1.0] 1.36.1-2 ii libglib2.0-0 2.38.0-1 ii libgnome-menu-3-03.8.0-2 ii libgstreamer1.0-01.2.0-1 ii libgtk-3-0 3.8.4-1 ii libical0 0.48-2 ii libjson-glib-1.0-0 0.16.2-1 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-4+b1 ii libmutter0b 3.8.3-1 ii libnspr4 2:4.10-1 ii libnspr4-0d 2:4.10-1 ii libnss3 2:3.15.1-2 ii libnss3-1d 2:3.15.1-2 ii libp11-kit0 0.20.1-1 ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpolkit-agent-1-0 0.112-1 ii
Bug#709846: synaptic: Download status column vanishes when downloads begin
I figured out what's happening, so hopefully you can look into it and maybe fix it now. Apparently the width of the status column in the individual file details table is being reduced to zero by all of the other columns beside it, the only way to get it to appear is to stretch the dialog window out wide enough that the columns can all be fully displayed without having to be scrolled horizontally. Perhaps the status column needs to be given a minimum width so that it's width cannot be reduced to zero by the other columns? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
Just want to let you know this bug can be closed now, I haven't once had the kernel crash due to Folding@Home since my last message and I've gone through several work units since then, all of which had been resumed several times through their progress. I think it's quite safe to say whatever bug was causing the kernel to crash back in 3.11-rc4 was fixed in 3.11-rc7 and remains fixed in the latest version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
I would like to report that this issue seems to have been resolved in kernel 3.11-rc7, I am able to run Folding@Home without the kernel crashing. I do currently appear to be working on a different type of unit than I had been with the previous kernel, however, but it does appear to be using the same core (FahCore_a4) that had been causing the crashes. This unit will probably take about 10 days or so to complete, as it's quite a large one, hopefully the next unit I receive is of a similar type to the ones I had been working on previously when the kernel was crashing any time Folding@Home attempted to resume the work units. I will check back in later with a status update, hopefully this issue has indeed been resolved and it's not just a fluke because of a different type of work unit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
(In reply to your earlier email) The problem is that I'm already using version 1.5.4-1 from Unstable, and it's having that issue, so either something's been changed in the recent kernel version that broke it again, or makedumpfile has regressed since version 1.5.1-1. Either way I've already filed a bug about it, so hopefully the package maintainers will look into it. (In reply to your later email) I've attached crash's output including the back trace and process status information, if there's anything else from crash (other than the unfortunately unobtainable crash log, which is dumped separately anyway) that you need, let me know and I'll see if I can get it to you. As for the questions I had asked, don't worry about them, I ended up finding some helpful information some time a little later that helped me address some of those issues. crash 7.0.1 Copyright (C) 2002-2013 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter help copying to see the conditions. This program has absolutely no warranty. Enter help warranty for details. NOTE: stdin: not a tty GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu... please wait... (gathering kmem slab cache data) please wait... (gathering module symbol data) please wait... (gathering task table data) please wait... (determining panic task) KERNEL: /usr/lib/debug/vmlinux DUMPFILE: /data/crashdumps/201308162051/dump.201308162051 [PARTIAL DUMP] CPUS: 2 DATE: Fri Aug 16 20:50:41 2013 UPTIME: 00:01:18 LOAD AVERAGE: 1.47, 0.63, 0.23 TASKS: 185 NODENAME: Kara01 RELEASE: 3.11-rc4-amd64 VERSION: #1 SMP Debian 3.11~rc4-1~exp1 (2013-08-08) MACHINE: x86_64 (1296 Mhz) MEMORY: 3.9 GB PANIC: WARNING: log buf data structure(s) have changed PID: 1765 COMMAND: FahCore_a4 TASK: 880137280800 [THREAD_INFO: 88013a41] CPU: 0 STATE: TASK_RUNNING (PANIC) PID: 1765 TASK: 880137280800 CPU: 0 COMMAND: FahCore_a4 #0 [88013a4119f0] machine_kexec at 8103366c #1 [88013a411a50] crash_kexec at 8108f00e #2 [88013a411b08] oops_end at 8138f793 #3 [88013a411b28] no_context at 81387f81 #4 [88013a411b68] __do_page_fault at 81391a58 #5 [88013a411c60] page_fault at 8138ee18 [exception RIP: jbd2_journal_file_inode+53] RIP: a02af28c RSP: 88013a411d10 RFLAGS: 00010246 RAX: RBX: 880138fe0ec0 RCX: 0019 RDX: 880138fe0ec0 RSI: RDI: 8801362553d8 RBP: R8: 880136541218 R9: b923 R10: 0020 R11: R12: 8801362553d8 R13: 8801362553d8 R14: 08cc R15: 1000 ORIG_RAX: CS: 0010 SS: 0018 #6 [88013a411d30] ext4_block_zero_page_range at a02d9112 [ext4] #7 [88013a411d88] ext4_truncate at a02d9b5f [ext4] #8 [88013a411de8] ext4_setattr at a02da5b2 [ext4] #9 [88013a411e48] notify_change at 81128a87 #10 [88013a411eb8] do_truncate at 811134fa #11 [88013a411f20] vfs_truncate at 81113656 #12 [88013a411f48] do_sys_truncate at 811137ce #13 [88013a411f80] system_call_fastpath at 81393d29 RIP: 008c3797 RSP: 7fd67a8fda68 RFLAGS: 0246 RAX: 004c RBX: 81393d29 RCX: RDX: 015cb3c0 RSI: 0007f8cc RDI: 0170f590 RBP: 1020 R8: 00c00140 R9: 06e5 R10: R11: 0206 R12: 0001 R13: 015c9900 R14: 015caa50 R15: 8801365fde40 ORIG_RAX: 004c CS: 0033 SS: 002b PIDPPID CPU TASKST %MEM VSZRSS COMM 0 0 0 81613400 RU 0.0 0 0 [swapper/0] 0
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
I've discovered that the kernel only crashes when the Folding@Home core attempts to resume a work unit already in progress. After configuring kdump-tools to not collect unused memory pages (something apparently recommended if your system has a larger amount of memory), I attempted to trigger a crash by starting the Folding@Home client service. However, after starting the service and waiting about 15 seconds or so (about how long it takes from starting the service to the kernel crashing), there was no crash. I waited a while longer, then checked on the work unit progress with FAHControl and noticed that Folding@Home had just downloaded and started a new work unit (that, thankfully, uses the same core as the previous one) as the previous unit had already been finished. I let it run all night without any issues, however when I powered off my laptop, booted it up again later and attempted to run Folding@Home again, the kernel crashed upon Folding@Home trying to resume the work unit. I do seem to have a problem getting crash dump collection to work, though. The dmesg file collected with this latest crash dump (which is apparently where the kernel log gets dumped, separate from the dump file) only contains the line [0.00] precisely 15447298 times (according to nano's line count upon opening the file). Clearly something is broken, but I do not know what exactly it is. (Previous attempts at crash dump collection did not even give me a plain text dmesg file, for some reason they were being saved as binary files, and I was unable to read them.) I may continue trying to get a proper crash dump with a proper kernel log dump with actual information in it so you have something to look at, though at this rate I'm about ready to give up. If you'd like what I have managed to get so far, useless dmesg file and all, I've packaged it up as a 277.4 MB .tar.gz I could send or upload to a file hosting site for you to download. If I do actually manage to get a kernel log with something useful in it (or, at least, something other than the same line repeated millions of times over) I will send that to you as soon as I can. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
Well, I've discovered why makedumpfile continues to run even after the dump files show up in the folder. It's failing to properly dump the kernel log, and is continually appending the line [ 0.00] to the dmesg file. I just ended up with a 3 GB file, nano ended up kaput trying to open it so I have no idea how many times it ended up printing that line into the file. I am going to file a bug on makedumpfile about this and hopefully it can be resolved, until then I am ceasing my dump collection attempts. (That said, the main dump file seems to be in alright shape, so some information may be able to be gleaned from that... I've archived my latest crash dump without the unnecessarily large, useless dmesg file and the total size comes to 107.4 MB, if your mail server can handle a file this size and you feel there may be something useful in the dump I can send the file with my next message.) (Also, apparently I was wrong about the previous dmesg dump files being saved as binary files, apparently that was a permissions-related issue, as they can only be viewed as root. Attempting to view them as a non-root user seems to mistakenly identify them as binary files rather than plain-text.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line [ 0.000000] to dmesg file
Package: makedumpfile Version: 1.5.4-1 Severity: grave Justification: renders package unusable Dear Maintainer, There seems to be a serious issue with makedumpfile that causes it to fail to dump the kernel log when collecting crash dump information. Instead, the program continues to run indefinitely, continually appending the line [ 0.00] to the file as it seems to attempt to dump the log, which, if left alone for any considerable length of time, can rapidly result in a very large, entirely useless dmesg dump file. I have been trying to collect crash dump information for a crash that's triggered whenever Folding@Home's FahCore_a4 attempts to resume an in-progress work unit, however, every crash dump I've collected has had this problem. The main dump file seems to be dumped without a problem (though crash identifies it as a partial dump, possibly due to the kernel log being dumped into a separate file). I hope you can look into this issue and hopefully it can be sorted out soon. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing'), (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-rc4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages makedumpfile depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-92 ii libdw1 0.156-1 ii libelf1 0.156-1 ii perl5.14.2-21 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages makedumpfile recommends: ii crash7.0.1-3 ii kexec-tools 1:2.0.3-4 makedumpfile suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
Apparently having the kernel image debug package installed is a good idea when trying to do anything with crash dumps... After installing the ~2GB (unpacked) package I was able to use the crash utility to analyze (to a degree) the crash dump file made by kdump-tools, however I am unable to extract the kernel log from the dump. When I run the 'log' command within crash I get this message: log: WARNING: log buf data structure(s) have changed I can, however, get a backtrace and the process status information from the dump. If you think it would be useful, I can output what I am able to get from crash to a file to send to you for you to look at. Also, I have a few questions: 1) Is there any way at all to give the crash kernel more memory to work with? kdump-tools does not work if I specify an amount greater than 128M in the bootloader config file (the system does not reboot into the crash kernel), which seems unnecessarily small for a system with 4GB of memory available, and it seems like the small amount of memory available slows things down considerably. 2) How long should the crash dump collection process normally take? I've noticed that it usually takes about 4 or 5 minutes after the system finishes rebooting for the dump and dmesg files to show up in the crash dump folder specified (prior to which there's only one file, dump_incomplete), however the makedumpfile process seems to continue running even after 5 hours (watching it with top). 3) Is the system supposed to boot as normal when booting into the crash kernel to collect the crash dump? I ask, because mine does, and the severely limited amount of memory available doesn't seem to allow for a full boot. (I suspect I may need to specifically tell kdump-tools to boot into a more suitable runlevel, as it doesn't appear to do so on its own.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
Ah, I didn't know exactly what you meant. Unfortunately I don't know how to extract anything from the dump files I got with kdump-tools. There are two files in the crash dump directory I made and pointed kdump-tools to, dmesg.201308111839 (which is the 2.9 GB file) and dump.201308111839 (the 1.5 GB file). I cannot seem to find anything useful with Google about what to do with these files. I'm pretty sure the Debian-supplied kernel is configured to work with kdump-tools (at least, the default configuration state in the sources was configured correctly for such, and I did get a kernel dump), but I do not have a debug kernel image available, which I'm assuming would probably make this easier. I'm going to look into trying to set things up better so I can hopefully get a crash dump I can actually do something with, I found a site that has some useful information and maybe I can get something that's actually useful, though if you know how to work with those files I mentioned above, I'll gladly take that information as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
I was unable to get a photo of the screen output, apparently neither of the cameras I have available can take high enough resolution shots to actually read the output even slightly, so I carefully wrote down (nearly) everything that was displayed and carefully typed it out into a text file (formatting may not be *exactly* as was on screen, but should be close enough) to send to you. The only thing not written down/typed out was the large list of kernel modules linked to (as I didn't think it was necessary), though if needed I can easily enough crash the kernel again to get that list for you. During my writing out of the terminal output I came to understand, due to its specifically being referenced in the output, that it's not the Folding@Home client service itself that's crashing the kernel, but the Folding@Home core (specifically, FahCore_a4, as you'll see in the terminal output) that's causing the kernel crash. Anyway, I hope this might help shed some light on the problem. BUG: Unable to handle kernel NULL pointer dereference at (null) IP: [a029728c] jbd2_journal_file_inode+0x35/0xdd [jbd2] PGD 1399c1067 PUD 1399b6067 PMD 0 Oops: [#1] SMP Modules linked in: [long list of modules] CPU: 0 PID: 1963 Comm: FahCore_a4 Tainted: G I 3.11-rc4-amd64 #1 Debian 3.11~rc4-1~exp1 Hardware name: Acer Aspire 1810TZ/JM11-MS, BIOS v1.3314 08/31/2010 task: 880139a40801 ti: 880139a4 task.ti: 880139a4 RIP: 0010:[a029728c] [a029728c] jbd2_journal_file_inode+0x35/0xdd [jbd2] RSP: 0018:880139a41d10 EFLAGS:00010246 RAX: RBX: 880138f7e1c0 RCX: 0019 RDX: 880138f7e1c0 RSI: RDI: 8801382c4408 RBP: R08: 8801382cf218 R09: 0020 R10: R11: R12: 8801382c4408 R13: 8801328c4408 R14: 08cc R15: 1000 FS: 7f595ead8700() GS: 88013fc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 000139993000 CR4: 000407f0 Stack: ea000404b728 8801382cf0b0 0734 8801382c4408 a02b1112 1000 007f 08cc 8801382cb540 8801382cf0b0 880139a41de0 8801382c4408 Call Trace: [a02b1112] ? ext4_block_zero_page_range+0x28b/0x29c [ext4] [a02b1bff] ? ext4_truncate+0x152/0x27f [ext4] [8111d48e] ? walk_component+0x163/0x1a2 [8112a22c] ? mntget+0x17/0x1c [811287b9] ? inode_change+0x2c/0x11a [a02b25b2] ? ext4_setattr+0x412/0x4b2 [ext4] [81046971] ? current_fs_time+0x2f/0x35 [81128a87] ? notify_change+0x1e0/0x2cc [81103b75] ? kmem_cache_free+0x3f/0x7c [811134fa] ? do_truncate+0x63/0x87 [81113656] ? vfs_truncate+0xe6/0x10d [811137ce] ? do_sys_truncate+0x3d/0x77 [81393d29] ? system_call_fastpath+0x16/0x1b Code: f5 53 48 8b 1f 48 85 db 75 11 be 49 09 00 00 48 c7 c7 14 03 2a a0 e8 70 c7 da e0 4c 89 e7 e8 3f df ff ff 85 c0 0f 85 98 00 00 48 39 5d 00 4c 8b 2b 0f 84 92 00 00 00 48 39 5d 08 0f 84 88 00 RIP [a029728c] jbd2_journal_file_inode+0x35/0xdd [jbd2] RSP 880139a41d10 CR2: ---[ end trace 0b57ed6584cd4409 ]---
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes after booting before display manager starts
It would seem the issue isn't so much that the kernel is causing the display manager to fail to start, apparently the kernel is crashing after the system finishes booting but before the display manager starts. I attempted to boot the system using SysV on the off chance it was an issue with the kernel and systemd not getting along and I got a dump in the terminal output after the system finished booting but before the display manager was started, however I do not know how to log such an event and I had no convenient way to take down any of what was displayed. (I did not get such output when booting using systemd for init, so I was not aware at the time I filed this bug that it was the kernel crashing.) If there's any way I can log the kernel crash dump for you I would like to know so I could do so, I believe there was more dumped than what could be displayed on screen, and I'm sure you would need the whole dump for it to really be of any use... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
So I figured out what's crashing the kernel, apparently kernel 3.11-rc4 and Folding@Home (when run as a system service) don't get along. I suspect this may be an issue with Folding@Home rather than the kernel, I may need to get in touch with them and inform them of this issue so it can be resolved. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
Oh, well, in that case, I guess reporting it was a good idea then. I can probably capture a crash dump some time later, if you need it, right now though I need to get some rest. On 11/08/13 07:50 AM, Ben Hutchings wrote: On Sun, 2013-08-11 at 07:40 -0400, Alex Vanderpol wrote: So I figured out what's crashing the kernel, apparently kernel 3.11-rc4 and Folding@Home (when run as a system service) don't get along. I suspect this may be an issue with Folding@Home rather than the kernel, I may need to get in touch with them and inform them of this issue so it can be resolved. It is a kernel bug; no application should be able to crash the kernel (unless it's run with special privileges). Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Kernel crashes when running Folding@Home as a system service
I have to ask: Is it normal for a crash dump (and, apparently, a dmesg dump as well) to be several GB in size? I ask, because my dump file from the crash is 1.5 GB and the dmesg dump is 2.9 GB. I would like to submit these somehow but I don't think via email would be the best way to do so, and I can't find any good, free file hosting sites that will accept files this large. Would anyone have anny suggestions as to what to do with them? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719277: linux-image-3.11-rc4-amd64: Display manager fails to start after system boots, cannot switch VTs
Package: src:linux Version: 3.11~rc4-1~exp1 Severity: important Dear Maintainer, It would seem that with the current RC of kernel 3.11 my display manager (GDM) fails to start after the system finishes booting, and I am unable to switch to any of the virtual consoles. It seems the system freezes up when trying to start the display manager, and all I am able to do is power off the system by holding down the power button. In order to file this bug with reportbug I had to boot into recovery mode and launch an X session from there, thus the Linux command line. Allowing the boot process to continue results in the same issue as a normal boot. I am fairly certain this is somehow related to the 3.11 RC kernel image because the display manager starts properly using the other available kernel images. I should probably also mention I am using Systemd for init due to it essentially being required by GNOME, however I do not believe this should be an issue. -- Package-specific info: ** Version: Linux version 3.11-rc4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.11~rc4-1~exp1 (2013-08-08) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.11-rc4-amd64 root=UUID=376d5c13-85a6-476a-aa9e-1be9dc19d808 ro single ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [ 14.130112] ACPI: Battery Slot [BAT1] (battery present) [ 14.190657] i801_smbus :00:1f.3: SMBus using PCI Interrupt [ 14.275159] input: PC Speaker as /devices/platform/pcspkr/input/input7 [ 14.455183] microcode: CPU0 sig=0x1067a, pf=0x80, revision=0xa07 [ 14.540446] acerhdf: Acer Aspire One Fan driver, v.0.5.26 [ 14.692474] ACPI Warning: 0x0428-0x042f SystemIO conflicts with Region \PMBA 1 (20130517/utaddress-251) [ 14.694610] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.700046] ACPI Warning: 0x0530-0x053f SystemIO conflicts with Region \GPIO 1 (20130517/utaddress-251) [ 14.702561] ACPI Warning: 0x0530-0x053f SystemIO conflicts with Region \_SB_.PCI0.LPC_.GPIO 2 (20130517/utaddress-251) [ 14.704747] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.706975] ACPI Warning: 0x0500-0x052f SystemIO conflicts with Region \_SB_.PCI0.LPC_.GPIO 1 (20130517/utaddress-251) [ 14.709223] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 14.711437] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 14.853933] cfg80211: Calling CRDA to update world regulatory domain [ 14.908380] systemd-udevd[321]: renamed network interface eth0 to eth1 [ 14.984879] acer_wmi: Acer Laptop ACPI-WMI Extras [ 14.991839] acer_wmi: Function bitmap for Communication Device: 0x10 [ 14.994159] acer_wmi: Brightness must be controlled by acpi video driver [ 14.996841] input: Acer BMA150 accelerometer as /devices/virtual/input/input8 [ 15.028740] platform microcode: firmware: agent aborted loading intel-ucode/06-17-0a (not found?) [ 15.031262] microcode: CPU1 sig=0x1067a, pf=0x80, revision=0xa07 [ 15.059332] iTCO_vendor_support: vendor-support=0 [ 15.068956] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [ 15.071390] iTCO_wdt: Found a ICH9M-E TCO device (Version=2, TCOBASE=0x0460) [ 15.074114] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 15.081653] platform microcode: firmware: agent aborted loading intel-ucode/06-17-0a (not found?) [ 15.084506] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 15.159526] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa, board id: 3655, fw id: 568746 [ 15.208288] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input9 [ 15.229355] Intel(R) Wireless WiFi driver for Linux, in-tree: [ 15.232072] Copyright(c) 2003-2013 Intel Corporation [ 15.234765] iwlwifi :02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 15.237689] iwlwifi :02:00.0: irq 44 for MSI/MSI-X [ 15.541269] iwlwifi :02:00.0: firmware: agent loaded iwlwifi-1000-5.ucode into memory [ 15.544207] iwlwifi :02:00.0: loaded firmware version 39.31.5.1 build 35138 op_mode iwldvm [ 15.923414] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 15.926155] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 15.928851] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 15.931506] iwlwifi :02:00.0: CONFIG_IWLWIFI_P2P enabled [ 15.934146] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [ 15.936887] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [ 15.996985] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 16.020899] media: Linux media interface: v0.10 [ 16.033770] Linux
Bug#714991: libqtcore4: New dependency qtcore4-l10n not recognized by i386 arch package, preventing multiarch upgrade
Package: libqtcore4 Version: 4:4.8.5+dfsg-1 Severity: important Dear Maintainer, The recent update for libqtcore4 (version 4:4.8.5+dfsg-1) brings in a new dependency on qtcore4-l10n, which appears to be an arch-independent package, however, on multiarch systems, the i386 package does not recognize the availability of qtcore4-l10n, and therefore cannot be upgraded. This in turn prevents the amd64 package from being updated (unless one is willing to remove the i386 packages and any packages depending on them, ie. Skype), as well as preventing all of the packages depending on libqtcore4 from being updated. I hope you can find a way to remedy this situation, for the time being I will have to hold off on these updates, since I would prefer to keep Skype installed. P.S. A similar issue occurred when the Pango libraries underwent a packaging change and the original libpango1.0-0 package was made into an arch-independent transitional package, ultimately this did not work (the i386 packages would not recognize that the arch-independent transitional package existed and was installed) and the package was split into separate arch-specific packages again. This may, unfortunately, be the route you have to take, unless someone can figure out why i386 packages seem to be unable to recognize arch- independent dependencies on multiarch systems. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-rc7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709846: synaptic: Download status column vanishes when downloads begin
I finally managed to get a window where the download status column is visible before any files have started downloading, I'm attaching a screenshot of this so you can compare it with the one in my previous message and see exactly what I'm talking about. Hopefully once you can see the problem in question you might be able to target it and possibly fix it, assuming it is related to Synaptic and not a GTK3 issue of some sort preventing that particular widget from being drawn (and somehow taking the whole column out with it). attachment: Status column visible before downloads start.png
Bug#712554: gnome-keyring: package dependency libgcr-base-3-1 does not exist
Package: gnome-keyring Version: 3.8.2-2+a1 Severity: important Tags: lfs Dear Maintainer, I think there may be a mistake with gnome-keyring's dependency on the non- existent package libgcr-base-3-1. There is a package libgcr-3-1 that may be the correct dependency. I've altered the dependency locally on the version prior to this recent update as well as to the recent update and everything appears to work correctly. I hope you can get this straightened out, because with the dependency as it is, these newer versions cannot be installed. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-rc5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-keyring depends on: ii dbus-x11 1.7.4-1 ii dconf-gsettings-backend [gsettings-backend] 0.16.0-4 ii gcr 3.8.2-1 ii libc62.17-5 ii libcap-ng0 0.7.3-1+b1 ii libcap2-bin 1:2.22-1.2 ii libdbus-1-3 1.7.4-1 ii libgck-1-0 3.8.2-1 ii libgcr-3-1 3.8.2-1 ii libgcrypt11 1.5.2-2 ii libglib2.0-0 2.36.3-1 ii libgtk-3-0 3.8.2-2 ii p11-kit 0.18.3-2 Versions of packages gnome-keyring recommends: ii libpam-gnome-keyring 3.8.2-2 gnome-keyring suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710212: Regarding: Bug#710212: fails to install
(Replying for the bug tracker.) On 09/06/13 11:21 AM, Geert Stappers wrote: Op 2013-05-30 om 02:54 schreef Alex Vanderpol: On 30/05/13 12:55 AM, Geert Stappers wrote: For what it is worth: this from syslinux (3:6.00~pre4+dfsg-10) * Correcting typo in extlinux debhelper install file (Closes: #710306). Please try the new version and report back. Installed it just now (as it finally showed up in the repos), seems to be working fine now, thanks! Thanks for the private reply. Good to know that extlinux again works. Is it okay for you that bugreport #710212 also gets your feedback? If 'yes': just reply to this E-mail, it has Reply-To set to the BTS. Cheers Geert Stappers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710847: libreoffice-core: needs update to use libharfbuzz0a instead of libharfbuzz0
Package: libreoffice-core Version: 1:4.1.0~beta1-2 Severity: important Dear Maintainer, Recent updates in SID/Unstable have replaced libharfbuzz0 with a newer package now named libharfbuzz0a. Libreoffice's dependency needs to be updated to use this new package, otherwise it cannot be installed. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libreoffice-core depends on: ii fontconfig 2.9.0-7.1 ii fonts-opensymbol2:102.3+LibO4.1.0~beta1-2 ii libatk1.0-0 2.8.0-2 ii libboost-date-time1.53.01.53.0-5 ii libc6 2.17-3 ii libcairo2 1.12.14-4 ii libclucene-contribs12.3.3.4-2 ii libclucene-core12.3.3.4-2 ii libcmis-0.3-3 0.3.1-3 ii libcups21.6.2-7 ii libcurl3-gnutls 7.30.0-2 ii libdbus-1-3 1.7.2-1 ii libdbus-glib-1-20.100.2-1 ii libexpat1 2.1.0-3 ii libexttextcat-2.0-0 3.4.0-4 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgcc1 1:4.8.0-9 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-02.36.1-2build1 ii libgraphite2-3 1.2.2-1 ii libgstreamer-plugins-base1.0-0 1.0.7-1 ii libgstreamer1.0-0 1.0.7-1 ii libgtk2.0-0 2.24.18-1 pn libharfbuzz0none ii libhunspell-1.3-0 1.3.2-4 ii libhyphen0 2.8.6-2 ii libice6 2:1.0.8-2 ii libicu484.8.1.1-12 ii libjpeg88d-1 ii liblangtag1 0.5.1-1 ii liblcms2-2 2.2+git20110628-2.2 ii libldap-2.4-2 2.4.31-1+nmu2 ii libmythes-1.2-0 2:1.2.2-1 ii libneon27-gnutls0.29.6-3 ii libnspr42:4.9.6-1 ii libnspr4-0d 2:4.9.6-1 ii libnss3 2:3.15~b4-1 ii libnss3-1d 2:3.15~b4-1 ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpangoft2-1.0-0 1.32.5-5+b1 ii libpng12-0 1.2.49-4 ii librdf0 1.0.16-1 ii libreoffice-common 1:4.1.0~beta1-2 ii libsm6 2:1.2.1-2 ii libssl1.0.0 1.0.1e-3 ii libstdc++6 4.8.0-9 ii libx11-62:1.5.0-1+deb7u1 ii libxext62:1.3.1-2+deb7u1 ii libxinerama12:1.1.2-1+deb7u1 ii libxml2 2.9.0+dfsg1-4 ii libxrandr2 2:1.4.0-1 ii libxrender1 1:0.9.7-1+deb7u1 ii libxslt1.1 1.1.28-1 ii libxt6 1:1.1.3-1+deb7u1 ii uno-libs3 4.1.0~beta1-2 ii ure 4.1.0~beta1-2 ii zlib1g 1:1.2.8.dfsg-1 libreoffice-core recommends no packages. libreoffice-core suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710847: libreoffice-core: needs update to use libharfbuzz0a instead of libharfbuzz0
Oh, well, never mind me then... I can wait for a little while for the beta2 update. Just wanted to make sure you were aware, which apparently you already were. On 02/06/13 06:50 PM, Rene Engelhard wrote: severity 710847 serious tag 710847 + pending thanks Hi, On Sun, Jun 02, 2013 at 06:43:01PM -0400, Alex Vanderpol wrote: Recent updates in SID/Unstable have replaced libharfbuzz0 with a newer package now named libharfbuzz0a. Libreoffice's dependency needs to be updated to use this new package, otherwise it cannot be installed. I know. I followed that one closely. Will do with the beta2 upload next week. (Needs source changes which I submitted upstream) Can do a backport; but given beta2 is due next week and already in preparation in git... Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710591: libreoffice: Missing .desktop files for all LibreOffice programs.
Package: libreoffice Version: 1:4.1.0~beta1-2 Severity: important Dear Maintainer, As stated in the bug subject, the .desktop files for all of the LibreOffice applications are missing. As such, LibreOffice applications do not appear in the GNOME Shell overview, and I imagine this means they also won't show up in any menus that populate using the .desktop files in /usr/share/applications. This makes it somewhat difficult to easily find and launch LibreOffice or any of its applications. I hope this can be corrected without difficulty. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libreoffice depends on: ii fonts-dejavu2.33+svn2514-3 ii fonts-sil-gentium-basic 1.1-5 ii libreoffice-base1:4.1.0~beta1-2 ii libreoffice-calc1:4.1.0~beta1-2 ii libreoffice-core1:4.1.0~beta1-2 ii libreoffice-draw1:4.1.0~beta1-2 ii libreoffice-impress 1:4.1.0~beta1-2 ii libreoffice-java-common 1:4.1.0~beta1-2 ii libreoffice-math1:4.1.0~beta1-2 ii libreoffice-report-builder-bin 1:4.1.0~beta1-2 ii libreoffice-writer 1:4.1.0~beta1-2 ii python-uno 1:4.1.0~beta1-2 Versions of packages libreoffice recommends: ii libpaper-utils 1.1.24+nmu2 ii ttf-mscorefonts-installer 3.5 Versions of packages libreoffice suggests: pn cups-bsdnone pn gstreamer1.0-ffmpeg none ii gstreamer1.0-plugins-bad1.0.7-1 ii gstreamer1.0-plugins-base 1.0.7-1 ii gstreamer1.0-plugins-good 1.0.7-1 ii gstreamer1.0-plugins-ugly 1.0.7-1 pn hunspell-dictionary none pn hyphen-hyphenation-patterns none ii icedove 17.0.5-2 ii iceweasel 23.0~a2+20130524004018-1 ii imagemagick 8:6.8.5.6-2 ii libgl1-mesa-glx [libgl1]8.0.5-6 ii libreoffice-gnome 1:4.1.0~beta1-2 pn libreoffice-grammarchecknone pn libreoffice-help-4.1none pn libreoffice-l10n-4.1none pn libreoffice-officebean none ii libsane 1.0.23-0.1~experimental1 ii libxrender1 1:0.9.7-1+deb7u1 ii myspell-en-us [myspell-dictionary] 1:3.3.0-4 pn mythes-thesaurusnone pn openclipart-libreoffice none ii openjdk-7-jre [java5-runtime] 7u21-2.3.9-5 pn pstoeditnone ii unixodbc2.2.14p2-5 Versions of packages libreoffice-core depends on: ii fontconfig 2.9.0-7.1 ii fonts-opensymbol2:102.3+LibO4.1.0~beta1-2 ii libatk1.0-0 2.8.0-2 ii libboost-date-time1.53.01.53.0-5 ii libc6 2.17-3 ii libcairo2 1.12.14-4 ii libclucene-contribs12.3.3.4-2 ii libclucene-core12.3.3.4-2 ii libcmis-0.3-3 0.3.1-3 ii libcups21.6.2-7 ii libcurl3-gnutls 7.30.0-2 ii libdbus-1-3 1.7.2-1 ii libdbus-glib-1-20.100.2-1 ii libexpat1 2.1.0-3 ii libexttextcat-2.0-0 3.4.0-4 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgcc1 1:4.8.0-9 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-02.36.1-2build1 ii libgraphite2-3 1.2.2-1 ii libgstreamer-plugins-base1.0-0 1.0.7-1 ii libgstreamer1.0-0 1.0.7-1 ii libgtk2.0-0 2.24.18-1 ii libharfbuzz00.9.17-4 ii libhunspell-1.3-0 1.3.2-4 ii libhyphen0 2.8.6-2 ii libice6 2:1.0.8-2 ii libicu484.8.1.1-12 ii libjpeg88d-1 ii liblangtag1 0.5.1-1 ii liblcms2-2 2.2+git20110628-2.2 ii libldap-2.4-2 2.4.31-1+nmu2 ii libmythes-1.2-0 2:1.2.2-1 ii libneon27-gnutls0.29.6-3 ii libnspr42:4.9.6-1 ii libnspr4-0d 2:4.9.6-1 ii libnss3 2:3.15~b4-1 ii libnss3-1d 2:3.15~b4-1 ii libpango-1.0-0 1.32.5-5 ii libpangocairo-1.0-0 1.32.5-5 ii libpangoft2-1.0-0 1.32.5-5 ii libpng12-0 1.2.49-4 ii librdf0
Bug#710591: libreoffice: Missing .desktop files for all LibreOffice programs.
On 13-06-01 05:25 AM, Rene Engelhard wrote: Hi, On Sat, Jun 01, 2013 at 03:20:23AM -0400, Alex Vanderpol wrote: As stated in the bug subject, the .desktop files for all of the LibreOffice applications are missing. Sorry, but this is not true completely. $ for i in *beta1-2*deb; do dpkg --contents $i | grep \.desktop$; done -rw-r--r-- root/root 1537 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/base.desktop -rw-r--r-- root/root 2519 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/calc.desktop -rw-r--r-- root/root 459 2013-05-29 02:19 ./usr/lib/libreoffice/share/xdg/xsltfilter.desktop -rw-r--r-- root/root 1429 2013-05-29 02:19 ./usr/lib/libreoffice/share/xdg/startcenter.desktop lrwxrwxrwx root/root 0 2013-05-29 03:08 ./usr/share/applications/libreoffice-startcenter.desktop - /usr/lib/libreoffice/share/xdg/startcenter.desktop -rw-r--r-- root/root 1720 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/draw.desktop -rw-r--r-- root/root 1030 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/qstart.desktop -rw-r--r-- root/root 2234 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/impress.desktop -rw-r--r-- root/root 208 2013-05-29 02:30 ./usr/share/templates/soffice.ods.desktop -rw-r--r-- root/root 204 2013-05-29 02:30 ./usr/share/templates/soffice.odg.desktop -rw-r--r-- root/root 218 2013-05-29 02:30 ./usr/share/templates/soffice.odp.desktop -rw-r--r-- root/root 207 2013-05-29 02:30 ./usr/share/templates/soffice.odt.desktop -rw-r--r-- root/root 1585 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/math.desktop -rw-r--r-- root/root 2423 2013-05-29 02:31 ./usr/lib/libreoffice/share/xdg/writer.desktop So yes the symlink in /usr/share/applications - except the startcenter (aka. LibreOffice) - are missing... But startcenter is there ... I wasn't aware the .desktop files were stored elsewhere and only symlinked in /usr/share/applications, that's my bad. As such, LibreOffice applications do not appear in the GNOME Shell overview, and I imagine this means they also won't show up in any menus that populate using the .desktop files in /usr/share/applications. ... and that one should appear in GNOME shell and those menus. It doesn't appear to by default (it was disabled in Alacarte), but enabling it to show does make it show up. This makes it somewhat difficult to easily find and launch LibreOffice or any Wrong :) Except that by default the LibreOffice launcher is hidden, unless *that* is a bug, or an old config setting on my system. of its applications. true (you need to go via the startcenter) But yeah, will look why the other symlinks went away... Regards, Rene Heh, thanks. I should probably have looked into things a little further myself before assuming this was a bug, but it wasn't functioning how it used to and there seemed to be no explanation as to why that happened, so naturally I assumed it was a bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710212: fails to install
Package: extlinux Version: 3:6.00~pre4+dfsg-9 Followup-For: Bug #710212 Dear Maintainer, Latest version (3:6.00~pre4+dfsg-9) still fails to install. Terminal output is as follows: P: Checking for EXTLINUX directory... not found. P: Creating EXTLINUX directory...mkdir: cannot create directory ‘’: No such file or directory dpkg: error processing extlinux (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: extlinux -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages extlinux depends on: ii debconf [debconf-2.0] 1.5.50 ii libc6 2.17-3 Versions of packages extlinux recommends: ii os-prober1.61 ii syslinux-common 3:6.00~pre4+dfsg-9 extlinux suggests no packages. -- debconf information: extlinux/install: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710212: fails to install
Attempting to narrow down the cause of this bug led me to an interesting
discovery.
There's a rather large difference between the /usr/sbin/extlinux-update
files in 3:6.00~pre4+dfsg-7 and 3:6.00~pre4+dfsg-8 that appears (in
part, at least) to be related to this issue.
This difference also exists in 3:6.00~pre4+dfsg-9.
Here's the diff output from 3:6.00~pre4+dfsg-7 to 3:6.00~pre4+dfsg-8 and
3:6.00~pre4+dfsg-9:
12,34d11
_EXTLINUX_DIRECTORY=/boot/extlinux
Update ()
{
# Upate target file using source content
_TARGET=${1}
_SOURCE=${2}
_TMPFILE=${_TARGET}.tmp
rm -f ${_TMPFILE}
echo ${_SOURCE} ${_TMPFILE}
if [ -e ${_TARGET} ] cmp -s ${_TARGET} ${_TMPFILE}
then
rm -f ${_TMPFILE}
else
# FIXME: should use fsync here
echo P: Updating ${_TARGET}...
mv -f ${_TMPFILE} ${_TARGET}
fi
}
60,145c37
# Checking extlinux directory
echo -n P: Checking for EXTLINUX directory...
# Creating extlinux directory
if [ ! -e ${_EXTLINUX_DIRECTORY} ]
then
echo not found.
echo -n P: Creating EXTLINUX directory...
mkdir -p ${_EXTLINUX_DIRECTORY}
echo done: ${_EXTLINUX_DIRECTORY}
else
echo found.
fi
# Setting defaults
EXTLINUX_ALTERNATIVES=${EXTLINUX_ALTERNATIVES:-default recovery}
EXTLINUX_DEFAULT=${EXTLINUX_DEFAULT:-l0}
EXTLINUX_ENTRIES=${EXTLINUX_ENTRIES:-all}
EXTLINUX_MEMDISK=${EXTLINUX_MEMDISK:-true}
EXTLINUX_MEMDISK_DIRECTORY=${EXTLINXU_MEMDISK_DIRECTORY:-/boot}
if [ -z ${EXTLINUX_MENU_LABEL} ]
then
if [ -x $(which lsb_release 2/dev/null) ]
then
EXTLINUX_MENU_LABEL=$(lsb_release -i -s) GNU/Linux, kernel
else
EXTLINUX_MENU_LABEL=Debian GNU/Linux, kernel
fi
fi
EXTLINUX_OS_PROBER=${EXTLINUX_OS_PROBER:-true}
EXTLINUX_PARAMETERS=${EXTLINUX_PARAMETERS:-ro quiet}
if [ -z ${EXTLINUX_ROOT} ]
then
# Find root partition
while read _LINE
do
read _FS_SPEC _FS_FILE _FS_VFSTYPE _FS_MNTOPS _FS_FREQ _FS_PASSNO EOF
${_LINE}
EOF
if [ ${_FS_SPEC} != # ] [ ${_FS_FILE} = / ]
then
EXTLINUX_ROOT=root=${_FS_SPEC}
break
fi
done /etc/fstab
fi
if [ -z ${EXTLINUX_THEME} ]
then
# Using default menu if available
if [ -e /usr/share/EXTLINUX/themes/default ]
then
EXTLINUX_THEME=default
else
EXTLINUX_THEME=none
fi
fi
EXTLINUX_TIMEOUT=${EXTLINUX_TIMEOUT:-50}
# Writing new default file
cat /etc/default/extlinux EOF
## /etc/default/extlinux - configuration file for extlinux-update(8)
EXTLINUX_UPDATE=${EXTLINUX_UPDATE}
EXTLINUX_ALTERNATIVES=${EXTLINUX_ALTERNATIVES}
EXTLINUX_DEFAULT=${EXTLINUX_DEFAULT}
EXTLINUX_ENTRIES=${EXTLINUX_ENTRIES}
EXTLINUX_MEMDISK=${EXTLINUX_MEMDISK}
EXTLINUX_MEMDISK_DIRECTORY=${EXTLINUX_MEMDISK_DIRECTORY}
EXTLINUX_MENU_LABEL=${EXTLINUX_MENU_LABEL}
EXTLINUX_OS_PROBER=${EXTLINUX_OS_PROBER}
EXTLINUX_PARAMETERS=$(echo -n ${EXTLINUX_PARAMETERS} | sed -e
's|\|\\\|g')
EXTLINUX_ROOT=${EXTLINUX_ROOT}
EXTLINUX_THEME=${EXTLINUX_THEME}
EXTLINUX_TIMEOUT=${EXTLINUX_TIMEOUT}
EOF
# Source /etc/extlinux.d scripts
---
# Running /etc/extlinux.d scripts
I hope this helps you fix this problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710075: libwebkitgtk-1.0-0: Recent libharfbuzz0 update makes Hotot unable to be launched
Package: libwebkitgtk-1.0-0 Version: 1.11.91-1 Severity: important Dear Maintainer, It would seem that a recent update to libharfbuzz0 (from 0.9.17-2 to 0.9.17-3) has rendered Hotot unable to be launched. The Traceback I get in the terminal when attempting to launch Hotot from there points to an undefined symbol that libwebkitgtk-1.0.so.0 seems to be looking for as the cause of the problem. Here is the Traceback: Traceback (most recent call last): File /usr/bin/hotot, line 13, in module from hotot import hotot File /usr/lib/python2.7/dist-packages/hotot/hotot.py, line 10, in module import view File /usr/lib/python2.7/dist-packages/hotot/view.py, line 4, in module import webkit File /usr/lib/pymodules/python2.7/webkit/__init__.py, line 21, in module import webkit ImportError: /usr/lib/libwebkitgtk-1.0.so.0: undefined symbol: hb_icu_get_unicode_funcs Based on the last line of the traceback, I suspect the issue ultimately lies with this package, and would probably be resolved with an appropriate update/fix applied to this package. For the time being I have downgraded libharfbuzz0 to the prior version that Hotot was able to launch with, and will hold it back until a later update to either this package or libharfbuzz0 which addresses this problem. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libwebkitgtk-1.0-0 depends on: ii libatk1.0-0 2.8.0-2 ii libc6 2.17-3 ii libcairo2 1.12.14-4 ii libdbus-1-3 1.7.2-1 ii libdbus-glib-1-20.100.2-1 ii libegl1-mesa [libegl1-x11] 8.0.5-6 ii libenchant1c2a 1.6.0-10 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgail18 2.24.18-1 ii libgcc1 1:4.8.0-7 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libgeoclue0 0.12.99-2 ii libgl1-mesa-glx [libgl1]8.0.5-6 ii libglib2.0-02.36.1-2build1 ii libgstreamer-plugins-base1.0-0 1.0.7-1 ii libgstreamer1.0-0 1.0.7-1 ii libgtk2.0-0 2.24.18-1 ii libharfbuzz00.9.17-2 ii libicu484.8.1.1-12 ii libjavascriptcoregtk-1.0-0 1.11.91-1 ii libjpeg88d-1 ii libpango1.0-0 1.32.5-5 ii libpng12-0 1.2.49-4 ii libsecret-1-0 0.15-2 ii libsoup2.4-12.42.2-3 ii libsqlite3-03.7.17-1 ii libstdc++6 4.8.0-7 ii libwebkitgtk-1.0-common 1.11.91-1 ii libwebp40.3.0-1 ii libx11-62:1.5.0-1+deb7u1 ii libxcomposite1 1:0.4.3-2 ii libxdamage1 1:1.1.3-2 ii libxfixes3 1:5.0-4+deb7u1 ii libxml2 2.9.0+dfsg1-4 ii libxrender1 1:0.9.7-1+deb7u1 ii libxslt1.1 1.1.28-1 ii libxt6 1:1.1.3-1+deb7u1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages libwebkitgtk-1.0-0 recommends: ii gstreamer1.0-libav 1.0.7-2 ii gstreamer1.0-plugins-bad 1.0.7-1 ii gstreamer1.0-plugins-base 1.0.7-1 ii gstreamer1.0-plugins-good 1.0.7-1 libwebkitgtk-1.0-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709845: update-alternatives: error: alternative path /usr/bin/compare-im6 doesn't exist
Package: imagemagick Version: 8:6.8.5.6-1 Severity: normal Dear Maintainer, As the bug subject hopefully indicates, the imagemagick post-installation script fails to complete due to a non-existent alternative path. This prevents anything dependent on imagemagick (eg. Prey) from being able to be installed due to imagemagick not being properly configured. Could this please be fixed? -- Package-specific info: ImageMagick program version --- animate: compare: convert: composite: conjure: display: identify: import: mogrify: montage: stream: -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imagemagick depends on: ii imagemagick-6.q16 8:6.8.5.6-1 imagemagick recommends no packages. imagemagick suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709845: update-alternatives: error: alternative path /usr/bin/compare-im6 doesn't exist
Checking into things a little further... The binaries are completely missing from this recent package update, no wonder the script fails. There appear to be a few other files missing as well that are linked to the missing binaries. (Appears to be some icons and the imagemagick display desktop file.) Is this intentional, or is this a mistake in the package build that needs to be fixed? Hopefully you can get this worked out and get a working update uploaded soon. In the mean time I've downgraded to the previous version and will hold on that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709846: synaptic: Download status column vanishes when downloads begin
Package: synaptic Version: 0.80.1 Severity: minor Dear Maintainer, I suspect recent GTK3 updates may be the cause of this issue. After the recent updates, when viewing the download progress of individual files, the Status column where the progress bars for the individual files would appear vanishes the moment the first file begins downloading, however it can be seen briefly during the short span of time between applying changes (or reloading the package lists) and when the first file actually begins downloading. This happens regardless of what GTK3 theme I use, including the default (Adwaita) theme. I'm not sure if this is a bug specifically in Synaptic or if it affects any GTK3 application that draws progress bars in columns, as I don't know of any other GTK3 applications that do such a thing to check if this problem affects them as well. (The only application I'm aware of that does this on my system uses GTK2 and still works fine.) The GTK3 widget factory application in gtk-3-examples does not appear to demo this particular widget. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages synaptic depends on: ii hicolor-icon-theme 0.12-1 ii libapt-inst1.5 0.9.8.1 ii libapt-pkg4.12 0.9.8.1 ii libatk1.0-0 2.8.0-2 ii libc6 2.17-3 ii libcairo-gobject2 1.12.14-4 ii libcairo2 1.12.14-4 ii libept1.4.121.0.9 ii libgcc1 1:4.8.0-7 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-02.36.1-2build1 ii libgtk-3-0 3.8.2-1 ii libpango1.0-0 1.32.5-5 ii libstdc++6 4.8.0-7 ii libvte-2.90-9 1:0.34.5-1 ii libx11-62:1.5.0-1+deb7u1 ii libxapian22 1.2.15-1 ii libxext62:1.3.1-2+deb7u1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages synaptic recommends: ii gksu 2.0.2-6 ii libgtk2-perl 2:1.247-2 ii policykit-10.110-2 ii rarian-compat 0.8.1-5 Versions of packages synaptic suggests: ii apt-xapian-index 0.45 ii deborphan1.7.28.8 pn dwww none ii menu 2.1.46 ii software-properties-gtk 0.92.17 pn tasksel none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708047: gnome-screensaver: dependency on libgnome-desktop-3-4 does not allow removal of the now-obsolete package
Package: gnome-screensaver Version: 3.6.0-1 Severity: normal Dear Maintainer, gnome-screensaver currently depends on libgnome-desktop-3-4, which has recently become obsolete. This dependency should probably be changed to libgnome- desktop-3-7. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-screensaver depends on: ii dbus-x11 1.7.2-1 ii dpkg 1.16.10 ii gnome-icon-theme 3.7.91-1 ii gnome-session-bin 3.7.92-1 ii gsettings-desktop-schemas 3.8.0-1 ii libc6 2.17-1 ii libcairo2 1.12.14-4 ii libdbus-1-31.7.2-1 ii libdbus-glib-1-2 0.100.2-1 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-0 2.36.1-2 ii libgnome-desktop-3-4 3.6.1-1 ii libgnomekbd7 3.4.0.2-1 ii libgtk-3-0 3.8.0-1 ii libpam0g 1.1.3-9 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxklavier16 5.2.1-1 ii libxxf86vm11:1.1.2-1 Versions of packages gnome-screensaver recommends: ii gnome-power-manager 3.6.0-1 ii libpam-gnome-keyring 3.8.0-1 gnome-screensaver suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708047: gnome-screensaver: dependency on libgnome-desktop-3-4 does not allow removal of the now-obsolete package
And I realize now, after submitting that report, that gnome-screensaver is still only version 3.6, so its dependency kind of makes sense... I suspect this means gnome-screensaver needs to be updated in general, and an updated version should hopefully be using libgnome-desktop-3-7, given that libgnome-desktop-3-4 has become obsolete. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708054: brasero: dependency on libtracker-sparql-0.14-0 does not allow removal of now-obsolete package
Package: brasero Version: 3.4.1-4 Severity: normal Tags: lfs Dear Maintainer, brasero currently depends on libtracker-sparql-0.14-0, which has recently become obsolete. As brasero is still currently at version 3.4, while GNOME in Experimental is at version 3.8, it might be a good idea to release an update for brasero, with an updated dependency on libtracker-sparql-0.16-0, so the now-obsolete libtracker-0.14-0 can be removed. -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages brasero depends on: ii brasero-common 3.4.1-4 ii gnome-icon-theme 3.7.91-1 ii gstreamer0.10-plugins-base 0.10.36-1.1 ii gvfs 1.16.0-1 ii libatk1.0-0 2.8.0-2 ii libbrasero-media3-1 3.4.1-4 ii libc62.17-1 ii libcairo-gobject21.12.14-4 ii libcairo21.12.14-4 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-0 2.36.1-2 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.2 ii libgtk-3-0 3.8.0-1 ii libice6 2:1.0.8-2 ii libnautilus-extension1a 3.8.0-1 ii libpango1.0-01.32.5-4 ii libsm6 2:1.2.1-2 ii libtotem-plparser17 3.4.4-1 ii libtracker-sparql-0.14-0 0.14.5-1 ii libxml2 2.9.0+dfsg1-4 Versions of packages brasero recommends: ii yelp 3.6.1-1 Versions of packages brasero suggests: ii libdvdcss2 1.2.13-dmo1 pn tracker none pn vcdimager none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705387: alacarte: cannot import GError from gi._glib
Package: alacarte Version: 3.5.3-1 Severity: important Dear Maintainer, Recent updates have made Alacarte unusable due to an import error from util.py. Here is the terminal output when I try to launch it: Traceback (most recent call last): File /usr/bin/alacarte, line 23, in module from Alacarte.MainWindow import MainWindow File /usr/share/alacarte/Alacarte/MainWindow.py, line 32, in module from Alacarte.MenuEditor import MenuEditor File /usr/share/alacarte/Alacarte/MenuEditor.py, line 23, in module from Alacarte import util File /usr/share/alacarte/Alacarte/util.py, line 25, in module from gi._glib import GError ImportError: cannot import name GError I hope this can be rectified soon! -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages alacarte depends on: ii gir1.2-gdkpixbuf-2.0 2.28.0-1 ii gir1.2-glib-2.0 1.36.0-1 ii gir1.2-gmenu-3.0 3.7.90-1 ii gir1.2-gtk-3.03.8.0-1 ii python2.7.3-13 ii python-gi 3.8.0-2 Versions of packages alacarte recommends: pn gnome-panel none alacarte suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705390: gnome-calculator: gnome-applications.menu (from /etc/sdg/menus) looking for gnome-calculator.desktop
Package: gnome-calculator Version: 3.8.0-1 Severity: important Dear Maintainer, After much frustration I finally discovered why GNOME's Calculator is not showing up in the GNOME applications menu. The applications menu file is looking for a differently named desktop file than is currently being shipped. The package currently ships gcalctool.desktop (the old name from the old gcalctool package, before it was renamed). The menu file is looking for gnome- calculator.desktop (named such after the new package providing the GNOME Calculator program). Could you please correct this? -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-calculator depends on: ii dconf-gsettings-backend [gsettings-backend] 0.16.0-1 ii libatk1.0-0 2.8.0-1 ii libc62.17-0experimental2 ii libglib2.0-0 2.36.0-2 ii libgtk-3-0 3.8.0-1 ii libpango1.0-01.32.5-4 ii libxml2 2.9.0+dfsg1-4 Versions of packages gnome-calculator recommends: ii gnome-icon-theme 3.7.91-1 ii gvfs 1.16.0-1 ii yelp 3.6.1-1 gnome-calculator suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705390: Ack, typo'd the subject, that should be /etc/xdg/menus
Just correcting the folder name, I mistyped it as sdg instead of xdg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705080: libpango1.0-0: version conflict between i386 package and all arch package renders both un-updateable
Actually, this was an update from version 1.32.5-1, I had downgraded back to it after the issues I had with missing modules (which it turns out are built-in now) and the issue with i386 arch packages dependent on libpango1.0-0 not recognizing the all arch package on my amd64 system. However, since the only arch that was updated to 1.32.5-4 was the i386 arch, the amd64 arch packages were all still version 1.32.5-3, thus the conflict. I suppose I should have just waited, it appears the amd64 arch packages were just lagging behind the i386 arch packages, and had I been more patient, I would not have had this issue. I'm sorry for bothering you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705188: gedit: needs update to use libgtksourceview-3.0-1
Package: gedit Version: 3.8.0-1 Severity: wishlist Dear Maintainer, gedit package needs rebuild to use libgtksourceview-3.0-1 instead of libgtksourceview-3.0-0, as a recent update has replaced the old package. -- Package-specific info: Active plugins: - 'spell' - 'filebrowser' - 'docinfo' - 'time' - 'modelines' No plugin installed in $HOME. Module versions: - glib 2.36.0 - gtk+ 3.8.0 - gtksourceview 3.8.0 - pygobject - enchant 1.6.0 - iso-codes 3.41 -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gedit depends on: ii gedit-common 3.8.0-1 ii gir1.2-gtk-3.0 3.8.0-1 ii gir1.2-gtksource-3.0 3.8.0-1 ii gir1.2-peas-1.01.8.0-1 ii gsettings-desktop-schemas 3.8.0-1 ii iso-codes 3.41-1 ii libatk1.0-02.8.0-1 ii libc6 2.17-0experimental2 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libenchant1c2a 1.6.0-9 ii libgdk-pixbuf2.0-0 2.28.0-1 ii libgirepository-1.0-1 1.36.0-1 ii libglib2.0-0 2.36.0-2 ii libgtk-3-0 3.8.0-1 ii libgtksourceview-3.0-1 3.8.0-1 ii libpango-1.0-0 1.32.5-4 ii libpangocairo-1.0-01.32.5-4 ii libpeas-1.0-0 1.8.0-1 ii libx11-6 2:1.5.0-1 ii libxml22.9.0+dfsg1-4 ii python-gi-cairo3.8.0-2 ii python33.2.3-6 ii python3-gi 3.8.0-2 Versions of packages gedit recommends: ii yelp3.6.1-1 ii zenity 3.4.0-2 Versions of packages gedit suggests: pn gedit-plugins none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705189: gnome-sushi: needs update to use libgtksourceview-3.0-1
Package: gnome-sushi Version: 3.8.0-1 Severity: wishlist Dear Maintainer, gnome-sushi package needs a rebuild to use libgtksourceview-3.0-1 instead of libgtksourceview-3.0-0, as a recent update has replaced the old package. NOTE: I have already built and installed a version that uses the new package on my system, however the official repository package needs to be rebuilt. -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-sushi depends on: ii dconf-gsettings-backend [gsettings-backend] 0.16.0-1 ii gir1.2-clutter-1.0 1.14.0-1 ii gir1.2-clutter-gst-2.0 2.0.2-1 ii gir1.2-evince-3.03.8.0-1 ii gir1.2-gdkpixbuf-2.0 2.28.0-1 ii gir1.2-gst-plugins-base-1.0 1.0.6-1 ii gir1.2-gtk-3.0 3.8.0-1 ii gir1.2-gtkclutter-1.01.4.4-2 ii gir1.2-gtksource-3.0 3.8.0-1 ii gstreamer1.0-plugins-good1.0.6-1 ii libatk1.0-0 2.8.0-1 ii libc62.17-0experimental2 ii libcairo-gobject21.12.2-3 ii libcairo21.12.2-3 ii libclutter-1.0-0 1.14.0-1 ii libclutter-gst-2.0-0 2.0.2-1 ii libclutter-gtk-1.0-0 1.4.4-2 ii libcogl-pango12 1.14.0-1 ii libcogl121.14.0-1 ii libegl1-mesa [libegl1-x11] 8.0.5-4 ii libevdocument3-4 3.8.0-1 ii libevview3-3 3.8.0-1 ii libfreetype6 2.4.9-1.1 ii libgdk-pixbuf2.0-0 2.28.0-1 ii libgirepository-1.0-11.36.0-1 ii libgjs0c [libgjs0-libmozjs185-1.0] 1.36.0-1 ii libglib2.0-0 2.36.0-2 ii libgstreamer-plugins-base1.0-0 1.0.6-1 ii libgstreamer1.0-01.0.6-1 ii libgtk-3-0 3.8.0-1 ii libgtksourceview-3.0-1 3.8.0-1 ii libjavascriptcoregtk-3.0-0 1.11.91-1 ii libjson-glib-1.0-0 0.14.2-1 ii libmusicbrainz5-05.0.1-2 ii libpango-1.0-0 1.32.5-4 ii libpangocairo-1.0-0 1.32.5-4 ii libsoup2.4-1 2.42.0-1 ii libwebkitgtk-3.0-0 1.11.91-1 ii libx11-6 2:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxdamage1 1:1.1.3-2 ii libxext6 2:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.1-1 ii libxrandr2 2:1.4.0-1 ii nautilus 3.8.0-1 gnome-sushi recommends no packages. Versions of packages gnome-sushi suggests: ii gstreamer1.0-libav 1.0.6-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705188: gedit: needs update to use libgtksourceview-3.0-1
I should also add I've already built and installed a version of the package locally that uses the new package (libgtksourceview-3.0-1), however the official repository package needs to be rebuilt. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705080: libpango1.0-0: version conflict between i386 package and all arch package renders both un-updateable
Package: libpango1.0-0
Severity: important
Dear Maintainer,
Unfortunately, the latest update to libpango1.0-0 did not end up fixing the
issue I was having previously, and creates a new problem on top of that as now
the all arch package and the i386 package are no longer equivalent versions
and therefore cannot be co-installed. As such, all of the new packages that the
all arch is supposed to be a transitional package for are also no longer at
matching versions in amd64 and i386, making it impossible to co-install them.
This is the output from Aptitude when trying to update libpango1.0-0 (for all
arch, on an amd64 system):
The following NEW packages will be installed:
libpango-1.0-0{ab} libpango-1.0-0:i386{ab} libpangocairo-1.0-0{ab}
libpangocairo-1.0-0:i386{ab} libpangoft2-1.0-0{ab} libpangoft2-1.0-0:i386{ab}
libpangox-1.0-0:i386{a} libpangoxft-1.0-0{ab} libpangoxft-1.0-0:i386{ab}
The following packages will be upgraded:
libpango1.0-0{b} libpango1.0-0:i386{b}
2 packages upgraded, 9 newly installed, 0 to remove and 21 not upgraded.
Need to get 1,940 kB of archives. After unpacking 1,578 kB will be used.
The following packages have unmet dependencies:
libpangoxft-1.0-0 : Breaks: libpangoxft-1.0-0:i386 (!= 1.32.5-3) but 1.32.5-4
is to be installed.
libpangoxft-1.0-0:i386 : Breaks: libpangoxft-1.0-0 (!= 1.32.5-4) but 1.32.5-3
is to be installed.
libpango1.0-dev : Depends: libpango1.0-0 (= 1.32.5-1) but 1.32.5-3 is to be
installed.
libpango-1.0-0 : Breaks: libpango-1.0-0:i386 (!= 1.32.5-3) but 1.32.5-4 is to
be installed.
libpango-1.0-0:i386 : Breaks: libpango-1.0-0 (!= 1.32.5-4) but 1.32.5-3 is to
be installed.
libpangocairo-1.0-0 : Breaks: libpangocairo-1.0-0:i386 (!= 1.32.5-3) but
1.32.5-4 is to be installed.
libpangocairo-1.0-0:i386 : Breaks: libpangocairo-1.0-0 (!= 1.32.5-4) but
1.32.5-3 is to be installed.
libpangoft2-1.0-0 : Breaks: libpangoft2-1.0-0:i386 (!= 1.32.5-3) but 1.32.5-4
is to be installed.
libpangoft2-1.0-0:i386 : Breaks: libpangoft2-1.0-0 (!= 1.32.5-4) but 1.32.5-3
is to be installed.
libpango1.0-0 : Conflicts: libpango1.0-0:i386 but 1.32.5-4 is to be installed.
libpango1.0-0:i386 : Breaks: libpango1.0-0 (!= 1.32.5-4) but 1.32.5-3 is to be
installed.
The output from Aptitude is similar if I try to update libpango1.0-0:i386.
I don't understand why the i386 packages on my multiarch system aren't properly
recognizing the all arch transitional package as being installed and
insisting on trying to install the package from the i386 arch. I will have to
try to investigate this further and see if I can't figure out why this is not
working as it should be.
-- System Information:
Debian Release: 7.0
APT prefers experimental
APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704872: libpango1.0-0: latest version no longer supplies modules, breaks initramfs with Plymouth, often pops up warnings
I probably should have mentioned I applied a patch for Plymouth that updated the hook to work with the newer versions of Pango (at least, the ones that still supplied separate modules). I don't think the patch was done properly though as it relies on pango-querymodules from the development package to find the modules, something I don't believe should be necessary in a normal setup, but at least it worked. The patch doesn't seem to work with the modules built-in though, so a proper fix is definitely in order. At any rate, thanks for the information. For the time being I'll continue using the previous version (since it seems to work best for now) and keep an eye out for an update that will hopefully fix that other problem I seem to be having... (Silly multiarch, y u no like all arch libpango1.0-0 package for i386 on amd64 system?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704872: libpango1.0-0: latest version no longer supplies modules, breaks initramfs with Plymouth, often pops up warnings
Package: libpango1.0-0 Version: 1.32.5-3 Severity: important Dear Maintainer, The latest version of Pango appears to be fairly problematic, first with i386 packages not recognizing the transitional package for all architectures (already filed a separate bug about that), and now I discover that the module files that used to be shipped with the older version no longer exist, breaking initramfs with Plymouth (meaning no new kernel installs or upgrades) and throwing up warnings for anything else looking for them. I am currently downgrading to the previous version until these issues are sorted out. -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpango1.0-0 depends on: ii libpango-1.0-0 1.32.5-3 ii libpangocairo-1.0-0 1.32.5-3 ii libpangoft2-1.0-01.32.5-3 ii libpangoxft-1.0-01.32.5-3 libpango1.0-0 recommends no packages. libpango1.0-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704795: libpango1.0-0: i386 packages do not recognize new all arch package on multiarch, want older i386 specific package installed
Package: libpango1.0-0 Version: 1.32.5-3 Severity: normal Dear Maintainer, A recent upgrade of Pango turned the libpango1.0-0 package into a transitional package for all architectures, however on my amd64 arch system with i386 as a foreign arch, i386 packages depending on libpango1.0-0 do not recognize the newer all arch transitional package and try to pull in the older i386-specific package instead, which causes conflicts and ultimately means those packages cannot be installed. I noticed this with the i386 arch versions of libgtk2.0-0 and other related packages necessary to allow my 32-bit applications to be themed using GTK, and have, for the time being, reinstalled those packages locally with the libpango1.0-0 dependency removed. I don't know if this is necessarily a bug with libpango1.0-0 or if it's a bug pertaining to how multiarch works, so if this bug report is misdirected, please direct it in the appropriate direction. If you're aware of this issue and know how to fix it properly so i386 packages will see the all arch transitional package properly, please inform me, the workaround I have in place works but I would prefer a more permanent solution. -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpango1.0-0 depends on: ii libpango-1.0-0 1.32.5-3 ii libpangocairo-1.0-0 1.32.5-3 ii libpangoft2-1.0-01.32.5-3 ii libpangoxft-1.0-01.32.5-3 libpango1.0-0 recommends no packages. libpango1.0-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704423: systemd: gdm does not start, user sessions have multiple issues, root session works normally
Package: systemd Version: 44-11 Severity: grave Justification: renders package unusable Dear Maintainer, ***I'm marking this as grave because it causes some fairly serious usability issues for me, if you feel this status is incorrect please feel free to change it.*** As you might know, much of GNOME 3.8 has landed in Experimental recently, certainly enough to run a GNOME 3.8 environment at least. GNOME 3.8, or, more specifically, gnome-settings-daemon 3.8, depends on systemd for a number of things, most notably the power manager plugin (requires systemd-logind to be running), leaving me without a power status indicator in GNOME Shell when using sysvinit. As I am operating on a laptop, having this indicator is most definitely desired, so I decided to switch my init system to systemd. This is where things go wrong. Firstly, after the initial boot phase is complete, when the desktop manager (GDM) is supposed to start, it doesn't. Xorg appears to start fine, and I get the busy cursor for a short while as the system seems to be loading, then the cursor changes to the normal pointer and nothing further happens. So I drop to a tty, and log in to my personal account. That's when I get these two messages: -su: /dev/cgroup/cpu/user/2866/tasks: No such file or directory -su: /dev/cgroup/cpu/user/2866/notify_on_release: No such file or directory Already this does not bode well for me. Next, I stop GDM, kill Xorg (for some reason it doesn't quit when GDM is stopped), and start an X session. It takes a few moments, but eventually everything loads and I'm in GNOME Shell. This is when I discover that things aren't working as I would expect them to. The entire environment is very laggy, cursor movements stutter, my audio doesn't work (PulseAudio shows my audio as Dummy Output), the network status indicator doesn't show my network connection status or show a list of nearby networks (or even the Network Settings menu option, nothing at all pops up) when clicked on, and when checking the Graphics information in the Details applet of GNOME Control Center, I see that it's using Gallium 0.4 on llvmpipe (LLVM 0x209) when it should be using my Intel integrated graphics (this probably accounts for the lag and stutters). I do get my power status indicator back, however, my graphical user session basically just doesn't work properly. So I close the session and logout, log in as root, and start an X session. Everything works as I would expect. The environment operates smoothly, I have sound, my graphics adapter is detected properly (Mobile Intel® GM45 Express Chipset), I have my power status indicator, the network status icon reflects my connected status and shows the nearby networks. It all works! So now I'm wondering... Maybe it's a problem with my personal user account? I create a brand new user account, log in as that user (and get two similar messages as when I logged into my personal account), and start an X session. It suffers the same problems as my personal user account. Now I have no idea what's going on, so I decide to file this bug report and hopefully get some ideas of what to do to determine what's going wrong and why, and possibly how to fix it all. All this, because I wanted my power status indicator back, because it doesn't show up when using sysvinit. Everything else seems to work just fine, but that indicator is missing and it bothered me that much. (I will note that I discovered that starting systemd-logind manually when using sysvinit, then killing and restarting gnome-settings-daemon does give me back the power status indicator without any other complications, however, this is not an ideal solution.) You'll have to forgive me for this lengthy report. I really wasn't sure how else to get everything across accurately. -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.10 ii initscripts 2.88dsf-41 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.17-0experimental2 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.4.3-4 ii libdbus-1-3 1.6.8-1 ii libkmod2 9-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-9 ii libselinux1 2.1.12-1 ii libsystemd-daemon0 44-11 ii libsystemd-id128-0 44-11 ii libsystemd-journal0 44-11 ii libsystemd-login044-11 ii libudev0 175-7.1 ii libwrap0 7.6.q-24 ii udev 175-7.1 ii util-linux 2.20.1-5.3 Versions of packages systemd recommends: pn libpam-systemd none Versions of packages systemd suggests: ii
Bug#704423: systemd: gdm does not start, user sessions have multiple issues, root session works normally
...Wow, I feel really dumb right now. That was all it took to get things working. Thank you so much! (I have to wonder now, though... if that package is necessary to make things work properly, why isn't a dependency of the package?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704177: libgnome-desktop-3-2: dependency on gnome-desktop3-data=3.4.2-1 blocks gnome-desktop3-data from being updated past 3.4.2-1
Ah, I noticed that just a while ago when I updated. In truth, EOG was the only application still dependent on that old package (at least, installed on my system), so with it updated to use libgnome-desktop-3-7, I don't have a reason to keep libgnome-desktop-3-2 around anymore. That said, if there are any other applications that depend on libgnome-desktop-3-2 that I don't happen to have installed for whatever reason, you may still need to change its dependencies, or update those packages to use the newer libgnome-desktop-3-7 package. (I don't see why the packages coming out for GNOME 3.8 would be depending on the older packages instead of libgnome-desktop-3-7, but then, I don't really understand how Debian's dependencies are tracked. I just notice when dependencies give me hell trying to get other things updated, heh.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704177: libgnome-desktop-3-2: dependency on gnome-desktop3-data=3.4.2-1 blocks gnome-desktop3-data from being updated past 3.4.2-1
Package: libgnome-desktop-3-2 Version: 3.4.2-1 Severity: normal Dear Maintainer, This has actually been an issue since GNOME 3.6 entered Experimental. libgnome-desktop-3-2 version 3.4.2-1 depends on gnome-desktop3-data being exactly the same version, preventing gnome-desktop3-data from being updated beyond that version. Since Eye of GNOME (eog) still depends on this package (even at version 3.8), I cannot update gnome-desktop3-data past version 3.4.2-1 without removing eog and libgnome-desktop-3-2. I'm not sure if there's anything in gnome-desktop3-data that libgnome- desktop-3-2 depends on so strictly that it can't work with newer versions of the package and have it's dependency changed to be on gnome-desktop3-data greater than or equal to version 3.4.2-1 (which is what libgnome-desktop-3-4 and libgnome-desktop-3-7 currently have as their dependency on that package), but if there's not, would it at all be possible to fix that dependency so gnome-desktop3-data can be updated? -- System Information: Debian Release: 7.0 APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnome-desktop-3-2 depends on: pn gnome-desktop3-datanone ii gsettings-desktop-schemas 3.6.0-1 ii libc6 2.17-0experimental2 ii libcairo2 1.12.2-3 ii libgdk-pixbuf2.0-0 2.28.0-1 ii libglib2.0-0 2.36.0-1 ii libgtk-3-0 3.8.0-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrandr2 2:1.4.0-1 Versions of packages libgnome-desktop-3-2 recommends: ii hwdata 0.234-1 libgnome-desktop-3-2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703665: linux-image-3.8-trunk-amd64: version 3.8.3-1~experimental.1 causes xrandr to detect too many monitors
Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Dear Maintainer, Recently it was discovered in Ubuntu that version 3.8.3 of the linux kernel had issues that caused xrandr to detect an external monitor connected to a laptop with Intel integrated graphics when in fact no monitors were connected, limiting the max display resolution to 1024x768 until the Mirrored Displays option was unchecked. This would allow one to set the laptop display to the correct resolution, though it would eventually reset itself back to 1024x768 because all open applications would fail to be drawn correctly on the window upon changing the resolution, meaning confirming the new settings wasn't possible. Logging out before this happens then logging back in would keep the changed resolution for the user, however the consoles and login screen would retain the incorrect resolution. I want to point out that your current kernel suffers from the same issues, and the Ubuntu kernel has recently been fixed so it no longer happens. The launchpad bug about this issue is here, for your perusal: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1156310 I hope you take a look into this and release a fixed kernel soon, until then I'll revert back to 3.8.2 to avoid this issue. -- Package-specific info: ** Version: Linux version 3.8-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.2-1~experimental.1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.8-trunk-amd64 root=UUID=376d5c13-85a6-476a-aa9e-1be9dc19d808 ro quiet splash ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [8.272826] Intel(R) Wireless WiFi driver for Linux, in-tree: [8.272831] Copyright(c) 2003-2012 Intel Corporation [8.273251] iwlwifi :02:00.0: irq 44 for MSI/MSI-X [8.493515] Linux video capture interface: v2.00 [8.593711] uvcvideo: Found UVC 1.00 device CNF9011 (04f2:b175) [8.610028] input: CNF9011 as /devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.0/input/input9 [8.610179] usbcore: registered new interface driver uvcvideo [8.610182] USB Video Class driver (1.1.1) [8.624411] iwlwifi :02:00.0: loaded firmware version 39.31.5.1 build 35138 [8.856100] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled [8.856107] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [8.856111] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [8.856115] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled [8.856119] iwlwifi :02:00.0: CONFIG_IWLWIFI_P2P enabled [8.856124] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [8.856266] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [8.942282] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [9.132175] snd_hda_intel :00:1b.0: irq 45 for MSI/MSI-X [9.483932] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa, board id: 3655, fw id: 568746 [9.499796] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input10 [9.530035] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input11 [9.576457] input: HDA Intel HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input12 [9.576664] input: HDA Intel Mic as /devices/pci:00/:00:1b.0/sound/card0/input13 [9.576827] input: HDA Intel Headphone as /devices/pci:00/:00:1b.0/sound/card0/input14 [9.790952] cfg80211: World regulatory domain updated: [9.790957] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [9.790962] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.790966] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.790970] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.790974] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.790977] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 12.416431] Adding 1048572k swap on /dev/sda3. Priority:-1 extents:1 across:1048572k [ 12.440647] EXT4-fs (sda1): re-mounted. Opts: (null) [ 12.831851] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 13.077889] fuse init (API version 7.20) [ 13.114873] loop: module loaded [ 16.539343] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [ 16.592183] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [ 25.942738] Bluetooth: Core ver 2.16 [ 25.942769] NET: Registered protocol family 31 [ 25.942772] Bluetooth: HCI device and connection manager initialized [ 25.942785] Bluetooth: HCI socket layer initialized [ 25.942790] Bluetooth: L2CAP socket layer initialized [ 25.942799] Bluetooth: SCO socket layer initialized [ 26.035018] Bluetooth: RFCOMM TTY layer
Bug#694261: Found a work-around
I just want to report that I found a work-around for this issue: Disable PulseAudio's flat volumes. Apparently having this setting enabled (Debian's default state) causes PulseAudio to increase the master volume to 100% if an application (ie. Banshee) sets it's volume to 100%. To disable this setting, open /etc/pulse/daemon.conf in a text editor, find the line ; flat_volumes = yes and change it to no, also removing the ; to uncomment the line so the setting is used. I suspect this may be the reason this issue doesn't appear to exist in Ubuntu, they must have flat volumes disabled by default... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694261: banshee: Banshee 3.6 does unusual, undesired things to audio playback in Debian
I just recently installed the latest version of Banshee from experimental (2.6.0-4) and I would like to update the status of this bug. There no longer seems to be an issue with Banshee messing up other applications audio output, nor does Banshee seem to be setting audio output to some sort of Mono setting, audio output remains Stereo as it should. Banshee is still boosting the system volume to 100% when starting playback. The volume can be turned down while playback is active, and remains lowered even after stopping and restarting playback while Banshee is running. Restarting Banshee will cause it to raise the volume again when starting playback. This should really be corrected, as having the system volume jump to 100% while using headphones is very hard on one's ears. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694261: banshee: Banshee 3.6 does unusual, undesired things to audio playback in Debian
Package: banshee Version: 2.6.0-1+b1 Severity: important Dear Maintainer, Banshee 3.6 is doing unusual things to audio playback on my system. When I start playing music in Banshee, my system volume immediately jumps to 100%, which is very unpleasant when using headphones. Also, audio output seems to be forced to some sort of mono output rather than proper stereo output. While Banshee is playing audio, other system sounds and audio from other applications is not played back correctly, once Banshee is shut down audio playback from other applications seems to revert to normal. I can adjust the system volume down back down while Banshee is playing, but if I stop audio playback then restart it it gets pushed back up to 100%. I thought at first this might be an issue with the Debian package, however installing a package built for Ubuntu also has the same problem, while the same package on Ubuntu does not have this problem. Both OSes are on the same hardware, and both OSes are using the same or equivalent versions of GStreamer packages (a number of which I've had to hold back due to causing an issue with Banshee and Rhythmbox music playback stalling at the beginning of a FLAC track when the previous track was an MP3...). I'm not sure if this is a problem specific to Banshee (since a package from Ubuntu causes the same problem on Debian but works fine on Ubuntu), but I do not know what other package might be responsible since downgrading Banshee to 3.4 makes the problem go away. If someone could point me in the right direction and help me narrow down the appropriate package, I would appreciate it. -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages banshee depends on: ii gnome-icon-theme 3.6.0-1 ii gstreamer0.10-alsa [gstreamer0.10-audiosink 0.10.35-1 ii gstreamer0.10-plugins-bad [gstreamer0.10-au 0.10.22-3+b1 ii gstreamer0.10-plugins-base 0.10.35-1 ii gstreamer0.10-plugins-good [gstreamer0.10-a 0.10.30-2.1 ii gstreamer0.10-pulseaudio [gstreamer0.10-aud 0.10.30-2.1 ii libboo2.0.9-cil 0.9.5~git20110729.r1.202a430-2 ii libc62.16-0experimental0 ii libcairo21.12.6-1 ii libdbus-glib1.0-cil 0.5.0-4 ii libdbus1.0-cil 0.7.0-5 ii libgconf2.0-cil 2.24.2-2 ii libgdata2.1-cil 2.1.0.0-1 ii libgdk-pixbuf2.0-0 2.26.4-2 ii libgkeyfile1.0-cil 0.1-4 ii libglib2.0-0 2.34.2-1 ii libglib2.0-cil 2.12.10-5 ii libgpod4 0.8.2-7 ii libgstreamer-plugins-base0.10-0 0.10.35-1 ii libgstreamer0.10-0 0.10.36-1 ii libgtk-sharp-beans-cil 2.14.1-3 ii libgtk2.0-0 2.24.13-1 ii libgtk2.0-cil2.12.10-5 ii libgudev1.0-cil 0.1-3 ii libkarma00.1.2-2.3 ii libmono-addins0.2-cil0.6.2-2 ii libmono-cairo4.0-cil 2.10.8.1-6 ii libmono-corlib4.0-cil2.10.8.1-6 ii libmono-posix4.0-cil 2.10.8.1-6 ii libmono-sharpzip4.84-cil 2.10.8.1-6 ii libmono-system-core4.0-cil 2.10.8.1-6 ii libmono-system-xml4.0-cil2.10.8.1-6 ii libmono-system4.0-cil2.10.8.1-6 ii libmono-zeroconf1.0-cil 0.9.0-4 ii libmtp9 1.1.5-1 ii libnotify0.4-cil 0.4.0~r3032-5 ii libpango1.0-01.30.1-1 ii libsoup-gnome2.4-1 2.40.1-1 ii libsoup2.4-1 2.40.1-1 ii libsqlite3-0 3.7.14.1-1 ii libtaglib2.0-cil 2.0.4.0-1 ii libwebkitgtk-1.0-0 1.9.2-1 ii libwnck222.30.7-1 ii libx11-6 2:1.5.0-1 ii libxrandr2 2:1.4.0-1 ii libxxf86vm1 1:1.1.2-1 ii mono-runtime 2.10.8.1-6 Versions of packages banshee recommends: ii avahi-daemon 0.6.31-1 ii brasero3.4.1-4 ii media-player-info 17-1 Versions of packages banshee suggests: pn
Bug#687500: hangs in console instead of switching to display manager
This is just a follow-up to my previous message. The message I get on the console when the system finishes booting but fails to switch to GDM is as follows: startpar: service(s) returned failure: plymouth ...Failed! I hope this may be helpful. Something else I noticed, if I uninstall Plymouth, but do not update the initramfs file afterward, the splash screen is still displayed, GDM has no problem loading afterward, and GDM also seems to be able to grab the last frame from the boot splash to fade in from (something that having Plymouth actually installed seemed to have broken when switching from Plymouth to GDM 3.4 previously). I don't know if this might be relevant or helpful information but it was something interesting I noticed... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687500: hangs in console instead of switching to display manager
Package: plymouth Version: 0.8.8-1 Followup-For: Bug #687500 I've begun experiencing this issue since my update to GDM 3.6 from Experimental, with GDM 3.4 there seemed to be no issue with Plymouth handing off to GDM once the computer finished booting. Occasionally I can drop to a console and restart GDM manually to get the display manager to come up, more often though I do not seem to be able to drop to the console. Occasionally I've noticed an error message related to the Plymouth service failing to start when I shutdown the computer after a failed boot (I'll try to get the exact error message later, it does not seem to be logged...), I suspect it may be a clue as to why Plymouth fails to hand off properly to the display manager once the computer finishes booting. I should note that I am using a graphical splash screen, I do not currently know if a text theme would exhibit the same issues. -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages plymouth depends on: ii initramfs-tools0.109 ii libc6 2.13-36 ii multiarch-support 2.13-36 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 7.0.3 ii plymouth-drm 0.8.8-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684231: libgstreamer-plugins-base0.10-0: Music playback in Banshee/Rhythmbox stalls when changing from an MP3 track to a FLAC track
Package: libgstreamer-plugins-base0.10-0 Version: 0.10.36-1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** The libgstreamer-plugins-base0.10-0 package versions since version 0.10.35-1 have been causing music playback in Banshee and Rhythmbox to stall at the beginning of a new track when the new track is in FLAC format and the previous track was in MP3 format. Playback may resume after some time, with playback being skipped ahead the amount of time it was stalled. This issue is not present in libgstreamer-plugins-base version 0.10.35-1. I determined this package to be the cause of this issue after reverting it and its various dependants to known good package versions (ie. did not have this problem), loading up Banshee's play queue with a mix of FLAC and MP3 tracks, then selectively updating GStreamer packages in small groups and playing through the queue until the issue showed itself, then reverting to the good packages again and narrowing down the number of packages being updated until it was only this one being updated. There does not seem to be any problem when the new track is in MP3 format and the previous track was in FLAC format. There is also no issue when manually switching tracks. Unfortunately I do not have music in other formats to possibly test for the same kind of stalling. Totem does not seem to suffer from this issue. -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (650, 'experimental'), (650, 'unstable'), (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgstreamer-plugins-base0.10-0 depends on: ii iso-codes 3.37-1 ii libc6 2.13-35 ii libglib2.0-02.33.8-1 ii libgstreamer0.10-0 0.10.36-1 ii liborc-0.4-01:0.4.16-2 ii multiarch-support 2.13-35 ii zlib1g 1:1.2.7.dfsg-13 libgstreamer-plugins-base0.10-0 recommends no packages. Versions of packages libgstreamer-plugins-base0.10-0 suggests: ii gnome-codec-install0.4.7+nmu1 ii libvisual-0.4-plugins 0.4.0.dfsg.1-7 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
