=== Meths_ is now known as Meths [00:34] hi spiv? [00:37] Hi poolie [00:37] hey [00:37] i was just going to check you were still ok to pilot [00:37] and to see if you wanted reviews or anything [00:38] i was going to work on launchpad flags and dkim but i could do that first if you want [00:39] The queue looks fairly short... although there are a couple of patches from me in it. [00:40] Perhaps take a look at https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42811 ? It's a prereq for the other two mps from me, although it is a pretty large diff. [00:41] Oh, although I see jam looked at a the previous iteration of it, so perhaps I should just ask him. === frakturfreak_ is now known as frakturfreak [04:48] Are there tools for looking directly at a repository's contents? [04:50] or, which python api should I be looking at? :) [04:52] like say I wanted to enumerate all of the leaf revision ids in a shared repository, can I do that? [04:53] exarkun: just a sec [04:54] (I think I deleted a branch that had some stuff in it that I want, and my assumption is that I didn't completely destroy the data since it was a branch in a shared repository...) [04:57] exarkun: API-wise it's something like python -c "from bzrlib.repository import Repository; repo = Repository.open('code/testtools'); repo.lock_read(); g = repo.get_graph(); print g.heads(repo.revisions.keys())" [04:58] exarkun: but now that I see you don't really care about the API, try "bzr heads" or "bzr heads --all", from the bzrtools plugin [04:58] Oh cool. Thankee. [05:01] yay recovered [05:32] * spiv sighs and restarts his gnome-terminal process, which has run out of fds. Someone really needs to add that fix to maverick-updates... [06:01] poolie: any thoughts on the UI change proposed in https://code.launchpad.net/~jelmer/bzr/diff-git/+merge/44185 ? (allow "bzr diff --git" rather than requiring "bzr diff --format=git") [07:24] hi all ! [07:29] hi spiv [07:33] hi vila [07:33] poolie: hey there ! [07:38] spiv, i answered [07:40] spiv: are you still here? [08:42] Funny trick with the new 'bzr config' command: when I do a review locally, I generally create a branch whose parent is lp:bzr [08:42] so when people update their branch I have to type again the url to get updates [08:42] right [08:42] well, I had. [08:42] Now I do: bzr config reviewed=lp: [08:43] and 'bzr pull -v `bzr config reviewed` [08:43] or 'bzr diff --old `bzr config reviewed`' [08:43] no more need to defined specific directory aliases like submit: , parent: and all, and it's supported by all bzr commands :) [08:47] hm [08:47] only on unix though [08:47] that's a nice reason to have config emit only the url [08:50] yup, I'm so totally convinced now :) [08:56] :) [08:56] on windows we could do something like bzr pull config:reviewed [08:59] vila, we should probably defer b5 until during/after the sprint [08:59] do you want to hack on it there? [08:59] or switch to tarmac there? === beaumonta is now known as abeaumont_ [09:00] yeah, I think that would be the best, having everyone involved and aware of all the issues and debugging all nits [09:01] yeah, definitely for 2.3b5 *and* tarmac, I'll update the release date [09:02] .. and discuss how we reach 2.3.0 final [09:03] well, we'll need to schedule it with the sysadmins too [09:04] yeah, but we can play with it on a scratch branch and ask the sysadmins to switch with a working setup [09:04] (unless I miss something on how tarmac is supposed to work) [09:05] but yeah, we can tell them we *will* switch around 2012-01-13 (I've update the 2.3b5 date on lp) [09:51] anyone here knows how to use bazaar.conf and lp-propose-merge to get an implicit push location [10:06] zyga: Most of the time I do: bzr push lp:~vila/bzr/`bzr nick` [10:07] zyga: the only way to go further today is to use locations.conf but it will take precedence over anything defined in branch.conf which is certainly not what you want [10:07] zyga: there is a work in progress to allow path-based default values to be defined in bazaar.conf though [10:09] vila, I want to "bzr push" [10:09] vila, salgado gave me bazaar.conf that doesn't work that works for him [10:09] http://paste.ubuntu.com/544906/ [10:09] vila, could it be possible that salgado is riding bzr.dev wave? [10:10] vila, my real problem is on usability of lp-propose-merge [10:10] it takes bzr push + bzr lp-propose-merge while I just wanted to lp-propose-merge [10:10] (and push also is verbose as you explained, you need to specify the push branch which is tedious) [10:11] zyga: sections defined in bazaar.conf are just ignored [10:11] hmm [10:11] zyga: unless salgado has written a plugin... which I doubt [10:11] vila, that's what salgado is using, I need to check with him again [10:11] zyga: may he uses locations.conf instea [10:11] hmm? should I put that in locations conf and see if it worsk? [10:12] I'm on 2.2.1 [10:12] zyga: but the aim of locations.conf is to *override* branch.conf (so whatever is defined in branch.conf is ignored if a matching is found in locations.conf) [10:13] zyga: it will work even for 2.0 I think (95% sure) [10:13] that's okay, I just want to stop having to type everything twice all the time [10:13] (something is happening) [10:13] yayt [10:13] it worked [10:13] bzr lp-propose-merge [10:13] no push needed :D [10:13] thanks :-) [10:13] hmm [10:13] (premature happines) [10:13] zyga: you need to type it once, once it's defined in branch.conf it will be used (--remember can change it) [10:14] vila, I keep making branches [10:14] zyga: type it once unless you define a default in locations.conf I mean [10:14] I have ~10 branches a day [10:14] http://pastebin.ubuntu.com/545877/ [10:14] what does that message mean? [10:15] this is my locations.conf [10:15] http://pastebin.ubuntu.com/545878/ [10:15] hmm, it may come either from launch-control not being a project defined on launchpad or some weirdness in the stacked-on branches defined on lp (and dev focus too) [10:16] hmm [10:16] launchpad.net/launch-control exists [10:16] ok [10:16] Does anyone here have experience maintaining a gnu autotools dependent project in bzr? [10:16] may be a missing trailing '/' ? [10:17] let's see [10:17] zyga: if you use bzr trunk, 'bzr config' will display the expanded values that apply in the current dir [10:17] vila, I don't use trunk, sorry :/ [10:17] np np [10:18] vila, is there any difference between lp:~something and the bzr+ssh://longish version? [10:18] I'd like to know what your opinion on the autogenerated files is: do you store them in the repo? [10:18] can I just use the lp: shorthand? [10:19] mok0: strictly speaking versioning generated files is... akward, but it may help when creating tarballs, but generally you don't mix the too, you version only files that a re modified by humans [10:19] zyga: yes you can [10:19] I hacked the locations conf a bit and bzr info in the branch I'm working on now says: http://pastebin.ubuntu.com/545881/ [10:19] it looks good IMHO [10:19] btw, what is submit branch? [10:19] vila: that's exactly the problem I have: "make dist" seems to work at cross purposes of bzr [10:19] I never figured that part out [10:20] zyga: the difference is that the lp: shorcuts can be expanded into their http: variant under some circumstances [10:20] vila, yeah I know, if lp-login is not used [10:20] zyga: submit_branch is the branch your merge from or against, a bit confusing [10:21] mok0: only if you version generated files [10:21] "merge from" ? [10:21] vila, can you give me an example of what command uses that submit_branch? [10:21] zyga: when you work on a feature branch and you want to update from trunk (merge new changes) [10:21] zyga: merge [10:21] zyga: send [10:22] zyga: lp-propose :) [10:22] hmm [10:22] vila: well, I don't like to store configure, aclocal.m4 and friends, but that means I need to generate configure, and that fails unless you have all the dependencies installed. [10:22] mok0: exactly [10:22] vila, so bzr push worked for me [10:22] Which is aPITA [10:22] zyga: don't forget the :policy=append_path bit [10:22] vila, but lp-propose-merge again said that "bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad" [10:23] OTOH, storing configure and friends in the repo is a PITA because they keep changing and it pollutes your history [10:23] mok0: it's more a work flow issue than a VCS issue per se, but depending on the project they often overlap [10:23] vila: yeah... I was just wandering if anyone had a smart solution [10:23] mok0: the question is how you distribute your sources and how you want people to contribute to the project [10:24] vila: I'm not upstream, only trying to maintain a deb package [10:24] vila: and I _need_ to patch configure.ac [10:24] mok0: either you version only non-generated files and requires devs to have the generating tools installed or you version the generated files but should ensure you're in sync at commit time [10:24] oh, packaging... that's different :) [10:25] mok0: In this case you have the additional issue that upstream may be versioning generated files [10:25] vila: yes, because you do build work etc. in the directory [10:25] vila, okay, one step closer, I removed merge_target and submit_branch from locations.conf, now lp-propose-merge wants to have a reviewer, can I make it use the default reviewer for lp:launch-control somehow? [10:25] zyga: search for the stacked-on branch and check that the dev focus is correct too [10:26] zyga: isn't it the default ??? [10:26] hmm [10:26] zyga: -R reviewer ? [10:26] vila, I don't understand either part [10:27] zyga: (from 'bzr help lp-propose' I rarely use this command myself) [10:27] vila, I could use that but lp already knows who is the reviewer [10:27] zyga: EPARSE [10:27] so I want to avoid having to type that, It must be a configuration issue somewhere [10:27] note: https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk this is the branch I want to submit to this is the development target [10:27] zyga: yeah probably [10:28] vila, if I do lp-propose-merge lp:launch-control [10:28] it says: $ bzr lp-propose-merge lp:launch-control [10:28] bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad [10:28] did I make a typo I cannot see or is there something wrong here? [10:29] zyga: weird, I can 'bzr info' it but not 'bzr config' it :-/ [10:29] vila, hmm? [10:31] bzr bug somewhere? [10:31] zyga: for bzr config, probably [10:31] vila, how about lp-propose-merge, why does it say that launch-control is not registered? [10:32] do I need to spell out the actual location of the branch: lp:~linaro-infrastructure/launch-control/trunk [10:32] zyga: you could try that yes [10:33] that worked but said that no reviewer is specified [10:33] sigh [10:33] how did salgado make this work without passing all those arguments [10:33] sounds like a launchpad config issue then [10:34] zyga: check with salgado, either he has a different config or you're not part of the same teams ? [10:34] is the maintainer the default reviwer? [10:34] we are both part of the ~linaro-infrastructure team [10:34] but who review the proposals ? [10:34] that team [10:34] is it properly configured on lp ? [10:34] 'it' being vague :) [10:35] vila, good question, how can I check that [10:35] https://launchpad.net/launch-control [10:35] maitainer is set [10:35] but not driver ? [10:35] no, driver is not set [10:35] * zyga never understood what that really meant [10:35] * vila neither :) [10:36] I set the driver too [10:36] let's see if lp-propose-merge will work now [10:36] nope [10:37] I just want this whole review thing to get out of my way ;-) [10:37] zyga: hmm, I think that's something that should be specified on the target branch or something [10:37] vila, thanks for all the help [10:37] target branch being? [10:37] trunk? [10:37] * vila looks at the bzr lp project [10:38] zyga: there is a review team for lp:bzr [10:38] bzr info does not say [10:38] zyga: it's a launchpad thing [10:38] zyga: look at https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev [10:39] there is a review team there, but nothing comparable on launch-control (may be because I'm not part of the team there, can't say for sure) [10:41] Is there a special channel for discussing packaging in bzr? [10:41] Or is that here :-P [10:41] mok0: here is fine [10:41] vila, thanks [10:42] mok0: #ubuntu-devel may be better if you're targeting Ubuntu (or even debian) [10:42] So now I am wondering, should I just make all changes in the autobuild system that I need on my bzr branch [10:42] ... and somehow create my package from that [10:42] mok0: you're *creating* a package ? [10:42] vila: ytes [10:42] yes [10:43] Upstream doesn't provide a recent tarball, source is distributed via svn [10:43] mok0: hmm, I'll be on limited help then, I don't have a significant experience here [10:43] I have it mirrored in an LP project [10:43] good [10:43] Then I have a branch off that called "ubuntu" :-) [10:43] mok0: you're targeting Ubuntu ? [10:43] vila: for now, yes [10:44] mok0: did you look at bzr-builddeb ? [10:44] vila: I've used it now and then, but I found it got in my way [10:44] mok0: you should definitely ask in #ubuntu-devel and file bugs when it gets in your way ! [10:44] I wasted hours until I discovered that it stashes away its own copy of the tarball in the buildarea [10:45] I couldn't understand WFT was going on [10:45] mok0: I don't know the details but there are several possible workflows, with a bit luck you're just not using the right one [10:45] vila: perhaps yes [10:46] vila: and then there's quilt.......... [10:46] vila, checking [10:46] mok0: james_w wrote a very succint document about that, but I don't remember if/where it's published [10:46] vila, sorry, my son is ill and needed some help [10:46] zyga: that's a *priority* interrupt [10:46] vila, lemme see if mr. Google will come to my help :-) [10:48] vila, the review team _is_ set [10:48] https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk/+reviewer [10:48] I can see linaro-infrastructure as the reviewer [10:48] zyga: no permission to look at that [10:49] vila, right but it's set there [10:49] vila, would you be referring to this? https://wiki.linaro.org/BzrIntroduction [10:49] I think lp might not show the reviewer if it's the same as owner [10:49] zyga: :-/ I'm out of my league then [10:49] mok0: no, it was one with pretty pictures :) [10:50] mok0: but james_w is mentioned so you're on the right track ;) [10:51] vila, hehe. I found this now, it looks like I need to read that: http://jameswestby.net/bzr/builddeb/user_manual/ [10:52] No pretty pictures though [10:52] mok0: certainly a must read :) [10:54] mok0: may be https://wiki.ubuntu.com/UbuntuDevelopment/ is a good starting point too [10:55] vila: Indeed... thought it mostly looks like a link-collection [10:55] mok0: could be, but #ubuntu-devel can better answer than me for that [10:56] vila: you've been most helpful, thanks [10:56] mok0: np, happy to help but I know bzr better than packaging (I'm learning though ;) [10:57] vila: I think dvcs packaging is very much in its infancy [10:57] mok0: yup, actively working on though ;) [10:58] vila: AFAIK you still need a tarball [10:58] vila: which is kinda crazy if the source can be pulled from a branch and you can construct the debian/ from the packaging branch [10:58] mok0: that's the part I'm unsure about (since I always start with a bzr branch myself) [10:59] mok0: that's what 'pristine tar' is about: re-create tarballs from a branch [10:59] vila: then that's a new definition... it used to be "the tarball you download from upstream" [11:00] vila: anyway, I don't see there's a need for tarballs [11:00] mok0: but for many operations builddeb re-creates the tarball from the branch [11:00] vila: I know... as I wrote above, I was burned by that [11:00] so instead of downloading it from upstream you just use the equivalent version [11:01] vila: because when you edit edit edit in the branch, the old tarball is still sitting there :-( [11:01] mok0: which is why I think you may not be using builddeb as intended [11:01] vila: and so it seems your edits are gone [11:01] vila: perhaps you are right [11:02] mok0: because you seem to be doing 'normal' things, so builddeb should know how to deal with them [11:02] vila: which is why I'd like to see a description of a proper workflow [11:02] vila: I agree [11:02] mok0: have you read the user manual you pointed above ? [11:03] vila: not yet ... I'm not THAT fast :-) [11:04] mok0: hehe, just checking, but I'm 60% sure you'll find many answers there [11:04] vila: I am sure I kan learn a lot [11:04] s/kan/can === zyga is now known as zyga-coffee === Ursinha-afk is now known as Ursinha === zyga-coffee is now known as zyga [13:52] I'm running bzr annotate filename and I'm getting something like "bzr: ERROR: The file id "file-20060906040903-s4f1zy3gz43haztt-3" is not present in the tree" any ideas as to what the problem could be? [13:58] hi johnf [13:58] jelmer: howdy [13:58] johnf: I thought you were based in .au ? [13:58] johnf: In what context? [13:58] jelmer: I usually am. In Germany for the holidays [13:59] jelmer: Let me pastie the whole thing [13:59] johnf: Ah, nice. Enjoying the snow ? :-) [14:00] jelmer: Yes :) I've never really experienced snow before. This is totally surreal! [14:01] jelmer: sent you the pastie privately since it has some email addresses etc I'd rather not make public :) [14:01] johnf: np [14:02] johnf: what's the status of that file in the current working tree? [14:03] jelmer: Hmm OK maybe I'm doing something dumb [14:04] I have a branch which is currently up to rev130 and I've done this "bzr up -r 20; bzr annotate file" [14:04] that is when I get the error [14:04] if instead I do "bzr branch -r 120 orig copy; cd copy; bzr annotate file" it works fine [14:05] should the first approach work? [14:05] * jelmer wonders what "bzr up -r" does exactly [14:07] jelmer: yeah I think that't the problem. It makes the working tree the same as rev 20. But I think when I run say the annotate command it is still working on revision 130 where the file no longer exists [14:22] johnf: does "bzr status" report a lot of changes? === bac` is now known as bac [14:22] johnf: You might want to try "bzr annotate -r -1 " or "bzr annotate -r 120 " [14:23] jelmer: bzr status says "working tree is out of date, run 'bzr update'" [14:23] johnf: ah, so "bzr up" only changes the working tree, not the branch [14:24] jelmer: yeah. Adding -r to annotate worked fine === Ursinha is now known as Ursinha-lunch [14:32] Hello, thank you for making bazaar available. We switched recently from git to bazaar. [14:32] Now a coworker hat done a bzr rmbranch bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk [14:32] Is there an easy way to undo this change? [14:35] ThiasG: hi [14:35] ThiasG: You should be able to run "bzr heads --dead" to find the previous tip revision [14:37] after that you should be able to create that branch again and then update it to that revision using "bzr pull -rrevid: ." [14:38] I found the revid. [14:39] The branch I just create with bzr init bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk ? [14:41] ThiasG: yep [14:41] ThiasG: if you don't have local access you'll need a somewhat more complicated pull command [14:41] ThiasG: rather than using "." you should probably specify the same branch URL, once for the target (with -d) and once as source [14:42] I have local access to the shared repo. [14:42] In the trunk dir, I typed in bzr pull -rrevid:timotheus.pokorra@solidcharity.com-20101220135316-3qbh20dt0fkwi811 [14:43] ThiasG: you'll probably need the "." after that as well, unless the default pull location has that revision [14:43] But this gave me "bzr: ERROR: No pull location known or specified." [14:43] okoay [14:43] Now he is working [14:44] All changes applied successfully. [14:44] Now on revision 1035. [14:44] I'm finished? [14:44] should be, yeah [14:45] Is it correct, that I could remove the content of the trunk directory except the .bzr directory? It is the shared remote repo. [14:46] ThiasG: yes; "bzr rmtree" should do that for you [14:47] I dod a bzr status, which gave me 8 modified files. [14:48] if there are modified files you should probably check why they are modified, just in case they're changes you'd like to keep.. [14:49] Okay, thank you very much for your help. [14:50] Does someone already have a hook for restricting removing of branches? Otherwise I have to write one ;-) [14:56] I don't think there is anything like that at the moment [14:58] Aber dann ist es nicht so tragisch. Ich checke sie ein, oder? [14:58] ja, selvfølgelig! [14:59] Sorry, wrong channel... [15:05] Just for completeness: The command for removing the working tree is "bzr remove-tree" [15:06] Thank you for your fast help :-) === Ursinha-lunch is now known as Ursinha === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno [17:26] hi, I'm using bzrlib to do the equivilent of "bzr branch $src $dst" [17:27] given a remove url for $srf [17:27] and a local file path for $dst [17:27] I have: [17:27] src_branch.create_clone_on_transport(get_transport(destination), revision_id=rev_id) [17:27] but that doesn't give me a working tree in $destination [17:27] what am I doing wrong? [17:31] mhall119: that's correct, branch.create_clone_on_transport() only creates a branch (and copies revisions where necessary) [17:32] you can create a tree later by calling bzrdir.create_workingtree() [17:46] that did the trick, thanks a bunch [17:46] np === deryck[lunch] is now known as deryck [21:15] mgz: hi [21:31] hey lifeless. [23:31] spiv: Thanks for acknowledging and helping clarify that bug. [23:43] mkanat: you're welcome :) [23:43] :-)