<> changed the topic of #nixos-aarch64 to: gchristensen has changed topic for #nixos-aarch64 to: "Get access to the NixOS Community aarch64 build box: https://github.com/nix-community/aarch64-build-box ... todo: https://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-jobs"
<andi-> started the upgrade, went to the cinema, came back... trashed :D
<samueldr> I haven't looked at the serial output yet, only hdmi, which stopped at "Starting kernel..."
<samueldr> (how did you get that specific log file?)
<andi-> samueldr: FTDI connected to the serial output of the pi
<andi-> (gnu) screen attached to the ttyUSBX, Ctrl-A ":logfile /tmp/foo.log"
<andi-> once your are done set ":log off"
<samueldr> ah, thanks, hadn't thought that screen can log
<samueldr> will be much better than trying to copy stuff as it's scrolling by
<andi-> :D
<andi-> yes..
<andi-> especially if you have a terminal that doesn't have scrollback (like I do... using `st`)
<Dezgeg> any chance of boosting the kernel loglevel up?
<andi-> will do that in the morning.. almost 4am.. gonna figure out how to remotely power-cycle that thingy as well...
* samueldr his fetching the raspi3
* gchristensen waits anxiously for a thing to show off
<gchristensen> it seems a major problem with the netboot image is the unionfs it uses consumes a lot of CPU
<samueldr> waiting on the SD card to finish doing stuff to then rebuild and switch to (hopefully?) non-working kernel
<clever> gchristensen: does the store have to be writable?
<gchristensen> yes
<Dezgeg> well we should switch to the in-kernel unionfs and not unionfs-fuse as the first step
<gchristensen> otherwise it isn't much use as a remote builder :)
<clever> ah yeah
<samueldr> hmmm, ah, I think I know, I was under the (obviously wrong) assumption the default kernel was 4.14 (latest) and not 4.9
<gchristensen> I picked a bad test case for my demo right before bed...
<samueldr> 4.9 has no trouble booting...
<gchristensen> ok well so I'm way over time for tonight, because I forgot qemu takes for-freaking-ever to build
<gchristensen> but sometime in the next while grahamcofborg will be posting build results for aarch64-linux here: https://github.com/NixOS/nixpkgs/pull/32389#pullrequestreview-83386503
<samueldr> that is literally where my log ends: https://gist.github.com/samueldr/14a58850150b9db504e758cd9a2fb76c
<samueldr> that is, unless loglevel=7 being appended while there is a loglevel=4 earlier causes issue
<samueldr> doesn't look like it was an issue, with boot.consoleLogLevel, at 7, still doesn't start
<samueldr> so, my results are different than andi-'s
<samueldr> looking at store hash, same kernel, different initrd
<samueldr> I'll have my kit out already for tomorrow evening if there's anything I can test
<andi-> Dezgeg: ^ thats with level 8
<andi-> some googling brought me to: https://lkml.org/lkml/2017/11/29/230
<andi-> will backport that patch and try again...
vcunat has joined joined #nixos-aarch64
<andi-> building a kernel is already much more fun ;-)
<andi-> it's booting again o/
<gchristensen> andi-: if your eval fails here https://github.com/NixOS/nixpkgs/pull/32595 I'll fix it, I'm testing a new thing.
<andi-> kk
<andi-> gchristensen: btw. you should also eval xen_4_8 there not just xen ;-) If you want to make sure it doesn't break stuff
<andi-> ahh I see thats what you are trying with just `eval`?
<grahamc> Eval doesn’t actually check packages just in the PR but all of nixpkgs to make sure the whole thing can evaluate. I’m adding an 8th check: that metadata is correct. It has been like 3 weeks coming dh
<grahamc> :)
<grahamc> But it has a chance of breaking PRs because of those changes in the last 3 weeks.
<andi-> I contacted the upstream OP-TEE developer with logs etc.. and the request to submit it to the stable queue..
<andi-> that should hopefully get in with the next release then...
<gchristensen> nice
<andi-> packaging openjdk requires an alreayd compiled (open)jdk... well this will be "fun" of sorts. The current openjdk build depends on some obscure binary packages that are downloaded from dropbox.com..
<gchristensen> heh ...
<sphalerite> Yeah I ran into that when I started trying to get openjdk on armv7
<sphalerite> Asked shlevy about it because he made those binaries at one point but didn't hear back
<sphalerite> I also didn't pursue it any further
<andi-> I have the fear that I might need to cross-compile a jdk at first and then use the result as a (permanent) input for nix builds
<gchristensen> that seems to be the case
<sphalerite> Maybe you can also use another distro's jdk for it?
<gchristensen> it'd be really nice to have a documented way to remake them, and then host them on something.nixos.org :)
<Dezgeg> you could bootstrap from the oracle jdk
<andi-> yes, that would be possible... will work on that later tonight
<Dezgeg> but yeah, the first thing that's needed is an expression to build the bootstrap tarballs
<andi-> yep
<andi-> there is already an expression but that currently depends on pkgs.openjdk... modifying that should be easy
<Dezgeg> oh, there is?
<andi-> make-bootstrap.nix
<andi-> in the openjdk folder
<andi-> mhm, in retrospec using an sd-card larger than 8GB would have been a good idea :D
<sphalerite> haha yes
<sphalerite> I'd say 32GB is a reasonable minimum for building everything from source
<sphalerite> leaves a bit of wiggle room but you do still have to think about it and remember to gc when you've done big stuff
<andi-> yeah... alreayd had to clean a few profiles to be able to install a new kernel..
<sphalerite> on my chromebook I've been usign a 32GB USB stick for the rootfs and pushing everything to a binary cache on a 1TB external HDD
<sphalerite> so I can gc without having to worry about how long it'll take to build that stuff again
vcunat has quit [(Quit: Leaving.)]
<grw> andi-: are you trying to compile kodi?
<andi-> grw: well that was the first high level thing that came to mind
<andi-> currently reading into the openjdk/icedtea crap..
<grw> only thing i hit needing jre.. you can use oracle jdk as Dezgeg says
<andi-> well I managed to hand-craft such an input
<andi-> fails at some random place..
<andi-> yet I am unhappy
<andi-> seems like one can also use gcj for the bootstrapping
<andi-> which can be build with a C compiler
<andi-> that woudl remove the requirement for a blob from $dropbox
<grw> iirc java is only needed for a trivial part of kodi build
<grw> easier to skip it :)
<andi-> well I am trying to educate myself in that area and getting rid of a few magically hand-crafted blobs in nixpkgs is probably worth a try
<grw> me too- i've found most "high level" blobs are there for a reason though
<andi-> that might very well be ;-)
<andi-> PI just OOMed.. probably gonna go this route (https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04688.html) for memory intensive tasks.. might be a bit slower but at least memory isn't an issue on x86