2017-03-07

<clever> smw_: one sec
<clever> probably
<clever> systemd.services.<name>.wants = [ "anotherService.service" ];
<clever> needs to be set to a string, not an attribute path
<clever> :)
<clever> had them backwards
<clever> oh, extraUsers is the alias
<clever> joncfoo: probably just add it to the user for that serivce, users.extraUsers.foo.extraGroups
<clever> and since my current machine cant do v7, it automaticaly farms it out to a v7 slave i configured in configuration.nix
<clever> but the --argstr system above, forces it to build for armv7
<clever> by default, nix will try to build for the arch the nix-build was compiled against
<clever> smw_: with this, i can do the bulk of the editing and caching on an x86 machine, and it will only use the arm to do the builds
<clever> copying 99 missing paths (44.58 MiB) to ‘builder@192.168.2.126’...
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ nix-build nixos/default.nix -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix --argstr system "armv7l-linux"
<clever> smw_: maybe
<clever> not that they would build on arm, lol
<clever> so you can just do boot.kernelPackages.nvidia_x11 to get the nvidia drivers for the current kernel
<clever> smw_: creating an attribute set with every driver package, built against the right kernel
<clever> smw_: linuxPackagesFor is a function that takes a kernel, and then runs all of the driver packages against it
<clever> ndowens08: and maybe the hashing algo
<clever> these paths will be fetched (166.50 MiB download, 1017.98 MiB unpacked):
<clever> smw_: and its getting a decent number of things from my hydra
<clever> joncfoo: my acme stuff is a lot more verbose, though i also am using it via nginx
<clever> smw_: so i will need a v7 slave configured in nix.buildMachines
<clever> smw_: i am testing it with this command, which will force armv7, even though i'm running it on an x86 box
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ nix-build nixos/default.nix -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix --argstr system "armv7l-linux"
<clever> smw_: it needs an attrset containing a kernel and modules built against that kernel
<clever> joncfoo: what about just "journalctl -f -n 2000"
<clever> smw_: i'll need to test it on this end and see what i can find
<clever> joncfoo: try the .service variant of that unit
<clever> ah
<clever> smw_: then it would still be using the non-rpi kernel
<clever> smw_: can you pastebin the output of "git diff" in your nixpkgs copy?
<clever> smw_: i'm thinking edit sd-image-armv7l-multiplatform.nix and change the kernelPackages = line to use the rpi kernel
<clever> smw_: aarch64 is less likely to work, it has a lot more kinks to work out
<clever> smw_: ah
<clever> smw_: i see a sd-image-raspberrypi.nix in the same directory
<clever> smw_: and the name alone implies its a generic arm image, for any arm device
<clever> smw_: you are currently building from nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix
<clever> smw_: vchiq is to do with the gpu side of the rpi
<clever> smw_: and it even lists the rpi in the dmesg output
<clever> [ 5.292996] raspberrypi-firmware soc:firmware: Attached to firmware from 2016-10-20 14:57
<clever> smw_: though this like is related to broadcom features
<clever> [ 5.320734] vchiq: vchiq_init_state: slot_zero = f0b2f000, is_master = 0
<clever> smw_: so you have no usb driver, and no SD card driver
<clever> smw_: its sounding like all of the raspberry pi specific hardware is missing drivers
<clever> smw_: yep
<clever> boot.shell_on_fail will give more options at the menu in the pastebin
<clever> smw_: you can just edit the bootloader config file
<clever> no
<clever> boot.shell_on_fail
<clever> smw_: add "boot.allow_shell" to the kernel args i believe
<clever> but i retired them because they where so slow
<clever> it was the armv6 models that i ran proper nixos on
<clever> but i did run not-os on it at one point
<clever> i havent ran nixos on it yet
<clever> smw_: one of them is an rpi3
<clever> i already have 4 pi's
<clever> lol
<clever> smw_: yeah
<clever> smw_: so any change to the nixpkgs causes the image to be rebuilt
<clever> smw_: oh, and one weird thing with stuff like the sdImage, it contains a complete copy of the nixpkgs it was built from
<clever> smw_: they get the config attrset from nixpkgs.config, within configuration.nix
<clever> smw_: and also, nixos builds generaly ignore config.nix
<clever> smw_: yeah
<clever> smw_: dont think that would have done it
<clever> smw_: so it wont have much effect in ~/.nixpkgs/config.nix
<clever> smw_: i believe the platform stuff mainly effects the kernel build options
<clever> yeah, that sounds like a good plan
<clever> smw_: ah
<clever> smw_: i believe you said you got some kernel output on the serial console?
<clever> smw_: one of the ones you pasted above was working before, so it should work again when tried on its own
<clever> you just need to set console= right, and the panic should go over the serial line
<clever> this is also a good sign, because it even sent the panic message there
<clever> smw_: it output only to the serial port you listed, which wasnt the right one
<clever> smw_: you didnt put in console=tty0, so it didnt output to the gpu
<clever> smw_: try a different console= value then
<clever> and if it was already working with that flag before, then you can kep it
<clever> that sets the baud rate and number of bits per byte
<clever> yeah, the miniuart took over, after the bluetooth stole the main uart
<clever> ah
<clever> smw_: thats where the serial port lands on x86
<clever> nekroze: all of the nixos testing does use 9p to mount /nix/store from the host->guest
<clever> smw_: so try cutting it down to just console=ttyAMA0,115200n8
<clever> smw_: the panic may also go to the last console= listed
<clever> nekroze: ah
<clever> smw_: and the last one listed is where the shell lands, so it might actualy be booting fine, and dropping a shell on the wrong tty
<clever> smw_: i think you have a few too many console='s on there, try finding just 1 that will output everything to the serial port
<clever> nekroze: this code makes 4 testcases, that nixos will automaticaly run under qemu vm's and show the status of on hydra
<clever> nekroze: i'm mainly using it to boot a configuration.nix under qemu and run some basic tests against it
<clever> smw_: is console= set in the kernel arguments?
<clever> and the 17.03 channel currently fails to even unpack my source, need to look into why
<clever> nekroze: so now hydra is testing against both channels
<clever> nekroze: i recently setup hydra to test my stuff against 16.09, and when 17.03 came out, i just cloned the entire jobset
<clever> gchristensen: ah, that email explains why somebody lost sudo a week ago

2017-03-06

<clever> ali1234: nix builds always lack root, but it can fire up a qemu vm for cases when it does need to edit a filesystem image
<clever> ali1234: and if root configures qemu-user-arm ahead of time, it can just run the arm compiler in nix builds
<clever> ali1234: with how nix works, it doesnt need fakeroot or fakechroot
<clever> dtzWill: the code expects the builder to be -9'd and not have any more output
<clever> dtzWill: its happening after nix-build has been ctrl+c'd
<clever> gchristensen: yeah
<clever> and nix normaly keeps things in a sandbox, so the rm -rf will clean it up anyways
<clever> it would need to term, sleep 30, then kill
<clever> anelson_: and the rest is just to keep any naughty programs from ignoring sigterm, and sticking around eating resources
<clever> anelson_: part of it, is that one of these killUser passes, is meant to sterilize the nixbld1 user, before a build starts, so you can prevent impurities from the last build under that user
<clever> nice
<clever> anelson_: for it to impact nix-daemon, it will have to be an override within configuration.nix
<clever> anelson_: and here is how you can apply a patch to nix easily
<clever> yeah
<clever> anelson_: there is a second spot you will need to patch also
<clever> anelson_: it appears to be a mix of killing everything under the build user, and killing the initial child nix made
<clever> but i can see the use in having it auto-upload
<clever> i would have just built them as an img file localy, along with a bash script that initiates the upload
<clever> anelson_: most of nix expects the builds to be contained and not have network access, so an rm -rf $NIX_BUILD_TOP would be enough to clean it up
<clever> anelson_: in the daemon case, you could connect to the daemon over localhost + tcp, and if the tcp link is lost at any point, kill all vm's!
<clever> anelson_: only thing i can think of, is to either route it thru a daemon that will cleanup automaticaly, or to configure the machines to shutdown after 1 hour
<clever> anelson_: what kind of resources is it allocating, that you want to clean up?
<clever> copumpkin: and i was upgrading it to nixos without any removable media
<clever> copumpkin: in my case, i started with half a gentoo install, that included a 2015 build of nix, that couldnt parse nixpkgs
<clever> i manualy changed things with sqlite3
<clever> copumpkin: ah, that github issue looks like a better way to fix it
<clever> Baughn: i have manualy downgraded the db before, and can help with that
<clever> niksnut: ah, and it sounds like it accepts things in the same format as NIX_REMOTE and the copy command
<clever> niksnut: what is the new API to configure substituters?
<clever> copumpkin: from what i saw in the source, yeah
<clever> niksnut: ah, and that syntax would involve "local?root=/" i'm guessing?
<clever> niksnut: and if your doing a build under /mnt/nix/store, does it know enough to copy from /nix/store?
<clever> niksnut: ah, looks simple enough, i'll have to try that next time i get a chance
<clever> niksnut: ah nice, and what about realizing a derivation within that new root?
<clever> niksnut: is there a similar command to copy from /nix/store to /mnt/nix/store ?
<clever> ive seen evidence in the code that it can do that, but not how to trigger it
<clever> shlevy: oh, do you know how to make the new nix write to a store store at /mnt/nix/store/ ?
<clever> Dezgeg: now that i know about self, the fix is easy, but i'll need time to compile the kernel
<clever> i'll fix the expression and test again
<clever> yeah
<clever> Dezgeg: the repl did unstable, but the configuration.nix was 16.09
<clever> Dezgeg: the api for this function differs between unstable and 16.09
<clever> 11290 linuxPackagesFor = kernel: lib.makeExtensible (self: with self; {
<clever> 11329 linuxPackagesFor = kernel: self: let callPackage = newScope self; in rec {
<clever> Dezgeg: i think i see the problem
<clever> error: value is a function while a set was expected, at /home/clever/nixpkgs/nixos/modules/tasks/cpu-freq.nix:6:14
<clever> Dezgeg: hmmm, the above expression works when put into nix-repl, but not in a configuration.nix
<clever> Dezgeg: hmmm, typo somewhere, *investigates*
<clever> Dezgeg: boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux.overrideDerivation (oldAttr: { patches = oldAttr.patches ++ [ ./fs-9p-Compare-qid.path-in-v9fs_test_inode.patch ]; }));
<clever> Dezgeg: applied to the host or guest kernel, looks like guest at a glance
<clever> Dezgeg: these zfs + 9p bugs are getting pretty anoying
<clever> server# [ 22.025044] systemd[1134]: mongodb.service: Failed at step EXEC spawning /nix/store/6akfivwijc51a6c767kmaq6l1dm9cy7i-mongodb-3.2.9/bin/mongod: No such file or directory
<clever> joneshf-laptop: shellHook = "source ${./foo.sh}";
<clever> bennofs1: raw hydra serves the nars at exactly their storepath, nix-serve i believe serves them at the hash from the storepath, and nix-push serves the nars at the hash of the nar contents
<clever> bennofs1: the nar path depends on the binary cache server
<clever> copumpkin: that sounds like S3 again
<clever> copumpkin: 404 on what?, 404's are normal for some things
<clever> avn: but i do have a nix expression to get a vnc server with full de/dm support
<clever> avn: cant see any obvious cause of recursion
<clever> avn: can you pastebin your source?
<clever> whichever you prefer
<clever> or /media

2017-03-05

<clever> and you have now created the very problem nix was meant to solve
<clever> but i cant just nix-env -i it, because those things conflict with other versions of kde utils
<clever> for example, kdenlive refuses to work until installed, because it expects things to be installed into your profile
<clever> there is another attr for that, but i avoid using it whenever possible
<clever> it doesnt show up at the final runtime that faces the "end user"
<clever> propagatedBuildInputs is only propagated to other builds
<clever> its been there since i started using nixos
<clever> in the journalctl man page
<clever> --vacuum-size=, --vacuum-time=, --vacuum-files=
<clever> so it always does what i wanted
<clever> and when updating, it can apply the changes to the new version
<clever> with nix, i describe the changes in a config file, and then all nix commands can apply those changes to things
<clever> it cant copy with files i never modified having minor changes done to them
<clever> i always found etc-update to be too dumb
<clever> the buildEnv method is also atomic
<clever> and it upgrades all of my things at once
<clever> yeah, i generaly make a buildEnv, so i can nix-env -iA nixos.mystuff
<clever> with your way, you can forget it came from master, and your next nix-env -u foo, will downgrade to the 16.09 version
<clever> so it can be rebuilt again in the future without having to track it down
<clever> i copy that nix file to ~/.nixpkgs/
<clever> its 1 line of code
<clever> foo = pkgs.callPackage ./foo.nix {};
<clever> viric: just add those to packageOverrides in ~/.nixpkgs/config.nix
<clever> viric: do you actualy want to install that, or just build it for testing/debug?
<clever> viric: i think nix-env expects a name or attribute, and gets upset when you dont supply one
<clever> that is what nix-env does
<clever> lorilan: nix-env will never list things installed via environment.systemPackages
<clever> ben: environment.systemPackages stuff always lands in /run/current-system/sw/bin/ which is already in $PATH
<clever> avn: LD_LIBRARY_PATH and makeWrapper are more likely to stick and get the job done
<clever> avn: i think dlopen() will search the rpath, but the fixup phase will delete that lib folder on you, because its not flagged as being needed
<clever> lorilan: the switch sub-command will switch to that new config for you, no need to reboot
<clever> and the 2nd one will tell you how to enable unfree if you dont have it on
<clever> lorilan: nix-env -iA nixos.google-chrome will give you the blob that google has pre-built
<clever> lorilan: nix-env -iA nixos.chromium will give you the fully open source build of chrome
<clever> lorilan: and nixos has 2 builds of chrome
<clever> lorilan: the package search wont show unfree packages until you enable unfree packages
<clever> 2016-12-14 18:46:18< LnL> gchristensen: nixpkgs manual is pretty simple nix-build '<nixpkgs/doc>'
<clever> 2017-02-23 22:07:31< clever> nix-build '<nixpkgs/doc>'
<clever> c0bw3b: i think its this systemd unit that actualy runs it
<clever> c0bw3b: i think its limited to anything not marked as "unfree"
<clever> nope, one min
<clever> so the software is now useless
<clever> and the most recent update cant render buttons of nixos
<clever> the servers also block all old versions from working
<clever> so this problem happens every ~2 months, on the most recent version of nixpkgs
<clever> as an example, teamviewer deletes old versions every time they make a release
<clever> depends on the source mirror
<clever> and if the old source is gone from its mirrors, your in trouble!
<clever> one minor issue with trying to build older nixpkgs revisions though, is that if its not in the binary cache, you need to download the old source
<clever> so nix cant cheat and build the missing stuff without you noticing
<clever> and another neat thing, the above command only works if that exact build is in cache.nixos.org
<clever> c0bw3b: the above command will download the exact build my nixpkgs references, and you dont need a copy of nixpkgs to do that
<clever> c0bw3b: nix-store -r /nix/store/7bqd18jfn63pqkcs78lcas5mcp10vmpy-hello-2.10
<clever> but you can also skip a few steps, and just directly go to the binary cache
<clever> as long as S3/AWS hasnt lost the data
<clever> c0bw3b: so if you save the attribute path and the revision of nixpkgs, you can re-download that package again at any point in the future
<clever> c0bw3b: so if you just grab a random commit from git, there is a chance hydra hasnt built it, and it wont be in the cache
<clever> c0bw3b: the channels are part of it, only something released in a channel is going to have been built fully by hydra
<clever> c0bw3b: also keep in mind, you can only compute the hash to download from cache.nixos.org if you use the old nixpkgs that the package was originaly in
<clever> hence the quotes
<clever> yeah
<clever> c0bw3b: i dont think the cache has ANY garbage collection on it, so the answer is currently "forever"
<clever> fuzzy_id: which works the same as config.nix's packageOverrides
<clever> fuzzy_id: set it in nixpkgs.config.packageOverrides
<clever> they have pretty much re-invented configure with makefile rules
<clever> it looks like it will only enable lua if it has a lua_inc path
<clever> ah
<clever> makefiles can do similar logic
<clever> ah
<clever> so even if gcc can find the headers, configure claims its not found
<clever> some configure scripts will try to look in /usr/include/lua.h, rather then just blindly checking of #include <lua.h> compiles
<clever> LUA_LIB_NAME=liblua can probably also go
<clever> since nixpkgs already adds them to the -L and -I paths
<clever> these are probably not needed
<clever> LUA_LIB=\${pkgs.lua5_3}/lib LUA_INC=\${pkgs.lua5_3}/include\"
<clever> and the only storepath i had to specify directly was ${out}
<clever> no configure, no automake, no cmake
<clever> fuzzy_id: i recently made a lua based program using just "buildInputs = [ protobuf libressl lua libevent ];" and " -lssl -lprotobuf -llua -levent_pthreads -levent -levent_openssl"
<clever> fuzzy_id: gcc will always add lib and .so to the name you give it
<clever> fuzzy_id: the argument is -llua
<clever> have you played with nix-repl before?
<clever> you would need something like nix-repl to keep the files loaded in ram
<clever> yeah
<clever> but using it directly lets you inspect any attribute of any set
<clever> MoreTea: this is the internals behind how hello.meta.position works
<clever> nix-repl> builtins.unsafeGetAttrPos "hello" pkgs
<clever> { column = 3; file = "/nix/store/f9bca2pbyya9iqcj3vzrn717zxs22m6l-nixos-16.09.1698.2da8a5d/nixos/pkgs/top-level/all-packages.nix"; line = 13535; }
<clever> MoreTea: have you seen builtins.unsafeGetAttrPos ?
<clever> MoreTea: neat
<clever> qknight: also, "man configuration.nix" shows all options for the nix channel you built against
<clever> i should automate that, and provide links for every channel
<clever> i had made a more up to date version of options.html for master, but i havent updated it in ages

2017-03-04

<clever> gwlan: cant see anything obvious as to why its broken, and its getting late here
<clever> gwlan: heading off to bed now
<clever> gwlan: and the full error
<clever> gwlan: can you pastebin the configuration.nix?
<clever> Mateon1: from one of your previous pastebins
<clever> Mar 04 23:17:04 hydra X[3082]: (++) Using config file: "/nix/store/aqcgdqm1z8lnnl6yqx30mxq7gi7wc4y6-xserver.conf"
<clever> gwlan: all of those symlinks are absolute, and refer to the other /nix/store, so they wont resolve right until you chroot or manualy resolve them in your head
<clever> ah
<clever> there are pre-made virtualbox images available for download
<clever> or a local vm
<clever> smw_: maybe you should start with a normal x86 machine you have physical access to?
<clever> Mateon1: if you post your backtrace and some config details, the sddm guys can probably find the problem better
<clever> Mateon1: last comment is a person claiming ABI problems, but nix cant really have those
<clever> Mateon1: or just search the issue list, lol: https://github.com/sddm/sddm/issues/599
<clever> and at this point, its easyer to edit sddm to just print the debug info out on its own
<clever> those mapnodebase's need to be cast to mapnode to see the .key
<clever> it looks like a tree at a glance
<clever> Mateon1: ah, i guessed wrong, left and right are more nodes
<clever> which is on line 205
<clever> Mateon1: d is an instance of the QMapData template
<clever> Mateon1: to the qt source!
<clever> wait, thats p=0, hmmm
<clever> Mateon1: those numbers look more sane, size is 4, and the head of the list has left=0
<clever> an entry with left=2
<clever> and then you would need to somehow navigate the internals of QMap to find the entry with a key of 2
<clever> Mateon1: most QT objects have a d pointer, for shared state between copy-on-write clones, and its just a normal pointer, not an array
<clever> Mateon1: though i dont think d works like that, i think you want helpers.d[0]
<clever> ah nice
<clever> so the only option left is to either start modifying the source, or pick a different display manager
<clever> ah
<clever> Mateon1: are you able to ssh into the machine before sddm crashes, from a 2nd box?
<clever> doesnt really say much
<clever> Mateon1: what about just "print helpers"
<clever> Mateon1: ah, its a QMap, so it cant use [] with the app dead
<clever> Mateon1: in gdb, what happens if you type in "frame 2" and then "print helpers[2]
<clever> up next, some source for context