<sonarpulse>
shlevy: in general i guess i will ruthless style critique infra and things that would get cargo culted
<sonarpulse>
(just ask dtz)
<sonarpulse>
but something like this which is unlikely to get coppied, eh...
pie_ has quit [Ping timeout: 245 seconds]
<shlevy>
sonarpulse: so should the only difference between stdenvCross and stdenv just be whether they set "cheating"?
<sonarpulse>
shlevy: I'd put it in stdenv/generic even
<sonarpulse>
there's a few build != host things there already
<shlevy>
So get rid of stdenvCross completely, and have generic take a flag?
<shlevy>
And have default set it yes for compat for now?
orivej has quit [Ping timeout: 256 seconds]
<sonarpulse>
shlevy: it already takes platform arguments
<sonarpulse>
and yes set compat for now
<sonarpulse>
for native
<sonarpulse>
shlevy: we should actually get rid of the cross adapater
<shlevy>
Sure, I mean a flag to say "cheat and put everything into PATH etc."
<sonarpulse>
shlevy: stdenv/cross/default can stay
<sonarpulse>
but here is why
<sonarpulse>
if we do my stdenv/generic -> build-support/stdenv
<sonarpulse>
and pkgs/stdenv -> pkgs/bootstrapping
<sonarpulse>
then it is clear that, yes, there is cross-specific *boostrapping*
<shlevy>
Right
<sonarpulse>
but not a cross-specific *stdenv*
<shlevy>
THe bootstrapping is the buildtime-native compiler, right?
<sonarpulse>
yeah, two extra stages
<shlevy>
(just to make sure we'reon the same terminological page)
<sonarpulse>
the cross tools and the cross packages
<shlevy>
OK
<sonarpulse>
[..normal, cross tools, cross pkgs]
<sonarpulse>
that is really all the pkgs/stdenv/cross/default.nix should do
<sonarpulse>
that's the goal at least
<shlevy>
Right. And ideally cross tools would either go away completely like llvm or be just special "normal" packages applied on top of some base multi-target system, right?
<shlevy>
But that's not something we can change by ourselves
<sonarpulse>
yeah
<sonarpulse>
none of this gccCrossStageStatic bussiness
<sonarpulse>
at least I got rid of gccCrossStageFinal
<shlevy>
OK so the specifics aboutmingw32 needs "file" and aarch64 needs "updateAutotoolsGnuConfigScriptsHook", those aren't really cross-specific, right?
<sonarpulse>
yeah
<sonarpulse>
the former can go in generic I suppose (if that's even true anymore)
<shlevy>
Does anyone target it? :o
<shlevy>
I don't even know who to ask
<sonarpulse>
angerman is working on windows stuff!
<shlevy>
why wouldn't the latter also go into generic?
<sonarpulse>
the latter is a bummer
<sonarpulse>
because
<sonarpulse>
if you look at the linux cross stdenv
<sonarpulse>
only certain stages have it
<sonarpulse>
I think the earliest cannot
<sonarpulse>
maybe there's a way to automatically do it with some sort of `buildPackages ? someDep`
<sonarpulse>
but i dunno
<shlevy>
Wait, why can't those be in the earliest?
<shlevy>
It just copies a config.guess right?
<shlevy>
sonarpulse: I wish there were some way we could do a similar restrictions for depsBuildBuild vs depsBuildHost... e.g. mark outputs of depsBuildHost binaries non-executable until the next stage :D
<sonarpulse>
shlevy: that would be nice!
<sonarpulse>
maybe just need to use a stdenvNoCC somewhere for the update....
<shlevy>
so all depsBuildRun (sorry, forgot to use the proper terminology) outputs would have to be post-processed?
<sonarpulse>
shlevy: for the latter, yeah we could just post fixup set executable bits
<sonarpulse>
but I suppose those outputs shouldn't be on PATHs anyways?
<shlevy>
Well the goal is to catch things that compile tools to help during the build
<shlevy>
If they're put into buildInputs later they won't be in PATH anyway
<shlevy>
and if they're put into nativeBuildInputs they'll be pulled from the previous stage
<shlevy>
But you definitely do want the outputs of depsBuildRun compilers to be on PATH eventually... That's the goal of cross-compilation ultimately :P
<shlevy>
Hmm... I wonder if we can do it with dynamic loader mangling
<shlevy>
So during the build the compiler gives a dummy loader
<shlevy>
and after we find all references to it and give it the real path
<shlevy>
Doesn't catch static, but if someone is compiling static binaries to run during the build and uses the wrong compiler I'm not sure how hard I want to try to help them :P
<clever>
if you wanted, proot can emulate binfmt-misc
<shlevy>
clever: that's going in the wrong direction :P
<shlevy>
We want to execute *fewer* binaries
<sonarpulse>
shlevy: oh so this is like about not keeping the outputs of depsBuildBuild around
<sonarpulse>
?
<sonarpulse>
i think i see
<shlevy>
sonarpulse: Well it's doing that *and* not executing the outputs of depsBuildRun during the build
<sonarpulse>
shlevy: ahhh i see
<sonarpulse>
nice!
<shlevy>
So when cc has host=target, in depsBuildRun it puts a mangled dynamic loader in
<shlevy>
And fixup fixes it up
<shlevy>
sorry, run = emit
<sonarpulse>
makes sense!
<gchristensen>
vcunat approved
<gchristensen>
should we merge this puppy?
<shlevy>
\o/
<shlevy>
Press the button
<sonarpulse>
woo!!!!
<gchristensen>
polynomial had some good feedback, but I'm not sure I want to do a revision,h eh
* shlevy
can already feel the power rushing to his head
<gchristensen>
shlevy: I can't press any buttons, I have no power on nixos/rfcs :)
<shlevy>
Aww it should be you
<gchristensen>
maybe we canget someone to get me access
<sonarpulse>
^ +99999
<gchristensen>
everyone with access is CET :P
<sonarpulse>
"communications and diplomacy team" should be able to merge rfc
<gchristensen>
lol
<sonarpulse>
rfcs in general
<gchristensen>
I'm actually not sure how people have merge access to that repo
<shlevy>
gchristensen: I appear to have rights
<shlevy>
But I'm not sure why :D
<sonarpulse>
do you have the rights to give graham the rights?
<shlevy>
I don't
<gchristensen>
actually
<gchristensen>
probably the person to do it
<gchristensen>
would be Eelco
<shlevy>
Yeah, if not you
<gchristensen>
... symbolically
<shlevy>
But I want to find out why I have rights... unless I was added as a user instead as part of a group?
<gchristensen>
must be
<gchristensen>
zimbatm has merge rights too but is only in the Nixpkgs Committers groups
<shlevy>
But there's no way I'm in a secret team that I can't see :D
<gchristensen>
very probably so
<shlevy>
(not really sure why e.g. nixpkgs committers is secret)
<gchristensen>
probably for strategic ( ;) ) reasons
<shlevy>
Anyway, let me know if you want me to merge or want to wait
<gchristensen>
I'd love to offer the opportunity to Eelco
<shlevy>
+1
TonyTheLion has quit [Ping timeout: 260 seconds]
sonarpulse has quit [Ping timeout: 240 seconds]
<angerman>
sonarpulse: so after playing with that a bit, it still won't work as I can't set `buildHaskellPackages = ps.buildPackages.haskell.packages.myghc;`
<angerman>
I guess we'll need some clean way to provide a custom ghc through config.nix?
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
thoughtpolice has quit [Ping timeout: 240 seconds]
gleber_ has quit [Ping timeout: 240 seconds]
zimbatm has quit [Read error: Connection reset by peer]
cbarrett has quit [Ping timeout: 240 seconds]
taktoa[c] has quit [Read error: Connection reset by peer]
ghuntley has quit [Read error: Connection reset by peer]
sorear has quit [Read error: Connection reset by peer]
manveru has quit [Write error: Connection reset by peer]
ocharles has quit [Ping timeout: 256 seconds]
mbrock has quit [Ping timeout: 256 seconds]
terrorjack has quit [Read error: Connection reset by peer]
angerman has quit [Ping timeout: 256 seconds]
pauldub has quit [Ping timeout: 240 seconds]
taktoa[c] has joined #nixos-dev
thoughtpolice has joined #nixos-dev
ghuntley has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
pauldub has joined #nixos-dev
zimbatm has joined #nixos-dev
gleber_ has joined #nixos-dev
cbarrett has joined #nixos-dev
angerman has joined #nixos-dev
adisbladis has joined #nixos-dev
sorear has joined #nixos-dev
manveru has joined #nixos-dev
ocharles has joined #nixos-dev
mbrock has joined #nixos-dev
terrorjack has joined #nixos-dev
JosW has joined #nixos-dev
davidlt_ has joined #nixos-dev
davidlt has quit [Ping timeout: 245 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
Lisanna has joined #nixos-dev
Lisanna has quit [Client Quit]
davidlt_ has quit [Remote host closed the connection]
<peti>
gchristensen: Thank you. :-)
davidlt has joined #nixos-dev
goibhniu1 is now known as goibhniu
__Sander__ has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
<gchristensen>
niksnut: you would like the honor of merging #25?
orivej has joined #nixos-dev
lopsided98 has quit [Ping timeout: 245 seconds]
<gchristensen>
shlevy: I thought paths kept in memory (like in a script) were automatically kept alive?
<shlevy>
gchristensen: Only on Linux, and I think there's a technical race while the outpath is still in the pipe buffer
<gchristensen>
interesting, why not instead use a tmpdir and result links in the tmpdir?
<shlevy>
Cleanup is not guaranteed
<gchristensen>
interestinger and interestinger
<shlevy>
gchristensen: I'd like to have a Store impl that just automatically sends permanent roots there... But C++'s metaprogramming is not good enough to easily make a forwarding store and I'm lazy :P
<gchristensen>
how did you come across this problem?
<shlevy>
Writing an internal nix installer that bundles in plugins and cache settings
<shlevy>
The installer users run is just a stub that a) runs the real nix installer if it's not installed already and b) pulls a real program from our binary cache and c) runs it
<shlevy>
Right now I just accept the race between b) and c) because it's a very small window and anyone running gc while running the script kind of has it coming ;)
<viric>
gchristensen: I think simply /proc/*/{exe,fd} are checked for runtime live paths
<shlevy>
viric: There's also memory scanning on linux
<viric>
Implement a nix gclock command to overcome races. :)
<shlevy>
and lsof on non-linux
<viric>
wow, very aggresive.
<viric>
shlevy: the mmaps in /proc you mean?
<sphalerite>
yeah so `sudo nix-store --delete <path>` will never work :D
<shlevy>
viric: Yep
<viric>
good
<viric>
"memory scanning" :)
<gchristensen>
well so I was also thinking about the environment variables
<gchristensen>
but I reckon macos doesn't have that either?
<shlevy>
Ah yeah for some reason I thought it was actually going through memory :D
<shlevy>
I guess not
<viric>
you frightened me
<LnL>
gchristensen: nope, no procfs or bind mounts on darwin
<sphalerite>
if you don't feel like breaking your system you might also want to kill SIGCONT it afterwards. But that's boring, right?
<sphalerite>
(also gets fun when the process stops itself)
<viric>
shlevy: ah I saw the riscv64 - what is that thing you run nixos on?
<sphalerite>
qemu right?
<viric>
oh, so disappointing if so. :)
<gchristensen>
shlevy: I'd be inclined to go the route of symlink cleanup too
<gchristensen>
with a trap to clean up the tmpdir of roots
<shlevy>
viric: qemu right now, HiFive Unleashed when it arrives
<viric>
shlevy: ah that sounds much better
<shlevy>
gchristensen: Right, but traps are unreliable. If your system relies on being able to run cleanup at its leisure your system is going to break :P
<shlevy>
(luckily, this will be easy to carry as a plugin if need be)
<gchristensen>
shlevy: I think I'm missing the part where cleaning up the process is more reliable
<sphalerite>
viric: does /dev/mem cover swap?
<shlevy>
gchristensen: If the system powers off, the process dies and its temproot (based on lock files) dies. If the script exits for any reason, it closes the stdin ofthe process and it exits
<gchristensen>
ah
<shlevy>
gchristensen: This is essentially the same safety you get if nix-build *itself* is terminated
<viric>
sphalerite: I expect not
<gchristensen>
I thought nix-build would let builds continue going if it was terminated ;')
<shlevy>
running a gc during nix-build is safe even if the out link doesn't exist yet
<gchristensen>
gotcha
<sphalerite>
I'd really like a way for nix-build to not be attached to the build process it spawns
<sphalerite>
so a build can continue e.g. if a remote build client loses its connection to the server
<sphalerite>
well in that case it's not actually nix-build but you know
<shlevy>
sphalerite: nohup?
<sphalerite>
shlevy: yeah sort of like wrapping the remote build process in nohup
<shlevy>
Oh, I see what you mean
<gchristensen>
or exactly wrapping the remote build process in nohup :)
<shlevy>
No, not quite
<shlevy>
Because e.g. ssh-ng talks to nix-daemon --stdio, which watches for stdin getting closed
<sphalerite>
I've frequently lost build progress from unreliable connections or from having to go from A to B with no internet connection in between A and B
<shlevy>
niksnut: Can I get github rights to create a new top-level team?
<sphalerite>
There is no nix cabal
<niksnut>
:-)
<shlevy>
niksnut: reviewing the PR now
<niksnut>
shlevy: how do I grant team creation rights?
<niksnut>
in any case I can create a nix-core team
<gchristensen>
pretty much have to be an "owner"
pie_ has joined #nixos-dev
<shlevy>
niksnut: I'd also like to create one for cross-compilation support, and musl if that goes through
<aminechikhaoui>
is #nix-core something for the general audience to discuss Nix related stuff with the core team or for the internal core team discussions ?
<shlevy>
I think both
<aminechikhaoui>
cool
<shlevy>
If we need a private channel at some point then we can get it then, but I hope it won't be needed
<shlevy>
Not general nix chat though, just stuff that is directed at core team business
manveru has quit [Read error: Connection reset by peer]
<niksnut>
actually what do we need a github team for?
<niksnut>
afaik they're mostly for repo access control
ghuntley has quit [Read error: Connection reset by peer]
<gchristensen>
they also provide the ability to tag the group
<samueldr>
I have this bot that logs channels (a bit like botbot does for #nixos), but I'm using it exclusively to log nix and nixos-related channels, which botbot won't because of their size, should I make it join #nix-core too?
<shlevy>
samueldr: Yeah
<samueldr>
btw, if there are any nix or nixos-related channel where it is wanted, just ask
<gchristensen>
btw nix core team, now that it is a thing, I'm going to be stepping aside to let y'all do your thing. let me know if you want me to help on stuff :)
ghuntley has joined #nixos-dev
manveru has joined #nixos-dev
{`-`} has joined #nixos-dev
<sphalerite>
-/j #nix-core
<aszlig>
btw... we do have a systemd regression at some point
<sonarpulse>
so great to not splice and call package
<sonarpulse>
but we need to think of something else
<sonarpulse>
shlevy: ^
<shlevy>
Yeah, I need to finish the proposal then wan to write up my thoughts
<shlevy>
sonarpulse: One easy but ugly thing is to have each package reference its variant in the previous stage
<shlevy>
so gcc.previous would be the cross compiler for example
<sonarpulse>
yeah
<sonarpulse>
shlevy: but it keeps a problem we have today
<sonarpulse>
package doesn't eval in current stage, but does in previous
<shlevy>
Well, ideally "package doesn't eval" wouldn't be a thing if you're not accessing the outPath or nix-env metdata
<shlevy>
It's just a set :)
<sonarpulse>
shlevy: true, but there's a number of ad-hoc assertions to get rid of
<sonarpulse>
and i suppose i can turn functions into "functors"
<sonarpulse>
never got around to that with splicing
<sonarpulse>
niksnut: I gather today nix is good at being agressive about lexical scope where there is no with or similar that must delay name resolution
<shlevy>
Yeah
<shlevy>
parse time
<sonarpulse>
does include vs import have any changes wrt that?
<sonarpulse>
I'd think maybe we have to eval packages for callPackage, but the scope of all-packages.nix is known earlier
<sonarpulse>
that might have neat effect on eval times
<sonarpulse>
shlevy: i think we might need a general "topic: portability" label
<shlevy>
sonarpulse: +1
<shlevy>
Do it :)
<shlevy>
sonarpulse: Yeah, it looks like {{ sets necessarily have to delay scope resolution until fix time
<shlevy>
Well, actually
<shlevy>
At parse time they can see if a certain thing is in scope
<shlevy>
But yeah
<sonarpulse>
shlevy: well see what niksnut linked above
<sonarpulse>
maybe we already have include
<sonarpulse>
(sounds like scopedImport anyways)
<shlevy>
niksnut: Maybe this is answered already, but how does (let x = 1; in {{ y = x; }}) // {{ x = 2 }} give?
<shlevy>
sonarpulse: If that is meant to eval with mainline nix, it has to use scopedImport somewhere... But I suspect it's partof an experimental branch of nix
<sphalerite>
what about nbp's "SOS" proposal?
<shlevy>
sphalerite: Go check the latest comments there ;)
<sphalerite>
ah right :D
<pierron>
I will comment tomorrow (when I would not be working)
<pierron>
niksnut: removing the clear scope of files is scary
<pierron>
niksnut: This sounds like a sanity issue to me that a file can behave differently based on its caller. (with the same arguments)
<simpson>
Hmmmm. Isn't this a kind of dynamic scoping?
<niksnut>
yes
<niksnut>
but once we started sticking pkgs. in front everything, the effect was the same, just more verbose
<simpson>
Hm. You're totally right, but I can't help but wonder if this means that we've been headed in the wrong direction with nixpkgs and we should be looking for something more compositional.
<niksnut>
the main advantage to declaring function arguments is that you get error messages if you make a typo
<niksnut>
however, "with" already broke that
<simpson>
Right, with the function introspection it's basically a signature.
<simpson>
Yeah, your reasoning is solid. I guess I'm gonna have to just get over it.
<shlevy>
simpson: Treat it as a less verbose way of declaring a function, not a dynamic scope :)
<shlevy>
It's not syntactic, you have to explicitly // in your argument set
<shlevy>
(with, of course, is terrible)
<shlevy>
sonarpulse: Yeah, so ideally what we'd have is the resolution scope for 'buildInputs' is a different set than that for nativeBuildInputs
<sphalerite>
I'm not sure I understand why all-packages.nix would be a non-extensible attribute set...
<sphalerite>
niksnut: I also don't get what the {{{ }}} is for?
<niksnut>
I fixed that as well
<sphalerite>
(in the firefox flashplayer examples)
<sphalerite>
ah ok
<shlevy>
sphalerite: Oh, I hadn't gotten to "include" yet :o
<shlevy>
sphalerite: Never mind, it's pure dynamic scope
<sonarpulse>
shlevy: i thought it was only that in conjunction with {{ }}
<niksnut>
sonarpulse: what's the problem with crosscompilation exactly?
<sonarpulse>
it is just "same scope" {{ }} is a form of dynamic scope
<shlevy>
niksnut: We want buildInputs to pull from a different package set than nativeBuildInputs
<shlevy>
I'm not sure why we need include as a language builtin
<sonarpulse>
niksnut: we've done first a nasty make derivation hack by viric, and now a nasty callPackage hack by me
<shlevy>
Instead of just include = f: (import f) // pkgs
<shlevy>
or not // exactly but something which takes things from pkgs as appropriate
<niksnut>
yes, if 'f' is an extensible attrset, you don't need include
<shlevy>
IMO that's much nicer
<niksnut>
but we don't have extensible attrsets
<shlevy>
But it's probably morally equivalent
<sonarpulse>
err but package extensible attr set
<sonarpulse>
is different fixpoint
<sonarpulse>
than set of all packages
<shlevy>
We don't have include eiterh ;)
<niksnut>
yes, but moving to the use of 'include' is a much smaller change
<sphalerite>
well, semantics gotchas and cross-compilation issues aside, this stuff sounds very cool and nice to use. I feel unqualified to comment on the issues arising from it though :p
<sonarpulse>
we could have {{ }} literally desugar into a self-super function
<sonarpulse>
asdf = ....;
<sonarpulse>
the scope of ... is
<sonarpulse>
with self; let include (super) asdf; <this scope>
<sonarpulse>
with self; let include (super) asdf; in <this scope>
<sonarpulse>
that would be the correct thing 99% of the time
<shlevy>
niksnut: Without super how do we do variants or overrides that the merge function didn't account for?
<niksnut>
we don't
<shlevy>
Well, ignore variatns I guess
<shlevy>
But for the latter that basically means out-of-tree overlays get much weaker
<sonarpulse>
I would prefer experimenting without langauge changes first, but I would prefer just new syntactic sugar without new values second
<niksnut>
the module system doesn't have "super" either, so I hypothesize that we can live without it
<sonarpulse>
niksnut: It's a fair hypothesis, but nixos modules system is working on like a derivation preimage at the end of the day
<shlevy>
I'm skeptical... The module system doesn't deal with overriding packages, and it doesn't let you override modules *at all*
<sonarpulse>
no subverting the abstraction of individual modules
<sonarpulse>
and many "extraConfig" attrs to work around
<sphalerit>
Also for the module system I've often wished there *was* a super
<sonarpulse>
we want to override *both* arguments to abstractions (mkDerivation, buildXXXPackage) or the output (raw derivation)
<shlevy>
niksnut: e.g. in the target haskell infrastructure we turn on profiling for all packages, and have a custom helper to disable certain profiling flags on certain packages. In a super-less world I'dneed to add that functionality into upstream nixpkgs?
<sonarpulse>
yeah haskell *heavily* uses super
<sonarpulse>
ahh this is too interesting/important but i do need to go eat
<dtz>
aww can't join nix-core via matrix? maybe a channel flag or something.
<shlevy>
dtz: Let me know what I need to do to fix it
<sphalerite>
dtz: did you message appservice-irc with !join #nix-core ?
<sphalerite>
dtz: it might just be that nobody's in there thorugh matrix yet so for the purposes of matrix it doesn't exist yet
<dtz>
haha no I just tried https://riot.im/app/#/room/#freenode_#nixos-dev:matrix.org only s/nixos-dev/nix-core/
<dtz>
haha
<niksnut>
shlevy: I think you would override builders.ghc to set enableProfiling by default
<shlevy>
niksnut: FWIW, my experience with NixOS is of just copying modules wholesale and adding little tweaks in part because we don't have something like super
<sphalerite>
^ +1
<shlevy>
"So we may want to have a language construct that changes the lexical scope in which a particular attribute of an extensible attrset is evaluated." ah this could be used for cross I think
<shlevy>
niksnut: If we have = for a merging assignment, maybe we can have := for a non merging assignment and on the RHS of foo := <expr> foo refers to super?
<niksnut>
yeah that would be a possibility
<shlevy>
that would also get rid of "order 0"
<niksnut>
right
<shlevy>
I'm curious how much of this needs to be built in vs just using strings in various places that functions replace with real packages
<shlevy>
I think having it built-in would be great eventually, but if we can iterate without language changes and validate the design..
<shlevy>
.
<niksnut>
well, we currently have a language that's neither a good general purpose language nor a good DSL
<shlevy>
Sure
<niksnut>
we keep expressing domain problems in the existing language rather than adding special syntax for them
<shlevy>
But if we can go 80% of the way and try it in the real world for awhile with some hacks or inefficiency but without codifying any changes...
<shlevy>
Right, the goal here would be to mimic the functionality of the new language design
<shlevy>
Eventually to be replaced
<shlevy>
It's not necessary of course, but if we *can* do it then we can be more confident that the design solves the problem.
<sphalerite>
is there any way to verify the contents of a chroot store currently? It seems to try to verify all the paths from the main store in the chroot store, which results in a bunch of No such file or directory errors
<__Sander__>
speaking about DSLs
* __Sander__
has some fond memories of my JavaScript experiment hehe
<__Sander__>
announced on April 1st
<__Sander__>
:D
<shlevy>
:D
<shlevy>
sonarpulse: Are you willing to try the move to the generic cross-compilation interface alongside an experimental nix-2.0 implementation of niksnut's ideas? I don't want to conflate unrelated things unnecessarily, but this would be a really good test case for ironing out the kinks
alunduil has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
pxc has joined #nixos-dev
<sonarpulse>
shlevy: yes sure
<shlevy>
Cool :)
<sonarpulse>
niksnut: I'm actually quite found of how we've one OOP-as-a-library
<sonarpulse>
it's lead me to believe there's a number of fixed point ideoms
<sonarpulse>
and trying to bake them into the language is more difficult to get right than the original smalltalkers or whowever thought
<sonarpulse>
now, granted, your design is a lot better than those for what we do too :)
<sonarpulse>
but yeah I am in no rush to need/want more sugar
<simpson>
sonarpulse: FWIW there's an entire branch of the Smalltalk family without classes or inheritance, where languages like E and Monte dwell. I don't feel like the nixpkgs lib provides objects, just traversal and cyclic structures.
<sonarpulse>
simpson: sure
<sonarpulse>
not super familiar
<sonarpulse>
but know those things exist
MichaelRaskin has joined #nixos-dev
disasm has quit [Ping timeout: 256 seconds]
taktoa has joined #nixos-dev
<shlevy>
niksnut: Is there any way to disable using builders as an unprivileged user
<shlevy>
Also, is there any way to disable running local builds when all of the builder's slots are taken?
<niksnut>
-j0
<niksnut>
no you can't disable builders as an unprivileged user
<shlevy>
-j0 doesn't get forwarded?
<shlevy>
OK, cool
disasm has joined #nixos-dev
<shlevy>
niksnut: Should it be possible? --no-build-hook used to be forwarded right?
<niksnut>
hm yeah
<thoughtpolice>
Here's a question: why can't I use `--builders` as an unprivileged user? (This is probably obvious, but)
<thoughtpolice>
This surprised me on my Fedora machine with 2.0
<thoughtpolice>
(Which uses `nix-daemon`)
<sphalerite>
thoughtpolice: it can only be set by trusted users
<sphalerite>
thoughtpolice: we need a warning or error for when settings are ignored like that
<shlevy>
thoughtpolice: builders can add arbitrary things to the store
<thoughtpolice>
Is that an even newer option? (Or one I just wasn't aware of?)
JosW has quit [Quit: Konversation terminated!]
<shlevy>
see trusted-users in nix.conf
<shlevy>
it's relatively new I think
<sphalerite>
thoughtpolice: trusted-users has been around for a long time I'm pretty sure
<shlevy>
:D
<shlevy>
2014
<sphalerite>
it was added in 2014
<shlevy>
I guess that's not new
<shlevy>
I'm just old :P
<thoughtpolice>
Ah, well that will be nice to fix so my 1950X is doing a bit more work around here...
<thoughtpolice>
(I don't really care to *always* remotely build on my laptop but the cores help for certain things)
<MichaelRaskin>
Yes, I liked the idea of having trusted-builders with users choosing an arbitrary subset
<shlevy>
Yeah, I like that too
<sonarpulse>
+1
<sphalerite>
something something DoS
<MichaelRaskin>
In what direction?
<shlevy>
sphalerite: I can already spam nix-daemon :P
<sphalerite>
idk really, but really giving anyone access to a nix daemon gives them DoS opportunityies
<sphalerite>
yea
<MichaelRaskin>
Oh well
<MichaelRaskin>
Do you give /dev/fuse access?
<MichaelRaskin>
I recently found a very interesting variation on the topic of fork-bomb using FUSE
<MichaelRaskin>
What is the simplest way to get a container in a VM-booted NixOS ISO?
<MichaelRaskin>
Maybe I should test if this fork-bomb is containable…
<sphalerite>
systemd-nspawn probably
<MichaelRaskin>
Are these supposed to be fully isolated and protect the host?
<sphalerite>
not sure
<sphalerite>
it certainly depends on the configuration
<sphalerite>
like there are definitely confiugrations which very much don't protect the host
<MichaelRaskin>
Because I can nsjail even without systemd
<MichaelRaskin>
I specifically want to see something that is supposed to be a VM replacement.
<MichaelRaskin>
(to see if this kind of resource exhaustion is still a problem)
<sphalerite>
is there such a thing at all?
<MichaelRaskin>
I mean, cloud hosts advertise container-based VPS
<MichaelRaskin>
I don't want to test on someone's production, though.
<sphalerite>
that's fair :D
<sonarpulse>
niksnut: here to merge the 2.0 PR now?
<sonarpulse>
everyone is delegating to everyone else
<sonarpulse>
I should just go merge it haha
<shlevy>
sonarpulse: ever run into an issue with strip cross-building a run=emit gcc?
<sphalerite>
MichaelRaskin: from #systemd: dreisner | sphalerite: no, nspawn makes no attempts to be a security-focused sandbox.
<shlevy>
configure looks like it finds riscv64-unknown-linux-gnu-strip but the actual failure references plain old strip
<MichaelRaskin>
Thanks
<sonarpulse>
shlevy: no, but a lot of cross just disabled strip across the board
<shlevy>
sonarpulse: Would you strongly object to 'stripped' defaulting to !(buildPlatform != runPlatform && runPlatform == emitPlatform) instead of "true"?
<shlevy>
I figure, if we're cross-building a run-native gcc we're just going to build bootstrap tools then build a native bootstrap tools anyway
<sonarpulse>
shlevy: across the board? fine with me
<shlevy>
Cool
<sonarpulse>
I made doHostStrip doCrossStrip
<sonarpulse>
but since this sefaulting on unknown binaries things happens
<sonarpulse>
I don't think those will help
<shlevy>
FWIW I bet this will be fine once everyone updates to binutils 2.30
<shlevy>
after all we build for all targets
<shlevy>
riscv just didn't land yet in 2.29 :D
<shlevy>
niksnut: settings.maxBuildJobs.set("1"); <- build-remote.cc sets this and it seems to get forwarded to nix-daemon --stdio :(
<niksnut>
you mean when using ssh-ng?
<shlevy>
Yeah
<niksnut>
so we shouldn't forward settings via ssh-ng
<shlevy>
Mm
<MichaelRaskin>
Ideally, one could want to ask builder to build with or without parallelism…
<sonarpulse>
shlevy: did they fix gnu as ?!?!?!
<sonarpulse>
oh
<sonarpulse>
right
<shlevy>
Hm?
<shlevy>
:D
<MichaelRaskin>
In the sense that per-package preferences and per-machine preferences can vary independently
<sonarpulse>
GNU AS is still the sole non multi-target part of binutils
<sonarpulse>
the rest happy obeys `--enable-targets=all`
<shlevy>
Aaaah
<sonarpulse>
as we do today
<shlevy>
So I bet that's why libsupc++ works for other platforms
<sonarpulse>
ah!
<sonarpulse>
really want to just patreon somebody to do gnu as
<sonarpulse>
not really important, but it just annoys me, job not done
<shlevy>
So if this fixes it I'll merge it forward to my binutils-2.30 branch and revert it there and see what happens
<sonarpulse>
:D
<sonarpulse>
sounds goodo
<shlevy>
Then we'd only need one binutils per build system right?
<sonarpulse>
yup!
<sonarpulse>
just re-wrap it
<sonarpulse>
for different targets
<shlevy>
Honestly I'd love to break out the target-specific knowledge of these tools into separate libs
<shlevy>
A common core driver, target-specific plugin (still part of the build-time package set of course)
<shlevy>
sonarpulse: Are we thinking about moving to always-prefix toolchains by the way?
<shlevy>
niksnut: Is it expected that nix copy is a noop with drvs?
<sphalerite>
^
<sphalerite>
this has bugged me quite a bit
<sonarpulse>
shlevy: I am
<sonarpulse>
but I haven't floated it with other people besides you
<sonarpulse>
(e.g. pinging them in that issue)
<shlevy>
:D
<shlevy>
sphalerite: Ah, I think I can get it working if I do nix-store -r with the local store as a substituter and the remote store as my store :D
<shlevy>
That will also start building but I can interrupt it at that point
<sphalerite>
>_>
<shlevy>
Nope, that didn't work
<shlevy>
OK, tryingto make a drv that takes that drv as a source input :D
<sphalerite>
on the topic of fixed-output stuff — we should make writeTextFile fixed-output!
<sphalerite>
The file's contents, and therefore their hash, can be computed at build time so all we need is the hashing bit. Which would probably be easier to implement as a builtin than in nix :p
<sphalerite>
s/build time/evaluation time/
<gchristensen>
like outputHash = builtins.hashString "sha256" outputString; ?
<shlevy>
sphalerite: Maybe you could find some way to lever builtins.hashString :P
<shlevy>
leverage*
<sphalerite>
something like that
<sphalerite>
I'm not sure it's possible without an additional builtin though
<sphalerit>
Since you need to produce a nar dump for it
<shlevy>
OK, starting my native build of stdenv for RISC-V :D
<aszlig>
shlevy: btw. which RISC-V hardware do you have?
<shlevy>
I'm getting the HiFive Unleashed
<shlevy>
I'm on qemu for now
goibhniu1 has joined #nixos-dev
<dtz>
^_^
goibhniu has quit [Ping timeout: 245 seconds]
<shlevy>
Sadly need to fix ssh-ng as a remote builder before I can share the setup widely :(
<shlevy>
Who was it that was working on that..
<dtz>
ah, i was wondering if that was especially problematic when remote builder is of different system
<dtz>
what does ssh-ng get you here over normal ssh store?
<dtz>
at one point for some variety of bad reasons :P I had a setup involving automounting /nix/store via sshfs lol :D
<shlevy>
dtz: The full store API
<shlevy>
Anything you can do over the daemon, you can do over ssh-ng
<shlevy>
And if your ssh user is in trusted-users on the remote, even more anything
<MichaelRaskin>
Read-only store over sshfs is OK…
<LnL>
shlevy: except for the settings I got ssh-ng to work with some simple changes IIRC
<shlevy>
Yeah, it's hte settings thing
<shlevy>
I just want to fix it right
<LnL>
that would be great, ran into that again today
<shlevy>
LnL: were you working on the "forwardable vs overideable" distinction?
<shlevy>
I think error messages aren't propagated rightwithout it...
<shlevy>
Ah well
<LnL>
I do remember there was something that caused the log to be streamed back twice breaking the nix build progress stuff
<LnL>
otherwise I would have created a pr for it
<dtz>
anyone know a good way to use a path in an expression like "builtins.storePath" but that causes nix to attempt to fetch it from substituters/remote stores if not locally available?
<dtz>
maybe kinda like what hydra used to do when generating nix channels, although I'm not sure.
<sonarpulse>
LnL: what was our last blocker with darwin->linux?
<LnL>
the kernel headers
<LnL>
I had to add some weirdness because of file case normalisation but there's also some cross issues with the build
<MichaelRaskin>
I wonder if filename-case-sensitive Darwin should be declared a separate platform
<MichaelRaskin>
It's the second time this week I hear of case-sensitivity problems…
<LnL>
it's not that common
<MichaelRaskin>
Well yes, because even on a fully supporting system it messes with the user's mind a bit.
<LnL>
once apfs becomes more prominent a solution could be to setup (or recommend) a separate case sensitive volume for the store
jtojnar has quit [Ping timeout: 256 seconds]
sonarpulse has quit [Quit: Leaving]
jtojnar has joined #nixos-dev
<Dezgeg>
I'd expect packages only tested on linux (by upsteam) have more problems with case insensitivity than other way around
sonarpulse has joined #nixos-dev
sonarpulse has quit [Quit: Leaving]
<zimbatm>
who has access to the nixos.org DNS, niksnut ?
sonarpulse has joined #nixos-dev
<zimbatm>
I think we should create a discourse instance to replace the ML
<zimbatm>
it would help communication and allow to classify threads better
<zimbatm>
especially with more teams being formed
<sonarpulse>
:q
sonarpulse has quit [Quit: Leaving]
<samueldr>
zimbatm: time for a RFC?
<zimbatm>
probably, it's going to be hard to compete popularity with the latest RFC :)
<samueldr>
does it need to? :)
<zimbatm>
no I'm happy if it gets accepted
goibhniu1 has joined #nixos-dev
goibhniu has quit [Ping timeout: 252 seconds]
goibhniu1 has quit [Ping timeout: 248 seconds]
<MichaelRaskin>
Well, codifying #nixos-chat happenned with no RFC…
goibhniu has joined #nixos-dev
<MichaelRaskin>
I mean, you probably need to let people try discourse during the RFC discussion, but then you could start experimenting with an instance without an RFC, and if it catches on, RFC can be not even needed.
<shlevy>
zimbatm: I'd be interested in seeing what discord would look like
<zimbatm>
shlevy: did you mean discourse?
<shlevy>
zimbatm: How hard would it be to set up a dummy with some threads as they are in the ML (or as they could've been better if they'd been there in the first place)
<shlevy>
:D Yes
<shlevy>
IRC is fine :P
lopsided98 has quit [Ping timeout: 240 seconds]
<zimbatm>
IRC forever
<gchristensen>
you can check out their demo install