[07:29] <vila> hi all !
[08:02] <poolie> hi vila!
[08:02] <vila> poolie: hey !
[08:03] <vila> poolie: what can you tell me about our epydoc support ? I tried playing a bit with it yesterday but even with a gross hack for the lazy imports I wasn't really happy with th result (still some ~600 markup errors)
[08:04] <poolie> hm, there's a 'make apidocs' that should work
[08:04] <poolie> i can't recall if it uses epydoc or something else
[08:04] <poolie> last time i ran it, it seemed to work
[08:06] <vila> yeah, api-docs, I used that
[08:07] <vila> I don't think I will go further with it though, better invest into sphinx
[08:08] <vila> but epydoc as involved internally and the trick mwhudson used for the previous versions is now obsolete (my hack reuse it though but applied at a different place)
[08:08] <vila> not sure it's worth publishing anyway
[08:08] <vila> I should file a bug instead :)
[08:50] <vila> mgz: did you receive the mails about the failing daily builds ? https://launchpad.net/~bzr/+archive/daily/+build/2107611/+files/buildlog_ubuntu-natty-i386.bzr_2.3.0%7Ebeta4%2Bbzr5579%7Eppa3877%2B3874%7Enatty1_FAILEDTOBUILD.txt.gz mentions AttributeError: 'InstrumentedTestResult' object has no attribute 'report_error',
[08:50] <mgz> no.
[08:51] <mgz> but that's generally a knock-on error from the tests in bt.test_selftest not being written very robustly
[08:51] <mgz> the real problem will be something else.
[08:51] <vila> mgz: I'm pretty sure this is a genuine bug in the bzr implementation that is triggered only for some weird combo of python/testtools versions
[08:51]  * vila nods
[08:52] <vila> mgz: by the way, do you feel strongly about a more robust isolation for doctests ? I'm unclear about your concerns there
[08:52] <mgz> there are some other failures in that log that I've had before and filed bugs on.
[08:53] <mgz> basically, python2.7 isn't clean yet
[08:53] <vila> python itself or testtools workarounds ? Or bzr on python2.7 itself ?
[09:00] <mgz> bzr on python 2.7
[09:02] <mgz> I see the failures from bug 654731 and bug 614595 in that log, and I think I rememeber breaking those test_selftest tests, but may not have filed anything for them
[09:03] <mgz> getting a 2.7 babune instance again would be good if that's a natty expectation
[09:03] <mgz> (sorry went off to get drink, hence delay)
[09:04] <vila> mgz: I'm monitoring a natty slave for stability (far too often I need to boot from a rescue CD to unlock a broken upgrade)
[09:04] <vila> once it's stable enough, I'll add it to babune
[09:04] <mgz> cool.
[09:05] <vila> and I will propably remove the jaunty one at the same time since it has EOD for a couple of months now
[09:05] <mgz> if the daily builds failures are an issue I can work through the remaining 2.7 failures I get locally.
[09:06] <vila> mgz: it *is* an issue, how important is subjective but getting rid of it would be highly appreciated :)
[09:07] <vila> right, so the bugs you filed are probably why I felt a deja-vu effect
[09:07] <vila> the bad thing is that I thought they were fiXed not fiLed :) Damn Alzheimer
[09:07] <mgz> I squished most of them before you moved your instance back to 2.6
[09:08] <vila> you mean you have fixes for them but no submission ?
[09:09] <mgz> those two linked up there are interestingly opposite ends of why-I-didn't-fix, the doctest issue is too trivial to care about, and the gzip one is scary.
[09:11] <vila> jelmer: hi and FYI ^
[09:12] <mgz> https://bugs.launchpad.net/bzr/+bugs?field.tag=python2.7&field.status%3Alist=CONFIRMED&field.status%3Alist=FIXRELEASED
[09:12] <vila> wow, re-reading 654731... yeah scary... but so huge it makes me wonder if we really it it in production code
[09:13] <mgz> yeah, I think we don't.
[09:13] <vila> a couple of test won't hurt to make it clearer then
[09:13] <mgz> but that makes me not want to touch it at all.
[09:13] <vila> hmm, nice summary
[09:14] <vila> mgz: right, I understand the feeling, but on the other hand it's kind of a FUD issue :)
[09:14] <mgz> launchpad really needs a way of saying "any status" without that daft field.status%3Alist= every-single-status thing.
[09:14] <vila> which is a bit silly
[09:14] <vila> mgz: there are related features in the pipe if I understand correctly what jml said on his blog
[09:16] <vila> can't we close bug #635583 for bzr ?
[09:16] <vila> can't we close bug #625583 for bzr ?
[09:16] <vila> pfff
[09:16] <mgz> on his blog? or some other one? I don't recall seeing it on his.
[09:16] <vila> let me check
[09:16] <mgz> vila: if you've upgraded to testtools 0.9.7 or later, yes.
[09:17] <mgz> but not having a 2.7 slave means I've not actually noticed if it's fixed or not yet.
[09:17] <vila> ok
[09:17] <vila> I should start filing bugs for babune (make slaves configuration easier to consult)
[09:18] <vila> and do another audit to ensure I can re-start publishing the code
[09:20] <vila> but may be it's a stupied idea to try auditing my own  setup...
[09:21] <mgz> personal glue code is always a bit odd.
[09:22] <mgz> my testing stuff is all carefully licenced and available over http, but I've never bothered telling anyone about it.
[09:22] <vila> My main problem is with security issues, I tried to ensure that user and passwords weren't versioned in the babune project but hudson doesn't make it clear whether I succeeded or not
[09:22] <vila> the slaves use some ssh keys, but those are clearly versioned somewhere else (and properly gpg-encoded before that anyway)
[09:24] <vila> so that leaves only the babune accounts potentially (this is where I have doubts) exposed, or so I wish :)
[09:24] <vila> but well, this is kind of relying on security through obscurity so I may just pusblish and monitor who is connecting when
[09:25] <vila> I've made the hudson instance run under a specific account anyway to even getting access there won't buy an attacker anything interesting...
[09:25] <vila> s/to even/so even/
[09:27] <vila> shudder, natty broken again after an update :-/
[09:28] <vila> ha, may be not, one more reboot needed
[09:28] <mgz> heh.
[09:29] <vila> could be vbox related...
[09:30] <vila> the main issue these days is that 3D is not supported so Unity is out of the game, I shouldn't really care not keep insisting about using GUI on the slaves, but, well, it has been easier so far
[09:30] <vila> right, runs ok after reboot and guest additions update
[09:44] <mgz> ah yeah, I remember. the failing tests you asked about earlier were ones I broke, it's basically covered bug bug 637674
[09:45] <mgz> was being clever making the thread leak stuff work with test case instances not derived from the bzrlib TestCase, but that breaks things
[09:46] <mgz> and those three bugs look like they cover all the failures in that log.
[09:46] <vila> wow, I would need to dig to understand here, I can't do that right now :-/
[09:47] <vila> But I could probably review if needed
[09:49] <vila> mgz: http://code.mumak.net/2010/11/and-then-what.html is what I had in mind
[09:49] <vila> there was a more precise one about the bug queries but may be it was from some lp dev, not sure
[09:51] <mgz> speaking of reviewing and understanding, I need to respond on the lp:~vila/bzr/321320-isolate-doc-tests mp as I feel we crossed wires a little.
[09:51] <vila> mgz: yeah, that was my question above
[09:51] <mgz> thanks for the link, I did see that post.
[09:52] <vila> I can't find this other post I'm mentioning but from memory there will be ways to define queries, save and share them
[09:53] <mgz> launchpad is generally pretty good at urls that don't suck, bug search interface in general is a bit of a low point though.
[09:53] <vila> some will be pre-defined and easily accessed from bug pages but you'll get full control for subscription for example (the two subjects are related so maybe I'm mixing things up)
[09:54] <mgz> I'm often doing a four or five page fetch thing trying to just look for some existing bug that may or may not already be fixed on trunk
[09:55] <vila> yeah, that's very bad
[09:56] <vila> searching is sub-optimal, you often give me more precise answers than what I get when searching myself a bit outside of the ones I know
[09:59] <vila> pfew, mail backlog was heavier than usual, back to the drawing board now
[10:17] <jelmer> vila: sorry, missed that earlier
[10:17] <jelmer> vila: g'morning!
[10:17] <vila> jelmer: np, g'morning :D
[11:33] <vila> jelmer: I'm experimenting weird mail issues (some of my mail are lost), did you get the one I wrote in the 'Ready in bzr/proposed: testtools 0.9.8, fixtures 0.3.5' thread ? (To which you just replied, the thread not my email)
[11:39] <jelmer> vila: checking
[11:44] <jelmer> vila: nope, I don't see it
[11:44] <vila> :-(
[11:50] <vila> darn, who knows since when I've been talking do /dev/null without even realizing...
[11:54] <vila> OMG, found the root cause :(
[11:55] <jelmer> vila: Talking to /dev/null is better than being ignored by the rest of the world ;-)
[11:56] <vila> hehe, I was vaguely suspecting the later (but not strongly enough to investigate ;) but I wasn't talking to /dev/null either, I have a bunch of mail reports in a mailbox now so I know which ones were not sent
[11:57] <vila> oh my... yet another one where I was surprised to see no answers..
[11:58] <vila> argh ! The 2.2.2 announce did not make it ! Nobody reacted :(
[12:00] <vila> bah, no wonder gary never replied to my emails...
[12:01] <vila> the fact that I do a lot through lp didn't help...
[12:17] <maxb> Are there any guidelines for landing approved reviews to non-PQM-managed bzr projects owned by ~bzr?
[12:18]  * maxb has an approved MP for bzr-fastimport... do I just merge and push, with an [r=person] commit message?
[12:19] <jelmer> maxb: The only guidelines are to use a merge to land the changes, and properly describe what changes you're landing.
[12:19] <jelmer> maxb: We don't have a tradition of mentioning reviewers, but it does seem like a reasonable thing to do.
[12:20] <maxb> Hmm, well, it's just a single trivial revision, so if I don't mention the reviewer, I might as well just push :-)
[12:48]  * maxb sobs a bit at discovering how iffy bzr-fastimport's marks handling is
[12:53] <jelmer> maxb: you mean the fact that it hardcodes marks where any kind of revision identifier is possible?
[13:05]  * jelmer gets bombarded with mail from vila
[13:06] <vila> jelmer: sorry about that, there were 74 mails that didn't went through...
[13:06] <jelmer> np :-)
[13:34] <knighthawk> I'm a bit confused about how to use bazaar as a central repos. I think its working trees vs non working trees that is tripping me up or perhaps commit vs push
[13:43] <vila> knighthawk: or even branch vs checkout :)
[13:43] <vila> knighthawk: so, start by reading http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief so we give the same meaning to tree, branch and repo
[13:45] <knighthawk> vila - thanks. I may have been trying to make bzr fit into my svn knowledge and so far its not working ;-)
[13:45] <vila> knighthawk: no problem, I'll help if I can
[13:46] <vila> once we are on the same page for the words to use, things will be eaiser
[13:46] <vila> easier than not making tyops at least...
[13:52] <knighthawk> thanks vila - okay reading the into now.
[13:58]  * jelmer lunches
[16:03] <dlee> Is it a bug, or known, that tags get lost on either bzr join or bzr upgrade from 0.92 to 2a?  (One or the other, not both; I assume join.)
[16:04] <vila> dlee: this rings no bell, worth filing as a bug
[16:05] <vila> dlee: I would tend to suspect join too
[16:05] <dlee> I'll need to find time to create a script to reproduce this... I have three bugs I need to do that for by now.  The others have to do with errors that block bzr join.
[16:06] <vila> ouch
[16:06] <dlee> I suspect bzr upgrade might create a root ID that is the same across multiple upgraded projects... wild guess, but what I see is that trying to join more than one tree into a common one fails on second and any subsequent trees.
[16:06] <vila> dlee: you know about the test-script command right ?
[16:07] <dlee> My apologies for the sparse info; these keep hitting me amid my job when I can't stop long enough to do a good repro. :P
[16:07] <dlee> no
[16:07] <vila> dlee: hmm, new in 2.3bn I think
[16:08] <dlee> Using 2.2.0 release here.
[16:08] <dlee> I upgrade sort of infrequently because I am responsible for upgrades for my whole office, and I like keeping versions in sync when possible.
[16:09] <vila> sure, which OS ?
[16:09] <dlee> Mostly Windows.  Also tried Cygwin port for the join blocker issues today.
[16:09] <dlee> Oh the Cygwin one is 2.1.2; I use that rarely and am the only one who uses it at all here.
[16:10] <vila> dlee: hmm, I have no idea about who is maintaining the cygwin port
[16:10] <dlee> vila: Holidays approach, and I try to tackle off-the-road projects during that time, when not playing card games or eating turkey etc. :)  So maybe I'll have a better chance at this soon.
[16:10] <vila> grr, and we lag a bit for the windows installers :-/
[16:12] <vila> dlee: so anyway, once you get a change to upgrade to 2.3, there is a test-script command that is targeted at bug reports, making it easier to write reproducing recipes
[16:13] <dlee> I'm good at shell scripts but I'll keep that in mind, gotta go now, someone is trying to work with me here. :)  Thanks for the info though.
[16:46] <fullermd> Trivial test does show join dropping tags on the floor   :(
[16:46] <vila> the source ones not the target ones I hope ?
[16:47] <fullermd> Well, source.  I didn't try target, but that would be REALLY egregious.  And probably take intention.
[16:47] <vila> :)
[16:47] <vila> by the way, I landed your smooth upgrades proposal, there is more work needed there so file bugs if you encounter problems or rough edges
[16:48] <fullermd> I did see that a couple days ago; thanks.  Now post-2.3 maybe I can move our last projects off 1.9 formats   :)
[16:49] <vila> ha ok, so you won't start using it before 2.3 is out right ?
[16:50] <fullermd> Well, I run .dev on my workstation.  But just releases everywhere else.
[16:50] <vila> ok, anyway if you do some tests, I'll be all ears
[16:51] <fullermd> Yeah, I'll probably fiddle with it.  But probably not in any situations I didn't before, so I doubt I'd turn up anything new.
[16:51] <fullermd> I'll toss together a repro script and bug for that join thing in a bit.
[16:53] <vila> cool
[16:54] <fullermd> Well, not as cool as not having to 'cuz there's no bug in the first place   :p
[16:57] <vila> I know :-/
[16:58] <vila> this one is probably there since day one
[18:02] <tgall_foo> on natty, doing a fresh bzr branch, has anyone seen an error of this form ? bzr: ERROR: d3b70ec01f6fbb6c152129e151757a28.rix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[18:03] <lifeless> tgall_foo: WAG - zero length file?
[18:04] <jelmer> tgall_foo: are you using XFS?
[18:04] <tgall_foo> jelmer: nope ...   am on an arm box tho
[18:04] <tgall_foo> jelmer: ext3 FWIW
[18:06] <tgall_foo> lifeless, I don't believe there are any zero length files involved ...     the repo in question is lp:~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering
[18:07] <tgall_foo> branches fine on my maverick box
[18:07] <lifeless> tgall_foo: you're getting that over the network ?
[18:07] <tgall_foo> yes
[18:09] <lifeless> http://bazaar.launchpad.net/~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering/.bzr/repository/indices/
[18:09] <lifeless> no inde d3b..
[18:09] <lifeless> no *index* d3b
[18:09] <lifeless> tgall_foo: whats the exact command giving the error ?
[18:10] <lifeless> bzr dump-btree http://bazaar.launchpad.net/~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering/.bzr/repository/pack-names
[18:11] <tgall_foo> lifeless,   bzr branch lp:~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering
[18:11] <lifeless> shows no expected index d3b...
[18:11] <lifeless> tgall_foo: ok, and what directory are you doing that in?
[18:11] <tgall_foo> it's just a dir in my home ...  ~/bzr/live-helper.configs
[18:11] <lifeless> ok
[18:12] <lifeless> can you run 'bzr info' in that dir
[18:12] <tgall_foo> sure
[18:12] <lifeless> paste the location: section
[18:13] <tgall_foo>   shared repository: .
[18:14] <lifeless> ok
[18:14] <lifeless> so its the local repository
[18:14] <lifeless> ls -lrt .bzr/repository/indices
[18:15] <tgall_foo> it's a fairly long list so I'll avoid flooding the channel ...
[18:15] <tgall_foo> http://pastebin.ubuntu.com/546665/
[18:16] <lifeless> -rw-r--r-- 1 tgall tgall  222 Nov 24 15:57 d3b70ec01f6fbb6c152129e151757a28.rix
[18:16] <lifeless> is the culprit, but indeed, its not zero-length
[18:17] <lifeless> bzr dump-btree .bzr/repository/indices/d3b70ec01f6fbb6c152129e151757a28.rix
[18:17] <tgall_foo> bzr: ERROR: d3b70ec01f6fbb6c152129e151757a28.rix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[18:18] <lifeless> head .bzr/repository/indices/d3b70ec01f6fbb6c152129e151757a28.rix
[18:18] <tgall_foo>     122664 |             284
[18:18] <tgall_foo> procmail                          | procmail                        | quilt (Build-Depend)                         | Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>                  |t
[18:19] <lifeless> thats very much not what a bzr index looks like :)
[18:19] <tgall_foo> interesting
[18:19] <lifeless> something has gone very wrong on your file system
[18:19] <tgall_foo> that is a very scary prospect... thanks lifeless
[18:19] <lifeless> possibly thats prior content and the file wasn't flushed to disk before a reboot/kernel crash
[18:20] <lifeless> possibly thats new content scribbled over the original file (note that the file dates from nov 24th, so if you've been branching in this repo in the ~month, and it was working... then it was originally written correctly)
[18:20] <lifeless> have a look at d3b70ec01f6fbb6c152129e151757a28.iix while you are there
[18:21] <lifeless> its the same length
[18:21] <tgall_foo> well at this point everything that was here has been pushed up to lp ... so there really isn't any loss blowing it away
[18:22] <tgall_foo> very similar for the iix file :  |          545026 |            1200
[18:22] <tgall_foo> python-central                    | python-central                  | debconf (Build-Depend)                       | Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[18:22] <lifeless> I humbly suggest an fsck
[18:22] <tgall_foo> I think you're right on that
[18:24] <maxb> jelmer: Do you happen to know if the list of projects using python-fastimport at https://launchpad.net/python-fastimport is reasonably complete? I wish to argue that some bits of python-fastimport are prematurely factored out implementation details of bzr-fastimport - checking whether they are in fact used elsewhere would be useful
[18:25] <jelmer> maxb: Dulwich and bzr-fastimport are the main other users that I'm aware of at the moment.
[18:26] <maxb> right
[18:39] <jelmer> maxb: Which bits specifically are you referring to?
[18:40] <mgedmin> just discovered an actual use case for bzr gcommit!
[18:40] <jelmer> hi Marius
[18:40] <jelmer> mgedmin: per-file commits?
[18:40] <mgedmin> yep
[18:40] <mgedmin> hi, jelmer
[18:41] <mgedmin> shame it stops me cold with "working tree out of date, please run bzr update"
[18:41] <mgedmin> and then has no 'reload' button, so I have to (1) write down the files names I've checked on a piece of paper, (2) close gcommit window, (3) restart gcommit
[18:41] <mgedmin> okay, I'm a bit exaggerating here
[18:41] <mgedmin> instead of (1) I did a commit in a different terminal window
[18:42] <mgedmin> gcommit helped me keep track of which files I wanted to commit
[18:42] <mgedmin> so thanks for that
[18:42]  * mgedmin guesses it is probably not appropriate to go and ask for a per-hunk commit selection pretty please with sugar on top?
[18:49] <jelmer> mgedmin: it would be appropriate and I agree it'd be nice to do, but it's also nontrivial
[18:49] <jelmer> so not very likely at this point
[18:50]  * mgedmin would take that on as a challenge, if /me had more time ...
[19:09] <lifeless> jelmer: why nontrivial?
[19:09] <lifeless> jelmer: we have merge -i after all ...
[19:25] <maxb> jelmer: reftracker and idmapfile - I've filed a bug
[20:04] <sqwishy> So, when a pull happens, it transfers the entire history, right?
[20:05] <sqwishy> Every time you pull?
[20:07] <lifeless> only the bits you don't have
[20:15] <jelmer> lifeless: hunk selection in diffs, using a GTK widget is nontrivial imho
[20:15] <jelmer> lifeless: I'd love to be proven wrong :-)
[20:22] <sqwishy> So how does a pull differ from and update? Assuming you already have a pull or a checkout a revision or two old.
[20:42] <fullermd> Pull is for updating one branch to match another.  Update is for updating a working tree to match its branch.
[21:04] <maxb> the lines do blur a bit with checkouts
[23:48] <spiv> Morning folks.