[00:38] hi flacoste, all [00:40] [A3 === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 267 [00:49] jelmer_: Around? [00:50] jelmer_: Any reason not to revert your bad codeimport stacking branch? [00:50] wgrant: it's a trivial fix [00:50] also, hi :) [00:51] Ah, your presence is unexpected. Hi. [00:51] That's good. [00:51] If you can land it before the weekend, I guess it can stay. [01:05] poolie: i just claimed your mp before i saw aaron's comments. are you working on making changes? [01:05] i think my cover letter was just really confusing :/ [01:05] so i haven't made any code changes but i have explained it better and generated the right diff [01:06] ok. i'll have another look [01:07] i see he replied [01:18] wallyworld_: thanks, i replied again [01:18] nb there's a new mp for it [01:18] * wallyworld_ looks [01:28] poolie: doesn't look like you've reclassified the diff generation error? or am i looking at the wrong mp? i can only see one [01:28] i accidentally deleted the old one [01:28] https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79351 [01:28] but you may still have mail about the old thing [01:29] that's one one. but there's no code to raise a different exception etc as discussed in the comments [01:29] yeah we talked about doing it (10m ago) but i haven't done it [01:29] yet [01:29] ah ok [01:32] wallyworld_: any comments beyond that? [01:33] curious what you think about testing logging ,from your experience elsewhere [01:33] poolie: i was avoiding that issue :-) [01:33] but i sort of agree with your take on it [01:34] so long as nothing breaks, to me it's logging etc is orthogonal to the core functionality [01:34] the only test is really "can I solve my problem further down the line" [01:34] the validation level is more important than the verification [01:34] and so we can avoid being too pedantic about explicitly testing it to the same level as other code [01:34] poolie: What takes so long to get LP running again each time? [01:34] "does the right thing" vs "does it right" [01:34] sudo apt-get update; sudo apt-get upgrade; rocketfuel-get should do it. [01:35] from someone i got the idea i should not use rocketfuel-get to update, but rather update the directories directly [01:36] but, an example is for instance allenap's storm psql bug yesterday [01:36] or, um [01:36] I always use rf-get ot update [01:36] poolie: if the output were being consumed by a reporting package or something else downstream where there were a formal intergration contract etc, then it would be different [01:37] i see rf-get fails in a colo branch [01:37] i don't know, it just seems like there's always a snag [01:37] w: yeah [01:50] wgrant: you must have seen me come on here and say "why am I getting random error X when I try to run the tests?" [02:15] poolie: True. [02:16] i can still get stuff done but it does show up [02:17] i suspect it's about a constant factor whether you try to do 4 hours of lp per week or 40 [02:17] a constant amount of hassle, but the percentages are worse [02:17] It probably works better if you don't also have an unstable distroseries involved. [02:18] that is part of it [02:19] i did see some snags when running earlier series though [02:21] Hmm. [02:21] I have little friction with a Lucid LXC container. [02:22] oh, another example would be the thing you helped with a while ago, where one of the js symlinks was wonky [02:22] it's not awful [02:22] but it could be a bit easier [02:22] i think paul is jumping to conclusions a bit by asking for debs [02:22] otoh perhaps we could have recipe builds of more things that are currently brancehs [02:23] Debs of Launchpad? [02:24] no of dependencies [02:24] for instance of bzr or of mailman [02:24] mailman is difficult, since we monkey-patched it [02:26] bzr is an egg, too. [02:26] While using the packaging system would be nice, it's not practical for our deployment strategy. [02:26] Because we need multiple concurrent versions of LP to run at once. [02:27] And Debian packaging does not support that. [02:27] right [02:27] you would need to run them inside some kind of container which would be probably difficult and maybe not have any other benefits [02:27] so that's why i say i think sladen is jumping to solutions [02:27] Yes. [02:28] LP development could certainly suck a lot less. [02:28] But packaging is not going to help that. [02:28] One does not develop using packages. [02:28] One cannot reasonable deploy using packages. [02:28] => packages are not a benefit. [02:57] * wgrant reverts r14149, since buildbot doesn't like yuixhr apparently. [03:12] mwhudson: Linaro doesn't produce XM builds any more? [03:12] wgrant: a lot of the time when linaro says "beagle" it really means "beagle xm" [03:12] wgrant: or do you mean something else? [03:12] That's what I meant. [03:13] Ah, there are community "BeagleBoard" builds down the bottom. [03:13] in terms of architecture i think they're fairly similar [03:13] although the xm is a bunch better specced, obviously [03:13] Yep. [03:14] Thanks. [03:23] poolie: debs for dependencies is a no-show until we have concurrent versions installed in dpkg, or we radically change our deployment story [03:23] poolie: did you want to talk about the jobs thing ? [03:24] lifeless: wgrant and I would like to talk about the privacy enum when you're free [03:24] Private teams. [03:24] sure [03:25] I'm here all week [03:25] Except Wednesday :-P [03:25] did you want voice? [03:25] Yeah [03:25] Let me grab my laptop so I can do this whole Skype thing [03:26] sounds good (har har) [03:26] Boo, hiss [03:26] wgrant: Hai ^ [03:27] I'm there. [03:27] Waiting for laptop to boot [03:30] StevenK: I'm trying to invite you. [03:30] StevenK: Do you want to host? [03:30] I don't mind either way [03:31] lifeless is supposedly calling you now. [03:31] Oh, sigh, Skype is being crap [03:31] We can't bring you in... [03:31] StevenK: 'remote sound problem' [03:31] Problem with playback device and then it hangs up [03:31] StevenK: try hosting it [04:22] StevenK: do you know about security adaptors? [04:23] wallyworld: ... what about them? [04:24] StevenK: i want to use one for a method on an object, but from what i can tell looking in security.py, they are declared for the entire object [04:25] so i want a mechanism for method level permissions [04:25] Security is declared by interface [04:25] In ZCML [04:25] wallyworld: We need a specific example. [04:25] So you can split the interface into another and change permissions for that one interface in the ZCML [04:25] StevenK: Not quite. [04:26] i want a specific set of permission checks for destroySelf() on BugTask [04:26] that do not mess up any existing permissions [04:26] so i guess i would have a IBugTaskDelete interface [04:26] You may be able to use launchpad.BugSupervisor. [04:26] with the destorySelf method on it [04:27] Or you could do permission checking inside destroySelf. [04:27] i could but i was wanting to try and use the zope security model [04:55] StevenK: Could you reinvite me, please? [04:58] wgrant: I have been trying [05:01] wgrant: can you see my ping ? [05:02] I can. [05:19] X getting OOM killed == bad [05:21] And wgrant puts me on hold. Hah. [05:37] mwhudson: hi, the more i think about it the more i think oauth-based ssh would be good [05:37] https://answers.launchpad.net/bzr/+question/174075 is the second example today of someone having trouble making ssh keys === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267 [07:43] rvba: btw we don't use wishlist - just low [07:43] rvba: (because there isn't a useful difference) [07:50] Any objections if I take down staging and qastaging for a few minutes soon? [07:51] lifeless: okay, thanks for the heads up [07:55] Hello 'padders [07:56] hi mrevell [08:05] good morning [08:06] * danilos pulls his hair because local codehosting now doesn't work for him, yet it used to work just fine two days ago... argh [08:09] danilos: You're still looking at the buildfarm issue? === almaisan-away is now known as al-maisan [08:22] adeuring: are you reviewing today? Got a simple one for you: https://code.launchpad.net/~jtv/launchpad/bug-812500/+merge/79373 [08:22] jtv: I'll look [08:23] thanks [08:23] wgrant, yeah === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 267 [08:23] wgrant, so, log files are still not recorded for translationtemplatejobs, and I want to see why is that [08:23] danilos: Do you have a local builder? [08:23] wgrant, because the job kicks in, and then fails at the last moment, it could be simply that intltool is not installed [08:24] Yeah. [08:24] wgrant, yeah, I am trying to get that set-up [08:24] I could also see if I can convince it to do something on DF. [08:24] Or locally. [08:24] wgrant, but now that soyuz seems to work locally, code-hosting is broken for me :/ [08:24] Hah. [08:24] What's it doing? [08:24] wgrant, well, not accepting connections when I try to bzr push lp://dev/... [08:25] You're doing make run_codehosting? [08:25] Not just make run? [08:25] wgrant, and I already changed the poppy port to 5022 [08:25] (make run_all works too) [08:25] wgrant, I was doing make run_all [08:25] Hm, codehosting normally listens on .99:5022 [08:25] poppy-sftp may well be listening on *:5022 [08:25] Or does codehosting listen on .88:5022... I can't quite remember. [08:25] Host bazaar.launchpad.dev HostName launchpad.dev Port 5022 [08:25] That's .88:5022 [08:26] well, they were conflicting the other day, I used to just kill poppy to make it work, but now after doing a fresh 'make schema', and then make-lp-user, I am having trouble getting it to listen properly on any port [08:27] I don't think I've run them simultaneously since poppy started listening on 5022 [08:30] wgrant, so, sftp.tac is also listening on .88:5022 [08:30] but run_codehosting wants to run it like that :/ [08:30] Best to move poppy-sftp. Add another 0 or something. [08:31] wgrant, I've moved it to 5023 already (and confirmed with netstat -palnt) [08:31] Oh, you said above you'd changed it to 5022 :) [08:32] There's no stale bzr-sftp lock? [08:34] wgrant, so, I ain't sure what daemons/sftp.tac presents, because it's run directly by "make run_codehosting", is that poppy? I don't think so because there's poppy-sftp.tac as well [08:34] sftp.tac is bzr-sftp [08:34] /var/tmp/development-sftp.pid may be relevant and stopping it from starting. [08:36] Of course, if you're not dealing with packages then you don't actually need poppy at all. === al-maisan is now known as almaisan-away [08:36] wgrant, right, I've killed it in the meantime, but it hasn't helped now (that's how I initially solved the problem of conflicting ports, thought I'd be smarter this time :) [08:37] Heh. [08:37] I just changed its sftp port to 50022, and now both are running fine. [08:40] wgrant, hum, yeah, I guess something else is borked here for me, I may have to start from scratch if I don't want to spend too much time trying to debug local setup [08:40] danilos: What if you blow away all the pidfiles in /var/tmp? [08:47] wgrant, nope, doesn't help, log file does have some interesting input like https://pastebin.canonical.com/54374/ [08:48] Ohh. [08:48] I am not sure why it's passing around danilo@bazaar.launchpad.dev as the email since I've made an LP user with my canonical.com address [08:48] Ctrl+C, rm /var/tmp/launchpad_forking_service.sock, make run_codehosting [08:48] The forking service likes to leave its FIFO around. [08:49] danilos: What's a good branch to test with? [08:50] wgrant, lp://staging/~danilo/translated/trunk should be good enough (and small), lp:eog is another good candidate [08:50] Thanks. [08:51] wgrant, depending on when you set-up translations import (i.e. before or after the branch is scanned), you may want to push another revision since only the branch scanner actually creates templates build jobs [08:51] Yep. [08:52] wgrant, and yes, the socket file was the problem, thanks for helping out [08:52] jtv: your changes , but what about a test? [08:53] adeuring: the case is tested; it just wasn't tested realistically. So the first thing I did was fix the test by using a slave-store object, so that it broke in the same way as production. [08:53] The main code change then fixes that failure. [08:54] jtv: gah, sure -- seems that I had not have enough coffee. r=me [08:54] * jtv looks up the diff [08:54] Ah. :) Thanks! [08:54] Phew, yes, it's right there, with a comment. [09:06] jtv: I think bug 375013 is already fixed for Launchpad, isn't it? [09:06] <_mup_> Bug #375013: Cannot commit directly to a stacked branch

< https://launchpad.net/bugs/375013 > [09:08] jtv: nevermind, I only just got the notification of your linked branch [09:08] ok [09:19] jtv: nice to get rid of another workaround :) [09:19] jelmer_: yup, paying off our tech debt. Too bad I can't tag the bug as tech-debt, because it only applies to the Launchpad task. [09:27] danilos: All working now? My local attempts were delayed when I realised that lpbuildd won't work in LXC. === almaisan-away is now known as al-maisan [09:34] jelmer_: feel like reviewing it? https://code.launchpad.net/~jtv/launchpad/bug-375013/+merge/79378 [09:36] * bigjools sighs at bugspam from lifeless [09:37] Ah yes, always nice to get mail. [09:38] maybe I should do what mwhudson did and upgrade to oneiric and have 10k emails deleted [09:40] That sounds efficient. [09:40] Inbox Zero, wayhay! [09:42] I am practising inbox ~750 [09:42] I am currently on inbox 17,425 [09:44] there was something I read recently about people who hoard everything in their inbox are quicker at finding emails that those who file them away [09:44] wgrant, not really, fighting the build-queue-builder readding "missing" stuff to buildqueue which I don't care about and which makes it fail [09:45] Why are you running queue-builder? === al-maisan is now known as almaisan-away [09:46] wgrant, I thought it was a replacement for buildd-manager, but I guess I was wrong ;) [09:46] queue-builder is ancient and probably doesn't work any more. [09:46] It served a different purpose to buildd-manager. [09:47] wgrant, now, I only have an issue where bob the builder is not considered a PPA builder, and translation template jobs seem to be [09:47] wgrant, right, I thought it was a newer "builder" for stuff in the "build queue" :) [09:48] jtv: Sure, I'll have a look [09:48] danilos: https://launchpad.dev/builders/bob/+edit, check "Virtualized", and enter garbage for the VM host. [09:49] thanks jelmer_! === almaisan-away is now known as al-maisan [09:52] wgrant, cool, thanks; I wonder what do I make ftpmaster.internal resolve to (https://pastebin.canonical.com/54376/) [09:52] danilos: Just ran into that myself. archive.ubuntu.com should work. [09:52] (but I changed the URL in the chroot) [09:53] wgrant, right, I'd probably even add my local apt-cacher-ng proxy there, but I don't want to get into editing a chroot tarball now :) [09:54] cd /tmp/; sudo tar xf ~/Downloads/chroot-ubuntu-natty-i386.tar.bz2; sudo sed -i s/ftpmaster.internal/blah.blah.blah/ /etc/apt/sources.list; sudo tar jcf ~/Downloads/chroot-ubuntu-natty-i386-2.tar.bz2 chroot-autobuild; scripts/ftpmaster-tools/manage-chroot.py -s natty -a i386 -f ~/Downloads/chroot-ubuntu-natty-i386-2.tar.bz2 add [09:58] danilos: No module named canonical.buildd.pottery [09:59] Hahahaha [09:59] There's our problem. [09:59] Bad Translations team is bad. [09:59] it's copying into python2.6 in the chroot. [09:59] wgrant, thanks :) I am having it building like this as well, but actually, it worked for me :/ [09:59] So when the default Python version changed to 2.7... [10:00] danilos: Which chroot are you using? [10:00] wgrant, lucid [10:00] Pre-Natty? [10:00] Yeah. [10:00] that's the problem. [10:00] wgrant, yep, that explains it [10:00] And why it broke in October. [10:00] We use the dev series chroot. [10:00] So, it's been entirely broken for a year and nobody really noticed... amusement. [10:00] $ grep -r python2.6 . [10:00] ./generate-translation-templates:PYMODULES=/usr/lib/pymodules/python2.6 [10:00] * wgrant looks disapprovingly. [10:01] wgrant, well, it's been noticed, but those who did were never sure if it was supposed to work considering it was such a recent feature anyway [10:01] Still, there's also LP-side bugs causing logs to not happen. [10:03] wgrant, right, I'd like to fix that: any idea why the log file would not be recorded? [10:05] wgrant, as for the python detection, even though I hate sh scripts like these, our best bet is probably to go with modifying PYTHON_PATH instead; what do you think? [10:05] danilos: Well, or we could s/2.6/2.7/... ahem. [10:06] As for the log issue, see TranslationTemplatesBuildBehavior.updateBuild_WAITING [10:06] wgrant, yeah, and trust that Barry's claim how there won't be further pythons in 2.x series :) works for me, though, but we are ultimately going to switch LP to 3.0 as well, and then there'll be more fun [10:07] danilos: The BPB/SPRB equivalent of updateBuild_WAITING calls handleStatus, which calls _handleStatus_PACKAGEFAIL in this case. [10:08] See PackageBuildDerived._handleStatus_PACKAGEFAIL for our log storing stuff. [10:08] wgrant, thanks [10:11] wgrant, I assume storeBuildInfo does that based on the slave_status? [10:13] danilos: I believe so. [10:13] Actually, slave_status is just used to find missing dependencies. [10:14] wgrant, I so want to fix bug 691530 as well, but I don't have the time [10:14] <_mup_> Bug #691530: Split up TranslationTemplatesBuildJob into a BranchJob and BuildFarmJobOld

< https://launchpad.net/bugs/691530 > [10:14] But storeBuildInfo is pretty obvious mostly. [10:14] danilos: I think there'll be a better refactoring around that area once we get SOA stuff going. But that will be after your time, sadly. [10:15] wgrant, yeah, but this is bound to be broken once the refactoring happens simply because it's one class pretending to be two things at the same time, iow, very easy to confuse what it's doing [10:16] danilos: Well, the model will hopefully be thoroughly rethought and reworked at that point. [10:16] danilos: But for now if you can store logs, we may be in a better state to diagnose this within 12 months :) [10:16] wgrant, right, supposedly that'll help [10:17] wgrant, heh, exactly, I'll get that done [10:17] Should be pretty easy. [10:17] Just steal bits of storeBuildInfo :) === al-maisan is now known as almaisan-away [10:58] gmb: a question to you as the "retired bug import specialist": Did you see this MP: https://code.launchpad.net/~ceejatec/sfbugs2launchpad/user-mapping/+merge/78076 ? looks really interesting to me, but you have more experience with bug imports. [10:59] the core change is a better mapping of SF user names to LP names [11:00] adeuring: I'll take a look. [11:01] gmb: cool, I'm asking for just a general assessment. I see a number of small issue, and one bigger problem: the script becomes complex enough to devsreve testing [11:02] adeuring: Ah, I hate it when that happens :) [11:02] but otherwise, I think is it a very nice imporvementz [11:02] adeuring: Okay. I'll cast a weather eye over it and see if I spot anything. [11:02] gmb: cool, I would do a detailed review, but I'd appreciate a "general comment" from you [11:03] adeuring: Righto, I shall endeavour to provide one, then :) [11:59] adeuring: That's a really cool branch. I don't see anything glaring at me about the way it does things, but I agree that that script requires some tests now. [12:00] gmb: ok, thanks! I'm now more comfortable to review the M :) [12:01] wgrant, btw, it was my understanding that all the indirection through .specific_job.build should be gone by now already, I guess it turned out to be impossible? (current state of things confuses me to no end, I am never sure what object type is the right one to pass around for these kind of things) [12:03] danilos: Not impossible, just a bit of work. [12:17] sinzui, hi. I'd like to talk sometime this morning about the possibility of html5browser growing the abilites to notice incremental test progress; to report what incremental records it saw, if anything; and to have timeouts per-increment in addition or instead of per-page. I'll look into the code and see if I think I can pull this off. [12:17] This is because of a buildbot test failure on something that passed locally and in ec2 but failed in buildbot with only the report "timeout error." That doesn't give me much to go on when the test passes in 10 seconds locally in a vm, and the timeout limit is 30 seconds. [12:18] gary_poster, okay [12:18] * sinzui needs to review what hh wrote [12:20] thanks sinzui. I have a doctor visit later this morning. lemme know when you are available [12:20] I mean, later, when you are [12:26] hmm, it seems somewhat odd I'm rewarded with a higher build score for doing PPA builds in private rather than in public [12:26] jelmer_: not at all - we consider private builds more urgent [12:26] jelmer_: Well, people with private PPAs are generally either privileged Canonical people or commercial customers. [12:26] bigjools: s/private/commercial/ ? [12:27] what he said [12:27] ie. they're not random daily builds of web browsers that take 4 hours each and there are 40 of them a day. [13:21] Thanks jelmer_ [13:22] jtv: geen dank :) [13:22] :) [13:27] sinzui, I've made it through my email. Are you going to be available for a hopefully quick call within the next 30 minutes, or will it be sometime after that? [13:28] gary_poster, I should be ready in 15 minutes [13:28] great thank sinzui [13:28] s [13:40] Internal Server Error [13:40] ShortListTooBigError [13:40] whee :( [13:45] sinzui: I have a file being linted that shouldn't be linted. Are you around to chat? [13:45] abentley, you are in a queue. Gary is the next out [13:45] :-) [13:45] sinzui: cool. [13:45] I'll try to be quick [13:45] jelmer_: getting a strange test error from code I didn't touch... ImportError: No module named builder.recipe [13:46] abentley, I have a list of things I do not wanted linted too. [13:46] jelmer_: any ideas? [13:46] gary_poster, I am on mumble? [13:51] jtv: hmm, not sure. it sounds like it might be related to removing an import of lp.codehosting somewhere, either directly or indirectly? [13:52] jelmer_: I was thinking, maybe because the auto-import-formatting-tool has moved it. I tried moving it back, but with the test trouble on oneiric it's hard to keep track of which test run has it which way! [14:02] hi abentley [14:03] sinzui: hi. [14:03] sinzui: mumble in orange 1o1? === gary_poster is now known as garytodoctor [14:12] abentley, I think this is the sed fix: -e '/@$/d'` [14:13] sinzui: cool. [14:21] jelmer_: yup, got a successful one at last. It's a matter of importing the bastards in a specific order. [14:21] We really should fix this. [14:21] jtv: urgh, indeed [14:22] ./utilities/format-new-and-modified-imports orders imports in an agreed, canonical way. [14:22] And, it seems, breaks some code that relies on lp.codehosting's import side effects in particular ways. [14:28] adeuring: could you please review https://code.launchpad.net/~abentley/launchpad/support-mustache/+merge/79404 ? [14:28] abentley: sure [14:44] abentley: r=me [14:44] adeuring: thanks! [15:01] bug 874298 (which I'm working on fixing) - any reason not to use lp-query-distro to get the list of architectures as well as the suite, given that it already supports this? [15:01] <_mup_> Bug #874298: cron.germinate needs to be fixed to examine the armhf architecture < https://launchpad.net/bugs/874298 > [15:01] the hardcoded architecture list looks like elderly cruft to me [15:05] adeuring: ^- as OCR? [15:09] cjwatson: I must admit to have no clue without a closer look... [15:10] I can just submit the 30-line patch for review if you prefer that over a pre-impl chat [15:27] cjwatson: well, I'd prefer if you could discuss this with somebody who has more soyuz-fu than myself ;) [15:32] jtv: maybe if you're available? [15:33] cjwatson: #sup? [15:40] bigjools: bug 874298, any reason not to use lp-query-distro to get the list of architectures as well as the suite, given that it already supports this? [15:40] <_mup_> Bug #874298: cron.germinate needs to be fixed to examine the armhf architecture < https://launchpad.net/bugs/874298 > [15:40] just checking before I submit this branch for review [15:40] checking [15:40] * jtv looks at what cjwatson & bigjools are discussing [15:41] cjwatson: +1 [15:41] cjwatson: FWIW I consider that code to be yours anyway [15:41] I eventually want it out of our tree so you can manage your scripts in the .d directories [15:42] It _sounds_ sensible, but then cron.germinate is a script I haven't been told to rewrite yet. :-) [15:42] Yes yes yes [15:42] bigjools: yep, indeed I mentioned that in the merge request. https://code.launchpad.net/~cjwatson/launchpad/germinate-armhf/+merge/79416 [15:42] cjwatson: lol @ pre-imp notes [15:43] context is for losers [15:45] cjwatson: it's approved [15:45] ta [15:54] bigjools: if you wouldn't mind landing it for me, that would be brilliant [15:54] ok [16:01] bug 874377 is a regression [16:01] <_mup_> Bug #874377: sync-source.py is broken: Values instance has no attribute 'moreverbose' < https://launchpad.net/bugs/874377 > === matsubara_ is now known as matsubara-lunch [16:52] sinzui: do you know how to fix bug #870130? hit the same error today, not even trying to build the recipe, but just edit it. [16:52] <_mup_> Bug #870130: OOPS when requesting recipe build < https://launchpad.net/bugs/870130 > === gary_poster is now known as garyposter === garyposter is now known as gary_poster === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 267 === salgado is now known as salgado-lunch [17:32] dobey, I do not exactly, but I expect anyone on the maintenance team can fix the issue in 2 hours using my summary of the historic issue [17:33] sinzui: should we bug someone in particular? [17:34] dobey The other route is to delete things that are causing the oops. The only thing I see from the candidate list is branches [17:34] hmm [17:35] we seem to be missing the Americans who are on maintenance [17:35] sinzui: hrmm. can you tell what's causing it exactly? [17:35] sinzui: ah, they are on holiday today? [17:35] maybe [17:36] dobey per the bug, Lp is preparing to send an email, so it makes a copy of the thing in the email. It is coping 1000's of things that you will never ever every never see. [17:36] sinzui: fun times :-/ [17:36] Since this issue only happens in a few cases, I believe that early adopters of recipes or bug users are branches are all heading to a bug pile up [17:37] We have known about this issue for 18 months, we wrote code to ensure it will not happen, but developers and reviewers do not enforce the rules [17:37] The fix really is fucking trivial [17:39] heh [17:40] dobey: I am feeling unproductive today. I will attempt to fix this after lunch if no maintenance teams see that this bug blocks Canonical projects from meeting their goals [17:40] sinzui: you haven't eaten yet? [17:41] too many machines broken by oneiric upgrades. There is a queue to get the one network cable in the house [17:42] :-/ [17:59] ugh, and LP just changed a bug to "confirmed" because someone clicked "affects me too" on it, even though the bug was already marked a dup [18:45] dobey: theres a bug for that [18:47] cool === herb__ is now known as herb