[00:01] evening... [00:29] 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] dOxxx: I don't follow [01:06] * igc bbiab === abentley1 is now known as abentley [01:24] 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] 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] yes [01:28] thats makes sense [01:28] simply not raising TestSkipped did not make sense. === abentley1 is now known as abentley === retupmoca` is now known as retupmoca [01:50] Is there any command in bazaar to remove those backup files? ex:database.php.~1~ [01:51] ricardo_br: it's a bit more than you're asking for but bzr clean-tree --ignored will kill them === jamesh_ is now known as jamesh [01:57] 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] ricardo_br: well 'find . -name \*~ -print0 | xargs -0 rm' will do it i guess [02:02] mwhudson: wow, I really need to study these shell commands, it worked, thanks [02:03] ricardo_br: find | xargs is both very handy and somewhat crazy :-) === abentley1 is now known as abentley [02:07] 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] ricardo_br: you know the saying "unix *is* user friendly, it's just picky about who its friends are" ? [02:09] Oh wow! My original "bzr pull" isn't entirely dead. [02:10] * igc lunch === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley [02:17] mwhudson: no I don't know this one, probably I'm that slow second cousin [02:23] ricardo_br: I think you want bzr clean-tree --detritus by the way. [02:30] mkanat: thank you! It's exactly what I'm looking for, I don't have to be friend with unix anymore [02:30] :-) [02:39] oh right [02:44] mwhudson: Did you see my long email? [02:44] mkanat: yes, it's been on my "to reply" list for about 7 hours now :) [02:45] mwhudson: Hahaha, okay. :-) === abentley1 is now known as abentley [03:03] mkanat: another team in launchpad trying spawning [03:03] mkanat: the scars are ugly and fresh [03:03] mwhudson: For loggerhead? [03:03] no, for some u1 related thing [03:03] mkanat: they went back to using paste [03:03] Okay. [03:03] Well, Spawning does say it's still a beta. [03:04] ehh, i guess i should reply to the mail [03:04] then have a conversation [03:04] not the other way around :-) [03:04] mwhudson: Okay. :-) [03:04] mwhudson: Spawning was, of course, just a random idea without any research yet. :-) [03:04] mwhudson: The more general idea being "scale better". :-) [03:05] mkanat: yes, i think that's basically the best idea [03:08] lifeless: can you remember the problems with spawning? [03:08] i have this vague recollection was that it wasn't very specific, it just didn't work very well [03:08] and was too magical [03:11] yes [03:11] it died inthe ass for u1 [03:11] 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] s/thing /think / [03:12] my suggestion if you want cpu concurrency for loggerhead is haproxy [03:12] or squid [03:12] just add another backend service and tell the frontend stuff to send to both. [03:12] simple, easy to admin, no code changes needed. [03:13] yeppers [03:20] lifeless: That was my idea as well. [03:20] We just need a way to share the revision cache between processes and then we're set. [03:20] That scales across cores and machines as well. [03:21] holy cow, it's an utter mission compiling python extensions for x64 on windows [03:21] Once upon a time there was someone doing distributed bugs (with bzr, I think, but no matter) [03:22] 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] 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] AfC: "bugseveryehwere" [03:24] AfC: http://bugseverywhere.org/be/show/HomePage [03:28] 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] what do I do now? [03:30] is there anyway to delete that comment with the "resubmit" vote? [03:31] mwhudson: that was what I was thinking of [03:31] AfC: all abentley's fault iirc [03:31] mwhudson: right [03:31] mkanat: well, not really. What good is a centralized [only] bug database if you're not on the internet? [03:32] If you take distributed == disconnected you empower a lot more than just branches. [03:32] AfC: Yeah, to some degree. I think it depends on the project. [03:33] mwhudson: do you know if Aaron is [still] using bugseverywhere? [03:33] AfC: not much, i think [03:34] AfC: but here he is, you can ask him :-) [03:34] 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] abentley: mwhudson mentioned a project of yours you once worked on, "bugseverywhere"; I was curious what your current opinion of it is? [03:35] AfC: Sure, but that's a separate issue, I think. [03:35] mkanat: that's the issue I'm trying to redress [03:35] AfC: Though not totally. [03:35] AfC: Fair enough. :-) [03:35] AfC: There are desktop clients for some trackers that will do offline work. [03:35] Doesn't whatsitsname include bug stuff... [03:36] 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] AfC: I think it's still a useful idea, but the tool could use some work to become more forgiving. [03:36] Fossil, that's it. The thing the SQLite guy did. [03:36] AfC: That's a situation I haven't thought of much, I have to admit. [03:36] AfC: Where I am, it's almost impossible to get away from the Internet. :-) [03:36] http://www.fossil-scm.org/index.html/doc/tip/www/bugtheory.wiki [03:37] AfC: Chris Ball maintains it now, and there's a small community around it, which is better than I ever did. [03:37] abentley: fair enough [03:38] theres another distributed bug db [03:38] (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] mkanat: [see? :)] [03:38] lifeless: oh? [03:39] AfC: I'll mail you [03:39] some web3 thing - the sharecropper argument, they made a distributed db and wrote a bug tracker on it === abentley1 is now known as abentley [03:40] lifeless: you have an idea of a google phrase to hunt for? [03:41] 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] mkanat: my email is a bit of a ramble tbh so far [03:41] oh well [03:41] 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] mwhudson: That's OK. :-) [03:41] lifeless: ok, thanks! [03:41] http://www.stackfoundry.com/dbug/ could be interesting too [03:41] * AfC ends essentially off topic conversation [03:42] AfC: I have to admit I found it interesting, since I'm one of the primary developers of a bug-tracking system. [03:42] 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] AfC: So if you find any of those to be particularly useful or interesting, I'd be interested to know. [03:43] AfC: http://code.bestpractical.com/project/Prophet [03:44] http://syncwith.us/sd/bugs [03:44] lifeless: thanks Robert. Will look. [03:44] I make no assertions [03:44] it crossed my radar a while back and seemed interesting [03:44] though it looks like they use git now for the bts, rather than prophet, which doesn't fit my memory [03:44] lifeless: NO WARRANTIES :) [03:45] lifeless: k [03:45] * AfC hibernates [or, reboots and fscks assuming the thing crashes again] [03:50] mkanat: mail sent [03:50] 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] oh, maybe because we tie access control up with the translation from name -> id [03:58] man [03:58] verterok_: hi [03:58] dOxxx: hi [03:59] we need a much smarter frontend :( [03:59] RenatoSilva: heya [04:00] mkanat: I wouldn't share the caches [04:00] mkanat: tell the front end how much of the path to hash to the same backends on [04:00] 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] lifeless: That would be OK, too. [04:01] hm, the frontend we already have could do that [04:01] lifeless: We're also discussing the possibility of just removing the cache entirely. [04:01] seeing as it has the branch id to hand [04:01] mwhudson: Are you using your router from the sprint? I'm using my eee as a router again! [04:01] well [04:01] yes [04:01] abentley: yes, finally [04:01] abentley: argh [04:01] abentley: because of the xx:45 disconnects? [04:01] mkanat: I've suggested that that is a good idea :) [04:02] what's the arg for bzr selftest that makes it faster? [04:02] RenatoSilva: -s bp.pluginname [04:02] mwhudson: That, and increasingly-agonizing internet connectivity in general. [04:02] RenatoSilva: note that this prefix is buggy [04:02] abentley: what did you have before? [04:02] 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] mwhudson: wrt54g [04:03] 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] abentley: huh, i thought they were ok [04:03] mkanat: i think it is [04:03] lifeless: interface conformance tests? [04:03] mwhudson: I've used this one for years. Maybe the love is gone. [04:04] My WRT-54G is pretty much OK, though I have DD-WRT on it. [04:04] abentley: or maybe your ire needs to be sent further upstream [04:04] lifeless: can't find any info about "bp" in bzr help selftest [04:04] mwhudson: I tried that, but elmo wasn't having it. [04:04] but i guess changing router is a good first thing to try [04:04] abentley: maybe not that far :-) [04:05] * rubbs does a little dance. His first patch ever was just accepted [04:05] mwhudson: I went to the vanguard on #is, but elmo joined the conversation. [04:05] abentley: i meant your isp [04:07] 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] abentley: oh right [04:11] rubbs: 'Grats! [04:12] mkanat: thanks! [04:16] anyone else getting this error? http://img69.imageshack.us/img69/9431/qterror.png [04:42] mkanat: fyi; we were arrrgggghhh!ing yesterday over the pager in gdb? rtfm reveals: (gdb) set pagination off :-) [04:42] spm: Ahhh. :-) [04:43] doncha hate it when the solution is the obvious one! [04:43] :-) [04:45] spm: set height 0 also does that i think [04:48] 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] night mwhudson, have a great w/e! [04:51] spm: well i'm working tomorrow :) [04:51] swap day for a couple of weeks [04:52] ahhh. fair enough. that'll learn you for having a honeymoon :-P [04:54] yeah === keithy_ is now known as keithy === keithy_ is now known as keithy [05:34] what version of pycrypto and paramiko does bzr use? [05:39] whatever you have installed [05:39] [was that what you meant to ask?] [05:49] lifeless: sorry, it's late and I'm not thinking straight. what version of pycrypto and paramiko does the windows installer bundle? [05:51] no idea; I thought pycrypto was built in now, and its likely latest released paramiko [05:55] 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] lifeless: Is it because I'm using python 2.6? [05:56] 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] dOxxx: I'm pretty sure we fixed all our deprecated warnings [05:56] what bzr are you using? [05:58] 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] oh [06:00] :( [06:00] 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] yeah [06:04] you could fix it :) [06:04] bleh [06:04] :) [06:04] not at 1am ;) [06:41] good night! [06:42] Yes, stock pyrcrpto has warnings with py2.6. [06:42] ah [06:42] * fullermd khan speel... [06:42] There are patches floating around. I know there's one on LP somewhere for Ubuntu. The FreeBSD port has one. [06:42] hmm maybe I'll scrounge around tomorrow [06:42] thanks for the info [06:42] (neither being platform-specific; it's pure py) [06:43] good night :) === abentley1 is now known as abentley [07:33] 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] hi ... i have pbm to access a repository behind a proxy... what should i look to? [08:55] i've well my http_proxy variable defined [11:59] jam: when you'll have a couple of free minutes -- I have a question [12:15] Hello. [12:16] 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] Could anyone help me with that? [12:17] that sounds rather broken [12:17] Garagoth: could you pastebin the full traceback? [12:17] Garagoth: Pastebin the traceback. [12:17] D'oh~ [12:17] MvG: hmm, I'm getting TracError: Unsupported version control system "bzr" [12:18] MvG: but unsure why [12:18] night all [12:18] night igc! [12:18] igc: Good night. :) [12:18] pastebin ? [12:18] Garagoth: Paste it on http://paste.ubuntu.com/ or a similar site and give us the URL. [12:18] ubottu: paste? [12:18] Sorry, I don't know anything about paste? [12:18] hmm [12:18] Hi LarstiQ! Nice to hear from you [12:18] Thanks Peng [12:18] igc: likewise :) [12:19] 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] http://paste.ubuntu.com/323262/ [12:19] MvG: oh, ok [12:19] Garagoth: ehm, your python install seems to be broken [12:20] LarstiQ: Ok, what is wrong with it? [12:21] Garagoth: What distro are you on? [12:21] Archlinux [12:21] Garagoth: Or, um, OS in general? [12:21] Oh. [12:22] j~.~.~. [12:22] gah [12:22] 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] Garagoth: To be more specific, it's empty. [12:23] Peng: Both release and version are empty. [12:23] Garagoth: Yes, well, that would be your problem. [12:25] Ok. version now works. [12:25] Note to self: File Python bug: platform._parse_release_file UnboundLocalError if the file is empty. [12:25] (Or if the first line is.) [12:25] release is still empty... but I had a test version file not from my distro ;-) [12:26] Anyway, I was eating pizza and/or watching TV. See ya. [12:26] Thanks for info. [12:26] and help/ [12:29] Now I have another issue... http://paste.ubuntu.com/323273/ [12:34] LarstiQ: hi [12:38] LarstiQ: I have some experience with trac-bzr, so I might help maybe [12:46] Anyone with fast-import experience? http://paste.ubuntu.com/323273/ [12:49] Garagoth: are you using the latest version of fast-impor from trunk? [12:50] revision-id: ian.clatworthy@canonical.com-20091106080627-0n409tg6rrj2hhb0 [12:50] date: 2009-11-06 18:06:27 +1000 [12:50] build-date: 2009-11-20 13:50:32 +0100 [12:50] revno: 260 [12:50] branch-nick: bzr-fastimport [12:51] I don't know what is build-date [12:51] anyway this is most likely bug in the plugin [12:51] Looks like date when i branched this repository [12:52] fast-import author is igc, he said goodnight half hour ago [12:52] you may want to file a bug [12:52] or try to use more recent/older revision [12:52] sorry, can't say more [12:53] Mm. Thanks. [12:55] plugin version is 0.9.0dev [12:56] 0.9.0dev means unreleased-yet version [12:56] it can has bugs inside [12:56] your traceback is cleanly bug [12:57] revno 260 -- is the latest version in trunk [12:57] Garagoth: you really need to file a bug report [12:59] Ok, I will. === verterok_ is now known as verterok [14:17] morning bialix, what's your question? [14:17] hi jam [14:17] jam: https://code.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp_trunk [14:18] this branch seems is not needed anymore? [14:18] we have your fix in the trunk, I'm not sure what the purpose of this branch [14:18] if it really no needed, can you mark it as merged or abandoned? [14:19] jam ^ [14:19] bialix: Sure, though I would have thought the fix would have been merged from there [14:19] anyway, I can mark it merged [14:19] jam: it strange but trunk has different your revision with slightly different commit message [14:19] I might have done it 2 times or something [14:19] and with the same revno [14:19] no big deal [14:19] thanks jam! [14:20] or maybe did an uncommit? [14:20] anyway [14:20] done [14:20] thanks [14:20] jam: and while I've got a bit of your attention, can I point on Bug 485771? [14:20] Launchpad bug 485771 in bzr "[win32][2.1.0b3] windows command-line parser replace \ with /" [Undecided,Confirmed] https://launchpad.net/bugs/485771 [14:21] I can imagine why it works as it works now, but I have reasons to think it's not right [14:23] 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] however note that if you do "bzr commit -m "foo\bar" it will 'just work' [14:24] also note that with the proposed patch, "bzr commit -m foo\bar" is going to warn/prompt you... [14:24] anyway, I forget the specific function, but certainly we could only try to expand things that have ? or * in them. [14:24] hmmm [14:24] I think I want to write a patch to disable glob with env variable [14:25] jam: BZR_GLOB=0 will be OK for you? [14:25] so caveat the discussion about it breaking scripts, etc [14:26] it seems ok [14:26] I might put "BZR_WIN32_GLOB=0" [14:26] or... BZR_WIN32_NOGLOB=1 [14:26] so many choices [14:26] flkip a coin? [14:26] anyway, I'll let you work out the details [14:26] yeah [14:26] BZR_WIN32_NOGLOB and any non-empty value [14:27] that sounds sane for me [14:27] something like there is done for NO_PROXY? [14:27] thx for suggestion, I'll try to make a patch this weekend [14:28] jam: is there planned b4? [14:28] bialix: yeah, I'm pretty sure, and certainly at least an rc1 [14:28] so rc1 => 2.1.0 final won't have many changes, but current => rc1 can [14:28] I just need to have some gap to make sure NOGLOB patch will be landed for 2.1 [14:29] basically at rc1 it goes 'stable' [14:29] you've got ~2 months [14:29] more than enough :-) [14:48] 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] on-top? [14:50] bialix: do both, not just noglob [14:50] ah, understand [14:51] noglob is useful, but it is a big hammer that people have to think about to turn on [14:51] rather than have things "just work" most of the time [14:52] jam: ok, I understand, but noglob is simpler to write right now, do what I mean needs some thinking [14:52] jam: another your branch @ qbzr: https://code.launchpad.net/~jameinel/qbzr/progress [14:52] do you recall what is it off hands? [14:57] bialix: I think qannotate just showed "loading" and that patch adds a progress bar [14:58] so that you could see how close it was to done [14:58] the progress bar was commented out in the code [14:58] I just uncommented it, etc. [14:59] I don't know where that widget is used, etc. [14:59] I haven't focused on it in a while [14:59] but it was nicer at the time [15:00] jam: ok thanks, I'll try to get a closer look on your changes, a bit later [15:02] 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] Garagoth: svn-import does not work for you? [15:04] Not tried that yet. [15:05] Is it part of bzr-svn ? [15:05] yep, it's from bzr-svn [15:05] Ok.. let me build that... [15:16] hi, i do a bzr st in my child branch and get [15:16] pending merges: [15:17] Peter Smith 2009-11-11 More stuff for ... [15:17] This info is available only in my parent branch , right? [15:18] so why is it shown to me? [15:18] You merged it but didn't commit it? [15:20] 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] so imo either he has merged all his changes to central repo or not [15:21] and if not, i dont need to see them!? [15:23] bialix: bzr svn-import seems to work. [15:23] Thanks. [15:25] is it understandable what i mean? [15:25] I cant do anything to clear the status [15:28] 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] Garagoth: something weird with your bzr [15:29] Garagoth: what version of bzr you are using? [15:29] 2.0.2 [15:29] 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] Garagoth: and bzr-svn? 1.0.1? [15:31] yes. [15:32] Tak: 41.2.30 is a normal revspec [15:32] Tak: It's just a revision that was committed as part of a merge [15:32] Garagoth: something weird, but I have no idea what exactly. [15:32] Tak: You can see it if you "bzr log -n 2" [15:32] hmm [15:35] bialix: http://paste.ubuntu.com/323424/ [15:35] trace from that error, from .bzr.log [15:36] Garagoth: it lloks like bzr-svn incorrectly working with bzr internals [15:36] Garagoth: it seems it's not your day today :-/ [15:36] bialix: Should I post a bug report about this? [15:36] yes, pleasd [15:36] yes, please [15:36] that would be third today... first day of bzr, and... [15:37] Garagoth: don't give up! [15:37] Garagoth: does there is something non-stadard in your system? filesystem? [15:37] Ha. I have 219 svn revisions to import, each of about 80MB when targzipped... [15:38] *non-standard [15:38] filesystem is ext3 [15:38] on raid5 [15:38] and lvm on top of it [15:38] Garagoth: does you svn repo have many branches? [15:38] not a single one. [15:38] can you try then just simple: bzr branch URL/to/svn [15:39] what is lvm? [15:39] logical volume manager [15:39] 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] it is used to make 'partitions' on disks... [15:43] bialix: bzr branch started similarly as svn-import (it scanned all revisions), and now it hangs on copying revision 0 [15:43] and svn repo starts from revision 1 ... [15:43] Garagoth: my bad, use URL/to/svn/trunk [15:44] smagoun: bzr merge -rN..N-1 [15:44] ah, no, there is revision 0, sorry. It is empty. [15:44] bialix: nifty, I'll try that. Thanks [15:44] bialix: You mean URL to working copy or what...? [15:45] Garagoth: no, I mean svn repo [15:45] using your traceback from paste it should be like this: file:///repository/svn/mudlib/trunk [15:46] bialix: There is no such thing. [15:46] Garagoth: file:///repository/svn/mudlib/ <-- is it correct URL to your svn repo you want to convert? [15:46] in repository/svn/mudlib I have: [15:46] conf dav db format hooks locks [15:46]