=== ebarretto_ is now known as ebarretto
=== sem2peie- is now known as sem2peie
[08:48] <cpaelzer> doko: rbalint: FYI I've seen you have rebuilt cyrus-imap but it's test dependency issues hold back perl and many (22) other things. I've found that Debian has our delta https://launchpad.net/ubuntu/+source/cyrus-imapd/3.2.3-2ubuntu1 now accepted in https://tracker.debian.org/news/1181216/accepted-cyrus-imapd-324-3-source-into-unstable/
[08:48] <cpaelzer> doko: rbalint: thereby it can be a sync and tests retriggered once built
[08:49] <cpaelzer> I'll file a bug and trigger the sync unless you say that you are already on it
[11:25] <seb128> hey there, python questions pyferret tests fail because it does
[11:25] <seb128>  ; for py in $(py3versions -r 2>/dev/null) ... ; $py -c "import pyferret"
[11:25] <seb128> and Depends on python3-ferret which Depends on python3 (>= 3.8~)
[11:26] <seb128> which leads to bash: python3.9: command not found
[11:26] <seb128> is the right fix for thoses cases to have the tests control Depends on python3-all?
[11:57] <doko> seb128: yes. can you file a RC issue for Debian too?
[11:57] <seb128> doko, yes, will do, thanks for the reply
[11:58] <doko> User: debian-python@lists.debian.org
[11:58] <doko> Usertags: python3.9
[11:58] <seb128> k
[11:58] <doko> seb128: ^^^
[12:13] <cpaelzer> doko: rbalint: FYI the sync I mentioned earlier unblocked all things that waited on cyrus-imapd
[12:16] <cpaelzer> doko: rbalint: sil2100: given the high number of long-duration-often-manually-retried that https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/arm64 and https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/armhf are causing - what do you think of badtesting that on armhf/arm64
[12:16] <cpaelzer> it feels that must have been discussed before ...
[12:16] <cpaelzer> Was there any hope to not expect this to be a retry-monster forever?
[12:17] <Laney> The desktop team should be asked if they can work on making that less flaky
[12:17] <Laney> I don't think ignoring the tests there is a good answer
[12:18] <Laney> Reducing the coverage would be preferable if that gets it to be more stable, for example, assuming the flakiness can't be easily fixed
[12:18] <cpaelzer> sounds good, I'll ask in #ubuntu-desktop if they have (or want) a bug for it
[12:19] <Laney> - or in the meantime while fixing the flakes as a more long term task
[12:45] <cpaelzer> Hi proposed migration tries to confuse me, on recent qemu 5.1 it tells me "old binaries left on amd64: qemu-kvm (from 1:5.0-5ubuntu11)" (and the same for arm64/ppc64el/s390x)
[12:45] <cpaelzer> And that is true and expected, binary "qemu-kvm" existed but is gone intentionally
[12:45] <cpaelzer> As replacement there are breaks/replaces on the qemu-system-* packages, so the rev-deps should be covered.
[12:46] <cpaelzer> I'm puzzled what to do now, I'd have expected this to be not a migration blocker
[12:46] <cpaelzer> And once the new one migrated the old binaries to be removed via https://people.canonical.com/~ubuntu-archive/nbs.html
[12:46] <cpaelzer> Seems to be different now, could someone advice what/if I have to do now to ge this unstuck?
[12:52] <Laney> cpaelzer: it exists in proposed, was there a previous upload that didn't migrate? (yes)
[12:52] <Laney> an archive admin needs to remove that
[12:53]  * Laney does
[12:55] <Laney> nein, doko already did it!
[12:56] <cpaelzer> thanks Laney, just to make sure I get it right (for next time). Usually we'd have the old package in -release and not in -proposed. But since I had one upload in -proposed with qemu-kvm and then another one to -proposed without we now have had the package in -proposed but not as part of the current version that shall migrate. And NBS would instead be for things missing in -release
[12:57] <cpaelzer> sort of makes sense, it seems I just didn't hit this particular sub-case yet (or an AA was always too fast resolving it before it bothered me)
[13:32] <rbalint> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Groovy | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rbalint
[13:36] <rbalint> cpaelzer, yesterday following the recommendation of doko and vorlon i moved to the plusone discussion channel to #ubuntu-release on https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[13:43] <cpaelzer> rbalint: intersting - we started there and were driven away being called too noisy
[13:45] <rbalint> ok, sorry, then this needs a wider discussion
[13:46] <rbalint> but this does not work, yesterday i missed the discussion by hanging out here
[13:47] <rbalint> who complained about the noise?
[13:50] <rbalint> cpaelzer, doko keeps talking on #ubuntu-release
[13:54] <doko> cpaelzer, rbalint: didn't vorlon change that to #u-r?
[13:57] <rbalint> doko, you suggested, vorlon agreed, i changed: https://pastebin.ubuntu.com/p/S5qRB9F8B7/
[14:06] <seb128> cjwatson, hey, I'm pondering adding a apt-proxy-url argument to launchpad-buildd/lpbuildd/livefs.py do you have any opinion on that before I actual start working on code changes?
[14:15] <cjwatson> seb128: Similar to the existing one in lpbuildd/debian.py?  Sounds reasonable to me if you have a good idea of how to jam it into livecd-rootfs and if it similarly defaults to the value in launchpad-buildd's config file
[14:22] <seb128> cjwatson, thanks, I hit the issue when trying local builds with ubuntu-old-fashioned, it uses the existing --http-proxy arg when there an apt config but that does
[14:22] <seb128>             if self.args.http_proxy:
[14:22] <seb128>                 proxy_dict = {
[14:22] <seb128>                     "http_proxy": self.args.http_proxy,
[14:22] <seb128>                     "LB_APT_HTTP_PROXY": self.args.http_proxy
[14:22] <seb128>                     }
[14:23] <seb128> cjwatson, the LB_ makes live-build do the right thing but the http_proxy blew up if you just use a squid-deb-proxy since it tries to use it as a real proxy and that fails
[14:23] <seb128> so I would just set "LB_APT_HTTP_PROXY" in the apt-proxy-url case
[14:27] <cjwatson> seb128: I expect I'll need to look at the diff, but sounds broadly reasonable I think
[14:27] <seb128> cjwatson, thanks
=== ijohnson is now known as ijohnson|lunch
[18:25] <ItzSwirlz> so mouseemu has been removed it seems, is that correct?
[18:28] <tumbleweed> yep
[18:30] <ItzSwirlz> alr, time to see how cinnamon is doing in hirsute
[18:31] <ItzSwirlz> hm, i gotta tell preining to release 4.7.0 in debian
[18:31] <ItzSwirlz> Or i can reqsync 4.6.3.
[18:32] <ItzSwirlz> It's in experimental, I'll choose the latter (4.6.0-3)
=== ijohnson|lunch is now known as ijohnson
[20:20] <rbasak> bdmurray: I replied in bug 1901491. Not sure if you were asking because you hadn't realised it was an SRU regression, or if you were asking why I was tagging post-accept.
[20:20] <ubottu> bug 1901491 in v4l2loopback (Ubuntu Focal) "Created devices are not available" [High,Fix released] https://launchpad.net/bugs/1901491
[20:29] <bdmurray> rbasak: Thanks, I wasn't sure if some action was required.
[22:02] <rbalint> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Groovy | If you can't send messages here, authenticate to NickServ first | Patch Pilots: