| urbanape | jelmer: http://paste.lisp.org/display/123948 | 00:05 |
|---|---|---|
| poolie | hello all? | 06:27 |
| spiv | poolie: hi ;) | 06:35 |
| poolie | hello | 06:35 |
| poolie | could you sanity check https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71154 | 06:35 |
| spiv | poolie: ugh, but +1 | 06:45 |
| vila | Morning all ! | 06:47 |
| poolie | hi vila, and goodbye | 06:47 |
| poolie | i might be back later | 06:47 |
| vila | hi poolie, cu later | 06:47 |
| jam | morning vila and poolie (if you are back) | 08:08 |
| vila | hello jam | 08:08 |
| jam | brb, pidgeon forgot who I am again | 08:09 |
| jelmer | hi jam, vila, poolie | 08:41 |
| jam | morning jelmer | 08:41 |
| vila | jelmer: hey ! | 08:41 |
| * fullermd continues in his quest to outlaw mornings... | 08:44 | |
| * vila suggests to shut down the sun | 08:45 | |
| vila | oh wait Oracle did that already | 08:45 |
| * fullermd *rimshot* | 08:45 | |
| fullermd | Shutting down the sun would have the added bonus of the temperature staying out of the 3 digit range. For a while, anyway. | 08:46 |
| vila | nah, bad plan, it will make it harder to boil water (that's what the 3 digit temperatures are about really) and as such coffee production will become harder, definitely a no-go | 08:48 |
| fullermd | You can cold press coffee, in extremis. I just wish it would stop trying to boil water everywhere outside my front door. | 08:49 |
| vila | :) | 08:50 |
| vila | In other news, with tag fetching being optional and equality_funcs.clear workaround in place and bug #822571 fix backported to 2.4, I'm ready to freeze 2.4.0 | 08:51 |
| ubot5 | Launchpad bug 822571 in Bazaar 2.4 "bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home fails" [High,Fix released] https://launchpad.net/bugs/822571 | 08:51 |
| jelmer | vila: \o/ | 08:51 |
| jelmer | hi Riddell | 08:51 |
| vila | jam, poolie, jelmer: pqm was very slow the day before yesterday, dunno if this has changed, but to be safe, please leave pqm alone (or I'll ask losas to kill the submissions ;) | 08:52 |
| Riddell | hello jelmer | 08:52 |
| vila | Riddell: hey ! You're back :) | 08:52 |
| vila | Riddell: welcome back then :) | 08:52 |
| jelmer | Riddell: how's the desktop summit? | 08:53 |
| vila | Riddell: please leave pqm alone too ;) | 08:53 |
| jelmer | vila: :) | 08:53 |
| Riddell | jelmer: desktop summit was fun, I got some ideas for Bazaar | 08:53 |
| fullermd | Apparently I'm still allowed to ridicule pqm about its childhood etc though. | 08:53 |
| vila | fullermd: sure :) | 08:54 |
| jelmer | Riddell: cool | 08:55 |
| === kedare_ifr is now known as kedare | ||
| === yofel_ is now known as yofel | ||
| maxb | poolie: I'm curious about your UDD change today, because the previously existing code in udd should have already accounted for the issues concerned | 09:40 |
| jam | vila: babune just stopped responding for me, did something happen? | 09:53 |
| vila | jam: nothing I'm aware if | 09:54 |
| vila | of | 09:54 |
| vila | even | 09:54 |
| spiv | maxb: that probably explains why his change didn't make any difference on production :) | 10:05 |
| jam | vila: seems it was just slow because I was loading multiple pages at once | 10:06 |
| jam | or maybe something on my end, given I just DCd from IRC | 10:07 |
| jam | vila: I can't reproduce the "PermissionError" bugs, but some of the others I can fix | 10:08 |
| vila | \o/ | 10:12 |
| jam | vila, mgz: One of the tests is a testtools bug | 10:29 |
| jam | well, test_selftest is asserting the output | 10:29 |
| jam | however the "if" check says "if version <= (0,9,11)" | 10:29 |
| jam | but my testtools.__version__ == (0, 9, 11, 'final', 0) | 10:30 |
| jam | which is > version | 10:30 |
| jam | anyway, "testtools_version[:3] <= " works | 10:30 |
| vila | jam: I plan on upgrading testtools on the slaves asap, will that workaround the issue ? (a fix would be better nevertheless) | 10:31 |
| jelmer | I guess we could fix the check to use testtools_version[:2] | 10:31 |
| jam | jelmer: [:3] | 10:31 |
| jam | :2 is (0,9) | 10:31 |
| jam | (it is an exclusive range) | 10:31 |
| jelmer | jam: ah, right | 10:33 |
| jam | vila: both selftest failures were because of that | 10:33 |
| jam | I don't know if there is anything else, though, and this is an easy fix | 10:33 |
| vila | jam: you mean for windows or you looked at all slaves ? | 10:34 |
| jam | vila: https://code.launchpad.net/~jameinel/bzr/2.5-win32-fixes/+merge/71176 | 10:34 |
| jam | vila: On the windows slave is what I was looking at | 10:35 |
| vila | k | 10:35 |
| jam | it was checking against 0.9.11 but the checks had the wrong bounds because of the 3-tuple vs 5-tuple | 10:35 |
| poolie | hello maxb | 11:23 |
| poolie | maxb, i think my change was misguided anyhow, as it doesn't seem to have fixed it | 11:25 |
| vila | poolie: I think I lost track about what was planned for pqm, but landing a patch takes more than 3 hours these days so we probably want to do *something* ;) | 11:27 |
| poolie | ah, maybe due to it syncing a lot while running the tests? | 11:28 |
| vila | ouch | 11:28 |
| vila | I was hoping for some unusual load there or some other misbehavior of the host instead :-} | 11:30 |
| poolie | that's possible too | 11:30 |
| poolie | ask a losa for help? | 11:30 |
| vila | poolie: sure, I wanted to check if I was up-to-date first. So nothing has occurred lately right ? | 11:31 |
| poolie | i'm not aware of anything else that could have broken it | 11:31 |
| vila | ok | 11:31 |
| fullermd | What sort of hardware does it sit on? | 11:31 |
| poolie | oh, tom was doing some work on setting up a new pqm box, but i didn't read anything about him having changed the existing machine | 11:31 |
| poolie | fullermd: an old DL-series hp server i think | 11:32 |
| fullermd | Running raw, not virtualized? | 11:32 |
| poolie | in a chroot | 11:32 |
| poolie | biab | 11:32 |
| fullermd | Wouldn't expect the fsync stuff to make a night and day change. | 11:34 |
| vila | fullermd: I don't have hard numbers but it seems we went from < 2 hours to > 3 hours | 11:34 |
| fullermd | Though the cost isn't trivial. Still, sounds like an OOM-ish hit on PQM from whatever. | 11:35 |
| fullermd | Hm. I figured pqm ran the test suite in 20, 30 minutes. | 11:35 |
| jelmer | vila: are you done with pqm? | 11:35 |
| fullermd | The timing poolie gave in the MP for fdatasyn showed ~20% increase. | 11:36 |
| vila | jelmer: not yet, still at least one submission to open 2.4.1 (which requires the current one to finish) and potentially a second submission to merge 2.4 to trunk | 11:37 |
| jelmer | vila: *nod* | 11:38 |
| vila | jelmer: thanks for your patience (though mine is running thin....) | 11:38 |
| poolie1 | hi vila, jelmer | 11:39 |
| jelmer | hey poolie1 | 11:40 |
| vila | poolie1: so, tom said the new pqm may be ready in a week or two | 11:40 |
| vila | also, it seems we're racing with u1 on the actual one which may explain the slowing | 11:40 |
| poolie1 | ok | 11:44 |
| poolie1 | we should see about turning off fdatasync during tests | 11:44 |
| jam | poolie1: did you see that your config stuff for fdatasync doesn't work? | 11:45 |
| jam | the new ConfigStack doesn't know about 'bool' | 11:45 |
| jam | so setting it to "False" returns a string which evaluates to True always | 11:45 |
| jam | I think you could set it to the empty string | 11:45 |
| jam | or an empty list | 11:45 |
| jam | (btw, you don't have any tests for it working. :) | 11:45 |
| poolie1 | :/ | 11:46 |
| jam | poolie1: I only found out because I was trying to copy your work for my config | 11:46 |
| jam | and hey, setting it to False doesn't do anything wth? | 11:46 |
| poolie1 | we'd better fix that for 2.4.0 then | 11:46 |
| vila | that would be for 2.4.1, 2.4.0 is already cut and landing on pqm, with tag | 11:51 |
| poolie1 | are the criticals all fixed+ | 11:54 |
| poolie1 | apparently yes,that's great | 11:54 |
| poolie1 | jam, did you file a bug for that? | 11:55 |
| vila | yes, I downgraded one since it was covered by the optional tag fetching | 11:55 |
| vila | we way still want to bump it to critical for udd though | 11:55 |
| vila | poolie1: I'm talking about bug #806348 | 12:04 |
| ubot5 | Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348 | 12:04 |
| vila | surprising... ubot5, why do you report about launchpad when bzr is the first project listed on the page and the primary project seems to be udd... | 12:06 |
| vila | (primary as in: http://pad.lv/806348 resolves to https://bugs.launchpad.net/udd/+bug/806348) | 12:06 |
| ubot5 | Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] | 12:06 |
| vila | bah | 12:07 |
| poolie1 | mm? | 12:07 |
| Riddell | vila: can I send things to PQM yet? | 12:11 |
| vila | Riddell: nope | 12:11 |
| vila | Riddell: :) | 12:11 |
| vila | Riddell: or rather, you can, but I will ask a losa to kill it ;) | 12:11 |
| === hexsprite_ is now known as hexsprite | ||
| poolie1 | vila, when did you first notice problems? | 12:16 |
| vila | I think I asked to jelmer a couple of days ago | 12:17 |
| vila | I tried toying with webnumber but it's not accurate enough to be conclusive | 12:17 |
| vila | http://webnumbr.com/bzr-pqm-queue-length.from%282011-06-27%29.to%282011-06-28%29 | 12:18 |
| vila | http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-09%29 | 12:18 |
| poolie1 | i don't think that's going to really correlate with much though | 12:43 |
| poolie1 | i guess we could look at mail that was sent to pqm and when it was returned but it's probably easier to see if the sysadmins can find a log for you | 12:44 |
| vila | poolie1: yeah, but since the new hardware is expected soon-ish, I'm not sure it's worth investigating either (tom prefer to focus on the new hardware and I see no point disturbing it) | 12:52 |
| jam | vila: because L comes before U, but magically after B? | 12:52 |
| poolie1 | ok i think i understand the httperror bug | 12:52 |
| vila | poolie1: \o/ | 12:53 |
| vila | jam: I killed your windows fixes submission and re-submitted it | 12:53 |
| jam | vila: you're the one that killed my submission? | 12:53 |
| jam | k | 12:53 |
| jam | I was a bit concerned about a failed test run with no failures | 12:53 |
| vila | jelmer, Riddell : feel free to overload pqm now ;) | 12:53 |
| jelmer | \o/ | 12:54 |
| Riddell | vila: what happened? | 12:54 |
| poolie1 | vila, did you actually kill it or just ask for it to be killed? | 12:55 |
| vila | Riddell: cutting a release requires two submissions: one for the release and its tag, one to open the branch for bugfixes, I prefer to pull between the two and not leave the branch in the transient state where nobody can land | 12:56 |
| vila | poolie1: I asked a losa | 12:56 |
| urbanape | jelmer: sorry I didn't get back to you earlier last night. | 12:57 |
| jam | poolie1: he rooted the machine via DDOS and a bug in pqm's web front end, I think :) | 12:58 |
| jam | he's really determined that his patch be next | 12:58 |
| jelmer | urbanape: np, I'm afraid I don't really have an answer either though. It seems like the issue is with the way the vcs-bzr script in emacs runs | 12:58 |
| jelmer | urbanape: (without a tty) | 12:58 |
| urbanape | gotcha. okay, bummer | 12:58 |
| urbanape | aha! | 13:01 |
| urbanape | awesome | 13:01 |
| urbanape | I added --no-tty to my agent-gpg script | 13:01 |
| urbanape | ta-da | 13:01 |
| jam | poolie1, vila: Even more fun. If you do "c = ConfigStack(); c.set('foo', True); c.get()" Returns True the object. But if you write it out, and then create "c2 = ConfigStack(); c2.get()" it returns u'True' the string. | 13:01 |
| jelmer | urbanape: ah, that was easy :) | 13:02 |
| poolie1 | yuk | 13:02 |
| urbanape | jelmer: it was | 13:02 |
| vila | jam: see my boolean-option (submitted to pqm) | 13:03 |
| jam | vila: sure. I'd put it pretty high in the 2.4.1 queue, given that one of the caveats for fdatasync is that people can disable it if they notice a slowdown | 13:04 |
| poolie1 | thanks vila | 13:04 |
| jam | vila: I'm a bit concerned that it requires an api break for a stable series. Should we just switch the code to config.get_user_option_as_bool() ? | 13:05 |
| jam | (I guess it isn't a major break) | 13:06 |
| vila | jam: the easiest may be to not use configstack at all for the datasync options then. Alternatively, options are strings unless specified otherwise (and in 2.4 nobody specifies otherwise ;) | 13:06 |
| vila | jam: yup, that's another alternative, whatever works | 13:06 |
| vila | jam: but I agree, backporting boolean-option to 2.4 is a no-go | 13:07 |
| vila | jam: and thanks for spotting the issue | 13:08 |
| jam | bug #824513 | 13:08 |
| ubot5 | Launchpad bug 824513 in Bazaar 2.4 "config item repository.fdatasync doesn't work as expected" [High,Confirmed] https://launchpad.net/bugs/824513 | 13:08 |
| vila | the 2.4.1 milestone has been created and the lp:bzr/2.4 is almost opened for bugfixes (you have to wait for the current submission to land to base your branch and get the proper news file) | 13:10 |
| vila | Riddell: see above for why I don't like to leave the branch in this transient state :0D | 13:10 |
| vila | poolie1: the suspense is killing me, what caused the httperror ?? | 13:12 |
| vila | :) | 13:12 |
| poolie1 | see the bug | 13:13 |
| vila | wow | 13:18 |
| jonathanj | where does bzr cdiff get its colour information from? | 13:20 |
| poolie1 | that was such an annoying api break | 13:24 |
| poolie1 | i have some uncommitted changes that i think ought to fix it, but perhaps they don't | 13:24 |
| === mwhudson_ is now known as mwhudson | ||
| fullermd | Gruuh, LP makes bzrtools difficult... | 13:42 |
| fullermd | It says the latest is 2.3.0. You have to dig to find that (a) there's a 2.3.1 succeeding that, and scroll way down in a list to find 2.4.0. | 13:42 |
| vila | fullermd: gigo :-/ | 13:55 |
| fullermd | It always makes me laugh (funny dear-god-no, more than funny ha-ha...) at how every new bzr release makes me have to work with CVS :| | 13:57 |
| urbanape | jelmer: hmm, I must have done something slightly odd, because now subsequent commits are now blocked. Getting errno 13: Permission denied. I don't see any lock files in the branch-lock directory under .bzr. | 13:59 |
| jelmer | urbanape: are you sure it's bzr that's blocked, not gpg? | 14:16 |
| Chex | hello there, can someone help me with a bzr branch issue I am having, trying to deploy branches for ISD ? | 14:36 |
| Chex | jelmer: I was given your name to try to see if you could help me. :) | 14:36 |
| jelmer | Chex: hey! | 14:37 |
| jelmer | Chex: Of course, happy to help | 14:37 |
| Chex | jelmer: awesome, thank you.. look here: https://pastebin.canonical.com/51102/ | 14:37 |
| Chex | and here, for related info: https://bugs.launchpad.net/config-manager/+bug/823010 | 14:37 |
| ubot5 | Ubuntu bug 823010 in config-manager "bzrlib error, cannot find revision in branch" [Undecided,New] | 14:38 |
| Chex | jelmer: this is a private branch, you wont be able to pull it yourself, but the account we are using has proper access to the branch | 14:39 |
| gour | is colo-branches same thing as hg's named branches? | 14:58 |
| jelmer | hi gour | 15:01 |
| gour | jelmer: hiya | 15:02 |
| jelmer | gour: in some regards | 15:02 |
| gour | I'm now pulling via bzr-hg from google | 15:02 |
| jelmer | gour: it's not exactly the same thing, but they both allow using multiple branches under one file system location. | 15:02 |
| jelmer | gour: did 2.4 work any better for the large branch for you yesterday? | 15:02 |
| gour | jelmer: not much...i killed it...however repo @google is 24M..it makes a difference | 15:03 |
| gour | it was more speedy, but still too slow | 15:04 |
| gour | ahh...conection with google dies after 8mins | 15:05 |
| jelmer | gour: well, it's almost 600Mb of compressed data | 15:05 |
| gour | jelmer: right...it's big repo | 15:06 |
| gour | now tryingto pull from google with 2.4 | 15:06 |
| gour | otoh, hg's named branches are cool...they're, iirc, in mtn, fossil | 15:07 |
| jelmer | gour: branch nicks in bzr are pretty similar | 15:08 |
| jelmer | gour: when tracking what branch a revision came from | 15:08 |
| jelmer | colo-branches is more like git branches | 15:08 |
| jelmer | the combination gives you something similar to hg branches | 15:08 |
| gour | hmm...it looks i've to re-read bzr docs a bit | 15:09 |
| gour | based on taht i read in hg docs, bookmarks are similar to git branches | 15:09 |
| jelmer | gour: that's hg bookmarks probably, though? | 15:10 |
| gour | yes, hg bookmarks | 15:10 |
| gour | too bad LP does not have project wikis like bitbucket... | 15:13 |
| jelmer | there was somebody working on that | 15:13 |
| jelmer | jml: do you know how far that's gotten? | 15:13 |
| gour | well, bug is quite old and still not on horizon (low priority) | 15:14 |
| gour | jelmer: how do bzr & hg compare today, considering 2.4 & 1.9.x ? | 15:15 |
| gour | (in general) | 15:15 |
| jelmer | gour: There was a community developer actively working on it a month or two ago | 15:15 |
| jelmer | gour: I'm not sure, my familiarity with hg doesn't really extend beyond the lower levels | 15:16 |
| gour | ok | 15:20 |
| jelmer | vila: when is 2.4.0 scheduled for? | 15:21 |
| gour | pulling with bzr-hr from google is slow.. | 15:21 |
| jelmer | gour: sure, bzr-hg is still fairly experimental and not really optimized yet | 15:22 |
| vila | jelmer: next Tuesday | 15:22 |
| jelmer | vila: roger | 15:23 |
| vila | jelmer: if pqm can handle the load :-/ | 15:23 |
| vila | err :) | 15:23 |
| jml | jelmer: how far what? | 15:26 |
| jelmer | jml: the wiki LEP, do you know what happened to it? | 15:26 |
| jml | jelmer: yeah. it's finished & rotting. | 15:28 |
| jelmer | jml: :-( | 15:28 |
| jml | jelmer: I didn't expect otherwise. Long drawn-out conversations about how we should do something that no one is actually planning to do tend to end this way. | 15:29 |
| gour | ok...16mins...let's try to push to LP now | 15:29 |
| === zyga is now known as zyga-afk | ||
| jelmer | jml: I guess it means at least we have *some* idea of the constraints and requirements | 15:37 |
| jml | jelmer: yeah, I hope so. Although until people are actually using it, it's all just waste. | 15:39 |
| === beuno is now known as beuno-lunch | ||
| urbanape | jelmer: not sure. But removing arguments from my vc-bzr-gpg script so that it just calls '/usr/bin/gpg $@' doesn't clear it up, and adding -v to the bzr ci doesn't offer any more information. | 15:49 |
| mthaddon | anyone able to help me troubleshoot the new PQM server? | 15:53 |
| mthaddon | getting https://pastebin.canonical.com/51118/ and test suite has been running for 50 mins or so | 15:54 |
| vila | mthaddon: for bzr ? | 16:05 |
| mthaddon | vila: yeah, for the new bzr pqm server | 16:06 |
| vila | 50mins is not unusual | 16:07 |
| vila | the warnings are a bit worrying though, pqm needs some update obviously | 16:07 |
| mthaddon | vila: but this is on much faster hardware, with nothing else happening on the box | 16:07 |
| vila | do you have /tmp on a tmpfs ? | 16:08 |
| mthaddon | vila: it's running the same version of PQM as the current PQM instance | 16:08 |
| mthaddon | vila: nope (nor does the current one) | 16:08 |
| mthaddon | (will be doing that later once we get one successful run) | 16:08 |
| vila | huge boost for bzr test suite, but you're the judge | 16:08 |
| vila | anyway, there should be one or two files to track progress, let me check the makefile | 16:09 |
| vila | 'selftest.log' in the directory where the command run | 16:09 |
| vila | mthaddon: running 'subunit-stats < selftest.log' may even gives you a summary | 16:10 |
| mthaddon | vila: that doesn't seem to have updated since 2011-07-27... | 16:11 |
| mthaddon | nm, my mistake | 16:11 |
| vila | np | 16:11 |
| mthaddon | vila: https://pastebin.canonical.com/51122/ | 16:12 |
| vila | mthaddon: something bad is going on, NoSuchFile in _check_safety_net... doesn't make sense | 16:15 |
| mthaddon | vila: what kind of bad? | 16:15 |
| vila | unless the tmp dir was deleted before the end of the run ??? | 16:15 |
| vila | mthaddon: a kind I don't understand | 16:15 |
| vila | check_safety_net is there to protect against some test bugs, but I almost never see it fail | 16:16 |
| vila | spiv changed it recently IIRC but that was for performance reasons and I never see it fails either | 16:17 |
| vila | mthaddon: does /tmp/testbzr-W7TYpR.tmp/ exists ? | 16:17 |
| mthaddon | vila: https://pastebin.canonical.com/51124/ | 16:18 |
| vila | -R ? | 16:18 |
| mthaddon | https://pastebin.canonical.com/51125/ | 16:19 |
| vila | mthaddon: do you get the same result if you do that again ? (ls I mean) | 16:21 |
| vila | a lot of files are missing there | 16:21 |
| vila | and dirs | 16:22 |
| mthaddon | yeah, same result | 16:22 |
| vila | mthaddon: my best guess would be that something went wrong very early in the test suite and failed to build the safety net (a bzr tree that no test should modify) | 16:23 |
| vila | and now all tests fail because the net has been damaged (in fact, it looks like a branch lock failed halfway) | 16:24 |
| vila | mthaddon: but that's a wild guess as I said, I never saw such a failure | 16:24 |
| mthaddon | hmm | 16:24 |
| vila | mtaylor: the begining of selftest.log may shed some light ? | 16:24 |
| vila | mtaylor: sry, silly auto-completion | 16:27 |
| vila | mthaddon: the begining of selftest.log may shed some light ? | 16:27 |
| mthaddon | vila: chinstrap:~mthaddon/selftest.log.gz | 16:29 |
| micahg | does bzr + pristine-tar have the ability to reproduce .bz2 tarballs? | 16:36 |
| vila | mthaddon: wow | 16:36 |
| vila | KeyError: 'getpwuid(): uid not found: 2005 | 16:36 |
| maxb | micahg: Yes, I think it's just .xz that's the problem at the moment. | 16:36 |
| micahg | hmm, ok, I guess it was a bad merge-upstream then... | 16:37 |
| vila | mthaddon: and indeed it was in _create_safety_net | 16:37 |
| mthaddon | vila: so is that an environment issue, or a test suite issue? | 16:37 |
| vila | mthaddon: I suspect it's a chroot issue as we are trying to expand ~ and fails | 16:38 |
| vila | mtaylor: /etc/passwd missing entries in the chroot kind of stuff | 16:38 |
| mthaddon | vila: I think I can reproduce - thx, will get that fixed and retry | 16:39 |
| vila | mthaddon: cool, './bzr selftest -s bb.test_add.TestAdd.test_add_control_dir' in the chroot should reproduce it without running the full test suite | 16:40 |
| mthaddon | k | 16:40 |
| jelmer | maxb: .xz should work too, it's just fairly inefficient because pristine-tar doesn't have proper support for xz | 16:43 |
| jelmer | micahg: are you running oneiric? | 16:43 |
| micahg | jelmer: not on the machine I was doing this on | 16:44 |
| jelmer | micahg: there's a bug with bz2 support in natty, that might explain the issue you were seeing | 16:44 |
| * micahg tries in oneiric | 16:45 | |
| micahg | jelmer: nope, still fails to make a .bz2 tarball | 16:47 |
| jelmer | micahg: what fails exactly? | 16:48 |
| micahg | jelmer: I have no guarantee a bz2 tarball was even imported into the branch | 16:48 |
| micahg | it makes a .orig.tar.gz | 16:48 |
| jelmer | micahg: what command are you running? | 16:48 |
| micahg | bzr bd --orig-dir=../tarballs/ | 16:49 |
| jelmer | micahg: how was the upstream tarball imported into the branch? | 16:50 |
| micahg | no idea | 16:50 |
| jelmer | micahg: it's likely that it went wrong there | 16:50 |
| micahg | supposedly using bzr merge-upstream, will have to find out later, too close to FF to debug | 16:50 |
| jelmer | micahg: is the branch public? | 16:50 |
| micahg | jelmer: let me get some more information from the committer and get back to you, wouldn't want you to go on a wild goose chase | 16:51 |
| jelmer | micahg: thanks | 16:53 |
| === kedare is now known as kedare_ifr | ||
| === beuno-lunch is now known as beuno | ||
| === abentley_ is now known as abentley | ||
| === zyga-afk is now known as zyga | ||
| === Vorpal_ is now known as Vorpal | ||
| jml | mgz: this bytes/unicode thing is doing my head in | 18:13 |
| mgz | ehhee | 18:13 |
| mgz | jml: and if you've not read PEP 383 yet, which poolie linked the other day, know that it only gets messiuer | 18:14 |
| mgz | -u | 18:14 |
| mgz | I think testtools is basically there, on a hard problem, apart from two things | 18:15 |
| jml | I haven't. | 18:15 |
| mgz | 1) Matcher and Mismatch classes need to not use %s, specifically StartsWith and MatchesRegex | 18:16 |
| mgz | 2) __str__ on Python 2 should mangle to ascii rather than return unicode and blow things up | 18:17 |
| jml | Ahhh, you *say* that. | 18:17 |
| mgz | testtools can be smart and try __unicode__ first, and other if the objects leak into other less careful libraries they won't be harmed | 18:18 |
| mgz | in fact, testtools already is smart. | 18:18 |
| jml | mgz: you mean something like http://paste.ubuntu.com/663608/? | 18:18 |
| mgz | I'd have spelled it differently, but yup, looks about what I was thinking | 18:19 |
| mgz | did it cause issues? | 18:19 |
| mgz | the only issue remaining from there is to not let non-ascii bytestrings in, which is why StartsWith etc needs chaning | 18:20 |
| jml | mgz: yeah | 18:20 |
| mgz | *changing | 18:20 |
| jml | mgz: even on Equals(), you get an unprintable assertion. | 18:20 |
| mgz | that's the describe() return issue. | 18:21 |
| mgz | I think it might be best to check the type in that __unicode__ function and do something similar to how bytes() get repr-ed in Python 3, rather than trying to fix every method... | 18:23 |
| mgz | hm. | 18:23 |
| jml | http://paste.ubuntu.com/663616/ for something to muck around with. | 18:24 |
| mgz | yup, that's the kind of assertion that we want to work for people. | 18:24 |
| mgz | okay, I'll think a bit and throw some code up | 18:25 |
| mgz | ...not as in vomit, though I don't guarentee it won't look like that | 18:25 |
| jml | http://paste.ubuntu.com/663619/ | 18:25 |
| jml | more data | 18:26 |
| jml | mgz: heh heh | 18:26 |
| jml | mgz: also, I didn't really know how to turn your demo tests into actual tests. | 18:26 |
| jml | mgz: just pushed up my latest changes, fixes the _exception_to_text abstraction violation. | 18:27 |
| jml | mgz: but, however you choose to project your code onto the internet, it would be much appreciated. | 18:28 |
| mgz | yeah, I left the demo file as was because getting into another layer of assertions gets really confusing, it's clearer to just see the output as a testtools user would | 18:31 |
| jml | fair enough | 18:31 |
| mgz | tests for the things that then make those cases work as intended are writable | 18:31 |
| mgz | (what type the describe() method returns on non-ascii mismatches etc) | 18:32 |
| jml | cool. I tried naively turning them into tests, and they all passed, which isn't really what we want. | 18:32 |
| jml | yeah | 18:32 |
| jml | fwiw, https://bugs.launchpad.net/testtools/+bug/686807 might be relevant | 18:32 |
| ubot5 | Ubuntu bug 686807 in testtools "Having __str__ not __repr__ as part of the matcher protocol is awkward" [Wishlist,Triaged] | 18:32 |
| * mgz looks | 18:32 | |
| mgz | yeah, that change could probably just be made, the __str__ methods already return things that should work as object creation code, and str() falls back to repr() | 18:34 |
| mgz | ids in reprs only matter when the object identity is significant, newer Python code tends to omit them from the repr string when the objects are interchangable | 18:36 |
| mgz | repr(Exception("whatever")) has gone from '<exceptions.Exception instance at 0x00B097D8>' to "Exception('whatever',)" | 18:37 |
| jml | cool | 18:43 |
| jml | I might do that post release | 18:43 |
| jml | (I want to have this assertThat bug fixed for the next release though) | 18:44 |
| jml | I also just tried to reproduce the only remaining critical bug (https://bugs.launchpad.net/testtools/+bug/672056) and failed. | 18:44 |
| ubot5 | Ubuntu bug 672056 in testtools "UnicodeEncodeError: 'ascii' codec can't encode characters in position 2217-2258: ordinal not in range(128)" [Critical,Incomplete] | 18:44 |
| * jml goes to make some dinner | 18:45 | |
| mgz | me too :) | 18:46 |
| jml | <http://pypi.python.org/pypi/unicode-nazi> | 18:47 |
| mgz | ^I have hope that the issues involved in that bug have been seperately resolved, | 18:47 |
| jml | mgz: me too. I'm going to give Thomi a few days to reproduce the bug, and close it if he doesn't respond. | 18:48 |
| === micahg_ is now known as micahg | ||
| matttbe | Hello jelmer. | 21:08 |
| matttbe | micahg said to me that I've to chat with you about a bzr issue. | 21:08 |
| matttbe | I used this command (I think but pretty sure, on natty but it was with another computer...) | 21:08 |
| matttbe | bzr merge-upstream --version 2.1.1 --distribution=oneiric http://ftp.gnome.org/pub/GNOME/sources/latexila/2.1/latexila-2.1.1.tar.bz2 | 21:08 |
| matttbe | And it seems that if 'bzr bd' is used to create the source package, it creates a .tar.gz tarball from bzr instead of a .tar.bz2. So a problem to import the right package. | 21:08 |
| micahg | merge proposal with branch here: https://code.launchpad.net/~latexila/ubuntu/oneiric/latexila/2.1.1/+merge/70964 | 21:12 |
| === Quintasan_ is now known as Quintasan | ||
| jelmer | sorry, was away for a bit | 21:31 |
| jelmer | matttbe: thanks | 21:31 |
| === yofel_ is now known as yofel | ||
| poolie | hi all | 21:53 |
| jelmer | moinmoin | 21:56 |
| poolie | hi mgz | 22:03 |
| mgz | hey poolie! | 22:03 |
| jimis | How can I switch branch on a lightweight checkout, but keep uncommitted changes in that branch for when I come back? The only way I've found is shelve everything, unshelve when I switch back... | 23:18 |
| jimis | But can't I somehow tell switch to preserve local changes, and do it in one step? | 23:18 |
| spiv | jimis: oh, you mean you want the uncommitted changes to be hidden until you switch back? | 23:22 |
| spiv | jimis: shelving and unshelving is currently the best way to do what you want, I think. | 23:23 |
| spiv | jimis: It would be fairly easily to write a switch-and-auto-shelve plugin to automate that, I think. | 23:23 |
| spiv | (it'd override the 'switch' command to first shelve uncommitted changes to a shelf named after the current branch, do the switch, then unshelve from the shelf corresponding to the new branch) | 23:24 |
| jimis | thanks spiv | 23:25 |
| jimis | would be very useful as a switch option too | 23:25 |
| jimis | --shelve for example | 23:25 |
| spiv | jimis: hmm, could be. File a bug asking for the feature :) | 23:26 |
| spiv | jimis: (just paste in this IRC chat as the description if you want to be lazy) | 23:26 |
| jimis | spiv: the reason it's important for changes to be hidden when switching, is avoid unwanted conflicts | 23:27 |
| spiv | That said, a good way to prototype that feature would be to write the plugin :) | 23:27 |
| jimis | I've had such conflicts before and it took lot of my time | 23:27 |
| spiv | jimis: hmm, I think that's just as much an argument for a cheap way to undo the switch (and its conflicts) | 23:28 |
| jimis | spiv: that's doable? | 23:28 |
| jimis | it would be a live-savour, for *after* the conflict happened :-p | 23:28 |
| spiv | jimis: or perhaps an argument for being able to shelve the original changes after the switch | 23:29 |
| jimis | whatever | 23:29 |
| spiv | (i.e. a way to say “please shelf the unconflicted changes I had a moment ago”) | 23:29 |
| spiv | I think it's doable, I don't think it's *easy* currently. | 23:29 |
| jimis | but after the conflict, you are left with various files injected with conflict marks etc... it's a mess | 23:29 |
| spiv | Yeah, I know the feeling. | 23:29 |
| jimis | yeah, that's why I think it's better to watch out during the switch | 23:30 |
| spiv | And often you don't realise that conflicts are going to be messy until after you've got them. | 23:30 |
| jimis | I'd personally advocate for shelving on switch always and transparently, and only taking changes with you if you provide a special flag to switch | 23:31 |
| jimis | but I don't think current behaviour can be broken :-s | 23:31 |
| spiv | A cheap-ish alternative might be an option on switch to abort (and undo) if there are going to be conflicts | 23:31 |
| jimis | true | 23:31 |
| spiv | And then you can either commit/shelve/revert/whatever, or you can pass a --force or --allow-conflicts switch to say “that's ok, I'll cope” | 23:32 |
| jimis | Will submit feature request later, hopefully I'll find some time | 23:32 |
| spiv | In fact, 'bzr merge' already behaves somewhat like that | 23:32 |
| spiv | You have to --force for it to even start in the presence of uncommitted changes. | 23:32 |
| jimis | I wonder why switch is that dangerous... | 23:32 |
| spiv | (Although the rationale for merge doing that is not quite the same, there is some overlap) | 23:33 |
| jimis | probably because most people work with multi-directory branches, not single-dir checkouts | 23:33 |
| spiv | Yeah | 23:33 |
| spiv | Although as bzr-colo becomes more popular (and is slowly integrated into the core), your workflow will be more common. | 23:34 |
| jimis | but when you have huge projects with thousands of files, checkouts are one-way | 23:34 |
| spiv | Right | 23:34 |
| jimis | spiv: are you on the bzr team? | 23:34 |
| jimis | Because I wonder if any dev agrees with my experience | 23:36 |
| spiv | jimis: yes (was a fulltime developer working for Canonical until a couple of weeks ago, have just switched jobs but I still care and have commit rights etc) | 23:38 |
| jimis | cool | 23:38 |
| spiv | jimis: I'm pretty sure most, maybe all, the core devs agree with you that we should do better for that case | 23:39 |
| spiv | And there's been serious talk about switching to single-dir checkouts as the default way of working in a future release (i.e. integrating and polishing the bzr-colo plugin into the core, and then promoting its workflow to be more prominent than the current multi-dirs of branches in shared repo model) | 23:41 |
| jimis | very interesting | 23:41 |
| spiv | Obviously we'd want to smooth out as many kinks as possible before doing that, including yours :) | 23:41 |
| jimis | single-dir checkout of a no-trees branch is my current way | 23:41 |
| jimis | It's the only usable way for huge branches like lp:gcc | 23:42 |
| spiv | Right. | 23:42 |
| jimis | but I've never used colo plugin | 23:42 |
| jimis | generally I tend to avoid installing extras | 23:42 |
| spiv | bzr-colo is basically intended to make that a bit nicer to use | 23:42 |
| kwmiebach | Hi. I have used "bzr fetch ..." from a launchpad repository. How can I switch to an earlier revision locally? | 23:53 |
| kwmiebach | Lets say I am aat rev. 500 now and would ike to see rev 450 | 23:54 |
| spiv | 'bzr pull -r 450 .' (the dot is significant, it says to pull from the branch in the current directory, which will be a bit faster than looking for that same revision on the remote branch) | 23:56 |
| spiv | Depending on what you want to do, | 23:57 |
| spiv | 'bzr update', 'bzr revert', 'bzr cat', or 'bzr qlog' (that one from the qbzr plugin) may be better suited to your needs though. | 23:57 |
| kwmiebach | spiv, thank you so much, couldnt find it in the docs. | 23:58 |
| kwmiebach | i will go and try now | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!