[01:21] <lifeless> boo!
[01:21]  * fullermd spills coffee all over the keyboard.
[02:00] <sysadmin2> 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] <mkanat> sysadmin2: Here is the place.
[02:02] <mkanat> sysadmin2: Ask and somebody will answer. :-)
[02:02] <mkanat> sysadmin2: http://launchpad.net/loggerhead
[02:04] <sysadmin2> 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] <sysadmin2> http://pastebin.ca/1710444
[02:13] <mkanat> sysadmin2: Are you running trunk?
[02:13] <mkanat> sysadmin2: start-loggerhead is really not the way loggerhead should be started.
[02:13] <mkanat> sysadmin2: Better to use serve-branches if you can.
[02:13] <sysadmin2> apt-get install loggerhead - I took that from the /etc/init.d/loggerhead script
[02:13] <mkanat> 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] <sysadmin2> oh hell - thats jaunty not karmic - okay - I'll download trunk
[02:14] <mkanat> sysadmin2: Okay.
[02:14] <mkanat> sysadmin2: Should just be bzr branch lp:loggerhead I think.
[02:14] <sysadmin2> thank you
[02:28]  * igc lunch
[02:48] <james_w> please help me
[02:48] <james_w> I'm going mad
[02:48] <james_w> http://paste.ubuntu.com/339059/
[02:48]  * poolie tries
[02:49] <james_w> when I run that from the command line all is good
[02:49] <james_w> when I run it from cron it never returns
[02:49] <poolie> !
[02:49] <james_w> but doesn't throw an exception apparently
[02:49] <james_w> and the processes aren't still running
[02:49] <james_w> is there an equivalent to "set -x" for python?
[02:50] <poolie> not really
[02:50] <poolie> (that i know of) - i'd manually open a file and print things to it
[02:50] <poolie> hm
[02:51] <poolie> could it be that failure_dir is not absolute and it's run from a different directory?
[02:51] <poolie> james_w: when you say 'never returns' do you mean the process is hung?
[02:51] <poolie> what happens if you strace it then?
[02:51] <james_w> the next line after that function is called is:
[02:52] <james_w> sys.stderr.write("Done\n")
[02:52] <james_w> sys.exit(1)
[02:52] <james_w> but I never get the mail
[02:52] <poolie> do you need to set MAILTO maybe?
[02:52] <james_w> and I can't find any processes still running
[02:52] <james_w> MAILTO is set
[02:53] <james_w> if I move the exit() to the first iteration of the loop then it mails me
[02:53] <poolie> oh ok
[02:53] <james_w> if I remove the open() stuff then it works again
[02:53] <james_w> if I only have the open stuff then it works
[02:53] <james_w> but I can't see a mistake with reusing variables
[02:53] <poolie> meaning if you only open it and don't read anything?
[02:54] <james_w> if I just "cat" the files it works
[02:54] <james_w> if I ignore the files and just do the prints with the info in the dicts then it works
[02:54] <poolie> could any of the files be enormous?
[02:54] <poolie> or not a regular file?
[02:55] <poolie> (biab, will try to help more then)
[02:55] <james_w> most are a few bytes
[02:55] <james_w> the biggest might be 1k
[03:15] <lifeless> james_w: whats your cron line
[03:16] <lifeless> james_w: and what is failure_dir
[03:16] <james_w> strace shows that everything is being printed
[03:16] <james_w> 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] <lifeless> _Andrew: bzr selftest plugins.pluginname, if its a tes tincluded in the plugin
[03:18] <lifeless> james_w: whats the total size ofoutput you are generating ?
[03:18] <lifeless> james_w: and do you have HOME set ?
[03:18] <james_w> HOME isn't set in crontab
[03:18] <james_w> total size is not huge
[03:18] <james_w> couple of thousand lines
[03:20] <lifeless> my guess is that you're exceeding a buffer in whatever cron has you hooked up to
[03:20] <lifeless> and so your process blocks on writing to that pipe
[03:22] <james_w> but it's not still running
[03:24] <james_w> */1 * * * * /bin/bash -c "/usr/bin/python /srv/package-import.canonical.com/new/scripts/categorise_failures.py 1>&2 || false"
[03:24] <james_w> that's the cron line
[03:24] <james_w> I wasn't sure whether it sent email only on failure, and only stderr
[03:31] <sysadmin2> resolved my issue from ealier by upgrading to karmic and a later version of loggerhead - thanks all
[03:36] <james_w> ok, worked around it
[03:36] <james_w> just making the script send the mail itself now
[03:37] <james_w> 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] <poolie> could be
[03:40] <spiv> 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] <poolie> surprising he didn't get a mail with the traceback though
[03:40] <spiv> Although I'd -- yeah.
[03:40] <spiv> I was just thinking that :)
[03:44] <poolie> spiv, when will we enjoy your sparking wit live and in person?
[03:45] <spm> yeah spiv, when???
[03:50] <spiv> 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] <lifeless> james_w: or it could be you exceeded a system mail size cap
[03:53] <lifeless> the canonical servers all have them, unless you get it configured to be larger.
[03:54] <james_w> I'm sending the same text though
[03:54] <james_w> and I could send *larger* text
[03:54] <spm> spiv: for shame, tsk tsk tsk even
[03:54] <lifeless> is someone picking luke up?
[04:13] <poolie> igc, still here?
[04:13] <poolie> is alldocs still the correct thing for the top-level doc pages?
[04:13] <igc> poolie: yep
[04:13] <igc> yes
[04:13] <poolie> k
[04:14] <poolie> just getting things restarted after escudero rearrangements
[05:07] <poolie> vila, hi?
[05:19] <bialix> igc here?
[05:19] <poolie> hi bialix
[05:19] <igc> hi bialix
[05:19] <poolie> vila, hi now?
[05:19] <bialix> hi all
[05:19] <GungaDin> Is bzr 2 compatible with bzr1 repos?
[05:19] <GungaDin> Can it still checkout from old repos?
[05:19] <GungaDin> and commit?
[05:19] <bialix> igc: if you have 5 minutes I can teach you about uplod translations
[05:19] <spiv> GungaDin: yes
[05:20] <bialix> igc: it seems your mails going to me with biiiiiiiiiiiig delay
[05:22] <igc> bialix: now is bad sorry - need to run some errands before the shops close
[05:22] <bialix> np
[05:23] <bialix> I'll be online after 3 hours
[05:32] <igc> bbl
[05:55] <poolie> have a good weekend, all
[05:55] <poolie> i'm off to the canonical sydney xmas party soon
[07:35] <bialix> hello bzr
[07:36] <bialix> igc: new pot uploaded
[07:36] <igc> bialix: mega thanks
[07:36] <fullermd> igc: BTW, is fast-export-from-cvs supposed to Just Work?
[07:36] <igc> bialix: I'm scrambling to wrap things up here before I need to start packing for my leave
[07:37] <igc> fullermd: does anything-from-cvs Just Work?
[07:37] <bialix> I don't understand
[07:37] <bialix> fullermd: not for me
[07:38] <igc> bialix: if you get a chance to look at any recently added epxlorer bugs today, that would help
[07:38] <fullermd> Well, no.  But some of them pretend to   :p
[07:38] <bialix> igc: unlikely
[07:38] <igc> 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] <bialix> igc: are you going on vacation?
[07:38] <igc> bialix: yes, offline and out of the city!
[07:39] <bialix> COOL!
[07:39] <bialix> I can release it for you
[07:39] <igc> bialix: that might be best - we can then wait a little longer for translations to get done over the weekend say
[07:40] <igc> fullermd: I did plan for fast-export-from-cvs to Just Work fwiw
[07:40] <bialix> so, you're free to fly away as soon as you wish ;-)
[07:40] <igc> fullermd: and in a sense, *my* bit of it does
[07:41] <igc> i.e. I think I wrap the underlying script successfully :-)
[07:41] <igc> but cvs2bzr needs some love I believe
[07:42] <igc> fullermd: I will say that the cvs2svn guys are really helpful though
[07:42] <fullermd> I presume you'll need at least something to point it at a config file.
[07:42] <fullermd> 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] <igc> fullermd: so if you need assistance, ping them, Michael Heggerty in particular is great
[07:42] <fullermd> (it's nice how cvs2_bzr_ tells you "ERROR: Git output [...]" though   :p)
[07:43] <bialix> fullermd: ~1.5-2 months ago I've sent mail to list with my experience about cvs2svn usage re conversion to bzr
[07:43] <igc> yeah, that's gross
[07:43] <fullermd> So f-e-f-c probably needs some way to pass an option through pointing at it.
[07:44] <igc> fullermd: right. It's a simple patch to add that btw
[07:44] <bialix> igc: enjoy your vacation :-) ping me if needed
[07:45] <igc> 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] <igc> thanks bialix!
[07:45] <bialix> anybody seen here garyvdm?
[07:45] <bialix> he's offline for ~ week
[07:47] <igc> bialix: bug 495003 may be a simple fix. It's happening on Windows iiuic and not on Ubuntu
[07:47]  * fullermd nods.
[07:47] <igc> bialix: I think someone needs to look at that before 0.10.0 ships
[07:47] <fullermd> Just happened to steal some time tonite to fiddle with it and see what it did.
[07:49] <vila> hi all
[07:49] <vila> igc: Hey ! Good to see you here :)
[07:49] <bialix> bonjour vila
[07:49] <vila> hi bialix
[07:49] <igc> hi vila!
[07:50] <vila> igc: can I ask you to pilot the doc patches by neil ?
[07:50]  * bialix looks at igc bug
[07:51] <fullermd> Ooer, vila's up and about.  Guess that means it's time to go to bed...
[07:51] <vila> 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] <vila> fullermd: hey !
[07:52]  * bialix wonders why you guys wrote windows-specific bugs
[07:54] <bialix> igc: I need your help
[07:54] <igc> on phone
[07:54]  * bialix waiting
[07:55] <bialix> this is not windows-specific bug
[07:55] <bialix> just pyqt 4.4 specific
[07:55] <bialix> QComboBox.addItem (self, QString atext, QVariant auserData = QVariant())
[07:56] <bialix> you put simple string instead of QVariant
[07:56] <igc> vila: I'm on vacation within the hour so I won't have time to look over Neil's patches sorry
[07:57] <igc> bialix: so what's the fix?
[07:57] <bialix> it depends on how you want to use this data
[07:57] <bialix> the fix itself is to wrap data to QVariant
[07:57] <bialix> but then you need to extract this data
[07:58] <bialix> where this data used?
[07:58] <igc> bialix: so the combo box has nice labels and actual values
[07:58] <igc> the user sees the nice (l10n) label
[07:58] <igc> the data is what's returned
[07:59] <bialix> yes, I see data=='bzr' and label=='Bazaar Command'
[07:59] <igc> right
[07:59] <bialix> where the data used later?
[07:59] <igc> get_tool() looks up the value
[07:59] <igc> no where else
[08:00] <bialix> igc: change line 64 to             combo.addItem(label, QtCore.QVariant(data))
[08:00] <bialix> can you test that everything works?
[08:01] <bialix> I'm not sure yet how to use this new feature
[08:01] <igc> bialix: I can't test it on pyqt 4.4
[08:01] <bialix> test on your own
[08:01] <bialix> it should work on any pyqt
[08:02] <igc> bialix: to test the feature, put in some random data and check BZR_CONFIG/explorer/tools.xml has a new entry
[08:02] <igc> i.e. .bazaar/epxlorer/tools.xml on ubuntu
[08:03] <bialix> it seems work for me
[08:03] <bialix> I'll push the fix
[08:04] <igc> bialix: works for me too
[08:04] <bialix> thx
[08:04] <igc> bialix: btw, after adding a tool, it should appear on your Tools menu and in your Toolbox
[08:04] <bialix> igc: can you prepare announce mail draft for me?
[08:05] <igc> bialix: sure do later tonight
[08:05] <igc> shall
[08:05] <bialix> igc: pushed
[08:06] <igc> bialix: thanks!
[08:06] <bialix> without your help this fix won't be so quick ;-)
[08:07] <bialix> igc: btw, fyi, I'm thinking about writing standalone app for explorer
[08:08] <bialix> maybe on xmas vacation
[08:08] <igc> to drop the dos box?
[08:08] <bialix> yep
[08:08] <igc> that would rock. dos box yells "non-professional" to me :-(
[08:08] <bialix> this black hole/console is annoying
[08:08] <bialix> yep
[08:09] <bialix> I just need to figure out where to redirect all this junk bzrlib tends to drop on stderr (and stdout sometimes)
[08:09] <bialix> e.g. when ssh connection established et al
[08:20] <vila> 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] <vila> like many ftp/sftp clients do for example
[08:20] <bialix> that's my intent, just need to convert it to code and see how it will work
[12:04] <LeoNerd> bzr-svn++ # I just  bzr merge svn+ssh://'ed and it JustWorked
[12:05] <LeoNerd> And bzr even knows its a merge in log10.. Hrm.. I wonder how that happens
[12:09] <bialix> magic
[12:13] <LeoNerd> Mmm... Well.. since I don't understand it, Clarke says it must be magic :)
[13:16] <Kamping_Kaiser> how does one debug a _slow_ bzr upload problem?
[13:23] <vila> Kamping_Kaiser: what is your remote server ?
[13:23] <vila> Kamping_Kaiser: ftp or sftp ?
[13:24] <vila> Kamping_Kaiser: by upload you mean the bzr-upload plugin or a regular bzr push ?
[13:24] <Kamping_Kaiser> vila: remote version? I don't know (i didn't set it up). using sftp.
[13:24] <Kamping_Kaiser> vila: and i was refering to bzr-push, its doing 1-2Kb/s
[13:24] <Kamping_Kaiser> s/-/ /
[13:25] <rubbs> good morning every one.
[13:25] <Kamping_Kaiser> 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] <vila> Hmm, that's highly unusal... unless you have a very high latency or are using a very old format
[13:25] <vila> hi rubbs
[13:26] <vila> what does bzr info <remote_url> says about the format and the branch/repo relationship ?
[13:28] <vila> Kamping_Kaiser: debian *stable*, what bzr version is that ?
[13:28] <Kamping_Kaiser> vila: shall i pastebin it?
[13:28] <vila> s.that.there.
[13:28] <vila> Kamping_Kaiser: sure
[13:28] <vila> !paste
[13:28] <Kamping_Kaiser> vila: currently using 2.0 from backports, i forget what stable ships by default
[13:29] <vila> ha, good, I had a horrible doubt about you using 1.12 or something :-)
[13:29] <Kamping_Kaiser> hehehe
[13:29] <Kamping_Kaiser> vila: http://pastebin.com/f717e494a
[13:29] <vila> no offense implied though, it's just that the problem would have been totally different
[13:30] <Kamping_Kaiser> i've had issues with debians default bzr before, so no offence taken.
[13:30] <vila> format: unnamed, bad juju
[13:31] <vila> either the repo or the branch may not have been upgraded
[13:31] <vila> try bzr info -v sftp://kgoetz@bzr.savannah.nongnu.org/srv/bzr/gnewsense/
[13:33] <Kamping_Kaiser> http://pastebin.com/f646ece25 this appears to know what it is
[13:33] <vila> good
[13:34] <vila> you may want to try an upgrade of the branch then
[13:34] <vila> it should be fast, really fast since you use a shared repo
[13:34] <Kamping_Kaiser> thelocal branch?
[13:34] <vila> the remote one
[13:35] <vila> 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] <Kamping_Kaiser> hm. I'll have to get someone to look at that.
[13:35] <Kamping_Kaiser> vila: thanks for your help :)
[13:36] <vila> Oh, and you want to check what format you use locally, cross-format conversions are still slow
[13:36] <vila> Kamping_Kaiser: you're welcome, feedback appreciated if you solve the problem !
[13:36] <vila> and more help available if you don't :)
[13:37] <Kamping_Kaiser> 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] <vila> Kamping_Kaiser: yes
[13:38] <vila> what does 'bzr info -v' says locally ?
[13:39] <Kamping_Kaiser> vila: beofre or after upgrade?
[13:39] <vila> now
[13:39] <Kamping_Kaiser> http://pastebin.com/f49fe8c18
[13:39] <vila> you mean you did upgrade in the last 2 minutes ?
[13:39]  * Kamping_Kaiser wonders how he lived before pastebinit
[13:39] <Kamping_Kaiser> yes
[13:40] <Kamping_Kaiser> hang on and i'll give you before upgrade too
[13:40] <vila> right, so you use a standalone branch not a 'checkout'
[13:40] <Kamping_Kaiser> http://pastebin.com/m9ba9455 pre upgrade
[13:41] <Kamping_Kaiser> yeah. my branch predates the move to shared repo
[13:41] <vila> right, try again, things should go better and faster
[13:41] <Kamping_Kaiser> woot.
[13:41] <vila> you may not even need to upgrade the remote branch, but I think it's worth checking what happened there
[13:41] <Kamping_Kaiser> 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] <vila> ok
[13:42] <Kamping_Kaiser> thanks again, I'll hunt you down if it works and thank you :D
[13:43] <vila> hehe, take care of your headache !
[14:46] <jam> igc: go enjoy your vacation :)
[14:46] <jam> morning vila, bialix, et al
[14:47] <bialix> heya jam!
[14:49] <vila> Goood morning jam
[14:50] <rubbs> morning jam
[14:53] <igc> thanks jam!
[14:53] <igc> jam: those fastimport patches look fine btw. Merge away ...
[14:54] <igc> night all. I'll offline now for a week plus.
[14:54] <jam> igc: have a great vacation
[14:54] <igc> shall do!
[14:54] <bialix> igc: you don't forget about me?
[14:55] <igc> bialix: I trust you to write a nice summary from the NEWS :-)
[14:55] <bialix> rats
[14:55] <bialix> so, enjoy!
[14:55] <igc> bialix: I didn't forget - just too sleepy sorry!
[14:56] <bialix> :-)
[14:56] <rubbs> igc: doing anything special for vacation?
[14:56] <jam> rubbs: not hanging around here :)
[14:56] <rubbs> jam: haha fair enough.
[15:40] <abentley> 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] <jam> 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] <jam> when you say "garbage" you mean data on stderr?
[15:43] <jam> my experience on this so far is single-cpu machines have issues cleaning up resources on secondary threads in a timely manner.
[15:43] <abentley> jam: No, I mean that it has an entry in gc.garbage, i.e. it's not garbage-collectable.
[15:43] <jam> ah
[15:44] <abentley> jam: It is collectable if I disable the __del__, but that defeats the purpose, of course.
[15:47] <jam> abentley: right, and _LockWarner is meant to hang of of an open lock and never be in a ref cycle
[15:47] <abentley> jam: And of course, they should be equivalent machines (dual-core x86-64/emt64)
[15:49] <jam> abentley: you could try something like this: http://paste.ubuntu.com/339283/
[15:49] <jam> and see if anything is assigning to LW that shouldn't be
[15:52] <abentley> jam: I've added the slots, but I don't understand the second part.
[15:53] <jam> 'understand the second part' ?
[15:53] <jam> The idea is if you have slots and someone assigns to _LockWarner.foo = bar
[15:53] <jam> it will fail
[15:53] <jam> rather than allowing a refcycle
[15:54] <jam> is it possible to inspect the LW class that is left in gc.garbage?
[15:54] <jam> or is it only reproducible on a machine you don't have direct access to?
[15:57] <abentley> jam: I see.  Well, it's not failing.
[15:58] <abentley> jam: It is possible to inspect the LW class in gc.garbage.  What should I look for?
[15:59] <jam> abentley: well, it is in gc.garbage because it is in a refcycle and has __del__ right?
[15:59] <jam> So you need to find the attribute that is causing the refcycle
[16:00] <jam> without __slots__ then doing "pp LW.__dict__" should give you an idea
[16:00] <jam> (with __slots__ there is no __dict__ attribute)
[16:03] <abentley> jam: pp lw.__dict__
[16:03] <abentley> {'lock_count': None,
[16:03] <abentley>  'repr': 'LockableFiles(<bzrlib.transport.chroot.ChrootTransport url=chroot-121047632:///~person-name9/product-name4/branch11/.bzr/repository/>)'}
[16:05] <abentley> jam: If there were live objects that referred to the LW, it wouldn't be in gc.garbage, right?
[16:13] <abentley> jam: gc seems to think that the LW doesn't refer to anything uncollectable: http://paste.ubuntu.com/339310/
[16:14] <abentley> 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] <jam> 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] <jam> unless maybe the class itself is referencing the object?
[16:20] <abentley> jam: yeah, me neither.
[16:20] <jam> can you check the references from bzrlib.lockdir._LockWarner ?
[16:20] <jam> or gc.get_referents(gc.get_referents(gc.garbage[0])[-1])
[16:20] <jam> (should be the same thing)
[16:21] <jam> and what does sys.getrefcount say?
[16:22] <jam> hmm... looking at http://docs.python.org/library/gc.html
[16:22] <jam> it looks like if gc thought it was once in a refcycle
[16:22] <abentley> jam: http://paste.ubuntu.com/339321/
[16:22] <jam> it would go into gc.garbage
[16:22] <jam> and never come out
[16:23] <jam> even after that cycle was fixed
[16:23] <abentley> jam: sys.getrefcount(gc.garbage[0]) returns 2
[16:23] <jam> http://docs.python.org/library/gc.html#gc.garbage specifically
[16:23] <jam> abentley: right, that means that gc.garbage is the only thing referring to this object now
[16:23] <jam> priority on *now*
[16:26] <abentley> jam: Okay, so if I follow the instructions and del gc.garbage[:], and then gc.collect, the list is empty.
[16:26] <jam> right
[16:26] <jam> from reading the docs, it sure looks like at some point LockWarner was referring to itself when gc.collect() ran
[16:27] <jam> oh, or it was part of some bigger cycle
[16:27] <jam> you know, it could have been in something like a comprehension
[16:27] <abentley> jam: I think this means that the test infrastructure is broken.  Do you agree?
[16:27] <jam> so, trying to read fully
[16:27] <jam> it sounds like if LW was in a refcycle with other code that didn't have __del__
[16:28] <jam> only *it* would get put into the garbage
[16:28] <jam> "By default, this list contains only objects with __del__() methods."
[16:28] <jam> the key is also this part:
[16:28] <jam> " including objects not necessarily in the cycle but reachable only from it."
[16:28] <jam> 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] <jam> which is a bit broken in python, if you ask me
[16:29] <jam> of course, you can't fix python for your test suite :)
[16:29] <jam> you might try running with: DEBUG_SAVEALL
[16:29] <jam> ?
[16:29] <abentley> 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] <jam> abentley: but it may have been uncollectable at some point, which then gets cleaned up by the time you investigate...
[16:32] <abentley> 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] <abentley> jam: I assume if it was actually uncollectable, it would get put back into gc.garbage?
[16:33] <jam> abentley: I'm willing to write a test to find out :)
[16:35] <jam> abentley: You seem to be correct, I'll paste
[16:38] <jam> abentley: http://paste.ubuntu.com/339330/
[16:39] <jam> so doing "del gc.garbage[:]; gc.collect()" does, indeed, seem to restore things that are still in cycles
[16:39] <abentley> jam: cool.
[16:41] <abentley> 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] <jam> abentley: well, disabling gc means that nothing will get put into gc.garbage as gc.collect is never running
[16:42] <abentley> jam: So it seems there's a cycle, but python fixes it.
[16:42] <jam> yeah
[16:42] <jam> it does seem a bit odd
[16:42] <abentley> jam: It means that there was a cycle after the test exited.
[16:42] <jam> if you go back to: http://docs.python.org/library/gc.html#gc.garbage
[16:43] <abentley> jam: at least, AFAICT.
[16:43] <jam> if DEBUG_SAVEALL is not set
[16:43] <jam> then it only puts the objects with __del__ into the garbage
[16:43] <jam> and goes ahead and deletes the rest
[16:43] <jam> which may be breaking the cycle somehow
[16:43] <jam> you might try running with
[16:43] <jam> gc.DEBUG_SAVEALL = True
[16:44] <jam> gc.collect()
[16:44] <jam> or something like that
[16:44] <jam> I should mention that pyrex/C objects get a _dealloc() function which doesn't block the garbage collector
[16:44] <jam> and can run actions at deconstruction
[16:45] <jam> so if LockWarner was in a cycle with an extension class, the extension class may break the cycle in its deconstructor
[16:48] <abentley> Actually, I believe DEBUG_SAVEALL is a flag you pass into gc.set_debug()
[16:55] <abentley> jam: Oh, this gets better and better: repr(gc.garbage)
[16:55] <abentley> *** UnicodeEncodeError: 'ascii' codec can't encode character u'\u02bb' in position 20: ordinal not in range(128)
[16:59] <jam> probably a case where an object is returning a Unicode from __str__
[16:59] <jam> which we've been guilty of in the past
[16:59] <jam> (and may still be guilty of...)
[16:59] <jam> well, tries, I think it forcibly casts the return  from __str__ to a str
[17:00] <abentley> jam: So with SAVEALL, there are 39 LockWarners in gc.garbage.
[17:09] <Calvin1602> Hi ! I'm experiencing a proxy problem with tortoiseBzr
[17:09] <jam> strange
[17:09] <Calvin1602> bzr: ERROR: Connection error: while sending OPTIONS /inkscape/: (10061, 'Connection refused')
[17:09] <jam> Calvin1602: how are you setting your proxy?
[17:09] <Calvin1602> ( the URL was https://launchpad.net/inkscape )
[17:10] <Calvin1602> Well, I don't, my question is how do I do it :)
[17:10] <jam> well, https://launchpad.net/inkscape isn't an actual branch
[17:10] <jam> bzr branch lp:inkscape would probably work better for you
[17:10] <Calvin1602> The user manual is very poor about that, especially for Windows
[17:10] <Calvin1602> nope
[17:10] <Calvin1602> tried it
[17:11] <Peng> jam: That should work as a branch, though. (There's a reference.)
[17:11] <Peng> I think.
[17:11] <jam> so, setting a proxy is generally setting "HTTP_PROXY" environment variable.
[17:11] <Peng> jam: Yeah.
[17:11] <Calvin1602> http ?
[17:11] <jam> Peng: I think the problem is some issues with bzr-svn trying to send OPTIONS and it getting caught in a auto-proxy
[17:11] <Calvin1602> not https ?
[17:11] <jam> but not sure
[17:11] <Peng> jam: Yeah, probably. I was just sayin'.
[17:11] <jam> Calvin1602: https:// is used by launchpad for serving lp pages, but not for bzr branches
[17:12] <jam> you could also try
[17:12] <jam> bzr branch http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/
[17:12] <jam> if you want to go directly to what everything will eventually redirect you to
[17:13] <Calvin1602> ok so I've set the HTTP_PROXY trough Windows+Pause, and ran bzr branch lp:inkscape
[17:13] <Calvin1602> guess what, bzr crashes
[17:14] <Calvin1602> want the stack on patebin ?
[17:15] <Calvin1602> http://pastebin.org/63578
[17:17] <Calvin1602> on the other hand, bzr branch http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/ gave a much nicer error :
[17:17] <Calvin1602> bzr: ERROR: Invalid url supplied to transport: "proxy.insa-rennes.fr:8080": No host component
[17:19] <Tak> does it work if you prepend "http://" to your proxy ?
[17:20] <Calvin1602> it does indeed, thanks :)
[17:20] <Calvin1602> Any idea why lp:inkscape makes it crash ?
[17:21] <Tak> no clue
[17:23] <jam> Calvin1602: we send an xmlrpc request to a different location
[17:23] <jam> what version of bzr?
[17:23] <jam> 2.0.2... probably doesn't have the xmlrpc supports proxies
[17:23] <jam> fix
[17:23] <Calvin1602> very last one, downloaded 1 hour ago
[17:24] <Calvin1602> 2.0.2, yeah
[17:24] <jam> yeah, looks like: bug #186920
[17:24] <jam> the bzr 2.1 series has a fix for it
[17:24] <jam> since 2.1.0b2
[17:25] <Calvin1602> Is there a windows installer for it ?
[17:25] <jam> yep
[17:25] <jam> Calvin1602: https://edge.launchpad.net/bzr/2.1/2.1.0b3
[17:26] <jam> or the direct link: http://edge.launchpad.net/bzr/2.1/2.1.0b3/+download/bzr-2.1.0b3-1-setup.exe
[17:26] <Calvin1602> Well, in fact, I can't use it right now. I'm not on my own computer, the network admin is away, so i'll have to live without it for the weekend
[17:27] <Calvin1602> So, hopefuly my last question : how do I convert a lp: adress to a https:// adress ?
[17:28] <Calvin1602> I have a project on launchpad. I'm told to use lp:~arnaud1602-gmail/sffs-sandbox/trunk , but as I said, I can't use it
[17:29] <Calvin1602> ( and, btw, I will need push privileges on it, so I guess https is needed instead of http ? )
[17:30] <Peng> Calvin1602: No, bzr+ssh (or sftp) is needed.
[17:30] <Peng> Calvin1602: Well, for pushing.
[17:31] <Peng> Calvin1602: Unless you're arnaud1602-gmail, you can't push to *that* branch, just your own branches (and those of teams you're in).
[17:31] <Calvin1602> I am arnaud1602
[17:31] <Calvin1602> and I want to push back tu launchpad
[17:32] <Calvin1602> to*
[17:32] <abentley> jam: Thanks for the help, but my brain is gonna explode.
[17:33] <jam> abentley: no problem, it would seem that just doing "gc.collect(); del gc.garbage[:]; gc.collect()" may be sufficient for what you need
[17:33] <jam> Calvin1602: you need an sshkey
[17:33] <jam> and then you can do "bzr lp-login arnaud1602-gmail"
[17:34] <jam> and it will connect via bzr+ssh instead of via http
[17:35] <abentley> jam: Yes, though the right place for that is the zope test runner, which is more work to patch.
[17:35] <jam> abentley: could you do the first part in tearDown ?
[17:35] <jam> (gc.collect(); del gc.garbage[:])
[17:35] <jam> It is a bit hackish
[17:35] <jam> but it may wokr
[17:35] <jam> work
[17:36] <abentley> jam: Yeah, I can do that as part of the cleanup, though it would reduce performance a bit.
[17:37] <abentley> jam: I'm still unclear whether there's a bug in python's garbage collector.
[17:41] <jam> not very clear here either
[17:41] <jam> and the randomness of it triggering is also unfortunate
[17:55] <cody-somerville> http://launchpadlibrarian.net/36654571/live-helper-trunk-log.txt <-- Can anyone help me with this import error?
[19:55] <NEBAP> hi
[19:55] <NEBAP> is there a document describing the current file format of bazaar?
[20:00] <phoenixz> With bzr st -S, what is the difference between +N and + ?
[20:03] <phoenixz> Because it seems that sometimes when I bzr add, the file has status + and sometimes the file has status +N but I can't find what the difference is
[20:05] <NEBAP> is there any document which tells me how a bazaar repository should be read?
[20:06] <NEBAP> i just wanted to add native read support for bazaar in non python code ..
[20:07] <NEBAP> but I couldn't find any documents about the file format
[20:07] <Peng> NEBAP: That's, uh, not simple...
[20:07] <NEBAP> :(
[20:08] <Peng> phoenixz: I think that stuff is documented in bzr.dev now.
[20:08] <NEBAP> I already talked to a developer (sorry couldn't remember the name) and he pointed me to the sources
[20:08] <NEBAP> but reading the sources for someone that isn't into the project is ... really hard ;)
[20:08] <phoenixz> Peng: bzr.dev?
[20:09] <Peng> phoenixz: lp:bzr
[20:09] <phoenixz> Peng: sorry, what?
[20:09] <Peng> phoenixz: "the trunk". "The development version". Whatever.
[20:09] <NEBAP> Peng: the problem is that there is no bazaar support for shared hosts (web interface)..
[20:09] <phoenixz> Right..
[20:10] <Peng> NEBAP: You *can* run Loggerhead with FastCGI, etc. Probably.
[20:10] <Peng> NEBAP: Not that your average shared host has the rAM for it....
[20:11] <NEBAP> Peng: so I need a solution for shared hosts, and I think many others would also appreciate a working solution
[20:11] <Peng> phoenixz: Hmm, I was wrong. I take back what I said.
[20:11] <Peng> phoenixz: I don't know the answer, sorry. :\
[20:12] <phoenixz> Peng: well, honestly, I didnt get the answer anyway...
[20:13] <NEBAP> what kind of documentation is used by the developers? Are they just using the source??
[20:26] <NEBAP> I know the file format is very tricky, but I thought it should be possible to just read from it ...
[20:37] <CaptTofu> hi, does anyone know why bzr/lp is broken like this: http://pastie.org/739518
[20:37] <CaptTofu> I upgraded bzr to 2.0.2, and still no go
[20:38] <beuno> CaptTofu, looks like a bug
[20:38] <beuno> could you please file it?
[20:45] <dOxxx> NEBAP: you  may get a better response if you ask on the bzr mailing list
[20:46] <dOxxx> NEBAP: or ask a question here: https://answers.launchpad.net/bzr/+addquestion
[20:46] <NEBAP> dOxxx: thanks, I posted a question on launchpad: https://answers.launchpad.net/bzr/+question/93740 (hope my english is ok ..)
[20:48] <Tak> NEBAP: it's great
[20:49] <NEBAP> Ta: what? the english??? you making fun of me ^^
[20:49] <rubbs> NEBAP: I had no problem understanding your question. Unfortunately, I don't know the answer to it :(
[20:51] <NEBAP> rubbs: no problem ;)
[20:51] <NEBAP> thanks
[20:51] <NEBAP> hopefully there is such a document ;)
[20:52] <NEBAP> making bazaar repositories be accessible on shared hosts would be great ;)
[20:52] <Tak> NEBAP: your english was very good, and I'm not making fun of you
[20:53] <NEBAP> Tak: thanks :)
[20:57] <NEBAP> good night, I'm leaving for today ;)
[21:37] <eric_f> Is it possible to have multiple branches in the same working dir? I would like to have trunk, feature1, and feature2 branches in my one working dir and be able to switch between them. You can do this with Git, I was curious if you can with Bzr?
[21:39] <rubbs> eric_f: I'm not 100% sure, but I believe bzr switch can do what you want
[21:40] <rubbs> eric_f: 'bzr help switch' it gives a discription. see if that's what you're talking about
[21:40] <eric_f> I guess I should rephrase, I want to have multiple local branches that are NOT published to a central server. I would like it if these branches and their data all existed in my working dir
[21:41] <eric_f> …I can publish to the central server if it's not possible, or a seperate-from-my-working-dir folder to hold all my local feature-branches
[21:42] <zsquareplusc> eric_f: it's typical to have a separate directory for each branch. but you can make a shared repo so that the history does not need to be multiple times on your disk
[21:44] <dOxxx> eric_f: something like this? http://doc.bazaar.canonical.com/developers/colocated-branches.html
[21:44] <eric_f> in Git you don't need a separate dir for each branch
[21:44] <rubbs> eric_f: not trying to say it can't be done (yet) but is there any reason to keep it all in the same working tree?
[21:44] <dOxxx> eric_f: the answer is that it's being contemplated but not currently possible
[21:45] <dOxxx> eric_f: the clsoes you can get is to create a shared repository with tree-less branches and a single working directory that is a lightweight checkout of a branch, and then you use 'bzr switch' on the checkout to switch between branches
[21:45] <dOxxx> closest*
[21:45] <eric_f> dOxxx: that looks like it
[21:45] <eric_f> dOxxx: yeah, I guess that makes sense to do for now
[21:46] <eric_f> rubbs: because I want to do all my bzr commands in one place
[21:46] <rubbs> eric_f: cool, np. I was just curious
[21:46] <dOxxx> eric_f: if co-located branches become possible in the future, I'm quite certain that you'll be able to migrate your stuff to it
[21:46] <eric_f> rubbs: I don't want to have to commit in my working dir, which commits to my local branch, which then I have to cd into and push up to the server
[22:00] <rubbs> xnox: I don't believe it can show a ascii DAG. I may be wrong, but I don't think it can. (unless it's some hidden feature I didn't know about).
[22:00] <rubbs> xnox: just check some help files, and I'm pretty sure that it can't give you an ASCII DAG. sorry.
[22:59] <Pilky> anyone around interested in seeing/giving feedback on some mockups I've done for improvements to launchpad?