<clever>
qyliss^work: ld.so is responsible for "interpreting" the elf, and performing dynamic linking
<clever>
qyliss^work: its set to the path of ld.so
<clever>
qyliss^work: elf files still have a interpreter
<clever>
ive written the nix expressions already
<clever>
one sec
<clever>
you can build a nix with nix, that has different paths
<clever>
--store works for downloading and i think building, but running itself will try to read /nix/store based paths
<clever>
ah
<clever>
NickHu: ah, then you mayb want a user namespace, look into nix-user-chroot
<clever>
NickHu: but if you manually create a /nix and chown it to the right user, it wont ask for sudo
<clever>
ottidmes: that both helps (you can verify the binary of a msg when filtering), and harms (journald now thinks your filter prog is the only thing logging)
<clever>
ottidmes: also of note, unix sockets allow you to query the PID of the remote process
<clever>
ottidmes: yeah, you would have to undo the symlink when turning the filter program off
<clever>
ottidmes: you could probably also just overwrite the /dev/log symlink
<clever>
and you must wipe the local cache
<clever>
if the cache claims a given file exists, nix will hard fail when you GC that file from the cache
<clever>
ive also had trouble with the positive ttl before, due to hydra GC
<clever>
ive seen ttl ooptions for both postive and negative ttl
<clever>
yeah, -vvvvv should mention that
<clever>
ah, nvm, negative cache stored
<clever>
copumpkin: have you checked the .narinfo url?
<clever>
fresheyeball: the fix is definitely on nixos-unstable
<clever>
fresheyeball: if you get a python3 error in the stdout of steam (run it in a terminal) then you need to update nixpkgs
<clever>
fresheyeball: ive had one or 2 games in my library work
<clever>
sirkha: do you have a ~/.nixpkgs/config.nix or ~/.config/nixpkgs/config.nix?
<clever>
thedavidmeister: Linux system76 4.14.67 #1-NixOS SMP Fri Aug 24 11:09:23 UTC 2018 x86_64 GNU/Linux
<clever>
thedavidmeister: let me see what kernel i'm on...
<clever>
thedavidmeister: aha
<clever>
thedavidmeister: try switching to slim for example, just temporarily
<clever>
samueldr: oh, that could be it
<clever>
thedavidmeister: try also commenting out the layout and libinput
<clever>
the default shows messages for me
<clever>
thedavidmeister: you have verbose = 0;, that would explain why all logs are missing
<clever>
thedavidmeister: ssh into the laptop from another system, scp can copy files, gist can upload from the CLI
<clever>
thedavidmeister: can you pastebin the entire hardware-configuration and configuration.nix files?
<clever>
thedavidmeister: was there anything else in the logs that you omited?
<clever>
ottidmes: run nix-store -qR on the storepath, then grep ALL of those for /dev/log
<clever>
thedavidmeister: there should be a lot more in the journal then what you listed above
<clever>
thedavidmeister: what display manager did you configure?
<clever>
thedavidmeister: ive got no issues on my system76 machine
2018-11-13
<clever>
nh2: i leave that enabled on most machines, and it makes it trivial to inspect an unexpected chrome segfault
<clever>
nh2: if you flip this on, and `ulimit -c unlimited`, then systemd will save coredumps for everything, you can then use `coredumpctl gdb <pid>` as root to inspct how it failed
<clever>
ottidmes: oh wait, not `return -ENOENT;` its `errno = ENOENT; return -1;` i belibe
<clever>
ottidmes: also, double-check what the real connect returns if you give it a socket that doesnt exist
<clever>
ottidmes: try just returning -ENOENT, dont remap it to another path
<clever>
nh2: only compiled things would avoid the dynamic issue
<clever>
nh2: oh, and ghci will likely have a lot of the same problems, because its dynamic loading
<clever>
nh2: try it only for the binary that uses malloc_info, dont set the var with export
<clever>
but that gives me another idea, what if you just prefix LD_LIBRARY_PATH right, or LD_PRELOAD the new glibc, for just the one binary that needs it?
<clever>
sort of, you would have to manually run that after every `cabal build`
<clever>
nh2: its basically just cat $in/bin/foo | sed > $out/bin/foo
<clever>
nh2: it doesnt work in a shell, because it acts after the build has finished
<clever>
overlays are also on 94
<clever>
nh2: Ericson2314 may know more about how to override glibc
<clever>
nh2: i think the boot on line 91 is where it makes the main stdenv, and line 94 is where your overrides come into play, too late
<clever>
nh2: also note that if you dont specify a config=, then the ~/.nixpkgs/config.nix gets loaded, and can cause unexpected problems
<clever>
nh2: you can also try { overlays = [ (self: super: { ... }) ];
<clever>
nh2: and the stdenv stuff is a bit protected, let me see what has happened to it lately
<clever>
and chrome should be part of the host nixos, and will ignore it
<clever>
nh2: do that inside your default.nix/shell.nix, and it will only impact things using that file
<clever>
let pkgs = import <nixpkgs> { config.packageOverrides = pkgs: {...}; }; in ...
<clever>
nh2: when you import nixpkgs, pass the override there
<clever>
nh2: yeah, thats also a hard question to answer
<clever>
yeah
<clever>
nh2: in c, all functions are exported by default, and you have to define it as static to not export it
<clever>
nh2: also not sure what this does, so you may need to name it malloc_info also
<clever>
weak_alias (__malloc_info, malloc_info)
<clever>
ugly, but it should work
<clever>
nh2: copy them over as well
<clever>
nh2: in theor, you can just copy the entire __malloc_info function to its own file, compile it to a simple .so, and then LD_PRELOAD it
<clever>
nh2: that allows you to transparently replace any function you want, and you can then optionally use `dlsym(RTLD_NEXT` to lookup the original version
<clever>
nh2: if you compile a .so file, and load it with LD_PRELOAD, it will be loaded first, and have priority when symbols collide
<clever>
nh2: if you import the right headers (and it has no static top-level vars in the file), the linker will just give it access to the internal state
<clever>
nh2: what if you just LD_PRELOAD a .so that replaces malloc_info() ?
<clever>
ahh
<clever>
what exactly needs that new glibc?
<clever>
nh2: you would need to create a new cross-compile target like musl64, that uses your patched glibc
<clever>
nh2: but a check with nix-build reveals it still has to compile a new ghc
<clever>
nh2: it will then have a host glibc and a target glibc
<clever>
nh2: the cross-compile logic should handle most of that
<clever>
looking at how it uses a different glibc should answer your question
<clever>
nh2: that is a build of the hello world app, using 64bit musl
<clever>
> pkgsCross.musl64.haskellPackages.hello
<clever>
nh2: looking at the musl stuff should help
<clever>
hmmm, close
<clever>
overrideCC
<clever>
nh2: one sec
<clever>
nh2: yeah, you need to patch the gcc
<clever>
nh2: you want an override
<clever>
nh2: replace-dependency.nix is a pure action that jussssst sed's paths as it recursively copies things
<clever>
ottidmes: with namespacing you can just mount --bind the host root to / and then mount --bind /dev/null to /dev/log
<clever>
its nix, you can trivially run a custom glibc for things like that, and not have any problems!!
<clever>
then PRELOAD wont be involved!!
<clever>
ottidmes: a more extreme fix, patch glibc to include your connect() change, and then link against that patched one
<clever>
ottidmes: or just file an upstream issue asking it to shut up :P
<clever>
ottidmes: namespacing is next then? lol, chroot it and delete /dev/log!
<clever>
ottidmes: yep, line 11 is the smoking gun, /dev/log
<clever>
ottidmes: grep some context around them (grep -C5 'connect(') and throw it all into a pastebin
<clever>
ottidmes: what about just connect( ?
<clever>
nh2: if you take the raw `.drv` from it, and `nix-copy-closure` to another machine, and then `nix-build --check /nix/store/foo.drv`, can you make it work on one, and break on another?
<clever>
ottidmes: i think so, but the `-ff` will also append to that string
<clever>
nh2: what is the state of your sandbox flag?
<clever>
ottidmes: ok, try doing `strace -ff -o logfiles -s 1000 <that prog>` and then search it for any `connect(0,` strings or similar
<clever>
ottidmes: oh, try `lsof -p pid` and see what it claims
<clever>
ottidmes: where is /dev/pid/fd/0 pointing?
<clever>
nh2: ran it twice and it passed both times
<clever>
Zer000: are there signs that one of them was just never used after the upgrade?
<clever>
Zer000: what about last-mod times on the files in each dir?
<clever>
Zer000: if you cat the script for prestart in gitlab.service, you should see some psql usernames and dbnames
<clever>
mudri: could file an issue to have it added, so nixos 19.03 properly warns people
<clever>
mudri: and line 38 of the diff reveals that your keymap was simply renamed to colemak
<clever>
mudri: and a bisect points me to a commit titled: kbd: Rename some keymaps.
<clever>
mudri: its in the `nix-build -A kbd` derivation
<clever>
mudri: i can confirm that this file is present on the rev you named, and missing on master
<clever>
-r--r--r-- 1 root root 1449 Dec 31 1969 result/share/keymaps/i386/colemak/en-latin9.map.gz
<clever>
Zer000: if you check in /etc/systemd/system/ for the gitlab service file, does it name the postgres db to use?
<clever>
double-check what your postgresql is using (ps aux should help), and if the data is in a related path
<clever>
and then the new dir was empty, so the db was gone
<clever>
Zer000: i had a problem with my hydra a few months ago during a similar upgrade, the postgresql datadir changed from /var/lib/something to /var/lib/something/1.2.3
<clever>
Zer000: did you change the stateVersion? (or is it missing)
<clever>
mudri: let me check closer...
<clever>
mudri: i'm guessing that that keymap isnt in the build anymore, so its not being found
<clever>
mudri: does the string en-latin9 exist anywhere in your nixos config?
<clever>
Ashy: ah, then you want either `nix-shell -I nixpkgs=$HOME/apps/nixpkgs` in the dir with your shell.nix, or change line 1 to `with import /home/clever/apps/nixpkgs {};`