[00:06] <[tpd]> Question : Can bzr-upload be visible in the windows right click menu?
[00:17] <lifeless> so jelmer, upload to debian? kgo
[00:17] <lifeless> [tpd]: I'm not sure, it could be added I imagine - you might like to file a bug asking for that.
[00:18] <james_w> lifeless: indeed
[00:18] <[tpd]> ok lifeless, just wanted to ask as it's not a core feature
[00:18] <[tpd]> So I'm not sure if it'll be added
[00:21] <lifeless> james_w: lets get a breakdown of the time-spent
[00:21] <lifeless> james_w: Ideally with one for apt-get source too
[00:21] <lifeless> james_w: turn that into a bug on bzr :)
[00:21] <james_w> you mean -Dhpss trace and some hacking to get a breakdown of downloading vs. unpacking for apt-get source
[00:22] <james_w> "bzr branch not as fast as apt-get source"?
[00:22] <lifeless> I think as s title thats a bit inflammatory ;) but yes
[00:22] <lifeless> also perhaps strace
[00:23] <lifeless> as things may happen outside of hpss - like the lp branch resolution lookup
[00:23] <[tpd]> One more question, is bzr-upload supposed to work on windows?
[00:23] <james_w> sure, I'll work on that
[00:23] <lifeless> [tpd]: I think so
[00:23] <james_w> I was very pleased to see the times comparable for small branches though, that's great
[00:23] <[tpd]> I'm having some trouble, see here : http://www.imgdash.com/uploads/b0d0d_Capture.png
[00:23] <lifeless> beuno: ^ your public awaits
[00:26]  * beuno looks
[00:27] <beuno> lifeless, that looks like bzr-svn breaking?
[00:27]  * beuno passes the ball to jelmer
[00:27] <james_w> I saw a bug like that the other day I think
[00:27] <james_w> I think it's fixed in a bzr-svn branch
[00:28] <beuno> [tpd], try disabling the bzr-svn plugin and trying again
[00:29] <james_w> bzr --no-plugins upload
[00:30] <lifeless> james_w: that will disable upload too :P
[00:30] <james_w> oh
[00:30]  * james_w gives up suggestions
[00:31] <vxnick> moving bzr-svn out of the plugins dir will work won't it?
[00:32] <james_w> yeah
[00:37] <[tpd]> gimme a sec
[00:38] <[tpd]> That worked great, cheers
=== kiko-afk is now known as kiko
=== qu1j0t3 is now known as FurnaceBoy
=== vxnick is now known as KX
[02:41] <ub3rst4r> does anyone know how to link a revision to a newly created release series?
[02:41] <ub3rst4r> in launchpad
[02:41] <bob2> if no one here pipes up, try #launchpad
[02:42] <lifeless> ub3rst4r: you link branches not revisions, to series
[02:43] <ub3rst4r> so i would have to create seperate branches then
[02:43] <lifeless> ub3rst4r: for what
[02:43] <ub3rst4r> for old releases
[02:44] <lifeless> ub3rst4r: you haven't said what you are trying to do
[02:44] <lifeless> ah, releases, not series. Different things ; )
[02:44] <lifeless> let me have a look-see
[02:44] <ub3rst4r> cus i release my source code to sf
=== rockstar is now known as Guest25594
[02:45] <ub3rst4r> theres no reason to have a different branch for every new version that comes out
[02:45] <lifeless> releases are tar files in launchpad
[02:45] <ub3rst4r> https://launchpad.net/lilregcleaner
[02:45] <lifeless> I don't think they have a revision field
=== rockstar` is now known as rockstar
[02:46] <lifeless> I've checked; at the moment you can't specify a revision in a release
[02:46] <lifeless> I'm filing a bug
[02:47] <ub3rst4r> a bug?
[02:47] <ub3rst4r> ok
[02:47] <lifeless> a bug about this
[02:47] <lifeless> its a reasonable thing to want to do, and you can't do it
[02:48] <ub3rst4r> k
[02:50] <ub3rst4r> thanks
[02:54] <lifeless> jelmer_: r543 of https://check.svn.sourceforge.net/svnroot/check/trunk may interest you
[02:59] <jelmer_> lifeless: Nice, congrats on finally landing it!
[03:03] <lifeless> thanks
[03:03] <lifeless> jelmer_: anything you want done in check, I can now commit
[03:03] <lifeless> long as it passes review yada yada yada
[03:08] <lifeless> jelmer_: final packaging update for a while, dev depends on lib now
[03:08] <lifeless> jelmer_: also, please upload to debian :)
[03:10] <jelmer_> lifeless: did you see my merge request for your packaging branch?
[03:10] <lifeless> no
[03:10] <lifeless> let me see
[03:11] <jelmer_> hmm, the web ui doesn't list it
[03:11] <jelmer_> lifeless: is launchpad supposed to accept merge requests for packaging branches yet?
[03:11] <lifeless> jelmer_: new feature, not released.
[03:11] <lifeless> its not supposed to ignore them
[03:12] <lifeless> but that doesn't mean it will honour them :)
[03:14] <lifeless> I can't see mail
[03:14] <lifeless> looking on web
[03:14] <jelmer_> lifeless:
[03:14] <jelmer_> lp:~jelmer/subunit/releases-revno
[03:16] <jelmer_> hmm, something is seriously wrong here: ganieda:~/git% bzr.foreign tags
[03:16] <jelmer_> bzr: ERROR: Cycle in graph [...]
[03:16] <lifeless> *blink*
[03:18] <lifeless> jelmer_: sure, land that in the releases tree; please also adjust it though to use a new dch entry and don't alter the successfully built-and-installed versions in changelog
[03:19] <jelmer_> lifeless: ah, right
[03:19] <jelmer_> lifeless: this has landed in karmic yet or just ppa for now?
[03:19] <lifeless> just ppa
[03:19] <lifeless> but its trivial to do right
[03:19] <lifeless> it will get into karmic from debian
[03:23] <jelmer_> lifeless: Any particular reason for the python2.6 dependency, or just that that's the default in jaunty?
[03:24] <lifeless> current default version
[03:24] <lifeless> as per the python policy
[03:24] <lifeless> [debian python policy at that :P]
[03:25] <jelmer_> hmm? sid still has 2.5 as default
[03:25] <lifeless> not the version, the explictness
[03:25] <lifeless> oh bugger, -dev now uinstallable
[03:25] <lifeless> remind me why I write libraries
[03:44] <lifeless> jelmer_: merge proposals web ui rejects the path for the packaging branch
[03:44] <lifeless> so yeah, its a fail
[03:44] <lifeless> filing a bug
[03:47] <lifeless> jelmer_: so arguably lp:~jelmer/subunit/releases-revno should be lp:~jelmer/ubuntu/jaunty/subunit/releases-revno
[03:47] <lifeless> jelmer_: as its not something to merge to upstream. But nevertheless ;)
[03:48] <jelmer_> I need to fix my personal bzr plugin to deal with them properly
[03:49] <lifeless> I've filed a bug on lp-code
[03:49] <jelmer_> thanks
[03:49] <lifeless> its probably something relatively simple
[03:59] <lifeless> bug 373952
[03:59] <ubottu> Launchpad bug 373952 in launchpad-code "merge proposal for a regular branch doesn't permit selecting a packing branch" [Undecided,New] https://launchpad.net/bugs/373952
=== dereine[OFF] is now known as dereine
[08:27] <madin60> hello
[08:28] <madin60> I want to use tu bzr-git plugin
[08:29] <madin60> but I don't understand how can I install Dulwich
[08:29] <madin60> module
=== dereine is now known as dereine[OFF]
=== dereine[OFF] is now known as dereine
[10:06] <xlax> Pff weird. I managed to "push" a repo to my ftp server, but there's no files there... Is that normal? :P (I only see .bzr)
[10:06] <bob2> yes
[10:06] <xlax> :o
[10:07] <xlax> And I was trying to fix that... -.-"
[10:07] <xlax> Thx
[10:07] <bob2> if you want it to create a checkout, too, there's a update-after-push plugin
[10:07] <bob2> but I don't think it works over ftp
[10:07] <xlax> But is it required if I just want that to be a backup.
[10:08] <bob2> no
[10:08] <bob2> all the revision data is in .bzr, there's just no checkout
[10:08] <bob2> (you can test - cd /tmp ; bzr branch ftp://.../)
[10:09] <xlax> I was just about to try that :P
[10:09] <xlax> Lookin' slick :P
[10:10] <xlax> Thanks.
=== dereine is now known as dereine[OFF]
=== dereine[OFF] is now known as dereine
=== dereine is now known as dereine[OFF]
=== vxnick is now known as vxnick_away
=== dereine[OFF] is now known as dereine
=== vxnick_away is now known as vxnick
=== dereine is now known as dereine[OFF]
=== krisfree is now known as krisfremen
[16:02] <balachmar> Hi, what is the easiest way to make a bzr branch available to other users. Without giving them further access to the system? I want the users to be able to read/write to the bzr branches but they should not be able to look at the rest of the system.
[16:02] <SamB> balachmar: publish via HTTP or push to launchpad
[16:02] <SamB> oh, read/write
[16:02] <SamB> that's trickier
[16:03] <SamB> well ... you could publish to launchpad and add them to a team which has read/write access ...
[16:04] <james_w> forced command ssh will get you part way there
[16:04] <balachmar> SamB: Well, the code will be of a website and I am not quite sure if I want to share that with everyone. So I guess launchpad is a nogo.
[16:05] <SamB> balachmar: hmm.
[16:05] <balachmar> james_w: forced command ssh?
[16:05] <SamB> balachmar: and why don't you want to let them have full SSH access to the machine ???
[16:05] <james_w> you give them ssh access, but only to run a single command
[16:05] <SamB> it might be useful if they have code to test, anyway ...
[16:06] <balachmar> SamB: Well, there is other stuff on the same server, which they don't need access to.
[16:06] <balachmar> Samb: They can log into the server, but just only look at stuff in their home.
[16:07] <SamB> balachmar: and unix groups aren't enough for that?
[16:08] <SamB> I think you should just allow them read/write access to the bzr repository for the website, and either set up a plugin to update the website when they push to the repository, or set up automatic pull
[16:09] <balachmar> I fear I might need to read up on that. I am not a sysadmin or anything. Basically just an Ubuntu user. And I have some knowledge, but not really on the administrative side of things.
[16:10] <SamB> balachmar: create a unix group, set the repository directory (and contents) to be owned by www.thegroup, and set the permissions to allow writing by the group ...
[16:11] <balachmar> SamB: But then they would still be able to read contents of the other directories. In a normal ubuntu installation.
[16:15] <balachmar> maybe just giving the user rbash will be enough. I don't expect them to try hacking the server.
[16:16] <balachmar> but ok, that is another issue. So sftp it is... :) Now just figuring out how to get it working :)
[16:17] <pygi> SamB: can I suggest something?
[16:17] <pygi> ups
[16:18] <pygi> that was for balachmar :)
[16:18] <balachmar> of course you may suggest something :)
[16:22] <balachmar> I think I will use rssh
[16:31] <cornucopic> vila, ping. I have filed the bug report for the second issue. Please check: https://bugs.launchpad.net/bzr/+bug/374139
[16:31] <ubottu> Ubuntu bug 374139 in bzr "'authentication.conf' accepts a server name of the form 'server:port'" [Undecided,New]
=== abentley1 is now known as abentley
[16:40] <pygi> balachmar: nah
[16:40] <pygi> ClueBzr-server
[16:40] <pygi> you need to highlight me :P
[16:40] <pygi> balachmar: rather simple thing, writing/reading over bzr+http, no ssh access
[16:40] <balachmar> pygi: Will do :P
[16:40] <jelmer_> pygi: what's up with ClueBzr-server these days?
[16:40] <cornucopic> vila, with reference to your https://bugs.launchpad.net/bzr/+bug/372800/comments/1, the SMTP server is running on a default port. Is your reasoning still valid?
[16:40] <ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress]
[16:40] <pygi> jelmer_: what do you mean?
[16:40] <balachmar> pygi: Got it set up already using rssh works perfectly as well
[16:41] <pygi> balachmar: oh well, oki :p
[16:41] <balachmar> pygi: but thansk anyway!
[16:41] <balachmar> thanks
[16:41] <pygi> jelmer: its in ok state, but it could be way better
[16:41] <pygi> I've hacked up some improvements to it, but I'd like the design improved in certain places
[16:42] <pygi> tho rocky is the chief, I'm just a random user :)
[16:42] <jelmer_> ah :-) what's the homepage?
[16:42] <cornucopic> vila, according to the manual, 'port' should be used only when "the server uses a port different than the scheme standard port,"
[16:42] <pygi> jelmer_: http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
[16:47] <pygi> jelmer_: I have no idea if he'll be at UDS so we could discuss the changes, but I don't think he'd mind patches :p
[16:48] <jelmer_> pygi: are you going to be at UDS?
[16:48] <pygi> jelmer_: yes
[16:48] <jelmer_> cool, me too
[16:48] <pygi> hehe, fantastic!
[16:49] <pygi> first time that I am actually attending xD
[16:50] <jelmer_> it's somewhat the first time for me, I attended one afternoon/evening of UDU
[17:00] <cornucopic> !seen vila
[17:00] <ubottu> I have no seen command
[17:01] <jelmer_> cornucopic: probably enjoying his well-earned weekend
[17:01] <cornucopic> jelmer, okay :) No problem! thanks!
[17:04] <cornucopic> all: Does the 'smtp_server' given in bazaar.conf 'percolate' down to 'host' in 'authentication.conf' ?
[17:06] <Noya> hello everyone
[17:06] <Noya> I seem not to be able to get bzr-email to run
[17:07] <Noya> if anyone has bzr-email running: in what config file do I have to add the post_commit_to = a@b.c ?
[17:07] <Noya> I tried .bazaar/bazaar.conf
[17:07] <Noya> and BRANCH/.bzr/branch/branch.conf
[17:08] <cornucopic> Noya, .bazaar/bazaar.conf does it for me
[17:08] <cornucopic> Noya, I am using smtplib
[17:08] <Noya> cornucopic: so you added it on the server side and everytime you push it'll send a email, right?
[17:10] <cornucopic> cornucopic, Okay. I am sorry. You are refering to the post_commit email recipient? That would be the later option
[17:10] <cornucopic> Noya, ^^
[17:12] <Noya> cornucopic: what do you mean by "later option"? ;)
[17:12] <cornucopic> Noya, in branch.conf.
[17:12] <Noya> okay
[17:13] <Noya> let me describe the setup that I have in my mind, just to be sure we talk about the same ;)
[17:13] <Noya> I have a server (foobar.org) and am working at home (home)
[17:14] <Noya> there is a user on my server called "bzr" and at home I am "noya"
[17:14] <Noya> noya@home$ bzr push bzr+ssh://foobar.org/somebranch
[17:15] <Noya> I want my foobar.org to send a mail to a mailinglist
[17:15] <Noya> when I push like described above :)
[17:16] <Noya> cornucopic: so I thought I would have to edit /home/bzr/.bazaar/bazaar.conf on foobar.org and put all the email-configuration in there
[17:16] <cornucopic> Noya, I have set up my commit emails properly, but I haven't tried push yet. And for my commit emails, I have set it up in 'branch.conf'. So, I am not going to be able to help in your scenario :)
[17:17] <cornucopic> Noya, In a week's time, may be, but that would probably be of no use to you :
[17:18] <Noya> cornucopic: ;)
[17:18] <Noya> cornucopic: thanks anyway :)
[17:18] <cornucopic> Noya, :)
[17:18] <asabil> Noya: hey dude
[17:18] <Noya> asabil: hey there ;)
[17:18] <asabil> Noya: you can check this plugin: https://code.launchpad.net/~johncarr/+junk/bzr-watcher
[17:19] <asabil> I never used it, but it sort of does what you want I think
[17:19] <asabil> there is also the bzr-email plugin iirc
[17:20] <Noya> asabil: right now I am trying to setup the bzr-email plugin
[17:20] <Noya> but I fail terribly ;)
[17:21] <asabil> let me check it out
[17:22] <asabil> Noya: are you using bzr+ssh when pushing ?
[17:22] <asabil> or bzr:// ?
[17:22] <Noya> asabil: yes
[17:23] <Noya> asabil: bzr+ssh
[17:23] <asabil> oki
[17:28] <Noya> tro:
[17:29] <Noya> whoops, sorry
[17:30] <asabil> Noya: do you have any specific error ?
[17:31] <Noya> asabil: sorry no, just nothing happens
[17:31] <Noya> the same as I wouldn't have installed the plugin
[17:33] <asabil> Noya: I don't think it is a plugin
[17:33] <asabil> but actually a separate program that you need to run
[17:33] <Noya> asabil: bzr-email is installed in bzrlib/plugins
[17:34] <Noya> and the doc says it is a simple post_commit_hook that gets called
[17:35] <asabil> Noya: ah we are not talking about the same one it seems
[17:35] <asabil> there is bzr-email-notifier
[17:36] <Noya> asabil: oh right
[17:36] <Noya> asabil: that doesn't look too bad
[17:36] <asabil> I think it is better to have the email notification stuff out of the bzr serve process
[17:37] <asabil> so I would go for the bzr-email-notifier solution instead
[17:38] <Noya> asabil: in the readme it says it is intended to be used on a server unlike the bzr-email plugin
[17:38] <Noya> asabil: nice :)
[17:40] <asabil> Noya: otherwise, I think you need to have post_commit_push_pull = True
[17:40] <asabil> in your bazaar.conf for bzr-email
[17:40] <Noya> asabil: did that, but didn't work either
[17:40] <Noya> asabil: I guess you are right and I'll take the bzr-email-notifier tool :)
[17:42] <asabil> ok, good luck with that
[17:51] <LarstiQ> Noya: also, you need to have the branch you're pushing to configured to email
[17:51]  * LarstiQ scrolls up a bit
[17:53] <LarstiQ> Noya: I'd pick locations.conf or .bzr/branch/branch.conf
=== mario_ is now known as pygi
[17:53] <LarstiQ> Noya: if locations.conf, and on the server as the user you're pushing at, over a smart protocol (so far so good), the branch location should be that as what you access it with remotely
[17:54] <LarstiQ> Noya: ie, it should be [bzr+ssh://server/srv/bzr/branch] and not [/srv/bzr/branch]
[17:54] <Noya> LarstiQ: so does every user have to configure it locally?
[17:55] <Noya> + on the server
[17:55] <Noya> or should it work if the branch on the server is configured?
[17:55] <Noya> only the branch on the server
[17:56] <LarstiQ> Noya: this is with bzr-email. If you use bzr-watcher/bzr-hookless-email/bzr-email-notifier, then it doesn't run from the bzr push, so users don't need to confiure
[17:56] <LarstiQ> Noya: but if you're using bzr-email, either all the ~user/.bazaar/locations.conf need to be configured so, or all the branch.conf's need to be.
[17:57] <LarstiQ> Noya: do note that you can get cascading with locations.conf, so if all the branches below a certain directory have the same configuration, you can just use [bzr+ssh://server/certain/directory]
[17:57] <LarstiQ> if you're not using bzr-email, then all this is moot :)
=== vxnick is now known as vxnick_away
[18:00] <asabil> jelmer: ping ?
[18:04] <Noya> LarstiQ: thanks for the info
[18:04] <Noya> as I don't want the users to configure anything I'll stick with bzr-email-notifier
[18:04] <Noya> let's see how this works out :)
[18:04]  * LarstiQ nods
[18:04] <Noya> okay people, thank you for your help
[18:04] <Noya> you've been very kind :)
[18:04] <Noya> gotta hop now
[18:04] <Noya> see you
=== vxnick_away is now known as vxnick
[19:26] <[-TPD-]> I've just installed bazaar on ubuntu 9.04, where are the plugins stored when installing via aptitude?
[19:27] <jelmer_> [-TPD-]: see the output of `dpkg -L <name>`
[19:27] <[-TPD-]> I've got this result, but I'm not sure it's correct
[19:27] <[-TPD-]> ok
[19:27] <jelmer_> [-TPD-]: or `bzr plugins -v`
[19:27] <[-TPD-]> ah, cheers
[19:49] <[-TPD-]> One more question, does bzr-upload integrate with eclipse?
[19:50] <LarstiQ> [-TPD-]: not by itself, no clue if the eclipse plugins do something with it.
[19:51] <[-TPD-]> hmm, because the bazaar extension has plugins path, so it must be doing something
=== dereine[OFF] is now known as dereine
=== dereine is now known as Taschentuchkille
=== Taschentuchkille is now known as dereine
=== krisfree is now known as krisfremen
[21:14] <[-TPD-]> I'm having a problem with upload when using the eclipse plugin
[21:14] <[-TPD-]> Seems to be caused when using the --auto switch
[21:14] <[-TPD-]> on commit via eclipse I get the following error.
[21:14] <[-TPD-]> 'cStringIO.StringO' object has no attribute 'encoding'
[21:14] <[-TPD-]> 'cStringIO.StringO' object has no attribute 'encoding'
[21:15]  * LarstiQ would need to see a (pastebinned) traceback to know more
[21:15] <[-TPD-]> How would I do that? I will happy to provide
[21:16] <LarstiQ> [-TPD-]: if it doesn't show you a traceback, you can get it from ~/.bzr.log. http://rafb.net/paste/ or any other for the binning
[21:25] <[-TPD-]> LarstiQ, http://bzr.pastebin.com/m40ebebd5
[21:26] <AmanicA> [-TPD-]: normally with bzr-eclipse I check if I have the latest updates and also the latest xmloutput plugin
[21:27] <[-TPD-]> I already updated xmlout, 0.8.3 was the latest
[21:43] <madin60> bonjour, je cherche de l'aide pour installer le plugin bzr-git
[21:47] <LarstiQ> hmm, [-TPD-]'s .bzr.log did not include a backtraxe
[21:48] <[tpd]> back
[21:48] <LarstiQ> [tpd]: your .bzr.log doesn't seem to include a traceback, weirdly enough
[21:49] <LarstiQ> [tpd]: different user maybe?
[21:49] <[tpd]> No idea, I've given up for now, waste too much time on it
[21:49] <LarstiQ> ok
[21:49] <[tpd]> No, don't think so LarstiQ
[21:49]  * LarstiQ goes to bed then
[21:50] <LarstiQ> madin60: if you ask your question, someone might know the answer
[21:51] <LarstiQ> night
[21:51] <[tpd]> night
[22:06] <madin60> Sorry
[22:07] <madin60> I can i install the dulwich module? It's in order to use the bzr-git plugin
[22:07] <madin60> How can I install...
[22:29] <jfroy> jelmer: hit that missing revision bug again on another branch
[22:29] <jfroy> :)
[22:29] <jfroy> * :(
[22:30] <jfroy> Same project, they're all branches derived from the same trunk branch.
[22:32] <jfroy> mmm, interesting!
[22:32] <jfroy> I just solved it by packing the shared repository storing the branches.
[22:33] <jfroy> I think I upgrade that repository or branch from 1.9 to 1.14
[22:33] <jfroy> Seems like you *must* pack after doing that or you'll run into problems. This suggests upgrade should automatically run a pack after it completes...
[22:40] <Peng_> 1.14 is exactly the same repository and branch format as 1.9.
[23:21] <jfroy> Peng_: might have been some other format then....