<samueldr>
and it's a recent log going from the timestamp
<samueldr>
oh, not from today though :/
copumpkin has joined #nixos-dev
copumpkin has quit [Client Quit]
ajs124 has left #nixos-dev [#nixos-dev]
<samueldr>
initial testing seems to show that `nix-build ./nixos/tests/installer.nix -A simple && nix-build ./nixos/tests/installer.nix -A simpleUefiGrub` will pass, but `nix-build ./nixos/tests/installer.nix -A simpleUefiGrub -A simple` fails
<samueldr>
are we betting it's likely tests run in parallel more often on epyc?
justanotheruser has joined #nixos-dev
Taneb has quit [Quit: I seem to have stopped.]
<samueldr>
same nixpkgs revision on the hosts; same nixpkgs revisions on which I nix-build; can reliably reproduce on my workstation, cannot on the laptop ¯\_(ツ)_/¯
<samueldr>
if anyone has anything to try and debug or investigate, I'm in
<samueldr>
differences between the two machines is ram (64 vs. 8 GB) and CPU (E5-1660 vs. i5-4210U [6*2 vs 2*2 core*threads]); otherwise they were really free as the laptop wasn't in use during the tests, only a terminal being started
<gchristensen>
samueldr: pretty sure epyc-1 does run multiple tests at once, indeed!
init_6 has joined #nixos-dev
init_6 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 250 seconds]
<samueldr>
I'm more annoyed at how it reliably reproduces on one machine, but not the other :/
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
<andi->
Have you considered restricting the amount of CPU flags to something which is available on all machines? Maybe that will already show if it depends on something specific of that one chip?
<samueldr>
andi-: how can I restrict the amount of cpu flags?
<samueldr>
in my local testing, at least, it's not done through hydra, and not done through a builder option, just plain native nix-build
<andi->
the qemu -cpu parameter probably
<andi->
must check what presets there are that make sense for a test..
<samueldr>
need to test with a real repro now that I know of one; but from the little research I did in the past it seems that with -kvm, it won't stop the cpu from working with these features, it just masks the flag
<andi->
yes it doesn't "protect" the CPU from executing them.
<samueldr>
and it wasn't obvious if instructions existed for those flags whether they'd work or not with qemu non-kvm
<andi->
It is just a wild guess since it seems to be specific to the epyc?
<andi->
we are already using kvm64 which is a common set of features AFAIK
<samueldr>
yeah, though my workstation is a 2012 vintage cpu; my laptop a 2014 vintage one :/
<andi->
so probably not it
<samueldr>
epyc is more recent, though it's entirely possible that an older xeon has features that a newer i* doesn't have
<samueldr>
anyway, even if it didn't that's the nix that should be in use
<andi->
Only on my work laptop that still runsn 18.09 now..
<samueldr>
the older xeon might not be on that revision, I'll update it just in case
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
<samueldr>
the older xeon powers through the build :/
<gchristensen>
(as you know, I'm happy to do remote hands stuff :))
<samueldr>
nix-build ./nixos/tests/installer.nix -A simpleUefiGrub -A simple # here when both are built simultaneously fails on one out of three machines
<samueldr>
in my test cases, it is always done on an almost unused machine, and the machine on which it fails has more cores available than the others, more memory also :/
<gchristensen>
samueldr, sphalerit, sphalerite: can we be certain to release this week?
<gchristensen>
like, if not, okay -- but we really need more communication about what is going on
<gchristensen>
it is a lot of volunteer work to organize a release -- it is okay if things are busy, or harder than expected, or not going as planned. the most important thing is to communicate the status
<gchristensen>
it also doesn't need to be perfect
<averell>
as long as you don't pull a MS-win10 18.09 update everything is cool :)
noonien has joined #nixos-dev
<gchristensen>
:)
<samueldr>
(I'm waiting for more details for the release, I thought it was good to go by today)
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 244 seconds]
drakonis_ has quit [Ping timeout: 240 seconds]
<averell>
which channel and package is this on? it might be possible to override the url or just update.
<averell>
ergh, ww
<niksnut>
btw I upgraded all my machines to 19.03 last week, very smooth upgrade :-)
<gchristensen>
nice!
<rycee>
Anybody around who has experience with the Emacs package generation? I'm looking for help updating them in Nixpkgs :-)
{`-`} has joined #nixos-dev
carter has quit [Read error: Connection reset by peer]
chrisaw has quit [Read error: Connection reset by peer]
chrisaw has joined #nixos-dev
vdemeester has joined #nixos-dev
carter has joined #nixos-dev
cocreature has quit [Ping timeout: 268 seconds]
cocreature has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
hl has quit [Read error: Connection reset by peer]
<ryantm>
rycee: Good to know that it's possible to update the emacs packages! I should try again.
<matthewbauer>
ryantm: have you ever though about getting nixpkgs-update to run emacs updates? it's kind of a different task, but since nixpkgs-update is already running it would be a pretty straightforward transition
<ryantm>
matthewbauer: I was investigating doing that the last time I ran into that issue I referenced.