<infinisil>
domenkozar: niksnut: gchristensen: There's 3 people in #50105 (aanderse, dasJ, marsam) that are interested in becoming a committer. I think all of them are fit for it. It would be awesome if any of you could give them commit rights, we could really use more help with nixpkgs maintenance.
<gchristensen>
t2a6 is especially interesting since it has been shut down for a few days now
<srhb>
Seems like something systemic is up with Hydra.
<gchristensen>
ok, niksnut is taking a look at them before they get killed
<srhb>
Sounds great :)
<samueldr>
confirmed cpu feature detection non-reproducibility issue with sage things and the machine named "hydra"; from the popcnt feature most likely considering my local repro steps
<samueldr>
decisions might need to be made with regards to how nixpkgs should handle those situations; and lowest common denominator builds might not be acceptable in all cases
<samueldr>
one of the issue is steps/jobs distribution in hydra, if nauty is built on pretty much any machine other than "hydra" it will enable popcnt, so anything using nauty might end up failing on that "hydra" machine in the build farm
<samueldr>
this is a generally trivial issue to solve with machine features with nix, I think (though maybe there are some drawbacks?)
<samueldr>
gchristensen: for r13y, it might be helpful to figure out a way to integrate build logs diffing, here the behaviour is identifiable in a "checking" step in configurePhase
<gchristensen>
I agree
<gchristensen>
also the temporary directory from the build would be very useful
<timokau[m]>
If we do this with hydra features, would it be possible to serve the users the right substitute?
<gchristensen>
timokau[m]: software is moving in that direction as reproducible builds become more desired
<arianvp>
I guess it's too late to get MESA 19 into 19.03 right?
<arianvp>
current MESA version's radeon driver borks all vulkan implementations
<timokau[m]>
Then maybe sticking with lowest common denominator for now would be best?
<arianvp>
meaning things like steamvr don't work on 19.03
<arianvp>
s/steamvr/steam
<samueldr>
I think it depends on what kind of cpu generation nixpkgs intend to be compatible with... BUT in that case it should never switch packages from using and not using those features :/
<samueldr>
not sure what other distros do about that kind of thing
<samueldr>
arianvp: I think it goes with how disruptive the change is vs. without the change, but I'm no MESA buff
<samueldr>
arianvp: the only thing I know is it seems it might be difficult to gauge without asking around and proper testing :/
<timokau[m]>
samueldr: I don't think we should cut off machines from 07
<samueldr>
yeah, thinking in a really more general sense
<timokau[m]>
But we probably already serve different binaries for 32 bit and 64 bit right? Or do we even support 32?
<samueldr>
though in another way, those are pretty much first to second generation x86_64
<samueldr>
different arch, i686
<samueldr>
it's not as easy and cut and dry with cpu features :/
<arianvp>
the "Stable" version of MESA 19 was released last week, so I don't foresee much issues
<gchristensen>
since we've never reliably built a working binary supporting that old one, I suggest its fine
<timokau[m]>
We could introduce a pseudo arch, grouping some commonly available features vs. no features (could we?)
<gchristensen>
arianvp: it is pretty tough to backport a big thing like that, so close to release
<arianvp>
I've been trying to pinpoint _why_ vulkan applications are failing in the first place, to see if there is some minor patch we can apply instead
<arianvp>
but no success so far, except that vulkan does seem to work again with MESA 19
<samueldr>
gchristensen: though if it means all vuklan+amd being broken without that, it becomes a bit of a balancing game :/
<gchristensen>
that is true
<arianvp>
I prefer if I can game the next few months :P
<arianvp>
problem is I don't know much about mesa.
<arianvp>
I have an alternative idea that could fix this as well. and that is add a nixos option that allows people to use AMD's amdvlk driver for vulkan instead of mesa-radv
<arianvp>
as that one seems to work fine.
<arianvp>
that shouldn't interfere with mesa at all.
<arianvp>
Oh nvm false alarm i'm mis-reading the thread
<arianvp>
it works for 19.03, just doesn't work for master
<andi->
I was about to comment about having played vulkan games all weekend on 19.03 ;)
<arianvp>
I'll make a PR to the release notes with that advice in it =)
<arianvp>
so again mutable state is the culprit of all evil it seems
<arianvp>
=)
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.3]
Mic92 has joined #nixos-dev
<gchristensen>
samueldr, srhb btw the problem is due to some memory tweaks which were made on hydra, causing a deadlock when allocating memory tokens, making the build results too large to be receivable
<gchristensen>
additional tweaks have been made :)
<srhb>
gchristensen: Thanks for the update :)
jtojnar has quit [Quit: jtojnar]
aanderse has joined #nixos-dev
<aanderse>
hello i'm looking for someone to backport to 18.09 apache version 2.4.39
<gchristensen>
aanderse: mind opening the PR with the backport?
<aanderse>
gchristensen: certainly
<gchristensen>
`git cherry-pick -x` the commits which fix it
<infinisil>
-xe*
<infinisil>
Oh
<gchristensen>
if you want to be fancy about it :P
<aanderse>
against release-18.09 yes? (ie. not staging)
<infinisil>
(Just lookup what the -e does, it just opens the editor for changing the commit message, man I've always thought that would do something more useful)
<infinisil>
aanderse: Yeah I think release-18.09
<infinisil>
Although ryantm's bot used staging in #58621
<infinisil>
worldofpeace: I thought of bringing this up in this chat before merging :)
<worldofpeace>
Ha, it's always a game right? Who's gonna merge
<infinisil>
Yeah, but I'd rather leave this to somebody else, especially for a non-trivial PRs
<infinisil>
So, does anybody here have strong opinions about above PR?
<Taneb>
I think it's a good idea, it would definitely encourage people like me to try and review more PRs
genesis has quit [Remote host closed the connection]
genesis has joined #nixos-dev
<worldofpeace>
FTR I think we had a good raising of awareness in the PR, and I'm looking for collaborators to continuiously improve the review experience
drakonis has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis1 has joined #nixos-dev
<infinisil>
Alright I think we're good to merge then :)
<infinisil>
worldofpeace: Feel free to do the thing
<worldofpeace>
infinisil: I though we were going to rock paper scissors 😇
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
<infinisil>
Hehe, I'd rather not for my own PRs, doesn't feel right ya know
<worldofpeace>
Right, feels kinda onesided for a contribution
orivej has joined #nixos-dev
<worldofpeace>
Hmm, does the change to template need to be backported? Or does github just always use the one from the primary branch.
<infinisil>
(Well, the primary branch yeah, not necessarily master)
<worldofpeace>
Yep. Also double checked against 19.03 just to be sure
aanderse has quit []
orivej has quit [Ping timeout: 250 seconds]
<samueldr>
matthewbauer: do you have a good one-liner description for #50212? To add in release notes. This sure looks spiffy, and might be worthy of a mention in the release notes to get eyes on that bit?
<matthewbauer>
samueldr: basically it provides an easy way to emulate other systems in Nixpkgs. the main use case is when you are cross compiling and you want to run something on the target system although other use cases are possible. the typical usage is something like: ```${stdenv.hostPlatform.emulator buildPackages} ./executable-to-run```
<samueldr>
oh, I know what it does, and it's neat, I'm looking for a one-liner that would fit in the release notes
<gchristensen>
would you might writing up 1-3 paragraphs with a brief example? :)
<gchristensen>
or link to docs
<samueldr>
(that would be even better, since in the PR I think there were no documentation added)
<samueldr>
it's more that I don't grok it, so I'm not trusting anything
<samueldr>
* I write about it as being good enough
<gchristensen>
it would be interesting to consider ways to avoid needing to go through 6mo (how many thousands?) of commits
<samueldr>
I'm going with some kind of priority; lib/ is combed through finely, then nixos/ is looked at attentively, nixos/modules first then all of it less attentively, then pkgs/ is where it gets a bit harder, but there's not much in there :)