jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
vcunat has quit [Ping timeout: 252 seconds]
vcunat has joined #nixos-dev
Mic92 has quit [Ping timeout: 240 seconds]
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
Mic92 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
Lisanna has joined #nixos-dev
cstrahan has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 240 seconds]
Lisanna has quit [Ping timeout: 256 seconds]
Lisanna has joined #nixos-dev
davidlt has joined #nixos-dev
vcunat has quit [Quit: Leaving.]
MichaelRaskin has quit [Quit: MichaelRaskin]
<mbrock>
without nix-push, is there any way to generate the .nar.xz and .narinfo files? nix copy doesn't do it like that, so I don't know how to generate my binary cache anymore
<mbrock>
ahh, I was missing the file:// prefix I guess
<LnL>
yeah, nix copy --to file://
goibhniu has quit [Quit: Leaving.]
goibhniu has joined #nixos-dev
ckauhaus has joined #nixos-dev
ckauhaus has quit [Remote host closed the connection]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Remote host closed the connection]
<Mic92>
gchristensen: Depends on the project. Usually I do my nix-review tool, which is my variant of nox-review. If the rebuild amount is small, I paste all rebuilded packages into the build bot as well. When the package comes from a user, that has tested the package I only do some sanity checks like `for i in $out/bin/*; do $i < /dev/null; done`. I also check what the package has installed `find $buildInputs`.
<Mic92>
For pure build fixes, when only a cflag is added I usually rely on the borg output these days. Automatic pull requests testing is kind of a problem though, because then I really have to know how the package works - since I have no users to rely on.
<gchristensen>
yeah
<Mic92>
Then I also have to checkout the changelog to see if I have to expect bigger breakages.
<gchristensen>
you might be the most thorough PR checker
<LnL>
yeah, I don't really go and look at the changelog unless it's something I use myself
<LnL>
and usually only test one or two packages that depend on it
ckauhaus has quit [Remote host closed the connection]
ckauhaus has joined #nixos-dev
<gchristensen>
oxij is tiring :(
<gchristensen>
I'd love to be able to accept _part_ of their patches sometimes and delete other parts
orivej has joined #nixos-dev
<Mic92>
gchristensen: make a new pr, if you mean the configuration.nix update.
<gchristensen>
yeah
<gchristensen>
I don't want to get in to a fight with them
<gchristensen>
they're very effective at grinding their pulseaudio axe
<Mic92>
gchristensen: then lock the pr
<gchristensen>
=) <3 thank you Mic92
ckauhaus has quit [Remote host closed the connection]
sonarpulse has joined #nixos-dev
<Mic92>
Sonarpulse: how fare did you came, when cross-compiling from linux for darwin? (This message has been postponed on 2018-03-09 11:45:49.)
ckauhaus has joined #nixos-dev
<gchristensen>
niksnut: can you allow all nixpkgs contributors to merge PRs on nix-pills?
<gchristensen>
oh maybe I can do thaht
<sonarpulse>
Mic92: decently
<sonarpulse>
I keep on forgetting what LnL7 and I got stuck on
<sonarpulse>
i guess I blocked for the meta.platforms fix
<sonarpulse>
but that isn't really a blocker
<sonarpulse>
just makes things cleaner
<Mic92>
Sonarpulse: at the moment it leads to infinite recursion. Did you ever commit your changes?
<Mic92>
But at least I know it is possible
<sonarpulse>
see LnL's branch?
<sonarpulse>
I should finish up that PR
ckauhaus has quit []
<LnL>
Sonarpulse: Mic92: linux headers
<niksnut>
gchristensen: did you do it?
<gchristensen>
niksnut: I did, is that okay?
<niksnut>
sure
<gchristensen>
cool, thanks :) I can't address the PRs there regularly enough
<Mic92>
Sonarpulse: you can merge now your own nix pills pr's
<shlevy>
bgamari-: Yikes. You may want to look at my DBI postInstall for vague outlines on getting started, I'll try to take a look myself hwen I get a chance
<gchristensen>
reboot any time someone mentions hydra on irc
<cransom>
is hydr<System going down for a reboot NOW>
<gchristensen>
#1 rule of the build system is don't talk about the build system
<makefu>
i'd rather add this watch dog for the mailing list. just have multiple stages: stage 1: nix-collect-garbage, stage 2: restart all the services, stage 3: destroy machine and rebuild
<makefu>
go into next stage if new mails arrive in the same thread
<niksnut>
hydra unikernel!
<clever>
i heard somebody mention before, that they had a system setup, where if anybody ssh's into a machine for any reason, 10 minuts after the DC, nixops would destroy and remake it
<clever>
no impurity will survive!
<shlevy>
:D
<gchristensen>
I had that at my last co, except it was 24hrs and w/out nixops
<gchristensen>
err... 2 co's ago
<clever>
ah, maybe it was you, and i just got things mixed up a bit
<gchristensen>
SSH would mark the machine as tainted and queue it for termination within 24hrs, and machines auto-tainted themselves after 90d
<gchristensen>
this was with a chef-based deployment, so much harder to track impurity :) it was a really effective way to force fixes being applied via chef
<gchristensen>
makefu says the github bot is annoying. should we just disable the bot altogether?
<gchristensen>
I've been banning it on long PR sprees
<gchristensen>
cransom agrees
<shlevy>
I've personally liked it as a way of getting a peek into activity without having to subscribe to all of nixpkgs
<samueldr>
make it post to #nixos-firehose ?
<shlevy>
Nah, I'd never check it :D
<shlevy>
Not a big deal though
<cransom>
in my own house, i try and keep the more frequent bots in a separate channel than the humans
<gchristensen>
I'll just make it PM you ;)
<cransom>
i could always just ignore the bot too.
<makefu>
worst thing with the github bot is merges with multiple lines in the chat. 3 lines of noise
<MichaelRaskin>
I guess I agree with oxij that the list version should just filter, not put nulls
<shlevy>
I agree too
<shlevy>
nulls toStringing to "" is not worth relying on
<shlevy>
[] toStrining to space-separated strings is especially not worth relying on in the __structuredAttrs world
<MichaelRaskin>
What does that do?
<shlevy>
MichaelRaskin: Primarily it puts the arguments to derivation into structured JSON
<shlevy>
secondarily, and tbh I'd rather this be part of stdenv, it makes a .attrs.sh that bash can source to do things like putting lists into bash arrays
<MichaelRaskin>
Ah
LnL has quit [Ping timeout: 256 seconds]
<MichaelRaskin>
shlevy: do you have any vision how to fight the combinatorial product problem?
<MichaelRaskin>
(yeah, I know, I am quite predictable)
<shlevy>
Well the default case is simple
<shlevy>
zlib = {};
<shlevy>
I'd like to language-extend that to just zlib;
<shlevy>
The lib.systems stuff probably should fall under Eelco's dynamic scoping proposal
<MichaelRaskin>
Why attrset and not list?
LnL has joined #nixos-dev
<shlevy>
1) ordering shouldn't matter and where it does it's probably a bug, 2) lists of attribute sets are ugly, 3) so you can do bison instead of "bison" without actually having to have the package in scope at the time
<shlevy>
But, to be fair, that's literally what we have with callPackage :P
<gchristensen>
as an impleme/ntation detail, not a fundamental truth
<shlevy>
It leaks through
<shlevy>
I don't think it's really just a detail
<gchristensen>
it does?
<shlevy>
And I think Eelco's proposal reflects this, in wanting to remove inputs from arguments
<shlevy>
Simple example: If you take pkg-config as an input and then evaluation fails because it's named pkgconfig in all-packages.nix, do you set pkg-config = pkgconfig in all-packages.nix or change your argument name?
<gchristensen>
This feels like a straw man
<shlevy>
Our current real usage is nearly completely isomorphic to string-based lookup, with twice the verbosity
<shlevy>
Anyway
<shlevy>
I'll wait to defend until I have a full proposal
<MichaelRaskin>
Well, all the attempts to dump the verbosity are declared ugly hacks…
<shlevy>
But I don't think we can really get around this issue if we want to do introspection without full composition
<shlevy>
MichaelRaskin: Maybe try again? It's been a long time and the community has changed a lot
<shlevy>
In particular, this whole discussion is centering around completely changing the language :P
<MichaelRaskin>
I don't have any idea what people currently consider design goals in that endeavour.
<MichaelRaskin>
And I know that designing a language that would be convenient for me… well, won't work.
<MichaelRaskin>
I mean, it will work in terms of getting a language definition, but won't work in terms of getting enough people to agree that it is a good idea.
<MichaelRaskin>
shlevy: won't completely changing the language lead to addition of static type inference, then to replacement of the language with Haskell?
<shlevy>
MichaelRaskin: I wish you'd sketch your ideas out at least. I'd like to see them.
<LnL>
Sonarpulse: there is a 18.03 branch... ;)
<MichaelRaskin>
Right now I don't even try to think them through coherently, though.
<shlevy>
Do you have ml threads or anything from previous times you tried at least?
<MichaelRaskin>
shlevy: maybe there could be some issue for just collecting design subgoals, to measure some initial reactions?
<MichaelRaskin>
That was in some old mailing list threads…
<MichaelRaskin>
For example at some point I have mentioned, that if overriding a bash derivation piece-by-piece to actually build binutils is hard but possible and transparent, I would find that a plus, and a powerful enough override system cannot avoid being able to do this.
<MichaelRaskin>
Oh well, _now_ overrideDerivation does allow it, but not in the most transparent and comprehensible way.
<MichaelRaskin>
Also, is the goal to make Nix small again by hardwiring things that now require complicated Nix code, or to admit that Nix is a general pure-computation programming language and should be convenient and efficient from that point of view?