Public bug reported:
Binary package hint: hal
On a new hardy install that was started from the netboot/mini.iso. I
did a cli install and then tried to 'apt-get install xubuntu-desktop'.
apt-get install hal
The following NEW packages will be installed:
hal
0 upgraded, 1 newly installed,
Public bug reported:
Binary package hint: update-manager
On a system running xubuntu-desktop the update-manager doesn't open the
browser set in 'prefered applications'. Instead it opens up firefox 3
apparently via gnome-open.
This is a really annoying behavior in my case because I still prefer
ntfsprogs isn't a meta package. It has many binaries and their
associated man pages.
See the following link for the a list of files in the package.
http://packages.ubuntu.com/hardy/i386/ntfsprogs/filelist
--
[8.04] ntfsprogs has no manual or help entry (undiscoverable)
My suggested solution, if some programmer looks at this and wants to
start coding, would be to add another item on the 'Display tab' under
the 'Remote Desktop Size'. I think you would want to add a fourth radio
box with text like 'Manually specified screen size', and then two text
boxes for the
I don't have a fix, but as a work-around you could prevent the menu.lst
from being broken by adjusting the values the post*_hook lines in your
/etc/kernel-image.conf which will prevent update-grub from running. You
could also put the linux-image packages on hold. Then you only update
the kernel
The 0.150-1ubuntu5 version that drops the Hildon interface patch seems
to fix this bug.
--
[intrepid] enter a computer name then hit enter, list stays on screen and
steals input
https://bugs.launchpad.net/bugs/270374
You received this bug notification because you are a member of Ubuntu
Bugs,
I also can confirm this bug on Intrepid.
I built the hardy source package for Intrepid and the bug went away.
The issue seems to be related to the patches that enable the Hildon
interface
--
[intrepid] enter a computer name then hit enter, list stays on screen and
steals input
FYI: I am pretty sure freerdp (a rdesktop fork) fixes this issue with
the refactoring they have been doing.
@PaulH (huffton), I am quite certain this lockup described has nothing
to do with compiz. I see this in a thinclient setup where there there
is no window manager at all, just rdesktop.
On 2009-09-22 Cyclops wrote
Isn't it already applied? I though I did already apply it.
Will look into it.
I am really surprised that this patch still wasn't applied to the
tsclient on 10.04.
I have tried recompiling it on 10.04, but it applied and compiled
cleanly on 9.04 and 9.10. Is
