orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
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?
<jackdk_> nschoe: I can never find the thing I'm looking for but https://nixos.wiki/wiki/Cross_Compiling
<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
orivej has joined #nixos-aarch64
<nschoe> bennofs[m], here is my release1.nix: https://gist.github.com/nschoe/390a2e01a2e54fd78df8a37be22935d9
<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)
<{^_^}> #21471 (by Ericson2314, 1 year ago, open): Always cross compile
<nschoe> bennofs[m], thanks
<nschoe> Looks interesting, thanks.
v0|d` has joined #nixos-aarch64
v0|d has quit [Ping timeout: 268 seconds]
v0|d`` has joined #nixos-aarch64
v0|d` has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<nschoe> Hi, it's me again (:/). The cross-compiling finally failed with those last few lines: https://gist.github.com/nschoe/171dbcff106d55ad69d9a2c6056d388f
<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> (I was just looking at all the places this env var was used https://github.com/NixOS/nixpkgs/search?q=NIXOS_INSTALL_BOOTLOADER&unscoped_q=NIXOS_INSTALL_BOOTLOADER )
<samueldr> busy at work, but yeah, that's a good clue to look for and expand your search
<gchristensen> you might want to not use github code search -- it misses things on big repos like hours
<gchristensen> I'm not saying it did miss stuff, but it often does. https://search.nix.gsc.io/?q=NIXOS_INSTALL_BOOTLOADER&i=nope&files=&repos=
disasm_ has joined #nixos-aarch64
<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> right, there's a state file
<samueldr> so something similar should be done
<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)
<samueldr> !!!!!
<samueldr> you remind me
<samueldr> with this, and u-boot's UEFI support, you can build the iso image from (with #51397) and do a "regular" install
<{^_^}> https://github.com/NixOS/nixpkgs/pull/51397 (by samueldr, 2 weeks ago, open): installer: Adds AArch64 UEFI installer support. (Work towards SBBR and EBBR support)
<samueldr> it could also netboot
<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.
<sphalerite> but it's not showing in my weechat.
<samueldr> fun!
<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> _____ ____ ___ ____ _ __ __
<gchristensen> | ___| _ \|_ _| _ \ / \\ \ / /
<gchristensen> | |_ | |_) || || | | |/ _ \\ V /
<gchristensen> | _| | _ < | || |_| / ___ \| |
<gchristensen> |_| |_| \_\___|____/_/ \_\_|
<gchristensen> except in lolcat color
<gchristensen> nix-shell -p lolcat -p figlet --run "echo FRIDAY | figlet | lolcat"
<samueldr> oh, it's a per-client side my setting for stripping colours
<samueldr> it's a dead giveaway here
<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
<samueldr> .r?
<gchristensen> doesn't work for me
<samueldr> makefu: fix yer link :)
<sphalerite> nor for me
<makefu> wupps,
<sphalerite> ugh
<sphalerite> but it doesn't fail in the proper NXDOMAIN way for me, no
<samueldr> better charge your laptop
* sphalerite quietly curses Telekom
<gchristensen> nice
<gchristensen> also please charge
<makefu> my computer starts nagging when my battery is low. i forgot to charge just too often
<makefu> screenshot is from yesterday, i am back at 33%
<sphalerite> makefu: how will you be getting the data?
<sphalerite> also I think we're in the wrong channel :D
<makefu> we have a big-ass button at the assembly which gets pushed
<samueldr> is the button plugged into an SBC?
<gchristensen> awesome
<samueldr> sorry, the ass-button plugged into an SBC?
<tilpner> Make sure to tell us the final count!
<sphalerite> samueldr++
<{^_^}> samueldr's karma got increased to 44
<makefu> big ass-button vs. big-ass button
<makefu> one of the features is that it will write to the irc channel
<makefu> i am not sure yet which channel to spam though
<tilpner> As long as it doesn't spam the whole logo and banner... c.c
<sphalerite> hahaha
<makefu> it will look like this: 35C3 NixOS Installation number *150* just completed. Debian--; NixOS++
<{^_^}> NixOS's karma got increased to 4
<makefu> with a set of different texts
<tilpner> How do you know they switched from debian?
<makefu> guessing
<gchristensen> NixOS++
<{^_^}> NixOS's karma got increased to 5
<makefu> it is actually: choice(otherdistros)
<tilpner> NixOS++
<{^_^}> NixOS's karma got increased to 1
<gchristensen> omg tilpner
<sphalerite> oh no
<makefu> so, it has come to this!
<tilpner> NixOS++
<{^_^}> NixOS's karma got increased to 1
<samueldr> it was fun while it lasted
<samueldr> "fun"
<gchristensen> pack it up, y'all
<gchristensen> it is all over
<makefu> the source code is also already on github, be sure to tell me your ideas what other text could be told https://github.com/krebs/35c3-install-counter/blob/master/curs.py#L108-L132
<makefu> also, i am looking for a biased choice so every text gets told every now and then. random is just a bit too ... random
<tilpner> I like how you didn't include Windows
<makefu> tilpner: we have to be honest here, nobody will switch from Windows to NixOS.
<makefu> (yet)
<sphalerite> and how many 35c3 attendees will be windows users, realistically?
<gchristensen> makefu: how about a self deprecating one: error: infinite recursion encountered,
<makefu> gchristensen: hehe nice, or something about "cannot coerce number to a string"
<gchristensen> haha
<gchristensen> ooh
<gchristensen> how about the error you get putting [ afunction "avalue" ]
<makefu> > "${1}"
<{^_^}> cannot coerce an integer to a string, at (string):214:2