<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]>
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...
<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 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