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