<clever>
if you just want something built, dont use develop, use build!
<clever>
clone the same repo on the linux end
<clever>
ssh into linux, and run the same command
<clever>
so it should only be ran on a linux system
<clever>
`nix develop` gives you a shell suitable for running the linux->linux compiler
<clever>
siraben: why are you trying to develop with the wrong arch?
<clever>
yeah, flakes tend to import <nixpkgs> repeatedly, for each arch for you, and then make a set of each arch
<clever>
which <nixpkgs> is
<clever>
siraben: --arg system only works if your pointing it to a function in the form of { system, ... }:
<clever>
Ericson2314: how much do you know about multi-lib?
<clever>
s1341: ive not done any android-native stuff, simplest answer is to just go static
<clever>
thats what git is for
<clever>
i need it to start on a given rev, but still allow updating the rev like normal
<clever>
immae: i think i'll just keep editing flake.lock by hand, thats worked so far
<clever>
immae: what if i'm converting a project from niv to flake, and nixpkgs master is broken, so i want flake.lock to start on a specific rev, and then figure it out later?
<clever>
immae: is there a way to set the nixpkgs input to a given rev?
<clever>
siraben: if everything else has already been downloaded, then rebuilding wont involve any query to the cache
<clever>
siraben: if you add `allowSubstitutes = false;` to a given derivation, nix will not search for that one thing on the caches
<clever>
and also...
<clever>
`--option substituters ''` could also be used
<clever>
when you -Lfoo, it wont search foo/<suffix>, i think
<clever>
Mic92: my guess, is that ld and gcc search something like /usr/lib/<suffix> automatically, and all of the buildInputs and -L magic on nix is the problem
<clever>
because multilib builds both hard and soft at the same time, and then picks the right one at link time
<clever>
Mic92: the complex bit, is that the multi-lib enable flag, conflicts with --with-float=soft
<clever>
gcc already has some internal logic to pick the right one, and to do things right, ld needs to respect the same logic
<clever>
Mic92: the complex bit, is that where the linker should search, depends on the -march and --float? options
<clever>
Mic92: the gcc is already able to produce both arm and thumb code, its just a matter of pre-compiled bits (newlib and crtbegin) being pre-built in both forms
<clever>
Mic92: i'm not sure how i would tell gcc to be thumb-only by default...
<clever>
prior to my changes, gcc was linking an arm32 crtbegin.o and an arm32 newlib, so it failed hard on startup
<clever>
Mic92: its a thumb-only soft-float cpu, and it uses the newlib(c) that the host toolchain provides
<clever>
Mic92: compiling for the new RP2040 that the raspberry pi team released
<clever>
Mic92: gcc itself is able to find things like the right crtbegin.o, but ld isnt dynamically changing its own search path
<clever>
Mic92: so i have to manually force the right variant of newlib, and thats not very flexible...
<clever>
but the ld wrappers in nixpkgs arent searching the right dirs for newlib
<clever>
Mic92: ive patched the arm-embedded cross stuff, to create a multilib build (thumb+arm, soft+hard), and newlib automatically went multilib as well
<clever>
Mic92: do you know much about gcc and multilib?
<clever>
if most lines have 3, but 2 lines have 6, then the resulting string will have 3 spaces on those 2 lines
<clever>
or more
<clever>
just that every line needs the same indent
<clever>
so the nix code can be multi-line, and nicely indented, but the string itself wont leak that extra indent
<clever>
if all lines in the string have 4 spaces of indent, nix removes 4 spaces from every line
<clever>
the only special thing, is the ''strings''
<clever>
indent means nothing to the syntax, its the same as a space or newline
<clever>
correct
<clever>
for nearly everything else, it just needs at least 1 (or sometimes even none) whitespace (space or newline)
<clever>
one is a side-effect of allowing http://example.com without quotes, the other is a function
<clever>
> x: y
<clever>
> x:y
<clever>
only in a few places
<clever>
nope, {} are always a set of key/value pairs
<clever>
`with set; []` is an expression that returns a list
<clever>
itai: throw some parens on it, (with pkgs; [foo]) ++ (with bar; [baz])
<clever>
this is a list, where foo will try to be found in pkgs first
<clever>
with pkgs; [ foo ]
<clever>
thats not a valid set
<clever>
a set must contain key=value; pairs
<clever>
(but the value could be a set, a list, or any other type)
<clever>
that expression returns a single value
<clever>
itai: the `with pkgs;` must be followed by exactly one expression, and it only effects the parsing of that expr
<clever>
rollback would make that much simpler
<clever>
but even if you can mount it fine, knowing what you need to undo isnt easy
<clever>
immae: the most common is just when the boot firmware/kernel on the sd card is broken, so you need to put the rootfs into another machine to repair it
<clever>
immae: in the case of the rpi, there are many levels of bricking
<clever>
immae: its usually a case of some critical app getting into a bad state, and there is no undo button in apt
<clever>
immae: its mostly the rollback option allowing you to undo almost anything
<clever>
bifunc2: i think the same thing, every time i see an rpi user trying to fix the machine after apt-get upgrade bricked it
<clever>
ambroisie: it should all be in the manual
<clever>
then filter, set->list, and map functions can further manipulate it
<clever>
ambroisie: builtins.readDir returns a set listing all files and dirs in a given dir
2021-01-30
<clever>
esotericnonsense: nix-env also has priority over most other sources
<clever>
esotericnonsense: simple answer, never install busybox, it overrides a lot of things, generally causing problems
<clever>
nly: you cant mix -A and -p, they do different things
<clever>
nly: nix-build '<nixpkgs>' -A linux.src -o linux.tar.xz, if you havent changed the default in configuration.nix
<clever>
pie_: ive not tried doing any proxy stuff with it
<clever>
SomeoneSerge: that shell script basically just downloads a tarball of a /nix/store that already has nix installed
<clever>
wnklmnn: its in the mime-type setup of the http server, which maps extensions to mime types
2021-01-29
<clever>
colemickens: nix-store -r /nix/store/foo --add-root result --indirect, is how i do things
<clever>
bqv: it might have been grub1, it was back around 2005, but most of those commands still work the same way, and the overall design
<clever>
and there is almost no way to detect that from within linux
<clever>
systemd-boot is just a giant sack of magic, you can permanently override the default boot option by just hitting the wrong key at the boot menu
<clever>
so i know all of the internals of grub
<clever>
back when i was getting into linux, i also read man and info pages, cover to cover
<clever>
bqv: i prefer grub, its far more configurable and debuggable
<clever>
i have used boot in the past, to install nixos over another distro
<clever>
the whole point of `result/bin/switch-to-configuration boot`, is to make whatever is in result the default
<clever>
systemd-boot is being impure by looking at profiles, and then randomly deciding "uh, no, ima do something different"
<clever>
id say grub is more pure, its doing exactly what it was told to do, make whatever is in result the default
<clever>
and just doesnt do as it was told :P
<clever>
if the one you gave it cant be found, it silently uses the latest
<clever>
for systemd-boot, it searches all generations of the system profile, and flags the one you gave it as default
<clever>
for grub, it just blindly says "ok, sure" and makes whatever storepath you said, the default
<clever>
but grub doesnt care, so you can just `result/bin/switch-to-configuration boot` and skip the generation entirely
<clever>
`switch-to-configuration boot` with systemd, will only work if that build is in the system profile (which nixos-rebuild does, i believe)
<clever>
there are also some quirks/bugs there
<clever>
chreekat[m]: sandbox wont let you follow absolute links that escape /nix/store
<clever>
yep
<clever>
the naming style for the .nar.xz varies depending on what uploads it, but the .narinfo contains the relative path
<clever>
ocharles: /nix/store/hffygyhn30m35g1142zj14bzqp6fgv11-ghc-8.10.1 would be stored as hffygyhn30m35g1142zj14bzqp6fgv11.narinfo
<clever>
the .narinfo will contain the relative path of the .nar.xz
<clever>
.narinfo and .nar.xz i believe
<clever>
it just shoves the entire 1.5gig into a single std::string, and then goes at it
<clever>
it took a while to figure out what it was even doing, lol
<clever>
ive investigated it before, because hydra was pinning one thread to 100% cpu, and making ZERO syscalls
<clever>
ocharles: but if you open `top`, switch to thread view (H), and then toggle `c` mode, you can see part of the storepath in the name of the thread
<clever>
ocharles: i believe the compression is done before uploading, and it doesnt report progress
<clever>
aforemny: so you can just `nix-build '<nixpkgs>' -A tests.cross.gcc.hello`
<clever>
mpickering: basically, its using some fun magic to be able to merge the .options and .config that every module returns, and then pass the merged result back into every module
<clever>
mpickering: the module system is doing some fun fixed-point stuff, where you are receiving your own return value as an argument
<clever>
mpickering: yep
<clever>
mpickering: misc/nixpkgs.nix will apply those overlays as it loads its neighboring nixpkgs copy
<clever>
mpickering: nixpkgs.overlays
<clever>
mpickering: by default, it gets nixpkgs from ../../.. (the root of a nixpkgs, that the nixos/default.nix came from)
<clever>
mpickering: _module.args lets any module add args that get passed to every module