[00:29] <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:30] <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.
[06:16] <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:17] <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:18] <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:20] <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:25] <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:26] <spiv> jtv: which version of bzr?
[06:26] <lifeless> spiv: not going to roll forward ? or is there no .new file ?
[06:27] <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:28] <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:29] <spiv> Yep
[06:31] <jtv> Well, that's done.
[06:32] <jtv> And it seems to be working!  Yay!
[06:32] <jtv> Thanks spiv, thanks lifeless  :-)
[06:33] <spiv> jtv: Now the only question is what caused it :/
[06:34] <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:48] <wgrant> jtv: It hasn't done that for a long time for me.
[06:48] <wgrant> Since maybe May.
[06:54] <spiv> wgrant: that's roughly when jam's fixes landed, IIRC
[06:55] <jtv> this is about the fs corruption I think, not the repo trouble
[06:55] <wgrant> FS corruption, yes.
[06:56] <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:57] <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:58] <spiv> (Perhaps utilities/update-sourcecode needs to be updated to call bzrlib.initialize()?)
[07:22] <vila> hi all !
[07:26] <vila> spiv: any chance you can review my looms tomorrow ? You did notice you are the pp this week :-D ?
[07:35] <vila> mgz: pong
[07:39] <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:40] <spiv> vila: yeah, I'll review
[07:41] <vila> yeah !
[07:41] <spiv> vila: interesting... I wonder if bigkevmcd had a crash as well?
[07:41] <vila> spiv: yeah, a reboot
[07:42] <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:43] <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:44] <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:49] <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:50] <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:51] <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:52] <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:53] <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:55] <vila> eerk, ordered is the default :-/ not journal
[07:55]  * vila revises its beliefs :(
[07:56] <vila> so the fs is not corrupted... I'm so glad :(
[07:57] <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:59] <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
[08:00] <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:01] <spiv> vila: also, see the auto_da_alloc option described at that URL
[08:03] <vila> spiv: and we don't use fsync right ?
[08:05] <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:06] <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:11] <vila> All I want is my rug back !
[09:19] <CcxCZ> hi, I have question about repository layout/workflow, can anyone advise?
[09:22] <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:27] <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:28] <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:30] <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:31] <CcxCZ> :[
[09:31] <CcxCZ> vila: thanks for info
[09:32] <vila> CcxCZ: depending on the volume of shared files and changes, there are some ways to address your need today but nothing trivial :-/
[09:34] <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:35] <vila> spiv: stop doing things behind callgrind back !
[09:37] <spiv> vila: I didn't think I was!
[10:03] <CcxCZ> what's best tool to migrate from svn?
[10:09] <vila> CcxCZ: bzr-svn allows you to work with bzr while still connecting to an svn server
[10:10] <maxb> I think in most cases, bzr-svn is also the best tool for a one-shot migration
[10:15] <CcxCZ> I think it required some specific repository format which was bothersome
[10:15] <CcxCZ> I'm going to try svn2bzr.py now
[10:19] <knittl> where can i find docs on compiling bazaar?
[10:20] <knittl> bzrlib/_static_tuple_c.c:35: fatal error: _simple_set_pyx_api.h: No such file or directory
[10:21] <jelmer> CcxCZ, it only requires a specific repository format if you're using bzr < 2.0
[10:22] <jelmer> (which you probably should not anyway..)
[10:25] <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:26] <knittl> i might be missing pyrex
[10:26] <knittl> what's the package's name in ubuntu?
[10:27] <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:28] <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:30] <knittl> what is setup.py used for then?
[10:31] <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:32] <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:33] <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:34] <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:35] <vila> knittl: if you really really want to install, then yes, run setup.py
[10:35] <knittl> there we go …
[10:36] <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:37] <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:38] <maxb> I can understand wanting to check out how difficult a self-build is, to not be beholden on packagers
[10:39] <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:40] <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:41] <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:42] <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:44] <knittl> yeah. but it's not 2.2
[10:44] <knittl> whatever, i'll have a look at the ppa as well
[10:48] <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:49] <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:51] <vila> knittl: ok, feel free to ask any questions anyway
[10:51] <knittl> i sure will. thx :)
[11:06] <CcxCZ> how do I remove project from shared repository?
[11:08] <maxb> Do you mean branch, not project?
[11:09] <CcxCZ> yes
[11:30] <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:34] <CcxCZ> so, the best way to clean shared repository is to make new one and re-branch all branches from the original one
[11:42] <maxb> If you really need the diskspace, yes
[11:56] <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:57] <Glenjamin> hi guys
[11:57] <Glenjamin> is there any way to tell the merge command to ignore certain files?
[12:00] <CcxCZ> Glenjamin: you can use --interactive
[12:04] <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
[13:08] <guiQt> hi! how can i add files that are outside the working tree?
[13:12] <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:15] <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:20] <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:21] <guiQt> Unignored
[13:21] <CcxCZ> I think he really means outside the wt
[13:22] <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:23] <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:24] <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:26] <guiQt> i'm new to versioning systems and i supposed this pattern was frequent: several projects sharing common libraries
[13:27] <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:28] <guiQt> c++ (qt)
[13:28] <Glenjamin> ah, i'm not really familiar with handling dependencies for C++
[13:29] <CcxCZ> guiQt: what's the problem versioning it separately?
[13:30] <CcxCZ> with*
[13:31] <guiQt> when exporting the project
[13:31] <guiQt> i'd like to have all my files togheter
[13:32] <guiQt> not each project uses all shared files
[13:33] <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:34] <CcxCZ> if you mean export as in bzr export (without history)
[13:34] <guiQt> exactly
[13:35] <guiQt> ok
[13:35] <guiQt> thank you so much for the talk. see you again. ;-)
[13:36] <CcxCZ> glad to help :-)
[14:02] <vila> mgz: pong
[14:17] <stub> [Errno 11] Resource temporarily unavailable
[14:18] <stub> http://paste.ubuntu.com/483956/
[14:18] <stub> Known issue with the new bzr from the PPA, or pebkac?
[14:19] <stub> pebkac
[14:20] <stub> So that error can mean 'disk full'
[14:25] <stub> Freed disk and it is still stuck.
[14:26] <stub> hulp
[14:28] <stub> sorted. another window had a 'bzr diff|less' open.
[15:52] <chx> how can i make bzr resolve by accepting all THIS files as valid?
[15:53] <jelmer> chx, I think "bzr resolved --take-this"
[15:54] <chx> weird, bzr help resolved didnt list that option
[15:54] <james_w> resolve/resolved
[15:55] <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
[17:01] <mgz> vila: still around?
[17:03] <vila> mgz: not for long
[17:04] <mgz> well, I'm yours till you need to be gone.
[17:04] <vila> hehe
[17:05] <vila> you pinged me .. yesterday ?
[17:05] <mgz> ah, yeah, two things about my current mp, probably should have just posted there
[17:06] <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:07] <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:08] <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:09] <mgz> you can't do much with cell objects.
[17:09] <mgz> and they're not terribly easy to get hold of.
[17:10] <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:11] <mgz> they've changed some css, I see
[17:11] <mgz> might have caused your browser confusion
[17:12] <vila> so, for log, isn't it enough to self.log_catcher = None ?
[17:13] <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:14] <vila> hmm, does the cleanup lambda keep a reference to self in that case ?
[17:16] <lamont> I rather suspect that bug 249452 in ubuntu was resolved some time ago
[17:19] <jelmer> lamont, did you see poolie's last comment on that bug?
[17:20] <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:21] <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:22] <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:24] <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:25] <vila> del inner ?
[17:25] <mgz> try it and see :)
[17:26] <mgz> wait, did I screw that test up..
[17:26]  * mgz tries being less lame
[17:27] <mgz> need the bzr TestSuite
[17:28] <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:31] <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:32] <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:33] <mgz> okay, so, just deleting something *should* work
[17:34] <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:35] <vila> mgz: so may be del MyLogFormatter ?
[17:35] <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:39] <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:40] <mgz> yeah, I'll dig a little more, thanks for the help.
[17:41] <vila> ok
[17:48] <mgz> okay, I understand now
[17:49] <mgz> it *is* the __new__ that's the issue, because it's (implicitly) a staticmethod
[18:01] <vila> mgz: that was my last suggestion, yes, so it should stay defined as long as the... test class is defined ? Ouch
[18:02] <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:04] <vila> mgz: maybe overriding b.log.LogFormatterRegistry.make_formatter can work around the problem...
[18:04]  * vila off again
[18:18] <lamont> bzrlib/_dirstate_helpers_pyx.c:9002: warning: dereferencing type-punned pointer will break strict-aliasing rules
[18:18] <lamont> nice.  only not.
[18:53] <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:54] <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:55] <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:56] <mkanat> glen: Okay. :-)
[19:36] <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:56] <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
[20:13] <mgz> vila: no, just as is would be great
[20:16] <vila> hmpf, massive maverick update
[20:16] <vila> 192 packages, 230MB will be downloaded :)
[20:26] <vila> hmm, nice colored ascii screen, makes me feel younger :) I prefer the graphic version though, especially when running X...
[20:27] <vila> at least a reboot fixed it :-/
[20:40] <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:41] <mgz> is that on 2.7 as per the name?
[20:41] <vila> yup
[20:42] <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:43] <vila> doesn't need 2.7 ??? Where did I get this belief then ?
[20:44] <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:45] <mgz> that's looking good, thanks vila
[20:46] <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:47] <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:49] <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:50] <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:54] <vila> mgz: I've created a new view to track this kind of jobs: http://babune.ladeuil.net:24842/view/debug/
[20:58] <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
[21:15] <mgz> that run looks wedged. is that going to be my fault or a known issue?
[21:19] <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:20]  * mgz bows to vila
[21:20] <mgz> and man that 2.7 logging change is obnoxious
[21:21] <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:22] <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:23]  * vila bangs head on desk
[21:23] <vila> also known as leaking tests fills up my OSX disk :-(
[21:24] <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:25] <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:26] <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:27] <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:28] <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:29] <mgz> ah, I meant, as in, write a testcase, but yes
[21:30]  * vila EODing, have fun !
[21:30] <mgz> bye vila!
[21:31] <lifeless> well 2.7 added an official skip
[21:31] <lifeless> which pastebin ?
[21:32] <mgz> sorry, wrong keyword,
 mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :)
[21:33] <mgz> those ones actually have the 'reason' detail, but others have the 'traceback' or 'log'
[21:35] <lifeless> whats wrong with it ?
[21:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <mgz> okay, so that's something seperate and fixable at least.
[21:59] <lifeless> probably by implementing the copy hook for TestCase
[21:59] <lifeless> I don't know what I was thinking
[22:01] <james_w> hey lifeless
[22:02] <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:10] <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:11] <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:12] <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:13] <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:14] <lifeless> then replacing just it at runtime is reasonable clean
[22:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <lifeless> fairynuff
[22:21] <lifeless> what are you working on ?
[22:46] <james_w> lifeless: the launch-control project with Zygmunt that I think you know a bit about.
[23:06] <ovnicraft> hi folks i want to update my repo at N revno is posible this with bzxr pull revno?
[23:08] <ovnicraft> bzr*
[23:22] <lifeless> james_w: I'm not sure I do know that one :)
[23:29] <james_w> lifeless: a QA dashboard type thing, with automated test results against images
[23:30] <ovnicraft> is posible what i want to do?
[23:32] <lifeless> james_w: nice
[23:32] <beuno> ovnicraft, yes, bzr pull -r REVNO
[23:34] <ovnicraft> beuno, now if i pull without and -r options and i want to back in revno its posible?
[23:36] <beuno> ovnicraft, sure, you can "bzr revert -r REVNO
[23:42] <ovnicraft> beuno, the revert changes are left as uncommited code?
[23:44] <ovnicraft> revert works fine but when bzr revno show me the latest
[23:45] <maxb> ovnicraft: Hi, could you restate what exact effect you want to acheive?
[23:46] <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:47] <maxb> If you want to briefly inspect a previous revision, you probably want 'bzr update -r X' (only fully added in 2.2)
[23:50] <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:51] <ovnicraft> maxb, i tried bzr update -r X with 2.1.1
[23:52] <fullermd> dev001: It's paramiko fighting with pycrypto.
[23:53] <dev001> fullermd: gesundheit!! ;-)
[23:53] <dev001> so, which do I fix?
[23:54] <fullermd> Well, since pycrypto defines its API, paramiko by definition is the broken one.
[23:55] <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:56]  * dev001 digs around, trying to figure out wtf I need paramiko for ...
[23:57] <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:58] <fullermd> There's an issue filed for it on github frmo a while back too, with no comments.