[13:58] <slangasek> https://plus.google.com/hangouts/_/7ecpj1uhgvnl346mfisfouopu0
[14:02] <dholbach> did anyone press the "go live" button already? :)
[14:02] <slangasek> no
[14:02] <apw> feels like not here
[14:02] <slangasek> we're missing doko, trying to decide if it's worth having the session for :)
[14:02] <pitti> slangasek: he pinged me half an hour ago, he's on crappy mobile network
[14:02] <slangasek> ok
[14:03] <pitti> not good enough for hangouts
[14:03] <slangasek> not even audio?
[14:03] <pitti> I don't know
[14:03] <pitti> he said "let's see.."
[14:05] <apw> slangasek, we can see you
[14:05] <pmcgowan> hear you
[14:05] <Saviq> \o/
[14:05] <pbass> we see you
[14:06]  * xnox runs off to find my 2fa token.
[14:06] <doko> slangasek, I'm online, lets see how this works out ...
[14:07] <slangasek> doko: ok - https://plus.google.com/hangouts/_/7ecpj1uhgvnl346mfisfouopu0 if you can; I was looking to see if we could call you to bridge you in, but hangouts have hidden the button again
[14:10] <apw> xnox, is there any reason mako cannot use v4.6 as well if that is what is upstream
[14:10] <apw> xnox, we probabally only use that because v4.8 didn't work, and v4.7 did
[14:11] <cjwatson> There's already a 4.7 cross stack in the archive, so no reason to take that backward
[14:11] <apw> ok
[14:11] <cjwatson> gcc-4.7-arm-linux-gnueabihf - GNU C compiler
[14:12] <asac> do we know why they kept going with 4.6 on kernels?
[14:12] <asac> (dont need to address in hangout, just question for channel)
[14:12] <xnox> asac: e.g. goldfish gives kernel panic before it completes boot, when compiled with 4.7 or 4.8.
[14:13] <ogra_> i think maguro too
[14:13] <asac> right. but i am sure google could have fixed that easily if there were no other reasons for staying on 4.6
[14:13] <apw> slangasek, can you add a WI for me to make that switch where needed
[14:13] <xnox> at the moment: all nexus kernels use 4.6, mako uses 4.7.
[14:13] <xnox> apw: done.
[14:13] <asac> e.g. i believe there might be good reasons... in particular if they use 4.7 for the userspace
[14:13] <slangasek> apw: which switch? to libiberty
[14:13] <asac> xnox: do they use 4.7 in userspace? or even 4.4?
[14:14] <ogra_> asac, 4.6
[14:14] <xnox> asac: haven't checked recently, I believe there was a newer toolchain for kitkat, in user-space only.
[14:14] <xnox> asac: pre-kitkat is 4.6
[14:14] <cjwatson> doko: (repeating from the hangout) binutils-dev already ships libiberty.a, so I don't quite get how it's an extra maintenance burden to just ship that as a separate binary package instead rather than duplicating the source - I guess I'm missing something?
[14:14] <asac> cjwatson: slangasek: talking about cross compiling kernels... any thoughts about allowing to cross compile kernels in PPAs?
[14:15] <ogra_> asac, for what ? to save 20min ?
[14:15] <lool> why dont I get a live stream of this session
[14:15] <cjwatson> Cross-PPA support is interesting - the trick is (maybe) limiting it to only things that would actually work so that people don't get a profoundly disappointing experience
[14:15] <asac> right
[14:15] <ogra_> lool, i do
[14:15] <lool> odd
[14:15] <cjwatson> My thoughts on this to date have been that it's better to focus on expanding the scope of things that we can cross-build so that it's less disappointing
[14:16] <lool> maybe I have too many streams open
[14:16] <doko> is there a way to turn off video in hangouts?
[14:16] <cjwatson> yes, there's a camera icon at the top that you can click
[14:16] <ogra_> doko, click the camera icon
[14:16] <cjwatson> or do you mean everyone else's video?
[14:16] <doko> the latter
[14:16] <pitti> turn bandwith usage down
[14:16] <ogra_> yeah
[14:16] <asac> lool: your computer doesnt like anything related to video streams... no hangouts, no yuoutube :)
[14:16] <pitti> in the "signal strenght" like slider
[14:16] <asac> etc.
[14:17] <ogra_> cjwatson, cant highbank do proper virtualization ? i thought it could ... i would rather see all PPAs get faster than having a list of püackages that can cross build in a PPA
[14:21] <lool> asac: :-)  actually it was due to too many streams open (was trying to follow two other sessions)
[14:21]  * asac wonders how lool can listen to multiple streams
[14:21] <asac> i can imagine two ... one for each ear
[14:21] <asac> everything else must also be hard for you to process
[14:21] <asac> hehe
[14:22] <ogra_> asac, 5:1 dolby surround ...
[14:22] <ogra_> 6 channels ;)
[14:22] <cjwatson> ogra_: I don't think highbank can, I think we're waiting for next-gen (A57 or similar)
[14:22] <ogra_> ah, ok
[14:22] <ogra_> i still think we should wait
[14:22] <ogra_> instead of having to maintain an artificially made up list
[14:23] <lool> asac: mute everything and listen i n2 minutes chunks  :-)
[14:23] <rsalveti> xnox: I believe kitkat should be using 4.7/4.8
[14:23] <cjwatson> I indeed don't think that a whitelist (or even blacklist) is a scaleable approach
[14:23] <rsalveti> but the kernel is still using that very old toolchain
[14:24] <ogra_> rsalveti, even the N5 one ?
[14:27] <rsalveti> ogra_: sorry, was thinking about the goldfish target (the one requiring 4.6)
[14:27] <ogra_> ah, good
[14:27] <ogra_> would be odd if hammerhead still used such an old kernel
[14:32] <pmcgowan> sounds good
[14:36] <mzanetti> I think app development would be mostly qmake
[14:36] <apw> did we just lose the feed, or si that me
[14:36] <mzanetti> apw: works here
[14:37] <mardy> and QBS! :-)
[14:37] <sergiusens> shouldn't the sdk should default to cmake for ubutnu touch projects?
[14:37] <mzanetti> thing is, qtcreator generates everything qmake for you. cmake is completely manually
[14:38] <cjwatson> qtcreator's under our control, at least partially
[14:38] <apw> firefox crashage, yay ...
[14:38] <mzanetti> cjwatson: well, we could extend qtcreator to properly support cmake, which sounds a lot to me tbh
[14:39] <mzanetti> fine with me personally. but it's more complex for app developers.
[14:39] <cjwatson> It might be more complex for the SDK team
[14:40] <slangasek> right
[14:40] <cjwatson> It should surely be invisible to app developers
[14:40] <slangasek> the SDK should DTRT
[14:40] <mardy> for app development QBS is easier, and it's probably going to be the build system better supported by QtCreator in the long term
[14:40] <cjwatson> (Unless they poke around at their build system)
[14:40] <mzanetti> cjwatson: no. it's never completely visible to the developer.
[14:40] <cjwatson> Is qmake == QBS?
[14:40] <mzanetti> err. completely invisible
[14:40] <mzanetti> QBS == QMake Build System
[14:40] <mzanetti> the new thing to come soonish
[14:40] <mardy> cjwatson: no, it's a new stuff, with a JSON/QML-like syntax
[14:41] <mzanetti> err.. QML Build system
[14:41] <cjwatson> Well, the reality is that right now we know how to make cmake support cross-building and we know that there are significant difficulties with qmake
[14:41] <cjwatson> Long-term I'd like to have all build systems cross-build-capable, but there's the matter of which we can do first
[14:41] <Saviq> https://bugreports.qt-project.org/browse/QTBUG-29987
[14:41] <mardy> cjwatson: makes sense
[14:42] <cjwatson> (And upstream cross-build-capability isn't necessarily the same as it working properly for Ubuntu - non-multiarch cross-building can be significantly different if done badly)
[14:45] <dholbach> (qt4) and checkbox I think, but AFAIK that's being rewritten
[14:46] <Saviq> qbs == Qt Build Suite apparently
[14:46] <Saviq> http://qt-project.org/doc/qbs-1.1/index.html
[14:49] <mardy> cjwatson: but not all the stack is built with cmake
[14:49] <lool> cjwatson: and similarly we should start by cross-compiling the clicks that we include I guess
[14:49] <cjwatson> mardy: not all the stack is built with any one system :-)
[14:50] <cjwatson> mardy: so yes, I expect that fixing the whole stack will involve fixing multiple build systems
[14:50] <cjwatson> lool: perhaps, yeah
[14:50] <mardy> cjwatson: yep :-)
[14:50] <lool> sergiusens: ^ FYI on cross-compilation topic, we're thinking of testing/dogfooding the cross-compilation story with the builds of the preinstalled click
[14:50] <lool> s
[14:51] <cjwatson> which of those are arch-dep right now?
[14:51] <lool> at the moment we pull some prebuilt files from .debs
[14:51] <lool> so the actual builds are not arch-specific, except for the armhf debs they download
[14:52] <mzanetti> o/
[14:52] <sergiusens> cjwatson, lool notes-app is the only one building that way
[14:52] <sergiusens> it's cmake based
[14:52] <lool> great
[15:04] <slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970
[15:05] <slangasek> jodh: ^^
[15:08] <stgraber> xnox: coming?
[15:09] <zyga> live
[15:09]  * slangasek waves
[15:09] <zyga> jodh: what are the small projects?
[15:10]  * xnox o/
[15:10] <slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970
[15:10] <slangasek> I'm gonna keep repeating that until people join ;)
[15:11] <zyga> slangasek: topic it
[15:11] <zyga> what is the goal of using cgroups in upstart?
[15:12] <xnox> zyga: resource control.
[15:13] <slangasek> zyga: just like we support ulimits / chroot primitives, we should support cgroups
[15:14]  * zyga needs to learn more about cgroups
[15:16] <apw> why can we not move the process to the cgroups after, i thought you could shift runnign things
[15:16] <apw> and if we have upstart running we have enough disk to make the cgroup mamanger startable directly rather than via a job
[15:18] <slangasek> apw: what do you mean, "directly"?
[15:18] <apw> slangasek, fork/exec it directly before parsing jobs
[15:19] <slangasek> hmm
[15:19] <apw> so it is part of upstart, but not killing upstart if it explodes
[15:20] <zyga> there is one more case to consider, what it there are no cgroups at all (or they are disabled for any reason)
[15:20] <zyga> the way cgroups are tied to jobs starting needs to address that
[15:20] <apw> yeah what if the kernel has no cgroup support ...
[15:20] <apw> slangasek, ^^
[15:20] <zyga> but I agree that cgroup helper should be special so that state is consistent
[15:21] <zyga> and that there are no arbitrary periods of time after a jobi started before its cgroup profile is applied
[15:21] <zyga> s/i / is /
[15:22] <zyga> time bridge would be fantastic
[15:23] <zyga> "start 10 minutes after system-booted"
[15:23] <zyga> system-booted is just a job name
[15:25] <marrusl> killing stuck jobs. is that part of "refining ptrace handling" ?
[15:25] <slangasek> zyga: "arbitrary periods of time" - well, the only way to do that is to delay the boot until the cgroup manager is started
[15:25] <slangasek> marrusl: yes
[15:25] <marrusl> I am so happy.
[15:26] <zyga> slangasek: indeed
[15:26] <zyga> slangasek: my point is that that arbitrary period feels bad from a design perspective
[15:26] <gQuigs> and it would actually fix a bug that we don't know when to kill dbus which the X app exits over ssh
[15:28] <gQuigs> this bug: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434
[15:28] <udsbotu> Launchpad bug 592434 in dbus (Ubuntu) "ssh -X user@machine hangs when using exit to terminate" [Low,Triaged]
[15:28] <gQuigs> re: track user SSH sessions ^
[15:28] <zyga> slangasek: perhaps the alternative is to have a stanza that controls this
[15:28] <zyga> slangasek: so for most jobs, that would be immediate, and blocking
[15:29] <zyga> slangasek: but for certain early jobs we can relax that to 'when possible' and perhaps send some signal to communicate the fact (or tie that requirement to SIGSTOP support)
[15:29] <zyga> slangasek: like startup-SIGSTOP-cgroups-SIGCONT
[15:29] <zyga> ^^ :D
[15:30] <zyga> socket bridge is not optional
[15:30] <zyga> cgropus can or can not be available and the job should not differ
[15:31]  * zyga might join the session but doesn't feel like a system level engineer to speak up really
[15:33] <zyga> jodh, slangasek, stgraber: ^^
[15:33] <slangasek> zyga: please join ;)
[15:36] <beidl> it has to be special cased because it provides the infrastructure for jobs
[15:36] <apw> slangasek, i think i liked your statement there "it backs a stanza implementation"
[15:37] <apw> "start on using_stanza_cgroups"
[15:39] <apw> xnox, i think you want upstrart syntax for that  different words for optional and not
[15:39] <apw> cgroup <stuff>
[15:39] <apw> cgroup optional <stuff>
[15:50] <mdeslaur> it's not something we need, it's something we'd be interested in looking at if it was available
[15:53] <gQuigs> why ever depend on having swap?
[15:58] <apw> jodh, could you do something like hte kernel does, and have the cgroup stanza actually start the job, like a modprobe for a protocol family in the kernel
[15:59] <apw> jodh, limits, can there not be a wrapper which applies those and used as an exec script prefix ?
[16:02] <roadmr> oh that's today! yay
[16:05] <cjwatson> Hangout URL?
[16:05] <cjwatson> (Who's running the video?  slangasek I assume)
[16:06] <slangasek> https://plus.google.com/hangouts/_/72cpj2k5dn4bjr053d5ehn1lpo
[16:06] <slangasek> cjwatson: ^^
[16:10] <apw> do we have a stream yet ?
[16:10] <slangasek> yes
[16:10] <rtg> not that we can see
[16:10] <slangasek> hmm
[16:10] <apw> white space for me
[16:11] <slangasek> checking
[16:11] <slangasek> oops, got the URLs backwards :P
[16:11] <slangasek> fixed
[16:12] <apw> slangasek, have it now
[16:12] <slangasek> also, why are you people not joining the hangout ;)
[16:12] <apw> is there any kernel work :)
[16:12] <rtg> haven't combed my hair yet
[16:12]  * apw has no hair
[16:12] <cjwatson> that's what video-off is for
[16:12] <apw> :)
[16:12] <cjwatson> (actually I just don't want to deal with bw awfulness)
[16:12] <slangasek> apw: do you want there to be?
[16:13] <apw> slangasek, i normally listen till it sounds like one needs kernel input
[16:13] <josepht> lower thirds please
[16:13] <apw> "sitting in the second row"
[16:38] <smoser> slangasek, link?
[16:55] <apw> slangasek, often to do with clocks yes
[16:55] <slangasek> hum
[16:55] <apw> slangasek, i don't thnk it was ubiquitus or anything
[16:55] <rtg> slangasek, yeah, that'll get important pretty quick
[16:56] <apw> stgraber, we will be interested in those, get us the bug #'s
[16:56] <stgraber> Nov 12 12:58:48 castiana kernel: [213981.764426] Request for unknown module key 'Magrathea: Glacier signing key: f440a253eb498df923d438caa09b3b5d99308405' err -11
[16:56] <apw> slangasek, keys have valid date ranges on them, a bad system clock can break the key load
[16:56] <rtg> slangasek, certificate authority date is related to the clock (I think)
[16:57] <slangasek> apw: hmm; so I don't think that was the cause for me
[16:57] <slangasek> [    2.523405] video: module verification failed: signature and/or required key missing - tainting kernel
[16:58] <slangasek> that's here on the most recent boot, and my system clock isn't dodgy
[16:58] <apw> slangasek, hmmm, yeah, i've added a WI to investigate them, if you could file a bug on that and get me the number, stgraber also
[16:59] <apw> slangasek, i can only assume it is an ordering issue, we boot too quick or something helpful
[16:59] <rtg> apw, there are plenty of bugs mentioning this problem. maybe jsalisbury would know one .
[16:59] <stgraber> slangasek: ah yeah, I see that one too
[16:59] <apw> rtg, good idea, will engage him
[16:59] <stgraber> slangasek: I'll file a bug
[17:00] <slangasek> stgraber: ta
[17:00]  * apw bets you both use somethign which gets graphics into your initrd
[17:00] <stgraber> we both use cryptsetup
[17:00] <apw> that ... see
[17:00] <apw> i bet that is why i don't see it
[17:01] <slangasek> ok
[17:07] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1253155
[17:07] <udsbotu> Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [Undecided,New]
[17:56] <dholbach> xnox, I'm leading another session at the same time :-/
[17:56] <dholbach> err, slangasek: ^
[17:57] <slangasek> dholbach: ok.  Do you need this rescheduled?
[17:57] <slangasek> I just sent the hangout invite to everyone subscribed to the session
[17:57] <dholbach> no, I don't think I need to be there, I'll watch the video later on
[17:58] <slangasek> ok, cool
[17:59] <karni> slangasek: Thanks for the invite Steve. For this session I'll be mostly a listener.
[18:03] <cjwatson> slangasek: I didn't get it AFAICS
[18:03] <slangasek> https://plus.google.com/hangouts/_/7acpje7f3dnktlourn64tm45kg
[18:03] <cjwatson> oh, maybe on my phone, which is no use to me :)
[18:03] <slangasek> cjwatson: I guess I sent it to the wrong you, sorry :)
[18:03] <slangasek> should've gone to the canonical-you
[18:03] <cjwatson> ok - I'll be there in a sec, I'm just finishing updating my local emulator with some rapid use of 3G
[18:03] <cjwatson> :-)
[18:05] <zyga> hi
[18:05]  * rsalveti waves
[18:05] <karni> o/
[18:06]  * ogra_ shores
[18:09] <ogra_> video !
[18:09] <karni> You're live
[18:09] <rickspencer3> o/
[18:09] <xnox> and it's live!
[18:09] <ogra_> oh, and colin made his hair ... (he switched the cam on)
[18:10] <asac> :)
[18:10] <karni> the whole browser, yes
[18:10] <xnox> yes.
[18:10] <asac> yes
[18:11] <xnox> cjwatson: still browser.
[18:11] <lool> cjwatson: works well
[18:11] <zyga> cjwatson: it's hard to share that one
[18:11] <zyga> orks
[18:11] <zyga> works
[18:11] <xnox> cjwatson: awesome.
[18:11] <karni> good
[18:11] <lool> I see the browser
[18:11] <lool> I see my browser window with cjwatson inside
[18:11] <slangasek> it's working now - we sorted it out on the hangout rather than waiting for the IRC round-trip :)
[18:12] <slangasek> lool: you must be desynced
[18:12] <lool> I am, but I was trying to make a silly joke too
[18:12] <lool> it's all good now  :-)
[18:12] <karni> hehe
[18:12] <rsalveti> and graphics should be working with latest emulator :D
[18:12] <lool> hehe
[18:13] <karni> rsalveti: \o/
[18:13] <lool> rsalveti: is that with passthrough?
[18:13] <slangasek> yes
[18:14] <rsalveti> lool: yes, because we need opengles v2
[18:14] <ogra_> we do !!
[18:20] <zyga> is the child one can hear behind the scenes coming from the current speaker?
[18:20] <ogra_> yes
[18:20] <zyga> ah, ok
[18:21] <karni> yes, shell
[18:21] <zyga> yes
[18:21] <ogra_> yes
[18:21] <zyga> but very small
[18:21] <zyga> too small to be readable
[18:21] <xnox> cjwatson: yes, we do, but it's small font =))))
[18:21] <zyga> or un-maximize the window
[18:21] <rsalveti> still small?
[18:21] <karni> much better
[18:22] <rsalveti> don't know if it's the delay
[18:22] <xnox> cjwatson: awesome.
[18:22] <ogra_> yeah
[18:22] <zyga> cjwatson: google gives you roughly the same texture for any size of your screen
[18:22] <rsalveti> there's a huge delay
[18:24] <zyga> cool demo!
[18:25] <xnox> fingers crossed.
[18:25] <ogra_> cjwatson, it takes 10min
[18:25] <sergiusens> just be patient!
[18:26] <xnox> cjwatson: very slow emulated processor.
[18:26] <ogra_> 400MHz ... 512M
[18:26] <ogra_> single core
[18:26] <zyga> ogra_: what is that emulated with? qemu?
[18:26] <ogra_> yep
[18:26] <ogra_> a very old version
[18:27] <zyga> ogra_: graphics patches holding it back?
[18:27] <ogra_> well, its heavily patched for goldfish
[18:27] <zyga> I see
[18:27] <ogra_> not just graphics
[18:28] <zyga> ah, I see
[18:28]  * zyga mutters something about tizen / bada emulator ;)
[18:29] <zyga> can we run the emulator with a prebuilt image
[18:29] <zyga> that we can download from somewhere?
[18:29] <zyga> I tried it today in trusty but the package was broken
[18:29] <janimo> zyga, it worked for me in trusty today
[18:29] <sergiusens> if it confuses people, just don't launch with -shell
[18:29] <janimo> zyga, I used the build image script as documented
[18:29] <zyga> janimo: the script for building the image is broken
[18:30] <ogra_> worked fine for me
[18:30] <zyga> janimo: it references stuff that's not in the package
[18:30] <zyga> I was following the wiki basically
[18:30] <sergiusens> zyga, you might of downloaded an older wrong package
[18:30] <zyga> I can take it offline if you want to know what I did
[18:30] <ogra_> zyga, then you got the broken package
[18:30] <sergiusens> zyga, you need -0ubuntu2
[18:30] <janimo> zyga, I was lucky I guess :) I did not check what it actually does, but it made a working sd.img
[18:30] <zyga> sergiusens: nope, never installed that before
[18:30] <ogra_> which also breaks your host
[18:30] <lool> I was asking on teh wrong chanel blah
[18:30] <lool> QUESTION: do we need separate chroots for native builds and cross-builds due to multiarch deps still?
[18:30] <ogra_> (if it is amd64)
[18:30] <lool> I mean if I'm on trusty/amd64 and I want to a) cross-build to saucy/armhf and b) build for saucy/amd64, can I use a single chroot?
[18:30] <zyga> oh
[18:30]  * zyga checks
[18:30] <ogra_> lool, cjwatson cant see his IRC
[18:30] <zyga> darn
[18:30] <xnox> slangasek: ^ relay question to cjwatson from lool
[18:30] <zyga> yeah I have 2
[18:30] <zyga> er
[18:30] <zyga> 1
[18:30] <ogra_> probably someone can forward the question to the hangout
[18:31] <zyga> can I just upgrade now? I recall scary recovery instructions
[18:31] <rsalveti> zyga: yes, latest should be safe
[18:31] <zyga> ok
[18:31] <ogra_> zyga, just never ever remove libc6-amd64
[18:31] <sergiusens> cjwatson, rsalveti check if it's processing a crash
[18:31]  * zyga reboots rarely so proably breaks-on-boot would be a bad thing to do now
[18:31] <ogra_> (which the broken package pulled in)
[18:31] <zyga> ogra_: heh, ok :)
[18:32] <zyga> ogra_: oh
[18:32] <rsalveti> sergiusens: I disabled whoopsie for now
[18:32] <zyga> ogra_: -amd64 vs :amd64?
[18:32] <ogra_> zyga, right
[18:32] <sergiusens> rsalveti, yay :-)
[18:32] <ogra_> rsalveti, evil you ! how are we getting all these crach reports now
[18:32] <zyga> ogra_: is there a way to safely get rid of that somehow?
[18:32] <ogra_> zyga, once the bug in libc is fixed perhaps
[18:33] <ogra_> for now, just dont touch it
[18:33] <slangasek> zyga: to fix it, just boot with break=bottom, and copy your ld.so/libc back from the initramfs to the rootfs ;P
[18:33] <slangasek> piece of cake
[18:33] <rsalveti> ogra_: well, otherwise you're basically unable to use it
[18:33] <ogra_> lol
[18:33] <cjwatson> zyga: sorry, my children can be a bit noisy at times indeed ...
[18:33] <ogra_> rsalveti, details :P
[18:33] <lool> cjwatson: ok, thanks
[18:33] <slangasek> (this happened to me a few weeks ago while sprinting, but sadly I did not link this in any way to the emulator package)
[18:33] <zyga> thanks!
[18:34] <lool> cjwatson: it was no strong reason except limiting the number of chroots people needed (space, ability to download them etc.)
[18:34] <lool> time to update them etc.
[18:34]  * cjwatson nods
[18:35] <lool> I feel the pressure for fixing the content-hub hook is increasing
[18:35] <zyga> thanks, interesting demo
[18:35] <zyga> cjwatson: could you record a video with start-to-end (till it boots) and publish that sometime later? I would think many people would be interested
[18:36] <sergiusens> cjwatson, do you have a link to the chroot setup/building? I might have missed it if you did mention it
[18:36] <xnox> cjwatson: don't hit ctrl-c
[18:36] <xnox> =)
[18:36] <ogra_> lol
[18:36] <xnox> cjwatson: you can open adb shell
[18:37] <zyga> cool, sounds good for me
[18:37] <cjwatson> click chroot -aarmhf create (from lp:click at present, soon from the click-dev package)
[18:37] <zyga> cjwatson: don't disregard the tutorial nature of a complete video though
[18:37] <cjwatson> zyga: agreed
[18:37] <cjwatson> would need a bit more prep than this got :-)
[18:37] <zyga> :-)
[18:38] <sergiusens> great
[18:39] <cjwatson> thanks all
[18:40] <cjwatson> sorry for the not-quite-fully-in-place demo, but I hope you'll agree it was close :-)
[18:40] <karni> thanks all!
[18:40] <sergiusens> thanks
[18:40] <karni> cjwatson: it was close! :)
[18:40] <cjwatson> and thanks as ever to rsalveti for tireless work on the emulator
[18:40] <ogra_> ++
[18:40] <rsalveti> still a lot to do, but we're getting there :-)
[18:40] <cjwatson> and to xnox
[18:40] <ogra_> ++ too
[18:40] <karni> yes we are!
[18:40] <ogra_> :)
[18:41] <ogra_> it is intresting though, for me the emulator worked on first try and a lot sooner than yours
[18:41]  * cjwatson tries ctrl-c and re-running
[18:41] <cjwatson> oh, I forgot one thing, instructions on the emulator
[18:41]  * ogra_ thinks the graphics HW you use has also some impact 
[18:41] <cjwatson> https://wiki.ubuntu.com/Touch/Emulator
[18:42] <cjwatson> just make sure to use the very latest version in trusty
[18:43] <cjwatson> one thing this really highlights is the need to rewrite click in C, as all that Python is slow on first boot :-/
[18:44] <ogra_> yeah
[18:44] <cjwatson> ha!  unity is up now
[18:44] <ogra_> and there is whoopsie (which is currently disabled) and apparmor creating profiles on first nboot
[18:44] <rsalveti> \o/
[18:44] <ogra_> yay
[18:44] <cjwatson> I should have ctrl-ced during the presentation :-)
[18:45] <karni> cjwatson: :D
[18:45] <ogra_> ureadahead too ... we might want to disable that
[18:45] <cjwatson> or fix ... cf earlier discussions
[18:47] <cjwatson> http://people.canonical.com/~cjwatson/tmp/emulator-yay.png
[18:47] <cjwatson> (sorry, import -window root is a bit odd with multi-monitor)
[18:47] <rsalveti> yay
[18:48] <sergiusens> cjwatson, write it in go :-)
[18:48] <sergiusens> that's just a pun ;-)
[18:51] <karni> cjwatson: thanks for the screenshot!
[19:01] <slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
[19:03] <slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
[19:04] <slangasek> more people please join the hangout, this should be a discussion
[19:04] <slangasek> don't leave me all alone in here with the kernel guys
[19:05] <diwic> slangasek, ok, I'll try :-)
[19:06] <tjaalton> i'm thinking about it
[19:06] <tjaalton> but my wife has the laptop now :P
[19:07] <tjaalton> yup
[19:08] <tjaalton> maarten didn't reply to my pings
[19:10] <tjaalton> ok got the laptop, will take a while to set things up..
[19:11] <xnox> ogasawara: well at the moment upgrade fails, so one will fail to upgrade from -lts-saucy to quantal.
[19:11] <xnox> infinity: ^
[19:12] <xnox> are upgrades ever tested from all enablements to trusty?
[19:12] <xnox> including -lts-trusty -> trusty
[19:13] <slangasek> currently, none are tested
[19:14] <infinity> xnox: No, but we need to.
[19:14] <arges> do we test LTS dkms packages against all hwe-kernels?
[19:14] <slangasek> arges: are there any dkms packages that are in main?
[19:14] <ogasawara> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1244438
[19:15] <udsbotu> Launchpad bug 1244438 in linux (Ubuntu) "EOL notification system required for HWE kernels in LTSs" [Medium,Triaged] - Assigned to Ubuntu Kernel Team (ubuntu-kernel-team)
[19:15] <geofft> at some point I'd like to ask about OpenAFS, which is in universe and broke with the most recent HWE kernel
[19:16] <apw> geofft, what broke with it ?  did it fail to install or fail to work
[19:16] <arges> slangasek: or maybe more general do we have a good way for dkms packages to support multiple kernels? Is it just #ifdef'ing properly or doing things like this: https://launchpad.net/ubuntu/precise/+package/openvswitch-datapath-lts-raring-dkms
[19:17] <geofft> apw: The DKMS modules failed to compile, and we're not really sure about the process for getting fixes
[19:17] <apw> geofft, cirtainly filing a bug, if that is a universe package it is then best efforts
[19:18] <marrusl> I had a large customer opt-in to HWE kernels accidentally because when they moved forward with the project they grabbed "the latest iso"
[19:18] <marrusl> they were ok with it in the end, but they weren't clearly aware of what they were doing.
[19:18] <apw> marrusl, messaging could be better yes
[19:18] <slangasek> geofft: it's a suitable target for SRU
[19:18] <xnox> marrusl: 12.04.0 images are out there. the messaging on the ubuntu.com website is clear about hardware and non-hardware ennablement stacks.
[19:18] <geofft> apw, slangasek: LP #1206387
[19:18] <udsbotu> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387
[19:19] <slangasek> geofft: we would welcome community SRUs for such issues, but Canonical won't own the update of those packages as part of the HWE stack
[19:19] <geofft> I think one thing is we're not sure if we did the SRU process right -- who should be subscribed to these things, what do we need to do to push it forward?
[19:19] <marrusl> hey I understand, but it's still very confusing to end users.  this is a very large corp that we would have assumed "knew better" but they didn't.
[19:19] <slangasek> effectively, you need to get a package uploaded to the queue
[19:19] <geofft> Also it would be _wonderful_ if this didn't break on the day of the upload of a new point release
[19:20] <slangasek> sponsored or otherwise
[19:20] <geofft> because we have users who will grab the new ISO, install, and then complain at us :-(
[19:20] <bjf> xnox, i don't know how you can claim that the messaging is clear .. http://www.ubuntu.com/download/server
[19:20] <geofft> and downgrading their enablement stack is a pain.
[19:21] <xnox> well on the bottom of "http://www.ubuntu.com/download/alternative-downloads" there mentioned about downloading image with "Precise stack" but that's not very clean =/
[19:21] <xnox> bjf: i don't think there was any on server pages.
[19:21] <xnox> slangasek: infinity: in the pool/*.deb
[19:22] <xnox> ?
[19:22] <bjf> xnox, so, you are assuming people know to go to the alternative downloads page and even on that page it is not clear
[19:23] <xnox> bjf: true. i somehow thought it was better explained, but i can't find it any more.
[19:23] <bjf> xnox, yes, you can go to "past releases and other flavours"
[19:23] <xnox> bjf: i think we need more explanation text right next to "download" button.
[19:24] <xnox> ... and on cdimage.u.c
[19:24] <bjf> xnox, i agree with that
[19:24] <xnox> ..
[19:24] <xnox> cannot hear bryan.
[19:25] <apw> he was asking if we will upgrade people at the end of life for the pre-trusty lts-
[19:25] <apw> backport stacks, and that was a no, we would message them
[19:25] <xnox> thanks.
[19:29] <marrusl> I have a feeling this won't be a popular idea... but I have multiple customers that would LOVE to see the HWE stack extended to networking.  specifically:  network-manager, modemmanager, wpasupplicant, and usb-modeswitch.
[19:30] <marrusl> (I have a feeling that NM deps will make this a big pain)
[19:30] <diwic> seems nobody wanted to hear about the audio stack perspective, or my mic was muted?
[19:30] <slangasek> marrusl: I don't see why we would make that part of the HWE stack, instead of simple standalone SRUs that nobody gets
[19:30] <infinity> marrusl: Too late, session over.  La la.
[19:30] <slangasek> diwic: oh - yes, you were muted!
[19:30] <slangasek> diwic: sorry :/
[19:30] <arges> diwic: your mic was muted
[19:30] <marrusl> meh
[19:31] <slangasek> diwic: wondered why you were so quiet the whole time... :)
[19:31] <diwic> anyway; so for PulseAudio we decided not to try to do enablement stack stuff
[19:31] <infinity> slangasek: s/that nobody gets/that everybody gets/?
[19:31] <slangasek> infinity: yes, the inverse nobody
[19:31] <diwic> and I think this has been working well enough to continue that for the next two years
[19:31] <slangasek> ok
[19:31] <diwic> compared to trying to backport PulseAudio
[19:32] <slangasek> so you agree with the "it worked last time, let's keep doing it"
[19:32] <marrusl> slangasek, ok interesting.  wpa and usbmodeswitch backport cleanly (iirc) to precise, but I gave up on NM (was way over my head)
[19:32] <diwic> I've had one or two patches I had to SRU into PulseAudio to make it benefit from newer kernels, but that's it
[19:32] <infinity> marrusl: Does NM actually provide new hardware support, or just shiny new features?
[19:32] <slangasek> marrusl: ah, I think I missed NM in your list.  Yeah, I don't think we would take that, in *either* kind of update
[19:32] <infinity> marrusl: The point of HWE isn't to backport the world to the LTS.
[19:32] <tjaalton> guess I missed the important bits while stealing my laptop :)
[19:32]  * slangasek nods
[19:33] <diwic> slangasek, so yes, I think we can continue with "cautious SRUing" for PulseAudio 14.04 too
[19:33] <apw> sounds has been pretty good in precise i think, so that sounds like a sane plan
[19:33] <marrusl> infinity, in effect it does...  mobile broadband cards are poorly standardized and one customer has found (working with upstream) that:
[19:33] <infinity> tjaalton:  [adconrad] delegate someone in X to do meta packages for X stack if possible
[19:33] <marrusl> sometimes they need to make a fix in modemmanager, sometimes it's in NM.
[19:33] <infinity> tjaalton: Can I delegate that to you after explaining what it means? :P
[19:33] <tjaalton> infinity: yeah I got that part
[19:34] <tjaalton> and understand what it means
[19:34] <marrusl> in the case of WPA you may be using new network geat/features that work flawlessly on wpa 1.0 (for example) and quite poorly on 0.7.3.
[19:34] <infinity> tjaalton: Excellent.  tjaalton on launchpad too?
[19:34] <tjaalton> yes
[19:34] <diwic> and the other point, tjaalton et al, we should probably sit down on our HWE sprint and have a meeting about how this will affect all our pre-installs when their kernels go out of scope. See what we can do if they're running OSP1 and/or OSP2
[19:34] <marrusl> s/geat/gear
[19:35] <tjaalton> diwic: migrating machines from stack-to-stack?
[19:35] <tjaalton> oh
[19:36] <diwic> tjaalton, essentially; everything we've been enabling this year, e g all the Haswell machines, what will happen when the kernel team stops supporting 3.5
[19:36] <gQuigs> xnox: heh.. on another note;  did we ever get data to know if we made right call re:64 bitdefault
[19:37] <tjaalton> diwic: yeah, falls under the third paragraph of the notes
[19:37] <tjaalton> actually
[19:37] <xnox> gQuigs: not yet, no. At release day, there was more people downloading 64-bit images. And i'm yet to hear a failure case "64-bit one didn't work on my machine"
[19:38] <tjaalton> I remember they should be migrated to the next LTS stack, ie. one that'll be in 12.04.5
[19:38] <tjaalton> so that 12.10 will be maintained three extra monts until this is available
[19:38] <tjaalton> rtg: ^ am I right?
[19:38] <gQuigs> xnox: yea I haven't seen any complaints either
[19:39] <diwic> tjaalton, given the user base I guess that's better than starting to ask questions
[19:39] <tjaalton> this was discussed in oakland and/or copenhagen
[19:39] <slangasek> geofft: so https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1206387 does not have the ubuntu-sponsors team subscribed; would you like me to subscribe them?
[19:39] <udsbotu> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed]
[19:39] <infinity> tjaalton: No one will be automatically migrated, but we'll be telling them all about their support status in motd/update-manager/lists/etc.
[19:40] <slangasek> geofft: also, can I suggest that you coordinate directly with infinity and/or the kernel team for pre-release testing of the hwe stacks for dkms compatibility?
[19:40] <tjaalton> infinity: ok, works for me
[19:40] <diwic> infinity, so I typically think that's a bad thing to do for a lot of pre-installs, but the question if the regression risk of moving along will be a worse thing
[19:41] <geofft> slangasek: if that's the next step, yes please! I didn't file this bug but I _thought_ we'd followed the SRU wiki page; if we missed a step, sure and apologies
[19:41] <infinity> diwic: I think it's a bad thing too, as does the kernel team, but we've pretty much been told we can't forcefully upgrade people.
[19:41] <gQuigs> wait how much time will people have to upgrade from a HWE kernel?
[19:41] <bjf> tjaalton, yes we will support the kernels until 14.04.1
[19:41] <tjaalton> right this can't be just a thing baked in update-manager
[19:41] <diwic> infinity, just FTR, told by who?
[19:41] <infinity> ogasawara: ^
[19:41] <tjaalton> there needs to be some apt-get'ty way to migrate
[19:41] <infinity> ogasawara: Who told us we can't force people to migrate?
[19:42] <bjf> infinity, mark
[19:42] <tjaalton> bjf: good
[19:42] <infinity> tjaalton: The apt-gety way to migrate is simple.
[19:42] <ogasawara> infinity: sabdfl
[19:42] <tjaalton> infinity: ok then
[19:42] <diwic> ok
[19:42] <geofft> slangasek: hm, or, is that the upload lfaraone already did?
[19:42] <diwic> question is if sabdfl's statement applies to preinstalls too, and the reasoning behind it
[19:43] <slangasek> geofft: oh, yes, it's in the queue as of 44 hours ago ;)
[19:43] <diwic> tjaalton, but anyway I'll write to YK and tell him to have this as a topic during the hwe sprint
[19:43] <infinity> diwic: I don't see why we'd treat preinstalls as unique snowflakes compared to end-user installs.
[19:44] <infinity> diwic: The end result is the same if you preinstalled or user-installed with a 3.5/3.8/3.11 kernel, after all.
[19:44] <tjaalton> yeah osp1 is 12.04.2+steroids, osp2 will be 12.04.3+viagra.. still the same tooling applies
[19:45] <geofft> slangasek: It seems like we didn't get any feedback here, so I'm curious what could have been done to get this bug a response better -- it was ready for action 3 months ago, I think.
[19:45] <diwic> tjaalton, osp2 = 12.04.4 based
[19:45] <ogasawara> diwic: so I did have follow on conversations w/smagoun and jonm where they voiced they had cases where they would want to automatically roll forward when a stack EOL's, so my team created meta packages which could be installed to do so
[19:45] <slangasek> geofft: response from whom?
[19:45] <tjaalton> diwic: oh right
[19:46] <slangasek> geofft: as I said, Canonical isn't going to own updates for universe dkms packages that break - but we welcome community involvement in vetting those
[19:46] <diwic> ogasawara, and so the question is if these are the packages we use in osp1/osp2 ?
[19:46] <geofft> I... don't actually know. What would have been the right steps for we-the-community to take after andersk's 2013-08-26 posting of a debdiff?
[19:46] <tjaalton> diwic: it's an extra package, the oem is free to install it aiui
[19:46] <tjaalton> if they wish auto-migration
[19:47] <ogasawara> diwic: I unfortunately don't know.  I'm not aware of what's in those osp1/osp2 deliverables
[19:47] <geofft> (Partly this is a special case because there was a question of, can we just take the latest upstream point release instead of backporting patches)
[19:47] <infinity> geofft: subscribing ubuntu-sponsors (or finding someone to review and upload) would have helped.
[19:47] <tjaalton> just a bunch of dkms backports..
[19:47] <diwic> ogasawara, I don't know either, but I know who can figure out at least
[19:51] <geofft> slangasek, infinity: Re pre-release testing for dkms in universe, let me see if I can try to find someone current from MIT to have this conversation
[19:51] <slangasek> ok
[19:51] <geofft> I graduated and don't personally care as much about OpenAFS any more, so I'll try to find someone better-placed to do it, but if not, I guess I'll email infinity + the kernel mailing list?
[19:52] <geofft> infinity: wasn't ubuntu-sponsors subscribed right after the debdiff was posted?
[19:53] <infinity> geofft: Oh, so it was, according to the bug log.  I was just going by what slangasek said above.
[19:54] <geofft> I think lfaraone unsubscribed ubuntu-sponsors last week after uploading
[19:54] <andersk> Hi guys, I wrote and posted the debdiff in question.
[19:55] <geofft> I'd like to know how to make this go better in the future, since this is not the last time OpenAFS will fail to compile on a new kernel.
[19:55] <geofft> (should we move to another channel?)
[19:56] <andersk> And yeah, I subscribed ubuntu-sponsors, updated the bug description with SRU information, and eventually found and poked lfaraone to make a (still unapproved) upload.	If there’s anything else I can do to help, I’d like to know.
[19:57] <infinity> Right, this session's officially ended, I'm jumping ship from this channel...