<clever>
yl[m]: the hash will at least pass if you switch to fetchurl
<clever>
yl[m]: we should kick apple out of the club for being crap :P
<clever>
yl[m]: are there potentially duplicate files, like foo and Foo in the repo?
<clever>
LnL: oh, case sensitive!
<clever>
which calls fetchzip behind the scenes, should be good
<clever>
yl[m]: is it fetchurl or fetchzip?
<clever>
list type options will always merge
<clever>
muvlon: an overlay is a way to add multiple sets of overrides to nixpkgs
<clever>
muvlon: yeah
<clever>
muvlon: in this example i linked, setting one of the enable flags will automatically add an overlay to nixpkgs, which includes the custom package it needs
<clever>
2019-01-20 16:44:22 < __monty__> clever: Ah, but teach a man to fix his discord and he will have pointless internet discussions for a lifetime ; )
<clever>
freedan42x: in any directory you have write access to
<clever>
freedan42x: yes, it will download all packages
<clever>
__monty__: yeah, that would save a step, but you can always add a remote to it
<clever>
freedan42x: that is not the command i gave you
<clever>
freedan42x: what command did you run?
<clever>
__monty__: depends on if its fixed upstream or if he is trying to edit it locally, and if he will be making a pr after fixing it
<clever>
laas: if your installing gcc, then your doing it wrong
<clever>
freedan42x: did you try the github search, for "discord" ?
<clever>
and there are many ways to do that
<clever>
freedan42x: that only works if the one on github has already been updated
<clever>
freedan42x: look at what changes other people have done, mostly in the version or src area, and then repeat them on your own clone of nixpkgs, with the new version#
<clever>
x
<clever>
freedan42x: click the history button on github, when looking at the discord/default.ni
<clever>
__monty__: find the default.nix for discord in nixpkgs, and check its git history
<clever>
__monty__: i believe discord is already fixed in master
<clever>
freedan42x: ^^
<clever>
fyuuri: ghci is the haskell repl
<clever>
fyuuri: the real source is already in /nix/store/
<clever>
fyuuri: /build/ is only the temp dir it unpacks the source to
<clever>
fyuuri: something like $out-chroot, based on what is currently being built
<clever>
fyuuri: /build/ is mapped to something in /nix/store/ and deleted when the build fails
<clever>
tilpner: those are only symlinks pointing into the nix store, its practically zero size
<clever>
fyuuri: its always in /nix/store/ and a nix-collect-garbage will get rid of it
<clever>
fyuuri: /build/ is a temporary directory for builds, where it unpacks the src, after having already downloaded it
<clever>
fyuuri: it will tell you the path, as it downloads it
<clever>
fyuuri: all things nix downloads always go to /nix/store/
<clever>
then you can directly refer to the derivation, and not put it in srcs
<clever>
fresheyeball: which is why i said, its simpler to just cp ${otherthing} $out/bar/
<clever>
fresheyeball: then things get overwritten
<clever>
WhittlesJr: then nvidia is somehow in your environment.systemPackages, but it could also be the x11 drivers doing that
<clever>
varies from case to case
<clever>
it generally works fine
<clever>
which then gives entirely different versions of all dependencies
<clever>
iqubic: the `import <nixpkgs>` in the wrapper, will load the nixpkgs from $NIX_PATH
<clever>
WhittlesJr: look at the order the derivations fail in at the end, it should say which depended on nvidia
<clever>
iqubic: its very likely to be the issue
<clever>
iqubic: the version of nixpkgs it uses to build discord
<clever>
fresheyeball: then cp ${other-derivation} $out/bar
<clever>
fresheyeball: it would likely be simpler to just cp ${./foo} $out/bar in the install phase
<clever>
fresheyeball: why do you need multiple srcs?
<clever>
yl[m]: most people i know only do deployments at controlled times, rather then at every push
<clever>
and each user is going to have to re-download the entire closure of the cluster from a binary cache, before they can deploy anything
<clever>
yl[m]: another problem, is that if you dont pin nixpkgs correctly, every person that deploys is going to (up/down)grade the entire cluster to a random version of nixpkgs
<clever>
yl[m]: have a dedicated machine that runs nixops, stores the state, and everybody ssh's into it
<clever>
yl[m]: and any time you try to do that, you ruin the lock file that is supposed to protect you from major merge conflict type problems
<clever>
yl[m]: i only use export/import as a way to migration a deployment to another box, something that shouldnt be done often
<clever>
yl[m]: `nixops modify -d foo path/to/bar.nix` can alter a deployment, after importing
<clever>
Zer000: the realpath binary does that for you, recursively
<clever>
Zer000: unfree, and if an update is available, the old version refuses to work
<clever>
iqubic: nix-channel --update, without anything else, updates all channels on the current user
<clever>
iqubic: yeah
<clever>
oh, `git push --force origin master`
<clever>
`git reset --hard REV` to set a local branch to a given commit
<clever>
and it will force push whatever your current branch is, to the remote one
<clever>
`git push --force master`
<clever>
force-push a different commit
<clever>
its not really of any use
<clever>
iqubic: you can basically just ignore the master branch on your fork
<clever>
iqubic: `git checkout -b foo` will create a branch called foo, based on the current commit
<clever>
appleclusters: its either a config file in $HOME (which nix will never delete) or is just always broken (you need to debug and fix it)
<clever>
appleclusters: the nix side of things is pure and would give you the exact same binaries, even if you fully deleted things
<clever>
Lisanna: maybe report it upstream
<clever>
Lisanna: definitely sounds like a bug in the drivers
<clever>
Lisanna: all i can think of is to grab the EDID block, and paste it into an online EDID decoder
<clever>
Lisanna: the "intel(0)" in your msg says your using the right driver
<clever>
Lisanna: not sure then
<clever>
Jan 15 13:27:26 nas display-manager[23257]: (II) RADEON(0): Modeline "1920x1080i"x60.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
<clever>
Jan 15 13:27:26 nas display-manager[23257]: (II) RADEON(0): Manufacturer: SNY Model: 4201 Serial#: 16843009
<clever>
Jan 15 13:27:26 nas display-manager[23257]: (II) RADEON(0): EDID for output HDMI-0
<clever>
Lisanna: check `journalctl -u display-manager` for a msg like this
<clever>
Jan 15 13:27:26 nas display-manager[23257]: (II) RADEON(0): Supported established timings:
<clever>
Lisanna: checking my media box to see what it says...
<clever>
pbb: i usually make /boot 1gig, for my rescue system
<clever>
pbb: i still dont trust grub with zfs support though
<clever>
which gives it enough support to mount /boot/, load your cfg, and read more grub module files
<clever>
the grub drivers for your /boot/ fs are also concat'd to that kernel
<clever>
and then that loads the grub kernel from the 2nd region
<clever>
in either case, a ~400 byte stub is put into sector 0, with the MBR tables (gpt has a protective mbr table)
<clever>
so it now requires you to properly define the region to use, with a bios boot partition
<clever>
pbb: but on gpt, the partition tables are larger then 1 sector, so thats no longer safe
<clever>
pbb: when on MBR, grub will use the "unused" space between sector 0 and partition 0
<clever>
pbb: grub will scan the partition table, and find the bios boot partition
<clever>
pbb: nope, the grub device is the hdd above the part, like sda
<clever>
pbb: it is never mounted, and does not need to be formatted
<clever>
pbb: if you want legacy booting on gpt, you must create a 1mb bios boot partition
<clever>
muvlon_: and nix will enforce that the hash of the output is what you claimed it is
<clever>
muvlon_: when sandboxing is enabled, only fixed-output derivations are allowed network access
<clever>
muvlon_: more about the outputs arent tracked, and it could do non-reproducible things
<clever>
ottidmes: there is also `nix show-config`
<clever>
muvlon_: it would be simpler to clone the nixpkgs repo at the current rev, and just edit the script
<clever>
muvlon_: you could just manually run it after every nixos-rebuild, but your bound to forget
<clever>
ottidmes: what about the nix.conf in $HOME ?
<clever>
muvlon_: and thats based on which boot.loader.X.enable you have set
<clever>
muvlon_: the only script being ran impurely, when updating /boot/
<clever>
fresheyeball: maybe your missing the --prefix=$out now?
<clever>
so cabal has fallen back to defaults
<clever>
muvlon_: there is currently no way to tell nixos-rebuild to run 2 scripts
<clever>
fresheyeball: does the cabal file or Setup.hs maybe have a hard-coded command to copy things to /usr/ ?
<clever>
muvlon_: no other scripts are ran at the right phase in nixos-rebuild
<clever>
fresheyeball: is /usr in the cabal file?
<clever>
muvlon_: only one script can be setup for installing a bootloader, so it will just run one
<clever>
muvlon: then youll want to read what samueldr linked
<clever>
muvlon: or patch the script samueldr linked in a nixpkgs fork, to make it better
<clever>
muvlon: looks like you may need an override on the kernel package, to change the dtb files within it
<clever>
muvlon: what about your bootloader config?
<clever>
muvlon: what is your current configuration.nix?
<clever>
muvlon: youll want to find out what script is copying it to /boot/ and then setup an override, is this on an rpi?
<clever>
pbb: thats weird
<clever>
pbb: i'm guessing thats more likely a coreboot issue then a grub issue, since the bios is typically responsible for bringing the gpu into a sane state
<clever>
pbb: as long as the modules nixos uses, are in your grub2 payload, it should just work, as long as the payload reads the grub.cfg nixos generates