alp has quit [Ping timeout: 265 seconds]
<angerman> I know some people actually use haskell.nix to build arm binaries. blackriversoftwa I abbliebe and there is another one in the issue haskell.nix tracker who just found a weird ghc llvm Ir bug. I haven’t heard of incorrect sizes yet?
<clever> angerman: the incorrect sizes have so far only happened with a 64bit host and a 32bit target, while building primitive
<clever> angerman: only confirmed to happen via standard haskellPackages.primitive, not tested with haskell.nix yet
<clever> angerman: is the full error log
<clever> angerman: and the final nail in the coffin, i want brick, which depends on vty, which depends on microlens, template haskell
<hexa-> gchristensen: +7k? wtf :D
<gchristensen> previous evals aborted the jobs regularly so they just weren't attempted
<hexa-> oh well
<angerman> clever: haskell.nix does have qemu-arm TH support.
<hexa-> gchristensen++
<{^_^}> gchristensen's karma got increased to 280
<clever> angerman: nice, i should look into getting it to work then...
<angerman> clever: haskell-nix.cabalProject + crossSystem.
<clever> angerman: first, i should start by trying to just build brick for the host, using haskell.nix, then it should "just work" when i set crossSystem...
<angerman> That’s the idea after all, yes.
<clever> angerman: what if i lack both a stack.yaml and a cabal.project?
<angerman> cabal.project < "packages: ."
<clever> i dont have a cabal file either, i was trying to get brick to build before i started that
<angerman> I think we might even infer that if there is no cabal.project, but maybe not.
<angerman> Haskell-Nix.hackage-package { Name = „brick“ ... }
<clever> heh, i cant just eval haskell.nix from `nix repl nix/sources.nix`
<clever> the attr needs to be quoted, so it wont work via the current scope, only as foo."haskell.nix"
jamii has joined #nixos-aarch64
<jamii> samueldr: better late than never -
<samueldr> jamii: sorry, late about? :)
<jamii> You asked about the app I was making and I said I would post something tomorrow. About three weeks ago :)
<samueldr> oops, that memory of the event must have left me :)
<jamii> :)
<samueldr> I'm currently putting some ducks in a row about writing stuff
<samueldr> I'll end up writing a (personal blog) post about mobile nixos and the pinephone "some assembly required"
<samueldr> because while I don't remember about the app, now I remember about helping you getting started
<jamii> Sweet, I'll keep an eye out for it
<clever> angerman: ah, it needed just "packages:", the `.` complained due to a lack of .cabal files
<jamii> Thanks for the help btw
<samueldr> they'll mostly be a rehash of the instructions, plus a couple alternative ways to do so
<samueldr> I don't think they'll end up useful for you :)
<angerman> clever: cabal less projects seem odd.
<clever> angerman: its more that i havent written a cabal file yet, because there is no point if i cant get the deps to build
<jamii> They might. I have everything working but I don't understand what I did. Eg why there are separate stages, what the boot process looks like.
<jamii> I guess I don't know much about arm in general.
<jamii> samueldr: Can you recommend any good resources for getting a high-level understanding of how the boot process works on arm?
<samueldr> hmm
<samueldr> in a way, most of what is relevant here is not specific to arm
<samueldr> the main thing specific is u-boot, and how it's part of the image
<samueldr> u-boot is not specific to arm, though
<samueldr> u-boot is kind of both a firmware (like a bios, like an uefi) and a bootloader (like grub, like systemd-boot)
<samueldr> we can abstract the boot flow here to "somehow it jumps to u-boot", the details are probably not important unless you work on the bootloader
<samueldr> and "somehow it jumps to u-boot" can be explained that the SoC looks for a program at a specific offset on the storage
<clever> for allwinner stuff, i believe the SoC loads a small blob from a specific offset
<clever> that blob brings dram online, and loads more blob after itself (the uboot code)
<samueldr> yeah
<samueldr> (but let's not break down the abstraction)
<clever> for zynq, its also 2 blobs, the 1st handles dram again, 2nd can be uboot, not sure where they are stored though
<samueldr> we can draw a full bull picture, or just enough to explain :)
<samueldr> anyway, how u-boot is started is not that important, only that it has to be present at a specific offset on the storage,
<samueldr> what I linked is basically where it is written to for allwinner SOCs
<samueldr> for u-boot systems, Mobile NixOS has a a boot flow that differs from NixOS proper and u-boot
<samueldr> though it is made so it ends up being more similar to other mobile devices, for all the good and the bad it implies :)
<samueldr> u-boot will read the boot script from the first partition marked bootable on the device it has been read from
<samueldr> this is where it stops being specific to u-boot
<samueldr> other platforms will load the initrd and kernel through other mechanisms that are not important here
<samueldr> but at that moment all devices do the same, they run the kernel!
<samueldr> on all systems running the linux kernel, the kernels "does stuff™", and then wants to run something
<samueldr> either what it's been told to run (init=) or /init
<jamii> So does the image built by `-A build.disk-image` contains uboot and the bootscript, and looks for a kernel on p2?
<samueldr> on p1
<samueldr> our init script doesn't do much, it starts a daemon to collect log output, and then runs the actual init code
<samueldr> that init does some things like starting udev to get all the hardware sorted out
<samueldr> it also mounts the filesystems on top of /mnt, and ends up "exec"-ing into whatever is the selected (or default) generation's init
<samueldr> at that point it's a bog standard nixos thing, nothing from Mobile NixOS
<samueldr> that is stage-2
h0m1 has quit [Ping timeout: 240 seconds]
<samueldr> so the boot chain specific to Mobile NixOS exists only from the boundary at the bootloader, up until the standard NixOS stage-2
<samueldr> here the u-boot program is an implementation detail, it's not really part of Mobile NixOS and that u-boot build should be able to boot anything just like u-boot does
<jamii> Ok, that makes things a lot clearer. Thanks for the explanation.
<jamii> I have to join a call in a minute but I'll dig through this stuff tomorrow and see if I can get it all straight in my head :)
h0m1 has joined #nixos-aarch64
<samueldr> no worries
<samueldr> it _is_ a lot to digest, but thankfully there's not too much that's specific to Mobile NixOS
jamii has quit [Remote host closed the connection]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
fps has joined #nixos-aarch64
<thefloweringash> I can't reproduce the failure at, can we try restarting the build?
<thefloweringash> and related question: will hydra restart builds that depended on the result of a failed build upon restart?
<samueldr> I don't think it restarts any dependent
<samueldr> and it's something I had a quick thought the other day
<samueldr> dependent?
<samueldr> anyways, whatever the right name is
<samueldr> it would be nice if steps depending on something were marked stale once that something's state changed
<samueldr> so you could say "restart all stale jobs for eval"
<samueldr> without needing to restart all failed jobs
<samueldr> thefloweringash: just restarted
<thefloweringash> thanks!
<samueldr> because right now the state is confusing
<thefloweringash> that stale tracking sounds sensible to me
<samueldr> let's say foobar depends on libjpeg-turbo
<samueldr> and it now works
<samueldr> foobar will still be failed
<samueldr> you follow the link to a failed build
<samueldr> and bam, it's now a successful build!
<thefloweringash> that's super confusing
<thefloweringash> recovering from a dependency failure in something critical also seems to come down to the "restart all failed" hammer you mentioned
<thefloweringash> or waiting for the next stdenv bump :-)
<samueldr> though the restart all also restarts all that won't work any better :)
<samueldr> that's why I think a stale status would be good
<samueldr> though, part of this, all failed builds should be kept tracked
<thefloweringash> Huh. Failed again the same way.
<samueldr> hmm
<samueldr> cpu features?
<samueldr> though I wouldn't think so, with one of the failures
<samueldr> Could not obtain MD5 sum: No such file or directory
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<thefloweringash> sent fix upstream:
<{^_^}> libjpeg-turbo/libjpeg-turbo#425 (by thefloweringash, 10 minutes ago, open): Build: add missing dependency for jpegtran icc test
FRidh has joined #nixos-aarch64
<Valodim> we just wanted to plug a device into the rpi3b, and use it as a hidraw device. doing so we found that the kernel is built without CONFIG_HIDRAW
<Valodim> it's a nixos 20.03 with no specific kernel package configured, which resolves to a 5.4.35
alp has joined #nixos-aarch64
<sphalerite> Valodim: PR welcome ;)
<Valodim> I'm not sure what to PR even? CONFIG_HIDRAW=y is set on five other nixos machines I could look at right now
<Valodim> is there just one stray kernelPackages package that doesn't have it?
<bennofs[m]> bigParallel seems to have worked 👏 And it now builds in 30 minutes it seems 😯
<sphalerite> Valodim: no, it's more a matter of it not being on the aarch64 config
<sphalerite> hang on
<sphalerite> pkgs/os-specific/linux/kernel/common-config.nix
<bennofs[m]> But one thing I do not understand: why is the first step listed as aborted here?
<fps> ok, after installing nixos in a vm and getting my package to build now it's time to try building an image for the rpi4 :)
<fps> wish me luck ;)
<fps> will i need both the module and the overlay?
<fps> ah, the qemu.nix references an overlay.. hmm
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
<fps> hmm, i'm following the guide on the nixos arm wiki. trying to go the binfmt qemu wrapper route.
<thefloweringash> Hm. That wiki looks a little outdated. There’s `boot.bintfmt.emulatedSystems = [ “aarch64-linux” ]` in upstream which does most of the work that the overlay does.
<srk> gchristensen: thanks for the armv7 builds!
<srk> looks way better now
makefu has quit [Quit: WeeChat 2.6]
<srk> thefloweringash: and you too ;)
makefu has joined #nixos-aarch64
<makefu> thefloweringash: sounds great, could you please fix the wiki entry with the new setup? :+1:
alp has quit [Ping timeout: 265 seconds]
<fps> thefloweringash: oh, good to know!
<thefloweringash> makefu, fps: I’ve updated the wiki
<makefu> great, thanks!
<thefloweringash> clever: FYI I’ve removed the link to your qemu directions on the wiki in favor of nixpkgs #61257
<{^_^}> (by matthewbauer, 51 weeks ago, merged): nixos/binfmt: handle emulatedSystems
alp has joined #nixos-aarch64
<Valodim> ah, indeed the default kernel config for arm64 doesn't include hidraw, while x86_64 does
<Valodim> the warning on top of common-config.nix sounds scary :)
<Valodim> CONFIG_HIDRAW has been enabled by default in x86_64 for 12 years though
<gchristensen> oh yeah I've had to turn that on myself
evils has quit [Ping timeout: 265 seconds]
evils has joined #nixos-aarch64
<Valodim> kernel docs say "when in doubt, say Y"
<clever> thefloweringash: i still need to get around to testing that
alp has quit [Quit: Leaving]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
rsa has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Quit: Leaving]
<fps> thefloweringash: cool..
<srk> error: stack overflow (possible infinite recursion)
<srk> oO
<srk> oh, nvm
<srk> playing with cross-compiling, something pulling copying path '/nix/store/lri4ga36rs450iwvvbcvsihjdcjfwzzr-firefox-60.9.0esr.source.tar.xz' from ''...
<srk> /o\
<thefloweringash> I bet it's spidermonkey
<thefloweringash> I think I saw spidermonkey 60 and spidermonkey 68 both scroll buy in recent times
<thefloweringash> scroll by*, when building a system for mobile-nixos
<srk> I see, what's pulling that?
<srk> polkit..
<thefloweringash> didn't stop long enough to find out :-)
<srk> of course
<srk> polkit is js based nowadays
<thefloweringash> why such an old codebase? at least spidermonkey 68 should correspond to firefox esr
<srk> pkgs/development/libraries/polkit/default.nix: [ expat pam spidermonkey_60 ]
<thefloweringash> firefox don't make it easy to find their esr release schedule. is 60 still supported? I must be searching with the wrong terms
<fps> hmm, so i have an sd-image.nix, i have boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; and nixpkgs.config.allowUnsupportedSystem = true; in my configuration.nix, nixos-rebuild switched the system, and rebooted. i also have { allowUnsupportedSystem = true; } in my ~/.local/nixpkgs/config.nx and now tried nix-build '<nixpkgs/nixos>' -A -I nixos-config=./sd-image.nix.
<fps> i still get that error about these two allowUnsupportedSystem settings.
<fps> i also tried with --argstr system aarch64-linux on the nix-build call. that does more.
<srk> thefloweringash: it does look more resonable with security.polkit.enable = false
<fps> i get loads of error messages about something being unable to allocate memory. are those critical?
<clever> fps: in your sd-image.nix, you must set nixpkgs.system = "aarch64-linux";
<thefloweringash> fps: the `--argstr system aarch64-linux` is required. You said it does more, what’s the failure?
<thefloweringash> ^ or that
<clever> ah, for <nixpkgs/nixos>' may also support --argstr system
<fps> thefloweringash: it hasn't failed yet. i just wondered about the gazillion error messages
<fps> clever: ah ok. the nix exp for the sd-image imports <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-aarch64.nix>. wouldn't that be a natural place for that?
<clever> fps: kinda, but you could build that for armv7l instead if you wanted
<fps> hmm, ok..
<clever> oh, i notice the deprecated `arm_control=0x200` in the config.txt of sd-image-aarch64.nix
<thefloweringash> I wouldn’t expect a spam of error messages. If nothing breaks I guess it’s ok. What’s the test of the message? Is it from figuring out what to build or when building a package?
<fps> i don't have the scrollback for the start of the spam, but this is the tail end of it:
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fps> btw: thanks for your work! i just reinstalled nixos yesterday and getting up to speed with building an image this quickly is quite amazing :)
<srk> now my only question is regarding dt overlays is whether to expose compileDTS derivation (.dts -> .dtbo) from pkgs as bennofs[m] suggested (provided I give it a better name)
<srk> is..
<fps> *reinstalled after a hiatus of a couple of years after checking nixos out initially
<srk> fps: \o/ cool
<srk> fps: what's the reason for binfmt? cross failing for you?
<thefloweringash> I don't know what to make of those error messages, but they make me a bit suspicious
<thefloweringash> it looks like it succeeded though, shrug
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<fps> srk: i'm not sure. i'm just following the wiki on "nixos on arm" ;)
<fps> i'm trying to build an aarch64 image for the rpi4. and i'm just chugging along semi blindly
<clever> 2020-04-29 13:31:28< clever> 2020-01-22 13:53:12< clever> Tenkawa: `nix-build '<nixpkgs/nixos/release.nix>' -A sd_image_raspberrypi4.aarch64-linux` for an rpi4 i believe
<clever> fps: from my notes, on how to make an rpi4 image
<fps> clever: yeah, i also plan on installing some custom software on it, setup a user, etc.. basically ready to plug into a rpi4 as a guitar effects appliance ;)
<clever> ah, nice
<fps> clever: my nixos system is x86_64 though in a virtual box. so i follow the wiki's advice on the binfmt wrapper
<fps> hmm, after a long lasting last step i got a 641 meg image out of the process..
<fps> i guess i need to bunzip2 it and slap it on an sdcard and see what gives..
<srk> you can easily define your own setup for building pi images according to that repo
<srk> I've add configs/cross_armv7 for cross compiling as well, currently running
<srk> (repo still requires few pending nixpkgs PRs but those parts can be disabled easily)
<fps> srk: hmm, interesting
<srk> hah
<srk> utils-2.31.1/bin/armv7l-unknown-linux-gnueabihf-ld: ../lib/.libs/ undefined reference to `rpl_malloc'
<srk> libgpiod won't cross :D
<srk> found a possible fix..
<srk> now I'm starting to wonder what would be a good home for stuff like raspberrypi specific modules and device tree overlays for mainline
<Valodim> sphalerite: as requested :)
<{^_^}> #86598 (by Valodim, 57 seconds ago, open): linux: CONFIG_HIDRAW=y
<Valodim> gchristensen: would also appreciate a look ^ , since you enabled this before for yourself
<Valodim> haha. 2fast4me
<Valodim> (actually I should probably leave a comment on why that's needed, given it's on by default for x86)
<Valodim> (done)
FRidh has quit [Quit: Konversation terminated!]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
alp has quit [Quit: Leaving]
samrose_ has quit [Quit: Konversation terminated!]
samrose has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pbb has quit [Quit: - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64