<clever>
ylwghst_: it gets generated automatically when you run "nixos-rebuild switch" or "nixos-rebuild boot"
<clever>
jellowj: there is a different version in libudev.lib
<clever>
libudev.lib 0 s /nix/store/qqz3iq8w5cqakdqw2rjbylzabf1pdb5z-systemd-232-lib/lib/libudev.so
<clever>
ylwghst_: it will be added it to the ~/.nix-profile of the user running nix-env
<clever>
ylwghst_: yes
<clever>
ylwghst_: nix-build creates a symlink called result in the current directory
<clever>
brb
<clever>
ylwghst_: this will just download it, and create a result symlink pointing to it
<clever>
nix-build '<nixpkgs>' -A grub2_efi
<clever>
ylwghst_: that downloads them, and adds it to your profile, which you probably dont want
<clever>
and it will keep working even if ipfs is turned off
<clever>
and ipfs can then optionaly share the content of /nix/nars back to the world
<clever>
a seperate daemon, would need to download the .nar file (http or ipfs), and store it in a path like /nix/nars
<clever>
the only thing really missing, is an RPC that allows adding/removing nar files, and to replace nix's internal "unpack nar to /nix/store" with "copy nar to X and RPC narfuse to reload"
<clever>
and it wont care if ipfs is sneaking a look and reading the same files to share
<clever>
and it doesnt need to talk to ipfs at any point
<clever>
and it will magically turn into a working /nix/store/ directory
<clever>
with narfuse or fusenar, you can just take a raw directory of 2anxmi1jpn6im0mqwxha2krmdjib2579-grub-2.x-2015-11-16.nar files
<clever>
and ipfs has said that in the future, they will allow sharing files you have promised to keep immutable, so they dont have to be chunked up and put into ~/.ipfs/blocks/
<clever>
i wrote a custom fuse layer, that lets you mount a directory full of .nar files at /nix/store
<clever>
and thats where narfuse and fusenar come into play
<clever>
next, using logic from nix-index, you could iterate over every derivation in a given channel release, bulk-download the narinfo's with ipfshash + signature, and setup a mirror
<clever>
and all binary-cache stuff continues to work as it does now
<clever>
its just a different way to download the .nar.xz
<clever>
so determinism never comes into the story
<clever>
hydra and cache.nixos.org still manage the signature (its in the narinfo), and advertise what the proper ipfs hash is
<clever>
then anybody can do "ipfs add foo.nar.xz" and share the file they downloaded with the world
<clever>
with 1 more field, the ipfs hash, we would have instant ipfs support
<clever>
and FileHash (a hash of the compressed file)
<clever>
within there, is the NarHash (a hash of the uncompressed nar)
<clever>
Infinisil: grab the hash from any valid storepath, and paste it into a url like this, and you get the narinfo
<clever>
[clever@amd-nixos:~]$ nix-build '<nixpkgs>' -A grub2_efi --no-out-link
<clever>
Infinisil: do you know how the narinfo files work?
<clever>
yeah
<clever>
the path in a.out has nothing to do with the actual value of the files inside a.out
<clever>
Infinisil: a.out is just a path, computed from the contents of a.drv
<clever>
Infinisil: if a.drv == b.drv, then a.out is always equal to b.out, but the contents within a.out may not match up
<clever>
ylwghst_: it is present
<clever>
-r-xr-xr-x 1 root root 9560 Dec 31 1969 /nix/store/2anxmi1jpn6im0mqwxha2krmdjib2579-grub-2.x-2015-11-16/lib/grub/x86_64-efi/setpci.module
<clever>
-r--r--r-- 1 root root 9016 Dec 31 1969 /nix/store/2anxmi1jpn6im0mqwxha2krmdjib2579-grub-2.x-2015-11-16/lib/grub/x86_64-efi/setpci.mod
<clever>
[clever@amd-nixos:~]$ ls $(nix-build '<nixpkgs>' -A grub2_efi --no-out-link)/lib/grub/x86_64-efi/setpci* -l
<clever>
avn: which points to a file or directory within ipfs
<clever>
avn: the closest thing is IPNS, which is based on publickey = signed(ipfs hash)
<clever>
that doesnt infer any relation between the hash of the output and the input values
<clever>
Infinisil: nope, deterministic just ensures the same input always gives identical output
<clever>
avn: and if you have to run gcc on a source file and hash it, you already have the value, and no longer need the cache
<clever>
avn: the problem is that IPFS is purely a hash(value) = value lookup system, so you need to know the hash of the value
<clever>
Infinisil: so you need a central index that maps hash(build-script) to hash(output)
<clever>
Infinisil: the root problem with anything using nix + ipfs, is that /nix/store/<hash> is a hash over the directions on how to build it, not a hash of the output
<clever>
it will usually download it from the binary cache
<clever>
it will then print the path to stdout, and --no-out-link stops it from creating a result symlink
<clever>
that tells nix-build to load the nix expressions in '<nixpkgs>' and then -A grub tells it to build grub
<clever>
ylwghst_: [clever@amd-nixos:~]$ ls $(nix-build '<nixpkgs>' -A grub --no-out-link)
<clever>
there is a command-not-found thing mentioned in the issues on it
<clever>
Infinisil: the new nix-index is written in rust, and scans every file in every derivation in the eval
<clever>
the old command-not-found used c++ to scan the closure of an entire hydra eval for binaries, and make a programs.sqlite
<clever>
its the new replacement for command-not-found
<clever>
irssi.out 11,680 x /nix/store/h1zm9jy0ns014nry2vj8s1vqzg0m7p5k-irssi-1.0.2/etc/irssi.conf
<clever>
dpino: i generally use nix-repl to do all of my searching, but the command you previous gave fails with a different error here, error: selector ‘nix-env’ matches no derivations
<clever>
deltasquared: and in the case of /etc, line 122 refers to the sum of all activation scripts, which are defined in another module
<clever>
and 105 builds the top-level derivation using the builder defined on 30
<clever>
line 132 defines system to be the result of applying some security related mutations over baseSystem from line 105
<clever>
deltasquared: and because of the module framework, this file is merged with every other module, and configuration.nix
<clever>
deltasquared: when you run nixos-rebuild, all it does is build the derivation refered to on line 252
<clever>
and in the end, you have a single derivation, that directly (or indirectly) depends on all of the config and everything it gnerates
<clever>
at its core, nixos is a module framework to combine option and config definitions from many modules, and allow the modules to set eachothers config
<clever>
not from the packages
<clever>
that must be done from nixos modules
<clever>
yep
<clever>
yeah
<clever>
then it can atomicly swap most of /etc by updating just /etc/static
<clever>
deltasquared: setup-etc.pl manages it by symlinking everything via /etc/static, and keeping track of which files it has created, so it can remove them later on
<clever>
yeah
<clever>
deltasquared: etc.nix defines the nixos options for it, make-etc.sh converts those options into a derivation, and then setup-etc.pl runs on bootup to re-sync /etc with the derivation
<clever>
dpino: the main thing is that nixos-rebuild expects a chanenl called nixos on root
<clever>
srhb: "rebuild switch" will definitely fail in a chroot, because it tries to mess with the active systemd, you want "rebuild boot"
<clever>
dpino: and 15.09 is really old
<clever>
dpino: then you have 3 channels
<clever>
ylwghst: if you have a /boot you must also mount it to /mnt/boot/
<clever>
dpino: what about sudo nix-channel --list?
<clever>
just set the right settings in configuration.nix and nixos-rebuild switch
<clever>
and it needs system wide config via configuration.nix, so it wont work right with nix-env
<clever>
networkmanager isnt under linuxPackages, and the pkgs. is redundant
<clever>
and that will upgrade the install
<clever>
ylwghst: simplest option, enable it in configuration.nix, then boot from the installer, re-mount the filesystems to /mnt, and re-run nixos-install
<clever>
Naughtmare[m]: but i dont see a QT option, so that would have to be added in pkgs/applications/networking/p2p/transmission/default.nix
<clever>
Naughtmare[m]: the normal and gtk versions are the same package, one of them just has enableGTK3 set to true
<clever>
ah, i see the second one, bash will probably treat it as part of the filename
<clever>
Returns a status of 0 or 1 depending on the evaluation of the conditional
<clever>
maurer: try setting the NIX_DEBUG variable to anything
<clever>
then it hasnt hit the strip yet
<clever>
ah, and its already missing even there
<clever>
dontStrip = true; can prevent that on a per-derivation basis
<clever>
it might be the automatic pass of "strip" over all binaries
<clever>
ah
<clever>
that definitely sounds important, when exactly is it breaking?
<clever>
ah
<clever>
maurer: plt?
<clever>
with the buildenv, id have to uninstall it because it would have conflicted in the future
<clever>
just add it, and nix-env -iA nixos.foo
<clever>
but its now far easier to add things without a mass-rebuild
<clever>
adelbertc: only downside i can see with this new trick, there is no easy way to see what is missing from newstuff, since its no longer showing as a single unit
<clever>
you can also install 2 things at once as an atomic operation
<clever>
installing ‘alsa-tools-1.1.3’
<clever>
replacing old ‘mystuff’
<clever>
[clever@amd-nixos:~]$ nix-env -iA nixos.newstuff -A nixos.mystuff
<clever>
thats why i havent been maintaining mystuff properly, and my nix-env -q has group out of control, lol
<clever>
before i can switch away from the system that forces mass-updating
<clever>
so i have to modify mystuff, and reinstall it (which upgrades ALL of mystuff)
<clever>
the alsa-tools in newstuff conflicts with the alsa-tools in mystuff
<clever>
collision between ‘/nix/store/g1f383mjbgv7wnqxgmgdymmc26abk5ry-mystuff/bin/as10k1’ and ‘/nix/store/fca9kqx6czwgcbp2k39c1bwzpc4ag03a-alsa-tools-1.1.3/bin/as10k1’; use ‘nix-env --set-flag priority NUMBER PKGNAME’ to change the priority of one of the conflicting packages
<clever>
another related issue
<clever>
you have to update all of them as one unit
<clever>
which makes it difficult to update just one item
<clever>
yeah
<clever>
line 11 is the new trick, 14 is the old trick
<clever>
and that set is automatically available in every nixpkgs you import as that user
<clever>
adelbertc: nixpkgs will load config.nix on startup, and that lets you set package overrides
<clever>
but i have since heard a new trick, just make a new set in packageOverrides like { packageOverrides = pkgs: with pkgs; { group1 = { inherit gitFull; }; }; }
<clever>
previously i made a single derivation in packageOverrides that used buildEnv to merge things
<clever>
i do that in ~/.nixpkgs/config.nix
<clever>
ah
<clever>
and then make a default.nix that does { pkgs ? import <nixpkgs>{} }: { foo = pkgs.callPackage ./foo.nix {}; }
<clever>
another option, create a foo.nix that properly does { stdenv, foo, bar }:
<clever>
yeah
<clever>
which runs with directly on the entire set
<clever>
or with import <nixpkgs> {};
<clever>
prefixing an attr path with pkgs. has no impact at all, once your in the set