Sonarpulse has quit [Ping timeout: 240 seconds]
<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]
Jackneill has joined #nixos-dev
ma271 has joined #nixos-dev
disasm has joined #nixos-dev
ma271 has quit [Ping timeout: 240 seconds]
<Mic92> This pr can serve as a benchmark for github's website https://github.com/NixOS/nixpkgs/pull/34645
ma271 has joined #nixos-dev
<ckauhaus> heh
<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]
Guest60246 has quit [Client Quit]
<Sonarpulse> dtz: yeah that's all wrong
<Sonarpulse> should be buildPackages.gccc6
<Sonarpulse> stdenv is weird
<Sonarpulse> not surprised most code is being wrong
<dtz> okay
<dtz> nbd just wanted to check
<Sonarpulse> sure np
<Sonarpulse> i wish i we could just get rid of stdenv
<Sonarpulse> have a more modular notion of "providing packages"
<Sonarpulse> where one interface is satisified by multiple packages
Jackneill has joined #nixos-dev
<Sonarpulse> (shell, cc, ld, etc)
<Sonarpulse> dtz: any idea how cross jobs broke?
<dtz> looking into it. the first failure is apparently some cross thing re:android; aarch64 gcc6 works for meeee
aminechikhaoui has joined #nixos-dev
<Sonarpulse> hmm
<dtz> oh
<dtz> i mean it works for me on my feature/musl branch lol
<Sonarpulse> lto's not a language lol
<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
<LnL> ah
<Profpatsch> The Github profile of genesis/bignaux looks a bit empty https://github.com/bignaux
<Profpatsch> Of course that doesn’t has to mean anything.
<gchristensen> so uh, anyone want to try nixos? I have room for three people to try it.
<LnL> I'm testing something if I can use nixos-unstable ;)
<gchristensen> hrmmm that might actually work
<gchristensen> your custom config should be able to do that just fine
<gchristensen> LnL: https://codepen.io/gchristensen/full/rJjvqY/ go ahead, you can be the first of three :P
<Mic92> gchristensen: context?
<gchristensen> Mic92: ^ check it out :)
<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…