jabranham has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
<gchristensen> why does the sd card image use ext4 over iso9660 ?
<gchristensen> or make-disk-image
<gchristensen> hmmM! make-disk-image makes an ext4...
<samueldr> because you install over the existing filesystem!
<samueldr> generation 1 is the installer
<samueldr> generation 2 is your installed system
<samueldr> when your system only boots from SD, it's easier to get started
<samueldr> the sd-image even resizes the root filesystem to fill the sd card!
<samueldr> in reality, I found that quite ingenious when fist installing on aarch64
<gchristensen> that is cool
<gchristensen> but can make-disk-image not produce the same result?
<samueldr> no idea, I'd have to look at those parts
<gchristensen> I'm a bit curious about why the sd card's ext4 disk is 2.2g in size but the graphical iso is less than 1g iirc
<samueldr> I do not think it's being built to fit
<samueldr> yeah, I was thinking about something else
<samueldr> (+20M slack)
<samueldr> no idea what's making it swell that much
<clever> gchristensen: this gives me a thought about packet.net
<gchristensen> oh?
<clever> gchristensen: what if you make-disk-image on some central cache, and then just dd it to the mdadm array
<gchristensen> hm
<clever> but it will still need a nixos-rebuild to finalize the config
<clever> due to the ip/rootpw/sshkey stuff
<gchristensen> util-linux-2.32.1
<gchristensen> util-linux-2.32.1
<gchristensen> stdenv-linux
<gchristensen> stdenv-linux
<gchristensen> some stuff is in the closure multiple times, with different store paths
<clever> nix-store --query --deriver on each
<clever> then nix-diff the 2 .drv's
<clever> there is a build of util-linux that lacks some interactive flags, which means `cal` cant show colors
<clever> and sometimes both wind up in the closure
<clever> gchristensen: yeah, i see the interactive and non util-linux, a musl busybox (initrd?) and i'm not sure why there are 2 boehms
<gchristensen> I'll why-depends it in a minute
<gchristensen> suspicious :) grahamc@Morbo> nix why-depends /nix/store/sq3xk8jr5jzx6bdy7bycfl5achgr3ria-nixos-sd-image-18.09beta-94788.gfedcba-aarch64-linux.img /nix/store/f3xa9wc8g7qms30q7bqzfmwwppngkknp-busybox-1.29.3
<gchristensen> /nix/store/sq3xk8jr5jzx6bdy7bycfl5achgr3ria-nixos-sd-image-18.09beta-94788.gfedcba-aarch64-linux.img
<gchristensen> ╚═══sd-image/nixos-sd-image-18.09beta-94788.gfedcba-aarch64-linux.img: …zb6g-findutils-4.6.0./nix/store/f3xa9wc8g7qms30q7bqzfmwwppngkknp-busybox-1.29.3.sha256:15hnhd7ib…
<gchristensen> => /nix/store/f3xa9wc8g7qms30q7bqzfmwwppngkknp-busybox-1.29.3
<clever> thats a bug in nix involving disk images
<clever> the path of every storepath in the image is inside the disk image itself
<clever> so the disk image depends on the entire closure directly
<gchristensen> the .sha256 prt?
<clever> if you tell why-depends to show every single dep, it will give more details
<clever> i think your seeing the substring of the disk image, that contains the nix db
<clever> why-depends --all should help
<gchristensen> aahhhh
<clever> it also helps to not use why-depends on the image itself, but the top-level path that was put into the image
<clever> but there can sometimes be a list for top-level
<clever> line 5 is part of the bootloader config, and i think 7 is /etc/extra-dependencies
<gchristensen> yeah
<clever> yep
<clever> line 23, is the default /bin/sh for nix sandboxes, a busybox sh
<clever> and then various things that depended on nix
<gchristensen> not sure why it uses a different busybox, but that doesn't really explain _so_ much more disk space does it?
<clever> and they are likely different builds of busybox, a fully featured one for the initrd (so nixos-rebuild is less likely to need network, busybox is only a build-time dep)
<clever> and the 2nd busybox is sh only
<clever> check the closure size on each busybox
<gchristensen> right
<clever> oh, and my du trick comes in handy here
<clever> [clever@system76:~]$ du -hc --max=0 $(nix-store -qR /nix/store/f3xa9wc8g7qms30q7bqzfmwwppngkknp-busybox-1.29.3) | sort -h
<clever> 826K/nix/store/f3xa9wc8g7qms30q7bqzfmwwppngkknp-busybox-1.29.3
<clever> 13M/nix/store/17b1xcgg2l2hyxh39inx6k83c3fzkxfd-glibc-2.27
<clever> 14Mtotal
<clever> gchristensen: this shows the closure, sorted by size of each dep
<gchristensen> nice
<clever> gchristensen: try that against /nix/store/zmac781py39jzmp3i664655rrw23aplc-nixos-system-nixos-18.09beta-94788.gfedcba
<clever> [clever@system76:~]$ du -hc --max=0 $(nix-store -qR /run/current-system) | sort -h
<clever> 169M/nix/store/5qmib3dl86iprk6b9d80pzff2ylp803s-mono-5.8.0.108
<clever> 173M/nix/store/61y9gr6kpyabis4ri902mjdbbdmgnh00-libreoffice-6.0.6.2
<clever> 175M/nix/store/sx8h2w1hfgbs542fhr3a3pmk1yrzb1kx-mono-5.8.0.108
<clever> 177M/nix/store/868x4i1qb9cs2zkyxsyc4snfajvm1icb-firmware-linux-nonfree-2018-10-17
<clever> 3.2Gtotal
<clever> gchristensen: yeah, those busybox's are so small that they arent worth fixing
<clever> also, your linux firmware is bigger then mine...
<clever> [clever@system76:~]$ du -hc --max=0 $(nix-store -qR /run/current-system) --apparent-size | sort -h
<clever> zfs compression!
<clever> my firmware is 411mb with apparent-size
<gchristensen> nice
<clever> by default, du counts real disk usage
<clever> rounding up for cluster size, and possibly being lower due to compression
<clever> --apparent-size counts the bytes in each file
<clever> so all FS based overhead (and savings) is out of the picture
<clever> 443M/nix/store/61y9gr6kpyabis4ri902mjdbbdmgnh00-libreoffice-6.0.6.2
<clever> why is that in my closure...
<gchristensen> hah!
<gchristensen> wtf why is ghc in my closure
<clever> because its in my systemPackages
<clever> but also, libreoffice compressed from 443mb to 173mb
<gchristensen> ... because its in my systemPackages
<clever> heh
<samueldr> [...]
<clever> why do i depend on 2 mono's?
<clever> 64 and 32bit
<clever> steam
orivej has quit [Ping timeout: 268 seconds]
makefu has quit [Ping timeout: 245 seconds]
FRidh has joined #nixos-aarch64
<sphalerite> clever: -hcd0 is shorter ;)
<Dezgeg> sd-image is uncompressed while the ISOs use squashfs
makefu has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<hark> Does someone know what is the correct url of the dezgeg arm channel, this http://nixos-arm.dezgeg.me/channel/ redirects to the wrong place
<hark> s/channel/cache
<samueldr> hark: this looks like it redirects to the right place
<samueldr> hark: what are you seeing, what did you expect?
<hark> gives me a bunch of html
<samueldr> yeah, looks like a 404
<samueldr> any reasons to think it shouldn't? there are a couple reasons to think it would
<samueldr> mainly, if the thing wasn't built yet, or wouldn't be built by the cache
<hark> i got multiple times a timeout, so i checked, then assumed i was looking at some different page
<samueldr> I see, though right now AFAIK the cache might be a bit stale (I could be wrong) if it never builds without building the sd-image files it could be as old as from september 13th
<samueldr> though looking at the timestamps "Last modified" on the listing it may have been updated on october 13th
<samueldr> Dezgeg: any issues with your builds? simply taking a nap?
<sphalerite> I'm guessing it's probably just the NFS bork again
<hark> samueldr: not sure it that thing is supposed to be in that cache, it was one of the ones that timed out
<samueldr> at least, it isn't on the server, and isn't on my mirror (so probably wasn't on the server ever)
<bennofs[m]> what is the output size limit on hydra? how small do we need the sd-image to get so it builds?
<bennofs[m]> ok hydra default appears to be `2ULL << 30` so I guess 2 GiB?
<gchristensen> bennofs[m]++
<{^_^}> bennofs[m]'s karma got increased to 3
<sphalerite> We at mayflower would quite like to get ourselves an ARM build server (hardware), does anyone have any idea where to find something like that?
<sphalerite> I've been able to find the GIGABYTE thunderx2 servers, but is there maybe something more similar to the elusive hi1616 chipset or anything?
<gchristensen> sphalerite: why buy over rent?
<clever> sphalerite: packet.net has aarch64, but its currently sold-out
<sphalerite> gchristensen: would be interested in hearing what you hear from libre.computer since you asked about getting something like that
<sphalerite> clever: yeah no we want to buy something
<gchristensen> but why? :)
<gchristensen> sphalerite: and, aarch64? armv7 capabale? send me more details (core count, ram, quantity, timeline) I can put you in touch with someone
<gchristensen> also, think hard about why you want a physical box :)
<sphalerite> gchristensen: we want warranty-voiding powers and to have it on the LAN :)
* gchristensen shrugs
<gchristensen> sure, if you want me to put you in touch with someone, send me some details (^)and I'll reach out to some folks :)
orivej has quit [Ping timeout: 268 seconds]
<samueldr> the hisilicon hardware on packet is from huawei
<samueldr> if it helps you finding such a vendor
<samueldr> sphalerite: the 60 core device is not from libre.computer, from a partner of theirs, firefly (just in case)
<sphalerite> samueldr: is it listed anywhere?
<gchristensen> no
<samueldr> I didn't keep notes of what I found :/
<gchristensen> it isn't for sale
<samueldr> Huawei Taishan 2280*
<gchristensen> "They also showed me a really cool 60-core fanless ARM64 cluster board (private development; not yet released)…"
<samueldr> turns out it was much less work finding it back than it was at first :)
<sphalerite> oooooooh that's a nice page
<gchristensen> looking at these vendor sites you'd think they don't actually want you to buy anything
<sphalerite> yes x)
<makefu> gchristensen: that what i was wondering as well, no "pricing" page is always positively suspicious to me
<gchristensen> (and the reality is, they don't want _you_ to buy any _thing_ -- they want YouInc to buy 1,000)
<makefu> of course!
<gchristensen> and that is all Enterprise Sales and introductions
<sphalerite> that does make sense
<makefu> it was founded by packet.net so everything goes full circle again
<gchristensen> WorksOnARM was, but they don't sell anything
<gchristensen> I meant the vendor pages -- who they list below that
<gchristensen> WorksOnARM is an ecosystem investment, Packet.net can sell more ARM systems if OSS projects run on ARM
<gchristensen> and, note, Packet didn't invest tht much :) https://www.worksonarm.com/about/
<makefu> yep i saw that :)
FRidh has quit [Quit: Konversation terminated!]
<makefu> maybe the firefly people can make some connections via the worksonarm ecosystem. especially if they can provide the `60 core` aarch64 device they supposently talked about
<gchristensen> yeah maybe the can
<gchristensen> I'll ask if they'd like to be put in touch
orivej has joined #nixos-aarch64
<samueldr> it all depends if 60 cores is something like 10 SBCs joined together in a network :/
<makefu> that would be nice, i have the feeling that they are quite desperate in establishing connections and ties into the european market
<makefu> samueldr: haha yeah
<gchristensen> heh remember the parallela?
<clever> nope
<gchristensen> :o
<makefu> gchristensen: unfortunately in parallela they didn't use general purpose cpus, you needed an extra library to run
<gchristensen> yeah :)
<makefu> it was more like an arm board with a (not that powerful) gpu on it
<gchristensen> I remember
* gchristensen looks at his parallelas
<makefu> you must have a giant stash of random arm boards at home
* makefu is a bit jealous
<gchristensen> actually just 2x parallelas and 1x odroid-c2
<clever> ive got 3 or 4 rpi's of various models, and a banana pi r1
<gchristensen> never even got a rpi
* samueldr won't list
<samueldr> it's not a problem, I can stop whenever I want
orivej has quit [Ping timeout: 240 seconds]
sigtrm has quit [Ping timeout: 264 seconds]
sigtrm has joined #nixos-aarch64