briandealwisI'm having strange locking problems on MacOS X where bzr is complaining about a lock being held — but it's the same process00:04
briandealwisThis is with 2.3.000:04
briandealwisI have a branch bound to another branch, that is itself bound to another branch00:04
briandealwisIt's complaining trying to acquire a lock to the third branch00:04
spivThat sounds like a familiar issue00:05
spivI'll see if I can find a bug report about that00:05
mgzIf there's something horribly wrong in my last post to the list, someone please correct me.00:07
spivbriandealwis: it might be related to https://bugs.launchpad.net/bzr/+bug/412223, but I think there's something specific to 2.3.0 because I think there's been a small spike in reports of it happening00:09
ubot5Ubuntu bug 412223 in Bazaar "bzr up locks master branch" [High,Confirmed]00:09
spivbriandealwis: I can't find an obvious bug about it though, so I guess file a new report.  Maybe we've regressed in how we handle a bound branch of a bound branch?00:10
briandealwisspiv: I don't think that's right.  At least all my branches are local and fully-qualified00:10
briandealwisAnd I just unbound the second level, and it's still occurring.00:10
briandealwisspiv: hmm, I'll have to dig into this tomorrow.  It doesn't seems to only happen with a particular branch pair00:14
spivbriandealwis: ok.  I think the contents of the .bzr/branch/branch.conf files would be particularly interesting00:15
briandealwisspiv: the only thing that's different is that I have some post-commit hooks to trigger a hudson build00:15
spivOh, and the traceback, of course :)00:16
briandealwisHow do I force a branch back to a previous version?  "bzr pull . -r −1" doesn't seem to do it…00:21
lifelessjelmer: when you are around00:22
ubot5Ubuntu bug 728691 in loggerhead "loggerhead NoSuchRevision: KnitPackRepository exception" [Undecided,Incomplete]00:22
briandealwisah, —overwrite it the key: "bzr pull . —overwrite -r −4"00:25
spivmgz: replied :)00:27
spivbriandealwis: yep, --overwrite00:27
jelmerlifeless: hi00:28
jelmerlifeless: hmm00:28
mgzspiv: aha, there was a generic method, thanks. what's still not clear to me is what initialisation steps need/should really be done first.00:29
jelmerlifeless: Is there actually any reason for that method to use revision_trees() rather than get_revision_delta() ?00:29
lifelessjelmer: good question00:29
lifelessjelmer: that may be addressed by jams historydb work00:29
spivmgz: just bzrlib.initialize(), IIRC00:30
lifelesswith bzrlib.initialze(): do stuff00:31
briandealwisspiv: I put the branch.conf and .bzr.log at http://pastebin.com/cmv6ZWqv00:33
briandealwisspiv: I thought it might be related to a plugin, but doesn't seem to be00:33
mgzis that true even with hooks? you can't use run_bzr like that because it doesn't know about the commands, do any of the command objects themselves depend on hooks that aren't installed by default?00:34
lifelessmgz: there is an entry point for running commands that adds the bzr-internal command hooks00:35
lifelessmgz: its what the bzr script calls00:35
mgzbut it's not part of initialize.00:36
lifelesswhich is called by run_bzr_catch_errors00:37
lifelessand run_bzr-catch_user_errors00:37
lifelesswhich is called by main()00:38
lifelessmgz: start with bzrlib.commands.main()00:38
mgzone of the important bits there seems to be _register_builtin_commands which doesn't have a public alternative as far as I can see.00:39
spivbriandealwis: hmm, could you add -Dlock to the command line and paste the .bzr.log from that?  That should tell us where the locking is happening.00:39
lifelessmgz: thats more plumbing :)00:39
lifelessmgz: if you want to use the inbuilt command dispatch, calling main() is the key00:40
briandealwisspiv: log at http://pastebin.com/68x4VM1n00:42
briandealwisspiv: oops, that didn't work00:42
briandealwisspiv: sorry, try this: http://pastebin.com/JptmhQUT00:43
ovnicrafthello, i found this plans http://doc.bazaar.canonical.com/developers/colocated-branches.html for 2.4 what is the state of this ?02:36
spivovnicraft: jelmer has the most up to date info I think02:47
spivovnicraft: IIRC, most if not all of the core infrastructure in the code now exists02:48
spivovnicraft: so what's left is mainly the UI02:48
ovnicraftwe have problems with all modules in our repo each module/directory has dependencies each other i was thinking in a module to manage this and canc clone just the dep02:54
ovnicrafti need colocated for this ?02:54
beunolifeless, ping02:57
lifelessbeuno: hi02:58
beunolifeless, hey!02:58
beunoso, I got into loggerhead hacking again02:58
beunotrying to get this tarball thing proposable02:58
beunoI've got it working02:58
lifelesshave you looked at launchpad_loggerhead? thats the glue we use to run lh in lp02:58
beunonow, I'm trying to figure out what the best way to make it easy for LP to turn it off02:59
beunoI haven't in 2 years I think02:59
spivovnicraft: there are some existing plugins that may help you02:59
lifelessbeuno: you should02:59
beunolifeless, where can I grab that from?02:59
ovnicraftspiv, maybe a clue03:00
lifelessbeuno: because we'd turn it off from there, whatever the mechanism - we'd be adding the hook or $whatever03:00
lifelessbeuno: lib/launchpad_loggerhead03:00
spivovnicraft: bzr-colo, bzr-colocated, bzr-scmproj03:00
beunolifeless, that assumes I have the LP tree  :)03:00
lifelessbeuno: yes, yes it does03:00
beunolifeless, lets pretend I don't03:00
lifelessbeuno: we have loggerhead running on lp03:01
lifelessbeuno: I hear you can browse via it03:01
ovnicraftspiv, yes i am checkin' bzr-colo so i need your opinion here to manage this if i am clear03:01
beunosounds like en evil technology03:01
ovnicraftmanaging dependencies using colocated and write a plugin03:01
lifelessovnicraft: easiest way to make it fast is to setup one, or perhaps several, shared repositories03:02
lifelessovnicraft: then use bzr-scmproj - the repository will cache data locally for you03:03
spivovnicraft: I agree with lifeless; my guess is bzr-scmproj will either do what you want or be a good starting point for building what you want.03:04
ovnicraftsound ok  i want to do something like bzr branch lp:project --myproj-modulename03:05
ovnicraftand maybe gets another modules03:06
ovnicraftlike bzr pull --myproj-anothermodule03:06
spivovnicraft: I wouldn't think colocated branches would be a natural fit for managing a collection of different modules and their dependency relationships.  It seems to me that colocated branches are better suited to tracking multiple versions of a single project (e.g. to have all of bzr 2.0, bzr 2.1, bzr 2.2, bzr 2.3 and bzr trunk branches).03:06
ovnicraftin that ways looks better so the problem is when cloning (if plugin exists) need just a copy from module and their deps03:08
ovnicraftand can pull more modules03:09
beunolifeless, up for a loggerhead review?03:49
beunoanyway, sleep now03:52
beunojam, if you happen to be around, https://code.launchpad.net/~beuno/loggerhead/export-tarball/+merge/5279703:52
beunothis branch has things committed it shouldn't03:52
beunogar... in the first revision03:53
beunook, really sleep now04:07
* beuno waves04:08
spivvila: hmm, 16 package imports failing due to LockContention?  That seems odd.04:30
=== Ursinha is now known as Ursinha-afk
vilaspiv: not fully there yet, but didn't bzr get upgraded on jubany ?06:43
vilaspiv: there have been a few bugs around LockContention lately (one in particular has to do with connection reuse in builddeb ?)06:49
vilaok, I'm in, spiv ?07:22
spivvila: there's an rt for upgrading bzr on jubany, but it hasn't been done yet IIRC07:39
spivrt 4439807:39
vilabzr version says 2.3b5 (which in itself is pretty weird, why b5 ???)07:40
vilaha right, so this points to bug #726854 which indeed mentions reusing transports (I didn't dig that though)07:43
ubot5Launchpad bug 726854 in SABnzbd "Upgrading queue from 0.5.x to 0.6.0 can fail" [Critical,Fix released] https://launchpad.net/bugs/72685407:43
spivvila: specifically I saw LockContention on a local branch, though07:44
spivvila: http://package-import.ubuntu.com/status/udev.html#2011-02-24%2020:39:43.44441007:44
vilagrr bug #72658407:44
ubot5Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/72658407:44
vila*local* branch ? Urgh07:45
maxbvila: Hi. I think I'll rename bzr.webdav now, since there have been no objections07:50
vilamaxb: please do ! Sorry I didn't find the time to do it myself :-/07:50
maxbnot a problem07:51
* vila is still fighting to unbrick a natty vm...07:51
maxbnothing too vital trapped inside it, I hope?07:51
vilano, it's ok07:51
vilawhat is a 'held package' ?07:51
spivA virtual brick?07:51
vilaupdate-manager is telling me: E:Error,pkgProblemResolver::Resolve generated breaks, this may be caused by help packages...07:53
vilaspiv: :)07:53
maxbvila: A held package is one which has been placed on hold in aptitude or dpkg by the local sysadmin, to prevent automatic upgrades07:57
vilaurgh, I can't remember doing that, how can I find it or them ?07:57
maxbdpkg -l | egrep ^h07:58
vilaempty :-/07:59
spivI guess held packages aren't the problem then!07:59
maxbMy general advice on encountering any sort of dependency chaos is that the interactive curses mode of aptitude is a wonderful tool :-)07:59
vilaha, let me try that08:00
* vila restores last backup08:01
vilathe nice thing with vms is that they are easy to restore, just use the whole disk backup :)08:02
vilaok, that's 6GB, but still :D08:02
jammorning vila, evening spiv08:27
vilahi jam08:27
mr-russout of curiosity, what tools to bzr developers use for development?  vi, eclipse or something else?08:30
lifelessmr-russ: depends on the dev08:37
lifelessmr-russ: most are vim, at least one is emacs08:37
jammr-russ: If I was using an idea, it would probably be Wing. Lots of good stuff there, but their VI-mode was lacking08:43
jamIt might have gotten better since08:43
jamit was a year or two ago08:43
jamIDEs can be great, but VIM just rocks as a text editor08:43
mr-russI've just never found a comfortable tools on linux that feels like I'm doing things fast.  vi is pretty good, but my skills ain't brilliant, especially with shortcuts for going into functions and back, like ctags08:44
jamor you're saying you know that but don't feel great with using it?08:45
jamOnce you have vim muscle memory, it is pretty hard to use another editor, IME08:45
sorenjam: I'd love to see you write code: wing - Galaga-like arcade game08:45
sorenAw, that's no fun at all.08:46
jamsoren: but yes, that would be pretty awesome08:46
jamsquashing bugs in real time, baby08:46
vilamaxb: unbricked ! I had to reinstall the vbox additions which confused me for a bit though08:57
vilamaxb: thanks for the aptitude trick !08:57
mok0"Branch to merge into, rather than the one containing the working directory." Does anyone understand that? I don't09:15
mok0(from bzr merge --help)09:15
vilamok0: yes, almost everybody :)09:15
vilamok0: by default you merge in the directory you're working09:15
mok0vila: ah, yes I see :-)09:16
mok0vila: that help text could be better though :-)09:16
vilamok0: if, for whatever reason, you want to merge into *another* directory than the current one, you use -d09:16
vilamok0: certainly09:16
mok0vila, I'd prefer (cd ../otherdir ; bzr merge )09:16
vilamok0: so you don't need -d09:17
mok0vila: right09:17
vilamok0: but if you have a good idea for a better phrasing, patch welcome !09:17
mok0vila: patch? That would take me an hour09:18
mok0vila: I can submit a bug09:18
vilabzr branch lp:bzr ; hack hack, bzr commit ; bzr push lp:~<lp_login>/bzr/better-merge-help ; bzr lp-propose ; done09:19
vilamok0: sure, a bug is a good starting point09:19
mok0vila: I could try. Never hacked on bzr before09:19
mok0vila: heh lp is down09:27
vilamok0: ooohhhhhh, paaaaaaaaiiiiinnnn09:27
mok0vila: actually, what I was looking for is a "dry-run" switch for merge09:28
vilamok0: db upgrade in progress, should be back in ~90 minutes at max :-/09:28
vilamok0: --preview09:28
vilamok0: http://identi.ca/launchpadstatus for tracking lp status09:29
mok0vila, oh, thanks. I got so puzzled at the -d switch I didn't discover that...09:30
vilamok0: :)09:30
vilamok0: almost all bzr commands accept a -d switch09:30
mok0vila: I am slowly trying to become a more sophisticated bzr user. Not doing too well ;-.)09:30
vilamok0: take your time ;)09:31
mok0vila: I guess the -h texts are not the best avenue for that endeavour09:31
mok0vila, will --preview give me an indication of potential conflicts?09:32
vilamok0: well, they should. They are supposed to help... May be not the newcomers that may be better served by http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html but still09:32
mok0Because sometimes I'd like to put off a merge if there are conflicts09:32
vilayes, --preview will tell you about conflicts09:33
mok0vila, I've read those docs many times09:33
mok0vila: but my brain is old and fragile09:33
vilayeah, brains tend to become fragile when you get old, but they are also supposed to be more effective ;)09:34
mok0vila: perhaps what I need is a reference-manual type document, with examples09:34
mok0vila: effective? I guess... I am still going pretty ok at 10% capacity :-)09:34
vilawow, indeed, if you're able to discuss with *me* at 10% capacity, that's surely a good sign :D09:35
mok0vila: the tutorials are fine for getting started, but they never give you the full story09:35
vilahttp://doc.bazaar.canonical.com/bzr.dev/en/user-reference/index.html then ?09:35
mok0vila, perfect! Bookmarked!09:36
vilahttp://doc.bazaar.canonical.com/bzr.dev/en/ is the starting point09:36
mok0vila, one problem I meet in my daily workflow is this:09:37
vilaor even http://doc.bazaar.canonical.com/en/ (except there is currently a bug there, 2.3 being the stable version, the links are valid, only the numbers are wrong)09:37
mok0I have upstreams subversion branch mirrored on LP. I have a packaging branch off that09:38
mok0upstreams branch contains a whole bunch of stuff that doesn't get into the distribution tarball ("make dist" tarball")09:38
mok0to avoid getting a huge .diff.gz file, I have deleted everything from the packaging branch that does not go into the dist tarball09:39
mok0that normally works fine, but when upstream has edited one of the "un-needed" files, I get conflicts09:40
mok0I just need to resolve them, but it is a drag09:40
mok0Most of the time, the merge goes smoothly, but I'd like to check if a merge would generate conflicts ahead of time. So perhaps --preview can help me there09:41
vilaThere are several works in progress to address that, including the ability to specify either globally or on a file-by-file basis that you don't care about modifications to deleted files09:41
vila--preview should help09:41
mok0vila: ultimately, we shouldn't have to rely on tarballs for source packages, but...09:42
vilayou should also be able to say 'bzr resolve --take-this <file>' to resolve the conflict where <file> is involved09:42
vilamok0: that's call UDD, see https://wiki.ubuntu.com/DistributedDevelopment09:43
* mok0 goes off to bzr reference manual to see :-)09:43
mok0vila: yeah, I've been tracking that now and then, but much of it goes over my head.09:43
vilamok0: then this needs to be fixed09:44
vilanot your head...09:44
mok0vila: It is my religious belief that the packaging branch should be a child of upstream09:44
mok0vila: and some of the current practices are not like that AFAIU09:44
mok0vila: as like having debian/ in its own branch09:45
vilamok0: <cough> I'm (still) not a seasoned packager myself, but I'd like to get there and yes, the idea is that upstream should be a parent branch09:45
vilamok0: yup, we hope to get away from this practice as soon as it becomes *easier* to *not* use it09:45
mok0vila: I also haven't grasped looms yet, which seems to be central in the whole patch thing09:46
vilamok0: looms are discussed indeed but needs some polish to be fully usable09:46
mok0vila: ... unfortunately 3.0 (quilt) seems to have consolidated the way patches are treated09:46
vilamok0: think of looms as a stack of branches with upstream at the bottom09:47
mok0vila: sort of like git?09:47
mok0git branches?09:47
vilano, git branches are more like colocated branches where you switch from one branch to the other without any enforced relationship between them09:48
mok0vila: I guess I should just try looms. I've put it off, because I've read (like you said) that looms "need some polish"09:49
vilacolocated branches help using a single working tree when ... it matters. It can be because it's expensive to maintain (lots of compilations), it can be a convenience09:49
vilamok0: they need polish for the udd case, I use them daily myself09:49
mok0I see09:49
mok0Perhaps I should just try them. Doesn't it add another layer of complexity?09:50
vilamok0: you can think of them as an alternative to quilt (IIUC) where each patch is turned into a branch (and as such get an history)09:50
vilamok0: it depends on your workflow09:50
mok0vila: hm, that sounds useful. I use quilt a lot09:50
mok0vila: I am patching upstreams code quite a lot, and I keep all my changes in quilt patches09:51
vilaI use looms when I want to work on a bug feature for a long time and create threads for pieces I can submit for inclusion in trunk09:51
=== Ursinha-afk is now known as Ursinha
mok0vila: threads? Uh-oh, another concept.. :-)09:51
mok0vila: so, can I use looms in one branch and not another?09:52
vilamok0: a loom is composed by threads, a thread is just a funny name for a branch but with a name and a position in the loom09:52
vilamok0: yes, you can go from branches to looms09:52
mok0vila: so looms replace branches?09:53
vilamok0: one part that need polish in looms is when you want to collaborate on looms, merging looms is... not implemented yet for example09:53
mok0vila: ah, so they're for personal use09:53
vilawell, technically they are a branch format09:54
vilamok0: in their actual state, they are safe to use for personal use, there are some rough edges when you try to share them09:54
mok0vila, so I can make a child branch and turn that into a loom?09:54
vilamok0: pipelines are an alternative that some people prefer09:55
vilabzr loomify09:55
mok0vila: and what will LP say to that?09:55
vilaFor example, when I start a loom, I do:09:55
vilabzr branch lp:bzr new-stuff09:56
vilacd new-stuff; bzr nick bzr.dev # to track trunk09:56
vilabzr create-thread stuff09:56
vilafrom there I have two threads in the loom, I'll use the 'stuff' one to develop my new feature and commit there09:57
vilawhen I want to resync with trunk I do: bzr switch bzr.dev ; bzr up-thread09:57
vilawhen I want to resync with trunk I do: bzr switch bzr.dev ; bzr pull -v ; bzr up-thread09:57
mok0vila: "up-thread" ?09:58
vilathe pull will update by base thread to the current version of trunk and 'up-thread' will merge my changes onto this new trunk09:58
vilait's a command provided by the loom plugin09:58
vilaand lp knows about looms so you can push there like any other branch09:58
mok0vila: it does sound a bit like a git-like  workflow09:59
mok0vila: beneath a bzr branch09:59
vilamok0: you mean rebase ?09:59
mok0vila: no, I mean like having a stack of branches in a single directroy10:00
vilaAFAIK with git you get a *set* of branches, not a stack10:00
mok0vila: ah yes, that's true10:01
mok0vila: so with threads, you can only merge "down" ?10:01
vilawell, up :)10:01
mok0vila: and when you do that, the stack becomes lower?10:02
vilawell, the pointer goes up10:02
vilaeach thread is fully included in the upper ones10:03
mok0vila: but the bottom two threads will then be identical?10:03
vilaif they are you use combine-threads to delete the upper one, it means you don't carry changes anymore in this thread10:03
vilait happens when the changes have landed on trunk10:03
mok0vila: It's starting to dawn...10:04
vilait's a bit like maintaining a series of patches except you keep track of the history (roughly)10:04
mok0vila: that sounds very useful10:05
mok0vila: I should "just try it"10:05
mok0vila: so I am maintaining my patches in quilt in the packaging branch. Where should I have the looms though? In "trunk" or in "ubuntu"?10:07
vilamok0: vast question :)10:08
mok0vila: I was afraid so :-)10:08
vilamok0: the current theory is that you work in a loom with the following threads (starting from bottom): upstream, debian packaging, ubuntu packaging10:09
vilanow, for the quilt patches, you can also add one thread by patch10:09
vilaand that's where the discussion is roughly as there are various ways to handle the quilt patches with or without threads10:09
mok0vila: but when you do "bzr builddeb" you need the debian/patches directory to be populated10:10
vilamok0: and I can't say much more on the topic as I don't know quilt :-/10:10
mok0vila: quilt just manages a stack of patches10:10
vilamok0: you'll need a better packager than me to answer this one ;D10:10
mok0perhaps bzr builddeb know how to deal with looms10:11
vilamok0: the idea is that it's better to work with the patches applied than working with diffs of diffs10:11
vilamok0: not yet (AFAIK)10:11
* maxb eeps at the size of scrollback.... what's the unanswered question, and can I help? :-)10:12
vilamok0: but the plan is to teach builddeb to (hand waving) make it easier :D10:12
mok0vila: I think just needs to try it10:12
vilamok0: maxb is a *far* better packager than me for one ;)10:12
mok0vila: that would be cool. But of course packaging policies are decided in Debians dungeons10:13
mok0maxb: we are discussing packaging using looms10:13
mok0maxb: and I am asking more questions than 20 geniuses can answer :-)10:14
maxbYes it's all a bit of an unresolved question10:14
maxbI think some people see a utopia where quilt series get mapped into looms, such that you keep history of the patch series too10:15
mok0maxb: I described my branchs 25 minutes ago (10:38 my time)10:16
maxb*gah*, I am being summoned afk, sorry10:16
mok0maxb: ah10:16
mok0maxb, let me copy-paste a bit10:16
mok0maxb, http://paste.ubuntu.com/578269/10:18
mok0maxb:  I also asked vila on advice for maintaining my patches and we discussed looms10:20
maxbOn the subject of the pastebin, that's a tricky one.10:29
maxbI think bzr core could use some way of being told that files are being deleted and you really don't care what upstream does with them from then on10:29
maxbHowever, you might be interested in using bzr-builddeb10:30
maxbIf, instead of merging normally from the upstream import, you use its merge-upstream command, it will not only help you track what is in the tarballs, but will embed pristine-tar metadata in the packaging branch such that original tarballs can be rebuild from it10:31
maxbIt goes like this:10:31
maxbbzr merge-upstream --version upstream-version path-or-url-to-upstream-tarball path-or-url-to-upstream-import-branch -r tag:the-tag10:32
maxbWhen you do this, bzr-builddeb will commit the contents of the tarball, associating it as a merge commit with the revision in the upstream import branch specified by the -r switch10:33
mok0maxb: but I really think as a matter of philosophy that the packaging branch should be a child off upstreams branch10:34
maxbAs for the looms, I'd be tempted to loomify the packaging, and simply not bother with a quilt series at all10:35
mok0maxb: ah, didn't read your last comment properly10:35
maxbI would use debian/source/options to put dpkg into single-debian-patch mode10:35
mok0maxb: but I need a quilt series once the package is created?10:35
maxbmok0: ish. your series can contain a single monolithic patch10:36
mok0maxb: single-patch mode?10:36
mok0maxb: like the old diff.gz file10:36
maxbgoogling for reference, one moment10:36
maxbPoint number 4 in http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/10:37
* mok0 looks10:37
mok0maxb: I've been avoiding 3.0 (quilt) ... I think it sux10:38
catphishi'm struggling to understand what initiates the execution of post_change_branch_tip hooks10:39
maxbThis mostly makes it unsuck by making it behave like 1.0 :-)10:39
catphishi have configured one, and if i commit or push locally, it is executed, but if i push to the server remotely it is not10:40
mok0maxb: I like the idea of debian/ in a tarball, but it is really unmanageable that unintentional changes to your source tree finds their way into debian/patches. That really sucks10:40
mok0maxb: I usually do a quick lsdiff -z ...diff.gz to check that nothing but debian/ is added10:40
maxbcatphish: Your hook is installed for the user that the server is executing as?10:41
mok0maxb: with 3.0, I need to unpack the debian tarball and go look10:41
catphishi am executing with -Dhooks10:47
catphishbut that doesn't tell me that they're trying to be executed10:47
catphishit works if i push to the same repository locally, but not remotely over bzr serve --inet10:50
vilajelmer: before I forget: it would be nice if you could add an entry in the what's-new for 2.4 about the bunch of changes related to both the weave-as-plugin and the foreign plugins being better tested10:57
vilajelmer: may be more than one entry in fact;D10:58
catphishvila: any idea who i should talk to regarding hooks?11:18
catphishi'd read the code if i were just a little smarter11:19
vilacatphish: lunch time right now, bbl (I'm freezing 2.3.1 though)11:20
vilacatphish: but first things first, make sure you get the right code on the server when testing for hooks and remember that paths may be different (if you use them to parametrize your hooks)11:20
catphishooo 2.3 1 :)11:21
catphishright code?11:21
catphishanyway enjoy lunch11:21
catphishi'd enjoy lunch more if i were in france i think11:22
jelmervila: Sure11:25
jelmervila: weave as a plugin hasn't really landed (yet) though11:26
vilajelmer: last I looked at the mp I understood you wanted to push some more changes or split it, should I look again ?11:33
vilacatphish: hehe, back, very quick lunch, light, but prepared by my daughter which gave it this invaluable love touch ;)11:34
jelmervila: Yeah, that's still the case (unless you feel like reviewing a 4k-line branch :))11:34
vilajelmer: not *that* much ;)11:35
vilacatphish: ok, so given your pastebin it looks like the code is in the right place, to be extra sure, you can try 'bzr plugins -v' on the server to check which plugins are seen there11:43
catphishyeah it shows up in bzr plugins11:44
vilacatphish: there may still be some env variations between your shell and your server but if the log comes from the server, you should be good11:44
catphishthat log i pasted it generated when pushing through the web server11:44
vilaok, so I don't know the shellhooks plugin, how do you associate actions with branches there ?11:44
vilahmm, the author's name rings a bell <sarcasm> :D11:45
catphishi rearranged it to be a little simpler for my needs11:45
catphishand if i push locally between 2 directories, the hook runs11:47
vilaright, so the idea there is that the hook is always called and pass the basedir to the shell script ?11:47
vilalocally == on the server11:47
catphishthe plugin isn't installed on the client machine11:48
vilahey ! if you push locally you don't involved the server code no ?11:48
catphishthat's also correct11:48
catphishpushing locally between dirs on the server is 100% bzr code11:48
catphishie. "bzr push /path/to/repo"11:49
vilahmm, so you probably don't use the right hook or the hook is not implemented correctly server-side11:49
vilaok, so the doc explicitly mention the server for post_change_branch_tip11:50
spivPossible gotchas: 1) environment you're running 'bzr serve --inet' in might see different plugins?  2) paths the server sees might not be what you expect (chroot transports and such)11:50
vilaspiv: the plugin doesn't filter the paths, it just pass them to the called shell command (AFAICS)11:51
spivI'm about to go to bed, but hopefully that's enough clues for vila to work with :)11:51
spivvila: what happens if the transport.base is 'chroot+1234://...'?11:51
vilaspiv: that the ones I started with but thanks for confirming :D11:51
vilawow: return !11:52
catphishthat'll probably be it!11:52
catphishi assumed it would get file:11:52
vilacatphish: here you are, the plugin doesn't suit your needs, the hidden assumption is that it's used only for the client for local paths11:53
spivIn the API it's not too hard to go from a chroot-decorated transport to the underlying file path11:53
spivThe shellhooks plugin probably ought to do that on behalf of the shell commands though.11:53
catphishi can easily rework the plugin now i know what the problem is11:53
catphish(assuming that's what the problem is :))11:54
vilacatphish: no, add a print, but as spiv said, you probably get {chroot|filtered}-12321://11:54
catphishdoes that mean i'll never actually get the real path?11:54
catphishhopefully the API will let me extract it11:54
spivYes, the API will let you unwrap that.11:55
spivI forget the exact details.11:55
vilacatphish: you won't get the real path, probably a relative path from the base dir with some decorations in front of it11:55
catphishthanks both!11:55
catphishi'm happy to hack away at it now i know where to start11:55
spiv(Perhaps the API is not as convenient as it should be, but it's definitely possible)11:56
vilacatphish: we did faster than yesterday ;)11:56
spivThinking of yesterday, I read the IRC logs about your bzr+https problem11:56
vilacatphish: I should have listened harder when you first mentioned chunked encoding, sry about that11:56
catphishyes, thanks for being so helpful!11:56
spivThe TCP dumps were a bit mangled (non-ascii bytes replaced with '.'s) but there was nothing obviously wrong11:57
catphishthat's yes to doing faster than yesterday, not yes you should have listened ;)11:57
catphishwell thanks both, i don't think i'd have got there on my own!11:57
spivI would in the first instance suspect your custom http->bzr server glue as having a bug, though.11:57
spivBut that's just a wild guess because there just isn't enough information to diagnose :(11:58
vilaspiv: that was using a chunked encoding which our http stack is *not* ready to handle11:58
spivI'm glad the Content-Length workaround helped.11:58
spivvila: really?!11:58
vilaseems so11:58
spivvila: Which part/s?11:58
spivI'm a bit sceptical of that, if that's true I would have expected problems before now.11:59
catphishchunked encoding combined with keepalive seemed to kill the http library after about 10 requests11:59
vilaspiv: we *don't* use chunked encoding ourselves11:59
spivI realise we mostly retrieve static files where the server can easily determine the content-length before it starts sending the body11:59
catphishwhich isn't a serious problem since it just opens a new connection and tries again, but if the request happens to have been a lock...11:59
spivvila: the smart server has at some point, IIRC...12:00
spivvila: (when conveyed over http)12:00
catphishthough in the future i'd prefer to be able to stream the response rather than buffering it to calculate the content-length12:00
vilaYesterday, I started with the assumption that we were supporting the chunked encoding and was proved wrong.12:01
catphishwell chunked encoding works12:01
spivvila: and to avoid buffering potentially the entire repo contents in memory it's basically necessary.12:01
catphishit just randomly fails12:01
catphishright now i have to buffer the whole response12:01
vilaSince then, I seem to remember that for properly supporting 1.1 we have to clean up the socket when all the data is not consumed and to do so I'm pretty sure we rely on Content-Length12:02
catphishfrom what i could see, the closing 0\r\n is left in the read buffer sometimes12:02
catphishbut since i'm not a python dev i'll stop talking now12:02
spivcatphish: do you have a trace of that somewhere we can see it?12:03
spivcool, file a bug with that attached.12:03
* spiv -> bed12:03
vilaspiv: the other cause can be a smart client not consuming properly some server response12:03
spivvila: not with v312:03
vilaspiv: that was v3...12:04
catphishthat's the smallest representation of the problem12:04
spivTwo things spring to mind: a) v3's unit tests are very thorough about stuff like 'consumes whole response', b) even if it wasn't, the HTTP layer ought to be robust against that anyway.12:05
catphishsadly what happens is that the request gets sent twice12:05
spivcatphish: beautiful, thanks12:05
vilaspiv: well, the robust part is to close, open a new connection, re-send the request12:06
vilaspiv: that failed because the request was a lock and properly processed on the server :)12:06
spivcatphish: it probably doesn't reveal anything, but the previous request-response pair might be interesting to see too12:06
spivvila: no12:07
spivvila: you can robustly consume and entire chunked http body12:07
spivvila: at which point the channel is clear for the next message12:07
spivs/and entire/an entire/12:07
vilamay be12:08
spiv(assuming the headers didn't specify Connection: close or whatever, of course)12:08
vilaI'm not sure the layer get enough info to know that12:08
catphishspiv: http://paste.codebasehq.com/pastes/49osq8c9otx712:08
vilabut in theory yes12:08
spivvila: which layer?12:08
catphishif you really want to get your hands dirty12:08
catphishthat's the tcp stream12:09
vilathe http transport12:09
catphishsadly it's ascii and not coloured properly12:09
catphishbut it shows what happened12:09
vilafor get_bytes() and readv() we let the higher layer handle the socket content12:09
catphishthe final request there is the one that failed (the write lock)12:09
vilaget_file() not get_bytes() of course12:10
spivvila: I think that's a tractable problem12:10
spiv(ITYM 'get' not 'get_file')12:11
spivvila: HttpTransportBase.get already reads (and so buffers!) the entire reponse12:12
vilaspiv: isn't there a FIXME there ?12:13
vilayes there is...12:14
spivSure that'd be nice to improve, but that's not *this* problem :)12:14
spivreadv is of course more complex, but basically the solution is the same:12:14
spivIf a caller issues a new request before you've finished reading the last response you only have a few options:12:15
vilaindeed, see response.py12:15
spiv1) raise an error (HPSS does this)12:15
spiv2) assume no further consumption of the existing response will happen and just read and discard the contents (and cause errors if someone does keep trying to use that ReadVFile or whatever)12:17
spiv3) read and buffer the remainder of the pending response so the existing call works before issuing the next request.12:17
spiv4) assume pipelining12:18
spiv(and possibly risk deadlocks)12:18
spiv5) make a new connection12:18
spivOf all those, for bzrlib I'd be most tempted by 2 or 3.12:19
spivAnyway, really bedtime now.12:19
vilayeah, sweet dreams :)12:19
catphishnight :)12:19
mok0vila, maxb, thanks for your help!13:14
=== vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.1 is frozen, installer build time ! (RM: vila)
vilajelmer: *now* you can make a bzr-svn release ;-)13:40
vilajelmer: preferably one compatible with 2.3 ;-D13:41
jelmervila: I'm on it :)13:46
jelmerI also just submitted three MPs for the weave plugin13:46
vilaha ha13:46
vilaok, I'll switch to that RSN :)13:47
bialixhey all14:17
bialixhi vila14:18
bialixI thought the spring is coming, but you're freezing releases, heh!14:18
vilatime-based ! And this one was delayed because I was in vacations ;)14:19
bialixI've tried to make joke with spring and freeze, but I'm bad in English jokes14:20
vilaoh my, I missed it :)14:20
bialixthere is very cold these days ;-)14:20
bialixjust wanna ask strange question14:21
bialixI've just realized that bzr info shows location is quite strange order: push first, parent second. why so?14:21
bialixvery strange14:22
bialixvila: re windows installer: Gary is really very busy with his work. I'm not sure he'll be able to do one14:23
bialixand I've lost my installa-fu some time ago :-(14:24
bialixvila: can you ask jam to do the installer?14:24
vilabialix: jam moved from US to EU, he's in out TZ now :)14:25
vilabialix: I think you wake him up from his nap by making his laptop ring :-D14:25
bialixjam have a ring now?14:25
vilabialix: as such, he may be too grumpy to jump on the offer ;)14:26
vilabialix: no idea, I'm making silly jokes14:26
jamI'm awake now, but I've got a pretty big stack on my plate14:26
jamwe tried to rollout a new system on launchpad and 2 of my patches "failed"14:26
bialixmorning jam14:26
vilajam: you're jinxed :-/14:26
jamEmpathy doesn't seem to ring like Pidgin did, but it does pop up a little Notifier for me.14:26
jamor maybe my music is too loud :)14:27
rvbaHi, I started hacking on lp:devel where I really should have on lp:db-devel ... I created a branch from lp:db-devel now but I need to pull my changes from my old branch (based on lp:devel).14:27
vilaSAY WHAT ?14:27
rvbaShould I export a patch and apply it manually or is there a more clever way to do this with bzr?14:27
jamrvba: I'm pretty sure you can just merge across14:27
jamdb-devel is supposed to be a superset of devel, aiui14:27
jamcd db-devel-based-branch14:28
rvbajam: ok, I'll try this then, thx14:28
awilkinsrebase, cherry pick14:28
jambzr merge devel-based-branch14:28
awilkinsor merge14:28
jamrvba: you may want to look at the diff, (bzr diff) and make sure you aren't bringing tons of unrelated devel stuff in14:28
jambut I think you'll be ok14:28
jamrvba: note, I had lots of trouble with devel vs db-devel as well14:28
bialixawilkins: or replay, that's one you haven't mentioned ;-)14:29
jamso don't feel too bad. double-mainlines is hard to keep straight for new contributors14:29
awilkinsbialix, That's a new one on me14:29
rvbajam: ok, thanks I'll see how it goes14:29
bialixawilkins: why? ah, yes, jelmer said it's hidden14:29
awilkinsWas it written to support the replay semantics that SVN supports?14:30
bialixawilkins: honestly, I have no idea what svn does. replay just replays commits, it's part of rebase (rewrite) plugin14:32
jelmerreplay needs more polishing before it's exposed14:33
jelmerawilkins: what replay semantics does svn support that e.g. bzr merge doesn't?14:34
awilkinsI think it just names the thing it uses for svnsync "replay" in some way14:34
jelmerthe replay in svnsync is just an optimized implementation of regular "svn up"14:51
maxbvila: bzr-fatimport, eh?15:06
vilamaxb: hehe, fixed in my branch, I saw the typo after sending the email :D I was wondering if/when someone will notice :)15:07
vilafor once, the tyop *is* the joke ;D15:07
fullermdI figured it was like a signature, so we'd know it was from you  :p15:10
vilaha ha, no, for those cases I just add 'crocodile' somewhere to catch true readers ;)15:11
fullermd'minds me of years back in school, where some friends and I had a running thing where, any time we gave a speech or wrote a paper, we had to include the phrase "aluminum siding" in it somewhere.15:13
fullermdIdeally in such a way as to not raise eyebrows.  It was entertaining.15:14
vilahttps://code.launchpad.net/~jelmer/bzr/lazy-bzrdir/+merge/52844 makes my head spin :-}15:14
jelmervila: in what way, just the different registration functions?15:14
vilafullermd: oh, this game is still heavily practiced there, one variation is called ... business loto or something15:15
vilajelmer: the relationships between probers, control dirs, formats, the @classmethods and the base class calls via the class name instead of super()15:15
jelmervila: basically what's involved here is:15:16
jelmer- The list of control dir formats, used by the test suite (ControlDirFormat._formats)15:16
vilajelmer: I'm sure it's clearer when you're deep in the code ;)15:17
jelmer- The list of known BzrDir formats (e.g. everything that has a unique string for .bzr/format) (BzrProber.formats)15:17
jelmer- controldir.network_format_registry15:17
jelmerand then there's BzrDir.register_format() which is a convenience wrapper to register a new bzrdir format, which takes care of registering it in the prober and in the control dir.15:18
vilaworth a dev doc then (which is what I'm asking in my review ;)15:18
fullermdNah, just ship jelmer in the tarball   ;>15:20
vilano way15:21
vilaa clone may be ?15:21
fullermdSome people might accidentally make a checkout instead of a clone and wind up changing the original...15:21
vilajelmer: hmm, but what do we really need ? A helper and a doc or a better doc and no helper ?15:22
jelmerfullermd thinks I should be treated like a wild-west criminal? :-P15:22
jelmertar and feathers..15:23
fullermdJust so, my fine feathered friend   O:-)15:23
jelmervila: I think the helper is useful, it gets called in quite a few places (even though it's just two lines)15:23
fullermd(actually, tarring and feathering was an Eastern thing...)15:24
jelmerfullermd: not according to the Lucky Luke comics I read!15:24
vilajelmer: I'm trying to think like a newcomer here... (which I'm not... or am I ?)15:25
jelmerfullermd: Or are you going to claim they're not historically accurate?15:25
fullermdAh, well then.  Far be it from me to gainsay such authority.15:25
vilafullermd: +1 on jelmer readings15:25
jelmervila: hmm15:25
jelmervila: I wonder if we could perhaps do away with the ControlDirFormatRegistry15:26
vilajelmer: it may just be a public/private thing to disambiguate but I;m not sure15:26
jelmerthe ControlDirFormat._formats registry15:26
fullermdIt was practiced during the Whiskey Rebellion, frex, which predated the existence of the West by some time.15:26
fullermdThus endeth fullermd's Random Historical Digression for the day   :p15:27
jelmerfullermd: :)15:29
jelmervila: so, I see to alternatives to make the current situation simpler15:29
jelmervila: we could either add Prober.known_formats() and use that to discover the available control dir formats15:29
jelmeror perhaps kill the helper in BzrDirFormat.register_format() and just have BzrDirProber.register_format() do what that helper does at the moment.15:30
jelmeror moving BzrProber.formats to BzrDirFormat.subformats and killing any helpers on BzrProber15:30
vilahow many probers exist ?15:31
jelmervila: there's one that covers all local bzr formats, one that covers all bzr remote formats, one for local svn, one for remote svn, one for git, one for hg15:32
vilaright, so a given format can be associated with only one prober15:32
jelmermy only concern with adding BzrProber.known_formats() is that a prober isn't necessarily that tightly coupled to a particular format15:32
jelmervila: exactly15:32
vilaand the main aim of a prober is to create format *objects* from a given transport15:33
vilaSo I'll tend to make it the main (or even only) entry point ro register a format15:34
jelmer(well, currently from a given transport. In the future it could perhaps support creating format objects from a HTTP options reply, etc)15:34
vilathat was my 'hmmm' content ;)15:35
vilaI was thinking about tests too15:35
vilaso may be we should keep a separate registry and build the prober from the registry15:35
jelmerI'm not sure I follow15:36
jelmerwe already have a registry for the available probers15:36
vilaand in that case, registration should transit via the prober15:36
vilaformat registration15:36
jelmerah, so basically Prober.known_formats() ?15:36
vilamay be, I'm not sure I understand the implications15:37
jelmerreconsidering this, I think that might indeed be the sanest solution15:38
jelmeras it would in fact remove the need for both ControlDirFormat.register_format and BzrDirFormat.register_format.15:38
vilaha ! I like that ;)15:39
vilastill not sure I follow every detail but this ^ sounds godd :)15:39
vilajelmer: also seeing BzrDirFormat.register_format directly calls ControlDirFormat.register_format rang a hard-to-override bell15:43
vilajelmer: sorry for the confusing/confused review but this code is really.... delicate15:45
jelmervila: np, you're absolutely right that this is confusing at the moment so I'm glad we could come up with a way to make it a bit simpler15:46
vilajelmer: the other registries you introduced made the code clearer without doubt, here... this seems... incomplete ? It's hard to express, I feel you're going in the right direction but15:46
vilaI don't want to block this mp either if you think it's a good step, may be the whole approach should be rethinked15:47
vilaI still have the feeling that there should a simpler way and that this code didn't anticipate all today's usages15:48
vilajelmer: but putting weave into a separate plugin should help anyway, so I'm +42 on your work15:49
jelmervila: thanks :)15:54
jelmervila: I've pushed a newer version (minus updated tests, etc). Can you tell me what you think of this alternative?16:12
vilajelmer: it leaves a better taste in the mouth now ?16:20
vilaerr s/now/no/ ?16:21
vilajelmer: why do you need to use a set() in known_formats() ?16:21
jelmervila: :)16:22
jelmervila: Just in case more than one prober returns the same format16:22
viladoes it make sense or would this be a bug ?16:23
vilayeah, it could make sense16:23
jelmerI think it would make sense. I don't want to tie the formats to particular probers too heavily.16:23
vilaeven if it doesn't today one can imagine various ways to get to the same format16:24
vilaok, so that needs a comment and some basic tests but I like it far better16:24
vilaif only because it removes a comment mentioning  a circular import ;)16:25
=== deryck is now known as deryck[lunch]
jelmervila: Which comment regarding a circular import?16:26
vila-# registered. Putting it in remote.py creates a circular import problem.16:26
jelmervila: the one with regards to RemoteBzrDirFormat should no longer be valid16:26
vilaindeed, you've deleted it16:27
vilaor was it already deleted in the previous version ?16:27
jelmerI think there's a communication mismatch here somewhere.. the comment no longer applies so why should it be kept in?16:29
vilajelmer: I said: "I'm glad you deleted that comment"16:30
jelmerah, " ok, so that needs a comment and some basic tests but I like it far better" was what threw me off :)16:30
vilaI'd like you to *add* a comment about why you're using a set in known_formats()16:30
vilayeah, I just realized while re-reading that I was referring to two different comments :)16:31
vilato make matter worse one didn't exist and the other was deleted :)16:31
vilaconfusion guaranteed !16:31
jelmervila: I think the other issue is that of deprecation16:33
jelmervila: I'd prefer to just get rid of these methods rather than deprecating them first, as it's very hard to provide backwards compatibility and the few users we have of the current mechanism can be patched to do the right thing.16:33
vilayeah :-/16:34
vila2.4b1 will get out next week (IIRC) so we need to check bzr-loom too16:34
jelmerbzr-loom shouldn't be affected as it doesn't introduce a new bzrdir format16:34
vilaooh ! right !16:35
vilaso, just get in touch with the bzr-{svn|hg|git} plugin authors then16:35
vilajokes aside, I'm fine with getting rid of the methods, but it would be better to bring the subject on the list :-}16:47
vilaWe may still encounter users that will upgrade bzr without upgrading the plugins so *they* need to get at least a proper error message16:49
vilaotherwise your karma will suffer (the real one, not the lp one ;)16:49
=== beuno is now known as beuno-lunch
=== deryck[lunch] is now known as deryck
jamvila, jelmer: I would like us to deprecate them in the short term, we can remove them after 2.4b1, that gives a small window for compatbility18:06
=== beuno-lunch is now known as beuno
vilajam: I think jelmer's point is that only bzr-{svh|hg|git} are using them and that he's willing to help the respective authors handle the compat in the plugins themselves (which I suspect is easier) rather than trying to do it in bzr, hence my compromise to at least blow up with a meaningful error message (which should also be easy to implement)18:09
vilaall in all, I'm all in favor of minimizing the effort for all parties involved18:09
wolfpackI was working on a project and the main branch is there on launchpad. There is other developer who has branched the code and I have my one branch. I cannot push the branch because of network firewall. I can only upload the patch. How will the syncing of the code will take place as both us will be changing the code ?19:19
vilawolfpack: simple things first:19:28
vilawolfpack: if you can provide a read-only access to *your* branch, then your co-worker can push to lp and read from you19:28
vilawolfpack: that's enough to provide you both access to all the needed data19:29
vilawolfpack: otherwise, you can keep the trunk on lp and send bundles to your co-worker and it publish them on lp (after setting a mirror of your branch where he can apply the bundles)19:30
wolfpackvila: Will this thing work?-> I will pull co-worker's branch after he pushes it, while continuing my work. After that I will upload the patch.19:31
vilawolfpack: bundles are produced with 'bzr send', you  send one when you're ready to publish your changes and it will contain all the changes you've made19:31
vilawolfpack: yes, upload my patch == send a bundle19:31
vilaexcept that the bundle can contain merges, commits and all the associated metadata (message, author, revision-ids, etc)19:32
wolfpackvila: So sending bundles does not require ssh connection?19:33
vilawolfpack: bundles are a bit more delicate to deal with if you can't share a public branch, but since you have lp to host multiples branches, you're fine19:33
vilawolfpack: you send a bundle by *mail*19:34
vilawolfpack: or any other mean, it's a text file19:34
wolfpackvila: Thanks19:36

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