| === yofel_ is now known as yofel | ||
| AfC | What does | 01:38 |
|---|---|---|
| AfC | AttributeError: 'Tree' object has no attribute 'encoding' | 01:38 |
| AfC | mean? | 01:38 |
| AfC | (doing bzr branch on a git repo) | 01:40 |
| spiv | Sounds like some code is expecting one kind of object but encountering another | 01:40 |
| spiv | Which could be due to a plugin needing to be updated to work with your version of bzrlib, or something like that. | 01:41 |
| AfC | spiv: It's the Bazaar PPA, on a Lucid box & `apt-get install bzr-git` | 01:42 |
| AfC | spiv: and, I suspect you're right, seeing as how this works on my Natty laptop. | 01:42 |
| poolie | afc, spiv, hi | 01:43 |
| AfC | (or at least, has worked for the use cases I have tried with small Git trees) | 01:43 |
| * AfC bows to poolie | 01:43 | |
| poolie | ! | 01:43 |
| AfC | (don't get too excited now) | 01:43 |
| poolie | please file a bug, with the traceback, against bzr-git, and post the number? | 01:43 |
| AfC | [there's also a problem where bzr-git refuses to branch from a github https URL, but that's for another day] | 01:44 |
| AfC | poolie: do you just want the dump to stderr, or the full commend run from .bzr.log? | 01:45 |
| spiv | When in doubt, scream and shout^W^W^W er, I mean, give more information rather than less ;) | 01:46 |
| AfC | poolie, spiv: as requested https://bugs.launchpad.net/bzr/+bug/861973 | 01:52 |
| ubot5 | Ubuntu bug 861973 in Bazaar "bzr crashes when trying to branch a Git repo, with "AttributeError: 'Tree' object has no attribute 'encoding'"" [Undecided,New] | 01:52 |
| poolie | thanks | 01:52 |
| AfC | I hope it's just a dependency problem; this has really messed me up. | 01:53 |
| poolie | it was working recently? | 01:54 |
| AfC | poolie: as I noted in the bug and above, this workflow does work on my Natty system. | 01:54 |
| AfC | [not, admittedly, with the large repo in question, but with other projects' locally cloned git repos] | 01:55 |
| poolie | huh | 01:56 |
| poolie | i can see how it would happen | 01:56 |
| poolie | i think | 01:56 |
| poolie | it got the hash of a tree when it expected a commit | 01:56 |
| AfC | poolie: I can try and duplicate this on my laptop, but I'll need to get to a fatter pipe first. | 01:57 |
| poolie | it might help if you can either attach or describe how to get the git branch that causes trouble | 02:02 |
| AfC | poolie: that doesn't sound like a missing dependency, then | 02:02 |
| AfC | poolie: oh, that's easy | 02:02 |
| poolie | no i don' think it is | 02:02 |
| poolie | it sounds like there is something in the structure of the repo it can't deal with | 02:03 |
| poolie | normally an attributeerror is a version mismatch but i think not in this case | 02:03 |
| AfC | poolie: git clone https://github.com/torvalds/linux.git linux | 02:03 |
| AfC | poolie: bzr branch linux upstream | 02:03 |
| * AfC just remembered he hadn't fetched the tags. I'll try that now | 02:04 | |
| AfC | same crash | 02:05 |
| AfC | Like I said, on this Natty system, admittedly against smaller projects, I have git cloned then bzr branched many times. | 02:06 |
| AfC | {shrug} | 02:06 |
| AfC | Upgrading this server to Natty isn't really an option, y'know? :) | 02:06 |
| poolie | well | 02:06 |
| poolie | if you're using the ppa there should be no need to upgrade to natty | 02:06 |
| AfC | poolie: (fwiw, this isn't makework; I really do need an import of the kernel tree) | 02:07 |
| AfC | poolie: that's what I would have thought, yes | 02:07 |
| poolie | i'll see if i can reproduce it on tip, at leaste | 02:07 |
| poolie | you could usefully try bzr-git from https://launchpad.net/~bzr/+archive/daily?field.series_filter=lucid | 02:08 |
| AfC | poolie: just bzr-git or change the whole PPA? | 02:08 |
| AfC | [you guys have been pretty ruthless over the years about warning people off the dailies] | 02:09 |
| poolie | hm | 02:09 |
| poolie | how i would describe the dailies is: | 02:09 |
| poolie | - don't be surprised if there are intermittent version incompatibilities, because they are just snapshots and they have had no time to settle against each other | 02:09 |
| AfC | [the "what? plugins don't work together? gee, too bad, that's what releases are for"] | 02:10 |
| poolie | - there is a somewhat higher chance of bugs | 02:10 |
| poolie | but not much | 02:10 |
| poolie | i think that's the main warning | 02:10 |
| AfC | right, well in this case we're talking about plugins, which is why I prevaricate | 02:10 |
| AfC | anyway, will try as requested | 02:10 |
| AfC | is that ppa:bzr/daily then? | 02:11 |
| poolie | yes | 02:11 |
| poolie | the answer to the version incompatibilty thing is basically to just be prepared to downgrade to the betas | 02:11 |
| poolie | iwnbni launchpad kept a little bit of history of ppa packages so that you could downgrade to an older daily | 02:12 |
| poolie | but, not yet | 02:12 |
| AfC | so, back to my original question, should I just grab the bzr-git .deb and dulwhich .deb from there? | 02:12 |
| AfC | or upgrade bzr as well | 02:12 |
| AfC | [whichever, I'm asking for your help so I will do either one as you request for diagnostics purposes] | 02:13 |
| poolie | probably everything | 02:13 |
| AfC | ok | 02:13 |
| poolie | obviously you know there may be some fallout, but also that you can downgrade again | 02:14 |
| AfC | kaboom :( | 02:15 |
| AfC | same error | 02:15 |
| AfC | well, I'm up against the bleeding edge incase you [can] fix something; otoh, if it's a missing dep then we can try that quicky too, in both scenarios | 02:16 |
| poolie | ok, that's useful to know at least | 02:16 |
| * AfC swears quietly | 02:16 | |
| AfC | poolie: oh, | 02:17 |
| poolie | ? | 02:18 |
| AfC | [oh, I just discovered I wasn't logging here[ | 02:18 |
| AfC | Jelmer discovered that the packaging branches of linux were missing | 02:19 |
| AfC | fyi | 02:19 |
| AfC | (they would have been useful, and, indeed, import-tar was my next fallback, but if your imports are breaking then I have a bad feeling mine won't work either) | 02:19 |
| AfC | here we are, | 02:20 |
| AfC | poolie: https://code.launchpad.net/ubuntu/+source/linux and http://package-import.ubuntu.com/status/linux.html#2011-04-22 01:24:13.263528 | 02:20 |
| AfC | hm | 02:20 |
| AfC | second is <http://package-import.ubuntu.com/status/linux.html#2011-04-22%2001:24:13.263528> | 02:21 |
| AfC | that | 02:21 |
| poolie | hm that looks like a different probelm | 02:21 |
| poolie | one possibly fixed by retrying it | 02:21 |
| AfC | poolie: ok, (but, meanwhile, there are no packaging branches for Linux there; is that expected?) | 02:21 |
| poolie | oh there is a bug https://bugs.launchpad.net/udd/+bug/792193 | 02:22 |
| ubot5 | Ubuntu bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Low,Confirmed] | 02:22 |
| poolie | well, it's known | 02:22 |
| AfC | Hardy? | 02:22 |
| AfC | hm. I was trying to find Maverick's packaging branches. Anyway. | 02:22 |
| poolie | so | 02:23 |
| poolie | i'm still waiting for that to download | 02:23 |
| poolie | if you run 'BZR_PDB=1 bzr branch ...' | 02:23 |
| poolie | and then you should get a debugger prompt; please type 'p locals()' | 02:23 |
| AfC | ok | 02:23 |
| AfC | poolie: : | 02:25 |
| AfC | {'rev': <Revision id git-v1:c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'self': <bzrlib.plugins.git.mapping.BzrGitMappingv1 object at 0x1699450>, 'commit': <Tree c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'decode_using_encoding': <function decode_using_encoding at 0x33167d0>, 'lookup_parent_revid': <bound method type.revision_id_foreign_to_bzr of <class 'bzrlib.plugins.git.mapping.BzrGitMappingv1'>>} | 02:25 |
| poolie | ok that's useful | 02:25 |
| AfC | gesundheit | 02:25 |
| poolie | and try 'up' 'p locals()' again | 02:26 |
| AfC | ok | 02:26 |
| AfC | > /usr/lib/python2.6/dist-packages/bzrlib/plugins/git/repository.py(332)lookup_foreign_revision_id() | 02:26 |
| AfC | -> mapping.revision_id_foreign_to_bzr) | 02:26 |
| AfC | {'foreign_revid': '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c', 'commit': <Tree c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'self': LocalGitRepository('file:///home/andrew/torvalds/linux/'), 'mapping': <bzrlib.plugins.git.mapping.BzrGitMappingv1 object at 0x1699450>} | 02:26 |
| AfC | [linux clone from github took 15m01s so you should be able to dup all this hopefully soon] | 02:28 |
| AfC | Always disappointing to read in a bug "Low priority because no one is ever going to use this so we don't really ever need to fix it" :( | 02:29 |
| poolie | which one? | 02:29 |
| AfC | https://bugs.launchpad.net/udd/+bug/792193/comments/17 | 02:29 |
| ubot5 | Ubuntu bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Low,Confirmed] | 02:29 |
| AfC | (the one you found 5 minutes ago) | 02:29 |
| AfC | My actual objective is to get a 2.6.35 kernel into bzr; Maverick shipped a 2.6.35 so that's what I was aiming at packaging wise. And meanwhile at Oneiric https://code.launchpad.net/ubuntu/+source/linux is still empty. | 02:31 |
| poolie | that would be nice | 02:32 |
| poolie | ok so i can reproduce the crash | 02:32 |
| poolie | which is a good start | 02:32 |
| AfC | great! | 02:32 |
| AfC | poolie: you on Lucid or Natty? | 02:32 |
| poolie | pah, oneiric | 02:32 |
| AfC | ok | 02:32 |
| poolie | :) | 02:32 |
| AfC | that means its not a Lucid problem, as such, but more likely a Bazaar problem, yeah? | 02:32 |
| poolie | i'm 80% sure it's a quirk in the linux.git history that bzr-git is not coping with | 02:33 |
| AfC | yeah | 02:33 |
| poolie | such as perhaps a tag pointing directly to a tree, not to a commit | 02:33 |
| AfC | that wouldn't surprise me | 02:33 |
| AfC | Not withstanding the whole "no one will ever use this vibe", (and as I said this isn't makework), it might be worth tracking down if for no other reason that we all know the Linux tree is kinda the canonical reference case for the "Git being better than Bazaar" bullshit | 02:34 |
| AfC | poolie: I have to relocate ... be back on in ~an hour. Ok if I ping you then? [or, I should just watch that bug?] | 02:40 |
| poolie | just watch it | 02:41 |
| poolie | jelmer can probably solve it much faster than me but i'll have a go | 02:41 |
| AfC | sweet | 02:43 |
| AfC | you guys rockl | 02:43 |
| poolie | :) thanks i hope we can get it unstuck | 02:45 |
| poolie | it may be fairly shallow | 02:45 |
| AfC | Hope s | 02:47 |
| AfC | o. I realize it may take a bit more than trivial engineering if it is some relation that Git allows that Bazaar doesn't yet model. | 02:47 |
| poolie | afc, it was indeed a quirky tag; deleting it lets the import proceed | 05:04 |
| poolie | i'm going to see if jelmer agrees with my approach | 05:04 |
| AfC | poolie: huh. Is that a condition you can anticipate (or, rather, when you hit that glitch in the future you can just programmatically skip past it?) | 05:10 |
| poolie | yep | 05:12 |
| poolie | i just want to know what j thinks about just how we will skip past it | 05:12 |
| poolie | i put a workaround on the bug | 05:12 |
| vila | hi all ! | 06:25 |
| jelmer | hi vila | 06:38 |
| jelmer | AfC: hi | 06:38 |
| vila | jelmer: hey ! | 06:38 |
| AfC | jelmer: yo | 06:39 |
| AfC | jelmer: Hit a funny bug in an unavoidably prominent tree I was trying to parse with bzr-git | 06:40 |
| jelmer | AfC: I'm just reading the bug report now | 06:41 |
| AfC | jelmer: if you need | want to reproduce, I can give you the git URL | 06:42 |
| AfC | jelmer: (also, bzr-git choking when given a github https URL, *is* fixed by the daily PPA, nicely done) | 06:44 |
| jelmer | AfC: thanks | 06:47 |
| jelmer | AfC: let me see if I can reproduce it manually first though\ | 06:47 |
| AfC | → city | 06:49 |
| vila | today's hang is on gentoo :-/ | 06:50 |
| jam | morning all | 06:59 |
| ccxCZ | good morning | 07:00 |
| ccxCZ | vila: what's the issue with gentoo? | 07:00 |
| vila | ccxCZ: there is hang in the test suite spuriously affecting various babune slaves, it's the gentoo one today, it was natty and maverick yesterday, I don't think it's specific to gentoo | 07:01 |
| jam | vila: I haven't been able to reproduce locally, is it possible to give me access so I can try it on the slaves themselves? | 07:02 |
| ccxCZ | I see. Anyway if you need some gentoo magic feel free to poke me. | 07:03 |
| jam | and have you tried running older versions to make sure that it is a change in *bzr* and not something else causing the problems? | 07:03 |
| vila | jam: you already have access via babune | 07:03 |
| jam | vila: except you never restored my account there | 07:03 |
| vila | the important bit above is "via babune* | 07:03 |
| jam | vila: I mean having me manually run "bzr selftest" | 07:03 |
| vila | you never had access to slaves | 07:03 |
| jam | vila: babune is not giving us enough insight into what is failing | 07:04 |
| jam | I was hoping to directly run selftest so that I could see a failing test, etc. | 07:04 |
| vila | jam: and you probably won't be able to reproduce outside of babune | 07:04 |
| poolie | hi jam, vila | 07:06 |
| jam | hi poolie | 07:06 |
| jam | vila: I thought you said that the schroots were failing, but the vms were not, did I misunderstand? | 07:06 |
| jam | Is it just purely random? | 07:06 |
| vila | it is random | 07:07 |
| vila | I saw one case where for the same revision the chroot hung but the vm passed | 07:07 |
| jam | vila: I saw this: http://paste.ubuntu.com/698934/ | 07:08 |
| jam | in the failing babune run of gentoo | 07:08 |
| poolie | vila, thanks for spotting that bug in my update patch | 07:08 |
| poolie | it now works from a subdir | 07:08 |
| jam | I wonder if -Werror is causing a thread to die | 07:08 |
| jam | because of a Warning from gzip | 07:08 |
| poolie | do you want to rereview it or should i just send it? | 07:08 |
| jam | causing something to hang. | 07:08 |
| jam | (note, that is the only line in the raw console output that looks at all different from the rest.) | 07:09 |
| jam | vila: and *that* would certainly be random, if it requires a gzip stream to somehow create a value that wasn't signed/unsigned etc. | 07:09 |
| jam | that one, in particular, looks to be line 21 of gzip.py, part of "write32u" | 07:10 |
| jam | and has the comment: # The L format writes the bit pattern correctly whether signed | 07:10 |
| jam | # or unsigned. | 07:10 |
| vila | poolie: you're welcome :) | 07:12 |
| vila | poolie: oh, please go ahead | 07:12 |
| vila | jam: may be, but it there has been no hang on gentoo for .... months, so pretty unlikely | 07:13 |
| vila | s/it// | 07:13 |
| vila | and the gentoo job currently running (and hung) is already a re-try, so could also be a different test split that is revealing another issue | 07:14 |
| jelmer | 'morning jam, poolie | 07:14 |
| poolie | hi jelmer, can you help me with bug 816973? | 07:18 |
| ubot5 | Error: Launchpad bug 816973 could not be found | 07:18 |
| JackWinter | i want to checkout the source from a prj on sourceforge using bazaar. the url i'm given is: bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth (read only), tried bzr init, and then bzr banch/checkout, but it tells me that bzr: ERROR: Not a branch: "bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth/". | 07:28 |
| jelmer | poolie: looking now | 07:29 |
| jam | vila: well, I do see the gzip warning, I'll go check if it exists in a non hanging run | 07:29 |
| jam | interestingly, the passing test has the hanging message on a line by itself, while the failing one has it intermixed | 07:31 |
| jam | I don't know if that is significant or not, I'm trying to diff the raw logs now | 07:32 |
| poolie | jelmer, https://bugs.launchpad.net/bzr-git/+bug/861973 | 07:32 |
| jam | not very helpful, as the --parallel means the ordering is ~locally random | 07:32 |
| ubot5 | Ubuntu bug 861973 in Bazaar Git Plugin "bzr crashes when trying to branch a Git repo, with "AttributeError: 'Tree' object has no attribute 'encoding'"" [High,In progress] | 07:32 |
| vila | ccxCZ: since you asked :) There is a weird failure documented in #830545 | 07:32 |
| jam | bug #830545 | 07:33 |
| ubot5 | Launchpad bug 830545 in bzr-buildbot-net "Update for Gentoo testing routines" [High,In progress] https://launchpad.net/bugs/830545 | 07:33 |
| vila | jam: thanks :) | 07:33 |
| jam | vila: something pretty weird. The failing test seems to be missing every 6th test or so. | 07:35 |
| jam | vila: across the test suite. Would one of the subprocesses have hung/died early, causing all of its partition of the tests to get discarded? | 07:35 |
| vila | jam: BZR_CONCURRENCY=6 on gentoo's slave | 07:36 |
| jam | I'm not particularly familiar with how --parallel=? is splitting stuff out | 07:36 |
| vila | possibly | 07:36 |
| lifeless | jam: round robin split for bzr, equal-time-buckets for testr | 07:36 |
| vila | jam: the last change here is spiv spreading the tests across the subprocess instead of giving a slice of the whole | 07:36 |
| lifeless | (with round robin for unknown time tests) | 07:36 |
| jam | vila: http://imagebin.org/176688 | 07:37 |
| lifeless | vila: oh? I'm out of date then :) | 07:37 |
| jam | vila: that is after 'sort' ing the output | 07:37 |
| jam | of the raw log | 07:37 |
| jam | that is gentoo run 520 vs 522 | 07:38 |
| vila | lifeless: no, not at all | 07:38 |
| vila | lifeless: but testr is not used there | 07:38 |
| JackWinter | oops out of swap :( but figured it out. had to use bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth/d2x-rebirth | 07:38 |
| vila | jam: yup, sounds like more evidence there is a hang in one subprocess while the others work normally | 07:39 |
| vila | the '----' line is weird though | 07:40 |
| jam | vila: that is Vim | 07:40 |
| jam | it is just saying "no content on left" | 07:40 |
| vila | oh, not from selftest then, ok | 07:40 |
| vila | jam: note that the 1/6 may be just caused by a test taking longer | 07:42 |
| vila | but of course a hung test takes forever | 07:42 |
| ccxCZ | vila: you mean the pyc stuff? is there a log for that somewhere> | 07:44 |
| jam | vila: how so? I sorted all tests, and then did th ediff | 07:45 |
| jam | so those tests are *not in the output* | 07:45 |
| jam | I went back and then searched the sorted log for the first tests that are missing | 07:45 |
| jam | http://paste.ubuntu.com/698951/ | 07:45 |
| vila | haaa | 07:45 |
| vila | well, just saying. You didn't explain your pastebin so I guessed (wrongly ;) | 07:46 |
| vila | what is this one about ? | 07:46 |
| jam | vila: so, first, I grabbed the raw console output from a success and a fail | 07:47 |
| vila | jam: ohh, re-reading the log you mentioned it ws sorted, I missed that | 07:47 |
| jam | then I sorted them, and did a diff | 07:47 |
| jam | finding ones that are in success | 07:47 |
| jam | then I iterated success in its original order | 07:47 |
| jam | and found ones that were marked missing in the hung test | 07:47 |
| jam | tests | 07:47 |
| jam | those are the first 10 | 07:47 |
| vila | so the hanging one should be before ? | 07:47 |
| ccxCZ | found the log, not sure what make of it though, never had issues with .pyc not loading | 07:47 |
| jam | vila: arguably, the first one should be the hung one, right? | 07:47 |
| jam | vila: ah, wait a sec | 07:48 |
| vila | hmm, the first or the preceeding one... you may be right... | 07:48 |
| jam | +bzrlib.tests.test_bundle.V4BundleTester.test_non_bundle ... /usr/lib/python2.6/gzip.py:21: DeprecationWarning: struct integer overflow masking is deprecated | 07:48 |
| jam | is the only interesting line in hung that isn't in success, except that is just because of the warning | 07:48 |
| vila | ccxCZ: ha, you neither, damn | 07:48 |
| jam | there is an "ok" still in the output for it. | 07:48 |
| jam | I'm guessing that is just noise. | 07:49 |
| vila | jam: I'm pretty sure the ok is output after the cleanups, mgz ? | 07:49 |
| jam | vila: the other thing that is missing in the output is the Cython lines | 07:49 |
| vila | whic cython lines ? WHile compiling the extensions ? | 07:49 |
| jam | vila: The 'diff' was just confused because the 'ok' ended up on a different line. | 07:49 |
| vila | jam: I'm confused as well about what fallouts this implies :) | 07:50 |
| ccxCZ | vila: you sure this is gentoo specific? do you have other slaves with same version of python? | 07:50 |
| jam | vila: this is the complete list of sorted-but-missing lines: http://paste.ubuntu.com/698953/ | 07:50 |
| jam | if you go to the end | 07:50 |
| jam | there are Cython lines | 07:50 |
| jam | Now, Cython only ~recently started writing "skipping XXX (up-to-date)" | 07:50 |
| jam | but something about hung isn't showing those lines. | 07:51 |
| vila | ccxCZ: which python version is that ? (I'm pretty sure we cover the whole range but I can't remember the specific one used on gentoo) | 07:51 |
| ccxCZ | and the first error seems to be related to pyc loading rather not loading | 07:51 |
| ccxCZ | vila: depends | 07:51 |
| vila | :) | 07:51 |
| vila | ok, let me check | 07:51 |
| jam | vila: ah, they show up at the end of the success log | 07:51 |
| jam | maybe because it is to stderr? | 07:51 |
| ccxCZ | it's rolling release, y'know :-) | 07:51 |
| vila | ccxCZ: yeah, I wsa hoping you spotted it when looking | 07:52 |
| jam | vila: all the way at the *end* of http://babune.ladeuil.net:24842/job/selftest-gentoo/520/consoleText | 07:52 |
| jam | It says "python setup.py build_ext -i" | 07:52 |
| jam | shouldn't that be happening before the test run? | 07:52 |
| vila | jam: depends :-} | 07:52 |
| ccxCZ | 2.6 something | 07:52 |
| vila | but extensions are re-compiled only when needed relying on make | 07:52 |
| jam | vila: sure, but compiling them after running the test suite seems odd | 07:53 |
| vila | ccxCZ: covered then, at least by lucid and maverick | 07:53 |
| jam | is it just a Jenkins-ism that it puts stderr after stdout ? | 07:53 |
| vila | jam: no, no | 07:53 |
| ccxCZ | you might want to consider having testing gentoo slave along stable one btw, quite a few people use that | 07:54 |
| vila | jam: there are various cases where the ouput appears in a weird order, but basically all jobs do: make; bzr selftest | 07:54 |
| vila | ccxCZ: lack of resources :-/ And I minimally understand admin'ing gentoo so I try to use something is close to the "default" install (understanding that's pretty arbitrary for gentoo) | 07:55 |
| vila | s//that is close/ | 07:55 |
| ccxCZ | really hard to tell error just from the exception | 07:55 |
| vila | ccxCZ: what could help ? | 07:56 |
| ccxCZ | well, first I'd have to understand what the tests actually do :-) | 07:56 |
| ccxCZ | but something along of strace might help | 07:56 |
| mgz | morning all | 07:59 |
| vila | ccxCZ: these tests checks that we import the plugin from the right place either from the .py or .pyc depending on the test | 08:00 |
| vila | ccxCZ: the test plugin code is generated on the fly by the test itself | 08:01 |
| ccxCZ | about the resources, I recently bought phenom x6 machine for a server, so I probably can spare some cpu time | 08:02 |
| vila | ccxCZ: last time I looked I was wondering if there was some python compile trick on gentoo can be different during the ebuilds | 08:02 |
| vila | ccxCZ: things like right access or putting the compiled files in a different place, things like that | 08:03 |
| vila | ccxCZ: interesting, would you be interested in setting up a slave ? (Not especially complex but requiring some ssh setup with dedicated keys mostly) | 08:04 |
| vila | ccxCZ: you'll keep full control about opening hours of course ;) | 08:04 |
| ccxCZ | I have vserver set up there, so I can create one or two dedicated systems for it easilly | 08:06 |
| ccxCZ | lets see, I'll look into python's ebuild if I see something out of ordinary, but I don't think there's some gentoo-specific thing | 08:07 |
| vila | ccxCZ: the unusual thing I can see there is that we use a specific import hook and there may be a bug there (but it works everywhere else) | 08:09 |
| ccxCZ | it does make sure that it uses system version of expat, libffi and zlib instead of the bundled ones, but I doubt that's related | 08:10 |
| vila | ccxCZ: yeah, doubtless | 08:11 |
| vila | on the other hand if this is achieved by sys.path trickery... | 08:11 |
| ccxCZ | there are some patches, btw did you enable tests when compiling python? | 08:11 |
| ccxCZ | nope, it just rm -rf the relevant directories in python sources | 08:12 |
| vila | ccxCZ: that went way above my gentoo knowledge, how is that achieved ? | 08:12 |
| ccxCZ | FEATURES=test | 08:13 |
| ccxCZ | also adding PORT_LOGDIR="/var/log/portage" into make.conf would provide you complete build logs, containing list of patches applied | 08:14 |
| ccxCZ | seems the only patches there are related to crosscompiling | 08:17 |
| vila | ccxCZ: FEATURES=test in /etc/make.conf ? | 08:17 |
| ccxCZ | yup, add it to other features if it's defined already (whitespace delimited list) | 08:18 |
| ccxCZ | man make.conf for details | 08:18 |
| vila | nope, no features there: http://paste.ubuntu.com/698963/ | 08:19 |
| ccxCZ | then just add it, here's mine for reference http://codepad.org/XdRh5So7 | 08:20 |
| vila | 8-) | 08:21 |
| vila | ccxCZ: done | 08:22 |
| ccxCZ | just fyi, there are four variants how software can be built on gentoo: as root or portage user and with or without sandbox | 08:23 |
| ccxCZ | these are controlled by userpriv sandbox and usersandbox features respectively | 08:24 |
| ccxCZ | now that you added logging feature and tests you may reemerge python so we can inspect the build log closely | 08:25 |
| vila | I think I use root/no sandbox | 08:26 |
| vila | just 'emerge python' then ? | 08:27 |
| ccxCZ | yup. but I doubt anyting would come from that. what would be interesting is look at the strace of the test run for particular test on gentoo and on platform where it succeeds | 08:27 |
| ccxCZ | you can run emerge --info to see how are features set | 08:28 |
| ccxCZ | I think sandbox is enabled by default | 08:28 |
| vila | ouch, will be noisy | 08:28 |
| ccxCZ | can we run particular tests only> | 08:28 |
| ccxCZ | ? | 08:28 |
| vila | yes, but even running a single will load a bunch of stuff | 08:29 |
| ccxCZ | we can grep for the output then | 08:29 |
| vila | emerge running | 08:30 |
| ccxCZ | that will take while, especially when tests are enabled | 08:30 |
| vila | the tests are running | 08:31 |
| vila | hmm | 08:31 |
| vila | http://paste.ubuntu.com/698974/ but sounds unrelated | 08:31 |
| ccxCZ | oi, you seem to be merging python-3.1, that's probably not what we want | 08:32 |
| vila | eeerk, what's up there ? | 08:33 |
| ccxCZ | I usually disable that one globally so I forgot to tell you to use version specifier | 08:33 |
| ccxCZ | ctrl-c that one | 08:33 |
| vila | done | 08:34 |
| ccxCZ | do you want py3k on that system? if not it's probably best to mask it | 08:34 |
| vila | no | 08:34 |
| vila | how ? | 08:34 |
| ccxCZ | echo '>=dev-lang/python-3' >>/etc/portage/package.mask | 08:35 |
| ccxCZ | now you can emerge -av python | 08:36 |
| ccxCZ | it's --ask --verbose, so you see what's portage up to | 08:36 |
| vila | ccxCZ: sry, had to change kbd batteries :-} | 08:41 |
| ccxCZ | okay, what would we benefit from would be logging listdir before test_plugins.py:906 | 08:44 |
| vila | ccxCZ: ok, i propose 2.7.1-r1 | 08:45 |
| vila | err, portage proposes | 08:45 |
| vila | I'd rather stay with 2.6 unless most gentoo users use 2.7 ? | 08:45 |
| ccxCZ | I assume 2.7 is stable now then. I myself use testing systems practically everywhere | 08:46 |
| vila | ok, i'll update it later then, let's not change too many things at once | 08:47 |
| ccxCZ | yup, 2.7 is now stable on all architectures http://packages.gentoo.org/package/dev-lang/python | 08:47 |
| ccxCZ | for now you can do emerge -av '<python-2.7' | 08:48 |
| vila | with s/-3/-2.7/ emerge proposes 2.6.6-r2, sounds fine for now | 08:48 |
| vila | ok, running | 08:48 |
| vila | http://paste.ubuntu.com/698978/ | 08:49 |
| Merwin | Hi guys. I just used merge to get some branch into mine, did a few modifs and commited. | 08:51 |
| ccxCZ | okay I guess I missed some patches that were hidden in eclass | 08:51 |
| Merwin | I would liek to generate a patch of my modifs, not of the merge ! | 08:51 |
| Merwin | How can I do this ? | 08:51 |
| ccxCZ | bzr log -n 0 will get you the revno of the last commit before the merge (something like 80.1.1 or so) | 08:54 |
| ccxCZ | you can diff against that | 08:55 |
| Merwin | Thanks ccxCZ :) | 08:59 |
| vila | so, it looks like jenkins hide the aborted jobs when it's restarted | 09:27 |
| vila | which I did quite often lately. | 09:27 |
| vila | mgz: by the way, regarding the windows slave, it uses the same versions of testtools. subunit BUT it uses --parallel=subprocess instead of --parallel=fork | 09:29 |
| vila | mgz: so the leaks may come from that ? | 09:29 |
| mgz | qua leaks? | 09:30 |
| vila | mgz: sorry, the apparent leaks in the output | 09:31 |
| mgz | link? I'm not sure which problem you're referring too | 09:32 |
| mgz | -o | 09:32 |
| vila | http://babune.ladeuil.net:24842/view/%20High/job/selftest-windows/lastFailedBuild/console | 09:33 |
| vila | scary, did anybody ever heard a tickling sounds when recharging a battery (coming from the battery itself) | 09:36 |
| mgz | the little man is trying to get out | 09:36 |
| ccxCZ | so as I was saying, could you look at test_plugins.py:906 and add listdir() there? | 09:36 |
| ccxCZ | not sure what convention for logging you have there | 09:37 |
| vila | ouchy the noise is related to some bubbles on the + end 8-) | 09:38 |
| vila | ccxCZ: not easy, the ebuild is controlling which sources is used | 09:39 |
| vila | ccxCZ: is there a way to tell it to use apply a patch ? | 09:39 |
| ccxCZ | hmm, is there way to run testcase on bzrilb I just just fetched from bzr? | 09:40 |
| mgz | ah, that's a bit of a mess at the end there | 09:40 |
| ccxCZ | I meant tests in bzrlib | 09:40 |
| mgz | possibly fixing the tilde issue will help there too? | 09:40 |
| ccxCZ | I wouldn't concern myself with python further | 09:40 |
| vila | ccxCZ: ./bzr selftest -s bt.test_plugin.<TestClass>.<TestName> | 09:40 |
| vila | mgz: I wasn't referring to the failures but to the noise in the output | 09:44 |
| ccxCZ | vila: gee the failing test runs fine on my machine | 09:44 |
| vila | which looks like subunit stuff that is not supposed to end up here | 09:44 |
| vila | ccxCZ: yeah :) That's the trouble, it failed "reliably" there ;) | 09:45 |
| poolie | jelmer, ok, i see, http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/revision/1403 is more or less what i had in mind | 09:48 |
| poolie | glad i was on the right track | 09:48 |
| ccxCZ | probably try upgrading python to 2.7 then, you'll need to emerge app-admin/python-updater that will rebuild any modules you might have after the upgrade | 09:48 |
| mgz | ugh, that wasn't fun to reproduce, this commit message encoding stuff is a mess | 12:17 |
| mgz | Riddell: quick question, in bzr-builddeb debian_changelog_commit calls debian_changelog_commit_message twice, is there a particular reason for that? | 12:24 |
| mgz | or could the first return be reused? | 12:24 |
| jelmer | vila: hi | 12:31 |
| vila | oh my 14:30 already ! | 12:33 |
| Riddell | mgz: I think that could be reused | 12:47 |
| mgz | thanks, I'll do that and see if anything breaks | 12:50 |
| jam | vila: well, I've managed to trigger a hang. Using my branch: bzr selftest -s bt.per_interrepository.test_fetch -v "g_boundary_smart_old.InterDifferingSerializer,.*2a" | 12:56 |
| jam | It isn't guaranteed, but it does happen | 12:56 |
| jam | oddly, with bzr.dev I haven't triggered it yet. | 12:56 |
| jam | It is a slow test to start with, so I'll poke at it further. | 12:56 |
| vila | jam: otp but \o/ | 12:58 |
| mgz | jam: when you have a spare five mins, could you cast an eye over the prereq mp that moves the pack_stat code around? | 13:00 |
| mgz | then I could land those branches | 13:00 |
| jam | mgz: Actually, I think I did and meant to approve it, checking | 13:00 |
| mgz | vila: or, I guess anyone, is there a test trick for doing something better than `run_bzr([...], stdin="y\n")`? | 13:00 |
| mgz | we don't have -y options | 13:01 |
| jam | mgz: I didn't see a test suite update | 13:01 |
| jam | for the move_pack_stat change | 13:01 |
| mgz | jam: right, that branch doesn't change the tests, it just moves code (and relies on the existing end-to-end testing) | 13:01 |
| mgz | the subsequent branch adds direct unit test coverage for the function | 13:02 |
| jam | mgz: approved | 13:03 |
| mgz | thanks! | 13:03 |
| mgz | ...I wonder if pqm will let me at 2.4 these days... | 13:04 |
| Riddell | I had to ask a sysadmin nicely | 13:11 |
| vila | mgz: better trick ? I think I lack context.. | 13:12 |
| vila | you mean you're forced to use a blackbox test ? | 13:12 |
| mgz | yeah, the code that needs testing relates to cmd_commit | 13:14 |
| mgz | ...I might be able to get around this another way | 13:15 |
| vila | ha, you'd like to create to be able to use a cmd_commit object ? | 13:16 |
| vila | meh | 13:16 |
| vila | ha, you'd like to be able to use a cmd_commit object ? | 13:16 |
| mgz | I think I can just avoid the prompt, provided the test passes | 13:18 |
| mgz | ack, wrong button | 13:42 |
| vila | hmm, better make sure you don't have a prompt if the test fails though :) | 13:43 |
| mgz | okay, 2.4 branch submitted to pqm, when if fails I'll find someone to beg as Riddell suggested | 13:49 |
| vila | mgz: I can do that unless you want to keep it as a test when admins ask for one | 14:07 |
| Riddell | is there a hook that would be run after a bzr branch command? I don't seem to find one | 14:12 |
| GRiD | hey, can someone tell me what the B+Tree graph indexes are mainly used for now? | 14:14 |
| mgz | Riddell: post_branch_init maybe? but briandealwis posted about some hook shortcomings in the tiplog thread on list | 14:17 |
| mgz | hey looks like the sysadmins deserve more credit, pqm seems to be letting me land on 2.4 | 14:39 |
| mgz | also, interesting, some tests seem not to be cleaning up after themselves very well even there: <http://pastebin.ubuntu.com/699125> | 14:40 |
| vila | mgz: yup, a handful | 14:41 |
| vila | I lost steam to track them at one point :/ | 14:41 |
| vila | mgz: also, I think there are cases were bzr doesn't delete some tmp file so it's not the test "fault" | 14:42 |
| jam | vila: well, it looks like the test is actually exposing some brittle code. We send a request that the server doesn't understand, see that it rejects it, and then don't reconnect, but just keep sending the next request. | 15:15 |
| jam | I *think* it means we can get out of sync | 15:15 |
| jam | So the next request fails, because it gets into the pipeline. | 15:15 |
| vila | urgh, yeah, that can easily hang | 15:16 |
| jam | vila: test case traceback: http://paste.ubuntu.com/699160/ | 15:16 |
| jam | anyway, I might be provoking it more now because of the timeout loop | 15:17 |
| jam | maybe we're doing an extra read on the socket or something. | 15:17 |
| jam | I need to probe deeper | 15:17 |
| jam | ah, I have an idea. | 15:17 |
| jam | the old read would have returned the empty string? | 15:17 |
| jam | maybe not | 15:18 |
| jam | anyway, I can trigger a hang on demand by putting a "import pdb; pdb.set_trace()" in the code | 15:18 |
| jam | which gets them more out of sync | 15:18 |
| jam | I think | 15:18 |
| jam | (I manually 'continue' every pdb trigger, but it still causes a hang) | 15:18 |
| mgz | ha, I have a cunning plan | 15:18 |
| mgz | if I can become a member of ~canonical-bazaar, that gets me in ~launchpad, which gets me in ~launchpadlib-developers, which means I can at long last land the fix I did months ago | 15:19 |
| mgz | and make my todo queue more reasonable | 15:20 |
| jml | vila: what python is available for production udd? | 15:20 |
| jam | mgz: you should get added to ~canonical-bazaar, email poolie for it. However, you should really poke the launchpad folks if something of yours isn't getting landed. | 15:20 |
| jml | vila: (can I use argparse?) | 15:20 |
| jam | jml: python says 2.6.4 | 15:20 |
| jam | sorry 2.6.5 | 15:20 |
| jml | jam: thanks. | 15:20 |
| jam | I'm pretty sure it is ~stock lucid | 15:21 |
| vila | jml: 2.6.5 | 15:21 |
| vila | jml: and your fix has been deployed ;) | 15:21 |
| vila | well, fix, your mp I mean | 15:21 |
| jml | vila: yay :) | 15:21 |
| jam | jml: 'import argparse' says no-such-module | 15:21 |
| jam | I'm pretty sure that's py2.7 | 15:21 |
| jml | yeah, it's a 2.7 thing. | 15:21 |
| vila | oh, did I mention the importer has been happily making tea this morning ? | 15:21 |
| jml | pity | 15:22 |
| jml | vila: that's pretty awesome | 15:22 |
| jam | vila: as in a good thing or bad thing? | 15:22 |
| vila | Pretty good, no spike of spurious failures | 15:22 |
| * jml mumbles something about bzr's awesome cli being more re-usable | 15:22 | |
| mgz | jam: suggest to me a pokee, there's no need to bug robert again | 15:23 |
| jam | vila: I wasn't sure if there was downtime that udd was happily making tea for, or if udd decided that it really needed to drink gallons of tea even though launchpad was working :) | 15:23 |
| vila | there was still a minor bug that we didn't get as many log messages as I planned, but I have evidence that 2 import failures were seen as lp down, retried and succeeded later | 15:23 |
| jam | mgz: Well, poke on the mp, or go to #launchpad-dev and poke whoever is the on-call-reviewer | 15:23 |
| jam | vila: sounds good, as long as LP really was down then :) | 15:24 |
| vila | hehe, no, in this case only 2 transient failures, tomorrow may be more interesting | 15:24 |
| jam | ah, so it wasn't down, but we still got transient failures | 15:24 |
| jam | interesting. | 15:24 |
| vila | jam: well, the thing is, according to wgrant, it wasn't :) | 15:24 |
| jam | though maybe just a load thing? | 15:24 |
| jam | in which case, backing off is reasonable to do anyway | 15:24 |
| vila | on the lp side yeah | 15:24 |
| vila | exactly ! | 15:24 |
| jam | let's hammer LP when it is having load problems responding to our requests | 15:25 |
| vila | which is why I consider it a small success but wait for a bigger down time to confirm | 15:25 |
| jam | vila: interestingly, it isn't the 'select.select()' line that causes the failure, it is the 'if self.finished: return None' line | 15:36 |
| jam | it seems that the race is that we've told the service to shut down before we've sent it more data, or something to that effect. | 15:37 |
| jam | anyway, I'll poke more tomorrow. | 15:37 |
| vila | jam: oneiric seems to be hung :-} | 15:37 |
| jam | vila: from what I can tell, it looks like something is stopping the service, and leaving bytes on the socket, which then gets re-used for some reason. | 15:37 |
| jam | so sure, random failures | 15:38 |
| vila | yeah, 28min instead of the usual 3 or 4, definitely hung | 15:38 |
| jam | anyway, EOD, might be around late tonight. | 15:38 |
| vila | ok | 15:38 |
| vila | Riddell: does http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo-ebuild/48/console rungs a bell ? | 15:39 |
| vila | rings | 15:40 |
| vila | bah, silly me, what's that encoding ??? | 15:40 |
| vila | don't tell me ascii :) The question was: why the hell is it not utf-8 there ? ;) | 15:41 |
| vila | Riddell: but for you the question was: have you seen such failures before ? | 15:42 |
| Riddell | vila: hmm, well it's a recent test I added | 15:44 |
| Riddell | and it works on ubuntu but I suppose the launchpad plugin might be disabled on gentoo | 15:44 |
| vila | no | 15:44 |
| vila | well, not as far as I know | 15:44 |
| vila | Riddell: Can reproduce the failure while running with --no-plugins ? | 15:45 |
| vila | grr can *you* ? | 15:45 |
| Riddell | let me see | 15:46 |
| vila | hmm, the question will then be how can we check that a plugin is available... a simple bzrlib.plugins.launchpad check in sys.modules ? | 15:47 |
| vila | Riddell: anyway, it's probably worth fixing it | 15:48 |
| jml | what does list_packages achieve? | 15:55 |
| jml | At first I thought it was a utility, but I discovered that it's in the crontab | 15:55 |
| jml | (Also, what's the right ML for discussing changes like putting config in another branch?) | 15:55 |
| vila | jml: we rely on bzr for the config stuff so bzr ml may be appropriate for that, otherwise unbutu-distributed-devel is | 16:03 |
| jml | vila: ok. thanks. | 16:03 |
| jml | and list_packages? | 16:04 |
| vila | oh sorry | 16:04 |
| vila | jml: but finishing on config first, | 16:04 |
| jml | vila: oh ok, go right ahead | 16:04 |
| vila | jml: any option defined in pkgimport.conf can be overridden from locations.conf | 16:05 |
| jml | (my laptop is about to shut down due to low battery, but I'll log the conversation anyway) | 16:05 |
| vila | jml: so that may help you (or not if you want to track your config in a branch) | 16:06 |
| vila | jml: IIRC, (but james_w can confirm/deny), list_packages is used to make sure we import new packages | 16:08 |
| === beuno is now known as beuno-lunch | ||
| achiang | does bzr have an animal mascot? | 16:30 |
| achiang | because i think you should: http://www.herbweb.org/animals-collective-nouns.html | 16:31 |
| achiang | "A bazaar of guillemots" | 16:31 |
| mgz | ehehe | 16:31 |
| achiang | http://en.wikipedia.org/wiki/File:ThickbilledMurre23.jpg | 16:31 |
| achiang | http://2.bp.blogspot.com/__q53AR1ORfo/TCe-j2n9lOI/AAAAAAAAHt4/LbwUfJxS-u4/s1600/Common+Guillemots.+25+Jun+10.JPG | 16:32 |
| achiang | shall i file a bug? ;) | 16:32 |
| mgz | "bzr needs more auks" | 16:33 |
| jml | ok. | 16:56 |
| vila | jml: as in: the script update the package table and mass_import use it (see AllQueue) | 16:57 |
| jml | vila: oh, I thought that add_import_packages did that | 16:58 |
| vila | jml: a bit hackish but enough for us and for now (you're lucky I put the crontab in the branch though :) | 16:59 |
| vila | jml: inst't add_import_packages adding jobs instead ? | 16:59 |
| jml | vila: hmm, yes, but it doesn't need list_packages in order to do that, does it? | 16:59 |
| vila | jml: no, AllQueue quiry both tables | 17:00 |
| vila | jml: don't ask me why :) I arrive too late in the game and never asked (yet) :) | 17:00 |
| jml | vila: ok. thanks. | 17:01 |
| vila | jml: I kind of feel the features could be made part of mass_import though | 17:01 |
| vila | achiang: make a proposal to the mailing list :) | 17:02 |
| jml | vila: yeah. | 17:03 |
| jml | scripts shouldn't have code in them :\ | 17:08 |
| jml | nor underscores in the names, neither | 17:08 |
| jml | honestly, young people these days | 17:08 |
| jml | they should get off my lawn and turn down their music | 17:09 |
| === beuno-lunch is now known as beuno | ||
| === r0bby is now known as robbyoconnor | ||
| bob921 | Can I automatically undo the changes that a revision made? I'm at revno=53, and I want to undo the effects of revno=47 | 22:02 |
| bob921 | Answer to my question: go to directory where file was changed. bzr diff -r48..49 | patch -R | 22:17 |
| jelmer | bzr merge -r49..48 should also work | 22:32 |
| poolie | good morning | 23:13 |
| Noldorin | jelmer, hey | 23:29 |
| Noldorin | you around? | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
