[12:16] <jordi> ychahibi: hmm, the problem with the oooo one is that i's a bit messy if I remember correctly
[12:16] <jordi> we need really good grammars, yes.
[12:16] <jordi> err, glossaries
[12:16] <lifeless> salgado: hiya
[12:17] <ychahibi> jordi, sure
[12:17] <ychahibi> jordi, the OOo glossary contains many non IT terms
[12:17] <jordi> yes
[12:17] <ychahibi> jordi, it also has to be classed into categories so translation can be easier
[12:21] <ychahibi> jordi, such a unified glossary can be useful for i18n projects, specially in the open source participation development, where translation is made by many contributers. Thus,any new contributor should know which terms were used by any former contributor.
[12:26] <mdke> ychahibi, rosetta already does that: it shows you every translation used for similar strings. That goes *some* of the way towards helping with that
[12:27] <mdke> I'd encourage you to use a mailing list/wiki page for now to coordinate about individual words, until Rosetta includes this functionality
[12:27] <ychahibi> mdke, yes.
[12:28] <ychahibi> mdke, won't it be better if the different languages used the same english terms database ?
[12:28] <mdke> what do you mean?
[12:28] <kiko> hey lifeless 
[12:29] <ychahibi> mdke, it would be nice to have a list of english words for all the languages to populate the wikipages with their equivalents in different languages 
[12:31] <mdke> ychahibi, you mean, technical words?
[12:32] <ychahibi> like computer, internet, hard disk ... related to computer sciences
[12:36] <mdke> ychahibi, that sounds like you'd be making a list to try and teach people English
[12:36] <ychahibi> mdke, no
[12:37] <ychahibi> mdke, something like http://l10n-status.gnome.org/HEAD/PO/gnome-glossary.HEAD.pot
[12:38] <mdke> i see
[12:38] <ychahibi> mdke, excuse my poor English :
[12:38] <ychahibi> :)
[12:39] <mdke> it's extremely good
[12:45] <matsubara> heh mtg
[12:45] <kiko> matsubara?
[12:45] <matsubara> I would benefit greatly to have that card 
[12:45] <matsubara> kiko: ponigru quit message.
[12:46] <matsubara> kiko: it's supposed to be a magic the gathering card.
[12:46] <kiko> yeah, I see
[12:46] <poningru> ng
[12:46] <poningru> sorry
[12:47] <matsubara> poningru: there's nothing to be sorry about. I was just commenting about your quit message. I used to play a lot of mtg in the old days.
[12:48] <poningru> hehe
[12:48] <poningru> I was apologizing for the stray piece of 'ng'
[01:21] <jordi> hmm, carlos's gone
[01:22] <jordi> and it's only 1:30 AM
[01:22] <kiko-zzz> I am too :)
[01:22] <kiko-zzz> (but I have work to do -- more work!)
[01:23] <jordi> you're going to sleep?
[01:23] <jordi> what time is it in Sao Carlos?
[01:24] <matsubara> jordi: 20:24
[01:25] <jordi> oh man, he's like a 6 y/o!
[01:25] <matsubara> like what?
[01:26] <kiko-zzz> six year old
[01:26] <kiko-zzz> late for swimming too
[01:29] <jordi> no swimming on thursdays
[01:29] <jordi> and it was even later last night anyway
[01:29] <jordi> and I couldn't sleep
[01:35] <matsubara> oh well. I need some sleep. see you later jordi.
[03:32] <jmg> np zero666
[05:00] <mpt> Goooooooooooooooooooooooooooood afternoon Launchpadders!
[05:08] <welshbyte> good 4:08am :)
[07:14] <lifeless> stub: I'm doing a test reconcile on balleny
[07:14] <lifeless> stub: debugging the revno problem
[07:15] <lifeless> stub: please not be killing bzr's :)
[07:15] <lifeless> it wont affect pqm, except memory pressure
[07:55] <spiv> lifeless: I'd like to merge in a backport of Twisted SVN r16671 to rocketfuel (for bug 41409) -- want to review or rubber stamp it?
[07:55] <Ubugtu> Malone bug 41409 in launchpad "initial push of a knit branch errors" [Critical,Confirmed]  http://launchpad.net/bugs/41409
[07:55] <lifeless> spiv: please
[07:55] <lifeless> (review)
[07:58] <spiv> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileSoLGjF.html
[08:21] <lifeless> r=lifeless
[08:22] <spiv> Thanks.
[08:22] <spiv> I've also added a related branch to the review queue, I have a diff ready if you don't want to wait for pending-reviews.
[08:22] <lifeless> sure
[08:23] <lifeless> oh there was one thing
[08:23] <lifeless> if you care to you could add a deprecation warning about the backend sending the bad exception
[08:24] <spiv> Yeah, that's a good idea.
[08:25] <spiv> I seperately need to refactor that exception handling, because it's starting to be duplicated in a few places in that class, so I think I'll hold off until I do that.  (Besides, I just sent the merge request a second before you suggested it ;)
[08:32] <lifeless> spiv: so where is this diff ?
[08:32] <spiv> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJQJkfg.html
[08:33] <lifeless> spiv: you can put the deprecation warning in twisted sv
[08:33] <spiv> lifeless: Yep, I'll do that tonight.
[08:36] <lifeless> how did you find setting up the interface based testing ?
[08:38] <lifeless> lastly, I think you might be leaking test????.tmp dirs
[08:38] <lifeless> as we aren't using the bzr test runner. Could you check for that ?
[08:38] <spiv> Yes, I am.
[08:39] <lifeless> +        self.local_branch = self.make_branch('.')
[08:39] <lifeless> +        tree = self.local_branch.bzrdir.create_workingtree()
[08:39] <lifeless> I would do
[08:39] <lifeless> tree = self.make_branch_and_tree('.')
[08:39] <lifeless> self.local_branch = tree.branch
[08:39] <spiv> I feel like the test_suite function is a bit more awkward than it needs to be, but I very much like the fact the facility exists.
[08:39] <spiv> I looked at make_branch_and_tree, I forget why I didn't use it.
[08:40] <spiv> I think probably for no good reason :)
[08:41] <lifeless> so, fixing the test leakage involves more cargo culting
[08:41] <lifeless> look in bzrlib/tests/__init__.py
[08:41] <spiv> I'd really like a way to say directly, "run this TestCase with X, Y and Z formats", rather than having to muck about with iter_suite_tests and stuff directly.
[08:41] <lifeless> yup
[08:41] <lifeless> its on my todo to refactor this
[08:41] <spiv> It could even hide the adapter from me, perhaps.
[08:42] <spiv> Cool.
[08:42] <spiv> Please consider this another data point for your refactoring :)
[08:42] <lifeless> so one possibility is an AdaptingTestSuite, whose run method clones on demand
[08:42] <lifeless> there are a number of possibilities :)
[08:42] <spiv> At the moment I think the minor ugliness is more than worth it for the benefits it gives, so I'm happy.
[08:43] <spiv> In the past, I've done this sort of thing with ad-hoc TestCase subclasses (which are then automatically discovered).
[08:43] <lifeless> anyhow, to remove the test????.tmp dirs, you need to remove TestCaseInTempDir.TEST_ROOT and reset it to None
[08:43] <lifeless> this is a wart
[08:43] <spiv> Which is sort of simpler, but a bit dirtier.
[08:43] <mpool> spiv: it seems to me it would be nice for test suites to declare
[08:44] <lifeless> (by remove, I mean shutil.rmtree
[08:44] <spiv> (e.g. there's twisted's FTP client test case with a 
[08:44] <mpool> "I want to run again all implementations of IFoo", or "the default IFoo", or "all that support something"
[08:44] <spiv> 'pasv' flag, and a trivial subclass than just sets the flag the other way).
[08:44] <stub> lifeless: ok (re. balleny bzr processes)
[08:44] <lifeless> spiv: right.
[08:44] <spiv> (or overrides a single simple method or something, I forget :)
[08:45] <lifeless> mpool: I think that when I make the scenario concept an object it will become simpler to use
[08:45] <spiv> lifeless: Ok, I'll do that.
[08:45] <lifeless> spiv: look at bzrlib.tests.run_suite
[08:45] <lifeless> mpool: because we can define precanned scenarios for those cases
[08:46] <spiv> lifeless: ta.
[08:46] <mpool> yep
[08:46] <spiv> lifeless: my other question about that branch is do you agree with my choice of formats I'm supporting?
[08:48] <lifeless> spiv: format 6 + all registered metadir formats - yes
[08:50] <lifeless> stub: I'm starting to plan the knit transition for launchpad
[08:50] <lifeless> https://wiki.launchpad.canonical.com/RocketfuelToKnits
[08:54] <spiv> lifeless: "Sender not authorised to commit to branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/twisted/trunk/"
[08:57] <lifeless> muhaha
[08:57] <lifeless> doth it pass tests ?
[08:57] <lifeless> remember, we dont run the twisted test suite, yet IIRC.
[08:58] <spiv> lifeless: Yes (not that http://twistedmatrix.com/buildbot/ really shows that, because of all the regular intermittent failures on every builder except full-2.4)
[09:00] <lifeless> where is your branch ?
[09:03] <lifeless> spiv: ^
[09:04] <spiv> lifeless: sftp://chinstrap.ubuntu.com/home/warthogs/archives/spiv/twisted/twisted-malone-bug-41409
[09:06] <lifeless> spiv: and what commit message wouldst thou liketh ?
[09:06] <spiv> "[r=lifeless]  Make the twisted.vfs SFTP adapter's removeFile method translate NotFoundError into the appropriate SFTPError."
[09:06] <lifeless> done
[09:09] <carlos> morning
[09:09] <ruffneck> morning carlos, how are you
[09:09] <ruffneck> http://matin.maapallo.org/site.pl/selain/?c=zits&i=439
[09:09] <lifeless> spiv: done
[09:10] <carlos> ruffneck: fine, thanks. And you?
[09:10] <spiv> lifeless: Thanks!
[09:11] <ruffneck> quite well; )
[09:17] <ruffneck> http://mikseri.mpoli.fi/hifi/download.php?fn=portrait_-_morrimoykky.mp3
[10:44] <SteveA> mpt: morning
[10:49] <SteveA> mpt_: morning
[10:57] <SteveA> mpt_: ping
[10:57] <kagou> anyone know how to remove calendar from https://launchpad.net/people/vetsel-patrice ?!
[11:02] <carlos> kagou: I don't think you can do it
[11:02] <kagou> so carlos should i report a bug ?
[11:03] <carlos> kagou: I don't think it's a bug...
[11:03] <carlos> kagou: but better ask jamesh, he wrote it
[11:03] <kagou> thanks carlos
[11:04] <jamesh> kagou: there is no facility for removing a calendar
[11:05] <kagou> jamesh: you mark this problem in your todo list or do i report a wish bug ?! ;)
[11:05] <jamesh> kagou: is there any particular reason you want to remove the calendar?
[11:06] <kagou> yes i'm not using it at all
[11:06] <kagou> and may be removing this saving cpu power/mem for the launchpad server
[11:07] <jamesh> kagou: it isn't a problem from the LP server end
[11:07] <mpt_> SteveA, pong
[11:07] <SteveA> mpt_: to the menus channel please!
[11:07] <kagou> ok jamesh. Thanks 
[11:28] <jamesh> hi ddaa
[11:29] <ddaa> hi jamesh
[11:30] <ddaa> didn't get the round tuits to look at your importd error reporting stuff
[11:31] <jamesh> ddaa: I've got bzrsync refactored and passing the existing tests again.  Just need to add the new tests you mentioned, and make sure they pass
[11:31] <ddaa> been scrambling to fix an important missing db constraint, then got sick :(
[11:31] <jamesh> so it now grabs the ancestry of the branch and imports all those revisions
[11:32] <jamesh> and if the revision exists, it makes sure the parent IDs match and are in the right order
[11:32] <jamesh> then goes through to synchronise the RevisionNumber objects
[11:32] <ddaa> that's great :)
[11:32] <jamesh> if it runs into a divergance, it truncates the history at that point
[11:33] <jamesh> so it should work correctly with a (branchid, revisionid) constraint on the RevisionNumber table
[11:33] <ddaa> I see, you truncate then recreate the revision numbers
[11:33] <jamesh> yeah
[11:33] <ddaa> it's not optimal, but it's the simplest way to deal with the new db constraints
[11:34] <ddaa> that could possibly go nasty on some pathological cases
[11:34] <jamesh> oh?
[11:34] <ddaa> Imagine an Arch import, with revision history several thousand revisions long
[11:35] <ddaa> with some missing ancestry
[11:35] <ddaa> the missing ancestry gets filled, and all the history gets shifted
[11:35] <ddaa> you have a divergence at the first revision in the history
[11:36] <jamesh> so there would be one truncate from rev 1 on, and then it recreates the RevisionNumber objects
[11:36] <ddaa> yup
[11:36] <jamesh> the alternative is to make the constraint a relaxed constraint (i.e. it can be broken temporarily during a transaction) and update all RevisionNumber objects in a single transaction
[11:37] <jamesh> although I'm not sure it will be a big deal in practice
[11:37] <ddaa> Some could be optimised out by truncating in a single query, but then you still need N query to fill the history, so it's not a significant improvement in term of algorithmic complexity. Probably not worth the trouble.
[11:38] <ddaa> jamesh: yeah, I was inappropriately concerned with long transactions. The branch-scanner is the only thing to update those tables, so there's no risk of lock contention.
[11:38] <jamesh> one issue might be if we have foreign keys pointing at RevisionNumber
[11:39] <ddaa> Mh
[11:39] <jamesh> but I suppose if the history changes for a branch, you wouldn't want old pointers at the RevisionNumber record
[11:39] <ddaa> there's a tension between me and sabdfl about that.
[11:40] <ddaa> he wants to use foreign keys to revisionnumber or revision (not sure which) when we need to point to a revision
[11:40] <jamesh> I suppose for things like bug branch linkage, it should use a Revision (even if it is displayed and entered in the UI as a revision number)
[11:40] <ddaa> I want to just use revision ids.
[11:40] <ddaa> Yeah, revision is much more robust.
[11:42] <ddaa> I'll be looking at your recent work once I have dealt with the current scramble for the missing db constraint on Branch, and after updating on my current backlog of pending merges.
[11:42] <jamesh> So if someone links (branch, revno) to a bug, it would actually store (branch, revision)
[11:42] <ddaa> depends on the use case here
[11:43] <jamesh> if revisions get renumbered, we could display the new revno (if it is still in the history), or indicate that it isn't in the revision history
[11:43] <ddaa> if we just want to know that a revision has been merged, we can just need the revision-id (the revision if sabdfl insists on it), and the branch is only a help for display as you say
[11:44] <ddaa> if we want to be able to checkout the given revision it's a bit more tricky, because we need a branch that does contain the revision in its repository.
[11:45] <ddaa> Which conflicts with the ability to change history and allow garbage collection on repositories.
[11:46] <ddaa> but that's a whole other can of worms
[11:46] <ddaa> not of concern right now, but good to keep in mind for future developments
[11:47] <jamesh> anyway.  Asking bzrlib for the branch ancestry rather than keeping a pending_parents list resulted in a net simplification of the code
[11:47] <ddaa> Ha, yes. That new bzrlib feature is really nice.
[11:48] <ddaa> brb
[11:50] <ddaa> sorry, not yet quite recovered, it's a realy PITA
[11:51] <ddaa> jamesh: I'm very happy to see you getting more responsive, I really need your help to get the branch stuff going smoothly
[11:53] <ddaa> let's recap what's on our plate
[11:54] <ddaa> after the branch scanner fix, there's the InternalHTTPLayer removal
[11:54] <jamesh> okay
[11:55] <ddaa> Then we will see how fast is the branch scanner when doing fewer transactions. Then you may or may not need to put some optimisations there.
[11:56] <ddaa> One thing I think would be nice to the user is to store the timestamp of the last scan in addition to the timestamp of the last pull, to account for the window where the branch mirorr is up to date but the listing is out of date.
[11:56] <jamesh> right now it commits one transaction for each new revision + one transaction for each changed revision number
[11:57] <jamesh> good idea.
[11:57] <ddaa> That same timestamp could be used to only scan branches which have been changed.
[11:57] <jamesh> would that be a timestamp of when the last scan started, or when it last successfully completed?
[11:57] <ddaa> jamesh: lifeless suggested just doing one transaction per branch. That should give some massive performance improvements.
[11:58] <ddaa> jamesh: mh... I'd say time of commit. The branch scanner is not supposed to fail ever.
[11:59] <jamesh> my branch adds a failure mode if the parent list for a branch changes.
[11:59] <jamesh> s/branch/revision/
[12:00] <ddaa> jamesh: that's a data corruption case as far as we are concerned. The db model is no prepared to deal with it.
[12:00] <ddaa> it's akin to what you get when you rm an Arch branch, then publish another branch by the same name. You are breaking model invariants.
[12:00] <jamesh> if we do a full scan in a single transaction, then the question about whether the timestamp is for the start or end is moot
[12:00] <jamesh> just use the time of the transaction
[12:01] <ddaa> right
[12:01] <ddaa> there's a few details to work out there too, for example avoid scanning branches which have never been successfully pulled.
[12:02] <jamesh> that's more an issue of what goes in the branch pull list though, right?
[12:03] <ddaa> jamesh: no, I'm thinking of removing all the BranchNotFound exceptions currently reported be the branch-scanner.
[12:03] <uws> hmm
[12:03] <uws> When will launchpad be able to track my 0.8 bzr branch?
[12:03] <ddaa> They are all caused by trying to scan branches which have never been successfully mirrored.
[12:04] <jamesh> uws: a knit branch?
[12:04] <uws> https://launchpad.net/people/uws/+branch/anewt/anewt-uws   is not updated anymore. jamesh: yes, I suppose tso
[12:04] <uws> so*
[12:04] <jamesh> uws: does "bzr info" say it is a knit format branch?
[12:04] <ddaa> uws: hu... right...
[12:05] <ddaa> lifeless has been pinging me about upgrading the bzrlib in launchpad so we can do that
[12:05] <uws> control: Meta directory format 1 working tree: Working tree format 3 branch: Branch format 5 repository: Knit repository format 1
[12:05] <ddaa> there's a new problem there
[12:06] <jamesh> uws: I think lifeless said that it is mainly an issue of upgrading the copy of bzr being used by the branch puller/scanner
[12:06] <ddaa> namely, the branch puller should delete the mirror branch if it does not have the same repository format as the source branch, then pull anew, because conversion between weave and knit is very cpu intensive.
[12:06] <uws> jamesh, ddaa: okay, when is that planned? I'd love to see the pages working again :)
[12:07] <ddaa> uws: cannot give you a firm date, but it should be a matter of weeks.
[12:07] <ddaa> ballpark: 2-3 weeks
[12:08] <ddaa> bzr 0.8 is not gold yet, is it?
[12:08] <uws> it isn't
[12:08] <jamesh> ddaa: https://launchpad.net/products/launchpad/+bug/41414 <- lifeless created a bug for that issue already
[12:08] <Ubugtu> Malone bug 41414 in launchpad "supermirror-branch-puller ignores format changes" [Normal,Unconfirmed]  
[12:09] <ddaa> jamesh: yup, that's it
[12:09] <ddaa> good to know salgado as been designated volunteer
[12:09] <jamesh> "designated volunteer" :)
[12:11] <ddaa> I'll take it that problem is under control, I really want to focus on clearing my backlog.
[12:11] <ddaa> So, two steps for knit support:
[12:12] <ddaa> 1. upgrade bzrlib, that should give knit support right away, but will let the mirror use the old format, which will hurt performance a lot
[12:12] <ddaa> (and annoy users too)
[12:13] <ddaa> 2. add logic to remirror on format change
[12:14] <ddaa> 1 should be easy. I expect some minor breakage because as a rule we ignore deprecation warnings until they turn into errors
[12:18] <jamesh> ddaa: I noticed one other weird issue in the bzrsync code: it was specifically checking if revision IDs were repeated in a revision's parents list, and only creating RevisionParent entries for the first occurrence (leaving gaps in the parent sequence numbers)
[12:18] <jamesh> was there any particular reason for doing this, as opposed to mirroring the parents list as is?
[12:18] <ddaa> Mh
[12:19] <ddaa> There was probably some reason that made sense at the time...
[12:19] <ddaa> there's a db constraint: "revisionparent_unique" UNIQUE, btree (revision, parent_id)
[12:20] <ddaa> duplicate parents are a contract violation in my understanding
[12:20] <ddaa> but that sort of shit does happen
[12:21] <ddaa> jamesh: I'm not quite sure whether we should faithfully reproduce what we find in the branch or not.
[12:21] <ddaa> it would be nice if you could check with lifeless or mpool about that.
[12:22] <jamesh> okay
[12:24] <ddaa> OTOH, nothing is using RevisionParent, it would be painful to use as SQL is really not suited to graph walking
[12:25] <ddaa> that information would be useful for revision display, like providing a bzrweb functionality in launchpad, but that would probably require an additional service on the supermirror anyway
[12:25] <ddaa> so it's clear that RevisionParent is not a YAGNI
[12:25] <ddaa> it's _not_ clear that...
[12:48] <carlos> BjornT: hi, do you have sometime to help me with a template problem I'm having?
[12:50] <BjornT> carlos: sure
[12:52] <carlos> BjornT: ok, thanks :-)
[12:52] <carlos> BjornT: I have this patch: https://chinstrap.ubuntu.com/~dsilvers/paste/file0tN8bJ.html
[12:52] <carlos> BjornT: it adds a new translation form for Rosetta
[12:53] <carlos> that is specific for one message instead of rendering 10 messages like the current one
[12:53] <carlos> I'm adding a new pomsgsetview but I'm reusing templates and views we are already using with the current translation form
[12:54] <carlos> but the code: 
[12:54] <carlos> +              <tal:block define="pomsgset_view view">
[12:54] <carlos> +                <metal:pomsgsetview
[12:54] <carlos> +                  use-macro="view/@@+pomsgset-translate/pomsgset-view"
[12:54] <carlos> +                  />
[12:54] <carlos> +              </tal:block>
[12:54] <carlos> is giving me problems
[12:55] <carlos> I have something similar in the current translation form and it works, but here, seems like the define is not working
[12:55] <BjornT> carlos: probably because the define causes 'view' to be called. if you really need the define, use define="pomsgset_view nocall:view"
[12:56] <carlos> well, the thing is that the macro wants a variable called 'pomsgset_view'
[12:56] <carlos> with the current translation form, it's defined as part of a loop
[12:57] <carlos> in this case, the own standard view is that pomsgset_view so we need to use an alias
[12:57] <BjornT> ok. so does it work if you use nocall?
[12:57] <carlos> checking it now...
[12:58] <carlos> hmm, it failed again, let me revert another change I did to be sure the failure is not cause by that other change
[01:00] <carlos> BjornT: yeah, it works now
[01:00] <carlos> BjornT: thank you!
[01:01] <BjornT> cool
[01:04] <carlos> but I don't understand exactly what's wrong to put there a view and get it 'called' it's just an object
[01:04] <carlos> so the call should do nothing unless you have the __call__ method, right?
[01:08] <doko> carlos: ku status? Erol's last comment to 41071?
[01:09] <cprov> good morning
[01:10] <carlos> doko: I saw it, don't worry I will take care of it
[01:13] <BjornT> carlos: tal always call the last object it traverses (foo/bar/last_object) whenever you use tal:define, tal:replace, tal:contents. views have a __call__ method automagically, so the define caused pomsgset_view to be a string.
[01:13] <carlos> oh, I see
[01:14] <doko> carlos: ok, a build is currently running, no ku translations from rosetta included
[01:15] <carlos> ok
[01:44] <lifeless> ddaa: there is a bug open on that
[01:47] <SteveA> meeting in 13 mins
[01:51] <ddaa> lifeless: ack, commented and subscribed to that bug
[01:52] <lifeless> ddaa: also see the support-repositories bug
[01:55] <SteveA> meeting in 5
[01:55] <SteveA> take a workrave now, or something
[01:59] <salgado> hey lifeless 
[02:00] <kiko-zzz> it must be meeting time!
[02:00] <SteveA> MEETING TIME
[02:00] <SteveA> who's here
[02:00] <SteveA> ?
[02:00] <jamesh> me
[02:00] <matsubara> me
[02:00] <carlos> me
[02:00] <salgado> me
[02:00] <BjornT> me
[02:00] <kiko> me
[02:00] <ddaa> me
[02:00] <bradb> me
[02:01] <SteveA> mpt just had a hardware problem.  he'll be back shortly
[02:01] <SteveA> spiv sends apologies
[02:01] <SteveA> lifeless sends apologies also
[02:01] <cprov> me
[02:01] <stub> Ouch
[02:01] <kiko> deserved!
[02:01] <SteveA> == Agenda ==
[02:01] <SteveA>  * Roll call
[02:01] <SteveA>  * Agenda
[02:01] <SteveA>  * Next meeting
[02:01] <SteveA>  * Activity reports
[02:01] <SteveA>  * Items from last meeting
[02:01] <SteveA>  * Launchpad oops milestone report
[02:01] <SteveA>  * Outstanding sysadmin requests
[02:01] <SteveA>  * Production / staging (stub)
[02:01] <SteveA>  * Decide who will be the bug contact for launchpad-dependencies.
[02:01] <SteveA>  * Keep, Bag, Change
[02:02] <SteveA>  * Three sentences
[02:02] <SteveA> 
[02:02] <SteveA> next meeting -- same time next week everyone?
[02:02] <SteveA>  * Activity reports
[02:02] <sivang> me
[02:02] <SteveA> yah, i suck -- i sent one this week :-(
[02:02] <SteveA> anyone doing better than me?
[02:02] <salgado> I'm up to date
[02:02] <kiko> I'm up to date
[02:02] <matsubara> up to date, but I've been batching them which is bad.
[02:03] <BjornT> i'm up to date
[02:03] <mpt> here!
[02:03] <carlos> I'm up to date
[02:03] <mpt> and up to date
[02:03] <cprov> i'm up to date
[02:03] <mpt> I've even caught up on a couple I forgot to send months ago :-)
[02:03] <SteveA> not heard from everyone yet
[02:04] <jamesh> i'm not up to date
[02:04] <ddaa> up to date
[02:04] <SteveA> jamesh: please send a summary
[02:04] <salgado> kiko, <salgado> I'm up to date
[02:04] <kiko> really now
[02:04] <salgado> you're not paying attention, dude!
[02:04] <SteveA> jamesh: please send a summary during this meeting
[02:05] <SteveA> props and respect to all who are up to date!
[02:05] <jamesh> okay
[02:05] <SteveA> thanks to mpt for compiling the last summary
[02:05] <SteveA>  * Items from last meeting
[02:05] <SteveA>  * '''BjornT''' to make it possible for anyone to close a support request
[02:05] <SteveA> BjornT: ?
[02:06] <BjornT> not done
[02:06] <SteveA> ok, so ItemForNextMeetingAgenda
[02:06] <mpt> that's less urgent now, because ...
[02:06] <SteveA> but, what's the reason we're tracking this item?
[02:06] <mpt> because we were getting many Launchpad support requests
[02:06] <mpt> and often the reporter doesn't close them
[02:07] <SteveA> what's changed?
[02:07] <mpt> ... because now we don't have the Launchpad support tracker links on the error pages any more
[02:07] <SteveA> we don't?
[02:07] <mpt> So it's still a problem, but not a major Launchpad project problem
[02:07] <SteveA> why was that link removed?
[02:08] <mpt> Because that's what we discussed at the meeting two weeks ago
[02:08] <SteveA> i wasn't here...
[02:08] <SteveA> please summarize
[02:08] <jamesh> SteveA: I believe it was because we already get a notification in the form of an OOPS report
[02:08] <mpt> see the minutes :-)
[02:08] <mpt> And many of them were either duplicates, or "asdfasdf"
[02:08] <ddaa> freelinexcd!
[02:08] <SteveA> hmm
[02:09] <SteveA> i think we may be leaving users with legitimate problems stranded
[02:09] <mpt> It now suggests mailing launchpad-users@ instead
[02:09] <SteveA> that's a pain
[02:09] <SteveA> because people need to subscribe
[02:09] <SteveA> or it makes more work for the list admins
[02:09] <mpt> exactly
[02:09] <SteveA> does it say "you need to subscribe before mailing that address?"
[02:09] <kiko> SteveA, we got /too/ many bogus reports
[02:09] <kiko> 99% of the reports were bogus
[02:10] <SteveA> maybe we need a pre-filesupportrequest-from-error page
[02:10] <mpt> SteveA, I didn't give an address, I linked to the listinfo page for subscribing
[02:10] <jamesh> spambayes, maybe? :)
[02:10] <kiko> (and I may be stretching it because I can't remember the 1%)
[02:10] <mpt> I can remember one that was an actual bug reported by someone outside Canonical
[02:10] <ddaa> kiko: the legit 1% were "please remove dud object" requests IIRC
[02:10] <SteveA> for now, please add to the page a note that people must subscribe to the list to post to it, mpt
[02:11] <mpt> and about three more that were reported by Canonical staff who might as well have reported a bug
[02:11] <SteveA> okay.
[02:11] <kiko> the points are: a) we already track OOPSen daily b) users don't read, so it doesn't matter if we tell them "File a support request if this blocks you from doing something".
[02:11] <SteveA> i think we should consider still using the support tracker, but think about how people can be directed there, in a way that makes it harder for them to file shite
[02:12] <SteveA> for the next meeting
[02:12] <kiko> well, I get the impression that the most thoughtful considerations will come in via -users
[02:12] <SteveA> continuing with the items from last meeting...
[02:12] <kiko> I have not seen anyone very clueful use the support tracker
[02:12] <SteveA>  * '''jamesh''' to change his error report script cron job to point at the copy of the script in rocketfuel-built, to let anyone to fix bugs, and to mail kiko about it
[02:12] <kiko> no email to me
[02:13] <kiko> but I wanted to be able to remove the 15 limit for crashes
[02:13] <SteveA> explicit infinitives are the way forward
[02:13] <kiko> and list all crashes
[02:13] <jamesh> I'll send the email now with details on updating the script
[02:13] <kiko> I also want to know wtf is up with staging oopses
[02:14] <kiko> because that's blocking our work on QAing staging
[02:14] <SteveA> kiko: i'll add that to the meeting agenda
[02:14] <SteveA>  * '''mpt''' to remove support request links from the error page
[02:14] <mpt> ... done.
[02:14] <SteveA>  * '''SteveA''' and '''cprov''' to talk about the zope security system
[02:14] <jamesh> I'll update the cron job to do staging OOPSs too
[02:14] <SteveA> cprov: resolved?
[02:15] <kiko> jamesh, problem is I don't think staging oopses are being mirrorred across
[02:15] <SteveA>  * '''stub''' to report a bug on increasing the # of retries attempted
[02:15] <cprov> we talked but looks like to solution to my issue goes in another direction, I'm testing your suggestion.
[02:15] <SteveA> ok, cprov, we'll talk again about it when you've updated the code
[02:15] <SteveA> stub: ?
[02:15] <SteveA>  * '''stub''' to discuss making Retry exceptions more informative, on the PostgreSQL mailing lists
[02:15] <cprov> SteveA: right
[02:15] <SteveA>  * '''stub''' to tell kiko where staging oopses are being stored
[02:16] <stub> Bug reported
[02:16] <jamesh> kiko: see chinstrap:/srv/asuka-logs
[02:16] <kiko> mmmm
[02:16] <kiko> k
[02:16] <stub> Staging logs are /srv/launchpad.ubuntu.com/staging-logs/ on asuka
[02:17] <SteveA> do these appear on chinstrap:/srv/asuka-logs ?
[02:17] <jamesh> they seem to be
[02:17] <stub> I recall it was rt'd for that to be the case
[02:18] <kiko> yep
[02:18] <kiko> they do
[02:18] <jamesh> there are OOPS reports from 2005-12-14 to 2006-04-27 there
[02:18] <kiko> jamesh, well, 05-26
[02:18] <kiko> err 04-26
[02:18] <jamesh> yeah
[02:19] <SteveA> ok
[02:19] <SteveA> good
[02:19] <SteveA> that is all the items from the last meeting
[02:19] <SteveA>  * Launchpad oops milestone report
[02:19] <SteveA> matsubara: 
[02:20] <matsubara> I've been tracking the oops report daily, reproducing and reporting bugs there. I'll add to my daily routine 'bothering people to get some of the bugs fixed' specially those that I can't fix myself :)
[02:20] <matsubara> Outstanding bug from today: non-ascii-password bug blowing up launchpad. I'm fixing it and I hope I'll finish it today, now that I'll remove all the password confirmation from some of the login token interactions.
[02:20] <mpt> hooray
[02:20] <matsubara> About the NotFound errors kiko has a patch that fixes some of them, right?
[02:20] <kiko> yes
[02:20] <kiko> and you haven't replied to my email yet.
[02:21] <matsubara> and I have to take a closer look at the oops report today
[02:21] <stub> I recall that there were some rationalizations for the 'enter password' confirmations, but I can't recall what they were. Anybody?
[02:21] <mpt> How easy is it to guess tokens?
[02:21] <SteveA> very hard. 
[02:21] <stub> Unguessable
[02:21] <SteveA> would be easier to intercept them
[02:21] <mpt> ok then
[02:21] <kiko> stub, mark would know
[02:22] <stub> Anyone talking to Mark today?
[02:22] <kiko> I could email him
[02:22] <SteveA> okay
[02:22] <BjornT> i'd guess one reason could be that the user will be logged in after visiting the token, which can be bad if someone intercepts the token.
[02:22] <SteveA> MeetingAction kiko, mail mark about this workflow
[02:23] <stub> Ok. Worth asking before Matsubara gets carried away pulling the password checks out.
[02:23] <SteveA> anything more on the oops milestone report?
[02:23] <kiko> BjornT, and we send email which is non-encrypted
[02:23] <kiko> that's the issue I think
[02:23] <jamesh> I suppose the password prompt makes it more difficult to steal someone's LP password
[02:23] <BjornT> kiko: i assume so
[02:23] <kiko> I remember now -- anyone can steal the link if they sniff their mailboxes
[02:23] <jamesh> if it was missing and I stole someone's LP cookie, I could add an email address set it as preferred and reset the password
[02:23] <salgado> BjornT, the user will not be logged in anymore
[02:23] <salgado> right, matsubara?
[02:24] <stub> jamesh: If you stole someones LP cookie, you could just reset the password.
[02:24] <jamesh> salgado: you don't need to be logged in to use the logintoken URL
[02:24] <jamesh> stub: that emails their current preferred email address though, right?
[02:24] <matsubara> salgado: right
[02:24] <salgado> jamesh, right, but today we may log him in after the validation is finished
[02:24] <SteveA> we have various other items in this meeting
[02:25] <salgado> this won't be possible anymore
[02:25] <SteveA> so, i'd like us to discuss this at more length afterwards
[02:25] <stub> ok.
[02:25] <SteveA> thanks
[02:25] <SteveA>  * Outstanding sysadmin requests
[02:25] <SteveA> any?
[02:25] <BjornT> 6081 blocks the debbugs bug watches sync
[02:25] <SteveA> that's an RT number?
[02:25] <kiko> uhm IIRC yes, but my browser won't start up so I can't tell. ddaa? BjornT? stub?
[02:26] <BjornT> SteveA: yeah
[02:26] <stub> I had a query about frequency and number of backup snapshots we keep, which hasn't been responded to (not in rt though)
[02:26] <kiko> what's it about BjornT?
[02:26] <ddaa> kiko: no RT bothering me right now
[02:26] <kiko> thanks ddaa 
[02:26] <BjornT> kiko: syncing the debbugs db daily, so that we can update the bug watches
[02:26] <stub> I also had a query asking if the debbugs mirror on gangotri is being synced daily, as we are getting a lot of 'debbugs bug not found' errors.
[02:26] <SteveA> MeetingAction: steve to talk with admins about priority of RT-6081
[02:27] <SteveA> stub: is that the same as issue 6081, or different?
[02:27] <kiko> that's the same apparently
[02:27] <BjornT> yeah, it's the same
[02:27] <stub> url? I can't drive rt
[02:28] <SteveA> ok
[02:28] <SteveA>  * Decide who will be the bug contact for launchpad-dependencies.
[02:28] <ddaa> lifeless volunteered
[02:28] <SteveA> really?
[02:28] <carlos> SteveA: yes
[02:28] <carlos> he sent an email to launchpad's mailing list
[02:28] <SteveA> okay.  so it is lifeless
 I also want to know wtf is up with staging oopses
[02:29] <mpt> Is it safe to install launchpad-dependencies in Dapper now?
[02:29] <stub> Bug 41739
[02:29] <Ubugtu> Malone bug 41739 in launchpad "Increase number of Retry attempts" [Normal,Unconfirmed]  http://launchpad.net/bugs/41739
[02:29] <SteveA> kiko: any further things on that
[02:29] <SteveA> ?
[02:29] <kiko> SteveA, apparently it's all good
[02:29] <sivang> mpt: I have it installed and updating since some time now, no real trouble 
[02:29] <sivang> mpt: (at least that I could notice)
[02:29] <mpt> So I won't be downgraded unexpectedly or anything
[02:29] <carlos> mpt: I'm using it
[02:29] <mpt> ok
[02:30] <SteveA> ddaa: landing bazaar-ui branch
[02:30] <mpt> I have to finish re-reviewing it, which is #1 on my to-do list except for the menus stuff
[02:30] <ddaa> sabdfl just gave me heat about this branch not landing yet, maybe there's something wrong with our process that caused it to stay outside for so long.
[02:31] <kiko> ddaa, are you looking for advice?
[02:31] <sabdfl> i don't like busting a gut on weekends to get code done for someone then not finding that in production a month later
[02:31] <ddaa> kiko: trying to find a way to prevent making sabdfl unhappy again with that sort of problem
[02:32] <sabdfl> it would be good to have metrics on the review process - time to land code, basically
[02:32] <kiko> I'll follow up in private on this, but my general advice is to be more practical when seeking and commenting on the review.
[02:32] <SteveA> we should move the review process into launchpad to get those metrics
[02:33] <SteveA> or... use bzr branch metadata
[02:33] <kiko> sabdfl, there is a general QoS level for reviews but in this case it's more that the branch has gone through multiple iterations.
[02:33] <ddaa> First it got reviewed by spiv for code, which called for a few fixes. Then it got reviewed by mpt who called for quite a number of changes. I think all were called for.
[02:33] <kiko> can we follow this up in private? I already know what advice to give. SteveA?
[02:33] <SteveA> were all called for in a way that required blocking it from landing?
[02:34] <SteveA> kiko: yes, but i'd like a summary report to the launchpad list
[02:34] <sabdfl> i like the idea of a general review mechanism in LP that can work for package uploads as well as branch landings
[02:34] <SteveA> once you've followed up
[02:34] <ddaa> Maybe there is a problem with the acceptable quality for landing code, maybe review should be more geared toward "can land, but please fix that ASAP"
[02:34] <kiko> sure
[02:34] <sabdfl> mpool and i need to work up some ideas there
[02:34] <SteveA> in general, i'm happy for code to land that has UI issues, if it is still usable
[02:34] <SteveA> i'm not happy for code to land that has problems with its code quality
[02:34] <SteveA> we can fix UI issues as we go
[02:35] <SteveA> but code quality causes other developers a headache
[02:35] <kiko> sabdfl, taking advantage of the fact you're here, can you confirm that the reason we ask for a password to validate a token is to avoid people stealing the URL from an email and taking over the person's account?
[02:35] <stub> I feel landings are often delayed unnecessarily. If code is going in the right general direction and considered an improvement on what is already there, I don't see a reason for not landing it immediately and the review fixes done post landing.
[02:35] <kiko> basically my advice is stub's.
[02:36] <ddaa> Sounds good, probably follow up in reviewers meeting.
[02:36] <SteveA> stub: yeah, let's follow up in the reviewers meeting.
[02:36] <sabdfl> stub: +1, though code quality should be sorted pre-landing, UI issues can be solved in a followup
[02:37] <SteveA> MeetingAction: lifeless to put this on the agenda for the reviewers' meeting
[02:37] <sabdfl> "please fix that ASAP" turns into large numbers of XXX's
[02:37] <SteveA> time to move on...
[02:37] <sabdfl> code quality should be 100%, test coverage in place, before landing
[02:37] <kiko> well, even "code quality" has varying levels
[02:37] <sabdfl> ok, you guys find a comfortable level
[02:37] <kiko> so reviewers need to use good common sense
[02:37] <kiko> anyway, enough on this topic
[02:37] <sabdfl> we've benefited from the strict review
[02:38] <SteveA> sabdfl: thanks for giving your support to the team aiming for high quality code.
[02:38] <SteveA>  * Keep, Bag, Change
[02:38] <kiko> sabdfl, taking advantage of the fact you're here, can you confirm that the reason we ask for a password to validate a token is to avoid people stealing the URL from an email and taking over the person's account?
[02:38] <SteveA> with a countdown...
[02:38] <SteveA> kiko: please, ask sabdfl in private
[02:38] <ddaa> KEEP: salgado, stub and jamesh doing good work helping me deal with Bazaar stuff
[02:38] <SteveA> not much time left in the meeting
[02:38] <SteveA> 8
[02:38] <SteveA> 7
[02:38] <SteveA> 6
[02:38] <SteveA> 5
[02:38] <SteveA> 4
[02:38] <ddaa> I really appreciate what all of you guys have done in the past weeks.
[02:38] <SteveA> 3
[02:39] <SteveA> 2
[02:39] <SteveA> 1
[02:39] <SteveA> okay, thanks ddaa
[02:39] <mpool> sabdfl: hi
[02:39] <SteveA>  * Three sentences
[02:39] <SteveA> go ahead!
[02:39] <mpt> DONE: Menus styling+feedback, Rosetta bugfixes, administrivia
[02:39] <mpt> TODO: Finish bazaar-ui and r3472 reviews, land MaloneSimplifications
[02:39] <mpt> BLOCKED: not enough time in the day
[02:39] <carlos> DONE: Dapper translation domains fixes, KDE imports, bugs #32610 #39879 #41371, oo.org fixes
[02:39] <carlos> TODO: Finish PoMsgSetPage, fix ku ooo translations, move language pack export script into production and plan with kiko my next tasks, the list is huge.
[02:39] <carlos> BLOCKED: Kiko and I should meet to plan my next tasks
[02:39] <ddaa> DONE: InternalHTTPLayer fix, some pending branches work, missing Branch db constraint, got sick
[02:39] <ddaa> TODO: more pending branches work, review jamesh work, cscvs/bzr-native, one day
[02:39] <ddaa> BLOCKERS: urgent problems, discussion and pending branches backlog do not leave me time for cscvs/bzr-native
[02:39] <Ubugtu> Malone bug 32610 in openoffice.org "all untranslated messages imported from OOo are marked as translated" [Normal,In progress]  http://launchpad.net/bugs/32610
[02:39] <matsubara> DONE: oops report reproducing and reporting, fixing non-ascii password, debugging bug in +translate form
[02:39] <SteveA> lifeless: DONE: bzr 0.8 stabilisation, reviews, etc etc.
[02:39] <SteveA> lifeless: TODO: Same.
[02:39] <SteveA> lifeless: BLOCKED: Nada.
[02:39] <matsubara> TODO:  finish the non-ascii password one, support request and bug triage
[02:39] <matsubara> BLOCKED: no
[02:39] <SteveA> spiv: DONE: Holiday!  Read a heap of email.  Bug 41409 (supermirrorsftp + knits).
[02:39] <SteveA> spiv: TODO: Reviews, make 'make check_merge' test all of sourcecode again.
[02:39] <SteveA> spiv: BLOCKED: no.
[02:39] <Ubugtu> Malone bug 41409 in launchpad "initial push of a knit branch errors" [Critical,In progress]  http://launchpad.net/bugs/41409
[02:39] <cprov> DONE: fix critical bugs in Soyuz and open Edgy tests on dogfood
[02:39] <cprov> TODO: more critical bugs, finish Edgy test, queue-ui + perms definitive fix
[02:39] <cprov> BLOCKED: SQL patch for dup librarian filenames (dsilvers)
[02:39] <jamesh> DONE: importd stuff (error collector script, bzrsync history rewriting, small amount on branch-pull-list in authserver), anzac day
[02:39] <jamesh> TODO: more importd stuff, code reviews
[02:39] <jamesh> BLOCKED: no
[02:39] <BjornT> DONE: fixed a few issues related to zope3. made timeouts work again. discussed bug watches.
[02:39] <BjornT> TODO: more work regarding bug watches as per discussion. take a closer look at testbrowser.
[02:39] <BjornT> BLOCKED: no
[02:40] <salgado> DONE: ShipItForDapper tweaks and tests, test the mirror-prober on mawson, found some bugs and fixed them, some work on the branch-puller, code review and fixed bug #5542
[02:40] <salgado> TODO: Get shipit ready for review, merge mirror-prober fixes, more code review. maybe (if shipit allows me to) start working on CoC bugs
[02:40] <salgado> BLOCKED: No
[02:40] <Ubugtu> Malone bug 5542 in malone "Malone shouldn't say "No matching results found" (inaccurate and imprecise)" [Normal,Fix released]  http://launchpad.net/bugs/5542
[02:40] <stub> DONE: Erm... something I hope :-/
[02:40] <stub> TODO: Text searching
[02:40] <stub> BLOCKED: Nope
[02:40] <ddaa> BLOCKED: urgent problems, discussion and pending branches backlog do not leave me time for cscvs/bzr-native
[02:40] <SteveA> DONE: dynamic menus work, code reviews, management
[02:40] <SteveA> TODO: virtual host improvements, crowdcontrol
[02:40] <SteveA> BLOCKED: no
[02:40] <SteveA> 
 BLOCKED: SQL patch for dup librarian filenames (dsilvers)
[02:41] <SteveA> does Kinnison know about this?
[02:41] <SteveA> i mean, that you're blocked?
[02:41] <kiko> DONE: management: overseeing Rosetta and Malone, daily OOPS and error log checking, performance reviews, minor template fixes, upgrades to Dapper
[02:41] <kiko> TODO: performance reviews, land minor fixes, more managing, staging oops control
[02:41] <kiko> BLOCKED: hopefully nothing now that staging oops reports are underway
[02:41] <bradb> DONE: Spec on IBug.last_updated. RFC'd launchpad@. Landed BP removal. Landing bugtask dates. Interviewed LP dev candidate.
[02:41] <bradb> TODO: Reach agreement on/and IBug.last_updated. Other stuff.
[02:41] <bradb> BLOCKED: No.
[02:41] <cprov> SteveA: it seems to be sorted in production, but I need to discuss the results with him and land it in LP
[02:42] <SteveA> cprov: arrange a meeting time with him today, and tell me if there's a problem
[02:42] <SteveA> stub pointed out that i'd fogotten:
[02:42] <SteveA>  * Production / Staging (stub)
[02:42] <stub> Most of the recent landings have been bug fixes suitable for cherry picking, and as a result production is currently running very close to HEAD. I will try and skip next weeks rollout if possible - it depends on what lands in the next few days. I don't think a rollout of current HEAD is warrented.
[02:42] <stub> The after-lunch staging update scheduled during the London sprint has been stopped, as it was interrupting stuff Carlos needs to do on the database.
[02:42] <stub> Production database has been growing recently, and we are now up to about 40GB of production data + indexes. This means the entire DB no longer fits in RAM :-) I'd be interested in opionions on what the extra data is - I expect pofile imports.
[02:42] <SteveA> stub: can you not ask the database what the extra data is?
[02:43] <bradb> SteveA: I just thought of an admin request: kill malone-users.
[02:43] <SteveA> bradb: i don't understand that, but if you have an admin request, you should write an RT ticket for it
[02:43] <SteveA> and tell me the RT number
[02:43] <SteveA> be sure to describe the issue fully in the RT ticket
[02:43] <carlos> stub: yes, pofile imports is one of the causes for that
[02:43] <kiko> it must be translations
[02:43] <stub> SteveA: I haven't got historical data on size of individual tables. I have row counts, but that doesn't directly correspond to size.
[02:43] <bradb> kill malone-users => remove the malone-users mailing list, since noone's using it
[02:43] <SteveA> Any other people blocked on things and need unblocking, other than cprov?
[02:43] <kiko> can we get more memory? :)
[02:44] <SteveA> i think various data will rarely be used
[02:44] <carlos> SteveA: I'm blocked, but I already agreed with kiko that we need to have the meeting
[02:44] <SteveA> more memory probably isn't useful right now
[02:44] <carlos> to unblock me
[02:44] <stub> kiko: Not on this hardware :-)
[02:44] <SteveA> carlos: okay, good
[02:44] <cprov> SteveA: I'll work to be unblocked til the end of the day.
[02:44] <jamesh> BjornT: re. the debbugs data, are you aware of the mirror on macquarie? (it was being used by debzilla)
[02:45] <kiko> stub, I wasn't really serious. we should just strangle carlos. :)
[02:45] <jamesh> BjornT: it is probably still updating
[02:45] <SteveA> okay, end of meeting time
[02:45] <kiko> thanks SteveA for another meeting well delivered
[02:45] <carlos> kiko: it's not my fault, it's dapper's one ;-)
[02:45] <SteveA> thanks for keeping to the agenda folks
[02:45] <SteveA> mpt has offered to write up again
[02:45] <SteveA> MEETING ENDS
[02:45] <kiko> mpt is a marvel
[02:45] <carlos> thanks 
[02:46] <carlos> see you later
[02:48] <mpt> That's because it's SteveA who's the marvel
[02:48] <BjornT> jamesh: no i'm not. i'm not sure how easy it is to have the cronscript run there, though.
[02:48] <sivang> mpt: :)
[02:50] <salgado> so, should we talk about the password on the logintoken pages now?
[02:53] <salgado> [4542261.378000]  Out of Memory: Killed process 6895 (ssh-agent).
[02:53] <salgado> [4542261.469000]  Out of Memory: Killed process 6906 (gnome-settings-).
[02:53] <salgado> [4542261.509000]  Out of Memory: Killed process 6907 (gnome-panel).
[02:53] <salgado> just because of a bzr commit
[02:54] <stub> I don't see how protecting against a hacked mailbox or sniffable emails is necessary, as the simplest attack would be to issue a 'forgotten password' request and follow the link.
[02:54] <mpool> salgado: sorry 
[02:55] <salgado> no worries. I know this is fixed already
[02:55] <salgado> I hope so, at least. :)
[02:56] <kiko> stub, I was talking to sabdfl now as well
[02:56] <kiko> he pointed out that people have to log in to the site already anyway
[02:56] <kiko> so we do have some risk of phishing already
[03:01] <richips> I'm looking for some aid with Rosetta
[03:02] <richips> Do I have to translate things as <emphasis role="bold">international fonts</emphasis>
[03:02] <kiko> you've come to the right place!
[03:02] <richips> :)
[03:03] <kiko> the translation should be <emphasis role="bold">fontes internacionais</emphasis> richips -- HOWEVER there is a bug in Rosetta that was fixed yesterday that is relevant to you
[03:03] <richips> tell me
[03:03] <kiko> what browser are you using?
[03:04] <richips> Morzilla Firefox
[03:10] <kiko> we all love accountants
[03:13] <sivang> kiko: heh
[03:17] <richips> So... what's that relevant BUG, kiko?
[03:17] <kiko> richips, argh, I forgot I was looking for that. sorry, juggling.
[03:17] <matsubara> richips: bug 39879
[03:17] <Ubugtu> Malone bug 39879 in rosetta "Translation string is crashing replacer function" [Major,Fix committed]  http://launchpad.net/bugs/39879
[03:17] <kiko> the bug is that we don't handle angle brackets inside textarea properly!
[03:18] <kiko> you can translate but you'll get bogus content stuck into that string
[03:18] <kiko> it's very unfortunate but it'll be fixed by next week
[03:18] <uws> just use standard xml escaping
[03:18] <kiko> he can't do that though
[03:18] <kiko> it is a problem in the HTML generated
[03:18] <uws> yeah, of course
[03:19] <kiko> it was a regression that we didn't test; we now do
[03:19] <richips> So... should I keep on traslating?
[03:20] <kiko> richips, well... I guess yes. we'll need to come back next week and sort this out for you anyway.
[03:20] <richips> Or should I wait for the bug to be fixed?
[03:20] <kiko> you'll get a weird effect after saving -- it will appear as though you have a string missing in the form
[03:20] <kiko> and if you're in opera, it will appear as though you have /two/ strings!
[03:21] <kiko> we didn't request an emergency fix because, well, I didn't think it would affect anyone this week :)
[03:22] <richips> Cool :)
[03:24] <richips> And... what about xrefs? How should I traslate it?
[03:24] <kiko> xrefs?
[03:24] <richips> <xref linkend="add-applications"/>
[03:24] <richips> That kind
[03:25] <kiko> you should translate nothing inside angle brackets
[03:25] <richips> OK
[03:28] <kiko> oh!
[03:29] <kiko> it's been fixed, richips 
[03:29] <kiko> it was fixed today.
[03:29] <kiko> richips, can you give me a URL to the page you're translating?
[03:29] <kiko> carlos, ping
[03:30] <richips> Wow, how fast...
[03:30] <richips> https://launchpad.net/distros/ubuntu/dapper/+source/kubuntu-docs/+pots/desktopguide/es/+translate?offset=220
[03:30] <richips> Actually, it starts at the first offset
[03:32] <kiko> okay.
[03:33] <kiko> richips, yes, it's been fixed. translate away!
[03:33] <richips> :D
[03:46] <richips> oh, another ask... <menuchoice><guimenu>View</guimenu><guimenuitem>Show Hidden Files</guimenuitem></menuchoice>
[03:46] <richips> Thats translatable?
[03:47] <richips> Should I translate the menu names and options?
[03:53] <ddaa> sabdfl bazaar-ui branch (without some of the UI fixes) in pqm queue
[03:54] <sabdfl> ddaa: rock, thanks!
[03:59] <SteveA> nice!
 should I translate this? It has brakets...
[04:05] <richips> I mean, the 'right' part
[04:13] <salgado> spiv, ping
[04:13] <spiv> salgado: pong
[04:15] <salgado> spiv, hey. if you're not leaving soon, maybe you'd like to have a look at a small patch I have for the mirror prober?
[04:15] <salgado> (it's mainly to make sure it honours the http_proxy env var and to batch the HEAD requests)
[04:15] <spiv> salgado: sure, I can do that.
[04:16] <salgado> great
[04:16] <salgado> spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/filehGG0Jh.html
[04:18] <spiv> +                # XXX: This might not be a good idea because we'll never have
[04:18] <spiv> +                # BACKPORTS for the in-development distrorelease, neither
[04:18] <spiv> +                # PROPOSED for already-released distroreleases. There might be
[04:18] <spiv> "neither" -> "nor" is more correct English.
[04:18] <salgado> ah, right
[04:18] <spiv> (always a good sign if I'm only finding English nitpicks...)
[04:19] <salgado> anyway, I've talked to kiko and these warnings are going away. so the comment will go away too
[04:19] <spiv> Heh.
[04:19] <spiv> Is self._parse still used?
[04:20] <salgado> no, I'm using twisted.web.client._parse instead
[04:20] <salgado> I'm just not sure if it's okay to use it
[04:20] <spiv> Also, using twisted.web.client._parse is treading on thin ice... it's clearly not a public API (even though twisted.web is unlikely to change dramatically any time soon).
[04:21] <salgado> exactly. that's what I thought
[04:21] <salgado> better to keep with self._parse, I guess?
[04:21] <spiv> Unfortunately, I think so.
[04:26] <spiv> Is it worth moving PROBER_TIMEOUT into launchpad.conf?
[04:26] <ddaa> thinICE sounds like xlib programming
[04:28] <salgado> spiv, I'm not sure... but kiko's over my shoulder telling me to say yes
[04:29] <spiv> Ok, I that's enough to convince me.  Make it proper config value :)
[04:29] <salgado> I will
[04:34] <SteveA> hello spiv
[04:34] <spiv> salgado: Aside from that, r=spiv
[04:34] <spiv> SteveA: Good, er, morning.
[04:35] <salgado> spiv, great. thank you!
[04:42] <matsubara> kiko, SteveA, mpt: is this right? portlets are now in the middle column: https://launchpad.net/distros/ubuntu
[04:50] <matsubara> kiko!
[04:50] <matsubara> kiko, SteveA, mpt: is this right? portlets are now in the middle column: https://launchpad.net/distros/ubuntu
[04:51] <kiko> matsubara, yes, it's a change mark did, as an experiment.
[04:51] <kiko> it's been in production for a while now
[04:52] <SteveA> might look better with a subtly different box outline
[04:52] <SteveA> like, maybe just the background and not a strong border
[04:52] <SteveA> or something
[04:52] <kiko> it's easy to do that
[04:52] <SteveA> so that it looks like they're deliberately there, and not just "fallen off" from the portlet columns
[04:59] <kiko> carlos, ping?
[05:00] <matsubara> hm ok then, it surely looks strange.
[05:00] <matsubara> kiko: you've got mail, btw :)
[05:01] <SteveA> matsubara: you can file a bug on mpt on what kiko and i just talked about
[05:01] <kiko> thanks mats
[05:01] <kiko> SteveA, or I can just go ahead and do it as part of my template fixes
[05:01] <kiko> they can only land next week though
[05:01] <kiko> tuesday
[05:02] <SteveA> kiko: if you can think of a good style to use
[05:02] <SteveA> me, i just know it should be different, but not what to change it to
[05:03] <kiko> I'll do it
[05:03] <SteveA> cool
[05:07] <matsubara> SteveA: reported bug 41755 and assigned to kiko then
[05:07] <SteveA> excellent
[05:24] <lucasvo> I can't find a search field on https://launchpad.net/malone
[05:24] <lucasvo> where can I search for bugs?
[05:25] <kiko> lucasvo, you first need to decide what you want to search for bugs in.
[05:25] <kiko> lucasvo, is it in Ubuntu?
[05:25] <kiko> or some other "thing"?
[05:25] <lucasvo> I'd like to search all the comments for the term "edubuntu"
[05:26] <kiko> lucasvo, /all/ the comments in all of the bugs on everything? even on launchpad?
[05:28] <lucasvo> yes
[05:29] <lucasvo> kiko: why shouldn't I?
[05:29] <kiko> it's not possible to do so, today.
[05:30] <lucasvo> and only the titles?
[05:30] <lucasvo> or description
[05:31] <kiko> you can't search through all the bugs in Malone, period
[05:31] <kiko> you can however search through bugs in ubuntu, if that helps
[05:31] <kiko> using /distros/ubuntu/+bugs
[05:31] <bradb_> #1 in pqm, that is
[05:32] <kiko> lifeless?
[05:32] <bradb_> er, "Now Playing" that is! :)
[05:32] <bradb_> it should be "now playing..."
[05:37] <bradb> Executing star-merge sftp://chinstrap/home/warthogs/archives/bradb/launchpad/malone-bug-dates/ at Thu Apr 27 16:35:19 2006
[05:37] <bradb> Seems like it started breathing again.
[05:38] <kiko> mmmm
[05:40] <BjornT> kiko, bradb: lifeless said earlier that he was doing a test reconcile on balleny. maybe that's still running and is slowing pqm down.
[05:41] <doko> carlos: stop lunching ;-P
[05:41] <kiko> ah maybe
[05:41] <kiko> BjornT, you're always great on IRC. how do you do it?
[05:43] <bradb> yeah, it's like running tests now!
[05:43] <BjornT> kiko: probably by spending too much time at the computer during non-work hours :-/
[05:43] <bradb> heh
[05:44] <kiko> possibly, mmm. I appreciate it, at any rate.
[05:44] <kiko> reponsiveness on IRC makes me feel I am less sundered from you lot
[05:55] <ddaa> it does not appear to be running tests anymore
[05:55] <ddaa> probably doing bzr houskeeping
[05:56] <ddaa> :( that can take a looong time
[05:58] <ddaa> ha yes, making progress
[05:58] <ddaa> it's running tests, it's just dog slow
[05:59] <carlos> doko: sorry, went out to have lunch with my girlfriend and it took more time than usual...
[05:59] <carlos> kiko: pong
[05:59] <kiko> hey carlos
[06:00] <kiko> was going to ask you about the import statistics report that just came out, and also, to remind you to get the broken </textarea>s fixed in production now that your patch has been rolled out and verified.
[06:03] <carlos> kiko: about the first thing, we got another race condition and pitti's script got yesterday tarball, we are fixing it now
[06:03] <carlos> kiko: today we got 762 translation domains
[06:03] <carlos> instead of the 628 the report says
[06:04] <carlos> kiko: about the cherry pick, that's cool. Thank you I will take a look to the broken entries and ask translators to fix them
[06:05] <kiko> carlos, okay, cool.
[06:09] <doko> carlos: yeah, some things are more important
[06:09] <doko> carlos: how/when can I get the OOo po files from rosetta?
[06:13] <doko> the new OOo build is in the archive now, so after the import of the files, I would need the files for the -l10n build.
[06:13] <carlos> doko: usually, the import takes two days....
[06:14] <carlos> doko: https://launchpad.net/rosetta/imports?status=APPROVED&type=all
[06:14] <carlos> there you have the list of files we are importing atm
[06:14] <carlos> most of them are OOo ones
[06:15] <doko> just 800?
[06:19] <kiko> doko, "just"?
[06:19] <kiko> that's a lot of translations!
[06:20] <carlos> kiko: oo.org is huge
[06:21] <doko> kiko: 50 x 65.000 messages
[06:21] <carlos> doko: well, 800 is the amount of .po files not the amount of messages
[06:22] <carlos> and there are some .po files that aren't from oo.org
[06:32] <kiko> carlos, can pitti regenerate the report? I'd like to read it.
[06:32] <carlos> kiko: he's doing it already
[06:33] <carlos> I want to read it too 
[06:33] <kiko> thanks very much
[06:33] <carlos> it will help me to know what's missing
[08:17] <carlos> I need to leave now
[08:18] <carlos> will be back later
[08:22] <ruffneck> I'll be back
[08:28] <kiko> just like arnie
[08:29] <ddaa> hey pqm, is there anyfuckingbody in there???
[08:29] <kiko> it's slow today eh?
[08:30] <ddaa> no change in the status for one hour AFAICT
[08:30] <kiko> yeah, 3h for bradb earlier
[08:30] <bradb> i waited four hours for "failure"
[08:30] <kiko> he he
[08:30] <kiko> what failed bradb?
[08:30] <bradb> five tests
[08:31] <kiko> tis life on the pqm-test
[08:31] <salgado> I've been waiting for brad's 4 hours, now ddaa's 4 hours and then my own 4 hours
[08:31] <salgado> I hope I don't get a failure
[08:31] <bradb> it's that sweet spot in agile development
[08:42] <kiko> thanks for the oops fix salgado 
[08:43] <salgado> it was a regression I caused, so I thought it'd be a good idea to fix it. (it was trivial, I have to admit)
[08:43] <kiko> and tested? :)
[08:44] <salgado> sure
[08:45] <salgado> almost TDD. I write the fix, then I comment it out, make a test, see that it fails, then I uncomment the fix
[08:46] <kiko> yeah I've done that before 
[08:55] <bradb> BjornT: 75-bugtaskwatchlinkage.txt is no longer relevant, is it?
[08:59] <bradb> er, at least specifically the test at line 35
[09:00] <ruffneck> http://www.youtube.com/watch?v=7SGLtxKkw6s&search=helsinki
[09:00] <BjornT> bradb: it's still relevant (although i'll re-write it slightly), since in the recent discussion we decided that it should be possible to unlink/link bug watches 
[09:01] <kiko> heh heh
[09:01] <bradb> BjornT: the test at line 35 seems to test something that can't currently be done in the UI, unless I'm missing something
[09:02] <bradb> and it's causing a:
[09:02] <bradb>     + <li>  Module canonical.launchpad.subscribers.karma, line 66, in bugtask_modified<br />
[09:02] <bradb>     +     assert task_delta is not None</li>
[09:02] <bradb> which is pretty annoying
[09:02] <bradb>     + <BLANKLINE>
[09:02] <bradb>     + </ul>AssertionError
[09:03] <BjornT> bradb: ah, that's true. it will be relevant soon, though :) feel free to delete it if you want, i'm going to rewrite it anyway.
[09:03] <kiko> yeah, delete all our tests, see if I care :)
[09:04] <bradb> well, might as well delete tests that are testing things that can't currently be done
[09:05] <BjornT> bradb: actually, it can be done in the UI, can't it?
[09:05] <bradb> not from what i can see, but maybe i'm missing something
[09:07] <BjornT> bradb: https://launchpad.net/distros/debian/+source/openssl/+bug/6761/+editstatus
[09:07] <Ubugtu> Malone bug 6761 in openssl "openssl: Expired certificates and recertification" [Unknown,Confirmed]  
[09:09] <bradb> yeah, i just added a second watch task and this time it showed the widget correctly. /me tries to figure out how i added another task without it showing that widget.
[09:10] <bradb> i added a task on evolution, linked to debbugs 123, and it added debbugs 123 in the portlet, but the task looked like a normal non-linked one
[09:11] <kiko> cprov-afk, I just got a fat-ass message from the library GC
[09:11] <kiko> 5.7M
[09:12] <BjornT> bradb: ah, that's a bug i'm going to fix in the branch i'm working on. evolution uses malone, so it can't have a bug watch linked to it
[09:13] <bradb> ah, ok. (indeed, i just reconfirmed the bug...pretty confusing.)
[09:15] <kiko> BjornT, why is our bugmail not getting wrapped?
[09:17] <jordi> carlos: is https://launchpad.net/distros/ubuntu/dapper/+lang/ca now working as expected?
[09:17] <jordi> ie, shows all?
[09:20] <cprov-afk> kiko: wow, could publish it somewhere ? 
[09:20] <BjornT> kiko: i'm not quite sure. it seems like it has problem wrapping when the comment has more than one paragraph. descriptions get wrapped properly, though, even though they have more than one paragraph. i can take a closer look tomorrow if i have time.
[09:21] <kiko> BjornT, I forwarded you the bugmail
[09:21] <kiko> cprov-afk, yeah, it's in launchpad-error-reports
[09:23] <cprov-afk> kiko: ahhh got it, killed thunderbird, though
[09:23] <kiko> cprov-afk, mutt dude. mutt.
[09:23] <kiko> carlos, you got mail
[09:24] <kiko> cprov-afk, why is bug 41583 critical?!
[09:24] <Ubugtu> Malone bug 41583 in soyuz "when publishing a security update, a template USN email needs to be generated" [Critical,Unconfirmed]  http://launchpad.net/bugs/41583
[09:25] <cprov-afk> kiko: :P. Bunch of deletions and it did found duplicated contents (a lot) I'm surprised.
[09:25] <kiko> yeah same here
[09:26] <cprov-afk> kiko: it's part of the security by soyuz milestone (to be created), I can reduce the severity if you want 
[09:27] <dilys> Merge to devel/launchpad/: [r=spiv]  sabdfl's bazaar-ui with some incontroversial fixes from mpt's review (r1828: David Allouche, Mark Shuttleworth)
[09:27] <ddaa> Yeeeeeeepeeeee!
[09:27] <kiko> yeah, cprov-afk -- major at most. it's a new feature, not a critical regression
[09:28] <cprov-afk> kiko: you're right.
[09:31] <lucasvo> I think it would be helpfull if a link Edit Status would be in the menu when viewing a bug
[09:31] <lucasvo> it is not very intuitive to click on the package name
[09:32] <lucasvo> when everything else is usually done over a link in the menu
[09:33] <lucasvo> I mean this: https://launchpad.net/distros/ubuntu/+source/sabayon/+bug/38410/+editstatus
[09:33] <Ubugtu> Malone bug 38410 in sabayon "Edubuntu clients can't log-in after sabayon is installed." [Normal,Confirmed]  
[09:37] <matsubara> bradb: is there an open bug to "Automatically subscribe me when I comment on change or edit its status"?
[09:38] <matsubara> bradb: it's similar to bug 977 that you just fixed.
[09:38] <Ubugtu> Malone bug 977 in malone "Commenting on bug should optionally subscribe you" [Major,Fix committed]  http://launchpad.net/bugs/977
[09:38] <ddaa> good night guys
[09:38] <matsubara> bradb: nm, found it
[09:39] <ddaa> woman is calling me from the sleeping end of the office
[10:21] <lucasvo> is there a bazaar irc channel?
[10:22] <mdke> lucasvo: #bzr for bazaar-ng, I think
[10:23] <mdke> I'm thinking they'll know bazaar too if you need it
[10:28] <lucasvo> I mean the versioning system
[11:23] <carlos> jordi: I don't think that page is fixed yet...
[11:23] <carlos> kiko: let me see
[11:26] <kiko> carlos!
[11:26] <carlos> hmm
[11:27] <carlos> kiko: That kind of upload is not using any guess
[11:27] <carlos> kiko: we already know the pofile where it should be imported
[11:27] <kiko> it's strange indeed then
[11:27] <carlos> yes
[11:27] <carlos> I see three options:
[11:28] <carlos> 1. The user didn't upload the file where he said he did
[11:28] <carlos> 2. Jordi changed where it should be imported (I didn't do it)
[11:29] <carlos> 3. We have a really weird bug there.
[11:29] <carlos> the problem is that I don't think any of those options as valid... and the more realistic one is 3.
[11:29] <carlos> but is really weird....
[11:42] <carlos> ok
[11:42] <carlos> found the problem
[11:43] <carlos> kiko: the link to the POFile that we are supposed to have there is not working
[11:43] <carlos> and thus, we are using the guessing algorithm
[11:43] <kiko> aha.
[11:43] <kiko> that sounds more like it
[11:43] <kiko> the bug /sounded/ like a guessing bug
[11:44] <carlos> the thing is that the guessing code should not be executed in that situation
[11:44] <carlos> because, in first place, we already know the pofile
[11:45] <kiko> why is it?
[11:48] <carlos> kiko: we are not storing the pofile in ITranslationImportQueueEntry.pofile attribute
[11:48] <kiko> carlos, huh?! ever?!
[11:48] <carlos> don't know, need to debug it
[11:49] <carlos> I guess it's a concrete code path
[11:49] <carlos> because I'm sure I wrote that code, unless we had a regression....
[11:50] <kiko> argh
[11:54] <carlos> well, dudes, I need to sleep
[11:54] <carlos> see you tomorrow
[11:55] <carlos> kiko: I already updated the bug report
[11:56] <kiko> rock on carlos