[00:20] <mwhudson> bzr tags -d $remote -> 16 vfs calls
[00:20] <mwhudson> that seems like a lot
[00:21] <mwhudson> i guess it's hardly been an optimizing target :)
[00:21] <jelmer> mwhudson: patches welcome? :-P
[00:21] <lifeless> surprisingly many
[00:22] <mwhudson> i guess _ensure_real implies a bunch of vfs calls?
[00:22] <jelmer> I guess we don't have a HPSS call for retrieving tags yet
[00:22] <lifeless> tonnes
[00:22] <lifeless> we do
[00:22] <lifeless> it returns the tags dict bytes
[00:22] <lifeless> IIRC
[00:22] <mwhudson> yeah, i mean, pull does the moral equivalent of 'bzr tags' i guess
[00:23] <jelmer> the /moral/ equivalent?
[00:23] <mwhudson> in other news, if some magic could happen where bzr tag --delete $tag; bzr push --overwrite removed $tag from the remote branch, that would be nice too :)
[00:23] <mwhudson> that's obviously a more subtle problem though
[00:26] <george_e> Quick question... I'm trying to store a password in ~/.bazaar/authentication.conf that has a '#' in it.
[00:26] <george_e> How can I do that?
[00:27] <mwhudson> huh, i think the vfs calls result from translating the revid into a revno
[00:27] <mwhudson> yeah, --show-ids -> 0 vfs
[00:50] <george_e> Anyone?
[00:50] <bob2> http auth?
[00:51] <mwhudson> george_e: well, i think it's parsed with configobj so i think your question is equivalent to "how do i put a value containing # in an .ini style file"
[00:51] <george_e> mwhudson: I got it.
[00:52] <george_e> I needed to quote it.
[00:52] <mwhudson> ah ok, cool
[00:52] <george_e> Thanks.
[04:25] <poolie> hi spiv?
[06:42] <george_e> I'm a little confused when it comes to working trees... I have a branch on a Windows server...
[06:43] <george_e> ...and on my own local machine, I ran 'bzr pull ftp://...' to checkout the code.
[06:43] <george_e> ...then I made some modifications to the code and did 'bzr push ...'
[06:43] <george_e> ...but the code on the server was not updated until I logged in to the server and ran 'bzr update'.
[06:43] <george_e> Is there some way I can have the code on the server automatically get updated?
[08:16] <sbarcteam> hi guys.
[08:17] <jam> morning all
[08:17] <sbarcteam> with svn one can checkout any subtree of a readable repository. this is convenient for various reasons. What is the way of doing this with bzr ? (don't think I'm starting some kind of flamewar)
[08:18] <poolie> hi jelmer, riddell
[08:18] <poolie> oops, jam
[08:18] <poolie> sbarcteam: check out the whole thing then use views to narrow it down
[08:20] <sbarcteam> poolie, it is nice when you have a small "whole thing".
[08:21] <sbarcteam> basically, we have some graphics, and other "content" related materials inside the version control.
[08:21] <poolie> i agree it would be useful
[08:22] <sbarcteam> I can see there's a design doc called "NestedTrees".
[08:22] <sbarcteam> (in launchpad)
[08:22] <sbarcteam> I wonder where does this thing is standing as of now ?
[08:22] <sbarcteam> (sorry for english grammar)
[08:23] <sbarcteam> I wonder where is this thing standing as of now ?
[08:24] <maxb> It's considered unfinished
[08:25] <maxb> uhoh, what? Is someone on the case with all those UDD failures?
[08:25] <maxb> Please tell me people haven't been removing ~ubuntu-branches without replacing the importer's needs
[08:26] <lifeless> the importers needs were discussed with james_w, poole and the techboard
[08:26] <lifeless> it should be allowing any uploader to push to any official branch
[08:26] <maxb> it's the set_official API call that is getting a 401 unauthorized
[08:27] <lifeless> that's also gated on uploader I think, though perhaps that patch hasn't landed yet
[08:27] <maxb> (<SourcePackage <Distribution 'Ubuntu' (ubuntu)> <DistroSeries u'lucid'> <SourcePackageName 'linux-meta-mvl-dove'>>, 'setBranch', 'launchpad.Edit')
[08:27] <lifeless> but if the patch hasn't landed the old rules should be applying
[08:28] <lifeless> ah, perhaps frozen series are going to be a head-desk moment.
[08:28] <lifeless> wgrant: ^ thoughts?
[08:29] <maxb> (<SourcePackage <Distribution 'Debian' (debian)> <DistroSeries u'experimental'> <SourcePackageName 'darcs-monitor'>>, 'setBranch', 'launchpad.Edit')
[08:30] <maxb> The importer also needs to be able to set official branches for Debian
[08:36] <makinen> is it possible to push one file?
[08:37] <makinen> I've made a bunch local commits but I'd like to get only one file pushed to the main branch
[08:38] <bob2> not really
[08:38] <bob2> commits are the thing you push
[08:38] <bob2> you could rewrite I giess
[08:39] <makinen> ok, is it then possible to commit the merged changes only?
[08:41] <makinen> I could use --no-strict option with push to omit the uncommitted local files but before pushing I have merge the changes from the main branch
[08:48] <vila> makinen: commit whatever you want to push is, I think, what bob2 said
[08:48] <bob2> bound branches lead to confusion :/
[08:49] <wgrant> lifeless: By frozen you mean released?
[08:52] <lifeless> thingy :P
[08:52] <makinen> bzr: ERROR: Selected-file commit of merges is not supported yet
[08:52] <makinen> :(
[08:53] <bob2> don't try to break up merges
[08:53] <bob2> if you insist, bzr revert --forget-merges
[08:53] <wgrant> lifeless: FROZEN should be OK. CURRENT/SUPPORTED/OBSOLETE won't be.
[08:54] <lifeless> wgrant: why won't they be?
[08:55] <wgrant> lifeless: Because uploads to the release pocket of them are rejected.
[08:55] <wgrant> lifeless: So you can't set the branch for the release pocket.
[08:56] <lifeless> does soyuz have a test that will francis should use?
[08:56] <wgrant> Not sure.
[08:56] <wgrant> I need to go now, sorry.
[08:57] <lifeless> viao
[09:01] <gour> jelmer: my hg import failed again - http://launchpadlibrarian.net/73472512/gour-myclientbase-trunk.log
[09:06] <Riddell> buenos dias
[10:03] <Riddell> jam: what's the status of your verify signatures plugin?
[10:03] <jam> Riddell: really-really-old. Like written for bzr-0.xx
[10:04] <Riddell> jam: is there a reason nobody has implemented signature verification with pgpme?
[10:04] <jam> Riddell: at one point we looked at the gpg python stuff, but at that time, they were all pretty bad
[10:05] <jam> I'm hoping things have gotten better
[10:05] <jam> (like segfaulting, etc)
[10:10] <Riddell> jamesh: have they? :)
[10:15] <jam> vila: looking here: http://babune.ladeuil.net:24842/job/selftest-windows/444/
[10:15] <jam> it says "3 failures" but only shows 1 failure???
[10:16] <jamesh> Riddell: I half ported jam's signing plugin to my pygpgme binding.
[10:17] <jamesh> the interesting thing would have been to add things like a commit hook to prevent merging an unsigned revision, or to only allow merges signed with known keys, etc.
[10:17] <vila> jam: click the 'Show all failed tests >>>'
[10:17] <jam> vila: so the hidden ones are ones which have been failing for a while?
[10:17] <vila> jam: no idea
[10:19] <jamesh> just not sure where I put the branch.
[12:37] <jelmer> gour: Sorry, missed that earlier. That's a known issue for which a fix is about to land.
[12:53] <CaMason_> Afternoon all. Is there a plugin or something that I can use to 'label' remote branches to make them easier to merge?
[12:54] <CaMason_> atm I have to keep asking my devs for the full path to their repo on the server - it would be good to just 'bzr merge nigel-feature-1'
[12:57] <spiv> CaMason_: there's the 'bzr bookmarks' plugin.
[12:57] <CaMason_> that sounds promising :D
[12:57] <spiv> https://launchpad.net/bzr-bookmarks
[12:57] <CaMason_> thanks, looks good to me
[13:03] <CaMason_> works great, thanks
[13:38] <gour> jelmer: any eta? it's not a rush, just curious what to expect
[13:39] <jelmer> gour, it's already landed in launchpad's development branch, just needs to be deployed.. should be about a week
[13:51] <gour> jelmer: thank you
[15:39] <smoser> hi, can i ask for lp:ubuntu/euca2ools to be kicked ?
[15:39] <smoser> http://package-import.ubuntu.com/status/euca2ools.html
[16:16] <Riddell> smoser: kicked in which way?
[16:17] <smoser> sent mail to ubuntu-distributed-devel
[16:18] <maxb> In the requeue_package.py --full sense
[16:19] <maxb> but that's all a moot point bug 797088 is fixed
[16:19] <jelmer> urgh :-(
[16:20] <maxb> Yes.
[17:01] <poolie> hi all
[17:01] <poolie> ouch
[17:27] <maxb> So about this ouch... is anyone addressing it?
[17:51] <maxb> https://code.launchpad.net/~maxb/udd/797088-workaround/+merge/64576
[17:53] <maxb> spiv: are you actively PPing right now, perchance?
[18:02] <poolie> spiv was on holiday monday/tuesday
[18:02] <poolie> and out of town
[18:02] <poolie> at the moment it's 3am in australia but i think he will be piloting later
[18:02] <poolie> suggest you mail him
[18:02] <poolie> or i could
[18:03] <poolie> review this
[18:05] <poolie> maxb: can you land it or do i need to?
[18:06] <maxb> I can land - can you deploy? :-)
[18:06] <poolie> yes, tell me when
[18:07] <maxb> done
[18:07] <maxb> And thanks :-)
[18:07] <maxb> and ./requeue_package --all-of-type cups will flush the backlog
[18:08] <maxb> Which should go pretty quickly since the imported branches are sitting on jubany's disk just waiting to be pushed
[18:08] <sinzui> jelmer: ping
[18:08] <maxb> we have a pending request for "./requeue_package.py --full euca2ools" as well, if you wouldn't mind whilst you're there
[18:10] <james_w> maxb, thanks for the workaround
[18:10] <jelmer> sinzui, hi
[18:10] <sinzui> jelmer: I want to fix bug 796856 . I have been fixing gtk3 bugs in my own tools and I think I understand all the issues. I do not know if we want a new series for gtk3, or if you want a branch that can be merged into trunk
[18:12] <jelmer> sinzui: I think a separate series is probably a good idea, at least while we're still working on gtk3 support
[18:12] <jelmer> I tried to do a combi gtk2/gtk3 branch a while back and it got too messy
[18:13] <sinzui> jelmer: I can fork trunk tonight and start working on it.
[18:14] <jelmer> sinzui, cool :)
[18:14] <jelmer> sinzui: you're welcome to join ~bzr-gtk if that helps in setting this up
[18:14] <sinzui> fab. I will apply
[18:17] <poolie> hi sinzui, jelmer
[18:18] <poolie> james_w, so are you doing that for maxb or should i?
[18:18] <james_w> poolie, I'm in a meeting, so if you are free could you do it?
[18:18] <jelmer> hi poolie
[18:18] <jelmer> sinzui: welcome :)
[18:39] <mgz> jelmer, can you use your newly found magic powers on bug 790268
[18:45] <jelmer> mgz: Magic fairy dust has been applied to bug 790268
[18:45] <mgz> thanks!
[18:46] <vila> jelmer: (-:
[18:46] <mgz> okay, that's another misconfigured locale one, the bug that was duped against it was etckeeper
[18:47] <mgz> I'll move the one from before to the etckeeper package, and dupe against that instead
[18:47] <jelmer> we really need a consistent way to deal with these unicode -> fs encoding bugs
[18:48] <mgz> poolie put up some sensible suggestions on the list
[18:56] <cordeiro> Hey, I have a (probably silly) question. :) I've separated repositories that I would like to combine in one without loosing the history of the files. Each rep. have the history of a research paper and now I want to combine them into one that will (finally :)) hold my thesis. What is the best approach to create this new rep?
[18:59] <jelmer> cordeiro, you can merge them into a single repository using "bzr merge" or "bzr join"
[18:59] <cordeiro> I can do that even if they don't have a single base revision?
[18:59] <cordeiro> (each one was created independently)
[18:59] <jelmer> cordeiro, yes, though you'll have to force the merge ("-r0..-1")
[19:00] <cordeiro> Ahh... this is the astuteness that I was missing. :)
[19:01] <cordeiro> Thanks, jelmer!
[19:02] <maxb> poolie: Hi, can you let me know which bits of jubany-wrangling you did, so I know what I still need to ask for?
[19:21] <poolie> hi maxb, have not done any yet
[19:22] <poolie> will do them now
[19:22] <maxb> many thanks. to recap, and ensure we're both on the same page:
[19:22] <maxb> * update deployment of lp:udd
[19:23] <maxb> * ./requeue_package --all-of-type cups
[19:23] <maxb> * ./requeue_package.py --full euca2ools
[19:23] <maxb> uh, missing .py, but you know what I mean
[19:23] <poolie> thanks for that
[19:24] <poolie> udd updated
[19:27] <poolie> all done
[19:28] <maxb> Excellent, I shall check status page when the cronjob has fired
[19:34] <maxb> poolie: Oops! I broke it :-/   Apparently I planned out my change, but then didn't commit it all. I've reopened https://code.launchpad.net/~maxb/udd/797088-workaround/+merge/64576 with another revision.
[19:36] <poolie> ok
[19:37] <maxb> I feel silly. I spent so long checking all call-sites and adding a docstring, that I didn't actually make the core of the change.
[19:37] <poolie> oh well, that doesn't reflect well on my code review either
[19:40] <poolie> ok, please merge that
[19:41] <maxb> pushed
[19:43] <poolie> requeue them again?
[19:43] <maxb> ./requeue_package --all-of-type cups
[19:43] <maxb> uh, .py
[19:44] <maxb> And as for euca2ools, ideally kill its import_package.py process and ./requeue_package.py euca2ools
[19:45] <Uber_Geek> hello,  I was wonder if there was a guide for SVN users to migrate to BZR
[19:45] <poolie> done
[19:47] <maxb> Thanks poolie  - I'm just staring at the failures page and am wondering if somehow some of these are ending up under a different traceback.
[19:47] <jelmer> Uber_Geek, see http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-svn-users.html
[19:47] <Uber_Geek> sweet, thanks
[19:57] <maxb> Something very very wacky has happened, we've got 700 new failures, but I can't see any obvious reason why they would be related to current goings on
[20:03] <gour> any idea what might be cause of "bzr: ERROR: Invalid http response for https://github.com/chillu/silverstripe-book.git/info/refs: Unable to handle http code 405: Method Not Allowed" ?
[20:05] <maxb> I think github only supports certain kinds of http access to repositories, which does not include the kind bzr-git wants to use
[20:05] <maxb> You should be able to use git:// instead
[20:06] <jelmer> yeah, you need git://
[20:06] <jelmer> the github http server only supports the smart server http protocol, which dulwich/bzr-git don't support yet
[20:06] <gour> with that i get: bzr: ERROR: The remote server unexpectedly closed the connection.
[20:07] <gour> (bzr branch -v git://github.com/chillu/silverstripe-book.git)
[20:07] <jelmer> gour, that command seems to work for me
[20:08] <gour> interesting...
[20:08] <gour> jelmer: shall i try with trunk?
[20:08] <jelmer> gour, worth a shot; what version are you running?
[20:09] <gour> jelmer: 0.6.0
[20:09] <gour> 2.3.3
[20:10] <gour> let me try with trunk
[20:11] <jelmer> poolie: what was the magic incantation you did last time to get the SRU moving after it was uploaded to -proposed?
[20:12] <gour> jelmer: same problem with the trunk
[20:12] <jelmer> gour, newer dulwich perhaps?
[20:13] <jelmer> gwenhwyvar:/tmp% bzr branch -v git://github.com/chillu/silverstripe-book.git
[20:13] <jelmer> Branched 114 revision(s).
[20:13] <gour> jelmer: i've dulwich-0.7.1
[20:14] <gour> that's the latest in ports
[20:15] <jelmer> gour, server side glitch perhaps? Have you tried again?
[20:15] <poolie> jelmer: (let's describe this on the sru wiki page)
[20:15] <poolie> basically it was, download it and test it
[20:16] <poolie> perhaps then add a comment on the bu saying it's all ok
[20:17] <poolie> perhaps checking that someone else useed it is goods
[20:17] <poolie> *good
[20:17] <gour> jelmer: "Branched 114 revision(s)." - on the 5th attempt after 4 failures...so much about github glory :-)
[20:17] <poolie> then i think you need to ask a sru-team member on irc to progress it
[20:17] <poolie> i haven't worked out any non-interactive way to make it happen
[20:18] <gour> jelmer: btw, how is it that you host dulwich at samba.org? is samba project satisfied with waf build tool?
[20:37] <jelmer> poolie: ah, thanks. I'll ask
[20:38] <jelmer> gour, most of the projects I started in my personal time are hosted on samba.org
[20:38] <jelmer> gour, we're fairly happy with waf..
[20:39] <gour> nice to hear...i hope that maybe bento will be enough for my purposes...otherwise there is waf back-end support
[20:39] <jelmer> gour, not all aspects of it, but we're happy with the choice we made (there don't appear to be any good alternatives)
[20:39] <gour> fbuild?
[20:41] <jelmer> gour: never heard of fbuild, do you have a link?
[20:42] <gour> jelmer: https://github.com/felix-lang/fbuild
[20:43] <gour> downside is that it's python-3 only, although not problem for me
[20:43] <jelmer> gour, it looks interesting
[20:44] <jelmer> gour, yeah, python 3 is a no go for us for at least the next year or so (probably more)
[20:47]  * gour hopes bento will emerge into nice (python) packaging tool
[22:35] <maxb> I'm rather perplexed how we ended up with "727 packages failed with key AssertionError:<module>:main:find_unimported_versions" all of a sudden
[22:36] <maxb> Could I have a ./requeue_package.py libclass-throwable-perl, to check whether it's a persistent problem?
[22:46] <poolie> sure
[22:57] <KombuchaKip> Does the nautilus-bzr plugin hook Nautilus file renaming to bzr rename?
[22:57] <poolie> not sure
[22:57] <poolie> it seems like it should
[22:58] <KombuchaKip> poolie: Let's fine out. One sec...
[23:02] <KombuchaKip> poolie: Just tested and no it doesn't appear to. I'll add a ticket on Launchpad.
[23:03] <poolie> k
[23:06] <visik7> hi
[23:06] <visik7> how is handled the file:// protocol ?
[23:06] <visik7> can I put relative paths ?
[23:06] <visik7> like bzr brach file://../ ?
[23:06] <poolie> no, they're always absolute
[23:06] <visik7> :(
[23:06] <poolie> just use the path
[23:06] <poolie> bzr branch ../../blah
[23:06] <visik7> I cannot
[23:06] <poolie> why?
[23:07] <visik7> bzr is called from inside maven release plugin
[23:07] <visik7> and I cannot commit the absolute path in the parent pom
[23:10] <KombuchaKip> poolie: Done: https://bugs.launchpad.net/bzr-gtk/+bug/797438
[23:21] <amanica> jelmer Hi, if you have a moment can you quickly look at the question I just posted: https://answers.launchpad.net/bzr-git/+question/161452  (How do I push multiple branches into one repo on github?)
[23:22] <amanica> whoops, thought he was here now. nevermind.
[23:55] <maxb> Well, grr. We do have a new persistent problem, and I don't know why