from the ``7z'' tools own manpage [code]man 7z[/code]
[quote]
Backup and limitations
DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :
- 7-zip does not store the owner/group of the file.
[/quote]
--
7z support under Ubuntu (and other Linux distros) is terrible
I can confirm similar behavior on Hardy Alpha6 to what's shown above,
_but_ I say that there is no bug here.
The behavior stems from the fact that the hostname is preset in 3 locations:
1. "/etc/hosts" 2. "/etc/hostname" which, in turn, sets the precedent for 3.
The kernel itself and/or "the Envi
Sorry for the double-post, but in a more direct response to the YELLING
in the topic:
If sudo behaved differently, it would become vulnerable to some sort of
`HOSTNAME=foobar sudo ...` attack.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/3
@Martin
> $ sudo true
> sudo: unable to resolve host pickles
^^ This is where sudo was broken. I can re-run the test using `sudo id` when I
get back to my Hardy box;
But, again, I feel there is no bug here:
Not being able to resolve the local hostname is a broken and unsupportable
state for any
> But consider there is a different behavior in hardy compared to previous
> releases (e.g. gutsy)
> where a different hostname in /etc/hostname and /etc/hosts is accepted
accepted by `sudo` or accepted "in general" ??
I can get away with that on my Gutsy box, but it _is_ a misconfiguration and
@Dorin
> Perhaps sudo should try to use the name from /etc/hostname when gethostbyname
> fails?
> It looks quite simple to do that, and assume that you'll have there 127:0.0.1
> (in both IPv4 and v6)?!?!?!
You seem to be confused.
That's _exactly_ what `sudo` is doing: it's using the known _loc
Public bug reported:
Binary package hint: gnome-system-tools
This is still a problem up through Ubuntu 8.04 HardyAlpha6.
`services-admin` improperly deletes soft links to startup scripts as
opposed to changing them to "kill scripts" ...
quoted from the `update-rc.d` manpage:
> A common system
oops, that url in the report is the wrong one ...
This bug, in turn, leads to https://bugs.launchpad.net/ubuntu/+source
/gnome-system-tools/+bug/69799
Also related to https://bugs.launchpad.net/ubuntu/+source/gnome-system-
tools/+bug/174502
--
[services-admin] Gnome services tool is NOT sysV co
edited description to fix the "oops."
** Description changed:
Binary package hint: gnome-system-tools
This is still a problem up through Ubuntu 8.04 HardyAlpha6.
`services-admin` improperly deletes soft links to startup scripts as
opposed to changing them to "kill scripts" ...
> I actually am certain that raising privileges on the local machine should not
> require networking bits at all.
> There is no real reason why that should be done. No real dependency of the
> network,
> unlike the X system that is actually meant and thought for networking.
In your own terms: T
I just stumbled on this bug. Bug #1292168 from me is related but not
duplicate. I felt that I needed to pull over my related comments from
there:
["lower" functionality] always *should* have been a part of the standard
window menu so let's go ahead and have it in there. Secondly, if right
click [t
Pardon the double post but this is a separate thought:
The standard window actions menu or alt+space menu has "always" been
available and "always" will in my perfect world by alt+rightclick
_anywhere_ on a window. Anecdotally, this has been my preferred method
for accessing Always on top/Move Work
I could not easily find this workaround from a google search so
documenting it here:
Typical "use with caution" notice, may cause a (small) rift in the
space-time continuum, etc.
Edit /lib/udev/rules.d/95-upower-csr.rules (with sudo), comment out
(with #) the last set of lines at the bottom so th
Honestly, I don't see why middle click should function on inactive
launchers by default but not the wheel. But as long as long as it can be
turned on somehow I'll be a happy camper.
The use case for this that I think those of us who like it have caught
on to without realizing it is that it doesn't
Somewhere between that last post and inspecting the behavior very
closely and actually looking at the code, I changed my tune. The
existing scroll up and down mixed behavior was very strange for 3+ open
windows. I created bug #1286784 for this issue.
I'm still for the working on unfocused app scen
I took a stab at this one...
Reverted the AppLauncherIcon to the earlier state that will grab focus
if it gets the scroll event, and changed Launcher itself to check its
new setting activate_on_scroll to decide if the event should even be
sent. New option is exposed at the bottom of the CCSM Unity
I've been running on the code pulled from the bzr branch since yesterday
and it seems like it's never working after I log out and back in. The
box is still checked in CCSM but after I un-check and re-check it's
working again. Can anyone confirm? (and/or have I borked my dconf :P)
--
You received
For those who google this, the quick fix to turn this on in a terminal without
CCSM is
[code]dconf write
/org/compiz/profiles/unity/plugins/unityshell/scroll-inactive-icons true[/code]
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: hud
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1278720
Title:
Libreoffice HUD entries are unresponsive
To manage notifications about
Related or duplicate: Bug #1291838
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1291407
Title:
shadows for application names in sidebar are showing shadow edges
To manage notifications about this
Related or duplicate: Bug #1291407
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1291838
Title:
[regression] Wrong Launcher tooltips decorations/shadows
To manage notifications about this bug go to
This is bug-ish behavior within Expo itself. It can be reproduced
without ever clicking the workspace launcher. You can click anywhere on
the screen immediately after Super+s and Expo will switch straight back
to the workspace nearest to the click, sometimes dragging windows along
with it unpredict
Hard to find but easy to patch :D.
It should be noted that this further breaks user configurability of
click actions. But these settings seem to already be ignored in Unity
lately with or without LIM.
** Patch added: "Quick fix - Lower action is hardcoded in."
https://bugs.launchpad.net/ubunt
Another thought about the patch, perhaps the function should explicitly
return after a call to lower? Changing the "else if" button != 1 to just
"if" would catch all cases and return just in case.
And a positive note about the "further breakage" - as is this does at
least provide complete consiste
I too find this new "corrected" behavior a big break in my workflow.
Bring it back please! Or add a toggle option for powerusers who can
control their own wheels and are not confused by the UI actually
reacting to inputs.
This whatever scroll up does scroll down should undo is nonsense.
Right-cl
"so we are looking in to adding a setting to restore the old behavior."
I only regret that I have but 2 thumbs to put up for this option.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1267888
Title:
26 matches
Mail list logo
