Good detection of PORTAGE_TMPDIR

[vincentdephily]

Currently defaults to /var/tmp/ and has a --tmpdir option, but it'd be nice to automate as this is a common config tweak.

Problem is that it's parsed by bash from /etc/portage/make.conf and various other locations (for example /etc/portage/env/* for per-package config), but I'd rather avoid invoking the full machinery.

Maybe one trick would be to accept multiple dirs internally, and try them in order in parse::current::get_buildlog(). We won't need fancy bash logic in that case, just a list of files to search with a regex.

[vincentdephily]

Another trick is to look for the build log in /proc/$(pgrep emerge)/fd. Might run into permission issues on some systems, but still a neat heuristic.

[kakra]

You could also read the environment of processes from /proc/$PID/environment, I've done that for Feral's gamemode: https://github.com/kakra/gamemode/commit/b434e9acc5f7acb768ada6fe0935e559628e5142

It's just a list of zero-terminated strings.

I use that to get the wine prefix: https://github.com/kakra/gamemode/blob/b434e9acc5f7acb768ada6fe0935e559628e5142/daemon/gamemode-wine.c#L111-L127

[vincentdephily]

Thanks for the idea. But I'm sure if I can read /proc/$PID at all I can read ./fd, and that gives me a more direct answer than parsing ./environment. Emlop already does a bit of /proc parsing, shouldn't be hard to implement this. Do you want to try it ? 😉

[kakra]

I think this is problematic. Gamemode runs a setcap helper to get elevated permissions, emlop probably doesn't want to do such tricks. So reading fd is probably more elegant for your use-case (as long as the processes hold an open FD to a directory) although it doesn't prevent permission issues either. I just wanted to give you another idea if something would still be missing.

OTOH, I wanted to look at rust a little - but let's wait until that may be needed.

[vincentdephily]

Yes, we don't want elevated permissions for emlop.

The "show current status from build.log" feature doesn't work as a non-root user because the build.log is not readable (it's 660 and owned by root, unless you tweaked your system). That's fine IMHO, emlop silently falls back to not printing anything (though you'll see the attempts if using -vvv). The recommended way to solve the permission issue is to run emlop as root.

AFAICS the /proc/pid/fd trick should work well to find the build log in non-standard locations. If there's a case where that trick doesn't work but another one does, we can add more fallbacks.

[kakra]

I think it's enough to be in the portage group? At least it shows builds queued for me on system where I am in the portage group. In that case, setting group portage sticky on the binary could also work but I'd prefer the approach of just being member in that group.

[vincentdephily]

Being in the portage group is needed to read emerge.log (660 portage portage), I think it's fair to assume that all emlop users have that. Interestingly, /var/cache/edb/mtimedb (for the current build queue) is world-readable (644 root portage).

What's only readable by the portage user and root is the $PORTAGE_TMPDIR/$CATEG/$EBUILD-$VERSION (it's 700 portage) where the build.log lives. Being in the portage group won't help you there. Run emlop p -vv with an ongoing emerge to see the failed open attempt. I don't think there's any way to change portage's behaviour here, as PORTAGE_TMPDIR is a sensitive folder. That's ok, reading the build log tagline is a minor feature anyway.

[vincentdephily]

Fixed in bec7bb92a1e08c3df9f2497e7a5303963e38f41c