-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:20
-queuebot:#ubuntu-release- New binary: nginx [i386] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)00:22
-queuebot:#ubuntu-release- New binary: nginx [ppc64el] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)00:23
-queuebot:#ubuntu-release- New binary: nginx [arm64] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)00:32
-queuebot:#ubuntu-release- New binary: nginx [armhf] (eoan-proposed/main) [1.15.12-0ubuntu1] (ubuntu-server)00:37
vorlontsimonq2: are you sure you don't care? :)  maybe lxpanel should be a sync again now that it's no longer seeded anywhere, hmm05:32
=== paride7 is now known as paride
=== MmikeM is now known as Mmike
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.1 => 4.1~rc1-3~ubuntu18.04.2] (core)08:12
-queuebot:#ubuntu-release- Unapproved: mdadm (cosmic-proposed/main) [4.1~rc1-4ubuntu1 => 4.1~rc1-4ubuntu1.1] (core)08:13
ddstreetoSoMoN network-manager has been in bionic-proposed for 122 days...can you find time to verify and get it pushed to -updates please?08:19
oSoMoNddstreet, that's on tkamppeter's plate now, and he marked the SRU bug (bug #1809132) verified a month ago08: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/180913208:27
ddstreetoSoMoN i think it's held up by lp #175467108:28
ubot5`Launchpad bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Fix committed] https://launchpad.net/bugs/175467108:28
oSoMoNtkamppeter, can you handle that one? ^08:29
ddstreetis someone else verifying that?08:29
seb128ddstreet, 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 correct08:34
seb128vorlon seemed to have doubts about it08:34
seb128we probably need foundations or someone who understands that topic enough to help08:34
oSoMoNha, I haven't gone through all my e-mail backlog yet08:34
tkamppeteroSoMoN, according to comment #24 there seems to be an upstream fix which is too complex for an SRU.08:42
tkamppeterWho at Foundation one should contact for such a thing.08:42
juliankhmm, so we diverged from Debian in renaming libsrecord0 to libsrecord0v509:58
juliankDebian had binNMUs09:59
juliankso gotta figure out if the binNMU happened before or after the g++ abi transition09:59
rbalintRAOF, bdmurray could you please accept lxd to cosmic-proposed? do-release-upgrade is broken on wsl until the package update is out10:12
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.36 => 1:2.5+dfsg-5ubuntu10.37] (ubuntu-server, virt)10:16
ddstreetsil2100 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:20
cpaelzerddstreet: acked the MP with some comments10:25
cpaelzerI see the fight between deadlines to fix it and my preference to have some more time&tests on it in -proposed10:25
cpaelzerbut getting it there certainly seems to be the right next step to me10:26
ddstreetthnx!  and once it's in -proposed, we should be able to provide a hotfix to reduce the urgency10:26
juliankSo, 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, I10:30
juliankfeel like maybe we should just revert it now10:30
juliankThere are no rdeps outside its source package, it's in universe, and it seems pointless work10:31
Laneydo it10:32
Laneywe basically mass scripted those changes, so ended up with a few that Debian didn't do10:33
-queuebot:#ubuntu-release- New binary: srecord [s390x] (eoan-proposed/universe) [1.64-1] (no packageset)10:35
-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:36
-queuebot:#ubuntu-release- New binary: srecord [armhf] (eoan-proposed/universe) [1.64-1] (no packageset)10:38
juliankI was looking at getting libgnome-keyring removed, seems rdeps are libgnomeui (and its rdep is linsmith)10:40
juliankthey are not in Debian testing, so prime candidate for removal10:41
-queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1] (no packageset)10:41
infinityjuliank: Wait, but you can't just sync that...10:46
juliankinfinity: No?10:46
infinityjuliank: Cause it needs all the control magic to takeover for the 0v5 one.10:46
infinityBasically, the exact inverse of what 0v5 does.10:46
infinityOr, just merge instead of syncing and keep the delta fiveever.10:47
juliankSo, it is safe to sync, as libsrecord0v5 Conflicts with libsrecord010:47
juliankit might trick apt into the wrong decision10:47
juliankbut we might get away with it even if it's wrong10:48
infinityupdate-manager won't upgrade that.  It'll poop and go partial.10:48
infinitySince the Conflicts/Replaces is in the other direction.10:49
infinityThe path of least resistance would have been to just beg Debian to do the (pointless?) ABI change. :P10:50
infinityOf course, someone should have done that 4 years ago.10:50
infinityIt's orphaned and QA maintained!10:52
infinityjuliank: You can just upload our delta to Debian and be done with it. :P10:52
infinityAlso, it's been uploaded once in the last 5 years, people clearly care deeply about it.10:53
juliankI mostly care about fixing the last few libgcrypt11-dev build-depends to say libgcrypt20-dev, and hence stumpled upon this10:53
* infinity nods.10:54
infinityI'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
juliankI asked Debian RT, and they mentioned debian bug 791295 - it was a conscious decision not to do the rename10: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/79129510:54
juliankAlthough, the Depends never happened10:55
juliankor well Breaks: srecord (<< version that expects pre-gcc5 things)10:55
infinityYeah, also, the "screw third-party software" stance feels wrong to me.10:56
infinityNo one said the ABI break wasn't real, just that they didn't care because no archive rdeps.10:56
infinityBut 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
infinityMy two cents.10:57
juliankIn any case, it's final buster freeze10:57
infinityOther option is a QA upload that just adds a Breaks/Conflicts against the 0v5 lib.10:57
infinitySo, no NEW processing, but we can sync that and it would Just Work.10:57
infinitySure, it might not migrate before release, not really an issue.10:58
infinitySince it's not broken in Debian.10:58
infinityAnd, like I said, one upload in 5 years doesn't point to a rapidly-changing history that you'd be blocking an RC upload. :P10:58
juliankcan do that later, but I don't want to block uploads to buster via unstable10:59
infinityOr slap it at experimental, but then you'd have to remember later, which sucks.10:59
julianknot sure how far we'll need that, I guess we still need it in 20.04?11:00
infinityAnyhow, I don't think we should let this version in eoan-proposed.  COncur?11:00
infinityYeah, we could just have a local delta to forcefully swap back and drop it post-20.0411:00
infinityBi-directional replaces is all manner of sketchy in dpkg, unfortunately, but the odds of interrupted upgrades and rollbacks are slim enough that meh.11:01
infinityOh, but it's C/R, not R, so it's not actually doing overwrites.11:02
juliankinfinity: 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" since11:02
infinityJust hinting.11:02
infinityI really wish someone had decided that a richer syntax was smarter than magic pair/triplet hints.11:03
juliankI filed bug 1825972 for the libgnome-keyring, libgnomeui, linsmith removal11:03
ubot5`bug 1825972 in linsmith (Ubuntu) "Remove libgnome-keyring, libgnomeui, linsmith from eoan" [Undecided,New] https://launchpad.net/bugs/182597211:03
julianknot sure if there's anything else to do - the packages are still in unstable after all, so would they sync again?11:04
infinityNot at the same versions.11:04
infinityBut new ones would.11:04
juliankthat should be fine I guess11:04
-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:05
juliankI feel like the rest of the week I'öö mainly be hitting autopkgtest retry buttons11:07
infinityYeah, I did that a LOT over the weekend.11:07
infinityI'm technically not here, but I decided to do a favour for Brian with precise-esm distro-into stuff.11:07
juliankAlso, I guess I'll be upgrading to eoan later today11:08
Laneyany particular problem?11:08
infinityLaney: With autopkgtest?11:08
infinityLaney: The biggest problem I had was the usual armhf-no-networky issue.11:09
juliankMore like I have a few tests failing with missing eoan in python-apt distro data11:09
juliankand gotta retry those11:09
-queuebot:#ubuntu-release- New binary: srecord [arm64] (eoan-proposed/universe) [1.64-1ubuntu1] (no packageset)11:09
Laneywhat the F is that problem about11:09
juliankbut also, quite a few in progress11:09
Laneylast I heard Steve was looking into it I think, but the ball is probably on the floor11:09
infinityLaney: 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:09
infinityI'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:10
Laneyright, I've never seen this particular problem on VMs11:11
infinityBut "blame lxd" also isn't a useful diagnosis.11:11
Laneywe did reconfigure armhf with Stéphane's recommended settings11:11
Laneybut that didn't completely fix the problem11:11
infinityIf 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:12
infinityBut 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:13
* juliank is always like "did I break software-properties?" when reading excuses, but then remembers it only failed because it needs new python-apt11:15
-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
infinityYeah, 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
infinityAll 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:16
-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-apt11:17
infinityUh oh, I think juliank is stuck in a loop.11:17
infinityCan we reboot him?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-apt11:18
juliankgoto out;11:18
juliankshould build a "could not find a distribution template for Ubuntu/" auto-retry11:18
juliankI did retry crash and software-properties now, in case anyone is wondering11:19
infinityI'm staying away from that stack, it's all yours.11:19
ddstreetjuliank 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
ddstreeti assume s-p doesn't currently use s-p because it predates that lib...11:26
ddstreeter, doesn't currently use launchpadlib, i mean11:27
infinityOh, sof.. RIght.11:27
infinityIt predates lplib by a couple of years.11:27
juliankso, it will pull it into a couple more tasks live server and cloud images11:27
infinityOTOH, 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
infinityI mean, if you're in a position to know the URL you want.11:28
ddstreetwell private ppas require authentication with lp11:28
infinityOh, private.  Right.  Fair enough.11:28
ddstreetit's really waaaaaaaay easier using lplib11:29
* infinity nods.11:29
juliankso this might blow up minimal images a bit I guess?11:29
ddstreetonce i have something to look at, i'll open a MP for your review11:29
juliankbut I don't really see any big issues11:29
* apw waits for his cve git repo to update11:30
infinityMinimal images shouldn't have software-properties.11:30
apw(and apprently for his irc client to switch buffers successfully, sigh)11:31
infinityIt's in desktop/server/cloud, nothing lower.11:31
juliankok, well, that makes sense11:32
infinityAnd 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
infinitySpeaking of that stack, sort of, it's a real shame we never managed to maintain update-manager in Debian in a reasonable fashion.11:34
infinityHonestly, 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
infinityIt's the little things.11:35
juliankDebian's stuck with PackageKit offline upgrades11:35
infinityI 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
infinityBlank screen, progress bar, angry message about not cutting power?11:36
juliankinfinity: Well, it installs _after_ reboot11:36
infinityBut in 2004/2005, update-manager was so much more slick than any other option.11:36
infinityjuliank: WIndows Updates "can't update locked files" updates happen post-reboot too.11:37
juliankthat's the key difference to Windows which installs before reboot and keeps you waiting, which is nice if you are low on power11:37
infinityUsually, 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:37
juliankI dropped update-manager in Debian to get rid of aptdaemon, as that ended up unmaintained, and packagekit became usable11:38
infinityI'm glad we're not that messy. :P11:38
juliankA lot of things would be a lot easier if we did offline upgrades, at least for release upgrades11:38
infinityCertainly less error prone in some cases, I don't disagree.11:39
infinityAnd I think for dist-upgrades, it's worth examining.11:39
infinityI mean, not the apt dist-upgrade case, but the "friendly" case.11:39
infinityI'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
infinityRetry limit of 3 or something, but once would usually do it.11:41
infinityA loop break at the dpkg level with a --force option we enable only for release upgrades could also work.11:42
infinityLike Debian used to --force-overwrite back in the bad old days.11:42
-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:08
-queuebot:#ubuntu-release- Unapproved: console-setup (disco-proposed/main) [1.178ubuntu12 => 1.178ubuntu12.1] (core)12:09
jdstrandhey, 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:36
jdstrandso no biggie))12:37
jdstrandstgraber: hey, you may know the 2nd part of that ^12:37
xnoxjdstrand, so, we need updated distro-info-data and then cpc to kick those build off.12:39
stgraberubuntu-daily is cloud-images so once a cloud image gets published you should be good12:39
xnoxjdstrand, but we can't have distro-info-data until EANIMAL is revealed.12:39
xnoxjdstrand, so ping mark12:39
jdstrandstgraber: thanks12:39
xnoxjdstrand, 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
jdstrandxnox: so we typically just wait until that happens before a thing that needs them migrates?12:40
xnoxjdstrand, imho, if $ ubuntu-distro-info --devel gives errors, one should fallback and use --stable12:40
xnoxjdstrand, something like that, yes.12:40
jdstrandok, thanks12:40
xnoxjdstrand, or ask release team / sru team to override, skiptest, mark bad test, etc.12:40
stgraberimages:ubuntu/eoan should work though as those are generated by the LXD team and they're showing up as green on our side12:41
jdstrandstgraber: + lxc launch ubuntu-daily:eoan/amd64 docker -c security.nesting=true12:41
jdstrandError: Failed container creation: The requested image couldn't be found12:41
jdstrandstgraber: maybe it was just a timing thing?12:41
xnoxjdstrand, images: != ubuntu-daily12:41
xnoxjdstrand, images: != ubuntu-daily:12:41
stgraberjdstrand: lxc launch images:ubuntu/eoan/amd6412:42
jdstrandthat's fair. note I was pretty clear that I didn't know what was being used ;)12:42
jdstrandstgraber: 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:43
jdstrandstgraber: actually, while I have you. did mdeslaur talk to you about libseccomp 2.4.1? also, do you use golang-seccomp?12:45
stgraberjdstrand: 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 dependencies12:46
stgraberjdstrand: we don't, no. LXD itself generates a liblxc plaintext policy whihc is then converted by liblxc (C library) using libseccomp12:47
jdstrandstgraber: cool. cause it had a bug in it you'd like want if you used it.12:47
jdstrandstgraber: 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 releases12:48
stgraberjdstrand: 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
jdstrandstgraber: iirc, you have a significant number of tests and it would be great if you could rung the libseccomp 2.4.1 packages through them12:49
stgraberjdstrand: 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 upstream12:50
jdstrandstgraber: we're hoping for testing prior to pushing to the archive12:50
jdstrandstgraber: I highly suggest looking at 2.4.112:50
stgraberjdstrand: yep, do you have those in -proposed? I can manually update our test runners for it (bionic)12:50
jdstrandstgraber: they aren't in proposed. let me ask mdeslaur what he thinks about pocket copying them12:51
jdstrandmdeslaur: stgraber is willing to testing lxd against our libseccomp updates. what do you think about them going to -proposed?12:51
mdeslaurjdstrand: I'm still unsure of the approach, so I'd rather we test lxd before sending them to -proposed12:52
mdeslaurbut if snap and lxd work, 2.4.1 in proposed sounds good12:53
mdeslaurjdstrand: ^12:53
jdstrandI'll be testing snapd today (so far it has been great)12:53
jdstrandstgraber: would our public security-proposed ppa work for you? something else? ^12:54
stgraberjdstrand: that's fine, I can just manually wget + dpkg install them12:54
jdstrandstgraber: ok. I'll copy them over. gimme a sec12:54
jdstrandmdeslaur: jeez we have access to a lot of ppas12:55
mdeslaurjdstrand: wait a sec12:55
mdeslaurjdstrand: I didn't put them there so people don't install them12:56
mdeslaurjdstrand: give stgraber access to our private ppa instead12:56
jdstrandI'll just scp them to people12:56
infinityxnox: Err, wat?12:57
xnoxinfinity, which bit? =)12:57
infinity06:39 < xnox> jdstrand, but we can't have distro-info-data until EANIMAL is revealed.12:57
jdstrandmdeslaur: we have people that regularly run our security proposed ppa?12:57
infinityxnox: distro-info-data is updated in every release going back to precise.12:57
xnoxinfinity, 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
infinityxnox: If anything's blocking cloud builds, it's not us.12:58
mdeslaurjdstrand: 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 stuck12:58
infinityxnox: No "planning" at all, it's done.  Days ago.12:58
jdstrandstgraber: I'm stepping into a meeting in 2 minutes. I'll ping you. thanks again12:58
xnoxinfinity, ok.12:58
jdstrandmdeslaur: I see. I'm pretty sure we are going to go forward. 2.3 is rather terrible wrt arg filtering I discovered12:59
xnoxdebootstrap is done too. Let me see where the eoan images are then12:59
jdstrandmdeslaur: but yes, must test :)12:59
infinityxnox: 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:01
xnoxbut i don't even see cpc-jenkins jobs to attempt building 19.10 which is way pre jerff bits.13:02
=== fidencio_ is now known as fidencio
xnoxjdstrand, infinity - pinged cpc team about it.13:14
jdstrandstgraber: fyi, http://people.canonical.com/~jamie/libseccomp/13:23
-queuebot:#ubuntu-release- Unapproved: debootstrap (disco-proposed/main) [1.0.112ubuntu1 => 1.0.112ubuntu1.1] (core)13:54
-queuebot:#ubuntu-release- Unapproved: debootstrap (cosmic-proposed/main) [1.0.108ubuntu1.1 => 1.0.108ubuntu1.2] (core)13:57
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95ubuntu0.3 => 1.0.95ubuntu0.4] (core)13:59
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.8 => 1.0.78+nmu1ubuntu1.9] (core)14:01
tewardum, is there any issue with the publishers to Proposed?14:09
tewardnginx has been stuck for 12 hours without being 'uploaded' - just stuck at 'pending publication' to proposed14:09
apwteward, it is in binary New14:12
tewardmissed that xD14:13
tewardapw: i'm guessing because there's a new .deb included in it.14:13
apwtkamppeter, geoip214:14
tewardwhich I had a discussion with sarnold about several times during last cycle :P14:14
tewardapw: guess i haven't had enough coffee to wake up today :)14:14
* teward goes and finds more14:14
tewardtkamppeter: 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:16
apwteward, and i read the associated bug as saying that it should end up in universe ...14:17
tewardcorrect, that is a Universe-targeted binary14:18
tewardit's not included in -core (that needs a MIR)14:18
tewardso 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
tewardbut 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 project14:19
tewardso that's taking some attention :p14:19
tewardwow 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:20
stgraberjdstrand: all our x86 CI nodes are now on the updated libseccomp, I'll let you know if we see anything bad happen14:40
jdstrandstgraber: great, thanks! (cc mdeslaur)14:41
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (disco-proposed) [1.0.112ubuntu1.1]14:42
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (cosmic-proposed) [1.0.108ubuntu1.2]14:47
-queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu6 => 1.78ubuntu7] (core)14:48
-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:50
bdmurrayinfinity: Were you going to verify tzdata?14:59
-queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (bionic-proposed) [1.18.0-1~ubuntu18.04.1]14:59
sil2100kenvandine, tkamppeter: hmm, the libqmi upload seems to have a bad version number15:03
sil2100kenvandine, tkamppeter: 1.22.0-1.3~ubuntu18.04.1, while I don't see 1.22.0-1.3 anywhere15:03
sil2100kenvandine, tkamppeter: so currently it would be higher than what's in disco/eoan15:03
sil2100Disco/eoan have 1.22.0-1.215:04
kenvandinei can reupload that in a couple minutes15:05
sil2100Thanks! :)15:06
sil2100I suspect 1.22.0-1.3 was supposed to be pushed to disco before release or something15:07
kenvandinei'll upload it as 1.22.0-1.2~ubuntu18.04.115:07
kenvandinesil2100: the problem there is it's older than the previous changelog entry15:10
kenvandinesil2100: i guess that's actually fine15:13
sil2100kenvandine: yeah, that's not a problem per-se, doesn't look perfect but yeah15:13
sil2100Many of our backport-SRUs have such situation15:13
kenvandinesil2100: ok, uploaded15:14
-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:15
-queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (bionic-proposed) [1.22.0-1.2~ubuntu18.04.1]15:17
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager [source] (bionic-proposed) [1.10.0-1~ubuntu18.04.1]15:19
tkamppetersil2100, I got a lot of messages about libmbim, is it correctly uploaded now? What was wrong with it?15:20
-queuebot:#ubuntu-release- Unapproved: accepted ureadahead [source] (xenial-proposed) [0.100.0-19.1]15:22
sil2100tkamppeter: 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 disco15:22
sil2100tkamppeter: so if we'd accept it, the package in bionic would have a higher version number than in disco/eoan15:23
sil2100tkamppeter: but Ken tweaked it15:23
vorloninfinity, 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/arm6415:24
tkamppeterI 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:28
tkamppetersil2100, kenvandine ^^15:29
kenvandinethat is really strange!15:29
kenvandinei wonder if i screwed that up :)15:29
tkamppetersil2100, 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
kenvandineit's been so long, i don't recall15:29
cyphermoxvorlon: ok15:31
sil2100tkamppeter: ouch, yeah, looks like those failed due to some LP issues, let me look15:33
Laneyvorlon: 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:33
tkamppetersil2100, 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:34
kenvandinetkamppeter: yes15:35
kenvandinetkamppeter: please email him about that15:35
tkamppeterkenvandine, done.15:42
kenvandinetkamppeter: thanks15:43
tkamppetersil2100, thank you very much for having modemmanager passed into -proposed.15:43
vorlonLaney: oh the 21st was after the release date as well, ok.  So yeah, it regressed shortly after archive opening :)15:50
sil2100tkamppeter: your welcome! libmbim is now built correctly, so now modemmanager should be able to build soon as well15:50
cyphermoxLaney: you're not missing anything, this isn't a regression, it's a test that is not flexible enough15:53
-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:05
-queuebot:#ubuntu-release- New binary: clamav [i386] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)16:07
-queuebot:#ubuntu-release- New binary: clamav [amd64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)16:08
acheronukwho needs to tell 'reverse-depends' about eoan? I can't recall who16:08
vorlontumbleweed: ^^16:09
-queuebot:#ubuntu-release- New binary: clamav [arm64] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)16:09
-queuebot:#ubuntu-release- New binary: clamav [armhf] (eoan-proposed/main) [0.101.2+dfsg-1ubuntu1] (ubuntu-server)16:10
tumbleweedvorlon: does eoan have a name yet?16:29
tumbleweedthat's blocking it16:29
xnoxtumbleweed, eoan is the adjective to use; there is no animal yet, but it shouldn't matter, right?16:30
xnoxtumbleweed, note how all of distro-info-data updated already, and debootstrap, etc.16:30
tumbleweedno, it's not (in Debian)16:30
tumbleweedI'm not going to get it updated in Debian, if we're getting a name, tomorrow16:30
xnoxtumbleweed, ransom holder!16:31
xnoxtumbleweed, i wish we knew if and when we get the eanimal16:31
tumbleweedI was giving it a few days to see if a name would appear16:31
vorlontumbleweed: why is the Ubuntu reverse-depends service blocked on a Debian upload of distro-info-data?16:47
tewardtkamppeter: got a few minutes to look at nginx in the NEW queue?16:53
tewardif you're not busy.16:53
tumbleweedvorlon: it's actually blocked on a git checkout of distro-info-data16:56
tumbleweedso I can just commit EANIMAL to that16:56
tumbleweedbut I was assuming we'd get an animal within a day or two16:57
tumbleweedis that unlikely?16:57
vorlontumbleweed: why wouldn't you just use the Ubuntu distro package anyway, given that distro-info-data is always srued?16:57
vorlontumbleweed: I have no control over the timeline, and reverse-depends not working is a nuisance now16:57
vorlonnot enough for me to have complained directly, but I'm +1ing acheronuk ;)16:57
tumbleweedbecause I didn't have root on ubuntuwire at the time16:57
vorlonah ;)16:57
* tumbleweed can probably unwind all of that16:58
tumbleweedI would like an animal, of course16:59
tumbleweedand I'm slightly worried that without the pressure of opening the release, it will take months now16:59
cjwatsonIf 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
tewardmultiversal panic perhaps? :P17:01
tumbleweedterrible wallpaper image?17:01
vorlonEoan Eoanimal, pronounced "an animal"17:01
tumbleweedno t-shirt :P17:01
cjwatsonI mean that's the designers' problem and they can apply whatever pressure they can if they need to :)17:01
cjwatsonBut the null animal seems like a better default than errno jokes that probably wouldn't be very good to actually release with17:02
cjwatsonAnd a more generalisable precedent if we had to17:02
* tumbleweed pulls out all of those local checkouts on my ubuntuwire cronjobs17:02
tewardanyone 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:05
tkamppeterteward, nginx in the new queue? What is that?17:25
tewardtkamppeter: apw pinged you maybe the wrong one to ping17:25
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 package17:26
tewardthough those binaries for libnginx-mod-http-geoip2 are new they should be demoted to Universe.17:27
tkamppeterteward, I think it was not meant for me, as I do all the printing stuff and network-manager.17:27
tewardwell in any case17:27
tewardi am a patient person and will wait :)17:27
teward... now if only people would stop calling my phone every 3 minutes17:27
tkamppeterI am also not responsible for the NEW queue.17:28
tewardas I said i'll wait :)17:28
tewardvorlon: 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.17:31
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (cosmic-proposed) [1:0.4.2]18:09
vorlonLaney, juliank: do you know anything about why ppc64el autopkgtest queues are lagging?18:32
vorlonalso why is armhf zippy all of a sudden, that's very suspicious18:35
ddstreetbdmurray 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 qemu18:37
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [sync] (bionic-proposed) [2.7.15-4ubuntu4~18.04]18:49
vorlonteward: ^^ some progress18:49
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [sync] (bionic-proposed) [3.6.8-1~18.04.1]18:56
coreycbvorlon: i'm not sure why python-formencode is listed as an openstack package19:06
tewardvorlon: indeed.19:12
tewardvorlon: would you be able to take a look at nginx in the NEW queue per chance?19:12
vorloncoreycb: https://bugs.launchpad.net/ubuntu/+source/python-formencode/+bug/49359319:12
ubot5`Ubuntu bug 493593 in scgi (Ubuntu Lucid) "MIR for paste." [High,Fix released]19:12
tewardif not that's fine, it's not a huge priority19:12
coreycbvorlon: 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
vorlonteward: well I'm currently still working on those SRU reviews19:12
tewardack, no problem.19:12
vorloncoreycb: if you want to negotiate having another team take over ownership of it in main, that'd be between you and them :)19:13
coreycbvorlon: 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:14
juliankvorlon: only heard about armhf having no networking or something19:16
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [sync] (bionic-proposed) [2.1.4-1ubuntu1.3]19:30
tsimonq2vorlon: You're welcome to sync.19:49
vorlonxnox: 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:48
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [source] (bionic-proposed) [2.5.1-1ubuntu1.3]20:49
tumbleweedreverse-depends for eoan have generated22:03
vorlontumbleweed: thanks22:06
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [sync] (bionic-proposed) [3.7.3-2~18.04.1]22:33
xnoxtumbleweed, we worship you!22:44
bdmurrayinfinity: Were you going to do that tzdata verification?23:00
infinitybdmurray: 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
infinitybdmurray: I can look later tonight.23:01
bdmurrayinfinity: I'm sorry you are sick man.23:04
tumbleweedxnox: pff. I'm lazy23:06
tsimonq2infinity: Less derp in the pastebinit version for Disco now, thanks.23:25
-queuebot:#ubuntu-release- Unapproved: pastebinit (disco-proposed/main) [1.5-2 => 1.5-2.2~ubuntu0.19.04.1] (core)23:26
Eickmeyertsimonq2: We all need a little less derp in our lives.23:35
tsimonq2Eickmeyer: I have no clue what I was thinking when I typed 1.5-2.2ubuntu~ and thought "this is totally a valid version!"23:36
Eickmeyertsimonq2: haha! Yeah, that is... wow.23:36
* tsimonq2 steals teward's coffee23:36
* Eickmeyer follows the coffee23:37
* Eickmeyer like a puppy dog23:37
tsimonq2haha :)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:37
* Eickmeyer folows the coffee like a puppy dog23:38
-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:46
xnoxinfinity, in france, if one is sick during holidays, one gets to reclaim those days!23:47
xnoxvorlon, ruby2.5 respun ^^^ skipped a version number, but otherwise it should be a clean diff on top of bionic-security.23:47
xnoxvorlon, 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:48
xnoxvorlon, ah, nevermind see the emails from you now!23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!