#ubuntu-uds-core-1 2014-03-10
<agus> ls
#ubuntu-uds-core-1 2014-03-11
<sofeafaef> Hi all
<sofeafaef> Hi to all
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYdwzZ1kXc6oi121rGs9L9ex5ZAZ7_MJRoCt3gGWBiIM--djug?authuser=0&hl=en
<ogasawara> smagoun, jibel, xnox ^^
 * ogasawara looks for others
<mdeslaur> \o
<ogasawara> mdeslaur: https://plus.google.com/hangouts/_/hoaevent/AP36tYdwzZ1kXc6oi121rGs9L9ex5ZAZ7_MJRoCt3gGWBiIM--djug?authuser=0&hl=en
<ogasawara> mdeslaur: hiya
<ara> hello!
<xnox> o/
<roadmr> hi
<ara> shouldn't https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule be updated to show that date? Aug 7th 12.04.5?
<smagoun> ara: yes
<smagoun> :)
<rbasak> What Adam says makes sense. But the flip side is that users would ideally always be able to install from the latest image, and never get a message immediately.
<xnox> as long as precise+trusty-hwe upgrade to trusty
<bdmurray> what about landscape?
<jamespage-uds> rbasak: dhenrich on the landscape team
<jamespage-uds> ogasawara: ^^
<ogasawara> jamespage-uds: awesome, thanks
<rbasak> apw: that one also needs to be able to answer people's question "will this be happening to me?" in advance of an actual notification.
<smagoun> ogasawara: I need to drop for another commitment - thank you for facilitating this
<ogasawara> smagoun: thanks
<ogasawara> jodh: https://plus.google.com/hangouts/_/hoaevent/AP36tYeuCFlc0lIjfDjhzuNFhXzVCok55HB8kUFPhezu3jicPS7A4Q?authuser=0&hl=en
<ogasawara> jodh: no hurry, you've got 10min
<ogasawara> jodh: let me know if you need help pinging participants
<jodh> ogasawara: thanks
 * pitti waves hello
 * slangasek waves
<slangasek> pitti: https://plus.google.com/hangouts/_/hoaevent/AP36tYeuCFlc0lIjfDjhzuNFhXzVCok55HB8kUFPhezu3jicPS7A4Q?authuser=0&hl=en
<ogra_> what about services that systemd needs, how do we transition things like rsyslog ?
<cjwatson> $ dpkg -L rsyslog | grep 'systemd.*service'
<cjwatson> /lib/systemd/system/rsyslog.service
<cjwatson> ogra_: ^-
<ogra_> oh ?
<ogra_> i thought that wasnt possible anymore
<ogra_> cool then
<cjwatson> yep, you can absolutely have both upstart and systemd configs in the same package
<gQuigs> anyone played with this?  https://launchpad.net/~ondrej/+archive/systemd
 * gQuigs couldn't get it to work
<ogra_> cjwatson, no, i mean using rsyslog on systemd ...
<ogra_> i thought systemd needs journald
<ogra_> as an essential bit
<cjwatson> the systemd journal writes through to rsyslog
<tedg> It seems like using Upstart/Systemd together means that we have more flexibility on the session side.
<cjwatson> that's the default config in Debian already
<tedg> If the session systemd can't run without a system systemd
<ogra_> sweet
<sergiusens> property watcher for android is system
<cjwatson> you get both information in the journal, and traditional logs
<cjwatson> the journal isn't nearly so evil a thing with that as it's been painted
<ogra_> well, i cant use less on the logs :)
<ogra_> reluctancy to change and all :)
<cjwatson> you can absolutely use less on the rsyslog-generated logs bridged through from the systemd journal
<ogra_> right, but i cant use it with plain journald logs
<cjwatson> I would encourage setting up a quick Debian VM, configure it to boot with systemd, and play with that
<ogra_> i'll surely do that (not right now indeed)
<cjwatson> ogra_: you can use journalctl/systemctl or whatever, or you can use less on the trad logs; while I can see that you want to look at the raw journal files if you're debugging systemd, I don't understand why that would be justified by a reluctance to change
<ogra_> sergiusens, well, before we even think about how to make the upstart bridges work with systemd we need to see if the android kernels can even run with systemd without to much patchwork :)
<cjwatson> if you're reluctant to change, you read the traditional logs and you ignore the journal
<ogra_> cjwatson, i know many people that run silly screen scraping shellscripts on logfiles etc
<sergiusens> ogra_, true
<ogra_> cjwatson, such setups kind of assume you have plain text logs
<cjwatson> ogra_: those will still work
<cjwatson> /var/log/syslog is *still there* and *still contains useful content*
<ogra_> right, in our setup
<ogra_> (or debians)
<sergiusens> ogra_, we will need to rewrite our overrides ourselves as well
<ogra_> "raw" systemd wouldnt though
<ogra_> sergiusens, yeah :(
<cjwatson> ogra_: why would I care about something that isn't our setup? :)
<cjwatson> or why should we care
<ogra_> heh
<ogra_> well, i dont know the debian setup yet ...
 * sergiusens stops commenting for ogra to single thread :-)
<cjwatson> anyway, my point is that the logs thing is a non-issue
 * ogra_ was always very happy with upstart ... i never felt the need to try other inits
<ogra_> right, i didnt know that debian had a solution already
<gQuigs> that seems painful to debug ....
<gQuigs> ... https://bugs.launchpad.net/upstart/+bug/160150  is this relevant?  nit: cannot be run as a PID other than 1
<udsbotu> Launchpad bug 160150 in upstart "init: cannot be run as a PID other than 1" [Wishlist,Triaged]
<ogra_> hmm, that used to work
<ogra_> (you were able to boot with init=/bin/sh and run /sbin/init manually for debugging)
<ogra_> sergiusens, the android property watcher just writes to a socket, isnt it ?
<ogra_> i think systemd should be capable to read from that
<rsalveti> probably
<apw> slangasek, can we not just move the system jobs to like /etc/init/system/* and only run those if pid==1 and not pid==2
<slangasek> apw: could be done, but that's a lot of glue code to add to upstart that doesn't currently exist
<apw> slangasek, by which i mean when we add a new systemd unit to the job move the upstart job to the systemd directory, so we know it is only needed when not using systemd
<apw> "a lot" is it really
<slangasek> ah, you mean moving them out of the standard upstart path so that they're not seen when booted as a helper, ok - seems the discussion on the hangout has caught up a bit :)
<gQuigs> which version of systemd are we aiming for?
<apw> slangasek, right if when you convert a job to system as well, you move those into a second place, upstart uses both dirs, upstart helper does not use the "converted" directory on its path
<xnox> apw: don't use subdirectory in /etc/init as upstart reads all subdirectories and it's all valid jobs.
<slangasek> right
<xnox> gQuigs: that bug is not relevant, upstart can run as both session or system init as not pid1. Most of our unit test rely on that. We have some safety checks in place, which will need to be tweaked, but nothing major.
<xnox> slangasek: apw: at the moment, we disable running system upstart with multiple config dirs, but that can be updated/re-enabled.
<ogra_> do you guys plan to cover the android related bits too ?
 * ogra_ doesnt see any recent notes about it, we need to make sure the helpers we use inside the android container still work or are portable ... and indeed there is that android kernel question ... can systemd work on 3.0 kernels etc 
<rsalveti> at least on >= 3.4
<sergiusens> rsalveti, that's min req I guess, but will it work?
<rsalveti> not without patching the kernel I believe
<xnox> pitti: but our 204 is with or without stable-branch patches?
<rsalveti> someone needs to get an action to check that for the next cycle
<pitti> xnox: not a lot of backported patches, mostly just for hwdb
<pitti> xnox: nothing stops us from pulling some in, of course
<xnox> pitti: ok.
 * ogra_ guesses the guys in the session dont read IRC 
<ogra_> :P
<xnox> cjwatson: but touch is next session =)
<ogra_> xnox, well, touch has also system jobs :P
 * tedg has jobs that use the apparmor stanza :-)
<ogra_> next session is about session
<pitti> heh
<tedg> the session session
<xnox> pitti: slangasek: yeah, how are we going to support android-bridge on systemd?
<slangasek> xnox: in the first iteration, is there any reason not to run that under upstart compatibility?
<ogra_> xnox, ++
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
<ogra_> slangasek, well, long term we need to switch
<xnox> slangasek: sounds good to me. I just thought phone could switch to systemd without any compatibility layer, as it doesn't need one at all.
<ogra_> and we start to rely more and more on system properties from android
<cjwatson> xnox: good to be accurate anyway :)
<ogra_> xnox, well, only if the bridge helpers work on systemd
<slangasek> xnox: well, it needs one for the android bridge, initially :)
<ogra_> and for session stuff we rely 100% on upstart today
<xnox> slangasek: cjwatson: e.g. do systemd unit files support arbitrary new stanzas and/or generic events thingies?
<ogra_> (way more than desktop for example)
<cjwatson> apw: I think we should avoid doing this in a way that requires us to do extra per-job work just to make upstart jobs work when they haven't been converted to systemd yet
<cjwatson> that way round means that we probably won't meet any sensible compatibility goals
<cjwatson> and in many cases if we're going to touch a package anyway it's just as easy to write a systemd unit for it
<cjwatson> e.g. I wrote systemd units for click which I'm pretty sure will work even though I've never run them
<slangasek> ogra_: do you want to join the hangout?
<ogra_> slangasek, i'm fine with IRC if someone pays attention to it :)
 * ogra_ would need to find a place where he can speak 
<ogra_> (not easy atm)
<slangasek> ogra_: well, /I'm/ not fine with IRC, the hangouts are used for a reason :)
 * tedg likes a silent ogra_ ;-)
<ogra_> :P
 * ogra_ reloactes
<slangasek> ogra_: (best case, there's significant lag between us talking and you seeing it on the feed)
<tedg> So an initial topic, it seems like we can't do any session migration until systemd is PID 1, right?
<xnox> tedg: correct, but once it is, we need a plan for conversion.
<tedg> But that's for trust + 1, right?
<tedg> We can't even think about it until then.
<ogra_> slangasek, gimme the HO url
<cjwatson> Some time between trusty+1 and trusty+4
<cjwatson> We can absolutely think about it
<cjwatson> And should
<slangasek> ogra_: https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
<tedg> I guess I think the session is going to be much easier to migrate than the system.
<tedg> We're not as complexly invested there, we simply haven't used it as long.
<slangasek> tedg: I don't agree that it's going to be *much* easier
<tedg> I'd love to avoid getting to tied into Upstart, but I do want to use "modern init features" more and more.
<cjwatson> There are things like associations with :sys: events
<tedg> slangasek, Well, I'm scared of servers, so it might be a perspective thing :-)
<slangasek> the uses of upstart in the session are largely orthogonal to how we're using it in the system init
<xnox> tedg: modern features would be using dbus-activation =)
<xnox> tedg: as that's managed under systemd ;-)
<tedg> That makes dbus-activation not suck. But it still doesn't align with purpose of session length jobs :-)
<tedg> +1, I think flag day.
<xnox> jdstrand: are you about?
<jdstrand> I am here
<xnox> jdstrand: join the hangout.
<xnox> jdstrand: https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
<tedg> ogra_, Unity shouldn't see much change, we've already abstracted it with libupstart-app-launch
<tedg> We just need to port UAL.
<xnox> tedg: and what would that involve?
<tedg> xnox, I mean I think it's more just "doing it" I'm guessing it's a week or two of work. Just need to schedule it.
<ogra_> tedg, well, doesnt ubity-mir do some lifecycle stuff that also might want to talk to upstart ?
<tedg> xnox, I don't think it's worth doing until we think we can have a systemd as PID 1 though.
<tedg> ogra_, AFAIK it does all of that through libual.
<xnox> tedg: well, we'll be able to start testing it as soon as we have ppa up with systemd as pid1
<ogra_> tedg, ok, so if you think we can easily transition that one to systemd we should be good
<tedg> xnox, Sure, but my manager doesn't take "I want to play with a PPA" as a good reason to schedule my time :-)
<xnox> tedg: which is in a matter of weeks, early 14.10. not something "in the very long future"
<xnox> tedg: ask slangasek to convince your manager ;-)
 * ogra_ would really prefer if we could stay on upstart with the phone until at least 15.04
<ogra_> (for sessions)
<cjwatson> Could you elaborate on reasons?  Is this just risk-aversion?
<ogra_> the system is far from being readily designed
<tedg> I'd rather design it more on systemd. Get it early, get it right.
<jodh> ogra_: FYI, I've started on a wiki page (it covers overrides btw): https://wiki.ubuntu.com/SystemdForUpstartUsers. More input welcome! :)
<serue> jodh: oh, nice, thanks for that
<slangasek> separately, the extensive use of overrides on the phone is really rather problematic
<pitti> jodh: hah, nice cheat sheet!
<sergiusens> tedg, so the u in libual will s/upstart/ubuntu/?
<tedg> sergiusens, Heh, that'd be a great idea!
<jodh> pitti, serue: :) I was hoping that that page would form part of the release notes once we've switched (or made that an option atleast)
 * tedg wants to name it bob
<sergiusens> ogra_, that's a problem from the prior session ;-)
<pitti> stgraber, ogra_: child reaper support is linux >= 3.4
<ogra_> sergiusens, yeah it was not dealt with in the former session, so i thought i should bring it up
<tedg> I don't think UAL is a "pain point," but it's a work item that we need to schedule.
<tedg> It's a significant thing that needs to be ported.
<tedg> I'd like to avoid supporting both at the same time, but if we have to, that's probably possible.
<cjwatson> I think we have to have some degree of dual running, both at the system and session levels
<cjwatson> I suppose worst case we could fork a systemd-app-launch if you really don't want both in UAL ...
<ogra_> hopoefully only during development
<cjwatson> (it'd want to be renamed anyway, right?)
<tedg> Eventually I think it should be.
<tedg> I like sergiusens' idea of "Ubuntu App Launch" though :-)
<ogra_> why does it have the session manager in its name ?
<tedg> We wouldn't have to support two APIs in Unity for sure.
<ogra_> it is used for launching click apps ...
 * ogra_ would call it click-app-launch :)
<tedg> Eh, I don't know. It was originally supposed to be a couple of Upstart jobs. It got feature creep :-)
<sergiusens> tedg, you forget the surfaceflinger/mir transition (still on going)
<sergiusens> :-)
<xnox> tedg: right it would be one or the other. you will not need to launch one app with systemd and another with upstart within the same session.
<tedg> sergiusens, I'm trying to forget ;-)
<cjwatson> ogra_: it's used for launching apps, not exclusively click apps
<tedg> It's also used for managing them. Finding PIDs, etc.
<ogra_> well, currently it only launches click apps ... due to circumstance :)
<xnox> ogra_: it launches click and legacy.
<sergiusens> ogra_, no, it launches legacy apps too
<tedg> Webbrowser isn't a click app :-)
<cjwatson> ogra_: perhaps, but consider the long tail of apps with unity8 on the desktop
<ogra_> oh
<ogra_> i stand corrected :)
<ogra_> cjwatson, well, they will hopefully all become click too ;)
<cjwatson> "long tail"
<ogra_> :)
 * sergiusens doesn't wnt to convert any more apps; too hard with the tight train schedule
<cjwatson> as the click author it is not my goal to stop people launching apps when they aren't in click format
<ogra_> sergiusens, just wait for libreoffice ;)
<cjwatson> I do not expect many apps to *ever* be converted, particularly people's local apps that they haven't rebuilt since 1995
<cjwatson> but this is for another session I suppose :)
 * ogra_ does ... but thats because i can read asacs mind :)
<cjwatson> asac is wrong :P
<ogra_> heh
<xnox> ogra_: one _never_ recompiles go-apps!
<xnox> =))))
<ogra_> xnox, who cares about go :) i want firefox and libreoffice click packages :)
<xnox> ogra_: nobody else wants those at all =)
<ogra_> convergence !
<xnox> ogra_: webbrowser-app https://drive.google.com
<ogra_> pfft
<ogra_> :)
<gQuigs> how can community contributers best help?
<slangasek> gQuigs: by taking workitems from the blueprint? :)
<gQuigs> err.. I mean from the perspective of changing jobs over.. when it's time to start, etc
<ogra_> gQuigs, and if you dont want to do that, we should have something to test at some point and someone will blog about how to use it and we'll need people to test the hell out of it
<gQuigs> ogra_: right
<ogra_> for changing jobs over we will first need the basics in place ...
<ogra_> once thats there you should be able to go wild on it :)
<gQuigs> ogra_: cool
<cjwatson> right, probably simplest to wait until we have a PPA you can work with and then start converting jobs where dependencies allow
<rsalveti> the android one is also system level
<ogra_> does it pick up anything there yet ?
<rsalveti> no, not picking at system level, I mean, it's part of system, not session
<ogra_> right
<ogra_> stgraber just translated your brazilian for me :P
<sergiusens> ogra_, that last comment came from the future
<sergiusens> :-)
<rsalveti> yeah, this delay is quite interesting
<ogra_> heh
<tedg> Thanks!
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/11/%23ubuntu-uds-core-1.html
#ubuntu-uds-core-1 2014-03-12
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html
<asac> ho
<ogra_> hohoho
<asac> :)
<asac> ogasawara: you run this track, right?
<ogasawara> asac: yep
<asac> ogasawara: when will we boot the room?
<ogasawara> asac: I usually start it up about 15min before
<asac> in 20 minutes early enough?
<asac> cool
<ogasawara> asac: then I ping the url here
<asac> good
<ogasawara> asac, didrocks: https://plus.google.com/hangouts/_/hoaevent/AP36tYejx4a57LGNk7fbW9HeUUpDvo-i-SHKLuRhKzSha-qxFpMxUA?authuser=0&hl=en
<didrocks> thanks ogasawara
<asac> ok lets see if this thing works here
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Landing process rules for ubuntu Touch | Url: http://summit.ubuntu.com/uds-1403/meeting/22174/core-1403-landing-process-touch/
<asac> bfiller: https://plus.google.com/hangouts/_/hoaevent/AP36tYejx4a57LGNk7fbW9HeUUpDvo-i-SHKLuRhKzSha-qxFpMxUA?authuser=0&hl=en
<olli_> hi folks
<asac> hi olli_
<karni> Someone could drop the presentation URL into the session pad, once it's over.
<asac> karni: will get it posted afterwards
<karni> elopio: you might want to mute yourself
<karni> asac: thanks!
<elopio> sorry. I'm muted now
<asac> dont want to interrupt didier
<dobey> anyone who is not talking should mute themselves
<dobey> in every session :)
<karni> elopio: np
<ogra_> hmm, cant get video here
<tedg> ogra_, didier is signing Hollywood music, so it's restricted.
<ogra_> heh, well, it doesnt load on yourtube (nor in the embedded thing)
<sergiusens> ogra_, I restarted firefox for it to work...
 * ogra_ only gets a spinner .
<ogra_> sergiusens, igh ... certainly wont do that
<ogra_> (too many open things here, cant restart it)
<rickspencer3> didrocks, for the "fix ready" line ...
<ogra_> (other videos work fine )
<sergiusens> ogra_, pkill firefox and restart
<rickspencer3> does that include reversions?
<sergiusens> ogra_, will restore all your tabs :-)
<ogra_> sergiusens, i will lose several oppen endit forms
<ogra_> *edit
<sergiusens> ogra_, you are so complicated :-P
<ogra_> and i can play any other video on youtube, just this one doesnt load at all
<rickspencer3> ogra_, maybe try joining the hangout?
<xnox> ..
<ogra_> rickspencer3, cant from this device ...
<xnox> autopilot did for sure catch failures.
<ogra_> heh
<dobey> ogra_: try shift-reload to reload without cache?
<ogra_> it also produced a lot
<ogra_> dobey, all tried
<dobey> ogra_: i've found i have to do that for all the uds videos when the session actually starts
<sergiusens> QUESTION: with most apps moving to autopilot and most test being against apps; is there a plan for the ci train to accommodate that?
<sergiusens> or is the focus going to move to running autopilot on system components (osk, unity8, uitoolkit)
<sergiusens> yes we can
<didrocks> asac: rick is talking!
<sergiusens> lol
<dobey> i can hear rick!
<geddy> we can hear him
<balloons> lol
<sergiusens> we can hear rickspencer3
<sergiusens> asac, restart your hangout
<lool> asac: you need to stop talking
<bregma> laaaaag!
<lool> asac: you're watching the youtube stream or something
<asac> sergiusens: well, leann also cant
<sergiusens> yeah; the delay doesn't help :-)
<rickspencer3> know we know why asac and ogasawara are so productive
<ogasawara> heh
<asac> :P
<lool> are they leaving 2 minutes in the future?
<lool> *living
<asac> oh i remember i installed the hangout block feature
<asac> for rick
<kenvandine> haha :)
<xnox> rickspencer3: clearly some people clicked "ignore this person" button =)))))))))) </kidding>
<rickspencer3> whatever works!
<tedg> It seems like a lot of the delay is in rebuilding images. But it seems like building multiple images is just a matter of CPU time.
<tedg> Can we build images for "instant revert" proactively?
<xnox> tedg: that's getting fixed, by moving cd building into launchpad and have a full pull of all builders which will be able to build image per each silo.
<asac> tedg: image building is only 1/4th of the time
<xnox> s/pull/pool/
<asac> the testing is what takes a long time (4-6h)
<ogra_> image builds take ~1h
<asac> we a) work on allowing parallel testing which will allows us to pipeline
<tedg> That actual building. But let's say we built all the image combinations. So we were just choosing which one.
<tedg> i.e. there's already an image without a certain silo landed.
<asac> b) later do swarm testing so it will take just 1h or even less
<asac> swarm waits for emulator
<olli_> kgunn, wasn't the number of silos somethnig you mentioned in an earlier conversation
<dobey> x86 emulator will make testing a lot faster
<asac> tedg: we have a bottleneck in our official image build infra
<tedg> asac, By swarm you mean AP with gemgem?
<asac> ogra_ knows what that bottleneck is
<ogra_> do we ?
<asac> tedg: well, taking 10 phones and running one AP on each instead of sequence
<asac> as an example
<kgunn> olli_: yes, more specifically - dedicated silo, available all the time to a team/proj
<asac> ogra_: we cant produce multiple images in parallel, right?
<asac> people told me we wait for buildd cloud
<ogra_> asac, ah, right, they get queued ...
<asac> ogra_: what part of infra cant do parallel?
<kgunn> olli_: but this is what didrocks calls "airline" vs train ....so some x amount of infrastructure or change to it needed to accomplish that
<ogra_> but that part of the build only takes 20-25min
<tedg> Can we "swarm test" manual testing by using the QA test tracker?
<ogra_> so we could raise the frequency a bit
<tedg> Basically make one entry per-image like we do with daily CDs?
<asac> tedg: we could look at swarming manual testing, but problem is that with manual testing the testers need to be calibrated
<asac> so you cannot just test once in a month one test case
<asac> usually you will report confusing things etc.
<asac> our problem is really getting the AP results asap
<tedg> Sure, but couldn't the calibrated testers just test the cases that are raised by the swarm?
<rickspencer3> I wonder if there is a way to make reversion faster and more reliable, but without slamming upstream trunk
<asac> rickspencer3: we revert without slamming upstream trunk
<rickspencer3> like could we keep copies of the last binaries around and put those into the image or something
<asac> rickspencer3: reverts are done in archive
<rickspencer3> ?
<rickspencer3> right, I think that's a good thing that we want to keep
<rickspencer3> but maybe we could make rollbacks easier and keep that goodness
<tedg> I guess for me I'd say we want rollbacks quicker so that they can be decisive and make it so that other things can land.
<rickspencer3> in other words, can we make it so that there is nothing that is "hard to rollback"
<xnox> rickspencer3: old binaries are available from librarian, but there is no guarantee they are installable when everything else moved on. Using old version binaries works for e.g. image-based upgrades. But doesn't help other silos/packages (they still see higher/broken version) or apt-get based machines.
<rickspencer3> xnox, but could we not calculate all the binaries that changes in the rollback?
<asac> i think we could do it by grapping old binaries, but it becomes pretty tricky for everything not a leave package
<asac> grepping
 * ogra_ thinks we just need to become better with testing so we dont have to roll back *after* something entered
<asac> err :) you know what i mean
<xnox> rickspencer3: from legal point of view, we build from the archive, as we publish matching source-code for those versions.
<xnox> rickspencer3: calculation could be done, but it would need verification that it indeed doesn't regress.
<rickspencer3> that doesn't seem like a blocker, I mean, the source code is available in the commit history
<rickspencer3> so it should be easy to get the source that is published
<xnox> rickspencer3: what i have seen with reverts, is that revert happened without consulting the uploader (myself), which is a no-win revert as it re-introduces fixed things.
<rickspencer3> to be clear, my implementation is maybe not good, but I think it's worth thinking about how to do rollbacks smarter
<pmcgowan> Question: are all regressions treated equally or is there some analysis of minor regression vs major feature landed and needs to be released
<tedg> rickspencer3, +1
<cjwatson> I think we *are* doing rollbacks quite smartly, and people are asking for them to be done more quickly but less smartly ...
<cjwatson> that's the strong impression I get
<rickspencer3> cjwatson, interesting point
<tedg> For me I'd like rollback, etc, to be more automatic. Not a "someone decides how important" it's just a part of the machine.
<xnox> rickspencer3: the way we do reverts, of a single package, not a full revert to previous image number, it still needs to go though full testing. As it's a new state. It has been identified to resolve /a regression/, but it's rarely verified fully to not introduce any /new regression/ as those reverts don't go through full test-plan.
<cjwatson> the pushback always seems to be in cases when we're in the middle of doing proper root-cause analysis
<rickspencer3> more quickly but also still smart sounds good
<tedg> So then things move on quickly.
<rickspencer3> cjwatson, I'm curious why that impacts the developers, I would think didr0cks could do a rollback to keep the image green while the developers keep going with their root cause anlaysis
<rickspencer3> what am I missing?
<xnox> didrocks: QUESTION: why reverts don't go through silo and a full test-plan execution?
<cjwatson> rickspencer3: I've suggested before that this could trivially be done by having a separate PPA that we copy old versions into
<rickspencer3> interesting
<cjwatson> and having that pinned through the roof in the image build process
<rickspencer3> in the meantime, profile before you optimise
<cjwatson> so far my suggestion has been largely ignored though *shrug*
 * ogra_ sighs ... no dice for me with the video, even on another machine with different DSL connection :/
<rickspencer3> the 5 hour automated test lag is clearly where we should focus
<pmcgowan> cjwatson, then the image does not match trunk or archive, is that a concern?
<cjwatson> pmcgowan: I think that's fine as long as we keep the list of active rollbacks small
<cjwatson> which should be good engineering practice anyway
<olli_> QUESTIONS: one thing that Google CI supposedly does well is to relate code changes to relevant test cases automatically and then run only that subset (automated). Have we any plans on targeting testcases more precisely?
<xnox> rickspencer3: re:automated lag - it takes less than 5 hours on armhf emulator, yet adding emulator to ci has been stalled it seems.
<rickspencer3> xnox, I thought you were going to add x86 emulator so that we could quickly scale out automated testing
<tedg> didrocks, asac, can we come up with a metric for "risky" so that people can understand it?
<xnox> rickspencer3: armhf emulator is available and it scales well on top of openstack. x86 emulator is in progress in bring up.
<tedg> i.e. not assigned by people, but by an algorithm
<xnox> rickspencer3: i made intial proposal to add amr emulato to jenkins / ci, and someone from #ci was working on it, but no updates for a few weeks now.
<xnox> s/amr emulato/arm emulator/
<sergiusens> rickspencer3, when you want to talk mute asac and unmute when done; should provide better sync and collision avoidance :-)
<ogra_> :)
<xnox> didrocks: QUESTION: there was full-train stop, which did delay python2-removal for example.
<rickspencer3> just like irl
<ogra_> duct tape ?
<asac> ah rick is talking
<asac> hehe
<didrocks> asac: yeah :)
<didrocks> asac: will tell you here
<didrocks> (I hope someone can relay the question in the hangout, I've my slides focused)
<asac> for me the definition of risky landing could be: if your testplan is affected by current regressions, you are at risk of landing more regressions
<asac> that you dont see
<tedg> I don't think it does. I think we need a way to ensure that "risky" is transparent. If you can't measure it, it really can't be part of the determination.
<asac> so its not so much where in the stack you are, but its kind of correlated
<rickspencer3> </soapbox>
<asac> tedg: is that a comment on my proposal of risk above?
<cjwatson> measure> yeah, absolutely; I get the sense that the "risky" category is kind of prejudice / based on something that happened months ago
<asac> feel thats pretty measurable. you have a risky landing if your component testplan is currently not 100% green
<cjwatson> sometimes, anyway
<tedg> rickspencer3, Isn't that really for images that get released to users. For instance, we're not going to do a daily release to all users. I think we need a different level for daily and to-user releases.
<ogra_> often enough, yeah
<asac> i think with this it will usually correlate on where you are on the stack
<asac> but it wouldnt be just "you are low, so you are risky"
<tedg> asac, I'm not sure what you mean by "component testplan"
<ogra_> tedg, the testplan for the component you maintain
<asac> tedg: every component like mir has a testplan. thats manual checks + a set of autopilots that folks run in the silo
<tedg> Yes, but how is that "green or not" ?
<ogra_> tedg, either your change passes or not
<balloons> I think even in normal states, it's difficult because nothing can merge to trunk
<tedg> We have no place that it's getting recorded. It's "green" in someone's head.
<asac> tedg: if you can run all the manual checks and autopilots tha tyou need for your landing in the current image and it is 100% succeess
<asac> its green
<balloons> trunk should not be the same as the archive
<asac> tedg: no its recorded
<asac> the manual part not. but the APs
<ogra_> well, the manual part is kind of as well
<asac> right.
<ogra_> by you setting the silo stuff
<tedg> asac, So if all the APs for a component is green, you consider it non-risky?
<asac> but we haven't figured how to ensure people that have testplans know whether their manual testplan is currently affected
<ogra_> if you say "tests passed" we have to assume your manual tests worked
<asac> tedg: all APs that you need to run for a component landing ... which is more than just the AP for that component
<balloons> under a normal process, you would have a release branch, a development branch, and feature branches. Features land into development, and occasionally you would push those then to a release branch
<asac> tedg: e.g. if you land mir we also run a bunch of app APs, unity8 AP etc.
<asac> tedg: so the APs in the component testplan being green == non-risky in the sense of phonecon1
<tedg> asac, How is that list generate?
<tedg> generated?
<ogra_> tedg, you as the developer define it
<asac> tedg: we start with a good initial guess out of experience ...
<asac> tedg: and if we identify that something slipped through, we grow that list
<asac> tedg: we try to not start with the complete list of reverse dependencies to stay efficient
<olli_> kgunn, isn't that how Mir is working atm?
<ogra_> you have to provide an initial testplan when getting the silo
<tedg> asac, Where is it recorded?
<asac> tedg: supposed to be recorded in the testplan
<ogra_> tedg, on the landing sheets
<xnox> ..
<cjwatson> tedg: https://wiki.ubuntu.com/Process/Merges/TestPlan/<foo>
 * asac is brave and reconnects
<sergiusens> a year and a bit ago we had the concept of a release commit which only then would push to our archive (which was a PPA at that time)
<xnox> e.g. with ubuntu-ui-toolkit we tried to land 17 branches in one go, which ofcourse, failed to merge and 4 branches did conflict between themself.
<ogra_> tedg, when you request a silo, you have to link your testplan ... when you did the testing, you have to note in the silo spreadsheet that it passed (or not)
<sergiusens> so people could merge to trunk and _release_ when it's ready
<asac>  \o/ i can hear rick :)
<xnox> and therefore was pain to land, as there was no sensible conflict resolution. 4 branches got kicked out, and eseentially landed one by one, weeks later.
<cjwatson> rickspencer3: anything that provides an API to anything else has a clear incentive to get things into the archive so that they can land changes that depend on new APIs, IME
<tedg> So, I'm confused. So for every image, QA takes the list of every silo landing and generates a list of APs to run.
<ogra_> tedg, no
<tedg> Where is the list of AP tests that'll be run on that image?
<cjwatson> rickspencer3: (e.g. I had a strong incentive to get libclick landed so that I could start landing the things that depend on that)
<ogra_> tedg, for your very own changes you use the silo ...
<ogra_> tedg, you do your testing, if your testing passes you can land it in the archive
<sergiusens> cjwatson, yeah, that's when stopping the line is the most burden
<xnox> ..
<ogra_> tedg, images are built out of sync here
<cjwatson> right, it's terrible for anything with multi-level stacking
<tedg> Or 100's of MR's queued...
<ogra_> tedg, and the images run *all* AP tests automatically before we consider them releasable
<kgunn> olli_: yes - mir works this way today on lp:mir/devel
<kgunn> and lp:mir
<ogra_> tedg, so if at that point a regression is found in the component you landed, we roll it back (or as you to)
<ogra_> *ask
<tedg> I'm confused. So project X is risky if any run of that it declares in its test plan has failed.
<dobey> all projects are risky
<ogra_> right
<tedg> So how do I determine if my project is risky?
<ogra_> the issue when your testplan passes but the image one doesnt is most likely that your testplan misses something
<dobey> tedg: if it has code, it's risky :)
<cjwatson> tedg: I think there's some talking past each other here; some people seem to be talking about risky projects, others about risky landings
<olli_> tedg's project are always risky
<rickspencer3> tedg, I think that the landing team tells you if it's risky
<cjwatson> those are obviously quite different things
<rickspencer3> and what olli says ;)
 * ogra_ would like to get away from that "risky/non risky" stuff
<cjwatson> rickspencer3: but that should be based on science
<cjwatson> and vaguely predictable
<ogra_> the issue we have is that the first level testing isnt good enough very often
<rickspencer3> cjwatson, indeed, I was subtly pointing out a potential problem
<dobey> to mee, it just seems like CI needs to be more async
<ogra_> if that is 100% reliable, you wont have to roll back ever
<tedg> I think it should be predictable, but I'd settle for transparent at this point :-)
<cjwatson> rickspencer3: *nod*
<rickspencer3> I do wonder if there is some kind of rdepends that we can run that predicts such things
<rickspencer3> like, a certain weight of things that depend on you equals risk level or something
<ogra_> not really, since we are working image based
<dobey> more async and more automation
<ogra_> one of the probs is that you test on the last image that was built... the stuff that you land lands in the next image that gets built ...
<ogra_> which means you have other changes that go in alongside ....
<ogra_> which can change the whole situation amnd stability
<tedg> Sure, but that doesn't effect how risky the project itself is.
<xnox> ..
<xnox> ideally we'd have integration branch for landing, ahead of the landing.
<dobey> tedg: ideally, every package/project would be treated as equally risky
<ogra_> tedg, no, but you have to asses the risk always in combination with all the other changes
<sergiusens> I agree with Saviq and want to add that merging a component of yours that depends on changes on many other projects (like mir or unity8) you sort of block everyone
<sergiusens> it's silo-cked
<ogra_> heh
<dobey> and you eliminate the thinking about whether something is risky or not, because everything is
<kgunn> lol
<cjwatson> the problem with this is that it puts massive friction on improving our core
<kgunn> "silo-cked" word of the day
<cjwatson> now, it also puts massive friction on breaking our core
<rsalveti> sergiusens: it'd still be an issue if we had devel/release branches
<cjwatson> so I get the trade-off, but still
<rsalveti> would not block trunk, but the issue would still be around
<sergiusens> rsalveti, oh, I'm not stating solutions today; just wanted ane xcuse to say silo-cked :-)
<cjwatson> cf. the gigantic project of Qt 5.2
<dobey> sergiusens: and then the silo-ns will nuke us all
<ogra_> ++
<rickspencer3> maybe risky = time since landing + weight of rdepends + history of regressions caused
<sergiusens> it was rsalveti :-P
<rickspencer3> ?
<rickspencer3> oops
<rickspencer3> sorry sergiusens and rsalveti :)
<sergiusens> np
<asac> yeah, but rsalveti said "i dont want my team to do that" :)
<rsalveti> another guy from south america :P
<sergiusens> we ar the same team and have the same opinion
<cjwatson> rickspencer3: also I think some judgement of the actual changes should be involved
<rickspencer3> size of patch?
<sergiusens> it's been this way for us since we started this project
<cjwatson> the stuff that's already in the image, well, we've accepted the risk
<kgunn> 2 other "small" things i would ask for today - self service reconfigure & not locking silo's on project use (only lock landing)
<rickspencer3> maybe risky = time since landing + weight of rdepends + history of regressions caused + size of patch?
<kgunn> asac: ^^
<sergiusens> but there are some corners where we might consider flag days perhaps
<rsalveti> asac: because we want to share the responsibility, and we can't afford having someone coordinate trunk/release merges
<sergiusens> as much as the android bump was tested; it wasn't enough; and qt 5.2 will have a similar problem most likely
<rickspencer3> sergiusens, yup, exactly
<rickspencer3> and that's not necessarily representing failure conditions
<cjwatson> sergiusens: risk-aversion is a continuum - it doesn't IMO make sense to crank the dial all the way to one side
<rickspencer3> some things are just tough
<ogra_> sergiusens, thats what i'm saying all the time above ... we need to get our pre-testing better
<cjwatson> the problem is that any time something goes wrong people ask "how could we have avoided this"
<cjwatson> which is healthy in one sense
<rickspencer3> cjwatson, well, we have the promotion as the ultimate safe gaurd
<cjwatson> but it means it's very hard to say "sometimes, it just wouldn't have been worth the degree of friction required to catch this"
<slangasek> managers enforcing releases once a week> that means the managers have to have eyes on all the individual components that their team has touched, right?
<rickspencer3> so, it seems to me that the "risk" really comes down to a lag between promoted images
<ogra_> rickspencer3, but we most of the time only discover the issues at that point
<ogra_> which is what causes us to roll back
<tedg> We could have sync points where everyone makes sure to have a release.
<dobey> i would land MPs in trunk as fast as possible, and automate daily releases and testing
<slangasek> also, what if one team is ready to do their weekly release, and it needs a change to a package from another team, and the other team has staged changes that are not yet releasable?
<ogra_> we need to get better (a lot) on the first test run and with the first test plan in the line
<xnox> rickspencer3: i'm ok for integration branches, but it shouldn't be an open-ended branches, but e.g. "next-landing" branch which would be limited to what is desired to land, not something open ended. Once it's full, it must land before merging more stuff into it.
<rickspencer3> ogra_, right, I guess I'm saying that just because we do a landing and we find issues, it's not a freak out situation
<cjwatson> tedg: we could have them every six months :)
<rickspencer3> ogra_, I think we all agree with that
<tedg> cjwatson, I was going to propose some interim ones, we could call them alpha/beta ;-)
<rsalveti> once we get the x86 emulator we'll at least the get the test results sooner
<cjwatson> tedg: heresy
<rickspencer3> as I say, it seems that we are good at keeping the impact to us as developers
<rickspencer3> and that promotion protects users
<rsalveti> and another issue is that we can't yet give a custom image to be tested like the ones we have in the dashboard
<ogra_> rsalveti, but the x86 emulator will test x86 binaries
<rsalveti> most of the issues are arch-indep
<ogra_> we will only see over time how reliable that even is
<cjwatson> ogra_: it's still catch a lot of things
<cjwatson> *it'll
<ogra_> sure
<cjwatson> the click problems over the last couple of days would absolutely have been caught by that
<cjwatson> for instance
<ogra_> yep
<mardy> bfiller: +1
<rsalveti> like, if I want to land hybris or android, I'd like to be able to create a custom image and give it to be automatically tested
<ogra_> but i assume there will still be many false positives
<cjwatson> it'll get better over time
<ogasawara> didrocks, asac: gotta start wrapping up...
<ogasawara> didrocks, asac: as I'll need to shut down this hangout in a few mins
<ogra_> rsalveti, use rootstock until cjwatson's PPA builds start working then
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Networking Health-Check | Url: http://summit.ubuntu.com/uds-1403/meeting/22215/core-1403-networking-healthcheck/
<tedg> I think it's important that we keep branches to releases for maintenance.
<didrocks> ogasawara: ok, got it, just have 30s to say
<ogasawara> cyphermox: will get your hangout up as soon as this one is done
<ogasawara> didrocks: ack
<rsalveti> ogra_: my issue is not creating the image, but using that to be automatically tested :-)
<cyphermox> ogasawara: ah, ok
<tedg> We are supporting those releases and need to base off of those.
 * stgraber waves
<tedg> But we use symbolic naming in LP for that.
<rsalveti> so later on we can have landing silo ppa -> image -> dashboard (tested with the x86 emulator)
<ogra_> rsalveti, well, doanac is working on a "home use utah" for that
<tedg> lp:foo goes to lp:~team/foo/trunk.14.04
<rsalveti> ogra_: right, but that's a feature I asked before we started trusty :-)
<ogra_> heh
<dobey> tedg: that's a bit annoying though
<sergiusens> ogra_, I think that utah is mostly done; at least my tools plan is to ask him to test against that :-P
<cjwatson> you can often create the maintenance branches for older series lazily
<cjwatson> lots of projects never need them
<ogra_> sergiusens, well, you dont really want to run systemsettle so testing locally will only take 1h instead of 3-4
<tedg> Sure, I find that's easy for us, but people who are more drive-by have a more difficult time finding those points.
<dobey> merging to trunk and releasing to archive/image being separate, but closely knit, seems like the best solution to me
<xnox> rickspencer3++
<pmcgowan> rickspencer3, +1
<sergiusens> ogra_, oh, these take 4h so I might be in full blown mode ;-)
<ogra_> sergiusens, yeah, its awful
<xnox> cjwatson: lp:project/stable
<rickspencer3> does anyone notice the artwork behind didrocks
<xnox> (not need to encode the codename)
<rickspencer3> those are by his wife, julie, she's an amazing artist
<dobey> rickspencer3: i have yeah
<Saviq> :)
<ogra_> rickspencer3, she has an afro haricut ?
<rsalveti> haha, indeed
<ogra_> oh ... "by his"
<ogra_> :)
<rickspencer3> yeah, the "by" is an important word there ;)
<pmcgowan> next sessions are starting fwiw
 * didrocks move the camera to make more ad :p
<dobey> the session ended 5 minutes ago guys :)
<ogra_> haha, you need to put prices on
<ogra_> should we schedule a followup session ?
<sergiusens> bfiller, asac for automerge; the auto tests were ran
<ogasawara> cyphermox: sorry for the delay, I'm proding these guys to wrap up
<cyphermox> ogasawara: I m following that session no worries
<cyphermox> mine will be short and sweet I think
<rickspencer3> maybe do it on the phone mailing list or something?
<asac> sergiusens: i know :)
<asac> rickspencer3: sure.
<sergiusens> just reconfirming
<asac> thanks guys
<didrocks> thanks
<asac> was a good session ... and i was even able to hear rickspencer3 at some point :)
<ycheng> hi, presentation URL please
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYeAxqTjWsaQHLR0uYFiN-6eEqJ4Hl0KAOI1HFX3gsnQNtpEug?authuser=0&hl=en
<ogasawara> cyphermox et al ^^
<xnox> cyphermox: down with bluez-gstreamer! can i go and drop that from ubuntu-desktop?! =)
<asac> jfunk-canonical: bfiller: kgunn: can you guys give a bullet list of what features "trunk" comes by with beyond review bot and automerge?
<cyphermox> xnox please don't
<xnox> cyphermox: =(
<awe__> cyphermox, do you know whether or not upstream is working on P2P support?
 * xnox is on like a minute delay on the stream =)
<xnox> cyphermox: thanks for your reply ;-)
 * ogra_ cant watch this stream either :(
<cyphermox> ogra_: why is that?
<rsalveti> ogra_: just join instead
<ogra_> no idea, the live streams dont work for me
<ogra_> i canm watch any other video on yourtube and i can join the hangouts, but i cant watch the stream
<asac> didrocks: you have the presentation URL?
<didrocks> asac: sure, https://docs.google.com/a/canonical.com/presentation/d/1G4eWxQ8OnwPMXFJFefYdRTKuKZd_Da9Zh2W_X5XRJCc/edit#slide=id.p
<asac> karni: ^^
<karni> thank you!
<xnox> ..
<xnox> who is making clicking noises ?! =)))))
<stgraber> I think it's cyphermox, everyone else is mutedd (but me, but I'm not the source)
<cyphermox> no, not me
<ogra_> must be tony then
<ogra_> no
<stgraber> nope, everyone else but cyphermox are muted now :)
<ogra_> definitely cyphermox
<ogra_> he needs a can of oil ;)
<xnox> stgraber: too late, photronix went live with articles saying we are updating bluez to 5 and pulseaudio to latest for 14.04 lts =))))
<xnox> </joking>
<awe__> xnox!  ;D
<awe__> http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/
<rsalveti> it'll be fun
<ogra_> totally
<rsalveti> do we need bluez5 for our first device? :-)
<cyphermox> rsalveti: no we don't. it was only awe pestering me about bluez5 before, for HSP/HFP ;)
<rsalveti> right
<ogasawara> rsalveti: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng?authuser=0&hl=en
<ogasawara> rsalveti: assuming you're attending the Qt5 session next
<rsalveti> yup
<rsalveti> thanks
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Establish forward plan for Qt5 versioning | Url: http://summit.ubuntu.com/uds-1403/meeting/22158/core-1403-qt5-versioning/
 * ScottK is here. 
<cjwatson> Cool.  Do you want to / can you join the hangout?
<rsalveti> Mirv: pmcgowan: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng?authuser=0&hl=en
<didrocks> asac: ^
 * sergiusens notices that all the interesting sessions are today
 * sergiusens at least for him
<sergiusens> ... at least for me
<didrocks> sergiusens: â¦ at least for you
<didrocks> :)
<didrocks> kidding, same for me
<ScottK> probably.
<ScottK> Can someone invite me into the hangout?
<asac> ScottK: https://plus.google.com/hangouts/_/hoaevent/AP36tYfZwrD2PD85D95eFMkloDXhOD2DAOUeki4Iln_rrdj-gA8Fng
<asac> doesnt work?
<asac> ogasawara: can you invite ScottK
<asac> ?
 * lool listens to stream
<ogasawara> ScottK: I can invite you.  let me know the email you prefer I use.
<sergiusens> Mirv, just use the devel list for updates
<Mirv> sergiusens: yep, CC:d then later on there, but devel is the correct place indeed
<ScottK> I'm on and off the hangout.
<ogra_> now you are on
<ogra_> :)
<cjwatson> I'm watching IRC from time to time, at least
<cjwatson> So happy to relay if need be
<ScottK> Can anyone hear me when I talk?
<ogra_> nope
<ogra_> i cant see you either anymore
<ogra_> (you are there but camera seems off)
<ScottK> I turned my camera off to cut bandwidth.
<xnox> <xnox> cjwatson: i'd expect each major qt 5.x release to have something major in it ;-) and it did harm us not moving to 5.1 first. We only started fixing 5.1 issues post 5.1 got released, thus those fixes landed in 5.2 only.
<xnox> <xnox> ditto our 5.2 fixes are landing in 5.3 only.
<xnox> <xnox> cjwatson: ideally, we'd have touch images with 5.3-trunk available under test.
<ScottK> zero regression tolerance is a recipe for failure.
<xnox> similarly how we test openstack-trunk on ubuntu-server all the time.
<cjwatson> ScottK: I haven't heard any audio from you on the HO so far
<xnox> (and on top of 12.04 LTS as well, since we backport openstack to last LTS)
<ScottK> K. can we ask people to be quiet for a moment and I'll talk.
<cjwatson> (moment)
<ScottK> sure
<cjwatson> word-in-edgeways problems :)
<ScottK> also Qt5 going through the landing process effectively makes it a Canonical only process.
<cjwatson> ScottK: you probably want to speak slightly slower - intelligible here but there's periodic feedback or something
<ogra_> yes, you come across very choppy
<slangasek> ScottK: really can't understand you :/
<slangasek> ScottK: can you type on IRC and we'll relay?
<ScottK> k
<ScottK> need to pick a version, land it early,  and work through the issues.
<ogra_> not sure that works with the no-regression-policy we have for phone
<slangasek> ScottK: if the "issues" are that the phone image is completely unusable for 2 months of the cycle, that's not acceptable for the phone development
<slangasek> which AIUI was the state we were actually in
<cjwatson> ogra_: I'm arguing that that is a policy that is not actually required in all cases
<cjwatson> I understand why we got there
<cjwatson> But it's a continuum
<ogra_> cjwatson, probably ... its not my policy :)
<slangasek> right
<cjwatson> We don't *have* to push the dial all the way to one side
<ScottK> landing the planned major Qt5 release post FF is not acceptable either.
<cjwatson> It's a choice to do so
<cjwatson> ScottK: *nod*
<slangasek> ScottK: agreed, but just saying that we'll land it come what may and work through the regressions is also not tenable
<cjwatson> those are two ends of a scale
<cjwatson> there exists a middle ground; a couple of weeks ago we'd have had some regressions but the phone image wouldn't have been completely unusable
<cjwatson> there are definitely issues that arise from doing so, but they're maybe a bit more amenable to actually being fixed/worked-around
<ScottK> lost the call
<Mirv> manual test results https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdGI4dGllUUxyZGxhc0tZWFhqNnJaaFE#gid=0
<Mirv> for the app store apps
<cjwatson> ScottK: (it never ceases to amaze me what a flaky platform we use for vUDS, but anyway ...)
<ogra_> ++
<ScottK> can't get back on.
<cjwatson> the youtube stream has some delay but would at least let us relay back and forward
<cjwatson> sorry :-/
<xnox> cjwatson: slangasek: ideally we'd be testing /next/ trunk-qt on ongoing basis. Cause at the moment, we have no idea how much qt 5.3 is broken at the moment.
<ScottK> One team shouldn't be able to unilateral lyrics block everyone else
<pmcgowan> +1
<slangasek> ScottK: there's no disagreement on that
<ScottK>  back on
<ScottK> I like that.
<ScottK> I'd also like to talk about the process for updating the packages.
<xnox> cjwatson++
<slangasek> Mirv: fwiw, on that list, seagullstrike is the app that requires a rebuild for the Qt5.2 float ABI change
<slangasek> Mirv: (and com.ubuntu.terminal is the other, which is perhaps not listed there because it's a core app?)
<cjwatson> ScottK: the landing-silo thing, or branch handling?
<cjwatson> (or something else)
<sergiusens> slangasek, we control terminal, so it's easy to get done at least
<Mirv> slangasek: yep, terminal app has a bug about rebuild needed http://is.gd/pNalUg
<slangasek> Mirv: ok - just wanting to make sure you know that seagullstrike is expected to be red until it's rebuilt
<slangasek> (dunno if anyone's reached out to the app developer)
<lool> Mirv: will it be uploaded to the silo too?
<Mirv> slangasek: yes, popey has marked it as "ABI Change" "Yes" in the spreadsheet
<sergiusens> lool, silos for click apps aren't implemented if that's what you are asking
<slangasek> Mirv: ah, great
<Mirv> lool: terminal's a click app so it needs recompilation in the store
<xnox> ..
<xnox> we use private symbols and headers, thus we don't have abi/api compat guarantee.
<didrocks> xnox: right
<ScottK> cjwatson the landing silo thing
<pmcgowan> xnox, didrocks for apps we do, apps dont use private stuff
<lool> Mirv: ah terminal is click, right
<davmor2> too much work unless you can automated it 100%
<lool> had forgotten we had converted all core apps
<cjwatson> I suspect the answer there is going to involve making landing silos less Canonical-only - after all most of the bits are open in some ways, there are just some obstructions
<cjwatson> they are genuinely useful for being able to assemble a bunch of pieces out of band and then land in one go
<pmcgowan> but thats a good point actually, as system stuff shares the runtime
 * ogra_ never thought of them as canonical only 
<ScottK> back on
<cjwatson> it's easy for Canonical people not to notice the problems, I suspect
<ogra_> true
<ScottK> the qreal/float thing is a one time bad deal.
<cjwatson> for instance can non-Canonical people see the spreadsheet?
<didrocks> cjwatson: yeah, I took great care of that
<sergiusens> cjwatson, I was told was
<didrocks> they can even run the jobs
 * sergiusens checks
<cjwatson> do they have the slightest idea where it is? :-)
<ogra_> heh, no
<didrocks> the only thing that will be potentially conflicting is the "assignement to silos"
 * sergiusens verified train spread works as anon
<ScottK> I can see the spreadsheet
<didrocks> cjwatson: I don't think they read/opened emails on that for instance, so I would doubt about it
<cjwatson> so, I mean if the answer is that the landing silos genuinely *aren't* Canonical-only then that's good news; I'm not sure I can recall ever seeing a landing from somebody non-Canonical though
<sergiusens> didrocks, did you get that url shortner I asked for the train? :-)
<ScottK> as a practical matter they are Canonical.
<cjwatson> they are basically just branches + PPAs + automation, so it's not something that's fundamentally alien to our community processes
<ogra_> right
<ogra_> but we need to make them known broadly
<cjwatson> but they are definitely unfamiliar to non-C core-devs
<didrocks> sergiusens: I did https://wiki.ubuntu.com/citrain
<sergiusens> didrocks, awesome
<didrocks> sergiusens: thanks for the hint! :)
<sergiusens> np
<ScottK> maybe not at the same time
<ogra_> at the same release
<ScottK> I think parallel install is going to be really hard.
<ScottK> yes. by release time.
<ogra_> (thought i'm not sure how that will work anyway, touch is basically on a rolling setup already ... totally decoupled from releases)
<cjwatson> channels
<ScottK> no upstream support for parallel install
<cjwatson> I mean it's not *that* different
<ogra_> well we dont stick to anything on the release schedule
<cjwatson> sure, the touch team basically ignores saucy now, but so do lots of desktop/server developers :)
<cjwatson> we didn't have much of a feature freeze in warty either
<ogra_> and with the zero regression stuff we could even drop releases altogether
<cjwatson> releases aren't just for stability
<ScottK> I think the main issue was the zero regression tolerance.
<ogra_> and just go on rolling
<cjwatson> they're also for people not having to deal with UI changes except at fixed points
<cjwatson> talk to somebody running a university's IT department sometime :)
<cjwatson> changing the interface around in the middle of a PhD student's degree is bad news :)
<ScottK> we should jointly agree on a target version.
<slangasek> ScottK: parallel install would be hard, but I think it's something Canonical recognizes we have to eat the work on if that's what's required
<ogra_> heh, indeed
<slangasek> ScottK: do you think agreement will always be possible?
<cjwatson> I suppose it would have to be a sysroot approach, but UGH
<ScottK> slangasek: probably.
<ScottK> Kubuntu will want the latest Qt5, but will need the minimum KF5 version (5.2 now)
<ScottK> 14.10 we hope to release with a Qt5 desktop.
<ogra_> we too :)
<ScottK> we just need to remember to have the UDS session to decide
<ScottK> sure
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html
<ScottK> I don't know the future requirements
<ScottK> I have to go.
<ScottK> Thanks
<ogra_> bye
<cjwatson> ScottK: thanks, very much appreciate your time
<asac> tanks
<didrocks> thanks
<asac> thanks :)
<slangasek> ah, lunch time
 * slangasek looks at the sun in the sky
<asac> slangasek: ;)
<asac> get a burger :P
<ogra_> and sunglasses
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYfEyF4H5Ix4D_-PoNwjYSGwFkAqsn02jmgkcL9I_Ff1WUTbeg?authuser=0&hl=en
<ogasawara> for those planning to join the next "Stable Core for Ubuntu Touch" session
<ogasawara> asac: ^^
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Stable Core  for Ubuntu Touch platform beyond 14.04 | Url: http://summit.ubuntu.com/uds-1403/meeting/22162/core-1403-stable-core-platform-for-touch-beyond-14.04/
<asac> rsalveti: ^^
<asac> cjwatson: slangasek: ^^
<ogra_> bah, break already over ?
<rsalveti> hangout link?
<didrocks> rsalveti: https://plus.google.com/hangouts/_/hoaevent/AP36tYfEyF4H5Ix4D_-PoNwjYSGwFkAqsn02jmgkcL9I_Ff1WUTbeg?authuser=0&hl=en
<rsalveti> didrocks: thanks
<ogra_> gah
<ogra_> i cant click the join button under the checkmark ... no scrollbars in the HO window
 * ogra_ has to F11 it to go fullscreen and get the last 2cm needed for that
<ogra_> how crappy
<rickspencer3> o/ all
<rickspencer3> hey, I'd like to join the stable core discussion, but don't see the button
<rickspencer3> could the leader please paste me a link?
<rickspencer3> nm
<rickspencer3> I guess I was too impatient :)
<ogra_> we had to discuss if we ant you in there first :P
<achiang> o/
<cjwatson> BTW I have to step out of this session at about the :30 mark, sorry
<ogra_> easy ... we just need to double the staff :)
<xnox> s/Core/SDK/ ?
<ogra_> nope
<ogra_> OS
<xnox> ack.
<xnox> cjwatson: i mean we can be taking 5.2.x
<ogra_> xnox, we plan 5.3
<cjwatson> the consensus in the Qt session was that we were in practice going to want 5.3
<lool> dont we want to start planning for multiple 5.x versions in parallel?
<xnox> lool: cjwatson: yeah, i'd rather see qt be part of HWE packs (e.g. same way we SRU/package kernels and x11)
<cjwatson> I don't think that's realistic for 14.04
<cjwatson> coinstallation is a lot of work
<cjwatson> maybe for future releases at some point
<cjwatson> but I don't think we can be working on that basis
<lool> not for 14.04, no
<asac> ScottK: following current session?
<lool> but we could arrange for having multiple qt runtimes in the future
<asac> ScottK: would you guys have problems getting 5.3 on trusty?
<lool> even if the 14.04 one stays where it is
<cjwatson> that's trusty post-release, for clarity
<cjwatson> aiu
<cjwatson> i
<asac> yes
<asac> SRU
<asac> cjwatson: why would qt5.2 be in main in trusty?
<cjwatson> qt5 is ridiculously far down dependency stacks
<cjwatson> it's in main *now*
<cjwatson> main is closed under dependency, once you pull it in somewhere it's in, it's almost impossible to avoid
<cjwatson> of course only some parts of it are in main
<cjwatson> qtdeclarative doesn't happen to be, say
<cjwatson> but I don't think it's a useful distinction to try to draw
<ScottK> I think Qt5 major version post-release update is very risky.
<ScottK> We don't even do minor version updates in Qt4 (We have an MRE for KDE, but not for Qt)
<ScottK> asac: ^^^
<slangasek> ScottK: is that risky to the things you're doing in 14.04, or are you just pointing out that it may be risky for unity8?
<slangasek> or are you concerned about risk to other, out-of-archive work someone may be doing based on 14.04?
<ScottK> We aren't using Qt5 for Kubuntu in 14.04.
<ScottK> So from a Kubuntu perspective, it's a don't care.
<slangasek> right, but there were going to be out-of-archive ppa things using it
<ScottK> With my SRU hat on though, I think it's an incredibly bad idea.
<slangasek> so with respect to those, would qt5.2->5.3 risky?
<ScottK> yes
<slangasek> oh
<slangasek> interesting
<slangasek> so I think we would never take this as an SRU unless we did have the compatibility question locked down
<ScottK> The history with Qt and second digit updates in Qt4 and Qt5 is not great.
<ScottK> Just because things are binary compatible, doesn't mean you won't have rendering issues or such.
<cjwatson> that's indeed the kind of thing that the phone is hitting with 5.0->2
<ScottK> I recall cases where API changed because it was the only way to fix a bug.
<cjwatson> (aiui, I haven't been following very closely 'cos not my field)
<ScottK> mine nether, but not surprising
<cjwatson> the other path though is that apps can still be developed targeting the 14.04 api
<xnox> ..
<xnox> rickspencer3: but our software store is a single store at the moment, thus people _will_ get e.g. updated core-apps.
<rickspencer3> xnox, right, but that's *good*
<rickspencer3> people want updated apps
<xnox> rickspencer3: thus my point is people want updated experience.
<rickspencer3> xnox, :)
<xnox> rickspencer3: everyone wants latest android Kool Koolaid on 4 year old phones.
<rickspencer3> yeah
<achiang> yes, agree with xnox
<ogra_> ++
<rickspencer3> I think that ScottK's experience is a little chilling
<rickspencer3> it kind of violates a core assumption
<ogra_> for the phone we should simply stop doing releases ... and just go on rolling
<ogra_> imho
<xnox> rickspencer3: as long as framework5/kde (provided out of band) is considered when preparing 14.04 updates, i see no reason _not_ to e.g. update qt5.3/mir/platform-api/unity8 in 14.04 LTS.
<ScottK> I only recall one case of an API change bugfix in Qt being an issue, but it could happen again.
<rickspencer3> ogra_, what is the difference between what we are doing on phone and a rolling release?
<xnox> rickspencer3: e.g. we did backport _a lot_ performance of unity7 into 12.04.1 / 12.04.2.
<ogra_> rickspencer3, on ubuntu release day we will move one image to the stable channel and call it "release"
<tedg> Why is it dark for didrocks but not for asac ?
<asac> tedg: dark?
<ScottK> xnox: That's not at all consistent with Ubuntu SRU policy.  I think the policy makes sense as is.
<tedg> asac, Night time
<apw> he lives in a cellar perhaps
<xnox> ScottK: right, and we'd need to handle it like we handle other security-regression and sru-regressions, by resolving that.
<ScottK> xnox: You're missing my point.  A major update like that is not suitable for an SRU.  Period.
<didrocks> tedg: no, it's dark for people in europe :)
<ScottK> The way you avoid regressions is by not doing it.
<slangasek> ScottK: for me, a precondition on taking this as an SRU would be showing that we can land it /in the devel series/ without the kind of pain and anguish we've had for 5.0->5.2
<slangasek> if you're saying that's not realistic, then I don't think we would even consider pushing it into 14.04
<xnox> i think the above pre-condition slangasek points out is a good one.
<ScottK> It likely won't be as painful as 5.0 -> 5.2, but I don't think SRUable is relistic.
<xnox> slangasek: but would you hold back 5.3 from 14.10 altogether in that case?
<cjwatson> re releases on the phone, I think the value there is having a stable branchpoint in the case that we find ourselves wanting to do things that don't necessarily align with carrier QA requirements
<slangasek> xnox: we would not, because it's inappropriate for us to block Kubuntu; but we might decide to stay with 5.2 on the phone
<tedg> Usually it's not a "week" or something like that. It's a few weeks of testing. Things like full RF testing, etc.
<ScottK> Copy 5.2 to a PPA and move on.
<cjwatson> I'm afraid I have to leave at this point - I have an immovable thing I'm taking my daughter to this evening
<slangasek> no, it would not be ppa
<slangasek> we would work out the parallel installability of qt versions
<cjwatson> I dropped a few more comments to Steve which he may or may not want to feed in
<ogra_> cjwatson, enjoy (if it is something enjoyable indeed)
<cjwatson> astronomy lecture, so yes
<ogra_> :)
<cjwatson> I'll catch up with the video later
<tedg> I think with convergence it means sharing resources as much as possible.
<tedg> For instance we have a schedule from imports from Debian.
<tedg> Would Touch have a different schedule?
<ogra_> we already have a different schedule
<slangasek> tedg: imports from Debian should never impact the phone, positively or negatively, and we should have adequate CI in place to ensure this
<tedg> I'd say we should fix that the opposite why you're suggesting :-)
<rickspencer3> I agree in principle with ogra
<t1mp> when we reach the convergence and have a single ubuntu release for desktop/server/phablet, then we have to follow the "ubuntu" (desktop/server) releases
<t1mp> right?
<tedg> slangasek, That's hopeful, really. I mean it's new versions, new bugs happen.
<ogra_> t1mp, why not the other way round ?
<slangasek> tedg: bugs happen but should be caught by integration tests before we promote images
<ogra_> swithc ubuntu to be more rolling
<didrocks> ogra_: +1
<ScottK> ogra_: Didn't we already have that conversation.  Let's not have it again so soon.
<tedg> slangasek, *should* :-)
<t1mp> ogra_: does that include stop having an LTS release?
<ogra_> t1mp, no
<ScottK> If I wanted to run Debian Unstable, I would.
<ScottK> (or even testing)
<slangasek> ogra_: we discussed that already, and it was rejected
<t1mp> ogra_: so you'd have an LTS and a newer rolling version
<ogra_> t1mp, you pick one image out of the always stable set and call it LTS :)
<ScottK> Can we please not do this again.
<slangasek> saying "Mozilla does rolling updates and the sky hasn't fallen" ignores the fact that this is actually bad for users
<t1mp> ogra_: yes, but if there are, for example, security issues, you want to patch the LTS
<t1mp> ogra_: without bringing in all the new stuff from the rolling release
<ScottK> t1mp: You're just repeating arguments we already had.
<t1mp> ScottK: yes I'm realizing that
<xnox> rickspencer3: do we have the u-name yet?! =))))
<ScottK> It's at least a month early for that.
<t1mp> ScottK: I didn't follow the discussion too much the previous time. But I'll just wait see what the people who thought about it come up with :)
<xnox> rickspencer3: well, you have the device kernel, which is non-changing.
<xnox> rickspencer3: you will get new libc for example.
<t1mp> *wait and see
<t1mp> ScottK: did the previous discussion include phone images?
<ScottK> No, but it's doesn't change the fundamental argument.
<t1mp> phones have different requirements, I think you want an LTS on a server, but rolling on a phone (no LTS)
<xnox> rickspencer3: kernels is a bad example, as we have per-device kernels, no devices run "linux-generic".
<ChickenCutlass> rickspencer3: the only real reason to move to a new android is mainly to support new hardware where the drivers only exist there.
<tedg> Seems like it'd be pretty optimistic, as for instance a new init system requires kernel features.
<tedg> Let's talk about the kdbus transition
 * ScottK doesn't want rolling on a phone.  I'd like something to have been tested and integrated before it lands on the handset I'm using.
<slangasek> ScottK: I think you're misunderstanding what "rolling" means here
<ScottK> Perhaps.
<xnox> rickspencer3: our update channels are on per-device basis, thus e.g. stable/mako stable/maguro both (typically) have latest rootfs, yet device tarballs are different and can be on per-device cadence.
<slangasek> it's taken as gospel that any update is tested and integrated before it hits the stable channel; but that stable channel will update at a much higher cadence than 6mo
<ogra_> xnox, not true ... maguro doesnt (it could though)
<xnox> ogra_: there is no ubuntu-archive, or system-image update limitation.
<ogra_> (which in turn proves we can just lock one single device to a version )
<t1mp> ScottK: new features are tested and integrated, and then land in rolling. So new features go there, but new features don't go in LTS
<ogra_> xnox, right, it was a decision we made
<xnox> ogra_: furthermore decision to drop maguro, is not a technical one, since cyonagenmod did port it to 4.4 base.
<ScottK> OK.
<ogra_> yep
<rsalveti> xnox: they did, but full of critical bugs
<rsalveti> and that's why google didn't decide to support it officially
<xnox> rsalveti: sure. but we can reupload older android base as android-maguro and build the old 4.2 android image for it. (we don't want to, cause it's not a meizu/bq :P)
<rsalveti> xnox: atm, yes
<achiang> how do people opt-in to unity8 on desktop today?
<ogra_> by installing a metapackage
<slangasek> ogra_: we *can* lock a device to a version of the rootfs, but it's shooting ourselves in the foot to ever do that for production devices
<ogra_> yeah
<didrocks> achiang: they do install either unity8-desktop-session-mir or unity8-desktop-session-x11, then there is a new session in lightdm
<slangasek> we do it for maguro because that's for internal dogfooding purposes
<slangasek> but we shouldn't do this for real devices
<ogra_> tell that to i.e. samsung :)
<achiang> seems like we should keep that same mechanism for 14.04 release
<slangasek> do I need to be telling that to samsung?
<slangasek> I think it's achiang's job to tell them that :)
<ogra_> well, they probably provide two updates in the lifecycle of a phone
<ogra_> ah, heh, yeah, indeed
<tedg> Staticly compile it all!
<rsalveti> I wonder if the vendor would also need to certify a newer stack/release
<tedg> :-)
<rsalveti> major one at least
<xnox> tedg: juju doesn't upload into the archive =)
<sergiusens> tedg, that's why we are rewriting everything in go ;-)
<ogra_> go go go
<tedg> I guess I just don't understand who wants their phone to change more frequently than every 6 months.
<tedg> :-)
<ogra_> you dont get much in contact with teenagers, eh ?
<rsalveti> you'd be surprised
<ogra_> :)
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/12/%23ubuntu-uds-core-1.html
<sergiusens> tedg, it doesn't even need to be an improvement
<sergiusens> just change icon colors or something
<sergiusens> :-P
<tedg> Can we just rotate the backgrounds?
<tedg> Daily?
<sergiusens> exactly
<slangasek> tedg: I don't want to wait 6 months between security updates!
<achiang> slangasek: you can be on the devel channel then ;)
<asac> good one
<tedg> slangasek, I have nothing to hide, I'm not a terrorist.
<asac> the devil channel :)
<asac> lol
<slangasek> achiang, tedg: could you please coordinate your trolling
<slangasek> I'm having trouble following all of this
<ogra_> just change the version number :P
<ogra_> hmm, my HO locked up
<tedg> slangasek, Just wait for the promoted troll
<ScottK> slangasek: +1 on phone security updates.  solve getting those to end users quickly and consistently and that'd be a real advantage.
<slangasek> ScottK: right... for the moment, the proposed model for doing that is frequent rolling updates, but this probably needs to be revisited once we have more real phones in the field
<ScottK> So I lose use of the phone for $MINUTES where the value might be more than a single digit for each security update?
<ScottK> (base on how long Andriod system updates take, I don't know if that's a fair comparison)
<slangasek> ScottK: eh, I don't know how long the downtime will be for the updates... hopefully we'll do better than that.  But the basic update model will still require a reboot to recovery
<slangasek> (there are reasons we're doing image-based updates, for devices that we have no text console or recovery media for)
 * ogra_ hopes we'll do image based updates on other devices too in the future :)
#ubuntu-uds-core-1 2014-03-13
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/13/%23ubuntu-uds-core-1.html
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Click Framework handling | Url: http://summit.ubuntu.com/uds-1403/meeting/22221/core-1403-click-framework-handling/
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYe9ZYPzrxTId__au2dBIegrg3YnxJSGY5SSyBDCBvU9H6prWw?authuser=0&hl=en
<ogasawara> lool: ^^
<rsalveti> morning folks
 * ogasawara waves
<ogasawara> I'm not really sure who owns this click framework handling session
<cjwatson> lool, I believe
<jdstrand> yes, he seemed to create it... yesterday?
<jdstrand> maybe tuesday
<ogasawara> just waiting a few mins folks
<zyga-uds> you are live
<lool> https://wiki.ubuntu.com/Click/Frameworks
<zyga-uds> will any of the base frameworks be backported to 14.04? say, 14.10 base frameworks? or is the train only going one way?
<xnox>  /all _3_ of them/ =)))
<zbenjamin> Do you know already when the new framework will be available in click chroots?
<tedg> Do we plan on provide an SDL framework tag?
<sergiusens> zyga-uds, almost sure it's a runaway train never coming back
<tedg> Guessing games don't want to depend on html or qml.
<zyga-uds> so you cannot release stuff that gives new features on LTS releases, that's not good IMHO
<sergiusens> zyga-uds, should of attended yesterday's session about stable core ;-)
<cjwatson> zbenjamin: once this is all definitely agreed for real, and Qt 5.2 is landed - so I guess next week
<xnox> lool: jdstrand: i guess "framework-qtwebkit" "framework-oxiede"
<zbenjamin> cjwatson: awesome! thx :)
<jdstrand> xnox: noooo!!!!! :)
<xnox> jdstrand: OKKKKKKKK!!!! :)
<tedg> Can we just remove the symbols from the library?
<jdstrand> it just should be on the deprecated/not supported list, just like any number of other apis
<tedg> I mean, if we don't think app developers should use it, really no one should.
<xnox> jdstrand: are we shipping qtwebkit on the phone image? just purge it from the ubuntu-touch images and be done with it.
<jdstrand> tedg: we could probably do that now. I doubt we could when kde starts using qt5
<xnox> tedg: universe can use anything they want ;-)
<rsalveti> yeah, we just don't want it to be used on touch
<dobey> jdstrand: well, if upstream is abandoning qtwebkit too, by the time kde switches, it might be gone anyway?
<tedg> We could split into a libqt and libqt-deprecated and just have the dpkg tools figure out which ones are needed. Touch could just not install the deperecated one.
<jdstrand> the reviews tools warn on it. once oxide is in the archive, we can error on it if we want
<dobey> but qtwebkit is also a separate binary package no? can't we just not put it on the phone image?
<jdstrand> and the review tools are part of the sdk now, so, that is pretty strong prevention
<rsalveti> but upstream is deprecating it but proposing a replacement as well
<jdstrand> yep
<xnox> rsalveti: upstream replacement is their own engine?
<rsalveti> xnox: yes, kind of similar to oxide
<jdstrand> they are developing a chromium content api based engine too
 * jdstrand feels a question coming on
<xnox> lool: cjwatson: well sdk-libs-dev is for the click chroot =) sdk-libs is runtimes only installed on the phone
<jdstrand> here is why we are doing oxide: http://www.chriscoulson.me.uk/blog/?p=196
<rsalveti> we want oxide :-)
<jdstrand> yes :)
<rsalveti> I'd love to land it today if I could :-)
<jdstrand> it is getting really close
<xnox> jdstrand: and qt upstream doesn't want oxide? can't we submit oxide upstream ? =)
<jdstrand> rsalveti: I don't think it ever hit the list, but we did benchmarks against qtwebkit-- oxide has very better support (like, everything works whereas on qtwebkit, it couldn't run all the tests), it pretty much blew away qtwebkit on performance on everything
<ogra_> rsalveti, just land it ! we can blame Qt5.2 for any breakage :)
<rsalveti> haha :-)
<rsalveti> jdstrand: awesome, good to know
<tedg> I don't always have libraries pull in daemons, but when I do, it's mostly to harass xnox.
<jdstrand> xnox: "Q: Isnât Qt already switching to Blink?" "A:
<jdstrand> Iâm aware of Qt WebEngine, although this was announced after Iâd already started work on this. However, whilst itâs great that somebody else is doing something similar, this would not solve our original problem â which is that we want something we can properly support for 5 years.
<jdstrand> Also, Oxide isnât particularly tied to Qt. Itâs been designed to support new ports fairly easily (eg, I might add a Gtk port in the future)
<jdstrand> "
<jdstrand> xnox: we plan to share code, patches, expertise, etc where we can
<cjwatson> xnox: sure - have you checked lately whether it's multiarch-coinstallable?
<cjwatson> xnox: we'll probably need to make it sdk-libs-papi-dev etc. or something
<xnox> cjwatson: i believe there are still unresolved pieces that cropped up. I'll double check.
<jdstrand> rsalveti: the hardware acceleration is really pretty exciting. it was cool watching a HD Rush concert video on youtube on my phone :)
<xnox> cjwatson: "papi" ?! (as in papi don't preach?!)
<cjwatson> platform API
<rsalveti> jdstrand: but is it using hardware acceleration for video decode?
<xnox> cjwatson: oh, ok.
<cjwatson> xnox: see https://wiki.ubuntu.com/Click/Frameworks
<geddy> jdstrand:glad you liked our video
<jdstrand> geddy: :)
<sergiusens> lool, you shouldn't need to provision anything
<jdstrand> rsalveti: ask chrisccoulson for details, but yeah, that is my understanding
<xnox> cjwatson: right so -qml will install runtime libs without any "-dev" packages (headers), whereas -pappi will pull in "-dev" packages.
<cjwatson> something like that ... we'll need to thrash out the package-level details
<rsalveti> jdstrand: interesting, it'd need to use gstreamer to be accelerated, I believe you just used ffmpeg internally (and was fast enough to render a HD video)
<cjwatson> -qml would need to install the qml bindings, -papi couldn't
<cjwatson> *wouldn't
<xnox> rsalveti: ffmpeg is purged from touch images, is oxide shipping it's own ffmpeg?
<lool> looking at questions
<rsalveti> xnox: need to check
<lool> are there questions that we should cover now in the HO?
<jdstrand> rsalveti: I recommend you talk to chris :)
 * jdstrand hasn't been in deep on that
<rsalveti> jdstrand: yeah :-)
<jdstrand> geddy: so, I don't know if you are the actual Geddy Lee, but I am going to believe you are and say, you made my day :)
<geddy> jdstrand:we are the priests!
<sergiusens> can we have a meta 'dev' framework which is marked unstable and then tag/define at the end of the cycle?
<cjwatson> I don't understand what value that would have
<jdstrand> geddy: :)
<cjwatson> we should just be able to update qtcreator to default to the newest available for 14.10 (say) when building an app against 14.10
<cjwatson> (which you'll only need to do if you're using facilities only available there, anyway)
<geddy> jdstrand:now i just have to convince alex that suse is a dead end. and we won't even talk about neil's love for that redmond OS.
<sergiusens> cjwatson, the sdk has removed components during development; so if I publish my app early in the cycle and care not to update it when things are removed, at the time of upload it would be compatible but not in the future
<sergiusens> jdstrand, are there going to be more policy versions per framework? if not, can't it be implicit?
<lool> are there any questions around frameworks
<cjwatson> sergiusens: I get that; but part of the point of declaring frameworks is that we can scan the store for stuff that's broken and rev it
<cjwatson> sergiusens: a single dev framework would actually make that harder
<cjwatson> we would have no idea what it actually referred to; and it would require pointlessly revving things for the tail-end of a cycle, since the last -devN framework would imply the same ABI as the final release
<sergiusens> cjwatson, that last sentence convinced me fully
<cjwatson> ok, good :)
<lool> ogasawara: THanks
<lool> And sorry for the late start
<ogasawara> np
<sergiusens> convinced was a stong word; but yeah
<zyga-uds> will this be summarized somewhere
<lool> router reconnected a couple of minutes before the hour
<zyga-uds> lool: ^^
<lool> zyga-uds: wiki page + this hangout
<tedg> How are we detecting whether the framework ABI changed?
<tedg> Seems like per-image we could do some sort of automated capture?
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYfjer1QM4nh5HLO8m_Vzu08XaxQsS7wGC7DeOyhqNHgyo-tQw?authuser=0&hl=en
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Carrier/OEM Customizations | Url: http://summit.ubuntu.com/uds-1403/meeting/22218/carrieroem-customizations/
<ogasawara> Carrier/OEM Customizations ^^
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYfjer1QM4nh5HLO8m_Vzu08XaxQsS7wGC7DeOyhqNHgyo-tQw?authuser=0&hl=en
<jdstrand> did someone post the hangout link for this? I likely won't have a ton to add, but do have a question or two for the end
<ogasawara> achiang: ^^
<jdstrand> ah
<jdstrand> :)
<zyga-uds> live :-)
 * zyga-uds worked on carrier image customization for a few years and will listen carefully looking for issues
<cwayne> bzr branch lp:savilerow
<ogra_> what i was always wondering was: what happens if we update the system underneath the customization, how to we make sure we dont trash the OEMs stuff ?
<rsalveti> cwayne: we need to add the custom.prop feature at http://people.canonical.com/~achiang/ubuntu_savvy/ as well
<ogra_> is that already used ?
<ogra_> (i know we can process it already)
<rsalveti> it can be used, yes
<rsalveti> and it was for mwc
<sergiusens> ogra_, you are on a channel that include the customizations
<zyga-uds> have we done some research on what carriers want to customize?
 * zyga-uds has some ideas but that's just one drop of experience
<ogra_> sergiusens, so that channel is owned by the OEM ... which means that it will oonly get updated once the OEM also updates the tarball ?
<ChickenCutlass> achiang: I love demos
<sergiusens> ogra_, that's political and I guess depends on achiang
<ogra_> sergiusens, which in the end means the OEM decides if security updtaes are even getting to users ?
<sergiusens> not sure if the trbal is to be sent here or they get their own channel/server
<ogra_> well, it sounds like it would be somewhat pointless if we couldnt bypass the OEM for security fixes in the rootfs
<sergiusens> ogra_, well the custom tarball could be a one time thing and it extends the ubuntu_commands
<sergiusens> so I see no problem in it being a central thing
<ChickenCutlass> achiang: cwayne can you talk about how this approach preserves the update process and avoids conflicts in the archive
<sergiusens> but that decision is political
<ogra_> right, i just try to understand how it works ... i would expekct us to be able to still independently provide a new rootfs
<sergiusens> ogra_, well if you look at https://system-image.ubuntu.com/trusty-customized-demo/manta/index.json you'll see it's the same ubuntu rootfs
<sergiusens> and the custom stuff is basically a drop on a specific location of the filesystem
<ogra_> sergiusens, right, my question is can we provide a new rootfs and the tarball will still cope
<sergiusens> it should
<ogra_> sinnce i dont expect the OEM to update the tarball at the same frequency as we upgrade the rootfs
<sergiusens> ogra_, look at one of the delta updates; it's only rootfs
<sergiusens> ogra_, type: delta in the json
<ogra_> right ..
<ogra_> achiang, thanks !
<rsalveti> ogra_: the oem carrier might end up having a specific system-server, that would then use the same rootfs
<rsalveti> but they might want to decide when to push updates to the user
<sergiusens> ogra_, this only depends on that API that achiang is just talking about
<rsalveti> so that can be better tested and so on
<sergiusens> if it doesn't change; it will keep working
<ogra_> rsalveti, right, i dont really like that since they can hold back security fixes etc
<sergiusens> rsalveti, yeah, but that's more politics than anything else
<lool> achiang: customizing the launcher is common on android
<rsalveti> ogra_: sure, but I'd guess they need to test and validate before pushing updates
<tedg> achiang, One thing that I think we don't have support for is custom APs. So as an AT&T customer I autologin to their Wifi network.
<lool> achiang: and we might want to allow for different launcher designs in this or that form factor
<karni> tedg: interesting point on custom APs
<ogra_> tedg, easy to fix by shipping the right NM config files
<tedg> karni, It's a custom AP, but also protocol to login. If I'm not an AT&T customer I have to agree to T&C to get access.
 * karni nod
<cyphermox> indeed
<rsalveti> I know we want to push down the rootfs for our users, but I'm just concerned how we'll validate that
<rsalveti> we believe an update will not break anything, but we'd need to test for real to make sure we're good
<karni> cwayne: no worries :)
<ChickenCutlass> achiang: cwayne is the idea that the OEM would run this tool themselves?  Or do we run it for them?
<karni> All, this is just a prototype, not a working solution yet.
<karni> ChickenCutlass: they run it
<ChickenCutlass> right
<achiang> lool: tedg: thanks for the ideas, i've added them to the pad
<achiang> ogra_: did we answer your question re: security?
<ogra_> achiang, half way, yes ... the OEM still runs an s-i server and needs to pick up the rootfs from us, or not ?
<ogra_> i.e. they can hold back security fixes
<gQuigs> will we support users uninstalling/disabling some/all of the OEM content?
<lool> rsalveti: same image tests have to rerun on top of the custom image, with additional tests for the customized bits?
<lool> e.g. check that the custom bookmarks are indeed the expected ones
<cwayne> lool, yes
<rsalveti> lool: yes
<karni> ogra_: I believe we release rootfs updates, not OEMs
<rsalveti> lool: it's fine if we have a few devices, but once we increase that number, it'll be harder
<ogra_> karni, so we need to run the s-i server for them
<ogra_> karni, if the server is in their hands it will want to ship all pieces together (device, rootfs and customization tarballs)
<xnox> is alex on irc here? what's his irc nick?! =)
<gQuigs> will this be applicable for PC OEMs too?
<cjwatson> xnox: achiang
<ogra_> which means they meed to import the rootfs
<karni> xnox: achiang
<ogra_> gQuigs, once desktop is converged enough to also use image based updates :)
<gQuigs> ogra_: right
<xnox> achiang: "oem-customize" ~= "cloud-init-style" =)
<achiang> ogra_: it is not clear that the OEMs will host the s-i servers
<ogra_> k
<achiang> ogra_: so i would say that question is still open
<ogra_> well, if we want to offer that feature, we should probably reconsider the s-i design
<ogra_> so that they only provide a customization server ....
<lool> rsalveti: I'm not sure why it gets harder; I mean, these devices have to be supported anyway, so it's about keeping the tests working; if you mean OEMs might stop caring, it's kind of the same problem no matter what (just like drivers support)
<ogra_> (for hardware and custom tarball ... but the rootfs comes from us)
<xnox> achiang: "go!"
<ogra_> go !
<ogra_> *snap*
<karni> cwayne: hold on with demoing while achiang is talking
<tedg> achiang, Are you saying some OEMs run RHEL?
<cjwatson> running click install on other systems may be interesting
<tedg> ;-)
<karni> cwayne: whatever you're doing is all in a small thumbnail (unless you speak up)
<cjwatson> I think it might actually be easier to just freeze the interfaces we care about and let Ubuntu Savvy reimplement them portably; not sure
<rsalveti> lool: harder as we need to coordinate more stuff :-) and make sure we're not the ones entirely responsible for the testing side of it
<cjwatson> rather than trying to port gobject-introspection to OS X ;-)
<sergiusens> achiang, it's fast to write go
<ChickenCutlass> achiang: do you support QNX
<sergiusens> lol
<ogra_> ChickenCutlass, only the unity8 version of QNX
<gQuigs> fair enough :)
<gQuigs> the other one got answered
<gQuigs> that makes sense to me, thanks!
<achiang> jdstrand: did you ahve a quesiont for us?
<lool> achiang: system update settings might be worth overriding too
<jdstrand> achiang: well, I did, but it didn't seem to fit. it was bringing up the old mailing list discussion wrt to apparmor policy, udev, rules, etc
<lool> update frequency, automatic updates, update server etc.
<cjwatson> achiang: click build is intended to work on any system that has python
<lool> which are customizable in the conf file
<cjwatson> achiang: I intend to keep it that way
<sergiusens> jdstrand, there's anothe session for that
<cjwatson> achiang: but the rest of click has no such guarantees
<sergiusens> jdstrand, later today
<jdstrand> ah, ok, good
<achiang> cjwatson: ack
<cjwatson> achiang: (also this is theoretical rather than tried, but it shouldn't be hard to fix)
<jdstrand> sergiusens: thanks
<sergiusens> achiang, it's not a full full port ;-)
<cjwatson> I'm not interested in click/go because I need to be able to provide a C API
<jdstrand> achiang: nm, sergiusens told me there is another session on that
<sergiusens> jdstrand, http://summit.ubuntu.com/uds-1403/meeting/22219/core-1403-hardware-handling-touch/
<tedg> achiang, Do we expect OEMs to significantly alter the base package set in any cases? i.e. a tablet manufacturer that wants to ship X11 support on their tablet.
<ogra_> jdstrand, next session covers HW decoupling
<cjwatson> I'd caution anyone who's reimplementing it to be very very careful :)
<ChickenCutlass> tedg: what's X11
<jdstrand> yikes, please let's not reimplement click
<rsalveti> x11 is not touch :P
<rsalveti> you can then ship ubuntu desktop
<tedg> ChickenCutlass, Enterprise features :-)
<tedg> I guess I was more worried about supporting connecting to your network servers or some such.
<tedg> Like I could see an IT focused device or something.
<sergiusens> the terminal app is a special case; if it's to prevent them from using it; it's not going to work as they can still install it
<sergiusens> if it's just considered _cruft_ in the image; it's fine either with the unregister or just not adding it
<cwayne> i'd say its not preventing use so much as not preinstalling
<xnox> .... terminal-app by default was a silly idea
<ogra_> nah
<ogra_> terminal app is great
<ogra_> we should just give OEMs a discount to not remove it ;)
<rsalveti> I don't think it's a silly idea
<sergiusens> xnox, talk to the elders of the internet; they convinced the product owners to add it :-P
<xnox> sergiusens: oh, i'm in big dept to the elders of the internet. I should shut up about this =)
 * xnox quickly purges logs
<gQuigs> we won't have X11 compatibility?   so only QML apps will work?
<lool> gQuigs: on touch
<tedg> gQuigs, Only things that support Mir.
<lool> gQuigs: but on desktop we will support X apps on top of Mir
<sergiusens> exactly,  failure would be to rebuild the rootfs
<gQuigs> how would we do convergence then?
<gQuigs> right, Xmir support is in, right?
<lool> gQuigs: probably not on mobile devices
<lool> it's not a technical limitations
<gQuigs> on tablets it  makes more sense...
<lool> it's more that you want mobile apps to be designed for touch, so you're looking at QML apps designed for this
<lool> or custom apps
<ogra_> gQuigs, it will be in for the phones that can become desktops
<tedg> lool, The question is more about running your phone with a keyboard and monitor case.
<ogra_> but generally we wont ship XMir for "normal" phones
<lool> right, in which case you get the desktop experience
<lool> which might involve X
<lool> but there are many cases of convergens
<tedg> So you'd need xmir, at least for a while.
<lool> *convergence
<tedg> Not sure if we shouldn't define a framework for that.
<gQuigs> thanks!
<tedg> So apps that need it, could specify that they need it.
<zyga-uds> sounds good
<tedg> achiang, Sounds good, thanks!
<cwayne> zyga-uds, do you have any particular areas of customization that we're missing?
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYd8oAPzkFdRqF_9QBHXxAJwSNQkkUCZfWIyp2dGLwfuzYqoYQ?authuser=0&hl=en
<ogasawara> ogra_, ChickenCutlass ^^
<ogasawara> for your next session
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Handling hardware solely from the android img files | Url: http://summit.ubuntu.com/uds-1403/meeting/22219/core-1403-hardware-handling-touch/
<rsalveti> https://plus.google.com/hangouts/_/hoaevent/AP36tYd8oAPzkFdRqF_9QBHXxAJwSNQkkUCZfWIyp2dGLwfuzYqoYQ?authuser=0&hl=en
<rsalveti> argh
<rsalveti> http://pad.ubuntu.com/uds-1403-core-1403-hardware-handling-touch
<xnox> ogra_: sergiusens: keying onto android-system.img is a bad idea. In system-image update mode, custom-per-device things are shipped inside a device tarball. Adding !android things inside android-system.img sounds like a recipe for disaster =)
<apw> ogasawara, are you proposing bind mounting each and every file in the overlay ?  do we ahve a view to how many that is, and the scalability of that
<apw> ogasawara,
<apw> argle
<apw> ogra_,
<ogasawara> :)
<xnox> ogra_: sergiusens: why not ship extra things in the device tarball?
<sergiusens> xnox, that's the idea
<sergiusens> xnox, what we discuss is how to make it available to the components tat need them
<ogra_> xnox, thats what we are discussion
<sergiusens> xnox, oh, so device != android device (system.img)
<ogra_> xnox, the device tarball *is* system.img from android
<awe> whomever is typing, *please* mute yourself
<janimo`> ogra_, were overlay filesystems considered?
<apw> janimo`, those do not necessarily exist in the older kernels these devices have
<janimo`> apw, situation is improving though, as OEMs move to newer kernels. But good to know that is the main blocker and not some technical detail
<janimo`> since then we could have a single overlay not several bind mounts
<apw> several thousand potentially
<janimo`> apw, and we touch the kernels anyway
<ogra_> janimo`, i think stgraber tested with overlay stuff before designing the current solution
<ogra_> and we dont want to put such a penalty to porters
<janimo`> ogra_, would be good to have an analysis of that. We have too many bits of knowledge in people's heads only
<ogra_> ask stgraber he analyzed it
<apw> ogra_, could we consider inverting, ie make the root the writable bits, and symlink the non-modified bits into it
<ogra_> apw, from the initrd, yep
<apw> ogra_, i mention this cause we have had trouble with large numbers of mounts cause severe performance issues
<xnox> ogra_: device tarball is _system.img from android, see for example are http://system-image.ubuntu.com/pool/device-456bc5a53bcbb0481be13acacc4de673433c4ea0255ffabe0cbc35925481715d.tar.xz
<xnox> ogra_: that has boot.img, recovery.img and system image as a folder unpacked.
<sergiusens> xnox, yeah, but I was slapped for not making the specific distinction :-)
<ogra_> xnox, thats what i said
<ogra_> xnox, boot.img isnt touchable for us ... (kernel and initrd) recovery isnt intresting ... so stuff needs to live in system.img
<victorp_uds> ChickenCutlass: we need a single process that works for both reference devices and products that go to shops
<ChickenCutlass> victorp_uds: totally agree.
<rsalveti> ogra_: what you mean a true x86 device?
<rsalveti> we have android running on a true x86 device :P
<ogra_> rsalveti, a desktop
<awe> ogra_, most of your examples are conf files, would your proposal work for binary files ( ie. libraries/plugins )?
<ogra_> awe, sure
<ogra_> bind mounts are bind mounts :)
<ogra_> they dont care which files you bind mount
<awe> sure...
<ogra_> for libs you would need an ldconfig run though
<ogra_> which makes it pretty complicated
<awe> but not necessarily for plugins
<ogra_> right
<awe> ( which is what I'm thinking of.  eg. ofono dynamic plugins )
<ogra_> yeah that should work just fine
<ogra_> root@ubuntu-phablet:/# ls /var/lib/lxc/android/pre-start.d/
<ogra_> 10-no-adbd     25-process-overrides   40-brcm_patchram_plus-disable
<ogra_> 15-no-uchroot  30-no-surface-flinger
<ogra_> 10-no-adb is the generic script to always disable adb inside the container
<ogra_> 25-* is for developer use only to replace files inside the system.img
<sergiusens> ogra_, to be honest we need to move that to android
<ogra_> 15-* is legacy
<ogra_> sergiusens, did ondra bribe you now ?
<ogra_> :)
<sergiusens> ogra_, nope
<sergiusens> ogra_, but the adb one is just dirty :-)
<rsalveti> most can be just removed
<ogra_> 40-brcm_patchram_plus-disable is actually something i was hoping to get input from cyphermox
<sergiusens> ogra_, surfaceflinger one is just a temporary thing
<ondra> ogra_: :)
<ogra_> sergiusens, yeah. most can go
<ondra> tarball again
<ondra> and next thing  is overlay
<ogra_> heh
<victorp_uds> ondra is this a drinking game?
<victorp_uds> tarball --> shot
<ondra> victorp_uds we should :D
 * victorp_uds drinks
<ondra> ogra_: your hangout is fine considering your line speed :)
<victorp_uds> ogra you need to move
<ogra_> haha
<cwayne> ogra_, just build shit on chinstrap :P
<janimo`> xnox, OEMs would not want to build debs, but stick to the tools and processes they are familiar with
<victorp_uds> \o/
<victorp_uds> ChickenCutlass:I want a faster internet too
<cwayne> ill take one while youre up
<awe> shot time
<ChickenCutlass> victorp_uds: no problem.
<ChickenCutlass> fast internet for everyone
<xnox> janimo`: right, at the moment we expand everything to a flat tree. and compile the image.
<janimo`> xnox, the ansroid tree also has ubuntu hooks already, like hybris and platform-api
<xnox> janimo`: we don't depend on /debs/ at all.
<janimo`> xnox, ok I misunderstood what you were avocating then
<janimo`> xnox, I thought we now have various udev rules and such in dev specific packages
<janimo`> like lxc-android-config
<ogra_> root@ubuntu-phablet:/# mount|grep system
<ogra_> /dev/loop1 on /android/system type ext4 (ro,relatime,data=ordered)
<janimo`> ondra, is that decided? Is the loop mounting only on nexus devices?
<cyphermox> ogra_: 40-brcm_patchram_plus-disable we need to get rid of
<ogra_> cyphermox, yeah
<janimo`> ondra, why? The android build will be a different rebuild of the same tree
<ogra_> cyphermox, but i think your bluettoth reworking covers it., right ?
<cyphermox> yes
<ogra_> great
<cyphermox> it would, haven't started yet
<cyphermox> next week
<lool> xnox: I think ondra is right that an update of android.img will cause hte whole file to be included
<ogra_> i'll add that info to the etherpade
<cyphermox> ogra_: and just bringup bluetooth and wifi from the init.whatever, and have on the ubuntu root have just one single, extremely simple upstart job that pokes the standardly named android init job to start bluetooth
<ogra_> yeah
<ondra> janimo`: no loop mounting on product
<awe> ogra_, how do these files get into the android.img?  Are you proposing they go into a standard place, and where is that?
<lool> I dont quite get the big deal, I dont think we like loop mounting, we want to avoid it; it's either by technical constraint on existing device (nexus 7) or by lack of time that we havent moved to partitions
<lool> loop mounting is just a fallback feature
<xnox> awe: we'd need to modify the upgrader script, inside the upgrade tarball, to look at those files and slap them on top of the read-only image.
 * victorp_uds finished the bottle
<ogra_> cheers
<lool> ondra: but what about tarballs and overlays?
<lool> j/k
 * ondra drinking :)
<lool> no mention of union filesystems so far!
<ondra> lool: :)
<ondra> ogra_: android system.img in the rootfs, imagine you get to repair shop which will try to fix your phone with flashing new Ubuntu version (mean formating rootf), bang you just bricked the phone :)
<ogra_> ondra, well, screw that shop if it doesnt use ubuntu-device-flash
<ogra_> :P
<awe> achiang, do a shot
<ogra_> cheers
<ondra> ogra_: it's product for consumers and we need to think about entire life cycle of device
 * ondra is getting drunk
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/13/%23ubuntu-uds-core-1.html
<ondra> ogra_: copying files around? :)
<ogra_> yeah :)
<victorp_uds> 5 bottles
<ondra> that was fun
<xnox> ondra: most fun session this vUDS for sure.
 * ondra is going to tar entire drive, just because I can :)
<xnox> ondra: have you seen wubi design? =))))
<ondra> xnox: nope
<ogra_> omg
<xnox> ondra: chain-boot windows into grub, which mounts NTFS partition (C:/ drive), then creates a thin image, loop mounts, unpacks ubuntu-desktop tarball, execs kernel/initramfs from that and uses that as a rootfs.
<xnox> ondra: thus giving you "ubuntu-app" on windows, which you can uninstall from control-center, yet able to boot into =))))
<ondra> almost ubuntu touch boot sequence :P
<ondra> xnox: number of loop and bind mounts is crazy
<ogra_> the prob with your partition attempt is that we have nothing designed to handle such a case today .... and i guess we need the devices first to properly do that
<xnox> ogra_: it's a chicken and egg problem, we need to pick one and start iterating....
<ogra_> right, but its a completely new design nobody has taken into account up to now
<ogra_> (smells very 14.10ish)
<xnox> ogra_: i've attempted proposals to do if for the emulator a few times by now.
<xnox> ogra_: but it keeps on bit-rotting.
<ogra_> i know slangasek initially played a bit with partitions ... but gave up due to the bad nexus 7 HW design
<slangasek> no, I stalled out because I got pulled into other things
<slangasek> it was entirely workable on the N4, which I also have here
<ogra_> then we made the decision for loop and this topic got forgotten
<ogra_> slangasek, right, but we will need some massive changes in the tools i suppose
<slangasek> a fair amount
<ogra_> since today they are all only designed for loop devices
<ogra_> which smells to me like "not for trusty" material
<sergiusens> ogra_, the word porters was involved t the time as well
<ogra_> yeah
<ogra_> and dual boot surely also plays a role
<ogra_> (we should invite someone like Tassadar to such a discussion since he maintains the most widely used dual boot setup atm)
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Boot experience on hidpi displays | Url: http://summit.ubuntu.com/uds-1403/meeting/22157/core-1403-hidpi-boottime/
<ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYfJU5nwXnVFKmHs-o5Qa3T70FlyMMXccK_Uo0Idc8go0VD89Q?authuser=0&hl=en
<ogasawara> slangasek: ^^ did you want in on this next session?
<slangasek> ogasawara: watching from the sidelines
<bregma> is there a URL to join?
<xnox> bregma: https://plus.google.com/hangouts/_/hoaevent/AP36tYfJU5nwXnVFKmHs-o5Qa3T70FlyMMXccK_Uo0Idc8go0VD89Q?authuser=0&hl=en
<bregma> ta
<slangasek> grub2 build-depends: fontconfig
<slangasek> (and pango)
<cjwatson> slangasek: NOOOO
<slangasek> ;)
<slangasek> just the notion of trying to get pango to build for the target is giving me gigglefits
<apw> cjwatson, i can see the virtual console on both here, so it is meant to show, binary drivers == fail
<cjwatson> that's what I thought, ok
<apw> xnox, i assume if you pass that to the kernel, the kernel would be ignoring it yes?  and letting userspace handle it
<xnox> apw: yeah, /proc/cmdline interface =)
<apw> xnox, right that was what i was thinking
<slangasek> oh, I thought blogs were external memory storage so you didn't have to remember what you'd done ;)
<xnox> apw: does kernel / drm give DPI informations, physical dimentions, pixel information?
<apw> xnox, i thought that was all edid infor, which i thought we just emitted in binary
<xnox> can you elaborate more?
<xnox> oh
<apw> xnox, so as cjwatson says a drm driver generally emits the edid (documented on wikipedia) in /sys/class/drm/card0-HDMI-A-1/edid
<slangasek> read-edid
<slangasek> edid-decode
<slangasek> if it lies, you RMA the hardware :P
<xnox> slangasek: i have alot of RMA experience. At the moment, only two things are still working from my last PC>
<apw> 12Horizontal display size, mm, 8 lsbits (0â4095 mm, 161 in)
<apw> from the edid
<slangasek> so there are EDID-quirking databases somewhere... I don't remember if the kernel has the one in current use?
<apw> i am sure we don't have any
<slangasek> ok
<slangasek> so maybe that was always only an X thing
<apw> cjwatson, there _is_ some form of quirk table in the kernel, but i don't think it is used to change the edid you get out
<cjwatson> xnox: Anything you think I've missed from the work items list in the pad?
<xnox> bregma: so interesting my laptop is not 96px but something like 138
<cjwatson> ogasawara: hope you have enough for this, my daughter is nagging me to come and play
<xnox> bregma: it's a 13.3" diagonal with 1600 by 900 resolution.
<ogasawara> cjwatson: go play!
<ogasawara> cjwatson: I'm good here
<xnox> ogasawara: yeah we've discussed dpi/scaling of: grub boot menu, plymouth splash screen, virtual console fonts, and how to reliably detect physical dimensions without using X.
<ogasawara> xnox: ack, thanks
<cjwatson> well.  "reliably"
<xnox> cjwatson: reliable != accurate =) as long as it's "reliably the same" it's good enough, it can be blindly wrong ;-)
<cjwatson> def physical_dimensions(): return 0, 0
<cjwatson> I think we possibly want the bar *slightly* higher
<xnox> cjwatson: qemu is not giving me any edid information =(
<cjwatson> You might try different -vga settings
<cjwatson> -vga std might be smarter
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/13/%23ubuntu-uds-core-1.html
<xnox> cjwatson: woho, i have plymouth using UbuntuFont, if available =)
<slangasek> xnox: "if available"> is there a reason not to swap the fonts-dejavu-core dep of plymouth-label for ttf-ubuntu-font-family?
<slangasek> (the latter is a bigger install size, but maybe we already have both by default everywhere?)
<xnox> slangasek: i dunno =) should i copy ubuntu-font into the initramfs as well?
<xnox> slangasek: i have no idea if/how-much we i18n strings shown by plymouth, and whether ubuntufont regresses showing those...
 * xnox guesses there are reasonable fallbacks.
<slangasek> xnox: we certainly shouldn't copy *both* fonts into the initramfs!  only whichever one we think we prefer
<xnox> slangasek: also i need to get upscaled graphics, i think.
<slangasek> the i18n support in plymouth is currently pretty weak
<slangasek> and the glyph coverage in the ubuntu font is pretty good, AIUI
<xnox> slangasek: as a lead visual designer of the initramfs graphical packages i prefer ubuntu font better =)
<slangasek> right; I think our default assumption should be that we want the ubuntu font in place of dejavu everywhere in the UI
<slangasek> and that we should only consider using dejavu for plymouth if there are specific reasons against it (prohibitive initramfs size, lack of glyph coverage)
<xnox> slangasek: i belive ubuntu-plymouth splash theme was developed before ubuntu font was published (only ubnt letters were available at the time)
<slangasek> correct
<xnox> slangasek: ok, i'll make a merge proposal? my plymouth branch start to smell like requireing FFe, it fixes too many things.
<slangasek> heh
<slangasek> stacked MP sounds good
<slangasek> I won't have a chance to look at it until tomorrow, fwiw
<slangasek> btw, did you see my question on #ubuntu-devel, about how your branch handles the case of a disconnect from the upstart private socket?
<xnox> slangasek: no, i did not see that question. sorry for lost ping.
<xnox> slangasek: i don't believe i reconnect, and simply the bridge dies, similar to all other bridges. I guess "respawn" stanza needs to be added to reconnect.
<xnox> slangasek: to be on par with all the other bridges.
<slangasek> xnox: ok; but then if the respawn happens before plymouth comes up, doesn't that mean any queued state that the bridge is holding in memory is lost?
<slangasek> (i.e., while we probably do want respawn, it's probably also better if the process can handle reconnecting rather than dying)
<xnox> slangasek: do you mean disconnects from plymouth or upstart or both. i'm not sure about internal bridge state machine at all =) didn't even look into it. And you are talking about upstart doing e.g. re-exec between startup event and plymouth up which is almost the first thing up on startup...
<slangasek> xnox: disconnects from upstart
<slangasek> and yes, it is unlikely that upstart will be respawned before plymouth
<slangasek> so we can probably safely ignore that, after all
<slangasek> but upstart re-exec during /boot/ is a known scenario
<xnox> slangasek: correct, but respawn is the right solution here, since well upstart will be doing respawn so that upstart is available once it respawns us.
<xnox> slangasek: and with plymouth, i believe it does a new connection to plymouth on each messages. No idea about queueing.
<xnox> slangasek: all other bridges don't reconnect to upstart, but wait for upstart to respawn them.
<xnox> slangasek: if there is a bridge which does reconnect to upstart private socket, i'd gladly copy it into this bridge.
<slangasek> xnox: right, I suppose we don't have that at this point; and it's not obviously more important to catch boot logs in the respawn window than it is to catch, say, udev events
<slangasek> xnox: so I'm happy with a simple 'respawn' to handle the cloud-init case
<xnox> slangasek: ack, will add that.
