sw_vers hangs during a build

[richard.t.lloyd@…]

Working from a clean disk (no macports remnants from previous) I did:

1. cd MacPorts-2.0.4 && ./configure && make && sudo make install

2. sudo port install gettext

All goes fine installing the 4 dependencies expat, libiconv, gperf, and ncurses. The problem is with gettext itself.

The build sequence hangs at: ---> Configuring gettext. It doesn't return, at least not for 4+ hours, which is this programmer's equivalent to never.

Attempting to understand what's happening I've looked at the MacPorts main.log as well as the various config.log files inside gettext. The last active point seems to be in gettext-runtime.

I've attached main.log, gettext/config.log, and gettext-runtime/config.log as well as the screen output.

Let me know if you need anything else.

[richard.t.lloyd@…]

stdout from port install gettext

[richard.t.lloyd@…]

the macports gettext main.log

[richard.t.lloyd@…]

gettext-0.18.1.1/config.log

[richard.t.lloyd@…]

gettext-0.18.1.1/gettext-runtime/config.log

[ryandesign (Ryan Carsten Schmidt)]

Certainly try MacPorts 2.1.0 beta 1 instead of 2.0.4. But if that doesn't work, you'll have to figure it out yourself, or wait until we have access to OS X 10.8 and Xcode 4.4 (i.e. when final versions are released to the public); either by then whatever the problem is will have been fixed by Apple or the developers gettext, or we'll be able to look into it further then.

[skymoo (Adam Mercer)]

Have you installed Java? If not try to run "javac" from the terminal and you should get prompted to download and install java I imagine this is the problem

[jeremyhu (Jeremy Huddleston Sequoia)]

It's been building fine for me for the past year or so... I've currently got gettext-0.18.1.1_2+universal.darwin_12.i386-x86_64.tbz2

All of your logs are truncated. We can't do anything without a real (complete) log.

[jeremyhu (Jeremy Huddleston Sequoia)]

If it's hung, you may have a bigger issue completely unrelated to gettext, and you're just hitting it in gettext because gettext is a dependency of pretty much everything...

Run 'sudo sysdiagnose' and email me the tarball. I'll take a look at it.

Do not discuss this in a public forum as doing so violates your NDA.

[richard.t.lloyd@…]

Problem solved. Turns out to have been a problem with javac. At some point during the flash security dance I seem to have gotten an incomplete install.

It took all day but I now have a 10.8 Build 12A193i system that can install gettext under MacPorts-2.0.4.

thanks for your help

[eirnym (Eir Nym)]

I've installed Mac OS X 10.8 & xcode 4.4 recently and fully uninstall all installed ports via macports. I have same problem at same point (with javac)

How has you fixed your problem?

$ javac -version
javac 1.6.0_33
$ port version
Version: 2.1.2
gettext-0.18.1.1

[codewranglers@…]

Cc Me!

[codewranglers@…]

Replying to codewranglers@…:

Cc Me!

Same problem here: Install of OS X 10.8 (12A269), Xcode 4.4, port 2.1.2. gettext-runtime's configure run hangs forever at javac.

[platon@…]

Cc Me!

[platon@…]

Cc Me!

[platon@…]

Cc Me!

[platon@…]

gettext main.log

[platon@…]

Replying to platon@…:

Cc Me!

Same problem here.

When I do the commands shown after “:debug:configure Executing command line:” in the main.log manually, configure does not stop but seems to work. I can do a “make install” afterwards without getting an error. Unfortunately, MacPorts does still not consider gettext installed. Doing “port install gettext” afterwards still shows the same pathological behavior.

[richard.t.lloyd@…]

As I reported about 3 months back, my problem was a damaged javac install. I'm not sure how or why it was damaged but I suspect I probably did it during my somewhat erratic effort to learn the install process with 10.8.

The fix for me was to backup my entire home directory (/Users/myself) on a separate drive and then do a full install of OSX and Xcode on a clean hard drive. I cleaned the drive using the 'boot from tools partition' that's available with 10.8.

If you don't know it, just reboot while holding Command-R and follow the path to the disk utility. Select your internal drive and reformat it - I didn't have the patience to wait for the 'most secure erase the contents' method but that effect the outcome. Then you can install OSX and Xcode from the App store and restore your home from the backup disk.

I am currently running:

OSX Version 10.8 Build 12A256 Xcode 4.5 DP 2 -- Version 4.5 (4G108j)

I just confirmed that gettext installs without a hitch using either MacPorts-2.1.2-10.8-MountainLion.pkg or MacPorts-2.1.2.tar.gz, both of which are currently available at the MacPorts Project --- Download & Installation page.

hope this helps

[garnould@…]

There is a workaround that permitted me to install gettext: kill the javac/java instances that are launched during install: # ps auxw | grep java => (get the PID) => # kill PID. You'll have about two or three java/javac instances to kill.

[tacliat@…]

On a whim I did a chmod u+s of the javac, java and jar binaries, since running configure worked as root. (this says run these binaries as root no matter which user executes them)

This solved the problem, so its something about the macports user is my guess.

FYI If you do use the chmod, after you are done building you can undo the change by running chmod u-s javac java jar

[eirnym (Eir Nym)]

Replying to richard.t.lloyd@…:

As I reported about 3 months back, my problem was a damaged javac install. I'm not sure how or why it was damaged but I suspect I probably did it during my somewhat erratic effort to learn the install process with 10.8.

The fix for me was to backup my entire home directory (/Users/myself) on a separate drive and then do a full install of OSX and Xcode on a clean hard drive. I cleaned the drive using the 'boot from tools partition' that's available with 10.8. [--%<-- cut content --%<--] hope this helps

You've reported that you have solved this, but haven't told how. I plan to do full reinstall, but it'll be in the future. ports provide some tools which I use in my work.

different java projects I have on computer had been successfully built with this javac and different arguments with no delays. (I've tested from maven, ant and ant with executing javac as system command.)

[eirnym (Eir Nym)]

Replying to garnould@…:

There is a workaround that permitted me to install gettext:....

Do you really know if gettext works correctly after this?

[codewranglers@…]

Replying to tacliat@…:

On a whim I did a chmod u+s of the javac, java and jar binaries, since running configure worked as root. (this says run these binaries as root no matter which user executes them)

This solved the problem, so its something about the macports user is my guess.

FYI If you do use the chmod, after you are done building you can undo the change by running chmod u-s javac java jar

The SetUID did the trick for me, too. Configure script took the stumbling block. Thanks for your creative thinking :)

But unfortunately a bit later in that configure run a bunch of errors turned up:

checking for sched_yield in -lposix4... no
configure: creating ./config.status
./configure: line 26835: ./config.status: Permission denied
./configure: line 26849: ./config.status: Permission denied
:
sed: stdout: Broken pipe
:
configure: error: write failure creating ./config.status
configure: error: ./configure failed for gettext-runtime
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gettext/gettext/work/gettext-0.18.1.1" && ./configure --prefix=/opt/local ac_cv_prog_AWK=/usr/bin/awk ac_cv_path_GREP=/usr/bin/grep ac_cv_path_SED=/usr/bin/sed --disable-csharp --disable-native-java --without-emacs --with-included-gettext --with-included-glib --with-included-libcroco --with-included-libxml --without-git --without-cvs 
Exit code: 1
Error: org.macports.configure for port gettext returned: configure failure: command execution failed
DEBUG: Error code: NONE
DEBUG: Backtrace: configure failure: command execution failed
    while executing
"$procedure $targetname"

Haven't figured out yet what the reason for that could be.

[neverpanic (Clemens Lang)]

codewranglers: Did you run configure as root manually between your attempts with macports? Anyway, clean gettext and try again.

[eirnym (Eir Nym)]

Replying to tacliat@…:

.... since running configure worked as root.....

I do port install only from root. Do I anything wrong? Should I separate this process? I have not configured macports to use separate user to configure/build/etc. So how it can helps if you run javac under root?

[codewranglers@…]

Replying to cal@…:

codewranglers: Did you run configure as root manually between your attempts with macports? Anyway, clean gettext and try again.

Yes I did that right now. With the java stuff running as root as well the configure script ran successfully.

[codewranglers@…]

All right, after wiping gettext I experienced a successful configure and build run of gettext. Like said before I set the uid bits for the java stuff and cleared them afterwards.

[platon@…]

Replying to richard.t.lloyd@…: richard.t.lloyd, I tried the fresh OS installation and it did nothing for me. Must have been some coincidence that it helped in your case.

However, the SUID trick for the java* executables did work for me.

So it seems to be a permission problem with some file system object that Java needs, but can't access as the “macports” user. I would guess that some part of the OS X distribution has faulty permissions, since in OS X 10.7 it still worked fine for me, and richard.t.lloyd's success with the 10.8 developer preview re-install might be explained that way (perms intermittently OK).

[platon@…]

Replying to platon@…:

BTW, I just found out that the same type of problem (with the same solution) exists with the “sw_vers” program (I experience this with the “python27” port). It works fine as long as you normally log in to some ID and then invoke sw_vers from the shell. But as soon as you “su” into another ID (from “root”) it hangs:

# “id” command, e.g., works:
$ su macports -c 'id'
uid=503(macports) gid=501(macports) groups=501(macports),12(everyone),61(localaccounts)
$ su macports -c 'sw_vers'
# (never returns...)

Note that for “su” to work this way, you have to set a login shell instead of /usr/bin/false.

[platon@…]

Replying to platon@…:

(Oops, sorry, hit that Submit button too early) This all seems to point to a problem with those new-fangled security gear (sandboxing & Co.) that Apple introduced with OS X 10.8. It's certainly not a problem in MacPorts or any individual software package. Until Apple fixes this, we're farked.

[BjarneDMat]

Cc Me!

[BjarneDMat]

the chmod u+s trick works for me too

is there any danger securitywise in keeping this setting permanently ?

[neverpanic (Clemens Lang)]

Replying to macintosh@…:

is there any danger securitywise in keeping this setting permanently ?

YES!

[richard.t.lloyd@…]

Replying to platon@…:

Replying to richard.t.lloyd@…: richard.t.lloyd, I tried the fresh OS installation and it did nothing for me. Must have been some coincidence that it helped in your case.

My problem was a failure during the OS install which could only be corrected by the clean / reinstall sequence. The versions of OSX, Xcode, MacPorts, and gettext were the same before and after the reinstall.

The only portion of the install that failed was gettext, all it's dependencies installed correctly.

There have been at least 2 updates to OSX 10.8, 1 to Java and some number to MacPorts and, as I reported above, I can install gettext with no errors reported. I'm not sure how to do the MacPort equivalent of "make test" so I don't know that no errors reported is equivalent to complete and correct.

However, the SUID trick for the java* executables did work for me.

I always run port as root, i.e.: $ sudo port.... It's never a good idea use chmod u+s on root-owned executibles as it's too easy to forget to change it back. Can you say Holy Mother of All Security Holes Batman.

So it seems to be a permission problem with some file system object that Java needs, but can't access as the “macports” user. I would guess that some part of the OS X distribution has faulty permissions, since in OS X 10.7 it still worked fine for me, and richard.t.lloyd's success with the 10.8 developer preview re-install might be explained that way (perms intermittently OK).

I think my current experience, gettext installs on 10.8 using either MacPorts...pkg or MacPorts...tar.gz, indicates that the problem is NOT WITH MACPORTS.

[eirnym (Eir Nym)]

As another workaround, with little bit less security breach.

tell "macportsuser root" in macports.conf and then revert it.

[eirnym (Eir Nym)]

Homebrew has same problems. We're not alone :)

[macports@…]

confirmed that eirnym's edit of macportsuser works for me

[eirnym (Eir Nym)]

experiments:

~> su root -c "chsh  -s /bin/sh macports"
Password:
Changing shell for macports.
~>su root -c env |grep PWD
(no password prompt, strange?)
PWD=/Users/myuser
OLDPWD=/Users/myuser
~>su macports -c env |grep PWD
PWD=/Users/myuser
~>su - root
~# su macports -c env |grep PWD
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
PWD=/var/root
~#su - macports -c env |grep PWD
PWD=/opt/local/var/macports/home
~>su macports -c "cd&&env" |grep PWD
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
chdir: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
OLDPWD=/var/root
PWD=/opt/local/var/macports/home

I scare if this is top of iceberg

[eirnym (Eir Nym)]

But su - root -c "su - macports -c javac" works fine! so may be we should do "full" su

[eirnym (Eir Nym)]

Cc Me!

[eirnym (Eir Nym)]

I've found how to get it to work correctly!

when do sudo(8) it works fine if you turn on flag stay_setuid

From sudoers(5):

Normally, when sudo executes a command the real and
effective UIDs are set to the target user (root by
default).  This option changes that behavior such that
the real UID is left as the invoking user's UID.  In
other words, this makes sudo act as a setuid wrapper.
This can be useful on systems that disable some
potentially dangerous functionality when a program is
run setuid.  This option is only effective on systems
with either the setreuid() or setresuid() function.
This flag is off by default.

[mathew@…]

The solution that has worked for me was to set JAVA_HOME. No system changes or similar workarounds were needed. Simply:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework
port install gettext

Attached is a possible patch with this solution in mind.

[jeremyhu (Jeremy Huddleston Sequoia)]

No, that is not a solution.

Please run 'sudo sysdiagnose sw_vers' when you are in this state and send me the resulting tarball.

[gnw3]

Cc Me!

[francis@…]

I don't think that my experience is relevant to the original problem report but it may be to some of the other commenters, so I hope nobody minds me posting here. I was experiencing hangs during port install <portname> for various ports when run from a sudo -s shell inside tmux. When I just ran sudo port install <portname> from a non-root shell for the same ports then the install completed without hanging. So something to do with running from a root shell or running inside tmux was causing the hangs for me.

[amrit@…]

For me (on Mountain Lion), it was not just javac that was the problem. To make gettext build without stalling, I had to:

chmod u+s `which java` `which javac` `which jar`

Leaving any of them out would result in a hang. (Don't forget to u-s them afterwards...)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #36645.

[psynowiec@…]

I have

JAVA_HOME=/System/Library/Frameworks/JavaVM.framework

I did

chmod u+s `which java` `which javac` `which jar'

and problem still exists I did

sysdiagnose sw_vers

and sent results to jeremyhu@…

I would really like to have this problem resolved as I can't install ports

[psynowiec@…]

I get rid of JAVA_HOME setting and works now.

[kevin@…]

as far as I can tell this seems to be related to the execution of shell commands without quotes EG:

/bin/sh -c "echo $(sw_vers -productVersion)" | sed -E 's/(10.[0-9]).*/\1/' produces an output of 10.8

and /bin/sh -c echo $(sw_vers -productVersion) | sed -E 's/(10.[0-9]).*/\1/' results in no output. this is because the sh command seems to be not behaving according to it's description - normally the args following the -c are supposed to be passed to the called program but that's not what is happening here. the -c requires its command to be quoted.

[neverpanic (Clemens Lang)]

Cc Me!

[kevin@…]

Ok this is because the shell in the user profile for root is bin/sh and that gets run when you are logged in as root. /bin/sh does not work correctly with the -c arg so it hangs.

running with sudo bypasses this because you are running with bash which is the default user shell.

[jeremyhu (Jeremy Huddleston Sequoia)]

I highly doubt that JAVA_HOME has anything to do with this issue.

---

Thanks for the sysdiagnose psynowiec. I've filed <rdar://problem/12544215> to track this internally in case anyone else @apple.com stumbles upon this.

psynowiec, can you please try reproducing this with just su and sudo. Ie, try something like this:

$ sudo -u macports sw_vers -productVersion

or:

$ sudo -s
$ su macports -c "sw_vers -productVersion"

or:

$ sudo -s
$ su macports
$ sw_vers -productVersion

Basically, try to reduce the issue without needing to go through port.

What is the output of:

$ id macports
$ id <numerical uid for the macports user>
$ dscl localhost -read /Search/Users/macports

When you see this, are you connected to any Open Directory server, Active Directory server, LDAP, NIS, or anything else which might be providing users to your system? If so, can you try this with those authentication servers disabled?

When you see this, what's the output of:

$ sudo -s
$ su macports -c "launchctl list"

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, I figured out a way to reproduce this.

Are you all using 'su -' to become root?

[psynowiec@…]

Jeremy

after I had a problem with another port - boost when installing as root using su - I install ports using sudo. This seems to work now with no problem

[cjones051073 (Chris Jones)]

just to add, I recently had this very issue with sw_vers hanging when attempting to develop a script to update MacPorts via a cron. I have a script that works fine, and was running ok when installed as root's crontab, but then one day got stuck whilst updating llvm 3.0. I didn't have time to dig deeper at the time, so shelved the idea, but reading this I suspect it was the same issue as 'su -' versus sudo.

[cjones051073 (Chris Jones)]

Cc Me!

[rahsaan.page@…]

pstree output

[rahsaan.page@…]

and i did 'su -" and 'sudo su -' i get the same results

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #36692.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

$ sudo -s
$ su macports -c "sw_vers -productVersion"

This is the one that produces no output for me.

$ id macports
$ id <numerical uid for the macports user>
$ dscl localhost -read /Search/Users/macports

$ id macports
uid=501(macports) gid=528(macports) groups=528(macports),12(everyone),61(localaccounts)
$ id 501
uid=501(macports) gid=528(macports) groups=528(macports),12(everyone),61(localaccounts)
$ dscl localhost -read /Search/Users/macports
dsAttrTypeNative:_writers_hint: macports
dsAttrTypeNative:_writers_jpegphoto: macports
dsAttrTypeNative:_writers_picture: macports
AppleMetaNodeLocation: /Local/Default
GeneratedUID: 653CB7F3-71DE-44A7-A342-F60304D3A91D
NFSHomeDirectory: /opt/local/var/macports/home
Password: *
PrimaryGroupID: 528
RealName: MacPorts
RecordName: macports
RecordType: dsRecTypeStandard:Users
UniqueID: 501
UserShell: /usr/bin/false
$

$ sudo -s
$ su macports -c "launchctl list"

No output.

Presumably this is because su ... -c tries to launch the user's shell, which is false?

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to rahsaan.page@…:

and i did 'su -" and 'sudo su -' i get the same results

Yeah, that would be expected.

So for now the workaround is for you guys to use 'sudo port ...' rather than using a root login shell ... is there some reason why you were using a root login shell instead of sudo?

[psynowiec@…]

for me there is no particular reason, just old habit from the past using different kind of Unix system

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to rahsaan.page@…:

and i did 'su -" and 'sudo su -' i get the same results

Yeah, that would be expected.

So for now the workaround is for you guys to use 'sudo port ...' rather than using a root login shell ... is there some reason why you were using a root login shell instead of sudo?

Yes, I would like to be able to run my updates via cron, installed as root, which then of course uses a root login shell.

[psynowiec@…]

if I'm not mistaken you can set cron task to run as different user than root, check this option out.

[cjones051073 (Chris Jones)]

It needs to run port as root though. The equivalent of 'sudo port'

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

It needs to run port as root though. The equivalent of 'sudo port'

Which is quite different than 'su - -c port' ... the problem is with having a root login shell. Notice all the paths that don't have a root login shell work fine (su, sudo -s, sudo port ..., su -c port ...) whereas root login shells are the problem (ssh root@localhost, su -, su - -c port ..., etc)

So you now have a workaround (which coincidentally is more secure than your old way), and this issue is being tracked by Apple as <rdar://problem/12544215>.

[cjones051073 (Chris Jones)]

Sorry, what exactly is the work around if I wanted to run port in a script via crontab ?

[cjones051073 (Chris Jones)]

Sorry... I may have just got what you are saying...

In my crontab script I was only running 'port X' instead of 'sudo port X' as I figured it was already running as root, so the sudo was not needed. Are you saying if I also add the sudo it will work around the problem ?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Sorry... I may have just got what you are saying...

In my crontab script I was only running 'port X' instead of 'sudo port X' as I figured it was already running as root, so the sudo was not needed. Are you saying if I also add the sudo it will work around the problem ?

No, I'm saying you should use your user's crontab and use sudo.

You will need to edit /etc/sudoers to allow your user to use 'sudo port' without a password.

[cjones051073 (Chris Jones)]

OK. Thats not really acceptable to me, I would like sudo when run from my normal user account to still require a password. I guess I'll have to wait until the core issue is fixed. No big deal, it was more an experiment really.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #36740.

[neverpanic (Clemens Lang)]

Replying to jeremyhu@…:

No, I'm saying you should use your user's crontab and use sudo.

You will need to edit /etc/sudoers to allow your user to use 'sudo port' without a password.

I don't think this is a good idea. Your Portfiles might be writable for your user depending on your configuration and tampering with the Portfiles would allow arbitrary commands to be run as root without password prompt, causing privilege escalation.

Jeremy: Isn't there a way around this problem? Can root's shell be changed?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to cal@…:

Replying to jeremyhu@…:

No, I'm saying you should use your user's crontab and use sudo.

You will need to edit /etc/sudoers to allow your user to use 'sudo port' without a password.

I don't think this is a good idea. Your Portfiles might be writable for your user depending on your configuration and tampering with the Portfiles would allow arbitrary commands to be run as root without password prompt, causing privilege escalation (but then, it wouldn't be a good idea to run them as root from a cronjob either).

It's no less secure than the user's previous setup.

Jeremy: Isn't there a way around this problem? Can root's shell be changed?

What would you expect that to accomplish. This has nothing to do with root's shell...

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to cal@…:

Replying to jeremyhu@…:

No, I'm saying you should use your user's crontab and use sudo.

You will need to edit /etc/sudoers to allow your user to use 'sudo port' without a password.

I don't think this is a good idea. Your Portfiles might be writable for your user depending on your configuration and tampering with the Portfiles would allow arbitrary commands to be run as root without password prompt, causing privilege escalation (but then, it wouldn't be a good idea to run them as root from a cronjob either).

It's no less secure than the user's previous setup.

Forgive me if I am being slow, by how is making sudo not require a password, for *any* use of it, be no less secure than installing a single script to run as a crontab as root, which only affects that one script ? I don't get why you say these are both equally as secure ?

Jeremy: Isn't there a way around this problem? Can root's shell be changed?

What would you expect that to accomplish. This has nothing to do with root's shell...

[cjones051073 (Chris Jones)]

For give me, I guess I was being slow this morning.

I forgot it is possible to make sudo not require a password for a single command, not only just globally. So I could make it so my update script didn't require a password, which I could then run as myself in crontab. If this is what you mean, then yes I agree this is perfectly reasonable.

[eirnym (Eir Nym)]

I don't like when sudo(8) doesn't ask password due security reasons and there are many tasks when you need do batch of tasks under root using port(1). So I'll try to find way to correct this bug which is bug.

Any way, there's some interest thing I've found on clean system: if you install gettext using sudo(8) and later try to install python (just as example) under root, you'll get same error. But if you'll do hack with chmod +s described above, there'll be no error.

[jeremyhu (Jeremy Huddleston Sequoia)]

ein, you can make it such that only specific actions can be taken by specific users without a password.

Also, 'su' always forces you to use a password, so if you want to use a password, then use 'sudo' *without* one. I fail to see how *that* is causing you a problem. Just switch from using su to using sudo.

Re your gettext/python comment, that does not provide new information. The issue is strictly with the use of su and some ruid euid issue "somewhere" in bootstrap-land ... please just use sudo.

[eirnym (Eir Nym)]

Replying to jeremyhu@…:

ein, you can make it such that only specific actions can be taken by specific users without a password.

Jeremyhu, I'm Eir if you like to make my nickname shorter. :-)

Also, 'su' always forces you to use a password, so if you want to use a password, then use 'sudo' *without* one. I fail to see how *that* is causing you a problem. Just switch from using su to using sudo.

I usually use sudo su -, because it asks my password, not roots'. But anyway, I always set timeout to 0 because in other way sudo is big security hole. By the way, I prefer workflow from FreeBSD ports for user installs: it asks for root password or use sudo for.

Re your gettext/python comment, that does not provide new information.

Nope, it does. It says that ./configure caches information about java and doesn't check it again later.

The issue is strictly with the use of su and some ruid euid issue "somewhere" in bootstrap-land ... please just use sudo.

As I saw bug in myports sources several months ago when it sets uids/euids. And I'll want to find the way to fix this bug.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to eirnym@…:

Replying to jeremyhu@…:

ein, you can make it such that only specific actions can be taken by specific users without a password.

Jeremyhu, I'm Eir if you like to make my nickname shorter. :-)

Ok, sorry. Thanks. I wish this showed names instead of email addresses =)

Also, 'su' always forces you to use a password, so if you want to use a password, then use 'sudo' *without* one. I fail to see how *that* is causing you a problem. Just switch from using su to using sudo.

I usually use sudo su -, because it asks my password, not roots'.

You want to use 'su -s' for that functionality.

But anyway, I always set timeout to 0 because in other way sudo is big security hole.

Fair enough

By the way, I prefer workflow from FreeBSD ports for user installs: it asks for root password or use sudo for.

If you want a shell, you can either ssh in as root if you want to use root's password, or you can use 'sudo -s' to use your password. There's something weird going on with euid/ruid when using 'su -', so please avoid it until we can figure out what the issue is. There is a radar open for it, and Apple engineers are aware of the issue. I can't really comment beyond that.

Re your gettext/python comment, that does not provide new information.

Nope, it does. It says that ./configure caches information about java and doesn't check it again later.

I'm not sure what you mean. Could you please open a new ticket, or followup with me offline, so I can understand this particular point better?

[jeremyhu (Jeremy Huddleston Sequoia)]

Setting __CFPREFERENCES_AVOID_DAEMON=1 in the build environment should workaround the issue. Can you try that on an affected port?

[jeremyhu (Jeremy Huddleston Sequoia)]

r104118

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

It's not "invalid" for a user to use a root login instead of sudo. A change Apple made in Mountain Lion made this no longer work, in some cases. And you've worked around it in base. So it's a valid issue, that has now been fixed.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

It's not "invalid" for a user to use a root login instead of sudo.

I never said it was.

A change Apple made in Mountain Lion made this no longer work, in some cases.

That is why I marked it invalid. It is invalid because it is not our bug. It is an Apple bug.

And you've worked around it in base. So it's valid issue, that has now been fixed.

Yes, I found a workaround for the bug, but the bug itself is a bug in the OS that we cannot fix in MacPorts.

[ryandesign (Ryan Carsten Schmidt)]

I use "invalid" when there is nothing we need to change in MacPorts. In this case, a change was needed in MacPorts to work around the problem so that users would no longer experience it, so I call that "fixed". When we release MacPorts 2.2, we'll want to have an entry in the ChangeLog and/or NEWS file mentioning that this problem is fixed, and we'll refer to this ticket. It would be weird for a fix to show up in the ChangeLog or NEWS but to refer to an "invalid" ticket.

Compare with the Leopard Tcl bug that makes unsetting environment variables fail, or the many cases where we blacklist older compiler versions which fail to build a particular port. These reports weren't "invalid" either. They were bugs in non-MacPorts components provided by Apple, but we worked around them in MacPorts and thereby "fixed" the problems the users reported.