#ubuntu-uds-core-2 2013-11-19
<cjohnston> asac can you please op me in both -core- channels
<slangasek> https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo
<stgraber> slangasek: can I get the URL? (I don't think I've got a whole lo to say though, just personal interest as I had to deal with that mess all too often)
<cjohnston> tsimpson-uds: ping
<slangasek> stgraber: https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo
<xnox> blueprint URL: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-dmraid2mdadm
<xnox> pad URL: http://pad.ubuntu.com/uds-1311-core-1311-dmraid2mdadm
<tsimpson-uds> cjohnston: \o
<cjohnston> tsimpson-uds: do you run udsbot ?
<tsimpson-uds> yep
<cjohnston> tsimpson-uds: can you please have it join -core-1 -core-2 and -design-1
<tsimpson-uds> cjohnston: I can, but it won't do much without some chanserv magic
<cjohnston> tsimpson-uds: I did it in -design-1 I'm waiting to do it in here
<asac> cjohnston: let me know iif its good
<slangasek> "Almost British"> lol
<cjohnston> ta
<asac> anyone else?
<cjohnston> nope
<apw> xnox, you are visible here
<arges-uds> is the video live
<apw> arges-uds, t'is for me
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Transitioning to use MDADM by default for some of the FakeRAID devices | Url: http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/
<apw> smb, i assume it does not work at all righ
<apw> smb, i assume it does not work at all right now even, so someone has to fix it if we can
<apw> dm_raid45              76611  0
<apw> it seems to be loaded on my non dm-raid45 system
<stgraber> that's unfortunate, would have been nice to get some stats...
<apw> stgraber, stick a work-item on us to figure out if we can tell, it maybe i have done something odd on this system to make this occur
<smb> apw, Do you have dmraid installed
<smb> (the user-space)
<apw> smb, i would assume so indeed
<apw> smb, yes i do
<apw> (the userspace)
<apw> so it maybe triggered by that, so as i say, lets get a WI to investigate if we can mine launchpad bugs for S to get stats or not
<cjwatson> indeed, on server images dmraid should generally only be installed if dmraid is actually in use
<cjwatson> I suspect kernel engineers are outliers :-)
<apw> (yeah as i say assume it is me fiddling on this issue which has gotten me here)
<apw> and lets investigate
 * apw sends some large vicious looking people to visit with xnox
<xnox> cjwatson: thanks.
<xnox> apw: =))))
<xnox> apw: if they come with harddrives and motherboards that's fine.
<apw> xnox, doesn't that depend if the failure mode is "not boot" or "eats my data"
<apw> smb, are you going to be investigating if you can back the old userspace with the builtin mdadm targets instead ?
<smb> apw, that might be a plan b I guess
<cjwatson> I suspect that the grub2 transition should not be regarded as a model here
<smb> hm better than not working
<apw> smb, if it makes sense, maybe we should at least evaluate it
<smb> apw, agree
<arges-uds> Are there going to kernel config changes? or will dm raid still be built as modules?
<xnox> arges-uds: still build modules by the looks of it for dm-raid.
<apw> arges-uds, that will depend if we are able to map the dmraid userspace to the new ones
<smb> arges-uds, there is dm-raid and dm-raid45
<smb> the latter is the special one we want to drop
<arges-uds> ok gotcha
<arges-uds> now finally get the video response
<arges-uds> : )
<xnox> cjwatson: so far I have been told to do a clean switchover, without a fallback (for intel raids, and ddf)
<apw> there is quite some lag, not the 7s jono suggested
<slangasek> how much?
<apw> xnox, there is a middle case, were might be able to back the dmraid (non-intel) using 'dm raid' not 'dm raid4-5' on the kernel side
<apw> slangasek, feels more like 30s at least
<slangasek> hmm :/
<slangasek> lag on IRC> yes, people should just join the hangout instead :)
<apw> i suspect the lag is proporionate to the distanve between the originator and viewer
<apw> slangasek, heh, maybe so but they are doing just fine over there
<stgraber> we definitely still have room in the hangout, so just join :)
<apw> xnox, we have a WI for that now already
<apw> smb, only need that if we have to move people up to 14.04 on 12.04 and that breaks them
<smb> apw, ERrm /me fails to parse
<cjwatson> well ... if people aren't used to having to use UUIDs by now ...
<cjwatson> but yeah, a quick safety check wouldn't hurt
<apw> 14.04 will replace all the lts-backport kernels on 12.04
<cjwatson> xnox: I wouldn't say it happened without *any* bugs :-)
<apw> we need to not break that
<cjwatson> But they should be shaken out by now, given it was, er, edgy or so?
<smb> apw, Ah ok... So if t kernel has no dm-raid45 we have to backport the new dmraid (or partions of)
<apw> smb, that indeed
<apw> so it might be easier to make dm-raid45 work here you never know
 * smb grubles
<apw> not that we shouldn't migrate people non the less on real 14.04 regardless
<xnox> cjwatson: =)))) you are the first one to mention there actually were bugs with that upgrade. (/dev/sda1->UUID)
<apw> smb, for us to discuss now we know the issues
<smb> yup
 * apw likes the idea of mapping over, if that works on all kernels back to P's on P
 * apw slaps self for rath
 * apw slaps self for ratholing
<cjwatson> xnox: Don't get me wrong, considering its complexity it went remarkably well
<xnox> ok.
<apw> smb, yeah we should likely only have the module enabled in the lts-backport-trusty and _not_ in the real 14.04 kernel
<apw> if we are forced to have it for that kernel
<apw> (the module == dmraid4-5)
<apw> to prevent 14.04 having the same problem
<apw> slangasek, we normally do them 3-4 weeks after, but not recommending htem to the first point release
<slangasek> ok
<slangasek> ah, actually 15 minutes to the next session
<smb> Great, enough time to go downstairs to the coffee machine
<pitti> slangasek: are you driving the TRIM hangout?
<slangasek> pitti: ogasawara is
<pitti> ogasawara: probably easiest to just put the URL here?
<ogasawara> pitti: you have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Enable automatic trimming of SSD drives | Url: http://summit.ubuntu.com/uds-1311/meeting/21974/core-1311-ssd-trimming/
<ogasawara> stgraber: https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en
<pitti> stgraber, ogra_, xnox: ^ if you want to join
<ogra_> pitti, i cant, running the bootsplash session myself next door
<pitti> ogra_: just FYI, not critical
<xnox> pitti: i'm joining encryption session.
<xnox> pitti: i think we are mostly aligned on the topic - i.e. cron it.
<pitti> xnox: ack, thanks
<arges> i can see video
<chiluk> so I disagree with using fstrim
<chiluk> I think we should be using discard.
<chiluk> from the benchmarks I've seen that discard does not actually trim in real time, but marks blocks for later trimming
<chiluk>  https://patrick-nagel.net/blog/archives/337
<chiluk> apw we the statistics I see are that discard does not affect writes because of caching in the vfs layer
<apw> chiluk, come join
<xnox> all other core sessions finished =)
<xnox> o/
<xnox> terrible lag on the video
<stgraber> xnox: so I think slangasek expressed an interest for that mountall workitem in the past, so it's probably worth discussing this with him
<stgraber> xnox: basically the plan is to have mountall remount any mounted fs where the existing flags don't match what's listed in /etc/fstab
<chiluk> I just realized something.
<xnox> stgraber: why wouldn't they?
<stgraber> xnox: and in the case of /, we'd want to only do a single remount, so have any missing flag added at the same time we remount it rw
<xnox> stgraber: mountall reads /etc/fstab in the initramfs case.
<chiluk> for phone it may be beneficial to only run fstrim when plugged in
<chiluk> pitti, ^^
<stgraber> xnox: I believe we at least had the case of /dev/pts not having matching mount options and that's what triggered that discussion originally
<pitti> chiluk: same for laptop actually, but it's a trade off
<pitti> chiluk: you could easily miss a few cron cycles if you mostly run on battery
<chiluk> I still like discard better for normal use.
<xnox> stgraber: it was non-matching in initramfs-less case as I far as I remember (and hence things breaking for infinity and his powerpc machines), but yeah in the initramfs-less case /root will have wrong/non-matching flags.
<stgraber> chiluk: well, phones will run with discard, so fstrim will be a very fast noop there anyway
<pitti> chiluk: and of course we cannot control this at all with discard, which we already agreed to on the phone..
<stgraber> xnox: ah yeah, that could have been.
<xnox> stgraber: pitti: did you agree for discard mount option on the desktop as well ?
<stgraber> xnox: no, we agreed on it for the phone. For desktop it's pending benchmarking by cking
<xnox> stgraber: ok. cool.
<pitti> xnox: right; chiluk brought up that it might not actually be synchronous any more on current kernels
<xnox> pitti: nice =)
<chiluk> yeah I'm fairly certain the discards get cached in the vfs like everything else.
<chiluk> at least that's what the benchmarks I've seen imply.
<pitti> chiluk: still a bit sceptical; http://goo.gl/1mdjzl benchmarks show 25% penalty on a "compile" test case
<pitti> (which would create and remove lots of small temp files)
<pitti> but then again I don't trust this benchmark much
<pitti> many numbers are very implausible
<xnox> pitti: what are typical phone usage patters? write only, delete occasionally.
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html
<pitti> xnox: yeah, deletion mostly for downloads/browsing, I suppose
<xnox> right, all the media / streaming caches.
<pitti> xnox: but in general you write a lot less on the phone, so keeping it "always clean" on small file systems which are mostly full is the more pressing concern there
<xnox> pitti: well, my laptop is ssd and I'm using "discard" mount option, and I haven't tried / compared with cronned fstrim.
<pitti> xnox: that's the kind of benchmark we want to do
<xnox> so far i am happy, but it is nowhere near full (disk uage)
<pitti> xnox: i. e. delete with lots of little, and a big file, with and without discard
<pitti> the discard overhead shouldn't really depend on how full the fs is?
<pitti> the "do it once a week" performance certainly does
<ogra_> if you measure this on a phone, please take wakeups and battery usage into account
<ogra_> thats my only concern about doing it cronned
<pitti> ogra_: that woudl rather be my concern about doing "discard", but yes
<pitti> ogra_: but the summed workload should be the same
<ogra_> well, indeed, if discard can cause wakeups in sleep state that would be bad
<pitti> in the end you need to trim all deleted blocks, either in one big chunk or in lots of little steps
<ogra_> i#m specifically talking about waking up from suspend to run the cron job
<pitti> ogra_: no, it's pretty much tied to removing, which is already keeping the process and drive awake
<ogra_> if the device is fully on thats a no brainer
<pitti> ogra_: but on the phone we already decided for "discard" anyway for other reasons
<pitti> ogra_: the benchmark/question is only about desktops at this point
<ogra_> on arm the system can simply wake only parts of the peripherial devices ... if cron kicks in (the clock is always on on arm) it might cause a wakeup on the lower system level to just do the removing
<ogra_> ah, k
<ogra_> (sorry, didnt follow the session, if discard is set by default thats fine)
<slangasek> stgraber, xnox: mountall> there's an open bug report on mountall about this
<pitti> can't find ^ right now
<pitti> I looked at some with plausible titles, but they sounded different
<jderose> is this the correct room for "Enable automatic trimming of SSD drives"?
<ogra_> jderose, it was ... for the last hour
<pitti> jderose: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming has the session notes and WIs
<jderose> ah, oops, guess i'm watching the recording :P
<jderose> pitti: FYI, System76 has been working toward enabling discard on imaging time. in our experience, on modern SSDs, there is very little overhead to discard. deletes are slower, but deletes are extremely fast anyway. So personally, we're leaning toward discard over cron + fstrim
<jderose> although on some older ssds, discard is very expensive
<jderose> (some anyway)
<xnox> jderose: cool, thanks for input.
<pitti> jderose: thanks
<xnox> jderose: i believe discard is now available in d-i, thus one can preseed discard already today, i think.
<pitti> xnox, stgraber, chiluk: something crossed my mind: on upgrades, when we alter fstab, we should probably call fstrim once
<jderose> xnox: gotcha, but we don't need it. we have very flexible imaging software :)
<pitti> otherwise we won't trim the already existing free blocks, just the future ones
<pitti> ^ added to BP
<stgraber> pitti: yep, that makes sense
<xnox> pitti: well one wants to run fstrim on first reboot once the file system is mounted with discard.
<pitti> xnox: self-destroying upstart job? (eww)
<pitti> xnox: perhaps better let the cron job do that?
<xnox> jderose: is it open sourced?
<jderose> i'm still listening to the recording, but this point was just raised: that using discard can be a better choice when an ssd in fairly full, so that you don't have inconsistent performance (degrading performance through the week till fstrim is run). this is another reason that System76 is leading toward discard
<xnox> pitti: hm. well we can leave a flag file (similar to reboot flag) and clear it once we successfully fstrimmed.
<pitti> xnox: right; the cron job could watch for that?
<jderose> xnox: no, it's not. i'm not the man who writes the paychecks, not my call :P
<xnox> pitti: yeah, and it would be @reboot type of job.
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Cgroup manager for LXC | Url: http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/
<cjwatson> xnox: discard> well - except that when I tried to SRU-QA that I found that it was broken
<cjwatson> xnox: I've been waiting for git.d.o to come back so that I can check whether it's fixed in Debian and if not fix it there
<cjwatson> (It's definitely on my plate)
<xnox> cjwatson: well mjt wrote a perl script to re-assembled the raid array, so all data is restored. last time I looked it was getting rsynced to a new VM.
<xnox> (literarly looking up bad blocks from the kicked out drive and doing writes)
<cjwatson> xnox: Yeah, I'm following #alioth too :-)
<xnox> cjwatson: s/git.debian.org/moszumanska.debian.org/ fetches d-i repositories for me =)
<cjwatson> xnox: I'm not touching the new host (even "read-only", which will probably in practice generate some writes) until they say it's OK, in case I disturb the recovery process
<cjwatson> I'd advise doing the same ...
<xnox> ok.
<chiluk> pitti, that makes sense, although you need to be careful on which side of the reboot that happens
<stgraber> slangasek, ogasawara: which of you is start the hangout?
<stgraber> *starting
<ogasawara> stgraber: slangasek is
<cjwatson> Even though I am itching to push stuff
<slangasek> https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas
<pitti> stgraber: would this by any chance be compatible to systemd's cgroup handler/service? that would unblock us being stuck at v204 (and at any rate, with this we would need to port logind 204 to that new service)
<depp> systemd's cgroup implementation is perfectly stackable
<depp> systemd runs fine inside of containers
<pitti> stgraber: ^ I added notes to the pad
<depp> so, you haven't looked at the api but claim it "wasn't flexible" enough?
<depp> are you aware that libcgroup is not maintained anymore upstream at RH?
<hallyn_> depp: yes, we are.  the cgroup daemon in libcgroup was unworkably racy
<depp> hallyn_: and now you want to make use of libcgroup nonetheless?
<depp> are you aware that dbus just uses a UNIX socket too? you could just create one of those and mount it into the container, too
<apw> depp, you should join the hangout
<slangasek> https://plus.google.com/hangouts/_/7acpi4r23mt7tv2v3j70q8bhas
<xnox> ..
<hallyn_> depp: only of some of the userspace commands, and we're not sure.  actually lmctfy is what i was going to leverage
<xnox> dbus supports starting private socket. and let your apps talk to you via private socket.
<xnox> ..
<xnox> without actually having a session/system dbus.
<xnox> ..
<depp> upstart itself even uses a private dbus socket...
<xnox> even an annonymous one.
<depp> are you aware that there are no real linux implementations that could run inside a container that doesn't come with libdbus anyway?
<depp> because dbus is based on unix sockets, it can do *anything* unix sockets can do, as good and well as any other IPC...
<stgraber> depp: I have a whole lot of users running minimal busybox based environment who'd beg to differ
<pitti> stgraber: you want to have cgroup management tools in that environment, but not libdbus?
<slangasek> pitti: I don't think that's the argument
<apw> pitti, he wants to be able to pass it into a container, and that pass it to a second container which consumes it, without the intermediate needing anything including libdbus
<pitti> stgraber: but in either case, it seems that our systemd-shim could take the org.freedesktop.systemd1.StartTransientUnit call on D-BUS and translate it to our service, so we'd be back to being compatible
<depp> sooo, you want to come to a conclusion here, admit that you have neither looked at systemd's cgroup stuff, nor on the google thing, do not have any idea about dbus? how's that going to work?
<pitti> apw: ack
<stgraber> pitti: yes, that's what I suggested earlier, having a small dbus service that just wraps our generic API to systemd's, then logind could just use that
<pitti> stgraber: right, we have that already for suspend/reboot/etc.
<pitti> stgraber: great
<pitti> meh, pad seems down
<slangasek> yep :/
 * apw pokes people
<hallyn_> depp: have looked at lmctfy;  systemd has told us at plumbers directly that only one pid on host should control cgroups.  please write more concisely what exactly you're advocating for.  we're just gathering reuirements and options here.
<hallyn_> (last time i looked deeply into dbus, it had a bad bug in how it passed lsm creds;  fixed that, but it did not inspire confidence)
<slangasek> hallyn_: if we're using a private socket, should all be fine
<hallyn_> slangasek: yeah i'm pretty sure i followed up at the time (2010) to get the bug fixed :)
<slangasek> heh
<depp> what about devices that come and go, whose major/minor need to be updated in the cgroup properties? afaik google doesn't do dynamic devices...
<depp> what about propagation between groups? any thoughts on that?
<slangasek> depp: I don't understand your question.  the major/minor of any given device is fixed, even if the device node comes and goes; the only exception to this is within containers themselves, where lxc diverts console devices
<depp> slangasek: the major/minor changes on each plug, you cannot use it for configuration
<slangasek> the major/minor changes only if the device name also changes
<hallyn_> that's related to what Michael Warfield is working on for lxc.
<depp> slangasek: that is non-sense, sorry, that's now how it works. the kernel just allocates the lowest free minor for most devices these days
<slangasek> yes, and the device *name* reflects the major/minor
<hallyn_> (well that dpeends on udev rules :)
<slangasek> but if the concern is for devices that don't have persistent names, then sure, that's back to what hallyn_ says that Michael is working on this
<pitti> hallyn_: no, udev rules don't set/change device names
<hallyn_> pitti: they soon might :)
<pitti> hallyn_: ??
<hallyn_> pitti: udev rules may fire and link devices into /dev/.lxc/$container
<hallyn_> pitti: that's part of what Michael is working on
<pitti> hallyn_: well, links, yes, but not names; the kernel defines device names
<hallyn_> pitti: eh, the kernel wants to tell me that it defines devices names but that i can't rely on them.  so i don't care :)
<pitti> hallyn_: the "rely" part are persistent symlinks :) (and we've had them for ages)
<pitti> but yes, in general device names are pretty uninteresting in most cases
<pitti> (for storage, USB, etc.)
<hallyn_> pitti: the specific problem Michael has is a 4-port (or so) serial board,
<hallyn_> where the specific ports are randomly assigned at boot, apparently
<hallyn_> lunch - \o
<pitti> lunch, too; thanks guys!
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Discuss reconciling the Qt requirements for Ubuntu vs. Kubuntu | Url: http://summit.ubuntu.com/uds-1311/meeting/21986/core-1311-qt5-versions-in-ubuntu/
<janimo> no video yet for the Qt session?
<Mirv> shoud be in 1min (starts :05), but no idea yet
 * sil2100 is waiting as well
<slangasek> https://plus.google.com/hangouts/_/72cpjem29pg1ifaht4etlvkqc0
<slangasek> come one, come all
<Mirv> Kubuntu people?
<pmcgowan> proposal is Qt 5.2
<Mirv> Saviq: joining?
<sil2100> Saviq: ping! Can you join?
<greyback> updated Qt version does not break public API or ABI, only the private stuff
<mzanetti> Mirv: unity uses some internal headers from qtdeclarative. not too much but we have a couple of patches to do on every upgrade.
<rsalveti> greyback: only private in the 5.x series?
<greyback> rsalveti: yes. There's no api guarantee with private stuff. But public has
<rsalveti> right, then we need to reduce that
<Mirv> mzanetti: ah, ok
<Mirv> and sorry, the hangout toolbox not starting for me so I don't have a name tag
<sergiusens> slangasek, add an action item to add the action item on the other session :-)
 * sergiusens jokes
<xnox> sergiusens: -EJOKERAISED
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html
#ubuntu-uds-core-2 2013-11-20
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-2.html
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Improve the cross-compilation story for Ubuntu Touch by 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21991/core-1311-cross-compilation/
<slangasek> https://plus.google.com/hangouts/_/7ecpj1uhgvnl346mfisfouopu0
<dholbach> did anyone press the "go live" button already? :)
<slangasek> no
<apw> feels like not here
<slangasek> we're missing doko, trying to decide if it's worth having the session for :)
<pitti> slangasek: he pinged me half an hour ago, he's on crappy mobile network
<slangasek> ok
<pitti> not good enough for hangouts
<slangasek> not even audio?
<pitti> I don't know
<pitti> he said "let's see.."
<apw> slangasek, we can see you
<pmcgowan> hear you
<Saviq> \o/
<pbass> we see you
 * xnox runs off to find my 2fa token.
<doko> slangasek, I'm online, lets see how this works out ...
<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
<apw> xnox, is there any reason mako cannot use v4.6 as well if that is what is upstream
<apw> xnox, we probabally only use that because v4.8 didn't work, and v4.7 did
<cjwatson> There's already a 4.7 cross stack in the archive, so no reason to take that backward
<apw> ok
<cjwatson> gcc-4.7-arm-linux-gnueabihf - GNU C compiler
<asac> do we know why they kept going with 4.6 on kernels?
<asac> (dont need to address in hangout, just question for channel)
<xnox> asac: e.g. goldfish gives kernel panic before it completes boot, when compiled with 4.7 or 4.8.
<ogra_> i think maguro too
<asac> right. but i am sure google could have fixed that easily if there were no other reasons for staying on 4.6
<apw> slangasek, can you add a WI for me to make that switch where needed
<xnox> at the moment: all nexus kernels use 4.6, mako uses 4.7.
<xnox> apw: done.
<asac> e.g. i believe there might be good reasons... in particular if they use 4.7 for the userspace
<slangasek> apw: which switch? to libiberty
<asac> xnox: do they use 4.7 in userspace? or even 4.4?
<ogra_> asac, 4.6
<xnox> asac: haven't checked recently, I believe there was a newer toolchain for kitkat, in user-space only.
<xnox> asac: pre-kitkat is 4.6
<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?
<asac> cjwatson: slangasek: talking about cross compiling kernels... any thoughts about allowing to cross compile kernels in PPAs?
<ogra_> asac, for what ? to save 20min ?
<lool> why dont I get a live stream of this session
<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
<asac> right
<ogra_> lool, i do
<lool> odd
<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
<lool> maybe I have too many streams open
<doko> is there a way to turn off video in hangouts?
<cjwatson> yes, there's a camera icon at the top that you can click
<ogra_> doko, click the camera icon
<cjwatson> or do you mean everyone else's video?
<doko> the latter
<pitti> turn bandwith usage down
<ogra_> yeah
<asac> lool: your computer doesnt like anything related to video streams... no hangouts, no yuoutube :)
<pitti> in the "signal strenght" like slider
<asac> etc.
<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
<lool> asac: :-)  actually it was due to too many streams open (was trying to follow two other sessions)
 * asac wonders how lool can listen to multiple streams
<asac> i can imagine two ... one for each ear
<asac> everything else must also be hard for you to process
<asac> hehe
<ogra_> asac, 5:1 dolby surround ...
<ogra_> 6 channels ;)
<cjwatson> ogra_: I don't think highbank can, I think we're waiting for next-gen (A57 or similar)
<ogra_> ah, ok
<ogra_> i still think we should wait
<ogra_> instead of having to maintain an artificially made up list
<lool> asac: mute everything and listen i n2 minutes chunks  :-)
<rsalveti> xnox: I believe kitkat should be using 4.7/4.8
<cjwatson> I indeed don't think that a whitelist (or even blacklist) is a scaleable approach
<rsalveti> but the kernel is still using that very old toolchain
<ogra_> rsalveti, even the N5 one ?
<rsalveti> ogra_: sorry, was thinking about the goldfish target (the one requiring 4.6)
<ogra_> ah, good
<ogra_> would be odd if hammerhead still used such an old kernel
<pmcgowan> sounds good
<mzanetti> I think app development would be mostly qmake
<apw> did we just lose the feed, or si that me
<mzanetti> apw: works here
<mardy> and QBS! :-)
<sergiusens> shouldn't the sdk should default to cmake for ubutnu touch projects?
<mzanetti> thing is, qtcreator generates everything qmake for you. cmake is completely manually
<cjwatson> qtcreator's under our control, at least partially
<apw> firefox crashage, yay ...
<mzanetti> cjwatson: well, we could extend qtcreator to properly support cmake, which sounds a lot to me tbh
<mzanetti> fine with me personally. but it's more complex for app developers.
<cjwatson> It might be more complex for the SDK team
<slangasek> right
<cjwatson> It should surely be invisible to app developers
<slangasek> the SDK should DTRT
<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
<cjwatson> (Unless they poke around at their build system)
<mzanetti> cjwatson: no. it's never completely visible to the developer.
<cjwatson> Is qmake == QBS?
<mzanetti> err. completely invisible
<mzanetti> QBS == QMake Build System
<mzanetti> the new thing to come soonish
<mardy> cjwatson: no, it's a new stuff, with a JSON/QML-like syntax
<mzanetti> err.. QML Build system
<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
<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
<Saviq> https://bugreports.qt-project.org/browse/QTBUG-29987
<mardy> cjwatson: makes sense
<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)
<dholbach> (qt4) and checkbox I think, but AFAIK that's being rewritten
<Saviq> qbs == Qt Build Suite apparently
<Saviq> http://qt-project.org/doc/qbs-1.1/index.html
<mardy> cjwatson: but not all the stack is built with cmake
<lool> cjwatson: and similarly we should start by cross-compiling the clicks that we include I guess
<cjwatson> mardy: not all the stack is built with any one system :-)
<cjwatson> mardy: so yes, I expect that fixing the whole stack will involve fixing multiple build systems
<cjwatson> lool: perhaps, yeah
<mardy> cjwatson: yep :-)
<lool> sergiusens: ^ FYI on cross-compilation topic, we're thinking of testing/dogfooding the cross-compilation story with the builds of the preinstalled click
<lool> s
<cjwatson> which of those are arch-dep right now?
<lool> at the moment we pull some prebuilt files from .debs
<lool> so the actual builds are not arch-specific, except for the armhf debs they download
<mzanetti> o/
<sergiusens> cjwatson, lool notes-app is the only one building that way
<sergiusens> it's cmake based
<lool> great
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Upstart Roadmap for 14.04 LTS release | Url: http://summit.ubuntu.com/uds-1311/meeting/21977/core-1311-upstart-roadmap/
<slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970
<slangasek> jodh: ^^
<stgraber> xnox: coming?
<zyga> live
 * slangasek waves
<zyga> jodh: what are the small projects?
 * xnox o/
<slangasek> https://plus.google.com/hangouts/_/7acpj036tlifqsdqh2tcf89970
<slangasek> I'm gonna keep repeating that until people join ;)
<zyga> slangasek: topic it
<zyga> what is the goal of using cgroups in upstart?
<xnox> zyga: resource control.
<slangasek> zyga: just like we support ulimits / chroot primitives, we should support cgroups
 * zyga needs to learn more about cgroups
<apw> why can we not move the process to the cgroups after, i thought you could shift runnign things
<apw> and if we have upstart running we have enough disk to make the cgroup mamanger startable directly rather than via a job
<slangasek> apw: what do you mean, "directly"?
<apw> slangasek, fork/exec it directly before parsing jobs
<slangasek> hmm
<apw> so it is part of upstart, but not killing upstart if it explodes
<zyga> there is one more case to consider, what it there are no cgroups at all (or they are disabled for any reason)
<zyga> the way cgroups are tied to jobs starting needs to address that
<apw> yeah what if the kernel has no cgroup support ...
<apw> slangasek, ^^
<zyga> but I agree that cgroup helper should be special so that state is consistent
<zyga> and that there are no arbitrary periods of time after a jobi started before its cgroup profile is applied
<zyga> s/i / is /
<zyga> time bridge would be fantastic
<zyga> "start 10 minutes after system-booted"
<zyga> system-booted is just a job name
<marrusl> killing stuck jobs. is that part of "refining ptrace handling" ?
<slangasek> zyga: "arbitrary periods of time" - well, the only way to do that is to delay the boot until the cgroup manager is started
<slangasek> marrusl: yes
<marrusl> I am so happy.
<zyga> slangasek: indeed
<zyga> slangasek: my point is that that arbitrary period feels bad from a design perspective
<gQuigs> and it would actually fix a bug that we don't know when to kill dbus which the X app exits over ssh
<gQuigs> this bug: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434
<udsbotu> Launchpad bug 592434 in dbus (Ubuntu) "ssh -X user@machine hangs when using exit to terminate" [Low,Triaged]
<gQuigs> re: track user SSH sessions ^
<zyga> slangasek: perhaps the alternative is to have a stanza that controls this
<zyga> slangasek: so for most jobs, that would be immediate, and blocking
<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)
<zyga> slangasek: like startup-SIGSTOP-cgroups-SIGCONT
<zyga> ^^ :D
<zyga> socket bridge is not optional
<zyga> cgropus can or can not be available and the job should not differ
 * zyga might join the session but doesn't feel like a system level engineer to speak up really
<zyga> jodh, slangasek, stgraber: ^^
<slangasek> zyga: please join ;)
<beidl> it has to be special cased because it provides the infrastructure for jobs
<apw> slangasek, i think i liked your statement there "it backs a stanza implementation"
<apw> "start on using_stanza_cgroups"
<apw> xnox, i think you want upstrart syntax for that  different words for optional and not
<apw> cgroup <stuff>
<apw> cgroup optional <stuff>
<mdeslaur> it's not something we need, it's something we'd be interested in looking at if it was available
<gQuigs> why ever depend on having swap?
<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
<apw> jodh, limits, can there not be a wrapper which applies those and used as an exec script prefix ?
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Secure Boot work for 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21978/core-1311-secure-boot/
<roadmr> oh that's today! yay
<cjwatson> Hangout URL?
<cjwatson> (Who's running the video?  slangasek I assume)
<slangasek> https://plus.google.com/hangouts/_/72cpj2k5dn4bjr053d5ehn1lpo
<slangasek> cjwatson: ^^
<apw> do we have a stream yet ?
<slangasek> yes
<rtg> not that we can see
<slangasek> hmm
<apw> white space for me
<slangasek> checking
<slangasek> oops, got the URLs backwards :P
<slangasek> fixed
<apw> slangasek, have it now
<slangasek> also, why are you people not joining the hangout ;)
<apw> is there any kernel work :)
<rtg> haven't combed my hair yet
 * apw has no hair
<cjwatson> that's what video-off is for
<apw> :)
<cjwatson> (actually I just don't want to deal with bw awfulness)
<slangasek> apw: do you want there to be?
<apw> slangasek, i normally listen till it sounds like one needs kernel input
<josepht> lower thirds please
<apw> "sitting in the second row"
<smoser> slangasek, link?
<apw> slangasek, often to do with clocks yes
<slangasek> hum
<apw> slangasek, i don't thnk it was ubiquitus or anything
<rtg> slangasek, yeah, that'll get important pretty quick
<apw> stgraber, we will be interested in those, get us the bug #'s
<stgraber> Nov 12 12:58:48 castiana kernel: [213981.764426] Request for unknown module key 'Magrathea: Glacier signing key: f440a253eb498df923d438caa09b3b5d99308405' err -11
<apw> slangasek, keys have valid date ranges on them, a bad system clock can break the key load
<rtg> slangasek, certificate authority date is related to the clock (I think)
<slangasek> apw: hmm; so I don't think that was the cause for me
<slangasek> [    2.523405] video: module verification failed: signature and/or required key missing - tainting kernel
<slangasek> that's here on the most recent boot, and my system clock isn't dodgy
<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
<apw> slangasek, i can only assume it is an ordering issue, we boot too quick or something helpful
<rtg> apw, there are plenty of bugs mentioning this problem. maybe jsalisbury would know one .
<stgraber> slangasek: ah yeah, I see that one too
<apw> rtg, good idea, will engage him
<stgraber> slangasek: I'll file a bug
<slangasek> stgraber: ta
 * apw bets you both use somethign which gets graphics into your initrd
<stgraber> we both use cryptsetup
<apw> that ... see
<apw> i bet that is why i don't see it
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-2.html
<slangasek> ok
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1253155
<udsbotu> Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [Undecided,New]
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Foundations for app developer workflow | Url: http://summit.ubuntu.com/uds-1311/meeting/21989/core-1311-foundations-for-app-developer-workflow/
<dholbach> xnox, I'm leading another session at the same time :-/
<dholbach> err, slangasek: ^
<slangasek> dholbach: ok.  Do you need this rescheduled?
<slangasek> I just sent the hangout invite to everyone subscribed to the session
<dholbach> no, I don't think I need to be there, I'll watch the video later on
<slangasek> ok, cool
<karni> slangasek: Thanks for the invite Steve. For this session I'll be mostly a listener.
<cjwatson> slangasek: I didn't get it AFAICS
<slangasek> https://plus.google.com/hangouts/_/7acpje7f3dnktlourn64tm45kg
<cjwatson> oh, maybe on my phone, which is no use to me :)
<slangasek> cjwatson: I guess I sent it to the wrong you, sorry :)
<slangasek> should've gone to the canonical-you
<cjwatson> ok - I'll be there in a sec, I'm just finishing updating my local emulator with some rapid use of 3G
<cjwatson> :-)
<zyga> hi
 * rsalveti waves
<karni> o/
 * ogra_ shores
<ogra_> video !
<karni> You're live
<rickspencer3> o/
<xnox> and it's live!
<ogra_> oh, and colin made his hair ... (he switched the cam on)
<asac> :)
<karni> the whole browser, yes
<xnox> yes.
<asac> yes
<xnox> cjwatson: still browser.
<lool> cjwatson: works well
<zyga> cjwatson: it's hard to share that one
<zyga> orks
<zyga> works
<xnox> cjwatson: awesome.
<karni> good
<lool> I see the browser
<lool> I see my browser window with cjwatson inside
<slangasek> it's working now - we sorted it out on the hangout rather than waiting for the IRC round-trip :)
<slangasek> lool: you must be desynced
<lool> I am, but I was trying to make a silly joke too
<lool> it's all good now  :-)
<karni> hehe
<rsalveti> and graphics should be working with latest emulator :D
<lool> hehe
<karni> rsalveti: \o/
<lool> rsalveti: is that with passthrough?
<slangasek> yes
<rsalveti> lool: yes, because we need opengles v2
<ogra_> we do !!
<zyga> is the child one can hear behind the scenes coming from the current speaker?
<ogra_> yes
<zyga> ah, ok
<karni> yes, shell
<zyga> yes
<ogra_> yes
<zyga> but very small
<zyga> too small to be readable
<xnox> cjwatson: yes, we do, but it's small font =))))
<zyga> or un-maximize the window
<rsalveti> still small?
<karni> much better
<rsalveti> don't know if it's the delay
<xnox> cjwatson: awesome.
<ogra_> yeah
<zyga> cjwatson: google gives you roughly the same texture for any size of your screen
<rsalveti> there's a huge delay
<zyga> cool demo!
<xnox> fingers crossed.
<ogra_> cjwatson, it takes 10min
<sergiusens> just be patient!
<xnox> cjwatson: very slow emulated processor.
<ogra_> 400MHz ... 512M
<ogra_> single core
<zyga> ogra_: what is that emulated with? qemu?
<ogra_> yep
<ogra_> a very old version
<zyga> ogra_: graphics patches holding it back?
<ogra_> well, its heavily patched for goldfish
<zyga> I see
<ogra_> not just graphics
<zyga> ah, I see
 * zyga mutters something about tizen / bada emulator ;)
<zyga> can we run the emulator with a prebuilt image
<zyga> that we can download from somewhere?
<zyga> I tried it today in trusty but the package was broken
<janimo> zyga, it worked for me in trusty today
<sergiusens> if it confuses people, just don't launch with -shell
<janimo> zyga, I used the build image script as documented
<zyga> janimo: the script for building the image is broken
<ogra_> worked fine for me
<zyga> janimo: it references stuff that's not in the package
<zyga> I was following the wiki basically
<sergiusens> zyga, you might of downloaded an older wrong package
<zyga> I can take it offline if you want to know what I did
<ogra_> zyga, then you got the broken package
<sergiusens> zyga, you need -0ubuntu2
<janimo> zyga, I was lucky I guess :) I did not check what it actually does, but it made a working sd.img
<zyga> sergiusens: nope, never installed that before
<ogra_> which also breaks your host
<lool> I was asking on teh wrong chanel blah
<lool> QUESTION: do we need separate chroots for native builds and cross-builds due to multiarch deps still?
<ogra_> (if it is amd64)
<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?
<zyga> oh
 * zyga checks
<ogra_> lool, cjwatson cant see his IRC
<zyga> darn
<xnox> slangasek: ^ relay question to cjwatson from lool
<zyga> yeah I have 2
<zyga> er
<zyga> 1
<ogra_> probably someone can forward the question to the hangout
<zyga> can I just upgrade now? I recall scary recovery instructions
<rsalveti> zyga: yes, latest should be safe
<zyga> ok
<ogra_> zyga, just never ever remove libc6-amd64
<sergiusens> cjwatson, rsalveti check if it's processing a crash
 * zyga reboots rarely so proably breaks-on-boot would be a bad thing to do now
<ogra_> (which the broken package pulled in)
<zyga> ogra_: heh, ok :)
<zyga> ogra_: oh
<rsalveti> sergiusens: I disabled whoopsie for now
<zyga> ogra_: -amd64 vs :amd64?
<ogra_> zyga, right
<sergiusens> rsalveti, yay :-)
<ogra_> rsalveti, evil you ! how are we getting all these crach reports now
<zyga> ogra_: is there a way to safely get rid of that somehow?
<ogra_> zyga, once the bug in libc is fixed perhaps
<ogra_> for now, just dont touch it
<slangasek> zyga: to fix it, just boot with break=bottom, and copy your ld.so/libc back from the initramfs to the rootfs ;P
<slangasek> piece of cake
<rsalveti> ogra_: well, otherwise you're basically unable to use it
<ogra_> lol
<cjwatson> zyga: sorry, my children can be a bit noisy at times indeed ...
<ogra_> rsalveti, details :P
<lool> cjwatson: ok, thanks
<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)
<zyga> thanks!
<lool> cjwatson: it was no strong reason except limiting the number of chroots people needed (space, ability to download them etc.)
<lool> time to update them etc.
 * cjwatson nods
<lool> I feel the pressure for fixing the content-hub hook is increasing
<zyga> thanks, interesting demo
<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
<sergiusens> cjwatson, do you have a link to the chroot setup/building? I might have missed it if you did mention it
<xnox> cjwatson: don't hit ctrl-c
<xnox> =)
<ogra_> lol
<xnox> cjwatson: you can open adb shell
<zyga> cool, sounds good for me
<cjwatson> click chroot -aarmhf create (from lp:click at present, soon from the click-dev package)
<zyga> cjwatson: don't disregard the tutorial nature of a complete video though
<cjwatson> zyga: agreed
<cjwatson> would need a bit more prep than this got :-)
<zyga> :-)
<sergiusens> great
<cjwatson> thanks all
<cjwatson> sorry for the not-quite-fully-in-place demo, but I hope you'll agree it was close :-)
<karni> thanks all!
<sergiusens> thanks
<karni> cjwatson: it was close! :)
<cjwatson> and thanks as ever to rsalveti for tireless work on the emulator
<ogra_> ++
<rsalveti> still a lot to do, but we're getting there :-)
<cjwatson> and to xnox
<ogra_> ++ too
<karni> yes we are!
<ogra_> :)
<ogra_> it is intresting though, for me the emulator worked on first try and a lot sooner than yours
 * cjwatson tries ctrl-c and re-running
<cjwatson> oh, I forgot one thing, instructions on the emulator
 * ogra_ thinks the graphics HW you use has also some impact 
<cjwatson> https://wiki.ubuntu.com/Touch/Emulator
<cjwatson> just make sure to use the very latest version in trusty
<cjwatson> one thing this really highlights is the need to rewrite click in C, as all that Python is slow on first boot :-/
<ogra_> yeah
<cjwatson> ha!  unity is up now
<ogra_> and there is whoopsie (which is currently disabled) and apparmor creating profiles on first nboot
<rsalveti> \o/
<ogra_> yay
<cjwatson> I should have ctrl-ced during the presentation :-)
<karni> cjwatson: :D
<ogra_> ureadahead too ... we might want to disable that
<cjwatson> or fix ... cf earlier discussions
<cjwatson> http://people.canonical.com/~cjwatson/tmp/emulator-yay.png
<cjwatson> (sorry, import -window root is a bit odd with multi-monitor)
<rsalveti> yay
<sergiusens> cjwatson, write it in go :-)
<sergiusens> that's just a pun ;-)
<karni> cjwatson: thanks for the screenshot!
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Planning the hardware enablement strategy for 14.04 LTS | Url: http://summit.ubuntu.com/uds-1311/meeting/22029/core-1311-hwe-plans/
<slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
<slangasek> https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
<slangasek> more people please join the hangout, this should be a discussion
<slangasek> don't leave me all alone in here with the kernel guys
<diwic> slangasek, ok, I'll try :-)
<tjaalton> i'm thinking about it
<tjaalton> but my wife has the laptop now :P
<tjaalton> yup
<tjaalton> maarten didn't reply to my pings
<tjaalton> ok got the laptop, will take a while to set things up..
<xnox> ogasawara: well at the moment upgrade fails, so one will fail to upgrade from -lts-saucy to quantal.
<xnox> infinity: ^
<xnox> are upgrades ever tested from all enablements to trusty?
<xnox> including -lts-trusty -> trusty
<slangasek> currently, none are tested
<infinity> xnox: No, but we need to.
<arges> do we test LTS dkms packages against all hwe-kernels?
<slangasek> arges: are there any dkms packages that are in main?
<ogasawara> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1244438
<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)
<geofft> at some point I'd like to ask about OpenAFS, which is in universe and broke with the most recent HWE kernel
<apw> geofft, what broke with it ?  did it fail to install or fail to work
<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
<geofft> apw: The DKMS modules failed to compile, and we're not really sure about the process for getting fixes
<apw> geofft, cirtainly filing a bug, if that is a universe package it is then best efforts
<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"
<marrusl> they were ok with it in the end, but they weren't clearly aware of what they were doing.
<apw> marrusl, messaging could be better yes
<slangasek> geofft: it's a suitable target for SRU
<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.
<geofft> apw, slangasek: LP #1206387
<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
<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
<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?
<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.
<slangasek> effectively, you need to get a package uploaded to the queue
<geofft> Also it would be _wonderful_ if this didn't break on the day of the upload of a new point release
<slangasek> sponsored or otherwise
<geofft> because we have users who will grab the new ISO, install, and then complain at us :-(
<bjf> xnox, i don't know how you can claim that the messaging is clear .. http://www.ubuntu.com/download/server
<geofft> and downgrading their enablement stack is a pain.
<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 =/
<xnox> bjf: i don't think there was any on server pages.
<xnox> slangasek: infinity: in the pool/*.deb
<xnox> ?
<bjf> xnox, so, you are assuming people know to go to the alternative downloads page and even on that page it is not clear
<xnox> bjf: true. i somehow thought it was better explained, but i can't find it any more.
<bjf> xnox, yes, you can go to "past releases and other flavours"
<xnox> bjf: i think we need more explanation text right next to "download" button.
<xnox> ... and on cdimage.u.c
<bjf> xnox, i agree with that
<xnox> ..
<xnox> cannot hear bryan.
<apw> he was asking if we will upgrade people at the end of life for the pre-trusty lts-
<apw> backport stacks, and that was a no, we would message them
<xnox> thanks.
<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.
<marrusl> (I have a feeling that NM deps will make this a big pain)
<diwic> seems nobody wanted to hear about the audio stack perspective, or my mic was muted?
<slangasek> marrusl: I don't see why we would make that part of the HWE stack, instead of simple standalone SRUs that nobody gets
<infinity> marrusl: Too late, session over.  La la.
<slangasek> diwic: oh - yes, you were muted!
<slangasek> diwic: sorry :/
<arges> diwic: your mic was muted
<marrusl> meh
<slangasek> diwic: wondered why you were so quiet the whole time... :)
<diwic> anyway; so for PulseAudio we decided not to try to do enablement stack stuff
<infinity> slangasek: s/that nobody gets/that everybody gets/?
<slangasek> infinity: yes, the inverse nobody
<diwic> and I think this has been working well enough to continue that for the next two years
<slangasek> ok
<diwic> compared to trying to backport PulseAudio
<slangasek> so you agree with the "it worked last time, let's keep doing it"
<marrusl> slangasek, ok interesting.  wpa and usbmodeswitch backport cleanly (iirc) to precise, but I gave up on NM (was way over my head)
<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
<infinity> marrusl: Does NM actually provide new hardware support, or just shiny new features?
<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
<infinity> marrusl: The point of HWE isn't to backport the world to the LTS.
<tjaalton> guess I missed the important bits while stealing my laptop :)
 * slangasek nods
<diwic> slangasek, so yes, I think we can continue with "cautious SRUing" for PulseAudio 14.04 too
<apw> sounds has been pretty good in precise i think, so that sounds like a sane plan
<marrusl> infinity, in effect it does...  mobile broadband cards are poorly standardized and one customer has found (working with upstream) that:
<infinity> tjaalton:  [adconrad] delegate someone in X to do meta packages for X stack if possible
<marrusl> sometimes they need to make a fix in modemmanager, sometimes it's in NM.
<infinity> tjaalton: Can I delegate that to you after explaining what it means? :P
<tjaalton> infinity: yeah I got that part
<tjaalton> and understand what it means
<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.
<infinity> tjaalton: Excellent.  tjaalton on launchpad too?
<tjaalton> yes
<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
<marrusl> s/geat/gear
<tjaalton> diwic: migrating machines from stack-to-stack?
<tjaalton> oh
<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
<gQuigs> xnox: heh.. on another note;  did we ever get data to know if we made right call re:64 bitdefault
<tjaalton> diwic: yeah, falls under the third paragraph of the notes
<tjaalton> actually
<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"
<tjaalton> I remember they should be migrated to the next LTS stack, ie. one that'll be in 12.04.5
<tjaalton> so that 12.10 will be maintained three extra monts until this is available
<tjaalton> rtg: ^ am I right?
<gQuigs> xnox: yea I haven't seen any complaints either
<diwic> tjaalton, given the user base I guess that's better than starting to ask questions
<tjaalton> this was discussed in oakland and/or copenhagen
<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?
<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]
<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.
<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?
<tjaalton> infinity: ok, works for me
<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
<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
<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.
<gQuigs> wait how much time will people have to upgrade from a HWE kernel?
<bjf> tjaalton, yes we will support the kernels until 14.04.1
<tjaalton> right this can't be just a thing baked in update-manager
<diwic> infinity, just FTR, told by who?
<infinity> ogasawara: ^
<tjaalton> there needs to be some apt-get'ty way to migrate
<infinity> ogasawara: Who told us we can't force people to migrate?
<bjf> infinity, mark
<tjaalton> bjf: good
<infinity> tjaalton: The apt-gety way to migrate is simple.
<ogasawara> infinity: sabdfl
<tjaalton> infinity: ok then
<diwic> ok
<geofft> slangasek: hm, or, is that the upload lfaraone already did?
<diwic> question is if sabdfl's statement applies to preinstalls too, and the reasoning behind it
<slangasek> geofft: oh, yes, it's in the queue as of 44 hours ago ;)
<diwic> tjaalton, but anyway I'll write to YK and tell him to have this as a topic during the hwe sprint
<infinity> diwic: I don't see why we'd treat preinstalls as unique snowflakes compared to end-user installs.
<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.
<tjaalton> yeah osp1 is 12.04.2+steroids, osp2 will be 12.04.3+viagra.. still the same tooling applies
<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.
<diwic> tjaalton, osp2 = 12.04.4 based
<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
<slangasek> geofft: response from whom?
<tjaalton> diwic: oh right
<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
<diwic> ogasawara, and so the question is if these are the packages we use in osp1/osp2 ?
<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?
<tjaalton> diwic: it's an extra package, the oem is free to install it aiui
<tjaalton> if they wish auto-migration
<ogasawara> diwic: I unfortunately don't know.  I'm not aware of what's in those osp1/osp2 deliverables
<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)
<infinity> geofft: subscribing ubuntu-sponsors (or finding someone to review and upload) would have helped.
<tjaalton> just a bunch of dkms backports..
<diwic> ogasawara, I don't know either, but I know who can figure out at least
<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
<slangasek> ok
<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?
<geofft> infinity: wasn't ubuntu-sponsors subscribed right after the debdiff was posted?
<infinity> geofft: Oh, so it was, according to the bug log.  I was just going by what slangasek said above.
<geofft> I think lfaraone unsubscribed ubuntu-sponsors last week after uploading
<andersk> Hi guys, I wrote and posted the debdiff in question.
<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.
<geofft> (should we move to another channel?)
<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.
<infinity> Right, this session's officially ended, I'm jumping ship from this channel...
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-2.html
#ubuntu-uds-core-2 2013-11-21
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-2.html
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Boot Experience | Url: http://summit.ubuntu.com/uds-1311/meeting/21976/core-1311-boot-ui/
<slangasek> heya - sorry folks, just one more minute on the hangout
<slangasek> https://plus.google.com/hangouts/_/72cpjsmf5m75etcllbd4s9csac
<slangasek> jodh: ^^
<jodh> slangasek: thanks
<zyga> hi
<josepht> streaming yet?
<slangasek> one more second
<slangasek> well
<slangasek> now
<arges-uds> HI
<Mirv> .
<zyga> I can see the stream now
<zyga> hi!
<Mirv> ^ that pip indicates when the stream started, to give an idea of delay :)
<arges-uds> did anybody test this: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/969489/comments/98
<udsbotu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [High,Triaged] - Assigned to Dalmer Vieira (dalmer-vieira)
<arges-uds> Won't people affected by this bug be willing to test solutions?
<arges-uds> Gotcha.
<smb> Would there also be a possibility to make feedback (like mountall waiting) also appear for configs that have console on serial?
 * ogra_ would even go further ... redirect all logging to serial if available and still be able to show a splash on the framebuffer 
<Mirv> QUESTION: Would the remaining (shutdown) part of bug #967229 fit to the blueprint? An OEM Priority tagged bug. I know it has been mentioned to be difficult without changing architecture some way, though.
<udsbotu> Ubuntu bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229 - Assigned to Steve Langasek (vorlon)
<karni> So there's a difference between operation kicking in long (like waiting for a download from the store to start) which should be indicated by a spinner or something, and an operation taking unacceptably long on the UI thread (i.e. you press a button, see it's highlighted, when you lift a finger, it's still highlighted because the operation hooked to that button has not finished). The spinner is responsible of the developer, the latter ...
<karni> ... visual feedback responsibility of the platform/framework to indicate "hey you, developer, you actually can do this better than what you did here".
<Mirv> karni: wrong channel? this'd be the boot experience one?
<karni> dang it, appdev-2 not core-2, sorry ;)
<karni> Mirv: thanks
<Mirv> thanks slangasek, just checking if any new thoughts on the topic
<smb> ogra_, me would be on the opposite side. Rather not be forced to move to framebuffer at all. Does not always work that well with virtual KVM switches and remote administration of servers... ;-P
<smb> But one cannot get everything :)
<ogra_> oh, i didnt mean to force people ...
<apw> smb, can't you just disable plymouth for your case completely
<ogra_> currentl plymouth doesnt allow serial and framebuffer at the same time
<ogra_> apw, no, mountall needs it
<smb> ogra_, Was not assuming you wanted to force me. :)
<slangasek> apw: disabling plymouth completely means you can't interact with fsck if it goes pear-shaped
<apw> slangasek, but can he disable splash and get textual and serialisable forms ?
<slangasek> apw: ok, but that's not "disable plymouth" :)
<smb> slangasek, not that I can interact with anything with plymouth still enabled but having console redirected to serial. ;) just saying
<smb> jodh, slangasek have you looked at boot speed (on to lightdm - lightdm to desktop) generally (had the feeling it became slower at least on netbook i386 atom style hw)
<slangasek> haven't looked into it; we should have routine bootspeed tests in the lab
<smb> slangasek, Yep and when finding them they showed some slowing down
<slangasek> ok
<Mirv> I've had mostly trouble with shutdown speed :) I've manually tweaked sendsigs max delaay to 1 second on all my computers bug #1212142
<udsbotu> Ubuntu bug 1212142 in sysvinit (Ubuntu Saucy) "Slow shutdown/restart on saucy with sendsigs waiting 10 seconds" [Medium,Confirmed] https://launchpad.net/bugs/1212142
<smb> Its a bit hard to dig down to useful runs to compare.... (bit being a bit underestimated)
<smb> apw could tell about it when he remembers. :)
<smb> ITs probably nothing that can be resolved here
<smb> Just wanted to bring it up
<smb> IIRC there was some reordering of executed thigns at some point and I think rendering seemed to get delayed
<Mirv> yes, it seems I've the 10 seconds wait every time without reasonable reason
<Mirv> thanks
<slangasek> jodh: ^^ maybe you can work with Mirv to get additional one-off debugging info
<smb> see you
<ogra_> thanx
<slangasek> perhaps there are lingering upstart user session shutdown problems
<Mirv> sure, happy to help on debugging jodh. I think lp:~jamesodhunt/ubuntu/saucy/sysvinit/log-processes-and-open-files-on-shutdown however needs refreshing and retargeting to trusty.
<jodh> slangasek, Mirv: sure.
<mlankhorst> hey
<apw> ho
<smb> lets go
<slangasek> https://plus.google.com/hangouts/_/76cpjqblm39a6ab37ctlc75f3s
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Automated upgrade testing to 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21973/core-1311-lts-upgrade-testing/
<pitti> jibel: ^ do you join?
<slangasek> bdmurray: https://plus.google.com/hangouts/_/76cpjqblm39a6ab37ctlc75f3s
<jibel> pitti, yes
<slangasek> session is started - two minutes early :-)
<mlankhorst> 2 minute lag
<plars> I don't know that we're still planning to move all this to utah
<xnox> ..
<xnox> QUESTION: the amd64 tests will run with i386 multi-arch enabled right?
<xnox> slangasek: from quantal to what? (straight to trusty)
<slangasek> xnox: yes
<xnox> ack.
<bdmurray> jibel: /usr/share/ubuntu-release-upgrader/DistUpgrade.cfg <- that change?
<xnox> and will we support raring straight to trusty as well? or do we expect raring people to upgrade via saucy?
<jibel> bdmurray, there is this and there was another change in the upgrader code
<jibel> bdmurray, it was when I checkd if it was possible to force the upgrade from LTS to any stable
<slangasek> xnox: raring goes EOL before trusty is released, so they need to upgrade to saucy
<xnox> ah, fair enough.
<xnox> so it's only quantal, which is a unique 18m snow-flake.
<xnox> slangasek: jodh: thanks for work-items on boot-ui session =) re: better handle output to console when splash is not in use - as far as I could tell, the plymouth-text-plugin seened to be modifyied to support same "progress" messages as "fancy graphics plugin" does. (if that's what you have discussed, haven't watched the video yet)
<xnox> does X have security support?
<slangasek> xnox: it's a protocol extension ;-P
<xnox> =)))))
<jibel> bdmurray, in MetaRelease.py line 276
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Continuing the Python 3 transition | Url: http://summit.ubuntu.com/uds-1311/meeting/22051/core-1311-python3-roadmap/
<jibel> bdmurray, it stops at the 1rst upgradeable release
<mlankhorst> EOW :P
<bdmurray> jibel: ah, thanks
<slangasek> https://plus.google.com/hangouts/_/7acpjlhnbik772ohdk2kqns32k
<slangasek> https://plus.google.com/hangouts/_/7acpjlhnbik772ohdk2kqns32k
<jamespage> o/
<slangasek> jamespage: https://plus.google.com/hangouts/_/7acpjlhnbik772ohdk2kqns32k
<pbass> https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=1
<bjf> the one question/issue i have (continuing issue) is launchpadlib and python 3
<alecu> QUESTION: what's the color coding of the spreadsheet?
<alecu> ah, it seems: unported=blue, inprogress=yellow
<pbass> alecu:described in the blueprint: https://wiki.ubuntu.com/Python/FoundationsTPythonVersions
<cjwatson> bjf: I understand that it's stuck on zope backporting
<cjwatson> or I probably mean just porting
<alecu> great, thanks
<bjf> cjwatson, is it on anyone's priority list?
<cjwatson> not right now, the LP team was reduced to a shadow of its former self ...
<bjf> cjwatson, i thought apport still uses lauchpadlib (could be wrong)
<cjwatson> It may well
<pitti> it does
<pitti> and a whole lot of other bits too, but we don't ship them by default either
<pitti> (we don't ship the apport python2 bits which needs launchpadlib by default)
<jamespage> the other biggish one for server: maas
<ralsina_> yes, xapian was the big problem and no, usc is not going away :-)
<ralsina_> mvo had done some work on using sqlite FTS instead
<alecu> we are keeping software center for 14.04, since we still need .deb apps for unity7, but we'll likely drop it once we have unity8 running as default on 14.10 or
<alecu> later
<xnox> thanks.
<slangasek> well, we need .deb support in the USC replacement for some time to come
<slangasek> please don't think that unity8 on the desktop means we don't need .deb support
<kiwinote> fwiw there is app grid (improvement to s-c) ( http://discourse.ubuntu.com/t/app-grid-discover-and-install-apps-for-your-computer/960 ) which already runs fully on python3 already - the main issue is licensing atm, but that's within my control - if there's interest we can discuss
<facundobatista>     3.4.0 beta 2: January 5, 2014
<facundobatista>     3.4.0 candidate 1: January 19, 2014
<facundobatista>     3.4.0 candidate 2: February 2, 2014
<facundobatista>     3.4.0 final: February 23, 2014
<ralsina_> kiwinote: that's *very* interesting, I'd love to talk with you about it :-)
<alecu> kiwinote: what backend are you using for the ratings and reviews? the same one as usc?
<alecu> kiwinote: it looks awesome indeed
<kiwinote> alecu: yes, backend is rnr-server, but with a custom client side
<kiwinote> ralsina_: feel free to e-mail me (@gmail) if you want to set up a hangout some time next week or so
<sbeattie> python security support has not been too onerous; issues have commonly been around SSL issues IIRC; getting TLS v1.1 and v1.2 natively in python 3.4 (rather than pyopenssl) would be nice, I think.
<ralsina_> SSO *may* go away
<ralsina_> and be replaced by ubuntu online accounts :-)
<ralsina_> reportlab is not near a py3 release at all
<alecu> thanks, bye!
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-2.html
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Release process review and discussion | Url: http://summit.ubuntu.com/uds-1311/meeting/22041/core-1311-release/
 * slangasek waves
<slangasek> https://plus.google.com/hangouts/_/72cpjq10emqosh7e6eu20vbnas
<slangasek> jamespage: hi, are you able to join this session to discuss the release schedule issues?
<jamespage> slangasek, smoser should be along
<slangasek> ok
<slangasek> smoser: https://plus.google.com/hangouts/_/72cpjq10emqosh7e6eu20vbnas
<slangasek> live
<knome> hey, sorry for being late. what's the youtube url?
<slangasek> the youtube url is in the summit window, as normal... do you mean the hangout url?
<slangasek> https://plus.google.com/hangouts/_/72cpjq10emqosh7e6eu20vbnas
<knome> no... the youtube url, i don't want to open the summit url (:
<smoser> Â  Youtube: http://youtu.be/hsEfuUkiN2Y
<smoser> knome, ^
<knome> cheers
<knome> has there been discussion about flavor release schedules?
<knome> xubuntu, it looks like (for point release)
<smoser> Â  Etherpad: http://pad.ubuntu.com/uds-1311-core-1311-release
<knome> release on wednesday april 30 (:
<infinity> smoser: Since hangouts hates me.  Has anyone actually suggested to upstream that they release a week or two earlier?
<infinity> smoser: In the past, they released on Apr 5 and Apr 4.
<infinity> smoser: So, really, like I said, if they keep slipping, we can't adjust for them forever.
<infinity> smoser: I think, in the future, we're going to end up always releasing with RCs, unless they pull their releases up a bit.
<smoser> infinity, agreed.
<knome> isn't the goal to have a stable release?
<knome> yeah, but the next release is LTS+1
<knome> it was brought to me elsewhere is that why aren't people still respecting freezes
<knome> all this discussion seems to revolve around the same issue
<knome> if we release on 17th, and you're late, then you're late
<smoser> so we don't like to do SRU on fridays, due to fallout
<smoser> but we'll do a release on the day before a 4 day weekend :)
<slangasek> it's not a 4-day weekend for /all/ of us :)
<cjwatson> I'm not wild about that either, but ...
<knome> it's like giving people freeze exceptions before the cycle even began, and then moving around all other dates and other peoples' schedules
<smoser> knome, i'm aware its not perfect.
<smoser> (even with a high degree of fuzzyness around 'perfect')
<knome> i mean, there was some serious discussions on "do not grant exceptions as much as before" in UDS-R, but then there was xmir landing with an exception (which fortunately didn't happen)
<knome> ^ just some feedback for the review&discussion.
<knome> is there any reason to not move the alpha1/2 freezes to mon/tue?
<knome> like the beta freezes
<cjwatson> I'm not actually concerned that icehouse is a freeze break in a meaningful sense, since in the past last RC -> final has been a trivial change
<knome> sure, wasn't about that specifically
<knome> brb
<knome> (back)
<knome> slangasek, ^
<knome> --> is there any reason to not move the alpha1/2 freezes to mon/tue?
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-2.html
<cjwatson> there's no alpha 1/2 freeze listed on the schedule right now at all ...
<Laney> I think they will be, if we have a freeze at all
<cjwatson> if we had them I wouldn't see a reason to have them be longer than the beta1 freeze
<slangasek> knome: alpha1/2 freezes> oh, perhaps we should have discussed that explicitly, yeah... let me take an action to follow up on list, I think we definitely do want shorter freezes for the alphas
<knome> well isn't there going to be *some* freeze anyway?
<Laney> We agreed on shortening them in a thread last cycle
<cjwatson> (which is listed as mon/tue)
<knome> slangasek, cheers
<infinity> +1 on formalising it to Monday, though it's not a hard freeze anyway, just a block and some discretion.
<knome> is there an action item on following up with flavors on whether/which milestones they will participate in?
<Laney> It'll be per-milestone
<Laney> There's usually a call out $days before asking who wants to participate
<knome> okay. does the release team want to track that somewhere, because i can promise xubuntu is opting-in in every milestone.
<skaet> knome,  I'll take an action to get a survey done as part of alpha 1
<knome> skaet, ^ there you go then :)
<skaet> will put a page togehter.
<knome> cheers
<knome> i suppose that was all i had to ask for now... you can catch me on #ubuntu-release if needed.
<Laney> So how are people supposed to get put forward for <archive management team>?
<Laney> Asking for a friend.
<Laney> Oh, got to go.
<Guest17696> hey guys , i would like to know if x will be the default or mir be the default on 14.04 ?
#ubuntu-uds-core-2 2013-11-22
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/22/%23ubuntu-uds-core-2.html
<xnox> Laney: ask stgraber, he was the latest addition to AA. i seems that AAs nominate new members into the group.
* ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/23/%23ubuntu-uds-core-2.html
