[08:26] -queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20190827-1~ubuntu18.04.1 => 0.2.0+git20190827-1ubuntu0.18.04.1] (no packageset)
[08:26] -queuebot:#ubuntu-release- Unapproved: libclc (eoan-proposed/universe) [0.2.0+git20190827-1 => 0.2.0+git20190827-1ubuntu0.19.10.1] (no packageset)
[08:27] <tjaalton> sil2100: hi, these ^ fix a regression with opencl
[08:39] -queuebot:#ubuntu-release- New binary: pynag [amd64] (focal-proposed/universe) [1.1.2+dfsg-1ubuntu1] (no packageset)
[09:11] <sil2100> tjaalton: oh no, ok! Looking
[09:15] <sil2100> tjaalton: did you push this revert to focal as well?
[09:16] <tjaalton> sil2100: it'll sync from debian
[09:17] <sil2100> Awesome
[09:19] -queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (eoan-proposed) [0.2.0+git20190827-1ubuntu0.19.10.1]
[09:20] -queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1ubuntu0.18.04.1]
=== cpaelzer__ is now known as cpaelzer
[09:26] <tjaalton> thanks1
[09:26] <tjaalton> !
=== andrewc is now known as Guest14485
=== enyc_ is now known as enyc
[10:26] <juliank> We should force-badtest aptdaemon/arm64/all I think
[10:27] <juliank> It did pass _once_
[10:27] <juliank> once in eoan, once in focal so far
[10:27] <juliank> there's a race condition somewhere that's been there forever
[10:28] <juliank> Then we can have aptdaemon migrate to release
[10:28] <juliank> which will partially unblock python-apt 1.9.5 I just pushed to proposed
[11:07] <xnox> sil2100:  casper is verified in bionic, can it please be released early such that i can upload it again?
[11:12] <sil2100> xnox: yeah, on it! In the meantime, just upload it to the queue and I'll pick it up in a moment
[11:12] <sil2100> Thanks!
[11:13] -queuebot:#ubuntu-release- Unapproved: casper (bionic-proposed/main) [1.394.2 => 1.394.3] (desktop-core, ubuntu-server)
[11:15] -queuebot:#ubuntu-release- New binary: node-node-sass [amd64] (focal-proposed/universe) [4.13.1-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: python-quantities [amd64] (focal-proposed/none) [0.12.4-1] (no packageset)
[11:18] -queuebot:#ubuntu-release- New: accepted node-node-sass [amd64] (focal-proposed) [4.13.1-1]
[11:18] -queuebot:#ubuntu-release- New: accepted v-sim [arm64] (focal-proposed) [3.7.2-8]
[11:18] -queuebot:#ubuntu-release- New: accepted python-quantities [amd64] (focal-proposed) [0.12.4-1]
[11:18] -queuebot:#ubuntu-release- New: accepted v-sim [armhf] (focal-proposed) [3.7.2-8]
[11:18] -queuebot:#ubuntu-release- New: accepted v-sim [amd64] (focal-proposed) [3.7.2-8]
[11:19] -queuebot:#ubuntu-release- New: accepted v-sim [s390x] (focal-proposed) [3.7.2-8]
[11:19] -queuebot:#ubuntu-release- New: accepted v-sim [ppc64el] (focal-proposed) [3.7.2-8]
[11:22] <xnox> apw:  infinity: sil2100: seeding oem kernels in focal properly https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/patch/?id=c287b1923d23ac9ef72d08dbc56f32757f7168df they appear to have landed into universe pocket for now.
[11:26] <apw> xnox, ta
[11:30] -queuebot:#ubuntu-release- New: accepted pynag [amd64] (focal-proposed) [1.1.2+dfsg-1ubuntu1]
[11:30] -queuebot:#ubuntu-release- New: accepted dbus-cpp [amd64] (focal-proposed) [5.0.1-1]
[11:30] -queuebot:#ubuntu-release- New: accepted dbus-cpp [arm64] (focal-proposed) [5.0.1-1]
[11:37] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394.3]
[12:52] <ahasenack> hi release team, if someone could please merge https://code.launchpad.net/~ahasenack/britney/samba-i386-bump/+merge/378163
[13:06] -queuebot:#ubuntu-release- New binary: neo [amd64] (focal-proposed/universe) [0.7.2-2] (no packageset)
[13:08] <tumbleweed> ahasenack: let's move that to a * then
[13:08] <ahasenack> I tend to be conservative with *, and i386 issues
[13:08] <tumbleweed> if we don't expect it to ever pass, it should be a *
[13:09] <ahasenack> at the same time, it seems to be under a section called "needs investigation", and it's possible I missed something
[13:09] <tumbleweed> half the other packages in the archive are
[13:09] <tumbleweed> it sounds like you investigated :P
[13:09] <ahasenack>  the dropping of samba/i386 (the bin package) was a request from vorlon, and he reviewed that, so I'm not sure why he didn't use * already
[13:10] <ahasenack> that's all
[13:10] <ahasenack> tumbleweed: can  you merge that? Or are you just commenting?
[13:10] -queuebot:#ubuntu-release- New: accepted neo [amd64] (focal-proposed) [0.7.2-2]
[13:10] <tumbleweed> I can merge that
[13:12] <ahasenack> do you want me to change it to *?
[13:12] <tumbleweed> naah, I can post-merge
[13:12] <sforshee> doko: yes they are
[13:12] <ahasenack> tumbleweed: thanks!
[13:14] <doko> sforshee: I'm asking "what are they?", and you reply with "yes they are"?
[13:17] <sforshee> doko: sorry, misread. The previous arm64 kernels wouldn't boot, and xnox told us there had been a binutils problem with arm64 which was fixed. Rebuilding the kernel fixed the arm64 boot issue
[13:18] <doko> sforshee: yes, just wondering that I see these changelog entries now a lot
[13:22] <sforshee> doko: we haven't done many of these type of uploads at all for devel series kernels that I can recall, if you are talking about SRU kernels I'm not so much in the loop on those
[13:34] <doko> vorlon: please could you add a python3-defaults hints like the one we had for python-defaults?
[13:46] <ahasenack> hi release team, another i386 bump for your consideration please: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/378167
[13:47] <ahasenack> ops, wrong merge target
[13:49] <ahasenack> fixed^
[13:55] <apw> ahasenack, not looking any different, showing 8k lines of change
[13:55] <ahasenack> the url probably changed
[13:55] <ahasenack> let me paste
[13:55] <ahasenack> apw: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/378168
[13:56] <ahasenack> sorry
[13:58] <ahasenack> thanks apw
[14:07] <xnox> apw:  components missmatches has now caught up, please promote oem stuff to main in focal as per https://lists.ubuntu.com/archives/ubuntu-release/2020-January/004890.html
[14:10] <xnox> once that publishes, we can re-add livecd-rootfs change to install oem kernel flavour
[14:43] <apw> xnox, wiggled
[14:47] <xnox> apw:  Ok google, play "Wiggle" feat. Snoop Dogg by Jason Derulo
[15:40] <vorlon> doko: python3-defaults> done
[16:24] -queuebot:#ubuntu-release- New binary: zeitgeist [amd64] (focal-proposed/universe) [1.0.2-3ubuntu1] (ubuntu-budgie, ubuntukylin)
[16:31] -queuebot:#ubuntu-release- New: accepted zeitgeist [amd64] (focal-proposed) [1.0.2-3ubuntu1]
[16:46] <vorlon> doko: looks like python3.* are holding up the libffi transition currently
[16:47]  * vorlon kicks some test retries with all-proposed
[16:49] <doko> vorlon: it looks like i386 removals hold up the python3.8 transition
[16:49] <vorlon> doko: ?
[16:49] <vorlon> doko: is that rdma-core, or something else?
[16:50] <doko> ceph
[16:50] <vorlon> right
[16:50] <vorlon> rdma-core+ceph, I've been working on, but there was another revdep after samba removed its dep
[16:50] <vorlon> so I had to get openmpi to migrate, now I'm checking the results right now
[16:50] <doko> I'm not yet looking at autopkg test failures, still doing the transition tracker
[16:51] <vorlon> so ceph is now out of the picture but hwloc still wants rdma-core :P
[17:10] -queuebot:#ubuntu-release- Packageset: Removed libfabric from i386-whitelist in focal
[17:10] -queuebot:#ubuntu-release- Packageset: Removed pep8 from i386-whitelist in focal
[17:11] <vorlon> doko: ceph binaries cleaned up from -proposed, but it looks like the ceph in -proposed also has other installability issues
[17:13] <bdmurray> sil2100: I'm not sure if you saw my ping but I upgraded from X to B with -proposed and u-r-u is good to go.
[17:37] <sil2100> bdmurray: awesome, thank you o/
[18:03] <infinity> xnox: Why are we adding the oem kernel to the desktop ISO, and is this meant to be backed out before release, or...?
[18:04] <xnox> infinity:  it's meant to be backed into focal release.....
[18:04] <xnox> as the second flavour
[18:05] <xnox> there is now a real 5.4 oem flavour
[18:05] <xnox> which is different from generic
[18:05] <infinity> ... why?
[18:06] <doko> make it 5.5
[18:06] <infinity> The whole point of OEM was to exit post-release and carry patches to agressive for stable kernels, but ultimately converge on the next generic.
[18:06] <xnox> infinity:  because there will be certified laptops on release day that will not work with generic, but will work with oem flavour. also it is likely that oem flavour will be 5.5 based at focal release time.
[18:06] <infinity> s/exit/exist/
[18:07] <xnox> infinity:  whilst your statement is true, it will not be so at 20.04.0 release day
[18:07] <infinity> xnox: Okay, and those certified laptop would have their own images/media, no?
[18:07] <xnox> infinity:  or maybe even v5.6 based oem flavour, with v5.4 based generic flavour at 20.04.0 time.
[18:07] <infinity> Complicating our "simple" installer with two kernels we can't adequately explain to the end user is not great.
[18:07] <infinity> And if one if 5.4 and one is 5.5, everyone will pick the 5.5 kernel.
[18:07] <infinity> So we may as well ditch generic.
[18:07] <xnox> infinity:  .... there is UX work, and installer work, to offer certified installer all-in-one......
[18:08] <xnox> which desktop team are working on.
[18:08] <infinity> Sunk cost doesn't imply it was a good idea.
[18:08] <xnox> there will not be an linux-hwe v5.6 based at release time.
[18:09] <xnox> and v5.6-oem will not be as usable as generic one is.
[18:09]  * xnox should finish the draft email to techboard.....
[18:09] <infinity> And literally no "dumb end user" will understand that.
[18:09] <xnox> infinity: non-certified machines will only boot -generic, and will not see any of the certified ux, or even the oem kernel.
[18:09] <infinity> This is why we don't ship both GA and HWE on desktop images today.
[18:10] <infinity> Giving people choice between kernel versions is not "simple" or "intuitive".
[18:10] <xnox> certified ones will boot to the oem kernel by default
[18:10] <infinity> Oh, gross.
[18:10] <xnox> meaning by default there is no choice.
[18:10] <xnox> unless one tries hard
[18:10] <infinity> You're doing this with ACPI model queries in grub?
[18:10] <xnox> (i.e. squint at grub meny on hi-dpi)
[18:10] <xnox> infinity:  yes. vendor, sku, product id.
[18:11] <infinity> re: squinting at grub menu, the non-default kernel shouldn't even be in the menu.
[18:11] <xnox> see smbios module that is in grub2 that can query all the things that are in $ sudo dmidecode => and match verbantim the vendor metapackages modaliases matches by sku
[18:12] <infinity> But okay, if you can hide it so it appears as though there's only one kernel per machine, I'll retract most of my "ew", except for the part where it's still kinda gross. ;)
[18:12] <xnox> infinity: add duplicate linux-restricted-modules and duplicate nvidia stuff too, to that ew to make it "ew supreme" .....
[18:12] <infinity> And I still bet you'll see blogs and forum posts telling people to run out and install linux-oem over linux-generic in one of those "first things to tweak after installing focal!" articles because the version's higher.
[18:14] <xnox> infinity:  i expect that for tigerlake / flagship laptops => yes.
[18:16] <xnox> infinity:  given that one can edit grub menu entry from 'vmlinuz' 'vmlinuz-oem' i think it's ok. Also, I was hoping to allow expert users to opt-into vanilla experience only, despite oem certified machine, because paranoia.
[18:17] <infinity> xnox: Letting OEM opt into GA is fine, letting GA opt into OEM is more sketchy.
[18:17] <xnox> "it's ok" to have like "Advanced Options" grub submenu with vanilla / oem entries.
[18:17] <vorlon> infinity: the reason we don't ship both GA and HWE on desktop today is that we can't guarantee they'll both work with the same squashfs due to userspace entanglement (drm, mesa).  But I've been given a committment going forward that there isn't going to be any more hwe skew for the graphics stack
[18:17] <infinity> xnox: And by "letting", I mean "having a visible menu item".
[18:17] <xnox> infinity:  oh yes, i mean oem opt into ga.
[18:17] <vorlon> like, we do present both ga and hwe kernels on server; the above is the blocking reason from my perspective why we never did the same on desktop
[18:18] <infinity> vorlon: Now more HWE skew for the graphics stack?  In what sense?
[18:18] <infinity> I'm curious about how this commitment was made in good faith. :P
[18:18] <vorlon> infinity: something something precise something libdrm-hwe
[18:19] <infinity> vorlon: But anyhow, I reject your assertion.  We toyed with shipping both, and opted not to because confusing.
[18:19] <vorlon> infinity: if the kernel team is signing up to maintain compatibility, then
[18:19] <xnox> infinity:  so i think apw said that graphics stack will follow the new kernel naming with version indirection, to roll people forward as much as possible; and use metapackages to create whatever is called "stable" vs "edge"(hwe) graphics stack.
[18:20] <vorlon> xnox: that is very different than what I was told
[18:20] <xnox> infinity:  i.e. most things need not to be divergent anymore; and it's only partial amouns of stack that needs to diverge.
[18:20] <vorlon> having any amount of the stack have to diverge means you can't use the same root squashfs for desktop
[18:20] <xnox> vorlon:  well, i am relaying what i understood apw said at the weekly OEM desktop calls
[18:20] <vorlon> xnox: apw and tjaalton need to get on the same page then
[18:21] <infinity> Yeah, the only way to have One True Livefs is for the kernel interfaces to be backported.
[18:21] <xnox> vorlon:  true, but i thought they will package things "normal" "edge" and roll edge->normal on continious basis.
[18:21] <infinity> Which they generally are for OEM, but not for GA.
[18:22] <infinity> Of course, that's enough if .1 has OEM/GA compat and .2 has OEM/HWE compat.
[18:22] <infinity> Which, really, is how it's been for years anyway.
[18:22] <infinity> (The bionic X stack depends on hwe/oem)
[18:22] <infinity> So maybe they're promising no changes because it's already being done right? :P
[18:23] <infinity> (Ignoring GA, of course)
[18:25] <xnox> that was the open question if we will seed ga/hwe/oem at .2 time, or if we stick to hwe/oem only for .2 onwards
[18:25] <xnox> however, we will potentially have equivalent of X stack needs to work on ga/oem at .0 time where ga is v5.4 and oem is v5.6
[18:26] <xnox> which is closer to ga/hwe compat from graphics point of view
[18:39] <ahasenack> hi release team, another /i386 hint bump for your consideration, talloc this time: https://code.launchpad.net/~ahasenack/britney/bump-talloc-i386/+merge/378196
[18:43] <blackboxsw> RAOF:  Is there an ubuntu-sru vanguard available to review the cloud-init -proposed SRU into xenial, bionic and eoan today? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
[18:43] <ubot5> Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,New]
[19:08] <tjaalton> xnox, vorlon: hum, what I recall saying last time in paris was that GA kernel works with HWE gfx stack, as it has already done for a couple of lts releases
[19:08] <tjaalton> so there's no reason why generic/oem kernel can't use the same userspace
[19:09] <tjaalton> if userspace is newer, but kernel is lacking a feature that userspace supports, then it's not getting enabled
[19:09] <tjaalton> if it's the other way around, same thing essentially
[19:10] <xnox> infinity:  ^^^^
[19:10] -queuebot:#ubuntu-release- Packageset: Added nvidia-settings to i386-whitelist in focal
[19:15] <infinity> tjaalton: Okay, so it's not that any effort is being made by us to make the interfaces compatible, it's just that upstream got smarter about bilateral backward compatibility on both sides of said interfaces?
[19:15] <infinity> (Maybe more technically forward compatibility in this case, but...)
[19:17] <tjaalton> infinity: well, new stuff might get added, but I don't recall old stuff removed breaking userspace
[19:18] <infinity> tjaalton: Sure, but there's a difference between "it's been working like this because no one removed old interfaces" and "it's working like this because people committed to not removing old interfaces".
[19:19] <infinity> tjaalton: One is an interesting anecdote, the other is something we can count on. :P
[19:20] <tjaalton> "New functionality in the kernel DRM drivers typically requires a new libdrm,
[19:20] <tjaalton> but a new libdrm will always work with an older kernel.
[19:20] <tjaalton> "
[19:20] <tjaalton> that's from libdrm readme
[19:21] <tjaalton> so I think we can count on that ;)
[19:21] <tjaalton> we wouldn't be the only ones to yell if something broke
[19:27] -queuebot:#ubuntu-release- Unapproved: pandas (eoan-proposed/universe) [0.23.3+dfsg-4ubuntu1 => 0.23.3+dfsg-4ubuntu1.1] (no packageset)
[20:11] <vorlon> ahasenack: bumped talloc to talloc/all/i386, because python
[20:12] <ahasenack> vorlon: great, thanks
[20:16] <Eickmeyer[m]> xnox: Question: Is the lowlatency flavor of the kernel going to be affected in any way?
[20:22] <infinity> Eickmeyer[m]: Don't see why it would be.
[20:22] <infinity> Eickmeyer[m]: This is just about which kernel(s) we inclue on the Ubuntu desktop image, nothing else really changes for anyone.
[20:22] <Eickmeyer[m]> infinity: Perfect. Thanks.
[20:34] <vorlon> infinity: are you driving https://wiki.ubuntu.com/EndOfLifeProcess for disco? I just told tdaitx not to add new disco blacklist entries for autopkgtest because it's EOL, then I notice we haven't done the rest of the cleanup yet
[20:35] <infinity> vorlon: Yeah, I'm doing some archive tidying right now and then whacking it.
[20:35] <vorlon> ok
[21:15] <vorlon> juliank, Laney: fyi I'm taking care of the disco EOL autopkgtest task
[21:33] <bdmurray> I just happened to notice that disco is still listed as supported.
[21:33] <bdmurray> In LP
[21:33] <xnox> Eickmeyer[m]:  affected... in respect to what? lowlatency today is a subflavour enabled on certain kernels. I.e. there is generic and generic-lowlatency
[21:33] <xnox> just like it was before, and is now.
[21:38] -queuebot:#ubuntu-release- Unapproved: walinuxagent (eoan-proposed/main) [2.2.40-0ubuntu1 => 2.2.45-0ubuntu1~19.10.1] (core, ubuntu-cloud)
[21:41] <Eickmeyer[m]> xnox: Thanks for the clarification.
[21:43] -queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.40-0ubuntu1~18.04.1 => 2.2.45-0ubuntu1~18.04.1] (ubuntu-cloud)
[21:52] <juliank> vorlon: ack
[21:57] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.40-0ubuntu1~16.04.1 => 2.2.45-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
[22:36] <xnox> lowlatency is the default on some flavour, but can't remember which
[22:38] <wxl> probably studio
[22:38] <wxl> which would be relevant given that's home for Eickmeyer[m] :)
[22:41] <Eickmeyer[m]> xnox: It's seeded by Ubuntu Studio.
[22:42] <xnox> yeah, that one installs lowlatency, and only uses lowlatency, and nothing else.
[22:42] <xnox> no changes there.
[22:50] <Eickmeyer[m]> xnox: Not sure if you know, but I lead Ubuntu Studio, so anything that affects Studio greatly interests me. Hence my question.