=== yofel_ is now known as yofel [01:38] What does [01:38] AttributeError: 'Tree' object has no attribute 'encoding' [01:38] mean? [01:40] (doing bzr branch on a git repo) [01:40] Sounds like some code is expecting one kind of object but encountering another [01:41] Which could be due to a plugin needing to be updated to work with your version of bzrlib, or something like that. [01:42] spiv: It's the Bazaar PPA, on a Lucid box & `apt-get install bzr-git` [01:42] spiv: and, I suspect you're right, seeing as how this works on my Natty laptop. [01:43] afc, spiv, hi [01:43] (or at least, has worked for the use cases I have tried with small Git trees) [01:43] * AfC bows to poolie [01:43] ! [01:43] (don't get too excited now) [01:43] please file a bug, with the traceback, against bzr-git, and post the number? [01:44] [there's also a problem where bzr-git refuses to branch from a github https URL, but that's for another day] [01:45] poolie: do you just want the dump to stderr, or the full commend run from .bzr.log? [01:46] When in doubt, scream and shout^W^W^W er, I mean, give more information rather than less ;) [01:52] poolie, spiv: as requested https://bugs.launchpad.net/bzr/+bug/861973 [01:52] 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] thanks [01:53] I hope it's just a dependency problem; this has really messed me up. [01:54] it was working recently? [01:54] poolie: as I noted in the bug and above, this workflow does work on my Natty system. [01:55] [not, admittedly, with the large repo in question, but with other projects' locally cloned git repos] [01:56] huh [01:56] i can see how it would happen [01:56] i think [01:56] it got the hash of a tree when it expected a commit [01:57] poolie: I can try and duplicate this on my laptop, but I'll need to get to a fatter pipe first. [02:02] it might help if you can either attach or describe how to get the git branch that causes trouble [02:02] poolie: that doesn't sound like a missing dependency, then [02:02] poolie: oh, that's easy [02:02] no i don' think it is [02:03] it sounds like there is something in the structure of the repo it can't deal with [02:03] normally an attributeerror is a version mismatch but i think not in this case [02:03] poolie: git clone https://github.com/torvalds/linux.git linux [02:03] poolie: bzr branch linux upstream [02:04] * AfC just remembered he hadn't fetched the tags. I'll try that now [02:05] same crash [02:06] Like I said, on this Natty system, admittedly against smaller projects, I have git cloned then bzr branched many times. [02:06] {shrug} [02:06] Upgrading this server to Natty isn't really an option, y'know? :) [02:06] well [02:06] if you're using the ppa there should be no need to upgrade to natty [02:07] poolie: (fwiw, this isn't makework; I really do need an import of the kernel tree) [02:07] poolie: that's what I would have thought, yes [02:07] i'll see if i can reproduce it on tip, at leaste [02:08] you could usefully try bzr-git from https://launchpad.net/~bzr/+archive/daily?field.series_filter=lucid [02:08] poolie: just bzr-git or change the whole PPA? [02:09] [you guys have been pretty ruthless over the years about warning people off the dailies] [02:09] hm [02:09] how i would describe the dailies is: [02:09] - 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:10] [the "what? plugins don't work together? gee, too bad, that's what releases are for"] [02:10] - there is a somewhat higher chance of bugs [02:10] but not much [02:10] i think that's the main warning [02:10] right, well in this case we're talking about plugins, which is why I prevaricate [02:10] anyway, will try as requested [02:11] is that ppa:bzr/daily then? [02:11] yes [02:11] the answer to the version incompatibilty thing is basically to just be prepared to downgrade to the betas [02:12] iwnbni launchpad kept a little bit of history of ppa packages so that you could downgrade to an older daily [02:12] but, not yet [02:12] so, back to my original question, should I just grab the bzr-git .deb and dulwhich .deb from there? [02:12] or upgrade bzr as well [02:13] [whichever, I'm asking for your help so I will do either one as you request for diagnostics purposes] [02:13] probably everything [02:13] ok [02:14] obviously you know there may be some fallout, but also that you can downgrade again [02:15] kaboom :( [02:15] same error [02:16] 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] ok, that's useful to know at least [02:16] * AfC swears quietly [02:17] poolie: oh, [02:18] ? [02:18] [oh, I just discovered I wasn't logging here[ [02:19] Jelmer discovered that the packaging branches of linux were missing [02:19] fyi [02:19] (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:20] here we are, [02:20] 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] hm [02:21] second is [02:21] that [02:21] hm that looks like a different probelm [02:21] one possibly fixed by retrying it [02:21] poolie: ok, (but, meanwhile, there are no packaging branches for Linux there; is that expected?) [02:22] oh there is a bug https://bugs.launchpad.net/udd/+bug/792193 [02:22] 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] well, it's known [02:22] Hardy? [02:22] hm. I was trying to find Maverick's packaging branches. Anyway. [02:23] so [02:23] i'm still waiting for that to download [02:23] if you run 'BZR_PDB=1 bzr branch ...' [02:23] and then you should get a debugger prompt; please type 'p locals()' [02:23] ok [02:25] poolie: : [02:25] {'rev': , 'self': , 'commit': , 'decode_using_encoding': , 'lookup_parent_revid': >} [02:25] ok that's useful [02:25] gesundheit [02:26] and try 'up' 'p locals()' again [02:26] ok [02:26] > /usr/lib/python2.6/dist-packages/bzrlib/plugins/git/repository.py(332)lookup_foreign_revision_id() [02:26] -> mapping.revision_id_foreign_to_bzr) [02:26] {'foreign_revid': '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c', 'commit': , 'self': LocalGitRepository('file:///home/andrew/torvalds/linux/'), 'mapping': } [02:28] [linux clone from github took 15m01s so you should be able to dup all this hopefully soon] [02:29] 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] which one? [02:29] https://bugs.launchpad.net/udd/+bug/792193/comments/17 [02:29] 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] (the one you found 5 minutes ago) [02:31] 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:32] that would be nice [02:32] ok so i can reproduce the crash [02:32] which is a good start [02:32] great! [02:32] poolie: you on Lucid or Natty? [02:32] pah, oneiric [02:32] ok [02:32] :) [02:32] that means its not a Lucid problem, as such, but more likely a Bazaar problem, yeah? [02:33] i'm 80% sure it's a quirk in the linux.git history that bzr-git is not coping with [02:33] yeah [02:33] such as perhaps a tag pointing directly to a tree, not to a commit [02:33] that wouldn't surprise me [02:34] 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:40] 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:41] just watch it [02:41] jelmer can probably solve it much faster than me but i'll have a go [02:43] sweet [02:43] you guys rockl [02:45] :) thanks i hope we can get it unstuck [02:45] it may be fairly shallow [02:47] Hope s [02:47] 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. [05:04] afc, it was indeed a quirky tag; deleting it lets the import proceed [05:04] i'm going to see if jelmer agrees with my approach [05:10] 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:12] yep [05:12] i just want to know what j thinks about just how we will skip past it [05:12] i put a workaround on the bug [06:25] hi all ! [06:38] hi vila [06:38] AfC: hi [06:38] jelmer: hey ! [06:39] jelmer: yo [06:40] jelmer: Hit a funny bug in an unavoidably prominent tree I was trying to parse with bzr-git [06:41] AfC: I'm just reading the bug report now [06:42] jelmer: if you need | want to reproduce, I can give you the git URL [06:44] jelmer: (also, bzr-git choking when given a github https URL, *is* fixed by the daily PPA, nicely done) [06:47] AfC: thanks [06:47] AfC: let me see if I can reproduce it manually first though\ [06:49] → city [06:50] today's hang is on gentoo :-/ [06:59] morning all [07:00] good morning [07:00] vila: what's the issue with gentoo? [07:01] 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:02] 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:03] I see. Anyway if you need some gentoo magic feel free to poke me. [07:03] 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] jam: you already have access via babune [07:03] vila: except you never restored my account there [07:03] the important bit above is "via babune* [07:03] vila: I mean having me manually run "bzr selftest" [07:03] you never had access to slaves [07:04] vila: babune is not giving us enough insight into what is failing [07:04] I was hoping to directly run selftest so that I could see a failing test, etc. [07:04] jam: and you probably won't be able to reproduce outside of babune [07:06] hi jam, vila [07:06] hi poolie [07:06] vila: I thought you said that the schroots were failing, but the vms were not, did I misunderstand? [07:06] Is it just purely random? [07:07] it is random [07:07] I saw one case where for the same revision the chroot hung but the vm passed [07:08] vila: I saw this: http://paste.ubuntu.com/698934/ [07:08] in the failing babune run of gentoo [07:08] vila, thanks for spotting that bug in my update patch [07:08] it now works from a subdir [07:08] I wonder if -Werror is causing a thread to die [07:08] because of a Warning from gzip [07:08] do you want to rereview it or should i just send it? [07:08] causing something to hang. [07:09] (note, that is the only line in the raw console output that looks at all different from the rest.) [07:09] 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:10] that one, in particular, looks to be line 21 of gzip.py, part of "write32u" [07:10] and has the comment: # The L format writes the bit pattern correctly whether signed [07:10] # or unsigned. [07:12] poolie: you're welcome :) [07:12] poolie: oh, please go ahead [07:13] jam: may be, but it there has been no hang on gentoo for .... months, so pretty unlikely [07:13] s/it// [07:14] 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] 'morning jam, poolie [07:18] hi jelmer, can you help me with bug 816973? [07:18] Error: Launchpad bug 816973 could not be found [07:28] 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:29] poolie: looking now [07:29] vila: well, I do see the gzip warning, I'll go check if it exists in a non hanging run [07:31] interestingly, the passing test has the hanging message on a line by itself, while the failing one has it intermixed [07:32] I don't know if that is significant or not, I'm trying to diff the raw logs now [07:32] jelmer, https://bugs.launchpad.net/bzr-git/+bug/861973 [07:32] not very helpful, as the --parallel means the ordering is ~locally random [07:32] 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] ccxCZ: since you asked :) There is a weird failure documented in #830545 [07:33] bug #830545 [07:33] Launchpad bug 830545 in bzr-buildbot-net "Update for Gentoo testing routines" [High,In progress] https://launchpad.net/bugs/830545 [07:33] jam: thanks :) [07:35] vila: something pretty weird. The failing test seems to be missing every 6th test or so. [07:35] 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:36] jam: BZR_CONCURRENCY=6 on gentoo's slave [07:36] I'm not particularly familiar with how --parallel=? is splitting stuff out [07:36] possibly [07:36] jam: round robin split for bzr, equal-time-buckets for testr [07:36] jam: the last change here is spiv spreading the tests across the subprocess instead of giving a slice of the whole [07:36] (with round robin for unknown time tests) [07:37] vila: http://imagebin.org/176688 [07:37] vila: oh? I'm out of date then :) [07:37] vila: that is after 'sort' ing the output [07:37] of the raw log [07:38] that is gentoo run 520 vs 522 [07:38] lifeless: no, not at all [07:38] lifeless: but testr is not used there [07:38] oops out of swap :( but figured it out. had to use bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth/d2x-rebirth [07:39] jam: yup, sounds like more evidence there is a hang in one subprocess while the others work normally [07:40] the '----' line is weird though [07:40] vila: that is Vim [07:40] it is just saying "no content on left" [07:40] oh, not from selftest then, ok [07:42] jam: note that the 1/6 may be just caused by a test taking longer [07:42] but of course a hung test takes forever [07:44] vila: you mean the pyc stuff? is there a log for that somewhere> [07:45] vila: how so? I sorted all tests, and then did th ediff [07:45] so those tests are *not in the output* [07:45] I went back and then searched the sorted log for the first tests that are missing [07:45] http://paste.ubuntu.com/698951/ [07:45] haaa [07:46] well, just saying. You didn't explain your pastebin so I guessed (wrongly ;) [07:46] what is this one about ? [07:47] vila: so, first, I grabbed the raw console output from a success and a fail [07:47] jam: ohh, re-reading the log you mentioned it ws sorted, I missed that [07:47] then I sorted them, and did a diff [07:47] finding ones that are in success [07:47] then I iterated success in its original order [07:47] and found ones that were marked missing in the hung test [07:47] tests [07:47] those are the first 10 [07:47] so the hanging one should be before ? [07:47] found the log, not sure what make of it though, never had issues with .pyc not loading [07:47] vila: arguably, the first one should be the hung one, right? [07:48] vila: ah, wait a sec [07:48] hmm, the first or the preceeding one... you may be right... [07:48] +bzrlib.tests.test_bundle.V4BundleTester.test_non_bundle ... /usr/lib/python2.6/gzip.py:21: DeprecationWarning: struct integer overflow masking is deprecated [07:48] is the only interesting line in hung that isn't in success, except that is just because of the warning [07:48] ccxCZ: ha, you neither, damn [07:48] there is an "ok" still in the output for it. [07:49] I'm guessing that is just noise. [07:49] jam: I'm pretty sure the ok is output after the cleanups, mgz ? [07:49] vila: the other thing that is missing in the output is the Cython lines [07:49] whic cython lines ? WHile compiling the extensions ? [07:49] vila: The 'diff' was just confused because the 'ok' ended up on a different line. [07:50] jam: I'm confused as well about what fallouts this implies :) [07:50] vila: you sure this is gentoo specific? do you have other slaves with same version of python? [07:50] vila: this is the complete list of sorted-but-missing lines: http://paste.ubuntu.com/698953/ [07:50] if you go to the end [07:50] there are Cython lines [07:50] Now, Cython only ~recently started writing "skipping XXX (up-to-date)" [07:51] but something about hung isn't showing those lines. [07:51] 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] and the first error seems to be related to pyc loading rather not loading [07:51] vila: depends [07:51] :) [07:51] ok, let me check [07:51] vila: ah, they show up at the end of the success log [07:51] maybe because it is to stderr? [07:51] it's rolling release, y'know :-) [07:52] ccxCZ: yeah, I wsa hoping you spotted it when looking [07:52] vila: all the way at the *end* of http://babune.ladeuil.net:24842/job/selftest-gentoo/520/consoleText [07:52] It says "python setup.py build_ext -i" [07:52] shouldn't that be happening before the test run? [07:52] jam: depends :-} [07:52] 2.6 something [07:52] but extensions are re-compiled only when needed relying on make [07:53] vila: sure, but compiling them after running the test suite seems odd [07:53] ccxCZ: covered then, at least by lucid and maverick [07:53] is it just a Jenkins-ism that it puts stderr after stdout ? [07:53] jam: no, no [07:54] you might want to consider having testing gentoo slave along stable one btw, quite a few people use that [07:54] jam: there are various cases where the ouput appears in a weird order, but basically all jobs do: make; bzr selftest [07:55] 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] s//that is close/ [07:55] really hard to tell error just from the exception [07:56] ccxCZ: what could help ? [07:56] well, first I'd have to understand what the tests actually do :-) [07:56] but something along of strace might help [07:59] morning all [08:00] ccxCZ: these tests checks that we import the plugin from the right place either from the .py or .pyc depending on the test [08:01] ccxCZ: the test plugin code is generated on the fly by the test itself [08:02] about the resources, I recently bought phenom x6 machine for a server, so I probably can spare some cpu time [08:02] ccxCZ: last time I looked I was wondering if there was some python compile trick on gentoo can be different during the ebuilds [08:03] ccxCZ: things like right access or putting the compiled files in a different place, things like that [08:04] 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] ccxCZ: you'll keep full control about opening hours of course ;) [08:06] I have vserver set up there, so I can create one or two dedicated systems for it easilly [08:07] 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:09] 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:10] 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:11] ccxCZ: yeah, doubtless [08:11] on the other hand if this is achieved by sys.path trickery... [08:11] there are some patches, btw did you enable tests when compiling python? [08:12] nope, it just rm -rf the relevant directories in python sources [08:12] ccxCZ: that went way above my gentoo knowledge, how is that achieved ? [08:13] FEATURES=test [08:14] also adding PORT_LOGDIR="/var/log/portage" into make.conf would provide you complete build logs, containing list of patches applied [08:17] seems the only patches there are related to crosscompiling [08:17] ccxCZ: FEATURES=test in /etc/make.conf ? [08:18] yup, add it to other features if it's defined already (whitespace delimited list) [08:18] man make.conf for details [08:19] nope, no features there: http://paste.ubuntu.com/698963/ [08:20] then just add it, here's mine for reference http://codepad.org/XdRh5So7 [08:21] 8-) [08:22] ccxCZ: done [08:23] just fyi, there are four variants how software can be built on gentoo: as root or portage user and with or without sandbox [08:24] these are controlled by userpriv sandbox and usersandbox features respectively [08:25] now that you added logging feature and tests you may reemerge python so we can inspect the build log closely [08:26] I think I use root/no sandbox [08:27] just 'emerge python' then ? [08:27] 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:28] you can run emerge --info to see how are features set [08:28] I think sandbox is enabled by default [08:28] ouch, will be noisy [08:28] can we run particular tests only> [08:28] ? [08:29] yes, but even running a single will load a bunch of stuff [08:29] we can grep for the output then [08:30] emerge running [08:30] that will take while, especially when tests are enabled [08:31] the tests are running [08:31] hmm [08:31] http://paste.ubuntu.com/698974/ but sounds unrelated [08:32] oi, you seem to be merging python-3.1, that's probably not what we want [08:33] eeerk, what's up there ? [08:33] I usually disable that one globally so I forgot to tell you to use version specifier [08:33] ctrl-c that one [08:34] done [08:34] do you want py3k on that system? if not it's probably best to mask it [08:34] no [08:34] how ? [08:35] echo '>=dev-lang/python-3' >>/etc/portage/package.mask [08:36] now you can emerge -av python [08:36] it's --ask --verbose, so you see what's portage up to [08:41] ccxCZ: sry, had to change kbd batteries :-} [08:44] okay, what would we benefit from would be logging listdir before test_plugins.py:906 [08:45] ccxCZ: ok, i propose 2.7.1-r1 [08:45] err, portage proposes [08:45] I'd rather stay with 2.6 unless most gentoo users use 2.7 ? [08:46] I assume 2.7 is stable now then. I myself use testing systems practically everywhere [08:47] ok, i'll update it later then, let's not change too many things at once [08:47] yup, 2.7 is now stable on all architectures http://packages.gentoo.org/package/dev-lang/python [08:48] for now you can do emerge -av ' with s/-3/-2.7/ emerge proposes 2.6.6-r2, sounds fine for now [08:48] ok, running [08:49] http://paste.ubuntu.com/698978/ [08:51] Hi guys. I just used merge to get some branch into mine, did a few modifs and commited. [08:51] okay I guess I missed some patches that were hidden in eclass [08:51] I would liek to generate a patch of my modifs, not of the merge ! [08:51] How can I do this ? [08:54] bzr log -n 0 will get you the revno of the last commit before the merge (something like 80.1.1 or so) [08:55] you can diff against that [08:59] Thanks ccxCZ :) [09:27] so, it looks like jenkins hide the aborted jobs when it's restarted [09:27] which I did quite often lately. [09:29] 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] mgz: so the leaks may come from that ? [09:30] qua leaks? [09:31] mgz: sorry, the apparent leaks in the output [09:32] link? I'm not sure which problem you're referring too [09:32] -o [09:33] http://babune.ladeuil.net:24842/view/%20High/job/selftest-windows/lastFailedBuild/console [09:36] scary, did anybody ever heard a tickling sounds when recharging a battery (coming from the battery itself) [09:36] the little man is trying to get out [09:36] so as I was saying, could you look at test_plugins.py:906 and add listdir() there? [09:37] not sure what convention for logging you have there [09:38] ouchy the noise is related to some bubbles on the + end 8-) [09:39] ccxCZ: not easy, the ebuild is controlling which sources is used [09:39] ccxCZ: is there a way to tell it to use apply a patch ? [09:40] hmm, is there way to run testcase on bzrilb I just just fetched from bzr? [09:40] ah, that's a bit of a mess at the end there [09:40] I meant tests in bzrlib [09:40] possibly fixing the tilde issue will help there too? [09:40] I wouldn't concern myself with python further [09:40] ccxCZ: ./bzr selftest -s bt.test_plugin.