<gchristensen>
niksnut: thank you for releasing! I had this idea in my head that you don't really like to release unless there is a bunch ready to be released. I'm glad that wasn't true, it is really fun seeing my docs changes go live.
orivej has quit [Ping timeout: 244 seconds]
<niksnut>
no, point releases can be done at any time
timokau_ has quit [Ping timeout: 246 seconds]
<gchristensen>
makes it more fun to send fixes :)
<gchristensen>
aszlig has made a docbook validation tool which can combine-and-validate at the same time, giving local error messages instead of "error at line 17,000,000,000 of manual-combined.xml"
orivej has joined #nixos-dev
<aszlig>
gchristensen: yeah, although it does still have a small problem with xinclude and parse="text"
<samueldr>
manveru: the gradient editor is... badly designed; you need to use the gradient tool, and in the toolbar at the top you'll be able to edit the stop points :/
orivej has quit [Ping timeout: 260 seconds]
<manveru>
ah, thanks, seems like that changed :|
<ekleog>
gchristensen: this question may be stupid, but… why would there be a deadline for backporting this? that's strictly a new feature, not breaking backwards-compatibility in any way, so why wouldn't it be back-portable like a new package or similar?
<samueldr>
manveru: yes, in the version present in 18.03 it had a different interface... I don't like the new one
<gchristensen>
well new features and packages typically don't get backported
<ekleog>
iirc the backporting guidelines, new packages can be backported if someone requests them
<gchristensen>
typically not, but exceptions are sometimes made
<samueldr>
ekleog: yeah, stable *should* mean feature freeze; new features and such in nixpkgs and nixos modules shouldn't really get backported :/
<samueldr>
but it's... not so well defined already, and some were started before and in "review hell", or other reasons... don't know what to say half the time
<samueldr>
gchristensen: if you write a test case to ensure no regressions happened, (if there wasn't one) it probably can be argued successfully into backporting
<samueldr>
ekleog: *packages* :)
<gchristensen>
samueldr: what is it you would expect the test to test? that by default the date is 48 years ago?
<ekleog>
indeed, modules are more borderline because it's like updating the source code of a virtual “nixpkgs” package :) we really should get a RFC for exact backporting guidelines for all use cases :( vcunat said he had a WIP section in https://github.com/NixOS/nixpkgs/pull/43889#issuecomment-407131071 , but sounds like it didn't concretize :/ will poke
<samueldr>
ekleog: yeah, with everything I'm doing I'm amassing thoughts and notes to refresh my RFC for backporting
<samueldr>
gchristensen: to be fair, I haven't looked (yet) closely into the change, maybe a "date is epoch+1" for the default, and... don't know how "now" can be tested exactly as now is a fleeting moment in time :/
<samueldr>
if it is even a testable feature
<ekleog>
samueldr: hmm, maybe a separate RFC? this would make refering to it easier, as what to backport isn't necessarily tied to the existence of a backports team :)
<samueldr>
ekleog: possibly yes, though still related; an RFC really focused on the what-ifs of a backport, and an RFC for how-to of a backport?
<ekleog>
(anyway, that's just nit-picking, great to know you're actually doing the compiling rules on backporting :D)
<gchristensen>
this also works: nix-env -iE '_: ((import <nixpkgs> {}).jq.overrideAttrs (x: { meta.outputsToInstall = [ "man" "out" ]; }))'
<samueldr>
(how-to being more about the process of ensuring nothing slips away)
<gchristensen>
oops
<ekleog>
yeah, I was thinking a RFC for what-to-backport (the backporting guidelines) and a RFC for how-to-not-miss-a-backport (the current backports team RFC, basically) :)
<samueldr>
yeah, probably easier so we don't trip on the details of one of those parts blocking the details of the other
<ekleog>
not like the RFCs are going to get merged anyway :°
<samueldr>
gchristensen: now that I have looked, I see what changes you have made and it's not as much "adding the possibility to set a date" as it is "adding the possibility to seed now() as the date", so yeah, not sure how much testing can be done :)
<samueldr>
(I initially assumed that it was hardcoded to only allow epoch+1)
<gchristensen>
samueldr: ah!
<gchristensen>
samueldr: though I have written a test ... :)
<samueldr>
probably won't hurt :)
<LnL>
gchristensen: your images where not built in 1970?