=== bdrung_ is now known as bdrung
=== Saviq_ is now known as Saviq
=== marlinc_ is now known as marlinc
=== essembe is now known as sbeattie
[10:17] <rbasak> infinity: opinion on bug 1528583 please?
[10:17] <ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
[10:18] <infinity> rbasak: My opinion without reading it is that we should probably do it for support longevitiy reasons, but I should read the bug first. :P
[10:47] <flexiondotorg> infinity, Could I get an ack on an FFe please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1556869
[10:47] <ubot5> Launchpad bug 1556869 in ubuntu-mate-welcome (Ubuntu) "FFe: ubuntu-mate-welcome 16.04.4 new release [debdiff and tarball attached]" [Undecided,New]
[10:48] <flexiondotorg> infinity, It is only seeded in Ubuntu MATE. Is specific to Ubuntu MATE. Has 3 developers. And we need this so we then translator are finished it can be multi-lingual.
[10:48] <infinity> flexiondotorg: 1.2MB diff?  Impressive.
[10:49]  * infinity groans at ./edgar-allan po
[10:51] <flexiondotorg> Yeah, we just went with it ;-)
[10:52] <infinity> flexiondotorg: It's entirely unreviewable, but seems fine in spirit.  And you have plenty of motivation to fix it if/when it explodes in your face, so go for it.
[10:53] <flexiondotorg> infinity, Can I quote you in the comment of that bug :-)
[10:53] <infinity> flexiondotorg: Yep.
[10:53] <flexiondotorg> infinity, Thanks. And it is well tested and we absolutely are motivated to fix it.
[10:56] <flexiondotorg> infinity, Where are you today?
[11:04] <rbasak> infinity: did you manage to look at bug 1528583 please?
[11:04] <ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
[11:15] <infinity> rbasak: Okay, caught up on the bug.  LGTM, but please see the transition and migration through to completion ASAP.
[11:15] <rbasak> infinity: ack. Thanks!
[11:15] <infinity> rbasak: And I hope that this work with Lars is ending up back in Debian too.  I don't want to see us forking.
[11:16] <rbasak> infinity: yes, it is. I'm DM for mysql in Debian now. Though this would be a new source package.
[11:16] <infinity> rbasak: Sure, I just meant packaging changes in general shouldn't be forked if we can help it.  Carry on.
=== barry` is now known as barry_
=== barry_ is now known as barry
=== henrix_ is now known as henrix
=== maxb_ is now known as maxb
=== rw is now known as dax
=== tyhicks` is now known as tyhicks
[17:06] <coreycb> hello, can an archive admin please promote python3-osprofiler to main?  python-osprofiler is already in main.  this will help get some openstack packages out of dependency waits.
[17:06] <coreycb> infinity, ^
[17:06] <infinity> coreycb: On it.
[17:07] <infinity> coreycb: And done.
[17:07] <coreycb> infinity, thanks!
[17:14] <andyrock> hey I would like to propose a FFe
[17:14] <andyrock> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/676457
[17:14] <ubot5> Launchpad bug 676457 in unity (Ubuntu Xenial) "[FFe] Launcher - Add 'launching' state to launcher icons" [Medium,In progress]
[17:14] <andyrock> tell me if you need something more
=== jhodapp is now known as jhodapp|errand
[18:30] <ogra_> infinity, eeek ... why multivers and not restricte for rpi ?
[18:30] <ogra_> *restricted
[18:31] <infinity> ogra_: Because the kernel is in universe.
[18:31] <ogra_> :(
[18:31] <infinity> ogra_: If the kernel moves, happy to move the firmware with it.
[18:31] <ogra_> yeah, given thats our reference arch for snappy armhf it should really move to main
[18:32] <infinity> Guessing some people don't want to get bitten by the omap4 reference arch thing where we committed to supporting a dead platform for 5 years. :P
[18:32] <ogra_> haha, yeah
[18:33] <infinity> (Almost done!)
[18:33] <ogra_> * ppisati hat die Verbindung getrennt (Quit: leaving)
[18:33] <ogra_> LOL !
[18:33] <ogra_> we scared him away
[18:33] <knome> infinity, what's yourr estimation on the possibility to see the xubuntu base stuff for beta 2?
[18:34] <infinity> ogra_: The thing with universe is that we can still hold the kernel team to the same standard, Canonical can still claim and sell support, but we make no promises to the community.  So, if we only claim it's supported for, say, a year, we can give up after that.
[18:34] <ogra_> funnily there are still people coming to #pandaboard ... even 4 years after it went out of prod.
[18:34] <infinity> ogra_: Given that argument, I'd say universe is where BSP kernels belong.
[18:34] <ogra_> yeah
[18:35] <infinity> knome: Good.
[18:35] <ogra_> i remember doing that for the ac100 video drivers back in the days
[18:35] <knome> infinity, great to hear; be in touch if anything comes up
[18:35] <ogra_> and with snappy it doesnt really matter much where the deb comes from ... as long as it lands in the snap store in the end
[18:36] <infinity> ogra_: It matters where it comes from if you want provenance for the source. :P
[18:36] <infinity> ogra_: But, yes, the component it comes from doesn't matter.
[18:36] <ogra_> not even the deb as long as your snap description points to the git tree
[18:36] <infinity> ogra_: Pointing to a git tree is a very sketchy way to "provide" source unless you control it.
[18:37] <ogra_> in the snappy world debs are just interim steps after all
[18:37] <infinity> (So, fine for Canonical trees that we promise not to break, abysmal for anything else)
[18:37] <ogra_> yeah, indeed ... i meant kernel.ubuntu.com ... not some random github source :)
[18:37] <infinity> kernel.ubuntu.com isn't the source for those kernels, though.
[18:37] <infinity> Err.
[18:38] <infinity> It is.
[18:38] <ogra_> heh
[18:38] <infinity> Somehow, I read kernel.org
[18:38] <infinity> Even while typing ubuntu.com
[18:38] <infinity> I'm not having the best day. :P
[18:38] <ogra_> jetlag galore i guess ?
[18:38] <infinity> Jetlag, evil abdominal pain, brain malfunction.  A bit of a mixed bad.
[18:38] <infinity> s/bad/bag/
[18:38] <apw> they really should be made into .debs so they get some review before we ship them, as snap seems to designed to avoid that
[18:39] <infinity> It took me 7 tries to type my GPG passphrase earlier.
[18:39] <ogra_> oh my
[18:39] <ogra_> apw, sure, but the user doesnt care ... and snappy doesnt either ...
[18:39] <ogra_> (we do, but thats a process thing)
[18:39] <infinity> Indeed, but it's a handy way to QA, at least for now.
[18:39] <ogra_> yeah
[18:40] <infinity> Down the road, I assume we'll have sane automated QA for kernel snaps generated directly from source.
[18:40] <infinity> We don't today.
[18:40] <ogra_> and its indeed helful for flavours
[18:40] <ogra_> *helpful
[18:40] <ogra_> but after all tteh deb is just a by-product ...
[18:40] <infinity> There's also, in this case, the promise that we're providing deb-based images too. :P
[18:40] <infinity> So, then obviously doing the kernel once is smarter than twice.  So, build a deb, slam the binaries in a snap, everyone wins.
[18:41] <ogra_> yeah, just talking from a snappy view here
[18:41] <infinity> ogra_: Yeah.  But please be careful about selling the "snappy is the future, the distro is dead" thing, cause that (wrong) message has travelled pretty far, and we're trying to undo it.
[18:41] <ogra_> it is definitely more convenient because we have pocesses around debs in place today ... but its not actually required from a tech POV
[18:41] <infinity> ogra_: Mark seemed shocked at the last sprint to find out that journalists and users think we're going that way.
[18:42] <infinity> So, for at least raspi2 and dragonboard, where we're also providing a deb-based ubuntu-server, the question is moot.  The deb isn't a "by-product", it's a real product and, indeed, the snap ends up a handy repackaging of the same binary.
[18:42] <knome> infinity, maybe it would help if there was clear communication about the situation
[18:42]  * ogra_ never said it is an exclusive way
[18:42] <infinity> For OEM devices, doing a deb is probably pointless, and they can snap directly.
[18:43] <knome> infinity, with flavors and all relevant teams too, not only with end-users
[18:43] <infinity> knome: Yeah, the messaging was a mess a year ago or so, and I think there needs to be some cleanup to fix that.  I'll see if I can get the right people involved to undo some of that.
[18:44] <knome> mhm, nice to hear that too :)
[18:44] <infinity> knome: If it's any consolation, Mark's been adamant (to the point of nearly shouting at people) that the classic apt/deb distro is not going away, neither now, nor in the future.  It's here to stay until no one wants distros anymore or Ubuntu dies a horrible death for unrelated reasons.
[18:44] <ogra_> i dont get where journalists would have gotten that ... it was made pretty clear in all the UOS talks, keynotes etc
[18:45] <apw> i get that impression when listeing to discussions about snaps mostly, and i know better
[18:45] <infinity> knome: The one caveat to that is that we might stop packaging a select few bits and require flavours to ship the snappy binary package to do snappy-on-desktop if they want to get those apps from us.  But we're still sorting out how all that might work (and, of course, you'd be free to get together and maintain those apps as debs if you prefer that option, no one would stop you).
[18:45] <knome> infinity, yeah, i'm not worried about the situation itself, it's just that sometimes the message does get out the wrong way (as we know) and if these things aren't communicated to flavor teams and other teams linked to ubuntu, it also means that those teams do not have any more confidence in X than the end-user
[18:46] <infinity> ogra_: Messaging around desktop-next hurt a lot.  People really thought we were dropping apt/deb entirely.  And even now, people refer to it as "snappy" and "classic Ubuntu" (and I've even heard "legacy Ubuntu").  Classic and legacy are not adjectives that make people think we want to keep the product around.
[18:46] <ogra_> true
[18:50] <infinity> Realistically, common sense says that we have millions of server/cloud users and tens of thousands of desktop users who would rise up with pitchforks and do Very Bad Things to us if we actually stopped producing the apt/deb distro, but that doesn't stop the FUD from spreading.
[18:50] <ogra_> well ... and its a fact that the phone (and thus the convergence desktop) will at some point be snappy based
[18:51] <ogra_> this might or might not extend to the normal desktop too, who knows ... but i dont think anyone of us ever claimed thats a done deal (or that debs wouldnt be supported in that case, they are today in snappy)
[18:52] <ogra_> the actual prob are journalist assumptions around this ... and a very blurry definition of what snappy actually is ... even internally
[18:54] <ogra_> infinity, btw ... your battling aginst the "classic" term might be a bit moot ... to enable deb support in todays snappy you literally have to run "snappy enable-classic"
[18:54] <infinity> ogra_: Yeah, I know.
[18:54] <ogra_> and thats a mark naming
[18:54] <infinity> ogra_: Not only am I aware of that, but I also saw it wipe out utlemming's laptop live and in person!
[18:54] <ogra_> lol
[18:54] <infinity> Yeah, not so lol for him.
[18:54] <ogra_> i'm not talking about the "snappy on classic deskktop" thing
[18:55] <infinity> mvo fixed the bug an hour later, but lacking a time machine, that didn't get his home directory back.
[18:55] <ogra_> i'm actually talking about the other way round
[18:55] <ogra_> (deb support on a native snappy install)
[18:55] <infinity> I know.  But "enable-classic" does/did Very Bad Things when run on a classic desktop.
[18:55] <infinity> Which was entertaining from a distance.  Painful up close.
[18:56] <ogra_> oh, he ran "snappy on classic deskktop" and there he ran snappy enable-classic ?
[18:56] <infinity> Yep.
[18:56] <ogra_> thats insane, we shouldnt support it
[18:58] <ogra_> (there is definitely no need for such an inception ... )
[19:01] <infinity> Anyhow, back to the original topic:
=== jhodapp|errand is now known as jhodapp
[19:02] <infinity> apw: Do you concur that tossing BSP kernels in universe (combined with main-like quality requirements and Canonical statements of support) is the sane way to handle things so we don't get stuck supporting a BSP for 5 years again, a la omap4/amradaxp/keystone?
[19:02] <apw> infinity, that sounds sane to me, as that lets us dial back support to product life
[19:02] <infinity> apw: To me, it seems much saner, so long as from our end we act as if it were in main, but we're making no bold promises to the community about lifecycle.
[19:03] <ogra_> omap4 wouldnt ave been that bad, had TI not decided to drop it completely right after 12.04 release :)
[19:03] <apw> infinity, that fits my mental model ...
[19:03] <infinity> ogra_: omap4 isn't actually hard to rebase/support (neither is armadaxp or keystone), but in all cases, the contracts ran out before the community support did, and that seems like a bit of a screw up.
[19:04] <ogra_> well, effectively the omap4 work is wasted time
[19:04] <ogra_> no matter if for contract or community ... the HW is gone
[19:05] <ogra_> (since about a month after the release that brought the support)
[19:05] <ogra_> infinity, apw, that remonds me, we'll have to look at the wifi firmware for the dragonboard too
[19:06] <ogra_> i guess that will be in the same camp then
[19:06] <ogra_> *reminds
[19:07] <ogra_> paolo has a package in his embedded PPA already
[19:15] <doko> infinity, do you have an idea about https://launchpad.net/ubuntu/+source/mmpong/0.9.1-3build2 ?
[19:24] <infinity> doko:
[19:24] <infinity> -- checking for one of the modules 'CEGUI-OPENGL'
[19:24] <infinity> -- disabling mmpong-gl because of missing dependencies.
[19:25] <infinity> doko: Not that the cmake output is very helpful about what it's looking for, but that cmake snippet is probably sort of readable.
[19:26] <doko> oops, that was the wrong one. was looking for the uninstallability of the smc b-d's
[20:26] <cyphermox> infinity: would you have time to review libcxl today?
[20:26] <infinity> cyphermox: Dunno.
[22:58] <flexiondotorg> infinity, Any news on Base?