[09:08] morning [09:12] mgz: hello ! [10:10] mgz: ok, 26b1 being frozen, any chance you could finish this config-caching review ? Pretty please :) [10:10] :) [10:44] jelmer: I need you brain and its mid-term memory :) [10:44] Oh no, midterms?! I haven't studied all millennium :( [10:45] When running 'make docs-sphinx' in a *fresh* bzr branch it fails with: http://paste.ubuntu.com/886129/ [10:45] or rather as mentioned in the paste, the command there (triggered by make) fails [10:46] but a second run succeeds (not investigated yet, probably make see some file left over by the failure and is happy) [10:46] jelmer: to the point: no default in format_registry ? Surely that should ring a bell [10:47] fullermd: one more joke making the whoosh sound above my head ;) [10:48] mid-term memory is not correct english ? How do you call the memory between short-term and long-term (and don't reply: can't remember, please ;) [10:49] Eh? Who're you? :p [10:49] hehe [10:49] I dunno. Is there even biophysiologically such a thing? I guess it's as good a term as any. [10:50] yeah, wikipedia agree with you, only short and long, weird [10:50] gimme my elastic memory back, best vaccine against Alzheimer ;) [10:51] on that topic, I read the last Pratchett and he seems to be doing fine so far (good). [10:51] Alzheimers is when you _lose_ your memory. As long as you never really get it in the first place, you can't get Alzheimers ;p [10:52] I should remember that... [10:52] Better write it down. [10:53] After all, the mind is the first thing to... to... uh... [10:53] jelmer: adding 'import workingtree' fixes the issue... what's the rationale again ? [10:53] wossname ? [10:54] 'medium term' would probably be most idiomatic. [10:55] mgz: my saviour :) [10:55] Eh, it's English. You can say any old meaningless thing, and pretty soon it'll become idiomatic. [10:56] From the language that brought you "the proof is in the pudding", and "I could care less". [10:58] 'I couldn't care less' is also valid and means the same. [10:59] so, you can be both correct and sensicle if you choose. [10:59] It's not _also_ valid. It's the only valid one. It's just not the one everyone around me says. [10:59] My hand gets so sore from smacking them... [11:02] good, so I could add 'because I could care less' to any sentence and leave other fail into the logic trap, very good [11:02] * fullermd rears back his arm. [11:10] earlier this week jelmer was suggesting drink, now fullermd is suggesting pudding [11:10] #bzr becomes more and more hospitable by the day. [11:10] can we have custard? [11:11] isn't it lovely ? ;) [11:14] I've forgotten... how does one get the repo for a Brancch? [11:15] .repository ? [11:15] fullermd: re "I could care less", http://www.youtube.com/watch?v=om7O0MFkmpw [11:15] mgz: ah yes, thanks. [11:16] mgz: it's not documented on http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html and other things that I would guess to be attributes are methods... [11:17] jml: on you udd branch, why fabric not juju? [11:17] mgz: because I'm deploying things to the Canonical data centre, and am thus compelled to use lucid. [11:18] mgz: and similarity to production is a cardinal virtue for a thing like this [11:18] seems like sticking it on canonistack as well as ec2 might be useful [11:18] mgz: yes. [11:18] ...which apart from a few hard coded things seems nearly possible [11:19] mgz: a juju charm would be great too [11:19] mgz: I've just done the bits that interested me [11:20] that's cool, was just curious for reasoning. [11:20] mgz: it's entirely because of lucid. [11:20] roll on precise! [11:20] how do people check for branch equality these days? [11:20] in tests [11:21] So, the reasoning used to be lucid, but now it's precise instead? [11:24] jml: is, or when its not the same object comparing the bits you care about, so transport, url, revision stuff [11:24] I'm not aware of a neater option. [11:25] mgz: thanks [11:26] fullermd: huh? no. when precise is in the Canonical DC, then I'm going to switch my projects to use juju for their cloud deployment [11:27] it was an adjective joke :) [11:28] oh huh [11:28] sorry. [11:28] I do have a sense of humour, honest I do. [11:29] fullermd is a strong cheese. [11:30] I'll put you down as a reference on my resume, shall I then? :p [12:11] Hi! Is there a shortcut/prefix for specifying a colocated branch, or do I have to use the full file://...,branch=... URL? [12:13] For example, something like "bzr merge colo:other-branch" (but that doesn't work for me in bzr 2.5.0) [12:22] ok, what about getting a controldir from a brancch? [12:24] alf_: hi [12:24] alf_: there are plans to add "co:" [12:26] jelmer: good to hear that, thanks [12:26] hmm, maybe a better question is how do I programmatically create a colocated branch in tests [12:27] jml: ctrldir.create_branch(name="foo") [12:27] jelmer: and how do I get a ctrldir from a branch? [12:29] jml: br.bzrdir [12:29] jelmer: also, is there a way to get the name of a colo branch given only the Branch object? [12:30] jml: br.name [12:30] IIRC [12:30] jelmer: thanks :) [13:06] does bzrlib have something that reformats file URLs as paths? [13:08] jml: it does [13:08] my guess is that it lives in bzrlib.urlutils but I don't remember the name [13:08] ah found it [13:09] local_path_from_url [13:09] that's the one [13:25] is it possible for a branch to define configuration for plugins inside of itself, so when people branch it that config is set by default? [13:33] with cooperation from a plugin, yes [13:33] what specifically do you want? [13:35] mgz, im writing a push_hook to integrate with our jenkins instance [13:36] so it'd be nice if our projects that are set up in jenkins could define this bzr config, and then developers with the hook installed dont have to do any configuration on their own for the plugin, it's already set up in the project [13:36] all they have to do is install the plugin [13:38] lamalex: that sounds fine [13:38] can do something like `bzr config --scope=branch plugin_name.option=value` [13:39] then in the plugin look at the branch config for some behaviours [13:39] ...bah, but that doesn't propogate [13:40] right, i want it to be stored in the remote branch, say on launchpad [13:40] would have to be a versioned file in the tree with a well-known name then [13:40] so would that be a new store I'd have to define? [13:41] vila may have better ideas [13:42] config option propagation... [13:42] open problem right now, will *LOVE* to have it defined properly... [13:43] version controlled config stores, same [13:44] lamalex: could you re-phrase your needs in higer level language for a second, there are a lot of tricks that can be achieved without the two features mentioned above nor implementing your own store [13:45] lamalex: when and where does the plugin run ? On user's machine or on the jenkins slave ? [13:45] or both ? [13:46] vila, it runs on the users machine [13:46] lamalex: for example, your plugin can very well write to the remote branch config === mrevell_ is now known as mrevell [13:47] vila, when I do bzr push lp:~alexlauni/unity/unity.flaming-launcher-icons my plugin does a bunch of magic to tell jenkins to make a job and start running our unity test suite on my unity branch [13:47] so you can use the remote branch.conf and don't need to implement any more stuff (just make sure you write-lock the right branch and set the config option named as mgz suggested) [13:47] since it's a push_hook, you should already have access to the right branch [13:48] yah, im asking about config because i dont want the other developers to have to set anything up [13:48] dunno if it's still locked but since it's pushed too obviously the user has write access [13:48] lamalex: well, the point of the config is that the user is in control *if needed* [13:49] s/the/one/ [13:49] s/the/one point/ grr [13:49] bah, tyop crisis [13:49] right, the user should be able to disable it or enable it on their own but i'd like our project maintainer to be able to set default for the project [13:49] * vila nods [13:49] Hello all. I would like to stop tracking changes to a .htaccess file but leave it it the working tree. Is there a way to do this? [13:50] ninjix: `bzr rm --keep FILE` [13:50] lamalex: ha, tricky, so from the hook you'd want to read "trunk" and set something in the pushed-to branch ? [13:51] mgz: so this will leave the base version for the other devs and users? [13:51] vila, hm no not exactly [13:51] please enlight me :) [13:51] yah im trying to find the right wording [13:52] there is currently one option I can think of that smells like a project setting: child_submit_to [13:52] ninjix: no, the normal way of doing something like that is having a template or example versioned, and leaving the real file unversioned [13:53] lamalex: bzr help child_submit_to [13:53] Where submissions to this branch are mailed to. [13:53] i dont think that's it [13:53] mgz: thank you. you've confirmed my hunch [13:53] the option is really jenkins on or off [13:53] that's pretty much it [13:54] oh [13:54] but i want it to be defined in the trunk branch that lives in launchpad [13:54] so when a developer branches, it's set inside their branch and when they push their branch gets submitted to jenkins [13:54] but for projects that dont have it set, nothing happsn [13:55] hmm, yeah, project-wide setting [13:56] and your jenkins will walk lp to find such branches ? [13:57] and if the setting is changed on lp's trunk how do you want that to propagate ? [13:57] no jenkins won't walk LP that's the point of the push hook- to not have to poll launchpad [13:58] oh, you mean, the user push *and* start a jenkins job then ? [13:58] vila, i'd guess like any other new revision? branches of trunk should update on pull [13:58] vila, yup [13:59] we're working on building a continuous integration workflow in product strategy [13:59] why not just have the plugin query the trunk's config then >? [13:59] as in go over the net and read from trunk's config? [14:00] yup, you already went over the net to push.. [14:00] right im not whining about network traffic im just making sure i understand [14:00] k [14:01] so really you'd be reading from parent_branch though right? [14:01] yes [14:02] ideally I would think this is for merge proposals so the *target* branch would sounds more appropriate [14:02] it's not for merge proposals [14:03] k [14:03] we want the tests to start running long before that [14:03] for the entire development life cycle of the branch [14:03] even if people push multiple times before submitting ? [14:04] yah for sure [14:04] k [14:04] so by the time you propose a merge you already know your code is clean [14:04] k [14:04] and the reviewer knows the code is clean [14:04] and has been tested in a clean env [14:05] the only brittle point I see is that parent_branch may be a local mirror of lp's trunk, but you may find a way to fix that [14:05] which is why i wanted the config to just come down when you branch trunk [14:06] doomed if you do doom if you don't ;) [14:07] lamalex: starting with parent_location should cover most of the use cases and allow you to validate the whole stuff though [14:08] lamalex: the trunk will always be on lp for your plugin right ? [14:08] yah [14:09] lamalex: I thought you already sorted out what the project name was so you may as well just query lp: no ? [14:09] ah yah that's valid [14:11] so now the question is how do i read from a remote config === mrevell_ is now known as mrevell [14:12] lamalex: you get the branch first then: br.get_config_stack().get(opt_name), done [14:13] do you think it's possible to import the bits from the launchpad plugin that translate lp:project into a real url for getting the trunk branch? [14:18] vila, ^ [14:18] lamalex: sure enough, but bzrlib can probably do that for you [14:19] lamalex: bzrlib.branch.Branch.open('lp:bzr') should just worl [14:19] work [14:21] oh far out [14:22] that's awesome [14:23] ok, i think i've got what i need. that's a lot vila and mgz [14:25] vila, hm hah finally how do i set an option on trunk? [14:26] lamalex: bzr config -d lp:bzr i.am=a.happy.camper [14:26] :) [14:26] ha, -d saying directory in the help doc is a little misleading [14:26] but excellent [14:26] thanks! [14:26] lamalex: don't forget to register your option (lazily of possible) [14:27] in my hook? [14:27] lamalex: look into the po_merge plugin (one of the last written so hopefully respecting most of the unspoken rules ;) [14:27] lamalex: in your plugin [14:28] well, my "plugin" is a push hook [14:28] lamalex: registration gives you 'bzr help ' for free [14:28] it's a plugin, that's all that matters ;) [14:32] heh ok [14:33] mgz: thanks for the review ! Some additional questions in the comments if you don't mind ;0) [14:34] * mgz refreshes [15:02] vila, Branch.open('lp:unity') doesn't work, Unsupported protocol for url "lp:unity"- do i need to import something? [15:03] bzrlib.plugins.launchpad [15:04] hmm, yeah, the lp plugin should be imported first, I wonder how you manage to execute your Branch.open without importing it though... manual testing ? [15:05] or loading all plugins? [15:05] lamalex: don't worry about importing order though, the way we implemented plugin import relies heavily on python sorting that for us [15:06] ha, good point from LarstiQ (hey !), but from a push hook, I except plugins to be imported well before that [15:06] vila: ah hmm, good point [15:06] * LarstiQ digs deper [15:06] deeper [15:06] vila, so i set my option on a branch like, bzr config -d lp:tictactoe jenkins.run_on_branches=true [15:07] but when i get('jenkins.run_on_branches') i literally get nothing back [15:08] lamalex: what does 'bzr config -d lp:tictactoe' display ? [15:08] lamalex: bzr version ? [15:08] 2.5 [15:09] k [15:09] in an ipython shell at least: 'import bzrlib.plugin; bzrlib.plugin.load_plugins(); from bzrlib.branch import Branch; Branch.open("lp:bzr")' works [15:10] vila, http://paste.ubuntu.com/886442/ [15:11] lamalex: no 'branch:' there, something is wrong :-/ [15:11] oh [15:12] bzr config -d lp:bzr doesn not work >-/ bzr config -d bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ does [15:12] * vila cries [15:13] heh [15:15] lamalex: bug filed, but you shouldn't be affected in your plugin, if you get a branch (and the right one) this should be ok [15:16] bug #957049 [15:16] Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 [15:16] ;) indeed- which is just a pain for setting the option but ill make a note of that === yofel_ is now known as yofel === Quintasan is now known as trolllogger === trolllogger is now known as Quintasan [15:50] jelmer: I just noticed a typo in bzr-webdav info.py in the bzr_plugin_name (wedadv instead of webdav), I wonder what 'bzr_plugin_name' is useful for ? [16:05] is there a doc for the error codes? i'm getting Errno 104 when I do some postdata in my plugin and it returns a 303 code [16:13] 'the' error codes? what's the context? [16:15] mgz, i'm sending a bunch of post data to a webservice that spawns a jenkins job. that service is returning a 302 when i do getrespone, and that is causing bzr to give me errno 104 Connection reset by peer [16:15] if i just dont call getresponse() everything works fine hah! i think bzr is trapping something and getting mixed up [16:19] jelmer: lintian found a typo ? Can you introduce this nice guy to me ? ;-D [16:19] vila: lintian is a tool that checks debian packages [16:19] jelmer: I know :) [16:19] vila: lint + debian :) [16:19] but how did it found a typo like that is what makes me wonder ;) [16:19] http://lintian.debian.org/full/jelmer@debian.org.html [16:20] vila: bzr_plugin_name is used by things like bzr-plugin-info, though that isn't in wide use today [16:20] I'm guessing the tyop was mine? [16:21] did you look at the blame jelmer? :) [16:21] mgz: I would take it as a personal offense if you're trying to steal *MY* typos [16:21] :-D [16:21] wait, which typo are we talking bout? [16:22] mine! [16:22] jelmer: wow, amazing [16:22] extention [16:22] see ? MINE ? My preciooouuuuss [16:23] hmm, and fullermd is not even around.... must be spring coming... [16:27] ok, the builtin's one was from Marius and the xml_serializer's one from mgz :-( [16:28] ha, you'll have to make your own typos [16:35] jelmer is on a lazy mission. [16:59] jelmer, around ? [16:59] i just hit bug again https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/923688 [17:00] Ubuntu bug 923688 in bzr-builddeb "bzr crashed with AttributeError in tree_unapply_patches(): 'DirStateRevisionTree' object has no attribute 'last_revision'" [High,Fix committed] [17:00] and went looking [17:00] build failed [17:00] https://launchpad.net/ubuntu/+source/bzr-builddeb [17:00] build log: https://launchpadlibrarian.net/95953060/buildlog_ubuntu-precise-i386.bzr-builddeb_2.8.3_FAILEDTOBUILD.txt.gz [17:00] smoser: it's on my list of things to fix, but it's an odd bug [17:00] the build bug? [17:01] yeah [17:01] suck. [17:01] so i keep hitting this... is there a way i can easily not hit it? [17:01] that test failure only occurs as part of a chroot package build, and doesn't happen on sid [17:01] smoser: "bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb" [17:01] gracias === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [21:31] hey guys [21:31] So, i have a svn 'dump' file by using rsvndump, do you guys know of any way to get this into bzr, or into fast-export or something? [21:36] mgrandi: rsvndump? [21:36] mgrandi: "bzr svn-import" supports svn dump files [21:37] rsvndump lets you make a 'dump' of the repository when you don't have access to the repo [21:37] k i'll try that [21:38] mgrandi: bzr-svn can also operate against remote svn operations directly [21:38] so it can basically get a repo from a svn repo? [21:40] (since i don't have access to the repo, its on some server) [21:42] mgrandi: yes, you can just specify "bzr branch svn://path/to/some/branch" [21:43] handy! [21:43] i'll do that if it can't import the dump file [21:44] mgrandi: bzr svn-import will actually reconstruct the repository locally, and then talk to that [21:46] ok [21:47] so, when i do bzr-svn import, does that create a repo? [21:47] i told it to create it in a branch and now i think its confused [21:48] mgrandi: yes, though it does it on the fly though in a temporary directory [21:48] mgrandi: how do you mean? [21:49] it imported it fine, into a folder that was a branch, that i created using bzr init [21:49] it told me to do bzr checkout to create a working tree, but now it says a control directory already exists in the folder [21:49] mgrandi: "bzr branch" creates a new branch, so if you specify an existing location it will indeed not work [21:50] so the folder i gave it is now a repo? [21:50] even though it started out as a branch? [21:51] bzr info just says its a standalone tree and i dunno what that is [21:52] mgrandi: bzr svn-import creates a repository with multiple branches in it [21:52] ah [21:52] mgrandi: the location you specified would be the root of the repository; if you had a standard layout in svn [21:53] it said something like 'using layout trunk0" [21:53] so branch that? [21:54] mgrandi: if you go to LOCATION/trunk you can run 'bzr co' there to create the tree [21:55] (this is why i hate svn haha) [21:56] ok [21:56] honestly i think i found a bug [21:56] cause i re did it and now i have a 'trunk' folder [21:56] but before, when i had the TO_LOCATION argument as a folder that was already a branch [21:56] it didn't create any of the folders and was branching 0 revisions, etc [21:58] and before, it said the folder was a 'standalone tree' but when i did it (correctly i guess) it says shared repository now [21:58] mgrandi: I guess it said it was a 'standalone tree' because you manually ran 'bzr init' beforehand [21:59] yeah [21:59] i think it just got confused or something, i dunno [22:03] also, im not sure if the 'parent branch' should be set to the temporary folder =P [22:04] mgrandi: heh, that's a good point [22:05] parent branch: /var/folders/hg/sz267ft96k34rjpc5zb23p200000gn/T/bzr-svn-dump-hAFefy/trunk [22:05] not the most useful thing [22:05] mgrandi: can you file a bug? [22:05] yeah, on bzr-svn? [22:05] yep [22:06] ok. and do you think that the thing i was describing about doing svn-import on a directory that is already a branch is a bug? [22:06] cause it didn't create the trunk/ folder like it was supposed to and it said it had no revisions [22:07] mgrandi: I'm a bit unclear as to what you've done exactly [22:08] mgrandi: if you can reproduce it, a bug would be useful [22:18] k jelmer, this is what i mean [22:18] http://bpaste.net/show/25314/ [22:18] at the bottom, when i cd into trunk there is no "trunk" folder [22:19] mgrandi: that's expected behaviour, "bzr init trunk" creates a branch [22:19] and i cant figure out how to check out [22:19] mgrandi: "bzr svn-import" creates a repository [22:19] mgrandi: and creates directories under the repository for each branch that was in the svn repo [22:19] but here it doesn't though [22:20] mgrandi: according to your pastebin it does [22:20] mgrandi: in other words, the "bzr init trunk" isn't necessary [22:20] yeah [22:20] i created a trunk folder, made that a branch [22:21] but then when svn-import imports the stuff in there, there is nothing under the trunk/ folder besides .bzr [22:21] as you can see in lines 8-14 [22:21] mgrandi: try 'bzr svn-import ../ellerrepodump.dat elerrepo' [22:21] that will create a repository in elerrepo [22:21] yeah [22:21] and a branch in elerrepo/trunk [22:21] i did that, and thats the correct way [22:21] you can then run "bzr co" in elerrepo/trunk to crete a working tree [22:22] however i feel that it shouldn't try and import into a branch or else you get a weird state [22:22] mgrandi: it doesn't really import into the branch [22:23] yeah [22:23] but then how do you check out when you do this though [22:23] i'm just wondering if this is intended behavior cause it seems like you just have a repo/branch that you can't do anything with [22:23] mgrandi: go to elerrepo/trunk (or in your case trunk/trunk) and then run 'bzr co' [22:24] do i create that directory if it doesn't exist? [22:24] mgrandi: hmm, if you have an older version of bzr-svn it might create colocated branches [22:24] mgrandi: I would suggest just starting from scratch and not using 'bzr init trunk', but just using 'bzr svn-import elerrepo' [22:25] ehm [22:25] 'bzr svn-import ../foo.svndmp elerrepo' [22:25] i know that is the correct behavior, by just using svn-import [22:25] but im just saying it lets you create this weird state [22:25] that oyu can't do anything with [22:25] seems like a bug, and it should not do that [22:25] or error out [22:27] mgrandi: what version of bzr-svn are you using? [22:27] mgrandi: can you try running 'bzr branches' in trunk? [22:27] ah, actually [22:27] can you run 'bzr up' in trunk [22:27] svn 1.1.2 [22:28] ok, bzr up did it. [22:28] mgrandi: this is fixed in 1.2.0 I think [22:28] in 1.1.2 it creates colocated branches even if you don't specify --colocated [22:28] what does it do there? [22:28] ahh [22:28] in 1.2.0 it would create trunk/trunk [22:29] it doesn't seem to of created a colocated repository [22:29] or i dont know if its using the plugin version where it has like .bzr/branches or whatever [22:32] mgrandi: what does "bzr branches --no-plugins" say? [22:32] *(default) [22:32] yeah, that's the default colocated branch [22:35] as in a 2.5 coloated branch? [22:35] mgrandi: yes [22:35] ok [22:35] so, how do i get bzr-svn the latest verison? just from launchpad? or is there an updated installer [22:36] mgrandi: yep [22:36] I'm not sure if there is an updated installer [22:36] i'll try and see if it works [22:43] jelmer: doing it with bzr-svn 1.2.1 gives this: bzr: ERROR: Repository CHKInventoryRepository('file:///Users/markgrandi/Desktop/try2/.bzr/repository/') is not shared. [22:43] so i guess that works out [22:45] mgrandi: that's correct, indeed [22:51] and bzr-svn still has the parent branch thing so i'll report a bug on that [22:51] thanks [22:59] jelmer: https://bugs.launchpad.net/bzr-svn/+bug/957511 [22:59] Ubuntu bug 957511 in Bazaar Subversion Plugin "svn-import produces branches with tmp directories as parent branches" [Undecided,New] [22:59] mgrandi: thanks [22:59] mgrandi: (note that this bug is specific to using bzr svn-import with svndump files) [23:00] oh [23:00] i'll edit it [23:00] IÇÇe already done so :) [23:02] k [23:15] mgrandi: done :) [23:23] that was fast! [23:24] it was a really simple fix [23:26] yeah, just add remember_parent=False a couple places