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