<catern>
if anyone is interested in radical ideas about the future of nixpkgs, take a look at https://git.io/vxcGi where I sketch out something I think would be neat
<catern>
(clear clickbait)
bgamari- has quit [Ping timeout: 276 seconds]
<dtz>
^_^
bgamari has joined #nixos-dev
bgamari has quit [Ping timeout: 268 seconds]
ma27 has joined #nixos-dev
jtojnar_ has joined #nixos-dev
ma27 has quit [Ping timeout: 245 seconds]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 240 seconds]
bgamari has joined #nixos-dev
bgamari has quit [Ping timeout: 264 seconds]
Lisanna has quit [Quit: Lisanna]
bgamari has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pie_ has quit [Ping timeout: 264 seconds]
pxc has quit [Quit: WeeChat 2.0]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
<domenkozar>
I can still claim ghc depends on perl
<catern>
niksnut: that is effectively what my proposal is :) except my proposal actually scales
<gchristensen>
it massively scales the "pain because of git submodules' UX" though
<shlevy>
:D
<catern>
yes, very true ¯\_(ツ)_/¯
<gchristensen>
I think a nice thing about nixpkgs as a repo is it doesn't use many of git's features
<niksnut>
is it scalable though? if every package uses this, it means having tens of thousands of submodules
<niksnut>
not sure how well git will behave with that
<catern>
(I definitely agree that having to deal with submodules is worse than having a single repository, but my work heavily uses submodules to scale the volume of code and though I hated it at first, I now find it not *too* bad. (that is ultimately what inspired this proposal))
<shlevy>
Do we actually *want* submodules though?
<catern>
niksnut: yeah, that scales just fine - we have ~2500 submodules in our monorepo at work
<niksnut>
ok
<shlevy>
It seems like we just want a) a declarative way to specify what we depend on (fetchGit works fine) and b) an easy way to check them out and make changes
<shlevy>
Why not build tooling on top of what we have that doesn't require all the gymnastics submodules have to do to make it look like one tree but not really one tree etc.?
<gchristensen>
I do not want submodules
<niksnut>
right, I recall guix has an easy way to override sources (something like --with-source /my/sources), Nix should have something like that
<shlevy>
+1. They've been a huge pain in every project I've used them on
<shlevy>
To be clear, I'm not opposed to solving this problem. I just think we can do better than submodules.
<gchristensen>
same
<domenkozar>
+1 for not using submodules
<catern>
shlevy: yes, I am not saying submodules are a perfect solution or even a good one, although I do think they have an undeniable architectural elegance
<catern>
(though their UX sucks)
<catern>
architectural elegance for this use case, I mean
<gchristensen>
shlevy: ok I tried again to get mac1 to use Nix 2.0 for the daemon via nix-darwin. hydra says it mac1 is down, possibly because it lost too many connections to it during my attempts. let's keep an eye, and if mac1 comes online and starts building I'll scale out to a few more macs.
<shlevy>
gchristensen: Is the SDL issue a mac versioning thing?
<catern>
(and you don't need any new tooling to use them)
<gchristensen>
shlevy: I have no real idea about darwin stuff, other than I have nix-darwin and I know how to use it sorta.
<shlevy>
OK
<shlevy>
niksnut: Shouldn't hanging builds be killed eventually?
<LnL>
shlevy: I don't remember what the actual issue with sdl-config is, in the "fixed" builds we just skipped it IIRC
<shlevy>
Is that because the Nix there can't catch POLLHUP?
<gchristensen>
w00t mac1 is back in rotation.
<niksnut>
yeah I had disabled it, sorry about that
<gchristensen>
oh ok no worries :)
<gchristensen>
I'm glad I didn't break it
<niksnut>
shlevy: in principle that shouldn't matter
<niksnut>
timeouts are implemented by the local nix, not hydra
<shlevy>
Hmm OK
davidlt_ has joined #nixos-dev
<niksnut>
sadly, apple's developer hostility makes it hard to debug these issues
<shlevy>
:( yeah
davidlt has quit [Ping timeout: 240 seconds]
<niksnut>
killing the conftest makes the build continue
<shlevy>
amazing
goibhniu has joined #nixos-dev
<niksnut>
I need to disable mac1 for a bit again
<gchristensen>
ok niksnut, I'm experimenting on mac3
<shlevy>
I'm too fundamentally impatient to be a stdenv hacker
<shlevy>
llvm building for 45 minutes and only at 15% :'(
<gchristensen>
you need faster single-core performance
<gchristensen>
like a time-traveling debugger but for compilation
goibhniu has quit [Ping timeout: 240 seconds]
<gchristensen>
OK mac3 looks healthy on Nix2, thank you a lot LnL for your help. trying mac4 now!
<niksnut>
okay, the timeout issue was caused by "NIX_REMOTE=daemon" in ~/.ssh/authorized_keys
<shlevy>
Ah
<shlevy>
So it *is* the POLLHUP issue?
<niksnut>
no
<LnL>
\o/
<shlevy>
Or are timeouts not forwarded?
<niksnut>
it's that nix-store --serve doesn't propagate timeouts to the daemon
<shlevy>
Ah
<gchristensen>
niksnut: so that is being added by the nix-darwin deploy tool I have. should I drop that env var? (cc LnL whom I got that from)
<niksnut>
since the daemon connection is established before it gets the timeouts from the client
<shlevy>
Should we switch to ssh-ng?
<niksnut>
gchristensen: yes, it's unnecessary / inefficient to use the daemon
<shlevy>
OK
<gchristensen>
ok, dropping!
<LnL>
gchristensen: niksnut: should it be using nix-daemon --stdio?
<niksnut>
that will probably create all sorts of new and exciting problems
<LnL>
my setup doesn't use root for the build user so that's why I have it in there
<shlevy>
:)
<shlevy>
Nothing like dogfooding to expose our bugs
<LnL>
shlevy: build-remote now works with ssh-ng?
<shlevy>
Yep
<LnL>
nice!
<shlevy>
LnL: (that's nix-daemon --stdio ;) )
<LnL>
I can enable that on my setup for a while and see if I run into issues
<LnL>
ah right, I remember needing it for something with 1.12 :)
<gchristensen>
niksnut: how does this look: command="NIX_SSL_CERT_FILE=/nix/store/5kkw217xqighkdh0y4bl9wk8j42ixsbq-nss-cacert-3.34.1/etc/ssl/certs/ca-bundle.crt /nix/store/2jlsrxmx8h64iwss2yhjrf0skafgfmc9-nix-2.0/bin/nix-store --serve --write" ssh-rsa...
<niksnut>
gchristensen: it's probably not a good idea to put store paths in authorized_keys since it's not a GC root
<niksnut>
better to use /nix/var/nix/profiles/default/bin/nix-store
<Profpatsch>
Which could be a template on how Nix RFCs / Pull Requests can/should be handled.
<gchristensen>
the contents of the authorized_keys is from /etc/static which is part of a GC root, niksnut
<gchristensen>
I could switch over to the default profile, it'll take some work to make nix-darwin handle that nicely
<LnL>
I think you could use /run/current-system/sw/etc/... if you add it to systemPackages but that's kind of weird
<gchristensen>
I worry about getting out of Eelco's comfort zone here :)
<LnL>
but if you don't remove the default profile cacert will be in there, just might be a bit older
<shlevy>
Profpatsch: reading now, one thing it seems like we're missing is a chair who makes the call on whether objections are addressed/small enough to move past them
<Profpatsch>
shlevy: I don’t think rough consenus requires a chair; or for parts of the infrastructure the “chairs” are the people who built/maintain these parts.
<shlevy>
Profpatsch: The problem I've seen is that it is rarely if ever clear who even gets to say when we have or haven't reached consensus, who is driving toward consensus, etc.
<Profpatsch>
But an awesome thing about rough consenus is that it’s organic and the results of a decision should be obvious by reading through the discussion and knowing about how rough consenus works.
<gchristensen>
niksnut: I think this should work okay, but I think you're right about using the default profile longer term. in the interest of getting Nix2 on all the macs I'm going to go ahead and finish it unless you strongly disagree, then try fixing the default profile problem
<shlevy>
In practice though that doesn't happen. WHat specifically do you think we should change to make it happen in the future, if not assign someone tomake the call?
<Profpatsch>
shlevy: True; but maybe the solution is that anybody who takes up the initiative can act as chair.
<niksnut>
gchristensen: ok, thanks
<Profpatsch>
And by taking the initiative is to lead to a rough consenus and then follow up with code.
<gchristensen>
thanks!
<shlevy>
Sure, that's a reasonable approach (so long as proposers have a decent base of trust)
dtz has quit [Ping timeout: 248 seconds]
olejorgenb[m] has quit [Ping timeout: 248 seconds]
<shlevy>
I think I could get behind that model
<Profpatsch>
Sure, trust is required, and that requires a community where everybody assumes the other is acting out of good will/intensions.
<Profpatsch>
That’s a requirement I think.
<shlevy>
Yeah
<shlevy>
I guess "commit bit on the RFCs repo" is a decent proxy for trust
<shlevy>
And if someone makes a proposal that doesn't have it, they can either request it or request someone who has it to "chair" the decision
<shlevy>
(just thinking as a first-pass approach)
olejorgenb[m] has joined #nixos-dev
dtz has joined #nixos-dev
<shlevy>
Profpatsch: If you wanted to write up an RFC for adopting rough consensus with explicit chairs I'd probably coauthor
<shlevy>
The paragraph starting "Now, a conclusion of having only rough consensus relies heavily on the good judgement of the consensus caller." seems key
<Profpatsch>
shlevy: I bet that RFC never gets implemented because we don’t have a structure to decide on such matters. :D
<niksnut>
eh
<niksnut>
didn't we just create nix-core for this?
<shlevy>
niksnut: That only applies to Nix
<shlevy>
niksnut: And isn't part of the point to provide a base to determine a working governance model?
<Profpatsch>
I think we already use rough consenus in practice.
<Profpatsch>
Though that RFC could help give it a name.
<niksnut>
shlevy: yes, with the possibility of extending it to nixpkgs/nixos
<niksnut>
it seems strange to already start thinking about a *different* governance model for nixpkgs/nixos
<shlevy>
Fair
Sonarpulse has joined #nixos-dev
ashgillman has quit [Ping timeout: 252 seconds]
<gchristensen>
niksnut: didn't we used to have a mac9?
<niksnut>
yes
<niksnut>
I don't know why it's disabled
<niksnut>
let's try
<Sonarpulse>
angerman: do you mind if I push to your PR?
<Sonarpulse>
(force push, that is, cause I'll rebase it)
<fpletz>
"It is a error message in a 1987 Texas Instruments computer operating system left in by accident"
<gchristensen>
that is definitely a mistake I would make ;)
Lisanna has joined #nixos-dev
<Mic92>
this should not give me any results: nix why-depends nixpkgs.pandoc nixpkgs.ghc
<Mic92>
pandocs contains string references to /nix/store/ghjrl4kznrfy2l89b5yb94gb60rxb7w1-pandoc-types-1.17.3.1/bin
<Mic92>
which eventually end up in having to download ghc for pandoc
goibhniu has quit [Ping timeout: 248 seconds]
<gchristensen>
gross!
<Mic92>
this recently broke, let's check
jtojnar has joined #nixos-dev
GlennS has quit [Remote host closed the connection]
<Mic92>
a question to the haskell people: I have a series of variables set in the binary: pandoc_types_bindir, pandoc_types_libdir pandoc_types_dynlibdir, pandoc_types_libexecdir etc
<Mic92>
who does set this?
<Mic92>
the same seems to be set for other libraries linked into pandoc