*** This bug is a duplicate of bug 636311 ***
https://bugs.launchpad.net/bugs/636311
Did some digging. The correct duplicate bug is #636311. I have updated
the details.
** This bug is no longer a duplicate of bug 658590
Rhythmbox will not minimize to sound-indicator if music is not
*** This bug is a duplicate of bug 658590 ***
https://bugs.launchpad.net/bugs/658590
Actually, I don't think this is a duplicate. The other bug (658950) is
related to the change in the way rhythmbox minimises. If you look at my
comments I am fine with that part (once I found out where to look
Public bug reported:
Binary package hint: rhythmbox
After upgrading to 10.10, closing rhythmbox no longer causes it to
minimise to the tray. It is still playing but there is no notification
anywhere. While in this state the left mouse button stops responding.
The cursor moves but clicking the
--
After upgrade to 10.10 rhythmbox no longer minimises to system tray and
prevents mouse buttons from working
https://bugs.launchpad.net/bugs/669301
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to rhythmbox in ubuntu.
--
OK. I found out that rhythmbox is now inside the sound menu.
Nevertheless, hit the play button (in the main gui or in the sound menu)
and that's the last left click I can make. After that the left button
becomes totally unresponsive.
I just discovered that unplugging and re-plugging the mouse
This issue is still present in maverick beta:
gnome-terminal:
Installed: 2.31.91-0ubuntu1
--
Color palette : Bad choice !
https://bugs.launchpad.net/bugs/377564
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs
Additional note here:
It appears that for all the actual predefined colour schemes, black is
black.
Black isn't black however for the default colour scheme set up when a
new user account is created.
To observe, remove ~/.gconf/apps/gnome-terminal, log out and in again.
--
Color palette : Bad
Note that the problem still exists in the lucid release
(2.30.0-0ubuntu1)
--
Recommend a grace timeout between blanking and locking the screen
https://bugs.launchpad.net/bugs/550825
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
I've never seen this fixed, and it still happens in lucid. Fullscreen
programs such as aptitude still get that washed-out look.
(Observed on the armel UNE image)
** Changed in: gnome-terminal (Ubuntu)
Status: Fix Released = Confirmed
--
Color palette : Bad choice !
Public bug reported:
Binary package hint: gnome-screensaver
On armel, the screensaver is not shown by default and instead the screen
locks immediately when gnome-screensaver's timeout fires.
This means that you get no chance to avoid entering your password,
whereas if the screensaver were to be
Hi,
On armel, the screensaver is not shown by default and instead
the screen locks immediately when gnome-screensaver's timeout fires.
This is already the case, as the screensaver fades out
gradually. Are you not seeing the fade on armel?
Was this feature added recently? If it was
That might work. Is there an easy way I can try that out?
--
Recommend a grace timeout between blanking and locking the screen
https://bugs.launchpad.net/bugs/550825
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-screensaver in
Public bug reported:
Binary package hint: gnome-terminal
Ubuntu lucid
gnome-terminal 2.29.6-0ubuntu1
Architecture: armel (imx51); probably applies to other arches too?
The effect may be an inappropriately used visual bell, or more probably
something else.
An infuriating side-effect is that the
FIx confirmed in fixed in 4.4.2-5ubuntu1
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in ubuntu.
--
desktop-bugs mailing list
Thanks!
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
** Changed in: gcc-4.4 (Ubuntu)
Status: Fix Released = Confirmed
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in ubuntu.
Unfortunately, the __sync_synchronize() bug appears still to be present in the
updated GCC.
A call to this intrinsic still disappears in the compiler's output.
The __sync_lock_test_and_set() bug may still be present; however it is
also possible that the __sync_synchronize() bug is masking the
-mimplicit-it=thumb does now seem to be passed correctly to the
assembler, though:
$ echo 'void f(void) { asm volatile(moveq r0, #1); }' | gcc -c -o
tmp.o -xc - objdump -d tmp.o
f:
...
4: bf08it eq
6: 2001moveq r0, #1
--
[armel] Atomic
Thanks for this.
My build failed, but I think this may be due to some autoconf version
mismatch or similar, or incorrect versions of some build dependency.
However, a .so was build successfully and looks correct (notwithstanding
the missing __sync_synchronize() calls resulting from
I got a good build, but it's not quite right... the __sync_synchronize()
calls compile away to nothing, which is not what's intended.
For now, the package builds and should run fine on uniprocessor
platforms, so this should unblock you, but I'll provide an additional
patch shortly once I've
Public bug reported:
Binary package hint: gcc-4.4
Observed in gcc 4.4.2-3ubuntu1
Believed to affect all versions
__sync_synchronnize() should perform a memory barrier, but is a noop (at least
with -O2)
__sync_lock_release() should place a memory barrier before the compare-exchange
operation,
** Description changed:
latest glib upload failed to build in lucid:
12:52 asac
https://edge.launchpad.net/ubuntu/+source/glib2.0/2.23.0-1ubuntu1/+build/1374402
- 12:53 asac libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/build/buildd/glib2.0-2.23.0/glib -I..
I expect to be able to post a patch soon; it may be simplest to leave
this unfixed until then.
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed
This patch should fix the issue with __sync_lock_release():
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00198.html
The __sync_synchronize() is not fixed by this— another patch should
follow soon.
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
This patch should fix the __sync_synchronize() issue, by making sure GCC does
not optimise away the call to the libgcc function which implements this:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html
These should now be fixed on the GCC trunk and await backporting to the
upstream 4.4
This patch converts to a cleaner and slightly more efficient
implementation, avoiding the need for the explcit __sync_synchronize()
in atomic_spinlock_release()
This patch should apply on top of the patch stack in debian/patches,
assuming that patch attached above has already been merged.
Note
** Tags added: armel armv7
--
assembly fails to build on armel/lucid
https://bugs.launchpad.net/bugs/491342
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
[Added the armv7 tag to help track ARMv7 migration issues.]
Agreed, the best way to solve cases like this is to use the GCC
intrinsics instead of inline asm.
The attached patch should hopefully work for this; but I haven't been
able to build or test it just yet.
I've tried to modify configure
$ grep ^X /etc/default/console-setup
XKBMODEL=pc105
XKBLAYOUT=gb
XKBVARIANT=
XKBOPTIONS=
This does not ever seem to change, even when the bug occurs and US
keyboard layout is used.
Basically, the bug seems to persist from installation until the default
user logs in explicitly (not using gdm
This is using auto-login. I didn't select anything explicitly, so I was
expecting the system default to be used.
Maybe there is something wrong with the initial user's preferences are
initialised during installation?
I currently have a reinstall under way; I'll try to answer the other
points
When logging in explicitly though GDM on the first boot after
installation, the keyboard layout option at the login screen defaults
correctly to UK, and I get UK keyboard layout after login.
If I then restart gdm so that auto-login happens again, I get UK layout
in the desktop session again, so
Unfortunately, Valgrind is not available for armel at this time.
--
gnome-panel crashed with SIGSEGV in gdk_window_impl_x11_get_colormap()
https://bugs.launchpad.net/bugs/461912
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
I now have a backtrace for a similar case. See:
https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/461912 (gnome-panel
crashed with SIGSEGV in gdk_window_impl_x11_get_colormap())
--
gnome-panel crashed with SIGSEGV in free()
https://bugs.launchpad.net/bugs/458109
You received this bug
** Visibility changed to: Public
--
gnome-panel crashed with SIGSEGV in gdk_window_impl_x11_get_colormap()
https://bugs.launchpad.net/bugs/461912
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-panel in ubuntu.
--
desktop-bugs
The panel disappears for a moment and then respawns.
No specific action appears to be required to provoke the bug, but if it
happens at all it happens shortly after login, when the system may still
be thrashing starting up applets etc.
The problem has maybe happened to be 3-4 times during the
Looks like there is a gnome-panel-dbg package in main after all.
I've grabbed this, but I can't promise quick feedback --- I don't know
how to provoke the error...
--
gnome-panel crashed with SIGSEGV in free()
https://bugs.launchpad.net/bugs/458109
You received this bug notification because you
Valgrind is not available for armel.
Is there another way to get useful extra debugging information?
--
gnome-panel crashed with SIGSEGV in free()
https://bugs.launchpad.net/bugs/458109
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
There seems to be no ddeb for gnome-panel for armel either.
The most recent armel ddeb seems to be for gnome-panel 2.26.0-0ubuntu7
(at http://ddebs.ubuntu.com/pool/main/g/gnome-panel/gnome-panel-
dbgsym_2.26.0-0ubuntu7_armel.ddeb), and is absent from the package
lists.
Is is possible that an
Public bug reported:
Binary package hint: gdm
If pam policy requires the default user's password to be changed when
gdm starts up, gdm hangs... never reaching a login box or the desktop
This issue was observed in http://cdimages.ubuntu.com/ports/daily-
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/33654515/Dependencies.txt
--
If pam policy requires the default user's password to be changed, gdm hangs,
never reaching a login box or the desktop
https://bugs.launchpad.net/bugs/451285
You received this bug notification
Public bug reported:
Binary package hint: f-spot
Installing f-spot on armel installs a load of Win32 PE executables
(.exe, .dll) and seems to rely on executing these to work.
dpkg prints out a load of illegal instruction errors when trying to
configure the package, but the package is
Note: the above issue applies to the following source package versions,
on Jaunty:
f-spot 0.5.0.3-1ubuntu6
mono 2.0.1-4
I haven't investigated whether Karmic is affected.
--
f-spot seems wrongly packaged / unusable for armel
https://bugs.launchpad.net/bugs/390591
You received this bug
*** This bug is a duplicate of bug 390591 ***
https://bugs.launchpad.net/bugs/390591
This bug seems totally unrelated to
https://bugs.launchpad.net/bugs/390591 (which is about an
architecture/build problem in f-spot/mono and has nothing to do with
text rendering).
Should the duplicate status
David: Its not clear if you've not used mono or C# before,
I haven't.
but mono uses the PE format for its executables, but instead
of using i386 or other assembly code, its CIL byte code.
Wikipedia has a fairly good writeup of how .NET (and thus
mono) applications work
44 matches
Mail list logo
