[00:10] thanks for your help guys, night === bjf is now known as bjf-afk [01:28] mwhudson or thumper, ping [01:30] mars: i [01:30] hi === bjf is now known as bjf-afk [01:31] hi mwhudson. Would you happen to have a moment to help debug a failing test I have? [01:31] I need someone else to verify that it fails on their system [01:34] mars: sure [01:35] mwhudson, thanks. Could you please tell me if this fails: [01:35] mwhudson, xvfb-run -s '-screen 0 1024x768x16' bin/test -t test_newly_linked_branch_diff_popup [01:35] mars: hang on, updating devel [01:35] I assume you have xvfb installed. If not, then just drop that part. [01:37] mars: ok, running [01:43] mars: bah, need to run make schema [01:43] boo [01:43] that is really annoying :) [01:44] I wonder if it could be made to fail earlier [01:44] 'make check_schema' [01:44] I've had that happen many times [01:54] confirm_dbrevision_on_startup() seems to do all the work to raise a database revision error. How to get that function into a script... [02:01] mars: anyway, that test passes for me [02:01] mwhudson, perfect, thanks for the help. [02:07] * wgrant wonders why make clean decides to obliterate a whole lot of data directories. [02:19] lunchtime [02:30] need help: error in make schema Missing ./download-cache. [02:30] Developers: please run utilities/link-external-sourcecode. [02:30] make: *** [download-cache] Error 1 [02:31] i got this error while building a pristine trunk (devel) instance [02:32] dhastha: a pristine trunk doesn't have all the external code that is needed. per the message, (i guess...) run utilities/link-external-sourcecode [02:34] i am getting error while run utilities/link-external-sourcecode [02:35] spm, Invalid line at line "4". [02:35] Invalid line at line "7". [02:36] bzrlib.errors.ParseConfigError: Error(s) parsing config file /home/dhastha/.bazaar/locations.conf: [02:43] spm, how to rectify those errors? [02:43] dhastha: I'd suggest you look at the file suggested and see why that appears broken as a 1st step. ? [02:57] dhastha: have you followed the setup instructions on the dev wiki? [03:37] heh [03:37] i can tell the uk is in summer time now, i'm getting mails from the future about bugs [03:38] That's still not fixed? [03:39] Bug #262040 [03:39] Bug #262040: Bogus timestamps on some unbatched bugmail [03:40] hey look i commented on that bug roughly a year ago [03:40] what are the chances [03:41] Heh heh. [04:14] spm: Has the PPA process-accepted.py gone and died again? [04:15] i hope not... [04:16] spm: Ah, no, just very late. [04:17] where does that one run again? soyuz is a mini nightmare of odd corners and crontabs... [04:18] It's germanium. Some of my binaries appeared 5 minutes late, but they did appear. [04:18] cron.publish-ppa on germanium. [04:18] bleh. that'd be right. i was on cocoplum and cesium. [04:18] Heh. [04:20] now if only i could find which of the 6 users it runs under... /me gives up and looks for a logfile for clues [04:21] lp_publish [04:22] is that called by something else then? cronscripts/publishing/cron.publish-ppa cronscripts/publishing/cron.daily-ppa scripts/process-death-row.py and keys and htaccess [04:23] are the only tasks of note that run [04:23] cron.publish-ppa calls process-accepted.py. [04:23] ahh there it is. the 1st. yup [04:24] one of the "possibilities" for our sprint coming up; is to drag eg Julien by the ear and nail him to the floor until he completely explains the entire soyuz "WTF" and how it "works". [04:25] Hahaha. [04:25] '"works"' is right. [04:25] with diagrams, if we're feeling really vindictive [04:26] https://wiki.ubuntu.com/CelsoProvidelo/SoyuzInfrastructureOverview but worse :P [04:31] there are already diagrams! [04:31] some of them may even be accurate [04:32] * spm is NOT game to click on that link before breaking for lunch. maybe after. and after I've digested. but not before. [04:34] wgrant: what was the oops that you needed looked at in the weekend ? [04:35] spm: Refreshing https://edge.launchpad.net/~wgrant/+archive/openttd/+build/1654520 regularly shows that shipova is being dodgy and keeps dropping the build (note the fluctuating start time). Can you marks shipova not-OK or something? I've seen others complaining about this one over the past couple of weeks too. [04:35] lifeless: Good point. [04:35] wgrant: not sure I can; one sec... [04:36] spm: https://launchpad.net/builders/shipova/+edit; uncheck the OK checkbox; save. unless you mean policy-wise. [04:37] policy/perms wise; looks like I can. see if that stops it [04:38] and is now showing disabled with a nice message as to why :-) [04:38] Great. And my build is going OK. [04:38] Thanks. [04:38] \o/ [04:38] I knew there was a dodgy builder around, but hadn't managed to work out which. [04:39] spm: Also, do you know why cocoplum OOPSes aren't syncing to the OOPS viewer thingy? [04:39] There are some interesting cocoplum OOPSes which cannot be viewed. [04:42] wgrant: I'ev just done a full manual sync - see if that works? [04:42] * spm afks for coffee... brb [04:42] thumper: were you asking for http://pythonpaste.org/webob/ earlier? [04:43] yeah, but found it elsewhere, thanks [04:43] :) [04:43] mwhudson: do you know if it has taken over as the prime development from paste? [04:43] thumper: i think so but i don't know so [04:44] it's only a replacement for bits of paste aiui [04:44] * wgrant is interested in OOPS-1553FTPMASTER11 and OOPS-1553FTPMASTER16 [04:44] Maybe they will exist now. [04:45] seems not [04:45] Grrr. [04:49] * spm has a look on the filesystem... [04:50] wgrant: when were they generated? [04:50] roughly? [04:50] actually - roughly to "which day" would work.... :-/ [04:51] i can't even see how you'd get an oops prefix like that [04:51] Actually, now I think about it... [04:51] because for the days of the 5th, 6th and 7th of April, there is only 1 oops. 81309.FTPMASTER1 [04:51] While the OOPS prefix was FTPMASTER... [04:52] The log was from a process that runs on cesium. [04:52] Ah ha! [04:52] * wgrant gives the production configs an A+ in confusion. [04:53] It was Friday or so, IIRC. [04:53] :-) [04:53] I think I can see why the oops *may* not show up. drwx------ 6 lp_buildd lp_buildd 4096 2010-04-02 14:28 lp_queue/ <== oops dir on cesium [04:54] Heh. [04:54] bingo. there they are. [04:54] all their perms are crap too. /me envisages another bug report for tdoay [04:56] lalalala that's not Soyuz any more lalalala [04:57] funky umask? [04:58] not likely - we've seen too many cases of these shenanigans before acorss all parts of LP to blame umasks; but I will check. [04:59] btw, have we ever mentioned how much we hate the twisted 1Mb log rotation evilness? <== grrrrr. [05:00] wgrant: try now? [05:00] spm: I don't actually have access to OOPSes. [05:00] hahaha. thought you did :-) [05:01] ad it still doesn't show. that may need a diogo fix [05:01] :( [05:02] authentication failed for user "uploader" [05:02] DB error - I'd guess it's been fixed since, as there are no more since then. Date: 2010-04-02T13:38:29.286748+00:00 [05:02] wgrant: OperationalError: FATAL: Ident authentication failed for user "uploader" [05:03] Ah, great. Thanks. [05:03] I didn't think it had happened since, but there appeared to be quite a few that day. [05:03] post rollout; and I'd suspect no one informed us of the new DB user in advance. Or we missed it. :-) [05:13] wgrant: what *&^%*&ing process/script generated those oops? I'm guessing cronscripts/buildd-queue-builder.py ? [05:14] spm: buildd-manager. [05:14] buildd-queue-builder is one of four scripts which do the job that buildd-manager does. [05:14] Oh ho ho. the daemon itself. [05:14] But it is way obsolete. [05:14] Oh, wait. [05:14] No. process-upload.py, launched by buildd-manager. [05:14] It will soon be buildd-manager itself, but not yet. [05:15] ahh; kk. thanks! [05:16] I think I will stop trying for accuracy or precision where soyuz bugs are concerned and just go with "it's broken. pls fix" reports. [05:16] testfix? [05:16] grr [05:17] spm: buildbot kickage pls [05:17] mwhudson: it says wrong python used [05:17] mwhudson: do you know what is going on? [05:17] damn. new there was a reason I wanted to stay logged onto prasé [05:17] thumper: yes [05:18] mwhudson: kicked [05:18] thumper: buildbot is fixed, it needs a restart and a force [05:20] spm: kicked or restarted? [05:20] restarted type of kicking [05:20] spm: thanks [05:22] mwhudson: my big branch passed all tests, and is on its way to landing on db-devel [05:23] thumper: woo [05:27] oh ffs, pqm still thinks it needs testfix [05:27] how do I smack it around? [05:27] sudo spm fix! <== probably [05:30] sudo spm fix plz [05:31] plz. command not recognised [05:32] thumper: ?? waterfall looks good? or are you referring to db_devel? [05:32] yes [05:33] it looks like buildbot-poll should be moving out of testfix [05:33] ah yup. we're in failure according to the pqm configs [05:33] thumper: when did you get the failure from pqm? [05:33] oh [05:33] silly pqm configs [05:33] mwhudson: after it was booted [05:33] spm: any log files to say why? [05:33] that hsould sort itself every 5 mins. hrm. wonder if just forcing a build should clear it? [05:35] Starting buildbot-poll at Wed Apr 7 05:34:35 BST 2010 [05:35] Builder lp at http://lpbuildbot.canonical.com:8010 failed building r10635 [failed shell_7]. [05:35] Builder db_lp at http://lpbuildbot.canonical.com:8010 succeeded building r9202. [05:36] so i read that as devel is the cause; and a build is underway to rectify that as we speak. ??? [05:36] oh right [05:36] that sort of makes sense, the tip of devel did fail to build [05:37] yup [05:37] i wonder if there's a way to fake it [05:37] so I have to wait then? [05:37] we could kill the current build and then force a build [05:37] meh [05:37] * thumper goes to guitar lesson [05:37] well the script that generated the above is run every 5 and is more or less getting it's status from the 'last build - I believe. and setting the failure/success mode accordingly. [06:29] wgrant, Did you say that process-accepted is dying again? [06:29] cody-somerville: No. It was just being slow. [06:33] hmmm... yea, I see at the tail of the cron.ppa.log that it failed to grab the lockfile several times. [06:34] What was it doing in the previous runs that took so long? [06:35] p-a normally takes <20s, AFAICT. [06:35] I guess a couple of big PPA index regenerations could easily throw p-d over 5 minutes, but I don't know of any PPAs that big. [06:38] looks like a bunch of nightly builds. [06:38] They must be huge. [06:38] Even chromium was only a couple of hundred MiB last time I looked. [06:41] Looks like there is a bunch of PoolFileOverwriteError exceptions that cause numerous PPAs to be processed each run. [06:41] And the fact that the publisher seems to publish suites and pockets that aren't even dirty probably doesn't help. [06:41] Bug #387049 [06:42] Bug #387049: Copy backend does not detect file conflicts [06:42] They must be dirty -- maybe they have pending deletions? [06:43] Domination is probably also significantly slower than it needs to be, but I have a simple fix for that. [06:43] Source domination, that is. [06:45] Looking here, an entire second per PPA is eaten processing suites and pockets that don't exist in PPAs at all and/or probably don't exist in that specific PPA. [06:45] In which step? Domination? [06:46] Step A: Publishing [06:46] Hmm. [06:46] Bad queries must be bad. [06:47] I see here a PPA that had nothing to be published and it took 2 seconds just for the publishing step. [06:47] I've almost fixed B and C', but I've not looked at A yet. [06:48] I wasn't aware that it took long at all. [06:50] On average, it looks like it takes half a second per file that actually has to be published plus a static 2-3 second overhead. [06:51] I know the indices on the publishing tables are stupid. [06:51] Maybe most of that overhead is just initial query time. [07:57] morning [07:58] is it normal for rocketfuel-setup to use mor than ~300 meg ram? [07:59] its eating trough all the ram on my virtualbox system getting killed eventually [07:59] underdrk: That's probably bzr. [07:59] noodles775: Morning. [07:59] wgrant: yup [07:59] noodles775: I need Soyuz acks on four MPs, when you have a moment. [08:00] so, what is bzr doing that it needs ~300m ram? [08:00] underdrk: Not sure. [08:00] shoudn't it just download and store stuff on disk? [08:00] Hey wgrant, jkust on the phone. Will look in a tick. [08:01] underdrk: Probably. But the LP branches are a little ancient and special, so may be causing some interesting behaviour. [08:01] noodles775: No urgency. Thanks! [08:01] wgrant: hmm, thats a pitty [08:02] ill see if I can make it download an a machine with more ram and then scp it into my virtualbox [08:02] underdrk: Your VM has only a few hundred megabytes of RAM assigned? [08:03] assign some more swap and see if that helps it continue; vs dying. hopefully without io thrashing as well. ??? [08:04] I don't like your chances of running much of LP with <1GB on i386, or much <2GB on amd64. [08:05] heh; given I just killed a 4Gb of memory importd that was running away a tad; yes; agreed :-) [08:05] spm: Linux as usual? [08:05] ruby actually; but not a bad guess. [08:05] Ah. [08:06] we have 3 nasties: linux kernel; gcc and ruby. [08:06] gcc shouldn't be so bad since incremental bzr-svn was deployed a week ago, right? [08:08] Ah, yes, it's even finished its initial import now. [08:08] oh cool. was just updating the related bug report; and noted that gcc was the 3rd of the triumvirate of pain, so :-) [08:09] good morning [08:10] hi :-) [08:18] Hm: http://forum.biosinteractive.com/viewtopic.php?f=5&t=7&p=28#p28 [08:18] People are not happy with Launchpad. [08:22] wgrant: for a development platform yes, I'd hope half a gig would be enough [08:23] but, ill mount some more swap [08:51] jelmer: Morning. === almaisan-away is now known as al-maisan [09:05] noodles775: Thanks for those. [09:05] wgrant: thank you :) [09:06] buildd-manager is a whole lot more understandable after that lot. [09:06] Yeah, it's great seeing the code continually improved! [09:22] So, I have a branch that removes 9500 lines of unused code. [09:23] ! [09:24] That seems to violate the 800 line rule by a little bit. [09:35] Hi [10:12] how do I find out if PQM is in textfix? [10:18] need help: error occuring while running ./utilities/link-external-sourcecode ~/launchpad/lp-sourcedeps [10:19] Wanted to link /home/dhastha/launchpad/lp-sourcedeps/download-cache to ./download-cache but source does not exist [10:19] james_w: if there's an email to the mailing list with a test failure and pqm rejects your requests, while its error message mentions requiring [testfix] [10:19] dhastha: hi [10:20] jelmer, hi error while installing launchpad locally [10:20] dhastha: how did you create lp-sourcedeps? [10:21] jelmer: yeah, I got rejections, I want to know if it's safe to submit again yet. [10:21] jelmer, after run rocketfuel-setup [10:21] Odd. buildbot merged 20 minutes ago. [10:21] Which suggests that thins weren't too unhealthy. [10:23] dhastha: perhaps rocketfuel-get fixes it? [10:24] jelmer, after run rocketfuel-get i got lp-branches and lp-soucedeps files automatically [10:26] jelmer, sorry i run rocketfuel-setup only, i don know about rocketfuel-get [10:26] wgrant: so it's probably ok now? [10:26] I got rejected some hours ago [10:26] dhastha: did rocketfuel-setup interrupt halfway through? [10:26] james_w: Ah, if it was that long ago, then go for it. [10:26] ok [10:26] anyone know how to land skipping ec2? [10:27] I just did "ec2 land", but it seems wasteful to run the tests again? [10:27] jelmer, no error in rocketfuel-setup [10:27] james_w: use "bzr lp-land" ? [10:27] jelmer, there is no error in database-setup also [10:28] james_w: you can't tell if we're in testfix, it really sucks [10:28] (there's a bug report, but i don't have any ideas on fixing it) [10:29] jelmer, error starting in make schema === daniloff is now known as danilos [10:33] what's PQM's address for LP? [10:33] (I have searched dev.launchpad.net for all this, but I couldn't find it) [10:35] james_w: Heh heh, I had exactly the same problem about a week ago. [10:36] pqm_email = Canonical PQM [10:36] Bah, jelmer! I was about to paste that === jtv is now known as jtv-otp [10:37] jelmer, download-cache folder is not available in my lp-sourcedeps folder so only error occuring. isn't it? [10:37] dhastha: yeah, I wonder what went wrong there. What happens if you run rocketfuel-setup again? [10:37] dhastha: it should be taking care of creating lp-sourcedeps [10:38] dhastha: Does lp-sourcedeps contain anything at all? [10:38] If it doesn't contain any significant volume of data, remove it and run rocketfuel-setup again. [10:39] jelmer, eggs, sourcecode two folders only are there [10:41] wgrant, k === jtv-otp is now known as jtv [10:49] dhastha, hi, is wgrant's suggestion helping? [10:50] danilos, i removed all the datas and trying once again [10:55] dhastha, cool [11:01] Morning, all. [11:50] LP rollouts are the third thursday of the month, right? [11:51] It depends. [11:51] This is a 5 week cycle (hence this is week 0) [11:51] persia: See https://dev.launchpad.net/Releases/2010Calendar [11:51] (no, there is not a release the day before Lucid) [11:51] Oh, perfect. THanks. [11:53] oh, we are in a week 0? [11:53] groovey [11:53] * wgrant points at /topic [11:54] (although I set it) [11:56] danilos, Permission denied (publickey). [11:56] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [11:57] danilos, same error [11:58] dhastha, what do you have in ~/launchpad? and what user did you run rocketfuel-setup under? [11:58] dhastha: You don't have your SSH key registered with Launchpad? [11:58] wgrant, he does [11:59] dhastha: What does 'bzr launchpad-login' say? [12:00] rocketfuel-setup file only i am having in ~/launchpad. while i run i am getting that error. but am having ssh key registered [12:00] dhastha, perhaps it's related with the keyserver, can you try changing it as suggested on https://dev.launchpad.net/Getting: [12:00] ## Sometimes the keyserver from Ubuntu doesn't respond, especially on Karmic [12:00] ## Try changing keyserver.ubuntu. to pool.sks-keyservers.net [12:00] danilos: That's for OpenPGP keys. [12:00] This is an SSH key problem. [12:00] wgrant, right, dumb me [12:01] dhastha, ok, so the only thing I can suggest is to make sure whatever environment bzr gets executed in, it has SSH_AGENT env variables properly set (i.e. don't run it with sudo options where it unsets some of these "unsafe" variables) [12:06] danilos, making local branch of launchpad trunk. bzr: ERROR: [Errno 13] Permission denied: '/home/dhastha/.bazaar/bazaar.conf' [12:07] danilos, finding revision going on [12:07] dhastha, ok, you'll probably have to revert those privileges to your own user using something like "sudo chown -r dhastha.dhastha /home/dhastha/.bazaar" [12:08] And be sure not to run rocketfuel-setup under sudo in the future. that's not right [12:10] that was my fault, I suggested it might be needed [12:16] jtv: Is your soyuz-sampledata-setup failure fixed by my sampledata reversion yesterday? [12:16] jtv: Its output was accidentally added to the sampledata a couple of weeks ago. [12:16] wgrant: that's what I was hoping for yesterday, but unless I was less up-to-date than I thought, it doesn't seem to help. [12:17] wgrant: oh wait, did you end up landing that on db-devel or not? [12:17] jtv: It landed on db-devel a couple of days ago, and on devel a little over 24 hours ago. [12:17] devel r10627 [12:17] db-devel r9194 [12:18] wgrant: it may be a "missing link" in how the revisions flowed on this system... I'll try again. === mrevell is now known as mrevell-lunch === matsubara-afk is now known as matsubara [13:32] gmb, I think we should make Bug #557252 a priority. Seems a simple fix with many gains. Would you agree? [13:32] Bug #557252: Creating CalculateBugHeatJob is very slow [13:33] deryck, I just triaged it as medium :). But if we've got someone to spare to fix it then yes, we should deal with it, if only to make garbo-hourly happier [13:34] gmb, yeah, that sounds fine. === mrevell-lunch is now known as mrevell [14:36] * wgrant loves bugmail from 'Tomorrow 00:32' [14:47] wgrant: http://fts.ifac.cnr.it/cgi-bin/dwww/usr/share/doc/emacs21-common/etc/future-bug [14:48] kfogel: Heh. [14:49] (Bug #262040 is the problem.) [14:49] Bug #262040: Bogus timestamps on some unbatched bugmail [14:59] reviewers meeting starting in one minute [15:16] danilos, are you there? [15:17] Anyone know why PQM is suddenly being very coy about showing details? http://people.canonical.com/~kfogel/images/pqm-opacity.png [15:19] dhastha, yeah === bjf-afk is now known as bjf [15:35] danilos (or anyone): know why PQM is suddenly being very coy about showing details? http://people.canonical.com/~kfogel/images/pqm-opacity.png [15:35] ? [15:36] kfogel: hum, probably submissions for non-LP branches, or something is weird with the PQM configuration [15:37] danilos: no, it's been like this for a while, and I know I had a submission in the queue then. I think the configuration is messed up. What's the best way to report that: RT, or file a bug? [15:37] kfogel: it's probably best to check with LOSAs [15:37] danilos: will do [15:37] kfogel: thanks :) === danilos is now known as daniloff === al-maisan is now known as almaisan-away [16:24] adeuring, Bug 550973 is really just about adding the referrer header exception and a good comment. So I moved it to easy bugs backlog. [16:24] Bug #550973: checkbox should send a referer header when it POSTs data to Launchpad. [16:25] deryck: OK, I know. The exception already exists, BTW [16:25] adeuring, oh, hmmm. So it's landed? [16:26] deryck: yes, as an RC branch, IIRC. But the comment that gary wants is still missing. [16:26] deryck: at least LP receives and prcesses again HWDB submissions [16:26] yeppers [16:26] adeuring, ok. so even more easy then :-) [16:27] deryck: I know; I just wnat to finish this mantis related bug. Otherwsie, I'll never finish that branch, I'm afaid. After that, I'll add this comment [16:28] adeuring, oh, yeah, I didn't mean to imply it should be done now. Just noting that I moved it to a different queue. [16:28] deryck: OK ;) === deryck is now known as deryck[lunch] === salgado is now known as salgado-lunch === gary_poster is now known as gary-lunch === deryck[lunch] is now known as deryck === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado [18:16] hello again [18:21] daniloff, are u there? [18:22] * maxb imagines that the "off" suffix means no [18:24] need help: error occuring while run launchpad locally. make run === matsubara is now known as matsubara-lunch [18:25] dhastha: that is not much detail for anyone to be able to help you with. Please pastebin the error [18:26] maxb, http://paste.ubuntu.com/410637/ [18:27] Hmm, I guess your rocketfuel-setup never finished successfully? [18:28] Do you have a /home/dhastha/launchpad/lp-sourcedeps/download-cache/dist/setuptools-0.6c9-py2.5.egg ? [18:28] maxb, finished successfully. no error found [18:29] maxb, upto download-cache only am having. there is no dist as well as setuptools.0. [18:30] What do you see if you run 'bzr info' in the download-cache dir? [18:31] Bound branch (format: pack-0.92) [18:31] Location: [18:31] branch root: . [18:31] bound to branch: bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/ [18:32] And 'bzr status' ? [18:32] bzr: ERROR: No WorkingTree exists for "file:///home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr/checkout/". [18:32] dhastha@dhastha-desktop:~/launchpad/lp-branches/devel/download-cache$ bzr statusbzr: ERROR: No WorkingTree exists for "file:///home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr/checkout/". === gary-lunch is now known as gary_poster [18:33] OK, run 'bzr checkout' and it should create a dist/ directory [18:34] bzr: ERROR: File exists: u'/home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr': [Errno 17] File exists: '/home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr' [18:36] Hrm [18:36] maxb, bzr checkout returns above error [18:36] Ok, try this: 'bzr unbind; bzr checkout; bzr bind lp:lp-source-dependencies' [18:39] same above error [18:44] maxb: rocketfuel-setup had taken somuch of time to complete [18:45] dhastha: How fast is your internet connection? One option would be to just throw away download-cache and re-fetch it [18:47] maxb, 60kb per sec. How to refetch that particular file only? [18:47] Unfortunately, that branch is huge [18:49] dhastha: Could you please run 'ls .bzr' in download-cache? [18:49] branch branch-format branch-lock checkout README repository [18:50] OK, 'rm -rf .bzr/checkout' and then try 'bzr checkout' again [18:51] no error found [18:51] Great, do you now have dist/ and cmmi/ directories in download-cache? [18:52] Also, please re-run 'bzr info' [18:53] there is no one folder there [18:54] while run bzr info it returns Checkout (format: unnamed) [18:54] Location: [18:54] checkout root: . [18:54] checkout of branch: bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/ [18:54]