[00:26] hi anyone know why launchpad is so slow [00:26] I am doing a checkout of a project [00:26] and is taking hours [00:27] I get.. Fetching revisions:Inserting stream:Estimate 589932/600665 [00:27] and only 43kbp/s transfer rate [00:30] JZA: Which project? [00:30] And how good is your ISP's connection to London? [00:30] they were supposed to be just scripts [00:30] but is a bit more than that [00:31] https://code.launchpad.net/~openerp-dev/openobject-addons/ [00:31] anyhow, still should take around 20 min, it's been downloading for hours now [00:31] I can downlaod a 1gb movie in 20min [00:31] usually less [00:33] There's a bit of a difference between downloading a single large file from local peers, and downloading a complex VCS tree from another continent, I'm afraid. [00:34] Lots of ISPs have pretty terrible connections to Europe. [00:34] However [00:34] Are you downloading over HTTP or SSH? === thomi_ is now known as thomi [01:30] wgrant: I am downloading from bzr, I guess it would use ssh [01:30] wgrant: who says I am in europe? [01:30] JZA: Launchpad is in Europe [01:30] wgrant: my bandwith is around 10mbps [01:30] And that branch is more than just scripts; it's about 700MB [01:31] JZA: bzr will use SSH if you've used 'bzr lp-login', HTTP otherwise. [01:31] oh [01:32] I'm not quite sure what's in there [01:32] But whatever it is, it's pretty huge... [01:32] wgrant: sucks... [01:32] I wonder why launchad cant zip the whole tree as a tarball [01:35] Normally projects release tarballs/zips themselves, but Launchpad can generate them directly from a branch. http://bazaar.launchpad.net/+branch/openobject-addons/tarball might work, but I don't know how well it scales to several hundred megabytes... [01:36] welll it's definely going faster [01:37] would it only tar the main branch? [01:38] JZA: That's for a single branch, yes. [01:40] I see [01:49] which branch are you downloading? [01:50] and why are there so many branches, sheesh [01:51] dobey: not sure, this was supposed to be only some scripts [01:51] but I guess this have to be compliat for each addon [01:51] what was? what bzr command did you use? [01:51] so they include the addons [01:52] bzr branch lp:openupgrade-addons [01:53] uhm [01:53] that is not openobject-addons [01:54] also, that is one heck of a lot of directories in a bzr branch [01:54] umm... ur right [01:54] too similar names [01:56] anyway, it looks like there also plenty of binary files in the tree [01:56] binary files make the size of the history to be quite large, if they are changed often [01:56] :S [02:00] dobey: actually binary isn't a problem per se; it's files where when they change the majority of the file changes thats an issue - and many binary files have this characteristic (but many don't) [02:00] for instance, running sqlite db's in bzr would be fine [02:03] well, i don't guess this branch is in that category of not having the problem [02:05] because i'm pulling that branch right now, and getting upwards of 7MB/s download at times, mostly it's around 3 MB/s. and it is taking quite a long while to pull it [02:05] it's been going > 10 minutes already [02:07] ah, just finished [02:07] and yeah, it's 898M [02:13] heh [02:13] oh well, it's late === dpm_ is now known as dpm === matsubara_ is now known as matsubara === yofel_ is now known as yofel === BradCrittenden is now known as bac [19:50] cjwatson, above, how do i do that ? [19:51] how does that stuff normally get crated ? [19:53] smoser: precise-proposed bzr branch of package in precise? [19:54] smoser: dput the proposed package to precise-proposed and it should get imported [19:55] dobey, well, well, [19:55] a.) i hope that works. i have very little success with the importer [19:55] b.) that looses interim commits that i wanted to preserve [19:55] s/well, well,/well.../ [19:56] oh. [19:56] c.) when does that occur ? on acceptance into -proposed ? (i've always been confused on that) [19:57] yes [19:57] it should occur when the package is accepted into proposed [19:59] though i'm not entirely sure what the expected interaction of imports is for Vcs-Bzr branches. that's always been a bit confusing === _Hassen_ is now known as Hassen [22:42] how can I automatically close LP bugs from commits? bzr --fixes lp:number only links the branch, doesn't set "fix commited" neither "fix released" [22:44] commits to what? [22:44] anyone can bzr commit --fixes lp:number in any branch; doesn't mean it fixes it in the thing it was reported in [22:46] dobey, how can I close the bug then? I mean, appart from going to the bug itself and manually setting it to fixed. [22:48] philsf: are you using merge proposals as a way of getting changes into your trunk? [22:51] dobey, nope, just merging locally. is that what it's required? === cinerama_ is now known as cinerama [22:53] it is required to use tarmac, which handles merging of branches, and has a plug-in to close bugs as fixed once the code is merged to trunk [22:59] maybe you should just write a script to close the bugs from the command line, using the launchpad api [23:07] https://launchpad.net/bzr-tarmacland ? [23:07] I can't find a package, with apt-cache search [23:10] my google-fu is failing me: I also can't find documentation on how to use it [23:30] lp:tarmac is tarmac [23:30] it's not packaged in ubuntu yet [23:30] i don't know what bzr-tarmacland is [23:31] it seems to be a plug-in useful for developers of launchpad itself [23:32] not generally useful to other people [23:44] oh, ok [23:46] dobey, what about "fix commited" -> "fix released"? I often see automatic LP comments in ubuntu bug reports, that a bug was fixed in a given release. How can I do that? [23:47] that is only in the packages in ubuntu [23:47] dobey, is it sufficient to include a "Closes: LP:number" in the pacakge changelog? [23:47] you need to do it manually for upstream releases [23:48] oh, that's a pitty. thanks for the info, anyway