=== frakturfreak_ is now known as frakturfreak [07:29] hi all ! [08:02] hi vila! [08:02] poolie: hey ! [08:03] 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] hm, there's a 'make apidocs' that should work [08:04] i can't recall if it uses epydoc or something else [08:04] last time i ran it, it seemed to work [08:06] yeah, api-docs, I used that [08:07] I don't think I will go further with it though, better invest into sphinx [08:08] 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] not sure it's worth publishing anyway [08:08] I should file a bug instead :) [08:50] 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] no. [08:51] but that's generally a knock-on error from the tests in bt.test_selftest not being written very robustly [08:51] the real problem will be something else. [08:51] 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] mgz: by the way, do you feel strongly about a more robust isolation for doctests ? I'm unclear about your concerns there [08:52] there are some other failures in that log that I've had before and filed bugs on. [08:53] basically, python2.7 isn't clean yet [08:53] python itself or testtools workarounds ? Or bzr on python2.7 itself ? [09:00] bzr on python 2.7 [09:02] 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:02] Launchpad bug 654731 in Bazaar "Using tuned_gzip.GzipFile.readline corrupts data on Python 2.7" [Medium,Confirmed] https://launchpad.net/bugs/654731 [09:02] Launchpad bug 614595 in Bazaar "unpack_highres_date doctest fails on Python 2.7" [Low,Confirmed] https://launchpad.net/bugs/614595 [09:03] getting a 2.7 babune instance again would be good if that's a natty expectation [09:03] (sorry went off to get drink, hence delay) [09:04] 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] once it's stable enough, I'll add it to babune [09:04] cool. [09:05] and I will propably remove the jaunty one at the same time since it has EOD for a couple of months now [09:05] if the daily builds failures are an issue I can work through the remaining 2.7 failures I get locally. [09:06] mgz: it *is* an issue, how important is subjective but getting rid of it would be highly appreciated :) [09:07] right, so the bugs you filed are probably why I felt a deja-vu effect [09:07] the bad thing is that I thought they were fiXed not fiLed :) Damn Alzheimer [09:07] I squished most of them before you moved your instance back to 2.6 [09:08] you mean you have fixes for them but no submission ? [09:09] 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] jelmer: hi and FYI ^ [09:12] https://bugs.launchpad.net/bzr/+bugs?field.tag=python2.7&field.status%3Alist=CONFIRMED&field.status%3Alist=FIXRELEASED [09:12] wow, re-reading 654731... yeah scary... but so huge it makes me wonder if we really it it in production code [09:13] yeah, I think we don't. [09:13] a couple of test won't hurt to make it clearer then [09:13] but that makes me not want to touch it at all. [09:13] hmm, nice summary [09:14] mgz: right, I understand the feeling, but on the other hand it's kind of a FUD issue :) [09:14] launchpad really needs a way of saying "any status" without that daft field.status%3Alist= every-single-status thing. [09:14] which is a bit silly [09:14] mgz: there are related features in the pipe if I understand correctly what jml said on his blog [09:16] can't we close bug #635583 for bzr ? [09:16] Bug 635583 on http://launchpad.net/bugs/635583 is private [09:16] can't we close bug #625583 for bzr ? [09:16] Launchpad bug 625583 in Bazaar "Strange details item reprs on skipped tests in babune" [Low,Confirmed] https://launchpad.net/bugs/625583 [09:16] pfff [09:16] on his blog? or some other one? I don't recall seeing it on his. [09:16] let me check [09:16] vila: if you've upgraded to testtools 0.9.7 or later, yes. [09:17] but not having a 2.7 slave means I've not actually noticed if it's fixed or not yet. [09:17] ok [09:17] I should start filing bugs for babune (make slaves configuration easier to consult) [09:18] and do another audit to ensure I can re-start publishing the code [09:20] but may be it's a stupied idea to try auditing my own setup... [09:21] personal glue code is always a bit odd. [09:22] my testing stuff is all carefully licenced and available over http, but I've never bothered telling anyone about it. [09:22] 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] the slaves use some ssh keys, but those are clearly versioned somewhere else (and properly gpg-encoded before that anyway) [09:24] so that leaves only the babune accounts potentially (this is where I have doubts) exposed, or so I wish :) [09:24] but well, this is kind of relying on security through obscurity so I may just pusblish and monitor who is connecting when [09:25] 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] s/to even/so even/ [09:27] shudder, natty broken again after an update :-/ [09:28] ha, may be not, one more reboot needed [09:28] heh. [09:29] could be vbox related... [09:30] 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] right, runs ok after reboot and guest additions update [09:44] ah yeah, I remember. the failing tests you asked about earlier were ones I broke, it's basically covered bug bug 637674 [09:44] Launchpad bug 637674 in Bazaar "RemotedTestCase.addCleanup exists but fails under Python 2.7" [Low,Confirmed] https://launchpad.net/bugs/637674 [09:45] 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] and those three bugs look like they cover all the failures in that log. [09:46] wow, I would need to dig to understand here, I can't do that right now :-/ [09:47] But I could probably review if needed [09:49] mgz: http://code.mumak.net/2010/11/and-then-what.html is what I had in mind [09:49] there was a more precise one about the bug queries but may be it was from some lp dev, not sure [09:51] 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] mgz: yeah, that was my question above [09:51] thanks for the link, I did see that post. [09:52] 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] 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] 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] 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] yeah, that's very bad [09:56] 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] pfew, mail backlog was heavier than usual, back to the drawing board now [10:17] vila: sorry, missed that earlier [10:17] vila: g'morning! [10:17] jelmer: np, g'morning :D [11:33] 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] vila: checking [11:44] vila: nope, I don't see it [11:44] :-( [11:50] darn, who knows since when I've been talking do /dev/null without even realizing... [11:54] OMG, found the root cause :( [11:55] vila: Talking to /dev/null is better than being ignored by the rest of the world ;-) [11:56] 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] oh my... yet another one where I was surprised to see no answers.. [11:58] argh ! The 2.2.2 announce did not make it ! Nobody reacted :( [12:00] bah, no wonder gary never replied to my emails... [12:01] the fact that I do a lot through lp didn't help... [12:17] 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] maxb: The only guidelines are to use a merge to land the changes, and properly describe what changes you're landing. [12:19] maxb: We don't have a tradition of mentioning reviewers, but it does seem like a reasonable thing to do. [12:20] Hmm, well, it's just a single trivial revision, so if I don't mention the reviewer, I might as well just push :-) === Vorpal_ is now known as Vorpal [12:48] * maxb sobs a bit at discovering how iffy bzr-fastimport's marks handling is [12:53] 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] jelmer: sorry about that, there were 74 mails that didn't went through... [13:06] np :-) === AfC1 is now known as AfC [13:34] 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] knighthawk: or even branch vs checkout :) [13:43] 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] vila - thanks. I may have been trying to make bzr fit into my svn knowledge and so far its not working ;-) [13:45] knighthawk: no problem, I'll help if I can [13:46] once we are on the same page for the words to use, things will be eaiser [13:46] easier than not making tyops at least... === zyga is now known as zyga-coffee [13:52] thanks vila - okay reading the into now. === shanx_ is now known as ichigo [13:58] * jelmer lunches === Ursinha is now known as Ursinha-lunch === Ursinha-lunch is now known as Ursinha === zyga is now known as zyga-afk [16:03] 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] dlee: this rings no bell, worth filing as a bug [16:05] dlee: I would tend to suspect join too [16:05] 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] ouch [16:06] 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] dlee: you know about the test-script command right ? [16:07] 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] no [16:07] dlee: hmm, new in 2.3bn I think [16:08] Using 2.2.0 release here. [16:08] 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] sure, which OS ? [16:09] Mostly Windows. Also tried Cygwin port for the join blocker issues today. [16:09] 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] dlee: hmm, I have no idea about who is maintaining the cygwin port [16:10] 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] grr, and we lag a bit for the windows installers :-/ [16:12] 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] 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. === beuno is now known as beuno-lunch [16:46] Trivial test does show join dropping tags on the floor :( [16:46] the source ones not the target ones I hope ? [16:47] Well, source. I didn't try target, but that would be REALLY egregious. And probably take intention. [16:47] :) [16:47] 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] 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] ha ok, so you won't start using it before 2.3 is out right ? === zyga-afk is now known as zyga [16:50] Well, I run .dev on my workstation. But just releases everywhere else. [16:50] ok, anyway if you do some tests, I'll be all ears [16:51] 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] I'll toss together a repro script and bug for that join thing in a bit. [16:53] cool [16:54] Well, not as cool as not having to 'cuz there's no bug in the first place :p [16:57] I know :-/ [16:58] this one is probably there since day one === deryck is now known as deryck[lunch] === Ursinha is now known as Ursinha-brb === beuno-lunch is now known as beuno === mtaylor is now known as mtaylor|afk [18:02] 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 . [18:03] tgall_foo: WAG - zero length file? [18:04] tgall_foo: are you using XFS? [18:04] jelmer: nope ... am on an arm box tho [18:04] jelmer: ext3 FWIW [18:06] 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] branches fine on my maverick box [18:07] tgall_foo: you're getting that over the network ? [18:07] yes [18:09] http://bazaar.launchpad.net/~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering/.bzr/repository/indices/ [18:09] no inde d3b.. [18:09] no *index* d3b [18:09] tgall_foo: whats the exact command giving the error ? [18:10] bzr dump-btree http://bazaar.launchpad.net/~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering/.bzr/repository/pack-names [18:11] lifeless, bzr branch lp:~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering [18:11] shows no expected index d3b... [18:11] tgall_foo: ok, and what directory are you doing that in? === deryck[lunch] is now known as deryck [18:11] it's just a dir in my home ... ~/bzr/live-helper.configs [18:11] ok [18:12] can you run 'bzr info' in that dir [18:12] sure [18:12] paste the location: section [18:13] shared repository: . [18:14] ok [18:14] so its the local repository [18:14] ls -lrt .bzr/repository/indices [18:15] it's a fairly long list so I'll avoid flooding the channel ... [18:15] http://pastebin.ubuntu.com/546665/ [18:16] -rw-r--r-- 1 tgall tgall 222 Nov 24 15:57 d3b70ec01f6fbb6c152129e151757a28.rix [18:16] is the culprit, but indeed, its not zero-length [18:17] bzr dump-btree .bzr/repository/indices/d3b70ec01f6fbb6c152129e151757a28.rix [18:17] bzr: ERROR: d3b70ec01f6fbb6c152129e151757a28.rix is not an index of type . [18:18] head .bzr/repository/indices/d3b70ec01f6fbb6c152129e151757a28.rix [18:18] 122664 | 284 [18:18] procmail | procmail | quilt (Build-Depend) | Ubuntu Developers |t [18:19] thats very much not what a bzr index looks like :) [18:19] interesting [18:19] something has gone very wrong on your file system [18:19] that is a very scary prospect... thanks lifeless [18:19] possibly thats prior content and the file wasn't flushed to disk before a reboot/kernel crash [18:20] 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] have a look at d3b70ec01f6fbb6c152129e151757a28.iix while you are there [18:21] its the same length [18:21] 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] very similar for the iix file : | 545026 | 1200 [18:22] python-central | python-central | debconf (Build-Depend) | Ubuntu Core Developers [18:22] I humbly suggest an fsck [18:22] I think you're right on that [18:24] 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] maxb: Dulwich and bzr-fastimport are the main other users that I'm aware of at the moment. [18:26] right [18:39] maxb: Which bits specifically are you referring to? [18:40] just discovered an actual use case for bzr gcommit! [18:40] hi Marius [18:40] mgedmin: per-file commits? [18:40] yep [18:40] hi, jelmer [18:41] shame it stops me cold with "working tree out of date, please run bzr update" [18:41] 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] okay, I'm a bit exaggerating here [18:41] instead of (1) I did a commit in a different terminal window [18:42] gcommit helped me keep track of which files I wanted to commit [18:42] 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] mgedmin: it would be appropriate and I agree it'd be nice to do, but it's also nontrivial [18:49] so not very likely at this point [18:50] * mgedmin would take that on as a challenge, if /me had more time ... [19:09] jelmer: why nontrivial? [19:09] jelmer: we have merge -i after all ... [19:25] jelmer: reftracker and idmapfile - I've filed a bug === Ursinha-brb is now known as Ursinha [20:04] So, when a pull happens, it transfers the entire history, right? [20:05] Every time you pull? [20:07] only the bits you don't have [20:15] lifeless: hunk selection in diffs, using a GTK widget is nontrivial imho [20:15] lifeless: I'd love to be proven wrong :-) [20:22] 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] Pull is for updating one branch to match another. Update is for updating a working tree to match its branch. [21:04] the lines do blur a bit with checkouts === JFo is now known as JFo-vacation === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [23:48] Morning folks.