[08:26] -queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20190827-1~ubuntu18.04.1 => 0.2.0+git20190827-1ubuntu<IP_ADDRESS>] (no packageset)
[08:26] -queuebot:#ubuntu-release- Unapproved: libclc (eoan-proposed/universe) [0.2.0+git20190827-1 => 0.2.0+git20190827-1ubuntu<IP_ADDRESS>] (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-1ubuntu<IP_ADDRESS>]
[09:20] -queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1ubuntu<IP_ADDRESS>]
[09:26] <tjaalton> thanks1
[09:26] <tjaalton> !
[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
[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.


[16:00] <fginther> o/
[16:00] <sil2100> o/
[16:00] <philroche> o/
[16:01] <Odd_Bloke>  /o /o /o
[16:01]  * slangasek waves
[16:01]  * infinity grunts
[16:01]  * rcj naps
[16:01] <slangasek> #startmeeting
[16:01] <meetingology> Meeting started Thu Feb 22 16:01:49 2018 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <slangasek> [TOPIC] Lightning round
[16:02] <slangasek> $ echo $(shuf -e slangasek bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson rcj philroche Odd_Bloke tribaal fginther juliank)
[16:02] <slangasek> doko xnox slangasek mwhudson juliank infinity rcj philroche fginther tribaal bdmurray rbalint cyphermox sil2100 Odd_Bloke tdaitx
[16:02] <rbalint> o/
[16:02] <slangasek> doko is off
[16:02] <slangasek> xnox:
[16:02] <xnox> bah
[16:02] <xnox> that's not fair!
[16:03] <xnox> * systemd SRUs are in the unapproved queue
[16:03] <xnox> * hw-detect/s390-tools srus are in proposed
[16:03] <xnox> * systemd &cryptsetup in bionic is almost ready to migrate; but open-iscsi regression (hint proposed; and fixing cloud images at the same time)
[16:04] <xnox> * todo - livecd-rootfs stuff for ubiquities & partman-auto for the point release
[16:04] <xnox> (done)
[16:05] <slangasek>  * no meeting last week due to conflict with company internal meeting
[16:05] <slangasek>  * various vacation days, holidays scattered throughout
[16:05] <slangasek>  * far too much effort put into getting packages unstuck from -proposed
[16:05] <slangasek>  * getting everything in order for upcoming retpoline rebuild in bionic
[16:05] <slangasek>  * working on netplan content
[16:05] <slangasek> (done)
[16:05] <slangasek> juliank:
[16:05]  * juliank is afraid it's going to be a bit long
[16:05] <juliank> * made grub show shorter version numbers (bug 1723434)
[16:05] <juliank> * SRUed ubuntu-release-upgrader fix to artful for bug 1744722
[16:05] <juliank> * enabled -updates for the devel release on ddebs.ubuntu.com
[16:05] <juliank> * provided hints for the util-linux SRUs in xenial and artful
[16:05] <juliank> * fixed console-setup to setup non-us keyboard layouts in initramfs again (bug 1719612)
[16:05] <juliank> * fixed apt cdrom support (bug 1746807)
[16:05] <juliank> * made apt check that the release file's date is not in the future (https://salsa.debian.org/apt-team/apt/merge_requests/3; not yet uploaded)
[16:05] <juliank> * uploaded SRU for bug 1732865
[16:05] <juliank> * provided a fix for apport's bug 1746874
[16:05] <juliank> * merge proposal: add per-teams lists to qa.ubuntuwire.org ftbfs page (https://code.launchpad.net/~juliank/lp-ftbfs-report/teams/+merge/338016)
[16:05] <juliank> WiP:
[16:05] <juliank> * trying to make apport accept named arguments (bug 1732962) - might be impossible without some issues
[16:05] <juliank> * teach ubuntu-bug about snaps (bug 1729491, PoC)
[16:05] <juliank> * started investigating bug 1726068
[16:05] <juliank> (done)
[16:05] <infinity> Oh no.  Is Julian the new Evan?
[16:06] <xnox> hahahha
[16:06] <xnox> infinity, it's more like barry though, just a paste of a lot of bug #, which spew out everything.
[16:06] <infinity> Yeah, fair.  Evan wrote novels.
[16:06] <infinity>  * glibc 2.27 uploaded to staging PPA:
[16:06] <infinity>    - will binary copy after all arches build and test a bit locally.
[16:06] <infinity>    - cross-builds still broken; will revisit after native builds land.
[16:06] <infinity>  * Some random archive admin work.
[16:06] <infinity>  * Catching up on the state of the xenial point release.
[16:06] <infinity>  * Fixed an upgrade bug in e2fsprogs.
[16:06] <infinity>  * Looking into powerpc-utils upstream changes for Debian and Ubuntu.
[16:06] <infinity>  * Trying to decide if I replace the clutch in my car or buy a new car.
[16:06] <infinity> (done)
[16:06] <rcj> rcj:
[16:06] <rcj> * Vacation days
[16:06] <rcj> * Sick days :(
[16:06] <rcj> * Code reviews, but not nearly enough
[16:06] <rcj> (done)
[16:07] <philroche> * Cloud image build system updates
[16:07] <philroche> * Helping with publication of cloud images with Retpoline patches
[16:07] <Odd_Bloke> rcj was big in Japan last week.
[16:07] <philroche> * Updated ubuntu-watch-packages to include package publication date
[16:07] <philroche> * Created and helped with release of image-status snap https://snapcraft.io/image-status
[16:07] <philroche> (done)
[16:07] <fginther> fginther:
[16:07] <fginther> * Revived the lp-to-trello syncing
[16:07] <fginther> * Provided test images for walinuxagent 2.2.20
[16:07] <fginther> * Created notes from all our various TEMP jobs before they are purged
[16:07] <fginther> * MP to clean obsolete jobs in dev jenkins deployments
[16:07] <fginther> * Assist with debuging issues around Oracle Classic API usage
[16:08] <fginther> * Reviewed changelog MPs
[16:08] <fginther> * Reviewed MPs for automated release promotion for a partner cloud
[16:08] <fginther> * MP to add jenkaas release publication for a partner cloud (almost ready)
[16:08] <fginther> (done)
[16:08] <tribaal> * Vanguard duties
[16:08] <tribaal> * Driving the "CVE" image release process for retpoline patches.
[16:08] <tribaal> * Code reviews (not enough)
[16:08] <tribaal> (done)
[16:08] <xnox> infinity, you are in north america? and you have a clutch in your car? you drive stick? i'm confused.
[16:08] <xnox> infinity, you drive stick?
[16:08] <infinity> xnox: Yes...
[16:08] <bdmurray> I wrote one for last week and didn't get to say it then so get ready for two weeks.
[16:08] <bdmurray> investigation into mojo spec CI failures (missing repo phase, wrong secrets, squid issue)
[16:08]  * Odd_Bloke has visions of infinity on a broomstick.
[16:08] <bdmurray> Fixed Error Tracker mojo spec so repo phase isn't required anymore
[16:08] <bdmurray> made a pretty graph of cloud image sizes again
[16:09] <bdmurray> investigation into dnssec-trigger, pump, openvpn, pppconfig for LP: 1713803
[16:09] <bdmurray> investigation into LP: #1642812
[16:09] <bdmurray> tested of balint's u-r-u and update-manager changes for partial upgrades
[16:09] <bdmurray> looked at how apport generates JournalErrors.txt & discussed with slangasek
[16:09] <bdmurray> reported e2fsprogs upgrade bug LP: #1749036
[16:09] <bdmurray> uploaded apport to bionic with JournalErrors change re warnings LP: #1738581
[16:09] <bdmurray> fixed apport-collect/apport-bug issue with python vs python3 LP: #1748621
[16:09] <bdmurray> modified daisy to only retry failures 2x instead of 3x and reduce logging
[16:09] <bdmurray> submitted RT regarding update of daisy in staging Error Tracker
[16:09] <bdmurray> modified retracer sources to have bionic-updates enabled for ddebs
[16:09] <bdmurray> tested update of daisy in staging Error Tracker (good)
[16:09] <bdmurray> submitted RT regarding of update of daisy in production error Tracker
[16:09] <bdmurray> tested bionic's apport-retrace w/ python3-lplib (good)
[16:09] <bdmurray> tested / reviewed sil2100's KPI regarding team assigned bugs
[16:09] <bdmurray> reviewed / tested juliank's apport lock timeout change
[16:09] <bdmurray> made ubuntu-release-upgrader depend on sensible-utils (LP: #1724224)
[16:09] <bdmurray> moved graphs from pvt dashboard to public one
[16:09] <bdmurray> investigation into freedombox-setup for LP: #1713803
[16:09] <bdmurray> bug triage of apport-collect 16.04 bug LP: #1749222
[16:09] <bdmurray> improved code for creating changelogs for partner images
[16:09] <bdmurray> tested retracing of Ubunty Kylin crash reports (good)
[16:09] <bdmurray> modified Launchpad retracers to retrace Kylin 18.04 crash reports
[16:09] <bdmurray> merge rbalint's britney hints for artful (s390x special cases)
[16:09] <bdmurray> created apport-test-crash for Ubuntu Kylin
[16:10] <bdmurray> updated ubuntu-release-upgrader to get latest mirrors for 16.04.4(?)
[16:10] <bdmurray> modified daisy to accept and retrace Ubuntu Kylin 18.04 crashes
[16:10] <bdmurray> modified daisy & errors charms to stop logging to stdout
[16:10] <bdmurray> submitted RT regarding update of daisy on staging Error Tracker
[16:10] <bdmurray> investigation into odd retracing failure with LP: #1750842
[16:10] <bdmurray> done
[16:10] <bdmurray> rbalint:
[16:10] <rbalint> (short week)
[16:10] <rbalint> * fixed package builds with Ruby 2.5 in Ubuntu, changes are upstreamed
[16:10] <rbalint>   - fixed ruby-redcarpet ftbfs (Debian's #888168)
[16:10] <rbalint>   - fixed ruby-rmagick ftbfs
[16:10] <rbalint>   - fixed ruby-rack-mount to not use ruby-multimap
[16:10] <rbalint>   - asked for ruby-multimap's removal LP: #1750740
[16:10] <rbalint> * auto-remove unused kernels in unattended-upgrades and several further u-u fixes
[16:10] <rbalint> (done)
[16:11] <rbalint> the lates u-u fixes are in the repo, not in Ubuntu yet, i'm still testing some additional ones
[16:11] <cyphermox> MIRs:
[16:11] <cyphermox>  - pyrfc3339, libglvnd, py-macaroon-bakery, mtd-utils, libfastjson, pysmi, uvloop
[16:11] <cyphermox> shim-review:
[16:11] <cyphermox>  - Review IGEL's submission for shim v14
[16:11] <cyphermox> netplan:
[16:11] <cyphermox>  - systemd Shutdown= patch submitted upstream
[16:11] <cyphermox>  - multiple bugfixes
[16:11] <cyphermox>  - received contributions from dja for bugfixes, new features
[16:11] <cyphermox>  - [HIGHLIGHT] netplan.io website is up
[16:11] <cyphermox>  - netplan.io bug fixes
[16:11] <cyphermox>  - routing code overhaul
[16:11] <cyphermox>  - major refactoring of netplan commands
[16:11] <cyphermox> proposed-migration:
[16:11] <cyphermox>  - attempting to write up a wrapper script for migration next steps
[16:11] <cyphermox>    - https://code.launchpad.net/~cyphermox/ubuntu-archive-tools/what-next/
[16:12] <cyphermox> bionic:
[16:12] <cyphermox>  - ndisc6 tiny Depends fixes
[16:12] <cyphermox>  - re-testing shim/grub chainloading in MAAS for shim protocols workaround (bug LP: #1711203)
[16:12] <cyphermox> (done)
[16:12] <sil2100> - 16.04.4 work (changesets, uploads, tweaks, rebuilds, coordination, stuff)
[16:12] <sil2100> - SRU reviews and releases
[16:12] <sil2100> - Preparing and releasing a revert of walinuxagent to 2.2.20
[16:12] <sil2100> - Kernel SRU reviews and releases (respins yaay)
[16:12] <sil2100> - Archive-admin work
[16:12] <sil2100>   * NEW review of calamares-settings-ubuntu
[16:12] <sil2100>   * Handling some main inclusions
[16:12] <sil2100> - Uploading libservicelog SRU with requested cherry-picked fixes
[16:12] <sil2100> - Setting up the canonical-foundations assigned bug KPI graph
[16:12] <sil2100> (done)
[16:12] <Odd_Bloke> * Performed SRU verification for Vagrant changes (https://bugs.launchpad.net/bugs/1747426)
[16:12] <Odd_Bloke> * Working on a substantial refactor of internal image publication code to support different image bases
[16:13] <Odd_Bloke> * Worked on moving GCE image publication to our new publication infrastructure
[16:13] <Odd_Bloke> * Initial engagement with a new partner for image delivery
[16:13] <Odd_Bloke> * Investigating issues with EC2 images in cn-north-1
[16:13] <Odd_Bloke> (done)
[16:13] <Odd_Bloke> tdaitx:
[16:13] <tdaitx_> * OpenJDK 9/10 as default JDK
[16:13] <tdaitx_>   - Testing maven reverse dependencies and reverse build dependencies
[16:13] <tdaitx_>   - Fixing LibreOffice build failures
[16:13] <tdaitx_> * Initial setup to get LibreOffice and Tomcat running with OpenJDK 9
[16:13] <tdaitx_> (done)
[16:15] <slangasek> sil2100: everything looking good for the revised .4 schedule?
[16:16] <sil2100> slangasek: yes, so far all is good
[16:16] <slangasek> cool
[16:16] <bdmurray> sil2100: Have you reviewed the ubuntu-release-upgrader upload?
[16:16] <sil2100> I will be spinning first RC candidates later today or (more probably) tomorrow
[16:17] <sil2100> bdmurray: no, but I can
[16:17] <infinity> sil2100: We should talk before you do that.
[16:17] <bdmurray> that which?
[16:17] <slangasek> sil2100: any help needed flushing the SRU queue into -updates?
[16:19] <sil2100> slangasek: no, I think we'll manage, we're looking through -proposed with jibel to see which packages we feel confident in actually flushing
[16:19] <slangasek> ok
[16:19] <slangasek> any other questions on status?
[16:19] <sil2100> infinity: ok! You mean, talk before spinning the images, right? :)
[16:19] <infinity> sil2100: Possibly, yes.
[16:20] <bdmurray> juliank: Do you want me to look at the apport test failures for the multiple core issues?
[16:20] <juliank> bdmurray: I thought it was one failing test, and you were going to delete it; was I wrong?
[16:21] <bdmurray> juliank: I believe there were a couple but that was last week so ?
[16:21] <juliank> oh, ok.
[16:21] <juliank> I don't mind, I'm not going to look at them today
[16:22] <juliank> at least
[16:22] <bdmurray> Okay, if I get to it I'll let you know.
[16:23] <slangasek> [TOPIC] Bugs
[16:23] <slangasek> [LINK] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html#foundations-bugs
[16:23] <bdmurray> bug 1385524 is uh interesting
[16:23] <bdmurray> Its been broken forever
[16:23] <slangasek> huh, incoming queue is looking quite large
[16:24] <slangasek> update-manager-text?  do-release-upgrade's ugly cousin?
[16:24] <bdmurray> So I wonder if we should just drop it.
[16:24] <slangasek> I agree
[16:25] <bdmurray> So target and card it?
[16:26] <slangasek> yes
[16:26] <slangasek> (inprogress)
[16:26] <slangasek> (done)
[16:26] <bdmurray> I ran into bug 1749036 during a partial upgrade
[16:27] <xnox> didn't infinity fix it?
[16:27] <slangasek> sounds like it; infinity to close out the bug
[16:28] <bdmurray> bug 1747711 seemed like something we might want to keep an eye on
[16:31] <slangasek> bdmurray: it doesn't seem important to me; am I missing something?
[16:31] <bdmurray> slangasek: No, probably not.
[16:32] <slangasek> "Consequently, only non-PIE executables can be opened in graphical file managers such as nautilus" - I don't think that's a common method for opening programs on a modern desktop
[16:32] <slangasek> declining then
[16:32] <bdmurray> Also when I tested with nautilus I didn't see that behavior.
[16:33] <slangasek> bdmurray: should LP: #1749199 have an assignee?
[16:33] <xnox> i've hit that bug
[16:34] <bdmurray> then you sound like a good candidate for fixing it!
[16:37] <slangasek> ok, I think we should take this for bionic
[16:38] <slangasek> interestingly I don't have those here
[16:38] <slangasek> oh because I purged
[16:40] <slangasek> LP: #1512322
[16:40] <slangasek> more low-numbered bugs
[16:41] <slangasek> trigger cycle
[16:41] <slangasek> taking
[16:44] <bdmurray> it looks like rbalint is working on bug 1698159 already
[16:45] <rbalint> yep
[16:45] <bdmurray> slangasek: so should we target that then?
[16:45] <rbalint> need the apt-side fix however, too
[16:45] <rbalint> imo the apt-side part is more important
[16:46] <bdmurray> is that something juliank is aware of?
[16:46] <rbalint> the u-u part comes as part of kernel autoremoval - and protecting running kernel
[16:46] <juliank> I vaguely recall something about that
[16:47] <slangasek> agreed that we should take it
[16:47] <bdmurray> okay
[16:47] <slangasek> the patterns in the generated /etc/apt/apt.conf.d/01autoremove-kernels just need to be updated to include linux-cloud-tools-foo
[16:47] <juliank> We can fix that in the next apt upload, that should just be some line added in the conf file with the proper regex :-)
[16:47] <slangasek> /etc/kernel/postinst.d/apt-auto-removal
[16:48] <juliank> No, /etc/apt/apt.conf.d/01autoremove
[16:48] <juliank> needs linux-cloud-.* I guess as VersionedKernelPackages
[16:48] <juliank> Well, I guess both works
[16:49] <juliank> We use that for headders, and linux tools, too, though, so it's probably the right location
[16:50] <slangasek> juliank: ah, you're right, /etc/apt/apt.conf.d/01autoremove, I was vague on the specifics of where the code lived
[16:51] <slangasek> I think that's enough within bugs, shall we move on?
[16:51] <bdmurray> sure
[16:51] <rbalint> slangasek: i have a candidate
[16:51] <rbalint> LP: #1737441
[16:51] <rbalint> i'm hitting it frequently now in u-u testing
[16:52] <rbalint> like 2 out of 3 runs when upgrading a lot of packages
[16:54] <slangasek> ok, taking
[16:55] <slangasek> [TOPIC] AOB
[16:55] <slangasek> anything else?
[16:55] <bdmurray> I'll likely be out tomorrow
[16:56] <slangasek> #endmeeting
[16:56] <meetingology> Meeting ended Thu Feb 22 16:56:59 2018 UTC.
[16:56] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2018/ubuntu-meeting.2018-02-22-16.01.moin.txt
[16:57] <slangasek> thanks, all!
[16:58] <sil2100> Thanks o/
[19:41] <cyphermox> ear
[19:42] <Odd_Bloke> nose


[00:44] <popey> hmmm
[00:44]  * popey taps the microphone
[00:48] <popey> hi Yellow_Stevej
[00:48] <Yellow_Stevej> hello
[00:49] <Yellow_Stevej> well that seems to work!
[11:08] <freeflying> @schedule shanghai
[13:01] <persia> #startmeeting
[13:01] <MootBot> Meeting started at 07:00. The chair is persia.
[13:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:01] <persia> [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2008/20080918
[13:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2008/20080918
[13:01] <persia> Welcome to the Mobile Team meeting.  The agenday is as listed at the above URL.
[13:01] <persia> First item: Roll Call.  Who's here?
[13:03] <persia> OK.  Moving on then.
[13:03] <persia> [TOPIC] Action Items
[13:03] <MootBot> New Topic:  Action Items
[13:03] <StevenK> What was that bit?
[13:03] <persia> Last bit was Roll Call.  Asking who was here.
[13:04] <cgregan> cgregan
[13:04] <lool> Hi
[13:04] <persia> So, first up: ogra: status of Q1 touchscreen support
[13:05] <lool> ogra is logging in
 I'll do it next week
[13:05] <persia> OK.
[13:05] <persia> Next persia to register spec for installer
[13:05] <persia> See https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-mid-live-installer
[13:06] <persia> Next: choice of mail client: modest vs. thunderbird.
[13:06]  * lool made no progress whatsover on modest
[13:07] <lool> At this point we should just keep thunderbird and revisit modest next cycle
[13:07] <lool> It's too much WIP tright now
[13:07] <persia> OK.  Shall we just agree on thunderbird for intrepid then, and look at modest for next cycle?
[13:07] <persia> Any objections?
[13:07] <cgregan> +1
[13:08] <persia> [AGREED] Ubuntu MID to use Thunderbird as the default mail client for intrepid
[13:08] <MootBot> AGREED received:  Ubuntu MID to use Thunderbird as the default mail client for intrepid
[13:08] <persia> [TOPIC] Current Items
[13:08] <MootBot> New Topic:  Current Items
[13:08] <persia> There's a few things listed here.
[13:08] <persia> amitk: anything you have to say about kernel issues?
[13:09] <persia> Hmm.  I think perhaps he's not here.
[13:09] <persia> Next: cgregan: Anything on the QA front?
[13:10] <cgregan> Just case work
[13:10] <cgregan> continuing
[13:10] <persia> Are you blocked by anything?
[13:10] <cgregan> need a spec for installer
[13:10] <cgregan> :-)
[13:10] <lool> haha :)
[13:11] <persia> cgregan: How much detail do you need?
[13:11] <cgregan> persia: Similar to StevenK's
[13:11] <persia> OK.
[13:12] <cgregan> Also, I might be mostly offline next week
[13:12] <persia> [ACTION] persia to flesh out ubuntu-mid-live-installer
[13:12] <MootBot> ACTION received:  persia to flesh out ubuntu-mid-live-installer
[13:12] <cgregan> potentially getting sent out your way persia
[13:12]  * ogra waves
[13:13] <persia> OK.  Next up: StevenK (but without any specific items for discussion: very confusing agenda)
[13:13] <StevenK> Oh, I'm on the agenda?
[13:14] <persia> StevenK: Yep.  You're listed under "Current Items".  Do you have any "Current Items"?
[13:14] <StevenK> What about me? :-)
[13:14] <Hobbsee> i'm sure people can suggest what should be on the agenda w.r.t. StevenK
[13:14] <persia> heh
[13:14] <Hobbsee> maybe that he has to fix all the bugs by tomorrow, or something.
[13:14] <ogra> show off your screenshots :)
[13:14] <ogra> !!
[13:14] <StevenK> I did
[13:15]  * lool didn't get them
[13:15]  * persia points at https://wiki.ubuntu.com/MobileTeam/Meeting/2008/20080918 again in case people didn't see the LINK earler.
[13:15] <StevenK> I reimplemented a new launcher in one day, replacing mobile-basic-flash
[13:15] <StevenK> [LINK] http://people.ubuntu.com/~stevenk/IMG_2095.JPG
[13:15] <MootBot> LINK received:  http://people.ubuntu.com/~stevenk/IMG_2095.JPG
[13:15] <persia> Woo Hoo!
[13:15] <lool> So you got python working?
[13:15] <StevenK> [LINK] http://people.ubuntu.com/~stevenk/IMG_2096.JPG
[13:15] <MootBot> LINK received:  http://people.ubuntu.com/~stevenk/IMG_2096.JPG
[13:15] <persia> How much NEW do you need?
[13:15] <StevenK> So we go from 1,800 lines of C to about 70 lines of Python
[13:16] <StevenK> persia: Two source NEW, 3 or so binary NEW
[13:16] <lool> StevenK: what was the issue with pythonhildon?
[13:17] <StevenK> lool: It builds two binary packages, and only one of them was installed.
[13:17] <lool> StevenK: Do you provide new .menu files?
[13:18] <lool> I think it would be nice to define All, Home, and what we care about for menu-filters in our own menu files if we have a serious xdg menus parser
[13:19] <persia> Definitely.  I'm up for generating .menu files if nobody else wants it.
[13:19] <lool> Generating?
[13:19] <persia> Yes, generating.  We'd have to construct them, no?
[13:20] <lool> I'm speaking of /etx/xdg/menus/*.menu files
[13:20] <lool> LIke /etc/xdg/menus/applications.menu
[13:20] <persia> Yes, I also.
[13:20] <StevenK> I think the first step is to get the thing into the archive.
[13:20] <persia> That works.
[13:20] <persia> StevenK: Do you want an action?
[13:20] <StevenK> I was defeated by hildon-desktop today since mobile-basic-flash is hard-coded in a few places.
[13:21] <StevenK> I'll go through it next meeting, an action probably means I do it sooner
[13:21] <lool> StevenK: The h-d config files use mbf
[13:21] <lool> So yes, we need to fix them
[13:21] <persia> [ACTION] StevenK to get new xdg-compliant launcher into the archives
[13:21] <MootBot> ACTION received:  StevenK to get new xdg-compliant launcher into the archives
[13:21] <lool> I think we need to fix the hd build in general
[13:22] <StevenK> lool: Right. And we can't rebuild hildon-desktop
[13:22] <lool> The hack of providing mbf etc. is plain ugly and doesn't solve the real issue that hd doesn't build
[13:22] <lool> StevenK: You can grep on HildonFile and hildon-file to see what hd is using from hildonfm
[13:22] <lool> Hopefully not too much
[13:22] <StevenK> I have two quick hacks in my launcher that provide mobile-basic-flash files, so it should work
[13:23] <lool> FIlechoosers are easy to replace, it's compatible with the gtk ones
[13:23] <lool> StevenK: We need to fix the hd desktop build, think of security updates for instance
[13:23] <persia> Can we even distribute it if we can't build from source?
[13:23] <StevenK> I guess
[13:23] <lool> Err we should just fix the build, not look at removing it; we use it
[13:23] <StevenK> lool: I'm not sure how to do that. I can post my build log
[13:24] <lool> StevenK: grep has this -r flag which allows for grepping "recursively" so to speak
[13:24] <lool> it will descend in directories and grep all files for the pattern
[13:24] <lool> So it will basically grep the whole source
[13:24] <lool> And so you can tell which files "match the pattern"
[13:24] <lool> so to speak
[13:25] <StevenK> I know that
[13:26] <lool> StevenK: So what would be nice is adding a configure.in flag to build hd without hildonfm
[13:26] <lool> StevenK: And adding some ifdefs for this
[13:27] <persia> I think we're getting deep into specifics.  Maybe the two of you could discuss this towards an implementation for the next meeting?
[13:28] <lool> StevenK: Could you try doing this in the next week and throw technical questions at me if you get stuck?
[13:29] <StevenK> Sure
[13:30] <persia> OK.  StevenK: anything else?  Does anything block you?  Do you need anything from someone?
[13:30] <StevenK> Nope, I'm good
[13:30] <persia> OK.  Next is me talking about the installer.
[13:31]  * lool pumps up the volume
[13:31] <lool> I heard we have working installer in images since monday?
[13:31] <persia> Bug #182004 was milestoned for beta, so there's a very good chance we'll be able to have the preseeding working properly for beta images.
[13:31]  * davidm listens with interest
[13:32] <persia> There was a report (I don't have the bug number) about issues with installing grub.  I've made some changes to the platform.intrepid seeds that ought fix that, but am still testing the implications thereof, and trying to understand exactly what isn't working.
[13:32] <lool> So is it correct that we have a working installer included in the dailies?
[13:33] <persia> I'm currently blocked by the state of the linux-lpia and linux-meta-lpia packages, but have been working on them to try to get something that meets our needs.
[13:33] <lool> If it's not preseeded, I guess it just ask more questions?
[13:33] <persia> lool: Yep.
[13:33] <lool> Cool \o/
[13:33] <persia> The problem is that it enforces a password for the "ubuntu" user, which is contrary to the behaviour we wanted.  Only with working preseeding can this be skipped.
[13:34] <lool> Can you just remove the partman preseeded Qs?
[13:34] <persia> There's also the chance that someone could change the username, which would break the way we launch X, and we don't honor the GDM auto-login flag that ubiquity can set.
[13:34] <persia> No.  partman fails under --automatic even when you don't preseed it.  IT has to do with the way that partman and ubiquity interact.
[13:35] <persia> I don't actually want to preseed partman, but we need 182004 fixed in order to preseed other stuff in --automatic mode, even when we ask the partitioning questions.
[13:35] <cjwatson> yeah, I'll be trying to sort out 182004. I have some ideas
[13:36] <persia> cjwatson: Oh.  I thought Evan was working on it.  If you're both chasing it, that's even better news.  Thanks.
[13:36] <cjwatson> actually partman will succeed if you *do* preseed it
[13:36] <cjwatson> it's when you don't and use --automatic that you have a problem
[13:36] <cjwatson> if the blocker is simply knowing how to preseed it properly, I can help with that
[13:36] <persia> Ah.  So if we forced formatting the entire drive (as was done for hardy), it would work with --automatic today?
[13:36] <cjwatson> yes
[13:37] <persia> OK.  I'll try that for a few days, and we can see if we like it.  I'll work with the installer team to make sure I have the right hints.
[13:37] <persia> Thanks cjwatson.
[13:37] <lool> cjwatson: Do you think this will be fixed for intrepid's release, or shall be best switch to preseeding the partionning right now?
[13:37] <cjwatson> you should be able to remove the password preseeding without trouble
[13:37] <cjwatson> lool: I'm reasonably hopeful of the former
[13:37] <lool> Cool
[13:37] <cjwatson> we might not get it perfect but we'll at least work around the immediate problems
[13:38] <lool> ogra: I hope you'll pull the installer in the mobile images as well :-)
[13:38] <persia> Actually, there aren't any mobile images, for any architectures, but let's get to that in the next items.
[13:38] <persia> I'm done.
[13:38] <ogra> lool, absolutely :)
[13:38] <persia> Next up is lool, who is also confusingly listed in the agenda without any specific items.
[13:39] <lool> I think it's just the status reports which we wanted to move on top of the agenda
[13:39] <ogra> but please note that my image build wont happen before monday, i simply wont find the time before sunday to work on the patches for livecd-rootfs and for StevenK's wrapper
[13:39] <lool> Anyway, status is I spent a lot of time on elisa which is looking great
[13:39] <lool> I'd love if we could use it, but there's a catch
[13:39] <lool> it requires GL
[13:39] <persia> That's less than ideal for a number of devices :)
[13:40] <lool> So it's going to be problematic for poulsbo and virtual images
[13:40] <lool> I guess it's a non issue for intel chips though
[13:40] <ogra> lool, perfect for ubuntu-mobile then :)
[13:40] <lool> I also spent time on misc hardy stuff and am at OSIM and maemo summit this week
[13:40] <ogra> the launcher currently requires GL anyway
[13:40] <lool> So not much is going to be listed in my AR
[13:41] <lool> I have many high priority stuff to fix for hardy and intrepid
[13:41] <ogra> so we should probably provide elisa as option ;)
[13:41] <lool> ogra: Indeed; you need to make sure they interact nicely though
[13:41] <persia> Well, anything in the repos is an option.
[13:41] <lool> ogra: I know elisa works badly with compiz right now
[13:41] <ogra> lool, well, the image is a first shot thing anyway ...
[13:41] <ogra> the launcher too ;)
[13:42] <lool> The other options for media playback would be totem and moblin-media
[13:42] <ogra> and maximus is a metacity extension
[13:42] <lool> I don't consider vlc, mplayer or xine integrated enough, but they work fine for me
[13:42] <ogra> cant use compiz on ubuntu-mobile atm
[13:42] <persia> Given the current state of moblin-media, shall we look at getting totem into the images and tested?
[13:42] <lool> That sounds good
[13:42] <lool> StevenK: Does moblin-media still fail to start after my python-hildon upload?
[13:43] <lool> Anyway, not much more to report; meeting interesting people here
[13:43] <StevenK> I think it's fixed
[13:43] <lool> Ok; so moblin-media remains an option
[13:43] <lool> It's UI is quite simplistic, but totem is decent
[13:43] <persia> The missing part of moblin-media is the photo app.  Do we want fspot?  gthumb?
[13:43] <lool> I'm happy either way
[13:44] <lool> Is antyhing else pulling mono?
[13:44] <persia> moblin-media doesn't have any icons, last I looked.  Do we have icons?
[13:44] <persia> Nothing else is pulling mono
[13:44] <lool> I'm not sure fspot isn't a bit too rich for MIDs; perhaps for netbooks
[13:44] <persia> -mobile uses fspot.
[13:44] <lool> No strong opinion here either
[13:45] <lool> I like fspot, gthumb doesn't really offer the same features, but then pulling mono is expensive
[13:45] <persia> I'd prefer gthumb for -mid just for the reduced depedencies, but I'm on a likely useless quest to fit it on a 512MB stick.
[13:46] <persia> cgregan: Would you have time to test and compare the two, and make a recommendation?
[13:46] <cgregan> sure
[13:46] <persia> [ACTION] cgregan to compare F-Spot and GThumb on MID and suggest which to use as a replacement for Photos.
[13:46] <MootBot> ACTION received:  cgregan to compare F-Spot and GThumb on MID and suggest which to use as a replacement for Photos.
[13:46] <persia> lool: Anything else?  Anything blocking you?  Do you need anything from anyone?
[13:47] <lool> No, as I was saying earlier I'm done reporting; nothing blocking me
[13:47] <persia> OK.  Next is ogra, also without specifics.
[13:47] <lool> Except my TODO list keeps getting longer and it's not going to improve this week  :-/
[13:47] <StevenK> Hah
[13:47] <ogra> well, behind on touchscreens, but done with the Q1 keyboard remapping
[13:48]  * lool would like to report that ogra has been smoking; it's very bad for his health
[13:48]  * ogra still hopes anyone can test that apart from himself
[13:48] <ogra> two cigarettes today !
[13:48] <ogra> come on
[13:48] <lool> ogra: You might mention this critical text rendering bug you have with -mobile
[13:48] <persia> ogra: I think we need images.  Any objections if I generate -mobile live images?
[13:48] <lool> ogra: Do you have a bug id?
[13:49] <ogra> yeah, the mobile desktop is largely done, still needs a patch i only have locally for the netbook-launche and has issues with font rendering atm
[13:49] <lool> persia: You have cdimage access?
[13:49] <persia> lool: No, but I have been reading all the relevant code closely recently, and so can probably put together the set of changes required fairly quickly.
[13:49] <persia> Turning code that generates images into cdimage images is a simpler matter.
[13:50] <ogra> lool, no, but there is one open, i have to look it up
[13:50] <lool> ogra: Ok, good that it's file
[13:50] <lool> *filed
[13:50] <ogra> yeah
[13:50] <ogra> njpatel is aware of it and ties to fix it before release
[13:50] <ogra> i'll bug him next week again
[13:50] <lool> persia: Ok; ogra has a lot of time between cigarettes and has cdimage access and knowledge (per cmpc work)
[13:50] <ogra> ppppft
[13:51]  * ogra decides to go for a smoke after the meeting ... all these mentioning of cigarettes ...
[13:51] <persia> OK.  I won't generate -mobile images then :)
[13:51] <lool> persia: I'd be tempted to see you work on critical installer issues prior to mobile images, but that's probably just me
[13:52] <lool> It's not like we in the team feel like we can help on installer issues much; at least I feel like it would take me some hours or a day to grasp where you're stuck and start working on fixes
[13:52] <persia> I think that's just you.  The only "critical" issue is beyond me, and I'll prepare a workaround in the next day or so.
[13:52] <ogra> the mobile images are trivial to get, its really only copying the lines of -mid in livecd-rootfs
[13:52] <persia> Yeah.  Just didn't know where you were for time.
[13:52] <lool> Where who was for what?
[13:53] <ogra> what ?
[13:54] <lool> persia: Could you rephrase your last line?
[13:54] <persia> ogra: I agree that the image generation change is relatively trivial, I just wasn't sure if you would have time to complete it in the next day or two.
[13:54] <lool> 6 minutes warning
[13:54] <persia> Right.
[13:54] <persia> ogra: Anything else?  Anything blocking you?  Do you need anything from anyone?
[13:55] <ogra> persia, i will prepare it on sunday
[13:55] <ogra> nothing from the top of my head ...
[13:55]  * lool just realized we don't have a status report for davidm
[13:55] <ogra> the conference is slightly distracting from work here
[13:55] <lool> We should take some time to ask him how things are going like for the rest of us
[13:55] <persia> lool: Add it to the agenda next time :)
[13:55] <ogra> yeah
[13:55] <lool> I will
[13:55] <persia> Anyway, moving on
[13:55] <ogra> make him type on the n800 :)
[13:55] <persia> [TOPIC] Everything else
[13:55] <lool> *10
[13:55] <MootBot> New Topic:  Everything else
[13:56] <persia> Anyone have anything else they want to discussi?
[13:56] <lool> Germans are crazy
[13:56]  * ogra sees davidm starting to type
[13:56] <persia> That's not really on-topic for this meeting :)
[13:56] <lool> ogra: It will take a while with the tiny keyboard :-P
[13:56] <ogra> not as crazy as the french :)
[13:56] <MacSlow> lool, maybe ... but I always try not to be ;)
[13:56] <ogra> yeah
[13:56] <lool> persia: "everything else" sounded pretty largely inclusive
[13:57] <persia> lool: Well, yeah.  It's still supposed to be constrained by "Mobile Team Meeting".
[13:57] <lool> Ah right
[13:57] <lool> But we're almost in the desktop team meeting, we need some kind of transition
[13:57] <lool> See MacSlow picked it up
[13:57] <persia> ian_brasil mentioned some ideas for theme changing in IRC, but I've not heard of a specific patch yet.
[13:57] <ogra> well, lool could put that comment under "conference report" :)
[13:57] <lool> Anyway, thanks for chairing, persia:
[13:57] <lool> s/:/!
[13:57] <davidm> the show is going well 1/2 of the people are interested in arm ubuntu which we don't currently have.
[13:57] <persia> Right.  Ending the meeting then.
[13:58] <davidm> #endmeeting
[13:58] <persia> #endmeeting
[13:58] <MootBot> Meeting finished at 07:58.
[13:58] <ogra> not so fast, david needs a minute per sentence :)
[13:58] <lool> I wonder what ogra will do in the 2 extra minutes
[13:58] <lool> haha
[13:58]  * lool disappears again &
[13:58] <persia> ogra: The trick to using a MID to participate in an IRC meeting is to have a large text buffer from which one can cut & paste.
[13:59] <ogra> hehe
[13:59] <ogra> i usually do that
[14:00] <MacSlow> re
[14:00] <davidm> #endmeeting
[14:02] <persia> davidm: I already did, and you can't because you're not chairing
[14:03] <ogra> persia, he's playing with the up arrow key :)
[14:03] <persia> Ah!
[14:04] <StevenK> Heh
[14:04] <davidm> :-)
[14:05] <davidm> the N810 is very nice
[14:05] <davidm> but hard to type on, no touch typing!
[14:06] <davidm> thumbs are even hard to use
[15:01] <persia> OK.  Who's here for the Java meeting?
[15:01] <Koon> o/
[15:01] <persia> Hmm.  Let's wait a bit then and see if anyone else shows up.
[15:05] <persia> Well, apparently not.
[15:05] <persia> OK.  Getting started then.
[15:05] <persia> Roadmap review:
[15:06] <persia> robilad and slytherin don't appear to be present, and Koon has a special agenda item about maven, so I think there's nothing special here.
[15:06] <persia> Next up: Koon, with Discuss KISS alternative design from MavenSupportSpec
[15:06] <Koon> hmm. that agenda item might date back from last week's meeting
[15:06] <persia> That's what I thought.  I remember discussing it last week.
[15:07] <Koon> anyway, I had an action point about it, start a bootstrap analysis
[15:07] <Koon> https://wiki.ubuntu.com/JavaTeam/MavenKissBootstrap
[15:07] <Koon> I started it, this is the very first steps
[15:07]  * Koon reposts url for slytherin
[15:07] <Koon> https://wiki.ubuntu.com/JavaTeam/MavenKissBootstrap
[15:08] <Koon> that doesn't look like so many packages to do
[15:08] <Koon> but there is still some bootstrap ordering to do. Like is it necessary to have maven-compiler-plugin to build maven-compiler-plugin
[15:08] <persia> What do the colors mean?
[15:08] <Koon> green means in the repositories
[15:08] <Koon> red means not in
[15:09] <Koon> on the version number, green means probably ok
[15:09] <Koon> yellow means potentially too different from required version
[15:09] <Koon> (and yes, running a simple compile makes maven download three different version of plexus-utils)
[15:10] <Koon> I mean... 4 different versions :)
[15:10] <persia> RIght.  4 different versions of plexus-utils is right out :)
[15:11] <Koon> so it's a finite number, but I'm not sure you can bootstrap it from source
[15:11] <Koon> I don't really get how to build maven-compiler-plugin
[15:11] <Koon> I need to push that analysis a little further
[15:11] <persia> So it's about 30 packages we need, and once we have them, we may need some bootstrapping to get them all built against themselves?
[15:12] <Koon> persia: i'm not exactly sure what's acceptable in that area (circular build deps)
[15:12] <persia> Circular build deps are bad, and should be avoided.
[15:13] <persia> When it's not possible to work around them, one generates a special bootstrap version of a package that "builds" in a clean environment, and uses that to build enough to be able to build a clean package, and then uses that to rebuild the deps, etc. until everything built is clean.
[15:14] <Koon> persia: you should still avoid to build A with a A build dep, I suppose
[15:14] <persia> Most critically, one wants to minimise the number of "bootstrapping" packages so that the majority is actually built cleanly.  As such, the special bootstrapping package may not closely resemble the final form of that package.
[15:15] <persia> Koon: Building A with A as a build-dep is undesireable, but sometimes hard to work around (consider ghc6 or gcc).
[15:15] <Koon> anyway, more noext week
[15:16] <persia> Having A build-dep on B and C and B build-dep on A and C and C build-dep on A and B is considerably worse.
[15:16] <persia> For 30 packages, we'll probably need to find some strategy to get them working: maybe hack the build systems all to use ant for a first run, and then go back to upstream build systems and rebuild, or some such.
[15:17] <Koon> i'm pretty sure we can emulate what maven does for those
[15:17] <persia> Personally, given the number already present, I'm fairly confident we can find a way to build most of it with the existing tools, and then use this stack to build other things.
[15:17] <Koon> yes
[15:17] <persia> That avoids recursive bootstrapping.
[15:19] <persia> OK.  slytherin: we skpped MoveToUniverse earlier.  I notice there are still 10 bugs listed on the wiki page.  Are any of them critical for beta, or are we basically done for intrepid?
[15:21] <slytherin> persia: done as in I am not going to log any more bugs. I am just continuing work on existing ones.
[15:21] <slytherin> I will probably convert few FFE bugs to simply "compile with openjdk' bugs.
[15:21] <persia> OK.  Are any of the existing bugs stuck, or are they all going fairly smoothly?
[15:21] <slytherin> going fine.
[15:22] <persia> OK great.
[15:22] <persia> Anyone have anything else to raise, or shall we close the meeting?
[15:23] <Koon> just a thing
[15:24] <persia> Yes?
[15:24] <Koon> openjdk in alpha6 has different versions for amd64 and i386
[15:24] <Koon> amd64 failed to build for some reason
[15:24] <Koon> https://launchpad.net/ubuntu/intrepid/+source/openjdk-6/6b12~pre1-0ubuntu3
[15:25] <persia> Failed on sparc as well, which is somewhat unexpected.
[15:25] <Koon> I'm not sure what the safeguards are to avoid this in a more... definitive release
[15:25] <Koon> because on testing I get different results depending on arch
[15:26] <Koon> (the depends for -ubuntu2 are much heavier than for -ubuntu3
[15:26] <Koon> ans that's... undesirable :)
[15:27] <Koon> an amd64 failed build doesn't prevent the i386 package to go to the archive and then on the CD ?
[15:27] <persia> http://people.ubuntu.com/~ubuntu-archive/testing-ports/intrepid_outdate.html and http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_outdate.html are the current safeguards.
[15:27] <persia> These lists need to be reviewed and cleared.
[15:28] <persia> Mind you, those are only for main.  Production of similar lists for universe and multiverse is being investigated, but may not be ready for intrepid release.
[15:28] <Koon> ok, was just a little worried when I saw that :)
[15:28] <persia> No, there's no such block: it's expected that all such situations like that can be fixed.
[15:29] <persia> segfault during documentation construction!  My, that's annoying.
[15:29] <persia> Has anyone tried a local build to see if it's transient?
[15:29] <slytherin> local build of openjdk? you are kidding right? :-)
[15:29] <Koon> hmm. building openjdk is not... light :)
[15:30] <Koon> my VMs don't have enough RAM, tbh
[15:31] <Koon> they start swapping and hell breaks
[15:32] <persia> I wasn't kidding.  I'd also recommend building in a chroot, rather than in a VM.
[15:32] <Koon> (my VM runs a pbuilder chroot)
[15:32] <slytherin> I don't have amd64 machine or I would have tried it.
[15:33] <persia> And I'm typically running too many VMs to also run that big a compile.  I suppose we'll hope doko can fix it then.
[15:33] <persia> OK.  Anything else?
[15:33] <Koon> nope
[15:33] <slytherin> I have one thing to say
[15:34] <slytherin> do we plan to test any frequently used java apps with openjdk. ex. azureus
[15:35] <persia> We've not identified any testing plans as a team.  Do you think we ought organise some as we near release?
[15:36] <slytherin> yes, probably after beta. But I am not sure what all apps we should test.
[15:36] <persia> Do we have anything other than the browser plugin that is destined for any of the CDs?
[15:36] <persia> Koon: Did tomcat make a CD?
[15:37] <Koon> There is tomcat-server tasksel on the server Cd
[15:37] <slytherin> cool
[15:37] <Koon> I'm in the process of plugging a test case into iso.qa.ubuntu.com
[15:38]  * persia checks the livecd manifest again
[15:38] <Koon> (that's why I was concerned about extra deps on the amd64 cd ;)
[15:39] <persia> Hmm.  LiveCD doesn't even ship the browser plugin.
[15:40] <persia> OK.  I claim testing tomcat is the priority.  azureus might be a good second test.  Any other packages that would be release-critical if they didn't work?
[15:41] <slytherin> persia: what is size of Live CD? browser plugin will need jre also so don't think tehy will fit on CD.
[15:41]  * slytherin has to go for meeting.
[15:41] <persia> slytherin: Indeed.
[15:42] <persia> OK.  Anything else to raise?
[15:43] <persia> OK.  Ending the meeting then.
[15:44] <persia> Koon: please share how we can test tomcat for the next meeting
[15:44] <persia> slytherin: Please organise some test cases for azureus so we can get it tested.
[15:44] <persia> Have a good week everyone.
[15:44] <Koon> ok
[20:37] <Arc> has anyone heard anything about the EMEA membership meeting reschedule?
[20:57] <stgraber> Arc: no planed date yet, sorry.
[21:00] <Arc> so I guess it's not going to be this week after all
[21:18] <leoquant> @schedule


[09:54] <thorwil> kwwii: so jaunty alpha3 still has the ibex wallpaper?
[10:21] <soc> hi
[10:21] <soc> someone from the dusttheme team online?
[12:08] <lianimator> anyone use wacom intuos3?
[12:08] <lianimator> need help configuring
[13:06] <soc> someone from the dusttheme team online?
[13:09] <thorwil> soc: you are looking for rsc. or maybe his nick was rsc- or something like that
[13:10] <soc> ah ok thanks
[13:13] <thorwil> soc: he seems to be rather busy these days, i don't see him here often. you might have more luck with a request on the mailing list
[13:13] <soc> ah ok, thanks
[13:15] <thorwil> soc: his site: http://www.ricostacruz.com/
[14:26] <soc> thanks