2018-11-01
14:18
<
clever >
lrwxrwxrwx 1 root root 9 Oct 31 15:36 /dev/disk/by-id/wwn-0x5000cca33ad2b4c7 -> ../../sda
14:18
<
clever >
turion: its /dev/disk you want
14:17
<
clever >
turion: hmmm no, not block
14:17
<
clever >
turion: you need to find a symlink under /dev/block that points to sdb
14:14
<
clever >
turion: sdb still
14:06
<
clever >
turion: gpt makes things more fun, by allowing labels on the partitions as well as the filesystems
14:04
<
clever >
turion: the label is part of the filesystem, not the parititon tables
14:00
<
clever >
infinisil: ah
14:00
<
clever >
turion: yeah, thats not even partitioned, "partition 1" starts at offset 0
13:59
<
clever >
infinisil: ,pastebin doesnt work
13:59
<
clever >
,pastebin turion
13:59
<
clever >
turion: i dont think its even partitioned right now, so you need to create an mbr partition
13:55
<
clever >
can you switch it back to english?, just need to tweak one of the LC_ vars i think
13:52
<
clever >
turion: can you pastebin `fdisk -l /dev/sdb` ?
13:50
<
clever >
as-in, not-gpt
13:50
<
clever >
ext4 on an mbr partition table
13:49
<
clever >
grub2 supports both legacy and efi
13:49
<
clever >
turion: by legacy, i mean not-efi
13:47
<
clever >
turion: if you only want legacy booting, then you could just make the entire usb stick ext4 on mbr
13:44
<
clever >
turion: the boot partition can be vfat, but the rootfs must support +x and chown
00:05
<
clever >
emily: at runtime or nix build time?
00:02
<
clever >
i just added pkgs.steam to systemPackages and it works
2018-10-31
23:01
<
clever >
but if you fail to meet the output hash you claimed, the build finishes
23:01
<
clever >
so the sandbox is relaxed and allows network access
23:01
<
clever >
fixed-output derivations declare the hash of the output in the nix, so $out is based purely on that declared hash, not the inputs
23:01
<
clever >
so as long as its not using rng and date/time to decide things during the build, its pure, and reproducible
23:00
<
clever >
those derivations are also pure when the sandbox is on, so the only thing that they can possibly access, is the inputs, that are hashed
23:00
<
clever >
so if any input changes, $out changes, and it will usually not find it in /nix/store, and rebuild
22:59
<
clever >
a non-fixed-output derivation, has the $out path based on a hash of every input
22:58
<
clever >
by default, derivations are not fixed-output
18:02
<
clever >
not really
17:55
<
clever >
chris|: but then multiple non-defaults will concat to eachother
17:54
<
clever >
chris|: the only time its not, is when the service has a default value, any non-default will overwrite it
17:46
<
clever >
chris|: all list options are append by default
16:38
<
clever >
so you have to set it in the file the error tells you to set it in
16:38
<
clever >
boxscapeR: nix-shell only obeys the main config.nix file
15:43
<
clever >
it sounds like it may be a bug in `nix eval`
15:43
<
clever >
tnks: ls -lh /home/tnks/.nix-defexpr/channels/nixpkgs/
15:42
<
clever >
tnks: ls -lh /home/tnks/.nix-defexpr/channels/nixpkgs
15:41
<
clever >
tnks: NIX_PATH=/home/tnks/.nix-defexpr/channels nix-instantiate --find-file nixpkgs
15:40
<
clever >
tnks: also, does /home/tnks/.nix-defexpr/channels/nixpkgs exist?
15:40
<
clever >
then you can test with things that arent a full nixpkgs
15:40
<
clever >
tnks: it helps a lot to instead use `nix-instantiate --find-file nixpkgs`
15:04
<
clever >
__red__: the history button for that dir reveals this commit deleted things
15:03
<
clever >
> lib.version
15:00
<
clever >
> avrgcc.meta.position
15:00
<
clever >
but you could look at how avrgcc handles things
15:00
<
clever >
ah, dont have that one memorized
15:00
<
clever >
__red__: which microcontroller is are you on?
14:36
<
clever >
arianvp: and 5 minutes later, due to a lack of services in dom0, the hypervisor watchdog assumes the world is ending, and forces a hard reset
14:35
<
clever >
arianvp: also, when you nixos-rebuild under xen, and i tries to restart xen services, they fail in weird ways
14:34
<
clever >
arianvp: maybe when updating things in /etc/ can break a running service
14:14
<
clever >
Mic92: delete all the old flags, and document it!
14:08
<
clever >
arianvp: sure
13:58
<
clever >
arianvp: havent heard of that
13:57
<
clever >
i want a base nixos install to not have perl in the closure!!
13:57
<
clever >
remove all perl!
13:57
<
clever >
arianvp: :D
13:56
<
clever >
arianvp: same, but i forgot that minor detail
13:54
<
clever >
arianvp: no reload support in this service
13:54
<
clever >
arianvp: ahh
13:53
<
clever >
__red__: thats one way to fix it
13:53
<
clever >
arianvp: ive also been wanting to know, how to make it restart, not stop+start
13:19
<
clever >
emerij: yeah
13:15
<
clever >
emerij: ah
13:09
<
clever >
just give it a clearly wrong hash and read the error
13:09
<
clever >
not really
13:08
<
clever >
so thats the hash of the raw patch, not the cleaned up patch
13:08
<
clever >
nix-prefetch-url doesnt do the cleanup fetchpatch does
13:08
<
clever >
you gave it the hash of something else, with a similar name, and it kept using that file, because you claimed thats what the hash was
13:07
<
clever >
qyliss^work: and if you temporarily make the hash invalid (just change 1 digit) what hash do you get?
12:57
<
clever >
if your using nixos
12:57
<
clever >
just that its a nixpkgs level option, so it has to go under nixpkgs.config
12:57
<
clever >
but its not clear what it does from there
12:56
<
clever >
emerij: its a bool that gets passed into this derivation
12:18
<
clever >
Synthetica: it has to be done in the nix files
12:07
<
clever >
Synthetica: allow port 22 to your deployer, and 80/443 to everyone else
12:06
<
clever >
> (import <nixpkgs> { config.allowUnfree = false; }).minecraft
12:06
<
clever >
> (import <nixpkgs> { config.allowUnfree = true; }).minecraft
12:06
<
clever >
Synthetica: when you import nixpkgs, set config.allowUnfree = true;
12:05
<
clever >
its an entire package manager
12:05
<
clever >
i have found the android-sdk to work very nicely, on other distro's
12:01
<
clever >
clefru: so its bypassing that
12:01
<
clever >
clefru: internally, ldd is just a bash script, that runs the right ld-linux on the binary, with some env vars set
12:00
<
clever >
patchelf and --set-interpreter have to be ran
12:00
<
clever >
clefru: yep, its /lib64/ld-linux-x86-64.so.2 thats not found
12:00
<
clever >
clefru: what about file on the binary?
11:57
<
clever >
and its half written in nix!
02:59
<
clever >
cant think of anything else that would cause the error you had
02:58
<
clever >
detran: thats a bit strange
02:38
<
clever >
detran: nix-store --verify --check-contents
02:38
<
clever >
detran: wait, exe format error....
02:38
<
clever >
detran: thats a weird one
02:11
<
clever >
what was the exact error it had?
02:08
<
clever >
and then the cryptkey = ...; device becomes useless, so it can be removed
02:08
<
clever >
so the keyFile=..; has to be removed
02:07
<
clever >
if a keyFile is specified in the nix, it wont ask for a password, i think
02:03
<
clever >
and any slot can be used to unlock the disk
02:03
<
clever >
each slot can be used by a passphrase or a keyfile
02:03
<
clever >
slot 0 is used on all, and slot 1 on one of them
02:03
<
clever >
your devices have 8 keyslots
02:03
<
clever >
in the output of luksDump
01:58
<
clever >
but you can easily transition to just a normal passphrase on both devices
01:56
<
clever >
i also refused to do that, and just put lvm on luks
01:56
<
clever >
and just ignore it
01:56
<
clever >
so if you can use that old cryptkey to add a password to both devices, you can then change the nixos config and upgrade
01:55
<
clever >
stage-1 will remember the passphrase you enter, and try it again on all other disks
01:55
<
clever >
thats not needed at all on modern nixos
01:55
<
clever >
ah, you have that messy setup with a cryptkey device
01:55
<
clever >
on nixos, fdisk supports both seamlessly
01:54
<
clever >
gdisk i think, or parted maybe
01:53
<
clever >
detran: your fdisk doesnt support GPT, so the output isnt complete
01:43
<
clever >
detran: ive not had any troubles with upgrading and luks
01:40
<
clever >
detran: i use luks on all of my installs now
01:37
<
clever >
__red__: you could also clone it elsewhere, and then symlink foo.nix to your default.nix
01:28
<
clever >
__red__: the hydra server is also a binary cache
01:03
<
clever >
2018-10-30 20:34:50 < clever> __red__: with import <nixpkgs> { overlays = [ (import ./foo.nix) ]; }; { inherit foo bar baz; }
01:02
<
clever >
__red__: the with is missing
2018-10-30
23:34
<
clever >
thats enough of a release.nix to make it build things from an overlay
23:34
<
clever >
__red__: with import <nixpkgs> { overlays = [ (import ./foo.nix) ]; }; { inherit foo bar baz; }
23:24
<
clever >
and this showed the drv for it
23:24
<
clever >
[clever@amd-nixos:~]$ nix-store -q --deriver /nix/store/a0d6q18gxggcvb5x24nrdg6nvhbnipnb-glibc-2.27
23:24
<
clever >
but in my case, it did nothing, which signaled i already had it
23:24
<
clever >
this let me fetch the same glibc you where fetching
23:24
<
clever >
[clever@amd-nixos:~]$ nix-store -r /nix/store/a0d6q18gxggcvb5x24nrdg6nvhbnipnb-glibc-2.27
23:24
<
clever >
and what it builds first, is what hydra was stuck on
23:24
<
clever >
nix-store ignores all those rules, and just builds whatever hydra was going to build
23:23
<
clever >
thats the same way i check for missing required system features
23:15
<
clever >
just add ,i686-linux to the platforms for the build slave, in the hydra config
23:14
<
clever >
you dont need substituters on to fix this
23:14
<
clever >
on the queue, it shows jobs per arch
23:14
<
clever >
hydra should show this
23:13
<
clever >
the system field in the build slave file is a , seperated list
23:13
<
clever >
builder@192.168.2.126 armv6l-linux,armv7l-linux /etc/nixos/keys/distro 1 1 big-parallel
23:13
<
clever >
Lisanna: do you have any 32bit build slaves?
23:12
<
clever >
Lisanna: thats a 32bit glibc
23:11
<
clever >
then it has to build its own glibc, and cant use the cache
23:09
<
clever >
oh, do you have binary cache support enabled in hydra?
23:09
<
clever >
thats somewhat normal
23:08
<
clever >
Lisanna: what is the name of what it started?
23:08
<
clever >
Lisanna: try again with nix-store -r /nix/store/foo.drv -j 1 -Q, and then ctrl+c it when it starts a build
23:05
<
clever >
Lisanna: yeah
23:05
<
clever >
Lisanna: can you pastebin that whole output?
23:02
<
clever >
Lisanna: if you `nix-store -r /nix/store/foo.drv --dry-run` on that builds drv, what does it say?
23:00
<
clever >
Lisanna: check `journalctl -f -u hydra-queue-runner`
20:38
<
clever >
__red__: and a let block can be used to clean that up if you want to
20:19
<
clever >
Lisanna: looks like hydra needs further patching then
20:17
<
clever >
Lisanna: yeah, it looks like i'm mis-remembering how it handles git stuff
20:15
<
clever >
Lisanna: deep is the oposite of shallow, and it has to do with how much history is left in .git
20:14
<
clever >
Lisanna: deep clone is unrelated to submodules
20:13
<
clever >
Lisanna: oh wait, i think something has changed..
20:12
<
clever >
thats why putting a branch name in the string even works
20:12
<
clever >
without any escaping
20:12
<
clever >
Lisanna: it just blindly passes the entire string from the build inputs config
20:10
<
clever >
writeScriptBin is the one that doesnt
20:09
<
clever >
steveeJ: pretty sure thats the default for writeScript
20:08
<
clever >
Lisanna: all i did in my patch was copy the nixpkgs version of nix-prefetch-git to hydra
20:05
<
clever >
__red__: only if thats a top-level input to hydra
20:05
<
clever >
__red__: that works when your at the nix level, but hydra has a different way of fetching the initial inputs
20:03
<
clever >
Lisanna: yeah
20:02
<
clever >
Lisanna: yep
20:01
<
clever >
Lisanna: you want --fetch-submodules, not deep clone
20:00
<
clever >
Lisanna: try turning that off temporarily
20:00
<
clever >
Lisanna: is any kind of automatic GC setup?
19:58
<
clever >
__red__: every attribute in the derivation is an env var at runtime
19:52
<
clever >
__red__: yeah, just make the buffer 128 bytes too big, thatll be plenty!
19:49
<
clever >
__red__: yep
19:48
<
clever >
hyperfekt: you could also do both in the same pr
19:47
<
clever >
hyperfekt: so arbitrary things can be added to the default for all pam services
19:47
<
clever >
hyperfekt: the next best thing would be to add an extraConfig to pam, and include it in that string
19:44
<
clever >
hyperfekt: that file is already full of conditional things, so why not just re-open the pr, but make it optional this time?
19:43
<
clever >
__red__: but if the nixpkgs your applying the overlay to changes, nix will still want to build a new copy
19:41
<
clever >
__red__: you would either need to run your own hydra or use cachix, but then you run into the issue that the cache only works if somebody is on the exact same niiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiixpkgs you built things for
19:40
<
clever >
hyperfekt: whhich file exactly are you trying to modify?
19:40
<
clever >
hyperfekt: you can usually do that by just assigning the right valuuue under security.pam.services
19:37
<
clever >
i dont think the module framework allows refering to the previous value at all, why exactly do you need to do that?
19:36
<
clever >
but not the nixos config itself
19:36
<
clever >
hyperfekt: that will only impact keys under the pkgs tree, when used within nixos modules
19:35
<
clever >
hyperfekt: overlays cant affect nixos options
17:49
<
clever >
romildo: i think ryantm is involved in that
17:16
<
clever >
wirew0rm: yeah
17:14
<
clever >
wirew0rm: what is the eval error?
16:56
<
clever >
wirew0rm: lists behave a bit weirdly, you need to wrap each item with () to make it parse the way your expecting
16:55
<
clever >
Acou_Bass: its more about querying the xorg state before you login, and normal security doesnt let you run arbitrary things then
16:53
<
clever >
and then start things like xrandr or even xterm, and inspect the current config and layout
16:53
<
clever >
if you mess with DISPLAY and XAUTHORITY, you should be able to connect to X from an ssh session
16:53
<
clever >
by chance, the login is on one of the main monitors
16:52
<
clever >
Acou_Bass: i just never bothered getting it configured right on the login page, and i let xfce fix things after login
15:29
<
clever >
lukego: gummiboot doesnt exist anymore
15:28
<
clever >
lukego: what boot.loader.X.enable=true; is setup?
13:22
<
clever >
srhb: all of those failures are epyc again, another restart is in order?
13:21
<
clever >
locallycompact: whenever it passes a set of tests
12:53
<
clever >
nix-repl> haskell.packages.ghc861.callHackage "th-desugar" "1.9" {}
12:49
<
clever >
you can try just `:b haskell.lib.doJailbreak pkgs.haskell.packages.ghc861.th-desugar` in the repl, to confirm if thats enough
12:48
<
clever >
that channel last updated 6 days ago
12:46
<
clever >
RyanGlScott: which channel are you on?
12:46
<
clever >
but it was removed 5 days ago
12:46
<
clever >
RyanGlScott: an 861 specific override did exist, to make it ignore the versions in the cabal file
12:40
<
clever >
RyanGlScott: and if you :b it, does it fail?
11:57
<
clever >
though multiple PR's may share some things, its a complex thing when it gets to that scale
11:56
<
clever >
nix caching can help, but if something deep in the dep-chain changes, its a mass mass rebuild
11:56
<
clever >
1200 jobs, at a rough guess
11:55
<
clever >
with all the normal nix caching
11:55
<
clever >
and if there are any changes in the code, it will re-test everything
11:55
<
clever >
and because hydra is poll based, it will check (and get a new merge commit) each time
11:54
<
clever >
but hydra can be configured to build one or both, and then re-test every time master moves
11:54
<
clever >
so when master changes in a breaking way, you never notice, you merge the pr, and then everyhting breaks :P
11:53
<
clever >
many ci sytems can build both, but they only build the merge comit once
11:53
<
clever >
one is the tip of the pr, the other is a dummy merge commit, simulating what would happen if you where to merge it
11:53
<
clever >
and pull/1234/merge i think
11:52
<
clever >
pull/1234/head
11:52
<
clever >
and reverse to that, only /commit tells you what branches a commit is in
11:52
<
clever >
but /commits does
11:52
<
clever >
one anoying thing, is that /commit doesnt shut status's from CI systems
11:48
<
clever >
and all commits from forks also exist in the parent repo, so you can use either for the owner/repo pair above
11:47
<
clever >
then you could get just a piece of my pr
11:45
<
clever >
but also, my pr has conflicts, so that patch wont apply to master
11:39
<
clever >
internally, it keeps a queue of pending notifications, and runs 2 in parallel
11:38
<
clever >
it could still loose notifications
11:37
<
clever >
its also going to result in a loss of github notifications
11:37
<
clever >
restarting it like that is going to interupt any job that takes over a minute to build, causing them to never finish
11:36
<
clever >
but it may also fix that
11:36
<
clever >
Lisanna: the main goal was to fix cached evals not re-notifying github
11:34
<
clever >
but it has a got conflict with another change that claims to fix the same submodule issue
11:32
<
clever >
so just creating a single submodule entry broke hydra and made your project untestable
11:31
<
clever >
Lisanna: there was a seperate bug in hydra's copy of nix-prefetch-git, that caused the entire clone to fail if any submodules existed in the repo, even if your not cloning them
2018-10-28
14:42
<
clever >
i'm going to get some sleep, send me a PM if you get it all working, i'm interested in fpga stuff as well
14:37
<
clever >
jophish: that help much?
14:37
<
clever >
show-backtrace-all-active-cpus(l) and show-task-states(t) can give useful debug
14:36
<
clever >
sync and poweroff give you a sorta cleanish shutdown
14:35
<
clever >
jophish: sysrq + ? would print the help, and confirm the kernel is at least responding
14:35
<
clever >
jophish: if you send a break signal over the serial port (depends on the client), you can trigger sysrq's over the serial
14:35
<
clever >
jophish: oh, sysrq
14:34
<
clever >
jophish: or an activation script
14:25
<
clever >
jophish: double-checking things
13:56
<
clever >
feep: every attribute in a derivation is an env var
13:51
<
clever >
hyper_ch: then use the date of the commit as a version
13:39
<
clever >
dramforever: yeah, it might be, but the only way to confirm if its enough or not is to try
13:39
<
clever >
feep: you can put the -E string into a .nix file, and then just run nix-build on the file
13:38
<
clever >
feep: this will build the package in nixpkgs, but change the src to come from the current dir
13:38
<
clever >
nix-build -E 'with import <nixpkgs> {}; cataclysm-dda.overrideAttrs (old: { src = ./.; })'
13:37
<
clever >
so its more for short-lived testing binaries
13:37
<
clever >
just keep in mind that nix may break the resulting binaries next time you run a garbage-collection
13:36
<
clever >
then just ./configure and make, as usual
13:36
<
clever >
that will drop you into a shell suitable for building the version in nixpkgs
13:36
<
clever >
feep: nix-shell '<nixpkgs>' -A cataclysm-dda
13:36
<
clever >
oh, if you want to develop it more, you probably want nix-shell initially
13:33
<
clever >
feep: ls -ltrh result/bin/
13:33
<
clever >
hyper_ch: there is also the contributing.md file, and adding it to all-packages.nix
13:32
<
clever >
feep: nix-build '<nixpkgs>' -A cataclysm-dda
13:31
<
clever >
hyper_ch: have you read the nixpkgs manual?
13:31
<
clever >
feep: do you want to install it, modify it, or depend on it?
13:27
<
clever >
/home/clever/nixpkgs/pkgs/tools/backup/duply/default.nix: postPatch = "patchShebangs .";
13:26
<
clever >
feep: run patchShebangs on the dir they are in
13:25
<
clever >
and then nix itself will build max-jobs seperate packages, in parallel
13:25
<
clever >
so if enableParallelBuilding is on, make will obey cores from nix.conf
13:24
<
clever >
cores is also at the make level
13:24
<
clever >
max-jobs is at the nix level
13:24
<
clever >
enableParallelBuilding is for the make level
13:24
<
clever >
there is both make and nix level parallism
13:22
<
clever >
but it needs some more work
13:22
<
clever >
yeah, `nix build` is the newer interface
13:22
<
clever >
feep: there is also `nix-store -l /nix/store/foo` to view the logs of something that has previously passed
13:21
<
clever >
feep: i just use `nix-build` when i want logs
13:13
<
clever >
jophish: you will obviously want a shorter interval, and maybe test it on a working machine first, systemctl list-timers
13:13
<
clever >
jophish: i think that handles the wantedby for you
13:13
<
clever >
2018-10-28 04:15:27 < clever> Arahael: you can define a custom timer by just setting systemd.services.foo = { script = ''....''; startAt = "nightly"; }; in configuration.nix i believe