I did not experience the bug last time I tried in jaunty. I'd say it is
fixed.
On Tue, Jun 23, 2009 at 6:33 PM, Robert
Ancellrobert.anc...@canonical.com wrote:
Thank you for taking the time to report this bug and helping to make
Ubuntu better. You reported this bug a while ago and there hasn't
An example archive.
** Attachment added: sunny.blend1
http://launchpadlibrarian.net/21662951/sunny.blend1
--
File roller only extracts files if they have the correct extension, despite
mimetype.
https://bugs.launchpad.net/bugs/318157
You received this bug notification because you are a
By example, do you mean a screenshot?
On Tue, Jan 20, 2009 at 8:27 AM, Pedro Villavicencio pe...@ubuntu.com wrote:
thanks for the report, may you please attach an example to the report?
thanks in advance.
** Changed in: file-roller (Ubuntu)
Importance: Undecided = Low
Assignee:
Blender doesn't set the right magic bytes at the beginning of an
compressed backup (I think). The freedesktop spec for MIME
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-
info-spec-0.11.html indicates that more specialised files should have
higher priority (Unified system:The
Public bug reported:
I have only seen this with one of my .blend1 (backup) files, and I have
only seen it in nautilus, although I've yet to try it with other file
managers. In addition to being read as a gzip that could not be
extracted, the file was displayed with a package/archive icon.
The representations were correct in nautilus, the backup was compressed.
The actual problem was that file roller did not accept the input of the
file without the file extension gz, even though it had the correct
(sorry) mimetype.
** Changed in: file-roller (Ubuntu)
Sourcepackagename: nautilus =
** Summary changed:
- Nautilus shows application/x-gzip mimetype for .blend file
+ File roller only extracts files if they have the correct extension, despite
mimetype.
** Description changed:
- I have only seen this with one of my .blend1 (backup) files, and I have
- only seen it in nautilus,
I forgot to mention that this also happens with the default
CtrlAltDown key binding if the ctrl and alt are on the right side of
the keyboard. And I believe something similar happened with the
metacity pager also, but I am no longer certain.
--
SuperDown keybinding doesn't unwrap cube in
Public bug reported:
When using the Super key and Down key as the binding for workspace
switching or for unwrapping the cube in compiz, the action begins but
then reverts to a state where it was like I had not pressed the keys.
For instance if I press Super + Down the cube begins to go to the
Public bug reported:
It has happened no less than three times that my system has suddenly
frozen after about 2 to 3 minutes after resuming system operation after
a command to sleep or suspend. When it happens a part of the screen's
image is tiled repeatedly across my monitor screen.
When it
10 matches
Mail list logo
