[00:58] <poolie> peitschie: maybe ian's names are too cute :)
[01:03] <peitschie> poolie: 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:04] <poolie> clothing?
[01:05] <peitschie> poolie: clothing XD
[01:08] <peitschie> I 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 redistribute
[01:08] <peitschie> quite 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 once
[01:08] <poolie> awesome
[01:09] <poolie> i think that's the direction he wanted to take it
[01:09] <poolie> towards being something that encapsulates a lot of the setup and policy for a particular project
[01:09] <peitschie> yar... 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:10] <peitschie> for 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 from
[01:11] <peitschie> would allow automatic versioning, distribution of updates, as well as easy management for multiple projects all at once
[01:11] <poolie> yeah
[01:11] <peitschie> (not that you guys are suffering a shortage of ideas ;))
[05:37] <peitschie> Is there anyone around that could potentially cast an eye at https://bugs.launchpad.net/bzr-svn/+bug/882388 for me?
[05:37] <ubot5> Ubuntu bug 882388 in Bazaar Subversion Plugin "Fetching svn revision info seems to be very slow" [Undecided,New]
[05:58] <wgz> dark dark dark
[06:02] <wgz> peitschie: nothing in particular rings a bell there.
[06:02] <wgz> if you can reproduce the 30 revs/min with just the first N revisions,
[06:03] <peitschie> wgz: 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 related
[06:03] <wgz> I'd do `bzr --lsprof-file callgrind.out branch svn:...` and attach that.
[06:04] <wgz> would tell you at least who's IO was to blame
[06:04] <wgz> ^+ -r100 or similar
[06:07] <wgz> you can also try disabling fsync at the bzr level (can't remember what exactly the effect on windows is) with er...
[06:08] <wgz> dirstate.fdatasync = false in config.
[06:08] <wgz> and repository.fdatasync
[06:09] <peitschie> wgz: I'll give those whirl... thanks :)
[06:10] <peitschie> wgz: are those branch config options or bazaar.conf options?
[06:17] <wgz> they can be global
[06:22] <peitschie> wgz: 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:26] <wgz> that looks like a good set of things for diagnosis
[06:26] <wgz> as for workarounds...
[06:28] <wgz> branching from svn on a nix box or older version of bzr if that's faster then branching that bzr copy?
[06:32] <wgz> you could also try putting the svn-cache dir on temp storage
[06:32] <wgz> there seems to be a config option, but setting up ramdisk under windows is a little annoying
[06:33] <wgz> or disable the cache entriely.
[06:34] <wgz> try use-cache = False in ~/.bazaar/subversion.conf
[06:36] <peitschie> wgz: hehe.  I found a fun one that works!  I installed a ram-disk, and moved the svn-cache file onto that = mega faster!
[06:40] <wgz> yeah, it looked from the files you posted that your sqlite hunch was right
[06:41] <wgz> okay, bus time
[06:42] <peitschie> wgz: thanks for your help :)
[06:46] <lifeless> btw
[06:46] <lifeless> there is a pragma you can set
[06:47] <lifeless> in sqlite db's
[06:47] <lifeless> to tell them to use a larger page cache
[06:48] <peitschie> I 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] <peitschie> as 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:55] <lifeless> http://www.sqlite.org/pragma.html
[06:55] <lifeless> heh, they have deprecated it (because apps are meant to set their own I think)
[06:56] <lifeless> anyhow, pragma default_cache_size = 4000;
[06:56] <lifeless> or some such
[06:56] <lifeless> or just hack bzr-svn to issue a cache_size pragma.
[06:56] <peitschie> potentially playing with the synchronous might be fun as well
[07:00] <lifeless> that will need ot be issued from the process using the db
[07:00] <lifeless> so hack it into bzr-svn
[07:05] <jelmer> we should really finish the pack-based cache format for bzr-svn, that will fix a whole bunch of issues
[07:54] <redwyre|w> is it possible to make a bzr branch/depot read only?
[08:03] <maxb> chmod it?
[08:14] <redwyre|w> I can't change the file permissions :/
[08:15] <redwyre|w> do you mean just set the readonly flag?
[08:20] <vila> hey all !
[08:22] <vila> jelmer: I requeued the mutiple tarballs yesterday, AFAICS they all fail: http://package-import.ubuntu.com/status/56c18c6ef2106c8a91a81b26466fa557.html
[08:22] <vila> jelmer: some shallow thing may be ?
[08:28] <mgz> remorning!
[08:37] <vila> mgz: hehe. hi !
[08:37] <vila> mgz: posted a better explanation for bug #880701 in the mp, let me know if it helps or if you need more
[08:37] <ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
[08:43] <vila> mgz: 2.4 full test suite passing again, I'm so grateful for that...
[08:46] <mgz> will have a look at that mp again vila
[08:47] <vila> thanks in advance
[08:49] <vila> damn, John McMaccarthy too !
[08:50] <vila> fullermd: we'll soon be the only ones left ;)
[08:53] <maxb> ok, who moved all the udd scripts into a bin/ directory and broke stuff? :-/
[08:54] <maxb> jml: 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 it
[08:54] <vila> maxb: search the history a bit :) I've fixed the fallouts that appeared in production, did you find more ?
[08:55] <maxb> hmm, fixed how?
[08:55] <vila> maxb: oh, for interactive use, you need to set PYTHONPATH
[08:56] <maxb> that sucks - before you didn't
[08:56] <maxb> I'm likely to MP moving the scripts back :-)
[08:58] <vila> maxb: I suggest you discuss with jml before starting an edit war :-)
[08:59] <vila> maxb, jml: And having more tests for the scripts is likely to help in any case ;)
[09:01] <maxb> bzrlib.errors.RevisionNotPresent: Revision {james.westby@ubuntu.com-20110209140824-ftq14u7pfwalt6f2} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[09:02] <maxb> Am I right in thinking we've not got to the bottom of why that happens?
[09:02] <maxb> (branching a precise branch)
[09:02] <vila> obviously :)
[09:02] <mgz> cleaning up the lp:udd layout without also adding an install step does seem to have been... disruptive
[09:02] <maxb> pleeeeeeeeaaaaaaaaaaaaaaaaase no install step
[09:02] <mgz> ^which branch maxb?
[09:02] <maxb> ubuntu/precise/libraw
[09:03] <vila> maxb: oh, that one, yeah, weird, I can't reproduce the failure seen by the importer myself
[09:03] <mgz> maxb: in which case, reverting the bin move may be the best option, can always install *into* bin from root of repo
[09:04] <odin_> is there a comment to check if the tree is clean "bzr status ." via exit status ?
[09:04] <vila> mgz, maxb: Let's not have this discussion without jml and james_w or we'll run into circles :-}
[09:04] <maxb> yeah
[09:04] <odin_> s/comment/command/
[09:04] <mgz> I was wondering odin...
[09:05] <vila> a discussion on the udd mailing list may help gather all the point of views, pro and cons though
[09:06] <vila> odin_: IIRC there is an opne bug about status not returning a documented retcode.
[09:07] <vila> odin_: but I'm not sure everybody agree about what constitutes a 'clean' tree (with or without 'unknowns' for example)
[09:07] <mgz> status doesn't seem to return anything in fact
[09:07] <odin_> Set also: status-flags  (does this exist anymore?)
[09:07] <mgz> it's always 0 or an internal error
[09:07] <odin_> then add that as an option
[09:08] <odin_> bzr status -q --exclude-unknowns && echo "Tree is clean"
[09:08] <vila> odin_: --strict is used for commit already may be more coherent, care to file a bug or +affectsmetoo the existing one ?
[09:09] <maxb> hm, it's looking like oneiric/libraw was damaged, and precise just copied that
[09:10] <mgz> maxb: the branch-distro check log doesn't complain about it, wasn't one of the ones with stacking issues
[09:10] <vila> mgz: was this log posted in a bug ?
[09:11] <vila> mgz: or did we never get the whole file ?
[09:11] <vila> (got ?)
[09:12] <mgz> I have a copy.
[09:13] <mgz> scped from carob
[09: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"; fi
[09:15] <maxb> waiiit. now I can branch precise but not oneiric?
[09:18] <maxb> Perhaps a mis-reading by me earlier
[09:18] <maxb> But, bzr 2.3 'bzr check's oneiric, whilst bzr 2.4 fails it
[09:20] <vila> maxb: while you're there (good to see you by the way ;) any issue with the beta ppa or just lack of time ?
[09:21] <maxb> just lack of time. I can probably devote some this weekend
[09:22] <vila> that would be awesome !
[09:26] <mgz> curious parties can see branch-distro-2011-10-14.log in my homedir on jubany for the full log with stacking warnings
[09:30] <maxb> uhoh, has bzr 2.4 regressed where accessing stacked repositories containing zero packs?
[09:32] <maxb> libraw/{oneiric,precise} have the same last-revision. oneiric is stacked on precise, and oneiric has no packs. Yet I can branch precise but not oneiric
[09:34] <maxb> whereas I *can* branch oneiric on jubany using the bzr 2.3 there
[09:39] <maxb> Also I'm seeing lots and lots of spurious-looking refresh_possible_transports errors
[09:40] <vila> maxb: really ? where ?
[09:40] <maxb> logs/packages/libraw, for example
[09:41] <maxb> it makes me wonder if the recent changes to broaden the caught exception there have gone a bit too far
[09:42] <vila> maxb: well, if the transport is dropped, there are not spurious, they are supposed to avoid errors while trying to reuse a dead transport
[09:43] <vila> but the fact that there are so may of them makes me wonder about proper tracking of connections for reuse...
[09:43] <vila> hmm, may be it's too aggressive indeed as it seems to drop even valid transports...
[09:44] <maxb> yup
[09:44] <maxb> In particular "No such file: file-that-does-not-exist" is not a problem with the connection :-)
[09:46] <vila> maxb: http://paste.ubuntu.com/720526/ ?
[09:48] <vila> maxb: the previous 'bzrlib isn't supposed to raise this error, but it does' comment when catching errors.PathError was a bit misleading no ? ;)
[09:52] <vila> Merwin: I've got a fix under review for bug #880701
[09:52] <ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
[09:53] <Merwin> Hi vila!
[09:59] <mgz> okay, other tasks done, I will now bang my head against vila's conflicts code
[09:59] <vila> mgz: make some tea first ;)
[10:01] <Merwin> vila: Nice work ;)
[10:01] <mgz> argh, speaking of conflicts...
[10:01] <mgz> were it not for release-notes I wouldn't even know what a conflict was
[10:01] <mgz> ...okay, that's a slight exageration
[10:01] <vila> Merwin: thanks, that was a really hairy bug
[10:02] <vila> mgz: bzr help conflict-types ?
[10:03] <vila> maxb: ping ?
[10:06] <spiv> mgz: improve news_merge then ;)
[10:06] <vila> spiv: hey !
[10:07] <vila> spiv: news_merge works pretty well in general, the issue to have it correctly configured (but you know that ;)
[10:07] <vila> s//is/ somewhere
[10:12] <mgz> or at all I think, with pqm
[10:15] <mgz> okay, and ...I can't get this conflict locally, what was pqm's issue
[10:15] <vila> mgz: and you don't have the news_merge configured locally ??
[10:16] <mgz> nope.
[10:16]  * vila blinks
[10:19] <mgz> okay, I'm mystified
[10:20] <mgz> and pqm doesn't give me any more information apart from:
[10:20] <mgz> Executing star-merge http://bazaar.launchpad.net/~gz/bzr/lru_cache_refactor at Thu Oct 27 09:59:03 2011
[10:20] <mgz> Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.5.txt
[10:28] <maxb> vila: pong
[10:29] <vila> maxb: nm, I wanted feedback on http://paste.ubuntu.com/720526/ but it's quite trivial
[10:32] <maxb> ah. looks superficially fine, and as I presently on a bus, I don't have easy access to additional context
[10:33] <maxb> * I'm
[10:38] <mgz> reviewing diffs from a bus is impressive in itself
[10:45] <vila> maxb: hehe, don't worry, enjoy your ride ;)
[11:00] <mgz> okay, getting somewhere understand merge
[11:01] <vila> mgz: great, that's a very tricky area with ramifications
[11:02] <vila> ..unsurprisingly...
[11:33] <mgz> vila: posted review, lunch lunch
[11:33] <vila> 1) thanks ! 2) good idea !
[11:33] <vila> :)
[12:27] <vila> mgz: thanks for the review, I've replied, we can discuss here to reach an agreement if you want
[12:31] <vila> something 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:43] <mgz> vila: review responses look fine to me
[12:44] <vila> ha, good, thanks !
[12:45] <vila> mgz: good to land then ?
[12:51] <mgz> hm. ideally I think someone else should have a chance to look at it as well, but we are a little short of someones currenty
[12:52] <vila> yeah :-/
[12:52] <vila> Now, I think the risk is pretty low there,
[12:52] <mgz> especially as its 2.4 targetted and we're overdue a 2.4 release, landing this is a little uncertain
[12:53] <vila> I'm not adding a new kind of conflict, I'm refining a case with exceptions that were leading to a malformed transform
[12:53] <vila> which partly explains why the fix itself seems so obscure
[12:54] <vila> yeah, 2.4.2...
[12:55] <vila> I'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:56] <vila> I'm a bit more pro-active than usual when it comes to conflict/resolve related bugs as they generally mean some user is blocked
[12:56] <vila> hard
[12:57] <vila> and this fix will help a lot of people encountering first-level parallel import issues,
[12:57] <mgz> yeah, I think the targetting is good
[12:57] <vila> I 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 branches
[12:57] <mgz> I'm just wondering whether releasing a 2.4 version with this, right now, is a good idea
[12:58] <mgz> I'd prefer not to delay till after UDS, but obviously I'm not the one who's doing the work
[12:58] <vila> oh, if I were to release 2.4.2 today, I probably won't land this
[12:58] <vila> on the other hand, without a release, few people will be able to test it
[12:58] <jml> maxb: I thought vila fixed that yesterday
[12:58] <mgz> we just said on the list of a couple of people who's bugs we fixed in 2.4 that we'd release this week
[12:58] <vila> mgz: so, land on trunk ?
[12:59] <vila> crap, missed that
[12:59] <mgz> vila: in the mgz ideal world, release 2.4.2, land merge fix for 2.4.3
[12:59] <vila> mgz: ok, so.... 2.4.2 freeze time I guess :-{
[12:59] <vila> .me nods
[12:59]  * vila nods (hehe typos in irc commands now)
[12:59] <maxb> jml: vila's worked around it by adding PYTHONPATH in places, but formerly there was no requirement to set PYTHONPATH to make the scripts work
[13:00] <mgz> jml: basically running from source got a bit more annoying I think, it's certainly possible to do
[13:09] <jml> mgz: there are tricks we can do to work around it. I think the separation is worth it for code discovery.
[13:09]  * jml → meeting
[13:17] <exarkun> Why can't I branch http://svn.twistedmatrix.com/bzr/Twisted/branches/halfclose-tls-5341 ?
[13:23] <vila> mgz: finding bug #839461 again, mentioning it so you can update your in-brain-bug-db ;0)
[13:23] <ubot5> Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461
[13:24] <vila> mgz: to be clear, I'm not suffering from it right now, just read it again in releasing.txt
[13:27] <exarkun> uuugh
[13:27] <exarkun> Why does bzr need over 2GB of memory to make this branch?
[13:31] <exarkun> jelmer: 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:32] <exarkun> up 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] <mgz> exarkun: how much of that is the sqlite cache and how much is python?
[13:32] <exarkun> mgz: is there an option to `top´ to split up like that?
[13:32] <mgz> vila: right.
[13:33] <mgz> exarkun, no it's all in-process so basic nix tools won't help unfortunately.
[13:33] <exarkun> How would I answer that question, then?
[13:33] <mgz> finding the cache dir and looking at it should tell you the basics though
[13:34] <exarkun> ugh
[13:34] <exarkun> the cache dir has two kinds of database in it
[13:35] <exarkun> The sqlite3 database is only 51MB
[13:35] <exarkun> So I hope the sqlite3 cache isn't a lot larger than that
[13:35] <mgz> that sounds reasonable indeed.
[13:35] <mgz> the other one isn't huge either I take it?
[13:35] <exarkun> 16MB
[13:36] <mgz> probably just having the whole tree in memory or something instead then
[13:37] <exarkun> This wasn't a problem before I upgraded to the latest bzr-svn
[13:37] <exarkun> I could actually check out branches, though it took 5 minutes.
[13:37] <mgz> file a bug, 2.8GB is clearly bad
[13:39] <mgz> I'd suggest getting a meliae log of all objects as well, but that's unfortunatly not straight forward
[13:39] <exarkun> https://bugs.launchpad.net/bzr-svn/+bug/191731 seems related, though it was filed 3 years ago
[13:39] <ubot5> Ubuntu bug 191731 in Bazaar Subversion Plugin "Memory problems prevent branch of very large svn repositories" [Medium,Triaged]
[13:40] <mgz> happened to look at that earlier today, nothing left there but general bzr problems with big branches
[13:40] <mgz> I'd file a new one, as this is a regression from your upgrade
[13:40] <exarkun> Okay
[13:49] <exarkun> filed <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] <ubot5> Ubuntu bug 882578 in Bazaar Subversion Plugin "Too much memory used when branching" [Undecided,New]
[13:51] <mgz> well, knowing if downgrading bzr-svn would be useful (to you as well, if that means you can branch again)
[13:52] <mgz> and a .bzr.log extract is always worth it
[13:52] <mgz> otherwise seems find as a symptom-bug
[14:00] <mgz> s/find/fine/
[14:02] <exarkun> Okay.  Thanks for the help.
[14:13] <mgz> vila: thanks for the 2.4.2 release!
[14:13] <vila> hehe, looks like your nudge was the right trigger to make it quickly (or quicker than usual at least) ;)
[14:34] <vila> woohoo we can compile the bzr extensions on jubany :-D
[14:37] <mgz> that 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 like
[14:37] <vila> easier to express :)
[14:38] <vila> the idea was that even old build deps should be enough and I didn't need to list them either
[14:39] <vila> now, if chromium-browser would finish (or at least say *something* in its log...)
[14:39] <vila> I smell something weird going on there...
[14:41] <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] <bigjools> can anyone help with an svn import weirdness please?
[14:41] <bigjools> https://code.launchpad.net/~vcs-imports/spamassassin/trunk
[14:42] <bigjools> taking massively longer than normal
[14:43]  * bigjools hopes jelmer is around today
[14:45] <bigjools> Darxus: this is a better place to ask as it's essentially a bzr thing. I hope someone replies.
[14:46] <Darxus> Thanks.  Can you paste me the question?
[14:47] <vila> <bigjools> can anyone help with an svn import weirdness please?
[14:47] <vila> <bigjools> https://code.launchpad.net/~vcs-imports/spamassassin/trunk
[14:47] <vila> <bigjools> taking massively longer than normal
[14:47] <vila> nothing obvious (not already mentioned in #launchpad) comes to mind
[14:47] <bigjools> vila: I PMed him P)
[14:47] <vila> ha, sorry
[14:48] <Darxus> The 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.txt
[14:48] <bigjools> Darxus: that is symptomatic of a change in the repo such that it's trying to build the same version with different source files
[14:48] <bigjools> which is forbidden in archives
[14:49] <bigjools> this ties in with the long running import - it's almost like the import address is pointing somewhere else
[14:49] <vila> wag: the change is the svn repo was... changed in a way that makes bzr-svn *slowly* re-process a lot of stuff
[14:49] <Darxus> The version is 3.4.0-0~{revno}.  You're saying somebody altered the repo without incrementing the revision number?
[14:50] <bigjools> looking at the last revno, something odd has happened
=== yofel_ is now known as yofel
[14:51] <Darxus> bigjools: What are you looking at?
[14:51] <bigjools> "determining revisions to fetch 0/1189081" versus "fetching svn revision info 4603/1135013"
[14:51] <Darxus> Ah, the last import log?
[14:51] <bigjools> 1189081 on old imports, 1135013 on the slow one
[14:52] <bigjools> 30k revisions disappeared?
[14:52] <vila> bigjools: could it be that the cache was cleared ?
[14:53] <vila> bigjools: jelmer didn't deploy a new version recently (as in pst hours or days) AFAIK
[14:53] <vila> s/pst/past/
[14:53] <vila> bigjools: or could it be that such a new version were deployed as part of an lp deployment ?
[14:54] <bigjools> I have no idea
[14:54] <bigjools> we roll out new stuff every day
[14:55] <vila> bigjools: and about the svn cache ?
[14:56] <bigjools> no idea :(
[14:57] <bigjools> I know less than nothing about code imports
[14:58] <vila> bigjools: tsk, tsk, that's still more than me ;)
[14:58] <Darxus> Thanks 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] <vila> bigjools: for example, do you have an idea about whether this cache is local to 'pear', 'neumayer' and 'galapagos'
[14:59] <bigjools> well it's currently running on galapagos, which it hasn't lately, so .... :)
[14:59] <vila> bigjools: and whether galapagos may be a newer player here (and as such... see ? :)
[15:00] <vila> let's wait for jelmer then, sry Darxus !
[15:00] <Darxus> Er.
[15:01] <Darxus> 2011-10-27 14:59:47 INFO    copying revision:fetching svn revision info 1/1129313
[15:01] <Darxus> 2011-10-27 15:00:12 INFO    copying revision:fetching svn revision info 1/1129286
[15:01] <Darxus> The total number of revisions is decreasing.
[15:01] <Darxus> I was going to try to calculate when it would be finished, and it... didn't cooperate.
[15:02] <Darxus> I think there's something wrong :P
[15:05] <mgz> did anyone state what version of bzr-svn is on the buildds?
[15:07] <vila> Darxus: hehe, on the other hand, it's better than having revisions disappearing from the svn repo ;)
[15:07] <vila> Darxus: for now, I'll bet on a local cache being populated
[15:07] <vila> Darxus: the slowness is disconcerting though
[15:11] <mgz> if it's the same version as peitschie or exarkun were complaining about earlier (for different) that may be relevent
[15:11] <mgz> +reasons
[15:13] <vila> mgz: I had some feeling that may be the case but didn't closely follow your discussion with exarkun
[15:13] <vila> mgz: but didn't he used a very recent version ?
[15:14] <mgz> yes, and the buildds were on a much older one.
[15:14] <mgz> but I don't know what they're currently running.
[15:14] <vila> bigjools: did the buildds use the same code as the code importer ?
[15:15] <bigjools> vila: same code in what regard?
[15:15] <vila> bigjools: bzr-svn
[15:17] <bigjools> vila: probably not but we'd need to check to be sure.  The buildds don't get rolled out with the rest of LP
[15:17] <vila> bigjools: and the code importer is part of lp right ?
[15:17] <bigjools> there is a new one waiting to go out actually, lamont is doing it soon
[15:17] <bigjools> yes
[15: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:18] <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:19] <mgz> odin: I suggest looking at the python api rather than trying to do it in shell script
[15:20] <vila> odin_: why simply merge master instead ?
[15:20] <vila> odin_: why *not* simply merge master instead ?
[15:20] <mgz> but I wonder if there isn't a better way of working on distro branches than your proposed way there
[15:20] <odin_> unfortunately I only do C/C++/Java/sh/perl no ruby no python
[15:21] <mgz> there are a lot of existing tools for making that kind of maintanance easy, though I'm only just starting to learn them myself
[15:21] <vila> once your branches are setup, it's will just be: bzr merge ; bzr commit -m 'merge master' ; bzr push
[15:22] <vila> odin_: also, lp already handle the namespace for you if you're dealing with ubuntu releases
[15: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:23] <vila> ha, recipes :-/ I should *really* look into them
[15: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:24] <odin_> so I need the merge to take place inside the subdir "/debian" as well
[15:24] <odin_> since it only applied to the package management control files
[15:25] <vila> but yeah, this sounds more appropriate (except for the last branch name which should be something like lp:~<you>/ubuntu/lucid/foobar/<whatever>)
[15:26] <mgz> odin_: have you looked at the bzr-builderplugin?
[15:27] <odin_> define "look at" heh, I know I have it installed, I know I am using it for dailydeb local testing
[15:29] <mgz> well, 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 steps
[15:31] <mgz> I guess you just need someone to tell you what recipe spelling to use
[15:32] <mgz> try posting your example problem to the list? most of the people who know this best are in a different timezone currently.
[15:52] <odin_> yes I will look up the "merge" recipe details/arguments in a moment
=== beuno is now known as beuno-lunch
[16:08] <odin_> is launchpad used by other debian based systems?
[16:11] <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:13] <jelmer> odin_: the --create-prefix and --stacked options shouldn't be necessary
[16:14] <jelmer> odin_: 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 base
[16:15] <odin_> but I don't want to have to manually rebase after every commit into base
[16: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 again
[16:17] <Darxus> jelmer: Did you see the issue with the lp:spamassassin import?
[16:22] <Darxus> It looks like galapagos is having similar difficulty importing songbird:  https://code.launchpad.net/~vcs-imports/songbird/trunk
[16:33] <lamont> vila: bzr-svn is not generally installed on the buildds
[17:00] <jelmer> Darxus: hi
[17:00] <Darxus> jelmer: Hi.
[17:01] <jelmer> Darxus, bigjools: it looks like somebody killed the cache on galapagos
[17:02] <Darxus> jelmer: So it is actually working, and it makes sense for it to take at least 7 hours?
[17:05] <jelmer> Darxus: no, that's not really correct either but it would explain why it's fetching the history metadta again from scratch
[17:05] <jelmer> vila: hi
[17:10] <jelmer> Darxus: I'm pretty sure I can fetch something like spamassassin in less than 30 minutes, from scratch
[17:12] <jelmer> Darxus: not sure if that helps much, but it seems to be an issue specifically with galapagos to me
=== beuno-lunch is now known as beuno
[17:13]  * jelmer goes back to his holiday
[17:14] <jelmer> odin_: I don't think it's possible to do something like that
[17:15] <Darxus> jelmer: So.. how do I get this in the hands of somebody that can and will fix it?
[17:15] <Darxus> And yeah, fetching all of spamassassin takes seconds.
[17:20] <jelmer> Darxus: filing a question against launchpad is probably the best course of action
[17:20] <Darxus> Thanks.
[17:21] <jelmer> Darxus: 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 imports
[17:24] <Darxus> Ah, okay.
[17:27] <Darxus> https://bugs.launchpad.net/launchpad/+bug/882681
[17:27] <ubot5> Ubuntu bug 882681 in Launchpad itself "lp:spamassassin import is taking 8 hours so far, usually ~5 minutes" [Undecided,New]
[17:30] <GRiD> hello
[17:31] <jelmer> hi GRiD
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
[19:42] <Darxus> galapagos'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.log
[19:43] <Darxus> bzrlib.plugins.svn.errors.IncompleteRepositoryHistory: Unable to fetch revision info; first available revision: 16493
[19:45] <wgz> poor jelmer isn't getting much of a break...
[19:45] <Darxus> Heh.
[19:46] <Darxus> SpamAssassin import has been running for 10 hours.
[19:48] <Darxus> I have a feeling it would've worked fine, but a tcp connection failed and it handled it badly or something.
[20:45] <poolie> hi all
[20:49] <GRiD> hi poolie
[21:26] <poolie> hi there, how's it going?
[22:08] <peitschie> hi everyone :)
[22:26] <peitschie> ouch... my bzr-svn checkin has been now running for 15hrs
[22:28] <Kamping_Kaiser> peitschie: impressive :)
[22:28] <peitschie> It is stable it seems... just taking a long time to find rhs ancestors
[22:30] <peitschie> And doing them at a rate of 1 every 10s of seconds
[22:30] <fullermd> It causes back injury if you do them too fast.
[22:32] <peitschie> ahh... that makes sense.  I guess I wouldn't want to cause my pc significant health problems in its old age
[22:32] <peitschie> I 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:33] <fullermd> Yeah, compiling is like the computer equivalent of skydiving.
[22:36] <Kamping_Kaiser> hehe
[22:50] <poolie> :/
[22:50] <poolie> peitschie: is this the one you said was faster in a previous release?
[22:51] <poolie> jelmer's away til monday
[22:55] <peitschie> poolie: 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 then
[22:57] <peitschie> poolie: 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] <peitschie> at the moment though, its downloaded, uhh, 12Gb @ 256kb/s overnight trying to find these rhs ancestors
[22:57] <poolie> if you can get an lsprof profile that would probably help
[22:57] <poolie> i should really write up some troubleshooting data
[22:58] <poolie> *docs
[22:58] <peitschie> it'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?
[23:12] <poolie> i think not, but i couldn't guarantee it
=== |Nephyrin| is now known as Nephyrin
[23:20] <peitschie> I'll just let it go for now then.  Safer not to risk it :(