<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?
<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
<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
<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…
<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
<{^_^}>
#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
<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
<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
<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
<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)
<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 ?
<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
<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.