| abentley | poolie: by "relevant plugins" do you mean ones that do iter_changes on PreviewTrees, or ones that might do RevisionTree.is_executable, or...? | 00:02 |
|---|---|---|
| poolie | im' not sure if it will be easy to identify which ones could be affected | 00:04 |
| poolie | we could guess based on the apis | 00:04 |
| poolie | or just test the ones that are packaged | 00:04 |
| abentley | poolie: I don't think it will be easy. | 00:04 |
| abentley | poolie: Okay, I'll go find out what's packaged and make sure I've got it all installed, and then run the plugin tests. | 00:05 |
| poolie | do you think this is too laborious and we should just land it? | 00:06 |
| poolie | i think it would be worth at least just running them | 00:06 |
| poolie | if it turns out they're too noisy, then we could decide what to do | 00:06 |
| abentley | poolie: I think I can run them and delta the test failures against vanila 2.2. | 00:11 |
| poolie | that sounds good to me if that works for you | 00:11 |
| poolie | so to keep this under control as a contract | 00:21 |
| poolie | i think i should mark out what we want in each particular future release | 00:21 |
| poolie | would that work for youL | 00:21 |
| poolie | mkanat: actually just generally, feel free to request review from me, jam, spiv, or all of ~bzr | 01:18 |
| mkanat | poolie: Okay. | 01:19 |
| mkanat | mwhudson: If I make the change about the None, do you want me to re-request review or just go ahead and merge it after doing it? | 01:34 |
| mwhudson | mkanat: if you're confident in your change, just merge it | 01:35 |
| mkanat | mwhudson: Okay. | 01:35 |
| mkanat | mwhudson: I'm also wondering if there might be an off-by-one error in the contents array, so that it has an extra line that it shouldn't have. | 01:36 |
| mwhudson | seems a bit unlikely somehow | 01:38 |
| mkanat | mwhudson: Well, I think that annotate_iter may not consider a final "\n" to be adding an extra line. | 01:39 |
| mwhudson | oh right maybe | 01:40 |
| mkanat | So I suppose I could just have the generator create an infinite number of empty containers at the end. | 01:41 |
| mkanat | Since we iterate over the contents array now instead. | 01:41 |
| mwhudson | that works i guess | 01:41 |
| mkanat | I think it'd be the simplest solution, code-wise. | 01:41 |
| mkanat | Well, launchpad outage stops me from doing any more development or merging. :-( | 01:46 |
| jdobrien | is there an issue with launchpad right now? | 01:54 |
| mwhudson | jdobrien: one of the data centres is offline | 01:55 |
| jdobrien | mwhudson, aha! that would answer it | 01:55 |
| jdobrien | mwhudson, I hope it was planned :o | 01:56 |
| AfC | mkanat: why would the lack of availability of a centralized web resource have anything to do with you being able to get work done with a distributed revision control system like Bazaar? | 02:01 |
| abentley | poolie: I've run all plugin tests, and none fail with is_executable that pass with 2.2. Actually, an extra fails with 2.2, so I assume it's a flaky test. | 02:41 |
| mkanat | AfC: Because my code exists only on LP right now, I reverted my patch locally. | 02:50 |
| poolie | abentley: nice | 03:10 |
| abentley | poolie: shall I go ahead and land it on 2.2, then? | 03:11 |
| poolie | please do | 03:11 |
| abentley | poolie: btw, I looked up who committed this code that's causing me grief. It was me. | 03:14 |
| poolie | haha :) | 03:14 |
| poolie | thanks for persisting with fixing it | 03:14 |
| abentley | poolie: no worries. | 03:16 |
| poolie | mkanat: reading your patch now | 05:02 |
| mkanat | poolie: Okay. | 05:20 |
| poolie | done! | 05:20 |
| poolie | good to go | 05:20 |
| mkanat | poolie: Thanks! Good timing by me. :-) | 05:20 |
| mkanat | poolie: BTW, I'm on the launchpad-devel mailing list still, so I do get the messages even if they're not CC'ed to me. (I usually just watch for subjects about loggerhead or codebrowse.) | 05:27 |
| mkanat | poolie: There is a test framework in place, BTW. | 05:27 |
| poolie | k | 05:28 |
| poolie | ... but it's hard to use for this? | 05:28 |
| mkanat | poolie: No, not that hard, I could do it. But I think it mostly already covers this, since annotate is already tested...I believe. | 05:29 |
| mkanat | Yeah, annotate is already tested. | 05:29 |
| poolie | it seems like if you're changing the default view | 05:29 |
| poolie | and the tests don't fail | 05:29 |
| poolie | there must be a gap in coverage? | 05:29 |
| mkanat | poolie: I haven't run the tests, because they're failing anyway. :-) | 05:29 |
| poolie | really, just generally? :/ | 05:31 |
| mkanat | poolie: Well, they were last time I ran them. | 05:31 |
| poolie | to the extent that it's not worth adding a new one? | 05:35 |
| mkanat | poolie: Ah, no, it could be worth adding a new one. Let me get the tests running on my new system (I just upgraded my OS and am missing some packages) and I'll see how much work it would be. | 05:35 |
| poolie | well, it could be worth a try | 05:39 |
| mkanat | I'm not quite figuring out why the tests won't run on my machine. Maybe it's some python 2.7 thing. | 05:42 |
| poolie | what os do you use? | 05:44 |
| spiv | mkanat: hmm, IIRC bzr's tests are fine on 2.7 now. | 05:44 |
| mkanat | poolie: Fedora | 05:44 |
| mkanat | spiv: Yeah, but these are loggerhead's tests. | 05:44 |
| mkanat | I seem to recall just being able to "nosetests" on python 2.6 and things would be fine. | 05:45 |
| mkanat | jam, mwhudson: Do you know what it takes to get the loggerhead tests to run right? | 05:48 |
| jam | mkanat: at one point I tried to integrate it with "bzr selftest -s bp.loggerhead" | 05:48 |
| mkanat | jam: Ohh, right. Since then, I think the tests have been broken with nosetests. | 05:49 |
| mkanat | jam: So I have to have it symlinked in as a plugin to do that, right? | 05:49 |
| jam | something like that, yes | 05:49 |
| mkanat | AttributeError: 'module' object has no attribute '_WritelnDecorator' | 05:50 |
| mkanat | Are bzr's tests only working with python 2.7 on trunk? | 05:50 |
| mkanat | I have 2.2.1 installed. | 05:51 |
| poolie | mkanat: probably yes | 05:52 |
| mkanat | Okay. | 05:52 |
| poolie | there's no py26 in fedora 14(?) | 05:52 |
| mkanat | poolie: Right. | 05:53 |
| spiv | I run bzr trunk's tests with 2.6 all the time. | 05:56 |
| spiv | Perhaps you need a newer testtools or something like that? | 05:56 |
| mkanat | spiv: No, I just easy_install'ed it. | 05:57 |
| mkanat | This is the traceback: http://pastie.org/1337546 | 05:57 |
| mkanat | It's pretty apparent that it's just related to the unittest changes in 2.7. | 05:58 |
| poolie | mm | 06:00 |
| poolie | you might be able to cherrypick-back the changes from 2.3 to fix it? | 06:00 |
| poolie | or perhaps testing it against bzr 2.3 is still useful | 06:00 |
| mkanat | Ah, well, I don't imagine LP runs 2.3. | 06:01 |
| mkanat | I'll have to figure out how to make these tests work with nosetests again. | 06:02 |
| mkanat | Wow, how is this SO FAST? Probably because of crazy custom Hg implementation. http://code.google.com/p/python-nose/source/list | 06:09 |
| poolie | that's what we should aim for | 06:15 |
| mkanat | Yeah. | 06:16 |
| poolie | might need more than little slices of time though :/ | 06:16 |
| mkanat | I think we'd have to actually cache the rendered HTML to get that fast. | 06:16 |
| mkanat | But maybe not. | 06:16 |
| poolie | perhaps an intermediate representation is cached | 06:16 |
| poolie | they're probably not touching a magnetic disk to have it consistently that fast | 06:16 |
| lifeless | that sort of speed is what cassandra is aimed at | 06:17 |
| lifeless | - its a bigtable backend for hg | 06:17 |
| mkanat | poolie: Well, if it's anything like their Svn implementation, it's a mapreduce thing with, yeah, bigtable. | 06:17 |
| mkanat | First off we'd have to figure out what and how to cache things. | 06:19 |
| mkanat | Although if you had a cassandra backend for bzr, we may not even have to cache them, I don't know for sure. | 06:19 |
| lifeless | you'd denormalise things like revnos | 06:20 |
| lifeless | in a sense such a thing is a cache | 06:21 |
| mkanat | Right, we already have a revno cache in loggerhead. | 06:21 |
| lifeless | if we can finish the 'does not need vfs for regular use' work, we could seriously consider a cassandra impl | 06:22 |
| lifeless | failing that we could push (thus limiting the operations that take place) into a ro cassandra mirror | 06:22 |
| poolie | using hpss to talk to a process that talks to cassandra? | 06:22 |
| poolie | oh nm, yes | 06:23 |
| lifeless | yes, exactly. | 06:23 |
| mkanat | jam: Do you know why your changes would have caused this (when trying to run the loggerhead tests via nosetests)? http://pastie.org/1337584 | 06:25 |
| jam | mkanat: not specifically, but I know that loggerhead doesn't know whether it is a plugin or a main script, and does some ugly hacks with the python import path to try and work both ways | 06:26 |
| mkanat | jam: Ah, yeah. | 06:26 |
| mkanat | poolie: It's probably going to take me quite some time to get the test suite working again, just as far as figuring out what's wrong and making things work right again. Do you still want me to add a test for the new controller? | 06:30 |
| spiv | mkanat: I'm not poolie, but I think investing in the test suite will pay off | 06:31 |
| mkanat | spiv: I fully and completely agree with you; this is more of a "how does Canonical want me to spend my hours" sort of a deal. :-) | 06:31 |
| poolie | mkanat: let's not block this merge on that, but i do think it would be worth spending some canonical time on it | 06:32 |
| mkanat | poolie: Okay. | 06:32 |
| mkanat | Sounds good. | 06:32 |
| poolie | it seems like it will help do other work in future | 06:32 |
| mkanat | poolie: Okay, agreed. | 06:33 |
| lifeless | it would be good to switch it to using testtools.run rather than nosetests | 06:34 |
| lifeless | which will give it easy hudson integration via subunit.run | 06:34 |
| mkanat | lifeless: It can already run under bzr selftest, I just can't run bzr selftest using my version of bzr and my version of Python. | 06:34 |
| lifeless | mkanat: why not? actually scratch that question. Different one: perhaps fixing that is more important. | 06:35 |
| mkanat | lifeless: Supposedly that's been fixed on trunk, just not in 2.2.x. | 06:35 |
| mkanat | lifeless: (This is with python 2.7.) | 06:35 |
| mkanat | So, TAL is not a very good template language. :-( | 07:36 |
| bob2 | the chameleon implementation is nicer | 07:38 |
| bob2 | gives you $foo for when you're feeling lazy | 07:38 |
| mkanat | Yeah, it's not so much the convenience of not of the language, as much as it is that it's just very difficult to work out how to do certain things. | 07:40 |
| mkanat | Particularly if you can't wrap an element in another element, or don't want to. | 07:40 |
| mkanat | I really liked Mako last time I used it, that's probably what I'd prefer, although I have no idea if there are any serious problems with it in production (or if it's still actively maintained). | 07:41 |
| vila | hello all ! | 07:46 |
| vila | full red babune | 07:46 |
| vila | I upgraded to testtools trunk yesterday, direct link, url: http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/ | 07:47 |
| vila | Nice tests as only reading their names strongly suggests a shallow problem | 07:48 |
| mkanat | I could do template inheritance with my patch that I'm working on right now, too, if I was using Mako instead. :-/ | 07:56 |
| vila | lifeless, jml: bug #683505 rings a bell regarding a recent change in testtools ? | 08:05 |
| ubot5 | Launchpad bug 683505 in Bazaar "bzrlib.tests.test_selftest.TestSubunitLogDetails failures with testtools trunk (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/683505 | 08:05 |
| vila | mgz: may also be related to a too aggressive cleanup of the test details ? ^ | 08:06 |
| vila | jml, lifeless: ping | 09:39 |
| vila | testtools introduced a change in revno 142 (regarding the return value of running a test suite with failing or erroring test), | 09:41 |
| vila | I'd like to guard against that by testing the testtools version | 09:41 |
| vila | I can use 0.9.8 for that except if you expect to change the behavior again before releasing 0.9.8 | 09:42 |
| vila | jml, lifeless: when do you expect to release 0.9.8 ? | 09:43 |
| lifeless | vila: its going to be backed out, see the bug | 09:45 |
| vila | lifeless: rats, too bad I missed that one, this sounded like a nice change though | 09:47 |
| lifeless | only part of the patch is buggy | 09:48 |
| lifeless | only that bit will be backed out | 09:48 |
| lifeless | it breaks subunit too | 09:48 |
| vila | Ok, I'll subscribe to the bug to see how it goes then | 09:49 |
| vila | meh, lp already subscribed me :) | 09:50 |
| vila | I'll revert my babune testtools in the mean time | 09:50 |
| vila | dOxxx: Hey ! | 13:06 |
| dOxxx | vila: hey :) | 13:07 |
| dOxxx | vila: everything go okay with the release? | 13:07 |
| vila | dOxxx: Thanks for the reviews and merges ! I haven't looked at the s/update/pull/ bit you mentioned, do you plan to: 1) fix it, 2) revert to use checkouts 3) something else ? | 13:07 |
| dOxxx | vila: fixed it when I merged your changes. | 13:07 |
| vila | dOxxx: AFAIK, yes, there are a couple of people having troubles with svn on OSX for reasons unclear to me, I was wondering if you knew more about that (they used 2.2.1 if that's relevant) | 13:08 |
| vila | dOxxx: Cool! | 13:08 |
| dOxxx | vila: Which version of OSX? | 13:08 |
| dOxxx | were there bugs filed? | 13:09 |
| vila | wow, that was ambigous, re-try: yes, the 2.2.2 release seems okay. Then some people with 2.2.1/10.5 have reported svn related problems | 13:09 |
| dOxxx | ok | 13:09 |
| vila | dOxxx: I think there were bugs, but linked to/from answers | 13:09 |
| vila | dOxxx: at least one of them has installed macports and had related problems but didn't confirm that uninstalling macports addressed them | 13:10 |
| vila | dOxxx: the other(s?) didn't mention macports | 13:11 |
| dOxxx | if you could point me to the bug reports, I'll take a look | 13:11 |
| vila | ok, let me find them | 13:11 |
| vila | but... just wondering, was it for 2.3bn that svn/subertpy tip was needed ? | 13:12 |
| dOxxx | checking | 13:13 |
| dOxxx | No, I think it was for all branches | 13:14 |
| dOxxx | But it's a compilation problem not a runtime thing | 13:14 |
| dOxxx | I needed r2219+ to actually get subvertpy to compile on 10.5 | 13:15 |
| jelmer | dOxxx: oh? | 13:15 |
| vila | bug #681285 | 13:16 |
| ubot5 | Launchpad bug 681285 in Bazaar "Can't push my changes in Bazaar" [Undecided,Incomplete] https://launchpad.net/bugs/681285 | 13:16 |
| vila | jelmer: ^ you may know better from the error message in the last comment | 13:16 |
| dOxxx | jelmer: yep, as I recall you made the changes for me | 13:16 |
| vila | well, the *2* error messages even | 13:16 |
| jelmer | dOxxx: can you fetch without problems from that location? | 13:17 |
| dOxxx | sorry still reading bug | 13:18 |
| jelmer | dOxxx: ahh, ok. That was a while ago though. | 13:19 |
| dOxxx | jelmer: yeah, so I don't think that's the problem here. | 13:19 |
| vila | dOxxx: right, the other is harder to find back: bug #682904 and https://answers.launchpad.net/bzr/+question/135989, read the question before the bug may be | 13:20 |
| ubot5 | Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904 | 13:20 |
| dOxxx | vila: could you check what version of svn you have on your 10.5 build machine? | 13:20 |
| vila | how ? | 13:20 |
| vila | I *have* svn ?? | 13:20 |
| dOxxx | of course, how do you think the installers build? :) | 13:21 |
| dOxxx | OS X comes with svn stock | 13:21 |
| vila | no idea, I've just pushing buttons ;) | 13:21 |
| vila | s/I've/I'm/ | 13:21 |
| dOxxx | hah | 13:21 |
| jelmer | dOxxx: Ahh, you're Gordon! | 13:21 |
| dOxxx | jelmer: yers ;) | 13:21 |
| vila | jelmer: meet dOxxx aka Gordon | 13:22 |
| dOxxx | sorry, shoulda introduced myself :) | 13:22 |
| vila | dOxxx: meet Jelmer :) | 13:22 |
| vila | svn --version reports: 1.4.4 (r25188) | 13:22 |
| jelmer | dOxxx: np, I know who you are.. but I hadn't connected you with your nick name :-) | 13:22 |
| dOxxx | hmm.... | 13:23 |
| vila | dOxxx: is this as bad as I think ? :-/ | 13:23 |
| dOxxx | jelmer: would compiling subvertpy against libsvn 1.4 cause a problem like described in these questions? | 13:23 |
| jelmer | dOxxx: yeah | 13:23 |
| vila | i.e. is bzr-svn compatible with svn 1.4.4 ? | 13:24 |
| jelmer | it is compatible but certain functionality won't be available | 13:24 |
| jelmer | and performance will be impacted | 13:24 |
| dOxxx | I don't want to include new svn libraries with the OSX bzr installer | 13:25 |
| jelmer | dOxxx: why not? | 13:25 |
| dOxxx | jelmer: 1) I'm not sure how to do it correctly, 2) that's touching system files, which is kinda icky | 13:25 |
| vila | jelmer: I don't think the OSX installer can use private binaries/libraries easily so they are installed sys... what he said :) | 13:26 |
| jelmer | vila: urgh :-( | 13:26 |
| jelmer | I guess it makes to use whatever the system is providing | 13:26 |
| vila | it is ! | 13:27 |
| dOxxx | the OSX installer puts all the bzr stuff into the system python's site-packages and stuff like the Qt framework in the system location too | 13:27 |
| vila | but the fix here may be to just tell people to upgrade their svn if needed | 13:27 |
| dOxxx | so it's already potentially overwriting Qt libraries | 13:27 |
| vila | but that's different than pushing a newer one | 13:27 |
| dOxxx | but those aren't installed stock with OSX so I didn't feel so bad about that | 13:27 |
| dOxxx | but even if they upgrade their system svn, it seems that since subvertpy is compiled against 1.4, it will still cause problems? | 13:28 |
| jelmer | yes | 13:28 |
| vila | oh my | 13:28 |
| dOxxx | right, so we'd need to compile subvertpy against svn 1.5 at least and tell users that they must install svn 1.5 first | 13:29 |
| vila | no, wait, I don't get it | 13:29 |
| dOxxx | vila: subvertpy build against svn 1.4 on our build machine will make it behave like a svn 1.4 client even if there are newer svn libraries installed on the user's machine | 13:29 |
| vila | are you both implying that 2.2.0 was ok, but 2.2.1 is not anymore because of subvertpy ? | 13:29 |
| dOxxx | vila: I don't think this is related to the bzr version | 13:30 |
| vila | I was referring to the installer version | 13:30 |
| vila | so the set of whatever we package there, including bzr, plugins and their dependencies | 13:31 |
| dOxxx | urgh | 13:32 |
| vila | if we can't provide an all-in-one installer including bzr-svn, it means (IMHO) that we should have specific packages for svn-1.4, 1.5 and/or whatever other versions are available and install only the relevant ones ? | 13:32 |
| vila | s/ones/one/ | 13:32 |
| vila | but back to my question: bzr-svn was working with the 2.2.0 installer right ? | 13:33 |
| dOxxx | like I said, I don't think this is a problem that was introduced in a particular version of the installer, it may have always existed | 13:34 |
| vila | dOxxx: or did you use a 10.5 host with an upgrade svn to 1.5 ? | 13:34 |
| vila | ha, ok :-/ So these are the first reports that bzr-svn doesn't work on OSX ? | 13:34 |
| dOxxx | vila: honestly, I can't remember what version of svn it had installed. I know that it was a fresh install of OS X 10.5, so I'm assuming that it was svn 1.4 like yours | 13:35 |
| vila | jelmer: did you get feedback from osx 10.5 users ? | 13:35 |
| dOxxx | vila: as far as I know, I don't seem to get emails for bug reports on bzr-svn | 13:35 |
| vila | dOxxx: honest ignorance is better than silence :D | 13:35 |
| jelmer | vila: please note that these bug reports are not an indication that bzr-svn doesn | 13:35 |
| jelmer | 't work at all, it's just certain kinds of pushes | 13:35 |
| vila | oh | 13:36 |
| vila | right :) | 13:37 |
| vila | I was shaking the tree to see which fruits will fall :) | 13:37 |
| vila | Wasn't meant to be negative | 13:37 |
| vila | meh, especially when the report starts with: "For a while, Bazaar was working fine, but now when I push, I get" | 13:38 |
| vila | dOxxx, jelmer : how does one check which svn and which subvertpy is used by bzr (or is subvertpy the only relevant part) ? | 13:40 |
| jelmer | vila: newer versions of bzr-svn will mutter that information to .bzr.log | 13:43 |
| vila | Said otherwise: how can one install an upgraded svn/subvertpy to make bzr happy ? | 13:43 |
| vila | hmm, or may be s/how can one/is it possible to/ | 13:43 |
| maxb | If you just install svn 1.5.x and reinstall subvertpy, things should be happy | 13:43 |
| dOxxx | jelmer: the bzr 2.2.2 OSX installer uses r2219 of subvertpy, has there been an official release since then? | 13:44 |
| dOxxx | looks like 0.7.4 and 0.7.5? | 13:45 |
| jelmer | dOxxx: yep | 13:46 |
| dOxxx | ok, I should update the installer configs to use 0.7.5 then I think | 13:46 |
| dOxxx | vila: do you think we should rebuild the OSX installers for 2.2.2 to use a newer subvertpy? | 13:46 |
| dOxxx | the version its currently using is from July and about 2 releases out of date | 13:47 |
| vila | hmm | 13:48 |
| dOxxx | I don't know if it will solve George's problem but it seems like a generally good idea | 13:48 |
| dOxxx | since it looks like there have been some svn 1.4 compatiblity fixes | 13:48 |
| vila | 2.2 is stable, if we broke it we should fix it, but upgrading too many things may break it even more | 13:49 |
| jelmer | dOxxx: yeah, it wouldn't solve George's problem | 13:49 |
| dOxxx | jelmer: would subvertpy 0.7.5 still be compatible with bzr-svn 1.0.3 or should we use a newer version of that? | 13:49 |
| jelmer | dOxxx: there's no need for a newer bzr-svn | 13:49 |
| dOxxx | ok thanks | 13:49 |
| vila | so, testing 2.2.1, 2.2.2, 2.3b3 locally with 'bzr info http://svn.apache.org/repos/asf/subversion/trunk' succeeds | 13:59 |
| vila | does it mean I need another svn server to test against ? | 13:59 |
| vila | to reproduce George's problem ? | 13:59 |
| dOxxx | vila: have you tried the URL George is using? | 13:59 |
| vila | not yet, I though it required some auth, let me try | 13:59 |
| maxb | jelmer: Did you deliberately turn the bzr-pqm-daily recipe on again for karmic? | 14:00 |
| * maxb turns it off again | 14:00 | |
| vila | dOxxx: indeed, it asks for a suer/password and when I enter none, fails with a 500 server error | 14:01 |
| dOxxx | darn | 14:01 |
| dOxxx | what I don't understand is why, if George upgraded his svn to 1.6.9 and subvertpy to 0.7.4, why is still not working? It gives a different error though. | 14:02 |
| jelmer | dOxxx: did he recompile his subvertpy against svn 1.6 ? | 14:03 |
| dOxxx | he doesn't say. | 14:03 |
| jelmer | maxb: I didn't realize it was intentionally disabled. I enabled the natty builds yesterday evening. | 14:03 |
| maxb | The recipe description field could do with being more prominant, and supporting line-breaks | 14:04 |
| dOxxx | vila, jelmer: I've updated https://answers.launchpad.net/bzr/+question/135989, asking George for specifics on how he upgraded svn and subvertpy | 14:06 |
| dOxxx | I need to go do my actual day job now unfortunately. :P | 14:07 |
| vila | jelmer: he says (in bug #682904) : "Note that I am running svn 1.6.9 and subvertpy 0.7.4." | 14:07 |
| maxb | jelmer: Oh, whilst I think about the recipes, I had a question: Why are the bzr daily recipes using version numbers like 1.4.0~bzr{revno}~ppa{revno:packaging}+{revno:debian} ? The ordering of {revno:packaging} and {revno:debian} is inverted to what feels natural to me? | 14:07 |
| ubot5 | Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904 | 14:07 |
| vila | dOxxx: no worries, thanks for the help ! | 14:07 |
| vila | jelmer: he didn't say *where* he installed them though | 14:08 |
| jelmer | vila: but that doesn't say against which version of the libsvn API his subvertpy was compiled against though | 14:08 |
| dOxxx | yeah that's what I'm wondering | 14:08 |
| dOxxx | considering he was using MacPorts before | 14:08 |
| vila | dOxxx: not sure that's the same guy | 14:08 |
| dOxxx | they seem to be the same George | 14:08 |
| vila | ha, good, well done to file different bugs then :-/ | 14:09 |
| dOxxx | yeah and two Questions with the same content :) | 14:09 |
| vila | ha, now we need duplicates for questions too... | 14:09 |
| jelmer | vila, dOxx: If he has svn 1.6.9 installed but compiled his subvertpy against svn 1.4 then it still won't work. | 14:10 |
| vila | ha no, poolie turned the bug into a question, oh my | 14:10 |
| jelmer | maxb: Something can be said for either | 14:10 |
| dOxxx | dammit, I'm not getting notified of bugs filed on bzr-mac-installers | 14:10 |
| vila | jelmer: /me nods | 14:10 |
| maxb | jelmer: ok :-) I'd like to understand what can be said for this way? | 14:11 |
| dOxxx | ok... set myself as the bug supervisor maybe that will do it | 14:11 |
| mgz | vila: I don't understand the testtools from the log or Robert's bug entry | 14:12 |
| mgz | +issue | 14:12 |
| vila | mgz: just a sec, let me push my wip branch, that should be clearer there | 14:13 |
| mgz | the three failing tests look wrong to me, but why were two of them passing before? | 14:13 |
| vila | three/two ? | 14:14 |
| vila | Three were passing three are now failing | 14:14 |
| mgz | we don't seem to use a custom wasSuccessful method, and the default one should return False if there's a failure | 14:14 |
| mgz | unexpected success flipped, but the other two should be the same | 14:14 |
| vila | mgz: in a nutshell, the bug I filed is a duplicate, more fixes should be done in testtools | 14:15 |
| mgz | I'm guessing from the bug entry Robert knows what's going on, I just can't divine what the fix should be from what he's written | 14:15 |
| vila | hmm, he said the change doesn't take into account decorated was_successful or something, including subunit | 14:16 |
| mgz | ah, maybe it's a subunit only thing. | 14:16 |
| smoser | i'm not sure this is bzr or launchpad question. | 14:17 |
| vila | mgz: now, I don't understand the specifics, I've only been looking at making the tests more precise about whether running a test suite should succeed or not depending on which tests were provided | 14:17 |
| dOxxx | argh | 14:17 |
| smoser | but this used to work: bzr branch lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds | 14:17 |
| smoser | but now gives bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/". | 14:17 |
| dOxxx | vila: looks like we need to do a new 2.2.2 installer build anyway to update bzr-svn to 1.0.4 | 14:17 |
| dOxxx | bug 621446 | 14:17 |
| ubot5 | Launchpad bug 621446 in Bazaar Mac Installers "AttributeError: paths when trying to svn-import" [Undecided,New] https://launchpad.net/bugs/621446 | 14:17 |
| jelmer | smoser: that's a #launchpad question really. You have a branch stacked on another branch that no longer exists. | 14:17 |
| smoser | https://code.launchpad.net/~ubuntu-virt shows no 0.12 branch there anymore. I'm guessing someone deleted that, and my branch shared data | 14:18 |
| smoser | jelmer, yeah. | 14:18 |
| smoser | jelmer, thanks. | 14:18 |
| jelmer | smoser: Soren had the same issue the other day. | 14:18 |
| vila | dOxxx: unless this is already fixed in 2.3b3 (or b4 which will be released tomorrow) | 14:18 |
| dOxxx | vila: no it's an installer issue. the installer is configured to use bzr-svn 1.0.3. | 14:19 |
| smoser | jelmer, funny, soren is probably who deleted my branch :) | 14:19 |
| jelmer | maxb: if somebody fixes something in the packaging branch then that change should sort before any fixes in the debian branch. | 14:19 |
| dOxxx | nothing to do with bzr version per se | 14:19 |
| soren | smoser: I didn't delete your branch. I moved mine to ~ubuntu-virt. | 14:19 |
| dOxxx | just that 2.2 is current stable branch so I should make sure it works ;) | 14:19 |
| vila | dOxxx: if 1.0.4 is not specifically targeted at bzr-2.2, we shouldn't include it in 2.2.[23] | 14:19 |
| smoser | well, one its gone from where it was, so move or delete, ... potAto potato | 14:19 |
| jelmer | maxb: ~bzr has write access to the packaging branch but not the debian branch so the packaging branch can always merge in the debian branch if necessary, never the other way around. | 14:20 |
| vila | dOxxx: otherwise we end up packaging the same thing in 2.3 and 2.2 and this will break the stability guarantee | 14:20 |
| smoser | soren, do you happen to know, then what i need to do to make that function again ? | 14:20 |
| vila | dOxxx: that's the rule, does it apply in this case ? | 14:21 |
| dOxxx | vila: not sure I understand your previous comment | 14:21 |
| vila | mgz: lp:~vila/bzr/683505-test-no-log, wip, doesn't work yet | 14:22 |
| maxb | jelmer: but, every build will always take the latest revno of the debian branch anyway, so I'm not seeing where this ordering issue would arise | 14:22 |
| vila | dOxxx: let me look at the bug | 14:22 |
| jelmer | maxb: Imagine somebody made a commit in the debian branch | 14:22 |
| jelmer | maxb: or, in fact, did a merge in the debian branch (changing the revno's) | 14:23 |
| maxb | but... that would be a silly thing to do! :-) | 14:24 |
| mgz | thanks vila. | 14:24 |
| vila | dOxxx: dang ! Same here, I never got gplyph answer ! | 14:24 |
| mgz | so, I think the conditions are backwards in those three tests, but it's subunit being funny. | 14:25 |
| mgz | so again, probably wants something changing in all three projects. | 14:25 |
| soren | smoser: I'd talk to mvo. I think he sorted it out. | 14:26 |
| dOxxx | okay really going to work now | 14:27 |
| dOxxx | seeya | 14:27 |
| vila | mgz: since babune was very update, I've reverted to testtools-0.9.7 waiting for a consensus to emerge :) | 14:27 |
| vila | mgz: what is backwards ? | 14:28 |
| vila | mgz: that subunit says all is well even when running a single failing test ? | 14:28 |
| vila | dOxxx: argh, no one more second ! | 14:29 |
| dOxxx | ? | 14:29 |
| vila | dOxxx: my comment was: if bzr-svn doesn't say: this release is compatible with bzr-2.2 and 2.2 users are expected to upgrade, we should include it in 2.2.2, otherwise we should not | 14:30 |
| vila | dOxxx: i.e.: the plugin authors should be explicit, like qbzr maintaining a specific series target at 2.2 and another targeted at 2.3 | 14:30 |
| dOxxx | that would be nice | 14:30 |
| vila | jelmer can confirm that bzr-svn is targeted at 2.2 and 2.3, so in this case, yes, we should rebuild the 2.2.2 installers | 14:31 |
| dOxxx | bzr-svn 1.0.4 | 14:31 |
| vila | meh, bzr-svn-1.0.4 yeah, thanks :D | 14:31 |
| dOxxx | argh | 14:32 |
| jelmer | dOxxx, vila: The supported versions for a bzr-svn branch should be available in info.py | 14:32 |
| dOxxx | George says he "replaced the system-installed svn with the new version using MacPorts" | 14:32 |
| vila | jelmer: by the way, the 1.1 and 2.0 series for bzr-svn are not that clear to me ;D | 14:32 |
| dOxxx | /facepalm | 14:32 |
| vila | dOxxx: be sure to check the dates ? | 14:32 |
| dOxxx | this is a new comment on the question | 14:33 |
| dOxxx | posted 15 min ago | 14:33 |
| dOxxx | https://answers.launchpad.net/bzr/+question/135989 | 14:33 |
| dOxxx | as far as I know MacPorts installs into /opt so it wouldn't replace the system svn | 14:33 |
| jelmer | vila: Yeah, I haven't really gotten to those. I have Plans, though :-) | 14:34 |
| vila | jelmer: hehe great ! | 14:34 |
| vila | so, bzr-svn 1.0.5 is targeted at 2.x for x in [0,1,2,3] :) | 14:34 |
| vila | bzr-svn 1.0.3 is targeted at 2.x for x in [0,1,2] | 14:35 |
| vila | and of course I don't have bzr-svn-1.0.4 available here ;D | 14:36 |
| dOxxx | anyway so I think his svn is not properly upgraded and his subvertpy not compiled against the right version. | 14:36 |
| dOxxx | and now I really must go to work, already 30 min late. | 14:36 |
| vila | dOxxx: right, happy work day ! Thanks again ! | 14:36 |
| dOxxx | bye! | 14:36 |
| vila | jelmer: one more thing: bzr-svn is aimed at being compatible with svn-1.[456] right ? (relying on subvertpy compiled against the right library ?) | 14:56 |
| jelmer | vila: yep, and 1.7 | 14:57 |
| vila | hmm, so the issue with OSX installers is to be able to build various subvertpy packages on a host with the right(s) svn installed :-/ | 14:59 |
| vila | and provide some way to select the right one :-( | 14:59 |
| === zyga is now known as zyga-food | ||
| === Meths_ is now known as Meths | ||
| === zyga-food is now known as zyga | ||
| mgz | vila: yes, that's my understanding of the subunit aspect. | 16:06 |
| vila | . o O (Oh my god, what does he mean with this 'yes'....) | 16:07 |
| vila | :D | 16:07 |
| mgz | <vila> mgz: what is backwards ? | 16:07 |
| mgz | <vila> mgz: that subunit says all is well even when running a single failing test ? | 16:07 |
| mgz | :P | 16:07 |
| vila | ha, ok | 16:07 |
| === deryck is now known as deryck[lunch] | ||
| vila | I wonder if he does this manually in order to carry some subliminal messages | 16:08 |
| mgz | the lunch? or lifeless quitting? :D | 16:08 |
| vila | mgz: not you ;D | 16:09 |
| vila | This has occurred several times these last weeks with an astonishing synchronicity :) | 16:09 |
| vila | mgz: random thought: about 'lost connection during...' errors, could that be explained by 'time' events going backwards in time ? | 16:13 |
| mgz | nope, they should be pure decoration. | 16:13 |
| vila | I hate them | 16:14 |
| mgz | it's not a very helpful starting point for debugging I agree. | 16:15 |
| mgz | could perhaps file a bug against subunit to make it provide more information in those circumstances | 16:17 |
| mgz | it's from falling off the end of a read-from-stream loop, printing state information about the subprocess where available might be helpful | 16:18 |
| mgz | breaks through the abstraction a bit, but otherwise you don't have any clue what caused the eof. | 16:19 |
| vila | mgz: is there a way to save these streams ? | 16:20 |
| mgz | tee? | 16:20 |
| vila | where ? | 16:20 |
| mgz | hm, point. | 16:20 |
| vila | :D | 16:20 |
| mgz | inside fork_for_tests I guess. | 16:21 |
| vila | yeah, I was afraid you'll say that ;) | 16:21 |
| === beuno is now known as beuno-lunch | ||
| ccxCZ | is there way to make bzr non-interactive when working on bzr+ssh branches, so it won't ask for password? | 16:40 |
| === deryck[lunch] is now known as deryck | ||
| mgz | http://babune.ladeuil.net:24842/job/selftest-windows/237/ <- are you aware of this regression vila? | 16:53 |
| mgz | bt.test_msgeditor.MsgEditorTest.test_deleted_commit_message has been consistently failing since then, though it passes locally for me. | 16:53 |
| vila | ccxCZ: like... using an ssh key and an ssh agent ? | 16:54 |
| mgz | it's something of a hacky test, perhaps tripping over something with del. | 16:54 |
| vila | mgz: shudder, I noticed and forgot and bialix also mentioned something related and I was waiting for his feedback | 16:55 |
| vila | ccxCZ: so the answer is yes, it would drive me crazy otherwise to type my passphrase hundreds of time each day | 16:56 |
| vila | mgz: 'since then' is related to bug #676637 ? | 16:57 |
| ubot5 | Launchpad bug 676637 in GStreamer "Wrong aspect ratio with DV AVI files in PiTiVi" [Low,New] https://launchpad.net/bugs/676637 | 16:57 |
| vila | probably not | 16:58 |
| vila | mgz: 'since then' is related to bug #673637 ? | 16:58 |
| ubot5 | Launchpad bug 673637 in Bazaar ""bzr commit" fails when BZR_EDITOR is emacsclient" [Medium,Fix released] https://launchpad.net/bugs/673637 | 16:58 |
| vila | more like it | 16:58 |
| mgz | since that set of revisions, but I'm guessing bug, yeah, that one | 16:58 |
| vila | damn, I should fix this asap then | 16:58 |
| vila | the bug report was for a windows user, too bad he didn't test it, lack of installer I presume | 16:59 |
| ccxCZ | vila: of course I know about ssh keys, but in case they're not loaded (eg. cronjob) I want bzr fail instead of hang | 17:01 |
| ccxCZ | bzr to fail* | 17:01 |
| mgz | the problem is bzr delegates to your ssh client | 17:01 |
| mgz | how would you prevent that from promting? | 17:02 |
| ccxCZ | which is paramikoI presume? | 17:02 |
| mgz | well, depends on what you have installed. | 17:02 |
| vila | the use case is valid though a bit weird | 17:02 |
| ccxCZ | you can stop openssh by options and maybe by env | 17:03 |
| mgz | vila, I'm not sure the fix for the bug is broken, just that test (and not always, as it seems to pass here) | 17:03 |
| vila | ccxCZ: you can force the ssh implementation via... | 17:03 |
| vila | BZR_SSH ? | 17:03 |
| vila | yeah, see 'bzr help env-variables' | 17:04 |
| mgz | yeah, making a sh script with ssh --some-no-prompt-option then setting BZR_SSH to that script would work | 17:04 |
| mgz | if you have an ssh client that supports something like that. | 17:04 |
| vila | ccxCZ: so you have a cronjob that pass where you have given access to some key via your agent and you want it to fail otherwise ? | 17:04 |
| vila | s/where/when/ | 17:04 |
| vila | ccxCZ: I use password-less keys for unattended jobs, so I'm curious about your use case here | 17:05 |
| vila | ccxCZ: also there have been discussions about a true non-interactive mode but I'm not sure the related changes have landed | 17:07 |
| vila | ccxCZ: better file a bug with your precise use case, I'm sure I will forget otherwise :( | 17:08 |
| ccxCZ | actually I want automate checking whether there are changes on remote server, probably by changing prompt on the shell that is cd'ed in a dir with .bzr in it | 17:09 |
| ccxCZ | what should I put in BZR_SSH? would "/usr/bin/ssh -o BatchMode=yes" work? | 17:10 |
| vila | I'm afraid we don't accept arguments in this variable, IIRC, it's either a pre-defined value or a path | 17:11 |
| vila | mgz: hmm, this may be babune specific... | 17:13 |
| mgz | yup. | 17:14 |
| lifeless | ccxCZ: you can put BatchMode=yes into a ~/.ssh/config stanza | 17:19 |
| ccxCZ | yes, but that would disable it for *every* ssh instance, which I don't want, since I might ssh into a server where I don't have a key | 17:21 |
| lifeless | no | 17:22 |
| lifeless | put it in a host stanza | 17:22 |
| lifeless | only affects that host | 17:22 |
| ccxCZ | that's not really what I want, it has several shortcomings | 17:27 |
| ccxCZ | needing to remember to add host when I branch from new one for example | 17:28 |
| ccxCZ | interesting thin is this still manages to ask for password: | 17:29 |
| ccxCZ | TTY="" ssh -p 2222 localhost </dev/null &>/dev/null | 17:29 |
| ccxCZ | thing* | 17:29 |
| jam | echo -e '#!/bin/sh\nexec ssh -o BatchMode=yes "$*"\n' > ~/bin/my_ssh; chmod ~/bin/my_ssh; export BZR_SSH=~/bin/my_ssh | 17:29 |
| jam | ccxCZ: openssh knows how to do direct-to-tty communication, not via stdin/stdout | 17:29 |
| jam | so that you can't get your password intercepted, etc | 17:30 |
| vila | jam: hello :) | 17:30 |
| jam | hi vila | 17:30 |
| jam | vila: I just found # cypthon: profile=True which seems very powerful. Of course, it just changed my runtime from 3min to >1hr so far... | 17:31 |
| jam | but you can also selectively disable it for specific functions | 17:31 |
| vila | :) :-/ | 17:31 |
| jam | i thought the 2x overhead from profiling regular python code was bad, 100x for compiled functions? | 17:32 |
| vila | may it's more precise :D | 17:32 |
| vila | it runs everything 100 times to avoid noise ;) | 17:33 |
| vila | jam: what BZR_SSH setting are you using on windows when running from a cygwin shell ? | 17:34 |
| jam | vila: BZR_SSH=paramiko | 17:34 |
| vila | doesn't work for me: | 17:34 |
| vila | err, not the same failure :( | 17:35 |
| jam | from cygwin shell, you'd still need "export BZR_SSH=paramiko", and you'd also want to make sure you actually have paramiko installed | 17:35 |
| ccxCZ | jam: yeah, I've done just that | 17:36 |
| ccxCZ | thanks everyone | 17:36 |
| vila | jam: hmm, will that be able to use a forwarded agent ? | 17:36 |
| jam | vila: paramiko doesn't talk to forwarded agents, AFAIK | 17:37 |
| jam | I'm not sure if "BZR_SSH=openssh" would be able to (if you have openssh installed on that machine) | 17:37 |
| jam | actually, AFAIK, you can't forward agents to windows, but I don't know the cygwin ssh server all that well | 17:37 |
| jam | I've never tried to use it in anger | 17:37 |
| vila | 'ssh-add -l' gives me the expected result | 17:38 |
| === beuno-lunch is now known as beuno | ||
| vila | ha,right, that's where I got the error: 4 [main] ssh 3980 C:\cygwin\bin\ssh.exe: *** fatal error - couldn't initialize fd 2 for /dev/tty0 | 17:38 |
| vila | I can connect "manually" but not via bzr+ssh :-/ | 17:39 |
| ccxCZ | /msg *status detach #bzr | 17:41 |
| ccxCZ | oops | 17:41 |
| vila | ccxCZ: bye ;) | 17:41 |
| jam | vila: probably something about TTY hiding/subprocess spawning | 17:42 |
| jam | vila: I would guess the problem is that your "bzr" is a win32 native process | 17:42 |
| jam | interposing itself from your cygwin shell that you sshed into, and the ssh you are going out of | 17:43 |
| jam | you could try running cygwin bzr | 17:43 |
| vila | which one is that ? ;D | 17:43 |
| * mgz uses plink | 17:44 | |
| mgz | mixing cygwin ssh and native bazaar could certainly cause oddness | 17:45 |
| vila | mgz: and you can ssh *to* a windows host *and* get bzr+ssh to say lp, working ? | 17:45 |
| mgz | why would I want to ssh to a windows host? | 17:45 |
| vila | mgz: to help me ssh to a windows host and have a babune setup working ;D | 17:46 |
| jam | vila: why not use pageant with a decent key and paramiko? | 17:47 |
| mgz | (In other words, I've never tried to run an ssh server on windows and probably can't help) | 17:48 |
| vila | jam: the windows host is started on demand, there is nobody logged there | 17:48 |
| mgz | I'd stick with screen sharing, even though that's not as nice for you as pretending it's another nix box. | 17:49 |
| jam | vila: well, *somebody* gets logged in... | 17:49 |
| vila | yes, via ssh, but how will pageant be started there ? | 17:50 |
| vila | no display | 17:50 |
| vila | mgz: screen sharing is good for interactive use, running the test suite doesn't care about a screen :) | 17:51 |
| mgz | hudson needs ssh access to work? | 17:52 |
| vila | hudson itself, no, but I don't want to duplicate everything just for windows, anyway, EOD for me, dinner is ready ;) I'll try plink tomorrow | 17:54 |
| jam | vila: I don't think plink knows how to talk to openssh agents | 17:55 |
| mgz | yeah, I'm not sure I'm solving your problem with that. | 17:55 |
| jam | the other option is paramiko without pageant, and just use password-less keys | 17:55 |
| vila | if this means having one dedicated ssh key for windows, I can leave with that | 17:55 |
| vila | or two (one for babune, one for lp) | 17:56 |
| jam | I believe paramiko will look in ~/.ssh/* which is C:/Documents and Settings/user on older windows and C:/Users/user on newer | 17:56 |
| vila | jam: ha ! excellent, that's certainly the missing bit, as <user> is *not* set correctly so far | 17:59 |
| * vila shouts: yeah, I'm coming darling, I'm coming | 17:59 | |
| Ddorda | hey guys. how do i push on the last commit? | 18:01 |
| dash | which one is the last one? :) | 18:03 |
| dash | or do you mean "on every commit" | 18:03 |
| Ddorda | dash: commit that overwrite the last commit | 18:04 |
| dash | Ddorda: commits don't "overwrite" stuff | 18:04 |
| Ddorda | dash: i mean revisions (woops) | 18:05 |
| dash | right, those don't either | 18:05 |
| Ddorda | to push overwriting the last rev. | 18:05 |
| Ddorda | so? | 18:25 |
| Ddorda | i want to remove the last rev. and make a new one instead | 18:25 |
| beuno | Ddorda, "bzr uncommit" | 18:26 |
| Ddorda | beuno: does it remove the changes? | 18:27 |
| beuno | Ddorda, it removes the commit, and leaves the changes uncommited | 18:27 |
| Ddorda | beuno: thank you :) | 18:27 |
| beuno | np | 18:28 |
| maxb | vila: Your lucid bzr-landing-dependencies has a version number less than the hardy one. This is bad, if there's ever an attempt to upgrade from one to the other | 18:49 |
| vila | maxb: thanks for the tip, I'll fix it, 1.0.2~lucid1ubuntu1 will do > | 18:56 |
| vila | ? | 18:56 |
| maxb | vila: Well, it's a pet peeve of mine - why include "ubuntu" when it's not a Debian derived package modified in ubuntu? | 18:57 |
| vila | maxb: no idea, monkey see monkey do, no thinking there :) I'm all ears | 18:57 |
| maxb | If it's a lucidified version of 1.0.0, I'd call it 1.0.0lucid1 | 18:58 |
| vila | maxb: oooh, that's the '~' that makes it smaller ? | 18:59 |
| maxb | Yes, the ~ is the magic that is smaller than nothing at all | 18:59 |
| maxb | Unfortunately, the rise of PPAs has taught people to use it as a generic separator | 18:59 |
| vila | maxb: because PPAs are supposed to provide preview versions right ? | 19:00 |
| maxb | Because they are often used that way | 19:00 |
| jam | vila: right, you usually want ppas to be overwritten by real releases | 19:01 |
| jam | I've seen similar tricks with nightly builds. So you have bzr-2.3b4~r5536 | 19:02 |
| vila | maxb: done and dput'ed | 19:02 |
| maxb | and mark-uploaded and pushed? :-) | 19:02 |
| vila | jam: yeah, as maxb said, I thought it was just a separator | 19:02 |
| jam | vila: there is a whole lot of voodoo magic that goes into debian versions :) | 19:02 |
| jam | - means something, as does ~, and everything else | 19:03 |
| vila | maxb: what ? Hmm, more tricks coming :) | 19:03 |
| vila | maxb: I just do a debchange/debcommit/debuild -S/dput dance | 19:03 |
| maxb | but don't you have this in a bzr branch? | 19:03 |
| vila | maxb: I do | 19:04 |
| maxb | "bzr mark-uploaded" is "bzr tag <figure it out from the changelog>" | 19:04 |
| vila | hmm, done | 19:05 |
| maxb | yay :-) | 19:05 |
| vila | pushed | 19:05 |
| vila | so the branch lacks a proper tag for the previous version, but we can forget about that right ? | 19:06 |
| vila | I should do the same in the hardy branch though | 19:06 |
| vila | or should I create 1.0.0hardy1 first to catch up ? | 19:07 |
| vila | OMG that's why ubuntu version follow the alphabet ? | 19:08 |
| jam | sometimes I wonder what the Unicode people are smoking: http://www.fileformat.info/info/unicode/char/1f63c/index.htm | 19:09 |
| jam | "Unicode Character 'CAT FACE WITH WRY SMILE'" | 19:09 |
| vila | maxb: ^ ? | 19:14 |
| maxb | Yes that is one of the reasons for ubuntu versions following the alphabet :-) | 19:15 |
| vila | maxb: cool :) And about creating a 1.0.0hardy1 version ? | 19:16 |
| maxb | There is no particular need to do 1.0.0hardy1, I would call the hardy branch the 'trunk' and let it use plain version numbers | 19:16 |
| vila | ok | 19:16 |
| radix | jam: FINALLY I've been wanting that codepoint for *ages* | 19:34 |
| maxb | File "/home/maxb/wc/bzr/qbzr/ppa/karmic/lib/tests/modeltest.py", line 69, in nonDestructiveBasicTest | 19:53 |
| maxb | assert(self.model.columnCount(QtCore.QModelIndex()) >= 0) | 19:53 |
| maxb | TypeError: QAbstractItemModel.columnCount() is abstract and cannot be called as an unbound method | 19:53 |
| maxb | Anyone qbzr-involved around who can interpret that? | 19:53 |
| maxb | The current qbzr packaging turns on the tests on the buildds, and it fails like that for karmic | 19:54 |
| maxb | I am now wondering if anyone actually uses qbzr from the ppa on karmic | 19:54 |
| maxb | or jaunty even | 19:54 |
| vila | gary gary where are you ??? garyvdm (hoping to trigger a curl/grep daemon) | 20:01 |
| vila | maxb: this smells like a qt dependency, filing a bug on qbzr may be your best bet | 20:02 |
| vila | mgz, jam: What will happend if bzr selftest has to access to the TEMP dir ? | 20:03 |
| vila | d for devil | 20:03 |
| vila | mgz, jam: in windows that is | 20:04 |
| jam | vila: if it has to, then it will access it... | 20:05 |
| jam | I don't quite understand your question | 20:05 |
| jam | are you wondering *where* temp is? | 20:05 |
| vila | it turns out babune has no write access (nor read even) to TEMP (c:\WINDOWS\TEMP) | 20:05 |
| vila | yet most of the tests pass... So I wonder how :D | 20:06 |
| jam | are you sure $TEMP isn't C:\Documents and Settings\<user>\Application Data\Local\Temp ? | 20:06 |
| jam | check what | 20:07 |
| jam | tempfile.mkstemp() returns | 20:07 |
| vila | nothing :-DF | 20:09 |
| vila | ha, no typo of course | 20:09 |
| vila | c:\\windows\\temp\\tpmxxxx | 20:09 |
| jam | or tempfile.NamedTemporaryFile().name | 20:10 |
| vila | blink | 20:10 |
| jam | vila: are you *sure* it doesn't have access :) | 20:10 |
| jam | I'm not sure the protection model for winxp, but it may be impossible to block the standard temp dir, or something | 20:10 |
| vila | that's weird, if I set TEMP to a dir I create myself the offending test pass | 20:10 |
| vila | jam: right, it has access, but... something goes wrong just for this test... | 20:17 |
| jam | we use $TEMP for the whole test suite, so I would be surprised if that was the specific failure | 20:19 |
| jam | maybe the path depth is getting too long? | 20:19 |
| vila | no, simple file name | 20:19 |
| jam | (more than 260 chars?) | 20:19 |
| vila | and my test dir is longer than windows/temp | 20:19 |
| vila | right, and from a cygwin shell TEMP is set as you said and the test pass | 20:24 |
| vila | so definitely some weird user setup, I fixed some, but more is needed, but enough for tonight, probably the ssh server fail to setuid properly, I may have to tweak the service definition and reboot or something-ish :) | 20:26 |
| poolie | hi jam, spiv | 21:01 |
| jam | hi poolie | 21:01 |
| poolie | jam, join #ubuntu-meeting? | 21:02 |
| dOxxx | I return! | 21:52 |
| jelmer | \o/ | 21:53 |
| dOxxx | so the eventual decision was that the installer for bzr 2.2.2 should include subvertpy 0.7.5 and bzr-svn 1.0.5? | 21:54 |
| jelmer | dOxxx: I don't remember releasing 1.0.5 :-) | 21:54 |
| jelmer | dOxxx: but other than that, yes. | 21:55 |
| dOxxx | (09:34:48) vila: so, bzr-svn 1.0.5 is targeted at 2.x for x in [0,1,2,3] :) | 21:55 |
| dOxxx | did he mean 1.0.4? | 21:55 |
| jelmer | dOxxx: no, 1.0.5 is in development at the moment | 21:56 |
| dOxxx | ah | 21:56 |
| dOxxx | um | 21:56 |
| dOxxx | jelmer: So, just to be sure, bzr-svn 1.0.4 should be bzr 2.2 compatible, right? | 21:59 |
| maxb | jelmer: speaking of which, when are you going to release 1.0.5 :-) | 22:00 |
| maxb | Would be nice to get those kde code imports that are currently being imported by my desktop on to launchpad proper | 22:00 |
| poolie | jam, hi, still around? | 22:14 |
| jelmer | maxb: I don't have any immediate plans, would like to get those ghost issues resolved first. | 22:14 |
| jelmer | maxb: It should be possible to cherrypick the new release for launchpad though, new bzr-svn releases have to be cherrypicked anyway. | 22:15 |
| maxb | jelmer: cherrypick as in merge just the relevant fixes into the ~launchpad-pqm branch? | 22:19 |
| jam | poolie: yeah, I'm still here | 22:20 |
| jelmer | maxb: No, sorry - I used the wrong word. I meant to say new bzr-svn releases have to be merged manually for lp anyway. | 22:21 |
| poolie | sorry otp at the moment | 22:22 |
| maxb | yes... but that is dependent on there being a new upstream release first :-) | 22:22 |
| jam | np, you were looking for me :) | 22:22 |
| jelmer | maxb: not really, we've merged snapshots in the past. | 22:22 |
| maxb | So I should review whether there's a comfortable point on lp:bzr-svn/1.0 which we can be happy about using | 22:23 |
| jelmer | maxb: Yes; hopefully that will be trip. | 22:23 |
| jelmer | *tip | 22:24 |
| vila | dOxxx: if 1.0.5 is not released, it's ok to put it in 2.3, hoping for jelmer to release it before 2.3 is final, for 2.2, we should stau with officially released versions, so 1.04, sory for the confusion, I was looking at the source in bzr-mac-installer/2.3/src/bzr-svn | 22:26 |
| vila | s/stau/stay/ | 22:26 |
| * vila off to bed ;) | 22:26 | |
| peitschie | nite vila | 22:30 |
| peitschie | (mornin jelmer, poolie, jam, maxb, dOxxx... woah.. busy today!) | 22:31 |
| poolie | bye vila | 22:35 |
| maxb | Does anyone know what the graph.sh in hydrazine is intended to be used with? | 23:38 |
| maxb | Because the data collection part of the puzzle appears to be missing | 23:39 |
| maxb | I am wondering if we should delete graph.sh from hydrazine | 23:39 |
| maxb | (poolie perhaps?) | 23:39 |
| _habnabit | Is there a thing anyone knows of that visualizes branching and merging? | 23:47 |
| dash | _habnabit: 'bzr qlog' | 23:47 |
| dash | or 'bzr vis' | 23:47 |
| _habnabit | Aha. | 23:47 |
| dash | depending on if you have the qt or gtk plugins installed | 23:48 |
| _habnabit | Apparently I have neither. | 23:48 |
| maxb | I recommend qlog. Even though I am a GNOME user. | 23:50 |
| maxb | qlog is just too shiny not to use, even if I have to install all of Qt to do it | 23:50 |
| _habnabit | Is there something that can spit out a dot file, maybe? | 23:50 |
| poolie | maxb, it's pretty old, i think we should delete it | 23:56 |
| poolie | if the collection code is checked in at all, it will be there | 23:56 |
| poolie | it never got to a super useful state though | 23:56 |
| poolie | i thought there was a count-bugs.py or something? | 23:56 |
| maxb | There is, but it emits human-readable text, not rrd anything | 23:57 |
| spiv | _habnabit: there is somewhere | 23:57 |
| spiv | _habnabit: the graph-ancestry command from bzrtools | 23:58 |
| _habnabit | Aha. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!