#ubuntu-uds-foundations-1 2013-03-04
<pitti_uds> hello (just testing for preparing)
#ubuntu-uds-foundations-1 2013-03-05
<zyga> slangasek: hey
<zyga> slangasek: just confirming, you are the track lead for foundations, correct?
<slangasek> zyga: yes
<zyga> slangasek: thanks
<zyga> slangasek: how do I as a session lead, "join" the hangout?
<zyga> slangasek: do I use the same page as everyone else?
<slangasek> zyga: the track lead should create the on-air hangout for you; if you're a session lead you should have been marked 'required' on the session, and then when you load the meeting page in summit you'll automatically get the onair hangout link instead of the view-only youtube link
<zyga> slangasek: thanks
<zyga> slangasek: "on the session" is in the blueprint? participation required in the blueprint, right?
<slangasek> zyga: summit has its own definition of who's required or not, because attendees can't be trusted to use the 'participation essential' field accurately and it used to gum up the scheduler.
<zyga> thanks
<slangasek> zyga: if you're bolded on the meeting in summit, you're required
<zyga> slangasek: meeting in the summit, which page is that?
<zyga> slangasek: http://summit.ubuntu.com/uds-1303/meeting/21607/client-1303-new-checkbox-core-plainbox/ this one?
<slangasek> zyga: yes
<zyga> slangasek: the 'attendee list' does not have anyone in bold
<zyga> slangasek: only 'attending' vs 'interested'
<zyga> slangasek: is that it?
<cjohnston> zyga: do you have a 'review attendees' in the subnav?
<zyga> yes
<cjohnston> click that
<slangasek> zyga: the bottom of the page you were already on has your name in bold under 'Attendees', and no one else
<zyga> ok
<zyga> aah
<zyga> ok I see
<zyga> slangasek: thanks I understand now
<cjohnston> zyga: you can only do that when you are the drafter
<cjohnston> so on a meeting where you aren't the drafter, you would have to ask the drafter or lead
<zyga> cjohnston: I'm the drafter
<zyga> cjohnston: so being one, I can mark other people as automagically attending from that page?
<cjohnston> right.. thats why you can.. I was explaining that on others, you may not be able to
<cjohnston> you can't create an attendee from that page, but you can make an attendee require
<cjohnston> d
<cjohnston> if someone should be attending but isnt on the list, subscribe them to the BP
<zyga> ok, I got this now
<zyga> thanks a lot
<xnox> hangout url! =)
<xnox> please =)
 * pitti_uds waves hello
 * slangasek waves
<pitti_uds> what's wrong? it's UDS and there are no cookies in my hallway!
 * gema_uds waves
<zyga> pitti_uds: haha
<xnox> pitti_uds: there are cookies in bluefin kitchen =)
<slangasek> xnox: we can't put everyone in the hangout... :)  I'll post the broadcast URL soon
<slangasek> if there are people who specifically want to be in the hangout (fishbowl), let me know and I'll pull you in
<xnox> slangasek: ok. I'm on duty to put it up on the projector for myself, ev, mpt.
<slangasek> xnox: hmm, do you guys want to be in the fishbowl collectively?
 * mainerror takes seat
<xnox> slangasek: ev run away.
<ev> I merely went to the kitchen for scone preparation materials
<ev> #36 in the list of things I can't do at a physical UDS
 * skellat gets ready to flip page on his legal pad for more note-taking
<ev> damn, Colin won the beard competition
<cjwatson> :-)
<kamal> cjwatson: now that's a very fine UNIX beard my  friend!
<cjwatson> slangasek: Ironically I only just loaded https://wiki.ubuntu.com/PlusOneMaintenanceTeam and remembered that I'm supposed to be on +1 this month *cough*
<pitti_uds> if the RR is consistent, how would the monthly not be?
<cjwatson> If it's being changed independently by security updates then it's not a given
<pitti_uds> ah, only for that, ok
<cyphermox> I'll check with my manager, but I'll be happy to help out for some future month
<barry_> for people on RR, will they have a separate security pocket or will they get all their security fixes via the release pocket?
<pitti_uds> how would britney help if we removed a package from RR which a previous security update was depending on?
<pitti_uds> i. e. we would we run britney before doing the removal, I itake it?
<pitti_uds> just as we do now with check-rdepends before removal?
<xnox> cjwatson: slangasek: ^^^^^^ note comments.
<pitti_uds> even now there are hundreds of things on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti_uds> so some more manpower could certainly not hurt
<Laney> my god all that haskell-*
<tumbleweed> pitti_uds: yeah, that seems to have been growing continually
<Laney> ;-)
<slangasek> xnox: ack, will circle around in a minute
<slangasek> you guys could short circuit this process by volunteering to step into the hangout ;)
<pitti_uds> slangasek: sure, as long as there's room
<xnox> Laney: can you block haskell?
<cjwatson> barry_: TBD
<xnox> as in, do it manually only, such that it's never broken....
<Laney> don't understand
<cjwatson> pitti_uds: my loose thought is that IWBNI proposed-migration took more control of removals
<cjwatson> The LP integration there is currently unimplemented because I'm a coward
<xnox> Laney: blacklist haskell-* from autosyncing, and sync it manually, in stages and wait for it to build properly.
<Laney> autosyncing isn't relevant here
<xnox> potentially even doing in a non-virt ppa, such that we can copy it into the archive in one bulk.
<sebsebseb> hi
<Laney> well, for this one, it might be in general
<Laney> (this one comes from experimental)
<pitti_uds> cjwatson, slangasek: I guess that's a matter for checkrdepends, not britney?
<cjwatson> well, britney does have removal handling, but tomayto tomahto
<Laney> can you invite me in?
<Laney> perhaps there is something to say about haskell
<Laney> or transitions in general with RR
<xnox> pitti_uds: wins the best backdrop of this hangout =)
<slangasek> pitti_uds, cjwatson: reminder to enable Lower Third in the Hangout Toolbox :)
 * tumbleweed can provide mountain and sea backgdrops on demand (it's a lovely sunny day here - slightly too warm for comfort)
<cjwatson> Oh, I thought that was for track leads
<pgraner> cjwatson, its so folks watching the stream know who you are
<kamal> cjwatson: I did not recognize you until you spoke!  ALL participants should use lower-third with name and irc nick!  ... just like on our UDS name badges.
<xnox> Laney: is that flipcharts in the background?
<pitti_uds> slangasek: figured it out
<Laney> whiteboard
<xnox> Laney: add a subtitle =)
<cjwatson> kamal: I thought it was track leads only from the plenary
<Laney> i don't know how
<cjwatson> I think I've enabled it now
<apw> Laney, toolbox "lower third"
<cjwatson> (IOW I thought that track leads were supposed to enable it for the whole hangout)
<pgraner> Laney, click on the toolbox and use lower third
<slangasek> cjwatson: ah, I don't believe we have that capability :)
<arges> i think my mic is broken. How does one recruit volunteers, or tell them who to get in contact with?
<pgraner> cjohnston, they can't do that, has to be done on an individual basis
<slangasek> I think you have to add it yourself
<pgraner> arges, have them get in touch with me
<arges> pgraner: cool.
<cjwatson> (Does my lower-third look mirrored left to right for anyone else, or is that just what happens for one's own?)
<Laney> the latter
<pgraner> cjohnston, it will be mirrored just for you
<cjohnston> :-(
<pgraner> cjohnston, we see yours just fine
<xnox> cjwatson: it looks good. just like everyone else.
<stgraber> cjwatson: IIRC there's an option you can tick to have it un-mirrored for you, but yeah, looks fine for everyone else anyway
<cjwatson> ok, good
<kamal> bigger icepicks
<slangasek> https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<cjwatson> https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<cjwatson> snap
<arges> Is there a link to the new rolling release schedules showing freeze dates etc? Or is this something being worked on this week
<cjwatson> Not set yet
 * xnox likes +1 as well
<barry> it's been a while since i did a +1, so i'd be up for doing another stint
<xnox> slangasek: ^^ two more
<stgraber> slangasek: I'd also be interested in finally doing some +1 work (been meaning to for a while but got busy with 12.04.1 and other things ;))
<arges> I volunteer 50% of me for another month.
<arges> pending mgr approval : )
 * mitya57|uds didn't see any schedule, but hopes there won't be freeze in two days ;)
<pgraner> arges, https://wiki.ubuntu.com/DraftReleaseSchedule
<arges> pgraner: cool
<mitya57|uds> pgraner: so there *will* be freeze? :(
<pgraner> mitya57|uds, prior to the LTS
<pgraner> mitya57|uds, and any point releases
<cjwatson> the freezes on the left are from the unmodified raring schedule
<mitya57|uds> the draft schedule you linked says "March 7th"
<pitti_uds> cjwatson: FYI, I muted you as your typing was quite loud
<arges> steve froze
<mitya57|uds> cjwatson: ah, nice then
<Laney> oh noes
<arges> yup works now
<slangasek> am I still frozen?
<geofft> I'm distinctly not volunteering, but I'm curious what the requirements are
<pitti_uds> oops, my hangout crashed
<cjwatson> pitti_uds: ah, sorry, new laptop and I'm not used to it yet
<jpickett> yep
<cyphermox> yes
<xnox> slangasek: yeah you are fine.
<geofft> both in terms of whether you need to have upload rights to things
<jsjgruber-uds> you are ok now, steve
<skellat> And you all are back
<apw> slangasek, i can hear you
<pgraner> mitya57|uds, thats the part of the original sechedule so people can see the contrast
<geofft> and time commitment
<xnox> pitti_uds: rejoin =)
<jsjgruber-uds> yes
<retoaded> yes
<xnox> slangasek: yes, we can.
<pgraner> mitya57|uds, columns are labeled :)
<apw> slangasek, we had a like a netsplit, three of you wen't pop
<mitya57|uds> :)
<arges> thanks again : )
<geofft> yeah, it sounded to me like Debian RC-bug squashing, which you can do unprivileged if you have a friendly sponsor
<geofft> would be good to mention on the wiki page
<geofft> thanks!
<xnox> slangasek: cjwatson: sorry what?
<xnox> ah ok.
<xnox> slangasek: but jenkins QA is quicker.
<xnox> cjwatson: jenkins notices quicker than people wakeup, and QA are pinging about those.....
<slangasek> https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Priorities
<slangasek> xnox: proposed-migration notices even quicker from jenkins, and I think infinity pulls from that report
<cjwatson> proposed-migration does not notice component mismatcehs
<slangasek> oh
<cjwatson> But component-mismatches does :-)
<slangasek> I mean component-mismatches
<slangasek> :)
<cjwatson> jenkins notices after there's an image build
<xnox> can we autofix them =) or block building images? (sounds like a too big of a hammer)
<psivaa__> Do you expect any change in the way we, QA communicate to you regarding the daily smoke test failures? :)
<rbasak> I'm good
<rbasak> For April
<xnox> psivaa__: I'm yet to reply to your email, btw. mostly you are right and do the right thing.
<rbasak> pgraner: ^^
<cjwatson> It's basically fine, it's just you shouldn't need to do so much work
<xnox> psivaa__: the blocker is fixing things quicker on our side and/or communicating that the next image should be fine.
<slangasek> xnox: the right answer is to not lose the overrides that were already present in -proposed when pocket-copying
<cjwatson> Which is 90% addressed by my action to ... what slangasek said
<psivaa__> xnox: fine then :-)
<xnox> ok.
<xnox> psivaa__: ;-)
<arges> cool thanks
<kamal> thanks +1 Maintenance Team... keep up the good work!
<mitya57|uds> thanks!
<xnox> stgraber: are you by any chance going to drop by http://summit.ubuntu.com/uds-1303/meeting/21606/client-1303-ubuntu-touch-porting/
<xnox> ?
<xnox> it's about porting ubuntu-touch quantal patches to raring which includes interesting things like resolvconf, mountall, telepathy stacks...
<stgraber> xnox: when is that?
<xnox> stgraber: it's next in parallel with "should we switch to rolling release"
<xnox> Laney: that session above is also questioning maliit.
<Laney> yeah, stupid scheduling there
 * Laney grumps
<seb128> everybody is going to go to the rolling release one, right?
 * seb128 feels like the rebase on raring will be empty
<xnox> stgraber: there is ophono questions on that etherpad as well.
<tumbleweed> Laney: I just got that one moved to suit me, stop grumping
<Laney> yah boo
<Laney> seb128: The rebase one was interesting because I expect to be doing some of the work there
<stgraber> xnox: well, kinda hard for me to attend two sessions at once...
<Laney> but the rolling one is also obviously quite important
<zyga-uds> seb128: hey, how can the session lead get a link to the hangout?
<sfeole> o/
<roadmr> hello
<diwic> hello
<diwic> stream hasn't started yet
<diwic> or has it?
<doanac_> diwic: i don't think it has
<sfeole> offline for me here
<zyga-uds> are we on?
<sfeole> i dont think so
<brendand_> no video yet
<smagoun> +1, no video for the plainbox session yet
<smagoun> i see video now
<roadmr> smagoun: it should be working now
<diwic> okay, it's on
<zyga-uds> IF YOU WANT TO BE IN THE HANGOUT PING ME (zyga)
<roadmr> http://summit.ubuntu.com/uds-r/meeting/21051/cert-r-checkbox-simplification/
<roadmr> it has tests - which checkbox lacked for a large portion of the core
<roadmr> it has documentation - which checkbox sorely lacked (high bus factor)
<smagoun> ara_: what is the plan to add manual tests to plainbox?
<brendand_> cwayne - it has a cli at the moment
<ara_> smagoun, they are there, but we don't have a UI connected yet to plainbox
<ara_> they work, but just with cli
<smagoun> ara_: Will checkbox + plainbox be maintained in parallel until plainbox can run manual tests?
<brendand_> cwayne - so you can run manual tests but you will get just a text prompt
<roadmr> smagoun: did what zyga just say solve your question?
<ara_> smagoun, of course
<zyga-uds> plainbox.readthedocs.org
<ara_> this is going to be an incremental development
<brendand_> cwayne - a bit like checkbox-cli at the moment
<cwayne> whats the difference between this and utah?
<roadmr> cwayne: why don't you ask zyga directly in the hangout :)
<cwayne> didnt want to interrupt :)
<sfeole> he just answered my question
<sfeole> pkg depends
<roadmr> sfeole: ftw!
<sfeole> :P
<nuclearbob> they're tailored to different workflows based on the needs of the teams developing them :)
<smagoun> is there a comparison of plainbox/utah someplace?
<roadmr> nuclearbob: exactly :)
<roadmr> smagoun: no, but it'd be good to have
<smagoun> roadmr: +1, are you volunteering? :)
<roadmr> nuclearbob: for instance I'm sure a lot of stuff that's done in checkbox had to be reimplemented in utah, since it's something that better fit your needs
<nuclearbob> utah has pilfered some good stuff from checkbox, I'm hoping maybe I can help with gaps in plainbox if they match things I've already done
<roadmr> nuclearbob: part of the goal in plainbox is to make those things more easily reusable so the next project that needs to do testing can leverage this
<ara_> smagoun, I will create a work item
<nuclearbob> roadmr: that was the initial goal of utah as well
<smagoun> roadmr: nuclearbob: Are the tests themselves interchangeable between checkbox/plainbox/utah?
<nuclearbob> smagoun: I don't think they are right now, that's an area where work is ongoing
<roadmr> smagoun: not at the moment
<brendand_> utah doesn't support manual tests does it?
<nuclearbob> brendand_ that's correct
<smagoun> I/my team want that (convergence in test case format) so that test cases can be shared across checkbox/plainbox/utah
<cwayne> that was weird
<nuclearbob> smagoun: I think that would be useful for a lot of teams
<brendand_> smagoun - checkbox and plainbox are synonymous here
<cwayne> sfeole: what did i miss?
<smagoun> +1 for separation of the test runner and the test cases
<nuclearbob> +1 from me as well
<roadmr> smagoun, nuclearbob : that was an obvious improvement, tbh not sure why we didn't do it before :/ hehe
<nuclearbob> roadmr: a lot of things seem obvious after they're already done :)
<ara_> you guys are just trying to avoid C++ :)
<roadmr> ara_: hey, at least it's not Java %)
<bkerensa> =)
<sfeole> long live CLI :P
<brendand_> ara - no not avoiding c++, avoiding horrible uneccesary glue code :)
<brendand_> ara - the other option would be to write plainbox in c++. how about it!?
<roadmr> can we leverage the new qml goodies? it'd be cool to have a phone-friendly plainbox ui :D
<brendand_> roadmr - it would definitely be worth thinking about if we do a full remastering of the ui
<brendand_> roadmr - cr3's initial reservation about qml that there is no good widget library is made redundant by the phone SDK
<roadmr> brendand_: yep
<nuclearbob> I can be on the utah half of the comparison
<roadmr> nuclearbob: thanks, signing you up :)
<spineau> AFAIK there's no qt5 python bindings available yet
<roadmr> plainbox.js FTW?
<roadmr> yay, the plainbox components can be leveraged to do stuff like syntax checking, fetching lists of available jobs, quick-running a single job to test it, etc ;)
<cwayne> i just liked being able to see the tree of test cases and be able to quickly add one roadmr :)
<roadmr> cwayne: plainbox provides a good set of foundations to make that happen
<cwayne> roadmr: ++
<zyga-uds> https://plainbox.readthedocs.org/en/latest/dev/index.html
<brendand_> cwayne - try and write down what checkbox editor does that you really use
<cwayne> brendand_: yep, already started :)
<brendand_> cwayne - we'll want to ask about it later on
<roadmr> ok, where to now?
<zyga-uds> smagoun: checkbox and plainbox use the same test case definition format
<slangasek> zyga-uds: and broadcast ended :)
<roadmr> slangasek: thanks for manning the a/v controls :D
<slangasek> sure thing
<zyga-uds> smagoun: we are talking about about a new format for 'plainbox' that has minimal changes and is totally backwards compatible (can be migrated automatically) that addresses some issues with checkbox jobs
<zyga-uds> smagoun: if you want to know more about that have a look at http://jobbox.readthedocs.org/en/latest/jobspec.html#jobbox-job-definition
<zyga-uds> smagoun: it's just a proposal that we're discussing and there's no support for that, in the end checkbox will keep supporting checkbox jobs, even with plainbox core, so nobody has to worry about it
<smagoun> zyga-uds: thanks for the link. My concerns are 1) leveraging existing checkbox test cases 2) machine-readable test cases that they can be analyzed/transformed (I believe we have this already) and 3) expanding the pool of test cases available to a test runner like checkbox/utah
<plars> is this one happening?
<plars> ah, I see it just fell off the schedule
<slangasek> hmm, why don't we have channel topics
<lool> cjohnston: can you give powers to slangasek to set channel topic?  e.g. op him
<lool> looks like udsbot isn't here
<lool> cjohnston: Might just be missing udsbotu
<cjohnston> lool: appears so
<lool> cjohnston: is it in your powers to fix udsbotu or would you know who to ping?
<cjohnston> im trying to ping
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | HWE Stacks for the 12.04.x | Url: http://summit.ubuntu.com/uds-1303/meeting/21598/foundations-1303-hwe-stack/
<cjohnston> lool: its here
<lool> cjohnston: thanks, you rock
<lool> slangasek: topic(s) fixed
<slangasek> lool: cheers
<slangasek> ogasawara: hangout url is up
<slangasek> although firefox is trying to kill my machine with swap
<xnox> "This live event will begin in a few moments"
<ogasawara> slangasek: you're a bit jittery on this end
<slangasek> yep
<apw> must ... fit ... entire ... google ... search ... db ... into slangasek swap
<smagoun> xnox: +1, waiting on youtube too
<cjwatson> solution: more swap
<ara> waiting as well
<slangasek> cjwatson: hehno
 * xnox pondered to put thunderbird into a cgroup such that it can learn to cope with having limitted RAM
<smagoun> slangasek: you could put your swap partition/file into a tmpfs. Should be much faster!
<arges> and its live!
<mlankhorst> where's the hangout?
<smb> here
<slangasek> cjwatson: you do know that firefox scales its cache according to how much system memory it sees?
<smb> refresh
<xnox> and we are live!
<arges> http://www.youtube.com/watch?feature=player_embedded&v=ph0V8i3sB5o&newstate=f79cf6d226e46a7e27e2874a67c67c88
<xnox> slangasek: leanne is not here.
<slangasek> xnox: where?
 * mlankhorst should probably be pulled into speakers
<xnox> slangasek: never mind, tab complete fail.
<slangasek> mlankhorst: you are marked for it, do you not see the link for the google hangout?
<xnox> ogasawara: heya =)
<cjwatson> slangasek: where the scaling factor is 100%?
<slangasek> cjwatson: roughly ;)
<cjwatson> I'm not seeing the hangout link either; dunno if I'm supposed to
<cjwatson> where would it be?
<apw> cjwatson, more refreshing
<smb> http://www.youtube.com/watch?feature=player_embedded&v=ph0V8i3sB5o
<apw> ogasawara, we seem to be missing 'two people' on the right
<cjwatson> I mean hangout not youtube :)
<cjwatson> ah, got it from Steve now
<tjaalton> mlankhorst: so you get to install it anyway ;)
<slangasek> yeah, I don't know where the link shows up on the page
<xnox> People on hangout please add your subtitles =) "third from the bottom in the toolbox" or something like that.
<apw> ogasawara, i think we should be taking whaever the current linus kernel at the time of the point release, if there are monthly 'freezes' perhaps from the previous one of those
<apw> cjwatson, we were told we would keep people on the one you installed until 14.04, post 14.04 you might be forced forward
<slangasek> xnox: "lower third" is the name of the tool, not its position in the menu :)
<smagoun> apw: +1 that is my recollection
<xnox> slangasek: =) Kylin ;-)
<slangasek> xnox: duÃ¬
<apw> cjwatson, i think we wanted to offer both options, for the period up to 14.04
<cjwatson> Right
<apw> cjwatson, so either have -quantal installed to stay, and -hwe to roll
<pgraner> ogasawara, we felt they were flexible due on the availability of the HWE package
<smagoun> ogasawara: Can we put in writing that we're not going to stop the point releases? That seems better than saying we haven't heard they're going to change
<pgraner> smagoun, the point releases wouldn't change
<pgraner> smagoun, the only thing that was up in the air was the release frequency
<CarlRichell> Intel haswell is expected to be released around June. Are haswell chipsets and graphics support expected in 12.04.X?
<cjwatson> I'll forward that to Rick; might as well include it in whatever we eventually document regarding rolling etc.
<smagoun> pgraner: right, is that written someplace (besides here?). My group's partners would appreciate the confirmation
<apw> slangasek, 'whos' upstream releases ?
<cjwatson> smagoun: ^-
<jmleddy> well except for i915_hsw
<smagoun> cjwatson: thanks!
<cjwatson> smagoun: Nothing has actually been formally announced yet anyway :)
<slangasek> apw: well, I was referring to hardware vendors' support landing upstream
<pgraner> smagoun, you won't get ANYTHING WRITTEN until decisions are made, we are still talking at this point
<apw> slangasek, right but ... they arn't really all sync'd was my only point
<slangasek> apw: primarily wrt the platforms themselves
<bryyce> for X package naming, will we use something different than -lts-raring?
<tjaalton> CarlRichell: is in 12.04.2 already
<xnox> bryyce: -lts-raring.1 ? =)
<CarlRichell> tjaalton: thanks!
<apw> bryyce, yeah the nameing is an issue, using -quantal and -raring was probabally a mistake anyhow
<apw> -12.04.3 ?
<bryyce> meh
<apw> slangasek, can we not follow the same basic plan, push something into -proposed 3m before the point release
<cjwatson> you can upgrade to 12.04.3 without switching to the new stack, so that would be confusing
<bryyce> apw: although to be honest I can't think of any better suggestions
<apw> cjwatson, fair pint
<xnox> No.
<mlankhorst> bryyce: I was thinking of adding version, mesa-9.1 and xserver-1.14 or something
<xnox> because we were taking a non-lts stack
<xnox> Stabilise in precise-proposed?
<xnox> too late?
<mlankhorst> it should be stable before then
<jmleddy> are we going to be basing it off of one of the monthly snapshots?
 * apw concurs with xnox ... stabalise for some time in precise-proposed and release later
<xnox> mlankhorst: but we can't stabilise in rolling. it should keep on going.
<cjwatson> There's the problem that relatively few people use precise-proposed, even compared to the number who use non-LTS releases
<cjwatson> So I guess it depends how much you're dependent on organic reports from random users as opposed to organised smoke-testing
<mlankhorst> xnox: the thing is that for xorg / mesa we usually do big bumps, rest is stabilization
<apw> cjwatson, yes there is that, but at least its not dumped into -updates without any testing that way
<jmleddy> what about a 12.04.3 beta?
<bryyce> at least for the X stack, stabilizing in RR would probably work out fine
<apw> cjwatson, and presumably we use the normal plan of doing point release qa against -proposed
<mlankhorst> so for mesa/xserver it's more stable by following and just postponing version bumsp until after a point release
<xnox> cjwatson: sure, for -lts-raring we did dailies from proposed and call for testing.....
<cjwatson> We could do a beta based on image builds from -proposed, I suppose, yes
<tjaalton> well, the x stack will be stabilized on the rolling release already, since the upstream six month release cadence sits between our point-release cadence, and we're not aggressively pushing prerelease versions to the archive anyway
<cjwatson> Might be necessary given reduced feedback from later series
<bryyce> tjaalton: right
<xnox> cjwatson: can we land it in -updates, but not flip the switch to upgrade people / not build images?
<cjwatson> Easier to build images off -proposed, I think
<cjwatson> Once we land it in -updates, at least some people are going to upgrade
<apw> ogasawara, i think the unaggreed part there is whether the -next is in archive or in a PPA
<apw> ogasawara, yes he is
<xnox> slangasek: just type, you are breaking apart.
<smagoun> slangasek: you're breakaing up
<bryyce> slangasek: type it in irc
<xnox> slangasek: reconnect, please.
<tjaalton> the problem graphics-wise is more in the kernel drm drivers, so for our point of view, the newer the better (most of the time :)
<bryyce> tjaalton: yeah
<mlankhorst> tjaalton: the second newest the better
<cjwatson> (I mean, given that we build images off -proposed for some period of time between point releases anyway)
<mlankhorst> newest always has fallout
 * xnox welcomes slangasek to swap death =)
<tjaalton> mlankhorst: maybe, depends. also if someone else is using a release as a stable release..
<tjaalton> *kernel release
<mlankhorst> indeed
 * mlankhorst always finds 1 or 2 bugs in pre-release kernels
<geofft> Tangentially, how (if at all) does the rolling linux-next proposal interact with e.g. xorg-edgers?
<jmleddy> I think we should use 3.9
<apw> bjf, we should consider taking whatever will give us a couple of months of stabilisation
<jmleddy> for the new Haswell support
<apw> (if we arn't releasing 13.04)
<apw> cjwatson, i think the normal plan was to try and ride 'all' of upstream stable for the kernel before relasing it into the point release
<kamal> slangasek: session video is locked on ogasawara -- can you fix that?
<arges> oh noes
<xnox> hangout crashed
<smb> kamal, jinx
<smagoun> doh, lost the hangout entirely on youtube
<smb> now it is gone completly
<pgraner> hangout died
<jsalisbury> hangout gone
<bryyce> geofft: edgers will just follow upstream.  I haven't reviewed the linux-next proposal but if it's following upstream as well I'd think they'd be compatible.
<jmleddy> what happened?
<cjwatson> apw: I guess I'm mostly trying to establish dates
<ppisati> ???
<jmleddy> google--
<xnox> I think slangasek hit the reset button, taking the hangout down.
<apw> ahh
<cjwatson> Some of us are still on G+
<xnox> as he was "hosting" the show.
<bryyce> ah
<geofft> bryyce: Right, so does "compatible" mean "they'll just turn into the same thing"?
<xnox> cjwatson: but it's not transmitted to the "public"
 * xnox We'll be right back.
<xnox> slangasek: it should take 8second to boot into desktop right?! =)
 * smb is glad there is no elevator music
<tjaalton> from a backporting point of view (and getting fixes from upstream), stabilizing on the kernel that is released ~2mo before the point release would be the best
<cjwatson> I am greatly enjoying the irony of my G+ video actually working better than >0 other people's
<cjwatson> OK, so what's the schedule for 3.9, ish?
<utlemming> the hangout seems to have died. There is "We'll be right back" message
 * mlankhorst has been trying very hard not to close his laptop
<utlemming> at least the Youtube broadcast is dead
<bjf> the merge window just closed
<apw> cjwatson, we just hit 3.9-rc1, so 7-8 weeks
<cjwatson> mkay
<bryyce> geofft: the X stack and kernel are not tightly coupled, you can mix and match to a large degree.
<cjwatson> so that's early May
<diwic> tjaalton, for audio, I tend to agree
<apw> bjf, when was .3 ?
<tjaalton> because then when we're stabilizing the stack, upstream is still working on the next kernel and can't use the excuse of "upgrade your kernel" :)
<tjaalton> also, less things have changed
<bjf> apw, aug. 15
<diwic> tjaalton, three months is a bit much, maybe 1 - 2 months would be better
<diwic> the 3.9 kernel is going to be fun for audio though
<apw> bjf, so we would expect 3.10 to drop before the point release, but not by much
<xnox> can we start a new hangout while slangasek reconnects?
<diwic> but that's another story
<apw> xnox, i think he is the one who knows how the stream clicks work
<xnox> apw: =) special training I take it.
<geofft> bryyce: Yup. But xorg-edgers does ship an upstream-ish kernel, and also I thought HWE has as much to do with X etc. despite people just talking about the kernel for convenience
<apw> xnox, very special, with pints of beer no doubt
<xnox> apw: a fly-in physical sprint at google campus? =)))))
<tjaalton> diwic: yeah, hard to find a balance.. it does take some time to shake out the worst bugs
<apw> geofft, there are two components, for some things the kernel is enough, obviously for graphics you need both
<xnox> delay point release, if not stable as a contingency?!
<apw> geofft, so nominally you can have half of it if the half you want is hte kernel
<cjwatson> engaged in SMS conversation with Steve
 * apw would hope the lack of a 13.04 would allow us to take a view on 3.9 against 3.10 for the point release based on the h/w it supported and apparent stability
<diwic> "The live recording you're trying to play is still being processed and will be available soon."
<xnox> diwic: yeah, it went into archiving mode.
<apw> but that would necessitate what ogasawara alluded to, keeping the 'next' kernel separate till we were sure we were happy with it, either in PPA or as linux-unstable
<xnox> such that a new session / url will need to be started.
<cjwatson> diwic: Steve's laptop has gone into swap death and apparently the stream is inextricably linked to that, so he'll need to reboot to fix it
<smb> Happened before. Someone has to post the link to part
<smb> 2
<cjwatson> Software is great
 * cjwatson goes to take up sheep-farming
<mlankhorst> cjwatson: well this uds is making me want to do that!
<gQuigs> maybe WebRT will be ready by the next UDS
<kamal> video is back up
<xnox> cjwatson: well the skills are transferable, no why not?
<jmleddy> is there a youtube link where they are broadcasting ?
<kamal> oh, no my mistake
<cjwatson> jmleddy: I think you probably won't get one until Steve gets sorted
<xnox> live is not up, just the recording of the first 25minuts.
<xnox> jmleddy: hangout is down at the moment.
<jmleddy> okay
<jmleddy> so it isn't like the hangout is going on without us
<diwic> the question is; if we package both linux-rc and linux-stable how many will follow/test each one
<apw> right they anr't talking at all,
<jmleddy> cool
<xnox> diwic: one will find out from errors.ubuntu.com and submitted bug reports.
<apw> diwic, well right now we test the -rc's early on out of the archive anyhow, so we might be doing so a little longer in this scenario
<xnox> diwic: at least thre relative split and stability comparison.
<jmleddy> we can also get testing help from partners if there are new enablement pieces
<diwic> what about QA/cert work for testing the kernels today?
<apw> diwic, i would almost prefer a PPA for -unstable (and not calling it that) because that way you can use that PPA as a depandant PPA for testing dkms package such as tseliot worried about
<apw> diwic, the QA testing i have seen can cope with the use of overlay package at least i think
<ara_> apw, is the youtube stream back up? what's the url?
<apw> not that i have heard
<ara_> ok
<diwic> apw, right, but I mean, they currently test non-lts releases somehow, over different hardware? Will that testing just disappear, or being transferred to do before a point release?
<apw> diwic, it would seem logical they would continue to test 'development' and the point releases as they do now
<pgraner> diwic, that won't change
<pgraner> diwic, we will test as usual
<ara_> slangasek, have you restarted the streaming? in the page we only get the recorded video for the first 25 minutes
<diwic> pgraner, could you refresh my memory about what testing is being done today?
<slangasek> I've just launched a new hangout
<slangasek> cjwatson, ogasawara, apw, bjf, mlankhorst : if you refresh you should have the new link now
<plars> we currently test the new development kernels, as well as the kernel updates to supported releases (ex. 3.2 kernel updates on 12.04.1, 3.5 kernels on 12.04.2, raring kernels...)
<kamal> slangasek: thanks -- up now:  http://summit.ubuntu.com/uds-1303/meeting/21598/foundations-1303-hwe-stack/
<cjwatson> slangasek: refresh what, summit?
<kamal> it is working
<smb> http://www.youtube.com/watch?feature=player_embedded&v=pXTfcl4kee4
<slangasek> cjwatson: yes
<cjwatson> summit doesn't give me a hangout link
<slangasek> hmm
<jmleddy> it is working for me
<cjwatson> (hangout != youtube)
<diwic> plars, how wide is that testing?
<plars> diwic: "wide"?
<diwic> plars, like, 5 or 50 different machines?
<pgraner> diwic, it does not include audio if thats what your getting at
<smb> cjwatson, that was more for apw
<slangasek> cjwatson: sorry... I haven't seen the link in summit myself, but I've been assured it's somewhere
<xnox> https://www.youtube.com/watch?v=pXTfcl4kee4&feature=plcp for public viewing =)
<plars> diwic: if your asking whether we test on every piece of possible hardware, clearly the answer is no. At the least though, we do test on both amd/intel, ati/nvidia, etc
<plars> diwic: ...and kvm/xen as well
<ppisati> dead again
<jjohansen> ppisati: not for me
<xnox> ppisati: not here. are you using the new url or the archive url?
<ppisati> refresh did it
<xnox> ppisati: that will not help, you want new url. If you are part of hangout
<xnox> check summit for new hangout invite.
<ppisati> xnox: no, i'm not part
<xnox> ppisati: for public viewing see https://www.youtube.com/watch?v=pXTfcl4kee4&feature=plcp
<diwic> plars, so just a few machines and not a complete hardware go-through (since it doesn't include audio), correct?
<xnox> slangasek: what about steam and games? mir will work for them?
<plars> diwic: that's just for the bits that I touch, cert may have some additional hw they test on as well, ara_?
<bryyce> wish I could chime in on the hangout
<ara_> diwic, so for certification we test point release with a range of hardware, depending on enablement
<jmleddy> it would be nice to know that nvidia and fglrx is still working in tip
<bryyce> slangasek: there's a lot of factors we account for when deciding about updating the xserver stack
<bryyce> slangasek: certainly we'll take into account if we don't need anything from a newer X and are focusing on mir
<bryyce> no, X and mesa can usually be updated independently (and we often do)
<xnox> slangasek: can you add bryyce to the hangout?
<tjaalton> X and mesa releases tend to have the same cadence
<mlankhorst> bryyce: yeah but they usuall get released around the same time, so we usually ship both together :)
<bryyce> tjaalton: yeah but not due to tight coupling, just that the maintainers often are on the same schedule
<tjaalton> bryyce: right
<xnox> apw: why can't one build dkms modules against linux-next and linux-general?
<xnox> in-archive?
<apw> xnox, you could but you are changing the pacacking potentially
<xnox> apw: true. point taken.
<xnox> (well dkms config file....)
<ara_> certification will also be more difficult, we would basically need to recertify everything in every point release
<arges> could we just have two?  a base LTS version 3.2 and then the rolling version?
<ara_> but we could probably do a recertification in a subset of systems covering a set of components
<xnox> cjwatson: well not the .1 (that didn't have hwe?!)
<jjohansen> ogasawara: we reduce support burden in that its only a select set of packages for HWE, of course nothing for kernel
<jjohansen> yeah that is how I remember it as well
<cjwatson> xnox: I couldn't remember :)
<diwic> If we support things for 6 months only, that's not an unusual time for pre-load machines to be in the store...
<xnox> cjwatson: me neither to be honest, all I recall is d-i and lvm....
<cjwatson> diwic: Right, I don't think we can withdraw support without having automatic upgrade to something that is supported
<xnox> who is typing so loud?
<mlankhorst> cjwatson
<cjwatson> Oh, sorry, might've been me
<cjwatson> Keep forgetting to mute
<bryyce> work items?
<arges> ogasawara: am i missing something. are we keeping for example the precise 3.2.x kernel as a supported kernel
<mlankhorst> probably
<bjf> arges, the support for precise is not changing
<xnox> we could stay longer as this is the last session for the day.
<superm1> slangasek: yes i agree with that.
<tjaalton> fewer point-releases would mean trouble hwe-wise
<ara_> .4 is the last one
<arges> bjf: ok ok
<jmleddy> 12.04.2 came out in feb, and 13.04 would have been 2 months later
<jmleddy> so it's just the same thing one year later
<slangasek> xnox: bryyce should be on the invite already, dunno why he's not in here. :)
<jmleddy> that's probably a bad idea
<jmleddy>  based on the hardware schedules
<CarlRichell> that's the case for system76 as well
<xnox> slangasek: ogasawara: should the .3 moved then?! and hence less work then.
<diwic> from time to time I add dkms packages to the pre-load image to enable audio. It might be difficult for me to get things into the next point-release's distro kernel, not rolling forward would give me 12 - 18 months instead of 0 - 6 months
<xnox> nice.
<cjwatson> Well, .3 isn't *just* for hwe :)  We could skip hwe in it without skipping the whole pr
<cjwatson> (General roll-up of updates and such)
<tjaalton> so, are we talking about point-releases as always having a backport stack?
<cjwatson> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.2 - all changes from .1 to .2
<diwic> jmleddy, do we have haswell in .2?
<jmleddy> diwic: not ULT
<cjwatson> Well, roughly all, depending on the vagaries of my half-arsed script
<diwic> jmleddy, ULT = ?
<tjaalton> maybe have .3 but just with an improved .2 stack
<xnox> and maintain for updates and security.
<CarlRichell> exception being if optimus support could make .3 release
<jmleddy> diwic: I was going to ask you about that actually, the ULT has a new audio chipset
<mlankhorst> CarlRichell: not going to happen
<CarlRichell> one can wish, right?
<jmleddy> diwic: ULT is a new chip
<danjared> skipping 12.04.3 definitely needs to be reviewed from the server perspective
<jmleddy> the big thing is a new audio DSP
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/foundations-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-foundations-1.log
<jmleddy> that just went to the linux mailing lists
<danjared> we (Dell) can talk with Canonical about this, though
<narindergupta> most of OEM supports only LTS and point releases only.
<jmleddy> client OEMs are not going to use .3
<cjwatson> narindergupta: In case the audio wasn't clear, I was talking about LTS - asking about whether the delay in .2 was troublesome for anyone
<cjwatson> danjared: Can you elaborate?
<cjwatson> I know there are bugs outside hardware enablement that need to be addressed
<slangasek> xnox: "what about steam and games? mir will work for them?" - in theory, running GL games on top of mir will work much better than running them on top of current unity :)
<xnox> slangasek: ok. sounds like a good enough promise to me.
<narindergupta> cjwatson: As more new servers are on the way and OEM expect to have those enabled in 12.04.3 with NIC options and storage controllers
<cjwatson> Gotcha
<rtg> danjared, that was my point about possibly needing a HWE kerenl in the point release, e.g., to support new boot essential devices.
<superm1> i should clarify, when speaking for dell on i'm speaking from the client perspective, danjared has a server perspective, so he might have some different views on need for HWE in the point release
<danjared> right, what superm1 said
<narindergupta> i am talking about server prospective
<danjared> cjwatson: -> private
<xnox> cjwatson: slangasek  could be backport the unity-quantal for .3
<xnox> s/be/we
<slangasek> xnox: hmm, that'd be a tricky proposition... I'm open to us discussing, but it clearly doesn't fit our existing SRU process
<cjwatson> It doesn't, indeed.  The net outcome might be better for 12.04 users though
<cjwatson> (System76 brought up how much better 13.04's unity was in the rolling release session earlier)
#ubuntu-uds-foundations-1 2013-03-06
<xnox> slangasek: cjwatson: what I am thinking is this - what is the minimal amount of features/packages we can backport to fake a non-lts like experience, without actually making a non-lts release.
<xnox> For a lot of users - backporting quantal theme changes to precise will make them believe they are running quantal.
<xnox> we already backported kernel and graphics stack to precise, thus hwe story/features are there.
<xnox> firefox and thunderbird are updated already. If we can identify a small subset of ubuntu-desktop packages that significantly improve user experience (e.g. speed & maybe eye candy). It would be a win for the e.g. system76 like laptop target market.
<xnox> E.g. I don't think anybody cares about gnome-terminal changes / updates. Yet unity improvements would be awesome.
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Integrate the building of the android phablet parts into cdimage | Url: http://summit.ubuntu.com/uds-1303/meeting/21633/foundations-1303-cdimage-android-builds/
<slangasek> xnox: what gives me pause is that a straight backport might include disruptive behavior changes in unity, that we wouldn't normally tolerate in an SRU, and those would be difficult if not impossible to separate out
 * stgraber waves
<slangasek> hi - sorry, hangouts giving me fits, will have things up shortly (I hope)
<slangasek> sorry, it's still not working
<slangasek> is there a Canonical person here who's registered to do on-air hangouts who could run the video for us today?
<slangasek> (at least for first session while I try to get this figured out)
<seb128> slangasek, I can
<seb128> my slot is empty
<slangasek> seb128: please do :)
<seb128> slangasek, only for the first slot though, I need to do client 1 then
<lool> ok, hangout open
<slangasek> seb128: yep, I'll work on trying to sort it here
<lool> seb128: I'm ready
<ogra_> link ?
<seb128> http://youtu.be/ixNPyJw9Lmw
<ogra_> seb128, i'm running this session ... not the on air one :)
<lool> I'm on
<ogra_> well, i would like too :)
<stgraber> can someone send me the link please (or update summit so that it gives it to me)?
<apw> ogra_, ^^
<ogra_> apw, yep already PMed
<ogra_> waiting for rsalveti
<smagoun> The embedded youtube link in http://summit.ubuntu.com/uds-1303/meeting/21633/foundations-1303-cdimage-android-builds/ isn't working, can someone update it to the video at http://www.youtube.com/watch?v=ixNPyJw9Lmw ?
<xnox> Is there a hangout yet?
<seb128> xnox, cf distro channel
<barry> xnox: i don't think so
<xnox> seb128: barry: http://www.youtube.com/watch?v=ixNPyJw9Lmw
<xnox> ogra_: can you update the summit with the hangout url
<xnox> ogra_: http://www.youtube.com/watch?v=ixNPyJw9Lmw
<xnox> ???
<cjohnston> I just put the link in summit
<xnox> cjohnston: thanks.
<xnox> ogra_: stgraber: how is the android rootfs build currently?
<ogra_> xnox, https://wiki.ubuntu.com/Touch/Porting#Building_the_image
<stgraber> xnox: I believe at least initially the rootfs was built on Offspring and the android image was built on Jenkins
<rsalveti> xnox: the usual android way of doing, if you ever built it
<cjwatson> Can you describe it briefly?  I assume it has no particularly intrinsic ties to Jenkins
<xnox> cjwatson: looks like stock android build system - get a forest of git repositories, modify configs a little bit - fire the build script "brunch" and wait till you get a rootfs blob
<ogra_> cjwatson, https://wiki.ubuntu.com/Touch/Porting#Building_the_image
<cjwatson> slangasek: FWIW, disabling IPv6 in Firefox fixed it for me
<xnox> "upstream android way"
<xnox> =)
<apw> cjwatson, interesting i use ipv6 with it (in chromium) no problem
<cjwatson> So did I, yesterday
<apw> quality
<lool> slangasek: ^
<lool> slangasek: disabling ipv6 perhaps?
<ogra_> cjwatson, it boils down to: phablet-dev-bootstrap [target_directory]; repo sync; . build/envsetup.sh brunch <targetdevice>
<stgraber> it's at least not a generic ipv6 problem as I'm connected to the hangout over IPv6 here
<cjwatson> No, I didn't debug it fully
<cjwatson> ogra_: Right, so nothing we couldn't do on a livefs builder, say
<ogra_> cjwatson, exactly, my proposal is to include that into BuildLiveCD or similar
<ogra_> cjwatson, does the live builder actually have internet access ? i thought it didnt
<xnox> ogra_: toolbox on the left -> enable "lower third" to have your name & irc nickname and a flag =)
<ogra_> xnox, trying that since yesterday, doesnt work :(
<xnox> ogra_: did you enable "permissions" for toolbox to access your video stream?! =)
<ogra_> heh, this time it works
<ogra_> HA !
<xnox> ogra_: \o/
<cjwatson> ogra_: Limited, I think
<cjwatson> ogra_: We could poke a firewall hole if needed, I'm sure
<ogra_> right, it needs to see phablet.ubuntu.com at least
<lool> are there questions from the audience here?
<slangasek> cjwatson: where do you disable IPv6 in firefox?  (I suspected it might be a v6 issue, but in the process of debugging my laptop overheated and I had to wait for it to cool down before I could log back in \o/)
<cjwatson> slangasek: about:config, search for ipv6
<cjwatson> I forget the exact key name but it's obvious
<slangasek> cjwatson: ack, thanks
<ogra_> lool, http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
<ogra_> lool, http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/quantal-ubuntu_stamp
<xnox> slangasek: what's that flag?
<joe-uds> why not have jenkins update the '/latest' link rather than polling?
<ogra_> jenkins has no write access to access cdimage
<ogra_> (and is unlikely to get it)
 * xnox has no clue about hostnames & network =)
<pgraner> cjohnston, its in the qa lab
<pgraner> cjwatson, ^^^^
<slangasek> xnox: "American Samora", according to Google
<ogra_> heh, pgraner isnt using xnox' tab completion fix to xchat :)
<slangasek> joe-uds: because we're used to thinking of the cdimage server being inaccessible :-)
<ogra_> :)
<pgraner> cjwatson, the qa lab is an internal canonical network, just let retoaded know and he'll take care of it
<pgraner> cjwatson, the firewall bits etc we do it all the time
<pgraner> slangasek, ^^^^^^^^^^^
<xnox> https://launchpad.net/ubuntu/+source/xchat/2.8.8-7ubuntu2 even references cj watson & c johnston
<slangasek> pgraner: the issue is going to be on nusakan's side :)
<pgraner> slangasek, thats fine we have two way all the time
<cjwatson> pgraner: cool, thought so
<cjwatson> jenkins certainly *can* have write access to cdimage via a suitably-careful trigger
<lool> cjwatson: So jenkins has tons of extra plugins and what not, and SSH / SFTP publishing are builtin features anyway, but the easiest would likely be to just run whatever unix commands we need to run at the end of the build scripts for the smoke tests
<lool> e.g. if it's a HTTP trigger or a SSH trigger, just run it from the shell script configured in the jenkins job to do the build
<cjwatson> OK, so it's just ssh cdimage@nusakan trigger
<lool> exactly
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/foundations-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-foundations-1.log
<lool> hmm maybe we want to push the smoke tests logs or something
<cjwatson> And a parser for $SSH_ORIGINAL_COMMAND or whatever it's called
<cjwatson> All I need is success/failure for a given build
<cjwatson> Logs can stay where they are
<cjwatson> Perhaps a link to them as a nicety, but it's not that important :)
<lool> cjwatson: so build id and result; sounds like a ssh command wrapper with 2 args then
<cjwatson> yep
<cjwatson> I'll work out the cdimage side and then say what I need
<lool> ok
<lool> I don't have write access to the jenkins side, but I would be happy to pass on
<lool> likely to Sergio
<ogra_> yeah
<lool> ogra_: thanks for the session!
 * lool moves to client-1
<cjwatson> In the first instance the jenkins instance in question would be the one that runs our x86 smoke-tests :-)
<ogra_> lool, thanks for participating !
<slangasek> ogasawara: fwiw G+ has been not very usable for me today; I managed to get connected to a session last hour and managed to launch a test on-air hangout, but it's back to giving me fits
<slangasek> ogasawara: do you think you could launch the on-air hangout (under your canonical acct) and pass me the urls for summit?
<xnox> slangasek: what's the next session for you? Kylin or Webkit or Communit/Quality ?
 * ogra_ ponders where to go ... 
<slangasek> ogasawara: oh; ignore me, that's not for another hour :)
<slangasek> so I have time to argue with software
<slangasek> xnox: I was going to poke my nose into the kylin one
<ogasawara> slangasek: if it's not sorted by then, just let me know
<xnox> slangasek: I'm thinking webkit =)
<xnox> slangasek: didn't want kylin to be left alone though.
<slangasek> ogasawara: ok, G+ has stopped throwing tantrums for the moment; hangout is up and going
<slangasek> ah, though that apparently leaves us with 15 minutes of excess footage at the beginning of the video if I do it that way ;)
<slangasek> so, cancelled and will relaunch in a little bit
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Rolling Kernel Maintenance | Url: http://summit.ubuntu.com/uds-1303/meeting/21599/foundations-1303-rolling-kernel-maintenance/
<seb128> slangasek, I think you can edit the videos to cut the non-interesting bits once they are published
<seb128> slangasek, yeah, there is an edit function with "cut" on it, seems trivial to use
<slangasek> seb128: oddly, I have used it before and when I went into my video list yesterday couldn't find it
<slangasek> regardless... hangout reset
<seb128> slangasek, weird, here my video list has a "modifier" (modify/change) combo next to the video
<seb128> slangasek, e.g the list in https://www.youtube.com/my_videos
<seb128> or if you have a grid view it's the second icon you get on mouseover
<slangasek> yeah, I'm not finding the 'cut' option anywhere
<seb128> slangasek, you have a top banner with icons
<seb128> info / changes /audio
<seb128> it's the second icon
<seb128> by default you land on the first "tab", info
<slangasek> ah righ
<slangasek> so in English it says 'Enhancements'
<seb128> the translation is better :p
<slangasek> which is less than clear, yeah :)
<sconklin_> sconklin
<arges> Also with the 3.9 kernel will there be an upstream stable branch maintained? or will need to maintain our own like 3.5?
<sforshee> arges, I don't think we know at this point
<gQuigs> yes, and please make it a real installable PPA so we can easily upgrade
<arges> I primarily use the mainline ppa builds for bug fixing, for example does this bug affect upstream
<gQuigs> arges: right but can that really be called a PPA, you can't add it to your sources
<arges> bjf: and would be apply all of our sauce patches on top of the daily PPA?
<bjf> arges, yes
<einonm> arges: all recent kernel version have a stable branch. Do you mean a longterm branch?
<arges> apw: so from a user of a develpoment release, if they hit a bug with a 'normal' kernel do we ask them to use the PPA daily kernel before proceeding?
<arges> yes
<arges> so if it affects a development release + daily PPA, we need to target upstream pretty much
<arges> then wait for it to trickle down
<chiluk__> but it should be closer to upstream right? so theoretically there will be less giberish to bring in..
<arges> einonm: yea -longterm
<diwic> bjf, since greg did not pick 3.8, maybe...
<geofft> Am I mishearing, or is the claim that if you install 12.04.1 instead of 12.04, you don't get 5 years security support?
<jjohansen> ogasawara: we did commit to the 14.04 kernel back on 12.04 for the life of 12.04
<apw> geofft, you are miss hearing i think
<jjohansen> geofft: not exactly, just that if you install 12.04.1 you have to roll forward to the 14.04 HWE stack on 12.04
<geofft> oh, that's going to exist? OK.
<geofft> I'm just curious what the expected path is if I install a server say now and want it supported until '17
<geofft> is it security updates, new kernel with 14.04, security updates, new kernel with 16.04?
<gQuigs> this is going to require more users to test on the kernel testing "PPA" right?   Could we make that easier for people to install and stay up to date on the different kernel PPAs?
<jjohansen> geofft: you can stay on 12.04 with security support for 5 years. The HWE stack for 12.04 will stop with 14.04
<geofft> Right, but suppose my server doesn't boot with 12.04.0 and requires the first HWE stack.
<jjohansen> geofft: so if you use the HWE stack, and are staying with 12.04, you WON'T get as 16.04 HWE stack on 12.04
<geofft> and will I have options for staying within security support for five years?
<jjohansen> geofft: you will stabilize at the 14.04 HWE stack
<geofft> OK.
<bjf> geofft, you can start with a 12.04.x and then you will want to upgrade to 14.04 when it comes out
<jjohansen> geofft: yes the 14.04 HWE stack will be supported for the life of 12.04
<geofft> bjf: if I'm running a server on the LTS, I'd rather not upgrade the userspace for five years.
<gQuigs> that makes it harder to test....
<jjohansen> bjf: no, we commited to a 14.04 HWE stack on 14.04
<jjohansen> s/14.04/12.04/
<bjf> geofft, i understand
<diwic> dkms = binary graphics?
<jjohansen> you don't have to roll forward to full 14.04
<bjf> jjohansen, yes, but we don't support the point releases for 5 years
<diwic> or all sorts of dkms packages?
<brendand_> what are the plans for kernel updates in raring (assuming a rolling release happens)?
<arges> apw: from a bug fix perspective, lets say I fix something upstream and we want all Ubuntu kernel versions to have this fix. Where all would these patches land? Development / SRU etc?
<geofft> apw: Okay, that makes sense, thanks.
<bjf> geofft, sorry for confusing you
<geofft> apw: "some kernel" under security support is plenty
<diwic> QUESTION: could you clarify *what* dkms packages that will / will not be tested?
<jjohansen> apw: right
<jjohansen> thanks for bringing that up
<diwic> apw, thanks
<cking> apw,  should we call out to community to find out what kind of DKMS packages are being used?
<arges> hey did you guys see my question ^^
<arges> ogasawara: bjf ^^^
<arges> apw: ok and those versions are going to have names? since we have rolling releases
<SpamapS> heavy testing and a more continuous model would be preferred over anything that involves the fairly limited bandwidth of the SRU team
<arges> haha
<arges> ok. cool thanks
<SpamapS> we don't really look at it anyway ;)
<arges> yea i usually try to verify a test build before submitting anyway
<arges> s/usually/always
<SpamapS> automate.. automate.. automate..
<arges> yup as much as possible. some bugs are very difficult to automate (specific hardware requirements, intermittent failures etc)
<cking> +1 to apw's comments, that's what I was driving at - good to flag it up those looking after DKMS packages
<diwic> but if the new actually breaks dkms packages; won't it get stuck in -proposed due to rdepends testing?
<geofft> Whose responsibility is testing the DKMS packages?
<SpamapS> diwic: only if it explicitly declares breakage
<geofft> We care about OpenAFS -- should I set up on an organizational machine a cronjob to test build it against the PPA?
<geofft> Or can we get automatic testing in Launchpad somehow?
<SpamapS> diwic: brittney doesn't actually try to install every package with every other package. It just runs the graph.
<geofft> Just whether it builds, is sufficient for OpenAFS
<geofft> since it's a filesystem, not a hardware driver
<cjwatson> Though I'd kind of like to test file conflicts too
<geofft> Sure, that makes sense.
<cjwatson> Doesn't yet, though
<diwic> SpamapS, hmm
<geofft> But if there's LP test build infrastructure, that would be better than setting up our own server for test builds
<plars> geofft: if you are just worried about it building, getting an autopkgtest in for it would be a good start
<cjwatson> LP has no test infrastructure except for what happens during package builds
<cjwatson> Tests are done by Jenkins
<geofft> OK. I'm not super familiar with Ubuntu's test infrastructure, but I should go figure that out
<geofft> But if there were a way I could get a test in the OpenAFS package that runs before kernels were pushed, that would be wonderful
<arges> thanks
<ogasawara> slangasek: you can kill the hangout whenever you're ready
<kamal> thanks folks
<Limurx> Most competent, reasonable and comprehensible session so far! Thanks!
<diwic> thanks
<cking> Limurx, +1 that
<geofft> thanks all for your work, btw. I know I'm just sitting here asking questions :)
<bjf> geofft, np, you can also ask in ubuntu-kernel channel any time
<cjwatson> geofft: So the plan is to let you do that with autopkgtest; they are not yet integrated into proposed-migration but it's on the list
<cjwatson> Although exactly how triggering that on kernel upgrades specifically would work is an open question (due to the way dependencies on the kernel work, or rather don't)
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/foundations-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-foundations-1.log
<slangasek> ogasawara: ok, killed ;)
<joe-uds_> is there a video link?
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Providing monthly snapshotting of the rolling release | Url: http://summit.ubuntu.com/uds-1303/meeting/21596/foundations-1303-monthly-snapshots/
<ogra_> joe-uds_, once the session starts
<ogra_> (7min)
<joe-uds_> ogra_: didn't realize I was early :)
 * ogra_ quickly cares for fresh cofee
<slangasek> sorry folks, this next session is being cancelled
<pgraner> slangasek, the providing monthly snapshotting?
<slangasek> we think we need to sort through the discussion that's been taking place on the list, and do further requirements gathering, before we try to have an implementation discussion
<slangasek> pgraner: yes
<pgraner> slangasek, ack sounds good
<slangasek> sorry for the short notice
<joe-uds_> slangasek: ack, thanks
<tumbleweed> thanks slangasek
<xnox> slangasek: I mean I can rsync dists/ and add reverse proxy to archive.ubuntu.com / launchpadlibrarian to fetch the debs. And updates the dists/ every month or even provide monthly folders.
<xnox> Completely outside of launchpad. Chuck it over to the mirror network and be done with it. And the launchpad side delay deb removal from the mirrors by e.g. 3 months from rolling. So it's not like that part is hard.
<xnox> the other questions of SRUs/security will need to be solved for rolling anyway independently of the snapshots.
<slangasek> xnox: wow, that's some serious breaking of threads :)
<xnox> slangasek: my view is that _all_ packages in a rolling release should be phased. And people given a notch to speed up phasing to get me all (current development release mode), participate (phase at 50% because I am an enthusiast), I want working updated machine (phase at 100% after everyone else)
<xnox> that way when regressions happen we can surplant the phasing.
<xnox> Or phase quicker for security / critical bugs.
<xnox> cjwatson was mentioning that phasing everything will enquire in "additional <something>" on launchpad / publishing side and will not scale. But I want to know further details about it.
<cjwatson> Eh?
<dobey> is the stream not up yet?
<cjwatson> dobey: 18:12 <@slangasek> sorry folks, this next session is being cancelled
<xnox> From my understanding, phasing everything has no added impact on launchpad/mirror/publishing side, as the decision is done enterily client side.
<cjwatson> 18:13 <@slangasek> we think we need to sort through the discussion that's been taking place on the list, and do further requirements gathering, before we try to have an implementation discussion
<dobey> oh
<dobey> thanks cjwatson
<cjwatson> xnox: So, every time you change the phased-update-percentage, that's a new publication (BPPH)
<xnox> cjwatson: I may be wrong, but I remember something like "phasing everything will require more publishing cycles" but I didn't understand it.
<cjwatson> And indeed it requires republishing the pocket in question (which is obviously a necessity - you have to rewrite Packages)
<cjwatson> This is something to bear in mind; I don't think it's a blocker
<cjwatson> My concern about phasing everything is more that we have zero experience with actually using phased-update-percentage right now, e.g. how it will interact with dependency chains, and I'd rather try it out in rather simpler cases first and gain that experience
<ev> cjwatson: doesn't it not touch dep chains?
<cjwatson> ev: be my guest if you want to work that out :-0
<cjwatson> :-)
<xnox> cjwatson: ok.
<cjwatson> I'm not convinced it won't cause spurious removals; the code is fairly crude
<ev> cjwatson: well I mean that it ignores the phasing for any dependencies surely
<cjwatson> But I didn't really want to go mucking around without some idea of roughly what kinds of things might go wrong
<ev> so it's hard to phase something like libgtk since it's a dep for everything
<cjwatson> ev: There's no explicit code to do that.  If it happens it's an emergent effect
<cjwatson> Which is entirely possible given u-m
<ev> but makes this problem easier
<ev> ah
<cjwatson> All that the phase handling does is rip the package in question out of the updates list
<cjwatson> Now, in theory I think anything that depends on it will end up held back as a result
<cjwatson> But what about sets of packages from the same source that all need to be installed together - I suspect that, as the code stands, the probability of them being selected will be raised to the power of the number of packages in question
<cjwatson> i.e. they will be disproportionately unlikely to be selected
<cjwatson> The client code definitely needs work
<xnox> cjwatson: right.
<ev> I don't see why it would be held back in that case. My understanding is that it's just hiding it from the updates list. So while libgtk may not show in the UI because it's below the threshold, if fooapp depends on it and fooapp is to be installed, it will be
<ev> since this is happening a level up from apt
<xnox> cjwatson: my idea was that if A and B are phased at 50% and libgtk is phased at 5%, those that "hit" a or b will get the libgtk as a dep as well. That means that the more reverse-depends a package has (e.g. libgtk) the slower it should be phased, as it is pulled in by _other_ packages in phasing as well.
<cjwatson> ev: I can believe that that may be true, but I have no evidence for it
<ev> :)
<cjwatson> xnox: Of course remember that actually requiring the *new* version of gtk will be quite rare
<cjwatson> (And likewise for most dependencies)
<cjwatson> ev: I thought that the updates list was computed after asking the depcache to upgrade, though; if you uncheck things in it by hand that have reverse-deps, all of the reverse-deps are automatically unchecked too, IIRC
<xnox> cjwatson: sure. but e.g. new major glibc every next package build after that upload will pretty much depend on a >> 1.17
<cjwatson> xnox: Hardly, given symbols files
<xnox> cjwatson: ok, true. =)
<cjwatson> glibc was practically the poster child for symbols files in the first place
<xnox> cjwatson: even better than.
<ev> cjwatson: eep. Still, it's fixable.
<cjwatson> Yep - like I say, would just like some real-world experience (or possibly a u-m test suite that's less painful to experiment in ...)
<cjwatson> Spoiled by at least some parts of the LP test suite
<cjwatson> (OK, some parts of it are dire, but if you find bits that use the right helpers it can be quite pleasant)
<tumbleweed> a derived distro lets you do new releases of your desktop, on the LTS Ubuntu base
<tumbleweed> err
<tumbleweed> wrong window
<xnox> cjwatson: so I guess we should start a test suite for all the /whatifs/. Cause even with SRUs we have cases of adding symbols to a library and a app potentially starting to use it and both "published" simultaniously, yet with phasing, a client might hit none, one or the other or both. And we do want to know what will happen then.
<cjwatson> Perhaps start by refactoring u-m's test suite
<cjwatson> If you spend about ten minutes on it you'll see the problems :)
<cjwatson> The only way to add cases is to manually add trees of sample Packages and dpkg/status files, which is pretty cumbersome
<cjwatson> Even just fixing that would make reasoning about the rest of this a whole lot easier
<xnox> cjwatson: ok.
<xnox> cjwatson: that sounds a lot like a copy&paste apt-get test suite?!
<cjwatson> Could well be
<xnox> with joethesixpack archive signing key and the rest of the bells and whistles.
<cjwatson> It would be massively improved by having the cases generated dynamically
<cjwatson> When I was doing the Conflicts/Replaces work recently, I spent a day or two hammering the test suite up to the point where I could actually add even one thing to it effectively, but there was still clearly lots to do
<cjwatson> I'd like to be able to say self.add_package("foo", conflicts="bar (<< 1.1)") or something like that
<cjwatson> I think the new apt integration tests have something very much along those lines in shell; it looked very nice to use
<xnox> cjwatson: no pseudo language to describe sample packages/status?
<xnox> fair enough.
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Phablet Kernel Maintenance | Url: http://summit.ubuntu.com/uds-1303/meeting/21597/foundations-1303-phablet-kernel-maintenance/
 * slangasek waves
<xnox> hola =)
 * xnox goes to the other room where logind and consolekit are discussed.
<cjwatson> ich auch
<smb> cjwatson, sehr schÃ¶n
<cjwatson> danke ;-)
<smb> cjwatson, yeah, sorry not very nice I guess. lacking a quick response at that time of day
<ogra_> ogasawara, mings sharing the hangout url ?
<smb> hangout broke
<cyphermox> uhoh.
<ppisati> ja
<sforshee> yep, for me too
<ricmm> feed is down again
<smb> yup
<slangasek> blast
<slangasek> sorry
<krabador> heh...
<mrman_> Stream is down
<jdstrand> *sigh*
<slangasek> ogasawara: maybe you could host?  browser probs again
<slangasek> (my own doing, but)
<krabador> google don't wants that people talks about other mobile kernels....
<ogasawara> slangasek: sure, just a sec
<slangasek> oh; or did it come back now?
<mrman_> back up
<smb> yes back
<krabador> back
<slangasek> ok, I will keep my hands off the browser :-)
<cyphermox> regdomain: yeah, that's kind of broken everywhere right now
<cyphermox> we ought to fix crda to at least get the right info from the installer
<cyphermox> (on desktop_
<sforshee> wpa_supplicant normally does the heavy lifting
<sforshee> as far as configuring wireless
<ogra_> on my SGS2 i can only get wlan0 up actually using the android wpa_supplicant (which seems to load the FW as well etc)
<cyphermox> sforshee: well, it doesn't currently appear to be doing much for this, at least on a portion of desktop installs: cf. iw reg get.
<ogra_> and even though i can bring up the device i cant access it
<cyphermox> then as awe mentions, it gets more complicated on touch, due to the lack of udev and stuff
<cyphermox> sforshee: we can all talk about it later
<sforshee> cyphermox, regulatory is a bit of a side issue
<sforshee> cyphermox, sure
<cyphermox> aye
<ogra_> rtg_, you are supposed to make calls ! not surf all day !
<cyphermox> why isn't he on IRC anwyay
<sforshee> for these fullmac devices the regulatory probably is done in the hw anyway
<sforshee> I don't know how the interaction is handled
<sforshee> broadcom does have an open-source fullmac driver in the kernel, I wonder if it supports the hw in question
<ogra_> sforshee, it doesnt on the n7 (we tested it)
<sforshee> ogra_, ack
<ogra_> (and i doubt it does on my SGS2 ... which admittedly isnt a supported device)
<cyphermox> sforshee: in hardware, I don't know too well how it works, but at least on the intel drivers it seems like the userspace gets a netlink message, udev reacts on it to set the regdomain
<cyphermox> but we never configure the default reg domain, so it always remains at 00
<sforshee> ogra_, I do have a pretty good working relationship with one of the broadcom engineers if we want to inquire with them
<sforshee> cyphermox, yeah but that's softmac where mac80211 handles the regulatory
<ogra_> that might make sense
<cyphermox> yeah
<sforshee> I'll have to look at what happens for fullmac
<bjf>  http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/uds-13.03/n7initial-issues.html
<sforshee> does autoloading of modules work in this bastardized android/ubuntu image?
<ogra_> sure
<sforshee> okay, I thought udev wasn't running
<ogra_> its a plain ubuntu, just a kernel built from android source
<rsalveti> not yet :-)
<rsalveti> it'll be
<ogra_> oh, heh
<ogra_> we'Re talking different things
<sforshee> the phablet image is what I'm talking about
<ogra_> yeah, no udev there
<sforshee> so that might be a concern wrt making some things into modules
<cking> apw, options like CC_OPTIMIZE_FOR_SIZE is really dependant  on how good gcc is, has that been checked to see how good it is?
<ogra_> cking, linaro did a lot on that iirc
<cking> ogra_, ok, I will defer to their wisdom ;-)
<ogra_> (not sure who anymore though)
<ogra_> that was a while ago
<cking> ..or which version of gcc .. ;-)
<sforshee> awe_, did they switch stacks for all devices or just those using broadcom wireless chipsets?
<sforshee> e.g., what does the n4 use?
<awe_> AFAIK, all devices
<ogra_> cyphermox, ^^^^
<awe_> but I could be wrong....
<awe_> rsalveti, ^^
<rsalveti> nexus 4 is atheros
<sforshee> rsalveti, right, I just wandered if they were still using the broadcom userland software for bluetooth that awe_ was talking about
<cyphermox> what's this about?
<cyphermox> oh bluetooth
<rsalveti> oh, sorry, about bluetooth
<ogra_> cyphermox, we were discussing BT
<rsalveti> not sure
<cyphermox> I don't know
<cyphermox> I suspect all?
<awe_> sforshee, I really haven't looked at bluedroid at all...
<cyphermox> if not, then that's good news, but heh
<awe_> we need someone to draw some basic diagrams of the two stacks, and involved components...
<cyphermox> last I touched a nexus 4 I didn't think of looking
<sforshee> I've got an n4, I'll take a look
<awe_> from kernel to UI
<awe_> sforshee, thanks
<sforshee> might help if I turned on bluetooth ...
<ogasawara> slangasek: we've ended early, you can kill the hangout
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/foundations-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-foundations-1.log
