[12:11] <bradb> "Applying 98 revisions"...i can't think of one good reason under the sun of why i should see that when baz get'ing kiko's branch.
[12:22] <jblack> What's the problem? 
[12:23] <jblack> You doubt that he comitted 98 times? 
[12:25] <bradb> .........
[12:25] <bradb> gzip: stdin: unexpected end of file
[12:25] <bradb> tar: Child returned status 1
[12:25] <bradb> tar: Error exit delayed from previous errors
[12:25] <bradb> baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status)
[12:25] <bradb>   please report this as a bug to bazaar@lists.canonical.com
[12:25] <bradb> jblack: the problem is that it sends a very hostile message to the user. it says "screw you sucker! you ain't goin' ANYWHERE tonight!"
[12:26] <bradb> and now, heck, it appears i can't even get the branch at all
[12:30] <bradb> hm, no, maybe delta instead
[12:35] <jblack> tar exited with non 0....
[12:35] <jblack> That implies that the archvie is corrupted on the filesystme level
[12:36] <cprov> jblack: dude, do you still working ?!?!
[12:36] <bradb> jblack: whose archive?
[12:36] <jblack> brabd: whichever archive its building the revision for.
[12:37] <jblack> cprov: My flight today was cancelled, so I fly tomorrow instead. 
[12:37] <bradb> p.s. i'm now doing: baz delta --diffs $rocketfuel christian.reis@canonical.com--lozenge/launchpad--devel--0 > kikos_changes.patch
[12:37] <jblack> cprov: Got you sweet stuff, btw.
[12:37] <jblack> bradb: Can you tell which revision tar is complaining about? 
[12:37] <cprov> jblack: ohh dear ... 
[12:38] <bradb> jblack: christian.reis@canonical.com--lozenge/launchpad--devel--0 is my best guess, but i have absolutely no idea if that's the real problem.
[12:38] <jblack> I couldn't get you chocolate (its middle of the summer in the US and it would have melted in the car) but I did get you hard candy. 
[12:38] <jblack> bradb: mind giving me the location? I'll try doing a get here.
[12:38] <bradb> jblack: sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/christian.reis@canonical.com--lozenge
[12:39] <jblack> registering... getting (this will take awhile) 
[12:39] <bradb> bah, failed again, i give up
[12:40] <bradb> the bottom of the error message looked like:
[12:40] <bradb> tar: launchpad--devel--0--patch-3.patches/patches/daemons: Cannot mkdir: No such file or directory
[12:40] <bradb> tar: launchpad--devel--0--patch-3.patches/patches/daemons/librarian.tac.patch: Cannot open: No such file or directory
[12:40] <bradb> tar: launchpad--devel--0--patch-3.patches/patches/daemons/trebuchet.tac.patch: Cannot open: No such file or directory
[12:40] <bradb> tar: Error exit delayed from previous errors
[12:40] <bradb> baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status)
[12:40] <bradb> oh, i'm out of space again :/
[12:40] <bradb>   please report this as a bug to bazaar@lists.canonical.com
[12:40] <jblack> Ahhh. 
[12:40] <bradb> but i wasn't before
[12:40] <jblack> Running out of disk space would cause that problem.
[12:40] <bradb> (i.e. the previous two times it errored out)
[12:40] <jblack> maybe your archive cache and archive lib are loaded up? 
[12:41] <bradb> i've deleted them several times in the last 20 minutes
[12:41] <jblack> personally, I suggest you bite the bullet and get a shiny new 200 gig drive rather than prune, but you're the master of your machine. 
[12:41] <bradb> jblack: i suggest the caching be fixed rather than making every user by a baz-sized hard drive. ;)
[12:42] <bradb> s/by a/buy a/
[12:42] <jblack> How about pruning out extra debs in /var/cache/apt...whatever,  /var/log... maybe cutting your pr0n back to the 5 best gigs. 
[12:42] <bradb> dude, i had 1,3 GIGS of free space!
[12:42] <jblack> bradb: Yeah. Some code to limit libraries to an arbitrary revision would be nice. 
[12:43] <jblack> is your library sparse or nonsparse? 
[12:43] <bradb> sparse
[12:43] <jblack> how big is it? 
[12:43] <jblack> (that will take some time to check)
[12:43] <bradb> it's empty (again) now
[12:44] <bradb> 2,2G free, here we go again...
[12:44] <bradb> (with the delta command above)
[12:44] <jblack> Do you use , in place of . ? 
[12:44] <jblack> So you're saying "2 gigs 200 megs" ? 
[12:44] <bradb> i guess so. french thing.
[12:44] <jblack> Ok. Just making sure.
[12:45] <kiko> bradb, this is HILARIOUS
[12:45] <jblack> The library shouldn't be filling 2.2 gigs if you're blanking it and then diffing kiko.
[12:45] <bradb> bradb@oxygen:~ $ baz delta --diffs $rocketfuel christian.reis@canonical.com--lozenge/launchpad--devel--0 > kikos_changes.patch
[12:45] <jblack> It should be the size of 3 or 4 launchpad trees.
[12:45] <bradb> * Scanning for full-tree revision ....................................................................................... done.
[12:45] <bradb> * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-2072
[12:45] <bradb> * Applying 36 revisions ..
[12:45] <bradb> at this point, "Applying 36 revisions" is BAD NEWS to me.
[12:46] <bradb> bazaar, i *don't* want you to tell me that. i have a lot to do tonight, and it don't include you.
[12:46] <jblack> Are you linux or os-10 ? 
[12:46] <kiko> linux, jblack 
[12:46] <bradb> ubuntu
[12:46] <kiko> he's been linux for about 10 years now
[12:47] <jblack> I'm not quite sure what to say here...
[12:47] <jblack> You're wiping the libraries that caches revision building, then complaining that they have to be built? 
[12:47] <bradb> down to 1,8G...
[12:47] <bradb> (we'll see if this delta goes ok. fourth time might be the charm.)
[12:49] <jblack> btw, if you think baz is bad, you should see git. =) 
[12:49] <jblack> How big is your hard drive? 
[12:50] <bradb> 80G
[12:50] <kiko> bradb, just erase half of that porn and baz will squeal with glee
[12:50] <bradb> home partition is only 9G
[12:50] <jblack> If you don't mind me asking, what's taking up the other 78 gigs? 
[12:50] <bradb> i don't want to embarass myself by filling up /usr with a revision library
[12:51] <jblack> can't you just carve something off with lvm? 
[12:51] <kiko> bradb, 9G home partition? where do you store all that "source code"?
[12:51] <jblack> You could turn off revision libraries, but performance is going to be bad. 
[12:51] <bradb> heh heh
[12:52] <bradb> btw, the reason i only have about 2,2G left is because i like flac
[12:52] <kiko> I don't use revlibs at all ftr
[12:52] <jblack> kiko: ???? You serious? 
[12:52] <bradb> * Applying 36 revisions .................................... done.
[12:52] <bradb> * Scanning for full-tree revision ..................................................................................................................................................... done.
[12:52] <kiko> yeah
[12:52] <bradb> * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-1671
[12:52] <bradb> * Applying 98 revisions .................
[12:52] <kiko> I don't care for revlibs
[12:52] <bradb> (1.6G and counting now...)
[12:53] <jblack> bradb, if you don't have room for a revision lib, turn it off.
[12:53] <jblack> Ok. done getting kiko.
[12:54] <bradb> jblack: just wondering: is there any particular reason that the speed/cache size issue isn't a developer priority right now? is there something more beneficial to the lp team right now than improving the speed and cache size issues?
[12:54] <jblack> the first time, cold, it took 15 minutes.
[12:54] <kiko> bradb, they are working on imports, don't twist jblack's arm
[12:54] <kiko> there's a lot of booze to import
[12:54] <bradb> sorry, particularly bad baz/pqm week for me
[12:55] <kiko> they got vodka from finland, sake from japan, caipirinhas from the 3rd world
[12:55] <jblack> bradb: The baz team is spending about 90% of its efforts on imports right now.
[12:56] <jblack> The other ten is eaten up by meetings, workflow sync.
[12:56] <jblack> Getting baz with a revlib the second time while hot was 1 min 29 secs
[12:56] <jblack> Getting baz with a revlib, with --link the third time, while hot, was 7.5 seconds.
[12:57] <bradb> i'd love to do --link, if fl-cow were apt-get installable in hoary
[12:58] <kiko> 192.168.99.199/~kiko/launchpad.tar.gz
[12:59] <cprov> jblack: another wierd situation in baz, I've interrupt a commit process at:
[12:59] <jblack> Why's it not in hoary? 
[12:59] <cprov> * Creating revlib entry for celso.providelo@canonical.com/launchpad--gpg-ng--0--patch-58
[12:59] <cprov> ^X
[12:59] <kiko> interrupted commits, hoho
[12:59] <cprov> jblack:  since it, baz is lost, no status, nothing usable
[12:59] <jblack> what's broken for you?
[01:00] <cprov> jblack: 5 minutes for a status
[01:00] <cprov> jblack: after this user-crash
[01:00] <bradb> jblack: 
[01:00] <bradb> * Applying 98 revisions ...........................................................................................
[01:01] <bradb> gzip: stdin: unexpected end of file
[01:01] <bradb> tar: Child returned status 1
[01:01] <bradb> tar: Error exit delayed from previous errors
[01:01] <bradb> baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status)
[01:01] <bradb>   please report this as a bug to bazaar@lists.canonical.com
[01:01] <bradb> can this possibly be anything to do with DNS or connectivity issues?
[01:01] <jblack> bradb: Didn't we already get to the bottom of it, that your filesystem is too small for a revision library? 
[01:01] <jblack> cprov: what was the error? 
[01:02] <bradb> jblack: nope, as i already said, it wasn't out of space the first two times it failed. not now either.
[01:02] <bradb> /dev/hda5             9,2G  7,4G  1,4G  85% /home
[01:02] <cprov> jblack: ok, looks like solved, did "baz library-remove launchpad--gpg-ng--0--patch-58"
[01:02] <jblack> bradb: wfm
[01:02] <jblack> cprov: great. =)
[01:02] <cprov> jblack:  it rebuild the revlib, and baz archive-mirror sends the stuff 
[01:02] <jblack> bradb: could you be running out of space in /tmp as well? 
[01:02] <cprov> jblack: thanks
[01:03] <bradb> jblack: nope
[01:03] <bradb> Filesystem            Size  Used Avail Use% Mounted on
[01:03] <bradb> /dev/hda3             9,2G  4,5G  4,3G  52% /
[01:03] <bradb> tmpfs                 252M     0  252M   0% /dev/shm
[01:03] <bradb> /dev/hda5             9,2G  7,4G  1,4G  85% /home
[01:03] <bradb> /dev/hda6              37G  2,2G   33G   7% /usr
[01:03] <bradb> /dev/hda7             9,2G  3,6G  5,2G  42% /var
[01:03] <bradb> none                  5,0M  600K  4,5M  12% /dev
[01:03] <jblack> bradb: Would you mind emailing me a long log, from the line where you type in the command, until the line where you're returned to the shell? 
[01:04] <bradb> kiko: what's the external IP for that download? :)
[01:05] <kiko> bradb, only the eleet have access to that one :)
[01:05] <bradb> heh
[01:05] <kiko> what does baz gzip ffs
[01:05] <bradb> jblack: sent. it's not actually that long either.
[01:06] <kiko> bradb, just rm -rf something
[01:06] <kiko> and then do it again
[01:06] <kiko> actually
[01:06] <kiko> why don't you merge my tree in?
[01:06] <bradb> third time i've done exactly that!
[01:06] <kiko> oh
[01:06] <bradb> kiko: merging == risk of conflicts
[01:06] <kiko> could your revlibs be foobed
[01:06] <jblack> bradb: For some reason, tar on your system is failing. 
[01:06] <kiko> bradb, you don't have a free branch of rocketfuel?
[01:06] <kiko> bradb, I'm synced up with RF
[01:06] <bradb> jblack: can it be a connectivity issue?
[01:06] <jblack> Its not kiko's archive, because I can get it here.
[01:06] <jblack> Maybe its your archive cache. 
[01:07] <jblack> maybe you ran out of space and have a partial revision stuck in there
[01:07] <kiko> my archive! the nerve!
[01:07] <bradb> jblack: it's totally empty dude
[01:07] <jblack> Not your arch library. your arch cache
[01:07] <bradb> except for =greedy and =sparse
[01:07] <bradb> oh
[01:07] <bradb> kiko: nope, i could get one though
[01:08] <bradb> jblack: have you somehow from the error message been able to rule out a connectivity issue?
[01:09] <jblack> rm -rf .arch-cache/archives/christian.reis@canonical.com--lozenge/*
[01:10] <jblack> bradb: Not strictly speaking, no, but it doesn't sound like a conenctivity problem to me, because you can reach some of his stuff. 
[01:10] <jblack> I can reach all of his stuff, you can reach all.What sort of connectivity problem would prevent you from hitting a particular .tar.gz file? 
[01:11] <jblack> I think what's happened here is that your starved filesystem broke baz at a really unusual time, and you've got something half written somewhere.
[01:11] <jblack> the two places we cache are in a library, if available, and .arch-cache
[01:12] <bradb> right, merging into a fresh rf checkout now. maybe the rm -rf foo did it
[01:12] <jblack> also, baz can sometimes sneak out of its tree looking for a sister tree that works, and use that as an impromptu read-only library (I know, I know)
[01:16] <bradb> jblack: question: why is it merging in 98 revisions when i merge into a fresh rf tree that kiko says he's synched up to?
[01:17] <bradb> sorry, s/merging in/"Applying %d revisions"/
[01:21] <jblack> bradb: because 98 revisions back is the latest cached revision in the archive.
[01:21] <jblack> baz stores just the changes between revisions normally. 
[01:21] <jblack> so, in order to get a full tree, it has to find the most recent full copy of the tree it can get its hands on, then apply the changes for the following revisions, one at a tme
[01:23] <bradb> jblack: when i empty out my revlib, why doesn't isn't it trying to apply 2108 patches to rocketfuel?
[01:24] <bradb> s/doesn't//
[01:24] <bradb> for some reason, i had the impression it was smart enough to do a bit of virtualization
[01:24] <jblack> because somewhere between base-0 and patch-2108, a cached revision was created and stored in the archive.
[01:25] <jblack> That happens by default once every 50 revisions.
[01:25] <bradb> ah
[01:26] <jblack> that you have to build 98 revisions from kiko tells me he's either using an older baz, has disabled cached revisions, or told mirroring to not upload cached revisions.
[01:26] <jblack> or a couple other possibilities
[01:26] <bradb> * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-1671
[01:26] <bradb> * Applying 98 revisions .................................................................................................. done.
[01:27] <bradb> Read from remote host chinstrap.warthogs.hbd.com: Connection reset by peer
[01:27] <bradb> * Scanning for full-tree revision failed to query archive:
[01:27] <bradb>   revision: rocketfuel@canonical.com/launchpad--devel--0--patch-2108
[01:27] <bradb>   location: sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/rocketfuel@canonical.com
[01:27] <bradb> * Searching for best merge point bradb
[01:27] <bradb> damn dude, i really think there's some connectivity problem action going on here
[01:27] <jblack> That looks like connectivity to me.
[01:27] <bradb> my wireless is flaky sometimes. sometimes it seems like DNS works only 2/3 tries, if that
[01:27] <jblack> I can get on chinstrap with no problem.
[01:28] <bradb> no, the connectivity would be my problem, not chinstrap
[01:28] <bradb> that's what made me lean towards asking about it before though, admittedly, i too wouldn't see a relationship between the gzip failure messages earlier and a connectivity problem.
[01:29] <jblack> Yeah. why break _there_, and consistantly at that? 
[01:29] <jblack> more likely it broke at some other time, and wedged something. 
[01:30] <jblack> I'm hungry. I don't want to make dishes since I'm leaving tomorrow (again). 
[01:30] <jblack> I think I'm going out.
[01:41] <bradb> right, got kiko's changes, diffing now
[01:45] <kiko> wwooo!
[01:46] <bradb> kiko: first thing i might improve:
[01:46] <bradb>  class BugWatch(SQLBase):
[01:46] <bradb> +    """A watch, which links a Malone bug to a bug in a foreign bugtracker"""
[01:46] <bradb> what about: """A link between an IBug and a bug in an external tracker."?
[01:46] <bradb> er, sorry
[01:46] <bradb> that docstring should also be in the iface, not the content class
[01:50] <bradb> oh...that "Change information for ..." text on the bug edit page is an interesting improvement.
[01:54] <bradb> and he gets rid of the table for also reported in! :)
[01:55] <bradb> kiko: is portlet-bug-people only used on the bug page? (the name implies yes, but just wanted to be sure)
[02:00] <bradb> kiko: this is evil: <ul tal:condition="python: not request.getURL().endswith('+edit')"> :)
[02:24] <kiko> bradb, now, yes
[02:24] <kiko> it used to be also used in the person page
[02:24] <kiko> sorry
[02:25] <kiko> it used to be also used in the bugtask page
[02:25] <kiko> bradb, yes, it's evil. do you have a suggestion?
[02:25] <bradb> thinking, while finishing off the rest of the review
[02:25] <kiko> I thought of many solutions but none were as simple
[02:25] <kiko> it's a damned hack, agreed
[02:25] <bradb> are you totally against putting the link in a little actions portlet, *just for now*? (since we've already got actions portlet everywhere anyway)
[02:26] <kiko> a one-item actions portlet? :-)
[02:27] <bradb> yeah, that's the problem, hm, /me thinks
[02:27] <kiko> my solution is crude but works :)
[02:29] <bradb> another option i can think of, slightly crude, but somewhat cleaner, is to define a method on BugTaskEditView
[02:29] <bradb> viewingEditScreen, or something
[02:29] <bradb> then tal:condition="view/viewingEditScreen|nothing" (or perhaps a better name for that method)
[02:30] <kiko> that doesn't work
[02:30] <kiko> BugTaskEditView is not the view for tha tportlet
[02:30] <kiko> it makes me feel like crying
[02:30] <kiko> I tried doing that
[02:33] <bradb> oh, ViewWithBugTaskContext, argh, bad memories
[02:34] <kiko> yes
[02:34] <kiko> right
[02:40] <bradb> kiko: response coming along in about 3 mins
[02:42] <kiko> thanks 
[02:49] <kiko-zzz> time for some dinner
[02:51] <bradb> sent!
[02:52] <bradb> kiko-zzz: ^^^
[03:00] <bradb> thanks for putting up with my ranting jblack, hope you have better luck getting to brazil tomorrow ;)
[09:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Validators should return NULL ON NULL INPUT (patch-2109: stuart.bishop@canonical.com)
[09:45] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Refactor database sanity checks to not leave an open connection (patch-2110: stuart.bishop@canonical.com)
[11:19] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  linkchecker tweaks (patch-97: stuart.bishop@canonical.com)
[11:30] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Trivial fixes lost in PQM (patch-98: stuart.bishop@canonical.com)
[11:31] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  linkchecker tweaks (patch-99)
[11:37] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  linkchecker tweaks (patch-100: stuart.bishop@canonical.com)