[00:00] <lifeless> ok
[00:00] <lifeless> sudo dpkg -P python-paste
[00:01] <lifeless> or in your favourite front end, choose 'purge'
[00:02] <beuno> lifeless, launchpad-dependencies
[00:02] <beuno>  is yelling at me when I try to do that
[00:02] <beuno> -f?
[00:02] <lifeless> yes
[00:04] <beuno> lifeless, done
[00:04] <lifeless> now install it
[00:05] <beuno> lifeless, no luck
[00:06] <beuno> ImportError: No module named paste
[00:06] <lifeless> dpkg -L python-paste
[00:07] <beuno> lifeless, https://pastebin.canonical.com/19126/ is all I did
[00:07] <beuno> lifeless, https://pastebin.canonical.com/19127/ for the above command
[00:11] <lifeless> uh
[00:12] <lifeless> have I mentioned I hate eggs
[00:13] <lifeless> you'll need to check that the namespace package contents are correct, and dig into the egg info
[00:13] <beuno> ew
[00:14] <lifeless> does zc.buildout use eggs? if so, chalk another ugh up for it
[00:14] <beuno> it does
[00:14] <beuno> which is why I suspect that installing LP first is to blame
[00:15] <beuno> beuno@beuno-laptop:~$ cat /usr/share/python-support/python-paste/Paste-1.7.1.egg-info/namespace_packages.txt
[00:15] <beuno> paste
[00:16] <lifeless> the pth files is the namespace path info
[00:17] <beuno> beuno@beuno-laptop:~$ cat /usr/lib/python-support/python-paste/python2.6/Paste-1.7.1-py2.6-nspkg.pth
[00:17] <beuno> import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('paste',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m = not ie and sys.modules.setdefault('paste',new.module('paste')); mp = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
[00:18] <mwhudson> wow that's *beautiful*
[00:18] <mwhudson> (mine is the same)
[00:18] <beuno> looks like perl
[00:18] <mwhudson> "the problem with setuptools is that people use it"
[00:19] <mwhudson> (unlike other pje creations, which managed to inspire saner alternatives before they took off in their own right)
[00:20] <lifeless> so
[00:20] <lifeless> check your import hook list too
[00:20] <lifeless> uhm
[00:20] <lifeless> and mwhudson - is python-support in your python path?
[00:21] <lifeless> (fooding and picking up mail from the post office, be 15)
[00:21] <mwhudson> lifeless: yes
[00:21] <cdecarlo_> hi, kinda embarassed to ask, but I grabbed bzr-gtk from apt (ubuntu) but I'm unser of how to run the gui?
[00:21] <lifeless> beuno: one thing you could try is to add python-support to your path by hand
[00:22] <lifeless> beuno: and see if that works, if so that would be useful data
[00:22] <beuno> lifeless, ok, I'll ask mwhudson for the command or from you when you get back  :)
[00:22] <mwhudson> lifeless: python-support is on beuno's path
[00:22] <beuno> cdecarlo_, you have new commands now. Try:  bzr help commands
[00:23] <cdecarlo_> oh, tricky
[00:23] <mwhudson> lifeless: the problem is that /var/lib/python-support/python2.6/paste/__init__.py doesn't exist
[00:23] <mwhudson> (afaics anyway)
[00:23] <beuno> mwhudson, does it exist for you?
[00:24] <mwhudson> beuno: yes
[00:24] <mwhudson> (it's an empty file)
[00:24] <beuno> I can try creating it, but it feels wrong
[00:24] <mwhudson> yes yes it does
[00:25] <mwhudson> my limited understanding is that something in python-support is supposed to create these files after installation
[00:26] <beuno> mwhudson, creating the __init__.py file fixes the import problem
[00:27] <lifeless> mwhudson: it's not in the package forme
[00:27] <beuno> I've removed it so we can figure out what's breaking it though
[00:27] <mwhudson> lifeless: me neither
[00:27] <mwhudson> if you mean what i think you mean
[00:27] <mwhudson> mwh@grond:dont-test-self-stacking$ dpkg -S /var/lib/python-support/python2.6/paste/__init__.py
[00:27] <mwhudson> dpkg: /var/lib/python-support/python2.6/paste/__init__.py not found.
[00:29] <lifeless> its likely meant to interpret the namespace-packages.txt file or something
[00:29] <lifeless> I couldn't find quick docs on that
[00:29] <lifeless> really -> post, now
[00:30] <mwhudson> beuno: what version of the python-paste package do you have installed?
[00:30]  * mwhudson stares at a debian/rules file
[00:31] <beuno> mwhudson, apt-cache says 1.7.1-1ubuntu1
[00:31] <mwhudson> beuno: and python-support?
[00:32] <beuno> mwhudson, 0.8.7ubuntu5~launchpad
[00:33] <mwhudson> same as me
[00:33] <mwhudson> wtf is going on
[00:33] <beuno> gat
[00:33] <beuno> garrrr
[00:34] <beuno> I'd blame myself, but it's a fresh install
[00:35] <beuno> the reason I did a fresh install is to avoid these things  :)
[00:35] <lifeless> look at update-python-modules
[00:35] <lifeless> def post_change_stuff
[00:43] <mwhudson> beuno: ok
[00:43] <mwhudson> sudo update-python-modules  python-paste
[00:44] <mwhudson> creates that file for me
[00:44] <mwhudson> i see lifeless is chasing the same tails as me :)
[00:44] <mwhudson> however
[00:44] <mwhudson> that command is in postinst
[00:44] <beuno> mwhudson, same here
[00:45] <mwhudson> so if removing and installing the package doesn't create the file, something odd is going on
[00:45] <mwhudson> (well, it's in postinst if i debuild here...)
[00:50] <mwhudson> /usr/sbin/update-python-modules is not the finest example of python coding i have ever seen
[01:00] <SamB> mwhudson: what might be?
[01:05] <poolie> hello beuno, all
[01:06] <beuno> heya poolie
[01:09] <lifeless> back
[01:10] <thumper> poolie: got a few minutes?
[01:13] <poolie> thumper: for you, always
[01:13] <thumper> :)
[01:16] <poolie> lifeless: what do you think of https://pastebin.canonical.com/19067/
[01:19] <poolie> nm i added the traceback to bug 390563
[01:34] <poolie> beuno, how's 2a going for you?
[01:35] <james_w> I've had a few instances of AbsentContentFactory related exceptions
[01:35] <james_w> I believe that is the bug that is fixed in 1.16.1 though
[01:35] <poolie> james_w: hi! robert says, in 390563, that we haven't closed all cases
[01:35] <poolie> but most seem to be fixed
[01:36] <james_w> would you like me to open a new bug report with the backtrace I have?
[01:37] <james_w> it's one in autopack
[01:37] <poolie> hm
[01:37] <lifeless> james_w: upgrade your bzr
[01:38] <james_w> *I* can't
[01:38] <lifeless> poolie: we have several bugs with the same bottom line but different intermediate stack traces
[01:38] <james_w> if it's a released version then a friendly sysadmin will
[01:38] <lifeless> james_w: its fixed in newer bzr
[01:38] <james_w> great, good to know
[01:38] <lifeless> autopack failing in 2a is fixed in dev, nightlies and 1.16.1
[01:41] <lifeless> james_w: as a workaround, you can pack the repo that is failing
[01:41] <lifeless> james_w: that will defer autopacking
[01:42] <james_w> I've only hit it twice so far, so implementing a workaround will be more work than just retrying the import when a fixed bzr is available on that machine
[01:42] <james_w> thanks for the tip though
[01:47] <beuno> poolie, doing great, flawless up to now. All ~120 branches converted, and just one very odd problem, which jam helped me resolve, and that a bug in bzr 0.13 or so introduced
[01:48] <beuno> speed has increased so much I don't even recognize the process  :)
[01:49] <beuno> space savings aren't something to write home about in my case
[02:21]  * SamB wonders how jelmer expects people to check out dulwich from git ...
[02:21] <SamB> ... and how he pushes to it
[02:21] <mwhudson> he pushes to it with bzr-git of course
[02:22] <SamB> that's funny given what the launchpad page for bzr-git says: https://launchpad.net/bzr-git
[02:23] <mwhudson> SamB: he uses dpush
[02:23] <SamB> mwhudson: oh, yuck :-(
[02:24] <SamB> what does the d even stand for?
[02:24] <SamB> ... and why can't he at least push a repository that git can checkout?
[02:24] <mwhudson> i guess you should ask him :)
[02:25] <SamB> but, but, he's not here :-(
[02:25] <mwhudson> gasp
[02:30] <SamB> or maybe he fixed that
[02:31] <spiv> The d stands for destructive/devilish/deviant or something ;)
[02:31] <RAOF> SamB: git clone  git://git.samba.org/jelmer/dulwich.git works fine here?
[02:31] <SamB> RAOF: yeah, he must have fixed it
[02:31] <SamB> or git has changed
[02:31] <SamB> one of those
[02:32] <SamB> used to have a .git directory in there that git really didn't like
[03:28] <poolie> spiv, are you aroundL how's stuff?
[03:36]  * igc lunch
[04:00] <KhaZ> Hey!  My tree is out of date, and if I do bzr update, it requires a merge.  Fine so far, except it's trying to rename a directory that has OS proteciton on it.  Is there a way I can tell bzr to update without moving the directory?
[04:02] <lifeless> KhaZ: no; its moving the directory because it got replaced on trunk
[04:06] <KhaZ> lifeless: Nuts.  I suppose that makes sense, but I was hoping I could have a work around so I could merge them manually in the meantime.
[04:06] <lifeless> KhaZ: why does it have os protection
[04:06] <lifeless> SamB: ping
[04:06] <SamB> yeah?
[04:06] <lifeless> SamB: bug 393694 is odd
[04:06] <lifeless> the code looks correct to me
[04:06] <lifeless> in 1.16
[04:06] <KhaZ> lifeless: Well, I'm probably a dolt for doing it, but I version my home directory.  On eof the directories was 'Documents', which MacOS protects.
[04:07] <KhaZ> For a work around I'll repair it on my Linux box by moving it to a data/Documents directory or some such, I suppose.
[04:07] <SamB> lifeless: okay, well, I'm using version "1.16.1-1"
[04:07] <lifeless> SamB: same same
[04:08] <SamB> it could be a bug in Debian, I guess ...
[04:09] <lifeless> possibly
[04:09] <lifeless> I've put a question in the bug tracker
[04:09] <SamB> is there a way to check that the .pyc and .py match?
[04:10] <lifeless> no
[04:10] <lifeless> you can remove the pyc
[04:10] <lifeless> or move it out of the way
[04:10] <SamB> I guess I'll sudo that, then
[04:11] <lifeless> I can't see any obvious leads to pull on
[04:12] <SamB> ... and reinstall the package
[04:13] <lifeless> so I'm limited to suggesting things to do to debug
[04:13] <lifeless> as I don't see it myself
[04:14] <SamB> is there a way to get a bzr to use cgitb?
[04:14] <poolie> SamB: in loggerhead or otherwise?
[04:14] <mwhudson> what the crap, why is "import bisect" in btree_index importing the bisect plugin?
[04:14] <poolie> i think the answer is no, but it's probably a trivial patch
[04:15] <poolie> mwhudson: python relative import fail
[04:15] <SamB> otherwise
[04:15] <poolie> mwhudson: that's only a guess
[04:15] <poolie> samb, actually i'd love a patch that would put cgitb-like data into the traceback
[04:15] <mwhudson> poolie: maybe if you ran it from within /home/naesten/.bazaar/plugins
[04:15] <poolie> would improve our bug reports
[04:15] <mwhudson> maybe
[04:15] <poolie> mwhudson: yeah
[04:15] <poolie> there's a bug that we should strip . off the path
[04:16] <SamB> poolie: you just use cgitb.enable(format='text'), don't you?
[04:16] <mwhudson> SamB: can you run python -vv /usr/bin/bzr rocks and pastebin the result?
[04:16] <mwhudson> SamB: there will be quite a lot of output
[04:16] <SamB> mwhudson: figured
[04:16] <lifeless> mwhudson: oh well spotted
[04:16] <SamB> I already tried running python -v /usr/bin/bzr ;-)
[04:17] <lifeless> SamB: is there a bisect directory in /usr/lib/python2.5/site-packages/bzrlib/ ?
[04:17] <mwhudson> it's a circular import
[04:18] <SamB> lifeless: nope
[04:18] <poolie> igc, if/when you're back give me a call?
[04:18] <lifeless> SamB: is there a ./bisect?
[04:18] <lifeless> directory that is
[04:19] <SamB> lifeless: oh, yeah
[04:19] <SamB> there is
[04:19] <lifeless> SamB: and is there a __init__.py in the current directory?
[04:19] <SamB> ... no
[04:19] <lifeless> ok
[04:19] <lifeless> so '.' is in your python path
[04:20] <SamB> lifeless: it often is
[04:20] <lifeless> its causing the problem
[04:20] <SamB> maybe bzr should take it out?
[04:20] <lifeless> I don't think thats a good idea
[04:20] <lifeless> because its needed sometimes too
[04:21] <SamB> when?
[04:21] <lifeless> it would be like setting PATH in an application; bad idea
[04:21] <SamB> I mean, when bzr doesn't detect that it's running out of it's source tree
[04:22] <SamB> lifeless: isn't it more like slightly altering LT_LIBRARY_PATH in an application?
[04:22] <SamB> er.
[04:22] <SamB> LD_
[04:23] <SamB> okay, so next time I get wierd errors when trying to branch a new plugin into my plugin directory, I guess I should try doing something in another directory ?
[04:24] <lifeless> yah. also take . out of your path :)
[04:24] <lifeless> its a security problem
[04:24] <lifeless> for vim and other programs too
[04:24] <SamB> *I* don't have it in my PYTHONPATH
[04:24] <SamB> % echo $PYTHONPATH
[04:24] <SamB> /home/naesten/hacking/Twisted:/home/naesten/hacking/Nevow:/home/naesten/lib/python:
[04:24] <lifeless> it is
[04:24] <lifeless> '' == .
[04:24] <SamB> lifeless: eh?
[04:25] <lifeless> its the last element in your path
[04:25] <SamB> yeah, I could have sworn python(1) said something different though
[04:25] <lifeless> >>> "/home/naesten/hacking/Twisted:/home/naesten/hacking/Nevow:/home/naesten/lib/python:".split(':')
[04:25] <lifeless> ['/home/naesten/hacking/Twisted', '/home/naesten/hacking/Nevow', '/home/naesten/lib/python', '']
[04:25] <mwhudson> oh heh
[04:26] <SamB> lifeless: where is it documented that an empty element does that?
[04:26] <lifeless> I doubt that it is
[04:26] <lifeless> in the context of PYTHONPATH
[04:27] <lifeless> however, listdir and other os functions treat anything not starting with '/' as a relative path
[04:27] <lifeless> and listdir('') == listdir('.')
[04:27] <SamB> crazy shit
[04:28] <SamB> maybe bzr should at least warn if you run it like that -- or at least warn about it when it does crash?
[04:29] <SamB> oh
[04:29] <SamB> I wrote "PYTHONPATH=~/hacking/Twisted:~/hacking/Nevow:~/lib/python:$PYTHONPATH" in my ~/.zprofile
[04:29] <SamB> what do I really want ...
[04:30] <lifeless> if [ -z "$PYTHONPATH" ]; ...
[04:32] <lifeless> ok, time for iter_changes loving
[04:33] <SamB> lifeless: thanks for the help even if it was mostly me being stupid ;-)
[04:35]  * SamB supposes this is why they added something for explicitly relative/absolute imports?
[04:35] <lifeless> part of it
[04:35] <lifeless> a bigger reason is that namespacing is horribly broken if you can't say 'start at the root'
[04:35] <SamB> well, yeah
[04:35] <spiv> poolie: hey
[04:36] <spiv> poolie: it's going pretty well, I'm just putting together the network bits.
[04:36] <poolie> oh ok, great
[04:37] <SamB> so ... I guess you won't be needing this -vv output?
[04:37] <poolie> is there already a bug for socket.error giving a traceback?
[04:37] <lifeless> nope, no need
[04:37] <mwhudson> SamB: yeah
[04:37] <poolie> i thought there would be a heavily-duped one but i can't find it
[04:37] <mwhudson> as in "you're right, no need"
[04:39] <spiv> poolie: in what context?  I don't know of any outstanding bugs with socket.error tracebacks (although I can believe they exist)
[04:39] <poolie> like bug 326485
[04:39] <spiv> I fixed one at UDS.
[04:39] <poolie> launchpad can't search for "socket.error" which sucks a bit
[04:40] <poolie> i don't think we treat it as an environment error but we probably should
[04:40] <SamB> poolie: and google didn't index it yet?
[04:40] <lifeless> poolie: socket error (just skip the dot)
[04:40] <spiv> Hmm, that particular example is arguably a bug in our ftp.py
[04:41] <poolie> lifeless: it gives me bugs containing {socket || error} which is a lot of them
[04:41] <SamB> spiv: a bug report can show the presence of more than one bug simultaneously, yes ;-)
[04:41] <spiv> I'd be a bit wary of a catch-all for treating socket.error as normal and not a bug.
[04:42] <SamB> https://launchpad.net/+search?field.text="socket+error"
[04:42] <lifeless> poolie: oh uhm.
[04:42] <SamB> poolie: try that ?
[04:43]  * SamB almost sent "trie that" ;-)
[04:43] <SamB> incidentally, the title for that URL is really awful
[04:43] <SamB> Pages matching ""socket error"" in Launchpad
[04:43] <spiv> SamB: that's why they're called double quotes!
[04:44] <SamB> spiv: ... noo, it isn't!
[04:46] <poolie> SamB: gives an error
[04:46] <SamB> there ought to be a "bzr sucks" command, which would just raise some sort of error
[04:46] <SamB> poolie: what the?
[04:47] <SamB> poolie: are you using edge or something, maybe?
[04:47] <spiv> SamB: "bzr alias sucks=rocks"
[04:47] <poolie> spiv, can you think of a good counterexample?
[04:47] <poolie> case 393713 btw
[04:47] <SamB> spiv: but bzr rocks doesn't raise an error
[04:48] <spiv> SamB: true.  You could always alias it to something buggy I guess.
[04:48] <SamB> spiv: I was thinking it should be there for testing the bug-report thingy
[04:49] <spiv> poolie: if a socket.error ever escapes the HPSS client code that would be a bug, although not necessarily a serious one.
[04:51] <spiv> poolie: Also potentially many different internal operations might use sockets, e.g. if you make a commit via bzr:// (or to a lp: URL, which is resolved via XML-RPC), and you also have bzr-email make an SMTP on commit and another plugin that uses TCP somehow to kick off a buildbot, or a plugin to tell LP to update its mirror.
[04:51] <poolie> spiv, i guess you could say that each transport or other network-using code should catch it
[04:51] <poolie> and translate it
[04:52] <poolie> spiv, yeah, i know
[04:52] <spiv> poolie: so the question is how to report those different situations to the user
[04:52] <poolie> well
[04:52] <poolie> i would agree you don't just want a mysterious "connection refused" with nothing more
[04:52] <spiv> A general "bzr: socket error: connection reset by peer" isn't going to help the user a whole lot.
[04:52] <poolie> hopefully you can at least say what host it was
[04:52] <spiv> Right.
[04:52] <poolie> right
[04:52] <poolie> otoh a traceback's not much better
[04:52] <spiv> Agreed.
[04:53] <spiv> The main issue is to give a good error.  I'm not sure that socket.error can give you enough details to report a host name or the particular operation that failed.
[04:55] <poolie> i think in general that's going to rely on transport-level or similar code decorating it
[04:55] <poolie> if it comes from eg a write() call, python's probably not smart enough to remember the host name
[04:55] <poolie> associated with that fd
[04:55] <spiv> So I think we need to be catching it at the point it happens and turning it into something more useful for the user, e.g. "FTP connection closed during PASV".
[04:56]  * mwhudson just merged pyflakes trunk into lp:~mwhudson/pyflakes/support-lazy-imports, if anyone is interested
[04:56] <spiv> Yeah, I think for socket-using transports the transport code needs to decorate it.  Similarly for plugins etc that use SMTP or XML-RPC.
[04:56] <spiv> mwhudson: ooh, ta
[04:56] <mwhudson> (actual conflicts this time!)
[04:57] <spiv> It's a bit hard to know exactly which information is most relevant to tell the user when an error happens.
[04:58] <spiv> But the type of socket error (connection reset or whatever), hostname/port, and some sort of high-level description of what bzr was attempting to do (e.g. "retrieve file from $URL") is probably achievable and good enough.
[04:59] <spiv> poolie: I can add this opinion to #393713 if you like
[04:59] <poolie> yeah
[04:59] <poolie> just paste the irc log
[05:00] <spiv> Ok.
[05:08] <fullermd> So, am I just special, or is the wiki really broken for everyone else since the openid change?
[05:13] <bialix> wfm
[05:30] <fullermd> Well, it's nice to be special I guess...
[06:39] <GungaJin> I just merged from trunk to a branch.. and I need to rebase to a previous revision of trunk in the branch.. how can I do this?
[06:42] <spiv> GungaJin: there's a bzr-rebase plugin, but why do you "need to rebase"?  Rebasing is generally a means to an end, not an end in itself.
[06:43] <GungaJin> because I merge from trunk a revision that doesn't compile... so I need to reverse that or to rebase.
[06:43] <poolie> fullermd: wfm too, can you be more specific?
[06:43] <thumper> uncommit?
[06:44] <GungaJin> but I committed already.
[06:44] <dash> GungaJin: that's what 'bzr uncommit' is for.
[06:44] <poolie> spiv, do you want a catchup call?
[06:45] <poolie> well, i do anyhow :)
[06:47] <fullermd> poolie: Well, I can't set anything in my UserPreferences, since it just keeps repeating "This email already belongs to somebody else."
[06:47] <fullermd> The time zone is wrong too, but it's grayed out so I can't even attempt changing it anyway.
[06:47] <lifeless> fullermd: please open a question at https://launchpad.net/launchpad
[06:48] <lifeless> fullermd: that will get sysadmin attention
[06:48] <lifeless> fullermd: an/or try removing your moin cookie and logging in fresh
[06:49] <poolie> fullermd: your tz is supposed to come in openid from launchpad
[06:50] <fullermd> Yes, but it comes in as -0600.  That's wrong; I'm on DST so it's -0500 now.
[06:51] <fullermd> lifeless: Does it really have anything to do with LP?  I thought LP just provided the initial auth; all the Prefs in the wiki should just be moin-internal, no?
[06:51] <lifeless> fullermd: 'that will get sysadmin attention'
[06:51] <lifeless> fullermd: but try the cookie thing first
[06:52] <fullermd> Already did, no change.
[06:52] <GungaJin> what a mess...
[06:52] <lifeless> then its possibly/presumably a side effect of the moin openid plugin
[06:52] <lifeless> GungaJin: what do you mean?
[06:53] <GungaJin> I mean something is messed up in my project..
[06:53] <poolie> fullermd: it's using a moin plugin to take at least some settings, including tz, from the openid thingum
[06:54] <fullermd> So saving prefs actually works for everyone else?  :(
[06:54] <lifeless> haven't tried
[06:57] <spiv> poolie: sure, call me in 5?
[07:09] <vila> hi all
[07:11] <vila> fullermd: Didn't your mother tell you about going to bed early ? Now you find even wikis can't understand your tz ? And you wonder ?
[07:11] <spm> hey vila
[07:11] <vila> hi spm !
[07:12] <spm> vila: I must say it's good to be back in a ... more reasonable TZ ;-)
[07:12] <vila> :-D
[07:13] <fullermd> vila: She might've, I dunno.  I was sleeping late that day   :p
[07:15] <spiv> poolie: was that you calling?  All I got was a bit of crackling then silence.
[07:18] <vila> spiv: ghosts do that these days, but poolie...
[08:14] <thekorn> hi, I accidentially removed a file at revno 10, I'm now at revno 20, how can I get this removed file back
[08:14] <thekorn> with all its history
[08:24] <spiv> thekorn: "bzr revert -r9 path/of/file"
[08:26] <thekorn> spiv: ah, ok, thanks, and than bzr commit path/to/file and revert the other changes?
[08:26] <thekorn> that's easy
[08:28] <thekorn> oh, nevermind
[08:28] <thekorn> ignore my last lines
[08:28] <thekorn> thanks again
[08:28] <spiv> thekorn: you're welcome :)
[08:49] <lifeless> thekorn: yes, you do need to commit the revert
[08:58] <thekorn> lifeless: right, that's what I did, I was a bit confused because I did not know it is possible to revert only a certain file
[09:13]  * igc dinner
[09:48] <jml> bzr alias upll="pull"
[09:52] <Peng_> More important is aliasing zbr to bzr. :D
[09:53] <Peng_> And /em to /me...
[09:55] <poolie> hello vila, Peng
[09:56] <Peng_> Good morning. :)
[09:58] <vila> hi poolie
[10:06] <vila> poolie: we both fixed the yY/nN FIXME in get_boolean but I wonder if mine isn't too broad...
[10:07] <vila> I added the ability to use y/n Yes/No On/Off 1/0 for booleans in config files, but allowing the latter for get_boolean (which add y/n to the prompt) may not be such a good idea in retrospect... thoughts ?
[10:10] <poolie> vila, both fixed in the sense of both merged or just both had patches?
[10:10] <poolie> i just wanted to merge the patch attached to that bug
[10:10] <vila> poolie: you merged, I didn't submit my patch yet
[10:10] <Peng_> Is it just me, or did a blog post called "Scalability benchmarking: packs vs 2a on OpenOffice.org" semi-appear on the planet?
[10:15] <poolie> Peng_: why 'semi'
[10:22] <poolie> vila, good stuff on the strict push etc
[10:22] <vila> poolie: I need to talk with jam about his concern, I don't quite understand :-/
[10:23] <vila> poolie: there is another patch waiting for a review about send --strict :-}
[10:24] <vila> I'm waiting for both of them to land before submitting the boolean stuff and the tree.has_changes() asked during review of the first attempt to fix push --strict
[10:25] <vila> poolie: by the way, I've switched to using mixins in the tests, you were right, that's clearer :-)
[10:27] <Peng_> poolie: It appeared in the feed, but without an URL. It's not displayed on the website.
[10:27] <Peng_> poolie: Never mind, now it's there.
[10:27] <Peng_> Still doesn't have an URL, though.
[10:28] <Peng_> igc: ping
[10:31] <visik7> a developer A has a local branch
[10:31] <visik7> how can I get it ?
[10:34]  * vila lunch
[10:42] <igc> hi Peng_
[12:21] <Peng_> igc: http://planet.bazaar-vcs.org/ lists a blog post by you, "Scalability benchmarking: packs vs 2a on OpenOffice.org", but there's no link to the rest of the post.
[13:20] <Peng_> Oh, I just found a link to igc's blog post on the mailing list. I had checked that blog once, but only before the post appeared.
[13:31] <lifeless> \o/ http://bazaar.launchpad.net/~domas-mituzas/%2Bjunk/uncache/annotate/head%3A/uncache.c for testing cold cache
[14:16] <jam> lifeless: so that lets you test cold cache without destroying everything?
[14:16] <jam> nice
[14:16] <jam> though figuring out what exactly needs to be uncached is probably a little tricky
[14:19] <Peng_> uncache looks slightly scary.
[15:09] <bialix> jam: good day
[15:10] <bialix> jam: I have question about TBZR version you're using to bundle into installer
[15:10] <bialix> jam: are you using tbzr trunk?
[15:10] <jam> bialix: since AFAIK tbzr has never had a release, yes
[15:10] <jam> though I think I need to manually update it
[15:10] <jam> bialix: I was just sending a response to your bug comment
[15:10] <bialix> I've read your build_release.py script
[15:11] <jam> and building a 1.16.1-2 release
[15:11] <jam> with the latest python pyqt and tbzr
[15:11] <jam> I'm copying it now
[15:11] <bialix> ok, thanks
[15:20] <garyvdm> Hi bialix
[15:20] <bialix> Hi Gary!
[15:20] <vila> hi Gar, hi Alexander :-D
[15:20] <garyvdm> I'm busy updating the qbzr version in karmic :-)
[15:20] <bialix> Bonjour!
[15:20] <vila> hi Gary, hi Alexander  (where did that y get lost ???)
[15:20] <garyvdm> hi Vincent
[15:22] <bialix> garyvdm: about your logslot branch: what I should to look there?
[15:23] <garyvdm> I think just give it a test - Make sure there are no regressions that I have missed
[15:24] <bialix> ok, will do in next few days.
[15:25] <bialix> there is too hot these days, my brains are melting.
[15:32] <garyvdm> bialix: I'm asking for reviews just to try avoid regressions. - Maybe what I should do with large changes like this is push it to launchpad, run it locally. and give it a week before I merge it, so that I put it through it paces before I submit it on you guys.
[15:32] <garyvdm> push it to a branch on launch pad...
[15:33] <vila> garyvdm: the silver bullet against regressions is.... :-D
[15:33] <garyvdm> tests
[15:34] <garyvdm> :-)
[15:36] <LarstiQ> jml: /win 22
[15:36] <LarstiQ> jml: woops, sorry :)
[15:37] <bialix> vila: heh, it's not silver :-P
[15:38] <vila> bialix: why ? (May be I miss a joke there...)
[15:39] <bialix> when someone run tests on one platform then other platfrom can regressed, you know
[15:39] <bialix> it's not joke, it's a sad
[15:39] <vila> ha ! That's because we don't do *engouh* tests !
[15:40] <vila> bialix: I'm setting up a build farm as a background task, windows will find its way, one day, I promise
[15:40] <fullermd> Well, there ARE only so many bits out there, so the domain IS finite.  So it's theoretically possible to do exhaustive testing...
[15:41] <fullermd> It would take a rather long time, though.
[15:41] <vila> bialix: and fullermd just voluntereed for a *BSD slave :)
[15:43]  * fullermd emancipates all his machines.
[15:46] <vila> fullermd: joke aside, I also want to add a BSD slave and I never installed one, so your advice will be appreciated
[15:46] <awilkins_> fullermd: I don't hink it's possible - because to do exhaustive testing you need more state than the astate you are testing. But then you need more state than that to test the testing. So exhaustive testing is infinite.
[15:47] <vila> awilkins_: pfff, only for small values of infinites, we're talking about TRUE infinite here
[15:47]  * fullermd . o O ( `bzr selftest --aleph-one` )
[15:49]  * vila . o O (`bzr selftest --parallel=morris-worm`)
[15:50] <jelmer> vila: :-))
[15:50] <jelmer> vila: botnets are the new cloud
[15:50] <jml> LarstiQ, np
[15:52] <vila> jelmer: hehe, botnets *are* the true power of the net, it always scares me to compare the raw power of the internet periphery and the raw power of the internet backbone...
[15:52] <vila> ...especially when the power of the former are used to attack the later.
[16:04] <Pilky> hey all, I'm currently looking into building an Obj-C API for bzr. Am I right in thinking that bzrlib.builtins is the best place to look at how bzrlib is used from the command line UI?
[16:05] <Pilky> basically I'm wanting to look at it from the view of "I can do bzr add from the command line, what does bzr call in bzrlib to do that" so I can use that for the basis of the Obj-C API
[16:14] <jelmer> Pilky, yeah, bzrlib.builtins seems like the best place for that
[16:14] <Pilky> cool, thanks
[16:21] <beuno> jelmer, hi
[16:21] <beuno> I'm trying to release loggerhead again
[16:21] <jelmer> beuno, Hey
[16:21] <beuno> and one of the blockers is daemonizing serve-branches
[16:22] <beuno> jelmer, could you point to your preferred implementation in bug 393619?
[16:43] <jam> abentley: I think bundlebuggy is down again
[16:44] <abentley> jam: restarted
[16:44] <jam> thanks
[16:56] <vila> jelmer: bzr-gtk users are dying for a new release ! :)
[17:00] <jelmer> vila, yeah, I know :-/ I'll see if I can do another release at some point.
[17:01] <jelmer> vila, It should really only matter for people who use the tarball though, and they can also use the bzr branch
[17:01] <vila> jelmer: that would be very appreciated
[17:01] <vila> jelmer: well, I'm pretty sure some distros will use only released versions...
[17:19] <Junqiang> hi all
[17:20] <Junqiang> anyone knows how to use new eol filter feature in bzr? I have serious trouble with it.
[17:50] <kfogel> what command what I run to find out if a file is under version control, in a bzr working tree?
[17:50] <kfogel> 'bzr status -v FILE' ?
[17:51] <kfogel> I guess so: silence means it's versioned, "unknown:" means it's not.
[17:52] <visik7> I have 2 branch of the same code
[17:52] <visik7> one at revision 1
[17:52] <visik7> the other at rev 2
[17:52] <LarstiQ> kfogel: I'd go with `bzr ls -V` I think
[17:52] <visik7> from rev 2 I run bzr send
[17:53] <LarstiQ> kfogel: but status would be my other approach
[17:53] <visik7> and from rev 1 I run bzr merge file.patch
[17:53] <visik7> but I got this error:
[17:53] <visik7> NoSuchRevision: KnitPackRepository('file:///Users/visi/Documents/Flex%20Builder%203/fotografie/.bzr/repository/') has no revision ('biagio@mattonella-20090630164723-2uiorutm7tj3srtq',)
[17:53] <kfogel> LarstiQ: thanks
[17:54] <Junqiang> Who have ever used the EOL filter feature?
[17:54] <LarstiQ> visik7: is the rev1 the submit branch for the rev2 one, and how did you run bzr send?
[17:55] <jelmer> Junqiang, igc developed it, but he's in .au so probably asleep atm.
[17:55] <LarstiQ> Junqiang: I haven't, but what are you having problems with?
[17:55] <visik7> the first question : I dunno, the second question: in which sense  how I run it?
[17:58]  * SamB wonders *why* git doesn't list directories in the index
[17:59] <kfogel> SamB: does git really version directories?
[18:00] <jelmer> kfogel: it only supports "implicit" directories, much like CVS I think
[18:00] <SamB> kfogel: it could, if it did
[18:00] <LarstiQ> Junqiang: don't message people in private unasked, it is rude and will not get you help from other people
[18:01]  * LarstiQ personally is at europython and a talk just started
[18:02] <mneptok> isn't "Europython" a porn film?
[18:03]  * mneptok shrugs
[18:05] <spetrunia> Hi! Anybody could help with this problem: my bazaar doesn't send commit notification emails. "bzr gcommit" says nothing but returns non-zero status
[18:05] <spetrunia> the commit iself is made, can see it in bzr log
[18:06] <SamB> jelmer: you have a really wierd way of numbering bzr-svn versions, you know that?
[18:06] <jelmer> SamB, what's strange about it?
[18:06] <SamB> well, I see 0.6 above 2.0 on this tree view ...
[18:06] <spetrunia> Here are .bzr.log and config: http://pastie.org/529613 ... overall the system is a very regular ubuntu 9.4
[18:06] <jelmer> SamB: That's a Launchpad bug
[18:06] <SamB> jelmer: oh ;-)
[18:27] <Tak> yay fetch-ghosts!
[18:28] <LarstiQ> hmm, Junqiang left. I messed that one up.
[18:29] <LarstiQ> mneptok: isn't everything?
[18:29]  * LarstiQ moves to the CouchDB talk
[18:37] <kfogel> spetrunia: I'm no expert, but I'll take a look
[18:39] <kfogel> spetrunia: :-(  I lack the knowledge to help.  Sorry!
[18:39] <spetrunia> kfogel: thanks for the attempt anyway :-)
[18:40] <kfogel> spetrunia: it was pretty futile -- I realized looking at your setup that you probably are more bzr expert than I am :-).
[18:51] <jelmer> spetrunia, does "bzr commit" work ok?
[18:51] <spetrunia> let me try...
[18:56] <spetrunia> jelmer: It has returned zero status, but still haven't tried to send the message... here's .bzr.log: http://pastie.org/529669
[18:57] <spetrunia> I wonder which part of bazaar sends emails? Is it its integral part or a plugin (property of your install), or a script (property of the branch), or both, or?
[19:03] <jelmer> spetrunia, do you have post_commit_to set? do you have bzr-email installed?
[19:05]  * spetrunia looking
[19:07] <spetrunia> jelmer: the tree has .bzr-mysql/ directory (next to .bzr) which has default.conf  which sets post_commit_to = maria-developers@lists.launchpad.net
[19:07] <spetrunia> bzr-email... not sure.. "bzr plugins" shows bzrtools 1.13 , dbus , gtk, launchpad, netrc_credential_store
[19:08]  * spetrunia tries to figure out if 'bzr commit' will even read .bzr-mysql/default.conf
[19:09] <spetrunia> hmm it does but it's not clear whether that is a read of config file or part of commit action...
[19:10]  * spetrunia googles for bzr-email
[19:18] <spetrunia> Hooray! after installing  bzr-email plugin, and seeing post_commit_to globally, it worked
[19:18] <spetrunia> jelmer: thanks!
[19:50] <jrwren> is there any smart server via fcgi info newer than http://doc.bazaar-vcs.org/bzr-0.15/http_smart_server.htm ?
[20:31] <jrwren> what purpose does the pipe server in the regex?   RewriteRule ^(.*/|)\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
[20:31] <jrwren> isn't that equivalent to .*/? ?
[20:36] <luks> .*/? would mean "something and optionaly /"
[20:37] <luks> I guess you could rewrite (.*/|) as (.*/)?
[20:39] <jrwren> .* isn't something though, it oculd be empty, so aren't they call equiv?
[20:43] <luks> it could also not be empty
[20:43] <luks> you don't want to accept "foo" as an input
[20:43] <luks> only "foo/" or "/"
[20:43] <luks> sorry
[20:43] <luks> only "foo/" or ""
[20:43] <jrwren> ah, ok.
[20:44] <jrwren> thank you.
[21:17] <Haris1> Hi, I need to do some web dev work and have been given access to a bzr installation. Being new to bzr I'm not sure whether I need to bzr checkout or bzr branch?
[21:18] <Haris1> I want to work on a local xampp installation and then when done developing upload back to the love server (original bzr installation)
[21:18] <LarstiQ> Haris1: either will work
[21:19] <LarstiQ> Haris1: ah, for that branch is better
[21:19] <LarstiQ> Haris1: since with a checkout every commit will go directly to the place you checked out from
[21:19] <Haris1> Hi LarstiQ, ok thanks, i was concerned that when i did a bzr commit it would send things back to the main server against my will
[21:20] <Haris1> aha that makes sense
[21:22] <LarstiQ> Haris1: `bzr branch` will get you a fully decentralized standalone branch to work with
[21:22] <Haris1> When I'm done developing locally, is it possible to send the local commit history and commit messages back to the main working folder (live server)?
[21:22] <LarstiQ> Haris1: commit is just local, push/send  get it upstream
[21:23] <LarstiQ> Haris1: yes
[21:23] <Haris1> Great! is push and send the same command?
[21:23] <jrwren> i'm having a bit of trouble with a wsgi smart server.   bzr ls bzr+https://myserver/rootofbzr works, but drilling down into a dir like https://myserver/rootofbzr/dir does not.
[21:24] <jrwren> it says bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-62309520:///'.")
[21:25] <LarstiQ> Haris1: no, two different ones, you probably want push (send is for when you don't have write access/want to mail the history/review etc)
[21:26] <LarstiQ> jrwren: that sounds like it doesn't like access above 'rootofbzr'?
[21:27] <Haris1> That's great it all makes sense now, thanks again LarstiQ, I'm off to put it into practice! :)
[21:27] <LarstiQ> Haris1: ok :)
[21:27] <jrwren> it should, but there is no "above" in the repo of rootofbzr, and in the apache config, the "above" is just the exposed bzr files.  I don't need a local checkout do i? because this is a repo with no trees.
[21:27] <LarstiQ> Haris1: the user guide should also help answer some of these questions
[21:28] <LarstiQ> jrwren: no, just the .bzr control dir
[21:28] <Haris1> I have been looking at it but I got a bit lost in the detail, will give it another look now that you've given mecontext
[21:28] <jrwren> if I have two .bzr dirs, that means 2 different branches or repos, right?
[21:28]  * LarstiQ nods at Haris1 
[21:28] <LarstiQ> jrwren: .bzr/ can contain any of /repository/, /branch/ or /checkout/
[21:29] <jrwren> I always found this particular repo rather strange.  I have c:/repo/.bzr and c:/repo/effectivelytrunk/.bzr and I thought I had all one repo, but now I'm thinking I actually have 2 repos
[21:29] <LarstiQ> jrwren: if you have a shared repository, you will have one for the repository and one for each branch
[21:29] <jrwren> ah, so that is what I have, a shared repo and each branch.
[21:29] <LarstiQ> jrwren: what does `bzr info` think of them?
[21:29] <LarstiQ> jrwren: sounds likely
[21:30] <jrwren> I was hoping to expose the whole repo, and all branches via bzr-smart.wsgi - but maybe I can only smart share a branch?
[21:30] <LarstiQ> jrwren: I haven't heard of bzr-smart.wsgi before, but I'd expect you to be able to expose the whole repo
[21:31] <jrwren> LarstiQ: indeed, my effectivelytrunk says it is a repository branch: effectivelytrunk
[21:31] <LarstiQ> jrwren: in particular, the branch control dirs don't contain the revision data, so if you don't expose the repository .bzr there is no way anyone can use the branches
[21:31] <jrwren> but it says Location: shared repository: .
[21:31] <jrwren> the repo is actually at .. relative to effectivelytrunk
[21:32] <LarstiQ> jrwren: if you run it from ..?
[21:32] <jrwren> yes
[21:32] <LarstiQ> jrwren: right, that makes
[21:32] <LarstiQ> sense
[21:32] <LarstiQ> jrwren: try to cd to effectiveltrunk and run `bzr info .`
[21:32] <jrwren> ok, so that was relative to my curdir, not relative to the subdir.
[21:32]  * LarstiQ nods
[21:32] <jrwren> LarstiQ: yup, just did that, and it makes sense.
[21:33] <LarstiQ> jrwren: so, when you access a branch, it walks up the directory structure to find it's repository
[21:33] <jrwren> ok, so this repo looks good.  Now I just need to figure out how to use bzr-smart.cgi (the wsgi is just a port of the cgi) with a repo
[22:25] <lifeless> moin
[22:26] <lifeless> jam: yes
[22:26] <lifeless> jam: cd repo; uncache; test
[22:26] <jam> morning lifeless
[22:27] <lifeless> I haven't tested it yet; but its from a drizzly/mysqly person so I imagine they have used it on Ubuntu :)
[22:27] <lifeless> hi jam
[22:27] <jam> lifeless: well, I suppose it depends if you want to flush the source files
[22:27] <lifeless> hmm, I wonder if it actually drops dentries as well or only content
[22:27] <jam> if you are just testing repo perf, then that looks quite good
[22:28] <lifeless> if (node->fts_info != FTS_F) continue;
[22:28] <lifeless> skips dirs I think
[22:28] <lifeless> but its probably tunable
[22:28] <lifeless> would need to use a stack
[22:48] <lennymaiorani> hello all. I have just upgraded to bzr 1.16.1 and I am seeing unusually high CPU load. Is this a known issue? Is there some way I can fix this?
[22:49] <mwhudson> lennymaiorani: on the server or the client side?
[22:49] <mwhudson> and doing what sort of operation?
[22:49] <mwhudson> (basically, i haven't heard of anything like this)
[22:49] <lennymaiorani> mwhudson: I have only looked at the client. I can take a peek at the server as well. I am doing a checkout, but also noticed it doing commits.
[22:50] <mwhudson> hmm
[22:50] <mwhudson> lennymaiorani: what did you upgrade to 1.16.1 from?
[22:51] <lennymaiorani> mwhudson: 1.15+x. I am not sure exactly which 1.15 I was on. It was something from the devel PPA
[22:51] <mwhudson> ok
[22:51] <mwhudson> that's pretty strange
[22:51] <mwhudson> commit was supposed to be faster in this release :)
[22:51] <mwhudson> i think
[22:51] <mwhudson> lennymaiorani: what format are you committing to?
[22:52] <lennymaiorani> mwhudson: server looks normal. very low load while i am doing a checkout
[22:53] <lennymaiorani> mwhudson: the server has a rich-root-pack repo
[22:53] <mwhudson> strange
[22:53] <lifeless> what bzr version is the server?
[22:54] <lennymaiorani> 1.17dev
[22:54] <lennymaiorani> oops. i thought it was 1.16.1
[22:54] <lennymaiorani> actually, my client is also. maybe i should go back to 1.16.1. my fault.
[22:56] <lennymaiorani> looks like i am on the nightly PPA. i meant to be on the beta PPA.
[23:00] <mwhudson> well if 1.17dev is acting up and 1.16.1 is not, that's interesting :)
[23:00] <lennymaiorani> mwhudson: I am downgrading to bzr 1.16.1 right now
[23:05] <lennymaiorani> mwhudson: I am seeing the same behavior from 1.16.1
[23:05] <mwhudson> lennymaiorani: so the problem is committing to a rich-root-pack ... lightweight checkout?
[23:06] <lennymaiorani> mwhudson: it is a rich-root-pack repo and a shared rich-root-pack repo full checkout
[23:07] <mwhudson> m
[23:07] <mwhudson> hm
[23:07] <mwhudson> i have one of them too
[23:07] <mwhudson> and it seems ok
[23:07] <mwhudson> (well it's 1.9-rich-root, but that shouldn't really matter)
[23:07] <mwhudson> lennymaiorani: how big is the branch?
[23:07] <lennymaiorani> mwhudson: 107 MB
[23:08] <mwhudson> mm
[23:08] <mwhudson> all i can suggest is collecting as much data as you can (like, how much slower is it that it was) and filing a bug
[23:09] <lennymaiorani> mwhudson: gotta run. i will try to get that done tomorrow. thanks for the input.
[23:09] <mwhudson> no worries