ekleog changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
Melkor333 has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
<matthewbauer[m]> Is anyone here familiar with how separateDebugInfo works? Why is it not enabled by default?
init_6 has joined #nixos-dev
pie___ has joined #nixos-dev
pie__ has quit [Ping timeout: 245 seconds]
jtojnar has quit [Ping timeout: 272 seconds]
drakonis has quit [Quit: WeeChat 2.3]
jtojnar has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pie___ has quit [Ping timeout: 250 seconds]
hedning has joined #nixos-dev
pie_ has joined #nixos-dev
andi- has quit [Ping timeout: 250 seconds]
<etu> Hi, in thinking of making a new directory in nixpkgs for hamradio packages. Now I think most of those are in "pkgs/applications/misc/" but I think that "pkgs/applications/hamradio" would be better. I also have the plan to package up more of those applications that people use to make a liveiso of NixOS with those to spread on the internet :)
<etu> Thoughts on making this new directory?
andi- has joined #nixos-dev
<clever> etu: sounds like a good idea to me
andi- has quit [Excess Flood]
andi- has joined #nixos-dev
<emily> maybe pkgs/applications/radio to be shorter/more generic?
pie_ has quit [Ping timeout: 240 seconds]
<etu> emily: Sure, that works as well
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
<gchristensen> would anyone be interested in building drv's for me to check for reproducibility? right now I build them all myself, which is fine, but if other people wanted to, too, it would increase confidence (by building them on more diverse systems)
<lassulus> I would be interested, what do I need to do?
<gchristensen> this is just a poll for now :)
<gchristensen> I don't have a way to contribute yet
<gchristensen> lassulus: I'll PM you when I have more :) thank you!
<lassulus> ok, cool!
drakonis has joined #nixos-dev
asymmetric has joined #nixos-dev
init_6 has quit []
init_6 has joined #nixos-dev
init_6 has quit []
<infinisil> gchristensen: Yeah I'd help out with that too
<tilpner> gchristensen: As long as it's just "build this part of nixpkgs", and you already had a module for it... sure
<gchristensen> it'll be something like that
asymmetric_ has joined #nixos-dev
asymmetric has quit [Ping timeout: 245 seconds]
<gchristensen> matthewbauer[m]: do you know the next time staging-netx merges?
<matthewbauer[m]> It should be soon
<gchristensen> cool
<matthewbauer[m]> We might want to wait until all of the queued jobs finish: https://hydra.nixos.org/jobset/nixpkgs/staging-next
<matthewbauer[m]> Otherwise though it looks like it's ready
<gchristensen> I could bump their priorities?
<matthewbauer[m]> Yeah although the queue it's pretty much the only thing in the queue right now. Hoping we can merge it today or tomorrow.
<matthewbauer[m]> Maybe better to cancel some of the older staging-next jobs if that's possible?
asymmetric_ has quit [Remote host closed the connection]
<gchristensen> sure
<gchristensen> only 158 of them were non-current though :)
<gchristensen> it would be interesting to teach diffoscope abut NAR files
asymmetric has joined #nixos-dev
pie_ has joined #nixos-dev
orivej has joined #nixos-dev
asymmetric has quit [Remote host closed the connection]
asymmetric has joined #nixos-dev
asymmetric has quit [Remote host closed the connection]
asymmetric has joined #nixos-dev
JosW has joined #nixos-dev
<gchristensen> lassulus, infinisil, tilpner: would you be opposed to running something like an ipfs node to participate?
<lassulus> ipfs was on my list of technologies to check out, I would be ok with that
<gchristensen> it is a bit annoying of a requirement. I'm thinking of ways to get differing NARs off build machines
<tilpner> gchristensen: I'd need to know more. Would I serve the entire closure via ipfs? Can ipfs serve from the store, or does it duplicate the store paths? Does IPFS have a GC? Can I keep just one full closure?
<tilpner> (I never had a usecase for IPFS, so I haven't played with it yet)
<gchristensen> for each build which was not reproducible, you would serve 2 archives of the store path which was not reproducible
<gchristensen> so you'd have ij6wirzff9id7jr071p04w4nk6hksc3y-bash-interactive-4.4-p23.a.tar and ij6wirzff9id7jr071p04w4nk6hksc3y-bash-interactive-4.4-p23.b.tar (or something like that)
<gchristensen> it would GC, yes
<tilpner> If it's only unreproducible paths, what about pushing those from the build machines instead of pulling via ipfs?
<gchristensen> I think that would be nicer, but a bit challengeng w.r.t. access control of who can push what
<gchristensen> nicest for me (?) would be each builder provides their own upload-to-somewhere-fetchable-by-curl
<gchristensen> but that is annoying too ;)
<tilpner> I think you can do that with ~~black magic~~ Bucket access policies
<tilpner> Or just host a Minio instance and give each machine their own user and bucket
<tilpner> I don't mind IPFS that much, but not having it might enable more users to join
<gchristensen> I also see the value in that
<tilpner> I recently fought the Wasabi bucket policies to create a bucket where each user had a directory they could write to
<gchristensen> hehe, wasabi is in magically-cheap territory
<tilpner> They did turn out to have a well-hidden minimum cost of $5/m
<gchristensen> I also was unimpressed to be billed $5 for a single empty file
<tilpner> But they were faster than B2 (from Europe), and had fine-grained access (unlike GCP)
<tilpner> (I even tried Tahoe-Lafs because you mentioned that, but didn't quite get comfortable with it)
<thoughtpolice> gchristensen: I'd be interested in participating probably, I have a bit of spare compute. I wouldn't necessarily be opposed to doing an IPFS node but tbh I already have some infrastructure set up for using Backblaze B2, myself...
<thoughtpolice> gchristensen: I could probably contribute two nodes actually, my ThreadRipper and an online Ubuntu (sandboxed) machine...
<gchristensen> ooh neat :)
<gchristensen> mind a PM?
<thoughtpolice> go ahead
Melkor333 has joined #nixos-dev
<gchristensen> ok, here is how I think it'll work: https://gist.github.com/grahamc/23e9efd825e2d809b1c96c091470db8e (hopefully you know rust, or can muddle through its types)
<gchristensen> I'd love feedback :)
<tilpner> gchristensen: What kind of instructions would a verifier receive?
<gchristensen> BuildRequest is the instructions
<tilpner> I was assuming this would be a weekly "build this and complain to me if it's not reproducable" thing
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
<tilpner> Ahh, should have finished reading before asking questions
<gchristensen> :) no worries (btw I'm about to head out for several hours)
<tilpner> And I'm not sure I correctly estimated the amount of build time this would mean
asymmetric has quit [Ping timeout: 245 seconds]
<gchristensen> part of the idea of randomization is you could build 1 or 1000 or more and potentially cover different ground from others
<tilpner> I thought we were talking about the ISO for now, but release-combined is a lot more. I don't know if I would like to verify more than the ISO for now, though more verification is of course preferable
<gchristensen> right, so for now the build instruction would be: Subset:NixOSReleaseCombined(["iso_minimal"])
Cale has quit [Ping timeout: 250 seconds]
<gchristensen> ok, time to head out. back in a while :)
<gchristensen> but you're right --it'd just be iso_minimal for now.
<tilpner> I don't want to impact normal usage too much, which I imagine would happen if my machines started building KDE every few hours
<tilpner> But I haven't tried that, maybe it would be okay with lots of nice/ionice
<ekleog> I've just come across https://github.com/NixOS/nixpkgs/pull/54619
<{^_^}> #54619 (by Mic92, 2 weeks ago, merged): treewide: remove wkennington as maintainer
<ekleog> I wonder: should we try to make some way of making packages without maintainers harder to use?
<tilpner> Huh, what do you mean?
<ekleog> It would make sense I think, as they'll likely become outdated relatively soon, no one will notice if they can be Just Used, and will potentially become sources of vulnerabilities
<ekleog> Something like the allowLicense stuff
<ekleog> allowUnmaintained
Cale has joined #nixos-dev
<tilpner> Which implies maintainers do... whatever maintainers do
<ekleog> like allowUnfreePackages* actually
<ekleog> Well, someone being listed as a maintainer at least means someone theoretically cares about it and should at least be subscribed to a RSS feed or similar
<ekleog> nothing is enforced but there's a non-null possibility someone is
<tilpner> Is that written down somewhere? Expectations might range from "has to sign off on PRs" to "has to keep up-to-date with upstreams issue tracker and possible security issues"
<ekleog> (and it'd be even better if maintainers get regularly pinged as is currently being envisioned with the unpriv maintainer RFC: people who don't care would no longer be written as maintainers and that would make the list more or less meaningful)
<ekleog> Not that I know of, unfortunately
<ekleog> At some point it meant “does receive mails when hydra builds fails”, but nowadays it's pure metadata
<ekleog> TBH until we start discussing splitting nixpkgs into core/community(/etc) I'm not sure it'd be meaningful to set expectations: we can't expect much from most one-off contributors
<tilpner> I'm asking because I didn't put myself down as a maintainer on a currently-open PR, exactly because I don't think I'll fulfill some interpretation of what those responsibilities might be
<ekleog> Right now my understanding of it is “cares about this package”
<tilpner> I might check for new versions every two months or so (or whenever I need them), and review PRs, but that's about it
<ekleog> It does sound like you could set yourself as maintainer as per our current unwritten rules, I think; it's already much more than some maintainers do
JosW has quit [Ping timeout: 252 seconds]
JosW has joined #nixos-dev
JosW has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<infinisil> gchristensen: I wouldn't mind IPFS
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev