[00:00] <mkanat> mwhudson: I am.
[00:00] <mwhudson> good
[00:02] <mkanat> mwhudson: pygdb gives me a backtrace.
[00:02] <mwhudson> mkanat: that's what it's supposed to do but i guess you mean the other kind :-)
[00:02] <mkanat> mwhudson: Hahaha, yeah. :-)
[00:03] <mkanat> mwhudson: http://pastie.org/979056
[00:03] <mwhudson> mkanat: huh bizarre
[00:03] <mwhudson> mkanat: what version of python are you using?
[00:03] <mkanat> mwhudson: 2.6.2
[00:03] <mwhudson> i've only used it with 2.5, i think
[00:04] <mkanat> mwhudson: Might be related to g.file('/usr/bin/python2.5')
[00:04] <mwhudson> mkanat: :)
[00:04] <mkanat> Nope, that doesn't fix it.
[00:04] <mwhudson> oh darn
[00:05] <mwhudson> mkanat: well, i guess you could poke around in gdb manually
[00:05] <mwhudson> i.e. gdb python2.6 $core
[00:05] <mwhudson> up a few times, see what
[00:05] <mwhudson> p co->co_file_name
[00:05] <mwhudson> says
[00:06] <mkanat> (gdb) p co->co_file_name
[00:06] <mkanat> No symbol "co" in current context.
[00:08] <mkanat> Okay, I at least have a reasonable gdb backtrace now.
[00:08] <mwhudson> type up until you're in PyEval_EvalCodeEx
[00:08] <mwhudson> or whatever
[00:09] <spiv> Good morning.
[00:10] <mkanat> mwhudson: Okay, will do. One sec.
[00:15] <mkanat> mwhudson:
[00:15] <mkanat> (gdb) p co->co_file_name
[00:15] <mkanat> There is no member named co_file_name.
[00:15] <mkanat> (gdb) p co
[00:15] <mkanat> $1 = <value optimized out>
[00:15] <mwhudson> mkanat: co_filename sorry
[00:16] <mkanat> (gdb) p co->co_filename
[00:16] <mkanat> Cannot access memory at address 0x50
[00:16] <mwhudson> mkanat: bing!
[00:16] <mwhudson> mkanat: maybe you need to be using a less aggressively optimized python interpreter?
[00:18] <mkanat> mwhudson: It's the gcc options for compiling python itself, you think?
[00:18] <mwhudson> mkanat: would be my guess, don't really know though
[00:20] <mkanat> mwhudson: It looks like the meliae problem is all in C anyhow, though.
[00:22] <mwhudson> mkanat: ok
[01:16] <lifeless> jam: poolie: spiv: this is the sort of thing I think we should also be looking at - https://bugs.launchpad.net/bugs/586139
[02:14] <Chipaca> hiya
[02:15] <Chipaca> is there a way to tell bzr to not check a certificate? I'm suspecting the answer is "no", which means I'm stuck using svn directly :(
[02:15]  * Chipaca has gotten too used to the bzr goodness
[02:22] <spiv> Chipaca: an HTTP certificate?
[02:22] <spiv> Er, HTTPS, I mean, of course :)
[02:22] <poolie> Chipaca, it rings a bell but maybe there's just still a bug open for it
[02:22] <spiv> If you uninstall pycurl I think bzr won't check
[02:22] <spiv> (because it will use urllib, which doesn't have that facility)
[02:23] <poolie> spiv presumably the actual https is done inside libsvn
[02:23] <mwhudson> Chipaca: what are you trying to do and what problems are you having?
[02:24] <spiv> Ah, I was assuming that if "using svn directly" worked then libsvn doesn't check, but maybe it's that it can check but the svn command has config that can turn that off?
[02:28] <lifeless> the cli prompts
[02:28] <lifeless> and you can ok it
[02:38] <lifeless> igc: ping
[02:44] <Chipaca> right, it says "dude, this cert is, like, way off!" and you say "yeah, whatev"
[02:45] <lifeless> spiv: ping
[02:46] <lifeless> spiv: https://code.edge.launchpad.net/~amanica/bzr/find_bzrdirs-ignore-PermissionDenied-dirs/+merge/24979 has conflicts; is newsmerge able to use branch.conf settings? if so, do you want to request a losa change to set it up for pqm, or do you want me to do that?
[02:46] <lifeless> s/pqm/launchpad
[03:14] <poolie> lifeless, thanks for all the landings
[03:14] <poolie> did i tell you about my wish for xbox-style achievements in launchpad
[03:14] <poolie> "land 20 branches with no rejections"
[03:16] <lifeless> lol
[03:16] <lifeless> have you seen unittest achievements?
[03:16] <poolie> nose achievemnts
[03:16] <poolie> yeah
[03:16] <poolie> this would be a bit less artificial i think
[03:17] <lifeless> pop quiz
[03:17] <lifeless> you've seen aarons change to bzr to cleanup the ui on exit
[03:17] <lifeless> yes?
[03:18] <poolie> yes
[03:18] <lifeless> would you prefer a cleanup global function
[03:18] <lifeless> or initialise() to return a cleanup function to be called
[03:18] <poolie> heh
[03:18] <lifeless> the latter is what I've suggested, and seems to me to be a step towards less globals
[03:19] <poolie> that's a reasonable idea
[03:21] <poolie> lifeless, is pqm working properly?
[03:21] <poolie> it seems suspiciously fast today
[03:21] <poolie> unless they upgraded the hardware and didn't tell me?
[03:22] <poolie> specifically my last commit succeded in 3 minutes elapsed
[03:23] <lifeless> that would be surprising
[03:23] <lifeless> I haven't changed anything
[03:31] <lifeless> poolie: it is running suspiciously quickly
[03:32] <lifeless> last change to Makefile was 6th april
[03:33] <lifeless> losa ping - has anything been changed on balleny vis-a-vis bzr-pqm.conf or related stuff in the last couple of days ?
[03:38] <MWinther> I thought bzr mv --after fromfile tofile would update the repo pointers correctly, even though I stupidly went ahead and moved stuff around... Anyone got a better suggestion? It tells me the new file is already versioned.
[03:39] <lifeless> spiv: ping
[03:40] <lifeless> MWinther: you've probably already added tofile
[03:40] <lifeless> MWinther: so check bzr st and make sure tofile shows as added; if so then 'bzr revert tofile' and then 'bzr move --after fromfile tofile'
[03:41] <MWinther> and that will not change the tofile, but just remove it and then add it again, but as the right file, so to speak?
[03:42] <lifeless> yes, revert of an added file just unadds it
[03:42] <lifeless> but check status first
[03:42] <MWinther> yep, it's added there. thanks!
[03:49] <lifeless> poolie: selftest hole, looking into it
[03:52] <lifeless> poolie: a syntax error in gio_transport led it to just bypass everything; a subunit-glue bug I'll address
[03:53] <MWinther> well, that worked for every file except one... That one says 'File id already exists in inventory as InventoryFile...'
[03:54] <lifeless> check bzr st for oldfile and newfile
[03:54] <MWinther> oldfile is removed, newfile is unknown.
[03:56] <lifeless> spiv: ping?
[03:58] <lifeless> poolie: https://bugs.edge.launchpad.net/subunit/+bug/586176
[04:00] <poolie> sheesh
[04:00] <lifeless> yes, mea culpa
[04:01] <lifeless> I'll do it shortly, probably not today.
[04:01] <poolie> i see this as evidence for having bzr emit a return code, even if subunit pipelines want to ignore it
[04:01] <lifeless> perhaps
[04:02] <lifeless> I don't mean to be equivocal here
[04:02] <lifeless> in hudson there is a 'build' vs 'test' separation
[04:02] <lifeless> where you can succeed at one and fail at the other; in hudson, this would be a failure because hudson looks at the test count
[04:02] <poolie> what should we do in the interim?
[04:03] <lifeless> well, I think the risk of doing nothing until say tuesday (to let spm get back here) is pretty low
[04:03] <lifeless> python 2.4 specific syntax errors are going to be about the only thing pqm will notice that we won't.
[04:04] <lifeless> and I can have a patch for subunit + a patch for bzr to use that prepped early next week
[04:04] <poolie> so things we land but not be tested?
[04:04] <lifeless> no, with the python2.4 syntax error fixed pqm is running tests again
[04:05] <lifeless> http://pqm.bazaar-vcs.org/
[04:05] <poolie> but my patch just slipped in while it wasn't running them?
[04:05] <poolie> hm
[04:05] <spiv> lifeless: pong
[04:05] <lifeless> yes, because the one right before was the gio patch which had the python2.4-breaking thing
[04:05] <poolie> ok
[04:05] <lifeless> spiv: poolie suggests and I agree that we should release 2.1.2 tomorrow
[04:06] <lifeless> spiv: you were working on sigwinch stuff; is 2.1.2 *currently* good-to-go, or do you need to do $something about it ?
[04:06] <spiv> lifeless: re earlier question, news_merge can't use branch.conf yet (although the better-news-merge branch is headed that way)
[04:07] <spiv> I need to do $something.  I just finished lunch, I'll finish that $something now.
[04:07] <lifeless> ok
[04:07] <lifeless> please assertively tell me when its done, I won't do a release tomorrow if I haven't heard from you. And I have a slightly offset-to-be-earlier day tomorrow.
[04:07] <lifeless> which reminds me... goes to mail
[04:07] <poolie> ah right
[04:08] <poolie> if your day is going to be too chopped up to do it, you can bail out
[04:09] <lifeless> poolie: if we're good to go this evening then it should be no trouble at all
[04:09] <lifeless> and I think it will be fine, sigwinch is the only gotcha I know of
[04:12] <spiv> lifeless: ok, will do
[04:13] <poolie> spiv, and you're basically going to take that patch that makes it poll, and put in the logic to use COLUMNS until the size changes
[04:13] <poolie> is that correct?
[04:13] <lifeless> poolie: if, when I go to sleep, 2.1.2 isn't good, I'll mail the list saying that its not copacetic and that I'm bailing :)
[04:15] <spiv> poolie: correct
[04:35] <lifeless> so, fires fought
[04:43] <lifeless> ok
[04:43] <lifeless> I'm putting nose down into this patch
[04:43] <lifeless> its been lingering all week
[04:43] <lifeless> and I wants to be able to use it.
[04:43] <lifeless> if you need me, ring me on skype or something :)
[05:04] <parthm> mgz: ping
[05:04] <lifeless> parthm: its 4am for him
[05:05] <parthm> lifeless: oh :P ... wrong time :) thanks for letting me know.
[05:07] <parthm> lifeless: i was thinking that the try/finally use for opening-read/write of file that mgz did in his recent patch should go into coding-style. is that something we want to follow normally?
[05:07] <lifeless> its there already, i think
[05:10] <parthm> lifeless: i cant seem to find it in doc/developers/code-style.txt .. i mean the explicit closing of file in finally rather chaining open.read/write than leaving it to gc
[05:11] <lifeless> please do add it
[05:11] <lifeless> it may be in developers/*.txt
[05:11] <lifeless> so have a search around
[05:12] <parthm> lifeless: will do. thanks.
[06:46] <parthm> lifeless: i sent the doc patch to pqm and got a mail that its queued. however it doesn't show up in http://pqm.bazaar-vcs.org/ or in feed-pqm. is this normal?
[06:48] <parthm> lifeless: status on https://code.launchpad.net/~parthm/bzr/doc-explicit-file-close/+merge/26121 shows queued and the queue is empty right now.
[06:57] <spiv> parthm: use the queue-by-email option in feed-pqm, rather than the other option ('e' rather than 's')
[06:57] <rsvp> Q: what happens after "bzr rm --keep foo" is executed? Do the all the diff versions of foo kept internally disappear? And so is there a reduction in the size of bzr files? Finally, is there an undo after such execution?
[06:58] <spiv> parthm: the queue-by-launchpadlib (the 's' option) isn't quite ready for use, Launchpad needs a little more work
[06:58] <spiv> It's a bit confusing because 's' used to be the queue-by-email option :/
[06:59] <spiv> rsvp: 'bzr rm' removes the file from the current version of the tree, but the old history is still there
[06:59] <spiv> So it doesn't cause any reduction in size
[07:00] <spiv> You can undo it with "bzr revert foo"
[07:00] <parthm> spiv: thanks for clarifying that. i will set it back to approved and use e.
[07:00] <spiv> parthm: yep, that should fix it
[07:01] <rsvp> spiv, thanks for your response -- so is there another command which will wipe out the old history?
[07:03] <spiv> rsvp: not builtin.  You have to rewrite the history to achieve that.  Possibly the bzr-rewrite plugin can help, otherwise I'd use the bzr-fastimport plugin to export a dump, filter that dump, and import that into a new repository
[07:03] <spiv> rsvp: note that rewriting history like that will make it hard to merge changes from other branches made from the old history :(
[07:05] <rsvp> spiv, sounds a bit hazardous ;-)
[07:06] <parthm> spiv: that worked. thanks :)
[07:07] <rsvp> spiv, thank you very much again for your help.
[07:09] <spiv> rsvp, parthm: you're both welcome :)
[07:25] <vila> hi all
[07:26] <spiv> vila: good morning
[07:26] <spiv> vila: https://code.edge.launchpad.net/~spiv/bzr/no-sigwinch-583941/+merge/26118
[07:26] <vila> spiv: Hopefully the day will continue better than it started, I've just been able to reboot my main mac which refused to do so for almost an hour....
[07:27] <vila> I haven't finished checking the basis stuff, just came here to warm
[07:29] <spiv> vila: ouch :(
[07:30] <vila> spiv: yeah, nightmare, never saw a mac refuse to boot.... not even the Apple logo on grey background.... and finally, hey I'm back, don't worry, nothing happened, yeah sure
[07:32] <vila> spiv: approved (web browser was a low risk try :), I'm less inclined to try to land though
[07:33] <vila> urgh, hidden ff window whining about not recovering session :(
[07:33]  * vila kills more chickens
[07:36] <fullermd> It's a mac; you better just go straight to goats.
[07:41] <spiv> vila: ok, thanks, I'll kick off the landing then
[07:42]  * vila add some goats
[07:42] <vila> err, wait, I don't have goats, rats
[07:46] <vila> hmm, did anybody ever see procmail crashing repeatedly (like hundreds of time in the same second) and filling system log ? (Well the later is OSX reporting crashes, but still)
[07:46] <spiv> vila: ouch, happily (for me), no.
[07:47] <spiv> lifeless: have sent SIGWINCH patch to PQM
[07:49] <vila> *** process 15666 exceeded 500 log message per second limit  -  remaining messages this second discarded ***
[07:49] <vila> don't you love that ? >-}
[07:50] <vila> of course it began at 7pm when I stopped working and crashed... around 5AM ?
[07:50] <vila> Did anybody has a log of this channel and can tell me when I disappeared ?
[07:52] <vila> May 27 05:03:23 bigmamac kernel[0]: hfs: Runtime corruption detected on osx, fsck will be forced on next mount.
[07:52] <vila> here we are, I've got my culprit, may also explain the unusual long time to boot, time for more thorough cheks, cu later
[07:58] <fullermd> 18:59 -!- vila [~vila@lec67-4-82-230-53-244.fbx.proxad.net] has quit [Remote host closed the connection]
[07:59] <fullermd> That would be, what, 7 hours ago?
[08:28] <spiv> parthm: I see your PQM request landed :)
[08:28] <parthm> spiv: yay :) ... i wasn't sure if email would work. haven't tried that before.
[08:29] <spiv> parthm: btw, with the current version of hydrazine, don't add the names of the proposer or lander to the commit message
[08:29] <spiv> parthm: hydrazine now does that for you, so if you do it too you get some redundancy
[08:29] <spiv> parthm: so the latest commit has an amusing message :)
[08:30] <parthm> spiv: yes. i noticed that ... but it was too late by then ... the message has more parthm than actual content :P
[08:31] <spiv> parthm: well, you do deserve some credit after all ;)
[08:37] <parthm> i noticed that diff for the mp https://code.launchpad.net/~snaggen/bzr/gio-transport/+merge/24664 is out of date. setting it from merged->needs review doesn't seem to rescan it.
[08:37] <parthm> are merged mps treated differently for rescan?
[08:39] <spiv> Not sure.
[08:39] <spiv> But probably making a new submission would make a little more sense anyway, if the original proposal has been merged
[08:40] <spiv> If you do it via the Resubmit status it'll even show the original conversation in the new proposal.
[08:44] <parthm> spiv: resubmit did the trick. thanks.
[08:45] <lifeless> merged proposals don't update
[08:45] <lifeless> simple reason, they would be empty
[08:47] <parthm> lifeless: in this case some new revisions were pushed. so setting it back to 'needs review' should probably have worked. but 'resubmit' seems better.
[08:47] <lifeless> perhaps file a bug
[08:47]  * StevenK wonders how to push a 4 pipe branch to lp properly
[08:48] <StevenK> The docs don't read clearly
[08:48] <StevenK> (Or I'm a muppet, which is possible)
[10:35] <YaManicKill> how do i overwrite files on my computer from a bzr branch without removing the old folder?
[10:36] <YaManicKill> cause "bzr branch lp:heybuddy" moans that the folder already exists, but i don't wanna have to delete it everytime i update the files
[10:37] <jpds> YaManicKill: cd heybuddy; bzr pull ?
[10:37] <YaManicKill> jpds: ahhh nice :-) works. thanks
[11:24] <lifeless> night y'all
[14:59] <alex-weej> o hai, i want to review revisions on someone else's branch. i've 'pulled' their branch into my repo but i screwed up because i had my 'trunk' branch in there and now all of their branch is inside that directory
[14:59] <alex-weej> any ideas what i should do?
[15:00] <alex-weej> also it went to the trouble of pulling the whole history which took ages, both my 'trunk' branch and their branch share most of the history
[15:00] <alex-weej> so what did i do wrong there?
[15:06] <parthm> alex-weej: are you using a shared-repo?
[15:07] <cnd> Can someone help me figure out how to do the following in bzr:
[15:07] <cnd> 1. make edit with typo
[15:08] <cnd> 2. make more commits on top of typo
[15:08] <cnd> 3. in git, I do a rebase -i and edit that one commit where I introduced the typo, and the rest of the commits magically are rebased on top of it
[15:08] <cnd> how can I do 3 in bzr?
[15:09] <parthm> cnd: bzr has a rewrite plugin for rebaseing. https://launchpad.net/bzr-rewrite
[15:09] <LeoNerd> Personally I'd branch it. branch the revision with the typo, uncommit, edit, recommit, then replay the rest on top. However, be aware that if you do that, all the later revisions now have a different revid, so other people's branches will now be broken
[15:09] <LeoNerd> so that's a really rude thing to do if anyone else has seen the branch since you made that commit
[15:10] <parthm> cnd: but generally rebasing isn't recommended in bzr. bzr anyway hides merge history by default.
[15:10] <cnd> my use case is that I'm editing multiple commits privately
[15:10] <cnd> and I realized before I went to push that I had a typo
[15:10] <cnd> I want to clean up the history
[15:11] <LeoNerd> See my suggestion then
[15:11] <alex-weej> parthm, i don't know, how do i check?
[15:11] <LeoNerd> (well, it's what I usually do anyway.. perhaps there's a neater solution somewhere)
[15:11] <cnd> LeoNerd: thanks, I'll look at that and bzr-rewrite
[15:12] <alex-weej> parthm, it's ok i just did init-repo on a new directory and branched both of them, it seemed to be more efficient that way
[15:12] <parthm> alex-weej: do you have a directory .bzr/branch
[15:13] <parthm> alex-weej: yes. shared-repo is the suggested way if its a long term project.
[15:13] <alex-weej> parthm, no not in my new one
[15:14] <parthm> alex-weej: yes. so init-repo creates the shared branch. you would typically do.
[15:14] <alex-weej> i want my working tree on another test machine (well a VM actually) -- i'm currently using NFS on my trunk branch folder but obviously if i want to switch to another branch lke with git then i need to update all my NFS stuff
[15:14] <alex-weej> can i use remove-tree on my 3 branches and somehow create a working tree that i can just switch between branches?
[15:14] <parthm> alex-weej: 'bzr init-repo foo && cd foo && bzr branch path-to-trunk'
[15:16] <parthm> alex-weej: so if i get your right you want to do in place switching between branches?
[15:17] <alex-weej> parthm, yeah i think so, like i used to do with git
[15:17] <parthm> alex-weej: so you would start off with a shared repo .. so if we have foo like what was created above. that will save all the history.
[15:18] <parthm> then you have branches 'foo/trunk', 'foo/bar', 'foo/bar' which all share history.
[15:19] <parthm> inside foo you can do 'bzr checkout --lightweight trunk edge'
[15:19] <parthm> you would use foo/edge as a bound branch ... so in the above command edge is bound to trunk.
[15:20] <parthm> once you are done hacking inside edge. you can do say 'bzr switch ../bar' this will bind edge to ../bar branch
[15:21] <parthm> personally i just work inside foo/trunk or foo/bar or foo/baz... as they all share history pull etc. are fast as only little history needs to be gotten.
[15:22] <alex-weej> parthm, ok thanks, my test deployment just wants the code to be in one folder -- i guess i'll use a lightweight checkout
[15:24] <alex-weej> is there anything like git stash? where i can commit my unsaved changes to a temporary branch so that i can switch to another branch?
[15:24] <parthm> alex-weej: bzr has a shelve command. i think it does something similar though i don't know git much.
[15:24] <parthm> and unshelve.
[15:24] <alex-weej> parthm, ok thanks
[15:42] <csgeek> hi all
[15:43] <cnd> I tried doing a bzr rebase --dry-run, but it seems to have made changes to my tree anyways! how do I go back?
[15:43] <cnd> is there something like git reflog?
[15:45] <csgeek> is there a guide to setting up a self hosted version of launchpad?  or is there some hosted version of bzr?  Looking for a nice little web frontend to read history, tickets, code review (would be nice), wiki.. usual tidbits
[15:57] <lifeless> cnd: bzr heads --dead
[15:59] <cnd> lifeless: ok, now how do I get one of them back?
[15:59] <cnd> I tried bzr pull . -r <revid>
[15:59] <cnd> but it complained that I've diverged
[15:59] <lifeless> yes, because rebase
[15:59] <lifeless> so --overwrite
[15:59] <cnd> ahhh, ok, thanks
[16:01] <csgeek> is there something like gitosis/gitolite for bzr?  Something that relies on RSA/DSA ssh key authentications rather then having a system user for each person needing to access that location?
[16:02] <lifeless> csgeek: the launchpad ssh hosting server does that
[16:02] <lifeless> you could adapt that to whatever backend you have
[16:04] <csgeek> lifeless: okay.  Is there a proper guide on how to setup/configure the launchpad hosting server? I found the project.. but can't find any decent guides
[16:11] <lifeless> well, for a test environment, see e.g. https://dev.launchpad.net/Running/VirtualMachine + https://dev.launchpad.net/Getting + https://dev.launchpad.net/Code/HowToUseCodehostingLocally
[16:15] <csgeek> lifeless: thank you very much.
[16:15] <lifeless> jam: ping
[16:32] <csgeek> I know that I can can an individual file from a bzr repo.  ie.  bzr cat http://foobar/path/readme.txt  is it possible to checkout only a certain file from a particular tag/revision
[16:32] <lifeless> can can ?
[16:33] <mgz> it's a little bit of a dance.
[16:37] <csgeek> s/can can/can/   the extra can is for extra superior ability
[16:37] <lifeless> csgeek: missing a verb then, I think :)
[16:38]  * lifeless is yak shaving at 3:37am. Not a good sign.
[16:38] <mgz> csgeek, what's the practical difference between cat -r 45 ..../file > ..../file and "checkout only a certain file"?
[16:38] <jelmer> lifeless: :-) What are you working on?
[16:38] <lifeless> jelmer: release process
[16:38] <mgz> you want a bzrdir with.. what?
[16:39] <lifeless> it was rather jumbled up
[16:39] <jelmer> lifeless: ah
[16:39]  * jelmer is looking forward to 2.2.0 - are you doing another beta?
[16:39] <lifeless> 2.1.2 and b3
[16:46] <mgz> jelmer, any insight on how bug 393038 can be reproduced? bzr-git seems to be in the traceback
[16:47] <mgz> the code in osutils is clearly bogus (anything doing `unicode(path)` is much the same as saying "make this look like it works on my machine but break for everyone else"), but could do with a test case
[16:47] <mgz> at a guess, checking out a git branch with latin-1 filename on a utf-8 filesystem?
[16:49] <jelmer> mgz: yeah, I suspect that would trigger it
[17:03] <csgeek> mgz: well.. I want to specify which branch/tag the file comes from ...
[17:03] <csgeek> not sure if cat will let me do that
[17:04] <csgeek> oh.. though -r 45 I would guess it does.
[17:04] <lifeless> :)
[17:04] <mgz> bzr help cat
[17:04] <lifeless> miao
[17:04] <jam> lifeless: pong, what are you doing up?
[17:05] <csgeek> and I presume I can specify -r N , with N being a tag name?
[17:05] <mgz> bzr help revisionspec
[17:05] <lifeless> jam: releasing
[17:06] <lifeless> couldn't sleep @ 3am - hating the bed in this rental place - and I was going to start work @5am anyhow.
[17:06] <lifeless> jam: I wanted to know if releasing.txt was up to date, but its all over the shop, so clearly not.
[17:06] <lifeless> jam: so, I want to know whats *not* documented :)
[17:07] <jam> lifeless: also check 'cycle.txt'
[17:07] <lifeless> oh!
[17:07] <jam> and ppa.txt
[17:09] <jam> I certainly think releasing.txt needs to be brought up to date
[17:09] <jam> but I think stuff like "update freshmeat" etc are all still correct
[17:10] <lifeless> sure
[17:10] <lifeless> I went to execute the algorithm and raised an exception up front :P
[17:12] <csgeek> thank you mgz.. that works.
[17:25] <lifeless> jam: when you do releases
[17:25] <lifeless> jam: do you tag locally, or let pqm merge the version change and *then* do a tag?
[17:25] <jam> lifeless: I *now* do the former
[17:25] <jam> the latter seemed more correct to me
[17:25] <jam> but it is a much larger PITA
[17:26] <lifeless> hmm
[17:26] <jam> especially since the branch itself won't end up with the tag
[17:26] <lifeless> we should work on that
[17:26] <jam> jml did the former, I'm not sure what poolie did, but somewhere in the release process I think poolie and I decided to switch to tagging locally
[17:29] <skeledrew> hello.  i'm getting an error in bzr in downloading wubi "ERROR: Unable to create symlink 'bin' on this platform". any fix for this?
[17:29] <jam> lifeless: for example, if you could feed-pqm and tell it 'tag this bzr-2.1.2 when it succeeds' that would simplify the process and switch to what I consider the "correct" way.
[17:29] <jam> skeledrew: I assume you are on Windows?
[17:30] <skeledrew> yes
[17:30] <jam> ATM, we don't have a workaround for checking out projects that have symlinks on platforms that don't have symlinks
[17:30] <jam> aside from having the upstream remove the symlink...
[17:30] <jam> the other option is to use the cygwin version of bzr
[17:30] <jam> which fakes symlink support
[17:30] <skeledrew> ok
[17:31] <mgz> file a bug with upstream, symlinks aren't portable, and "bin" should be created by the build process, not be part of the revision history
[17:32] <lifeless> jam: it says to 'upload the source tarball on the milestone'
[17:32] <lifeless> jam: but I can't see how to do that without doing a release; is that right ?
[17:32] <jam> lifeless: you have to do the release, and upload to that, yes
[17:32]  * lifeless bugginates
[17:32] <jam> but you upload to 2.1/2.1.2/
[17:33] <lifeless> yes, I was just cross-checking
[17:33] <jam> lifeless: IIRC, if you don't do a release then "lp.net/bzr/2.1/2.1.2" doesn't *exist* yet, since you only have "../bzr/2.1/+milestone/2.1.2"
[17:33] <lifeless> sure
[17:34] <lifeless> I was clarifying an ambiguity between the docs, intent, and lp
[17:34] <lifeless> the intent is not to announce the release
[17:34] <jam> I was just working through the logic to make sure I remembered correctly :)
[17:34] <lifeless> lp announces releases when you do the release thing on the milestone
[17:34] <lifeless> and our docs weren't clear that doing the release was ok
[17:34] <jam> lifeless: last I checked, lp didn't announce until you manually announced, that changed?
[17:34] <lifeless> theres a feed
[17:34] <jam> (it was partially why many of our releases were never announced)
[17:34] <lifeless> and announcements separately
[17:39] <lifeless> https://bugs.edge.launchpad.net/launchpad/+bug/586445
[17:40] <lifeless> huh bah
[17:41] <lifeless> thats not what bug 586445 is
[17:41] <lifeless> Wow
[17:41] <lifeless> I'm not going to try and explain that right now.
[17:47] <jam> lifeless: now that is pretty fun. Wonder if it is was an edg vs normal problem
[17:48] <jam> lifeless:  seems to be bug 583385
[18:10] <lifeless> hmm
[18:10] <lifeless> I probably should have done 2.0.6 first
[18:10] <lifeless> ah well
[18:31] <lifeless> hmm
[18:31] <lifeless> Using default stacking branch /~ubuntu-branches/ubuntu/maverick/bzr/maverick at lp-69641680:///~lifeless/ubuntu/lucid/bzr
[18:31] <lifeless> -   4216kB    26kB/s | Finding revisions
[18:31] <lifeless> little high
[18:35] <lifeless> james_w: oh hahah - merge-upstream in lucid's bzr from tarball + bzr upstream branch [18:36] <lifeless> james_w: it works, which is nice, but it also joins the previously unjoined history, and thats one hellof a lot of merged-revisions :)
[18:39] <james_w> lifeless: \o/
[18:39] <lifeless> jam: do you know, does igc still manually update the pretty docs
[18:40] <lifeless> jam: or is the cron script working ? (see releasing.txt for context)
[18:40] <lifeless> james_w: yeah, fallout from my otherwise perfect patch a while back
[18:40] <lifeless> james_w: I'll file a bug once I finish 2.2b3
[18:40] <lifeless> james_w: the SRU reviewer for 2.1.2 will get a surprise :)
[18:41] <lifeless> 'here, have 35 MB of new history`
[19:51] <lifeless> brekkie time I think
[20:47] <lifeless> ok, that was more painful than I expected.
[20:55] <lifeless> abentley: I'm really liking lp-propose.
[20:55] <lifeless> I wish API's were faster though.
[20:56] <abentley> lifeless, cool.  I wish the APIs were faster too.
[22:02] <Spajderix> Hi
[22:02] <lifeless> hi
[22:04] <Spajderix> when using bzr with bzr+ssh paths it invokes bzr server with parameter --directory=/, directory is always / is there a way to force bzr to send path from given url, eg. when i use bzr+ssh://user@host[/path/to/something] bzr serve will be invoked with --directory=[/path/to/something]?
[22:09] <lifeless> not from the client side
[22:10] <lifeless> you can use a restriction tool on the server side to force that by ssh key or whatever - hum, I think 'rsh' (confusing name, its not the remote shell tool) is one such restriction thing
[22:20] <Spajderix> lifeless: restricting path to given ssh key is no option, because I want one key to access multiple paths on server, is there any way, from environment variable or anything else, to see /path/to/something or even whole bzr+ssh://user@host/path string?
[22:21] <lifeless> the two things are rather disconnected
[22:21] <lifeless> is something actually going wrong in your environment?
[22:21] <lifeless> are you getting an error? I have the feeling you're debugging something and we don't have the whole story to be able to help you properly
[22:25] <Spajderix> here's the thing: I wanted to rewrite bzr_access script in a way that i will be able to assign list of premissions to a given key, eg. give rw permission to branch1 in repository1 and r permission to branch2 and so on, but I don't know how to find a path that a key is trying to access
[22:47] <jam> lifeless: sorry, I think mbp might know more about doc gen. I never worked on it.
[23:04] <AfC> bzr check is the first thing to do if Bazaar crashes, right?
[23:05] <lifeless> jam: no worries
[23:05] <lifeless> AfC: ask here is usally the thing to do
[23:05] <lifeless> check only considers known data issues, bzr can crash due to bugs as well
[23:06] <AfC> bzr: ERROR: exceptions.IndexError: list index out of range
[23:06] <AfC> 2.1.1, lucid
[23:07] <lifeless> more of the backtrace would be uesful
[23:07] <lifeless> that could be just about anything
[23:07] <AfC> yup
[23:07] <AfC> working on it
[23:07] <AfC> (so, multiparent)
[23:08] <AfC> lifeless: http://paste.pocoo.org/show/219107/
[23:08] <AfC> bzr crash dump (nice)
[23:10] <lifeless> that looks like a bug to me
[23:10] <lifeless> rather than data corruption
[23:10] <AfC> shit
[23:10] <AfC> hooray for me.
[23:10] <AfC> I will file
[23:11] <lifeless> IMBVW
[23:11] <lifeless> hmmm, caffeination I think
[23:11] <AfC> meanwhile I need to figure out how to accept this person's contributed revisions :(
[23:11] <lifeless> also I need to reboot to make usb work :(
[23:11] <lifeless> brb
[23:26] <poolie> jam, hi?
[23:31] <jelmer> moin lifeless
[23:34] <poolie> hi jelmer
[23:35] <jelmer> hey poolie
[23:35] <AfC> lifeless: it appears I hit https://bugs.launchpad.net/bzr/+bug/514369 so I attached my crash dump there.