<shlevy>
peti: When does haskell-updates get merged?
<shlevy>
peti: Can I merge my GHC fixes in once hydra is done?
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
romildo has joined #nixos-dev
yegortim1 has quit [Ping timeout: 255 seconds]
yegortim1 has joined #nixos-dev
taktoa has quit [Remote host closed the connection]
yegortim1 has quit [Ping timeout: 255 seconds]
yegortim1 has joined #nixos-dev
romildo has quit [Quit: Leaving]
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
ma27 has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
Lisanna has joined #nixos-dev
Lisanna has quit [Client Quit]
ma27 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 252 seconds]
mingc has quit [Quit: WeeChat 2.0.1]
<peti>
shlevy: I merge regularly -- mostly whenever there's no more (or very little) breakage due to updates.
<peti>
shlevy: About the GHC patches: I am somewhat surprised (and a little scared) to learn that those patches break legitimate builds! That doesn't sound like a good idea. What about people who try to compile packages with our GHC using stack or cabal-install? They'll run into weird build errors then without any clue at all what is causing them. I, personally, I was *very* surprised when liquidhaskell suddenly
<peti>
stopped compiling.
<peti>
shlevy: So I'm wondering whether it might be better to apply your patches to a variant of the normal ghc and to keep our default compiler pristine and predictable.
goibhniu has joined #nixos-dev
mingc has joined #nixos-dev
goibhniu has quit [Client Quit]
goibhniu has joined #nixos-dev
goibhniu has quit [Ping timeout: 265 seconds]
goibhniu has joined #nixos-dev
FRidh has joined #nixos-dev
<FRidh>
Is it possible to use a chroot store that uses /nix/store/ store paths while Nix itself is running from and targetting a custom location? The use case I see is when user namespaces are not available but you still want to use a store in your home folder, without having to rebuild everything (just nix end deps)
orivej has joined #nixos-dev
FRidh has quit [Ping timeout: 276 seconds]
disasm has quit [Remote host closed the connection]
ghuntley has quit []
ghuntley has joined #nixos-dev
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
gchristensen is now known as nixos
nixos is now known as gchristensen
<shlevy>
peti: I'll try a variant of the patch that doesn't change exposed interfaces
zimbatm has quit []
zimbatm has joined #nixos-dev
<shlevy>
peti: The reason LH hit it was they copied GHC modules wholesale into their tree, I knew on some level that you *could* technically import any GHC module but these ones are morally internal so I didn't think about it in those terms.
pauldub has quit []
pauldub has joined #nixos-dev
manveru has quit []
manveru has joined #nixos-dev
ocharles has quit []
ocharles has joined #nixos-dev
FRidh has joined #nixos-dev
mbrock has quit []
mbrock has joined #nixos-dev
orivej has joined #nixos-dev
ma271 has joined #nixos-dev
ma27 has quit [Remote host closed the connection]
ma271 has quit [Ping timeout: 260 seconds]
__Sander__ has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
ckauhaus has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
<ckauhaus>
"grahamcofborg-eval — Failed to enumerate outputs after merging to staging"
<Mic92>
when your pr has a changelog, it is too big.
<ckauhaus>
can be used as benchmark for various pieces
<copumpkin>
niksnut: I see you removing nixos-prepare-root in the nix-2.0 branch
<gchristensen>
cheesy petes dtz! :D
<copumpkin>
niksnut: not quite clear how make-disk-image works after that though
<niksnut>
it calls nixos-install
<copumpkin>
niksnut: didn't you just stick most of the logic back in runInLinuxVM, which was what I went to all the work to undo?
<dtz>
LOL sorry
<dtz>
new browser benchmark
<niksnut>
copumpkin: no
<niksnut>
I didn't move anything into runInLinuxVM
<niksnut>
nixos-install runs outside of the VM
<copumpkin>
oh
<copumpkin>
you have a nixos-enter now, hmm
<niksnut>
it no longer needs root
<copumpkin>
interesting
<copumpkin>
I'm going to need to test this since I make images with this code a dozen times a day :P
* copumpkin
shudders a little
<copumpkin>
looks exciting if it works!
<niksnut>
yeah please test
aminechikhaoui has quit [Ping timeout: 260 seconds]
<dtz>
ckauhaus: yeah I need to cleanup accesses to stdenv.glibc; started doing so (feature/musl-next) but still going through.. and since this is already way too big might handle that separately
<ckauhaus>
would probably be a good idea to squash that one into 4 commits or so conforming to the stages in the PR changelog
<niksnut>
copumpkin: channel installation in the image is currently missing btw
<copumpkin>
I was actually going to make that optional
<copumpkin>
just talked about it with a colleague yesterday :P
<copumpkin>
I don't like how that all works today
<copumpkin>
niksnut: did you run into issues with it or just haven't gotten around to it yet?
<niksnut>
no, it just needs a --channel flag to nixos-install, similar to --closure (which should be renamed to --system)
<dtz>
ckauhaus: well I'm hoping review and such will work towards getting the result into a good place, then we can rewrite history about how to get there "sanely" :D
<copumpkin>
aha
<dtz>
although this is already highly reduced from original xD but still a way to go :)
aminechikhaoui has joined #nixos-dev
aminechikhaoui is now known as Guest38534
FRidh has joined #nixos-dev
<copumpkin>
are we moving to llvm 5 for 18.03?
<LnL>
I'm planning to fix qt and merge the update this weekend
<dtz>
\o/
Sonarpulse has joined #nixos-dev
<Sonarpulse>
dtz: I'm pursuadable, but currently thinking for now we get rid of is{Glibc,Musl}
<Sonarpulse>
otherwise we have two sources of truth
<dtz>
(!) two?
<Sonarpulse>
yeah
<Sonarpulse>
if libc is overridden
<Sonarpulse>
those can be wrong
<Sonarpulse>
cause those are used to set libc
<Sonarpulse>
and don't take into account libc
<dtz>
(I already moved to "hostPlatform.isGlibc" instead of stdenv.libc)
<dtz>
err
<Sonarpulse>
because the matcher thingy only takes account .parsed
<Sonarpulse>
dtz: or rather here's a more modest thing
ma271 has quit [Ping timeout: 255 seconds]
ma272 has joined #nixos-dev
<Sonarpulse>
lets do that *just* to add your lib changes
<Sonarpulse>
before my lib changes, even
<Sonarpulse>
(cause not sure where vcunat is who did much of the meta checks)
<Sonarpulse>
then, instead of immediately massively refactoring all your other commits
<Sonarpulse>
maybe we can instead move libc to parsed
<Sonarpulse>
or make the matcher include everything
<Sonarpulse>
so isMusl isGlibc will take account libc overrides
<Sonarpulse>
make sense?
<dtz>
yes! Well I think so :).
<dtz>
err everything other than "lets do that just to add your lib changes"
<dtz>
I'm not sure it makes sense to have conflicting config and libc entries anyway??
<dtz>
but if that's not something we should reject I agree that currently isMusl/isGlibc do wrong thing and badness will result when trying to use a config like { config = "x86_64-unknown-linux-musl"; libc = "glibc"; }
<Sonarpulse>
"I'm not sure it makes sense to have conflicting config and libc entries anyway?"
<Sonarpulse>
that's a good point
<Sonarpulse>
dtz: ok step 1) lib changes with is{glibc,musl}
<Sonarpulse>
step 2) remove all explicit libc setting; it should only be a "derived parameter"
<dtz>
ah, haha okay
<Sonarpulse>
optional step 3), get rid of glibc field altogether, just computing it on the fly, also adding back in is{Glibc,Musl}
<Sonarpulse>
dtz: also sorry to go afk for a bit, got distracted with coworker's monitor setup
<dtz>
haha np! :D
<Sonarpulse>
*get rid of libc field
<Sonarpulse>
stdenv.glibc should/is going too, but that's separate :)
<dtz>
yeah, I'm gonna restore that in this PR I think, too messy to remove right now :(
<Sonarpulse>
dtz: yeah no prob
<Sonarpulse>
that's why i think it's good to land steps 1 and 2 separately
<dtz>
related: using 'stdenv.cc.bintools.dynamicLinker' is "wrong" when patchelf'ing things since that's from target not host.... right?
<Sonarpulse>
3 could just be beginning of pr or separate too
<Sonarpulse>
dtz: actually that should be right?
<Sonarpulse>
stdenv contains package from previous stage
Guest38534 has quit [Quit: leaving]
<Sonarpulse>
so stdenv.cc is like buildPackages.{gcc, clang}
<dtz>
which is a shame because it'd be nice to replace every mini table or if/else chain computing dynamic linker (mostly when handling proprietary code)
<dtz>
Sonarpulse: oh? well that'd be awfully nice :D
<Sonarpulse>
yeah it's the previous stage's target platform
aminechikhaoui has joined #nixos-dev
<Sonarpulse>
which is the current stage's host platform
<dtz>
yay! :D
aminechikhaoui is now known as Guest73477
Guest73477 has quit [Remote host closed the connection]
<dtz>
on the subject, I actually was wondering: does.... overrideCC somehow (somehow?!) magically handle platforms ? haha
<Sonarpulse>
dtz: doubt it
<Sonarpulse>
what do you mean?
<Sonarpulse>
what would this magic be?
aminechikhaoui has joined #nixos-dev
aminechikhaoui is now known as Guest60246
<dtz>
well so sometimes we do things like "stdenv = overrideCC stdenv gcc6" and in a cross-env you'd want the gcc6 to be something you could run, not the gcc6 in scope (which might be.. host=arm or something)
Jackneill has quit [Read error: Connection reset by peer]
<dtz>
IIRC it definitely does not on master, not sure when that started
<dtz>
haha
<dtz>
psh I took 4 years of LTO in high school
<dtz>
AP LTO
<dtz>
lol
<Sonarpulse>
what's that even stand for lol
<Sonarpulse>
in AP context
<dtz>
although on my branch the wrapper fails because it uses coreutils compiled from arm instead of elsewhere, no idea what that's about
<Sonarpulse>
dtz: yeah wrappers haven't been used with build != host at all
<Sonarpulse>
that's not you
<Sonarpulse>
that's just existing not done work
<dtz>
LTO=link-time-optimization; AP is.. "advanced placement". It's some thing for high schoolers to get college credits (mostly skip early stuff) by taking a special class + test at the end
<dtz>
anyway nevermind it was a silly joke :D
<dtz>
there are AP classes for a number of things including languages like french/spanish/etc
<dtz>
...lol O:)
<dtz>
okay cool re:wrappers, seems like NBD just was worried I borked it but couldn't fathom how/why
<dtz>
:D
<Sonarpulse>
dtz: heh i thought it was like AP LiTerature O...
<dtz>
haha no that would maybe make sense :D
goibhniu has quit [Ping timeout: 240 seconds]
ma273 has joined #nixos-dev
ma272 has quit [Remote host closed the connection]
JosW has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
JosW has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 276 seconds]
Lisanna has joined #nixos-dev
JosW has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
garbas has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #nixos-dev
ckauhaus has quit [Quit: Leaving.]
JosW has quit [Quit: Konversation terminated!]
<LnL>
Mic92: Profpatsch: what's going on with squashfuse?
<Profpatsch>
LnL: Ah, that was a little bit unfortunate.
<Profpatsch>
That genesis guy escalating like that is kind of funny and disturbing, though.
<Profpatsch>
Maybe I pushed the right/wrong buttons? Not sure.
<gchristensen>
yikes
<LnL>
dunno what's going on, all I see is somebody complaining and a revert pr without context
<samueldr>
it's pretty awesome, had an early preview yesterday
<gchristensen>
* note please don't share this around :P it isn't tested against malicious inputs / doesn't handle edge cases very well
<Mic92>
gchristensen: you have my discretion
orivej has joined #nixos-dev
<Mic92>
I see terraform :)
<gchristensen>
:)
<Mic92>
gchristensen: btw. if your system is running systemd, you can do proper, safe kexec with systemctl.
<gchristensen>
oh cool
<Mic92>
it does a filesystem sync
<gchristensen>
oops someone else tried it and it didn't work ...
<gchristensen>
something to fix :)
<LnL>
was it me?
<LnL>
:D
<gchristensen>
probably
<LnL>
/o\
<gchristensen>
for some reason it uses a shared lock for all terraform deployments, despite there being multiple terraform deployments here
<gchristensen>
ok Mic92 you should be up now
<Mic92>
gchristensen: yes, login works
<gchristensen>
its fitting the first thing anyone does with it is setup a tor node :P
<Mic92>
gchristensen: no, it's only the client so
<Mic92>
I use this for service discovery
<gchristensen>
ahh
<gchristensen>
my motivation: wouldn't it be neat if there was a try-it-now site where you can launch a NixOS VM and play with it for an hour? This would also let you provide a gist of a NixOS configuration to use in the box, just like Rust's playground. Imagine being able to get support for _your entire OS_ by pasting a `configuration.nix`.
<MichaelRaskin>
I should try running containers on NixOS booted from live image…
<gchristensen>
Mic92: what'd you think? :D
<MichaelRaskin>
I have a failure of FUSE that seems to bring chaos in a weird way (a very hard to kill fork bomb that works as a bomb without creating actual processes? I don't want to repeat it…), and I want to see if the chaos can break out of container.
Sonarpulse has quit [Ping timeout: 240 seconds]
<Mic92>
gchristensen: This definitely lowers the barrier. How do you get the VM ressources?
<Mic92>
MichaelRaskin: the FUSE servers or clients accessing it.
<Mic92>
?
<MichaelRaskin>
Well, if just a single client hanged, that would be OK
<Mic92>
I think I have read most of the FUSE kernel code by now
<MichaelRaskin>
Well, spawn a VM you can discard, and install unionfs-fuse.
<MichaelRaskin>
To DoS the VM, try to union /tmp/a/ and /tmp/b/ into /tmp/a/
<Mic92>
ah a cycle that nobody stops
<MichaelRaskin>
I tried to abort the fuse connection via fusectl FS and failed
<MichaelRaskin>
I tried to kill -9 the unionfs process
<Mic92>
thanks to fuse automatic multi-threading, it will also use all cores.
pie_ has quit [Ping timeout: 276 seconds]
<MichaelRaskin>
I think at some point I lost the ability to spawn new processes.
<grahamc>
Mic92 I’m just paying for hetzner :)
<MichaelRaskin>
I only wrote FUSE FSes myself in Common Lisp, and there I had to reimplement the event loop and threading.
<Mic92>
I did the same for Rust.
<Mic92>
not the whole thing though
<MichaelRaskin>
I think Rust at least has an option to use FUSE main loop through a few more unsafe's
<Mic92>
I did not use libfuse
<MichaelRaskin>
With advanced automatic GC's it may become not an option at all.
<MichaelRaskin>
Oh.
<MichaelRaskin>
I ended up using a large part of libfuse, I had no reason to reimplement FUSE protocol parsing.
<MichaelRaskin>
Just had to reimplement the event loop and threading.
<Mic92>
did you implement threading with a Queue?
<MichaelRaskin>
Wait, _my_ implementation is in Common Lisp
<Mic92>
the actual language does not make that much of a difference as long as it is reasonable fast. I measured that only 2% of the time was actually spent in my FUSE code.
<Mic92>
well depends on what the FUSE does maybe.
<MichaelRaskin>
I just assume from capitalisation that Queue is a specific type
<Mic92>
No it's just my weird brain, that makes me write subjects sometimes with capital letters - this is a German thing.
<MichaelRaskin>
A German thing should apply to _all_ the nouns!
<gchristensen>
he did say weird :)
<MichaelRaskin>
I grabbed a queue/thread pool library, yes.
<MichaelRaskin>
I do manage to make FUSE not the slowest link sometimes; that requires issuing nontrivial SQL queries inside directory listing.
garbas has quit [Quit: WeeChat 1.9.1]
<MichaelRaskin>
Preferably to large tables, of course
<gchristensen>
you are a fascinating person
<MichaelRaskin>
We were promised a fusion of DBs and FSes, and where?
<MichaelRaskin>
So I had to hack together my own…
<gchristensen>
:D
<Mic92>
MichaelRaskin: BigQuery is a DB on an Filesystem.
<MichaelRaskin>
A specialised DB on a restricted-API FS…
<MichaelRaskin>
I want SQL and a POSIX FS to work together!
<gchristensen>
I support this
<MichaelRaskin>
I actually partially do have them work together…