[00:01] <pcjc2> http://pastebin.com/22DZ5hNS
[00:02] <lifeless> pcjc2: so that uses __eq__
[00:02] <lifeless> it will match u'' == ''
[00:02] <lifeless> the string is different
[00:02] <lifeless> to whit:
[00:02] <lifeless> >>> a="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'bob'))"
[00:02] <lifeless> >>> b="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'bob'))"
[00:02] <lifeless> >>> a==b
[00:03] <lifeless> False
[00:03] <lifeless> note the 'bug.id' vs 'Bug.id'
[00:03]  * pcjc2 explodes
[00:03] <pcjc2> I pasted both strings in my texteditor and did a search to compare
[00:03] <pcjc2> and it highlighted both
[00:03]  * pcjc2 goes back to using a REAL editor like gvim ... screw gedit
[00:04] <pcjc2> sorry for the noise
[00:04] <lifeless> no probs!
[00:06]  * pcjc2 feels stupid
[00:06] <lifeless> its not the most helpful assertion
[00:07] <pcjc2> Should I be matching WHERE BugTag.bug = Bug.id
[00:07] <pcjc2> OR WHERE BugTag.bug = BugTask.bug  ??
[00:07] <pcjc2> Either should work, but the old query was BugTask.bug IN
[00:13] <lifeless> depends what we want to correlate on
[00:13] <lifeless> Bug.id is a smaller set than BugTask.bug
[00:14] <lifeless> 1 bug to many bugtasks
[00:18] <jml> looks like we'll need a losa to fix the build. we'll have to wait until the release is done.
[00:20] <lifeless> fooding downstairs
[00:59] <jml> wgrant: btw, I've landed a rollback for r12181. I guess another thing to do would have been to delete the date_finished assertions in test_uploadprocessor, but I was a bit rushed at the time and not fully certain.
[01:01] <wgrant> jml: Were there test failures?
[01:02] <jml> wgrant: yeah. sorry to bring bad news.
[01:02] <mwhudson> jml, crusher of hope
[01:02] <mwhudson> thwarter of desire
[01:02] <wgrant> jml: *sigh*
[01:03] <wgrant> Self-reviewed *and* untested.
[01:03] <jml> yeah. it's a pain, and worse for being easily avoidable.
[01:04] <jml> I want to upgrade Twisted, so I need a working devel in order to do a sane ec2 test run.
[01:04] <jml> anyway, I guess that can be the work of tomorrow
[01:09] <jml> I'm signing off
[01:09] <wgrant> Night.
[01:09] <jml> g'night all
[01:09] <wgrant> Thanks for reverting that.
[01:13] <jml> np.
[01:27] <LPCIBot> Project devel build (352): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/352/
[01:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=664828] Fixed timeout when deactivating a
[01:27] <LPCIBot> member of a team.
[01:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Upgrade to testtools 0.9.8 final
[01:40] <pcjc2> lifeless: Patch is available for the tags issue, but haven't done any testing on it locally (other than proving test-suite now runs for the handful of test you identified)
[01:40] <pcjc2> https://code.launchpad.net/~pcjc2/launchpad/fix-tag-search-bug-501945/+merge/46075
[01:52] <pcjc2> lifeless: When PQM runs the test-suite,... does it use that opportunity to benchmark Launchpad?
[01:52] <pcjc2> It occurred to me that one could take a snapshot of a fairly large testing database, grab a load of "typical" queries from a day in the life of Launchpad.. and make some kind of performance metric for code-changes
[01:53] <pcjc2> Would probably have to be read only queries unless there was a way to roll-back a big DB snapshot after testing
[01:53] <lifeless> no
[01:54] <lifeless> in fact for lp we don't run the test suite in pqm; we do that in a CI tool (currently buildbot) post-landing
[01:54] <lifeless> the live db (which you need for perf evaluation) is 250GB
[01:54] <pcjc2> thought it would be a problem ;)
[01:54] <pcjc2> My HDD is only 500GB
[01:54] <lifeless> yeah
[01:54] <pcjc2> I guess perf could be made from a set of read-only queries on the live DB
[01:54] <lifeless> it won't fit on my laptop, thats for sure
[01:55] <pcjc2> but data changes of course - so hard to remain consistent.
[01:55] <lifeless> yeah
[01:55] <lifeless> we have comprehensive performance data anyhow
[01:55] <pcjc2> Perhaps that doesn't matter though... bad perf is bad perf, caused by increased DB size, or whatever
[01:55] <pcjc2> Ok - that is good
[01:55] <lifeless> we trace all requests and generate page render times, broken down by page, url, what have you
[01:55] <pcjc2> Was just wondering if changes like the bug tags one would get noticed
[01:55] <lifeless> well, that bug will be closed
[01:56] <lifeless> we'll have some less backend data
[01:56] <lifeless> howevewr
[01:56] <lifeless> I suspect its < 10 pages a day hitting that bug (perhaps much less)
[01:56] <lifeless> and we have 4000000 page renders a day
[01:56] <pcjc2> https://devpad.canonical.com/openid/+login
[01:57] <pcjc2> Authorization is required to access https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-timeout-candidates.html
[01:57] <lifeless> yup, internal only atm
[01:57] <pcjc2> shame
[01:57] <lifeless> we're going to get a sanitised extract
[01:57] <lifeless> but we have confidential project names of our customers exposed in the raw report
[02:04] <pcjc2> Btw.. were the concerns about git (as regards possible integration with LP) documented somewhere?
[02:09] <lifeless> I suspect not
[02:09] <lifeless> I mean
[02:09] <lifeless> we do mirror git into LP
[02:10] <lifeless> and I think it would be fairly sane to publish bzr branches into git automatically
[02:10] <lifeless> I'm not at all sure about speaking git for writes
[02:10] <pcjc2> (that has confused some people in our project already)
[02:10] <lifeless> on purely technical limits
[02:10] <lifeless> let alone the room for confusion
[02:11] <pcjc2> we already have git repositories in various places, so something distributed would be nice to support
[02:11] <pcjc2> It doesn't really matter to us that launchpad mirrors through bzr in order to get at things like translations etc..
[02:11] <pcjc2> But it would be nice if we could hide that fact as an "admin only" detail, rather than have users think we use bzr
[02:12] <pcjc2> I should file a feature request for adding more comments on the "code" page of a project. We'd love to add some notes to https://code.launchpad.net/geda
[02:13] <lifeless> please do
[02:13] <poolie> that would be nice
[02:13] <pcjc2> I'm going to bed shortly - I'll try and find time tomorrow to have a think about a) how our lives could be made less confusing w.r.t code on LP, and b) What wishlist we might have for git integration
[02:14] <pcjc2> I do love the ease with which you can push personal branches to launchpad with bzr
[02:14] <pcjc2> The code review workflow is lovely too. I wish we had the same for git
[02:15] <lifeless> what keeps you on git ?
[02:15] <pcjc2> it was not _that_ long ago that we moved to it, and we find it serves almost all our needs
[02:15] <lifeless> what I mean is
[02:15] <lifeless> if you like everything else about lp
[02:15] <lifeless> and you want to avoid confusing your users
[02:16] <pcjc2> The one area it could be better is that some users used to CVS / SVN just don't know how to "cvs up" with git
[02:16] <lifeless> one option is to migrate to bzr
[02:16] <pcjc2> that is of course an option ;)
[02:16] <lifeless> (where you can bzr up :P)
[02:16] <pcjc2> indeed
[02:16] <lifeless> I'm totally cool with you staying on git, of course
[02:16] <lifeless> just curious about how you perceive it all
[02:17] <pcjc2> I'd bet that bzr can do almost all of what we want, but it is one more thing to learn. I expect to learn it in due course though.
[02:17] <pcjc2> I find git more polished and pleasing to use than bzr though
[02:17] <pcjc2> faster - more obvious what is going on under the hood. Nice paged output with colours by default ;) (No doubt all options I've yet to find in bzr)
[02:18] <pcjc2> With bzr, I still get the uneasy feeling that I don't know where my data is
[02:19] <pcjc2> With git, I know where the data is (when unpacked), where the reflogs are, where to find the internals of stgit, how to manually fixup most problems one might encounter
[02:19] <pcjc2> (Thank-you very much ext4 + OS crash for the 0-length files in the repository's store)
[02:20] <lifeless> heh
[02:20] <lifeless> yeah, ext4 is not happy making
[02:20] <pcjc2> using it now, but its habit of truncating files is not nice
[02:21] <pcjc2> I recall there was a technical reason for the decision, but it is a shame they had to make it
[02:21] <lifeless> it doesn't actually truncate
[02:21] <lifeless> rather it saves the directory before saving the file inode
[02:21] <lifeless> pcjc2: there are technical *arguments*... calling it a reason is a stretch in the opinion of quite a few people :)
[02:22] <pcjc2> irritating behaviour whatever the cause. I recalled it was something to do with ensuring consistency
[02:23] <lifeless> its all about performance
[02:23] <lifeless> delayed allocatio
[02:23] <lifeless> n
[02:23] <pcjc2> http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
[02:23] <lifeless> and yes
[02:24] <lifeless> one of the problems is the black and white way the problem is framed
[02:24] <lifeless> most apps *don't* care about 'on disk', but they do care about 'ordered in this way'
[02:24] <lifeless> its better for battery life to care about the second point
[02:24] <pcjc2> ignore the negative comments abut Ubuntu in that blog post
[02:26] <poolie> bzr should probably just fsync files (or whatever exactly is needed) on ext4 bydefault
[02:27] <pcjc2> It was a git repository I got corrupted, but I imagine both might benefit from fsync around critical changes
[03:06] <pcjc2> goodnight
[03:26] <wgrant> Storm is too lazy :(
[03:30] <thumper> wgrant: in what way?
[03:31] <wgrant> thumper: Applying @cachedproperty to a method that returns a resultset does nothing.
[03:33] <thumper> heh
[03:58]  * thumper EODs
[05:40]  * huwshimi is heading off
[05:52] <wgrant> I'm guessing there are no reviewers around?
[05:52] <wgrant> thumper: ?
[06:13] <LPCIBot> Project devel build (353): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/353/
[06:13] <LPCIBot> Launchpad Patch Queue Manager: [r=benji][ui=none][bug=701613] update keyring to 0.5.1
[06:15] <LPCIBot> Project devel build (354): STILL FAILING in 2 min 33 sec: https://hudson.wedontsleep.org/job/devel/354/
[06:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=702170][no-qa] Fix yui deps to list the
[06:15] <LPCIBot> current yui files.
[06:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][no-qa] Adds more logging to the request_daily_build
[06:15] <LPCIBot> script.
[06:15] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=sinzui][bug=700864] Show a warning to the user if the
[06:15] <LPCIBot> daily build won't happen due to PPA upload permission problems.
[06:15] <LPCIBot> * Launchpad Patch Queue Manager: [rs=jml][ui=none][rollback=12181] Rollback r12181,
[06:15] <LPCIBot> which introduced test failures.
[08:39] <adeuring> good morning
[08:43] <wgrant> jtv: Morning.
[08:43] <jtv> wgrant: morning… or… late afternoon?
[08:43] <wgrant> jtv: One of those.
[08:43] <wgrant> Or others.
[08:44] <wgrant> jtv: Bug 702228
[08:44] <wgrant> rosetta-export-queue is broken.
[08:44] <jtv> Arrr
[08:44] <wgrant> _mup_: bug 1234
[08:44] <wgrant> :(
[08:44] <wgrant> bad _mup_
[08:45] <jtv> I guess I didn't make the display of current backlog on the export page prominent enough.
[08:45] <wgrant> jtv: It is hanging on one export.
[08:46] <jtv> Firefox, too.
[08:46] <wgrant> natty firefox, IIRC.
[08:46] <wgrant> Yeah.
[08:46] <jtv> Do we know though that this isn't a stale lock file after the rollout?
[08:47] <wgrant> jtv: It was processing firefox before the rollout.
[08:47] <wgrant> And is processing firefox again after the rollout.
[08:48] <jtv> Looks to me as if the bug report may be completely unrelated to what we're actually seeing.
[08:49] <jtv> The backlog is 16 hours.
[08:50] <wgrant> 2011-01-13 07:16:16 DEBUG   Exporting objects for Данило Шеган, related to template firefox in Ubuntu Natty package "firefox"
[08:50] <wgrant> It did it again an hour ago.
[08:50] <wgrant> This is an ongoing problem.
[08:50] <jtv> But one unrelated to the complaint of "it don't work for 2 day," which is more likely to be an email problem or something.
[08:51] <wgrant> Ah, true.
[08:53] <jtv> What has me curious is why the backlog is listed as about 16 hours, when rollout was scheduled about 10 hours ago.
[08:53] <jtv> Surely we didn't stop the script 6 hours prior to rollout?
[08:54] <jtv> It's possible that this is unrelated to rollout, but given how close to rollout it happened, one would suspect a connection.
[08:56] <wgrant> jtv: Indeed.
[08:58] <wgrant> jtv: Except that rollout prep didn't start for another 4 hours, AFAICT.
[09:00] <jtv> Right.  It actually seems to have happened just before rollout.  Not 2 days before, not immediately after.
[09:01] <jtv> Which also means that we didn't cause this in db-devel.
[09:39] <adeuring> stub: could you have a look at this schema patch: http://paste.ubuntu.com/553532/ ?
[09:40] <adeuring> stub: this breaks "make schema" when the test DBs are populated
[09:49] <stub> adeuring: How does it break? It might be you need to use $$ quoting instead of single quotes for the function body, and the function should go in trusted.sql.
[09:49] <adeuring> stub: IntegrityError: new row for relation "message" violates check constraint "message__must_have_chunks"
[09:50] <stub> I wouldn't add this constraint anyway, as it is only checked at insert time
[09:50] <adeuring> stub: my main point: do you think the patch itself is reasonable? If not there is not need to dive into the samledata iusse ;)
[09:50] <stub> Sounds like some of our messages in sampledata don't have chunks.
[09:50] <adeuring> stub: exactly
[09:51] <adeuring> and this causes several headaches
[09:51] <stub> Don't add the constraint would be my preference.
[09:51] <adeuring> we don't know why this happens, so I thought that postgres could guard it
[09:51] <stub> Constraints are good to provide guarantees, but in this case it cannot provide a guarantee
[09:52] <adeuring> stub: well, the contraint will cause exepctions
[09:52] <stub> If we want to guarantee this, a trigger is a better option
[09:52] <adeuring> if we'll get these empty messages again
[09:52] <adeuring> stub: how would you use a trigger here?
[09:53] <stub> We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message.
[09:54] <adeuring> stub: ok, makes sense.
[10:13] <stub> (16:53:48) stub: We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message.
[10:13] <stub> (16:54:51) stub: I guess it is pretty much the same as the CHECK constraint
[10:13] <stub> (16:56:19) stub: 'SELECT TRUE FROM MessageChunk WHERE message=$1 LIMIT 1' reads nicer to me and I think more likely to get a nice plan.
[10:13] <stub> (16:58:38) stub: adeuring: Have you looked at the contents of Message.raw for these empty messages?
[10:13] <stub> 17:00
[10:13] <stub> (17:02:21) stub: adeuring: IIRC it is actually valid to have a Message with no MessageChunks - eg. an email that is just headers and no body. I don't see any use for these though even if they are technically valid so don't mind guarding against them if we need to.
[10:13] <stub> (17:09:05) stub: adeuring: https://launchpadlibrarian.net/42717149/UYhI9QHAcptcDE1jt64zhivlP6.msg is the last one in the system, which looks like an email imported from debbugs
[10:13] <stub> (17:09:42) stub: adeuring: And it is an email with no body - just headers
[10:15] <adeuring> stub: ah, that's interesting. Seems that i need to check again what to do with empty messages
[10:19] <adeuring> stub: strictly speaking, tis mail is _not_ empty: There are four empty lines after the headers, so a body content of '\n\n\n'
[10:19] <adeuring> so that mail _should_ have a MessageChunk record
[10:19] <stub> adeuring: So check out or email_to_message helper - we are likely deliberately stripping leading and trailing whitespace.
[10:20] <adeuring> stub: right
[11:21] <jtv> stub: it's a bit awkward to slap a SlaveOnlyDatabasePolicy around just the right parts of the export procedure… would a SlaveDatabasePolicy around the whole thing be as valid?  AFAIK we never ask for the master unless we really need the master.
[11:23] <jtv> If that leaves cursor() on the master, I could just eliminate the call.
[11:59] <LPCIBot> Project devel build (355): STILL FAILING in 4 hr 47 min: https://hudson.wedontsleep.org/job/devel/355/
[12:03] <deryck> Morning, all.
[12:29] <gmb> deryck: I think it'd be a good idea to make you an admin on ~malone-alpha so that you can approve new members. Any objections?
[12:33] <gmb> deryck: Also, do you have the slightest clue what's going on here: https://bugs.launchpad.net/launchpad/+bug/702022/+attachment/1792482/+files/out-2.ogv
[12:33] <_mup_> Bug #702022: Once a project is modified you can no longer modify the status <Launchpad itself:Incomplete> < https://launchpad.net/bugs/702022 >
[12:38] <bigjools> can someone remind me where our QA tagging guide lives please?
[12:40] <bigjools> ah nm
[12:41] <deryck> gmb: sure, make me an admin.  looking at the other now.
[12:45] <gmb> Ta]
[12:46] <stub> jtv: Sounds fine
[12:47] <deryck> gmb: yeah, I've seen that before, but don't recall exactly the work around.  it's something to do with renaming projects and permissions after that.
[12:49] <gmb> deryck: Damn. Maybe sinzui, oracle of Registry, will know more.
[12:56] <deryck> gmb: it's something to do with because the "-old" team is inactive.
[12:56] <gmb> Ah.
[12:57] <gmb> deryck: So, if they reactivate that the problem might go away?
[12:57] <deryck> gmb: indeed, it might
[12:57] <gmb> I'll update the bug.
[13:02] <wgrant> deryck, gmb: The top task is a deactivated project.
[13:02] <wgrant> Nothing to do with a team.
[13:02] <wgrant> I thought we hid those or something.
[13:03] <gmb> wgrant: Yeah, I s/team/project/'d before updating the bug.
[13:03] <wgrant> Ah, great.
[13:03] <gmb> deryck, wgrant: I reactivated the -old project too, to speed things along. Hurrah for limited admin permissions.
[13:03] <wgrant> Heh.
[13:06] <gmb> allenap: ISTR you looked into why archived debian bugs weren't synced correctly... Did you ever get anywhere with that?
[13:07] <gmb> I ask because of https://bugs.launchpad.net/launchpad/+bug/702332.
[13:07] <_mup_> Bug #702332: debbugs #605391 not able to correctly update information <Launchpad itself:New> < https://launchpad.net/bugs/702332 >
[13:32] <allenap> gmb: I started investigating with mthaddon... it might have been a problem with the archive not syncing properly.
[13:34] <gmb> allenap: Yeah; I came to the conclusion that because old archived stuff only sticks around for so long, we might not have a copy of it.
[13:35] <allenap> gmb: I think that archived debbugs get moved into a separate database. Do you remember the bug that triggered http://twitter.com/grahambinns/status/18060932747886592?
[13:35] <allenap> We should/are syncing both, but perhaps there is a problem.
[13:37] <gmb> Hah, no.
[13:38] <gmb> allenap: Yeah, I thought we were syncing both, and I seem to have got the idea that stuff gets deleted from the archive, too, which is clearly nonsense.
[13:38] <gmb> (Having just re-read the same page that gave me that idea I can now see that I was just getting fuddled)
[14:50] <leonardr> sinzui, thanks a lot for that sample. i'm sooo close to having something working
[14:51] <leonardr> the only problem now is that the top-level collections are showing up twice: once as collections and once as entries
[14:51] <leonardr> they're not being filtered out properly
[14:52] <leonardr> my diff: http://pastebin.ubuntu.com/553622/
[14:54] <leonardr> i think i probably just converted the last bit incorrectly
[14:55] <sinzui> leonardr: are they twice in the toc or twice in the content
[14:56] <leonardr> sinzui: both. that makes me think i didn't look carefully at the last two "if test"s
[14:56] <leonardr> give me a minute
[14:58] <leonardr> sinzui: i think this is the problem. $master_top_level_collections isn't a list of ids, it's a list of tags
[14:58] <leonardr> so $master_top_level_collections[contains(., $id)] always fails
[14:58] <leonardr> does that make any sense?
[14:59] <leonardr> i took out this code because it didn't seem to do anything:
[14:59] <leonardr>             <xsl:variable name="top_level_collections"
[14:59] <leonardr>                 select="$master-top-level-objects" />
[15:01] <sinzui> leonardr: id does make sense. We can either revise the master code to work with the master set to get ids from the tags, or we define a id version of the variable
[15:02] <leonardr> sinzui: let's define another variable since it's used twice
[15:02] <leonardr> what does it look like?
[15:02] <jml> mrevell: hi
[15:02] <mrevell> jml, Hi
[15:02] <jml> mrevell: am stuck in a plenary atm
[15:05] <jml> mrevell: do you want to have a call today?
[15:06] <mrevell> jml, I'll be seeing you all day every day next week, so I'm happy to skip it. :)
[15:06] <jml> mrevell: ok, cool. :)
[15:07] <jml> wuuuuu Dallas!
[15:07] <mrevell> hehe, you've been there so long now I bet you're picking up the accent.
[15:07] <jml> not quite
[15:07] <jml> I do have pick-up truck envy though
[15:08] <jml> I want a pick-up truck so big that it's not legal to drive it within signatories of the Geneva convention
[15:08] <mrevell> haha
[15:09] <sinzui> leonardr: maybe this?
[15:09] <sinzui> http://pastebin.ubuntu.com/553629/
[15:12] <lifeless> so, how do I upgrade my ui ?
[15:12] <lifeless> I pulled in dists
[15:12] <lifeless> ran bin/buildout
[15:15]  * jml tries upgrading Twisted
[15:16] <StevenK> jml: Didn't we just do that?
[15:16] <jml> StevenK: we upgraded for 10.1, and then we applied a recent patch from trunk to fix a particular bug
[15:16] <StevenK> jml: Or was that just discussing 10.2, but not doing it
[15:16] <jml> StevenK: but 10.2 was released toward the end of last year, so it's time for an upgrade
[15:17] <lifeless> wgrant: still awake?
[15:17] <jml> StevenK: I tried upgrading to 10.2 yesterday, but got blocked on test failures introduced into the build by other branches.
[15:17] <StevenK> lifeless: It's 0217, so I seriously doubt it
[15:17] <lifeless> StevenK: there is always hope
[15:17] <lifeless> so, how do I upgrade my yui ?
[15:28] <bigjools> lifeless: would you have any idea why Storm would throw an IndexError when I call is_empty on a ResultSet?
[15:31] <bigjools> hmmm actually it's the stuff in ftests/pgsql.py
[15:37] <lifeless> bigjools: not offhand
[15:38] <bigjools> lifeless: http://pastebin.ubuntu.com/553640/
[15:38] <bigjools> I think I'll be filing a bug
[15:42] <leonardr> sinzui: i don't understand this error from the code you just sent me
[15:42] <leonardr> XPath error : Invalid type
[15:42] <leonardr> xmlXPathCompiledEval: 1 objects left on the stack.
[15:42] <leonardr> clearly there's something wrong with the substring-after call, but i don't see it
[15:43] <sinzui> I do not understand it either. I will re-read what I wrote
[15:45] <leonardr> sinzui: if it helps, i get the same error replacing the xpath expression with a random string
[15:45] <leonardr> select="substring-after('foo', '#')"
[15:49] <sinzui> leonardr: okay. I reproduced the error.
[15:52] <sinzui> leonardr: looks like the problem is not in the new variable bug in how we use it.
[15:52] <leonardr> ok
[15:53] <leonardr> not($master_top_level_collection_ids[contains(., $id)]) is wrong?
[16:01] <flacoste> allenap, benji, Edwin-afk: can you QA your bugs, I'd like to make a nodowntime release later today
[16:01] <allenap> Sure.
[16:01] <benji> flacoste: will do
[16:01] <flacoste> thx
[16:04] <EdwinGrubbs> working on it
[16:06] <sinzui> leonardr: I suspect we are getting a null string. Maybe we have an item in the xml where there is not string after #
[16:07] <leonardr> sinzui: there is a param with an empty wadl:link
[16:07] <leonardr> resource_type_link in the top-level
[16:07] <sinzui> okay I will look into that
[16:15] <bigjools> benji: keyring problems all seem sorted for me, thanks!
[16:15] <benji> yay
[16:16] <leonardr> sinzui: i'm going to move this stylesheet to launchpad while i'm at it. do you have an opinion where in the tree it should go?
[16:20] <sinzui> leonardr: I am not sure. I would think lib/lp/services/api if we intend to migrate api generation code to a single location
[16:25] <LPCIBot> Project devel build (356): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/devel/356/
[16:25] <LPCIBot> Launchpad Patch Queue Manager: [r=benji,
[16:25] <LPCIBot> edwin-grubbs][ui=none][bug=620868] Allow the viewing and editing of
[16:25] <LPCIBot> recipes with invalid recipe text.
[16:25] <sinzui> leonardr: I was mistaken that I could use substring-after to create create a node set. We are not getting the correct type back. I will make an alternate suggestions
[16:25] <lifeless> gmb: hi
[16:26] <lifeless> gmb: why is bug 380362 wontfix? - found it chasing a newly reporting 'bug not found' error in debbugs
[16:26] <_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. <lp-bugs> <Launchpad itself:Won't Fix by gmb> < https://launchpad.net/bugs/380362 >
[16:29] <LPCIBot> Project db-devel build (264): FAILURE in 4 hr 46 min: https://hudson.wedontsleep.org/job/db-devel/264/
[16:30] <gmb> lifeless: Because of some confusion a while back. allenap and I think there might be a problem syncing archived bug reports. I'll re-open the bug now.
[16:31] <lifeless> gmb: bug 702332
[16:31] <_mup_> Bug #702332: debbugs bug watch not updating an archived debbug (#605391) <bugwatch> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702332 >
[16:31] <lifeless> gmb: may be a dupe
[16:31] <james_w> hi lifeless, where are you hanging out today?
[16:31] <lifeless> bzr room atm
[16:32] <gmb> lifeless: It is a dupe. allenap and I were discussing it just today, actually, but I hadn't got round to finding this bug and duping the new one. Will do it now, thanks.
[16:59] <sinzui> leonardr: I think this solves the issue: http://pastebin.ubuntu.com/553663/
[17:01]  * leonardr shall check
[17:12] <leonardr> sinzui: looking good
[17:12] <sinzui> fab
[17:13] <sinzui> leonardr: jcsackett is reviewing today and he knows xslt. Is there a chance you can get your branch into review?
[17:13] <jcsackett> jcsackett *sort of* knows xslt. :-P
[17:13] <leonardr> sinzui: yes, i just need a minute to do a diff of the stylesheet. i'm moving it into launchpad so the whole thing willl show up in the diff
[17:28] <jml> sinzui: is utilities/migrater still needed in trunk?
[17:30] <jcsackett> jml: i think that will still be useful for as long as there are things to move from /canonical to /lp, yes?
[17:31] <jml> jcsackett: I guess. I'm just mildly inconvenienced when file-ownership.txt shows up in my greps.
[17:31] <jml> so it's no big deal
[17:31] <jcsackett> jml: if you're grepping across the launchpad tree, you might look at utilities/migrater/find.py
[17:32] <jml> jcsackett: you're going to have to work harder than that to get me to abandon bzr grep.
[17:32] <sinzui> jml: I regenerate my own each time. file-ownership is vestigial
[17:32] <jcsackett> jml: fair. wasn't trying to get you to abandon. i just find it a useful tool. :-)
[17:38] <lifeless> flacoste: hi
[17:38] <lifeless> flacoste: there are something like 10/15 rt's in the lp/bzr queue with pri 0 which AIUI means 'unset' - I'm wondering if you could drive that to 0? [on the same basis we drive NEW to zero]
[17:49] <jml> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
[17:49] <jml> just got that on 'make schema'
[17:49] <jml> anyone know what's up with that?
[17:50] <mwhudson> jml: lifeless filed a bug about that
[17:50]  * jml looks
[17:52] <jml> ahh. rm -rf lazr-js/build
[18:08] <jml> can someone please run "./bin/test -cvvt distribution-mirror.txt" for me?
[18:08] <jml> I wonder if this is a natty thing.
[18:11] <lifeless> jml: doing a make schema
[18:11] <lifeless> then I'll try for thee
[18:11] <jml> lifeless: thanks
[18:13] <flacoste> lifeless: i can do that yes
[18:14] <jml> also
[18:14] <jml> my current working hypothesis is that Python is broken in natty
[18:15]  * jml gets on to that
[18:17] <lifeless> 2.6 or 2.7 :p
[18:20] <jml> 2.7
[18:20] <jml> but I think it's actually bzr being broken in Python 2.7, which is more plausible
[18:24] <lifeless> the test failed for me
[18:25] <lifeless> /home/robertc/launchpad/lp-branches/working/lib/canonical/librarian/testing/server.py:120: DeprecationWarning: Attempt to start Tachandler with an existing instance (21693) running in /var/tmp/fatsam.test/librarian.pid.
[18:25] <lifeless>     +     url = librarian.remoteAddFile(
[18:25] <lifeless>     + AttributeError: 'thread._local' object has no attribute 'interaction'
[18:25] <lifeless>     + ERROR   Error while sending mail from bounces@canonical.com to david.allouche@canonical.com.
[18:25] <lifeless>     + Traceback (most recent call last):
[18:25] <lifeless>     +   File "/home/robertc/launchpad/lp-sourcedeps/eggs/zope.sendmail-3.7.1-py2.6.egg/zope/sendmail/queue.py", line 261, in run
[18:25] <lifeless>     +     raise error, msg
[18:25] <lifeless>     + error: [Errno 111] Connection refused
[18:30] <jml> hmm
[18:30] <jml> I get completely different failures
[18:30] <jml> but!
[18:30] <jml> the stack traces show that it's using python 2.7
[18:31] <jml> which means that buildout is somehow using system standard python rather than a hard-coded python 2.6
[18:31] <jml> gary-lunch: does that sound plausible? ^
[18:33]  * gary_poster has a call noe, jml...um
[18:33] <jml> gary_poster: don't worry. I'll keep poking around.
[18:33] <gary_poster> ok thanks, will ping
[18:36] <gary_poster> jml, yes, that's what our Makefile does.  It was because of Hardy/Lucid transition.  Can specify 2.6 now
[18:37] <jml> gary_poster: just set PYTHON to python2.6 in the Makefile?
[18:37] <gary_poster> jml, prob
[18:37] <jml> ok
[18:37] <jml> will give it a try
[18:37] <jml> gary_poster: thanks.
[18:47] <jml> yeah. that does it.
[19:07] <pcjc2> Lifeless, did you get a chance to review my patch? Would like to see it on staging so I can QA the changes
[19:11] <flacoste> thumper: if you could QA the two bugs you landed, i'd like to do a nodowntime release later today
[19:33] <lifeless> pcjc2: hi
[19:33] <lifeless> pcjc2: been flat out; best way to get it reviewed is to pop into #launchpad-reviews and ask for a reviewer
[19:33] <lifeless> it looked ok to me to the extent I had looked at it
[19:33] <pcjc2> ok, - will do, sorry for assigning you directly
[19:34] <lifeless> no worries
[19:34] <lifeless> I'm happy to look at it
[19:34] <pcjc2> that might have slowed progress if other potential reviewers ignored it as a result
[19:34] <pcjc2> I'll ask in #launchpad-reviews
[19:48] <thumper> flacoste: done
[19:48] <flacoste> thumper, thx
[20:10] <thumper> morning
[20:15] <maxb> Does anyone know if the fact launchpad is supporting jaunty PPAs long after the jaunty EOL is a deliberate choice? It was not so for intrepid
[20:25] <lifeless> maxb: accident I think
[20:30] <bryceh_> StevenK, https://code.launchpad.net/~bryce/launchpad/lp-617698-forwarding
[20:43] <jml> lifeless: is there a fixture for the librarian that I can use instead of the layer?
[20:44] <jml> hmm.
[20:44] <jml> found it.
[20:44] <pcjc2> Hi Bryceh_, you working on LP as well as Ubuntu-X now?
[20:44] <jml> (or should I actually use the layer)
[20:45] <lifeless> jml: the answer is probably 'you should use th elayer'
[20:45] <lifeless> jml: what are you doing ?
[20:46] <jml> moving some tests out of doctests
[20:46] <mwhudson> destroying cute kittens with the power of is mind
[20:47] <StevenK> lp:~stevenk/launchpad/lp-617698-forwarding
[20:47] <jml> I can use the layer without much hassle, I just thought I might try something.
[20:48] <lifeless> jml: so the layer has dependencies
[20:48] <lifeless> jml: its more appropriate for what you're doing
[20:49] <LPCIBot> Project devel build (357): STILL FAILING in 4 hr 24 min: https://hudson.wedontsleep.org/job/devel/357/
[20:49] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=699820] Ensure that
[20:49] <LPCIBot> buildfarmjob.date_finished is only set by the buildd-manager
[20:49] <LPCIBot> and not the upload processor so that we can accurately see the
[20:49] <LPCIBot> overhead that the upload processor incurs.
[20:49] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=702192] determineArchitecturesToBuild
[20:49] <LPCIBot> no longer fails when nominatedarchindep is not supported by the
[20:49] <LPCIBot> archive.
[20:51] <LPCIBot> Project db-devel build (265): STILL FAILING in 4 hr 22 min: https://hudson.wedontsleep.org/job/db-devel/265/
[20:51] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12190
[20:51] <LPCIBot> included.
[20:59] <lifeless> abentley: hi, if you're around, could you comment on the expected behaviour in bug 702524 ?
[20:59] <_mup_> Bug #702524: Merged branches keep 'Development' status when their merge proposal is marked as 'Merged' <Launchpad itself:New> < https://launchpad.net/bugs/702524 >
[21:13] <abentley> lifeless, the expected behaviour is that the branch scanner will detect merges.
[21:13] <lifeless> abentley: and change the branch state from 'development' to 'merged' ?
[21:13] <lifeless> abentley: its clearly detecting the merge, or the merge proposal wouldn't be changed to 'merged'
[21:14] <abentley> lifeless, per-branch detection of "merged" isn't tied to whether there is a merged merge proposal, and I believe it pre-dates merge proposals.
[21:15] <abentley> lifeless, I believe it depends on whether the branch has been merged into the development focus, but I'll have to check.
[21:16] <lifeless> abentley: if you could check that would be awesome; I mean - it seems like a reasonable request that this mark the branch as merged, but if there is a reason we don't, we can say so.
[21:18] <abentley> lifeless, we only mark a merge if it's a merge into the development focus, OR if there's a merge proposal and it's a merge into a series branch.
[21:18] <abentley> lifeless, thumper may have a better idea of the reasoning behind this.
[21:19] <lifeless> thanks
[21:19] <lifeless> hmm, thumper should be around anytime now ;)
[21:19] <abentley> lifeless, he's around.  We just had a chat.
[21:19] <abentley> lifeless, he's just on a call right now.
[21:19] <lifeless> thanks!
[21:21] <lifeless> jml: https://lpstats.canonical.com/graphs/KarmaActivityUpstreamsUbuntuWeek/20100114/20110114/
[21:21] <pcjc2> gah - internal only
[21:22] <jml> lifeless: yes?
[21:22] <lifeless> jml: poking around at our popularity via various proxies
[21:22] <jml> lifeless: oh, right. are you working on my talk for next week? :P
[21:22] <lifeless> I don't know... are you working on mine?
[21:23] <lifeless> jml: is there an 'active in the last month' ?
[21:23] <jml> lifeless: yes.
[21:23] <jml> lifeless: it's in the same area
[21:23] <lifeless> jml: I'd like to see how much churn/low frequency use there is
[21:23] <jml> lifeless: https://lpstats.canonical.com/graphs/KarmaActivePeople/
[21:24] <jml> lifeless: the data starts at ~2007-07-01
[21:24] <jml> lifeless: I find it useful to look at the whole of it when consulting those graphs
[21:24] <jml> lifeless: the Ubuntu release cycles become more obvious
[21:24] <lifeless> yeah
[21:24] <lifeless> the troughs are near identical
[21:24] <lifeless> pcjc2: sorry :)
[21:25] <micahg> lifeless: regarding edge URLs, granted the redirect will send people to the right place, but shouldn't the code be fixed not to send out e-mails with it?
[21:26] <lifeless> micahg: the code sends out emails based on the url they hit
[21:26] <micahg> lifeless: ah, so the user posting the comment was on edge
[21:26] <lifeless> micahg: 'fixing' it would be special casing edge as a domain to ignore even if running on edge
[21:26] <lifeless> which is just the sort of thing I want to be cleaning up, not adding :)
[21:26] <lifeless> micahg: yes, I very much expect they were
[21:26] <micahg> ah, ok, sorry, I thought the URL was because of me and not the person using LP
[21:27] <micahg> I confirmed this, I have some e-mails with non-edge URLs
[21:27] <micahg> sorry for the noise
[21:28] <lifeless> no worries
[21:36] <huwshimi> Morning all
[21:36] <mwhudson> hello huwshimi
[21:36] <StevenK> huwshimi: Morning! When do you fly out?
[21:38] <huwshimi> StevenK: In two days (Sunday Sydney time arrive Sunday Dallas time).
[21:38] <StevenK> huwshimi: Yes, I also live in Sydney, so I had that fun last weekend.
[21:40] <huwshimi> StevenK: Oh great. Will be nice to meet some fellow Sydney siders
[21:40] <StevenK> huwshimi: It's awesome we have to fly for 20-ish hours to meet each other
[21:41] <huwshimi> StevenK: Haha, only a little more than on a train to meet here though.
[23:24] <huwshimi> Hey, is anyone able to review a CSS bug fix (bug #684911: https://code.launchpad.net/~huwshimi/launchpad/broken-calendar-684911/+merge/46208)?
[23:24] <_mup_> Bug #684911: calendar overlay widget style broken after lazr-js 191 upgrade <javascript> <lazr-js-upgrade> <lp-web> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684911 >
[23:25] <thumper> huwshimi: ask sinzui in #launchpad-reviews :)
[23:25] <huwshimi> thumper: Ok thanks.