=== matsubara is now known as matsubara-afk
=== michaelh is now known as michaelh|away
=== michaelh|away is now known as michaelh
=== michaelh is now known as michaelh|away
[07:58] <a-l-e--> hi
[07:58] <a-l-e--> i could create a ppa and upload it to my launchpad account
[07:58] <a-l-e--> now, i want to update the package...
[08:00] <a-l-e--> i've updated the source code from the git repository...
[08:01] <a-l-e--> exported it to a zip file...
[08:04] <a-l-e--> created a new folder next to the one where i've put the "older" source code when creating a ppa, with a new name matching the current timestamp:
[08:04] <a-l-e--> scribus-git-indic-1.5.0git.indic201209271000
[08:05] <a-l-e--> copied the debian/ directory from the old scribus-git-indic* directory to the new one...
=== rvba is now known as Guest78352
[08:14] <a-l-e--> added a log entry...
[08:15] <a-l-e--> ... is everything correct until now?
=== michaelh|away is now known as michaelh
=== michaelh is now known as michaelh|away
=== michaelh|away is now known as michaelh
=== _rvba is now known as rvba
=== michaelh is now known as michaelh|away
=== issyl0 is now known as Guest85093
=== Guest85093 is now known as issyl0
[11:34] <geser> wgrant: where should the "all"-part of "Architecture: all armel" get build? on i386, right? see also https://launchpadlibrarian.net/117435196/buildlog_ubuntu-quantal-i386.fso-frameworkd_0.9.5.9%2Bgit20110512-4_FAILEDTOBUILD.txt.gz
[11:37] <wgrant> geser: Bug #690428
[11:37] <ubot5> Launchpad bug 690428 in launchpad-buildd "FTBFS due to arch check failing to match Architecture: "all" at sbuild time" [Low,Triaged] https://launchpad.net/bugs/690428
[11:37] <geser> this also leads to the somewhat weird situation where fso-frameworkd-gta0{1,2} get build on armel and published but fso-frameworkd doesn't get build at all the currently published version is from the previous upload/build (uploaded/build in karmic)
[11:38] <wgrant> I'm not sure if modern non-LP sbuild supports that situation these days, but two years ago it didn't.
=== matsubara-afk is now known as matsubara
=== Guest32361 is now known as slank
=== slank is now known as Guest2828
=== sagaci_ is now known as sagaci
=== slank is now known as Guest55818
[16:11] <ttx> Hey guys, looks like I built a milestone page that is just too big for Launchpad (too many bugs and blueprints targeted), it always timeouts
[16:11] <ttx> https://launchpad.net/nova/folsom/2012.2
[16:28] <ttx> flacoste: any idea how we can work around that ?
[16:29] <flacoste> ttx: we can increase the timeout on the page, or you could reduce the number of bugs and blueprints linked ;-)
[16:29] <ebergen> fix bugs :)
[16:30] <ttx> ebergen: well, they are all FixReleased ;)
[16:30] <ttx> flacoste: if increasing the timeout is an option, that would be great
[16:30] <ttx> we like to show off with lists of bugs and blueprints completed
[16:30] <ebergen> it didn't time out for me
[16:31] <ebergen> that is an impressive list
[16:31] <ttx> ebergen: quick let me try so that I benefit from your cache
[16:31] <flacoste> jcsackett: can you take care of increasing the timeout on the milestone page please? as it's timing out for openstack and their folsom release
[16:31] <ttx> ebergen: still fail for me
[16:31] <ebergen> let me try when I'm logged in
[16:31] <ebergen> without being logged in it takes 8 seconds
[16:32] <ebergen> now it times out
[16:32] <ttx> jcsackett: for reference: https://launchpad.net/nova/folsom/2012.2
[16:32] <ebergen> interesting
[16:33] <ebergen> while logged in it times out after about 7 seconds
=== matsubara is now known as matsubara-lunch
[16:33] <ebergen> now dead :(
[16:34] <jcsackett> flacoste: sure. right now timeout is set 6000, try 9000 you think?
[16:34] <flacoste> jcsackett: yes, we probably don't want to increase it too much
[16:35] <flacoste> jcsackett: thanks!
[16:35] <jcsackett> flacoste: yw. i'm listing you as the approval in the request. that cool?
[16:35] <ebergen> I also approve :)
[16:36] <flacoste> jcsackett: of course!
[16:49] <jcsackett> ebergen, ttx, flacoste: request is in. will ping you when it's live.
[16:49] <ttx> jcsackett: thx!
=== Guest75974 is now known as dpb___
[17:02] <smallfoot-> what does FFe mean?
[17:02] <ttx> smallfoot-: FeatureFreeze exception
[17:03] <smallfoot-> ok thx
[17:23] <dobey> is there any way to acces /+apidoc/ directly from a subdomain?
[17:26] <jcsackett> ebergen, ttx: timeout increased. give it a try.
[17:26] <ebergen> nope :(
[17:27] <ebergen> still takes 3 or 4 tries
[17:28] <jcsackett> flacoste: ^
[17:28] <dobey> or can someone fix the +apidoc css to have body { font-size: 12px; } like the rest of launchpad.net seems to have?
[17:28] <ebergen> then it does load it only takes a few seconds
[17:28] <jcsackett> ebergen: right; previous hits are just warming it up.
[17:29] <jcsackett> ebergen: guess i'll see about incrementing it further.
=== matsubara-lunch is now known as matsubara
[17:53] <flacoste> jcsackett: might be worth a look at actually fixing the underlying bug
[17:54] <flacoste> jcsackett: but we could increase the time to 15 in the mean time
[18:07] <jcsackett> flacoste: yeah, we have a bug for it and sinzui and i were talking about fixes.
[18:08] <jcsackett> flacoste: i think we'll probably be motivated to move on that now.
[18:15] <jcsackett> ttx, ebergen: we've temporarily set the timeout at 15; for me, it's still timing out. i'm going to begin work on the underlying issues.
[18:15] <ebergen> I don't think that is the right timeout because it times out in about 7 seconds for me
[18:18]  * jcsackett looks
[18:32] <ttx> jcsackett: yeah, same here, timeouts after 7 sec
[18:32] <ttx> maybe a released milestone has a different reference frmo an unreleased one
[18:34] <ttx> jcsackett: lifeless pointed to https://bugs.launchpad.net/launchpad/+bug/736010
[18:34] <ubot5> Ubuntu bug 736010 in Launchpad itself "Milestone:+index timeouts" [Critical,Triaged]
[18:34] <jcsackett> ttx: yes, that's the bug i'm looking at. it's part of purple's critical list.
[18:35] <lifeless> jcsackett: flacoste: I don't think the timeout will work :)
[18:35] <lifeless> its bad O python code
[18:35] <lifeless> and when python goes bad, it goes way bad :)
[18:35] <jcsackett> lifeless: oh goodie.
[18:36] <ttx> sorry for pushing that page over the limit :)
[18:36] <lifeless> jcsackett: see the time breakdown in the oops - 400ms sql, 6 seconds python
[18:36] <jcsackett> for what it's worth, i was indeed looking at the wrong timeout; ProjectMilestone vs Milestone
[18:36] <ttx> jcsackett: so increasing the timeout should still help, I guess
[18:37] <ttx> even if the bug should be fixed in any case
[18:37] <jcsackett> ttx: oh yes, the bug is going to be fixed. i don't like leaving a timeout limit as a solution.
[18:37] <lifeless> jcsackett: so for this
[18:37] <lifeless> jcsackett:  have a look a tthe sql statement log
[18:37] <lifeless> jcsackett: there are no long sql statements, but you can still infer interesting things
[18:53] <jcsackett> ttx, ebergen: try now. ebergen was correct, i was misreading the timeout rules.
[18:53] <jcsackett> it now loads for me.
[18:54] <ttx> jcsackett: works now, awesome
[18:54] <ttx> Thanks for the quick fix!
[18:55] <lifeless> OOPS-cd08a4707c43e68373197833bb4d271c
[18:55] <ubot5> https://oops.canonical.com/?oopsid=cd08a4707c43e68373197833bb4d271c
[18:59] <ebergen> now it works
=== yofel_ is now known as yofel
=== michaelh|away is now known as michaelh
[20:19] <cmars232> ajax not working on launchpad... how come?
[20:25] <lifeless> cmars232: more details needed
=== michaelh is now known as michaelh|away
[20:27] <cmars232> lifeless: sorry.. when i click on the yellow edit links, they usually open an ajaxy popup. today they have mostly been loading a different edit page. for example, if i want to change the status of a bug
[20:28] <cmars232> lifeless: it's not consistent though, i've gotten the popups a few times, but not very often
[20:30] <lifeless> give me an example of a page that isn't working for you please
[20:32] <cmars232> lifeless: https://bugs.launchpad.net/ztrustee/+bug/1033527
[20:32] <ubot5> Error: ubuntu bug 1033527 not found
[20:32] <cmars232> lifeless: private project
[20:33] <lifeless> ah
[20:33] <lifeless> I won't be able to test there then I suspect
[20:33] <cmars232> let me see if a public one does it
[20:33] <cmars232> lifeless: public project doesn't have this problem
[20:34] <cmars232> lifeless: at least, not the one i own
[20:34] <lifeless> ok, so its likely something specific to private projects
[20:34] <lifeless> cmars232: please file a bug
[20:35] <lifeless> cmars232: bugs.launchpad.net/launchpad/+filebug
[20:40] <cmars232> lifeless: done, https://bugs.launchpad.net/launchpad/+bug/1057752
[20:40] <ubot5> Ubuntu bug 1057752 in Launchpad itself "AJAX not working for private projects" [Undecided,New]
[20:40] <lifeless> thanks
[20:41] <beuno> seems that in the case of merge proposals
[20:41] <beuno> you can't set pre-req branches due to this
[20:41] <beuno> http://ubuntuone.com/2UTX2yREfhc58B7Xs3Zb0i
=== michaelh|away is now known as michaelh
[21:03] <cody-somerville> It seems it isn't all AJAX that is broken - just modal dialogues aren't working.
[21:06] <cody-somerville> or at least certain ones
[21:06] <cody-somerville> newer ones don't seem to be affected
[21:11] <lifeless> I'm going to guess that sinzui will be siccing wallyworld__ on it, but its only a guess.
[21:11] <sinzui> I think privacy banner is the cause
[21:11] <sinzui> I just dupe two bugs against the one I reported/experienced
[21:34] <wallyworld__> lifeless: why my fault? i found an issue yesterday with our js (not me) and put up a branch for review to fix it
[21:36] <lifeless> wallyworld__: I didn't say or suggest it was your fault.
[21:36] <lifeless> wallyworld__: you seem to get a lot of the js work in your squad, I was making an educated guess about who would be likely to be scheduled onto this issue.
[21:36] <wallyworld__> i should have included a :-)
[21:36] <wallyworld__> np, sorry
[21:37] <wallyworld__> i miss interpreted what siccing meant
[21:37] <lifeless> no worries
[21:37] <lifeless> sorry for the confusion
[21:37] <wallyworld__> np, i only just woke up, so my brain is still fuzzy
[21:37] <wallyworld__> although some might argue it never changes
[21:38]  * wallyworld__ goes to buy a dictionary
[21:39] <sinzui> wallyworld__ I think rich_h's changes to the privacy banner are the cause
[21:39] <wallyworld__> sinzui: yes, my branch fixed those
[21:39] <wallyworld__> landing now
[21:46]  * sinzui awards wallyworld__ 5 gold stars ★★★★★