[00:38] <_Andrew> I think my bzr upgrade is borked I started it hours ago and it's not finished [00:38] <_Andrew> bzr upgrade sftp://andrewfenn@bazaar.launchpad.net/~hardwar/hardwar/trunk/ [00:38] <_Andrew> I it's still at making backup of tree history [00:52] _Andrew: does strace show any activity? [01:01] <_Andrew> I never used strace before [01:01] http://www.gnome.org/~newren/tutorials/developing-with-gnome/html/ch03s02.html [01:02] it will show if any activity, loosely, is happening - ie via system calls. #1 debugging tool for all sysadmins. [01:04] so in your case: a Q&D use would be: strace -p ;; any scolling output means stuff is still happening. [01:04] poolie: are you the distcc Martin Pool ? [01:07] mtaylor: yes [01:08] mtaylor: hi [01:08] mtaylor: how did you go with that plugin; I saw your query but you had logged [01:09] poolie: (sorry to bug you in the wrong place...) is there a way to pass an option to distcc so that the preprocessor run gets it, but it doesn't get sent to gcc on the build hosts? [01:09] lifeless: I'm getting Unable to load plugin 'repodetails' from '/home/mtaylor/.bazaar/plugins' [01:09] mtaylor: CPP_FLAGS perhaps ? [01:09] lifeless: hm. the env var? [01:09] mtaylor: yah [01:09] mtaylor: no problem, though i should say i'm not working on it very actively at the moment [01:10] mtaylor: the plugin requires my repository branch [01:10] mtaylor: the client has some hardcoded knowledge about which options should be seen by cpp [01:10] lifeless: yup. I installed that too [01:10] or you could use that variable lifeless mentioned [01:10] mtaylor: to make it be exclusive to that branch, just put it in bzrlib/plugins/repodetails of that branch [01:10] hm [01:10] hm [01:10] it's probably a bug that distcc doesn't specifically handle it [01:10] mtaylor: then when you run that branches bzr it will find it, but other ones won't [01:10] I'm having problems specifically with -Wunusued-macros [01:10] lifeless: ah, good call [01:11] or, -Wunused-macros, rather [01:11] lifeless: the error I'm getting from the import is ImportError: cannot import name chk_map [01:13] lifeless: so perhaps my bzr is too old? [01:13] mtaylor: that file is only present in my 'repository' branch [01:13] ahhhhhhhhh [01:14] * mtaylor groks your repository branch better now [01:17] concretely - bzr branch http://people.ubuntu.com/~robertc/baz2.0/repository repo [01:17] bzr branch http://bazaar.launchpad.net/~lifeless/+junk/bzr-repodetails repo/bzrlib/plugins/repodetails [01:18] repo/bzr repository-details repo [01:18] yes. now it's making sense [01:18] I was assuming repository was a plugin :) [01:18] oh! [01:26] <_Andrew> http://pastebin.com/d54907c82 [01:26] <_Andrew> That's what I get for strace [01:42] _Andrew: ok. so what would that suggest to you? [01:45] _Andrew: eg, by way of comparison with say: strace wget http://google.com [01:47] <_Andrew> It would suggest I just screwed up my launchpad project? [01:48] _Andrew: heh. no. the read system call is nicely 'wedged' attempting to read from id #6. [01:49] why? is unknown at this stage. [01:49] you could lsof against that pid, and see if you can see what #6 refers to. If network, or filesystem. [01:50] _Andrew: did it get beyond 'backing up' at all ? [01:50] _Andrew: if not, I suspect a bug and a hung server on the lpside [01:50] <_Andrew> nope [01:51] _Andrew: in that case please file a question on the bazaar-launchpad product listing your branch [01:51] <_Andrew> should I just stop and restart? [01:51] _Andrew: and the symptoms; quote this conversation too [01:51] _Andrew: I doubt that stopping and restarting will magically fix it [01:52] pastebin is transient : best to attach the pastebin as a file rather than by reference [01:56] <_Andrew> How do I revert my launchpad repo back to the .backup? [01:59] _Andrew: if it never got past doing the backup, then it is unaltered [02:00] <_Andrew> bzr: ERROR: File exists: '/~hardwar/hardwar/trunk/backup.bzr': mkdir failed: unable to mkdir [02:00] <_Andrew> bzr disagrees with you [02:01] <_Andrew> So is there a way to get rid of the .backup folder so I can try again [02:20] _Andrew: not trivially; please file that question I asked you to [02:21] <_Andrew> I already filed a bug [02:25] <_Andrew> https://bugs.launchpad.net/launchpad-bazaar/+bug/286180 [02:25] Launchpad bug 286180 in launchpad-bazaar "Error on upgrade of bzr repo" [Undecided,New] [02:45] Hello, folks! How's the launchpad<->trac integration coming? [02:45] I set up the plugin on my trac instance -- http://allmydata.org -- and then this revealed a bug in session mgmt (or some such) in the launchpad side, and then that bug was fixed, and then we were waiting for the fix to make its way into the deployed launchpad instance. [02:45] If I understand correctly. === jamesh__ is now known as jamesh [02:52] Oops, familytime! === zooko is now known as zookoafk [02:54] zookoafk: most recent rollout was late last week, give it a shot it may be fixed [02:55] <_Andrew> Why aren't all bzr repos just upgraded locally.. [02:55] <_Andrew> I remember Launchpad being down either last week or the week before that. [02:55] _Andrew, Some are very large, and want to be upgraded by someone with not so much bandwidth. [02:57] <_Andrew> ... anyway what can I do now? [03:01] _Andrew: just keep using it [03:02] 01:56 <_Andrew> How do I revert my launchpad repo back to the .backup? [03:03] _Andrew: right now it sounds like it's unaltered *except* for the presence of backup.bzr [03:03] so as lifeless says you can keep on using it as normal; it's just that upgrade won't work [03:04] _Andrew: they aren't just all upgraded locally because upgrading drops compatibility with older versions of bzr, which not everyone finds desirable [03:05] Or if you *really* want to upgrade, pull the latest revision, delete the backup, upgrade it locally, and push with --overwrite : the problem with doing this is that it destroys the information required to fix the issue you've encountered. [03:11] persia: push --overwrite doesn't upgrade the remote branch. [03:12] "push --overwrite" won't actually delete existing revision data at the remote end either. [03:12] --overwrite means "make the remote branch's tip revision be the same as local, even if the local one is earlier than or has diverged from the remote one". [03:12] spiv, Hrm? I thought that if I upgraded locally, and pushed, it would upgrade the remote, under normal circumstances. [03:12] it'll update the head revision pointer even if the new head isn't descended from the old head [03:13] persia: no, the only operation that upgrades an existing branch (or repo, or working tree) is "bzr upgrade". [03:13] spiv: when are we getting a smart server verb for upgrade? :) [03:13] Ah, so running bzr upgrade locally can never change a remote branch? [03:14] Because silent/automatic upgrades would make it dangerous to use new bzr versions on branches than are intentionally in older formats (which you may want because you want older clients to keep being able to use them). [03:14] persia: "bzr upgrade sftp://..." will upgrade a remote branch, but it is slow [03:15] persia: right; you have to explicitly upgrade the remote location. [03:15] OK. My mistake. Thanks for the clarification. [03:15] * persia will probably use bzr upgrade more often as a result [03:15] jamesh: when we figure out a sensible scheme for discussing formats in the smart protocol, I guess. [03:15] Anyway, food time! [03:15] * spiv -> food [03:17] persia: if you're working with bazaar.launchpad.net, I've found the quickest way to do an upgrade is to use lftp to connect via sftp, then do a recursive delete of the branch data [03:17] then use "bzr push --use-existing-dir" to push a copy in the new format [03:18] at a minimum, "bzr upgrade" over the network will involve downloading all the branch data an uploading it again [03:26] jamesh: at least twice, IIRC [03:27] cjwatson: right. What I gave was the lower bound [03:28] so if you've already got all the data locally, you can easily beat the time "bzr upgrade" would take [03:32] <_Andrew> lifeless: if I commit and push branches up will it screw up finding the error (since that's what you're concerned in finding) [03:34] _Andrew: no, I don't rhink it will make difficult [03:36] <_Andrew> eh... think? [06:27] Hi, I'm trying to reassign bug 285508 from project ubuntu-mobile to ubuntu, and LP is telling me "Enter a project name" [06:27] Launchpad bug 285508 in ubuntu-mobile "User ubuntu must be present for MID install to work" [Undecided,New] https://launchpad.net/bugs/285508 [06:29] StevenK: you can't change it. You need to change the URL (take out the -mobile), then load the page, then click on the option that comes up, to affect it there. Then you can mark the mobile one as invalid [06:30] Hobbsee, Isn't there a way to just change it? Leaving it invalid leaves the implicit subscribers subscribed. [06:31] persia: don't think so, because ubuntu isn't a project - it's a distribution [06:31] persia: actually, there might be a bogus project - registry admins or something? [06:31] you can reassign it to some other unrelated project [06:31] that way it is their problem rather than yours [06:31] Hobbsee: btw, why prefer URL hacking over clicking "Also affects distribution"? [06:31] jamesh, That's not very nice. [06:31] spiv: because those pages confuse me [06:32] spiv: and because i wasn't sure if it'd work [06:32] * spiv nods [06:32] persia: no it isn't. [06:32] spiv, URL hacking is faster, and usually more reliable [06:32] i can figure it out for other packages inside ubuntu, but not otherwise [06:32] persia: and you know it's actually going to do what you want, whether you know the terminology or not [06:32] there is no way to convert a distro bug task to a project bug task or vice versa [06:32] (at least not last time I checked) [06:33] jamesh: correct. [06:33] So if reporters file things in the wrong place, there's no way to safely move them without annoying the bug contacts for the project that was spammed? [06:35] Hobbsee, Also, most of the time it skips the business logic for the buttons, so you can do things that might otherwise not work. [06:35] persia: right. [06:40] persia: what sort of business logic do you expect to bypass by hacking URLs? [06:41] jamesh, I haven't done it in a while because I have the necessary rights now, but task nomination was something I used to abuse that way all the time. [06:41] Yep. [06:41] I know it still works to file bugs against closed projects. Dunno what else. [06:41] Email works for that too. [06:41] It's great to work around some stupid LP bugs. [06:42] It's the same issue : the business logic is triggered by the UI, rather than being triggered during the commit. [06:43] ah, yes, that's what it always get to used for, for people without rights - the task nominations [06:43] I think mpt filed a bug about it in Edgy, but don't remember the number. [06:47] The problem is that fixing it either means rewriting massive chunks of LP, or duplicating the business logic for each interface. There are plenty of more annoying bugs. [06:47] there are multiple layers at which business logic is defined. [06:47] Oh good, so it's only exposed for some things. [06:48] ideally the checks at the UI layer would only prevent the user from hitting fatal errors [06:48] and have the important checks done at the model layer and protected by the security proxies [06:49] I'm slightly concerned at how little seems to be checked by the securitypolicy. [06:49] Right. That's a little bit of duplication, but probably worthwhile to avoid users being annoyed about being able to press buttons that don't work. [06:49] Lots of things are read-only in the API that shouldn't be. [06:50] file bugs? [06:50] Which means the checking is being done outside the usual security infrastructure. [06:51] wgrant: for some interfaces inside LP, the security proxies make certain data read only and require modifications to go through particular methods [06:51] wgrant: I haven't played with the API stuff much, but I wouldn't be surprised if the read only attributes get exposed automatically but the methods need special handling to expose [06:52] i.e. it doesn't sound like evidence that the layering is being bypassed [06:52] jamesh: I noticed that with status transitions and the like. [06:52] But thinks like Person.{latitude,longitude}. [06:52] bug status transition is definitely an example of this kind of thing. [06:53] There's no special handling needed for location, except for the permissions specialcasing. [06:53] But they are read-only in the API. [06:54] so [06:54] I'd suggest filing bugs [06:54] I've done enough of that to know it doesn't work too often. [06:54] lp exposing apis is making layering more important than ever, and now there are multiple people driving it [06:55] wgrant: statistically, it is more effective than not filing bugs [06:56] jamesh: Only slightly. [06:57] wgrant: where does complaining on IRC fall on that spectrum? :) [06:57] Actually, although I file bugs, I find that discussion on IRC runs about even with filing bugs towards a resolution. [06:58] spiv: For Launchpad it's surprisingly high. [06:59] IRC might be good for things that can be fixed quickly, but it is easy to lose such reports [06:59] jamesh, Very true. [06:59] spiv: if a LP developer files the bug, it seems to tend to get done faster. IRC tends to get LP devs to filde them. [07:00] s/filde/file/ [07:00] That's what makes it both surprising and impressive that IRC is such an effective forum in LP. [07:00] and it won't be that effective if the person who can fix it lives in the wrong time zone ... [07:01] Hobbsee: correlation is not causation... [07:03] spiv: sure, that's true. It's just interesting that it often seems to happen that way [07:06] Hobbsee: it's certainly interesting, but by itself it doesn't really tell us much. [07:08] Anyway, this discussion is getting hopelessly -meta. Can we either discuss things about launchpad (rather than launchpad development habits) or not discuss so much? [07:08] Hobbsee: I'd expect you'd have better luck with your bugs than many people -- you know who to ask in many cases. [07:08] Hobbsee: and it definitely isn't an argument for not filing bugs yourself. (And I wonder... if users filed more bugs, would the correlation decrease?) [07:09] jamesh: that's true. That doesn't translate to them actually getting fixed, unless they're critical. [07:09] I'd imagine that is one of the things that favours bugs filed by insiders. [07:09] theoretically. Maybe we then file more bugs than most others, so see a smaller percentage actually get fixed. [07:09] Hobbsee: I've filed bugs that have sat round for a long time but were low importance [07:09] although I was pleased to see the turn around time for the breakage yesterday - well done guys! [07:10] spiv: interesting experiment. I do need to file some more bugs, so we'll see. [07:11] * Hobbsee goes off to file that rotten advanced search bug [07:14] hm, nope, surprisingly it's not reported. [07:15] What is it? [07:16] wgrant: do an advanced search (say, search for all bugs with u-u-s subscribed), hit search, then do a reorder. [07:17] it drops the advanced search term, shows you all the open bugs that you had, without the advanced search criteria in place. [07:18] I haven't noticed that for years... I just take it as a given. [07:19] i keep getting caught by it. [07:19] i mean, by the same logic, i don't expect to suddenly get all bugs, globally, if i do a reorder on all ubuntu bugs. [07:21] what's the plural of criteria? [07:22] oh, that is the clural. criterion is the singular. interesting. [07:24] right. Filed the LP bug for the day. [07:24] I won't do a wgrant, and file 15. [07:24] https://bugs.edge.launchpad.net/malone/+bug/286249 [07:24] Launchpad bug 286249 in malone "Ordering after an Advanced Search drops the search criteria" [Undecided,New] [07:26] I haven't followed 15-a-day for a while now. [07:28] next up will be that buildd crazy UI bug. [07:28] spiv: seeing as you're advocating me filing bugs myself, does bugs with the +builds/ and related pages go under soyuz, or? [07:29] That would be Soyuz. [07:29] Hobbsee: I'm (blissfully) ignorant of the answer to that question ;) [07:30] spiv: hehe, OK [07:30] spiv: how long do you think a bug about "please remove these two pages because they're duplicated" will take to fix? [07:30] I'm a bit confused about where the line between Foundations and Registry lies, but I'm fairly sure of other things. [07:30] Hobbsee: Until you can slip an rm in on someone's laptop. [07:30] Hobbsee: "it depends" :) [07:30] ie. UDS. [07:30] Hobbsee, all launchpad developers are in london for a 2 week sprint, so, "longer than usual" :) [07:31] I'm actually having breakfeast there right now [07:31] Hobbsee: potentially quite fast, but who knows what terrors lurk in dark corners... [07:31] beuno: no, usual is at least 6 months, as it's not a critical bug. :P [07:31] spiv: hehe, OK [07:31] Hobbsee: That said, *probably* it is actually quick to fix. [07:31] Considering that a separate bug was needed for removing the actions menu from each of the bug pages, I don't hold much hope. [07:32] (and most of them slipped from 2.1.10... wtf) [07:32] Hobbsee, is this something in soyuz? [07:32] spiv: that's what I would have thought, but I would have thought the same of adding headers to mails [07:32] beuno: which? [07:32] Hobbsee, this bug you want to report [07:32] beuno: i've already reported https://bugs.edge.launchpad.net/malone/+bug/286249, and am about to report one in soyuz, yes. [07:32] Launchpad bug 286249 in malone "Ordering after an Advanced Search drops the search criteria" [Undecided,New] [07:33] Hobbsee, all listings will be redeisgned to fix all those problems [07:33] when? [07:33] and, as for soyuz, I have a UI sprint planned for around january, so the more bugs I have to work on, the better [07:33] beuno: "will be" in which timeframe? [07:34] wgrant, in the launchpad 3.0 release cycle [07:34] which is until july next year or so [07:34] beuno: Do we get customisable columns? [07:34] So filing these bugs is largely useless, and it's better to talk to you about it on IRC? [07:35] Or s/IRC/UDS/ for Soyuz stuff? [07:35] wgrant, I haven't figured out all the details, but, the more I know about what you guys find useful, the more chances it has of landing :) [07:35] UDS is probably more effective than IRC [07:36] right, I will be doing some soyuz research during UDS especially [07:36] persia, wgrant, bugs are vey useful so I don't forget [07:36] Sounds good, considering your users will be there. [07:36] I'm happy to discuss it on IRC/UDS, but bugs help me focus :) [07:37] heh [07:37] I'm really looking forward to talking to you guys in UDS [07:37] I think the way to fix Soyuz navigation is a big rm followed by rethinking it. [07:37] Or maybe just lots of portlet abolition. [07:37] I've been working on navigation proposals a lot lately [07:38] all of launchpad needs a re-think [07:38] It is a nasty thing to design, particularly in Soyuz land. [07:38] I won't really decide until I understand all LP apps [07:38] When you have things like DASBPR, you know you're in trouble. [07:38] and do extensive testing [07:38] soyuz, and navigation? [07:39] beuno: https://bugs.edge.launchpad.net/soyuz/+bug/286253 for you [07:39] Launchpad bug 286253 in soyuz "mass duplication in buildd administration" [Undecided,New] [07:39] only way to navigate soyuz from one section to another effectively is through bookmarks. [07:39] Hobbsee, feel free to subscribe me to UI bugs when you file them [07:39] Hobbsee, No, URL hacking works too. [07:39] beuno: you're on it now, thanks. [07:40] persia: i don't remember hte magic URL bits [07:40] Oh. Then URL hacking works for me :) [07:40] URL hacking works for me too. [07:40] (but I don't do nearly as much buildd stuff as you) [07:40] some parts it does for me [07:41] But I have some bookmarks that take arguments for the really common things. [07:41] buildds aren't really teh problem - it's finding the queue, or the build queues [07:41] wgrant, I suspect the magic bits are part of Hobbsee's magic power [07:41] er, upload queue, or the build queues can get interesting. [07:41] particularly if you're looking for a particular release. [07:41] rather than globally [07:41] beuno: Try to find binary download links from https://edge.launchpad.net/ubuntu/+source/linux [07:42] wgrant: *snort*. [07:42] wgrant: for a past binary... [07:42] wgrant: throw him in the deepend, why don't you? :) [07:42] It's the same as a current binary. [07:42] wgrant, That's an especially evil example though. [07:42] persia: it's one that gets used a lot, though [07:42] But you have to notice the portlets and realise that you have to go through the build. [07:43] Hobbsee, True, actually. Probably gets used more than anything else. [07:43] persia: i doubt it's bookmarkable either - that's the real pain [07:44] Hobbsee, Depends on the automation of your bookmarks : you can get it iff you have the correct versions. [07:44] It's not like build logs, where you have to collect the buildID from somewhere first. [07:44] persia: sorry, i meant generically enough that you didn't need to know the version [07:45] Oh, no, you can't do that. [07:51] * Hobbsee --> lecture [07:53] Hobbsee: Late! [07:53] (says he who is still in a workshop) [07:53] wgrant: i know! I have to drive there still! [07:53] Eww. [07:54] at least i'm driving away from the traffic! [07:55] Hobbsee: evening lecture? suck. === mdz_ is now known as mdz === Rinchen is now known as Rinchen-sprintin [11:51] hi [11:51] anyone here in charge of bzr? [11:51] bugabundo_work, bzr as software, or the bzr server used in launchpad? [11:51] humm again no one responsible for the # help? I must live in strange timezone lol [11:51] bzr software [11:51] Try #bzr [11:52] I started using it as a TimeMachine [11:52] ok [11:52] * bugabundo_work checks #bzr === mrevell is now known as mrevell-sprint [12:50] spiv: yup. 3 hours on compilers. Usually it makes sense, but this was programming a bit close to the metal for my liking [13:02] I always liked compiler theory at university [13:03] * wgrant isn't up to such interesting stuff, unfortunately. [13:04] cjwatson: it's certainly interesting...but the code generation part's just a bit...too far. [13:14] Hm, how do I test whether launchpad is now poking ticket updates into my trac? === zookoafk is now known as zooko === zooko is now known as zookoafk === lamont` is now known as lamont === SPS is now known as sps_br [15:04] is this channel to discuss bugs in intrepid too? [15:04] sps_br, No. This channel is to discuss launchpad. For intrepid bugs, you probably want either #ubuntu-bugs or #ubuntu+1 [15:05] persia: thanks, but, isn't launchpad a bug discussion area? [15:06] Launchpad is a suite of software for managing bugs, code, user support, distribution, package building, translations, and lots of other stuff. [15:07] Ubuntu uses most of the launchpad services, including the bugtracker service. [15:07] ah ok, thanks! [15:20] anyone having any issues tonight? It seems to be /really/ slow here... [15:24] Magilla: What actions are you finding slow? General browsing of Launchpad? [15:24] mrevell-sprint: editing my profile [15:25] I'm waiting 60s+ for each page load [15:26] Magilla: It's slow for me too but I'm on a ropey connection right now. Let me check if there are any known issues. [15:26] I started loading the current page before joining the channel [15:26] and it's still going [15:26] Please try again [15:26] Sorry, there was a problem connecting to the Launchpad server. [15:27] Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode. [15:27] hrm [15:27] [15:28] I'm currently trying to finish registration of my gpg key [15:29] Oh, and the instructions on launchpad for setting up a gpg/OpenPGP key are missing a vital piece of information [15:29] Magilla, we're checking to see if there are any problems [15:29] thanks [15:33] hmm, the information seems to be there now [15:33] Magilla, what's missing in the gpg help? [15:33] maybe it was the Bazaar docs that were missing info [15:33] :/ [15:34] whatever setup guide I was following, it said to run gpg --keyserver keyserver.ubuntu.com --send-keys [15:34] but neglected to point out that you need to put the key ID on the end [15:34] Magilla: Performance should be improved now [15:35] mrevell-sprint: thanks [15:35] * Magilla clicks "Continue" [15:35] Magilla, doesn't that command send all of them? [15:35] it didn't do anything [15:35] at all [15:35] just returned me to the cli [15:36] no feedback, and the key never appeared on the server [15:36] epic frustration until I found another howto [15:36] Magilla, I'll look into it and get the wiki corrected [15:36] thanks for the tip [15:37] beuno: I've had another look at the docs, and it appears to be there [15:37] (now, at least) [15:37] ah, cool [15:37] the failure may have been on the Bazaar site [15:37] I'll try to find it and let them know [15:37] thanks for the help [15:41] Ah, I remember what happened [15:42] in the profile, where you add your key, it says to do this: [15:42] gpg --send-key key-id [15:42] but I couldn't figure out what the key id was [15:43] it just didn't work [15:43] beuno: LP seems to be broken. [15:43] I didn't realise you shouldn't use the 1024/ prefix before the key [15:43] Completely. [15:43] Hmm. [15:43] Got a request through then. [15:43] But it's slow and intermittent. [15:44] so I went looking for other howtos, and thats where I got the other command, but it omitted the key-id bit [15:44] * wgrant waits for kwwii to complain. [15:44] Dear god. [15:44] Launchpad is very sick. [15:44] wgrant: nahhh, I was going to wait 5 min to see if anyone else has problems [15:45] if anything, maybe a quick "this is what your key id is" in there would be great [15:45] kwwii: It's damn slow for me. [15:45] *then* I will scream like only an artist can [15:45] lol [15:45] And I just got 7 alerts on the one page to tell me that I had filed a bug. [15:45] But I haven't filed a bug for hours. [15:45] Something is broken. [15:45] wgrant: well, I cannot even connect "Sorry, there was a problem connecting to the Launchpad server." [15:46] w00t, it finally worked [15:47] http://www.qeuni.net/f/1/2008/repetitive-launchpad.png [15:50] My first bazaar push has successed! [15:50] \o/ [16:02] * nijaba agrees the lp is having speed issues ATM... [16:08] https://launchpad.net/landscape-dev-scripts [16:08] (that link is for rockstar) [16:18] Hmm, bad weather on launchpad today... I'm getting server-side timeouts sometimes trying to edit bugs (returns a 'please try again' page), and when pages do load it takes several minutes. [16:18] yes :( [16:23] ToyKeeper, hi there! [16:23] Gremlins hiding in the latest release? Unusually high load today? Flu going around the data center? :) [16:25] ToyKeeper, it's probably because we're all in London. :) Murphy's Law or something. [16:26] Yeah, must be something which happens whenever you get too close together. :) [16:26] * ToyKeeper saw Hancock, maybe Canonical works the same way [16:28] morning ! :D [16:28] Sorry, there was a problem connecting to the Launchpad server. Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode. Thanks for your patience [16:28] I'm just letting you know :D [16:28] Anyway, I'm probably the zillionth person to mention it, but I figured I should say something just in case. [16:28] awsome work by the way [16:29] cw yeah we're having some disruptions today [16:30] oh and I got pidgin working with intrepid since libpurple0 and libperl were messed up [16:30] we've got folks diagnosing the issue [16:30] just had to manually recompile pidgin [16:30] just fyi [16:31] everythings working great otherwise..and thanks for the response Rinchen, i do aqppreciate that. [16:31] A note in the /topic might help. :) [16:31] no worries cw .. we're all sprinting today in London but our admins notified us of the issues [16:31] so we're diagnosing logs and also beating up the servers to recreate the issue [16:32] lol no probs.. at your own time.. everythings working again for me at least "workable" in a running environment [16:32] i know you probably have your hands full, so I'll just say thanks and let you get back to what-ever it was you were doing to make the world a better place :D [16:32] Rinchen-sprintin, You can't recreate? [16:33] we installed some code on Friday to help us diagnose this odd behaviour [16:33] so we're trolling through new logs and also following up on some suspicions [16:33] persia, not consistently which is darn frustrating [16:33] well if you see my email in the logs.. cw will make sense ;) [16:34] << coder :D [16:34] persia, the moon phase changes and we get data and then suddenly....no problem. [16:34] anyways, you fine people have an awsome morning and thanks again for all your help [16:34] Thanks cw [16:34] Rinchen-sprintin, Ah, yeah. The things that break all work the second or third time for me, which I prefer to not working at all, but I can see how it might be frustrating. [16:34] sorry for any inconvenience. [16:35] I have to get to work. again no probs.. I'm just glad someones "on the ball" so to speak lol [16:35] Take care, I'll check back in later. [16:36] Peace [16:59] Hello! Please take a look at https://help.launchpad.net/YourAccount/Branding?action=diff&rev1=10&rev2=12 and rollback the page :) [17:03] andrea-bs, /+me/ can be useful in URLs [17:03] thanks andrea-bs [17:04] I'll get that fixed and locked [17:04] andrea-bs, Nevermind. Sorry. [17:04] mrevell-sprint, ^^ [17:05] andrea-bs: Thanks for letting us know, I rolled that back already. Strange what some people will put on a wiki page! [17:05] thanks Rinchen-sprintin === zookoafk is now known as zooko [17:29] launchpad slow, make bug day cry... please give the bandwidth [17:30] DBO, we're working on it [17:31] =) [17:31] do you have an ETA on a fix [17:31] because we can get pizza or something while we wait [17:34] go for pizza, we don't want our users to be hungry [17:35] is launchpad down? [17:35] yeah [17:36] well [17:36]