| jelmer | spiv: :-( Is your data ok? | 00:03 |
|---|---|---|
| spiv | jelmer: yeah, everything on that disk is backed up every 3 hours | 00:04 |
| spiv | So at worst we'll have lost some mail I guess... and a whole bunch of time. | 00:05 |
| poolie | hi spiv | 00:06 |
| poolie | spiv, raid1 :) | 00:06 |
| poolie | you know it makes sense | 00:06 |
| spiv | poolie: :) | 00:10 |
| spiv | I'm not sure that futzing with making raid work is actually a net savings of time ;) | 00:11 |
| LeoNerd | RAID of course also doesn't protect you from rm -rf | 00:13 |
| LeoNerd | Or ext3 bugs | 00:13 |
| spiv | The current arrangement is basically have a dedicated backup drive and a cronjob for rdiff-backup. | 00:13 |
| spiv | LeoNerd: right | 00:13 |
| spiv | So we'd want to add another drive rather than repurpose the existing backup drive. | 00:14 |
| maxb | 'Error -3 while decompressing data: incorrect data check' ... hmm, mysterious | 00:26 |
| poolie | spiv, you may be right | 00:27 |
| poolie | i bought a UPS but it has been a net loss of time so far | 00:27 |
| poolie | (more for the sake of avoiding spikes than to stay up and running) | 00:28 |
| lifeless | spiv: you might like to look for ForwardingResult in bzrlib.tests | 00:41 |
| lifeless | spiv: theres a trivial patch waiting for someone ;) | 00:41 |
| sidnei | hi poolie, i can't remember if i asked you this before or not, so here goes: is it possible to mark a text file as binary in bzr so that it doesn't show up in diffs and so it gets different conflict resolution? or is that a stupid idea? | 01:02 |
| poolie | it's a good idea but it's not currently supported | 01:02 |
| poolie | there's a bug asking for it | 01:02 |
| sidnei | poolie, we're storing minified css/js files in a branch, and we constantly get conflicts on them. the fix is always to re-build them from the original source. it also makes merge proposals pretty nasty. | 01:03 |
| poolie | patches welcome :) | 01:04 |
| poolie | it won't be too hard | 01:04 |
| poolie | you know you want to :) | 01:04 |
| sidnei | i do :) | 01:04 |
| sidnei | maybe during paternity leave | 01:04 |
| sidnei | poolie, would that be bug #218128? | 01:10 |
| ubot5 | Launchpad bug 218128 in Bazaar "want a way to mark files as binary even if they look like text (eg pdf files) (affected: 9, heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/218128 | 01:10 |
| poolie | yes | 01:12 |
| sidnei | bug #491556 seems relevant too | 01:26 |
| ubot5 | Launchpad bug 491556 in Bazaar "Add option to ignore files from diff view but not VCS (affected: 3, heat: 1)" [Wishlist,Confirmed] https://launchpad.net/bugs/491556 | 01:26 |
| === Ursinha is now known as Ursinha-afk | ||
| jbowtie | CodePlex is happy for me to test bzr-tfs against their servers, even if the tests generate malformed weirdness. | 01:42 |
| jbowtie | So we may actually get something halfway robust this release. | 01:43 |
| lifeless | jbowtie: awesome | 01:44 |
| jbowtie | lifeless: thanks. | 01:49 |
| poolie | rocking | 01:49 |
| jelmer | jbowtie: Great :-) | 01:52 |
| jelmer | Some people have already been using bzr-svn against their svn bridge, I suspect that may have a fair bit more impact on their servers because of the mapping that has to happen on both sides. | 01:53 |
| FryGuy- | jbowtie: are you the guy that handles the bzr-tfs? | 01:56 |
| jbowtie | FryGuy-: Yes, that's me. | 01:57 |
| FryGuy- | also, is it normal for bzr merge to complain about uncommitted changes, but bzr st shows nothing? :( | 01:57 |
| FryGuy- | Hi. I'm the guy that puts broken branches into the repository | 01:57 |
| jbowtie | Yes, I was going to review those over the weekend. | 01:58 |
| lifeless | FryGuy-: no, thats not normal | 01:58 |
| lifeless | FryGuy-: are you perhaps using 'bzr st .' rather than 'bzr st' ? | 01:59 |
| FryGuy- | Unfortunately, I've broken my tfs repository, and bzr-tfs no longer can work on it | 01:59 |
| jbowtie | I really appreciate you taking the time to do that, it's really helpful. | 01:59 |
| FryGuy- | [24]: bzr merge C:\dev\botevent | 01:59 |
| FryGuy- | bzr: ERROR: Working tree "C:/dev/robogames/registration/" has uncommitted changes (See bzr status). | 01:59 |
| FryGuy- | [25]: bzr st | 01:59 |
| FryGuy- | [26]: | 01:59 |
| lifeless | thats ... bizarre | 02:00 |
| jbowtie | Ouch, hopefully it wasn't bzr-tfs that broke it. | 02:00 |
| FryGuy- | glad it's not bazaar. hehe | 02:00 |
| lifeless | uhm, you don't have any aliases perhapss? | 02:00 |
| FryGuy- | no this is my local machine, not my work machine | 02:00 |
| lifeless | try 'bzr commit' - it should pop up an editor with whatever changes it thinks exists | 02:01 |
| lifeless | or 'bzr revert', if you're sure you have no changes. | 02:01 |
| jbowtie | FryGuy-: What does bzr info say about those branches? | 02:01 |
| spiv | Or 'bzr --no-aliases --no-plugins st' | 02:01 |
| FryGuy- | [26]: | 02:01 |
| FryGuy- | bzr commit | 02:01 |
| FryGuy- | Committing to: C:/dev/robogames/registration/ | 02:01 |
| FryGuy- | missing application/config/config.template.php.OTHER | 02:01 |
| FryGuy- | aborting commit write group: PointlessCommit(No changes to commit) | 02:01 |
| FryGuy- | [27]: bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow. | 02:01 |
| lifeless | hah, added but missing | 02:01 |
| lifeless | FryGuy-: bzr remove --new | 02:02 |
| lifeless | should do it | 02:02 |
| FryGuy- | ah | 02:02 |
| FryGuy- | i did it another way, but ya | 02:02 |
| spiv | Hmm, that's perhaps a bug in 'bzr st' | 02:02 |
| lifeless | spiv: 'feature' >< | 02:02 |
| FryGuy- | bzr rm application/config/config.template.php.OTHER | 02:02 |
| FryGuy- | should I file a bug report? | 02:03 |
| spiv | FryGuy-: yes, please do. | 02:03 |
| spiv | At a minimum that error shouldn't suggest 'See bzr status' if that command won't tell you anything :) | 02:04 |
| FryGuy- | well, i'm glad there's some experts in here at least :) | 02:06 |
| jbowtie | I'm going to have to start prioritising my bzr work, too many open branches on my local machine. | 02:07 |
| jbowtie | OK, just proposed an actual plan of attack for large binaries on the mailing list. Please find the glaring flaw in my logic. | 03:07 |
| KombuchaKip | jbowtie: Man, I really started a shit storm opening pandora's box in bringing up that whole issue with my game. | 03:21 |
| poolie | hi spiv | 03:23 |
| jbowtie | KombuchaKip: We were always going to have the issue eventually, might as well get it sorted now. | 03:23 |
| poolie | are you persisting on the inventory package importer failures? | 03:24 |
| KombuchaKip | jbowtie: Fair enough. And at least now we'll have a good real world case study to test it on. | 03:24 |
| jbowtie | KombuchaKip: That's the plan. I was going to need this solved before I could start writing my diff/merge proposal for Blender files anyhow. | 03:25 |
| jbowtie | And if no one finds a glaring flaw in my approach, it'll be a glorious opportunity to really learn the messy internals of bzr. | 03:27 |
| KombuchaKip | jbowtie: Excellent. I'll let you know the repository URL as soon as I get it up so you can see how well it runs on our large game data files. I'd have the repository up sooner, but sadly DreamHost doesn't have Bazaar over any other means than ssh. | 03:27 |
| poolie | spiv i think you win some kind of prize for single largest diff | 03:29 |
| poolie | even though it's mechanical | 03:29 |
| spiv | poolie: yes, I am persisting on that, in between trying to recover from the disk failure. | 03:46 |
| poolie | :} sorry, didn't mean to lack sympathy there | 03:46 |
| poolie | is it kaput? | 03:46 |
| spiv | Don't worry, no lack of sympathy inferred :) | 03:46 |
| spiv | We're a bit puzzled atm, actually. | 03:47 |
| lifeless | spiv: just checking it wasn't lost - did you see the code duplication I referenced in tests ? | 03:47 |
| spiv | We're fearing an issue in something other than the disks, because while copying from the backup drive to the new drive we started getting IO errors too. | 03:48 |
| spiv | lifeless: I did, branch pushed even, just haven't lp-proposed it yet | 03:48 |
| lifeless | awesome thanks | 03:48 |
| spiv | lifeless: thanks for noticing! | 03:48 |
| spiv | On one hand it would be nice to discover all our data is completely intact, even stuff since the last 3-hour backup window... on the other, hard drives are cheap and quick-ish to replace, other components not so much. | 03:49 |
| poolie | do you have offsite backups too? | 03:51 |
| poolie | duplicity to s3 is very good | 03:51 |
| spiv | For some key stuff, but not for the bulk. | 03:53 |
| spiv | I think when we last looked s3 was more expensive than we were willing to pay. Someone recently pointed us to crashplan which looks tempting. | 03:54 |
| poolie | hm | 03:55 |
| poolie | we could swap gpg-encrypted duplicities with each other | 03:55 |
| poolie | i have a few tens of GB free, at least | 03:55 |
| spiv | That sort of thing starts making Tahoe sound more interesting :) | 03:58 |
| poolie | mm | 03:59 |
| dmuir | anyone, how do I deal with a path conflict? | 04:59 |
| dmuir | ah, found it in the docs | 05:03 |
| dmuir | hmm, looks like the docs are wrong | 05:08 |
| dmuir | it says to use `bzr mv PATH2 PATH1` + --action=take-other or --action=done to resolve the conflict | 05:09 |
| dmuir | I tried being smart and did bzr resolve PATH2 --take-this | 05:11 |
| dmuir | but this resulted in bzr crashing | 05:11 |
| dmuir | I re-read the docs, and I misunderstood because of a formatting bug | 05:27 |
| dmuir | filed a bug report for the crash | 05:33 |
| jbowtie | dmuir: Can you also file a bug report for doc formatting bug? | 05:39 |
| dmuir | sure | 05:40 |
| jbowtie | dmuir: Thanks. I'll fix that up this weekend. | 05:41 |
| dmuir | had a look at the bzr.dev docs and it looks like it has been fixed there | 05:41 |
| dmuir | jbowtie: should I still submit a bug report? | 05:42 |
| jbowtie | dmuir: Well mention which version of the docs you were looking at and I'll get the fix backported to the appropriate branch. | 05:42 |
| dmuir | it was 2.2, but that said, in some ways the formatting was better in 2.2 | 05:43 |
| jbowtie | dmuir: I'm about to go offline, I'll have to continue the conversation in the bug tracker. ;) | 05:44 |
| dmuir | ok | 05:44 |
| poolie | hi | 06:55 |
| poolie | hi vila? | 06:58 |
| * vila still shaving :) | 06:59 | |
| poolie | your face, or a yak? | 07:00 |
| vila | poolie: hi, almost there but typing with a single hand, expect more typos :) | 07:01 |
| poolie | go away and be in the moment :) | 07:01 |
| vila | my dace :D (must eome yaks are easier) | 07:01 |
| fullermd | I thought you said you'd make MORE typos :p | 07:01 |
| vila | face some. that's MORE :) | 07:02 |
| fullermd | See, that's why I gave up shaving last millennium. Saves me all those tpyos. | 07:03 |
| poolie | woo, feedparser took my patch to enable cache contro/ | 07:06 |
| vila | hi all ! (Shaved and showered) | 07:12 |
| vila | poolie: thanks for the reviews ! | 07:14 |
| vila | poolie: reading the modify-config one | 07:14 |
| vila | 1) regarding indentation: I disagree but don't care enough either to block on this so I'll fix it | 07:15 |
| vila | 2) regarding sections: I won't to keep avoiding them until we are a clearer plan but it *will* be taken into account (later) | 07:16 |
| vila | 3) regarding config_id/paths. As explained in the COVER letter (I think) I don't want to force the user to use paths for --scope | 07:17 |
| vila | So it's more coherent to display them in the output. Now we *also* need a way to make the relationship more obvious | 07:17 |
| vila | But since there will be scopes that are not taken into account yet, I'd like to address that later too | 07:18 |
| vila | (default values in code, command line, env variables are such scopes) | 07:18 |
| vila | and they don't have a clear path equivalent (of course we can just say that in the output but... I feel it's too soon) | 07:19 |
| vila | and a minor point is also that it makes testing harder since the paths are ugly there and not relevant to the real usage | 07:19 |
| vila | poolie: I still don't get what shell scripting use case you have in mind | 07:20 |
| poolie | re 1- i'd like to understand your thoughts there | 07:20 |
| poolie | 2- i don't understand | 07:20 |
| poolie | 3- that's fine; it could be nice for followon work | 07:21 |
| vila | 3ok | 07:21 |
| poolie | re shell scripting: people like to get bzr output that's easily machine parseable | 07:21 |
| poolie | eg for emacs or shell scripts | 07:21 |
| poolie | if I can say just, oh i don't know | 07:21 |
| poolie | mail -s 'here you are' `bzr config submit_to` | 07:21 |
| poolie | i think that's nicer than needing to strip it out | 07:21 |
| poolie | i don't mind if that's, say | 07:22 |
| poolie | `bzr config --just-the-value submit_to` | 07:22 |
| poolie | (hypothetically) | 07:22 |
| vila | ha, right, so that's the --active option which only output the *value* | 07:22 |
| poolie | ok, great | 07:22 |
| vila | typing too slow, yeah, right | 07:23 |
| poolie | then perhaps that should be in the user docs too? | 07:23 |
| vila | indeed | 07:23 |
| vila | and implemented ;) | 07:23 |
| vila | 2 sections are useful but in the actual implementation... messy | 07:23 |
| vila | so I avoided supporting them even if I *want* them supported once we settle on (for example) use them *only* for paths | 07:24 |
| poolie | (i don't think we should reproduce all the help in the user guide, but we do get some feedback saying there's not enough there, and like tests or washing up it's much easier to do it as you go | 07:24 |
| vila | got you | 07:24 |
| poolie | are you talking about printing which section of the config it came from? | 07:24 |
| spiv | Hooray, all data recovered. | 07:24 |
| vila | yes | 07:24 |
| vila | but also about specifying it when setting a value | 07:24 |
| vila | the use cases I presented are all when working in a given working tree (or branch) | 07:25 |
| poolie | hooray | 07:25 |
| poolie | spiv, so you have more than daily rdiff backups? | 07:25 |
| poolie | you may have a point there | 07:25 |
| poolie | spiv, i think you should land your news branch soon before it goes stale | 07:26 |
| vila | but in the long term it's probably useful to be able to work on any config scope by specifying the right options from the command line | 07:26 |
| vila | but since sections are still unclear I prefer to not implement anything before they are clearly defined | 07:26 |
| poolie | fair enough | 07:26 |
| poolie | we could have a followon bug for that too | 07:26 |
| vila | the whole idea of this proposal is to have a rough version *now* that can already help us understand what is going on | 07:27 |
| poolie | yup | 07:27 |
| vila | hence the reference to 'bzr config -d lp:bzr' showing a config value almost everybody forgot | 07:27 |
| poolie | i really support the principle of not insisting on things fully fleshed out in every respect when they first land | 07:28 |
| poolie | ? | 07:28 |
| spiv | poolie: yes, just doing that now | 07:29 |
| vila | right, that's why I feel a bit blocked on some mps even if I tried to make it clear that some parts will need further work ;) | 07:29 |
| spiv | No conflicts with trunk atm, so hopefully it'll be trouble-free... | 07:30 |
| poolie | vila, let's get you unblocked | 07:31 |
| spiv | poolie: regarding backups, it seems the drives are only failing intermittently atm, so it's been relatively easy to copy everything (also, our rdiff runs every few hours, not just daily) | 07:31 |
| poolie | i might change mine to be more frequent too | 07:31 |
| spiv | Intermittent failures is a weird way for a drive to behave, but better than total failure I guess. | 07:32 |
| poolie | i just put up a patch for https://bugs.launchpad.net/duplicity/+bug/433970 that makes duplicity to S3 something like 6x faster | 07:32 |
| ubot5 | Launchpad bug 433970 in Duplicity "Add an option to connect to S3 with regular HTTP (and not HTTPS) (affected: 3, heat: 16)" [Medium,In progress] | 07:32 |
| poolie | i was very pleased | 07:32 |
| poolie | pretty small patch | 07:32 |
| poolie | that does suck; i have seen it before for mechanical failures | 07:32 |
| spiv | I'd suspect cables or something, but both drives had read errors on totally different hardware. | 07:33 |
| vila | poolie: https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690 is the one I have in mind, it's opt-in now so I don't know what is missing here or in the pre-requisites | 07:33 |
| poolie | i had a confusing thing with my sata drives a while ago where the cable was loose and it gave intermittent errors | 07:33 |
| poolie | i'll have a look | 07:33 |
| vila | no whatsnew for modify-config... wtf ! I'm 95% sure I put something there.... did I commit in wrong tree ? | 07:35 |
| vila | by the way, using paths for section in configs have several consequences I thought about: | 07:38 |
| vila | 1) it can be used in *all* config files, so we could merge bazaar.conf and locations.conf | 07:40 |
| vila | 2) , it can apply to paths that describe branches but *also* to relative paths inside a working tree or colocated branches or branches in a repo | 07:40 |
| vila | 3) it could even be used for ignores (opening a path to be more compatible with foreign vcs that implement ignore rules in multiple files | 07:40 |
| poolie | what do you mean for 'paths for section'? | 07:48 |
| poolie | making everything like location.conf? | 07:49 |
| vila | what we do in locations.conf | 07:49 |
| vila | i.e. this applies only to the matching path, highest levels being inherited | 07:49 |
| vila | which works pretty well for scalars but need some... tweaks for lists | 07:50 |
| vila | s/pretty well// | 07:50 |
| vila | like the ability to say: I want to add values to the inherited list (removing values... I don't know what to do with the idea) | 07:51 |
| poolie | mm, and also there's the question of 'match the most specific path' vs 'match in the most important relevant config file' | 07:52 |
| poolie | i probably asked for it, but should we really have 'bzrlib.transform' vs maybe just 'transform'? | 07:52 |
| vila | the later takes priority I'd say | 07:52 |
| poolie | i'm typing too fast | 07:52 |
| vila | I think I understand and that | 07:52 |
| poolie | you're saying the most important relevant match? that works for me | 07:53 |
| vila | yeah | 07:53 |
| vila | regarding bzrlib.transform vs transform, my take was to allow aliases but you disagreed, this is related to what namespace we want there | 07:54 |
| poolie | we could say the 'bzrlib' is implicit | 07:54 |
| vila | it's a little bit less important than the sections though (or may be not) | 07:54 |
| vila | it's higly tempting yes | 07:54 |
| vila | but what about 'alias', 'bookmarks' and whatever plugin authors want to use | 07:55 |
| poolie | plugin.bookmarks? | 07:55 |
| poolie | plugin.bookmarks.auto_record? | 07:55 |
| vila | which immediately raises: whine, this is too long, why is bzrlib taking all the good short names | 07:56 |
| poolie | but surely bzrlib.transform.orphan_policy is a bit inconsistent with bookmarks.auto_record? | 07:56 |
| vila | yup | 07:57 |
| vila | aliases kind of avoid the issue | 07:57 |
| vila | which is not necessarily good | 07:57 |
| vila | it 's a bit like selftest -s, we have a clearly defined name space, but we know some shortcuts are more important than others | 07:58 |
| poolie | in some ways avoiding the 'plugins.' from the name is good because it allows code to move | 07:58 |
| poolie | a bit like that | 07:58 |
| poolie | i wonder if we will ever have overlap with multiple things wanting the same name? | 07:58 |
| vila | and there should be some easy way to avoid name collisions at the alias definition registration | 07:59 |
| vila | :) | 07:59 |
| vila | there is always the case of different plugins clashing | 07:59 |
| vila | or worse: bzr-core starting to use some names without knowing that a plugin was using it | 08:00 |
| poolie | i think that would be a real concern if there was no namespacing at all | 08:00 |
| poolie | but if we have a single word namespace, perhaps it's less so | 08:00 |
| poolie | but if we have a single word namespace, perhaps it's less so | 08:00 |
| poolie | git does use git.core.thing vs others | 08:01 |
| vila | git.core sounds redundant vs git though | 08:01 |
| vila | from a user pov, 'bzr.' 'svn.' might be enough | 08:02 |
| vila | we don't *have* to say 'bzrlib.transform.orphan_policy' when 'bzr.orphan_policy' is enough | 08:03 |
| poolie | i think some amount of grouping of the options is useful though | 08:03 |
| poolie | in programs that get a lot of them (dozens or a hundred) then having them just all randomly named makes things a bit harder | 08:04 |
| vila | but that requires specifying 'bzr.orphan_policy' when declaring 'bzrlib.transform.orphan_policy' (but may be I'm over-concerned here) | 08:04 |
| poolie | how about bzr.transform.orphan_policy then | 08:04 |
| vila | yeah, I don't have hard numbers about what could *become* config variables in the code base | 08:04 |
| vila | hmm, s/bzrlib/bzr/ and be done, seducing | 08:05 |
| vila | s/bzrlib.plugins.name/name/ | 08:05 |
| vila | the later should work too, very-unlikely to clash since that requires having a plugin named after a bzrlib module | 08:06 |
| vila | checking with http://doc.bazaar.canonical.com/plugins/en/ | 08:07 |
| vila | pfew, email vs email_message | 08:07 |
| vila | bisect vs bisect_multi | 08:08 |
| vila | that's the closest, so no clash | 08:09 |
| vila | and if a clash would happen... that would strongly suggest inclusion in core anyway :) | 08:09 |
| poolie | right | 08:10 |
| poolie | obviously you can just have random names and then group them in metadata or in the documentation | 08:10 |
| poolie | but then everything needs to know about that | 08:10 |
| poolie | i think there's quite a few things that will make more sense as config options | 08:10 |
| poolie | especially if we allow for builtin defaults, and for per-process settings | 08:11 |
| poolie | and make the internal api a bit cleaner | 08:11 |
| poolie | as i think you've started doing | 08:11 |
| vila | yup, I should really focus on documenting what I have in mind in a.... developer doc and make a mp for that for feedback | 08:12 |
| vila | and refer to it for a ML discussion | 08:12 |
| poolie | that'd be good, and also user docs | 08:12 |
| vila | indeed, but user docs aren't enough, I should have said that: user doc *and* dev doc since I'd like to change the internal model | 08:13 |
| vila | I think this sums up my feelings regarding the modify-config mp: I wanted to land *something* so I can refer to it in these docs | 08:14 |
| vila | so I deliberately avoid some issues and implement some hacks with an unspecified target which led to annoying questions raised in the review :) | 08:15 |
| vila | I *don't* have an hidden agenda, I just happen to not have published it yet :) | 08:16 |
| vila | it just happend that I don't have ? | 08:16 |
| vila | right, I happen every day :) | 08:17 |
| poolie | i'm replying again now | 08:23 |
| poolie | vila, ok, a few more tweaks and let's land it | 08:25 |
| poolie | i think i did many more reviews this week than when i was officially pp last week | 08:25 |
| poolie | which is fine | 08:25 |
| vila | indeed, thanks for that, the queue is back under control | 08:26 |
| vila | now if we could get testtools updated on pqm.... | 08:26 |
| poolie | mm | 08:26 |
| poolie | i'm going to leave the rest of them to you i think | 08:27 |
| poolie | i still wanted to finish my lp dkim fixes today and it's 6.30 already | 08:27 |
| poolie | maybe next week i'll try tarmac | 08:28 |
| vila | I don't have mps I haven't review at least once any more | 08:28 |
| vila | some are waiting for either another reviewer or testtools upgrade or more input from the reviewee | 08:29 |
| poolie | well, "leave them to someone else" then | 08:31 |
| vila | sure, I even ping them when needed ;) | 08:32 |
| vila | hmm, I know another reason why I don't like indenting the inplace files: it's one of the very few cases where emacs don't DTRT when I press TAB anywhere in the line :) | 08:37 |
| vila | AAAARGH, still not fixed in maverick... why oh why can't process monitor remember that I *want* to see the command line !! | 08:46 |
| vila | sudo process-monitor show-me-your-config-files-so-I-can-nuke-them | 08:47 |
| bigjools | Can anyone help me work out why bzr is giving me this error please? http://pastebin.ubuntu.com/513683 | 09:50 |
| spiv | bigjools: random guess: bzr-pqm plugin is old? | 09:56 |
| * bigjools checks | 09:56 | |
| spiv | Hmm, a glance at the revision history for bzr-pqm suggests I'm probably right. | 09:56 |
| bigjools | spiv: that was it, thank you | 09:57 |
| spiv | Cool. | 09:58 |
| poolie | spiv i think you broke 'make doc-website' | 11:07 |
| poolie | shell cruftiness disliking parens in filenames | 11:07 |
| ddaa | or lack of proper shell quoting | 11:10 |
| poolie | yep | 11:13 |
| poolie | that's crufty | 11:13 |
| poolie | ddaa, do you remember off hand how to avoid that in a makefile? | 11:16 |
| poolie | if i just put "$@" does that do the right thing? | 11:16 |
| poolie | ie quote the words individually | 11:16 |
| vila | poolie: can't reproduce locally, what error are you seeing ? | 11:16 |
| poolie | me either | 11:16 |
| poolie | +/srv/doc.bazaar.canonical.com/bzr/bin/update-bzr-docs:36> dchroot -c karmic --directory /srv/doc.bazaar.canonical.com/bzr//bzr.dev make doc-website | 11:16 |
| poolie | I: [karmic chroot] Running command: "make doc-website" | 11:16 |
| poolie | python tools/generate_release_notes.py doc/en/release-notes/index.txt d...... | 11:16 |
| poolie | /bin/sh: Syntax error: "(" unexpected | 11:17 |
| poolie | it may be something about dash vs zsh | 11:17 |
| vila | poolie: I got one error at first run but re-running was enough until it fails in tex for some encoding issue | 11:17 |
| poolie | i did get a unicode error in latex but that's not so important | 11:17 |
| vila | ha karmic... karmic ? | 11:17 |
| vila | ha, so we got the same latex error at least | 11:17 |
| vila | why and where is karmic involved there oh, where the cron job is running ? | 11:18 |
| vila | I also got a bunch of conflicts in my trunk mirror where I use to run make *docs* thingies, could that be related ? | 11:19 |
| poolie | that's andrew's change, but it's not what's breakign escudero | 11:19 |
| poolie | i'm getting tired | 11:19 |
| vila | ok | 11:19 |
| vila | poolie: the web site itself is not broken so this could wait right ? | 11:20 |
| poolie | mm | 11:20 |
| poolie | i think the docs will just be stale until it's fixed | 11:21 |
| poolie | and it will keep sending me mail | 11:21 |
| vila | one by hour or by day ? | 11:21 |
| vila | poolie: anyway, this way we are sure this doesn't get forgotten :-p | 11:21 |
| poolie | a few a day | 11:22 |
| poolie | oh, and bialix will mail me after a couple of days :) | 11:22 |
| poolie | going by history | 11:22 |
| poolie | vila https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/38522 should fix it | 11:23 |
| poolie | i can't reproduce it either so it's kind of blind | 11:24 |
| vila | hmm, I wonder if it was due to some persistent sphinx data and as such, will never recir | 11:26 |
| vila | recur | 11:26 |
| poolie | i'm just looking | 11:27 |
| poolie | yep, that fixed it | 11:27 |
| poolie | i mean, cleaning the tree and reverting seem to have fixed it | 11:27 |
| spiv | poolie: odd! | 11:28 |
| poolie | stupid danilo finding unicode bugs :/ | 11:29 |
| vila | poolie: ok, your mp isn't needed right ? | 11:29 |
| poolie | if ascii was good enough for jesus... | 11:29 |
| vila | lol | 11:29 |
| poolie | not sure, i might like to land it anyhow | 11:29 |
| vila | except for deleting the release-notes part: approve | 11:30 |
| poolie | why not delete it? | 11:30 |
| poolie | it's included in 1.18 | 11:30 |
| vila | haaa, including the entry ? | 11:30 |
| vila | we were duplicatong in theses days ? ;) tsk tsk | 11:31 |
| poolie | no, i suspect andrew moved it to 1.18 when 1.17.1 didn't happen | 11:31 |
| vila | just kidding, if the entry exist somewhere that's all I care, remove this objection | 11:31 |
| spiv | poolie: presumably there was a filename with a ( in it for some strange reason? | 11:32 |
| mgz | is spiv's 27816 line diff getting reviewed? :) | 11:33 |
| poolie | because there was a release called '1.17.1 (unreleased0' | 11:33 |
| poolie | it looks messy in the ToC anyhow | 11:33 |
| vila | spiv: the privous generate-release-notes.py was creating it yes | 11:33 |
| poolie | it's not exactly likely to get released now :) | 11:33 |
| spiv | Oh, huh. The new build process won't do that :) | 11:33 |
| poolie | it was detritus in this tree | 11:33 |
| poolie | right | 11:33 |
| spiv | "$@" is good practice anyway | 11:33 |
| poolie | i don't know what caused it to break but a clean trunk has fixed it | 11:33 |
| spiv | And the unreleased release is pretty uninteresting, so +1 on your patch, but pretty unimportant now. | 11:34 |
| vila | mgz: alaready landed and spiv got the record | 11:34 |
| spiv | \o/ | 11:34 |
| vila | spiv: since you're there, can we land https://code.edge.launchpad.net/~spiv/bzr/hooks-refactoring/+merge/36101 or do you need something done there ? | 11:34 |
| spiv | Or if you are Unicode 6.0 enabled: 🙌 | 11:35 |
| vila | it seems I'm not Unicode 6.0 enabled :) | 11:35 |
| Glenjamin | what char is that? | 11:35 |
| mgz | I'm guessing one of the new two-people-holding-hands ones | 11:36 |
| spiv | vila: there's a docstring tweak to make, otherwise I think it's good to land. | 11:36 |
| spiv | mgz: U+1F64C is PERSON RAISING BOTH HANDS IN CELEBRATION | 11:36 |
| vila | spiv: in the pyutils module ? | 11:36 |
| poolie | \N{CHEERS} | 11:37 |
| spiv | Apparently new versions of the relevant Xorg module will add Compose, \, o, / as a binding for it... | 11:37 |
| poolie | mm | 11:37 |
| poolie | i wish there was some better discovery mechanism for compose sequences than googling for 'linux compose sequence' | 11:37 |
| vila | spiv: by the way, do you think python compatibility methods can be added there (like when we want to carry fixes that exist for 2.6 or 2.7 and use them for 2.4 or 2.5) ? | 11:38 |
| poolie | which last time i looked suggested you read the X11 source :) | 11:38 |
| Kinnison | poolie: I just tend to guess, and if that fails, run unicode in a terminal and c&p :-) | 11:38 |
| spiv | poolie: me too | 11:38 |
| * spiv applies some guess work | 11:38 | |
| spiv | poolie: /usr/share/X11/locale/en_US.UTF-8/Compose ? | 11:39 |
| poolie | gucharmap is ok | 11:39 |
| poolie | i'd like to press Compose-something then type "celebration" and have it find it... | 11:39 |
| spiv | poolie: Compose F1 ;) | 11:40 |
| spiv | poolie: that would be lovely | 11:40 |
| mgz | thanks for the testtools reviews lifeless! will just leave a couple of comments in the mps. | 11:41 |
| vila | spiv: by the way, do you think python compatibility methods can be added there (like when we want to carry fixes that exist for 2.6 or 2.7 and use them for 2.4 or 2.5) ? | 11:41 |
| spiv | vila: python compat methods are harder, because sometimes they use syntax that simply won't compile in earlier versions | 11:41 |
| spiv | vila: which suggests that we perhaps should have pycompat_27 or whatever for things backported from 2.7 | 11:42 |
| spiv | etc | 11:42 |
| vila | spiv: ha, sure, I was thinking about things like open_socket_as_you_should and... what was it... the addinfo_url stuff | 11:42 |
| spiv | Hmm, I don't think the addinfo_url thing is a good candidate for such a general module. | 11:43 |
| vila | ok, nm | 11:43 |
| spiv | You'd start forcing imports of that sort of stuff on every invocation unless you use some contortions. The cure would be worse than the disease. | 11:43 |
| poolie | \N{PERSON LEAVING COMPUTER} | 11:46 |
| mgz | ehehe | 11:46 |
| Glenjamin | i suppose in theory everything that requires compatibility needs to be abstracted behind at least 1 layer, and then that layer adds the compat if necessary | 11:48 |
| spiv | Glenjamin: or in some cases you can simply write the code in such a way that it works directly on all supported versions | 11:56 |
| spiv | Excellent, new hard drives installed and backups restored. | 12:33 |
| vila | grrr, pqm accepting submissions far too fast again and no feedback on what is failing again | 12:36 |
| vila | ping losa, something is weird in the bzr.dev pqm branch, submissions are accepted far too fast (as in: the tests don't run so some error is seen as success) | 12:40 |
| mgz | doesn't poolie's makefile change just need to land? | 12:41 |
| vila | my first suspicion will go to cruft in doc/en/release-notes leading to conflicts and some unexpected consequence that my crystal ball refuses to reveal | 12:41 |
| spiv | +1 mgz | 12:41 |
| spiv | Hmm | 12:42 |
| vila | mgz: why can't I reproduce locally then ? | 12:42 |
| spiv | Although, I think the checkout is constructed from scratch each time, so old detritus shouldn't be an issue. | 12:42 |
| spiv | But I "makefile changes land" swiftly followed by "weird landing issues" is a pretty suspicious combination. | 12:43 |
| spiv | It wouldn't hurt to throw poolie's change at PQM and see what happens, though. | 12:43 |
| vila | well, I don't know what damage has already occurred so I prefer quick losa check first | 12:44 |
| mgz | hm, vila, can I get some of your time today to help me with leak things? | 12:51 |
| vila | mgz: sure | 12:51 |
| mgz | the second babune run from last night shows I fixed the obvious things, but... | 12:52 |
| mgz | for some reason the actual leak prevention bit isn't working | 12:52 |
| mgz | http://babune.ladeuil.net:24842/job/selftest-subset-windows/11/ <- took nearly four hours to complete | 12:52 |
| mgz | when I was testing locally, every run has been fine, except one where *everything* hung. so there's something odd going on. | 12:53 |
| vila | mgz: let's retry just this one then, something weird happened this night too for the jaunty and karmic claves (took several hours each) | 12:54 |
| mgz | I'd blame babune too were it not for the fact one run I got it too. | 12:55 |
| vila | when ? | 12:55 |
| mgz | there was no obvious trigger, just testing a subset from the console, so there's still something non deterministic here | 12:55 |
| vila | I mean, when did you see that, yesterday ? | 12:56 |
| mgz | yup, last night, after I'd pushed up the last change | 12:56 |
| mgz | I frantically reverted stuff to try and work out what I'd broken... but never saw it again | 12:57 |
| mgz | I still sometimes get a leak, but I've not seen any other hangs, and it was *everything* hanging | 12:57 |
| vila | shudder | 12:57 |
| mgz | which is clearly what babune had to make it over three hours | 12:59 |
| mgz | http://babune.ladeuil.net:24842/job/selftest-subset-windows/11/testReport/bzrlib.tests.per_branch.test_branch/TestReferenceLocation/ <- see multiple tests taking 5 seconds. | 12:59 |
| mgz | the hack branch didn't get that... might just be bad luck, or might be something borked | 12:59 |
| vila | one possible cause could be the hook is not taken into account because all hooks are cleared for test isolation but I don't believe it | 13:03 |
| mgz | right, manually checked that for the first rev and the hook clearing happens before the hook is added. | 13:05 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-windows/11/consoleFull | 13:06 |
| mgz | but it does feel like the hook was ripped out entirely for that one run. | 13:06 |
| vila | hangs all over the place indeed | 13:06 |
| vila | right, the current run also has hangs, I'll kill it | 13:10 |
| mgz | ValueError: line 6 of the doctest for bzrlib.pyutils.calc_parent_name has an invalid option: '+SKIP' | 13:11 |
| mgz | bah, hadn't seen that before | 13:11 |
| mgz | will want fixing on trunk. | 13:11 |
| mgz | (presume it's using some 2.6/2.7 only doctest feature) | 13:12 |
| vila | where do you get that ? | 13:12 |
| mgz | it's from spiv's hook refactoring branch that I'm building on. | 13:13 |
| spiv | mgz: oh :( | 13:14 |
| vila | which has landed | 13:14 |
| mgz | okay, -s bt and I can get hangs, I'll see if that happens again, then maybe I can debug this | 13:14 |
| spiv | mgz: the docs don't say it is new :( | 13:14 |
| spiv | Ah, they do, but not at the description of SKIP | 13:15 |
| spiv | further down they say: Changed in version 2.5: Constant SKIP was added. | 13:15 |
| spiv | It's probably reasonable to just not doctest this module, but poolie may disagree. | 13:15 |
| mgz | that might be what broke pqm | 13:15 |
| mgz | as doctests are weird and get compiled before most other things happen | 13:15 |
| mgz | can't avoid 'em with -s for instance | 13:16 |
| spiv | (I only added ths module to the list of doctested modules at poolie's request during review) | 13:16 |
| vila | indeed, pqm use python2.4 but we are supposed to catch such errors :-/ | 13:17 |
| spiv | mgz: hmm, seems improbable: if it would break pqm, then it wouldn't have landed. | 13:17 |
| vila | spiv: it *has* landed | 13:17 |
| mgz | it breaks the test suite at an odd place, you don't get failures, just a traceback internal error. | 13:17 |
| spiv | vila: sure | 13:17 |
| mgz | but yeah, I thought we were now checking the return code properly | 13:18 |
| spiv | vila: which therefore suggests it doesn't break pqm | 13:18 |
| vila | I can reproduce locally with py24 | 13:18 |
| vila | well, locally, on hardy | 13:18 |
| spiv | (and regardless the other possiblity is it had failed to land, in which case of course pqm is not broken because it didn't land) | 13:18 |
| spiv | (so my argument is independent of the specific outcome...) | 13:19 |
| spiv | Anyway, bedtime for me. | 13:19 |
| spiv | Good luck figuring out what's broken :/ | 13:19 |
| spiv | So far all the candidates have been my branches... | 13:19 |
| vila | nah, 2 for you 2 for me | 13:20 |
| vila | shudder no subunit installed for py24 on hardy ... grrrr | 13:20 |
| vila | hmpf, reproduced | 13:22 |
| mgz | night spiv. | 13:22 |
| vila | the error is output in selftest.log which means we have *some* output and as such we happily consider the tests as passing | 13:22 |
| vila | so that's the bug that 'broke' pqm | 13:23 |
| mgz | ...I was sure we checked the return code now | 13:23 |
| mgz | after last time the suite broke before being run | 13:23 |
| vila | see the Makefile for the actual check, I'll dig the mp to refresh my memory about details and alternate implementations that were discussed | 13:24 |
| mgz | I remember various shell weirdness. | 13:25 |
| mgz | At least cmd consistently sucks! | 13:26 |
| vila | basically the idea was that bzr failures where supposed to leave stdout empty leading to an empty selftest.log and we used that to catch errors | 13:26 |
| vila | and then subunit-stats is supposed to fail it it sees a failure in this non-empty selftest.log | 13:27 |
| mgz | I see. | 13:28 |
| vila | but in this case, the doctest outputs something which subunit-stats doesn't interpret and we're doomed | 13:28 |
| spiv | vila: I'm surprised | 13:28 |
| spiv | vila: (not disagreeing, just surprised) | 13:28 |
| spiv | But, also, I'm really going to bed now :) | 13:28 |
| vila | spiv: sleep well | 13:29 |
| * vila crosses fingers hoping that no failure will appear caused by one the unchecked submissions | 13:48 | |
| vila | at least tests are running again, unping losa | 13:59 |
| zpletan | I am trying to "bzr branch lp:gimp", which is >300MB (don't really know exactly how big). I have a rather slow internet connection, which died 320MB into bzr's downloading. Is there a way I can have bzr pick up where it left off, rather than re-downloading the first 320MB which takes around two hours? | 14:02 |
| vila | zpletan: what did you get locally in the end ? | 14:03 |
| vila | zpletan: i.e. `ls -lR .bzr/` and pastebin the output | 14:03 |
| vila | !paste | 14:03 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 14:03 |
| vila | mgz: any progress ? | 14:04 |
| mgz | yeah, got some tests that reliably hang, have hook installed | 14:04 |
| vila | doh | 14:04 |
| zpletan | vila: http://paste.ubuntu.com/513847/ | 14:04 |
| mgz | so, the hook is currently covering less than the hack was, just need to work out where | 14:04 |
| mgz | possibly smart server things, investigating. | 14:05 |
| vila | zpletan: unlucky :-/ | 14:05 |
| zpletan | Bummer. Thanks anyway! | 14:06 |
| vila | the file feufc824zjpib16c8n3m.pack is probably borked | 14:06 |
| vila | zpletan: wait ! There are different workarounds | 14:06 |
| zpletan | vila: still here - go ahead | 14:06 |
| vila | zpletan: the easiest one is to pull in chunks: | 14:06 |
| vila | bzr init gimp ; cd gimp ; bzr pull -r100 lp:gimp | 14:07 |
| vila | then | 14:07 |
| vila | bzr pull -r200 ; bzr pull -r 300 | 14:07 |
| mgz | suspicious looking: | 14:07 |
| mgz | # FIXME: No test are exercising the hooks for the test server | 14:07 |
| mgz | # -- vila 20100618 | 14:07 |
| mgz | self.run_server_started_hooks() | 14:07 |
| vila | depending on your internet connection you can try bigger increments | 14:07 |
| mgz | where's that defined? | 14:08 |
| zpletan | vila: thanks - I'll try that | 14:08 |
| vila | mgz: irrelevant, that;s the smart server specific hooks | 14:08 |
| mgz | you didn't do any dodgy voodoo in the method? | 14:08 |
| vila | zpletan: also, file a bug asking for resumable pull, search for a duplicate this has been asked before | 14:09 |
| zpletan | will do - thanks | 14:09 |
| vila | mgz: when you say the hook is there, have you checked it is called and if yes, when ? | 14:10 |
| mgz | it's not called. | 14:10 |
| mgz | just using -Ethreads now to narrow things down. | 14:10 |
| vila | not called at all or called too late ? | 14:11 |
| mgz | at all, for the test I'm running. | 14:11 |
| vila | and is it present with the right content / | 14:11 |
| mgz | sec, I'll paste you my output | 14:11 |
| mgz | I don't like that I'm getting the same thread id multiple times in the hang output at the end either | 14:12 |
| vila | s/def _add_disconnect_cleanup(transport)/def _add_disconnect_cleanup(self, transport)/ ? | 14:12 |
| vila | nah, nm | 14:13 |
| mgz | it gets called for other tests. | 14:13 |
| mgz | http://paste.ubuntu.com/513854/ | 14:14 |
| mgz | http://paste.ubuntu.com/513855/ <- the old hack branch | 14:14 |
| vila | will be joined before started... | 14:15 |
| vila | isn't that lovely | 14:16 |
| === Ursinha is now known as Ursinha-afk | ||
| vila | right, so, I'd add some prints for each hook call and each get_transport call | 14:18 |
| mgz | http://paste.ubuntu.com/513856/ <- hook does work for some tests | 14:18 |
| === Ursinha-afk is now known as Ursinha | ||
| mgz | but clearly not all of 'em... | 14:19 |
| vila | some transports are used internally during setup, I fail to see why they can escape the hook nor why they could lead to hand...except if they are the ones hanging the *server* may be | 14:19 |
| mgz | that was my thought. | 14:19 |
| vila | ha, got a theory | 14:20 |
| vila | the hook fires later so the disconnect happens... sooner ? meh, doesn't fly :) | 14:20 |
| vila | ha, no, the disconnect happen at different times, so *new* causes lead to hangs | 14:21 |
| vila | hmm, still no godd | 14:21 |
| mgz | I'll add some printing to my old hack so we can see where that's called in the test. | 14:22 |
| vila | first, let's make sure no transport escape the hook, then we can think about why disconnect fails to address the hangs | 14:22 |
| vila | right, got it | 14:23 |
| mgz | ...it is the server. | 14:24 |
| mgz | despite the fact it's client threads leaking. | 14:24 |
| vila | I think the server cleanup and the transport cleanup are not registered in the same order as with the hack | 14:24 |
| mgz | well, the server gets registered with the hack, but the hook never fires | 14:24 |
| vila | right, because we are shutting down the server before trying to disconnect | 14:25 |
| vila | which is weird | 14:25 |
| mgz | http://paste.ubuntu.com/513866/ <- with the hack, disconnect gets queued | 14:26 |
| mgz | http://paste.ubuntu.com/513854/ <- there's no "hook" line printed here at all. | 14:26 |
| mgz | so disconnect will never be called. | 14:26 |
| vila | but did the transport connected ? | 14:28 |
| mgz | presumably, the test passes. I've not traced through yet to work out why the hook doesn't fire. | 14:29 |
| vila | mgz: 'Client thread' may be misleading here, all threads are for the server, one for the listen, the others for the accept | 14:30 |
| vila | yeah, one print for get_transport, one print for set_connection (or transport.connect), one print in the hook | 14:31 |
| mgz | seems RemoteTransport doesn't call _set_transport | 14:35 |
| mgz | *_set_connection | 14:36 |
| vila | because it delegates to the... what's the attribute name | 14:36 |
| mgz | _shared_connection ? | 14:38 |
| vila | RemoteHTTPTransport delegates to _http_transport, should be fine | 14:39 |
| vila | RemoteSSHTransport... is unclear, which kind is involved for you ? | 14:40 |
| mgz | RemoteTCPTransport | 14:41 |
| vila | ha | 14:41 |
| mgz | so, we want to do something with the _build_medium methods? | 14:41 |
| mgz | trying to work out the prettiest way to sort this out with the various transport classes doing rather different things | 14:43 |
| vila | mgz: right, you've put your finger in the hole between remote transport and all the others: _set_connection is not used | 14:44 |
| vila | so, from memory, spiv said the medium is the connection so _set_connection wasn't making sense or something | 14:44 |
| vila | this may mean you need to call the hook in a different place | 14:45 |
| vila | an additional different place | 14:45 |
| vila | wll, it's that or force the _set_connection call even with no credentials | 14:46 |
| vila | see comment in remote.py:136 The medium is analogous to the connection for ConnectedTransport: it | 14:46 |
| vila | allows connection sharing. | 14:46 |
| vila | ha, I forgot those ones, see also get_smart_client() and get_smart_medium() | 14:47 |
| vila | I'm pretty sure we can deprecate get_smart_client though, will need to check with spiv | 14:48 |
| mgz | scattering the hook around more places does make the tests happy again | 14:49 |
| vila | how many more ? | 14:50 |
| mgz | well, currently inside some _build_medium methods, I've done a full test run to see if that covers everything the get_transport hack did, but it looks good so far | 14:51 |
| vila | so, I'm not sure _build_medium is called on reconnects | 14:54 |
| mgz | alternatively inside the `if medium is None` block in RemoteTransport.__init__ but not sure that's the right interaction either | 14:54 |
| vila | but I'm not sure either that the remore transports handle reconnects :) | 14:54 |
| mgz | ...I think I'll push that, it seems right-ish for TCP and HTTP (which overrides __init__) so it's probably worth a run | 14:56 |
| vila | mgz: so a better place would be in smart/medium.py but do we have access to the transport hooks there... | 14:56 |
| mgz | not as a transport hook, no. | 14:57 |
| vila | at least that's where disconnect() and _ensure_connection() are defined | 14:57 |
| mgz | the medium gets passed the details from the transport instance, but not the instance itself | 14:58 |
| mgz | okay vila, I've pushed that. can I have another babune windows run to check that was the only missing element. | 15:01 |
| mgz | we can discuss in the mp if we want a different hook approach, per transport rather than per connection/medium does have some downsides. | 15:02 |
| vila | the one we need here is clearly per connection | 15:02 |
| vila | it may make sense to have one for the transports and one for the remote transport | 15:03 |
| vila | if only to avoid to fire twice for RemoteHttpTransport | 15:03 |
| vila | ideally the should be one Connection object that can be inherited for this and some other attributes | 15:04 |
| vila | s/the/there/ | 15:04 |
| mgz | as pushed, RemoteHTTPTransport correctly only fires once (the hook is in parent __init__ which is upcalled on a path that doesn't re-fire) | 15:05 |
| mgz | ...wait, I thought, but maybe not. | 15:06 |
| mgz | it has _http_transport *and* _from_transport, confusing. | 15:06 |
| vila | which means it doesn't get called when the underlying http transport reconnect ? | 15:06 |
| vila | _from_transport is for cloning | 15:07 |
| mgz | I was trying to just leave the unlying http transport to hook on _set_connection, and not re-call | 15:07 |
| vila | transports connects only when needed, you can have multiple clones before the first connection occurs | 15:07 |
| mgz | but haven't quite done it right. | 15:07 |
| mgz | unlying = underlying, clearly. | 15:08 |
| vila | yup | 15:08 |
| vila | transport != connection is clearly the issue here | 15:08 |
| mgz | not undying. it's not a zombie transport. | 15:08 |
| vila | I read it as underlying | 15:08 |
| mgz | or untrying. a lazy transport. | 15:09 |
| vila | ehehe | 15:09 |
| mgz | I'll write some of this up in the mp after I've had some lunch. That, and respond to jam and lifeless in other mps... so much fun, so little time. | 15:11 |
| vila | mgz: right, I'll look there | 15:12 |
| jam | vila: I thought I'd point you to bug #389674, there is a bugfix patch that seems about correct, but will need some lovin to land. I don't know whether the contributor is able to finish off the work, though I only just asked | 15:31 |
| ubot5 | Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory (affected: 4, heat: 20)" [Medium,Confirmed] https://launchpad.net/bugs/389674 | 15:31 |
| vila | jam: I wouldn't dare take credit for a patch you wrote :-P | 15:34 |
| jam | well, I'm not immediately planning on playing with it, seemed a PP thing to do. But looks like it can wait for now | 15:35 |
| vila | jam: I've subscribed to the bug so it wont fall off my radar, but I'd like to finish my buf 323111 review tweaks and I have to leave early today (as in less than an hour) | 15:36 |
| jam | vila: np, it certainly is the end of the week anyway, just something that caught my eye | 15:37 |
| vila | ubot5: when I mistype buf you're supposed to understand I meant bug | 15:37 |
| ubot5 | Error: I am only a bot, please don't think I'm intelligent :) | 15:37 |
| vila | jam: the weird thing is that I seem to recall seeing a mail from you not so long ago with the same kind of patch... | 15:38 |
| vila | ha, maybe the patch was inlined in the mail | 15:38 |
| jam | I just hacked something quickly and pasted it into the bug report | 15:40 |
| mgz | http://babune.ladeuil.net:24842/job/selftest-subset-windows/13/ <- worked, 41 mins. so, just need to work out how best to hook and will be sorted. | 15:47 |
| vila | mgz: whereas the karmic run seem to be hanging making me wonder if finally the same bug is not revealing itself on Ubuntu too... | 15:50 |
| vila | nah, autofs4 playing tricks... again :-/ | 15:51 |
| vila | I should really stop mounting file systems in slaves no matter how convenient it seems to be at first | 15:52 |
| === deryck is now known as deryck[lunch] | ||
| mgz | jam: I've updated lp:~gz/bzr/require_unicode_committer_614593 per your review, if you could just double check the change is sane | 17:42 |
| jam | mgz: do you have a quick link? | 17:42 |
| mgz | https://code.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334 | 17:43 |
| jam | mgz: looks good to me | 17:43 |
| vila | mgz: feeling lonely in the review queue ? | 17:44 |
| mgz | you're still there with me! | 17:44 |
| mgz | ack, no, you've just been merged. | 17:45 |
| mgz | darn... | 17:45 |
| vila | mgz: hehehe | 17:46 |
| vila | is your transport hook mp up-to-date ? A single additional call is enough ? | 17:46 |
| mgz | I've just worked off the rest of my debt and am about to write up the earlier chat in the mp. | 17:47 |
| mgz | The mp works for stopping leaks currently, but the hook still needs work to be generally useful I think. | 17:48 |
| mgz | s/mp/branch/ | 17:48 |
| vila | mgz: that could be a followon submission, stopping leaks properly is significant enough to land asap (needs a NEWS entry, err, release-notes :) | 17:49 |
| mgz | yeah, see my cunning plan in not writing NEWS there? | 17:49 |
| mgz | one fewer merge-from-trunk needed. | 17:49 |
| vila | yeah, add some kind of epic fail myself regarding doc, so don't expect me to look elsewhere :) | 17:50 |
| mgz | oh, one other thing from that mp. | 17:50 |
| mgz | you say in the first comment "Don't forget the hooks-help.txt file." | 17:51 |
| vila | if you haven't done it yet, I *urge* you to merge from trunk, there is HUGE probability that pqm will fail with conflicts otherwise | 17:51 |
| mgz | where is this, and what needs not forgetting about it? | 17:51 |
| mgz | ^I will still need one nightmare merge from trunk, clearly | 17:51 |
| mgz | with luck it won't even be than bad a dream. | 17:52 |
| vila | mgz: cleanup your doc/en/release-notes dir first if you ever generate the doc | 17:52 |
| vila | doc/en/user-reference/hooks-help.txt | 17:53 |
| vila | all hooks are documented there AFAIK | 17:53 |
| mgz | ...is auto generated? | 17:53 |
| mgz | I don't have such a file in a clean tree. | 17:54 |
| vila | could be :) | 17:54 |
| mgz | good good, one less thing to worry about. | 17:54 |
| vila | meh, I have both a hooks.txt and a hooks-help.txt... what a mess | 17:55 |
| vila | ok, bzr ls -V | grep hook gives an empty output, so definitely generated from the docstring :) | 17:57 |
| vila | right, so calling from RemoteTransport.__init__ is probably wrong as no connection has occurred yet... Moreover there is a FIXME about medium being a private parameter for tests only | 18:00 |
| vila | :-/ | 18:00 |
| vila | mgz: I don't know what to say... my feeling is that we should just file a bug asking for some sort of re-design as this is getting out of scope for the fix you had in mind which is good-enough here since I'm pretty sure a medium never re-connect | 18:03 |
| vila | mgz: I'd approve your actual proposal with a FIXME above the remote hook call explaining that it's called once per connection but *before* the connection occurs and mentioning the lack of _set_connection call (which *becomes* an issue now) | 18:06 |
| vila | mgz: unless you have a better idea to differ the hook call in medium._ensure_connection | 18:07 |
| mgz | sure but a hook is a public thing so we don't want to land anything too screwy. it's the weekend now, so can leave deciding anything for now | 18:07 |
| mgz | but can probably come up with something a little cleverer than the current that still works for leak squashing. | 18:07 |
| vila | one solution would be to have another hook for transport *creation* and have the post_connect covers the reconnect case and make the tests set both | 18:09 |
| vila | since disconnect() can be called multiple times, that should work | 18:09 |
| vila | but there will still be a bug in the post_connect hook if it can't be implement for smart transports | 18:10 |
| mgz | hm, looking at the commit builder code, I'm having third thoughts about the require_unicode_committer change too | 18:13 |
| mgz | there's no point doing a per_repo test for something we're throwing on in __init__ I bet. | 18:15 |
| mgz | and there's a _validate_unicode_text method I could have used but... it doesn't actually... do that | 18:15 |
| mgz | so rev props, message, and all the other text is probably also vulnerable | 18:15 |
| mgz | ...I'll get my lonely mps done in the end! | 18:16 |
| vila | yeah, if a losa can upgrade testtools on pqm we may even empty the queue ! Two records in the same week !! The biggest diff and the smaller queue !!!!!1111!! | 18:17 |
| vila | at that point, I think I should stop working and start drinking for good :) | 18:17 |
| mgz | right. :) | 18:18 |
| vila | mgz: you haven't feed-pqm'd https://code.edge.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334, want me to do it ? | 18:32 |
| mgz | no, see my rethink just ^ up there about whether it's exactly right. | 18:35 |
| vila | mgz: land this one and make a new one then or at least land the minimum before working on the next, less job for the reviewer and for you | 18:36 |
| vila | s/job/work/ | 18:36 |
| vila | bah, the two can be said with the same word in french ;) | 18:37 |
| mgz | at the least I think I should probably move the test from bt.per_repository.test_commit_builder to somewhere like bt.test_repository.TestCommitBuilder as the test never gets as far as building a real repo now | 18:37 |
| mgz | making the other params more robust against bad input should probably be another mp though. | 18:37 |
| vila | yup | 18:37 |
| vila | and you may encounter other problems, so better land the bug fix and file other bugs | 18:38 |
| vila | this can also help people if they encounter a slightly different bug and don't consider the one you have fixed | 18:39 |
| vila | ok, I'm off, have a nice evening, week-end all ! | 18:39 |
| mgz | hm, maybe the test is okay where it is, there are multiple commit builder classes, just seems wasteful. | 18:40 |
| mgz | bye vila! | 18:40 |
| === deryck[lunch] is now known as deryck | ||
| txdv_ | fucking shit, why does bzr log the nick of the branch | 19:39 |
| txdv_ | is there any way to change it? | 19:39 |
| txdv_ | i want to change the branch nick in the last 5 commits | 19:40 |
| LeoNerd | It's recorded in the revision metadata. So, no. | 19:40 |
| txdv_ | that fucking sucks | 19:40 |
| txdv_ | why should someone use bzr at all it can't even handle stuff like that | 19:41 |
| LeoNerd | You could rewrite it somehow, but then that's done by creating new revisions, so you'll break anyone else who's seen it up to that point... | 19:41 |
| txdv_ | nobody has seen it | 19:41 |
| LeoNerd | Well.. what you're describing is called Rewriting History. | 19:41 |
| LeoNerd | Ah, well.. then rewrite it then :) | 19:41 |
| txdv_ | and how do i do it? :/ | 19:41 |
| LeoNerd | Offhand, I'm not sure. Perhaps someone else in here knows. Likely some variant on bzr rewrite | 19:42 |
| txdv_ | i was so fucking pissed of my assignment that i named the branch penis | 19:42 |
| txdv_ | ;( | 19:43 |
| LeoNerd | Heh.. Yes.. it is a little nonobvious that the directory's basename gets recorded... | 19:43 |
| txdv_ | i like the concept of branches in git better | 19:43 |
| txdv_ | a branch in bzr is the directory name | 19:43 |
| txdv_ | ... | 19:44 |
| LeoNerd | Well.. bzr tries to be fairly minimal in this regard. People already understand directories on disks... so we'll just store one branch per dir. People already know how that works. | 19:44 |
| LeoNerd | Trying to put multiple independent branches in one directory just adds complexity to the model for no real benefit. | 19:45 |
| txdv_ | checking out a branch in git is faster | 19:45 |
| txdv_ | branching is faster | 19:45 |
| txdv_ | especially if they differ just by a small n of commits | 19:46 |
| LeoNerd | Hrm? | 19:46 |
| LeoNerd | bzr can share commit information just fine... | 19:46 |
| LeoNerd | I do that all the time. :) | 19:46 |
| LeoNerd | I have the actual commits stored in /var/bzr/leo/ itself, and all the individual branches live at e.g. /var/bzr/leo/perl/Foo-Bar.CRAZYFEATURE | 19:47 |
| LeoNerd | Creating a branch just creates the initial container and says "OK this is a branch of that revision".. small constant data; the actual revisions are stored in the repo | 19:48 |
| txdv_ | now rebase is not even at the pc at my work | 19:55 |
| txdv_ | in other words it's not even in the default package | 19:55 |
| txdv_ | im in a world of pain | 19:57 |
| LeoNerd | If you can't install it on that machine, you could run it someplace you can install, and push it across... | 19:58 |
| LeoNerd | E.g. a home machine or whatever.. | 19:58 |
| txdv_ | i bad to copy 200mb | 20:02 |
| txdv_ | that's not the problem | 20:02 |
| txdv_ | renaming those branches is | 20:02 |
| txdv_ | rebase doesnt work | 20:03 |
| AfC | huh? | 20:03 |
| txdv_ | im using it wrong | 20:03 |
| AfC | $ mv before after | 20:03 |
| AfC | Branch renamed. | 20:03 |
| txdv_ | and what about the history | 20:04 |
| txdv_ | i already made 5 commits and i want to rename the BRANCH NAME in the HISTORY | 20:04 |
| AfC | oh, that's fixed | 20:04 |
| AfC | {shrug} | 20:04 |
| AfC | most of us have learned to ignore that | 20:04 |
| txdv_ | a collective mind of bzr users? | 20:05 |
| txdv_ | or what do you refer to with 'most of us'? xD | 20:05 |
| AfC | most of us who long ago decided that "feature", as implemented, was completely useless, and so learned to ignore it on the rare occasions we do `bzr log --format=long` | 20:06 |
| AfC | (this one is in the same general category as wanting to be able to "fix" commit messages after the fact. The idea is to make a change, but record somewhere in the meta data that such a change was made [ie layered on top]. | 20:07 |
| AfC | This seems agreed as the right thing to do, but for reasons I can't quite make sense of, it hasn't been done yet. | 20:08 |
| AfC | I suspect the real reason is that the core developers of Bazaar a) write pithy thin commit messages they don't care about fixing, and b) likewise ignore the "branch nick" field. | 20:08 |
| AfC | So, {shrug} fair enough, it hasn't been acted on by anyone as yet) | 20:09 |
| txdv_ | ill just stick to the branch name penis then | 20:10 |
| txdv_ | and push it at my work | 20:11 |
| AfC | Well, if you used that, then it's your own damn fault I should think | 20:11 |
| txdv_ | yeah | 20:11 |
| txdv_ | obviously a feature missing | 20:11 |
| txdv_ | it's my god damn fault | 20:11 |
| txdv_ | it surely is, i started using bzr | 20:12 |
| AfC | Or, as you've already mentioned, use the rebase plugin. | 20:12 |
| AfC | {shrug} | 20:12 |
| AfC | you have options. | 20:12 |
| LeoNerd | To be honest, I'd say it's a mistake to store that branch nick in the first place. It adds nothing to meaning, and isn't really interesting... | 20:12 |
| LeoNerd | I know of no interesting use to try to read it. | 20:12 |
| AfC | LeoNerd: yeah, it's a bit of a professionalism failure there, I'd say | 20:12 |
| LeoNerd | Anyway. Lunchtime. | 20:12 |
| txdv_ | omg bzr is starting to piss me off massively | 20:40 |
| txdv_ | change is in the log of the last revision, diff doesn't show any changes, though the change is not in the working directory | 20:40 |
| AfC | txdv_: $ bzr diff -r -1.. | 20:49 |
| jam | txdv_: I would have said "bzr diff -r -2..-1" but I'm not sure what you are trying to look at | 20:50 |
| txdv_ | i guess a bzr update did it | 20:52 |
| AfC | jam: of course (just realized what I'd typed, thanks) | 20:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!