| jfroy | jelmer: there a way to list ghost revisions or try to figure out where to grab missing revisions? Loggerhead is dying on a new revision in which I've branched a few svn remote branches because it's missing revisions | 00:02 |
|---|---|---|
| lifeless | poolie: ping | 00:03 |
| thumper | poolie: ping too | 00:12 |
| poolie | hello thumper, lifeless | 00:25 |
| poolie | was a late night | 00:25 |
| lifeless | poolie: on your progress branch, can you please run the fixer script from the other bug | 00:27 |
| lifeless | bug 305964 or some such | 00:28 |
| ubottu | Launchpad bug 305964 in nautilus ""Preferred Applications -> Multimedia" should have "Do Nothing" as selection" [Undecided,Invalid] https://launchpad.net/bugs/305964 | 00:28 |
| lifeless | well, not that #. but something :P - documented in the mail I sent to announce last week about networking bugs | 00:28 |
| lifeless | jml: could the branh6/7 thing with LP be the bug I filed about the puller not noticing format changes? | 00:30 |
| poolie | lifeless: yes that's the next thing i was going to do | 00:31 |
| poolie | thumper, what's up? | 00:31 |
| poolie | jam: still around at all? | 00:32 |
| thumper | poolie: was wanting to talk | 00:32 |
| thumper | poolie: although now is probably not a good time | 00:32 |
| lifeless | poolie: jam headed out to pickup his son; he says he may drop in later | 00:32 |
| lifeless | poolie: when you've done that, if your progress branch is fixed, it means that the bug you commented on is probably CHK specific; if your progress branch isn't fixed it could be generic. | 00:33 |
| poolie | lifeless: ok, so that branch is diverged from my local copy of it | 00:35 |
| poolie | it may be the same as the one on my laptop | 00:35 |
| poolie | i'll look into it | 00:35 |
| poolie | thumper just ping me later | 00:35 |
| thumper | ok | 00:35 |
| lifeless | poolie: ok; if you need help/assistance let me know. One thing I'll mention is that the fixer script doesn't accept lp: urls. | 00:36 |
| lifeless | poolie: other than that it should be trivial to use. | 00:36 |
| poolie | so | 00:38 |
| poolie | there's not much content in that branch that i actually want | 00:38 |
| poolie | i can just delete it, unless it's useful debugging information to see whether the script works | 00:38 |
| lifeless | please fix it | 00:40 |
| lifeless | it will tell us whether or not you were seeing the known bug, or something new affecting all formats | 00:40 |
| lifeless | the fixer is pretty quick | 00:40 |
| poolie | ok | 00:41 |
| poolie | so the affected branch is on launcphad | 00:41 |
| poolie | do i run it across sftp? | 00:42 |
| lifeless | bzr+ssh | 00:42 |
| gcpeters | hey everone.. i'm a fairly new user of Bzr and I had a question about the .bzr folder and vs2003 web applications. | 00:42 |
| lifeless | python fixer.py bzr+ssh://bazaar.launchpad.net/~mbp/bzr/progress | 00:42 |
| lifeless | gcpeters: shoot | 00:42 |
| gcpeters | unfortunately we have some legacy projs under vs2003. It appears that folders starting with a period throws off vs for web projects | 00:43 |
| gcpeters | I noted that svn usrs had the same issue but they resolved it with a .net hack by going to _svn | 00:44 |
| gcpeters | is there an option for bzr to use a different root folder for the branch information? | 00:44 |
| lifeless | not at the moment, no. | 00:44 |
| gcpeters | ok | 00:44 |
| lifeless | (sorry) | 00:45 |
| gcpeters | no worries..it'll be an incentive to convince my manager to switch to vs2005 faster. :) | 00:45 |
| gcpeters | thx though. | 00:45 |
| LaserJock | is it possible to do equivalent to svn-copy with bzr-svn? | 00:56 |
| SamB | jelmer: grr, why does a bzr svn-import have to do so many reads of the bzr repository? | 01:02 |
| SamB | or, noo, wait, those are swap-ins aren't they ... | 01:03 |
| * SamB should have looked closer at gkrellm | 01:04 | |
| * SamB wonders what the percentages in the SWAPIN column even mean | 01:05 | |
| poolie | isn't maritza nice :) | 01:15 |
| SamB | poolie: who/what? | 01:15 |
| SamB | what ubuntu release is currently comparable with testings/unstable? | 01:18 |
| dash | do you mean "which one is the newest"? karmic | 01:23 |
| lifeless | SamB: karmic is probably closest at the moment; its usually, as dash implies, whatever ubuntu version is newest. | 01:25 |
| SamB | dash: I mean which one should I have in my /etc/apt/sources.list for bzr-related PPAs, given that I'm actually using testing/unstable | 01:25 |
| lifeless | SamB: karmic | 01:25 |
| SamB | lifeless: how come they don't have a name for that ? | 01:25 |
| lifeless | SamB: its done differently to debian | 01:26 |
| lifeless | unlike debian, after a release ubuntu has a period of anarchy where noone can safely run it | 01:26 |
| lifeless | while the mass merges from debian happen, the toolchain gets rebuilt - everything built again | 01:26 |
| SamB | lifeless: say WHAT? | 01:26 |
| mwhudson | poolie: yes, hang on to that one | 01:26 |
| SamB | oh | 01:27 |
| SamB | oh, btw, how come you always release right before GHC? | 01:27 |
| lifeless | coincidence | 01:27 |
| lifeless | we release right after gnome ;) | 01:27 |
| garyvdm | Whats GHC? | 01:32 |
| mwhudson | glasgow haskell compiler usually... | 01:33 |
| lifeless | haskell | 01:33 |
| jml | lifeless, I don't think so. I've specifically told the puller to mirror those branches each time I've upgraded them. | 01:37 |
| lifeless | jml: is that done by setting the 'next pull time' ? | 01:39 |
| jml | lifeless, yes. | 01:39 |
| lifeless | then it would still fit my bug | 01:40 |
| jml | lifeless, you've lost me. | 01:46 |
| poolie | mwhudson: on to maritza? | 01:49 |
| lifeless | jml: I filed a bug that when the puller runs on a branch with no new revs but a format change, it doesn't remirror the branch | 01:50 |
| lifeless | you're saying yo don't think that fits your scenario, because you've told the puller to run, but I don't see that that stops it fitting the situation I described | 01:51 |
| * SamB never dreamed that darcs' use of _darcs had any advantages | 01:58 | |
| jml | lifeless, the scanner is the thing that updates the format on the branch page, the puller works entirely from the next pull time and notices format changes. | 02:00 |
| jml | lifeless, bug 376276 wouldn't explain end-users branching from a branch and getting an old format. It would explain discrepancies between the website's display of format and what I might expect the format to be, however. | 02:01 |
| ubottu | Launchpad bug 376276 in launchpad-code "mirror doesn't notice format changes without a rev change" [Low,Triaged] https://launchpad.net/bugs/376276 | 02:01 |
| SamB | jml: so what do you think is going wrong? | 02:02 |
| SamB | the puller is just pulling into the same branch without running --upgrade? | 02:02 |
| SamB | er. without running "bzr upgrade" | 02:02 |
| lifeless | SamB: the puller shouldn't upgrade; it zaps and remirrors | 02:03 |
| SamB | lifeless: oh | 02:04 |
| SamB | lifeless: you're sure about that? | 02:04 |
| SamB | have you *seen* it do this? | 02:04 |
| lifeless | SamB: I wrote the original code | 02:05 |
| SamB | and you're sure nobody changed it? | 02:05 |
| jml | and since then we've fixed it. but it still does zap & remirror. | 02:05 |
| lifeless | SamB: I'm sure its been changed, but I'm also sure ^ | 02:05 |
| lifeless | SamB: because upgrade is very expensive | 02:05 |
| lifeless | SamB: compared to zap and pull | 02:06 |
| SamB | really ? | 02:06 |
| SamB | that's wierd | 02:06 |
| SamB | why is that? | 02:06 |
| lifeless | copying is cheaper than calculating | 02:06 |
| SamB | what if the other end is slow? | 02:07 |
| lifeless | then it takes a while, but launchpad isn't wasting CPU cycles | 02:07 |
| SamB | true | 02:07 |
| SamB | I hope you actually keep a backup while this goes on? | 02:08 |
| lifeless | SamB: no, why would we? | 02:08 |
| SamB | in case the other end goes down half-way through or something | 02:08 |
| lifeless | this is a mirror we're maintaining | 02:08 |
| lifeless | most of the lp branches are hosted anyway, so the other end is on the same LAN [FSVO LAN] | 02:08 |
| SamB | oh | 02:09 |
| lifeless | jml: bug https://bugs.edge.launchpad.net/bzr/+bug/390563 - any chance of getting the server traceback that is written to .bzr.log? | 02:09 |
| ubottu | Ubuntu bug 390563 in bzr "absent factory exception from smart server when merging or branching" [Critical,Confirmed] | 02:09 |
| SamB | you mean you aren't talking about what happens if I mirror a repository from some random URL? | 02:09 |
| lifeless | nothing to do with the command line bzr behaviour | 02:10 |
| lifeless | or qbzr/bzr-gtk etc either | 02:10 |
| SamB | it sounded like you were discussing launchpad | 02:10 |
| lifeless | we are | 02:10 |
| lifeless | the internals of launchpad | 02:10 |
| jml | lifeless, perhaps. we don't have a facility for it, but we could probably grab a LOSA sometime this evening. | 02:10 |
| lifeless | jml: it would be of great assistance to debug the cause quickly | 02:11 |
| SamB | so, are you talking about the code that maintains a branch I set up to mirror a URL? | 02:11 |
| jml | lifeless, ok. then your best bet is to contact a LOSA directly, I think. | 02:11 |
| lifeless | SamB: and that maintains the http mirrors for hosted branches | 02:12 |
| lifeless | jml: Are there plans to tie this into oops? | 02:12 |
| lifeless | [this == bzr serve exceptions] | 02:12 |
| SamB | lifeless: in the case of a non-hosted branch, does it zap before re-mirroring on format changes? | 02:12 |
| jml | lifeless, no immediate ones. we'd love to, of course | 02:13 |
| mwhudson | poolie: yeah | 02:13 |
| lifeless | jml: I'll file a bug then | 02:13 |
| jml | lifeless, but these days, mwhudson & I's days are basically made entirely out of interruptions. | 02:13 |
| thumper | poolie: ping | 02:13 |
| poolie | mwhudson: you might look at bug 390542 | 02:14 |
| ubottu | Launchpad bug 390542 in loggerhead "Installation fails on Windows [bzr 1.16]" [Undecided,New] https://launchpad.net/bugs/390542 | 02:14 |
| poolie | thumper: hi | 02:14 |
| thumper | poolie: call? | 02:14 |
| mwhudson | poolie: yes, a catch up of loggerhead bugs is on my list of things to do today | 02:15 |
| mwhudson | after lunch though | 02:15 |
| poolie | thumper: sure | 02:15 |
| lifeless | jelmer_: ping. please explain why you reopen tasks on bugs that people move to bzr-svn with reasons - it means we won't get into back-and-forth | 02:27 |
| poolie | i should read your check-1 branch i guess? | 02:29 |
| lifeless | if its not reviewed yet, please. stacking-policy is actually more urgent though | 02:32 |
| lifeless | as it makes upgrading a series branch impossible | 02:32 |
| poolie | lifeless: thumper asks: brisbane-core pack can take a long time, recompressing things | 02:33 |
| poolie | does this mean that finishing a stream to a smart server might sometimes take a very long time? | 02:33 |
| lifeless | 'why are you running bzr pack' | 02:33 |
| jelmer_ | lifeless: there's some duplication in bzr-svn that can be fixed, but even when that's done the main problem is that bzr deals with full file texts | 02:34 |
| poolie | well, forget about me running bzr pack | 02:34 |
| jelmer_ | lifeless: I don't see how commit builder fits into all of this | 02:34 |
| lifeless | jelmer_: with jams next commit to bzr.dev, commit will hold one copy of the file in memory | 02:35 |
| poolie | is it possible that finishing a stream could take a very long time if it causes repacking? | 02:35 |
| jelmer_ | lifeless: I don't see what commit has to do with this | 02:35 |
| jelmer_ | lifeless: this bug is about fetch | 02:35 |
| lifeless | jelmer_: its the API you're using | 02:35 |
| lifeless | add_lines is part of commit | 02:35 |
| lifeless | jelmer_: anyway, bzr _has_ lower memory API's. bzr-svn should use them. | 02:36 |
| jelmer_ | lifeless: bzr-svn doesn't use commit | 02:36 |
| lifeless | jelmer_: this won't get you below 160MB to commit a 160MB file, but it will get you below 1GB | 02:36 |
| lifeless | jelmer_: which is what the guy is complaining about. I Agree we need to fragment-or-something, but thats a different issue. | 02:37 |
| lifeless | jelmer_: I know you don't use commit builder | 02:37 |
| lifeless | poolie: potentially yes. FSVO of 'very long time' | 02:37 |
| lifeless | poolie: a few minutes perhaps | 02:37 |
| lifeless | may 10 or 15 on the mysql trunk or openoffice. And in those cases, it will do that once every few years. | 02:38 |
| jelmer_ | lifeless: It's not just that, it's also that I can | 02:42 |
| jelmer_ | 't afaik iterate over a large file without loading it into memory | 02:42 |
| poolie | lifeless: ok, but not hours? apparently a full 'bzr pack' of launchpad can take over an hour | 02:42 |
| lifeless | poolie: that seems slow to me | 02:42 |
| === Kissaki is now known as Kissaki^0ff | ||
| lifeless | poolie: and we can look at reusing compression groups in the future | 02:43 |
| poolie | ok | 02:43 |
| lifeless | poolie: a normal push only autopacks, which is logarthimic backoff | 02:43 |
| poolie | yes, i thought this was something we can potentially tune later | 02:43 |
| poolie | right, that too | 02:43 |
| lifeless | so trunks will only do the equivalent of a full pack when they hit the next power of 10 revisions over their current count | 02:43 |
| poolie | another question: tim says the launchpad branches need to be reconciled because they have inconsistent head pointers | 02:43 |
| lifeless | reconciling stacked branches should be very fast | 02:44 |
| poolie | however, this takes a long time, and might block out people from writing to those branches for days | 02:44 |
| lifeless | reconcile them on the server in batch, and upgrade for the users. | 02:44 |
| lifeless | there is a bug open about having a button to request upgrades | 02:44 |
| thumper | lifeless: reconcile on LP 2a format takes over 4 days | 02:45 |
| lifeless | thumper: /stacked/ branches should be very fast to reconcile | 02:45 |
| thumper | these are the trunk, unstacked ones | 02:45 |
| lifeless | thumper: you've already reconciled them as part of the upgrade | 02:45 |
| lifeless | haven't you? | 02:45 |
| thumper | I reconciled the original branch, and upgraded, but when I pulled in the updates, there were inconcistent heads in those | 02:46 |
| thumper | we didn't stop commits for 4 days to do this | 02:46 |
| lifeless | thumper: thats why you needed to reconcile the others before pulling in | 02:46 |
| lifeless | we're working on making check and reconcile be able to look at just a few revisions | 02:46 |
| thumper | there was no partial reconcile | 02:47 |
| jelmer_ | lifeless: what other codepaths could bzr-svn use that use less memory? Doesn't insert_record_stream() require a fulltext or a chunked text? | 02:47 |
| lifeless | thumper: when thats done you can fix things up, if you're not experiencing errors at the moment. There is no ETA for it at the moment. | 02:47 |
| thumper | well | 02:47 |
| thumper | actually we are | 02:47 |
| thumper | well, some people are | 02:47 |
| lifeless | jelmer_: we're talking past each other. You're talking about 'use < file size memory'. I'm talking about 'use 2xfile size memory at most' | 02:48 |
| thumper | those that reconciled thier local repos after I had fixed some of the issues in the later revisions | 02:48 |
| thumper | and they can't merge their pack 0.92 branches into 2a | 02:48 |
| thumper | without reconciling their 2a repo | 02:48 |
| thumper | which takes ages | 02:48 |
| lifeless | jelmer_: insert_record_stream or _add_text can both use less memory than add_lines, for 2a repos. | 02:49 |
| lifeless | thumper: then they'll need to reconcile their repositories. This is /why/ reconcile was such a big feature in the 'how to upgrade' docs. | 02:49 |
| igc1 | hi all | 02:52 |
| === igc1 is now known as igc | ||
| jelmer_ | lifeless: this bug report was unrelated to 2a (it's from march) | 02:53 |
| garyvdm | Hi Ian | 02:53 |
| lifeless | jelmer_: thats true; how does bzr-svn go for 2a formats? | 02:53 |
| jelmer_ | lifeless: also, how can add_lines() be using more memory than VF.insert_record_stream(ChunkedContentFactory) ? | 02:55 |
| jelmer_ | lifeless: It works fine, but I don't know about memory usage | 02:55 |
| lifeless | jelmer_: I think we should either close with 'try with 2a', or you should actually measure how it does. AFAICT you should be able to use no more than 320MB with bzr for a 160MB file coming from svn | 03:01 |
| lifeless | jelmer_: because add_lines requires buffer splitting and joining. Its terrible. | 03:02 |
| jelmer_ | lifeless: isn't that required for chunked data as well? | 03:03 |
| lifeless | no | 03:03 |
| lifeless | for starters, you don't need to use CCF if you have the full contents you can just use a FCF | 03:03 |
| lifeless | and I encourage you to focus on 2a memory performance ;) | 03:03 |
| jelmer_ | CCF? | 03:04 |
| lifeless | chunked content factory | 03:04 |
| jelmer_ | but isn't a list of lines just chunked data as well? | 03:05 |
| lifeless | thumper: can you please make sure that there is a bug or something documenting the error some people are having ? | 03:05 |
| * jelmer_ fears he's missing something obvious here | 03:05 | |
| thumper | lifeless: I'm about to | 03:05 |
| lifeless | I want to make reconcile faster, but I can't remove checks that prevent fetching working etc. | 03:06 |
| lifeless | jelmer_: lines have to be split exactly on \n | 03:07 |
| lifeless | jelmer_: svn uses binary deltas | 03:07 |
| RenatoSilva | is there a way to show a diff between branches? | 03:07 |
| lifeless | RenatoSilva: diff -r branch:oldbranch | 03:07 |
| lifeless | RenatoSilva: or diff --old oldbranch --new newbranch | 03:08 |
| RenatoSilva | the latter makes more sense to me. | 03:08 |
| RenatoSilva | you mean bzr diff right? | 03:08 |
| lifeless | RenatoSilva: yes | 03:08 |
| jelmer_ | lifeless: sure, but eventually the result of that would be chunked data, not a fulltext | 03:08 |
| lifeless | RenatoSilva: if you're in the new branch, the former is easier to type :) | 03:08 |
| RenatoSilva | ok, -r is for revision? | 03:08 |
| RenatoSilva | let me try... | 03:09 |
| lifeless | jelmer_: sure, but the output of svn is chunked, *not* lines. To make it into lines then requires str copying, which gives you two copies. | 03:09 |
| spiv | RenatoSilva: yes. see "bzr help revisionspec" or http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#specifying-revisions | 03:09 |
| lifeless | jelmer_: so by using add_lines you're doubling the memory usage, unless you're very careful to get rid of the svn output before calling into add_lines | 03:10 |
| RenatoSilva | oh, branch: is literal | 03:10 |
| jelmer_ | lifeless: Sure; I'm just trying to understand why the current add_lines() code that John added, which uses some parent data caching, would be worse than my original code which used FCF | 03:12 |
| lifeless | jelmer_: well, if its using the parent map stuff, thats a dict of old texts, so it will be huge in memory | 03:12 |
| lifeless | not get_parent_map, but the cache of serialised forms | 03:13 |
| lifeless | jelmer_: knits are problematic anyway, because of design defects we were not allergic enough to | 03:13 |
| jelmer_ | lifeless: ahh | 03:14 |
| lifeless | jelmer_: Lastly, I want to delete add_lines | 03:14 |
| jelmer_ | lifeless: so in other words, the current code is optimal for knits but for bbc it would make more sense to use insert_record_stream() ? | 03:14 |
| lifeless | I want VF to have /just/ insert_record_stream | 03:14 |
| jelmer_ | lifeless: optimal for knits in terms of speed I mean | 03:15 |
| lifeless | jelmer_: possibly yes, I mean, I haven't looked at what the bzr-svn code is doing | 03:15 |
| lifeless | knits should be very fast via insert_record_stream too. | 03:15 |
| jelmer_ | lifeless: it's basically caching two things; the texts (via LRUSizeCache) since they need to be available as base texts to delta against later, and some opaque structure returned by add_lines and passed into add_lines againg for parents | 03:17 |
| jelmer_ | lifeless: since insert_record_stream() doesn't receive the serialized parent texts in any form, how much will this impact performance against knits? | 03:19 |
| lifeless | -> poolies | 03:31 |
| lifeless | jelmer_: I will chat in a bit | 03:31 |
| jelmer_ | lifeless: thanks for being so patient explaining this :-) | 03:32 |
| jelmer_ | lifeless: I'll probably be gone by the time you get back, time for some sleep | 03:33 |
| SamB | jelmer: current code is very slow here ... | 03:55 |
| SamB | swaps a LOT | 03:55 |
| jelmer_ | SamB: which current code? | 03:57 |
| jelmer_ | SamB: I think I'm missing context, or are you referring to the conversation above? | 03:57 |
| SamB | someone mentioned something about "parent caching" and "full texts" | 03:58 |
| jelmer_ | SamB: in bzr-svn yes, but that'll only really impact you if you have files that are tens of megabytes in size | 03:59 |
| SamB | jelmer: just how many parents does it cache? | 03:59 |
| jelmer_ | SamB: 50 at most | 04:00 |
| SamB | jelmer: that sounds like a lot | 04:00 |
| SamB | does that get multiplied if there are many branches? | 04:01 |
| jelmer_ | SamB: no | 04:01 |
| SamB | how would I know if bzr-svn is encountering files of that magnitude ? | 04:01 |
| jelmer_ | SamB: it's the files in your branch | 04:02 |
| SamB | it's not MY branch ... | 04:02 |
| jelmer_ | SamB: well, after you've imported the branch | 04:02 |
| jelmer_ | SamB: this would only really be a problem if you're importing from a repository that *only* contains iso's | 04:03 |
| SamB | oh. | 04:03 |
| jelmer_ | SamB: I mean, that sort of magnitude | 04:03 |
| * igc lunch | 04:03 | |
| SamB | well, any idea why else bzr-svn would end up using more RAM than firefox? | 04:03 |
| jelmer_ | SamB: what are you importing? | 04:03 |
| SamB | well, first valgrind ... then vex | 04:04 |
| SamB | hmm, they do have a 1.5 MB Makefile.in and a 1.3 MB Makefile | 04:04 |
| dash | impressive | 04:04 |
| SamB | well, I guess the Makefile is local | 04:04 |
| SamB | not in the branch | 04:05 |
| SamB | oh, Makefile.in is from automake too ... | 04:05 |
| jelmer_ | SamB: even if you end up with 50 copies of the makefile that cache won't be a problem (1.5Mb * 50) | 04:06 |
| SamB | jelmer: is there some kind of retainer profiling I can do to diagnose the problem ? | 04:07 |
| mwhudson | heh, amusing | 04:07 |
| mwhudson | repo.iter_inventories([revid, revid]) expodes | 04:07 |
| jelmer_ | SamB: Yeah, I think John posted something to the list about memory profiling a month or two ago | 04:08 |
| * SamB finds the emacs frame where hee has Wanderlust open | 04:11 | |
| jelmer_ | SamB: also, are you using the 2a format yet? | 04:13 |
| SamB | jelmer: how do I do that? | 04:13 |
| SamB | I've been using bzr from apt lately, mostly from PPAs but they seem to have dried up or something ... | 04:14 |
| jelmer_ | SamB: When you create a repository or branch you can specify the format | 04:14 |
| jelmer_ | SamB: 2a is still in beta, but I was curious as it has different codepaths (and memory usage) as knit packs | 04:15 |
| SamB | jelmer: what is the minimum version of bzr that supports 2a? | 04:15 |
| jelmer_ | SamB: 1.16 I think | 04:15 |
| SamB | jelmer: and how would I pass a format to bzr svn-import ? | 04:15 |
| jelmer_ | SamB: you need to create the repository first | 04:16 |
| SamB | jelmer: oh | 04:16 |
| SamB | and what flag do I use to do that? | 04:16 |
| SamB | I didn't see any "2a" in current-formats | 04:16 |
| jelmer_ | I think it's not listed there because it's still in beta | 04:17 |
| SamB | couldn't they just warn about it ? | 04:17 |
| SamB | or maybe have a future-formats topic? | 04:17 |
| jelmer_ | SamB: bzr help other-formats | 04:17 |
| SamB | jelmer: I thought that was for obsolete formats | 04:18 |
| jelmer_ | SamB: "bzr help formats" mentions it | 04:18 |
| SamB | so will converting a repository convert all the branches? | 04:20 |
| jelmer_ | SamB: "bzr upgrade" won't touch anything but the current directory afaik | 04:22 |
| SamB | do the branches even need converting? | 04:23 |
| jam | poolie: ping | 04:30 |
| jam | beuno: I was able to finally connect to your branch, and it failed over bzr+ssh, and looks like it is working via sftp | 04:32 |
| beuno | jam, cool, so you're up to speed now | 04:33 |
| beuno | we now just have to find a fix :) | 04:33 |
| beuno | note that I re-pushed it with some black magic | 04:33 |
| beuno | and it didn't fail afterwards | 04:34 |
| thumper | poolie, lifeless: bug 390951 filed | 05:02 |
| ubottu | Launchpad bug 390951 in bzr "Revision not present errors in Launchpad's scanner" [Undecided,New] https://launchpad.net/bugs/390951 | 05:02 |
| jam | beuno: pushed to the same location? | 05:09 |
| jam | or to a new one | 05:09 |
| === AfC1 is now known as AfC | ||
| mwhudson | no New bugs in loggerhead \o/ | 06:21 |
| Peng_ | Just lots of old bugs :D | 06:22 |
| Peng_ | :P | 06:22 |
| mwhudson | Peng_: how do you trigger https://bugs.edge.launchpad.net/loggerhead/+bug/382765 ? | 06:23 |
| ubottu | Ubuntu bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] | 06:23 |
| Peng_ | mwhudson: Honestly, I've got no idea. | 06:24 |
| Peng_ | mwhudson: When I was testing Loggerhead once recently, I realized that it should probably be failing, but it wasn't. | 06:24 |
| Peng_ | mwhudson: So...I have no idea what's going on. :D | 06:25 |
| mwhudson | hooray | 06:26 |
| mwhudson | serve-branches http://... seems to be broken too? | 06:27 |
| Peng_ | It is? | 06:29 |
| mwhudson | maybe | 06:30 |
| mwhudson | oh wow | 06:30 |
| Peng_ | mwhudson: It is, but I think it's bzr-svn's fault. | 06:31 |
| Peng_ | mwhudson: bzr+http works. http does a PROPFIND but nothing else. | 06:31 |
| Peng_ | mwhudson: Wow what? | 06:31 |
| mwhudson | Peng_: serve-branches http://localhost/.../loggerhead/trunk | 06:31 |
| mwhudson | go to some revision page | 06:32 |
| mwhudson | expand all | 06:32 |
| mwhudson | and boooooooom | 06:32 |
| mwhudson | like this: http://pastebin.ubuntu.com/201853/ | 06:32 |
| mwhudson | something somewhere is very not threadsafe | 06:33 |
| Peng_ | Wow, 300 lines of tracebacks. | 06:34 |
| mwhudson | i wonder why this isn't happening on launchpad | 06:34 |
| mwhudson | i'm going to file a bug and see if this goes away/makes more sense in the morning | 06:39 |
| mwhudson | i guess there's massively inappropriate connection sharing going on | 06:40 |
| mwhudson | aaaa | 06:41 |
| mwhudson | today's lesson: don't share transports between threads | 06:43 |
| mwhudson | and also, t2 = t1.clone(path); <use t1 and t2 in separate threads> --> utter fail for ConnectedTransports | 06:45 |
| Peng_ | Ah. | 06:45 |
| mwhudson | Peng_: does https://bugs.edge.launchpad.net/loggerhead/+bug/390972 make sense to you? | 06:52 |
| ubottu | Ubuntu bug 390972 in loggerhead "need to be more aggressive about transport thread safety" [Critical,Triaged] | 06:52 |
| === afk is now known as mthaddon | ||
| poolie | mwhudson: urgh, don't do that | 06:57 |
| mwhudson | poolie: nmf! | 06:58 |
| mwhudson | there are disadvantages to letting other people commit to trunk, it turns out :) | 06:58 |
| Peng_ | Don't do what? threading.local? | 07:00 |
| lifeless | Peng_: create a transport in thread a, use in thread b | 07:01 |
| lifeless | Peng_: when thread a may still use it | 07:01 |
| poolie | spiv, igc, do either of you want a brief call? | 07:08 |
| igc | poolie: would tomorrow morning be ok? | 07:08 |
| igc | 10-ish say? | 07:08 |
| poolie | fine with me | 07:09 |
| poolie | just go ahead and call if you like | 07:09 |
| vila | hi all | 07:19 |
| mthaddon | erm, any idea why the main links for downloads, etc for bzr1.16 are for the edge version of launchpad? | 07:25 |
| poolie | hello mthaddon | 07:25 |
| mthaddon | hi poolie | 07:25 |
| poolie | and hello vila! | 07:25 |
| poolie | where? | 07:25 |
| poolie | i mean which links?_ | 07:25 |
| mthaddon | http://bazaar-vcs.org/Download | 07:25 |
| mthaddon | first links next to "Source of the stable release for any platform" | 07:26 |
| poolie | i guess jml or somebody just copied the links | 07:31 |
| jml | yeah, I copied them from the commented out lines in the wiki source | 07:32 |
| jml | I guess they should be production links. | 07:32 |
| poolie | is fixed | 07:33 |
| jml | thanks. | 07:41 |
| * davidstrauss is about to complain. | 07:42 | |
| davidstrauss | When are we getting fresh OS X .dmg files? | 07:42 |
| davidstrauss | I'm happy to build 10.5 ones if I can get instructions. | 07:43 |
| poolie | davidstrauss: there were instructions in the thread about this the other day from jfroy | 07:44 |
| poolie | want to give it a try? you'd win acclaim throughout the land | 07:44 |
| davidstrauss | poolie: Have a link? | 07:45 |
| davidstrauss | poolie: just found it | 07:45 |
| mneptok | you would win acclaim throughout the land, but from Mac users. who will turn on you like a pack of rabid, starving, insane wolves if your icon doesn't scale well. | 07:47 |
| davidstrauss | mneptok: :-P | 07:48 |
| mneptok | *muah* :) | 07:48 |
| poolie | well, there is that | 07:48 |
| poolie | don't even think about fixing openbsd selftest :) | 07:48 |
| mneptok | poolie: i owe the list an e-mail, which will be sent when i return from .fi | 07:48 |
| mneptok | "Your test suite violates about EVERY law of proper security practice this project relies upon. You are obviously a mental inferior, and why your parents let you live is beyond my comprehension. BTW, I have attached some patches you might try. When you're not drunk. Love, Theo de Raadt." | 07:50 |
| davidstrauss | poolie: Will anyone care if I drop rebase, qbzr, and looms from the OS X build? | 07:57 |
| poolie | i think some people will | 07:57 |
| poolie | it might still be useful though at least as an intermediate step | 07:57 |
| bialix | qbzr require PyQt4 and there are many questions from mac users about installing this GUI toolkit. | 08:01 |
| bialix | so, bundling qbzr without PyQt is problem for the users | 08:02 |
| bialix | that said: I think if you drop it, not so many people will complain | 08:03 |
| === mthaddon is now known as afk | ||
| === RAOF__ is now known as RAOF_13 | ||
| === RAOF_13 is now known as RAOF | ||
| davidstrauss | poolie: The package is building now, including all the same plugins. | 08:41 |
| lifeless | davidstrauss: have you update to loom trunk? | 08:45 |
| davidstrauss | lifeless: yes | 08:45 |
| lifeless | davidstrauss: cool | 08:45 |
| davidstrauss | lifeless: I saw the commit about 1.16 compat | 08:45 |
| lifeless | :) | 08:45 |
| * lifeless goes to organise dinner | 08:46 | |
| stewart_ | does anybody have a suggestion on how to solve: Unable to load plugin 'gtk'. It requested API version (1, 15, 0) of module <module 'bzrlib' from '/home/stewart/lib/python/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0) | 08:48 |
| stewart_ | latest gtk and latest bzr | 08:48 |
| Peng_ | stewart_: Which latest gtk? | 08:49 |
| Peng_ | stewart_: If it's a package, it may be out-of-date. | 08:49 |
| stewart_ | Peng_: bzr+ssh://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ | 08:49 |
| Peng_ | Oh. :D | 08:50 |
| stewart_ | latest from bzr :) | 08:50 |
| === afk is now known as mthaddon | ||
| Peng_ | stewart_: Well, I'd probably just edit __init__.py, adidng (1, 17, 0) to COMPATIBLE_BZR_VERSIONS, but that's kind of wrong. :D | 08:51 |
| stewart_ | does seem to work :) | 08:53 |
| Peng_ | stewart_: You should poke the bzr-gtk developers too. | 08:53 |
| === thekorn is now known as _thekorn | ||
| davidstrauss | Anyone want to try out my Bazaar 1.16 installer for OS X 10.5? | 09:16 |
| Peng_ | FWIW, using Loggerhead's repo, pushing the whole thing from 2a to 1.9-rich-root locally takes 1m11s, but pushing a couple revisions is close enough to instant that dogfooding it would be doable. | 09:18 |
| === _thekorn is now known as thekorn | ||
| Peng_ | ("close enough to instant" == 2 seconds, FYI) | 09:19 |
| * igc dinner | 09:19 | |
| Peng_ | Remote pushes might be different, of course... | 09:19 |
| lifeless | there is a critical bug open about IDS being used for bzr+ssh | 09:20 |
| lifeless | till thats closed remote pushes will be rather different | 09:20 |
| Peng_ | I'm assuming it's not "good" different... :P | 09:20 |
| lifeless | stewart_: file a bug on bzr-gtk | 09:20 |
| vxnick | davidstrauss: I will | 09:27 |
| davidstrauss | vxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip | 09:28 |
| vxnick | thanks | 09:28 |
| vxnick | davidstrauss: doesn't look like it's overwritten my previous bzr - where does it install bzr to? | 09:30 |
| davidstrauss | vxnick: should be /usr/local/bin | 09:30 |
| vxnick | that's showing me as 1.14.1 | 09:31 |
| davidstrauss | oh, that's cute | 09:33 |
| davidstrauss | it installed everything to / | 09:33 |
| vxnick | haha | 09:33 |
| vxnick | got an uninstaller for it/ | 09:33 |
| davidstrauss | vxnick: just look in / by date | 09:34 |
| vxnick | alrighty | 09:34 |
| davidstrauss | i'll fix the installer | 09:34 |
| davidstrauss | vxnick: Rebuilding the installer now | 09:45 |
| vxnick | davidstrauss: nudge me when ready | 09:45 |
| davidstrauss | vxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip | 09:52 |
| vxnick | davidstrauss: thanks | 09:52 |
| davidstrauss | vxnick: I've verified that it installs the right places now | 09:52 |
| vxnick | davidstrauss: seems to work fine :) | 09:54 |
| davidstrauss | vxnick: cool | 09:54 |
| vxnick | davidstrauss: are you the maintainer for the mac images? | 09:54 |
| davidstrauss | vxnick: Installing to / is such an amazingly dumb default | 09:54 |
| vxnick | :P | 09:54 |
| davidstrauss | vxnick: No, just someone frustrated with the slow updates and probably taking over | 09:55 |
| davidstrauss | vxnick: But I am not a Mac developer, just a user. So this is my first OS X installer build. | 09:55 |
| vxnick | sounds good | 09:55 |
| vxnick | you did good | 09:55 |
| davidstrauss | :-) | 09:55 |
| vxnick | I was looking for a 1.16 build | 09:55 |
| davidstrauss | vxnick: I do maintain RPMs | 09:55 |
| davidstrauss | vxnick: And have for a while | 09:56 |
| vxnick | cool | 09:56 |
| davidstrauss | vxnick: Making my first Mac installer is enough for one night I think. Bedtime for me. | 09:57 |
| vxnick | :) | 09:58 |
| davidstrauss | vxnick: I've made some minor tweaks to the installer to fix man paths, but I haven't uploaded an update yet | 10:03 |
| vxnick | oh, nudge me as usual then | 10:03 |
| davidstrauss | vxnick: Contact me on IRC if you run into any issues | 10:04 |
| vxnick | will do | 10:04 |
| davidstrauss | vxnick: I won't update any more tonight | 10:04 |
| vxnick | no worries | 10:04 |
| davidstrauss | vxnick: Do you work for Canonical? | 10:04 |
| vxnick | davidstrauss: nope | 10:04 |
| davidstrauss | vxnick: Just a bzr+launchpad user? | 10:04 |
| vxnick | davidstrauss: that's right :) | 10:04 |
| davidstrauss | me too | 10:05 |
| Hamaryns | ping gmb | 10:05 |
| Hamaryns | hé jelmer, is het gelukt om Trac naar Launchpad te migreren? | 10:06 |
| LarstiQ | Hamaryns: in what sense? | 10:22 |
| Hamaryns | Um, ok, back to English: Jelmer seems to be the guy that asked https://answers.edge.launchpad.net/malone/+question/73758 and I wanted to ask wether it worked since I am astruggling with the same problem | 10:23 |
| LarstiQ | Hamaryns: ah, jelmer doesn't seem to be done with that yet | 10:28 |
| Hamaryns | I’m onto it with Graham right now, actually | 10:44 |
| Hamaryns | keep an eye on https://answers.edge.launchpad.net/malone/+question/69864 | 10:44 |
| === Kissaki^0ff is now known as Kissaki | ||
| === Hamaryns is now known as Hamaryns|weg | ||
| === Hamaryns|weg is now known as Hamaryns | ||
| lifeless | gnight | 13:00 |
| awilkins | jelmer: Is there any reason why --2a isn't compatible with bzr-svn? | 13:06 |
| jelmer_ | awilkins: 2a is compatible with bzr-svn | 13:07 |
| jelmer_ | Hamaryns: the actual import hasn't happened yet | 13:07 |
| jelmer_ | Hamaryns: but obtaining the xml did | 13:08 |
| awilkins | jelmer: Specifically ; as a test I upgraded a --1.14-rich-root repo to 2a.. I think it make have halted silently though | 13:08 |
| Hamaryns | right, I am in the same phase now, I mailed the xml file to graham binns, waiting for him now. | 13:08 |
| awilkins | jelmer: I'll try it again | 13:09 |
| jelmer_ | awilkins: during "bzr upgrade --2a" you mean? | 13:09 |
| awilkins | jelmer_: Yes, I think it may have halted there | 13:09 |
| awilkins | jelmer_: The next thing to try is to pull it from the SVN repo into a fresh 2a repo | 13:10 |
| awilkins | jelmer_: After I'm getting a "NoSuchRevision" error for what I presume is the tip revision of the branch concverned | 13:10 |
| jelmer_ | awilkins: and into a 1.9-rr repo works? | 13:11 |
| awilkins | awilkins: This was a 1.9-rr upgraded to 1.14-rr | 13:11 |
| awilkins | I'm trying upgrading again | 13:12 |
| awilkins | jelmer_: This repo has some very large revisions in it | 13:12 |
| awilkins | jelmer_: I think it halted during a repack | 13:13 |
| jelmer_ | awilkins: that's all inside of bzr itself; the NoSuchRevision error would be a bzr-svn bug though | 13:25 |
| jelmer_ | awilkins: are you running 0.6 ? | 13:25 |
| awilkins | jelmer_: This is the lastest windows drop 1.16.1 with (AFAIK 0.6.1 bzr-svn) | 13:26 |
| jelmer_ | awilkins: in that case, this might be a known fixed bug | 13:26 |
| awilkins | I'll try it again, I deleted the repo and I'm converting again from the backup | 13:27 |
| awilkins | (taken immediately before conversion) | 13:27 |
| awilkins | As long as it's not a bug related to subvertpy I can try updating my bzr-svn | 13:28 |
| awilkins | subvertpy is a PITA to build on win32 | 13:28 |
| jelmer_ | you shouldn't need a newer subvertpy | 13:30 |
| awilkins | jelmer_: Aha, it halted during repacking inventories | 13:33 |
| awilkins | jelmer_: No stacktrace either | 13:33 |
| awilkins | So not a bzr-svn bug | 13:33 |
| * awilkins tries pull-from-scratch | 13:35 | |
| zarq | hm, gcc on rhel 4.8/itanium is taking forever (over 12 minutes now) to compile _dirstate_helpers_c.c when i do easy_install bzr | 13:37 |
| awilkins | zarq: It should take a few secnds | 13:38 |
| awilkins | zarq: And that's exaggerating | 13:38 |
| zarq | i'll try to install 1.15 | 13:39 |
| zarq | 1.13 installs fine, 1.14 1.15.1 and 1.16 take "forever" to build | 13:42 |
| awilkins | It might be some quirk of Itanium I suppose | 13:44 |
| vila | jam: ping | 13:55 |
| bialix | igc: ping | 13:59 |
| igc | hi bialix | 13:59 |
| bialix | what is your timezone? | 13:59 |
| bialix | re your latest change in bzre (revno 108): IIUC std_profile xmls always should be installed with sources? | 14:00 |
| bialix | igc: if std_profile is must have then we have to add them to setup.py and windows installer | 14:02 |
| igc | bialix: ah ok, I wasn't sure seeing it's not a 'package', just a directory | 14:02 |
| igc | bialix: I'll do it now ... | 14:03 |
| igc | bialix: do I update the packages list in setup.py? | 14:03 |
| bialix | in setup.py you need to use package_data | 14:03 |
| igc | ok | 14:03 |
| igc | bialix: and in the installer, what there? | 14:04 |
| bialix | section [Files], but installer I can update myself | 14:04 |
| bialix | igc: I think Nick Allen should have separate team for qbzr-eclipse | 14:05 |
| bialix | May be we want in the future to create big umbrella team for all qbzr-related things... I dunno | 14:05 |
| igc | bialix: I'd like a bzr-desktop team myself, including qbzr, bzr-gtk and bzr-ide-integration | 14:06 |
| igc | bialix: we need to get more consistency across UIs I think | 14:07 |
| igc | bialix: and many topics are about design, not the technology | 14:07 |
| bialix | yes | 14:07 |
| bialix | igc: good news: translation template is imported! https://translations.launchpad.net/bzr-explorer | 14:14 |
| bialix | igc: new bzr explorer icon in LP is funny :-) | 14:22 |
| igc | bialix: the feet were just too fuzzy :-) | 14:22 |
| igc | bialix: and my daughter, who put both together, preferred the new one | 14:23 |
| bialix | yeah, this one has more positive energy | 14:23 |
| bialix | I really like it | 14:23 |
| bialix | it's funny and positive | 14:23 |
| bialix | but your slogan: "is for human beings" ;-) | 14:24 |
| bialix | perhaps now you would add: and for extra terrestials too! | 14:24 |
| bialix | :-) | 14:24 |
| ddaa | Who said aliens are not human beings? | 14:24 |
| ddaa | Xenist! | 14:24 |
| bialix | Well, I never saw them | 14:25 |
| jimmy_dean | Is it possible with bzr to do the following scenario: Have one master branch with one or more sub-branches, each having been independently initialized with "bzr init". Then be able to commit to any of the subbranches, but also have the ability to pull the master branch and get all of the subbranches. | 14:25 |
| bialix | how can I know about them? | 14:25 |
| bialix | jimmy_dean: yes and no | 14:26 |
| ddaa | jimmy_dean: you appear to be requesting what we call "nested tree" tracking. | 14:26 |
| jimmy_dean | yes :) | 14:26 |
| ddaa | Which is not (yet) in core. | 14:26 |
| jimmy_dean | does a master branch know about sub branches | 14:26 |
| bialix | there is poor man emulation available in plugin | 14:26 |
| jimmy_dean | is it in the works? | 14:26 |
| ddaa | It's been in the works for years. | 14:27 |
| jimmy_dean | oh really, what's the name of that plugin? | 14:27 |
| bialix | scmproj | 14:27 |
| ddaa | jimmy_dean: the person you need to harass about it is abentley. | 14:27 |
| jimmy_dean | lol, ok | 14:27 |
| bialix | harass about nested trees | 14:27 |
| jimmy_dean | this would prove extremely useful for how we use bzr at the company I work for | 14:27 |
| * ddaa nods enthusiasticly | 14:28 | |
| jimmy_dean | I'm surprised that it's not requested more often | 14:28 |
| bialix | every day or so? | 14:28 |
| jimmy_dean | oh really, wow | 14:28 |
| bialix | every week -- for sure | 14:29 |
| jimmy_dean | so is abentley the only one working on this functionality? | 14:30 |
| jimmy_dean | does he need some help? | 14:30 |
| abentley | jimmy_dean: I'm not currently working on this functionality. | 14:30 |
| jimmy_dean | ok, so this functionality is currently abandoned? | 14:31 |
| bialix | I don't think so | 14:32 |
| ddaa | I guess it's "dormant". | 14:32 |
| ddaa | Anyway, scmproj should be as good as what you can get from any other DVCS. | 14:32 |
| abentley | jimmy_dean: It's on hold while I work on some other things. | 14:33 |
| jimmy_dean | ok | 14:33 |
| igc | night all | 14:33 |
| jimmy_dean | abentley: thanks for letting me know | 14:34 |
| bialix | igc: bye | 14:34 |
| jimmy_dean | so how many active core developers are there on bzr, is it a project that needs some help? | 14:34 |
| bialix | I think so | 14:36 |
| jam | vila: pong | 14:36 |
| bialix | hello jam | 14:37 |
| jam | morning bialix | 14:37 |
| bialix | :-) | 14:37 |
| ddaa | There are bunch of core devs on bzr (several on them on payroll at Canonical), but the only software project that does not need help is a dead one. | 14:37 |
| bialix | it's closer to evening there | 14:37 |
| bialix | jimmy_dean: there is a lot places where one can help | 14:38 |
| ddaa | jimmy_dean: nested trees could use some help, if only as a way of demonstrating active community interest. It's problably something very complex and reaching deep in the guts of bzrlib. So not a week-end project. | 14:38 |
| abentley | ddaa: We are stuck at the design stage. Coding help is not useful. | 14:40 |
| ddaa | Then I think coding help would be most useful. I have deep respect for the bzr folks, but you have an unhealthy propension to analysis paralysis on some subjects. | 14:42 |
| abentley | ddaa: I have written plenty of code, and it has not yet been merged. Code help is not useful. | 14:42 |
| ddaa | Ok. | 14:43 |
| LenzGr | jelmer: Around? | 14:49 |
| jimmy_dean | ok, maybe I could start looking at some bugs | 14:49 |
| jimmy_dean | since I'm an experienced coder, but am relatively new to Python | 14:49 |
| jimmy_dean | I'm a C/C++ guy mainly | 14:50 |
| * LenzGr tries to compile subvertpy for bzr-svn, but gets compile errors | 14:50 | |
| jelmer_ | LenzGr: hi | 14:54 |
| LenzGr | jelmer_: Sorry to bother you, but could you look at this compile failure in subertpy? I wonder if it's my setup or a bug... | 14:55 |
| jelmer_ | LenzGr: sure | 14:55 |
| LenzGr | ok, one sec... | 14:55 |
| LenzGr | jelmer_: http://paste2.org/p/279813 | 14:56 |
| LenzGr | jelmer_: This is subvertpy-0.6.0, subversion-1.6.2 and python-2.5.2 | 14:57 |
| jelmer_ | LenzGr: does /usr/include/subversion-1/svn_props.h contain a definition for SVN_PROP_REVISION_LOG ? | 14:58 |
| LenzGr | jelmer_: Yes: | 14:58 |
| LenzGr | 446:#define SVN_PROP_REVISION_LOG SVN_PROP_PREFIX "log" | 14:59 |
| jelmer_ | LenzGr: subvertpy 0.6 is a bit old, it was the initial subvertpy release | 14:59 |
| jelmer_ | LenzGr: any chance you can try 0.6.8 ? | 14:59 |
| LenzGr | jelmer_: Oh, sure! Weird, I wonder where I got that one from... | 15:00 |
| ddaa | jelmer_: why "0.6"? Because you thought "Hm, I guess it's a bit more than halfway there", or something else? | 15:00 |
| LenzGr | jelmer_: Will try and get back to you... | 15:00 |
| jelmer_ | ddaa: it's split out from bzr-svn, so I kept the bzr-svn version numbering up until I split it out | 15:01 |
| jelmer_ | ddaa: bzr-svn 0.6.0 was the first to use an external subvertpy | 15:02 |
| ddaa | Ok. | 15:02 |
| LenzGr | jelmer_: Please disregard, now it compiles fine. I should have taken a closer look at which version was the latest :) | 15:02 |
| * LenzGr simply clicked on the topmost file at http://samba.org/~jelmer/subvertpy/ | 15:02 | |
| jelmer_ | LenzGr: ah | 15:02 |
| jelmer_ | LenzGr: perhaps I should reverse the ordering | 15:02 |
| LenzGr | jelmer_: I think that would make sense :) | 15:03 |
| LenzGr | jelmer_: In any case, I'll work on getting a package of it into the openSUSE build service (to support bzr-svn) | 15:03 |
| jelmer_ | LenzGr: cool | 15:05 |
| abentley | jam: is there something I can do to help you diagnose this inconsistency? | 15:45 |
| abentley | jam: When I got that error, bzr was transferring 190 revisions. But the branch itself had less than 10 lefthand revisions. Is the inconsistency being detected because bzr is doing too much work? | 16:04 |
| jam | abentley: regardless too much work or not... we have a per-file graph where one side says a revision has 2 parents, and the other side says only 1 | 16:10 |
| jam | and you should certainly realize that 190 revs is easy to hit with 10 mainline :) | 16:10 |
| jam | we *could* be hitting too much, but that would still be a bug in the per-file code | 16:10 |
| abentley | jam: I recognize that there is a real inconsistency here. I just think earlier formats weren't so sensitive to this kind of inconsistency. | 16:11 |
| jam | abentley: can you link the bug report again | 16:11 |
| abentley | jam: which bug report? | 16:11 |
| jam | abentley: whatever the traceback was | 16:12 |
| jam | sorry, email | 16:12 |
| jam | brb | 16:12 |
| jam | abentley: so it is possible that it is the new streaming fetch code | 16:12 |
| jam | which tries to fill in things when it thinks other things are missing, etc. | 16:12 |
| jam | certainly we might be looking at more than before | 16:12 |
| jam | because the CHK pages give us more neighbors | 16:12 |
| jam | than the minimal inventory XML delta | 16:13 |
| abentley | jam: https://pastebin.canonical.com/18881/ | 16:13 |
| abentley | jam: It's also possible that the faulty revisions were because PQM was running an old bzr. | 16:13 |
| jam | so the error is saying that the local repo is claiming 1 parent, but the merge source is claiming 2 | 16:14 |
| abentley | jam: I was pulling lp:~launchpad-pqm/launchpad/devel into my local, reconciled, repo. | 16:15 |
| jam | abentley: well one thing we could try | 16:15 |
| jam | r = bzrlib.repository.Repository.open('local') | 16:15 |
| jam | r.lock_read() | 16:15 |
| jam | t = r.texts | 16:15 |
| jam | keys = t.keys() | 16:15 |
| jam | parent_map = t.get_parent_map(keys) | 16:16 |
| jam | remote_r = ... | 16:16 |
| jam | repeate | 16:16 |
| jam | and then compare remote_parent_map with parent_map | 16:16 |
| jam | see how bad things are | 16:16 |
| jam | there should be some keys missing on both sides | 16:16 |
| jam | present entries should have the same value | 16:16 |
| jam | it *sounds* like ghost issues | 16:16 |
| jam | though you shouldn't have ghosts with bzr revisions | 16:17 |
| jam | (versus Arch) | 16:17 |
| jam | ahh.... | 16:17 |
| jam | and the new code notices that the inventories are different | 16:17 |
| jam | because they have different per-file info... perhaps | 16:17 |
| pygi | vila: poke | 16:18 |
| abentley | jam: Working on it.. | 16:18 |
| jam | abentley: if you have 2 repositories with different per-file graph, that might cause the inventories to have different last-modified settings | 16:20 |
| jam | if that was true | 16:20 |
| jam | then "derived" inventories would have a different entry in the inventory | 16:20 |
| jam | and that would show up during the inventory-diff stage | 16:20 |
| jam | and tell us to fetch that record | 16:20 |
| jam | which then gives different content, and boom | 16:21 |
| jam | (versus XML formats, that assumed the XML line-delta held all the information about what was needed to be fetched) | 16:21 |
| jam | though... the last modified revision should be known, since that is the text key we are using for insertion... | 16:21 |
| jam | so maybe I'm off | 16:21 |
| abentley | jam: So if I've done this right, there are 2918 inconsistent texts between the two repos. | 16:25 |
| jam | ouch. that seems like a lot | 16:26 |
| abentley | https://pastebin.canonical.com/18883/ | 16:26 |
| vila | pygi: Hi mario | 16:26 |
| abentley | jam: It's a lot, but it's ~1% of the total texts. | 16:27 |
| jam | abentley: it looks like you did it correctly | 16:27 |
| pygi | vila: are you busy? I want to discuss bzr-gtk :) | 16:27 |
| jam | by my read | 16:27 |
| vila | pygi: yeah pretty busy :-/ Let's try anyway | 16:29 |
| pygi | vila: basically, bzr-gtk is in problems IMHO | 16:30 |
| vila | pygi: define problems :) | 16:30 |
| pygi | Szi doesn't have time, Jelmer either, and I didn't have time even to fix that path issue and/or look at that dbus stuff | 16:30 |
| jam | and at least all the ones I've seen so far say that your local repo claims more revs than the remote | 16:30 |
| pygi | vila: no release for a year? :p | 16:30 |
| jam | well, more parents | 16:30 |
| abentley | jam: I don't think so. My repo is claiming (('bugsemailaffectspath-20070306155409-3k9ueivfh05v4v3b-1', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),) | 16:31 |
| jam | abentley: sorry, I read it backwards | 16:31 |
| jam | parent_map is the local one | 16:31 |
| abentley | jam: right. But I did the list comprehension using remote_parent_map, since it would have the subset that's common to the repos. | 16:33 |
| vila | pygi: ha, right, let's look at the active devs list to find a new RM then... abentley (oops), beuno (oops), garry (oops), | 16:33 |
| vila | pygi: :-/ | 16:33 |
| pygi | vila: I'll have more time starting mid-next month so I'll at least fix windows problems | 16:34 |
| jam | abentley: do you have the XML versions of these repos? | 16:34 |
| beuno | vila, I'll be happy to work out a relaese for bzr-gtk after I manage to get loggerhead out the door :) | 16:35 |
| vila | beuno: err, we want it for yesterday, not next year :-D | 16:35 |
| abentley | vila: I'd take over as the *leader* of pygtk. I wouldn't want to RM without that much authority. Too much strangeness in that codebase. | 16:35 |
| abentley | vila: I mean bzr-gtk | 16:35 |
| vila | abentley, beuno : I was *joking* I didn't think any of the ones I mentioned *can* actully become RM | 16:36 |
| abentley | jam: I don't have an XML version of the remote one, and the local one has had revisions added since the conversion. | 16:37 |
| beuno | :) | 16:37 |
| vila | jelmer: you should know better than me if phanatik intend to do a bzr-gtk release shortly | 16:38 |
| * vila kicks NFS a..^W head for working in all configurations except the one needed right *now* | 16:39 | |
| abentley | jam: Ah, fun! All these bad texts contain 'abel' in their revision-id. | 16:40 |
| abentley | jam: This suggests abel was using an old bzr, and it's not likely that current bzrs are broken. | 16:41 |
| abentley | jam: abel thinks he was using 1.6 (not 1.16). Could it have had such a bug? | 16:44 |
| === vednis is now known as mars | ||
| abentley | jam: so why does fetch care that the remote repository has wrong data about a revision that is already present in the local repository? | 17:01 |
| jam | abentley: my guess is that his *derived* inventories are showing different content | 17:01 |
| abentley | jam: it would be nice if we could somehow fetch the revisions without this affecting us. Otherwise, it's hard to see how we can get properly reconciled across the team. | 17:03 |
| abentley | jam: Could we indirect through an xml-based repo? Or use a more generic fetch codepath? | 17:05 |
| jam | hmm... | 17:06 |
| jam | you could comment out the GCCHK stream source | 17:06 |
| jam | in repofmt/groupcompress_repo.py | 17:06 |
| jam | well, comment out returning it from _get_source | 17:06 |
| jam | that would at least be something to try | 17:09 |
| jam | it would go back to the "generic" path | 17:09 |
| jam | though I can't swear by it | 17:09 |
| jam | the other possibility is to force the InterDifferingSerializer | 17:09 |
| jam | which I think would be the most likely to work | 17:09 |
| abentley | jam: Cool, I'll try it. | 17:10 |
| abentley | jam: No joy the first approach: https://pastebin.canonical.com/18887/ | 17:14 |
| abentley | jam: How do I force the InterDifferingSerializer? | 17:15 |
| jam | === modified file 'bzrlib/repository.py' | 17:16 |
| jam | --- bzrlib/repository.py 2009-06-22 21:55:37 +0000 | 17:16 |
| jam | +++ bzrlib/repository.py 2009-06-23 16:16:28 +0000 | 17:16 |
| jam | @@ -3489,6 +3489,7 @@ | 17:16 |
| jam | @staticmethod | 17:16 |
| jam | def is_compatible(source, target): | 17:16 |
| jam | """Be compatible with Knit2 source and Knit3 target""" | 17:16 |
| jam | + return True | 17:16 |
| jam | # This is redundant with format.check_conversion_target(), however that | 17:16 |
| jam | # raises an exception, and we just want to say "False" as in we won't | 17:16 |
| jam | # support converting between these formats. | 17:17 |
| jam | sorry for the spam | 17:17 |
| abentley | jam: No joy: https://pastebin.canonical.com/18891/ | 17:21 |
| abentley | jam: So it seems this error is being triggered because we're adding records to a GraphIndex which are already present in that GraphIndex. | 17:31 |
| abentley | jam: does that seem like a good thing to you? | 17:38 |
| SamB | is there a way to ask bzr what file defines a given command? | 17:41 |
| jam | abentley: so... not really, but we are doing so because there is a discrepancy, which *does* seem like a good thing to check | 17:45 |
| SamB | jelmer: is there a nice way to find out the closest SVN parent of a working tree's commit, and how far away it was ? | 17:45 |
| abentley | jam: It seems to me like we are checking something we shouldn't check, and getting an irrelevant error as a result. The revisions I want to pull don't have inconsistent parents, AFAIK. | 17:47 |
| abentley | jam: or at least, they don't *introduce* inconsistent parents. | 17:53 |
| jam | so is any of this actually available? | 17:53 |
| abentley | jam: The launchpad branches are not publically available. Is that what you mean? | 17:54 |
| jam | abentley: right, so *I* don't have the easy ability to look at these and see what it thinks needs to be transferred | 17:54 |
| jam | my guess is that these revs say something different than the parent revs | 17:54 |
| abentley | jam: One is lp:~launchpad-pqm/launchpad/devel. I don't know whether you have access to that. I can push my local repo to devpad, or whatever machine we both have access to. | 17:57 |
| jam | I do have access to devel | 17:57 |
| jam | abentley: if you want you can push the other to devpad | 17:58 |
| abentley | jam: pushing... | 18:00 |
| kirkland | jelmer: hey, vcs-imports question again | 18:13 |
| kirkland | jelmer: i'm still not having much success at all with the launchpad auto vcs imports git->bzr for qemu | 18:13 |
| kirkland | jelmer: however, i do have fast-export and fast-import working pretty reliably | 18:14 |
| kirkland | jelmer: i'm wondering if it would make sense at this point just to cronjob something on my end | 18:14 |
| kirkland | jelmer: that would do a fast-export, fast-import, and push periodically | 18:14 |
| kirkland | jelmer: at least until LP gets its vcs importing sorted out | 18:14 |
| === mario_ is now known as pygi | ||
| === mthaddon is now known as afk | ||
| abentley | jam: The faulty revisions were committed with whatever preceeded 1.16rc1 in the bzr beta PPA. | 18:32 |
| jam | abentley: where is it pushed to? | 18:41 |
| abentley | jam: /home/abentley/branches, but the rsync hasn't completed yet. | 18:43 |
| kirkland | jelmer: also, i think you can delete lp:~jelmer/qemu/kvm-git-import-HEAD and lp:~jelmer/qemu/git-import-HEAD | 19:03 |
| mxpxpod | jelmer: ping? | 19:16 |
| abeaumont | hmmm, bzr is taking quite a bunch of resources here: 21683 alfredo 20 0 2936m 1.6g 1816 R 95 40.8 1037:31 bzr | 20:07 |
| abeaumont | 20:07 | |
| abeaumont | is there any way to improve bzr-svn's performance? | 20:08 |
| dash | Hmm | 20:44 |
| dash | i'm trying to envision a workflow for loom | 20:44 |
| dash | i have a big huge branch with changes all jumbled together in it. I want to stratify this into a set of patches for submitting to trunk (which is an svn repo and doesn't care about my local history) | 20:45 |
| dash | so i guess one way to do it is to create a new branch from trunk, loomify it, merge my existing branch, and use shelve to selectively commit things to different threads? | 20:47 |
| === verterok_ is now known as verterok | ||
| Isaiah | Is there a way to have bzr ignore everything except one file in a directory? Can I just do !filename like in git? | 21:55 |
| Tak | ? ls | grep -v filename | xargs bzr ignore | 21:56 |
| beuno | Isaiah, just don't add the other files? | 21:57 |
| abentley | jam: This fixes the problem for me. I know it's inefficient, but is it sane? https://pastebin.canonical.com/18904/ | 22:00 |
| Peng_ | Isaiah: Use a * ignore rule, and then "bzr add" that one file. | 22:01 |
| Isaiah | Ah cool, that works! Thanks Peng_ and beuno :) | 22:02 |
| jam | abentley: I think you can do that sort of thing differently, but the check you are trying to do is there | 22:04 |
| jam | namely, if we have it, skip it | 22:04 |
| abentley | jam: What's a better way of doing it? | 22:05 |
| lamalex | Can anyone help me with bzr bisect | 22:05 |
| lamalex | the --help is ambiguous | 22:05 |
| jam | abentley: if self.get_parent_map(key): continue | 22:05 |
| jam | well | 22:05 |
| jam | if self.get_parent_map([key]): continue | 22:05 |
| jam | though that may do something based on fallbacks | 22:06 |
| lamalex | If I'm looking for what revision a bug was introduced at, and the current revision has the bug would I want to do bzr bisect yes or no | 22:06 |
| lamalex | bzr bisect yes [-r rev] The specified revision (or the current revision, if not given) has the characteristic we're looking for, | 22:06 |
| lamalex | Is the characteristic im looking for the bug, or not the bug | 22:06 |
| dash | you're looking for where a bug was introduced | 22:07 |
| dash | so 'yes' | 22:07 |
| lamalex | thanks | 22:08 |
| abentley | jam: It would be nice to be able to predict the text keys before drinking the stream. | 22:12 |
| jam | abentley: sinks aren't supposed to | 22:12 |
| jam | as it sort of violates the "streaming" principle | 22:12 |
| jam | as would having the source peak at the target | 22:13 |
| jam | at least, that's what I've been told | 22:13 |
| abentley | jam: I know that it does, but you can see why it would be useful. | 22:13 |
| jam | abentley: sure | 22:13 |
| abentley | jam: Still pushing the repo, by the way. | 22:13 |
| jam | big repo, it would seem | 22:13 |
| lamalex | wow, bzr bisect fails | 22:13 |
| abentley | jam: .3 G, and twice that with obsolete_packs. | 22:14 |
| === mwhudson_ is now known as mwhudson | ||
| === nevans1 is now known as nevans | ||
| lifeless | oioioi | 23:05 |
| beuno | good morning lifeless | 23:05 |
| === Kissaki is now known as Kissaki^0ff | ||
| lifeless | jam: | 23:14 |
| lifeless | jam: https://devpad.canonical.com/~spm/bzr-logs.tgz | 23:14 |
| mtaylor | lifeless: morning! | 23:25 |
| mtaylor | lifeless: I'd just like to point out: /usr/lib/python2.6/dist-packages/bzrlib/util/bencode.py:22: DeprecationWarning: bzrlib.util.bencode was deprecated in version 1.16. | 23:26 |
| Peng_ | Somebody forgot a stacklevel=2. | 23:26 |
| mtaylor | I mean, it's obviously not breaking anything - but it is annoying to see _every_ time I do anything | 23:26 |
| Peng_ | mtaylor: That error message is useless. It doesn't say *what*'s importing bzrlib.util.bencode. Is there a traceback in .bzr.log or something? | 23:27 |
| mtaylor | Peng_: nope | 23:27 |
| Peng_ | Argh. I knew I should've sent a patch for that. | 23:27 |
| mtaylor | heh | 23:27 |
| * mtaylor _really_ hates stack traces that swallow incoming stack | 23:28 | |
| Peng_ | mtaylor: I think bzr-svn or bzr-git imported bencode, and a development version fixes the deprecation warning. | 23:28 |
| Peng_ | fwiw | 23:28 |
| mtaylor | Peng_: cool | 23:28 |
| mtaylor | Peng_: I don't have bzr-git - but I do have bzr-svn | 23:28 |
| mtaylor | not that I really need it atm... | 23:29 |
| Peng_ | Anyway, it's only a guess at what's causing it. | 23:29 |
| garyvdm | Hi all | 23:30 |
| lifeless | mtaylor: edit that file | 23:30 |
| Peng_ | That part of bzr-svn probably shouldn't get imported unless you're actively using bzr-svn. | 23:30 |
| lifeless | mtaylor: on that line is a function call | 23:30 |
| lifeless | add stack_level=2 to the call | 23:30 |
| Peng_ | stacklevel=2 | 23:31 |
| mtaylor | lifeless: symbol_versioning.warn(dep_warning, DeprecationWarning, stack_level=2) | 23:31 |
| mtaylor | ah | 23:31 |
| Peng_ | No underscore. | 23:31 |
| mtaylor | HAHA | 23:31 |
| mtaylor | it's a local plugin | 23:31 |
| mtaylor | thanks guys! | 23:32 |
| lifeless | mtaylor: :) | 23:32 |
| mtaylor | lifeless: /home/mordred/.bazaar/plugins/mysql/emailer.py | 23:32 |
| * Peng_ sends a trivial patch. | 23:32 | |
| Peng_ | mtaylor: Change it to use bzrlib.bencode. | 23:32 |
| Peng_ | mtaylor: (Or do a try...except ImportError for bzrlib.bencode, falling back to bzrlib.util.bencode.) | 23:32 |
| mtaylor | actually... since I don't hack on mysql internals anymore - I might just uninstall the plugin... | 23:33 |
| Peng_ | Or that. | 23:33 |
| lifeless | drizzle isn't mysql? | 23:33 |
| mtaylor | god no | 23:33 |
| lifeless | YHBT HAND HTH | 23:33 |
| lifeless | ah, the sweet smell of trolling in the morning | 23:33 |
| mtaylor | mmm | 23:33 |
| lifeless | where are those bindings in your stack now? | 23:34 |
| mtaylor | ooh. actually, that might be something I can whip up while sitting here in this conference... | 23:34 |
| mtaylor | I'm certainly not actually getting anything out of the talks | 23:34 |
| lifeless | what conf? | 23:34 |
| mtaylor | lifeless: velocity | 23:35 |
| mtaylor | lifeless: I'm speaking tomorrow, so I'm here today | 23:35 |
| lifeless | its a LEAN conf or something? | 23:35 |
| mtaylor | lifeless: does mainline bzr have default hooks for not commit conflict markers yet? | 23:36 |
| mtaylor | that's the main reason I was keeping the mysql plugin around | 23:36 |
| mtaylor | lifeless: it's an O'Reilly conference about Scaling | 23:37 |
| lifeless | expand on ' default hooks for not commit conflict markers' | 23:38 |
| mtaylor | lifeless: if you ran bzr resolve on a merge conflict, but you actually didn't catch all of the conflicts | 23:39 |
| lifeless | 'bzr resolve foo' ignores the file content. | 23:39 |
| mtaylor | lifeless: so somewhere in your code something is broken and has a <<< MERGE-SOURCE (or whatever the marker is) | 23:39 |
| mtaylor | right | 23:39 |
| lifeless | 'bzr resolve' scans all conflicted files and resolves those that look clean | 23:39 |
| mtaylor | ok. | 23:40 |
| lifeless | moral of the story, use 'bzr resolve' | 23:40 |
| mtaylor | well, yeah. I like doing that | 23:40 |
| mtaylor | you know when that doesn't work? | 23:40 |
| mtaylor | when I pull changes into a branch, and one of the changes was adding a file that already existed in the branch I'm pulling in to | 23:40 |
| mtaylor | I have to resolve each of those individually :( | 23:40 |
| lifeless | yes | 23:41 |
| mtaylor | but I can get over that | 23:41 |
| lifeless | its a weak point | 23:41 |
| mtaylor | while I'm whinging ... | 23:43 |
| mtaylor | unshelve Restore shelved changes. | 23:43 |
| mtaylor | unshelve1 Restore shelved changes. [bzrtools] | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!