| spiv | Good morning. | 00:54 |
|---|---|---|
| poolie | hi all | 01:34 |
| JaredW | I think there was a plugin that automatically finds the revision where something broke (by running a command on different revisions in a binary search). Does anyone remember the name? | 01:46 |
| spiv | bisect | 01:46 |
| poolie | hello spiv | 01:49 |
| spiv | Hi poolie | 01:50 |
| poolie | i might have a look at this spurious test failure | 04:32 |
| poolie | should we actually keep the strace facility? | 04:57 |
| poolie | nothing uses it but its own tests | 04:57 |
| poolie | lifeless: ^^ | 04:57 |
| poolie | i can see it being useful for some effort tests, but i can also see that causing deadlocks etc by trying to trace ourselves | 04:57 |
| lifeless | poolie: if its a pain, nuke it. | 04:59 |
| lifeless | I doubt I'll be doing low level perf work on bzr in the near term :( | 05:00 |
| poolie | :( | 05:00 |
| poolie | if you were, do you think you'd use this? | 05:00 |
| lifeless | I did anytime I needed strace stuff | 05:00 |
| poolie | how did you use it? by logging the activity of a particular bit of code? | 05:00 |
| poolie | or actually writing tests that inspected it? | 05:01 |
| lifeless | the former | 05:01 |
| poolie | i can see that being useful, to catch just a particular seciton | 05:03 |
| poolie | wbn for prof too | 05:03 |
| lifeless | right, prof does that :) | 05:04 |
| poolie | prof does what? | 05:05 |
| lifeless | sorry, brb | 05:05 |
| poolie | https://code.edge.launchpad.net/~mbp/bzr/626679-strace/+merge/34157 | 05:23 |
| lifeless | poolie: sorry, was otp | 05:24 |
| lifeless | back now | 05:24 |
| poolie | np | 05:24 |
| poolie | i decided it was worth keeping around | 05:24 |
| lifeless | bzrlib.lsprof lets you call a specific section easily. | 05:24 |
| poolie | you can review it if you have a moment | 05:24 |
| lifeless | when it updates the diff I shall | 05:25 |
| poolie | sorry i meant perf, not prof | 05:26 |
| poolie | which is an external tool like strace | 05:26 |
| fullermd | Most profs get annoyed if you perf them... | 05:26 |
| mkanat | Prof perf. | 05:27 |
| poolie | hello mkanat | 05:29 |
| mkanat | Hey poolie! | 05:29 |
| poolie | hi there | 05:29 |
| poolie | i'm back from my trip | 05:29 |
| mkanat | Oh great. :-) | 05:29 |
| poolie | did you get to working on loggerhead yet? | 05:29 |
| mkanat | poolie: I didn't, unfortunately. I'm thinking it will be after Sept 2. | 05:29 |
| mkanat | poolie: Although I did do a bit of work last week. | 05:30 |
| poolie | np, just wondered if you were blocked or anything | 05:30 |
| mkanat | poolie: Okay. :-) | 05:31 |
| vila | hi all ! | 08:00 |
| mgz | morning all. | 08:10 |
| mgz | vila: these are the tests that are different between r5395 and r5396 from my run: | 08:16 |
| mgz | http://float.endofinternet.org/temp/landed_leaking_diff.xml | 08:16 |
| vila | mgz: meh, http://float.endofinternet.org/temp/landed_leaking_diff.xml#bb.test_branch.TestSmartServerBranching.test_branch_from_trivial_branch_to_same_server_branch_acceptance | 08:18 |
| vila | AttributeError: 'TestAncestry' object has no attribute '_cleanups' ? You're cleaning up too much my dear :) | 08:18 |
| mgz | yeah, I think this is to do with TestCase instances sharing too much | 08:19 |
| vila | mgz: first you don't want me to use closures and now I can't even use cleanups ? :) | 08:19 |
| mgz | no, I just think it's a pre-existing bug :) | 08:19 |
| mgz | like bug 625574 or something | 08:19 |
| ubot5 | Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625574 | 08:19 |
| vila | mgz: TestCase instances sharing... anything sounds scary, that needs to be precisely diagnose to know whether or not we can do that (by default: no, but there could be exceptions for read-only things (methods, functions, whatever, I think there is at least a _test_root_dir or something that is legal to share))))) | 08:21 |
| vila | mgz: hmm, interesting bug... this really needs to be dug | 08:22 |
| vila | mgz: anyway, back to your initial remark, can you summarize your feelings about the differences ? | 08:23 |
| mgz | well, took 72mins vs. 51mins which I think I can live with for the moment, and basically everything but the run time is an improvement | 08:25 |
| mgz | (pretty sure all the new orange is equally shallow) | 08:26 |
| vila | mgz: so on this precise point, I'm pretty sure it's only the hung threads adding their 5s timeouts which a 'kill thread' should fix | 08:26 |
| mgz | I prefer 5s waits to thread killing. | 08:26 |
| vila | why ? | 08:26 |
| mgz | TerminateThread is scary in a way TerminateProcess isn't | 08:27 |
| vila | I've diagnosed those as being: both client and server are waiting for each other or, said otherwise, python seem to not shake some bytes in the socket under unknown scenarios only encountered on windows | 08:27 |
| vila | mgz: ha, yes, this fear :) Well, the plan is to test first how this behaves, since all threads (we care about in this precise case) catch exceptions, it will be totally safe (the kill will happen during test shutdown where, by definition, we know we are done with whatever socket or any other resource used) | 08:29 |
| mgz | ah, you just mean raising an exception in the threads? | 08:31 |
| vila | spiv: have you seen bug #626876 | 08:31 |
| ubot5 | Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876 | 08:31 |
| mgz | not killing them dead? | 08:31 |
| vila | mgz: hehe, 'kill thread' is implemented by raising an exception in the thread :) | 08:31 |
| vila | and AFAIK we can raise *any* exception | 08:32 |
| vila | but that's what I want to test | 08:32 |
| mgz | okay, that's less scary then | 08:32 |
| vila | good | 08:33 |
| vila | Knowledge 1 - Ignorance (driving fear) 0 | 08:34 |
| mgz | I'm out for the day, see y'all later. | 08:49 |
| lifeless | ciao | 08:53 |
| spiv | vila: seen, yes. Thought carefully about... not yet :) | 08:55 |
| vila | lifeless: cu | 08:55 |
| vila | spiv: right, so I think there are two ways to rewrite it: 1) use a server in the same process, 2) spawn a real server as a separate process | 08:56 |
| vila | the actual version is a mix of both (the real server is spawned at connection time) | 08:56 |
| vila | I favour (1) and may give it a shot today | 08:57 |
| poolie | hi mgz, vila | 09:00 |
| vila | poolie: hey !! | 09:00 |
| poolie | thanks for the speedy review vila | 09:01 |
| vila | my great pleasure ;) | 09:01 |
| vila | poolie: made me feel, like, 5 years younger or something :) | 09:02 |
| poolie | :) | 09:07 |
| === idart_ is now known as idart | ||
| GaryvdM | Hi vila. I'm trying to fix the test error with https://code.edge.launchpad.net/~vila/qbzr/config-get-filename-deleted/+merge/34095 | 12:16 |
| GaryvdM | It's failing because TEST_DIR/home/.bazaar does not exist. | 12:17 |
| GaryvdM | vila: Can you give me any pointers on how to fix? | 12:18 |
| vila | GaryvdM: that's ensure_config_dir() call missing, rats, old bzr or current ? | 12:24 |
| vila | GaryvdM: lunch time, here, bbl-ish | 12:25 |
| GaryvdM | vila: That error is only on old bzr, not on current | 12:25 |
| GaryvdM | vila: ok - Busy reading diff of you lock config files patch | 12:25 |
| vila | GaryvdM: right, ok, so for old you can call ensure_confdir_exist with a check for bzr version :-/ | 12:26 |
| vila | GaryvdM: yeah, you should read it carefully and I advice you now inherit from LockableConfig, just to protect yourself against multiple qbzr instances runnning conccurrently (qlog here, qblame there, yet another qlog, etc), I dunno if you're yet ready to have a 2.2 branch in addition to a trunk branch though | 12:27 |
| vila | GaryvdM: but definitely interested in how you handle the transition | 12:28 |
| vila | GaryvdM: off now, back in <= 1h | 12:28 |
| GaryvdM | vila: ok | 12:28 |
| lvh` | Hi | 12:50 |
| lvh` | is it possible to revert the damage done by the rewrite plugin? I'm guessing no. | 12:50 |
| lvh` | Actually, it's probably okay. No commits were lost. | 12:51 |
| luks | I'm sure they are not | 12:53 |
| luks | revisions are never deleted from a repository | 12:53 |
| lvh` | right | 12:53 |
| luks | use bzr heads --dead to see all the revisions which are not referenced by the branch | 12:53 |
| lvh` | they're just organized a bit bogusly and I found a better way to fix the original problem | 12:53 |
| luks | then you can use bzr pull -r revid:XXX --overwrite to get the revision back | 12:53 |
| vila | lvh`: daggy-fix is your friend then, start again from before your first attempt and redo your commits from there in the right order. 'bzr merge -rx..y' (aka cherry-pick) can help you, as well as 'bzr diff --old <old> .' to see how you converge | 13:13 |
| vila | GaryvdM: I'm back | 13:14 |
| GaryvdM | Hi vila. | 13:25 |
| GaryvdM | vila: I think I need to do alot of cleaning up of the qbzr config code. | 13:26 |
| vila | GaryvdM: Will you try to maintain compatibility with bzr-2.2 ? | 13:27 |
| GaryvdM | vila: Yes | 13:27 |
| vila | GaryvdM: good, I'm all ears about potential problems then, especially if we could make the transition easier by adding some deprecated helpers in bzr.dev | 13:28 |
| GaryvdM | vila: Well in not sure why we have 2 different classes to write to qbzr.conf. So I'm going to start by deleting QBzrGlobalConfig... | 13:30 |
| vila | wow | 13:30 |
| GaryvdM | QBzrConfig does not inherit from bzrlib.config.XXX classes, so compatibility should not be a issue... | 13:31 |
| vila | WOW | 13:31 |
| GaryvdM | I'm going to copy your locking code to QBzrConfig | 13:32 |
| vila | GaryvdM: it's abit of a shame that this code isn't shared, but on the other hand, it addresses the compatibility issues :) | 13:34 |
| === lvh` is now known as lvh | ||
| stianse | hi. i'm trying to create a svn mirror of a bazaar branch, that for instance in a cron job pulls from the bazaar branch and pushes into the svn repository. | 14:49 |
| stianse | However, the "bzr push svn://whatever/path" fails due to "Tags not supported" | 14:49 |
| stianse | The revisions are there, so it seems to work, but is there a better way that does not cause the command to fail? | 14:50 |
| stianse | I've tried dpush, but then the next pull won't work since I get the message about diverged branches. | 14:51 |
| jelmer | stianse, hi | 14:57 |
| jelmer | stianse: your local branch has tags, and bzr-svn doesn't know where to add them. | 14:57 |
| === Ursinha is now known as Ursinha-afk | ||
| stianse | jelmer, yes i figured. That's why I tried dpush, but that had bad side effects for the next pull. | 14:59 |
| stianse | Perhaps there is a way to delete all tags before pushing to svn? | 15:00 |
| jelmer | stianse: did you use the --no-rebase option perhaps? | 15:00 |
| jelmer | stianse: You can delete the tags using "bzr tag --delete" | 15:00 |
| parthm | hello. i update my bzr.dev trunk today and `bzr selftest` fails with error importing TestLoader. has something changed? http://pastebin.com/KSbvutec | 15:01 |
| vila | parthm: perhaps you didn't run the tests for bzr-search for a long time ? | 15:02 |
| parthm | vila: ah. yes. ... i just noticed it was the plugin. never mind. i will just disable it. i wanted to run the test on the trunk :) | 15:03 |
| parthm | vila: thanks. | 15:03 |
| vila | parthm: you're welcome | 15:04 |
| parthm | hmm. it seems to fail for plugin_info also. | 15:05 |
| stianse | jelmer, the problem about using tag --delete is that you have to know the tag names. since I plan to run this in a automatic script this is not very practical | 15:06 |
| jelmer | stianse: can you just not create the tags in the first place, or push to a svn location that supports tags? | 15:07 |
| vila | jelmer: Russel mentioned bzr-svn trunk being broken with bzr.dev, I'm 95% sure it's related to my second fix for bug #525571 which introduced real lock for config files, feel free to ping me if you need help. Otherwise, your feedback is welcome if you encounter problems migrating to the new config objects. | 15:07 |
| ubot5 | Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 7, heat: 52)" [High,Fix released] https://launchpad.net/bugs/525571 | 15:07 |
| stianse | jelmer, I could if I had control of either of the two. unfortunately I don't | 15:08 |
| stianse | jelmer, dpush --no-rebase causes the next dpush to fail because they have diverged. not using --no-rebase causes the next pull to fail | 15:08 |
| jelmer | stianse, how does the next pull fail exactly? | 15:09 |
| jelmer | stianse: well, you can push to the svn repository so you have /some/ control over it :-) | 15:09 |
| vila | jam: can you test lp:~vila/bzr/626876-bzr-connect-to-bzr-ssh on windows ? | 15:13 |
| jam | morning vila | 15:13 |
| jam | sure | 15:13 |
| vila | jam: morning ! | 15:13 |
| vila | This "fix" it for me on hardy and karmic so far | 15:14 |
| mgolisch | can i create a new branch from changes i did but not actualy commiting them to the current branch? | 15:14 |
| GaryvdM | parthm: I've logged that as bug 627435 | 15:14 |
| ubot5 | Launchpad bug 627435 in bzr search plugin "ImportError running selftest -s bp.search in bzr.dev (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/627435 | 15:15 |
| vila | jam: I totally forgot about the FIXME above the one-liner fix :) | 15:15 |
| stianse | jelmer, uploaded the commands and output at http://pastebin.com/hghpLeYQ | 15:15 |
| parthm | GaryvdM: thanks for the ticket :) | 15:16 |
| jam | vila: well, not really a fix per say just a hack around :) | 15:16 |
| jelmer | stianse, you're pulling from a different location than you're dpushing to | 15:16 |
| stianse | jelmer, i know. isn't that allowed if i don't have any new commits? | 15:18 |
| vila | jam: well, you've read the comment ? I was deep into paramiko internals when I wrote that, it's a shame we have to wait there, but it's needed to make paramiko happy. | 15:18 |
| stianse | jelmer, the location I'm pushing to is just a mirror and won't have any additional commits | 15:18 |
| jelmer | stianse: it is, but please read up on what dpush does - it changes the revisions in the current branch | 15:18 |
| jam | vila: paramiko is doing a 'wait' on a Threading.event() I don't see why we should need to sleep at all | 15:19 |
| jam | though it may depend on version | 15:19 |
| vila | jam: Otherwise, we get all sort of random failures (as collected in the bug report) because some sockets are checked too early and considered broken | 15:19 |
| jelmer | stianse: thus making your current branch deferred from whatever branch you might be pulling from | 15:19 |
| vila | jam: because multiple threads are involved and if the wrong one is awaken too soon it draws the wrong conclusion about the socket | 15:19 |
| stianse | jelmer, ok I understand. That leaves me with the push command. | 15:20 |
| jam | vila: any sort of delay like this is going to be wrong sometimes... depending on load, etc. | 15:21 |
| jam | but I'm running it now | 15:21 |
| jam | (while my system is otherwise heavily loaded :) | 15:21 |
| vila | having several threads handling the same socket (from both sides) *and* using timeouts is a Bad Idea | 15:21 |
| jam | failed | 15:21 |
| vila | jam: shouldn't matter | 15:21 |
| vila | try increasing the timeout | 15:21 |
| jam | vila: changing 0.2 => 0.5 would have a strong indication on load | 15:21 |
| jam | running again, it fails in a different place, at least | 15:21 |
| jelmer | stianse: You can either add "/trunk" to the URL you're pushing to, and bzr-svn will push tags to "/tags/tagname", or remove the tags before pushing. | 15:22 |
| vila | jam: I don't intend to propose this fix, I just wanted to know if I had a fallback | 15:22 |
| vila | jam: I encounter the comment while setting up a new test smart server :) | 15:22 |
| jam | vila: if I set the time.sleep to 5.0s then it does pass | 15:23 |
| jam | at 1.0s, it sometimes passes, sometimes fails, and still gives: No handlers could be found for logger "paramiko.transport" | 15:24 |
| vila | jam: ok, thanks, that's enough for me. It means paramiko is somehow broken and should be used with caution, once I had the test rewritten, I'll get rid of the sleep too | 15:24 |
| stianse | jelmer, that "/trunk" in the URL was exactly what I was looking for. I didn't know about that feature. | 15:28 |
| stianse | jelmer, thanks for your help | 15:28 |
| jelmer | stianse, np | 15:28 |
| bcurtiswx | is there a step-by-step for a proper merge.. I keep getting Branches have no common ancestor, and no merge base revision was specified. | 16:06 |
| GaryvdM | bcurtiswx: Merging branches that don't have a common ancestor in quite uncommon. Is there a reason why you are doing that? | 16:07 |
| GaryvdM | bcurtiswx: May be you are merging branches from different projects. | 16:08 |
| bcurtiswx | well, i think my issue is with getting that common ancestor | 16:08 |
| bcurtiswx | i branch lp:ubuntu/lucid-proposed/empathy | 16:08 |
| bcurtiswx | which is version 2.30.2 | 16:08 |
| maxb | A common ancestor naturally results from normal bzr usage | 16:08 |
| maxb | You must be doing something unusual :-) | 16:09 |
| vila | ... when faced with parallel imports :-/ | 16:09 |
| vila | ... except when faced with parallel imports :-/ | 16:09 |
| bcurtiswx | maxb: im not denying that, i'm trying to figure out where my stupidity has started from :P | 16:09 |
| vila | bcurtiswx: what is your other branch and where is it coming from ? | 16:09 |
| bcurtiswx | so I want to take the new 2.30.3 and merge with 2.30.2,.. | 16:10 |
| bcurtiswx | i bzr init empathy/empathy-2.30.3 | 16:10 |
| bcurtiswx | move file contents over, bzr add | 16:10 |
| vila | stop | 16:10 |
| vila | wrong | 16:10 |
| maxb | uh, yes, don't do that :-) | 16:10 |
| bcurtiswx | OK, so where to go from here :) | 16:10 |
| vila | bcurtiswx: doing that will create a different ancestry which is why you wont have a common ancestor :) | 16:11 |
| vila | err, sry, where do you get 2.30.3 ? | 16:11 |
| === deryck is now known as deryck[lunch] | ||
| bcurtiswx | vila http://ftp.gnome.org/pub/GNOME/sources/empathy/2.30/ | 16:12 |
| bcurtiswx | bottom | 16:12 |
| vila | ha, right, a tarball | 16:12 |
| vila | so, tar xf on top of your branch unless there is a lp:empathy, | 16:12 |
| bcurtiswx | sorry for the newbish but what do you mean on top of my branch? | 16:13 |
| vila | bcurtiswx: sry, I meant, in the directory where you have your 2.30.2 branch | 16:14 |
| vila | i.e. you will update your working tree which is 2.30.2 with the sources that are 2.30.3 | 16:14 |
| vila | bzr st ; bzr diff; should show you what have changed | 16:15 |
| maxb | except, wait, if this is an Ubuntu packaging branch, you presumably want bzr merge-upstream | 16:15 |
| vila | bcurtiswx: oops, listen to maxb ! | 16:15 |
| bcurtiswx | my goal is to make a branch of the changes, and request a merge | 16:15 |
| bcurtiswx | yes ubuntu | 16:15 |
| bcurtiswx | maxb: how does a bzr merge-upstream work, and whats the correct syntax? | 16:16 |
| maxb | I'm not very familiar with bzr-builddeb's voodoo, but I do know you definitely need to use it | 16:16 |
| maxb | james_w`: You don't happen to be around, do you? | 16:17 |
| james_w` | maxb: I do | 16:17 |
| maxb | james_w`: bzr merge-upstream confuses me, but I know it's what bcurtiswx needs to use - do you have a good initial reference to point him to? | 16:17 |
| james_w` | hi bcurtiswx | 16:18 |
| bcurtiswx | james_w`, hi | 16:18 |
| james_w` | bzr merge-upstream takes a tarball and merges it in to your packaging branch | 16:18 |
| bcurtiswx | james_w`, whats the correct syntax then? | 16:18 |
| james_w` | it does this in a way that means that it builds on the previous upstream changes, but merges in your packaging changes | 16:18 |
| vila | mgz: ping, I have another instance of selftest unable to complete because of a unicode error (on OSX). testtools and subunit up-to-date, Do you have something in the pipe I can try or do you want a bug report ? | 16:19 |
| james_w` | the basic syntax is (in the branch you want to merge to) bzr merge-upstream --version 2.30.3 http://ftp.gnome.org/pub/GNOME/sources/empathy/2.30/empathy-2.30.3.tar.gz | 16:19 |
| vila | mgz: or is there some existing bugs I should check ? | 16:19 |
| james_w` | that will then churn for a minute, then should tell you either that there were conflicts or that the merge went fine | 16:20 |
| james_w` | either way "bzr diff" will show you the changes bought in by the new upstream version | 16:20 |
| bcurtiswx | james_w`, 'bzr merge-upstream <tar.gz file>' from the packaging branch? | 16:20 |
| james_w` | tweak the changelog as necessary, and make any other changes that need making, including resolving any conflicts, and then commit | 16:20 |
| bcurtiswx | james_w`, thx, i will go try that right now | 16:21 |
| james_w` | bcurtiswx: you currently need --version as well, as it is not smart enough to infer that yet | 16:21 |
| james_w` | for the tar.gz file it can take any local path, or http, ftp, sftp, etc. uri | 16:21 |
| bcurtiswx | james_w`, i get an "unknown command 'merge-upstream'" | 16:22 |
| maxb | You need the bzr-builddeb extension | 16:23 |
| james_w` | bcurtiswx: install bzr-builddeb | 16:23 |
| bcurtiswx | hmm, thought I had that. thx | 16:23 |
| * maxb wonders if anyone has thoughts on my "testtools and subunit in the ~bzr PPA" email | 16:27 | |
| bcurtiswx | hmm, may still need some advice | 16:37 |
| === beuno is now known as beuno-lunch | ||
| bcurtiswx | bzr push lp:~bcurtiswx/lucid-proposed/empathy | bzr: ERROR: Invalid url supplied to transport: "lp:~bcurtiswx/lucid-proposed/empathy": No such project: lucid-proposed | 16:38 |
| bcurtiswx | i wanted it to create lp:~bcurtiswx/lucid-proposed/empathy , it has before, idk why not now | 16:38 |
| maxb | bcurtiswx: Basically, there are two kinds of lp: URLs | 16:39 |
| maxb | Project, and Distro-Source-Package | 16:39 |
| maxb | So, lp:~user/project/branchname, but lp:~user/distro/series/package/branchname | 16:40 |
| maxb | And then each of those has abbreviated forms for important branches | 16:40 |
| bcurtiswx | so i want lp:~bcurtiswx/ubuntu/lucid-proposed/empathy ? | 16:41 |
| maxb | no - look again at my 5-element example (most importantly, there must be 5 elements :-) ) | 16:42 |
| bcurtiswx | so i want lp:~bcurtiswx/ubuntu/lucid-proposed/empathy/empathy-2.30.3 | 16:42 |
| maxb | Nearly, but the 3rd component is just a series, not a series-pocket | 16:42 |
| bcurtiswx | so it doesn't matter that it will end up in lucid-proposed, i just need lucid? | 16:43 |
| maxb | yes | 16:43 |
| maxb | and yes, this is a bit arcane | 16:43 |
| maxb | especially since the 3-element shortcut form for DSP branches does have a series-pocket in it | 16:44 |
| === Meths_ is now known as Meths | ||
| === deryck[lunch] is now known as deryck | ||
| mgz | vila: is the OSX problem bug 625589 as well? in which case, yeah, I've got something lined up. | 17:53 |
| ubot5 | Launchpad bug 625589 in Bazaar "babune junitxml not well formed on Python 2.7 (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625589 | 17:53 |
| === beuno-lunch is now known as beuno | ||
| exarkun | Why can't I see any loom data when I check out nosmart+bzr+ssh://bazaar.launchpad.net/~exarkun/+junk/modules ? | 17:59 |
| vila | mgz: I don't think so: http://paste.ubuntu.com/486389/ | 18:04 |
| mgz | ah, I see. Yeah, I've hit that before and just changed this line in the bzrlib TextTestRunner: | 18:08 |
| mgz | stream = osutils.UnicodeOrBytesToBytesWriter(encode, stream) | 18:08 |
| mgz | to add a 'replace' | 18:09 |
| mgz | wonder why the mac stdout is 'ascii' rather than 'utf8' like other nix boxes. | 18:09 |
| vila | hmmm, ascii, indeed, why ? | 18:10 |
| mgz | 'v written code in testtools 0.9.4 that's a bit more robust about how it prints test results to stream, but didn't want to change the bzrlib code to require it till people had time to upgrade | 18:10 |
| maxb | exarkun: According to http://bazaar.launchpad.net/~exarkun/+junk/modules/.bzr/branch/last-loom, your loom has no threads | 18:11 |
| vila | mgz: mail the list, pqm should come first | 18:12 |
| maxb | exarkun: that is somewhat broken, as I understand it | 18:12 |
| mgz | vila: what does python -c "import bzrlib.osutils;print osutils.get_terminal_encoding()" give you? | 18:12 |
| exarkun | maxb: The branch I pushed had two threads | 18:12 |
| mgz | +bzrlib. | 18:12 |
| vila | exarkun: sounds like an old bug in loom | 18:12 |
| exarkun | Last night lifeless suggested that if I re-pushed with a new version of loom everything would be great | 18:12 |
| exarkun | But I did that and it didn't appear to help | 18:12 |
| maxb | exarkun: Perhaps you could try pushing to a fresh launchpad branch? | 18:12 |
| vila | mgz: just a sec, locale under emacs (where I ran selftest) says: LC_ALL='' and the rest C, while launching a terminal properly put utf8 all over the place | 18:13 |
| mgz | ha. that'd be the immediate cause then. | 18:13 |
| exarkun | Hm. Okay. When the machine with the original branch comes back. | 18:13 |
| mgz | there is a real bug with printing results to non-unicode-encoding streams though, that I'll file. | 18:14 |
| maxb | exarkun: based on 'bzr heads --dead' not showing anything, it appears the loom metadata has not made it up to launchpad at all | 18:15 |
| vila | mgz: yup, US-ASCII under emacs, UTF-8 in terminal, that maybe a bug in my setup though | 18:16 |
| GaryvdM | vila: I'm trying to write better tests for qlog. I just wrote this: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/annotate/head:/lib/tests/test_loggraphprovider.py#L47 | 18:26 |
| GaryvdM | vila: what do you think. one thing I don't like about it is I can't easily visualise the expected data that I am specifying. | 18:27 |
| * GaryvdM starts writing a printComputed method for debugging... | 18:31 | |
| vila | GaryvdM: argh, I've EODed, cooking right now :-/ Can you send me an email so I don' forget to look at that ? | 18:51 |
| GaryvdM | vila: np - ok | 18:52 |
| vila | GaryvdM: but after quick glance, you want to look at branchbuilder.py and hmmm what;s the name LogCatcher ? in bt.test_log ? | 18:53 |
| GaryvdM | vila: I did look a branchbuilder. I will take a look at test_log. | 18:54 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| GaryvdM | woot! qlog data represented as unicode text: http://pastebin.com/Eruy5wnC | 20:33 |
| GaryvdM | And as ascii, for test results: http://pastebin.com/WSjGe2TJ | 20:34 |
| jam | GaryvdM: interesting, though the dot doesn't seem quite right in the ascii case | 20:35 |
| jam | or maybe it is, but it doesn't match the unicode version | 20:35 |
| GaryvdM | jam: I fiddled with the data to cause a failure. | 20:36 |
| GaryvdM | jam: In the ascii, you see 2. The second is correct | 20:37 |
| jelmer | 'evening Gary, John | 20:37 |
| GaryvdM | Hi jelmer | 20:38 |
| jam | hi jelmer | 20:38 |
| mgolisch | if i wanted to save the changes i did to my current branch as a new branch, how would i go about that? | 20:43 |
| GaryvdM | mgolisch: If you have allready commited: push to new branch. uncommit & revert in old | 20:43 |
| GaryvdM | mgolisch: If you have not yet committed: branch. then merge --uncommited | 20:44 |
| GaryvdM | and revert in old branch | 20:44 |
| mgolisch | oh i see | 20:44 |
| mgolisch | that was what i was looking for | 20:44 |
| mgolisch | thx | 20:44 |
| GaryvdM | jam: How do you think about this: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/revision/1323 | 21:03 |
| GaryvdM | s/How/What/ | 21:05 |
| === Ursinha-afk is now known as Ursinha | ||
| jam | GaryvdM: you mean what do I think about having a DummyBranch that just proxies the graph information? It looks like it does what you want it to do | 21:07 |
| jam | I believe I've written similiar code myself | 21:07 |
| GaryvdM | jam: So doing that in a test is ok. | 21:08 |
| jam | though it also makes me wonder if it would be better to have a specific function on loggraphprovider.BranchInfo that didn't require going through self.branch.repository.get_graph() | 21:08 |
| jam | such as... passing in the Graph object yourself | 21:08 |
| GaryvdM | jam: Or a custom version of LogGraphProvider that you can just pass a graph. | 21:10 |
| jam | GaryvdM: I don't know the qbzr internals all that well, but yeah, basically all you need for what you are doing is a Graph and a tip pointer | 21:10 |
| GaryvdM | jam: Ok - Thanks | 21:11 |
| jam | GaryvdM: though I guess you also are doing something with tags? | 21:13 |
| jam | what about fixed bugs, etc | 21:14 |
| GaryvdM | jam: fixed bugs come from the revisions, which get loaded lazyly | 21:14 |
| maxb | jelmer: Is a bzr-svn LogWalker iter_changes supposed to traverse copy history? | 21:15 |
| jelmer | maxb: yes | 21:16 |
| * maxb is confused - I have an invocation with strict_node_history=False, yet I'm not seeing history traversed | 21:17 | |
| * maxb wonders if the Apache repository is just being *odd* | 21:18 | |
| === Ursinha is now known as Ursinha-afk | ||
| GaryvdM | jam: Better solution: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/revision/1323 | 21:30 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| exarkun | I get this error when I try to push this branch with loom info to a new location on launchpad | 22:42 |
| exarkun | bzr: ERROR: The revision exarkun@twistedmatrix.com-20100830220539-v8ovhik3byonepog is not recorded in the loom LoomBranch7 | 22:42 |
| exarkun | What does that mean? | 22:42 |
| exarkun | Well, I guessed that it means that I should run `bzr record ''` again, and that let the push succeed at least. | 22:44 |
| exarkun | not a particularly comprehensible error message though | 22:44 |
| exarkun | However, my threads are still destroyed by the process. | 22:45 |
| exarkun | branching nosmart+bzr+ssh://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom doesn't give me something very closely resembling the original branch | 22:45 |
| mwhudson | exarkun: what version of bzr-loom do you have? | 22:54 |
| exarkun | 2.1.0 | 22:54 |
| mwhudson | i have to admit i've never been able to predict what will happen when i push or pull looms | 22:55 |
| maxb | Hmm, well it's definitely possible for it to work, since I took your previous branch, pushed it to a new non-loomed branch, loomified it, and pushed it to lp:~maxb/+junk/to-loom-or-not-to-loom, and it seems intact | 22:55 |
| maxb | looms are woefully underdocumented. After trying for quite some time, I only finally understood them after turning to the source code | 22:56 |
| maxb | After which, I finally went "ooh, what a clever idea" | 22:57 |
| exarkun | When I branch lp:~maxb/+junk/to-loom-or-not-to-loom I get something without any threads | 22:57 |
| maxb | hrm | 22:57 |
| maxb | When I do, I get a loom with one thread called 'base' | 22:57 |
| exarkun | Ah, but it works when I branch nosmart+bzr+ssh://bazaar.launchpad.net/~maxb/+junk/to-loom-or-not-to-loom | 22:57 |
| exarkun | But the nosmart trick didn't help my modules-with-loom branch | 22:58 |
| maxb | Why nosmart+, ooi? | 22:58 |
| mwhudson | bzr show-loom sftp://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom doesn't give any output | 22:59 |
| maxb | exarkun: Well, I'm guessing the lack of any threads listed at http://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom/.bzr/branch/last-loom indicates the loom never made it up to the server successfully | 22:59 |
| exarkun | I heard a rumor that bzr+ssh doesn't support looms properly | 22:59 |
| maxb | Well, I've both pushed and branched my to-loom-or-not-to-loom over bzr+ssh | 22:59 |
| maxb | smart bzr+ssh, that is | 22:59 |
| maxb | Are you on Ubuntu? | 23:00 |
| exarkun | yes, 9.10 | 23:00 |
| mwhudson | whereas bzr show-loom sftp://bazaar.launchpad.net/~maxb/+junk/to-loom-or-not-to-loom does | 23:00 |
| exarkun | with versions of everything from the bzr ppa | 23:00 |
| maxb | exarkun: hmm, interesting. Let me downgrade my bzr-loom..... | 23:00 |
| exarkun | maxb: downgrade? so you've got something newer than 2.1.0? | 23:01 |
| maxb | I generally run tip of trunk for most bzr plugins | 23:01 |
| exarkun | hey so I just pushed again to nosmart+bzr+ssh: instead of lp: and I think that helped | 23:02 |
| exarkun | yea, branching that, also with nosmart+bzr+ssh: gives me something with threads | 23:03 |
| exarkun | mwhudson: is sftp: the same as nosmart+bzr+ssh:? | 23:03 |
| maxb | ahaha | 23:04 |
| maxb | Using 2.1 my loom comes back broken | 23:04 |
| mwhudson | exarkun: for the purposes of this discussion, yes, i expect so | 23:05 |
| exarkun | I was wondering if they indicated the same protocol | 23:05 |
| mwhudson | the bytes on the wire will be different | 23:05 |
| maxb | Hmm, so using 2.1, my push pushed a working loom, but I couldn't branch it back until I upgraded to trunk again | 23:05 |
| mwhudson | with nosmart+bzr+ssh there's still a bzr serve process on the other end | 23:06 |
| mwhudson | rather than something talking sftp | 23:06 |
| exarkun | gotcha | 23:06 |
| maxb | So it's sounding like we need a bzr-loom release | 23:07 |
| lifeless | doit | 23:08 |
| maxb | bug 201613 sounds likely | 23:08 |
| ubot5 | Launchpad bug 201613 in Loom "fetching looms does not work properly with bzr+ssh (dup-of: 193893)" [Critical,Fix released] https://launchpad.net/bugs/201613 | 23:08 |
| ubot5 | Launchpad bug 193893 in Loom "branching over bzr+ssh does not propogate loom threads (affected: 2, heat: 16)" [Critical,Fix released] https://launchpad.net/bugs/193893 | 23:08 |
| * lifeless throws the reins in the air | 23:08 | |
| maxb | heh | 23:08 |
| exarkun | thanks for the help | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!