pooliepeitschie: maybe ian's names are too cute :)00:58
peitschiepoolie: hehe.  They are awkward to type in doco's thats for sure! ("Please install your... wait... what is the singular of clothes? Outfit? Cloth?")01:03
peitschiepoolie: clothing XD01:05
peitschieI must admit, I do like the direction these things are going.  The next step up for me would be to make the hats & clothing easier to redistribute01:08
peitschiequite a portion of my doc is related to "copy folder A to destination B", because I can't distribute a set of things (clothes, hats & plugins) all at once01:08
pooliei think that's the direction he wanted to take it01:09
poolietowards being something that encapsulates a lot of the setup and policy for a particular project01:09
peitschieyar... that'd be very cool.  Bazaar Explorer is the only tool I know of that is working towards this kind of thing for source control :).  very exciting!01:09
peitschiefor a corporate network / dev environment, it'd almost be nice to be able to point bazaar explorer at a specially structured bzr repository to retrieve these things from01:10
peitschiewould allow automatic versioning, distribution of updates, as well as easy management for multiple projects all at once01:11
peitschie(not that you guys are suffering a shortage of ideas ;))01:11
peitschieIs there anyone around that could potentially cast an eye at https://bugs.launchpad.net/bzr-svn/+bug/882388 for me?05:37
ubot5Ubuntu bug 882388 in Bazaar Subversion Plugin "Fetching svn revision info seems to be very slow" [Undecided,New]05:37
wgzdark dark dark05:58
wgzpeitschie: nothing in particular rings a bell there.06:02
wgzif you can reproduce the 30 revs/min with just the first N revisions,06:02
peitschiewgz: it seems to be very consistent at the moment.  I added some more bits to the bug report though... my HDD is thrashing like crazy at the moment which makes me wonder if this is fsync related06:03
wgzI'd do `bzr --lsprof-file callgrind.out branch svn:...` and attach that.06:03
wgzwould tell you at least who's IO was to blame06:04
wgz^+ -r100 or similar06:04
wgzyou can also try disabling fsync at the bzr level (can't remember what exactly the effect on windows is) with er...06:07
wgzdirstate.fdatasync = false in config.06:08
wgzand repository.fdatasync06:08
peitschiewgz: I'll give those whirl... thanks :)06:09
peitschiewgz: are those branch config options or bazaar.conf options?06:10
wgzthey can be global06:17
peitschiewgz: those haven't seemed to help a lot (as in the HDD still goes crazy, and it isn't faster).  I've spammed the bug with a few callgrind combinations... mmm. Any more ideas?06:22
wgzthat looks like a good set of things for diagnosis06:26
wgzas for workarounds...06:26
wgzbranching from svn on a nix box or older version of bzr if that's faster then branching that bzr copy?06:28
wgzyou could also try putting the svn-cache dir on temp storage06:32
wgzthere seems to be a config option, but setting up ramdisk under windows is a little annoying06:32
wgzor disable the cache entriely.06:33
wgztry use-cache = False in ~/.bazaar/subversion.conf06:34
peitschiewgz: hehe.  I found a fun one that works!  I installed a ram-disk, and moved the svn-cache file onto that = mega faster!06:36
wgzyeah, it looked from the files you posted that your sqlite hunch was right06:40
wgzokay, bus time06:41
peitschiewgz: thanks for your help :)06:42
lifelessthere is a pragma you can set06:46
lifelessin sqlite db's06:47
lifelessto tell them to use a larger page cache06:47
peitschieI suspect its more a transactional thing than a page cache thing though... but if anyone knows the settings I can give it a whirl :)06:48
peitschieas it is, this sucker is flying along quite well with the ramdisk... and once I have a copy I can email that to the other team members I *think*06:48
lifelessheh, they have deprecated it (because apps are meant to set their own I think)06:55
lifelessanyhow, pragma default_cache_size = 4000;06:56
lifelessor some such06:56
lifelessor just hack bzr-svn to issue a cache_size pragma.06:56
peitschiepotentially playing with the synchronous might be fun as well06:56
lifelessthat will need ot be issued from the process using the db07:00
lifelessso hack it into bzr-svn07:00
jelmerwe should really finish the pack-based cache format for bzr-svn, that will fix a whole bunch of issues07:05
redwyre|wis it possible to make a bzr branch/depot read only?07:54
maxbchmod it?08:03
redwyre|wI can't change the file permissions :/08:14
redwyre|wdo you mean just set the readonly flag?08:15
vilahey all !08:20
vilajelmer: I requeued the mutiple tarballs yesterday, AFAICS they all fail: http://package-import.ubuntu.com/status/56c18c6ef2106c8a91a81b26466fa557.html08:22
vilajelmer: some shallow thing may be ?08:22
vilamgz: hehe. hi !08:37
vilamgz: posted a better explanation for bug #880701 in the mp, let me know if it helps or if you need more08:37
ubot5Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/88070108:37
vilamgz: 2.4 full test suite passing again, I'm so grateful for that...08:43
mgzwill have a look at that mp again vila08:46
vilathanks in advance08:47
viladamn, John McMaccarthy too !08:49
vilafullermd: we'll soon be the only ones left ;)08:50
maxbok, who moved all the udd scripts into a bin/ directory and broke stuff? :-/08:53
maxbjml: Hi. There's a problem with moving all the udd scripts into bin/ . They were deliberately using the fact they were in the same directory as the udd/ namespace in order to import from it08:54
vilamaxb: search the history a bit :) I've fixed the fallouts that appeared in production, did you find more ?08:54
maxbhmm, fixed how?08:55
vilamaxb: oh, for interactive use, you need to set PYTHONPATH08:55
maxbthat sucks - before you didn't08:56
maxbI'm likely to MP moving the scripts back :-)08:56
vilamaxb: I suggest you discuss with jml before starting an edit war :-)08:58
vilamaxb, jml: And having more tests for the scripts is likely to help in any case ;)08:59
maxbbzrlib.errors.RevisionNotPresent: Revision {james.westby@ubuntu.com-20110209140824-ftq14u7pfwalt6f2} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".09:01
maxbAm I right in thinking we've not got to the bottom of why that happens?09:02
maxb(branching a precise branch)09:02
vilaobviously :)09:02
mgzcleaning up the lp:udd layout without also adding an install step does seem to have been... disruptive09:02
maxbpleeeeeeeeaaaaaaaaaaaaaaaaase no install step09:02
mgz^which branch maxb?09:02
vilamaxb: oh, that one, yeah, weird, I can't reproduce the failure seen by the importer myself09:03
mgzmaxb: in which case, reverting the bin move may be the best option, can always install *into* bin from root of repo09:03
odin_is there a comment to check if the tree is clean "bzr status ." via exit status ?09:04
vilamgz, maxb: Let's not have this discussion without jml and james_w or we'll run into circles :-}09:04
mgzI was wondering odin...09:04
vilaa discussion on the udd mailing list may help gather all the point of views, pro and cons though09:05
vilaodin_: IIRC there is an opne bug about status not returning a documented retcode.09:06
vilaodin_: but I'm not sure everybody agree about what constitutes a 'clean' tree (with or without 'unknowns' for example)09:07
mgzstatus doesn't seem to return anything in fact09:07
odin_Set also: status-flags  (does this exist anymore?)09:07
mgzit's always 0 or an internal error09:07
odin_then add that as an option09:07
odin_bzr status -q --exclude-unknowns && echo "Tree is clean"09:08
vilaodin_: --strict is used for commit already may be more coherent, care to file a bug or +affectsmetoo the existing one ?09:08
maxbhm, it's looking like oneiric/libraw was damaged, and precise just copied that09:09
mgzmaxb: the branch-distro check log doesn't complain about it, wasn't one of the ones with stacking issues09:10
vilamgz: was this log posted in a bug ?09:10
vilamgz: or did we never get the whole file ?09:11
vila(got ?)09:11
mgzI have a copy.09:12
mgzscped from carob09:13
odin_ok will lookup bug system in a moment, for now I try: wc=$(bzr status . | wc -l); if [ $wc -eq 0 ]; then echo "Tree is clean"; fi09:13
maxbwaiiit. now I can branch precise but not oneiric?09:15
maxbPerhaps a mis-reading by me earlier09:18
maxbBut, bzr 2.3 'bzr check's oneiric, whilst bzr 2.4 fails it09:18
vilamaxb: while you're there (good to see you by the way ;) any issue with the beta ppa or just lack of time ?09:20
maxbjust lack of time. I can probably devote some this weekend09:21
vilathat would be awesome !09:22
mgzcurious parties can see branch-distro-2011-10-14.log in my homedir on jubany for the full log with stacking warnings09:26
maxbuhoh, has bzr 2.4 regressed where accessing stacked repositories containing zero packs?09:30
maxblibraw/{oneiric,precise} have the same last-revision. oneiric is stacked on precise, and oneiric has no packs. Yet I can branch precise but not oneiric09:32
maxbwhereas I *can* branch oneiric on jubany using the bzr 2.3 there09:34
maxbAlso I'm seeing lots and lots of spurious-looking refresh_possible_transports errors09:39
vilamaxb: really ? where ?09:40
maxblogs/packages/libraw, for example09:40
maxbit makes me wonder if the recent changes to broaden the caught exception there have gone a bit too far09:41
vilamaxb: well, if the transport is dropped, there are not spurious, they are supposed to avoid errors while trying to reuse a dead transport09:42
vilabut the fact that there are so may of them makes me wonder about proper tracking of connections for reuse...09:43
vilahmm, may be it's too aggressive indeed as it seems to drop even valid transports...09:43
maxbIn particular "No such file: file-that-does-not-exist" is not a problem with the connection :-)09:44
vilamaxb: http://paste.ubuntu.com/720526/ ?09:46
vilamaxb: the previous 'bzrlib isn't supposed to raise this error, but it does' comment when catching errors.PathError was a bit misleading no ? ;)09:48
vilaMerwin: I've got a fix under review for bug #88070109:52
ubot5Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/88070109:52
MerwinHi vila!09:53
mgzokay, other tasks done, I will now bang my head against vila's conflicts code09:59
vilamgz: make some tea first ;)09:59
Merwinvila: Nice work ;)10:01
mgzargh, speaking of conflicts...10:01
mgzwere it not for release-notes I wouldn't even know what a conflict was10:01
mgz...okay, that's a slight exageration10:01
vilaMerwin: thanks, that was a really hairy bug10:01
vilamgz: bzr help conflict-types ?10:02
vilamaxb: ping ?10:03
spivmgz: improve news_merge then ;)10:06
vilaspiv: hey !10:06
vilaspiv: news_merge works pretty well in general, the issue to have it correctly configured (but you know that ;)10:07
vilas//is/ somewhere10:07
mgzor at all I think, with pqm10:12
mgzokay, and ...I can't get this conflict locally, what was pqm's issue10:15
vilamgz: and you don't have the news_merge configured locally ??10:15
* vila blinks10:16
mgzokay, I'm mystified10:19
mgzand pqm doesn't give me any more information apart from:10:20
mgzExecuting star-merge http://bazaar.launchpad.net/~gz/bzr/lru_cache_refactor at Thu Oct 27 09:59:03 201110:20
mgzConflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt10:20
maxbvila: pong10:28
vilamaxb: nm, I wanted feedback on http://paste.ubuntu.com/720526/ but it's quite trivial10:29
maxbah. looks superficially fine, and as I presently on a bus, I don't have easy access to additional context10:32
maxb* I'm10:33
mgzreviewing diffs from a bus is impressive in itself10:38
vilamaxb: hehe, don't worry, enjoy your ride ;)10:45
mgzokay, getting somewhere understand merge11:00
vilamgz: great, that's a very tricky area with ramifications11:01
mgzvila: posted review, lunch lunch11:33
vila1) thanks ! 2) good idea !11:33
vilamgz: thanks for the review, I've replied, we can discuss here to reach an agreement if you want12:27
vilasomething weird seem to have happened to the chromium-browser import... it lloks like it has been restarted? at  Time (UTC): 2011-10-27 04:52:29.428890 ???12:31
mgzvila: review responses look fine to me12:43
vilaha, good, thanks !12:44
vilamgz: good to land then ?12:45
mgzhm. ideally I think someone else should have a chance to look at it as well, but we are a little short of someones currenty12:51
vilayeah :-/12:52
vilaNow, I think the risk is pretty low there,12:52
mgzespecially as its 2.4 targetted and we're overdue a 2.4 release, landing this is a little uncertain12:52
vilaI'm not adding a new kind of conflict, I'm refining a case with exceptions that were leading to a malformed transform12:53
vilawhich partly explains why the fix itself seems so obscure12:53
vilayeah, 2.4.2...12:54
vilaI'm one the biggest fan of timely releases but I feel this one could be delayed until after UDS (unless you've seen an unusual number of bug reports for 2.4.1)12:55
vilaI'm a bit more pro-active than usual when it comes to conflict/resolve related bugs as they generally mean some user is blocked12:56
vilaand this fix will help a lot of people encountering first-level parallel import issues,12:57
mgzyeah, I think the targetting is good12:57
vilaI also suspect these are generally not reported as people may feel they were at fault since it occurs only when you add the same file in two different branches12:57
mgzI'm just wondering whether releasing a 2.4 version with this, right now, is a good idea12:57
mgzI'd prefer not to delay till after UDS, but obviously I'm not the one who's doing the work12:58
vilaoh, if I were to release 2.4.2 today, I probably won't land this12:58
vilaon the other hand, without a release, few people will be able to test it12:58
jmlmaxb: I thought vila fixed that yesterday12:58
mgzwe just said on the list of a couple of people who's bugs we fixed in 2.4 that we'd release this week12:58
vilamgz: so, land on trunk ?12:58
vilacrap, missed that12:59
mgzvila: in the mgz ideal world, release 2.4.2, land merge fix for 2.4.312:59
vilamgz: ok, so.... 2.4.2 freeze time I guess :-{12:59
vila.me nods12:59
* vila nods (hehe typos in irc commands now)12:59
maxbjml: vila's worked around it by adding PYTHONPATH in places, but formerly there was no requirement to set PYTHONPATH to make the scripts work12:59
mgzjml: basically running from source got a bit more annoying I think, it's certainly possible to do13:00
jmlmgz: there are tricks we can do to work around it. I think the separation is worth it for code discovery.13:09
* jml → meeting13:09
exarkunWhy can't I branch http://svn.twistedmatrix.com/bzr/Twisted/branches/halfclose-tls-5341 ?13:17
vilamgz: finding bug #839461 again, mentioning it so you can update your in-brain-bug-db ;0)13:23
ubot5Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/83946113:23
vilamgz: to be clear, I'm not suffering from it right now, just read it again in releasing.txt13:24
exarkunWhy does bzr need over 2GB of memory to make this branch?13:27
exarkunjelmer: is the reason newer versions of bzr-svn are "more efficient" is that they use a ton of memory instead of a ton of time?13:31
exarkunup to 2.8GB, which is almost 6x as much memory as this machine actually has, so I guess this operation will never complete, will probably get OOM killed, and I suppose that's why I can't check out that branch.13:32
mgzexarkun: how much of that is the sqlite cache and how much is python?13:32
exarkunmgz: is there an option to `top´ to split up like that?13:32
mgzvila: right.13:32
mgzexarkun, no it's all in-process so basic nix tools won't help unfortunately.13:33
exarkunHow would I answer that question, then?13:33
mgzfinding the cache dir and looking at it should tell you the basics though13:33
exarkunthe cache dir has two kinds of database in it13:34
exarkunThe sqlite3 database is only 51MB13:35
exarkunSo I hope the sqlite3 cache isn't a lot larger than that13:35
mgzthat sounds reasonable indeed.13:35
mgzthe other one isn't huge either I take it?13:35
mgzprobably just having the whole tree in memory or something instead then13:36
exarkunThis wasn't a problem before I upgraded to the latest bzr-svn13:37
exarkunI could actually check out branches, though it took 5 minutes.13:37
mgzfile a bug, 2.8GB is clearly bad13:37
mgzI'd suggest getting a meliae log of all objects as well, but that's unfortunatly not straight forward13:39
exarkunhttps://bugs.launchpad.net/bzr-svn/+bug/191731 seems related, though it was filed 3 years ago13:39
ubot5Ubuntu bug 191731 in Bazaar Subversion Plugin "Memory problems prevent branch of very large svn repositories" [Medium,Triaged]13:39
mgzhappened to look at that earlier today, nothing left there but general bzr problems with big branches13:40
mgzI'd file a new one, as this is a regression from your upgrade13:40
exarkunfiled <https://bugs.launchpad.net/bzr-svn/+bug/882578>.  seems somewhat anemic.  I don't think I can get a meliae log.  Maybe I can try if the problem isn't reproducable elsewhere.  Anything other information you'd suggest adding?13:49
ubot5Ubuntu bug 882578 in Bazaar Subversion Plugin "Too much memory used when branching" [Undecided,New]13:49
mgzwell, knowing if downgrading bzr-svn would be useful (to you as well, if that means you can branch again)13:51
mgzand a .bzr.log extract is always worth it13:52
mgzotherwise seems find as a symptom-bug13:52
exarkunOkay.  Thanks for the help.14:02
mgzvila: thanks for the 2.4.2 release!14:13
vilahehe, looks like your nudge was the right trigger to make it quickly (or quicker than usual at least) ;)14:13
vilawoohoo we can compile the bzr extensions on jubany :-D14:34
mgzthat was fast. I wondered if asking for the bzr build deps was a bit much, given the junk we pull in to do pretty docs and such like14:37
vilaeasier to express :)14:37
vilathe idea was that even old build deps should be enough and I didn't need to list them either14:38
vilanow, if chromium-browser would finish (or at least say *something* in its log...)14:39
vilaI smell something weird going on there...14:39
vila... but top reports it's happily crunching on something memory even (but less than the observed maximum), the CPU goes up and down (so IOs somewhere ?)...14:41
bigjoolscan anyone help with an svn import weirdness please?14:41
bigjoolstaking massively longer than normal14:42
* bigjools hopes jelmer is around today14:43
bigjoolsDarxus: this is a better place to ask as it's essentially a bzr thing. I hope someone replies.14:45
DarxusThanks.  Can you paste me the question?14:46
vila<bigjools> can anyone help with an svn import weirdness please?14:47
vila<bigjools> https://code.launchpad.net/~vcs-imports/spamassassin/trunk14:47
vila<bigjools> taking massively longer than normal14:47
vilanothing obvious (not already mentioned in #launchpad) comes to mind14:47
bigjoolsvila: I PMed him P)14:47
vilaha, sorry14:47
DarxusThe other weird thing is that the last automated daily build attempts from that import failed to upload:  https://launchpad.net/~spamassassin/+archive/spamassassin-daily/+recipebuild/107643/+files/upload_3002271_log.txt14:48
bigjoolsDarxus: that is symptomatic of a change in the repo such that it's trying to build the same version with different source files14:48
bigjoolswhich is forbidden in archives14:48
bigjoolsthis ties in with the long running import - it's almost like the import address is pointing somewhere else14:49
vilawag: the change is the svn repo was... changed in a way that makes bzr-svn *slowly* re-process a lot of stuff14:49
DarxusThe version is 3.4.0-0~{revno}.  You're saying somebody altered the repo without incrementing the revision number?14:49
bigjoolslooking at the last revno, something odd has happened14:50
=== yofel_ is now known as yofel
Darxusbigjools: What are you looking at?14:51
bigjools"determining revisions to fetch 0/1189081" versus "fetching svn revision info 4603/1135013"14:51
DarxusAh, the last import log?14:51
bigjools1189081 on old imports, 1135013 on the slow one14:51
bigjools30k revisions disappeared?14:52
vilabigjools: could it be that the cache was cleared ?14:52
vilabigjools: jelmer didn't deploy a new version recently (as in pst hours or days) AFAIK14:53
vilabigjools: or could it be that such a new version were deployed as part of an lp deployment ?14:53
bigjoolsI have no idea14:54
bigjoolswe roll out new stuff every day14:54
vilabigjools: and about the svn cache ?14:55
bigjoolsno idea :(14:56
bigjoolsI know less than nothing about code imports14:57
vilabigjools: tsk, tsk, that's still more than me ;)14:58
DarxusThanks for looking into it.  I'm not in a rush.  If jelmer hasn't popped up when I get back on in an hour I'll probably email him and open a bug against launchpad like last time :)14:58
vilabigjools: for example, do you have an idea about whether this cache is local to 'pear', 'neumayer' and 'galapagos'14:58
bigjoolswell it's currently running on galapagos, which it hasn't lately, so .... :)14:59
vilabigjools: and whether galapagos may be a newer player here (and as such... see ? :)14:59
vilalet's wait for jelmer then, sry Darxus !15:00
Darxus2011-10-27 14:59:47 INFO    copying revision:fetching svn revision info 1/112931315:01
Darxus2011-10-27 15:00:12 INFO    copying revision:fetching svn revision info 1/112928615:01
DarxusThe total number of revisions is decreasing.15:01
DarxusI was going to try to calculate when it would be finished, and it... didn't cooperate.15:01
DarxusI think there's something wrong :P15:02
mgzdid anyone state what version of bzr-svn is on the buildds?15:05
vilaDarxus: hehe, on the other hand, it's better than having revisions disappearing from the svn repo ;)15:07
vilaDarxus: for now, I'll bet on a local cache being populated15:07
vilaDarxus: the slowness is disconcerting though15:07
mgzif it's the same version as peitschie or exarkun were complaining about earlier (for different) that may be relevent15:11
vilamgz: I had some feeling that may be the case but didn't closely follow your discussion with exarkun15:13
vilamgz: but didn't he used a very recent version ?15:13
mgzyes, and the buildds were on a much older one.15:14
mgzbut I don't know what they're currently running.15:14
vilabigjools: did the buildds use the same code as the code importer ?15:14
bigjoolsvila: same code in what regard?15:15
vilabigjools: bzr-svn15:15
bigjoolsvila: probably not but we'd need to check to be sure.  The buildds don't get rolled out with the rest of LP15:17
vilabigjools: and the code importer is part of lp right ?15:17
bigjoolsthere is a new one waiting to go out actually, lamont is doing it soon15:17
odin_how might I script some actions ... checkout a sub-branch (use the current branch name, append some fixed label, check it out), then rebase the sub-branch on the master, add/commit, then checkout the original branch ?15:17
odin_current branch is lp:foobar/master  so I want lp:foobar/master/ubuntu-lucid  (but this only has a 2 line patch difference between it and lp:foobar/master so I want it to rebase itself everytime master is committed and pushed)15:18
mgzodin: I suggest looking at the python api rather than trying to do it in shell script15:19
vilaodin_: why simply merge master instead ?15:20
vilaodin_: why *not* simply merge master instead ?15:20
mgzbut I wonder if there isn't a better way of working on distro branches than your proposed way there15:20
odin_unfortunately I only do C/C++/Java/sh/perl no ruby no python15:20
mgzthere are a lot of existing tools for making that kind of maintanance easy, though I'm only just starting to learn them myself15:21
vilaonce your branches are setup, it's will just be: bzr merge ; bzr commit -m 'merge master' ; bzr push15:21
vilaodin_: also, lp already handle the namespace for you if you're dealing with ubuntu releases15:22
odin_so I change to recipie to be 3 stages, main project (git mirror) lp:foobar-git-mirror, nest debian lp:foobar/master debian, merge lp:foobar/master/ubuntu-lucid debian ?15:22
vilaha, recipes :-/ I should *really* look into them15:23
odin_the main project does nto know about package management, and is check out into "/" and then recipe checks out  lp:foobar/master into subdir "/debian"15:23
odin_so I need the merge to take place inside the subdir "/debian" as well15:24
odin_since it only applied to the package management control files15:24
vilabut yeah, this sounds more appropriate (except for the last branch name which should be something like lp:~<you>/ubuntu/lucid/foobar/<whatever>)15:25
mgzodin_: have you looked at the bzr-builderplugin?15:26
odin_define "look at" heh, I know I have it installed, I know I am using it for dailydeb local testing15:27
mgzwell, it does seem a little short on examples, but the idea seems to be you can do what you're trying to there without extra rebasing steps15:29
mgzI guess you just need someone to tell you what recipe spelling to use15:31
mgztry posting your example problem to the list? most of the people who know this best are in a different timezone currently.15:32
odin_yes I will look up the "merge" recipe details/arguments in a moment15:52
=== beuno is now known as beuno-lunch
odin_is launchpad used by other debian based systems?16:08
odin_so I push first, like "bzr push --create-prefix --stacked lp:~group-project/ubuntu/lucid/packaging"  then make change(s), then add, then commit, then "bzr push" ?  then how do I go back to the original branch ?16:11
jelmerodin_: the --create-prefix and --stacked options shouldn't be necessary16:13
jelmerodin_: what tdo you mean with the original branch?16:14
odin_I have a 2 file patch, that removes 1 line from each file, I want it to always be a kind of patch on top of a base16:14
odin_but I don't want to have to manually rebase after every commit into base16:15
odin_I want to let bzr-builder be the thing to notice a problem with a "merge" than means I have to manually rebase this time to get it working again16:15
Darxusjelmer: Did you see the issue with the lp:spamassassin import?16:17
DarxusIt looks like galapagos is having similar difficulty importing songbird:  https://code.launchpad.net/~vcs-imports/songbird/trunk16:22
lamontvila: bzr-svn is not generally installed on the buildds16:33
jelmerDarxus: hi17:00
Darxusjelmer: Hi.17:00
jelmerDarxus, bigjools: it looks like somebody killed the cache on galapagos17:01
Darxusjelmer: So it is actually working, and it makes sense for it to take at least 7 hours?17:02
jelmerDarxus: no, that's not really correct either but it would explain why it's fetching the history metadta again from scratch17:05
jelmervila: hi17:05
jelmerDarxus: I'm pretty sure I can fetch something like spamassassin in less than 30 minutes, from scratch17:10
jelmerDarxus: not sure if that helps much, but it seems to be an issue specifically with galapagos to me17:12
=== beuno-lunch is now known as beuno
* jelmer goes back to his holiday17:13
jelmerodin_: I don't think it's possible to do something like that17:14
Darxusjelmer: So.. how do I get this in the hands of somebody that can and will fix it?17:15
DarxusAnd yeah, fetching all of spamassassin takes seconds.17:15
jelmerDarxus: filing a question against launchpad is probably the best course of action17:20
jelmerDarxus: svn only fetches a single revision, bzr fetches the entire history. It's correct that it takes a bit longer, but that shouldn't be significant for incremental imports17:21
DarxusAh, okay.17:24
ubot5Ubuntu bug 882681 in Launchpad itself "lp:spamassassin import is taking 8 hours so far, usually ~5 minutes" [Undecided,New]17:27
jelmerhi GRiD17:31
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
Darxusgalapagos's import of Songbird failed, I expect the same for spamassassin:  https://code.launchpad.net/~vcs-imports/songbird/trunk http://launchpadlibrarian.net/83846750/vcs-imports-songbird-trunk.log19:42
Darxusbzrlib.plugins.svn.errors.IncompleteRepositoryHistory: Unable to fetch revision info; first available revision: 1649319:43
wgzpoor jelmer isn't getting much of a break...19:45
DarxusSpamAssassin import has been running for 10 hours.19:46
DarxusI have a feeling it would've worked fine, but a tcp connection failed and it handled it badly or something.19:48
pooliehi all20:45
GRiDhi poolie20:49
pooliehi there, how's it going?21:26
peitschiehi everyone :)22:08
peitschieouch... my bzr-svn checkin has been now running for 15hrs22:26
Kamping_Kaiserpeitschie: impressive :)22:28
peitschieIt is stable it seems... just taking a long time to find rhs ancestors22:28
peitschieAnd doing them at a rate of 1 every 10s of seconds22:30
fullermdIt causes back injury if you do them too fast.22:30
peitschieahh... that makes sense.  I guess I wouldn't want to cause my pc significant health problems in its old age22:32
peitschieI wonder what their health cover is like?22:32
peitschie"sorry mister pc... you ran some wild software in your younger days... we really don't cover that mad source compiling"22:32
fullermdYeah, compiling is like the computer equivalent of skydiving.22:33
pooliepeitschie: is this the one you said was faster in a previous release?22:50
pooliejelmer's away til monday22:51
peitschiepoolie: I don't actually know to be honest.  The last time I had to build the svn metadata from scratch was like April last year.  Which means we've gone from 3000 commits to that branch to 11000.  It may be that this is some type of exponential problem that was not significant back then22:55
peitschiepoolie: I'm hoping this stuff is only a once-off hit, that once I generate the required indexes etc. on my computer, I can just copy it over to the other devs.  So in theory it won't be a show stopper for us... just painful for now :)22:57
peitschieat the moment though, its downloaded, uhh, 12Gb @ 256kb/s overnight trying to find these rhs ancestors22:57
poolieif you can get an lsprof profile that would probably help22:57
pooliei should really write up some troubleshooting data22:57
peitschieit's in the middle of a commit, the file has landed in svn already (did last night before it took this step).... am I likely to damage something if I interrupt things?22:58
pooliei think not, but i couldn't guarantee it23:12
=== |Nephyrin| is now known as Nephyrin
peitschieI'll just let it go for now then.  Safer not to risk it :(23:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!