=== medberry is now known as med_out [09:10] morning all [09:23] hi jam! [09:23] want to dial in? [09:23] certainly [09:23] * bialix waves [09:32] jelmer, spiv: bug 597686 was the one I was talking about at breakfast [09:32] Launchpad bug 597686 in Bazaar "bzr: ERROR: [Error 145] The directory is not empty: u'C:/Users/exarkun/twistedbot/windows7-64-py2.6-select/Twisted/.bzr/checkout/limbo/new-7/words'" [Medium,Confirmed] https://launchpad.net/bugs/597686 === hunger_ is now known as hunger [09:36] jam: you need ":multiuser on" and ":addacl jriddell" i think [09:36] if they fail, i think root needs to allow the change [09:47] Riddell: "screen -x jameinel/" [12:16] jam do you know what's up with https://answers.launchpad.net/loggerhead/+question/80612 [12:18] poolie: I posted an info request. I don't specifically know on that part. === zyga-afk is now known as zyga [12:35] Riddell: https://code.launchpad.net/~jameinel/bzr/2.4-update-basis-by-delta-781168/+merge/61232 [13:48] mgz: fwiw I've pushed those experimental transform.py tweaks to lp:~spiv/bzr/treetransform-robustness-597686 [14:18] http://stackoverflow.com/questions/6009280/git-gui-like-bzr-explorer-but-for-git [14:23] spiv: lp:~gz/bzr/treetransform_create_file_interrupt_597686 has the tests in their current state [14:23] bialix: haha, nice answer :) [14:23] I know somebody from canonical did the same trick in the past [14:25] spiv: the comments for that question is very funny too === med_out is now known as medberry [14:49] i presume if i see _th [14:49] i presume if i see _this_, things are very very bad: bzr: ERROR: The file id "x_Matt_Zimmerman__Sun_Mar_13_00:51:19_2005_1366.3" is not present in the tree . [14:52] it depends what you are doing [15:56] Hi there [15:57] I'm trying to use the bzrlib with python, but I don't know where to start (the auto-documentation isn't that descriptive). What I want to do is just read the revision log of a repository. Could someone help? [15:58] etenil: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html [15:59] oh I didn't find this [15:59] thanks [15:59] etenil: (and other docs in http://doc.bazaar.canonical.com/bzr.dev/developers/, like http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html, will probably help) [16:00] awesome, it's exactly what I looked for [16:00] thanks a lot spiv [16:07] etenil: you're welcome :) [16:22] Riddell: we don't use Fix Committed for bzr bugs: http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html#bug-status [16:28] poolie: added to http://webnumbr.com/profile?name=https%3A%2F%2Flaunchpad.net%2F~spiv [16:31] poolie: http://webnumbr.com/.join%28launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all%29 [17:07] james_w: I'd like to ask you a question about something odd the UDD importer does, when you have some time? [17:08] maxb, I can talk now if you like [17:08] Specifically, I'm confused about why the importer uses the method it does for plucking out the upstream branch [17:08] This is in import_package.py extract_upstream_branch [17:09] What it does, is to examine all the upstream-* tags, and pick the revision with the highest revision timestamp === beuno is now known as beuno-lunch [17:10] This has been causing me problems because of an import where the highest timestamp is not actually the highest debian version [17:10] so it should just use highest debian version? [17:10] That is one option [17:11] The existing code in bzr-builddeb uses two different algorithms in different places [17:11] merge-package, import-dsc and merge-upstream look at the changelog in the branch, take the upstream version from that, and find the appropriate upstream- tag [17:11] import-upstream reviews all upstream-* tags and picks the one with the highest debian version [17:12] I was wondering if you had any insight on how the importer came to be using a third, different algorithm [17:16] I think it was actually the first alogrithm :-) [17:16] but I don't really know why there are three versions [17:17] It looks like you introduced the algorithm in udd r36, replacing the old algorithm based on find_changelog [17:17] * jelmer 's ignorance is probably the cause of one of the extra versions [17:17] Ironically, the fix I've developed for the problem I'm having is effectively reverting back to the find_changelog algorithm [17:17] "Hopefully fix the problems with resurrecting the upstream branches. [17:18] is what you said back in 2009 :-) [17:18] yeah, now I wish I had been more specific [17:21] Hm. This poses a problem, because the current algorithm is definitely broken for my current pet testcase [17:22] Whereas the other algorithm was presumably broken for something in the past [17:28] Thinking of webnumbrs: http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 [17:30] The example on how to get a revision doesn't work here: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html [17:31] It complains that the module repository doesn't contain any "get_revision" function [17:31] mistake? [17:36] mmh, maybe I don't understand well [17:36] let's say I have a done a bzr branch /tmp/branch/ [17:37] then should I consider /tmp/branch as a repository in itself? [17:39] hum, that did it [17:40] not as simple as expected [17:49] ok so the example at http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html is indeed incorrect and should read as http://dpaste.com/543458/ [17:49] http://dpaste.com/543461/ wrong paste :( [17:50] dunno who I should contact to correct it === beuno-lunch is now known as beuno [19:06] mgz: voila https://code.launchpad.net/~jr/qbzr/778012-user-error-handling/+merge/61289 [19:06] etenil: actually, the way it is written is correct, but assumes you already have a Branch object named "branch". === medberry is now known as med_out [19:15] james_w: I have an udd importer branch with 1 approve review. What are the next steps? (This change is separate to what I was asking about a few hours ago) [19:15] you can go ahead and merge it [19:15] then someone on the bzr team can help you get it deployed [19:17] james_w: I'm not an ~udd member - jelmer is, but wasn't clear on whether it was OK to land without an OK on deploying it from someone [19:17] yeah, I think you can go ahead [19:18] Alright, so then I just have to ask around for a ~canonical-bazaar member who is confident in deploying the change themselves? === deryck is now known as deryck[lunch] [19:26] maxb, yeah [19:55] Hi all, I've set up a no-trees shared remote repository -nested style- [19:55] I branched it, checked it out [19:56] to my local machine, added source [19:56] committed [19:57] what is the preferred method to publish /auto mirror /push a copy of the working tree to a directory [19:57] ? like /var/www/site? [19:57] I tried export but the dir is empty [19:59] I am trying to automirror the shared remote repository (which has no working tree)) === deryck[lunch] is now known as deryck === med_out is now known as medberry [20:50] Do branches that contain a debian/ folder need a packaging recipe? [23:38] hi [23:38] hm.. i think i answered my question by relooking at a directory string [23:38] heh