<handheldCar>Do we just need one build user per guix user? You know all the other users may show up on one's login screen? <jmd>Is hydra.gnu.org down ? <mark_weaver>handheldCar: if more than one build is happening concurrently, each one has to have a distinct user id. <mark_weaver>handheldCar: there are a couple of ways to avoid seeing them in your display manager login screen. <mark_weaver>I'm only (vaguely) familiar with how GDM does it off hand. if the UID is below a certain number (usually 1000, iirc), then it is assumed to be a system account and thus not shown. <mark_weaver>there's also a config file where you can specify the exist list of users to show. <handheldCar>I tried without multiple build users, and it failed; so I added the other nine. Is there a wiki for saving this type of info? <waxysubs>if something needs to be fixed, I think we should just fix the manual, no? what change do you think should be made? <mark_weaver>if something needs to be fixed, I think we should just fix the manual, no? what change do you think should be made? <handheldCar>Nothing needs to be fixed though. It's just an explanation for 10 build users and suggestions for hiding them from GDM. <mark_weaver>yeah, I guess we should suggest to use UIDs in the range reserved for system accounts. <handheldCar>as long as they don't clash - Red Hat starts users at 500 <mark_weaver>well, they shouldn't clash because any well-designed system should automatically allocate new system accounts from the available set. Debian certainly does, and I'd be surprised is RPM doesn't. <mark_weaver>it should never create another system UID that's the same number as one you created. <mark_weaver>but you have to avoid the ones that are already there; that's certainly true. <mark_weaver>I see that "useradd" has a --system option, which specifies that "their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups)." <mark_weaver>and I see that our docs already suggest the use of "useradd", so I guess we should just add --system to the list of options in our suggested command. <jmd>What's the best way to the path of the gcc used in the build ? <mst>civodul: mind if I /msg ? want to run through a few things about the channel setup <civodul>jmd: guix build -e '(@ (gnu packages base) gcc-final)' <jmd>I meant how do I find it in a script. <jmd>Anyone know when hydra is going to be available again? <mst>mark_weaver: hopefully the /notice on join is subtle enough you can keep the bot <mst>note that civodul basically gave you access all areas in terms of channel perms <mst>so if you're not sure how to do something with them, you're welcome to ask <mst>I may just point you at '/chanserv help foo' but knowing -which- 'foo' to ask for help on is sometimes most of the battle <mst>sorry for being a grumpy bastard before but after 7+ years of helping projects run IRC channels, when somebody says "oh that failure mode won't be a problem" it tends to make me annoyed because generally I've seen more than one incident where it was or I wouldn't've mentioned it in the first place <mst>however, while you might have triggered the grumpiness, it's not your fault I'm grumpy in general, if you see what I mean ;) <mark_weaver>no worries. I confess I could have been more open minded about it. <mst>eh. the stuff I was worrying about is now all sorted ***Steap is now known as skarnyx
***skarnyx is now known as Steap
<adhoc>mst: yeah corner cases like that come back to haunt you at the most inconvenient times <adhoc>mst: and because you've ignored them and excluded it from your design, are the hardest to fix <mst>adhoc: in this case it was a discussion about IRC channel setup ... but I regard it the same way as any service configuration task <mst>"any single point of failure will, at some point, fail. have a plan."