<gchristensen>
that... doesn't belong in a distro ...
<MichaelRaskin>
makefu: actually, a proper fortune origram should have both offensive and non-offensive messages, with a flag to use offensive ones.
<MichaelRaskin>
program
peti has joined joined #nixos-dev
<makefu>
true, however if i choose to show offensive messages why is there a discussion about these messages to be offensive?
<MichaelRaskin>
Dunno.
<MichaelRaskin>
Declaring everything but freebsd-tips offensive could make more sense, I guess.
<gchristensen>
$ cowsay -f sodomized hi
<MichaelRaskin>
But they decided not to ship anything offensive.
<gchristensen>
cowsay: Could not find sodomized cowfile!
<gchristensen>
fpletz: we're clear
<fpletz>
gchristensen: nice :)
<MichaelRaskin>
I wonder if at the point of inclusion the quotes from Hitler were considered an obvious argument ad hitlerum; unfortunately, nowadays they can be taken by some at face value.
<makefu>
lets see how long it takes until peta discovers flaming-sheep and demand instant removal
<makefu>
or someone easily offended discovers `head-in`
<MichaelRaskin>
I guess someone easily offended has a risk of being declared a sockpuppet of 0xABAB
<gchristensen>
I don't think that exploring that hypothetical would result in anything useful
<gchristensen>
(but I could be wrong)
<MichaelRaskin>
Hopefully it turns out to be a hypothetical and not planning…
ma27 has quit [(Ping timeout: 240 seconds)]
ma27 has joined joined #nixos-dev
<copumpkin>
niksnut: if we (temporarily) switch the installer back to single-user for darwin, would you object?
<gchristensen>
probably should :(
<copumpkin>
at least until we can sort out this user add thing
<gchristensen>
it'd be neat if we could make that adjustable in the nixos.org/nix/install script itself, like being able to pass flags from there "--multi-user-darwin" -> turns on the multi user code path, absent goes single-user
<copumpkin>
it would be nice if there were a more agile way to switch back and forth, or even just have different endpoints (with a symlink for nixos.org/nix/install)
<gchristensen>
:D
<copumpkin>
yeah or that
<copumpkin>
perhaps an env var, since it's hard to pass args into a curl | sh
<gchristensen>
I mean not passed at the curl | sh level, but inside the `install`
<copumpkin>
ah
<gchristensen>
but yeah you may be right
<copumpkin>
gchristensen: you interested in joining darwin-maintainers group now that github has discussion threads?
<gchristensen>
this fails because you need `interactive`: sudo /usr/sbin/sysadminctl -addUser "nixbld$i" -fullName "Nix build user $i" -home /var/empty -UID "3000$i" -addUser "nixbld$i"
<gchristensen>
this fails because you need `sudo`: /usr/sbin/sysadminctl interactive -addUser "nixbld$i" -fullName "Nix build user $i" -home /var/empty -UID "3000$i" -addUser "nixbld$i"
<domenkozar>
why do we need interactive?
<copumpkin>
apple decided so
<gchristensen>
you have to authenticate with SystemAdministration Framework
<copumpkin>
:)
<copumpkin>
it wasn't the case in 10.12
<copumpkin>
but .13 wants that
<gchristensen>
you either have to call: sysadminctl interactive -addUser <- and this prompts for the admin password every time it is called
<gchristensen>
or ... you call sysadminctl -adminUser <username> -adminPassword <password> -addUser <- but here you have to prompt the username/password ahead of time and pass it in over the CLI, which feels icky
<domenkozar>
so basically they don't consider root as root anymore
<gchristensen>
not in the context of SystemAdministration Framework, apparently
<copumpkin>
that's been true for a while
<copumpkin>
but yeah, it's even less rooty than it used to be
<gchristensen>
next version of macos: "Failed to authenticate with SystemAdministration framework to write to /nix/store/<hash>-foo/my-file"
<domenkozar>
sigh
<domenkozar>
well, we bend over
<domenkozar>
and pass the password
<domenkozar>
so it's more secure for apple
<domenkozar>
:D
<domenkozar>
it seems like apple and microsoft CEOs switched mentality a few years ago
<domenkozar>
the two OSes are going the opposite ways
<domenkozar>
one is rapidly adopting linux
<domenkozar>
other one is rapidly building walls
<domenkozar>
probably a russian hack
<gchristensen>
I don't think it is a good idea to ask for a password and then pass it in on the cli, its pretty unsafe and will make people squirm
<gchristensen>
unfortunately
<domenkozar>
also it can only be then interactive, not part of any CI
<copumpkin>
is there a way to get the list of overlays from within the imported nixpkgs?
<copumpkin>
something like pkgs.args.overlays or something
<copumpkin>
Sonarpulse: seems like something you might know :)
<lassulus>
q
peti has quit [(Quit: WeeChat 1.8)]
vcunat has quit [(Ping timeout: 255 seconds)]
peti has joined joined #nixos-dev
<LnL>
nixos or just nixpkgs
<copumpkin>
nixpkgs
ma27 has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
<Sonarpulse>
to be clear, I don't expect that to break anything (I looked over all uses of the file itself)
<LnL>
yeah, takes longer then I expected
<LnL>
but that eval should be good once it's finished
<vcunat>
if I simply count the ratio of darwin jobs, there should be ~50h remaining
<gchristensen>
would anyone be mad if I blew up our file layout of our XML docs and restructured them?
<gchristensen>
O:)
<vcunat>
I think we have quite a lot of changes in the current iteration, but once Linux jobs are cleared up, we can just start building again, in parallel with Darwin finishing this round.
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Read error: Connection reset by peer)]
jtojnar has joined joined #nixos-dev
JosW has quit [(Quit: Konversation terminated!)]
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
<Sonarpulse>
vcunat: which order is that?
jtojnar has joined joined #nixos-dev
<vcunat>
Sonarpulse: order? What do you mean?
<Sonarpulse>
vcunat: like is there a mass rebuild going on right now that shouldn't be interrupted?
<Sonarpulse>
or can i merge mine and then lnl's will just rebuild darwin for it?
* Sonarpulse
can get anxious about merging things as it's taken quite a while, that isn't either fault of yours, however
<vcunat>
I would lean no to cancel the current evaluation.
<gchristensen>
"configuration-ad-hoc-network-config.xml:12: parser error : expected '>' <title>Ad-Hoc Configuration</title> ^ configuration-networking.xml:18: element include: XInclude error : could not load configuration-ad-hoc-network-config.xml, and no fallback was found.f"
<Profpatsch>
These functions are not used yet in nixpkgs proper, I’d say we can change their interface.
<gchristensen>
Profpatsch: ^ how about that for error reporting
<vcunat>
Sonarpulse: seems OK to merge, having gotten a few reviews.
goibhniu1 has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 248 seconds)]
<Sonarpulse>
vcunat: thanks!
<Profpatsch>
gchristensen: Where’s that from?
<gchristensen>
daps :)
<vcunat>
I once wanted to look into using daps for our manuals, but it's never happened.
<Profpatsch>
That looks cool.
<gchristensen>
it also has spell check, man/html/mobi/webhelp/text/epub/pdf creation, autoformatting, style checking, image optimization, and link chhecking
<Profpatsch>
It seems to be a lot more specific, so it can probably give better error messages.
<gchristensen>
it requires we reorg our docs, but who cares?
<Profpatsch>
gchristensen: Should we merge the PR and wait until somebody rewrites everything in daps?
<gchristensen>
every single line of this file has been a struggle
<orivej>
Sonarpulse: my hydra has checked that https://github.com/NixOS/nixpkgs/pull/31414 does not break anything in nixpkgs on Linux. the point of not merging this until the current staging is merged into master is to be able to quickly fix it needed.
<orivej>
err, fix something in staging if needed before merge
<Sonarpulse>
orivej: it is nice to merge to staging when nothing else is outstanding
<Sonarpulse>
but i figure vcunat can always not merge staging tip or something
<Sonarpulse>
i dunno
<Sonarpulse>
like idealy staging would never be more than 1 pr or so ahead of master or something
<vcunat>
right, it makes such fixes more difficult, but at this point I thought it unlikely they will be needed
<orivej>
IHMO staging should be merged to master about once a week to reduce redownloads by the end users. It can accumulate as many PRs as happen in that time.
<vcunat>
(It's still possible to start with the older commit built on Hydra, add a few commits on top and merging the result to master, without creating another branch.)
<orivej>
vcunat: yes, but without building on Hydra
<vcunat>
yes
<vcunat>
At current rate we can't catch to rebuild each commit separately.
<orivej>
I can not reproduce the failure of https://hydra.nixos.org/build/64459883 , even though it appers that it was restarted on Hydra multiple times and failed each time...
<LnL>
Sonarpulse: that sounds fine to me, only issue with that is if something else needs to be fixed before the merge
<Sonarpulse>
LnL: yes, true
<LnL>
but I built the bootstrap tools and some other stuff so it should be fine
<gchristensen>
it still regularly points directly to /etc/xml/catalog
<jtojnar>
was not able to find any docs about requesting the merge rights
<orivej>
all but one nixpkgs:staging:*.x86_64-linux builds at https://hydra.nixos.org/machines are hung. could someone cancel them?
<gchristensen>
jtojnar: its on the website ... somewhere ... but basically you just say "hey I'd like merge rights, can that happen?" and then someone cc's domenkozar