<sphalerite>
THFKA4: `nix-store -q --graph $(nix-instantiate '<nixpkgs/nixos>' -A system)` can probably help you find what's pulling in java
<sphalerite>
err nvm me, the trace is already showing where I guess
ryantrinkle has quit [Ping timeout: 248 seconds]
<sphalerite>
THFKA4: it seems that epubcheck, a java tool which asciidoctor seems to optionally depend on, was recently packaged in nixpkgs
<sphalerite>
THFKA4: you can probably get it working again by removing epubcheck from asciidoctor's dependencies, or just setting it to null in an overlay, or similar
<THFKA4>
that makes sense, thanks sphalerite
<THFKA4>
thing is...SHOULD it depend on jdk upstream
<THFKA4>
or maybe be hidden behind an option
<sphalerite>
java on nixpkgs on ARM is just generally in a bit of a sad state currently
<THFKA4>
i'm more concerned about transitive closure sizes in general, especially on tiny ARM boards
<THFKA4>
i switched from guix where everything is built with every flag set, they didn't even HAVE options
<sphalerite>
well on 32-bit arm where there's no binary cache you're generally doomed to needing lots of space anyway
<sphalerite>
lots of space and lots of build time
<THFKA4>
nixos has options that can toggle build dependencies, right? how many people really care about jdk for their docs
<sphalerite>
well, actually a lot of nixos's docs needs java stuff to build
<sphalerite>
can't remember exactly what it was, but you need some java tools for building the manual iirc
<THFKA4>
that's a bit crazy. if you look at the dependency chain in my paste, java AND ruby end up getting draged in from udisks
<THFKA4>
(if i'm interpreting it right)
<THFKA4>
dragged in*
ryantrinkle has joined #nixos-aarch64
<THFKA4>
if i make a patch separating out the docs as another output, do you think it'd get accepted? or is this something that's not really a focus
<sphalerite>
yeah. That's wonderfully avoidable with a binary cache, where you can limit it to the runtime deps, but not when you don't have that :/
<sphalerite>
Splitting the outputs won't help in this case, because you still need asciidoctor to _build_ the docs
<sphalerite>
I mean, maybe disabling udisks is an acceptable workaround in your case :)
<sphalerite>
It's one of my go-to changes for making more minimal systems as well
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<THFKA4>
i'm definitely still learning, but i feel that nix is expressive enough to allow us to depend on the base udisk without the docs
zupo has joined #nixos-aarch64
<sphalerite>
Not depending on the docs and not building the docs are different things
<sphalerite>
Splitting outputs allows the former, but doesn't help with the latter
<THFKA4>
okay, so is it possible to gate native build inputs behind options?
<sphalerite>
sure
<THFKA4>
and that would get rid of docs even during build, right?
<samueldr>
though it'd need to be implemented per build system / per package
<sphalerite>
Yes
<sphalerite>
^
<samueldr>
unless during my sleep all projects unified under a single build system with unified options :)
<sphalerite>
Are you sure you need udisks? Because disabling it would be a much simpler and less painful way to get around your problem.
<sphalerite>
samueldr: well, you _could_ set e.g. asciidoctor = null; in an overlay, thus preventing anything from depending on it. But that's likely to break some builds as well.
<samueldr>
yeah
<samueldr>
wondering though if it could be "stubbed enough"
<samueldr>
imagine if dependencies only use it as a binary (not as a library)
<sphalerite>
you mean like asciidoctor = pkgs.writeScriptBin "asciidoctor" "#!${coreutils}/bin/true"; ?
<sphalerite>
:D
<samueldr>
though it's still only one of the myriad tools :)
<samueldr>
something like that
<sphalerite>
hehe.
<samueldr>
assuming the build system doesn't want the output
<sphalerite>
hehehehe.
<sphalerite>
MUAHAHAHAHA
<samueldr>
if it fails on missing output it'd need to be a bit more intelligent
<THFKA4>
i'm more interested in learning nix than getting this build fixed haha. i understand that i can override anything i want locally
<sphalerite>
samueldr: yeah nah.
<samueldr>
sphalerite: though, the idea is on the table to maybe bootstrap hard stuff like java...
<sphalerite>
THFKA4: then you're probably best off playing around on x86_64 or aarch64.
<samueldr>
java is likely "the" big blocker for aarch64 soon, since it kinda blocks chromium, kodi and other big hitters
<THFKA4>
yeah i have nixos on the main box already, this is one of many many SBCs i have that have been collecting dust until now
<THFKA4>
the experience with a binary cache is definitely miles ahead of building everything on a tiny board
<sphalerite>
hmm, how does debian do it, I wonder…
<sphalerite>
(inb4 no bootstrap)
<samueldr>
likely from the previouses javaes compounding into an initial old bootstrap?
<THFKA4>
i think the binary cache can actually hide these exploding dependency issues. you don't feel any costs when bringing in java for example :3
<sphalerite>
exactly
<sphalerite>
in this case, you don't even bring in java
<sphalerite>
because it's only a build-time transitive dependency
<THFKA4>
it'll just get GCed after the build right
<sphalerite>
no, you don't even download it in the first place (unless you're patching something that needs epubcheck at build time)
<THFKA4>
oh really? so it only becomes a problem because it gets evaluated by default then?
<THFKA4>
because it's in the same .nix file as something that i DO need?
<THFKA4>
anyway, i'll keep looking. thanks for the help guys.
<sphalerite>
well, it gets evaluated in all the cases
<THFKA4>
use flags when
<sphalerite>
but you only _need_ java if something depends on it, like epubcheck
<sphalerite>
and you only _need_ epubcheck if something depends on it, like asciidoctor
<sphalerite>
and you only _need_ asciidoctor if something depends on it, which libndctl does, but only at build time
<sphalerite>
and if you can get libndctl from the binary cache, then you don't need to build it, so you don't need asciidoctor, epubcheck and java
<THFKA4>
i see. and if i add a bunch of use flags, the gentoo way, then the binary cache becomes much less useful
<sphalerite>
THFKA4: we don't have use flags because the common use case prefers _not_ rebuilding the world over the extra customisability
<sphalerite>
exactly
<sphalerite>
we could have something like use flags, but then everyone's rebuilding the world and we've lost one of the advantages over gentoo :p
<sphalerite>
some people do prefer that, and do customise everything (thinking of oxij building everything without pulseaudio for instance), but the more common case seems to be people who like having a binary cache
<sphalerite>
THFKA4: disabling udisks may also get you the massive benefit of not having gtk in your system closure as well, just on the side ;)
<THFKA4>
yeah that'd be great, considering it's headless
<THFKA4>
i don't know, i can definitely see how well everything works on x86 and how it falls apart on armv7
<THFKA4>
i would love to explore trimming some bloat by default
<THFKA4>
would ease the load on the build farm too
<samueldr>
one of the main difference is the amount of development work being done on x86 which doesn't translate directly to arm platforms
<samueldr>
as java is bootstrapped in nixpkgs for x86_64, any use of java is transparent
<samueldr>
while on aarch64, the same thing ends up failing due to it needing java
<sphalerite>
THFKA4: wouldn't really ease the load, since everything's getting built on x86_64 one way or the other :)
<samueldr>
(likely the same for armv7)
<sphalerite>
worse for armv7, since you often have to build a bunch more stuff to even find out ;)
<thefloweringash>
So I'm digging in to why 4.4 and 4.9 kernels don't build on nixos-unstable. Current theory: d180cb98503d2dc1e51d8c14b4a567e1ed3e996d made -march always part of cflags. These kernels set -mcpu=generic+crc to enable crc instructions. -mcpu is weaker than -march, so the -mcpu is ignored, and it builds without crc instruction support, which fails.
<samueldr>
scratch the last part, this isn't the bit that does it :/