[00:03] poolie: correction, no lp committers have commented on it [00:03] I've looked at it and determined that I'm not qualified [00:03] I'll poke jml and mwhudson :) [00:03] haha [00:03] ok, thanks :) [00:04] so, if its conditional. [00:04] lets land it. [00:04] and iterate. [00:04] lifeless: you review it then [00:04] rs=lifeless [00:04] done [00:04] poolie: is it proposed into the right branch? [00:04] 4907 + [00:04] doesn't seem like something i'd expect to see [00:05] lifeless: i think it is worth fixing the issues andrew raised [00:05] poolie: right [00:05] but none of them seem profound so i wanted to pipeline other reviews [00:05] I knew that the code had been reviewed. [00:05] and andrew is an emeritus lp reviewer. [00:05] so he can vote it through. [00:05] mwhudson: i suspect it is a mix of db-devel and devel, so it may not be possible to land until they merge [00:06] which may now have happeende [00:06] jam will also need someone to sponsor this and to help him shake it out on staging [00:06] or it is landed on db-devel [00:06] * thumper is off next week [00:09] thumper: you mean it could land on db-devel instead? [00:09] yes [00:13] poolie: it definitely can't land on devel until the next release [00:13] well, unless there's some history rewriting [00:13] meaning 2 weeks from now? [00:14] i think it's a bit more than that [00:14] but if it landed on db-devel, it would be available for testing on staging? [00:14] yes [00:18] poolie: the branch has conflicts with db-devel it seems [00:18] jam: can you merge db-devel, fix the conflicts and repropose it against db-devel? [00:25] i don't think he's here at the moment but i put that on the mp [00:26] thanks [00:29] I think getting a new mp against db-devel would help [00:30] as it would avoid all the extra crap [00:30] we should allow target editing [00:30] (but don't yet) [00:30] and a way to regenerate the diff [00:30] yet more on the mp todo list [00:54] hi, I'd like to develop new features for rosetta (launchpad translations), but there are quite a lot of branches. Which one should I use as a base? [01:00] https://dev.launchpad.net/Trunk will help you understand how the various branches relate [01:00] Or, in short, base of lp:launchpad/devel [01:06] maxb: nice, thank you [01:07] thumper: yo [01:13] wallyworld: hi [01:14] skype? [01:15] ok [01:21] thumper: i agree changing the target wbn [01:28] mars: Um, good luck with getting dpkg to downgrade packages. [01:28] Downgrades aren't actually supported. [01:29] ? [01:29] s/dpkg/apt/ [01:29] meaning the packages aren't required to cope with it? [01:29] packaging 101 question: is there a script to make a tar.gz from an egg for adding to download-cache? [01:30] poolie: Correct. [01:31] apt will try very hard to avoid it. [01:39] * thumper feels like crying [01:39] why is this so fucking hard [01:39] * thumper is upset bzr doesn't allow me to push without stacking [01:40] thumper: init the branch, turn off stacking, then push [01:40] I can't init the branch [01:40] the branch is trunk [01:40] ? [01:40] I'm trying to fix up the remaining 9 maverick branches that are stacked on lucid [01:40] it already exists on lp and is stacked? [01:40] where reconfigure --unstacked breaks [01:41] poolie: yes [01:41] I have local full copies of the branches on devpad [01:41] and I was trying to move the existing .bzr to backup.bzr using hitchhiker [01:41] and repush the full unstacked branch [01:41] but I can't [01:41] two problems stop it [01:42] there is a bug in LP where the trunk is offered to stack when pushing trunk [01:42] (in the weird edge case where you do that) [01:42] and that bzr can't avoid stacking at creation time [01:44] you'd think it wouldn't be that hard [01:45] thumper: --stacked-on= doesn't help? [01:45] wgrant: is that valid? [01:45] thumper: I think so. [01:45] It used to be. [01:45] * thumper pokes something [01:46] $ bzr push lp:~thumper/wikkid/test --stacked-on= [01:46] Created new stacked branch referring to file:///home/tim/sandbox/wikkid-sandbox. [01:46] .... great. [01:46] Well, you could start pushing, kill it before it finishes, then push again. [01:46] That should result in it being unstacked. [01:47] I'm tempted to just use hitchhiker to copy the .bzr dir from the devpad copy [01:48] that may work [01:48] :/ [01:48] poolie: lynne is back, but I'm feeling shitty - going to find a local gp and pop in. [01:48] once I get through to a human @ vodafone [01:48] np [01:48] although I'd have to do something about the checkout dir [01:49] there is a medical centre under the forum, on the side nearest the urban; good luck [01:49] 6 minutes on hold so far [01:49] poolie: can you think of a better idea? [01:50] i'm trying to understand what you're trying to do [01:50] poolie: ok... here goes [01:51] https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick is stacked on https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/libsoup2.4/lucid [01:51] it shouldn't be [01:51] the lucid branch should be stacked on maverick [01:51] I'm trying to fix that [01:51] or [01:51] more correctly [01:51] I'm trying to unstack the maverick branch [01:51] I don't care about lucid not being stacked [01:51] however [01:51] ok, and just reconfiguring it fails how? [01:52] reconfigure --unstacked breaks [01:52] with an error similar to what I pastebinned yesterday [01:52] http://pastebin.ubuntu.com/502991/ [01:52] well, this is for lp:ubuntu/language-pack-gnome-tg [01:52] but it is also one of the 9 that fail [01:53] ok and you have new proper copies of the branches elsewhere [01:53] 312 of the 321 incorrectly stacked branches got unstacked correctly using reconfigure --unstacked [01:53] yes, on devpad [01:54] hm [01:55] is it an option to just overwrite it using sftp+? [01:56] what do you mean? [01:57] well, first, let me try to work out if that revision is meant to be in either of those brancehs [01:58] thumper: Why can't you just mv .bzr backup.bzr.~1~ in hitchhiker, then bzr init lp:foo; bzr reconfigure --unstacked lp:foo; bzr push lp:foo ? [01:58] maxb: because bzr init lp:foo errors [01:58] ! [01:58] yeah [01:58] thumper: because it tells it to stack on itself? [01:59] can you pastebin that error? [01:59] the error is worse now :( [02:00] uh, still? [02:00] bzr: ERROR: Server sent an unexpected error: ('error', ' cannot have linked branches.">') [02:00] ! [02:01] that's not my fault :) [02:01] I was going to look at those after I had fixed these branches [02:01] hm so what do you want? [02:01] i can make a patch to disable stacking on random things [02:01] or we can manually edit that repo [02:01] or we can investigate why it won't unstack [02:03] poolie: is it possible to have a hacky plugin to allow me to push without stacking? [02:03] poolie: that might be easiest [02:04] sure [02:04] poolie: then I could move the .bzr to backup.bzr with hitchhiker [02:04] poolie: and push the full copy in [02:04] i'm just wondering if you're going to hit the same zope error? [02:04] that zope error is due to it looking for the branch to stack on [02:04] I can use the full url to hitchhiker in still [02:05] so all we need is to be able to push an unstacked branch [02:05] then we can look into the unstacking failure [02:05] et al [02:05] I need to fix those error messages [02:05] but I'm not sure that'll get done in time [02:05] i.e. by EOD as I'm off next week [02:05] I might get abentley to look into it next week [02:06] I'm guessing it isn't actually that hard [02:06] just catching the error in the right place [02:06] and returning it correctly though the smart server [02:15] * thumper looks for food [02:16] thumper, i'll see what i can do about it [02:16] i don't think i'll have access to write to those branches but that can probably be fixed [02:35] poolie: if you can get me the hacky plugin, I can put it on devpad and push the branches [02:35] poolie: you can always test it locally [02:35] k [02:39] just testing it [03:09] Did anyone make any headway on the CSCVS NoWhoami problem yesterday? [03:10] * maxb is collating a list of failed imports [03:10] maxb: not that I know of [03:11] maxb: is there a bug filed? [03:11] we need a losa to look at the importds i think [03:12] mwhudson: do you think that is better than hacking CSCVS? [03:13] thumper: maybe not [03:13] thumper: ok, lp:~mbp/bzr/stacking adds a -Ddisable_stacked_on_url debug flag [03:13] which should do what you need [03:13] you can set that for pushing, etc [03:13] i don't understand why it changed though :/ [03:15] poolie: can I just check that out on devpad and use the bzr in it directly? [03:15] poolie: do I have to compile anything? [03:16] $ bzr branch lp:~mbp/bzr/stacking mbp-bzr [03:16] bzr: ERROR: The branch lp:~mbp/bzr/stacking has no revision None. [03:16] ? [03:17] ah, heh [03:17] i'm using it to push itself, so it's taking a bit longer than usual :) [03:17] i'll push it to devpad in a shared repo [03:17] hang on [03:23] thumper: that branch is there for you now [03:23] poolie: on lp? [03:24] yup [03:27] poolie: do I have to "make" anything [03:27] ? [03:47] poolie: doesn't quite work: $ ~/mbp-bzr/bzr push -Ddisable_stacked_on_url --use-existing lp:~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick [03:47] Using default stacking branch /~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick at lp-64804368:///~ubuntu-branches/ubuntu/maverick/libsoup2.4 [03:47] bzr: ERROR: The branch 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick/' cannot be stacked on '/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick'. [04:13] thumper: sorry, back now, no, you shouldn't need to build anythnig [04:14] can you paste the traceback please? [04:15] there was no traceback [04:15] not even in .bzr.log? [04:16] * thumper looks [04:17] poolie: devpad:/home/tim/.bzr.log [04:17] mwhudson: ping [04:19] sorry thumper, that's -Ddisable_set_stacked_on_url [04:19] :/ [04:19] my mistake [04:19] * thumper sighs [04:19] obviously it's too long [04:20] what about -Ddisable_stacking [04:20] thumper: hi [04:20] mwhudson: got a few minutes for a pre-impl? [04:20] that would've been smarter [04:20] mwhudson: translatePath errors [04:20] thumper: ok [04:21] mwhudson: thanks [04:22] hmm [04:22] thumper: can you hear me? [04:22] mwhudson: no all I could here was me [04:22] bah [04:23] thumper: i'm trying to work out if i should file a follow-on bug to fix this properly [04:24] oh ffs [04:24] perhaps it is that we want a configuration option to say whether bzr should trust server-suggested stacking? [04:24] poolie: it would be great to have a client side way of saying "ignore stacking" [04:31] thumper: i guess it's bug 368913 [04:31] <_mup_> Bug #368913: bzr tries to stack on a new branch with stacking policy pointing at . [04:31] and bug 391405 [04:31] <_mup_> Bug #391405: want an option to force stacking or not when creating a branch [04:38] thumper: sorry for the lag, is it ok now? [04:41] poolie: looks like that works [04:41] 8 left to fix [04:55] it's hard to get used to having so much code in .txt files [05:09] how do i run just a single doctest? [05:09] i mean, a single file? [05:11] bin/test -t blahblah.txt [05:11] Don't try to give the full path -- it's often not what you expect. [05:14] ah, so bugs-emailinterface as a workaround for something appears under lib.canonical.launchpad.ftests [05:15] not the module that actually contains it [05:17] It varies. [05:18] poolie: Everything in canonical.launchpad shouldn't be there (but where to put it? Its still unclear often where under lp. things should go) [05:23] stub: well, in this case the actual file is in lp.bugs.tests [05:23] which is not a bad place for it imo [05:24] something to do with bug 305856 [05:24] <_mup_> Bug #305856: Spurious/intermittent test failure in answers/doc/emailinterface.txt

[05:24] right. but people are encouraged to put new stuff in the 'correct' place rather than in canonical. which might explain the disconnect [06:45] wallyworld: normally page tests test no-js functionality [06:45] wallyworld: and the windmill ones test js functionality [06:46] wallyworld: interactively I use a firefox plugin to disable js [06:46] thumper: in that case, everything should be sweet, no? [06:46] wallyworld: have you checked that the existing test coverage covers the case you care about? [06:46] yes, xx-branchmergeproposals.txt [06:47] wallyworld: have you made the fix? [06:47] that doc test basically creates merge proposals etc and checks the results [06:47] i added to it as well as part of the increased test coverage for the new stuff in the branch [06:48] wallyworld: you are good to go now [06:48] * thumper EOWs [06:49] thumper: thanks. enjoy your week off :-) === almaisan-away is now known as al-maisan [07:32] Morning [07:32] Morning noodles775. [07:59] ok [07:59] trying to fix my dkim/gpg failures now [08:07] omg these doctests with everything running together [08:35] w [08:40] good morning [09:01] stub: ttps://bugs.edge.launchpad.net/launchpad-foundations/+bug/640125 is linked to the branch in rev 11567, but it needs qa [09:01] <_mup_> Bug #640125: cron scripts should log everything, but only send mail for errors

[09:02] Yup. That might have got to staging now so can be tested when I've kicked off the 8.4 slave [09:03] What do we use python-tickcount for? [09:04] It seems odd that nobody else on the planet needs it. [09:04] stub: its causing https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt issues because (like me) you reuse branches [09:04] wgrant: lsprof didn't exist [09:05] morning all [09:05] Morning bigjools. [09:07] oh yay [09:07] lifeless: Can we use lsprof instead? [09:07] well we won't get ticks, but I'm not sure they are a great proxy [09:07] better to implement bug xxxx for per thread resource usage in oops. [09:08] (python-tickcount and ubuntu-keyring are the two packages that really tie us to Ubuntu) [09:09] Hey [09:12] Good morning [09:12] thumper, poolie: hi [09:13] thumper, poolie: I've honestly been meaning to check out jameinel's branch. Really. [09:19] np, it shouldn't be your job to review everything [09:19] though i guess this is a bit in your areao [09:23] gmb: can i trouble you for an incremental review on https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985 [10:15] noodles775: just looking at your comment ordering post... [10:16] noodles775: out of curiosity, is the code in that demo using lp.services.comments? [10:16] jml: yep. [10:16] noodles775: cool :) [10:18] noodles775: ping [10:19] jml: I had to modify lp.services.comments a bit, and I think lp.services.comments could be generalised a bit more too. [10:19] mrevell: yup? [10:19] noodles775: both make sense. [10:19] noodles775: as far as I know, lp.s.comments is an intent-to-generalize more than an actual proven generic solution. [10:20] noodles775: Hey, do you have time for a call today? I'd like to pick your brains on your screencast recording setup. [10:20] mrevell: sure, although it's just gtk-recordmydesktop. I can talk now, or after lunch, whatever works for you. [10:21] noodles775: Is in five minutes okay? [10:21] Sure, I'll be in the soyuz 1-1 on mumble? [10:21] Ta [10:46] afk for ~20 mins [11:07] now, to action [11:12] jml: where is your bzr plugin to show the XXXes? [11:13] lp:difftodo [11:13] jml: rock, thanks [11:13] it's not bundled as a regular plugin. am happy to help w/ install issues [11:13] * bigjools as adding copious more to the b-m code === al-maisan is now known as almaisan-away [11:18] jml: I checked it out in plugins/ and did "bzr todo" - how easier can it be? :) [11:19] bigjools: glad to hear it. it's just been ages since I've installed it or had a new user, so was expecting worse. [11:28] jml: this _deferred_list stuff is a nightmare :/ [11:28] bigjools: I've long thought so :) [11:29] jml: in particular the way it chains callables together in the recording slave with the *DispatchResult at the end [11:29] bigjools: you mean the way it hangs so much on exactly what kind of dispatch result you get? [11:30] jml: it's a consequence of the recording slave strategy. Because it doesn't know in advance what Deferreds will be fired or how many of them, it just keeps processing the recorded slave calls until it hits an instance of the BaseDispatchResult [11:31] ahh [11:31] which, when called,p does a Thing [11:31] bigjools: that makes a strange kind of sense [11:31] the Thing to do was decided ages ago [11:31] jml: yes, that's the annoying thing about it :) [11:32] bigjools: actually, I was going to ask you about the branch anyway... [11:32] jml: fire away [11:33] bigjools: I'd like to keep up-to-date with the changes. I'll probably have thoughts, questions etc. What's the most helpful way of sending those back to you? [11:33] bigjools: as I get them, or wait until you've reached some kind of checkpoint or... ? [11:33] jml: as you get them would be good - I'm committing a few times a day when I work on it, but that's not regular at all [11:33] bigjools: will do. [11:33] I'm trying to make the commit messages as useful to you as possible [11:34] stub: any idea about the 15 second update in the +delete bug? [11:34] ENOCONTEXT [11:34] bigjools: not promising I'll get any time. I just filled up an a4 page with "work things currently on the go" [11:34] ha [11:35] stub: https://bugs.edge.launchpad.net/launchpad-registry/+bug/652802 [11:35] <_mup_> Bug #652802: Person:+delete timeouts on teams [11:35] jml: BTW remember all those traps we added that just log messages? [11:35] bigjools: yeah. [11:35] jml: I've decided that we should remove them, because inside scan() it catches all errors anyway and does the failure counting. [11:36] if we can make all aspects of the job management get failure counted for free, that would be...win [11:36] bigjools: that makes sense... as long as the errors don't get lost. [11:36] jml: I can still log - just throw the failure again [11:37] bigjools: for me, the confusing part of the error handling is that some parts catch and throw away and others re-raise and others catch and then signal failure with some different mechanism [11:37] jml: you're not alone in confusion [11:37] bigjools: it would be nice if everything just damn well raised & let the bm take care of it all. [11:38] exceptions are great for errors [11:38] in exceptional cases [11:38] routine errors - no [11:41] you've argued this before, but not made a compelling case [11:44] lifeless: It is slow because it is trying to update 25k rows in a table of 60million [11:44] oh wow. [11:45] deceptive ;P [11:45] thanks for looking that up [11:46] real question is how come it managed that query in 15s. Took my test 46s :) [12:02] Morning, all. [12:07] night all [12:35] * bigjools drowns in build manager hideousness [12:37] That rabbitmq hang on shutdown is annoying. [12:38] deryck: yes [12:39] I've made a /etc/default/rabbitmq file that overrides the DAEMON variable in the startup script to /bin/true [12:39] I shall do that now. [12:40] death to persistent services only needed by LP.... [13:03] om nom nom [13:14] My /etc/default/rabbitmq says "exit 0" :-) [13:27] heh === matsubara-afk is now known as matsubara [13:31] our fake logger copes quite miserably when one of the strings it's trying to log has a % in it [13:31] which of our 3 fake loggers ? :-) [13:32] quite [13:40] bryceh: Can you triage bug 644794? It's one of yours :) [13:40] <_mup_> Bug #644794: Link BugTrackerComponents to distro/sourcepackages [13:43] bigjools: I thought we fixed that. [13:45] sinzui: hi [13:45] hi jml [13:45] sinzui: (foo,) is perfectly valid Python syntax, PEP 8 preferred and our historical coding standard. Why are we changing it? [13:46] because PEP8.py is complaining and I do not want to see the complaint [13:46] sinzui: fix pep8.py [13:47] maybe [13:49] sinzui: or stop using it. it's putting the cart before the horse to change the way we write code to match a bug in a third-party tool. [13:49] would you like to put pylint back [13:49] no. [13:49] but that's not the only other option open to us :) [14:01] sinzui: https://code.edge.launchpad.net/~jml/pocket-lint/singleton-tuples/+merge/37242 [14:02] allenap, many many thanks for helping triage bugs today. Sorry if I'm stepping on you, too. :-) Was trying to help catch them up today as well. [14:02] deryck: I haven't noticed actually. [14:03] ok, cool [14:07] sinzui: thanks for the review. how soon can we have the patched version on developer machines? [14:07] jml: we have, but this time it's in the string outside of the exc_info [14:07] deryck: is sladen filing bugs by email, or is the dupe checker substantially worse [14:07] bigjools: huh what? [14:08] jml: a traceback being passed in instead of using exc_info, basically [14:08] jml: soon is never an option with building PPAs. maybe Wednesday [14:08] sinzui: what needs to happen? [14:08] bigjools: sorry I think I missed some context. [14:09] bigjools: oh never mind [14:09] sinzui: there are plenty of buildd-admins around who can rescore builds, I'm one of them ;) [14:09] I push the new source package then we wait for its turn to be built [14:09] * sinzui has never consider cheating [14:09] sinzui: I have a graph that shows the queue empties regularly [14:09] wel not on this subject anyway [14:10] jml, the last pocket-lint build for Jelmer took about a weeks to do all the hops [14:10] sinzui: anyway the queue is small [14:11] sinzui: well, let me know when you've pushed the build. I guess it has to go into the launchpad developer PPA? [14:11] jml, okay [14:11] jml, we just vopy it [14:11] copy [14:12] sinzui: nice. [14:24] deryck: Can you triage bug 651128? I can't really judge how important it is. [14:24] <_mup_> Bug #651128: Email bug submission fails due to erroneous bad signature detection