<gchristensen>
we have our first 20.03-darwin channel, which was the last "oh I hope that is done by the release" for me
<cole-h>
🎉
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
tom39934 has joined #nixos-dev
Cale has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
__monty__ has joined #nixos-dev
sogatori has joined #nixos-dev
ixxie has joined #nixos-dev
tom39934 has quit [Quit: WeeChat 2.7.1]
tom43422 has joined #nixos-dev
tom43422 has quit [Client Quit]
tom43422 has joined #nixos-dev
<flokli>
edef: I think it should point to the latest... And software explicitly needing the old version would need to have updated what protobuf is passed in
cole-h has quit [Ping timeout: 260 seconds]
bhipple has joined #nixos-dev
bhipple has quit [Ping timeout: 256 seconds]
<rnhmjoj>
does anyone have a better idea than mine for #81013 ? if not i'm going ahead and merge the current solution since it's harmless and will fix a couple failures on hydra
<flokli>
any idea why it doesn't work with networkd?
<flokli>
ah, in fact it
<flokli>
's linked
<rnhmjoj>
i think it's in the commit message i mentioned
<rnhmjoj>
i don't know the details but network manager can't handle a virtual interface configured like that
<flokli>
yes
<flokli>
network manager doesn't have anything to do with that
<rnhmjoj>
sorry, i mean't networkd
<flokli>
but the explanation is in the commit message
<rnhmjoj>
*meant, ahaha
<rnhmjoj>
i haven't slept much
<flokli>
everyone should!
<Emantor>
I have this PR open since mid of january: https://github.com/NixOS/nixpkgs/pull/77500, my colleague tested it. I have just updated the formatting and moved autoreconfHook around. Would be nice to get this merged.
<Emantor>
Valodim: for lack of testing, if somebody needs a RFC2217 compliant serial program on other platforms, they can test and add the other platforms.
<Emantor>
But I suspect there are GNU/Linuxism inside the code base. We only ever ran this on Linux.
<Valodim>
Emantor: I think the typical approach I observed in nixpkgs was not to limit the platform unless concretely indicated (like a failed build process), and add the constraint when it turns out it is needed
teto has joined #nixos-dev
<Valodim>
(although I'm not really sure that's a formalized intended strategy?)
<Emantor>
clever, LnL, thanks for the insights :-)
sogatori has quit [Remote host closed the connection]
pie_ is now known as pie_[bnc]
erictapen has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
<pie_[bnc]>
does anyone actually have funding such that theyre working on nix/pkgs/os solely for the sake of nix/pkgs/os?
erictapen has quit [Ping timeout: 256 seconds]
drakonis has quit [Ping timeout: 265 seconds]
* srk
wishes he had
johnny101m has quit [Quit: -a- Connection Timed Out]
erictapen has joined #nixos-dev
johnny101m has joined #nixos-dev
<Ericson2314>
pie_[bnc]: people are typically more interested in funding capital than operational expenditures
<Ericson2314>
but the capital ones can still be very for-the-commons-y
justanotheruser has joined #nixos-dev
<qyliss>
pie_[bnc]: nixpkgs-update?
<pie_[bnc]>
funding capital?
<qyliss>
and mobile nixos, if that counts
<Ericson2314>
pie_[bnc]: *funding capital expenditures
<pie_[bnc]>
to expand a bit, i was mostly wondering if most of our management tarpit problem is that everybody is trying to do the basic work in their spare time
<pie_[bnc]>
not that i know anything about management or leadership
<pie_[bnc]>
Ericson2314: aha
drakonis has joined #nixos-dev
<Ericson2314>
pie_[bnc]: that doesn't help, but I think it shouldn't be an excuse (not to say you do either)
<Ericson2314>
the limited time of everyone involved means we should have more clear, not less clear, rule on delegation
drakonis1 has quit [Ping timeout: 240 seconds]
<pie_[bnc]>
i guess i bring up the meta-question again, of why we seem to be stuck (are we?) where we are x)
<edef>
we have a lot of stakeholders and no meaningful prioritisation or even overview of what they want
<edef>
and a good chunk of them are poorly represented
<pie_[bnc]>
well, edef *does* have management experience
<edef>
even basic things like code style are hardly documented
<edef>
pie_[bnc]: by necessity
<pie_[bnc]>
nixos is missing management despite necessity? :P
<edef>
i suppose so
drakonis_ has joined #nixos-dev
<edef>
right now a lot of technical debt just accumulates
<edef>
because we hardly even track it
<pie_[bnc]>
i want to say thats "fine", but somehow we dont seem to be making progress on it, and i dont mean decreasing the issue count, or issue rate, because im not sure thats a decent metric
<edef>
but i believe paying that down involves changing a lot of working but fragile stuff
<pie_[bnc]>
s/decent/useful
<pie_[bnc]>
like, we can operate in failure mode, we seem to be doing fine for the moment
<edef>
sure
<pie_[bnc]>
(i love to quote "complex systems operate in failure mode", but anyway)
<edef>
but what percentage of our time are we spending on stuff that's just fixing things that repeatedly break for architectural reasons
<pie_[bnc]>
yeah
<edef>
at some point 100% of your work becomes break-fix work
<pie_[bnc]>
i dont want to turn this into an everything sucks circlejerk but im not sure what to do
<pie_[bnc]>
and to be clear ,everything *doesnt* suck
<edef>
and everyone is 100% busy, so clearly we're all doing our best,
<pie_[bnc]>
right
drakonis has quit [Ping timeout: 246 seconds]
<pie_[bnc]>
hence the whole "why are we stuck and wtf can we do about it even"
<pie_[bnc]>
i guess 100%occupied really forces an answer of prioritization
<edef>
yes
* pie_[bnc]
should listen in on some of those release meetings
<pie_[bnc]>
despite all this we still manage to have releases somehow, so maybe its just me not seeing the trees from the forest :D
<edef>
imo the FFI unsafety in Nix itself right now really drives home that we're willing to take arbitrary risk for shiny feature we want right now
<pie_[bnc]>
which FFI unsafety?
<MichaelRaskin>
There is some Rust code in Nix
<pie_[bnc]>
ah. that.
<edef>
it's a big pile of UB, niksnut has already admitted he doesn't give a shit — i recall a quote along the lines of "we'll just [fix it / roll back the compiler] if it breaks"
<pie_[bnc]>
mh
<qyliss>
yikes
<edef>
idk if that stance has changed since but it definitely left a sour taste for me
<MichaelRaskin>
I mean, it is inside a C++ project.
<edef>
"here, in order to get shiny feature, i will decrease reliability and create future break-fix work"
<edef>
MichaelRaskin: UB in C++ is equally serious, just harder to avoid
<pie_[bnc]>
yeah I havent kept up with the details but that doesnt sound great, i really cant comment
<pie_[bnc]>
though thats kind of ironic in light of rust beign supposed to increase reliability
<edef>
MichaelRaskin: Rust's unsafe code guidelines are not particularly hard to follow
<MichaelRaskin>
edef: in the context of FFI with C++ that also uses BoehmGC?
<edef>
pie_[bnc]: the only memory-safety / defined behaviour promise Rust makes is that everything will be fine *if* the code inside your unsafe blocks is memory-safe
<edef>
MichaelRaskin: i don't see why Boehm would work any less well against the Rust bits
<edef>
it's just scanning stack/heap
* pie_[bnc]
isnt worried about *specific* issues in the context since there seem to be deep underlying issues
* pie_[bnc]
may be misguided
<MichaelRaskin>
Having things with complicated lifetimes on the other side of FFI
<edef>
we can ensure it uses the right allocator Rust-side as well
<edef>
either way, "stuff is bad, let's make it worse" isn't super high up my list of favoured attitudes
<pie_[bnc]>
if its sufficiently bad it might just fail the port, but idk about that
<edef>
right now we have *layout* UB that does not have anything to do with the things MichaelRaskin is describing
<MichaelRaskin>
OK, layout UB is bad everywhere
<edef>
it's not for any actual benefit, doing the casts is straightforward, it's just stupid
<edef>
but since it's niksnut's code that can be merged into master without addressing that
<pie_[bnc]>
stuff like merging into master without going through CI happens to be how i ended up thinking about this
<edef>
i'm not intending to deploy Nix releases after 2.3.3 to production because the code quality has suffered
<pie_[bnc]>
my question is not why we are merging to master without CI , but why its even possible for that to happen
<edef>
(2.3.3 does not contain any of the Rust UB)
<pie_[bnc]>
should be institutionally impossible
<edef>
(or any Rust, for that matter)
<edef>
pie_[bnc]: of which repository
<edef>
in what context
<pie_[bnc]>
edef: to be clear this is just stuff ive heard about and not personally looked into
<edef>
i'm honestly less worried about things like small commits pushed straight to master
<pie_[bnc]>
i only got more comfortale with git like two weeks ago
<pie_[bnc]>
edef: sure but why even bother and not just have an auto-merge-after-tests-pass-staging
<edef>
like, i'm fine with someone tweaking a maintainers field or whatever
<MichaelRaskin>
Ironically, _that's_ where it is most likely to have a problem caught _only_ by CI
<MichaelRaskin>
(but trivial to fix, so cost-benefit is a toss)
<MichaelRaskin>
pie_[bnc]: because it's infrastructure?
<pie_[bnc]>
MichaelRaskin: hm?
<MichaelRaskin>
Auto-merge
<pie_[bnc]>
* why even bother [merging to master, the staging becomes your new "virtual" master]
<MichaelRaskin>
This is a commitment to a constant effort making sure this doesn't break down and get the entire development stuck
<pie_[bnc]>
i mean yeah someone needs to set it up and its work, sure
<MichaelRaskin>
And _keep_ it up
<srk>
(what's UB?)
<MichaelRaskin>
srk: undefined behaviour
<pie_[bnc]>
which comes back to the "is this a lack of funding pure nix work" problem?
<srk>
MichaelRaskin: ty :)
<pie_[bnc]>
ongoing props to graham because idk where we'd be without ofborg :P
<MichaelRaskin>
On a noncritically higher breakage level, and a bit higher general annoyance level
drakonis has joined #nixos-dev
<MichaelRaskin>
(and it is reducing the second that makes ofborg valuable)
<edef>
it doesn't block my merges when i newly break stuff
<pie_[bnc]>
failing to understand what youte saying here; <MichaelRaskin> On a noncritically higher breakage level, and a bit higher general annoyance level
<pie_[bnc]>
oh
<pie_[bnc]>
i got it
<edef>
and last i remember, it tends to have a bunch of stuff show up as indeterminate when it actually is broken? i'm not sure actually
<edef>
i definitely don't feel aware of whether stuff is actually ok on darwin
<MichaelRaskin>
Notion of broken is… complicated
<pie_[bnc]>
actually, i managed to mentally lump together ofborg and hydra, not actually sure whats going on there
<edef>
and recently broke google-cloud-sdk
<edef>
only on Darwin, so i had no opportunity to test it
<edef>
plus it's fairly hard to debug for me, so realistically i'd have either abandoned the change, or merged it so someone who actually has a darwin system shows up to complain
<edef>
(the latter happened anyway)
<edef>
i've ended up enlisting a friend to set me up a Darwin system just so i can avoid this in the future, which i consider a failure case at some level
<pie_[bnc]>
a lot of these are all recurring _technical_ problems, which we still have for nontechnical reasons?
<pie_[bnc]>
well that was a bighandwave
<pie_[bnc]>
probably unjustified
<rnhmjoj>
what is the purpose of the 2G output limit on hydra?
<MichaelRaskin>
Log output or output path?
<rnhmjoj>
i guess output path. i'm just reading the discussion on GHC exceeding this limit on aarch64
<pie_[bnc]>
sanity check maybe?
<pie_[bnc]>
is there a repo of the hydra config?
<rnhmjoj>
why can't the limit increased or GHC made an exception? no having a compiler in the binary cache it's pretty bad
<samueldr>
now, why this number? my bet is on past-eelco thinking "no sane build will be larger than 2GiB, and if it is, it's probably a mistake"
<samueldr>
though I had that thought before knowing it was so "close" in the past, in 2016
<pie_[bnc]>
which is not unreasonable
<pie_[bnc]>
is there an override?
<samueldr>
globally yeah
<samueldr>
can it be made an exception? maybe, but I don't know if the code exists in hydra, like it does for the timeouts
<samueldr>
build timeouts IIRC can be overriden at the derivation level
<pie_[bnc]>
yeah i meant per-...attribute or something
<samueldr>
I figure it would be more tolerable as a change if we could select exceptions rather than apply this outright
<MichaelRaskin>
I think it is more that «if a build is over 2GiB, it is probably data and we should not waste Hydra storage on it»
<pie_[bnc]>
i didnt really read the code but it sounds like it doesnt exist otherwise graham would have just said yeah we'll override it or something :P ?
<samueldr>
MichaelRaskin: that also
<samueldr>
(but, isn't code data?)
<pie_[bnc]>
MichaelRaskin: that also crossed my mind *shrug*
<pie_[bnc]>
my knee-jerk is this is a reasonable thing and being able to apply indiviual exceptions sounds good?
<MichaelRaskin>
No, code is ELF binary, (usually) dynamically linked
<pie_[bnc]>
by the way
<samueldr>
sorry, this wasn't meant as a serious thing
<pie_[bnc]>
the graphical iso weighs in about 1.3 gigs right?
<samueldr>
yes
<samueldr>
which is quite weighty
<MichaelRaskin>
samueldr: I tried to quote «file» output without CPU-specific parts
<pie_[bnc]>
(did we even have a graphical iso a couple years ago?)
<rnhmjoj>
GHC is just a little over 2GB, increasing it a bit would fix the issue but it's not a great solution
<samueldr>
pie_[bnc]: pretty sure a graphical iso has been a thing since a while
<pie_[bnc]>
rnhmjoj: well i see a ghc issue was opened, maybe it *is* a build bug
<pie_[bnc]>
samueldr: im just saying because that might coincidentally be why the limit is not say, 1 gig or something :P *shrug*
<MichaelRaskin>
We had graphical ISO _ten_ years ago
<samueldr>
I think the graphical iso was just shy of a gig when I started using nixos in ~2017
<pie_[bnc]>
im now mildly curious about what the largest packages on hydra are
<MichaelRaskin>
.~
<MichaelRaskin>
Yes, way back ago it fit on a larger CD-RWs
<samueldr>
I am, too
<srk>
fonts!
<pie_[bnc]>
s/package/drv result
<pie_[bnc]>
samueldr: oh?
<pie_[bnc]>
man im still not clear with the drv package build result whatever terminology :P
<samueldr>
(who is?)
<pie_[bnc]>
yeah we *really* need to do something about that
<MichaelRaskin>
There are store paths
<MichaelRaskin>
Packages do not exist, they are a myth
<samueldr>
a social construct around store paths
<pie_[bnc]>
they exist as much as my left hand is my left hand
<MichaelRaskin>
A language-level construct for packages might happen at some point
<Profpatsch>
you think so?
<pie_[bnc]>
maximize confusion :D
<MichaelRaskin>
Apparently, derivation is not it.
<Profpatsch>
I have seen many people talk about it with some certainty, but I have yet to see any kind of design proposal.
<MichaelRaskin>
Profpatsch: I think Eelco Dolstra wondered if it would be a good idea
<MichaelRaskin>
Look at flakes, you got the order wrong
<Profpatsch>
We could start by getting rid of callPackage :)
<MichaelRaskin>
To replace it with what?
<srhb>
I propose "argify"
<srhb>
See, I was ready.
<Profpatsch>
MichaelRaskin: flakes has nothing to do with package descriptions last I looked.
<MichaelRaskin>
I mean, I will support anything that a) makes hello/default.nix plain data without defining any functions, b) keeps override capabilities we have now, c) does not break cross-builds and stuff
<MichaelRaskin>
Profpatsch: they do have to do with expectations about the order of spec and the first prototype
<Profpatsch>
Though I agree that the self/super fixpoint thing is something that has proven its practicality enough to get first-class language support with well-defined semantics
<Profpatsch>
And maybe this would finally get rid of infinite recursions, or at least give them understandable error messages
<MichaelRaskin>
Not sure you want to enshrine self/super exactly like now, making hello/default.nix plain data would probably need some realignment of what happens where
<pie_[bnc]>
i propose angrify
<Profpatsch>
I’m totally against “plain data” in the sense of removing functions.
<Profpatsch>
let should be non-recursive however, and the y-combinator forbidden
<MichaelRaskin>
I am against removing functoins from the language — and this will break cross with >90% chance
<Profpatsch>
I wonder where you get the 10% from :P
<MichaelRaskin>
You know Y is not the only fixpoint combinator, right?
<MichaelRaskin>
From first-class cross-builds as a language construct, obviously
<MichaelRaskin>
Note: <10%
<MichaelRaskin>
Not 10%
<MichaelRaskin>
But I am all for not making _every_ package define a function
<Profpatsch>
yeah, as I said, let’s get rid of callPackage
<pie_[bnc]>
a) im not sure "getting rid of infinite recursion" is feasible b) im not a pl researcher, but well behaved recursion is possible with some languages where it checks stuff like you reducing your inputs
<pie_[bnc]>
nixos in agda anyone?
<pie_[bnc]>
a and b are contradictory yes :D
cole-h has joined #nixos-dev
<MichaelRaskin>
I am pretty sure our current module system allows theoretically-non-elementary complexity with every module being well-behaved in isolation
<MichaelRaskin>
Profpatsch: callPackage is irrelevant
<MichaelRaskin>
Nix of 2010 did not have callPackage, it still had a function per package
<pie_[bnc]>
i forgot we have such valuable ancient knowledge <MichaelRaskin> Nix of 2010 did not have callPackage, it still had a function per package
<pie_[bnc]>
people have seen nixpkgs before we had what we do now :D
<gchristensen>
you should look at early nixpkgs
<gchristensen>
the .fix files were fascinating
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis2 has joined #nixos-dev
drakonis1 has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
I mean, at this I have looked as a curiousity.
<MichaelRaskin>
At Nixpkgs with no good overrides I have looked as sources for my laptop's OS installation.
<drakonis>
.fix files?
<drakonis>
this i gotta see
erictapen has quit [Ping timeout: 256 seconds]
<pie_[bnc]>
gchristensen: hm?
<rnhmjoj>
gchristensen: we were discussing GHC hitting the hydra ouput limit. do you know why the limit can't be raised or an exception be added for GHC?
<Profpatsch>
MichaelRaskin: I’m having a problem how you can pass dependencies without having functions, or at something that’s equivalent. Call it “templating”
<Profpatsch>
You can have more metadata, that is true.
<Profpatsch>
A system that says “you have `pkgs`, which is a giant attrset with all the packages in it”, is essentially passing pkgs like a function, but robs you of any actual capabilities
<gchristensen>
rnhmjoj: I don't know if there is a good answer, but increasing the limit without knowing why it grew so much so suddenly, and without any effort to fix it doesn't seem good for users
<MichaelRaskin>
Well, if an overwhelming supermajority of our dependency passing is done by selecting from pkgs by attribute path, we can as well just make it the default way (using lists of strings and not functions)
<samueldr>
gchristensen: it's the ol' ghc aarch64 issue
<gchristensen>
I know
<MichaelRaskin>
You could treat attribute paths as selectors, and allow functions for the minority case
<samueldr>
alright
<Profpatsch>
MichaelRaskin: That’s how bazel does it.
<Profpatsch>
And the semantics is all over the place tbh.
<gchristensen>
samueldr: I haven't seen any lookingin to it
<gchristensen>
in the upstream issue at all
<LnL>
generally getting over the output limit is caused by excessive warnings in the build
<gchristensen>
I think this error is about build output not log output?
<samueldr>
LnL: output size, not the log size
<rnhmjoj>
gchristensen: i agree, but having no GHC on a major platform is not good either
<LnL>
or at least that's the only times I've ran into it
<samueldr>
(but you would be right for log size)
<gchristensen>
neither is needing 3G of space to get ghc for your rpi
<LnL>
samueldr: oh, there's a limit on that?
<Profpatsch>
MichaelRaskin: Also, that’s how build systems go to die :) Nix doesn’t have the advantage of being in a language everyone wants to hack in, but at least it exposes a language everybody *can* hack in
<samueldr>
LnL: yes
<LnL>
how does ghc hit that tho, aren't there bigger things in nixpkgs?
<samueldr>
it looks like an aarch64 specific issue
<Profpatsch>
nixpkgs wouldn’t be at the point that it is today without that.
<gchristensen>
LnL: in one point release their output sizegrew by like 700M
<LnL>
sure, but we have iso builds...
<MichaelRaskin>
Profpatsch: note that I explicitly stress hello/default.nix and not generic default.nix
<Profpatsch>
MichaelRaskin: If you want to modify some of the built-in bazel semantics, good look, here’s 200k lines of Java, have fun
<gchristensen>
yeah, afaik their output size grew by as much as 1 ISO build :P
<MichaelRaskin>
Sure, a minority of packages would still need Nix functions as selectors
<samueldr>
LnL: yes, and sd image builds which we had to start compressing as they got over the 2.0GiB limit
<Profpatsch>
s/look/luck
<MichaelRaskin>
But it won't be actually worse than now.
<samueldr>
(the iso are squashfs'd, which helps with size, compared to the sd image)
<MichaelRaskin>
And if _most_ of packages avoid defining functions, we have a tractable amount of functions defined and can actually try to optimise evaluation
<Profpatsch>
MichaelRaskin: I’m experimenting with a nix-based project build system where the user writes dhall files and nix is just the implementation language of the library
<gchristensen>
but rnhmjoj I thought domenkozar[m] was saying ghc 8.8 worked?
<Profpatsch>
And I think tazjin does some stuff that uses nix as a monorepo build language.
<MichaelRaskin>
Profpatsch: that sounds as more friction for overrides than what I describe
<Profpatsch>
MichaelRaskin: do you have a mockup of how hello would look in your design?
<MichaelRaskin>
Let me generate it quickly, I guess…
<Profpatsch>
I’m guessing hello would essentially be a covariant json, with a `buildDependencies` field that gets the dependencies as strings
<MichaelRaskin>
Yes
<Profpatsch>
that makes sense.
<Profpatsch>
We also have good semantics of the different build fields for cross by now.
<gchristensen>
at any rate, rnhmjoj, I'm not opposed to increasing the limit, but I don't want to *just* increase the limit. I'd like to see a bit of leg-work along the lines of GHC knowing why it is so big
<Profpatsch>
MichaelRaskin: If you mocked up something, I’d be up to transforming some packages in live nixpkgs and seeing if we are missing somethingt.
<Profpatsch>
MichaelRaskin: The “implementation” of that would still be the usual, so the result would fit.
<Profpatsch>
MichaelRaskin: lol
<MichaelRaskin>
But src still counts
<Profpatsch>
But we can start to be more data-based.
<Profpatsch>
MichaelRaskin: hello is probably the wrong package to convert if we want to try it out first :)
<Profpatsch>
Because it’s the example.
<rnhmjoj>
gchristensen: i don't know much about this issue, i stumbled upon the issue in github, just now. the last comment from vcunat says the situation just got worse...
<MichaelRaskin>
It is the wrong package to _commit_ converted
<Profpatsch>
yeah
<gchristensen>
rnhmjoj: exactly, if ghc doesn't know why they're growing so much... that doesn't spell good news for anybody
<Profpatsch>
MichaelRaskin: How about mktorrent?
<Profpatsch>
It’s a package I maintain
<Profpatsch>
And pretty standard
<MichaelRaskin>
Look, I started editing hello
<LnL>
rnhmjoj: I think the static libs should be moved to a separate output, that would make it _much_ smaller
<Profpatsch>
MichaelRaskin: if you do hello, I will use that example to do mktorrent
<gchristensen>
Profpatsch: is there a trivial way to then seed that mktorrent result in a CLI, without a daemon, which just seedsas long as the process is running?
<Profpatsch>
> :p let y = f: (x: f (x x)) (x: f (x x)); in y (x: { a = 3; b = x.a + 3; })
<{^_^}>
{ a = 3; b = 6; }
<Profpatsch>
sure enough (I typed it from Wikipedia, even I don’t understand how that shit works)
<globin>
gchristensen: building on the release branch now, I'll check if I can backport the ghc bump for aarch64 maybe or find some other solution, pending on a number structured-attrs builds right now anyway
<gchristensen>
I think the problem is on master too, though?
<thefloweringash>
I get 2.2G for `du -hs /nix/store/56psrkjvcp0ki9n0v6mv3zspm1m2bd7v-ghc-8.6.5-binary`
<MichaelRaskin>
Profpatsch: I want rec enforcing aciclycity of references
<globin>
thefloweringash: on aarch?
<MichaelRaskin>
And note that once you define functions you can define Y combinator directly anyway
<thefloweringash>
globin: yep (shouldn't the store path ensure that too?)
<globin>
thefloweringash: yes, i'm just confused
<infinisil>
MichaelRaskin: Profpatsch: Btw there is #nix-lang for such discussions, it's kind of offtopic here
<globin>
thefloweringash: let me --check it
<Profpatsch>
infinisil: There’s a channel for everything!
<nh2>
also, do I read https://status.nixos.org correctly that this one package is what prevented `nixos-20.03` from advancing for 6 days?
<Profpatsch>
MichaelRaskin: It already starts with conditional stuff like ++ stdenv.lib.optional stdenv.isi686 "USE_LARGE_FILES=1"
<Profpatsch>
How to encode that?
<Profpatsch>
Because suddenly you need hella complicated logic in the description language.
<Profpatsch>
Or you are overly restrictive.
<MichaelRaskin>
It's a good question how much of this we have…
drakonis has quit [Read error: Connection reset by peer]
<Profpatsch>
MichaelRaskin: even a simple derivation like mktorrent has two different flags
<samueldr>
nh2: unlikely, transient failures (like timeouts) are lost when restarted
<Profpatsch>
And then the question is: where do you want to allow flags to influence the final data
<samueldr>
nh2: so it might not have been only one package during the 6 days, but it resolved in one, if you see what I mean
<nh2>
samueldr: not quite sur I understand, are you saying there may have been other things that held it back from advancing, but now it's only that one
<nh2>
samueldr: other question though: If _now_ we fix `elementary-videos` the channel would advance, right?
<samueldr>
assusming it's what stopped the pantheon test from going, highly likely yes
<Profpatsch>
MichaelRaskin: An easy check is grepping for isDarwin and looking at what people are doing with that.
<nh2>
samueldr: ok great, thanks
<samueldr>
(other failures could have been added in the meantime!)
<Profpatsch>
Because suddenly the data structure is turned into a DSL that has to support a boolean logic in most places.
<nh2>
samueldr: do you mean only in between pantheon and elementary-videos, or in other packages? Because I'd imagine that if it's other packages it would also show up? Or does it show only the first error there?
<samueldr>
in the time since 22h ago when the last build finished :)
<samueldr>
but highly unlikely on a stable branch
<MichaelRaskin>
Profpatsch: which is more annoying is that stdenv needs to be a parameter…
<Profpatsch>
It doesn’t need to, but then how do you represent it.
luc65r has joined #nixos-dev
<Profpatsch>
e.g. look at the cabal format, that’s similar.
<Profpatsch>
All the places they (have to) support arbitary boolean branching
<MichaelRaskin>
… and we already have the mess of all the cross-related inputs
<Profpatsch>
Well, those shoud be easy, because they are transparent.
<Profpatsch>
You supply all the different buildBuild, buildHost, … fields as dependency fields
<Profpatsch>
As long as there’s not too much branching going on inside the package descriptions, it’s fine.
<Profpatsch>
But you would have to severely restrict the branching in the package description itself.
<MichaelRaskin>
I mean, we already have this which is basically also branching but unrolled
<Profpatsch>
e.g a `license = if stdenv.isDarwin then licenses.unfree else licenses.gpl3` is only possible if the meta-language allows it.
<Profpatsch>
(in exactly that field)
<MichaelRaskin>
I think this is bad enough to use an escape
<Profpatsch>
Let’s say we allow it only in dependencies for now (which is not practical), how would I represent it, maybe like ([ shared-dependency ] ++ { flag = { f = "isAarch"; val = [ aarchDep ]; })
<Profpatsch>
And then you have to translate that to `optional stdenv.isAarch [ aarchDep ]` on the outside.
<MichaelRaskin>
I think a goal could be to allow plain-data selectors for the easy case, but arbitrary functions can also be selectors
<Profpatsch>
So how do you allow arbitrary functions without sacrificing the data-aspect of the format again?
<Profpatsch>
remember: there’s no passing any arguments to the file
<MichaelRaskin>
Profpatsch: did you open the link I posted?
<Profpatsch>
And also no local lambdas that are not completely filled in at the file border
<Profpatsch>
I saw the ({pkgs, platforms, ...}: platforms.linux), but that’s not gonna fly I’m afraid.
<Profpatsch>
Because suddenly it’s more complicated than what we do right now.
<MichaelRaskin>
I think if we gain enough eval-time win, people could agree to ({platforms}: platforms.linux) for escapes
<MichaelRaskin>
As escapes are discouraged anyway
<Profpatsch>
And then the interpreter has to call every field with `if builtins.isFunctions then <pass arbitrary arguments> else …`
<Profpatsch>
So you get one branch per item of each list.
<MichaelRaskin>
isFunction is probably the last branch, not the first
<Profpatsch>
Well, it’s still a branch
<MichaelRaskin>
The real branch is probably list-or-attrset
<MichaelRaskin>
Well, list-or-not
<MichaelRaskin>
The second one being attrset-or-not
<MichaelRaskin>
I guess
<Profpatsch>
Nah, not a good interface.
<tazjin>
Profpatsch: did someone say monorepo
<Profpatsch>
This shows the major restrictions of an untyped language like this, you just can’t build any good abstractions.
<Profpatsch>
tazjin: In passing :)
<infinisil>
You could make a strict DSL in nix :P
<Profpatsch>
well, yeah, that’s basically what we are proposing.
<simpson>
I don't know what types have to do with abstractions.
<MichaelRaskin>
Well, types would not really make it simpler
<Profpatsch>
simpson: good error messages for one, showing the user what is and isn’t allowed.
<simpson>
We have such a system for NixOS options. Types aren't needed to build such a thing, and usually some sort of type reflection ends up being necessary in statically-typed systems.
<Profpatsch>
simpson: yet, options are typed
<Profpatsch>
But let’s not get into discussions like that :)
<simpson>
I know the correct response for that, actually.
simpson has left #nixos-dev ["WeeChat 1.0.1"]
<Profpatsch>
lol, if you think so.
<MichaelRaskin>
Whatever we would use to put the type constructors into scope could be just used to smuggle other stuff in case of untyped Nix
<Profpatsch>
MichaelRaskin: as a first step, we could encode the lib.option dependency thing.
<MichaelRaskin>
Encode where?
<Profpatsch>
So my idea here is that callPackage is replaced by (callPackageNew version0_1), where version0_1 gives you the exact semantics of the format you have available.
<Profpatsch>
And that would determine the DSL you have available in your package.
<MichaelRaskin>
That does not sound as improvement
<Profpatsch>
Well, instead of your package being an arbitrary function, it is now a function restricted by the semantics of the builder you pass it.
<MichaelRaskin>
I am not sure it will help to reduce the RAM consumption of evaluation, though
<Profpatsch>
Which determines the exact library that is available to build the package.
<Profpatsch>
I was not aware that was a goal here.
<Profpatsch>
I don’t think leaf package descriptions like the ones we are talking about have a big influence on evaluation times tbh.
<MichaelRaskin>
I mean, just restricting from all-packages.nix what a package definition can use without gaining any performance benefit sounds like increasing the amount of places to check when doing updates
<MichaelRaskin>
They do!
<MichaelRaskin>
The corresponding function has to be constructed and then kept
<Profpatsch>
That’s about override(Attrs) though, isn’t it?
<MichaelRaskin>
(because without overrides everytihng falls down)
drakonis has joined #nixos-dev
drakonis2 has quit [Ping timeout: 256 seconds]
<Profpatsch>
Well, so I guess how this would work is that you start by restricting the interface that the packages can use, and then on the outside you can start optimizing, e.g. by keeping the package inputs as strings and figuring out an alternative way of overriding that doesn’t have to keep the old definitions around.
luc65r has quit [Remote host closed the connection]
<Profpatsch>
e.g. by exposing a set of flags that packages expose that are not just function arguments passed to them.
drakonis_ has joined #nixos-dev
<Profpatsch>
And finally, when enough packages use the new format, you add a flag that allows people on the outside to disable `.override` completely and only enable the more efficient new system.
drakonis1 has joined #nixos-dev
<MichaelRaskin>
Erm. Nixpkgs actually needs override in many places
<MichaelRaskin>
But maybe re-importing would be more efficient
<Profpatsch>
MichaelRaskin: for example?
drakonis has quit [Ping timeout: 246 seconds]
<MichaelRaskin>
I am pretty sure we end up having multiple overridden boosts
<Profpatsch>
Most overrides I see are either flipping some flags that a package exposes, or they overwrite a package.
<Profpatsch>
Which could both be done by exposing e.g. `slots` to the user that are names mapped to a type.
<MichaelRaskin>
Or passing an reconfigured dependency
<MichaelRaskin>
What the slots would give?
<MichaelRaskin>
There is still a full function to carry around
<MichaelRaskin>
With more or less the same body
<Profpatsch>
The package would say slots = { fooSupport = boolean; } or something, and it could switch on the flag e.g. with buildInputs = … ++ builderLib.boolSlot "fooSupport" [ "fooPkg" ]
<MichaelRaskin>
But still, a function with roughly the same body, no?
<Profpatsch>
And then another package could use a modified version of your package with setSlot pkg { fooSupport = true; }
<Profpatsch>
err, no, with setSlot "thatpkg" { fooSupport = true; }, since you want to reference packages by symbol not by structure.
<gchristensen>
who wants to refer to packages by symbol O.o eww
<gchristensen>
I thought I'd managed to escape that when I left debian etc.
<MichaelRaskin>
Mwahaha
<MichaelRaskin>
No escape
<gchristensen>
I mean, I can think of one escape
<MichaelRaskin>
Guix?
<gchristensen>
anything else
<Profpatsch>
Well, different abstraction level. You can also reference them via naturals :)
<Profpatsch>
In fact, you can reference every nix package that will ever be written by a natural!
<worldofpeace>
Dandellion: it really depends. If it's like a leaf package and for some reason you have to do the upgrade with a breaking change you have to. But if not, you shouldn't. Point of a stable distribution is basically the package versions
<garbas>
worldofpeace: tnx, i'll fix it.
<Dandellion>
yeah i'm asking because we haven't technically released yet. It'd suck to be stuck with traefik 1.0 for another 6 months on stable
<garbas>
worldofpeace: to make it a bit better then last time. can i have a peak at your release notes?
<worldofpeace>
garbas: I'm looking my notes for the news item "nixos logo for website is the resized logo in nixos-artwork 100px wide (with whatever height that is correct for that)". Do you mean the release announcement https://nixos.org/nixos/manual/index.html#at-final-release-time ?
<garbas>
worldofpeace: yeah, the announcement that you plan to put also on discourse. for now we will copy it and i hope until next time we will just use rss feed from discourse
<garbas>
next time == 20.09
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
bhipple has joined #nixos-dev
justanotheruser has quit [Ping timeout: 256 seconds]