gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 18.09 release managers: vcunat,samueldr | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
alunduil has joined #nixos-dev
alunduil has quit [Client Quit]
alunduil has joined #nixos-dev
alunduil has quit [Client Quit]
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
elvishjerricco has quit [Ping timeout: 258 seconds]
<samueldr> too many heap sections @ ~17:33 UTC https://gist.github.com/samueldr/be771f51d6b5f24f1f129bc2b3749bbb
elvishjerricco has joined #nixos-dev
elvishjerricco has quit [Max SendQ exceeded]
elvishjerricco has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.3]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
avn has quit [Ping timeout: 268 seconds]
avn has joined #nixos-dev
<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.
<{^_^}> https://github.com/NixOS/nixpkgs/issues/50105 (by Infinisil, 20 weeks ago, open): New nixpkgs committers requirements/process
MichaelRaskin has quit [Quit: MichaelRaskin]
orivej has joined #nixos-dev
<domenkozar> will take a look :)
<domenkozar> seems like ryan opened ~200 PRs in last 3 days
<domenkozar> sorry, that many are unmerged
drakonis_ has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
<srhb> There's four quite suspect jobs going currently: https://hydra.nixos.org/build/91217039 https://hydra.nixos.org/build/91217039 https://hydra.nixos.org/build/91298077 https://hydra.nixos.org/build/91287586 -- that last one has a step "receiving outputs" and has been going in total for 3d. That doesn't seem right, even for GHC, does it?
<globin> srhb: that definitely isn't normal
<srhb> I am pondering killing them and restarting .
<srhb> I doubt they will ever complete
<srhb> but if someone wants to debug first, I don't want to disrupt that :)
<srhb> gchristensen?
<globin> srhb: don't think you can kill those from the interface actually
<gchristensen> srhb: go ahead
<srhb> globin: You're right
<srhb> Needs project admin to clean up :)
<gchristensen> oh
<gchristensen> ok, I can do it in a bit :)
<srhb> gchristensen: Thanks.
* gchristensen doesn't like to ssh decaffeinated
<srhb> gchristensen: God no. :-)
<infinisil> domenkozar: Awesome thanks!
<infinisil> domenkozar++
<{^_^}> domenkozar's karma got increased to 22
<srhb> Hmm, it's a lot worse than just those four.
<srhb> https://hydra.nixos.org/machines -- see the packet aarch64 machines, several multi day jobs running.
<srhb> oh, t4b too..
<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?
<samueldr> I don't think so
<samueldr> and it would probably be a bad idea?
<samueldr> I mean, doing it surreptitiously
<timokau[m]> What I've been doing for some packages is add an `optimize` option that throws out all attempts at being reproducible and instead goes for the best performance on that machine: https://github.com/NixOS/nixpkgs/blob/ad71d9b0d5bbbcbf4c5364fee40f116dba778aea/pkgs/development/libraries/givaro/default.nix
<samueldr> what might be possible is something like nauty-optimized and nauty-compatible
<timokau[m]> That would go nicely together with oxijs use-flags
<timokau[m]> Resulting in a gentoo-like experience
<gchristensen> how old is hydra?
<timokau[m]> samueldr: Yeah I'm not sure it is worth it for most software
<samueldr> timokau[m]: where it is needed, obviously
<timokau[m]> Would be kind of nice if cpu feature detection was moved to runtime, although that would probably introduce its own heap of funny bugs
<samueldr> launch date of the cpu in it was Q4'07 gchristensen
<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
<{^_^}> #57770 (by shirona, 2 weeks ago, open): Vulkan applications no longer work
<arianvp> \o/
<arianvp> so I have another 3 months to fix it :P
<arianvp> or not... 19.03 seems to be running the probelmatic 18.3.4 version as well now
<arianvp> I just found this comment: https://github.com/NixOS/nixpkgs/pull/56022#issuecomment-465531259 i'm gonna try this
<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
<{^_^}> #58947 (by aanderse, 17 hours ago, open): apacheHttpd: CVE-2019-0211
<aanderse> this is a pretty serious vulnerability
<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
<{^_^}> https://github.com/NixOS/nixpkgs/pull/58621 (by r-ryantm, 3 days ago, merged): apacheHttpd: 2.4.38 -> 2.4.39
<aanderse> i'm looking to get this into production today if possible
<gchristensen> aanderse: right
<infinisil> I wish I could see the number of rebuilds a PR caused after it was merged
<gchristensen> for 18.09, let's skip staging.
<aanderse> gchristensen: infinisil: thank you both very much
<aanderse> gchristensen++ infinisil++
<{^_^}> gchristensen's karma got increased to 95, infinisil's karma got increased to 74
<gchristensen> oh nice, infinisil
<{^_^}> #58967 (by aanderse, 25 seconds ago, open): apacheHttpd: 2.4.38 -> 2.4.39
<aanderse> will give bot a few moments to do its thing then we can run some tests
<gchristensen> do you know the nixos test which covers apache?
<aanderse> looking now
<aanderse> there are a few that use it i believe
<aanderse> owncloud is a good test as it uses mod_php i believe
<aanderse> erm... ignore that last comment :)
<srhb> aanderse: I think that's dead.
<aanderse> too many things on the go
orivej has quit [Ping timeout: 245 seconds]
<aanderse> srhb: yes, it is dead, but in the 18.09 branch the test and subservice still exist
<srhb> Oh, right.
<srhb> php-pcre maybe
<aanderse> upnp, proxy, and owncloud are all reasonable and test different aspects
<aanderse> hmm... i'll swap owncloud for wordpress
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
<gchristensen> gutsy, calling all three tests in the same ofborg call ;)
<aanderse> ha ha ha
<aanderse> yeah that is a very good point
<aanderse> i've seen that fail more than once
<aanderse> oops
<gchristensen> no worries
srhb has quit [Quit: ZNC 1.7.2 - https://znc.in]
srhb has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
<aanderse> gchristensen: infinisil: all tests passed
<gchristensen> thanks!
<infinisil> aanderse: Merged it, thanks :)
<aanderse> <3 infinisil
<{^_^}> infinisil's karma got increased to 75
<samueldr> ouch srhb
<samueldr> we need to slim the aarch64 sd image stat!
<samueldr> (sorry to rope you in, I just saw you talk on #nixos)
<samueldr> it's pretty likely it will still exceed the output size whenever it catches up
<srhb> samueldr: Yeah, can probably look but not until the weekend :/
<srhb> And no reason to be sorry, unblocking or diagnosing Hydra channel stuff is basically what I do most.. :P
<samueldr> well, I was just flagging that it will probably hold back the channel for coming builds too :/
<samueldr> though I can tip you off: the image build was already close to the limits
<srhb> Yeah. I might not have time to fix it. Got some personal server issues today. But I'll look if I have a chance.
* srhb nods
<samueldr> hmm
* samueldr thinks there might be some weirdness
<samueldr> the logs don't seem to agree?
<srhb> Inconceivable!
<samueldr> or maybe it's benign, the "sqlite databse is busy" https://hydra.nixos.org/build/91227965/nixlog/4
<samueldr> I thought the logs would show that the output limit would exceed anyway
orivej has joined #nixos-dev
<srhb> That sounds benigh.
<samueldr> :/ and you can't shave off from the ext4 image anymore: the few bytes left are required for it to boot
<samueldr> (the image is resized to fit the data in snugly)
<samueldr> might look into it during the week-end too, or when 19.03 has been kicked off
drakonis has joined #nixos-dev
thefloweringash has quit [Ping timeout: 264 seconds]
thefloweringash has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
<worldofpeace> infinisil: shall I do the honors or should I leave it too you? :) #58098
<{^_^}> https://github.com/NixOS/nixpkgs/pull/58098 (by Infinisil, 1 week ago, open): PULL_REQUEST_TEMPLATE: Add encouragement to review PRs
<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> Yeah github uses the master branch always I'm pretty sure
<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?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/50212 (by matthewbauer, 20 weeks ago, merged): Add "emulator" function to systems
<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 :)
<gchristensen> hmm cool
<samueldr> lib/ is less than a screenful
<gchristensen> <3