[00:06] <poolie> hi wallyworld,thumper
[00:06] <poolie> wgrant
[00:06] <wallyworld> poolie: g'day
[00:06] <lifeless> wallyworld: so remember the query parameters thing
[00:06] <StevenK> wallyworld: O hai. How were your flights?
[00:06] <wgrant> Morning poolie.
[00:06] <wallyworld> lifeless: yeah
[00:06] <lifeless> wallyworld: matsubara says that oops-tools /should/ handle queries with parameters already substituted
[00:07] <lifeless> wallyworld: so the simplest thing is ok to do.
[00:07] <wallyworld> lifeless: \o/
[00:07] <lifeless> if it doesn't handle them, it has code to normalise that we can just fiddle with
[00:07] <lifeless> wallyworld: I thought that might make you happy ;)
[00:07] <thumper> hi poolie
[00:07] <wallyworld> lifeless: very, cause it means i already have the coding done :-)
[00:08] <wallyworld> i need to finish a couple of other things and then i'll get a mp up
[00:08] <wallyworld> StevenK: flights were good - had a spare seat next to me :-)
[00:08]  * StevenK grumbles
[00:09] <wallyworld> StevenK: your flight was full then?
[00:09] <StevenK> Utterly
[00:09] <StevenK> Surprised they weren't people being asked to sit on others laps
[00:10] <wallyworld> wow. you fly to sydney and then cancerra?
[00:10] <wallyworld> s/cancerra/canberra
[00:10] <StevenK> wallyworld: Why would I do that?
[00:10] <wallyworld> StevenK: i thought you lived in canberra?
[00:10] <StevenK> wallyworld: Heh. No.
[00:11]  * wallyworld should change his nic to rambo
[00:14] <StevenK> Yes!
[00:16] <rambo> StevenK: don't mess with me
[00:17] <StevenK> Haha
[00:22] <lifeless> righto
[00:22] <lifeless> time to fire up a garbo job I think
[00:23] <lifeless> I feel the need to code
[00:30] <lifeless> thumper: do you know if there is a bug open about the 'edit' link for a reviewers prior vote taking you to a different page (vs ajaxing it up)
[00:31] <thumper> lifeless: not sure
[00:35] <lifeless> thumper: fyi 707217
[00:35] <lifeless> bah
[00:36] <lifeless> thats a bug number
[00:36] <wgrant> Anyone to review https://code.launchpad.net/~wgrant/launchpad/bug-707189-forgetful-copier/+merge/47341?
[00:36] <lifeless> I'll do it
[00:36] <wgrant> Thanks.
[00:36] <wgrant> It's pretty simple.
[00:36] <lifeless> uhm
[00:36] <lifeless> the unmerged revisions list is huge
[00:36] <wgrant> It is, yes.
[00:36] <wgrant> I was wondering about that.
[00:36] <lifeless> I wonder if jtv's branchrevision change caused that?
[00:37] <wgrant> I presume so.
[00:37] <lifeless> it didn't look like it could
[00:37] <wgrant> No, it didn't.
[00:37] <wgrant> But I don't see what else it could be.
[00:37] <wgrant> Was going to investigate after getting this through.
[00:37] <lifeless> wgrant: while I read, care to file a bug, tagged regression
[00:37] <lifeless> (and thus critical)
[00:38] <StevenK> lifeless: I'm ready to +1 it, if you want to mentor my rewview
[00:38] <StevenK> *review
[00:38] <lifeless> sure
[00:40] <poolie> http://www.flickr.com/photos/mbp_/5386185146/
[00:41] <lifeless> wgrant: tweak
[00:42] <lifeless> StevenK: you need to read a little closer I think :)
[00:42] <StevenK> Hm
[00:42] <StevenK> - distroarchseries=distroarchseries)
[00:42] <StevenK> 26	+ distroarchseries=arch)
[00:42] <lifeless> thats the actual bugfix
[00:42] <StevenK> wgrant: Isn't that supposed to be target_archs ?
[00:42] <lifeless> the rest is sugar to make it clearer, and tests
[00:43] <wgrant> lifeless: Ugh, sorry, copied that from a test above.
[00:43] <lifeless> wgrant: I suspected :)
[00:43] <wgrant> StevenK: 'for arch in target_archs:' precedes that.
[00:43] <lifeless> wgrant: there may be others, that stood out to me
[00:43] <wgrant> StevenK: I could rename arch to target_arch, i suppose.
[00:43] <wgrant> lifeless: I deliberately fixed them all.
[00:43] <StevenK> wgrant: No, it's fine
[00:43] <wgrant> But apparently not.
[00:45] <wgrant> lifeless: https://code.launchpad.net/~jtv/launchpad/forget-branchrevision-id/+merge/46955 <- in lib/lp/code/model/branchmergeproposal.py, the SourceRevision.branch_id == self.target_branch.id condition is new.
[00:46] <wgrant> not bad timing.
[00:46] <wgrant> jtv: Morning.
[00:46] <jtv> hi wgrant!  Evening here.
[00:47] <wgrant> jtv: Any ideas on why https://code.launchpad.net/~wgrant/launchpad/bug-707189-forgetful-copier/+merge/47341? has lots of merged revisions listed as unmerged?
[00:48] <wgrant> There is an extra condition that you added in getUnlandedSourceBranchRevisions.
[00:56] <maxb> wgrant: hi
[00:56] <wgrant> maxb: How did you notice the lpia issue?
[00:56] <wgrant> I presume you don't actually have any lpia users.
[00:57] <maxb> another package unexpectedly went to dependency-wait
[00:57] <wgrant> Ah, of course.
[00:57] <maxb> You're right, if it had been a leaf package, I'd never have noticed :-)
[01:13] <LPCIBot> Project devel build (388): FAILURE in 5 hr 27 min: https://hudson.wedontsleep.org/job/devel/388/
[01:16] <lifeless> hmm
[01:16] <lifeless> I wonder if we can get rid of the tree structure of messages for bugs
[01:16] <lifeless> it seems to add significant overhead
[01:17] <wgrant> Aha.
[01:17] <wgrant> The librarian failures have now shown up on Hudson.
[01:17] <lifeless> aha?
[01:17] <poolie> lifeless, it would give me a warm glow if you run and like Wrested
[01:17] <poolie> not necessarily right now
[01:17] <james_w> hi poolie
[01:17] <lifeless> poolie: I've put it in my toys to play with box
[01:17] <james_w> poolie, did you start a new library?
[01:17] <lifeless> that box is a little full right now though :(
[01:17] <poolie> hi james_w
[01:17] <poolie> :)
[01:18] <lifeless> 'win' https://hudson.wedontsleep.org/job/devel/388/changes
[01:19] <thumper> damn
[01:19] <thumper> I'm slightly confused
[01:20] <thumper> I remember in dallas removing a PPA from a recipe and having it work
[01:20] <thumper> but now it doesn't
[01:20] <thumper> and according to the source, it shouldn't have worked before
[01:20] <lifeless> abentley: (trying to rule stuff out) did you land your translations patch via ec2 land, or direct ?
[01:20] <thumper> and I don't know why it did
[01:21] <poolie> james_w, i did start a new library
[01:21] <poolie> i think it currently imports something from txrestfulclient but not very much
[01:21] <poolie> i don't mean any disrespect
[01:22] <poolie> i just wanted to start from zero so i could understand what was happening
[01:22] <poolie> lplib has kind of a lot of layering between the app and what's on the wire
[01:22] <poolie> i would be happy to turn this into a patch to txrestfulclient etc
[01:22] <poolie> but it will probably change the apis a lot
[01:22] <james_w> right, I've just seen your mail
[01:25] <james_w> replied
[01:25] <james_w> (twice, sorry)
[01:28] <poolie> np, thanks
[01:29] <poolie> turning them into lower and higher layers could be good
[01:29] <poolie> i still think getting an object and then separately populating it is likely to cause bugs
[01:29] <poolie> but imbw
[01:29] <james_w> agreed
[01:30] <james_w> that's what I meant by using this as the building blocks, sorry for not being clear
[01:30] <james_w> that was me trying to keep it familiar to people who had used lplib, but that wasn't the right approach
[01:32] <poolie> right
[01:32] <poolie> are there enough users of txrestfulclient at the moment that we need to worry about keeping it's api stable?
[01:32] <poolie> (that probably is true for launchpadlib for example)
[01:33] <james_w> nope
[01:38] <rambo> thumper: if a branch has a sourcepackage, did we want to include the source package's linked_branches in the related branches list?
[01:39] <thumper> rambo: maybe?
[01:39] <rambo> and if yes, then do we need to collect the linked_branches for each sourcepackage in product.distrosourcepackages when the branch is a product branch?
[01:40] <rambo> would be good to have a proper dataset to try it on
[01:47] <rambo> StevenK: can we have a mumble chat?
[01:57] <StevenK> rambo: Sure
[01:58] <rambo> StevenK: see you at the Blue Oyster
[01:58] <rambo> s/Blue Oyster/Blue Room
[01:58] <StevenK> rambo: You're tempting me to find a clip of the Blue Oyster Bar music
[01:59]  * rambo LOL
[02:00] <lifeless> ahha
[02:00] <lifeless> 84 /  192  BugTask:+index is back at ze top
[02:01] <rambo> StevenK: you got cold feet?
[02:04] <StevenK> rambo: Sorry, you're breaking up very badly
[02:04]  * rambo :-(
[02:11] <lifeless> wgrant: OOPS-1850PPA1004
[02:16] <huwshimi> Does anyone know where the javascript is that handles the advanced search? I've been told it exists, but I can't see it anywhere.
[02:17] <lifeless> huwshimi: what javascript ?
[02:17] <lifeless> huwshimi: its a form submission
[02:17] <lifeless> (which is why the url is terrible; stock html forms don't know about 'optional' fields.)
[02:18] <huwshimi> lifeless: This is what is confusing me.
[02:19] <jtv> wgrant: sorry urgent stuff elsewhere… don't know what's wrong with that MP you pointed out, but could it be that the branch came off devel?  It's proposed for merging into db-devel.
[02:19] <lifeless> huwshimi: you're talking about e.g. https://bugs.launchpad.net/launchpad-project/+bugs?advanced=1
[02:19] <huwshimi> lifeless: Yeah
[02:19] <lifeless> jtv: lp:launchpad is devel these days
[02:19] <jtv> oh!
[02:20] <huwshimi> lifeless: so I'm having a look at simplifying those urls and now I see that the suggestion wasn't to modify the javascript but rather to add it :)
[02:20] <lifeless> huwshimi: :)
[02:20] <lifeless> man, we have a tonne of boilerplate in the source for that page
[02:20] <lifeless> we redefine make_picker for each person picker instance on the page :)
[02:21] <lifeless> :( :( :(
[02:21] <huwshimi> lifeless: Thanks. There was a reason I couldn't find it beyond my lack of familiarity with the source
[02:21] <lifeless> yeah, it doesn't exist :>
[02:33] <wallyworld> thumper: just talked with stevenk, will include link_branches off the context branch's sourcepackage in the related branches list
[02:34] <wallyworld> s/link_branches/linked_branches
[02:41] <thumper> wallyworld: ok
[02:43] <lifeless> ok, i'm going crazy
[02:45] <lifeless> whats the difference between
[02:45] <lifeless> IBugComment
[02:45] <lifeless> and
[02:45] <lifeless> IBugMessage
[02:45] <lifeless> other than spelling
[02:47] <lifeless> ... one is in browser code

[03:04]  * thumper wandesr off
[03:04]  * thumper needs coffee badly
[05:27]  * StevenK blinks at his new MP including lots of unmerged revs
[05:40] <wgrant> StevenK: We believe that it's fallout from jtv's BranchRevision.id changes a couple of days back.
[05:40] <wgrant> I haven't investigated thoroughly.
[05:40] <StevenK> Right
[05:40] <StevenK> That makes a vague sort of sense
[05:44] <StevenK> thumper: rofl:
[05:44] <StevenK>         # XXX MichaelHudson 2010-01-13: Write _mergeSourcePackageRecipes!
[05:44] <StevenK>         #self._mergeSourcePackageRecipes(cur, from_id, to_id))
[06:04] <thumper> heh
[06:12] <lifeless> StevenK: so, I think you're changing the wrong part of the system
[06:12] <lifeless> StevenK: I've suggested a better change in the review.
[06:12] <lifeless> StevenK: the red flag that went off was 'filtering in python'
[06:12] <StevenK> You haven't yet, it seems
[06:14] <StevenK> lifeless: I'm about to head out, but I would like to get the interval request_daily_builds runs at down to 10 minutes, which I think is sufficent to not really worry with more granularity
[06:15] <lifeless> StevenK: why 10 minutes? whats the overall goal here.
[06:15] <StevenK> Out of time, sorry
[06:15] <lifeless> later then
[06:15] <lifeless> anyhow, my comment applies regardless of the granularity
[06:19] <LPCIBot> Project devel build (389): STILL FAILING in 5 hr 5 min: https://hudson.wedontsleep.org/job/devel/389/
[06:19] <LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=705197] Replaces use of storm.base.Storm
[06:19] <LPCIBot> with a new class, Stormbase,
[06:19] <LPCIBot> which descends from base.Storm but adds SQLObject's __storm methods.
[06:19] <LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][no-qa] Migrate translations to new API
[06:54]  * huwshimi signs off
[08:32] <adeuring> good morning
[08:56] <al-maisan> moin adeuring :)
[08:57] <adeuring> hi al-maisan!
[11:28] <Ursinha> good morning launchpad
[11:37] <jml> Ursinha: good morning.
[12:03] <deryck> Morning, all.
[12:28]  * gmb lunches
[13:56] <jcsackett> morning, all.
[14:00] <bac> benji: do you have a prefered day to do OCR?  since i'll be mentoring you we'll both need to commit to that day.  my slot is currently friday.
[14:02] <deryck> adeuring, ping for standup
[14:02] <adeuring> oops, thanks
[14:19] <adeuring> abentley: I'm pushing lp:~adeuring/launchpad/translation-fixing3 to LP righ now
[14:25] <dpm_> hi jml, quick question: if I want to know in more detail how the LP api docs are generated and published, who should I best talk to?
[14:25] <leonardr> dpm_: i can help you
[14:26] <dpm_> leonardr, ah, great.
[14:27] <dpm_> leonardr, I've got a few questions on that, let me send you an e-mail.
[14:27] <leonardr> ok
[14:42] <abentley> adeuring, ack
[14:44] <jcsackett> where can one lookup what the timeout thresholds are for qastaging/staging?
[14:45] <jml> jcsackett: good questions
[14:45] <flacoste> jml: my calendar still show the product stand-up, i thought you changed it yesterday, google brokeness or you reverted that devision?
[14:45] <jml> flacoste: starting next week
[14:46] <flacoste> jcsackett: lp:lp-production-configs
[14:46] <flacoste> jml: ok!
[14:46] <jcsackett> flacoste: thanks.
[14:46] <jml> flacoste: you are welcome to join us.
[14:51] <sinzui> salgado: do you have time to review https://code.launchpad.net/~wallyworld/launchpad/recipe-find-related-branches/+merge/47367
[14:51] <salgado> sinzui, sure. can it be after my lunch?
[14:52] <sinzui> I think that will be fine. wallyworld is asleep for the next few hours
[14:52] <salgado> cool; I'll do it then
[15:13] <bigjools> jml: hi
[15:14] <jml> bigjools: hi. on a call atm.
[15:14] <bigjools> ah ok, will wait around
[15:28] <bigjools> jml: so when you're off your call I could do with some help fixing an ec2/paramiko problem, it can't find my ssh keys :(
[15:28] <jml> bigjools: how can I help you
[15:28] <jml> bigjools: ahh.
[15:29] <bigjools> heh, snap
[15:29] <bigjools> I figured you're a knowledgeable chap
[15:29] <jml> bigjools: can you paste the error?
[15:29] <bigjools> ec2: ERROR: You must have an ssh agent running with keys installed that will allow the script to access Launchpad and get your branch.
[15:29] <jml> I know some things
[15:29] <bigjools> if I run the paramiko code it uses, I can re-create.  get_keys() returns nowt.
[15:29] <bigjools> I do have an ssh agent running
[15:30] <jml> bigjools: what keys are in the agent?
[15:30] <bigjools> oh god, do I need to manually ssh-add them? .... :/
[15:30] <jml> bigjools: umm... I don't *think* so.
[15:30] <jml> bigjools: ssh-add -l should list
[15:30] <bigjools> I just did ssh-add and it works now
[15:31] <jml> ahh.
[15:31] <bigjools> :(
[15:31] <jml> it ought to just get them from... somewhere
[15:31] <leonardr> gmb, or anyone else who wants an easy branch to review: https://code.launchpad.net/~leonardr/lazr.restful/web-link-wadl/+merge/47404
[15:31]  * jml feels embarrassed for not knowing
[15:31] <bigjools> it ought to
[15:31] <gmb> leonardr: Sure, I'll take easy work.
[15:31] <bigjools> this is my maiden ec2 run
[15:31] <jml> bigjools: I can't recall manually adding a key using ssh-add on this laptop
[15:32] <bigjools> it might be an artefact of using kubuntu
[15:32] <maxb> Normally you need to ssh-add keys if you're using ssh-agent
[15:32] <jml> bigjools: maybe. your key is in ~/.ssh/id_[rd]sa(.pub)?, right?
[15:32] <bigjools> that's what I thought too
[15:32]  * gmb thinks that we need a better way to maintain state on the review queue than using the topic. There's too much of it to be helpful in this channel.
[15:32] <maxb> Later Ubuntu's gnome keyring stuff does weird stuff, which I carefully turn off
[15:33] <bigjools> jml: yes
[15:33] <jml> maxb: maybe that's it.
[15:33] <bigjools> you'd think that paramiko would look in ~/.ssh
[15:33] <jcsackett> gmb: yes.
[15:33] <jcsackett> i was noting that yesterday.
[15:34] <gmb> jcsackett: I'll mail the list about it after I've done this review. Maybe we should just use +activereviews and claim reviews as we start them.
[15:35] <jml> gmb: that seems a sensible approach.
[15:35] <gmb> Yay, I said something that made sense. The jet lag must be receding.
[15:36]  * gmb waits for the obvious rejoinder
[15:40] <bigjools> I am all out of joke juice this morning
[15:43] <gmb> leonardr: In your diff it looks like there's a missing or extra single quote:
[15:43] <gmb> 113	+      <param style="plain" name="web_link" path="$[web_link']"
[15:43] <gmb> (specifically $[web_link'])
[15:43] <leonardr> gmb, thanks
[15:48] <gmb> leonardr: r=me.
[15:48]  * gmb goes off call
[16:23] <jcsackett> sinzui: do you recall where one finds oops logs for qastaging?
[16:29] <sinzui> jcsackett: yes
[16:29] <sinzui> jcsackett: https://devpad.canonical.com/~lpqateam/ contains the reports we are gathering and the historical reports
[16:30] <jcsackett> sinzui: ah, thanks.
[16:30]  * jcsackett bookmarks
[16:44] <adeuring> henninge_: can you give me a hint how to replace the call of updateTranslation() in stories/standalone/xx-translationmessage-translate.txt?
[16:55] <jcsackett> sinzui: any notion where the raw oops files go? i recall you pointing it out to me once. i need to fetch a particular oops that happened on qastaging while i was qaing.
[16:55] <jcsackett> i want to make certain my branch is not the cause.
[16:55] <sinzui> jcsackett: yes, somewhere in var
[16:55] <sinzui> I can look in a minute
[17:02] <jcsackett> sinzui: i can dig through var, just needed to narrow it down from /
[17:18] <jcsackett> sinzui: found what i needed, thanks. :-)
[17:21] <bryceh> deryck, we're seeing Return of the Living Unknown with bug #707478
[17:21] <_mup_> Bug #707478: Freedesktop bug watches are (incorrectly) updated with "importance unknown" <Launchpad itself:Confirmed> < https://launchpad.net/bugs/707478 >
[17:21] <deryck> bryceh, ah, that sucks.
[17:21]  * deryck looks more closely at the bug
[17:27] <deryck> bryceh, so if this just appeared today, I would guess something suddenly changed in the upstream tracker, as you noted in the bug.
[17:27] <deryck> bryceh, did you notice anything upstream that seems different?
[17:28] <bryceh> deryck, no, however my upstream cgi tool thingee quit working about a month ago
[17:28] <bryceh> which I suspect was due to upstream changes to their new bug form
[17:29] <deryck> ah
[17:29]  * bryceh goes to look
[17:29] <deryck> bryceh, if you can spare the time to hunt down what's changed upstream, and dump it in the bug, that bug gets seriously easier to fix.
 bryyce: Do you know why all these bug watches are getting their importance set to unknown?
 was just going to ask about that -- it looks like a bug in the gnome bugzilla status parser?
[17:36] <jml> benji, gary_poster: wikipedia's zope article has this sentence: "BlueBream (earlier called Zope 3) is less widespread but underlies several large sites, including Launchpad"
[17:36] <jml> I'm not quite sure what to make of it :)
[17:36] <gary_poster> heh
[17:37] <gary_poster> until we get rid of zope.app.*, I'd say they have a point, jml :-)
[17:42] <LPCIBot> Yippie, build fixed!
[17:42] <LPCIBot> Project devel build (390): FIXED in 4 hr 59 min: https://hudson.wedontsleep.org/job/devel/390/
[17:53] <bigjools> how freakin awesome is this https://code.launchpad.net/+daily-builds - 250!
[18:02] <jml> bigjools: that is pretty good :)
[18:03] <jml> I like that it goes down to 158 when you select "last 30 days". Software is hard.
[18:03] <bigjools> it's been about 1 year since we started the daily builds project
[18:03] <jml> yeah.
[18:04] <bigjools> the hard bit went surprisingly quickly
[18:04] <bigjools> then the niggles came
[18:04] <jml> incidentally, we really need to display lists of data better than that.
[18:06] <leonardr> hey, gary
[18:06] <leonardr> a while ago i had a lazr problem with tests picking up the system libraries instead of the libraries in the source tree i was testing
[18:06] <leonardr> you fixed this by changing the [interpreter] recipe to z3c.recipe.scripts
[18:06] <leonardr> i believe you helped me fix lazr.restful
[18:07] <leonardr> i'm having the same problem with lazr.restfulclient now, and i can't figure out the solution
[18:12] <bryceh> deryck, well, dunno if this has to do with the Importance bug, but I sorted out the problem with my upload tool - had to switch from POSTing the data to bz, to doing it via GET
[18:13] <gary_poster> leonardr: I didn't fix lazr.restful
[18:13] <dobey> how often is loggerhead updated for bazaar.launchpad.net?
[18:13] <gary_poster> It is using a recipe that isn't upgraded to the new stuff
[18:13] <gary_poster> lazr.restfulclient should be easier
[18:13] <deryck> bryceh, hmm, ok.  likely not causing the importance issue, but could be related to the same change.
[18:13] <bryceh> deryck, https://bugs.freedesktop.org/page.cgi?id=release-notes.html isn't mentioning anything obvious to have to do with that change
[18:14] <gary_poster> leonardr: zc.recipe.egg -> z3c.recipe.scripts, and then use the new zc.buildout
[18:14] <gary_poster> (1.5.2 IIRC)
[18:14] <deryck> bryceh, I'll triage it, and hopefully someone on one of the maintenance teams can take a look.
[18:14] <bryceh> deryck, also btw kees' assumption of breakage with gnome bugzilla turned out to be a false positive one we investigated.  So this seems localized to the fdo bz
[18:15] <leonardr> gary: i think i'm stuck on "use the new zc.buildout". how?
[18:15] <deryck> bryceh, ok, thanks
[18:15] <bryceh> deryck, thanks.
[18:16] <gary_poster> leonardr: 1) versions.cfg 2) new bootstrap.py 3) maybe update Makefile if it seems to refer to a specific version of buildout when it calls bootstrap
[18:17] <leonardr> ok, trying it
[18:17] <jml> lifeless: what steps are left for removing our dependence on z.testing layers?
[18:17] <jml> (it seems a thing I can tug away at in my spare hacking time)
[18:19] <leonardr> gary: i'm going to paste this stuff in rather than try to try to figure out exactly what's going on
[18:19] <leonardr> The version, 1.2.3b2, is not consistent with the requirement, 'zc.recipe.egg>=1.3.0'.
[18:19] <leonardr> ah, maybe i figured it out
[18:19] <gary_poster> k
[18:22] <leonardr> gary: i got it to work, but only with allow-picked-versions=true. what do i need to do now?
[18:23] <gary_poster> leonardr: figure out the versions that are being used, and update them in versions.cfg.  To figure out, ./bin/buildout -vv | grep 'Picked:' .  I usually then sort the output in Python or my editor or something
[18:23] <gary_poster> (and remove dupes)
[18:24] <leonardr> gary, thanks a lot
[18:24] <gary_poster> np leonardr
[18:26] <jml> jelmer: btw, what was the RT for the bzr/bzr-builder stuff for the buildds?
[18:26] <leonardr> gary: i can now run buildout but i'm still getting the error. i'm going to try completely form scratch, but any other ideas?
[18:27] <gary_poster> leonardr: still what error?  you mean, finding some package or other?
[18:27]  * gary_poster has call in 3
[18:27] <leonardr> gary: when i run the tests it still uses the local packages
[18:27]  * leonardr can work on something else, np
[18:28] <gary_poster> leonardr: put branch up somewhere and tell me what it is and I will look
[18:28] <leonardr> i think there's a bootstrap.py problem
[18:28] <gary_poster> ah, may be
[18:36] <jcsackett> leonardr: i have some  more questions from what i was asking you about yesterday. have some time?
[18:37] <leonardr> jcsackett, sure
[18:38] <jcsackett> leonardr: so, i ran with pdb in the section of _resource you recommended, and it's entering there but skipping the "if IClient..." bit.
[18:39] <jcsackett> digging in, i discovered that webservice_error only works on exceptions raised by the exported method. but i've set the exported method to reraise, and still no dice. thoughts?
[18:39] <jcsackett> leonardr: if mumble is better for you than irc, let me know. this does get muddled in text form. :-P
[18:46] <leonardr> gary, whenever you have time, lp:~leonardr/lazr.restfulclient/test-2
[18:46] <leonardr> ok, jcsackett...
[18:46] <gary_poster> ack
[18:46] <jcsackett> leonardr: yeah. lot of info to parse. feel free to force me to give it in smaller chunks. :-)
[18:51] <leonardr> jcsackett: try calling lazr.restful.error.expose on the exception before re-raising
[18:52] <leonardr> we seem to have switched to a system where individual exceptions must be marked--i don't remember this code
[18:54] <jcsackett> leonardr: got it in one. i had been told to avoid expose in the past, and evidently i then forgot about it. thanks for the reminder.
[19:12]  * jml dinner
[19:14] <lifeless> jml: graph optmisation for fixtures
[19:15] <jml> lifeless: which I guess depends on a declarative syntax for fixtures.
[19:15] <lifeless> jml: I don't think it does
[19:15]  * jml blinks
[19:15] <lifeless> I think it depends on an external dependency graph api to be exposed by fixtures
[19:16] <bigjools> lifeless: morning
[19:16] <jml> lifeless: hmm. I think I remember you talking about this before and me not quite understanding.
[19:16] <lifeless> hi bigjools
[19:17] <jml> lifeless: I will consult my archives.
[19:17] <jml> lifeless: meanwhile, I solicit your feedback on https://bugs.launchpad.net/launchpad/+bug/707524
[19:17] <_mup_> Bug #707524: Debugging branch access problems requires running custom scripts against live data <Launchpad itself:Triaged> < https://launchpad.net/bugs/707524 >
[19:17] <bigjools> lifeless: I've been experimenting with queries/schemas and adding the debversion_sort_key as a column turns a 350ms query into a 200ms one on dogfood.  I'm going to prepare a schema patch in advance of code changes if you still agree it's a good direction?
[19:27] <lifeless> jml: I will look at that shortly
[19:28] <lifeless> bigjools: I think that that is a conservative denormalisation we should be able to trivially keep synced which can offer significant performance benefits
[19:28] <lifeless> bigjools: e.g. 'fine by me'
[19:28] <bigjools> :)
[19:29] <lifeless> bigjools: I'm going to send a mail this morning as perf tuesday wrapup talking about the analysis I did on this
[19:29] <bigjools> great
[19:29] <bigjools> once we get the new column I can stick an index on it as well
[19:29] <lifeless> there may be other such cross-table situations where we have missed the actual cost
[19:29] <lifeless> bigjools: what is binarypackagename for ?
[19:30] <gary_poster> leonardr: The bootstrap you have in test-2 is  not right.  use the one from launchpadlib
[19:30] <bigjools> lifeless: in what context?
[19:30] <lifeless> Launchpads db schema
[19:30] <bigjools> it, er, stores binary package names :)
[19:30] <leonardr> gary: i'm pretty sure i did that before i pushed. let me double check
[19:30] <leonardr> obviously i did something wrong if you're not seeing that though
[19:30] <gary_poster> on call again :-P
[19:31] <lifeless> bigjools: why ;) - was it simply 'well thats third normal form', or something deeper ?
[19:31] <lifeless> I need to go cook breakfast
[19:31] <lifeless> back shortly
[19:31] <bigjools> lifeless: it's been like that since well before my time - I assume it was to save db space
[19:32] <lifeless> bigjools: note that if it was inlined into binary package release we could sort from index
[19:32] <lifeless> (even without a debversion_sort_key column)
[19:33] <bigjools> possibly
[19:33] <lifeless> (we probably would want a debversion_sort_key column still)
[19:33] <bigjools> yes, it's effectively pre-caching the result of a slow function
[20:04] <lifeless> bigjools: sinzui: bug 707478 - would one of you like to nab this as a zomg situation ?
[20:04] <_mup_> Bug #707478: Freedesktop bug watches are (incorrectly) updated with "importance unknown" <bugwatch> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707478 >
[20:05] <lifeless> deryck: hey
[20:06] <lifeless> deryck: wondering if you can help me figure out how to qa the front of the queue
[20:06] <sinzui> I do not think this is ready to code yet. No one on my team could start this until it is clear what has to change.
[20:06] <bigjools> same here - I am on my own until tomorrow when Gavin is around, he could look then if it can wait
[20:07] <deryck> lifeless, hey, let me look at the queue and see.
[20:07] <lifeless> so, on operational issues, I don't know that waiting for RTC makes a lot of sense : there is investigation needed for sure, but thats no different to needing to do db analysis when figuring out teamparticipation corruption, for instance.
[20:08] <lifeless> flacoste: what do you think?
[20:09] <thumper> morning
[20:09] <flacoste> lifeless: i'd agree, but at the same time, i think it makes sense to leave that for allenap to look at tomorrow
[20:09] <sinzui> jcsackett: you question-state bug might be one test and one guard, but is `./bin/test -vvc -m lp.answers` fails, talk to me
[20:09] <deryck> lifeless, we usually mark checkwatches bugs qa-untestable.  With some trackers -- maybe mantis is one -- we can run checkwatches from staging.  Sometimes we get odd connection issues with this.  usually to do with ssl, IIRC.
[20:10] <flacoste> unless someone is ready to start something fresh
[20:10] <jcsackett> sinzui: dig. thanks.
[20:10] <flacoste> in which case, they could start, but they'd likely to have to talk to allenap or gmb at this point
[20:11] <lifeless> deryck: so I might mark this qa-untestable then
[20:11] <flacoste> lifeless, deryck: we have a long-standing RT to set-up some bug trackers for QA purpose
[20:11] <flacoste> it sat very high the queue
[20:11] <SpamapS> "Bug watch updates for Red Hat Bugzilla are disabled.
[20:11] <flacoste> but we never got to it
[20:11] <SpamapS> :( how come?
[20:11] <lifeless> deryck: does that seem ok ?
[20:12] <lifeless> bigjools: would it be ok with you if we assign this fdo bug to allenap ?
[20:13] <bigjools> yep, I was going to suggest it
[20:13] <lifeless> SpamapS: dunno.
[20:13] <bigjools> lifeless: what; the bug?  I'll do it
[20:13] <bigjools> what's
[20:13] <lifeless> https://bugs.launchpad.net/launchpad/+bug/707478
[20:13] <_mup_> Bug #707478: Freedesktop bug watches are (incorrectly) updated with "importance unknown" <bugwatch> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707478 >
[20:13] <lifeless> thanks!
[20:14] <deryck> lifeless, yes, that seems fine with me.
[20:14] <deryck> flacoste, we never got that RT finished off because it required coordination with LOSAs and they never responded on it before we moved on to other work, so I never pushed it further.
[20:15] <flacoste> deryck: we meant losa in this case
[20:15] <lifeless> bigjools: https://bugs.launchpad.net/launchpad/+bug/660433 - I'm inclined to untestable that as well
[20:15] <_mup_> Bug #660433: lucid support timeframe information not updated for NEW packages in lucid-updates <lp-soyuz> <qa-needstesting> <Launchpad itself:Fix Committed by allenap> < https://launchpad.net/bugs/660433 >
[20:16] <lifeless> bigjools: but I don't have a deep enough understanding of this area to be sure that that is wise :)
[20:16] <bigjools> lifeless: that's perfectly testable on DF
[20:16] <lifeless> bigjools: ah! what is required to test it ?
[20:16] <bigjools> I usually get pitti to do an upload, run the publisher, then ask him to look at the Packages file
[20:17] <lifeless> ok, so in principle we could do on qas once we have an archive for it
[20:17] <bigjools> please don't skip QA on publisher changes :)
[20:17] <bigjools> yes
[20:20] <lifeless> bigjools: this is cron.germinate
[20:20] <bigjools> yeah
[20:20] <lifeless> does it actually need an upload at all ?
[20:20] <bigjools> yes, or the publisher has nothing to do
[20:20] <lifeless> it looks like it will do work regardless
[20:21] <lifeless> bigjools: would an upload to universe be sufficient ?
[20:21] <bigjools> it will, but it depends on whether new input is needed
[20:21] <bigjools> I am not very familiar with the changes
[20:21] <lifeless> https://code.launchpad.net/~mvo/launchpad/support-timeframe-fix-660433/+merge/38503 - the english at the top is reasonably clear
[20:22] <lifeless> packages that come into NEW
[20:22] <lifeless> were not getting support timeframe set correctly
[20:22] <bigjools> ok it's going to change existing stuff
[20:23] <lifeless> AFAICT we could just run it
[20:23] <lifeless> and diff the more-extras.override files
[20:24] <bigjools> ok
[20:24] <bigjools> I'll do it
[20:25] <bigjools> it doesn't make it clear what the expected changes are though
[20:25] <leonardr> gary, still the same problem: lp:~leonardr/lazr.restfulclient/test-2
[20:26] <lifeless> bigjools: thanks!
[20:27] <lifeless> bigjools: its changing from suite=`$LAUNCHPADROOT/scripts/ftpmaster-tools/lp-query-distro.py development`
[20:27] <lifeless> to
[20:28] <lifeless> SUITES=`$LAUNCHPADROOT/scripts/ftpmaster-tools/lp-query-distro.py supported`
[20:28] <lifeless> so the big thing AFAICT is that a) its going to take significantly longer and b) rewrite frozen distros
[20:29] <bigjools> hmmm
[20:29] <lifeless> and its doing this because NEW packages in lucid are not getting support durations exported
[20:30] <lifeless> I am assuming that the ubuntu 'development' series is 'supported' too
[20:30] <lifeless> otherwise it seems buggy ><
[20:30] <gary_poster> leonardr: zc.recipe.testrunner needs to be updated too, because it generates bin/test.  I will try it and then confirm if that helps.
[20:31] <bigjools> lifeless: so re-writing overrides for older series will make no difference
[20:31] <bigjools> because the next invocation of the publisher will ignore them
[20:31] <bigjools> we never, ever change stuff on released series, other than -updates etc.  I'm not sure if this is what he intended.
[20:32] <bigjools> lifeless: I want to wait to speak to him before saying this is ok, because it needs two publisher runs.  Germinate sets up data that the following publisher run uses.
[20:34] <lifeless> bigjools: does that mean we also need to change the publisher to not ignore changes to the overrides ?
[20:35]  * lifeless can see significant overheads arriving
[20:35] <lifeless> bigjools: should we roll this patch out then, if its going to stall ?
[20:36] <bigjools> lifeless: 1. no, no and thrice no.  2. the patch is not for the nodowntime set so it won't break anything if you mark it untestable on the provisio we look at it before the next rollout
[20:37] <lifeless> 1. I meant rollback, not deploy ;)
[20:37] <bigjools> and I meant you don't need to do that
[20:37] <bigjools> not right now anyway
[20:38] <lifeless> ok
[20:38] <lifeless> so, I propose to:
[20:38] <lifeless>  - mark it untestable
[20:38] <lifeless>  - file a new bug saying that we have this time bomb
[20:38] <bigjools> the code will never run anywhere except cocofigpineapplecumquat
[20:38] <lifeless>  - assign it to you, mail mvo, and cross every available limb
[20:38] <lifeless> how does that sound?
[20:38] <bigjools> great
[20:39] <lifeless> cool
[20:39] <bigjools> I'll co-ordinate with him to do tests
[20:39] <bigjools> when's our next rollout date?
[20:39] <Ursinha> Feb 9, I guess
[20:39] <gary_poster> leonardr: http://pastebin.ubuntu.com/558269/ then it works for me (bin/test passes)
[20:39] <bigjools> Ursinha!
[20:40] <Ursinha> :)
[20:40] <bigjools> did you like the cat video?
[20:40] <Ursinha> bigjools, I had a hard time laughing
[20:40] <lifeless> huh, no 2011 calendar
[20:40] <lifeless> I was sure edwin made one
[20:41] <lifeless> bigjools: while you are around, http://launchpad.net/bugs/707189
[20:41] <_mup_> Bug #707189: Architecture-independent direct copies can sometimes forget to copy some architectures <qa-needstesting> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/707189 >
[20:42] <bigjools> lifeless: actually looking at the merge again, I think his intent is only to set the timeframe data for new stuff in old releases
[20:42] <lifeless> bigjools: If I understand correctly I could qa that via the web UI ?
[20:42] <lifeless> bigjools: yes, thats his intent
[20:42] <bigjools> lifeless: yes, copy an arch-indep package w/rebuild, and make sure it creates builds for all three PPA archictectures (which means copying a hardy package)
[20:43] <thumper> flacoste: hey
[20:43] <bigjools> lifeless: so the patch is fine - but I'll test it with him anyway since I don't want to fuck anything up with the publisher
[20:43] <thumper> flacoste: I'm digging into more lazrjs widgets today
[20:44] <lifeless> bigjools: so NEW stuff will honour overrides?
[20:44] <bigjools> lifeless: yes
[20:44] <thumper> flacoste: the multiline text editor needs some work, which I'm going to do
[20:44] <lifeless> great, my knowledge expands :)
[20:44] <bigjools> lifeless: because it lives in -updates
[20:44] <thumper> flacoste: I want to get it to the same state as the picker widget, so you just render the widget and it all works
[20:44] <thumper> flacoste: which isn't the case right now
[20:44] <bigjools> lifeless: only the release pocket is frozen
[20:48] <flacoste> thumper: that sounds very good!
[20:48] <lifeless> bigjools: bug 707630 for your qa pleasure
[20:48] <_mup_> Bug #707630: qa needed for cron.germinate changes in rev 12250 <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/707630 >
[20:48] <bigjools> ok
[20:51] <lifeless> bigjools: so from hardy to hardy? or from hardy to lucid would work (https://launchpad.net/bugs/707189)
[20:51] <_mup_> Bug #707189: Architecture-independent direct copies can sometimes forget to copy some architectures <qa-needstesting> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/707189 >
[20:52] <bigjools> lifeless: you need a series that has lpia in it - hardy does
[20:52] <bigjools> (the target series)
[20:53] <bigjools> lifeless: well, anything up to karmic is ok
[20:54] <lifeless> so arch indep only generates i386 though?
[20:56] <cody-somerville> Does launchpad use mod_xsendfile by any chance?
[20:56] <lifeless> no
[20:58] <cody-somerville> for files served from the librarian, does the web server read and stream the file or the launchpad librarian web app do that?
[20:58] <lifeless> the librarian daemon serves on http
[20:58] <lifeless> the squid front end caches
[20:58] <lifeless> and the apache front end does ssl
[20:58] <lifeless> which web server of those three are you asking about ?
[20:59] <lifeless> oh, and the haproxy does load balancing
[21:00] <cody-somerville> lifeless, Were the issues with serving files from the librarian caused by timeouts in the librarian daemon?
[21:00] <lifeless> cody-somerville: what issues?
[21:00] <cody-somerville> lifeless, the timeouts
[21:00] <lifeless> cody-somerville: I don't know what you're talking about
[21:00] <lifeless> bug #?
[21:01] <cody-somerville> lifeless, I'll look it up, one second.
[21:02] <lifeless> bigjools: I think I'll wait for wgrant, my understanding here isn't sufficient for me to be confident
[21:02] <bigjools> lifeless: it's trivial to test
[21:02] <lifeless> bigjools: I'd expect a source copy of an arch-all package to only make an i386 build
[21:03] <lifeless> bigjools: I copied langpack-locales from my hardy ppa to https://qastaging.launchpad.net/~bzr-beta-ppa/+archive/obsolete/+packages
[21:03] <bigjools> lifeless: yes, but it needs publishing entries in all arches
[21:03] <lifeless> bigjools: that requires a buildd to build it first, right ? :)
[21:04] <bigjools> sorry I was confusing you earlier by saying builds, I should have said "builds published"
[21:04] <bigjools> it does
[21:04] <lifeless> confusion corrected.
[21:04] <bigjools> I can update dogfood
[21:04] <lifeless> and we don't have a buildd for qastaging yet
[21:04] <bigjools> then we can do it there
[21:04] <lifeless> bigjools: that would be great, I don't think the patch has propogated to staging yet
[21:05] <lifeless> abentley: your patch has had a good test run with buildbot, FYI
[21:10] <bigjools> lifeless: so I can easily QA his change but it would be nice to spread some knowledge, I can take you through it if you want
[21:12] <cody-somerville> lifeless, I can't find the particular bug at the moment but I know you helped fix what ever was wrong :P
[21:12] <cody-somerville> lifeless, anyhow, was just curious if you guys used it
[21:13] <abentley> lifeless, I saw that.  Also saw that the bug is looking not buildbot-specific.
[21:14] <lifeless> abentley: yeah
[21:14] <lifeless> abentley: which is both good and bad
[21:14] <lifeless> bigjools: I'd like that
[21:15] <bigjools> lifeless: ok just bringing up DF with newest code
[21:15] <lifeless> cody-somerville: are you thinking of the apport incident months ago?
[21:15] <bigjools> lifeless: do you know off hand if the revision made it to db-devel et?
[21:15] <bigjools> yet
[21:15] <cody-somerville> lifeless, no, thinking of the timeouts when accessing files from the private librarian
[21:15] <lifeless> bigjools: I haven't looked
[21:15] <lifeless> cody-somerville: that would be apport then
[21:16] <lifeless> cody-somerville: so the 'timeouts' are also known as 'firewall rules' :)
[21:16] <lifeless> cody-somerville: or if you go far enough back, we were serving private librarian content via the front end app servers
[21:16] <lifeless> cody-somerville: so what would happen is this:
[21:17] <lifeless>  - request for a 100MB (or whatever) file hits zope
[21:17] <lifeless>  - zope copies it from the librarian
[21:17] <lifeless>  - its not in the OS page cache so disk IO happens
[21:17] <lifeless>  - request times out
[21:17] <lifeless> once its in the OS page cache the copy to the zope server was fast enough that things would work, but that could take multiple requests
[21:18] <lifeless> what we do know is have the appserver issue a redirect when someone is authorised to access a private file
[21:18] <lifeless> s/know/now/
[21:20] <lifeless> cody-somerville: anyhow, no, we don't use sendfile
[21:20] <lifeless> no particular urge to do so either
[21:21] <cody-somerville> I just figure apache2 is probably pretty good at reading and streaming files. ;)
[21:21] <lifeless> cody-somerville: so is twisted
[21:22] <lifeless> cody-somerville: and twisted can do our token authentication checks directly rather than having a somewhat awkward external helper to write
[21:22] <lifeless> cody-somerville: as well as the mapping from url to disk (which is db dependant)
[21:22] <cody-somerville> lifeless, you can do that with xsendfile too
[21:23] <cody-somerville> lifeless, your python app can do authentication and what ever and then send the x-send-file header to have apache take over and handle the heavy lifting let your app get back to other things
[21:23] <lifeless> cody-somerville: what we have now works great; and given how average apache2 actually is at serving from disk, I'm really not inclined to fiddle.
[21:23] <cody-somerville> lifeless, no disagreement.
[21:30] <leonardr> abentley, do you want me to review https://code.edge.launchpad.net/~abentley/launchpad/translation-fixing4/+merge/47461 or did you deliberately give it to deryck and henninge?
[21:31] <abentley> leonardr, I want henninge to review it.
[21:31] <leonardr> ok, just checking
[21:31]  * leonardr has had a lonely tenure as ocr today
[21:32] <abentley> leonardr, I know the feeling.  But I want hennninge to review it, because I'm rewriting translations tests and I want him to make sure I'm not changing their meaning.
[21:33] <leonardr> got it
[21:37] <thumper> leonardr: how do I get the exported_as attribute out of a exported field from the Interface
[21:37] <thumper> leonardr: for example if I have ISomeInterface['fieldname']
[21:39] <leonardr> thumper: you'll probably need to root around in the annotations. why do you need this?
[21:39] <thumper> leonardr: I'm wanting to pass the interface field through to the lazrjs text editing widgets like we do for the popup
[21:39] <thumper> leonardr: so we don't have to explicitly specify the exported name, and accept empty values
[21:40] <thumper> leonardr: ideally I want to have it automatically generate the text to show too
[21:40] <thumper> leonardr: I'm refactoring the lazrjs text widgets
[21:40] <thumper> to make them more magic and awesomer
[21:41] <leonardr> thumper: one complication comes from the fact that a single field may have multiple exported_as attributes in different versions. of course, you'll want the 'devel' name...
[21:43] <leonardr> thumper: this should get you in the vicinity
[21:44] <thumper> leonardr: ok, thanks
[21:44] <leonardr> no, i wasn't done
[21:44] <leonardr> that wasj ust me thinking, here's the actual helpful part:
[21:44] <thumper> :)
[21:44] <lifeless> anyone ever seen '__storm_table__ missing' in a SQLBase child class ?
[21:44] <lifeless> has me a little flummoxed
[21:45] <lifeless> ah
[21:45] <lifeless> figured it out.
[21:45] <leonardr> thumper: sorry, my head is abuzz with ideas. let's nail down what we want
[21:45] <leonardr> you have ISomeInterface['fieldname'], which is exported_as('fieldname2')
[21:45] <lifeless> I was returning BugMessage.bug, had to return BugMessage.bugID
[21:45] <thumper> leonardr: yes,
[21:46] <thumper> leonardr: IProduct['programminglang'] in fact
[21:46] <leonardr> you are writing some python that takes as an argument the Field object ISomeInterface['fieldname']
[21:46] <leonardr> is that right?
[21:46] <thumper> yes
[21:47] <leonardr> ok. one way of doing this would be to find the IEntry adapter corresponding to IProduct
[21:47] <leonardr> this would be called something like IProductEntry_devel
[21:47] <leonardr> but i think there's a simpler way to do it
[21:48] <leonardr> give this a try and see what you get
[21:49] <leonardr> call .queryTaggedValue(LAZR_WEBSERVICE_EXPORTED) on IProduct['programminglang']
[21:49] <leonardr> L_W_E is a constant you can import from lazr.restful.declarations
[21:50] <leonardr> thumper -^
[21:50]  * thumper tries
[21:50] <leonardr> you can get IProductEntry_devel by calling EntryAdapterUtility.forSchemaInterface(IProduct, request)
[21:51] <leonardr> but then you have the opposite problem--how to see which field was originally called 'programminglang'
[21:51] <leonardr> however, i do see code that does that:
[21:51] <leonardr>                     tagged_values = field.getTaggedValue(
[21:51] <leonardr>                         'lazr.restful.exported')
[21:51] <leonardr>                     original_name = tagged_values['original_name']
[21:52] <thumper> <lazr.restful.utils.VersionedDict object at 0x3e5f810>
[21:52] <leonardr> ok, we can do this
[21:52] <leonardr> what's its items? it should have ['as'], and that should be the value you're looking for
[21:52] <thumper> I get 'programminglang' from the versioned dict
[21:53] <thumper> 'as' is a simple string value
[21:53] <thumper> which is 'programming_lang'
[21:53] <thumper> which seems right
[21:53] <thumper> but what about the problem with devel vs other versions?
[21:54] <leonardr> thumper: it's fine. we are always using the latest version, and the default state of a VersionedDict is for the latest version's values to be on top
[21:54] <thumper> on top?
[21:54] <leonardr> a VersionedDict is a stack of dicts
[21:54] <leonardr> with bleedthrough
[21:54] <thumper> ok
[21:55] <thumper> how can I see the stack?
[21:55] <thumper> just for my interest
[21:55]  * leonardr checks
[21:55] <leonardr> thumper: it's available as .stack
[21:56] <thumper> cook
[21:56] <thumper> cool
[21:57] <leonardr> thumper: we have a EntryAdapterUtility to hide this kind of detail (getTaggedValue) when it comes to the generated IEntry interfaces
[21:57] <leonardr> we should consider adding a similar utility to manage the tags on the source interfaces
[21:57] <thumper> hmm...
[21:57] <thumper> yep
[21:58] <thumper> I'll go with this for a first cut refactoring
[21:58] <leonardr> sure
[22:13] <leonardr> matsubara, do you need a review? i'm eod but i can do one if it's quick
[22:13] <matsubara> leonardr, yes, I'm writing the mp. just a sec.
[22:13] <lifeless> wgrant: hi?
[22:14] <matsubara> leonardr, https://code.launchpad.net/~matsubara/oops-tools/fix-graphs/+merge/47470
[22:17] <matsubara> so basically the script I added is a python script that replaces the bash script in devpad. It uses the new report objects to generate the reports rather than calling the analyse script. (which I'm going to deprecate once I get rid of all of the scripts/cronjobs using it)
[22:17] <leonardr> matsubara: what kind of dsl is that in the setup.py?
[22:18] <matsubara> leonardr, dsl?
[22:18] <leonardr> 'graph_report = oopstools.scripts.graph_report:main',
[22:18] <leonardr> that's not python
[22:18] <leonardr> esp. because it's in a string
[22:18] <leonardr> what is it? i'm just curious--it looks good judging by the context
[22:19] <matsubara> right, that's how setup.py sets up new scripts in the bin/ directory
[22:19] <leonardr> is it normal to have two underscores in name__in?
[22:19] <matsubara> graph_report is how the script will be called and oopstools.scripts.graph_report:main is the entry point
[22:20] <matsubara> yep, that's django's orm syntax
[22:20] <matsubara> leonardr, setup.py will turn that into this script https://pastebin.canonical.com/42317/ in bin/
[22:21] <matsubara> btw, what do you mean by dsl?
[22:22] <leonardr> domain-specific language
[22:22] <leonardr> like the makefile language
[22:22] <matsubara> ah right. makes sense now :-)
[22:23] <leonardr> r=me
[23:46] <wgrant> lifeless: Hi.
[23:46] <wgrant> I'm not here today.
[23:46] <wgrant> But what's up?
[23:49] <lifeless> ah
[23:49] <lifeless> so, I thought you might have triggered the kde build on rubudinium
[23:50] <wgrant> Which?
[23:51] <lifeless> its gone now
[23:51] <lifeless> shrug
[23:51] <lifeless> enjoy your awol :)
[23:53] <bigjools> I am offski, see y'all tomorrow
[23:54] <wgrant> Night bigjools.


[08:35] <lordievader> Good morning.
[12:55] <BluesKaj_> Hiyas all
[13:21] <elfy> hi BluesKaj_
[13:22] <BluesKaj_> hey elfy, what's happening today ?
[13:22] <elfy> I am completely undecided :p
[13:23] <elfy> mostly a lot of looking out of the window and mmmm :)
[13:23] <elfy> actually I'm patiently waiting for something to break this cycle
[13:24] <elfy> might have to look at ubuntu or kubuntu or something :)
[13:27] <BluesKaj_> elfy, running a lighter weight 'buntu due to computer age and HW or ?
[13:28] <elfy> what I've got here would run either ubuntu or kubuntu - so just choice :)
[13:32] <BluesKaj_> right , then there's the new plasma 5 for kde which is ok but not what would call a step forward looks wise , IMO of course
[13:32] <elfy> yea - had a quick look last cycle towards the end
[13:33] <BluesKaj_> some ppl love it , I'm kind of neutral
[13:33] <elfy> :)
[13:33] <elfy> I'm not that partial to kubuntu tbh - I tried it a couple of times - probably need to try it longer than a day :)
[13:34] <BluesKaj_> I installed it on the laptop, guess I'm stuck with it since I promised I'd test it
[13:35] <elfy> ha ha ha
[13:35] <BluesKaj_> plasma5 that is
[13:35] <BluesKaj_> love Kubuntu/KDE ...unity and gnome etc aren't my cuppa tea
[13:37] <lordievader> BluesKaj_: You make it sound like it is a burden...
[13:37] <BluesKaj_> apps are snappier since increasing the RAM to 6G
[13:38] <BluesKaj_> plasma 5 is to some degree ,since it has so many limitations
[13:38] <BluesKaj_> not very configurable atm
[13:39] <BluesKaj_> that's why I'm using my old desktop more these days :)
[13:39] <lordievader> It does the config I want ;) But it is not yet up to the height of Plasma4.
[13:41] <BluesKaj_> I should qualify configurable, I mean in the "theme and look" sense
[13:45] <BluesKaj_> suppose I could upgrade this pc to 15.04, but I like having a stable OS/machine available
[23:23] <ChogyDan> hi all, I have an old computer where both the 14.04 and 14.10 kernels don't work, but 3.17.4 does.  In your opinion, should I upgrade now?  Will vivid be usable?  Or is it still in the super unstable phase...   I'm curious with the thought that if I run the testing release, I could report bugs before release rather than after
[23:25] <maxb> In your situation I'd just stick on 14.10 with a custom kernel
[23:34] <ChogyDan> kk, thanks


[17:06] <dmj_s76> sforshee: I've found another bug in linux-firmware: bluetooth doesn't work on at least some systems with the intel 8265 on 16.04.2.
[17:07] <dmj_s76> Adding the ibt-12-16.sfi and ibt-12-16.ddc fixes it.
[17:09] <dmj_s76> dmesg reports that the kernel failed to load the ibt-12-16 firmware, and bluetooth doesn't work because those files aren't present on xenial.
[17:12] <sforshee> dmj_s76: okay, we'll need a bug to sru that
[17:13] <sforshee> dmj_s76: also did you see that linux-firmware for zesty needs verification for the fix for your 8000C issue?
[17:16] <dmj_s76> This one can be hard to reproduce because installing a later version of Ubuntu will permanently fix it, even when installing 16.04.2 again
[17:16] <dmj_s76> sforshee: I'll get on the zesty verification
[19:21] <dmj_s76> sforshee: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1686815
[19:33] <sforshee> dmj_s76: thanks