[02:41] <jtv> morning peops
[03:26] <jtv> Oh how I hate this… when we're late paying the bill, my ISP regularly stops routing my packets until it's been able to redirect an http request to its "pay up or da bitch gets it" notice.  But how often do we use http these days?
[03:26] <StevenK> Ah yes, my ISP does that too.
[03:27] <StevenK> The way I notice is when my DSL connection gets assigned an internal IP
[03:30] <jtv> I wonder if this could be generalized into the same problem as those annoying redirect-all-your-browser-tabs-with-no-way-back wifi login pages, so that someday some saviour may come up with a helpful protocol.
[03:31] <jtv> "Some annoying twit insists on showing you their web page.  They may just be really proud of it, or they may want money.  I've stopped them from messing with your browser tabs, but click here to see what they have to say."
[03:34] <lifeless> jtv: you mean like all the launchpad operational pages (devpad, lpstats etc)
[03:35] <LPCIBot> Yippie, build fixed!
[03:35] <LPCIBot> Project db-devel build #606: FIXED in 5 hr 30 min: https://lpci.wedontsleep.org/job/db-devel/606/
[03:35] <jtv> lifeless: yes, come to think of it it would be nice there as well.
[03:35] <jtv> Log in once, then reload all those tabs.
[03:36] <jtv> I've lost God knows how many pages to broken login redirects.
[03:38] <jtv> And then there's broken censorship proxies: "your license to use StalinWare™ SafeBrowse® has expired.  Please contact your nearest military dictator for new terms."
[03:38] <lifeless> rofl
[03:39] <jtv> (Although that _is_ one of the funniest things I've ever seen — proprietary commercial software and authoritarian state censorship biting each other)
[03:39] <jtv> I may have misremembered some details of the exact wording, of course.
[03:39] <sinzui> wallyworld_: I think this fixes the badge issue in the picker: http://pastebin.ubuntu.com/616306/
[03:41] <wallyworld_> sinzui: thanks. i had the style elements similar to yours but couldn't get the override aspect to work
[03:41] <sinzui> This is easier to read http://pastebin.ubuntu.com/616309/
[03:43] <sinzui> wallyworld_: I think this markup means we can show only one badge
[03:43] <wallyworld_> sinzui: that css should go in lazr-js though. do we still need it in the lp tree?
[03:44] <sinzui> No keep it in our tree. I am tired of that lib inject rules into Lp
[03:44] <wallyworld_> sinzui: my css was positon:relative; padding-left: 5px and that works for multiple
[03:44] <sinzui> I am sure U1 and landscape do not want us injecting rules into their sites
[03:45] <lifeless> man, all software sucks
[03:45] <wallyworld_> sinzui: ok. i built a lazr-js tar ball with "setup sdist" but that results in lp jsbuild issues which i'm still trying to figure out
[03:45] <sinzui> wallyworld_: I think relative will have surprising results across browsers
[03:46] <wallyworld_> sinzui: so relative isn't interpreted in a starndard way?
[03:46] <lifeless> ekiga, on startup, reads something like all of /dev
[03:46] <sinzui> wallyworld_: I have not seen it be reliable
[03:46] <sinzui> wallyworld_: I just switched my example to relative and it is not working in webkit
[03:47] <wallyworld_> sinzui: i think we need a way of displaying multipe badges though
[03:47] <sinzui> There can be only one primary context
[03:47] <wgrant> sinzui: No.
[03:47] <wgrant> sinzui: Subscribing someone to a multi-task bug.
[03:47] <wgrant> Multiple contexts.
[03:48] <wgrant> (yes, there is a single root context for the page, but that is a bug)
[03:48] <wallyworld_> so we could use a div and put all the badges in there with no "posiiton" style attribute?
[03:50] <sinzui> Well relative does not work for me and I do not think we want to tell abandon branches for one case
[03:50] <sinzui> s/branches/badges/
[03:53] <sinzui> wallyworld_: I can make multiple appear, but they break the bound box and can only be aligned by percentage. It is very unreliable
[03:53] <wallyworld_> sinzui: ok. so just stick to one for now?
[03:53] <wgrant> Can't you just put them in a div, and stick that to the right of the li?
[03:54] <wallyworld_> that's what i was asking :-)
[04:00] <wallyworld_> sinzui: so given that img.badge is a new style and we won't be messing with u1 et al since they won't be using it, could we not include the css in lazr-js?
[04:03] <lifeless> its not a new style is it ?
[04:03] <lifeless> its a picker injected style which we're overriding
[04:04] <wallyworld_> lifeless: it is a new style
[04:04] <wallyworld_> because it pertains to badges being displayed next to the picker item title
[04:05] <wallyworld_> so css "img.badge" is new
[04:06] <sinzui> wallyworld_: this will support a few badges, but I think we need to view it in a few rendering engines:
[04:06] <sinzui> http://pastebin.ubuntu.com/616323/
[04:06] <sinzui> wallyworld_: Yes, these are new classes
[04:06] <wgrant> What's position: initial?
[04:07] <wgrant> I've not seen that before :/
[04:07] <wallyworld_> sinzui: thanks for the new css. so since they are new, i could reasonably put them in lazr-js?
[04:07] <sinzui> Please do not
[04:08] <sinzui> I hate every person who put their sites' rules into Lp that I had ti undo. That is a contributing reason to Lp's CSS woes
[04:08] <sinzui> These rules belong in Lp's CSS
[04:08] <wallyworld_> ok :-)
[04:09] <wallyworld_> i guess i was just thinking that lazr-js should work sensibly "out of the box"
[04:09] <wallyworld_> and downstream could always override stuff as required
[04:10] <sinzui> wallyworld_: This is what the sample looked like in my test: http://people.canonical.com/~curtis/badges.png
[04:10] <wallyworld_> sinzui: nice :-)
[04:11] <sinzui> wallyworld_: The out of the box experience, much like YUI's out of the box experience imposes rules at too many levels many upgrades difficult.
[04:12] <sinzui> As you can see by my diff, our rules were broken last august when we updated yui
[04:13] <wallyworld_> sinzui: sure. so your philospohy is each user of lazr-js needs a stylesheet with all the necessary css rules for the lazr-js widgets defined for their app?
[04:14] <wallyworld_> wgrant: you may be able to help me. i build a lazr-js tarball with setup sdist (after changing __version__ to 1.6DEV-xxx). i change versions.cfg in lp, do a make clean build, but new new js is not being used :-(
[04:14] <wallyworld_> i put the tarball in download cache
[04:14] <wgrant> wallyworld_: rm -r lazr-js/build
[04:14] <wgrant> make jsbuild
[04:15] <wgrant> Ah.
[04:15] <wgrant> make clean_js
[04:15] <wgrant> make jsbuild
[04:15] <wallyworld_> wgrant:  tried that. make clean does it also
[04:15] <wallyworld_> ah didn't try make clean_js
[04:15] <sinzui> wallyworld_: The CSS chain imposes a style, one that happen to not work well with what Lp is trying to do. We should have about 100 CSS rules, but we have about 800. Most rules are struggling to undo a rule defined before it :(
[04:15]  * wallyworld_ tries it
[04:16] <wallyworld_> sinzui: sounds like a job for huwshimi :-)
[04:17] <wallyworld_> sinzui: but forgetting about lp, as a user of a 3rd party library like lazr-js, i expect sensible defaults that i can customise if i wish. but that's only my view. we can discuss over a beer at the epic :-)
[04:20] <wallyworld_> wgrant: something is wrong with the tarball perhaps. a compare with the working one shows only the expected source differences, but when i try and make jsbuild, i get:
[04:20] <wallyworld_>   File "/home/ian/projects/lp-sourcedeps/eggs/lazr_js-1.6DEV_r209-py2.6.egg/lazr/js/build.py", line 72, in update
[04:20] <wallyworld_>     target_fh = open(self.target_file, 'w')
[04:20] <wallyworld_> IOError: [Errno 2] No such file or directory: 'lazr-js/build/lazr.js'
[04:20] <sinzui> wallyworld_: So who uses badge?, what are their image sizes? How many do they require? What is their picker width? How large is their text? These are the kind of questions that were not asked about previous additions, so we need to redefine them
[04:20] <wgrant> wallyworld_: Have you compared the tarballs?
[04:20] <wallyworld_> wgrant: yes
[04:20] <wallyworld_> only the expected changes from an itinial look. i'll fire up meld again
[04:21] <wallyworld_> sinzui:  all good points
[04:21] <wgrant> wallyworld_: Oh, heh.
[04:21] <wgrant> Just reread the error message.
[04:22] <wgrant> lazr-js/build shouldn't have been deleted.
[04:22] <wgrant> It just needed to be emptied.
[04:22] <wgrant> bzr st should tell you.
[04:22] <wallyworld_> wgrant: make clean_js does a rm -f -r lazr-js/build
[04:23] <wgrant> That's unhelpful.
[04:23] <wallyworld_> wgrant: bzr status doesn't complain
[04:24] <sinzui> wallyworld_: the img.badge class may not be needed. I like this more http://pastebin.ubuntu.com/616332/
[04:25]  * wallyworld_ looks
[04:27] <wallyworld_> sinzui: that looks nice and clean. i'll use it. i wasn't passing in any alt attributes. are they strictly required? i would have to modify the IHasAffiliation implementation etc to provide the extra info
[04:28] <wgrant> wallyworld_: I'd have an alt and title.
[04:29] <wgrant> I think.
[04:29] <wgrant> Like team badges do.
[04:29] <wgrant> No alt == accessibility fail
[04:29] <wallyworld_> wgrant: ok. btw, the build.py in the latest lazr-js source tree is brooken :-(
[04:29] <wallyworld_> that's why it won't build :-(
[04:30] <wgrant> Awesome!
[04:30] <wallyworld_> i haven't yet looked to see how it happened
[04:41] <wallyworld_> mwhudson: ping!
[04:41] <mwhudson> wallyworld_: hello
[04:42] <wallyworld_> mwhudson: hi. i'm trying to understand a change made to build.py in lazr-js. was that you per chance?
[04:42] <wallyworld_> its a change to SRC_DIR
[04:42] <mwhudson> wallyworld_: i think that may have been me
[04:42] <wallyworld_> it seems to have broken make jsbuild for lp
[04:42] <mwhudson> wallyworld_: iirc it was so it would work uninstalled
[04:43] <mwhudson> wallyworld_: i'm sorry to hear that
[04:43] <wallyworld_> mwhudson: np. i'm trying to see the best way to fix it
[04:43] <wallyworld_> so that what the change fixed still works and so can lp
[04:44] <wallyworld_> what's thebest way to test your change so that i can mess with it can make both scenarios work?
[04:45] <mwhudson> wallyworld_: put "WSGIScriptAlias /combo /path/to/lazr-js/combo.wsgi" in apache config, restart apache, does combo loader work?
[04:46] <mwhudson> wallyworld_: i'm sure we can change our combo loader deployment to run installed in a virtualenv or something,  which might make the previous version work
[04:47] <wallyworld_> mwhudson: given the change that was made, i'm wondering if it is possible to support both scenarios?
[04:48] <wallyworld_> mwhudson:  one would be to try the new SRC_DIR and revert to the old definition if it isn't there
[04:48] <wallyworld_> a bit hacky perhaps
[04:53] <mwhudson> i guess that works
[04:55] <wallyworld_> mwhudson: actually, i've read the source code a bit - it supports a cmdline option to override the src_dir. i'll see if i can modify the make scripts for lp to pass in the relevant directory
[05:03] <lifeless> huwshimi: hi
[05:03] <lifeless> 16:01 < micahg> lifeless: BTW, I failed to note it was private until after I posted the first reply to you, I guess I'm not used to the bar on top yet :-/
[05:03] <lifeless> 16:02 < lifeless> hmm
[05:03] <lifeless> 16:02 < lifeless> :(
[05:03] <lifeless> 16:02 < micahg> the benefit on the bar on the side was that you could see it all the way down the page, my eyes went straight to the description
[05:03] <lifeless> 16:03 < lifeless> thats worth noting on the bug I think
[05:04] <micahg> lifeless: which bug did you mean for me to note it on?
[05:04] <lifeless> there is one about the privacy banner
[05:04] <micahg> k
[05:05] <StevenK> micahg: Personally, I find the bright red bar enough of a visual warning -- it's bright enough and large enough that my eyes are drawn to it.
[05:06] <huwshimi> lifeless: Thanks
[05:06] <micahg> not if you're ignoring the top 100px of the window (I'm on 1920x1080 at the moment)
[05:07] <micahg> bug 29152?
[05:07] <micahg> oops
[05:07] <_mup_> Bug #29152: Suggestions for FAQ guide <Ubuntu Documentation:Fix Released by robertstoffers> < https://launchpad.net/bugs/29152 >
[05:07] <micahg> bug 298152
[05:07] <_mup_> Bug #298152: privacy portlet is not visible enough for indicating private objects <disclosure> <lp-web> <oem-services> <privacy> <ui> <Launchpad itself:In Progress by huwshimi> < https://launchpad.net/bugs/298152 >
[05:08] <micahg> lifeless: is that the one? ^^
[05:08] <lifeless> yes
[05:09] <StevenK> micahg: I am also on 1920x1080, on a 22 inch LCD screen, and I don't ignore the top 100px of the window
[05:09] <micahg> my screen is 15.6" and I still managed to miss it :)
[05:09] <StevenK> micahg: See a doctor? :-)
[05:14] <micahg> lifeless: commented in the above bug
[05:14] <lifeless> micahg: thanks, appreciate the feedback
[05:28] <cody-somerville> lets get rid of private stuff all together, then no more problem :P
[05:29] <lifeless> cody-somerville: ^^
[05:29] <lifeless> cody-somerville: you'd be out of a job then ;)
[05:29] <cody-somerville> we'd use bugzilla :P
[05:29] <cody-somerville> (sadly of course)
[05:29] <lifeless> I don't see it meeting your partitioned-view needs
[05:30] <StevenK> cody-somerville: Isn't that a downgrade?
[05:30] <cody-somerville> Yes but I doubt we could get approval to run our own launchpad instance :P
[05:31] <lifeless> cody-somerville: still wouldn't do what you say you need ;)
[05:31] <lifeless> cody-somerville: you'd need N separate instances
[05:31] <lifeless> cody-somerville: and I don't see how that is a usability improvement :>
[05:32]  * cody-somerville is being entirely facetious... we'd of course use Microsoft Dynamics CRM :P
[05:32] <cody-somerville> or maybe Microsoft's Team Foundation Server
[05:33]  * StevenK goes to review his lunch
[05:34] <wgrant> That sounds less than ideal.
[05:35] <StevenK> cody-somerville: I'm blaming you for that.
[05:37] <StevenK> cody-somerville: Besides, isn't using a CRM as a bug tracker a bit like using a wiki as an issue tracker?
[05:37] <wgrant> *cough* SharePoint
[05:41] <lifeless> question for the peanut gallery
[05:41] <lifeless> does the codehosting bzr+ssh server reject attempts to creation branches with experimental formats
[05:42] <wgrant> bzr: ERROR: Server sent an unexpected error: ('error', "'Bazaar development format 8\\n'")
[05:42] <lifeless> is that one *in* the bzrlib we run
[05:43] <wgrant> A good question.
[05:44] <wgrant> Seems to be.
[05:44] <lifeless> cool
[05:44] <wgrant> bin/bzr init --development-subtree works.
[05:45]  * lifeless closes wontfix
[06:04] <jtv> stub: I got a review request message for your tests branch.  Did you request a review from me?
[06:05] <stub> I requested a review from 'launchpad'
[06:05] <lifeless> hi stub
[06:05] <stub> yo
[06:06] <stub> I should have gone out drinking last night so I have an excuse for this hangover.
[06:06] <lifeless> :)
[06:06] <StevenK> Haha
[06:07] <lifeless> getting old ?
[06:07] <stub> Falling apart
[06:07] <StevenK> I'm reading The Last Continent, and Rincewind has staggered into the pub, hungover, and the bartender says "You look like you need the hangover cure!" "Oh, what's that?" "More beer!"
[06:10] <jtv> Thanks for the spoiler.
[06:11] <StevenK> It's one joke
[06:11] <jtv> Now I know how my next hangover is going to end.
[06:11] <StevenK> :-)
[06:14] <lifeless> stub: index repack time ?
[06:14] <stub> bug_fti? I did that just two days ago
[06:14] <lifeless> cool,t hanks
[06:14] <lifeless> so something else iz making the slow
[06:15] <stub> Could be another index... bug search again?
[06:16] <lifeless>     Hard / Soft  Page ID
[06:16] <lifeless>       98 /   38  Person:EntryResource:searchTasks
[06:16] <lifeless>       78 /   20  Distribution:EntryResource:searchTasks
[06:16] <lifeless>       59 /    8  POFile:+filter
[06:16] <lifeless>       56 /   15  Distribution:+bugs
[06:16] <lifeless>       52 /   16  MaloneApplication:+bugs
[06:16] <StevenK> How do you repack it? Hopefully it isn't DROP INDEX, CREATE INDEX?
[06:16] <lifeless> no
[06:16] <lifeless> its create drop
[06:24] <stub> create drop rename
[06:25] <lifeless> stub: shall we chat ?
[06:26] <stub> lifeless: sure.
[07:22] <jtv> Do we have a way to specify an adapter from an enumeration to an interface?
[07:23] <jtv> Adapting lazr.enum.DBItem works, but… yuck.
[07:23] <lifeless> eeeeek
[07:23] <lifeless> wouldn't a factory function be better ?
[07:25] <jtv> That's basically what I have, except it's got the name of the interface.
[07:25] <jtv> "I have this enum for one of a number of policies; give me the matching policy implementation."
[07:26] <jtv> (It's "got the name of the interface" only when invoking, obviously, not in implementation)
[07:38] <wgrant> wallyworld_: Your query has a bug.
[07:38] <wgrant> wallyworld_: The outer EmailAddress join query needs to do the PREFERRED check too.
[07:39] <wgrant> wallyworld_: Otherwise you'll return multiple rows for teams with multiple addresses.
[07:39] <wgrant> s/join query/join condition/
[09:20] <mrevell> Good morning
[09:56] <jtv> allenap: and when you're done with stub… https://code.launchpad.net/~jtv/launchpad/db-bug-790761/+merge/63203
[09:57] <allenap> jtv: Brillig :)
[09:57] <StevenK> jtv: I was in line first :-P
[09:57] <allenap> StevenK: I haven't forgotten :)
[09:57] <jtv> StevenK: and you aren't any more?  Good.
[09:57] <StevenK> allenap: :-) Do you need a link?
[09:57] <jtv> I thought "brillig" was a weather condition.
[09:59] <allenap> StevenK: You seem to have something on +activereviews.
[09:59] <StevenK> allenap: If it's 'copies-use-notify', that's it
[09:59] <allenap> Yes.
[10:05] <jtv> bigjools: afaict we create PPCJs in 2 places: "Sync Sources" and "Upgrade Packages."  Which should have which policy?
[10:06] <bigjools> jtv: sync is the "insecure", upgrade is the "sync"
[10:06] <jtv> how perfectly straightforward (!)
[10:06] <bigjools> this naming in the UI needs to be fixed
[10:06] <bigjools> can you do a drive-by?
[10:07] <bigjools> Upgrade should be "mass-sync"
[10:07] <bigjools> the SyncCopyPolicy should be MassSyncCopyPolicy
[10:08] <jtv> Probably best done after Gavin finishes my review; got a sequence of branches in flight right now.
[10:13] <lifeless> evening podeans
[10:15] <bigjools> hello lifeless
[10:15] <jtv> lifeless: *You're* an evening podean.
[10:15] <jtv> That shut him up.  Now, what's an evening podean?
[10:22] <lifeless> pfttt
[10:23] <bigjools> did lifeless just fart?
[10:23] <lifeless> blew a raspberry
[10:27] <jtv> I guess people on his side of the globe fart out the other side.
[10:28] <lifeless> Given you're on the same side of the globe...
[10:29] <bigjools> well he's in between.  the mind boggles
[10:29] <jtv> Nonsense.  I'm on the Northern Hemisphere, so you're upside down.
[10:30] <lifeless> dude, you're so far down you'll slide off sideways
[10:30] <lifeless> and after that, you're clearly southern :>
[10:31] <jtv> Well people did warn me about the slippery slope when I moved here...
[10:31] <lifeless> one night in bangkok
[10:32] <bigjools> confucius say, man who go through check-in desks sideways going to Bangkok
[10:33] <lifeless> whimper
[10:33] <bigjools> right, I have my first legitimate change to use matchers.MatchesStructure in a test \o/
[10:33] <bigjools> chance, even
[10:49] <jtv> bigjools: which policy did you say we could default to?
[10:50] <bigjools> jtv: the old insecure
[10:50] <jtv> Old?
[10:50] <jtv> What's old about it?
[10:50] <bigjools> well you're changing the name to an enum
[10:50] <bigjools> but that one
[10:50] <jtv> Oh, yes I am.  So now it's INSECURE.  :)
[11:19] <jtv> bigjools: I've thrown in a PackageCopyJob.getPolicyImplementation() that gives you the applicable ICopyPolicy.
[11:20] <jtv> (Since you're planning to glue it all together)
[11:20] <bigjools> coo9l
[11:20] <bigjools> why not just "getPolicy" ?
[11:20] <jtv> Because that might cause confusion with PackageCopyPolicy.
[11:20] <jtv> Horrible, I know.
[11:21] <bigjools> what confusion?
[11:21] <jtv> You'd have copy_policy and getPolicy()
[11:21] <jtv> —and they'd give you slightly different things.
[11:21] <bigjools> oh, what does copy_policy return?
[11:21] <jtv> Enum value.
[11:21] <jtv> The enum is called PackageCopyPolicy.
[11:22] <bigjools>  /o\
[11:22] <jtv> ?
[11:22] <jtv> Or is that just the penny of the above horror dropping?
[11:22] <bigjools> yes
[11:22] <bigjools> perhaps s/PackageCopyPolicy/PackageCopyPolicyType/ ?
[11:22] <jtv> Talk to stub — he seems to have a headache he doesn't need
[11:23] <jtv> Aaaaaarrrrgh!
[11:23] <bigjools> PackageCopyPolicy is massively confusing
[11:23] <jtv> PackageCopyPolicyDBEnumItemsListType?
[11:23] <bigjools> there's already a bunch of XXXCopyPolicy objects
[11:23] <jtv> Is there!?
[11:23] <bigjools> :p
[11:23] <jtv> Damn RIAA.
[11:24] <jtv> Sorry, for XXXCopyPolicy it'd be the MPAA.
[11:26] <jtv> bigjools: ah, but those are the actual ICopyPolicy implementations.
[11:26] <bigjools> yes
[11:26] <jtv> So that's not very confusing at all
[11:26] <bigjools> it is to me :/
[11:27] <bigjools> gah
[11:27] <bigjools> whatever, I'm too knackered to argue the toss
[11:27] <jtv> What I have now is: an ICopyPolicy interface, implemented by both SyncCopyPolicy and InsecureCopyPolicy.  That part does not seem difficult.
[11:27] <bigjools> ok
[11:28] <jtv> What does confuse things a bit is that there's a PackageCopyPolicy enum whose items correspond to those two implementing classes.
[11:28] <jtv> But that's about it.
[11:29] <jtv> (And there is no longer a direct inheritance relationship between SyncCopyPolicy and InsecureCopyPolicy.  They just both use a helper class for the common parts).
[11:30] <jtv> Also, and this may help, the docstrings should be fairly clear about the relationship between the policy classes and the policy enum values.
[11:49] <jelmer> allenap: hi
[11:49] <allenap> jelmer: Hi there.
[11:49] <jelmer> allenap: are you still reviewing today?
[11:50] <allenap> jelmer: Yes. I have one review to finish then two more in the queue. I'll be able to do yours but not for a few hours.
[11:50] <jelmer> allenap: (it seems like you're always on call?)
[11:50] <allenap> jelmer: Just Thursdays :)
[11:52] <jelmer> hmm, I just must've submitted my last couple of MPs on Thursdays then.. :)
[12:07] <lifeless> night everyone
[12:08] <allenap> Cheerio.
[12:24] <bigjools> allenap: helleau, can I have a review for the override stuff plz
[12:24] <bigjools> https://code.launchpad.net/~julian-edwards/launchpad/override-class/+merge/63221
[12:24] <jtv> We may have kept him slightly busy.  :)
[12:24] <wallyworld> wgrant: just got back from soccer and saw your message. the outer email join does do the preferred check, unless i am mistaken. did you see the version of the query in the mp?
[12:25] <wgrant> wallyworld: I was looking at the latest rev of your branch at the time.
[12:25] <wgrant> wallyworld: It does that in the WHERE clause.
[12:25] <wgrant> But not in the join condition.
[12:25] <wgrant> So it will join all of them.
[12:25] <wallyworld> let me take a look
[12:25] <wgrant> And teams are exempt from the preferred check in the WHERE, so all of their addresses will show up.
[12:26] <wallyworld> you taking about the query in the mp?
[12:27] <wallyworld> it appears so
[12:27] <wgrant> I'm looking at r13133 of your branch.
[12:27] <wgrant> I don't have the MP nearby. Let's see.
[12:27] <wallyworld> i will have to compare it with the original version of the sql before the changes, but i don't *think* that bit of the logic has changed
[12:28] <wgrant> Hmmm.
[12:28] <wallyworld> and all the tests pass so there's inadequate coverage if there is a problem
[12:28] <wallyworld> i thought there was a comment about ignoring email for teams somewhere
[12:29] <wallyworld> in the code
[12:29] <wallyworld> i will try and find that
[12:29] <wallyworld> actually, it is possible to run both versions of the query (old and new) by turning the featureflag on/off
[12:30] <wallyworld> wgrant: do you have a search term that shows the issue? is it only apparent on dogfood rather than the sample data?
[12:31] <jtv> jcsackett: good morning!  Reviewing today?  If so, https://code.launchpad.net/~jtv/launchpad/db-bug-791737/+merge/63220 :-)
[12:32] <wgrant> wallyworld: Oh, the original query has a DISTINCT.
[12:32] <wgrant> wallyworld: That would probably solve it.
[12:32] <wallyworld> ah
[12:32] <wgrant> Oops.
[12:32] <wgrant> And my extra stuff to return the rank disturbed that.
[12:32] <wgrant> Never mind me.
[12:33] <wallyworld> that's ok. if there is a problem with the query let me know so i can fix it
[12:34] <wallyworld> wgrant: btw, the latest badges css stuff works on chrome but fails on ff4 :-( i'll look into it
[12:34] <wgrant> wallyworld: Fails how?
[12:34] <wallyworld> all the badges are aligned hard right
[12:34] <wallyworld> over the top of each other
[12:34] <wallyworld> nicely spaced on chrome through
[12:35] <wallyworld> i really thought this css shit would be sorted out in 2011
[12:35] <wallyworld> sigh
[12:36] <wallyworld> wgrant: fixed the lazr-js build too. it was indeed a regression in the build.py introduced after rev 206
[12:37] <wgrant> wallyworld: Does it work both ways?
[12:37] <wallyworld> the default is the new way and of the dir it expects isn't there (which it won't be for lp where it runs from the egg) it uses the old way
[12:38] <wallyworld> s/of/if
[12:47] <NCommander> morning wgrant
[12:48] <wgrant> Hi NCommander.
[12:49] <NCommander> wgrant: do you plan to be up for a bit longer? I'd like to bridge the discussion on putting SUPERSEDED packages in the indices with bigjools while you are around
[12:49] <wgrant> NCommander: Not tonight, I'm afraid.
[12:50] <bigjools> I am too busy to have a conversation, but why do you want to do that?
[12:51] <NCommander> bigjools: to work towards making archive skew a thing of the past. Having SUPERSEDED but still alive packages in the indices would make it extremely straightforward with the added advantage that apt-cache will also be able to show the status of a package that is still in a state of transition.
[12:52] <bigjools> you're talking about packages that still have dependencies on them, right?
[12:53] <bigjools> I'd rather fix that properly than hacking the publisher to keep superseded packages in the repo
[12:53] <wgrant> bigjools: I think this may be the proper fix.
[12:53] <bigjools> URGH
[12:53] <wgrant> Hm?
[12:53] <bigjools> please no
[12:53] <wgrant> These packages are superseded.
[12:54] <wgrant> But they're not yet to be removed.
[12:54] <wgrant> Which means they are dominated, but not judged.
[12:54] <wgrant> We already do this.
[12:54] <wgrant> To keep sources around when their binaries are.
[12:54] <bigjools> yes but the implication is that they are disappearing RSN
[12:55] <bigjools> it's a different situation
[12:55] <wgrant> It's the same situation.
[12:55] <wgrant> There is a newer version, but archive consistency constraints prevent the removal.
[12:55] <bigjools> it's not an archive consistency issue
[12:55] <bigjools> it's a dependency issue
[12:56] <wgrant> NCommander: Oh, you are still wanting full dependency checking?
[12:56] <wgrant> Rather than just what Debian has?
[12:56] <NCommander> wgrant: Debian does full dependency checking
[12:57] <wgrant> NCommander: Do you have a code pointer?
[12:57] <wgrant> That's not what I understood.
[12:57] <bigjools> there's a bug about this somewhere as well
[12:57] <NCommander> wgrant: its handled by britney, which is where their images are built from
[12:57] <wgrant> NCommander: That's separate.
[12:57]  * NCommander finds the spec that explains what dak does
[12:58] <wgrant> NCommander: britney handles testing migrations.
[12:58] <wgrant> It's not what keeps unstable installable.
[12:59] <elmo> nothing keeps unstable installable ;-)
[12:59] <wgrant> True.
[12:59] <NCommander> wgrant: yes, but it doesn't matter if unstable is uninstallable if their images are built from testing
[12:59] <wgrant> NCommander: That's completely different from the spec you pointed at last time.
[13:00] <NCommander> wgrant: I'm trying to find it
[13:00] <wgrant> http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
[13:01] <NCommander> http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
[13:01] <NCommander> bah
[13:01] <NCommander> you beat me to it
[13:02] <NCommander> So to be specific, dak itself doesn't do dependency checking, but britney does.
[13:02] <elmo> oh, wow, this spec
[13:02] <elmo> I suggested this *years* ago
[13:02] <elmo> I didn't actually do it though, so...
[13:02] <wgrant> NCommander: It's entirely separate.
[13:03] <wgrant> NCommander: Implementing britney-style consistency in a single suite is a thoroughly different problem.
[13:03] <jtv> bigjools: eod and everything's up for review.  Anything in particular you'd like me to pick up tomorrow morning?
[13:03] <wgrant> And some orders of magnitude less feasiblwe.
[13:03] <NCommander> wgrant: fair enough
[13:03] <NCommander> wgrant: and for what I need, overkill
[13:04] <wgrant> elmo: There are lots of XXXs from 2005 about it.
[13:05] <elmo> it's actually a really good idea
[13:05] <elmo> ;-)
[13:05] <NCommander> wgrant: I suppose its a matter if you see britney as part of Debian publishing infrastructure. I do. I realize opinions on this differ.
[13:05] <wgrant> NCommander: It's more part of their release management infrastructure.
[13:05] <wgrant> But possibly.
[13:07] <NCommander> That being said, from the perspective of someone building images, having all the versions appear is desirable. Then deathrow just needs to be adjusted to make sure death only comes to packages that have been completely superseded
[13:26] <jkakar> Is there an alias for lp:~jkakar/+junk/...?  Having +junk in a branch URL always feels bad.
[13:26] <jkakar> Couldn't it just be +branches or something?
[13:27] <wgrant> Part of the point of +junk is discouragement, I believe.
[13:27] <jkakar> Or maybe +sandbox.
[13:27] <wgrant> Both of those have been suggested. There's a bug about that...
[13:27] <jkakar> wgrant: Well, it works I guess.. but I have a number of things I will never create a project for.
[13:27] <bigjools> it's discouragement
[13:27] <bigjools> we want people to have projects
[13:27] <jkakar> wgrant: For example, I keep my emacs configuration in a branch and push it to lp:~jkakar/+junk/emacs.  I don't need (or want) a project for that.
[13:28] <bigjools> I keep a junk branch for some of my stuff too :)
[13:28] <wgrant> Bug #147407
[13:28] <_mup_> Bug #147407: Junk sounds too harsh <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/147407 >
[13:28] <jkakar> wgrant: Thanks.
[13:29] <jkakar> Why hasn't this been marked 'Opinion'?
[13:29]  * jkakar hides ;b
[13:29] <wgrant> I contest some of the interpretation on that bug, though.
[13:30] <wgrant> Perhaps it is a locale issue.
[13:30] <wgrant> junk does not seem offensive or childish to me.
[13:30] <allenap> bigjools: Sure, I'll review that after I've done a few others.
[13:30] <wgrant> And indeed, that was the term used on a few uni systems for a similar purpose.
[13:31] <wgrant> So who knows.
[13:31] <bigjools> allenap: priority interrupt? :)
[13:31] <StevenK> bigjools: No queue jumping!
[13:31]  * StevenK waves a big stick at bigjools.
[13:31] <bigjools> There has to be some sort of international directive I can invoke
[13:32] <StevenK> The international directive of "Wait your turn, bitch"
[13:32] <wgrant> That's probably just an EU directive.
[13:34] <bigjools> EU directives amount to "do what we say. oh, and give me all your money"
[13:34] <wgrant> I hoped for more of a response than that.
[13:35] <bigjools> EUSSR ;)
[13:37] <StevenK> It can't the USSR, it isn't a Commuist regime.
[13:37] <StevenK> Communist, sigh
[13:38] <bigjools> it has an unelected, authoritarian core, it couldn't be more communist if it tried.
[14:13] <abentley> bac: the buildbot failure doesn't look like something I did.  Was it you, or something intermittent? https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1004
[14:14] <bac> abentley: will look
[14:14] <wgrant> bac, abentley: Spurious. The librarian or other random port service decided to listen on buildd-manager's port.
[14:15] <NCommander> bigjools: re: implementing indexing SUEPRSEDED, it has the additional side effect of allowing apt-get to grab all files on disk, which is useful when you want to grab an older source package that won't leave the archive. I'm curious on why you feel though having SUPERSEDED in th eindex is a bad thing. When they get deathrow'ed, they'll be removed from the index
[14:15] <NCommander> so at most its still a handful of packages
[14:16] <bigjools> NCommander: I will not support indexing superseded.  If they are indexed, they are published.  We need to fix which packages remain published.
[14:17] <wgrant> Sounds like I have some convincing to do.
[14:24] <bigjools> wgrant: it's a *very* strong meme in Soyuz that published = in the index
[14:24] <wgrant> bigjools: Possibly.
[14:24] <allenap> bigjools: I missed your priority interrupt earlier. It came just before X decided that I hadn't seen gdm's loveliness in a while, and that, in the absence of something that is almost, but not quite, entirely unlike tea, to abruptly and irrevocably log me out.
[14:24] <wgrant> More that it's visible to apt, I think.
[14:26] <bigjools> allenap: lovely!
[14:26] <bigjools> wgrant: superseded is a publishing state, not whether the package is actually superseded
[14:27] <wgrant> bigjools: I always interpreted it as an indication that the publication was superseded.
[14:28] <wgrant> bigjools: I think we can sensibly rework this.
[14:28] <wgrant> But it needs much discussion when you are not hideously busy.
[14:28] <wgrant> Which could be a while.
[14:28] <bigjools> yes
[14:28] <bigjools> also, I'm not prepared to spend that much time on it anyway unless it's been officially escalated
[14:29] <bigjools> bit harsh, but there's a million other things that need fixing too
[14:29] <wgrant> Indeed.
[14:30] <allenap> bigjools: I wanted to get the tea thing in even though it doesn't make any sense, and I forgot to ask if you want me to review your branch next, or if I should continue on with jtv's?
[14:31] <bigjools> allenap: nah, I was half joking.  I am sorta blocked on it but I can assume you'll review it with flying colours and just merge it into my dependent branch :)
[14:34] <jcsackett> testSMTPServerIsAvailable is one of the intermittently failing tests we have right now, right?
[14:38] <StevenK> allenap: Many thanks for the review. I thought there was a function to do Person -> formattted address, but neither wgrant or myself could think of one.
[14:53] <jcsackett> sinzui: time to chat this morning?
[14:54] <sinzui> jcsackett: yes
[14:54] <sinzui> let me get some coffee first
[14:55] <jcsackett> ooo. good idea.
[14:55] <bigjools> allenap: I am just adding another method to the branch up for review, did you start it yet?
[14:56] <allenap> bigjools: Nope, not yet.
[14:56] <bigjools> coolio
[14:59] <sinzui> jcsackett: I am ready. sip?
[14:59] <jcsackett> sinzui: sure. ringing you in a moment.
[15:02] <jcsackett> sinzui: having a bit of an issue with empathy. one sec.
[16:09] <abentley> allenap or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/ppa-api/+merge/63170 ?
[16:10] <allenap> abentley: Sure, I'll take it.
[16:10] <abentley> allenap: Thanks.
[16:15] <bigjools> thanks for the review allenap
[16:15] <bigjools> MatchesStructure is great eh
[16:16] <allenap> bigjools: That it is.
[16:46] <allenap> Sayonara jcsackett, happy reviewing :)
[16:47] <jcsackett> ciao, allenap. :-)
[17:28] <dpm> thanks flacoste for testing the lp-get-ul10nstats
[17:28] <dpm> script
[17:29] <sinzui> jcsackett: can you review https://code.launchpad.net/~sinzui/launchpad/picker-suggestion-menu-0/+merge/63260 today?
[17:29] <jcsackett> sinzui: i can do it in just a few moments, in fact. :-)
[17:32] <jcsackett> sinzui: i see text conflict on your MP.
[17:38] <jtv> jcsackett: thanks for the review — I've responded.
[18:02] <LPCIBot> Project windmill-devel build #166: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/166/
[18:08] <jcsackett> jtv: thanks for the explanation. r=me. :-)
[18:08] <jtv> thanks!
[18:26] <bigjools> good night all
[18:36] <jcsackett> sinzui: comment on your MP.
[18:36] <sinzui> jcsackett: I just resolved conflicts.
[18:36] <jcsackett> \o/
[18:37] <sinzui> jcsackett: I see someone listened to lint, but did not run tests. devel is broken, but my branch had the fix
[18:37] <sinzui> yeah for running the tests manually
[18:38] <jcsackett> so the only other thing is if "field.initval-suggestions" was meant to be "field.initial-suggestions" or if initval is correct, sinzui.
[18:38] <sinzui> jcsackett: initval happens to be the name of a field in the existing test. my spell checker hates it
[18:38] <jcsackett> sinzui: dig.
[18:39] <sinzui> I can give it a realistic name or a total nonsense one so we do not think wtf next time
[18:39] <jcsackett> sinzui: if you like. i don't know that it is necessary.
[18:39] <jcsackett> you get an r=me without it.
[18:39] <jcsackett> i am just waiting ofr the diff to update to make it official.
[18:40] <sinzui> Well, since you were confused, and I was too at first, I will improve the name
[18:41] <sinzui> jcsackett: I had a few questions for you in your branch as well
[18:42] <bac> hi matsubara, a lot of those OOPS in your report cause a server error when i try to look them up.
[18:43] <matsubara> bac, can you give me one as an example?
[18:43] <bac> matsubara: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1887O957
[18:45] <matsubara> bac, hmm I'll have a look at the logs to confirm, but I think those oopses are old ones that were removed by the oops-pruner but are still in the database
[18:45] <matsubara> so, the pruner removes it from the file system and when oops-tools tries render it, it can't find the file
[18:45] <bac> matsubara: that one i gave you dates back to march of this year
[18:45] <bac> matsubara: how old before they are pruned?  i assume referenced ones are kept?
[18:46] <matsubara> bac, IIRC pruner is set to delete oopses older than 30 days
[18:46] <jcsackett> sinzui: i saw. i'm preparing a few fixes and will post some answers shortly.
[18:46] <matsubara> bac, yep, the ones referenced in the LP database (bug messages, answers, merge proposals, etc) are kept regardless of its age
[18:47] <bac> matsubara: good to know, thanks
[18:47] <LPCIBot> Project windmill-devel build #167: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/167/
[18:58] <sinzui> I think I have the fix for the windmill fail ^. The picker.js was updated to quiet link, but it was not tested. "temp_spinner !== null" will fail because the object is undefined. The code did not work as we thought it did
[19:32] <LPCIBot> Project windmill-devel build #168: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/168/
[19:41] <jcsackett> sinzui: replied to your comment and pushed up some changes.
[19:44] <matsubara> bac, I filed bug 791975 for that 500 error. Fix is here: https://code.launchpad.net/~matsubara/oops-tools/791975-deleted-oops/+merge/63277. Would you like to review it? :-)
[19:44] <_mup_> Bug #791975: Oops deleted from the filesystem raises an OopsReadError rendering the page <OOPS Tools:Triaged> < https://launchpad.net/bugs/791975 >
[19:47] <jcsackett> matsubara: if bac can't, i can look at it.
[19:48] <matsubara> jcsackett, that'd be great. thanks!
[19:48] <bac> jcsackett: thanks, please do
[19:48]  * jcsackett looks at it.
[19:48] <bac> thanks for the quick fix matsubara
[19:48] <matsubara> you're welcome
[19:50] <jcsackett> matubara: r=me.
[19:50] <jcsackett> matsubara, rather. :-P
[19:50] <matsubara> jcsackett, thank you! :-)
[20:29] <sinzui> jcsackett: I approved your branch
[20:33] <jelmer> mwhudson: hi
[20:33] <jelmer> mwhudson: I'm trying to figure out
[20:33] <jelmer> mwhudson: I'm trying to update bzr on Launchpad, but hitting a strange test failures; I was wondering if you might have an idea
[20:33] <jcsackett> sinzui: cool! thanks. :-)
[20:34] <jelmer> mwhudson: http://pastebin.ubuntu.com/616992/
[20:46] <lifeless> moin
[20:46] <lifeless> statik: we're on today right ?
[20:49] <statik> lifeless, yessir
[20:54] <mwhudson> jelmer: oh god, those tests are difficult
[20:54] <lifeless> delete them all
[20:56] <mwhudson> jelmer: has anything changed in bzr around breaking locks?
[20:56] <mwhudson> jelmer: is that the only test that fails?
[20:57] <LPCIBot> Project windmill-db-devel build #357: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill-db-devel/357/
[21:07] <james_w> wasn't there something about bzr not complaining about its own stale locks?
[21:12] <mwhudson> right, that's in the sort of area that could affect these tests
[21:13] <mwhudson> in fact, it might make some of the games the puller plays unnecessary, and then lifeless' solution (delete the tests, but also the code) comes in to play
[22:06] <lifeless> mwhudson: I was being HHOS
[22:06] <lifeless> mwhudson: but - moving this out to a microservice would be awesome
[22:07] <mwhudson> lifeless: HHOS?
[22:07] <elmo> haha only serious
[22:21] <flacoste> abentley: how do i get the default cover template when using lp-propose?
[22:23] <abentley> flacoste: install lp-review-body (should be in the ppa)
[22:24] <flacoste> abentley: ok, thanks
[22:26] <lifeless> matsubara: whats south ?
[22:26] <matsubara> lifeless, it's the schema migration tool for django
[22:26] <lifeless> thanks
[22:27] <matsubara> lifeless, http://south.aeracode.org/
[22:27] <flacoste> abentley: how does I use it afterwards? i thought lp-propose would use it automatically
[22:29] <abentley> flacoste: It does.  It uses the target branch of the merge proposal to decide whether to supply the launchpad-specific template.
[22:30] <flacoste> abentley: any idea why it didn't pick it over here?
[22:31] <abentley> flacoste: what target branch is it showing?
[22:31] <flacoste> the merge proposal is created with lp:launchpad
[22:31] <flacoste> https://code.launchpad.net/~flacoste/launchpad/bug-365098/+merge/63301
[22:31] <flacoste> was created using lp-propose
[22:31] <flacoste> after having installed the package
[22:32] <flacoste> oh
[22:32] <abentley> flacoste: Do you still have the editor window up?  That gives the exact URL that was used.
[22:33] <flacoste> i see that i have old lpreview and lpreview_body in my .bazaar/Plugins
[22:33] <flacoste> i'll delete those
[22:34] <abentley> flacoste: it should match 'bzr\+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/(db-)?devel'
[22:34] <flacoste> abentley: deleting the plugins in my home directory did the trick :-)
[22:34] <flacoste> sorry for the noise
[22:34] <abentley> flacoste: Oh, cool.
[22:50] <LPCIBot> Project windmill-db-devel build #358: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/358/
[22:50] <maxb> Is there an email interface for opening new questions in the answers app?
[22:56] <sinzui> no
[22:56] <sinzui> maxb: We assume the user is not an engineer and has no idea how to do it even if we built it
[22:57] <maxb> Right. Makes sense. Was just trying to be really sure about a user who was claiming to be unable to access the account that they had asked a question as
[23:07] <wallyworld> sinzui: the positional style "initial" for the badges doesn't work on ff4. however, "relative" works on both ff4 and chrome. I've not come across "initial" before. I only know about "absolute", "fixed" "relative", "static"
[23:10] <lifeless> cody-somerville: hi https://launchpad.net/bugsy/development/
[23:10] <lifeless> cody-somerville: could you check its performance for you please?
[23:11] <cody-somerville> yay! it loads :)
[23:11] <lifeless> what was the render time ?
[23:12] <lifeless> cody-somerville: ^
[23:16] <wallyworld> lifeless: 1.87 seconds for me :-)
[23:17] <lifeless> wallyworld: needs to be cody to test
[23:17] <lifeless> wallyworld: it was scaling due to team membership
[23:17] <wallyworld> ah sorry
[23:19] <lifeless> nothing to be sorry about
[23:19] <lifeless> just explaining why I asked cody rather than just doing it myself :)