Opened 22 months ago

Last modified 12 months ago

#58709 assigned defect

prometheus, node_exporter, alertmanager: Unable to initialize project info

Reported by: ryandesign (Ryan Schmidt) Owned by: herbygillot (Herby Gillot)
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: Cc: jmroot (Joshua Root), herbygillot (Herby Gillot)
Port: prometheus, node_exporter, alertmanager

Description

prometheus does not build:

Unable to initialize project info
!! Couldn't get current user: user: Current not implemented on darwin/amd64

Change History (22)

comment:1 Changed 22 months ago by herbygillot (Herby Gillot)

This is a problem with 'promu', the build tool used by prometheus-based projects. For some reason, it has been failing in buildbot environments with this error, but works fine everywhere else (I've tested this on macOS machines and VMs). Is there any way to get access to an environment similar to the one buildbots run in?

comment:2 Changed 22 months ago by ryandesign (Ryan Schmidt)

The environment is a normal macOS installation, but instead of running port commands via the terminal, they're run by mpbb, which in turn is being run by buildbot. So you could try cloning mpbb and seeing if running ./mpbb --prefix /opt/local install-port prometheus works for you.

Looking up this error on Google, I found other projects experiencing the same problem. Here's how one of them solved it:

https://github.com/github/hub/pull/1082

Maybe that's helpful to the developers of prometheus in fixing it.

Last edited 22 months ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:3 Changed 22 months ago by ryandesign (Ryan Schmidt)

In the case of hub, their fix was to stop using user.Current(). Another avenue of exploration would be to figure out why user.Current() doesn't work in our go installation, and if possible fix it so that it does work; that could potentially help other projects, not just prometheus.

comment:4 Changed 14 months ago by herbygillot (Herby Gillot)

Would it be possible to get the USER environment variable set?

From a build of 2.17.0, on a much more recent version of Go:

Unable to initialize project info
!! Couldn't get current user: user: Current requires cgo or $USER set in environment

comment:5 Changed 14 months ago by ryandesign (Ryan Schmidt)

As far as I can tell on my Mac, whether port is run from within mpbb or not, the USER environment variable is already set to root.

comment:6 Changed 14 months ago by herbygillot (Herby Gillot)

Gotcha. Is there a way we can verify directly in the buildbot environment whether USER is set there as well?

comment:7 Changed 14 months ago by ryandesign (Ryan Schmidt)

You could add

pre-build {
    system "env"
}

to the Portfile and then look at the log from the buildbot.

comment:8 Changed 14 months ago by ryandesign (Ryan Schmidt)

Cc: jmroot added

Herby made that change as part of [fe4db4df994f130a29de6c7bb2e4ef1cf935c493/macports-ports].

And it looks like USER really isn't set when MacPorts runs from buildbot:

--->  Building prometheus
DEBUG: Executing proc-pre-org.macports.build-build-0
DEBUG: system: env
DEVELOPER_DIR=/Library/Developer/CommandLineTools
TMPDIR=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_prometheus/prometheus/work/.tmp
ARCHIVE_SITE_LOCAL=http://packages.internal.macports.net/:tbz2 http://packages-private.internal.macports.net/:tbz2
NO_PROXY=*.local,169.254/16
CCACHE_DIR=/opt/local/var/macports/build/.ccache
PATH=/opt/local/bin:/opt/local/sbin:/opt/bblocal/libexec/libarchive:/bin:/sbin:/usr/bin:/usr/sbin
PORTSRC=/opt/bblocal/var/buildworker/ports/build/macports.conf
PWD=/opt/local/var/macports
LANG=en_US.UTF-8
SHLVL=1
HOME=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_prometheus/prometheus/work/.home
_=/usr/bin/env

For comparison, here's what it looks like on my system running from a bash shell:

--->  Building prometheus
DEBUG: Executing proc-pre-org.macports.build-build-0
DEBUG: system: env
DEVELOPER_DIR=/Library/Developer/CommandLineTools
TMPDIR=/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk-new_net_prometheus/prometheus/work/.tmp
NO_PROXY=*.local,169.254/16
USER=root
CCACHE_DIR=/opt/local/var/macports/build/.ccache
COLUMNS=333
PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
PWD=/opt/local/var/macports
LANG=en_US.UTF-8
LINES=88
SHLVL=1
HOME=/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk-new_net_prometheus/prometheus/work/.home
DISPLAY=/private/tmp/com.apple.launchd.ZKgVfDs3cL/org.macports:0
_=/usr/bin/env

So now the question is: what do we do? Do we need to modify our buildbot configuration so that we set USER before calling mpbb? Or do we modify mpbb to do that? Or do we modify MacPorts base?

comment:9 Changed 14 months ago by jmroot (Joshua Root)

There's no general requirement for USER to be set. Seems like it shouldn't be that hard for upstream to fall back to id -un, but the portfile could also set configure.env USER=${macportsuser}.

comment:10 in reply to:  9 Changed 14 months ago by ryandesign (Ryan Schmidt)

Replying to jmroot:

There's no general requirement for USER to be set.

Yeah I haven't heard of this being a problem for other ports. Maybe it is best for the prometheus port to work around this.

Seems like it shouldn't be that hard for upstream to fall back to id -un, but the portfile could also set configure.env USER=${macportsuser}.

macportsuser would be "macports" but on my system (when using a root MacPorts installation) the USER was set to "root".

Not sure why a build system should care what user it's being run as. Seems like it should be completely irrelevant.

comment:11 Changed 14 months ago by herbygillot (Herby Gillot)

I think USER is an environment variable that's reasonable to expect in most environments.

It will usually be absent if the shell is not started by login, or in certain instances in a shell spawned by sudo.

I suppose I can look into making that change, but it would be interesting to know why the buildbot environment _outside_ of mpbb doesn't have it set.

comment:12 Changed 14 months ago by herbygillot (Herby Gillot)

In terms of why USER is even needed, prometheus is being built by promu, which is a build tool, and promu captures some info about the build it's about to perform.

comment:13 in reply to:  11 Changed 14 months ago by ryandesign (Ryan Schmidt)

Replying to herbygillot:

I think USER is an environment variable that's reasonable to expect in most environments.

It will usually be absent if the shell is not started by login, or in certain instances in a shell spawned by sudo.

I suppose I can look into making that change, but it would be interesting to know why the buildbot environment _outside_ of mpbb doesn't have it set.

Presumably the reason is that buildbot is started by launchd, not in a shell.

comment:14 in reply to:  12 Changed 14 months ago by ryandesign (Ryan Schmidt)

Replying to herbygillot:

In terms of why USER is even needed, prometheus is being built by promu, which is a build tool, and promu captures some info about the build it's about to perform.

And I guess my argument is: it should not do that. It does not need to know.

comment:15 Changed 14 months ago by jmroot (Joshua Root)

Recording the user anywhere is certainly not recommended for the purpose of reproducible builds.

comment:16 Changed 14 months ago by ryandesign (Ryan Schmidt)

Cc: herbygillot added
Port: node_exporter added
Summary: prometheus @2.11.0: Unable to initialize project infoprometheus, node_exporter: Unable to initialize project info

comment:17 Changed 13 months ago by herbygillot (Herby Gillot)

OK, PR with an attempted fix: https://github.com/macports/macports-ports/pull/6782

If it works, then I will add the same for node_exporter and alertmanager, which are both projects building with promu.

comment:18 Changed 13 months ago by ryandesign (Ryan Schmidt)

Port: alertmanager added
Summary: prometheus, node_exporter: Unable to initialize project infoprometheus, node_exporter, alertmanager: Unable to initialize project info

comment:20 Changed 13 months ago by ryandesign (Ryan Schmidt)

alertmanager: [7b9edbaf09b858af3357b4de09b1684fe36feca6/macports-ports]

node_exporter: [4a5423f2f5bff98a5b305906387eb5cb8ceae5ee/macports-ports]

Remember to include the ticket URL in the commit message so they can be linked automatically. It looks like you put it into the PR description, but it needs to be in the commit message for Trac to see it and act on it.

Is there already a bug report to promu about this?

comment:21 Changed 12 months ago by herbygillot (Herby Gillot)

Sorry for response delay @ryandesign - I did not open a bug report with promu as this looks like it's by design. I can if we insist, but we can probably close this one as resolved.

comment:22 Changed 12 months ago by ryandesign (Ryan Schmidt)

I'm sure it's by design. I don't know anything about that design or why it was designed that way, but I would begin from the assumption that the design is faulty as per comment:14 :)

If we do not report it to them and they do not fix it, then we'll have to have this USER environment variable in these ports forever and also remember to add it to any other ports that we might add in the future that use promu.

Note: See TracTickets for help on using tickets.