[Bug 1159707] Re: Cinnamon panel / task bar becomes unresponsive to mouse
Tried the solution given by #36 (select xserver-xorg-video-nouveau instead of nvidia-304). It worked for me too ;-) More info: My set-up is a fresh install of Mint-18 with my /home/* directory copied from Mint-17.3 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1159707 Title: Cinnamon panel / task bar becomes unresponsive to mouse To manage notifications about this bug go to: https://bugs.launchpad.net/linuxmint/+bug/1159707/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1406882] [NEW] Digikam deleting images when Applying Tags or Description
Public bug reported: Noticed a problem today with 64 bit digikam version 4:3.5.0-0ubuntu10. After uploading images from a camera, I started applying Descriptions and Tags. As soon as Apply was hit, digikam appeared to be doing the apply but then the image(s) disappeared from the Thumbnails and/or Preview Image panes. The images appear to have been permanently deleted (not moved to Trash). I couldn't find them anywhere in the file system. I tried this several times, restarted digikam, rebooted, etc, but with the same results. It appears to be related to the writing of the metadata because if I turn off all metadata options (or write the metadata only to a sidecar file) then the image does not appear to ever get deleted. I have only recently turned on the sidecar option, so the bug might be somehow related to that action. ** Affects: digikam (Ubuntu) Importance: Undecided Status: New ** Tags: deleting digikam -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1406882 Title: Digikam deleting images when Applying Tags or Description To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/1406882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 865032] Re: digikam cannot connect to PTP cameras
This bug has been here for months now. It is a big backward step for digikam. Can someone say why the fix hasn't appeared in an update, and when/if it might appear? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/865032 Title: digikam cannot connect to PTP cameras To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/865032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 359857] Re: blt does not work as currently packaged
I suspect that you (pauljohn32) have made a typo in your posting, but just to reiterate, my patch causes tcl/tk 8.5 to load libBLT.2.4.so.8.5 instead of the incorrect libBLT.2.4.so.8.4 (i.e. it doesn't change the version of tcl/tk which is loaded). I haven't worked through the building of BLT to see what the differences are between libBLT.2.4.so.8.4 and libBLT.2.4.so.8.5 so I don't know if my patch affects the anti-aliased fonts problem at all. In my case the problem was that I was getting a segfault in Blt_Init. I didn't dig down to find out exactly what was happening to cause the segfault. -- blt does not work as currently packaged https://bugs.launchpad.net/bugs/359857 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 359857] Re: blt does not work as currently packaged
First, I should declare that I don't know much about the internal
workings of Python, Tcl, or BLT.
This bug has been stopping one of my programs from working. Waiting for
a fix to appear demonstrably didn't work :-( hence I have tackled the
problem with a brute force approach and have found a solution which
works for me. Others can judge whether it is the correct solution.
Starting from the top, I found that in my case the sequence was like this:
Python calls Pmw.ButtonBox
Pmw.ButtonBox calls Pwm._checkForBlt, which calls Tcl (via Tk) ('package',
'require', 'BLT')
Tcl goes through its magic and calls Blt_Init in libBLT.2.4.so.8.4
Boom!
I noticed something suspicious when I got this far into the bowels: The
current Ubuntu version of BLT installs libBLT.2.4.so.8.4 and
libBLT.2.4.so.8.5, which are presumably meant to be used with tcl8.4 and
tcl8.5 respectively. A bit of digging showed that Pmw was using tcl8.5.
The question then was why was Blt using the wrong version? More brute-
forcing showed that libBLT.2.4.so.8.4 was being loaded because
/usr/lib/blt2.4/pkgIndex.tcl said to.
I haven't done any coding in Tcl for some time but it didn't take much
skill to see that /usr/lib/blt2.4/pkgIndex.tcl doesn't appear to know
about tcl8.5. It appears that whoever maintains BLT has forgotten to
update library/pkgIndex.tcl.in in the sources. By making the following
change (and installing the updated /usr/lib/blt2.4/pkgIndex.tcl which
results) I have managed to get my Python program work again ;-)
$ diff -u blt-2.4z/library/pkgIndex.tcl.in~ blt-2.4z/library/pkgIndex.tcl.in
--- blt-2.4z/library/pkgIndex.tcl.in~ 2009-09-11 18:38:35.0 +1000
+++ blt-2.4z/library/pkgIndex.tcl.in2009-09-11 18:33:37.0 +1000
@@ -15,8 +15,10 @@
set taillib ${version}.so.8.2
} elseif {[package vcompare [info tclversion] 8.4] < 0} {
set taillib ${version}.so.8.3
-} else {
+} elseif {[package vcompare [info tclversion] 8.5] < 0} {
set taillib ${version}.so.8.4
+} else {
+set taillib ${version}.so.8.5
}
if { [info commands tk] == "tk" } {
--
blt does not work as currently packaged
https://bugs.launchpad.net/bugs/359857
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 284484] Re: USB ports don't work with kernel 2.6.24.21
I have observed a problem with USB which is probably due to the same cause. USB works o.k. with the 2.6.24-19-generic kernel, but I have problems with the 2.6.24-21-generic kernel. I am using the 8.04 version of Kubuntu. The problems I have observed are related to the use of a USB hub. Basically, the hub is unusable under the 2.6.24-21-generic kernel. My motherboard uses an Intel 845E to provide the USB ports. The hub is a Logitech High Speed mini hub (Vendor Id: 0409, Product Id: 005a). The hub is recognised when it is plugged in but devices plugged into it are not. The kernel appears to not notice when the hub is unplugged (e.g. it still turns up in USBview). The same devices plugged directly into the motherboard USB ports appear to work o.k. Re-booting into the 2.6.24-19 kernel fixes the problem. -- USB ports don't work with kernel 2.6.24.21 https://bugs.launchpad.net/bugs/284484 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 118292] Re: vol_id: detects vfat instead of ext3 UUID
I have been bitten by the same bug.
In my case the disk drive started life with the installation of Fedora
(although the the computer supplier had used some version of Windows on
the disk for testing, which was removed before the computer was supplied
to me). I had no problems using the disk with Fedora for several years.
Kubuntu looked interesting, so I decided to try it by installing it on a
second drive which I added to the computer.
Kubuntu installed and I have been using it (e.g. now) and working around
the inevitable bugs and inconsistencies...
A particularly annoying bug is the fact that udev fails to see my
original Fedora partition. This means that I can't use the LABEL or
UUID methods for that partition in fstab (udev deletes the entries in
/dev/disk and creates new ones each time it is restarted. "mount"
appears to use these entries). Ubuntu uses the new-fangled "upstart"
init scheme (which is annoying on two counts: how it works on Ubuntu
doesn't appear to be well documented, and it seems to be mostly set up
to emulate Sysv init anyway!). Having worked my way through this maze
(init and udev), I found that script /etc/udev/rules.d/65-persistent-
storage.rules appears to be one of the main culprits.
The udev script uses the "vol_id" program to fetch the information about the
LABEL and UUID of each disk device. (remark: the man page for vol_id omits
several of the options which vol_id accepts, including --help and --probe-all)
`vol_id --probe-all` reveals that it identifies two partition signatures on my
old Fedora partition: a vfat one and an ext3 one. For some reason (I haven't
yet been able to find an explanation in my googling) it is possible to have
both at the same time. The vfat signature is, it appears, always in the first
512 bytes. The ext3 ones start at byte 1024. Thus is would appear that it is
possible to have the two valid signatures at the same time by either of the
following: format a partition as a vfat drive first and then format it as ext3,
or (possibly) format it as vfat and then use it and then by chance have the
Windows FAT contain a valid ext3 signature (I don't know whether this is
possible but it almost certainly has a very low probability). A key question
here is: why didn't the program I used to format the partition as ext3 write
nulls over the first 512 bytes?
The solution for me was, as I found on the web, to do "dd if=/dev/zero
of=/dev/XXX bs=512 count=1" and hope I didn't mistype it.
However, this took quite a lot of time to track down and I know from my
web searching that the bug has troubled a number of people. It
certainly didn't make Ubuntu look very "user friendly". I believe that
the bug should be squashed (or beaten into submission) and that the
importance should be above "low".
Some ways to make the process work better:
1. It would appear to be fairly easy to detect the multiple signatures
("vol_id --probe-all") before udev sets up the /dev/disk entries for a
partition and then, if the relevant partition table entry id is not for an MS
file system, to offer to wipe the first 512 bytes for the user (with
appropriate warnings).
2. Do the same checks during the installation process for Ubuntu.
3. Do the same checks in programs such as the KDE "Disk & Filesystem
Configuration Tool"
4. An interesting alternative would be to modify the behaviour of "vol_id" to
always check for multiple signatures and then, if vfat and ext3 (or similar)
are found, to default to returning the information from the second signature
instead of the first (which it does now). This would appear to have a finite,
but low, probability of failure but this probability could be lowered by
comparing the relevant areas of the two copies of the MS FAT.
--
vol_id: detects vfat instead of ext3 UUID
https://bugs.launchpad.net/bugs/118292
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
