| spiv | Good morning. | 00:03 |
|---|---|---|
| yann2 | is there a good reason why I wouldnt want to have +w for group on .bzr/checkout/dirstate ? | 00:24 |
| yann2 | I got problems by pushing because that file belongs to another user, although the group is set correctly, the user seems to need to write there | 00:25 |
| spiv | yann2: Odd, I wouldn't have thought that push would need to write to that file at all. | 00:29 |
| yann2 | it might be the update I just added before actually :) | 00:30 |
| spiv | yann2: the reason not to set group +w for that is if you don't want to allow other users in that group to tell bzr that files have been added or deleted, or that merges have been made... | 00:30 |
| spiv | (Or that renames have happened, or conflicts resolved, etc, i.e. changes to the state of the checkout) | 00:31 |
| spiv | Yeah, the update would make sense :) | 00:31 |
| yann2 | well users in the group can basically remove the .bzr folder :) | 00:31 |
| yann2 | I think the problem is that I do an automated update before doing a push... mmmmh, I ll look into that, thanks... | 00:32 |
| RenatoSilva | how to diff between branches? | 02:32 |
| spiv | D'oh, missed RenaotSilva | 02:37 |
| * jelmer waves to spiv | 02:38 | |
| spiv | For the record: "bzr help diff" | 02:38 |
| spiv | Hi jelmer | 02:38 |
| spiv | Any progress on the bzr-svn/chk issue? | 02:38 |
| jelmer | spiv: No, I need to follow up on your email but I haven't had the time to do so yet (travelling at the moment). | 02:39 |
| spiv | I was CC'd on part of a thread, but don't know if I'm missing any discussion, and probably the discussion ought to happen on (or at least summarised on) the bug... | 02:39 |
| spiv | Ah, ok. | 02:39 |
| spiv | To UDS, I guess? | 02:39 |
| jelmer | spiv: No, although I am in the US. Google Summer of Code mentor summit and GitTogether | 02:40 |
| spiv | Oh, heh. | 02:40 |
| spiv | So near and yet so far! | 02:40 |
| spiv | (not that I'm at UDS this time either) | 02:40 |
| jelmer | spiv: Are you going to the epic? | 02:42 |
| spiv | I am | 02:46 |
| jelmer | Cool | 02:48 |
| === spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | 2.3b2 is officially released, test it! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | hi all ! | 07:50 |
| GaryvdM | Hi vila | 07:51 |
| vila | _o/ | 07:52 |
| === beaumonta is now known as abeaumont_ | ||
| mgz | I see jml has blizted a bunch of testtools things | 15:10 |
| mgz | wonder if he'd prefer follow up bugs for continuing issues or reopening the current ones | 15:10 |
| lifeless | mgz: new bugs | 15:11 |
| mgz | will do, just found a mp for one of them and added a comment too. | 15:14 |
| mgz | I guess I could subscribe to testtools somehow. | 15:14 |
| mgz | ...might just put up some branches for these test failures, some of them are shallow. | 15:23 |
| mgz | hm, Python doesn't expose raise. I guess kill covers it anyway. | 15:34 |
| === Meths_ is now known as Meths | ||
| === mtaylor is now known as 52AACIHR4 | ||
| === tchan1 is now known as tchan | ||
| === deryck_ is now known as deryck | ||
| RenatoSilva | bzr qlog shows "Failed to decode using utf8, falling back to latin1", why? | 17:11 |
| RenatoSilva | isn't bzr aware of the encoding of the file? | 17:12 |
| abentley | RenatoSilva: bzr does not store any information about file encoding. | 17:13 |
| abentley | RenatoSilva: Individual commands can guess the current file encoding, if they choose. | 17:13 |
| === mordred_ is now known as mtaylor | ||
| RenatoSilva | if they choose? a command needing to print file content ought to do that, doesnt it? | 17:14 |
| RenatoSilva | what's funny is that file is latin1 and diff in bzr qlog shows file as utf8 (drop down in bottom) but the chars are ok | 17:15 |
| abentley | RenatoSilva: No, generally just emitting the bytes to the console works quite well. | 17:16 |
| abentley | RenatoSilva: And for binaries, it's generally the only thing that can be done. | 17:16 |
| RenatoSilva | hmm this is a bug, it tries to decode from utf8 and something defaults to latin1 (msg above), but the drop down is not updated | 17:16 |
| === Meths_ is now known as Meths | ||
| RenatoSilva | by emiting the bytes to console you mean relying on python's guessing right | 17:17 |
| abentley | RenatoSilva: Actually, it means relying on the console to have an encoding that is compatible with the files' encoding. | 17:19 |
| RenatoSilva | where console is the python's stdout object | 17:19 |
| abentley | RenatoSilva: The console is written to via python's stdout object, but it is not, itself, anything to do with python. | 17:20 |
| RenatoSilva | by console you mean the terminal? | 17:20 |
| abentley | RenatoSilva: yes, it is usually a terminal. | 17:21 |
| === oubiwann-away is now known as oubiwann | ||
| radix | hey guys | 17:46 |
| radix | is there an easy idiomatic solution to "the g+w problem" yet? | 17:47 |
| radix | i.e., when I bzr push with bzr+ssh to a repo on a shared server, I want it to be group writeable | 17:47 |
| radix | do I still have to use a debian "alternative" and a wrapper script? :( | 17:47 |
| mwhudson | radix: i'm not aware of any new stuff in that area | 17:54 |
| radix | ok | 17:55 |
| radix | it'd be really nice if bzr serve had an option for that :) | 17:57 |
| === Ursinha is now known as Ursinha-lunch | ||
| gthorslund | hi! is there a way in bzrlib to just check status for uncommitted changes. what I've found is http://people.canonical.com/~mwh/bzrlibapi/bzrlib.status.html#show_tree_status . so I guess it would be possible to put something on top of this, but is there a better way? | 18:30 |
| === beuno is now known as beuno-lunch | ||
| arthur_ | Hi. I have got two separate repo 'a' and 'b'. On 'b' a 'bzr pull' from 'a' was performed at some point, long ago. Now I want to consolidate 'a' and 'b' using 'bzr join' under the same repo and it fails since there are duplicates in the inventory. Any help to work around this problem would be appreciated. | 18:47 |
| gthorslund | arthur_: can't you just pull all from 'a' into 'b'? | 18:49 |
| maxb | arthur_: Could you explain a little more about the kind of history these repositories contain? It seems very odd that you would want to 'bzr join' repositories which already share ancestry. Why is 'bzr merge' not the right tool at this point? | 18:49 |
| arthur_ | alright. maybe I should rewind a little and listen to your suggestions. Here is the situation. | 18:50 |
| arthur_ | I just joined a company where they currently have ~20 repositories for various services. | 18:50 |
| arthur_ | We want to consolidate into a single repo. | 18:51 |
| arthur_ | while keeping the history. How should I proceed? | 18:51 |
| dash | well, repos don't contain history so much as revisions :) | 18:51 |
| === Ursinha-lunch is now known as Ursinha | ||
| arthur_ | dash: well. you got my point | 18:52 |
| maxb | arthur_: I think you should not proceed. It is natural and expected for various separate services to live in different repositories | 18:53 |
| arthur_ | maxb: there are much more tied than you think. Think of them as interfaces and implementations rather than services. | 18:54 |
| maxb | So it truly makes sense for every developer who works on any of them, to work in a tree containing all of them, and to _always_ branch and tag them as a combined tree? | 18:54 |
| arthur_ | maxb: most changes are across 3-5 services... so with the current layout it is pretty complex. | 18:55 |
| maxb | And the problem is that in the past, some services started as branches of other services? | 18:56 |
| arthur_ | maxb: that's right. one of them... | 18:56 |
| maxb | hmm. This isn't going to be very nice :-/ | 18:56 |
| arthur_ | which prevents me from doing a join. Believe me I was pissed when the very last join failed :) | 18:57 |
| maxb | I cannot think of any workaround which will preserve the ability to follow all files history back to where it naturally began | 18:57 |
| maxb | The only workaround I can think of is to effectingly delete and re-add the entire contents of one of the trees with duplicate file-ids | 18:57 |
| arthur_ | maybe I should do that on only the set of files that were common at the time | 18:58 |
| arthur_ | the pull was done pretty early (revno 6) | 18:58 |
| lifeless | gthorslund: yes, you can layer things on top of that api | 19:07 |
| lifeless | gthorslund: or the status command object | 19:07 |
| lifeless | and there is now a hook for that too | 19:07 |
| === beuno-lunch is now known as beuno | ||
| === Meths_ is now known as Meths | ||
| gthorslund | lifeless: since cmd_status is using show_tree_status that feels like a higher level then I need. looking at show_tree_status it appears to be nothing lower level that would be useful for me, so I guess show_tree_status would be right for me then. | 19:16 |
| lifeless | gthorslund: depends on what you're trying to do, I guess | 19:19 |
| gthorslund | lifeless: I'm looking at changing revert calls in bzr-bisect with update calls instead. if there have been local changes done I kind of end up with a mess of .moved files and other. (revert just removes local changes). I refuse starting without those changes being handled some way first. | 19:27 |
| gthorslund | hi mtaylor! | 19:27 |
| lifeless | gthorslund: iter_changes is probably what you want, then. | 19:27 |
| gthorslund | lifeless: so http://people.canonical.com/~mwh/bzrlibapi/bzrlib.tree.InterTree.html#iter_changes would be my homework then, right? | 19:31 |
| lifeless | yes | 19:33 |
| lifeless | show_tree_status calls into this | 19:33 |
| lifeless | if you want a crib sheet | 19:33 |
| mtaylor | hi gthorslund ! | 19:35 |
| gthorslund | mtaylor: I'm hacking some python. hope that makes you proud of me ;-) | 19:36 |
| gthorslund | lifeless: looks like it should give me enough of clues. thx | 19:37 |
| mtaylor | gthorslund: excellent | 19:37 |
| beuno | hi jam! | 20:01 |
| beuno | got a minute to help me with meliae? | 20:01 |
| beuno | jam, we have servers blowing up all over the place and we'd like to do some diagnosing | 20:01 |
| mwhudson | beuno: jam is here at uds, so might not be very responsive | 20:02 |
| beuno | mwhudson, well, lucky you, I hear you're quite involved in meliae as well :) | 20:02 |
| mwhudson | beuno: eh, a bit | 20:03 |
| mwhudson | beuno: mostly a cheerleader :) | 20:03 |
| beuno | mwhudson, what would be your guess if we only get a partial meliae dump? | 20:03 |
| mwhudson | beuno: are you looking at jam's blog posts? | 20:04 |
| beuno | mwhudson, I am | 20:04 |
| mwhudson | beuno: missing a flush? | 20:04 |
| mwhudson | beuno: how are you invoking meliae? | 20:05 |
| beuno | mwhudson, this is what we have: https://pastebin.canonical.com/39038/ | 20:05 |
| mwhudson | beuno: meliae trunk? | 20:06 |
| beuno | mwhudson, 0.1.3~1.CAT.8.04 | 20:06 |
| beuno | which I presume is some sort of monster we backported to hardy | 20:07 |
| mwhudson | seems pretty recent | 20:07 |
| mwhudson | although not tagged in trunk, naughty jam | 20:07 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| beuno | mwhudson, does that script look like we'd need to flush anything? | 20:09 |
| mwhudson | no | 20:09 |
| mwhudson | beuno: you get a nice 200 response back? | 20:09 |
| beuno | mwhudson, not really, it complains about not being able to write to "+meliae" | 20:09 |
| beuno | although it does write teh .json file | 20:10 |
| mwhudson | beuno: ?? | 20:10 |
| beuno | mwhudson, scratch that | 20:10 |
| beuno | I do get a 200 | 20:10 |
| mwhudson | beuno: i guess it's hard to say, but is the dump massively truncated or a little bit? | 20:10 |
| jam | mwhudson: what needs to be tagged? | 20:10 |
| mwhudson | jam: there's no 0.3.1 tag in lp:meliae | 20:11 |
| beuno | 3:23 < beuno> (ami-hardy-i386)ubunet@ip-10-122-34-239:~$ wget http://127.0.0.1:8881/+meliae --no-check-certificate | 20:11 |
| beuno | 13:23 < beuno> --18:23:00-- http://127.0.0.1:8881/+meliae | 20:11 |
| beuno | 13:23 < beuno> => `+meliae' | 20:11 |
| jam | mwhudson: I don't think I did an official release, but I'm not positive | 20:11 |
| beuno | 13:23 < beuno> Connecting to 127.0.0.1:8881... connected. | 20:11 |
| beuno | 13:23 < beuno> HTTP request sent, awaiting response... 200 OK | 20:11 |
| beuno | 13:23 < beuno> Length: unspecified [text/html] | 20:11 |
| beuno | but I think it's something wrong with the return | 20:11 |
| mwhudson | jam: oh ok | 20:11 |
| beuno | 13:23 < beuno> +meliae: Permission denied | 20:11 |
| beuno | 13:23 < beuno> Cannot write to `+meliae' (Permission denied). | 20:11 |
| beuno | is what I get | 20:11 |
| jam | mwhudson: I only have 0.3.0 here | 20:11 |
| beuno | mwhudson, the process is ~800mb, and the dump is 13mb | 20:11 |
| mwhudson | beuno: run that in a directory that you have write access to :-) | 20:11 |
| beuno | I'd expect a lot to be missing | 20:11 |
| mwhudson | or wget -O- or something | 20:12 |
| beuno | mwhudson, heh, of course, wget wanting to write | 20:12 |
| beuno | would that truncate the output file? doesn't seem so | 20:12 |
| jam | beuno: dump_all_objects() is what you want to be using, and will try to find everything | 20:12 |
| mwhudson | it does seem unlikely | 20:12 |
| jam | however, being 13MB is not strictly a truncated file | 20:13 |
| beuno | jam, https://pastebin.canonical.com/39038/ | 20:13 |
| beuno | well | 20:13 |
| jam | if you were reading and it said that there was broken content, *that* would be truncated | 20:13 |
| beuno | I say it's truncated because at the end there is half a line | 20:13 |
| jam | beuno: well, that is what I was pointing at. | 20:13 |
| beuno | yes, that's exacly what I get | 20:13 |
| beuno | :) | 20:13 |
| jam | so there was an issue that os.fdopen().flush() wasn't actually flushing if you used the raw FILE * pointer | 20:14 |
| jam | which was fixed (checking the rev) | 20:14 |
| jam | beuno: you have "0.1.3" that is 0.1 series, not 0.3 series | 20:14 |
| jam | definitely upgrade to trunk | 20:14 |
| beuno | aha | 20:14 |
| beuno | ok | 20:15 |
| beuno | that's a good first step | 20:15 |
| mwhudson | doh! | 20:15 |
| jam | if it is just the truncation thing, that should make a big difference | 20:15 |
| mwhudson | beuno: sorry for missing that :) | 20:16 |
| beuno | mwhudson, no worries! this is a lot of progress! | 20:16 |
| jam | beuno: Flush was fixed in the 0.2.1 ish timeframe | 20:16 |
| beuno | thanks jam, mwhudson, I'll update the server and see what happens | 20:16 |
| jam | beuno: I believe mwhudson did something similar but returned the dumped content to the url rather than dumping it to disk, I'm curious why you prefer this method. | 20:17 |
| jam | (certainly from a remote user, it would be nice to get the raw content back.) | 20:18 |
| beuno | jam, I'm actually locally on the server, but what was there was this django middleware to trigger the dump | 20:19 |
| === dash_ is now known as dash | ||
| jam | beuno: any luck? | 20:53 |
| beuno | jam, just managed to get trunk on the server | 20:53 |
| beuno | waiting for some more tests that are going on to finish | 20:53 |
| beuno | and will try again | 20:53 |
| jam | beuno: sounds good. If you need help debugging the dump, let me know. | 20:54 |
| beuno | jam, will do, thanks. Hope to try again in 10-15 | 20:54 |
| jam | you aren't in UDS, right? | 20:54 |
| beuno | no :( | 20:55 |
| beuno | missed it this time around | 20:55 |
| jam | np | 20:56 |
| jam | would have been nice to sit over your shoulder while you worked with it | 20:56 |
| beuno | yeah, would of been great | 20:56 |
| beuno | I'll break more servers next uds you are there too | 20:57 |
| jam | beuno: well if necessary, there is always "screen" | 20:57 |
| jam | anyway, switching rooms, bbiab | 20:58 |
| === Ursinha is now known as Ursinha-afk | ||
| beuno | jam, so, with the new version, they don't seem to truncate, although they do seem small | 21:04 |
| beuno | they are smaller than expected | 21:05 |
| beuno | but size may not matter after all | 21:05 |
| jam | beuno: if you have very large strings, we only dump 100bytes of a given string | 21:07 |
| abentley | jam, I am thinking that my algorithms in https://dev.launchpad.net/Code/BranchRevisions are slightly wrong, in that they assume that there is a single mainline_parent entry for each revision. | 21:07 |
| jam | if you have lots of small objects, then the dump is usually about the same to larger than mem | 21:07 |
| jam | abentley: IIRC, it could still work, you would just search multiple tips concurrently | 21:08 |
| jam | I'd have to look closely again, though | 21:08 |
| jam | beuno: there is also 'dark' memory that I've run into, which can be a lot more than I would like | 21:08 |
| abentley | jam, this affects "Branch page" and "Merge proposal page". | 21:08 |
| dash | jam: oh, that reminds me, thank you for writing meliae | 21:08 |
| dash | jam: it has made my life easier. :) | 21:08 |
| jam | zlib.decompress and zlib.compress tend to have a lot of buffers that aren't particularly accessible, for example | 21:09 |
| jam | dash: I'm very happy it has proven useful to you. It certainly helped me. Feedback always welcome, btw | 21:09 |
| dash | jam: well the only thing i'd change is the license. ;) | 21:09 |
| jam | dash: to? | 21:10 |
| abentley | jam: I worry that a given revision might not be the head of a mainline_parent_range. Maybe the simplest thing is to accept ANY maninline_parent_range where the revision is mentioned. | 21:10 |
| dash | something shorter :) gplv2 or apache/mit/etc | 21:10 |
| jam | dash: why v2 vs v3? | 21:10 |
| abentley | jam: i.e. not the range table per se, but any entry in mainline_parent_range where the revision id is correct. | 21:11 |
| jam | (v3 is canonical policy unless there is specific reason to do otherwise, so if you have specific reasons, I'm willing to listen) | 21:11 |
| abentley | jam: argh, "mainline_parent" | 21:11 |
| dash | ah, i wasn't aware of that. | 21:11 |
| jam | ok | 21:11 |
| dash | jam: my real preference is permissive licenses, personally. it's just that gplv3 makes people in legal very nervous :) | 21:12 |
| dash | anyway, it's not like i'm distributing it to customers, so whatever :) | 21:12 |
| abentley | jam, maybe "SELECT range FROM mainline_parent_range WHERE revision = %s ORDER BY DIST DESC LIMIT 1"? | 21:13 |
| abentley | jam, err "SELECT range FROM mainline_parent WHERE revision = %s ORDER BY DIST DESC LIMIT 1"? | 21:13 |
| jam | dash: atm meliae is designed more as a helper than something you would bundle in your package, though | 21:14 |
| jam | so the license doesn't matter as much | 21:14 |
| jam | abentley: well that query doesn't require it to be the head | 21:15 |
| dash | jam: Sure. | 21:15 |
| dash | like i said, not a big deal. | 21:15 |
| abentley | jam, right, because there might not be an entry where it's the head. | 21:18 |
| abentley | jam, so this way at least you find the entry where it's closest to the head. | 21:19 |
| jam | beuno: any interesting insight ? | 22:13 |
| beuno | jam, well, not from the meliae dump | 22:13 |
| beuno | it seems normal | 22:13 |
| beuno | which is baffling | 22:13 |
| beuno | since we see that processes memory grow over 1gb | 22:13 |
| beuno | but, we found a piece of code that, when removed, stops the server from dying under a small amount of load | 22:14 |
| === Ursinha-afk is now known as Ursinha | ||
| jam | beuno: 1 are you sure you are dumping while it is at its peak, 2 it could be memory fragmentation | 22:14 |
| jam | 3) ISTR that Thread objects take up a lot of memory, which may not be tracked | 22:14 |
| * beuno nods | 22:14 | |
| jam | there are other possible hidden memory allocations | 22:14 |
| beuno | right | 22:14 |
| beuno | I am slowly getting into this part of the world | 22:15 |
| beuno | so no good ideas yet | 22:15 |
| beuno | the other problem we have | 22:15 |
| beuno | is we can't really reproduce it locally | 22:15 |
| jam | beuno: if the dump is small enough, you could bz2 it and put it somewhere and I'll give it a look | 22:15 |
| beuno | only on ec2 instances on staging | 22:15 |
| beuno | jam, sure, it's 14mb and it should shrink quite a bit | 22:15 |
| beuno | will email | 22:16 |
| beuno | jam, sent | 22:22 |
| mgz | jml: in case you didn't see it, I can make those SIGINT tests pass, just whether or not you think the ctypes hackery is worth it. | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!