| james_w | mtaylor: so, the failure that stops it extracting for me on lucid is the same problem that building has apparently, but instead of being an error it just silently carries on. I don't see how this ever worked though. | 00:29 |
|---|---|---|
| james_w | mtaylor: the way I see it, it calls tar with -k, which means "don't replace existing files when extracting" and so the updated file that is listed in include-binaries isn't written over the top of the file from upstream. | 00:30 |
| === Ursinha-afk is now known as Ursinha | ||
| jtv | spiv: lifeless tells quite highly of your repo repair skills | 06:16 |
| spiv | jtv: was just reading backlog from the other channel | 06:16 |
| * jtv cheers him on | 06:16 | |
| jtv | (btw got the Prague picture? Women here have a tendency to point at you and ask questions when I show them my pictures) | 06:16 |
| spiv | jtv: pastebin the contents of 'find . -type f .bzr/repository'? | 06:17 |
| spiv | jtv: I did, thanks :) | 06:17 |
| jtv | spiv: not sure what it is you want me to find—that's not correct "find" syntax. | 06:17 |
| spiv | Although I admit to being puzzled why you are showing my picture to various women ;) | 06:17 |
| spiv | Oh, thinko | 06:17 |
| jtv | spiv: it's just in the batch, I can't help it. Some quite good ones. | 06:17 |
| spiv | 'find .bzr/repository -type f' | 06:18 |
| jtv | Got a great one of elmo, like an ultra-modern version of a 17th-century Dutch painting. But he doesn't like being in pictures so I'm not sharing widely. :/ | 06:18 |
| jtv | spiv: http://paste.ubuntu.com/483798/ | 06:20 |
| spiv | And pastebin 'bzr dump-btree .bzr/repository/pack-names' | 06:20 |
| jtv | spiv: http://paste.ubuntu.com/483800/ | 06:20 |
| spiv | jtv: ok, that definitely looks like you hit a pack-names update race. The fix should be 'mv .bzr/repository/obsolete_packs/f16*.*ix .bzr/repository/indices/ && mv .bzr/repository/obsolete_packs/f16*.pack .bzr/repository/packs' | 06:25 |
| spiv | jtv: which version of bzr? | 06:26 |
| lifeless | spiv: not going to roll forward ? or is there no .new file ? | 06:26 |
| spiv | lifeless: nope | 06:27 |
| jtv | spiv: 2.2.0 | 06:27 |
| spiv | jtv: drat, that should contain all the fixes jam has made in this area :/ | 06:27 |
| spiv | jtv: which filesystem? | 06:27 |
| jtv | ext4 | 06:28 |
| jtv | it goes bad from time to time… wgrant has reported the same | 06:28 |
| jtv | Can I just cp -r to back up my repo? | 06:28 |
| spiv | Yep | 06:29 |
| jtv | Well, that's done. | 06:31 |
| jtv | And it seems to be working! Yay! | 06:32 |
| jtv | Thanks spiv, thanks lifeless :-) | 06:32 |
| spiv | jtv: Now the only question is what caused it :/ | 06:33 |
| jtv | My candidates are: a recent filesystem corruption and a race condition (the problem struck when I was pulling multiple branches in the same repo) | 06:34 |
| wgrant | jtv: It hasn't done that for a long time for me. | 06:48 |
| wgrant | Since maybe May. | 06:48 |
| spiv | wgrant: that's roughly when jam's fixes landed, IIRC | 06:54 |
| jtv | this is about the fs corruption I think, not the repo trouble | 06:55 |
| wgrant | FS corruption, yes. | 06:55 |
| wgrant | Block device flakes out for a moment, kernel marks it read only, FS goes bye-bye... | 06:56 |
| jtv | For me they seemed to go away for a while when I switched from the proprietary nVidia driver to nouveau, but now they're back. | 06:56 |
| jtv | Oh, more trouble while running rocketfuel-update. :-( | 06:56 |
| jtv | Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://jtv@bazaar.launchpad.net/)> ignored | 06:56 |
| jtv | Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0xa3b895c> ignored | 06:56 |
| jtv | sorry, rocketfuel-get. | 06:57 |
| spiv | Those are harmless warnings, there have been posts on the list about them. | 06:57 |
| jtv | ok | 06:57 |
| spiv | (Perhaps utilities/update-sourcecode needs to be updated to call bzrlib.initialize()?) | 06:58 |
| vila | hi all ! | 07:22 |
| vila | spiv: any chance you can review my looms tomorrow ? You did notice you are the pp this week :-D ? | 07:26 |
| vila | mgz: pong | 07:35 |
| vila | jtv, spiv: bigkevmcd also had a corrupted repo yesterday, also on ext4 :-/ I asked him to file a bug (to track the config details) but I don't see it so far | 07:39 |
| spiv | vila: yeah, I'll review | 07:40 |
| vila | yeah ! | 07:41 |
| spiv | vila: interesting... I wonder if bigkevmcd had a crash as well? | 07:41 |
| vila | spiv: yeah, a reboot | 07:41 |
| spiv | Hmm! | 07:42 |
| vila | spiv: an empty .pack file but dirstate and last-revision where mentioning the missing revision | 07:42 |
| vila | which can only be explained by a very very dirty fs flush... | 07:42 |
| spiv | vila: interesting, quite different to jtv's symptoms then | 07:42 |
| spiv | vila: which was pack-names referenced a pack that had been moved to obsolete_packs | 07:43 |
| vila | spiv: I didn't follow jtv's crash, can you summzrize or point me to the right... ok | 07:43 |
| vila | eeerk an impossible scenario too... | 07:43 |
| spiv | No temporary pack-names files lying around (although a couple of upload/*.autopack, not sure how recent) | 07:43 |
| vila | hmm, unless a pack-names file creation wasn't flushed (including creation of the temp one and its renaming...) | 07:44 |
| vila | twilight zonesque | 07:44 |
| spiv | vila: right | 07:44 |
| spiv | so concretely, the fs might guarantee that f = open('foo.new', 'w'); write(f, '...'); close(f); rename('foo.new', 'foo') is atomic in the face of a crash (as I believe ext3 and ext4 do by default now), but not guarantee anything about whether files created and renamed before that will actually hit disk before that. So the (small) pack-names file might have its update committed, but the larger pack file might not be. | 07:49 |
| vila | ...or somehow related to a journalling problem... It's hard to believe that an out-of-order error can happen for the updates of a single process though... | 07:50 |
| vila | hehe long mesgs tend to cross on the wire :) | 07:51 |
| spiv | Well, in the face of a system crash, I don't think any guarantee is made about the relative order that files are written. | 07:51 |
| vila | but journalling is supposed to protect against such scenarios... | 07:52 |
| spiv | ext4 defaults to data=ordered, which strictly speaking only guarantees that the file *metadata* is journalled. | 07:52 |
| spiv | Search for "* ordered mode" in http://lxr.free-electrons.com/source/Documentation/filesystems/ext4.txt | 07:53 |
| vila | i.e. dir content and that's exactly what failled...oh wait, *file* content vs *dir* content :-/ | 07:53 |
| vila | eerk, ordered is the default :-/ not journal | 07:55 |
| * vila revises its beliefs :( | 07:55 | |
| vila | so the fs is not corrupted... I'm so glad :( | 07:56 |
| spiv | And even if data=journalled it's not clear to me if that implies that changes to multiple files are necessarily committed in the same order as a (single) process that issues them. That doc only clearly states than an individual file will be consistent. | 07:57 |
| vila | spiv: if data=journal (and the journal is not lost somehow), then after a crash, the journal is replayed and all updates should be seen | 07:59 |
| vila | that's the point of a journal or all bets are off | 07:59 |
| spiv | vila: right, but the most recent changes might not be "committed" and lost, so the question of ordering still matters. | 08:00 |
| vila | once an update is committed on the main fs, the corresponding entries must be deleted from the journal or be defined in a way that allow them to become no-ops if they are re-played | 08:00 |
| spiv | vila: also, see the auto_da_alloc option described at that URL | 08:01 |
| vila | spiv: and we don't use fsync right ? | 08:03 |
| vila | It's a bit scary to be qualified 'broken' there, sounds like some fs optimizations are a bit user-hostile... | 08:05 |
| spiv | vila: right, because it practice it is a huge performance hit because it tends to cause a system-wide flushing of buffered writes :( | 08:05 |
| vila | EISHOULDNTHAVETOCARE | 08:05 |
| spiv | vila: there have been some "entertaining" discussions on the topic of fsync/ext4/etc summarised on LWN in the last year or so | 08:06 |
| spiv | vila: google for o_ponies if you like ;) | 08:06 |
| vila | hehe | 08:06 |
| vila | All I want is my rug back ! | 08:11 |
| === Leonidas is now known as Guest60304 | ||
| === Leonidas_ is now known as Guest96662 | ||
| CcxCZ | hi, I have question about repository layout/workflow, can anyone advise? | 09:19 |
| CcxCZ | I have two projects which share common source files. What is the best way to keep it all versioned and make it easy to backport changes from one project to another? | 09:22 |
| vila | CcxCZ: the easiest way today is to handle 3 separate projects: project A, project B and project common | 09:27 |
| vila | CcxCZ: 'nested trees' is the planned feature you really want here | 09:27 |
| vila | CcxCZ: with nested trees you will be able to "nest" project common in both projects and cleanly merge changes made by one project or the other | 09:28 |
| CcxCZ | vila: isn't it supported by 2.2? | 09:30 |
| vila | CcxCZ: no, at best it will be supported or alpha in 2.3 | 09:30 |
| CcxCZ | :[ | 09:31 |
| CcxCZ | vila: thanks for info | 09:31 |
| vila | CcxCZ: depending on the volume of shared files and changes, there are some ways to address your need today but nothing trivial :-/ | 09:32 |
| spiv | Huh, for some reason --lsprof-file foo.callgrind has given me a callgrind file where most of the calls aren't connected to each other :( | 09:34 |
| vila | spiv: stop doing things behind callgrind back ! | 09:35 |
| spiv | vila: I didn't think I was! | 09:37 |
| CcxCZ | what's best tool to migrate from svn? | 10:03 |
| vila | CcxCZ: bzr-svn allows you to work with bzr while still connecting to an svn server | 10:09 |
| maxb | I think in most cases, bzr-svn is also the best tool for a one-shot migration | 10:10 |
| CcxCZ | I think it required some specific repository format which was bothersome | 10:15 |
| CcxCZ | I'm going to try svn2bzr.py now | 10:15 |
| knittl | where can i find docs on compiling bazaar? | 10:19 |
| knittl | bzrlib/_static_tuple_c.c:35: fatal error: _simple_set_pyx_api.h: No such file or directory | 10:20 |
| jelmer | CcxCZ, it only requires a specific repository format if you're using bzr < 2.0 | 10:21 |
| jelmer | (which you probably should not anyway..) | 10:22 |
| vila | knittl: just try 'make' in the source directory | 10:25 |
| vila | knittl: you need pyrex and a C compiler | 10:25 |
| knittl | vila: make? i did setup.py install | 10:25 |
| knittl | i might be missing pyrex | 10:26 |
| knittl | what's the package's name in ubuntu? | 10:26 |
| vila | knittl: why do you want to run setup.py if you're using Ubuntu ? There is a ppa with the latest stable versions and if you want to run from sources you shouldn't need setup.py | 10:27 |
| knittl | because setup.py is usually the right way for python apps | 10:27 |
| knittl | and i need to run from source | 10:28 |
| maxb | CcxCZ: svn2bzr.py? Hasn't that project been dead for three years? | 10:28 |
| vila | knittl: then run from sources, using setup.py will only make your life harder | 10:28 |
| vila | knittl: python-pyrex | 10:28 |
| knittl | what is setup.py used for then? | 10:30 |
| vila | knittl: *installing* from a release tarball for platforms that doesn't provide binary packages :) If you encounter a problem using it, please file a bug so we can track it | 10:31 |
| vila | knittl: but if you want to run from sources, you don't need it (or you will have to run it each time you modify the sources) | 10:32 |
| knittl | uhm ok. let's try make | 10:32 |
| maxb | Well, that's not entirely true. You only need to re-run it when you modify compiled bits | 10:32 |
| vila | knittl: all you need to run from sources is to make the 'bzr' script appears in your PATH | 10:32 |
| maxb | And "make" is just a trivial wrapper around setup.py | 10:32 |
| knittl | well, run everytime sources change is normal routine for selfcompiled apps | 10:32 |
| vila | maxb: I was talking about setup.py, not make | 10:33 |
| knittl | no target install | 10:33 |
| knittl | :-/ | 10:33 |
| vila | knittl: 'make' not 'make install' | 10:33 |
| knittl | i did make. and then i wanted to install | 10:33 |
| vila | knittl: ghaaa, sorry. 'make' will build the extensions in the *source* dir, you can then run from here, no need to install, | 10:34 |
| knittl | but i want to install it systemwide | 10:34 |
| vila | knittl: if you really really want to install, then yes, run setup.py | 10:35 |
| knittl | there we go … | 10:35 |
| vila | knittl: why not use the version provided by either Ubuntu or one of the ppas described at https://edge.launchpad.net/bzr ? Just curious... | 10:36 |
| vila | knittl: some plugins requires that the dependencies are kept in sync and is not a trivial task (/me looks at maxb ;) | 10:37 |
| maxb | It's not that hard, either, though | 10:37 |
| knittl | running comparisons of different dvcs (latest version from source) | 10:37 |
| maxb | I can understand wanting to check out how difficult a self-build is, to not be beholden on packagers | 10:38 |
| vila | knittl: then I'd strongly recommend using https://edge.launchpad.net/~bzr/+archive/ppa , it's recent enough to make no differences with bzr.trunk except that the later may drive you into dependencies problems that will be totally irrelevant to a dvcs comparison... | 10:39 |
| knittl | hmm | 10:40 |
| vila | knittl: anyway, these are the options, use whatever you see fit | 10:40 |
| knittl | but it's only rc? | 10:40 |
| vila | knittl: nope, see this channel topic, I'm pretty sure all installers are already up-to-date (minus the OSX one ?) | 10:41 |
| knittl | what's special about the channel topic? | 10:41 |
| vila | knittl: so the official announcement will occur RSN but the sources have been frozen already | 10:41 |
| vila | knittl: it says: bzr 2.2-final has gone gold | 10:42 |
| vila | not rc nor beta anymore | 10:42 |
| knittl | yes. but current trunk is 2.3.0, isn't it? | 10:42 |
| vila | knittl: no, it's trunk but will become 2.3 in ~6 months | 10:42 |
| knittl | yeah. but it's not 2.2 | 10:44 |
| knittl | whatever, i'll have a look at the ppa as well | 10:44 |
| vila | knittl: indeed, it's not 2.2 and as such is not as stable as 2.2, my point is just to warn you about that. While bzr.dev have a few bug fixes/memory consumption optimizations, I don't think that's worth the risk for a comparison if this means you get a bad user experience (and hard to reproduce problems, trunks of bzr and plugins may change quickly especially just after a release) | 10:48 |
| vila | knittl: on the other hand, I'm not aware *today* of any problem in this area... | 10:49 |
| knittl | i'm not comparing usability | 10:49 |
| vila | knittl: ok, feel free to ask any questions anyway | 10:51 |
| knittl | i sure will. thx :) | 10:51 |
| === Guest96662 is now known as Leonidas | ||
| CcxCZ | how do I remove project from shared repository? | 11:06 |
| maxb | Do you mean branch, not project? | 11:08 |
| CcxCZ | yes | 11:09 |
| maxb | CcxCZ: You can just delete the branch from disk. Unfortunately there's no way to make bzr purge the data in the repository which is now unreferenced | 11:30 |
| === FryGuy_ is now known as FryGuy- | ||
| CcxCZ | so, the best way to clean shared repository is to make new one and re-branch all branches from the original one | 11:34 |
| maxb | If you really need the diskspace, yes | 11:42 |
| kiwinote | quick bzr question if anyone knows. I mistyped a branch name, hence merged with a non-existent branch, this didn't time out, so I ctrl+z'ed it. Now I get errors about the dirstate lock not being available. Ideas? | 11:56 |
| Glenjamin | hi guys | 11:57 |
| Glenjamin | is there any way to tell the merge command to ignore certain files? | 11:57 |
| CcxCZ | Glenjamin: you can use --interactive | 12:00 |
| Glenjamin | i was hoping for a middleground. I've got a branch which is going to be hanging around with a few changes from trunk - and i'd like be able to merge fiex back upstream without messing around a lot | 12:04 |
| Glenjamin | i guess merge -c is probably my best bet | 12:04 |
| guiQt | hi! how can i add files that are outside the working tree? | 13:08 |
| vila | guiQt: 'bzr add file' unless they are really *outside* of the working tree as in 'above the root of the wt' in which case, you can't | 13:12 |
| guiQt | but using bazaar explorer, i can't even see files outside the working tree... :-( | 13:15 |
| guiQt | that's the reason of my question | 13:15 |
| Glenjamin | guiQt: Under the working tree section, there's a drop down box to the left of "Filter:" | 13:20 |
| Glenjamin | what does it say? | 13:20 |
| guiQt | Unignored | 13:21 |
| CcxCZ | I think he really means outside the wt | 13:21 |
| Glenjamin | select "All" | 13:22 |
| Glenjamin | or "Unversioned" | 13:22 |
| guiQt | i have several project directories and a shared folder. they're all siblings. how can i add files belonging to shared folder? | 13:22 |
| Glenjamin | ah, i see | 13:22 |
| guiQt | yes, shared is above the root of each project | 13:23 |
| Glenjamin | then the previous answers were more accurate - you can't add files that are actually *outside* the working tree | 13:23 |
| guiQt | but what is the best strategy for such a case? | 13:23 |
| Glenjamin | i believe there's a feature called nested trees in development, that works in a broadly similar way to svn:externals - but i don't know how complete it is yet. | 13:24 |
| guiQt | i'm new to versioning systems and i supposed this pattern was frequent: several projects sharing common libraries | 13:26 |
| Glenjamin | yes, you'd normally version the common libraries separately | 13:27 |
| Glenjamin | and essentially treat them as their own project - which the other projects depend on | 13:27 |
| guiQt | so do i till now! | 13:27 |
| Glenjamin | which language are you using? | 13:27 |
| guiQt | c++ (qt) | 13:28 |
| Glenjamin | ah, i'm not really familiar with handling dependencies for C++ | 13:28 |
| CcxCZ | guiQt: what's the problem versioning it separately? | 13:29 |
| CcxCZ | with* | 13:30 |
| guiQt | when exporting the project | 13:31 |
| guiQt | i'd like to have all my files togheter | 13:31 |
| guiQt | not each project uses all shared files | 13:32 |
| guiQt | not a problem at all, only a matter of redundancy | 13:33 |
| CcxCZ | I'd write an export script for each project, exporting only necessary files | 13:33 |
| CcxCZ | if you mean export as in bzr export (without history) | 13:34 |
| guiQt | exactly | 13:34 |
| guiQt | ok | 13:35 |
| guiQt | thank you so much for the talk. see you again. ;-) | 13:35 |
| CcxCZ | glad to help :-) | 13:36 |
| === Noldorin_ is now known as Noldorin | ||
| vila | mgz: pong | 14:02 |
| stub | [Errno 11] Resource temporarily unavailable | 14:17 |
| stub | http://paste.ubuntu.com/483956/ | 14:18 |
| stub | Known issue with the new bzr from the PPA, or pebkac? | 14:18 |
| stub | pebkac | 14:19 |
| stub | So that error can mean 'disk full' | 14:20 |
| stub | Freed disk and it is still stuck. | 14:25 |
| stub | hulp | 14:26 |
| stub | sorted. another window had a 'bzr diff|less' open. | 14:28 |
| === JFo is now known as JFo-swap | ||
| chx | how can i make bzr resolve by accepting all THIS files as valid? | 15:52 |
| jelmer | chx, I think "bzr resolved --take-this" | 15:53 |
| chx | weird, bzr help resolved didnt list that option | 15:54 |
| james_w | resolve/resolved | 15:54 |
| chx | yeah that probably needs 2.2 | 15:55 |
| chx | i only have 2.1 | 15:55 |
| chx | i guess revert | 15:55 |
| james_w | revert . | 15:55 |
| james_w | without the dot it will forget you merged as well, which you don't want | 15:55 |
| === zyga is now known as zyga-dinner | ||
| === zyga-dinner is now known as zyga | ||
| mgz | vila: still around? | 17:01 |
| vila | mgz: not for long | 17:03 |
| mgz | well, I'm yours till you need to be gone. | 17:04 |
| vila | hehe | 17:04 |
| vila | you pinged me .. yesterday ? | 17:05 |
| mgz | ah, yeah, two things about my current mp, probably should have just posted there | 17:05 |
| mgz | 1) can I have your output with 2000 complaining tests, because I don't get nearly that many (and don't think I skip that much either) | 17:06 |
| mgz | 2) how is bb.test_log fixable just with addCleanup? | 17:06 |
| vila | hmm, I'll need to re-run that | 17:06 |
| mgz | also, if you need any of my results for your leak branch, I've got the full thing | 17:07 |
| vila | I don't clearly see where the cycle is, but you should be able to break it in an addCleanup | 17:07 |
| vila | if only by deleting the offending attribute | 17:08 |
| vila | or setting it to None | 17:08 |
| mgz | right, that doesn't work, because it's on the closure over the instance | 17:08 |
| mgz | you can't do much with cell objects. | 17:09 |
| mgz | and they're not terribly easy to get hold of. | 17:09 |
| vila | waitaminute | 17:10 |
| mgz | there might be some locals poking trick, but not one I know about. | 17:10 |
| vila | rhaa, what's wrong with lp ? I had all sort of random font sizes problems :-/ | 17:10 |
| mgz | they've changed some css, I see | 17:11 |
| mgz | might have caused your browser confusion | 17:11 |
| === beuno is now known as beuno-lunch | ||
| vila | so, for log, isn't it enough to self.log_catcher = None ? | 17:12 |
| vila | mgz: after reverting your patch of course | 17:13 |
| mgz | nope, and I tested that just to be sure. | 17:13 |
| vila | or del it | 17:13 |
| mgz | (well, to be exact, | 17:13 |
| mgz | + self.addCleanup(setattr, self, "log_catcher", None) | 17:13 |
| mgz | ) | 17:13 |
| vila | hmm, does the cleanup lambda keep a reference to self in that case ? | 17:14 |
| === chx_ is now known as chx | ||
| lamont | I rather suspect that bug 249452 in ubuntu was resolved some time ago | 17:16 |
| ubot5 | Launchpad bug 249452 in bzr (Ubuntu) "bzr overrides the shell prompt settings (affected: 0, heat: 17)" [Undecided,Confirmed] https://launchpad.net/bugs/249452 | 17:16 |
| jelmer | lamont, did you see poolie's last comment on that bug? | 17:19 |
| lamont | yeah, it's fix released in Bazaar, but still open in ubuntu, I'm guessing it never actually made it out as part of 1.6? | 17:20 |
| lamont | mostly I didn't want to track down what version it was fixed in for ubuntu | 17:20 |
| mgz | vila: because the cycle is between the cell and the instance | 17:20 |
| mgz | not the attribute. | 17:21 |
| vila | mgz: ha, looking at the source instead of the mp... | 17:21 |
| vila | what do you call the 'cell' ? | 17:21 |
| mgz | it's the little object python creates for closures to store the outer variables | 17:21 |
| * mgz is actually a little shaky on these internal details... | 17:21 | |
| vila | mgz: so you need to delete the closure | 17:21 |
| vila | or step back and re-think the approach taken in def getme(branch) | 17:22 |
| mgz | okay, here's a minimal case, what's the right cleanup to add? | 17:22 |
| vila | hack in hijacking == True :) | 17:22 |
| mgz | http://float.endofinternet.org/bazaar/simple/weakcycle/weakcycle.py | 17:24 |
| mgz | the refs and weakref stuff is just to see what's happening, all that's needed is the closure for the cycle. | 17:24 |
| vila | del inner ? | 17:25 |
| mgz | try it and see :) | 17:25 |
| mgz | wait, did I screw that test up.. | 17:26 |
| * mgz tries being less lame | 17:26 | |
| mgz | need the bzr TestSuite | 17:27 |
| vila | with or without inner defined I get the same result | 17:28 |
| mgz | yeah, I minimised too much without checking the negative result | 17:28 |
| mgz | fixing... | 17:28 |
| vila | mgz: I remember why I did that I think: I needed to get the right LogFormatter object but the registry is a factory so I had to define __new__ to capture the object creation | 17:31 |
| vila | there may be alternatives that doesn't involve cycles, but I'm still unsure about the whole cycle elements | 17:32 |
| mgz | yeah, the way the test is written currently is explainable | 17:32 |
| mgz | okay, so, just deleting something *should* work | 17:33 |
| mgz | but... log_catcher isn't sufficent. | 17:34 |
| vila | mgz: as long as it's part of the cycle, yes, that's the idea | 17:34 |
| vila | so, what constitute this cycle | 17:34 |
| vila | mgz: so may be del MyLogFormatter ? | 17:35 |
| === Ursinha is now known as Ursinha-lunch | ||
| mgz | no, that's just the type, not involved | 17:35 |
| vila | or MyLogFormatter.__new__ = None | 17:35 |
| * mgz unshelves his debugging function | 17:35 | |
| vila | well, __new__ reference self (the test instance) | 17:35 |
| === deryck is now known as deryck[lunch] | ||
| vila | mgz: I'll be passing around only for the next hours but will be available if needed around 21h00 my time (in ~3 hours), ack ? | 17:39 |
| mgz | yeah, I'll dig a little more, thanks for the help. | 17:40 |
| vila | ok | 17:41 |
| mgz | okay, I understand now | 17:48 |
| mgz | it *is* the __new__ that's the issue, because it's (implicitly) a staticmethod | 17:49 |
| === gorozco is now known as p4tux | ||
| vila | mgz: that was my last suggestion, yes, so it should stay defined as long as the... test class is defined ? Ouch | 18:01 |
| vila | there is still one bit I don't remember (or may be I didn't understand it either at the time): why defining __init__ isn't enough ? | 18:02 |
| vila | mgz: maybe overriding b.log.LogFormatterRegistry.make_formatter can work around the problem... | 18:04 |
| * vila off again | 18:04 | |
| === beuno-lunch is now known as beuno | ||
| === Ursinha-lunch is now known as Ursinha | ||
| lamont | bzrlib/_dirstate_helpers_pyx.c:9002: warning: dereferencing type-punned pointer will break strict-aliasing rules | 18:18 |
| lamont | nice. only not. | 18:18 |
| === deryck[lunch] is now known as deryck | ||
| glen | does bzr have such concept as "tag", how do i add tag to a project, say "2.3", and how do i check if such tag already exists? | 18:53 |
| mkanat | glen: bzr tag | 18:54 |
| mkanat | glen: and "bzr tags" to see existing ones. | 18:54 |
| glen | thanks a bunch! | 18:54 |
| mkanat | glen: You probably don't want to tag something just like "2.3" because tags merge across branches. | 18:54 |
| mkanat | glen: So you probably want something like myproject-2.3 | 18:54 |
| glen | i.e it can't start with a number? | 18:55 |
| mkanat | glen: It *can*, I just wouldn't recommend it. | 18:55 |
| glen | anyway, i see project already has tag set: "release-2.3-final 4132" | 18:55 |
| mkanat | glen: Also, you could have a revision number "2.3", which means you'd have to explicitly do -r tag:2.3 instead of just being able to do -r 2.3 | 18:55 |
| mkanat | glen: Okay. :-) | 18:56 |
| vila | mgz: ping, are there any updates on your mps for testtools or bzr that I should pull before re-running for the 2000 ? | 19:36 |
| rocky | don't suppose any setuptools_bzr contributors hang out here? having a problem with setuptools_bzr 2.0 and bzr 2.0 | 19:56 |
| rocky | er... bzr 2.2.0 | 19:56 |
| mgz | vila: no, just as is would be great | 20:13 |
| vila | hmpf, massive maverick update | 20:16 |
| vila | 192 packages, 230MB will be downloaded :) | 20:16 |
| vila | hmm, nice colored ascii screen, makes me feel younger :) I prefer the graphic version though, especially when running X... | 20:26 |
| vila | at least a reboot fixed it :-/ | 20:27 |
| vila | mgz: hmm, ran 4 tests... again ? See http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/3/console | 20:40 |
| * mgz looks | 20:40 | |
| vila | mgz: did I use the wrong branch ? | 20:40 |
| mgz | is that on 2.7 as per the name? | 20:41 |
| vila | yup | 20:41 |
| mgz | it doesn't need to be... | 20:42 |
| mgz | also, I've not done anything to fix --parallel=fork | 20:42 |
| mgz | (yet) | 20:42 |
| vila | doesn't need 2.7 ??? Where did I get this belief then ? | 20:43 |
| vila | running without --parallel at http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/4 | 20:44 |
| mgz | it's probably based on the branch for fixing selftest on 2.7 as that changed a bunch of things that would conflict. | 20:44 |
| mgz | that's looking good, thanks vila | 20:45 |
| vila | mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :) | 20:46 |
| mgz | hmpf, that's still getting junk in the output | 20:46 |
| mgz | ...is that what your link is saying too? | 20:47 |
| vila | for skipped tests | 20:47 |
| mgz | it's still 2.7... that needs tracking down, I'll file a bug already. | 20:47 |
| mgz | this is really only a 2.7 thing, right? doesn't appear on any of your other bots. | 20:49 |
| vila | mgz: I've setup a dedicated job on babune (it should pull from the bzr branch but not the testtools one though), so it will be easier to re-run or tweak | 20:49 |
| mgz | great, thanks. | 20:49 |
| vila | I've setup a maverick slave and add the adequate ppa so py27 is the default | 20:49 |
| vila | but the ppa lacks pyrex so far | 20:50 |
| mgz | I think I'll file against subunit because I've failed at seeing anything wrong in bzr or testtools | 20:50 |
| mgz | can always get moved later. | 20:50 |
| vila | mgz: if you read the begining of the log, I've added some commands to display what is used | 20:50 |
| vila | mgz: I've created a new view to track this kind of jobs: http://babune.ladeuil.net:24842/view/debug/ | 20:54 |
| mgz | this skipped printing-of-random-details-member thing doesn't actually look fatal | 20:58 |
| mgz | so, it might be a seperate bug that's causing the xml parser to fail on the subunit output later | 20:58 |
| mgz | that run looks wedged. is that going to be my fault or a known issue? | 21:15 |
| vila | mgz: no idea | 21:19 |
| vila | mgz: rather, no known cause for hanging runs on mo.... no space left on device :-) | 21:19 |
| mgz | wait, now it's progressing | 21:19 |
| mgz | er... well | 21:19 |
| mgz | IOError: [Errno 28] No space left on device | 21:19 |
| * mgz bows to vila | 21:20 | |
| mgz | and man that 2.7 logging change is obnoxious | 21:20 |
| vila | meh, no idea what obnoxious means here ;) | 21:21 |
| mgz | the log ends with thousands of tracebacks from the logging module | 21:21 |
| vila | looks like tmp is full | 21:21 |
| mgz | which isn't nice, or useful. | 21:22 |
| vila | there is 1GB log file there | 21:22 |
| vila | WARNING listening socket error: [Errno 24] Too many open files | 21:22 |
| vila | mwahahahahaha | 21:22 |
| * vila bangs head on desk | 21:23 | |
| vila | also known as leaking tests fills up my OSX disk :-( | 21:23 |
| mgz | well, at least we're progressing on several fronts, even if it's a pain. | 21:24 |
| vila | I don't want to start saying: I've told you.... | 21:24 |
| cody-somerville | why does bzr launchpad-login try to fetch the +sshkeys page from launchpad for the user? | 21:24 |
| vila | but I've been repeating for ages that the leaking tests could blow up at any time... | 21:24 |
| vila | cody-somerville: to check that the user can login with one key registered on lp ? | 21:25 |
| lifeless | vila: oh hai | 21:25 |
| lifeless | and hi mgz | 21:25 |
| vila | lifeless: hey ! | 21:25 |
| mgz | hey lifeless. | 21:26 |
| mgz | before I get back to filing this against subunit for lack of better ideas, do you have any smart thoughts on why 2.7 only babune gets skipped [some random details member] in the output? | 21:26 |
| mgz | see vila's pastebin ^up there for an example | 21:27 |
| vila | mgz: so, either you fix --parallel or you wait for my leaking tests mp to land (or review it :-) | 21:27 |
| vila | mgz: s/only/on/ ? | 21:27 |
| mgz | well, I mean that it happens on 2.7 but apparently not 2.6 | 21:28 |
| mgz | ^okay, I'll look at parallel, presume that I can just override osutils.---thingy---concurrency to test | 21:28 |
| vila | BZR_CONCCURRENCY even | 21:28 |
| mgz | ah, I meant, as in, write a testcase, but yes | 21:29 |
| * vila EODing, have fun ! | 21:30 | |
| mgz | bye vila! | 21:30 |
| lifeless | well 2.7 added an official skip | 21:31 |
| lifeless | which pastebin ? | 21:31 |
| mgz | sorry, wrong keyword, | 21:32 |
| mgz | <vila> mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :) | 21:32 |
| mgz | those ones actually have the 'reason' detail, but others have the 'traceback' or 'log' | 21:33 |
| lifeless | whats wrong with it ? | 21:35 |
| mgz | it's weird, and we're not sure if it's related to the other things that go wrong with 2.7 like, the xml output not being well-formed | 21:36 |
| lifeless | it looks like parameterisation or something to me | 21:36 |
| lifeless | the reason you'd get logs and stuff, is if the skip is done late | 21:37 |
| lifeless | after test activity | 21:37 |
| lifeless | like I say | 21:37 |
| lifeless | 2.7 added skip support | 21:37 |
| lifeless | so I suspect an interaction with that | 21:37 |
| mgz | sounds likely, so, where should I be filing this? bzr? testtools? subunit? | 21:38 |
| lifeless | whereever the problem is ;) | 21:38 |
| mgz | ;_; | 21:38 |
| lifeless | I doubt subunit | 21:38 |
| lifeless | very very much | 21:38 |
| lifeless | maybe testtools, maybe bzr | 21:39 |
| mgz | okay, I'll have another look at testtools first. | 21:39 |
| lifeless | but | 21:39 |
| lifeless | dunno what the problem is | 21:39 |
| lifeless | so - I'd a) reproduce locally | 21:39 |
| lifeless | b) use the magic of greyskull^Wpdb | 21:40 |
| mgz | the log thing due to a later skip might help, I'll see if I can work out if there's a difference in the tests that have reason and those that have log | 21:40 |
| lifeless | they should still have a reason | 21:40 |
| lifeless | it will depend on the API they use | 21:40 |
| lifeless | if they call addSkip(test, foo) - then reason only | 21:40 |
| lifeless | if they call addSkip(test, details=...) | 21:41 |
| lifeless | then you'll get log + reason + other stuff | 21:41 |
| mgz | getting that out the way will hopefully make tracking down the actual broken output and other weirdness easier | 21:41 |
| mgz | another one I saw was a x6 paramatised test that failed, | 21:42 |
| mgz | getting traceback-0 through -5 | 21:42 |
| lifeless | thats bogus | 21:42 |
| mgz | as each one failed. | 21:42 |
| lifeless | 6 tracebacks would make sense for a server test where multiple threads can die | 21:42 |
| mgz | that doesn't look like what this is: | 21:45 |
| mgz | right, but this was totally, straight up, adding the | 21:45 |
| mgz | gra. | 21:45 |
| mgz | wrong paste | 21:45 |
| mgz | this: | 21:45 |
| mgz | http://float.endofinternet.org/temp/babune_log_extract.txt | 21:45 |
| mgz | first fail has traceback. second has traceback, traceback-1, third has traceback, traceback-1, traceback-2... etc | 21:46 |
| lifeless | perhaps something is gone fucked up with test parameterisation | 21:46 |
| lifeless | like sharing object state or something | 21:46 |
| mgz | seems likely. | 21:46 |
| mgz | might just be that test case class then? | 21:46 |
| lifeless | well | 21:47 |
| lifeless | the tracebacks are stored in self._details | 21:47 |
| lifeless | if that dict were initialised before parameterisation | 21:47 |
| lifeless | and shallow copied | 21:47 |
| lifeless | (which I think we do, for various reasons) | 21:47 |
| lifeless | [the shallow copying we do] | 21:47 |
| lifeless | and indeed | 21:48 |
| mgz | okay, food for me now, I'll make a list of these things and file bugs so that the ones I can't work out myself don't get lost. | 21:48 |
| lifeless | TestCase.__init__ sets self.__details | 21:48 |
| lifeless | so if we're shallow copying we'll be sharing details | 21:48 |
| lifeless | and cleanups | 21:48 |
| lifeless | and other fun stuff | 21:48 |
| lifeless | and clone_with_new_id uses copy.copy | 21:49 |
| lifeless | need to check what bzr uses | 21:49 |
| lifeless | copy.copy | 21:49 |
| lifeless | so, thats why | 21:49 |
| lifeless | grah fuckers. | 21:49 |
| mgz | okay, so that's something seperate and fixable at least. | 21:50 |
| lifeless | probably by implementing the copy hook for TestCase | 21:59 |
| lifeless | I don't know what I was thinking | 21:59 |
| james_w | hey lifeless | 22:01 |
| james_w | lifeless: is testing with different imports a use case for testscenarios? We may want to test against built in json and simplejson using it if possible. | 22:02 |
| lifeless | james_w: yes you could use it for that | 22:10 |
| lifeless | if you pass in the module to your tests - ('json': {'implementation':__import__('json')]), ('simplejson': {'implementation':__import__('simplejson')]) | 22:10 |
| lifeless | if you pass in the module to your tests - ('json': {'implementation':__import__('json')]), ('simplejson': {'implementation':__import__('simplejson')]) | 22:10 |
| james_w | lifeless: ok, thanks, I'll pass that on | 22:11 |
| lifeless | james_w: if the module is implicit state in your environment its a bit trickier | 22:11 |
| lifeless | I'd probably use a Fixture + scenarios then | 22:11 |
| lifeless | and have the setup reimport the right thing for you | 22:12 |
| lifeless | and the cleanup replace the original | 22:12 |
| james_w | lifeless: generally it as as the code under test will usually do something like "import json; except ImportError: import simplejson as json" | 22:12 |
| lifeless | so, I'd be tempted to have a local module | 22:13 |
| lifeless | json_impl | 22:13 |
| lifeless | which does from json import * / from simplejson import * | 22:13 |
| james_w | he has one of those actually | 22:13 |
| lifeless | then replacing just it at runtime is reasonable clean | 22:14 |
| james_w | lifeless: replacing in terms of mucking about with sys.modules? | 22:15 |
| * james_w has never got that involved in import machinery | 22:15 | |
| lifeless | well | 22:16 |
| lifeless | so lets say there is module A | 22:16 |
| lifeless | which does 'import json_impl as json' | 22:16 |
| lifeless | that means that you have the name json bound to the module currently in sys.modules | 22:16 |
| lifeless | you have two places you can muck around with | 22:17 |
| lifeless | the bound name - rebind it to a new json_impl (e.g. directly to simplejson), or | 22:17 |
| lifeless | the module - change its contents (but not the module object itself) | 22:17 |
| lifeless | def change_impl(impl): | 22:18 |
| lifeless | for name in dir(impl): | 22:18 |
| lifeless | globals()[name] = getattr(impl, name) | 22:18 |
| lifeless | if that existing in json_impl | 22:18 |
| lifeless | existed | 22:18 |
| lifeless | you could call | 22:18 |
| lifeless | json_impl.change_impl(simplejson) | 22:18 |
| lifeless | et voila | 22:19 |
| james_w | gotcha, thanks | 22:19 |
| lifeless | if there are many A's, then mucking with the module contents is easier. | 22:19 |
| lifeless | if there is one A, changing the name binding is easier. | 22:19 |
| james_w | we may just support one implementation instead, but it's good to know we have this to ensure that both work if we choose to support both | 22:20 |
| lifeless | fairynuff | 22:21 |
| lifeless | what are you working on ? | 22:21 |
| james_w | lifeless: the launch-control project with Zygmunt that I think you know a bit about. | 22:46 |
| ovnicraft | hi folks i want to update my repo at N revno is posible this with bzxr pull revno? | 23:06 |
| ovnicraft | bzr* | 23:08 |
| lifeless | james_w: I'm not sure I do know that one :) | 23:22 |
| james_w | lifeless: a QA dashboard type thing, with automated test results against images | 23:29 |
| ovnicraft | is posible what i want to do? | 23:30 |
| lifeless | james_w: nice | 23:32 |
| beuno | ovnicraft, yes, bzr pull -r REVNO | 23:32 |
| ovnicraft | beuno, now if i pull without and -r options and i want to back in revno its posible? | 23:34 |
| beuno | ovnicraft, sure, you can "bzr revert -r REVNO | 23:36 |
| ovnicraft | beuno, the revert changes are left as uncommited code? | 23:42 |
| ovnicraft | revert works fine but when bzr revno show me the latest | 23:44 |
| maxb | ovnicraft: Hi, could you restate what exact effect you want to acheive? | 23:45 |
| ovnicraft | revno at my revert -r REVNO | 23:46 |
| ovnicraft | maxb, changes as uncommited can be logic | 23:46 |
| maxb | 'bzr revert -r X' sets the *content* of the tree to that of revision X, but does not change the tree's idea of what revision it is based on. | 23:46 |
| maxb | If you want to briefly inspect a previous revision, you probably want 'bzr update -r X' (only fully added in 2.2) | 23:47 |
| dev001 | When I 'bzr pull' latest source, I get: Using saved parent location: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/; /usr/lib64/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken | 23:50 |
| dev001 | Is this a python issue, or a bzr prob? the provided link is broken ... | 23:50 |
| ovnicraft | maxb, i tried bzr update -r X with 2.1.1 | 23:51 |
| fullermd | dev001: It's paramiko fighting with pycrypto. | 23:52 |
| dev001 | fullermd: gesundheit!! ;-) | 23:53 |
| dev001 | so, which do I fix? | 23:53 |
| fullermd | Well, since pycrypto defines its API, paramiko by definition is the broken one. | 23:54 |
| fullermd | Back at the beginning of the year when the new pycrypto came out and started throwing errors, I just uninstalled paramiko, figuring it might take a few weeks for a fix. | 23:55 |
| fullermd | 'course, that was in January... | 23:55 |
| * dev001 digs around, trying to figure out wtf I need paramiko for ... | 23:56 | |
| fullermd | ssh/sftp, if it's not using a system-installed (e.g. openssh) | 23:57 |
| fullermd | Still doesn't seem to be a patch in paramiko git :| | 23:57 |
| dev001 | fullermd: beat me to it ... just found the git, and was looking | 23:57 |
| fullermd | There's an issue filed for it on github frmo a while back too, with no comments. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!