| poolie | hi all | 00:30 |
|---|---|---|
| nigelb | Morning poolie! | 01:00 |
| poolie | hi nigel | 01:07 |
| === robbyoconnor is now known as CapnRobby | ||
| === CapnRobby is now known as robbyoconnor | ||
| === wallyworld___ is now known as wallyworld | ||
| === wallyworld is now known as Guest73189 | ||
| === robbyoconnor is now known as CapnRobby | ||
| vila | hi all ! | 06:34 |
| poolie | hi vila | 06:36 |
| === Quintasan_ is now known as Quintasan | ||
| jam | morning all | 07:25 |
| poolie | hi there jam | 07:25 |
| poolie | vila, istm wrt packaging plugins, the most scalable thing is to get babune jobs going for bzr+plugins | 07:37 |
| vila | poolie: right | 07:38 |
| vila | poolie: the issue is to install the right plugins for the right bzr versions and decide what kind of test run we want | 07:40 |
| vila | poolie: all selected plugin tips against bzr.dev is probably the first step | 07:40 |
| poolie | sounds good to me | 07:41 |
| poolie | as a first step, doing that just for one plugin would be good | 07:41 |
| poolie | we can get that green then iterate | 07:41 |
| vila | poolie: but it should be done in a way tht doesn't break running bzr.dev itself (i.e. without plugins) | 07:41 |
| poolie | that could be either one that's really unlikely to break, or that's very actively maintained | 07:41 |
| poolie | what do you mean? | 07:41 |
| poolie | i think we need a separate job from the tests for bzr itself | 07:42 |
| vila | yes, separate run isolated from the plugins | 07:42 |
| vila | but the plugins still need to installed on the slaves, jenkins tracks a single branch for a given run | 07:43 |
| vila | s/to/to be/ | 07:43 |
| poolie | oh, i see | 07:45 |
| poolie | it has no capability to test combinations of branches? | 07:45 |
| poolie | i'm surprised | 07:45 |
| vila | poolie: it's somewhat related to testtools/subunit deployment on all slaves and also with bug #839461 | 07:48 |
| ubot5 | Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461 | 07:48 |
| poolie | surely other people use jenkins to test combinations of one project running on another? | 07:49 |
| vila | poolie: nothing in the GUI hints at that (imbw) | 07:50 |
| vila | or if they do they use other tricks, maven ? | 07:51 |
| poolie | hm | 07:52 |
| poolie | http://stackoverflow.com/questions/7189874/how-can-i-automatically-build-multiple-eclipse-plug-in-projects-as-one-jenkins-pr suggests it is "make everything look like one big branch" | 07:52 |
| poolie | does it really need to know about all the branches? | 07:53 |
| poolie | how about having just one job that runs every day and just does a 'pull' on every branch, then runs the tests? | 07:53 |
| poolie | i know that's not quite elegant | 07:53 |
| lifeless | sorry, I'm missing a subtlety | 07:54 |
| lifeless | whats the problem ? | 07:54 |
| poolie | i would like to test bzr tip against the tip of various plugins | 07:54 |
| poolie | vila says this is hard because jenkins does not have a concept of one job depending on multiple branches | 07:54 |
| lifeless | its pretty straight forward | 07:54 |
| lifeless | setup one job that as you say branches LP then uses a script to branch in the dependencies / plugins. | 07:55 |
| lifeless | setup one job per thing you want to trigger that job, and have that jobs test be a no-op (or even run just the tests for that plugin, if you like) | 07:55 |
| lifeless | et voila | 07:55 |
| lifeless | s/branches LP/branches bzr/ | 07:56 |
| lifeless | the script is the 'pre actions' in jenkins, doesn't need to be formal; just a few lines of bash in the config pag.e | 07:56 |
| poolie | so the second job is "when lp:bzr-svn changes: do nothing; then run job 1" | 07:56 |
| lifeless | for instance, yes. | 07:56 |
| lifeless | it could be 'package and build bzr-svn; if that works run job 1' | 07:57 |
| vila | multiply by supported platform | 07:57 |
| lifeless | which is what dx's hudson does/did - it would ppa build take the package then use it as a dep in all the things that use it. | 07:57 |
| lifeless | vila: the platform multiplier should be straight forward with matrix | 07:57 |
| lifeless | vila: but even a single platform would be a big win on its own, no? | 07:58 |
| poolie | +1 | 07:59 |
| vila | patches welcome ? :D | 08:00 |
| poolie | seriously, just ignoring multiplication for now would still give us something really useful | 08:00 |
| poolie | then if it turns out that it is useful, but we're missing things that only occur on other platforms, we can work out how to add it | 08:01 |
| poolie | doing just a single version does not seem like it would make that any harder to do later on | 08:01 |
| lifeless | vila: I'll trade, you can bootstrap SOA on Launchpad and change nappies in alternating hours, I'll drive your point-n-click CI tool :P | 08:01 |
| poolie | ow | 08:01 |
| vila | I can put that on top of my babune TODO list but I'd like to clean up my plate a bit before switching to it | 08:02 |
| vila | changing nappies.... | 08:02 |
| vila | cute memories :) | 08:02 |
| vila | anyway, babune's backup is under way and therefore it's off-line right now | 08:05 |
| MvG | Hi! I'm trying to deprecate an argument to a builtin command (wrt. lp:~gagern/bzr/log-omit-merges). Added code using symbol_versioning.deprecated_passed and so on as other parts of bzrlib do. selftest does see the deprecation warning in its captured command output, but I myself don't. And I'm not running a final version of bzrlib either. Does anyone know whether deprecation warnings might be configured off somewhere? | 08:05 |
| lifeless | MvG: running a recent python ? | 08:05 |
| lifeless | MvG: upstream turned deprecations off globally. Because they were ugly or something. | 08:06 |
| MvG | lifeless: Yes, very recent python. | 08:07 |
| MvG | So if I want to warn the user about something, I'll have to drop the warning category? | 08:08 |
| lifeless | I don't know what we should do here. | 08:08 |
| poolie | MvG, DeprecationWarning is only for developer-oriented deprecations | 08:08 |
| poolie | there is a separate ui_factory.user_warning | 08:08 |
| poolie | (sp?) | 08:09 |
| poolie | which is more appropriate | 08:09 |
| lifeless | theory is that devs will turn deprecations on so that they know. | 08:09 |
| lifeless | however, your experience demonstrates the obvious flaw there, that I was worried about :) | 08:09 |
| poolie | we use a separate mechanism for a bunch of reasons, one being that the python deprecations tend to error out or to print lines of code that are not appropriate for users | 08:09 |
| poolie | also to vary across platforms | 08:09 |
| poolie | lifeless, i think one of the best things is to set the equivalent of -Werror from the test suite | 08:15 |
| poolie | at least optionally | 08:15 |
| poolie | which bzr does | 08:15 |
| vila | lifeless: there are various ways to make this work with jenkins, none are trivial and I'm already focusing on other stuff for today (bug #795321 and some config stuff for/with jelmer) | 08:17 |
| ubot5 | Launchpad bug 795321 in Ubuntu Distributed Development "udd importer should make tea while launchpad is down" [High,In progress] https://launchpad.net/bugs/795321 | 08:17 |
| lifeless | vila: thats fine, we've moved on haven't we ? | 08:19 |
| vila | lifeless: yeah ;) | 08:19 |
| vila | ok, let's have tea | 08:26 |
| MvG | jelmer, vila, jam: Will you re-review https://code.launchpad.net/~gagern/bzr/log-omit-merges/+merge/74821 or should I file a new merge request? | 08:55 |
| poolie | MvG, you don't need to file a new request but asking for review (as you did now) is useful | 08:55 |
| jam | MvG: arr, matey, I be slackin' on givin' ya feedback | 08:58 |
| jam | MvG: did ye just push some changes? It be claimin that the diff be updatin soon | 08:58 |
| MvG | jam: Pushed some a moment ago, yes, and to me lp talked about updating the diff. Done so now. | 08:59 |
| jam | http://www.talklikeapirate.com/ in case ye be wondrin | 08:59 |
| MvG | ARG! the diff has a merge conflict, although I just merged bzr.dev into my treee. Probably hadn't pulled bzr.dev before that... | 09:00 |
| poolie | o/ jelmer | 09:12 |
| MvG | vila: thx 4 the review! | 09:20 |
| vila | MvG: be my guest ;) Wait for some more opinions though ;) | 09:20 |
| MvG | It's not as if I could send this to pqm mysel before that, is it? | 09:21 |
| vila | hehe :) | 09:21 |
| vila | touche | 09:21 |
| MvG | btw: added one release notes item after your review. is that going to confuse pqm? | 09:22 |
| vila | MvG: nope, pqm uses the lp branch when it receives the submissions and nobody sent the submission so far | 09:23 |
| MvG | So I could slip an arbitrary change into a branch after sane stuff has been approved? Sounds frightening. | 09:24 |
| MvG | btw: I'm (mostly) around in case someone wants to talk about the really evil bug #842695. | 09:24 |
| ubot5 | Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695 | 09:24 |
| vila | did anybody ever witness rsync "pausing" for a long time ? (the file it's trying to sync is ~30GB if that's relevant) | 09:24 |
| vila | "pausing" in this case includes a case where the tmp file on the receiving side wasn't updated for ~1h and both client or server rsync processes were sleeping (AFAICS) | 09:26 |
| MvG | nope, but does sound bad. | 09:27 |
| MvG | strace those processes'? | 09:27 |
| vila | can I do that for an already running process ? | 09:28 |
| MvG | yepp | 09:28 |
| MvG | at least on linux | 09:28 |
| MvG | probably won't tell you mich if the process is really asleep, but otherwise you should see some i/o | 09:29 |
| MvG | can even gdb the running process, see what it's waiting for, but that will probably require debug symbols. | 09:29 |
| MvG | The "Unmerged revisions" list in https://code.launchpad.net/~gagern/bzr/log-omit-merges/+merge/74821 is incomplete, and doesn't indicate so. I'd consider this a bug in LP, do you agree? | 09:35 |
| poolie | yes, very much | 09:36 |
| poolie | not one i remember seeing before either; please file it | 09:37 |
| vila | MvG: only the 10 most recent ones but none of the previous ones ? | 09:39 |
| jelmer | hi poolie, MvG, vila | 09:45 |
| jelmer | sorry, had to go out for some emergency coffee beans | 09:45 |
| poolie | :) tut tut, insufficient preparation :) | 09:45 |
| vila | jelmer: _o/ | 09:45 |
| poolie | i see Riddell's pilot this week | 09:46 |
| poolie | ok i'm off to squash | 09:46 |
| poolie | possibly but probably not back later | 09:46 |
| Riddell | I shall steer the ship of patches with precision! | 09:46 |
| === Riddell changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell | ||
| poolie | pilot like a pirate | 09:48 |
| poolie | riddell did you see my blog post draft? | 09:48 |
| poolie | if you can't get at it, ask in #is | 09:48 |
| Riddell | poolie: no I don't thinkso | 09:49 |
| Riddell | on the bazaar blog? | 09:49 |
| jelmer | poolie: have fun :) | 09:49 |
| poolie | can you click login on blog.bazaar.canonical.com? | 09:49 |
| jelmer | vila: Have you seen issues with http redirects to the root of the server rather than the actual location? | 09:49 |
| jelmer | http://varnish-cache.org/svn/trunk/ is permanently redirected to https+urllib://www.varnish-cache.org/ | 09:50 |
| Riddell | poolie: i don't see a login option | 09:51 |
| vila | the only bell ringing is one about some path lost inside bzrlib or a plugin, I forgot the root cause | 09:51 |
| Riddell | oh "log in" | 09:51 |
| Riddell | poolie: ok I see "bzr starts speaking your language" | 09:52 |
| poolie | yep, edit to taste and post | 09:52 |
| poolie | or not | 09:52 |
| Riddell | I had a blog post on my own blog last week | 09:52 |
| Riddell | but my blog seems to have falled off planet bazaar :( | 09:52 |
| Riddell | probably because of the move to a new kde.org domain | 09:53 |
| poolie | oh right, i saw that | 09:53 |
| poolie | sorry i forgot | 09:53 |
| poolie | file an rt i guess | 09:53 |
| Riddell | I'll just post this one then do the rt thing | 09:53 |
| jelmer | vila: HttpTransport._redirected_to seems to strip it, I'll have a closer look | 09:58 |
| vila | that rings another bell... unclear, but I seem to recall some servers not sending back the proper url to redirect to under... some circumstances ? Sorry for the vagueness :-/ | 09:59 |
| jelmer | vila: if we redirect to something non-http/https then we drop the path component | 10:12 |
| vila | urgh, including http+urllib ? | 10:12 |
| vila | oh, httpS+urllib ? | 10:12 |
| jelmer | yep | 10:13 |
| vila | hmm, I thought this was taken care of, I'm pretty sure there are even tests for that... regression ? | 10:13 |
| jelmer | it might be a regression, but at least there are no tests for this | 10:14 |
| vila | test_redirected_to_same_host_sibling_protocol | 10:15 |
| vila | test_redirected_to_same_host_different_protocol | 10:15 |
| jelmer | vila: that second test doesn't check the r.base | 10:15 |
| vila | that's the hole :) | 10:15 |
| vila | hmm, well, the base may change for a redirect so the test is... incomplete ? | 10:18 |
| jelmer | yeah, I'll add some tests for r.base too | 10:19 |
| * vila nods | 10:23 | |
| jelmer | vila: hmm | 11:10 |
| jelmer | vila: it looks like the issue is that self._path has a trailing / whereas the source URL that is being passed in does not | 11:10 |
| vila | stupid Apache ? They are the same damn thing but Apache insists that a dir must have a trailing /, is this the case here ? Or is there more than the final / that differs ? | 11:11 |
| jelmer | this is actually in our tests, we seem to assume that the server will send a trailing slash | 11:12 |
| jelmer | I'm hitting this trying to test _redirected_to directly | 11:12 |
| vila | hmm | 11:14 |
| vila | I think our test servers follow apache and *will* send a trailing slash, not a good reason to assume they will always do though | 11:14 |
| vila | jelmer: yeah, see http_server.py ~line 198 | 11:15 |
| vila | how do the tests assume that ? | 11:16 |
| jelmer | Transport adds a trailing slash | 11:17 |
| jelmer | > | 11:18 |
| vila | transport as in our own bzrlib.transport ? I know there was a very old bug about *not* stripping the final slash when we know we're talking about a dir, I'm pretty sure this has never been fixed though | 11:19 |
| jelmer | vila: see bzrlib/transport/__init__.py:1326 | 11:20 |
| vila | jelmer: yeah, bzrlib.transport.Transport.relpath line 513 blindly strip | 11:20 |
| vila | jelmer: but who talks last ? :) | 11:21 |
| jelmer | vila: Transport.relpath isn't broken, but _redirected_to has its own relpath implementation | 11:21 |
| jelmer | and that relpath implementation breaks with a trailing slash | 11:21 |
| vila | strip() triggers only if there is one to strip, what is breaking exactly ? | 11:24 |
| jelmer | vila: it returns an empty string | 11:28 |
| jelmer | vila: and that causes parsed_url.path[:-len(relpath)] to break | 11:28 |
| jelmer | as parsed_url.path[:0] == "" | 11:28 |
| vila | I miss some context here, what is the abspath that leads an empty relpath() ? | 11:31 |
| vila | s/leads/returns/ | 11:31 |
| jelmer | e.g. http://www.example.com/foo, for transport with base http://www.example.com/foo/ | 11:32 |
| vila | right, so that's 'base_path = parsed_url.path[:-len(relpath)]' which is bogus, the base_path should just be relpath right ? | 11:39 |
| vila | errr,should just be parsed_url.path | 11:40 |
| jelmer | that was my thinking too, that would also simplify a bit of the other code | 11:41 |
| vila | jelmer: so, in your case, the server redirected from 'xxx/' to 'xxx' ? | 11:43 |
| jelmer | vila: the server redirects from http://foo/bar to https://foo/bar | 11:43 |
| jelmer | (note the missing trailing slashes) | 11:43 |
| jelmer | and what _redirected_to sees is a call with "http://foo/bar" and "https+urllib://foo/bar" | 11:43 |
| vila | ooooh, no slash nowhere and *we* injected a slash | 11:44 |
| vila | and probably never encountered it before because we received redirected urls with trailing slashes ? | 11:44 |
| jelmer | yeah | 11:44 |
| vila | (including our test servers....) | 11:45 |
| vila | wow | 11:45 |
| jelmer | this might be a regression when I introduced the URL classes | 11:46 |
| vila | doesn't seem to be the case, the relpath handling there is... unclear, the comment says why we do it, but an example may have been clearer | 11:49 |
| vila | jelmer: do you know what kind of server is involved there ? | 11:50 |
| jelmer | no idea | 11:50 |
| jelmer | vila: it seems to break with our existing _redirected_to tests too | 11:50 |
| jelmer | see the tests added in r-2 in lp:~jelmer/bzr/853765-http-redirects-broken | 11:51 |
| vila | what ? the fix we just ... let me look | 11:51 |
| vila | jelmer: meh, I've got failures from test_http.SmartHTTPTunnellingTest.test_open_bzrdir ??? | 11:54 |
| jelmer | vila: try the second to last revision, that just changes tests | 11:55 |
| vila | eeerk, tests failing on trunk ! | 11:58 |
| jelmer | which ones, and how? | 11:58 |
| vila | at revno 6144, the ones I mentioned above, no pycurl on pqm nor babune ? | 11:58 |
| vila | InvalidURL: Invalid url supplied to transport: "" | 11:59 |
| vila | bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir(pycurl,HTTP/1.1) | 11:59 |
| vila | bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir(pycurl,HTTP/1.0) | 11:59 |
| jelmer | seems fine here | 12:00 |
| jelmer | what's the backtrace like? | 12:00 |
| vila | http://paste.ubuntu.com/692972/ | 12:01 |
| vila | jelmer: ha, some plugin is involved, using BZR_PLUGIN_PATH=-site, the test succeed | 12:09 |
| jelmer | vila: ah, ok | 12:10 |
| jelmer | vila: I'm looking into the redirected_to issue further, thanks for the hints | 12:10 |
| vila | ok, thanks | 12:11 |
| jelmer | vila: fixed, https://code.launchpad.net/~jelmer/bzr/853765-http-redirects-broken/+merge/76014 | 12:21 |
| vila | jelmer: looking | 12:36 |
| vila | jelmer: BB:tweak | 12:43 |
| Noldorin | hi jelmer | 13:21 |
| === Ursinha is now known as Ursinha-brb | ||
| jelmer | hi Noldorin | 13:44 |
| Noldorin | jelmer, hey. i updated the bug comments if you saw it :-) | 13:53 |
| jelmer | Noldorin: yep! did you post the actual script to reproduce it ? | 13:58 |
| Noldorin | jelmer, no but i can give it to you now | 13:59 |
| Noldorin | it's a powershell script | 13:59 |
| Noldorin | or just push the test repo somewhere if you like | 13:59 |
| jelmer | Noldorin: the test repo won't be of much use, but it'd be great if you can attach the powershell script | 14:07 |
| Noldorin | jelmer, will do | 14:08 |
| Noldorin | did you see my previous note about the rename error btw? | 14:08 |
| Noldorin | that may be the cause | 14:08 |
| Noldorin | that bzr-git isn't handly it properly... | 14:08 |
| jelmer | Noldorin: how do you mean? | 14:09 |
| Noldorin | jelmer, the error in my penultimate comment | 14:12 |
| jelmer | Noldorin: doesn't that happen before you call dpush? | 14:15 |
| Noldorin | jelmer, yes but i think it could still be a hint as to whjat's 'upsetting' dpush | 14:15 |
| jelmer | hmm, that's an interesting thought | 14:16 |
| jelmer | although that's definitely a different issue from the original bug | 14:16 |
| Noldorin | okay | 14:19 |
| Riddell | MvG: log-omit-merges seems to be approved, I don't think you have permission to send it to PQM, would you like me to do so? | 14:49 |
| MvG | Riddell: Yes, please. | 14:49 |
| MvG | Should I enter a comit msg in lp first, or will you take care of that as well? | 14:49 |
| Riddell | MvG: yes do, you'll know better than me a good message | 14:51 |
| Riddell | jam: don't forget the question for you on https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381 | 14:52 |
| === Ursinha-brb is now known as Ursinha | ||
| MvG | Riddell: Should I include my name in the commit msg, or will pqm add that automatically? | 14:53 |
| Riddell | MvG: no need, your name will be in the merge changelog and more importantly in doc/en/release-notes/bzr-2.5.txt | 14:54 |
| MvG | Riddell: OK, commit message updated (was already entered but out of date). Ready for pqm as far as I am concerned. Thx for submitting it! | 14:55 |
| Noldorin | jelmer back | 14:57 |
| Noldorin | jelmer, will upload shortly | 14:57 |
| MvG | Trying to figure out what behaviour people expect, I've got a question for everybode around here, related to bug #842695. | 15:14 |
| ubot5 | Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695 | 15:14 |
| MvG | Suppose a feature branch branches off trunk at revision 10, at some point merges r 30 of trunk, and gets itself merged into trunk at r 40. Suppose furthermore that some other branch gets merged at trunk r 20, and that that branch modifies files in a given directory foo, not modified by any other branch since trunk r 10. | 15:14 |
| MvG | Now if you do "bzr log -n0 foo" on the trunk, would you expect to see the commit where trunk was merged into the feature branch? | 15:14 |
| MvG | Personally, I would not, because the feature branch was not dealing with directory foo at all, except for merging from trunk things which the log will already report in other places. But current log implementation does (mostly) report that, based on the fact that the merge modified that directory relative to the leftmost parent inside the feature branch. Which is unserstandable, once you think of it in those terms, and really makes me wonder whether | 15:14 |
| Riddell | MvG: whether... I think you got cut off | 15:27 |
| MvG | I did? Pidgin doesn't reflect that fact... :-( | 15:27 |
| MvG | [...] and really makes me wonder whether other people would expect the same behaviour that I expect. So please let me know what you think! | 15:28 |
| jelmer | MvG: I think the current behaviour makes sense, but I don't feel strongly either way. | 15:32 |
| MvG | Current behaviour can lead to a single file being reported as "added" multiple times in the verbose log. Which I consider one of themost confusing aspects about this interpretation, and which is also the root of the bug described above. | 15:35 |
| Noldorin | hi jam | 15:36 |
| Noldorin | jelmer, just added a new comment with the script attachment | 15:53 |
| jelmer | Noldorin: thanks | 15:54 |
| Noldorin | jelmer, you can probably write a bash script to do the same thing | 15:55 |
| Noldorin | jelmer, then have a very simple example to debug. i bet you will see immediately :-) | 15:56 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| Noldorin | jelmer, hey, back | 20:11 |
| jelmer | Noldorin: hey :) | 20:11 |
| Noldorin | jelmer, okay so i guess you're actually wanting me to write the unit test for this ;-) still, we are very very close now | 20:13 |
| Noldorin | in that... | 20:13 |
| Noldorin | we have it reproduced in a *new* branch | 20:13 |
| jelmer | Noldorin: well, close to that but yeah :) | 20:15 |
| jelmer | Noldorin: it's still a branch with a lot of extra data that makes it hard to see what the actual issue is | 20:15 |
| jelmer | and something that's indeed hard to turn into a unit test | 20:15 |
| Noldorin | jelmer, no, it's precisely a new branch. it doesn't import any metadata, just file data | 20:16 |
| jelmer | Noldorin: that's still a lot of extra data | 20:16 |
| Noldorin | true | 20:16 |
| Noldorin | let me see what i can do... | 20:16 |
| Noldorin | jelmer, i also am curious when the 2.5b1 windows setup will be out...i guess jam builds it | 20:16 |
| jelmer | Noldorin: related to that, I just proposed adding bzr-git to the installer: https://code.launchpad.net/~jelmer/bzr-windows-installers/bzr-git/+merge/76100 | 20:20 |
| Noldorin | jelmer, awesome :-D | 20:20 |
| Noldorin | jelmer, site we got site-packages though, it's pretty easy to add manually anyway though | 20:20 |
| Noldorin | only that annoyingly python doesn't recognise symlinks on windows :-S | 20:20 |
| jelmer | Noldorin: presumably it shouldn't matter what the contents of the files are that change, just whether they changed | 20:21 |
| Noldorin | so i can't link it to the repository | 20:21 |
| Noldorin | jelmer, indeed | 20:21 |
| Noldorin | jelmer, okay, got a script that reproduces it from scratch :-D | 20:31 |
| Noldorin | will post now | 20:31 |
| Noldorin | jelmer, done! check the comment log | 20:43 |
| mars | Hi, has anyone noticed that the Ubuntu Software Center in Oneiric has two packages named Bazaar? | 20:52 |
| mars | One is Bazaar itself (titled Bazaar Version Control System), the other is bzr-gtk | 20:52 |
| wiz | hello everyone :) | 21:02 |
| jelmer | hi mars | 21:02 |
| jelmer | mars: no, I hadn't seen that. Can you file a bug? | 21:03 |
| mars | jelmer, certainly | 21:03 |
| mars | fwiw, here is what I see when I search: http://people.canonical.com/~mars/USC%20Bazaar%20search%20-%20Screenshot%20at%202011-09-19%2016:54:02.png | 21:04 |
| wiz | it would be great if someone can provide a bit of light for me regarding the bazaar :) I'm currently considering to begin to use it... but there is one thing that bothers me and I didn't find it within documentation yet :( | 21:04 |
| Noldorin | jelmer, so? | 21:14 |
| poolie | hi all | 21:31 |
| mgz | hey poolie. | 21:33 |
| poolie | hi mgz | 21:33 |
| jelmer | hi poolie, mgz | 21:36 |
| jelmer | Noldorin: I'll have a look in a second | 21:36 |
| poolie | hi jelmer | 21:36 |
| jelmer | mgz: did you see my follow question to the bug you filed about cache files opened by bzr-git on windows? | 21:36 |
| jelmer | *follow-up | 21:36 |
| mgz | ah, not yet, I'll look at it. | 21:39 |
| poolie | hi jelmer | 21:40 |
| jelmer | hey poolie | 21:43 |
| jelmer | hmm, glitch in the matrix? | 21:45 |
| mgz | :) | 21:45 |
| Noldorin | jelmer, ok cool | 21:46 |
| jelmer | poolie: do you have anymore thoughts on landing the colocated format changes? | 21:52 |
| jelmer | I'd like to move it forward but am not entirely sure how to do so. | 21:52 |
| jelmer | mars: thanks for filing that bug | 22:00 |
| AfC | poolie wins coolest unicode glyph of the day award with '⪆' | 22:02 |
| poolie | :) | 22:02 |
| poolie | i hope it means what i think it means | 22:02 |
| jelmer | a tent falling in the sea? | 22:03 |
| soren | There are some delightfully confusing glyphs in that section. ⪐ is particularly spectacular. "Can you use it in a sentence?" | 22:06 |
| Noldorin | jelmer, that other rename error can be dealed with separately you think eh? | 22:10 |
| Noldorin | jelmer, i guess the first thing with your testing is to convert that into a bash script (pretty easy i think) and then check what's going on in bzr-git! | 22:20 |
| Noldorin | the problem boils down to moving a subdir into a newly created dir it seems | 22:54 |
| Noldorin | hmm | 22:54 |
| jelmer | Noldorin: looking now | 23:07 |
| Noldorin | great | 23:11 |
| Noldorin | jelmer, just poke me if you need help with the script/other stuff, i'm not going anywhere. :-) | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
