| poolie | maxb, is there any place that th eudd importer summarizes successful imports? | 00:07 |
|---|---|---|
| === mnepton is now known as mneptok | ||
| poolie | ok back in a bit | 00:34 |
| AuroraBorealis | so | 00:45 |
| AuroraBorealis | how the heck do i install pycrypto for windows >.> | 00:45 |
| AuroraBorealis | (which is needed to run bazaar development version or something) | 00:46 |
| AuroraBorealis | or rather what version of visual studio do i need to compile it | 00:56 |
| === AuroraBorealis is now known as aurora|away | ||
| === r0bby is now known as robbyoconnor | ||
| vila | Heigh-ho, Heigh-ho | 07:42 |
| vila | good morning all | 07:42 |
| poolie | hi vila | 07:45 |
| vila | hey poolie | 07:46 |
| vila | :) | 07:48 |
| jelmer | Salut poolie, vila | 07:52 |
| vila | jelmer: hey ! | 07:52 |
| poolie | bon soir | 07:52 |
| poolie | shall we have a chat in a few minutes? | 07:53 |
| vila | poolie: French is not a coherent language, one say (one word) 'bonsoir', 'bonjour' but (two words) 'bonne soirée', 'bonne journée'... | 07:53 |
| vila | poolie: yes, mumble or voip ? | 07:53 |
| vila | poolie: and of course (two words) 'bon appétit' ;) | 07:54 |
| poolie | heh | 07:55 |
| poolie | so much for that | 07:55 |
| Riddell | hi | 07:58 |
| jelmer | moin Riddell | 07:59 |
| poolie | jam, helllo? | 07:59 |
| jam | hi poolie | 07:59 |
| poolie | jam, mumble? | 08:06 |
| poolie | jam: ? | 08:09 |
| jam | right, sorry | 08:09 |
| jam | brt | 08:09 |
| poolie | so vila, thanks for working on the release | 08:15 |
| jam | jelmer: poke? | 08:16 |
| poolie | so, what else, aside from chasing people up about that? | 08:16 |
| vila | so, the summary is that I don't officially announce 2.4.0 waiting for windows installers themselves waiting for a bzr-svn release fixing bug #826946 | 08:16 |
| ubot5 | Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/826946 | 08:16 |
| poolie | fair enough, let's decide about that | 08:17 |
| poolie | and you worked a bit more on configuration stuff? | 08:17 |
| vila | yup, with more to come | 08:17 |
| vila | I'm currently encountering issues about how we deal we env variables | 08:17 |
| poolie | oh? | 08:17 |
| vila | mainly: how are they encoded | 08:17 |
| vila | which itself raises the issue of decoding differently paths/urls and other stuff | 08:18 |
| poolie | ok, so this is if they hold non-ascii strings etc? | 08:18 |
| poolie | "they're in utf-8" :-P | 08:18 |
| vila | with also a link to how configObj "helpfully" returns lists when encountering commas (instead of unicode strings in all other cases) | 08:18 |
| vila | poolie: or mbcs for windows | 08:18 |
| vila | and when I went the "utf-8 rules" route for BZR_HOME I encountered some resistance :) | 08:19 |
| vila | and was told to use fs encoding instead | 08:19 |
| poolie | vila, you seem to have 0 bugs in progress? | 08:20 |
| vila | which is fine except it requires some more input to decide whether an env variable is a path or not | 08:20 |
| vila | meh | 08:20 |
| vila | https://bugs.launchpad.net/bzr/2.4/+bug/824513 ? | 08:20 |
| ubot5 | Error: ubuntu bug 2 not found | 08:20 |
| poolie | i don't want to create a lot of paperwork but perhaps having just a "environment isn't handled by config" etc makes sense | 08:20 |
| vila | oh, that's because it's fixed in trunk but not in 2.4 | 08:20 |
| poolie | ok, so what's up next? | 08:21 |
| vila | once env vars are sorted, option expansion (waiting on env vars but almost ready to submit) | 08:22 |
| vila | then 'bzr config' on top of the new design | 08:22 |
| vila | then probably a path/url option type (not sure about that yet) | 08:23 |
| poolie | ok | 08:23 |
| vila | then migrating the remaining options | 08:23 |
| poolie | jam, jelmer, does working on this still make sense to you? | 08:23 |
| jelmer | poolie: hmm | 08:24 |
| jelmer | it'd be nice to finish the work | 08:24 |
| jelmer | but there's always plenty of small things to work on | 08:29 |
| poolie | jelmer, so you're saying these don't necessarily stick out ahead of other bugs? | 08:30 |
| poolie | jr, thanks for the pp mail | 08:33 |
| poolie | like i said on the list the main thing is probably to just chase people up to finish them | 08:33 |
| poolie | (possibly people is me) | 08:33 |
| poolie | jr, i think getting i18n finished off would be well worth while | 08:38 |
| poolie | since it seems like it does largely exist | 08:38 |
| poolie | i think we will need to fix up the way some strings are handled | 08:38 |
| poolie | perhaps we can have a debug flag that turns off gettext entirely, in case something horrible goes wrong | 08:39 |
| poolie | oh, one thing i was going to mention is tox | 08:58 |
| poolie | http://pypi.python.org/pypi/tox | 08:58 |
| poolie | which you can use for a kind of local mini-babune | 08:59 |
| vila | poolie: sry, I missed "environment isn't handled by config" msg, what do you mean by that ? Stop supporting env vars ? BZR_EMAIL, EDITOR and so on ? Ignore the existing bugs ? Or just "don't try too hard" for the new stuff ? (Which is the spirit I followed in https://code.launchpad.net/~vila/bzr/convert-default-values/+merge/72431) ? | 09:04 |
| poolie | my point was, please file bugs for enhancement work | 09:04 |
| poolie | vila, does that answer your question? | 09:08 |
| vila | on the surface, yes, on the deeper issue of whether or not we should fix config, not really | 09:10 |
| vila | bugs like http://pad.lv/388725, the lack of a proper conf file for working trees, the diverging implementations of config stuff in plugins, needs a re-design. | 09:14 |
| ubot5 | Launchpad bug 388725 in Duplicity "Report when duplicity is 'done' with restoring a file" [Undecided,New] | 09:14 |
| vila | bah, bug #388275 | 09:14 |
| ubot5 | Launchpad bug 388275 in Bazaar "want configuration option to control progress bars" [Medium,Confirmed] https://launchpad.net/bugs/388275 | 09:14 |
| vila | gha, bug #491196 damn it | 09:15 |
| ubot5 | Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196 | 09:15 |
| nigelb | poolie: lol, I had babu on /hilight and I got pinged for babune ^-^ | 09:18 |
| jimis | Hi all, I'm trying to connect to launchpad (bzr launchpad login) but because of a firewall on outgoing connections I can't. | 09:31 |
| jimis | Which ports should be allowed to connect? strace shows too many, are they all needed? In particular I can see 785,786,745,53,443 | 09:32 |
| jelmer | just https and ssh should be sufficient I think | 09:33 |
| jelmer | and DNS obviously :) | 09:33 |
| jimis | thanks jelmer | 09:41 |
| jimis | DNS, why didn't I think of that :-) | 09:41 |
| jimis | jelmer: ssh at launchpad is on port 22? | 09:42 |
| jelmer | jimis, yep | 09:42 |
| jimis | ok, I'll ask for 443 and 22 from the admin | 09:43 |
| jimis | I believe 443 will be easy, but we'll have some disagreement on 22 :-p | 09:43 |
| * vila pesters useless goats | 09:49 | |
| poolie | jam, lool just told me he regularly run http://paste.debian.net/127113/ | 09:50 |
| poolie | to fetch history | 09:50 |
| poolie | so, apparently having a lot of history copied is not enough to make the existing get_parent_map patch work really well | 09:51 |
| lool | the main reason we're running this is to speed up pushes, because there is only one stacked branch, but it was lacking too much data from gcc-4.4 or 4.6 and that slowed down pushes dramatically | 09:53 |
| poolie | right | 10:00 |
| poolie | hm | 10:00 |
| poolie | i wonder if they should be unstacked altogether if you're doing this then | 10:01 |
| poolie | let's see if jam comes back | 10:01 |
| jam | lool: that is fetching into r_4_5, don't you want to fetch into r_4_6? | 10:02 |
| jam | or are you saying that doing the fetches into r_4_5 didn't make things faster? | 10:02 |
| jam | if 4.5 is the "dev_focus" it should *already* have all the revisions | 10:03 |
| jam | the thing we wanted you to run is to push the extra revisions into the stacked branches, until such time that we fix the fetch issues | 10:03 |
| jam | (the issue is that when a revision is in the stacked-*on* branch, not the stacked branch, we first query the stacked branch, and then fall back to the stacked-on branch, where we already have the information cached in memory, we just need to access it first.) | 10:04 |
| lool | jam: 4.5 is the devfocus, so is the default stacked branch | 10:07 |
| lool | jam: what we want is for a push to be fast | 10:07 |
| jam | lool: "it is the default branch that gets stacked on" | 10:07 |
| jam | lool: what branches are you pushing to regularly? All of them? Just 4.5? | 10:08 |
| lool | jam: e.g. I push a new topic branch, for 4.4, 4.5 or 4.6 and I want that push to be fast because launchpad stacks the devfocus (4.5) by default | 10:08 |
| lool | jam: 4.4 is probably abandonned by now; 4.5 is mostly bugfixes, the true dev focus is 4.6 AFAIK | 10:08 |
| lool | so we push to random new topic branches for merging, and we push to 4.5 and 4.6 | 10:09 |
| jam | lool: most likely you should try to migrate your dev focus branch to 4.6 | 10:09 |
| jam | since, in theory, it should always have everything 4.5 has, right? | 10:09 |
| jam | (at least after convergence) | 10:09 |
| jam | I'm not sure how gcc does multiple mainlines | 10:09 |
| jam | do you merge up? | 10:09 |
| lool | jam: I don't think we ever merge across 4.x branches; too much upstream delta for this to be useful | 10:10 |
| jam | k | 10:10 |
| jam | so you'll still need to do some sort of fetch everything if it isn't happening naturally | 10:10 |
| lool | jam: I also believe that we should switch the devfocus, but I don't think it would make any concrete difference, would it? | 10:10 |
| jam | otherwise the 4.X(not-focus) feature branches will grow | 10:11 |
| lool | yes | 10:11 |
| jam | lool: for push performance, it should be similar | 10:11 |
| jam | just that it takes less maintenance the closer you get it to the actual feature branches | 10:11 |
| lool | well, launchpad could be more clever about picking up stacked branches, but that's another story | 10:11 |
| jam | for *pull* and *branch* performance, that could be different | 10:11 |
| lool | would it? AIUI, people work with local rev repos (init-repo) so that they already have most of the revs around | 10:12 |
| lool | does the lookup in the stacked branch cost a lot to launchpad? | 10:12 |
| jam | lool: it is cheap for launchpad, but it is a round trip. the bug is #388269 | 10:15 |
| jam | lool: if people have shared repos that are populated, it doesn't make a difference | 10:16 |
| jam | bug #388269 is about initial branching into an empty shared repo | 10:16 |
| ubot5 | Launchpad bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,In progress] https://launchpad.net/bugs/388269 | 10:16 |
| jam | which is *painfully* slow | 10:16 |
| jam | like hours doing nothing slow. | 10:16 |
| jam | because it sends 100k requests to lp each one replying with "nope, I don't have that" | 10:16 |
| lool | so if gcc-4.6 is stacked on gcc-4.5 in launchpad and I branch 4.6, I would hit that bug? | 10:22 |
| lool | sounds like I should populate 4.6 with 4.5 contents then, just in case some 4.6 revs are in 4.5 and that it takes a roundtrip to figure it out | 10:23 |
| jam | lool: right, it only really matters for big fetches. If it is 50 round trips, not a big deal. The problem is when it is *thousands* | 10:24 |
| jam | So you shouldn't have to do it regularly, we just want to do it once | 10:24 |
| jam | but we don't have write access. | 10:24 |
| lool | I'll do it from my cron which is doing this already | 10:33 |
| lool | I've setup a special launchpad account which has write permissions to the linaro toolchain branches | 10:33 |
| lool | well only need to be done once indeed; new 4.6 revisions would be pushed only there anyway, not to the stacked branch | 10:39 |
| poolie | ok good night | 11:24 |
| lool | 'night | 11:25 |
| lool | the copy hsa been running for close to an hour now, gah | 11:25 |
| jelmer | g'night poolie | 11:25 |
| lool | Connection to bazaar.launchpad.net closed by remote host. | 11:37 |
| lool | ..... | 11:37 |
| lool | .... but it still runs | 11:37 |
| masterkorp | hello, how do i get the brevision number ? | 12:32 |
| masterkorp | *revision | 12:32 |
| masterkorp | of the repo | 12:32 |
| lool | bzr revno | 12:36 |
| lool | but it's per-branch, not per-repo | 12:36 |
| masterkorp | lool: thnks i just want anything to help on packaging | 12:37 |
| * lool goes out & | 12:37 | |
| === med_out is now known as medberry | ||
| === shadeslayer_ is now known as shadeslayer | ||
| Riddell | jelmer: you did bug 810701 in trunk, how come you milestoned it to 2.4 but didn't put it into 2.4? | 14:57 |
| ubot5 | Launchpad bug 810701 in Bazaar "i18n.install fails in fails some situations" [High,Fix released] https://launchpad.net/bugs/810701 | 14:57 |
| jelmer | Riddell: I don't recall, I suspect it was probably around the time the 2.4 branch was opened | 15:01 |
| Riddell | jelmer: well this gives me a good opportunity to learn how to do backporting | 15:02 |
| Riddell | how is backporting done? merge request to 2.4 and pqm? | 15:02 |
| jelmer | Riddell: yep, basically | 15:02 |
| jelmer | Riddell: you'll need pqm commit access to 2.4 | 15:02 |
| Riddell | and that's different to trunk? | 15:02 |
| jelmer | yep | 15:03 |
| Riddell | how do I know if I have that? | 15:03 |
| jelmer | try to submit something and see if you get back an error :) | 15:03 |
| jelmer | otherwise, it should be trivial for jam or vila to submit it once the MP is up on Launchpad | 15:03 |
| * vila nods | 15:04 | |
| vila | jelmer: alternatively mail rt to get this fixed ;) | 15:04 |
| Riddell | "merge http://bazaar.launchpad.net/~jr/bzr/2.4-810701-lang-not-set http://bazaar.launchpad.net/~bzr-pqm/bzr/2.4 Command failed!" | 15:12 |
| Riddell | guess I don't have permission then | 15:12 |
| vila | where did you see that ? | 15:12 |
| Riddell | in my e-mail | 15:12 |
| vila | ha, ok | 15:12 |
| Riddell | what is our magic secret rt address? | 15:12 |
| Riddell | well hopefull that won't take a week to go through like it did last time | 15:16 |
| vila | Riddell: I can submit it if you want | 15:25 |
| Riddell | vila: I'd like to get it in, just to check I understand the process | 15:26 |
| vila | Riddell: well, I just did | 15:26 |
| vila | argh | 15:26 |
| jelmer | if you're going to submit a RT anyway, can you mention me as well? | 15:26 |
| Riddell | hah, you're too fast | 15:26 |
| vila | Riddell: but once it has landed, you can still merge 2.4 into trunk and submit that | 15:26 |
| Riddell | it's already in trunk | 15:27 |
| vila | which is really part of the backport workflow | 15:27 |
| vila | then merging will make sure noone else have to handle possible conflicts | 15:27 |
| Riddell | jelmer: done | 15:27 |
| Riddell | vila: so it should be merged to trunk even if it's already in trunk? | 15:27 |
| vila | only if the initial proposal wasn't targeted at 2.4 | 15:28 |
| vila | i.e. if you backported by cherry-picking, conflicts can occur when merging | 15:28 |
| Riddell | that's confusing | 15:29 |
| vila | if you're the one handling *that* merge, the conflicts will be trivial to solve | 15:29 |
| vila | Riddell: what is confusing ? | 15:29 |
| vila | that the same change applied to two different branches can conflict ? | 15:29 |
| Riddell | yes | 15:29 |
| vila | well, backports generally involve slightly different changes | 15:30 |
| vila | if the change is *exactly* the same, there should be no conflict | 15:30 |
| Riddell | it's the same except for the release note | 15:30 |
| vila | ha, then no conflict there obviously (but we try to avoid duplicating the news entries... which means targeting the lower possible series and merging up.. shudder) | 15:32 |
| mgz | yeah, release notes/news tend to make life overly complicated | 15:42 |
| * mgz fiddled with the bug entries a bit | 15:42 | |
| mgz | vila: good you mentioned the path-in-envvar thing in the meeting this morning, I wanted to ask you about that since the branch with the config env changes landed | 15:43 |
| vila | right, I filed some bugs since then and I'm eagerly awaiting for your comments at least on bug #832028 | 15:45 |
| ubot5 | Launchpad bug 832028 in Bazaar "environment variables are not decoded properly" [Medium,Confirmed] https://launchpad.net/bugs/832028 | 15:45 |
| mgz | cool, catching up on mail now, will leave comments as I go | 15:47 |
| mgz | Riddell: who was it you were helping land a branch in here the other evening? | 15:55 |
| mgz | ...I should just grep logs I guess | 15:55 |
| mgz | ~weyrick | 15:57 |
| Riddell | mgz: that's the one | 15:57 |
| Riddell | GRiD | 15:57 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === medberry is now known as med_out | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| AuroraBorealis | hello. | 17:49 |
| AuroraBorealis | anyone here to help me understanding some of the bzr code base? :D | 17:51 |
| jelmer | AuroraBorealis, hey | 17:53 |
| jelmer | AuroraBorealis: Sure, ask away :) | 17:53 |
| AuroraBorealis | so i'm trying my best to fix https://bugs.launchpad.net/bzr/+bug/81689, and Martin Pool was giving me some pointers to get started, and my first question is what are the TreeTransform classes? | 17:55 |
| ubot5 | Ubuntu bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed] | 17:55 |
| AuroraBorealis | or rather a more general description of them then just "represent a tree transformation | 17:55 |
| AuroraBorealis | also: i love how the bzr lazy import system makes pydev + eclipse go crazy. | 18:00 |
| * jelmer looks a tthe bug | 18:00 | |
| jelmer | AuroraBorealis, the tree transform classes live in bzrlib/transform.py IIRC | 18:00 |
| AuroraBorealis | yeah i'm looking at them | 18:01 |
| jelmer | AuroraBorealis, they're the layer that's used for modifying trees on disk when creating a new checkout or applying a merge to a working tree | 18:01 |
| AuroraBorealis | so, baiscally they are just classes that manipulate a tree in some way, either to merge or to write to disk? | 18:02 |
| jelmer | AuroraBorealis, they're the infrastructure that's used by merge and the working tree construction code | 18:02 |
| AuroraBorealis | ah ok | 18:03 |
| jelmer | the merge/revert/checkout code lives on top of tree transform | 18:03 |
| AuroraBorealis | cause the method where its throwing the 'can't create symlinks on windows" is in DiskTreeTransform, which i assume is just the class for creating a working tree on disk | 18:04 |
| jelmer | AuroraBorealis: the tree transform code is generic - the same TreeTransform class is used to create files on disk as is used to apply the changes of a merge | 18:05 |
| jelmer | At least that's my understanding of it - merge would use DiskTreeTransform too | 18:05 |
| AuroraBorealis | ok, kinda makes sense | 18:07 |
| AuroraBorealis | its also a bit confusing cause in transform.py they are using a lot of dictionaries and i'm nott sure what is used for what :> | 18:11 |
| AuroraBorealis | but anyway, i think i know what place to fix it, but should i leave the "file kind" as symlink, or a file? | 18:13 |
| jelmer | AuroraBorealis: I'm not sure, I'm not very familiar with the transform code | 18:16 |
| jelmer | AuroraBorealis, the best thing to do would probably be to ask on the bug | 18:16 |
| AuroraBorealis | i'll post there and mess around on my code, thanks =) | 18:16 |
| AuroraBorealis | also, is there a file that lists what...gets called for each of bazaar's actions? like.. bzr add, checkout, merge, etc | 18:42 |
| GRiD | hi mgz, did you need something? (re: Riddell helping me land the branch) | 20:25 |
| davi_ | is there a way to limit the number of revisions in dpush (bzr-git)? looking at the code, it seems it should be possible to pass a stop revision | 20:57 |
| jelmer | davi_: Hi | 20:58 |
| jelmer | davi_: yes, but I don't think dpush does what you want | 20:58 |
| jelmer | davi_: dpush only supports incremental pushes since it changes the source branch | 20:59 |
| jelmer | which is fine if you | 20:59 |
| jelmer | 're contributing back to an upstream project that is in git | 20:59 |
| jelmer | but it doesn't work for the situation where you're maintaining an independent mirror | 20:59 |
| jelmer | it sounds like what you want is "proper" push support, which is bug 544776; that would also allow incremental pushing | 21:00 |
| ubot5 | Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776 | 21:00 |
| davi_ | jelmer, there won't be "contributing" back, just want to be able to keep some branch (in git) up to date with the upstream (in bzr). is there any problem in changing the source branch? it's a throw away branch any taken from the real upstream | 21:04 |
| davi_ | *anyway | 21:05 |
| jelmer | davi_: If it changes the source branch then you won't be able to pull from bzr anymore, as the histories diverge | 21:05 |
| davi_ | jelmer, ah. in what what way it changes the source branch history? | 21:06 |
| jelmer | davi_: dpush (and this is why it's a separate command, and not part of "bzr push") basically pushes all data that can natively be represented in git into the target branch, then reimports it into bzr | 21:08 |
| davi_ | jelmer, ah, i wasn't aware of the reimport part. thanks | 21:08 |
| jelmer | davi_: you can prevent dpush from rewriting the source branch with the reimported data by using --no-rebase | 21:08 |
| jelmer | davi_: but if you do that, then there is no shared history the next time you run dpush | 21:09 |
| davi_ | jelmer, ok, i should have read the help for dpush more carefully.. | 21:09 |
| jelmer | davi_: The roundtripping support (in other words, getting "bzr push" to work) is on my long term todo list. | 21:12 |
| jelmer | davi_: In the mean time, I suspect bzr fast-export is probably the best alternative | 21:12 |
| davi_ | jelmer, yeah, saw that the bug report is in progress. | 21:12 |
| davi_ | jelmer, but one question, if there are two independent source branches, with round tripping, will both be able to push into the git repository? (like, one of the branches has fewer revisions than the other when compared to a upstream branch) | 21:14 |
| jelmer | davi_: Yeah | 21:14 |
| davi_ | jelmer, ok, i shall wait then. thanks | 21:15 |
| mgz | GRiD: no, sorry, just wanted to look at the branch as I was interested | 21:29 |
| mgz | (I was thinking about a related kind of handling of large files previously and wanted to see how it compared) | 21:32 |
| GRiD | mgz, oh ok. how does it compare? :) | 21:33 |
| mgz | GRiD: the ui looks similar, which is good | 21:40 |
| mgz | and I'm not sure the idea of treating large files as unversioned branch objects like tags is a good one, given the problems tags have run into | 21:41 |
| mgz | (the basic idea was to, rather than ignore files larger than threshhold, stash a single copy so it can be branched, but not save all past versions) | 21:42 |
| mgz | your branch avoids all the accidental pain without having to add a whole new store, which is a really good thing | 21:45 |
| GRiD | ok. well it sounds like your idea had more sophisticated goals, where they knew the large file existed and they didn't want to deal with the overhead of a normal versioned file? this patch was really more on the order of saving people from accidentally committing their ISOs (or whatever) | 21:46 |
| mgz | right. | 21:47 |
| GRiD | i'd honestly be thrilled to hear this saved someone some pain, i'm not sure how much of a requested feature this really is. it was an old bug :) | 21:48 |
| GRiD | (it was really intended as a way for me to jump in bzr hacking) | 21:48 |
| GRiD | s/in/into | 21:48 |
| mgz | I suspect you'll never hear that, but we'll have fewer reports of OOM or performance issues from people who have such mistakes at some point during their project history | 21:49 |
| mgz | which *has* happened quite a lot, so it was a really good bug to tackle. | 21:49 |
| GRiD | nod. cool, that's good to hear. | 21:50 |
| GRiD | i'm currently taking suggestions on useful bugs to solve for my second effort ... | 21:50 |
| mgz | ho ho ho. | 21:50 |
| GRiD | ;) | 21:50 |
| GRiD | i was looking at some of the performance bugs, since i enjoy working on that kind of thing. but i probably don't know the codebase well enough to dive in that far, yet. | 21:52 |
| mgz | if you're up for a little investigation, how about bug 720853 for instance? | 21:53 |
| ubot5 | Launchpad bug 720853 in bzr search plugin "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [High,Confirmed] https://launchpad.net/bugs/720853 | 21:53 |
| mgz | repo involves a plugin, but the problem seems to be in a specific bit of bzrlib | 21:54 |
| GRiD | ok sure, i'll take a look. | 21:56 |
| poolie | hi all | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!