[00:01] <dOxxx> evening...
[00:29] <dOxxx> Would it be acceptable to modify start_bzr_subprocess and finish_bzr_subprocess to not raise TestSkipped if python 2.6's Popen.send_signal method is available?
[00:51] <lifeless> dOxxx: I don't follow
[01:06]  * igc bbiab
[01:24] <dOxxx> lifeless: start_bzr_subprocess raises TestSkipped if os.kill isn't available, as on win32. However, with ptyon 2.6, the subprocess.Popen class has a send_signal method which maps SIGTERM to the TerminateProcess Win32 function.
[01:25] <dOxxx> lifeless: to make more tests run on win32, I was wondering if it would be acceptable to add an alternate codepath that used Popen.send_signal if it was available
[01:28] <lifeless> yes
[01:28] <lifeless> thats makes sense
[01:28] <lifeless> simply not raising TestSkipped did not make sense.
[01:50] <ricardo_br> Is there any command in bazaar to remove those backup files? ex:database.php.~1~
[01:51] <mwhudson> ricardo_br: it's a bit more than you're asking for but bzr clean-tree --ignored will kill them
[01:57] <ricardo_br> mwhudson : it's almost it, but I have some ignored folders that I don't want to delete (some project folders), is there any linux command that I can use?
[01:57] <mwhudson> ricardo_br: well 'find . -name \*~ -print0 | xargs -0 rm' will do it i guess
[02:02] <ricardo_br> mwhudson: wow, I really need to study these shell commands, it worked, thanks
[02:03] <mwhudson> ricardo_br: find | xargs is both very handy and somewhat crazy :-)
[02:07] <ricardo_br> well, I read the first part of the xargs' man page and it really scared me (xargs - build and execute command lines from standard input), A few time ago I was using windows I must admit
[02:08] <mwhudson> ricardo_br: you know the saying "unix *is* user friendly, it's just picky about who its friends are" ?
[02:09] <Peng> Oh wow! My original "bzr pull" isn't entirely dead.
[02:10]  * igc lunch
[02:17] <ricardo_br> mwhudson: no I don't know this one, probably I'm that slow second cousin
[02:23] <mkanat> ricardo_br: I think you want bzr clean-tree --detritus by the way.
[02:30] <ricardo_br>  mkanat: thank you! It's exactly what I'm looking for, I don't have to be friend with unix anymore
[02:30] <mkanat> :-)
[02:39] <mwhudson> oh right
[02:44] <mkanat> mwhudson: Did you see my long email?
[02:44] <mwhudson> mkanat: yes, it's been on my "to reply" list for about 7 hours now :)
[02:45] <mkanat> mwhudson: Hahaha, okay. :-)
[03:03] <mwhudson> mkanat: another team in launchpad trying spawning
[03:03] <mwhudson> mkanat: the scars are ugly and fresh
[03:03] <mkanat> mwhudson: For loggerhead?
[03:03] <mwhudson> no, for some u1 related thing
[03:03] <mwhudson> mkanat: they went back to using paste
[03:03] <mkanat> Okay.
[03:03] <mkanat> Well, Spawning does say it's still a beta.
[03:04] <mwhudson> ehh, i guess i should reply to the mail
[03:04] <mwhudson> then have a conversation
[03:04] <mwhudson> not the other way around :-)
[03:04] <mkanat> mwhudson: Okay. :-)
[03:04] <mkanat> mwhudson: Spawning was, of course, just a random idea without any research yet. :-)
[03:04] <mkanat> mwhudson: The more general idea being "scale better". :-)
[03:05] <mwhudson> mkanat: yes, i think that's basically the best idea
[03:08] <mwhudson> lifeless: can you remember the problems with spawning?
[03:08] <mwhudson> i have this vague recollection was that it wasn't very specific, it just didn't work very well
[03:08] <mwhudson> and was too magical
[03:11] <lifeless> yes
[03:11] <lifeless> it died  inthe ass for u1
[03:11] <lifeless> it does things like monitor for module changes and reload() when a foo.py changes (just thing what apt-get install will do to it :P)
[03:11] <lifeless> s/thing /think /
[03:12] <lifeless> my suggestion if you want cpu concurrency for loggerhead is haproxy
[03:12] <lifeless> or squid
[03:12] <lifeless> just add another backend service and tell the frontend stuff to send to both.
[03:12] <lifeless> simple, easy to admin, no code changes needed.
[03:13] <mwhudson> yeppers
[03:20] <mkanat> lifeless: That was my idea as well.
[03:20] <mkanat> We just need a way to share the revision cache between processes and then we're set.
[03:20] <mkanat> That scales across cores and machines as well.
[03:21] <dOxxx> holy cow, it's an utter mission compiling python extensions for x64 on windows
[03:21] <AfC> Once upon a time there was someone doing distributed bugs (with bzr, I think, but no matter)
[03:22] <AfC> does anyone have a suggestion for listing bugs _in tree_ of a project (ie not in a distributed bug database, but in a project tree) so that commits to code are done along with commits to {TODO, BUGS, bugs/filename.txt, ?}
[03:24] <mkanat> AfC: Not particularly. (Somebody else might.) It has always seemed to me that one of the major purposes of bug-tracking was central coordination, whereas development and branching really should be distributed.
[03:24] <mwhudson> AfC: "bugseveryehwere"
[03:24] <mwhudson> AfC: http://bugseverywhere.org/be/show/HomePage
[03:28] <rubbs> Ok, so I've submitted a patch last night on a documentation bug, and got some feedback. I made changes according to the suggestions, and pushed up the results. I then made a comment, but taged it with the "resubmit" vote. I've just now realized that it wasn't a tag but a review vote.
[03:28] <rubbs> what do I do now?
[03:30] <rubbs> is there anyway to delete that comment with the "resubmit" vote?
[03:31] <AfC> mwhudson: that was what I was thinking of
[03:31] <mwhudson> AfC: all abentley's fault iirc
[03:31] <AfC> mwhudson: right
[03:31] <AfC> mkanat: well, not really. What good is a centralized [only] bug database if you're not on the internet?
[03:32] <AfC> If you take distributed == disconnected you empower a lot more than just branches.
[03:32] <mkanat> AfC: Yeah, to some degree. I think it depends on the project.
[03:33] <AfC> mwhudson: do you know if Aaron is [still] using bugseverywhere?
[03:33] <mwhudson> AfC: not much, i think
[03:34] <mwhudson> AfC: but here he is, you can ask him :-)
[03:34] <AfC> mkanat: again, not really. If you the coder are frequently off the global network, then a bug database not locally accessible isn't any help to your development efforts
[03:35] <AfC> abentley: mwhudson mentioned a project of yours you once worked on, "bugseverywhere"; I was curious what your current opinion of it is?
[03:35] <mkanat> AfC: Sure, but that's a separate issue, I think.
[03:35] <AfC> mkanat: that's the issue I'm trying to redress
[03:35] <mkanat> AfC: Though not totally.
[03:35] <mkanat> AfC: Fair enough. :-)
[03:35] <mkanat> AfC: There are desktop clients for some trackers that will do offline work.
[03:35] <fullermd> Doesn't whatsitsname include bug stuff...
[03:36] <AfC> mkanat: no web hosted centralized only bug database is any use to me as an open source developer, because both I and my collaborators are only intermittently on the internet
[03:36] <abentley> AfC: I think it's still a useful idea, but the tool could use some work to become more forgiving.
[03:36] <fullermd> Fossil, that's it.  The thing the SQLite guy did.
[03:36] <mkanat> AfC: That's a situation I haven't thought of much, I have to admit.
[03:36] <mkanat> AfC: Where I am, it's almost impossible to get away from the Internet. :-)
[03:36] <fullermd> http://www.fossil-scm.org/index.html/doc/tip/www/bugtheory.wiki
[03:37] <abentley> AfC: Chris Ball maintains it now, and there's a small community around it, which is better than I ever did.
[03:37] <AfC> abentley: fair enough
[03:38] <lifeless> theres another distributed bug db
[03:38] <fullermd> (note that I haven't done more than read about it, so I don't know how or how well it works in practice)
[03:38]  * AfC pulls the plug on his wireless internet connection to conserve battery
[03:38] <AfC> mkanat: [see? :)]
[03:38] <AfC> lifeless: oh?
[03:39] <lifeless> AfC: I'll mail you
[03:39] <lifeless> some web3 thing - the sharecropper argument, they made a distributed db and wrote a bug tracker on it
[03:40] <AfC> lifeless: you have an idea of a google phrase to hunt for?
[03:41] <mkanat> mwhudson: Anyhow, an email response would probably be good since that's how we arrange the go-ahead for me to do further work.
[03:41] <mwhudson> mkanat: my email is a bit of a ramble tbh so far
[03:41] <mwhudson> oh well
[03:41] <mkanat> mwhudson: Honestly, I'd almost just love to help you out in my free time, except that that doesn't exist, and when it does, I don't use it to code. :-D
[03:41] <mkanat> mwhudson: That's OK. :-)
[03:41] <AfC> lifeless: ok, thanks!
[03:41] <lifeless> http://www.stackfoundry.com/dbug/ could be interesting too
[03:41]  * AfC ends essentially off topic conversation
[03:42] <mkanat> AfC: I have to admit I found it interesting, since I'm one of the primary developers of a bug-tracking system.
[03:42] <mkanat> I haven't yet seen a pressing *broad* need for distribution in bug-tracking, but that doesn't mean it isn't necessary, useful, or going to become one of those two things.
[03:43] <mkanat> AfC: So if you find any of those to be particularly useful or interesting, I'd be interested to know.
[03:43] <lifeless> AfC: http://code.bestpractical.com/project/Prophet
[03:44] <lifeless> http://syncwith.us/sd/bugs
[03:44] <AfC> lifeless: thanks Robert. Will look.
[03:44] <lifeless> I make no assertions
[03:44] <lifeless> it crossed my radar a while back and seemed interesting
[03:44] <lifeless> though it looks like they use git now for the bts, rather than prophet, which doesn't fit my memory
[03:44] <AfC> lifeless: NO WARRANTIES :)
[03:45] <AfC> lifeless: k
[03:45]  * AfC hibernates [or, reboots and fscks assuming the thing crashes again]
[03:50] <mwhudson> mkanat: mail sent
[03:50] <mkanat> mwhudson: Thank you. :-)
[03:58]  * mwhudson tries to remember why the backend server for codebrowse takes path based urls, not id based ones
[03:58] <mwhudson> oh, maybe because we tie access control up with the translation from name -> id
[03:58] <mwhudson> man
[03:58] <RenatoSilva> verterok_: hi
[03:58] <RenatoSilva> dOxxx: hi
[03:59] <mwhudson> we need a much smarter frontend :(
[03:59] <dOxxx> RenatoSilva: heya
[04:00] <lifeless> mkanat: I wouldn't share the caches
[04:00] <lifeless> mkanat: tell the front end how much of the path to hash to the same backends on
[04:00] <RenatoSilva> dOxxx: hi, thanks for fixing that test bug. Even formely deactivated AVG was still working. I ended up uninstalling AVG, now the tests pass fine :)
[04:01] <mkanat> lifeless: That would be OK, too.
[04:01] <mwhudson> hm, the frontend we already have could do that
[04:01] <mkanat> lifeless: We're also discussing the possibility of just removing the cache entirely.
[04:01] <mwhudson> seeing as it has the branch id to hand
[04:01] <abentley> mwhudson: Are you using your router from the sprint?  I'm using my eee as a router again!
[04:01] <mwhudson> well
[04:01] <mwhudson> yes
[04:01] <mwhudson> abentley: yes, finally
[04:01] <mwhudson> abentley: argh
[04:01] <mwhudson> abentley: because of the xx:45 disconnects?
[04:01] <lifeless> mkanat: I've suggested that that is a good idea :)
[04:02] <RenatoSilva> what's the arg for bzr selftest <plugin> that makes it faster?
[04:02] <lifeless> RenatoSilva: -s bp.pluginname
[04:02] <abentley> mwhudson: That, and increasingly-agonizing internet connectivity in general.
[04:02] <lifeless> RenatoSilva: note that this prefix is buggy
[04:02] <mwhudson> abentley: what did you have before?
[04:02] <lifeless> RenatoSilva: because it excludes interface conformance tests (which may not apply to you). But if they do apply to you using that doesn't test the whole plugin.
[04:03] <abentley> mwhudson: wrt54g
[04:03] <mkanat> mwhudson: I replied, but if the list is moderated, you'll have to clear my reply, since I'm not on the list.
[04:03] <mwhudson> abentley: huh, i thought they were ok
[04:03] <mwhudson> mkanat: i think it is
[04:03] <RenatoSilva> lifeless: interface conformance tests?
[04:03] <abentley> mwhudson: I've used this one for years.  Maybe the love is gone.
[04:04] <mkanat> My WRT-54G is pretty much OK, though I have DD-WRT on it.
[04:04] <mwhudson> abentley: or maybe your ire needs to be sent further upstream
[04:04] <RenatoSilva> lifeless: can't find any info about "bp" in bzr help selftest
[04:04] <abentley> mwhudson: I tried that, but elmo wasn't having it.
[04:04] <mwhudson> but i guess changing router is a good first thing to try
[04:04] <mwhudson> abentley: maybe not that far :-)
[04:05]  * rubbs does a little dance. His first patch ever was just accepted
[04:05] <abentley> mwhudson: I went to the vanguard on #is, but elmo joined the conversation.
[04:05] <mwhudson> abentley: i meant your isp
[04:07] <abentley> mwhudson: mtr showed packet loss at the entry point to canonical, so I went to #is.  elmo explained that this doesn't really prove a problem, because routers will often discard ICMP datagrams.
[04:07] <mwhudson> abentley: oh right
[04:11] <mkanat> rubbs: 'Grats!
[04:12] <rubbs> mkanat: thanks!
[04:16] <RenatoSilva> anyone else getting this error? http://img69.imageshack.us/img69/9431/qterror.png
[04:42] <spm> mkanat: fyi; we were arrrgggghhh!ing yesterday over the pager in gdb? rtfm reveals: (gdb) set pagination off :-)
[04:42] <mkanat> spm: Ahhh. :-)
[04:43] <spm> doncha hate it when the solution is the obvious one!
[04:43] <mkanat> :-)
[04:45] <mwhudson> spm: set height 0 also does that i think
[04:48] <spm> mwhudson: so it does.! ta! "The number of lines GDB thinks are in a page. Use 0 to keep GDB from pausing."
[04:50]  * mwhudson stops for the day
[04:51] <spm> night mwhudson, have a great w/e!
[04:51] <mwhudson> spm: well i'm working tomorrow :)
[04:51] <mwhudson> swap day for a couple of weeks
[04:52] <spm> ahhh. fair enough. that'll learn you for having a honeymoon :-P
[04:54] <mwhudson> yeah
[05:34] <dOxxx> what version of pycrypto and paramiko does bzr use?
[05:39] <lifeless> whatever you have installed
[05:39] <lifeless> [was that what you meant to ask?]
[05:49] <dOxxx> lifeless: sorry, it's late and I'm not thinking straight. what version of pycrypto and paramiko does the windows installer bundle?
[05:51] <lifeless> no idea; I thought pycrypto was built in now, and its likely latest released paramiko
[05:55] <dOxxx> lifeless: The problem I'm having is that in order to use ssh while running bzr from source, I need to have paramiko and pycrypto installed for the version of python I'm using. However, I'm getting deprecation warnings about the sha and md5 modules.
[05:55] <dOxxx> lifeless: Is it because I'm using python 2.6?
[05:56] <dOxxx> hmm bzr from windows installer bundles python 2.5, that's probably why I don't see the warnings when I'm using that
[05:56] <lifeless> dOxxx: I'm pretty sure we fixed all our deprecated warnings
[05:56] <lifeless> what bzr are you using?
[05:58] <dOxxx> lifeless: latest from bzr.dev. these deprecation warnings are coming from pycrypto v2.0.1. if I try pycrypto v2.1.0b1, I get different deprecation warnings about RandomPool
[05:59] <lifeless> oh
[06:00] <lifeless> :(
[06:00] <dOxxx> they're only warnings, stuff still works, it just irks me when I'm running selftest every couple of minutes to test a change and I have to mentally filter out these warnings
[06:04] <lifeless> yeah
[06:04] <lifeless> you could fix it :)
[06:04] <dOxxx> bleh
[06:04] <dOxxx> :)
[06:04] <dOxxx> not at 1am ;)
[06:41] <dOxxx> good night!
[06:42] <fullermd> Yes, stock pyrcrpto has warnings with py2.6.
[06:42] <dOxxx> ah
[06:42]  * fullermd khan speel...
[06:42] <fullermd> There are patches floating around.  I know there's one on LP somewhere for Ubuntu.  The FreeBSD port has one.
[06:42] <dOxxx> hmm maybe I'll scrounge around tomorrow
[06:42] <dOxxx> thanks for the info
[06:42] <fullermd> (neither being platform-specific; it's pure py)
[06:43] <dOxxx> good night :)
[07:33] <MvG> LarstiQ: When you find the time, can you try whether lp:~gagern/trac-bzr/quoting works on trac 0.10? I fear it won't...
[08:01]  * igc dinner
[08:55] <eMerzh> hi ... i have pbm to access a repository behind a proxy... what should i look to?
[08:55] <eMerzh> i've well my http_proxy variable defined
[11:59] <bialix> jam: when you'll have a couple of free minutes -- I have a question
[12:15] <Garagoth> Hello.
[12:16] <Garagoth> I wanted to try Bazaar, but once I installed it, it fails... 'bzr version' gives me a traceback with message: 'UnboundLocalError: local variable 'version' referenced before assignment'
[12:17] <Garagoth> Could anyone help me with that?
[12:17] <LarstiQ> that sounds rather broken
[12:17] <LarstiQ> Garagoth: could you pastebin the full traceback?
[12:17] <Peng> Garagoth: Pastebin the traceback.
[12:17] <Peng> D'oh~
[12:17] <LarstiQ> MvG: hmm, I'm getting TracError: Unsupported version control system "bzr"
[12:18] <LarstiQ> MvG: but unsure why
[12:18] <igc> night all
[12:18] <LarstiQ> night igc!
[12:18] <Peng> igc: Good night. :)
[12:18] <Garagoth> pastebin ?
[12:18] <Peng> Garagoth: Paste it on http://paste.ubuntu.com/ or a similar site and give us the URL.
[12:18] <LarstiQ> ubottu: paste?
[12:18] <LarstiQ> hmm
[12:18] <igc> Hi LarstiQ! Nice to hear from you
[12:18] <igc> Thanks Peng
[12:18] <LarstiQ> igc: likewise :)
[12:19] <MvG> LarstiQ: Never mind, I'm just about to set up a dedicated apache config on my desktop in order to test trac-bzr, I'll set up one with 0.10 as well.
[12:19] <Garagoth> http://paste.ubuntu.com/323262/
[12:19] <LarstiQ> MvG: oh, ok
[12:19] <LarstiQ> Garagoth: ehm, your python install seems to be broken
[12:20] <Garagoth> LarstiQ: Ok, what is wrong with it?
[12:21] <Peng> Garagoth: What distro are you on?
[12:21] <Garagoth> Archlinux
[12:21] <Peng> Garagoth: Or, um, OS in general?
[12:21] <Peng> Oh.
[12:22] <LarstiQ> j~.~.~.
[12:22] <LarstiQ> gah
[12:22] <Peng> Garagoth: 1.) There's a bug in Python's platform module, 2.) You have a weird /etc/*release or /etc/*version file; otherwise the bug wouldn't be exposed.
[12:23] <Peng> Garagoth: To be more specific, it's empty.
[12:23] <Garagoth> Peng: Both release and version are empty.
[12:23] <Peng> Garagoth: Yes, well, that would be your problem.
[12:25] <Garagoth> Ok. version now works.
[12:25] <Peng> Note to self: File Python bug: platform._parse_release_file UnboundLocalError if the file is empty.
[12:25] <Peng> (Or if the first line is.)
[12:25] <Garagoth> release is still empty... but I had a test version file not from my distro ;-)
[12:26] <Peng> Anyway, I was eating pizza and/or watching TV. See ya.
[12:26] <Garagoth> Thanks for info.
[12:26] <Garagoth> and help/
[12:29] <Garagoth> Now I have another issue... http://paste.ubuntu.com/323273/
[12:34] <bialix> LarstiQ: hi
[12:38] <bialix> LarstiQ: I have some experience with trac-bzr, so I might help maybe
[12:46] <Garagoth> Anyone with fast-import experience? http://paste.ubuntu.com/323273/
[12:49] <bialix> Garagoth: are you using the latest version of fast-impor from trunk?
[12:50] <Garagoth> revision-id<EMAIL_ADDRESS>[12:50] <Garagoth> date: 2009-11-06 18:06:27 +1000
[12:50] <Garagoth> build-date: 2009-11-20 13:50:32 +0100
[12:50] <Garagoth> revno: 260
[12:50] <Garagoth> branch-nick: bzr-fastimport
[12:51] <bialix> I don't know what is build-date
[12:51] <bialix> anyway this is most likely bug in the plugin
[12:51] <Garagoth> Looks like date when i branched this repository
[12:52] <bialix> fast-import author is igc, he said goodnight half hour ago
[12:52] <bialix> you may want to file a bug
[12:52] <bialix> or try to use more recent/older revision
[12:52] <bialix> sorry, can't say more
[12:53] <Garagoth> Mm. Thanks.
[12:55] <Garagoth> plugin version is 0.9.0dev
[12:56] <bialix> 0.9.0dev means unreleased-yet version
[12:56] <bialix> it can has bugs inside
[12:56] <bialix> your traceback is cleanly bug
[12:57] <bialix> revno 260 -- is the latest version in trunk
[12:57] <bialix> Garagoth: you really need to file a bug report
[12:59] <Garagoth> Ok, I will.
[14:17] <jam> morning bialix, what's your question?
[14:17] <bialix> hi jam
[14:17] <bialix> jam: https://code.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp_trunk
[14:18] <bialix> this branch seems is not needed anymore?
[14:18] <bialix> we have your fix in the trunk, I'm not sure what the purpose of this branch
[14:18] <bialix> if it really no needed, can you mark it as merged or abandoned?
[14:19] <bialix> jam ^
[14:19] <jam> bialix: Sure, though I would have thought the fix would have been merged from there
[14:19] <jam> anyway, I can mark it merged
[14:19] <bialix> jam: it strange but trunk has different your revision with slightly different commit message
[14:19] <jam> I might have done it 2 times or something
[14:19] <bialix> and with the same revno
[14:19] <jam> no big deal
[14:19] <bialix> thanks jam!
[14:20] <jam> or maybe did an uncommit?
[14:20] <jam> anyway
[14:20] <jam> done
[14:20] <bialix> thanks
[14:20] <bialix> jam: and while I've got a bit of your attention, can I point on Bug 485771?
[14:21] <bialix> I can imagine why it works as it works now, but I have reasons to think it's not right
[14:23] <jam> bialix: so... I think there is a "has_glob" function in 'glob', that you can use to tell if we need to try and expand a command line param
[14:23] <jam> however note that if you do "bzr commit -m "foo\bar"  it will 'just work'
[14:24] <jam> also note that with the proposed patch, "bzr commit -m foo\bar" is going to warn/prompt you...
[14:24] <jam> anyway, I forget the specific function, but certainly we could only try to expand things that have ? or * in them.
[14:24] <bialix> hmmm
[14:24] <bialix> I think I want to write a patch to disable glob with env variable
[14:25] <bialix> jam: BZR_GLOB=0 will be OK for you?
[14:25] <jam> so caveat the discussion about it breaking scripts, etc
[14:26] <jam> it seems ok
[14:26] <jam> I might put "BZR_WIN32_GLOB=0"
[14:26] <jam> or... BZR_WIN32_NOGLOB=1
[14:26] <bialix> so many choices
[14:26] <bialix> flkip a coin?
[14:26] <jam> anyway, I'll let you work out the details
[14:26] <jam> yeah
[14:26] <bialix> BZR_WIN32_NOGLOB and any non-empty value
[14:27] <bialix> that sounds sane for me
[14:27] <bialix> something like there is done for NO_PROXY?
[14:27] <bialix> thx for suggestion, I'll try to make a patch this weekend
[14:28] <bialix> jam: is there planned b4?
[14:28] <jam> bialix: yeah, I'm pretty sure, and certainly at least an rc1
[14:28] <jam> so rc1 => 2.1.0 final won't have many changes, but current => rc1 can
[14:28] <bialix> I just need to have some gap to make sure NOGLOB patch will be landed for 2.1
[14:29] <jam> basically at rc1 it goes 'stable'
[14:29] <jam> you've got ~2 months
[14:29] <bialix> more than enough :-)
[14:48] <jam> bialix: I think not globbing when there isn't a glob character is also a worthwhile fix, on-top of a _NOGLOB variable.
[14:49] <bialix> on-top?
[14:50] <jam> bialix: do both, not just noglob
[14:50] <bialix> ah, understand
[14:51] <jam> noglob is useful, but it is a big hammer that people have to think about to turn on
[14:51] <jam> rather than have things "just work" most of the time
[14:52] <bialix> jam: ok, I understand, but noglob is simpler to write right now, do what I mean needs some thinking
[14:52] <bialix> jam: another your branch @ qbzr: https://code.launchpad.net/~jameinel/qbzr/progress
[14:52] <bialix> do you recall what is it off hands?
[14:57] <jam> bialix: I think qannotate just showed "loading" and that patch adds a progress bar
[14:58] <jam> so that you could see how close it was to done
[14:58] <jam> the progress  bar was commented out in the code
[14:58] <jam> I just uncommented it, etc.
[14:59] <jam> I don't know where that widget is used, etc.
[14:59] <jam> I haven't focused on it in a while
[14:59] <jam> but it was nicer at the time
[15:00] <bialix> jam: ok thanks, I'll try to get a closer look on your changes, a bit later
[15:02] <Garagoth> Hmm. I'm trying to fast-export an svn repository (to import it to Bazaar later), but exporting fails with: Can't create a character converter from 'UTF-8' to native encoding
[15:03] <bialix> Garagoth: svn-import does not work for you?
[15:04] <Garagoth> Not tried that yet.
[15:05] <Garagoth> Is it part of bzr-svn ?
[15:05] <bialix> yep, it's from bzr-svn
[15:05] <Garagoth> Ok.. let me build that...
[15:16] <konnertz> hi, i do a bzr st in my child branch and get
[15:16] <konnertz> pending merges:
[15:17] <konnertz> Peter Smith 2009-11-11 More stuff for ...
[15:17] <konnertz> This info is available only in my parent branch , right?
[15:18] <konnertz> so why is it shown to me?
[15:18] <Lo-lan-do> You merged it but didn't commit it?
[15:20] <konnertz> i should add, Peter is somebody else with his own branch and he is the main person reviewing the changes i bzr send to the main repo
[15:21] <konnertz> so imo either he has merged all his changes to central repo or not
[15:21] <konnertz> and if not, i dont need to see them!?
[15:23] <Garagoth> bialix: bzr svn-import seems to work.
[15:23] <Garagoth> Thanks.
[15:25] <konnertz> is it understandable what i mean?
[15:25] <konnertz> I cant do anything to clear the status
[15:28] <Garagoth> bialix: I spoke too early... 'bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository('file:///warlock/Bazaar/mudlib/mudlib/.bzr/repository/')
[15:28] <bialix> Garagoth: something weird with your bzr
[15:29] <bialix> Garagoth: what version of bzr you are using?
[15:29] <Garagoth> 2.0.2
[15:29] <Tak> when I do `bzr annotate` , I get a lot of revisions like "41.2.30" - is there any way to go from that to a "normal" revspec? (i.e. the ones shown in `bzr log`)
[15:31] <bialix> Garagoth: and bzr-svn? 1.0.1?
[15:31] <Garagoth> yes.
[15:32] <Lo-lan-do> Tak: 41.2.30 is a normal revspec
[15:32] <Lo-lan-do> Tak: It's just a revision that was committed as part of a merge
[15:32] <bialix> Garagoth: something weird, but I have no idea what exactly.
[15:32] <Lo-lan-do> Tak: You can see it if you "bzr log -n 2"
[15:32] <Tak> hmm
[15:35] <Garagoth> bialix: http://paste.ubuntu.com/323424/
[15:35] <Garagoth> trace from that error, from .bzr.log
[15:36] <bialix> Garagoth: it lloks like bzr-svn incorrectly working with bzr internals
[15:36] <bialix> Garagoth: it seems it's not your day today :-/
[15:36] <Garagoth> bialix: Should I post a bug report about this?
[15:36] <bialix> yes, pleasd
[15:36] <bialix> yes, please
[15:36] <Garagoth> that would be third today... first day of bzr, and...
[15:37] <bialix> Garagoth: don't give up!
[15:37] <bialix> Garagoth: does there is something non-stadard in your system? filesystem?
[15:37] <Garagoth> Ha. I have 219 svn revisions to import, each of about 80MB when targzipped...
[15:38] <bialix> *non-standard
[15:38] <Garagoth> filesystem is ext3
[15:38] <Garagoth> on raid5
[15:38] <Garagoth> and lvm on top of it
[15:38] <bialix> Garagoth: does you svn repo have many branches?
[15:38] <Garagoth> not a single one.
[15:38] <bialix> can you try then just simple: bzr branch URL/to/svn
[15:39] <bialix> what is lvm?
[15:39] <Garagoth> logical volume manager
[15:39] <smagoun> Is there a way to revert/uncommit a specific revision? Say my current tree is at r100, I want to revert r98. The catch is that r98 includes binary files, so I can't just do 'bzr diff -r97..98 > foo.patch && patch -R < foo.patch' or so.
[15:40] <Garagoth> it is used to make 'partitions' on disks...
[15:43] <Garagoth> bialix: bzr branch started similarly as svn-import (it scanned all revisions), and now it hangs on copying revision 0
[15:43] <Garagoth> and svn repo starts from revision 1 ...
[15:43] <bialix> Garagoth: my bad, use URL/to/svn/trunk
[15:44] <bialix> smagoun: bzr merge -rN..N-1
[15:44] <Garagoth> ah, no, there is revision 0, sorry. It is empty.
[15:44] <smagoun> bialix: nifty, I'll try that. Thanks
[15:44] <Garagoth> bialix: You mean URL to working copy or what...?
[15:45] <bialix> Garagoth: no, I mean svn repo
[15:45] <bialix> using your traceback from paste it should be like this: file:///repository/svn/mudlib/trunk
[15:46] <Garagoth> bialix: There is no such thing.
[15:46] <bialix> Garagoth: file:///repository/svn/mudlib/ <-- is it correct URL to your svn repo you want to convert?
[15:46] <Garagoth> in repository/svn/mudlib I have:
[15:46] <Garagoth> conf  dav  db  format  hooks  locks
[15:46] <bialix> Garagoth: that's ok
[15:47] <bialix> svn has inside virtual fs
[15:47] <smagoun> bialix: so that didn't work - it tried to merge from a remote branch which I had previously merged into r50 or so of my current branch). "Merging from remembered submit location bzr:ssh://bazaar.launchpad.net/blahblah"
[15:47] <jam> konnertz: doesn't "bzr revert" clear the status?
[15:47] <bialix> smagoun: use . as merge source
[15:47] <Tak> Lo-lan-do: cool, that helps - thanks! ( http://img265.imageshack.us/img265/5346/bzrannotatemerge.png )
[15:47] <Garagoth> bialix: bzr: ERROR: Not a branch: "/repository/svn/mudlib/trunk".
[15:48] <smagoun> bialix: seems to have done the trick - thank you
[15:48] <smagoun> !
[15:48] <bialix> Garagoth: I'm not very good in svn, but what URL you may use to run svn co ... ?
[15:49] <Garagoth> Hmm... I was using it by svnserve... and I belive it was just: mudlib
[15:49] <Garagoth> bialix: as svnserve was running from /repository/svn
[15:50] <Garagoth> bialix: Yup. URL I was using was: svn://<IP_ADDRESS>/mudlib
[15:51] <bialix> ok
[15:51] <bialix> so run: bzr branch svn://<IP_ADDRESS>/mudlib
[15:51] <Garagoth> Ahm. First I have to run svnserve.
[15:52] <Garagoth> argh. Just a moment, I will set it up...
[15:52] <Peng> What's the point of using svn://localhost? Why not just file://?
[15:52]  * Peng sees backlog. Oh.
[15:52]  * bialix not very good in svn
[15:53] <bialix> Peng: can you suggest something? I'm almost out of ideas how to help Garagoth
[15:53] <Garagoth> Peng: That is why I was trying with file://repository/svn/mudlib/ ...
[15:53] <Tak> does svn+file://... work?
[15:54] <Garagoth> Tak: in which command?
[15:55] <Tak> bzr branch
[15:55] <bialix> Garagoth: bzr branch svn+file
[15:56] <Garagoth> bzr: ERROR: Invalid url supplied to transport: "svn+file:/repository/svn/mudlib"
[15:56] <gdoubleu> I was trying to use svn+file yesterday when testing a checkout of a svn repo, but got the same error
[15:56] <gdoubleu> https://bugs.launchpad.net/bzr-svn/+bug/485496
[15:56] <Garagoth> but with file:///
[15:56] <Garagoth> it started, but just hung at revision 0
[15:57] <Garagoth> hang?
[15:57] <Peng> Garagoth: Hung? How long? Was it really hung or was it still working?
[15:58] <Peng> Garagoth: Is this a small repo or not?
[15:58] <Garagoth> Peng: revision 0 is empty. Revision 1 has some data. It was copying revision 0 for 5 minutes or so, then I interrupted it.
[15:59] <Garagoth> svn-import went thru rev 0 in less then second, completed rev 1, 2, and failed on rev 3
[15:59] <konnertz> jam, ok yes it does. But there is a change in parent branch, i fetch with bzr merge
[16:00] <konnertz> raising a criss-cross merge msg
[16:00] <jam> konnertz: if you "bzr merge" you have to "bzr commit" that before it is recorded locally
[16:00] <konnertz> i resolve the conflict manually
[16:00] <konnertz> and the bzr st shows me the pending merge
[16:00] <jam> criss-cross warning isn't harmfull, though doing "bzr merge --weave" will likely result in fewer conflicts in that situation
[16:00] <jam> konnertz: you haven't committed the merge yet
[16:00] <jam> so it will continue to tell you about it until you do
[16:01] <konnertz> i see , moment
[16:02] <konnertz> ok, bzr st is clear and bzr merge nothing to do,
[16:02] <Lo-lan-do> jam: I was under the impression that --lca was more recommended than --weave, did I miss something?
[16:02] <jam> Lo-lan-do: --weave was badly broken ~ 1 year ago, I've fixed it
[16:02] <konnertz> now there's a bla.xy~1~ file
[16:02] <jam> *I* prefer --weave to --lca
[16:02] <jam> abentley probably would say the opposite
[16:03] <Lo-lan-do> Heh
[16:03] <jam> they have slightly different characteristics
[16:03] <Lo-lan-do> Okay, I'll remember to try it next time I get criss-cross conflicts.
[16:03] <jam> edge case handling, etc
[16:03] <konnertz> ok same content as current file, i deleted
[16:04] <abentley> Lo-lan-do: When two sides have resolved a merge differently, weave arbitrarily picks one side, lca conflicts.
[16:04] <konnertz> i see, i'll check the other merge alg. next time
[16:05] <Lo-lan-do> abentley: I see.
[16:05] <Lo-lan-do> abentley: Which side is picked, if you remember offhand?
[16:06] <abentley> Lo-lan-do: I don't remember which side is picked.  jam is likely to.
[16:11] <jam> Lo-lan-do: things tend to depend on the order things were inserted into the weave. so merging a=>b may give a different result than b=>a.
[16:11] <jam> However, IIRC there are also differences when you have 'multi-layered' crisscross issues
[16:11] <jam> where weave takes into account more history than lca
[16:11] <jam> which only looks at the immediate lca ancestors
[16:12] <Lo-lan-do> That's way above my level of understanding of the innards of merges, but thanks anyway :-)
[16:13] <jam> Lo-lan-do: as a short point: http://paste.ubuntu.com/323450/
[16:14] <jam> D supersedes both B & C, so if there is a conflict between D & E
[16:14] <jam> but the line in E clearly comes from B or C
[16:14] <jam> then D should win
[16:14] <jam> "clearly" I think is at least partially up for debate
[16:14] <Lo-lan-do> Sounds reasonable.
[16:15] <jam> --lca only looks at D & E, so it can't directly tell
[16:15] <jam> However, Aaron's comment is that if D picks B and E picks C
[16:15] <jam> then weave may not conflict
[16:15] <jam> and just "pick B" or something
[16:16] <jam> if you look at: http://revctrl.org/CrissCrossMerge#orderingambiguities%3Aordering
[16:16] <Lo-lan-do> Hmm.
[16:17] <jam> under "Simple Weave Merge" it describes one of the "accidentally clean" failures of weave merging
[16:17] <Garagoth> bialix, Peng: FYI, svn-import svn://<IP_ADDRESS>/mudlib failed with same error on revision 3
[16:17] <jam> I'm not positive if "bzr merge --weave" suffers from this, but it probably does
[16:18] <bialix> Garagoth: jelmer is the author of bzr-svn and main wizard of it.
[16:19] <bialix> I'd ask him about your problem
[16:19] <Garagoth> bialix: And where can I find him...?
[16:19] <Peng> I want to push 2 (unstacked) copies of the same branch to LP. Any way to do it without having to upload everything twice?
[16:20] <bialix> Garagoth: usually he appears on this channel very often, but rightn now IIUC he's on UDS
[16:20] <Peng> Hmm. Does LP mind if I stack on something other than the development focus branch?
[16:20] <bialix> try to send mail to main bzr ML
[16:21] <Garagoth> bialix: I am im middle of reporting a bug in bzr-svn, shall I continue?
[16:21] <bialix> yes, he will receive that too
[16:21] <Garagoth> ok
[16:26] <bialix> Garagoth: jelmer just entered the building! magic!
[16:26] <bialix> hi jelmer, we waiting you :-)
[16:26] <Garagoth> Hmmm.... now svn-import (another try) hangs in revision 0... uses 96% of cpu, some io...
[16:27] <Garagoth> jelmer: Hi. Could you please have a look at: http://paste.ubuntu.com/323424/
[16:27] <jelmer> bialix: uhm.. hi :-)
[16:27] <bialix> :-D
[16:28] <jelmer> Garagoth, is this using the latest version of bzr-svn?
[16:28] <Garagoth> 1.0.1
[16:28] <jelmer> Garagoth, is the repository you're trying to import public?
[16:29] <Garagoth> No.
[16:29] <jelmer> Garagoth: The error you are seeing is masking the actual error
[16:29] <jelmer> Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again
[16:30] <Peng> FYI: The answer is no, it does not mind. Probably; I haven't fully tested it. That makes sense, since the development focus branch can be changed, and IIRC old stacked branches will not be updated.
[16:30] <jelmer> jam: hi
[16:30] <jam> hey jelmer
[16:31] <jelmer> jam: Is there a particular reason why bzr only supports stacking on the source branch from the UI?
[16:31] <jelmer> jam: Preventing users from shooting themselves in the foot?
[16:32] <jam> no clearly defined way of specifying something else?
[16:32] <jam> not really sure
[16:32]  * Peng has steel boots on to prevent that. :)
[16:32] <jam> jelmer: 'bzr push --stacked-on ..."  allows you to specify a location
[16:32] <jam> I assume you could do something similar for 'bzr branch'
[16:33] <jam> however, I think the goal is to limit stacking a bit
[16:33] <jam> since the branch must always be available ,etc.
[16:34] <Garagoth> jelmer: Ok, will try in a moment... I lifted memory limits and executed it again, now it is thinking very hard on revision 3...
[16:34] <Garagoth> Hm, went to 4th rev
[16:34] <jelmer> jam: Thanks
[16:35] <Garagoth> jelmer: Maybe it run out of memory (had 512MB limit), not it allocated 930 MB and is still working.
[16:35] <Garagoth> jelmer: Is that possible?
[16:36] <jelmer> could be - how much data is in that repo?
[16:37] <Garagoth> jelmer: rev1 is 57MB, rev2 is 5MB, rev3 is 2MB
[16:37] <bialix> Garagoth: so what was non-standard in your system! memory limiter
[16:37] <bialix> I feel this
[16:37] <bialix> too much very strange errors here and there
[16:38] <bialix> Garagoth: maybe without hard limits you can manage fast-import to work too
[16:38] <Garagoth> bialix: Well, that is why I increased it to 1GB
[16:39] <Garagoth> But anyway, error is VERY misleading
[16:40] <jelmer> Garagoth, odd, it shouldn't be using that much memory in that case
[16:40] <bialix> because you have out of memory and error reporter failed to create right leading message :-)
[16:41] <Garagoth> jelmer: Well, stands still at 750MB virtual mem and 200MB res
[16:42] <Garagoth> maybe not that still. 762MB now.
[16:42] <jam> bialix: lp:///~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob
[16:42] <jam> once it finishes pushing
[16:43] <Garagoth> Hm, just finished with rev 4, started copying rev 5
[16:43] <Garagoth> jelmer: Do you want that error from paste.ubuntu filed as a bug report?
[16:44] <bialix> jam: cool, thanks!
[16:44] <Peng> What makes a branch stacked? Presence of stacked_on_location in branch.conf?
[16:44] <Peng> Anything else?
[16:44] <jelmer> Garagoth, what was the actual error you got when you replaced that line?
[16:45] <Garagoth> jelmer: What do you mean: replaced that line?
[16:46] <jam> bialix: looking at the code, it was clearly wrong
[16:46] <jam> as it would replace all '\' with '/' even in quoted messages, etc.
[16:46] <bialix> ouch!
[16:46] <jam> https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob/+merge/15094
[16:47] <Garagoth> jelmer: I pasted what I found in .bzr.log, on console I only got last message (BzrError: Must end write group before releasing write lock ...)
[16:48] <Peng> I think my stacking experiment failed.
[16:48] <jelmer> Garagoth: see my comment earlier
[16:48] <bialix> jam: bb:approve :-)
 Garagoth: The error you are seeing is masking the actual error
[16:48] <jelmer>  Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again
[16:49] <MvG> "pydoc -p", the python documentation http server, fails to serve documentation for e.g. bzrlib.branch. Is it just me, is pydoc broken, or is bzr doing something particularly fishy?
[16:50] <Garagoth> jelmer: Ahm. Just a sec, I will lower memory limit back to 512MB and try again. Can I simply edit file in /usr/lib/python... ?
[16:50] <Peng> Never mind. "bzr check" is just confusing: It gives the local repository URL even when checking revisions in the stacked-on repo.
[16:50] <Peng> fallback repo. Whatever.
[16:51] <jelmer> Garagoth: Yeah
[16:53] <bialix> MvG: I'd say bzrlib
[16:54] <MvG> OK, probably not worth fixing, so I'll stick to ascii pydoc.
[16:54] <Garagoth> jelmer: Ok. Thais might take a while, I'm waiting for current process to interrupt (it does not end immediately on Ctrl-C) and the run again, revs 1 and 2 take about 5 minutes to import...
[16:54] <Garagoth> jelmer: And it allocated 850 virt, 200 res at this moment...
[16:54] <Garagoth> jelmer: in MB
[16:55] <bialix> MvG: you may find useful http://starship.python.net/crew/mwh/bzrlibapi/
[16:56] <bialix> MvG: IIRC there is problems with lazy_imports which used pretty heavily inside bzrlib
[16:56] <MvG> bialix: That link indeed looks useful, thanks!
[16:56] <bialix> :-)
[16:56]  * bialix hopes to look at new trac-bzr soon
[16:57] <MvG> bialix: just trying to fix "view changeset by revis, without naming a branch" behaviour...
[16:58] <Garagoth> jelmer: Why it is spending so much time on copying revisio 0? It is empty...
[16:58] <bialix> MvG: I just need to get some free time to upgrade our trac install at work, my remark just "sigh"
[16:59] <MvG> As of an hour ago, I've got a working apache setup running on my local machine and serving both trac 0.10 and trac 0.11... And in CGI mode, which will make development faster than with the fcgi I used before, where I had to restart apache after every modification.
[17:00] <jelmer> Garagoth, it should be fairly quick processing rev0
[17:01] <Garagoth> jelmer: strange. First try I ever made was fast. Each of next ones takes forever.
[17:01] <bialix> MvG: so I can try to hope that 0.10 will be supported more or less well?
[17:02] <bialix> cool
[17:02] <Garagoth> jelmer: And it allocated 478MB already
[17:02] <Garagoth> still at rev 0
[17:02] <Garagoth> Aha!
[17:02] <Garagoth> jelmer: Failed with: MemoryError
[17:03] <jelmer> Garagoth: Still at rev0 ?
[17:03] <jelmer> Garagoth, There is something going very wrong there....
[17:03] <MvG> bialix: YOu at least have a chance that all improvements I do that will work for 0.10 are incorporated into a 0.10 branch, and that I won't commit stuff to that branch that doesn't work for 0.10. At least in cases where "works" is easy to see.
[17:04] <Garagoth> jelmer: Ok, what can I show to you then?
[17:05] <bialix> MvG: cool, thank you!
[17:06] <Garagoth> jelmer: http://paste.ubuntu.com/323495/
[17:06] <jelmer> Garagoth, that doesn't help much unfortunately
[17:08] <jelmer> Garagoth, what distro are you using?
[17:09] <Garagoth> Archlinix
[17:09] <Garagoth> Archlinux*
[17:10] <jelmer> Garagoth: does "bzr selftest bzrlib.plugins.svn" work?
[17:11] <Garagoth> jelmer: executing...
[17:12] <Garagoth> 240 tests done, 84MB allocated...
[17:15] <jelmer> vila: ping
[17:15] <Garagoth> jelmer: Ran 1288 tests in 200.115s, OK (known_failures=2), 46 tests skipped, tests passed.
[17:40] <CoffeeIV> I am moving a working directory (checked out) and the branch it was checked out from, to a new directory.  Is the .bzr/branch/branch.conf the only file I have to edit to point the working directory to the new branch ?
[17:41] <maxb> I think so
[17:43] <CoffeeIV> ok . . . I made backups so I guess I will try it and find out
[17:54] <abentley> jam: I'm pretty sure weave merge does suffer from it.  I'm pretty sure mysql wanted that.
[18:00] <jam> abentley: so the specific cases I debugged were cases where there was a double-criss-cross and the fallback had a clear resolution on one side
[18:00] <jam> but yes, that could also be true
[18:02] <abentley> jam: Oh, I thought that each side of the criss-cross kept resolving the conflicts in their favour, and they wanted a merge that would do that automatically.
[19:03] <echos> How do I remove a symbolic link from commit tree?
[19:07] <echos> I'm using bzr remove but it doesn't seem to be working at all
[19:07] <echos> I'm getting ERROR: * is not in the same branch as *
[19:31] <maxb> That's a really weird error
[19:32] <maxb> Oh
[19:32] <maxb> Are you removing part of the error and replacing it with * for IRC?
[19:32] <maxb> Please don't
[20:20] <jam> echos: rm symlink ; bzr rm
[20:20] <jam> 'bzr rm' should remove any file that was versioned but is no longer present
[20:35] <Saktoth> Hey folks. Any idea what this means? Im totally clueless:
[20:35] <Saktoth> C:\Program Files\2awr>bzr up
[20:35] <Saktoth> Unable to load plugin u'rebase'. It requested API version (2, 0, 0) of module <m
[20:35] <Saktoth> odule 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo
[20:35] <Saktoth> '> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
[20:35] <Saktoth> bzr: ERROR: No WorkingTree exists for "file:///C:/Program%20Files/2awr/.bzr/chec
[20:35] <Saktoth> kout/".
[20:38] <lifeless> it means you need a newer bzr-rebase plugin. Its called bzr-rewrite now.
[20:48] <Saktoth> How do i get that? Get the test release? Latest stable? or do i need to download the plugin seperately?
[21:32] <joaopinto> hello
[21:54] <jml> hey
[21:54] <jml> we're writing useful Python code snippets into a gobby session
[21:56] <jml> at desktop-code-snip-party
[23:49] <ub3rst4r> hi, i was wondering what the difference between update and merge is, and why i have to do merge instead update when i go to work on the code
[23:50] <fullermd> Update updates your working tree to match its branch.  Merge brings changes over from another branch.
[23:51] <ub3rst4r> k
[23:51] <ub3rst4r> so why do i need to use merge?
[23:51] <mwhudson> hm!
[23:51] <mwhudson> abentley: are you still here?
[23:53] <fullermd> I...   don't know.  That's like asking "why do I have to drive downtown?"  If you have to go downtown, then you have to because you have to; if you don't, you don't...
[23:54] <ub3rst4r> i thought there was a way on launchpad to change how to manage the code when working with multiple accounts
[23:55] <mwhudson> if you have people doing development in parallel you're likely to have to merge at some point
[23:55] <mwhudson> unless you all use checkouts
[23:56] <ub3rst4r> i sort of dont understand it
[23:56] <ub3rst4r> do u need to run the merge command everytime u go to work on the code?
[23:57] <fullermd> Well, merge/update/etc don't really have anything to do with LP...  's all about what branches you have where.
[23:57] <mwhudson> ub3rst4r: i work in the 'feature branches' model
[23:57] <mwhudson> so all commits to trunk are merges
[23:58] <ub3rst4r> ?
[23:58] <mwhudson> ub3rst4r: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/organizing_your_workspace.html#feature-branches
[23:58] <mwhudson> ub3rst4r: reading this whole page may do you a lot of good, i'd guess
[23:59] <fullermd> You may want to look over http://bazaar-vcs.org/MatthewFuller/AboutPushPullMerge as well; it sounds like you're not really clear on which pieces you're putting where.


[00:10] <greearb> cjwatson, thanks, my xchat buffer scrolled off over the long weekend.
[00:51] <greearb> boot.cat and a *CN.hlp file in isolinux/ is bad, it seems...maybe I generated the md5sum file wrong?
[07:26] <twb> Does ubiquity do raid and/or lvm yet?
[07:26] <cjwatson> no, sorry
[07:27] <twb> No problem, thanks.
[13:02] <xivulon> some users claim that .17 kernel breaks wubi, can somebody please test that and confirm?
[14:45] <xivulon> evand ^
[14:46] <xivulon> also do you recall the discussion about http://www.sendspace.com/file/vwm18u ? the chap does in fact have an sda5 partition, not sure why partman has issues with it
[14:50] <cjwatson> I think that's due to a problem in wubi's preseeding that will happen for any non-English installs
[14:50] <xivulon> cjwatson: can you expand? I cannot access the logs from here
[14:51] <cjwatson> xivulon: I think you need to apply http://paste.ubuntu.com/15325/ (untested)
[14:51] <cjwatson> that form of preseeding was needed before hardy, but was buggy in this kind of way and hardy introduced a better scheme
[14:52] <cjwatson> the installation guide documents the form in that patch now
[14:52] <xivulon> Will do, wasn't aware of that
[14:52] <cjwatson> looks like I missed that wubi used that
[15:07] <evand> odd that it wasn't triggered in other installs
[15:39] <xivulon> was thinking the same thing, anywy will ask the user to try that
[15:44] <xivulon> anything else I should change in the preseed file?
[15:46] <cjwatson> I didn't see anything else obvious, at least not in the same category of problems
[15:46] <cjwatson> didn't do a full audit though
[15:55] <xivulon> I opened bug #235518 if you can think of anything else, feel free to put it in there
[16:42] <xivulon> cjwatson http://ubuntuforums.org/showpost.php?p=5062712&postcount=29
[16:45] <cjwatson> http://ubuntuforums.org/showthread.php?p=5062902#post5062902
[18:17] <davmor2> xivulon: sorry for the late start on the verbose test just got busy.  It's running now and put the log file online as soon as it has finished :)
[18:18] <tmmoyer> I have a package that is a custom GRUB bootloader.  The package name is TrustedGRUB, but I indicate that it provides linux-boot-loader.  Is there anyway in the seed file to have that selected as the bootloader instead of traditional GRUB, while using the seeded answers from the GRUB debconf questions?
[18:32] <tmmoyer> where might I find information/source for the installer that handles bootloaders?  I would like to see how grub is installed and create a custom version that will installer TrustedGRUB from a package that I have created?
[18:50] <davmor2> xivulon: which log file did you want?
[18:51] <davmor2> was it casper.log
[18:51] <xivulon> evand my branching naming convention was to keep one per release i.e. wubi/hardy lupin/hardy and then branch off for intrepid development
[18:51] <xivulon> davmor2: can you remind me of the bug in question?
[18:52] <xivulon> evand, do you prefer to have a single trunk, and only create branches for *.proposed?
[18:52] <davmor2> bug 234974 m-a not functioning in wubi
[18:53] <xivulon> davmor2 you have to install in verbose mode, then from ubuntu tgz /var/log/installer
[18:53] <xivulon> password might be in there (although hashed)
[18:54] <davmor2> xivulon: right no probs
[18:54] <xivulon> davmor2: thx
[18:56] <xivulon> evand, also didn't you mention that new changes didn't have to be in trunk but in a separate branch a few days ago'?
[18:57] <evand> xivulon: correct, I'd prefer for future branches that you create project.trunk or something similar and then branch for things like hardy-proposed, that way there's no confusion or unnecessary branch creation when a new release comes out.
[18:57] <evand> I don't see any need to change existing branches, however.
[18:58] <xivulon> I have no strong preference for branch naming, will do as you say in the future
[18:58] <evand> ok, thanks
[18:58] <xivulon> would you think it is appropriate to rename the current hardy branches to trunk or simply branch off and start fresh?
[18:59] <evand> I think they're fine as-is for now.
[18:59] <xivulon> so intrepid development will take care in a new branch called trunk/devel
[18:59] <evand> but I wont complain if you want to rename them.
[18:59] <xivulon> whatever you prefer
[19:02] <evand> I don't think a new branch is the right solution.  Assuming LP supports branch renaming, changing *.hardy to *.trunk is suitable, though I don't think there's any rush to do that.
[19:02] <xivulon> evand re pm-utils had a message yesterday about a user that had a corrupted fs because of hard reboot after hibernation
[19:03] <xivulon> so yes, I'd like to see that in 8.04.1
[19:03] <davmor2> xivulon: It's up I chmoded the file so you can access it.
[19:03] <xivulon> http://ubuntuforums.org/showpost.php?p=5054940&postcount=6
[19:08] <xivulon> for 230716 cjwatson confirmed that the code was ok in casper, doing that in lupin-casper would be more invasive
[19:08] <xivulon> evand ^
[19:09] <evand> ok
[19:10] <xivulon> on 222546 I had a quick exchange with Lamont via the bug comments, didn't hear anything else since
[19:11] <xivulon> for 229000 yep, didn't have time to look at the code yet, but will do so
[19:11] <xivulon> that was intended more as a reminder for self


[22:28] <Seven_Six_Two> I got 14.04 today, but now the shipping company is asking me to call and confirm with customs. Is there a charge for receiving the loco pack?