IRC channel logs


back to list of logs

<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 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>sorry, that was me typing from my private logger.
<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
<handheldCar>therefore Fedora possibly as well
<mark_weaver>yeah, the range is system-specific.
<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.
<handheldCar>probably would be neater
<civodul>Hello Guix!
<zacts>lo guix!
<jmd>What's the best way to the path of the gcc used in the build ?
<mst>civodul: hey dude
<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)'
<civodul>mst: yes, sure
<civodul>i mean, go ahead :-)
<jmd>I meant how do I find it in a script.
<civodul>in a build-side script?
<civodul>you can use (which "gcc")
<civodul>or (assoc-ref inputs "gcc")
<handheldCar>wb civodul
<handheldCar>mark_weaver: I just submitted a bug about what we discussed:
<jmd>Anyone know when hydra is going to be available again?
<mark_weaver>handheldCar: great, thanks!
<mst>mark_weaver: hopefully the /notice on join is subtle enough you can keep the bot
<mark_weaver>mst: looks good.
<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
<mark_weaver>that's good :)
***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."
<adhoc>mst: indeed