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