Looking at the ebuild it looks like the GOHOSTARCH was set to x64-macos where it should be amd64. Also it seems like the script will use /usr/sbin/sysctl to get the system architecture information https://golang.org/src/cmd/dist/util.go#L407 and this binary is not in PATH during emerge. Reproducible: Always
Ping on this? I have a dirty workaround on this if someone wants to review it.
Created attachment 415100 [details, diff] go-macos-sysctl.patch
Created attachment 415102 [details] go-1.5.1.ebuild
I applied this stuff, thanks!
All, I just came across this bug. Comment #1 states that this is a dirty workaround, and I agree. The better fix is to figure out why /usr/bin is not in the path and fix that issue.
/usr/sbin is not in the path because this is Prefix. Also outside of prefix, it isn't expected that non-root users have /usr/sbin in PATH. So, not sure what you plan on doing on this. The fix I applied is the right one (give that Gentoo only does Prefix for OSX).
(In reply to Fabian Groffen from comment #6) > /usr/sbin is not in the path because this is Prefix. Also outside of > prefix, it isn't expected that non-root users have /usr/sbin in PATH. > > So, not sure what you plan on doing on this. The fix I applied is the right > one (give that Gentoo only does Prefix for OSX). Outside of Prefix, /usr/sbin will always be in the path during emerge, because emerge always runs as root. If a user were going to install go as a user package outside of prefix, the user would use the upstream installation instructions, e.g. the installation would go in /home/<username>/go [1]. I'm not sure what I'm going to do yet, but basically I would rather not hard code paths to binaries because of something that Gentoo specifically does with the path, e.g. I think most distros have /usr/sbin in the path for everyone, and there really is no compelling reason not to do that. I'll probably end up bringing this to the list if you do not see another way to handle it. [1] https://golang.org/doc/install/source
(In reply to William Hubbs from comment #7) > (In reply to Fabian Groffen from comment #6) > > /usr/sbin is not in the path because this is Prefix. Also outside of > > prefix, it isn't expected that non-root users have /usr/sbin in PATH. > > > > So, not sure what you plan on doing on this. The fix I applied is the right > > one (give that Gentoo only does Prefix for OSX). > > Outside of Prefix, /usr/sbin will always be in the path during emerge, > because emerge always runs as root. If a user were going to install go as a > user package outside of prefix, the user would use the upstream installation > instructions, e.g. the installation would go in /home/<username>/go [1]. I think you miss the point of Prefix here. It runs unprivileged, in a location other than /. That said, if you're really that concerned about this (Python as opposed to Golang does this all-over for example) I suggest we try to find consensus which is beneficial for both of our users. As I understand the situation right now: - none of your users are affected in any way by my patch - prefix users on OSX can enjoy golang from Gentoo - the maintenance of this patch is fully up to me, and will never block you
(In reply to William Hubbs from comment #7) > I'm not sure what I'm going to do yet, but basically I would rather not hard > code paths to binaries because of something that Gentoo specifically does > with the path, e.g. I think most distros have /usr/sbin in the path for > everyone, and there really is no compelling reason not to do that. Even Gentoo doesn't add /usr/sbin to the path of users, so I'm not sure what you're aiming at here.
(In reply to Fabian Groffen from comment #9) > (In reply to William Hubbs from comment #7) > > I'm not sure what I'm going to do yet, but basically I would rather not hard > > code paths to binaries because of something that Gentoo specifically does > > with the path, e.g. I think most distros have /usr/sbin in the path for > > everyone, and there really is no compelling reason not to do that. > > Even Gentoo doesn't add /usr/sbin to the path of users, so I'm not sure what > you're aiming at here. As I said, I think we should fix PATH, even in Gentoo, as opposed to hard coding paths to binaries in software. I don't see a compelling reason to not have /sbin and /usr/sbin in the path for everyone. After all, as far as I know, we are the only distro I'm aware of that goes out of our way to remove these from the path for users.
sysctl doesn't belong in sbin if it can/should be utilized by normal users. That's likely historical baggage: the binary has always been in sbin. I'm guessing it would be relatively difficult to convince Apple to move it to bin. Given that constraint, using the full path to the binary seems like a reasonable workaround.
(In reply to Mike Gilbert from comment #11) > sysctl doesn't belong in sbin if it can/should be utilized by normal users. > That's likely historical baggage: the binary has always been in sbin. > > I'm guessing it would be relatively difficult to convince Apple to move it > to bin. > > Given that constraint, using the full path to the binary seems like a > reasonable workaround. @floppym: I suspect that Prefix is doing the same thing we are in Gentoo, going out of our way to remove /sbin and /usr/sbin from the path for non-privileged users, which really there is no reason to do, and I've never seen another distro do that. I suspect that even on native OSx, /sbin and /usr/sbin are not removed from the path for a normal user.
(In reply to William Hubbs from comment #12) > (In reply to Mike Gilbert from comment #11) > > sysctl doesn't belong in sbin if it can/should be utilized by normal users. > > That's likely historical baggage: the binary has always been in sbin. > > > > I'm guessing it would be relatively difficult to convince Apple to move it > > to bin. > > > > Given that constraint, using the full path to the binary seems like a > > reasonable workaround. > > @floppym: > I suspect that Prefix is doing the same thing we are in Gentoo, going out of > our way to remove /sbin and /usr/sbin from the path for non-privileged > users, which really there is no reason to do, and I've never seen another > distro do that. I suspect that even on native OSx, /sbin and /usr/sbin are > not removed from the path for a normal user. Native OSX does not: Austins-Mac-mini:~ austin$ uname -a Darwin Austins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 Austins-Mac-mini:~ austin$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin but Debian (unstable) does remove it: austin@debian-laptop:~$ uname -a Linux debian-laptop 4.2.0-1-amd64 #1 SMP Debian 4.2.3-2 (2015-10-14) x86_64 GNU/Linux austin@debian-laptop:~$ cat /etc/issue Debian GNU/Linux stretch/sid \n \l austin@debian-laptop:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
(In reply to austinenglish@gmail.com from comment #13) > (In reply to William Hubbs from comment #12) > > (In reply to Mike Gilbert from comment #11) > > > sysctl doesn't belong in sbin if it can/should be utilized by normal users. > > > That's likely historical baggage: the binary has always been in sbin. > > > > > > I'm guessing it would be relatively difficult to convince Apple to move it > > > to bin. > > > > > > Given that constraint, using the full path to the binary seems like a > > > reasonable workaround. > > > > @floppym: > > I suspect that Prefix is doing the same thing we are in Gentoo, going out of > > our way to remove /sbin and /usr/sbin from the path for non-privileged > > users, which really there is no reason to do, and I've never seen another > > distro do that. I suspect that even on native OSx, /sbin and /usr/sbin are > > not removed from the path for a normal user. > > Native OSX does not: > Austins-Mac-mini:~ austin$ uname -a > Darwin Austins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep > 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 > > Austins-Mac-mini:~ austin$ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin This is what I was mostly interested in. OSx doesn't remove *sbin from a users path, so I see this as an issue with PATH that should be fixed rather than hard coding the path to the sysctl binary. > > but Debian (unstable) does remove it: > austin@debian-laptop:~$ uname -a > Linux debian-laptop 4.2.0-1-amd64 #1 SMP Debian 4.2.3-2 (2015-10-14) x86_64 > GNU/Linux > > austin@debian-laptop:~$ cat /etc/issue > Debian GNU/Linux stretch/sid \n \l > > austin@debian-laptop:~$ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games This is interesting that Debian unstable is removing *sbin from the user's path, but I don't think it affects this bug.
(In reply to William Hubbs from comment #14) > (In reply to austinenglish@gmail.com from comment #13) > > (In reply to William Hubbs from comment #12) > > > (In reply to Mike Gilbert from comment #11) > > > > sysctl doesn't belong in sbin if it can/should be utilized by normal users. > > > > That's likely historical baggage: the binary has always been in sbin. > > > > > > > > I'm guessing it would be relatively difficult to convince Apple to move it > > > > to bin. > > > > > > > > Given that constraint, using the full path to the binary seems like a > > > > reasonable workaround. > > > > > > @floppym: > > > I suspect that Prefix is doing the same thing we are in Gentoo, going out of > > > our way to remove /sbin and /usr/sbin from the path for non-privileged > > > users, which really there is no reason to do, and I've never seen another > > > distro do that. I suspect that even on native OSx, /sbin and /usr/sbin are > > > not removed from the path for a normal user. > > > > Native OSX does not: > > Austins-Mac-mini:~ austin$ uname -a > > Darwin Austins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep > > 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 > > > > Austins-Mac-mini:~ austin$ echo $PATH > > /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin > > This is what I was mostly interested in. OSx doesn't remove *sbin from a > users path, so I see this as an issue with PATH that should be fixed rather > than hard coding the path to the sysctl binary. Or, it could be argued that using sysctl is flawed, so if possible, come up with another test that uses a binary in that is not located in /usr/sbin.
(In reply to William Hubbs from comment #14) > (In reply to austinenglish@gmail.com from comment #13) > > but Debian (unstable) does remove it: > > austin@debian-laptop:~$ uname -a > > Linux debian-laptop 4.2.0-1-amd64 #1 SMP Debian 4.2.3-2 (2015-10-14) x86_64 > > GNU/Linux > > > > austin@debian-laptop:~$ cat /etc/issue > > Debian GNU/Linux stretch/sid \n \l > > > > austin@debian-laptop:~$ echo $PATH > > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > This is interesting that Debian unstable is removing *sbin from the user's > path, but I don't think it affects this bug. Sure. I included it as an extra data point, I assume most people on b.g.o mostly only have access to Gentoo machines ;)
Looking at this in detail, for Gentoo Prefix this patch is wrong for it assumes 64-bits world even on a 32-bits userland/binary. The whole /usr/sbin/sysctl point is moot. I understand upstream had an issue figuring this out, but basically this should be a compile time setting such that the binary matches what it wants to produce, regardless machine it runs on.
Based on comment #17, I am removing this patch. Is this an issue to address Upstream, or is it something we can fix in the ebuild without patching the code?
If you insist on breaking Go for OSX, go ahead. As it looks, no we can't fix it without patching the code. We can conditionalise it for Darwin if that makes you feel better about it, though.
In Gentoo, we are discussing adding the sbin directories to the path for all users, and as Austin pointed out above, the sbin directories are in the path for all users, privileged or not, on native OSx. Is there any way you would consider doing that on prefix?
If Gentoo mainline does it, we will follow. It is irrelevant to this bug, however. Portage itself re-sets PATH, so whatever the shell does, it doesn't care (for good reasons). In Prefix, we currently do NOT include sbin from the host-OS, to do that we need to update Portage ebuild for it simply doesn't pass these onto configure.
(In reply to Fabian Groffen from comment #17) > Looking at this in detail, for Gentoo Prefix this patch is wrong for it > assumes 64-bits world even on a 32-bits userland/binary. The whole > /usr/sbin/sysctl point is moot. I understand upstream had an issue figuring > this out, but basically this should be a compile time setting such that the > binary matches what it wants to produce, regardless machine it runs on. It is. The util.go code is the fallback autodetect code; its output gets overridden later by the envvars. The only thing that matters is that the build script can find a sysctl binary at all, it doesn't even matter what output it spits out. Thus, yegle's patch should do fine.
@grobian: I'm not interested in breaking things for OSx; I am interested in a patch that could be sold upstream, and I think this patch is going to be hard to sell. What exactly is sysctl being used for on OSx? Is there a better way it could be done that doesn't use sysctl?
I have applied a version of the upstream patch to dev-lang/go-1.5.3. This should resolve the issue. Thanks, William
