[Bug 246067] Re: Kernel panic during boot in VirtualBox with kernel 2.6.26.*-generic

2008-09-07 Thread Cyphase
I was able to get Alpha 5 working in Virtualbox 2.0. I used the
alternate installer instead of the desktop CD. Of course, I used the
noreplace-paravirt kernel option. After installing, I tried booting with
noreplace-paravirt. It booted, but X wouldn't respond to my keyboard or
mouse. I went to a virtual terminal and tried to add the c-korn ppa (
https://launchpad.net/~c-korn/+archive ), but when I ran apt-get update,
it couldn't resolve any domain names. The network interface wasn't
working. I manually downloaded the patched kernel from
http://ppa.launchpad.net/c-korn/ubuntu/pool/main/l/linux/ and put it on
an iso, then mounted it in Virtualbox. After installing it via dpkg, I
restarted the VM. It booted without a problem. After that I used
Synaptic to force the versions of all the kernel packages to the c-korn
repository. This seems like it should work for everyone.

-- 
Kernel panic during boot in VirtualBox with kernel 2.6.26.*-generic
https://bugs.launchpad.net/bugs/246067
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 266932] [NEW] Problems with Vino's Disable the wallpaper when connected option

2008-09-05 Thread Cyphase
Public bug reported:

Binary package hint: vino

Vino 2.23.91-0ubuntu1 on Intrepid

As far as I can tell, this isn't a programming error, it's a logic
error. I have a separate computer running Intrepid, on which Vino is
configured to disable the wallpaper if someone is connected. I VNC'ed
into it, and the wallpaper was disabled. Then, to try out the latest
Vinagre, I VNC'ed from the Intrepid system to the Intrepid system. At
this point both my main system and the Intrepid system are VNC'ed into
the Intrepid system. When I closed Vinagre on the Intrepid system, Vino
restored the wallpaper. Obviously, this isn't the preferred behavior. It
should keep it disabled as long as anyone is connected. I tried
disabling the Disable the wallpaper when connected option, then re-
enabling it, but the wallpaper still showed. When I disconnected then
reconnected, it hid the wallpaper, and would not show it if I disabled
the hide wallpaper option. Also, if I connect, which causes the
wallpaper to be disabled, then disable the hide wallpaper option and
disconnect, it doesn't re-enable the wallpaper. Here's how I think it
should happen, starting with no one connected and wallpaper enabled
(although if a use has manually disabled their wallpaper, the below
code would handle it) (I don't know anything about the Vino code, so
I'm just making up function/variable names):

code

vinoDisabledWallpaper = false # default value

def ConnectionEstablished(...):
...
if GConf(/desktop/gnome/remote_access/disable_background) == true: # 
If Vino is set to disable the background
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.

def ConnectionTerminated(...):
...
if IsAnyoneConnected() == false  isWallpaperDisabled = true:  # If no 
one is still connected and

# Vino disabled the wallpaper
EnableWallpaper() # Even if (especially if) someone disabled 
the hide wallpaper option, it should enable the wallpaper

def EnableHideWallpaperOption(...): # Enabling the Disable the wallpaper when 
connected option
...
if IsAnyoneConnected() == true: # If someone is connected
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.

def DisableHideWallpaperOption(...): # Disabling the Disable the wallpaper 
when connected option
...
if vinoDisabledWallpaper == true:
EnableWallpaper()
vinoDisabledWallpaper = false

/code

** Affects: vino (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: background vino vnc wallpaper

** Summary changed:

- Vino restores wallpaper when someone disconnects, even if someone else is 
still connected
+ Problems with Vino's Disable the wallpaper when connected option

** Tags added: background vino vnc wallpaper

-- 
Problems with Vino's Disable the wallpaper when connected option
https://bugs.launchpad.net/bugs/266932
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 266932] Re: Problems with Vino's Disable the wallpaper when connected option

2008-09-05 Thread Cyphase
** Description changed:

  Binary package hint: vino
  
  Vino 2.23.91-0ubuntu1 on Intrepid
  
  As far as I can tell, this isn't a programming error, it's a logic
  error. I have a separate computer running Intrepid, on which Vino is
  configured to disable the wallpaper if someone is connected. I VNC'ed
  into it, and the wallpaper was disabled. Then, to try out the latest
  Vinagre, I VNC'ed from the Intrepid system to the Intrepid system. At
  this point both my main system and the Intrepid system are VNC'ed into
  the Intrepid system. When I closed Vinagre on the Intrepid system, Vino
  restored the wallpaper. Obviously, this isn't the preferred behavior. It
  should keep it disabled as long as anyone is connected. I tried
  disabling the Disable the wallpaper when connected option, then re-
  enabling it, but the wallpaper still showed. When I disconnected then
  reconnected, it hid the wallpaper, and would not show it if I disabled
  the hide wallpaper option. Also, if I connect, which causes the
  wallpaper to be disabled, then disable the hide wallpaper option and
  disconnect, it doesn't re-enable the wallpaper. Here's how I think it
- should happen, starting with no one connected and wallpaper enabled (I
- don't know anything about the Vino code, so I'm just making up
- function/variable names):
+ should happen, starting with no one connected and wallpaper enabled
+ (although if a use has manually disabled their wallpaper, the below
+ code would handle it) (I don't know anything about the Vino code, so
+ I'm just making up function/variable names):
  
  code
  
  vinoDisabledWallpaper = false # default value
  
  def ConnectionEstablished(...):
...
if GConf(/desktop/gnome/remote_access/disable_background) == true: # 
If Vino is set to disable the background
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.
  
  def ConnectionTerminated(...):
...
if IsAnyoneConnected() == false  isWallpaperDisabled = true:  # If no 
one is still connected and

# Vino disabled the wallpaper
EnableWallpaper() # Even if (especially if) someone disabled 
the hide wallpaper option, it should enable the wallpaper
  
  def EnableHideWallpaperOption(...): # Enabling the Disable the wallpaper 
when connected option
...
if IsAnyoneConnected() == true: # If someone is connected
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.
  
  def DisableHideWallpaperOption(...): # Disabling the Disable the wallpaper 
when connected option
...
if vinoDisabledWallpaper == true:
EnableWallpaper()
vinoDisabledWallpaper = false
  
  /code

-- 
Problems with Vino's Disable the wallpaper when connected option
https://bugs.launchpad.net/bugs/266932
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 266932] Re: Problems with Vino's Disable the wallpaper when connected option

2008-09-05 Thread Cyphase
** Description changed:

  Binary package hint: vino
  
  Vino 2.23.91-0ubuntu1 on Intrepid
  
  As far as I can tell, this isn't a programming error, it's a logic
  error. I have a separate computer running Intrepid, on which Vino is
  configured to disable the wallpaper if someone is connected. I VNC'ed
  into it, and the wallpaper was disabled. Then, to try out the latest
  Vinagre, I VNC'ed from the Intrepid system to the Intrepid system. At
  this point both my main system and the Intrepid system are VNC'ed into
  the Intrepid system. When I closed Vinagre on the Intrepid system, Vino
  restored the wallpaper. Obviously, this isn't the preferred behavior. It
  should keep it disabled as long as anyone is connected. I tried
  disabling the Disable the wallpaper when connected option, then re-
  enabling it, but the wallpaper still showed. When I disconnected then
  reconnected, it hid the wallpaper, and would not show it if I disabled
  the hide wallpaper option. Also, if I connect, which causes the
  wallpaper to be disabled, then disable the hide wallpaper option and
  disconnect, it doesn't re-enable the wallpaper. Here's how I think it
  should happen, starting with no one connected and wallpaper enabled
- (although if a use has manually disabled their wallpaper, the below
+ (although if a user has manually disabled their wallpaper, the below
  code would handle it) (I don't know anything about the Vino code, so
  I'm just making up function/variable names):
  
  code
  
  vinoDisabledWallpaper = false # default value
  
  def ConnectionEstablished(...):
...
if GConf(/desktop/gnome/remote_access/disable_background) == true: # 
If Vino is set to disable the background
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.
  
  def ConnectionTerminated(...):
...
if IsAnyoneConnected() == false  isWallpaperDisabled = true:  # If no 
one is still connected and

# Vino disabled the wallpaper
EnableWallpaper() # Even if (especially if) someone disabled 
the hide wallpaper option, it should enable the wallpaper
  
  def EnableHideWallpaperOption(...): # Enabling the Disable the wallpaper 
when connected option
...
if IsAnyoneConnected() == true: # If someone is connected
if IsWallpaperAlreadyDisabled() == true: # If wallpaper is 
already disabled by the user
return # Than it's already disabled
else:
DisableWallpaper()
vinoDisabledWallpaper = true# So you know it was 
disabled by Vino, and not by the user.
# You 
wouldn't want to enable the wallpaper if the user had manually disabled it.
  
  def DisableHideWallpaperOption(...): # Disabling the Disable the wallpaper 
when connected option
...
if vinoDisabledWallpaper == true:
EnableWallpaper()
vinoDisabledWallpaper = false
  
  /code

-- 
Problems with Vino's Disable the wallpaper when connected option
https://bugs.launchpad.net/bugs/266932
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 199309] [NEW] Thumbnails aren't redone after codecs are installed

2008-03-06 Thread Cyphase
Public bug reported:

If a thumbnail is generated for a video file before the necessary codecs
are installed (resulting in the generic icon, a roll of film), once they
are installed, the thumbnail is not regenerated. This should be fixed.
Maybe the config file (I think there is one, or is the thumbnail name
just a hash of the path?) that tells nautilus where the thumbnail is for
a particular video could have some information about what codecs
were/weren't installed when it was generated, or maybe files with
generic thumbnails could try rethumbnailing every X amount of time.

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
Thumbnails aren't redone after codecs are installed
https://bugs.launchpad.net/bugs/199309
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 132657] [feisty] regression: rtl8180 card worked on fresh edgy install, but not on feisty or gutsy

2007-08-15 Thread Cyphase
Public bug reported:

Binary package hint: linux-source-2.6.22

My RTL8180L 802.11b WiFi card worked out-of-the-box while running Edgy,
but ever since I've been using Feisty I've had to use ndiswrapper. I've
also tried Gutsy and it doesn't work there either.

** Affects: linux-source-2.6.22 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
[feisty] regression: rtl8180 card worked on fresh edgy install, but not on 
feisty or gutsy
https://bugs.launchpad.net/bugs/132657
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


[Bug 70580] Re: Repositories dialog crashes (no distribution tamplate)

2006-12-26 Thread Cyphase
Nevermind, it's fixed.

-- 
Repositories dialog crashes (no distribution tamplate)
https://launchpad.net/bugs/70580

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 70580] Re: Repositories dialog crashes (no distribution tamplate)

2006-12-25 Thread Cyphase
I can confirm this bug as of December 25th. I loaded the Herd 1 Live CD
and did all the updates.

-- 
Repositories dialog crashes (no distribution tamplate)
https://launchpad.net/bugs/70580

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 69207] dhclient doesn't tell the router the computer's hostname by default

2006-10-29 Thread Cyphase
Public bug reported:

Binary package hint: dhcp3-client

When you connect to a router with Ubuntu, by default it doesn't tell the
router the computer's hostname, so you're forced to use the IP to access
it. Meaning, if your computer is called Sam, you won't be able to access
Sam from any other computer. You instead have to use 192.168.0.5 or
whatever it is in your case.

A quick fix I found is to open

 /etc/dhcp3/dhclient.conf

uncomment the line that says

 #send host-name HOSTNAME;

and change HOSTNAME into whatever you want. It's probably a good idea to
make it the same as your computer's name :).

One possible solution is to have the installer configure dhclient.conf
correctly, and then to change it whenever you change your hostname.
Maybe dhclient.conf can reference /etc/hostname ?

** Affects: dhcp3 (Ubuntu)
 Importance: Undecided
 Status: Unconfirmed

-- 
dhclient doesn't tell the router the computer's hostname by default
https://launchpad.net/bugs/69207

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 54826] Help-Release Notes thinks Dapper is version 6.04, and why is it in there anyway?

2006-08-01 Thread Cyphase
Public bug reported:

Binary package hint: firefox

When you click Help-Release Notes in Firefox, it takes you to
http://www.ubuntu.com/support/releasenotes604 , which doesn't exist. It
should be taking you to http://www.ubuntu.com/support/releasenotes606 ,
which does exist. Second, why is it in Firefox anyway? Shouldn't it be
in System-Help on the panel?

** Affects: firefox (Ubuntu)
 Importance: Untriaged
 Status: Unconfirmed

-- 
Help-Release Notes thinks Dapper is version 6.04, and why is it in there 
anyway?
https://launchpad.net/bugs/54826

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 54660] Package TrueCrypt for Ubuntu

2006-07-31 Thread Cyphase
Public bug reported:

TrueCrypt is an open-source disk encryption utility. It should be
packaged for Edgy Eft. http://www.truecrypt.org/

** Affects: Ubuntu
 Importance: Untriaged
 Status: Unconfirmed

-- 
Package TrueCrypt for Ubuntu
https://launchpad.net/bugs/54660

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs