[01:17] <NET||abuse> hey guys.. i tried to branch off a repo on one of my web servers, bzr+ssh   it got to 124MB, still says 1171KB/s but it's stuck, for about the last 15 minutes.
[01:18] <NET||abuse> there's only 10 MB left in the repo i believe
[01:18] <NET||abuse> is there anything i can do to cancel and recover the branch operation?
[01:24] <spiv> NET||abuse: unfortunately bzr can't yet resume interrupted fetches
[01:25] <spiv> NET||abuse: strange that it got stuck, though
[01:25] <NET||abuse> yeh, been waiting a while.
[01:25] <NET||abuse> still stuck :(
[01:25] <NET||abuse> crap.. it's a big fetch, 135 MB
[01:26] <spiv> I don't suppose there's any errors in ~/.bzr.log on the server?
[01:26] <NET||abuse> right, i could look.
[01:27] <NET||abuse> yep, error
[01:27] <spiv> If you do need to restart, perhaps try "bzr branch -r 500 ...", then "bzr pull -r 1000", "bzr pull -r 1500", etc to do it in stages.
[01:27] <spiv> Could you pastebin it?
[01:27] <NET||abuse> File "/usr/lib/python2.4/site-packages/bzrlib/osutils.py", line 1810, in until_no_eintr  return f(*a, **kw)  IOError: [Errno 32] Broken pipe
[01:29] <spiv> How strange.  Could you paste the full traceback in http://pastebin.com/ ?
[01:29] <spiv> But that snippet implies that the connection was lost, at least as far as the server is concerned.
[01:41] <jfroy|work> jelmer: ping
[01:52] <NET||abuse> arrg.
[01:52] <NET||abuse> timeout?
[01:53] <spiv> NET||abuse: yes, you dropped of IRC due to a timeout
[01:53] <spiv> NET||abuse: which I suppose is consistent with the bzr stream failing due to a network drop out...
[01:53] <NET||abuse> oh well..
[01:53] <NET||abuse> :) maybe my net connection is dorky
[01:53] <spiv> NET||abuse: so I'd grab the branch in smaller chunks
[01:53] <jelmer> jfroy|work, hi
[01:53]  * spiv -> lunch
[01:53] <NET||abuse> well, any ideas from my pastbin.
[01:54] <NET||abuse> smaller chunks? how do i do that?
[01:54] <jfroy|work> jelmer: I have a rather serious problem
[01:54] <spiv> NET||abuse: didn't get your pastebin URL
[01:54] <NET||abuse> ahhhh
[01:54] <spiv> < spiv> If you do need to restart, perhaps try "bzr branch -r 500 ...", then "bzr pull -r 1000", "bzr pull -r 1500", etc to do it in stages.
[01:54] <NET||abuse> http://pastebin.com/m64de9e31
[01:54] <jfroy|work> jelmer: there was some... evil messing around with our subversion repository
[01:54] <NET||abuse> i posted when seemingly my irc had dropped, there was no indication for a while.
[01:54] <spiv> NET||abuse: also, if your branch isn't in 2a format yet, consider upgrading, it'll be smaller.
[01:55] <poolie> jml: now would be good, if you've lunched
[01:55] <jfroy|work> I described what was done in https://bugs.launchpad.net/subvertpy/+bug/497280
[01:55] <NET||abuse> it is 2a already
[01:55] <spiv> NET||abuse: ok
[01:55] <jfroy|work> now, beyond that kink, which I worked around, I thought everything was fine.
[01:55] <spiv> NET||abuse: hmm, that doesn't look like the whole traceback, just 3 frames, but I think given that you're having network issues it's safe to assume it's not bzr's fault.
[01:55] <jfroy|work> But, a co-worker just committed a revision to our trunk (nested inside our project directory in our new repository)
[01:56] <jfroy|work> and bzr won't pull the changes introduced by that revision
[01:56] <spiv> NET||abuse: thanks for pasting that though
[01:56]  * spiv -> really lunch this time
[01:56] <jfroy|work> worse, it allowed me to push 2 new revisions after that revision without any complaint -- normally, it should have stopped, telling me the branches had diverged
[01:57] <jfroy|work> if you have a bit of time, I'd like to try to figure out what the heck is going on
[01:58] <jelmer> jfroy|work, did your two revisions merge any of his changes?
[01:58] <jfroy|work> no
[01:58] <jfroy|work> they were completely unrelated sets of changes
[01:58] <jfroy|work> well, at least I didn't intentionally do a merge
[01:59] <jelmer> can you check if those revisions have any other parents?
[01:59] <NET||abuse> well, there's nothing i can do other than try fetch again.
[01:59] <jelmer> you didn't push with --overwrite or anything like that?
[01:59] <jfroy|work> but, if you read the bug I filed on subvertpy, it's possible bzr-svn is getting confused by merge properties or even bzr-svn properties that are completely bogus
[01:59] <jfroy|work> nope, I did a commit from a bound branch
[02:00] <jfroy|work> or, I should say, properties that have been made bogus
[02:00] <jfroy|work> and OK, I do I check for parents?
[02:02] <jelmer> jfroy|work, bzr log --show-ids should tell you
[02:03] <jfroy|work> the subversion revision in question does not appear in the log
[02:04] <jfroy|work> yep, it's as if it was being skipped entirely
[02:04] <jfroy|work> the revision that should have the missing revision as its parent instead points to the one before
[02:09] <jelmer> jfroy|work, that's correct, as that's the order in which you committed them locally
[02:10] <jfroy|work> well yes, but there's a whole in there
[02:10] <jelmer> so I wonder why it didn't complain about diverged branches - you're sure you didn't push with --overwrite?
[02:10] <jfroy|work> pretty sure...
[02:11] <jfroy|work> unless something can turn that option on...
[02:11] <jfroy|work> it wasn't even a push, it was a commit in a bound branch
[02:16] <jelmer> jfroy|work: might be a bug in the commit code in bzr-svn in that case, can you file a bug?
[02:16] <jelmer> jfroy|work, I've responded to the other bug report in subvertpy, which is probably unrelated
[02:16] <jfroy|work> sure, although I'm not sure I can provide much more information than I have.
[02:16] <jfroy|work> Yes, it's probably unrelated
[02:17] <jfroy|work> Also, is there a way I can fix the situation?
[02:17] <jelmer> you can cherrypick the changes from the missing revision
[02:17] <jfroy|work> Apply a diff manually between a svn checkout and a bzr checkout and push --overwrite, at least to pick up the missing changes>
[02:17] <jelmer> commit those and then push them
[02:17] <jfroy|work> *?
[02:18] <jelmer> I need to get some sleep, let's move this discussion to the bug report
[02:18] <jelmer> sorry
[02:18] <jfroy|work> OK
[02:18] <jfroy|work> no worries at all
[02:18] <jfroy|work> I appreciate you taking some time at all.
[03:57]  * mwhudson randomly wonders how long away realistically being able to disable vfs operations on the smart server is
[04:05] <spiv> mwhudson: ages, probably, given that it doesn't seem particularly relevant to udd goals
[04:06] <mwhudson> spiv: yeah, fair enough
[04:06] <lifeless> ronny: hi, I'm back
[04:07] <mwhudson> spiv: if it was a priority, do you have a sense how long it would take?
[04:07] <mwhudson> / how much work it would be?
[04:07] <lifeless> mwhudson: I think you're asking the wrong question :)
[04:08] <mwhudson> lifeless: i find it hard to believe you know why i'm asking
[04:08] <lifeless> mwhudson: I think the question you want to ask is 'how many operations do people do, that need the VFS today, which we would have to support to be willing to disable the VFS'
[04:08] <lifeless> mwhudson: I've got no idea why you are asking
[04:08] <lifeless> but we can disable the VFS today, just at high impact.
[04:09] <mwhudson> lifeless: yes, ok, that's a more answerable question
[04:09] <lifeless> mwhudson: also you have a question in /msg
[04:10] <lifeless> mwhudson: one implication of framing the question about VFS as I have, is that you can clearly see that lp might reach a different answer than (say) savannah
[04:11] <mwhudson> yeah
[04:12] <lifeless> or, more importantly, than core.
[04:12] <lifeless> One useful thing would be to get a % use of VFS today.
[04:12] <lifeless> I suspect its 60-70%
[04:12] <lifeless> (connections which invoke vfs at all), not % of operations on a connection.
[04:30] <mwhudson> yeah, i guess we could measure it
[04:31] <mwhudson> though it's probably not so interesting, i mean i would guess 90% of connections just do a fetch in one direction or the other
[04:31] <lifeless> so if we want to push for vfs free lp
[04:31] <lifeless> then we should measure it
[04:31] <lifeless> if we basically do-not-care
[04:32] <lifeless> then its all moot :P
[04:32] <mwhudson> i guess it's in the do-not-really-care bucket for now, as spiv says
[04:33] <spiv> mwhudson: if you do start to really care, I'm sure you'll let us know :)
[04:35] <mwhudson> :-)
[04:47] <StevenK> Isn't there a bzr command that will show me pending merges? I'd like to confirm it before I commit and I'm having a temporary brain-freeze.
[04:48] <Kamping_Kaiser> status? or am i missing the point?
[04:49] <Kamping_Kaiser> 'arvo, btw.
[04:49] <StevenK> Hey!
[04:49] <Kamping_Kaiser> :)
[04:49] <StevenK> st just shows me modified files. Perhaps because they were all conflicted.
[04:49] <StevenK> Well, all bar one.
[04:50] <spiv> Then you have no pending merges.
[04:50] <AnAnt> Hello, what are valid bzr URLs (other than lp:// & bzr+ssh://) ?
[04:50] <spiv> Unless you've done "bzr alias st='status --no-pending'" ;)
[04:51] <spiv> AnAnt: bzr help urlspec
[04:51] <AnAnt> thanks
[04:51] <StevenK> spiv: I ran bzr merge, resolved the bunch of conflicts, but I'd expect it to still say there is a pending merge
[04:51] <spiv> (which will include url schemes supported by plugins, if any)
[04:52] <spiv> StevenK: you probably did a cherrypick then
[04:52] <StevenK> spiv: Yeah, it was only one revision
[04:52] <spiv> Right.
[04:52] <StevenK> spiv: That isn't a real merge per-se?
[04:52] <spiv> Well, it's real, but bzr can't record it :)
[04:52] <spiv> bzr represents merges as extra parents for the revision.
[04:54] <spiv> So it has no way to record "X was merged but not X-1"
[04:55] <spiv> It's simply "X was merged [and so implicitly all of its ancestors too]", or nothing.
[04:55] <spiv> We'd like to support that better, but it hasn't quite made it to the top of our todo list.
[04:58] <lifeless> poolie: I wonder if you could mail me your APN details from your magic
[04:58] <AnAnt> is there a way to check wether a bzr URL is valid or not ?
[04:58] <spiv> AnAnt: valid for what purpose?
[04:59] <poolie> lifeless: what is an apn?
[05:00] <AnAnt> spiv: ie. the URL is not wrong, for example, if I do bzr branch lp:foo/boo/zoo I would get this error: "bzr: ERROR: Invalid url supplied to transport: "lp:boo/foo/doo": No such project: boo"
[05:00] <AnAnt> I want to check if the URL is valid or not without actually doing a bzr branch
[05:00] <lifeless> poolie: access point name
[05:00] <lifeless> poolie: ~= to essid
[05:01] <AnAnt> I don't see a dry-run option for bzr branch
[05:01] <spiv> AnAnt: Well, if you want to check if there's a branch there without branching, you can do "bzr info URL" or even just "bzr revno", for example.
[05:01] <AnAnt> thanks
[05:03] <lifeless> poolie: settings -> wireless -> mobile networks, there should be a list of apns there, I'd like the settings for the one that you're using, which will be what vodafone shipped
[05:04] <poolie> ok
[05:04] <poolie> on phone now
[05:04] <lifeless> no rush
[05:04] <lifeless> I'm trying to set up tethering to my phone
[05:12] <AnAnt> spiv: thanks again, that helped me to fix something in git-bzr
[05:13] <spiv> AnAnt: you're welcome
[07:05] <vila> hi all
[07:37] <jml> oh right.
[07:37] <jml> I'm still trying to land this branch.
[07:50] <poolie> hi vila
[07:50] <poolie> and good night
[07:50] <poolie> and send a pp report :)
[07:50] <vila> :)
[07:51] <poolie> i booked trains btw, the details are on the wiki
[07:51] <poolie> it was quite cheap
[07:51] <poolie> have a good day and a good trip
[07:51] <vila> poolie: thanks and thanks for updating the patch pilot page !
[08:10] <jml> vila, can you please help me land this patch?
[08:11] <jml> I get the error: merge http://bazaar.launchpad.net/~jml/bzr/lp-login-oauth-2 http://bazaar-vcs.org/bzr/bzr.dev
[08:11] <jml> Command failed!
[08:11] <jml> All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.dev
[08:11] <Peng> jml: Try the new http://bazaar.lp URL.
[08:12] <vila> jml: one sec, but I think trying Peng suggestion is worth it
[08:12] <jml> Peng: which one is that?
[08:12] <vila> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev or lp:bzr :)
[08:13]  * jml tries lp:bzr first
[08:16] <jml> vila, what do you have in your locations.conf?
[08:16]  * vila was well known for hanging pqm with lp urls :)
[08:17] <vila> jml: I use branch.conf: http://paste.ubuntu.com/343725/
[08:18] <vila> relevant part: http://paste.ubuntu.com/343726/
[08:18] <jml> vila, that seems to be a bit better.
[08:19] <vila> jml: the change dated back to the switch from bazaar-vcs.org to lp for hosting bzr.dev
[08:19] <vila> s/for hosting/to host/ ?
[08:19] <jml> the first one is correct.
[08:20] <jml> vila, I see that HACKING.txt hasn't been updated then.
[08:21] <vila> yes, lifeless mentioned it yesterday too, you may have missed that
[08:23] <jml> ahh, I did miss that.
[09:37] <johnf1> vila: I sent my contributor agreement through months ago. CCd poolie. Where is the best place to resend it?
[09:38] <vila> johnf1: Just comment in the merge proposal, poolie will be the patch pilot next week so he will sort that out
[09:39] <vila> johnf1: sorry about that :-/
[09:39] <johnf1> no problems
[09:42] <MvG> Good morning!
[09:42] <MvG> I've released trac-bzr 0.3.0 today. Due to lack of testing, I've got to consider it of beta quality, so I'll be happy for all of you who use Trac to give it as much testing as possible.
[09:54] <NET||abuse> hey guys.. i want to inspect older revisoins of one particular file, how can i do this easily?
[09:54] <MvG> NET||abuse: bzr cat, I'd say
[09:54] <NET||abuse> hmm, ok
[09:58] <spiv> NET||abuse: you might find the bzr-gtk or qbzr plugins handy, they give you commands like glog/qlog that let you explore history with a GUI.
[09:59] <NET||abuse> not a bad idea i suppose.
[10:00] <NET||abuse> any preference between qbzr or gtk?
[10:02] <spiv> NET||abuse: qbzr is probably a little more polished at this point
[10:03] <NET||abuse> just tried to install...
[10:03] <NET||abuse> no applications->programming item, no obvious terminal line command to run
[10:22] <vila> NET||abuse: try  bzr help plugins/qbzr
[10:22] <vila> then you most probably try 'bzr qlog' or 'bzr qblame FILE'
[10:23] <NET||abuse> that seems to do it.
[10:23] <vila> err, qannotate (qblame is an alias so it doesn't appear in that help)
[10:43] <NET||abuse> what does the qannotate doe exactly?
[10:44] <NET||abuse> the qlog was great, i got to view the tree from the old revision... was able to open the file in question, i had a UTF-8/Latin10 character encoding problem. litereally the files own encoding type.
[10:54] <Peng> vila: What time zone are you in?
[10:54] <vila> CET
[10:54] <vila> i.e. I will go to lunch soon :)
[10:55] <Peng> Oh, fun.
[10:57] <Peng> Hehe, I'm in -0500; it's 05:57 here right now. If only I had a sleep schedule...
[10:58] <vila> Peng: Really ? Where are you ?
[10:59] <NET||abuse> that's just east coast US
[11:00] <Peng> Yep.
[11:01] <vila> could have been canada or south america :)
[11:02] <Peng> I'm in Florida, to be a bit more specific.
[11:03]  * vila feeds the satellite Laser
[11:04] <Peng> I think my LP map location is set semi-accurately.
[11:05] <Peng> So as long as the laser can take out an area, say, 30 miles wide, I think it will work.
[11:06]  * vila tries
[11:06] <vila> oops
[11:06] <vila> Peng: your timezone says UTC though
[11:07] <Peng> vila: I like using UTC.
[11:07] <vila> Peng: doesn't really help in that for visitors trying to reach you :-D
[11:08]  * vila add 'case'
[11:08] <Peng> vila: Well, my usual sleep schedule is more like Australia anyway.
[11:09] <vila> good, use that :)
[11:09] <Peng> But I like UTC. No Daylight Saving Time.
[11:10] <Peng> Hmm, using an Australian time zone is a completely insane idea that sounds totally fun.
[11:11] <vila> Peng: yes, that's fine, I'm talking about your lp page, where I don't think *you* care much about what is displayed there, but *others* may. But that's your page in the end :)
[11:11] <Peng> vila: Ah. Does that setting influence times displayed on LP, though?
[11:12] <vila> You'll tell me :)
[11:16] <Kamping_Kaiser> why does bzr have >700KB of data transferred to do a 2 line commit? :/ Could this be a continuation of  the issues I was asking about earlier in the week?
[11:17] <Kamping_Kaiser> i shoul work out who i was talking before *checks logs*
[11:18] <Kamping_Kaiser> ah, vila .
[11:18]  * vila search logs too
[11:19] <vila> What is your remote server and what protocol do you use ?
[11:19] <Kamping_Kaiser> i should probably grill the savannah admins before i ask here more, i know they have issues at their end.
[11:20] <vila> Ha ! savannah, sftp
[11:21] <Peng> vila: I added a note to my LP page. :)
[11:21] <vila> So you may be doing a repack which requires downloading/uploading more than strictly the 2 lines commit
[11:22] <Kamping_Kaiser> from your reaction i take it sftp is not the fastest way to transfer data :)
[11:22] <Kamping_Kaiser> i note my other checkout pulls over http and pushes on sftp - strange but true.
[11:22] <vila> Kamping_Kaiser: .bzr.log should give hints
[11:22] <vila> Kamping_Kaiser: well, the smart server is supposed to be really smarter than the dumb servers
[11:22] <Peng> Savannah runs such an old version of bzr that you're better off avoiding their smart server, if they have one.
[11:23] <vila> In particular it knows how to repack locally (or remotely, well, locally from its pov)
[11:23] <vila> Peng: I don't think so, I'm pretty sure they use a backported 2.0.3
[11:23] <Peng> vila: Oh, they do now? Thank goodness.
[11:23] <vila> But they don't have allow the use of it, Kamping_Kaiser ? Can you confirm that ?
[11:23] <Peng> vila: I had heard that they were going to stick with Debian Stable, which is 1.5 or something.
[11:24]  * Peng shrugs.
[11:24] <Kamping_Kaiser> vila: can't confirm what savannah runs sorry.
[11:24] <lifeless> Peng: backports
[11:24] <vila> Peng: The change occurred recently (if it has), one or 2 weeks
[11:24] <lifeless> Peng: see the long thread on same
[11:24] <Kamping_Kaiser> I've successfully avoided becoming responsable for savannah in any form *g*
[11:25] <Peng> Yeah, I stopped paying attention to that thread. :P
[11:25] <Peng> That's great to hear, though. Go Savannah! :
[11:25] <Peng> :)
[11:25] <vila> Kamping_Kaiser: I like the etymology of responsible: the one who can respond for :)
[11:26] <Kamping_Kaiser> vila: hehe. the problem is, I tend to involve myself in projects deeper then i need ;) (I'm still a bzr _user_ thank goodness)
[11:27] <vila> I think spiv and/or jam hacked a ping plugin that could help here but I don't remember the details...
[11:27] <Kamping_Kaiser> bzr log tells me 21.366  fetch up to rev<EMAIL_ADDRESS>so i'll guess thats the problem on that data transfering
[11:28] <vila> Kamping_Kaiser: context ? More than 1 commit ?
[11:28] <Kamping_Kaiser> vila: i'll pastebin the log stanzas, just a tick
[11:29] <Kamping_Kaiser> http://paste.debian.net/54352/
[11:29] <spiv> vila: lp:bzr-ping, usage simply 'bzr ping URL', it will report the smart server version at that URL
[11:30] <spiv> (or at least which version of bzr the smart server claims to be)
[11:30] <vila> spiv: \o/
[11:32] <vila> Kamping_Kaiser: that doesn't tell me if there was more than 1 rev to push  :-/
[11:33] <vila> But that strongly remains me that we have a pending patch that give that kind of info for pull (at least the revno/revid *before* the pull), it would be nice to do the same for push
[11:33] <Kamping_Kaiser> vila: afaik it was just one revision
[11:34]  * vila breathes again, subunit/testtools/bzr working happily together again to provide --parallel=fork
[11:34] <Kamping_Kaiser> interesting... bzr.log confirms 2009-11-22 was the last submission CIA got from me. i should track that problem down
[11:34] <Kamping_Kaiser> sorry. getting distracted by my new data source :p
[11:34] <vila> Kamping_Kaiser: no simple explanation comes to mind then :-/ Do you observe that for every push ?
[11:35] <Kamping_Kaiser> vila: the last half a dozen at least (they're the ones i remember).
[11:36] <Kamping_Kaiser> vila: I suspect something in a newer version of bzr isn't playing happily with something in my install. cia disapeared enf of last month, and this slowlness issue, its definitely only been a month or so
[11:37] <vila> what bzr version are you using ?
[11:37] <Kamping_Kaiser> 2.0.2-1~bpo50+1
[11:39] <vila> where did you get that ?
[11:40] <Kamping_Kaiser> http://www.backports.org (directly from them, or via roberts backports repo)
[11:41] <vila> ok, so that's an official 2.0.2 right ?
[11:42] <vila> haaa bpo == backports ?
[11:42] <Kamping_Kaiser> yup
[11:42] <vila> k, excuse my English I'm French :) (And sorry for my president too :-/)
[11:43] <Kamping_Kaiser> no worries.
[11:43] <Kamping_Kaiser> i'll match and raise your president with my communications minister
[11:45] <vila> Kamping_Kaiser: where are you from ?
[11:46] <Kamping_Kaiser> vila: Australia. http://www.abc.net.au/news/stories/2009/12/15/2772467.htm
[11:46] <vila> Kamping_Kaiser: bug #465517 may be a candidate, but I doubt it
[11:47] <vila> Kamping_Kaiser: Oh my, you too have internet censors for you own godd ^^
[11:47] <Kamping_Kaiser> not the same - whole repo isn't copied, but could be related (as is the way with software)
[11:47] <Kamping_Kaiser> vila: I feel safer already ;O
[11:48] <vila> Kamping_Kaiser: you repo is big ?
[11:48] <vila> Kamping_Kaiser: your repo is big ?
[11:48] <vila> Kamping_Kaiser: do you an url where I can branch from ?
[11:49] <Kamping_Kaiser> vila: 88 mb. hang on for the uri
[11:49] <Kamping_Kaiser> bzr branch http://bzr.savannah.nongnu.org/r/gnewsense/builder should do the job (I assume you don't have a savannah login :))
[11:50] <vila> Kamping_Kaiser: Oh I should have one.... but where :D
[11:50] <Kamping_Kaiser> hehehe
[11:51] <Kamping_Kaiser> https://savannah.nongnu.org/bzr/?group=gnewsense ftr, but i doubt you'll need it
[11:55] <vila> Kamping_Kaiser: ok, so the repository is currrently quite fragmented 32 packs in http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/ so we may need to access the corresponding indices which in turn should not be quite good for you if you have high latency to savannah
[11:56] <vila> what is your ping time there ?
[11:56] <Kamping_Kaiser> vila: 324ms
[11:56] <vila> again, the smart server can help a lot here since all the indices are local from its pov
[11:58] <vila> so if you can afford to issue 'bzr pack :push' and try a new push after that you may get far better results
[11:58] <Kamping_Kaiser> vila: will all checkouts be this fragmented, or just mine?
[11:59] <vila> the fragmentation is natural but... geee, I wish I had an url for that explanation...
[11:59] <vila> every 10 commits a bigger pack file is created, every 100 an even bigger with the 10 bigs, etc
[12:00] <vila> http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/?C=S;O=A
[12:00] <Kamping_Kaiser> hm, ok. so is this an 'email everyone suggesting they repack' moment, or a 'oh good, something new learned'? from what you say i assume only people with a reasonable number of commits will be affected to start with
[12:01] <vila> I suspect the high latency is really the most proeminent problem here and only the smart server can address that
[12:02] <vila> bzr pack *should not* be needed under normal circumstances, I'm asking here to see if it changes the behaviour you're seeing *right* now
[12:02] <vila> If you look at the last url I pasted you can see that your last commit is really small, so bzr didn't upload a lot, I'm trying to roughly evaluate if the time can be due to a lot of downloads instead, hence the proposal
[12:03] <Kamping_Kaiser> ok. its repacked, and pushing. :)
[12:04] <vila> But that url is weird too because it seems to show a weird distribution of sizes...
[12:04] <vila> Still the same, are you sure you packed the remote one and not the local one ?
[12:05] <Kamping_Kaiser> incase its relevant, the original repo was svn, it got bzr-svned, then commited to, then upgraded to some format, then commited to, then upgraded again, and commited to again
[12:05] <Kamping_Kaiser> vila: its still uploading.
[12:05] <Kamping_Kaiser> [########/           ]   7920KB     1KB/s | repacking chk:chk node 9760/47924
[12:05] <vila> repacking, here we go
[12:07] <vila> right, so that may explain the weird distribution, can you put dates on the events above that we can relate the pack dates ?
[12:08] <Kamping_Kaiser> should be able to, it'll involve some logs diving though, so could take a min
[12:11] <vila> Kamping_Kaiser: looking at http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/upload/ progress, I think I can leave you there and be back after lunch
[12:11] <Kamping_Kaiser> hehe. most likely. i'm going nowhere.
[12:12] <vila> Kamping_Kaiser: I'll be back in ~< 1h
[12:12] <Kamping_Kaiser> enjoy lunch :)
[12:12] <vila> no no, already 6.6M uploaded, don't stop it !
[12:12] <Kamping_Kaiser> 26000KB to upload 6.6mb. ah well. repacking ftw ;)
[12:12] <vila> wow, huger spike suddenly 11M....
[12:13] <vila> no, your repo is far bugger than 6M !
[12:13] <vila> more like 65M roughly
[12:13] <vila> s/bugger/bigger/ damn keyboard
[12:14] <Kamping_Kaiser> nm. i'll dig those logs, see you later.
[12:18] <bialix> MvG: ping
[12:18] <MvG> bialix: pong
[12:18] <bialix> congrat on new trac-bzr release
[12:18] <bialix> have a question
[12:19] <bialix> does trunk supposed to be used only with trac 0.11? or?
[12:19] <bialix> MvG: ^
[12:20] <MvG> bialix: No, so far trunk and trac-0.10 are equal.
[12:20] <bialix> oh, that's great
[12:20] <MvG> I just want to give devs the option to track trac-0.10 and be ensured that their setups won't break.
[12:20] <MvG> And I had supposed I'd break compatibility before releasing 0.3.0, but it turns out there was no pressing need to yet.
[12:21]  * MvG is AFK for a minute.
[12:21] <bialix> thanks for the info
[12:22] <bialix> MvG: did you send announcement to bazaar-announce or main bzr ML?
[12:23] <bialix> when you'll have a chance, please do :-)
[12:26] <MvG> Oh, thanks for the reminder, will try to do so if I find the time...
[12:27] <MvG> bialix: btw: caching scheduled as main goal for 0.4: https://blueprints.launchpad.net/trac-bzr/+spec/caching
[12:27] <bialix> \o/
[12:27]  * MvG is AFK for a while longer now.
[12:31] <Kamping_Kaiser> vila-lunch: this should give you some idea. http://paste.debian.net/54356/ not brilliantly accurate, hope its enough (all times GMT+9.5 or +10.5)
[13:09] <Coke> Hello! I'm using sftp to upload changes to my main repos, it says I'm uploading using 1KB/s. At the same time, I can upload files using sftp at several MB/s. Why is Bazaar so slow?
[13:10] <Coke> Right now bazaar is about 100-200 times slower than svn
[13:10] <Coke> (for checking in and updating)
[13:11] <Kamping_Kaiser> Coke: hm... hang around. i have the same slow sftp upload issue.
[13:11] <Kamping_Kaiser> someone was helping me. perhaps he'll come back from ....
[13:11] <Kamping_Kaiser> lunch ;O
[13:11] <vila> Kamping_Kaiser: wow, the restaurant was crowded...
[13:11] <vila> but still < 1h :-D
[13:11] <Coke> Kamping_Kaiser: I've had this problem forever
[13:11] <Kamping_Kaiser> ;D
[13:12] <Kamping_Kaiser> Coke: i haven't had it that long - its only existed in my lifetime for example :D
[13:12] <vila> Coke: What `bzr version`, what repository format `bzr info` ?
[13:12] <Coke> 2.0.1
[13:12] <Coke>  pack-0.92
[13:12] <vila> Kamping_Kaiser: looks like your repo is packed now
[13:13] <vila> Coke: upgrading to 2a should make a significant difference, using a smart server (bzr+ssh: instead of sftp:) even more
[13:13] <Kamping_Kaiser> vila: yes, it is. i pasted you a pastebin link giving some rough info you asked about
[13:13] <Coke> vila: I'm not interrested in changing the setup
[13:13] <Coke> If anything I'll just revert to svn
[13:13] <Coke> or upgrade bzr
[13:14] <Coke> Why is it so slow?
[13:15] <Coke> socket.write(data, 1024); sleep(1000) ???
[13:15] <vila> Coke: Good catch, patches welcome !
[13:15] <Coke> vila: I'm not really sure how you can get down to 1KB/s without doing above code
[13:16] <vila> Coke: If you don't want to use the smart server you can still upgrade your repository to the 2a format
[13:16] <Coke> sftp is pretty smart
[13:18] <Coke> Kamping_Kaiser: did you solve it by upgrading?
[13:19] <vila> Kamping_Kaiser: Nothing suspicious in your log, bzr upgrade --2a should end with an automatic repack so the distribution I oberved before has no good explanation. Is that repository shared with other branches or projects where some commits may have resulted in pack files in the 10MB range ?
[13:19] <vila> Kamping_Kaiser: more importantly what happens *now* if you push ?
[13:20] <Kamping_Kaiser> vila: shared at the server end? I think so. (I didn't set it up). I doubt theres been any 10mb commits to it, but I can't say i've kept very close tabs on it.
[13:21] <vila> Coke: sftp is not "smart" enough because it just provides us with a remote file system, when bzr wants to merge several pack files into a bigger one, it sill has to download the pack files and then upload the resulting one
[13:22] <Coke> vila: ok, I'll be honest, I dont understand how the protocol works
[13:22] <Coke> vila: but here's what I do know; only bazaar manage to turn my 24MB line into a 9k modem speed
[13:22] <vila> Coke: The "smart" server can do that locally and don't have to use any bandwith for that
[13:22] <Coke> vila: sftp in itself does not
[13:22] <Coke> vila: but I have 24MB!
[13:22] <Coke> I shouldn't have to worry about bandwidth
[13:22] <vila> Coke: what is your latency ?
[13:23] <Coke> around 30ms
[13:23] <vila> Are your repositories/branches used shared with others ?
[13:23] <Coke> no
[13:23] <Coke> and it doesnt matter
[13:24] <Coke> 1KB/s is just not acceptable after the introduction of 56k modems
[13:24] <Kamping_Kaiser> vila: its still "fetching revisions: inserting stream". is this a function of sftp? :/
[13:24] <Kamping_Kaiser> vila: it seems to be faster though, for the small commit i made to test
[13:24] <vila> Kamping_Kaiser: the message is expected
[13:24] <Coke> I get that too
[13:25] <vila> Coke: expected too
[13:25] <Coke> is regular ssh+bzr faster?
[13:26] <Kamping_Kaiser> vila: ok. so it has to download <an ammount> anyhow, i assume its related to what you just told Coke about the sftp issue :)
[13:26] <vila> Coke: bzr+ssh is almost always faster than sftp these days (at worst it should be as fast (or slow :))
[13:26] <vila> Kamping_Kaiser: Well, bzr has to check what history is available remotely to know what should be uploaded, so certainly the smart server is far better for that
[13:27] <Kamping_Kaiser> nod.
[13:27] <Coke> vila: all revision systems do that
[13:27] <vila> But the progress bar indicators are not the best tool to diagnose what is dowloaded/uploaded and whn
[13:27] <Kamping_Kaiser> when i do pushes i'll keep my eye on it and see if it seems to work consistantly better or not.
[13:28] <vila> Coke: We can discuss for hours why the old formats are bad, but I find it a bit less interesting than knowing if the new format and/or the smart server suitsyour needs or not
[13:28] <Coke> I went with bzr because of launchpad, basically
[13:29] <Coke> vila: does the smart server require me to add additional daemons server side?
[13:29] <vila> no
[13:29] <vila> as long as bzr is available in your path there is 0 setup
[13:30] <vila> if it's not you have to set BZR_REMOTE_PATH locally or bzr_remote_path in your locations.conf file
[13:30] <Coke> vila: hm. I don't think the host will allow me to run it
[13:30] <Coke> I asked before and they said "no, it hogs too much CPU, your shell account is not for running stuff, only for uploads"
[13:31] <Coke> might just move the repos elsewhere
[13:31] <Coke> Ok, thanks for yer help. I'll have to think about what to do next.
[13:32] <vila> Coke: try 2a, most of the people who tried were happy
[13:32]  * vila keeps talking alone :-.
[13:32] <vila> Kamping_Kaiser: so your commit test created a 7kB pack file, expected
[13:33] <vila> Kamping_Kaiser: you may want to try to correlate http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/?C=S;O=D with your expected upload times and see
[13:33] <vila> Kamping_Kaiser: and come back here to tell us or file a bug on launchpad
[13:34] <Kamping_Kaiser> vila: i assume its a new pack for every commit? or will bzr re-roll the packs now and then?
[13:34]  * bialix waves to vila
[13:34] <vila> \o
[13:34] <Kamping_Kaiser> and ftr, i'll definitely come here before dealing with LP ;)
[13:35] <vila> Kamping_Kaiser: a new pack for every commit, then merge the 10 into a bigger one, then the 10 big into, etc
[13:35] <wvd> I've installed bazaar, and now I wanted to do bzr branch lp:ubuntu-bots, but it's gives me some error: 'bzr: ERROR: Unable to create symlink 'bans.cgi' on this platform'
[13:35] <vila> Kamping_Kaiser: Is there a specific problem with LP ?
[13:35] <vila> wvd: running windows ?
[13:36] <Kamping_Kaiser> vila: let me use it for 10 min and I'll reply to that question... I never seem to feel the love though. (Its definitely not a politicial issue)
[13:36] <wvd> vila: yes
[13:36] <rubbs> wvd: windows has some issues with symlinks.
[13:37] <vila> Kamping_Kaiser: ok, just checking the meme "lp is closed source" wasn't acting again :)
[13:37] <rubbs> wvd: not sure what the work around is, since I haven't come across that problem yet
[13:37] <rubbs> wvd: maybe vila knows
[13:37] <vila> wvd: bzr doesn't support creating symlinks when doing a checkout
[13:37] <Kamping_Kaiser> vila: nah, I have (gasp) usability issues with it ;)
[13:37]  * Kamping_Kaiser heads off to do more hacking.
[13:38] <Kamping_Kaiser> vila: thanks for your help again, I'll bug you another day :)
[13:38] <wvd> vila: how would I do this manually?
[13:38] <vila> Kamping_Kaiser: EWRONGCHANNEL :-D You want #launchpad-dev :0P
[13:38] <vila> Kamping_Kaiser: Always happy to help (tm) !
[13:39] <bialix> :-)
[13:39] <Kamping_Kaiser> :)
[13:39] <vila> wvd: on windows ? You can't. You need a filesystem that support symlinks, I'm not sure you can find that (but I'd love to be proved wrong)
[13:39] <wvd> vila: However, is this new? Since like 1 month ago I did some bzr checkouts.
[13:39] <vila> wvd: There was a plugin that provided some support for that but bzr evolved and broke it
[13:40] <vila> wvd: then you have to talk with your upstream projects and explain them that using symlinks is not windows-friendly and see if they can find another implementation
[13:40] <wvd> vila: so any way to still do a checkout indirectly or something?
[13:41] <rubbs> wvd: if you don't have a system that supports symlinks, then I'm not sure what you can do.
[13:41] <vila> wvd: do you have access to some host running some unix or even a mac :-D
[13:42] <wvd> I got Ubuntu on this machine, though, my adapter is the *worst* supported, and I got tired of trying to get it work after 15 hours.
[13:42] <vila> wvd: otherwise you can try installing virtualbox and a Ubuntu guest but that's certainly not ... easy
[13:42] <vila> adpater ?
[13:42] <vila> adapter ?\
[13:42] <wvd> wifi usb adapter.
[13:42] <vila> :-/
[13:43] <vila> EWRONGCHANNEL ? :-D See #ubuntu-devel ??
[13:43] <vila> kidding
[13:43] <MvG> bialix: wrote a mail to bazaar@ and bazaar-announce@ to announce the trac-bzr 0.3.0 release.
[13:43] <vila> wvd: You have a dual-boot setup ?
[13:43] <wvd> vila: yes. (first time linux ever)
[13:43] <rubbs> wvd: vila's suggestion about virtualbox is not a very elegant solution, but it would work.
[13:44] <vila> rubbs: it's very elegant I use it on my desktop, on my laptop and on my other desktop too :-D
[13:44] <wvd> It's just 1 checkout.
[13:45] <bialix> MvG: \o/
[13:45] <vila> wvd: If I have a simpler solution, trust me, I'll tell you :D
[13:45] <vila> bialix: any idea about the symlinks issue ?
[13:45] <wvd> vila: Isn't there some site, which checkouts, and then uploads the file for you :P?
[13:45] <rubbs> vila: I mean that he wouldn't be able to use his native environment.
[13:45] <bialix> wvd: use Cygwin
[13:45] <vila> bialix: \o/
[13:46] <rubbs> wvd: you could try looking for a shell access site, but they tend to be very restricted environments
[13:46] <bialix> vila: :-D
[13:46] <wvd> Meh, I'll just wait for someone who develops it, and i'll ask him if he can upload it.
[13:47] <rubbs> bialix: does cygwin allow for symlinks? I wasn't aware of that
[13:50] <vila> wvd: there are 7 symlinks in that checkout in the root directory only
[13:51] <bialix> rubbs: yes, it emulates them
[13:51] <vila> wvd: all created in revno 123, so at best you can `bzr branch -r 123 lp:ubuntu-bots`
[13:51] <vila> rhaaa 122
[13:52] <vila> then you can contact http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/?C=S;O=D and askhim if they are really needed...
[13:52] <vila> rhaaa damn keyboard
[13:52] <james_w> hi vila, bialix
[13:52] <bialix> james_w: heya
[13:52] <vila> then you can contact Terence Simpson<EMAIL_ADDRESS>and ask him if they are really needed...
[13:53] <vila> hi james_w
[13:53] <rubbs> james_w: hello
[13:53] <james_w> hello rubbs
[13:55] <wvd> vila: it worked fine, thankyou.
[13:56] <vila> wvd: you realize the trunk is at revno 148 right ?
[13:56] <rubbs> wvd: I would highly suggest looking into Cygwin like bialix said. It might give you a more "complete" environment
[13:56] <wvd> vila: I basically only needed one plugin, and it doesn't seem to be changed that much, and yes I realize.
[14:20] <vila> wvd: One other trick you may use is `bzr export -r148  xxx.tar` and see if you have a tar that can workaround the symlink problem better than bzr
[15:06] <jam> morning vila
[15:06] <vila> morning jam :)
[15:07] <rubbs> morning jam
[15:17] <zekopeko_> hi
[15:17] <rubbs> zekopeko_: hello
[15:17] <zekopeko_> is there a way to see how big a bzr branch is before checkout?
[15:17] <zekopeko_> in MB
[15:18] <zekopeko_> i'm having problems with one on lp
[15:18] <rubbs> zekopeko_: how big the branch is or just a check out? a check out is just the working directory.
[15:18] <zekopeko_> well this one: https://code.launchpad.net/~gloobus-dev/gloobus/newInterface
[15:18] <zekopeko_> last night I got to some 300mb before quiting
[15:19] <zekopeko_> so either bzr on lp is broken or i'm doing it wrong or the author actually put insane amount of data in there (highly unlikely)
[15:21] <rubbs> zekopeko_: honestly I'm not sure if you can check the size beforehand.
[15:22] <zekopeko_> :(
[15:23] <rubbs> zekopeko_: I'll keep looking
[15:24] <jam> zekopeko_: looking here: http://bazaar.launchpad.net/~gloobus-dev/gloobus/newInterface/.bzr/repository/packs/
[15:24] <jam> it seems to be abuot 100MB or so
[15:24] <jam> about
[15:25] <jam> 300 sounds a bit big, but if you were fetching over http there are some inefficiencies
[15:25] <jam> I certainly wouldn't have thought it would be bigger than that
[15:25] <zekopeko_> man, what did he put in there?
[15:26] <zekopeko_> thanks for your help guys. any chance to point me to more efficient ways of getting the thing?
[15:27] <zekopeko_> just want to try that branch
[15:27] <rubbs> zekopeko_: did you use the lp: shortcut? that usually goes to bzr+ssh
[15:28] <zekopeko_> i don't have ssh keys on launchpad
[15:28] <rubbs> ah...
[15:28] <zekopeko_> guess it's time to add them :P
[15:28] <vila> so I just did that using lp: took less than a minute I think at 2MB/s
[15:29] <rubbs> I'd still suggest using the lp: shortcut. It tries the fastest ways first.
[15:29] <vila> the resulting working tree is 94MB with 89MB for .bzr
[15:29] <zekopeko_> i just used the one on the page
[15:29] <zekopeko_> bzr branch lp:xxxxxx
[15:29] <rubbs> yeah
[15:30] <jam> zekopeko_: yes, though you need to have logged into launchpad first, (set up a user id, ssh key, etc.)
[15:30] <jam> If you haven't done that 'lp:' will still go via http
[15:31] <zekopeko_> i'm registered, so just need to upload a key
[15:31] <jam> zekopeko_: k, then run 'bzr lp-login' so that we know what username to connect to lp with
[15:32] <vila> right, so using http stil saturate the badnwith at 2MB/s but tooks longer....
[15:33] <vila> jam: and no peaks, so definitely something wrong on your connection :-/
[15:33] <vila> reaching the 300MB and counting with http :-/
[15:33] <vila> done
[15:34] <vila> I missed the precise number but below 400MB
[15:35] <vila> exact same numbers for the resulting wt and associated .bzr dir, pfew
[15:35] <jam> vila: expected, but good to know it worked appropriately
[15:35] <vila> so 3 mins for http vs 1min for bzr+ssh, gee, upload your ssh keys :)
[15:36] <vila> since the bandwith was saturated that's indeed 3 times more data downloaded >-/
[15:37] <vila> there is a bunch of Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x2f35d50>, 28198373, 22489166) to an LRUSizeCache failed. value 45109186 is too big to fit in a the cache with size 41943040 52428800 messages in the log
[15:38] <vila> 14 to be precise occurring roughly every 10/12 seconds
[15:39] <vila> and also some '25 bytes left on the HTTP socket' that look quite dirty, who did that , sheesh
[15:40] <Tak> any monodevelop users in the house?
[15:41] <bialix> heya jam
[15:41] <jam> hi bialix
[15:41] <jam> vila: ouch...
[15:42] <jam> that would indicate that gloober has a single groupcompressblock > 45MB
[15:42] <jam> and it causes us to redownload it repeatedly over dumb transports
[15:42] <jam> zekopeko_: it looks like somebody added a 40+MB (gz compressed) file to your repository
[15:42] <jam> And probably modified it a few times
[15:43] <zekopeko_> thats how badchoice rolls (the author)
[15:43] <zekopeko_> :sigh:
[15:43] <rubbs> sounds like his name is appropriate
[15:44] <zekopeko_> i still don't get it how after almost 2 years he still doesn't get good development practices
[15:45] <jelmer> Tak: Yes :-)
[15:45] <rubbs> zekopeko_: some people just don't learn quickly ;)
[15:46] <vila> apart from the configure file and some Makefile I see nothing wrong here
[15:46] <zekopeko_> rubbs, i'm getting an error. i think that i did something wrong with the ssh thingy
[15:47] <vila> a couple of unfortunate ~ files, probably backups not worth versioning...
[15:47] <vila> jam: but no big image or other binary file
[15:47] <rubbs> zekopeko_: what's the error?
[15:47] <jam> vila: could have been added and deleted
[15:48] <vila> jam: yup, looking at log -v right now
[15:48] <zekopeko_> i accidentally added a private key to lp first, then deleted it and added a key i could remember the password for and finally did it right (tm) on the third try
[15:48] <jam> zekopeko_: glad you got it working
[15:48] <zekopeko_> jam not yet
[15:48] <zekopeko_> rubbs, Agent admitted failure to sign using the key.
[15:48] <jam> ah, I thought "did it right" meant it worked
[15:49] <zekopeko_> i did bzr lp-login mylogin
[15:49] <zekopeko_> and that doesn't report any error but once i try branching that message pops up
[15:49] <vila> here we go, tar.gz, jpg, pdf, first commit :)
[15:50] <vila> lol, even a git repo !
[15:50] <vila> part of it removed in revno 15
[15:51] <rubbs> zekopeko_: what OS are you running?
[15:51] <zekopeko_> 9.10
[15:51] <rubbs> hmmm...
[15:52] <rubbs> jam: do you know what's going on with zekopeko_'s error?
[15:52] <jam> zekopeko_: have you done "ssh-add" ?
[15:52] <vila> zekopeko_: is src/gloobus an executable ?
[15:53] <Tak> jelmer: hi :-)
[15:53] <zekopeko_> jam no
[15:53] <zekopeko_> i'm following the faq
[15:53] <zekopeko_> and adding with the web interface
[15:53] <jelmer> Tak: hey
[15:53] <Tak> jelmer: can I send you an mpack to test, or have you test the one generated by the tip of my md-bzr branch?
[15:53] <jam> vila: so .git was added in 1, removed in 15, added *again* in 76
[15:54] <jam> deleted in 81
[15:54] <vila> revno 76 another bunch of... jam beat me :)
[15:54] <zekopeko_> vila have no idea
[15:55] <zekopeko_> i wouldn't be surprised
[15:55] <Tak> (with md 2.2)
[15:55] <rubbs> I don't claim to be even a decent developer, but holy crap that's some bad repo usage
[15:56] <zekopeko_> rubbs, http://paste.ubuntu.com/343769/
[15:56] <vila> well, people deserves the right to be creative in the way they use the tool
[15:56] <zekopeko_> rubbs, i'm no dev but even i know that you don't do shit like that
[15:57] <zekopeko_> just have to catch him on irc and bug him i guess
[15:57] <jam> zekopeko_: what is your lp username?
[15:57] <zekopeko_> zekopeko
[15:57] <vila> zekopeko_: either you didn't upload the right ssh key or you don't present the right ssh to lp or you didn't inform your ssh agent to use a new key
[15:58] <zekopeko_> i'm just gonna delete the .ssh folder and start over
[15:58] <vila> eerk no !
[15:58] <jam> zekopeko_: you have one ssh key uploaded, ending with: zekopeko@leviathan
[15:58] <jam> which seems reasonable
[15:58] <zekopeko_> yup
[15:58] <zekopeko_> the problem is probably this:
[15:58] <jam> at least it looks like an ssh public key
[15:59] <zekopeko_> i accidentally added a private key to lp first, then deleted it and added a key i could remember the password for and finally did it right (tm) on the third try
[15:59] <vila> zekopeko_: what does 'ssh-add -l' says ?
[16:00] <zekopeko_> 2048 96:fb:9d:34:cd:50:98:7f:9c:1e:a6:2f:40:39:e9:a3 zekopeko@leviathan (RSA)
[16:02] <rubbs> zekopeko_: I'm out of ideas, but vila and jam are regular contributors, they can really help you out.
[16:02] <vila> zekopeko_: do 'ssh-add -D' then try again your agent may have kept a previous key
[16:04] <zekopeko_> did that now what?
[16:04] <zekopeko_> still doesn't work
[16:05] <rubbs> zekopeko_: not that you need to use this solution forever, but what if you used a non-password procected key?
[16:05] <rubbs> at least until we figure out what's going on
[16:05] <vila> zekopeko_: going to manual mode :) try 'ssh -v<EMAIL_ADDRESS>[16:05] <vila> that should fail but tell us why
[16:06] <vila> !paste
[16:06] <zekopeko_> http://paste.ubuntu.com/343771/
[16:09] <zekopeko_> hmmm... perhaps a complete delete .ssh and start over would work?
[16:09] <vila> try logout/login first
[16:10] <vila> the paste above confirms a problem with the agent or a mismatch so just restarting it should be enough and logout/login is the easiest to ensure you get that right
[16:14] <zekopeko_> vila, no go
[16:14] <vila> you entered your password again ?
[16:14] <zekopeko_> in the web interface right? if so yes
[16:15] <vila> no, locally, your ssh agent should ask for the passphrase protecting your private key
[16:15] <vila> what web interface are you referring to ?
[16:16] <zekopeko_> but how do i log out?
[16:16] <zekopeko_> i'm guessing bzr lp-login zekopeko logs in
[16:17] <vila> ha sorry, I meant logout/login from your Ubuntu session
[16:17] <vila> the one that manage the ssh-agent
[16:18] <zekopeko_> oh i thought on lp.net
[16:18] <zekopeko_> that the problem was there and not here
[16:18] <vila> yeah, sorry, bad explanation from me :(
[16:18] <zekopeko_> ok wait
[16:19] <vila> yeah, I noticed he didn't quit but I thought he was using some irc proxy... doesn't match the ssh problem though :-/
[16:20] <zekopeko_> villa yey, it works!
[16:20] <zekopeko_> thank you
[16:20] <vila> zekopeko_: well done !
[16:20] <vila> zekopeko_: Always happt to help (tm) ! :D
[16:21] <vila> gee, yet another long day....
[16:21] <vila> zekopeko_: Always happy to help (tm) ! :D
[16:22] <rubbs> vila: thanks for taking over that problem. I try to help when I can, but I'm not always great at troubleshooting everything
[16:26] <zekopeko_> no to see if it's gonna make
[16:32] <vila> rubbs: you're doing fine ! (sry was on the phone)
[16:34] <bialix> good weekend for everyone, bye
[17:06] <Anthony_> hi.
[17:06] <Anthony_> how can use bzr+ssh with non-standard port ?
[17:09] <Anthony_> sorry
[17:09] <Anthony_> already found, have a nice day
[18:35] <ronny> NET||abuse: those add new commands to the bzr cli as far as i can tell
[18:35] <ronny> oh man
[18:36] <NET||abuse> ??
[18:36] <ronny> i just noticed i was scrolled back damn much
[18:36] <NET||abuse> :P
[18:36] <NET||abuse> this re: bzr qlog
[18:36] <NET||abuse> ?
[18:36] <ronny> when you asked why those didnt add entries in the applications menu
[18:37] <ronny> bbl
[18:37] <NET||abuse> :) yeh, i thought there was a qt front end app that was just like a full gui application that could be used as a front end to bzr in general, not just the revision history stuff :)
[18:38] <NET||abuse> but, that said, i'm very happy working cli now,, it's a little tricky switching between svn, bzr and git from time to time, not to mention when i'm pulling from mercurial. :)
[18:38] <NET||abuse> but overall, i'm comfortable with bzr at this point.
[18:39] <NET||abuse> pretty comfortable with svn also.
[18:39] <NET||abuse> git is still a little alien, and hg... welll, i really havn't a clue.
[18:41] <rubbs> it can be hard to learn so many
[18:41] <rubbs> especially since some of the terms mean different things to different VCS's
[18:41] <jam> vila:  are you still around?
[18:41] <NET||abuse> rubbs, oh god really? there's terminology collision?  eg?
[18:41] <vila> jam: for a couple of minutes
[18:41] <rubbs> I should rephrase that
[18:42] <ronny> NET||abuse: yup, i learned the guts of all 3, there are various weird differences
[18:42] <vila> jam: I'm finishing my patch pilot summary mail
[18:42] <jam> vila: I was wondering if you have the ec2 tools on babune
[18:42] <rubbs> I meant that the workflow descriptsions seem similar until you really get into them
[18:42] <jam> I'm unable to bundle the instance
[18:42] <ronny> hm, all 4 i meant
[18:42] <vila> jam: no idea, so propably not
[18:42] <jam> and I'm not even getting a failure message
[18:42] <NET||abuse> ah, yeh, i'm mostly in bzr and svn these days,, i'm leaving git till i really need to learn it..
[18:42] <vila> what are they ?
[18:42] <jam> vila: well 'ec2-bundle-vol' is the command
[18:42] <jam> but sure
[18:42] <jam> if you don't know them, you probably haven't installed them
[18:43]  * vila fires synaptic
[18:43] <rubbs> NET||abuse: good idea. I'm attempting to learn git as well, but it's slow going...
[18:43] <NET||abuse> i'm very happy with bzr.
[18:43] <NET||abuse> i just do alot of solo web dev..
[18:44] <vila> jam: ec2-ami-tools and ec2-api-tools seem relevant ?
[18:44] <jam> vila: yes
[18:44] <vila> jam: one of them ? both ?
[18:44] <jam> might be an 'ami' tool, but probably both are worthwhile
[18:44] <jam> one may depend on the other
[18:44] <jam> (ami seems like it would depend on api)
[18:45] <NET||abuse> but from time to time someone else joins me, so for the most part, i have my local repo, then i push that up to the hosting server storage, below webroot, and export the code from that to the live site for rollout, but also means i can jump computers(i have 3 laptops) or allow another dev, or designer to join me in working on it very easily.
[18:45] <vila> no dependencies, both installed, try again
[18:45] <NET||abuse> rubbs, so i'm sorta centralized, but distributed when i want to be :)
[18:46] <jam> vila: 'ec2-bundle-vol' is now present. Thanks
[18:46] <rubbs> NET||abuse: whatever works. there's no reason to change things up if what is working now is fine.
[18:59] <vila> jam: for the record, ec2-bundle-vol is part of ec2-ami-tools
[18:59] <alex_> hi
[19:00] <jam> vila: well, I actually needed ec2-bundle-instance, but I assume that is in the same tool
[19:01] <vila> jam: no ! It's part of ec2-api-tools !
[19:01] <jam> :'(
[19:02] <alex_> is anyone know why the stable update-site (for bzr eclipse plugin) is unavailable ?
[19:02] <jam> vila: well, issuing the command via ec2-bundle-instance did, indeed get it to work as I wanted
[19:02] <vila> jam: great
[19:03] <jam> of course, now to understand why ElasticFox is der-broken
[19:03] <jam> ....
[19:03] <vila> alex_: did you check recently ? I thought it was broken by the redirection but fixed since...
[19:04] <jam> vila, alex_: I believe bzr-eclipse (not qbzr-eclipse) was just removed because it had not been updated in a long time
[19:04] <jam> I could be remembering wrong
[19:04] <jam> but yes, both were broken by the bazaar-vcs.org => bazaar.canonical.com change
[19:04] <alex_> qbzr is another eclipse plugin ?
[19:04] <alex_> i'v been on the wiki to pickup the stable url
[19:04] <jam> qbzr-eclipse is an eclipse plugin that wraps the qbzr ui
[19:04] <jam> versus a closer-integrated eclipse ui
[19:05]  * vila crashes
[19:05] <vila> Have a nice day all !
[19:05] <rubbs> night!
[19:05] <alex_> night !
[19:13] <hazmat> hmm.. so in a working copy i do a bzr merge ../branch.. bzr revert -R . ... and then if i do a bzr merge ../branch  i get an exception with traceback http://gist.github.com/259691
[19:14] <hazmat> basically i tried to back out of a merge with revert, and then when i went to do it again.. bzr barfed.
[19:15] <james_w> hazmat: just use "bzr revert" to revert the merge
[19:15] <hazmat> james_w i tried to that.. order of steps to reproduce exception was . bzr merge.. bzr revert .. bzr merge
[19:16] <hazmat> ^do
[19:16] <james_w> hmm
[19:17] <james_w> sounds like bug 336618
[19:17] <salgado> vila, around?
[19:17] <james_w> salgado: he left 10 minutes ago
[19:17] <james_w> of course, he might not really be gone :-)
[19:18] <salgado> oh, that's a shame.  will have to bother next week's pilot, then
[19:18] <hazmat> james_w yup thats the same issue it looks like
[19:18] <james_w> salgado: can I help?
[19:19] <rubbs> salgado: maybe we can help you. what's up?
[19:19] <salgado> james_w, maybe.  I'm giving a go at fixing bug 317896
[19:20] <james_w> ah, cool
[19:20] <salgado> I did what jam suggested, but tree.changes_from(workingtree) gives me a TreeDelta and I couldn't find a way to extract a diff from that
[19:20] <james_w> so, what I would do here is look for cmd_diff in bzrlib/builtins.py
[19:20] <james_w> that will show how "bzr diff" draws diff
[19:21] <james_w> it's something like bzrlib.diff.show_diff_trees(tree1, tree2) or something
[19:21] <salgado> yeah, I was able to get a diff using that
[19:21] <james_w> show_diff_trees(old_tree, new_tree, sys.stdout)
[19:22] <salgado> but it includes lots of garbage (e.g. [19:22] <jam> hazmat: it looks like you did a partial revert (-R .), which would hint that you are then doing 'bzr merge --force', is that true?
[19:23] <salgado> james_w, and, since it's a diff between the working tree and the PreviewTree containing the shelved changes, all uncommitted changes show up in the diff as removed
[19:23] <jam> salgado: an executable bit change would be considered a change
[19:23] <james_w> (setting old_label and new_label could help make it clear whether it is the diff that would be applied that is shown, or the diff that was taken away)
[19:24] <james_w> salgado: could you pastebin your diff to trunk? I'd like to see the approach you are taking.
[19:24] <salgado> james_w, diff.show_diff_trees(self.tree, merger.other_tree, sys.stdout) is what I did
[19:24] <jam> salgado: so there are a few possible diffs to show
[19:24] <jam> 1) the diff versus the committed state and the current state (what you are doing)
[19:24] <jam> s/committed/shelved/
[19:25] <jam> 2) the diff of shelved state versus its basis state (what was shelved)
[19:25] <jam> 3) the diff of the shelved state applied to the current state versus the current state
[19:25] <jam> the latter is *probably* what people want
[19:25] <salgado> right
[19:25] <jam> but requires doing the steps to stage the unshelve into limbo
[19:25] <jam> and do the diff from there
[19:25] <james_w> I'd argue that --dry-run has to show the latter
[19:26] <james_w> we could add the others, but having --dry-run not show what unshelve would do would be confusing
[19:26] <jam> james_w: only in that we are using --dry-run to say 'show me the contents', if we had a different 'show me the contents'
[19:26] <jam> as you said
[19:27] <james_w> so, I would use the same as merge --preview to do this
[19:27] <james_w> get the Unshelver
[19:27] <james_w> merger = unshelver.get_merger()
[19:27] <hazmat> jam it happens with or without the -r flag
[19:27] <james_w> tt = merger.make_preview_transform()
[19:28] <james_w> result_tree = tt.get_preview_tree()
[19:28] <jam> hazmat: not '-r', -R
[19:28] <james_w> show_diff_trees(merger.this_tree, result_tree, sys.stdout)
[19:28] <jam> 'bzr revert' no options
[19:29] <hazmat> jam.. trying
[19:29] <james_w> tt.finalize()
[19:29] <salgado> james_w, cool, let me give this one a go
[19:31] <hazmat> jam.. it triggers the error with a naked revert .. http://gist.github.com/259699
[19:31] <hazmat> is a shell script that reproduces it
[19:32] <jam> hazmat: you still have '.' in there, right?
[19:32] <jam> (bzr revert .) versus (bzr revert) ?
[19:32] <jam> from what you've written, I would guess it only happens when 'b' has no ancestry
[19:32] <salgado> thanks jam, james_w!  I'll now figure out how to write a test for it.
[19:32] <james_w> it works?
[19:33] <hazmat> jam.. ah
[19:33] <salgado> james_w, yep.  don't you trust your code!? ;)
[19:33] <james_w> not at all!
[19:33] <jam> this is actually the "merge into a branch with no history" bug, plus a little bit extra
[19:34] <jam> something that we could support, but really doesn't happen in practice
[19:34] <jam> since,, you generally have history
[19:34] <jam> :)
[19:36] <hazmat> jam, it happens with 'bzr revert', and it happened to me in practice when i had history
[19:47] <hazmat> jam possibly it wouldn't have happened to me in practice if had used "bzr revert" instead of "bzr revert ." but thats a disconcerting fragile distinction imo
[19:54] <jam> hazmat: bzr revert . is quite a bit different from bzr revert
[19:55] <jam> the former doesn't remove the pending merges
[19:55] <jam> just reverts the file content
[19:55] <jam> if you had history
[19:55] <jam> the next 'bzr merge' would refuse because it thinks you have pending changes (the pending merge should be committed)
[20:40] <johnjosephbachir> Is there a recommended set of things to check before killing off a branch -- i can check for local changes, and if there is anything on the shelf -- is there anything else to check? any single command to use to see if deleting a branch won't lose work?
[20:41] <lifeless> lastlog lifeless
[20:44] <rubbs> johnjosephbachir: that's basically all I check, but my workflow is to just create a feature branch and then delete it when I'm done.
[20:44] <rubbs> don't know if that helps, but there it is.
[20:44] <johnjosephbachir> it does help
[20:44] <johnjosephbachir> thanks
[20:44] <rubbs> np
[20:53] <ronny> is there any way to get tags as repo objects instead of that britle text file of references?
[21:03] <joaopinto> hi
[21:03] <joaopinto> bzr: ERROR: No such file: 'hlmad90t8zneqx2ad024.pack': [Errno 2] No such file or directory: '/home/janito/workspace/debfactory/.bzr/repository/upload/hlmad90t8zneqx2ad024.pack'
[21:04] <joaopinto> how do I recover from this error ? it's happening during a commit
[21:11] <cellofellow> how do I remove a "submit branch" from a branch?
[21:18] <joaopinto> manually creating the upload dir resolved my problem
[21:22] <lifeless> ronny: hi
[21:22] <lifeless> ronny: branch.tags
[21:27] <ronny> lifeless: i meant that in a repo format sense, i know the api
[21:27] <ronny> lifeless: oh, and hi
[21:59] <ronny> hmm, how do i get bzr to color diffs?
[22:09] <james_w> ronny: bzrtools has cdiff
[22:09] <ronny> hmm, i remembered that vc actually colors diffs, even from bzr
[22:10] <djbclark> so just googled for this for about 10 minutes, no luck... how does one list all remote branches under a certain point using bzr? I did find a page that showed how to do it with some git bzr-using magic, but that seems suboptimal.
[22:11] <james_w> djbclark: bzr branches URI might be what you want
[22:15] <Kamping_Kaiser> james_w: /win 33
[22:15] <Kamping_Kaiser> oops
[22:15] <Kamping_Kaiser> james_w: bzr: ERROR: unknown command "branches"
[22:16] <Kamping_Kaiser> seems to not exist in 2.0.2 :/
[22:16] <james_w> hmm, is that bzrtools as well?
[22:17] <Kamping_Kaiser> don't think iv'e got bzrtools atm, that might be the cause
[22:19] <djbclark> Kamping_Kaiser: yeah I just installed pretty much anything that looked bzr-related and it's churning away at something (eg no immediate no command return)
[22:22] <djbclark> yep, that's a long hang, still sitting there... status would be nice ;-)
[22:22] <Kamping_Kaiser> thats a big think. whats it doing, downloading the world?
[22:22] <djbclark> Kamping_Kaiser: no just "bzr branches<EMAIL_ADDRESS>[22:23] <djbclark> Kamping_Kaiser: I should prob try the non-sftp URL, but now I'm intriqued to see if it ever times out.
[22:24] <Kamping_Kaiser> theres about a dozen branches, iirc.
[22:25] <ronny> oh my goodness
[22:25] <ronny> how do i get bzrtools cdiff to use green instead of that blue
[22:25] <djbclark> Kamping_Kaiser: ooo it actually did finally work
[22:25] <djbclark> lols
[22:26] <Kamping_Kaiser> djbclark: huzzah :) is it any faster over http?
[22:26] <ronny> hmm, i suppose i'll just have to use `vc diff`
[22:28] <djbclark> Kamping_Kaiser: not so much
[22:41] <lifeless> jkakar: you should get commandant packaged ;)
[23:24] <scorp007> hi, is it possible to, after having done a lw-checkout, turn it into a full checkout?


[00:21] <chris4585> ah
[15:06] <wrst> http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services/
[19:30] <Unit193> wrst: Also, interesting.  Good thing I don't use it, but should check the files there.
[19:30]  * Unit193 be "using" dropbox.
[19:31] <wrst> Unit193: ever used copy?
[19:32] <Unit193> I presume you don't me cp file file2 dir/ :P
[19:36] <wrst> no copy.com like dropbox but a lot more storage
[19:38] <wrst> https://copy.com?r=C4gXNY
[19:39] <wrst> if you want to thats ^^^ my referral link gets us both 5 extra GB
[19:39]  * wrst feels like such a troll now...
[19:43] <Unit193> Technically if I went for it, that'd be actually giving us both more storage. :)
[19:44] <wrst> yes it would
[19:52] <Unit193> Doesn't seem to be much information there. :/
[19:54] <wrst> i wouldn't treat it as secure but it stores files like dropbox
[19:55] <wrst> of course no ppa for ubuntu, but a package for arch ;)
[19:55] <Unit193> Hah. :P
[19:55] <Unit193> http://softwarebakery.com/maato/thunar-dropbox.html that's why dropbox has a point in it's favor.
[19:56] <wrst> ahh makes sense
[19:58] <Unit193> First went to their site, thought it was a bit slow, but forgot I was using a proxy. :P
[20:13] <wrst> of course you were
[20:19] <Unit193> Heeey, I don't always, I was checking something.
[20:34] <wrst> of course you were
[20:38] <cyberanger> Unit193: never forget using good security & anonmyity measures
[20:38] <cyberanger> ;-)
[20:50] <Unit193> This wasn't that, really! :P
[20:55] <cyberanger> Unit193: sure it was, for me.


[09:13] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Focal 20.04.5] has been marked as ready
[11:43] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server arm64+raspi [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server riscv64+unleashed [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server armhf+raspi [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server riscv64+unmatched [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.5] has been marked as ready
[12:06] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.5] has been marked as ready
[12:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.5] has been marked as ready
[13:01] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Focal 20.04.5] has been marked as ready
[13:02] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop amd64 [Focal 20.04.5] has been marked as ready
[13:15] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.5] has been marked as ready
[13:15] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.5] has been marked as ready
[13:15] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base amd64 [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base armhf [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base riscv64 [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Server riscv64+unleashed [Focal 20.04.5] has been disabled
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base arm64 [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base s390x [Focal 20.04.5] has been marked as ready
[14:00] -queuebot:#ubuntu-quality- Builds: Ubuntu Base ppc64el [Focal 20.04.5] has been marked as ready