[Bug 580242] Re: Kmail cannot send to groups
however 4.4.4 from https://edge.launchpad.net/~kubuntu- ppa/+archive/ppa/ still shows the same problem :-( -- Kmail cannot send to groups https://bugs.launchpad.net/bugs/580242 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 580242] Re: Kmail cannot send to groups
I can confirm this problem. The page linked in the first post suggests this is fixed in KDE 4.4.3. -- Kmail cannot send to groups https://bugs.launchpad.net/bugs/580242 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
Hi, A note for those who are dissatisfied with the progress on this bug. It seems likely that these usb problems could actually be caused by numerous different glitches in different usb controllers or devices. Don't expect one single fix to address all these problems simultaneously; I guess there will only be fixes or workarounds produced one at a time, by someone with access to the relevent hardware. It is the same situation seen on the release of windows vista, where the minor differences between xp and vista exposed similar device bugs which sent vendors scurrying to produce driver updates. -- ehci_hcd module causes I/O errors in USB 2.0 devices https://bugs.launchpad.net/bugs/88746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 268859] Re: USB flash drive not recognized
*** This bug is a duplicate of bug 88746 *** https://bugs.launchpad.net/bugs/88746 It looks different to #88746. You mention you have one USB drive that works, and one that does not; can you confirm this happens even if there are inserted into the same USB port. That would definitely make it different to #88746. If that is the case, can you eliminate the possibility that your Relay drive is defective by trying it on a different computer. -- USB flash drive not recognized https://bugs.launchpad.net/bugs/268859 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
Ive been checking whether it is sufficient to disable autosuspend for a few specific devices on the nforce2 board, hoping to package an easier fix as a udev rule. In short, its not possible. I haven't been able to determine the full pattern, but I definitely also need to disable autosuspend on the powered hub (Belkin 050d:0237 - it has no problems with other machines), and some effects depend on whether autosuspend is enabled when the device is first scanned. For this nforce2 board, disabling autosuspend entirely through modprobe.d seems the appropriate fix. -- ehci_hcd module causes I/O errors in USB 2.0 devices https://bugs.launchpad.net/bugs/88746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
I previously reported that USB devices were not working on my nforce2 system when connected via hub after a dapper to hardy upgrade. I had tried the suggested workarounds here and nothing helped *except* blacklisting ehci_hcd, So Ive been living with usb 1 speeds for a month :-( But now I have a fix... Robert North has describes two implementations of the autosuspend workaround in this bug report. Firstly at https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/88746/comments/188 he suggests setting /sys/module/usbcore/parameters/autosuspend to -1 and reloading ehci-hcd. This is what I tested, and it did not help. After further debugging I independantly found a working solution which is identical to his second suggestion at https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.20/+bug/88746/comments/209. This involves including the setting in modprobe.d and rebooting. The first solution was insufficient in my case because the value in /sys/module/usbcore/parameters/autosuspend is a default which is applied to newly detected devices, but reloading echi-hcd was insufficent to force the redetection of all my usb devices. A transcript of the first workaround: [EMAIL PROTECTED]:~# rmmod ehci_hcd [EMAIL PROTECTED]:~# echo -1/sys/module/usbcore/parameters/autosuspend [EMAIL PROTECTED]:~# cat /sys/module/usbcore/parameters/autosuspend -1 [EMAIL PROTECTED]:~# modprobe ehci_hcd [EMAIL PROTECTED]:~# cat /sys/module/usbcore/parameters/autosuspend -1 [EMAIL PROTECTED]:~# find /sys/ -name autosuspend /sys/devices/pci:00/:00:02.0/usb1/power/autosuspend /sys/devices/pci:00/:00:02.1/usb2/power/autosuspend /sys/devices/pci:00/:00:02.2/usb3/power/autosuspend /sys/devices/pci:00/:00:02.2/usb3/3-2/power/autosuspend /sys/module/usbcore/parameters/autosuspend [EMAIL PROTECTED]:~# cat `find /sys/ -name autosuspend` 2 2 -1 -1 -1 Two devices were left using autosuspend. I can patch them manually to get a working system: [EMAIL PROTECTED]:~# echo -1 /sys/devices/pci:00/:00:02.0/usb1/power/autosuspend [EMAIL PROTECTED]:~# echo -1 /sys/devices/pci:00/:00:02.1/usb2/power/autosuspend [EMAIL PROTECTED]:~# cat `find /sys/ -name autosuspend` -1 -1 -1 -1 -1 Setting it in modprobe.d is much better because the option will be set sufficiently early that no devices ever have autosuspend turned on. That link again: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209 Robert described that second workaround as to apply the workaround permanently, but it is obviously deeper than that. I guess the default 2 second timeout on autosuspend may explain the various posts which say it _sometimes_ works I works if the device is inserted within 2 seconds of other usb activity. -- ehci_hcd module causes I/O errors in USB 2.0 devices https://bugs.launchpad.net/bugs/88746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
FWIW I'm seeing this too. Also on nforce2 chipset. Recently upgraded from Dapper which did not show this problem. -- ehci_hcd module causes I/O errors in USB 2.0 devices https://bugs.launchpad.net/bugs/88746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 46234] Re: Segmentation fault in jpeg plugin
For anyone else affected by this, there is a workaround here: http://ubuntuforums.org/showthread.php?t=422490 -- Segmentation fault in jpeg plugin https://bugs.launchpad.net/bugs/46234 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 72869] Re: Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5
I think this was once fixed by an update, but a subsequent hal update means dapper is still suffering from this bug. Workaround on dapper is downgrading hal. No idea about edgy... -- Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5 https://bugs.launchpad.net/bugs/72869 You received this bug notification because you are a member of Kubuntu Team, which is subscribed to kdebase in ubuntu. -- kubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 72869] Re: Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5
Problem confirmed here too. I have been using the /etc/dbus-1/system.d/hal.conf workaround since upgrading to kde 355. I can also confirm the downgrade fixes the problem. -- Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5 https://launchpad.net/bugs/72869 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 70278] Re: Changes to imlib2 in recent security update causes digikam breakage
have a fix for the broken Dapper too? This is now fixed on Dapper for me. -- Changes to imlib2 in recent security update causes digikam breakage https://launchpad.net/bugs/70278 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48104] Re: Ugly mount point name used for removable media
Confirmed fixed in edgy, and 355 on dapper -- Ugly mount point name used for removable media https://launchpad.net/bugs/48104 -- kubuntu-bugs mailing list kubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 70400] digikam viewer shows black photos in kde 355
Public bug reported: Digikam worked great in dapper using the packages for kde-353. Since installing kde-355 on dapper I am seeing some problems using Digikam's internal viewer/editor. The first photo opened is displayed well. Pressing the 'previous' toolbar button also works, however pressing 'next' shows a black window and the pixel size indicator show 0x0 pixels. Note that it doesnt matter which photo you start with: the first one always displays well, all photos shown by pressing 'previous' display well, but those shown by pressing 'next' do not. This is with digikam 0.8.2~rc1-0ubuntu3. There is nothing interesting in stderr. ** Affects: kubuntu-meta (Ubuntu) Importance: Undecided Status: Unconfirmed -- digikam viewer shows black photos in kde 355 https://launchpad.net/bugs/70400 -- kubuntu-bugs mailing list kubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 70417] safely remove isnt safe
Public bug reported: Binary package hint: kdebase Using safely remove on a usb memory stick causes the desktop icon to disappear immediately, without waiting for any cached writes to complete. I have observed this behaviour in both edgy and dapper with kde-355, with two different memory sticks. kde-353 used to show a progress bar while flushing the cached writes. This was still less than ideal because the progress bar stuck at 0% then jumped to 100% once writing was complete, but at least you knew when it was safe to remove the device. ** Affects: kdebase (Ubuntu) Importance: Undecided Status: Unconfirmed -- safely remove isnt safe https://launchpad.net/bugs/70417 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 52126] unattended-upgrades needs manual configuration
Public bug reported: Binary package hint: unattended-upgrades The unattended-upgrades package needs manual configuration after it is installed. Unattended upgrades are disabled by default, even once this package is installed. I suggest adding to /etc/apt/apt.conf.d/50unattended-upgrades APT::Periodic::Unattended-Upgrade 1; ** Affects: kubuntu-meta (Ubuntu) Importance: Wishlist Status: Confirmed -- unattended-upgrades needs manual configuration https://launchpad.net/bugs/52126 -- kubuntu-bugs mailing list kubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 52126] Re: unattended-upgrades needs manual configuration
Aha! I only just noticed that unattended-upgrades is part of the default ubuntu and xubuntu install. I therefore agree the current configuration file defaults make sense. It is NOT part of the default install of Kubuntu. Changing that would be a better wishlist item. -- unattended-upgrades needs manual configuration https://launchpad.net/bugs/52126 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 52126] unattended-upgrades needs manual configuration
Public bug reported: Binary package hint: unattended-upgrades The unattended-upgrades package needs manual configuration after it is installed. Unattended upgrades are disabled by default, even once this package is installed. I suggest adding to /etc/apt/apt.conf.d/50unattended-upgrades APT::Periodic::Unattended-Upgrade 1; ** Affects: unattended-upgrades (Ubuntu) Importance: Untriaged Status: Unconfirmed -- unattended-upgrades needs manual configuration https://launchpad.net/bugs/52126 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 51502] Re: hardware clock overrides time set by ntpdate on boot
bootchart here (but remove the XXX): http://www.tarind.com/dapXXXper-20060701-1.png -- hardware clock overrides time set by ntpdate on boot https://launchpad.net/bugs/51502 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 51268] adept-notifier, and users who cannot sudo
Public bug reported: Binary package hint: adept Adept-notifier currently works identically for all users. This is counterproductive for users who do not manage the computer, are not in the admin group, and cannot sudo. if an update is needed it displays the warning icon which encourages the user to click. That then shows the kdesu password prompt but, for these users, there is no possible password which will work. Very frustrating. ** Affects: ept (Ubuntu) Importance: Untriaged Status: Unconfirmed -- adept-notifier, and users who cannot sudo https://launchpad.net/bugs/51268 -- kubuntu-bugs mailing list kubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 30720] Re: sb_filter.py does not lock the database file resulting in corruption
(I am an occasional spambayes developer) This behaviour is by design. future versions are likely to offer other storage options which do not have this problem (possibly based on zodb). Short-term solutions include: a. Configure procmail to use a lock file, and use a wrapper script around sb_filter.py for training which also uses the 'lockfile' utility to serialise access to your database. b. Replace all uses of sb_filter.py with sb_bnfilter.py. This behaves (almost) identically, but all operations are automatically dispatched through a shared, automatically managed daemon process. The primary purpose of this is to reduce startup overhead, but it will also eliminate the concurrency which causes this corruption. I hope this helps, -- sb_filter.py does not lock the database file resulting in corruption https://launchpad.net/bugs/30720 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
