zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
jackdk_ has joined #nixos-aarch64
<nschoe>
Hi everyone, quick question in case you can solve it easily (I've asked on #nixos and was given links to creatig overlays, which I will be looking at). I'd like to cross-compile my (haskell) package for my rPi 3. I've confirmed I can build it with nix-build (for my laptop).
<nschoe>
Following this guide: https://nixos.wiki/wiki/Cheatsheet I have tried this command: `nix-build release1.nix --arg crossSystem '(import <nixpkgs> {}).lib.systems.examples.aarch64-multiplatform' -A hub` ('hub' is the name of my executable in my release1.nix file).
<jackdk_>
there's an easier to engage cross-compile machinery I think
<nschoe>
The issue is that this command succeeds very fast, I do get a `result` symlink, which *works* when I try to run it in on my laptop. And which gives me exeuctable forma terror when I use nix copy on my rPi.
<nschoe>
So it seems to me that it actually doesn't cross compile it at all ;/
<efraim>
bennofs[m]: author of the aarch64 guix article here (i lurk here), icedtea-1 doesn't support aarch64 so I'm hoping to (eventually) bootstrap it from armhf, which unfortunately wouldn't work on a ThunderX machine
<nschoe>
jackdk_, really? I'm interested to know how?
<nschoe>
jackdk_, Yeah I also know of pkgsCross, but those are for "standard" packages, like hello, emacs, etc. My package however, is source files in my workspace. It's not in the pkgsCross. So how should I go about it?
<bennofs[m]>
What's in your release.nix?
<jackdk_>
then what I _think_ you want to do is package it into an overlay, so you can do `(import nixpkgs { overlays = [ (import ./path/to/your/overlay.nix) ]; }).pkgsCross.yourPackage` or something like that
<nschoe>
bennofs[m], this is just overriding some packages to disable doctest.
<nschoe>
jackdk_, yeah, okay so I'm back to overlays. This was mentionned to me in #nixos yesterday. I haven't had time to chec on that, but I will definitely do this, then
<nschoe>
Thanks then.
<bennofs[m]>
nschoe: so the reason this doesn't do anything I'd that your release.nix has no crossSystem argument. You can pass the crossSystem directly in your release.nix, where you import nixpkgs I think
orivej has quit [Ping timeout: 245 seconds]
<nschoe>
bennofs[m], Hum... I see. I was precily beginning to look at this "crossSystem" thing.
<nschoe>
But then I looked as nixpkgs/pkgs/applications/misc/hello/default.nix and there's no "crossSystem" either, yet it cross-compiled okay. How's so?
<nschoe>
Is there _another_ derivation for hello somewhere?
<bennofs[m]>
nschoe: the crossSystem argument needs to be passed to the "nixpkgs packages set" when it is created. When you do something like nix-build '<nixpkgs>' --arg crossSystem ... -A hello, then crossSystem is handled by '<nixpkgs>' (see https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/default.nix#L25)
<bennofs[m]>
so when you call nixpkgs yourself, you can set the cross system like this: `import <nixpkgs> { inherit config; crossSystem = ... }` to get a package set for cross compiling
<bennofs[m]>
you could even add it as argument to your release1.nix next to "compiler" (default to `null`) and then just pass it on by using `inherit crossSystem` at the nixpkgs import
<nschoe>
bennofs[m], oh! Okay.
<nschoe>
Let me give it a try, thanks a lot.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jackdk_ has quit [Remote host closed the connection]
<nschoe>
bennofs[m], I've changed it like this: https://gist.github.com/nschoe/390a2e01a2e54fd78df8a37be22935d9 (tried to make it default to `localSystem` but it could not find the variable. I think I would have needed to import nixpkgs first). It's building now. Taking much more time, so I guess it's actually doing something.
<bennofs[m]>
yes that looks good! null should be the local system default (right now, cross compiling for the local system is not exactly the same as not cross compiling at all - so null as default is better)
<nschoe>
All right, thanks for this.
<nschoe>
(How com ecross compiling for the local system is not the same as not cross compiling?)
<nschoe>
(Yeah I confirm it: laptop is getting hot, fans is screaming, and it's taking for-ever. I think this is actually cross compiling "correctly". Now let's hope it finished and succeeds before the heat-death of the Universe :D)
<bennofs[m]>
nschoe: don't know the exact differences, but https://github.com/NixOS/nixpkgs/issues/21471 is an issue about using the cross compilation infra in all cases (even where build = host)
<nschoe>
What's the deal with "gcc no found" (line 26) and then the issue with `mv` not finding a file. Is there any clue in here as to what I can do?
zupo has joined #nixos-aarch64
v0|d`` has quit [Ping timeout: 250 seconds]
zupo has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
{`-`} has joined #nixos-aarch64
<bennofs[m]>
nschoe: looks like gdb doesn't cross compile :/
<bennofs[m]>
another question though would be why your package depends on gdb ...
orivej has joined #nixos-aarch64
disasm has quit [Ping timeout: 268 seconds]
disasm has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
tilpner has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<samrose>
samueldr: were you able to find the difference in networking on defconfig between bpim64 and sopine?
<samueldr>
didn't take a look
<samrose>
seeking advice: if I have a sumber of aarch64 machines deployed remotely, are there feasible approaches to updating u-boot builds on those machines using nixos/autoupgrade capacity?
<samrose>
*capability
<samrose>
sumber/number
<samueldr>
I wouldn't think so since there's no support to even do the initial install
<samueldr>
well, nothing nixos-specific
<samrose>
like maybe nix is capable of dd copying new file to installed image if that is not insance to do
<samrose>
insane rather :)
<samueldr>
nix itself can't
<samrose>
nix can run dd I suppose
<samueldr>
it won't have access to the device (hopefully) :)
<samueldr>
but nixos has ways, you could look at how bootloader installation is done
<samrose>
hmm yes
<samrose>
nixos, I guess I should have been more specific sorry
<samrose>
samueldr: do you mean the way nixos-install handles bootloader installation?
<samueldr>
also nixos-rebuild --install-bootloader
<samrose>
samueldr: sorry for distraction I will check it out
<samrose>
gchristensen: good to know thank you
<samueldr>
(and it's also because I don't *know*, I'd look at the same code to provide guidance)
<samrose>
I will end up having to solve this problem, so if it seems useful for me to PR or document it once I get it working I am happy to do it
<samueldr>
I'm thinking that supporting some way to "install" u-boot on the current boot media might be useful in the end
disasm has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
disasm_ has quit [Read error: Connection reset by peer]
disasm has joined #nixos-aarch64
<tilpner>
I guess you could have an activation script that always writes u-boot? And hope it never fails :/
orivej has quit [Ping timeout: 250 seconds]
disasm has quit [Ping timeout: 250 seconds]
disasm has joined #nixos-aarch64
<sphalerite>
tilpner: aaaaargh no!
<tilpner>
Wow, highlight text is red on pink
* tilpner
edits settings to read message
<sphalerite>
lol
<sphalerite>
but please please please stop recommending activation scripts :(
<sphalerite>
they're bad enough for stuff like setting up state directories, but installing a bootloader in one is just stupid
<samueldr>
I made sure to say: "do as nixos does for bootloaders" :D
<tilpner>
Then why does it install/update grub on every activation here?
<samueldr>
also, part of it, is to **not** willy nilly re-install bootloaders
<samueldr>
it changes the configuration, but does not re-configures itself to eh EFI vars and such
<samueldr>
[citation needed]
<sphalerite>
yeah nixos uses the NIXOS_INSTALL_BOOTLOADER env var for the switch-to-configuration script, which is only set if you're using nixos-install or if you pass --install-bootloader to nixos-rebuild
<tilpner>
Oh, it takes so long I figured it'd something interesting
<tilpner>
*it'd do something
<tilpner>
I guess it can check if the u-boot is different from the installed u-boot?
<tilpner>
That doens't really change anything though
<sphalerite>
tilpner: are you sure it's on every activation? It should only be happening on profile switches (boot and switch, but not test)
<tilpner>
If I only ever switch and boot, that's every activation :)
<tilpner>
(I rarely test. Usually my changes go well, and if not I can just pick a previous generation)
<sphalerite>
no, (nixos-rebuild|switch-to-configuration) boot doesn't do an activation
<sphalerite>
the actual booting does
<samueldr>
tilpner: though (AFAIK) even our grub doesn't get updated if grub updates (I'm checking that right now)
<samueldr>
(so I was wrong, it will reinstall grub on upgrade)
<samueldr>
(which is good)
<tilpner>
I'm not sure at all, I havent't looked into it
<samueldr>
not just upgrade, version change
<tilpner>
All I noticed is that my deploys hang on something that involves grub and updating, a lot
<tilpner>
(For a few seconds, it's not that bad)
<samueldr>
it may be something else that doesn't print
<samueldr>
there's a bunch of silent things going on at once
<samueldr>
and between those there's some verbiage from some steps :/
<tilpner>
I agree that activation scripts are dangerous, but so are services that run as root. So I don't yet see how activation scripts are the devil, and systemd services are good :/
<tilpner>
We've talked about this before, regarding my footgun^W files.nix module
<tilpner>
Yes, that could be too, samueldr
<samueldr>
I think the main issue is how the activation scripts are a monlithic beast, while using services you can rely on systemd for more fine-grained control, instead of re-implementing the logic in shell
<samueldr>
(I may be off)
<tilpner>
While you're all here, any way to have disk encryption on Pine64/Pinebook without going for a fully manual install? (Which wouldn't be bad, but isn't automated)
<sphalerite>
tilpner: the biggest problem is the combination of A) if an activation script fails at boot time, your system doesn't boot, and that B) a buggy activation script can work fine when running nixos-rebuild switch but fail when booting
* samueldr
should merge the PR
<tilpner>
samueldr: I have not. All this does (Asking to understand, not be mean) is flash u-boot to different storage, which means my build doesn't have to dd u-boot to the correct place anymore?
<samueldr>
right
<samueldr>
though if you flash it at $location on either SD or eMMC it will prefer *that* u-boot
<tilpner>
sphalerite: Systemd services have prevented my machine from booting in the past, and I have written services that don't work after a fresh boot, but work when activated into a live system
<sphalerite>
tilpner: how have they prevented your machine from booting?
<tilpner>
sphalerite: I don't mind admitting that activation scripts may need a little bit more care to be safe™, but does that mean they have valid usecases? I don't know. I've used activation scripts because they are immediate. I know when it runs and when it's done
<tilpner>
I can't really say the same for systemd services. They might fail silently in the background, they can run asynchronously (that's the best I can write them), and skimming the output of an activation can give a somewhat okay overview of what's changed
<sphalerite>
tilpner: I don't really care if you use activation scripts tbh, what I care about is that you almost always suggest it for use cases that should be using a oneshot systemd service, typically to people who don't know what the problems with activation scripts are
<sphalerite>
or for use cases where it's completely inappropriate, like above
<tilpner>
That was actually not a serious suggestion, I thought it was clear enough, sorry
<tilpner>
(It's not)
<sphalerite>
ok :)
<sphalerite>
still, the bit about recommending dangerous things to newbies stands
<tilpner>
Yeah, I'll try not to do that. Also see the part where my called my activation-script-based module a footgun
<tilpner>
s/my/I/
<sphalerite>
yeah I saw that :)
<samueldr>
so uh, my X11 session runs in an activation script
<samueldr>
j/k
<sphalerite>
re: synchronous and "noisy" oneshot services, yeah, would be nice if systemd could show info about stuff like that
<tilpner>
I guess all I want is to *know* things are correct ("activated") when an activation finishes
<tilpner>
Maybe there are systemd features that can give me that feeling. I don't know them though
<tilpner>
If the activation fails, okay, I don't mind
<tilpner>
But at least it fails quickly
<tilpner>
And loudly
<tilpner>
Though I did break my boot for a few minutes with a syntax error...
<sphalerite>
um. That last message isn't showing for me.
<tilpner>
Sorry, I forget this side of IRC might not be familiar with it
<tilpner>
It's a message with the same foreground and background color, some terminals show it when you select it, with others you can still select and copy the text
<samueldr>
(my client is configured to strip all fun stuff)
<tilpner>
awww
<sphalerite>
ooooh lol
* gchristensen
checks #nixos to see if it is +c
<samueldr>
it was last time I checked
<sphalerite>
I think it is?
<gchristensen>
#rust every friday has someone pastethis:
<tilpner>
It is, sadly :(
<sphalerite>
yeah didn't you set it during one of hte spambot waves?
<gchristensen>
why is your logger censoring us, man!
<gchristensen>
the man keeping us down
<samueldr>
the logger's stripping the colours
<gchristensen>
(I'm kidding)
<tilpner>
<tilpner>
888b 88 88 ,ad8888ba, ad88888ba
<tilpner>
8888b 88 "" d8"' `"8b d8" "8b
<tilpner>
88 `8b 88 d8' `8b Y8,
<tilpner>
88 `8b 88 88 8b, ,d8 88 88 `Y8aaaaa,
<tilpner>
88 `8b 88 88 `Y8, ,8P' 88 88 `"""""8b,
<tilpner>
88 `8b 88 88 )888( Y8, ,8P `8b
<tilpner>
88 `8888 88 ,d8" "8b, Y8a. .a8P Y8a a8P
<tilpner>
88 `888 88 8P' `Y8 `"Y8888Y"' "Y88888P"
<tilpner>
<tilpner>
<tilpner>
Like that?
<samueldr>
better not make an habit of this
* samueldr
is reminded that this client doesn't show colours
<gchristensen>
perfect, tilpner
<tilpner>
Oh, don't worry, I won't
<makefu>
absolutely fantastic, i have planned an install counter for the NixOS assembly at the 35c3, here is a screenshot http://paste.r/TXHG9FqK/+inline