[07:45] <dednick> Saviq: re: active call indicator - I'm going into the office tomorrow to show designers what I've got. If they're happy, we're happy.
[07:47] <Saviq> dednick, kthxbai
[07:51] <Saviq> tsdgeos, hey, one more chevron is too big - the "go back to parent" one
[07:51] <tsdgeos> ah right
[07:51] <tsdgeos> too many of them
[07:53] <tsdgeos> pused
[07:53] <tsdgeos> +h
[07:53] <dednick> what's with the freaky new indicators on desktop...
[07:53]  * Saviq reboots
[07:54] <dednick> they're like... buttons.
[07:56] <Saviq> dednick, sounds like you lost the theme? look the same here...
[07:56] <dednick> Saviq: yeah. that would probably track with what i'm seeing in other apps...
[08:02] <Saviq> mhr3, hey, do you know if it's on purpose that there's only headerless categories in the amazon scope now?
[08:04] <Saviq> mhr3, also, it seems the dept hierarchy in amazon is rather fragile... I just ended up in a category with no depts :|
[08:05] <Saviq> mhr3, although it looks like the query was good http://paste.ubuntu.com/7667799/ :|
[08:10] <mhr3> Saviq, what category was that?
[08:10] <mhr3> too much stuff in the log
[08:10] <Saviq> mhr3, the last one
[08:11] <Saviq> mhr3, I pasted the log as I was looking at a category with no depts
[08:11] <Saviq> tsdgeos, are we confident in childrenRect.height? wasn't it the case that it didn't update with the children changing size?
[08:11] <tsdgeos> hmmmm
[08:12] <Saviq> tsdgeos, I'm not seeing any artifacts of that in the behaviour, just asking
[08:12] <tsdgeos> i think there may be a problem if it shrinks
[08:12] <tsdgeos> don't recall right now
[08:12] <tsdgeos> but everywhere i've used lately seemed to work fine
[08:12] <Saviq> tsdgeos, now I remember
[08:13] <Saviq> tsdgeos, it was a specific case where anchors made the children grow, but shrinking didn't go back due to the children actually keeping the grown size
[08:14] <Saviq> tsdgeos, I'd have to think again to remember exactly what was happening, but yeah, it was some circular dep basically
[08:14] <tsdgeos> yeah i've seen that
[08:15] <tsdgeos> some min of childrenrect and stuff
[08:15] <tsdgeos> and then the parent makes the child big
[08:15] <tsdgeos> don't remember the exact sceneario either
[08:16] <tsdgeos> Saviq: just pushed a fix for swipe down to close two finger
[08:16] <tsdgeos> when you have time
[08:16] <Saviq> tsdgeos, great, thanks
[08:17] <Saviq> aaargh f*cking disappearing firefox... who broke unity :|
[08:19] <tsdgeos> my internet is specially unstable today :/
[08:19] <Saviq> tsdgeos, we need a bit more margin between the "go back" chevron and the label
[08:20] <Saviq> https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/toolkit/2-navigation/02_Amazon_nav-01.jpg
[08:21] <tsdgeos> ok
[08:21] <tsdgeos> can do
[08:23] <tsdgeos> Saviq: i'm going to 0.5gu
[08:23] <tsdgeos> i know you hate decimal gus
[08:23] <Saviq> tsdgeos, .5 is fine
[08:23] <tsdgeos> but we're always going to have pxtogu > 2
[08:24] <tsdgeos> so it should work
[08:24] <tsdgeos> pushed
[08:24] <Saviq> tx
[08:33] <Saviq> arg
[08:36] <mhr3> Saviq, can't rep, you're getting different deps than in uk
[08:36] <Saviq> mhr3, k, let's see if we can get it later
[08:37] <mhr3> Saviq, were you at least able to recover from it?
[08:37] <Saviq> mhr3, reopen the scope :|
[08:37] <Saviq> mhr3, wouldn't be good on a favourited one
[08:38] <Saviq> tsdgeos_, re: nullifyDepartment, why don't we just want to drop the delegate to the left as well? are we keeping the "history" of delegates all there?
[08:38] <mhr3> Saviq, tried entering search and clearing?
[08:38] <Saviq> mhr3, right, that would probably help as well
[08:38] <Saviq> mhr3, but seeing as the query came back with departments, it looked like something broke closer to the UI (either plugin or dash UI)
[08:39] <tsdgeos_> Saviq: it's hard to make the listview play nice with us if you remove the thing on the left
[08:39] <tsdgeos_> doesn't like prepending stuff, et al
[08:39] <Saviq> tsdgeos_, mhm :|
[08:39] <tsdgeos_> Saviq: don't remember the exact problem, but it's what i originally had
[08:40] <Saviq> tsdgeos_, the delegates are destroyed anyway, so it's probably fine
[08:41] <Saviq> tsdgeos_, any reason why not Flickable { Column { FooButton { } BarButton { } Repeater { } } }
[08:42] <tsdgeos_> Saviq: "free" animation between columns when changing current index
[08:42] <mhr3> Saviq, can we have a quick chat about customizations + cache later today?
[08:42] <Saviq> mhr3, tomorrow, I'm actually supposed to have a holiday today
[08:42] <mhr3> heh, ok
[08:43] <Saviq> tsdgeos_, not sure what that means, we're switching the whole delegate anyway?
[08:43] <tsdgeos_> i mean the horizontal animation when going up/down
[08:43] <tsdgeos_> listview takes care of that
[08:43] <Saviq> tsdgeos_, yes
[08:43] <Saviq> tsdgeos_, I mean in DashDepartmentsList
[08:43] <tsdgeos_> ah
[08:44] <Saviq> tsdgeos_, you have a Flickable, two (conditional) buttons and a Repeater there
[08:44] <tsdgeos_> yep
[08:44] <Saviq> tsdgeos_, and calculate height / anchor / calculate y and all kind of things that column would do for you?
[08:45] <tsdgeos_> right
[08:45] <tsdgeos_> no reason other than i didn't think about it
[08:45] <Saviq> tsdgeos_, no need to change height then either, column disregards invisible items
[08:45] <tsdgeos_> can try changing if you want
[08:45] <Saviq> tsdgeos_, yeah, it will be like 20 lines less and less complicated
[08:45] <tsdgeos_> ook
[08:45]  * tsdgeos_ does
[08:50] <tsdgeos> mhr3: so https://code.launchpad.net/~unity-api-team/unity-scopes-shell/department-support/+merge/222345 looks good to me, do you want me to top approve or wait for someone else?
[08:51] <mhr3> tsdgeos, feel free to top, anyway pete and pawel are holidaying
[08:58] <tsdgeos> Saviq: it's not that many changes, no? only http://paste.ubuntu.com/7668003/
[08:58] <tsdgeos> you see anything else that'd change?
[08:59] <Saviq> tsdgeos, sounds about right
[08:59] <tsdgeos> ok then
[08:59] <tsdgeos> not a huge improvement, but better still
[09:00] <Saviq> yeah, less crazy stuff :D
[09:01] <tsdgeos> but something broke horribly
[09:01]  * tsdgeos checks
[09:06] <Saviq> tsdgeos, some small comments inline on the MP
[09:06] <tsdgeos> ok
[09:52] <Saviq> mhr3, tsdgeos, FYI, mikenagle is having a play with departments now, will comment on Albert's MP
[09:52] <Saviq> thostr_, ↑
[10:12] <tsdgeos> Saviq: pushed + answered on the departments thing
[10:17] <tsdgeos> Saviq: cool, let's see what mikenagle thinks :D
[10:20] <mhr3> > Why do we need this? Wouldn't model: department just work? Do we need to wait for it to be loaded?
[10:20] <mhr3> Yes, i don't want stuff to appear one by one in case the model loads very slowly
[10:20] <mhr3> tsdgeos, ^^ backend-wise it's already binary
[10:21] <mhr3> the model is either empty and !loaded, or filled in && loaded
[10:26] <Saviq> tsdgeos, saw mhr3's response?
[10:26] <tsdgeos> nah
[10:26] <tsdgeos> sad internet today
 > Why do we need this? Wouldn't model: department just work? Do we need to wait for it to be loaded?
[10:26] <Saviq>  Yes, i don't want stuff to appear one by one in case the model loads very slowly
[10:26] <Saviq>  tsdgeos, ^^ backend-wise it's already binary
[10:26] <Saviq>  the model is either empty and !loaded, or filled in && loaded
[10:27] <Saviq> mhr3, tsdgeos, in any case, this way it's more future-proof, in case you start lazy-loading them
[10:27] <tsdgeos> ah
[10:27] <tsdgeos> ok
[10:28] <Saviq> tsdgeos, still don't know how index == currentIndex is different than ListView.isCurrentItem ;)
[10:28] <Saviq> tsdgeos, the "I want to wait for the transition to finish" is handled by x  == contentX
[10:28] <tsdgeos> Saviq: ah damn, i thought you were speaking about the other part
[10:28] <Saviq> tsdgeos, yeah, thought so
[10:29] <tsdgeos> actually with the other part i don't even need that i think
[10:29] <tsdgeos> let me check
[10:29] <Saviq> probably
[10:31] <Saviq> tsdgeos, did you have a look at http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.ListItems/ ? those look kinda like everything you need (with the exception that the left icon would probably end up being too big...
[10:32] <Saviq> tsdgeos, so I'd be fine with "TODO: check if SDK ListItems could be use here" fornow
[10:32] <tsdgeos> i did look there yes
[10:32] <tsdgeos> i mean it provides what exactly that would save me any code?
[10:33] <Saviq> tsdgeos, in any case - if it does *not* help us, we need to make it so that it does
[10:34] <tsdgeos> correct
[10:34] <tsdgeos> ok, i'll add the TODO, ok?
[10:34] <Saviq> yup
[10:34] <Saviq> tsdgeos, because it's just a damn shame that we have to do it manually when the pattern is used across the board
[10:34] <Saviq> we should just be able to do
[10:35] <tsdgeos> correct
[10:35] <Saviq> ListItem { leftIcon: "foo"; text: "bar"; rightIcon: "bar" }
[10:35] <Saviq> and be done with it
[10:36] <tsdgeos> Standard would be it maybe
[10:36] <tsdgeos> but doesn't have the backicon and stuff
[10:41] <tsdgeos> Saviq: ok, removed  index == departmentListView.currentIndex
[10:55] <Saviq> tsdgeos, well, backicon you could do, but there's no way to add a custom icon on the right
[11:00] <Saviq> mhr3, I just saw the "Get more apps" card in Apps... it's medium instead of large? and has transparent grey background, that expected?
[11:01] <mhr3> Saviq, was asking apps guys about that, they said it's temporary cause dash doesn't support what they want
[11:01] <Saviq> mhr3, what is it they want?
[11:01] <Saviq> mhr3, it's wrapped, elided, it's just bad right now
[11:01] <mhr3> https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/scopes/app-scope-home/app-scope-landing-page/01_Home_apps_store_scope.jpg?attachauth=ANoY7cpK1NvR0ZTsFyIXnZaKtcG2FSSY_cyU5yEdv-Xht60QMZ8PALgaBxN3HEIBoG6lzO45JQ2IoF-fagQuvVtjJIJn2g7JPlDr6RZZPTENKfu9uNzXWkHqdloDqYeINZa2Vyl4mcmaoeIXy_BK1G8H6W_PVwq7FTeqn8eW-kllBkw5OP8nws_JTfy2fKeeEzKj0FUmqhFyVpmr9wzrOLxYuHBUbDNG2EkDwKxAvoy3Z3DfaCmNDdfQkDy8713Bo
[11:01] <mhr3> 5CmF224NEFg478xcqQRF6ohRhTiBtDFbh9WNbyM0B8VsHxKch7LaFk%3D&attredirects=0
[11:02] <mhr3> Saviq, http://goo.gl/DOVGvO
[11:03] <Saviq> hmm ok that's news to me, last I checked it was meant to be a full-width card :|
[11:04] <Saviq> what's on this image doesn't look like anything that's planned to work :|
[11:04] <mhr3> Saviq, spec says Sm_ARt_Header_Vertical
[11:05] <Saviq> mhr3, except there's no overlay background
[11:05] <mhr3> with title overlay
[11:05] <Saviq> mhr3, yeah, but overlay requires some background, this one doesn't have it
[11:06] <mhr3> wasn't there one customization param for that?
[11:06] <Saviq> mhr3, solid background
[11:06] <Saviq> mhr3, not transparent, because then we can't know what foreground colour to use
[11:07] <Cimi> I will spend the rest of my life in this file
[11:07] <mhr3> Saviq, meh, it's ubuntu orange
[11:08] <Saviq> mhr3, it's not, it's transparent ;)
[11:08] <mhr3> visual bug :P
[11:08] <Saviq> if you say so ;)
[11:08] <Saviq> but yeah, we can do that with a solid overlay background
[11:10] <Saviq> mhr3, should I see "allLabel" in the proxy log?
[11:10] <mhr3> Saviq, if it's != label
[11:10] <Saviq> mhr3, that's what Mike noticed that the bold label is not "All books" but "Books"
[11:10] <mhr3> scope bug
[11:11] <Saviq> k
[11:11] <mhr3> facundo should be here
[11:11] <Cimi> Saviq, I recommend to approve and merge emblem
[11:11] <Cimi> Saviq, then we wait for this rewrite
[11:12] <Saviq> Cimi, you "recommend" meaning that you couldn't do what I asked you to?
[11:12] <Cimi> Saviq, yeah
[11:12] <Cimi> Saviq, need more time
[11:13] <Cimi> Saviq, and we have a reference code that works
[11:13] <Cimi> Saviq, so it is easier to spot regressions if I mess up with this
[11:13] <Cimi> otherwise wait more :)
[11:13] <Cimi> i hope to finish today
[11:14] <facundobatista> buenos días a todos!
[11:14] <Saviq> Cimi, I'm finishing up for today anyway
[11:14] <Saviq> tsdgeos_, ACK from me
[11:14] <Saviq> mhr3, ↑
[11:14] <Saviq> thostr_, ↑
[11:15] <mhr3> wooo :)
[11:15] <Saviq> so unless Mike says NACK, you can land
[11:15]  * Saviq rebuilds unity8 though
[11:15] <mhr3> i'll be heading to the office, see what mike says
[11:15] <tsdgeos_> great
[11:15] <mhr3> Saviq, i'll do it
[11:15] <Saviq> mhr3, ok
[11:17] <Saviq> mhr3, thostr_, you will execute the unity8 TestPlan of course? :)
[11:18]  * Saviq just added to the landing line
[11:18] <mhr3> Saviq, of course! ;)
[11:19] <Saviq> o/
[12:03] <mhr3> facundobatista, ehm
[12:03] <mhr3> facundobatista, https://dash.ubuntu.com/smartscopes/v2/amazon/search?q=&session_id=session_id&query_id=0&platform=phone&locale=en_US
[12:03] <mhr3> just departments, no results
[12:03] <mhr3> what the? ^
[12:05] <facundobatista> mhr3, amazon fuzzy behaviour? I just tried it and got one result
[12:05] <mhr3> facundobatista, apparently it's the query_id=0 that blows it
[12:05] <facundobatista> mmm
[12:07] <facundobatista> mhr3, it shouldn't... query_id is just converted to int if there (so '0' is ok), and not used at all in the scope
[12:07]  * facundobatista tries it locally
[12:07] <mhr3> caching issue?
[12:09] <mhr3> facundobatista, what is the id even used for?
[12:09] <mhr3> we seem to be passing 0 all the time
[12:09] <mhr3> marcustomlinson, ^?
[12:10] <marcustomlinson> mhr3: integer incremented for each subsequent query in a session
[12:10] <marcustomlinson> mhr3: we haven't even got session_id implemented
[12:11] <mhr3> marcustomlinson, nope, query_id is always 0 in the request
[12:11] <marcustomlinson> mhr3: yes, I'm saying its not implemented
[12:11] <facundobatista> mhr3, when it's implemented, we will use it to gather stats between searches and previews
[12:12] <facundobatista> mhr3, like "oh, see, if the images are > N pixels wide, the preview hit rate goes up by M%!!"
[12:12] <mhr3> seems too much to require per-session ids AND sequence number within that session
[12:12] <facundobatista> mhr3, in any case, it's not breaking the query
[12:13] <mhr3> it is for me
[12:14] <mhr3> facundobatista, does this help? http://paste.ubuntu.com/7668748/
[12:14] <facundobatista> mhr3, you have different results without the query_id parameter?
[12:14] <mhr3> yes
[12:16] <facundobatista> it may be caching, yes, let me see
[12:16] <facundobatista> mhr3, can you issue both queries from your machine using "curl -i", please?
[12:17] <mhr3> facundobatista, http://paste.ubuntu.com/7668758/
[12:20] <facundobatista> mhr3, that is not with and without the query_id parameter
[12:20] <facundobatista> mhr3, that is with different value
[12:20] <facundobatista> mhr3, "query_id" is not used at all in the amazon scope
[12:20] <mhr3> same thing
[12:20] <mhr3> http://paste.ubuntu.com/7668767/
[12:21] <facundobatista> mhr3, right, same thing, that implies that the parameter is not breaking the query
[12:21] <mhr3> it implies that the cache is broken for query_id=0
[12:23] <facundobatista> ah, mmm
[12:24] <mhr3> fwiw some of these were cache misses when i started
[12:24] <facundobatista> mhr3, I will investigate this cache issue
[12:24] <mhr3> thx
[13:21] <elopio> ping @unity. Can somebody review this one please?
[13:21] <elopio> https://code.launchpad.net/~elopio/unity8/flake8/+merge/223495
[13:22] <tsdgeos> it has lots of stuff i don't like
[13:23] <tsdgeos> probably has one of those silly "we live in the 70s and you're using a 80 column terminal to edit this so let's wrap the line" rules
[13:23] <tsdgeos> so you'll find someone else to approve it
[13:28]  * kgunn takes note to get tsdgeos and duflu in a cage match over 80 col topic ;)
[13:29] <tsdgeos> kgunn: i honestly don't care, just unhappy people destroy history over small stuff like that
[13:41] <mhr3> mikenagle, ping?
[13:42] <mhr3> mikenagle, are you in a meeting somewhere? can't find you
[13:44] <Cimi> mhr3, he's not in the office
[13:45] <mhr3> Cimi, oh?
[13:45] <Cimi> mhr3, you went to the office for nothing
[13:45] <Cimi> mhr3, I'm taking piss... I don't know really :P
[13:46] <mhr3> Cimi, anyway i mostly wanted lunch for borough market :P
[13:46] <mhr3> from*
[13:46] <Cimi> ahaha
[13:46] <mhr3> Cimi, ah, cheeky bastard! :P
[13:58] <elopio> tsdgeos: it's pep8, not a small thing :D
[13:59] <elopio> all the rules of the python civilization are built on top of it
[14:04] <tsdgeos> elopio: that's why i'm not against it, just not approving it ;)
[14:12] <seb128> Saviq, should unity8 in silo 008 be rebuilt with the new mir?
[14:13] <tsdgeos> seb128: i think he said he was off for the day
[14:13] <tsdgeos> seb128: but afaik we're landing departments first
[14:13] <tsdgeos> mhr3: are we?
[14:13] <tsdgeos> did anyone find mikenagle so he can ack/nack?
[14:13] <seb128> tsdgeos, well, that silo is a test one, no landing planned yet
[14:14] <tsdgeos> ah :D
[14:14]  * tsdgeos hides
[14:14] <mhr3> tsdgeos, yes, landing right now
[14:14] <tsdgeos> mhr3: awesome \o/
[14:14] <mhr3> seb128, ^^
[14:15] <seb128> tsdgeos, mhr3: thanks
[14:16] <Cimi> Saviq, did you see my comment yesterday on how to turn on infographics?
[14:16] <mikenagle> tsdgeos - saviq got hold of me - just been in a lot of meetings
[14:20] <Saviq> Cimi, yes I saw that, we still need to wait for Pete to say why it doesn't work
[14:20] <Cimi> Saviq, well camera doesn't work
[14:20] <Cimi> Saviq, infographics on shell do
[14:20] <Saviq> Cimi, it should work on others as well (through a compatibility layer)
[14:20] <Saviq> seb128, no need to rebuild u8, no, not until 5.3 lands, which should happen later today
[14:21] <Saviq> seb128, only unity-mir would need rebuilds against new Mir
[14:21] <Cimi> Saviq, so we wait till pete fixes issues in the service?
[14:21] <seb128> Saviq, k, thanks
[15:52] <tsdgeos_> arggg internet!
[15:59] <tsdgeos_> enough internet disconnections for today
[15:59] <tsdgeos_> !
[15:59]  * tsdgeos_ waves
[16:23] <kgunn> mterry: hey, boot anim looks good to me
[16:23] <mterry> kgunn, oh awesome!
[16:24] <mterry> kgunn, I'll mark that silo as tested then.  Seemed fine to me yesterday too
[16:24] <kgunn> have you test n10 ? i was gonna test it real quick...n4, n7 look fine
[16:24] <mterry> kgunn, no I haven't recently
[16:24] <kgunn> 5 min and i'll have it
[16:24] <mterry> kgunn, OK
[16:24] <mterry> kgunn, I believe the icon will appear smaller than you'd like.  But that's a filed bug that MacSlow will hopefully have time for
[16:25] <kgunn> ack
[16:39] <MRRpc> hello is there anybody to help me :)
[16:48] <mterry> kgunn, any luck with n10?
[16:48] <kgunn> mterry: just finished...all good
[16:48] <mterry> sweet
[16:48] <kgunn> ship it
[16:49] <mterry> kgunn, how was icon size?
[16:50] <kgunn> fine
[16:53] <mterry> oh good.  Maybe MacSlow doesn't need to do anything after all
[17:08] <kgunn> mterry: do you have an opinion on the last comment on this mp ?
[17:08] <kgunn> https://code.launchpad.net/~albaguirre/unity8/use-new-display-power-state-interface/+merge/219552
[17:48] <facundobatista> mzanetti, ping, remember that tool you told me about in Malta? How was it named? I have a Utopic machine, I can use it :)  thanks!


 We missed standup today.
 oops
[06:14] -lugito:#lubuntu-devel- [rMANUAL78d80a61c4d1: Remove uneeded whitespace] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL78d80a61c4d1
[08:04] -lugito:#lubuntu-devel- [rMANUAL71ce373f0575: Update ARK version] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL71ce373f0575
[20:28] -lugito:#lubuntu-devel- [rLXQTPANELPACKAGING4ef0632ba2c4: Merge from Ubuntu Merge-o-Matic] The_LoudSpeaker (Raman Sarda) committed: https://phab.lubuntu.me/rLXQTPANELPACKAGING4ef0632ba2c4
 ^ Here the other changes mentioned in changelog (entries other than mine) are already present in the source. Just that the changelog got updated now. Should I mention that in changelog or leave it be? As it should be understood from the title of the commit.
 ^ @kc2bez wxl: @RikMills
 The debian/changelog merge entry should document the delta to debian that you left, and why. You haven't done that!
 And the delta you left looks not right.
 That is the delta
 You did not mention:
 - What you kept different in debian/control, and why
 - That you did not merge the copyright changes. You should have merged that I think.
 - install file differences
 - debian/rules differences
 - you hadn't merged the debian/meta. Which you should have done
 - That you kept the watch file url at the wrong url with lxde in it. 😱
[21:15] -lugito:#lubuntu-devel- [T128: Alt-Tab and Alt-Shift-Tab feature request (openbox conf)] EinarMostad (Einar Mostad) commented on the task: https://phab.lubuntu.me/T128#3104
[23:15] <wxl> ir
[23:15] <wxl> wth https://bugs.launchpad.net/bugs/1862428
[23:16] <kc2bez> I was just trying to make sense of that.
[23:16] <wxl> oh i think i understand it now
[23:16] <wxl> once they fix cdimage to serve https we need to update the download links
[23:17] <kc2bez> That was they way I understand it too.
[23:17] <kc2bez> Nothing too much to worry about immediately.
[23:17] <wxl> and probably we're the only other ones besides xubuntu that have a registered project for the website soo XD
[23:17] <wxl> well in august they're blocked
[23:59] <guiverc> new qa-install of 20.04 on sony ultracrap; I'm having trouble with connecting to wifi with default term box as it opens.  If i increase [qterminal] size before I edit-connections i can use it, but as installed it kept misbehaving (I couldn't connect wifi)


[08:49] <CIA-5> ubiquity: evand * r1489 ma/ (10 files in 7 dirs): Merged with trunk.
[08:55] <CIA-5> ubiquity: evand * r1490 ma/debian/ubiquity.templates: I forgot to update debian/ubiquity.templates.
[09:10] <evand> cjwatson: See above.  Sorry.
[09:10] <evand> I probably should've attempted the remote administration option as upon inspecting scripts/install.py it looks like it would've taken a matter of minutes to code up.  Feisty+1, I suppose.
[09:20] <cjwatson> evand: ok - hmm, did you push that?
[09:20] <cjwatson> $ bzr pull
[09:20] <cjwatson> Using saved location: http://bazaar.launchpad.net/~evand/ubiquity/ma/
[09:20] <cjwatson> No revisions to pull.
[09:22] <evand> whoops
[09:22] <evand> sorry, it's early
[09:22] <evand> one sec, I'll push
[09:23] <evand> done
[09:24] <cjwatson> what timezone are you on? ::)
[09:24] <cjwatson> :)
[09:24] <evand> cjwatson: EDT, whatever that is now
[09:24] <evand> 4:24AM
[09:24] <cjwatson> ah, that sort of early then
[09:24] <evand> indeed!
[09:25] <evand> Are there any areas of Ubiquity that need help?  With everything in freeze I'm looking for something to do.
[09:31] <cjwatson> there are still a few bits to iron out in the new partitioner
[09:31] <cjwatson> somebody should sort out the timezone page rework from https://wiki.ubuntu.com/Ubiquity/FeistyReview
[09:32] <cjwatson> um, there's probably a bunch of other stuff but 8:30am is not my best time either
[09:32] <evand> heh
[09:33] <evand> If you think of anything else, just let me know.  I'm eager to get involved in more than just m-a where possible.
[09:33] <evand> I'll take a look at what you've already listed later today.
[09:34] <cjwatson> there's https://wiki.ubuntu.com/InstallerDevelopment/ToDo
[09:34] <CIA-5> ubiquity: cjwatson * r1954 ubiquity/debian/ (changelog ubiquity.templates): merge from Evan
[09:34] <cjwatson> need to keep that better updated
[09:35] <cjwatson> * recover more gracefully from errors, particularly boot loader installation problems
[09:35] <cjwatson> sorting out that item would be fantastic; maybe some kind of retry option
[09:35] <evand> cjwatson: should I start up a new branch or are these things that can still go into Feisty?
[09:36] <cjwatson> I think they're probably feistyable, although you probably want a new branch anyway
[09:36] <evand> ok
[09:37] <CIA-5> ubiquity: cjwatson * r1955 ubiquity/debian/po/ (77 files): debconf-updatepo
[09:38] <evand> oh, that's something that's confusing me
[09:39] <evand> I noticed that the data in ubiquity.templates isn't getting put in the po files.  Was there any reason for this?  I thought maybe it had something to do with a new translation approach.
[09:39] <cjwatson> you need to run debconf-updatepo when changing .templates
[09:39] <cjwatson> the d-i project has a cron job that runs over svn and does that, so developers don't need to
[09:39] <cjwatson> we don't though
[09:40] <evand> Is that why things like partman-failed-mount were not in the po files?
[09:42] <cjwatson> partman-failed-unmount? it's there
[09:42] <cjwatson> #. Type: boolean
[09:42] <cjwatson> #. Description
[09:42] <cjwatson> #: ../ubiquity.templates:91001
[09:42] <cjwatson> msgid "Failed to unmount partitions"
[09:42] <cjwatson> msgstr ""
[09:42] <evand> yeah whoops
[09:42] <evand> I was grepping for the title, which obviously doesn't work
[09:42] <evand> ok, noted
[09:42] <cjwatson> some of the templates aren't translatable - the ones with Description rather than _Description
[09:43] <evand> indeed
[09:43] <cjwatson> oh, other thing that needs attention, memory use
[09:43] <cjwatson> I found an easy 2MB savings the other day, but I'm sure there's lots more
[09:43] <evand> yeah, I noticed you started doing that
[09:44] <cjwatson> and fitting the UI into 640x480, for similar reasons
[09:44] <evand> mind if I ask how you're profiling?  Or is it just a combination of the running app and top?
[09:44] <cjwatson> I haven't figured out a great way of doing it yet
[09:44] <cjwatson> I was using python-dbg and PYTHONDUMPREFS=1
[09:44] <cjwatson> it's not really quite what I want
[09:45] <cjwatson> or maybe I'm just not good at reading the output yet
[09:45] <evand> hrm
[09:46] <cjwatson> there are some speed/memory tradeoffs in ubiquity
[09:47] <cjwatson> the most significant is the way I read a bunch of translations into memory because extracting them from debconf is slow
[09:47] <cjwatson> maybe that should become simple temporary files or something like that, which could be mmaped
[09:47] <cjwatson> or just opened each time
[09:48] <cjwatson> though of course temporary files use up memory on the live session too, so that doesn't help
[09:48] <evand> via cow, right?
[09:48] <cjwatson> right
[09:48] <cjwatson> should probably finish the work I started on making cdebconf mmap its databases, and then switch ubiquity to cdebconf
[09:49] <cjwatson> trying to make debconf lowmem-friendly is a bit of a dead end
[09:49] <evand> you're going to switch to cdebconf for Feisty?
[09:49] <cjwatson> no
[09:50] <cjwatson> I thought about it, but it doesn't really buy anything without the db mmap work
[09:50] <cjwatson> doesn't seem significantly faster
[09:51] <evand> didn't cdebconf not have some issues that debconf does?  I seem to recall something about metaget not working quite right, though I could be way off.
[09:52] <evand> or perhaps I'm thinking of a different problem entirely
[09:54] <cjwatson> there have been various issues where one is better than the other
[09:54] <cjwatson> cdebconf doesn't have escape capb support yet, which would be a requirement to switch
[09:54] <cjwatson> I started writing that but got bored
[09:54] <evand> hahaha
[10:12] <CIA-5> ubiquity: cjwatson * r1956 ubiquity/ (configure configure.ac): bump to 1.4.2
[12:22] <saispo> cjwatsohi all
[12:22] <saispo> oups
[12:22] <saispo> hi all :)
[12:23] <saispo> cjwatson: if i change my gpg keys for creating a custom cd, i must rebuild ubuntu_keyrings ?
[01:44] <saispo> hi cr3
[01:57] <cr3> saispo: ahoy!
[04:35] <saispo> if no kernel found, it's due to ubuntu-keyring ?
[05:10] <saispo> anyone can give me some tips ? i have rebuild ubuntu-keyrings with my two rsa gpg keys include in it, sign the pacakges, put it on the cd
[05:11] <saispo> but at the end, the installer say that it's doesn't found any kernels
[05:11] <saispo> anyone have an idea ?
[05:15] <saispo> i have two idea... it's an rsa key, she have a password...
[05:15] <saispo> when i test with a dsa key with no password, all work...


[02:48] <bkerensa> waaa waa so hot today
[02:48] <bkerensa> 92 degrees
[20:29] <bkerensa> nathwill: was it a success?


[02:06] <lifeless> sinzui: ping
[02:06] <LPCIBot> Project windmill build #91: FAILURE in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/91/
[02:45] <lifeless> thats better,
[02:45] <lifeless> more closed bugs
[02:45] <lifeless> and one more hidden critical unearthed
[02:55]  * lifeless resists the urge to start at bug oldest and walk forward
[02:55] <lifeless> wgrant: ping
[02:56] <lifeless> I'm pinging you cause curtis had better be asleep by now :) -  where is Cve:+index - is jc still on it, or would it be ok if I pick it up? its our #2 frequency OOPS
[02:56] <wgrant> lifeless: He's still on it.
[02:56] <lifeless> kk
[03:08] <lifeless> wgrant: have you poked at +needs-packaging at all ?
[03:08] <lifeless> wgrant: I'm struggling to find top-10 timeouts that are not fixed-undeployed, bugtask:+index, or in-progress by someone
[03:10] <wgrant> lifeless: Not at all.
[03:11] <wgrant> You seem to love BugTask:+index
[03:11] <lifeless> wgrant: Not at all.
[03:12] <lifeless> wgrant: the next obvious thing is a paginated message display
[03:12] <lifeless> wgrant: which is to big for me: I get called away all over the place.
[03:12] <lifeless> wgrant: I mean, making a vertical page-reloading batchnav is easy.
[03:13] <lifeless> wgrant: making one that uses js to incrementally pull in new messages and actions and shows the comment form once you read to the bottom - a bit harder.
[03:14] <wgrant> Yeah.
[03:15] <lifeless> wgrant: so other than ratcheting scaling down a bit more, I'm not likely to really touch it for a bit
[03:15] <lifeless> dammit, I need to finish my analysis of deletable bugtasks etc
[03:15]  * lifeless adds a note to talk to jml about said
[03:16] <lifeless> wgrant: (oh, and I'd be delighted for someone else to do the next iteration on bugtask:+index)
[03:18] <lifeless> wow
[03:18] <lifeless> 400ms overhead per page atm
[03:19] <lifeless> just doing traversal
[03:19] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1907C1055
[03:19] <lifeless> probably a busy appserver contributing
[03:27] <mwhudson> i worry a bit sometimes about the minimum time launchpad can produce a page in
[03:27] <mwhudson> (i think it's quite a while, like 100ms)
[03:27] <mwhudson> maybe not that bad
[03:28] <lifeless> mwhudson: well, the page I'm looking at - 400ms minimum.
[03:28] <lifeless> mwhudson: trace the queries down to the session update after traversal
[03:29] <mwhudson> lifeless: erk
[03:29] <lifeless> we're still in phase one though - drive the 99th% percentile down by fixing poor scaling in pages
[03:30] <mwhudson> oh that's the server machine wgrant is always complaining about isn't it?
[03:30] <lifeless> mwhudson: well, its not the hardware.
[03:30] <wgrant> It's partly the hardware.
[03:30] <lifeless> mwhudson: its a 4-thread appserver with maybe 2-4 additional requests parsed and awaiting handoff
[03:30] <lifeless> wgrant: it really isn't :)
[03:30] <wgrant> lifeless: soybean has lots of them as well.
[03:30] <wgrant> But we see most of our timeouts from the old appservers.
[03:31] <mwhudson> lifeless: yeah, something smells off about that that's not entirely related to the code in lp:launchpad
[03:31] <lifeless> anyhow
[03:31] <lifeless> tonight is pounce on the sysadmins night
[03:31] <StevenK> Poor sysadmins
[03:31] <lifeless> (not nastily)
[03:32] <lifeless> just that tom is the guy working this progression
[03:34] <wallyworld_> lifeless: if there's a bug with total crap in it (random text), do we just mark it as incomplete or do we need to get it deleted?
[03:36] <lifeless> invalid probably.
[03:36] <lifeless> whats the bug #?
[03:37] <lifeless> wallyworld_: ^
[03:37] <wgrant> wallyworld_: Sorry, I meant to look at that earlier, but got sorta distracted :/
[03:37] <wallyworld_> 738023
[03:38] <lifeless> lol - classic - http://programming-motherfucker.com/
[03:38] <lifeless> wallyworld_: that seems to be outside the launchpad project?
[03:39] <wallyworld_> yes
[03:39] <wallyworld_> but it's an open lp question
[03:39] <lifeless> ah
[03:39] <wallyworld_> so i thought i'd clean it up since it's clearly a crap bug
[03:39] <lifeless> so there is no spam in it
[03:39] <lifeless> incomplete leaves it open
[03:40] <lifeless> I would make it invalid
[03:40] <wallyworld_> no. just crap
[03:40] <wallyworld_> ok
[03:40] <wallyworld_> thanks
[03:47] <cody-somerville> Why does the series filter on the main pages of PPAs have such huge text? lol
[03:47] <wgrant> Someone embedded a form inside a heading, and this was exposed in the recent style unifications.
[03:48] <lifeless> H1 is big
[04:45] <lifeless> I can has review https://code.launchpad.net/~lifeless/launchpad/bug-722794/+merge/54466 ?
[04:51] <StevenK> lifeless: Done, r=me
[04:52] <lifeless> thanks
[05:36] <lifeless> wgrant: wtf: https://lp-oops.canonical.com/oops.py/?oopsid=1907C2337
[05:37] <lifeless> wgrant: I'm pinging you cause you added the transaction status to the timeline :)
[05:40] <wgrant> lifeless: Huh.
[05:40] <wgrant> But API timeouts normally work fine :/
[05:41] <wgrant> Although leonardr did change them recently.
[05:41] <lifeless> https://bugs.launchpad.net/launchpad/+bug/730396
[05:41] <_mup_> Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >
[05:54] <lifeless> what does BuildFarmJob.status <> 1 OR BuildFarmJob.date_finished IS NOT NULL imply
[05:54] <lifeless> not fullybuilt and finished ?
[05:54] <lifeless> the query I'm looking at also checks for FAILEDTOBUILD
[05:54] <lifeless> can I drop the BuildFarmJob.date_finished IS NOT NULL condition without breaking semantics ?
[06:03] <lifeless> thumper: https://bugs.launchpad.net/launchpad/+bug/730396/comments/9
[06:03] <_mup_> Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >
[06:15] <wgrant> lifeless: That query is stupid, yes. For some of the cases you can drop the first BFJ <> AND date_finished IS NOT NULL check, yes.
[06:15] <wgrant> lifeless: But we need to keep date_finished IS NOT NULL if status == 1.
[06:18] <lifeless> sure
[06:18] <lifeless> so over here
[06:18] <lifeless> uhm
[06:18] <lifeless> if we don't gc builds
[06:18] <lifeless> there is no point reading all *FTBFS* rows every time
[06:18] <lifeless> full stop
[06:18] <StevenK> Hmmm, looks like I didn't kill dogfood
[06:19] <wgrant> lifeless: If we move to an incremental model, sure.
[06:19] <wgrant> lifeless: But then we'd need to read all recent successes too.
[06:19] <lifeless> wgrant: why?
[06:20] <wgrant> lifeless: Because we need to be able to remove failures that are no longer failures.
[06:20] <lifeless> wgrant: do they get removed from this collection?
[06:20] <wgrant> If we're not reading the whole failure collection, we need to read every other collection.
[06:23] <lifeless> wgrant: do they get removed from this collection?
[06:25] <wgrant> lifeless: Which collection?
[06:25] <lifeless> fbtfs
[06:25] <wgrant> lifeless: A retried build is not a new build.
[06:25] <wgrant> A retried build will disappear from this page.
[06:25] <wgrant> (unless it fails again)
[06:25] <lifeless> wgrant: so, we do gc
[06:25] <wgrant> Pardon?
[06:25] <lifeless> or are you asying we reuse the BFJ ?
[06:26] <wgrant> We reuse the BFJ.
[06:26]  * lifeless headdesks
[06:26] <wgrant> Yes.
[06:26] <wgrant> Someone made this decision 6 years ago, and uh, yeah.
[06:26] <lifeless> anyhow
[06:26] <lifeless> I'd read all collections incrementally
[06:27] <lifeless> that seems cheap and effective as long as you don't shutdown for a month
[06:28] <lifeless> wgrant: what rev has leonards change for timeouts ?
[06:28] <wgrant> lifeless: It was a lazr.restful upgrade.
[06:29] <lifeless> meh, I'll raise a critical
[06:29] <wgrant> I'm pretty sure this worked after my changes, although it's clearly somewhat related.
[06:33] <lifeless> https://bugs.launchpad.net/launchpad/+bug/740750
[06:33] <_mup_> Bug #740750: API timeouts broken and returning no useful data... <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 >
[07:05] <poolie> big f* jools?
[07:11] <lifeless> poolie: ?
 We reuse the BFJ.
[07:16] <wgrant> Heh'
[07:16] <lifeless> poolie: before his time
[07:16] <StevenK> poolie: Build Farm Job
[07:17] <poolie> https://bugs.launchpad.net/launchpad/+bug/740759 might amuse you
[07:17] <_mup_> Bug #740759: creating bzrdir on launchpad is slow (BzrDirFormat.initialize_ex_1.16) <codehosting-ssh> <hpss> <lp-code> <performance> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740759 >
[08:28] <adeuring> good morning
[09:03] <lifeless> stub: hi
[09:03] <lifeless> stub: how are you feeling?
[09:03] <stub> yo
[09:03] <stub> Better today... slept 13 hours straight last night.
[09:04] <lifeless> stub: good timing - we tried your live index docs but got the patch number wrong: https://code.launchpad.net/~wgrant/launchpad/fix-patch-57/+merge/54481 is meant to fix it, but wanted to confirm: is the db patch *in the tree* meant to be a .1 patch, or a .0 with the same major as the one done live ?
[09:04] <wgrant> I think the numbers have to match./
[09:04] <wgrant> Or it will be reapplied on the next db-deploy and then blow up.
[09:04] <wgrant> I think.
[09:04] <stub> db patch in the tree is supposed to be a 2208-xx-01 (or -02 etc.) patch. The number should match what you inserted into LaunchpadDatabaseRevision on production
[09:05] <poolie> hi
[09:05] <poolie> would i be right in expecting that the qastaging database will be generally faster than lpnet?
[09:05] <poolie> because of less load
[09:05] <wgrant> It's a much smaller DB server.
[09:06] <wgrant> And the cache will be colder.
[09:06] <stub> Why this works - Launchpad appservers check LaunchpadDatabaseRevision for patches that have been applied that are not in the local source tree, and for patches in the local source tree that have not been applied. It ignores all patches that are non-zero in the 'patch' field.
[09:06] <StevenK> So it's generally slower
[09:06] <poolie> hm
[09:07] <stub> lifeless, wgrant: So that patch seems correct, and matches what I see on the production db. Did the patch also get applied to launchpad_prod_2 and launchpad_prod_1 ?
[09:08] <lifeless> stub: yup
[09:08] <stub> So it worked out best with id in the first field of the index?
[09:08] <wgrant> stub: It was applied as -0 to all three.
[09:08] <lifeless> stub: it was a lopsided problem
[09:08] <stub> I don't see -0 in LaunchpadDatabaseRevision - I only see 57-1
[09:08] <wgrant> stub: Right, we had to fix it when an appserver failed to start.
[09:08] <lifeless> stub: we tried a number of permutations on qastaging, and found that a partial index on the queues that are driven to 0 (the NEW and INCOMPLETE) performed very well
[09:08] <wgrant> lifeless: NEW and UNAPPROVED
[09:09] <stub> I thought the index would have worked better with id in the last field, as the ordering would have been done last, but I hadn't checked and wasn't sure.
[09:09] <wgrant> stub: As would I. I didn't follow lifeless' trials very closely, though.
[09:09] <lifeless> can't do id last
[09:09] <lifeless> not without a bunch of headaches
[09:09] <stub> interesting
[09:10] <lifeless> right now we use one query for both:
[09:10] <lifeless>  - queue processing
[09:10] <lifeless>  - historical data analsis
[09:10] <lifeless> pg won't use the indices we tried with id last, unless the full index sort was given
[09:10] <lifeless> archive desc distroseries desc setc
[09:11] <lifeless> it *will*, but not for status=0 [or 1 we are pretty sure]
[09:11] <lifeless> because its a lopsided data problem
[09:11] <lifeless>  status |  count
[09:11] <lifeless> --------+---------
[09:11] <lifeless>       4 |    5777
[09:11] <lifeless>       1 |     182
[09:11] <lifeless>       2 |   47494
[09:11] <lifeless>       3 | 2289831
[09:11] <lifeless>       0 |   40961
[09:12] <wgrant> Um what?
[09:12] <wgrant> That's about 41000 more with status 0 than I would expect.
[09:12] <lifeless> wgrant: indeed, but not enough to worry the index
[09:12] <wgrant> Enough to worry me, though...
[09:13] <lifeless> wgrant: sure, separate problem
[09:13] <bigjools> *blink*
[09:13] <wgrant> Similar on mawson.
[09:13] <wgrant> Hmm.
[09:14] <wgrant>       0 |           97 | 40877
[09:14] <wgrant> Distroseries 97
[09:14] <lifeless> stub: so the headaches are: we would have to either: split out a separate query for the historical data, if we changed the status 0 case to use archive desc distroseries desc status 0 desc id desc
[09:14] <wgrant> karmic
[09:15] <lifeless>      (because the historical data /wants/ id as the first sort key - and pg does a decent job there today)
[09:15] <wgrant> Oh.
[09:15] <lifeless>  or
[09:15] <wgrant> bigjools: Old archive rebuilds :(
[09:15] <lifeless> well, no or
[09:15] <stub> lifeless: Sure. I recall the query. I'm interested in you found it works best with the id in the sort key. I think we have similar cases elsewhere - bugs or bugtask I think.
[09:15] <lifeless> basically, there are two totally different use cases in the one table
[09:16] <lifeless> stub: only because its essentially a micro-table embedded in the bigger one
[09:16] <lifeless> stub: thats why adding a partial index gave good results - -very- fast results once applied [to that particular query]
[09:17] <bigjools> wgrant: grar
[09:17] <wgrant> bigjools: 2009ish
[09:17] <bigjools> let's clear those out
[09:17] <wgrant> So long-fixed.
[09:17] <wgrant> But yes.
[09:17] <lifeless> stub: its possible you can come up with something better
[09:17] <wgrant> Also, accepted is pretty big... probably newer copy archives.
[09:18] <wgrant> Indeed, the newer copy archives.
[09:19] <stub> lifeless: If you tried the partial index on (distroseries, archive, id) instead of (id, distroseries, archive), that would be all I'm interested in at the moment.
[09:19] <lifeless> stub: but the nice thing here was that the partial index was small - 1280 kB
[09:20] <stub> lifeless: I think in earlier versions of PG, the index would not have been used at all because the first field in the index was not used until the very end.
[09:20] <lifeless> stub: we didn't try that variation, no
[09:21] <bigjools> wgrant: we need a way of cleaning out copy archives entirely
[09:21] <wgrant> bigjools: Yes.
[09:21] <bigjools> wgrant: I want to make derived distros supersede them
[09:21] <lifeless> stub:  Limit  (cost=0.00..104.34 rows=31 width=36) (actual time=0.132..83.965 rows=1 loops=1)
[09:21] <lifeless>    ->  Index Scan Backward using packageupload__distroseries__status__archive__idx on packageupload  (cost=0.00..5287.65 rows=1571 width=36) (actual time=0.131..83.961 rows=1 loops=1)
[09:21] <wgrant> bigjools: An interesting plan.
[09:21] <lifeless>          Index Cond: (distroseries = 104)
[09:21] <lifeless>          Filter: ((archive = ANY ('{1,534}'::integer[])) AND (status = 0))
[09:22] <lifeless>  Total runtime: 84.023 ms
[09:22] <lifeless> stub: ignore the index name, thats on qastaging where we were experimenting
[09:22] <bigjools> wgrant: they're essentially the same thing, but copy archives have a spethial UI
[09:22] <lifeless> stub: also - thats *cold* runtime
[09:22] <wgrant> bigjools: Indeed.
[09:23] <stub> lifeless: Right. So in PG 8.4, it might well be more efficient to put the field we are ordering on first, and the ordering and filtering done in one index scan.
[09:23] <lifeless> stub: at least sometimes, yeah
[09:23] <stub> Which is different to how we optimized stuff before elsewhere in the schema. Might be some room for improvement there.
[09:25] <bigjools> wgrant: OOPS-1907BUILDMASTER3 ....
[09:25] <stub> lifeless: Where the live rollout docs good enough for the losas to apply the patch without hiccups?
[09:25] <wgrant> bigjools: What about it?
[09:25] <lifeless> stub: yup, except we got the patch # wrong
[09:26] <wgrant> bigjools: It's annoying, but ordinary and harmless.
[09:26] <bigjools> wgrant: it should not be an oops
[09:26] <wgrant> bigjools: Sure.
[09:27] <bigjools> well, we could see if someone deleted the source
[09:27] <wgrant> Someone uploaded one to supersede it.
[09:27] <bigjools> or that
[09:27] <stub> lifeless: Right. Applying a -0 patch live would mean the appservers fail to restart, so wouldn't even be immediately noticeable.
[09:27] <bigjools> that oops happened 3 times
[09:27] <wgrant> bigjools: Different archs?
[09:28] <bigjools> ah might be
[09:28] <wgrant> Hm, no.
[09:28] <wgrant> Different series.
[09:28] <wgrant> https://launchpad.net/~kxstudio-team/+archive/ppa/+packages?field.name_filter=lv2core&field.status_filter=&field.series_filter=
[09:28] <lifeless> stub: we only caught it when we tested dropping the appserver name from the lpnet configs and found it broke
[09:28] <bigjools> ok
[09:28] <lifeless> stub: so the name in db-devel is meant to be -1 ?
[09:28] <stub> lifeless: Yes.
[09:29] <lifeless> cool
[09:29] <stub> lifeless: Anything non-zero in that field. A non-zero in the 'patch' field means ignore this on runtime checks - it is a minor patch and you shouldn't care if it has been applied or not. Matches our life updates usecase exactly, so yay for prescience.
[09:30] <lifeless> stub: kk
[09:31] <henninge> jtv: Hi!
[09:31] <jtv> hi henninge
[09:31] <henninge> jtv: Are your reviewing today?
[09:31] <jtv> henninge: oh, completely forgot about it.  :(  OTP now.
[09:32] <henninge> np
[09:32] <stub> lifeless: Hmm.... in fact, I can't see why -1+ patches can't land on launchpad/devel ....
[09:32] <henninge> danilos should be reviewing today, too. ;-)
[09:32] <lifeless> stub: that would be great
[09:33] <stub> Where does that rule get changed now?
[09:33] <lifeless> the pqm config
[09:33] <lifeless> its out of the tree
[09:34] <wgrant> Heh, the first time it's needed a change in almost three years, a month after I argued that it never needed changing...
[09:34] <stub> :-)
[09:36] <stub> I think we just need to block *-0.sql from landing on launchpad/devel now. No problems landing updates to the scripts, security.cfg or minor db patches.
[09:36] <wgrant> Right.
[09:36] <stub> Anyone see a problem with that rule?
[09:36] <wgrant> Nope. We should also drop the conflict check while we're there, since it doesn't work.
[09:36] <wgrant> And is pointless.
[09:36] <lifeless> fine with me
[09:38] <stub> wgrant: Do you want to file an RT explaining that conflict check thing, or do you want to explain the conflict check thing to me so I can file the RT ?
[09:39] <wgrant> stub: https://pastebin.canonical.com/45073/ is the current hook.
[09:40] <stub> MY EYES!
[09:40] <wgrant> stub: The second bit (bzr ls -0 [...]) is meant to check for conflicts, but doesn't actually work. I considered removing it when we migrated the check from the tree to PQM, since it seems pretty pointless, but decided to make as few changes as possible.
[09:43] <stub> So precommit_hook=[ -z "$(bzr status -S database/schema/ | grep '-0.sql$')" ]     ??
[09:44] <wgrant> stub: Don't need to protect fti.py or anything?
[09:45] <stub> wgrant: fti.py is 50/50 - adding a new index could futz things, changing an existing one will not (the column will exist, it just won't have the expected data in it)
[09:47] <wgrant> Sounds good, then.
[09:47] <wgrant> RT time.
[09:47] <stub> I guess we should block it - we likely won't change anything there anyway until we know where our search is heading.
[09:47] <wgrant> stub: Thanks for the review.
[09:55] <stub> precommit_hook=[ -z "$(bzr status -S database/schema/ | grep -e '\(-0\.sql\|/fti.py\)$')" ]
[09:55] <stub> is what I end up with
[09:56] <wgrant> Looks sensible, as long as it works.
[10:55] <henninge> danilos! ;)
[10:55] <danilos> henninge, :)
[10:55] <danilos> henninge, I don't know what you've been talking about ;)
[10:55] <henninge> danilos: I do, though! Can I please have a review?
[10:56] <danilos> henninge, sure thing
[10:56] <henninge> danilos: diff is only 1075 lines
[10:56] <henninge> https://code.launchpad.net/~henninge/launchpad/devel-605924-hastranslationtemplates/+merge/54470
[10:56] <danilos> henninge, ha-ha-ha
[10:56] <danilos> henninge, ok, I'll take it
[10:56] <henninge> danilos: thanks
[10:58] <danilos> henninge, btw, just looking through proposal text, "shortlist" is especially recommended when you expect something to return a short list
[10:58] <danilos> henninge, because then it catches bugs early
[10:58] <henninge> danilos: oh, i thought it was about cutting a list off.
[10:59] <danilos> henninge, no, it throws an OOPS/exception when hard limit is broken
[10:59] <henninge> ah
[10:59] <henninge> so using shortlist is saying "tell me if this ever gets longer than X"
[11:00] <henninge> danilos: thanks, I did not know that. I am happy to put it back in, then.
[11:00] <danilos> henninge, yeah, it's a developer tool :)
[11:00] <danilos> henninge, I don't know in what context did you drop it, so it all depends on that, but just clarifying what shortlist is about
[11:01] <LPCIBot> Project windmill build #92: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/92/
[11:03] <deryck> Morning, folks.
[11:05] <danilos> henninge, good job clearing the inter-dependency between template count and uses-translations
[11:06] <henninge> yeah, that was strange to see
[11:16] <danilos> henninge, not yours, but line 226 of the diff: "hidding"
[11:29] <danilos> henninge, in TranslationTemplatesCollection, I am surprised target_pillar is not used anywhere, but since it's apparently not, good cleanup there as well :)
[11:30] <henninge> danilos: yes, that was only used to access translation_usage in getCurrentTranslationTemplates
[11:31] <danilos> henninge, also, instead of listifying stuff in tests, I suggest you use assertContentEqual instead
[11:32] <danilos> henninge, unless where you want to compare the order as well
[11:32] <danilos> henninge, fwiw, this is probably irrelevant comment when you get shortlist back :)
[11:33] <danilos> henninge, also, I'd rather see test_has_obsolete_translation_templates as 3 separate tests
[11:33] <danilos> henninge, or 4
[11:36] <danilos> henninge, and also, you probably inserted list() on diff line 116 because you removed the shortlist as well, so that can probably go (and if you decided not to re-insert shortlist, this is where you should use it)
[11:38] <danilos> henninge, r=me
[11:38] <henninge> danilos: yup, that's just because of shortlist.
[11:38] <henninge> danilos: thanks
[11:39] <danilos> henninge, up to you to decide if you want shortlist back or not, not a big deal either way
[11:39] <henninge> danilos: I felt the same about test_translation_templates but I played along with what the rest of the file was doing.
[11:39] <henninge> I may just split up the other tests, too.
[11:40] <danilos> henninge, right, we did write tests that way in the past
[11:40] <henninge> danilos: And I was always the one saying "one assert per test"!
[11:40] <danilos> henninge, that'd be great, but if it gets complex, it might mean a new branch
[11:40]  * bigjools waves at danilos
[11:40] <henninge> I'll have a look
[11:40] <danilos> henninge, heh, well, that is tricky because we sometimes use asserts to make sure input data is right
[11:41] <danilos> bigjools, hi there
[11:41] <henninge> danilos: ok, that is only a guideline.
[11:41] <henninge> ;-)
[11:41] <danilos> bigjools, I hope you just look forward to hearing my lovely voice :)
[11:41] <bigjools> danilos: are you reviewing?  I have a short branch
[11:41] <danilos> bigjools, yeah, I do (but I am disappointed ;)
[11:41] <danilos> bigjools, pass it on, just done with henninge's
[11:41] <bigjools> danilos: I miss your booming presence on the TL calls :)
[11:41] <danilos> henninge, yep, cheers
[11:42] <danilos> bigjools, ok, now I feel better, thanks :)
[11:42] <bigjools> danilos: https://code.launchpad.net/~julian-edwards/launchpad/localdiff-sync-bug-739525/+merge/54496
[11:44] <danilos> bigjools, branch sounds like a nice feature, but you've got a single lint issue so please fix it (I understand it may not be from your changes :)
[11:44] <danilos> looking at the code now
[11:45] <bigjools> :/
[11:45] <LPCIBot> Project windmill build #93: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill/93/
[11:45] <bigjools> it was my lint
[11:48] <danilos> bigjools, I am sad to see a message like "The following sources *would have been* synced if..." go from the real UI
[11:50] <bigjools> :)
[11:50] <wgrant> bigjools: Have you worked out how permissions are going to work?
[11:50] <bigjools> no
[11:50] <wgrant> Heh
[11:50] <danilos> bigjools, r=me, but I'd also remove the "XXX" from a comment about a thing you are not really going to fix unless it proves to be broken
[11:50] <bigjools> ok
[11:50] <bigjools> thanks danilos
[11:51] <bigjools> wgrant: right now it's launchpad.edit on the series
[11:52] <wgrant> bigjools: launchpad.Edit and launchpad.Append (since you need Append to run syncSources)
[11:52] <bigjools> right
[11:52] <bigjools> this will all fall out in the wash when we start doing intensive testing
[11:52] <wgrant> Yeah.
[11:52] <wgrant> And then we realise we need queues.
[11:53] <bigjools> which Steve is doing tomorrow :)
[11:53] <wgrant> And then you have an excuse to fix copying.
[11:53] <bigjools> queues would be nice
[11:53] <bigjools> I might have to badger flacoste and jml about that
[11:53] <jml> mushroom! mushroom!
[11:53] <bigjools> snaaaaaaaake
[13:29] <sinzui> jcsackett: I Untriaged bug 740225. The former rosetta team need to explain if this was inteded and why or if it is a regression. The behaviour is correct for Ubuntu so it appears to be by design
[13:29] <_mup_> Bug #740225: The differences between New and Translated for upstreams was removed <rosetta-imports> <upstream-translations-sharing> <Launchpad itself:New> < https://launchpad.net/bugs/740225 >
[13:36] <stub> Are lp-propose-merge bugs bzr bugs or something else?
[13:39] <jcsackett> sinzui: understood.
[13:42] <jcsackett> sinzui: do you remember the issue you helped oem with regarding filing bugs in IE?
[13:43] <jcsackett> i believe it was an issue with an error popping up on the summary field? i've got an open question about it, and was wondering if there was a bug filed. i can't find one.
[13:44] <sinzui> jcsackett: The JS to populate the matches and enable the continue actions does not work in IE. It is impossible to report a bug since the user is forced to use the guided process
[13:45] <sinzui> jcsackett: The bug is filed and has many dupes. tag: javascript, text ie or ie8 or ie7
[13:45] <jcsackett> ah right, tags!
[13:45]  * jcsackett never remembers tags when bug searching.
[13:46] <sinzui> first match
[13:46] <sinzui> I always use tags but I hate the default ANY, I am not sure I have ever used ANY in a search
[14:02] <abentley> adeuring1: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/js-translation
[14:03] <abentley> adeuring1: https://code.launchpad.net/~abentley/launchpad/js-translation/+merge/54067
[14:06] <henninge> deryck: I'll restart
[14:10] <abentley> adeuring1: do you want to chat in mumble about the template changes?
[14:10] <adeuring1> abentley: no yet, let me first read a bit more
[14:10] <abentley> adeuring1: okay, ping me whenever.
[14:15] <leonardr> danilos, would you take a look at https://code.launchpad.net/~leonardr/lazr.restful/integrate-strict-versioning/+merge/54530 ?
[14:16] <adeuring1> abentley: so your idea is to always render both variants of "X is configured/not configured" and to make the "wrong" variant invisible via CSS, right?
[14:16] <abentley> adeuring1: right.
[14:16] <adeuring1> ok, so no need to mess with the menu:overview stuff, i think
[14:16] <adeuring1> abentley: ^^^
[14:18] <abentley> adeuring1: Actually, we probably do.
[14:18] <adeuring1> abentley: why?
[14:18] <danilos> leonardr, after lunch, sorry
[14:18] <abentley> adeuring1: The icon is supposed to vary between "plus" and "edit".
[14:18] <adeuring1> abentley: ah, right
[14:18] <abentley> adeuring1: Depending on whether there's already a value.
[14:19] <abentley> adeuring1: But that state is frozen when the template is rendered.
[14:19] <adeuring1> right
[14:19] <abentley> adeuring1: So either we get two plusses or we get two edits.
[14:19] <adeuring1> yeah
[14:19] <jam> dear codehosting devs, why is my +junk branch trying to stack on /~sathishmanohar/junk/main
[14:20] <jam> lp:~jameinel/+junk/one-rev-1
[14:20] <jam> ah, stupid me, doing '/junk/" without the +
[14:20] <abentley> jam, right.
[14:20] <jam> I only noticed because it fails on qastaging because 'junk' doesn't exist
[14:26] <jcsackett> danilos or abentley: could i request a review of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/54408?
[14:27] <jam> any way to bulk upload attachments? I have 6 attachments I want to add to a bug, and it is a pain to do them one-by-one
[14:31] <benji> jam: not that I know of; I wonder if a little launchpadlib script would be helpful, but it will take longer to write than just doing the uploads
[14:37] <abentley> jcsackett: sure.
[14:38] <abentley> jcsackett: You say "the branch partially relies on a branch that exposes Question on the webservice".  This sounds like a prerequisite branch to me.
[14:39] <abentley> jcsackett: Do you know about prerequisite branches?
[14:52] <LPCIBot> Project windmill build #94: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/94/
[14:58] <jml> abentley: I learnt a thing about the job system today. It uses Python imports as a registry.
[14:59] <abentley> jml: that doesn't parse.
[15:00] <jml> abentley: as in, it very strongly encourages job sources to be defined as classes that have all of their state on the class so that it can then load these classes using import/module-lookup/getattr-fu in other processes.
[15:01] <abentley> jml: this is true.
[15:02] <jml> abentley: so in this regard, it's using Python's namespace/import system as a registry of job sources. sort of.
[15:03] <jml> abentley: I bumped into this because I thought having an instance job source would make testing easier, so I gave it a try.
[15:03] <abentley> jml: Seems like a stretch to me, unless you think that most python functionality uses imports (by which you mean packages/modules?) as a registry.
[15:04] <jml> abentley: well, maybe it is a stretch. it's just that I can imagine alternative implementations that make as much sense as importing that are more obviously registry-like
[15:04] <abentley> jml: In which case, it doesn't seem worth mentioning.
[15:04] <jml> e.g. pickling the job source to a known directory and passing the filename through to the child process
[15:05] <jml> or having a config file that maps names to ways of acquiring job source objects.
[15:06] <abentley> jml: we actually do have a config that maps names to job source classes.
[15:07] <jml> abentley: class names in Python modules?
[15:09] <abentley> jml: No, when we use cronscripts/run_jobs.py, we pass in a config name, which includes the job source as one of its variables.
[15:10] <abentley> jml: e.g.  packaging_translations
[15:13] <jml> abentley: hmm. that's a more flexible than the TwistedJobRunner. Still assumes a particular mechanism for acquiring the IJobSource object though (it has to be a member of a module, available on import).
[15:14] <abentley> jml: I don't think it's more flexible.  I can easily imagine using it with the TwistedJobRunner.
[15:14] <jml> abentley: you'd have to change TwistedJobRunner first, surely
[15:14] <abentley> jml: what would I need to change?
[15:15] <jml> abentley: the bit where it figures out the import name based on job_source.__name__
[15:15] <abentley> jml: why?
[15:15] <jml> abentley: to use a non-class object as a job source
[15:16] <abentley> jml: I expect an interface to correspond to a class.  Don't you?
[15:16] <jml> abentley: Yes, but that's not what I mean.
[15:17] <jcsackett> abentley: sorry i missed your comment earlier. i know about prereq branches, but the the prereq branch had other stuff that messed up the diff, as i only brought over the webservice bits.
[15:18] <jml> abentley: the TwistedJobRunner theoretically expects a job source object that provides ITwistedJobSource. The implementation demands that it is a class that classProvides ITwistedJobSource.
[15:18] <abentley> jml: From an interface, we get a class, from the class, we get job_source.__name__, what's the issue?
[15:19] <abentley> jml: still not following why I'd need to change TwistedJobRunner to make it work with run_jobs.
[15:19] <jml> oh right.
[15:20] <jml> abentley: run_jobs takes an arbitrary name to import, TwistedJobRunner infers the name from the passed in job source object (which has to be a class)
[15:20] <LPCIBot> Project devel build #569: FAILURE in 4 hr 52 min: https://lpci.wedontsleep.org/job/devel/569/
[15:23] <abentley> jml: right, but these conditions are met for all of our job sources, so I don't need to address that in order to use TwistedJobRunner.
[15:23] <jml> job_source = somethingThatMakesAJobSource(); runner = TwistedJobRunner(job_source, ...); ... will explode unless job_source has a __module__ and __name__ and can be reconstructed by importing "%s.%s" % (job_source.__module__, job_source.__name__)
[15:23] <sinzui> jcsackett: set  ~jcsackett/launchpad/questions-on-webservice  as a dependency of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/54408
[15:23] <jcsackett> sinzui: ok.
[15:24] <jml> abentley: of course. I was trying something different and discovered these conditions.
[15:25] <adeuring1> abentley: I think there is a more fundamental problem with the approach to hide  the "wrong" <li> entries via CSS: If no packaging link is set, we can't generate the links "set source branch", "enable translations", "enable auto sync" at all: We don't know which target to use...
[15:26] <jcsackett> sinzui: is there a way to do that without redoing the proposal?
[15:26] <abentley> adeuring1: I've already addressed that for the branch link.
[15:26] <abentley> jcsackett: You resubmit the proposal.
[15:26] <adeuring1> let me look...
[15:26] <abentley> adeuring1: It creates an empty link.
[15:26] <adeuring1> abentley: ah, right!
[15:27] <sinzui> jcsackett: you may hate me. We should not export Question.priority. It is unused
[15:28] <adeuring1> abentley:  regarding the icons: I think we always have the pencil icon. So I think we don't have to tinker with the menu: stuff
[15:28] <jcsackett> sinzui: that's an easy fix. no need for hate. :-)
[15:29] <abentley> adeuring1: that's nice, but it's inconsistent with how we're handling branches.
[15:30] <abentley> deryck: adeuring1 reports that productseries always has an edit icon, never an add icon, unlike branches.  Should we make them consistent?
[15:34] <deryck> abentley: I would think consistency would be better, yes.
[15:34] <leonardr> benji, i'd like to go over lp:~leonardr/launchpad/explicit-versions with you, both to do review and to bring you up to speed on my changes
[15:35] <abentley> jcsackett:   If you base your branch on the other branch, it's much clearer what came from what.  Why did you only bring over the webservice bits from the other branch?
[15:36] <jcsackett> abentley: prereq was based on devel, this is db-devel. didn't want all the changes coming across before pqm brought them over automatically.
[15:36] <LPCIBot> Project windmill build #95: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill/95/
[15:36] <benji> leonardr: sure; I'm deep in something at the moment; how about after lunch (1 ish)
[15:36] <abentley> deryck: Do you want to change branch so it only uses edit, or productseries so it uses add and edit?
[15:36] <jcsackett> abentley: in retrospect, questions-on-webservice probably should have just been based on db-devel as well.
[15:37] <leonardr> o
[15:37] <leonardr> k
[15:37] <deryck> abentley: can productseries be none intially?  (I assume so)
[15:38] <deryck> abentley: if so, that should behave like branch then.
[15:38] <abentley> deryck: Yes, and this is the most important case.
[15:38] <deryck> abentley: yes, so it should get an add icon to start with, I think.
[15:38] <abentley> adeuring1: ^^ could you do this as part of your work, please?
[15:39] <adeuring1> deryck. abentley: yes.
[15:39] <abentley> adeuring1: thanks.
[15:42] <danilos> leonardr, looks good, r=me
[15:42] <leonardr> great
[15:43] <abentley> jcsackett: I wouldn't worry overmuch about applying the changes before PQM brings them across automatically.  You might get a criss-cross merge, but --lca or --weave merge should handle it fine.
[15:43] <jcsackett> abentley: dig.
[15:43] <jcsackett> if you like, i can merge the prereq completely in before you review.
[15:44] <jcsackett> abentley ^
[15:45] <abentley> jcsackett: I don't think I need that.  It just stuck out as weird, and I didn't want to start reviewing until I understood what was going on.
[15:46] <jcsackett> abentley: got it. sorry for the oddities.:-)
[15:53] <abentley> jcsackett: For your tests, did you consider using WebServiceTestCase?
[15:53] <jcsackett> abentley: i did not. i am not aware of WebServiceTestCase
[15:54] <abentley> jcsackett: It allows you to test your code using launchpadlib.
[15:55] <abentley> jcsackett: So you're testing something closer to what users will actually use, and it's closer to native code, too.
[15:56] <sinzui> jcsackett: I had a few notes about the branch too. I added them to the MP
[15:58] <jcsackett> abentley: seems worth looking at then. :-)
[15:59] <jcsackett> there are a lot of tests i've seen that could benefit from that.
[15:59] <abentley> jcsackett: it's similar to what you're doing in TestSetCommentVisibility, only generic.
[15:59] <sinzui> jcsackett: wgrant. allhands should know about your participation in the 2011 campaign now.
[16:01] <abentley> jcsackett: Why are you testing the XHTML?  This seems like your are testing the webservice implementation, not your exports.
[16:04] <jcsackett> abentley: it looks like even the "clean" diff i pasted in has some noise--if you're looking at TestQuestionRepresentation, that's from the other branch. sorry.
[16:05] <abentley> jcsackett: yes, I was.
[16:05] <jcsackett> i'm not sure why that made it into the diff i generated.
[16:05] <sinzui> abentley: jcsackett: this testing point relates to my experience with anon users and representations. The simple doctests for the representation easily documents what anon users can see
[16:06] <sinzui> jcsackett: and about my anon + IQuestionMessage remark on the Mp, may be we do not want them public, see bug 740208
[16:10] <abentley> jcsackett: Was there a preimplementation discussion?
[16:10] <jcsackett> yes, sinzui and i have talked a lot about how to go about this.
[16:11]  * jcsackett sees he skipped that bit in the proposal.
[16:12] <abentley> jcsackett: 1 out of 1 abentleys recommend lp-propose for all your merge-proposing needs.
[16:13] <stub> abentley: Are lp-propose bugs bzr bugs or some other package?
[16:13] <abentley> stub: bzr, I would say.
[16:14] <jcsackett> abentley: i have actually used lp-propose before, and while it opens a local editor and then pushes the whole thing to lp, it doesn't do so from a template. is there a config step i missed for that?
[16:14] <abentley> jcsackett: You may be missing the lpreview-body plugin.
[16:15] <jcsackett> i am indeed.
[16:17] <abentley> jcsackett: try apt-get install bzr-lpreview-body
[16:19] <jcsackett> i have it now. i'll see if alls well on the next branch.
[16:20] <abentley> jcsackett: cool.
[17:07] <benji> leonardr: ready when you are
[17:08] <leonardr> benji, let's go
[17:08] <leonardr> have you read the mp?
[17:09] <benji> looking at it now
[17:12] <benji> leonardr: ok, the MP makes sense
[17:13] <leonardr> benji: and you understand the basic require_explicit_versions rule, right?
[17:13] <benji> leonardr: yep, I believe so (its intent if not yet its implementation)
[17:14] <leonardr> ok, take a look at apihelpers.py to see how i hack into the implementation
[17:14] <benji> why did you have to add all the patch_entry_explicit_version calls in _schema_circular_imports?  Is it really circular imports or something else?
[17:16] <leonardr> benji: it's something else, but it's the same kind of 'patch everything' logic
[17:16] <leonardr> i'm ok with moving it though the imports would be a pain
[17:17] <benji> just I wonder if making a new module and copying over all the imports and then running that through the linter to show unused imports would work well enough to make it worth it
[17:18] <benji> would those ideally be in the same file where the interface is defined?
[17:20] <leonardr> benji: yeah, but if you're going to go through that much trouble it approaches the amount of work necessary to just stop using it
[17:21] <benji> that makes sense; I'm cool on leaving them where they are.  I might try the move-and-lint trick if I get 15 minutes.
[17:56] <bigjools> night folks
[18:32] <abentley> deryck: chat?
[18:47] <deryck> abentley: I can't sorry.  Sorry.  Having to pull double duty now, since wife just came home sick.  Kids need moderate supervision.
[18:48] <abentley> deryck: okay.  Will want to chat tormorrow about branch picker and vocabulary context.
[18:50] <deryck> abentley: sure.  we can do it first thing tomorrow.
[19:01] <sinzui> jcsackett: mumble?
[19:01] <jcsackett> sinzui: oh, it is 3. one sec.
[19:02] <jcsackett> abentley: my earlier mp is updated, both with new diff and comments.
[19:03] <abentley> jcsackett: cool.  I'll have a look.
[19:16] <sinzui> jcsackett: http://pastebin.ubuntu.com/584448/
[19:46] <jcsackett> abentley: ws_object is now used in the test, and your question about endInteraction was answered.
[20:14] <LPCIBot> Project devel build #570: STILL FAILING in 4 hr 53 min: https://lpci.wedontsleep.org/job/devel/570/
[20:18] <lifeless> gary_poster: hi
[20:18] <lifeless> gary_poster: I noticed this - https://bugs.launchpad.net/launchpad/+bug/741234 - by chance when looking at a timeout
[20:18] <gary_poster> lifeless hi
[20:19] <lifeless> gary_poster: I don't know if you want to pick it up or not, I may well be misremembering which squad changed the visibility rules
[20:19] <_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <Launchpad itself:Triaged> < https://launchpad.net/bugs/741234 >
[20:19] <lifeless> [I probably am misremembering]
[20:19] <gary_poster> lifeless, I don't *think* we touched that...it certainly doesn't ring any bells
[20:19] <lifeless> gary_poster: de nada :)
[20:19] <gary_poster> :-)
[20:20] <jml> lifeless: Red squad will be doing disclosure/visibility once one of the current squads finishes up
[20:22] <lifeless> jml: cool
[20:22] <lifeless> jml: this was missed during a change in the last few months which is why I mentioned it
[20:22] <lifeless> anyhow
[20:22] <lifeless> -> dentist
[20:22] <jml> \o/
[20:32] <sinzui> jcsackett: how goes CVEs?
[20:32] <jml> https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598 – fix for an intermittent failure (I think)
[20:33] <jml> wgrant: ^^
[20:37] <jcsackett> sinzui: i got derailed by a hardware issue, but i think what we chatted about is showing promise.
[20:38] <jcsackett> i'm having to fight my desire to do something about the nested chain that is the various nomination-rows &c.
[20:38] <sinzui> jcsackett: are you working with BugLinksListingView ?
[20:40] <sinzui> I see the pairing of the view to the template is broken. That view ensures can_view_bug is available to avoid security checks, but the template ignores it in two cases. I think that view should also use the trick I showed you to change the security checker on the object so subsequent checks are fast
[20:44] <jcsackett> sinzui: how can you tell it is broken? i recall odd behavior when i was looking at this last which that might explain.
[20:44] <jcsackett> though i just have the recollection of said behavior, and can't recall exactly what it was.
[20:44]  * jcsackett needs to take better notes.
[20:45] <sinzui> jcsackett: view build a dict of bug info to show. It recovered from an Unauthorized error and adds 'can_view_bug': False. The template does not need to call required:launchpad.View on the bug!
[20:50] <sinzui> jcsackett: I am sure the adaption to +bugtasks-and-nominations-table also calls permission checks. Since the view has done the work, we want a fast permission checker on the good ones. We can update the cve-index.pt template to always use can_view_bug
[20:52] <jcsackett> sinzui: dig.
[20:54] <sinzui> jcsackett: I can send you a diff of the changes actually, so you can have an adventure with milestones
[20:57] <jcsackett> sinzui: i'm not sure that's what i would call "adventuring" :-P
[21:02] <wallyworld_> leonardr: mumble?
[21:05] <jml> g'night all.
[21:09] <leonardr> wallyworld, 1 minute, sorry
[21:10] <wallyworld_> np
[21:11] <leonardr> wallyworld, i can hear you
[21:11] <leonardr> wallyworld, go ahead and give me your status, i'll try to figure it out
[21:11] <lifeless> sinzui: jcsackett: are you talking bug security checks?
[21:11] <lifeless> sinzui: jcsackett: if so there is no need for that now, our searches inject the rules.
[21:13] <leonardr> wallyworld: sorry, still not working
[21:13] <lifeless> jml: I wrote the fixture you asked for
[21:14] <sinzui> lifeless: okay good to know. We could reimplement the oddness in the view
[21:16] <lifeless> sinzui: what symptoms are you seeing ?
[21:18] <sinzui> No symptoms. The does very odd things to build a dict of bugs, and the template ignores the work the view did hald the time. We have bool in the dict, which must be faster than adaption
[21:18] <lifeless> sinzui: any bug task gotten via IBugTaskSet.searchTasks will not trigger security lookups; bugs gotten via other methods that do not indirect to searchTasks should be updated to do so
[21:18] <lifeless> sinzui: ok
[21:29] <jml> lifeless: yeah, I saw, thanks.
[21:33] <leonardr> wallyworld_: take a look at lazr.restful.interfaces.IWebBrowserOriginatingRequest
[21:33] <leonardr> launchpad defines an adapter from WebServiceLayer (ie. a web service request) to IWebBrowserOriginatingRequest, in webapp/configure.zcml
[21:39] <leonardr> in _resource.py, applyChanges, lazr.restful casts the current request to IWebBrowserOriginatingRequest
[21:39] <leonardr> if the result is None (because the application never defined an adapter), one thing happens
[21:39] <leonardr> if it's not none (because this is launchpad), another thing happens
[21:58] <wgrant> jml: !
[21:59] <wallyworld_> leonardr: thanks!
[21:59] <leonardr> np
[22:02] <rockstar> huwshimi, hi
[22:02] <huwshimi> rockstar: Hey
[22:03] <rockstar> huwshimi, what particularly about YUI are you struggling with?
[22:04] <huwshimi> rockstar: Oh, nothing in particular (I've just replied to your email).
[22:04] <rockstar> huwshimi, yeah, I saw it.
[22:04] <huwshimi> rockstar: I just don't like the way it does certain things, but I can get over that and use it anyway
[22:05] <rockstar> huwshimi, most of the concerns I've seen from people about YUI (and javascript in general) are because there's something idiomatic that they don't understand.
[22:05] <rockstar> huwshimi, what particularly do you not like though?
[22:05] <rockstar> (It's quite possible that we are doing it wrong it YUI, and I'd like to help fix it if need be)
[22:08] <huwshimi> rockstar: I'm not sure exactly. I need to spend some more time with YUI3 to really be able to help you out with that
[22:44] <sinzui> wgrant: I think you should block about the private bug as 404 change. Many users are confused by this. They think Lp is broken (making bad links)
[22:44] <sinzui> wgrant: s/block/blog/
[22:48] <cody-somerville> In that case why is it 404 instead of 403?
[22:49] <wgrant> cody-somerville: We are moving to deny the existence of private objects, because it is much simpler. :/
[22:49] <wgrant> Private bugs are just about impossible to do sensibly.
[22:49] <wgrant> Without 404ing.
[22:49] <wgrant> (because of the redirects)
[22:49] <sinzui> wgrant: actually, I think switching to NotFound is a bug. We cannot make links that will 404. We need to ensure that the user has permission to see the link we are making
[22:50] <sinzui> wgrant: and yes, because of redirects this can be near impossible
[22:50] <wgrant> sinzui: We don't make links, AFAIK.
[22:50] <wgrant> Hmm.
[22:50] <cody-somerville> what redirects?
[22:50] <wgrant> Except perhaps if the bug is referenced in text.
[22:50] <wgrant> cody-somerville: /bugs/1 -> /ubuntu/+bug/1
[22:50] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[22:50] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[22:50] <wgrant> cody-somerville: /otherproject/+bug/1 -> /ubuntu/+bug/1
[22:50] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[22:50] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[22:50] <poolie> good thing that line is truncated :)
[22:52] <sinzui> wgrant: bug https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/739380 certainly does link to a private bug. I am sure it shows up in the 404 reports
[22:52] <_mup_> Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name':  ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 >
[22:53] <sinzui> wgrant: I think this is another case where the is a right way to do something, but it is more fun to creaft your own links and play with interpolation
[22:54] <sinzui> sorry about the spelling. I am a wreck. I should end my day
[22:54] <lifeless> sinzui: we don't create links to hidden bugs though
[22:55] <cody-somerville> why not just handle this the same way as oh, I dunno... most other websites? :P lol. Sorry to be facetious but LP can't be the first website trying to solve these kinds of problems, can it? :P
[22:55] <lifeless> sinzui: (because we filter all hidden bug objects so they don't show up in miletones, search results etc)
[22:55] <sinzui> lifeless: But we do https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/739380
[22:55] <_mup_> Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name':  ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 >
[22:55] <lifeless> cody-somerville: this is how other websites handle it
[22:55] <sinzui> lifeless: look above the comment box
[22:55] <lifeless> the 'Remember, this bug report is a duplicate of bug #710026. ' ?
[22:56] <lifeless> sinzui: so, this is related to the disclosure work - remember how you were saying that we shouldn't permit adding tasks outside of visibility zones
[22:56] <lifeless> sinzui: same thing - when something is duped on a private bug we need to take disclosure into account
[22:56] <wgrant> lifeless: I thought the duplicate warning avoided linking. Maybe only some of them do.
[22:57] <sinzui> lifeless: I think this relates to an even older rule I have when reviewing code. Do not craft a link that you are not will to write a test for to verify it behaves like the canonical link code.
[22:58] <lifeless> sinzui: sounds plausible to me
[22:58] <lifeless> interestingly
[22:58] <lifeless> sinzui: I can see that private bug
[22:58] <sinzui> your special
[22:58] <lifeless> I'm not an admin
[22:58] <wgrant> Any more, at least.
[22:59] <lifeless> sigh, rub it in :)
[22:59] <sinzui> I am just one of the proles.
[22:59] <lifeless> I'm in ubuntu-bugcontrol
[22:59] <wgrant> If it's apport, your MOTU membership will let you see it.
[22:59] <lifeless> wgrant: ah
[22:59] <lifeless> k
[22:59] <wgrant> Indeed, it is apport.
[22:59] <lifeless> sinzui: so you see a link there
[22:59] <lifeless> sinzui: and you can't see the master bug
[23:00] <lifeless> wgrant: looks to me like apport should have unprivated this
[23:00] <sinzui> I see "Remember, this bug report is a duplicate of bug #710026. Comment here only if you think the duplicate status is wrong."
[23:00] <lifeless> sinzui: and that is linkified ?
[23:00] <sinzui> yes
[23:01] <wgrant> lifeless: Indeed, nothing private there.
[23:02] <lifeless> wgrant: worth filing a bug about this?
[23:03] <wgrant> lifeless: Not sure.
[23:06] <sinzui> I think this instance I see is bug. Isn't the reason the oops reports have a NotFound section is to encourage us to not do stupid thinks to frustrate users.
[23:07] <lifeless> sinzui: indeed, we shouldn't generate links that break
[23:07] <lifeless> we need to teach the linkifier code to rewrite bug references too
[23:08] <lifeless> e,g. https://bugs.l.n./foo/+bugs/NNN -> check visibility and don't link otherwise.
[23:08] <sinzui> The message I see is wrong. Since the bug is private and I cannot see it, I cannot say I think the duplication was a mistake. I have to know to locate a bug contact for the zero-vector bug I cannot see and ask for it to be make pulic of be subscribed
[23:08] <lifeless> which also implies a batch scan-and-check for efficiency
[23:08] <sinzui> That is an daunting task for most users
[23:08] <lifeless> sinzui: I totally agree. I filed a couple of bugs about usability here earlier this week
[23:08] <lifeless> sinzui: let me dig them up
[23:10] <sinzui> oh, yes I do realised that my grievance is goes back to when we issued a 403. Users are just more confused since bugs privacy is volatile, unlike team privacy.
[23:11] <lifeless> thumper: bug 740750 - I think I mailed you.
[23:11] <_mup_> Bug #740750: API timeouts broken and returning no useful data... <regression> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 >
[23:16] <lifeless> bug 334130
[23:16] <_mup_> Bug #334130: misbehaviour in marking duplicates of a private bug <lp-bugs> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/334130 >
[23:16] <lifeless> bug 434733
[23:16] <_mup_> Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 >
[23:16] <lifeless> I can't find the one I thought I filed
[23:17] <lifeless> bug  157899
[23:17] <poolie> lifeless, oh just one more thing
[23:17] <_mup_> Bug #157899: Shouldn't need access to private bug report to reverse a public duplicate marking <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/157899 >
[23:17] <lifeless> bug 136570
[23:17] <_mup_> Bug #136570: Can't unsubscribe from duplicates if dupe is private <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 >
[23:17] <poolie> i see people adding new apis for admin use etc
[23:20] <lifeless> poolie: yes?
[23:21] <poolie> it seems like it's kind of half-baked without a cli
[23:21] <poolie> i don't want to hold things hostage but i was wondering if people could add things to lptools for admin use
[23:21] <poolie> it shouldn't be much more incremental work
[23:21] <lifeless> poolie: I don't think they should
[23:21] <poolie> or, at least, to file a bugtask against lptools
[23:21] <lifeless> poolie: following reasons:
[23:22] <lifeless>  - these apis are not productised; we don't want to have to care about them in the stable api, and lptools is a productised project
[23:22] <lifeless>  - the api client for them should be the web ui, not a cli
[23:23] <poolie> oh
[23:23] <lifeless> I think its fine if a dev things lptools is the best place to do it, but its not where I would encourage them to go with these apis
[23:23] <poolie> are these meant to be internal-use things for ajax only?
[23:23] <poolie> i misunderstood
[23:24] <lifeless> poolie: we have /one/ api, it serves both launchpadlib (python) and a yui launchpad object that all the web ui ajax uses
[23:24] <lifeless> so theres no clear separation, for right or wrong
[23:24] <poolie> what does "not productised" mean in this context?
[23:25] <lifeless> we don't care about API churn
[23:25] <lifeless> we'll change them willynilly as needed
[23:27] <poolie> what is the intended client for them? ajax?
[23:28] <lifeless> I don't know
[23:28] <lifeless> the syadmin request is a button in the ui
[23:28] <lifeless> but the work is being done in spare timeslots
[23:29] <poolie> ok
[23:29] <poolie> i was confused because the bug seemed to say "please add an api"
[23:29] <poolie> i'll add lptools bugtasks
[23:29] <lifeless> the bug was added to reflect the unit of work, for tracking qa
[23:30] <lifeless> poolie: if the api is in devel, which I htink it is, you may not want lptools using it
[23:30] <lifeless> poolie: because lptools is a packaged product
[23:30] <lifeless> I wouldn't want bugs filed on lp if we change this api
[23:30] <poolie> ok
[23:30] <poolie> better to have the function than not at all though
[23:31] <lifeless> poolie: this doesn't seem like a thing that will broadly interest lptools users; I'm confused by your interest in it
[23:31] <poolie> anyhow
[23:31] <poolie> i had the misapprehension that people were adding an api so that other people could write ad hoc scripts to call it
[23:31] <poolie> and in that case i would rather those scripts went into lptools
[23:31] <sinzui> lifeless: one of those bugs may be a duplicate of a bug I reported 5 months ago. I would need to see a TB to be certain. Maybe Gary's team will fix the defect before they declare bug subscriptions ready.
[23:31] <lifeless> they may be; even if that is the case, why is it appropriate for lptools ?
[23:31] <poolie> it's more the general pattern than the specific case
[23:32] <poolie> sorry i've got to go get a haircut, biab
[23:32] <lifeless> poolie: I'm worried about the problem we have with edge and bzr happening here. Talk to you later about it.
[23:37] <lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/434733/comments/4
[23:37] <_mup_> Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 >
[23:37] <lifeless> wgrant: it happens a lot, I think we need to talk to pitti
[23:53] <lifeless> do we still send mail to all duplicates when a master bug is altered, even if the master is privte?
[23:53] <wgrant> lifeless: I'm pretty sure not.
[23:54] <wgrant> Since only direct subscriptions function for private bugs.
[23:55] <lifeless> hmm, then I think I can close one of those bugs off completely
[23:55] <wgrant> Oh?
[23:55] <wgrant> Which?
[23:55] <lifeless> bug 136570
[23:55] <_mup_> Bug #136570: bug mail explaining cause of message has an inaccessible link when the the master is private and the subscription is is via duplicates <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 >
[23:56] <lifeless> don't need to unsubscribe if you don't get mail
[23:57] <lifeless> bug 589878 looks nice, I was thinking of a branch of yours recently I'd love the bug subscribers to all be able to see
[23:57] <_mup_> Bug #589878: bzr branches should be private by default if linked to a private bug <lp-code> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/589878 >


[00:44] <Omnifrog> it randomly studers into a loop and then locks everything up
[00:44] <Omnifrog> unless I can get to a tty and kill it quick enough
[00:45] <Omnifrog> otherwise it's a hard reboot


[12:07] <Keybuk> gnargh, I hate UNIX sometimes
[12:07] <Keybuk> SIGCHLD isn't getting delivered :-/
[12:09] <Keybuk> (gdb) p sigpending (&act.sa_mask)
[12:09] <Keybuk> $34 = 0
[12:09] <Keybuk> (gdb) p sigismember (&act.sa_mask, 17)
[12:09] <Keybuk> $35 = 1
[12:09] <Keybuk> is definitely pending
[12:09] <Keybuk> yet, when I remove the procmask, it doesn't turn up


[19:40] <locodir-user> i am having problems getting my panel to the right settings when i fisrt login it isnt showing the xfce panel
[19:44] <locodir-user> is there a way to get it back to the orignallogin screen
[19:45] <locodir-user> when i am logged in it does not show the xubuntu desktop