[00:30] <spm> jelmer: heyo, need a key updated?
[00:31] <jelmer> spm: hi!
[00:32] <jelmer> spm: Yes - I have a new GPG key, D729A457 and would like to use it in the Bazaar PQM
[00:32] <spm> kk
[00:33] <lifeless> jelmer: done a key transition document ? :)
[00:36] <jelmer> lifeless: no, that's a good point actually...
[00:39] <SamB_XP> especially important is a section on going back in time and preventing yourself from losing the previous key in the first place ...
[00:57] <spm> jelmer: sorry, got a tad distracted on other stuff tehre; that key is now imported, so should be fine and dandy.
[01:10] <awilkins> jelmer: I've split all those branches in the big repo into separate repositories since they probably don't have much in common apart from being for the same project ; one other branch was broken by that missing object
[01:11] <awilkins> I've kept the old repo but I can't release it.. it bother me that "check" ran OK on it even though it was broken
[01:12] <awilkins> Anyway sleeptime
[01:20] <lifeless> spiv: got any specific network stuff you want me to look at this week?
[01:22] <spiv> lifeless: not off the top of my head.
[01:22] <lifeless> k
[01:23]  * lifeless goes back to dirstate 
[01:33] <jelmer> spm: Cool, thanks!
[01:50]  * igc bbl - out for a medical visit
[01:52] <lifeless> abentley: is there a tag for tree transform bugs?
[02:06] <spiv> lifeless: four bugs (2 open) have 'treetransform' (which was my first guess).
[02:13] <jfroy|work> OK, so people are complaining about the PyCrypto warnings
[02:14] <jfroy|work> Should I just outright patch PyCrypto?
[02:15] <fullermd> I'd say so.  It's a pretty simple patch.
[02:15] <Peng_> I think people have done just that; maybe Ubuntu?
[02:16] <fullermd> There's a patch on LP somewhere for it.  The FBSD port of it has a functionally identical patch.
[02:17] <jfroy|work> Done deal.
[02:18] <fullermd> http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/py-pycrypto/files/python25%2B.txt?rev=1.1
[02:18] <fullermd> Should DTRT with older versions too.
[02:42] <barry> lifeless: ping
[02:43] <barry> or spiv perhaps?
[02:44] <lifeless> hai
[02:45] <barry> lifeless: hiya.  yesterday you mentioned in passing upgrading my branch "in-place".  what did you mean? :)
[02:47]  * spm waves hi to barry with the RedHat son ;-)
[02:48] <lifeless> barry: 'bzr upgrade lp:FOO'
[02:48]  * barry waves and reminds him it was a /Ferrari/ hat!  he's got an ubuntu laptop fer gosh sakes :)
[02:48] <lifeless> barry: will upgrade that branch; if its a branch that other branches are stacked on, you have to upgrade the stacked branches too or they will stop working
[02:48] <barry> lifeless:  gotcha, thanks.  i'm going to try it.  i think there are few if any stacked branches
[02:55] <blueyed_> why are >50mb being uploaded to a stacked branch (where I have branched from, changed some files, and now are pushing back to)?
[02:55] <blueyed_> format changes?
[02:55] <blueyed_> $ bzr push lp:~blueyed/b2evolution/slug-history
[02:55] <blueyed_> Using default stacking branch /~blueyed/b2evolution/trunk-cvs at lp-46127440:///~blueyed/b2evolution
[02:55] <blueyed_> [#########-          ]  51621KB   116KB/s | Fetching revisions:Inserting stream
[02:56] <SamB_XP> blueyed_: could be ...
[03:00] <spiv> No, the formats are the same.
[03:01] <lifeless> spiv: sure about that ?
[03:02] <lifeless> blueyed_: can you pastebin the end of your ~/.bzr.log ?
[03:02] <spiv> lifeless: well, Launchpad is!
[03:02] <lifeless> spiv: on the server end yes
[03:02] <lifeless> spiv: but old bzr + on the fly conversion ...
[03:03] <lifeless> spiv: note that blueyed_ branched *from* an existing stacked branch, so there wouldn't be a warning about the formats as the branch isn't being created
[03:03] <spiv> Oh, I see
[03:03] <spiv> Certainly, the revids for say rev 8249 are the same in the two branches, so there should be common history.
[03:03] <lifeless> right
[03:03] <blueyed_> lifeless: http://pastebin.com/m22326b2c
[03:04] <blueyed_> nothing about stacking in the log though.
[03:05] <lifeless> blueyed_: oh, and whats your bzrv ersion ?
[03:05] <blueyed_> lifeless: karmic, 2.0..
[03:05] <blueyed_> 2.0.0
[03:05] <lifeless> ok
[03:05] <lifeless> what does 'bzr info' show for your local branch ?
[03:06] <lifeless> blueyed_: the branch on launchpad doesn't claim to be stacked when I examine it
[03:07] <lifeless> blueyed_: and in fact, its a pack-0.92 branch, which doesn't support stacking
[03:07] <blueyed_> but bzr told me about it, when pushing?! what can I do to make it stacked? I thought LP would do so automatically?
[03:07] <lifeless> blueyed_: so I think the answer is 'its not stacked' ;)
[03:07] <blueyed_> ok :)
[03:07] <blueyed_> I need to upgrade and push the trunk branch?
[03:07] <blueyed_> (which is autogenerated via tailor)
[03:07] <lifeless> blueyed_: upgrade your trunk branch to something thats supports stacking, such as 1.6 (the minimum) or 2a (one way conversion but worth doing :))
[03:08] <blueyed_> ok, thanks.
[03:08] <blueyed_> good night
[03:08] <lifeless> gnight
[03:08] <spiv> Oh, right, that's one of those confusing "Using default stacking ..." messages that are actually emitted on stderr on the server.
[03:09] <lifeless> I'm starting to hate the big red border
[03:34] <jfroy> I have a new Snow Leopard package to upload to LP with a patched PyCrypto.
[03:34] <jfroy> http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg
[03:34] <jfroy> Whoever can do that :)
[03:39] <lifeless> jfroy: have you digitally signed it ?
[03:39] <lifeless> gpg --armor --sign --detach-sig Bazaar2.0.0-3.pkg
[03:40] <jfroy> Hum, that would require me to have a gpg signature :p
[03:40] <lifeless> ok
[03:40] <jfroy> I can sign the package with a certificate however
[03:40] <lifeless> I urge you to do that in future, it makes it easier :)
[03:40] <lifeless> its uploading now
[03:40] <jfroy> "that"?
[03:40] <lifeless> should I delete the -2 version?
[03:40] <jfroy> Yes
[03:41] <lifeless> [get a GPG sig]
[03:41] <jfroy> Right, I can get that.
[03:41] <jfroy> Not that anyone would trust me :|
[03:41] <lifeless> you can get in the global web of trust pretty easily
[03:41] <lifeless> where are you geographically?
[03:41] <jfroy> Cupertino, CA
[03:41] <lifeless> Dead Easy
[03:42] <lifeless> back shortly
[03:43] <fullermd> I can't have web of trust discussions.  I found out that it takes an average of 4 minutes (with 1 sigma of about 2.5 min) to get into the metaphysics of identity, then everything falls apart.
[03:46] <lifeless> yes, but you use FreeBSD :P
[03:46] <dash> jfroy: heh i'm in santa clara
[03:46] <spm> my observation is most people ignore the 'trust' part. They want certainty in an uncertain world.
[03:46] <fullermd> Well, it SAYS it's FreeBSD anyway.  I don't know whether to trust that claim...
[03:47] <jfroy> spm: and an untrusted signature gives you none of that.
[03:47] <jfroy> :p
[03:48] <dash> jfroy: i work in cupertino though :D
[03:48] <lifeless> trust is relative
[03:49] <jfroy> dash: ^^
[03:49] <jfroy> mmm
[03:49] <jfroy> I think I do in fact have a GPG key
[03:50] <jfroy> or used it
[03:50] <jfroy> *used to
[03:50] <jfroy> might be expired by now. Let's see, how do I use this gpg thingy
[03:50] <lifeless> spiv: bug 327558
[03:52] <lifeless> jfroy: don't worry about it now, I did the upload already :)
[04:03] <spiv> lifeless: thanks
[04:04] <lifeless> spiv: appears harmless but noisy; I haven't dug deeply, it showed up as an odd tag so I peeked at it
[04:04] <lifeless> spiv: may be something to toss to vila
[04:04] <spiv> lifeless: already fixed actually :)
[04:04] <lifeless> spiv: easythen ;)
[04:04] <spiv> Very!
[04:04]  * spiv -> lunch
[04:06] <jfroy> lifeless: http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg (new package signed with my MobileMe cert) and http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg.asc signed with 0591FA2D
[04:06] <jfroy> the key should be on the MIT server.
[04:06] <jfroy> I think :/
[04:07] <lifeless> jfroy: gpg: key 0591FA2D: public key "Jean-Francois Roy <bahamut@macstorm.org>" imported
[04:07] <lifeless> ?
[04:07] <jfroy> indeed, should have 3 identifies in it
[04:07] <lifeless> jfroy: I think I touched a couple of your bugs this morning
[04:07] <jfroy> thought I changed the principal one to jeanfrancois.roy@me.com
[04:07] <jfroy> Oh well.
[04:08] <jfroy> *identities
[04:09] <lifeless> ok, deleting that -3 and reuploading
[04:11] <jfroy> It's always worth it to do it right :)
[04:11] <jfroy> And almost never not to.
[04:15] <lifeless> jfroy: so, dirstate bugs
[04:15] <lifeless> jfroy: can you reproduce?
[04:15] <jfroy> huh, remind me the bug #
[04:15] <lifeless> check your bugmail :)
[04:15] <lifeless> this laste 4 hours I've been trawling bugs
[04:15] <jfroy> right, those emails I send to Trash almost in a manic way :p
[04:15] <jfroy> joking
[04:16] <jfroy> or not?
[04:16] <jfroy> doh
[04:17] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/328674
[04:17] <jfroy> whoa talk about ancient
[04:17] <jfroy> haven't seen that backtrace again I think
[04:18] <jfroy> In any case, I have no idea what I was doing at the time that triggered the problem.
[04:20] <lifeless> ok
[04:51] <tolstoy> Oh, dear. The Snow Leopard installer doesn't work. Yikes!
[04:52]  * igc lunch
[04:56] <lifeless> tolstoy: which one
[04:56] <tolstoy> The third one.
[04:57] <tolstoy> I tried it on two machines.
[04:57] <lifeless> jfroy: ^
[04:57] <tolstoy> The first machine already had the first version of the package installed, and the other hard the second.
[04:57] <tolstoy> Syslog doesn't reveal much.
[04:57] <tolstoy> I'm not sure how to completely uninstall the whole thing to see if maybe there's an artifact from an earlier install.
[04:59] <lifeless> tolstoy: could you file a bug?
[04:59] <tolstoy> Okay. I was just going to reply to the mailing list.
[05:00] <lifeless> do both :)
[05:00] <lifeless> bugs are useful though
[05:03] <tolstoy> Is there a log one can tail to find more detailed output about what an installer is doing?
[05:04] <tolstoy> Hm. Maybe install.log?
[05:04] <lifeless> no idea sorry, not a macoser
[05:05] <tolstoy> Failed install preflight: Error Domain=PKInstallErrorDomain Code=102 UserInfo=0x11a59a5f0 "The package “Bazaar2-1.0.0-3.pkg” is untrusted." Underlying Error=(Error Domain=NSOSStatusErrorDomain Code=-2147409622 UserInfo=0x11a591fd0 "The operation couldn’t be completed. CSSMERR_TP_NOT_TRUSTED")
[05:08] <tolstoy> Glad I found that log. I bet that's pretty clear to jfroy'll know right off the bat what's up with that.
[05:08] <lifeless> ah thats the signature :)
[05:08] <lifeless> I guess you have to trust him somewhere
[05:09] <tolstoy> The other two packages worked. I bet it's just a missed step somewhere.
[05:11] <tolstoy> lifeless: You think I should still file a bug?
[05:11] <lifeless> yes
[05:12] <lifeless> we'll need to document it
[05:12] <lifeless> tolstoy: -3 is the first one that is signed
[05:12] <tolstoy> Ah, okay.
[05:13] <tolstoy> https://bugs.launchpad.net/bzr/+bug/439141
[05:14] <tolstoy> Ah. Well, there you go. ;)
[05:18] <lifeless> thanks
[05:20] <jfroy> tolstoy: ouch, that's bad
[05:21] <tolstoy> Heh. At least I could find a decent error message! ;)
[05:23] <jfroy> So apparently what I thought was a trusted system root wasn't
[05:23] <jfroy> :sigh: this has been a huge FAIL in retrospect
[05:24] <Peng_> Stupid question: Renaming a directory and renaming the files in it. Does that work?
[05:28] <tolstoy> Peng_: Works for me, as long as it's "bzr mv".
[05:28] <lifeless> jfroy: -4, unsigned, gpg sig only ? :)
[05:29] <Peng_> Ah, I got it! Except the moves are listed in "status" 2-3 times. That can't be good.
[05:29] <jfroy> lifeless: coming right uo
[05:29] <jfroy> *up
[05:29] <Peng_> Committing seems alright, though.
[05:30] <lifeless> Peng_: each fileid that has its parent or name change will be listed, and only those
[05:30] <jfroy> lifeless: http://www.devklog.net/bazaar/Bazaar2.0.0-4.pkg, http://www.devklog.net/bazaar/Bazaar2.0.0-4.pkg.asc
[05:34] <Peng_> Uh-oh. Now "bzr check" fails.
[05:36] <lifeless> Peng_: ?!
[05:36] <lifeless> Peng_: bzr version ?
[05:36] <Peng_> lifeless: bzr.dev, as of yesterday.
[05:37] <Peng_> The "bzr check" failure doesn't seem to be related. I think it might be...not a problem, anyway. Hold on.
[05:39] <Peng_> Remember that branch with the screwed-up revision? My current repo doesn't have the revision, but I still have the branch, so I think it failed because the branch points to a revision that does not exist.
[05:39] <lifeless> ah if its in the reop check will examine it
[05:40] <lifeless> anyone think the karmic booting screen looks very X-Files?
[05:40] <Peng_> Yeah, I temporarily moved the branch out of the way, and check passes now. Never mind about the crisis. :P
[05:41] <Peng_> Sorry if I raised your blood pressure or anything.
[05:41] <lifeless> no
[05:41] <lifeless> but thanks :)
[05:41] <fullermd> lifeless: Bug 403322 the same thing as bug 430672, no?
[05:41] <lifeless> TolstoyAway: try now
[05:41] <lifeless> -4 is up
[05:45] <jfroy> yeah
[05:45] <jfroy> and the link has been updated on the wiki
[05:59] <lifeless> fullermd: could be
[05:59] <fullermd> It looks like the same trigger mechanism (mv'ing to the lexically earlier name), and the error looks the same.
[06:01] <lifeless> fullermd: see my latest comment
[06:03] <fullermd> Yeah, that looks like what it should do.  Wanna just dupe it?
[06:06] <Peng_> beuno: ping
[06:07] <Peng_> beuno: (Low-priority, though.)
[06:11] <Peng_> beuno: Never mind.
[06:12] <lifeless> fullermd: yeah, reduped, moved over, submitted for review
[06:13] <fullermd> Sweet.
[06:14] <fullermd> Lesson learned: I don't need to get things marked Critical.  Just leave additional bugs for the same problem lying around, and pounce on people when they start working on them   ;)
[06:16] <lifeless> fullermd: my lp bug for the afternoon
[06:16] <lifeless> https://bugs.edge.launchpad.net/launchpad/+bug/439153
[06:22] <fullermd> If you find a bug using a bug tracker, does that count as two wrongs making a right?
[06:33] <lifeless> fullermd: no
[06:34] <lifeless> fullermd: did you look at the png ?
[06:35] <fullermd> Oh, yes.  I was being more whimsical.
[06:36] <wgrant> lifeless: That bug is a dupe. Not sure which of. It's less impressive for those who are not members of ~launchpad.
[06:37] <lifeless> wgrant: thanks
[06:37] <lifeless> i was... startled
[06:38] <fullermd> OK, there's _definitely_ whimsy potential in a dupe bug about a problem with dupeing...
[06:39] <wgrant> Now, there is already a dupe of the original.
[06:39] <wgrant> So I might mark lifeless' bug as a dupe of the dupe, take a screenshot of the error and attach it to the original.
[06:40] <fullermd> Should be safe, as long as the bug tracker supports tail recursion   ;)
[06:41] <wgrant> There was a bug just after AJAX dupe-marking was introduced where it wouldn't stop you from marking a bug as a dupe of itself.
[06:41] <wgrant> This caused infinite recursion.
[06:41] <wgrant> And LP devs got the very, very long traceback in the same popup as lifeless' screenshot shows.
[06:48] <lifeless> I love to get tracebacks
[06:48] <lifeless> especially red ones in skinny boxen
[06:51] <emmajane> igc, ping?
[06:51] <igc> hi emmajane
[06:51] <emmajane> igc, hey.
[06:51] <emmajane> I'm going a bit cross-eyed trying to catch up with the mailing list and get the changes in. Can you take a peek at the latest and let me know what i'm missing?
[06:52] <igc> emmajane: sure
[06:52] <emmajane> thanks
[06:52] <igc> emmajane: I was just pushing an update to the Download text and saw your latest round of changes
[06:52] <emmajane> igc, I'm not sure how much more I can do tonight. (it's nearly 2am here)
[06:53] <igc> np
[06:53] <igc> emmajane: the banner looks a little out of alignment btw
[06:53] <igc> the "Bazaar" title is lower than the logo
[06:53] <emmajane> igc, move it up?
[06:56] <igc> emmajane: I'll try that
[06:56] <emmajane> igc, I've already got the fix. I just wanted to make sure you meant that. :)
[06:57] <igc> emmajane: pull my dlwnload fix before committing btw
[06:57] <emmajane> ok
[06:59] <igc> emmajane: also Get Help needs to link to BzrSupport, not BzrExtras :-)
[06:59]  * emmajane sighs. too tired to copy and paste. good catch.
[06:59] <igc> emmajane: the Home link needs to go to '.', not '/'
[07:00] <igc> emmajane: otherewise it breaks in it's current location (xxx/static/)
[07:00] <igc> s/it's/its/
[07:00] <lifeless> it's important to get that right :)
[07:01] <fullermd> Yeah, people who get it wrong really put they're credibility on the line.
[07:01] <lifeless> ouch
[07:02] <fullermd> Accept when it's intentional, of course   :p
[07:03] <emmajane> igc, links fixed.
[07:03] <igc> emmajane: the top line links are really nice now - well done
[07:03] <emmajane> argh. I think I screwed that up. where did your distro links go? :/
[07:03] <igc> emmajane: but search is broken?
[07:04] <emmajane> oh, there they are.
[07:04] <emmajane> search has never worked. I am still trying to figure out what Dustin sent me.
[07:04] <emmajane> he's got some extra XML site map and other directories and stuff.
[07:04] <kirkland> emmajane: ?
[07:04] <emmajane> it has always loaded inline
[07:04] <emmajane> kirkland, hey :)
[07:05] <kirkland> emmajane: hiya
[07:05] <emmajane> kirkland, your search is way intense.
[07:05] <emmajane> kirkland, it confuses me.
[07:05] <kirkland> emmajane: :-)  is it?
[07:05] <kirkland> emmajane: sorry
[07:05] <emmajane> kirkland, assok. I just open the files and stare at them and then walk away trying not to cry at how stupidly complicated google makes a SEARCH WIDGET.
[07:07] <kirkland> emmajane: okay, it's not that bad
[07:07] <kirkland> emmajane: i've made it complicated to do extra complex things
[07:07] <lifeless> it's worse?
[07:07] <emmajane> http://bazaar-vcs.org/static/
[07:07] <igc> emmajane: one more thing we discussed on the list ...
[07:07] <emmajane> kirkland, I can't figure out how to make it not load inline.
[07:07] <igc> emmajane: the subtext for qdiff
[07:07] <kirkland> emmajane: the results?
[07:08] <emmajane> kirkland, yeah
[07:08] <lifeless> fullermd: got any other pet bugs ?
[07:08] <emmajane> igc, Either I haven't found that yet, or I can't remember finding it.
[07:08] <igc> should just be "Track changes easily with QBzr."
[07:08] <emmajane> with a link?
[07:08] <emmajane> or no link.
[07:08] <igc> emmajane: they can't dwnload qdiff as such
[07:08] <emmajane> k
[07:09] <igc> I don't think it needs a link
[07:09] <fullermd> lifeless: Not that come to mind.  Lemme see if anything discrete jumps out of what LP thinks I'm related to...
[07:09] <kirkland> emmajane: http://pastebin.ubuntu.com/281892/
[07:09] <kirkland> emmajane: you need that snippet wherever you want your results
[07:09] <emmajane> igc, uploaded
[07:10] <kirkland> emmajane: changing, of course, the id from mine to yours
[07:10]  * emmajane nods
[07:10] <emmajane> kirkland, and if I want it on another page?
[07:10] <emmajane> like a proper form ought to work? ;)
[07:11] <emmajane> or rather, is it possible (for now) just to dump it to a google provided page?
[07:12] <kirkland> emmajane: you just change the action of your form
[07:12] <emmajane> kirkland, also? why are you still awake answering my questions at 1am? :)
[07:12] <kirkland> emmajane: why are you still awake?  :-)
[07:13] <kirkland> emmajane: i'm fighting eucalyptus
[07:13] <emmajane> kirkland, I asked you first! ;)
[07:13] <kirkland> :-)
[07:13] <emmajane> I'm guessing eucalyptus is not what I think it is.
[07:13] <fullermd> lifeless: Nothing particularly recent anyway.  Plenty of things I'd like to see, but...
[07:13] <kirkland> emmajane: okay, so whats the location of your results page?
[07:14] <emmajane> kirkland, I'm inventing one now.
[07:14] <emmajane> I was thinking it should go to google.
[07:14] <emmajane> so now I'm making a search results .html file.
[07:14]  * emmajane tries to remember not to cuss in the commit messages. :)
[07:15] <jfroy> emmajane: the navigation tabs look wrong on Safari I think
[07:15] <emmajane> "wrong" doesn't help me much
[07:15] <jfroy> get the browser and see for yourself :p
[07:15] <lifeless> fullermd: no worries
[07:15] <lifeless> I've just been trying to make dirstate really robust
[07:15] <lifeless> tired of corrupt dirstate files
[07:16] <jfroy> http://home.devklog.net/~bahamut/tabs.png
[07:16] <jfroy> or not
[07:16] <jfroy> ok go now
[07:16] <jfroy> mv-ed the file in the wrong directory :|
[07:19] <emmajane> hm. I already solved that problem.
[07:20] <igc> poolie: how often does /static/ auto-refresh from the branch
[07:21] <fullermd> Yeah.  I remember the first few versions after 0.15, when I kept finding new ways to trip it up every few weeks.  It really had it in for me for a while there   :|
[07:21] <fullermd> (and not just for my inspired proliferation of pronouns)
[07:22] <emmajane> kirkland, ok, that's what had me. I don't have a <form> according to what Google told me to insert into my page template. Which means there's no where to tell it to go to a secon dpage.
[07:22] <kirkland> emmajane: what's your results page?
[07:22] <kirkland> emmajane: i'll give you the two snippets
[07:23] <emmajane> the file name?
[07:23] <kirkland> emmajane: http://pastebin.ubuntu.com/281902/
[07:23] <kirkland> emmajane: replace http://foo with your results page
[07:23] <kirkland> emmajane: and replace the cx with your cx
[07:24] <emmajane> OH!
[07:24] <igc> emmajane: more feedback from the list discussions ... (nothing important at this time of night)
[07:24] <emmajane> kirkland, you just ignore their javascripty thing.
[07:24] <igc> emmajane (1) text size is apparently too small
[07:24] <emmajane> igc, it's using ems now.
[07:24] <kirkland> emmajane: and this goes on the results page: http://pastebin.ubuntu.com/281904/
[07:24] <igc> (2) abentley mentioned extra whitespace after the footer - seems ok to me
[07:25] <kirkland> emmajane: i gotta call it a night
[07:25] <kirkland> emmajane: messages logged; ping me tomorrow if you're still having issues
[07:25] <kirkland> g'night
[07:25] <emmajane> igc, I'm ignoring the whitespace. it's because of the extra clears used to make sure the background extends properly.
[07:25] <emmajane> igc, messing with it could wreck it. ;)
[07:25] <emmajane> kirkland, thank you :)
[07:25] <emmajane> kirkland, I owe you loads of $drink
[07:26] <igc> (3) that's all I can recall right now (except more carousel images)
[07:26] <kirkland> emmajane: heh ;-)  thx
[07:26] <emmajane> igc, ok. let me just figure out the search and then I'll ping you.
[07:34] <vila> hi all
[07:47] <igc> emmajane: that cascading header link problem occurs on IE8 as well as Safari
[07:47] <igc> emmajane: ok on FF on Vista and Ubuntu though
[07:47] <emmajane> igc, I'm probably just going to switch it back to what I had that worked instead of inserting random CSS from someone on the list.
[07:47] <emmajane> seeing as what I had was browser tested. :)
[07:48] <igc> emmajane: yep
[07:49] <igc> emmajane: I'm heading off early today - family stuff to do
[07:49] <igc> emmajane: poolie might be around later if you have questions
[07:49] <emmajane> igc, I'll hopefully be asleep shortly. it's nearly 3am here.
[07:49] <igc> night all
[07:50] <igc> emmajane: sounds a good idea :-)
[07:50] <emmajane> igc, have a good afternoon
[08:00] <emmajane> igc, ok. I've pushed the latest that includes the template for search results. It's not working locally, but I'm sure that isn't a surprise. sleep is next on the agenda for me.
[08:01] <tolstoy> jfroy: The Mac OSX installer (snow leopard) #4 works! Even for me! Thanks for all the effort.
[08:02] <jfroy> tolstoy: good to know
[08:02] <jfroy> The PyCrypto warnings are gone?
[08:02] <tolstoy> Yep.
[08:16] <lifeless> spiv: if you have time in your day, I have two 2.0.x patches I'd love reviews on :)
[08:18] <spiv> lifeless: I'll take a look and see if I can manage something before heading to yoga...
[08:43] <lifeless> spiv: thanks
[09:10] <poolie> hi igc, lifeless, spiv (where applicable)
[09:11] <vila> hello poolie :-P
[09:11] <poolie> hey there
[09:11]  * poolie is swallowed by a meeting
[09:11] <vila> hehe
[09:12] <davidstrauss> lifeless: Re: the issue on the corrupted dirstate, I have the shared branch storage .bzr/, but I've converted all branches to be standalone.
[09:14] <lifeless> kk; it'll be only in the wt so we can't really progress it
[09:15] <vila> lifeless: related to dirstate, a way to force dirstate re-build from scratch could help in many circumstances, is that something that you can easily add in dirstate2 (or even dirstate) ?
[09:20] <lifeless> vila: just an automated 'remove-tree; checkout .' ?
[09:21] <vila> kind of, don't touch my tree :D
[09:22] <vila> the idea is that it's needed in contexts where you need the dirstate even in somewhat buggy contexts so the less commands are used the better
[09:27] <jtv> lifeless: we're suddenly hitting bug 375013 on lp branches.  Any idea what changed & what we can do about it?
[09:28] <lifeless> what do you mean 'on lp branches'
[09:28] <jtv> lifeless: on lp-hosted branches.
[09:29] <lifeless> details man!
[09:29] <jtv> We're committing translations to them using the commit-preview-tree trick.  This started giving errors for some branches.
[09:30] <lifeless> those branches are stacked; you can't commit directly to them
[09:32] <jtv> so have to branch-commit-push like regular people?
[09:32] <lifeless> yes
[09:32] <lifeless> its a limitation/bug
[09:32] <lifeless> can be fixed but not trivially
[09:33] <lifeless> we have certain invariants we require repositories (which every branch has one) to maintain
[09:33] <jtv> there's a workaround in the bug description...  does it "fix up" the branch for thus usage permanently?
[09:33] <lifeless> and commit wasn't maintaining them, this was causing corrupt branch errors
[09:33] <lifeless> jtv: no, it makes a local branch
[09:33] <lifeless> 'checkout' does a full clone
[09:34] <jtv> similar to 'branch'?  Or is it lightweight?
[09:34] <lifeless> ==branch
[09:35] <lifeless> if this is for translation
[09:35] <lifeless> I suggest saying 'can only be done to series'
[09:35] <lifeless> and having some glue in lp that makes sure series branches are not stacked.
[09:35] <lifeless> or something like that
[09:35] <lifeless> hmm, not well thought out.
[09:36] <lifeless> anyhow, your users need to do 'bzr reconfigure --branch URL' where URL is the lp url to the branch they want translations to go into
[09:37] <lifeless> jtv: sorry, --unstacked
[09:37] <jtv> lifeless: yes, this is for translations... I wouldn't want to add a restriction like that; I have heard rumblings about branches becoming stacked by default.
[09:38] <lifeless> branches are stacked by default
[09:38] <jtv> then what are they stacked on if no parent is given?
[09:38] <lifeless> as long as their is somewhere to stack them and the palce to stack them is itself stackable (so we don't de facto require a minimum bzr that group don't require
[09:38] <jtv> ah
[09:38] <lifeless> the trunk series
[09:39] <jtv> so about bzr reconfigure...  what's that do?
[09:39] <jtv> I'm assuming it'd upset people if we did it for them...
[09:39] <jtv> ...at least if we did it quietly.
[09:45] <lifeless> I don't think it would upset them
[09:45] <lifeless> it may disrupt access while its done though [I haven't checked]
[09:46] <jtv> hah... we lock the branch anyway
[09:46] <jtv> so what does it do?  If it were completely harmless, it'd be automatic.
[09:47] <lifeless> it does a big fetch
[09:47] <lifeless> pulls in all the unfetched data
[09:47] <lifeless> then toggles the bit that says 'stacked' to say 'not stacked'
[09:52] <jtv> So at that point it draws a static copy from the branch it was stacked on, and replaces its stacking with that copy?
[09:52] <bialix> hello igc
[09:52] <bialix> igc: why not show bzr-explorer screenshot on new bzr site instead of qdiff? why???
[09:56] <lifeless> jtv: uhm, something like that ;P
[09:56] <jtv> which sounds like it might very well upset some users...
[09:56] <lifeless> jtv: huh? why
[09:57] <jtv> Because updates from the stacked-on branch would stop showing up in the stacked branch, wouldn't they?
[09:58] <lifeless> no, updates don't show up in other branches anyway
[09:58] <lifeless> this is a sharding layer change
[09:58] <lifeless> to put it in db terms
[09:58] <lifeless> semantically transparent
[09:59] <jtv> oic
[09:59] <jtv> so merely less efficient in storage, that sort of thing?
[09:59] <jtv> which in this case is our problem anyway, not the users'
[10:01] <lifeless> right
[10:01] <lifeless> thus, 18:44 < lifeless> I don't think it would upset them
[10:02]  * jtv comprehends
[10:04] <jtv> lifeless: so just bzr reconfigure --unstacked lp:~my/project/branch would do it?  Then we can recommend that as a workaround, and figure out a good way to automate it.
[10:04] <lifeless> yes
[10:05] <jtv> any easy way to do it straight from bzrlib?  or better to go with the command-line client?
[10:07] <lifeless> branch.set_stacked_on_url(None)
[10:09] <jtv> that's actually easier
[10:09] <jtv> lifeless: I suppose I can just do that before exporting, without checking if it's actually needed first?
[10:10] <lifeless> jtv: uhm, I'm not sure I'd do that ;)
[10:10] <lifeless> have a poke at the code first...
[10:10] <jtv> ok, I'm sure there's a matching getter that I can check first
[10:11] <jtv> if branch.get_stacked_on_url(): branch.set_stacked_on_url(None)
[10:13] <lifeless> yes, thats safe
[10:13] <lifeless> I'm not sure that setting it unconditionally is /unsafe/ mind you, just ECautious
[10:13] <jtv> Right
[10:14] <jtv> and if lifeless is not sure, I'm not touching anything at all  :)
[10:19] <jtv> lifeless: thanks manily!
[10:20] <lifeless> de nada
[10:56] <nedosa> lifeless: quick question, so bzr rebase doesn't support re-arranging commits, is that right ?
[10:58] <Lo-lan-do> nedosa: I believe it doesn't
[10:59] <nedosa> Lo-lan-do: cheers, is there any way around it  ?
[11:04] <Lo-lan-do> No easy way that I know of. You can use bzr replay by hand, but it's not going to be as slick.
[11:08] <nedosa> Lo-lan-do: is bzr replay a plugin ?
[11:09] <luks> it's a command from the bzr-rewrite plugin
[11:09] <Lo-lan-do> It's in rebase
[11:10] <luks> wasn't that renamed to bzr-rewrtie?
[11:11] <Lo-lan-do> Was it? I don't know.  Feel free to ignore me :-)
[11:11] <lifeless> yes, it was renamed
[11:11] <lifeless> nedosa: replay is in the bzr-rewrite plugin
[11:12] <lifeless> nedosa: and you could use that to reorder, approximately.
[11:12] <lifeless> it will be a bit clunky, we don't have a good answer to history editing yet.
[11:12] <Lo-lan-do> Is there something for squashing yet?
[11:12] <nedosa> lifeless: cheers, will give that a try
[11:12] <lifeless> Lo-lan-do: merge
[11:13] <Lo-lan-do> lifeless: It still keeps the intermediate revisions, or did I miss something else?
[11:14] <luks> bzr revert --forget-merges
[11:14] <Lo-lan-do> Nice.
[11:25] <nedosa> lifeless: do you think your dev branch of the bzr-rewrite plugin is fairly reliable ? having a hard time locating the bzr rewrite plugin :)
[11:26] <lifeless> jelmer: ^
[11:27] <lifeless> nedosa: no comment :O
[11:27] <lifeless> nedosa: but have you tried lp:bzr-rewrite ?
[11:28] <nedosa> lifeless: ah sorry, my siliness
[11:29] <nedosa> so seems like bzr-rebase is being renamed to bzr-rewrite
[11:38] <SamB_XP> hmm, there should be a "motd" on lp:bzr-rebase to announce this ...
[11:56] <mereandor> hi! I have a problem with "bzr export" when LC_ALL=C - it works just fine with the normal locale - is there a way to work around this?
[11:57] <lifeless> mereandor: details please :P
[11:57] <mereandor> http://nopaste.info/b495a6edc9.html
[11:57] <mereandor> when I use LC_ALL=C bzr export I get this error
[11:58] <mereandor> without the LC_ALL it works just fine
[11:58] <lifeless> ok, you have a path that is not ascii
[11:58] <mereandor> in the repository or in my filesystem?
[12:01] <lifeless> not sure from the traceback, but I'd suspect repository
[12:01] <mereandor> ok
[12:02] <mereandor> is there a way to make bzr accept unicode filenames?
[12:02] <lifeless> anyhow, to handle non-ASCII we need a non-ASCII locale; such as UTF8 or whatever
[12:02] <mereandor> ok
[12:02] <lifeless> mereandor: we handle unicode filenames, thats what LC_ALL=OTHER_THAN_C lets us do
[12:02] <lifeless> LC_ALL=C -> ASCII only
[12:04] <mereandor> ok so I have to change the locale to something sensible
[12:05] <mereandor> thanks a lot for your help
[13:42] <johnf> so if a bzr check gives bzr: ERROR: parent_id {53@91d23e16-c8f7-0310-bc44-da976c688e4e:customer_care%2Ftrunk:lib%2FBulletproof%2FPlan} not in inventory
[13:42] <johnf> what would my next step be?
[13:47] <lifeless> install bzr 2.0.0 and call me in the morning
[13:49] <johnf> yeah just realised this server is running 1.13
[13:51]  * Lo-lan-do wants 2.0 in bpo
[13:52] <johnf> Lo-lan-do: let me see what I can do
[13:56] <Lo-lan-do> johnf: Actually, I can wait for a few weeks.  Give it time to propagate to testing first :-)
[13:56] <Lo-lan-do> (I can do a local backport myself if needed, I'm just going to need an "official" one for a client in a few weeks)
[14:06] <phinze> oh boy, now i've gone and done oit
[14:07] <phinze> it started by getting "Tree transform is malformed" on a bzr shelve operation
[14:07] <phinze> but now i get a StopIteration on all bzr shelve commands
[14:07] <phinze> but i needed shelf #1 :(
[14:09] <phinze> time to root around in .bzr i suppose ... if anybody has any tips i'd much appreciate it
[14:13] <vila> phinze: what did you do ?
[14:14] <phinze> vila: i believe it may have had to do with shelving additions of several binary (swf) files
[14:14] <phinze> all's well now, i reached into .bzr/checkout/shelf/ and (after backing it up) removed 5 1.5MB shelf-N files and renamed shelf-4 (at 85K) to shelf-1
[14:14] <vila> phinze: have a look in .bzr/checkout/shelf, you'll find several files there, moving them around should allow you to identify the culprit
[14:15] <phinze> one step ahead of you :)
[14:15] <vila> phinze: :D
[14:15] <vila> the renaming was optional and dangerous (who told you that number wasn't used somewhere else ? )
[14:15] <vila> ;-)
[14:15] <phinze> always nice when the internals of my tools are relatively sane
[14:16] <phinze> heh, well... ls told me! :)
[14:35] <johnf> lifeless: similar error now
[14:35] <johnf> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', '53@91d23e16-c8f7-0310-bc44-da976c688e4e:customer_care%2Ftrunk:lib%2FBulletproof%2FPlan'
[14:35] <johnf> reason: Parent not in inventory.
[14:35] <johnf> that's on 2.0
[14:38] <jelmer> johnf: is this an import from svn made using an older bzr-svn version?
[14:39] <johnf> jelmer: yes
[14:39] <johnf> well a branch of an olf svn tree anyway
[14:39] <johnf> old even
[14:47] <jam> morning all
[15:38] <jam> barry: ping
[15:39] <barry> jam: pong
[15:39] <barry> hiya!
[15:39] <jam> hey
[15:39] <jam> Thought it might work better to do a bit more live support
[15:40] <jam> rather than via email
[15:40] <barry> jam: just read your message, yes, thanks!
[15:41] <jam> barry: so lets start with
[15:41] <jam> sftp ...
[15:41] <jam> cd ...
[15:41] <barry> jam: aside: i really think we need that big launchpad button to upgrade a branch.  i suspect my network is not stable enough to complete such a long running task
[15:41] <jam> ls .bzr/
[15:41] <barry> sftp> cd ~mailman-coders/mailman/3.0
[15:41] <barry> sftp> ls .bzr
[15:41] <barry> .bzr/README               .bzr/branch               .bzr/branch-format
[15:41] <barry> .bzr/branch-lock          .bzr/repository           .bzr/repository.backup
[15:41] <jam> barry: you could add my ssh public key to let me connect as you and have me do it :)
[15:41] <jam> (you can always remove it after)
[15:41] <jam> ls .bzr/repository
[15:41] <jam> ls .bzr/repository.backup
[15:42] <barry> jam: i wouldn't mind doing that, but i kind of want to feel the pain so i have a better idea of what's happening ;)
[15:42] <jam> (btw, I agree that we should be creating the new repo somewhere *else* and then move it into place... not sure why that design wasn't chosen.)
[15:42] <jam> barry: ssh devpad; screen; bzr upgrade ...
[15:42] <jam> ?
[15:42] <jam> of course ,the best way to do it is:
[15:42] <jam> bzr branch lp:mailman
[15:42] <jam> cd mailman
[15:42] <jam> bzr upgrade
[15:43] <jam> bzr push lp:~mailman/mailman/trunk-2a
[15:43] <barry> jam: +1 on screen
[15:43] <barry> jam: i've done that (called it mm3-2a)
[15:43] <barry> jam: but i really want my 3.0 trunk branch to be called "3.0" :)
[15:43] <barry> sftp> ls .bzr/repository
[15:43] <barry> .bzr/repository/format                  .bzr/repository/indices
[15:43] <barry> .bzr/repository/lock                    .bzr/repository/obsolete_packs
[15:43] <barry> .bzr/repository/pack-names              .bzr/repository/packs
[15:43] <barry> .bzr/repository/shared-storage          .bzr/repository/upload
[15:43] <barry> sftp> ls .bzr/repository.backup
[15:43] <barry> .bzr/repository.backup/format           .bzr/repository.backup/indices
[15:43] <barry> .bzr/repository.backup/lock             .bzr/repository.backup/obsolete_packs
[15:43] <barry> .bzr/repository.backup/pack-names       .bzr/repository.backup/packs
[15:43] <barry> .bzr/repository.backup/shared-storage   .bzr/repository.backup/upload
[15:44] <barry>  
[15:44] <jam> ls -l .bzr/repository/pack-names .bzr/repository.backup/pack-names
[15:44] <barry> sftp> ls -l .bzr/repository/pack-names .bzr/repository.backup/pack-names
[15:44] <barry> -rw-r--r--    0 1001     1001           72 Sep 29 21:57 .bzr/repository/pack-names
[15:44] <barry>  
[15:45] <jam> ls -l .bzr/repository.backup/pack-names
[15:45] <jam> (check if there is a typo there)
[15:46] <barry> ah, right, i thought that looked weird.  sec...
[15:46] <barry> ls -l .bzr/repository.backup/pack-names
[15:46] <barry> -rw-r--r--    0 1001     1001          966 Sep 29 21:57 .bzr/repository.backup/pack-names
[15:46] <barry>  
[15:47] <jam> so if it was up to me, I would do
[15:47] <jam> rmtree backup.bzr
[15:47] <jam> rm tree .bzr/repository
[15:47] <jam> mv .bzr/repository.backup .bzr/repository
[15:48] <jam> though you probably need something like a gui client or hitchhiker to get 'rmtree'
[15:48] <barry> i've never used hitchhiker.  maybe time to start.  but... are you sure that's safe?
[15:49] <jam> barry: you just said you have another copy of it locally, right?
[15:49] <jam> but yeah
[15:49] <jam> it should be ok in this situatio
[15:49] <jam> of course, if you really want to do it
[15:49] <jam> rmtree .bzr
[15:49] <jam> bzr push lp:mailman --use-existing-dir
[15:49] <jam> since you already have a local conversion
[15:50] <barry> jam: probably: cd mm3-2a; bzr push lp:~mailman-coders/mailman/3.0 --use-existing-dir (since i de-linked the dev focus when i started)
[15:50] <barry> jam: i'm willing to try that
[15:51] <jam> barry: You also can just go onto launchpad and rename the mm3-2a
[15:51] <jam> or use the launchpad gui to delete a branch, etc
[15:51] <barry> jam: hmm, yeah, you're right!
[15:51] <barry> jam: delete the 3.0 branch, rename mm3-2a to 3.0
[15:52] <jam> right
[15:52] <barry> jam: re-link the dev focus to 3.0
[15:52] <jam> the only issue is if people are currently stacked on your 3.0 branch
[15:52] <jam> it won't let you delete it
[15:52] <jam> but I think it will let you rename it
[15:52] <barry> jam: thanks.  sometimes the obvious is staring you right in the face :)
[15:52] <jam> If it doesn't let you, we can work around using --use-existing-dir
[15:52] <barry> right.  i think we have no stacked branches on 3.0, but i'll find out
[15:52] <barry> jam: +1.  give me a sec to try it...
[15:54] <jam> if you do have stacked branches, they'll have to then be upgraded before they work again, but yeah, let me know
[15:54] <jam> vila: morning, can I ask a question
[15:55] <vila> morning jam ! Sure ask :)
[15:56] <jam> vila: I'm trying to do some memory profiling (as I think you know) but I don't have a 64-bit python version anywhere
[15:56] <jam> do you have one I could have access to ?
[15:56] <vila> hmm, as on babune ?
[15:56] <jam> vila: something like that
[15:56] <barry> jam: there were merge proposals hanging off the old branch.  even though they were merged, lp would make me delete them, so instead, i renamed it and moved mm3-2a to 3.0
[15:56] <jam> I'd need a shell account, etc
[15:57] <jam> barry: sounds reasonable
[15:58] <vila> jam: yeah, sure, appetizers are included
[15:58] <barry> jam: thanks!  i will write up my experiences and post them to the bazaar mailing list.  hopefully it will help make life easier for the next person.  i really appreciate the help
[16:00] <jam> barry: yeah, I'm sorry it was a pita for you
[16:00] <jam> it certainly is something we should do better
[16:00] <vila> jam: what's your preferred ssh key on lp ?
[16:01] <vila> jameinel@samus  ?
[16:01] <barry> jam: yep, though i don't mind slogging through it to identify the pain points
[16:09] <jam> vila: yeah, I think that is good
[16:09] <vila> shudder, reboot after panic, writing crash summary, /: write failed, file system is full :-(
[16:09] <jam> vila: ouchie!!!
[16:09] <vila> jam: well, only there are 2 with that comment, I pick the first
[16:44] <Zelut> I just did a pull, it suggested I run 'bzr upgrade' which i did, and now it wont let me push my changes back.
[16:45] <Zelut> [cedwards@daphne origami]$ bzr push lp:origami
[16:45] <Zelut> Format <RepositoryFormatKnit1> for lp-46123344:///~christer.edwards/origami/trunk/.bzr is deprecated - please use 'bzr upgrade' to get better performance
[16:45] <Zelut> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~christer.edwards/origami/trunk/.bzr/)
[16:45] <Zelut> is not compatible with
[16:45] <Zelut> any suggestions?
[16:45] <Zelut> CHKInventoryRepository('file:///home/cedwards/origami/.bzr/repository/')
[16:45] <Zelut> different rich-root support
[17:18] <Tak> does launchpad support that format yet?
[17:19] <Tak> also, is there any reason that "Pull New Revisions" in BazaarExplorer doesn't behave the same as `bzr pull`?
[17:23] <asabil> Zelut: you need to upgrade your repository a well in launchpad
[17:27] <Zelut> asabil: can you tell me how to do that?
[17:27] <jelmer> Zelut: update your local repository to 2a
[17:27] <jelmer> Zelut: bzr upgrade --2a <url>
[17:32] <Zelut> thanks. that seems to have fixed it.
[21:00] <tsmith> is this the help chanel or the dev channel or both?
[21:01] <tsmith> So, there are times when I just cna't seem to get a fix to work; and I end up w/ lots of commits like "Fixes issue #1" "Fixes issue #1 try 2" so on and so on...sometimes up to 10 tries.  Is there a way to distribute changes to an external server, and revert them all as a group?
[21:21] <Keybuk> bzr: ERROR: 77afdcdf611d88cf3e8b0806fd04c56c.tix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[21:21] <Keybuk> help!
[21:24] <lifeless> Keybuk: head the file
[21:27] <Keybuk> lifeless: the file?
[21:27] <Keybuk> debian/changelog?
[21:28] <Keybuk> oh, you mean find the .tix file under .bzr ?
[21:28] <Keybuk> it's a file of 316 zeros
[21:29] <lifeless> Keybuk: you had a system crash, didn't you
[21:29] <Keybuk> nope
[21:29] <Keybuk> ah, no, I did copy this branch off the system that crashed
[21:29] <Keybuk> yes
[21:29]  * lifeless suspects it was running ext4
[21:30] <Keybuk> indeed
[21:30]  * lifeless wants fbarrier very badly indeed
[21:30] <Keybuk> fpony ()
[21:30] <lifeless> at 316 bytes it was probably a new commit not a repack, so we don't have the data at all
[21:31] <lifeless> are the other files with the same prefix also zeroed?
[21:31] <lifeless> and how old a ext4 version was it running when the crash happened?
[21:32] <Keybuk> so I tried to branch it again
[21:32] <Keybuk> then I got
[21:32] <lifeless> the first question is to see if we have any hope of recovery; the latter is for input to whether bzr should start fsyncing/add an option
[21:32] <Keybuk> bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66', 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh')]).
[21:33] <lifeless> branch from.. the old machine?
[21:33] <Keybuk> no, LP
[21:33] <Keybuk> bzr branch lp:~ubuntu-core-dev/upstart/ubuntu
[21:33] <Keybuk> crashed with that
[21:33] <lifeless> una momento
[21:35] <lifeless> works for me
[21:35] <lifeless> cd /tmp/
[21:35] <lifeless> robertc@lifeless-64:/tmp$ bzr branch lp:~ubuntu-core-dev/upstart/ubuntu
[21:35] <lifeless> Branched 1223 revision(s).
[21:36] <lifeless> robertc@lifeless-64:/tmp$
[21:36] <lifeless> now, I'm not in core dev
[21:36] <Keybuk> hasn't for me twice in a row
[21:36] <Keybuk> same failure both times
[21:36] <lifeless> so lets look at what lp thinks
[21:37] <lifeless> what does 'bzr revno lp:~ubuntu-core-dev/upstart/ubuntu' report for you?
[21:37] <Keybuk> 1223
[21:38] <lifeless> ok
[21:38] <lifeless> try this
[21:38] <lifeless> bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu
[21:38] <lifeless> if that works for you, the writable copy on lp is missing those texts
[21:38] <lifeless> probably from a bug we closed early this year
[21:39] <lifeless> I'll find you the fix script in a minute, and you should run that
[21:41] <Keybuk> that did, indeed, work
[21:42] <lifeless> ok
[21:42] <lifeless> cd to that branch
[21:42] <Keybuk> yup
[21:42] <StyXman> does anyone know any other free project hosting wich supports bazaar besides launchpad? I'm just looking for options...
[21:43] <lifeless> grab this file
[21:43] <lifeless> http://launchpadlibrarian.net/26166834/fix-branch.py
[21:43] <lifeless> (linked from https://bugs.edge.launchpad.net/launchpad-code/+bug/354036)
[21:44] <Keybuk> lifeless: IndexError: list index out of range
[21:44] <Keybuk> oh, I see, I need to give it "."
[21:44] <Keybuk> ok
[21:44] <Keybuk> but now what?
[21:44] <Keybuk> warcraft upstart% bzr push --remember lp:~ubuntu-core-dev/upstart/ubuntu
[21:44] <Keybuk> No new revisions to push.
[21:44] <lifeless> actually, as I look deeper you have a unique issue
[21:45] <lifeless> You're using 2.0.0 ?
[21:45] <Keybuk> yes
[21:45] <Keybuk> though I suspect for the first time
[21:45] <lifeless> ok, I'm going to file a bug and get back to you about how to correct this
[21:45] <lifeless> actually, lets fix it
[21:45] <lifeless> and I'll file a bug separately
[21:45] <lifeless> python
[21:45] <lifeless> >>> import bzrlib.repository
[21:45] <lifeless> source = bzrlib.repository.Repository.open('.')
[21:46] <lifeless> target = bzrlib.repository.open('bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu/')
[21:46] <lifeless> source.lock_read()
[21:46] <lifeless> target.lock_write()
[21:46] <Keybuk> AttributeError: 'module' object has no attribute 'open'
[21:47] <lifeless> stream = source.texts.get_record_stream([('texts', 'process.c-20060804042848-002ec799c7183356',
[21:47] <Keybuk> ok
[21:47] <lifeless>                 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356',
[21:47] <lifeless>                 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66',
[21:47] <lifeless>                 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh')], 'unordered', True)
[21:47] <Keybuk> ok
[21:47] <lifeless> (the attribute error - missing 'Repository' as per the line before)
[21:47] <lifeless> target.texts.insert_record_stream(stream)
[21:47] <Keybuk> right
[21:47] <Keybuk> bzrlib.errors.RevisionNotPresent: Revision {[('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c')]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(<bzrlib.btree_index.BTreeGraphIndex object at 0x32d8090>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5e10>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5bd0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5990>, <b
[21:47] <Keybuk> zrlib.btree_index.BTreeGraphIndex object at 0x32ce510>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d55d0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5390>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5150>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2ed0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2c90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2a50>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2810>
[21:47] <Keybuk> , <bzrlib.btree_index.BTreeGraphIndex object at 0x32d25d0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2390>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2150>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32ceed0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32cec90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32cea50>)), <bzrlib.knit._DirectPackAccess object at 0x32cc850>)".
[21:48] <lifeless> \o/
[21:48] <lifeless> ok, I'm filing a bug
[21:48] <lifeless> this needs deeper checking
[21:48] <lifeless> are you 'keybuk' on launchpad ?
[21:49] <Keybuk> no, 'scott'
[21:49] <lifeless> does 'bzr check' pass for you?
[21:51] <Keybuk> in the checkout-from-http?
[21:52] <Keybuk> yes, ish
[21:52] <Keybuk>   2259 revisions
[21:52] <Keybuk>    626 file-ids
[21:52] <Keybuk>      2 inconsistent parents
[21:53] <lifeless> ok, just realised I didn't transform the error keys
[21:53] <lifeless> this will work:
[21:54] <lifeless> http://pastebin.com/fdb29168
[21:54] <Keybuk> ok
[21:55] <Keybuk> that did not error
[21:55] <Keybuk> now what do I do?
[21:55] <lifeless> cool
[21:55] <lifeless> try branching again
[21:55] <lifeless> from the normal url
[21:56] <Keybuk> ok...
[21:56] <Keybuk> is branching
[21:59] <lifeless> success?
[22:00] <Keybuk> bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66', 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh'), ('texts', 'main.c-20060516195723-2691e3b471617c66'
[22:00] <Keybuk> , 'scott@netsplit.com-20090922205552-q4izjm87q1pxjlp6')]).
[22:00] <Keybuk> ;)
[22:00] <lifeless> though art kidding me
[22:01] <lifeless> ok
[22:01] <lifeless> try
[22:01] <lifeless> nosmart+lp:~....
[22:01] <lifeless> [I can't test this, not in the right group]
[22:02] <igc> morning
[22:03] <Keybuk> lifeless: thatest worketh
[22:03] <lifeless> Keybuk: ok, smart server bug, or something approximately like that.
[22:03] <lifeless> Keybuk: filing, high.
[22:04] <lifeless> Keybuk: nothing is wrong with your repo AFAICT.
[22:04] <lifeless> bzr is being bitchy
[22:25] <tsmith> man i tried ext4 and jfs
[22:26] <tsmith> i constantly had to run fsck ;O they jus twouldn't mount!!! corrupted block or something
[22:26] <tsmith> i went back to xfs
[22:27] <lifeless> hi igc
[22:27] <igc> hi lifeless
[22:31] <Keybuk> tsmith: of course, the difference there is that ext4 is *telling* you that your filesystem is corrupted
[22:31] <Keybuk> whereas xfs does it itself quietly ;)
[22:32] <mzz> I haven't had an ext4 fs eat itself yet (but for that matter I haven't had a reiserfs do it yet either, so perhaps I'm just not abusing them enough or something)
[22:32] <lifeless> Keybuk: so how recent was the ext4 kernel that ate that file?
[22:33] <lifeless> [broadly speaking]
[22:33] <mzz> I have had some hardware-level hd trouble though, so I'm more likely to worry about that currently.
[22:33] <Keybuk> lifeless: given that the disk died on the laptop I rescued it from, I'm not entirely blaming ext4
[22:33] <mzz> err, yeah.
[22:34] <lifeless> Keybuk: ah, fair'nuff
[22:34] <lifeless> clickodeath
[22:34] <lifeless> ?
[22:34] <Keybuk> yup
[22:34] <lifeless> whats our hardware support on eeepc's like?
[22:34] <Keybuk> good
[22:34] <lifeless> cool
[22:34] <Keybuk> all diamondville stuff is fully supported
[22:34] <lifeless> Lynne is in love:)
[22:34] <awilkins> I find the most common cause of filesystem corruption I have these days is bad RAM
[22:35] <mzz> I guess that makes sense, since a lot of the important bits should end up cached
[22:36] <awilkins> I had some bad blocks in the first 20MB or so and it made things unstable... you could see it when you booted windows 7 because it was RIGHT in the middle of where the splash movie loaded
[22:36] <tsmith> mzz: you arent' abusing it correclty
[22:36] <tsmith> i can get ext4 to fail in a matter of days
[22:36] <mzz> weird.
[22:36] <tsmith> but i dont know if ext4 was made for my particular needs
[22:37] <tsmith> redditmirror.cc
[22:37] <mzz> I don't shutdown uncleanly *that* often, but I do feel like I actually use the fs.
[22:37] <tsmith> hundreds of millions of small files (jpg, css, html) in tends of thousands of directories, accessed randommly by hundreds of thousands of visitors
[22:37] <tsmith> pushing 100 m hits a week ;/
[22:39] <lifeless> tsmith: it was made to be fast there... no wonder it gets speed wobbles
[22:40] <tsmith> when i was the #1 link on stumbleupon for 3 days, my server was pushing 80% CPU just on IO waits
[22:40] <tsmith> it was crazy
[23:27] <igc> emmajane: did you see the email re the top navigation links still not quite right? The last two are lower than the others
[23:34] <beuno> james_w, hey. bzr is complaining that it doesn't have it's extensions built, after installing from nightlies. Any ideas?
[23:34] <james_w> hmm, maybe pyrex got dropped again
[23:34] <james_w> beuno: please file a bug
[23:39] <lifeless> james_w: last time this happened I suggested you put a check in the nightlies to _require_ the .so's
[23:39] <lifeless> james_w: this time, unless you have a really good reason, I'm going to be much more persistent about this
[23:39] <james_w> I know
[23:39] <james_w> well
[23:39] <james_w> the nightlies use the same packaging as the PPAs
[23:39] <james_w> why not have the check there as well?
[23:39] <lifeless> even more important
[23:39] <lifeless> I'm totally up with that
[23:40] <lifeless> we don't want any deb to ship without the full range of so's
[23:41] <james_w> lp:~bzr/bzr/packaging-{dapper,hardy,intrepid,jaunty,karmic}
[23:41] <lifeless> I'm not blaming you :) I just want to make sure that when the nightlies are fixed, that the problem will stay fixed
[23:41] <lifeless> s/blaming/blaming or accusing/
[23:42] <lifeless> so, there is a bug barry opened
[23:42] <lifeless> I'll add to that that the PPA packaging is used (I didn't know that)
[23:42]  * barry wakes up
[23:42] <lifeless> and if you have time to look at this, you could add the check, otherwise I'll pester johnf to look at it
[23:42] <lifeless> james_w: sound good?
[23:43] <james_w> sure
[23:43] <lifeless> barry: do you have that bug # handy?
[23:43] <lifeless> barry: about the missing .so's
[23:43] <barry> lifeless: let me look
[23:44] <lifeless> [back shortly, foodingk]
[23:45] <barry> lifeless: bug 439100
[23:49] <lifeless> barry: and you're using nightlies?
[23:49] <barry> lifeless: yes, i believe i am (somewhat unintentionally)
[23:49] <lifeless> james_w: are you intending to poke at this?