[00:20] -queuebot:#ubuntu-release- New binary: nginx [amd64] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[00:20] -queuebot:#ubuntu-release- New binary: nginx [s390x] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[00:22] -queuebot:#ubuntu-release- New binary: nginx [i386] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[00:23] -queuebot:#ubuntu-release- New binary: nginx [ppc64el] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[00:32] -queuebot:#ubuntu-release- New binary: nginx [arm64] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[00:37] -queuebot:#ubuntu-release- New binary: nginx [armhf] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)
[05:32] <vorlon> tsimonq2: are you sure you don't care? :)  maybe lxpanel should be a sync again now that it's no longer seeded anywhere, hmm
=== paride7 is now known as paride
=== MmikeM is now known as Mmike
[08:12] -queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.1 => 4.1~rc1-3~ubuntu18.04.2] (core)
[08:13] -queuebot:#ubuntu-release- Unapproved: mdadm (cosmic-proposed/main) [4.1~rc1-4ubuntu1 => 4.1~rc1-4ubuntu1.1] (core)
[08:19] <ddstreet> oSoMoN network-manager has been in bionic-proposed for 122 days...can you find time to verify and get it pushed to -updates please?
[08:27] <oSoMoN> ddstreet, that's on tkamppeter's plate now, and he marked the SRU bug (bug #1809132) verified a month ago
[08:27] <ubot5`> bug 1809132 in network-manager (Ubuntu Bionic) "Updated bionic to the current 1.10 stable version" [Low,Fix committed] https://launchpad.net/bugs/1809132
[08:28] <ddstreet> oSoMoN i think it's held up by lp #1754671
[08:28] <ubot5`> Launchpad bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Fix committed] https://launchpad.net/bugs/1754671
[08:29] <oSoMoN> indeed
[08:29] <oSoMoN> tkamppeter, can you handle that one? ^
[08:29] <ddstreet> is someone else verifying that?
[08:29] <ddstreet> thnx!
[08:34] <seb128> ddstreet, oSoMoN, we started an email discussion about that some days ago in desktop, the issue is that our team lacks knowledge around those topics so we would need help testing that side of the changes/verifying they are correct
[08:34] <seb128> vorlon seemed to have doubts about it
[08:34] <seb128> we probably need foundations or someone who understands that topic enough to help
[08:34] <oSoMoN> ha, I haven't gone through all my e-mail backlog yet
[08:42] <tkamppeter> oSoMoN, according to comment #24 there seems to be an upstream fix which is too complex for an SRU.
[08:42] <tkamppeter> Who at Foundation one should contact for such a thing.
[09:58] <juliank> hmm, so we diverged from Debian in renaming libsrecord0 to libsrecord0v5
[09:59] <juliank> Debian had binNMUs
[09:59] <juliank> so gotta figure out if the binNMU happened before or after the g++ abi transition
[10:12] <rbalint> RAOF, bdmurray could you please accept lxd to cosmic-proposed? do-release-upgrade is broken on wsl until the package update is out
[10:16] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.36 => 1:2.5+dfsg-5ubuntu10.37] (ubuntu-server, virt)
[10:20] <ddstreet> sil2100 if you have time for this qemu, it's a small workaround fix needed only for xenial, that does have moderate urgency for a customer; cpaelzer is ok with the workaround based on previous discussion with him (tho he can correct me if needed :)
[10:25] <cpaelzer> ddstreet: acked the MP with some comments
[10:25] <cpaelzer> I see the fight between deadlines to fix it and my preference to have some more time&tests on it in -proposed
[10:26] <cpaelzer> but getting it there certainly seems to be the right next step to me
[10:26] <ddstreet> thnx!  and once it's in -proposed, we should be able to provide a hotfix to reduce the urgency
[10:30] <juliank> So, um, Debian did not follow the srecord gcc ABI rename, and stayed with libsrecord0 instead of libsrecord0v5. It's the only change we have, so um, I
[10:30] <juliank> feel like maybe we should just revert it now
[10:31] <juliank> There are no rdeps outside its source package, it's in universe, and it seems pointless work
[10:32] <Laney> do it
[10:33] <Laney> we basically mass scripted those changes, so ended up with a few that Debian didn't do
[10:34] <juliank> ack
[10:34] <juliank> synced
[10:35] -queuebot:#ubuntu-release- New binary: srecord [s390x] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:36] -queuebot:#ubuntu-release- New binary: srecord [i386] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:36] -queuebot:#ubuntu-release- New binary: srecord [ppc64el] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:36] -queuebot:#ubuntu-release- New binary: srecord [amd64] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:38] -queuebot:#ubuntu-release- New binary: srecord [armhf] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:40] <juliank> I was looking at getting libgnome-keyring removed, seems rdeps are libgnomeui (and its rdep is linsmith)
[10:41] <juliank> they are not in Debian testing, so prime candidate for removal
[10:41] -queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1] (no packageset)
[10:46] <infinity> juliank: Wait, but you can't just sync that...
[10:46] <juliank> infinity: No?
[10:46] <infinity> juliank: Cause it needs all the control magic to takeover for the 0v5 one.
[10:46] <juliank> hmm
[10:46] <infinity> Basically, the exact inverse of what 0v5 does.
[10:47] <infinity> Or, just merge instead of syncing and keep the delta fiveever.
[10:47] <juliank> So, it is safe to sync, as libsrecord0v5 Conflicts with libsrecord0
[10:47] <juliank> it might trick apt into the wrong decision
[10:48] <juliank> but we might get away with it even if it's wrong
[10:48] <infinity> update-manager won't upgrade that.  It'll poop and go partial.
[10:49] <infinity> Since the Conflicts/Replaces is in the other direction.
[10:49] <juliank> nice
[10:50] <infinity> The path of least resistance would have been to just beg Debian to do the (pointless?) ABI change. :P
[10:50] <infinity> Of course, someone should have done that 4 years ago.
[10:52] <infinity> Oh!
[10:52] <infinity> It's orphaned and QA maintained!
[10:52] <infinity> juliank: You can just upload our delta to Debian and be done with it. :P
[10:53] <infinity> Also, it's been uploaded once in the last 5 years, people clearly care deeply about it.
[10:53] <juliank> I mostly care about fixing the last few libgcrypt11-dev build-depends to say libgcrypt20-dev, and hence stumpled upon this
[10:54]  * infinity nods.
[10:54] <infinity> I'd definitely just go for pushing our delta to Debian and double-uploading that to Ubuntu so you don't have to wait on NEW, but that's me.
[10:54] <juliank> I asked Debian RT, and they mentioned debian bug 791295 - it was a conscious decision not to do the rename
[10:54] <ubot5`> Debian bug 791295 in src:srecord "srecord: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791295
[10:55] <juliank> Although, the Depends never happened
[10:55] <juliank> or well Breaks: srecord (<< version that expects pre-gcc5 things)
[10:56] <infinity> Yeah, also, the "screw third-party software" stance feels wrong to me.
[10:56] <infinity> No one said the ABI break wasn't real, just that they didn't care because no archive rdeps.
[10:57] <infinity> But also, it's been orphaned since then, and I figure QA can do whatever they please in the interest of easing cross-distro compat.
[10:57] <infinity> My two cents.
[10:57] <juliank> In any case, it's final buster freeze
[10:57] <infinity> Other option is a QA upload that just adds a Breaks/Conflicts against the 0v5 lib.
[10:57] <infinity> So, no NEW processing, but we can sync that and it would Just Work.
[10:58] <infinity> Sure, it might not migrate before release, not really an issue.
[10:58] <infinity> Since it's not broken in Debian.
[10:58] <infinity> And, like I said, one upload in 5 years doesn't point to a rapidly-changing history that you'd be blocking an RC upload. :P
[10:59] <juliank> can do that later, but I don't want to block uploads to buster via unstable
[10:59] <infinity> Or slap it at experimental, but then you'd have to remember later, which sucks.
[11:00] <juliank> not sure how far we'll need that, I guess we still need it in 20.04?
[11:00] <infinity> Anyhow, I don't think we should let this version in eoan-proposed.  COncur?
[11:00] <infinity> Yeah, we could just have a local delta to forcefully swap back and drop it post-20.04
[11:01] <infinity> Bi-directional replaces is all manner of sketchy in dpkg, unfortunately, but the odds of interrupted upgrades and rollbacks are slim enough that meh.
[11:02] <infinity> Oh, but it's C/R, not R, so it's not actually doing overwrites.
[11:02] <juliank> infinity: The Replaces are not a problem I think, as they're used with Conflicts and not Breaks, so we do not use them in the "replaces files" since
[11:02] <infinity> Just hinting.
[11:02] <juliank> yes
[11:03] <infinity> I really wish someone had decided that a richer syntax was smarter than magic pair/triplet hints.
[11:03] <juliank> I filed bug 1825972 for the libgnome-keyring, libgnomeui, linsmith removal
[11:03] <ubot5`> bug 1825972 in linsmith (Ubuntu) "Remove libgnome-keyring, libgnomeui, linsmith from eoan" [Undecided,New] https://launchpad.net/bugs/1825972
[11:04] <juliank> not sure if there's anything else to do - the packages are still in unstable after all, so would they sync again?
[11:04] <infinity> Not at the same versions.
[11:04] <infinity> But new ones would.
[11:04] <juliank> that should be fine I guess
[11:05] -queuebot:#ubuntu-release- New binary: srecord [amd64] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:05] -queuebot:#ubuntu-release- New binary: srecord [ppc64el] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:05] -queuebot:#ubuntu-release- New binary: srecord [i386] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:05] -queuebot:#ubuntu-release- New binary: srecord [s390x] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:07] <juliank> I feel like the rest of the week I'öö mainly be hitting autopkgtest retry buttons
[11:07] <infinity> Yeah, I did that a LOT over the weekend.
[11:07] <infinity> I'm technically not here, but I decided to do a favour for Brian with precise-esm distro-into stuff.
[11:08] <juliank> Also, I guess I'll be upgrading to eoan later today
[11:08] <Laney> any particular problem?
[11:08] <infinity> Laney: With autopkgtest?
[11:08] <Laney> ye
[11:09] <infinity> Laney: The biggest problem I had was the usual armhf-no-networky issue.
[11:09] <juliank> More like I have a few tests failing with missing eoan in python-apt distro data
[11:09] <juliank> and gotta retry those
[11:09] <Laney> ahhh
[11:09] -queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:09] <Laney> what the F is that problem about
[11:09] <juliank> but also, quite a few in progress
[11:09] <Laney> last I heard Steve was looking into it I think, but the ball is probably on the floor
[11:09] <infinity> Laney: I genuinely don't know.  I want to say it *seems* to be related to load, but that could just be confirmation bias because more tests == more failures.
[11:10] <infinity> I'm about 100% sure it'd go away if we put the effort into making armhf a first-class citizen with kvm instead of lxd, but that's also a huge draw on already limited compute resources (plus man hours we don't really have)
[11:10] -queuebot:#ubuntu-release- New binary: srecord [armhf] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)
[11:11] <Laney> right, I've never seen this particular problem on VMs
[11:11] <infinity> But "blame lxd" also isn't a useful diagnosis.
[11:11] <Laney> we did reconfigure armhf with Stéphane's recommended settings
[11:11] <Laney> but that didn't completely fix the problem
[11:12] <infinity> If the plan of record is to ship armhf with 20.04, *and* we get new arm64 kit to let scalingstack breathe, I think I'd like to give a stab at making armhf kvmish.
[11:13] <infinity> But until A is decided, it's a waste of our time, and until B is sorted, it's a waste of compute we don't have.
[11:13] -queuebot:#ubuntu-release- Unapproved: ubuntu-fan (xenial-proposed/main) [0.12.8~16.04.2 => 0.12.8~16.04.3] (no packageset)
[11:15]  * juliank is always like "did I break software-properties?" when reading excuses, but then remembers it only failed because it needs new python-apt
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [amd64] (eoan-proposed) [1.64-1]
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [armhf] (eoan-proposed) [1.64-1]
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [ppc64el] (eoan-proposed) [1.64-1]
[11:16] <infinity> Yeah, the first week while everything that knows about new names is migrating is "fun".
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [arm64] (eoan-proposed) [1.64-1]
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [s390x] (eoan-proposed) [1.64-1]
[11:16] -queuebot:#ubuntu-release- New: rejected srecord [i386] (eoan-proposed) [1.64-1]
[11:16] <infinity> All the things that fail because lxd/docker images don't exist yet is also irritating.
[11:16] -queuebot:#ubuntu-release- New: accepted srecord [amd64] (eoan-proposed) [1.64-1ubuntu1]
[11:16] -queuebot:#ubuntu-release- New: accepted srecord [armhf] (eoan-proposed) [1.64-1ubuntu1]
[11:16] -queuebot:#ubuntu-release- New: accepted srecord [ppc64el] (eoan-proposed) [1.64-1ubuntu1]
[11:16] -queuebot:#ubuntu-release- New: accepted srecord [arm64] (eoan-proposed) [1.64-1ubuntu1]
[11:16] -queuebot:#ubuntu-release- New: accepted srecord [s390x] (eoan-proposed) [1.64-1ubuntu1]
[11:17] -queuebot:#ubuntu-release- New: accepted srecord [i386] (eoan-proposed) [1.64-1ubuntu1]
[11:17]  * juliank is always like "did I break software-properties after all?" when reading excuses, but then remembers it only failed because it needs new python-apt
[11:17] <infinity> Uh oh, I think juliank is stuck in a loop.
[11:17] <infinity> Can we reboot him?
[11:18]  * juliank is always like "did I break software-properties after all?" when reading excuses, but then remembers it only failed because it needs new python-apt
[11:18] <juliank> goto out;
[11:18] <juliank> should build a "could not find a distribution template for Ubuntu/" auto-retry
[11:19] <juliank> I did retry crash and software-properties now, in case anyone is wondering
[11:19] <infinity> I'm staying away from that stack, it's all yours.
[11:26] <ddstreet> juliank btw i have a day or two this week that i'll update s-p to handle private ppas, but as part of that i'm adding python3-launchpadlib as a dep; i assume there is no issue with that?
[11:26] <ddstreet> i assume s-p doesn't currently use s-p because it predates that lib...
[11:27] <ddstreet> er, doesn't currently use launchpadlib, i mean
[11:27] <infinity> s-p?
[11:27] <ddstreet> software-properties
[11:27] <infinity> Oh, sof.. RIght.
[11:27] <infinity> It predates lplib by a couple of years.
[11:27] <ddstreet> yep
[11:27] <juliank> so, it will pull it into a couple more tasks live server and cloud images
[11:28] <infinity> OTOH, depending on your goals, sometimes just smacking the API via direct HTTP is less error prone than pulling in lplib for the fully integrated API experience.
[11:28] <infinity> I mean, if you're in a position to know the URL you want.
[11:28] <ddstreet> well private ppas require authentication with lp
[11:28] <infinity> Oh, private.  Right.  Fair enough.
[11:29] <ddstreet> it's really waaaaaaaay easier using lplib
[11:29]  * infinity nods.
[11:29] <juliank> so this might blow up minimal images a bit I guess?
[11:29] <ddstreet> once i have something to look at, i'll open a MP for your review
[11:29] <juliank> but I don't really see any big issues
[11:30]  * apw waits for his cve git repo to update
[11:30] <infinity> Minimal images shouldn't have software-properties.
[11:31] <apw> (and apprently for his irc client to switch buffers successfully, sigh)
[11:31] <infinity> It's in desktop/server/cloud, nothing lower.
[11:32] <juliank> ok, well, that makes sense
[11:32] <infinity> And lplib is already in most of the desktops, so this would just add it to a couple more and server, which seems fine.
[11:32] <juliank> ack
[11:34] <infinity> Speaking of that stack, sort of, it's a real shame we never managed to maintain update-manager in Debian in a reasonable fashion.
[11:35] <infinity> Honestly, when I first installed Ubuntu a few minutes after getting the job, update-manager immediately impressed me as a "oh, this is actually a Linux I could install on my mom's computer".
[11:35] <infinity> It's the little things.
[11:35] <juliank> Debian's stuck with PackageKit offline upgrades
[11:36] <infinity> I mean, I don't mind that solution (for my parents) either.  While I've never seen it, I assume it plays similarly to the "must reboot to update" Windows Updates?
[11:36] <infinity> Blank screen, progress bar, angry message about not cutting power?
[11:36] <juliank> infinity: Well, it installs _after_ reboot
[11:36] <infinity> But in 2004/2005, update-manager was so much more slick than any other option.
[11:37] <infinity> juliank: WIndows Updates "can't update locked files" updates happen post-reboot too.
[11:37] <juliank> that's the key difference to Windows which installs before reboot and keeps you waiting, which is nice if you are low on power
[11:37] <infinity> Usually, you'll see it split in 3.  Stuff it can do online, stuff it can do on shutdown, stuff it does after reboot, and I'm not really sure where the lines are drawn.
[11:38] <juliank> I dropped update-manager in Debian to get rid of aptdaemon, as that ended up unmaintained, and packagekit became usable
[11:38] <infinity> I'm glad we're not that messy. :P
[11:38] <juliank> A lot of things would be a lot easier if we did offline upgrades, at least for release upgrades
[11:39] <infinity> Certainly less error prone in some cases, I don't disagree.
[11:39] <infinity> And I think for dist-upgrades, it's worth examining.
[11:39] <infinity> I mean, not the apt dist-upgrade case, but the "friendly" case.
[11:40] <juliank> ack
[11:41] <infinity> I'm also wondering if we shouldn't paper over trigger loops with a log parses that just retries --configure and continues the upgrade.
[11:41] <infinity> Retry limit of 3 or something, but once would usually do it.
[11:41] <infinity> s/parses/parser/
[11:42] <infinity> A loop break at the dpkg level with a --force option we enable only for release upgrades could also work.
[11:42] <infinity> Like Debian used to --force-overwrite back in the bad old days.
[12:08] -queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.8 => 1.178ubuntu2.9] (core)
[12:08] -queuebot:#ubuntu-release- Unapproved: console-setup (cosmic-proposed/main) [1.178ubuntu9.1 => 1.178ubuntu9.2] (core)
[12:09] -queuebot:#ubuntu-release- Unapproved: console-setup (disco-proposed/main) [1.178ubuntu12 => 1.178ubuntu12.1] (core)
[12:36] <jdstrand> hey, when does the dev release typically show up in https://cloud-images.ubuntu.com/<name> and also for wherever lxc fetches stuff (lxc launch ubuntu-daily:<name>/<arch>)? I ask cause the libseccomp upload is failing autopkgtests in part because of the latter (and I'm trying to test locally for the former and noticed autopkgtest-buildvm-ubuntu-cloud fails (I'm going to create disco and upgrade,
[12:37] <jdstrand> so no biggie))
[12:37] <jdstrand> stgraber: hey, you may know the 2nd part of that ^
[12:39] <xnox> jdstrand, so, we need updated distro-info-data and then cpc to kick those build off.
[12:39] <stgraber> ubuntu-daily is cloud-images so once a cloud image gets published you should be good
[12:39] <xnox> jdstrand, but we can't have distro-info-data until EANIMAL is revealed.
[12:39] <xnox> jdstrand, so ping mark
[12:39] <jdstrand> heh
[12:39] <jdstrand> stgraber: thanks
[12:40] <xnox> jdstrand, for ADT testing we "fake" devel images, by manually copying disco -> eoan, and sed sources.list, apt update, and hope for the best ;-)
[12:40] <jdstrand> xnox: so we typically just wait until that happens before a thing that needs them migrates?
[12:40] <xnox> jdstrand, imho, if $ ubuntu-distro-info --devel gives errors, one should fallback and use --stable
[12:40] <xnox> jdstrand, something like that, yes.
[12:40] <jdstrand> ok, thanks
[12:40] <xnox> jdstrand, or ask release team / sru team to override, skiptest, mark bad test, etc.
[12:41] <stgraber> images:ubuntu/eoan should work though as those are generated by the LXD team and they're showing up as green on our side
[12:41] <jdstrand> stgraber: + lxc launch ubuntu-daily:eoan/amd64 docker -c security.nesting=true
[12:41] <jdstrand> Error: Failed container creation: The requested image couldn't be found
[12:41] <jdstrand> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/d/docker.io/20190423_082805_6dc5d@/log.gz
[12:41] <jdstrand> stgraber: maybe it was just a timing thing?
[12:41] <xnox> jdstrand, images: != ubuntu-daily
[12:41] <xnox> jdstrand, images: != ubuntu-daily:
[12:42] <stgraber> jdstrand: lxc launch images:ubuntu/eoan/amd64
[12:42] <jdstrand> that's fair. note I was pretty clear that I didn't know what was being used ;)
[12:43] <xnox> =)))))
[12:43] <jdstrand> stgraber: ok, sure. I wasn't really planning on touching docker.io but I can. are you saying this is a more robust invocation in general?
[12:45] <jdstrand> stgraber: actually, while I have you. did mdeslaur talk to you about libseccomp 2.4.1? also, do you use golang-seccomp?
[12:46] <stgraber> jdstrand: I wouldn't say more robust as the CPC generated images (ubuntu: and ubuntu-daily:) do tend to be more tested. But "images:" is generated by a much simpler build process (same as we use for all other LXD distro images) and so we tend to have the images for the new development release the day the name is announced whereas the CPC images can take over a week because of various dependencies
[12:47] <stgraber> jdstrand: we don't, no. LXD itself generates a liblxc plaintext policy whihc is then converted by liblxc (C library) using libseccomp
[12:47] <jdstrand> stgraber: cool. cause it had a bug in it you'd like want if you used it.
[12:48] <jdstrand> stgraber: as for 2.4.1, not sure if you saw, but db was reworked by upstream and as part of that they fixed a CVE wrt arg filtering. we are looking to upgrade to 2.4.1 in all releases
[12:49] <stgraber> jdstrand: ah, interesting. I don't believe we actively use arg filtering anywhere now so unlikely to be a big deal for us, but the snap will pick it up once 16.04 has it.
[12:49] <jdstrand> stgraber: iirc, you have a significant number of tests and it would be great if you could rung the libseccomp 2.4.1 packages through them
[12:49] <jdstrand> run*
[12:50] <stgraber> jdstrand: we intend to start shipping our own copy of libseccomp in the snap very soon too as we'll need support for userspace mediation once we get those landed upstream
[12:50] <jdstrand> stgraber: we're hoping for testing prior to pushing to the archive
[12:50] <jdstrand> stgraber: I highly suggest looking at 2.4.1
[12:50] <stgraber> jdstrand: yep, do you have those in -proposed? I can manually update our test runners for it (bionic)
[12:51] <jdstrand> stgraber: they aren't in proposed. let me ask mdeslaur what he thinks about pocket copying them
[12:51] <jdstrand> mdeslaur: stgraber is willing to testing lxd against our libseccomp updates. what do you think about them going to -proposed?
[12:52] <jdstrand> s/testing/test/
[12:52] <mdeslaur> jdstrand: I'm still unsure of the approach, so I'd rather we test lxd before sending them to -proposed
[12:53] <mdeslaur> but if snap and lxd work, 2.4.1 in proposed sounds good
[12:53] <mdeslaur> jdstrand: ^
[12:53] <jdstrand> I'll be testing snapd today (so far it has been great)
[12:54] <jdstrand> stgraber: would our public security-proposed ppa work for you? something else? ^
[12:54] <stgraber> jdstrand: that's fine, I can just manually wget + dpkg install them
[12:54] <jdstrand> stgraber: ok. I'll copy them over. gimme a sec
[12:55] <jdstrand> mdeslaur: jeez we have access to a lot of ppas
[12:55] <mdeslaur> jdstrand: wait a sec
[12:56] <mdeslaur> jdstrand: I didn't put them there so people don't install them
[12:56] <mdeslaur> jdstrand: give stgraber access to our private ppa instead
[12:56] <jdstrand> I'll just scp them to people
[12:57] <infinity> xnox: Err, wat?
[12:57] <xnox> infinity, which bit? =)
[12:57] <infinity> 06:39 < xnox> jdstrand, but we can't have distro-info-data until EANIMAL is revealed.
[12:57] <jdstrand> mdeslaur: we have people that regularly run our security proposed ppa?
[12:57] <infinity> xnox: distro-info-data is updated in every release going back to precise.
[12:58] <xnox> infinity, i might be wrong, but we normally update distro-info-data with both adjective & animal. Or are you planning to update it with adjective alone; and then later sru the animal name?
[12:58] <infinity> xnox: If anything's blocking cloud builds, it's not us.
[12:58] <mdeslaur> jdstrand: yeah, we do...which is why I try to upload stuff there...but if we don't go forward with 2.4.1, they will get stuck
[12:58] <infinity> xnox: No "planning" at all, it's done.  Days ago.
[12:58] <jdstrand> stgraber: I'm stepping into a meeting in 2 minutes. I'll ping you. thanks again
[12:58] <xnox> infinity, ok.
[12:59] <jdstrand> mdeslaur: I see. I'm pretty sure we are going to go forward. 2.3 is rather terrible wrt arg filtering I discovered
[12:59] <xnox> debootstrap is done too. Let me see where the eoan images are then
[12:59] <jdstrand> mdeslaur: but yes, must test :)
[13:01] <infinity> xnox: To be fair, jerff was waiting on a new-new distro-info for other reasons (ESM madness), but I got that all fixed up, so they can upgrade that machine.
[13:02] <xnox> true
[13:02] <xnox> but i don't even see cpc-jenkins jobs to attempt building 19.10 which is way pre jerff bits.
=== fidencio_ is now known as fidencio
[13:14] <xnox> jdstrand, infinity - pinged cpc team about it.
[13:16] <jdstrand> thanks
[13:23] <jdstrand> stgraber: fyi, http://people.canonical.com/~jamie/libseccomp/
[13:54] -queuebot:#ubuntu-release- Unapproved: debootstrap (disco-proposed/main) [1.0.112ubuntu1 => 1.0.112ubuntu1.1] (core)
[13:57] -queuebot:#ubuntu-release- Unapproved: debootstrap (cosmic-proposed/main) [1.0.108ubuntu1.1 => 1.0.108ubuntu1.2] (core)
[13:59] -queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95ubuntu0.3 => 1.0.95ubuntu0.4] (core)
[14:01] -queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.8 => 1.0.78+nmu1ubuntu1.9] (core)
[14:09] <teward> um, is there any issue with the publishers to Proposed?
[14:09] <teward> nginx has been stuck for 12 hours without being 'uploaded' - just stuck at 'pending publication' to proposed
[14:12] <apw> teward, it is in binary New
[14:13] <teward> ah
[14:13] <teward> missed that xD
[14:13] <teward> apw: i'm guessing because there's a new .deb included in it.
[14:14] <apw> tkamppeter, geoip2
[14:14] <teward> which I had a discussion with sarnold about several times during last cycle :P
[14:14] <teward> hep.
[14:14] <teward> yep*
[14:14] <teward> apw: guess i haven't had enough coffee to wake up today :)
[14:14]  * teward goes and finds more
[14:16] <teward> tkamppeter: apw: for the record, geoip2 module was added to the NGINX packages as a third party plugin because the in-built GeoIP module only works with MaxMind legacy which is no longer available for 'free' - this is ultimately done in order to provide an alternative for those who want to use GeoIP with the MM GeoIP2 DBs.
[14:17] <apw> teward, and i read the associated bug as saying that it should end up in universe ...
[14:18] <teward> correct, that is a Universe-targeted binary
[14:18] <teward> it's not included in -core (that needs a MIR)
[14:19] <teward> so that binary can be dropped to Universe.  I'm working on prepping the MIR to Main that one (it's currently only dep'd by nginx-extras and nginx-full both binary debs in Universe)
[14:19] <teward> but i'm also 'dragging my feet' as it's early in the cycle, not to mention I just got dropped on me at work creating a REST API for a huge project
[14:19] <teward> so that's taking some attention :p
[14:20] <teward> wow i'm an idiot the big red "NEW" is right there in front of me, I should've noticed that.  *smacks face against keyboard*
[14:40] <stgraber> jdstrand: all our x86 CI nodes are now on the updated libseccomp, I'll let you know if we see anything bad happen
[14:41] <jdstrand> stgraber: great, thanks! (cc mdeslaur)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (disco-proposed) [1.0.112ubuntu1.1]
[14:47] -queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (cosmic-proposed) [1.0.108ubuntu1.2]
[14:48] -queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu6 => 1.78ubuntu7] (core)
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.95ubuntu0.4]
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.9]
[14:59] <bdmurray> infinity: Were you going to verify tzdata?
[14:59] -queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (bionic-proposed) [1.18.0-1~ubuntu18.04.1]
[15:03] <sil2100> kenvandine, tkamppeter: hmm, the libqmi upload seems to have a bad version number
[15:03] <kenvandine> ugh
[15:03] <sil2100> kenvandine, tkamppeter: 1.22.0-1.3~ubuntu18.04.1, while I don't see 1.22.0-1.3 anywhere
[15:03] <sil2100> kenvandine, tkamppeter: so currently it would be higher than what's in disco/eoan
[15:04] <sil2100> Disco/eoan have 1.22.0-1.2
[15:05] <kenvandine> i can reupload that in a couple minutes
[15:06] <sil2100> Thanks! :)
[15:07] <sil2100> I suspect 1.22.0-1.3 was supposed to be pushed to disco before release or something
[15:07] <sil2100> (synced)
[15:07] <kenvandine> i'll upload it as 1.22.0-1.2~ubuntu18.04.1
[15:10] <kenvandine> sil2100: the problem there is it's older than the previous changelog entry
[15:13] <kenvandine> sil2100: i guess that's actually fine
[15:13] <sil2100> kenvandine: yeah, that's not a problem per-se, doesn't look perfect but yeah
[15:13] <sil2100> Many of our backport-SRUs have such situation
[15:14] <kenvandine> sil2100: ok, uploaded
[15:14] <sil2100> Thanks!
[15:15] -queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (bionic-proposed) [1.22.0-1.3~ubuntu18.04.1]
[15:15] -queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3ubuntu1 => 1.22.0-1.2~ubuntu18.04.1] (kubuntu, ubuntu-desktop)
[15:17] -queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (bionic-proposed) [1.22.0-1.2~ubuntu18.04.1]
[15:19] -queuebot:#ubuntu-release- Unapproved: accepted modemmanager [source] (bionic-proposed) [1.10.0-1~ubuntu18.04.1]
[15:20] <tkamppeter> sil2100, I got a lot of messages about libmbim, is it correctly uploaded now? What was wrong with it?
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted ureadahead [source] (xenial-proposed) [0.100.0-19.1]
[15:22] <sil2100> tkamppeter: it's all fine now, the problem was that the upload was 1.22.0-1.3~ubuntu18.04.1 while 1.22.0-1.3 never got synced into disco
[15:23] <sil2100> tkamppeter: so if we'd accept it, the package in bionic would have a higher version number than in disco/eoan
[15:23] <sil2100> tkamppeter: but Ken tweaked it
[15:24] <vorlon> infinity, cyphermox, Laney: not sure who's in the best position to look into this, but ubiquity autopkgtests have suddenly regressed as soon as the release name changed http://autopkgtest.ubuntu.com/packages/u/ubiquity/eoan/arm64
[15:28] <tkamppeter> I see now that my original debdiff attached to the bug report also had the correct version 1.22.0-1.2~ubuntu18.04.1 and not ...-1.3~... really strange.
[15:29] <tkamppeter> sil2100, kenvandine ^^
[15:29] <kenvandine> that is really strange!
[15:29] <kenvandine> i wonder if i screwed that up :)
[15:29] <tkamppeter> sil2100, I was asking about libmbim, because I got a lot of error mails, but according to the bug rpoert it seems to have ended up all OK.
[15:29] <kenvandine> it's been so long, i don't recall
[15:31] <cyphermox> vorlon: ok
[15:33] <sil2100> tkamppeter: ouch, yeah, looks like those failed due to some LP issues, let me look
[15:33] <Laney> vorlon: cyphermox: Looks like the dpkg-trigger triggered one did pass on eoan, but it broke between then and 2019-04-23, or do I miss something?
[15:34] <tkamppeter> sil2100, kenvandine, now seems that Yuan-Chen Cheng from OEM nees to verify the fix, as he should be the one with these new modem models.
[15:35] <kenvandine> tkamppeter: yes
[15:35] <kenvandine> tkamppeter: please email him about that
[15:42] <tkamppeter> kenvandine, done.
[15:43] <kenvandine> tkamppeter: thanks
[15:43] <tkamppeter> sil2100, thank you very much for having modemmanager passed into -proposed.
[15:50] <vorlon> Laney: oh the 21st was after the release date as well, ok.  So yeah, it regressed shortly after archive opening :)
[15:50] <sil2100> tkamppeter: your welcome! libmbim is now built correctly, so now modemmanager should be able to build soon as well
[15:53] <cyphermox> Laney: you're not missing anything, this isn't a regression, it's a test that is not flexible enough
[15:54] <Laney> nod
[16:05] -queuebot:#ubuntu-release- New binary: clamav [s390x] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:05] -queuebot:#ubuntu-release- New binary: clamav [ppc64el] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:07] -queuebot:#ubuntu-release- New binary: clamav [i386] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:08] -queuebot:#ubuntu-release- New binary: clamav [amd64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:08] <acheronuk> who needs to tell 'reverse-depends' about eoan? I can't recall who
[16:09] <vorlon> tumbleweed: ^^
[16:09] -queuebot:#ubuntu-release- New binary: clamav [arm64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:10] <acheronuk> thanks
[16:10] -queuebot:#ubuntu-release- New binary: clamav [armhf] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)
[16:29] <tumbleweed> vorlon: does eoan have a name yet?
[16:29] <tumbleweed> that's blocking it
[16:30] <xnox> tumbleweed, eoan is the adjective to use; there is no animal yet, but it shouldn't matter, right?
[16:30] <xnox> tumbleweed, note how all of distro-info-data updated already, and debootstrap, etc.
[16:30] <tumbleweed> no, it's not (in Debian)
[16:30] <tumbleweed> I'm not going to get it updated in Debian, if we're getting a name, tomorrow
[16:31] <xnox> tumbleweed, ransom holder!
[16:31] <xnox> tumbleweed, i wish we knew if and when we get the eanimal
[16:31] <tumbleweed> I was giving it a few days to see if a name would appear
[16:47] <vorlon> tumbleweed: why is the Ubuntu reverse-depends service blocked on a Debian upload of distro-info-data?
[16:53] <teward> tkamppeter: got a few minutes to look at nginx in the NEW queue?
[16:53] <teward> if you're not busy.
[16:56] <tumbleweed> vorlon: it's actually blocked on a git checkout of distro-info-data
[16:56] <tumbleweed> so I can just commit EANIMAL to that
[16:56] <vorlon> ah
[16:57] <tumbleweed> but I was assuming we'd get an animal within a day or two
[16:57] <tumbleweed> is that unlikely?
[16:57] <vorlon> tumbleweed: why wouldn't you just use the Ubuntu distro package anyway, given that distro-info-data is always srued?
[16:57] <vorlon> tumbleweed: I have no control over the timeline, and reverse-depends not working is a nuisance now
[16:57] <vorlon> not enough for me to have complained directly, but I'm +1ing acheronuk ;)
[16:57] <tumbleweed> because I didn't have root on ubuntuwire at the time
[16:57] <vorlon> ah ;)
[16:58]  * tumbleweed can probably unwind all of that
[16:59] <tumbleweed> I would like an animal, of course
[16:59] <tumbleweed> and I'm slightly worried that without the pressure of opening the release, it will take months now
[17:00] <cjwatson> If we used the null animal (i.e. literally just called it Eoan, not Eoan EANIMAL or whatever) and it were to happen that we didn't get an animal by release time, what would go wrong?
[17:00] <vorlon> Eoanimal
[17:01] <teward> multiversal panic perhaps? :P
[17:01] <tumbleweed> terrible wallpaper image?
[17:01] <vorlon> Eoan Eoanimal, pronounced "an animal"
[17:01] <tumbleweed> no t-shirt :P
[17:01] <cjwatson> I mean that's the designers' problem and they can apply whatever pressure they can if they need to :)
[17:02] <cjwatson> But the null animal seems like a better default than errno jokes that probably wouldn't be very good to actually release with
[17:02] <cjwatson> And a more generalisable precedent if we had to
[17:02]  * tumbleweed pulls out all of those local checkouts on my ubuntuwire cronjobs
[17:05] <teward> anyone able to take a look at nginx / libnginx-mod-geoip2 in the NEW queue?  The 'new' binaries created need demoted to Universe, ultimately, though this is being added to the packaging because of the GeoIP support for MaxMind Legacy no longer being usable due to MaxMind dropping the Legacy DBs for non-paying customers, and there not being any in-built GeoIP2 module within the code base yet for the GeoIP2 databases.
[17:25] <tkamppeter> teward, nginx in the new queue? What is that?
[17:25] <teward> tkamppeter: apw pinged you maybe the wrong one to ping
[17:26] <teward> *yawns* I have an NGINX upload (web server software) that includes a new plugin .deb for GeoIP2 support and it's in NEW because it's new to the package
[17:27] <teward> though those binaries for libnginx-mod-http-geoip2 are new they should be demoted to Universe.
[17:27] <tkamppeter> teward, I think it was not meant for me, as I do all the printing stuff and network-manager.
[17:27] <teward> yep
[17:27] <teward> well in any case
[17:27] <teward> i am a patient person and will wait :)
[17:27] <teward> *lurks*
[17:27] <teward> ... now if only people would stop calling my phone every 3 minutes
[17:28] <tkamppeter> I am also not responsible for the NEW queue.
[17:28] <teward> as I said i'll wait :)
[17:31] <teward> vorlon: any progress on the OpenSSL SRU for Bionic?  Just wondering, I have people emailing me asking me to push an nginx rebuild in Bionic for TLS1.3 support in -proposed but I am not going to so we don't have any blocking things preventing security updates, etc. from happening before OpenSSL 1.1.1 is done.
[18:09] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (cosmic-proposed) [1:0.4.2]
[18:32] <vorlon> Laney, juliank: do you know anything about why ppc64el autopkgtest queues are lagging?
[18:35] <vorlon> also why is armhf zippy all of a sudden, that's very suspicious
[18:37] <ddstreet> bdmurray during your sru vanguard shift today, if you have time, can you approve the qemu upload to xenial plz - it's a rather important fix for a customer issue of crashing qemu
[18:49] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [sync] (bionic-proposed) [2.7.15-4ubuntu4~18.04]
[18:49] <vorlon> teward: ^^ some progress
[18:56] -queuebot:#ubuntu-release- Unapproved: accepted python3.6 [sync] (bionic-proposed) [3.6.8-1~18.04.1]
[19:06] <coreycb> vorlon: i'm not sure why python-formencode is listed as an openstack package
[19:12] <teward> vorlon: indeed.
[19:12] <teward> vorlon: would you be able to take a look at nginx in the NEW queue per chance?
[19:12] <vorlon> coreycb: https://bugs.launchpad.net/ubuntu/+source/python-formencode/+bug/493593
[19:12] <ubot5`> Ubuntu bug 493593 in scgi (Ubuntu Lucid) "MIR for paste." [High,Fix released]
[19:12] <teward> if not that's fine, it's not a huge priority
[19:12] <coreycb> vorlon: actually i guess we still depend on it for py2 via swift and python-paste. looks like if and ever we get to swift py3 we may not need it.
[19:12] <vorlon> teward: well I'm currently still working on those SRU reviews
[19:12] <teward> ack, no problem.
[19:13] <vorlon> coreycb: if you want to negotiate having another team take over ownership of it in main, that'd be between you and them :)
[19:14] <coreycb> vorlon: no problem. i think i'll cross that bridge once it's no longer used by openstack packages. for now i'll shake my hand at swift.
[19:16] <juliank> vorlon: only heard about armhf having no networking or something
[19:30] -queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [sync] (bionic-proposed) [2.1.4-1ubuntu1.3]
[19:49] <tsimonq2> vorlon: You're welcome to sync.
[20:48] <vorlon> xnox: ruby2.5/bionic needs rebased on the 2.5.1-1ubuntu1.2 in bionic-security (which doesn't match the one in the sru changelog)
[20:49] -queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [source] (bionic-proposed) [2.5.1-1ubuntu1.3]
[22:03] <tumbleweed> reverse-depends for eoan have generated
[22:06] <vorlon> \o/
[22:06] <vorlon> tumbleweed: thanks
[22:33] -queuebot:#ubuntu-release- Unapproved: accepted python3.7 [sync] (bionic-proposed) [3.7.3-2~18.04.1]
[22:44] <xnox> tumbleweed, we worship you!
[23:00] <bdmurray> infinity: Were you going to do that tzdata verification?
[23:01] <infinity> bdmurray: I were.  Just, y'know, swap days, and sick (how unfair is that, getting sick when you're already taking time off), etc.
[23:01] <infinity> bdmurray: I can look later tonight.
[23:04] <bdmurray> infinity: I'm sorry you are sick man.
[23:06] <tumbleweed> xnox: pff. I'm lazy
[23:25] <tsimonq2> infinity: Less derp in the pastebinit version for Disco now, thanks.
[23:26] -queuebot:#ubuntu-release- Unapproved: pastebinit (disco-proposed/main) [1.5-2 => 1.5-2.2~ubuntu0.19.04.1] (core)
[23:35] <Eickmeyer> tsimonq2: We all need a little less derp in our lives.
[23:35] <tsimonq2> ^^
[23:36] <tsimonq2> Eickmeyer: I have no clue what I was thinking when I typed 1.5-2.2ubuntu~0.19.04.1 and thought "this is totally a valid version!"
[23:36] <Eickmeyer> tsimonq2: haha! Yeah, that is... wow.
[23:36]  * tsimonq2 steals teward's coffee
[23:37]  * Eickmeyer follows the coffee
[23:37]  * Eickmeyer like a puppy dog
[23:37] <tsimonq2> haha :)
[23:37]  * teward appears in front of tsimonq2 with a laser sword, cuts down tsimonq2, then reclaims his coffee and walks back off as if nothing happened.
[23:38]  * Eickmeyer folows the coffee like a puppy dog
[23:46] -queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.2 => 2.5.1-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
[23:47] <xnox> infinity, in france, if one is sick during holidays, one gets to reclaim those days!
[23:47] <xnox> vorlon, ruby2.5 respun ^^^ skipped a version number, but otherwise it should be a clean diff on top of bionic-security.
[23:48] <xnox> vorlon, UNAPPROVED queue (bionic/libio-socket-ssl-perl, bionic/libnet-ssleay-perl) what about these two? i only have "autopkgtests / unittests pass" as the testcase for both.
[23:55] <xnox> vorlon, ah, nevermind see the emails from you now!