[12:42] <zyga> slangasek: hey
[12:42] <zyga> slangasek: just confirming, you are the track lead for foundations, correct?
[13:52] <slangasek> zyga: yes
[13:53] <zyga> slangasek: thanks
[14:35] <zyga> slangasek: how do I as a session lead, "join" the hangout?
[14:35] <zyga> slangasek: do I use the same page as everyone else?
[14:36] <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
[14:37] <zyga> slangasek: thanks
[14:37] <zyga> slangasek: "on the session" is in the blueprint? participation required in the blueprint, right?
[14:38] <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.
[14:38] <zyga> thanks
[14:38] <slangasek> zyga: if you're bolded on the meeting in summit, you're required
[14:39] <zyga> slangasek: meeting in the summit, which page is that?
[14:39] <zyga> slangasek: http://summit.ubuntu.com/uds-1303/meeting/21607/client-1303-new-checkbox-core-plainbox/ this one?
[14:39] <slangasek> zyga: yes
[14:40] <zyga> slangasek: the 'attendee list' does not have anyone in bold
[14:40] <zyga> slangasek: only 'attending' vs 'interested'
[14:40] <zyga> slangasek: is that it?
[14:41] <cjohnston> zyga: do you have a 'review attendees' in the subnav?
[14:41] <zyga> yes
[14:41] <cjohnston> click that
[14:41] <slangasek> zyga: the bottom of the page you were already on has your name in bold under 'Attendees', and no one else
[14:41] <zyga> ok
[14:41] <zyga> aah
[14:41] <zyga> ok I see
[14:41] <zyga> slangasek: thanks I understand now
[14:41] <cjohnston> zyga: you can only do that when you are the drafter
[14:41] <cjohnston> so on a meeting where you aren't the drafter, you would have to ask the drafter or lead
[14:41] <zyga> cjohnston: I'm the drafter
[14:42] <zyga> cjohnston: so being one, I can mark other people as automagically attending from that page?
[14:42] <cjohnston> right.. thats why you can.. I was explaining that on others, you may not be able to
[14:42] <cjohnston> you can't create an attendee from that page, but you can make an attendee require
[14:42] <cjohnston> d
[14:42] <cjohnston> if someone should be attending but isnt on the list, subscribe them to the BP
[14:43] <zyga> ok, I got this now
[14:43] <zyga> thanks a lot
[14:55] <xnox> hangout url! =)
[14:55] <xnox> please =)
[14:56]  * pitti_uds waves hello
[14:56]  * slangasek waves
[14:56] <pitti_uds> what's wrong? it's UDS and there are no cookies in my hallway!
[14:56]  * gema_uds waves
[14:56] <zyga> pitti_uds: haha
[14:56] <xnox> pitti_uds: there are cookies in bluefin kitchen =)
[14:57] <slangasek> xnox: we can't put everyone in the hangout... :)  I'll post the broadcast URL soon
[14:57] <slangasek> if there are people who specifically want to be in the hangout (fishbowl), let me know and I'll pull you in
[14:57] <xnox> slangasek: ok. I'm on duty to put it up on the projector for myself, ev, mpt.
[14:58] <slangasek> xnox: hmm, do you guys want to be in the fishbowl collectively?
[14:58]  * mainerror takes seat
[15:01] <xnox> slangasek: ev run away.
[15:02] <ev> I merely went to the kitchen for scone preparation materials
[15:02] <ev> #36 in the list of things I can't do at a physical UDS
[15:02]  * skellat gets ready to flip page on his legal pad for more note-taking
[15:03] <ev> damn, Colin won the beard competition
[15:03] <cjwatson> :-)
[15:04] <kamal> cjwatson: now that's a very fine UNIX beard my  friend!
[15:04] <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*
[15:06] <pitti_uds> if the RR is consistent, how would the monthly not be?
[15:06] <cjwatson> If it's being changed independently by security updates then it's not a given
[15:06] <pitti_uds> ah, only for that, ok
[15:07] <cyphermox> I'll check with my manager, but I'll be happy to help out for some future month
[15:09] <barry_> for people on RR, will they have a separate security pocket or will they get all their security fixes via the release pocket?
[15:09] <pitti_uds> how would britney help if we removed a package from RR which a previous security update was depending on?
[15:10] <pitti_uds> i. e. we would we run britney before doing the removal, I itake it?
[15:10] <pitti_uds> just as we do now with check-rdepends before removal?
[15:10] <xnox> cjwatson: slangasek: ^^^^^^ note comments.
[15:11] <pitti_uds> even now there are hundreds of things on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[15:11] <pitti_uds> so some more manpower could certainly not hurt
[15:12] <Laney> my god all that haskell-*
[15:12] <tumbleweed> pitti_uds: yeah, that seems to have been growing continually
[15:12] <Laney> ;-)
[15:12] <slangasek> xnox: ack, will circle around in a minute
[15:12] <slangasek> you guys could short circuit this process by volunteering to step into the hangout ;)
[15:13] <pitti_uds> slangasek: sure, as long as there's room
[15:13] <xnox> Laney: can you block haskell?
[15:13] <cjwatson> barry_: TBD
[15:13] <xnox> as in, do it manually only, such that it's never broken....
[15:13] <Laney> don't understand
[15:13] <cjwatson> pitti_uds: my loose thought is that IWBNI proposed-migration took more control of removals
[15:14] <cjwatson> The LP integration there is currently unimplemented because I'm a coward
[15:14] <xnox> Laney: blacklist haskell-* from autosyncing, and sync it manually, in stages and wait for it to build properly.
[15:14] <Laney> autosyncing isn't relevant here
[15:14] <xnox> potentially even doing in a non-virt ppa, such that we can copy it into the archive in one bulk.
[15:14] <sebsebseb> hi
[15:14] <Laney> well, for this one, it might be in general
[15:14] <Laney> (this one comes from experimental)
[15:14] <pitti_uds> cjwatson, slangasek: I guess that's a matter for checkrdepends, not britney?
[15:16] <cjwatson> well, britney does have removal handling, but tomayto tomahto
[15:17] <Laney> can you invite me in?
[15:17] <Laney> perhaps there is something to say about haskell
[15:17] <Laney> or transitions in general with RR
[15:18] <xnox> pitti_uds: wins the best backdrop of this hangout =)
[15:18] <slangasek> pitti_uds, cjwatson: reminder to enable Lower Third in the Hangout Toolbox :)
[15:19]  * tumbleweed can provide mountain and sea backgdrops on demand (it's a lovely sunny day here - slightly too warm for comfort)
[15:19] <cjwatson> Oh, I thought that was for track leads
[15:19] <pgraner> cjwatson, its so folks watching the stream know who you are
[15:19] <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.
[15:19] <xnox> Laney: is that flipcharts in the background?
[15:20] <pitti_uds> slangasek: figured it out
[15:20] <Laney> whiteboard
[15:20] <xnox> Laney: add a subtitle =)
[15:20] <cjwatson> kamal: I thought it was track leads only from the plenary
[15:20] <Laney> i don't know how
[15:20] <cjwatson> I think I've enabled it now
[15:21] <apw> Laney, toolbox "lower third"
[15:21] <cjwatson> (IOW I thought that track leads were supposed to enable it for the whole hangout)
[15:21] <pgraner> Laney, click on the toolbox and use lower third
[15:21] <slangasek> cjwatson: ah, I don't believe we have that capability :)
[15:21] <arges> i think my mic is broken. How does one recruit volunteers, or tell them who to get in contact with?
[15:21] <pgraner> cjohnston, they can't do that, has to be done on an individual basis
[15:21] <slangasek> I think you have to add it yourself
[15:21] <pgraner> arges, have them get in touch with me
[15:21] <arges> pgraner: cool.
[15:23] <cjwatson> (Does my lower-third look mirrored left to right for anyone else, or is that just what happens for one's own?)
[15:23] <Laney> the latter
[15:23] <pgraner> cjohnston, it will be mirrored just for you
[15:23] <cjohnston> :-(
[15:23] <pgraner> cjohnston, we see yours just fine
[15:23] <xnox> cjwatson: it looks good. just like everyone else.
[15:23] <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
[15:24] <cjwatson> ok, good
[15:24] <kamal> bigger icepicks
[15:24] <slangasek> https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[15:24] <cjwatson> https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[15:24] <cjwatson> snap
[15:25] <arges> Is there a link to the new rolling release schedules showing freeze dates etc? Or is this something being worked on this week
[15:25] <cjwatson> Not set yet
[15:26]  * xnox likes +1 as well
[15:27] <barry> it's been a while since i did a +1, so i'd be up for doing another stint
[15:27] <xnox> slangasek: ^^ two more
[15:27] <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 ;))
[15:27] <arges> I volunteer 50% of me for another month.
[15:27] <arges> pending mgr approval : )
[15:27]  * mitya57|uds didn't see any schedule, but hopes there won't be freeze in two days ;)
[15:28] <pgraner> arges, https://wiki.ubuntu.com/DraftReleaseSchedule
[15:28] <arges> pgraner: cool
[15:29] <mitya57|uds> pgraner: so there *will* be freeze? :(
[15:29] <pgraner> mitya57|uds, prior to the LTS
[15:30] <pgraner> mitya57|uds, and any point releases
[15:30] <cjwatson> the freezes on the left are from the unmodified raring schedule
[15:30] <mitya57|uds> the draft schedule you linked says "March 7th"
[15:30] <pitti_uds> cjwatson: FYI, I muted you as your typing was quite loud
[15:30] <arges> steve froze
[15:30] <mitya57|uds> cjwatson: ah, nice then
[15:30] <Laney> oh noes
[15:31] <arges> yup works now
[15:31] <slangasek> am I still frozen?
[15:31] <geofft> I'm distinctly not volunteering, but I'm curious what the requirements are
[15:31] <pitti_uds> oops, my hangout crashed
[15:31] <cjwatson> pitti_uds: ah, sorry, new laptop and I'm not used to it yet
[15:31] <jpickett> yep
[15:31] <cyphermox> yes
[15:31] <xnox> slangasek: yeah you are fine.
[15:31] <geofft> both in terms of whether you need to have upload rights to things
[15:31] <jsjgruber-uds> you are ok now, steve
[15:31] <skellat> And you all are back
[15:31] <apw> slangasek, i can hear you
[15:31] <pgraner> mitya57|uds, thats the part of the original sechedule so people can see the contrast
[15:31] <geofft> and time commitment
[15:31] <xnox> pitti_uds: rejoin =)
[15:31] <jsjgruber-uds> yes
[15:31] <retoaded> yes
[15:31] <xnox> slangasek: yes, we can.
[15:31] <pgraner> mitya57|uds, columns are labeled :)
[15:31] <apw> slangasek, we had a like a netsplit, three of you wen't pop
[15:32] <mitya57|uds> :)
[15:32] <arges> thanks again : )
[15:33] <geofft> yeah, it sounded to me like Debian RC-bug squashing, which you can do unprivileged if you have a friendly sponsor
[15:33] <geofft> would be good to mention on the wiki page
[15:33] <geofft> thanks!
[15:35] <xnox> slangasek: cjwatson: sorry what?
[15:36] <xnox> ah ok.
[15:36] <xnox> slangasek: but jenkins QA is quicker.
[15:37] <xnox> cjwatson: jenkins notices quicker than people wakeup, and QA are pinging about those.....
[15:37] <slangasek> https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Priorities
[15:38] <slangasek> xnox: proposed-migration notices even quicker from jenkins, and I think infinity pulls from that report
[15:38] <cjwatson> proposed-migration does not notice component mismatcehs
[15:38] <slangasek> oh
[15:38] <cjwatson> But component-mismatches does :-)
[15:38] <slangasek> I mean component-mismatches
[15:38] <slangasek> :)
[15:38] <cjwatson> jenkins notices after there's an image build
[15:38] <xnox> can we autofix them =) or block building images? (sounds like a too big of a hammer)
[15:39] <psivaa__> Do you expect any change in the way we, QA communicate to you regarding the daily smoke test failures? :)
[15:40] <rbasak> I'm good
[15:40] <rbasak> For April
[15:40] <xnox> psivaa__: I'm yet to reply to your email, btw. mostly you are right and do the right thing.
[15:40] <rbasak> pgraner: ^^
[15:40] <cjwatson> It's basically fine, it's just you shouldn't need to do so much work
[15:40] <xnox> psivaa__: the blocker is fixing things quicker on our side and/or communicating that the next image should be fine.
[15:40] <slangasek> xnox: the right answer is to not lose the overrides that were already present in -proposed when pocket-copying
[15:40] <cjwatson> Which is 90% addressed by my action to ... what slangasek said
[15:40] <psivaa__> xnox: fine then :-)
[15:40] <xnox> ok.
[15:40] <xnox> psivaa__: ;-)
[15:41] <arges> cool thanks
[15:41] <kamal> thanks +1 Maintenance Team... keep up the good work!
[15:41] <mitya57|uds> thanks!
[15:48] <xnox> stgraber: are you by any chance going to drop by http://summit.ubuntu.com/uds-1303/meeting/21606/client-1303-ubuntu-touch-porting/
[15:48] <xnox> ?
[15:49] <xnox> it's about porting ubuntu-touch quantal patches to raring which includes interesting things like resolvconf, mountall, telepathy stacks...
[15:49] <stgraber> xnox: when is that?
[15:50] <xnox> stgraber: it's next in parallel with "should we switch to rolling release"
[15:50] <xnox> Laney: that session above is also questioning maliit.
[15:50] <Laney> yeah, stupid scheduling there
[15:50]  * Laney grumps
[15:50] <seb128> everybody is going to go to the rolling release one, right?
[15:51]  * seb128 feels like the rebase on raring will be empty
[15:51] <xnox> stgraber: there is ophono questions on that etherpad as well.
[15:52] <tumbleweed> Laney: I just got that one moved to suit me, stop grumping
[15:52] <Laney> yah boo
[15:52] <Laney> seb128: The rebase one was interesting because I expect to be doing some of the work there
[15:53] <stgraber> xnox: well, kinda hard for me to attend two sessions at once...
[15:53] <Laney> but the rolling one is also obviously quite important
[15:55] <zyga-uds> seb128: hey, how can the session lead get a link to the hangout?
[15:57] <sfeole> o/
[15:58] <roadmr> hello
[15:58] <diwic> hello
[15:59] <diwic> stream hasn't started yet
[15:59] <diwic> or has it?
[15:59] <doanac_> diwic: i don't think it has
[16:00] <sfeole> offline for me here
[16:00] <zyga-uds> are we on?
[16:00] <sfeole> i dont think so
[16:00] <brendand_> no video yet
[16:01] <smagoun> +1, no video for the plainbox session yet
[16:01] <smagoun> i see video now
[16:01] <roadmr> smagoun: it should be working now
[16:01] <diwic> okay, it's on
[16:02] <zyga-uds> IF YOU WANT TO BE IN THE HANGOUT PING ME (zyga)
[16:02] <roadmr> http://summit.ubuntu.com/uds-r/meeting/21051/cert-r-checkbox-simplification/
[16:10] <roadmr> it has tests - which checkbox lacked for a large portion of the core
[16:10] <roadmr> it has documentation - which checkbox sorely lacked (high bus factor)
[16:16] <smagoun> ara_: what is the plan to add manual tests to plainbox?
[16:16] <brendand_> cwayne - it has a cli at the moment
[16:16] <ara_> smagoun, they are there, but we don't have a UI connected yet to plainbox
[16:16] <ara_> they work, but just with cli
[16:16] <smagoun> ara_: Will checkbox + plainbox be maintained in parallel until plainbox can run manual tests?
[16:16] <brendand_> cwayne - so you can run manual tests but you will get just a text prompt
[16:16] <roadmr> smagoun: did what zyga just say solve your question?
[16:16] <ara_> smagoun, of course
[16:16] <zyga-uds> plainbox.readthedocs.org
[16:16] <ara_> this is going to be an incremental development
[16:17] <brendand_> cwayne - a bit like checkbox-cli at the moment
[16:18] <cwayne> whats the difference between this and utah?
[16:18] <roadmr> cwayne: why don't you ask zyga directly in the hangout :)
[16:19] <cwayne> didnt want to interrupt :)
[16:20] <sfeole> he just answered my question
[16:21] <sfeole> pkg depends
[16:21] <roadmr> sfeole: ftw!
[16:21] <sfeole> :P
[16:23] <nuclearbob> they're tailored to different workflows based on the needs of the teams developing them :)
[16:23] <smagoun> is there a comparison of plainbox/utah someplace?
[16:23] <roadmr> nuclearbob: exactly :)
[16:23] <roadmr> smagoun: no, but it'd be good to have
[16:24] <smagoun> roadmr: +1, are you volunteering? :)
[16:24] <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
[16:24] <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
[16:24] <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
[16:25] <ara_> smagoun, I will create a work item
[16:25] <nuclearbob> roadmr: that was the initial goal of utah as well
[16:25] <smagoun> roadmr: nuclearbob: Are the tests themselves interchangeable between checkbox/plainbox/utah?
[16:25] <nuclearbob> smagoun: I don't think they are right now, that's an area where work is ongoing
[16:25] <roadmr> smagoun: not at the moment
[16:26] <brendand_> utah doesn't support manual tests does it?
[16:26] <nuclearbob> brendand_ that's correct
[16:27] <smagoun> I/my team want that (convergence in test case format) so that test cases can be shared across checkbox/plainbox/utah
[16:27] <cwayne> that was weird
[16:27] <nuclearbob> smagoun: I think that would be useful for a lot of teams
[16:27] <brendand_> smagoun - checkbox and plainbox are synonymous here
[16:27] <cwayne> sfeole: what did i miss?
[16:30] <smagoun> +1 for separation of the test runner and the test cases
[16:31] <nuclearbob> +1 from me as well
[16:31] <roadmr> smagoun, nuclearbob : that was an obvious improvement, tbh not sure why we didn't do it before :/ hehe
[16:32] <nuclearbob> roadmr: a lot of things seem obvious after they're already done :)
[16:39] <ara_> you guys are just trying to avoid C++ :)
[16:39] <roadmr> ara_: hey, at least it's not Java %)
[16:40] <bkerensa> =)
[16:40] <sfeole> long live CLI :P
[16:41] <brendand_> ara - no not avoiding c++, avoiding horrible uneccesary glue code :)
[16:42] <brendand_> ara - the other option would be to write plainbox in c++. how about it!?
[16:42] <roadmr> can we leverage the new qml goodies? it'd be cool to have a phone-friendly plainbox ui :D
[16:43] <brendand_> roadmr - it would definitely be worth thinking about if we do a full remastering of the ui
[16:44] <brendand_> roadmr - cr3's initial reservation about qml that there is no good widget library is made redundant by the phone SDK
[16:44] <roadmr> brendand_: yep
[16:45] <nuclearbob> I can be on the utah half of the comparison
[16:45] <roadmr> nuclearbob: thanks, signing you up :)
[16:45] <spineau> AFAIK there's no qt5 python bindings available yet
[16:46] <roadmr> plainbox.js FTW?
[16:50] <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 ;)
[16:52] <cwayne> i just liked being able to see the tree of test cases and be able to quickly add one roadmr :)
[16:52] <roadmr> cwayne: plainbox provides a good set of foundations to make that happen
[16:53] <cwayne> roadmr: ++
[16:53] <zyga-uds> https://plainbox.readthedocs.org/en/latest/dev/index.html
[16:53] <brendand_> cwayne - try and write down what checkbox editor does that you really use
[16:53] <cwayne> brendand_: yep, already started :)
[16:53] <brendand_> cwayne - we'll want to ask about it later on
[16:55] <roadmr> ok, where to now?
[16:55] <zyga-uds> smagoun: checkbox and plainbox use the same test case definition format
[16:55] <slangasek> zyga-uds: and broadcast ended :)
[16:56] <roadmr> slangasek: thanks for manning the a/v controls :D
[16:56] <slangasek> sure thing
[16:56] <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
[16:56] <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
[16:57] <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
[17:02] <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
[18:22] <plars> is this one happening?
[18:22] <plars> ah, I see it just fell off the schedule
[18:48] <slangasek> hmm, why don't we have channel topics
[18:52] <lool> cjohnston: can you give powers to slangasek to set channel topic?  e.g. op him
[18:52] <lool> looks like udsbot isn't here
[18:52] <lool> cjohnston: Might just be missing udsbotu
[18:52] <cjohnston> lool: appears so
[18:53] <lool> cjohnston: is it in your powers to fix udsbotu or would you know who to ping?
[18:53] <cjohnston> im trying to ping
[18:59] <cjohnston> lool: its here
[18:59] <lool> cjohnston: thanks, you rock
[19:00] <lool> slangasek: topic(s) fixed
[19:00] <slangasek> lool: cheers
[19:00] <slangasek> ogasawara: hangout url is up
[19:03] <slangasek> although firefox is trying to kill my machine with swap
[19:03] <xnox> "This live event will begin in a few moments"
[19:03] <ogasawara> slangasek: you're a bit jittery on this end
[19:03] <slangasek> yep
[19:03] <apw> must ... fit ... entire ... google ... search ... db ... into slangasek swap
[19:04] <smagoun> xnox: +1, waiting on youtube too
[19:04] <cjwatson> solution: more swap
[19:04] <ara> waiting as well
[19:04] <slangasek> cjwatson: hehno
[19:04]  * xnox pondered to put thunderbird into a cgroup such that it can learn to cope with having limitted RAM
[19:04] <smagoun> slangasek: you could put your swap partition/file into a tmpfs. Should be much faster!
[19:04] <arges> and its live!
[19:04] <mlankhorst> where's the hangout?
[19:04] <smb> here
[19:04] <slangasek> cjwatson: you do know that firefox scales its cache according to how much system memory it sees?
[19:04] <smb> refresh
[19:05] <xnox> and we are live!
[19:05] <arges> http://www.youtube.com/watch?feature=player_embedded&v=ph0V8i3sB5o&newstate=f79cf6d226e46a7e27e2874a67c67c88
[19:05] <xnox> slangasek: leanne is not here.
[19:05] <slangasek> xnox: where?
[19:05]  * mlankhorst should probably be pulled into speakers
[19:05] <xnox> slangasek: never mind, tab complete fail.
[19:05] <slangasek> mlankhorst: you are marked for it, do you not see the link for the google hangout?
[19:05] <xnox> ogasawara: heya =)
[19:05] <cjwatson> slangasek: where the scaling factor is 100%?
[19:05] <slangasek> cjwatson: roughly ;)
[19:06] <cjwatson> I'm not seeing the hangout link either; dunno if I'm supposed to
[19:06] <cjwatson> where would it be?
[19:06] <apw> cjwatson, more refreshing
[19:06] <smb> http://www.youtube.com/watch?feature=player_embedded&v=ph0V8i3sB5o
[19:06] <apw> ogasawara, we seem to be missing 'two people' on the right
[19:06] <cjwatson> I mean hangout not youtube :)
[19:06] <cjwatson> ah, got it from Steve now
[19:07] <tjaalton> mlankhorst: so you get to install it anyway ;)
[19:07] <slangasek> yeah, I don't know where the link shows up on the page
[19:07] <xnox> People on hangout please add your subtitles =) "third from the bottom in the toolbox" or something like that.
[19:08] <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
[19:09] <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
[19:10] <slangasek> xnox: "lower third" is the name of the tool, not its position in the menu :)
[19:10] <smagoun> apw: +1 that is my recollection
[19:10] <xnox> slangasek: =) Kylin ;-)
[19:10] <slangasek> xnox: duì
[19:11] <apw> cjwatson, i think we wanted to offer both options, for the period up to 14.04
[19:11] <cjwatson> Right
[19:11] <apw> cjwatson, so either have -quantal installed to stay, and -hwe to roll
[19:13] <pgraner> ogasawara, we felt they were flexible due on the availability of the HWE package
[19:13] <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
[19:13] <pgraner> smagoun, the point releases wouldn't change
[19:14] <pgraner> smagoun, the only thing that was up in the air was the release frequency
[19:14] <CarlRichell> Intel haswell is expected to be released around June. Are haswell chipsets and graphics support expected in 12.04.X?
[19:14] <cjwatson> I'll forward that to Rick; might as well include it in whatever we eventually document regarding rolling etc.
[19:14] <smagoun> pgraner: right, is that written someplace (besides here?). My group's partners would appreciate the confirmation
[19:14] <apw> slangasek, 'whos' upstream releases ?
[19:14] <cjwatson> smagoun: ^-
[19:14] <jmleddy> well except for i915_hsw
[19:15] <smagoun> cjwatson: thanks!
[19:15] <cjwatson> smagoun: Nothing has actually been formally announced yet anyway :)
[19:15] <slangasek> apw: well, I was referring to hardware vendors' support landing upstream
[19:15] <pgraner> smagoun, you won't get ANYTHING WRITTEN until decisions are made, we are still talking at this point
[19:15] <apw> slangasek, right but ... they arn't really all sync'd was my only point
[19:15] <slangasek> apw: primarily wrt the platforms themselves
[19:16] <bryyce> for X package naming, will we use something different than -lts-raring?
[19:16] <tjaalton> CarlRichell: is in 12.04.2 already
[19:16] <xnox> bryyce: -lts-raring.1 ? =)
[19:16] <CarlRichell> tjaalton: thanks!
[19:16] <apw> bryyce, yeah the nameing is an issue, using -quantal and -raring was probabally a mistake anyhow
[19:16] <apw> -12.04.3 ?
[19:16] <bryyce> meh
[19:17] <apw> slangasek, can we not follow the same basic plan, push something into -proposed 3m before the point release
[19:17] <cjwatson> you can upgrade to 12.04.3 without switching to the new stack, so that would be confusing
[19:17] <bryyce> apw: although to be honest I can't think of any better suggestions
[19:17] <apw> cjwatson, fair pint
[19:17] <xnox> No.
[19:18] <mlankhorst> bryyce: I was thinking of adding version, mesa-9.1 and xserver-1.14 or something
[19:18] <xnox> because we were taking a non-lts stack
[19:18] <xnox> Stabilise in precise-proposed?
[19:18] <xnox> too late?
[19:18] <mlankhorst> it should be stable before then
[19:18] <jmleddy> are we going to be basing it off of one of the monthly snapshots?
[19:18]  * apw concurs with xnox ... stabalise for some time in precise-proposed and release later
[19:19] <xnox> mlankhorst: but we can't stabilise in rolling. it should keep on going.
[19:19] <cjwatson> There's the problem that relatively few people use precise-proposed, even compared to the number who use non-LTS releases
[19:19] <cjwatson> So I guess it depends how much you're dependent on organic reports from random users as opposed to organised smoke-testing
[19:19] <mlankhorst> xnox: the thing is that for xorg / mesa we usually do big bumps, rest is stabilization
[19:19] <apw> cjwatson, yes there is that, but at least its not dumped into -updates without any testing that way
[19:19] <jmleddy> what about a 12.04.3 beta?
[19:19] <bryyce> at least for the X stack, stabilizing in RR would probably work out fine
[19:20] <apw> cjwatson, and presumably we use the normal plan of doing point release qa against -proposed
[19:20] <mlankhorst> so for mesa/xserver it's more stable by following and just postponing version bumsp until after a point release
[19:20] <xnox> cjwatson: sure, for -lts-raring we did dailies from proposed and call for testing.....
[19:20] <cjwatson> We could do a beta based on image builds from -proposed, I suppose, yes
[19:20] <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
[19:20] <cjwatson> Might be necessary given reduced feedback from later series
[19:20] <bryyce> tjaalton: right
[19:20] <xnox> cjwatson: can we land it in -updates, but not flip the switch to upgrade people / not build images?
[19:20] <cjwatson> Easier to build images off -proposed, I think
[19:20] <cjwatson> Once we land it in -updates, at least some people are going to upgrade
[19:20] <apw> ogasawara, i think the unaggreed part there is whether the -next is in archive or in a PPA
[19:21] <apw> ogasawara, yes he is
[19:21] <xnox> slangasek: just type, you are breaking apart.
[19:21] <smagoun> slangasek: you're breakaing up
[19:21] <bryyce> slangasek: type it in irc
[19:21] <xnox> slangasek: reconnect, please.
[19:21] <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 :)
[19:21] <bryyce> tjaalton: yeah
[19:21] <mlankhorst> tjaalton: the second newest the better
[19:21] <cjwatson> (I mean, given that we build images off -proposed for some period of time between point releases anyway)
[19:21] <mlankhorst> newest always has fallout
[19:21]  * xnox welcomes slangasek to swap death =)
[19:21] <tjaalton> mlankhorst: maybe, depends. also if someone else is using a release as a stable release..
[19:22] <tjaalton> *kernel release
[19:22] <mlankhorst> indeed
[19:22]  * mlankhorst always finds 1 or 2 bugs in pre-release kernels
[19:22] <geofft> Tangentially, how (if at all) does the rolling linux-next proposal interact with e.g. xorg-edgers?
[19:22] <jmleddy> I think we should use 3.9
[19:22] <apw> bjf, we should consider taking whatever will give us a couple of months of stabilisation
[19:22] <jmleddy> for the new Haswell support
[19:22] <apw> (if we arn't releasing 13.04)
[19:24] <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
[19:24] <kamal> slangasek: session video is locked on ogasawara -- can you fix that?
[19:24] <arges> oh noes
[19:24] <xnox> hangout crashed
[19:24] <smb> kamal, jinx
[19:24] <smagoun> doh, lost the hangout entirely on youtube
[19:24] <smb> now it is gone completly
[19:25] <pgraner> hangout died
[19:25] <jsalisbury> hangout gone
[19:25] <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.
[19:25] <jmleddy> what happened?
[19:25] <cjwatson> apw: I guess I'm mostly trying to establish dates
[19:25] <ppisati> ???
[19:25] <jmleddy> google--
[19:25] <xnox> I think slangasek hit the reset button, taking the hangout down.
[19:25] <apw> ahh
[19:25] <cjwatson> Some of us are still on G+
[19:25] <xnox> as he was "hosting" the show.
[19:25] <bryyce> ah
[19:25] <geofft> bryyce: Right, so does "compatible" mean "they'll just turn into the same thing"?
[19:25] <xnox> cjwatson: but it's not transmitted to the "public"
[19:26]  * xnox We'll be right back.
[19:26] <xnox> slangasek: it should take 8second to boot into desktop right?! =)
[19:26]  * smb is glad there is no elevator music
[19:26] <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
[19:26] <cjwatson> I am greatly enjoying the irony of my G+ video actually working better than >0 other people's
[19:26] <cjwatson> OK, so what's the schedule for 3.9, ish?
[19:26] <utlemming> the hangout seems to have died. There is "We'll be right back" message
[19:27]  * mlankhorst has been trying very hard not to close his laptop
[19:27] <utlemming> at least the Youtube broadcast is dead
[19:27] <bjf> the merge window just closed
[19:27] <apw> cjwatson, we just hit 3.9-rc1, so 7-8 weeks
[19:27] <cjwatson> mkay
[19:27] <bryyce> geofft: the X stack and kernel are not tightly coupled, you can mix and match to a large degree.
[19:27] <cjwatson> so that's early May
[19:27] <diwic> tjaalton, for audio, I tend to agree
[19:27] <apw> bjf, when was .3 ?
[19:27] <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" :)
[19:28] <tjaalton> also, less things have changed
[19:28] <bjf> apw, aug. 15
[19:28] <diwic> tjaalton, three months is a bit much, maybe 1 - 2 months would be better
[19:28] <diwic> the 3.9 kernel is going to be fun for audio though
[19:28] <apw> bjf, so we would expect 3.10 to drop before the point release, but not by much
[19:28] <xnox> can we start a new hangout while slangasek reconnects?
[19:28] <diwic> but that's another story
[19:28] <apw> xnox, i think he is the one who knows how the stream clicks work
[19:29] <xnox> apw: =) special training I take it.
[19:29] <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
[19:29] <apw> xnox, very special, with pints of beer no doubt
[19:29] <xnox> apw: a fly-in physical sprint at google campus? =)))))
[19:29] <tjaalton> diwic: yeah, hard to find a balance.. it does take some time to shake out the worst bugs
[19:29] <apw> geofft, there are two components, for some things the kernel is enough, obviously for graphics you need both
[19:29] <xnox> delay point release, if not stable as a contingency?!
[19:30] <apw> geofft, so nominally you can have half of it if the half you want is hte kernel
[19:30] <cjwatson> engaged in SMS conversation with Steve
[19:30]  * 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
[19:30] <diwic> "The live recording you're trying to play is still being processed and will be available soon."
[19:31] <xnox> diwic: yeah, it went into archiving mode.
[19:31] <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
[19:31] <xnox> such that a new session / url will need to be started.
[19:31] <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
[19:31] <smb> Happened before. Someone has to post the link to part
[19:31] <smb> 2
[19:31] <cjwatson> Software is great
[19:31]  * cjwatson goes to take up sheep-farming
[19:32] <mlankhorst> cjwatson: well this uds is making me want to do that!
[19:32] <gQuigs> maybe WebRT will be ready by the next UDS
[19:32] <kamal> video is back up
[19:32] <xnox> cjwatson: well the skills are transferable, no why not?
[19:32] <jmleddy> is there a youtube link where they are broadcasting ?
[19:32] <kamal> oh, no my mistake
[19:33] <cjwatson> jmleddy: I think you probably won't get one until Steve gets sorted
[19:33] <xnox> live is not up, just the recording of the first 25minuts.
[19:33] <xnox> jmleddy: hangout is down at the moment.
[19:33] <jmleddy> okay
[19:33] <jmleddy> so it isn't like the hangout is going on without us
[19:34] <diwic> the question is; if we package both linux-rc and linux-stable how many will follow/test each one
[19:34] <apw> right they anr't talking at all,
[19:34] <jmleddy> cool
[19:34] <xnox> diwic: one will find out from errors.ubuntu.com and submitted bug reports.
[19:34] <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
[19:34] <xnox> diwic: at least thre relative split and stability comparison.
[19:35] <jmleddy> we can also get testing help from partners if there are new enablement pieces
[19:35] <diwic> what about QA/cert work for testing the kernels today?
[19:35] <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
[19:35] <apw> diwic, the QA testing i have seen can cope with the use of overlay package at least i think
[19:36] <ara_> apw, is the youtube stream back up? what's the url?
[19:36] <apw> not that i have heard
[19:36] <ara_> ok
[19:36] <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?
[19:37] <apw> diwic, it would seem logical they would continue to test 'development' and the point releases as they do now
[19:37] <pgraner> diwic, that won't change
[19:37] <pgraner> diwic, we will test as usual
[19:37] <ara_> slangasek, have you restarted the streaming? in the page we only get the recorded video for the first 25 minutes
[19:37] <diwic> pgraner, could you refresh my memory about what testing is being done today?
[19:37] <slangasek> I've just launched a new hangout
[19:38] <slangasek> cjwatson, ogasawara, apw, bjf, mlankhorst : if you refresh you should have the new link now
[19:39] <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...)
[19:39] <kamal> slangasek: thanks -- up now:  http://summit.ubuntu.com/uds-1303/meeting/21598/foundations-1303-hwe-stack/
[19:39] <cjwatson> slangasek: refresh what, summit?
[19:39] <kamal> it is working
[19:39] <smb> http://www.youtube.com/watch?feature=player_embedded&v=pXTfcl4kee4
[19:39] <slangasek> cjwatson: yes
[19:39] <cjwatson> summit doesn't give me a hangout link
[19:39] <slangasek> hmm
[19:39] <jmleddy> it is working for me
[19:39] <cjwatson> (hangout != youtube)
[19:39] <diwic> plars, how wide is that testing?
[19:40] <plars> diwic: "wide"?
[19:40] <diwic> plars, like, 5 or 50 different machines?
[19:40] <pgraner> diwic, it does not include audio if thats what your getting at
[19:40] <smb> cjwatson, that was more for apw
[19:40] <slangasek> cjwatson: sorry... I haven't seen the link in summit myself, but I've been assured it's somewhere
[19:41] <xnox> https://www.youtube.com/watch?v=pXTfcl4kee4&feature=plcp for public viewing =)
[19:41] <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
[19:41] <plars> diwic: ...and kvm/xen as well
[19:41] <ppisati> dead again
[19:41] <jjohansen> ppisati: not for me
[19:41] <xnox> ppisati: not here. are you using the new url or the archive url?
[19:42] <ppisati> refresh did it
[19:42] <xnox> ppisati: that will not help, you want new url. If you are part of hangout
[19:42] <xnox> check summit for new hangout invite.
[19:42] <ppisati> xnox: no, i'm not part
[19:42] <xnox> ppisati: for public viewing see https://www.youtube.com/watch?v=pXTfcl4kee4&feature=plcp
[19:43] <diwic> plars, so just a few machines and not a complete hardware go-through (since it doesn't include audio), correct?
[19:44] <xnox> slangasek: what about steam and games? mir will work for them?
[19:44] <plars> diwic: that's just for the bits that I touch, cert may have some additional hw they test on as well, ara_?
[19:45] <bryyce> wish I could chime in on the hangout
[19:45] <ara_> diwic, so for certification we test point release with a range of hardware, depending on enablement
[19:46] <jmleddy> it would be nice to know that nvidia and fglrx is still working in tip
[19:46] <bryyce> slangasek: there's a lot of factors we account for when deciding about updating the xserver stack
[19:47] <bryyce> slangasek: certainly we'll take into account if we don't need anything from a newer X and are focusing on mir
[19:47] <bryyce> no, X and mesa can usually be updated independently (and we often do)
[19:47] <xnox> slangasek: can you add bryyce to the hangout?
[19:47] <tjaalton> X and mesa releases tend to have the same cadence
[19:48] <mlankhorst> bryyce: yeah but they usuall get released around the same time, so we usually ship both together :)
[19:48] <bryyce> tjaalton: yeah but not due to tight coupling, just that the maintainers often are on the same schedule
[19:48] <tjaalton> bryyce: right
[19:48] <xnox> apw: why can't one build dkms modules against linux-next and linux-general?
[19:48] <xnox> in-archive?
[19:48] <apw> xnox, you could but you are changing the pacacking potentially
[19:49] <xnox> apw: true. point taken.
[19:49] <xnox> (well dkms config file....)
[19:50] <ara_> certification will also be more difficult, we would basically need to recertify everything in every point release
[19:50] <arges> could we just have two?  a base LTS version 3.2 and then the rolling version?
[19:50] <ara_> but we could probably do a recertification in a subset of systems covering a set of components
[19:51] <xnox> cjwatson: well not the .1 (that didn't have hwe?!)
[19:51] <jjohansen> ogasawara: we reduce support burden in that its only a select set of packages for HWE, of course nothing for kernel
[19:52] <jjohansen> yeah that is how I remember it as well
[19:52] <cjwatson> xnox: I couldn't remember :)
[19:52] <diwic> If we support things for 6 months only, that's not an unusual time for pre-load machines to be in the store...
[19:53] <xnox> cjwatson: me neither to be honest, all I recall is d-i and lvm....
[19:53] <cjwatson> diwic: Right, I don't think we can withdraw support without having automatic upgrade to something that is supported
[19:53] <xnox> who is typing so loud?
[19:53] <mlankhorst> cjwatson
[19:53] <cjwatson> Oh, sorry, might've been me
[19:53] <cjwatson> Keep forgetting to mute
[19:54] <bryyce> work items?
[19:54] <arges> ogasawara: am i missing something. are we keeping for example the precise 3.2.x kernel as a supported kernel
[19:55] <mlankhorst> probably
[19:55] <bjf> arges, the support for precise is not changing
[19:55] <xnox> we could stay longer as this is the last session for the day.
[19:55] <superm1> slangasek: yes i agree with that.
[19:56] <tjaalton> fewer point-releases would mean trouble hwe-wise
[19:56] <ara_> .4 is the last one
[19:56] <arges> bjf: ok ok
[19:56] <jmleddy> 12.04.2 came out in feb, and 13.04 would have been 2 months later
[19:56] <jmleddy> so it's just the same thing one year later
[19:56] <slangasek> xnox: bryyce should be on the invite already, dunno why he's not in here. :)
[19:57] <jmleddy> that's probably a bad idea
[19:57] <jmleddy>  based on the hardware schedules
[19:57] <CarlRichell> that's the case for system76 as well
[19:57] <xnox> slangasek: ogasawara: should the .3 moved then?! and hence less work then.
[19:57] <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
[19:57] <xnox> nice.
[19:58] <cjwatson> Well, .3 isn't *just* for hwe :)  We could skip hwe in it without skipping the whole pr
[19:58] <cjwatson> (General roll-up of updates and such)
[19:58] <tjaalton> so, are we talking about point-releases as always having a backport stack?
[19:59] <cjwatson> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.2 - all changes from .1 to .2
[19:59] <diwic> jmleddy, do we have haswell in .2?
[19:59] <jmleddy> diwic: not ULT
[19:59] <cjwatson> Well, roughly all, depending on the vagaries of my half-arsed script
[19:59] <diwic> jmleddy, ULT = ?
[19:59] <tjaalton> maybe have .3 but just with an improved .2 stack
[19:59] <xnox> and maintain for updates and security.
[19:59] <CarlRichell> exception being if optimus support could make .3 release
[19:59] <jmleddy> diwic: I was going to ask you about that actually, the ULT has a new audio chipset
[19:59] <mlankhorst> CarlRichell: not going to happen
[19:59] <CarlRichell> one can wish, right?
[19:59] <jmleddy> diwic: ULT is a new chip
[20:00] <danjared> skipping 12.04.3 definitely needs to be reviewed from the server perspective
[20:00] <jmleddy> the big thing is a new audio DSP
[20:00] <jmleddy> that just went to the linux mailing lists
[20:00] <danjared> we (Dell) can talk with Canonical about this, though
[20:00] <narindergupta> most of OEM supports only LTS and point releases only.
[20:01] <jmleddy> client OEMs are not going to use .3
[20:01] <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
[20:01] <cjwatson> danjared: Can you elaborate?
[20:02] <cjwatson> I know there are bugs outside hardware enablement that need to be addressed
[20:02] <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 :)
[20:02] <xnox> slangasek: ok. sounds like a good enough promise to me.
[20:02] <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
[20:02] <cjwatson> Gotcha
[20:03] <rtg> danjared, that was my point about possibly needing a HWE kerenl in the point release, e.g., to support new boot essential devices.
[20:03] <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
[20:03] <danjared> right, what superm1 said
[20:03] <narindergupta> i am talking about server prospective
[20:05] <danjared> cjwatson: -> private
[20:08] <xnox> cjwatson: slangasek  could be backport the unity-quantal for .3
[20:08] <xnox> s/be/we
[20:17] <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
[20:28] <cjwatson> It doesn't, indeed.  The net outcome might be better for 12.04 users though
[20:28] <cjwatson> (System76 brought up how much better 13.04's unity was in the rolling release session earlier)


[01:16] <wgrant> StevenK: Ah
[01:16] <wgrant> StevenK: You broke the build twice.
[01:50] <StevenK> wgrant: I did notice, yes.
[01:50] <StevenK> One of them I'm annoyed about, since that test failed in ec2 and then locally
[01:51] <StevenK> However, it also seems we have a smoking gun for the postgres connection leak. Maybe.
[02:04] <wgrant> StevenK: The postgres leak first showed up in r15502, 68 revs before this reliable failure.
[02:05] <wgrant> But the immediate issue is fixed.
[02:06] <StevenK> wgrant: Ah, nice.
[02:06] <StevenK> How does that deal with ClassAlias? It doesn't?
[02:07] <wgrant> StevenK: __storm_table__ on a ClassAlias is correct.
[02:07] <wgrant> So it should be fine.
[02:07] <wgrant> We'll find out for sure in 5.5 hours
[02:10] <StevenK> wgrant: The Armor of Al'tair is mine, btw
[05:18] <rigel_> Hello, I saw the hiring notice on the Launchpad blog, and I noticed it mentioned having an interest in Haskell. I was wondering if Canonical have plans to use Haskell for any projects in the future. Thanks!
[08:44] <cjwatson> hm, qastaging looks unhappy
[08:45] <cjwatson> (503 for the last hour or so)
[08:46] <StevenK> That's not good, because that is roughly the time the latest revno would have hit it.
[09:14] <wgrant> cjwatson, StevenK: It's probably due to a bug in the new staging restore procedure.
[09:14] <wgrant> It's meant to take staging down for a day or so, but not qastaging.
[09:14] <wgrant> fg
[09:14] <wgrant> fg
[09:22] <cjwatson> StevenK: I should've said "at least the last hour or so" - I have no information about before that
[10:59] <czajkowski> aloha
[11:01] <jelmer> kai ora
[11:02] <nigelb> jelmer: Isn't it kia ora? :)
[11:02] <jelmer> nigelb: euhm, yes, thanks :)
[11:03] <nigelb> :D
[11:05] <czajkowski> nigelb: pedantic :)
[11:05] <czajkowski> jelmer: ello hows you
[11:05] <nigelb> Hah :)
[11:09] <jelmer> czajkowski: all's well :) how's your weekend?
[11:13] <czajkowski> not bad, got into a tidying mode yesterday and redid the spare room so all the shuttle boxes are now labeled and I can now see the drobo box and router are off the ground
[11:14] <czajkowski> am going to attempt to tackle the wiring later on that is currently glaring at me once I come back from lunch
[11:40] <jelmer> czajkowski: sounds awfully well organized
[11:42] <czajkowski> jelmer: the spare room was a dumping ground for new gadgets, boxes servers and bf bike gear, there needed to be some order :)
[12:33] <StevenK> czajkowski: Ew, Drobo
[23:23] <cjwatson> Anyone fancy reviewing https://code.launchpad.net/~cjwatson/launchpad/queue-api-fix-urls/+merge/113776?  Last piece needed to make the API queue client basically usable.
[23:24] <cjwatson> (There's one bug remaining that shows up if you try to override just the section of a source upload; workaroundable in the client and easy to fix anyway.)
[23:30] <wgrant> cjwatson: That won't work
[23:30] <wgrant> cjwatson: It'll break the security team, since it won't work for private source.s
[23:31] <wgrant> sourceFileUrls was originally introduced for generating USNs.
[23:32] <cjwatson> I introduced sourceFileUrls.
[23:33] <wgrant> Ah yeah, different object.
[23:33] <cjwatson> What's a working way to do this?  Proxying through Archive definitely doesn't work ...
[23:34] <cjwatson> And it looked to me as though .getURL() worked for private URLs, but perhaps I was misreading
[23:35] <wgrant> Oh, getURL will work, yes. Thought you were still using http_url
[23:35] <cjwatson> (It starts "if not self.restricted:")
[23:35] <wgrant> But that's fairly evil
[23:36] <cjwatson> Because it hands out private URLs that can be passed on to anyone?
[23:38] <wgrant> Sort of
[23:38] <wgrant> We generally try to avoid issuing TLTs unless someone explicitly asks for them.
[23:38] <lifeless> (A TLT requires a DB commit)
[23:39] <lifeless> TLT's are the right thing to do to hand out urls into the librarian for private objects.
[23:39] <cjwatson> I guess an alternative would be to invent a thing to proxy URLs through the PackageUpload object
[23:39] <lifeless> But - unless you're very sure every script calling this will download the files, better to do what e.g. bugs do
[23:39] <wgrant> lifeless: In every single other case we redirect through the webapp.
[23:40] <lifeless> which is what wgrant just said :P
[23:40] <lifeless> wgrant: I thought, perhaps wrongly, that the API has a codepath to invoke the same thing
[23:40] <wgrant> No.
[23:40] <lifeless> huh
[23:41] <lifeless> so its uglier than even I appreciated ;)
[23:46] <cjwatson> So near and yet so far.


[00:48] <Noldorin> hlmm
[00:49] <Noldorin> does bzr have an equivalent of git cherry-pick?
[01:10] <bob2> http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html


[00:57] <kaushal> hi
[00:57] <kaushal> I have upgraded java6 from u22 to u24, I get this issue http://pastebin.ubuntu.com/606323/ I am on Ubuntu 8.04 Linux. Any Clue ?
[00:58] <kaushal> Further details -> http://pastebin.ubuntu.com/606327/
[19:48] <aboudreault> hiiiii
[19:48] <aboudreault> what's that: http://packages.ubuntu.com/natty/i386/libpng12-dev/filelist
[19:48] <aboudreault> /usr/lib/i386-linux-gnu/libpng.so
[19:48] <aboudreault> This will break a lot of configure script, isn't?
[19:54] <Ampelbein> aboudreault: not if they use pkg-config.
[19:54] <aboudreault> most of them use autoconf and check the /usr/lib directory
[19:57] <Ampelbein> aboudreault: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=
[19:57] <Ampelbein> &field.subscriber=&field.component-empty-marker=1&field.tag=multiarch&field.tags_combinator=ALL&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints
[19:57] <Ampelbein> .used=&field.has_no_blueprints=on  lists 30 known issues that are related to multiarch, please file a bug on the package in question and tag it as "multiarch"
[19:57] <Ampelbein> eek
[19:58] <Ampelbein> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=multiarch is the link I wanted to send
[19:59] <Ampelbein> aboudreault: anyway, most packages are fine. Please file a bug on the package that isn't.
[20:00] <aboudreault> the package is mine so...
[20:00] <aboudreault> but will have to tell dev to update their configure script.


[00:40] <blackboxsw> azure run looks like it is going ok w/ new creds https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-bionic-azure/70/console
[00:47] <blackboxsw> I mean with new pycloudlib && handling jenkins workers without azure-cli installed
[10:16] <aciba> blackboxsw: holmanb: https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-bionic-azure/70/ looks ok respect to the credentials problem. There are a couple of new ansible tests failing, but those are not new nor related to azure (see https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-kinetic-ec2/55/)
[12:16] <blackboxsw_afk> aciba: I think that run is ok as it was "Started 3 days 6 hr ago" before the ansible fixes.
[12:17] <blackboxsw_afk> we only need validate jenkins build runs which kicked off within the last 24 hours. (and hopefully kick off more manually, one per cloud, to get coverage)
[12:23] <blackboxsw> from the looks of jenkins timed runs are in progress right now for lxd_container/vm/gce and ec2. so hopefully some good results shortly
[13:46] <aciba> let's how they finish. About https://bugs.launchpad.net/cloud-init/+bug/1983306, I have created a PR here: https://github.com/canonical/cloud-init/pull/1644
[20:39] <ananke> this is a long shot, but I don't suppose anybody's familiar with how cloud-init works in conjunction with netplan? straight to the point though: I'm trying to execute custom code via dhclient's exit hooks, but that's not working on ubuntu (code does not execute at all. works fine on debian)
[20:40] <ananke> in the cloud-init logs I see that cloud-init copies and executes dhclient with its own set of options
[20:42] <ananke> and looks like its options are set to specify script to be /bin/true: 2022-08-09 20:19:02,244 - subp.py[DEBUG]: Running command ['/var/tmp/cloud-init/cloud-init-dhcp-0bf1kmdu/dhclient', '-1', '-v', '-lf', '/var/tmp/cloud-init/cloud-init-dhcp-0bf1kmdu/dhcp.leases', '-pf', '/var/tmp/cloud-init/cloud-init-dhcp-0bf1kmdu/dhclient.pid', 'ens5', '-sf', '/bin/true']
[20:48] <ananke> hah, so netplan points fingers at networkd-dispatcher: https://netplan.io/faq
[20:57] <ananke> hah. and I just figured out why I was getting poor results with networkd-dispatcher


[01:13] <bryceh> ogasawara, you might want to build a kernel for bug #614238; there's a confirmed patch that fixes it upstream.
[01:13] <ubot2> Launchpad bug 614238 in linux "Intel Core i3 External Monitor Wavy Output" [Medium,Confirmed] https://launchpad.net/bugs/614238
[01:26] <bjf> bryceh, looks like stable kernels
[01:28] <bjf> bryceh, ah! i fully read your last comment
[01:45] <bryceh> bjf, right.
[07:48] <smb> morning .+
[07:54] <apw> smb, moin
[07:57] <cking> morning
[07:59] <apw> cking, hiya
[07:59] <apw> cking, hows it going ?  win ?
[08:00] <cking> yep, win
[08:05] <jk-> winning
[08:06] <jk-> hey all.
[08:34] <Fudge> hi not sure if this is right place to ask, ive noticed often on my gigabyte g41 motherboard with realtek onboard audio, i boot form live ubuntu cd's and have to unmute the audio. the same goes the  after install and again when new kernels are installed. is this normal? or is it something related to my sound server?
[08:36] <smb> Fudge, That would rather be the sound server (pulse). Though I dunno how to avoid it
[08:37] <Fudge> smb , its well known then?
[08:37] <apw> audio changing on installing a new kernel is a common issue, something to do with having to flush the previous settings in case they are are a different binary form on the new kernel
[08:38] <apw> in my case it always unmutes, which is even more annoying
[08:38] <cjwatson> Hi - could somebody try a kernel test build in precise with kernel-wedge 2.81ubuntu1 to see if it gets rid of bug 879340?  If so, a fresh upload at some point this week would be very helpful
[08:38] <Fudge> any bug reports or docs I can refer to on it?
[08:38] <ubot2> Launchpad bug 879340 in linux "nic-shared-modules ballooned in size in precise" [Undecided,Confirmed] https://launchpad.net/bugs/879340
[08:38] <apw> cjwatson, is that in the archive already (kernel-wedge) ?
[08:38] <cjwatson> yes
[08:38] <apw> cjwatson, ok will do
[08:38] <cjwatson> uploaded yesterday evening
[08:38] <cjwatson> thanks!
[08:39] <cjwatson> if it doesn't help, I'm a bit stumped on what caused the problem in that bug report and wouldn't mind debugging it with somebody
[08:39] <Fudge> apw  I use a script called Vinux which is for visually impaired, screen readers etc. We find it difficult when people install a system or update and they get no audio. you can prob imagine someone who is blind gets in a bit of a stick.
[08:39] <apw> yeah i cannot deny you have a bit of a problem if you are blind ...
[08:40] <apw> Fudge, my expectation is you'd have the opposite problem, so i'd think filing a bug would be reasonable
[08:40]  * smb wonders whether TheMuso has something working for him
[08:40] <apw> especially due to the accessiblity concerns
[08:40] <Fudge> yeah mate loL, its nice to know its not just somethign we've done though, we also currently use pulseaudio in system mode and that was a possible contributor
[08:40] <ogra_> apw, why is it not possible to just re-read the alsa state file after applying everythig ?
[08:40] <Fudge> TheMuso  is aware but i bug him enough
[08:40] <Fudge> i had the same thought, but implementing such a thing i have no idea
[08:41] <ogra_> that should get you back exactly what you had
[08:41] <Fudge> im a thinker, not a coder loL
[08:41] <apw> ogra_, re-read in what sense
[08:41] <ogra_> apw, alsactl restore
[08:41] <apw> ogra_, my understnading is it is a kernel specific binary form
[08:41] <Fudge> oh yes, automatically i mean
[08:41] <ogra_> its not
[08:41] <apw> and therfore not necessarily applicable safely
[08:41] <apw> whats in it
[08:41] <Fudge> and on a live cd it prob wouldnt work
[08:41] <apw> live cd yep, we are hosed
[08:41] <ogra_> look at /var/lib/alsa/asound.state
[08:42]  * apw would normally refer this kind of thing to david
[08:42] <smb> apw, I thought it was some sort of xmlish but not sure
[08:42] <Fudge> we have keybiindings to unmute but not everyone knows them and or use keyboards with media keys
[08:42] <ogra_> yeah, livecd is different, though we had a rule in tegh past to default to 80% volume, where is that gone ?
[08:42] <Fudge> ogra_  thank you but it would be a bit difficult for someone who cant do anything without sound
[08:42] <apw> ogra_, ahh it is text, but using kernel specific naming for the elements for the controls
[08:42] <Fudge> ah that sounds like a good idea
[08:43] <Fudge> maybe the rule went away
[08:43] <ogra_> apw, well, iterate over it once to see the controls still exist, then apply it
[08:43] <apw> ogra_, heh we may well default to 80% volume, but mute is separate, its not volume
[08:43] <ogra_> if controls went missing, dont apply it
[08:43] <apw> but we are well outside a kernel engineers comfort zone already :)  we need david
[08:43] <ogra_> it shouldnt happen that controls vanish/appear randomly ... at least on released installs
[08:44] <Fudge> i thought that when a volume is set if it was to 0 previously it would be unmuted
[08:44]  * Fudge calls for David :)
[08:44] <ogra_> i guess he's on vacation or traveling to UDS already
[08:45] <Fudge> left early?
[08:45]  * ogra_ hasnt seen him the whole week
[08:45] <Fudge> social time first, then work
[08:46] <Fudge> ill hang round, do u guys have a process where this may be able to be addressed? if appropriate
[08:46] <smb> Or he may be involved in DX?
[08:47] <apw> ogra_, yeah concur, not seen him this week
[08:47] <apw> Fudge, get a bug filed 'ubuntu-bug sound' and let us know the number
[08:47] <Fudge> apw  sure ill have a shot, url?
[08:48] <apw> just run 'ubuntu-bug sound' in a terminal
[08:48] <Fudge> oh kewl
[08:49] <Fudge> um, wouldnt i need to be on a system where the sound is experiencing problems?
[08:49] <Fudge> Package sound does not exist
[08:50] <smb> audio maybe?
[08:50] <smb> But yes, it would be better run from the affected system
[08:51] <Fudge> mm, ok
[08:51] <ogra_> and use an actual package name like alsa-utils
[08:51] <ogra_> david will assign it to the right bit i guess
[08:51] <Fudge> actually, that may not help PulseAudio is running as a system-wide daemon.
[08:51] <Fudge> This mode of operation is not supported by Ubuntu.
[08:52] <Fudge> but ill try it on a ubuntu cd where pulse runs correctly
[08:52] <Fudge> thanx
[09:43] <apw> cjwatson, seems that this new kernel-wedge has some new behavior in gencontrol, specifically if none of your kernels have an architecture specific builddep it no longer emits stub correctly
[09:53] <cjwatson> apw: OK, I'll fix that; can you modify gen-control locally or do you need an upload?
[09:54] <apw> cjwatson, i can work round it as i can make our configuration trigger the right behaviour
[09:55] <apw> cjwatson, i am assuming its a bug in detecting this "allow to be run by the source pacage" support but ... what its meant to really check i have no idea
[09:57] <cjwatson> it's because the Debian kernel packages don't have control.stub
[09:58] <cjwatson> apw: try http://paste.ubuntu.com/719554/ applied to /usr/share/kernel-wedge/commands/gen-control
[09:58] <cjwatson> if you can
[09:58] <apw> cjwatson, will do
[09:59] <apw> DatabaseError: database disk image is malformed
[09:59] <apw> lovely, seems pastebin is sick
[10:00] <bjf> apw, wfm
[10:00] <apw> bjf, click the text link at the bottom
[10:01] <bjf> apw, indeed
[10:01] <bjf> borked
[10:01] <bjf> it's python, what did you expect
[10:14] <apw> cjwatson, ok this will take a bit, tangerine just face-planted
[10:18]  * apw goes make some precise chroots on his local build machine ... sigh
[10:50] <apw> cjwatson, ok that patch seems to work as expected
[10:55] <ppisati> guys, can any of you have a look at 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e? this is the fix for cve 1082 and embedded in the commit msg there's the "proof-of-concept" that shows the vulnerability. Problem: it's either missing something (or it has been slightly borked to keep script-kiddies away) or i can't make it work.
[10:59] <apw> ppisati, is this on hardy ?
[10:59] <ppisati> yep
[10:59] <apw> it is possible that hardy is immune for other reasons, like lack of features
[10:59] <ppisati> uhm
[10:59] <apw> have you tried it on a modern release with that commit reverted?
[11:00] <ppisati> sounds strange since epoll() is there
[11:00] <ppisati> uhm no
[11:00] <ppisati> ok, let me try
[11:00] <apw> my first reaction would be to confirm it works there
[11:00] <ppisati> ok, i'll try on lucid
[11:00] <apw> i am saying the implemntation of epoll() has changed, so it is entirly possible the exploit isn't valid
[11:00] <apw> and we _may_ not need to do anything on hardy
[11:01] <ppisati> uhm, actually having a "this commit has introduced this problem" could help inm this case
[11:01] <ppisati> anyway, let me see on lucid
[11:01] <apw> yeah they often know that info and don't put it in, which is annoying
[11:03] <apw> ppisati, one other thing, its possible that hardy say doesn't support adding epoll descriptors to themselves at all, i note that the exploit code does _not_ check the return codes from anything, perhaps strace it to see if any are failing
[11:03] <ppisati> did it
[11:04] <ppisati> i checked all the return code, and everything was ok
[11:04] <ppisati> from the commit msg it says
[11:04] <ppisati> "this code leads to a deadlock" so i expected the exploit to hang
[11:04] <ppisati> but it just exit
[11:05] <apw> which could lead to deadlock"
[11:05] <ppisati> ok
[11:05] <ppisati> right
[11:05] <ppisati> could be racy
[11:05] <apw> dunno, unhelpful
[11:05] <ppisati> so me might never hit that case
[11:05] <ppisati> *we
[11:05] <apw> it is cirtanly unclear from that
[11:05] <ppisati> quantum-exploit
[11:06] <ppisati> sometimes it's true, sometimes it's not
[11:06] <apw> i think the point might be more that actually the example makes an invalid loop structure
[11:06] <apw> so it should work before the patches, and fail after the patches
[11:06] <ppisati> ah
[11:06] <ppisati> good point
[11:07] <apw> while epoll should keep working for non-loop structures
[11:07] <ppisati> after thge patch the "loop struct" should fail when it's created
[11:07] <ppisati> *structure
[11:07] <apw> yes the insertion of the loop should not be possible after
[11:07] <ppisati> ok
[11:11] <apw> ogasawara, heads up that kernel-wedge is borked in precise at the moment, so hold on uploading any kernels
[11:16] <ppisati> apw: it was exactly that case
[11:16] <ppisati> apw: with the patch applied, we can't create circual structures anymore
[11:16] <ppisati> "epoll_ctl_failed: Too many levels of symbolic links"
[11:17] <apw> great
[11:57] <cjwatson> apw: that kernel-wedge is uploaded, although it'll have to wait for the LP builders to be unstuck.  Did that new kernel-wedge all told cause nic-shared-modules to come back down to reasonable size and contents?
[12:03] <apw> cjwatson, the build just got lost, power outage on my builder ... stray foot
[12:03] <apw> should know soonish
[12:03] <cjwatson> stray foot> LOL
[12:10] <apw> cjwatson, annoying appendages and no mistake
[12:14] <cking> apw, looks like tangerine is stuck, can you prod it?
[12:20] <apw> cking, she is dead, need some rtg action on the power switch
[12:24] <cking> looks like udev got all locked up
[12:24] <cking> :-(
[12:24] <cking> time for lunch then ;-)
[14:02]  * ogasawara back in 20
[15:09] <sconklin> jsalisbury: you around?
[15:20] <jsalisbury> sconklin, yes
[15:22] <sconklin> jsalisbury: help me out here - I think you helped with this . . . a few weeks ago we had a bug that only showed up on systems with hybrid graphics, when Intel and Nvidia were both installed . . .
[15:22] <sconklin> And it looks to me like that might be the case with the "purple screen at boot" bug:
[15:22] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/880476
[15:22] <ubot2> Launchpad bug 880476 in linux "after update to kernel 3.0.0-13 ubuntu 11.10 does not start" [High,Triaged]
[15:23] <jsalisbury> sconklin, I don't recall the bug a few weeks ago, but I do recall seeing some hybrid graphics bugs comming in.
[15:23]  * jsalisbury is looking
[15:24] <sconklin> wait, I remember reverting a patch for it, let me check the git logs
[15:24] <jsalisbury> sconklin, here is one: bug 881132
[15:24] <ubot2> Launchpad bug 881132 in linux "vga_switcheroo makes system freeze" [Medium,Triaged] https://launchpad.net/bugs/881132
[15:24] <jsalisbury> sconklin, intel/radeon graphics
[15:25] <sconklin> jsalisbury: That may be a duplicate of the one I was thinking of, but same cause
[15:25] <jsalisbury> sconklin, ahh
[15:26] <sconklin> ok, that's enough of a memory kicker to probably get me what I need. It was due to an upstream patch that we reverted (In Natty I think), and I'll check and see if the same patch just landed in Oneiric
[15:26] <sconklin> jsalisbury: Thanks!
[15:26] <jsalisbury> sconklin, np, thanks for looking at this :-)
[15:27] <sconklin> jsalisbury: it rang a bell, I just couldn't do the pattern matching . . .
[15:27] <jsalisbury> sconklin, :-)
[15:28] <apw> -rw-r--r-- 1 apw apw<PHONE_NUMBER>-10-26 16:24 nic-shared-modules-3.1.0-2-generic-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> -rw-r--r-- 1 apw apw<PHONE_NUMBER>-10-26 16:24 nic-shared-modules-3.1.0-2-generic-pae-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> -rw-r--r-- 1 apw apw<PHONE_NUMBER>-10-26 16:24 nic-shared-modules-3.1.0-2-virtual-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> cjwatson, ^^ that looks more like your expectations i think ?
[15:37] <apw> ogasawara, about ?
[15:37] <ogasawara> apw: yep
[15:37] <apw> ogasawara, just checking you saw my kernel-wedge warning
[15:38] <ogasawara> apw: I did
[15:38] <apw> ogasawara, that said i believe we now have a fixed kernel-wedge in the archive
[15:38] <apw> if and when cjwatson confirms he is happy with the nic-shared-modules above we probaally want to do
[15:38] <apw> another upload to fix up the installer stuff
[15:38] <ogasawara> apw: ack.  I was hoping to upload today or tomorrow
[15:39] <cjwatson> apw: the size is definitely much better
[15:39] <cjwatson> apw: can I have dpkg -c, just to check?
[15:40] <cjwatson> and yes, kernel-wedge is fixed
[15:40] <apw> cjwatson, http://paste.ubuntu.com/719766/
[15:42] <apw> ogasawara, before you do i have two build rules fixes for you, just re-re-re-testing them now
[15:42] <cjwatson> apw: looks good
[15:42] <ogasawara> apw: cool.  feel free to push them when you're confident and then ping me.
[15:42] <cjwatson> so if you want, just reassign that bug to kernel-wedge and close it
[15:43] <apw> cjwatson, yep will do the admin on it now
[15:43] <cjwatson> great, thanks for checking that out
[15:44] <apw> cjwatson, and thanks for the quick fix on the other kernel-wedge issue
[15:45] <apw> ogasawara, ok i've pushed the two commits, i am still doing a deeep test build but don't expect issue
[15:45] <apw> ogasawara, and this way you can do some test builds in parallel :)
[15:45] <ogasawara> apw: yep, I'll kick off my test builds.  will let you know if anything breaks.
[15:46] <apw> i have one set of builds under my belt, so am expecting few issues
[15:46] <apw> ogasawara, OH you do need the latest latest latest kernel-wedge in your chroots when building
[15:46] <apw> ogasawara, so make sure they are updated
[15:46] <ogasawara> apw: ack
[15:47] <apw> ogasawara, it hink gomisa updates itself
[15:47] <ogasawara> tgardner: ^^ can we get the latest kernel-wedge in our precise chroots?
[15:47] <apw> tgardner, that reminds me.  i hand edited the update script on tangerine to add precious
[15:48] <apw> tgardner, the update for the /usr3/ubuntu/ubuntu-*
[15:48] <apw> tgardner, and that likely needs to be done on goemisa too
[15:50] <tgardner> apw, are you channeling gollum? what is precious ?
[15:51] <apw> tgardner, heh ... dammit i knew that would happen.  precise is a tooooo similar in my mind and gets swapped out
[15:51] <tgardner> ogasawara, updating now
[15:59] <tgardner> ogasawara, tangernie x86en schroots are done for precise, armel is building
[15:59] <tgardner> tangerine*
[15:59] <ogasawara> tgardner: ack
[15:59] <tgardner> ogasawara, also updated tangerine to the oneiric LTS kernel.
[16:25] <GrueMaster> Not sure that word got out, but I will be unable to test armel SRU kernels until after UDS.  Please hold all requests until then.
[16:28] <apw> bjf, ^^
[16:29] <bjf> apw, saw it, don't care, the cadence marches on
[16:34] <apw> works for me
[16:35] <apw> ogasawara, those builds worked out ok here
[16:35] <ogasawara> apw: cool, mine are just finishing up
[16:35] <apw> ogasawara, a good sign indeed.  so this is a rebase to 3.1 final ?
[16:35] <ogasawara> apw: yep
[16:39] <kees> hrm, I seem to lack access to zinc. shouldn't that still be open to non-canonical contributors?
[16:41] <tgardner> kees, I think elmo shut it down to non-canonical folks after the kernel.org debacle
[16:41] <kees> tgardner: ah. urm, that will make things a bit tricky.
[16:42] <tgardner> kees, yeah, likely. what do you need ?
[16:43] <kees> tgardner: well, I was going to rebase my various patchsets to precise.
[16:43] <tgardner> kees, you mean you can't pull? Use the git:// protocol.
[16:44] <tgardner> git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
[16:44] <kees> tgardner: I can pull fine, but I can't push
[16:44] <tgardner> kees, I guess for that you'll have to send pull requests from your kernel.org repo.
[16:45]  * kees doesn't have one there yet
[16:45] <kees> and things are delayed due to kernel summit
[16:45] <tgardner> kees, huh, I figured you of all folks would have one. how about github ?
[16:46] <kees> tgardner: I do that. is the no-canonical thing final, or just a temp precaution?
[16:46] <kees> er, I can do ...
[16:46] <tgardner> kees, I'm not sure. I think we'd like to be as paranoid as kernel.org and restrict shell access.
[16:47] <tgardner> kees, you still coming to orlando ? I want you to sign my key.
[16:50] <kees> tgardner: I'm not, unfortunately. when will you be visiting pdx next? :)
[16:51] <tgardner> kees, dunno. maybe you could sign bjf and ogasawara. I'll get jjohansen to sign mine.
[16:51] <ogasawara> tgardner: kees has signed mine
[16:52] <tgardner> ogasawara, good, that gets you one removed from Linus
[16:52] <kees> and jj, iirc
[16:52] <ogasawara> yep
[16:52] <jjohansen> tgardner: you should also grab slangasek
[16:52] <tgardner> jjohansen, ack
[16:53] <jjohansen> tgardner: yep, I've got kees's, gregkh, trippet, bottomly, jamie sharp, and a few others
[16:54]  * slangasek feeds the web of trust into a protein-folding program and watches the carnage
[16:56] <tgardner> apw has a pretty good program for generating the web of trust relative to your key
[16:56] <tgardner> a picture of the web of trust, rather
[17:02] <apw> yeah :)
[17:02] <apw> ogasawara, we need to have a bit of a keysigning with you at UDS
[17:03] <apw> and if we can get slangasek as well we'll be looking good
[17:03] <slangasek> I think I already signed ogasawara's
[17:03] <apw> slangasek, that'll be good
[17:03] <ogasawara> apw: yep, I've got slangasek.
[17:03] <ogasawara> apw: maybe we can do some keysigning during one of our round tables
[17:04] <apw> ogasawara, or in the bar, i assume the bar will be a common location
[17:04] <slangasek> y'all going to participate in the organized KSP?
[17:04] <slangasek> not sure how organized it actually is... I guess there's a wiki page :P
[17:04] <tgardner> apw, what was that key signing program we used? caff ?
[17:04] <tgardner> yes, caff
[17:05] <slangasek> from the package signing-party
[17:05] <tgardner> slangasek, that works pretty slick
[17:05]  * slangasek nods
[17:07] <apw> tgardner, yep caff, works like a charm
[17:18] <tgardner> apw, I'm pretty sure util-linux is one of those packages that are an assumed build-dep.
[17:26] <apw> tgardner, i couldn't be sure so shoved it in for now
[17:27] <tgardner> apw, they way you muck about with fd 9 makes my head hurt. I had to go look it up.
[17:27] <apw> tgardner, heh who me ... never
[17:37] <kees> tgardner: is the precise tree on github? rebasing maybe become madness quickly if not
[17:38] <apw> kees, you can pull zinc trees over git: regardless no?
[17:38] <tgardner> kees, I started experimenting with mirroring on github at the release sprint, but I haven't wrapped it up yet.
[17:40] <tgardner> kees, why is this a problem? github is gonna be a readonly repo just like zinc.
[17:40] <kees> apw: yeah, I can fetch, but then I need to push -f a copy of precise to github so I can have my own branch to request pulls from
[17:40] <kees> apw: the trick is noticing when precise gets rebased
[17:40] <kees> anyway, I'll deal with it. :)
[17:46] <apw> kees, ahh, heh, normally leann sends out an email to say it has been uploaded at least
[17:47]  * kees nods
[17:58]  * tgardner -> lunch
[18:29] <apw> kees, hey do you know if you can configure the default retention time for ssh keys
[18:30] <apw> (its the sort of thing you'd know i feel)
[18:31] <kees> apw: depends on your ssh-agent
[18:31] <kees> apw: if you mean the horrible thing that is it gnome-keyring now, no.
[18:32] <kees> apw: it's a seriously PITA
[18:32] <apw> kees, that is the default i assume, then yes.  it seems to have separate defaults for gpg keys and ssh keys .. but the ssh key default is more progressive than i would like
[18:32] <kees> they gutted it while trying to move to dconf, but didn't actually add support for a default.
[18:32] <apw> bah, always backwards
[18:32] <kees> \o/
[19:17] <ogasawara> apw: just fyi, I notice "UBUNTU: [Config] di -- include empty builddep fields" results in dpkg-buildpackage failing if not in a precise chroot/environment
[19:18] <tgardner> ogasawara, thats gonna make the LTS backport unhappy
[19:18] <apw> ogasawara, hrm, then i'd say drop it for now
[19:18] <ogasawara> apw: ack
[21:20] <kees> it's like magic! :) https://github.com/kees/linux/branches
[21:20] <kees> and then on monday I'll move it all to kernel.org
[21:27] <jjohansen1> kees: hehe nice
[21:28] <kees> jjohansen1: yeah, it's not ready for a pull though. I think Will is going to consolidate his patches. But I just wanted to get everything rebased at least.
[23:07] <steph7> hi do you know if acer_wmi module can freeze ubuntu at boot if blacklisted?
[23:27] <steph7> no one? :-(


[00:00] <davmor2> meh
[00:00] <davmor2> evand1: cjwatson: wubi just locked up at scanning disks
[00:05] <davmor2> rebooted now it's working meh
[00:05] <davmor2> may have to try this again tomorrow
[00:13] <davmor2> fail
[00:13] <davmor2> I'm checking the cd incase it's a bad burn
[08:34] <xivulon> cjwatson, tested wubi and is fine here :)
[08:34] <davmor2> xivulon: sweet
[08:34] <xivulon> only minor thing, is that the grub2 menu should be hidden, as discussed a few days ago'
[08:35] <xivulon> davmor2, please test it yourself and let me know if there is any issue
[08:35] <davmor2> I think I might of had a dud burn or something
[08:36] <StevenK> xivulon: Oooh, does Wubi work now?
[08:37] <xivulon> StevenK works for me, please try it out and report any problem
[08:37] <StevenK> xivulon: I shall
[08:37] <xivulon> for this cycle it is mostly merit of cjwatson
[08:38] <davmor2> xivulon: out of interest what size partition did you give wubi?
[08:38] <xivulon> 5GB
[08:39] <davmor2> I was having issues last night at the default of 17gb
[08:39] <xivulon> what sort of issues?
[08:39] <davmor2> no grub.cfg at all
[08:40] <xivulon> hmm that should be independent of the partition size
[08:40] <davmor2> but as I say I'm hoping it was just down to a bum burn and am trying again this morning
[08:41] <xivulon> in case you have the same issue post in lp
[09:03] <davmor2> cjwatson: Wubi worked Yay \o/
[09:03] <davmor2> must of just been a bad burn
[09:20] <xivulon> davmor2 cool
[10:01] <cjwatson> davmor2: there definitely seems to be some instability
[10:02] <cjwatson> it works, but only sometimes, AFAICS
[10:02] <cjwatson> I have a hard time putting your previous problem down to a bad burn; if that were the case I'd expect some log messages
[10:05] <davmor2> cjwatson: I'm just trying a 64 bit one now I'll let you know
[10:07] <davmor2> cjwatson: the only flaw I had in the 32bit one was with the gdm respawn at the end
[10:07] <cjwatson> right
[10:29] <davmor2> dj64bit just locked up on scanning disks
[10:29] <davmor2> cjwatson: ^
[10:30] <davmor2> don't where the dj came from
[10:31] <evand> davmor2: by locked up do you mean you cannot use the mouse and keyboard?
[10:32] <davmor2> evand: mouse moves, no c-a-fx though
[10:32] <cjwatson> C-A-Fx is broken on Wubi installation, I don't know why
[10:32] <cjwatson> and this is the same kind of instability I was referring to
[10:32] <cjwatson> reboot and try again :-/
[10:38] <davmor2> cjwatson: reboot it's now gone sailing past that point no issues so far
[10:38] <evand> lovely
[10:48] <davmor2> cjwatson: that time it's worked fine Meh
[10:55] <evand> superm1: cody-somerville: would you be so kind as to add resierfsprogs to your respective live seeds.  Thanks!
[11:21] <davmor2> evand, cjwatson: would you like me to post a bug that wubi is a little erratic and you may need to reboot?
[11:24] <cjwatson> sure, though I don't think I'll be able to do anything much about it myself :(
[11:26] <davmor2> cjwatson: no but at least it can be release noted :)
[11:29] <cody-somerville> evand: done
[11:45] <davmor2> cjwatson: bug 439279
[12:37] <davmor2> cjwatson: on kubuntu wubi install I get:
[12:38] <davmor2> Try (hd0,0): NTFS5: No wubildr
[12:38] <davmor2> same for hd (0,1)
[12:39] <davmor2> and then Try (hd0,2): NTFS5: _  with the _ being the cursor then nothing
[12:43] <cjwatson> would be interesting to know if it reproduces
[12:45] <davmor2> I'll re-run it now
[12:47] <evand> I'll give wubi a testing as soon as I get to the bottom of this usplash not showing the eject CD message issue I'm seeing.
[12:51] <davmor2> cjwatson: reboot give exactly the same result
[12:51] <davmor2> 3 reboots
[12:51] <davmor2> trying a reinstall
[12:54] <cjwatson> yeah, I meant reinstall I'm afraid
[12:54] <cjwatson> I'll give it a try myself later - this sounds more like instability than something intrinsically Kubuntu-related though
[13:08] <davmor2> cjwatson: this time it's been dropped into sh:grub>
[13:57] <ara> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/439306
[13:58] <ara> evand, ^
[13:58] <cjwatson> evand: ^-
[13:58] <cjwatson> snap
[13:58] <ara> :)
[13:58] <evand> long known problem
[13:58] <evand> migrationassistant will get replaced at some point
[13:58] <evand> but right now it doesn't understand sqlite
[14:01] <cjwatson> maybe there's a test case somewhere that we can annotate to say this
[14:04] <davmor2> cjwatson: I'm going to try a 64kub wubi install
[14:05] <cjwatson> I don't know if completing the matrix there is going to add much information, TBH
[14:05] <davmor2> if this one fails dismally too do you want me to bother loop mounting the drive to get the logs off it?
[14:05] <cjwatson> it seems somewhat unstable and nondeterministic in all combinations
[14:05] <cjwatson> it's not that any one thing always fails dismally, or always succeeds
[14:06] <cjwatson> it's that all of them are somewhat random
[14:06] <cjwatson> sure, logs won't hurt
[14:06] <davmor2> okay cool :)
[14:06] <cjwatson> from what I can gather I don't think we should label failures as specific to any particular build though
[14:06] <davmor2> just wubi
[15:01] <davmor2> cjwatson: http://www.davmor2.co.uk/wubi/syslog1
[15:03] <cjwatson> could this go on a bug or something please, I can't really look just now
[15:04] <davmor2> cjwatson: yeah do you want a new bug or will my generic wubi is a bit screwed bug do?
[15:04] <cjwatson> though again, doesn't show any *evidence* of breakage that I can see
[15:04] <cjwatson> the same one should be ok
[15:04] <cjwatson> would like /boot/grub/grub.cfg too if it exists
[15:04] <cjwatson> or a note if it doesn't
[15:04] <davmor2> no probs
[15:14] <davmor2> cjwatson: that's interesting the last kubuntu failure has a grub.cfg that looks correct
[15:14] <cjwatson> how does it fail this time?
[15:15] <davmor2> sh:grub>
[15:17] <cjwatson> search -s -f -n /ubuntu/disks/root.disk
[15:18] <ara> dpm, I don't know if this should be a bug in firefox or casper/ubiquity: bug 439392
[15:18] <evand> cjwatson: if you happen to do any testing with KVM later, can you confirm bug 439385 ?
[15:19] <CIA-33> ubiquity: cjwatson * r3493 ubiquity/ (debian/changelog scripts/install.py): Use a separate PROGRESS REGION for each install plugin (LP: #438979).
[15:19] <cjwatson> ara: is the Spanish firefox localisation package installed?
[15:20] <cjwatson> ara: oh, this is probably the open bug about language-support packages not being installed at all following their reorganisation
[15:20] <dpm> ara: thanks for the heads up, I think it is a problem with the es_ES locale, let me see if I can dig the bug out...
[15:20] <cjwatson> I was going to fix that for beta but didn't have time
[15:20] <cjwatson> evand: ok
[15:21] <cjwatson> ara,dpm: I'm thinking of bug 434173
[15:21] <ara> cjwatson, it is happening in the live environment as well
[15:21] <cjwatson> ara: live environments are expected not to have complete localisation; there is not enough space
[15:21] <ara> cjwatson, ok
[15:22] <cjwatson> oh yes, that's why I didn't fix bug 434173 - I can't because language-selector hasn't been uploaded yet
 dpm: the country code is only an issue if the exported .po files have that
 like es-ES -> broken
[15:22] <dpm>  fi -> works
[15:22] <dpm> I think it is a particular bug in FF
[15:22] <cjwatson> dpm: so possibly two overlapping issues here
[15:22] <dpm> yep
[15:22] <cjwatson> (a) localisation package not installed (b) it wouldn't work if it were
[15:23] <cjwatson> I'll make 434173 release-critical for the final release
[15:39] <evand> I've run into the scanning disks wubi bug :-/
[15:46] <superm1> evand, what's wrong with making it a recommends for ubiquity (reiserfsprogs)? wouldn't that fix the problem without requiring all seeds to explicitly declare it?
[15:47] <evand> superm1: I don't see any problem with that.  I was just following the existing convention.
[15:48] <superm1> evand, okay so i guess next logical question is why was that existing convention defined that way?
[15:48] <evand> cjwatson: ^ ?
[15:50] <CarlFK> are there any size constraints for the netboot initrd?    what is at: http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/netboot/ubuntu-installer/i386/initrd.gz
[15:51] <CarlFK> I am getting "E100_request_firmware failed to load firmware "e100/d101m_ucode.bin file not found."  if that is expected because there isn't room, ... grumble... else I'll file a bug
[15:52] <evand> cjwatson: so I found a bit of a workaround for the not having getty and wubi failing issue.  Wait for the slideshow to appear, click on a link.  When Firefox opens, type irc: in the address bar, then select a custom handler of /usr/bin/xterm ;)
[16:01] <cjwatson> evand: reiser> don't have strong feelings either way
[16:01] <cjwatson> evand: haha
[16:01] <evand> Is there a bug open for the ubiquity lock ups when running under wubi bug?
[16:01] <evand> I can't seem to find it under ubiquity, partman-auto-loop, or wubi
[16:01] <cjwatson> CarlFK: I *think* that's the responsibility of the kernel to ship the right bits in the firmware udebs
[16:02] <cjwatson> evand: I thought davmor2 filed one on wubi - bug 439279?
[16:02] <evand> ah weird. Somehow I missed that.  Thanks
[16:03] <CarlFK> cjwatson: isn't the installer kernel the same as the kernel that gets installed? (so should have all the same support... so something broke)
[16:03] <cjwatson> CarlFK: the kernel image (vmlinuz) itself is, but the module selection is stripped down
[16:03] <cjwatson> (and always has been)
[16:06] <CarlFK> cjwatson: ok - as long as its intentional and not an opps.  but I am guessing good nic support is something the netboot kernel should have - Ill bug all this and let someone make a decision
[16:06] <cjwatson> stick the bug on linux, it's probably just a matter of adding that file to nic-firmware
[16:07] <mikefletcher_> Hi.  In Jaunty I used to be able to add 'text' to the boot options on the live cd and I would end up in a logged in shell.  I opened bug 434769 to cover this regression.  It has been fixed but I retested on the latest nightly and it doesn't work.  My Question: What package should this bug be under?
[16:10] <cjwatson> mikefletcher_: that's bug 438678
[16:10] <cjwatson> mikefletcher_: sorry about the fix being incomplete - the more complete fix will land right after beta, we didn't have time to squeeze it into beta builds
[16:11] <mikefletcher_> cjwatson: ok thanks! I'll watch 438678 and test after its fixed.
[16:12] <mikefletcher_> cjwatson: X crashes my pc when the livecd boots.  Is there any other way to get a logged in text console on a livecd?
[16:15] <cjwatson> only ones very early in weird environments
[16:15] <cjwatson> well
[16:16] <cjwatson> you could boot with 'break=casper-bottom' as a kernel argument, then run:
[16:17] <cjwatson> sed -i 's/basename \$f/& .conf/g' /scripts/casper-bottom/25configure_init
[16:17] <cjwatson> exit 0
[16:17] <cjwatson> that ought to fix it
[16:17] <cjwatson> but you'd have to do that every boot, it's not a great workaround
[16:18] <mikefletcher_> cjwatson: ok, I will try that.  I just need to setup something to grab x logs after it dies.  Thank you very much.
[17:05] <davmor2> evand: that's the all new generic wubi's bost bug
[17:36] <cjwatson> you know, I wonder if http://paste.ubuntu.com/282302/ is the source of some of this wubi trouble too
[17:36] <cjwatson> nothing handles the loop variable, so --set=loop is pretty odd
[17:37] <cjwatson> hmm, that said it shouldn't matter
[17:37] <cjwatson> nah, never mind, that's a red herring, reverting
[17:37] <cjwatson> evand: would appreciate a new wubi build from updated trunk after beta
[17:39] <evand> sure thing
[17:44] <davmor2> evand, cjwatson: what package is most likely to be causing the gdm/kdm respawn issue on ubiquity only installs, like wubi and install from menu?
[17:45] <cjwatson> davmor2: I don't know yet, but I'm on it
[17:45] <davmor2> bug 439405
[17:46] <cjwatson> or I would be if I could reproduce it at the moment
[17:46] <cjwatson> just assign it to me?
[17:46] <cjwatson> I think we can put it on ubiquity for the moment, but it may not be that
[18:31] <CIA-33> ubiquity: cjwatson * r3494 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[18:31] <CIA-33> ubiquity: * GTK frontend:
[18:31] <CIA-33> ubiquity:  - When switching language, translate other top-level widgets (dialogs)
[18:31] <CIA-33> ubiquity:  and their children, as well as the main notebook pages.
[18:32] <lamalex> evand: My comany is being really weird about signing over the IP to that patch, I can't get them to comprehend that it's beneficial for everyone if we don't have to carry it
[18:32] <lamalex> "BUT IT'S OUR IP. WE CAN'T GIVE IT TO ANOTHER COMPANY"
[18:32] <evand> no worries
[18:32] <evand> I understand
[18:32] <lamalex> still working on it, will let you know if anything changes
[18:32] <evand> okay
[18:33] <evand> thanks for the update
[18:34] <lamalex> np
[22:38] <CIA-33> ubiquity: evand * r3495 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[22:38] <CIA-33> ubiquity: Port fix for return_to_partitioning from the GTK+ frontend to the
[22:38] <CIA-33> ubiquity: KDE frontend (LP: #439184).
[22:42] <CIA-33> ubiquity: evand * r3496 ubiquity/debian/ (changelog control):
[22:42] <CIA-33> ubiquity: Explicitly depend on reiserfsprogs so that we don't have to add it
[22:42] <CIA-33> ubiquity: to every live seed (LP: #431976).


[03:29] <grantbow> anyone interested in https://wiki.ubuntu.com/CaliforniaTeam/Projects/Representative-Letters ? we can talk about it any day this week at 7:30 PM
[03:29] <darthrobot> Title: [CaliforniaTeam/Projects/Representative-Letters - Ubuntu Wiki]
[17:51] <Torikun> https://www.box.com/signup/o/dell_50gb_give_get  Special offer from hacker news on box.com!
[17:51] <darthrobot> Title: [Box | Simple Online Collaboration: Online File Storage, FTP Replacement, Team Workspaces]


[03:02] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: tumbler 4.17.0 released @ http://www.mail-archive.com/xfce-announce@xfce.org/msg00644.html