<samueldr>
we don't have armv6l nor armv7l builds on the cache
<unclechu>
samueldr: aarch64 doesn’t work for rpi 1? sorry, i’m a noob here
<samueldr>
aarch64 is 64 bit ARM, the rasspberry pi up to the 2 used arm 32 bit, either armv6 or armv7
<samueldr>
think of it like x86_64 -> aarch64, i686 -> armv7, i586 -> armv6
<samueldr>
(a bit more nuanced, but that's a way to look at it)
<unclechu>
okay. then if i build my own image, boot it, and see that the partition is not resized to the whole sd card it means it does not work for me?
ryantrinkle has joined #nixos-aarch64
<samueldr>
it's a big hint
<unclechu>
i guess even if i install something like raspbian i couldn’t make Nix work? since there is no binary cached too?
<unclechu>
okay, sd card does not resize
<unclechu>
nix-shell does not work too
<samueldr>
nix could, and most likely would work
<samueldr>
but you wouldn't have a binary cache
<unclechu>
samueldr: i mean how would i install the nix itself
<unclechu>
but i’m starting to think that some of the software i wanted to deal with have probably dropped 32bits support
<unclechu>
so i might get stuck at some point
<unclechu>
or i would try to use older software, i don’t know
<unclechu>
i wanted to use nixos in order to gain reproducibility. to have a config that i can build at any time and have a replicated copy.
<unclechu>
if it goes to manual work it doesn’t make much sense i suppose
<unclechu>
i would try a couple of tricks still but i have more doubt that it would work than i have hope
<unclechu>
but it seems to me now if i had newer raspberry pi i would have a lot more chances
<unclechu>
maybe i should consider to buy a newer one
<DigitalKiwi>
why a rpi1
<unclechu>
DigitalKiwi: because it’s one that i had in my closet, for years
<DigitalKiwi>
i don't think it'll be fun even if you can get it to work since there's not a cache you'll have to build things for days
<DigitalKiwi>
...and that's if it even works :)
<unclechu>
and it turned out i need a pedalboard again, but this time i wanted reproducibility
<unclechu>
DigitalKiwi: yeah, i have the same thoughts. what newer raspberry pi model you would recommend to try then?
<unclechu>
i’ve seen in the docs or somewhere else that rpi4 is not yet supported or something
<samueldr>
the pi3 would be the only "supported" pi board for the time being
<samueldr>
though only supported with mainline linux
<samueldr>
it can work with the vendor-specific ecosystem if desired
<DigitalKiwi>
i've used it on a 3b with a 32gb micro sd card and it wasn't too bad. i wouldn't want to use less than 32gb (i have done it but it's not nice) 4b are nice too i have a few of them but there are more problems on nixos than the 3b i guess
<DigitalKiwi>
fwiw i upgraded my 3b to a 3b+ (the 3b i had now runs grahams lights)
<DigitalKiwi>
gchristensen: i miss them
<unclechu>
say 3B for today is the best choice for nixos. thanks
<samueldr>
hmm, the more I look the less I think it can integrate nicely into NixOS without a major rethink of Mobile NixOS...
<samueldr>
(of the organization thereof)
<DigitalKiwi>
i think you can probably get a 3b+ for about the same or sometimes better price than a 3b and i don't know of any reasons not to and it is a bit better
<unclechu>
by 3B did you mean 3B in general. like 3B+ is okay as well?
<DigitalKiwi>
is nixos on the pi4 bad enough that we shouldn't tell people to use it samueldr
<unclechu>
i don’t know yet how 3B+ is different though
<DigitalKiwi>
like i have it booted right now next to me lol
<samueldr>
until it's well-supported by mainline linux, I wouldn't
<samueldr>
and we (I) don't support the vendor-specific stuff in general, including the raspberry pi
<samueldr>
though it is possible to use the vendor bootloader flow and kernel
<DigitalKiwi>
3b+ has faster ethernet and wifi
<samueldr>
I personally wouldn't recommend any pi devices, but I don't have specific recommendations either
<DigitalKiwi>
and a faster processor
<samueldr>
the raspberry pi foundation has proven times and times again it's not interested into being a good citizen, and just acts like any vendor does
justanotheruser has quit [Ping timeout: 260 seconds]
<DigitalKiwi>
oh and poe
<samueldr>
though they have the advantage of having a huge community around them
<samueldr>
but it also depends on what the user (here unclechu) wants to do
<samueldr>
if it's desired to use "pi shields" or other vendor-ecosystem nonsense like that, then a pi is probably the only solution
<samueldr>
and probably easier if they use the vendor ecosystem stuff (bootloader flow, kernel, etc)
<samueldr>
nothing's black or white here
<DigitalKiwi>
fun (sad)fact: the rpi that runs the nixos logo i made for gchristensen runs raspbian
<samueldr>
was it to integrate with a hardware nonsense?
<DigitalKiwi>
yeah i didn't ever get around to figuring out if/how to get the library i needed to work on nixos
<samueldr>
yeah, probably a multi-pronged problem
<samueldr>
in addition to the libraries, getting the right "device tree" working with the "right" kernel
<unclechu>
samueldr: i’m just familiar only with rpi. in particular, for this case, i need gpio, audio stack (alsa, jack) and the networking in order to make a pedalboard for the guitar
<samueldr>
which, with raspberry pi ecosystem stuff is rarely working with mainline
<unclechu>
detect button presses and expression pedal, and send those signals to my pc over network
<samueldr>
you can go with what you're familiar, and it's not a mistake to use the raspberry pi
<unclechu>
something like this
<samueldr>
but my personal opinion is that they're not as "open source friendly" as they claim
justanotheruser has joined #nixos-aarch64
FireFly has quit [Quit: Goodbye]
FireFly has joined #nixos-aarch64
fooker has quit [Ping timeout: 272 seconds]
fooker has joined #nixos-aarch64
globin has quit [Ping timeout: 260 seconds]
globin has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<sphalerite>
gchristensen: it's not rebooting again >_<
<sphalerite>
and maybe we should move the reboot notifications to PMs or #bottest?
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98_ has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<betaboon>
hello. I'm building against nixos-20.09 but alot of packages (it seems like almost all) for aarch64 are being compiled and not take from cache (eg. `p2vm103ll9rz0arxfbq8wk5307s000qh-openssl-1.1.1g-aarch64-unknown-linux-gnu.drv`). am i doing something wrong or is this to be expected ?
<betaboon>
is it because I'm cross-compiling and the aarch64-builds in cache are built natively therefor the hashes are different ?
alpernebbi has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
cole-h has quit [Ping timeout: 264 seconds]
ryantrinkle has joined #nixos-aarch64
zupo has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<ehmry>
betaboon: correct
<ehmry>
there is no way around this, even if the binaries are identical, there are tests that are skipped for non-native builds
<ehmry>
come to think of it, I don't know what we will do about tests when content addresses builds are ready…
<ehmry>
aka checkPhase
<betaboon>
wasnt there a discussion about "always crosscompile" a while ago?
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<betaboon>
what was the command for crosscompiling for aarch64 using nix-build again? eg for `nix-build '<nixpkgs>' -A hello`
<sphalerite>
betaboon: nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello
<betaboon>
ah. `nix-build '<nixpkgs>' --arg crossSystem '{ system = "aarch64-linux"; }' -A hello
<betaboon>
sphalerite: thanks. is there a difference to what i just wrote ? or does that implicitly do the same ?
<sphalerite>
the result will be the same, but it's not entirely the same thing
<betaboon>
hm I'm trying to debug why autogen fails to crosscompile in my gitlab-ci pipelines even tho it works with just nix-build. fails similar to #106165
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…]
zupo has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
rajivr has quit [Ping timeout: 260 seconds]
rajivr has joined #nixos-aarch64
ashkitten has quit [Ping timeout: 260 seconds]
ashkitten has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
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…]
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<sphalerite>
gchristensen: could you give the reboot script another poke? It doesn't seem to be rebooting the machine, even though it says it is. And I checked that it's the right machine this time :D
<gchristensen>
ping in 20min?
<sphalerite>
ok
<gchristensen>
thanks
<samueldr>
ehmry: I guess checkPhase being skipped in cross isn't an issue with the CAS if we consider the same output
<sphalerite>
gchristensen: ping
<gchristensen>
I don't see any logs w.r.t. the reboots ...
<gchristensen>
either in reboot.py or packet
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<sphalerite>
hm, and it's still not rebooting…
<sphalerite>
at least, nothing's coming up on the serial
<gchristensen>
weird
<gchristensen>
I just issued a manual reboot from the console sphalerite
<gchristensen>
let's see if that does it
<gchristensen>
maybe packet got in to a weird state
<sphalerite>
yep, that's done something
<gchristensen>
reboot 8dec7562-fd58-4493-af8b-4cc5d8db83a8? ok
<sphalerite>
and the script… still doesn't seem to be having an effect?
<sphalerite>
:(
<gchristensen>
yeah it is weird
<gchristensen>
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.packet.net:443
<sphalerite>
gchristensen: I'm onto the final iteration of the bisect! :D
<gchristensen>
:D
zupo has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 272 seconds]
Darkmatter66 has quit [Ping timeout: 260 seconds]
pinage404[m] has quit [Ping timeout: 268 seconds]
pinage404[m] has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
justanotheruser has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 240 seconds]
<sphalerite>
noooooo I thought I was done, but… the option doesn't fix the problem on master!?
<gchristensen>
ohno...
<samueldr>
multiple compounding issues suck
<sphalerite>
false alarm, I seem to have misidentified the option that caused the problems.
<sphalerite>
out of two.
<sphalerite>
so there's still hope!
<sphalerite>
oh no… " If saying YES here breaks your board you should work on fixing your board."
<gchristensen>
haha
<gchristensen>
fuck
<sphalerite>
linux commit 954a03be033c7cef80ddc232e7cbdb17df735663. The security feature can still be disabled via the command line (which is easier as well and doesn't involve kernel rebuilds, nor making the kernel insecure for all platforms just to make c1.large.arm work)
<sphalerite>
but eeeeeeeeh
<patagonicus>
Omg, the Pinephone will get a "PSION5 like keyboard addon". I am so going to buy one. I had/have a PSION 5mx and it's great.
<sphalerite>
I'm testing the cmdline parameter right now
<samueldr>
mostly because it looks like they're doubling down in owning the design for more stuff
<patagonicus>
No newly produced Pinebook Pros until March is a bit disappointing, but I think with the keyboard addon for the Pinephone I'm not even sure I'll even buy a Pinebook.
<samueldr>
which is good because it hopefully means they're not in trouble
<samueldr>
oh, and nutcracker is also a good sign (though an older news)
<samueldr>
it'd be great to have a not-sucky wifi option
<sphalerite>
uname -a ⇒ Linux (none) 5.9.14 #1-NixOS SMP Fri Dec 11 12:22:14 UTC 2020 aarch64 GNU/Linux
<sphalerite>
on the thunderx!
<samueldr>
sphalerite: old
<sphalerite>
with an unmodified kernel!
<sphalerite>
lol
<samueldr>
:)
<sphalerite>
do we have 5.10 in nixpkgs already?
<samueldr>
I don't know
<samueldr>
while it's not ideal that they don't have in-house software development
<samueldr>
we all know how most vendors fare with in-house software development
<sphalerite>
I think I prefer them not having in-house software development? :p
<samueldr>
yeah
<samueldr>
it's passable enough to me that they get the community involved enough with their designs
<samueldr>
because often the community wouldn't be able to scrounge up the means to produce something like a pinephone hardware
<samueldr>
but there they're able to
<sphalerite>
gchristensen: so yeah, pass `arm-smmu.disable_bypass=0` on the commandline and the c1.large.arm will boot. Annoying that this means that a security feature is being disabled, but it does let us get on newer kernels.
<sphalerite>
gchristensen: I'll probably pass this on to equinix, maybe it's something that can be fixed in firmware. I don't know enough of the technical details.
<gchristensen>
oh nice
<gchristensen>
sounds good make sure to get the attention of ed
<sphalerite>
alright, thanks for the tip. Done :)
<samueldr>
neat, there's this one problem where it's doing it in a loop, but right now the mobile nixos stage-1 can kexec into a generation's kernel+initrd
kloenk has quit [Ping timeout: 268 seconds]
kloenk has joined #nixos-aarch64
<samueldr>
one of the good news is that in the VM it seems to be able to do it a bunch of times over without failing
veleiro has quit [Ping timeout: 260 seconds]
* colemickens
hadn't realized the rm2 gives ssh access, apparently specifically because of GPLv3!
<colemickens>
I don't know of many real world end-user products that comply with GPLv3 like that
<samueldr>
they generally try to avoid gplv3 things
<samueldr>
and when they include some, act as if it wasn't a problem
<samueldr>
or say that "their cellphone does not have software"
<gchristensen>
colemickens: afaik most of them do if you send a proper letter
<gchristensen>
or maybe my current client is an outli
<samueldr>
gplv3 specifically
<samueldr>
generally proprietary-flavoured hardware will avoid GPLv3 like plague
<colemickens>
yeah, it's entirely possible and likely that this is the first consumer device I've owned or interacted with that was bold enough to ship/admit/comply with v3
<samueldr>
I'm pretty sure that a platform of TV set-top box made by an american telco (I don't remember if it was verizon) might be using GPLv3 software
<samueldr>
one of our telco uses that platform and IIRC it listed GPLv3 specifically in the licenses
<qyliss>
The weird thing is the RM2 doesn't even have that much GPLv3 software in it
<qyliss>
And the GPLv3 software it does have all has non-GPLv3 alternatives
<qyliss>
So it makes me wonder how much of it is somebody who thought giving access would be cool justifying that by saying they needed to because of bash or something
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I would gather the latter, they must know it doesn't harm them to do so
<samueldr>
AFAIK they don't have any paid services tied to the remarkable
<samueldr>
so no reason to try and stop you from using your device as you see fit