/srv/irclogs.ubuntu.com/2009/06/23/#bzr.txt

jfroyjelmer: 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 revisions00:02
lifelesspoolie: ping00:03
thumperpoolie: ping too00:12
pooliehello thumper, lifeless00:25
pooliewas a late night00:25
lifelesspoolie: on your progress branch, can you please run the fixer script from the other bug00:27
lifelessbug 305964 or some such00:28
ubottuLaunchpad bug 305964 in nautilus ""Preferred Applications -> Multimedia" should have "Do Nothing" as selection" [Undecided,Invalid] https://launchpad.net/bugs/30596400:28
lifelesswell, not that #. but something :P - documented in the mail I sent to announce last week about networking bugs00:28
lifelessjml: could the branh6/7 thing with LP be the bug I filed about the puller not noticing format changes?00:30
poolielifeless: yes that's the next thing i was going to do00:31
pooliethumper, what's up?00:31
pooliejam: still around at all?00:32
thumperpoolie: was wanting to talk00:32
thumperpoolie: although now is probably not a good time00:32
lifelesspoolie: jam headed out to pickup his son; he says he may drop in later00:32
lifelesspoolie: 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
poolielifeless: ok, so that branch is diverged from my local copy of it00:35
poolieit may be the same as the one on my laptop00:35
pooliei'll look into it00:35
pooliethumper just ping me later00:35
thumperok00:35
lifelesspoolie: 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
lifelesspoolie: other than that it should be trivial to use.00:36
poolieso00:38
pooliethere's not much content in that branch that i actually want00:38
pooliei can just delete it, unless it's useful debugging information to see whether the script works00:38
lifelessplease fix it00:40
lifelessit will tell us whether or not you were seeing the known bug, or something new affecting all formats00:40
lifelessthe fixer is pretty quick00:40
poolieok00:41
poolieso the affected branch is on launcphad00:41
pooliedo i run it across sftp?00:42
lifelessbzr+ssh00:42
gcpetershey everone.. i'm a fairly new user of Bzr and I had a question about the .bzr folder and vs2003 web applications.00:42
lifelesspython fixer.py bzr+ssh://bazaar.launchpad.net/~mbp/bzr/progress00:42
lifelessgcpeters: shoot00:42
gcpetersunfortunately we have some legacy projs under vs2003.  It appears that folders starting with a period throws off vs for web projects00:43
gcpetersI noted that svn usrs had the same issue but they resolved it with a .net hack by going to _svn00:44
gcpetersis there an option for bzr to use a different root folder for the branch information?00:44
lifelessnot at the moment, no.00:44
gcpetersok00:44
lifeless(sorry)00:45
gcpetersno worries..it'll be an incentive to convince my manager to switch to vs2005 faster. :)00:45
gcpetersthx though.00:45
LaserJockis it possible to do equivalent to svn-copy with bzr-svn?00:56
SamBjelmer: grr, why does a bzr svn-import have to do so many reads of the bzr repository?01:02
SamBor, noo, wait, those are swap-ins aren't they ...01:03
* SamB should have looked closer at gkrellm01:04
* SamB wonders what the percentages in the SWAPIN column even mean01:05
poolieisn't maritza nice :)01:15
SamBpoolie: who/what?01:15
SamBwhat ubuntu release is currently comparable with testings/unstable?01:18
dashdo you mean "which one is the newest"? karmic01:23
lifelessSamB: karmic is probably closest at the moment; its usually, as dash implies, whatever ubuntu version is newest.01:25
SamBdash: I mean which one should I have in my /etc/apt/sources.list for bzr-related PPAs, given that I'm actually using testing/unstable01:25
lifelessSamB: karmic01:25
SamBlifeless: how come they don't have a name for that ?01:25
lifelessSamB: its done differently to debian01:26
lifelessunlike debian, after a release ubuntu has a period of anarchy where noone can safely run it01:26
lifelesswhile the mass merges from debian happen, the toolchain gets rebuilt - everything built again01:26
SamBlifeless: say WHAT?01:26
mwhudsonpoolie: yes, hang on to that one01:26
SamBoh01:27
SamBoh, btw, how come you always release right before GHC?01:27
lifelesscoincidence01:27
lifelesswe release right after gnome ;)01:27
garyvdmWhats GHC?01:32
mwhudsonglasgow haskell compiler usually...01:33
lifelesshaskell01:33
jmllifeless, I don't think so. I've specifically told the puller to mirror those branches each time I've upgraded them.01:37
lifelessjml: is that done by setting the 'next pull time' ?01:39
jmllifeless, yes.01:39
lifelessthen it would still fit my bug01:40
jmllifeless, you've lost me.01:46
pooliemwhudson: on to maritza?01:49
lifelessjml: 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 branch01:50
lifelessyou'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 described01:51
* SamB never dreamed that darcs' use of _darcs had any advantages01:58
jmllifeless, 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
jmllifeless, 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
ubottuLaunchpad bug 376276 in launchpad-code "mirror doesn't notice format changes without a rev change" [Low,Triaged] https://launchpad.net/bugs/37627602:01
SamBjml: so what do you think is going wrong?02:02
SamBthe puller is just pulling into the same branch without running --upgrade?02:02
SamBer. without running "bzr upgrade"02:02
lifelessSamB: the puller shouldn't upgrade; it zaps and remirrors02:03
SamBlifeless: oh02:04
SamBlifeless: you're sure about that?02:04
SamBhave you *seen* it do this?02:04
lifelessSamB: I wrote the original code02:05
SamBand you're sure nobody changed it?02:05
jmland since then we've fixed it. but it still does zap & remirror.02:05
lifelessSamB: I'm sure its been changed, but I'm also sure ^02:05
lifelessSamB: because upgrade is very expensive02:05
lifelessSamB: compared to zap and pull02:06
SamBreally ?02:06
SamBthat's wierd02:06
SamBwhy is that?02:06
lifelesscopying is cheaper than calculating02:06
SamBwhat if the other end is slow?02:07
lifelessthen it takes a while, but launchpad isn't wasting CPU cycles02:07
SamBtrue02:07
SamBI hope you actually keep a backup while this goes on?02:08
lifelessSamB: no, why would we?02:08
SamBin case the other end goes down half-way through or something02:08
lifelessthis is a mirror we're maintaining02:08
lifelessmost of the lp branches are hosted anyway, so the other end is on the same LAN [FSVO LAN]02:08
SamBoh02:09
lifelessjml: bug https://bugs.edge.launchpad.net/bzr/+bug/390563 - any chance of getting the server traceback that is written to .bzr.log?02:09
ubottuUbuntu bug 390563 in bzr "absent factory exception from smart server when merging or branching" [Critical,Confirmed]02:09
SamByou mean you aren't talking about what happens if I mirror a repository from some random URL?02:09
lifelessnothing to do with the command line bzr behaviour02:10
lifelessor qbzr/bzr-gtk etc either02:10
SamBit sounded like you were discussing launchpad02:10
lifelesswe are02:10
lifelessthe internals of launchpad02:10
jmllifeless, perhaps. we don't have a facility for it, but we could probably grab a LOSA sometime this evening.02:10
lifelessjml: it would be of great assistance to debug the cause quickly02:11
SamBso, are you talking about the code that maintains a branch I set up to mirror a URL?02:11
jmllifeless, ok. then your best bet is to contact a LOSA directly, I think.02:11
lifelessSamB: and that maintains the http mirrors for hosted branches02:12
lifelessjml: Are there plans to tie this into oops?02:12
lifeless[this == bzr serve exceptions]02:12
SamBlifeless: in the case of a non-hosted branch, does it zap before re-mirroring on format changes?02:12
jmllifeless, no immediate ones. we'd love to, of course02:13
mwhudsonpoolie: yeah02:13
lifelessjml: I'll file a bug then02:13
jmllifeless, but these days, mwhudson & I's days are basically made entirely out of interruptions.02:13
thumperpoolie: ping02:13
pooliemwhudson: you might look at bug 39054202:14
ubottuLaunchpad bug 390542 in loggerhead "Installation fails on Windows [bzr 1.16]" [Undecided,New] https://launchpad.net/bugs/39054202:14
pooliethumper: hi02:14
thumperpoolie: call?02:14
mwhudsonpoolie: yes, a catch up of loggerhead bugs is on my list of things to do today02:15
mwhudsonafter lunch though02:15
pooliethumper: sure02:15
lifelessjelmer_: 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-forth02:27
pooliei should read your check-1 branch i guess?02:29
lifelessif its not reviewed yet, please. stacking-policy is actually more urgent though02:32
lifelessas it makes upgrading a series branch impossible02:32
poolielifeless: thumper asks: brisbane-core pack can take a long time, recompressing things02:33
pooliedoes 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 texts02:34
pooliewell, forget about me running bzr pack02:34
jelmer_lifeless: I don't see how commit builder fits into all of this02:34
lifelessjelmer_: with jams next commit to bzr.dev, commit will hold one copy of the file in memory02:35
poolieis 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 this02:35
jelmer_lifeless: this bug is about fetch02:35
lifelessjelmer_: its the API you're using02:35
lifelessadd_lines is part of commit02:35
lifelessjelmer_: anyway, bzr _has_ lower memory API's. bzr-svn should use them.02:36
jelmer_lifeless: bzr-svn doesn't use commit02:36
lifelessjelmer_: this won't get you below 160MB to commit a 160MB file, but it will get you below 1GB02:36
lifelessjelmer_: which is what the guy is complaining about. I Agree we need to fragment-or-something, but thats a different issue.02:37
lifelessjelmer_: I know you don't use commit builder02:37
lifelesspoolie: potentially yes. FSVO of 'very long time'02:37
lifelesspoolie: a few minutes perhaps02:37
lifelessmay 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 can02:42
jelmer_'t afaik iterate over a large file without loading it into memory02:42
poolielifeless: ok, but not hours? apparently a full 'bzr pack' of launchpad can take over an hour02:42
lifelesspoolie: that seems slow to me02:42
=== Kissaki is now known as Kissaki^0ff
lifelesspoolie: and we can look at reusing compression groups in the future02:43
poolieok02:43
lifelesspoolie: a normal push only autopacks, which is logarthimic backoff02:43
poolieyes, i thought this was something we can potentially tune later02:43
poolieright, that too02:43
lifelessso trunks will only do the equivalent of a full pack when they hit the next power of 10 revisions over their current count02:43
poolieanother question: tim says the launchpad branches need to be reconciled because they have inconsistent head pointers02:43
lifelessreconciling stacked branches should be very fast02:44
pooliehowever, this takes a long time, and might block out people from writing to those branches for days02:44
lifelessreconcile them on the server in batch, and upgrade for the users.02:44
lifelessthere is a bug open about having a button to request upgrades02:44
thumperlifeless: reconcile on LP 2a format takes over 4 days02:45
lifelessthumper: /stacked/ branches should be very fast to reconcile02:45
thumperthese are the trunk, unstacked ones02:45
lifelessthumper: you've already reconciled them as part of the upgrade02:45
lifelesshaven't you?02:45
thumperI reconciled the original branch, and upgraded, but when I pulled in the updates, there were inconcistent heads in those02:46
thumperwe didn't stop commits for 4 days to do this02:46
lifelessthumper: thats why you needed to reconcile the others before pulling in02:46
lifelesswe're working on making check and reconcile be able to look at just a few revisions02:46
thumperthere was no partial reconcile02: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
lifelessthumper: 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
thumperwell02:47
thumperactually we are02:47
thumperwell, some people are02:47
lifelessjelmer_: 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
thumperthose that reconciled thier local repos after I had fixed some of the issues in the later revisions02:48
thumperand they can't merge their pack 0.92 branches into 2a02:48
thumperwithout reconciling their 2a repo02:48
thumperwhich takes ages02:48
lifelessjelmer_: insert_record_stream or _add_text can both use less memory than add_lines, for 2a repos.02:49
lifelessthumper:  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
igc1hi all02:52
=== igc1 is now known as igc
jelmer_lifeless: this bug report was unrelated to 2a (it's from march)02:53
garyvdmHi Ian02:53
lifelessjelmer_: 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 usage02:55
lifelessjelmer_: 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 svn03:01
lifelessjelmer_: 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
lifelessno03:03
lifelessfor starters, you don't need to use CCF if you have the full contents you can just use a FCF03:03
lifelessand I encourage you to focus on 2a memory performance ;)03:03
jelmer_CCF?03:04
lifelesschunked content factory03:04
jelmer_but isn't a list of lines just chunked data as well?03:05
lifelessthumper: 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 here03:05
thumperlifeless: I'm about to03:05
lifelessI want to make reconcile faster, but I can't remove checks that prevent fetching working etc.03:06
lifelessjelmer_: lines have to be split exactly on \n03:07
lifelessjelmer_: svn uses binary deltas03:07
RenatoSilvais there a way to show a diff between branches?03:07
lifelessRenatoSilva: diff -r branch:oldbranch03:07
lifelessRenatoSilva: or diff --old oldbranch --new newbranch03:08
RenatoSilvathe latter makes more sense to me.03:08
RenatoSilvayou mean bzr diff right?03:08
lifelessRenatoSilva: yes03:08
jelmer_lifeless: sure, but eventually the result of that would be chunked data, not a fulltext03:08
lifelessRenatoSilva: if you're in the new branch, the former is easier to type :)03:08
RenatoSilvaok, -r is for revision?03:08
RenatoSilvalet me try...03:09
lifelessjelmer_: 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
spivRenatoSilva: yes.  see "bzr help revisionspec" or http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#specifying-revisions03:09
lifelessjelmer_: 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_lines03:10
RenatoSilvaoh, branch: is literal03: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 FCF03:12
lifelessjelmer_: well, if its using the parent map stuff, thats a dict of old texts, so it will be huge in memory03:12
lifelessnot get_parent_map, but the cache of serialised forms03:13
lifelessjelmer_: knits are problematic anyway, because of design defects we were not allergic enough to03:13
jelmer_lifeless: ahh03:14
lifelessjelmer_: Lastly, I want to delete add_lines03: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
lifelessI want VF to have /just/ insert_record_stream03:14
jelmer_lifeless: optimal for knits in terms of speed I mean03:15
lifelessjelmer_: possibly yes, I mean, I haven't looked at what the bzr-svn code is doing03:15
lifelessknits 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 parents03: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-> poolies03:31
lifelessjelmer_: I will chat in a bit03: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 sleep03:33
SamBjelmer: current code is very slow here ...03:55
SamBswaps a LOT03: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
SamBsomeone 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 size03:59
SamBjelmer: just how many parents does it cache?03:59
jelmer_SamB: 50 at most04:00
SamBjelmer: that sounds like a lot04:00
SamBdoes that get multiplied if there are many branches?04:01
jelmer_SamB: no04:01
SamBhow would I know if bzr-svn is encountering files of that magnitude ?04:01
jelmer_SamB: it's the files in your branch04:02
SamBit's not MY branch ...04:02
jelmer_SamB: well, after you've imported the branch04:02
jelmer_SamB: this would only really be a problem if you're importing from a repository that *only* contains iso's04:03
SamBoh.04:03
jelmer_SamB: I mean, that sort of magnitude04:03
* igc lunch04:03
SamBwell, any idea why else bzr-svn would end up using more RAM than firefox?04:03
jelmer_SamB: what are you importing?04:03
SamBwell, first valgrind ... then vex04:04
SamBhmm, they do have a 1.5 MB Makefile.in and a 1.3 MB Makefile04:04
dashimpressive04:04
SamBwell, I guess the Makefile is local04:04
SamBnot in the branch04:05
SamBoh, 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
SamBjelmer: is there some kind of retainer profiling I can do to diagnose the problem ?04:07
mwhudsonheh, amusing04:07
mwhudsonrepo.iter_inventories([revid, revid]) expodes04:07
jelmer_SamB: Yeah, I think John posted something to the list about memory profiling a month or two ago04:08
* SamB finds the emacs frame where hee has Wanderlust open04:11
jelmer_SamB: also, are you using the 2a format yet?04:13
SamBjelmer: how do I do that?04:13
SamBI'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 format04:14
jelmer_SamB: 2a is still in beta, but I was curious as it has different codepaths (and memory usage) as knit packs04:15
SamBjelmer: what is the minimum version of bzr that supports 2a?04:15
jelmer_SamB: 1.16 I think04:15
SamBjelmer: and how would I pass a format to bzr svn-import ?04:15
jelmer_SamB: you need to create the repository first04:16
SamBjelmer: oh04:16
SamBand what flag do I use to do that?04:16
SamBI didn't see any "2a" in current-formats04:16
jelmer_I think it's not listed there because it's still in beta04:17
SamBcouldn't they just warn about it ?04:17
SamBor maybe have a future-formats topic?04:17
jelmer_SamB: bzr help other-formats04:17
SamBjelmer: I thought that was for obsolete formats04:18
jelmer_SamB: "bzr help formats" mentions it04:18
SamBso will converting a repository convert all the branches?04:20
jelmer_SamB: "bzr upgrade" won't touch anything but the current directory afaik04:22
SamBdo the branches even need converting?04:23
jampoolie: ping04:30
jambeuno: I was able to finally connect to your branch, and it failed over bzr+ssh, and looks like it is working via sftp04:32
beunojam, cool, so you're up to speed now04:33
beunowe now just have to find a fix  :)04:33
beunonote that I re-pushed it with some black magic04:33
beunoand it didn't fail afterwards04:34
thumperpoolie, lifeless: bug 390951 filed05:02
ubottuLaunchpad bug 390951 in bzr "Revision not present errors in Launchpad's scanner" [Undecided,New] https://launchpad.net/bugs/39095105:02
jambeuno: pushed to the same location?05:09
jamor to a new one05:09
=== AfC1 is now known as AfC
mwhudsonno New bugs in loggerhead \o/06:21
Peng_Just lots of old bugs :D06:22
Peng_:P06:22
mwhudsonPeng_: how do you trigger https://bugs.edge.launchpad.net/loggerhead/+bug/382765 ?06:23
ubottuUbuntu 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. :D06:25
mwhudsonhooray06:26
mwhudsonserve-branches http://... seems to be broken too?06:27
Peng_It is?06:29
mwhudsonmaybe06:30
mwhudsonoh wow06: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
mwhudsonPeng_: serve-branches http://localhost/.../loggerhead/trunk06:31
mwhudsongo to some revision page06:32
mwhudsonexpand all06:32
mwhudsonand boooooooom06:32
mwhudsonlike this: http://pastebin.ubuntu.com/201853/06:32
mwhudsonsomething somewhere is very not threadsafe06:33
Peng_Wow, 300 lines of tracebacks.06:34
mwhudsoni wonder why this isn't happening on launchpad06:34
mwhudsoni'm going to file a bug and see if this goes away/makes more sense in the morning06:39
mwhudsoni guess there's massively inappropriate connection sharing going on06:40
mwhudsonaaaa06:41
mwhudsontoday's lesson: don't share transports between threads06:43
mwhudsonand also, t2 = t1.clone(path); <use t1 and t2 in separate threads> --> utter fail for ConnectedTransports06:45
Peng_Ah.06:45
mwhudsonPeng_: does https://bugs.edge.launchpad.net/loggerhead/+bug/390972 make sense to you?06:52
ubottuUbuntu bug 390972 in loggerhead "need to be more aggressive about transport thread safety" [Critical,Triaged]06:52
=== afk is now known as mthaddon
pooliemwhudson: urgh, don't do that06:57
mwhudsonpoolie: nmf!06:58
mwhudsonthere are disadvantages to letting other people commit to trunk, it turns out :)06:58
Peng_Don't do what? threading.local?07:00
lifelessPeng_: create a transport in thread a, use in thread b07:01
lifelessPeng_: when thread a may still use it07:01
pooliespiv, igc, do either of you want a brief call?07:08
igcpoolie: would tomorrow morning be ok?07:08
igc10-ish say?07:08
pooliefine with me07:09
pooliejust go ahead and call if you like07:09
vilahi all07:19
mthaddonerm, any idea why the main links for downloads, etc for bzr1.16 are for the edge version of launchpad?07:25
pooliehello mthaddon07:25
mthaddonhi poolie07:25
poolieand hello vila!07:25
pooliewhere?07:25
pooliei mean which links?_07:25
mthaddonhttp://bazaar-vcs.org/Download07:25
mthaddonfirst links next to "Source of the stable release for any platform"07:26
pooliei guess jml or somebody just copied the links07:31
jmlyeah, I copied them from the commented out lines in the wiki source07:32
jmlI guess they should be production links.07:32
poolieis fixed07:33
jmlthanks.07:41
* davidstrauss is about to complain.07:42
davidstraussWhen are we getting fresh OS X .dmg files?07:42
davidstraussI'm happy to build 10.5 ones if I can get instructions.07:43
pooliedavidstrauss: there were instructions in the thread about this the other day from jfroy07:44
pooliewant to give it a try? you'd win acclaim throughout the land07:44
davidstrausspoolie: Have a link?07:45
davidstrausspoolie: just found it07:45
mneptokyou 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
davidstraussmneptok: :-P07:48
mneptok*muah* :)07:48
pooliewell, there is that07:48
pooliedon't even think about fixing openbsd selftest :)07:48
mneptokpoolie: i owe the list an e-mail, which will be sent when i return from .fi07: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
davidstrausspoolie: Will anyone care if I drop rebase, qbzr, and looms from the OS X build?07:57
pooliei think some people will07:57
poolieit might still be useful though at least as an intermediate step07:57
bialixqbzr require PyQt4 and there are many questions from mac users about installing this GUI toolkit.08:01
bialixso, bundling qbzr without PyQt is problem for the users08:02
bialixthat said: I think if you drop it, not so many people will complain08:03
=== mthaddon is now known as afk
=== RAOF__ is now known as RAOF_13
=== RAOF_13 is now known as RAOF
davidstrausspoolie: The package is building now, including all the same plugins.08:41
lifelessdavidstrauss: have you update to loom trunk?08:45
davidstrausslifeless: yes08:45
lifelessdavidstrauss: cool08:45
davidstrausslifeless: I saw the commit about 1.16 compat08:45
lifeless:)08:45
* lifeless goes to organise dinner08: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 bzr08: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. :D08: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. :D08: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
davidstraussAnyone 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 dinner09:19
Peng_Remote pushes might be different, of course...09:19
lifelessthere is a critical bug open about IDS being used for bzr+ssh09:20
lifelesstill thats closed remote pushes will be rather different09:20
Peng_I'm assuming it's not "good" different... :P09:20
lifelessstewart_: file a bug on bzr-gtk09:20
vxnickdavidstrauss: I will09:27
davidstraussvxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip09:28
vxnickthanks09:28
vxnickdavidstrauss: doesn't look like it's overwritten my previous bzr - where does it install bzr to?09:30
davidstraussvxnick: should be /usr/local/bin09:30
vxnickthat's showing me as 1.14.109:31
davidstraussoh, that's cute09:33
davidstraussit installed everything to /09:33
vxnickhaha09:33
vxnickgot an uninstaller for it/09:33
davidstraussvxnick: just look in / by date09:34
vxnickalrighty09:34
davidstraussi'll fix the installer09:34
davidstraussvxnick: Rebuilding the installer now09:45
vxnickdavidstrauss: nudge me when ready09:45
davidstraussvxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip09:52
vxnickdavidstrauss: thanks09:52
davidstraussvxnick: I've verified that it installs the right places now09:52
vxnickdavidstrauss: seems to work fine :)09:54
davidstraussvxnick: cool09:54
vxnickdavidstrauss: are you the maintainer for the mac images?09:54
davidstraussvxnick: Installing to / is such an amazingly dumb default09:54
vxnick:P09:54
davidstraussvxnick: No, just someone frustrated with the slow updates and probably taking over09:55
davidstraussvxnick: But I am not a Mac developer, just a user. So this is my first OS X installer build.09:55
vxnicksounds good09:55
vxnickyou did good09:55
davidstrauss:-)09:55
vxnickI was looking for a 1.16 build09:55
davidstraussvxnick: I do maintain RPMs09:55
davidstraussvxnick: And have for a while09:56
vxnickcool09:56
davidstraussvxnick: Making my first Mac installer is enough for one night I think. Bedtime for me.09:57
vxnick:)09:58
davidstraussvxnick: I've made some minor tweaks to the installer to fix man paths, but I haven't uploaded an update yet10:03
vxnickoh, nudge me as usual then10:03
davidstraussvxnick: Contact me on IRC if you run into any issues10:04
vxnickwill do10:04
davidstraussvxnick: I won't update any more tonight10:04
vxnickno worries10:04
davidstraussvxnick: Do you work for Canonical?10:04
vxnickdavidstrauss: nope10:04
davidstraussvxnick: Just a bzr+launchpad user?10:04
vxnickdavidstrauss: that's right :)10:04
davidstraussme too10:05
Hamarynsping gmb10:05
Hamarynshé jelmer, is het gelukt om Trac naar Launchpad te migreren?10:06
LarstiQHamaryns: in what sense?10:22
HamarynsUm, 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 problem10:23
LarstiQHamaryns: ah, jelmer doesn't seem to be done with that yet10:28
HamarynsI’m onto it with Graham right now, actually10:44
Hamarynskeep an eye on https://answers.edge.launchpad.net/malone/+question/6986410:44
=== Kissaki^0ff is now known as Kissaki
=== Hamaryns is now known as Hamaryns|weg
=== Hamaryns|weg is now known as Hamaryns
lifelessgnight13:00
awilkinsjelmer: Is there any reason why --2a isn't compatible with bzr-svn?13:06
jelmer_awilkins: 2a is compatible with bzr-svn13:07
jelmer_Hamaryns: the actual import hasn't happened yet13:07
jelmer_Hamaryns: but obtaining the xml did13:08
awilkinsjelmer: Specifically ; as a test I upgraded a --1.14-rich-root repo to 2a.. I think it make have halted silently though13:08
Hamarynsright, I am in the same phase now, I mailed the xml file to graham binns, waiting for him now.13:08
awilkinsjelmer: I'll try it again13:09
jelmer_awilkins: during "bzr upgrade --2a" you mean?13:09
awilkinsjelmer_: Yes, I think it may have halted there13:09
awilkinsjelmer_: The next thing to try is to pull it from the SVN repo into a fresh 2a repo13:10
awilkinsjelmer_: After I'm getting a "NoSuchRevision" error for what I presume is the tip revision of the branch concverned13:10
jelmer_awilkins: and into a 1.9-rr repo works?13:11
awilkinsawilkins: This was a 1.9-rr upgraded to 1.14-rr13:11
awilkinsI'm trying upgrading again13:12
awilkinsjelmer_: This repo has some very large revisions in it13:12
awilkinsjelmer_: I think it halted during a repack13:13
jelmer_awilkins: that's all inside of bzr itself; the NoSuchRevision error would be a bzr-svn bug though13:25
jelmer_awilkins: are you running 0.6 ?13:25
awilkinsjelmer_: 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 bug13:26
awilkinsI'll try it again, I deleted the repo and I'm converting again from the backup13:27
awilkins(taken immediately before conversion)13:27
awilkinsAs long as it's not a bug related to subvertpy I can try updating my bzr-svn13:28
awilkinssubvertpy is a PITA to build on win3213:28
jelmer_you shouldn't need a newer subvertpy13:30
awilkinsjelmer_: Aha, it halted during repacking inventories13:33
awilkinsjelmer_: No stacktrace either13:33
awilkinsSo not a bzr-svn bug13:33
* awilkins tries pull-from-scratch13:35
zarqhm, gcc on rhel 4.8/itanium is taking forever (over 12 minutes now) to compile _dirstate_helpers_c.c when i do easy_install bzr13:37
awilkinszarq: It should take a few secnds13:38
awilkinszarq: And that's exaggerating13:38
zarqi'll try to install 1.1513:39
zarq1.13 installs fine, 1.14 1.15.1 and 1.16 take "forever" to build13:42
awilkinsIt might be some quirk of Itanium I suppose13:44
vilajam: ping13:55
bialixigc: ping13:59
igchi bialix13:59
bialixwhat is your timezone?13:59
bialixre your latest change in bzre (revno 108): IIUC std_profile xmls always should be installed with sources?14:00
bialixigc: if std_profile is must have then we have to add them to setup.py and windows installer14:02
igcbialix: ah ok, I wasn't sure seeing it's not a 'package', just a directory14:02
igcbialix: I'll do it now ...14:03
igcbialix: do I update the packages list in setup.py?14:03
bialixin setup.py you need to use package_data14:03
igcok14:03
igcbialix: and in the installer, what there?14:04
bialixsection [Files], but installer I can update myself14:04
bialixigc: I think Nick Allen should have separate team for qbzr-eclipse14:05
bialixMay be we want in the future to create big umbrella team for all qbzr-related things... I dunno14:05
igcbialix: I'd like a bzr-desktop team myself, including qbzr, bzr-gtk and bzr-ide-integration14:06
igcbialix: we need to get more consistency across UIs I think14:07
igcbialix: and many topics are about design, not the technology14:07
bialixyes14:07
bialixigc: good news: translation template is imported! https://translations.launchpad.net/bzr-explorer14:14
bialixigc: new bzr explorer icon in LP is funny :-)14:22
igcbialix: the feet were just too fuzzy :-)14:22
igcbialix: and my daughter, who put both together, preferred the new one14:23
bialixyeah, this one has more positive energy14:23
bialix I really like it14:23
bialixit's funny and positive14:23
bialixbut your slogan: "is for human beings" ;-)14:24
bialixperhaps now you would add: and for extra terrestials too!14:24
bialix:-)14:24
ddaaWho said aliens are not human beings?14:24
ddaaXenist!14:24
bialixWell, I never saw them14:25
jimmy_deanIs 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
bialixhow can I know about them?14:25
bialixjimmy_dean: yes and no14:26
ddaajimmy_dean: you appear to be requesting what we call "nested tree" tracking.14:26
jimmy_deanyes :)14:26
ddaaWhich is not (yet) in core.14:26
jimmy_deandoes a master branch know about sub branches14:26
bialixthere is poor man emulation available in plugin14:26
jimmy_deanis it in the works?14:26
ddaaIt's been in the works for years.14:27
jimmy_deanoh really, what's the name of that plugin?14:27
bialixscmproj14:27
ddaajimmy_dean: the person you need to harass about it is abentley.14:27
jimmy_deanlol, ok14:27
bialixharass about nested trees14:27
jimmy_deanthis would prove extremely useful for how we use bzr at the company I work for14:27
* ddaa nods enthusiasticly14:28
jimmy_deanI'm surprised that it's not requested more often14:28
bialixevery day or so?14:28
jimmy_deanoh really, wow14:28
bialixevery week -- for sure14:29
jimmy_deanso is abentley the only one working on this functionality?14:30
jimmy_deandoes he need some help?14:30
abentleyjimmy_dean: I'm not currently working on this functionality.14:30
jimmy_deanok, so this functionality is currently abandoned?14:31
bialixI don't think so14:32
ddaaI guess it's "dormant".14:32
ddaaAnyway, scmproj should be as good as what you can get from any other DVCS.14:32
abentleyjimmy_dean: It's on hold while I work on some other things.14:33
jimmy_deanok14:33
igcnight all14:33
jimmy_deanabentley: thanks for letting me know14:34
bialixigc: bye14:34
jimmy_deanso how many active core developers are there on bzr, is it a project that needs some help?14:34
bialixI think so14:36
jamvila: pong14:36
bialixhello jam14:37
jammorning bialix14:37
bialix:-)14:37
ddaaThere 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
bialixit's closer to evening there14:37
bialixjimmy_dean: there is a lot places where one can help14:38
ddaajimmy_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
abentleyddaa: We are stuck at the design stage.  Coding help is not useful.14:40
ddaaThen 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
abentleyddaa: I have written plenty of code, and it has not yet been merged.  Code help is not useful.14:42
ddaaOk.14:43
LenzGrjelmer: Around?14:49
jimmy_deanok, maybe I could start looking at some bugs14:49
jimmy_deansince I'm an experienced coder, but am relatively new to Python14:49
jimmy_deanI'm a C/C++ guy mainly14:50
* LenzGr tries to compile subvertpy for bzr-svn, but gets compile errors14:50
jelmer_LenzGr: hi14:54
LenzGrjelmer_: 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: sure14:55
LenzGrok, one sec...14:55
LenzGrjelmer_: http://paste2.org/p/27981314:56
LenzGrjelmer_: This is subvertpy-0.6.0, subversion-1.6.2 and python-2.5.214:57
jelmer_LenzGr: does /usr/include/subversion-1/svn_props.h contain a definition for SVN_PROP_REVISION_LOG ?14:58
LenzGrjelmer_: Yes:14:58
LenzGr446:#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 release14:59
jelmer_LenzGr: any chance you can try 0.6.8 ?14:59
LenzGrjelmer_: Oh, sure! Weird, I wonder where I got that one from...15:00
ddaajelmer_: why "0.6"? Because you thought "Hm, I guess it's a bit more than halfway there", or something else?15:00
LenzGrjelmer_: 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 out15:01
jelmer_ddaa: bzr-svn 0.6.0 was the first to use an external subvertpy15:02
ddaaOk.15:02
LenzGrjelmer_: 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: ah15:02
jelmer_LenzGr: perhaps I should reverse the ordering15:02
LenzGrjelmer_: I think that would make sense :)15:03
LenzGrjelmer_: 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: cool15:05
abentleyjam: is there something I can do to help you diagnose this inconsistency?15:45
abentleyjam: 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
jamabentley: 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 116:10
jamand you should certainly realize that 190 revs is easy to hit with 10 mainline :)16:10
jamwe *could* be hitting too much, but that would still be a bug in the per-file code16:10
abentleyjam: 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
jamabentley: can you link the bug report again16:11
abentleyjam: which bug report?16:11
jamabentley: whatever the traceback was16:12
jamsorry, email16:12
jambrb16:12
jamabentley: so it is possible that it is the new streaming fetch code16:12
jamwhich tries to fill in things when it thinks other things are missing, etc.16:12
jamcertainly we might be looking at more than before16:12
jambecause the CHK pages give us more neighbors16:12
jamthan the minimal inventory XML delta16:13
abentleyjam: https://pastebin.canonical.com/18881/16:13
abentleyjam: It's also possible that the faulty revisions were because PQM was running an old bzr.16:13
jamso the error is saying that the local repo is claiming 1 parent, but the merge source is claiming 216:14
abentleyjam: I was pulling lp:~launchpad-pqm/launchpad/devel into my local, reconciled, repo.16:15
jamabentley: well one thing we could try16:15
jamr = bzrlib.repository.Repository.open('local')16:15
jamr.lock_read()16:15
jamt = r.texts16:15
jamkeys = t.keys()16:15
jamparent_map = t.get_parent_map(keys)16:16
jamremote_r = ...16:16
jamrepeate16:16
jamand then compare remote_parent_map with parent_map16:16
jamsee how bad things are16:16
jamthere should be some keys missing on both sides16:16
jampresent entries should have the same value16:16
jamit *sounds* like ghost issues16:16
jamthough you shouldn't have ghosts with bzr revisions16:17
jam(versus Arch)16:17
jamahh....16:17
jamand the new code notices that the inventories are different16:17
jambecause they have different per-file info... perhaps16:17
pygivila: poke16:18
abentleyjam: Working on it..16:18
jamabentley: if you have 2 repositories with different per-file graph, that might cause the inventories to have different last-modified settings16:20
jamif that was true16:20
jamthen "derived" inventories would have a different entry in the inventory16:20
jamand that would show up during the inventory-diff stage16:20
jamand tell us to fetch that record16:20
jamwhich then gives different content, and boom16:21
jam(versus XML formats, that assumed the XML line-delta held all the information about what was needed to be fetched)16:21
jamthough... the last modified revision should be known, since that is the text key we are using for insertion...16:21
jamso maybe I'm off16:21
abentleyjam: So if I've done this right, there are 2918 inconsistent texts between the two repos.16:25
jamouch. that seems like a lot16:26
abentleyhttps://pastebin.canonical.com/18883/16:26
vilapygi: Hi mario16:26
abentleyjam: It's a lot, but it's ~1% of the total texts.16:27
jamabentley: it looks like you did it correctly16:27
pygivila: are you busy? I want to discuss bzr-gtk :)16:27
jamby my read16:27
vilapygi: yeah pretty busy :-/ Let's try anyway16:29
pygivila: basically, bzr-gtk is in problems IMHO16:30
vilapygi: define problems :)16:30
pygiSzi doesn't have time, Jelmer either, and I didn't have time even to fix that path issue and/or look at that dbus stuff16:30
jamand at least all the ones I've seen so far say that your local repo claims more revs than the remote16:30
pygivila: no release for a year? :p16:30
jamwell, more parents16:30
abentleyjam: I don't think so.  My repo is claiming (('bugsemailaffectspath-20070306155409-3k9ueivfh05v4v3b-1', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),)16:31
jamabentley: sorry, I read it backwards16:31
jamparent_map is the local one16:31
abentleyjam: 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
vilapygi: ha, right, let's look at the active devs list to find a new RM then... abentley (oops), beuno (oops), garry (oops),16:33
vilapygi: :-/16:33
pygivila: I'll have more time starting mid-next month so I'll at least fix windows problems16:34
jamabentley: do you have the XML versions of these repos?16:34
beunovila, I'll be happy to work out a relaese for bzr-gtk after I manage to get loggerhead out the door  :)16:35
vilabeuno: err, we want it for yesterday, not next year :-D16:35
abentleyvila: 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
abentleyvila: I mean bzr-gtk16:35
vilaabentley, beuno : I was *joking* I didn't think any of the ones I mentioned *can* actully become RM16:36
abentleyjam: 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
vilajelmer: you should know better than me if phanatik intend to do a bzr-gtk release shortly16:38
* vila kicks NFS a..^W head for working in all configurations except the one needed right *now*16:39
abentleyjam: Ah, fun!  All these bad texts contain 'abel' in their revision-id.16:40
abentleyjam: This suggests abel was using an old bzr, and it's not likely that current bzrs are broken.16:41
abentleyjam: 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
abentleyjam: 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
jamabentley: my guess is that his *derived* inventories are showing different content17:01
abentleyjam: 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
abentleyjam: Could we indirect through an xml-based repo?  Or use a more generic fetch codepath?17:05
jamhmm...17:06
jamyou could comment out the GCCHK stream source17:06
jamin repofmt/groupcompress_repo.py17:06
jamwell, comment out returning it from _get_source17:06
jamthat would at least be something to try17:09
jamit would go back to the "generic" path17:09
jamthough I can't swear by it17:09
jamthe other possibility is to force the InterDifferingSerializer17:09
jamwhich I think would be the most likely to work17:09
abentleyjam: Cool, I'll try it.17:10
abentleyjam: No joy the first approach: https://pastebin.canonical.com/18887/17:14
abentleyjam: 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 +000017:16
jam+++ bzrlib/repository.py        2009-06-23 16:16:28 +000017:16
jam@@ -3489,6 +3489,7 @@17:16
jam     @staticmethod17:16
jam     def is_compatible(source, target):17:16
jam         """Be compatible with Knit2 source and Knit3 target"""17:16
jam+        return True17:16
jam         # This is redundant with format.check_conversion_target(), however that17:16
jam         # raises an exception, and we just want to say "False" as in we won't17:16
jam         # support converting between these formats.17:17
jamsorry for the spam17:17
abentleyjam: No joy: https://pastebin.canonical.com/18891/17:21
abentleyjam: 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
abentleyjam: does that seem like a good thing to you?17:38
SamBis there a way to ask bzr what file defines a given command?17:41
jamabentley: so... not really, but we are doing so because there is a discrepancy, which *does* seem like a good thing to check17:45
SamBjelmer: 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
abentleyjam: 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
abentleyjam: or at least, they don't *introduce* inconsistent parents.17:53
jamso is any of this actually available?17:53
abentleyjam: The launchpad branches are not publically available.  Is that what you mean?17:54
jamabentley: right, so *I* don't have the easy ability to look at these and see what it thinks needs to be transferred17:54
jammy guess is that these revs say something different than the parent revs17:54
abentleyjam: 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
jamI do have access to devel17:57
jamabentley: if you want you can push the other to devpad17:58
abentleyjam: pushing...18:00
kirklandjelmer: hey, vcs-imports question again18:13
kirklandjelmer: i'm still not having much success at all with the launchpad auto vcs imports git->bzr for qemu18:13
kirklandjelmer: however, i do have fast-export and fast-import working pretty reliably18:14
kirklandjelmer: i'm wondering if it would make sense at this point just to cronjob something on my end18:14
kirklandjelmer: that would do a fast-export, fast-import, and push periodically18:14
kirklandjelmer: at least until LP gets its vcs importing sorted out18:14
=== mario_ is now known as pygi
=== mthaddon is now known as afk
abentleyjam: The faulty revisions were committed with whatever preceeded 1.16rc1 in the bzr beta PPA.18:32
jamabentley: where is it pushed to?18:41
abentleyjam: /home/abentley/branches, but the rsync hasn't completed yet.18:43
kirklandjelmer: also, i think you can delete lp:~jelmer/qemu/kvm-git-import-HEAD and lp:~jelmer/qemu/git-import-HEAD19:03
mxpxpodjelmer: ping?19:16
abeaumonthmmm, bzr is taking quite a bunch of resources here: 21683 alfredo   20   0 2936m 1.6g 1816 R   95 40.8   1037:31 bzr20:07
abeaumont 20:07
abeaumontis there any way to improve bzr-svn's performance?20:08
dashHmm20:44
dashi'm trying to envision a workflow for loom20:44
dashi 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
dashso 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
IsaiahIs 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 ignore21:56
beunoIsaiah, just don't add the other files?21:57
abentleyjam: 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
IsaiahAh cool, that works! Thanks Peng_ and beuno :)22:02
jamabentley: I think you can do that sort of thing differently, but the check you are trying to do is there22:04
jamnamely, if we have it, skip it22:04
abentleyjam: What's a better way of doing it?22:05
lamalexCan anyone help me with bzr bisect22:05
lamalexthe --help is ambiguous22:05
jamabentley: if self.get_parent_map(key): continue22:05
jamwell22:05
jamif self.get_parent_map([key]): continue22:05
jamthough that may do something based on fallbacks22:06
lamalexIf 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 no22:06
lamalexbzr bisect yes [-r rev] The specified revision (or the current revision, if not given) has the characteristic we're looking for,22:06
lamalexIs the characteristic im looking for the bug, or not the bug22:06
dashyou're looking for where a bug was introduced22:07
dashso 'yes'22:07
lamalexthanks22:08
abentleyjam: It would be nice to be able to predict the text keys before drinking the stream.22:12
jamabentley: sinks aren't supposed to22:12
jamas it sort of violates the "streaming" principle22:12
jamas would having the source peak at the target22:13
jamat least, that's what I've been told22:13
abentleyjam: I know that it does, but you can see why it would be useful.22:13
jamabentley: sure22:13
abentleyjam: Still pushing the repo, by the way.22:13
jambig repo, it would seem22:13
lamalexwow, bzr bisect fails22:13
abentleyjam: .3 G, and twice that with obsolete_packs.22:14
=== mwhudson_ is now known as mwhudson
=== nevans1 is now known as nevans
lifelessoioioi23:05
beunogood morning lifeless23:05
=== Kissaki is now known as Kissaki^0ff
lifelessjam:23:14
lifelessjam: https://devpad.canonical.com/~spm/bzr-logs.tgz23:14
mtaylorlifeless: morning!23:25
mtaylorlifeless: 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
mtaylorI mean, it's obviously not breaking anything - but it is annoying to see _every_ time I do anything23: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
mtaylorPeng_: nope23:27
Peng_Argh. I knew I should've sent a patch for that.23:27
mtaylorheh23:27
* mtaylor _really_ hates stack traces that swallow incoming stack23:28
Peng_mtaylor: I think bzr-svn or bzr-git imported bencode, and a development version fixes the deprecation warning.23:28
Peng_fwiw23:28
mtaylorPeng_: cool23:28
mtaylorPeng_: I don't have bzr-git - but I do have bzr-svn23:28
mtaylornot that I really need it atm...23:29
Peng_Anyway, it's only a guess at what's causing it.23:29
garyvdmHi all23:30
lifelessmtaylor: edit that file23:30
Peng_That part of bzr-svn probably shouldn't get imported unless you're actively using bzr-svn.23:30
lifelessmtaylor: on that line is a function call23:30
lifelessadd stack_level=2 to the call23:30
Peng_stacklevel=223:31
mtaylorlifeless: symbol_versioning.warn(dep_warning, DeprecationWarning, stack_level=2)23:31
mtaylorah23:31
Peng_No underscore.23:31
mtaylorHAHA23:31
mtaylorit's a local plugin23:31
mtaylorthanks guys!23:32
lifelessmtaylor: :)23:32
mtaylorlifeless: /home/mordred/.bazaar/plugins/mysql/emailer.py23: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
mtayloractually... since I don't hack on mysql internals anymore - I might just uninstall the plugin...23:33
Peng_Or that.23:33
lifelessdrizzle isn't mysql?23:33
mtaylorgod no23:33
lifelessYHBT HAND HTH23:33
lifelessah, the sweet smell of trolling in the morning23:33
mtaylormmm23:33
lifelesswhere are those bindings in your stack now?23:34
mtaylorooh. actually, that might be something I can whip up while sitting here in this conference...23:34
mtaylorI'm certainly not actually getting anything out of the talks23:34
lifelesswhat conf?23:34
mtaylorlifeless: velocity23:35
mtaylorlifeless: I'm speaking tomorrow, so I'm here today23:35
lifelessits a LEAN conf or something?23:35
mtaylorlifeless: does mainline bzr have default hooks for not commit conflict markers yet?23:36
mtaylorthat's the main reason I was keeping the mysql plugin around23:36
mtaylorlifeless: it's an O'Reilly conference about Scaling23:37
lifelessexpand on ' default hooks for not commit conflict markers'23:38
mtaylorlifeless: if you ran bzr resolve on a merge conflict, but you actually didn't catch all of the conflicts23:39
lifeless'bzr resolve foo' ignores the file content.23:39
mtaylorlifeless: so somewhere in your code something is broken and has a <<< MERGE-SOURCE (or whatever the marker is)23:39
mtaylorright23:39
lifeless'bzr resolve' scans all conflicted files and resolves those that look clean23:39
mtaylorok.23:40
lifelessmoral of the story, use 'bzr resolve'23:40
mtaylorwell, yeah. I like doing that23:40
mtayloryou know when that doesn't work?23:40
mtaylorwhen 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 to23:40
mtaylorI have to resolve each of those individually :(23:40
lifelessyes23:41
mtaylorbut I can get over that23:41
lifelessits a weak point23:41
mtaylorwhile I'm whinging ...23:43
mtaylorunshelve           Restore shelved changes.23:43
mtaylorunshelve1          Restore shelved changes. [bzrtools]23:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!