blazked has quit [Quit: Connection closed for inactivity]
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
wavirc22_ has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has quit [Ping timeout: 256 seconds]
wavirc22_ has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<thefloweringash> it's not super stable, but I made it to kde:
zupo has joined #nixos-aarch64
<sphalerite> thefloweringash: nice¬!
<sphalerite> which phone is that?
<thefloweringash> Nexus 5 / lg-hammerhead
<srk> cool
<srk> reminds me of a friend who was running Inferno on his nexus for few weeks :D
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
<prusnak> thefloweringash: nice! will you send a PR to the repo soon? I have lg-bullhead (Nexus 5X) here, done some work there, but I assume lots of stuff from your effort can be reused
prusnak has quit [Changing host]
prusnak has joined #nixos-aarch64
prusnak has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has left #nixos-aarch64 [#nixos-aarch64]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Asmadeus has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
orivej has joined #nixos-aarch64
<thefloweringash> prusnak: I need to iron out a few more things. I'm still having trouble with the display. if you want to see my current state, it's up on github:
<thefloweringash> and if you want to build up to kde on armv7, my nixpkgs fixes are also on github:
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
julm has joined #nixos-aarch64
zupo has joined #nixos-aarch64
samrose_ has joined #nixos-aarch64
samrose has quit [Ping timeout: 256 seconds]
dongcarl has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
mla has quit [Ping timeout: 258 seconds]
v0|d has quit [Remote host closed the connection]
nschoe has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
womfoo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<womfoo> hi guys! i recently got an e-ink HAT for my rpi3b+. has anyone gotten to make this work on nixos? i'm still unfamiliar with SPI/GPIO/etc. on rasbian, its just a matter of adding dtparam=spi=on in config.txt
<clever> womfoo: if you add that dtparam to config.txt, and uboot isnt breaking things, you should then get a /dev/spi-something in linux
<womfoo> yup adding the dtparam still manages to boot. nothing new in /dev/spi*
<clever> you may need to modprobe something...
<womfoo> tried modprobing it but nothing shows up
<clever> `modprobe spidev` ?
<lopsided98> dtparam doesn't work when using U-Boot
<womfoo> yes tried that and spi_bcm2835
<clever> ah, so the firmware is generating a new and updated DTB, but the uboot throws that out and uses its own DTB
<clever> which breaks everything
<lopsided98> there is the hardware.deviceTree.overlays option, which works if you have a DT overlay that enables SPI
<womfoo> oh no wonder i dont see the gradient at startup
<{^_^}> #79370 (by sorki, 12 weeks ago, open): Improve device-tree overlay support
<srk> or womfoo ^
<clever> womfoo: the rainbox is done by start.elf before it launches uboot
<lopsided98> yeah, that PR fixes a lot of the issues with that option. In particular it is currently not possible to apply overlays to the standard NixOS mainline kernel
<womfoo> interesting, if i apply this patch will it recompile everything?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<srk> only device trees, according to comments it needs updating for cross-compiling to work
<srk> almost got to that today.. soon
zupo has joined #nixos-aarch64
<womfoo> nice, let me read up on dtbs and dtbo. will have to compare whats getting loaded in raspbian.
<womfoo> or is there a handy utility to dump this?
<srk> fdtdump iirc
<clever> womfoo: i think you want one of these spi files, not sure which one
<srk> clever: they are not for mainline tho
<clever> oh
<srk> yeah..
<srk> there's a repo
* srk 's trying to find it..
<womfoo> yeah tried dumping files inside /boot/nixos/...linux..-dtbs earlier but it didn't pick it up
<womfoo> not sure if its sensitive to filenames or dups?
<srk> also dtc can (de)compile these
<srk> but it's probably best to grab linux git repo and look there as decompiled are not nice to work with :)
<womfoo> yeah its easier that way
<womfoo> i do have to mention that i havent tried the same kernel version yet
<clever> srk: how does fdtdump differ from just using the dtc command to turn a dtb back into a dts?
<womfoo> raspbian is on 4.x
<clever> srk: ive also had trouble before, getting dts files with #include to compile, you seen the "right" way to do that?
<clever> its anoying to have to translate c #define's into ints myself
<srk> clever: the PR does that I think
<srk> clever: or maybe you mean something different - it enables resolving symbols
<clever> srk: when compiling my own dts files like this, i cant use #include to leech constants from c header files
<clever> i havent figured out what i'm missing to fix that
<srk> I think it's symbols, still looking
<srk> dtc
<srk> -@, --symbols
<srk> Enable generation of symbols
<srk> but now I'm not sure if that also works for includes because I'm still using
<srk> gotta check linux source too
<srk> yeah, with symbols <BCM2835_FSEL_ALT0> _should_ work as well, need to test again
<srk> I'll take a look at that tomorrow as I need to apply another overlay to fix gpu on my laptop
<clever> without that change, it does:
<clever> Error: /nix/store/bwdlv35yczswqlghb164xs9s8y1n2idw-rpi3.dts:138.26-27 syntax error
<clever> srk: with -@, it fails the exact same way, checking one more thing...
<clever> Error: /nix/store/ws4v7wnlfjj6wkdrww935q4jy939v578-rpi3.dts:5.1-8 syntax error
<clever> srk: yeah, -@ doesnt allow you to #define within the dts file
<srk> yeah, I think I confuse these two things and the constants needs linux source..
<srk> symbols are merely to able to refer to e.g. target = <&gpio>;
<clever> the constants needs some special build flag, to allow the c pre-processor to run over it
<clever> and then some .h files, to get constants from
<srk> hmm, sounds easy when you put it like that :)
<clever> i tried just blindly running cc -E over it, but it didnt work
<clever> i have also noticed that turning the c pre-processor on in haskell, breaks how \ behaves at the end of lines, causing compile failures
<srk> hah :D
<clever> the pre-processor deals with \ for you, combining lines
<clever> which changes the syntax of the haskell code
<srk> I see, don't have not much experience with that, it feels weird to have C preprocessor in Haskell :D
<clever> its mainly used in FFI based code
<clever> when you want to import c constants into haskell
* clever gets example
<srk> yeah, makes sense. and for compatibility accross ghcs and libs
<srk> no need to, had the pleasure :)
<srk> last time with rtnetlink-hs ;)
<clever> i think thats using hsc though, which does diff things
<srk> > hackage "rtnetlink-hs"
<srk> hmm
<clever> 404
<srk> > hackage "rtnetlink"
<srk> this
<clever> ah, nice
<srk> quite useful lib!
<clever> ive had to deal with that lib in c++ before i think
<clever> when writing my vpn
<thefloweringash> The trick is to use: cc -x assembler-with-cpp -E
<srk> oh nice
<srk> thefloweringash++
<{^_^}> thefloweringash's karma got increased to 11
<clever> thefloweringash: i'll give that a try in a min or 2, currently cross-compiling brick to armv7
<clever> > hackage "brick"
<srk> aaa, I need xmonad! :D
<srk> haskell cross just works now?
<clever> srk: seems to
<srk> epic
<srk> can finally unify my desktop configurations for both x86 and armv7 :D
<clever> srk: this will cross-compile a c library, then cross-compile HPi (which links to that c lib)
<clever> > "HPi"
<clever> > hackage "HPi"
<{^_^}> "HPi"
<clever> builder for '/nix/store/yq31wkgw4hqcfh1fqpw2qaj88qc206rq-primitive-' failed with exit code 1
<clever> but vector cant build...
<srk> nschoe was trying to build HPi as well ^ :)
<clever> • Couldn't match expected type ‘Int#’ with actual type ‘Int64#’
<clever> srk: he's the one that told me it builds successfully
<clever> and ive wanted a better gui for managing gpio stuff
<clever> but brick depends on vector, which depends on primitive, which fails to build
<clever> Data/Primitive/Types.hs:279:1279: error:
<srk> aah, right :)
<srk> I think I'll try to write libgpio bindings
<clever> what the heck is that?
<clever> oh
<clever> CPP, line 208
<srk> wow
<clever> i think the problem, is that sIZEOF_INT is using the host sizeof(int)
<clever> which breaks when doing 64->32 cross-compile
<clever> and nschoe did aarch64 target, so he probably avoided it
<srk> lol I now remeber I've managed to crosscompile ghc already for armv7 few weeks ago but didn't do anything with it..
<srk> now it's probably gced already
<srk> :D
<srk> ahaa
<clever> srk: i just pushed and let my hydra do it
<srk> makes sense
<clever> that both roots it, and keeps updating the root with all future pushes
<srk> yeah, I don't have a hydra atm :(
<srk> but enough spare SBCs to build one..
<clever> my laptop is the build machine for hydra
<clever> and the nas runs the hydra itself
<srk> and spare laptops!
<srk> :D
<clever> now the tricky part, doing 32bit ghc...
<srk> I have unused x230 but it has bad fan so I don't want to push it
<srk> until I replace it, overheats quite a lot
<clever> pkgsi686Linux.pkgsCross.raspberryPi.hello
<clever> > pkgsi686Linux.pkgsCross.raspberryPi.hello
<{^_^}> "<derivation /nix/store/55rw3fmrnm36rylfyp6wcyas8kljv5f4-hello-2.10-armv6l-unknown-linux-gnueabihf.drv>"
<clever> will this use a 32bit cross-compiler....
<srk> mm, even armv6, nice!
<srk> neat trick
<bennofs[m]> Saw you were talking about DT overlays before. The dtbs in nixos mainline are not compiled with symbols, so the usual overlay stuff is a bit tricky to use
<clever> /nix/store/fah0fy53gcnm1697xn75hvj8h857lbh2-stdenv-linux.drv is indeed a 32bit derivation
<clever> i think that will work
<thefloweringash> ghc on armv7 would be nice to have. There’s no upstream binary but we could build our own cross bootstrap ghc
<clever> thefloweringash: last time i tried to run ghc natively on arm, it segfaulted if you used more then -j1
<thefloweringash> Did that pull request to make device tree overlays in nix have symbols by default and also support rpi overlays get merged?
<thefloweringash> clever: where did you get the ghc from?
<clever> arm732 = pkgs.pkgsi686Linux.pkgsCross.armv7l-hf-multiplatform.extend overlay;
<clever> srk: this should use a 32bit cross-compiler to build to arm7
<srk> thefloweringash: needs updating, tomorrow
<clever> thefloweringash: cant remember, it was many months ago
<srk> gonna test that for sure
<thefloweringash> Oh, #79370
<{^_^}> (by sorki, 12 weeks ago, open): Improve device-tree overlay support
<clever> srk: hydra is now building ghc again, this time for 32bit
<srk> cool, will grab that :)
<clever> but, i dont think a 32bit x86->arm compiler is in upstream hydra
<clever> so i have to build some gcc's first
<clever> srk: i think thats the pubkey for my hydra
<srk> thanks!
<srk> noted.
<nschoe> srk: hi, was away. I did manage to build HPi for aarch64. I packaged bcm2835 if needed, too. I can provide the gist.
<clever> nschoe: does brick build for aarch64?
<nschoe> clever: did not try it yet.
<nschoe> clever: give me a sec I'll try right now
<nschoe> clever: it's building deps now.
<nschoe> clever: no it fails to build because of depency microlens, because if I understood correctly what alp told me: forcross-compiling we're building a ghc stage1, and stag1 is not able to compile template haskell.
<clever> nschoe: ah, what about vector?
<nschoe> clever: building now
<srk> I can try building native one with stage1 if it works and if I figure out how
alp has joined #nixos-aarch64
<nschoe> srk: I asked alp to join an quickly described your problem, here's what he's told me: "
<nschoe> Now I believe alp joined, so if you have more questions he might be able to answer if he's around:-)
<nschoe> one needs to use -fexternal-interpreter, along with an instance of the "iserv" program, to run TH with cross-compilers"
<alp> stage 1 ghcs (e.g cross-compilers) _can_ run TH but this requires -fexternal-interpreter along with a local/remote iserv process which can interpret TH for the stage 1 GHC and communicates with it
<nschoe> clever: (it's still building deps for vector0
<alp> angerman knows this inside out :-)
<nschoe> s/o/)
<srk> oh cool :)
<srk> I was talking to him today, good to know :D
<srk> alp++
<clever> yeah, angerman has written haskell.nix, which deals with the cross-compile and TH stuff fully
<clever> and cabal conditionals
<clever> the cabal file can contain if statements, so you only depend on unix on unix-y platforms, and Win32 on windows
<clever> haskell.nix translates that to nix if statements, so you dont wind up building Win32 on linux
<srk> awesome, haskell everywhere \o/
<clever> and it also adds a bunch of new features, like building each component (the library, executables, and tests) in seperate derivations
<clever> the windows TH currently uses wine and iserv-proxy
<clever> originally, iserv-proxy was meant to run directly on the target device (like an iphone), and handled running TH on the target
<clever> qemu-user-arm could also be used, to handle arm TH
<clever> and if your not running child procs, qemu-user is as simple as wine, no need for root
<srk> I need to take a good look at haskell.nix :)
<nschoe> clever: yup, 'vector' just finished building for aarch64, no build error.
<clever> nschoe: for me, vector depends on primitive
<clever> nschoe: and primitive fails due to type errors, mixing up 32bit and 64bit stuff
<clever> nschoe: i think whats happening, is that primitive is using the host sizeof(int) and then things fall apart when the target has a different pointer size
<clever> nschoe: since you did x86_64 -> aarch64, things lined up, and vector/primitive just work
<clever> but i'm targetting armv7l, so i need to use an i686-linux -> armv7l cross-compiler
<nschoe> clever: uh, good catch
<nschoe> well maybe primitive can be fixed / patched?
<nschoe> Is it _supposed_ to take the host's sizeof?
<clever> nschoe: i think its supposed to use target sizeof
<clever> but its just grabbing a .h file, and using host gcc to build it
<nschoe> :/
<clever> haskell.nix might already fix this
<clever> or maybe not, we are cross-compiling to win64, so it could have slipped under the radar
<nschoe> Hum, I'm trying to cross-compile hsI2C, it fails because it requires base<4.11. So I have an override of aarch64-multiplatform.haskellPackages with "base = super.callHackage "base" "" {};" but it fails with "error: anonymous function at /nix/store/ccywvfqq5m3ji9lp7rik74wyb45k2drg-cabal2nix-base- called without required argument 'invalid-cabal-flag-settings', at /home/nschoe/nixpkgs/pkgs/
<nschoe> Am i missing something obvious?
<nschoe> development/haskell-modules/make-package-set.nix:87:27"
<clever> nschoe: you cant change the version of base in haskellPackages
<clever> nschoe: its a boot package, and handled specially
<clever> you can try jailbreak instead, to make it ignore the base version
<nschoe> erf
<clever> the nixpkgs haskell infra is additive
<nschoe> So it means git clone the repo locally, remove the base constraint, and rey, right?
<clever> nschoe: nope, nixpkgs has a jailbreak function
<clever> nschoe: haskell.lib.doJailbreak
<clever> the ghc within nixpkgs, includes several "boot" packages, specifically, Cabal and all of its deps
<clever> enough that you can compile a Setup.hs file and run it
<clever> every other library you want, is just merged into the ghc-pkg db, using buildEnv
<clever> because its additive, adding a 2nd base would cause duplicates, and break everyting
<clever> so the boot packages cant be updated at all
<clever> haskell.nix on the other hand, constructs the entire ghc-pkg db from scratch, for each package
<clever> so its capable of changing those packages
<nschoe> ok, so I'm trying doJailbreak.
alp has quit [Ping timeout: 272 seconds]
<nschoe> clever: good! hsI2C built with doJailbreak.
<clever> nschoe: you may still want to check the cabal file for it, and see if any comments say why it had that constraint
<clever> ive seen some things, where the constraint was due to silent data corruption on certain versions
<nschoe> clever: don't see anything there.
<clever> nschoe: yeah, and git blame says its been there since day 1
<clever> the constraint likely has no purpose, and shouldnt really be there
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nschoe> clever: I'm about to copy teh closure on the rPi and try to make my test program work, seewhat this does.
<clever> performing step ‘/nix/store/cabwyx7rc82bwsqg2scl6g1xv3x1xx7h-glibc-2.27-armv7l-unknown-linux-gnueabihf.drv’ 1 times on ‘builder@’ (needed by build 100738 and 1 others)
<nschoe> clever: perfect! hsI2C test program works on the rPi, and it doesn't "mess the i2c bus" like HPi does when using the clode() and end() function.
<nschoe> I guess I'll write my driver with it hsI2c then.
zupo has joined #nixos-aarch64
<clever> performing step ‘/nix/store/avp7kvlrrlgxxgn12j277zmx7pn8wa1w-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-6.5.0.drv’ 1 times on ‘builder@system76.localnet’ (needed by build 100738 and 1 others)
<clever> performing step ‘/nix/store/qnygsjp79ja0x8i7n2czawapyikmak3m-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-9.2.0.drv’ 1 times on ‘builder@’ (needed by build 100738 and 1 others)
<clever> ok, weird, its now cross-compiling 2 gcc's at once
<clever> nschoe: uh oh, now its building llvm
<srk> I think that's the default for arm
<srk> not even sure if there's any other way
<srk> cross compiling llvm? :D
<clever> srk: native llvm, but it failed
<clever> /nix/store/37ybk085fpwl7qbf8gnypbr7l06w203i-bash-4.4-p23/bin/bash: ../../bin/llvm-tblgen: cannot execute binary file: Exec format error
<nschoe> clever: ah, good luck :/ Mine compiled gcc and ghc.
<nschoe> Laptop died of OOM when compiling GHC because I had optimistically set --cores 4 -j 4.
<clever> nschoe: 32gig of ram
<nschoe> clever: :D
<nschoe> Show off ^^
<clever> so i cant build vector for armv7l with a 64->32 cross compile, due to a ghc bug
<clever> i cant 32->32 cross compile, due to llvm failing to build
<clever> and aarch64 isnt viable for one of my targets, because i dont have 64bit boot yet
<srk> x86 ghc targeting armv7? :)
<srk> not sure if possible
<clever> srk: the x86-64 ghc targeting armv7l "works", but primitive fails to build due to using the host sizeof(int)
<clever> srk: so only a small subset of hackage can be used
<srk> ah, right
<srk> primitive has no issues related to arm on github
<clever> it looks like a cross issue
<clever> due to the host and target having differnt bit-widths
<srk> LD_PRELOAD sizeof? :)
<clever> srk: sizeof is a compiler trick
<clever> not a real function
<srk> aah, of course
<clever> srk: i think the problem is that sIZEOF_INT is wrong
<srk> hmm, patching primitive with hardcoded val work(around)?
<srk> primitive patch heh
<clever> /tmp/nix-build-llvm-6.0.1.drv-0/llvm/build/bin/llvm-tblgen: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /nix/store/xyffzrwpk2wrawz6mm5qzpqy2k6l5v18-glibc-2.27-armv7l-unknown-linux-gnueabihf/lib/, for GNU/Linux 2.6.32, with debug_info, not stripped
<clever> it seems that it build an arm binary for the llvm
<clever> i think its an i686-linux -> armv7l-linux cross llvm
<clever> and it broke
alp has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<alp> perhaps you can apply a patch on the fly, to use the right bit-widths where appropriate? might be painful, but better than not being able to use primitive =)
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zarel_ has joined #nixos-aarch64
zarel has quit [Ping timeout: 265 seconds]
Thra11 has quit [Quit: WeeChat 2.8]
minicom has quit [*.net *.split]
mvnetbiz_ has quit [*.net *.split]
ornxka has quit [*.net *.split]
andi- has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
qyliss has quit [*.net *.split]
{^_^} has quit [*.net *.split]
lopsided98 has quit [*.net *.split]
greizgh has quit [*.net *.split]
andi- has joined #nixos-aarch64
minicom has joined #nixos-aarch64
qyliss has joined #nixos-aarch64
ornxka has joined #nixos-aarch64
greizgh has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
aminechikhaoui has joined #nixos-aarch64
womfoo has quit [Ping timeout: 260 seconds]
{^_^} has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
alp has joined #nixos-aarch64