-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:26
tjaaltonsil2100: hi, these ^ fix a regression with opencl08:27
-queuebot:#ubuntu-release- New binary: pynag [amd64] (focal-proposed/universe) [1.1.2+dfsg-1ubuntu1] (no packageset)08:39
sil2100tjaalton: oh no, ok! Looking09:11
sil2100tjaalton: did you push this revert to focal as well?09:15
tjaaltonsil2100: it'll sync from debian09:16
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (eoan-proposed) [0.2.0+git20190827-1ubuntu0.19.10.1]09:19
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1ubuntu0.18.04.1]09:20
=== cpaelzer__ is now known as cpaelzer
=== andrewc is now known as Guest14485
=== enyc_ is now known as enyc
juliankWe should force-badtest aptdaemon/arm64/all I think10:26
juliankIt did pass _once_10:27
juliankonce in eoan, once in focal so far10:27
juliankthere's a race condition somewhere that's been there forever10:27
juliankThen we can have aptdaemon migrate to release10:28
juliankwhich will partially unblock python-apt 1.9.5 I just pushed to proposed10:28
xnoxsil2100:  casper is verified in bionic, can it please be released early such that i can upload it again?11:07
sil2100xnox: yeah, on it! In the meantime, just upload it to the queue and I'll pick it up in a moment11:12
-queuebot:#ubuntu-release- Unapproved: casper (bionic-proposed/main) [1.394.2 => 1.394.3] (desktop-core, ubuntu-server)11:13
-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:15
-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:18
-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:19
xnoxapw:  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:22
apwxnox, ta11:26
-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:30
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394.3]11:37
ahasenackhi release team, if someone could please merge https://code.launchpad.net/~ahasenack/britney/samba-i386-bump/+merge/37816312:52
-queuebot:#ubuntu-release- New binary: neo [amd64] (focal-proposed/universe) [0.7.2-2] (no packageset)13:06
tumbleweedahasenack: let's move that to a * then13:08
ahasenackI tend to be conservative with *, and i386 issues13:08
tumbleweedif we don't expect it to ever pass, it should be a *13:08
ahasenackat the same time, it seems to be under a section called "needs investigation", and it's possible I missed something13:09
tumbleweedhalf the other packages in the archive are13:09
tumbleweedit sounds like you investigated :P13: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 * already13:09
ahasenackthat's all13:10
ahasenacktumbleweed: 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
tumbleweedI can merge that13:10
ahasenackdo you want me to change it to *?13:12
tumbleweednaah, I can post-merge13:12
sforsheedoko: yes they are13:12
ahasenacktumbleweed: thanks!13:12
dokosforshee: I'm asking "what are they?", and you reply with "yes they are"?13:14
sforsheedoko: 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 issue13:17
dokosforshee: yes, just wondering that I see these changelog entries now a lot13:18
sforsheedoko: 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 those13:22
dokovorlon: please could you add a python3-defaults hints like the one we had for python-defaults?13:34
ahasenackhi release team, another i386 bump for your consideration please: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/37816713:46
ahasenackops, wrong merge target13:47
apwahasenack, not looking any different, showing 8k lines of change13:55
ahasenackthe url probably changed13:55
ahasenacklet me paste13:55
ahasenackapw: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/37816813:55
ahasenackthanks apw13:58
xnoxapw:  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.html14:07
xnoxonce that publishes, we can re-add livecd-rootfs change to install oem kernel flavour14:10
apwxnox, wiggled14:43
xnoxapw:  Ok google, play "Wiggle" feat. Snoop Dogg by Jason Derulo14:47
vorlondoko: python3-defaults> done15:40
-queuebot:#ubuntu-release- New binary: zeitgeist [amd64] (focal-proposed/universe) [1.0.2-3ubuntu1] (ubuntu-budgie, ubuntukylin)16:24
-queuebot:#ubuntu-release- New: accepted zeitgeist [amd64] (focal-proposed) [1.0.2-3ubuntu1]16:31
vorlondoko: looks like python3.* are holding up the libffi transition currently16:46
* vorlon kicks some test retries with all-proposed16:47
dokovorlon: it looks like i386 removals hold up the python3.8 transition16:49
vorlondoko: ?16:49
vorlondoko: is that rdma-core, or something else?16:49
vorlonrdma-core+ceph, I've been working on, but there was another revdep after samba removed its dep16:50
vorlonso I had to get openmpi to migrate, now I'm checking the results right now16:50
dokoI'm not yet looking at autopkg test failures, still doing the transition tracker16:50
vorlonso ceph is now out of the picture but hwloc still wants rdma-core :P16:51
-queuebot:#ubuntu-release- Packageset: Removed libfabric from i386-whitelist in focal17:10
-queuebot:#ubuntu-release- Packageset: Removed pep8 from i386-whitelist in focal17:10
vorlondoko: ceph binaries cleaned up from -proposed, but it looks like the ceph in -proposed also has other installability issues17:11
bdmurraysil2100: 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:13
sil2100bdmurray: awesome, thank you o/17:37
infinityxnox: Why are we adding the oem kernel to the desktop ISO, and is this meant to be backed out before release, or...?18:03
xnoxinfinity:  it's meant to be backed into focal release.....18:04
xnoxas the second flavour18:04
xnoxthere is now a real 5.4 oem flavour18:05
xnoxwhich is different from generic18:05
infinity... why?18:05
dokomake it 5.518:06
infinityThe 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
xnoxinfinity:  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
xnoxinfinity:  whilst your statement is true, it will not be so at 20.04.0 release day18:07
infinityxnox: Okay, and those certified laptop would have their own images/media, no?18:07
xnoxinfinity:  or maybe even v5.6 based oem flavour, with v5.4 based generic flavour at 20.04.0 time.18:07
infinityComplicating our "simple" installer with two kernels we can't adequately explain to the end user is not great.18:07
infinityAnd if one if 5.4 and one is 5.5, everyone will pick the 5.5 kernel.18:07
infinitySo we may as well ditch generic.18:07
xnoxinfinity:  .... there is UX work, and installer work, to offer certified installer all-in-one......18:07
xnoxwhich desktop team are working on.18:08
infinitySunk cost doesn't imply it was a good idea.18:08
xnoxthere will not be an linux-hwe v5.6 based at release time.18:08
xnoxand v5.6-oem will not be as usable as generic one is.18:09
* xnox should finish the draft email to techboard.....18:09
infinityAnd literally no "dumb end user" will understand that.18:09
xnoxinfinity: non-certified machines will only boot -generic, and will not see any of the certified ux, or even the oem kernel.18:09
infinityThis is why we don't ship both GA and HWE on desktop images today.18:09
infinityGiving people choice between kernel versions is not "simple" or "intuitive".18:10
xnoxcertified ones will boot to the oem kernel by default18:10
infinityOh, gross.18:10
xnoxmeaning by default there is no choice.18:10
xnoxunless one tries hard18:10
infinityYou're doing this with ACPI model queries in grub?18:10
xnox(i.e. squint at grub meny on hi-dpi)18:10
xnoxinfinity:  yes. vendor, sku, product id.18:10
infinityre: squinting at grub menu, the non-default kernel shouldn't even be in the menu.18:11
xnoxsee 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 sku18:11
infinityBut 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
xnoxinfinity: add duplicate linux-restricted-modules and duplicate nvidia stuff too, to that ew to make it "ew supreme" .....18:12
infinityAnd 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:12
xnoxinfinity:  i expect that for tigerlake / flagship laptops => yes.18:14
xnoxinfinity:  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:16
infinityxnox: 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
vorloninfinity: 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 stack18:17
infinityxnox: And by "letting", I mean "having a visible menu item".18:17
xnoxinfinity:  oh yes, i mean oem opt into ga.18:17
vorlonlike, 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 desktop18:17
infinityvorlon: Now more HWE skew for the graphics stack?  In what sense?18:18
infinityI'm curious about how this commitment was made in good faith. :P18:18
vorloninfinity: something something precise something libdrm-hwe18:18
infinityvorlon: But anyhow, I reject your assertion.  We toyed with shipping both, and opted not to because confusing.18:19
vorloninfinity: if the kernel team is signing up to maintain compatibility, then18:19
xnoxinfinity:  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:19
vorlonxnox: that is very different than what I was told18:20
xnoxinfinity:  i.e. most things need not to be divergent anymore; and it's only partial amouns of stack that needs to diverge.18:20
vorlonhaving any amount of the stack have to diverge means you can't use the same root squashfs for desktop18:20
xnoxvorlon:  well, i am relaying what i understood apw said at the weekly OEM desktop calls18:20
vorlonxnox: apw and tjaalton need to get on the same page then18:20
infinityYeah, the only way to have One True Livefs is for the kernel interfaces to be backported.18:21
xnoxvorlon:  true, but i thought they will package things "normal" "edge" and roll edge->normal on continious basis.18:21
infinityWhich they generally are for OEM, but not for GA.18:21
infinityOf course, that's enough if .1 has OEM/GA compat and .2 has OEM/HWE compat.18:22
infinityWhich, really, is how it's been for years anyway.18:22
infinity(The bionic X stack depends on hwe/oem)18:22
infinitySo maybe they're promising no changes because it's already being done right? :P18:22
infinity(Ignoring GA, of course)18:23
xnoxthat was the open question if we will seed ga/hwe/oem at .2 time, or if we stick to hwe/oem only for .2 onwards18:25
xnoxhowever, 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.618:25
xnoxwhich is closer to ga/hwe compat from graphics point of view18:26
ahasenackhi release team, another /i386 hint bump for your consideration, talloc this time: https://code.launchpad.net/~ahasenack/britney/bump-talloc-i386/+merge/37819618:39
blackboxswRAOF:  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/185972518:43
ubot5Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,New]18:43
tjaaltonxnox, 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 releases19:08
tjaaltonso there's no reason why generic/oem kernel can't use the same userspace19:08
tjaaltonif userspace is newer, but kernel is lacking a feature that userspace supports, then it's not getting enabled19:09
tjaaltonif it's the other way around, same thing essentially19:09
xnoxinfinity:  ^^^^19:10
-queuebot:#ubuntu-release- Packageset: Added nvidia-settings to i386-whitelist in focal19:10
infinitytjaalton: 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:15
tjaaltoninfinity: well, new stuff might get added, but I don't recall old stuff removed breaking userspace19:17
infinitytjaalton: 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:18
infinitytjaalton: One is an interesting anecdote, the other is something we can count on. :P19:19
tjaalton"New functionality in the kernel DRM drivers typically requires a new libdrm,19:20
tjaaltonbut a new libdrm will always work with an older kernel.19:20
tjaaltonthat's from libdrm readme19:20
tjaaltonso I think we can count on that ;)19:21
tjaaltonwe wouldn't be the only ones to yell if something broke19:21
-queuebot:#ubuntu-release- Unapproved: pandas (eoan-proposed/universe) [0.23.3+dfsg-4ubuntu1 => 0.23.3+dfsg-4ubuntu1.1] (no packageset)19:27
vorlonahasenack: bumped talloc to talloc/all/i386, because python20:11
ahasenackvorlon: great, thanks20:12
Eickmeyer[m]xnox: Question: Is the lowlatency flavor of the kernel going to be affected in any way?20:16
infinityEickmeyer[m]: Don't see why it would be.20:22
infinityEickmeyer[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:22
vorloninfinity: 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 yet20:34
infinityvorlon: Yeah, I'm doing some archive tidying right now and then whacking it.20:35
vorlonjuliank, Laney: fyi I'm taking care of the disco EOL autopkgtest task21:15
bdmurrayI just happened to notice that disco is still listed as supported.21:33
bdmurrayIn LP21:33
xnoxEickmeyer[m]:  affected... in respect to what? lowlatency today is a subflavour enabled on certain kernels. I.e. there is generic and generic-lowlatency21:33
xnoxjust like it was before, and is now.21:33
-queuebot:#ubuntu-release- Unapproved: walinuxagent (eoan-proposed/main) [2.2.40-0ubuntu1 => 2.2.45-0ubuntu1~19.10.1] (core, ubuntu-cloud)21:38
Eickmeyer[m]xnox: Thanks for the clarification.21:41
-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:43
juliankvorlon: ack21:52
-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)21:57

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