[12:11] asabil, NfNitLoop: http://rafb.net/p/6eZRXW13.html :) [12:15] luks: nice work. === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [12:32] morning all === MishaS [i=MishaS@a91-154-120-151.elisa-laajakaista.fi] has joined #bzr === asabil [n=asabil@ti0035a340-0084.bb.online.no] has joined #bzr [12:50] hmm, luks nice but maybe having it per branch can be more handy ? [12:52] well, I was just playing, it's nothing serious. per-branch bookmarks wouldn't be so easy as these global ones [12:53] http://rafb.net/p/H4YUxG13.html if you want more complete version [12:56] that;s awesome already :) [12:58] I was also wondering if there any way to attach some kind of metadata to a branch [12:58] I was hacking on loggerhead a bit [12:59] and what I did was to add a branch-info file inside each branch [12:59] and that file contains variables like description = "branch descriptio" [12:59] this is particularely useful for auto discovered branches [01:00] is there any clean way to implement this feature ? [01:02] asabil: I have implemented a VCS frontend that used per-branch aliases, and I found it had poor usability. [01:03] Because you were never sure what aliases were set where. [01:03] hmmm [01:03] And which ones were global, versus local. [01:03] I don't think that global aliases are useful [01:03] I think it would only work if they were either all global or all local... [01:03] They're very useful. [01:04] I agree Odd_Bloke [01:04] then maybe the ablity to specify shorthands for servers ? [01:04] Most of my work is done against two or three branches. Having shorthands would be quite nice. [01:05] then maybe the ability to say [01:05] myserv/bzr/branch.x [01:05] Well, just set it up so that you can append to the alias. [01:05] where myserv is a shorthand [01:06] So you can alias example.com/bzr to myserv, and just specify "myserv/branch.x" [01:06] I know that git have some sort of aliasing because I was reading a blog post about it. No doubt that'll have disappeared into the depths of reddit by now. [01:07] As for per-branch descriptions, I think it would be reasonable to stick them in branch.conf. The branch nick is already there. [01:07] The example they used would have me specifying, for example, 'abentley' to point to your branch so if I want to pull your changes I literally type 'git pull abentley'. [01:07] abentley: where is branch.conf ? [01:07] Ow! [01:07] asabil: in .bzr/branch/ [01:07] I think that then pulls the changes to a local cache which you can then treat as a branch. [01:07] ok thanks abentley :) [01:08] So I was thinking, if there were a smart-server or something running at the other end, it generates a merge-directive and sends you that. [01:08] But that was just an idea that flitted through my mind at some point. [01:10] Quite hard to form exactly what the use case for that would be, because I don't do any development that's distributed to that extent. [01:11] The smart server can take a more direct approach than a merge directive. [01:11] hmmm, I think it can be a very nice feature [01:13] hello === poolie__ is now known as poolie [01:18] poolie: should I do debs of the rc2 [01:18] yes, please [01:20] lifeless, so can we expect 0.90final to go into gutsy? how about rc2? [01:20] I need to do the request as per discussion with mdz [01:20] that I cc'd you on [01:21] k [01:21] bzr-svn is now in debian [01:21] so I should have the request put up today === jml_ [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr === jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === jml_ is now known as jml === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [01:40] abentley: I presume bzrtools 0.91 is imminent ? [01:41] jelmer: bzr-gtk 0.91 coming soon === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [01:42] Yeah, I'll get that out soon. [01:43] abentley: with nested trees, does the parent entry file id need to match the subtree root id ? [01:43] Yes, that's the current design. === orospakr [n=orospakr@bas4-ottawa23-1177649282.dsl.bell.ca] has joined #bzr [01:45] interestingly that isn't enforced by commit [01:52] ok, bug fixed in fetch for subtrees. [01:54] poolie: bzr.dev still has all the 0.91 changes in its in development section [01:55] poolie: this seems wrong ? [01:55] i [01:55] i haven't committed a change to bump the version [01:55] should do that now [01:55] lifeless, i see gutsy claims to have 0.90 already [01:56] or at least '0.90-1' [01:56] I thought the version bump commit was in the release process? [01:57] yes, 0.90 has reached gutsy [01:57] it is, i haven't finished the process though === corporate_cookie [n=richie@64-191-132-172.xdsl.qx.net] has joined #bzr [01:57] I think mdz has got someone to do the sync I asked for anyhow [01:58] my point is, that seems to be the wrong version number, should it not be 0.90rc1? [01:58] no [01:58] 0.90 got released remember [01:58] you're working on 0.91 [01:59] oh right [01:59] just coincidental [02:00] if you count a missing digit :) === corporate_cookie [n=richie@64-191-132-172.xdsl.qx.net] has joined #bzr [02:01] lifeless: Will do so by the end of the week [02:01] jelmer: I can't really upload debs of the 0.91 rc's without fixed plugins [02:01] lifeless: I'm considering stopping doing synchronized releases [02:02] lifeless: I'm a bit busy at the moment, can't really put the effort into testing bzr-gtk at the moment [02:02] jelmer: perhaps you could share the responsibility [02:02] lifeless: I've been trying to get Szilvester to do a release for the last couple of releases :-) [02:03] lifeless: If you feel like doing it, you're more than welcome [02:03] lifeless: btw, thanks for uploading 0.4.2 [02:03] well [02:03] is there any reason not to just say 'its released' ? [02:04] The only two things in it I've used since I did the previous release are viz and gcommit [02:04] but there has been a lot going on, merged by other people [02:05] so I don't really feel comfortable releasing it without testing, especially since there are so little unit tests. [02:07] another option would be to simply upload a copy of bzr-gtk 0.90 but mark it as being compatible with 0.91 === mw is now known as mw|out [02:08] because none of the important API's have changed [02:10] jelmer: You're not concerned about Branch.last_revision / WorkingTree.last_revision? [02:11] abentley: ah, I wasn't aware of that.. [02:12] abentley: whats happened to those apis ? [02:13] They now return NULL_REVISION instead of None [02:13] ah right [02:14] poolie: that bug I found last night? I've done a regression test for it and mailed to the list right now [02:14] I think this is critical enough for 0.91 [02:14] thx [02:17] jelmer: I think you should ask for help on the list [02:17] jelmer: you maintain two plugins that are version locked that I know of [02:18] lifeless: bzr-svn isn't version locked - it contains a list of versions it knows it is compatible with and will warn if it sees an unknown version but will still work [02:18] jelmer: and its bad for bzr to have mismatches during release; there is a week of freeze for plugin authors to know there are no changes incoming that will bust api's [02:19] jelmer: warning confuses and infuriates users [02:19] lifeless: there have been too many api changes to not have those warnings in [02:20] lifeless: for bzr-gtk I can see a point in not having the warnings - that's why I was suggesting desynchronizing the releases [02:20] jelmer: well, the warnings are not useful when a user is using the plugin and no newer release has happened [02:20] I'd argue that they *are* useful when a user experiences a bug [02:21] and reporting plugin versions in bzr's error output supercedes that warning IMO, because you, the author, will be able to tell [02:21] lifeless: so far, bzr has broken bzr-svn every release [02:22] ok [02:22] well, its your domain [02:22] I'm also confident enough to do a bzr-svn release, as I'm the sole maintainer of the main branch and it's very well tested [02:24] bzr-gtk has almost no tests, several different people committing to mainline, no review, out-of-date NEWS... [02:24] so doing a release for it is more work [02:25] can you change your process [02:25] for instance, set policy like bzr does for NEWS [02:25] require review like bzr does - perhaps ask Aaron to setup a prefix like [bzr-gtk/MERGE] for a different bundle buggy instance? [02:26] lifeless: I'd agree with Jelmer; before plugin authors will remove the warnings, they need to trust Bazaar not to break the API. [02:26] lifeless: review sent to the list on 'knit text add reductions' [02:28] lifeless: I'll send through some more feedback on http://bundlebuggy.aaronbentley.com/request/%3C1189034650.27751.10.camel@lifeless-64%3E as well - I'd really like to see this one land soon [02:28] which is that [02:29] the 'move stuff into CommitBuilder' one [02:29] (0.92 targetted) [02:29] right [02:29] that needs an update [02:29] massive bugs that I fixed last night [02:29] :-) [02:30] I saw the changes in your commit branch [02:30] lifeless: we did talk about bundle buggy at some point, but never got around to it. I agree it would be a good idea to use it for bzr-gtk. [02:31] lifeless: with path_content_summary, why did you not make file-id a parameter? [02:31] igc: because it has no use for one [02:31] jelmer: I'd be happy to chat about BB at some point. [02:31] its unneeded overhead to pass one in === jroes [n=jroes@halcyon.xeria.net] has joined #bzr [02:32] won't same trees benefit from it?? [02:32] s/same/some/ [02:32] 'some' trees? [02:32] if you are doing a commit from a tree that has no path orientated data structure - e.g. committing from something like a revision tree. [02:32] but yagni [02:33] working trees have disk [02:33] hey guys, anyone else think the sftp example at http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html is a bit misleading? on a default setup, you need to specify the absolute path to the dir you want to push your revisions to (I doubt most user accounts have write access to /) [02:33] memory trees have a transport with path data [02:33] abentley: Szilveszter and have been talking about setting up a separate copy of it somewhere, but if it's possible to have one up on the main site, that'd be awesome === jdub [n=jdub@home.waugh.id.au] has joined #bzr [02:33] yo folks [02:34] hi jdub [02:34] I was thinking about workingtree4 where lookup by id would save a path -> id conversion from the little I know of that code [02:34] lovely to see bzr so versionly close to 1.0 8) [02:34] igc: the api does not use id at all [02:34] igc: so why would it do a path->id conversion at all ? [02:35] Jelmer: in theory, I'd be happy to. But I'm a bit worried about performance on that machine. [02:35] have an svn-upgrade issue to ask about... [02:35] $ bzr svn-upgrade [02:35] Using saved location: http://svn.automattic.com/wordpress-mu/trunk [02:35] bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): No module named rebase.rebase [02:35] [02:37] lifeless: path_content_summary() in workingtree_4.py has an implementation for DirStateRevisionTree but not WorkingTree4. Just thinking out loud about a potential implementation ... === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [02:37] igc: I really don't understand what you are thinking about [02:37] abentley: ah, ok [02:37] igc: what fileid keyed data are you thinking it would want? [02:38] jdub: Do you have trunk of bzr-rebase installed as ~/.bazaar/plugins/rebase ? [02:38] sha1. I really need to know that code better. I plan to look at it today so I can ask more intelligent questions. [02:38] igc: sha1 is keyed by path [02:38] jelmer: no plugins installed -- bummer [02:38] ok - that's good to know [02:39] igc: if there are multiple fileids at a given path, only one of them will be present in tree 0 - the working tree [02:39] so thats the one to use [02:39] jdub: trunk of bzr-rebase is at http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/ [02:39] though if you have no local changes, it's probably faster to just 'bzr branch' from scratch rather than svn-upgrade [02:39] jelmer: aptitude install bzr-rebase [02:39] jelmer: so the new bzr-svn breaks svn but bzr doesn't include the bits to fix it yet? :-) [02:39] jdub: its in a separate plugin, which bzr-svn recommends [02:40] lifeless: hrm, not available to me yet === jroes [n=jroes@halcyon.xeria.net] has left #bzr [] [02:41] hmm, whoever synced bzr-svn missed the new recommends [02:41] jelmer: *why* doesn't it depend on bzr-rebase? [02:41] in 10 minutes escudero.canonical.com, the machine hosting www.bazaar-vcs.org, will be shut down for some necessary maintenance, ETD is 5 minutes [02:42] lifeless: it's only needed for svn-upgrade [02:42] thanks elmo [02:42] jelmer: all the same [02:42] :) [02:42] lifeless, sync pickups entire package, so nobody *missed* it, the debian maintainer did it [02:42] or am I missing something? :) [02:42] i guess if you don't forsee svn-upgrade being used regularly, you'd only need bzr-rebase on these odd occasions [02:43] lifeless: svn-upgrade is only necessary for those upgrading from bzr-svn 0.3 [02:43] pygi: I think you are missing several emails, irc discussion and the debian maintainer has done nothing wrong [02:43] jelmer: I see this as a purity vs do-the-right-thing situation [02:44] lifeless: more feedback on the 'knit text' stuff - 32 unit tests are failing because of parameter count mismatches. Do you want a pastebin or email? [02:44] but with the break in this upgrade, having all the tools available would make users less surprised [02:44] igc: its all fixed here [02:44] igc: like I said, massive fixes needed [02:44] cool [02:44] jdub: I'm with you [02:45] btw, the message i get from bzr merge wouldn't hint me towards svn-upgrade [02:45] lifeless: just to be clear, I'm talking about the patch I reviewed this morning (random_id etc.), not the other one [02:46] revno: 2810 [02:46] committer: Robert Collins [02:46] branch nick: knits [02:46] timestamp: Tue 2007-09-11 14:05:11 +1000 [02:46] message: [02:46] Unbreak weaves. [02:48] poolie: you know you could have just changed the product rather than marking invalid and filing a new task [02:48] FWIW [02:49] lifeless: That's a humdinger of a bug you found with fileids_altered_by [02:49] abentley: yah [02:50] abentley: totally by accident too [02:51] Such an ugly hack, that code. I'm surprised we haven't found more bugs. [02:52] (escudero / www.bazaar-vcs.org is back) [02:52] abentley: well its reasonably well tested; the glitch here was no direct testing of nested tree fetching [02:55] lifeless, i din't realize it was possible to change the product of a task [02:55] oh [02:55] lifeless: well, it's a bit more hackish than that... bzr-rebase 0.2 isn't out yet. [02:55] so click on the thing to expand it [02:56] ah, i think i saw the greyed out text as "you can't change this" [02:56] and there is a field [02:56] you can edit it [02:56] lifeless: whoa, that crazy stuff still afflicts launchpad? [02:56] lifeless: which I admit is ugly [02:56] jelmer: seems difficult for users:) [02:58] lifeless: trunk works fine for bzr-svn, but has two bugs that block it from being uploaded as an official bzr-rebase release. [03:01] poolie: someone mailed me saying they want to put bzrlib/patches.py into the standard library. I wrote all but 14 lines, but Canonical has joint copyright. Are you in favour of relicensing it in principle? [03:03] elmo: what's the appropriate way to request ubuntu.com alias changes? [03:03] jelmer: still difficult for users to have to choose between 'working bzr-rebase' and 'working bzr svn-upgrade' [03:03] jelmer: ran into a crasher bug with bzr-svn. I've filed a bug with all the information I have, but I'd be happy to provide more on request [03:03] "svn_path_basename: Assertion `is_canonical(path, len)' failed." then a segfault [03:03] jdub: outside of the LP-automagic ones? rt@ubuntu.com [03:04] jdub: (as in, send a mail to that address) [03:04] yeah [03:04] jamesh: where did you file it? The latest bug report from you I have here is from 25 october last year [03:04] jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/139020 [03:04] Launchpad bug 139020 in bzr-svn "assertion error segfault when branching from svn+http://svn.effbot.python-hosting.com" [Undecided,New] [03:05] elmo: i think my jeff.waugh is not LP-automagic (how do they work?) [03:05] jdub: -> privmsg [03:05] jelmer: the email will probably go out in 5 minutes (LP waits a little to batch changes) [03:05] sorry :0 [03:05] :) [03:05] jamesh: ah, 3 minutes ago.. that explains it :-) [03:05] it's okay, we're just off topic [03:06] abentley, i don't see any problem with that [03:06] jelmer: I managed to pull out a Python stack trace from the segfault if that helps ... [03:07] jamesh: seems I can reproduce it here [03:08] might just be a weird SVN server [03:08] poolie:Okay, I'll mail you something more formal if/when we get there. [03:08] although (assertion errors seem unexpected) [03:09] lifeless: yes, that's true [03:09] jamesh: the subversion library asserts on invalid paths [03:09] jdub: Oh, hi Jeff. [03:12] hey abentley [03:12] Next time you're in Toronto, give a shout. [03:12] ! [03:12] i'm in toronto atm! [03:13] Dude! [03:13] <- asshat. [03:13] i am in sydney [03:13] which looks a little bit like toronto [03:13] it is very sprawly [03:13] concrete fences around the CBD? [03:13] PyGTA showed me pics of your visit. [03:13] but our security is VERY NICE! HIGH FIVE! [03:13] jelmer: bzr-rebase isn't in debian even is it ? [03:13] jamesh: bah! [03:14] pygta? [03:14] I think the concrete fence was entirely appropriate; it is an island of convicts after all [03:14] Yeah, Sydney wasn't to hard to get my head around. [03:15] igc: new patch version, want to confirm you're happy with what I did? [03:15] lifeless: 0.1 is in debian [03:15] jelmer: hmm, madison isn't showing it. whats the source package name? [03:15] you don't want all the world leaders escaping and overstaying their visas too [03:15] lifeless: bzr-rebase [03:15] better to keep them locked up [03:15] http://linuxcaffe.ca/node?page=3 [03:15] hmm, madison crackness [03:15] lifeless: it's both in sid and lenny [03:16] lifeless: sure, I'll look now [03:16] thanks for the fast turnaround [03:16] jdub: PyGTA meet at linuxcaffe. [03:17] oh, that was ages ago, after i spoke in toronto on the badgerbadgerbadger tour [03:17] it was just random [03:17] Hehe. === Vantage13 [n=Vantage@www.toddcharron.com] has joined #bzr [03:20] poolie: is there anything in bzr.dev yet that shouldn't be in 0.91 ? [03:20] i have not merged anything like that yet === poolie looks [03:20] no, there is nothing that can't merge to 0.91 [03:21] ok [03:21] I'll merge my branch trivially then [03:21] i was going to merge the version bump, but will hold off [03:21] ok [03:21] jamesh: fixed in trunk. [03:21] thanks for the bugreport :-) [03:23] igc: I think 'saving data locally' might be better as 'Finalizing commit' or something === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [03:23] lifeless: sounds better to me [03:24] jelmer: thanks. === Theuni_ [n=ctheune@uter.gocept.com] has joined #bzr [03:29] lifeless, let me know when you're done and i'll open things for 0.92 [03:29] they are both in pqm now [03:30] back shortly [03:31] poolie: lol you and your committed pdb lines :) [03:32] lifeless: so, what should we do with bzr-gtk 0.91 ? when are you going to upload the .debs? [03:32] :) [03:32] i need a precommit hook maybe [03:32] specifically what happened though is that i started from an unclean tree and should have checked that [03:33] lifeless: s/going to/would you like to/ :-) === ..[topic/#bzr:poolie] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === beuno wonders if 0.92 will have packs in it [03:37] they should be in as an experimental format === Theuni [n=ctheune@uter.gocept.com] has joined #bzr [03:38] Mmmm. [03:39] great, I'll be experimenting with them then [03:39] jelmer: if poolie is going to do an rc3 I'll wait for that, otherwise I'll start on them in a couple hours [03:39] I keep hearing good things about it [03:40] i'm going to just use the break command rather than set_trace() for a while :) [03:40] lifeless, wait for rc3 to make debs? [03:40] when should we do rc3? today? tomorrow? [03:43] lifeless: it's ok to wait until the weekend with bzr-gtk 0.91 though? [03:43] lifeless: otherwise, feel free to take a snapshot and call that 0.91~rc1 or something.. [03:43] jelmer: well as soon as I upload debs to bazaar-vcs.org, the other plugins will break [03:43] thats my concern [03:43] bzrtools is good now, as abentley has done a release [03:44] poolie: so, my fetch fix - do you want to do an rc3 with that immediately, or wait a bit., If you are waiting I'll do debs of rc2, otherwise I'll do the debs after you do rc3 [03:45] lifeless: I'll do bzr-svn 0.4.3 tomorrow, release is already tagged just not packed and uploaded yet [03:45] have fun [03:45] g'night === abentle1 [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === arjenAU [n=arjen@mysql/community/arjenAU] has joined #bzr === jml_ [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr === jml_ is now known as jml === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr [04:10] anyone have any tips/guides on importing in a large cvs repo into bzr? [04:24] Vantage13, is it an open source tree? [04:24] poolie: nope... [04:25] Vantage13, http://bazaar-vcs.org/BzrMigration?highlight=%28import%29#head-4b8472ce65e228eb1e87383ff908129305df9dee [04:25] cvsps-import is probably a good way to go [04:26] poolie: thanks. I'll give it a shot [04:26] please let us know if you have any problems/questions, or if it works well [04:29] poolie: my patch causes an error in a different test [04:31] just debugging now [04:32] k === jroes [n=jroes@halcyon.xeria.net] has joined #bzr [04:34] anyone ever accidentally try bzr pushing to sftp://blah.net/blah/blah without a username@? bzr (or maybe it's the paramiko dependency) crashes pretty hard on win32 [04:35] I don't use win32, but we do that all the time without a username [04:35] by crash do you mean you get a backtrace [04:35] yup [04:35] I get a python bt that is [04:35] could you file a bug then? [04:36] sure, looking for the bug tracker now [04:38] launchpad.net/bzr === igc food [04:40] doesn't look like an already existing one, surprisingly [04:40] I hope it's repro-able [04:41] poolie: the test fails cause of another bug AFAICT [04:41] abentle1: are you still up ? [04:42] lifeless: yeah [04:42] with nested trees [04:42] should we have a knit TREE_ROOT ? [04:43] A knit *for* TREE_ROOT? [04:43] yes [04:43] fileids_altered_by_revisions() [04:43] We do have one [04:43] returns {'TREE_ROOT':['ghost'] } [04:43] in the test test_fetch_all_fixes_up_ghost [04:44] when the source and target repo's are both KnitRepository3 [04:44] but there is no such source weave in the test case [04:44] I'm not sure if the test is invalid [04:44] That's strange. [04:45] if you apply my patch to fix the regex, then run ./bzr selftest test_fetch_all_fixes_up_ghost [04:45] you'll see the failure [04:45] The only case would be if there were no revisions to store. [04:46] I'm sorry, but I'm not feeling so hot tonight. [04:46] :(. Get well soon [04:46] Tx. [04:47] It's toothache. Very distracting. [04:47] its a test that sets up a manual repo [04:47] rather than using commit builder [04:47] Ooooh. [04:48] Then it sounds quite likely it's setting up an invalid knit3 repo. [04:49] yes [04:49] thats my conclusion, I'm upgrading it to commit builder [04:51] oh, now launchpad is cool. I was able to say "this also applies to paramiko" :) [04:51] lifeless, btw is configmanager in launchpad? [04:51] i couldn't find it the other week [04:51] uhm don't think so [04:52] k [04:52] hi, the http smart server guide says "this feature is EXPERIMENTAL and is NOT SECURE. It will allow access to arbitrary files on your server." i wonder how is that done? === nxsryan [n=ryan@linefeed.org] has joined #bzr [04:55] hello [04:55] NamNguyen: I think that is outdated, spiv can comment more [04:55] nxsryan: hi [04:55] i installed the plugin to send emails on commit -- i want this to happen anytime anyone commits. but where do i put the conf variables, then? [04:55] nxsryan: in ~/.bzr/locations.conf [04:55] nxsryan: bzr help email has documentation about this [04:56] lifeless: i looked at that [04:56] nxsryan: you can put them in ~/.bazaar/bazaar.conf [04:56] or ~/.bazaar/locations.conf [04:56] lifeless: i know that, i'm trying to figure out how to configure it so it happens for every user [04:56] lifeless: system-wide [04:56] the configuring-bazaar document has more details on the configuration system [04:56] i just pinged spiv, he should be on in a bit [04:56] nxsryan: bzr does not have a system wide configuration system at the moment, only per-branch, per user and per-user-location [04:57] hm :/ === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr [04:57] it'd be reasonable to read something like /etc/bazaar/bazaar.conf i guess [04:57] hello spiv, is the http smart server still prone to security problems? [04:57] there does seem some potential for unwanted disclosure if email is turned on globally [04:58] poolie: one can always disable it per user [04:58] if people are also keeping personal files say [04:58] poolie: definitely it'd be better to have the option and decide not to use it! [04:58] NamNguyen: I don't think so, but I haven't thought closely about it recently. I think with the ChrootTransport it should be fairly trustworthy. [04:58] Well, that calls for /etc/bazaar/locations.conf (rather, /usr/local/etc/bazaar/ for some of us) too... [04:59] spiv: the docs @ http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/http_smart_server.html says abitrary files might be read, i wonder how it is done? at the HTTP layer or at the bzr layer? [04:59] NamNguyen: I should re-read the documentation and update it. [05:00] blah. this plugin uses a weird switch to mail -> "mail: illegal option -- a" [05:01] it could have used smtplib [05:01] New bug: #139031 in paramiko "bzr push via sftp without username crashes on win32" [Undecided,New] https://launchpad.net/bugs/139031 [05:01] NamNguyen: We actually have some nicer stuff on top of smtplib also. [05:02] abentle1: does it support utf-8 on SMTP headers and message body? [05:02] i noticed your BB does support utf-8 in the message body [05:02]