| thumper | :( | 00:29 |
|---|---|---|
| thumper | not for the first time have I gone bzr add in an ignored directory | 00:30 |
| thumper | and it added a whole pile of intermediate files | 00:30 |
| thumper | can I revert this easily? | 00:30 |
| thumper | poolie: ? ^^ | 00:34 |
| thumper | found it | 00:34 |
| thumper | bzr remove build | 00:34 |
| thumper | that backs out my problems | 00:35 |
| poolie | hi thumper | 00:44 |
| poolie | bzr rm --keep | 00:44 |
| thumper | poolie: I hadn't committed the add | 00:54 |
| thumper | will bzr rm --keep remove all added files? new ones? | 00:54 |
| poolie | it will remove whatever you ask it to | 00:55 |
| poolie | 'bzr -0 added|xargs -0 bzr rm --keep' will likely do the exact right thing | 00:56 |
| spiv | (IIRC, strictly speaking --keep is unnecessary for files listed in 'bzr added': it defaults to never deleting files you might not have another copy of. --keep is probably a good habit though!) | 01:06 |
| poolie | riht | 01:09 |
| poolie | *right | 01:09 |
| === r0bby is now known as robbyoconnor | ||
| mwhudson | jelmer: hello | 03:47 |
| jimis | Hi, I'm working on a local checkout of a --no-trees branch of big project. But now my version is pretty old. What's the proper way to update to latest revisions from remote repo? | 04:01 |
| lifeless | if its a checkout, bzr update | 04:02 |
| lifeless | if the branch is actually just a regular clone and the checkout is because you're using switch locally, then bz rpull | 04:02 |
| lifeless | I would guess bzr pull is what you want | 04:02 |
| jimis | thanks lifeless, I've already done bzr pull and it updated my unmodified trunk branch | 04:03 |
| lifeless | great | 04:03 |
| jimis | but should I use merge to also update some feature branches that have diverged from trunk? | 04:03 |
| lifeless | perhaps you mean 'I have a branch that I'm working in,m how do I incorporate changes made in trunk?' | 04:03 |
| lifeless | if so, then 'bzr merge + bzr commit'. | 04:04 |
| jimis | then the merge will show as a separate commit, *after* my local changes? | 04:04 |
| jimis | lifeless: indeed "bzr merge" created some conflicts, as expected | 04:05 |
| jimis | bzr status also says: pending merge tips:... | 04:06 |
| jimis | so I suppose the commit will be handled specially and won't show in history? | 04:06 |
| lifeless | no, it will, this is normal. | 04:06 |
| lifeless | after all your code changes in it :) | 04:06 |
| jimis | ok to show *my* commits, but not the upstream commits as newer than mine :-p | 04:07 |
| jimis | anyway I'll do it and see | 04:08 |
| jimis | thanks | 04:08 |
| lifeless | the upstream commits won't show unless you supply -n0 | 04:08 |
| lifeless | the *merge* of upstream will show. | 04:08 |
| jimis | and while editing out the conflicts, how can I view the original version of trunk or my own tree? I'm asking since this is a no-trees branch, so I can't just find them in the filesystem | 04:33 |
| lifeless | .BASE and .OTHER files | 04:34 |
| lifeless | in your tree | 04:34 |
| jimis | They always confuse them... So .BASE is my feature branch, .OTHER is the trunk I'm merging from, and .THIS is what? | 04:36 |
| jimis | s/They/I/ | 04:36 |
| lifeless | .BASE is the common ancestor | 04:39 |
| lifeless | .THIS is your feature branch | 04:39 |
| jimis | yeah I just noticed that .THIS had my changes :-) | 04:39 |
| jimis | thanks, I now understand | 04:40 |
| === wilx_ is now known as wilx | ||
| jimis | How can I do a checkout from a server where I only have ssh access? For example if the branch directory is "host:stuff/project" | 06:08 |
| jimis | If the server has commandline bzr, I can use bzr+ssh protocol? | 06:08 |
| poolie | jimis, bzr branch bzr+ssh://host/~/stuff/project | 06:08 |
| poolie | yes | 06:08 |
| jimis | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 06:11 |
| poolie | there's probably another error higher up | 06:11 |
| jimis | I'm checking client/server logs, but can't see anything useful | 06:11 |
| jimis | server logs almost nothing, client logs unexpected end of message | 06:12 |
| jimis | poolie: no other error, even though I run bzr co -v | 06:12 |
| poolie | how about 'ssh -v host bzr serve --inet' | 06:13 |
| jimis | I'll update the server-side bzr first, just to be sure... it's running beta-5 | 06:13 |
| jimis | poolie: I should run bzr serve on the server? Is it necessary, or just for logging purposes? | 06:14 |
| jimis | poolie: never mind I think I got it | 06:19 |
| vila | hi all ! | 06:19 |
| jimis | hi | 06:20 |
| jimis | poolie: even if bzr is on my path, it probably doesn't find the executable | 06:20 |
| jimis | maybe it doesn't source my .bash_profile | 06:20 |
| spiv | No, SSH doesn't. | 06:22 |
| spiv | (Not when running a command rather than making an interactive shell) | 06:23 |
| spiv | You can explicitly set a config value like bzr_ssh_remote_path in your client to workaround that | 06:24 |
| spiv | (A good place would be in your ~/.bazaar/locations.conf in a section for just that host) | 06:24 |
| vila | bradm: any news on that import issue ? | 06:25 |
| vila | spiv: _o/ | 06:26 |
| jimis | spiv: It would be useful if it run bzr in a subshell, I have used BZR_REMOTE_PATH to find the executable, but now I get an error about missing bzrlib | 06:27 |
| jimis | it's probably the same for my PYTHONPATH | 06:27 |
| poolie | i think you can set this in some kind of ssh configuration | 06:27 |
| jimis | I'll check, thanks | 06:28 |
| jimis | can't find relevant ssh option | 06:30 |
| jimis | Is there a way to set REMOTE_PYTHONPATH for bzr too? | 06:31 |
| jimis | hmmm or I could just use sftp and get over with it :-) | 06:31 |
| poolie | see SendEnv | 06:32 |
| poolie | in ssh_config | 06:32 |
| lifeless | jimis: or you can run from the source tree, where bzr will find its library | 06:32 |
| lifeless | jimis: or you can put the PYTHONPATH setting in your .bashrc | 06:32 |
| jimis | lifeless: bashrc? But the problem is ssh doesn't execute bzr under a shell | 06:33 |
| bradm | vila: nope, got overrun with other work :( I had a quick chat to lamont tho, he knows another buildd is having the issues | 06:34 |
| vila | bradm: k | 06:34 |
| spiv | Or you can use a separate SSH key and set the remote's authorized_keys for that key to run a script like bzr_ssh_path_limiter or bzr_access | 06:34 |
| jimis | I've done a local install in my ~ since I have no admin privileges, hence all the trouble | 06:34 |
| fullermd | That's not really true... ssh always calls your shell. | 06:35 |
| fullermd | bash just loads (or doesn't load) various files depending on whether it's being started as an interactive shell or not. | 06:36 |
| jimis | allright, will check SendEnv first, although I think it won't do, because I'll have to change local environment too | 06:36 |
| vila | jimis: I did the same in an old setup with bzrssh being a wrapper calling "python /Users/vila/bin/bzr $*" | 06:36 |
| jimis | fullermd: from ssh manual: "If command is specified, it is executed on the remote host instead of a login shell." | 06:36 |
| spiv | jimis: that doesn't actually contradict fullermd :) | 06:37 |
| jimis | thanks vila, that will solve it for sure. And within the wrapper I'll be able to set PYTHONPATH too. | 06:38 |
| spiv | It could just mean running "$SHELL -c cmd..." vs "$SHELL -l" | 06:38 |
| vila | well, the bzr script manage to have its associated bzrlib accessible via sys.path IIRC | 06:38 |
| lifeless | jimis: it does actually | 06:39 |
| lifeless | jimis: it just does not execute bash_profile | 06:39 |
| lifeless | because it doesn't create a login shell | 06:39 |
| vila | jimis: you also need a dedicated section in locations.conf to set bzr_remote_path = /Users/vila/bin/bzrssh | 06:40 |
| fullermd | You can easily demonstrate it by setting your shell to e.g. /usr/bin/false and trying to ssh $SERVER $CMD. | 06:40 |
| fullermd | (don't close your existing session before trying though :p) | 06:40 |
| * lifeless would put it in .bashrc - simplest. | 06:41 | |
| lifeless | its *why* there are two two distinct files | 06:41 |
| vila | .bashrc is still executed IIRC but not the profile nor the login one, 'ssh host echo $PATH' should help you debug these | 06:41 |
| vila | jimis: bah, quoting $PATH to avoid local expansion of course | 06:43 |
| jimis | yeap, you are right, "ssh host env" shows that the SHELL variable is set to /bin/bash, makes sense now that I see it :-p | 06:45 |
| jam | morning all | 06:51 |
| jam | mwhudson: I just remembered that bzr+ssh://user:pass@host may not do what you want. I think if the ssh implementation is Openssh then we can't pass it a password. So you'll also need to set BZR_SSH=paramiko | 06:51 |
| jimis | wow, bzr has advanced a lot speedwise... lightweight checkout via *sftp* finished in 2 min, I didn't expect that :-) | 06:53 |
| jimis | I'm curious now to try the smart protocol :-) | 06:55 |
| jimis | that was for the gcc project, so 2 min is a short time, I should have mentioned that :-) | 07:00 |
| spiv | Hopefully jam can finish the 'bzr branch --stacked' from HPSS patch soon, which I think would be nice for working on gcc. | 07:03 |
| jam | hey spiv, good to see you around again | 07:04 |
| spiv | I'm only slightly around :) | 07:05 |
| jam | spiv: better than not around at all | 07:06 |
| spiv | True! | 07:14 |
| poolie | vila, hi? | 08:26 |
| vila | poolie: hey | 08:27 |
| vila | poolie: RT #47638 has been escalated to CharlieS but I couldn't get in touch with him (bad TZ overlap), can you see to it ? | 08:28 |
| vila | poolie: the reason for escalation is worries about impacts on the rest of the system | 08:29 |
| poolie | hi there | 08:29 |
| poolie | vila, i hope to get around to making it report success, some time | 09:05 |
| poolie | aside from being useful it would show a much better attitude | 09:05 |
| jam | poolie: make what report success? | 09:08 |
| poolie | udd | 09:08 |
| poolie | at the moment they can only be noticed in the web page by their absence | 09:09 |
| poolie | afaik | 09:09 |
| jam | poolie: ah right. Also, being able to open the page for the package and have it say "last successfully imported" rather than having the page just disappear would be nice. | 09:10 |
| jam | I was thinking about bug #795025. It looks pretty easy to do now that I have the timeout stuff working. | 09:11 |
| ubot5 | Launchpad bug 795025 in Bazaar "no way to gracefully disconnect clients and shut down the bzr server" [High,In progress] https://launchpad.net/bugs/795025 | 09:11 |
| jam | basically, just adding a trigger (something like SIGHUP) that will set self.finished | 09:11 |
| jam | and then check that right after the timeout logic. | 09:11 |
| jam | so SIGHUP should trigger EINTR for select.select(), which can then say "oh, you want me to stop now" | 09:12 |
| jam | And if they are in the middle of processing, it will be set and detected once the current command ends. | 09:12 |
| jam | Anyone have a preference for what the signal should be? | 09:12 |
| poolie | jam, that's awesome, i'm otp with vila atm | 09:22 |
| jam | poolie: sounds good. I changed my mind to SIGTERM, but thanks for the feedback. | 09:22 |
| jam | mgz: question about test case logging. I believe you last said you didn't like test cases uses self.get_log() does that still hold true? | 09:29 |
| ccxCZ | hi guys, I've recently ran into project that uses lot of patch magic in the workflow. How would you sanitize this? http://list.linux-vserver.org/archive?mss:5375:201109:dnnehlgageenpcekjlmh I have no experience with the loom plugin but I think it's the appropriate tool. | 09:40 |
| poolie | lifeless, still here? can you help him? | 09:44 |
| jelmer | vila: hi? | 09:45 |
| vila | jelmer: otp with poolie | 09:45 |
| jelmer | ah | 09:48 |
| jam | ccxCZ: it does sound like looms would be appropriate | 10:00 |
| jam | top level '0' would be to have the base of your loom be upstream vanilla kernel | 10:00 |
| jam | 'unpacking' becomes switching to it, and pulling the latest | 10:00 |
| jam | 1. => becomes 'bzr up-thread' which should apply the changes in that thread merging the upstream vanilla updates. | 10:01 |
| jam | At that point, you'll probably have some conflicts to resolve, which aren't mentioned in the workflow | 10:01 |
| jam | After 'bzr commit' then to generate a new diff you would do "bzr diff -rthread:" (IIRC) | 10:02 |
| jam | that would be 1.1 | 10:02 |
| jam | 2. becomes 'bzr up-thread' again, where the next thread has the grsec changes | 10:02 |
| jam | again, generating a diff is "bzr diff -r thread:" after you've resolved any issues | 10:02 |
| ccxCZ | thanks a lot, I'm bit baffled by loom's terminology | 10:02 |
| jam | if you need to consult history, "bzr log/qlog" should be useful | 10:02 |
| jam | 4. => bzr up-thread to Rik Bobbaers | 10:03 |
| jam | 5. compute the full diff => bzr diff -r thread:upstream | 10:03 |
| jam | and bzr diff -r thread:vserver I think | 10:03 |
| jam | for 5.1 | 10:03 |
| ccxCZ | manually resolving all conflicts again and again seemed silly to me | 10:04 |
| lifeless | poolie: who, ? | 10:04 |
| poolie | ccxCZ, but i think jam got it | 10:06 |
| mgz | jam: what get_log does has changed completely now | 10:07 |
| jam | ccxCZ: you may still encounter bits of that, but it should at least be better. | 10:07 |
| jam | mgz: sure ,but if I wanted to add a test that confirms something is being logged, would you go "ew" or would it be ok? | 10:08 |
| mgz | I think the obvious way of doing it would be fine. | 10:08 |
| jam | vila: let me know when you're done with the phone stuff. I had a thought about config that would at least make *me* happier about how it interacts with testing. | 10:08 |
| ccxCZ | the vserver thread is currently provided as discrete patches to specific kernel releases. any idea how to convert that to contiguous loom thread? | 10:12 |
| mgz | hm, bug 850004 is network share related, not sure where to go from there | 10:18 |
| ubot5 | Launchpad bug 850004 in Bazaar "NoSuchFile on .bzr/repository/pack-names after committing in bzr explorer" [Undecided,Incomplete] https://launchpad.net/bugs/850004 | 10:18 |
| jam | ccxCZ: start at upstream with the oldest vanilla that the oldest vserver thread applies to | 10:21 |
| jam | create upstream | 10:21 |
| jam | create vserver thread | 10:21 |
| jam | apply first patch | 10:22 |
| jam | switch down to upstream | 10:22 |
| jam | update to 'version for next vserver thread' | 10:22 |
| jam | bzr up-thread | 10:22 |
| jam | bzr revert -r thread:; apply the next patch; bzr commit | 10:22 |
| jam | so the global loop is | 10:22 |
| jam | bzr down-thread; bzr pull -r NEXT_VSERVER_VANILLA_BASE; bzr up-thread; bzr revert -r thread:; patch ...; bzr commit | 10:23 |
| ccxCZ | neat, I guess I'll try to buildbotize most of the process | 10:25 |
| jam | ccxCZ: You'll also want to "bzr record" somewhere in there. It can be considered "bzr commit" to record the current tip of each thread. You need to do it before you 'bzr push' the loom somewhere else. | 10:27 |
| ccxCZ | okay | 10:27 |
| jam | (bzr commit snapshots the state of the current working tree, 'bzr record' snapshots the state of the threads) | 10:27 |
| ccxCZ | makes sense | 10:28 |
| vila | jam: shoot ! | 10:30 |
| vila | jam: I tried your branch on natty => hangs, with --parallel => hang, on OSX (to have the *other* socket implementation ;) => hang | 10:31 |
| vila | jelmer: about bug https://bugs.launchpad.net/udd/+bug/836782 | 10:33 |
| ubot5 | Ubuntu bug 836782 in Ubuntu Distributed Development "bzr-builddeb requires dpkg-dev >= 1.15.7" [High,In progress] | 10:33 |
| vila | well jelmer, maxb, jam, poolie, Riddell, whoever is involved with monitoring the package importer | 10:33 |
| maxb | ? | 10:33 |
| vila | poolie put a recent dpkg-mergchangelogs in the scripts/ directory and I've enable the merge hook again in builddeb, | 10:34 |
| vila | so far, many imports have succeeded so I'm reasonably confident it works | 10:34 |
| vila | but if you see weird changelogs issues, please tell me | 10:35 |
| * jelmer nods | 10:35 | |
| vila | maxb: hi :) | 10:36 |
| ccxCZ | I wonder how long will branching linux kernel take :] | 10:38 |
| blackarchon | mgz: I'm here if you need further data regarding 850004 | 10:40 |
| mgz | your last post was really helpful, but I'm not sure how to debug the issue | 10:42 |
| blackarchon | maybe a tool like 'Process monitor' from sysinternals may help, because it is able to show all activities of a process (bzr.exe) | 10:45 |
| lifeless | mgz: perhaps a crufty server | 10:48 |
| lifeless | blackarchon: we had a case once where a windows cluster server filesystem took several *seconds* to show in reads the impact of writes *from the same client*. | 10:48 |
| lifeless | bah | 10:48 |
| lifeless | mgz: ^ | 10:48 |
| mgz | ow. there's not much that can be done to mitigate that kind of thing. | 10:50 |
| blackarchon | ok, how can I verify that this is really the reason? | 11:01 |
| jam | vila: the test suite as a whole hangs, or something specific hangs? I would guess something like run_bzr_subprocess is waiting the 5-min for default timeout, and we aren't cleaning up our connections properly on the client side to tell it that no, you can hang up now. | 11:04 |
| vila | in one case *all* 8 parallel processes hung | 11:04 |
| jam | as for the config stuff... indirecting through files that have to be read for every test case seems particularly bad. Would there be a way to inject an in-memory-already-decoded Config object for the test suite? | 11:05 |
| jam | vila: that just depends on how the tests get farmed out. But if you know what test is hanging, i'm happy to investigate. | 11:05 |
| mgz | blackarchon: that might be tricky, but a workaround for problems with network filesystems is to use some other protocol to access that box | 11:05 |
| vila | jam: see my comments on review | 11:05 |
| jam | vila: the commented out ignored_exceptions was just a bogus debugging thing | 11:06 |
| vila | jam: that's premature optimization :) But yes, that would be trivial once the stores are shared. | 11:06 |
| jam | I certainly didn't plan on including it | 11:06 |
| jam | vila: current experience shows that adding a config for every test case slows it down significantly, thus not really premature | 11:06 |
| vila | jam: all TestCaseWithTransport *have* to check for bazaar.conf and locations.conf *today* | 11:08 |
| lifeless | blackarchon: it may not be; I was noting that its a problem we've seen before, and something that ruling out would be good | 11:08 |
| jam | vila: but we leave them empty, and thus don't have anything to do | 11:09 |
| lifeless | blackarchon: manual testing with a little dedicated python script might be a good way to rule it out, for instance. | 11:09 |
| vila | why would that change ? | 11:09 |
| jam | vila: For example, the default timeout for client is ridiculous during the test suite, this is one case where production values are very different from test suite values | 11:09 |
| jam | I'd like to avoid overrideAttr hacks | 11:10 |
| jam | in production, the value will always be propagated from above (ultimately read in a config) | 11:10 |
| jam | I don't really want that overhead in every test case. | 11:10 |
| jam | You *could* do that for specific test cases where you know you'll be exercising the code, but then a bad test ends up taking 5min to timeout | 11:10 |
| vila | there are at least 3 ways to address that: | 11:12 |
| vila | 1) chose a default value appropriate for tests and be explicit for production, | 11:12 |
| vila | 2) support command-line overrides for selftest (i.e. provide a value for the option so the config files are not queried at all) (not supported yet) | 11:13 |
| vila | 3) inject config stores in each test (not supported yet) | 11:13 |
| vila | 2 and 3 have no associated bugs AFAIK | 11:13 |
| jam | vila: btw, consider the changes to test_server.py to be experimental and reverted (I just committed the reversion) | 11:14 |
| jam | I was trying to debug the never timing out thing | 11:14 |
| jam | Right now, I'm trying to work out the config stuff, while I was waiting for feedback on the rest. | 11:15 |
| jam | I'm currently on Windows to fix up things on that side, but hopefully I'll get back to natty soon to work out if something is breaking. | 11:16 |
| jam | vila: as for "trace.note()" we *already* print unhandled exceptions to stderr | 11:16 |
| jam | I'm actually *reducing* the amount of stuff that goes out that way | 11:16 |
| jam | but I didn't want to reduce it to 0. | 11:16 |
| jam | vila: I'm actually only encountering weird things in the select.select() because of how we implemented SmartTCPServer_for_testing having it close its own sockets, etc. If we just closed the clients, it would have been happy without whack-a-mole. | 11:18 |
| jam | which again means that testing is very little like production for this stuff | 11:18 |
| jam | vila: I do apologize for the noise on test_server.py, I didn't intend for that part to get reviewed. | 11:19 |
| vila | jam: I just mentioned the smart server comment, its scope is unclear to me so your usage is too | 11:19 |
| vila | hey, no problem with that, I mentioned the hangs as in this area I found it excessively frustrating to see success while testing only to have to start again while broadening the tests | 11:20 |
| vila | It occurred a lot and while I was fiddling with one part I didn't realize the implications (and windows was yet another different beast), so I thought it was better to warn you early | 11:21 |
| vila | jam: but overall (and related to moles), I think your initial idea is worth trying harder (a simple select) adding more stuff around that sounds like working around timing issues, and down this path ... madness because you will never be sure you nail it down correctly or by luck | 11:27 |
| jam | vila: yeah, thanks for the heads up. Can you try again with rev 6152 | 11:28 |
| jam | vila: I'll probably poke again. It took a while to figure out what was actually going on. And the fact that we suppress errors at various levels meant that I wasn't *seeing* EBADF propelry. | 11:29 |
| jam | properly. | 11:29 |
| jam | it would timeout, but then actually go to read, and I didn't know whether the read | 11:29 |
| jam | was then returning '' | 11:29 |
| jam | indicating the client was closed | 11:29 |
| vila | yup, nigtmares that | 11:29 |
| jam | when it was actually raising EBADF | 11:29 |
| jam | which osutils.read_from_socket suppresses | 11:29 |
| vila | did you read the select man page ? | 11:29 |
| jam | and turns into '' | 11:29 |
| jam | vila: I have, I didn't see anything about closing the descriptors after select has started. | 11:30 |
| vila | they mention a race and a weird behaviour you may be interested in | 11:30 |
| vila | 12 failures so far, but nohang | 11:30 |
| vila | AttributeError: 'module' object has no attribute 'config' :-} | 11:31 |
| jam | vila: the race I see here: http://linux.die.net/man/2/select | 11:31 |
| jam | is talking about SIGNALs | 11:31 |
| vila | There may be other circumstances in which a file descriptor is spuriously reported as ready. | 11:32 |
| jam | vila: can you give a quick traceback? | 11:33 |
| jam | sounds like "from bzrlib import config" is failing | 11:33 |
| vila | it's in lazt_import | 11:33 |
| jam | vila: yeah, because we spawn a subprocess, and I'm using config.option_registry.get('serve.client_timeout').default | 11:33 |
| jam | to avoid repeating the default timeout | 11:33 |
| vila | http://paste.ubuntu.com/689919/ | 11:34 |
| jam | which is some of the... how can we do this in a way that doesn't make me cry | 11:34 |
| vila | start by using default values suitable for tests (funnily enough I *just* encounter the exact same issue (but I don't have a config there ;)) | 11:34 |
| jam | vila: that specific failure is just a bug | 11:34 |
| jam | i accidentaly did a lazy import from "bzrlib.transport import (config)" rather than "from bzrlib import (config)" | 11:35 |
| jam | vila: I *really* don't prefer to write test code in production code. | 11:35 |
| jam | so writing test-applicable values is ~ the same thing. | 11:35 |
| jam | I can do it if we must. | 11:36 |
| jam | Anyway, I'm almost at the point that the timeout gets propagated appropriately | 11:36 |
| jam | which might let me set the timeout in SmartTCPServer_for_testing | 11:36 |
| jam | which would be appropriate *testing* code. | 11:36 |
| vila | test code in production is no-go, I was proposing a temp work around | 11:38 |
| jam | vila: interesting thing, there is no 'config.float_from_store' vs "int_from_store" | 11:41 |
| vila | please file a bug ;) | 11:43 |
| jam | vila: I'm likely to just implement it for this test case | 11:48 |
| vila | stop listening to me, you're trying too hard ;) | 11:49 |
| jam | vila: are there any direct tests of SmartTCPServer_for_testing ? | 11:52 |
| vila | gee, can't say off hand | 11:52 |
| jam | there are a lot of things that use it | 11:52 |
| jam | but I don't see a "TestSmartTCPServer_for_testing", etc. | 11:52 |
| jam | and bzrlib/tests/test_server.py doesn't have any actual test cases in it | 11:53 |
| jam | ah, a test_test_server | 11:53 |
| vila | isn't there a test_test_server ? | 11:53 |
| jam | yeah, but it doesn't have TestSmartTCPServer_for_testing | 11:54 |
| jam | but I'll add it there | 11:54 |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga | ||
| === zyga is now known as zyga-afk | ||
| vila | quizz: how long takes the package importer to queue (and process) all packages ? | 13:22 |
| vila | on average that is, not from scratch | 13:23 |
| vila | maxb: any issue with 2.4.1 ? I just noticed the stable PPA still propose 2.4.0 | 13:55 |
| jam | vila: https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348 is ready for re-review, I believe. There are 2 blackbox tests that I need to write on Linux, but otherwise I think I'm happy. | 14:05 |
| jam | rebooting now | 14:06 |
| blackarchon | mgz: I updated bug 850004 | 14:31 |
| ubot5 | Launchpad bug 850004 in Bazaar "NoSuchFile on .bzr/repository/pack-names after committing in bzr explorer" [Undecided,Incomplete] https://launchpad.net/bugs/850004 | 14:31 |
| jam | vila: ok, bunch of failing blackbox tests on Linux. Looks like I didn't hook up the PipeStreamMedium correctly | 14:38 |
| jam | however, there is another bug | 14:38 |
| jam | with config | 14:38 |
| jam | that i'm hoping you might shed some light on | 14:38 |
| jam | ah, nevermind | 14:39 |
| jam | typo (server.* vs serve.*) | 14:39 |
| vila | having mouse trouble here and freezing 2.5b1 too | 14:39 |
| vila | dang, not mouse, focus issues... argh, gimme my editor back ! | 14:43 |
| mgz | blackarchon: that's great. can you also confirm that 2.4.1 *does* work if there are no umlauts involved? | 14:47 |
| blackarchon | mgz: I will test it! | 14:48 |
| blackarchon | ok, the same error happens also without umlauts and 2.4.1 | 14:52 |
| mgz | that's what I thought... still no luck doing similar things here | 15:09 |
| mgz | how much more can you remove and still get the error? try using `bzr qcommit` directly, then `bzr commit` | 15:09 |
| mgz | I want to narrow down project where the regression happened so we can try to find the specific revision. | 15:10 |
| blackarchon | ah, I found something interesting | 15:17 |
| blackarchon | if I do 'bzr init', 'bzr add .' and then 'bzr qcommit -m "First"', there is no error | 15:18 |
| blackarchon | but if I use Bazaar Explorer, the errors return | 15:20 |
| mgz | so, that makes it look like the LockContention is caused by explorer and qcommit both trying to get access, and that error then causes the later one | 15:21 |
| mgz | this could still just be a laggy network filesystem like lifeless said earlier, but something changed at least to expose the problem for you in 2.4 | 15:22 |
| blackarchon | yes, seems so | 15:23 |
| jam | mgz, blackarchon: Note that I think in 2.4 and maybe 2.3? We started doing the right thing and locking config files before we update them. | 15:25 |
| jam | Otherwise there was a race in the past | 15:25 |
| jam | where 1 bzr could update X, and the other could update Y and silently discard X | 15:25 |
| jam | anyway, I'm off for tonight. Good luck | 15:26 |
| mgz | this is on dirstate, which annoyingly I can't reproduce locally, I just get a hang | 15:26 |
| throughnothing | I accidentally removed a file with bzr remove, and then I added it back with bzr add, but the diff still shows the whole file being removed then re-added, how can I 'undo' the remove (I haven't committed yet) | 15:27 |
| mgz | `bzr revert` | 15:28 |
| blackarchon | 'bzr revert filename' should do the trick | 15:28 |
| mgz | and optionally the filename | 15:28 |
| blackarchon | :) | 15:28 |
| throughnothing | perfect, that worked | 15:31 |
| throughnothing | thanks! | 15:31 |
| Noldorin | hey jelmer | 15:36 |
| jelmer | hola | 15:36 |
| Noldorin | jelmer, i see bzr 2.5b1 is out :-) | 15:36 |
| Noldorin | how about colocated branches support in LP...up yet? | 15:36 |
| jelmer | Noldorin: landed, but I don't think deployed yet | 15:36 |
| Noldorin | jelmer, ah right. so in the next day or two i suppose | 15:36 |
| Noldorin | jelmer, can i subscribe to anythign to see when it's deployed? | 15:40 |
| jelmer | Noldorin: yeah, bug 380871 | 15:43 |
| ubot5 | Launchpad bug 380871 in Launchpad itself "support for colocated branches" [Medium,Fix committed] https://launchpad.net/bugs/380871 | 15:43 |
| Noldorin | jelmer, oh ok, already subscribed...thanks | 15:44 |
| Noldorin | jelmer, chance to work on the bzr-git issue today you think? :-) | 15:44 |
| blackarchon | well I'm done for today... cya | 15:46 |
| jam | I'm seeing some test runner noise, has anyone else also seen this: http://paste.ubuntu.com/690112/ | 16:21 |
| Noldorin | jelmer, well? | 16:35 |
| jelmer | Noldorin: nothing yet, I'll keep the bug report posted | 16:36 |
| jelmer | jam: I haven't see the "failed to open trace file:" warning, but the import warnings look familiar | 16:36 |
| jelmer | jam: I think they've been happening for a while in sid/oneiric | 16:36 |
| Noldorin | jelmer, sure...i like forward to it. | 16:36 |
| Noldorin | jelmer, will be around today again to help...but not tomorrow probably | 16:37 |
| jelmer | jam: importing lazr.restfulclient seems to trigger them | 16:37 |
| Noldorin | also, is there a windows redistributable release for 2.5b1 ? | 16:37 |
| jelmer | Noldorin: see http://wiki.bazaar.canonical.com/WindowsDownloads | 16:42 |
| jelmer | I'm not sure if we usually provide setup files for betas | 16:42 |
| jelmer | looks like we do | 16:43 |
| jelmer | Noldorin: see also https://launchpad.net/bzr/+download | 16:43 |
| Noldorin | jelmer, yeah, no luck there.... i only want the installer because i want tortoisebzr really :-S | 17:00 |
| jam | Noldorin: Given that vincent hasn't announced it yet, and only created the tag about 3 hrs ago, we haven't built it yet | 17:03 |
| jam | there is 2.4.1 which should have the latest tbzr | 17:03 |
| Noldorin | jam, oh ok, but it will be released soon-ish eh? :-) | 17:04 |
| jam | Noldorin: I would expect 2.5b1 to be announced tomorrrow | 17:05 |
| jam | and an installer built... whenever I can get around to it | 17:05 |
| === beuno is now known as beuno-lunch | ||
| Noldorin | jam, ok cool...i only ask about the windows build for 2.5b1 because i want colocated branch support | 17:05 |
| === deryck is now known as deryck[lunch] | ||
| Saviq | hi all, any way to only commit a subset of changes? something that `git add -p` allows? | 17:35 |
| LeoNerd | bzr ci some file names here | 17:39 |
| Saviq | LeoNerd: what about per-hunk? | 17:40 |
| LeoNerd | Ah, for that case I usually use "bzr shelve" to remove all the changes I don't want to commit | 17:40 |
| LeoNerd | That way I can run unit tests etc.. on just those bits I do want to commit, so when I bzr ci I know I'm committing exactly what I tested | 17:41 |
| Saviq | found it - https://launchpad.net/bzr-interactive | 17:41 |
| Saviq | bit inactive, but I'll try | 17:42 |
| LeoNerd | I prefer the shelve approach | 17:42 |
| LeoNerd | shelve is a widely-used plugin so it's well supported. And again also, the unit testing :) | 17:43 |
| LeoNerd | Personally I really dislike the partial-hunk selection way of committing, because you don't really know if that partial selection even compiles, let alone actually works.. | 17:43 |
| Saviq | well, since you have that in separate revisions, you can easily find out | 17:44 |
| LeoNerd | My usual workflow consists of *hack hack hack...* bzr shelve -m "Things that aren't done yet"; make test; bzr ci -m "Did stuff"; bzr unshelve.. | 17:45 |
| LeoNerd | possibly recursively. | 17:45 |
| LeoNerd | shelves stack, you can have multiple of them, nested | 17:45 |
| LeoNerd | This way I know that every single commit definitely passes unit tests, because it was committed immediately after "make test" passed | 17:46 |
| Noldorin | jelmer, no rush for fixing the bzr-git bug i guess...now that i know the 2.5b1 windows installer won't be out for a few days... | 18:19 |
| Noldorin | jelmer, nor will the LP support for colocation...they'll all come at about the same time i guess :-) | 18:19 |
| === beuno-lunch is now known as beuno | ||
| jelmer | Noldorin: any reason you're waiting for all of them to be updated? | 18:25 |
| === deryck[lunch] is now known as deryck | ||
| Noldorin | jelmer, i want to be able to push all my LP bzr branches to github :-) | 18:30 |
| Noldorin | can't do that until all 3 are updated/fixed | 18:30 |
| Noldorin | brb | 18:39 |
| Noldorin | hey jelmer | 20:41 |
| jelmer | hi | 20:50 |
| Noldorin | jelmer, sorry to pester again...any progress? :-) | 20:51 |
| jelmer | Noldorin: I'll post to the bug once I've looked into it further | 20:52 |
| Noldorin | okay :-) | 20:52 |
| Noldorin | ta | 20:52 |
| BasicOSX | evening | 21:14 |
| BasicOSX | something wrong with the bzr repo? | 21:14 |
| BasicOSX | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ebzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 21:14 |
| BasicOSX | bzr update before that ERROR message | 21:14 |
| jelmer | BasicOSX: you're trying to write to a repository (bzr.dev) over http | 21:16 |
| BasicOSX | seems strange, bzr update, just pulls from the repo right? | 21:16 |
| jelmer | BasicOSX: this usually happens if it's trying to take a write lock for some reason | 21:18 |
| jelmer | BasicOSX: what version of bzr are you using to do the update? | 21:18 |
| BasicOSX | Bazaar (bzr) 2.5.0dev2 from bzr checkout /Users/tanner/projects/bzr.dev | 21:19 |
| BasicOSX | revision: 6141 | 21:19 |
| BasicOSX | 21:19 | |
| jelmer | BasicOSX: can you pastebin the output of "bzr up -Derror" ? | 21:19 |
| BasicOSX | meh | 21:20 |
| BasicOSX | all looks ok! | 21:20 |
| BasicOSX | $ bzr up -Derror | 21:20 |
| BasicOSX | Tree is up to date at revision 6141 of branch http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev | 21:20 |
| BasicOSX | oh, never mind, so sorry, I did !bzr for command recall and the last bzr operation was a bzr merge :-( apologies! | 21:21 |
| jelmer | ah :) | 21:22 |
| * BasicOSX goes and hides in the corner | 21:22 | |
| jelmer | though we should print a saner error message.. | 21:23 |
| Noldorin | shit. i just clobbered my branch on LP by reverting to r0 | 21:24 |
| Noldorin | can i recover it? | 21:24 |
| Noldorin | uncommitting to r0 | 21:24 |
| Noldorin | buggggger | 21:24 |
| jelmer | Noldorin: just push again ? | 21:25 |
| Noldorin | jelmer, it's clobbered locally to | 21:25 |
| Noldorin | they were bound | 21:25 |
| Noldorin | i guess | 21:26 |
| jelmer | you can run "bzr heads --dead-only" to find the previous tip | 21:27 |
| jelmer | then "bzr pull -rrevid:<therevid> ." to revert back | 21:27 |
| Noldorin | jelmer, there are no dead heads :-S | 21:29 |
| Noldorin | jelmer, maybe you pulled the 0.4 branch recently and have it on your HD? | 21:29 |
| Noldorin | i'm so fucked otherwise | 21:33 |
| jelmer | Noldorin: what's the lp branch? | 21:33 |
| jelmer | Noldorin: I see quite a few dead heads on the lp branch | 21:34 |
| Noldorin | jelmer, lp:ircdotnet/0.4 | 21:35 |
| jelmer | Noldorin: "bzr heads --dead-only" shows a handlful of dead heads for that branch | 21:35 |
| Noldorin | :-S | 21:36 |
| Noldorin | jelmer, it says no revisions to pull when i try to pull again | 21:37 |
| jelmer | Noldorin: are you specifying a particular revision> | 21:37 |
| jelmer | ? | 21:37 |
| Noldorin | nope | 21:37 |
| Noldorin | just want to pull afresh | 21:37 |
| Noldorin | so i created a new directory | 21:37 |
| Noldorin | and bzr init | 21:37 |
| Noldorin | then bxr pull lp:ircdotnet/0.4 | 21:38 |
| Noldorin | and it tells me nothing to pull | 21:38 |
| jelmer | Noldorin: that won't work, because you've removed all the revisions from that branch | 21:38 |
| jelmer | Noldorin: you can still fetch a revision from the repository though | 21:38 |
| Noldorin | oh? | 21:38 |
| Noldorin | how do i do that? | 21:38 |
| jelmer | Noldorin: run "bzr heads --dead-only lp:ircdotnet/0.4" | 21:38 |
| jelmer | then find the relevant revision id | 21:39 |
| Noldorin | got it | 21:39 |
| jelmer | "bzr pull -rrevid:<revid> lp:ircdotnet/0.4" | 21:39 |
| flacoste | hi there | 21:39 |
| flacoste | is it a known bug that bzr qannotate cause sXorg to take all available memory on Oneiric? | 21:39 |
| jelmer | hi Francis | 21:40 |
| jelmer | flacoste: I don't think I've heard about that one | 21:40 |
| Noldorin | jelmer, nothing recent there :-S | 21:40 |
| flacoste | jelmer: yeah, bzr qlog seems to work fine | 21:41 |
| jelmer | flacoste: I can't reproduce the qannotate issue here (oneiric, bzr 2.4, qbzr 1.2.1), so there must be something specific that triggers it | 21:41 |
| flacoste | actually | 21:42 |
| Noldorin | bah | 21:42 |
| flacoste | it's not qannotate so much than qdiff | 21:42 |
| Noldorin | this is not fun.. | 21:42 |
| jelmer | Noldorin: are you sure there were ever newer revisions on launchpad? | 21:43 |
| flacoste | as if I request a file difference in qlog, it does the same thing: Xorg goes to 2G RSS | 21:43 |
| flacoste | in a few seconds | 21:43 |
| jelmer | Noldorin: uncommit doesn't remove revisions from the repository | 21:43 |
| flacoste | jelmer: that's on the LP tree | 21:43 |
| Noldorin | jelmer, yes, up to r49. 100% sure | 21:43 |
| flacoste | i'll check on a small tree to see if the same things happen | 21:43 |
| Noldorin | in this case it does... | 21:43 |
| flacoste | jelmer: yes, same behavior on a small tree | 21:44 |
| flacoste | so must be qdiff related | 21:44 |
| flacoste | and might be a change in the way the QT libraries does its thing | 21:44 |
| flacoste | i'll report a bug | 21:44 |
| jelmer | flacoste: thanks! | 21:45 |
| jelmer | fwiw, I can't reproduce that here either on a small tree | 21:46 |
| === Ursinha is now known as Ursinha-afk | ||
| jelmer | Noldorin: what does "bzr heads --dead-only" on your local repository say? | 21:47 |
| flacoste | jelmer: i have this in the terminal: | 21:48 |
| flacoste | QWidget::setMinimumSize: (/DiffWindow) The largest allowed size is (16777215,16777215) | 21:48 |
| Noldorin | jelmer, sorry sorry, me being an idiot... i assumed dead-only heads were in chronological order :-P | 21:48 |
| Noldorin | jelmer, not that i want to...but is it possibly to remove dead heads? | 21:48 |
| jelmer | flacoste: that sounds like it might be relevant, I'm not seeing that here | 21:49 |
| flacoste | jelmer: bug 851379 | 21:52 |
| ubot5 | Launchpad bug 851379 in qbzr (Ubuntu) "qdiff makes Xorg eats up all RAM on Oneiric" [Undecided,New] https://launchpad.net/bugs/851379 | 21:52 |
| flacoste | jelmer: yeah, i think it's creating a too big window that takes all RAM in the X server | 21:52 |
| flacoste | I've now lost my code archeology tool! | 21:52 |
| jelmer | flacoste: I'm afraid I'm not all that familiar with Qt and qbzr (other than as a user), but maybe Riddell has an idea | 21:53 |
| Noldorin | jelmer, ? | 21:58 |
| jelmer | Noldorin: in theory, yes. In practice we don't have a command that does it. | 22:01 |
| Noldorin | ah ok sure | 22:01 |
| Noldorin | jelmer, it's a good safety measure anyway so that's fine ;-) | 22:01 |
| Riddell | flacoste: what happens if you move ~/.bazaar/qbzr.conf out the way? | 22:04 |
| flacoste | Riddell: same thing | 22:06 |
| flacoste | i need to run, will follow-up with any question on the bug report | 22:06 |
| Noldorin | jelmer, no luck trying to create a minimal example of the bzr-git issue here | 22:17 |
| Noldorin | odd | 22:17 |
| Noldorin | :-S | 22:17 |
| Noldorin | jelmer, what is the easiest way to join a series of commits into a single revision? | 22:29 |
| Noldorin | for hte purpose of testing... | 22:29 |
| === thomi|work is now known as thomi | ||
| === yofel_ is now known as yofel | ||
| poolie | hi all | 23:24 |
| lifeless | morning | 23:27 |
| jelmer | g'morning poolie, lifeless | 23:35 |
| poolie | hi jelmer | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!