jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
ris has quit [(Ping timeout: 255 seconds)]
jtojnar has joined joined #nixos-dev
zraexy has quit [(Ping timeout: 268 seconds)]
mbrgm has quit [(Ping timeout: 255 seconds)]
mbrgm has joined joined #nixos-dev
_ts_ has quit [(Ping timeout: 248 seconds)]
orivej has quit [(Ping timeout: 240 seconds)]
orivej has joined joined #nixos-dev
zraexy has joined joined #nixos-dev
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
MichaelRaskin has quit [(Quit: MichaelRaskin)]
ma27 has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 246 seconds)]
vcunat has joined joined #nixos-dev
vcunat has quit [(Client Quit)]
vcunat has joined joined #nixos-dev
<orivej>
vcunat: Shall we merge staging at 9ae72f2 to master? (Hydra has abandoned our evaluation https://hydra.nixos.org/eval/1412641, the number of queued jobs has not changed for hours; all of them are for x86_64-linux.)
<vcunat>
We can try.
<vcunat>
orivej: but I'm afraid that with those jobs stuck we won't get a channel update on that.
<orivej>
vcunat: Could you try to cancel the whole evaluation? If they disappear from https://hydra.nixos.org/machines, I'd expect that they will be evaluated once in master.
<vcunat>
orivej: done; I'm not so confident about that.
_ts_ has joined joined #nixos-dev
<vcunat>
I believe cancelling whole evaluation is equivalent to cancelling each build separately.
<orivej>
You must be right, the machines are "busy" running the cancelled jobs. Who can restart or operate Hydra? niksnut?
<vcunat>
yes
<vcunat>
I'm not sure about anyone else in particular having access
<orivej>
ok, let's wait with the merge until these builds are cancelled (or a future evaluation of staging completes)
<orivej>
"nix-build ./nixos/release.nix -A tests.wordpress" works for me
<gchristensen>
yeah ... user error :)
<gchristensen>
I'd done a silly thing in my test checkout
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
mbrgm has quit [(Ping timeout: 255 seconds)]
FRidh has quit [(Quit: Konversation terminated!)]
mbrgm has joined joined #nixos-dev
vcunat has quit [(Quit: Leaving.)]
ma27 has quit [(Quit: WeeChat 1.9.1)]
ma27 has joined joined #nixos-dev
phreedom has quit [(Ping timeout: 240 seconds)]
ma27 has quit [(Ping timeout: 255 seconds)]
phreedom has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 240 seconds)]
<aszlig>
orivej: oh wait, you stumbled upon the same regression?
<aszlig>
(i'm speaking about the legacy ssh store)
michaelpj has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
michaelpj has joined joined #nixos-dev
<orivej>
aszlig: yes, I've not figured out the exact conditions of its presence, but they involve Nix 1.12 and remote building; probably ssh store too
<orivej>
I was told that "nix build" followed by "nix log /nix/store/....drv" may be used instead of "nix-build" to see the build log
<ekleog>
hmm, I wondered, if I change the definition of the derivation for eg. package-X.Y.Z without bumping the version, for some reason (adding a dependency needed by some rarely-used feature, etc.), am I supposed to bump the version to eg. package-X.Y.Z-nix1 or whatever? if not, would it be anti-nix to require this? (I was thinking of writing a tool for getting a human-readable diff between two nixos generations
<ekleog>
in order to generate apt-listchanges-like logs, and such a requirement would come in very handy in order to make a difference between “this package changed because its dependencies were updated” and “this package changed because its nix expression changed”, the case “this package changed because its version was bumped” being already taken of by the version number)
<aszlig>
orivej: i'm currently bisecting this
<aszlig>
orivej: well, i'd still consider this a regression, because if you actually *want* the log you won't get it
<aszlig>
well, except afterwards of course
<aszlig>
but you'd have to specify the build-slave directly either via NIX_REMOTE or --store
<aszlig>
which at least for my infrastructure won't work because nobody gets access to the build slaves directly
<orivej>
ekleog: the requirement to maintain "-nixV" suffix seems burdensome. If your tool is able to say what has changed with the version bump, it does not actually have to look at the version; and if not, just saying that "-nix1" is now "-nix2" is not very useful. You may be interested in looking at nox-update: https://github.com/madjar/nox#experimental
<ekleog>
that's quite fun, I was actually looking around it! though searching for how to disable the “accepted connection from pid X, user Y”, as this logging when using nox-update consumes megabytes of disk space if I can believe iotop
<ekleog>
that said, debian etc. do use a “dX” (or similar, can't remember) suffix -- then, maybe the information can be fetched from the .drv, but based only on the built files I don't think it would be possible to figure out whether the expression for building (like the builder) changed or its dependencies changed, unless maybe running a diff on the whole hierarchy to check whether changes are just sed's of
<ekleog>
the dependencies -- and then that would fail for all non-reproducible builds at least
<orivej>
the check for "has the expression or the dependencies changed" should be performed on .drv, not on the results of the build. this is what I expect nox-update to be doing.
<orivej>
the disk activity you see may be caused by writing .drv files rather than by logging "accepted connection"
<ekleog>
hmm, wait, how would nox-update be writing .drv files? aren't they supposed to be already generated?
<orivej>
it should be calling "nix-instantiate" that writes .drv files
<ekleog>
hmm, I don't really get why it should be calling nix-instantiate, given it takes as arguments old-system-path and new-system-path?
<orivej>
it has to read .drv to do its job, and there are no such .drv in the store before nix-instantiate
<orivej>
(i mean, there are some .drv, but not all of them)
Sonarpulse has quit [(Ping timeout: 252 seconds)]
<ekleog>
erhm. in my mind nix always first computed the .drv, then stored them, then tried to use substituters to download the built, I guess I misunderstood
<ekleog>
(also, you're right, I just tried and there are “only” 2KB of “accepted connection” after journalctl compression, thanks for the pointer! guess I'll have to read more about when exactly a .drv is stored)
<orivej>
nix writes .drv only for the stuff it builds, not the stuff it downloads from the substituters
<orivej>
because .drv is a build recipe
<ekleog>
hmm, there must be something more: I've had 3MB/s of disk write for the past 10s, and `l /nix/store | wc -l` didn't change :/
<aszlig>
orivej: bisected the error and fixed it, PR incoming