[00:04] <igc> poolie, spiv: call on today?
[00:05] <poolie> igc, yes, but i can't get in
[00:06] <poolie> still trying
[00:06] <igc> poolie: I'll hang up in case that helps
[00:07]  * spiv hangs up too
[00:07] <schierbec1> jelmer: ping
[00:08] <igc> poolie: I got straight back in ok
[00:08] <igc> is it your local phone maybe?
[00:12] <poolie> it might be my phone
[00:12] <poolie> when i tried i got through to varying extents
[00:12] <poolie> anyhow
[00:13] <poolie> let's just catch up here on irc?
[00:13] <spiv> Sounds good.
[00:13] <igc> me too
[00:13] <poolie> so i think the PPA stuff is all settled now
[00:14] <igc> today, I'm planning to review patches, particularly the xml8 serializer one
[00:14] <poolie> i'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking
[00:14] <igc> I need to learn more about that so reviewing that patch will help me
[00:15] <poolie> i'd like to suggest the whole project do a bug day tomorrow, will send mail about that
[00:15] <poolie> also i seem to have some Ubuntu bugs atm
[00:15] <poolie> so will file them
[00:16] <igc> poolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak
[00:16] <poolie> i'll do that
[00:16] <igc> thanks
[00:17] <poolie> also when lifeless is back i'll call him re his conference submission
[00:17] <poolie> and i owe thumper a call or sketch of the branch listing page
[00:17] <igc> if you get a chance, I'd like some feedback on my hook patch/rfc too
[00:18] <spiv> I've sent off the core bits of the fix for bug 207558.  I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done.
[00:18] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
[00:18] <poolie> ok
[00:18] <poolie> i'll try to read that for you spiv
[00:18] <poolie> what is next for you?
[00:18] <spiv> So today will be mainly server-side hooks.
[00:20] <igc> poolie: another thing for me today - kill & resume the OOo import
[00:21] <igc> it's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow
[00:22] <igc> I took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps
[00:31] <poolie> ok, good
[00:39] <lifeless> igc: We should find what the cache was masking and fix it.
[00:44] <lifeless> igc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer
[00:45] <lifeless> igc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist.
[00:46] <igc> lifeless: maybe. commit-builder currently does things much slower than the importer does
[00:47] <igc> it simply can't make some of the assumptions than an importer can
[00:47] <igc> which make big differences to speed
[00:48] <lifeless> igc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be.
[00:48] <lifeless> igc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :>
[00:48] <lifeless> I'm going to do a couple of spikes today
[00:48] <lifeless> and get back to VF this afternoon
[00:50] <lifeless> I chatted with benno last night about python performance
[00:50] <lifeless> and he concurred with my import analysis, gave some commentary on os call performance readdir etc
[00:50] <lifeless> so I'm going to do this long threatened import hook
[00:53] <spiv> lifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time).  I'll be interested to see if the reality is different.
[00:55] <lifeless> spiv: strace doesn't show how much time python spends marshalling
[00:55] <lifeless> spiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook
[00:59] <lifeless> holy cow 'import bzrlib' hits a lot of shit
[00:59] <lifeless> 34 modules
[00:59] <poolie> yes, i know
[01:00] <lifeless> many are demand load stubs I think
[01:00] <lifeless> or something strange
[01:01] <lifeless> -weird
[01:01] <lifeless> >>> type(sys.modules['bzrlib.struct'])
[01:01] <lifeless> <type 'NoneType'>
[01:02] <spiv> That's expected.
[01:03] <spiv> When a module inside the bzrlib package tries "import struct", python first treats it as a relative import.
[01:03] <spiv> And when an import fails, it caches misses as well as hits in sys.modules.
[01:03] <lifeless> ah good
[01:04] <spiv> (Bring on python 2.5...)
[01:04] <lifeless> 12 real modules imported then
[01:20] <spiv> lifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev.  (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...)
[01:21] <spiv> (as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)")
[01:27] <lifeless> spiv: what does your faster-startup branch do ?
[01:27] <lifeless> spiv: (I am only planning to alter the behaviour of bzrlib specific imports)
[01:28] <spiv> lifeless: basically, various hackery to defer unnecessary imports
[01:28] <spiv> (or avoid)
[01:29] <spiv> lifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get.
[01:30] <lifeless> has anyone tried running freeze on bzr ?
[01:30] <spiv> Oh, and specifically also reducing the amount of the universe that "import bzrlib" imports :)
[01:30] <lifeless> e.g. making *everything* import and running freeze
[01:31] <lifeless> spiv: so my thesis is that we should make importing everything fast
[01:31] <lifeless> because in the general case most of the code is needed
[01:46] <lifeless> spiv: what do you mean about 2.5?
[01:46] <mwhudson> i don't think he meant 2.5
[01:47] <mwhudson> at some point, imports written the normal way will be absolute
[01:47] <mwhudson> which means less looking for things like bzrlib.struct
[01:49] <spiv> I meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html
[01:49] <spiv> 2.5 introduces "from __future__ import absolute_import"
[01:50] <mwhudson> oh, heh
[01:50] <mwhudson> shows when i stopped paying microscopic attention to python development
[01:54] <lifeless> damn, pkgutil doesn't exist in 2.4
[02:08] <lifeless> so, I'm saving 130/4900 open calls
[02:08] <lifeless> all of which look like failures
[02:18] <LaserJock> question, how do I change the "parent branch" of a branch?
[02:19] <poolie> igc, is there a BB enttry for the patch from james_w you mentioned before?
[02:20] <poolie> igc, i take it you were referring to the one to give a warning when getting a readonly transport?
[02:20] <igc> poolie: that's right
[02:21]  * igc looks
[02:21] <igc> http://bundlebuggy.aaronbentley.com/request/%3C1205831646.7247.295.camel@flash%3E
[02:21] <igc> poolie: ^^^
[02:22] <poolie> thanks
[02:23] <lifeless> LaserJock: pull --remember
[02:26] <LaserJock> lifeless: awesome
[02:35]  * igc lunch
[02:46]  * mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes
[02:51] <spiv> mwhudson: there was a thread about that on the list recently
[02:51] <spiv> mwhudson: it shouldn't complain, IIRC
[02:51] <mwhudson> there was?  must have missed that in my catchup
[03:04] <lifeless> mwhudson: it should tell you, and take your changes as part of the merge
[03:04] <lifeless> mwhudson: IMO
[03:06] <mwhudson> i guess that makes sense
[03:14] <lifeless> ok, I now have my code being called consistently
[03:21] <abentley> lifeless: well, I'm not convinced.
[03:21] <abentley> It's not a very accurate preview that way.
[03:21] <lifeless> abentley: why is it less accurate?
[03:23] <abentley> because merge won't make any of those changes.  It will barf.
[04:07] <poolie> abentley: thanks for the review ofthe help change
[04:07] <abentley> np
[04:08] <abentley> Something else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca
[04:09] <abentley> Even though those algorithms handle criss-cross better.
[04:10] <abentley> So perhaps it should say not to remerge if you're already using --lca or --weave.
[04:10] <poolie> so would you overall suggest using remerge, or revert and merge again?
[04:13] <lifeless> back in a few minutes; getting lunch
[04:24] <abentley> poolie: I'd suggest revert and merge.
[04:25] <abentley> Fewer commands to learn that way.
[04:29] <lifeless> abentley: when is remerge a good thing to learn and use then ?
[04:30] <abentley> I generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can.
[04:31] <abentley> If there are basic, intermediate, and advanced commands, I'd consider it intermediate.
[04:31] <lifeless> ok
[04:31] <lifeless> one thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down.
[04:31] <lifeless> I think we may have something similar here.
[04:32] <poolie> that is basically when i use remerge too
[04:32] <poolie> rarely on the whole tree
[04:33] <poolie> could we at least make it fail safe on looms - like give an error rather than mess things up?
[04:34] <abentley> lifeless: are you familiar with the problem?
[04:35] <lifeless> abentley: no, I've never used remerge like that
[04:35] <lifeless> oh, you mean with looms - I've seen the bug report
[04:36] <abentley> So the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent.
[04:37] <abentley> but with up-thread, it is actually the rightmost parent.
[04:37] <lifeless> I think the things are about-face for performance
[04:37] <lifeless> I didn't want to transform; then merge
[04:38] <abentley> I'm not sure your approach is wrong.  A different approach might lead to more conflicts.
[04:39] <lifeless> its on my long todo to teach bzr's merge the ability to be told different file suffixes
[04:40] <lifeless> so we can drop the 'right files' in the right places
[04:40] <lifeless> and give better herringbone labels
[04:40] <abentley> You'd also want to swap the conflict markers.
[04:40] <abentley> :-)
[04:40] <lifeless> I'd actually like to call them by their thread names
[04:40] <fullermd> Speaking of merge, did --reprocess stop doing its thing sometime?  Or did it just never really cut things down a lot?
[04:40] <abentley> Sure.
[04:41] <lifeless> fullermd: I think it became default
[04:41] <poolie> abentley: could you suggest some better help text?
[04:41] <poolie> should we say "use remerge FILE, or revert and merge again?"
[04:42] <abentley> Let's say "revert and merge again".
[04:42] <abentley> lifeless: So we understand the problem-- is there a short-term fix we can do like poolie suggested?
[04:43] <abentley> fullermd: I don't think it became the default.  But it only helps a narrow class of merges, and only applies to --diff3
[04:44] <abentley> lifeless: The problem so far is that we can't even tell that the merge was different.
[04:45] <fullermd> I've got kernel configs in bzr to easily merge upstream changes, and every time I do (last was some months ago), I get hyuge spurious conflicts that it doesn't help.
[04:53] <abentley> fullermd: line endings?
[04:53] <fullermd> No, but changes in single lines ended up resurrecting giant blocks that I'd deleted.
[04:53] <awmcclain> Imagine we pushed some changes for April Fools day. Like, 4 revisions. What would the easiest way, hypothetically, to check an older revision to head?
[04:54] <fullermd> I guess it's some artifact of the diff hunk for the revs where I whacked the blocks.
[04:55] <spiv> awmcclain: bzr push -r NNN --overwrite
[04:55] <spiv> awmcclain: (NNN == -4, I guess...)
[04:55] <awmcclain> spiv: And if it's a bound branch, can we do bzr ci -r NNN --overwrite?
[04:56] <abentley> fullermd: I'd normally offer to help, but I'm behind already.
[04:56] <spiv> awmcclain: ah, with a bound branch, use uncommit
[04:56] <awmcclain> spiv: 4 times?
[04:56] <spiv> awmcclain: which also takes a -r arg.
[04:56] <spiv> Or just run it 4 times, sure.
[04:56] <awmcclain> spiv: Gotcha!
[04:56] <fullermd> Or just pull -r-4 --overwrite .
[04:56] <spiv> fullermd: heh.
[04:56] <lifeless> fullermd: pull overwrite affects master branch :)
[04:57] <fullermd> abentley: *shrug*  It's not that big a deal.  Bugs me for 30 seconds or so a couple times a year when I do it.  Hasn't been a high enough priority for me to build up a test case for it.
[04:57] <abentley> fullermd: You might try --lca.  It's kinda got --remerge built in.
[04:57] <abentley> s/--remerge/--reprocess
[04:58] <fullermd> Last time I tried was probably pre-lca; I tried both diff3 and weave, with/out reprocess; came up the same every time.
[04:58] <awmcclain> But if I want to commit _over_ the current changes, not remove them.. could i bzr revert -r NNN then ci?
[04:58] <fullermd> I'll try getting creative next time it comes up.
[04:58] <spiv> awmcclain: right
[04:59] <poolie> abentley, BB seems to be stuck, can you whack it?
[05:00] <abentley> poolie: did it give you a lock error?
[05:01] <spiv> abentley: I'm currently getting 502 Proxy Error
[05:02] <spiv> "Reason: Error reading from remote server"
[05:04] <igc> abentley: me too
[05:04] <igc> " The proxy server could not handle the request GET /."
[05:05] <abentley> I have increased the database timeout to unreasonable levels.
[05:05] <abentley> So there's an active lock, but I'm not sure whether it will resolve itself.
[05:06] <abentley> The last time I got a 502, it did.
[05:07] <poolie> same
[05:07] <lifeless> you're using sqlite right?
[05:07] <abentley> Okay, whacked.
[05:07] <abentley> lifeless: right
[05:08] <lifeless> there is something funny in the python bindings AFAICT
[05:08] <bob2> sqlite3?
[05:08] <poolie> abentley: how about this:
[05:08] <poolie> In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give
[05:08] <poolie> better results.  You may wish to `bzr revert` the working tree and merge
[05:08] <poolie> again, or use `bzr remerge` on particular conflicted files.
[05:09] <poolie> i feel kind of reluctant not to mention remerge because it's what i usually run myself
[05:09] <poolie> i see your point though about involving less commands
[05:09] <abentley> Okay, fair enough.
[05:09] <poolie> and if they did help criss-cross just after the failure they will not lose anything
[05:09] <abentley> Perhaps we should omit the revert; remerge thing.
[05:09] <abentley> Pardon?
[05:10] <abentley> lifeless: Any suggestions on a band-aid for up-thread?
[05:11] <lifeless> abentley: w.r.t remerge ?
[05:11] <abentley> Yes.
[05:11] <lifeless> I don't think there is a good band-aid; I think it just needs the bzrlib work done.
[05:11] <poolie> """In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give
[05:11] <poolie> better results.  You may wish to `bzr revert` the working tree and merge
[05:11] <poolie> again.  Alternatively, use `bzr remerge` on particular conflicted files.
[05:12] <poolie> "'"
[05:21]  * poolie reads fix for 207558
[05:23] <lifeless> poolie: call ?
[05:23] <poolie> in 6m?
[05:23] <lifeless> sure
[05:38] <abentley> poolie: re that TT bug, it's due to adding a file to a deleted directory, when the deleted directory was the root directory.
[05:39] <poolie> !
[05:39] <poolie> ok
[05:40] <lifeless> spiv: ping
[05:40] <abentley> Anyhow, now that I can reproduce it, it shouldn't be a hard fix.
[05:40] <lifeless> I have a 'wtf' moment with my import hook
[05:41] <poolie> lifeless: your phone's engaged?
[05:41] <lifeless> its trying to import 'debian_bundle' from '' in the Numeric path path_hook object
[05:41] <lifeless> poolie: no??
[05:44] <spiv> lifeless: pong
[05:44] <lifeless> does Numeric do crack?
[05:59] <spiv> lifeless: I don't know if Numeric does crack or not.
[06:00] <mwhudson> beuno: around?
[06:13] <lifeless> spiv: you have mail
[06:13] <lifeless> spiv: should be self evident if you want to apply it to bzr.dev and play
[06:14] <lifeless> spiv: I get quite reduced syscalls with this but its buggy :/
[06:38] <jamesh> lifeless: bzr-gtk has now been updated so that it functions correctly with my bzr-dbus patches, btw
[06:39] <jamesh> they're waiting on you for review though.
[06:40] <lifeless> thanks
[06:51] <spiv> abentley: bb seems to be wedged again
[07:34] <vila> lifeless: regarding loom-specific conflict markers, please be sure you won't break external tools that are looking for them (i.e. may be *add* thread name after the usual markers instead of replacing MERGE-SOURCE and/or TREE)
[07:52] <Egotrip> Want to make $$$ just by clicking? Sign up on http://bux.to/?r=eg0trip, and begin recieving checks!
[07:54] <james_w> no thanks
[07:54] <Egotrip> yes you do
[08:04] <mdke> lifeless: still around?
[09:03] <lifeless> dunno who egotrip was, but we don't want spam here.
[09:08] <fullermd> He didn't explain himself very well, certainly.  I kept clicking, but I got @@@ instead of $$$   :|
[09:15] <jamesh> and I'd prefer to receive cheques rather than checks
[09:30] <yacc> Hmm, how can I force a baseless merge with bzr?
[09:32] <schierbeck> jelmer: ping
[09:32] <yacc> schierbeck: I second that: ping jelmer
[09:32] <schierbeck> :)
[09:32] <yacc> schierbeck: what's it for you? In my case bzr-svn seems to have forgotten about branch relationships ;(
[09:33] <schierbeck> tough luck
[09:33] <schierbeck> nah, i just want him to give his 2 cents before i send in a merge request
[09:34] <james_w> yacc:  merge -r1..-1
[09:35] <yacc> james_w: is that a good idea, considering that the branch contains the same revisions as the remote one? (bzr just seems to think that they are unrelated)
[09:35] <james_w> yacc: probably not
[09:35] <james_w> how did you create your local branch?
[09:35] <yacc> bzr branch svn+https://...
[09:36] <james_w> from the same branch you are trying to merge now?
[09:37] <yacc> Look at: https://bugs.launchpad.net/bzr-svn/+bug/210705
[09:37] <ubotu> Launchpad bug 210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New]
[09:37] <yacc> james_w: but basically yes.
[09:38] <yacc> james_w: => it remembers where it pulled from, and pushed to in the past.
[09:38] <yacc> james_w: just when doing a merge it complains about being unrelated.
[09:38] <yacc> Oh, bzr missing lists all revisions as missing on both sides, plus the one that I did commit locally, which is only listed on one side.
[09:39] <yacc> but the merge did not help anything, it still misses 3/4 revisions ;(
[09:40] <yacc> james_w: despite the above merge -r1..-1, it still claims that the branches are diverging.
[09:40] <james_w> yacc: can you pastebin a bzr missing --show-ids
[09:40] <yacc> james_w: just a moment, first I'm curious ;)
[09:42] <yacc> james_w: they don't match :(
[09:42] <yacc> http://rafb.net/p/a1aZXh19.html
[09:43] <yacc> james_w: guess that is what jelmer meant with the ids can change?
[09:43] <yacc> jelmer!!!!!!!!!!!!!!!
[09:43] <james_w> they don't match is the reason that you are seeing this issue.
[09:43] <james_w> calm down, he's been highlighted, if he's around he'll see it
[09:44] <yacc> james_w: yeah, BUT: I had to change the scheme to include new trunks
[09:44] <yacc> revision-id: svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56
[09:44] <yacc> revision-id: svn-v3-list-QlpoOTFBWSZTWYDqAEcAADdRgAAQAAK3r94gIABISkMo0zUaemoEkkaZMAm1IM83f4FQYGxfzVWsvATONoa96yIoS8IEx1BxVRIGB_MCYIMwX5NxaET_F3JFOFCQgOoARw..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56
[09:45] <yacc> see the base64 encoded list of paths <= I had to change that to accomodate a new branch.
[09:45] <james_w> you changed the svn branching scheme?
[09:45] <yacc> james_w: list-path1-path2 => list-path1-path2-path3 <= I had to add path3 because it's a new branch I need access to?
[09:47] <yacc> james_w: basicaly the revids for branch X contain the a list of all other branches that I'm accessing in the given SVN repo.
[09:48] <yacc> james_w: Hmmm, I think the fix would be to make bzr-svn use svn-v3-list-$PATH_USED_IN_THIS_CASE instead of svn-v3-list-$PATH_OF_THE_COMPLETE_SCHEME?
[09:50] <yacc> james_w: Any explanation what the different branching schemes are good for?
[09:53] <james_w> yeah, so it's caused by the change to the branching scheme
[09:54] <james_w> the scheme is to tell bzr-svn which paths in svn to consider branches
[09:56] <yacc> yeah, but the problem is, appending one new "path" in the repository is a quite expected thing to do.
[09:56] <yacc> It should not break all branches/checkouts in the wild, just because I need to track one additional location?
[09:57] <james_w> yacc: add this information to the bug report.
[09:57] <yacc> Already done so.
[10:00] <yacc> james_w: single would mean that I can only access exactly one path inside the svn repo?
[10:00] <james_w> I think so
[10:01] <yacc> Hmmm.
[10:01] <yacc> So basically I would need to parametrize the "schema name for property name" lookup thing.
[10:02] <yacc> It basically needs to take the URL being accessed into account ;(
[10:06]  * yacc wonders what the schemes are good for at all?
[10:10] <igc> james_w: I'm hoping to review that gnome bug tracker patch tomorrow
[10:10] <igc> if you put through abentley's tweak tonight, that would be nice ...
[10:10] <igc> though I realise you may not have time
[10:10] <igc> I'm heading off now
[10:10] <igc> night all
[10:11] <james_w> igc: thanks, I'll try and get to it.
[10:11] <james_w> night
[10:13] <jml_> lifeless: ping
[10:22] <yacc> jelmer: ping
[10:27] <yacc> jelmer: would it be ok by you to implement a "EveryPathIsABranchScheme"?
[10:40] <AnAnt> Hello, when using bzr, can't I checkout just a single folder instead of the whole branch ?
[10:41] <luks> right, you can't
[10:41] <luks> bzr can only work with whole branches
[10:42] <AnAnt> unlike svn
[10:43] <luks> svn doesn't have branch :)
[10:43] <luks> *branches
[10:44] <yacc> luks: and branches is (almost) all that bzr has ;)
[10:44] <yacc> How do I make bzr send my local commits as a patch to the maintainer?
[10:45] <luks> bzr send
[10:46] <yacc> I just discovered that just switching schemes won't work => the svn repos contains pointers to the old scheme name, ...
[10:47] <yacc> My only hope for a sane scheme is rapidly crashing.
[10:51] <yacc> jelmer: ping
[11:05] <ChriS_T> I am trying to convince a colleague to use bzr for our collaboration.  However, he has a mac OSX 10.4 intel.  Is there a ready to use disk image for that machine ?
[11:13] <james_w> there's a macport I think
[11:18] <ubotu> New bug: #210665 in bzr-svn "bzr svn-import fails" [Undecided,New] https://launchpad.net/bugs/210665
[11:20] <ubotu> New bug: #210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] https://launchpad.net/bugs/210705
[11:21] <ubotu> New bug: #210723 in bzr "Some tests failed when selftest is invoked with -v" [Low,Confirmed] https://launchpad.net/bugs/210723
[11:22] <jelmer> yacc: pong
[11:23] <jelmer> yacc: EveryPathIsBranchingScheme will be incredibly slow
[11:24] <yacc> jelmer: why?
[11:25] <yacc> jelmer: and it misses to_list, which makes --set break, but I guess it breaks for other schemes too.
[11:25] <jelmer> yacc: When searching for revision ids, bzr-svn checks every possible branch path for properties
[11:26] <yacc> Well, it seems the that list paths get embedded in the properties somehow, so just doing a fresh branch with the ammended paths is not an option either.
[11:26] <jelmer> in the case of EveryPathIsBranchingScheme that means one call per file/directory in the remote repository
[11:27] <yacc> And let me guess it does not cache the results in any way ;)
[11:27] <jelmer> it does cache the results
[11:27] <jelmer> but that's still too slow
[11:28] <yacc> brb
[11:32] <yacc> so how to fix the list scheme then?
[11:34] <jelmer> how do you mean?
[11:52] <yacc> Well, the list scheme embeds the paths in the revision stuff.
[11:53] <yacc> Meaning that when somebody adds a new path (because a new path got added), bzr-svn implods.
[11:53] <yacc> jelmer: : #210705
[11:54] <yacc> jelmer: easy to demonstrate: with a branch that uses a list scheme, add another path to the list => et voila, bzr thinks that the svn remote branch and your local bzr branch do not share any history.
[11:54] <yacc> Which is wrong.
[11:55] <yacc> Considering the fact that some svn users use very very creative directory setups, ...
[11:55] <jelmer> yacc: that's correct because they have a different branching scheme
[11:55] <yacc> Ok, so how do I handle the case that my upstream project just got a new subproject?
[11:55] <jelmer> yacc: What you really want is a fix for bug 130372
[11:55] <ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
[11:55] <jelmer> yacc: you can use wildcards in listbranchingscheme
[11:56] <yacc> jelmer: Only if I would have started with wildcards. Take a look at the later comments in 210705 and you'll notice that it seems impossible to switch the scheme for a given repo and recreate the bzr branch
[11:57] <jelmer> yacc: yes, that's correct
[11:57] <jelmer> yacc: that's why there's bug 130372
[11:57] <ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
[11:58] <yacc> so what do I do? write myself scripts that replace ~/.bazaar/subversion.conf based on the directory I'm in when calling bzr?
[12:00] <jelmer> yacc: The error fetching after changing branching schemes is a bug
[12:01] <yacc> So I open up a time loop window, and go studying the source code to fix that bug? <= I mean the scheme is part of the revision IDs?
[12:05] <yacc> Serious, new bug or known bug?
[12:06] <jelmer> yacc: the branching scheme is part of the revision id
[12:06] <jelmer> yacc: that's bug 130372 I mentioned earlier
[12:06] <ubotu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
[12:07] <yacc> jelmer: 130372 is not about a bug fix, it's about joined branches, right? Meaning that you could drop to supporting only trunk/none for bzr-svn and make the people use split out parts of these repositories, right?
[12:08] <jelmer> yacc: no, it's about abandoning branching schemes completely
[12:08] <jelmer> as soon as by-value branches are supported
[12:09] <jelmer> well, replacing branching schemes with a "repository layouts", which are not included in the revid
[12:11] <yacc> So nothing simple for a newbie that has only a limited understanding of bzr internals might want to tackle ;(
[12:13] <jelmer> yacc: not really, though it should be possible to get that "not present in "... error fixed
[12:13] <jelmer> I'll see if I can fix that
[12:14] <rexbron> hey everyone, the docs on this function are a little bit unclear in what order the branch and tree objects are returned
[12:14] <rexbron> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_tree_or_branch
[12:14] <rexbron> I think it is mentioned at the end, but I am still unsure
[12:15] <jelmer> rexbron: tuple with tree and branch
[12:15] <rexbron> jelmer: K, it mainly that the other funtions make that more clear
[12:16] <bob2> the first sentence should be fixed then
[12:17] <yacc> How do I undo local commits?
[12:17] <rexbron> yacc: bzr uncommit?
[12:17] <rexbron> or revert
[12:18] <rexbron> bob2, jelmer: I think it should be changed to something like the method below: Returns (tree, branch)
[12:18] <bob2> famen
[12:18] <bob2> tr -d f
[12:19] <spiv> yacc: in bzr.dev, "bzr uncommit --local"
[12:19] <spiv> I don't think that's in a release yet, though :(
[12:19] <yacc> spiv: Well, uncommit seems to have worked :)
[12:19] <james_w> rexbron: tree will be None if there isn't one if you hadn't figured that out yet.
[12:20] <spiv> yacc: oh good :)
[12:20] <rexbron> james_w: I think I need to refresh exactly what the difference between a branch on the file system and a workingtree (beyond different methods for those objects)
[12:20] <james_w> rexbron: i see ":return: (tree, branch)" for that method
[12:20] <james_w> rexbron: you can have a branch with no tree
[12:20] <james_w> i.e. you have .bzr/branch/
[12:21] <james_w> but there are no files in the working directory, and there will be no .bzr/checkout/
[12:21] <rexbron> james_w: My comment was that it could be more clearly stated, like in the other functions
[12:21] <rexbron> james_w: ok
[12:21] <james_w> you can get this with bzr remove-tree, or with a treeless repository
[12:21] <bob2> james_w: the furst sentence says the opposite, and I don't think it's unreasonable to assume that it should be correct also :-)
[12:21] <james_w> and it will also happen for remote trees.
[12:21] <james_w> bob2: that's true
[12:21] <james_w> rexbron: that is markup that used to denote the return value.
[12:22] <rexbron> james_w: is the doc system supposed to format it differently that it currently is?
[12:22] <james_w> ah, it appears to be spelt wrong, as other functions have it formatter
[12:23] <james_w> see open_containing_from_transport
[12:24] <rexbron> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_repository seemes to also have a formatting issue
[12:24] <rexbron> for :param _unsupported:
[12:26] <rexbron> now that I look for it, I see a lot of method docs that are (perhaps) not formatted correctly
[12:26] <james_w> yeah, they do seem to be a bit bad.
[12:27] <james_w> the API documentation is very hit and miss
[12:29] <rexbron> james_w: what system is being used, as I would be happy to submit patches
[12:30] <rexbron> ok, looks like pydoctor
[12:31] <sabdfl> is mail from the bazaar list getting doubled up?
[12:32] <yacc> :)
[12:33] <james_w> sabdfl: I don't see it, you mean you receive multiple copies?
[12:34] <rexbron> Is there a page which documents the syntax for pydoctor? or is it the same as something else?
[12:34] <james_w> rexbron: I think it uses the pydoc ones or whatever they are.
[12:35] <james_w> rest markup in python docstring might get you some useful pages from google.
[12:35] <sabdfl> james_w: yes, i do get multiple copies
[12:35] <sabdfl> peregrine% ./bzr pull
[12:35] <sabdfl> Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/
[12:35] <sabdfl> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/".
[12:35] <sabdfl> anybody know what would cause this?
[12:36] <sabdfl> when I go to that URL I see the loggerhead page
[12:36] <spiv> sabdfl: you're using bzr.dev
[12:36] <james_w> sabdfl: I think the default is for the list software not to forward it's copy to you if you are already in the to list, but it sounds like it's all mail.
[12:36] <spiv> sabdfl: the fix is on the list
[12:36] <sabdfl> ok thanks spiv
[12:36] <spiv> sabdfl: the bug is 207558
[12:36] <spiv> ubotu: bug 207558
[12:36] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
[12:42] <rexbron> hmm, I can not seem to find what markup syntax bzr is using to generate the api docs
[12:42] <rexbron> pydoctor's site does not really mention anything
[12:43] <spiv> rexbron: epydoc
[12:43] <bob2> epydoc
[12:43] <spiv> (the ReST variant of it, IIRC)
[12:48] <james_w> rexbron: http://epydoc.sourceforge.net/manual-epytext.html
[12:48] <rexbron> james_w:
[12:48] <james_w> but it uses : to start, rather than @
[12:48] <rexbron> ya, I found that
[12:48] <james_w> it is the rest variant it uses, but that seems to suggest other markup.
[12:49] <rexbron> From a quick look, the reason some is being formatted correctly and others not is a lack of a blank line
[13:10] <schierbeck> jelmer: i've made the bugs tab look good: lp:~dasch/bzr-gtk/revisionview-bugs-page
[13:10] <schierbeck> what do you think?
[13:16] <jelmer> schierbeck: yeah, that's definitely an improvement
[13:17] <jelmer> hmm, the bug isn't clickable anymore
[13:17] <schierbeck> try double-clicking
[13:17] <schierbeck> i'll fit a button in there
[13:17] <schierbeck> for now, i removed the status string, since "fixed" is the only one supported...
[13:18] <jelmer> double-clicking doesn't work
[13:19] <jelmer> schierbeck: I'd rather keep it in there and make the message say something like "This revision changes the affects one or more bugs."
[13:19] <schierbeck> jelmer: the status message?
[13:20] <schierbeck> i think we should only do that when bzr supports more than one type
[13:20] <jelmer> yeah, or otherwise we should be making sure the status message == "fixed"
[13:20] <schierbeck> i could do that
[13:20] <jelmer> otherwise if bzr supports more than one type in the future, users will get very confusing errors
[13:22] <schierbeck> jelmer: okay
[13:23] <schierbeck> jelmer: i think the bugs tab should always be visible
[13:24] <schierbeck> it's pretty confusing when ui elements magically appear on the screen
[13:26] <jelmer> I'd be fine with having it insensitive
[13:26] <jelmer> if there are no bugs
[13:26] <jelmer> but one of the nice things now is that you don't actually have to switch to the bugs tab to see if a revision touches any bugs
[13:26] <schierbeck> okay
[13:26] <schierbeck> jelmer: the same thing applies for signatures
[13:27] <schierbeck> but if the user is not able to open the tab, he may think that he needs to install something
[13:30] <jelmer> schierbeck: Alternatively, we could show an icon in the branchview to indicate a revision touches bugs
[13:30] <schierbeck> jelmer: just my thought
[13:31] <schierbeck> i just need a smaller icon then
[13:31] <schierbeck> currently i just copy-paste from the shared icons i've got lying around...
[13:31] <schierbeck> hope i don't get in any trouble
[13:32] <jelmer> schierbeck: yeah, we need to check what the license on those icons is..
[13:33] <schierbeck> i'll get on it before we release, but most likely it won't be an issue
[13:34] <ignas> are there any documents on how to solve permission problems with shared repositories? i have a group stbaz that can commit to the shared repository, but it seems that after bzr push'es or bzr commits from a lightweight repos using sftp
[13:34] <ignas> some files get owned by my user
[13:34] <ignas> both as a user and as a group
[13:35] <Invisionfree> Hi, I was just wondering, does BZR work with Kerberos?
[13:36] <bob2> it doesn't have specific kerberos support, afaik, but it would work with kerberised ssh
[13:37] <jelmer> yeah, I used it with kerberized ssh without problems
[13:38] <jelmer> kerberized ftp is not supported yet though (kerberized sftp should be fine)
[13:39] <james_w> ignas: have you set g+s on the directories?
[13:40] <ignas> yes, it seems so
[13:40] <ignas> let me check
[13:40] <schierbeck> jelmer: okay, i've pushed the changes to lp
[13:41] <james_w> ignas: there's also a limitation of sftp in this area, bzr+ssh will serve you better.
[13:41] <ignas> james_w: oh, i see, do i need to do something special? or just replace sftp with bzr+ssh and that's it?
[13:42] <james_w> ignas: you need bzr installed on the server
[13:42] <james_w> but otherwise probably not
[13:42] <ignas> i see
[13:42] <james_w> (the exception would be if you had bzr installed somewhere outside the $PATH on the server)
[13:42] <ignas> it's in $PATH
[13:43] <ignas> by the way - is there a way to get something like a lightweight checkout
[13:43] <ignas> that would not need network connection
[13:43] <ignas> for bzr status or bzr diff
[13:43] <james_w> bzr checkout --lightweight
[13:43] <ignas> i am using --lightweight
[13:44] <ignas> but every operation like bzr st or bzr diff seems to be connecting to the server
[13:44] <james_w> oh, not need network connection, sorry.
[13:44] <bob2> that's the 'lightweight' - most stuff is on the server
[13:44] <Peng> s/most/all/.
[13:44] <james_w> you can use a normal, non lightweight, checkout.
[13:44] <ignas> well - i want a compromise
[13:45] <ignas> something that is not 70mb
[13:45] <ignas> and does not need network to tell if i have changed a file
[13:45] <ignas> like with svn ;)
[13:45] <james_w> that puts all of the data on your local disk, but pushes it to the server when you commit, so you only need network access for write operations.
[13:45] <Peng> ignas: There is nothing like that yet.
[13:46] <ignas> i see
[13:46] <ignas> :/
[13:46] <Peng> ignas: All or nothing.
[13:46] <ignas> ouch
[13:46] <bob2> how far along are lifeless's shallow branches?
[13:46]  * Peng points out that 70 MB isn't huge.
[13:46] <james_w> bob2: quite close I think, it's just a case of making everything "stackable-on"
[13:47] <james_w> the smart server for one thing I think
[13:47] <bob2> ah
[13:47] <bob2> hopefully 1.4 then
[13:48] <jelmer> schierbeck: I think the message in the bugs tab should say "This revision fixes one or more bugs." since we're not showing the status anymore
[13:48] <abentley> bob2: They aren't shallow branches.
[13:49] <schierbeck> jelmer: i'm editing it as we speak :)
[13:49] <bob2> abentley: oh
[13:49] <abentley> They're not intended to allow you to work when the source branch is unavailable.
[13:50] <bob2> ah
[13:50] <schierbeck> jelmer: should we use "fixes" or "claims to fix"?
[13:50] <abentley> Stacked branches are mostly a storage optimization.
[13:51] <bob2> sounds about equivalent to co's bound to a shared repo?
[13:52] <schierbeck> jelmer: for now i'll go with "claims to fix", as we don't really know
[13:54] <abentley> Well, stacked could let you create a checkout of emacs without downloading all its revisions.  And diff/status would be zippy.  But log would not be.
[13:56] <bob2> ah, of course
[14:04] <jelmer> schierbeck: yeah, claims to fix sounds fine
[14:06] <abentley> In a true shallow checkout, non-local revisions would be handled as ghosts, so log would be speedy but short.
[14:07] <bronger> Is "bzr branch" identical to "bzr init" + "bzr pull"?
[14:11] <fog> re
[14:12] <TFKyle> bronger: I wouldn't think so, but I could be wrong
[14:21] <gioele> hello
[14:21] <bronger> The background of my question is: If I want to update a remote SVN repo, I can create a branch of it locally, merge the new changes and pull it back.  Would it be different in any way if I pulled it to an empty revisioned directory first?
[14:22] <bronger> Sorry "... push it back"
[14:28] <gioele> what is a "submit branch"?
[14:28] <gioele> is it another name for a "push branch"?
[14:31] <bronger> gioele: It may also mean a commit in the branch is bound.
[14:32] <bronger> "... if the branch is bound"
[14:33] <gioele> bronger: bzr info in a bound branch (a checkout) says
[14:33] <gioele> Location:
[14:33] <gioele>   light checkout root: .
[14:33] <gioele>    checkout of branch: http://...
[14:33] <gioele> is that the submit branch?
[14:35] <james_w> bronger: init + pull is the same as branch, yes.
[14:36] <gioele> ah, the submit branch is the location where "bzr send" sends changes
[14:43] <bronger> james_w: Thank you!
[14:45] <gioele> is there a revspec with the meaning "last time it was changed"?
[14:45] <gioele> For example, current revision is 20 and file foo has been modified at revision 12 and 8. Is there a revspec that I can use instead of 12 and 8 in "bzr diff -r 8..12 foo"
[14:46] <Peng> That would be useful, but I don't know of one.
[14:46] <Peng> The docs list all the types of revspecs.
[14:46]  * Peng goes back to bed.
[14:47] <schierbeck> jelmer: ping
[14:47] <jelmer> schierbeck: pong
[14:47] <schierbeck> jelmer: do you think we should rename the "Signature" tab to "Authenticity"?
[14:47] <james_w> gioele: I don't think there is one.
[14:47] <schierbeck> after all, that's really all it's about
[14:49] <jelmer> schierbeck: We need to verify the testament first
[14:49] <jelmer> schierbeck: but otherwise, sounds fine to me
[14:51] <schierbeck> jelmer: yeah, i was gonna ask that, too
[15:10] <antoranz> Hi, guys!
[15:11] <mw-home> morning
[15:11] <antoranz> I was merging the changes from another branch yesterday (both local FS branches) and I got an error and don't know if It's a bug in bazaar
[15:12] <antoranz> I had made a post in linuxquestions but nobody replyed to it, that's why I looked if there was an IRC channel... and so I'm here.
[15:13] <gioele> antoranz: link?
[15:13] <antoranz> the post is here: http://www.linuxquestions.org/questions/linux-software-2/problem-with-bazaar-632262/
[15:13] <bob2> in future, I'd say that posting to the list is a lot more likely to find someone who knows bzr thatn linuxquestions :)
[15:13] <gioele> list = mailing list on bazaar-vcs.org
[15:14] <antoranz> k
[15:14] <bob2> someone reported almost that exact error yesterday
[15:14] <bob2> bzr in gutsy?
[15:14] <antoranz> mmm........... yes, it's gutsy
[15:16] <gioele> I think this deserves a bug at https://bugs.launchpad.net/bzr/+filebug
[15:17] <james_w> there's already a bug for it I think
[15:18] <bob2> try upgrading (add 'deb http://ppa.launchpad.net/bzr/ubuntu gutsy main' to /etc/apt/sources.list, 'sudo aptitude update', 'sudo aptitude dist-upgrade')
[15:18] <james_w> I don't think it's fixed
[15:18] <bob2> ah, ok
[15:19] <bob2> I forget the conversation yesterday, but did -q workaround?
[15:19] <antoranz> what's the problem? My use of "á" in the directory name or something?
[15:19] <antoranz> cause I haven't had a problem so far with it in the branch where I created it committing to it.
[15:20] <antoranz> is that repository stable?
[15:21] <james_w> bob2: I think this is a different location to yesterday's
[15:22] <james_w> https://bugs.edge.launchpad.net/bzr/+bug/135320
[15:22] <ubotu> Launchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New]
[15:23] <antoranz> I'll append my info to that bug.
[15:28] <antoranz> The bug a little old though
[15:29] <antoranz> anyway... I've already appended my trace to it.
[15:30] <gioele> How do you debug bzr plugins?
[15:30] <gioele> Is there a way to make the plugin hook the eric debugger at a certain point? Any other IDE is OK
[15:31] <antoranz> I'll try changing the name of the directory to see what happens
[15:32] <antoranz> F***! It failed when I tried to commit the mv
[15:33] <antoranz> all I did was: $ bzr mv doc/Cities/Bogotá/ doc/Cities/Bogota
[15:38] <ignas> Peng: by the way - if 70 mb is not much, why is it taking ~30 minutes or more tu make a branch :/ how long does it take with "much" ;)
[15:39] <james_w> antoranz: can you pastebin the traceback you get for that please?
[15:40] <james_w> gioele: what I normally do is edit the source and add "import pdb; pdb.set_trace()" where I want it
[15:40] <james_w> if the problem is a plugin not loading then ~/.bzr.log will have the error.
[15:40] <antoranz> sure
[15:41] <gioele> james_w: is there an API documentatio for bzrlib?
[15:41] <antoranz> I'm filling for a new bug including both bugs in https://bugs.launchpad.net/bzr/+filebug. Want to see it?
[15:41] <james_w> gioele: sort of yes
[15:42] <antoranz> Here it is: https://bugs.launchpad.net/bzr/+bug/210838
[15:42] <ubotu> Launchpad bug 210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New]
[15:42] <james_w> http://starship.python.net/crew/mwh/bzrlibapi/
[15:42] <antoranz> that was fast! :-D
[15:42] <james_w> there's also http://bazaar-vcs.org/Integrating_with_Bazaar
[15:43] <james_w> antoranz: he responds to what you say
[15:43] <james_w> they'll be the new bug notification in a minute or two
[15:44] <bob2> ignas: btw, cp -r is a valid way to branch a standalone branch to anothoer standalone branch
[15:45] <ignas> bob2: i know, but cp -r does not work if your branch is on launchpad
[15:45] <bob2> ah
[15:45] <antoranz> ignas: that was good!
[15:51] <ubotu> New bug: #210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New] https://launchpad.net/bugs/210838
[15:55] <antoranz> I'll try the repository you provided mye with... hold on to your butts. :-)
[15:58] <antoranz> hell! I tried to commit just like that and it "added" the directory (didn't move it)
[15:59] <antoranz> I just checked the repository and I have 5 inconsistent parents
[16:00] <antoranz> how do I get rid of those "parents"?
[16:05] <schierbeck> jelmer: what do you think about a "Tags" page in the revision view? i think it would boost the discoverability.
[16:05] <schierbeck> i know they belong in the branch, but to the user who wants to add a tag to a revision, it's natural to select that revision in the viz and go from there.
[16:06] <jelmer> schierbeck: tags are already shown in the revisionview, in the main tab
[16:06] <schierbeck> jelmer: yeah, but i'm thinking more like a treeview, where you can "rename" and add tags
[16:07] <antoranz> can I delete .bzr/branch/lock so I get rid of the lock on the repository?
[16:07] <schierbeck> jelmer: the current ui doesn't allow for deleting tags in the revisionview
[16:07] <antoranz> I've already done it, so I think it's safe, right?
[16:08] <jelmer> schierbeck: yeah, makes sense
[16:08] <schierbeck> jelmer: let's get the bugs and signature page branches merged first, then i'll refactor the revision view and go from there
[16:09] <abentley> antoranz: You're supposed to use the bread-lock command.
[16:09] <schierbeck> jelmer: do you think there's anything missing from those two branches? i've already sent a mail to the tag icon artist
[16:10] <antoranz> I've should know better, wasn0't I? after I removed the lock (by deleting, by the way :(), I was able to commit into the stable branch even with the names with non-ascii characters
[16:10] <antoranz> my godness... what a gramatical mess did I write! :-D
[16:10] <jelmer> schierbeck: the signatures branch disables the signature tab
[16:10] <jelmer> schierbeck: but that still says "this revision has one or more signatuers"
[16:11] <schierbeck> schierbeck: huh?
[16:11] <jelmer> schierbeck: that's all I can think of right now
[16:11] <schierbeck> jelmer: the seahorse-integration branch?
[16:11] <schierbeck> i think that's the one we should ship
[16:17] <antoranz> I think my repository got completely busted (both the stable and the development one... as a matter of fact, I deleted the developemt one and can't branch from the stable)
[16:18] <antoranz> I just noticed I lost quite some hours of work goys
[16:20] <antoranz> say-.... 2 days of work
[16:21] <kohwj> hi, can i get bzr serve to prompt clients for a password?
[16:23] <antoranz> there's something strange going on here.
[16:24] <antoranz> I was able to commit the changes brought from the development branch in the stable branch.... I can see the diffs applied
[16:25] <antoranz> however, there are not "efective" in the physical files of the stable repository
[16:25] <antoranz> they, I mean
[16:46] <schierbeck> jelmer: okay, i've sent in the merge requests
[16:47] <schierbeck> once they're approved, i'll start refactoring the revision view
[16:48] <gioele> schierbeck: olive? gtk?
[16:49] <schierbeck> gioele: bzr-gtk
[16:49] <schierbeck> the bottom part of the viz
[16:50] <gioele> I love viz
[16:51] <gioele> How do I get the arguments passed to bzr from my RevisionSpec?
[16:52] <ignas> why is bzr push to a remote repository is a mega pain? and what should I do instead?
[16:53] <snod> unter linux siehts auf jeden fall anders aus
[16:53] <snod> fc
[16:53] <ignas> i checkout the "trunk", checkout the branch, bzr merge the branch into the trunk, and am trying to bzr push the mainline back so everyone (especially our mega release tools) would see the changes...
[16:53] <ignas> bzr push seems to be taking ages
[16:54] <ignas> even though there was only 1 small change made to the trunk
[16:58] <bob2> are they the same branch formats (should be unless you use a shared repo)
[16:58] <ignas> hmm, ok it seems that it was taking so long because it was synchronizing the fact that i have enabled tags on the remote repository
[16:58] <ignas> i am using a shared repository
[16:59] <ignas> for my remote branch
[16:59] <ignas> because all the release branches will be stored in the same location
[16:59] <ignas> but yes, now that the first push got through it is bearable (takes only 10-20 seconds)
[17:02] <ignas> what can I do about "Value "bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/" is masked by "bzr+ssh://bazaar.launchpad.net/%7Eignas/schooltool/lyceum/" from locations.conf"?
[17:03] <ignas> and where is that locations.conf thing?
[17:03] <ignas> i have tried doing "bzr push --remember bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/"
[17:06] <gioele> ~/.bazaar/locations.conf
[17:07]  * gioele wonders when bzr will conform to XDG Base Dir spec
[17:08] <ignas> emm, why is it there? and why is it overriding parameters i am passing through command line?
[17:08] <ignas> i mean - maybe there is a reason, and i am doing something wrong...
[17:08] <gioele> that file is used for the parameters that you didn't specify on the cmd line
[17:09] <ignas> so when i do "bzr info"
[17:09] <ignas> paths are taken from that file
[17:09] <ignas> not from some place in .bzr ?
[17:09] <luks> ignas: old branch formats used to save it to locations.conf, new formats use .bzr/branch/branch.conf
[17:09] <ignas> oh, i see
[17:09] <ignas> so i should upgrade my branch and remove that file?
[17:10] <luks> if it was complaining about masked location, your branch is probably already upgraded
[17:10] <luks> you can just remove the branch from locations.conf
[17:11] <ignas> ok
[17:24] <schierbeck> jelmer: ping
[17:24] <jelmer> schierbeck: hi
[17:25] <schierbeck> jelmer: i've got permission to use the tag icon
[17:25] <jelmer> cool
[17:25] <schierbeck> can i get you to review the merge request?
[17:25] <jelmer> yeah, just give me a few minutes
[17:25] <schierbeck> okay
[17:27] <ignas> how do i convert a branch into a checkout?
[17:28] <schierbeck> ignas: bzr help bind
[17:29] <ignas> schierbeck: thanks
[18:21] <eddyMul> how do I "un-add" files?
[18:26] <antoranz> revert
[18:26] <eddyMul> antoranz: ah! thanx!
[18:26] <antoranz> if you haven't commited
[18:27] <eddyMul> antoranz: no, I haven't.  :)
[18:28] <antoranz> there you go then.
[19:00] <gioele> hello
[19:01] <gioele> does the mailing list accept mails from Gmane?
[19:16] <ubotu> New bug: #210938 in bzr "bzr status -v should show also non-modified files" [Undecided,New] https://launchpad.net/bugs/210938
[19:29] <james_w> gioele: I don't know. The list is moderated, so it might be that.
[19:36] <gioele> james_w: no, it passed fine. Maybe Gmane is a bit slow today
[19:39] <james_w> ah, ok
[20:02] <bialix> hi, I have question about merge.py
[20:05] <bialix> abentley, may I ask you about merge.py?
[20:05] <abentley> Sure.
[20:06] <bialix> there is Merger, Merge3Merger and others
[20:06] <bialix> it seems like Merger is main of them
[20:06] <bialix> it's correct?
[20:06] <abentley> Yes.  It's been suggested that Merger should be renamed to MergeController.
[20:07] <bialix> so, it's always created Merger instance for merge operations?
[20:08] <abentley> Yes.  It's not required, but I believe all callers do go through Merger.
[20:08] <bialix> my actual question is: where I should put my code for support merge of file properties
[20:09] <bialix> is it Merger correct place, or Merge3Merger?
[20:09] <abentley> Probably in Merge3Merger.
[20:09] <bialix> i.e. actual merge done in Merge3Merger, right?
[20:10] <abentley> Yes, the actual operation is handled by Merge3Merger or a subclass.
[20:11] <bialix> all other merge types is subclased Merge3 as I could see.
[20:11] <abentley> Right.
[20:11] <bialix> okay, thank you.
[20:12] <abentley> np
[20:17] <Verterok> moin
[20:19] <abentley> eddyMul: More specifically, you use "bzr remove --keep --new".  That will avoid reverting any other changes.
[20:23] <eddyMul> abentley: I used `bzr revert specific_files`, and it worked for me.
[20:24] <eddyMul> abentley: judging from `bzr help remove`, it appears like `bzr remove --keep --new` is the like the "anti" of `bzr add`. Very handy. Thanx!
[20:24] <abentley> np
[20:31] <james_w> hi bialix, Verterok
[20:32] <bialix> hi james_w
[20:32] <james_w> bialix: sorry I haven't had a chance to look over your file properties mail yet
[20:33] <bialix> it seems like nobody have this chance yet
[20:33] <bialix> there was a lot of people who cry without line-endings support
[20:33] <Verterok> james_w: hi
[20:33] <james_w> bialix: yeah, it would be great to have.
[20:34] <bialix> they already worked
[20:36] <bialix> I need only to beat merge and to teach it write files to disk with proper eol
[20:39] <bialix> abentley: Merge3Merger.__init__: has arguments working_tree, this_tree, base_tree, other_tree -- what's difference between working_tree and this_tree? it's not the same?
[20:41] <abentley> this_tree is the input tree that you read from in order to calculate the merge.  working_tree is the output tree that you write the changes to.
[20:41] <abentley> They are commonly the same, but this_tree is sometimes a RevisionTree.
[20:42] <bialix> in which case?
[20:46] <bialix> I see in constructor's code:         self.this_tree = working_tree
[20:46] <bialix> and it seems like this_tree argument is not used actually
[20:46] <bialix> so I'll ignore it.
[20:49] <abentley> Don't be a jerk.
[20:55] <james_w> abentley: as far as I can see the "this_tree" argument to Merge3Merger is not used in Merge3Merger.__init__, and none of the subclasses in the same file override __init__.
[20:55] <db-keen> Why can't I bzr mv from one branch in a repository to another?
[20:56] <james_w> so is it just there in case a subclass wants to?
[20:56] <mwhudson> db-keen: because bzr is not like subversion?
[20:56] <abentley> james_w: WeaveMerger used to do that, and future mergers may also do that.  It's quite likely to be a performance win.
[20:56] <james_w> ah, ok, thanks
[20:56] <poolie> db-keen: well it's more complicated for us than for svn
[20:56] <poolie> we should make it possible
[20:56] <gioele> is there a way to have "external" branches inside a branch?
[20:57] <james_w> abentley: I think your reaction might have been a bit strong then, but maybe I misread it
[20:57] <db-keen> I'm trying to take a project and split it into smaller branches, what's the best way to do this?
[20:58] <james_w> db-keen: are you splitting on directory boundaries?
[20:58] <abentley> james_w: If writes to this_tree or reads from working_tree, I'll veto his patch so fast his teeth will shake.
[20:58] <db-keen> my initial reaction was to create new branches and move stuff from the old large one into these new small ones, but obviously that doesn't work
[20:58] <db-keen> james_w: mostly
[20:59] <james_w> db-keen: there's a split command that may help
[20:59] <james_w> abentley: but the default mergers read from working_tree?
[20:59] <abentley> No
[20:59] <abentley> They read from this_tree
[21:00] <james_w> abentley: they read from self.this_tree, which working_tree is assigned to in the constructor
[21:01] <abentley> which is entirely different.
[21:02] <poolie> thumper: hi, are we meeting now?
[21:02] <thumper> poolie: yeah
[21:02] <james_w> abentley: well, I don't still fully understand, even with the extra discussion, so I still think your response was too strong.
[21:06] <abentley> james_w: think what you like.  When people ask me for advice, I expect them not to ignore it.
[21:08] <dato> james_w: I guess that the API/contract is that you read from this_tree, without caring what gets assigned to it before. or so. from my limited understanding. :)
[21:08] <abentley> They may decide that they don't agree, or that it doesn't apply.  But it's not okay if they just ignore it.
[21:09] <james_w> I read his statement as ignoring this_tree, just like the existing code does, not ignoring your answer, but I don't know what he meant
[21:10] <abentley> The existing code does not ignore this_tree.
[21:14] <james_w> maybe I am wrong to say ignore, but the this_tree parameter passed to Merge3Merge.__init__ is unused as far as I can see. This may well be because working_tree fulfils the contract of this code just as well as this_tree.
[21:20] <abentley> We're not talking about constructors, so when you say this_tree, I assume you mean self.this_tree
[21:23] <james_w> sorry for the misunderstanding then, I tried to be clear that I was talking about this_tree passed to the constructor as opposed to self.this_tree
[21:25] <abentley> So it looks like the Merge3Merge constructor is a bit broken.
[21:26] <hmeland_> Regarding the "fix botched log-message" discussion: Does any of the storage mechanisms actually have an API for "turn revision X into a ghost"?
[21:26] <abentley> It's probably due to the shuffling around we did to enable merge previews.
[21:26] <abentley> hmeland_: No, all of our formats are append-only.
[21:27] <abentley> You would need to create a new repository, and not add those revisions.
[21:27] <hmeland_> Right.
[21:32] <hmeland_> In principle you could repair revision X by adding a X' (which has X and the parent(s) of X as its parents) with the fix, convert X into a ghost, and repeat for all revisions that are descendants of X.
[21:33] <hmeland_> But without an easy way to do the "convert X into a ghost" step, that sounds somewhat cumbersome.
[21:35] <hmeland_> The approach might also have bad (performance) implications for e.g. merge, especially if such fixing were to be as common as I gather git's "commit --amend" is.
[21:37] <james_w> "commit --amend" only works for the tip of the branch, and is another form of rebase.
[21:37] <hmeland_> Ah, good.
[21:38] <james_w> I think there are two cases being discussed, one is the "nuclear launch codes" and the "abusive commit message" case, and the other is the "spelling mistake case"
[21:39] <dato> "abusive commit message"?
[21:39] <james_w> the latter could be solved by just adding a note somewhere saying "when displaying it, set the message of X to Y"
[21:39] <james_w> dato: it's an example from the list of where there was evidence of sexual harrasment in a commit message.
[21:39] <dato> oh, wow, I missed that
[21:40] <hmeland_> james_w: I think *abusive* commit message is a form of nuclear launch codes, actually.
[21:40] <james_w> hmeland_: yes, it is, but I was just using the two examples from the list discussion.
[21:40] <hmeland_> OTOH, an *incorrect* commit message might be solvable in the way you describe.
[21:41] <james_w> for the former you need to remove X from history so that it is unreachable.
[21:41] <james_w> so this could either be a rebase type operation, or introducing a ghost, both of which have their issues.
[21:42] <hmeland_> Yes.  Both NLC and ACM goes in the former category, to my mind.
[21:43] <hmeland_> The nice thing about the ghost-introduction solution is that other existing branches would still be related to the original branch.
[21:43] <james_w> exactly
[21:44] <hmeland_> You might have to take care that merges from any such branches didn't re-introduce the ghosted revisions, though.
[21:44] <james_w> however, currently ghosts have no information whatsoever, not even their parents, which means that you can't get at the history previous to the ghost.
[21:45] <james_w> and it would also be information disclosure, which some people in some circumstances wouldn't accept.
[21:46] <hmeland_> If you branched from revision Y, which has now been converted into a ghost, there will be a new revision Y' in the source branch, whose mainline history will take you all the way back to before the fixed revisions.
[21:47] <james_w> hmeland_: no, when you branch you are based of Y still
[21:47] <james_w> it's not like svn where you have to make a commit to start a branch.
[21:47] <james_w> but you are right, I think care would have to be taken not to get unwanted ghosts again when merging.
[21:47] <hmeland_> Yes, that's what I'm saying.  In the *source* branch there will be a Y'.
[21:48] <james_w> hmeland_: ah, in your proposal for creating Y' from Y, sorry
[21:49] <james_w> there would be the peverse case where you made Y a plain ghost, as now you can't do 3 way merging as you can't get the text from the base revision.
[21:52] <lifeless> hmeland_: the conversion of X's descendants to X''s descendants will not propogate
[21:52] <hmeland_> james_w: Right, you'd have to pull before merging, I think.
[21:53] <hmeland_> lifeless: In the case of multiple fixes, you mean?
[21:54] <hmeland_> X' will have (X + parents(X)) as parents.  X'' will have (X' + parents(X')) as parents.
[21:54] <james_w> hmeland_: you can't pull before merging, if you have diverged then pulling is not allowed.
[21:54] <james_w> hi lifeless
[21:54] <lifeless> hi james_w
[21:55] <lifeless> hmeland_: no, I mean in the case of having more than one repository which needs the correction done
[21:55] <lifeless> hmeland_: all other repositories will have the original X as their semi-ultimate descendant
[22:00] <hmeland_> Not X, but the tip of the branch X was in when X was fixed, I think?
[22:00] <hmeland_> But yes, ghosts do not propagate.
[22:04] <schierbeck> jelmer: ping
[22:04] <jelmer> schierbeck: pong
[22:05] <schierbeck> I've fixed the remaining issues with the Seahorse integration branch, and I've sent in an updated merge request. Could I get you to take a look at it?
[22:11] <lifeless> hmeland_: and neither does the conversion to 'fixed' revisions, only the ones actually fixed will propogate
[22:15] <schierbeck> wow, apparently you can be allergic to electricity...
[22:15] <schierbeck> that's pretty f****d up!
[22:17] <jelmer> schierbeck: Iyou don't appear to be catching the errors if there is no seahorse interface
[22:19] <schierbeck> jelmer: have you tested it? i check for the seahorse service name
[22:19] <schierbeck> if seahorse is installed, the object paths and interfaces should be there
[22:19] <schierbeck> it worked when i uninstalled seahorse...
[22:20] <hmeland_> lifeless: Assuming a mainline-only history: If you actually fix revision 2 by introducing 2' (with 2 (now ghosted) and 1 as parents), and "fix" revision 3 by introducing 3' (with 3 (now ghosted) and 2' as parents), wouldn't a branch at e.g. 3 doing a pull cause both 2' and 3' to propagate?
[22:20] <jelmer> schierbeck: ah, I missed that - sorry
[22:20] <schierbeck> jelmer: :)
[22:20] <jelmer> schierbeck: any chance you can make two more changes?
[22:21] <jelmer> schierbeck: I'll reply to the email
[22:21] <schierbeck> jelmer: which?
[22:21] <schierbeck> ok
[22:27] <lifeless> hmeland_: a new branch from 3' will take 3' of course. But *all* the other existing branches won't be fixed.
[22:28] <james_w> I think the suggestion is to mark some ghosts as propagating, so the next merge or pull will fix them
[22:30] <hmeland_> james_w: That's not what I'm suggesting; I'm just trying to understand if the algorithm I suggested above might be a viable starting point for the requested functionality.
[22:31] <james_w> ah, ok, sorry
[22:31] <lifeless> the general thing here is that revisions are immutable
[22:32] <lifeless> having efficient, safe trustable mutable revisions is possible, buts its a lot of complexity
[22:32] <lifeless> you basically need a meta-timeline for versioning revisions too
[22:32] <hmeland_> If you the requires-fixing revision is present in branches you don't control, I'm leery of trying to propagate the fix to them automatically.
[22:37] <hmeland_> lifeless: Yeah.  So I'm trying to see whether the "convert to ghost and add alternative timeline" approach could get us at least some of the benefits without all the complexity.
[22:40] <hmeland_> Anyway, thanks for the input, I guess I'll sleep on it and see if I can come up with something.
[22:52] <xma> 'lo #bzr
[22:55] <lifeless> hi
[22:55] <schierbeck> jelmer: okay, i've sent in yet another iteration
[22:56] <schierbeck> i've also contacted the author of the bug icon
[23:02] <jelmer> schierbeck: ah, thanks
[23:02] <jelmer> schierbeck: (wasn't strictly necessary btw, I voted bb:tweak)
[23:04] <xma> is it me or the proportion for BB to be unavailable is increasing day after day ?
[23:05] <jelmer> it's been months since I've seen bundlebuggy downtime for bzr.dev
[23:14] <igc> morning
[23:15] <yacc> Hmmm, does anyone maintain a bzr branch of the current Python code?
[23:15] <yacc> I'm not completly sure if branching the svn URL would be a very enjoyable experience.
[23:17] <jelmer> yacc: it's not too bad with 0.4.9
[23:20] <radix> yacc: you mean CPython? I'm pretty sure I've heard others talking about such a thing, but I'm not sure where.
[23:20] <mwhudson> yacc: you mean like http://www.python.org/dev/bazaar/ ?
[23:25] <yacc> jelmer: you are trying to sell me on going back to using a released version of bzr-svn ;)
[23:26] <jelmer> yacc: :-)
[23:26] <jelmer> yacc: If performance or reliability matters to you, you should be using a release
[23:26] <jelmer> performance certainly matters for the python repo, given its size
[23:26] <yacc> jelmer: does it support bzr 1.3?
[23:26] <jelmer> yacc: yep
[23:27] <yacc> jelmer: And I ended up using a trunk scheme, so I guess this should work too?
[23:27] <bob2> yacc: http://www.python.org/dev/bazaar/
[23:28] <jelmer> yacc: yep
[23:28] <bob2> oh, oops, too slow
[23:37] <mwhudson> bob2: well, maybe he'll tell _you_ why that isn't what he wants :)
[23:45] <jelmer> bob2: what's too slow?


[00:05] <micahg> asac: ^^^
[00:06] <micahg> fta: are you going to file the request for another lpia builder or shoudl I?
[00:07] <fta> micahg, please do, i was about to leave
[00:07] <micahg> fta: k, have a good night
[00:07] <fta> thanks
[00:07] <fta> btw, i've committed the apport hooks to the daily branch
[00:08] <fta> will need more testers, esp on stable releases
[00:08] <micahg> fta: cool, thanks
[13:22] <chrisccoulson> asac - i noticed you're still assigned to mozilla bug 467766. are you planning to add a test-case for that patch, or do you want me to take that?
[13:22] <ubot2> Mozilla bug 467766 in Preferences: Backend "user settings for pref keys with defaults in extension get reset on upgrade" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=467766
[13:23] <chrisccoulson> asac - same question for mozilla bug 460917 too :)
[13:23] <ubot2> Mozilla bug 460917 in Plugin Finder Service "New plugins only recognized after restarting Firefox" [Major,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=460917
[14:34] <fta2> chrisccoulson, hi, if you have time, could you please test my apport hooks in the latest chromium? (python /usr/share/apport/package-hooks/chromium-browser.py)
[14:35] <chrisccoulson> fta2 - yeah, sure. is there anything in particular you want me to test for?
[14:49] <fta2> chrisccoulson, well, no assert, for one. and if the reported info match what you have, and if possible, ch v6
[14:50] <fta2> i expect a few minor adjustments are needed
[15:59] <fta> micahg, did you file the request for more lpia builders?
[16:00] <micahg> fta: yeah, the queue is under 24 hours, so the builds should finish today
[16:00] <fta> chrisccoulson, did you have a chance to give my apport hooks a try?
[16:00] <chrisccoulson> fta - that's my next task :)
[16:00] <chrisccoulson> sorry, was just finishing with a gnome-terminal crasher
[16:04] <micahg> chrisccoulson: I'm pushing up Thunderbird 3.0.8 to thunderbird-stable since I haven't fixed the wrapper yet
[16:04] <chrisccoulson> micahg - cool, thanks.
[16:08] <chrisccoulson> urgh, so many updates to do.....
[16:08] <chrisccoulson> i think i will leave those for when i have more time :)
[16:22] <chrisccoulson> fta - the apport hook is working ok so far with the combinations i've tested. i'll try with ch 6 in a moment
[16:29] <fta> good (so far)
[16:37] <fta> doesn't work for v6 with a clean profile
[16:40] <fta> ok, easy enough, fixed
[17:06] <chrisccoulson> fta - you fixed this one already?:
[17:06] <chrisccoulson> if 'check_default_browser' in entry['browser']:
[17:06] <chrisccoulson> KeyError: 'browser'
[17:06] <chrisccoulson> (with a clean profile)
[17:07] <fta> yep, hold on a sec, i've also extended it to add the active plugin list
[17:10] <fta> chrisccoulson, http://people.ubuntu.com/~fta/chromium/chromium-browser.py
[17:10] <micahg> chrisccoulson: I'm also pushing FF4.0 b6
[17:10] <chrisccoulson> fta - thanks
[17:10] <chrisccoulson> micahg - awesome :)
[17:10] <micahg> chrisccoulson: I'm not merging the test suite changes as I don't have time
[17:11] <chrisccoulson> micahg - no, those aren't important for that. the test-suite changes are really to catch regressions when i start trying PGO builds :)
[17:11] <fta> hm, bug 529758
[17:11] <ubot2> Launchpad bug 529758 in baltix (and 2 other projects) "Extension to install a flash provider (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/529758
[17:13] <chrisccoulson> fta - i think that was one of the things jcastro mentioned in his e-mail when explaining the reason for not switching to chromium on UNE
[17:14] <chrisccoulson> s/reason/reasons/
[17:15] <fta> hm, it's an old bug, why did i just receive an update?
[17:15] <fta> oh, an upstream bug
[17:15] <chrisccoulson> fta - yeah, someone just added a link, and a baltix task as well
[17:26] <fta> chrisccoulson, is the new version ok?
[17:26] <chrisccoulson> fta - just trying that now
[17:27] <chrisccoulson> fta - yeah, that's working ok now
[17:31] <fta> hm.. for some reason, the plugins key is not populated until something is manually changed in about:plugins
[17:34] <chrisccoulson> fta - yeah, i see that too (on ch 6)
[17:35] <fta> it's not my fault though, so it's fine as long as the hooks survive
[17:35] <chrisccoulson> fta - where is the "Default Plug-in" for chromium stored? (or is it actually compiled in?)
[17:36] <fta> chrisccoulson, i guess it's built-in
[17:37] <chrisccoulson> fta - do you know if it's possible to build it as a real plugin?
[17:38] <fta> chrisccoulson, there are 1 or 2 sample plugins doing nothing that are built but that i don't ship in the debs
[17:43] <fta> ok, committed the new version
[17:44] <fta> i still need to see a real bug report using it :P
[17:45] <fta> also, i'm far from sure it works down to hardy
[17:45] <fta> the apport api seems to be moving quite fast
[17:51] <fta> chrisccoulson, do you have a hardy setup at hand? (to test the hooks)
[17:51] <chrisccoulson> fta - yeah, i have a hardy VM here
[17:51] <chrisccoulson> i can test that in 20 minutes or so if that's ok?
[17:51] <fta> sure
[19:51] <BUGabundo> kenvandine: ping
[19:51] <kenvandine> BUGabundo, pong
[19:52] <BUGabundo> what do you need to check on gwibber?
[19:52] <BUGabundo>   Installed: 2.33.0~bzr864-0ubuntu1~daily1
[19:52] <BUGabundo> on Maverick 64bits
[19:54] <BUGabundo> kenvandine: ^^^^
[19:54] <kenvandine> logs
[19:54] <kenvandine> and what isn't working
[19:54] <BUGabundo> no timeline updates
[19:55] <BUGabundo> what logs you need? runtime debug?
[19:55] <BUGabundo> one $ gwibber-service -d -o coming right up
[19:56] <kenvandine> ~/.cache/gwibber/gwibber.log
[19:56] <kenvandine> so none of your services are updating?
[19:57] <BUGabundo> $ pastebinit ~/.cache/gwibber/gwibber.log
[19:57] <BUGabundo> uploading a 3MB file
[19:57] <BUGabundo> Gwibber Dispatcher: DEBUG    <twitter:responses> Performing operation
[19:57] <BUGabundo> Gwibber Dispatcher: DEBUG    <twitter:lists> Adding record
[19:57] <BUGabundo> Gwibber Dispatcher: DEBUG    <twitter:lists> Finished operation
[19:57] <BUGabundo> Gwibber Dispatcher: ERROR    Twitter failure - {u'favorited': False, u'contribu
[19:57] <BUGabundo> I only see a bunch of this
[19:59] <BUGabundo> kenvandine: http://paste.ubuntu.com/497182/
[19:59] <BUGabundo> kenvandine: all timelines have been stalled for 3 days
[20:01] <kenvandine> interesting... are you using RTL?
[20:01] <BUGabundo> not afaik
[20:01] <BUGabundo> but my lang system seems to be wacky
[20:02] <BUGabundo> could be related
[20:03] <kenvandine> oh
[20:03] <kenvandine> interesting
[20:03] <BUGabundo> what is ?
[20:03] <kenvandine> so it is seeing content of a message as being RTL
[20:03] <kenvandine> and causing a traceback
[20:03]  * BUGabundo reinstalls lang packs and tries to fix _something_
[20:04] <kenvandine> which is aborting the message
[20:04] <kenvandine> no... not that
[20:04] <kenvandine> seems content related
[20:04] <BUGabundo> ahh
[20:04] <BUGabundo> from some user?
[20:04] <BUGabundo> yes. a friend posted some hacky encoded chars the other day
[20:04] <BUGabundo> broke a few apps
[20:04] <BUGabundo> let me get his timeline
[20:05] <kenvandine> well i think this exposed a bug in gwibber, of course :)
[20:05] <kenvandine> which is GREAT
[20:05] <BUGabundo> http://twitter.com/hcarrega/status/24882953041
[20:05] <kenvandine> i would never see it
[20:05] <fta> mdeslaur, 6 times the same email for USN-989-1??
[20:05] <BUGabundo> kenvandine: that's why I'm talking to you :P
[20:06] <BUGabundo> need it filed ?
[20:06] <mdeslaur> fta: I didn't send it 6 times...your mail server is going haywire
[20:06] <kenvandine> BUGabundo, please file the bug
[20:06] <BUGabundo> ahah
[20:06] <kenvandine> i am trying to fix now... but would be good to track it
[20:06] <BUGabundo> what do you need me to write on it ?
[20:07] <kenvandine> failing to finish a refresh
[20:07] <kenvandine> post the log as  the output
[20:07] <kenvandine> and put this traceback in the content
[20:07] <kenvandine> Traceback (most recent call last):
[20:07] <kenvandine>   File "/usr/lib/python2.6/dist-packages/gwibber/microblog/dispatcher.py", line 92, in perform_operation
[20:07] <kenvandine>     m["rtl"] = util.isRTL(re.sub(text_cleaner, "", m["text"].decode('utf-8')))
[20:07] <kenvandine> KeyError: 'text'
[20:08] <BUGabundo> kenvandine: https://bugs.edge.launchpad.net/gwibber/+bug/643784
[20:08] <ubot2> Ubuntu bug 643784 in gwibber "failing to finish a refresh (affects: 1) (heat: 6)" [Undecided,New]
[20:08] <fta> mdeslaur, nope, just checked, the issue is somewhere inside google
[20:09] <BUGabundo> kenvandine: done
[20:09] <mdeslaur> fta: ok
[20:10] <fta> (i use my gmail address for those announces with a redirect to my own mail farm)
[20:10] <fta> 1st time it happened in years
[20:16] <fta> jdstrand, it seems that if no one asks for chromium to be explicitly on the agenda of the next t-b meeting, nothing will happen
[20:17] <fta> maybe it's a lost cause, like in debian
[20:17] <kenvandine> BUGabundo, thx
[20:17] <BUGabundo> kenvandine: my pleasure
[20:17] <BUGabundo> gwibber may suck, but I still find it useful :p
[20:17] <kenvandine> :)
[20:17] <kenvandine> lets make it not suck :)
[20:18] <BUGabundo> what? you gonna make it use <40MBs of ram? instead of 400?
[20:18] <BUGabundo> use realtime?
[20:18] <BUGabundo> upload pics?
[20:18] <BUGabundo> support lists?
[20:18] <BUGabundo> shall I continue ? ahah
[20:18] <BUGabundo> I'll be happy if it just works, right now
[20:18] <kenvandine> lists work
[20:19] <kenvandine> upload pics... i am anxious for
[20:19] <BUGabundo> its the only tool that can list my mentions from all networks
[20:19] <BUGabundo> and show notifications of my timelines
[20:19] <kenvandine> realtime stuff from twitter will work in 3.0
[20:19] <kenvandine> gwibber-service is using 26M for me... the client... we need to ditch webkit to make it smaller
[20:19] <kenvandine> which hopefully will happen next cycle
[20:20] <BUGabundo> kenvandine: and statusnet... also has RT support
[20:20] <BUGabundo> RT = realtime
[20:20] <kenvandine> it does?
[20:20] <BUGabundo> ofc
[20:20] <kenvandine> i had heard they were working on it
[20:20] <kenvandine> that is ryan's area :)
[20:21] <BUGabundo> 25756  72088     68       2151K 648.3M 131.5M 648.3M 131.5M   3% gwibber
[20:21] <BUGabundo> that's not 26MBs
[20:21] <kenvandine> that isn't gwibber-service
[20:21] <kenvandine> the client needs to ditch webkit to get smaller
[20:21] <BUGabundo> 24915  71322     31       2151K 405.6M 38004K 405.6M 38004K   1% gwibber-servic
[20:22] <kenvandine> for me the client is using 119M of RSS
[20:22] <kenvandine> yeah, 38M that is acceptable
[20:22] <BUGabundo> wth
[20:22] <BUGabundo> all of the sudden gwibber started working :S
[20:22] <kenvandine> although not sure why your's is that much more than mine...
[20:23] <kenvandine> my 26M of RSS includes facebook, twitter, statusnet, identica, foursquare, greader, and flickr accounts
[20:23] <kenvandine> :)
[20:23] <BUGabundo> HUGE logs/DBs?
[20:23] <BUGabundo> one identica, one statusnet, two twitter
[20:23] <kenvandine> nah, that shouldn't affect that
[20:24] <kenvandine> actually... maybe all those failures you have
[20:24] <BUGabundo> and its pretty recent
[20:24] <BUGabundo> maybe 1 month old
[20:24] <kenvandine> there might some lists that aren't getting freed
[20:24] <kenvandine> since they don't get inserted in the db
[20:24] <BUGabundo> bbl, dinner
[20:25] <kenvandine> later
[20:41] <fta> kenvandine, greader in gwibber? really? how does it look like?
[20:46] <kenvandine> fta, not great yet
[20:46] <kenvandine> i am experimenting with a branch someone else is maintaining
[20:46] <kenvandine> basically new feed entries appear in the message stream
[20:47] <kenvandine> i think they need to be separated, they don't feel "right" there imho
[20:49] <fta> well, 140 char lines mixed with pages long articles, often with pictures and videos
[20:50] <fta> weird idea
[20:50] <fta> tweeter feeds into greader look weird too
[20:50] <fta> i have one, it's plain ugly
[21:50] <fta> micahg, 9 days :(  https://edge.launchpad.net/~chromium-daily/+archive/dev/+packages
[21:50] <fta> it keeps being pushed forward
[21:53] <micahg> fta: that's weird
[21:55] <micahg> fta: the build has been scored down :(
[21:55] <fta> ??
[21:55] <micahg> Start in 8 hours             (2455)
[21:55] <fta> why? they are no different from my other builds
[21:55] <micahg> should be 2505
[21:55] <fta> http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[21:56] <micahg> ask in LP if someone scored the PPA down
[21:57] <BUGabundo> kenvandine: look at http://seesmic.com/web/
[21:57] <BUGabundo> they know how to make it look great
[21:57] <fta> micahg, there's no longer listening to me there :(
[21:57] <BUGabundo> I would use it, if it supported statusnet
[21:58] <BUGabundo> they do on the desktop app, but it runs on silverlight (blerg)
[21:58] <micahg> fta: I'll try asking later tonight
[21:58] <fta> micahg, i'm not doing all that for myself, i'm doing it for the community. if it was only me, the dailies would be enough
[21:59] <micahg> fta: I know, I'll see if someone scored it lower
[21:59] <BUGabundo> kenvandine: if you have 30 mins, ping me back. I have something I want to run by you
[21:59] <fta> BUGabundo, shame! https://wiki.ubuntu.com/Translations/Wanted/ChromiumDesktop
[22:22] <kenvandine> BUGabundo, humm... so what is it that seesmic web does right that gwibber doesn't
[22:22] <kenvandine> it actually seems pretty similar
[22:23] <BUGabundo> buzz and greader
[22:23] <kenvandine> i don't see greader in there
[22:23] <kenvandine> how do i add that?
[22:24] <BUGabundo> its on the Desktop version
[22:24] <BUGabundo> not web
[22:24] <kenvandine> oh
[22:24] <kenvandine> ok
[22:24] <BUGabundo> but what I wanted to ask you was
[22:25] <BUGabundo> if you could use some of the know how of gwibber, and make an android app, to use with web.pond.pt
[22:25] <BUGabundo> there's the API http://web.pond.pt/home?action=dev
[22:25] <kenvandine> they say they have an android app
[22:26] <kenvandine> i hadn't seen pond before
[22:27] <BUGabundo> the app sucks
[22:27] <BUGabundo> doesn't do a basic think like filter read items, like full web does
[22:27] <BUGabundo> and the api has support for it
[22:27] <BUGabundo> I've contacted the team several times, requesting just that
[22:27] <BUGabundo> and been ignored so far :(
[22:30] <kenvandine> i wouldn't be of any help to get an android client done and gwibber isn't really suited for a phone yet
[22:31] <kenvandine> BUGabundo, how rich is pond's service as it relates to supporting service features?
[22:31] <kenvandine> like facebook and stuff
[22:31] <BUGabundo> fb, twitte, flickr, and a few others
[22:31] <BUGabundo> but they have a unique feature I would love twitter/SN had natively
[22:31] <BUGabundo> read/unread state of notices
[22:32] <kenvandine> that is something i want to do in gwibber too
[22:32] <BUGabundo> we can't ever browse older entries in gwibber
[22:32] <BUGabundo> and gwibber is a desktop app
[22:32] <kenvandine> but like facebook... posting of images, etc
[22:32] <BUGabundo> this is a web service
[22:32] <kenvandine> all works ok?
[22:33] <BUGabundo> don't have a prob with it
[22:33] <BUGabundo> but their android app is very week
[22:33] <kenvandine> we won't track all messages, but any message gwibber has downloaded i want to track if it is been seen
[22:34] <kenvandine> i also want to "star" or tag them somehow
[22:36] <kenvandine> which doesn't necessarily change any status on a server... so not super persistent
[22:36] <kenvandine> but on the client, you could have a way to always display starred messages
[22:36] <kenvandine> or something
[22:36] <kenvandine> so you can go back to them later when you have time or whatever
[22:37] <kenvandine> kind of like a save for later
[22:38] <BUGabundo> I only use gwibber on this laptop
[22:38] <BUGabundo> I use 3 other PCs, and my android
[22:38] <BUGabundo> I need a _cloud_ something :\
[22:38] <kenvandine> sure... not the average user :)
[22:39] <kenvandine> it would be nice if we had a way to do that in the cloud universally without yet another web service to complicate life
[22:39] <BUGabundo> we do
[22:39] <BUGabundo> ubuntu one ?
[22:40] <BUGabundo> google app engine LOL
[22:40] <kenvandine> my goal is much simpler, just let you tag a message that looks interesting so you can go back in a bit to read it
[22:40] <kenvandine> doesn't need to be long lived
[22:40] <kenvandine> ubuntu one could be cool
[22:40] <kenvandine> but a lot of work :)
[22:41] <kenvandine> we need to focus on solving the 95% case first... and doing it well :)
[23:46] <chrisccoulson> micahg - do you think we should just re-use the former source package name for lightning (lightning-sunbird)?
[23:47] <micahg> chrisccoulson: if I didn't I wouldn't have wanted it dropped from Lucid ;)
[23:47] <micahg> *did
[23:47] <micahg> which was probably a mistake in retrospect
[23:47] <chrisccoulson> do you think lightning-calendar is ok?
[23:47] <chrisccoulson> or lightning-extension?
[23:48] <micahg> chrisccoulson: that's what I was thinking, or lightning-calendar
[23:49] <micahg> lightning-extension is the current package, so maybe that
[23:49] <chrisccoulson> yeah, i can use that
[23:49] <micahg> but the binary should probably be xul-ext-lightning-calendar or something to that effect
[23:50] <chrisccoulson> yeah, i've taken care of that already
[23:50] <micahg> whatever the conventions are
[23:50] <micahg> chrisccoulson: can you tell I haven't had a chance to look at it yet?
[23:50] <chrisccoulson> heh :-)
[23:51] <micahg> chrisccoulson: k, so I want to file an AA bug once it's in to add it to the mozilla packageset as well as the gnome-pm extension, and drop miro does that sound ok?
[23:51] <chrisccoulson> yeah, that should be fine