aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
cjpbirkbeck has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
orivej has joined #nixos-dev
<angerman>
where would I find documentation on hydra, and why we conceptually need to separate eval and build?
<angerman>
I have some rough ideas as to why, but would like to get those confirmed in an authorative way.
MichaelRaskin has quit [Quit: MichaelRaskin]
FRidh has joined #nixos-dev
cjpb has joined #nixos-dev
cjpbirkbeck has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 240 seconds]
cjpb2 has joined #nixos-dev
jonringer has quit [Ping timeout: 250 seconds]
cjpb has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-dev
pie__ has quit [Ping timeout: 246 seconds]
<globin>
gchristensen, niksnut: channels seem to not be getting bumped
<ivan>
angerman: eval is safe and not architecture-specific, also the meta determines where to build the package
<angerman>
ivan: that is only true up to IFDs I'm afraid.
<globin>
angerman: IFD is not allowed on hydra
<angerman>
globin: well... is that stated anywhere? E.g. that using IFDs will fundamentally violate assumptions hydra makes?
<FRidh>
Why would that be assumptions?
<angerman>
I think I've seen ifds work on hydra
<FRidh>
yes, it happens, but we should avoid it
<angerman>
why? conceptually or because hydra doesn't support them properly?
<FRidh>
in my opinion 1) conceptually because you cannot separate eval from build step and 2) practically nix and thus hydra will perform a build step as part of eval
<angerman>
FRidh: why can't I separate them?
<FRidh>
angerman: it becomes impossible to perform a full evaluation without also doing one or more builds to get the IFD data you will continue to evaluate
<angerman>
FRidh: do I always *need* a full evaluation?
<FRidh>
angerman: that depends on what you expect a tool such as nix to do. If I am using a tool like Nix, i would expect to always be able to perform a full evaluation.
<angerman>
FRidh: even across multiple architectures?
<FRidh>
angerman: why would that be relevant?
<FRidh>
architectures are only relevant in building step, for eval it should not matter
<angerman>
FRidh: only if you are fine with pre-computing nix expressions for all your target architectures :(
<FRidh>
angerman: you will have the data already somewhere, its just not in a format nix can deal with. That's why IFD is (typically) used, so the conversion can be done without checking in converted code or data
<angerman>
FRidh: what if generating the nix depends on the architecture you run the conversion tool on?
<angerman>
FRidh: say you have a package that has changing dependencies if you target say linux, mac or windows?
<FRidh>
angerman: as I said before, typically the data (deps per arch) is already described. It's just the tooling that doesn't offer you a direct way to extract the information and make it importable by nix. This is especially the case in imperative formats (such as setup.py in case of python).
<angerman>
FRidh: right. I've been working on haskell.nix, which makes heavy use of IFDs to get dependencies, and flags, and ... right.
<FRidh>
angerman: yes, it's very convenient. It just breaks the separation between eval and build. Then you have to choose, pragmatism or not.
<angerman>
FRidh: and the issue with separation between eval and build is relevant only because of... hydra?
<FRidh>
angerman: from a practical point of view, we've chosen not to want it on hydra because it loads the evaluator.
<aanderse>
a pr removed openssl from msodbcsql17 and i approved it because i tested it with php and perl
<clever>
looks good at a glance, and improves the cross-compile support for it
<aanderse>
so i thought everything was ok, sure
<aanderse>
i didn't test isql
<aanderse>
>_<
<aanderse>
yeah anywho, reading the docs from microsoft and then running ldd on the old and new version to understand what the PR that "broke" this was doing... it all makes sense now
<aanderse>
thanks for looking
<aanderse>
not sure if i can do a clean cherry pick for the backport or not because there have been some other changes in the module
<aanderse>
oh well
<aanderse>
** module = package
<andi->
When do we stop supporting 19.03? (/me looks at backporting rustc to 19.03 and pukes)
<gchristensen>
sounds like now!
<ivan>
+1
<andi->
While I wouldn't mind that it also isn't compatible with my quality targets :/ Abitrary deprecation before the "promised" month is over.
<infinisil>
andi-: Usually it's one month after the new stable release
<infinisil>
s/one/for one
<andi->
infinisil: yeah, I know... I think we should try harder.. I'll try for another hour.
<niksnut>
uh oh, looks like github changed the ETags they return for tarballs