sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
<worldofpeace> I think there was some discussion on like saving the environment variables and then unsetting the original one so it doesn't propagate
<samueldr> though, wondering how it can end up unsetting right, without patching an unset right after $software uses an environment variable
<samueldr> or hooking on exec and such
<samueldr> hmm, hooking on exec and such _would_ work, but... hm
<samueldr> there still would be the issue of differenciating between a variable that has been further manipulated by the software
<worldofpeace> yep and certain softwares proper function is completely reliant on that actually happening
<worldofpeace> hmm, I think dolphin doesn't get wrapped because https://github.com/NixOS/nixpkgs/blob/617a3a64026338cc47fa47a5abf416a8d7314866/pkgs/development/libraries/qt-5/hooks/wrap-qt-apps-hook.sh#L68 doesn't return on non zero exit status on the binary
<samueldr> right, why does readelf not return 0?
<samueldr> (I'm assuming it would be readelf)
Guanin has quit [Remote host closed the connection]
<worldofpeace> this is what readelf returns for dolphin https://gist.github.com/worldofpeace/c365456b06c459e2e4a0afc9d8f31ab0
<worldofpeace> it's checking for libQt5Core with grep
<samueldr> ah, and libkdeinit5_dolphin only
<worldofpeace> at any rate it shouldn't silently not wrap things
<samueldr> is it that libkdeinit5_dolphin itself has the deps on Qt?
<worldofpeace> it should be a failure "Not a qt application"
<worldofpeace> probably samueldr
<samueldr> yeah, though not fail the build
<worldofpeace> Which means isQtApp isn't succinct enough of a check
<samueldr> just like sometimes the autopatchelf hook prints "irrelevant" "not an elf"
<samueldr> looks like it'd need to go through RUNPATH, check all shared libraries recursively
<samueldr> not something I'd want to implement in bash
<worldofpeace> yeah I'd just remove that function there entirely
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-dev
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
janneke has quit [Ping timeout: 250 seconds]
orivej has quit [Ping timeout: 246 seconds]
janneke has joined #nixos-dev
layus has quit [Quit: ZNC 1.7.3 - https://znc.in]
das_j has quit [Quit: "Bye!";]
orivej has joined #nixos-dev
das_j has joined #nixos-dev
layus has joined #nixos-dev
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
Guanin has joined #nixos-dev
LnL7 has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
<ivan> https://github.com/NixOS/nixpkgs/pull/64054 this can be merged, I've tested it long enough
<{^_^}> #64054 (by ivan, 2 weeks ago, open): snscrape: 0.2.0 -> 0.3.0
cransom has quit [Quit: WeeChat 2.4]
psyanticy has joined #nixos-dev
<zimbatm> hello gang :)
<zimbatm> I made a PR to update the issue templates; let me know if there are any objections: https://github.com/NixOS/nixpkgs/pull/64983
<{^_^}> #64983 (by zimbatm, 14 minutes ago, open): Update issue templates
orivej has quit [Ping timeout: 248 seconds]
<zimbatm> it automatically adds labels to issues and users can now select between bug reports and packaging requests
<zimbatm> we can also add feature requests later if we want
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
tilpner has quit [Quit: WeeChat 2.4]
avn has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 268 seconds]
tilpner has joined #nixos-dev
<worldofpeace> #64984 ☚ī¸ I think it's absolutely essential for 19.09 that no user has this problem
<{^_^}> https://github.com/NixOS/nixpkgs/issues/64984 (by emmanuelrosa, 4 hours ago, open): qutebrowser: This application failed to start because no Qt platform plugin could be initialized.
<gchristensen> do we have a handle no a solution?
<gchristensen> on a*
<worldofpeace> pretty sure just add wrapQtAppsHook to nativeBuildInputs to basically every application that needs it
<gchristensen> is there a way we can test for this problem automatically?
<worldofpeace> Pretty much that error at runtime
<gchristensen> so, like, run every executable from every package and see if it emits that error?
<worldofpeace> think so
<gchristensen> it depends on system state, right?
<gchristensen> I'm somewhat wondering what would it take for me to do this :P
<worldofpeace> yes the environment, the unwrapped applications could for example inherit the wrapped env from plasma5 and "work"
<worldofpeace> I wouldn't start though until #64720 is complete
<{^_^}> https://github.com/NixOS/nixpkgs/pull/64720 (by worldofpeace, 3 days ago, open): wrapQtAppsHook: wrap binaries in libexec
cransom has joined #nixos-dev
<gchristensen> would a basic construct like: start a NixOS VM with xserver and the "xterm" "desktop manager" enabled, execute each binary from a given package, kill them after a couple seconds, search output for "failed to start because ..." ... suffice?
<gchristensen> would a basic construct like: start a NixOS VM with xserver and the "xterm" "desktop manager" enabled, execute each binary from a given package, kill them after a couple seconds, search output for "failed to start because ..." ... destroy the VM. repeat for each package. suffice?
<worldofpeace> I thought of writing a test like that yesterday even
<gchristensen> that would be awesome!
<gchristensen> if you'd like to collaborate, I can get hardware for such experiments =)
<worldofpeace> I'd hope it would be simple like that, Qt isn't exactly my wheelhouse since I'm maintaining the gtk side of things. But we sure could try
<gchristensen> sounds great :) I know almost nothing about Qt, but if some effort and a lot of CPUs can help make (almost) no user experience that problem again, I am on board
<samueldr> worldofpeace, gchristensen, #47552 has a testable repro
<{^_^}> https://github.com/NixOS/nixpkgs/issues/47552 (by samueldr, 41 weeks ago, open): Clear reproduction of Qt versions mismatch causing plasma failure
<samueldr> from my testing, the non-wrapper approach seemd sturdier :/
<gchristensen> oh cool
<worldofpeace> 🎆
<gchristensen> oh _this_ issue. the one with two alternative solutions?
<samueldr> two differing implementations
<worldofpeace> with two differing opinions :)
<gchristensen> generally I prefer solutions which don't use wrappers... :)
<worldofpeace> but you know status quo etc.
<samueldr> though understandably, maintaining a somewhat intrusive (though small) patch is a bother
<clever> samueldr: i already have a ticket open on nix itself, for qt type problems
<{^_^}> #30775 (by cleverca22, 1 year ago, open): nix-env silently collides propagated-user-env-packages
<samueldr> right
<clever> for qt specifically, there is an assert in the library, so qt 1.2.3 cant mix with 1.2.4
<clever> but then some silly developer put all of the libraries in $out/lib/qt-1.2
<clever> so you can still get conflicts :P
<samueldr> yes, that was something I touched on
<samueldr> while Qt says it should be possible to do so, I found out it's not
<clever> samueldr: ditching nix-env -i would solve the issue i linked! :D
<samueldr> that particular one yes
<samueldr> or uh, would tone it down
<samueldr> though it's still possible to mix and match through nix-build and ./result/bin/*
<clever> it would move the problem into tools like home-manager, which use pkgs.buildEnv and can warn on collisions
<clever> such tools would also typically use the same nixpkgs for every package, and not conflict
<samueldr> when the system and home-manager clashes, it would break stuff too AFAICT
<clever> yeah, ./result can still conflict with ~/.nix-profile
<clever> yes, i have run into a user where an old qt in ~/.nix-profile caused the entire kde session manager to crash on login
<clever> resulting in him being unable to login graphically
<samueldr> yes, which is what #47552 allows to reproduce :)
<{^_^}> https://github.com/NixOS/nixpkgs/issues/47552 (by samueldr, 41 weeks ago, open): Clear reproduction of Qt versions mismatch causing plasma failure
FRidh has joined #nixos-dev
<worldofpeace> hey cross compilation friends, this in need of your review #64655 and it should be fairly straightforward
<{^_^}> https://github.com/NixOS/nixpkgs/pull/64655 (by tadeokondrak, 5 days ago, open): fribidi: fix cross compilation
<worldofpeace> So I'm thinking, would it be easier to just identify what applications are qt ones with nix and just filter that out? It should just be fine then to add the setup-hook to all of them
<gchristensen> could only do programs where `qt` is in a store path of its dependencies
<clever> gchristensen: there was a package somewhere, that basically checked for foo in $PATH, and if it was found, enabled support for foo
<worldofpeace> yeah I think libQt5Core
<clever> gchristensen: except, store path hashes .....
<clever> so, it would randomly enable support for something, and fail to build
<samueldr> worldofpeace: maybe with the qtbase setup hook? https://github.com/NixOS/nixpkgs/pull/44047/files#diff-0d4fd569da3fdaee275ea9d30230b6ff
<samueldr> or something similar?
<samueldr> whenever the setup hook is used, automatically wrap everything?
Drakonis has quit [Quit: WeeChat 2.4]
Drakonis has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
Drakonis has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
Drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 250 seconds]
Drakonis has quit [Ping timeout: 264 seconds]
<worldofpeace> samueldr: that might be a good idea, currently qt5's mkDerivation just adds it automatically but everything doesn't use that
Jackneill has quit [Remote host closed the connection]
justan0theruser is now known as justanotheruser
{^_^} has quit [Ping timeout: 276 seconds]
<arianvp> where in the nix store are signatures stored?
<arianvp> in the sqlite db?
<thoughtpolice> arianvp: Yes. You can see the schema yourself with `nix run nixpkgs.sqlite -c sqlite3 /nix/var/nix/db/db.sqlite ".schema" | less` (run as `root`)
<thoughtpolice> `sqlite3 /nix/var/nix/db/db.sqlite "SELECT sigs FROM ValidPaths WHERE sigs != \"\""`
orivej has quit [Ping timeout: 248 seconds]
FRidh has quit [Quit: Konversation terminated!]
arianvp has quit [Quit: WeeChat 2.4]
arianvp has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
<arianvp> where are signatures stored for /nix/store?
<clever> arianvp: in /nix/var/nix/db/db.sqlite
<arianvp> and on a 'remote' binary cache?
<clever> arianvp: the narinfo files
<clever> arianvp: check this url
<arianvp> cool thans
Drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
Drakonis has quit [Ping timeout: 276 seconds]
Jackneill has joined #nixos-dev
Drakonis has joined #nixos-dev
avn has joined #nixos-dev
averell has quit [Quit: .]
averell has joined #nixos-dev
orivej has joined #nixos-dev
{^_^} has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
<worldofpeace> FRidh: when do you decide to merge master into python-unstable?
justanotheruser has quit [Ping timeout: 245 seconds]
justanotheruser has joined #nixos-dev