[00:08] <poolie> hi all
[00:09] <mgz> hey poolie.
[00:09] <poolie> hi there
[00:25] <mgz> poolie: what do you want done with the Ubuntu bits of theses new exciting bugs you've made public? jam suggested closing them after opening an upstream task, but I'm not sure I have perms to do that.
[00:26] <poolie> mgz i don't know
[00:26] <mgz> ...where 'bits -> 'bug task'
[00:26] <poolie> hm
[00:26]  * mgz needs to clearer
[00:26] <poolie> i guessed
[00:27] <poolie> in some ways, if they are not going to be *specifically* fixed in upstream
[00:27] <poolie> they should be 'wontfix'
[00:27] <poolie> but, that sounds a bit negative to the reporter perhaps
[00:27] <poolie> you could just make them mirror the upstream tasks?
[00:28] <maxb> Wouldn't it make sense to leave the Ubuntu tasks open, until we eventually close them via LP: #nnnnn in debian/changelog ?
[00:28] <poolie> mm that could be good
[00:29] <poolie> in that case then triaged or confirmed, and matching importance
[00:29] <mgz> well, that's like the 'fix released' issue poolie posted about the other day.
[00:29] <mgz> unless there's some automation there already?
[00:30] <maxb> Well, for Ubuntu package tasks, there's an automated robot which closes bugtasks from debian/changelog uploads
[00:31] <mgz> how does it get in the changelog though?
[00:31] <poolie> manually i think
[00:32] <poolie> well, perhaps for a new major release there could, or perhaps is, a script to gather it?
[00:32] <dchilton> Hi I just launched a series of lp:whatever updates with bazaar @ a bunch of different machines ... everyone's returning: "ssh: connect to host bazaar.launchpad.net port 22: No route to host".  Is anyone else seeing anything?  Not sure if there's a status page to check ...
[00:33] <mgz> I got that just now, branched locally instead, launchpad likes midnight updates.
[00:35] <dchilton> mgz: ah, didn't realize launchpad's in Europe ...
[00:35] <mgz> http://identi.ca/launchpadstatus/ <- doesn't look planned this time.
[00:35] <dchilton> mgz: a status page!  evern better, thx!
[00:37] <dchilton> good excuse to go get a beer early ... thx!
[00:40] <mgz> and I need to sleep, will have to do mps tomorrow.
[00:50] <poolie> sleep well
[00:58] <mgz> ...fell into the just one more bug trap. now I'm really going. :)
[01:01] <spiv> Good morning.
[01:04] <poolie> haha
[01:04] <poolie> hi spiv!
[01:26]  * spiv blinks
[01:26] <spiv> mutt crashed.  That's new!
[01:27] <bob2> heh, it reliably crashes every night for me while doing imap idle
[01:28] <spiv> I use offlineimap to handle the actual imap
[01:30] <spiv> I'm not sure I really want to send a 1.7GB apport report though!
[01:32] <spiv> I'm rather impressed than an 8MB crash file can apparently expand that much…
[01:33] <spiv> Ah, no, apport's GUI is just lying to me.
[04:22] <AfC> jelmer: Doubt you noticed in the avalanche of bugmail, but regarding the problem pulling from GNOME git trying to clone GTK, I discovered
[04:22] <AfC> jelmer: that you can duplicate with the public (anonymous [sic]) git:// URL as well as the git+ssh:// one. So with any luck you might be able to duplicate the crash I'm experiencing
[04:23] <AfC> jelmer: [all on the bugs are bad but encountering someone else's reproducible bug might find something deeper that does matter]
[04:45] <poolie> spiv do you use tribunal or subunit on pqm failures?
[04:45] <poolie> tribunal seems to not be coping with them recently
[04:45] <poolie> just started digging into it before lunch
[04:47] <poolie> nm, stupid bug
[05:05] <poolie> spiv i'm going to backport the importwarning fix to 2.1, 2.2 and 2.3
[05:05] <poolie> it seems necessary to land anything on those branches in lucid
[05:05] <poolie> that code didn't exist in 2.0
[05:05] <poolie> do you see any risks?
[05:17] <poolie> sent anyhow
[05:37] <spiv> poolie: sorry, was out for a bit over lunch.  The importwarning fix seems ok... oh, but is it in 2.4?
[05:37] <spiv> poolie: Hmm, no, docs say ImportWarning is new in 2.5
[05:38] <spiv> poolie: I don't use tribunal for that, partly because I happily don't get too many failures back from PQM, and partly because it just doesn't work quite well enough :/
[05:38] <poolie> :/
[05:39] <spiv> Subunit streams seem a bit fragile, so it seems like half the time I have to try random filtering options to use them.
[05:39] <poolie> that is true
[05:39] <poolie> there was an embarassing total-failure bug in trunk, the presence of which indicates not that many people are using it
[05:39] <poolie> which is fine
[05:39] <poolie> anyhow, if you hit stuff that's not stream fragility, let me know
[05:39] <spiv> But also each time I use tribunal I get itchy to make it better, rather than work on what I was originally doing :)
[05:39] <spiv> It's been a while since I've tried though
[05:39] <poolie> yeah
[05:40] <poolie> that actually puts me off using it :)
[05:40] <poolie> too many yaks
[05:40] <poolie> in this case i did though
[05:40] <poolie> i might fix bug 760387 now though
[05:40] <poolie> how is the pack code?
[05:47] <spiv> Fairly good.  I've mostly extracted out the state and logic I wanted to extract into its own class, although it's still a bit more bound up with the original class than I'd like
[05:48] <spiv> I've got some basic tests using that, and I'm about to start writing tests for the edge cases that brought me here in the first place.
[06:36] <poolie> lifeless: hi, just quickly, can you tell me what if any special expectations pqm has for subunit support?
[06:36] <poolie> does it look for a selftest.log file?
[06:36] <lifeless> no, it parses stdout
[06:36] <poolie> or does it just expect that stdout might be a stream?
[06:36] <poolie> that's all?
[06:36] <lifeless> yup thats it
[06:40] <poolie> do you recall what it is that generates the summary in the pqm rejection mail?
[06:40] <poolie> well, not a summary, but a list of skipped tests etc
[07:05] <lifeless> poolie: sorry, I'm looking at this cisco issue
[07:06] <lifeless> the mail body is generated by pqm using the subunit library
[07:06] <lifeless> pretty straight forward to change if you want it different
[07:07] <poolie> np
[07:07] <poolie> that'd be something to change in pqm's code?
[07:11] <lifeless> yup
[07:14] <lifeless> pqm/output.py
[07:14] <lifeless> client = subunit.test_results.TestResultFilter(client)
[07:14] <lifeless> constructs the used filter
[07:15] <lifeless> what do you need changed?
[07:16] <poolie> i'd like it to just tell me about the tests that actually failed (!)
[07:17] <poolie> at the moment the output is enormous and mostly irrelevant
[07:17] <poolie> https://bugs.launchpad.net/bzr/+bug/760387
[07:19] <lifeless> I think thats a combination of things; its showing skips which changing the line to include filter_skip=Tre as a parameter will address
[07:20] <lifeless> and the skips have an attachment which is useful when debugging why something skipped
[07:20] <lifeless> but not great en masse
[07:20] <lifeless> spm: ping
[07:20] <spm> yo
[07:20] <lifeless> on balleny, in the pqm checkout that pqm runs from
[07:20] <lifeless> can you change
[07:20] <lifeless> client = subunit.test_results.TestResultFilter(client)
[07:20] <lifeless> to
[07:21] <lifeless> client = subunit.test_results.TestResultFilter(client, filter_skip=True)
[07:21] <lifeless> in the file
[07:21] <lifeless> pqm/output.py
[07:21] <lifeless> if this works and makes poolie happy, I'll commit said change to the public branch
[07:22] <spm> lifeless: hrm. that'd be a no. I can't get to balleny atm
[07:22] <lifeless> ah
[07:22] <lifeless> E-pic routing
[07:22] <spm> purple routing?
[07:22] <spm> I lie! I'm in!
[07:22] <lifeless> you are such a tease
[07:23] <spm> it was staring at me for ages diong nothing....
[07:23] <lifeless> sadface
[07:23] <lifeless>     raise errors.NoWhoami()
[07:23] <lifeless> bzrlib.errors.NoWhoami: Unable to determine your name.
[07:23] <poolie> hooray cowboys
[07:23] <poolie> lifeless: on where?
[07:23] <lifeless> poolie: pqm test suite
[07:24] <spm> lifeless: ~ line 97?
[07:24] <lifeless> spm: zigactly
[07:24] <spm> lifeless: changed
[07:25] <lifeless> poolie: toss something broken at it
[07:26] <poolie> i think it's full at the moment
[07:26] <poolie> i'm sure i will give it something broken in good time
[07:26] <poolie> thanks for that
[07:30] <poolie> re: reliability, the problem may be that other output from bzr or pqm or make sometimes gets into the stream
[07:30] <poolie> in some ways it is in an unhappy compromise between being strictly defined and requiring a reliable transport, and being fuzzy
[07:31] <lifeless> poolie: I would like it if you can tell me in the next week whether its better or not
[07:31] <lifeless> so we don't have an extended cowboy
[07:32] <lifeless> poolie: pqm keeps stdout and stderr separate; it is still possible to have things messed up of course.
[07:32] <lifeless> but stderr/stdout interleaving is the most common cause
[07:32] <poolie> i will tell you
[07:33] <poolie> there are some things in bzr that leak to stdout
[07:33] <poolie> also ,tribunal is kind of buggy
[07:35] <poolie> ok i sent in an intentionally buggy merge
[07:35] <poolie> it should get to the top of the queue in a couple of hours
[07:41] <lifeless> cool, thank you
[07:53] <poolie> lifeless: btw next in the queue is my fix for bug 751824 which might be related to your nowhoami thing
[07:54] <poolie> well, it's _related_ though i don't know if it will fix it
[07:54] <lifeless> possibly
[07:54] <lifeless> basically pqm gets few edits
[07:54] <lifeless> so it only encounters bzr api changes infrequently
[07:58] <jam> morning poolie
[07:58] <poolie> hi there jam
[08:48] <spiv> poolie: I think the ImportWarning fix needs to be updated to support Python 2.4, which doesn't have ImportWarning.
[08:54] <poolie> ah, yuck
[08:54] <poolie> just when it finished merging all the way up too
[08:55] <poolie> spiv i actually found a better way to do it, which is to just set a -W option
[08:55] <poolie> ImportWarning is ignored by default even in 2.7 and i don't think it will actually help with anything to turn it on
[08:57] <poolie> just for curiousity, did you just think of that, or did you notice in babune?
[09:04] <poolie> spiv: a great example that nothing is truly trivial i guess
[09:12] <poolie> spiv: hm the last ubuntu release with 2.4 is karmic which is eol now, or really soon
[09:13] <poolie> but better not to accidentally break it
[09:13] <poolie> lifeless: i got the result from your pqm tweak
[09:14] <poolie> it's still including knownfailure/xfail results
[09:14] <poolie> it would be nice to exclude them too because they're not relevant to any particluar landing
[09:14] <poolie> aside from that it looks really good
[09:15] <poolie> (not urgent)
[09:16] <lifeless> that may need a tweak to subunit to know about that class in the filter module (or I may have an old version in my lp vm)
[09:16] <lifeless> poolie: remind me monday
[09:16] <poolie> sure
[09:16] <poolie> thanks for the patch
[09:20] <poolie> spiv yes that does fail on 2.4, not surprisingly
[09:30] <poolie> ok i'm out for a bit, good luck
[10:34] <lifeless> poolie: http://iatp.typepad.com/thinkforward/2011/04/us-subsidizes-brazilian-cotton-to-protect-monsantos-profits.html may entertain you
[12:29] <spiv> poolie: I didn't check babune, the 2.4 issue is just something I thought of glancing at that patch for probably the 4th time in the last week or so
[12:29] <spiv> poolie: the definition of “trivial” certainly isn't trivial!
[12:31] <poolie> :)
[12:34] <jelmer> spiv: +1
[12:35] <jelmer> vila and I explicitly talked about the fact that ImportWarning wasn't in python2.4 when we were discussing why the ImportWarning didn't happen on hardy.
[12:43] <jam> jelmer, poolie: So... time to deprecate python 2.4 support?
[12:43] <jam> We've been searching for an excuse
[12:44] <jelmer> jam: I don't remember what came out of the discussion in January; does bumping the minimum version to 2.5 gain us much?
[12:44] <jam> jelmer: clearly it gets us ImportWarning
[12:44] <jelmer> well, apart from that extremely exciting feature :)
[12:44] <jam> jelmer: with statements
[12:45] <poolie> jam, i think we should drop it in trunk
[12:45] <jam> try/except/finally
[12:45] <jam> jelmer: a much easier way to migrate to a python3 code base
[12:45] <jam> note, though, that 2.5 still doesn't let us use "bytes()"
[12:46] <jam> poolie: AIUI, the primary reason to support it was that RHEL5 only has python-2.4 and will be supported by RH for another 5 years or so
[12:46] <jam> and if we introduce a new repo format that users need to upgrade to, they won't be able to get that on their RHEL systems.
[12:48] <jam> poolie: but personally, I'm probably in favor of dropping 2.4 support in trunk. Especially since RHEL6 is officially out, so RHEL people have an upgrade path they can use.
[14:04] <rom1> hi all
[14:05] <rom1> I am checking a problem that i have with bzr-xmloutput
[14:05] <rom1> about the ssh connections not closed until the rpc server is closed
[14:05] <rom1> I am a bit lost to understand the flow to open a ssh connection through bzrlib
[14:06] <rom1> Is there a developer doc describing this ?
[14:06] <rom1> Or can you give me an api that i could  check ?
[14:08] <jelmer> rom1: hi
[14:09] <jelmer> rom1: The ssh connection is opened from a SFTP or SSH Transport, both of which get created when you open a Branch, Repository, BzrDir, etc at a remote URL
[14:10] <jelmer> rom1: there isn't any functionality to close ssh connections as far as I know, I think there's a bug about it in bzr
[14:10] <poolie> mm, i think there is a disconnect method
[14:11] <poolie> but can you say more about just what's going wrong?
[14:11] <rom1> thx jelmer
[14:11] <rom1> poolie : in fact, i have many users using bzr-eclipse
[14:12] <rom1> and for each commands sent to a remote repository, a connection is openned and never closed
[14:12] <rom1> connections in bzr+ssh
[14:12] <rom1> I had up to 400 connections for one user
[14:12] <rom1> I have detected in fact taht's the xmlrpc server that keeps openning connections without nor closing them nor reusing them
[14:13] <rom1> and i've seen that closing the rpc server, the connections are closed.
[14:13] <rom1> i haven't this issue using directly the bzr command line
[14:14] <rom1> so i try to see if i can force the connection closure in the rpc server (i am talking about the server from bzr-xmloutput)
[14:15] <poolie> rom1, there is a Transport.disconnect method
[14:15] <poolie> the key thing is to decide when it ought to disconnect
[14:15] <poolie> and indeed why it's not reusing the existing connection if it is keeping them open
[14:15] <rom1> indeed
[14:16] <rom1> from what i see in the code, it calls the commands.main method
[14:16] <rom1> code of the rpc server
[14:16] <rom1> does bzr normally reuse existing connections ?
[14:18] <poolie> rom1 only when the transport object is reused
[14:18] <poolie> there's no implicit cache
[14:18] <poolie> now i need to sleep though...
[14:18] <rom1> good night poolie, and thx !
[14:18] <jam> night poolie
[15:34] <AfC> Oh man, I'm doing a bzr clone of a git repo, and it's "fetching revisions" at about 1 per second with 100% CPU. That's ok. Only 30,000 to go.
[15:35] <LeoNerd> Last time I tried doing that, it ended up bombing out because it'd filled the /tmp partition with a huuuuuge binary blob file
[15:36] <LeoNerd> I haven't touched it since
[15:41] <AfC> I'm going to have to leave this running overnight. Wow.
[15:43] <soren> AfC: A public get repo?
[15:44] <AfC> soren: yes,
[15:44] <AfC> $ bzr clone git://git.gnome.org/gtk+
[15:45] <soren> https://code.launchpad.net/~vcs-imports/gtk/trunk
[15:45] <soren> If you'd rather go that route.
[15:45] <AfC> soren: that's a _conversion_ isn't it?
[15:45] <AfC> soren: not a bzr-git repo?
[15:46] <maxb> AfC: It's a bzr-git repo
[15:47] <AfC> oh
[15:47] <maxb> well, branch
[15:48] <AfC> hm
[15:48] <AfC> well, shit, ok
[15:50] <AfC> Do you know if they're globally unique and repeatable? If I then use bzr-git myself against upstream am I going to end up with the same revids?
[15:51] <james_w> AfC, yes, it is deterministic
[15:52] <james_w> that branch is what you would get if you waited for yours to finish
[15:52] <AfC> james_w: That's the word I was looking for, thanks. Clearly it's zzz time
[15:53] <jelmer> AfC: Are you using bzr and dulwich with compiled extensions?
[15:53] <AfC> james_w: very cool. Thanks. Pity it takes so long. Most people trying this wouldn't come here to ask / wait for it to finish [in the damn, more bad press sense]
[15:53] <AfC> jelmer: hey
[15:53] <jelmer> AfC: The gtk+ conversion took less than an hour here
[15:53] <jelmer> AfC: Hi! Sorry, missed the conversation here earlier.
[15:53] <AfC> jelmer: I couldn't say - I'm using whatever is packaged in the Bazaar PPA
[15:54] <jelmer> that should be the packaged bits.
[15:54] <jelmer> AfC: Are you using the nightly PPA or another one?
[15:54] <AfC> jelmer: no releases. You guys have years of track record of warning people that dailies are broken. I don't need to try them myself to experience it.
[15:55] <AfC> deb http://ppa.launchpad.net/bzr/ppa/ubuntu maverick main
[15:55] <AfC> jelmer: ^ that one
[15:55] <jelmer> AfC: snapshots may be broken, but the PPA packages run the testsuite before they're built
[15:55] <jelmer> AfC: The followup on the bzr-git bug report, was that using a release?
[15:55] <AfC> jelmer: yes
[15:56] <AfC> jelmer: (I said so there :))
[15:56] <AfC> jelmer: I've been working on your request to blow it away and start again
[15:57] <jelmer> AfC: is that 0.6.0 or something earlier?
[15:57] <AfC> wha? It's whatever you released into the Bazaar PPA
[15:57]  * AfC looks
[15:57] <AfC> yes
[15:57] <AfC> git 0.6.0
[15:58] <jelmer> ok, that should be recent enough
[15:58] <AfC> Wow. It did a repack at 10,000 revisions and now it's back to 1/second.
[15:59] <AfC> Only 22,000 to go
[15:59]  * AfC is astonished this only took you 1 hour
[15:59] <jelmer> AfC: do you have bzr 2.3 or 2.4 ?
[15:59] <AfC> jelmer: whatever is released by the Bazaar project in the PPA.
[16:00] <AfC> $ bzr --version
[16:00] <AfC> Bazaar (bzr) 2.3.1
[16:00] <jelmer> I'm running 2.4. I'd be surprised if it made that much of a difference though.
[16:01]  * jelmer tries another clone of gtk+
[16:01] <AfC> {shrug} don't want to waste your time
[16:01] <jelmer> it's not that much effort :)
[16:02] <AfC> but it seems like some profiling of this run might bear some fruit
[16:02] <AfC> I guess I should abort this and just use ~vcs-imports
[16:03] <jelmer> it'd be great to know if it was indeed related to the shared repository you were doing the clone in
[16:03] <AfC> jelmer: but I will let it continue & then attempt to pull in it periodically over the next few weeks so as to confirm that bug is gone
[16:04] <AfC> jelmer: I'm disappointed that the branch's revisions got corrupted like that, though. I've never experienced that with Bazaar before.
[16:05] <AfC> jelmer: obviously we don't want that to happen, so I wish I could give you more information.
[16:05] <jelmer> AfC: it's not corruption, it's just that bzr-git can't regenerate the original git commit from the bzr revision
[16:05] <jelmer> though I admit the error message looks a bit scary
[16:05] <AfC> just a little [and to an end user, it's corruption :)]
[16:06] <AfC> Well, I will leave this running. I'll check back tomorrow
[22:12] <BasicOSX> do! heh Adium on Colloquy!
[22:20] <poolie> hi BasicOSX!
[22:23] <BasicOSX> hello
[22:23] <BasicOSX> wrong channel :-)
[22:28] <poolie> :)
[22:58] <kirkland> maxb: hey, i finally got around to testing your lp:~maxb/bzr-builddeb/no-error-unknown-distro branch ...
[22:58] <kirkland> maxb: it gets me past the first error, but still another blocker:
[22:58] <maxb> hi
[22:58] <kirkland> maxb: bzr: ERROR: Inconsistency between source format and version: version is native, format is not native.
[22:58] <maxb> uh, well, that's slightly good :-)
[22:58] <kirkland> maxb: :-)
[22:59] <maxb> cat debian/source/format and head -n1 debian/changelog say what?
[23:00] <kirkland> maxb: okay, i worked around that one by removing debian/source/format
[23:06] <LeoNerd> It strikes me that 'bzr missing' is slightly misnamed, if it reports that the local branch has more than upstream does..
[23:09] <maxb> nah, it tells you what upstream is missing :-)
[23:11] <LeoNerd> Hmmm... I suppose that's true
[23:17] <knighthawk> I just did a bzr svn-import
[23:17] <knighthawk> now when I try to create a branch I get the following errr
[23:18] <knighthawk> zr: ERROR: Not a branch: "/home/pluvious/wc-grc/.bzr/branch/": location is a repository
[23:18] <knighthawk> is there something I need to do first to access it?
[23:19] <knighthawk> I also tried to do a checkout but I think I got the same error
[23:19] <mr-russ1> knighthawk: you don't branch the .bzr
[23:19] <mr-russ1> wc-grc is the repository that hosts branches.
[23:20] <mr-russ1> you should be able to branch from  wc-grc/trunk
[23:20] <knighthawk> mr-russ1, thanks
[23:20] <knighthawk> I may have a layout issue.
[23:20] <mr-russ1> knighthawk: probably, I've found it painful to get svn converted to bzr the way that I'd like.
[23:21] <mr-russ1> repository is a collection of branches.  it's there to save space as the common revisions are only stored once.
[23:22] <mr-russ1> repository is really good for projects with multiple branches.
[23:23] <mr-russ1> off to work for me now.
[23:23] <maxb> knighthawk: So, wc-grc was the root directory created by the svn-import?
[23:23] <maxb> It should contain within it a number of other directories which mirror the structure of branches within the svn repository
[23:30] <knighthawk> maxb yeah I just had to drill down to the trunk
[23:30] <knighthawk> seems to be working now. only I did a branch instead of a checkout so I'm not all that sure how many extra steps I'm going to have to do to have it work like svn (well sort of like svn)
[23:36] <poolie> hi all
[23:38] <spiv> poolie: Good morning
[23:38] <spiv> poolie: http://albertomilone.com/wordpress/?p=502
[23:39] <poolie> that's good
[23:39] <poolie> o/ cinerama :)
[23:39] <cinerama> hi!
[23:41] <poolie> spiv i'm finding i get by fairly ok with hamster just in the launcher
[23:42] <jelmer> 'morning poolie, spiv
[23:42] <poolie> hi jelmer
[23:42] <poolie> i guess first of all i should revert the importwarning landings, unless someone else already did
[23:43] <jelmer> nobody has yet, I wasn't sure what the right thing to do was
[23:43] <jelmer> I guess we can fix it to use ImportWarning if available and otherwise just catch ImportError /
[23:44] <poolie> i think the right thing is -Wignore::ImportWarning as long as that works on 2.4
[23:44] <poolie> i think it will, but i'll test it now
[23:45] <poolie> it seems to
[23:45] <poolie> so i'll revert the change to the except statement and add that to the makefile?
[23:45] <jelmer> wfm
[23:47] <spiv> jelmer, poolie: see my comment on the MP
[23:47] <spiv> You can just do "try: errors = (ImportError, ImportWarning) except NameError: errors = ImportError" then use "except errors"
[23:48] <spiv> Oh, jelmer just said basically that.
[23:48] <spiv> I don't have a strong opinion on -Wignore::ImportWarning vs that
[23:49] <spiv> I guess we don't need that normally because normally we don't use -Werror?  Does the -Wignore::foo stack nicely with -Werror?
[23:50] <poolie> yes, as long as you specify them in the opposite order to what the manual implies :)
[23:50] <poolie> -Wignore is shorter :)
[23:50] <poolie> arguably we should actually just blacklist with -Werror warnings we do actually care about
[23:51] <poolie> if this happens again i'd probably do that
[23:53] <poolie> biab, natty upgrades...