[Bug 286017] and Gentoo developer's *behavior*

[Earthwings]

For that matter, why is the bug now restricted?

The bug reporter kept reopening the bug although being asked not to.

I didn't reopen it after it was asked.

You reopened it twenty minutes after flameeyes' "And I start to get quite pissed off by your insisting reopening this bug." comment.

[nico--]

What should maintainer do?

Leave the bug open.

[vasily_pupkin]

USE="-nano -emacs vim"

This is true *gentoo way* Is in't it?

This options or BUILDING, not for configuration. visudo have some resrictions with configuratio-when-building, This configuration setted up to stage-default. All ok

[energyman76b]

(By the way. I don't know anything about visudo till this morning, but i spend about 5 minutes to solve topicstarter's "problem". Is this really problem? )

I prefer when package maintainer spend 5 minute ONCE to do things work as expected, than
when 100000 users spend 5 minute (5*100000) on doing unnecessary job.

=============================================
!!! UPDATE !!!
You can see the copy of the ticket by yourself here:
http://www.rootshell.be/~spinal/gentoo_ ... 86017.html

gentoo is all about 'the user sets the stuff as he wants it' and you are complaining that you have to set something?

You know, there are distros for people like you, maybe you should have a look at ubuntu, fedora or opensuse?

what you want is to make all the non-vi users suffer because you can't be assed to set a simple one line option. Do you see the problem?

[nico--]

what you want is to make all the non-vi users suffer because you can't be assed to set a simple one line option. Do you see the problem?

The ebuild should give the user a warning (elog/ewarn) about setting the option when they don't have nano installed. I'm sure there are some non-vi users who don't have nano.

[energyman76b]

what you want is to make all the non-vi users suffer because you can't be assed to set a simple one line option. Do you see the problem?

The ebuild should give the user a warning (elog/ewarn) about setting the option when they don't have nano installed. I'm sure there are some non-vi users who don't have nano.

first time they try visudo, they get an error, they set EDITOR, everything is fine.

[nico--]

first time they try visudo, they get an error, they set EDITOR, everything is fine.

Setting EDITOR does not work, that's why nano is hardcoded in the ebuild to begin with.

[energyman76b]

first time they try visudo, they get an error, they set EDITOR, everything is fine.

Setting EDITOR does not work, that's why nano is hardcoded in the ebuild to begin with.

as several people in the very long email list thread have written, setting EDITOR works just fine.

[vasily_pupkin]

Setting EDITOR does not work, that's why nano is hardcoded in the ebuild to begin with.

RTFM

[Spinal_by]

Latest news...

1) Here's a copy (just a copy, all links are useless) of bug report done by me.
I was forced to copy that page to hosting because package maintainer restricted
access to users who began to vote for this bug.
+===============================================+
| http://www.rootshell.be/~spinal/gentoo_ ... 86017.html |
+===============================================+
2) Here's a link for the patch, that I attached to the ticket in my last post:
+======================================================+
| http://www.rootshell.be/~spinal/gentoo_ ... illa.patch |
+======================================================+
3) And now the most interesting. I was banned by maintainer. Now I cannot
access the ticket too.
======================================
Access Denied
You are not authorized to access bug #286017.
Please press Back and try again.
======================================

I think the maintainer was not aware about the bug report was copied to the
hosting and about my posts in mail-list.
I didn't reopen bug, I just made post, concluding what was suggested in mail-list
and attached a patch. Then I was just kicked of the ticket (I'm the ticket creator).

Any ideas?..

[desultory]

I didn't reopen bug, I just made post, concluding what was suggested in mail-list
and attached a patch. Then I was just kicked of the ticket (I'm the ticket creator).

Which reopened the bug.

[Spinal_by]

I didn't reopen bug, I just made post, concluding what was suggested in mail-list
and attached a patch. Then I was just kicked of the ticket (I'm the ticket creator).

Which reopened the bug.

To reopen the bug, one should choose the option "Reopen the bug" or may leave "Resolved as CANTFIX".
I didn't choose "Reopen the bug" and "Resolved as CANTFIX" radiobutton left checked.
So he just got my reply with the patch attached. The bug was not reopened.

P.S. Did you visit the link? It's obviously seen there, just next to button "Commit"
http://www.rootshell.be/~spinal/gentoo_ ... 86017.html

[brezblock]

I didn't reopen bug, I just made post, concluding what was suggested in mail-list
and attached a patch. Then I was just kicked of the ticket (I'm the ticket creator).

Which reopened the bug.

Sorry, do you read http://www.rootshell.be/~spinal/gentoo_ ... 86017.html ?

[jw5801]

...
Anyway, I realise that this thread is not in fact about the 'bug', but more about flameeyes. So I'll say that everything I've seen of him has been positive, so this is unusual and I'm sure there was a valid reason (whether it was something you did, or otherwise), so cut him a bit of slack and don't take it to heart.

------- Comment #4 From Diego E. 'Flameeyes' Pettenò 2009-09-24 21:39:05 0000 [reply] -------

This would require having an "editor" script and an eselect editor module, but
I really don't want to start with this myself…


------- Comment #5 From Arthur Demchenkov 2009-09-28 19:34:46 0000 [reply] -------

To Diego E. 'Flameeyes' Pettenò:
That was funny, closing that ticket as CANTFIX.

What about changing the string in ebuild:
--with-editor=/bin/nano
to something like this:
--with-editor="${EDITOR}"

Could you please forward the ticket to someone who can make decisions?
Thank you.

Ah look, a valid reason.

The tone before your comment here (#5) was quite friendly and constructive all around. Your suggestion in this comment is also probably valid and helpful, however you've also denigrated into sarcasm and base insults. I think if you want to complain about `*behaviour*', you should look at your own. The tone of this comment is completely uncalled for, and almost certainly is the cause of the later comment from flameeyes which you opened this thread to complain about.

To summarise:

• Nano is the default Gentoo editor, if you don't like it, change it. Given that sudo requires something to be hardcoded as a default, obviously the default editor will be used.
• To gracefully solve this without opening security vulnerabilities would require much work, which this developer was not willing to put in. Instead of offering to maybe assist with this work, or proposing a simpler solution, you responded with sarcasm and insults.
• The discontent evoked by this comment meant that any subsequent useful contributions were ignored.

[gentoo-dev]

Okay. Now I'm seriously *tired* and *pissed off* and I'm going to say "bye" to
politically correctness and politeness.

If I hear one of you _again_ come up with "the Gentoo Way" *while not being a
Gentoo developer*, I'm going to ask for your bugzilla account to be locked
down.

I'm _not_ going to change this behaviour. Full stop.
Sudo wants a default (which the admin can change in the configuration file),
and that default is _the same as provided in baselayout!_ The same editor that
_is installed with the damn stages_.

You want to change it? You change it with EXTRA_ECONF.

Is it normal Gentoo developer's behaviour pattern?
Is it fair for *god* Gentoo developer just allow to knock off from community *mortal* users??
Is it fair to restrict community from discuss bugs and it's solution???

Normal, no, definitely typical though.
Gentoo decided to change upsteam's hardcoded value without taking the required steps to make sure it would not trigger any problems. Bad, Gentoo, naughty, naughty...

[Anon-E-moose]

I also ran into this issue yesterday. It would be nice if the ebuild at least printed a warning for those of us who don't have /bin/nano.

why?

even if you don't have nano - when you set up EDITOR correctly, visudo will use whatever editor you want it to use.

It will not make use of it without extra configuration.

Um, yes it will. It pays attention to the EDITOR, I changed it on the fly and it called up whatever editor I had it set to.

As far as flameeyes behavior, I saw some of the "bug" discussion before it got locked and he had good reason for his attitude, IMO.
That is all that I will say on that.

[nico--]

as several people in the very long email list thread have written, setting EDITOR works just fine.

According to the man page for visudo(8):

There is a hard-coded list of editors that visudo will use set at compile-time that may be overridden via the editor sudoers Default variable. This list defaults to the path to vi(1) on your system, as determined by the configure script. Normally, visudo does not honor the VISUAL or EDITOR environment variables unless they contain an editor in the aforementioned editors list.

and in sudo(8):

By default, the env_reset sudoers option is enabled. This causes commands to be executed with a minimal environment containing TERM, PATH, HOME, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process permitted by the env_check and env_keep sudoers options.

[Anon-E-moose]

That's just plain incorrect. At least on my system anyway. The only place I've ever set EDITOR is in /etc/rc.conf. I rarely ever actually use sudo and haven't changed any of it's default settings, yet visudo opens emacs, not nano.

Try running "sudo visudo", that's what all this started with.

Ah, I see. Well, it makes sense that sudo should drop the EDITOR variable.

If you want to keep your environ then "sudo -E visudo" should be being used.

This is not a visudo problem, nor a sudo problem, it was the original poster not understanding how they work.

[jw5801]

I also ran into this issue yesterday. It would be nice if the ebuild at least printed a warning for those of us who don't have /bin/nano.

why?

even if you don't have nano - when you set up EDITOR correctly, visudo will use whatever editor you want it to use.

It will not make use of it without extra configuration.

Um, yes it will. It pays attention to the EDITOR, I changed it on the fly and it called up whatever editor I had it set to.

As far as flameeyes behavior, I saw some of the "bug" discussion before it got locked and he had good reason for his attitude, IMO.
That is all that I will say on that.

That's not entirely correct, but the problem is not related to visudo in particular, it's related to sudo. When you run `sudo <anything>' it drops most of the environment (unless you tell it not to in /etc/sudoers), otherwise you could set the EDITOR variable to whatever you wanted, then run a command that executes it and essentially run whatever you wanted to with sudo. It therefore defaults to firstly whatever environment variables are set in /etc/sudoers (which would be the simplest way to fix this problem) and secondly to whatever is hardcoded at build time.

[Anon-E-moose]

first time they try visudo, they get an error, they set EDITOR, everything is fine.

Setting EDITOR does not work, that's why nano is hardcoded in the ebuild to begin with.

Setting EDITOR does work, as I said earlier use "sudo -E visudo" or try and RTFM.

And you are giving a fine example of why flameeyes got so upset.

[Anon-E-moose]

I also ran into this issue yesterday. It would be nice if the ebuild at least printed a warning for those of us who don't have /bin/nano.

why?

even if you don't have nano - when you set up EDITOR correctly, visudo will use whatever editor you want it to use.

It will not make use of it without extra configuration.

Um, yes it will. It pays attention to the EDITOR, I changed it on the fly and it called up whatever editor I had it set to.

As far as flameeyes behavior, I saw some of the "bug" discussion before it got locked and he had good reason for his attitude, IMO.
That is all that I will say on that.

That's not entirely correct, but the problem is not related to visudo in particular, it's related to sudo. When you run `sudo <anything>' it drops most of the environment (unless you tell it not to in /etc/sudoers), otherwise you could set the EDITOR variable to whatever you wanted, then run a command that executes it and essentially run whatever you wanted to with sudo. It therefore defaults to firstly whatever environment variables are set in /etc/sudoers (which would be the simplest way to fix this problem) and secondly to whatever is hardcoded at build time.

Yes, it is correct if you use the "-E" option with sudo. It will use your EDITOR setting, from your environment.

"sudo visudo" uses nano
"sudo -E visudo" uses vim which is what my EDITOR is set to.


Edit to add:
I just set EDITOR, FCEDIT and VISUAL to "cat"
did "sudo -E visudo"
and no editor was invoked, it simply "catted" the file.

The man page for visudo says that "VISUAL" is used first and if not set then "EDITOR" is used.
But as my test showed, it will work with a non-editor if you wanted it to.

[nico--]

as I said earlier use "sudo -E visudo" or try and RTFM.

And you are giving a fine example of why flameeyes got so upset.

I'm sorry for not using my time machine before posting.

TFM says vi is the default for visudo and sudo doesn't depend on nano. I upgraded it the day after I removed some files from /etc, so I assumed I had broken a configuration file. nano isn't mentioned anywhere except the ebuild and its changelog, which were the last places I checked.

[Anon-E-moose]

Visudo and sudo behave as they always have.
The complaint about "changed behavior" is just dead wrong.

---

Gentoo compiled it this way, from the ebuild.

# XXX: /bin/vi may not be available, make nano visudo's default.
econf --with-secure-path="${ROOTPATH}" \
--with-editor=/bin/nano \
--with-env-editor \

---

From the visudo man page:

There is a hard-coded list of editors that visudo will use set at compile-time that
may be overridden via the editor sudoers Default variable. This list defaults to
the path to vi(1) on your system, as determined by the configure script. Normally,
visudo does not honor the VISUAL or EDITOR environment variables unless they
contain an editor in the aforementioned editors list. However, if visudo is
configured with the --with-enveditor option or the env_editor Default variable is
set in sudoers, visudo will use any the editor defines by VISUAL or EDITOR. Note
that this can be a security hole since it allows the user to execute any program
they wish simply by setting VISUAL or EDITOR.

---

and as I and others have shown, using the "-E" option on sudo will make it do what you want, again in the man pages.

Have a great day/night.

[Naib]

Code: Select all

FluidMotion naib # visudo &
[1] 31902
FluidMotion naib # ps
  PID TTY          TIME CMD
31891 pts/1    00:00:00 su
31894 pts/1    00:00:00 bash
31902 pts/1    00:00:00 visudo
31903 pts/1    00:00:00 vim
31904 pts/1    00:00:00 ps

[1]+  Stopped                 visudo
FluidMotion naib # echo $EDITOR
/usr/bin/vim

NOTE the vim process (which is spawned by visudo) as well as the EDITOR variable is populated
Likewise the instalation handbook (section 8.c. System Information)

As you can see, this file is well commented to help you set up the necessary configuration variables. You can configure your system to use unicode and define your default editor and your display manager (like gdm or kdm).

/THREAD

[Spinal_by]

Code: Select all

FluidMotion naib # visudo &
[1] 31902
FluidMotion naib # ps
  PID TTY          TIME CMD
31891 pts/1    00:00:00 su
31894 pts/1    00:00:00 bash
31902 pts/1    00:00:00 visudo
31903 pts/1    00:00:00 vim
31904 pts/1    00:00:00 ps

[1]+  Stopped                 visudo
FluidMotion naib # echo $EDITOR
/usr/bin/vim

NOTE the vim process (which is spawned by visudo) as well as the EDITOR variable is populated
Likewise the instalation handbook (section 8.c. System Information)

As you can see, this file is well commented to help you set up the necessary configuration variables. You can configure your system to use unicode and define your default editor and your display manager (like gdm or kdm).

/THREAD

Looks like you can't read.
Do you understand what are we speaking about?
You can find the information you are not aware about here:
http://www.rootshell.be/~spinal/gentoo_ ... 86017.html

Specially for you, running "sudo visudo" is something different from running visudo being root...