[08:21] <lordievader> Good morning
[13:27] <coreycb> sahid: I think once we get cinder updated for focal the remaining tempest failures will get resolved
[13:32] <sahid> coreycb: i was not able to fix the issue that you had for merging so i created an other snapshot
[13:32] <sahid> which is comming with some dependencies versions that i need to bump up
[13:33] <coreycb> sahid: ok need a hand with the dependencies?
[13:33] <sahid> thank you that should be fine i will ping you to merge when ready
[13:34] <sahid> can you have a look at python-ironic-lib and python-openstacksdk
[13:34] <sahid> they are ready I guess
[13:34] <coreycb> sahid: yep
[13:35] <sahid> coreycb: also i don't understand the problems with alembic, python-mistral and python-neutron-lib
[13:35] <sahid> if you can have a look
[13:35] <coreycb> sahid: ok I'll take a look
[14:21] <jamespage> sahid, coreycb: https://bugs.launchpad.net/ubuntu/+source/pyrsistent/+bug/1860422 needs a bit of love
[14:22] <coreycb> jamespage, sahid: I'll take a look
[14:23] <sahid> jamespage, coreycb ack
[14:50] <coreycb> sahid: python-ironic-lib and python-openstacksdk uploaded, thanks
[14:51] <sahid> ack
[15:13] <coreycb> sahid: jamespage: everything in ussuri-staging is now promoted to ussuri-proposed. matplotlib and networkx will build successfully once the pandas SRU for bionic is released (tomorrow hopefully).
[15:14] <jamespage> coreycb, sahid - could we take a look at removing python3-keyring from our dependency chain in Openstack? see comments on https://bugs.launchpad.net/ubuntu/+source/jeepney/+bug/1861268
[15:16] <coreycb> jamespage: sure
[15:25] <coreycb> sahid: hmm, python-openstacksdk is hitting some timeouts
[15:57] <coreycb> jamespage: looks like python3-pyrsistent is already in main. updating the bug to say that.
[18:34] <smoser> bryce: if you're around.. https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/378282 is happy now (i think) and the '-B' simplifies things.
[18:35] <bryce> smoser, great, thanks.
[18:37] <smoser> i guess that a nwere version of 3.6 must have come in with the -B flag that you thougt was not available until 3.8
[18:37] <bryce> yeah I was just wondering the same
[19:22] <slimschwifty> Hey all, I'm looking for some advice. I'm upgrading my existing headless ubuntu server and plan to add an RX 580 to help encode my DVR captures. The server doesn't have any GUI as it never needed it, but I believe I need one to utilize the vaapi acceleration with ffmpeg. Is lubuntu-gtk-core my best bet for an absolute minimal GUI for this purpose or is there a better alternative?
[19:24] <bryce> slimschwifty, not really a server question, but I think it might be possible to run pure X.org with no WM.  Depends on what you're trying to maximize/minimize I guess.
[19:25] <bryce> however it seems like there must be a way to run ffmepg even with vaapi, without any X/Wayland at all.  But that may be more a question for ffmpeg folks
[19:26] <slimschwifty> I may be misunderstanding the requirements. I'll try the ffmpeg folks, thanks
[20:01] <Sven_vB> hi! I'm using xinetd on xenial to guard a weak proxy from being overrun. I do this by limiting the number of instances my xinetd proxy service is allowed to have. when apt tries to hammer it, xinetd blocks it. is there a way to have xinetd instead hold up to a few hundred connections in limbo until it's their turn to be served?
[20:02] <Sven_vB> to clarify, "xinetd proxy service" is a xinetd service that netcats to the real proxy.
[20:10] <Sven_vB> wow, even with cps = 512000, "Deactivating service ??? due to excessive incoming connections."
[20:10] <Sven_vB> maybe I underestimated how intense apt update really is
[20:12] <Sven_vB> even if I increase to "instances = 2500" and of course reload xinetd
[20:12] <Sven_vB> I wonder just what is happening
[20:21] <Sven_vB> as a stopgap I'll use a node.js connection limiter in front of xinetd.
[20:21] <Sven_vB> but would be nice to have a more basic solution.
[20:25] <sdeziel> Sven_vB: nowadays, I use systemd-socket-proxyd instead of xinetd
[20:25] <sdeziel> dunno if it's available on Xenial but it is on Bionic
[20:25] <Sven_vB> sdeziel, thanks, I'll try that.
[20:25] <Sven_vB> can it hold connections idle until the service is ready?
[20:26] <Sven_vB> "ready" as in, below limits again
[20:26] <sdeziel> Sven_vB: not that I know. It only lets you set a cap on the number of connections
[20:26] <Sven_vB> yeah I do have that. it's part of the problem.
[20:26] <sdeziel> Sven_vB: if you want something fancy, haproxy does a good job
[20:26] <Sven_vB> I can choose between apt not working because xinetd blocks the rage, or apt not working because the weak proxy breaks down.
[20:27] <sdeziel> Sven_vB: but I'm surprised that you need to proxy to a proxy ;)
[20:27] <Sven_vB> I wouldn't consider "just wait and do nothing" as "fancy"
[20:28] <sdeziel> true but I don't have good alternatives to propose
[20:28] <Sven_vB> yeah I'd prefer all apps I use were kind of friendly, but most of them just don't care about how aggressive they are, because their intended target servers are ready to deal with the assault.
[20:28] <Sven_vB> I mean I kinda accept that lack of respect from overworked people at hipster companies, but now even apt? :<
[20:29] <Sven_vB> well I should study the apt manual again
[20:29] <Sven_vB> maybe it can restrain itself afterall
[20:32] <sdeziel> Sven_vB: there is a Queue-Mode param mentioned in apt.conf man page
[20:32] <sdeziel> can't find what's the default though
[20:35] <tomreyn> there is Acquire::http:Pipeline-Depth also
[20:35] <Sven_vB> https://linux.die.net/man/5/apt.conf covers it, a crude way to limit to 1 connection per criteria
[20:35] <Sven_vB> ah maybe that one will allow a better compromise.
[20:36] <Sven_vB> s:compromise:tradeoff:
[20:38] <tomreyn> see apt-transport-http(1) for details
[20:41] <Sven_vB> thanks!
[21:06] <Sven_vB> strange, it looks like apt only got into that rage because the network interface to the interwebs was down, which I didn't notice at first. now that it's up, it goes way more slowly.