lopsided98 has quit [Remote host closed the connection]
shad has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
Piece_Maker has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 252 seconds]
Piece_Maker is now known as Acou_Bass
Acou_Bass has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
Guillaum has joined #nixos-aarch64
<Guillaum>
I am right that native aarch64 package have a different checksum than crosscompiled ones? Said otherwise, I cannot use the binary cache when I'm cross compiling?
<samueldr>
right, they don't have the same inputs
<Guillaum>
can I cheat by creating my own derivation which depends on the native derivation and just copy / paste result inside it?
<gchristensen>
no
<sphalerite>
I think it should be theoretically possible to mix cross and native stuff, but I'm not sure anyone's done it and it'll probably be a pain
<Guillaum>
I solved the issue by using the native aarch64 package. That's ugly: (import (fetchTarball channel:nixpkgs-unstable) {system = "aarch64-linux";}).hdf5-cpp
<Guillaum>
it should not build in theory, but because it hit the cache first, it works.
<sphalerite>
Guillaum: yep! Another way to make it work is by adding an aarch64 remote builder
<sphalerite>
Guillaum: although maybe `import pkgs.path` is nicer if you've already got a pkgs in scope since you'll use the same nixpkgs
<sphalerite>
the issue with the whole approach is that it'll use up a bunch more space since you're getting two copies of all the relevant dependencies
<sphalerite>
and potentially compatibility issues, not sure about that
<Guillaum>
sphalerite: I'm not sure about the remote builder, because there is still a hash difference between the "native" and the "cross" output.
<sphalerite>
since you've got two distinct glibcs
<Guillaum>
sphalerite: I did not think about the glibcs. There should be "the same", but built with a different process. I hope for the best.
<sphalerite>
yep
<sphalerite>
Guillaum: but the remote builder should work just the same way as the binary cache
<Guillaum>
sphalerite: ha, yes. In case what I'm looking for is not available in the binary cache, I can create a remote builder, indeed.
<Guillaum>
Initially I thought about creating a local "qemu" builder.
<sphalerite>
that is possible but won't be fun
<sphalerite>
there's also qemu-user which avoids needing to emulate the whole kernel and stuff, but it's still a far cry, both in performance and reliability, from a real machine
<Guillaum>
I discovered qemu-user yesterday, that's awesome.
<sphalerite>
the performance is awful and there are unimplemented/incorrectly implemented (I think) instructions
<samueldr>
I think there's only nixpkgs and no nixos jobset for unstable aarch64
<gchristensen>
nixos/release-combined.nix in input nixpkgs
<gchristensen>
it is looking at the nixos release.nix
<samueldr>
(nixos:unstable-aarch64 was last evaluated in april)
<gchristensen>
oh I see , unstable
<samueldr>
I kinda can feel my way around in hydra now
s33se has joined #nixos-aarch64
<timokau[m]>
So it seems like limited-hassle aarch64 support is not quite there yet? The image build is failing and the binary channel is 6 months old?
s33se has quit [Client Quit]
<gchristensen>
it works great for 18.09, but I admit I've never done an install without already having an aarch64 nixos builder available
<timokau[m]>
So 18.09 is up-to-date? Shouldn't unstable-aarch64 be at least as up-to-date then?
<samueldr>
unstable has the full package set built
<samueldr>
but it's built using nixpkgs instead of nixos
<gchristensen>
there is no aarch64 channel
<samueldr>
^
<gchristensen>
there is no aarch64-*specific* channel
<timokau[m]>
I'm confused
<timokau[m]>
How do builds on 18.09 work then?
<samueldr>
gchristensen: your explanation is probably going to be more precise than mine :)
<gchristensen>
I can't explain :( I'm on a phone call
<samueldr>
right, correct me later :)
<samueldr>
18.03 and 18.09 have a specific channel for aarch64 so they don't stop the main channel from updating
<samueldr>
so if the aarch64 jobset fails, the main channel won't stay behind
<timokau[m]>
Makes sense. But the same is not the case for -unstable?
<samueldr>
for nixpkgs unstable, AFAIUI, the aarch64 builds are part of the main jobset
<samueldr>
but *nixpkgs* and not nixos
<samueldr>
though the defails I'm not entirely sure for nixpkgs-unstable + aarch64
<samueldr>
details*
s33se has joined #nixos-aarch64
<timokau[m]>
And how does nixos:unstable-aarch64 fit into this?
<samueldr>
not entirely sure
s33se has left #nixos-aarch64 [#nixos-aarch64]
<samueldr>
only thing I know is that it last evaluated in april
<timokau[m]>
Maybe just for tests before it was integrated in the main jobset
<samueldr>
though I think it wasn't for nix_os_-unstable :/
s33se has joined #nixos-aarch64
<timokau[m]>
So basically channels are reasonably up-to-date, 18.09 works, the core packages work. Only thing missing is the image for 18.09
<timokau[m]>
I still haven't quite understood why we differentiate between nixos and nixpkgs channels, but I guess thats another matter
<samueldr>
but, as far as *using* nixos on aarch64, it works fine, but I'm not using the aarch specific channels, but checking out a repo to a known working revision
<samueldr>
so I can't say how much the aarch64 channel updates
<timokau[m]>
Alright
<samueldr>
but other than things that *didn't build*, I don't have to build stuff
s33se has quit [Client Quit]
s33se has joined #nixos-aarch64
<timokau[m]>
I'm thinking about replacing my archlinux rpi2 "homeserver" with a aarch64 nixos one
<timokau[m]>
samueldr: You're using a rpi?
<samueldr>
rpi3, pine A64-LTS
<samueldr>
I have on-ice an underpowered orange pi aarch64 board for a project
<samueldr>
and I'm waiting for an RK3399 device to dogfood aarch64 as a daily driver
<samueldr>
(waiting as in: it's ordered, needs to ship)
<timokau[m]>
For some reason the odroid c2 and the pine are both roughly twice as expensive on german amazon than they are on amazon.com :/ I'd love to finally have a board with proper gigabit ethernet.
<timokau[m]>
The rk3399 looks impressive
<samueldr>
:( I understand the feeling of non-USD buying
<samueldr>
$CAD
<timokau[m]>
Can't you just let them ship it in from the US? Shouldn't be too expensive from canada right?
<samueldr>
it all depends on the product
<samueldr>
and who sells
<timokau[m]>
Buying the odroid from a US retailer and shipping it to germany actually seems a bit cheaper (because that makes perfect economic sense)
<samueldr>
last time I did so, from ameridroid, I had to pay a bunch on customs fees :/
<samueldr>
like more than expected, not entirely sure why
<timokau[m]>
Well thats actually the retailer I was looking at, so there are hidden fees?
<samueldr>
and if it's shipped via ups or dhl, they LOVE charging me convenience fees
<samueldr>
timokau[m]: maybe not, depends on your customs
<timokau[m]>
Who's charging you those fees?
<samueldr>
the government
<samueldr>
and then the shippers *may* charge you more for handling it
<timokau[m]>
But you see that before ordering right?
<samueldr>
probably not
<samueldr>
but it all depends on how germany works
<samueldr>
I'm speaking as a canadian
<timokau[m]>
So they charge you at delivery?
<samueldr>
I had a *warranty* 0$ cost SSD shipped by crucial... UPS charged me 25$ to pay 8$ customs fees (25+8$)
<samueldr>
yes
<samueldr>
the 8$ was because of the declared value of the item, the full price
<timokau[m]>
Huh, thats stupid
<timokau[m]>
I should fly to the US again to buy some stuff
<samueldr>
DHL did the same thing, ordered something, DHL handled the customs declaration and payments, so they charged me ~30$ for the service, and I had to pay IIRC 10$ for the customs fees :(
<samueldr>
customs fees I'm fine with, paying for the service by the shipper, no
<samueldr>
it's not a "customs fee", misspoke: it's a tax
<samueldr>
technically, you (probably) have to pay it even if you fly in/out
<timokau[m]>
Even customs fee isn't fine if it isn't disclosed upfront
<timokau[m]>
That should be part of the shipping costs
<timokau[m]>
Same with tax
<samueldr>
customs != shipping; and it's impossible to know for sure by another country's citizen how customs will act
<timokau[m]>
At least for germany there's some threshold (I think $1000 or $2000 or something) that you don't have to re-tax when flying in
<samueldr>
yeah, same in most countries, a treshold
<timokau[m]>
Then they should suck up those costs and adjust their shipping costs to cover them I think
<gchristensen>
when Emily and I went to EU she wanted to declare the value of our laptops :')
<timokau[m]>
Probably getting a bit too off-topic^^
<gchristensen>
ehh
<timokau[m]>
gchristensen: Did you move or go on vacation?
<gchristensen>
work trip
<timokau[m]>
The government sure would love if we re-paid taxes every time we cross a border :D
<gchristensen>
:D
<samueldr>
so, the TLDR: I don't mind paying duties (found the right word I think!), it's the law, and is an issue for local competitiveness; but I hate how some shipping businesses handle it :(
<timokau[m]>
Yeah paying it makes sense but paying it on delivery does not
<samueldr>
unless you ask of everyone selling in the world to ring up the country and ask upfront the costs, it's going to be *hard* as long as we have countries
<samueldr>
because they'd also have to send the money to said country
<timokau[m]>
Why is it hard? I'm sure UPS knows exactly how much it costs them to deliver from US to canada
<timokau[m]>
Don't they have to do that either way?
<samueldr>
not the same issue
<samueldr>
ups has an operating cost of weight+volume from point A to point B
<samueldr>
the customs care about the value of the things passing by
<samueldr>
(when extremely simplified)
<samueldr>
ups *could* ask everyone for the money upfront, but then they'd look more expensive I guess? and they'd still need to charge for the service
<timokau[m]>
Yes, but now UPS pays them and then asks you for the costs. Instead they could ask you (or the retailer) for the costs up-front and then pay them.
<timokau[m]>
Yes they'd look more expensive but it would still be the customer-friendly thing to do
<samueldr>
for that I would agree, but it's way more work for the shipping company since the duties *will* change depending on arcane rules, so asking upfront becomes hard
<samueldr>
e.g. textiles wouldn't cost the same as clothes even if by weight and monetary value they were identical
<timokau[m]>
Good point.
<sphalerite>
timokau[m]: not sure about Germany since I only just moved here, but in the UK rather than the thing I'd ordered I got a letter asking me to pay the dut, then it would be released and delivered to me
<timokau[m]>
Still, I think tracking that kind of thing is their job (not the customers) and with their scale they could probably easily do it
<timokau[m]>
sphalerite: Sounds a bit like blackmail to me :D
<samueldr>
Canada Post / Postes Canada have a debit/credit terminal on hand to get paid on postal deliveries :D
<timokau[m]>
(And Willkommen in Deutschland :))
<samueldr>
or you can do it at the post office if you somehow don't have money and can't pay at the door
<sphalerite>
wait… I can't call UK 0800 numbers with my UK SIM when I'm in Germany? Aaaaaargh
<samueldr>
but those scrooges at UPS and DHL will ask for money at the door, without letting you see the receipt (so you don't know what you're paying for) and if you don't they mark as refused :(
<sphalerite>
timokau[m]: thank you :D
<timokau[m]>
samueldr: So your choice is to pay whatever amount they ask for or have them keep the delivery you already paid for. Delightful.
<samueldr>
timokau[m]: not keep, send back!
<timokau[m]>
Here I am hoping we have a sensible law against his in germany but too lazy to actually look it up
<timokau[m]>
samueldr: Which makes perfect economic sense again, now they can pay the customs fee twice!
<samueldr>
while CPC (canadian postal services) do the right thing and just send it to the post office, like you weren't there :/
<samueldr>
(and anyways shows you upfront it's *just* the duty)
s33se has quit [Quit: s33se]
jtojnar has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
jtojnar has quit [Ping timeout: 252 seconds]
<grw>
samueldr: wrt testing sbcs- you can transfer a kernel and initrd and boot it all over usb on some socs too
<samueldr>
oh sure
<samueldr>
I was thinking more about a holistic test, with stage-2 of the installer sd-image tested
<grw>
hm i see
<grw>
maybe you can test installing to nbd disk or something. it works well over usb
<samueldr>
the end-user wouldn't use it through nbd :)
<samueldr>
(though realistically the end-users wouldn't boot usb either)
<samueldr>
though yeah, a first more approchable test farm could be entirely netboot based
<samueldr>
as long as they already have their u-boot available
<grw>
true, its a bit easier if youre working with something stateless though
<samueldr>
(for which an upgrade image could be made)