worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
<worldofpeace> yeah, a footnote would be a good idea
worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
worldofpeace_ has quit [Quit: worldofpeace_]
<worldofpeace> lol, the discourse post was the draft before the changes in nixos-homepage. just synced them hope no one noticed
* cole-h definitely noticed but didn't want to ping you again
<jtojnar> yeah, it would need --no-merges to filter them out
<worldofpeace> eventually the nixos releases section of discourse will be connected to the news.html on the website
<MichaelRaskin> Will this happen faster than we switch to a discussion medium with first-class support for threaded display and no mangling of emails?
<worldofpeace> Jan Tojnar: do you think excluding merges is important?
<drakonis> MichaelRaskin: oh oh i'll take no mangling
<MichaelRaskin> worldofpeace: depends on what you want to encourage?
<MichaelRaskin> If you say that merges are the actual bottleneck, then excluding them might be counterproductive even
<worldofpeace> idk, every merge commit is an effort
<jtojnar> they are different kinds of contributions so lumping them together might not necessarily make sense
<jtojnar> IIRC, the older discourse posts showed bot --merges and --no-merges separately
<worldofpeace> they did?
<worldofpeace> ahh, looking at samueldr thing
<jtojnar> yeah, that is what I meant
<samueldr> I didn't mean to make it a rule or anything :) it was mostly for fun
<worldofpeace> yeah, that's true
<worldofpeace> we could really get a website like rust has
<samueldr> but I do agree that merges/no-merges are an important metric
<jtojnar> though, of course, other types of merges would not be included so perhaps you also need comitters that differ from authors
<jtojnar> and at that point it is too much trouble
<worldofpeace> it's going into my notes anyways :D
bhipple_ has joined #nixos-dev
<bhipple_> Ericson2314: matthewbauer: are you guys around? Wondering how the Numpy issues are going.
<bhipple_> I see some PRs fixing some issues, currently building and testing the numpy site.cfg one
<matthewbauer> bhipple_: Yeah the two main issues are fixed in
<{^_^}> #85636 (by matthewbauer, 3 hours ago, open): BLAS/LAPACK fix fallout from #83888
<matthewbauer> It may be better to test that one, especially because it has
<bhipple_> Takes so long for my laptop to upload MKL's tar.gz file to my remote AWS builders. Should setup cachix at some point for it :/
<bhipple_> Ok, so you want to fix it forward rather than revert? Sounds good to me, assuming there aren't too many remaining issues?
<matthewbauer> bhipple_: yeah the question is how many other things there are, but the many regression should be fixed. It was probably merged too soon, although in the end ,merging is a great way to force people to review it :)
<bhipple_> Yeah that's true, probably should have been sent to staging as well given the number of rebuilds
<bhipple_> although it's nice that it's now going through; I think this will be a huge step forward for much of the ML community in Nix
<bhipple_> matthewbauer: Can you touchup the alternatives docs in the python section?
<worldofpeace> also did the call for 20.09 manager:
<cole-h> "I hope to hear from all of you." All nixpkgs contributors RM for 20.09!
<worldofpeace> haha
<worldofpeace> that would be crazy
<bhipple_> matthewbauer: looks like we still have issues w/ numpy and mkl
tilpner has quit [Ping timeout: 256 seconds]
<matthewbauer> bhipple_: is that with the latest on ? I thought I had it working with python2
<{^_^}> #85636 (by matthewbauer, 4 hours ago, open): BLAS/LAPACK fix fallout from #83888
tilpner has joined #nixos-dev
bhipple_ has quit [Ping timeout: 256 seconds]
bhipple has quit [Ping timeout: 256 seconds]
bhipple has joined #nixos-dev
bhipple_ has joined #nixos-dev
bhipple has quit [Ping timeout: 265 seconds]
bhipple_ has quit [Ping timeout: 256 seconds]
bhipple has joined #nixos-dev
bhipple_ has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
bhipple_ has quit [Remote host closed the connection]
<drakonis> the name is oddly accurate
<cole-h> jtojnar++ Nice find
<{^_^}> jtojnar's karma got increased to 42
<{^_^}> #82377 (by danderson, 5 weeks ago, merged): libsass: 3.6.1 -> 3.6.3
<cole-h> Yep
<jtojnar> > Checking themes can be done while its in staging-next so we have a stdenv.
<{^_^}> error: syntax error, unexpected IN, expecting ')', at (string):304:39
<jtojnar> of course we forgot about it
<cole-h> :D
abathur has quit [Ping timeout: 256 seconds]
<matthewbauer> bhipple_: yeah I think i missed it originally with mkl - it looks like numpy really wants to have something called
drakonis has quit [Quit: WeeChat 2.8]
Jackneill has quit [Ping timeout: 264 seconds]
abathur has joined #nixos-dev
Jackneill has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
cole-h has quit [Quit: Goodbye]
FRidh has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
ris has quit [Ping timeout: 258 seconds]
__monty__ has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 260 seconds]
justanotheruser has quit [Ping timeout: 265 seconds]
Jackneill has quit [Read error: Connection reset by peer]
<gchristensen> matthewbauer: when you're able, do you have access to the nixtravis user?
Jackneill has joined #nixos-dev
<gchristensen> I've been looking in to what it'd look like to enable debugging symbols by default in an overlay. anyone played with this before?
<tilpner> I'm not going to build it to find out if it works, and it probably doesn't
<tilpner> But... does self: super: { stdenv = super.stdenvAdapaters.keepDebugInfo super.stdenv; } do something?
<LnL> gchristensen: what for? certain things already have separate debuginfo
<gchristensen> yeah, so I've been building that for about an hour now, tilpner :) hoping it works
<gchristensen> LnL: I'm annoyed that I don't have symbols for everything available :(
<srk> dwarffs isn't usable?
<LnL> that only works for things with separate debuginfo enabled I think
<srk> I see
<LnL> would be nice to roll that out more tho, I bet many things only need separateDebugInfo = true;
avn has quit [Ping timeout: 256 seconds]
<gchristensen> the trouble afaik is debug symbols are like a 10x increase in data
<Profpatsch> Oh boy, Build Systems a la Carte, Game of the Year edition!
<Profpatsch> Go read that paper, possibly before niksnut’s PhD thesis.
abathur has joined #nixos-dev
<michaelpj> glad to see they've added a bit more discussion of Nix this time around!
<srk> is there a changelog? :)
<gchristensen> hrm. glibc doesn't build when built with: super.stdenvAdapters.keepDebugInfo super.stdenv; ... malloc.c:4075:53: error: 'nb' may be used uninitialized in this function [-Werror=maybe-uninitialized]
<srk> guess I'll read it again, it is pretty awesome anyway
abathur has quit [Ping timeout: 256 seconds]
<pie_[bnc]> does anyone want to set up some kind of reading session for the paper or something?
<pie_[bnc]> if not, i might try to do it myself
<pie_[bnc]> id need some help infrastructure-wise thoguh
<gchristensen> andi-: I can't find that issue you opened about autoluks being troulbesome
<gchristensen> do you know it?
<andi-> gchristensen: you closed it :P
<gchristensen> I can't find it anyway :P
<{^_^}> nixops#1156 (by andir, 46 weeks ago, closed): auto-luks: require new `mountPoint` option
<andi-> it might just have been that PR
avn has joined #nixos-dev
avn has quit [Ping timeout: 265 seconds]
<gchristensen> cursed: `dontStrip` could have been `don'tStrip`
avn has joined #nixos-dev
<LnL> are you sure bash would like that? :p
<gchristensen> uei:)
<gchristensen> :)
<gchristensen> so, something weird is happening. with tilpner's overlay suggestion, glibc doesn't build due to malloc.c:4075:53: error: 'nb' may be used uninitialized in this function [-Werror=maybe-uninitialized] ... if I change glibc's expression to set dontStrip = false, it continues to fail -- so I'm supposing that something about debug info in one of its inputs is causing this?
<gchristensen> or maybe it is the cflags change 3...
<tilpner> I did warn that I didn't have any confidence in it :c
<gchristensen> sure :) I mean, like I said, it was the same overlay I had come up with too :D
<Profpatsch> pie_[bnc]: sure, later?
<Profpatsch> Can do it on mumble
<pie_[bnc]> Profpatsch: i figured maybe schedule something on the weekend for reading it and the weekend after that for discussing it, idk
<pie_[bnc]> Profpatsch: people seem to like zoom?
<pie_[bnc]> idk how unnecessary video is
<pie_[bnc]> its not /necessary/ but having some nonverbal communication around is probably helpful
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
<srk> I think jitsi meet is now prefered to zoom
abathur has joined #nixos-dev
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 136
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 137
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 138
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 139
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 140
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 141
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 142
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 143
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 144
<disasm> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 145
<disasm> worldofpeace++
<{^_^}> disasm: You've been giving a bit too much karma lately!
<disasm> worldofpeace++
<{^_^}> disasm: You've been giving a bit too much karma lately!
<disasm> worldofpeace++
<{^_^}> disasm: You've been giving a bit too much karma lately!
<disasm> worldofpeace++
<{^_^}> disasm: You've been giving a bit too much karma lately!
<disasm> worldofpeace++
<{^_^}> disasm: You've been giving a bit too much karma lately!
<disasm> sorry for the spam, but worldofpeace deserves it!
<disasm> Thanks all for coming together for this release!
<etu> worldofpeace++ worldofpeace++ :)
<{^_^}> worldofpeace's karma got increased to 146
<domenkozar[m]> thank you worldofpeace & disasm
<domenkozar[m]> & samueldr !
<Valodim> finally, on the 51st of march \o/
<Valodim> thank you for your work!
<Valodim> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 147
sphalerite has quit [Quit: WeeChat 2.7.1]
<{^_^}> firing: BuildsStuckOverTwoDays:
<pie_[bnc]> " By default zfs pools will now be trimmed on a weekly basis. " what was the previous value?
<gchristensen> probably no trimming
<pie_[bnc]> *nod*
<Profpatsch> worldofpeace++ disasm++
<{^_^}> disasm's karma got increased to 36, worldofpeace's karma got increased to 148
cole-h has joined #nixos-dev
<{^_^}> hydra#739 (by grahamc, 1 minute ago, open): Hydra Event Bus
<LnL> guess I should write a summary?
<gchristensen> maybe just a bit of information about the data you're looking to see / format / etc.? just wanted to put a place to collect design
<LnL> yeah, good idea :)
<LnL> btw this is one of the things I already prepared for this, if somebody wants to review nixpkgs meta stuff
<gchristensen> nice
peelz has joined #nixos-dev
<gchristensen> I would look but github is giving me 500's
<LnL> yeah same, loads sometimes
risson has joined #nixos-dev
<peelz> Is wrapQtAppsHook necessary for building a library that builds against Qt?
Raito_Bezarius has joined #nixos-dev
<gchristensen> ,tell matthewbauer to ping me when he's available
<{^_^}> gchristensen: I'll pass that on to matthewbauer
<gchristensen> LnL: looks pretty nice
<LnL> it's also pretty fast, no drvs are evaluated and it's just a single pass
<gchristensen> LnL: since github is busted:
<peelz> gchristensen: if I add cc's to an existing github comment, will the recipients get the notification?
<gchristensen> not sure
<peelz> let's try it out... as soon as github stops blowing up!
<gchristensen> especially not sure since gh is busted :)
<peelz> yeah haha
<LnL> gchristensen: yeah, I noticed there's no difference between input and output fields in the meta checker which is a bit weird
<LnL> meta.broken should be bool -> meta.broken: attribute error :p
<gchristensen> hah
<LnL> but the reverse is also true here, unfree is accepted but not used at all
<gchristensen> right :/
<infinisil> gchristensen: What PR is that?
<cole-h> #85545
<infinisil> {^_^}: *cough*
<cole-h> GH hiccupping
<cole-h> Or dying
<infinisil> Ah, that makes sense
<LnL> I could add isUnfree = attrs.unfree || hasUnfreeLicense attrs, that solves the inconsistency but not sure it's useful
<peelz> gchristensen: let me know if you get a ping on #85690
<peelz> I somehow managed to slip that edit in
justanotheruser has joined #nixos-dev
<gchristensen> nope :)
<peelz> hmm either it doesn't work or GH is busted :P
<peelz> or both
<gchristensen> hehe
<infinisil> > unicorn = "🦄"
<{^_^}> unicorn defined
<srk> haha, was looking for it :D
<srk> infinisil++
<{^_^}> infinisil's karma got increased to 260
<infinisil> Hehe
<srk> irssi completion I've installed only has unamused which is kind-of appropriate as well 😒
<infinisil> I can't even see the unicorn emoji with the font I have lol, and to type it I just copied it from a website
<srk> same, it is quite funny that some work in one urxvt with less fonts installed but not in the other one, that handles some other..
<srk> I was looking for a fallback which could convert to text as a fallback but it's not that easy
* infinisil goes to #nixos-chat
<worldofpeace> Awww, disasm. I'm soo touched. Thanks 💖
sphalerite has joined #nixos-dev
<peelz> gchristensen: lol the PR triggered a purple tag :P
<gchristensen> RIP github
<gchristensen> ofborg should stop itself while the status page is unhappy
<peelz> /shrug
<gchristensen> honestly the label should be renamed from ofborg-internal-error to github-broke
<peelz> haha
<gchristensen> not kidding
<peelz> it's more often a github problem than an ofborg problem?
<gchristensen> pretty much always
<peelz> btw if github is stable enough, you should have a notification
* cole-h looks at GitHub dropping the one parameter that actually matters in status queries
<andi-> eventual availability
<gchristensen> lol
<srk> I'm tempted to open a forum discussion about possible alternatives
kalbasit has quit [Ping timeout: 256 seconds]
<srk> bad idea?
<andi-> The last thread has been locked because people got personal.
<gchristensen> that is definitely going to produce a fruitful and useful discussion
<srk> andi-: yes, that's why I'm asking, seen only last few posts of that
<srk> gchristensen: well if not phrased "Move out of GitHub" but consider other alternatives it might be good
kalbasit has joined #nixos-dev
<gchristensen> I think the only way to do it would be to start with research in to requirements and present a list of trade-offs for some options
<gchristensen> I think it'd probably degrade in to not much useful discussion quickly otherwise, and may still, but at least it started with research in to requirements and trade-offs :P
<srk> right, I like where Vervis is going with federated approach on top of ActivityPub but it's too early. there are bunch of competing projects in this space currently and other projects having the same discussions
<tilpner> We don't have to move off of GH right away
<srk> yes, this
<tilpner> An alternative solutions could be kept in parallel, so that integrations can be ported gradually
<tilpner> And this doesn't even require consensus or a decision of stakeholders
<gchristensen> yikes
<tilpner> Of course, there's the risk of lots of wasted effort
<srk> tilpner: well I'm trying not to circumvent the established stuff which is why I'm asking here before triggering another flame war :)
<gchristensen> one thing to weigh is the benefits of being on GitHub and the cmomunity / ecosystem / people that brings, despite its outages
<tilpner> I'm only saying an unofficial test-run on a different platform could help argue that platform
<Valodim> my biggest concern would be the churn rate for new contributors
<tilpner> *for that platform
<srk> gchristensen: yes, I'm aware of that - people often mention this but also the network effect
<gchristensen> exactly
<srk> it is awesome that it's easy to contribute *iff* you're already a github user but it's still a SPOF
feepo has quit [Ping timeout: 272 seconds]
<srk> which is weird considering the distributed nature of git
<gchristensen> coordination is the hard part :)
vdemeester has quit [Ping timeout: 272 seconds]
<srk> yup, hence my rants about kernel model (which is far from ideal I would say)
feepo has joined #nixos-dev
jared-w has quit [Ping timeout: 272 seconds]
noonien has quit [Ping timeout: 256 seconds]
manveru has quit [Ping timeout: 252 seconds]
elvishjerricco has quit [Ping timeout: 265 seconds]
aristid has quit [Ping timeout: 256 seconds]
vdemeester has joined #nixos-dev
tazjin has quit [Ping timeout: 272 seconds]
FRidh has quit [Ping timeout: 240 seconds]
FRidh2 has joined #nixos-dev
* srk off to play some games, thanks for the input!
<tilpner> I feel the need to clarify that I wasn't suggesting to just switch unofficially, that's not realistic. Just that a more complete list of required changes can be gathered by actually simulating a move, instead of just planning it
claudiii has quit [Ping timeout: 240 seconds]
jared-w has joined #nixos-dev
noonien has joined #nixos-dev
manveru has joined #nixos-dev
feepo has quit [Max SendQ exceeded]
aristid has joined #nixos-dev
elvishjerricco has joined #nixos-dev
feepo has joined #nixos-dev
tazjin has joined #nixos-dev
chrisaw has quit [Ping timeout: 272 seconds]
claudiii has joined #nixos-dev
jared-w has quit [Max SendQ exceeded]
chrisaw has joined #nixos-dev
jared-w has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
<MichaelRaskin> I think it is no longer easy to start contributing, even if one has a GH account. Check out a kind of huge repo, then spend some time finding out whom to ping for package addition on this topic…
Bunogi has quit [Quit: The Lounge -]
Bunogi has joined #nixos-dev
Bunogi has quit [Client Quit]
Bunogi has joined #nixos-dev
ris has joined #nixos-dev
<abathur> Maybe a better way to frame it, in terms of the discussion not getting out of hand, is as a component of a broader continuity plan?
<abathur> so that it's more about understanding what's essential to keeping the project(s) moving, keeping updated lists of software/services/procedures to replace the loss of any of those essential components, evaluating the procedure/cost of switching
<raboof> MichaelRaskin: I'm a new user/contributor since about half a year and found the experience very nice actually
<raboof> I didn't know you had to ping someone for package addition though, I just create PR's :)
<Valodim> is there a way to find which gcroot pins some package?
<Valodim> I notice that nix-collect-garbage doesn't want to gc a steam installation, but I can't figure out what pins it
<Valodim> oh, `nix-collect-garbage -d` did delete it. weird. I never had steam installed in the system, only in my home-manager profile
<Valodim> I would have expected `nix-collect-garbage -d` to only make a difference in terms of nixos-rebuild generations?
<MichaelRaskin> raboof: it's a coin toss if it gets handled quickly, some get lucky
<raboof> that's true, finding ways to deal with the volume of PR's better would definitely be welcome, but that's expected
<MichaelRaskin> I was indeed talking on the scale of «is lack of need of registration even a noticeable part of the effort»
<gchristensen> imo yes but
<MichaelRaskin> I did like the Nix manual 10 years ago, and it did not get worse, and there are small additions to do, which of course makes it easier to start than in some places
<infinisil> What if derivations also tracked what input derivation paths it read from
<gchristensen> hm?
<infinisil> E.g. you could ask "What paths from derivation A did derivation B access during the build?"
<infinisil> This would allow you to eliminate a bunch of rebuilds
<Valodim> "tracked" as in straced?
<infinisil> Valodim: Yeah
<Valodim> I wonder what the performance hit of that would be
<MichaelRaskin> inotify on a hundred directories?
<MichaelRaskin> Should not be that bad
<Valodim> inotify tells you about reads?
<infinisil> So, I'm thinking: If we know that derivation B only accessed certain paths of derivation A-v1, if A gets a small update to A-v2 which doesn't change those paths, we'd already know that B doesn't get changed
<MichaelRaskin> Yes
<gchristensen> infinisil: what if derivation B only opens A/bar when checksum(A/foo) == 12?
<MichaelRaskin> infinisil: isn't it dependent on CA?
<infinisil> gchristensen: I don't see a problem with that
<MichaelRaskin> gchristensen: if A/foo changes, then B needs a rebuild
<gchristensen> right
<gchristensen> what if a major (run-time) bug is fixed in A/bar, but only A/foo is accessed during build time?
<infinisil> Then the runtime bug certainly couldn't have been triggered
<MichaelRaskin> I mean, all this _clearly_ requires relocation
<infinisil> Since it wasn't accessed
<MichaelRaskin> CA or whatever we call it
<gchristensen> infinisil: but when I rebuild it, do I get the bugfixed version or no?
<MichaelRaskin> After relocation A/bar will be referenced
<MichaelRaskin> Yes you do
<infinisil> Ah, so currently I'm not even thinking of Nix actually preventing rebuilds
<MichaelRaskin> But all this is an incremental strengthening of CA
<infinisil> I'm just thinking for PR reviews where you could skip rebuilding certain paths on your own because you know they won't change the result
<gchristensen> ah
<MichaelRaskin> Oh hm
<infinisil> But I guess making that information be used by Nix would be the next step
<infinisil> Kind of the more extreme version of rfcs#17 rfcs#62
<{^_^}> (by wmertens, 2 years ago, open): [RFC 0017] Intensional Store
<{^_^}> (by regnat, 18 weeks ago, open): [RFC 0062] Content-addressed paths
<MichaelRaskin> infinisil: as I said, just a strengthening of rfcs#62
<{^_^}> (by regnat, 18 weeks ago, open): [RFC 0062] Content-addressed paths
<MichaelRaskin> You do not need global intensional store
<infinisil> Ah yes
<MichaelRaskin> (which might end up implausible anyway)
<gchristensen> I wish I could express in a derivation the intent to access a specific file
<infinisil> gchristensen: Oh yeah same
<{^_^}> #84129 (by Infinisil, 2 weeks ago, merged): Support removing python from zfs/grub closure
<gchristensen> like "${pkg}/foo" is fine, but "${pkg#"/bin/myprogram"}" and have that validated by Nix before building
<infinisil> Yeah, in above PR, I noticed that zfs partially dependend on python just because it depends on a single (non-python) binary from nfs-utils, which itself depends on python for other binaries
<infinisil> I wonder how this could be solved in a universal way
<LnL> well, what about propagated inputs?
<infinisil> LnL: What about them?
<LnL> should those follow or not?
janneke has quit [Quit: janneke quits Mes'sing]
<infinisil> Aren't those taken care of on the evaluation layer already?
<infinisil> Like through the derivation builtin or mkDerivation
<gchristensen> the best way to solve this universaly is probably the CA store, and liberal application of multiple-outputs
janneke has joined #nixos-dev
<infinisil> gchristensen: How about the extreme: Every file of the output is stored under its own /nix/store path, with a CA store
<gchristensen> sounds pretty cool
<infinisil> And let's add a builtins.derivationPath <derivation> "/path/to/file" to refer to them
<infinisil> Which you'd probably use instead of $out to have self-referential things
<infinisil> (and also for the usecase of only needing single files/dirs)
<infinisil> Though I guess you can still have $out which points to a directory of symlinks
<infinisil> Then we can get rid of the optimized store concept too, as all stores would be optimized
<infinisil> And we wouldn't have to worry about splitting outputs manually anymore
<infinisil> Sounds pretty good in my books!
<{^_^}> firing: BuildsStuckOverTwoDays:
<MichaelRaskin> infinisil: wait, how exactly you are going to make the upstream garbage refer to the weird paths now?
<infinisil> MichaelRaskin: Not sure what you mean by that
<MichaelRaskin> You know, all these files are put at their places for a reason
<MichaelRaskin> So the code needs to find them
<MichaelRaskin> I guess if the code is clean enough, you could try to automate patching it
<infinisil> Oh, so like a script that looks at $SCRIPT_PATH to find other files?
<infinisil> Hm that would be a problem indeed..
<MichaelRaskin> What about icons that have to be in a pretty interesting hierarchical directory structure?
<infinisil> MichaelRaskin: For those you'd just use `builtins.derivationPath <derivation> "/path/to/directory"`, where all the icon files would be in
<MichaelRaskin> Eh?
<infinisil> Think like how the current optimized-store works
<infinisil> Wait no
<MichaelRaskin> Like, that's a completely different situation
<MichaelRaskin> Do you say we need to explicitly say what must stay together?
<infinisil> I'm thinking $out is a directory like { bin -> /nix/store/...-bin; ... } where the -bin path contains symlinks to all binaries
<MichaelRaskin> Are you going to allow store with broken runtime references?
<infinisil> No clue, this is a fresh idea!
<infinisil> Would obviously be simpler if no exceptions are needed, but I guess that's not entirely realistic
<infinisil> Hm yeah this might not work after all
<worldofpeace> 20.09: has a QA team
<worldofpeace> wishlist
<gchristensen> woo!oh
<MichaelRaskin> Can this QA team please have the final say on all tests added to Nixpkgs?
FRidh2 has quit [Quit: Konversation terminated!]
<worldofpeace> MichaelRaskin: that's a good idea. I saw someone comment on 20.03 with "manual desktop item in plasma iso opened in kate default", and I was like, hmm, someone should have looked over that artifact.
<worldofpeace> but obviously it's much more
<MichaelRaskin> There are many possible tests that require some infrastructure but run faster end-to-end than a NixOS test VM boots, so it would be nice having a team actually interested having tests draw the lines about the amount of code dublication etc.
phreedom has quit [Ping timeout: 240 seconds]
<worldofpeace> "end to end" MichaelRaskin ?
<MichaelRaskin> Well, from starting nix-store -r to nix-store terminating
<clever> MichaelRaskin: that can be tested outside a vm using --store local?root=/tmp
<MichaelRaskin> The test is not about testing Nix though
<MichaelRaskin> The test is some application stuff
<clever> ah
phreedom has joined #nixos-dev
drakonis has joined #nixos-dev
ixxie has joined #nixos-dev
ehmry has quit [Quit: - Chat comfortably. Anywhere.]
ehmry has joined #nixos-dev
<pie_[bnc]> finish, skipping any commands where no inputs have changed." have you already heard of this?
<pie_[bnc]> edef: nh2: I would like to bring your attention to page 51 of the a la carte paper, listing related work, "The one build system we are aware of that cannot be modelled in our framework is F ABRICATE by Hoyt et al. (2009) To achieve minimality, each separate command is traced at the OS level, allowing F ABRICATE to record a trace entry stating that gcc -c util.c reads from util.c. In future runs, F ABRICATE runs the script from start to
<edef> i have not!
<edef> i wonder how it differs from tup
<pie_[bnc]> i dont know, but tup i think is mentioned in the paper
__monty__ has quit [Quit: leaving]
<pie_[bnc]> Ericson2314: you were working on some low level derivation stuff right? im not sure if this is relevant to yout interests but i figured it cant hurt to mention it
andi- has quit [Ping timeout: 252 seconds]
<colemickens> how is version info passed in for official releases?
<colemickens> I'm trying to figure out how to properly name (with clean/good version) the Azure VHDs.
andi- has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
<cole-h> Do you mean `20.03` or `20.03 "Markhor"`? Or something else I'm not thinking of?
<gchristensen> colemickens: the module attribute would be like config.system.nixos.version
<gchristensen> nix-repl> config.system.nixos.version
<gchristensen> "20.03beta1355.0f920b05cbc"
<colemickens> where does teh git rev come from in that version string?
<colemickens> is that part of the channel process?
<gchristensen> yeah
<cole-h> gchristensen: You do know 20.03 is officially released now, right? No longer in beta ;^)
justanotheruser has quit [Ping timeout: 240 seconds]
<gchristensen> haven't had a moment to update my system =)
andi- has quit [Excess Flood]
<gchristensen> and recompiling emacs takes a hot minute, so I tend to push it off sometimes :P
<cole-h> A truer statement has ne'er been spoken
andi- has joined #nixos-dev
<qyliss> Should we just get pgtk emacs into Nixpkgs?
<qyliss> Enough people use it at this point
<colemickens> in my repl, I get "20.09pre-git". so am I supposed to be setting this module option myself?
<gchristensen> qyliss: I dunno :/ I'd say NUR definitely, nixpkgs? not sure.
<qyliss> We have plenty of other widely-used software variants
<colemickens> I guess I'm looking for the script that must exist somewhere that does "is git clean, get git revision, set it in nixos version module, then build the official ISO" or whatever. Or is it all done as a hydra job?
<gchristensen> qyliss: I wonder what the chances of upstream adoption are
<cole-h> colemickens: It's in lib/trivial.nix somewhere
<cole-h> ^ and that lol
<worldofpeace> this is hot on the press for people who have good nitpicking skills #85727
<{^_^}> (by davidak, 5 minutes ago, open): Improve backport instructions
<cole-h> 👀
<MichaelRaskin> I am good at nitpicking and bad at understanding why we have releases in the first place. Sooo, nitpicking in which direction is needeD?
<worldofpeace> english
<worldofpeace> and git
<MichaelRaskin> Hmm.
<MichaelRaskin> (my official position is git loses enough crucial data that the history will be meh anyway)
justanotheruser has joined #nixos-dev
<gchristensen> MichaelRaskin is one of the best nit-pickers I've ever met. thorough, but respectful.
<MichaelRaskin> Hmmm. Steps 2 and 3 have no reason to be separate, but maybe it is easier to explain like that
<worldofpeace> gchristensen: Yes, I recall having a certain discusion on the "needs help" pr template comment. As described, thorough and respectful.
<cole-h> Can we get a NixOS/nitpick team? 👀
<gchristensen> exhaustive (, and sometimes a smidge exhausting[, and willing to stop])
<gchristensen> cole-h: not sure the skill and technique is easily transferrable, or good to encourage :)
<MichaelRaskin> I can even say it _might_ be related to reasons of my dropping NixOS mainline
<MichaelRaskin> (It would be fun to have an official NixOS team with a lot of churn because of people dropping NixOS I guess? Or consisting of people not using NixOS)
<{^_^}> firing: BuildsStuckOverTwoDays:
<MichaelRaskin> worldofpeace: OK, more serious question than 2/3 separation: is it supposed that backporting more than one commit at once is so rare we should not mention it at all?
<cole-h> btw gchristensen, mind removing the purple label of doom from #85688 ?
<{^_^}> (by 1000101, 7 hours ago, open): shopify-themekit: init at 1.0.3
<cole-h> (or anybody who is allowed to fiddle with labels, really)
<gchristensen> ^ can someone else do that? dinner
<qyliss> got it
<cole-h> qyliss++
<{^_^}> qyliss's karma got increased to 53
<cole-h> Thank you
<worldofpeace> MichaelRaskin: yeah, that's a valid issue
<MichaelRaskin> Wait, what you are proposing would literally mean git cherry-pick with multiple arguments?
<pie_[bnc]> MichaelRaskin: the post-nixos team
<MichaelRaskin> Hmm, OK, multi-cherry-pick is at least promised to work as expected
<MichaelRaskin> worldofpeace: an alternative is to cherry-pick the merge, of course…
<qyliss> only works for PRs with a merge commit
<qyliss> and PRs that are branched off before the release, probably?
<qyliss> Unless it just squashes it into a one-parent commit
<MichaelRaskin> I think merges are more frequent than rebase-pushes. no?
<MichaelRaskin> If there is a single commit to pick, there is no problem in the first place.
<qyliss> probably more frequent, but not 100%
<qyliss> just telling people to cherry-pick all commits will work for merges and rebase-applies
<MichaelRaskin> One might of course encouraging cherry-picking commit-by-commit to ensure that backporting a change with actually many commits is annoying (so people notice they deviate from instructions and discuss whether this should be backported)
<qyliss> not annoying at all in magit :P
<MichaelRaskin> Problem!
<worldofpeace> I usually just cherry-pick with the range in a pr, something^..otherthing
<Ericson2314> pie_[bnc]: Thanks for the heads up. I have read that paper, heh, but I think there are things about nix and sanboxing that it doesn't quite capture---e.g. if you focus lots on what things can do, you can miss the beautifulness that arises from making bad things impossible.
<pie_[bnc]> Ericson2314: meanwhile i got into correspondence with the main author, i coooould ask him to join us
<pie_[bnc]> though he might be anyway, im not sure
<Ericson2314> Andrey Mokov? Yeah he's a really nice guy
<pie_[bnc]> (oh no im organizing an actual thing???)
<pie_[bnc]> Ericson2314: so, will you be joining?
<Ericson2314> I'll go if he goes. I don't have much more interest in that paper since I last read it based on those things, but I wouldn't turn down on oppertunity to try to talk to him more about nix things hehe
<pie_[bnc]> hehe ok
<pie_[bnc]> did you read the old or the new paper? i dont know how much the new one adds
<Ericson2314> I give it a look over
<Profpatsch> Ericson2314: there’s an overview of what changed
<pie_[bnc]> its also listed in the introduction, but im not sure how helpful that actually is
<pie_[bnc]> i doubt the theoretical framework changed much, probably mostly practical stuff thats new
<pie_[bnc]> Ericson2314: in any case, i did "formally" invite him now
<pie_[bnc]> hyperfekt: Ericson2314, if you want to hang around till the events, weve got some participants preliminarily gathered in ##bsalc
<Ericson2314> OK I'll take a look in there
<hyperfekt> pie: ha i was just taking a look at the paper again to make sure it wasn't over my head before i say yes to coming ^^
<pie_[bnc]> hyperfekt: you can hang around even if it is :P
<pie_[bnc]> to be honest i uh, made the announcement without having a clue whats in there
<pie_[bnc]> because i trust profpatsch and its got SPJ as a co-author 'xD
<pie_[bnc]> on th eother hand nothing would happen if i told myself ill start after reading it, so..
<pie_[bnc]> so im kind of just trying to organize something than be a participant, because i think its worth getting some nix people to look at and discuss this together :)
<pie_[bnc]> ill probably have some idea by the time i finish the paper though
<cole-h> Huh, I hadn't heard of that paper (likely because I don't really follow academia). Seems like an interesting read.