LnL has joined joined #nixos-dev
LnL has quit [(Ping timeout: 252 seconds)]
seppellll has quit [(Ping timeout: 248 seconds)]
mbrgm has quit [(Ping timeout: 240 seconds)]
mbrgm has joined joined #nixos-dev
michaelpj has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
michaelpj has joined joined #nixos-dev
JosW has joined joined #nixos-dev
zraexy has quit [(Ping timeout: 258 seconds)]
LnL has joined joined #nixos-dev
MoreTea has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 240 seconds)]
FRidh has joined joined #nixos-dev
MoreTea has quit [(Ping timeout: 248 seconds)]
kuznero has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
__Sander__ has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 248 seconds)]
FRidh has joined joined #nixos-dev
jtojnar_ has quit [(Ping timeout: 248 seconds)]
jtojnar_ has joined joined #nixos-dev
seppellll has joined joined #nixos-dev
seppellll has quit [(Ping timeout: 258 seconds)]
sivteck has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 248 seconds)]
sivteck has quit [(Quit: user missing.)]
sivteck has joined joined #nixos-dev
FRidh has joined joined #nixos-dev
sivteck has quit [(Quit: user missing.)]
seppellll has joined joined #nixos-dev
<LnL> is there something wrong with the *-unstable channels?
<LnL> recent builds are green but they have not updated for a couple of days
sivteck has joined joined #nixos-dev
sivteck has quit [(Read error: Connection reset by peer)]
sivteck has joined joined #nixos-dev
sivteck has quit [(Quit: user missing.)]
<copumpkin> niksnut: okay, after that comment I give up on 408 :P
<kuznero> Can you please give any general recommendations for the one willing to become part of nixos org on github?
<goibhniu> kuznero: you'd like to be able to merge PRs?
<copumpkin> kuznero: the usual guidance is just to ping ikwildrpepper after contributing a fair number (I've seen 50-100) of useful PRs or work in other ways
<kuznero> goibhniu: eventually, yes. ok
<kuznero> copumpkin: thanks! got the idea
<copumpkin> no rules set in stone as far as I know. If you have one PR that revolutionizes how Nix works and everyone loves it, I'm sure they'd probably be fine with it. Just looking for some demonstration that you won't go screw up the repo if people stop paying attention :)
<goibhniu> I see you have 8 PRs so far.
<gchristensen> it is a bit early, but I'd love for you to join when you've gotten enough practice, kuznero.
<goibhniu> Also, if you make sensible comments on other PRs and help people out with getting them merged, that would be great.
<copumpkin> yeah, we're drowning in PRs, so testing them and providing feedback, etc., will be very helpful
<copumpkin> drowning in PRs is a good problem to have, but still a problem :)
<kuznero> I see the point. Thanks! This is good enough guidelines for me going forward :) Hope to bring some more folks from my work place. Not sure though if they are going to be contributing, but at least using NixOS.
<copumpkin> yay
<goibhniu> o/
<kuznero> copumpkin: so, jumping on PRs that are sitting there and see how I can help with those... that sounds like interesting way to keep learning :) Will try
<copumpkin> yeah obviously defer to others if you don't know what's going on (providing bad advice is detrimental, and we've even had newish folks go insulting contributors, so please don't do that either :P) but anything you can help with would be great
<kuznero> will try to do my best :)
<gchristensen> kuznero: and mistakes are okay, do your best and we'll be glad to have you
<kuznero> gchristensen: thanks
<gchristensen> "code owners" seem not so helpful, they just always request a review from eelco
sivteck has joined joined #nixos-dev
<goibhniu> kuznero: also, updating packages is nice. If you're looking for something to work on: https://repology.org/repository/nix_unstable provides a good overview.
<kuznero> goibhniu: thanks
<kuznero> would be interesting to have such stats pulled into one place - rather undescoverable
<goibhniu> np, yes indeed
<copumpkin> ooh interesting! link from readme?
<copumpkin> would be interesting to see what it uses to detect "metapackages", compute outdated, etc.
<copumpkin> oh we publish a packages.json or something don't we
<gchristensen> I wonder if grahamcofborg should have a "small" tag for not-mass-rebuilds. this hints towards those buckets raskin was suggesting
<gchristensen> https://github.com/NixOS/nixpkgs/pull/30817 hard to know if this just hasn't been checked, or isn't a M.R.
<copumpkin> yeah, or what Raskin was proposing on list: a few buckets in tags
<copumpkin> possibly colored appropriately :) green to red
<copumpkin> so everything gets tagged with some number of rebuilds, and one tag could be 100% green for a single rebuild
<gchristensen> want to make the labels and send me a PR? :)
<copumpkin> I added a few colored labels, wanna check them out?
<copumpkin> can't make PR right now but will later
<gchristensen> I'd skip 2-10, make it just 1-10, and add a 100-500
<copumpkin> wanted to make it clear if a package was isolated or had even a small number of deps
<copumpkin> since it tells me if @grahamcofborg package-name is sufficient to "test" it
<gchristensen> ah, cool
<copumpkin> although telling grahamcofborg to "build-changed" might also be enough
<globin> copumpkin: yes repology uses the packages.json + a hidden package.json for the unstable channel
<copumpkin> instead of enumerating things explicitly, we check how many rebuilds it would be and then only do it if fairly small
<gchristensen> yeah that could do
<copumpkin> I'll leave 1 out for now
<copumpkin> so you think the 500-1000 range is interesting?
kuznero has quit [(Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)]
<copumpkin> or should I just do 100-500 and then 500+
<copumpkin> globin: yeah, cool. Mapping package names to known versions seems tricky in general though
<copumpkin> some of them have very generic names
<globin> copumpkin: yup but it really is quite good at it
<niksnut> copumpkin: he's misguided
<niksnut> sure, it's not an error from the POV of the server
<niksnut> but the client should still retry...
<copumpkin> yeah
<copumpkin> hoping my latest comment will sway
<niksnut> it just says "remove this stale connection from yoyr connection pool"
<niksnut> also, there is nothing that clients of aws-sdk-cpp can do to prevent this
<copumpkin> other than retry like 3 layers up :P
<niksnut> the use of a connection pool is an internal detail of aws-sdk-cpp that shouldn't be exposed
<niksnut> yeah, this makes the retry logic in aws-sdk-cpp kinda pointless
<copumpkin> maybe mention that too? I didn't realize that the pool stuff was in there
<niksnut> if we need to implement our own retry on top of it
<globin> copumpkin: would be nice if we'd include all language in the packages.json, those would be interesting, too => probably build special package.jsons for repology
<copumpkin> yeah
<gchristensen> ok y'all, I'm shutting down grahamcofborg for most of the next day, only running when I have 100% battery and am plugged in to charge
<copumpkin> :) cool
<copumpkin> gchristensen: any thoughts on 500 vs. 1000?
<copumpkin> I'm thinking 101-500 is interseting range and then 500+
<gchristensen> cool, and >??? can be the standard mass-rebuild
<copumpkin> yeah
<globin> gchristensen: have a power socket adapter with you? ;)
<gchristensen> :shipit:
<copumpkin> although I guess some folks might still want to treat "changes the stdenv" as special
<gchristensen> globin: 2! :)
<copumpkin> could just be 10.rebuilds-linux: stdenv
<globin> gchristensen: whoa %)
<copumpkin> ?
<copumpkin> that would be pretty clear about the definition
<gchristensen> copumpkin: meh, they can send a PR if they'd like
<copumpkin> ok :)
<gchristensen> globin: one for Emily :)
<copumpkin> okay, the tags are colored and sized appropriately
<copumpkin> gchristensen: https://github.com/grahamc/network/pull/2 whoops
<copumpkin> I guess there's a special case of "rebuilds: 0
<copumpkin> that is unhandled right now
zraexy has joined joined #nixos-dev
sivteck has quit [(Quit: user missing.)]
sivteck has joined joined #nixos-dev
jtojnar_ has quit [(Remote host closed the connection)]
Sonarpulse has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 240 seconds)]
__Sander__ has quit [(Quit: Konversation terminated!)]
<aminechikhaoui> What should be the ownership of the /nix/var/nix/gcroots/hydra/ folder in a hydra instance ?
<aminechikhaoui> I think I messed up a bit with that folder and the hydra-queue-runner of my server is barfing about permission denied of non existent roots
<aminechikhaoui> ah wait the group was root -_-
goibhniu has quit [(Ping timeout: 240 seconds)]
sivteck has quit [(Quit: user missing.)]
seppellll has left #nixos-dev ["Leaving"]
sivteck has joined joined #nixos-dev
<copumpkin> in ‘toFile’: the file ‘x.json’ cannot refer to derivation outputs :(
<copumpkin> :( :( :(
MichaelRaskin has joined joined #nixos-dev
<copumpkin> niksnut: is there a good way to get nix-instantiate to spit out .drvs it finds along the way during an --eval --strict?
<niksnut> copumpkin: don't think so
<copumpkin> :( I'm trying to get --eval --strict --json to contain valid paths and it's proving to be a real PITA
<copumpkin> I tried writeText (builtins.toJSON ...) as a derivation and that's proving to be a pain because it's a real derivation and doesn't work if system != currentSystem
<copumpkin> builtins.toFile refuses to write strings with dependencies
<MichaelRaskin> Well, there is discarding context (although it is unsafe, but it exists.)
<MichaelRaskin> builtins.unsafeDiscardStringContext
<copumpkin> hmm, but that wouldn't work either because I want it to actually build the thing
<MichaelRaskin> In the same pass? You could xargs nix-store -r the file
<copumpkin> well, the thing is a nontrivial structure I'm dumping to JSON
<copumpkin> and it has strings with deps at various points in the structure
<copumpkin> like I really just want nix-build --eval --strict --json :P
<copumpkin> instead of nix-instantiate :)
<LnL> what about a drv that writes builtins.toJSON
<copumpkin> that's what I have right now, but now that drv has dependencies of its own and has a system and I can't run it across systems
<LnL> ah
<copumpkin> whereas in principle there's no reason for the JSON to be bound to a system
<MichaelRaskin> But then it cannot realise the dependencies?
<copumpkin> that's fine
<copumpkin> just need to query them
<MichaelRaskin> But then the JSON cannot be written either, right?
<LnL> how do you do that part with toJSON?
<copumpkin> well, if I use nix-instantiate --eval --strict --json
<copumpkin> then I can write the JSON :)
<MichaelRaskin> If the JSON file has dependencies, you cannot write it unless they can be realised.
<copumpkin> I know, I don't want a JSON file as a derivation
<copumpkin> that seemed like a quick hack
<MichaelRaskin> Can't you just discard the context, write JSON then scan for store path format?
<LnL> then you'd miss dependencies, but the json output should be equivalent
<copumpkin> yeah I can scan outside of nix, but I need the .drvs out of it, not the actual output paths
<copumpkin> what I long for is a Nix API :P
<LnL> pretty sure builtins.unsafeDiscardStringContext "${drv.drvPath}" would work
<copumpkin> so I don't need to go weaseling around in all the command-line options hoping that one of them matches my needs
<infinisil> What would that API entail?
<copumpkin> LnL: but I need all the .drvs for the things inside the JSON
<copumpkin> infinisil: I dunno, lower-level access to all this stuff that doesn't precompose the various operations :)
<LnL> oh, so you're using nix-store -qR now?
<copumpkin> yeah among other things
<copumpkin> or trying to
<copumpkin> this is all about evaluating stuff on one platform against another platform
<infinisil> that very much sounds like you want nix-store -qR indeed
<copumpkin> to check contents of a binary cache
<copumpkin> think nix-build --dry-run
<LnL> yeah, don't about anything that would help there
<LnL> except what you're doing right now
sivteck has quit [(Quit: user missing.)]
<infinisil> I also like to combine nix-instantiate --eval --json with jq and do some fancy operations on the data
sivteck has joined joined #nixos-dev
<MichaelRaskin> clever: maybe what you want is adding builtins.stringDependencies
<MichaelRaskin> (I mean adding a builtin to Nix)
<clever> MichaelRaskin: to replace builtins.storePath?
<MichaelRaskin> Erm, why replace?
<MichaelRaskin> You want a list of derivations that are dependencies of your string?
<MichaelRaskin> You would need two Nix passes: one to discard dependencies and write the string, and one to instantiate the dependencies
<copumpkin> I still don't know how to instantiate the dependencies though
<copumpkin> without bringing in a bunch of other junk
<copumpkin> I guess I could use the derivation primop :)
<copumpkin> feels really shitty though
<infinisil> But isn't that what you need to instantiate them?
<infinisil> Ah no
<copumpkin> I don't even need to discard dependencies if I just want the JSON
<copumpkin> I can use --eval --strict --json
<copumpkin> the question is just how to talk about the dependencies of that output
<MichaelRaskin> I guess you need to add a builtin so that you can do builtins.toJSON + builtins.stringDependencies.
<MichaelRaskin> Should be mergeable, it is not like you add GPGPU support to Nix (which will also be added eventually, but that will be a heroic epos)
zraexy has quit [(Quit: Leaving.)]
zraexy has joined joined #nixos-dev
bgamari has joined joined #nixos-dev
<bgamari> Sonarpulse, duly noted
gleber_ has joined joined #nixos-dev
sivteck has quit [(Quit: user missing.)]
<copumpkin> have any of you ever longed for path references with magic sharing/symlink trees?
<Sonarpulse> copumpkin: you mean normalizing /nix/store subtrees with their own hash?
<copumpkin> I mean actually sharing subtrees of our standard path references
<Sonarpulse> well, it's related
<Sonarpulse> with intensional store
<Sonarpulse> dedup of subtrees
<copumpkin> ./foo/bar will copy potentially a ton of stuff if even one file changes
<Sonarpulse> is free and mandatory
<Sonarpulse> oh when coppying in new paths
<gleber_> oh, what is the status of intensional store?
<copumpkin> it lives on in our heads
<copumpkin> I think niksnut had a prototype a bajillion years ago
<bgamari> Sonarpulse, I believe the fix is simply setting USE_LIBPATH=yes
<bgamari> in genscripts.sh
<Sonarpulse> bgamari: oh!
<bgamari> I'm testing a patch now
<Sonarpulse> bgamari: thanks!
<fadenb> more and more people joining tomorrow evening :) will have to increase the number of reserved seats :p
zraexy has quit [(Ping timeout: 260 seconds)]
<gchristensen> copumpkin: nice
JosW has quit [(Quit: Konversation terminated!)]
<gchristensen> copumpkin: problem: nixpkgs/maintainers/scripts/rebuild-amount.sh doesn't seem to work for small PRs
<copumpkin> :O
<copumpkin> how does it fail?
<gchristensen> it seemingly returns nothing
<copumpkin> interesting
<copumpkin> not sure though
<gchristensen> $(nix-instantiate --eval -E '<nixpkgs/maintainers/scripts/rebuild-amount.sh>') 'origin/master' is what I run
<gchristensen> (basically)
<copumpkin> maybe worth summoning vcunat?
<copumpkin> or we can bug him at nixcon
<copumpkin> oh it was pierron
<copumpkin> whom we can also bug at nixcon
<gchristensen> :)
<gchristensen> `set +eux; set -o pipefail` ok what's goin on
<pierron> copumpkin: what have I done?
<gchristensen> the danger of fixing this script is becoming responsible for it
<copumpkin> actually it looks like it's not your script anymore pierron
<copumpkin> git says you created but it seems like someone changed it a lot
<copumpkin> not sure who, based on github
<copumpkin> all the diffs are attributed to a merge commit from vcunat
<copumpkin> which seems odd
<copumpkin> yeah that was the first one
<copumpkin> but now it looks very different, and the blame is all on that merge commit: https://github.com/NixOS/nixpkgs/blame/master/maintainers/scripts/rebuild-amount.sh#L98
<pierron> I was the first! o/
<copumpkin> :D
<gchristensen> wow that is a lot nicer than it is now
<pierron> lol “Versionning for Dummies”
<copumpkin> okay judging from the two parents of the merge commit, the diff actually came from the merge o.O
<copumpkin> a big part of the diff is: s/^#.*$//g
<copumpkin> :P
<MichaelRaskin> Versioning for Dummies: 1. Use Git. 2. Expect to get any useful history out of it. 3. You are dummy.
<copumpkin> MichaelRaskin: you going to nixcon btw?
<MichaelRaskin> No
<gchristensen> bummer
<copumpkin> have I already linked this btw? https://medium.com/@Pinterest_Engineering/continuous-integration-for-ios-with-nix-and-buildkite-ef5b36c5292d or someone else probably did
<fpletz> gchristensen: ircing from the airport? :)
<gchristensen> yeah :) my best train to the airport got here like 4 hours early >.>
<pierron> MichaelRaskin: no, this is the content of a comment in the initial version of the file.
<pierron> MichaelRaskin: for when your VCS are different directories where each one contains a different version of Nixpkgs.
<gchristensen> copumpkin: I think the problem is I'm using origin/* and it resets origin/master to be the same commit I'm comparing against
<copumpkin> I'd probably separate the concerns in that script
<copumpkin> like the VCS management from the "I have two nixpkgs, what's different about them"
<copumpkin> having it try to automatically shuffle git revisions sounds kinda awkward
<copumpkin> that looks pretty promising
<copumpkin> are you also running the darwin one?
<gchristensen> yeah
<copumpkin> hm?
<disasm> wait, I thought gchristensen was flying yesterday?
<gchristensen> copumpkin: it showed I added the event three times, but it seems to have collated it
<gchristensen> collected it* d'oh
<gchristensen> copumpkin: I'm seeing the socket drop issue again :(
<pierron> how much time is there between the airport and the city center?
<pierron> I guess I could ask google :/
<pierron> 42 minutes … I am definitely going to be late for dinner :/
<MichaelRaskin> Why twice the same label?
<ekleog> hmm... should I add myself as meta.maintainer of the modules I write? it looks intermittently done across the tree
zraexy has joined joined #nixos-dev
<gchristensen> can't hurt
<ekleog> 'k thanks :)
Sonarpulse has quit [(Ping timeout: 248 seconds)]