[02:44] <xnox> vorlon:  doko: can you please remove dogtag-pki from focal & freeipa? https://bugs.launchpad.net/ubuntu/+source/dogtag-pki/+bug/1858967
[04:04] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.6-1ubuntu1 => 1.3.6-1ubuntu1] (core)
[04:08] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.6-1ubuntu1 => 1.3.6-1ubuntu1] (core)
[04:08] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.6-1ubuntu1 => 1.3.6-1ubuntu1] (core)
[05:54] <tjaalton> echoing here..
[05:54] <tjaalton> xnox: the reason why it's not in testing or stable is because openjdk-8 will never migrate. and it works just fine with current nss, and supports tls 1.3 via jss
[05:56] <tjaalton> fedora hasn't moved on from jdk8 yet, which is why jdk11 support hasn't been a top priority. jss and dogtag do now build fine against it, but the rest is still WIP
[08:28] -queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [208-1~ubuntu19.10.1 => 210-1~ubuntu19.10.1] (no packageset)
[08:32] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [210-1~ubuntu19.10.1]
[08:32] -queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [208-1~ubuntu19.04.1 => 210-1~ubuntu19.04.1] (no packageset)
[08:33] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [210-1~ubuntu19.04.1]
[08:33] -queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [208-1~ubuntu18.04.1 => 210-1~ubuntu18.04.1] (no packageset)
[08:40] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [210-1~ubuntu18.04.1]
[09:08] <jamespage> ahasenack: I think most mojo usage is not via packages tbh
[09:20] <LocutusOfBorg> vorlon, can we please hint cp2k on armhf? regressed in release http://autopkgtest.ubuntu.com/packages/c/cp2k/focal/armhf
[09:21] <LocutusOfBorg> so we might have some scalapack/petsc/slepc/mumps/ and something else migrate
[09:22] <LocutusOfBorg> maybe kicking out sdpa from release pocket until openblas is fixed might help a lot
[10:44] <oSoMoN> firefox is blocked in focal-proposed because of the missing i386 build, I thought this had been dealt with already?
[10:50] <oSoMoN> Laney, vorlon: I noticed there's a duplicate force-badtest entry for firefox/armhf in lp:~ubuntu-release/britney/hints-ubuntu, so one of them should be removed
[10:50] <oSoMoN> and interestingly the last 8 test runs have passed consistently (http://autopkgtest.ubuntu.com/packages/firefox/focal/armhf), so maybe remove both entries?
[10:55] <Laney> okey dokey
[11:15] -queuebot:#ubuntu-release- New binary: python-intervaltree-bio [amd64] (focal-proposed/none) [1.0.1-3.1] (no packageset)
[11:31] -queuebot:#ubuntu-release- New source: pop-gtk-theme (focal-proposed/primary) [5.0.0~1576602011~19.10~7760154~ubuntu1]
[11:32] -queuebot:#ubuntu-release- New source: pop-icon-theme (focal-proposed/primary) [2.1.0~1571158475~19.10~6bf9347~ubuntu1]
[12:12] <oSoMoN> dear SRU team: can someone please review chromium-browser 79.0.3945.79-0ubuntu0.19.10.2 in the eoan queue?
[12:14] <ahasenack> jamespage: looks like IS built their own package, for trusty
[12:15] <ahasenack> at least on wendigo
[12:22] <oSoMoN> vorlon, can you please help unblocking firefox in focal-proposed (blocked by the missing i386 builds)?
[12:27] <jamespage> ahasenack: I think we're only talking about RM'ing for focal development
[12:28] <ahasenack> jamespage: yeah, I'm fine with that, I checked yesterday and updating to 0.11.0 (latest upstream) was annoying, and just fixing the existing old version was annoying as well, it's an old package that has not been rebuilt recently
[12:28] <ahasenack> just copied over from release to release
[12:30] <doko> xnox, vorlon: I see that tjaalton handles these ...
[14:04] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.2 => 1.2.10-1ubuntu2~ubuntu18.04.3] (desktop-core)
[14:16] -queuebot:#ubuntu-release- New: accepted open-font-design-toolkit [amd64] (focal-proposed) [1.8]
[14:16] -queuebot:#ubuntu-release- New: accepted python-intervaltree-bio [amd64] (focal-proposed) [1.0.1-3.1]
[14:21] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-172.202] (core, kernel)
[14:23] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-172.202]
[14:51] <superm1> can someone poke the fwupd in focal unapproved?  I'm hoping it sorts out the transient autopkgtest failures that have been preventing migration.
[14:53] -queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.0.0-0ubuntu1 => 2:15.0.1-0ubuntu1] (openstack, ubuntu-server)
[14:53] -queuebot:#ubuntu-release- Unapproved: octavia (eoan-proposed/universe) [5.0.0-0ubuntu1 => 5.0.1-0ubuntu1] (no packageset)
[14:53] -queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.0-0ubuntu1 => 2:15.0.1-0ubuntu1] (openstack, ubuntu-server)
[15:10] <seb128> superm1, hey, happy new year!
[15:10] <seb128> superm1, ^
[15:10] <seb128> superm1, ups, I though the bot showed that but I accepted them now
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.6-1ubuntu1]
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.6-1ubuntu1]
[15:11] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.6-1ubuntu1]
[15:31] <seb128> can someone ignore the openjdk-13/14 armhf autopkgtest failures for libglvnd? those are clearly not due to that lib, just not working more often than not and taking ages when they do work still
[16:08] <vorlon> LocutusOfBorg: where do you see that it has regressed in release? http://autopkgtest.ubuntu.com/packages/c/cp2k/focal/armhf shows failures for the -proposed version only
[16:08] <vorlon> LocutusOfBorg: I have been working on this transition, cp2k is the problematic one because the regression happens as a result of the Debian changes
[16:09] <vorlon> oSoMoN: not blocked by missing build but by failing autopkgtest; I'll hint it now
[16:12] <superm1> seb128: happy new year to you too.  great thanks!
[16:16] <ddstreet> vorlon i see ubuntu-distro-info lists next friday as the final day for Disco, but i havent' seen any reminder email yet, is that day correct or will disco eol later in the month?
[16:18] <vorlon> infinity: ^^
[16:23] <infinity> ddstreet, vorlon: Ahh, yeah, the notice should have gone out when we were all still on holidays to make that date.  I'll send it today, and it'll be today + 14 days.
[16:23] <ddstreet> thnx!
[16:23] <LocutusOfBorg> 6.1-3build1 	cp2k/6.1-3build1 	2020-01-05 06:34:12 UTC 	1h 29m 05s 	vorlon 	fail 	log   artifacts  
[16:23] <LocutusOfBorg> vorlon, ^^
[16:23] <LocutusOfBorg> oh got it
[16:23] <LocutusOfBorg> meh
[16:24] <LocutusOfBorg> a nasty guy might want to sync cp2k from experimental
[16:41] <oSoMoN> vorlon, thanks
[16:47] <vorlon> LocutusOfBorg: given that many of the test regressions seem to be due to changes to what version of libint is linked against, probably not
[16:52] -queuebot:#ubuntu-release- New binary: plymouth [s390x] (focal-proposed/main) [0.9.4git20200109-0ubuntu1] (core)
[16:53] -queuebot:#ubuntu-release- New binary: plymouth [ppc64el] (focal-proposed/main) [0.9.4git20200109-0ubuntu1] (core)
[16:55] -queuebot:#ubuntu-release- New binary: plymouth [arm64] (focal-proposed/main) [0.9.4git20200109-0ubuntu1] (core)
[16:58] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-27.29] (core, kernel)
[16:58] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-27.29] (core, kernel)
[16:58] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-27.29] (core, kernel)
[16:59] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-27.29] (core, kernel)
[17:03] -queuebot:#ubuntu-release- New binary: plymouth [armhf] (focal-proposed/main) [0.9.4git20200109-0ubuntu1] (core)
[17:29] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-27.29]
[17:29] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-27.29]
[17:29] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-27.29]
[17:29] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-27.29]
[17:31] -queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (focal-proposed/main) [19.11-2ubuntu1] (ubuntu-server)
[17:43] -queuebot:#ubuntu-release- New binary: dpdk [armhf] (focal-proposed/main) [19.11-2ubuntu1] (ubuntu-server)
[17:54] <ahasenack> did the excuses page break, or is it just taking longer to process all the data? Timestamp is Generated: 2020.01.09 15:18:56 +0000
[17:54] <ahasenack> that's over 2h ago
[17:56] <RikMills> ahasenack: proposed migration runs have been failing with: "FATAL: Failure to fetch swift results from ...."
[17:57] <RikMills> current one is still going so fingers crossed
[17:57] <ahasenack> oh
[17:57] <RikMills> damn. that crashed
[17:57]  * RikMills jinxed it
[17:58] <ahasenack> so canonistack issue?
[17:59] <RikMills> Laney cjwatson? ^
[17:59] <cjwatson> RikMills: autopkgtest isn't me
[18:00] <RikMills> sorry. hard to keep track of who pushes buttons on what!
[18:00] -queuebot:#ubuntu-release- New binary: dpdk [amd64] (focal-proposed/main) [19.11-2ubuntu1] (ubuntu-server)
[18:01] <Laney> I'll ask IS but I can't really stick around
[18:01] <ahasenack> RikMills: where did you see that error?
[18:02] <Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/focal/2020-01-09/
[18:02] <Laney> worth bookmarking
[18:02] <ahasenack> til
[18:04] <ahasenack> thanks, and thanks for checking with #is
[18:05] <Laney> OK it's being looked into, maybe vorlon can update this channel when there's an outcome
[18:05] <Laney> o/
[18:06] <vorlon> ack
[18:21] -queuebot:#ubuntu-release- New: accepted dpdk [amd64] (focal-proposed) [19.11-2ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (focal-proposed) [19.11-2ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted plymouth [armhf] (focal-proposed) [0.9.4git20200109-0ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted plymouth [s390x] (focal-proposed) [0.9.4git20200109-0ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted dpdk [armhf] (focal-proposed) [19.11-2ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted plymouth [ppc64el] (focal-proposed) [0.9.4git20200109-0ubuntu1]
[18:21] -queuebot:#ubuntu-release- New: accepted plymouth [arm64] (focal-proposed) [0.9.4git20200109-0ubuntu1]
[18:53]  * infinity side-eyes nova, and wonders why it's suddenly trying to pull a different netcat implementation into main.
[18:54] <vorlon> infinity: because it's the one that still exists on i386 (it's an arch: all package)
[18:54] <infinity> Well, maybe not "suddenly".  Seems the release pocket has this oddity too.
[18:54] <infinity> vorlon: Oh.  That makes more sense.  And ick.
[18:55] <infinity> vorlon: Was just going through c-m/c-m-p, didn't think to apply a "lol i386" filter to it.
[18:55] <vorlon> :)
[18:55] <infinity> vorlon: Plans to remove nova/i386 or resurrect netcat-openbsd/i386?
[18:56] <vorlon> infinity: problem is, nova is *also* arch: all
[18:56] <infinity> Oh.  More ick.
[18:56] <vorlon> not sure if marking nova as seeded only on !i386 would help
[18:57] <vorlon> or just make germinate grow a hand so it can hold the knife to stab me
[18:57] <infinity> It won't.
[18:59] <infinity> vorlon: Resurrecting netcat-openbsd/i386 doesn't seem like it'd be super awful.
[18:59] <infinity> Only deps are libc6 and libbsd0 (which seems to still exist on i386 for now)
[19:00] <vorlon> infinity: ok.  add it to the seed and resurrect?
[19:00] <infinity> Will do.
[19:01] <Kamilion> Busy testrolling my focal iso, went to install squid-deb-proxy-client, it wanted to pull in py2, so I threw half an hour at bringing it to py3. Patch sent to mvo@debian, I'll leave it here too. https://files.sllabs.com/files/storage/code/ubuntu/apt-avahi-discover.p3.patch
[19:03] <rbasak> Nice, thanks!
[19:04] <vorlon> infinity: oh also since netcat-openbsd had an upload after the filter went into effect, looks like the resurrect requires a manual packageset tweak plus a no-change rebuild :P
[19:05] <infinity> vorlon: Yes to the first, no to the second (I have magic powers).
[19:05] <vorlon> hngh ok
[19:06] <vorlon> infinity: anyway I've addded it to the packageset for you
[19:06] <infinity> vorlon: Shiny, then I shall magically power it.
[19:08] <infinity> 2020-01-09 19:08:01 INFO    Considering netcat-openbsd 1.206-1 in focal
[19:08] <infinity> 2020-01-09 19:08:01 INFO    Created 1 build(s)
[19:11] <infinity> vorlon: And re-published the release pocket version in case the proposed one gets stuck.
[19:12] <infinity> s/gets/stays/ ..
[19:18]  * infinity removes linux-oem-osp1 with extreme prejudice now that the meta is transitioned.
[19:22] -queuebot:#ubuntu-release- Packageset: Added netcat-openbsd to i386-whitelist in focal
[20:27] <Eickmeyer> I see nobody has taken a look at lv2vst in NEW yet? This is part of a backup plan in case Hydrogen doesn't release a 1.0 in time for Focal so that we can change our manual ISO QA tests if necessary.
[20:28] <Eickmeyer> Basically, I need this ASAP as its a build-dep for another package we need (avldrums.lv2).
[20:37] -queuebot:#ubuntu-release- New binary: sight [amd64] (focal-proposed/universe) [19.0.0-4] (no packageset)
[21:01] <vorlon> I didn't get any specific updates from IS, but I see that the latest p-m run has cleared the swift problems of before
[21:02] <RikMills> :)
[21:50] <vorlon> infinity: I don't see your netcat-openbsd/i386 binaries in either pocket yet, do you know if there've been publisher problems?
[21:53] <vorlon> first time I've ever had syncpackage -f fail complaining that it can't verify the gpg signature on the source package. :/ is that a question of out-of-date debian-keyring on the client OS?
[21:53] <vorlon> and I see no option to skip verification
[21:54] <vorlon> (package is libfastahack, client OS is eoan)
[21:55] <vorlon> works if I run syncpackage from focal
[21:58] <mfo> Question on apparent SRU corner case.  A package has a bug when running in the v5.3 kernel. Thus it needs fixing in Eoan and Bionic (for the HWE kernel).  Does Disco (regardless of time-to-EOL at this point) which runs the v5.0 kernel thus not affected, needs the patches too, for the only reason that they're being introduced in an earlier release (Bionic), and the rule is that all later releases should have the fixes too?
[22:01] <mfo> Other question is obviously, now considering Disco time-to-EOL, must it get not-too-serious-impact fixes now (e.g, case above), given that -proposed takes 7+ days, and it has ~14 left?  Not a problem uploading it, just want to make not spending other reviewers/sru-team time.
[22:01] <mfo> s/make not/make sure I'm not/
[22:02] <infinity> vorlon: https://launchpad.net/ubuntu/focal/i386/netcat-openbsd
[22:03] <infinity> vorlon: Things are slow, but getting there.
[22:03] <vorlon> yeah, was wondering about the "are slow" part
[22:04] <infinity> Thu, 09 Jan 2020 18:07:13 +0000: Triggering archive.syncproxy.ubuntu.com:
[22:04] <infinity> Thu, 09 Jan 2020 18:07:13 +0000: Triggering ports.syncproxy.ubuntu.com:
[22:04] <infinity> Thu, 09 Jan 2020 20:40:33 +0000: Triggering archive.syncproxy.ubuntu.com:
[22:04] <infinity> Thu, 09 Jan 2020 20:40:34 +0000: Triggering ports.syncproxy.ubuntu.com:
[22:04] <vorlon> mfo: don't bother with disco
[22:04] <infinity> Thu, 09 Jan 2020 21:54:02 +0000: Triggering archive.syncproxy.ubuntu.com:
[22:04] <infinity> Thu, 09 Jan 2020 21:54:03 +0000: Triggering ports.syncproxy.ubuntu.com:
[22:04] <infinity> There are a few very long runs in a row.  Current one's not super quick either.  Should be clearing up, I hope.
[22:05] <vorlon> mfo: because of the timing.  This does make me wonder however what we do for users who have installed the HWE kernel on bionic, then configure do-release-upgrader for non-LTS upgrades and then upgrade to disco
[22:06] <vorlon> since the linux-hwe metapackage doesn't exist at all in non-LTS releases currently
[22:06] <mfo> vorlon, yeah, ddstreet and I were wondering about that too.
[22:06] <vorlon> I guess this means a user who has installed the hwe kernel - which is the default for some install media starting with the .2 point release - wind up with no kernel support after upgrade
[22:06] <vorlon> bdmurray: ^^ do you know of any release-upgrader handling to the contrary?
[22:07] <mfo> vorlon, for now, I was most curious if there's anything set in stone that later releases should have the patches introduced in earlier releases, even if not affected, for whatever reason/policy.
[22:07] <mfo> say, if a similar case pops up in the future.
[22:07] <mfo> for a release that would take longer to EOL :)
[22:08] <vorlon> mfo: the rule is that if you fix a bug in one release, it shouldn't regress for the user when they upgrade to a later release
[22:08] <infinity> vorlon: I feel like Andy and I have discussed this in the past, and the plan was for LTS+1 and beyond to have the meta revert hwe-XX.XX to generic, but I'm not sure if that ever happened past discussion.
[22:08] <infinity> vorlon: It absolutely is not the release upgrader's job to get that right, IMO.
[22:09] <vorlon> infinity: well, linux-image-generic-hwe-18.04 exists only in bionic and focal
[22:09] <infinity> Right, so that never got past the discussion stage, apparently. :P
[22:09] <infinity> Could still be fixed in eoan if we cared.  Or we could turn over a new leaf for 20.10 and beyond.
[22:12] <apw> infinity, i believe that those transition to -generic in focal
[22:12] <mfo> vorlon, right, that I know. but in this case (ignoring for a moment the possibility of ending up with a v5.3 kernel in Disco via Bionic upgrade), where there's no 'regression' possible bcz the supported configuration does not allow it to happen.   I guess the question is,  is this a rule based on 'make sure the code is applied, regardless'  or on 'avoid regressions where they can happen' (on the supported configurations).
[22:12] <infinity> apw: They sure do.  But the point is that they should do so earlier as well, for people upgrading to interim releases from .2 through .4
[22:12] <infinity> apw: And I thought we'd planned on that, but maybe it's all in my head.
[22:13] <infinity> mfo: The rule is avoid regressions, not pointlessly copy and paste dead code.
[22:13] <apw> infinity, hmm yes, we might have intended to do that
[22:13] <mfo> infinity, alright, that phrases it pretty well.
[22:14] <mfo> vorlon, infinity: thanks
[22:16] <infinity> vorlon: Looks like all things Soyuz have been gummed up by chubby security releases.  I *think* the current cycle in progress should be the last long one.
[22:17] <infinity> Maybe.
[22:17] <wgrant> process-build-uploads is sluggish atm due to some KDE stuff
[22:20] <infinity> Ahh, yes, there's also that.  Which was why my build took 37 years to "upload".
[22:20] <infinity> But I was strictly looking at publisher timings here.
[22:20] <infinity> Which is currently firefox security (and other misc).
[22:21] <cjwatson> Also long backlog from network trouble I think
[22:22] <infinity> The best solution is to stop watching the log and to start driving to the taco place.
[22:22] <wgrant> Definitely.
[22:33] <vorlon> doko: I've had a look now at the specifics of the gcc-9/i386 autopkgtest failures.  it's an interesting case, of course the autopkgtest wants to install the i386 gcc, but because my autopkgtest cross patch uses apt-get build-dep, we're stuck because apt-get also enforces that the build-essential package be installed despite this not being declared anywhere... and of course gcc-9:i386 conflicts with
[22:33] <vorlon> a dependency of build-essential.  I wonder if juliank has thoughts on apt-get build-dep --without-build-essential
[22:51] <infinity> vorlon: A cross apt-get build-dep should install the right cross-build-essential, ideally.  Not sure if it knows how to do that and, if so, not sure you'd be calling it in a way that would do so.
[22:51] <infinity> I think last time we did mass cross-building, that hack was in sbuild, not apt.
[22:52] <vorlon> infinity: we are calling apt-get build-dep -a arch
[22:52] <vorlon> it still enforces build-essential in addition to crossbuild-essential-arch
[22:52] <infinity> That doesn't seem right.  Should be one or the other, I'd think, not both.
[22:54] <infinity> Or maybe it is right.  It's been a while since I walked those twisty cross-build roads.
[22:54] <infinity> I guess cross does want HOSTCC and BUILDCC to both exist for $reasons, so maybe having both build-essentials is correct.
[23:59] -queuebot:#ubuntu-release- Unapproved: openssh (eoan-proposed/main) [1:8.0p1-6build1 => 1:8.0p1-6ubuntu0.1] (core)