=== cpaelzer_ is now known as cpaelzer
[05:39] <cpaelzer> fnordahl: hey, openvswitch tests on v3.3.0-5 seem to fail a lot and I get the feeling it might indeed be due to the new dpdk stable update in -proposed
[05:39] <cpaelzer> fnordahl: is that something you are aware of and/or look into already from any other POV?
[05:41] <cpaelzer> ginggs: LocutusOfBorg: bryceh: ^^ FYI since you generally retriggered it you might know more, for me (not knowing more) but 14/14 fails oO suggest this needs debugging ...
[06:07] <cpaelzer> while looking for other things, I see this in there "/home/ubuntu/autopkgtest/ssh-setup/nova: 234: [: x86_64: unexpected operator"
[06:07] <bryceh> @cpaelzer, other than that dpdk seems related, I have no insights particularly.  I thought maybe it depended on something else in -proposed but that seems not to be the case.
[06:07] <cpaelzer> might be unrelated to the issue I'm chasing but bdmurray paride is that a known one?
[06:08] <cpaelzer> bryceh: yeah, I've looked at output a bit and I think it is a real issue
[06:08] <bryceh> I've seen that unexpected operator error elsewhere a lot, I think that may be an orthogonal issue
[06:08] <cpaelzer> bryceh: "issue in the test" or "real thing broken" I'm not sure yet
[06:08] <cpaelzer> bryceh: yep, I think that is a separate issue as well - but wanted to ping for awareness
[06:09] <cpaelzer> bryceh: hmm local autopkgtest image creation doesn't like oracular for me - is that known issue to you and are there hints?
[06:13] <cpaelzer> bryceh: strike that, worked on the second try
[06:13] <cpaelzer> maybe it needed some patience
[06:13] <bryceh> @cpaelzer, haven't run into that, sorry
[06:14] <cpaelzer> found the 6 actually failing tests \o/
[06:14] <bryceh> actually, this cycle been impressed lxd has been ahead of the curve
[06:14] <cpaelzer> bryceh: on having images ready for you?
[06:15] <bryceh> yep
=== gurupras- is now known as guruprasad
[08:07] <cpaelzer> juliank: btw I love the new tabulated and colorized apt install output on oracular
[08:34] <juliank> cpaelzer: :)
[09:22] <fnordahl> cpaelzer: to your question on the openvswitch autopkgtests, I have indeed been wondering about the failures.  Upstream has held off spinning new point releases citing getting ready for the new DPDK release, so that does indeed look like a plausible culprit (ref: https://mail.openvswitch.org/pipermail/ovs-dev/2024-May/414129.html)
[09:23] <cpaelzer> fnordahl: interesting, I have some writeup myself to put it in a lp-bug as reference for the issue in excuses
[09:24] <cpaelzer> fnordahl: so your suggestion would be to let dpdk 23.11.1 stay in -proposed until OVS 3.3.1 is there as well
[09:24] <cpaelzer> fnordahl: and only care about the details if that does not overcome the issue?
[09:25] <cpaelzer> fnordahl: even if that is it - I wonder, how could we MRE it to noble then, as DPDK does not depend on OVS but we'd need to make sure the newer 23.11.1 DPDK would not go with the older OVS. Maybe a breaks to ensure the odering? Details ...
[09:25] <cpaelzer> fnordahl: I'll let you know the bug number once created
[09:28] <fnordahl> cpaelzer: it is probably worth looking into it, just echoed my current knowledge of the situation having just returned from PTO.
[09:29] <fnordahl> cpaelzer: looks like our tests are doing us good service though, if OVS needs to change to work with the new DPDK version, would that not also be the case for other consumers?
[09:30] <cpaelzer> yes
[09:30] <cpaelzer> well, let us find what it really is
[09:31] <fnordahl> 👍
[09:31] <cpaelzer> fnordahl: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2067889
[09:31] -ubottu:#ubuntu-devel- Launchpad bug 2067889 in openvswitch (Ubuntu) "DPDK 23.11.1 / OVS 3.3.0 cause test failures" [Undecided, New]
[09:32] <fnordahl> cpaelzer: thanks, will have a look
[09:32] <cpaelzer> fnordahl: all I've found - maybe with that we can reach out to our respective communities if any of that is known?
[09:38] <fnordahl> cpaelzer: yep, I've added a task for the current pulse to triage and see if there is anything we can do to expedite this to help unblock your proposed migration
[11:37] <arif-ali> ubuntu-sru just pinging here again, Can anyone help with LP: #2054395 with my new comments on that, so that I can facilitate and move things forwards TiA
[11:37] -ubottu:#ubuntu-devel- Launchpad bug 2054395 in sosreport (Ubuntu Mantic) "[sru] sos upstream 4.7.0" [Medium, In Progress] https://launchpad.net/bugs/2054395
[11:59] <rbasak> arif-ali: what are you waiting for from the SRU team exactly on that bug? I don't see any obvious questions in your comment, and there hasn't been a new upload to Unapproved with Steve's review requests fixed?
[12:01] <arif-ali> rbasak: I think his question about release and the patches, would it preferred that we ditch the patches for uploading 4.7.1. I am more than happy to upload a new debdiff to start that ball rolling if that is preferred
[12:37] <rbasak> arif-ali: perhaps you could release a 4.7.2 upstream with the patches included, and then focus on SRUing that?
[12:38] <rbasak> arif-ali: I'm not saying that we absolutely cannot release 4.7.1 with your distro patches in an SRU. But the process is complicated enough as it is. The exception you have is predicated on the upstream release already being sufficiently QA'd upstream, and that's defacto not the case with distro patches (since they're not upstream), so by adding them you're escaping QA that means that we then need to
[12:39] <rbasak> individually decide what to do about QA for them.
[12:39] <rbasak> If you integrate them upstream and follow what you already do for QA upstream, then there's no escape, and less decision making to negotiate for the SRU.
[12:39] <rbasak> tl;dr: distro patches in this case just unnecessarily complicate everything
[12:41] <arif-ali> yeah, I understand, it just took so long for this to come through, and since then we're almost 2 minor releases in. Moving forward it will be more streamlined as better testing upstream is now happening. Just need my sunbeam patches in, and 4.7.2 should be out soon
[12:41] <arif-ali> I presume, I just close this LP, and open a new one for 4.7.2, when upstream release is done
[12:49] <rbasak> arif-ali: if you're happy with that then sure. Do you want me to reject the current set of uploads from the queues?
[12:50] <rbasak> arif-ali: it might be better to just rename this bug to 4.7.3, so that the previous commentary is still readily available.
[12:55] <arif-ali> rbasak: well, it's been a learning experience :), as we've put a lot of effort in in these uploads. So, yeah, let's get those rejected as the same comments Steve added would have still apply, as we would've had to upload them again anyhow. I'll manage the next z-release with upstream and we'll start with that
[12:56] <rbasak> OK I'll update the bug. Thanks!
[13:18] <athos> Thanks, rbasak :)
[13:35] <cpaelzer> fnordahl: I was trying to further isolate the issue, but it keeps resisting my debugging. I left you all I had on the bug so you can continue without having to re-discover anything I already did
=== matttbe5 is now known as matttbe
[13:41] <mitchdz> LocutusOfBorg: I was planning to handle the nginx transition this cycle, so I'd be glad to help out there
=== vorlon` is now known as vorlon
=== ebarretto is now known as ebarretto_
=== cpete_ is now known as cpete
=== ebarretto_ is now known as ebarretto
[17:12] <LocutusOfBorg> mitchdz, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072394
[17:12] -ubottu:#ubuntu-devel- Debian bug 1072394 in src:fcgiwrap "fcgiwrap: autopkgtest failures: The requested URL returned error: 500" [Serious, Open]
[17:12] <LocutusOfBorg> this is the only showstopper
[17:13] <LocutusOfBorg> and perl, but that one will not need anything new I gues
[17:13] <LocutusOfBorg> *ss+
[17:54] <mitchdz> LocutusOfBorg: Thanks for the pointer. I'll take a look at the fcgiwrap autopkgtest
[18:52] <LocutusOfBorg> mitchdz, I failed to setup an autopkgtest and to reproduce it
[18:52] <LocutusOfBorg> don't really know what is going on... :/
[18:53] <LocutusOfBorg> same failure in Debian, looks like it regressed even without new nginx
[18:53] <LocutusOfBorg> maybe its related to newer git?
[18:53] <LocutusOfBorg> or a mix of two issues
[18:53] <LocutusOfBorg> not sure if a no change rebuild can help, I guess not
[18:53] <LocutusOfBorg> I'm trying an NCR in any case
[19:04] <mitchdz> LocutusOfBorg: Same, simple autopkgtest in an LXC container doesn't reproduce it for fcgiwrap_1.1.0-14build1
[19:13] <mitchdz> Okay yeah, just updating git from oracular-proposed reproduces the failure in an LXC container
[19:18] <mitchdz> Been failing since LocutusOfBorg: made https://bugs.launchpad.net/bugs/2067942 to track it for Ubuntu
[19:18] -ubottu:#ubuntu-devel- Launchpad bug 2067942 in fcgiwrap (Ubuntu) "autopkgtest failure in oracular" [Undecided, New]
[21:28] <bdmurray> cpaelzer: The unexpect operator issue should not have affected the test results at all and is known by Skia.
[22:57] <rlaager> sil2100 / mfo: Has anyone asked you to look at the SRU for fail2ban? https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/2055114
[22:57] -ubottu:#ubuntu-devel- Launchpad bug 2055114 in fail2ban (Ubuntu Noble) "fail2ban is broken in 24.04 Noble" [High, Confirmed]
[22:58] <rlaager> At this point, I think it's waiting approval to enter -proposed. Then I can (re-)test and give a formal verification-done-noble on it.
[23:02] <Eickmeyer> I mean, there's a ton of SRUs waiting to enter -release too, and quite a few waiting to enter -proposed.
[23:02] <Eickmeyer> The queue is long.
[23:43] <mfo> rlaager, no, I haven't been asked about it. I see it's in the list/unapproved queue, but I didn't get to it in today's shift. as I mentioned in #ubuntu-release (I guess it's more suited for SRUs than #ubuntu-devel, but here is fine :) I'll try and get to more SRU processing over the week to make some time I couldn't put in today; so I may reach that one, if someone else doesn't beat me to it.
[23:44] <rlaager> mfo: Fair enough. Trust me, I fully get time limitations. I'm just trying to do what I can here, and that's the next step in the process. Thanks for hearing me out!
[23:59] <mfo> rlaager, sure, you're welcome -- I can appreciate that, and do it often as well :)