2018-01-31

<clever> cinimod_: nix-env -iA nixos.texlive.combined.scheme-basic
<clever> cinimod_: and probably a nixpkgs as well, or nixos
<clever> cinimod_: -iA
<clever> domenkozar: and some codecs have bugs that others dont
<clever> domenkozar: the hda-intel hardware doesnt work with raw pcm samples, so the kernel has to use the right codec when streaming data to the card
<clever> snd_hda_codec 106496 3 snd_hda_intel,snd_hda_codec_generic,snd_hda_codec_realtek
<clever> domenkozar: can you compare the output of lsmod between a nixos generation that works, and one that doesnt?
<clever> maybe
<clever> but qt is also a tree of derivations, so its trick to override the entire set
<clever> pie_: you could maybe create a packageOverride that forces every channel to use the same qt version
<clever> domenkozar: this might be related: https://github.com/NixOS/nixpkgs/issues/15005
<clever> domenkozar: oh, and do you have virtualbox enabled in nixos?
<clever> pie_: but thats sort of the original problem nix was meant to solve, and relying on things being in a common directory goes against nix
<clever> pie_: i think the first step would be to rename the qt-5.9 directory in lib to qt-5.9.1, so that the versions that it complains about, cant conflict
<clever> pie_: it works best if you only install QT programs via systemPackages, then they always share the same nixpkgs version
<clever> domenkozar: and without pulseaudio managing the difference between the speaker and headphone mutes, you may also want to manualy manage that in alsamixer
<clever> pie_: the QT stuff in nix is a bit of a mess, and the one thing ive found that breaks all the rules
<clever> pie_: nix-shell works purely thru env variables, and wont set it up right
<clever> pie_: a lot of QT things assume that the propagated-user-env-packages land in $HOME/.nix-profile/ and configure their search paths to match that
<clever> domenkozar: yep
<clever> pie_: this is also the second time ive seen this bug crash plasma
<clever> domenkozar: next thing i was thinking of testing, disable pulseaudio, and then use an old alsa test application to see if the alsa drivers are even working
<clever> which is the oposite of what nix-env normally does
<clever> so when things ask for both 5.9.1 and 5.9.2, it just gives one and doesnt tell you
<clever> propagated-user-env-packages will also silently ignore collisions
<clever> keep searching the --tree for any other things depending on QT
<clever> pie_: something else you have is silently adding it
<clever> pie_: propagated-user-env-packages
<clever> pie_: plasma runs as your user, and obeys the search path that points into ~/.nix-profile
<clever> but anything you got from unstable is going to be breaking the os
<clever> ah
<clever> pie_: and how did you tell nix-env to upgrade?
<clever> how did you upgrade things?
<clever> are there multiple channels on either user?
<clever> pie_: does the user have its own nix-channel?
<clever> pie_: so you need to either get all of nix-env on 5.9.1, or just remove all qt from nix-env
<clever> pie_: aha, so i was backwards in assuming 5.9.2 was the right one
<clever> pie_: nix-store -qR $(which plasmashell) i think
<clever> pie_: now double-check what version of QT plasma was linked against
<clever> pie_: but the storepath behind those names does
<clever> pie_: and does the 5.9 contain 5.9.1 or 5.9.2?
<clever> pie_: do you have a directory matching ~/.nix-profile/lib/qt*
<clever> pie_: but the runtime assertion is more strict then that namespacing
<clever> pie_: double-check in ~/.nix-profile/lib/ and you should see a qt directory, that is partially namespaced on version
<clever> pie_: i dont think 5 can ever load 4 by mistake
<clever> i use imports = [ ./nixcfg/agh.nix ]; and keep the repo in /etc/nixos/nixcfg
<clever> or better, uninstall them, and add them to systemPackages so they remain in sync
<clever> pie_: it should result in you having only QT 5.9.2 in the tree
<clever> pie_: check nix-store --query --tree ~/.nix-profile/ for anything refering to QT 5.9.1, and upgrade those
<clever> pie_: firefox doesnt use QT, so it shouldnt matter
<clever> pie_: if you do upgrade your nix-env stuff, it will cause the same problem 6 months down the road, when you update nixos again
<clever> pie_: entire make sure every single QT program in nix-env is on the same QT version as nixos, or remove all QT programs from nix-env
<clever> coconnor: yeah, ~/.nix-profile has priority over systemPackages
<clever> which just break everything :P
<clever> and that has conflicting versions of the libraries
<clever> the system plasma obeys the env vars that say to look in ~/.nix-profile/
<clever> and/or remove them and let systemPackages keep them in sync
<clever> pie_: the only solution, is to upgrade every QT package in nix-env to the same nixpkgs
<clever> pie_: the problem is that you mixed QT versions inside nix-env
<clever> pie_: reboot wont fix that, i have an issue open for it
<clever> pie_: aha
<clever> mbrock: but if things are just interupted, it will restart on another slave
<clever> mbrock: and things getting stuck in limbo is either a case of the retry timeout not being visible, or require features not being met, and the GUI cant tell you what its waiting on
<clever> mbrock: i have noticed poor scheduling before, where it will do 2 steps of a build on different slaves, and have to transfer the closure twice, once to each slave
<clever> mbrock: only issue, would be the interuption of something that was in-progress at reboot
<clever> mbrock: so complete loss of the store on a slave has little impact
<clever> mbrock: hydra makes no attempts to track what a slave has previously downloaded and to optimize things around that
<clever> mbrock: you can set a weight for each jobset, and there is a queue within hydra and you can bump some things up
<clever> mbrock: it doesnt involve nix-build at all, but rather, directly calls ssh and talks to the remote nix-daemon
<clever> coconnor: most of mine is in a private repo, but i have slowly been migrating to https://github.com/cleverca22/nixos-configs
<clever> each machine has its own root that it starts at, and all of them include core.nix at some point
<clever> then i just git clone nixcfg, and put a tree of modules in there
<clever> coconnor: similar here, my configuration.nix only contains what is required to make the machine boot, and imports = [ ./nixcfg/amd.nix ];
<clever> ottidmes: then if an OS starts a partition on block 3, and the FS deals with groups of 4 blocks, it will always overlap between 2 hardware blocks, which destroys performance
<clever> ottidmes: when hardware started to go beyond 512 byte blocks, it broke many OS's, so the hardware lies and claims its still 512 bytes
<clever> ottidmes: there is also the fun of finding the block size of the hard-drives
<clever> and can be nested wherever a value is expected
<clever> pie_: both of the above, are equivelant to just a raw value or expression
<clever> pie_: with value; value
<clever> pie_: let foo = bar in value
<clever> yeah
<clever> pie_: with pkgs; [ lyx texmaker texlive.combined.scheme-full ]
<clever> ottidmes: aha, so the system-product-name isnt always accurate
<clever> hakujin: that will tell you how much is in the nix language, and how much is just building
<clever> hakujin: as a test, you can compare how long it takes to nix-instantiate an expression, vs how long it takes to `nix-store -r /nix/store/foo.drv` the derivation it produced
<clever> hakujin: there is also some overhead in nix setting up sandboxes
<clever> ottidmes: sounds like your just on baremetal, so it would be up to either the BMC/IPMI or a physical serial cable
<clever> hakujin: nix has to build ghc1 with ghc2 which was built with ghc3, and it has to eval the closure of every ghc thru nixpkgs
<clever> hakujin: there is also some more layers of overhead in how ghc gets bootstrapped
<clever> pie_: if you can get root, systemctl restart display-manager
<clever> pie_: it has been disabled on some systems
<clever> hakujin: callCabal2nix involves import from derivation, so it has to run cabal2nix every time the source changes, to generate the nix expressions
<clever> pie_: ctrl+alt+backspace is a hotkey in xorg, that just kills xorg
<clever> ottidmes: what does `dmidecode -s system-product-name` say?
<clever> and then the presense of the mysql dataDir will prevent it from happening again in the future
<clever> gilligan_: then after the daemon has started, it checks the the existance of mysql_init, does some one-time stuff, and deletes mysql_init
<clever> gilligan_: if the mysql dataDir doesnt exist before starting the daemon, it creates /tmp/mysql_init
<clever> gilligan_: the /tmp/mysql_init example in here is a bit of a complex one: https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/databases/mysql.nix
<clever> hakujin: builtins.filterSource, or just manually delete them
<clever> ottidmes: that sounds like normal hardware serial, or a VM trying to emulate normal hardware
<clever> hakujin: and thats everything, you didnt exclude anything?
<clever> hakujin: yeah
<clever> ottidmes: in the case of my xen guest, the bulk of the 32 i saw had the same invalid port of 0
<clever> ottidmes: yep, and it also says what IO port each is on
<clever> hakujin: line 28, how big is that directory it refers to?
<clever> ottidmes: and also check `cat /proc/tty/driver/serial`
<clever> the man page shows how to set the name
<clever> pie_: nix-channel --add again, and set the name to nixos, and the url pointing to maybe 17.09
<clever> along with 8 hvc's
<clever> ottidmes: and it claims to have 32 legacy serial ports, lol
<clever> ottidmes: i can see these under drivers, within a xen guest
<clever> hvc /dev/hvc 229 0-7 system
<clever> serial /dev/ttyS 4 64-111 serial
<clever> each driver has its own details page, and drivers lists them all
<clever> ottidmes: `cat /proc/tty/driver/serial` as well
<clever> ottidmes: `cat /proc/tty/drivers` will also reveal what the kernel is using to power that tty
<clever> Lisanna: if the contents of the generated .service file change for any reason, nixos will restart the service
<clever> Lisanna: yeah
<clever> pie_: low level: nix-env --list-generations and nix-env --delete-generations, high level, nix-collect-garbage --delete-older-than
<clever> pie_: `nix-store -qR /run/current-system ~/.nix-profile` would give a list without dups
<clever> pie_: some of the data is shared between those 2, and thats just the current generation
<clever> Lisanna: then depend on the derivation that creates the file
<clever> Lisanna: use pkgs.writeText to write the result of an expression to a file
<clever> pie_: nix-store --query --roots on a given storepath, to see what prevents a GC
<clever> pie_: and keep in mind, that profiles and generations will hold on to everything you think your removing
<clever> pie_: down to 5gig after removing the last thing that depended on ghc
<clever> and when you du them seperately, those shared items get double-counted
<clever> pie_: also, there will be paths shared between nix-env and nixos
<clever> pie_: yeah, /run/current-system
<clever> pie_: 5.3gig now
<clever> pie_: i prefer to have to the haskell stuff in a single expression, so they all upgrade at once and share a ghc, rather then having 20 ghc's
<clever> ottidmes: i think i had also used it when testing things under kexec
<clever> ottidmes: yeah, to debug when it fails to boot
<clever> pie_: moved ycmd to my system packages, total is now 5.4gig
<clever> now how do you get logs?
<clever> ottidmes: and if it fails to boot, you wont get network
<clever> ottidmes: in some cases, the graphics drivers get confused during kexec, so you loose all console access
<clever> then use / to search for the thing and work your way backwards up the tree
<clever> pie_: nix-store -q --tree ~/.nix-profile/
<clever> and |sort causes the total to be last, because its always biggest
<clever> -qR lists all deps recursively, and -c tells du to give a total
<clever> mine ends with this
<clever> 272M /nix/store/6nzb1s93l7rzaa0s6cflnm4hf59fg2ba-clang-4.0.1
<clever> 6.1G total
<clever> 182M /nix/store/zip6rrw80vf1w0xs2958papzxb3kn48n-ghc-8.0.2
<clever> pie_: [clever@amd-nixos:~]$ du --max=0 -h -c $(nix-store -qR ~/.nix-profile) | sort -h
<clever> rnhmjoj[m]: yeah, the selection buffer
<clever> ah
<clever> middle click also acts as paste in nearly every linux application
<clever> left and right adjust the selection
<clever> sahabi: yeah, control is the hotkey for the menu, normal middle click is paste
<clever> and it uses the selection buffer, not the clipboard, so it will paste whatever you have selected
<clever> sahabi: middle click is paste
<clever> it will activate whatever option your pointing at when you release the mouse
<clever> sahabi: hold control and then hold left, right, or middle click
<clever> __red__: i always point the document root to a derivation

2018-01-30

<clever> and you dont even have a /lib
<clever> lexwho: most of the time, buildFHSUserEnv is the wrong tool to solve a problem
<clever> i'm not sure where else that error could be coming from
<clever> add-hardening.sh is what sets it
<clever> nextos: the gcc wrapper just obeys it
<clever> nextos: what does echo $hardeningCFlags say?
<clever> nextos: oh, because its called hardeningDisable, lol
<clever> github search is being derpy and finding all but the most important reference to it
<clever> nextos: disableHardening has to be set to a special string
<clever> nextos: one min
<clever> jack[m]: the biggest benefit of that method, is that you can audit your expressions, by confirming they build with NIX_PATH unset, then you know that you dont care what the value is in the future

2018-01-29

<clever> adelbertc: i think its launchctl start something.something.something
<clever> manualy restart it with launchctl
<clever> dhess: load the release.nix in nix-repl and see what it returns
<clever> freeman42x: thats inside pkgs
<clever> freeman42x: haskell.lib.doJailbreak
<clever> vaibhavsagar: also check the ~/.nix-defexpr/ symlink
<clever> sure
<clever> was up to +4c outside this afternoon, but its already gotten pretty chilly
<clever> "2018-01-28 23:54:20 bedroom temp: 21.44c(70.59f), kitchen: 19.12c(66.43f), living room: 18.44c(65.19f), outdoor: -7.56c(18.39f), server: 21.56c(70.81f) VCC: over 4.5 volts portb: 00000000"
<clever> i find a lot of americans thinking that the entire continent ends at their shore line, lol
<clever> its 11:52 pm here

2018-01-28

<clever> Rovanion: reprogramming a keyboard?
<clever> chisui: isNormalUser sets it for you
<clever> chisui: oh, and you dont have to set the home directory in the config
<clever> so nobody can ever change their own password
<clever> one thing to note, is that if you set mutableUsers=false;, it will reset the password of every user at bootup, to match the config file
<clever> i think its mostly user preference, ive just never bothered to change it
<clever> yeah, that should work
<clever> chisui: youll need to either disable mutableUsers, or manualy set the password with passwd
<clever> chisui: but since the user is pre-existing, its defering to the existing password hash
<clever> chisui: if you had the hashedPassword in the config before the user had been made, it would have taken effect
<clever> chisui: one min
<clever> Rovanion: try adding avrlibc to the buildInputs
<clever> Rovanion: nix-build '<nixpkgs>' -A avrlibc
<clever> «derivation /nix/store/i393apa64vfd46ni8fc7bkkn2y5a4zb9-avr-libc-2.0.0.drv»
<clever> nix-repl> avrlibc
<clever> the cross-compile may add things
<clever> and also via running `env` around postInstall
<clever> bgamari: if you eval it in nix-repl, can you confirm the presense of that attribute?
<clever> bgamari: ah, so the setupHook attribute was defined on the derivation, and its trying to create $out/nix-support/setup-hook, for future sourcing
<clever> bgamari: can you gist the derivation that is having this failure?
<clever> bgamari: i think only for setup hooks will the stdenv source things
<clever> bgamari: so you need to ensure you dont have those if $out is a file
<clever> bgamari: propagated build inputs work via $out/nix-support/something
<clever> very rarely will it be a file
<clever> macslayer: fonts cant just be installed, they have to be added to a font option
<clever> bgamari: try running "set -x" in the postInstall region
<clever> bgamari: that sounds like it failed after the build finished
<clever> bgamari: can you paste the error here?
<clever> fresheyeball: try executableSystemDepends or librarySystemDepends ?
<clever> yeah
<clever> GiGa|Laptop: look at line 19 and 21 of your pastebin
<clever> GiGa|Laptop: one of the patches doesnt apply to the source anymore
<clever> GiGa|Laptop: the yep was aimed at mlin
<clever> CapsAdmin: then use the nix that nix built from then onwards
<clever> CapsAdmin: i would usually only use such nix once, to nix-env -iA nixpkgs.nix
<clever> yep
<clever> mlin: your /boot is read-only, the bootloader reads the kernel and boots, but the OS never touches /boot
<clever> nixos-generate-config will regenerate hardware-configuration.nix based on what is currently mounted
<clever> mlin: youll want to manualy mount it, and fix your config, then nixos-rebuild switch
<clever> mlin: yeah
<clever> mlin: is it listed when you run `mount` ?
<clever> mlin: double-check that /boot is mounted before the nixos-rebuild
<clever> mlin: changes being reverted like that can happen if /boot is mounted
<clever> mlin: is /boot mounted correctly?
<clever> glines: neat
<clever> glines: check --list both with and without root
<clever> GiGa|Laptop: buildDotnetPackage.override { mono = mono50; }
<clever> glines: there is also a nix-channel --remove
<clever> and it does accept mono as an argument
<clever> buildDotnetPackage = callPackage ../build-support/build-dotnet-package { };
<clever> nix-repl> builtins.unsafeGetAttrPos "buildDotnetPackage" pkgs
<clever> { column = 3; file = "/home/clever/apps/nixpkgs/pkgs/top-level/all-packages.nix"; line = 280; }
<clever> i cant find it in the top-level of nixpkgs
<clever> and i think that only works for channels root has added
<clever> the name from `nix-channel --list`
<clever> glines: put the channel name between the < and >
<clever> and it cant delete half a file
<clever> boomshroom: it probably deleted a single file, that was 4gig
<clever> boomshroom: nix-collect-garbage --max-freed 1 will tell it to stop after deleting 1 byte
<clever> boomshroom: yeah, nix will gc the dead links at the start of any gc
<clever> that will show symlinks pointing to ever result you have forgoten about
<clever> palo: you can also: ls -lh /nix/var/nix/gcroots/auto/
<clever> palo: that is how nix deduplicates things
<clever> gnome3.gtk.out 1,166,488 x /nix/store/rqsnb5fv5rwkih74ygb5ar092p82wcl9-gtk+3-3.22.11/lib/libgdk-3.so.0.2200.11
<clever> nix-locate libgdk-3
<clever> yeah, deleting that symlink will let it GC some more things
<clever> there should also be some numbered entries
<clever> those cant be GC'd
<clever> palo: what differs between each of them?
<clever> palo: run nix-store --query --roots on each path to intellij
<clever> havent tried much yet
<clever> yeah
<clever> we could try building it ourselves
<clever> erlandsona: that could work
<clever> petersjt014[m]: not that i know of
<clever> or config.hardware
<clever> so now you can narrow it in some, like config.fileSystems
<clever> petersjt014[m]: yeah, thats the entire config tree for nixos
<clever> petersjt014[m]: just type config with nothing else
<clever> petersjt014[m]: then just eval config in the repl and youll see every config option in all of nixos
<clever> petersjt014[m]: what do you want to do with that nixos config?
<clever> erlandsona: its not attempting to link against gtk, thats the weird part
<clever> boomshroom: dont know
<clever> petersjt014[m]: you can also just spam tab
<clever> petersjt014[m]: try to eval config and options, i believe those are 2 of the main ones it adds
<clever> petersjt014[m]: that loads all of nixos, which loads the configuration.nix to configure itself
<clever> petersjt014[m]: instead fo :l <nixpkgs/nixos>
<clever> erlandsona: yeah, thats next on our todo list
<clever> the puzzling part, is that it refers to a gdk symbol, but doesnt link to any gdk libs
<clever> ./result/bin/reaper5: symbol lookup error: /nix/store/0xkvp0ngxxr46psic51fp84aqynk362c-reaper/bin/libSwell.so: undefined symbol: gdk_init_check
<clever> dontStrip fixes the above error
<clever> ./result/bin/reaper5: ./result/bin/reaper5: no version information available (required by ./result/bin/reaper5)
<clever> erlandsona: i can just throw it into a gist when i'm done
<clever> /nix/store/j4vcckdcbim2qqyr0kjw9dcvlcm9as12-reaper-derivation/reaper5: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory
<clever> but that doesnt include the contents of the reaper bash script
<clever> erlandsona: you dont need to use a builder.sh, pkgs.runCommand would do the same thing
<clever> erlandsona: can you gist that bash script?
<clever> erlandsona: if you run `file` on reapter5, what does it say?

2018-01-27

<clever> nice
<clever> x86_64-unknown-linux-gnu
<clever> boomshroom: gcc has clever@c2d ~ $ gcc -dumpmachine
<clever> something is broken
<clever> cinimod: there is no libmariadb.2.dylib in that directory
<clever> [clever@amd-nixos:~]$ ls -lh /nix/store/wbbxlsnyp1vpwj7rp9d0l0m4d4z425gl-mariadb-connector-c-2.3.4/lib/
<clever> cinimod: i'm guessing that rgdal is just failing to build
<clever> cinimod: can you add the default.nix file to that?
<clever> cinimod: can you gist that as well?
<clever> cinimod: is there a default.nix or shell.nix file in that directory?
<clever> cinimod: you didnt tell nix-shell what to load, so its probably trying to build every single package in the universe
<clever> and thats just what is in the house
<clever> 3 servers, 1 desktop, 1 laptop, plus a laptop i no longer use but it works and has nixos
<clever> srhb: it takes me a while to count them too :P
<clever> GNU ld (GNU Binutils) 2.23.51.20121030 has -z in the man page
<clever> CapsAdmin: -z accepts another argument, that tells ld to do something
<clever> and more