[05:09] <radical> hi
[05:10] <radical> ...
[09:14] <MortezaE> Hey iraj
[10:51] <iraj> MortezaE, salam vro
[10:51] <iraj> MortezaE, bro*
[10:51] <iraj> MortezaE, che khabar?
[10:58] <MortezaE> iraj, fadat dada... 9karam
[11:27] <MortezaE> iraj, khoobi bro?
[11:47] <iraj> MortezaE, shokr. bd nistam
[11:47] <iraj> bad*
[11:47] <iraj> MortezaE, to chetory?
[11:49] <MortezaE> khob malome mage mishe bad bood!
[11:50] <iraj> heheh
[11:50] <MortezaE> everything is OK in stability isle
[11:50] <iraj> :))
[11:50] <MortezaE> inja khalvate hamishe?
[11:51] <iraj> MortezaE, fekr nakonam khalvat besheh
 Hi. When I want to see in which category did I bookmarked current page, It quickly goes under "Other Bookmarks" !
 It's so in several recent versions of Firefox
[11:52] <MortezaE> iraj, to #firefox ye mosalmoon nist engar. to nemiduni?
[11:53] <iraj> MortezaE, yekami sabr on  bebin
[11:54] <MortezaE> 2 sa'at bas nis?
[11:54] <iraj> MortezaE, heheh. baleh kafie
[11:54] <iraj> MortezaE, shayad soalet irad dare
[11:55] <MortezaE> oon k are :D
[11:56] <iraj> MortezaE, hanuz C++ kode mizani?
[11:57] <MortezaE> iraj, node
[11:57] <MortezaE> tazegi crypto trade mikonam
[11:58] <iraj> MortezaE, wow
[11:58] <iraj> MortezaE, bitcoin?
[11:58] <MortezaE> no wow.. cap is so low
[11:58] <MortezaE> are
[11:59] <MortezaE> poole bikar dari beriz toosh
[11:59] <MortezaE> beriz toosh LOL
[11:59] <iraj> :D
[12:00] <MortezaE> age be 5000 resid hatman begir chon risk nazdik sefre
[12:00] <iraj> MortezaE, man felan bikaram :D
[12:00] <MortezaE> poolat mohemme khodeto kar nadaram
[12:01] <iraj> MortezaE, tuye Iran kesi estefade mikone?
[12:02] <MortezaE> ask smart questions:
[12:02] <MortezaE> tu iran mishe trade kard? noon dare?
[12:02] <iraj> heheh na
[12:02] <MortezaE> are kheili ham dare age tahlil balad bashi
[12:03] <MortezaE> ba iran chekar dari.. ba exchange haye khareji kar mikoni
[12:03] <iraj> MortezaE, hmm


[01:02] <itnet7> mhall119: I found a bunch of the Planet Linux Caffe events that were never really added to the LoCo Dir. What do you recommend doing with the details? They are from Planet Linux Caffe's calendar
[01:04] <itnet7> I think I have a bunch of pictures from some of the events up on facebook, but I don't have a list of everyone that was in attendance, though most events there usually had about 15-20 attendees (not necessarily from the Florida Team itself)
[01:22] <mhall119> itnet7_away: if govatent or others from the team were there we should add them
[01:23] <itnet7_away> I was also there
[01:23] <itnet7> for all of them but maybe one
[01:23] <mhall119> oh, if you were there they yeah, go ahead and add them
[01:23] <itnet7> That's why I have pictures
[01:23] <mhall119> I already put us on the LC's calendar for next week's meeting
[01:24] <itnet7> Yeah, I knew you were going to add that, I was just trying to help spruce up the wiki, while I'm listening to my audio schoolbook
[01:24] <itnet7> I should probably read along so I can retain some of it :-)
[01:24] <itnet7> but.....
[01:25] <itnet7> Man, I miss Planet Linux Caffe, we really did have some good times there :-(
[01:32] <mhall119> I wish I could have made it to one
[15:31] <Bryanstein> mhall119, quick question then I'm out the door...if I'm a member of the mailing list, then why are my posts still being moderated
[17:55] <mhall119> Bryanstein: are you sending them from the address you registered with?
[17:56] <mhall119> Bryanstein: I have that problem because my @ubuntu.com address is an alias for my @gmail.com, and if I signup with one and send with the other it gets stuck


[08:27] <pragomer> I can pin every running programm to the budgie panel (not plank, I mean the panel!) except virtualbox. any tipps?
[09:49] <notze> HI guys! i like budgie very much. But the  window manager is not working so good. if i press Linux Key + ARROWBOTTOM THE WINDOWS are not positioned propperly. This is IMHO veryimportant for daily use. Can you tell me where i can read further how to fix this issue?
[11:34] <notze> has anyone an idea
[11:34] <notze> ?
[13:44] <notze> Hello
[13:45] <notze> Has anyone an idea for my pborblem
[13:45] <notze> HI guys! i like budgie very much. But the  window manager is not working so good. if i press Linux Key + ARROWBOTTOM THE WINDOWS are not positioned propperly. This is IMHO veryimportant for daily use. Can you tell me where i can read further how to fix this issue?
[18:39] <fossfreedom> notze, not sure what you are referring to - what are you expecting to happen?


[04:44] <bzoltan_> jibel: I have a super high priority landing in the silo31. That is fixing a critical OTA7 bug we have just captured https://bugs.launchpad.net/canonical-devices-system-image/+bug/1502093 This bug forced us to revert the previous UITK landing. So this landing has other 3 OTA7 bugfixes. I would like to ask you to push this silo to QA validation as first on Monday.
[04:44] <ubot5`> Ubuntu bug 1502093 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape crash with latest UITK on mako/flo" [Critical,Confirmed]


[07:26] <micahg> any LOSAs around?
[07:26] <spm> micahg: yup; whats up?
[07:26] <micahg> I think a couple builders are stuck
[07:27] <micahg> https://edge.launchpad.net/builders/lansones
[07:27] <micahg> https://edge.launchpad.net/builders/radon
[07:28] <spm> I'm guessing  23 minutes for a build of those packages is considered long?
[07:28] <micahg> just got a failure for one
[07:29] <micahg> it did seem long though
[07:29] <wgrant> I wonder if buildd-manager was asleep for a while.
[07:29] <micahg> and the other just finished
[07:29] <micahg> maybe that was it
[07:29] <wgrant> Nothing had been dispatched in > 20 minutes.
[07:32] <spm> I've been getting bunches of alerts all week from the buildd side - very transient tho. it looks like "something" is running MUCH slower vs actually breaking tho.
[07:33] <wgrant> The logging should be much less unclear now.
[07:33] <wgrant> eg. it will actually tell you what it's doing for most operations.
[07:34] <StevenK> spm: Looks like you forgot to feed the hamsters again
[07:34] <spm> StevenK: we stopped feeding them ages back; they'd just poop on the servers more; so we've setup some spare server fans we had lying around and attached tiny whips to 'em.
[07:35] <spm> alongh the principle of "the beatings will continue until morale improves"
[07:35] <spm> it seems to work more effectively
[07:35] <StevenK> spm: Just wait, the hamsters will rise up and form a union, and then you'll be doomed!
[07:37] <spm> they wish. that's when we start substituting the hamsters on the pentagrams where previously we were using the Black Cockrel's in our secret damned sysadmin secret biznis.
[07:38] <noodles775> Are these hamsters related to bug 557391?
[07:38] <wgrant> Ah, that could be it.
[07:38] <spm> noodles775: we have SO got to have another word about your use of facts in serious discussions.... ;-)
[07:39] <noodles775> ;)
[07:39] <wgrant> I don't see how a lock file could block buildd-manager, though -- does it really take out and release a lock every cycle?
[07:39]  * wgrant looks.
[07:39] <noodles775> I couldn't even see a shared lockfile (it uses the name of the script)... I didn't get a chance to look deeper.
[07:40] <noodles775> StevenK: did you get a chance to look at that bug?
[07:40] <mwhudson> could it block inside postgres </wild spectulation>
[07:40] <mwhudson> ?
[07:40] <wgrant> mwhudson: I considered that... possibly.
[07:41] <noodles775> Yeah, a transaction lock was ...
[07:41] <wgrant> I forget how queuebuilder handles transactions.
[07:41] <spm> wouldn't be the first time we've had funky locks in the DB....
[07:41] <wgrant> Even though I've touched it a lot in the past couple of weeks.
[07:41] <spm> wgrant: so... it's your fault????
[07:41] <wgrant> spm: Well, the first bits of the refactoring landed a couple of hours ago, so hopefully not!
[07:42] <spm> heh. and I was just getting the sacrificial knives out and specially blunted. darn it.
[07:43] <mwhudson> what'
[07:43] <mwhudson> s that think from the discworld?  an unhangover or something
[07:43] <mwhudson> oh, hangunder
[07:43] <wgrant> Oh, no, I did touch the relevant method in 10.03. But the transaction lifetimes should be identical.
[07:44] <spm> mwhudson: ha; no. for a change; I did originally type sharpening; but figured that blunt ones would hurt more so... >:)
[07:44] <mwhudson> spm: i meant that wgrant's changes might me so incredible they're affecting things before they're deployed
[07:45] <wgrant> How is queuebuilder being invoked?
[07:50] <spm> mwhudson: that really wouldn't surprise me....
[07:50] <spm> wgrant: cron. every 20 mins.
[07:50] <spm> oh wait. that's the rescore.
[07:51] <wgrant> Do we know which one is being contentious?
[07:51] <wgrant> The --score-only, or the not --score-only?
[07:51] <spm> --score-only
[07:52] <spm> noodles775: there's a question. how IS the queuebuilder invoked? via cesium/buildd manager?
[07:53] <wgrant> b-m doesn't know about it at all.
[07:53] <wgrant> It needn't even be on cesium, but it probably is.
[07:53] <noodles775> spm: I was just hunting through the crontabs on dogfood to try to find it.
[07:55] <spm> :-)
[08:04] <noodles775> spm: I can't see it anywhere in the crontabs I have access to (and I don't have access to /var/spool/cron/crontabs)
[08:05] <spm> noodles775: we DID used to run a queuebuilder on cesium every hour. but that was disabled for an 'indefinite' period in late 2008. so....
[08:05] <noodles775> spm: so how is it being determined that it's causing the lock? Can you see the process?
[08:06] <noodles775> Or maybe lamont was just guessing? I'll ask him later if he can fill in the bug with further details if he's got them.
[08:06] <spm> noodles775: it seems to be a combo of things.
[08:06] <spm> 2010-04-08 07:46:00+0100 [-] startBuild(http://americium.ppa:8221/, transmission, 1.92+r10460-0ubuntu0~lucid, Release)
[08:06] <spm> 2010-04-08 08:04:25+0100 [-] americium (http://americium.ppa:8221/):
[08:07] <wgrant> Oh.
[08:07] <spm> by way of example. is a rather long gap - that's triggering an alert
[08:07] <wgrant> That's probably just a builder being stupid.
[08:07] <wgrant> Although the timeouts should catch most things, if a PPA builder reset trigger hangs then buildd-manager will.
[08:08] <wgrant> And that looks suspiciously like that.
[08:09] <spm> possibly - all I know is I'm getting a lot of those this week :-(
[08:13] <mwhudson> wgrant: are you working on making buildd-manager less bonkers?
[08:13] <wgrant> mwhudson: I've removed most of it.
[08:13] <mdke> anyone around who is an "LOSA"?
[08:13] <mwhudson> wgrant: impressive
[08:13] <spm> mdke: what's up?
[08:13] <wgrant> But this particular issue is more related to the rapid partial asynchronisation of it a couple of years ago, which left us with lovely creatures like RecordingSlave.
[08:14] <mwhudson> wgrant: that was the bonkersness i was thinking of
[08:14] <mdke> spm: I wonder if you could take a look at this question for me. I'm sorry to push for it, I'm sure you have plenty in the queue, but it's preventing me from uploading a branch - https://answers.edge.launchpad.net/launchpad-code/+question/106509
[08:14] <noodles775> wgrant: so the recording slave is receiving the msg to start a build, but then hangs? (why were the recording slaves introduced? wasn't it because the scan cycle was taking too long?)
[08:15] <noodles775> wgrant: also, can you update the above bug with anything you find? Thanks!
[08:16] <spm> mdke: done
[08:16] <wgrant> noodles775: The RecordingSlave lets all the synchronous model code be asynchronous. It takes XML-RPC calls and returns a fake response, and buildd-manager later replays the calls asynchronously.
[08:16] <mdke> spm: fabulous, thanks a bunch
[08:17] <wgrant> So while it prints startBuild there, the slave call may actually happen much later.
[08:18]  * noodles775 tries to see why that would mean that the buildd-manager doesn't log anything after the startBuild (like "resetting builder...")
[08:19] <wgrant> noodles775: That's true.
[08:19] <wgrant> I haven't had a good look just yet.
[08:19]  * wgrant gets a 10.03-like branch.
[08:19] <spm> mdke: np
[08:20] <wgrant> spm: So those two americium lines are immediately adjacent?
[08:20] <spm> wgrant: yup. straight from the raw log
[08:21] <spm> we have an alert for the log not benig updated in 5-10 minutes; hence why I've had a few of these.
[08:23] <wgrant> spm: if there are no private builds involved, can you pastebin a few of the subsequent log lines?
[08:25] <spm> wgrant: um. no. for exactly that reason. :-/
[08:25] <wgrant> Bah.
[08:27] <spm> typically - all the others I can easily find are also private. wonder if cuase/effect or just sheer coincidence.
[08:28] <mdke> spm: mwhudson: not sure if you're available to help, but after spm has done his thing, the import is failing (https://code.edge.launchpad.net/~vcs-imports/gnome-user-docs/master)
[08:28] <wgrant> The builder varies?
[08:28] <spm> wgrant: I'm guessing you're after the text between the '***** RESULT ***** ;;;;******************' bits
[08:28] <mwhudson> mdke: :(
[08:28] <wgrant> spm: I don't care about that at all.
[08:28] <spm> yeah. looking at one for nannyberry atm
[08:28] <mdke> mwhudson: yeah
[08:29] <mwhudson> jelmer: ^^ can you look at mdke's failure?
[08:30] <wgrant> spm: So the hang is between the startBuild() and the ************MOREASTERISKS****** RESULT *****EVENMORE******?
[08:30] <mwhudson> mdke: i guess the conversion could be done with bzr-git by hand
[08:31] <spm> wgrant: like this: http://paste.ubuntu.com/410900/
[08:31] <mdke> mwhudson: I don't know
[08:32] <wgrant> spm: Thanks.
[08:32] <mwhudson> mdke: if i unhook the branch from being the dev focus, at least you'll be able to push your branch
[08:32] <wgrant> So the problem isn't in the asynchronous part. This is good.
[08:33] <mwhudson> mdke: or you could do that i guess
[08:33] <mdke> mwhudson: that's correct I think, the problem is the repository format between Launchpad and my local repo is not compatible
[08:34] <mdke> mwhudson: yes, I'll do that now
[08:35]  * mwhudson really needs to get away from the computer
[08:36] <mdke> mwhudson: ok, thanks for your help. Have a nice evening
[08:42] <wgrant> All I can think of is that BQ.markAsBuilding might be conflicting with queuebuilder's scoreCandidates. While I moved that method in 10.03, the transaction use there hasn't changed.
[08:42] <wgrant> The other few dozen lines between the log messages look perfectly safe.
[09:46] <jelmer> mwhudson, mdke: looking
[09:55] <rdb> is there any documentation available on cscvs?
[09:55] <wgrant> From what I've seen, 'run away'.
[09:57] <jelmer> mwhudson, mdke: no idea, works here locally :-(
[10:19] <BUGabundo> morning
[10:19] <BUGabundo> should click images attached to LP open a new tab?
[10:19] <BUGabundo> or use the same?
[10:23] <BUGabundo> using chromium daily, fyi
[10:30] <rdb> wgrant, 'run away'? :-? It looks quite complicated
[10:44] <bialix> interesting is it possible to bookmark a projects on LP? there is related projects to some user. what if I just want to track the progress of some project, but I'm not part of it?
[10:45] <bialix> something to quick access projects on LP from LP user home page
[11:00] <sebi`> when writing an announcement, is there a way to use text-markup?
[11:20] <czajkowski> aloha :)
[11:21] <czajkowski> just wondering is it possible to create a bug and mark it just for one council to be able to view - I want to create Ubuntu Loco council bugs to track issues? and only the people on this team to access the bug ?
[11:28] <bialix> czajkowski: there is security issue checkbox
[11:29] <BUGabundo> deryck: should click images attached to LP open a new tab? or use the same?
[11:30] <deryck> czajkowski, yeah, what bialix said.  That's the only way to file a private bug and once the bug is reported, you can uncheck security but leave private enabled.
[11:30] <deryck> BUGabundo, click images?  What do you mean?
[11:30] <BUGabundo> deryck: an attached screenshot for example
[11:30] <deryck> BUGabundo, ah.  Should open in the same window.  We don't do anything to make them open new.
[11:31] <BUGabundo> :\\
[11:31] <idnar> I think you can have a project set to create private bugs by default
[11:31] <BUGabundo> I'll open a wishbug
[11:31] <idnar> I'm not sure if that's done for projects that don't pay for a commercial license, though
[11:31] <BUGabundo> don't like to lose previous page
[11:31] <idnar> BUGabundo: can't you control-click or middle-click them?
[11:31] <BUGabundo> yep
[11:32] <idnar> that seems like a better solution than forcing a new window / tab on everyone
[11:32] <BUGabundo> but the behaviour I expect for clicking attached files is new tab with focus
[11:32] <deryck> idnar, private by default is only for commercial projects
[11:32] <czajkowski> bialix: deryck cheers
[11:32] <BUGabundo> other then see it replace the bug page
[11:33] <czajkowski> just when I create community bugs, there seems to be half a dozen folks already assigned to bugs and I want to avoid that
[11:33] <deryck> BUGabundo, yeah, feel free to file a wishlist bug, but I don't think we would ever do that by default.
[11:33] <BUGabundo> shame :\
[11:33] <deryck> Sorry, but I think more users would be upset by that than those that would like that. :-)
[11:40] <BUGabundo> really?
[11:41] <deryck> BUGabundo, that's my assumption based on the fact that users *generally* don't want new windows and controlling whether it's a new window or new tab is a browser setting.
[11:41] <czajkowski> deryck: is there any reason why some folks are automatically assinged to community bugs? that aren't council members??
[11:42] <deryck> czajkowski, if someone has subscribed to all bugs for your project they will automatically be subscribed to new bugs.
[11:42] <deryck> BUGabundo, but really, there's no way to know for sure without asking users somehow.
[11:43] <czajkowski> deryck: oh how does one do that say for community bugs?
[11:47] <deryck> czajkowski, go to the bugs section for a project, look down the right side of the page where the X open bugs links are.  Just below that there is a "Subscribe to bug mail" link.
[11:49] <czajkowski> deryck: cheers
[11:51] <czajkowski> deryck: cheers, that answer my question then, if I want to create LoCo council bugs and have only the 6 of us get them that's not possible
[11:52] <deryck> czajkowski, not by default, that's right.  Launchpad assumes use is for open projects if you don't have a commercial subscription.
[11:53] <czajkowski> deryck: what I'm trying to do is log issues that are mailed to the 6 of us to keep track of and some are delicate
[12:01] <deryck> czajkowski, I understand.  Unfortunately, I don't think there's a way to support this with launchpad currently.  You can mark security as mentioned above when filing the bug, but that's it really.
[12:17] <czajkowski> deryck: ok thanks
[13:21] <mdz> should Launchpad be emailing my own comments back to me when I reply to a merge proposal? it doesn't seem helpful
[13:27] <deryck> hi mdz.  Yeah, it normally does that.  and yeah, it's not really helpful.
[13:28] <mdz> deryck, should I just add a filtering rule to discard the messages, like I do for bugs, or is this likely to change?
[13:28] <lifeless> it also emails you when you edit a bug/merge proposal in the web ui
[13:28] <lifeless> also not useful :)
[13:29] <deryck> so this will change from bugs very soon... mdz, not sure about the MPs.  Looking at bugs now...
[13:29] <mdz> deryck, oh, that's good news
[13:30] <deryck> mdz, lifeless -- we have a focus on better bug notifications coming next for us.  See:  https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications
[13:30] <deryck> jml, do you know if the email noise from yourself for MPs is likely to change?
[13:31] <jml> deryck: what noise?
[13:31] <jml> (I guess not)
[13:31] <deryck> jml, when you reply to an MP, you get a mail back for your own comment.  see mdz's comment above.  ^^
[13:32] <jml> oh right.
[13:32] <jml> deryck: we ought to change it, I don't know of any plans to do so currently
[13:33] <deryck> mdz, so mail filter looks the best route then for MPs.
[13:33] <jml> deryck: further, it's crappy that we have things set up in such a way so that it's easy for you to fix this problem for bugs but not for merge proposals
[13:34] <deryck> jml, *agreed*
[13:34] <deryck> this is some of the worst pain of launchpad dev to me.
[13:35] <jml> deryck: I'll ask thumper about it when I speak with him later today
[13:36] <deryck> cool
[13:37] <jml> as for the more general problem of the respective notification systems being divergent, no concrete next actions spring to mind
[13:38] <deryck> jml, I wonder if as part of the better-notifications work we shouldn't spend some time unifying notifications across LP?  users don't see the distinction, I'm sure.
[13:38] <deryck> that's huge, I know.
[13:39] <jml> deryck: it's tempting.
[13:39] <jml> deryck: want to think about it some more and then we can talk about it in our call tomorrow?
[13:39]  * jml actually needs to think it through
[13:40] <deryck> jml, definitely we can talk about it then.  I think it takes it from a 1-2 month story currently to a 3-5 month story, though.  depending on how many engineers are on it.
[13:40] <deryck> maybe I'm a pessimist about how quickly things can be done in lp though :-)
[13:41] <deryck> jml, did you see my cycle time email I sent?
[13:42]  * jml looks
[13:43] <deryck> it's very long, sorry.  week old now.
[13:43] <jml> deryck: yeah, it's tagged with @READ :)
[13:44] <jml> deryck: so I will read it...
[13:44] <deryck> jml, yeah, understood. :-)  Basically, we do dev and review in 3-4 then spend average of 8 days beyond that in queuing and landing.
[13:44] <deryck> for a 12 day cycle time on a bug or task.
[13:44] <deryck> toooooooo long.
[13:45] <jml> deryck: yeah. In some projects, queueing and landing is a sub-minute operation :)
[13:45] <deryck> jml, exactly!
[13:51] <hyperair> does anyone know what happened to the BGO bug status trackers?
[14:13] <deryck> hyperair, hi.  Sorry but I don't know what you mean by BGO.  Is that a project on LP?
[14:15] <persia> deryck: Just from backscroll: one nice feature about LP sending you your own notes from bugs is that the local mailspool contains a complete record of the bug.  This may be less useful for merge proposals or similar.
[14:16] <deryck> persia, interesting.  Assuming you replied on LP itself, right?  If you reply via mail, that should already be there, correct?
[14:16] <persia> Depends on your client configuration: it may not be in the same threading view.
[14:17] <persia> (some clients auto-merge send and receipt, some don't)
[14:17] <persia> Mind you, the answer might be "go use a different mail client", or "set up your filters to do something useful" :)
[14:22] <jml> deryck: BGO often means "bugzilla.gnome.org"
[14:23] <deryck> ah
[14:23] <deryck> persia, that's a nice perspective though, thanks.
[14:24] <deryck> hyperair, are you asking about updates to bugs linked to the gnome bugzilla?  if so, it's being worked on.  Very close but still not there yet.
[14:29] <hyperair> deryck: ah cool. thanks for the information.
[15:18] <mok0> w
[16:50] <qense> I've got a problem with the sprints section of Launchpad. At <https://edge.launchpad.net/sprints/uds-m> I -- Sense Hofstede -- am listed as attending, but I can still press the 'Register Yourself' button and http://summit.ubuntu.com/uds-m still thinks I'm not attending. I've marked myself as attending yesterday evening, so it can't be that I just have to wait another few minutes and refresh.
[16:55] <deryck[lunch]> qense, that seems an issue with the summit.ubuntu.com app, since you're listed in the launchpad sprints page.
[16:55] <deryck[lunch]> qense, I'm not sure who to ping about that, but I can check after I eat.
[16:56] <qense> deryck[lunch]: the strange thing is that the Launchpad page for the summit also still allows me to (+) Register my attentdance.
[16:56] <qense> deryck[lunch]: but have your lunch first :)
[16:59] <persia> qense: OOh, cool.  I can replicate.  I'm not sure it's an LP issue though, as LP showed me as attending both before and after I played with summit and reregistered.
[17:01] <qense> persia: But shouldn't the (+) button go away on Launchpad when you've registered yourself as attending?
[17:01] <persia> I don't think so: I think it's an artifact of being able to edit one's attendance.  Yes, it's a bug, but just a minor UI bug (should be pencil rather than +)
[17:04] <qense> then it's just an Summit issue
[17:04] <persia> I think so.
[17:04] <persia> Plus the minor UI bug.
[17:06] <qense> ok
[17:07] <qense> persia: There is going to land a new version of Summit real soon, iirc, so I'll wait for that to arrive.
[17:07] <persia> No idea.
[17:07] <persia> jcastro: Do you know who knows about summit, or in which channel we should ask questions, or how to file bugs?
[17:08] <qense> iirc there is a 'summit' project on LP for that
[17:08] <jcastro> persia: lp.net/summit
[17:08] <jcastro> persia: Daviey is your man
[17:09] <persia> jcastro: Cool, thanks :)
[17:10] <jcastro> persia: I've assigned him some bugs already so get them in quick before scheduling starts!
[17:10] <persia> qense: Are you handling this bug, or shall I file it?  If you are, please subscribe me.
[17:11] <qense> persia: I'll file it and subscribe you.
[17:12] <persia> qense: Thanks :)
[17:13] <persia> I'll confirm it in a bit.
[17:13] <qense> persia: thanks for that!
[17:14] <qense> persia: You're subscribed!
[17:15] <persia> Confirmed and me-too'd.
[17:15] <qense> great!
[19:03] <cbx33> hey guys got a question
[19:03] <cbx33> I see a packge ina  ppa, but when I try to apt-get install it, it's not there
[19:04] <cbx33> and it's not in the packages.gz file either
[19:04] <cbx33> any ideas?
[19:06] <james_w> cbx33: did it fail to build?
[19:06] <cbx33> I don't htink so
[19:07] <cbx33> it is the zfs-fuse package from brcha ppa
[19:08] <james_w> which series?
[19:08] <james_w> it's not available for karmic or lucid
[19:08] <cbx33> hmmm
[19:08] <cbx33> that's odd
[19:08] <cbx33> a page i saw had it add it for karmic
[19:09] <cbx33> the title of the post was zfs-fuse for 9.10
[19:38] <deryck> sinzui, does registry get sprint app bugs?
[19:39] <sinzui> no, They exist for the sake of blueprints
[19:41] <sinzui> deryck, I retargeted a sprint bug to blueprints a few hours ago
[19:42] <deryck> sinzui, ah, ok.  Thanks.
[19:46] <micahg> is  that right, 16k jobs for the i386 PPAs?
[19:52] <persia> micahg: Maybe an archive-rebuild-test?
[19:52] <micahg> persia: maybe
[19:52] <persia> Those are low-priority (below PPA) typically.
[19:57] <sladen> https://bugs.launchpad.net/malone/+bug/558642  <-- celebrity bug popularity fail
[20:01] <kfogel> sinzui: Do you know if there's any way for me to set an arbitrary user as an Answer Contact for Launchpad?
[20:01] <kfogel> sinzui: I click "Set answer contact" to get to https://answers.edge.launchpad.net/launchpad/+answer-contact, but my choices there are: myself, or one of a set list of teams.  I can't just type in a user's name.
[20:05] <sladen> kfogel: isn't on the basis of a user choosing to subscribe themself?
[20:05] <sladen> themselve
[20:06] <kfogel> sladen: yeah, I'm going to ask the user if he can set himself (but suspect he can't).
[20:06] <sinzui> kfogel, you cannot make someone do a task
[20:06] <sinzui> kfogel, though it would be nice if I could subscribe a user to a question that concerns him
[20:07] <kfogel> sinzui: ok
[20:07] <sinzui> kfogel, a user can choose the be an answer contact for *any* project.
[20:08] <kfogel> sinzui: oh, great, I didn't realize that
[20:09] <sinzui> kfogel, Launchpad recognises that the support and translation communities are often autonomous from the core project. we let communities contribute by choice rather than by authority
[20:09]  * sinzui may have the formation of his next blog post
[20:10] <kfogel> sinzui: :-)
[20:11] <kfogel> sinzui: this is all around that user who asked matsubara if he (the user) could be an answer contact for Launchpad.  After all this digging, it turns out he could have just set himself as a contact from the get-go.
[20:11] <kfogel> It sounds like, anyway.
[20:13] <sebi`> does launchpad allow any sort of markup for, let's say, announcements, and kinds thereof?
[20:17] <matsubara> kfogel, you're right. I just tested on staging with my test account and by setting myself as the answer contact I was able to edit a question's assignee
[20:17] <matsubara> kfogel, so just telling the guy to set himself as an answer contact will solve the trick
[20:18] <matsubara> s/the trick/the problem/
[20:29] <cbx33> sladen, hey long time dude
[21:03] <mdke> jelmer, mwhudson - what should I do to try and resolve this? File a bug? On what project?
[21:04] <jelmer> mdke: I'm not sure where the problem is exactly; I can't reproduce the failure locally
[21:04] <jelmer> So perhaps this can be resolved by updating the version of bzr-git on Launchpad
[21:05] <mdke> jelmer: so should I file a question / bug for that?
[21:06] <jelmer> mdke: Good question
[21:06] <jelmer> mwhudson: there?
[21:07] <jelmer> mwhudson: I'll push a fix for the -0000 / +0000 patch in a bit, perhaps we could try that patch on staging?
[21:11] <mwhudson> jelmer: yeah ok
[21:14] <bodhi_zazen> Is there a limit to how many admins can be on a project or team ?
[21:14] <bodhi_zazen> And can only the project owner add an admin, or can another admin add one ?
[21:15] <persia> bodhi_zazen: No, and yes
[21:15] <bodhi_zazen> TY


[07:20] <tvoss> good morning
[07:20] <tvoss> Mirv, good morning
[07:22] <Mirv> hi tvoss
[07:23] <tvoss> Mirv, looking at the sheet, line 9
[07:23] <tvoss> Mirv, I don't understand the comment there
[07:23] <tvoss> Mirv, could you explain to me what happened?
[07:29] <Mirv> tvoss: it seems it has been published, but is stuck in -proposed for some reason
[07:29] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbus-cpp
[07:30] <Mirv> arm64 has failed to build, but it succeeded before: https://launchpad.net/ubuntu/+source/dbus-cpp/2.0.0+14.04.20140307-0ubuntu1
[07:30] <Mirv> seems to be the reason
[07:30] <Mirv> https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:31] <tvoss> hmmm, that's weird
[07:38] <tvoss> cjwatson, good morning
[07:38] <tvoss> cjwatson, I get a build failure here https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:39] <didrocks> Mirv: hey, can you provide an url if you still have the same issue?
[07:39] <didrocks> for the silo stuff
[07:40] <didrocks> oh found the issue
[07:40]  * didrocks fixes
[07:40] <didrocks> ah no
[07:40] <didrocks> hum
[07:41] <Mirv> didrocks: I haven't yet retried since I thought you'd take a glance first
[07:41] <didrocks> Mirv: yeah, please give me a link
[07:41] <didrocks> you didn't in your email
[07:42] <Mirv> didrocks: it's in my last e-mail bu http://<IP_ADDRESS>/job/prepare-silo/421/console
[07:42] <didrocks> Mirv: ah, ok, was still on the first one
[07:42] <didrocks> thanks
[07:42] <didrocks> yeah, weird that we have WARNING:root:Can't load configuration: No JSON object could be decoded
[07:42] <didrocks> Mirv: I'll look in a few
[07:42] <Mirv> yep, that one is weird
[07:43] <Mirv> yeah, no hurry. I found 4 more packages not yet in landing PPA, and 3 of them are manual uploads which I'm doing now.
[07:46] <didrocks> ok, we'll get that fixed
[07:46] <didrocks> the logic seems good, so it's like it can't find the initiale configuraiton
[07:46] <didrocks> I'll check with debug :)
[07:46] <didrocks> (10 minutes)
[07:58] <didrocks> Mirv: ah, interesting, the config file is empty
[07:59]  * didrocks restore and try
[07:59] <didrocks> Mirv: did you have any failure previously on that silo?
[08:00] <didrocks> Mirv: and after that, all work like expected. It would be interesting to know what lead in your silo to have that empty config file
[08:02] <didrocks> Mirv: running http://<IP_ADDRESS>/job/prepare-silo/423/console btw
[08:07] <Mirv> didrocks: the only thing I did was aborting build job, because of a ppc64el build that the system thought was building while it was not
[08:08] <Mirv> didrocks: I got the error twice in the row and stopped at that. interesting.
[08:08] <didrocks> Mirv: yeah, shouldn't happen
[08:08] <didrocks> Mirv: tell me next time you see it, I'll be interested in fixing this bug
[08:08] <didrocks> not sure, I try to always have transactional writes
[08:08] <Mirv> sure, I will
[08:08] <didrocks> thanks ;)
[08:09] <didrocks> Mirv: on your question: please for those package, just disable them in daily release
[08:09] <didrocks> + upstream merger and so on
[08:09] <didrocks> (the 3 lines)
[08:10] <Mirv> didrocks: ok, thanks, I'll disable those: dee-qt qtpowerd poppler-qml-plugin u1db-qt ubuntu-system-settings-online-accounts unity-scope-online-music click-update-manager clickmanager-plugin ubuntu-purhase-service
[08:12] <Mirv> well, some of them already are, but anyhow
[08:23] <didrocks> ok ;)
[08:23] <popey> bug 1289804
[08:23] <popey> seems we have a memory leak issue..
[08:23] <popey> (not just music-app)
[08:23] <didrocks> popey: blocker in your opinion?
[08:23] <popey> been there a while
[08:24] <popey> but worse than it was in #194.
[08:24] <didrocks> popey: they will tell you they will only look with 5.2 :p
[08:24] <popey> we tested with 5.2 too..
[08:24] <popey> https://bugs.launchpad.net/music-app/+bug/1289804/comments/9
[08:25] <didrocks> popey: argh, ok
[08:25] <popey> so no, not a blocker to #226
[08:25] <popey> it manifests itself in music because it's unconfined, you can get any app to eat ram by keeping it alive with taps
[08:25] <popey> so it certainly needs examination
[08:26] <didrocks> yep :)
[08:26] <didrocks> hum
[08:26] <popey> my phone was unusable after 20 hours of uptime and no usage ☻
[08:26] <didrocks> I received the notification for the team meeting
[08:26] <popey> americans changed TZ
[08:26] <didrocks> meaning the meeting is not set in UTC?
[08:26] <popey> it moved here too
[08:26] <popey> (the meeting moved) - it shows at 08:30 UTC
[08:26] <didrocks> let me adjust the time again
[08:27] <popey> probably the Ubuntu Engineering calendar is USA TZ
[08:27] <ogra_> didrocks, you will have to adjust back on the 30th
[08:27] <didrocks> ogra_: yep
[08:27] <didrocks> popey: weird, the Tz set for it is "France" though
[08:28] <didrocks> anyway, let's move them
[08:28] <didrocks> and we'll move them back
[08:28] <didrocks> oh, there is one everyday?
[08:28] <didrocks> it's a separate one :p
[08:28] <didrocks> ah no, phew
[08:28] <didrocks> just long to refresh
[08:28] <popey> no, they are separate
[08:29] <popey> i moved some ☻
[08:29] <didrocks> ahah :)
[08:29] <didrocks> the 6PM as well?
[08:29] <didrocks> or they didn't move?
[08:30] <popey> oof, I broke, let me fix
[08:30] <didrocks> removing as well meetings during vUDS
[08:31] <popey> ah yes
[08:33] <didrocks> vUDS is so empty!
[08:33]  * didrocks scheduled last client meetings in seb128's track
[08:33] <didrocks> hehe :)
[08:40] <popey> didrocks: who 'owns' ubuntu-emulator? xnox?
[08:40] <didrocks> popey: yeah, the biggest contributors are xnox/cjwatson/rsalvetti AFAIK
[08:40] <popey> hm, ok
[08:41] <tvoss> didrocks, good morning
[08:41] <sil2100> Finally made it
[08:42] <sil2100> Morning!
[08:42] <didrocks> hey tvoss, morning
[08:42] <didrocks> hey sil2100 :)
[08:42] <didrocks> popey: anything we should be worried about?
[08:42] <popey> saw a couple of people in -touch mention that their emulator wasn't starting. I tried this morning and I can't get it to build a working image either
[08:42] <popey> just get a black screen
[08:42] <tvoss> didrocks, sil2100 the dbus-cpp landing seems to be stuck in proposed due to arm64 not building. However, the compilation fails with the compiler complaining about -fstack-protector missing
[08:43] <tvoss> didrocks, sil2100 the interesting bit is: I think I don't set that explicitly somehwere
[08:43] <popey> trying again from clean.
[08:44] <didrocks> tvoss: it's the distribution default
[08:44] <tvoss> didrocks, that's interesting that it fails on arm64 then :)
[08:44] <tvoss> didrocks, https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:44] <didrocks> tvoss: https://wiki.ubuntu.com/ToolChain/CompilerFlags
[08:45] <didrocks> tvoss: I guess it's something to check with doko, I have no clue about arm64 if it's supposed to support stack-protector or not
[08:45] <sil2100> tvoss: hmm, well, there was no way to test it beforehand on arm64, as I can't set up a arm64 chrrot even
[08:45] <didrocks> and if so, why it's set
[08:45] <sil2100> tvoss: strange thing - why didn't it fail for the previous dbus-cpp builds?
[08:46] <didrocks> tvoss: and yeah, I confirm that you don't seem to do anything with the flags that can set it on that arch
[08:46] <didrocks> (and so override potential defaults)
[08:46] <didrocks> but you force 4.7
[08:46] <didrocks> and I'm unsure 4.7 has the right defaults for that arch, I guess doko only cares about 4.8
[08:46] <didrocks> tvoss: that can be a lead to discuss about it with him I think ^
[08:50] <didrocks> sil2100: previous version was built with 4.7 or 4.8?
[08:54] <sil2100> hm, with 4.7
[08:54] <sil2100> didrocks: since the whole issue we had with location-service being 100% CPU was caused by the 4.7/4.8 incompatibility
[08:54] <didrocks> sil2100: ok, weird then
[08:55] <didrocks> I think tvoss has enough information to know where to look at anyway :)
[08:55] <cjwatson> tvoss: Morning.  arm64 doesn't have stack-protector.  Why are you forcing that, though, given that -fstack-protector is on by default in Ubuntu anyway?
[08:55] <sil2100> So we pushed a force rebuild on 4.7 + the symbols hack
[08:55] <cjwatson> didrocks: emulator> not me
[08:55] <sil2100> Strange anyways!
[08:55] <tvoss> cjwatson, I'm *not* forcing it
[08:55] <didrocks> cjwatson: I don't see it in his build flags though, but he's using gcc 4.7, do you think that disabling stack-protector can be missing on that versioN?
[08:55] <cjwatson> didrocks: It's explicitly on the command line
[08:56] <cjwatson> So it's not GCC's fault :)
[08:56] <cjwatson> Wonder if it's cmake
[08:56] <didrocks> yeah, I'm looking into that direction
[08:56] <cjwatson> Or dpkg-buildflags
[08:56] <didrocks> nothing special on the configure flags
[08:56] <cjwatson> I'd have thought dpkg-buildflags shouldn't have -fstack-protector on arm64 though
[08:57] <didrocks> well, I guess all packages would fail otherwise…
[08:59] <cjwatson> that command line does look awfully like dpkg-buildflags though
[09:00] <didrocks> yeah, followed by --param=ssp-buffer-size=4 and so on, with -g -O2 before…
[09:01] <cjwatson> Oh
[09:01] <cjwatson> dpkg (1.17.5ubuntu5) trusty; urgency=medium
[09:01] <cjwatson>   * Allow -fstack-protector on arm64 now that GCC and glibc support it.
[09:01] <cjwatson>  -- Adam Conrad<EMAIL_ADDRESS>Fri, 07 Mar 2014 18:47:57 +0800
[09:01] <didrocks> here we go
[09:01] <cjwatson> So gcc-4.8 supports it, but of course dbus-cpp is forcing gcc-4.7
[09:01] <didrocks> tvoss: you have your infos ^
[09:01] <cjwatson> tvoss: export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector
[09:02] <cjwatson> well, conditional on arm64
[09:02] <cjwatson> so, in debian/rules:
[09:02] <tvoss> cjwatson, so that's in debian/rules?
[09:02] <cjwatson> ifeq (arm64,$(DEB_HOST_ARCH))
[09:02] <cjwatson> export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector
[09:02] <cjwatson> endif
[09:02] <cjwatson> should do it
[09:02] <cjwatson> with a comment that this is because g++-4.7 doesn't have SSP, and it can go away if/when you move to 4.8
[09:04] <cjwatson> didrocks,Mirv: the ppc64el build in question was a build *failure*, not so much "building" although that's how the job described it
[09:04] <didrocks> cjwatson: something stripped out the status file, so it wasn't refreshed anymore. So don't take into account the status reported in that case
[09:05] <cjwatson> didrocks,Mirv: that was qttools-opensource-src, which we got building later
[09:05] <cjwatson> it was definitely not building at the time
[09:05] <cjwatson> or rather it was definitely failed at the time
[09:05] <didrocks> cjwatson: I'm maybe out of context for that last ping, but the job was running or you were talking about the jenkins job iself?
[09:05] <didrocks> itself*
[09:06] <Mirv> cjwatson: I think since it started on Friday, it had not yet been build at all. the first failure of qttools was then on Saturday after copy-package https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+builds?build_text=qttools&build_state=all
[09:06] <cjwatson> I don't know the distinction
[09:06] <cjwatson> Mirv: it was dep-wait on qtdeclarative at the time - I checked
[09:06] <Mirv> but on Friday (until Saturday) CI Train was under impression there was a build of ppc64el that was building
[09:06] <cjwatson> that's why I sent you a qtdeclarative porting branch
[09:06] <Mirv> cjwatson: this is what I aborted originally http://<IP_ADDRESS>/job/landing-006-1-build/65/console
[09:06] <cjwatson> I was explicitly working on clearing up that job :)
[09:06] <Mirv> cjwatson: aha, ok
[09:07] <cjwatson> from my point of view the ci-train job was entirely correct - I mean, regardless of fine distinctions, it'd have got stuck in proposed-migration due to the missing ppc64el build, so it was right to fix it
[09:08] <tvoss> sil2100, pushed an update to https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-race-and-add-tests
[09:08] <tvoss> sil2100, can you trigger a rebuild?
[09:09] <didrocks> tvoss: that should be before the include I guess
[09:09] <didrocks> (and you can retrigger yourself normally, with ignore step and only set the component you want to rebuild with only rebuild)
[09:10] <didrocks> you don't need sil2100 for that
[09:10] <sil2100> tvoss: you can rebuild yourself :)
[09:10] <cjwatson> include> I don't know if it matters, but can't hurt to move it earlier
[09:11] <sil2100> tvoss: just find the silo on the spreadsheet, press rebuild, log into jenkins (SSO) and press build
[09:11] <sil2100> tvoss: maybe write to only 'rebuild' dbus-cpp
[09:12] <didrocks> cjwatson: ah ok, I was under the impression it was looking for the definition in the env first and won't look at it again, but I just skimmed over the makefile for that, so you're probably more exact than I am. Thanks :)
[09:12] <sil2100> didrocks: how do we handle cases when a silo is already in the 'releasing, stuck in proposed' state?
[09:12] <sil2100> tvoss: wait a moment with that if anything
[09:12] <didrocks> sil2100: just rebuild what's needed to be rebuilt and I think you will need the "ignore step" option
[09:13] <sil2100> didrocks: ok
[09:13] <didrocks> then, it will rebuild only that component, and track it
[09:13] <sil2100> tvoss: let me help you in that then, I'll do this
[09:13] <didrocks> (however, it will recollect all commits since latest version in the release pocket and upload with -v)
[09:13] <tvoss> sil2100, ack
[09:13] <cjwatson> didrocks: this is one of those things where I'd have to read the GNU Make manual carefully, and it's not worth it :)
[09:13] <didrocks> but that was only tested in labs, it's the first time in production :)
[09:13] <didrocks> cjwatson: heh, indeed :)
[09:14] <sil2100> didrocks: uuuu ;p Ok, let's try that then
[09:15] <sil2100> didrocks: hmmm... I just noticed my mail, I probably missed something, but was todays landing meeting moved to an earlier hour?
[09:16] <didrocks> sil2100: it was, weirdly (probably due to US dailylight saving switch)
[09:16] <didrocks> sil2100: so I rescheduled at the correct time
[09:16] <sil2100> My google calendar said 9:30 till 10, like one hour earlier than normally :o Did I miss it?
[09:16] <sil2100> Ah
[09:16] <sil2100> Ok ;)
[09:16] <didrocks> sil2100: your google calender should have it updated?
[09:17] <sil2100> didrocks: ah, right, calendar has the correct date, but I didn't get a confirmation of the change on e-mail, so I was a bit shocked
[09:17] <sil2100> THanks ;)
[09:18] <didrocks> yeah, I avoided to spam all of you
[09:26] <sil2100> tvoss: let's wait for it to re-build
[09:26] <tvoss> sil2100, ack
[09:31] <didrocks> popey: coming?
[09:32] <popey> omw
[10:01] <cjwatson> Mirv: given that we'll be waiting for arm64 to build everything, I would suggest blocking the set of packages in the Qt5.2 silo in proposed-migration
[10:01] <cjwatson> (once you push the button)
[10:01] <cjwatson> just to avoid accidents with partial promotions
[10:03] <popey> didrocks: who should I poke https://bugs.launchpad.net/music-app/+bug/1289804 with?
[10:03] <didrocks> popey: reboot worked for you?
[10:03] <popey> yes didrocks
[10:04] <didrocks> popey: ok, I don't have it either here in a fresh flashed image
[10:04] <didrocks> worth keeping it in mind and see
[10:04] <popey> will keep an eye out for it on future updates
[10:04] <didrocks> thanks
[10:04] <didrocks> popey: for bug #1289804, I would say let's start with upstream, so osomon/bfiller
[10:04] <Mirv> cjwatson: ok, didrocks can probably set the block, at least if it turns out we enable the arm64 builds but then suddenly make a decision tomorrow or so about actually landing it
[10:05] <Mirv> arm64 is going to be interesting, starting with qtbase where doko told the arm64 patches can be dropped with 5.2, I hope it's so
[10:06] <didrocks> davmor2: oh btw, can you dogfood image #229? We'll get it in our bag for promotion :)
[10:06] <didrocks> Mirv: yeah, better to prepare it
[10:06] <didrocks> Mirv: when is that meeting? Maybe I should come this time
[10:07] <davmor2> didrocks: yeah no worries
[10:07] <Mirv> didrocks: umm, I now see the meeting is no more this week, at least currently. it used to be 14:00 UTC
[10:07] <didrocks> Mirv: interesting…
[10:07] <didrocks> Mirv: wasn't moved to one hour later? (as many meeting due to US TZ change)
[10:07] <didrocks> meetings*
[10:08] <Mirv> didrocks: no, just not there. probably set to be daily "until we've probably shipped it" or so :)
[10:08] <didrocks> Mirv: yeah ;)
[10:08] <Mirv> the unity8 AP problem might have a fix now, since I rebuilt qtbase with a fix suggested from unity people
[10:09] <didrocks> Mirv: tell me if you need anything, but I clearly think that we should continue on what was discussed Friday: only the expected AP failure
[10:09] <didrocks> ok
[10:09] <Mirv> weather app I think was already seen to be broken, probably needs fixes for 5.2
[10:09] <didrocks> expected == clock apps as from today
[10:09] <Mirv> it'd be nice if gallery app could be tested somehow
[10:09] <didrocks> and 2 weather apps ones
[10:09] <didrocks> ah no, it's one on weather-app
[10:10] <didrocks> Mirv: so, we expect only 1 clock AP test failure + 1 weather AP test failure
[10:10] <didrocks> all the rest needs to be investigated
[10:10] <Mirv> didrocks: I checked that online-acounts does have the revert in it
[10:10] <didrocks> Mirv: the run from Friday?
[10:10] <didrocks> AP test run?
[10:11] <didrocks> (the code where we see it failing shouldn't be in the revert at all)
[10:11] <Mirv> didrocks: hmm, actualy, it's a good question whether the AP run or the Friday's online-accounts rebuild was there first..
[10:11] <Mirv> didrocks: so that's probably then it
[10:11] <didrocks> Mirv: ok, worth having a look anyway :)
[10:12] <Mirv> didrocks: I originally btw thought that if 5.0 image can be promoted, it's good to land 5.2, but you think we continue at least for now seeking to do 100% smooth transition (where, nearer to it than current situation)?
[10:12] <Mirv> I wonder if UI Freeze on Thursday poses a problem
[10:12] <didrocks> Mirv: yeah, otherwise, we'll never recover and block everyone else not part of the transaction
[10:13] <didrocks> Mirv: why? we have FFe for our components (and it doesn't change the UI)
[10:13] <Mirv> true enough, nothing should change UI wise
[10:13] <didrocks> Mirv: we can't ask blocking the whole distro again on pushing something not ready when we know it's not ready yet
[10:13] <didrocks> that won't make it more "ready"
[10:15] <Mirv> I don't think anyone is currently working on the 5.2 related AP problems, though, yet
[10:15] <Mirv> that should change, of course
[10:15] <didrocks> Mirv: that should have been the focus as well of the 5.2 meetings though
[10:16] <didrocks> yeah
[10:16] <Mirv> didrocks: the problem was that for most of the last week the AP runs were not working because of the adb/makodevice problems
[10:16] <Mirv> now we've that one run finally
[10:16] <didrocks> Mirv: which issue?
[10:17] <didrocks> Mirv: something we don't have on ci.ubuntu.com?
[10:17] <Mirv> didrocks: I mean the AP runs were not possible to do because of http://q-jenkins:8080/job/autopilot-release-gatekeeper/61/console
[10:17] <Mirv> first the adb problems and then the connection to mako:s not working, elopio & his team were then onto it
[10:18] <didrocks> Mirv: ok, so infra issues mostly?
[10:18] <Mirv> didrocks: yes
[10:18] <didrocks> Mirv: anyway, we discussed about the AP tests on Friday with elopio and asac as well agreed with me
[10:18] <didrocks> Mirv: so I don't think that will come to a surprise
[10:19] <Mirv> yeah. so trying to fix those should continue together with the DPR issue fix.
[10:21] <didrocks> yep
[10:24] <tvoss> sil2100, didrocks I'm kinda lost with the dbus-cpp landing now
[10:25] <sil2100> tvoss: ok, wait, it finished building
[10:25] <cjwatson> didrocks,Mirv: landing-006 has arm64 now, so can you please copy everything in that PPA into itself?
[10:25] <sil2100> tvoss: let's do a quick test-spin on a device if all is ok and then re-publish
[10:26] <cjwatson> (let me know if you need a canned command line)
[10:26] <didrocks> Mirv: you are handling the copy?
[10:26] <tvoss> sil2100, okay, I will give it a spin, too
[10:26] <tvoss> sil2100, could you try it, too?
[10:26] <cjwatson> copy-package -p ci-train-ppa-service --ppa-name landing-006 -b <list of all the source packages>
[10:26] <sil2100> tvoss: sure, doing that now
[10:27] <tvoss> sil2100, thanks
[10:27] <Mirv> cihelp infrastructure problems running AP tests http://q-jenkins:8080/job/autopilot-release-gatekeeper/64/ - previous successful run on Friday
[10:28] <Mirv> didrocks: ok, handling the copy
[10:28] <didrocks> thanks :)
[10:32] <Mirv> actually, I'll not copy everything, since not everything build-deps on the new Qt. so starting with Qt itself which is all set up good regarding dependencies
[10:33] <cjwatson> why the backup-landing1?
[10:33] <cjwatson> oh ye of little faith
[10:35] <Mirv> cjwatson: too much to lose :)
[10:35] <cjwatson> you couldn't copy it back without generating at least some new builds anyway ... but ok
[10:37] <ogra_> hmm, promoting takes loong with so many arches
[10:38] <Mirv> actually, I will start by qtbase only because that's the one with the libqt5core5 -> libqt5core5a change
[10:38] <cjwatson> reasonable, yeah
[10:38] <sil2100> wow
[10:39] <Mirv> and so it begins
[10:41] <sil2100> hmmm, what a nice bug I got!
[10:43] <didrocks> sil2100: on the double promotion for fixing something stuck into proposed? It's possible as I only tested that case in lab :)
[10:44] <sil2100> didrocks: no no, on 229 ;) I'll show a photo of that, it's just a funny thing, I guess it's just some layouting issue or something ;p
[10:45] <didrocks> ah :)
[10:46] <ogra_> grmpf ...
[10:46] <ogra_> promotion of 226 on mako runs since 13min ... doesnt move ...
[10:52] <didrocks> ogra_: still stuck?
[10:52] <ogra_> yes
[10:52] <ogra_> 29071 pts/1    S+    16:12 /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k
[10:52] <didrocks> so, we'll need stgraber?
[10:52] <ogra_> runs sine 16:12
[10:52] <ogra_> yes, i think so
[10:52] <ogra_> seems copy-image also doesnt produce any logs
[10:53] <ogra_> it just sits there (seems to be in running state though)
[10:53] <cjwatson> might just be rechecksumming or something
[10:53] <ogra_> i see it updated the timestamp for the output dir though
[10:53] <cjwatson> 29071 pts/1    S+    16:14  |                   \_ /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k
[10:53] <cjwatson>  2963 pts/1    Rl+    0:33  |                       \_ pxz -z -9 -c /tmp/tmpgcbAS5/output.tar
[10:53] <cjwatson> looking at more of the process tree helps :P
[10:53] <ogra_> sigh ... we have 6 arches to promote
[10:53] <cjwatson> I'm sure it'll get there
[10:53] <ogra_> that will take 1.5h now
[10:54] <cjwatson> xz compression just takes a while
[10:54] <ogra_> yeah, but it used to be a matter of 1-2min before
[10:54] <cjwatson> then why will it take 1.5h now?
[10:54] <cjwatson> 1-2min * 6 != 1.5h
[10:54] <ogra_> i guess that we havent promoted anything in rwo weeks might play a role for the diffing
[10:54] <ogra_> cjwatson, it used to take 1-2min ... if it takes 15 per arch now it will take a small century :)
[10:55] <ogra_> ah, it moved
[10:55] <cjwatson> does it matter for this particular run? :)
[10:55] <Mirv> cjwatson: ok doesn't start too well https://launchpadlibrarian.net/168944721/buildlog_ubuntu-trusty-arm64.qtbase-opensource-src_5.2.1%2Bdfsg-1ubuntu6_FAILEDTOBUILD.txt.gz
[10:55] <ogra_> not anymore, no ... i would have waited with starting it though ... since i have to go afk in 10min
[10:55] <Mirv> the patches that were there with 5.0.2 were http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/revision/140
[10:56] <cjwatson> ogra_: it got through manta pretty quick, so *shrug*
[10:56] <ogra_> oh, seems the other arches run faster
[10:56] <cjwatson> Mirv: so what thinks it needs to use -m64?
[10:56] <ogra_> grr
[10:56] <ogra_> http://paste.ubuntu.com/7067002/
[10:57] <cjwatson> Mirv: oh right, easy
[10:57] <cjwatson> Mirv: http://paste.ubuntu.com/7067006/
[10:58] <cjwatson> that's for arches where -m64 doesn't make sense
[10:59] <Mirv> cjwatson: ok, and I don't see other similar things in debian/rules so I guess worth a rerun unless there's a test PPA to use
[10:59] <cjwatson> you used to have a separate if case for it, you just moved arm64 to the wrong place
[11:00] <cjwatson> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/view/140/debian/rules lines 69-72
[11:00] <davmor2> Morning all
[11:00] <cjwatson> Mirv: probably worth just rerunning in 006
[11:00] <Mirv> ok
[11:02] <mandel> ogra_, do you know how is the qt 5.2 thing going?
[11:02] <ogra_> mandel, Mirv does ;)
[11:03] <Mirv> mandel: https://bugs.launchpad.net/webbrowser-app/+bug/1207270 needs to be fixed and some AP tests are failing http://q-jenkins:8080/job/autopilot-release-gatekeeper/63/
[11:03] <mandel> Mirv, thx
[11:04] <ogra_> mandel, Mirv does ;)
[11:04] <ogra_> oops
[11:04] <ogra_> sorry
[11:04] <Mirv> I do, I do
[11:04] <ogra_> heh, EFOCUS
[11:04] <Mirv> and that's why I've prevented 'up' binding in irssi, requiring ctrl-up
[11:06]  * ogra_ needs to go afk now for like 20min ... i'll check the promotion later ... looks like mako might need a re-run
[11:06] <mandel> Mirv, we need to fix that ogra_ bot, it has some weird stammer
[11:07] <ogra_> heh
[11:15] <tvoss> sil2100, ping
[11:16] <tvoss> sil2100, any luck with the dbus-cpp packages?
[11:16] <tvoss> sil2100, didrocks can I get a silo for line 34?
[11:17] <didrocks> tvoss: unity-mir is part of the qt 5.2 landing
[11:17] <tvoss> didrocks, oh okay
[11:18] <sil2100> tvoss: still checking out - looks ok from the outside, but I still couldn't get location working yet
[11:19] <tvoss> sil2100, location not working as in?
[11:23] <sil2100> tvoss: can't force webbrowser to use location data after enabling it in the indicator
[11:24] <sil2100> popey, davmor2: does location work properly for you on stock 229 ?
[11:24] <tvoss> sil2100, the indicator is not fixed with my changes. Also: it might take 15 minutes to acquire a fix
[11:24] <popey> sil2100: define "work"
[11:26] <sil2100> popey: after enabling the indicator, does opening a webbrowser prompt you for allowing location on google maps and then it finally finds the GPS signal?
[11:26] <popey> sil2100: i have _never_ had success in a browser finding location
[11:26] <davmor2> sil2100: haven't tried it yet, ignore the indicator though it lies
[11:27] <popey> tell you what is odd though
[11:28] <popey> open browser, visit maps.google.com, kill browser, start again.
[11:28] <popey> The first time you get mobile version of gmaps, second time you get desktop version
[11:28] <davmor2> popey: because you click on the link for maps right
[11:29] <davmor2> popey: -https:// always links to the mobile site, if you click on the link it the address bar it always goes to desktop
[11:31] <ogra_> hmm, so promoting mako and generic failed ... re-running for these two
[11:32] <popey> no
[11:32] <popey> i didnt click any link
[11:32] <popey> i opened browser
[11:33] <ogra_> ugh, and flo too ...
[11:33]  * ogra_ sighs
[11:34] <davmor2> sil2100: osmtouch has me pinpointed nicely so I assume gps is working
[11:38] <popey> davmor2: osmtouch doesn't use gsm
[11:38] <popey> *gps
[11:39] <davmor2> popey: It's stops flashing the warning there is no gps and pinpoints you precisely when there is a fix and google maps works then too
[11:41] <davmor2> popey: initially it doesn't I agree but then it tells you it isn't using gps and also tells you that the position is approximate
[11:45] <davmor2> popey, didrocks, ogra_: screen has just frozen again, this time 2 apps open and I swiped to get back to the dash chasing up on #ubuntu-mir channel but not seeming to get a response yet,  I'll carry on dogfooding on the n7 for a bit
[11:45] <didrocks> davmor2: thanks
[11:46] <ogra_> davmor2, make sure to back up syslog and the output of dmesg ... and probably also logcat
[11:47] <davmor2> ogra_: thanks will do that now, the phone is working fine just not the screen
[11:47] <ogra_> right
[11:47] <popey> davmor2: Mar 10 11:47:38 ubuntu-phablet com.ubuntu.location[893]: SV status update: [#svs: 23]
[11:47] <popey> i get 23 satellites in view and it still cant get a lock
[11:47] <ogra_> syslog should show OOM if there is any OOM going on ... and logcat should show any graphics driver issues
[11:48] <davmor2> popey: just checked top and there is no swap being used so it's not the issue you saw
[11:48] <popey> it takes a long time to use swap
[11:48] <popey> you need an app to be open for hours
[11:49] <davmor2> popey: ah okay so no :)
[11:51] <sil2100> tvoss: didn't test location properly yet but all seems to be ok I think
[11:51] <ogra_> sigh .... and generic failed again ... as did flo
[11:51] <sil2100> Let's publish (again)
[11:51]  * ogra_ re-runs again with these two arches
[11:53] <didrocks> ogra_: keep logs for Stéphane I guess
[11:53] <didrocks> ogra_: btw, as mako is promoted, it's now show up as promoted on the dashboard :p
[11:54] <ogra_> yeah, indeed
[11:58] <popey> davmor2: for me, it always says no gps
[11:59] <davmor2> popey: let me get it install on the n7
[12:12] <sil2100> didrocks: http://<IP_ADDRESS>/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-cpp_2.0.0+14.04.20140310-0ubuntu1.diff <- packaging change ;)
[12:12] <tvoss> sil2100, ack and thx
[12:13] <tvoss> sil2100, I got a fix here, standing on the balcony and waiting for ~8 minutes
[12:13] <didrocks> sil2100: looks good to me
[12:19] <sil2100> didrocks: thanks ;) Let's see how it goez
[12:23] <davmor2> popey: this is all I get once I have a lock http://ubuntuone.com/4HwOplWn8pgR3yWMU1Hq7e until then it shows me in bushbury about a mile and a half away and says it's a guess :)
[12:25] <sil2100> didrocks: so, can I now publish only one component that was re-built? Since I rebuilt only dbus-cpp, publish job says that others (platform-api and location-service) weren't rebuilt - can I safely tell him to ignore those and just push dbus-cpp out? No need to re-release the others, no changes or rebuilds required there
[12:26] <didrocks> sil2100: yeah, just use the ignore flag
[12:26] <popey> davmor2: how do you know when you have a gps lock?
[12:26] <sil2100> *click*
[12:27] <davmor2> popey: I keep clicking on the My location button either in maps.google.com or osmtouch till it is right :)
[12:28] <sil2100> didrocks: all seems to work fine! o/
[12:28] <didrocks> :)
[12:28] <ogra_> didrocks, so i promoted on all arches now manually bit by bit ... sald yi messed up on flo so that it is called 207 there ... will sort that ut once stgraber is up
[12:28] <didrocks> ogra_: ok, thanks a lot! :)
[12:29] <davmor2> popey: maps.google.com tends to show position correctly when osmtouch does though up until then it says no gps location or words to that effect
[12:29] <ogra_> smells like the import job that runs every 5 min to check for new cdimage files makes it fall over ... once i disabled it i could at least run copy-image manually for each arch
[12:36] <didrocks> sil2100: as you can see, it's tracking the right version of dbus-cpp
[13:01] <cjwatson> Mirv: looks like qtbase/arm64 is good now
[13:02] <Mirv> cjwatson: yes, I was just refreshing Packages file and starting landing the rest of the Qt modules
[13:05] <Mirv> done, qtxmlpatterns started already
[13:17] <sergiusens> didrocks, hey, for new packages that would be handled by ci train; how do we do the ffe?
[13:18] <didrocks> sergiusens: it's packages that are new to the archive?
[13:18] <sergiusens> didrocks, yup
[13:18] <sergiusens> didrocks, media-hub to be specific
[13:18] <sergiusens> and this is also a request to get that in :-)
[13:20] <didrocks> sergiusens: it needs a regular FFe, then, we just handle it as any new package (so either an empty MP to get it landing or an existing one)
[13:20] <didrocks> sergiusens: you can file the request first in, but please add to the comment that it needs the FFe to be acked
[13:26] <didrocks> tvoss: you can merge and clean btw
[13:26] <tvoss> didrocks, okay
[13:52] <cjwatson> Mirv: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5798790 looks like a proposed-migration blocker
[13:52] <plars> didrocks: we have an issue with the ubuntuuitoolkit tests - on mako there seems to be an issue where it sometimes runs forever (until the job times out after 300 min)
[13:52] <didrocks> plars: oh, interesting, we didn't get any change on the toolkit for that. Is that quite new?
[13:52] <didrocks> bzoltan1: you may have some people too look at that ^
[13:53] <plars> didrocks: ah, wait
[13:53] <plars> didrocks: maybe a false alarm - it looks like it's still on just the custom image
[13:53] <plars> didrocks: for a second I saw that mako was still running and thought we were seeing the same thing on the regular images
[13:55] <didrocks> interesting…
[13:55] <didrocks> plars: keep us posted :)
[13:55] <plars> cwayne was looking into it on custom but if anyone has ideas, could probably use some help
[13:55] <tvoss> didrocks, can I just press merge and clean in the silo?
[13:57] <bzoltan1> didrocks:  let me look at it
[13:57] <didrocks> tvoss: yeah
[13:58] <didrocks> bzoltan1: apparently, cwayne will be your best contact :)
[13:58] <tvoss> didrocks, without setting any options I assume?
[13:58] <bzoltan1> plars: please ping me and paste the logs if you suspect the ui toolkit doing something wromg
[13:58] <didrocks> tvoss: right, no option
[14:05] <cjwatson> Mirv: http://paste.ubuntu.com/7067776/ should fix https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5798788, or at least move onto the next thing - not a proposed-migration blocker but would be awfully nice
[14:07] <Mirv> cjwatson: there was a recent 5.0.2 patch that didn't apply but it seems it can be made to apply.
[14:07] <Mirv> cjwatson: this applies http://pastebin.ubuntu.com/7067786/
[14:08] <Mirv> cjwatson: so maybe I'll apply both?
[14:11] <cjwatson> Mirv: aarch64.patch already has a definition of WTF_CPU_ARM64 (you could pick either but there's no reason to change the existing patch really)
[14:12] <cjwatson> Mirv: and I think it's probably better to match the style of the code the patch would be applying to, which is all __foo__ macros rather than CPU(foo)?
[14:12] <cjwatson> Mirv: it's certainly the same idea though
[14:12] <cjwatson> Mirv: if qtwebkit doesn't have that yet, it'll probably need it too, though
[14:13] <cjwatson> I suppose you might need to care about CPU(ARM64) vs. CPU(AARCH64) if that's exported to other packages; I don't know whether that's so
[14:14] <cjwatson> doesn't really matter which, pick one :-)
[14:21] <Mirv> cjwatson: which aarch64.patch already has WTF_CPU_ARM64? so what I pasted is from https://launchpad.net/ubuntu/+source/qtscript-opensource-src/5.1.1+dfsg-2ubuntu1~really5.0.2+dfsg-3ubuntu1 modified to apply to 5.2.1 qtscript
[14:21] <cjwatson> Mirv: the one you currently have in qtbase
[14:22] <cjwatson> Mirv: sorry, in qtdeclarative
[14:22] <cjwatson> which I ported over from webkitgtk
[14:22] <cjwatson> we've apparently used different names in different places, shrug
[14:22] <Mirv> oh, there!
[14:22] <Mirv> right
[14:23] <cjwatson> probably ought to be consistent within qt* at least :)
[14:23] <Mirv> cjwatson: another problem is that qtdeclarative failed to build on arm64, which wouldn't be a problem otherwise but it's nowadays required by qttools which did build on arm64 before..
[14:24] <davmor2> didrocks: things look okay on the n7 I still need to get my n4 unlocked and it looks like the first of the people who maybe able to help me is now online
[14:25] <cjwatson> Mirv: that was what I gave you the patch above for, http://paste.ubuntu.com/7067776/
[14:25] <didrocks> davmor2: excellent! good luck and cross fingers :p
[14:25] <pmcgowan> didrocks, are you considering a change to the landings order given Qt is still getting fixes
[14:26] <didrocks> pmcgowan: you mean, order like 1, 2… 3 or anything else?
[14:26] <Mirv> cjwatson: ahah, I mistakenly thought it was reated to qtscript first you mentioned earlier. ok, let's see.
[14:26] <pmcgowan> didrocks, like landing mir and scopes before qt for example
[14:26] <didrocks> pmcgowan: basically everything that are not in Qt "lock list" can enters
[14:26] <pmcgowan> didrocks, cool
[14:26] <didrocks> pmcgowan: Mir will be blocked I guess because of unity-mir though
[14:27] <didrocks> (it's in the Qt lock list IIRC)
[14:27] <pmcgowan> maybe it can get unlocked for the time being
[14:27] <didrocks> pmcgowan: totally fine with that, it's just a rebuild for Qt?
[14:27] <didrocks> Let me check
[14:27] <pmcgowan> not sure
[14:27] <cjwatson> I might try another click landing to get a bit more of libclick (manifest extraction and the supported framework stuff)
[14:27] <cjwatson> squeezing that in before Qt would be good
[14:27] <pmcgowan> that would be good
[14:27] <pmcgowan> +1
[14:29] <didrocks> pmcgowan: ok, so unity-mir is just a rebuild
[14:29] <didrocks> pmcgowan: we can easily stick it out, get Mir landing and stick it back
[14:29] <pmcgowan> didrocks, great
[14:29] <didrocks> just Mirv needs to do a manual tracking to remember to rebuild it once Mir is in :)
[14:29] <pmcgowan> yep
[14:29] <pmcgowan> we did that with eds the other day as well
[14:30] <didrocks> yeah, that's easy to do, just need to not forget about it in the bazillon packages :)
[14:31] <didrocks> kgunn: you want to make a Mir landing tentative?
[14:32] <kgunn> didrocks: yes!
[14:32] <kgunn> thankyou!
[14:32] <didrocks> kgunn: the line request is up to date?
[14:33] <didrocks> Mirv: mind if I remove unity-mir from you, as discussed? ^
[14:33] <ogra_> [14:33] <ogra_> (now including all arches etc)
[14:34] <pmcgowan> nice
[14:34] <didrocks> ogra_: great!
[14:34] <ogra_> so the long tarball genersation due to the diff being gigantic after two weeks was the issue
[14:34] <ogra_> it caused some "stepping on my own toes" in the tools
[14:35] <balloons> wahoo!
[14:35] <didrocks> kgunn: ready is set to "No", on purpose?
[14:37] <davmor2> \o/ \o/ \o/
[14:39] <sil2100> \o/
[14:39] <didrocks> Mirv: unconfigured unity-mir then
[14:40] <didrocks> ah, will need to unconfigure u-s-c as well
[14:44] <didrocks> sil2100: Mirv: ok, I unlocked unity-mir and unity-system-compositor Qt 5.2 landing. I kgunn ack the Mir landing line, please assign to him
[14:44]  * didrocks is going for a run now
[14:49] <kgunn> didrocks: sorry...was in a meeting
[14:49]  * kgunn looks to catchup
[14:49] <rsalveti> popey: have a bug number for the emulator issue?
[14:49] <rsalveti> popey: downloading the latest and will check
[14:49] <popey> rsalveti: tried multiple times and got black screen first few times then it worked the last time annoyingly
[14:49] <kgunn> didrocks: fixed the sheet
[14:53] <rsalveti> popey: alright, guess just the usual issue with qemu not bringing up everything sometimes
[14:54] <rsalveti> cjwatson: Mirv: not sure if helps, but marcin had a few arm64 patches for qt5.2 as well: https://bugzilla.redhat.com/show_bug.cgi?id=1056051 https://bugzilla.redhat.com/show_bug.cgi?id=1056071 https://bugzilla.redhat.com/show_bug.cgi?id=1056160
[14:56] <cjwatson> probably similar/overlapping
[14:57] <rsalveti> yeah, at least the last 2 are already upstream as well
[14:58] <sil2100> didrocks: ok
[15:03] <rsalveti> davmor2: popey: did we have a bug for the delay when enabling/disabling speaker mode?
[15:03] <rsalveti> sil2100: didrocks: thanks for creating the silo for 46 btw
[15:03] <kgunn> Mirv: sil2100 ...can you reconfig silo2 ? i add one more MP back into the list
[15:04] <sil2100> kgunn: ok
[15:04] <sil2100> rsalveti: no problem
[15:05] <davmor2> popey: did we modify your original sound loud speaker doesn't work bug?
[15:05] <sil2100> kgunn: can I reconfigure already or are you still adding?
[15:05] <kgunn> sil2100: yeah, sorry, just hit enter...now try :)
[15:05] <popey> davmor2: my what?
[15:06] <sil2100> ;)
[15:07] <davmor2> popey: you filed a bug for loud speaker not working did we modify that when both of us got it to work but delayed?
[15:07] <popey> pass
[15:08] <pmcgowan> davmor2, there is a bug on the delay, forget against which package
[15:08] <davmor2> rsalveti: ^
[15:08] <davmor2> pmcgowan: thanks I thought there was too :)
[15:08] <rsalveti> pmcgowan: remember the number?
[15:09] <pmcgowan> rsalveti, not off hand, I can look
[15:09] <davmor2> rsalveti: more than 1, less than a billion, does that help lower it down?
[15:09] <rsalveti> davmor2: not much lol
[15:10] <pmcgowan> rsalveti, davmor2 https://bugs.launchpad.net/dialer-app/+bug/1277765
[15:10] <rsalveti> pmcgowan: awesome, thanks
[15:11] <davmor2> pmcgowan: thanks
[15:37] <rsalveti> pmcgowan: davmor2: popey: mind help testing https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/ ? (alsa-lib, fix the delay when enabling/disabling speaker-mode)
[15:37] <rsalveti> didrocks: sil2100: guess I also need someone from the ci team to give it a try as well :-)
[15:38] <davmor2> rsalveti: I'm working on my issue with mir right now.
[15:40] <cjohnston> /3/17
[15:44] <sil2100> rsalveti: what's up?
[15:44] <sil2100> rsalveti: the alsa one?
[15:44] <sil2100> :)
[15:48] <rsalveti> sil2100: yes
[16:00] <bregma> sil2100, could I get a silo for line 42 please?
[16:01] <sil2100> bregma: let me take a look
[16:02] <seb128> bregma, sil2100: you probably want "gnome-screensaver" in the column G
[16:23] <sil2100> bregma: is the FFe accepted? Can you point me to the bug?
[16:26] <cjwatson> Mirv: at least qtdeclarative is down to tedious symbols stuff now ...
[16:26] <cjwatson> so close :)
[16:29] <bregma> sil2100, FFe bug is https://bugs.launchpad.net/unity/+bug/1282798
[16:30] <bregma> being review still, obviously we won't land the silo before it's approved
[16:33] <sil2100> bregma: right, I didn't see a Triaged yet
[16:33] <sil2100> bregma: is it important that we have it built for the FFe to be reviewed?
[16:35] <bregma> sil2100, better to ask Laney
[16:35] <Laney> You can build it, that allows for testing
[16:36] <Laney> just don't put it in trusty
[16:36] <sil2100> Laney, bregma: I'll assign a silo and mention it in the comment
[16:40] <sil2100> Damn, good that CITrain is smart!
[16:41] <kgunn> sil2100: hey...would you be the right person to approve/add...the following
[16:41] <kgunn> http://summit.ubuntu.com/uds-1403/kgunn72/meetings
[16:42] <sil2100> Oh, shock, it seems I do have the power
[16:48] <sil2100> bregma: assigned a silo, you can build ;)
[16:49] <rsalveti> pmcgowan: sil2100: landing 46 (https://launchpad.net/~ci-train-ppa-service/+archive/landing-001) is working as expected, would just like someone else to give it a try before getting it published (as we're in degraded mode)
[16:49] <sil2100> rsalveti: upgrading on my device
[16:49] <rsalveti> great
[17:00] <sil2100> rsalveti: did most of the testing from the testing plan and I think it seems ok
[17:00] <popey> didrocks: "You're not allowed to join this video call."
[17:01] <ogra_> popey, use the right account then :P
[17:01]  * ogra_ has to wrangle with that once a week
[17:01] <popey> i am
[17:01] <didrocks> weird…
[17:01] <popey> i use two browsers
[17:01] <rsalveti> sil2100: great, can we land it already? or should we wait
[17:02]  * popey invited himself to the meeting
[17:04] <davmor2> didrocks: https://bugs.launchpad.net/mir/+bug/1290416
[17:07] <rsalveti> davmor2: wonder if this might be the issue that was fixed for mwc
[17:07] <rsalveti> kgunn: should know more
[17:07] <rsalveti> but I know we had a screen freeze there as well
[17:08] <sil2100> rsalveti: oh, you forgot to push 'build' with 'watch only' for the silo ;)
[17:08] <sil2100> rsalveti: want me to do that?
[17:10] <kgunn> davmor2: mir hasn't changed since ~Feb20
[17:10] <kgunn> davmor2: does your image include Qt5.2 ?
[17:10] <kgunn> (sorry i need a decoder ring :)
[17:10] <davmor2> kgunn: no
[17:11] <davmor2> kgunn: kdub and AlbertA are happy that they have starting point on that bug now
[17:12] <kgunn> ack...
[17:12] <davmor2> kgunn: this has only been happening since R226
[17:12] <davmor2> kgunn: which is the promoted image from Friday
[17:13] <kgunn> davmor2: hmmm...what was big landing there ? anyone know ?
[17:14] <davmor2> kgunn: pretty much everyone now but I've not long finished adding all the debug stuff to the bug for your guys to work with :)
[17:14] <ogra_> plars, could someone look at the messaging-app tests on the tablets ? it looks like ofono-phonesim is not installed when they run
[17:14] <davmor2> kgunn: hence giving didrocks the bug number for the daily release report ;)
[17:15] <kgunn> davmor2: ack...just trying to square what you are describing as a "mir regression"..but we haven't released a new mir :)
[17:16] <kgunn> AlbertA: kdub ^
[17:16] <sil2100> rsalveti: I'll do it then and publish
[17:16] <davmor2> kgunn: no not a regression but it has only been noticeable since R226  :)
[17:16] <AlbertA> kgunn: yeah it's still 0.1.5
[17:17] <AlbertA> kgunn: areas of suspect from the logs are snapshooting
[17:17] <AlbertA> kgunn: and a possible deadlock during sessionDestroyingSurface
[17:18] <kgunn> AlbertA: ah...so this is the old mwc bug
[17:19] <AlbertA> kgunn: oh this was known?
[17:20] <kgunn> AlbertA: yeah...but just hung up on "process" itself :)...its fixed on dev
[17:20] <davmor2> kgunn: ah cool :)
[17:24] <bregma> sil2100, I don't see a silo for line 42 no matter how many times I refresh, did I miss something?
[17:28] <robru> kgunn, just checking in. I'm all yours for the next 8 hours if you need any help with the Mir landing.
[17:29] <kgunn> robru: thanks...working on damn mp conflicts now!...arg
[17:29] <robru> kgunn, yeah, i noticed that ;-)
[17:34] <sil2100> didrocks: ok, so it seems cyphermox freed the silo
[17:34] <sil2100> bregma: ^
[17:34] <didrocks> sil2100: yeah, what I told you, I guess he did this because of the unack FFe
[17:34] <sil2100> cyphermox: so, Laney as the reviewer of the FFe approved the assignment of the silo for testing purposes
[17:35] <Laney> haha
[17:35] <Laney> I don't want to be known as 'the reviewer' please
[17:35] <sil2100> cyphermox: I made the comment red to make sure it doesn't land before ACKing the FFe itself
[17:35] <Laney> anyone on the RT can look at any request
[17:35] <Laney> I just think it's sensible to be able to test it
[17:35] <sil2100> Laney: ok ;) But I saw you being the most active on that bug
[17:36] <cgoldberg> robru, cyphermox, any chance of getting a silo allocated for line 47 today? (Autopilot)
[17:36] <sil2100> cyphermox, didrocks: you think we can re-add that silo, or you want to leave it unassigned?
[17:36] <cgoldberg> i was unable to make landing meeting earlier
[17:36] <robru> cgoldberg, I can assign it
[17:36] <sil2100> It's fine either way for me, but as Laney mentioned, it might be easier to test for people actually
[17:37] <cgoldberg> robru, great thanks
[17:37] <didrocks> sil2100: please readd
[17:37] <didrocks> robru: try to decouple the Mir and autopilot landing please
[17:37] <robru> didrocks, yes ;-)
[17:37] <didrocks> like having an image just with one, and an image with the other
[17:37] <didrocks> thanks!
[17:38] <robru> cgoldberg, yeah, I have to try not to land mir and autopilot too close together
[17:38] <didrocks> cgoldberg: I don't think autopilot-qt though
[17:38] <didrocks> cgoldberg: remember that both autopilot and autopilot-qt were reverted
[17:38] <robru> cgoldberg, ok you got silo 5, please build
[17:38] <didrocks> due to the regression
[17:38] <didrocks> are they fixed?
[17:38] <sil2100> cyphermox: ^ please don't unassign for now ;)
[17:39] <cgoldberg> didrocks, yes afaik
[17:39] <didrocks> cyphermox: apparently, the release team wants to test built packages before +1 or -1
[17:39] <didrocks> cgoldberg: so, why autopilot-qt isn't part of the landing?
[17:40] <cgoldberg> didrocks, one sec.. let me go through email and see whats up with autopilot-qt
[17:40] <didrocks> robru: please don't release before this is cleared out ^
[17:40] <robru> didrocks, ok. i plan to do mir first anyway
[17:41] <sil2100> bregma: the silo is back - silo 008 now
[17:41] <sil2100> Ok guys, I drive home now - see you around!
[17:41] <robru> sil2100, good night!
[17:41] <didrocks> see you sil2100 :)
[17:45]  * didrocks waves good evening as well now
[17:45] <didrocks> cgoldberg: keep us posted on the ML as well (the whole LT)
[17:45] <didrocks> thanks
[17:54] <rsalveti> kgunn: davmor2: it's probably related with 4.4
[17:54] <rsalveti> kgunn: that's why I said it should be similar with the issue we had with the mwc demo image
[17:55] <rsalveti> so the only thing that changed is the hwcomposer
[17:55] <rsalveti> as it's using a different version now, so mir might still have issues with it (hwcomposer 1.2)
[18:02] <sergiusens> robru, can I get a silo for l50?
[18:03] <robru> sergiusens, sure
[18:03] <davmor2> rsalveti: that's fine if there is already a fix that is awesome :)
[18:04] <davmor2> rsalveti: if all my logs and everything provided was confirmation that the bug is the same then it doesn't feel like a complete waste of a day :)
[18:04] <robru> sergiusens, ok, you got silo 9, please build
[18:04] <rsalveti> davmor2: sure
[18:04] <sergiusens> ty
[18:05] <robru> you're welcome!
[18:09] <sergiusens> robru, one more for l51 if you don't mind
[18:10] <robru> sergiusens, is the py3 stuff backwards compatible? or are you breaking py2 there?
[18:10] <sergiusens> robru, it's backwards compatible
[18:10] <robru> sergiusens, great ;-)
[18:11] <sergiusens> robru, but; that's why we need to run agains everything currently under the ci image test anyways to make sure
[18:11] <robru> sergiusens, right
[18:11] <robru> sergiusens, ok, you got silo 10, please build
[18:11] <sergiusens> I intend to ping doanac` for that; tsk :-)
[18:12] <robru> seb128, do you need me to publish silo 7? I forget if you can publish or not
[18:12] <seb128> robru, just did, thanks
[18:12] <robru> seb128, great
[18:14] <davmor2> psivaa, plars: you guys around now?
[18:14] <psivaa> davmor2: hello
[18:15] <plars> davmor2: yes
[18:15] <davmor2> psivaa, plars: If you are both about could we have a 5 minute hangout?
[18:15] <plars> sure
[18:16] <davmor2> psivaa, plars: https://plus.google.com/hangouts/_/7ecpj08l3ar12lr9julchs3cvc?hl=en-GB
[18:17] <plars> davmor2: it says I'm not allowed to join
[18:17] <davmor2> plars: it's a canonical one
[18:18] <kgunn> sorry...had some internet monkey biz... davmor2 kdub AlbertA rsalveti ...the free bug is this one, and has a fix in 0.1.6...which i'm trying to land right now
[18:18] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1281728
[18:18] <plars> davmor2: I'm logged into two accounts - it's never been a problem before though
[18:18] <davmor2> plars: :(
[18:19] <davmor2> psivaa: is in so I don't know what the issue is
[18:19] <davmor2> plars: ^
[18:19] <plars> davmor2: give me a sec
[18:19] <davmor2> kgunn: fantastic so when the new version lands everythign should be back to normal then right?
[18:20] <plars> davmor2: can you invite me?
[18:20] <kgunn> davmor2: unless its a new bug...in which case all my wonderings about no-new-mir are meaningful :)
[18:22] <rsalveti> kgunn: are we still trying to land mir before qt 5.2?
[18:22] <kgunn> rsalveti: so i have mir building in silo 002 atm
[18:23] <kgunn> i know 5.2 is special...so not completely sure how to answer your question :)
[18:23] <robru> rsalveti, oh yes, the plan is to land mir today, and qt5.2 "sometime this week" (when it's ready)
[18:24] <kgunn> robru: so..i just lost console on silo002....but i assume the build is still going ?
[18:24] <kgunn> clicking on console view give me a "service temporarily unavailable"
[18:24] <sergiusens> robru, I just got a 503 from jenkins/train, is it only m?
[18:24] <robru> kgunn, dear god...
[18:24] <sergiusens> ah
[18:25] <sergiusens> not only me then...
[18:25] <robru> kgunn, your builds are still here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/+packages
[18:25] <rsalveti> great then
[18:25] <robru> not sure where jenkins wentthough
[18:25] <robru> cyphermox is the only person who has the access to fix this at this time of day.
[18:27] <sergiusens> doanac`, can you run https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28 with utah/ci?
[18:29] <doanac`> sergiusens: ack.
[18:31] <sergiusens> doing the same, but without utah
[18:31] <kgunn> robru: so...looks like none of those packages actually published
[18:31] <kgunn> failed on dep waits...
[18:31] <robru> kgunn, amazing
[18:32] <robru> kgunn, how did they both fail? the ppa build should not be affected by jenkins going down (jenkins just monitors the builds, they are standard PPA builds handled by launchpad)
[18:32] <doanac`> sergiusens: NOTE: we aren't using utah for touch testing anymore, but i'm still running it through our ci scripts here: http://q-jenkins:8080/job/andy-smoke-daily-test/3/console
[18:34] <kgunn> robru: gotta run for lunch...bbiab
[18:35] <sergiusens> doanac`, oh, interesting; thanks for the detail
[18:36] <robru> kgunn, so lp:mir never got uploaded to the silo.
[18:38] <robru> kgunn, and therefore everything that depended on it is stuck in depwait
[18:39] <robru> kgunn, i am literally powerless to fix this until cyphermox gets here to reboot jenkins. he just told me he'll be available in a few minutes though
[19:04] <cyphermox> just started jenkins
[19:05] <cyphermox> sorry, I was stuck in traffic
[19:06] <cyphermox> robru: kgunn: jenkins is back up
[19:17] <robru> cyphermox, thanks
[19:21] <robru> kgunn, i started a rebuild for you
[19:31] <thomi> robru: cyphermox: are one of you two gentlemen able to explain to me why this build job failed please? http://<IP_ADDRESS>/job/landing-005-1-build/57/console
[19:31] <robru> thomi, checking
[19:31] <thomi> There's a 'warning' message at the end of the console, but since it's a warning (and not an error) I'm not sure if that's why the build failed
[19:31] <thomi> also, the message doesn't make sense to me at all
[19:32] <thomi> I think maybe it's due to didier's reverting the package in distro
[19:32] <robru> thomi, yep, that warning is exactly why it failed.
[19:32] <robru> thomi, and also yes, a revert in distro would cause that.
[19:32] <thomi> ok - that message *really* should be an error then... but anyway... how do I fix it?
[19:32] <robru> thomi, so what you need to do is grab the debian/changelog from distro and just copy that changelog entry into one of the MPs for the project, then once changelog matches distro then the build will proceed
[19:33] <thomi> robru: OK, gotchya, thanks.
[19:33] <robru> thomi, you're right though, it's weird that it's just a warning but then it fails on that... should be an error
[19:33]  * thomi adds this bit of information to his ci-train manual
[19:35] <robru> rsalveti, seb128 : hope I'm not stepping on your toes but I merged silos 1, 3, and 7 for you.
[19:35] <rsalveti> robru: that's fine, thanks
[19:37] <robru> sergiusens, status is wrong in spreadsheet, silos 9 and 10 are both done building if you want to start testing
[19:39] <sergiusens> robru, yeah, started a bit back when I saw the ppa finished buildinf :-)
[19:39] <sergiusens> thanks btw
[19:39] <robru> sergiusens, you're welcome
[19:40] <robru> ok, everything looks good for now as far as I can tell, I'm going to take lunch, should be back within an hour, feel free to ping me if you need anything.
[19:57] <seb128> robru, that's ok, thanks
[19:59] <popey> 36
[19:59] <popey> bah
[20:00] <bregma> rsalveti, I need someone to upload a package to a silo and it looks like you're the only one around who can help at the moment ... willing?
[20:00] <rsalveti> bregma: sure, what's up?
[20:01] <bregma> rsalveti, I need http://people.ubuntu.com/~3v1n0/Lockscreen-GS/ uploaded to ppa:ci-train-ppa-service/landing-008 (after properly setting the release in d/changelog) if you could
[20:03] <rsalveti> bregma: sure, 1 sec
[20:09] <rsalveti> bregma: building
[20:12] <bregma> rsalveti, thanks
[20:24] <bregma> robru, cyphermox, could I get a silo assigned to line 52 please?
[20:24] <cyphermox> most certainly sir
[20:28] <cyphermox> bregma: landing-001
[20:28] <bregma> woo hoo, thanks
[20:54] <robru> ok, i'm back for landings now
[20:58] <robru> kgunn, just checking on mir, looks like the last rebuild i started failed due to a bunch of depwaits, but the good news is that mir itself got uploaded and built successfully. I suspect if we just force yet another rebuild, it should all work.
[20:59] <kgunn> robru: yep...or target build unity-mir, papi, usc
[20:59] <robru> kgunn, right, we should start target building mir first ;-)
[21:00] <kgunn> robru: yeah...its weird, i thot it should do it all in order of the MP's
[21:00] <kgunn> e.g. mir mp is first
[21:02] <robru> kgunn, yeah, i thought that was the case as well, but when I looked deeper into it, it seems to only respect the order within projects (eg, multiple MPs against papi will get merged in the right order) but the actual order of projects is completely arbitrary. not even alphabetical, it looks like they're stored in a python dict and then uploaded in python-dict-access-order, which is essentially unpredictable
[21:16] <dobey> seems like something needs to apply all the patches to everything in the silo, then generate a package build dependency graph, get the source package for each binary bulid-depends, and see if it is one of the things in the silo, and build things in the silo in the appropriate order according to the dep chain
[21:16] <dobey> but that is incredibly complex to do :)
[21:41] <robru> dobey, yeah, easier would be if it just built them in the damn order that we put the MPs ;-)
[22:13] <robru> kgunn, how's testing mir going? need a hand?
[22:14] <kgunn> robru: was just about to begin...but yeah, if you're interested...
[22:14] <robru> kgunn, yeah ;-)
[22:14] <robru> kgunn, so I just installed the silo contents on my mako, rebooted, and it won't boot. somewhat troubling...
[22:14] <kgunn> robru: hmmm...that is no good...
[22:14]  * kgunn gets a little worried
[22:14] <robru> kgunn, just gets stuck at the 'Google' screen with the little unlock icon
[22:17] <robru> kgunn, hummm, reflashing didn't fix it. bootstrapping now
[22:17] <robru> kgunn, any luck on your end?
[22:26] <bregma> robru, do me a favour and find a silo for line 53 when you get the chance?
[22:26] <robru> bregma, webapps? my pleasure!
[22:27] <robru> bregma, ok, you got silo 3
[22:27] <bregma> thanks muchly
[22:27] <robru> you're welcome!
[22:30] <robru> kgunn, is it possible that simply installing all binary packages present in the silo can result in a broken system? is there a certain subset of packages I should be installing in order to test this properly?
[22:31] <kgunn> robru: so you do have to have all those packages together for sure
[22:31] <kgunn> robru: i gotta run... i forgot about family dinner...bbiab...
[22:32] <robru> kgunn, ok, i'll keep poking at it
[22:32] <robru> kgunn, I'm gonna take a wild guess and say that installing ubuntu-desktop-mir on the phone was probably a mistake ;-)
[22:40] <robru> kgunn, hummm, now I can get past the Google screen, but it just boots into a black screen now. pressing the power button visible toggles from "screen on but black" vs "screen off". can't get unity8 to appear
[22:43] <robru> kgunn, ping me when you're back. not sure how to proceed
[22:53] <doanac`> sergiusens: here are the results from running that phablet-tools branch: http://q-jenkins:8080/job/andy-smoke-daily-test/3/#showFailuresLink
[22:53] <sergiusens> doanac`, yeah, was just seeing them
[22:54] <doanac`> not sure which failures you expected and which you didn't. music app seems to not have run at all
[22:54] <sergiusens> doanac`, calendar is expected; I forgot we needed a new image build for that
[22:54] <sergiusens> doanac`, and gallery unexpected but easy to fix in any case
[22:54] <doanac`> sergiusens: great. let me know, and I can re-run for you any time
[22:54] <sergiusens> doanac`, thanks, and will do!