<samueldr>
though am I right in assuming staging workflow is more for "this possibly will break stuff" than a "simpler"(?) patch-level update?
lassulus has quit [Ping timeout: 240 seconds]
lassulus_ is now known as lassulus
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
orivej has quit [Ping timeout: 240 seconds]
Drakonis has joined #nixos-dev
Drakonis has quit [Remote host closed the connection]
Ericson2314 has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-dev
<Enzime>
samueldr: alternatively
<Enzime>
you could branch off their PR branch
<Enzime>
and pull request your changes into their PR branch
<Enzime>
although that's not super clean if the changes aren't additive
<Enzime>
(e.g. you want to change some of their commits)
<Dezgeg>
you could name your commits such that 'git rebase --autosquash' would squash them if the original author were to run that, I guess
<Enzime>
Dezgeg: never heard of that command
<Enzime>
how does that work?
<Dezgeg>
I haven't actually used that personally, but I think I have seen other people use it
<Dezgeg>
basically, if your commit message starts with 'fixup! FOO' then git rebase --autosquash will squash that in the latest commit whose title is FOO
jtojnar has quit [Quit: jtojnar]
<Enzime>
Dezgeg: apparently you can use git commit --fixup to create such a commit
<LnL>
yeah, I'm pretty sure you can propagate revisions to other jobsets but ideally channel updates would wait for everything
<LnL>
and doing this has other disadvantages
<srhb>
gchristensen: It will eventually fail with the regular error, that's what's happened the past few days.
<LnL>
splitting the other way, by platform, would also reduce the memory footprint
<gchristensen>
niksnut: have you seen these failures due to memory problems?
<gchristensen>
new since last 8 days
<srhb>
gchristensen: The latest error message is a timeout though. I wonder if that means the evaluator has some other limitation that could just be bumped?
<srhb>
I don't recall any...
<niksnut>
I don't know what causes the timeout. The hydra-evaluator logs don't show anything.
<niksnut>
the queueu runner crashes seem to be fixed
<srhb>
(my $res, my $jobsJSON, my $stderr) = captureStdoutStderr(21600, @cmd); die "$evaluator returned " . ($res & 127 ? "signal $res" : "exit code " . ($res >> 8))
<srhb>
21600 = 6 hours, does that match?
<srhb>
Oh, is the perl stuff even running that anymore...
<gchristensen>
some places seem to be copy-pastaing it around, unless there is a secret reason I don't know about
<aminechikhaoui>
probably to override the execstart from the upstream pkg ?
<Dezgeg>
yes, if that unit is overriding some other unit with the same name, that overrides the ExecStart field instead of appending to ExecStart
<gchristensen>
that is a weird thing
<gchristensen>
why is this the way to do that?
<aminechikhaoui>
Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is not a dependency), such as AssertPathExists= (or e.g. ExecStart= in service units), one needs to first clear the list before re-adding all entries except the one that is to be removed. Dependencies (After=, etc.) cannot be reset to an empty list, so dependencies can only be added in
<aminechikhaoui>
drop-ins. If you want to remove dependencies, you have to override the entire unit.
<aminechikhaoui>
gchristensen: also in that PR systemd.packages = [ pkgs.containerd ]; makes the unit use the upstream unit definition i.e from ${pkg}/lib/systemd afaik so you don't have control over that from nix
globin has quit [Ping timeout: 260 seconds]
<niksnut>
hm, looks like hydra-eval-jobs is hanging somewhere in a boehm GC waiting on a futex
<niksnut>
never seen that before
<niksnut>
maybe boehm doesn't like fork
<Dezgeg>
any backtrace?
<gchristensen>
aminechikhaoui: weird :)
<gchristensen>
aminechikhaoui: thank you a lot
<aminechikhaoui>
yeah systemd can be weird sometimes :D
Lisanna has quit [Ping timeout: 260 seconds]
ma27 has joined #nixos-dev
ma27 has quit [Client Quit]
<gchristensen>
domenkozar: ping? where is the nix-support located in Travis's repos?
orivej has joined #nixos-dev
<vdemeester>
gchristensen, aminechikhaoui : yeah I took inspiration in other unit files (mainly docker's one)
<vdemeester>
(thanks a lot for the explanation :) )
Drakonis has joined #nixos-dev
<domenkozar>
gchristensen: I just google it
<domenkozar>
matthewbauer travis nix github :P
orivej has quit [Ping timeout: 256 seconds]
<gchristensen>
domenkozar: oh, haha, cool
<gchristensen>
we should (very soon) update the travis CI thing to use a pinned version of the nix installer
<gchristensen>
so that when 2.1 comes out, it doesn't break
<gchristensen>
back in ~30
<domenkozar>
will 2.1 break?
<LnL>
how would it break?
<LnL>
I know builtin:buildenv changed, but that doesn't matter for travis
<gchristensen>
the installer is defaulting to multi-user if possible, and the current system assumes linux means single-user
<LnL>
doesn't it run a container? I doubt multi-user would just work on travis
<gchristensen>
not always, with sudo it installs in a VM
orivej has joined #nixos-dev
init_6 has quit [Ping timeout: 244 seconds]
init_6 has joined #nixos-dev
<gchristensen>
w00t I got approval to hack on a long-term project I've been wanting to do, of making an automatic test matrix for the nix installer
<infinisil>
\o/
ma27 has joined #nixos-dev
orivej has quit [Remote host closed the connection]
<domenkozar>
nice :)
orivej has joined #nixos-dev
init_6 has quit [Ping timeout: 244 seconds]
ma27 has quit [Remote host closed the connection]
<LnL>
gchristensen: nice!
<gchristensen>
stand by for a thing to read, about what I want to do
<clever>
gchristensen: ive also discovered that it will detect sudo in your script, and silently switch you to the vm, even though you didnt ask for sudo
<gchristensen>
neat
<clever>
gchristensen: and the vm has a different version of ubuntu, with different files in /etc, that can break nixops hard
<clever>
nixops has since been fixed, but its something to beware of
<clever>
so simply adding `sudo echo` to your travis script, causes nixops to fail
<infinisil>
"This shouldn’t be written in bash." haha nice
<gchristensen>
that is a little reminder to me not to start with bash )
<gchristensen>
:)
<infinisil>
gchristensen: Shouldn't multi-user be an option one gets to choose? Or is this just whether multi-user would be supported?
<domenkozar>
why not? if you use nix+bash then it's easy to a) provision the thing b) execute
<domenkozar>
I think you only need to separate a from b
<domenkozar>
and then a can be something non-bashy
<gchristensen>
infinisil: multi-user is a result of the test, so you could imagine a "debian jessie, default options" "debian jessie, multi-user forced", "debian jessie, single-user forced"
<infinisil>
I see
<gchristensen>
domenkozar: because I'm too good at starting with bash and then sticking with it far too long and giving up because I just have a pile of soupy bash
* infinisil
is with gchristensen on that one
<domenkozar>
I give up regardless of bashing :)
<infinisil>
gchristensen: You may want to incorporate "correct failure messages" as well somehow. So when a system has way too little RAM or so, the Nix install errors out correctly, which should still count as a success
<gchristensen>
hmm yeah
<domenkozar>
infinisil: that's like v3 to me
<domenkozar>
right now we'd prefer release of Nix doesn't take internet down
<domenkozar>
on 64GB ram machine
<infinisil>
gchristensen: Also I feel like a binary result is a bit limiting. You could also have results of how long the installation took, or even per stage
<gchristensen>
I don't think anything here indicates the results are binary
<gchristensen>
other than the current example results are... :)
<infinisil>
Ah I see
<infinisil>
Right :)
<domenkozar>
gchristensen: btw this could be a project that rewrites testing framework to use libvirtd
<gchristensen>
oh my word
<Dezgeg>
doesn't sound necessary
<domenkozar>
can you spawn macos with qemu?
<gchristensen>
you can
<domenkozar>
yeah then you probably can use qemu for all of it
<domenkozar>
carry on
<gchristensen>
I dunno, v0.1 might use vagrant
<Dezgeg>
vagrant inside nix-build sounds pain
<domenkozar>
I think if testing framework was a bit more composable, it could be used here
<gchristensen>
it won't be inside a nix-build
<Dezgeg>
but one idea that I had for this kind of testing is to use the cloud images of various distros that run cloud-init
<gchristensen>
the tests to access the internet
<Dezgeg>
which means you get root execution by passing a suitably formatted emulated cd drive that cloud-init knows how to parse
<infinisil>
gchristensen: In the end it would be cool to have a 3D matrix of how this 2D tables result changed over time with the commits :P
<gchristensen>
agreed!
* infinisil
tries to think of another dimension to add
<infinisil>
This could also use some systems that are in a purposefully bad state
<gchristensen>
definitely yes!
<Dezgeg>
wouldn't probably be too hard to also integrate this with the current nixos test runner... I can't remember if I attempted that at some point
<gchristensen>
Dezgeg: I put that under "future requirements"
woffs has left #nixos-dev [#nixos-dev]
<Dezgeg>
apparently I did make some progress on that... need to re-test that
<gchristensen>
ok all this feedback has been really helpful, thank you all :) I'll definitely consider using the existing test framework for it, but I won't commit to it :)
<domenkozar>
unless somebody objects, I'm giving commit access to timokau[m]
__Sander__ has quit [Quit: Konversation terminated!]
<niksnut>
oh man, I just noticed how complex generic/make-derivation.nix has become
<niksnut>
no wonder nixpkgs evaluation is becoming so slow
<gchristensen>
all the cross stuff?
<LnL>
I've wondered before if stuff like the duplicate entries we've seen recently has impact on that
<niksnut>
gchristensen: not just, also computation of attributes like 'dependencies' (whereas we used to just pass through attributes like buildInputs directly)
<niksnut>
also, lots of calls to lib.unique, which has O(n^2) complexity
<gchristensen>
oh dear
<niksnut>
maps of maps
<niksnut>
many list concatenations
<MichaelRaskin>
I thought there was some builtin added that allowed reasonable uniq…
<LnL>
hmm, thought most of that happened at runtime
<gchristensen>
niksnut: how do you dig around the evaluation of nixpkgs to find performance problems?
<niksnut>
we don't really have good tools to do that
<gchristensen>
my novice brain thinks it'd be neat to emit data sufficient for us to generate flamegraphs
<clever>
,profiling
<{^_^}>
Use NIX_COUNT_CALLS=1 and/or NIX_SHOW_STATS=1 to profile Nix evaluation
<clever>
gchristensen: ive mostly used these, and just brute-force
<clever>
at one point, i discovered that the nixops made by nixops's release.nix via IFD was adding over a gig to the nixops deployment,because it was being imported by every host in the cluster
<gchristensen>
oh dear
Drakonis has quit [Remote host closed the connection]
<MichaelRaskin>
Isn't there deduplication?
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
Ericson2314 has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-dev
orivej has joined #nixos-dev
xeji_ has quit [Quit: WeeChat 2.0]
<gchristensen>
is qemu as exhausting to everyone else as it is to me?
<clever>
gchristensen: i dont really have any issues with it
<clever>
and ive read over its command line args page 2 or 3 times, in full
<gchristensen>
that explains it :P
xeji has joined #nixos-dev
xeji has quit [Quit: WeeChat 2.0]
<aszlig>
gchristensen: what's so exhausting?
<samueldr>
aszlig: oh, thanks for the fix, I must have failed at looking it up :/ I'll keep in mind to try even more
<aszlig>
samueldr: yeah, although i don't really feel confortable using read for the passphrase :-/
<aszlig>
samueldr: because this can leave artifacts of it in memory, as commented on that PR
<aszlig>
let alone rm'ing it from a ramfs
<samueldr>
hm, maybe I conflated the "leaky read" issue with the memory safety issue when re-reading
sir_guy_carleton has quit [Quit: WeeChat 2.0]
Lisanna has joined #nixos-dev
<gchristensen>
aszlig: I don't know what I'm doing and don't know what I don't know, mostly
init_6 has joined #nixos-dev
<aszlig>
gchristensen: what are you trying to do then?
<gchristensen>
aszlig: I want to boot an arbitrary qcow2 file (specifically, a vmdk of debian jessie which I converted with qemu-img convert -f vmdk -O qcow2 ./the.vmdk $out) , and am getting nothing after "Booting from Hard Disk..." . I want to have stdio be the console of the vm
<aszlig>
gchristensen: the image is configured so it sends output to virtio-serial, right?
<gchristensen>
I hope so :) but maybe not, I'll mount it and look around. this is my run command: qemu-system-x86_64 -m 2G -smp 2 -enable-kvm -nographic -serial mon:stdio -no-reboot -vga none -net none ./image.qcow2
<clever>
gchristensen: what about -curses ?
<aszlig>
-curses would also work, if you don't have serial output
<aszlig>
qemu then tries to graphically match the font
<aszlig>
otherwise, try -serial pty
<gchristensen>
(looking in to -curses)
<aszlig>
or remove the mon:
<aszlig>
(except if you want to have direct access to it)
<aszlig>
s/it/the monitor/
<gchristensen>
I'd rather avoid -curses, I don't need the monitor
<clever>
gchristensen: do you know if serial console is actually enabled?
<aszlig>
gchristensen: okay, then -serial pty or stdio should be fine
<aszlig>
clever: 01:27 < gchristensen> I hope so :)
<samueldr>
for automated (r-ryantm mostly) updates that are "blocked", for various reasons, is there something we could do to mark them, is there an appropriate tags we should use?
<samueldr>
some of them will be fixed in due time (regressions in dependent software, regressions in upstream)
<samueldr>
some of them could mean platform-dependent changes need fixes (darwin mostly)
<samueldr>
oh, I'd instinctively assume anything vagrant won't have serial, as it's expected to have ssh