[00:09]  * rockstar goes to search for dinner
[00:12] <wgrant> The project owner has an implicit subscription to all of the project's bugs unless there is a bug supervisor set. The bug supervisor can unsubscribe from its subscription, but the owner cannot. Is this intentional?
[00:12] <wgrant> So, basically, you must have a bug supervisor set or the owning team gets spammed.
[00:13] <wgrant> I wonder if it's a holdover from when bug supervisors couldn't unsubscribe either.
[00:28] <maxb> Total: 23204 tests, 8 failures, 7 errors in 236 minutes 9.812 seconds.
[00:28] <maxb> karmic, python2.4
[00:28] <maxb> devel r9098
[00:28] <wgrant> maxb: pastebin beckons.
[00:28]  * kfogel is away: Smithwicks w/ Omar
[00:28] <wgrant> I must set LP up in a karmic chroot...
[00:43]  * thumper wanders up the road for a coffee
[00:46] <maxb> Hmm, so several appear to be because I was holding out making sqlite available to python 2.4 until I verified what wanted it
[00:48] <maxb> canonical/lazr/doc/timeout.txt failure... http://paste.ubuntu.com/252217/ - mean anything to anyone?
[00:49] <maxb> test_realiseUpload_for_delayed_copies - http://paste.ubuntu.com/252218/ - DONE != ACCEPTED assertion failure
[00:50] <wgrant> maxb: There were no errors before that last one?
[00:50] <maxb> no
[00:51] <maxb> and then lastly soyuz/doc/gina.txt and soyuz/doc/package-diff.txt are very unhappy
[00:51] <wgrant> gina.txt gets unhappy sometimes.
[00:52] <wgrant> ubuntu-meta sometimes fails to unpack on Karmic.
[00:52] <wgrant> Even though it always works when I do it manually.
[00:52] <wgrant> I might look further into that today, if it's that close to working on 2.4 Karmic.
[01:03] <maxb> yup, confirmed, with the appropriate additional sqlite packages, down to just the 4 mentioned failures
[01:27] <maxb> documented on LaunchpadOnKarmic
[02:36] <wgrant> maxb: I can only reproduce the package-diff.txt and gina.txt failures.
[02:37] <wgrant> The package-diff.txt one was an easy fix (debdiff in < Karmic is buggy, and doesn't obey the manpage wrt. exit codes; Karmic's does)
[02:37] <wgrant> gina.txt I'm looking at now...
[02:37] <wgrant> But it's non-deterministic :(
[02:53]  * wgrant kicks gina a few times for being non-Zopey, non-Stormy, and non-deterministic.
[03:12] <cprov> wgrant: on the bright side it is still importing debian 2x day with no complaints, has its merits.
[03:13]  * cprov has to setup an karmic chroot, it's about time.
[03:14] <wgrant> cprov: Indeed. It works mostly.
[03:14] <wgrant> But has strange strange strange issues in karmic.
[03:15] <cprov> maxb: on the test_realiseUpload_for_delayed_copies failure, print the 'logger.buffer' it might contain a hint about what's going worng.
[03:16] <cprov> wgrant: paste me the complete failure if you can.
[03:16] <wgrant> cprov: It's an error 29 (ESPIPE!?) running dpkg-source on a variable number of packages.
[03:17] <cprov> wgrant: did anything sensible changed in karmic dpkg ?
[03:17] <wgrant> cprov: I'm trying to work out exactly what it does so I can try to reproduce.
[03:17] <wgrant> Since the command it says errored works fine.
[03:17] <wgrant> So it might be something in Python.
[03:21] <cprov> wgrant: `dpkg -sn` ?? there is no -n switch
[03:22] <wgrant> cprov: Maybe not, but it works.
[03:22] <wgrant> Just sometimes not when gina does it.
[03:23] <wgrant> The number of failures differs each time.
[03:23] <wgrant> Sometimes it succeeds.
[03:23] <wgrant> cprov: Ah, -sn is one option. Of course.
[03:24]  * wgrant waits for slow slow uni proxies.
[03:25] <cprov> wgrant: yes, -sn exists, my bad
[03:27]  * cprov goes to bed.
[03:28] <wgrant> Night cprov.
[03:33] <kfogel> barry: are you actually on right now?
[03:37] <wgrant> (I noticed that it actually means the exit code was 29, not that an error with errno 29 occurred)
[03:38] <kfogel> thumper: thanks for the review.  I'm getting 'bzr: ERROR: unknown command "pqm-submit" '... isn't pqm-submit part of the launchpad plugin?
[03:50] <thumper> kfogel: no, it is bzr-pqm
[03:50] <kfogel> thumper: ah
[03:51] <kfogel> thumper: so I'm confused because it's *always* Just Worked from this box, and now suddenly it doesn't.  AFAIK I didn't do anything to change things... well, whatever.  I'll go look for the plugin.
[03:52] <thumper> kfogel: which bzr?
[03:52] <kfogel> thumper: trunk, recent
[03:52] <kfogel> /usr/local/bin/bzr
[03:52] <kfogel> symlink to my src
[03:53] <kfogel> thumper: submitted
[04:04] <thumper> spm: ping
[04:05] <spm> thumper: heyo
[04:06] <thumper> spm: can I get logs for the scripts bmp creation jobs
[04:06] <thumper> spm: (both of them)
[04:06] <thumper> spm: logs synced that is
[04:06] <thumper> spm: I should see why I didn't get an email from karl
[04:07] <spm> kk
[04:09] <spm> thumper: bzrsyncd is done; doing codehost atm (can't recall offhand which one that stuff runs on)
[04:10] <thumper> spm: me neither
[04:10] <thumper> I'd love to rename the jobs so I can get it right
[04:10] <spm> ignorance shared is.... hmmm. ignorance squared?
[04:12] <spm> thumper: mpcreationjobs is bzrsyncd, fwiw
[04:15] <wgrant> cprov, maxb: The gina.txt failure is a Karmic dpkg bug, which is probably maybe sort of tracked in bug #399938.
[04:15] <mup> Bug #399938: unpacking the upstream tarball not working <apport-bug> <i386> <bzr-builddeb (Ubuntu):Fix Released> <https://launchpad.net/bugs/399938>
[04:25] <wgrant> Hrm, the explanation in the bug was not clear.
[04:25] <wgrant> It looks like it might actually be that the fixed dpkg bug has the same symptoms that are caused by Python ignoring SIGPIPE.
[04:25]  * wgrant pokes harder.
[04:32] <wgrant> There we go.
[04:32] <wgrant> Fixed.
[05:09] <thumper> spm: still cherrypicking?
[05:14] <spm> thumper: ha. 4 hour test run? yes. :-)
[05:14] <thumper> :(
[05:14] <thumper> spm: plz get faster 'puter
[05:14] <spm> thumper: pls write faster tests
[05:15] <spm> last word. I win. :-P
[05:15] <wgrant> I can haz ec2test and review?
[05:15] <wgrant> lp:~wgrant/launchpad/karmic-2.4-fixes
[05:15] <wgrant> I've only tested on karmic and jaunty, not hardy.
[05:22] <thumper> spm: arg
[05:27] <spm> thumper: hopefully should be finishing sometime in the next hour, hour & ½.
[05:27] <thumper> ok
[05:57] <jtv> thumper: while you wait, can you help me figure out a problem I'm looking at?
[05:58] <thumper> jtv: me waiting?  hah, but sure - hit me
[05:58] <jtv> that thumper... last time he was in a slapping mood, now he's in a be-slapped mood
[05:58]  * jtv hits thumper
[05:58] <jtv> *any-way*...
[05:59] <jtv> My script commits translations snapshots to a bzr branch.  Works fine generally.
[05:59] <thumper> I feel a but coming along
[05:59] <jtv> But there's a project that exports its translations back to the same branch it also imports translations from.
[06:00] <jtv> That _should_ work.  The imports are based on branch jobs when the branch changes, the exports are done from a cron job.
[06:00] <jtv> If the exporter sees that there's an unfinished translations import job on the branch, it backs off from committing to it.
[06:01] <jtv> But I notice that for several days in a row now, every daily run sees this situation and backs off.
[06:01] <thumper> ok...
[06:02] <jtv> On staging there are such jobs, except they're all completed.
[06:02] <thumper> how do you determine an unfinished translation import job
[06:02] <jtv> Exactly.
[06:02] <thumper> ah
[06:02] <thumper> don't we have a start time?
[06:02] <jtv> Well I look at type and status.
[06:02] <thumper> OK, the way I see it you need two things:
[06:02] <thumper> firstly
[06:03] <lifeless> thing
[06:03] <lifeless> ...
[06:03] <lifeless> profit!
[06:03] <jtv> lifeless: thanks, that's very helpful
[06:03] <jtv> can we skip straight to the profit?
[06:03] <thumper> unfinished should mean pending, that has started but not yet finished :)
[06:03] <lifeless> jtv: I aim to please.
[06:03] <thumper> rather than just pending in the future some time
[06:03] <lifeless> better than aiming at peas.
[06:03] <jtv> cringe
[06:03] <thumper> and the import job would need to know not to run while an export is running on the same branch
[06:04] <thumper> lifeless: better than aiming your pee
[06:04] <jtv> no, actually aiming your pee is quite useful.
[06:04] <lifeless> thumper: if you don't aim you will dis please
[06:04] <thumper> jtv: as long as it isn't at you or me
[06:04] <jtv> thumper: actually it's the other way around—I want the import job to complete peacefully and the export job to back off.
[06:04] <thumper> it all depends on the target
[06:05] <jtv> I'm just trying to figure out why the exporter hits that situation quite so often.
[06:05] <thumper> jtv: yes, but if there is an export job running, you don't want the import job to start right?
[06:05] <thumper> jtv: my guess is that when an import job has finished, it creates another at some future time
[06:05] <jtv> thumper: the exporter has the branch locked anyway.
[06:06] <jtv> I don't suppose the stuff I'm doing with the branch causes RosettaUploadJobs to be created even before I commit?
[06:07] <jtv> AFAICT the import job does not create a new instance of itself: it's created by the branch scanner when a change is detected.  Besides, on staging I only see completed ones.
[06:07] <thumper> hmm..
[06:08] <thumper> I'd say get a losa to run queries for you
[06:08] <jtv> it _might_ be an unlucky interference between cron jobs I guess
[06:08] <thumper> to see if production is like you think it should be
[06:08] <thumper> jtv: possibly
[06:08] <thumper> but I don't think so
[06:08] <jtv> owww, do I _have_ to talk to spm again?  :-)
[06:08] <thumper> it seems wrong
[06:08] <thumper> jtv: no, you could wait for herb :)
[06:09] <jtv> spm it is then :)
[06:10] <jtv> For the "I'm unwittingly creating the job myself" hypothesis I could ask a losa to give the export job an extra run...
[06:13] <jtv> thumper: ahhhhh I think I may have it
[06:13] <jtv> Job.id == BranchJob.id
[06:13] <jtv> Bad join condition.
[06:14] <thumper> haha
[06:14] <thumper> yes
[06:14] <jtv> Should be Job.id == BranchJob.job
[06:14] <thumper> right
[06:19] <thumper> jtv: I CC'ed you on my email about query performance
[06:19] <thumper> jtv: I thought you might have some ideas
[06:19] <thumper> jtv: it went to the launchpad-dev list anyway
[06:19] <jtv> thumper: I see it
[06:20] <jtv> and I owe you a look.  :)
[06:20] <thumper> jtv: I _think_ we may be able to speed up the queries with an index
[06:20] <thumper> jtv: I'm hoping
[06:20] <thumper> or we may need some other magic
[06:21] <jtv> thumper: I'll have a look.  Most well-documented "query performance post" I've seen so far.
[06:22] <thumper> jtv: thanks
[06:22] <jtv> thumper: this is a common pattern... IIRC BjornT had a similar optimization problem dealing with "either non-private or visible to this user."
[06:22] <jtv> Maybe we should just have a team for Everyone.  :)
[06:23] <jtv> thumper: you're always checking for ownership, even though you've got a done deal in the common case where the branch is public.
[06:24] <jtv> thumper: (assuming the "private = %s" means "private is false")
[06:24] <thumper> jtv: it is
[06:24] <thumper> in the subscription one we only look for private
[06:24] <jtv> you'll want to limit the ownership check to private branches
[06:25] <thumper> do you think that it makes that much of a difference?
[06:25] <thumper> perhaps it does
[06:26] <jtv> thumper: it's hard to say; it's right at the other end of the join so maybe not.  But even then we'd hate ourselves for not checking.
[06:26] <thumper> jtv: it could be huge
[06:26] <thumper> jtv: given that we have 150k branchesnow
[06:26] <jtv> child's play
[06:26] <thumper> it is a one line fix
[06:26] <jtv> wanna play with the TranslationMessage table?
[06:26] <thumper> that should break no tests
[06:27] <thumper> jtv: looked at the branch revision table?
[06:27] <thumper> I think we win
[06:27] <jtv> ah now, branch _revision_ table is big I know
[06:27] <jtv> how big is it?
[06:27] <thumper> biggish
[06:27] <jtv> how biggish?
[06:27] <spm> jtv: heyo
[06:28] <thumper> spm: want to compare some timings for me?
[06:28] <jtv> hi spm!  nm, thumper sat by the couch as I wrestled through my emotional problems and resolved the issue
[06:28] <spm> jtv: errr. oki. I'll try not to feel left out, unwanted etc
[06:29] <jtv> (It was something to do with my mother not loving me, or a bad join condition)
[06:29] <spm> thumper: is that a trick question?
[06:29] <thumper> spm: what is my person id?
[06:29] <thumper> spm: I'm assembling the query now
[06:30] <jtv> thumper: you can also move the selection of all public branches out of the union: "Branch.private = FALSE OR Branch.id IN (... UNION ...)"
[06:30] <spm> thumper: 433852
[06:34] <thumper> spm: http://pastebin.ubuntu.com/252311/
[06:34] <thumper> spm: there are three queries there
[06:35] <spm> thumper: oki
[06:35] <thumper> spm: much appreciated
[06:36] <spm> thumper: in return. does this look spurious or serious to you? https://pastebin.canonical.com/21094/
[06:36] <jtv> spm, thumper: also, try this with a partial index on private branches only.  Indexing just the "private" attribute may not be quite as effective.
[06:37] <spm> can't find any mention of that failed test beyond that.
[06:37] <thumper> spm: spurious I think
[06:37] <thumper> jtv, spm: the partial index thing is probably best done on staging :)
[06:37] <thumper> jtv: can you give spm an example of what you mean?
[06:37] <spm> I wasn't planning on doing it on prod! :-)
[06:37] <thumper> spm: I wouldn't think you would
[06:38] <thumper> spm: are you running my three on staging?
[06:38] <thumper> spm: staging is fine I think
[06:38] <spm> thumper: prod, but can shift?
[06:38] <thumper> spm: I just need comparitive results
[06:38] <thumper> spm: prod is fine too
[06:38] <thumper> I think the first one takes around 1200ms
[06:38] <spm> thumper: coolio. do you need the output or, sure you've got it right?
[06:38] <thumper> I don't need the output, just the times
[06:39]  * spm ndos
[06:39] <thumper> the output should be the same for all three
[06:39] <thumper> if it isn't
[06:39] <thumper> something is wrong
[06:39] <thumper> spm: it is just a count of active reviews I'm doing
[06:39] <thumper> spm: it won't be very big
[06:40] <jtv> I'd try "CREATE UNIQUE INDEX foo ON Branch(id) WHERE private IS TRUE" and "CREATE INDEX bar ON Branch(owner) WHERE private IS TRUE" and then run the query with the "private IS TRUE" condition on the ownership check.
[06:40] <jtv> One or the other might catch something.
[06:40]  * thumper waits 
[06:40] <spm> thumper: 1st was 2.2secs, then 1.7 to 1.9secs on later runs. result is count = 1.
[06:40] <thumper> I'm EODing after this
[06:41] <thumper> spm: ok
[06:41] <thumper> spm: that matches what I'm seeing in the oopses
[06:42] <spm> thumper: 2nd was 2.9 for first; then consistant 1.8's; again count == 1
[06:42] <thumper> ok, not much in that one then
[06:42]  * thumper taps his foot
[06:43] <spm> thumper: wow. I think you want to use #3. 0.127secs from the get go
[06:43] <thumper> w00t
[06:43] <thumper> jtv: you tha man
[06:43] <spm> 10x improvement is impressive
[06:43] <thumper> I think I can submit that fix easily
[06:43] <spm> +1 from me for it at any rate :-)
[06:43] <jtv> I haven't exactly followed the channel...  what was it that did it?
[06:44]  * thumper branches now
[06:44] <thumper> jtv: the third query in the pastebin
[06:44] <thumper> jtv: moving Branch.private = False out of the union
[06:45] <jtv> thumper: cool, I think I've repaid you for the day then.  :)
[06:45] <thumper> jtv: that you have, thanks
[06:45] <jtv> my pleasure, sir
[06:46] <thumper> ok...
[06:47] <thumper> not as trivial as I hoped
[06:47] <jtv> uh-oh
[06:47] <thumper> but I think I can get it done tomorrow
[06:47] <thumper> it is more how we handle visibility checks in the branch collection code
[06:47] <thumper> I was hoping for a two line fix
[06:47] <thumper> and it will be longer
[06:47] <thumper> but still relatively simple I think
[06:47] <thumper> but not for today
[06:47] <thumper> I'll look at it tomorrow
[06:48]  * thumper acts like a tree
[06:48] <jtv> Oh, I think I've looked at that code once and the function calls to build up the query go pretty deep.
[06:48] <jtv> What do trees do?  Grow?  Metabolize carbon dioxide?  Get hugged by hippies?
[06:49] <spm> trees? cut down and turned into beautiful furniture? a la my lovely jarrah desk I built that I'm sitting at atm
[06:50] <jtv> spm: we don't want thumper to be get cut down and turned into furniture, now do we?
[06:51] <jtv> (*Beautiful* furniture could be hard, but let's generalize the principle)
[06:51] <spm> ah. that'll teach me for reading approximately ONE line of scrollback and responding. Doh.
[06:51] <jtv> No worries.  All makes for good entertainment.
[06:52] <spm> LOSA Duties: operational sysadmin; general entertainer; etc
[06:54] <jtv> spm: dance for us!
[06:54] <jtv> (At this point I bet ara is wondering...)
[06:55] <spm> jtv: I dance... on  the inside
[06:56] <jtv> ooh, nice comeback
[06:56] <jtv> so nice in fact that I'll refrain from making jokes like "inside of what?"
[06:57] <spm> heh
[07:27] <maxb> +  * lib/lp/soyuz/tests/../doc/gina.txt - tar broke dpkg. dpkg was fixed. python breaks the fix. wgrant has a fix.
[07:27] <maxb> whoa, sounds hellish :-)
[07:28] <wgrant> maxb: Nasty signal stuff.
[07:28] <wgrant> But see lp:~wgrant/launchpad/karmic-2.4-fixes
[07:28] <wgrant> All fixed.
[07:28] <wgrant> Soyuz tests pass now.
[07:29] <wgrant> That one took a little while to track down.
[07:40]  * maxb wonders how on earth we get valid archives wherein tar doesn't consume all the compressed data
[07:40] <wgrant> Who knows.
[07:41] <wgrant> But it happens...
[07:41] <wgrant> Often.
[08:03] <wgrant> maxb: What arch did you run the tests on?
[08:04] <wgrant> Because I have no idea where those other failures came from...
[08:07] <maxb> amd64
[08:08] <wgrant> Seems unlikely, but that's one difference.
[08:11] <maxb> I'd try again, but I'm in the middle of a py2.5 testrun
[08:11] <maxb> I need to make myself a separate lp-sourcedeps for 2.4 vs 2.5
[08:11] <wgrant> I need a separate sourcedeps for amd64 vs. i386 :(
[08:12] <wgrant> That's why all my instances are i386; my first one was.
[08:12] <maxb> I'm thinking symlink download-cache, bzr checkout --lightweight sourcecode/*
[08:13] <wgrant> Possibly.
[08:15]  * wgrant heads home.
[08:28] <adeuring> good morning
[09:18] <mrevell> Morning
[10:21] <wgrant> Now that Bugs people are around:
[10:22] <wgrant> The project owner has an implicit subscription to all of the project's bugs unless there is a bug supervisor set. The bug supervisor can unsubscribe from its subscription, but the owner cannot. Is this intentional? I wonder if it's a holdover from when bug supervisors couldn't unsubscribe either.
[10:22] <wgrant> This confused when I moved a project to Launchpad last week, and couldn't unsubscribe the team.
[10:33] <intellectronica> wgrant: i'm not sure i understand. what were you expecting to be able to do?
[10:35] <wgrant> intellectronica: The project owner always has an implicit subscription to a project's bugs if the project has no bug supervisor.
[10:35] <wgrant> intellectronica: This subscription is impossible to remove.
[10:36] <wgrant> It is the only one which is irremovable.
[10:36] <wgrant> This seems strange.
[10:37] <intellectronica> wgrant: well, it's not really a subscription. it's an "also notified"
[10:37] <intellectronica> the point is that _someone_ needs to be notified, and project owner or bug supervisor make sense
[10:37] <wgrant> intellectronica: It's a forced structural subscription.
[10:37] <wgrant> intellectronica: The bug supervisor can easily unsubscribe.
[10:37] <wgrant> As the bug supervisor is no longer implicitly notified; it just normally has a structural subscription.
[10:38] <wgrant> The project owner *is* implicitly notified, without a subscription.
[10:38] <wgrant> This is entirely unobvious.
[10:38] <wgrant> 'Subscribe to bugmail' is the obvious place to look, but doesn't help.
[10:38] <wgrant> So I checked the code, and indeed it is hardcoded.
[10:38] <wgrant> (lp.bugs.model.bug:620)
[10:44] <wgrant> intellectronica: So, it is quite easy to get into a condition where nobody gets email, but also quite hard for users to work out how to stop email.
[10:44] <wgrant> And other bugtrackers don't by default email anybody about all new bugs.
[10:44] <wgrant> So it wouldn't be entirely unthinkable to not have the owner notified by default.
[10:46] <intellectronica> don't know, maybe you're right and we don't have to have any subscribers by default. haven't though about this enough. i still think that it would be bad if a project had noone notified
[10:49] <wgrant> intellectronica: It sounds like a question that should be asked during the guided project creation.
[10:50] <wgrant> That can then create a structural subscription if the creator desires.
[10:51] <intellectronica> wgrant: i'm not sure it's worth asking, but it might make sense to simply create a structural subscription (which can then be removed)
[10:51] <intellectronica> there's one serious implication of having no subscriptions, though, and that's private bugs
[10:51] <wgrant> intellectronica: That does get slightly confusing when the ownership changes.
[10:51] <wgrant> intellectronica: Private bugs do not care about indirect subscriptions, do they?
[10:51] <wgrant> Don't they just subscribe either the security contact or the bug supervisor?
[10:51] <wgrant> Or owner if either doesn't exist?
[10:52] <intellectronica> they do, in the sense that indirect subscriptions are converted to direct ones when a bug becomes private
[10:52] <wgrant> Right.
[10:52] <wgrant> But I'm not sure why that's of concern.
[10:52] <wgrant> Or do you mean that you'd expect the project team to be able to see them always?
[10:53] <wgrant> I think bug privacy implications need to be much more obvious, which would alleviate this.
[10:53] <intellectronica> because you can end up with orphan bugs. bugs which nobody will be able to see. this is risky in particular with security-related bugs
[10:53] <intellectronica> i agree
[10:53] <wgrant> Bugs that are filed as security bugs will always have somebody subscribed, though.
[10:54] <wgrant> And maybe marking a bug as private should warn if only you'll be able to see it.
[10:54] <wgrant> But if a structural subscription is created initially, the projects with nobody subscribed should be minimal. In my case the interested developers subscribed separately.
[10:54] <wgrant> But there are managerish people in the team, and they probably didn't want notifications.
[13:25] <mrevell> jtv: What do you reckon we should call these "policies"? Review policies?
[13:26] <jtv> mrevell: access or permissions policies
[13:26] <mrevell> jtv: Okay, let's stick with permissions policies as that's what we've had pretty much all along.
[13:27] <jtv> mrevell: cool
[13:27] <beuno> g'mornin
[13:28] <jtv> beuno: buenos
[13:30] <beuno> jtv, que tal?
[13:30] <jtv> beuno: bien, bien... ¿tu?
[13:31] <jtv> oh, I can do better: tú
[13:32] <jtv> danilos: cp requests are both there now... what else have I forgotten?  :)
[13:32] <beuno> jtv, "vos"
[13:32] <jtv> beuno: ahhh, you funny folks  :)
[13:32] <beuno> :)
[13:33] <jtv> The two countries whose Spanish is _really_ weird and different: Argentina and Spain
[13:34] <beuno> we like being unique
[13:36] <salgado> hey beuno!  any news about those breadcrumbs?  I'd like to see some more examples to make sure the new infrastructure can cope with them
[13:37] <beuno> salgado, I will write them *now*
[13:40] <salgado> beuno, great, thanks!
[14:08] <beuno> salgado, Im putting examples for:  a bug, a branch, a merge proposal, a package, a bug in a package and a blueprint. Need anymore?
[14:12] <salgado> beuno, how about https://translations.edge.launchpad.net/ubuntu/jaunty/+source/gfxboot-theme-ubuntu/+pots/bootloader/af/+translate ?
[14:13] <beuno> salgado, will add that as well
[14:13] <beuno> working on the wiki page
[14:13] <beuno> gimmi a few more minutes
[14:13] <salgado> sure thing!
[14:19] <BjornT> sinzui: ping?
[14:19] <sinzui> Hi BjornT
[14:19]  * gmb => caffeine. BBIAB.
[14:19] <BjornT> sinzui: hi. i'm looking at c.l.javascript/registry/milestoneoverlay.js
[14:19]  * sinzui saw the bug
[14:20] <BjornT> sinzui: when you show an error message in the overlay, why don't you use overlay.showError()?
[14:20] <sinzui> BjornT: It did not exist when the widget was created
[14:21] <BjornT> sinzui: ok. so it's ok if i change it to use showError()?
[14:21] <sinzui> BjornT: I think rockstar added the feature after looking at competing implementations. I talked to him about it
[14:21] <sinzui> BjornT: +1 to fix the widget. If you do not have time, I think we will get to it before 3.0
[14:22] <BjornT> sinzui: cool. i'll do it, since i want to update it to use a new method i wrote, and the custom error handling got in the way.
[14:31] <beuno> salgado, that was a tricky one
[14:31] <beuno> salgado, danilos, https://wiki.canonical.com/Launchpad/UI/Navigation
[14:32] <beuno> I did something weird there
[14:32] <beuno> Ubuntu > Jaunty 9.04 > Afrikaans translations > gfxboot-theme-ubuntu > Translating bootloader
[14:32] <beuno> instead of:
[14:32] <beuno> Ubuntu > Jaunty 9.04 > gfxboot-theme-ubuntu > Afrikaans translations > Translating bootloader
[14:33] <beuno> it was an arbitrary decision, to fix a long-standing bug for translators who can't get back to their language to translate more templates
[14:34] <beuno> I will continue adding the remaning examples, but let me know what you think
[14:34] <danilos> beuno: right, it's something we discussed before, and what we want to fix anyway
[14:35] <danilos> beuno: we need that on product translations as well
[14:35] <beuno> danilos, yeah, and the links don't make sense in the second option, even though the hierarchy may
[14:35] <beuno> I'm not 100% sure this isn't too crazy, but I'm 65% sure
[14:35] <danilos> beuno: yeah, we can easily move the links around as well
[14:36] <beuno> danilos, will do one for product translations. Do you have a link handy?
[14:36] <danilos> beuno: https://translations.launchpad.dev/evolution/trunk/+pots/evolution-2.2/es/+translate (I think, I made half of it up :))
[14:36] <danilos> beuno: or, if you want something on edge...
[14:37] <beuno> danilos, yes  :)
[14:37] <danilos> beuno: https://translations.edge.launchpad.net/tangocms/trunk/+lang/es and any link from there
[14:38] <beuno> danilos, thanks
[15:10] <danilos> kfogel: flacoste is in a crapper :)
[15:13] <matsubara> stub, herb, flacoste, rockstar, bigjools, henninge, sinzui, intellectronica: LP production meeting in 47 min in #launchpad-meeting
[15:13] <intellectronica> thanks for the reminder, matsubara
[15:13] <herb> matsubara: thanks
[15:19] <salgado> sinzui, one of the tests failed because I forgot to re-add the link to '+branding' that was removed from the actions menu. should I leave it in the nav menu for now?
[15:21] <sinzui> salgado: Can you add the link to details page.
[15:22] <sinzui> salgado: change details page.
[15:22] <sinzui> salgado: EdwinGrubbs: Beuno provided a good plan to allow us to move branding links into the page, so we only need to provide the link from the change details page for now.
[15:23] <salgado> sinzui, at the bottom of the +edit page, using the related pages thing? or something else?
[15:25] <sinzui> salgado: That is the immediate kind of fix (and we can hack the h2 and ul into template, no menu) , the other route is add a sentence that includes the link in extra-form slot
[15:28] <salgado> sinzui, +edit has been converted to 3.0 in this branch of mine, and it already has a <tal:menu replace="structure view/@@+related-pages" />
[15:28] <salgado> so, if there isn't anything preventing me from defining a menu to be used there, I think I'll just do it
[15:29] <sinzui> +1
[15:49] <beuno> kfogel, http://googletesting.blogspot.com/2009/07/call-for-attendance-google-test.html
[15:54] <salgado> sinzui, https://pastebin.canonical.com/21116/ fixes most of the tests that failed.  only 2 more to go
[15:56] <sinzui> salgado: +1
[15:57] <sinzui> salgado: if the product-menu test failed, make sure you have the latest version...the lastest version is not bittle
[15:57] <salgado> sinzui, I've removed portlet-milestones from project-index.pt, so now there's a test failing because there's no 'See all milestones' link in that page
[15:58] <sinzui> We should add the link I think. I do not think there is any other way to get to that page.
[15:59] <salgado> sinzui, any suggestions for where to put the link?  I don't see any obvious place for it in the current layout
[16:01] <sinzui> At the bottom of projects portlet, where we list milestones
[16:02] <beuno> sinzui, could you comment on bug 412971?
[16:02] <mup> Bug #412971: Convert bug-edit.pt to 3.0 template <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/412971>
[16:03] <deryck> beuno, sinzui -- I'm adding notes/questions/etc. to that bug right now with questions I have so far.
[16:04] <beuno> deryck, I commented
[16:04] <beuno> thought I did
[16:04] <beuno> but something... odd happened
[16:05] <beuno> or even better, "can we make it an open team"
[16:07] <deryck> beuno, ah the "no portlets" rule will solve half of my questions then :)
[16:07] <deryck> beuno, I should have refreshed first :)
[16:07] <beuno> deryck, perfect  :)
[16:07] <deryck> beuno, some questions are still relevant though
[16:07] <beuno> deryck, will look and answer
[16:15] <beuno> salgado, finished with the breadcrumb detailing: https://wiki.canonical.com/Launchpad/UI/Navigation
[16:15] <beuno> (I will move that to the public wiki soon)
[16:23] <EdwinGrubbs> sinzui: the base-layout.pt moved the informational messages just above the maincontent div. Is there any reason it can't be moved back in? I have one test that fails, and I assume there will be others that we'll have to fix, because we usually use find_main_content() instead of importing BeautifulSoup directly.
[16:24] <sinzui> EdwinGrubbs: I think I can move back. I did not intend to move it
[16:24] <EdwinGrubbs> ok
[16:48] <gary_poster> matsubara-afk: lemme know when you can give me some background for the librarian-gc failure.  no rush, just trying not to forget my part ;-)
[16:50] <sinzui> salgado: I would like your thoughts about how to proceed from this: https://pastebin.canonical.com/21124/
[16:58] <bigjools> sinzui: woohoo that did the trick thanks
[16:58] <bigjools> I don't get rounded corners on the boxes, is that intentional now or am I missing some css?
[16:59] <salgado> sinzui, sorry, was on the phone; looking now
[17:00] <sinzui> bigjools: is your css uptodate? There was a typo in the css where the *border-radius properties uses % instead of px.
[17:01] <bigjools> sinzui: I think so, the project page has rounded corners in .dev for me
[17:01] <sinzui> bigjools: they should appear in the side for all .side .portlet classes
[17:02] <sinzui> bigjools: then I wonder if some divs are missing class="portlet"
[17:02] <bigjools> not that I can see
[17:02] <bigjools> the yui-u is the outer div and the portlet is the inner div right?
[17:05] <barry> sinzui: so ~person index should be a main_only, right?
[17:06] <sinzui> barry: no way an objects index will be main_side in most cases. see the design that was sent out months ago
[17:07] <barry> right, so main_only is the right thing to use
[17:08] <sinzui> barry: no, main_side because it is a primary object's index page https://devpad.canonical.com/~curtis/LP_userdetail.png is not ready. I want it
[17:09] <sinzui> barry: do not work on this. I want the team page to land first. It has layout changes that the user page should use.
[17:09] <barry> yep, i know
[17:10] <barry> i'm trying to get some basic grounding here.  okay, so ~person does have side actions
[17:14] <bigjools> sinzui: I see the problem.  I was using Konqueror, it doesn't round the edges.
[17:15] <sinzui> bigjools: It should...there is something missing from the style. Which version are you using...the latest uses webkit and we cover that case
[17:15] <bigjools> sinzui: I am using the very latest in kde4.3
[17:17] <sinzui>     -webkit-border-radius: 5px;
[17:18] <bigjools> I see it
[17:18] <salgado> sinzui, have you considered a new interface for objects that provide a registrant/registration-date, plus changing existing classes to provide that interface? I think that'd be the best way forward as it'd also get us on the right path for standardizing the names we use for this
[17:19] <sinzui> salgado: So add properties or fix models to support this?
[17:20] <salgado> sinzui, I'd add aliases to the existing properties and mark the existing ones as deprecated
[17:21] <intellectronica> EdwinGrubbs: around?
[17:21] <sinzui> salgado: okay. I will take that approach
[17:21] <EdwinGrubbs> intellectronica: hi
[17:56] <mrevell> catch you tomorrow guys
[18:19] <sinzui> deryck[lunch]: I replied to the bug, sorry for the delay
[18:20] <sinzui> deryck[lunch]: I can get you a diff of another edit page that was modified to show all the changes you might make to convert a modification page to ui 3.0
[18:31] <sinzui> deryck[lunch]: I added an example diff of a full conversion of a modification page: https://dev.launchpad.net/VersionThreeDotO/UI/Conversion
[19:05] <deryck> sinzui, thanks for all that.  *very* helpful work.
[19:56] <gary_poster> abentley, rockstar, on #launchpad someone is having problems pulling.  They say it is neverending and then they get
[19:56] <gary_poster> bzr: ERROR: http://bazaar.launchpad.net/%7Eturl/%2Bjunk/ircbot/.bzr/repository/packs/dd8ac238ab24bfcbbb8620946cf7d032.pack is redirected to https://launchpad.net
[19:56] <gary_poster> do one of you have time to check that out?
[19:57] <rockstar> gary_poster, abentley is on holiday this week. I'll figure chat with them.
[19:57] <gary_poster> rockstar: ok thanks much
[20:25] <deryck> sinzui, ping.
[20:25] <sinzui> hi deryck
[20:26] <deryck> sinzui, hi! With generic-edit.pt, there's no way to get messages/notifications back to the template, right?
[20:26] <sinzui> deryck: those are supplied by base-layout.
[20:27] <sinzui> deryck: EdwinGrubbs discovers a bug this morning. the notifications are in the wrong place
[20:27] <sinzui> deryck: EdwinGrubbs may have a fix ready
[20:27] <EdwinGrubbs> deryck: yes, I changed it in my branch, which I will put into review today.
[20:28] <deryck> sinzui, ah, ok.  So it should work soon if I continue to use generic-edit.pt?  I have broken tests that test for confirmation messages is why I ask.
[20:28] <deryck> EdwinGrubbs, awesome!  Good news then :)
[20:43] <intellectronica> bigjools: bear in mind my branch is going to spend quite some time in pqm, it's lazr so it gets a full run. if you rather have it killed so that your testfix gets in quickly it's fine by me
[20:43] <intellectronica> let me know if you do so that i can resubmit
[20:44] <bigjools> intellectronica: ah bugger, might be a good idea to do that
[20:44] <bigjools> or trunk will sit broken
[20:44] <intellectronica> yeah
[20:44] <bigjools> mthaddon: would you mind doing the honours please? ^
[20:46] <mthaddon> bigjools: stop pqm, remove intellectronica's branch?
[20:46] <bigjools> mthaddon: yeah please, so mine gets in quicker
[20:46] <bigjools> and then tom can resubmit
[20:48] <mthaddon> intellectronica: ok, feel free to resubmit
[20:48] <intellectronica> mthaddon: cheers
[20:48] <mthaddon> yah
[20:51] <rockstar> How do I enable the storm tracer for make run?
[20:53] <rockstar> EdwinGrubbs, ^^ Maybe you know?
[20:57] <thumper> rockstar: skype
[20:57] <rockstar> thumper, hi.
[21:01] <bigjools> thanks for pointing that one out intellectronica
[21:02] <intellectronica> np
[21:35] <sinzui> beuno: is there a reason we do not want to show distribution custom icons in links?
[21:36] <beuno> sinzui, none at all
[21:36] <beuno> it's a bug
[21:36] <sinzui> beuno: I seem to have fixed it. It was an accident.
[21:38] <beuno> sinzui, thank you
[21:53] <maxb> ajax bug commenting is entirely shiny :-)
[22:00] <EdwinGrubbs> rockstar: do you still need info on the storm tracer?
[22:00] <EdwinGrubbs> sinzui: is there a bug open already for the team edit pages?
[22:00] <sinzui> No
[22:01] <sinzui> EdwinGrubbs: maybe
[22:01]  * sinzui looks at EdwinGrubbs assigned bugs
[22:02] <EdwinGrubbs> huh, how did I miss that?
[22:02] <sinzui> EdwinGrubbs: You have two bugs. One for the index and one for the edit pages
[22:02] <rockstar> EdwinGrubbs, I think we're okay now, thanks.
[22:04] <maxb> uhoh. ajax bug commenting is shiny, but not when it fails to actually save your comment despite looking as if it did!
[22:05] <maxb> oh
[22:05] <maxb> no, it did save, but there was a quirky browser caching issue
[22:07] <beuno> sinzui, https://staging.launchpad.net/bzr
[22:10] <sinzui> Those file names are going to be difficult. What part can we hide? Maybe we need a smaller font
[22:12] <sinzui> beuno: I think we need a santise the packages portlet. Show the the latest pacckage, or limit it to 3
[22:12] <beuno> sinzui, exactly
[22:12] <beuno> I think the length is not a problem, but the large amounts of them is
[22:13] <EdwinGrubbs> sinzui: mp sent
[22:13] <sinzui> beuno: the file names are a font-size larger than the body text
[22:13] <sinzui> EdwinGrubbs: thanks!
[22:13] <beuno> sinzui, ah, indeed they are
[22:16] <Fly-Man-> Evening all
[22:16] <Fly-Man-> I have succesfully installed the LaunchPad on a local server
[22:17] <Fly-Man-> and made some Wiki changes on how to get it running so you can work it on a internal network
[22:17] <Fly-Man-> but I have a Q about the source importer
[22:17] <Fly-Man-> does it work in the development branch /
[22:17] <maxb> I'm fairly sure that's illegal unless you rebrand it
[22:18] <maxb> I wish it wasn't though, I'd quite like to use Malone myself
[22:18] <Fly-Man-> okay, so the code importer doesn't work in the development branch ?
[22:18] <maxb> I have no idea
[22:18] <Fly-Man-> because waiting for 1 hour now and I see no change on the pages
[22:19] <Fly-Man-> maxb: https://dev.launchpad.net/Running/LocalNetwork
[22:19] <Fly-Man-> For getting it to run on a local network
[22:19] <maxb> I'd imagine it probably needs to be kicked off from a cronjob
[22:21] <maxb> Whilst it's nice that Canonical have open-sourced LP at all, it seems that they've diligently avoided distributing a configuration capable of running a local instance for production purposes.
[22:21] <Fly-Man-> Hmm, but so far it's working like a charm
[22:21] <Fly-Man-> yeah, and still need to find out how i can delete the "test" stuff and projects
[22:22] <Fly-Man-> so I can have a clean tree
[22:38] <maxb> Fly-Man-: What do you mean by code importer, ooi?
[22:38] <Fly-Man-> maxb: the part where I put in a SVN url
[22:38] <Fly-Man-> and it starts to grab that SVN
[22:38] <Fly-Man-> and downloads the SVN history into the trunk on the Launchpad
[22:38] <Fly-Man-> so I can fiddle with it
[22:39] <Fly-Man-> and checkout the source with bzr
[22:39] <Fly-Man-> Like it tells on this page:
[22:39] <Fly-Man-> https://help.launchpad.net/VcsImports
[22:40] <maxb> It probably has something to do with cronscripts/code-import-dispatcher.py
[22:41] <Fly-Man-> And also what I notices
[22:41] <Fly-Man-> the version of the trunk build is still 2.2.6
[22:42] <maxb> huh, still? I though wgrant landed a branch to fix that
[22:42] <Fly-Man-> I see this:
[22:42] <Fly-Man->  Launchpad 2.2.6 (r9108)  devmode
[22:42] <Fly-Man-> I grabbed the source 4 hours ago
[22:43] <maxb> hmm, wonder what happened to that branch
[22:43] <Fly-Man-> no clue ...
[22:44] <thumper> Fly-Man-: yes the importer stuff works
[22:44] <Fly-Man-> thumper: is there any page on the Wiki about it ?
[22:44] <Fly-Man-> how to setup ?
[22:44] <thumper> no
[22:45] <thumper> and right now I'm firefighting
[22:45]  * Fly-Man- throws a fire blanket to thumper 
[22:53] <Fly-Man-> thumper: hope it's not your pc that's on fire ....
[22:53] <thumper> flacoste: no, production issues
[22:54] <Fly-Man-> okay ...
[22:54] <thumper> flacoste: sorry, tab completion fail
[22:55] <Fly-Man-> well, i'll have some sleep
[22:55] <Fly-Man-> and maybe tomorrow when it's not fire time we can have a talk ?
[22:56] <thumper> it is friday for me today :)
[22:56] <Fly-Man-> thumper: it's almost friday for me here
[23:03]  * Fly-Man- yawns
[23:03] <Fly-Man-> K, time for me to get some sleep
[23:03] <Fly-Man-> Nite all :)
[23:04] <Fly-Man-> and thanks for the help so far
[23:13] <wgrant> maxb: Mine was r9109
[23:13] <wgrant> Landed 12:41 UTC
[23:13] <maxb> not that branch, different branch - what happened to your "fix the version numbers to say 2.2.7" branch?
[23:14] <wgrant> Oh.
[23:14] <wgrant> I didn't have a branch to fix that.
[23:15] <maxb> ah. someone did. I must be misremembering
[23:16] <wgrant> I tried to run the test suite in Karmic 2.4 last night, but my LVM snapshot filled up :(
[23:26] <intellectronica> wow, something very strange is happening. i've submitted a lazr.restful branch to pqm and pqm spat it back claiming there are merge conflicts. but there are no revisions in trunk that are not present in my branch!
[23:27] <thumper> intellectronica: crisscross merges?
[23:28] <intellectronica> thumper: no no, my branch is exactly one revision on top of what's already in trunk. should be a very straightforward merge
[23:28] <thumper> intellectronica: are you sure you are submitting to the correct branch?
[23:29] <intellectronica> yeah, i'm wondering that too. i'm submitting to ~launchpad-pqm/lazr.restful/trunk
[23:30] <intellectronica> which is the branch i branched from, so it is, actually, the correct branch
[23:30] <wgrant> intellectronica: That's not really trunk.
[23:30] <intellectronica> wgrant: oh?
[23:30] <wgrant> Recent commits have been to ~lazr-developers/lazr.restful/trunk
[23:31] <wgrant> Not via PQM either, AFAICT.
[23:31] <intellectronica> which doesn't conflict with my branch either
[23:32] <intellectronica> i find it very hard to believe that whatever we're using in lp accept merges not through PQM
[23:32] <intellectronica> maybe it's a parallel branch or something
[23:33] <intellectronica> you're right, though, that this is the branch currently registered as trunk
[23:36] <intellectronica> leonardr: any idea what's going on? ^^^^^
[23:38] <intellectronica> trying to submit to that branch fails too, which sort of makes sense, because it isn't owned by pqm
[23:39] <intellectronica> ha ha, ok, i get it
[23:40] <intellectronica> wgrant: thanks, your clue helped
[23:40] <intellectronica> so my branch doesn't conflict with the branch i thought is the one i'm submitting too, which is the lazr-developers branch, but it conflicts all over the place with the branch managed by pqm
[23:40] <wgrant> intellectronica: Excelent.
[23:41] <wgrant> Ah.
[23:41] <wgrant> Makes sense.
[23:41] <wgrant> Apart from why the branch isn't PQMed.
[23:41] <intellectronica> yeah, that's very strange, i don't remember any mention of that change
[23:42] <wgrant> I've seen a couple of mentions of moving to a non-PQMed trunk in lazr.restful merge proposals as they fly past.
[23:43] <maxb> What's the bin/test incantation to run a single doctest?
[23:44] <wgrant> bin/test -vvt testname.txt
[23:44] <wgrant> That's what I use.
[23:44] <wgrant> You can also give the full path.
[23:51] <maxb> wgrant: many thanks for sorting gina.txt. Unfortunately package-diff.txt is still broken.
[23:52] <maxb> http://paste.ubuntu.com/252805/
[23:53] <wgrant> maxb: Huh.
[23:53] <wgrant> My Karmic LP chroot is currently rebuilding, so I'll look in a moment.
[23:53] <wgrant> But that's nothing like the failures I had yesterday.
[23:58]  * maxb rants furiously at shhh.py