2019-01-21

<clever> lokado: is the keyboard working at all?
<clever> fresheyeball: is NIX_REMOTE set to anything?
<clever> that shouldnt affect nix-daemon in any way...
<clever> fresheyeball: was nix-build or nix-daemon ran under stace?
<clever> 814 } catch (std::bad_alloc & e) {
<clever> src/nix-daemon/nix-daemon.cc: tunnelLogger->stopWork(false, "Nix daemon out of memory", 1);
<clever> fresheyeball: does the box have swap?
<clever> fresheyeball: which daemon?
<clever> fresheyeball: can you pastebin the result of `strace -ff -e execve -o logfiles nix-build ...` ?
<clever> fresheyeball: what does `ls -lhd /nix/var/nix/` say?
<clever> fresheyeball: one min...
<clever> fresheyeball: already in another voice chat
<clever> nh2: running meson --buildtype=help in a nix-shell should give options
<clever> nh2: i believe you want to set the nix var mesonBuildType
<clever> if system isnt set, it defaults to the version of the nix binary
<clever> > builtins.currentSystem
<clever> then the new nixpkgs will match the pkgs set
<clever> timclassic: you must import (builtins.fetchGit { ... }) { system = pkgs.system; }
<clever> timclassic: you didnt set system= on that, so its defaulting to the arch of the nix binary
<clever> fresheyeball: although...., if nix-daemon is in use, then jenkins shouldnt be able to mess with such things
<clever> nh2: because it works when the exact same expression is manually build
<clever> nh2: jenkins might be setting different values in ulimit, so it only fails under an automated job
<clever> fresheyeball: and if you compare running `ulimit -a` from an automated ci job, vs a normal shell?
<clever> timclassic: are you doing `import <nixpkgs> {}` at any point?
<clever> nh2: if you restart pulseaudio, then chrome looses the ability to capture any audio, until its also restarted
<clever> fresheyeball: also, compare what `ulimit -a` prints, under both a CI job, and a normal shell, on the same machine
<clever> fresheyeball: try switching to the right user with `sudo -u X -i` ?
<clever> fresheyeball: are you doing that from the same dir jenkins uses internally? as the same user?
<clever> fresheyeball: if you manually run nix-build on the problem machine, does it still fail?
<clever> fresheyeball: have you thought of using hydra?
<clever> fresheyeball: travis, or something custom?
<clever> nh2: try `nix-store -q --tree /nix/store/yqmn382kz80h0bgzs3jb5kgz13x1l6vn-gst-plugins-bad-1.15.1.drv` instead
<clever> nh2: why-depends only works on finished builds
<clever> fresheyeball: which CI system?
<clever> nh2: you may have GC'd libuv previously
<clever> it automatically applies the right override flags for you
<clever> check the example above
<clever> nh2: ah, thats what enableDebugging does
<clever> ,locate libgstsrt.so
<clever> nh2: whatever derivation is providing it
<clever> nh2: having debug symbols would let you confirm the args to strchr
<clever> nh2: this one
<clever> > enableDebugging pkgs.glibc
<clever> wait no, wrong adapter
<clever> nh2: then you can see the args passed to __strchr_avx2
<clever> nh2: an override on glibc using makeStaticLibraries i think, but the stdenv may complicate it
<clever> nh2: rebuild it against a debug glibc
<clever> nh2: glib was changed from autoconf to meson, so it ceased to obey makeStaticLibraries
<clever> nh2: i also ran into meson problems in glib today
<clever> samueldr: i would just migrate the profile to it :P
<clever> and i need to reboot soon for a kernel update in nixos
<clever> fresheyeball: restoring 1000+ tabs
<clever> fresheyeball: will take about an hour to open my chrome
<clever> fresheyeball: can you run `nix show-derivation /nix/store/m2s4i2g6gln9vf6pvh37x37cvsk12gik-cabal2nix-kassir.drv` on the CI system?
<clever> fresheyeball: run `nix show-derivation` on both of those drvs, and then compare them
<clever> fresheyeball: are the .drv paths and $out paths the same on both local and CI?
<clever> fresheyeball: i think that limit is lower then the default
<clever> fresheyeball: did it give a build error?
<clever> fresheyeball: what happened with the ld fix from anger mans fork?
<clever> fresheyeball: still?

2019-01-20

<clever> yl[m]: need root for that
<clever> it may cause similar problems if any darwin user tries to clone the repo
<clever> you could also maybe find the problem file upstream, and file an issue about it
<clever> but, then its sensitive to what the FS on the host does, when you unpack X and then discover it turned into x
<clever> fetchzip will hash the unpacked contents, so it doesnt care about how the zip describes the files
<clever> which causes a new hash every time
<clever> yl[m]: some crap services, will generate a new zip/tar every time, with varying timestamps in the zip listing
<clever> github is usually good at making a stable tarball
<clever> yl[m]: you will want a URL like https://github.com/keybase/client/archive/v2.13.1.tar.gz
<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> muvlon: yes
<clever> nh2: strace time, see how its searching
<clever> but it might be something weird youve done, that sometimes isnt recursive
<clever> ivan: if it was recursive, it would consume all stack without limit
<clever> ivan: or you have a recursive import statement somewhere
<clever> nh2: either 9.2 deviced to remove it, or the 9.2 package is broken
<clever> ivan: thats 8192kb, not 8192byte
<clever> nh2: ah, then you probably need the 9.1 version
<clever> ivan: ulimit
<clever> nh2: my first guess, try just adding pkgconfig to the nativeBuildInputs ?
<clever> nh2: its calling a function called dependency
<clever> nh2: what i always do in situations like this, is read the configure script and find out how its detecting a package
<clever> Ashy: the build probably failed
<clever> freedan42x: nix-env -f https://github.com/nixos/nixpkgs/archive/master.tar.gz -iA discord --arg config '{ allowUnfree = true; }'
<clever> *doh*
<clever> that tells it to ignore config.nix
<clever> freedan42x: nix-env -f https://github.com/nixos/nixpkgs/archive/master.tar.gz -iA discord --arg config '{}'
<clever> freedan42x: yes
<clever> freedan42x: nix-env -f https://github.com/nixos/nixpkgs/archive/master.tar.gz -iA discord
<clever> ah, mixed the 2 convos up
<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> freedan42x: to the current directory
<clever> freedan42x: `git clone https://github.com/nixos/nixpkgs`
<clever> freedan42x: you must either copy the whole nixpkgs, or just git clone it from github
<clever> freedan42x: everything in /nix/store/ is read-only
<clever> appleclusters: or users.users.<name?>.packages
<clever> laas: that gives a shell with gcc and meson
<clever> laas: nix-shell -p meson
<clever> freedan42x: nix-instantiate --eval -E "with import <nixpkgs> {}; discord.meta.position"
<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> Lisanna: yeah, i dont think 1.2 can do 4k
<clever> Lisanna: what about `xrandr -q` ?
<clever> 4k requires a higher bitrate, which older cables arent rated for
<clever> and is the hdmi cable also rated for 4k?
<clever> Lisanna: do you know for sure that the GPU is capable of 4k?

2019-01-19

<clever> martin___: the default configure script may disable gd by default
<clever> that would be set by, configureFlags = [ "--enable-gd" ];
<clever> martin___: it may need a --enable-gd flag to configure
<clever> martin___: what is the error your getting?
<clever> martin___: you should add gd to the buildInputs in that case
<clever> martin___: also, nix-build will never be able to see things installed via nix-env
<clever> martin___: you must use nix-shell for gcc to find the libs
<clever> martin___: the gcc that comes with nix will also never search the location nix-env affects
<clever> ,libraries martin___
<clever> also, nix-env will never install the -dev
<clever> martin___: split outputs
<clever> infinisil: bit shift is just *2 or /2, if your lazy
<clever> > lib.mod 11 5
<clever> iqubic: nix-env --profile /nix/var/nix/profiles/system --delete-generations 188
<clever> iqubic: what does `ls -lh /nix/var/nix/profiles/system` return?
<clever> iqubic: give it something to import, like nix repl '<nixpkgs>'
<clever> iqubic: nix repl, "${pkgs.hello}"
<clever> iqubic: yes
<clever> iqubic: and use nix-store --query --roots to find the roots
<clever> selfsymmetric-mu: http://howoldis.herokuapp.com/ has links to the tested jobs for each channel
<clever> i prefer putting the version= into a let block, so its more obvious it cant be changed
<clever> no, its 4am, and i need to sleep :P
<clever> --option takes 2 args
<clever> yeah, you only quote the URL's
<clever> --option a 'b c' is setting a=b c
<clever> --option a b c, is setting a=b, and then passing c as the URL to dl
<clever> you want to quote the option
<clever> if you just feed a URL to nix-build, it will download and try to un-tar it
<clever> fresheyeball: it has to go into the binary cache list, like in the config i linked
<clever> fresheyeball: what did you feed that url to?
<clever> fresheyeball: hydra.iohk.io has most of this branch cached
<clever> fresheyeball: changing nixpkgs is easyer, -I nixpkgs=https://github.com/input-output-hk/nixpkgs/archive/d11dbab6ae9f15fa2bd97906f09eaec934021f6d.tar.gz
<clever> fresheyeball: i dont think its easy to up the limit
<clever> fresheyeball: yeah, that commit, on the fork
<clever> fresheyeball: what happens if you switch to that commit of nixpkgs?
<clever> the commits angerman linked, will use response files to bypass argv
<clever> and nix puts hashes on every single one
<clever> fresheyeball: and haskell has a lot of libs being passed to ld
<clever> fresheyeball: yeah, linux requires that the sum of envvars, and argv, be within a certain limit
<clever> fresheyeball: your CI has a higher limit, but that may just be outside of the nix sandbox
<clever> fresheyeball: i believe master has had ghc gixed involving command line length, though it may only be in angerman's branch
<clever> Maximum length of command we could actually use: 2082552
<clever> fresheyeball: run `xargs --show-limits` on both CI and local
<clever> fresheyeball: which channel?
<clever> which will // an attr in, before calling the real one
<clever> fresheyeball: now, when every single package in the set tries to call mkDerivation, it calls this variant
<clever> fresheyeball: foo = haskellPackages.override { overrides = self: super: { mkDerivation = args: super.mkDerivation (args // { foo = true; }); }; }
<clever> fresheyeball: if you make an override on mkDerivation, you can also do overrideCabal style things globally
<clever> and that chain has zero effect
<clever> > haskellPackages.lens
<clever> fresheyeball: not sure how to squeeze a .override in though
<clever> > ((haskell.lib.overrideCabal haskellPackages.lens (old: {})).overrideAttrs (old: {})).overrideDerivation(old: {})
<clever> it is also possible to use all the overrides!
<clever> been there
<clever> overrideDerivation acts after stdenv.mkDerivation, so it cant affect some of the stdenv magic
<clever> overrideCabal acts before generic-builder.nix
<clever> so overrideAttrs acts on the "nix derivation" after it has had all the haskell magic applied to it
<clever> fresheyeball: the generic-builder.nix calls stdenv.mkDerivation
<clever> fresheyeball: the problem, is that overrideAttrs acts on stdenv.mkDerivation
<clever> yeah, that looks right
<clever> fresheyeball: mostly, haskell.lib.overrideCabal drv (old: { ... })
<clever> fresheyeball: you must use overrideCabal
<clever> pbb: so you can just not run the script after booting
<clever> pbb: doesnt matter that much, all it does is put justdoit into $PATH
<clever> fresheyeball: what was it?
<clever> or other repair
<clever> and if you can access grub, you can then boot into it at any time, to handle reinstalls
<clever> pbb: this puts the same kind of kernel/initrd uses for kexec into /boot/
<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