gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<thoughtpolice> andi-: Ping -- I'm not sure what the protocol is for Rust changes, but can https://github.com/NixOS/nixpkgs/pull/50452 go to master when it's ready?
<{^_^}> #50452 (by P-E-Meunier, 1 day ago, open): Rust build-support: fixing a compilation error in some crates
<thoughtpolice> andi-: I know rust re-compilation is generally expensive but I think buildRustCrate changes aren't quite as bad (it's not used as much I think?) ofborg only lists ~100 rebuilds, so I think that's pretty ok
<andi-> thoughtpolice: sure, let me just comment on P-E-M's last question… I think we need test cases in the `tests/` subfolder of the build-rust-crate thingy.. Those heuritisc/problematic packages should be added for future testing.
<thoughtpolice> andi-: I think in my case proc-macro2 got pulled in by failure-derive, so maybe just committing a carnix package for that and trying to build it would work
<thoughtpolice> I'll see if it does
<andi-> check the tests in the folder. I alreayd have one that has a larger list of dependencies.. maybe just "merging" that carnix generated file there would be a good thing to do. I really do not want to bloat nixpkgs with those :/
<thoughtpolice> the brotli one? that one isn't too bad at least, but I'll see if I can merge them somehow
<andi-> thoughtpolice: Just today I found `cargo build --build-plan` which could serve as a proper replacement for all the hacky things we do there. Maybe we can have a nice(r) way to build rust crates using that with the dependency information. It could remove the need for carnix entirely.
<thoughtpolice> andi-: Honestly it's arguably a bug in proc-macro2, as well
<thoughtpolice> I mean, look at the build.rs: https://github.com/alexcrichton/proc-macro2/blob/master/build.rs#L10
<thoughtpolice> It just silently continues if the compiler minor version can't be found? That... seems wrong, tbh.
<thoughtpolice> Like I can't imagine there are many cases when RUSTC is unset. And if there are, like this case, it clearly results in a totally broken build? So why do it silently?
<thoughtpolice> Maybe I should file something upstream about this too
<andi-> that would be good
<{^_^}> alexcrichton/proc-macro2#153 (by thoughtpolice, 9 seconds ago, open): Consider failing loudly when RUSTC is unset in build.rs
<thoughtpolice> andi-: Also, looking at --build-plan, it certainly looks like it could fulfill that roll. Looking at its output, the main thing it would need is to track source repositories/non-crate dependencies better. That's a problem with Carnix I'm currently trying to work around (annoyingly)
<thoughtpolice> andi-: Mainly, it looks like it lacks any sort of information about where a build came from. So for example I want to clone repository foo.git, and retrieve packages foo-bar, and foo-baz. But by the time Cargo emits the build plan, it's already thrown that information away -- it already checked out the repository
<thoughtpolice> That's made worse because Cargo also knows how to scan manifests/repositories for Cargo.toml files to find a dependency in some subdirectory, e.g. I just point the source of 'foo-bar' to foo.git and Cargo magically figures out the subdir. Honestly I feel this is a misdesign, but oh well
<thoughtpolice> If it could tell you 1) where it came from and 2) where the resolved Cargo file is, that would be ideal and almost perfect.
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 244 seconds]
lassulus_ is now known as lassulus
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
drakonis has quit [Quit: WeeChat 2.2]
orivej has quit [Ping timeout: 240 seconds]
garbas has quit [Quit: WeeChat 2.3]
<andi-> thoughtpolice: the main takeaway isbthst it is relatively easy to implement since you can have custom executors in/around cargo
drakonis_ has quit [Ping timeout: 272 seconds]
lopsided98 has quit [Ping timeout: 264 seconds]
Lisanna_ has joined #nixos-dev
lopsided98 has joined #nixos-dev
orivej has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
FRidh has joined #nixos-dev
jtojnar has joined #nixos-dev
lassulus has quit [Ping timeout: 244 seconds]
lassulus has joined #nixos-dev
jtojnar has quit [Read error: No route to host]
jtojnar has joined #nixos-dev
drakonis has joined #nixos-dev
init_6 has quit []
<timokau[m]> If I have a variable `a = "xorg.xmodmap"`, is there a way to do something like `pkgs.${a}` mean `pkgs.xorg.xmodmap`? When doing it naively nix assumes the dot is part of the attribute name.
<timokau[m]> I guess I'm looking for something like `eval` in nix
<simpson> Hm, interesting. I don't think that there's builtin syntax, but maybe there's a library function somewhere.
<qyliss> there’s builtins.tryEval…
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
<timokau[m]> qyliss: Thats nearly what I need, but if I understand correctly that doesn't return the output of the evaluation
<timokau[m]> It just echoes its input if the evaluation was successful
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<timokau[m]> Oh `tryEval` doesn't actually evaluate a string. It evaluates a nix expression. Which is why it echoes back any string.
<ekleog> > let a = "xorg.xmodmap"; in lib.attrByPath (lib.splitString "." a) (throw "not found") pkgs
<{^_^}> "<derivation /nix/store/844csgxshd9q0pd9760di3j2iwcn12s8-xmodmap-1.0.9.drv>"
<ekleog> ^ timokau[m]
<ekleog> by default the dot is part of the attribute name because eg. services.nginx.virtualHosts."example.com" = ...
<timokau[m]> ekleog: Just came up with `nestedSubattr = cur: attrs: if attrs == [] then cur else nestedSubattr cur.${lib.head attrs} (lib.tail attrs);` but your version is a little less horrible :D
<timokau[m]> Thanks!
drakonis has quit [Ping timeout: 245 seconds]
<ekleog> your version looks like exactly lib.attrByPath, btw :p
<ekleog> (as you're handling a list and not a .-separated string)
<timokau[m]> Well at least I don't have to maintain it myself ^.^
<ekleog> heh ^^
FRidh has quit [Quit: Konversation terminated!]
genesis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
genesis has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
lassulus has quit [Ping timeout: 252 seconds]
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
* gchristensen waves
<samueldr> doesn't waving hurt?
<samueldr> and: hi!
<gchristensen> actually, no, it doesn't hurt
<gchristensen> compared to my right elbow surgery, this one was easy and painless
<flokli> welcome back, and good it went well :-)
garbas has joined #nixos-dev
<jtojnar> let's just merge the meson PR
<LnL> gchristensen: welcome back to the land of the living :)
<gchristensen> as mark twain says, reports of my death have been greatly exagerated. (however only one person, in jest, PM'd and asked if I was still alive)
<LnL> btw, I was thinking yesterday, we could monitor (and kill?) processes that have been running for too long on the builders
<LnL> because of the build users we can identify them, and something that's running for 6d isn't normal given the hydra timeouts
<gchristensen> that sounds really good
<gchristensen> ideally we could take a stack trace too?
drakonis has quit [Ping timeout: 240 seconds]
<LnL> you don't want data like that in prometheus, but exposing it some other way might be possible
<gchristensen> I agree
<gchristensen> even just emitted to journald would be fine, just to capture some data
<gchristensen> we don't want to stymie efforts to fix the bugs :)
lassulus has joined #nixos-dev