| poolie | hi all | 00:08 |
|---|---|---|
| mgz | hey poolie. | 00:09 |
| poolie | hi there | 00:09 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| maxb | Well, for Ubuntu package tasks, there's an automated robot which closes bugtasks from debian/changelog uploads | 00:30 |
| mgz | how does it get in the changelog though? | 00:31 |
| poolie | manually i think | 00:31 |
| 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:32 |
| mgz | I got that just now, branched locally instead, launchpad likes midnight updates. | 00:33 |
| 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:35 |
| dchilton | good excuse to go get a beer early ... thx! | 00:37 |
| mgz | and I need to sleep, will have to do mps tomorrow. | 00:40 |
| poolie | sleep well | 00:50 |
| mgz | ...fell into the just one more bug trap. now I'm really going. :) | 00:58 |
| spiv | Good morning. | 01:01 |
| poolie | haha | 01:04 |
| poolie | hi spiv! | 01:04 |
| === r0bby is now known as robbyoconnor | ||
| === psynaptic|away is now known as psynaptic | ||
| * spiv blinks | 01:26 | |
| spiv | mutt crashed. That's new! | 01:26 |
| bob2 | heh, it reliably crashes every night for me while doing imap idle | 01:27 |
| spiv | I use offlineimap to handle the actual imap | 01:28 |
| spiv | I'm not sure I really want to send a 1.7GB apport report though! | 01:30 |
| spiv | I'm rather impressed than an 8MB crash file can apparently expand that much… | 01:32 |
| spiv | Ah, no, apport's GUI is just lying to me. | 01:33 |
| 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:22 |
| AfC | jelmer: [all on the bugs are bad but encountering someone else's reproducible bug might find something deeper that does matter] | 04:23 |
| 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:45 |
| poolie | nm, stupid bug | 04:47 |
| 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:05 |
| poolie | sent anyhow | 05:17 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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 |
| ubot5 | 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 |
| poolie | how is the pack code? | 05:40 |
| 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:47 |
| 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. | 05:48 |
| 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:36 |
| 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 | 06:40 |
| lifeless | poolie: sorry, I'm looking at this cisco issue | 07:05 |
| 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:06 |
| poolie | np | 07:07 |
| poolie | that'd be something to change in pqm's code? | 07:07 |
| lifeless | yup | 07:11 |
| lifeless | pqm/output.py | 07:14 |
| lifeless | client = subunit.test_results.TestResultFilter(client) | 07:14 |
| lifeless | constructs the used filter | 07:14 |
| lifeless | what do you need changed? | 07:15 |
| poolie | i'd like it to just tell me about the tests that actually failed (!) | 07:16 |
| poolie | at the moment the output is enormous and mostly irrelevant | 07:17 |
| poolie | https://bugs.launchpad.net/bzr/+bug/760387 | 07:17 |
| ubot5 | Ubuntu bug 760387 in Bazaar "failures are not easily visible in pqm make check error output" [High,Confirmed] | 07:17 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| spm | lifeless: ~ line 97? | 07:24 |
| lifeless | spm: zigactly | 07:24 |
| spm | lifeless: changed | 07:24 |
| lifeless | poolie: toss something broken at it | 07:25 |
| 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:26 |
| 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:30 |
| 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:31 |
| 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:32 |
| poolie | there are some things in bzr that leak to stdout | 07:33 |
| poolie | also ,tribunal is kind of buggy | 07:33 |
| 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:35 |
| lifeless | cool, thank you | 07:41 |
| poolie | lifeless: btw next in the queue is my fix for bug 751824 which might be related to your nowhoami thing | 07:53 |
| ubot5 | Launchpad bug 751824 in Bazaar "whoami-related test failures with bzr.dev" [High,In progress] https://launchpad.net/bugs/751824 | 07:53 |
| 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:54 |
| jam | morning poolie | 07:58 |
| poolie | hi there jam | 07:58 |
| === Ursinha is now known as Ursinha-afk | ||
| spiv | poolie: I think the ImportWarning fix needs to be updated to support Python 2.4, which doesn't have ImportWarning. | 08:48 |
| poolie | ah, yuck | 08:54 |
| poolie | just when it finished merging all the way up too | 08:54 |
| 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:55 |
| poolie | just for curiousity, did you just think of that, or did you notice in babune? | 08:57 |
| poolie | spiv: a great example that nothing is truly trivial i guess | 09:04 |
| poolie | spiv: hm the last ubuntu release with 2.4 is karmic which is eol now, or really soon | 09:12 |
| poolie | but better not to accidentally break it | 09:13 |
| poolie | lifeless: i got the result from your pqm tweak | 09:13 |
| 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:14 |
| poolie | (not urgent) | 09:15 |
| 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:16 |
| poolie | spiv yes that does fail on 2.4, not surprisingly | 09:20 |
| poolie | ok i'm out for a bit, good luck | 09:30 |
| === Ursinha-afk is now known as Ursinha | ||
| === zyga_ is now known as zyga | ||
| lifeless | poolie: http://iatp.typepad.com/thinkforward/2011/04/us-subsidizes-brazilian-cotton-to-protect-monsantos-profits.html may entertain you | 10:34 |
| 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:29 |
| poolie | :) | 12:31 |
| jelmer | spiv: +1 | 12:34 |
| 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:35 |
| jam | jelmer, poolie: So... time to deprecate python 2.4 support? | 12:43 |
| jam | We've been searching for an excuse | 12:43 |
| 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:44 |
| 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:45 |
| 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 |
| === psynaptic is now known as psynaptic|away | ||
| 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:46 |
| 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. | 12:48 |
| rom1 | hi all | 14:04 |
| 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:05 |
| rom1 | Is there a developer doc describing this ? | 14:06 |
| rom1 | Or can you give me an api that i could check ? | 14:06 |
| jelmer | rom1: hi | 14:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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 | 14:18 |
| === psynaptic|away is now known as psynaptic | ||
| 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:34 |
| 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:35 |
| LeoNerd | I haven't touched it since | 15:36 |
| AfC | I'm going to have to leave this running overnight. Wow. | 15:41 |
| soren | AfC: A public get repo? | 15:43 |
| AfC | soren: yes, | 15:44 |
| AfC | $ bzr clone git://git.gnome.org/gtk+ | 15:44 |
| 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:45 |
| maxb | AfC: It's a bzr-git repo | 15:46 |
| AfC | oh | 15:47 |
| maxb | well, branch | 15:47 |
| AfC | hm | 15:48 |
| AfC | well, shit, ok | 15:48 |
| 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:50 |
| james_w | AfC, yes, it is deterministic | 15:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 15:59 |
| AfC | $ bzr --version | 16:00 |
| AfC | Bazaar (bzr) 2.3.1 | 16:00 |
| === psynaptic is now known as psynaptic|food | ||
| jelmer | I'm running 2.4. I'd be surprised if it made that much of a difference though. | 16:00 |
| * 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:01 |
| 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:02 |
| 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:03 |
| AfC | jelmer: I'm disappointed that the branch's revisions got corrupted like that, though. I've never experienced that with Bazaar before. | 16:04 |
| 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:05 |
| AfC | Well, I will leave this running. I'll check back tomorrow | 16:06 |
| === 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 | ||
| BasicOSX | do! heh Adium on Colloquy! | 22:12 |
| poolie | hi BasicOSX! | 22:20 |
| BasicOSX | hello | 22:23 |
| BasicOSX | wrong channel :-) | 22:23 |
| poolie | :) | 22:28 |
| 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:58 |
| maxb | cat debian/source/format and head -n1 debian/changelog say what? | 22:59 |
| kirkland | maxb: okay, i worked around that one by removing debian/source/format | 23:00 |
| LeoNerd | It strikes me that 'bzr missing' is slightly misnamed, if it reports that the local branch has more than upstream does.. | 23:06 |
| maxb | nah, it tells you what upstream is missing :-) | 23:09 |
| LeoNerd | Hmmm... I suppose that's true | 23:11 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| mr-russ1 | repository is a collection of branches. it's there to save space as the common revisions are only stored once. | 23:21 |
| mr-russ1 | repository is really good for projects with multiple branches. | 23:22 |
| 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:23 |
| 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:30 |
| poolie | hi all | 23:36 |
| spiv | poolie: Good morning | 23:38 |
| spiv | poolie: http://albertomilone.com/wordpress/?p=502 | 23:38 |
| poolie | that's good | 23:39 |
| poolie | o/ cinerama :) | 23:39 |
| cinerama | hi! | 23:39 |
| poolie | spiv i'm finding i get by fairly ok with hamster just in the launcher | 23:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:47 |
| spiv | Oh, jelmer just said basically that. | 23:48 |
| spiv | I don't have a strong opinion on -Wignore::ImportWarning vs that | 23:48 |
| 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:49 |
| 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:50 |
| poolie | if this happens again i'd probably do that | 23:51 |
| poolie | biab, natty upgrades... | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!