<samueldr>
I'm hoping the new generation of ARM servers will somehow free up those AArch32 capable servers in the coming year or two *
<samueldr>
(before armv7l devices become too irrelevant, though imho they never will be, if we stand for reusing working hardware instead of sending them into trash heaps)
<samueldr>
or new aarch32-capable µarch
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-aarch64
alex_giusi_tiri has left #nixos-aarch64 [#nixos-aarch64]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
worldofpeace has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
alex_giusi_tiri has joined #nixos-aarch64
alex_giusi_tiri has left #nixos-aarch64 [#nixos-aarch64]
worldofpeace has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
<exarkun1>
afaik ec2 won't let me import any kind of arm images.
<exarkun1>
:(
<samrose>
can anyone see any reason hydra can't run on a decent-resourced ARM server?
<samueldr>
samrose: asking theorerically or having issues?
<samueldr>
and the whole hydra frontend or just a builder?
<samueldr>
(I may have the terms wrong)
<samueldr>
and ARM AArch64 or AArch32?
<samrose>
samueldr: I am asking both theoretically, but I am also about to pull the trigger on a configuration.nix and see if it "works" :-D
<samueldr>
you tell us then
<samrose>
just thought I'd ask in case someone went down the road before, but it looks like not, and I will tell you for sure
<samrose>
I was looking at the whole hydra enchilada
<samueldr>
I wouldn't be surprised if it works, since after all "it's just software", but as there's a bunch of software which doesn't built for aarch64, so here it's a gamble on: is there anything in there that won't build?
<samueldr>
since it's mostly perl and native, I'd wager on: it'll work
<samueldr>
unless you cross-compile, where I'd wager on: it can work, but maybe needs fixes
<samrose>
yeah, I couldn't see anything in here that stood out
<samrose>
this will be used just to build aarch64
<samrose>
and I have a hydra running on x86 already for that build
<samrose>
for the records, the first try said something about
<samrose>
Package ‘ghc-8.4.4’ in /nix/store/003naalxz3bpipgh6qix127i3q08y6hw-nixos-18.09.1829.0396345b794/nixos/pkgs/development/compilers/ghc/8.4.4.nix:238 is not supported on ‘aarch64-unknown-linux-gnu’, refusing to evaluate.
<samrose>
but for now I just tried nixpkgs.config.allowUnsupportedSystem = true;
<samrose>
I actually don't know too much about the Glasgow Haskell Compiler, but it was on my list to learn Haskell and it's ecology eventually
<samueldr>
samrose: I presume you're on 18.09 then?
<samrose>
yes, I updated the server to 18.09
<samueldr>
IIRC unstable has switched that on, though it hasn't always been able to succesfully build
<samueldr>
(switched that on -> allowed ghc to build)
<samrose>
good to know, I guess if it comes down to it I can retry if I roll this machine back to 18.03
<samrose>
so far it the Haskell stuff is building
alex_giusi_tiri has joined #nixos-aarch64
<alex_giusi_tiri>
would have anyone managed to compile and install ceph on aarch64? a few tests fail for cherrypy, a dependency
<alex_giusi_tiri>
more specifically, on rpi3b
<samrose>
alex_giusi_tiri: what are the tests that fail for cherrypy?
<alex_giusi_tiri>
I didn't save any log of the output, and I since closed the terminal, but I am trying now again, and saving it, but one that I remember is anti-something xfail, i belive; I think about 7 total. this happens with version 18.09.1853 which I updated to last night; i had more errors (I belive about half of total tests) with the just previously released version, which i can't quite rember the precise last version number (18
<alex_giusi_tiri>
also tried with version 18.03, but then there was a different error. (I changed between versions by changing the nix-channel)
<alex_giusi_tiri>
oh, antistampede was the first one
<alex_giusi_tiri>
and, towards the end, the rest occur
<alex_giusi_tiri>
I think one was autoreload
<alex_giusi_tiri>
and I think another one was about memory being released
<alex_giusi_tiri>
18.09.1834 is the other version, and I think I was trying to install with version 18.09.1829. with these versions, more tests fail than 18.09.1853
<alex_giusi_tiri>
[...] I was trying to install with version 18.09.1829 *also*
<alex_giusi_tiri>
aarch64 is still experimental/testing/beta, right?
<alex_giusi_tiri>
the 18.03 version that i tried is 18.03.133389.b551f89e256
<samrose>
alex_giusi_tiri: yes aarch64 is still experimental even if you are otherwise using a stable version of nixos
<samrose>
many times you will have not much choice but to dig into the source code of deps, and see if maybe there is something there that assumes non aarch64 system, etc
<samrose>
alex_giusi_tiri: there apparently is an arm64 version of ceph if that makes a difference?
<alex_giusi_tiri>
how could I try it? i just used `nix-env -iA nixos.ceph`
<samrose>
alex_giusi_tiri: I am not aware of an existing nixpkgs implementation of ceph for arm64
<samrose>
I was just speculating that maybe the issues you are seeing are around this architecture difference
<samrose>
I am looking for clues on how one might build ceph from source for arm64
<samrose>
alex_giusi_tiri: so you could create a nix expression that builds this from source with the proper arguments, but an existing package doesn't work
<alex_giusi_tiri>
but, are arm64 and aarch64 different?
<samrose>
doesn't exist I mean
<samrose>
alex_giusi_tiri: I am not a ceph expert but I believe with regard to these ceph make files and source, that aarch64 and arm64 are the same
<alex_giusi_tiri>
I thought that they would be, but I just liked to confirm
<samrose>
there may be better ways, but sometimes when I am experimenting with this kind of thing, I fork https://github.com/NixOS/nixpkgs create a branch, and just hack on these packages and track my changes in my branch, and build the ceph package using my fork repo as the input
<alex_giusi_tiri>
but I don't remember that the whole installation process reaches building ceph itself, it stops after cherrypy fails
<samrose>
alex_giusi_tiri: also if you check in with ceph community, they could probably show you how to build this from source on aarch64, which would make it easier to translate into nixos
<samrose>
yes, it seems somehow that the ubuntu and debian packages make it past that step just scanning through various repos on this
<samrose>
so chances are it could be solved in nixos, but I wouldn't know without digging in
<alex_giusi_tiri>
no problem, don't worry too much
<samrose>
sure, just thought I'd share what I was digging up
<alex_giusi_tiri>
I also looked into cross compiling only cherrypy on x86_64, but there it skipped all the tests, and later on, it tried running an executable that was for aarch64, failing, and it then the installation failed
<alex_giusi_tiri>
don't get me wrong! please keep sharing with us! it's just that I am unprepared to do all this at the moment, because I haven't studied the nix language yet, so I'm just looking, as we say, 'like a cat at a calendar', because I don't really know how to interpret it all :-) (and then modify it more! (what does that red button do? :P)) :-) but for sure it would be helpful, and it has been!
<alex_giusi_tiri>
I meant that it's not an emergency or something alike
<alex_giusi_tiri>
but if you want to tackle it, I wouldn't mind!
<alex_giusi_tiri>
thank you! btw
<exarkun1>
samueldr: Hm. Would having an armv7l Nix system where "nix build" runs and a faster aarch32-capable aarch64 system configured as a remote builder help with the problems that arise from trying to do native armv7l builds on aarch64? Or do you still have exactly the same problems?
<alex_giusi_tiri>
and if I would modify locally the nixpkgs repository, how could I share it? do I just open a pull request? i never did that; it's scary! what if I do something wrong?
<alex_giusi_tiri>
would there be any other alternative?
<exarkun1>
alex_giusi_tiri: if you want it in upstream, open a PR, yes. If you did something wrong, hopefully someone will notice and tell you about it and you'll learn something wonderful.
<exarkun1>
alex_giusi_tiri: If you just want to share but you don't necessarily think what you've done makes sense to have upstream, pushing it anywhere public and then sharing the location will do the job.
<exarkun1>
AFAIK buildPythonPackages is broken for cross-compilation
<exarkun1>
I have hacked a bunch of packages to work by replacing buildPythonPackages with buildPackages.python.pkgs.buildPythonPackages
<exarkun1>
As far as I can tell this works but I'm pretty sure it is not the nicest solution.
<exarkun1>
And I haven't tried fixing cherrypy this way. But it looks pretty much like many other packages I have successfully hacked thusly.
<alex_giusi_tiri>
thanks
<samrose>
all good alex_giusi_tiri are you compiling this on aarch64 ?
<samrose>
(on aarch64 hardware)
<alex_giusi_tiri>
yes
<alex_giusi_tiri>
here is the summary it reached just a few minutes ago: "== 12 failed, 276 passed, 6 skipped, 4 xfailed, 1 xpassed in 3417.63 seconds ==="
<samrose>
to answer question above, if you open a PR, and you do something wrong, a reviewer or the system will make you aware, and you can fix it, and resubmit! :)
<samrose>
a good way to get ready for a PR is to create a fork and a branch, do your thing, pull and merge latest upstream and then initiate a PR from your branch to the target you want to get merged with