[Bug 1315434] Re: Mouse with no time remaining estimate showing in preference to battery being charged
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 that it's left like
this:
# Unifying HID++ devices
#SUBSYSTEM!=hid, GOTO=up_unifying_end
#ATTRS{idVendor}==046d, ENV{UPOWER_VENDOR}=Logitech, Inc.
#ATTRS{idVendor}==046d, ATTRS{idProduct}==c52b,
DRIVER==logitech-djdevice, ENV{UPOWER_BATTERY_TYPE}=unifying
#ATTRS{idVendor}==046d, ATTRS{idProduct}==c532,
DRIVER==logitech-djdevice, ENV{UPOWER_BATTERY_TYPE}=unifying
#ATTRS{idVendor}==046d, ATTRS{idProduct}==c52f,
ENV{UPOWER_BATTERY_TYPE}=lg-wireless
LABEL=up_unifying_end
^Everything commented out but that last LABEL.
On the next reboot, UPower will completely ignore these Unifying
devices!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1315434
Title:
Mouse with no time remaining estimate showing in preference to battery
being charged
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1315434/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 656519] Re: Window management - Alt+Space window accessibility menu should not be accessible by right clicking on a window title bar
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 [the title bar] does not expose this menu because of LIM/Indicator consistency, then let's just go ahead and bring back the window menu as a standard part of every window decoration. I'm thinking it will replace/obsolete the always visible minimize/maximize buttons and will integrate seamlessly with LIM such that opening the window menu and then mousing right will move right on to File, Edit, View, etc. This would add a further layer of consistency for windows that do not support resizing or maximizing. As is, the dedicated maximize button on them can be taken away leading to slight inconsistency in window decoration, but with a window menu instead it will always be there and will simply have the options inside greyed if the window does not support them. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/656519 Title: Window management - Alt+Space window accessibility menu should not be accessible by right clicking on a window title bar To manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/656519/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 656519] Re: Window management - Alt+Space window accessibility menu should not be accessible by right clicking on a window title bar
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 Workspace/etc. for quite a while now to eliminate the need to hit the smaller target of just the titlebar. I would note that this is not a pure mouse option though. But on top of that I support Gobal Menus and LIM moving on to accept any click. And on top of that I still would hope never to remove a pure mouse solution. So that brings me back to the good old window menu button again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/656519 Title: Window management - Alt+Space window accessibility menu should not be accessible by right clicking on a window title bar To manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/656519/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1283849] Re: LIM breaks middle click title bar
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/ubuntu/+source/unity/+bug/1283849/+attachment/4038463/+files/lp1283849.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1283849 Title: LIM breaks middle click title bar To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1283849/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1283849] Re: LIM breaks middle click title bar
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 consistency with LIM vs. not and maximized vs not. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1283849 Title: LIM breaks middle click title bar To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1283849/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1026553] Re: Double clicking Workspace Switcher too fast switches workspaces and moves windows unpredictably
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 unpredictably. A slight improvement that might be achievable is if the Workspace Launcher can block Expo from receiving clicks. But the bug still lies with Expo willing to process clicks during unpredictable animation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1026553 Title: Double clicking Workspace Switcher too fast switches workspaces and moves windows unpredictably To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1026553/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1291407] Re: shadows for application names in sidebar are showing shadow edges
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 bug go to: https://bugs.launchpad.net/unity/+bug/1291407/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1291838] Re: [regression] Wrong Launcher tooltips decorations/shadows
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: https://bugs.launchpad.net/unity/+bug/1291838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1278720] Re: Libreoffice HUD entries are unresponsive
** 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 this bug go to: https://bugs.launchpad.net/hud/+bug/1278720/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288957] Re: Add option to restore behavior of using mouse scrollwheel to focus app windows
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. https://bugs.launchpad.net/bugs/1288957 Title: Add option to restore behavior of using mouse scrollwheel to focus app windows To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1288957/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288957] Re: Add option to restore behavior of using mouse scrollwheel to focus app windows
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 this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288957 Title: Add option to restore behavior of using mouse scrollwheel to focus app windows To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1288957/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288957] Re: Add option to restore behavior of using mouse scrollwheel to focus app windows
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 Launcher tab. ** Patch added: lp1288957.patch https://bugs.launchpad.net/unity/+bug/1288957/+attachment/4014606/+files/lp1288957.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288957 Title: Add option to restore behavior of using mouse scrollwheel to focus app windows To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1288957/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288957] Re: Add option to restore behavior of using mouse scrollwheel to focus app windows
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 require the mouse to come to a complete stop to activate. Actually clicking with a moving mouse of course initiates a drag operation; but with the wheel selection you can just keep right on moving. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288957 Title: Add option to restore behavior of using mouse scrollwheel to focus app windows To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1288957/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1263786] Re: Nonsense behavior of scrollwheel over Launcher
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 scenarios, but the scroll up and down mixture needed a little work in all scenarios. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1263786 Title: Nonsense behavior of scrollwheel over Launcher To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1263786/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1263786] Re: Nonsense behavior of scrollwheel over Launcher
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-clicking a laucher icon has the same effect whether the app is focused or not. Mid-clicking a launcher icon has the same effect whether the app is focused or not. Scrolling a launcher icon _should_ have the same effect whether the app is focused or not. I believe I shall file a new bug later with more detail on this issue and the use cases that are now broken. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1263786 Title: Nonsense behavior of scrollwheel over Launcher To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1263786/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1267888] Re: Using mouse scrollwheel on unfocused/inactive Launcher icons should not focus that app
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: Using mouse scrollwheel on unfocused/inactive Launcher icons should not focus that app To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1267888/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 123038] Re: 7z support under Ubuntu (and other Linux distros) is terrible
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 https://bugs.launchpad.net/bugs/123038 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 204090] Re: [services-admin] Gnome services tool is NOT sysV compliant
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 ... quoted from the `update-rc.d` manpage: A common system administration error is to delete the links with the thought that this will disable the service ... The correct way to disable services is to configure the service as stopped in all runlevels in which it is started by default. In the System V init system this means renaming the service’s symbolic links from S to K. - This bug, in turn, leads to https://bugs.launchpad.net/ubuntu/+bug/24874 + This bug, in turn, leads to https://bugs.launchpad.net/bugs/69799 Maybe there should be something in the Hardy Release Notes about `bum` being a much more suitable services config tool. -- [services-admin] Gnome services tool is NOT sysV compliant https://bugs.launchpad.net/bugs/204090 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 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
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: The `sudo` system _IS_ meant and thought for networking! And even so, resolving the _LOCAL_ hostname is not networking bits. And once again, my point of view: raising privileges on the LOCAL machine should NOT require networking bits. NEVER. You are willfully ignorant of and blurring the line between _LOCAL_ hostname and networking bits. The _LOCAL_ hostname _IS_ mandatory and does not constitute networking bits. Of course it is no bug in the sense that it breaks any specified contract, but ubuntu does not have a password for root and sudo is the only way to repair a wrong /etc/hosts. Precisely, I say that this non- bug can be closed/resolved/cancelled! Discussion of repairing the _local_ hostname configuration is already here: https://bugs.launchpad.net/ubuntu/+source/rescue/+bug/19553 -- sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://bugs.launchpad.net/bugs/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
@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 _local_ hostname which would've been set in /etc/hostname. It has to resolve this _local_ hostname and does so with the _local_ /etc/hosts file. gnome-terminal is simply broken if it needs to resolve any kind of hostname during startup. you are aware that the X Window System is a client-server setup over the loopback interface aren't you?!? Apps should _always_ be able to resolve the _local_ hostname and some have come to rely on this fact. @everyone *_There is no bug here_* The original bug reporter in the _blog_ overwrote his /etc/hosts file and in doing so broke his _local_ host configuration. `sudo` errors were merely the first symptom he noticed of his newly broken system. *_To prove that something is wrong with sudo_* you would need to show a situation where `sudo` does _not_ work but the following does: ~$ grep `hostname` /etc/hosts ***Revised Proof: Same machine, 2 terminals; root breaks and fixes the system; asmoore tests sudo: - [EMAIL PROTECTED]:~$ grep `hostname` /etc/hosts 127.0.1.1 pickles [EMAIL PROTECTED]:~$ sudo id [sudo] password for asmoore: uid=0(root) gid=0(root) groups=0(root) [EMAIL PROTECTED]:~$ sudo -k [EMAIL PROTECTED]:~# sed -i s/pickles/foobar/g /etc/hosts [EMAIL PROTECTED]:~$ grep `hostname` /etc/hosts [EMAIL PROTECTED]:~$ sudo id sudo: unable to resolve host pickles [EMAIL PROTECTED]:~$ sudo -k sudo: unable to resolve host pickles [EMAIL PROTECTED]:~# hostname foobar [EMAIL PROTECTED]:~$ grep `hostname` /etc/hosts 127.0.1.1 foobar [EMAIL PROTECTED]:~$ sudo id [sudo] password for asmoore: uid=0(root) gid=0(root) groups=0(root) [EMAIL PROTECTED]:~$ sudo -k [EMAIL PROTECTED]:~# hostname `cat /etc/hostname` [EMAIL PROTECTED]:~# sed -i s/foobar/pickles/g /etc/hosts [EMAIL PROTECTED]:~$ grep `hostname` /etc/hosts 127.0.1.1 pickles [EMAIL PROTECTED]:~$ sudo id [sudo] password for asmoore: uid=0(root) gid=0(root) groups=0(root) [EMAIL PROTECTED]:~$ sudo -k - Adam sM -- sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://bugs.launchpad.net/bugs/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 204090] [NEW] [services-admin] Gnome services tool is NOT sysV compliant
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 administration error is to delete the links with the thought that this will disable the service ... The correct way to disable services is to configure the service as stopped in all runlevels in which it is started by default. In the System V init system this means renaming the service’s symbolic links from S to K. This bug, in turn, leads to https://bugs.launchpad.net/ubuntu/+bug/24874 Maybe there should be something in the Hardy Release Notes about `bum` being a much more suitable services config tool. ** Affects: gnome-system-tools (Ubuntu) Importance: Undecided Status: New -- [services-admin] Gnome services tool is NOT sysV compliant https://bugs.launchpad.net/bugs/204090 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 204090] Re: [services-admin] Gnome services tool is NOT sysV compliant
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 compliant https://bugs.launchpad.net/bugs/204090 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 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
@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 *X system. -- sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://bugs.launchpad.net/bugs/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
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 causes certain programs(such as `gnome-terminal`) to take much longer to open. -- sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://bugs.launchpad.net/bugs/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
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 Environment If you change the hostname from within the `network-admin` tool, you have no issues with `sudo` _and_ the tool warns you that your system will be in an inconsistent state until the next reboot. Steps to confirm the lack of a bug: I, too, use 2 terminals, 1 in a `sudo -s` session as a failsafe and a second to test for breakage of `sudo` in general. The commands are posted in the order I execute them and you can use the leading '$' or '#' to distinguish between the 2 terminals: - # hostname pickles $ sudo true [sudo] password for asmoore: $ sudo -k # sed -i s/pickles/foobar/g /etc/hosts $ sudo true sudo: unable to resolve host pickles # hostname foobar $ sudo -k $ sudo true [sudo] password for asmoore: - Observe that `sudo` went from working, to broken, to working again as I restored the system to a semi-consistent state by having `hostname` and /etc/hosts agree. Note that, had I rebooted right after, `sudo` and many other things would've been broken again because /etc/hosts and /etc/hostname do _not_ agree; this, too, is _not_ a bug. The original bug reporter needs to understand that: 1. His system is broken simply because he broke it. 2. Freedom means free to do anything, even if it is destructive. 3. A blog post does not a bug report make. IMHO, this bug report is akin to `sudo rm -rf` hosed my system! Adam sM, ubuntuforums.org member, my first launchpad.net posting. -- sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://bugs.launchpad.net/bugs/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 32906] Re: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
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/32906 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
