[01:21] boo! [01:21] * fullermd spills coffee all over the keyboard. [02:00] hi - any ideas where I can ask about loggerhead please ? I'm struggling to find the homepage and wondered if it was part of bzr [02:02] sysadmin2: Here is the place. [02:02] sysadmin2: Ask and somebody will answer. :-) [02:02] sysadmin2: http://launchpad.net/loggerhead [02:04] thanks - I'm running it on stock karmic, it is not running from the init script - further investigation reveals I can only get it to run if I run it in the foreground with the -f switch - the same command without throws horrible errors [02:06] http://pastebin.ca/1710444 [02:13] sysadmin2: Are you running trunk? [02:13] sysadmin2: start-loggerhead is really not the way loggerhead should be started. [02:13] sysadmin2: Better to use serve-branches if you can. [02:13] apt-get install loggerhead - I took that from the /etc/init.d/loggerhead script [02:13] sysadmin2: Oh, I've never used the package, I don't know what version it is. [02:14] * mkanat actually doesn't even use ubuntu. [02:14] oh hell - thats jaunty not karmic - okay - I'll download trunk [02:14] sysadmin2: Okay. [02:14] sysadmin2: Should just be bzr branch lp:loggerhead I think. [02:14] thank you [02:28] * igc lunch [02:48] please help me [02:48] I'm going mad [02:48] http://paste.ubuntu.com/339059/ [02:48] * poolie tries [02:49] when I run that from the command line all is good [02:49] when I run it from cron it never returns [02:49] ! [02:49] but doesn't throw an exception apparently [02:49] and the processes aren't still running [02:49] is there an equivalent to "set -x" for python? [02:50] not really [02:50] (that i know of) - i'd manually open a file and print things to it [02:50] hm [02:51] could it be that failure_dir is not absolute and it's run from a different directory? [02:51] james_w: when you say 'never returns' do you mean the process is hung? [02:51] what happens if you strace it then? [02:51] the next line after that function is called is: [02:52] sys.stderr.write("Done\n") [02:52] sys.exit(1) [02:52] but I never get the mail [02:52] do you need to set MAILTO maybe? [02:52] and I can't find any processes still running [02:52] MAILTO is set [02:53] if I move the exit() to the first iteration of the loop then it mails me [02:53] oh ok [02:53] if I remove the open() stuff then it works again [02:53] if I only have the open stuff then it works [02:53] but I can't see a mistake with reusing variables [02:53] meaning if you only open it and don't read anything? [02:54] if I just "cat" the files it works [02:54] if I ignore the files and just do the prints with the info in the dicts then it works [02:54] could any of the files be enormous? [02:54] or not a regular file? [02:55] (biab, will try to help more then) [02:55] most are a few bytes [02:55] the biggest might be 1k [03:15] james_w: whats your cron line [03:16] james_w: and what is failure_dir [03:16] strace shows that everything is being printed [03:16] it's something to do with buffering or the like [03:17] <_Andrew> Anyone know how I run a test case on a bzr plugin? [03:17] _Andrew: bzr selftest plugins.pluginname, if its a tes tincluded in the plugin [03:18] james_w: whats the total size ofoutput you are generating ? [03:18] james_w: and do you have HOME set ? [03:18] HOME isn't set in crontab [03:18] total size is not huge [03:18] couple of thousand lines [03:20] my guess is that you're exceeding a buffer in whatever cron has you hooked up to [03:20] and so your process blocks on writing to that pipe [03:22] but it's not still running [03:24] */1 * * * * /bin/bash -c "/usr/bin/python /srv/package-import.canonical.com/new/scripts/categorise_failures.py 1>&2 || false" [03:24] that's the cron line [03:24] I wasn't sure whether it sent email only on failure, and only stderr [03:31] resolved my issue from ealier by upgrading to karmic and a later version of loggerhead - thanks all [03:36] ok, worked around it [03:36] just making the script send the mail itself now [03:37] my guess is that cron didn't like some of the characters that were being output and so refused to send the mail [03:39] could be [03:40] Yeah, could be. Perhaps cron runs with LANG=C or something like that that means Python won't let you write non-ascii unicode objects to stdout? [03:40] surprising he didn't get a mail with the traceback though [03:40] Although I'd -- yeah. [03:40] I was just thinking that :) [03:44] spiv, when will we enjoy your sparking wit live and in person? [03:45] yeah spiv, when??? [03:50] spm (and poolie): at the bbq, I think -- I've had some unplanned disruptions this morning and atm I'm having a bizarre compulsion to try get some work done! [03:52] <_Andrew> wth.. [03:52] <_Andrew> My colleague has somehow managed to remove the same file three times in each commit he's done [03:53] <_Andrew> How's that even possible [03:53] james_w: or it could be you exceeded a system mail size cap [03:53] the canonical servers all have them, unless you get it configured to be larger. [03:54] I'm sending the same text though [03:54] and I could send *larger* text [03:54] spiv: for shame, tsk tsk tsk even [03:54] is someone picking luke up? [04:13] igc, still here? [04:13] is alldocs still the correct thing for the top-level doc pages? [04:13] poolie: yep [04:13] yes [04:13] k [04:14] just getting things restarted after escudero rearrangements [05:07] vila, hi? [05:19] igc here? [05:19] hi bialix [05:19] hi bialix [05:19] vila, hi now? [05:19] hi all [05:19] Is bzr 2 compatible with bzr1 repos? [05:19] Can it still checkout from old repos? [05:19] and commit? [05:19] igc: if you have 5 minutes I can teach you about uplod translations [05:19] GungaDin: yes [05:20] igc: it seems your mails going to me with biiiiiiiiiiiig delay [05:22] bialix: now is bad sorry - need to run some errands before the shops close [05:22] np [05:23] I'll be online after 3 hours [05:32] bbl [05:55] have a good weekend, all [05:55] i'm off to the canonical sydney xmas party soon [07:35] hello bzr [07:36] igc: new pot uploaded [07:36] bialix: mega thanks [07:36] igc: BTW, is fast-export-from-cvs supposed to Just Work? [07:36] bialix: I'm scrambling to wrap things up here before I need to start packing for my leave [07:37] fullermd: does anything-from-cvs Just Work? [07:37] I don't understand [07:37] fullermd: not for me [07:38] bialix: if you get a chance to look at any recently added epxlorer bugs today, that would help [07:38] Well, no. But some of them pretend to :p [07:38] igc: unlikely [07:38] bialix: at this point, I'm either going to package first thing in my morning (13-14 hrs from now) or not at all :-( [07:38] igc: are you going on vacation? [07:38] bialix: yes, offline and out of the city! [07:39] COOL! [07:39] I can release it for you [07:39] bialix: that might be best - we can then wait a little longer for translations to get done over the weekend say [07:40] fullermd: I did plan for fast-export-from-cvs to Just Work fwiw [07:40] so, you're free to fly away as soon as you wish ;-) [07:40] fullermd: and in a sense, *my* bit of it does [07:41] i.e. I think I wrap the underlying script successfully :-) [07:41] but cvs2bzr needs some love I believe [07:42] fullermd: I will say that the cvs2svn guys are really helpful though [07:42] I presume you'll need at least something to point it at a config file. [07:42] I hacked up a conversion manually some time ago, and I had to put together some rather obscure and sparsely-documented config file to get it to work. [07:42] fullermd: so if you need assistance, ping them, Michael Heggerty in particular is great [07:42] (it's nice how cvs2_bzr_ tells you "ERROR: Git output [...]" though :p) [07:43] fullermd: ~1.5-2 months ago I've sent mail to list with my experience about cvs2svn usage re conversion to bzr [07:43] yeah, that's gross [07:43] So f-e-f-c probably needs some way to pass an option through pointing at it. [07:44] fullermd: right. It's a simple patch to add that btw [07:44] igc: enjoy your vacation :-) ping me if needed [07:45] fullermd: it never went into the initial wrapper because the underlying script used to take either options or an options file. Now isn't smart enough to support both [07:45] thanks bialix! [07:45] anybody seen here garyvdm? [07:45] he's offline for ~ week [07:47] bialix: bug 495003 may be a simple fix. It's happening on Windows iiuic and not on Ubuntu [07:47] * fullermd nods. [07:47] Launchpad bug 495003 in bzr-explorer "Tools \ Add Tool dialog generates TypeError" [Undecided,New] https://launchpad.net/bugs/495003 [07:47] bialix: I think someone needs to look at that before 0.10.0 ships [07:47] Just happened to steal some time tonite to fiddle with it and see what it did. [07:49] hi all [07:49] igc: Hey ! Good to see you here :) [07:49] bonjour vila [07:49] hi bialix [07:49] hi vila! [07:50] igc: can I ask you to pilot the doc patches by neil ? [07:50] * bialix looks at igc bug [07:51] Ooer, vila's up and about. Guess that means it's time to go to bed... [07:51] igc: I've tried to review the ones I was comfortable with but except for the "chained bound branches" concepts which I think is wrong and mentioned in several patches, I just can't finish reviews [07:51] fullermd: hey ! [07:52] * bialix wonders why you guys wrote windows-specific bugs [07:54] igc: I need your help [07:54] on phone [07:54] * bialix waiting [07:55] this is not windows-specific bug [07:55] just pyqt 4.4 specific [07:55] QComboBox.addItem (self, QString atext, QVariant auserData = QVariant()) [07:56] you put simple string instead of QVariant [07:56] vila: I'm on vacation within the hour so I won't have time to look over Neil's patches sorry [07:57] bialix: so what's the fix? [07:57] it depends on how you want to use this data [07:57] the fix itself is to wrap data to QVariant [07:57] but then you need to extract this data [07:58] where this data used? [07:58] bialix: so the combo box has nice labels and actual values [07:58] the user sees the nice (l10n) label [07:58] the data is what's returned [07:59] yes, I see data=='bzr' and label=='Bazaar Command' [07:59] right [07:59] where the data used later? [07:59] get_tool() looks up the value [07:59] no where else [08:00] igc: change line 64 to combo.addItem(label, QtCore.QVariant(data)) [08:00] can you test that everything works? [08:01] I'm not sure yet how to use this new feature [08:01] bialix: I can't test it on pyqt 4.4 [08:01] test on your own [08:01] it should work on any pyqt [08:02] bialix: to test the feature, put in some random data and check BZR_CONFIG/explorer/tools.xml has a new entry [08:02] i.e. .bazaar/epxlorer/tools.xml on ubuntu [08:03] it seems work for me [08:03] I'll push the fix [08:04] bialix: works for me too [08:04] thx [08:04] bialix: btw, after adding a tool, it should appear on your Tools menu and in your Toolbox [08:04] igc: can you prepare announce mail draft for me? [08:05] bialix: sure do later tonight [08:05] shall [08:05] igc: pushed [08:06] bialix: thanks! [08:06] without your help this fix won't be so quick ;-) [08:07] igc: btw, fyi, I'm thinking about writing standalone app for explorer [08:08] maybe on xmas vacation [08:08] to drop the dos box? [08:08] yep [08:08] that would rock. dos box yells "non-professional" to me :-( [08:08] this black hole/console is annoying [08:08] yep [08:09] I just need to figure out where to redirect all this junk bzrlib tends to drop on stderr (and stdout sometimes) [08:09] e.g. when ssh connection established et al [08:20] bialix: the easy-don't-think-too-much-about-it will be to have some console for bzr-explorer that can be opened on demand, where you drop the whole content of stdout/stderr [08:20] like many ftp/sftp clients do for example [08:20] that's my intent, just need to convert it to code and see how it will work [12:04] bzr-svn++ # I just bzr merge svn+ssh://'ed and it JustWorked [12:05] And bzr even knows its a merge in log10.. Hrm.. I wonder how that happens [12:09] magic [12:13] Mmm... Well.. since I don't understand it, Clarke says it must be magic :) === mrevell is now known as mrevell-lunch [13:16] how does one debug a _slow_ bzr upload problem? [13:23] Kamping_Kaiser: what is your remote server ? [13:23] Kamping_Kaiser: ftp or sftp ? [13:24] Kamping_Kaiser: by upload you mean the bzr-upload plugin or a regular bzr push ? [13:24] vila: remote version? I don't know (i didn't set it up). using sftp. [13:24] vila: and i was refering to bzr-push, its doing 1-2Kb/s [13:24] s/-/ / [13:25] good morning every one. [13:25] i'm not sure whats caused it - it was either upgrading from the bzr in debian stable, or the repo getting converted from unique branches into a shared repo (which i think is the current situation) [13:25] Hmm, that's highly unusal... unless you have a very high latency or are using a very old format [13:25] hi rubbs [13:26] what does bzr info says about the format and the branch/repo relationship ? [13:28] Kamping_Kaiser: debian *stable*, what bzr version is that ? [13:28] vila: shall i pastebin it? [13:28] s.that.there. [13:28] Kamping_Kaiser: sure [13:28] !paste [13:28] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [13:28] vila: currently using 2.0 from backports, i forget what stable ships by default [13:29] ha, good, I had a horrible doubt about you using 1.12 or something :-) [13:29] hehehe [13:29] vila: http://pastebin.com/f717e494a [13:29] no offense implied though, it's just that the problem would have been totally different [13:30] i've had issues with debians default bzr before, so no offence taken. [13:30] format: unnamed, bad juju [13:31] either the repo or the branch may not have been upgraded [13:31] try bzr info -v sftp://kgoetz@bzr.savannah.nongnu.org/srv/bzr/gnewsense/ [13:33] http://pastebin.com/f646ece25 this appears to know what it is [13:33] good [13:34] you may want to try an upgrade of the branch then [13:34] it should be fast, really fast since you use a shared repo [13:34] thelocal branch? [13:34] the remote one [13:35] I don't know how the upgrade was done there, but it seems that only the repo has been upgraded (at least that's my understanding) [13:35] hm. I'll have to get someone to look at that. [13:35] vila: thanks for your help :) [13:36] Oh, and you want to check what format you use locally, cross-format conversions are still slow [13:36] Kamping_Kaiser: you're welcome, feedback appreciated if you solve the problem ! [13:36] and more help available if you don't :) [13:37] ok. so local tree is rich-root-pack, shared repo with trees is ormat 2a - are you saying i should upgrae my checkout to match teh shred repo? [13:38] * Kamping_Kaiser tries it [13:38] Kamping_Kaiser: yes [13:38] what does 'bzr info -v' says locally ? [13:39] vila: beofre or after upgrade? [13:39] now [13:39] http://pastebin.com/f49fe8c18 [13:39] you mean you did upgrade in the last 2 minutes ? [13:39] * Kamping_Kaiser wonders how he lived before pastebinit [13:39] yes [13:40] hang on and i'll give you before upgrade too [13:40] right, so you use a standalone branch not a 'checkout' [13:40] http://pastebin.com/m9ba9455 pre upgrade [13:41] yeah. my branch predates the move to shared repo [13:41] right, try again, things should go better and faster [13:41] woot. [13:41] you may not even need to upgrade the remote branch, but I think it's worth checking what happened there [13:41] I don't have anything to hack at the moment, so it'll have to be another day. I'll let you know how it goes [13:42] * Kamping_Kaiser takes his headache to bed ;) [13:42] ok [13:42] thanks again, I'll hunt you down if it works and thank you :D [13:43] hehe, take care of your headache ! === mrevell-lunch is now known as mrevell [14:46] igc: go enjoy your vacation :) [14:46] morning vila, bialix, et al [14:47] heya jam! [14:49] Goood morning jam [14:50] morning jam [14:53] thanks jam! [14:53] jam: those fastimport patches look fine btw. Merge away ... [14:54] night all. I'll offline now for a week plus. [14:54] igc: have a great vacation [14:54] shall do! [14:54] igc: you don't forget about me? [14:55] bialix: I trust you to write a nice summary from the NEWS :-) [14:55] rats [14:55] so, enjoy! [14:55] bialix: I didn't forget - just too sleepy sorry! [14:56] :-) [14:56] igc: doing anything special for vacation? [14:56] rubbs: not hanging around here :) [14:56] jam: haha fair enough. === beuno is now known as beuno-lunch [15:40] jam: Launchpad's test suite checks to make sure garbage isn't left behind. On one machine, it's now complaining about _LockWarner, but the other is happy. Any thoughts what would cause this? [15:42] abentley: I'm trying to track some of that stuff down myself. _LockWarner can generally only trigger in a thread, because we run with -Werror (so if it triggers in the main thread it fails PQM) [15:43] when you say "garbage" you mean data on stderr? [15:43] my experience on this so far is single-cpu machines have issues cleaning up resources on secondary threads in a timely manner. [15:43] jam: No, I mean that it has an entry in gc.garbage, i.e. it's not garbage-collectable. [15:43] ah [15:44] jam: It is collectable if I disable the __del__, but that defeats the purpose, of course. [15:47] abentley: right, and _LockWarner is meant to hang of of an open lock and never be in a ref cycle [15:47] jam: And of course, they should be equivalent machines (dual-core x86-64/emt64) [15:49] abentley: you could try something like this: http://paste.ubuntu.com/339283/ [15:49] and see if anything is assigning to LW that shouldn't be [15:52] jam: I've added the slots, but I don't understand the second part. [15:53] 'understand the second part' ? [15:53] The idea is if you have slots and someone assigns to _LockWarner.foo = bar [15:53] it will fail [15:53] rather than allowing a refcycle [15:54] is it possible to inspect the LW class that is left in gc.garbage? [15:54] or is it only reproducible on a machine you don't have direct access to? [15:57] jam: I see. Well, it's not failing. [15:58] jam: It is possible to inspect the LW class in gc.garbage. What should I look for? [15:59] abentley: well, it is in gc.garbage because it is in a refcycle and has __del__ right? [15:59] So you need to find the attribute that is causing the refcycle [16:00] without __slots__ then doing "pp LW.__dict__" should give you an idea [16:00] (with __slots__ there is no __dict__ attribute) [16:03] jam: pp lw.__dict__ [16:03] {'lock_count': None, [16:03] 'repr': 'LockableFiles()'} [16:05] jam: If there were live objects that referred to the LW, it wouldn't be in gc.garbage, right? [16:13] jam: gc seems to think that the LW doesn't refer to anything uncollectable: http://paste.ubuntu.com/339310/ [16:14] jam: And note that the lock count is None. This implies that it's been locked and unlocked, because it's initialized to 0, not None. [16:19] abentley: well, repr is a string and lock_count is None, I don't see how it could be in a reference cycle [16:20] unless maybe the class itself is referencing the object? [16:20] jam: yeah, me neither. [16:20] can you check the references from bzrlib.lockdir._LockWarner ? [16:20] or gc.get_referents(gc.get_referents(gc.garbage[0])[-1]) [16:20] (should be the same thing) [16:21] and what does sys.getrefcount say? [16:22] hmm... looking at http://docs.python.org/library/gc.html [16:22] it looks like if gc thought it was once in a refcycle [16:22] jam: http://paste.ubuntu.com/339321/ [16:22] it would go into gc.garbage [16:22] and never come out [16:23] even after that cycle was fixed [16:23] jam: sys.getrefcount(gc.garbage[0]) returns 2 [16:23] http://docs.python.org/library/gc.html#gc.garbage specifically [16:23] abentley: right, that means that gc.garbage is the only thing referring to this object now [16:23] priority on *now* [16:26] jam: Okay, so if I follow the instructions and del gc.garbage[:], and then gc.collect, the list is empty. [16:26] right [16:26] from reading the docs, it sure looks like at some point LockWarner was referring to itself when gc.collect() ran [16:27] oh, or it was part of some bigger cycle [16:27] you know, it could have been in something like a comprehension [16:27] jam: I think this means that the test infrastructure is broken. Do you agree? [16:27] so, trying to read fully [16:27] it sounds like if LW was in a refcycle with other code that didn't have __del__ [16:28] only *it* would get put into the garbage [16:28] "By default, this list contains only objects with __del__() methods." [16:28] the key is also this part: [16:28] " including objects not necessarily in the cycle but reachable only from it." [16:28] so if we have a cycle, and hanging off of that is this class with __del__ it could get put into gc.garbage [16:28] which is a bit broken in python, if you ask me [16:29] of course, you can't fix python for your test suite :) [16:29] you might try running with: DEBUG_SAVEALL [16:29] ? [16:29] The test infrastructure wants to know if we've left anything uncollectable behind. It seems to me that we haven't left anything uncollectable behind. [16:30] abentley: but it may have been uncollectable at some point, which then gets cleaned up by the time you investigate... [16:32] jam: True, but my point is that the test infrastructure is buggy, and presumably the way to fix it is to either disable automatic garbage collection during the test run or to do this del gc.garbage[:] thing. [16:32] jam: I assume if it was actually uncollectable, it would get put back into gc.garbage? [16:33] abentley: I'm willing to write a test to find out :) [16:35] abentley: You seem to be correct, I'll paste [16:38] abentley: http://paste.ubuntu.com/339330/ [16:39] so doing "del gc.garbage[:]; gc.collect()" does, indeed, seem to restore things that are still in cycles [16:39] jam: cool. [16:41] jam: So what's odd here is that I've disabled the gc before running the test. After the test, gc.garbage is []. Then I call gc.collect, and it adds the lock warner. [16:42] abentley: well, disabling gc means that nothing will get put into gc.garbage as gc.collect is never running [16:42] jam: So it seems there's a cycle, but python fixes it. [16:42] yeah [16:42] it does seem a bit odd [16:42] jam: It means that there was a cycle after the test exited. [16:42] if you go back to: http://docs.python.org/library/gc.html#gc.garbage [16:43] jam: at least, AFAICT. [16:43] if DEBUG_SAVEALL is not set [16:43] then it only puts the objects with __del__ into the garbage [16:43] and goes ahead and deletes the rest [16:43] which may be breaking the cycle somehow [16:43] you might try running with [16:43] gc.DEBUG_SAVEALL = True [16:44] gc.collect() === beuno-lunch is now known as beuno [16:44] or something like that [16:44] I should mention that pyrex/C objects get a _dealloc() function which doesn't block the garbage collector [16:44] and can run actions at deconstruction [16:45] so if LockWarner was in a cycle with an extension class, the extension class may break the cycle in its deconstructor [16:48] Actually, I believe DEBUG_SAVEALL is a flag you pass into gc.set_debug() [16:55] jam: Oh, this gets better and better: repr(gc.garbage) [16:55] *** UnicodeEncodeError: 'ascii' codec can't encode character u'\u02bb' in position 20: ordinal not in range(128) [16:59] probably a case where an object is returning a Unicode from __str__ [16:59] which we've been guilty of in the past [16:59] (and may still be guilty of...) [16:59] well, tries, I think it forcibly casts the return from __str__ to a str [17:00] jam: So with SAVEALL, there are 39 LockWarners in gc.garbage. [17:09] Hi ! I'm experiencing a proxy problem with tortoiseBzr [17:09] strange [17:09] bzr: ERROR: Connection error: while sending OPTIONS /inkscape/: (10061, 'Connection refused') [17:09] Calvin1602: how are you setting your proxy? [17:09] ( the URL was https://launchpad.net/inkscape ) [17:10] Well, I don't, my question is how do I do it :) [17:10] well, https://launchpad.net/inkscape isn't an actual branch [17:10] bzr branch lp:inkscape would probably work better for you [17:10]