<clever>
Baughn: its trying to create a whole new store in result/madoka/nix/store to act as the source
<clever>
Baughn: skip the --from
<clever>
ambro718: an issue is already open on nixops, and i think Baughn commented on it
<clever>
"oh, your package manager turned off the network"
<clever>
"your package manager is crap, let me do that for you"
<clever>
Myrl-saki: ive seen one package use Setup.hs to pre-download and build a c++ project from source, so the ffi code could link into it
<clever>
Myrl-saki: i think things like native dependencies that cabal doesnt understand
<clever>
Myrl-saki: but a custom Setup.hs could do extra stuff in the configure
<clever>
Myrl-saki: the 2 line default i gave above compiles into a binary that is basically identical to cabal, so you can just `./Setup configure` or `./Setup repl`
<clever>
Myrl-saki: its a wrapper around cabal, that allows a package to extend cabal
<clever>
Myrl-saki: i suspect (but havent confirmed) that the defaultMain is already compiled and will run fast even in runhaskell
<clever>
Myrl-saki: yes, but 99% of the time, Setup.hs is 2 lines: import Distribution.Simple ; main = defaultMain
<clever>
Myrl-saki: compileBuildDriverPhase is what compiles it
<clever>
Myrl-saki: potentially, we can just runhaskell Setup.hs
<clever>
Myrl-saki: ah, one problem ive noticed, nixpkgs wants to compile Setup.hs, and the linking can be rather slow
<clever>
Myrl-saki: for haskell projects, there isnt much in the configure phase
<clever>
Myrl-saki: for autoconf based projects, there is a lot of useless checking of things like the size of an int, which the stdenv could be caching
<clever>
Myrl-saki: i think it depends a lot on the package
<clever>
Myrl-saki: the dependency tree doesnt always allow it to do things in parallel
<clever>
hlolli: as root
<clever>
hlolli: what channel does `nix-channel --list` say your on?
<clever>
hlolli: yeah, that could explain it
<clever>
hlolli: add one of these 5 keys to your configuration.nix
<clever>
monotux: i think theres an after field in the systemd config on nixos, for each service
<clever>
niksnut: main issue i ran into, is that nix doesnt have a way to serialize a set into a .nix file, so i cant generate a manifest.nix, which means `nix-env -i` wont work right
<clever>
niksnut: this generates an arx bundle containing the closure of nix and a basic shell env, run sh on it to install, and then you have a full non-root mount namespace in ~/nix-install along with a script for entering the namespace
<clever>
so when you add/update a channel, it basically just does nix-env -p <foo> -i /path/to/channel
<clever>
behind the scenes, nix-channel will manage a nix-env profile
<clever>
+1
<clever>
makefu: pasted more into it
<clever>
i dont have a wiki acct
<clever>
and it will search within it
<clever>
makefu: any directories above that (like test in my example) are basically ignored, but allow you to symlink into dirs owned by other users
<clever>
makefu: nix-env will recursively search ~/.nix-defexpr/ until it either finds <name>.nix or <name>/default.nix, and then create a channel with <name>
<clever>
makefu: for a more complete explanation of how things work
<clever>
just the vm
<clever>
yeah
<clever>
you might be able to remove those udev rules now and still have it work
<clever>
so it relied on the udev rules
<clever>
i'm guessing that previously, the helper to gain root and not need udev was just missing
<clever>
ah
<clever>
something must have changed
<clever>
where you running things as root?
<clever>
you need the config listed in the comment to make it setuid
<clever>
i'm also not sure what nix2 has done with ~/.nix-defexpr/
<clever>
makefu: that would be a good idea
<clever>
the-kenny: nix-env is the only tool that reads ~/.nix-defexpr/ and the structure is un-documented
<clever>
the-kenny: no changes at all to it
<clever>
or have entirely custom package sets
<clever>
all nix-env cares about, is that it returns a function, which returns a package set, so you can import any nixpkgs you want, fetched any way you want
<clever>
makefu: this creates a foo channel, so i can now nix-env -iA foo.hello
<clever>
so i used a bind-mount at boot time to change the whole profiles directory
<clever>
yeah
<clever>
nixos-rebuild cant be told to use a different profile
<clever>
profiles-arm/system
<clever>
or rather
<clever>
yeah
<clever>
but in my case, i was running arm and x86 nixos from the same disk
<clever>
that would probably be simpler, if you only have 1 nixos
<clever>
ah yeah, if you just mess with the ~/.nix-profile symlink, you can get nix-env to use any profile
<clever>
boomshroom: the default profile is roots nix-env profile
<clever>
boomshroom: i had to manually add both to the gcroots directory
<clever>
to bind-mount the right one
<clever>
boomshroom: when i shared a store between platforms, i had a profiles.x86 and a profiles.arm, and then i used fileSystems."/nix/var/nix/profiles" = { fsType = "bind"; ...
<clever>
dtz: yeah, the commit messages are a bit cut off
<clever>
or that?
<clever>
2018-03-11 16:52:11-{^_^}:#nixos- → 0edb8f7b by @dtzWill: Merge pull request #36810 from dtzWill/fix/glibc-with-mus
<clever>
samueldr: maybe that?
<clever>
2018-03-11 16:44:45-{^_^}:#nixos- → 880311a5 by @grahamc: Merge pull request #36824 from dupgit/patch-
<clever>
samueldr: i checked it here, nothing looks cut off
<clever>
if you wipe that, it will re-check everything
<clever>
Lisanna: ~/.cache/nix/tarballs/ is where it stores the cache
<clever>
ahh
<clever>
heh
<clever>
?
<clever>
an hour i think?
<clever>
yep
<clever>
yes
<clever>
Lisanna: the ttl for builtins.fetchTarball
<clever>
boomshroom: if your on wep or open, you can manually connect using iwconfig
<clever>
boomshroom: yeah
<clever>
and hardware.wireless.enable = truee;
<clever>
boomshroom: for all of my systems, the wifi drivers just work, and all i have to do is copy /etc/wpa_supplicant.conf in to make it live
<clever>
yeah, something sometimes doesnt work right with that in the binary cache
<clever>
so it never uses it
<clever>
disasm: you dont have cache.nixos.org listed