=== frakturfreak_ is now known as frakturfreak | ||
vila | hi all ! | 07:29 |
---|---|---|
poolie | hi vila! | 08:02 |
vila | poolie: hey ! | 08:02 |
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:03 |
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:04 |
vila | yeah, api-docs, I used that | 08:06 |
vila | I don't think I will go further with it though, better invest into sphinx | 08:07 |
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:08 |
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:50 |
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:51 | |
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:52 |
mgz | basically, python2.7 isn't clean yet | 08:53 |
vila | python itself or testtools workarounds ? Or bzr on python2.7 itself ? | 08:53 |
mgz | bzr on python 2.7 | 09:00 |
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:02 |
ubot5 | 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 |
ubot5 | Launchpad bug 614595 in Bazaar "unpack_highres_date doctest fails on Python 2.7" [Low,Confirmed] https://launchpad.net/bugs/614595 | 09:02 |
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:03 |
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:04 |
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:05 |
vila | mgz: it *is* an issue, how important is subjective but getting rid of it would be highly appreciated :) | 09:06 |
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:07 |
vila | you mean you have fixes for them but no submission ? | 09:08 |
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:09 |
vila | jelmer: hi and FYI ^ | 09:11 |
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:12 |
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:13 |
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:14 |
vila | can't we close bug #635583 for bzr ? | 09:16 |
ubot5 | Bug 635583 on http://launchpad.net/bugs/635583 is private | 09:16 |
vila | can't we close bug #625583 for bzr ? | 09:16 |
ubot5 | Launchpad bug 625583 in Bazaar "Strange details item reprs on skipped tests in babune" [Low,Confirmed] https://launchpad.net/bugs/625583 | 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:16 |
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:17 |
vila | and do another audit to ensure I can re-start publishing the code | 09:18 |
vila | but may be it's a stupied idea to try auditing my own setup... | 09:20 |
mgz | personal glue code is always a bit odd. | 09:21 |
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:22 |
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:24 |
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:25 |
vila | shudder, natty broken again after an update :-/ | 09:27 |
vila | ha, may be not, one more reboot needed | 09:28 |
mgz | heh. | 09:28 |
vila | could be vbox related... | 09:29 |
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:30 |
mgz | ah yeah, I remember. the failing tests you asked about earlier were ones I broke, it's basically covered bug bug 637674 | 09:44 |
ubot5 | Launchpad bug 637674 in Bazaar "RemotedTestCase.addCleanup exists but fails under Python 2.7" [Low,Confirmed] https://launchpad.net/bugs/637674 | 09:44 |
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:45 |
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:46 |
vila | But I could probably review if needed | 09:47 |
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:49 |
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:51 |
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:52 |
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:53 |
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:54 |
vila | yeah, that's very bad | 09:55 |
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:56 |
vila | pfew, mail backlog was heavier than usual, back to the drawing board now | 09:59 |
jelmer | vila: sorry, missed that earlier | 10:17 |
jelmer | vila: g'morning! | 10:17 |
vila | jelmer: np, g'morning :D | 10:17 |
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:33 |
jelmer | vila: checking | 11:39 |
jelmer | vila: nope, I don't see it | 11:44 |
vila | :-( | 11:44 |
vila | darn, who knows since when I've been talking do /dev/null without even realizing... | 11:50 |
vila | OMG, found the root cause :( | 11:54 |
jelmer | vila: Talking to /dev/null is better than being ignored by the rest of the world ;-) | 11:55 |
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:56 |
vila | oh my... yet another one where I was surprised to see no answers.. | 11:57 |
vila | argh ! The 2.2.2 announce did not make it ! Nobody reacted :( | 11:58 |
vila | bah, no wonder gary never replied to my emails... | 12:00 |
vila | the fact that I do a lot through lp didn't help... | 12:01 |
maxb | Are there any guidelines for landing approved reviews to non-PQM-managed bzr projects owned by ~bzr? | 12:17 |
* maxb has an approved MP for bzr-fastimport... do I just merge and push, with an [r=person] commit message? | 12:18 | |
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:19 |
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:20 |
=== Vorpal_ is now known as Vorpal | ||
* maxb sobs a bit at discovering how iffy bzr-fastimport's marks handling is | 12:48 | |
jelmer | maxb: you mean the fact that it hardcodes marks where any kind of revision identifier is possible? | 12:53 |
* jelmer gets bombarded with mail from vila | 13:05 | |
vila | jelmer: sorry about that, there were 74 mails that didn't went through... | 13:06 |
jelmer | np :-) | 13:06 |
=== AfC1 is now known as AfC | ||
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:34 |
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:43 |
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:45 |
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:46 |
=== zyga is now known as zyga-coffee | ||
knighthawk | thanks vila - okay reading the into now. | 13:52 |
=== shanx_ is now known as ichigo | ||
* jelmer lunches | 13:58 | |
=== Ursinha is now known as Ursinha-lunch | ||
=== Ursinha-lunch is now known as Ursinha | ||
=== zyga is now known as zyga-afk | ||
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:03 |
vila | dlee: this rings no bell, worth filing as a bug | 16:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:12 |
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:13 |
=== beuno is now known as beuno-lunch | ||
fullermd | Trivial test does show join dropping tags on the floor :( | 16:46 |
vila | the source ones not the target ones I hope ? | 16:46 |
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:47 |
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:48 |
vila | ha ok, so you won't start using it before 2.3 is out right ? | 16:49 |
=== zyga-afk is now known as zyga | ||
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:50 |
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:51 |
vila | cool | 16:53 |
fullermd | Well, not as cool as not having to 'cuz there's no bug in the first place :p | 16:54 |
vila | I know :-/ | 16:57 |
vila | this one is probably there since day one | 16:58 |
=== 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 | ||
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:02 |
lifeless | tgall_foo: WAG - zero length file? | 18:03 |
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:04 |
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:06 |
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:07 |
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:09 |
lifeless | bzr dump-btree http://bazaar.launchpad.net/~tom-gall/linaro/live-helper.config.natty.linaro-graphical-engineering/.bzr/repository/pack-names | 18:10 |
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 |
=== deryck[lunch] is now known as deryck | ||
tgall_foo | it's just a dir in my home ... ~/bzr/live-helper.configs | 18:11 |
lifeless | ok | 18:11 |
lifeless | can you run 'bzr info' in that dir | 18:12 |
tgall_foo | sure | 18:12 |
lifeless | paste the location: section | 18:12 |
tgall_foo | shared repository: . | 18:13 |
lifeless | ok | 18:14 |
lifeless | so its the local repository | 18:14 |
lifeless | ls -lrt .bzr/repository/indices | 18:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:24 |
jelmer | maxb: Dulwich and bzr-fastimport are the main other users that I'm aware of at the moment. | 18:25 |
maxb | right | 18:26 |
jelmer | maxb: Which bits specifically are you referring to? | 18:39 |
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:40 |
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:41 |
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:42 | |
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:49 |
* mgedmin would take that on as a challenge, if /me had more time ... | 18:50 | |
lifeless | jelmer: why nontrivial? | 19:09 |
lifeless | jelmer: we have merge -i after all ... | 19:09 |
maxb | jelmer: reftracker and idmapfile - I've filed a bug | 19:25 |
=== Ursinha-brb is now known as Ursinha | ||
sqwishy | So, when a pull happens, it transfers the entire history, right? | 20:04 |
sqwishy | Every time you pull? | 20:05 |
lifeless | only the bits you don't have | 20:07 |
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:15 |
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:22 |
fullermd | Pull is for updating one branch to match another. Update is for updating a working tree to match its branch. | 20:42 |
maxb | the lines do blur a bit with checkouts | 21:04 |
=== JFo is now known as JFo-vacation | ||
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
spiv | Morning folks. | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!