[00:03] <blackboxsw> and drop the super deprecated modules part 2 https://github.com/canonical/cloud-init/pull/134
[00:03] <blackboxsw> ok EOD for me
[08:32] <mkrai> blackboxsw, Hi I get error running clour-init query all command http://paste.openstack.org/show/787808/
[14:03] <otubo> I have to work in such a different timezone, any of the maintainers here can help with the migrate-lp-user-to-github script?
[14:03] <otubo> smoser: blackboxsw perhaps are already up :
[14:04] <otubo> *I hate to work, I can't even blame the autocorrect, it's my mind that want's to leave on vacation already :-D
[14:26] <otubo> Ha! No worries smoser blackboxsw, I just figured out the problem I was having. That's my launchpad-github mapping https://github.com/canonical/cloud-init/pull/135
[14:27] <otubo> Also, I run the script with --dryrun enabled but it ended up doing the whole proccess. Perhaps there's a bug there. :-)
[14:41] <Odd_Bloke> blackboxsw: I'm seeing a bunch of automated "This bug is believed to be fixed in cloud-init in version 19.2-67" bug mail from you, with the last number changing in (what looks like) each one.  Is that intentional?
[14:43] <Odd_Bloke> Oh, I see the PR now.
[15:10] <smoser> Odd_Bloke: i just did https://github.com/canonical/cloud-init/pull/135
[15:10] <smoser> approved it, but if you can land it.. i'm not sure (i need to figure out) what the landing process is.
[15:13] <otubo> smoser: Odd_Bloke rharper blackboxsw guys, I'm leaving for the shutdown now. Thanks for the good work this year. See ya in the next decade. :-)
[15:23] <Odd_Bloke> otubo: Thanks, have a good break! :)
[15:25] <Odd_Bloke> smoser: I can't see o'tubo in our CLA spreadsheet, so I'm checking internally if we have a non-individual signature that covers them.
[15:29] <danmux> Hi, is it ok to ask for help on using cloud-init in here, it's not just reserved for development?
[15:32] <Odd_Bloke> danmux: Yep, please do!
[15:34] <danmux> ace! specifically multipart user-data and jinja2
[15:35] <danmux> Should I be using `Content-Type: text/jinja2` in place of `text/cloud-config` ?
[15:36] <danmux> (also can i confirm `cloud-init devel render` does not handle muilti-part files, just the raw template bit)
[15:38] <danmux> in which case how best can I test my multipart `user-data.txt`
[15:40] <Odd_Bloke> Hmm, good questions.
[15:41] <Odd_Bloke> I haven't really dealt with multipart user-data much myself.
[15:41] <Odd_Bloke> smoser: blackboxsw: Perhaps one of you have context to answer (some of) the above without digging into the code too much?
[15:54] <danmux> I've been digging around the code a bit, and it looks to me like it is either or thing but I'm not 100%
[15:54] <danmux> I can't tell if it would go on and honour the `template` directive - for example...
[15:54] <danmux> ```Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"MIME-Version: 1.0--MIMEBOUNDARYContent-Transfer-Encoding: 7bitContent-Type: text/cloud-configMime-Version: 1.0## template: jinja#cloud-configwrite_files:  - path: /usr/local/etc/nomad/client.hcl```
[15:55] <danmux> (oops)
[15:58] <danmux> for info `/usr/bin/cloud-init 19.2-36-g059d049c-0ubuntu2~18.04.1`
[16:25] <blackboxsw> danmux: it's been a while since I've touched that part of the code. will run a test. I think you might have had to pass text/jinja2 as content type. But, will validate and get you a working example
[16:26] <danmux> blackboxsw hang fire a sec - im able to test now
[16:26] <blackboxsw> sweet
[16:27] <danmux> hmm ok it failed
[16:28] <danmux> oh should i be editing the `.i` file ?
[16:30] <danmux> blackboxsw - ok I was running a single module again, but i think the templating is done in `init`?
[16:33] <danmux> ah - im doing something dumb
[16:45] <blackboxsw> danmux, here's what works for me
[16:45] <blackboxsw> ... sorry getting a paste together
[16:46] <danmux> (y)
[16:48] <blackboxsw> danmux: at long last https://pastebin.ubuntu.com/p/GzbR23WjQg/
[16:50] <danmux> tyvm - you couldn't paste the `mime-msg` as well blackboxsw :pray:
[16:50] <blackboxsw> to retest on your system that had already booted cloud-init. you can run the following to clean you system, force a reboot and re-run cloud-init with :     sudo cloud-init clean --logs --reboot
[16:51] <blackboxsw> ahh will do now danmux
[16:52] <blackboxsw> danmux: https://pastebin.ubuntu.com/p/XKwSf7x4bX/
[16:52] <danmux> great ty for the test advice - otherwise I should just setup a container as per your example.
[16:52] <blackboxsw> the tool in cloud-init ./tools/make-mime.py -a <your_yaml>:<mime-type>
[16:53] <blackboxsw> will generate that content for you
[16:53] <blackboxsw> if you have cloud-init source tree
[16:53] <blackboxsw> https://github.com/canonical/cloud-init/blob/master/tools/make-mime.py
[16:54] <danmux> yup - got it - ours is being generated by terraform. But with your info I'm sure i can make some progress!
[16:54] <blackboxsw> good luck :)
[16:54] <blackboxsw> hope it helps
[17:23] <danmux> Woohooo! blackboxsw that nailed it! tyvm - no I can sign off for Christmas (UK timezone) - Merry Christmas to you and to Odd_Bloke for the referral (y)
[17:23] <blackboxsw> Schweet! danmux
[17:23] <danmux> s/no/now
[17:23] <blackboxsw> good to hear
[18:05] <meena> ah, the joy of freelancing. no holidays, no vacations, no time off, no nothing
[18:06] <meena> (i think i'm mostly joking, but i can't really tell)
[18:12] <meena> https://github.com/canonical/cloud-init/pull/61#pullrequestreview-335429532 merge?
[18:18] <blackboxsw> hah!
[18:27] <blackboxsw> powersj: minor suggestion on your doc branch and I think we can land it https://github.com/canonical/cloud-init/pull/109#pullrequestreview-335437127
[18:27] <powersj> blackboxsw, fixed
[18:27] <blackboxsw> meena: I'll let Odd_Bloke close out on that review
[18:32] <blackboxsw> approved waiting on CI
[18:45] <Odd_Bloke> meena: Goneri: It's landed!
[18:54] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/136
[19:17] <meena> cool, cool, cool
[19:17] <meena> now, it's time for some refactoring
[19:20] <blackboxsw> Odd_Bloke: on it for 136. and powers I replied to your doc https://github.com/canonical/cloud-init/pull/104/files
[19:20] <blackboxsw> ooh meena, putting the fun back into refactoring :)
[19:23] <meena> "can't spell refactoring without fun" — blackboxsw
[19:24] <blackboxsw> :)   -> lunch -> coffee
[19:25] <blackboxsw> or -> coffee -> lunch .... can't decide
[19:28] <meena> i find lunch - > coffee to be slightly more conducive to having a proper post lunch sleep and then wake up refreshed
[19:29] <Odd_Bloke> "refunctoring" means "rewriting in Haskell", right?
[19:35] <meena> I'm partial to any functional language i can write, haskell i can only read
[20:28] <Odd_Bloke> powersj: blackboxsw: Let's kick off the holidays (and the decade) the right way: https://github.com/canonical/cloud-init/pull/137
[20:28] <blackboxsw> woot!
[20:30] <blackboxsw> Odd_Bloke: in the theme of dropping all the dead code:  https://github.com/canonical/cloud-init/pull/134
[20:30] <blackboxsw> your above is +2'd just waiting on CI
[20:30] <Odd_Bloke> blackboxsw: The PR I've already Approved, you mean? ;)
[20:30] <blackboxsw> hah
[20:31] <blackboxsw> ahh I'll wait for your py.27 to land and I'll close out 134
[20:31] <Odd_Bloke> Thanks for the speedy reviews!
[20:32] <blackboxsw> unfractured attention makes for light work :)
[20:49] <Odd_Bloke> Landed. \o/
[20:59] <blackboxsw> Odd_Bloke: can you confirm breakage of make config/cloud.cfg
[21:00] <blackboxsw> or powersj
[21:00] <blackboxsw> on focal it doesn't work for me as it tries to interpret $user from config/cloud.cfg.tmpl line 17
[21:00] <blackboxsw> as a required substitution param
[21:01] <Odd_Bloke> blackboxsw: Breakage of what exactly?
[21:01] <blackboxsw>     return str(selected_params[key])
[21:01] <blackboxsw> KeyError: 'user'
[21:01] <blackboxsw> make: *** [Makefile:79: config/cloud.cfg] Error 1
[21:02] <blackboxsw> no emitted 'rendered' cloud-config
[21:02] <blackboxsw> I'm unable to make that target (to generate cloud.cfg from template)
[21:04] <blackboxsw> and if I do provide a bogus user: ME to the templater.render_string(...., tpl_params)  then I get a rendered output file that subtitutes ME for $user on line 17 of  config/cloud.cfg.tmpl
[21:06] <blackboxsw> it's tools/render-cloudcfg is called by setup.py during package creation. I'm wondering why that hasn't broken our package builds too
[21:08] <blackboxsw> interesting. this works on xenial: ./tools/render-cloudcfg --variant ubuntu config/cloud.cfg.tmpl
[21:08] <blackboxsw> not on focal
[21:08] <Odd_Bloke> I have never seen these Make targets before. :p
[21:08] <blackboxsw> yeah I hadn't until I started fgreping.   so something else in the template engine is getting hung up on the $user in the config template file
[21:09] <blackboxsw> I think it may be focal only
[21:09] <Odd_Bloke> blackboxsw: What do you want me to run to reproduce?
[21:09] <blackboxsw> checking eoan /bionic I might have a trivial patch
[21:09] <blackboxsw> Odd_Bloke   ./tools/render-cloudcfg --variant ubuntu config/cloud.cfg.tmpl
[21:09] <Odd_Bloke> And what are these used for?  (Should we remove them?)
[21:09] <blackboxsw> should emit output to stdout with the rendered template
[21:09] <Odd_Bloke> It does.
[21:09] <blackboxsw> Odd_Bloke: they are used in setup.py to build the package
[21:10] <blackboxsw> but we probably can drop the makefile target
[21:10] <powersj> blackboxsw, if these were broken, how did you upload to focal?
[21:10] <Odd_Bloke> OK, so we probably shouldn't remove them. :p
[21:11] <blackboxsw> powersj: I think something in the python environment used though dh_python is succeeding there whereas direct script running through python3 does not.
[21:11] <powersj> ah
[21:11] <Odd_Bloke> blackboxsw: I can't reproduce a problem on focal.
[21:11] <blackboxsw> ok so something from where I sit
[21:11] <blackboxsw> hrm
[21:12] <blackboxsw> ahh I'm on eoan :/
[21:12] <blackboxsw> checking eoan and focal containers
[21:13] <blackboxsw> and upgrading my laptop
[21:14] <blackboxsw> ok success on focal
[21:18] <blackboxsw> ok; dirty local dev environment. Fresh eoan no problems. something I've inevitably pip installed that is colliding w/ the renders
[21:18] <blackboxsw> Odd_Bloke: powersj n/m thanks for validation
[21:18] <powersj> :D
[21:18]  * blackboxsw should work in a clean dev container to avoid thrashing
[21:18] <meena> someone post an image link or a github thingy pls
[21:22] <blackboxsw> https://imgflip.com/i/3k3kft
[21:31] <meena> excellent, previews are working.
[21:31] <meena> now, to get back to refunctoring.
[21:37] <meena> whoa
[21:37] <meena> Python2.7 is dead?!
 meena: Goneri: It's landed! <3
[21:39] <Odd_Bloke> meena: Yep! \o/
[21:40] <meena> Odd_Bloke: can i get some starting help with the refactor?
[21:40] <blackboxsw> long live python 3
[21:40] <meena> just to get the class(es) started, i can do the rest myself.
[21:41] <meena> blackboxsw: ETA for Python 4? :P
[21:44] <Odd_Bloke> meena: This is wrong point in the decade to ask for help, I'm afraid. ;)
[21:45] <Goneri> Odd_Bloke, thank you, now I will refresh the netbsd branch :-)
[21:45] <meena> Odd_Bloke: in that case, i'll just repeat all of Distros mistake, and you get to fix them next decade.
[21:45] <Odd_Bloke> meena: I would experiment with moving one of the two "*_on_{freebsd,linux}" functions onto either the Distro or Renderer classes.
[21:45] <Odd_Bloke> Which one they go on will probably depend on what makes sense in the structure of the code.
[21:45] <Goneri> I think we need a distros/linux.py and some inheritance
[21:46] <Goneri> and a lot of linux specific content should be move from net/__init__.py to this new distros/linux.py
[21:46] <meena> Goneri: that's what distros/__init__.py is.
[21:46] <Goneri> distros/__init__.py is linux specific, it should be agnostic
[21:47] <Odd_Bloke> On the Distro would seem more natural to me, as the functions aren't to do with the rendering of network stuff.
[21:47] <Odd_Bloke> I would suggest that refactoring them onto an existing class would make sense.
[21:48] <Odd_Bloke> Refactoring to have a Linux Distro and an agnostic, shared super-class is something I would support, but we would need to discuss that as a project.
[21:48] <Goneri> a large part of net/__init__.py is actually just some Linux specific code.
[21:48] <Goneri> Odd_Bloke, yes maybe, it's indeed already a good step in the right direction.
[21:49] <Odd_Bloke> As a reminder, the intent of the exercise is to gather data about what refactoring looks like it would make sense.
[21:49] <Odd_Bloke> So we don't need it to be Done (TM).
[21:50] <Odd_Bloke> We just need to be able to see roughly what it would look like, and modifying the existing distros.Distro to add functionality and overriding it in freebsd.Distro would do that, I think.
[21:50] <meena> Good point.
[21:50] <meena> points.
[21:50] <Goneri> IMO, a good metric is the number of is_FreeBSD in the code base
[21:50] <Goneri> the less, the better
[21:51] <Odd_Bloke> Agreed.
[21:59] <meena> Odd_Bloke: how do we access the distro from cloudinit/net?
[22:03] <Odd_Bloke> meena: That will be one thing that will need to be worked out.
[22:05] <meena> Odd_Bloke: >_>
[22:05] <meena> okay.
[22:08] <Odd_Bloke> (=
[22:12] <meena> i wonder if we can do that with decorators… maybe. probably not.
[22:49] <meena> maybe the easiest way would be to
[23:02] <meena> hmm… a class?
[23:19]  * meena gives up for tonight o/~


[01:36] <Rocket2DMn> i have a question on wiki pages
[01:36] <Rocket2DMn> i'm from the Beginners Team on the forums, and we are wondering if it's OK for us to delete some pages in our area at https://help.ubuntu.com/community/Beginners/
[18:06] <j1mc> would going people should really right because could though something
[18:07] <j1mc> ^^ the most frequenly used words in this channel.  hmm.
[18:10] <nixternal> wth
[18:10] <nixternal> oh
[18:10] <nixternal> I thought you were really drunk there for a second :p
[18:11] <j1mc> :)
[18:11]  * j1mc is drinking coffee
[18:11] <j1mc> drinky drinks will come later tonight.
[19:29] <j1mc> hi jjesse
[19:32] <jjesse> hello j1mc
[19:34] <j1mc> how are kubuntu docs going?  has it been very difficult trying to write up docs for KDE3.5 and KDE4?
[19:41] <ubotu> New bug: #194843 in kubuntu-docs (main) "Please add linitian over-ride for native-package-with-dash-version" [Undecided,New] https://launchpad.net/bugs/194843
[21:11] <dsas> when making a patch we don't usually patch the pots do we?
[21:11] <dsas> (I think I'm right in assuming they're automatically generated)
[21:14] <dsas> Just in case someone responds after I leave, I'm asking because of the patch attached to bug 162446
[21:14] <ubotu> Launchpad bug 162446 in ubuntu-docs "Outdated link in Programming section" [Low,In progress] https://launchpad.net/bugs/162446
[21:16] <jpatrick> dsas: hey, that's one of mine!
[21:16] <dsas> jpatrick: yup.
[21:16] <jpatrick> mdke ^^
[21:41] <dsas> hmm, is the "-l" in "ls -l" an option or an argument? We don't refer to it consistently.
[21:42] <dsas> (Personally I call it an argument)
[21:50] <jpatrick> I call it an argument too
[21:50] <dsas> the majority of the documentation in basic-commands.xml disagrees with us both.
[21:51] <dsas> It uses option consistently except in one place. So I've gone with the flow.
[22:16] <ubotu> New bug: #194886 in ubuntu-docs (main) "Hardy Heron cd repo name needs testing" [Low,New] https://launchpad.net/bugs/194886
[23:21] <j1mc> anyone around?  i have a couple of file that don't validate because of this: see <link linkend="add-applications">Add Applications</link>), but that approach to linking works correctly in yelp.
[23:21] <j1mc> any advice?
[23:21] <j1mc> (that link was present in the gutsy release)
[23:25] <nixternal> is add-applications in the same document you are using the linkend?
[23:25]  * j1mc looks
[23:25] <j1mc> no
[23:25] <nixternal> that be the reason :)
[23:26] <j1mc> what type of link can i use instead?
[23:26] <nixternal> if we were still doing our documentation in bookform, it would work, but in article it doesn't
[23:26] <j1mc> and why does it not validate if it works in yelp?  /me confused.
[23:26] <nixternal> you could use <ulink url="document.xml">foo</ulink>
[23:26] <nixternal> it works in Yelp?
[23:27] <nixternal> now that is odd
[23:27] <j1mc> would i need to provide any kind of path data?  <ulink url="../../document.xml">foo</ulink>
[23:27] <nixternal> ya
[23:27] <nixternal> hrmm
[23:27] <nixternal> ya
[23:27] <nixternal> I was thinking of translations for a sec, but it would be fine
[23:28] <j1mc> i'll give that a try.  see if it works.
[23:28] <j1mc> thanks.
[23:28] <nixternal> see, for Kubuntu we build out to HTML, which is stupid but we do
[23:28] <j1mc> see, for Xubuntu, we don't know what the hell we're doing, which is stupid, but we do.  :)
[23:28] <nixternal> lol
[23:28] <j1mc> ok.  thanks.
[23:29] <j1mc> i'll probably post to the ML with how i fix it, just to see if someone has another suggestion.  this problem is in several docs, so i'd hate to change it in all of them, think it works, and then find out it breaks something.
[23:30] <nixternal> if you haven't yet, also on freenode is #docbook, and you can catch walsh in there sometimes to give you some pointers
[23:30] <j1mc> thanks.  :)
[23:30] <nixternal> he is the inventor of docbook and can be of great help too when you are stuck with some tricky stuff
[23:30] <j1mc> ok


[00:04] <igc> morning all
[00:04] <igc> hi jelmer
[00:09] <SamB> am I right in thinking that bzr selftest -E foo is supposed to put 'foo' in bzrlib.debug.debug_flags ?
[00:24] <poolie> lifeless: i see we have an Inventory and an InventoryCommon class
[00:24] <poolie> which i think is the antipattern we were talking about a while ago wrt RepositoryBase
[00:24] <lifeless> no quite
[00:25] <lifeless> InventoryCommon is the base; Inventory is really MutableInventory, or InMemoryInventory
[00:25] <lifeless> but there were enough uses of it that renaming would have been traumatic
[00:25] <poolie> why is that different?
[00:25] <lifeless> we've moved a lot of stuff to Common
[00:25] <lifeless> CHKInventory is immutable
[00:25] <poolie> i could equally say that Repository is really VFSBasedRepository
[00:26] <SamB> hooray for immutability
[00:26] <SamB> poolie: do you have some other kind?
[00:26] <lifeless> poolie: Repository long ago lost concrete code
[00:26] <poolie> RemoteRepository
[00:26] <lifeless> its not a leaf
[00:26] <lifeless> RemoteRepository is a leaf, as is Inventory, and CHKInventory
[00:26] <poolie> argh
[00:27] <lifeless> poolie: I could be wrong; but thats why I think the cases are different
[00:27]  * SamB wishes for a black board
[00:27] <poolie> i should be more precise
[00:27] <poolie> the issue is: things that sound like they should be base classes, actually are not
[00:28] <lifeless> poolie: oh right. Inventory is a really misleading name
[00:28] <lifeless> I would love to renamed it to (say) InMemoryInventory
[00:28] <lifeless> s/renamed/rename/
[00:28] <SamB> how about rename but leave an alias behind?
[00:28] <poolie> we could get there from here by either - inserting a new class called *Base or *Common
[00:28] <SamB> with a comment that it's there to avoid pain
[00:28] <poolie> or, changing the existing one
[00:28] <poolie> SamB: it's too hard wrt our api compatibility
[00:29] <poolie> i'm hoping that introducing different api break windows may make it easier
[00:29] <lifeless> SamB: do, or do not :).
[00:29] <poolie> it may still be traumatic even just within bzrlib though
[00:29] <SamB> well, at least that way people would see the right name if they repr'd it
[00:30] <poolie> btw re https://code.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739
[00:30] <poolie> do you object to me putting has_filename in the base class?
[00:30] <lifeless> so, to rename it, we could do it, use a factory as Inventory, which can issue deprecationwarning
[00:31] <poolie> anyhow, concretely
[00:31] <poolie> the thing to do is change RemoteRepository to inherit from Repository and see if anything breaks
[00:31] <poolie> or if anything should go into a LocalRepository
[00:31] <poolie> or some better name
[00:31] <lifeless> yes
[00:31] <lifeless> I'd just change RR to inherit from R and see what the fallout is
[00:32] <lifeless> +1 on that change
[00:32] <lifeless> has_filename is a little ugly though
[00:39] <igc> lifeless: that usertest run on OOo with your pending patches got done last night ...
[00:39] <igc> lifeless: 73.9 -> 1.8 seconds for selective commit
[00:39] <poolie> ! :)
[00:39] <lifeless> well, thats better than it was
[00:39] <lifeless> hows full commit?
[00:39] <igc> lifeless: and also interesting is ...
[00:40] <lifeless> [drum roll please]
[00:40] <igc> send -o dropping from 332 seconds to 69.6 seconds
[00:40] <lifeless> in my branch?
[00:40] <igc> lifeless: where 70 seconds still sucks, fwiw
[00:41] <lifeless> that would be the path2id improvement showing up
[00:41] <lifeless> igc: whats full tree commit in OOo?
[00:41] <igc> 1.8 seconds
[00:42] <lifeless> ok, so we're still dominated by something not addressed
[00:42] <lifeless> I'd love an lsprof of both incremental and full commits of a single file
[00:42] <lifeless> I suspect dirstate load/save
[00:42] <igc> shall do
[00:43] <igc> lifeless: if it is, I have a patch for that - still in review maybe
[00:43] <poolie> igc, i assume that send thing is with jam's ptach?
[00:43] <lifeless> poolie: I improved a code path send uses as well
[00:45] <igc> poolie: the 332 seconds is with bzr.dev rev 4593 - pretty recent
[00:45] <igc> poolie: but looking deeper, I'm not sure whether my 'pending' branch with robert's patches has it or not
[00:48] <poolie> spiv, does my last comment on bug 405251 make any sense to you? :)
[00:54] <thumper> does anyone use bzr with windows and launchpad here?
[00:54] <thumper> https://answers.edge.launchpad.net/launchpad/+question/79261
[00:54] <thumper> the question here is trying to work out why it isn't working
[00:54] <sidnei> thumper: occasionally
[00:54] <thumper> AFAICT it should work
[00:55] <thumper> so I'm guessing it has to do with getting bzr on windows to use his putty key
[00:55] <thumper> and I have no idea how to check that
[00:55] <spiv> poolie: "I wonder if this is related to binary modules not being built?" ?
[00:56] <spiv> Oh, there's a newer one now.
[00:56] <poolie> mm, maybe, or actually to something being stuck or inefficient in hpss protocols
[00:56] <spiv> It wasn't there when I first loaded the page.  email lag I suppose.
[00:56] <poolie> bit of a wild-ass-guess
[00:57] <sidnei> thumper: the steps he outlined seem correct generally. unless he messed up on step 5.
[00:57] <thumper> sidnei: is there any way for him to check?
[00:57] <sidnei> step 5 from the launchpad wiki, that is, the one that has a explicit warning about where it can get messed up
[00:57] <lifeless> igc: there are a few commits from trunk missing
[00:59] <sidnei> thumper: when you upload the ssh key to launchpad does it get used right away, or there's a time needed for it to sync somewhere?
[01:00] <lifeless> igc: its missing 4588
[01:00] <lifeless> which changes bundles as well
[01:00] <lifeless> igc: I'll merge trunk now
[01:01] <igc> lifeless: thanks. My 'pending' trunk is usually trunk + merges of stuff I want to benchmark but ...
[01:01] <igc> lifeless: I'd prefer to just benchmark you branch if it's up to date with trunk
[01:01] <igc> s/you/your/
[01:01] <thumper> sidnei: I don't know
[01:03] <lifeless> sidnei: its usable immediately, modulo db lag
[01:03] <sidnei> thumper: that's the only thing that comes to mind: he uploaded the key and expected it to work right away, but the key isn't immediately put in place on the server side. but i don't know if that is the case or not.
[01:03] <thumper> hmm..
[01:03] <lifeless> sidnei: the ssh daemon isn't openssh, so it just asks the db for the key, rather than waiting for it to be put on disk
[01:03] <lifeless> igc: pushed
[01:12] <igc> lifeless: is iter-changes-partial-parents enough yet? Or do I still need to follow that up with a merge from selective-file-commit?
[01:13] <lifeless> you need both
[01:24] <poolie> igc, any comments on kiko's vm mail?
[01:32] <igc> poolie: if we want continuous testing following a commit, we need it up most of the time I suspect
[01:32] <poolie> yeah
[01:33] <igc> poolie: perhaps a time out of a few hours would work though and ...
[01:33] <poolie> that's about $100/month, it shouldn't break the bank
[01:33] <igc> might result in it being down over weekend periods in particular
[01:34] <igc> poolie: if we go the mega-vs-simple installer route, ...
[01:34] <igc> poolie: then the testing only needs the standard simple installer or easy-install
[01:34] <igc> poolie: building the mega-installer will happen rarely
[01:42] <sidnei> hey igc, poolie
[01:42] <sidnei> not sure if vila let you guys know, but we have builds being run by kerguelen now
[01:43] <lifeless> excellent
[01:43] <lifeless> sidnei: have you seen hudson?
[01:43] <sidnei> matter of fact, i did
[01:43] <mwhudson> ...
[01:43] <sidnei> :P
[01:43] <lifeless> mwhudson: change your highlight rules ;)
[01:44] <mwhudson> lifeless: this one is in my brain, sadly
[01:44] <lifeless> mwhudson: I hear electroshock is much more refined these days
[01:44] <mwhudson> heh heh
[01:45] <kiko> poolie, igc: I'm outta that circuit now -- I have done what I can :-)
[01:45] <kiko> poolie, igc: again, for me bzr2 is the priority -- this is just something nice to have happen
[01:57] <poolie> kiko, thanks for connecting the circuit
[01:57] <poolie> a good 2.0 is the priority but getting good windows builds for it will help make it a good release
[02:08] <spiv> Hmm, test_pack_repository really ought to be renamed to per_pack_repository or per_repository_pack I think.
[02:12] <spiv> poolie: actually, that's something you might want to look at while looking at running tests with 2a as the default, test_pack_repository doesn't include 2a in its scenario list!
[02:13] <spiv> (also, the way the scenario definition duplicates a bunch of format strings etc rather than just grabbing them off the format objects is weird, I think.)
[02:15] <poolie> :/
[02:15] <poolie> could you file a bug assigned to me?
[02:16] <spiv> Sure.
[02:24] <jfroy> jelmer: is there some guide on using dpush?
[02:30] <lifeless> poolie: review sent
[02:31] <lifeless> bah
[02:31] <lifeless> spiv: review sent
[02:32] <poolie> for the delta branch?
[02:32] <lifeless> yes
[02:32] <lifeless> about 6 hours of reading and thinking
[02:36] <krisives1> Anyone know how I can get `bzr log` to output time and date?
[02:36] <lifeless> it does by default?
[02:37] <krisives1> It outputs date, but no timestamp
[02:37] <lifeless> timestamp: Fri 2009-08-07 01:03:20 +0100
[02:37] <lifeless> is what I see
[02:37] <lifeless> what are you seeing?
[02:37] <krisives1> Wait, nevermind
[02:37] <krisives1> I am using `bzr log --short`
[02:37] <krisives1> Hmm, I want the short but with the timestamp
[02:38] <krisives1> I suppose I can parse
[02:42] <spiv> lifeless: thanks!
[02:42] <krisives1> I know this isn't SQL
[02:42] <krisives1> Anyone know a good way to swap 2 primary keys?
[02:43] <lifeless> lunch
[02:43] <lifeless> if you need me, ring me, I'll be offline
[02:44] <krisives1> cheers lifeless
[03:59]  * igc lunch
[04:14] <emmajane> igc, noooo. no lunch!
[04:14] <emmajane> :)
[06:36] <spiv> Oof, reviews replied to.
[06:38] <poolie> lifeless: are you back?
[06:40] <poolie> epic review there
[06:40] <spiv> Yes, "epic" was exactly the word I was just thinking of :)
[06:41] <spiv> More epic than expected, really.
[06:41] <spiv> There are a few points still not 100% resolved, but I think it's probably good enough to land, and the last few nits can happen in a followup landing, I think.
[06:42]  * spiv makes a coffee
[06:53] <spiv> Yeah, with the aid of this coffee, I'm pretty comfy with the state of this branch, so I'll pqm-submit it now and send the last few fixes later.
[07:25] <vila> hi all
[07:27] <vila> poolie: I'd like to answer that mail about the win32 build machines but I miss the meaning of some TLAs: AWS, AMI ?
[07:29] <bob2> amazon webservices, amazon machine something (disk image)?
[07:30] <vila> ha right
[07:47] <poolie> hello vila
[07:49] <vila> poolie: hey !
[07:49] <poolie> hi
[07:49] <poolie> shall we talk about that?
[07:50] <poolie> i was just going to send mail
[07:50] <poolie> or maybe i should send mail and then we  should talk
[07:50] <vila> poolie: same here, mail nearly godd to be sent from here
[07:57] <poolie> vila what do you mean by "as long as we can be freed from the nightly ones"
[07:58] <vila> grr, freed "from the risk of regressions"
[07:59] <vila> wow, this sentence makes no sense at all, sorry :-/
[07:59] <vila> I meant to say: If the nightly builds gave us the benefit of catching the regressions sooner, the release builds should be hassle free and as such can be done by humans
[08:00] <poolie> ok, right
[08:00] <poolie> at least kicked off by a human
[08:03] <vila> poolie: 'kicked off' as in 'in a freshly started VM' ? Yes
[08:03] <vila> or any other valid host
[08:05] <spiv> Heh, "make check" fails on my branch due to "make docs" not liking the markup for the -DIDS:always debug flag.
[08:06] <poolie> spiv maybe eventually debug_flags should be a dict
[08:07] <poolie> i'd kind of agree for now it should be IDS_always but whatever
[08:12] <vila> spiv: 'IDS:' made it kind of obvious that the flags were exclusive... too bad :)
[08:14] <lifeless> vila: bob2: amazon web services, amazon machine image
[08:16] <spiv> I could take lifeless' suggestion and just not document them...
[08:17] <vila> spiv: >-/
[08:20] <poolie> no, they're fine
[08:52] <poolie> lifeless: in the context of https://code.edge.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739
[08:53] <poolie> what's the difference between test_inv and per_inventory?
[08:53] <poolie> it looks like they want to be the same thing?
[08:53] <lifeless> I think they do
[08:53] <lifeless> except
[08:53] <lifeless> perhaps
[08:53] <lifeless> per_inventory wants to be per_mutable_inventory
[08:54] <lifeless> and the tests at the top of test_inv - the parameterised ones, a small part of the file
[08:54] <lifeless> want to be per_immutable_inventory
[08:54] <lifeless> or something along those lines of separation
[08:56] <poolie> ok
[08:56] <poolie> then i might:
[08:56] <poolie> file a bug for this
[08:56] <poolie> rearrangement;
[08:56] <poolie> stick a test for has_filename into test_inv
[08:56] <poolie> and merge my change
[08:56] <lifeless> yup
[08:57] <lifeless> per_inventory only tests Inventory today
[09:46]  * igc dinner
[10:14] <spiv> lifeless: btw, if I just delete that if block from the per_interrepo fetch test the tests still pass.
[10:14] <spiv> lifeless: so whatever bug I had that prompted me to add it in is gone.
[10:15] <lifeless> \o/
[10:15] <spiv> Another problem solved by deleting some code!
[10:27] <Kinnison> huzzah
[10:27] <lifeless> spiv: uhm
[10:27] <lifeless> spiv: you should delete the if statement and undent the block, I think.
[10:27] <spiv> lifeless: right, that's what I meant.
[10:28] <lifeless> phew
[10:28] <spiv> run the assertions unconditionally.
[10:28] <lifeless> I thought that on first read
[10:28] <spiv> Sorry about the false alarm(s) :)
[10:28] <lifeless> then I read what you wrote.
[10:28] <spiv> Yeah, my bad.
[10:28] <lifeless> :)
[12:04] <OllieR> Hey, do symlinks work in bzr?
[12:07] <fullermd> In what sense?  bzr sill store and version symlinks, sure.
[12:33] <vila> sidnei: ping
[13:15] <jelmer> jfroy: not really, it's basically just like push
[14:10] <jelmer> igc: hi
[14:32] <igc> hi jelmer
[14:38] <jelmer> igc: I've proposed a merge for some foreign branch tests, I was wondering if you could comment on the general approach I've taken, so I know if I'm on the right track before doing a lot more of these tests.
[14:39] <jelmer> igc: (the merge proposal is at https://code.edge.launchpad.net/~jelmer/bzr/foreign-tests/+merge/9642)
[14:40] <igc> jelmer: I won't have time in coming days sorry, Maybe vila or jam could offer an opinion? If not, I'll take a look mid-to-late next week
[14:40] <igc> jelmer: sorry about that but I just have too much other stuff on my plate currently :-(
[14:41] <jelmer> igc: No worries
[14:43] <igc> night all
[14:43] <jelmer> g'night igc
[14:57] <dgoulet> hey people!, with bzrlib, is it better to use bzrlib.commit or bzrlib.builtins.cmd_commit() for a working tree?
[15:00] <dgoulet> anybody?
[15:03] <vila> dgoulet: cmd_commit is very close to the command line but may be harder to use than the command line itself
[15:04] <vila> bzrlib.commit may be harder to understand if you're not familiar with the bzr internals
[15:04] <jelmer> dgoulet: any reason for not using WorkingTree.commit()? That invokes bzrlib.commit
[15:04] <jelmer> moin vila
[15:04] <vila> jelmer: hi
[15:05] <dgoulet> no not at all, actually i'm getting deeper into bzrlib day after day and I'm wondering the best way to commit a working tree
[15:05] <dgoulet> i'm using cmd_commit right now but i was thinking that there might be a better way
[15:07] <vila> dgoulet: you should have a look at the commit tests and decide from there what suit your needs
[15:08] <vila> dgoulet: try 'bzr selftest commit --list' to get a taste
[15:08] <vila> but presumably jelemer is right, you awnt to use wt.commit()
[15:09] <dgoulet> hmm ok I look into that, very nice
[15:11] <dgoulet> another question while i'm here
[15:11] <dgoulet> i have a branch with NO tree (only .bzr)
[15:12] <dgoulet> what's the best way of getting that into a working tree to work on whitout a cmd_branch() ?
[15:15] <jelmer> dgoulet: BzrDir.open(path).create_workingtree()
[15:15] <meuserj> After upgrading bzr to 1.17, my integration with Redmine suddenly stopped working.  Did a little diving into Redmine to see what command is causing the issue, and bzr is indeed crashing on the command which redmine uses: http://pastebin.com/d58052ae2
[15:16] <meuserj> any fixes or workarounds available?
[15:18] <jelmer> meuserj: please file a bug report, this looks like a regression in bzr
[15:28] <meuserj> jelmer: a little more experimentation shows that it is the revno:-1 option which is causing the crash
[15:35] <meuserj> ah, and it only happens when I use bzr://.. other remote protocols, including bzr+ssh seem to work.
[15:57] <jelmer> meuserj: ah, odd
[15:57] <jelmer> meuserj: definitely seems like a bug then
[15:57] <jelmer> meuserj: the fact that it only occurs with bzr:// probably explains why nobody has noticed it before
[15:59] <meuserj> jelmer: yeah I assumed that bzr:// isn't used often.. the only reason I use it is that the machine hosting Redmine is different than the machine hosting the central repository, and it's easier to use the bzr server than try to set up ssh keys for the web server user.
[16:06] <dgoulet> from a working tree, if I want to revert a specific file to a lower revision, how can I make that happen because i'm having no result from wt.revert()... ?
[16:13] <meuserj> jelmer: wow.. yet another variable.. it only happens with repositories served via bzr-server, not individual branches
[16:21] <manuee> hi everyone, brand new user here... silly question: if i do bzr ignore dirname, is everything under that directory ignored recursively?
[16:21] <Tak> dgoulet: I'm using RevisionTree.revert()
[16:21] <vxnick> manuee: yes
[16:21] <manuee> ow awesome
[16:21] <manuee> i was wondering because olive lists the files under those dirs as unknown instead of ignored
[16:21] <manuee> so i was geting confused
[16:22] <vxnick> ah :)
[16:22] <manuee> thanks vxnick =)
[16:22] <dgoulet> yess that's what I though but when I try to get the RevisionTree from my WorkingTree, it always tell me that NoSuchRevision...
[16:22] <dgoulet> i'm doing something bad but I can,t figure it out
[16:22] <manuee> im planing on geting my drupal development under bazaar (soloing)
[16:22] <Tak> wait, my bad
[16:22] <dgoulet> from a RevisionSpec, how can I get the revision id ?
[16:23] <jelmer> dgoulet: the as_revision_id() method IIRC
[16:23] <Tak> I'm getting the rev from the revision tree, then using WorkingTree.revert() with that rev
[16:23] <dgoulet> :| how?
[16:23] <Tak> one sec, let me pastebin some code
[16:23] <manuee> ive got my repository setup here onmy local development machine, the next step would be to set it up on the production server,... any guides/howtos/tips on how to go about it so ican push changes to my server from my local machine?
[16:24] <manuee> i know its a broad question... perhaps i should study the manual a bit more
[16:24] <manuee> :X
[16:24] <vxnick> manuee: depends if you wanna use commit/update or push/pull
[16:24] <vxnick> I think the manual has a few examples which you might find helpful
[16:25] <manuee> yeh i should probably re-read that see if i figure things out
[16:25] <manuee> ow
[16:25] <manuee> server doesnt have bzr installed :X
[16:25] <vxnick> if you want to use push/pull you don't need bzr installed on the server
[16:26] <manuee> ooow nice
[16:26] <vxnick> you can do bzr push<EMAIL_ADDRESS>[16:26] <manuee> push only uploads stuf ?
[16:26] <dgoulet> Tak: thanks!
[16:26] <manuee> i rtfm vxnick
[16:26] <Tak> http://paste2.org/p/366912
[16:26] <manuee> heheh bbiab
[16:26] <Tak> that's what I'm doing, which may not be The Right Way
[16:27] <Tak> err, remove that [0] from the first line
[16:27] <dgoulet> i figure ;) i'm trying it real quick
[16:27] <manuee> reading http://bazaar-vcs.org/BazaarForWebDevs atm--- it mentions to use the bzr-push-and-update plugin
[16:27] <vxnick> manuee: only if you have a remote working tree, which you prob don't need
[16:28] <manuee> ah right
[16:28] <manuee> ye only my local box will be having vc
[16:28] <manuee> thanks vxnick
[16:28] <vxnick> no probs
[16:29] <manuee> im tryin to just have a simple setup, im very new to vcs :X
[16:29] <manuee> =)
[16:29] <manuee> back to reading (getin excited)
[16:30] <vxnick> manuee: have you made the repo on your local machine already?
[16:30] <manuee> humm yes
[16:30] <manuee> i ran bzr innit
[16:30] <manuee> ignored everything but the custom code i want on vc
[16:30] <manuee> and added what i wanted
[16:30] <vxnick> committed?
[16:30] <manuee> i committed the first yes
[16:30] <manuee> i havent created a branch though
[16:30] <manuee> not sure how that goes :X
[16:30] <vxnick> do this:
[16:31] <vxnick> check the manual for bzr push - this will upload your repo to your server. If you want to get a copy of it on other machines, you use bzr branch on the URL
[16:32] <manuee> bzr info returns Standalone tree (format: pack-0.92)
[16:32] <vxnick> so when you make changes in future, commit then push again (you don't need to specify the server details each time), then others can use bzr pull to grab your changes
[16:32] <manuee> ok bzr help push --- reading...
[16:34] <dgoulet> Tak: it's working very well!
[16:34] <dgoulet> thanks a lot! I appreciate it!!
[16:35] <Tak> np
[16:35] <manuee> ow ok, bzr remove actualy deletes the files
[16:35] <manuee> lol good go know
[16:36] <vxnick> you can use --keep to keep them
[16:36] <manuee> ah awesome
[16:36] <manuee> im thinkin im only going to vc the theme for now
[16:36] <vxnick> you may as well do the whole thing, makes life easier :)
[16:37] <vxnick> and bzr revert should bring back those deleted files, if you want them
[16:38] <manuee> ah heheh
[16:40] <manuee> very handy
[16:46] <manuee> ok moment of truth
[16:47] <manuee> im using bzr push --creat-prefix sftp:/blabla --use-existing-dir
[16:47] <manuee> i hope it puts things into its place :X
[16:48] <vxnick> --use-existing-dir seems redundant as --create-prefix implies that you're pushing to a path that might not already exist
[16:48] <vxnick> but don't worry about it
[16:49] <manuee> i didnt use it the first time and it got me an error saying it doesnt have a valid .bzr directory
[16:50] <vxnick> ah, ok
[16:51] <manuee> "Created new branch."
[16:51] <manuee> looks like it worked no?
[16:51] <vxnick> you can test by branching it to another directory and making sure it pulls all the files
[16:52] <manuee> humm k i dont understand the whole branching deal it looks like
[16:53] <vxnick> branching means to copy the repository to another location
[17:09] <sohail|laptop> getting a wierd problem. I can use putty to connect to my host but when I do bzr+ssh, I get bzr: ERROR: socket.error: Socket is closed
[17:09] <sohail|laptop> the host that I am trying to bzr+ssh to is a mac
[17:09] <manuee> hmmm k it isnt working
[17:10] <manuee> i made a small change to a file to test, commited the change, ran bzr push, which looked ok, but the file didnt get updated on the server
[17:10] <sohail|laptop> hmm, sftp works
[17:10] <sohail|laptop> oh well
[17:11] <vxnick> manuee: the files don't actually end up on the server, just the contents of .bzr
[17:11] <manuee> ow
[17:11] <manuee> humm so im missing a step then?
[17:11] <vxnick> if you branch it though you'll see them :)
[17:11] <vxnick> nope you've done it correctly
[17:12] <vxnick> if you actually want the files to be uploaded to the server, look at the bzr-upload plugin
[17:15] <manuee> ow ok
[17:15] <manuee> thanks vxnick
[17:15] <vxnick> no prob :)
[17:17] <manuee> http://bazaar-vcs.org/BazaarUploadForWebDev =))
[17:18] <manuee> "No uploaded revision id found, switching to full upload"
[17:18] <vxnick> that's fine
[17:19] <manuee> ah its cause its the first time right
[17:19] <vxnick> yeah
[17:19] <manuee> oki
[17:24] <manuee> w00t its working
[17:24] <manuee> i dont htink i actualy need to push anything right
[17:25] <manuee> since im not versioning files over there
[17:27] <vxnick> you don't need to push it if your'e the only one using the repo
[17:29] <manuee> ah k, i think im starting to understand things
[17:30] <manuee> so to remove what i did using push, i just delete the .bzr directory on the server, and all is like before there
[17:30] <vxnick> yep
[17:30] <manuee> its nice it only adds it at one location, cvs is crazy like that (which is what the drupal proyect is under sigh)
[17:30] <vxnick> hehe
[17:30] <manuee> i can barely get my head around cvs to maintain a couple of proyects i have on there
[17:31] <manuee> everytime i have to look up the docs lol
[17:31] <vxnick> luckily bzr is a lot simpler :)
[17:31] <manuee> no doubt
[17:31] <manuee> thanks a ton for your help & patience vxnick
[17:31] <manuee> you helped a lot
[17:32] <vxnick> a pleasure
[18:28] <SamB> jelmer: so ... I pushed up some code to log SVN editor activity on lp:~naesten/bzr-svn/355143-replay/ ... I added it to PathStrippingDirectoryEditor and PathStrippingEditor. Not sure if that was the best place, thogh... what do you think?
[18:31]  * SamB wonders how to set a PDB breakpoint in code he can't/shouldn't edit without using the PDB shell ...
[18:35] <LarstiQ> SamB: edit code; import ipdb; ipdb.set_trace() ?
[18:38] <SamB> LarstiQ: I hesitate to do that to a module in the globally-installed standard library ;-)
[18:39] <LarstiQ> SamB: be fearless! ;)
[18:39] <LarstiQ> SamB: how about starting it with the pdb command then?
[18:39] <LarstiQ> you can set a break, and then continue
[18:40] <SamB> I guess I could do that
[18:40] <SamB> somehow I'd gotten it into my head that that would not work ;-)
[18:40] <SamB> say, where is debugging of bzr documented?
[18:42] <LarstiQ> SamB: HACKING I'd think
[18:42] <LarstiQ> SamB: you're aware of BZR_PDB and C-\ ?
[18:43] <SamB> LarstiQ: yeah
[18:43] <SamB> but it might be a good idea to remind folks that they can still use plain-old pdb?
[18:43] <LarstiQ> sure
[18:44] <LarstiQ> and the import pdb; pdb.set_trace() routine
[18:44] <SamB> LarstiQ: though the C-\ trick I picked up only by seeing sigquit listed somewhere related to BZR_PDB, and I think I found out that C-\ is the usual way to send one from wikipedia ...
[18:45] <LarstiQ> SamB: doh
[18:45] <SamB> maybe there should be an entry in the online help too?
[18:45] <SamB> it could even just say to look in some particular other place, for all I care
[18:45] <LarstiQ> SamB: it is mentioned in HACKING under Debugging
[18:46] <LarstiQ> SamB: right, good idea
[18:47] <SamB> oh, speaking of the online help ...
[18:48] <SamB> https://bugs.launchpad.net/bzr/+bug/408983
[18:51] <SamB> LarstiQ: does that not seem like a good idea?
[18:51] <SamB> like, practically essential even?
[18:52] <LarstiQ> SamB: not sure about essential, but I think it is a good idea too.
[18:52] <jelmer> this is why I don't like the online help system in bzr, we basically end up implementing our own documentation reader in the end :-(
[18:52] <SamB> jelmer: true
[18:53] <LarstiQ> jelmer: I'm fine with hooking up with `info`
[18:53] <jelmer> SamB: Thanks, I'll have a look
[18:53] <jelmer> sorry for answering in the wrong order :-)
[18:54] <SamB> jelmer: I'm not at all sure I've taken the right approach with that tracing, which is why I'm asking you to look at it
[18:55] <SamB> the more I think about it, the more I feel like it might be better to create a set of wrapper classes that, when the flag is enabled, wrap around the actual editors for tracing purposes
[18:56] <jelmer> SamB: right, that's what we do for transports
[18:56] <jelmer> SamB: see MutteringTransport
[18:56] <SamB> that was actually my first idea
[18:56] <SamB> ;-)
[18:57] <SamB> jelmer: so do you think I should go ahead and do that?
[18:57] <SamB> jelmer: and if so, where should I put them?
[18:58] <SamB> (and I really wish bzr had a concept of "interfaces", if only for documentation purposes ...)
[19:00] <SamB> jelmer: hmm ... what module is that in?
[19:00] <SamB> I found something a bit different-looking in bzrlib.transport.trace...
[19:04]  * SamB wishes bzr selftest could abbreviate test names like 'bzrlib.plugins.' => 'bp.'
[19:20] <SamB> hmm, would it be allowable for bzrlib to override unittest.TestResult._exc_info_to_string() ?
[19:23] <jelmer> SamB: sure, just put them in fetch.py
[19:24] <jelmer> SamB: technically, this is a subvertpy API
[19:24] <SamB> jelmer: point
[19:24] <SamB> I realized that pretty soon after mentioning that
[19:25] <SamB> but, if bzr used interfaces as defined by some standard and/or popular third-party library, subvertpy could too, couldn't it?
[19:25] <SamB> if only for documentation purposes?
[19:28] <SamB> jelmer: hmm, is bzr-svn considered to have a public API?
[20:32] <jelmer> SamB: other than the layout stuff, not really
[20:35] <jelmer> SamB: also, subvertpy._ra.Editor documents the Editor interface (just committed)
[20:53]  * SamB wishes one or the other of the python modes would highlight local variables somehow ...
[20:54] <SamB> heck, even highlighting variables name and attribute names differently would be helpful ...
[20:57] <SamB> jelmer: committed where exactly ?
[21:24] <RenatoSilva> how to rename tags?
[21:32] <SamB> doh. committed to subvertpy, duh ;-P ...
[21:37] <fullermd> RenatoSilva: No way, the name _is_ the tag.  But you can make a new tag with a different name pointing at the same place.
[21:41] <meuserj> The topic says that Launchpad is now open source... but I don't see anything about where to get it on launchpad.net...
[21:41] <RenatoSilva> fullermd: ok
[21:44] <beuno> meuserj, code.launchpad.net/launchpad
[21:45] <meuserj> duh.. it make sense that they would host their own card.
[21:45] <meuserj> err code
[22:24] <RenatoSilva> is there a way to search for a text that was added or removed in some commit? I have a new line which introduced a bug, and I want to remove it, but before I want to know why that line was inserted. So I want to find the commit which inserted that change. Any idea?
[22:26] <fullermd> annotate will tell you when a line was last changed (which may or may not be the insertion; you can step backward if it's not)
[22:26] <fullermd> Removed is obviously harder.
[22:32] <SamB> fullermd: I think he was hoping for a pickaxe
[22:33] <SamB> which would be seriously usefull, really
[22:37] <fullermd> I've got a splitting maul, is that close enough?
[22:39] <SamB> probably not
[22:51] <lifeless> RenatoSilva: bzr search can do that
[22:52] <RenatoSilva> it's a plugin, right?
[22:52] <lifeless> yes
[22:53] <lifeless> however, gannotate is probably best
[22:53] <RenatoSilva> is there a way to at least show a log including the diffs? Then I could use grep...
[22:53] <lifeless> as it can step through full lines
[22:53] <lifeless> log -p
[22:54] <RenatoSilva> Yeah, I just read this in the help, thanks!
[23:00] <RenatoSilva> lifeless: it was commit 1, and I discovered the reason it was added anyway..
[23:00] <RenatoSilva> thanks
[23:04] <SamB> jelmer: ... who is supposed to call close on an Editor ?
[23:40] <jelmer> SamB: whoever is reporting the changes
[23:41] <SamB> jelmer: well, I don't see it getting called on my tracing editors ...
[23:46] <Noldorin> LarstiQ: heya
[23:47] <Noldorin> LarstiQ: any news on the chmod issue?