<clever>
nixos-unstable correctly refused to update, and protected those users
<clever>
NinjaTrappeur: there was a wave of people a few years back that just lost the ability to boot, because nixpkgs-unstable broke the grub config file
<clever>
NinjaTrappeur: the nixos services arent tested when updating that channel
<clever>
check the nix-channel man page
<clever>
you have to give nix-channel --add the name "nixos" to overwrite the 17.09
<clever>
xmr-nixos-user: nixos is still running from the 17.09 channel, which is from last year
<clever>
xmr-nixos-user: also, check nix-channel --list again as root
<clever>
xmr-nixos-user: you must never run nixos from the nixpkgs-unstable channel
<clever>
nope
<clever>
you need to use the --include or --exclude flag to stop it from trying to talk to a machine thats offline
<clever>
nixops generates that and inserts it for you
<clever>
correct
<clever>
i think nixops will also manage booting and the IP for you then, so you dont need to be as careful with getting the config right the first time
<clever>
yeah
<clever>
enless you dont mind just destroying it now and letting nixops remake the whole thing
<clever>
so its simpler to just set the targetEnv to none, and manage the destruction yourself, whenever that comes up
<clever>
but there is no way to tell nixops to adopt something that youve already created
<clever>
ixxie: and nixops will manage creation, deployment, and destruction
<clever>
ixxie: for proper DO stuff, you set the backend to the keyname for DO, and leave it
<clever>
ixxie: the 3 examples i linked all use none, just give it an ip and it will assume control of the machine
<clever>
ixxie: if you want to reuse an existing instance, ignore the digitalocean directions, and instead use the none backend
<clever>
but you may want to isolate it from updates that happen to the local machine
<clever>
ixxie: it will use the local <nixpkgs> by default
<clever>
i believe that was the trick
<clever>
nixops set-args -d name -I nixpkgs=https://github.com/nixos/nixpkgs/archive/8bce347f02f6bd606ec1822f0ba9b94d7f139071.tar.gz
<clever>
ixxie: and if you want to control the nixpkgs nixops uses
<clever>
ixxie: those should already have it
<clever>
ixxie: you want to copy the existing configuration.nix and hardware-configuration.nix the machine is already using
<clever>
ixxie: and for digital ocean, you have to configure the static ip properly
<clever>
ixxie: the key thing to keep in mind, is that you have to properly define the boot and fileSystems stuff at a minimum, so whatever nixops creates can still boot
<clever>
ixxie: all 3 of those systems where converted from normal nixos-rebuild to nixops
<clever>
ive used nixops to manage 2 netbooks that dont have enough free disk space to build themselves
<clever>
yeah
<clever>
ixxie: some parts still have to run on the droplet, even with remote builds
<clever>
ixxie: also, it depends on which part of nix is running out of memory
<clever>
softinio: ah, not sure then
<clever>
and nix-store -r to build them
<clever>
ixxie: you can use nix-copy-closure to copy .drv files to another machine
<clever>
ixxie: your welcome
<clever>
softinio: compare $TERM with ssh and mosh
<clever>
softinio: its more likely that the old env vars that mosh is resuming may be to blame
<clever>
$TERM should match whatever you have at the client end
<clever>
softinio: ssh doesnt change the type of your terminal emulator
<clever>
softinio: what terminal are you using?
<clever>
somebody set off the matrix bomb
<clever>
jluttine: look at the lines containing execve, those have the args passed to ssh
<clever>
jluttine: so it will only work if you nix-copy-closure the exact build to the remote machine
<clever>
jluttine: and nixpkgs has patched an absolute path into the script
<clever>
jluttine: i think i see the problem, the script is trying to run itself on the remote machine, via ssh
<clever>
ixxie: yeah
<clever>
jluttine: once more, but with strace -f
<clever>
as long as it doesnt conflict with any existing things
<clever>
ixxie: pretty much
<clever>
Ankhers: it will resize itself automatically when you reboot
<clever>
Ankhers: it doesnt set PATH properly, but the default aws config for nixos runs it automatically in the initrd, so you dont really have to touch it directly
<clever>
jluttine: try running it under strace, and then pastebin the output
<clever>
jluttine: diskrsync appears to just be a bash script, not an executable
<clever>
jluttine: and what is it failing to find when running?
<clever>
jluttine: and was the binary built with nix-shell or nix-build?
<clever>
jluttine: what does `file` say when ran against the binary?
<clever>
that should reveal if the change is spreading too deep into the tree
<clever>
angerman: try doing nix-instantiate on the expression you have, tweak the generic-builder.nix, nix-instantiate again, then nix-diff the 2 .drv files
<clever>
angerman: have you played with nix-diff yet?
<clever>
it probably just got overlooked, try poking gchristensen or someone else in here
<clever>
yrashk: builtins.derivation is a fairly special function, that will hash its inputs and compute an output path
<clever>
yrashk: not sure, youd have to ask somebody that has merge prmission
<clever>
yrashk: generally, you define a function in the same file, then call it twice, to produce the 2 packages
<clever>
angerman: but thats still far better then all of ghc
<clever>
angerman: it will still rebuild 2 haskell packages, hscolour and one other, on every iteration
<clever>
let me grab an example of a cleaner way to do it
<clever>
ah, i see, the defaults
<clever>
yrashk: i think you can merge most of default.nix into apeclex.nix
<clever>
ixxie: now you can run passwd to change the root password
<clever>
ixxie: tell it to continue when it claims the file doesnt exist
<clever>
ixxie: hit e while in grub and selecting a menu entry
<clever>
ixxie: edit the cmdline in grub to have init=/bin/sh
<clever>
das_j: activation scripts are the worst place, never do anything network there
<clever>
das_j: i think the acme scripts in nixos just run daily, and then internally check how old the cert is and abort
<clever>
and you cant just wait for the timer to start it?
<clever>
restartTriggers has nothing to do with timers
<clever>
so when the config file is changed, the service file changes, and it triggers a restart
<clever>
so the trick, is to make it a storepath pointing to a config file the service reads
<clever>
and if the .service file changes for any reason, nixos-rebuild will restart the service
<clever>
the field is essentialy ignored by everything, but it winds up in the .service file
<clever>
restartTriggers can be any string
<clever>
kisik21: no clue
<clever>
the last game i tried was slightly buggy, it had been modified to integrate into steam achivements, and caused errors when running on an un-modified renpy
<clever>
kisik21: i think you just run renpy and give it the path to the game
<clever>
kisik21: probably
<clever>
Myrl-sak1: yes, but your better off delting the duplicate
<clever>
kisik21: nix-env -iA nixos.renpy
<clever>
!-iA
<clever>
kisik21: what args did you run nix-env with?
<clever>
Myrl-sak1: you have 2 copies of nixpkgs, delete the one on the pi user
<clever>
Myrl-sak1: and root?
<clever>
Myrl-sak1: what does nix-channel --list show as each user?
<clever>
kisik21: renpy
<clever>
Myrl-sak1: nix-env uses ~/.nix-defexpr/ but nix-shell uses $NIX_PATH
<clever>
Myrl-sak1: with what args?
<clever>
kisik21: renpy is also packaged in nixpkgs
<clever>
kisik21: does xterm work in the same chroot?
<clever>
i was thinking, nix-store --query --derirver to find the .drv of a path, then check for a .debug output, and nix-store -r to fetch, then just add it to the search path
<clever>
i was thinking of something simpler then dwarffs
<clever>
ah
<clever>
that might be the thing i saw gdb loading, havent read its source yet
<clever>
you may also have better luck creating a buildEnv that has the right outputs, and then install it
<clever>
so it may be possible to auto-fetch the debug from the cache
<clever>
it looks like gdb is already loading python code it finds in the debug dirs
<clever>
sphalerite: i also noticed gdb is running nix via a .py file somewhere in glibc i think
<clever>
sphalerite: i think you where asking about how to get gdb to find things before
<clever>
steveeJ: i never actually wrote that part, its just a hard-coded switch-case
<clever>
phry: but my kexec trick boots a full nixos in ram, and then your free to nuke the disk from orbit and partition it however you like
<clever>
phry: basically, all nixos-in-place does is rename everything in /, populate /nix/store with a copy of nixos, and overwrite the bootloader
<clever>
phry: the main limitation, is that you cant change the partition layout
<clever>
phry: nixos-in-place is based on how i had forcibly converted a gentoo netbook into nixos
<clever>
steveeJ: and then i repurposed pieces of it for installing to the new laptop
<clever>
steveeJ: justdoit+kexec was written mainly for installing to remote servers in datacenters
<clever>
steveeJ: uefi on sata, and also 2 for nvme
<clever>
steveeJ: there are entries in release.nix for legacy on sata, with and without luks
<clever>
steveeJ: and after you install and shutdown, ./result/bin/qemu_test2 to boot the hdd without the generated kernel+initrd, to confirm the install can boot
<clever>
steveeJ: also, you can `nix-build release.nix -A luks_legacy` then ./result/bin/qemu_test1 to boot the generated kernel+initrd under qemu for testing justdoit
<clever>
steveeJ: but if you check the luks man pages, that can probably be automated
<clever>
steveeJ: yeah, if you want luks, somebody has to type it on the console
<clever>
(line 57)
<clever>
which is why the WAN interface is pointing at a wifi card
<clever>
steveeJ: my original use-case for netboot_server.nix, was to turn my old laptop into a complete router and netboot server, which would forcibly install nixos onto the new laptop, no need to mess with usb sticks or iso's
<clever>
the kexec variant omits it, since ipxe wasnt in the loop
<clever>
steveeJ: the netboot_server.nix variant keeps the netbootipxescript intact (line 18), so you can just chainload netboot.ipxe
<clever>
steveeJ: so you can just ssh into the machine and run `justdoit`, and your done
<clever>
steveeJ: you set a few basic options, like the hdd type (vda, sda, nvme0n1), uefi, luks, boot/swap size, and then it generates a bash script to fully automate the install
<clever>
steveeJ: you can also modify the 1st command from session.md to -A cofnig.system.build.image, then result will just be a directory with a naked kernel+initrd+cmdline, configure the bootloader yourself
<clever>
steveeJ: this configures a complete router, with NAT, bind, tftp, nginx, and dhcpd
<clever>
steveeJ: i'm heading to bed now, but if you get stuck or have questions about the kexec trick, just leave a PM and i can answer things later
<clever>
steveeJ: just upload the tarball to any linux machine, run 1 command, and its running nixos in a ramdisk, run 1 more command, and the disk is wiped and it now has nixos
<clever>
ah, i was expecting the if to be re-arranged
<clever>
Myrl-saki: and i dont think the last commit you made has the changes
<clever>
then the 2nd commit just wont exist, the 1st will be everything
<clever>
Myrl-saki: so you could switch back to the 1st commit in the pr, then amend again
<clever>
Myrl-saki: another handy but optional thing, if you run 'git reset --soft revision' it will forcibly change the commit the current branch points to, without loosing any files
<clever>
it only messes things up if another person pulls the branch
<clever>
i force-push dozens of times
<clever>
nope
<clever>
and git push --force
<clever>
also handy, git commit --amend -p
<clever>
didnt even read it
<clever>
Myrl-saki: (if condition then self.callPackage else self.callPackage_i686) ./path {};
<clever>
self.pkgsi686Linux.callPackage
<clever>
just an alias
<clever>
the same thing
<clever>
so pkgsi686Linux.callPackage only ever makes 32bit programs
<clever>
Myrl-saki: pkgsi686Linux is a 32bit version of pkgs
<clever>
oh, but there is a 2nd pkgs
<clever>
Myrl-saki: the arch has to be set when you import nixpkgs
<clever>
the kernel defaults to putting it higher up in the address space
<clever>
but qemu doesnt know what is already in use, and when trying to get the entire 4gig chunk to fit within the 1st 4gig of ram
<clever>
Myrl-saki: the 1st argument is a hint at where to put it
<clever>
Myrl-saki: at a glance, it appears to be allocating a 4gig chunk of ram starting at 0x1000
<clever>
Myrl-saki: there is also an mmap flag that can fix this
<clever>
a 32bit build of qemu always gets 32bit mmap results
<clever>
so it has to do weird things to make things work
<clever>
Myrl-saki: the issue, is that the mmap winds up allocating ram above the 4gig mark, beyond what 32bit can address
<clever>
Myrl-saki: ahh, i think i see the problem
<clever>
fixed
<clever>
oops, editing it some
<clever>
Myrl-saki: left a comment in the PR
<clever>
*looks*
<clever>
Myrl-saki: got a link?
<clever>
:D
<clever>
haskell packages do that
<clever>
probably
<clever>
thats probably the nix language itself, just add more swap and it should release that ram
<clever>
your better off running cabal2nix on another machine, there is no real reason to run it on the pi itself
<clever>
ah, id expect that to need a lot of ram, since it has to build ghc
<clever>
Myrl-saki: what args did you give it?
<clever>
Myrl-saki: use -iA not -i
<clever>
Myrl-saki: to run what?
<clever>
it may be off by default
<clever>
jonasem: you may need to check ./configure --help
<clever>
so you need to put a cp command into the postInstall, to copy it to $out/bin/
<clever>
yeah
<clever>
jonasem: i think you want to change the ls command to `ls -l src compile tools` and see where the binary was left
<clever>
jonasem: it looks like the makefile does have an install rule, but its probably not installing what you want it to install
<clever>
jonasem: yeah
<clever>
jonasem: add this to the nix file, postInstall = "pwd; ls; ls $out";
<clever>
cinimod_: yeah, you have 2 copies of nix installed, as dom run `nix-env -e nix` to remove the duplicate, then if you want to upgrade, run `nix-env -iA nixpkgs.nix` as under `sudo -i`
<clever>
cinimod_: and `which --all nix-env` ?
<clever>
what does `type nix` say?
<clever>
cinimod_: your running nix2 with a 1.1 nix-daemon
<clever>
cinimod_: i think somebody in #nix-darwin mentioned recently that qt is broken on darwin
<clever>
Geraldus: the error says that yesod-bin depends on it, maybe you just have haddock enabled?
<clever>
can you gist the entire output from the failing build?
<clever>
does your cabal file define a min cabal version?
<clever>
hello
<clever>
Geraldus: yes
<clever>
htafdwes[m]: it also gets a bit tricky to put conditions in the imports field, doing config = lib.mkIf is a lot simpler, have a look at almost any nixos module for an example
<clever>
kuri0: i think youll need to add support in 3 before nixpkgs can support ilp32
<clever>
kuri0: ah, you need to set something in the area of nixpkgs.config, or nixpkgs.system, not sure on the right value though
<clever>
hlint is using static haskell linking, so it only has a binary and nothing else
<clever>
haskellPackages.hlint is using dynamic haskell linking, and includes all of the dependencies, which conflict with the last thing you installed
<clever>
nix-env -f /Users/dom/nixpkgs -iA hlint
<clever>
cinimod_: try without the haskellPackages.
<clever>
kuri0: what do you want to change the abi to?
<clever>
self: super: let config = {...}; nixpkgs = (...); pkgs = ..; in pkgs.haskellPackages....
<clever>
it goes before the let
<clever>
then it becomes overlays = [ (self: super: import ./custom-packages/utleague.nix) ];
<clever>
then use self instead of import <nixpkgs> {}
<clever>
you can also fold the self: super: into custom-packages/utleague.nix
<clever>
it needs the import function at the start, i pasted an example already
<clever>
and this time without {}, because it doesnt accept any args