[00:00] <jelmer> groo_: It hasn't changed recently - see the bzr bug report for details: https://bugs.launchpad.net/bzr/+bug/402814
[00:37] <poolie> good morning
[00:49] <groo_> jelmer: tks for info :)
[00:58] <spiv> Good morning.
[01:06] <poolie> hi spiv, jelmer
[01:15] <maxb> hrm
[01:16] <maxb> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing text keys: [('dulwich/____init____.py', 'git-v1:f60d0a17de087f21708f7f32115b7cc957d51a1a'), ....
[01:16] <maxb> in our dulwich-daily recipe
[01:16]  * maxb suspects the damaged divergence of pushed and dpushed dulwich
[01:47] <TJNII> I've set up bzr as a centralized vcs successfully.  Now I would like to set up a directory that gets updated every time something is committed to the central repo, so that it always the newest and shiniest bits.  This directory will be read only, so merging should not come in to play.  Is a hook script the best way to do this, or can loggerhead do this better?  I'm mainly wondering what documentation to read at this stage.
[01:51] <spiv> TJNII: loggerhead is a web UI for viewing bzr branches
[01:52] <spiv> It looks like http://bazaar.launchpad.net/+branch/bzr
[01:52] <TJNII> Okay, so that's a no, then.
[01:53] <TJNII> Thanks for the example, though.  I was wondering what it looked like.
[01:56] <poolie> TJNII: there is a push-and-update plugin that might be what you want
[01:56] <TJNII> poolie: But that needs to be installed for each client, yes?
[01:57] <maxb> although, that relies on the person pushing to use it
[01:57] <maxb> I think a hook would make the most sense here
[01:57] <poolie> yes
[01:57] <TJNII> Requiring all users to run it isn't really feasable.... Is there a sound argument against a hook?
[01:57] <poolie> a server side hook to do this would be good
[01:57] <TJNII> Okay, that's what I thought.
[01:57] <poolie> there probably is such a hook
[01:57] <TJNII> Thanks for the confirmation.
[01:57] <poolie> post_tip_change
[01:57] <poolie> but i don't know if there is something that hooks into it that will update the tree
[01:57] <maxb> although a hook will only fire if the push is over a smart transport
[01:57] <poolie> if you know python it should not be hard to run
[01:58] <poolie> there is that too
[01:58] <poolie> another option is to just set up a cron job to update the working tree
[01:59] <TJNII> Which transports would not be considered "smart"?
[02:00] <maxb> Ones which do not rely on there even being a copy of Bazaar installed on the server
[02:01] <spiv> TJNII: http://doc.bazaar.canonical.com/plugins/en/automirror-plugin.html might be close enough.
[02:01] <spiv> TJNII: pushing over bzr+ssh is "smart", i.e. runs bzr on the server.  Pushing over sftp isn't.
[02:02] <maxb> bzr+ssh is smart. http will try to use smart bzr+http if available, otherwise fall back to dumb http. sftp is dumb file operations
[02:02] <spiv> The automirror plugin is at least an example of using the post_change_branch_tip hook.
[02:02] <TJNII> maxb: How does that work in a centralized configuration without bzr?  I thought bazaar did not maintain a usable tree that could be accessed directly due to logistical reasons at the core repo?
[02:02] <TJNII> By "usable" I mean "directly accessable"
[02:03] <TJNII> My verbage was not to good, there.
[02:03] <maxb> directly accessible by a human using basic file tools isn't the same as accessible using Bazaar remotely
[02:04] <TJNII> Oh, so the remote bazaar modifies the .bzr directory?
[02:04] <spiv> TJNII: is your central repo written to via bzr+ssh?
[02:05] <TJNII> spiv: Right now, yes.  I think I can maintain that, though I haven't played with the Windows end yet.
[02:05] <spiv> Ok, that works well then.
[02:06] <spiv> Because bzr+ssh means bzr is running on the server, and the client is merely asking the server's bzr to make changes rather than writing to .bzr itself.  So you just need to install the hook on the server, and it will be run.
[02:07] <TJNII> Aah, I understand.
[02:07] <spiv> I'd try the automirror plugin first, I think it's pretty close to what you want.
[02:08] <TJNII> Gotcha, thanks.
[02:31] <poolie> jelmer, are you still here?
[02:31] <poolie> what do you think of bug 758758 vs bug 681582?
[06:23] <spiv> poolie: do you know anything about “AssertionError: NoWhoami not raised” test failures on lp:bzr/2.3?
[06:23] <poolie> hi spiv
[06:23] <poolie> there is a bug open for it
[06:24] <spiv> Hmm, do you have the number handy?  A search didn't find it for me.
[06:25] <spiv> I'm a bit puzzled about how it passed PQM, perhaps there's a test isolation problem?
[06:25] <poolie> spiv it is a test isolation thing
[06:25] <poolie> specifically the heuristic of having /etc/mailname probably works on your laptop but not on pqm
[06:26] <poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/56503
[06:26] <poolie> is supposed to have fixed it
[06:26] <spiv> But isn't merged to 2.3?
[06:28] <poolie> ah ha
[06:28] <poolie> was meant to go in to 2.3 but did not
[06:28]  * spiv wonders where his ssh agent went
[06:32]  * spiv wonders where the environment variables pointing to the perfectly good ssh agent went
[06:33] <poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/57436
[06:33] <poolie> the diff to 2.3 looks reasonable so i'll send it
[06:34] <spiv> poolie: if it's the same fix already approved & merged for lp:bzr then I approve without even looking at it :)
[06:34] <spiv> Thanks!
[06:35] <spiv> For bonus points, do you think gnome-session is a reasonable package to file a bug against if my new terminal instances started by Ctrl-Alt-T (but not Ctrl-Shift-N from an existing terminal!) are lacking environment gnome-sessiony variables?
[06:35] <poolie> and, ah, https://bugs.launchpad.net/launchpad/+bug/676769
[06:36] <poolie> filed by you :)
[06:36] <poolie> spiv i'd guess that was a gnome-terminal bug
[06:36] <poolie> that's surprising
[06:36]  * spiv hmms
[06:36] <poolie> it seems like it would have to try hard to break it
[06:37] <spiv> Huh, yes, maybe g-t
[06:37] <spiv> Using Alt-F2 to run xterm inherits the vars ok
[06:37]  * spiv wonders what the Ctrl-Alt-T shortcut does exactly.
[06:39] <spiv> Hmm, part of the “Gnome compatibility plugin” in ccsm
[06:43] <poolie> wow
[06:43] <poolie> ok, i sent that to pqm
[06:44] <poolie> spiv i might go out for a bit, as i have some calls tonight
[06:44] <poolie> should be back about 5
[06:44] <spiv> Ok, see you later
[07:35] <maxb> mm yay it's beta time again, watch the ~bzr/beta ppa become a nightmare of uninstallability
[07:40] <maxb> jelmer: I want a bzrtools snapshot in ~bzr/beta for installability, are you interested in having it in experimental too (i.e. should I prepare it on the alioth experimental branch?)
[08:21] <spiv> losa ping: http://pqm.bazaar-vcs.org/ is giving 503 Service Temporarily Unavailable.  Is that a known issue?
[08:22] <spm> hrm. not by me.
[08:24] <spm> spiv: iz back; had crashed
[08:28] <spiv> spm: thanks!
[08:28] <spiv> And apparently poolie's patch for 2.3 didn't land.  Hmm.
[08:30] <spm> I call cause and effect. poolie's patch is clearly evil and crashed the pqm ui.
[08:31] <poolie> maxb: what happens around beta time?
[08:31] <poolie> bzr betas?
[08:32] <maxb> the usual api compatibility versioning nonsense mess
[08:33] <poolie> because of bzr changes?
[08:33] <poolie> oh, from 2.4b1?
[08:33] <poolie> :/
[08:33] <maxb> yes
[08:33] <maxb> and of course right up there in front in bzrtools
[08:35] <maxb> I have a lot of disbelieve that bzrtools 2.3.x cannot function reasonably with bzr 2.4
[08:35] <maxb> *disbelief
[08:35] <maxb> but it insists on being awkward
[08:36] <maxb> aaaaanyway. I should probably go to work
[08:36] <poolie> i agree
[08:36] <poolie> i mean i share your disbelief
[08:36] <poolie> i'd like to put up a patch to relax the check
[08:36] <poolie> either in bzrtools or bzr core
[08:37] <poolie> hi jam
[08:37] <jam> maxb: abentley prefers to make sure that at least the test suite passes before he "signs off" on it being compatible
[08:37] <jam> hi poolie
[08:39] <poolie> jelmer are you up yet?
[08:40] <poolie> spiv, spm, i didn't getting a failure message from pqm
[08:40] <spiv> poolie: hmm!
[08:40]  * spm hi-fives spiv - troll successful;
[08:40] <poolie> i'm preitty sure
[08:42] <spiv> spm: it's cheating if you use your admin powers to crash the system to rig the result ;)
[08:42] <poolie> canberra must be more boring than i remembered
[08:43] <spm> poolie: 1, spm 0
[08:44] <bob2> haha
[08:46] <poolie> spm, so, seriously, is there any evidence?
[08:46] <poolie> hi bob2
[08:46] <bob2> 'evening
[08:46] <spm> poolie: that your patch crashed it? Idoubt it. the ui is independant of pqm itself. I've not et chased why it crashed.
[08:48] <spm> poolie: when was your patch sent in? I'm not seeing anything in the log since about 10am our time, and that was something from jam
[08:48] <poolie> ah, i wonder if it even left my machine
[08:49] <jam> spm: last patch was about 1am my time I think. Which is, 23:00 UTC?
[08:49] <spm> jam: dat's der bunny
[08:49] <poolie> nup, stuck in postfix!
[08:49] <spm> poolie: that's impressive! that your patch didn't even hit pqm and still managed to crash the ui!!
[08:53] <spm> spiv: hrm. looks like it may have been down for a while. since ~ 8am on the 11th our time.
[08:53] <spm> no reason why, just no running, afaict.
[08:55] <spiv> spm: hmm.  Please arrange the cosmic ray reflectors in the data centre to point at someone else's box, thx.
[08:55] <poolie> spm, you know bradm did the upgrade to lucid the other day?
[08:55] <poolie> ok, apparently a change to my internet setup was causing my mail to queue up here
[08:55] <poolie> it should have left now
[08:56] <spm> poolie: that was just in the chroots aiui?
[08:56] <poolie> yes, we copied the chroot, upgraded the new copy, and pointed pqm at that
[08:56] <poolie> so it should not have caused pqm to stop running
[08:56] <poolie> unless the config change had a typo or something
[08:56] <spm> hrm. the timing is sus
[08:57] <spm> very sus. aligns perfectly. I'd say that was it. something about the chroot upgrade crashed it.
[08:57] <jelmer> poolie: hi
[08:58] <spm> hey jelmer
[08:58] <jelmer> hey Steve
[08:59] <poolie> spm, but other pqm requests do seem to have got through in the interim
[08:59] <jelmer> maxb: having bzrtools in experimental seems reasonable
[09:00] <spm> poolie: for sure. the UI isn't needed to get stuff thru pqm; it's actually a very separate process(?) within the same code.
[09:00] <jam> poolie: are we doing the standup now?
[09:00] <maxb> ok, I'll look at that after I've got 2.4b1 done for all series
[09:04] <poolie> yes, it's time
[09:05] <jam> poolie: jelmer spiv and I are in mumble
[09:06] <poolie> hm having some trouble getting in
[09:06] <jam> poolie: mwa-ha-ha-haaaa!
[09:07] <jelmer> jam: your laugh is particularly diabolical today ?
[09:10] <jelmer> poolie: you've muted me, I can't unmute myself as far as I can tell
[09:11] <poolie> oop
[09:11] <poolie> why would i do that? :)
[09:20] <poolie> jam perhaps you should take more inprogress bugs onto your kanban
[09:21] <poolie> Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
[09:22] <poolie> jelmer, https://wiki.ubuntu.com/UDS-O#preview
[09:43] <poolie> spiv, spm, i did get back an apparently real failure
[09:44] <poolie> i wish our pqm failures were a bit more to-the-point
[10:58] <poolie> SRU progressed, yay!
[10:58] <poolie> http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates#preview
[11:10] <maxb> Yay
[11:10] <maxb> Give Karmic's impending EOL, any objections to changing "not urgent" to "not going to happen" ?
[11:12] <jelmer> maxb: I think so
[11:12] <poolie> +1
[11:13] <poolie> i would like to get the lucid one out though
[11:13] <poolie> someone asked about it the other day
[11:13] <maxb> poolie: Oh, if you really want to test in a ppa, if you define a new dput configuration stanza using incoming = ~%(ppa)s/ubuntu/maverick, the trailing path segment will override the specification in the changelog and changes file
[11:13] <poolie> perhaps this will get faster
[11:13] <poolie> maxb maybe you should apply for upload rights too?
[11:13] <poolie> oh, that's useful
[11:13] <poolie> could you add that to the page if you're changing it?
[11:13] <poolie> ok, really offline now
[11:13] <poolie> have a good night
[11:13] <poolie> or whatever
[11:13] <maxb> I'm not sure I recomment it however
[11:14] <poolie> i think on the whole there are probably enough checkpoints
[11:14] <maxb> Because it will cause .debs to exist in your ppa which are named and versioned like the primary archive, but are not the same build
[11:14] <poolie> right
[11:15] <maxb> yeah, maybe I should apply for PPU - between PPA stuff and Ubuntu process knowledge, I probably qualify
[11:32] <jml> poolie: your blog is down.
[11:32] <jml> http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html fails
[11:33] <poolie> maxb: i would certainly endorse you
[11:34] <poolie> hi jml
[11:34] <poolie> i think the machine might be down
[12:44] <briandealwis> jelmer: thanks for the new bzr-git release.  But 0.6.0 complains that it needs dulwich >= 0.7.1 – which isn't available
[12:58] <briandealwis> …ah, but there is a dulwich-0.7.1.tar.gz available on jelmer's dulwich page, though it's not linked
[13:12] <jelmer> briandealwis: not linked where?
[13:29] <briandealwis> http://samba.org/~jelmer/dulwich/
[13:29] <briandealwis> Ah, it shows 0.7.0 twice
[13:29] <briandealwis> jelmer: ^
[13:30] <jelmer> briandealwis: should be fixed now
[13:30] <briandealwis> coolio, thanks.
[13:32] <briandealwis> jelmer: in case you want more nits, lp:bzr-git lists 0.5.4 as the latest and lp:dulwich lists 0.7..0 as the latest
[13:32] <jelmer> briandealwis: you mean the tags?
[13:37] <briandealwis> jelmer: both the latest file versions, and I guess the tags (they're listed as "milestones" with an open circle vs the closed circles for the other versions)
[13:37] <jelmer> briandealwis: the milestones aren't related to the tags
[13:38] <jelmer> briandealwis: the file versions on the site are updated automatically by Launchpad, I guess it hasn't picked them up yet
[14:10] <sambatyon> hey guys, I need some help. There is some file in the repository, the project file. This project file will be changed in my local branch but I don't want it to be commited, or updated nor pulled nor merged, or anything of the sort, since paths and other stuff are particularly to my environment. However the project needs to be in the main branch so new programmers can customized it. Is there a way to avoid these things to get caught by
[14:10] <sambatyon> bazaar in merges and things like that?
[14:18] <maxb> The standard solution is to keep a template file in the branch, and let developers copy it to a new name before making their local modifications
[14:18] <maxb> e.g. project.conf.template in the branch, people use it to create a project.conf locally
[14:21] <sambatyon> yes, I would do that… unfortunately I am not the admin
[14:26] <sambatyon> (and now it is too late for that)
[14:55] <gypsymauro> hi
[14:56] <gypsymauro> I'm trying to ceckout a working copy with sftp but I get this error: bzr: ERROR: Not a branch: "sftp://root@192.168.64.244/home/bzr
[14:57] <gypsymauro> any hint?
[14:57] <maxb> Ok... Is that location actually a branch? Does /home/bzr/.bzr/branch/format exist?
[14:59] <gypsymauro> yeah Bazaar Branch Format 7 (needs bzr 1.6)
[15:00] <maxb> OK, please try the command again with the -Derror flag and pastebin the output
[15:07] <gypsymauro> maxb: http://pastebin.com/WhdUW8A2
[15:07] <maxb> What version is Bazaar on the client side?
[15:08] <gypsymauro> the same on the server 2.1.2-1
[15:09] <gypsymauro> funny is that if I run bzr co on local machine it works
[15:13] <maxb> Please try running:
[15:13] <maxb> echo "get /home/bzr/.bzr/branch-format" | sftp root@192.168.64.244
[15:18] <gypsymauro> File "/home/bazar/.bzr/branch-format" not found.
[15:18] <gypsymauro> but there is that file
[15:19] <gypsymauro> doh...
[15:19] <mgz> spelling?
[15:19] <gypsymauro> two ssh processes on the same ip...
[15:21] <gypsymauro> sorry :)
[15:21] <gypsymauro> I need a cup of coffee..
[15:22] <mgz> maxb or someone, what's the right way of dealing with all these bzr (ubuntu) bugs poolie opened up?
[15:23] <mgz> I can mark it confirmed, but should I open it against bzr (upstream) where I have tracker rights?
[15:28] <jam> mgz: I would use "Also Affects Project"
[15:28] <jam> and add bzr
[15:28] <jam> and then we can decide what to do with the upstream portion
[15:29] <jam> I often close it with a "moving to upstream"
[15:29] <mgz> thanks jam.
[15:29] <jam> because we don't usually care about the status in a particular "Ubuntu" package
[15:29] <jam> It is unfortunate that you can't just say "this is Upstream" directly
[15:29] <mgz> just posting a commect on your bug 758652 as well.
[15:29] <jam> but I think there is a bug open in LP about it.
[15:29] <maxb> mgz: what bugs?
[15:29] <mgz> bug 686735 for eg. which I want to fix today.
[15:30] <jam> mgz: yeah, it looks like reporting bugs via apport defaults to making them private
[15:31] <jam> so Martin has to go through them and make sure there isn't anything personal included and manually make them public
[15:31] <mgz> right.
[15:31]  * jam doesn't like bottlenecking things through a single person
[15:40] <gypsymauro> suppose I move a repository from a machine to another , there is a way to udpate a local working copy to point to the new location of the repository?
[15:41] <jam> gypsymauro: if you are using a lightweight checkout "bzr switch --force"
[15:41] <jam> (--force if the old repo no longer is available)
[15:42] <gypsymauro> jam: not lightweight
[15:42] <jam> gypsymauro: heavy checkout then? 'bzr switch' still works
[15:42] <jam> if it isn't a checkout, and just a branch, and you want to update the push and pull locations
[15:42] <jam> use '--remember'
[15:42] <jam> bzr push --remember new-location
[15:42] <jam> etc
[15:43] <gypsymauro> doen with "checkout" is an heavy right?
[15:44] <vanguard> how much work would it be approx. to do i18n on the bzr cli?
[15:44] <jam> gypsymauro: yes
[15:45] <jam> vanguard: There are quite a lot of strings around. I think the biggest hurdle we ran into was that importing gettext is *slow*
[15:45] <jam> added something like 0.5s to every run
[15:45] <jam> I don't remember the details anymore, but that was a fair punishment for trying to do it.
[15:47] <vanguard> jam: so it is basically cancelled?
[15:49] <jam> vanguard: I don't think anyone has confirmed the results in a while (like a couple of years)
[15:49] <jam> so it might be wrong
[15:49] <jam> I know the guis are translated
[15:49] <vanguard> Explorer and qbzr are, bzr-gtk is not I think
[15:49] <jam> right
[15:50] <jam> I know bzr-gtk does import gettext
[15:50] <jam> it used to break when in a debugger because of gettext evil and the '_' operator
[15:50] <jam> (gettext would create a builtin '_' operator, but pdb uses '_' as the result-of-last-command variable
[15:50] <vanguard> maybe it just has no german l10n. What is the gettext evil?
[15:50] <vanguard> right, I see
[15:50] <jam> which would then break like mad when bzr-gtk would try to _() a string)
[15:51] <vanguard> so the _ is not that clever in python I gather
[15:55] <gypsymauro> there was a new file, I made a ci and it marked aas unknown, now if I do a bzr add it doesn't add it :/ the default is recursively right?
[15:56] <jam> gypsymauro: what does "bzr status" say?
[15:57] <jam> add is recursive by default, yes
[15:57] <jam> The file might be ignored?
[15:58] <gypsymauro> it says, unkown: pathofthefile
[15:58] <jam> gypsymauro: if it shows up as unknown, then it should be added by plain 'bzr add'
[15:58] <jam> Only thing I can think is if you have a secret subtree that is in the way
[15:59] <gypsymauro> uh
[16:00] <gypsymauro> no
[16:00] <gypsymauro> I defenitely need a coffee
[16:00] <gypsymauro> you can see the status if you are in a different subtree
[16:00] <gypsymauro> but bzr add doens't works globally
[16:00] <gypsymauro> u need to be on the root
[16:00] <gypsymauro> or on the right folder
[16:02] <jelmer> jam, vanguard: bzr-gtk uses _i18n rather than _()
[16:02] <jelmer> the gettext import overhead is negligable these days
[16:02] <jam> jelmer: it does *now* it didn't many moons ago
[16:03] <jam> AIUI, it does specifically because of that
[16:03] <jelmer> jam: Yes, exactly
[16:03] <gypsymauro> can bzr and svn work on the same working copy? :) I mean I've a project that is mantained by a guy that uses svn , but I want to keep the revision on my own too, can they live togheter?
[16:03] <jam> jelmer: are you including the time to install the specific language, etc for gettext?
[16:04] <jam> "import gettext" is pretty fast, but ISTR it costing more to actually set up translations, et.c
[16:04] <jam> gypsymauro: you can, but things get weird if you install bzr-svn and try to share a working tree
[16:04] <jelmer> jam: I'm not sure about that, this is the overhead on my system (which has LC_ALL=en_IE.UTF-8)
[16:04] <jam> (bzr-svn lets you checkout from subversion as though it were a bzr branch, etc)
[16:05] <jam> jelmer: my point is that it isn't just 'import gettext', I don't remember the specific invocation, though.
[16:06] <jelmer> jam: binding to a specific gettext domain, etc is included (but without any actual translations present)
[16:06] <gypsymauro> jam: oh no I want just let him to work on his project with svn , but I want to keep track of theproject on my own with bzr
[16:06] <jelmer> I'm not sure how worried we are about overhead for users without i18n enabled vs the overhead for users who do want i18n
[16:06] <jam> jelmer: you haven't actually said what the overhead is :)
[16:07] <jam> gypsymauro: jelmer is the man to talk to. Anyway, I need to go do family time. See you guys later.
[16:07] <jelmer> jam: have a nice evening :)
[16:07] <jelmer> jam: I said negligable, which can mean anything.. ;-)
[16:07] <jelmer> I'll get some more details
[16:07] <jelmer> gypsymauro: you should be able to just "bzr branch <svn-url>"
[16:09] <gypsymauro> jam:  tank you :D
[16:10] <gypsymauro> jelmer: ?
[16:10] <gypsymauro> I've already a working copy I want to create a new repository from it
[16:10] <jelmer> gypsymauro: you'd like to create a bzr branch from a svn repository?
[16:12] <jelmer> sorry, from a svn working copy?
[16:13] <gypsymauro> I'm not sure what u mean with "branch" , I mean that I want to version a svn working copy with bzr :)
[16:14] <gypsymauro> something like cvs add
[16:17] <jelmer> gypsymauro: so you'd just like to version the entire tree, without preserving any of the existing svn history?
[16:17] <jelmer> gypsymauro: in other words, the fact that it's a svn working copy isn't really relevant?
[16:18] <gypsymauro> jelmer: exactly
[16:19] <jelmer> gypsymauro: see the bzr in 5 minutes guide
[16:19] <jelmer> (http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html)
[16:19] <jelmer> basically - "bzr init; bzr add ."
[16:36] <gypsymauro> tank you jelmer
[16:51] <mgz> vanguard: I'm curious, why do you want to work on making the cli german rather than just qbzr/explorer?
[16:53] <mgz> most devs I know, even the ones with localised web browsers and so on, don't expect native command line tools.
[16:53] <mgz> and the gnu stuff pisses the hell out of my by guessing my prefered language incorrectly.
[16:56] <briandealwis> Does anybody know if I can do a bzr-svn dpush from a loom or a pipeline?  I'm looking to "hide" some (orthogonal) local patches required to get the tree in a running state on my machine.
[16:58] <jelmer> briandealwis: Somewhat; if you don't dpush the tip of the pipeline then you'll have to rebase the unpushed pipes after dpushing
[16:59] <briandealwis> Ok, makes sense.  Unfortunately I'm working against an old Subversion installation that won't be upgraded, and I want to avoid polluting with file-properties.
[16:59] <briandealwis> Thanks Jelmer
[17:05] <jelmer> does anybody else have trouble accessing e.g. https://code.launchpad.net/~maxb/bzr-builddeb/no-error-unknown-distro/+merge/56998 when logged in?
[17:06] <maxb> trouble?
[17:06] <jelmer> I get a 403
[17:06] <maxb> How odd
[17:07] <maxb> I can see it fine, anonymous, as ~maxb, and as ~maxb-autobuild
[17:07] <jelmer> it's fine now if I refresh but I can confirm it from two machines
[17:08] <jelmer> maxb: what about the MP linked from https://code.launchpad.net/~spiv/bzr-loom/plugin-init ?
[17:08] <maxb> fine
[17:08] <maxb> oh, the MP
[17:08] <maxb> the MP OOPSes
[17:08] <maxb> Shall we transfer to #launchpad-dev ?
[17:09] <jelmer> sure
[18:07] <dpm> hi jelmer, all set for your appdeveloperweek session later on?
[18:08] <jelmer> dpm: still working on some notes, but ready otherwise
[18:08] <dpm> jelmer, excellent. Thanks and good luck on the session!
[18:09] <jelmer> dpm: It's 4 hours from now right?
[18:10] <dpm> jelmer, yeah, at 23:00 for you, if you're on CEST -> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable
[18:11] <jelmer> dpm: Thanks
[18:11] <jelmer> dpm: Just double checking, it wouldn't have been the first time I missed up a tz :)
[18:11] <jelmer> *messed
[18:11] <dpm> jelmer, no worries, thank _you_ :)
[18:11] <Fidelix> Hello. I have some files in an Unix remote server, and I'd like it to be a central place for developers to commit. How can I do that?
[18:16] <LeoNerd> Most likely just something simple over ssh; either bzr+ssh, or sftp.
[18:17] <Fidelix> LeoNerd, was that for me?
[18:17] <LeoNerd> Yes
[18:17] <Fidelix> LeoNerd, how should I create the repository on the remote server?
[18:17] <LeoNerd> bzr push sftp://server/path/to/repo
[18:17] <LeoNerd> will create it if it doesn't exist
[18:17] <Fidelix> LeoNerd, but the files are on the server.
[18:18] <LeoNerd> Hmmm?
[18:18] <Fidelix> The files are already on the server.
[18:18] <Fidelix> The files are ONLY on the server.
[18:19] <LeoNerd> Just as bare files, not managed by bzr?
[18:19] <Fidelix> The project was started there. Using simple FTP.
[18:19] <Fidelix> LeoNerd, exactly.
[18:19] <LeoNerd> I see.. Well... bzr init; bzr add them, bzr commit  to create the first revision... now it's a branch.
[18:19] <LeoNerd> Others can access that branch, check it out, commit to it, etc.. by any of the usual mechanisms
[18:19] <LeoNerd> Though note that not all transports can update a remote checkout after a push
[18:20] <Fidelix> LeoNerd, what is a transport? A user?
[18:20] <Fidelix> *an user?
[18:20] <LeoNerd> file or sftp or bzr+ssh or whatever...
[18:20] <LeoNerd> URL schemes
[18:20] <Fidelix> Oh, ok. Can bzr+ssh do that?
[18:21] <LeoNerd> Hmm.. pass. Not sure offhand. Try it out.
[18:21] <LeoNerd> There's a warning message if it doesn't.
[18:21] <Fidelix> OK. Thanks.
[18:21] <Fidelix> LeoNerd, what is "Lightweight Checkout" ?
[18:22] <LeoNerd> A checkout that doesn't haev a branch.
[18:22] <LeoNerd> Think like CVS checkouts
[18:22] <Fidelix> Alright. That's what I need. Thank you very much
[18:23] <Fidelix> Authentication (publickey) successful!
[18:23] <Fidelix> Secsh channel 1 opened.
[18:23] <Fidelix> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
[18:28] <mgz> Fidelix: paste the full traceback somewhere? you possibly have some filenames that are not utf-8, or a misconfigured locale.
[18:28] <Fidelix> mgz, I closed the window, opened again, and it worked fine.
[18:29] <Fidelix> I'm using bzr explorer
[18:29] <mgz> I'm curious about what the actual error was, can you find it in .bzr.log and put it somewhere for me to see?
[18:29] <Fidelix> I believe it is this bug: https://bugs.launchpad.net/bzr-explorer/+bug/599860
[18:29] <Fidelix> yes, I'll paste.
[18:30] <Fidelix> mgz, where is bzr.log ?
[18:30] <mgz> I think explorer will tell you where to find it under 'about'.
[18:30] <mgz> otherwise run `bzr qversion` from the command line.
[18:34] <mgz> hm, not in about, can do Bazaar/All Commands... and type 'version' in the 'Command' drop down and hit okay, then scroll the output so you can see where the log file is.
[18:35] <Fidelix> mgz, I hope you don't mind... I removed some personal data. http://pastebin.com/H8vaabTX
[18:36] <mgz> that's fine.
[18:36] <mgz> actually, looks like the bug I am looking into *just this second* which is bug 686735
[18:37] <mgz> what's your qbzr version? that's something the explorer 'about' will tell you.
[18:38] <mgz> finally, in the parts you starred out, were there any non-ascii characters or % encoded URL bits?
[18:40] <Fidelix> mgz, http://felipefidelix.com/f/System_Information-2011-04-13_14.39.59.png
[18:41] <Fidelix> Not on the server, but on my computer, maybe... IF # is utf-8, which I don't think it is...
[18:43] <mgz> sorry, that's the other dialoge box, I wanted the info in Bazaar Explorer's Help/About Bazaar Explorer specifically the line that says for me:
[18:43] <mgz> QBzr 0.20.0.dev, ....
[18:44] <Fidelix> http://felipefidelix.com/f/About_Bazaar_Explorer-2011-04-13_14.43.57.png
[18:44] <mgz> The # should be fine indeed, just needed to check
[18:44] <mgz> thanks Fidelix.
[18:44] <Fidelix> No, thank you!
[18:45] <mgz> feel free to +metoo that bug I linked and I'll mark it confirmed.
[18:46] <Fidelix> Alright
[18:50] <mgz> wait, I... edited the wrong bug earlier >_<
[19:03] <TJNII_work_> I want to set up bzr to run a shell script on post_commit.  I'm looking at the docs, but I don't understand the naming system in .bzr/hooks.  Where should a script like this go?
[19:07] <TJNII_work_> The hooks page talks about "types": branch and server, but doesn't clearly state what the differences are, and the hooks help uses post_commit whereas the hooks page uses post-commit.
[19:09] <jelmer> TJNII_work_: the hooks are installed by bzr plugins, they're not shell scripts
[19:10] <jelmer> where do you see a reference to .bzr/hooks ?
[19:13] <TJNII_work_> wiki.bazaar.canonical.com/BzrHooks
[19:14] <TJNII_work_> under "Specify hooks in directories"
[19:14] <TJNII_work_> So I can't just have bazaar run a shell script on post_commit?  That is no longer supported?
[19:15] <TJNII_work_> I need soemthing server side.  Requiring all clients to install a plugin is unacceptable.
[19:15] <TJNII_work_> I was under the impression I could install a hook in the server .bzr direcroty and the "smart" protocols would activate it.
[19:22] <mDuff> TJNII_work_, I haven't kept up with bzr very closely, but I wasn't aware that server-side hooks were ever supported without a PQM.
[19:22] <mDuff> TJNII_work_, (...speaking of which, have you *considered* a PQM?)
[19:23] <mDuff> ...hmm. Actually, looking at that page, it looks like they are. Nifty.
[19:24] <mDuff> (supported since 1.6, apparently)
[19:24] <TJNII_work_> What is a PQM?
[19:25] <mDuff> a patch queue manager, a central daemon which receives and handles please-merge-my-branch requests (typically with configuration to support running unit tests, or voting on whether to accept the patch, or the like first)
[19:27] <mDuff> btw, http://doc.bazaar.canonical.com/latest/en/user-guide/hooks.html and http://doc.bazaar.canonical.com/latest/en/user-reference/hooks-help.html look relevant (the latter discusses exactly when hooks are run on the server)
[19:27] <TJNII_work_> I see.
[19:27] <TJNII_work_> Where is that documented?
[19:27] <TJNII_work_> Is is not in the users guide
[19:27] <TJNII_work_> The admin guide has a heading for it, but no content.
[19:28] <mDuff> https://launchpad.net/pqm is one particular PQM instance
[19:28] <TJNII_work_> Yea, I'm looking at those pages, but they don't clearly define what pathing bazaar uses
[19:29] <TJNII_work_> Would it be .bzr/hooks/branch/post_commit?  Or .bzr/hooks/branch/post-commit?  or .bzr/hooks/server/post_commit?  I don't know.
[19:30] <mDuff> Docs clearly specify "the plugins subdirectory of your configuration directory" should have a Python plugin that installs your hook.
[19:31] <mDuff> ...so you're writing Python code rather than a shell script (even if it's Python code that starts a shell script)
[19:32] <mDuff> ...in the initial BzrHooks wiki page you pointed at, support for shell scripts is listed as a "desired improvement", not a feature.
[19:35] <TJNII_work_> Oh, I see.  So even though the docs clearly say "In addition to plugins installing hooks, users can provide shell scripts to run when hooks are triggered. The scripts to run for hook xxx are specified in the following directories: " it doesn't actually do that.  Which is kinda documented in the "Requested Improvements (Dec 2007)" block.
[19:35] <mDuff> ...well, you'd want someone who actually knows the code (or is at least willing to grep it) to give a _conclusive_ answer
[19:38] <mDuff> ...but having a behavior that's documented only in the wiki but not the manual isn't exactly confidence-inspiring.
[19:38] <mDuff> oh, that's under "ideas"
[19:39] <mDuff> "Configuration Ideas"
[19:39] <mDuff> ...so yup, that would clearly look to be brainstorming for future implementation.
[19:43] <lifeless> TJNII_work_: there is a plugin that will run shell scripts of your choice on actions
[19:43] <lifeless> TJNII_work_: you can install that server side
[19:43] <lifeless> TJNII_work_: as long as folk use bzr:// to push it will run.
[19:44] <lifeless> I don't remember its hane, sorry - but jelmer may.
[19:44] <TJNII_work_> lifeless: Where?  I'm looking for it and not finding it.  If you know the URL that would help greatly
[19:44] <TJNII_work_> The plugins page lists shell-hooks, but that's dead
[19:44] <TJNII_work_> Nothing on the site
[19:45] <lifeless> thats what I was thinking of I suspect
[19:45] <TJNII_work_> Yea, there's a trunk directory from 2008 that is empty.  No code.
[19:45] <TJNII_work_> So, what would the python script / plugin need to be named?  post_commit_hook.py?
[19:47] <mDuff> TJNII, ...the plugin's name doesn't matter -- it's the contents that do the registrations
[19:48] <mDuff> TJNII, umm, you say "empty" -- it's a bzr repo
[19:48]  * TJNII_work_ smacks his forehead
[19:48] <TJNII_work_> duh.
[20:35] <maxb> OK, this is not so bad. All plugins in ~bzr/beta install and at least load except bzrtools bzr-pipeline and bzr-svn
[20:36] <maxb> abentley: What stage in the 2.4 beta process are you likely to release compatible versions of bzrtools and bzr-pipeline?
[20:37] <abentley> maxb: probably when bzr 2.4.0 goes gold.
[20:38] <maxb> ah. I should probably think about snapshot .debs then
[20:39] <abentley> maxb: currently, these are both slow-moving projects whose trunk declares compatibility.
[20:41] <abentley> maxb: The whole versioning thing is a mess, as we recently discussed on the list.  But I would expect the last release of bzrtools to work with beta versions of bzr.  It doesn't?
[20:43] <maxb> Oh!
[20:43] <maxb> It looks like we may have mis-transliterated its internal API versioning into debian package dependencies
[20:45] <abentley> maxb: Yeah, it wouldn't be compatible with final bzr releases, but it shouldn't complain about betas.
[20:55] <maxb> Ah....
[20:55] <maxb> bzrtools special-cases 'dev' but not 'beta'
[20:55] <maxb> So it will work, but it will warn
[20:57] <abentley> maxb: Oh.  I was assuming that betas were dev, since they're not releases.
[20:58] <maxb> They're beta releases :-)
[20:58] <maxb> Perhaps != 'final' would be best?
[21:00] <abentley> maxb: perhaps.  API changes can still happen in the betas, right?
[21:01] <maxb> IIRC we pick a specific beta as the start of API freeze? Usually the last beta?
[21:02] <maxb> (so, yes)
[21:05] <abentley> maxb: It doesn't make sense for bzrtools to claim compatibility with 2.4 until it the final bzr 2.4 API is available, so there ought to be a way for bzrtools to work with betas.
[21:05] <mDuff> -
[21:05] <maxb> Right - so, treat 'beta' and 'dev' version classes the same
[21:06] <abentley> maxb: okay, I'll look into revamping the versioning of pipeline and bzrtools so that they work with the subsequent betas.
[21:07] <maxb> Great!
[21:07] <maxb> bzrtools works now, except that it claims that bzrtools 2.4 should be available if you run it against a beta release
[21:10] <abentley> maxb: Yes.  For now, I guess snapshots are the way to go.
[21:58] <orospakr> Hey, can I delete tags from a repository (not a branch)?
[21:58] <orospakr> for that matter, how can I get the equivalent of "bzr log" from a repository?
[21:59] <fullermd> Oh, removing tags from a repository is easy.  You just...  do nothing   :).  Tags are in branches, not repos.
[22:01] <orospakr> ah, I found another way around my problem. nvm.