=== JasonO is now known as MisterX
=== hunger_ is now known as hunger
[08:25] <jam> morning all
[08:25] <jam> poolie: How would you like me to call in?
[08:26] <maxb> morning :-)
[08:26] <fullermd> Shucks, morning _again_?  I haven't recovered from the last one yet.
[08:26]  * maxb is in the millbank lobby
[08:28] <jam> maxb: I'm glad you have network access in the lobby :)
[08:29] <jam> Are there big angry guards keeping you out?
[08:29] <maxb> android ftw - network access anywhere
[08:30] <maxb> apparently no one's answering the phone in the office yet
[08:30] <jam> maxb: I thought you just talked to the front desk, gave them your name, and they give you a visitor's badge.
[08:30] <maxb> which is completely reasonable considering how early I am
[08:30] <jam> but I haven't been to London in about 3 years
[08:30] <jam> 9am is start time, so 9:30 is ... late :)
[08:31] <jam> maxb: did you try poolie's cell phone? He has one just for london
[08:31] <maxb> jam: it's currently 08:30
[08:31] <jam> maxb: huh, I didn't think there was a TZ difference from here. Ok
[08:32] <GungaDin> I need to create a patch from bzr diff and apply it on a different branch... but I always get that the patch is ignored... how do I do that?
[08:32] <jam> GungaDin: "bzr diff | patch -p0" ?
[08:33] <GungaDin> ?
[08:33] <GungaDin> I need to apply the patch on a different branch
[08:34] <jam> GungaDin: bzr diff > file.patch; cd ../other/branch; cat file.patch | patch -p0
[08:34] <GungaDin> but that way I get that a lot of hunks fail.
[08:44] <jam> GungaDin: then are you sure the patch would apply cleanly anyway?
[08:44] <jam> are you trying to merge a bunch of changes?
[08:45] <GungaDin> jam - no, I'm not.
[08:45] <jam> GungaDin: if it is simple enough, then you could go "cd different/branch; bzr merge ../original/branch"
[08:45] <jam> And if you just want some of the changes you can specify a range to merge
[08:45] <jam> however, if you are getting conflicts, my guess is that the patch *just doesn't apply*.
[08:46] <jam> We can't make your changes apply to code that doesn't look like the "pre" version.
[08:54] <LarstiQ> GungaDin: can you explain in more detail what you are trying to accomplish?
[08:55] <GungaDin> that's alright.. I suppose it's natural that all those hunks are failing.
[08:55] <GungaDin> the other branch has progressed substantially.
[08:55] <bialix> hi sprinters, are you already running?
[08:56] <LarstiQ> GungaDin: so why diff/patch and not merge?
[08:57] <LarstiQ> bialix: maxb was in the milbank lobby at 08:30, but no one to let him in yet
[08:57] <GungaDin> because those changes haven't been committed to the other branch, nor should they now.
[08:57] <LarstiQ> GungaDin: you could try merge --uncommitted
[08:57] <bialix> LarstiQ: are you also in?
[08:57] <LarstiQ> bialix: I'm not sprinting
[08:57]  * LarstiQ shouldn't be here either ;)
[08:57] <bialix> hehe
[08:58] <fullermd> Sprinting's not my thing.  I'm sitting on the finish line, making sure it doesn't blow away.
[08:58] <LarstiQ> just 5 more minutes and then I'll make my Fourier homework, I promise!
[08:58] <LarstiQ> fullermd: :)
[08:59] <bialix> oh, Fourier, so nice
[09:00] <bialix> fullermd: we don't have spring here in my city. Yesterday was cold winter, and tomorrow will be hot summer.
[09:00] <fullermd> Oh, that's nothing.  We have 2 seasons here; summer, and January 15th.
[09:00] <bialix> rotfl
[09:01] <jam> LarstiQ: who needs to actually finish a dissertation? I thought it was the journey that mattered :)
[09:01] <bialix> wait, why 15th and 14th?
[09:01] <bialix> wait, why 15th and *not* 14th?
[09:01] <LarstiQ> jam: unfortunately (finally) getting my bachelor is required for being allowed to study towards a masters degree in Finland
[09:02] <fullermd> I dunno.  I'm prejudiced against multiples of 7, maybe.
[09:02] <LarstiQ> bialix: because the 14th is my birthday? ;)
[09:02] <bialix> January 14th is old new year here in xUSSR
[09:02] <fullermd> Maybe the sun hasn't gotten the news about Gregorian yet.
[09:04] <LarstiQ> fullermd: did someone send it a message by pigeon carrier again? Those always burn up prematurely.
[09:04] <fullermd> Just need faster pigeons.
[09:05] <fullermd> Of course, if they go too fast, they slingshot around and travel back in time.
[09:05] <fullermd> Sometimes even to somewhere under Julian calendars, which just adds to the confusion.
[09:05] <bialix> right
[09:25] <spiv> jam: how would you like to be called in? :)
[09:26] <jam> spiv: Skype has seemed to be the most reliable in the past.
[09:26] <jam> spiv: but I have mumble and Ekiga as well
[09:32] <poolie> hi jam
[09:32] <jam> morning poolie
[09:33] <poolie> if you have something connected to our voip system, i think calling the table phone here would be good
[09:33] <poolie> which is um
[09:33] <poolie> 2428
[09:39] <poolie> any good?
[09:39] <jam> trying now
[09:39] <jam> "User not found"
[09:40] <jam> ah, you have to dial the millbank prefix first, I think
[09:41] <poolie> you might need to use a headset
[09:41] <lifeless> jam: in ekiga? I think you need a 5 or a 9 before it
[09:41] <poolie> hi lifeless
[09:41] <spiv> lifeless: he's connected
[09:42] <poolie> you can dial itn too if you wish
[09:42] <poolie> he's just echoy
[09:42] <jam> lifeless: yeah, 51
[09:42] <jam> for millibank
[09:43] <lifeless> poolie: hi; uhm, I'll pass (2040 here - family time :P)
[09:44] <spiv> lifeless: your bzr family misses you too :P
[09:44] <lifeless> awww
[09:44] <fullermd> Also, I spilled my milk in the corner...
[09:44] <lifeless> I would have loved to be at uds
[09:44] <lifeless> and the upcoming bzr sprint
[09:45] <Merwin> Please, I can't apply a patch. In the patch file, the file 'xxx.yy', whereas in the path it is 'settings/xxx.yy'. I that's why bzr can't apply it
[09:45] <Merwin> How can I do?
[09:47] <poolie> Merwin: use plain patch and say 'patch settings/xxx.yy < foo.patch'
[09:49] <poolie> lifeless: wow that's a bit tz gap
[09:49] <poolie> it's funny to see it from the other side
[09:50] <Riddell> hi poolie
[09:51] <Merwin> poolie: Thanks ;)
[09:53] <poolie> can you hear that jam?
[10:12] <jam> spiv: that's a *long* push
[10:15] <jam> brb, door
[10:16] <jam> back
=== spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
[10:23] <lifeless> poolie: 11h at a guess :)
[10:43] <poolie> yes, it is 11h
[10:43] <poolie> have a good night
[10:43] <poolie> we can have a chat at some better time if you like
[10:45] <lifeless> sure
[10:46] <jam> poolie: ~100k calls
[10:46] <jam> same for emacs
[10:46] <jam> very linear history
[10:46] <jam> it can't expand quickly
[11:09] <mgz> hi!
[11:27]  * bialix waves at mgz
[11:27]  * bialix has bzr t-shirt put on today
[11:28] <jam> poolie: yes, I can hear him
[11:29]  * mgz waves at bialix
[11:30] <mgz> I asked riddell if he'd like to look at qbzr too :)
[11:31] <Riddell> get your requests in fast while I'm still looking for things to do :)
[11:36] <jam> looks like "dist-upgrade" just decided that Ekiga needs to die.
[11:36] <jam> I'm going to go to lunch real quick while the upgrade finishes
[11:37] <spiv> maxb: http://packages.python.org/manuel/
[11:54] <bialix> hi Riddell! There is one bug I need somebody with Ubuntu expertise to look at and maybe provide some feedback: https://bugs.launchpad.net/bugs/782926 Actually any feedback will be helpful
[11:54] <ubot5> Ubuntu bug 782926 in unity "[Unity] Application doesn't show up in Launcher when open" [Undecided,New]
[11:55] <poolie> hi bialix
[11:55] <poolie> i think it's a nuity bug
[11:55] <poolie> i retargeted it
[11:55] <bialix> hi poolie :-D
[11:55] <Riddell> yes, sounds like Unity, it works fine in KDE
[11:56] <bialix> I remember last year we have fixed a bug with Mac, with help of kaaloo
[11:56] <bialix> Riddell, poolie: great
[11:57] <Riddell> I wonder if adding a TryExec= line would help
[11:58] <mgz> whoops. tried too big a chunk of selftest and got some bits of my desktop reaped.
[11:58]  * mgz will be back shortly
[12:28] <mgz> well, mostly working again but the session is borked somehow so xfwm4 doesn't come up on its own
[12:41] <vila> bialix: \o_ me and spiv wear the same T-shirt too ;)
[12:41] <bialix> ole, ole-ole-ole!
[12:54] <vila> bialix: hmm, sounds like football supporter chanting... Was it the intended effect ? ;)
[12:54] <bialix> vila: make you smile, no more
[12:55] <vila> bialix: worked :D
[12:55] <bialix> :-D
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[13:55] <jam> poolie: let me know when you guys come back from lunch
[13:58] <jam> spiv: what is the status of your new Twisted patch? Has it landed upstream, and can it be deployed to LP?
[13:58] <jam> I had a branch of LP that handled I think 2 more cases of exception => slow Failure objects
[13:58] <jam> but I don't really want to push on it, if we can just make Twisted better for Launchpad
[13:59] <poolie> we're back
[14:00] <poolie> but now i'm off for a bit
[14:02] <spiv> jam: yes and probably
[14:10] <jelmer> hey jam :)
[14:11] <jam> hi jelmer
[14:19] <james_w> hi sprinters
=== med_out is now known as medberry
[14:23] <jam> hi james_w
[14:32] <james_w> hi jam
[14:32]  * jelmer waves
[14:34] <jelmer> verterok, ping
[14:34] <verterok> jelmer: hi! (pong)
[14:41] <verterok> jelmer: reviewing :)
[14:41] <vila> james_w: \o_
[14:41] <vila> verterok: hey !
[14:42] <jelmer> verterok, :)
[14:42] <jelmer> verterok, thanks :)
[14:42] <verterok> vila: hi! how's going? :)
[14:42] <verterok> thank you :)
[14:42] <vila> verterok: very well, back in Millbank where we meet... nice memories :)
[14:42] <vila> s/meet/met/
[14:43] <verterok> oh, nice. indeed!
[14:44] <verterok> jelmer: approved and merged, thanks!
[14:48] <jelmer> verterok: thank you :)
[14:51] <spiv> jam: http://askubuntu.com/questions/29757/what-can-replace-system-monitoring-in-the-top-gnome-panel-in-unity
[14:51] <jam> http://www.techdrivein.com/2011/05/10-useful-application-indicators-for.html
[14:54] <spiv> jam: http://albertomilone.com/wordpress/?p=502
[14:56] <poolie> hi all; statik says hi
[14:57] <poolie> hi james_w
[14:57] <spiv> jam: https://bugs.launchpad.net/unity/+bug/752098
[14:57] <ubot5> Ubuntu bug 752098 in unity (Ubuntu) "In a dual monitor setup with different resolutions, Unity places windows in the "dead zone"" [Low,In progress]
[15:32] <jamestunnicliffe> Hi, I have a branch on LP that has changed stacked on location. It is now set as: stacked_on_location = /~linaro-image-tools/linaro-image-tools/trunk
[15:32] <jamestunnicliffe> I am getting an error when I check out
[15:32] <jamestunnicliffe> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for StaticTuple('__init__.py-20100827182754-i149503ctn97gm7c-2', 'salgado@canonical.com-20110128195048-5w2xc3ya7havirtn')")
[15:33] <jamestunnicliffe> I am guessing I have done something wrong.
[15:33] <jamestunnicliffe> Looking at a branch stacked on the new location, it has a branch.conf with stacked_on_location = /+branch-id/355746
[15:33] <jam> spiv: I'm trying to call but the phone just rings. Should I try again?
[15:34] <Riddell> jam: spiv is in a meeting
[15:34] <jamestunnicliffe> Should I use that? Seeing a number in there made me worry that it may be tied to a rev.
[15:34] <jam> ah, thanks Riddell
[15:34] <Riddell> jam: the speakerphone is saying missed calls
[15:34] <Riddell> so maybe it did get your calls but didn't ring at us
[15:34] <jam> jamestunnicliffe: the number there is the launchpad db id for the branch you are stacking on
[15:35] <jam> Riddell: trying again now
[15:35] <jam> thanks
[15:35] <Riddell> you're back!
[15:35] <Riddell> they're talking about C
[15:36] <jamestunnicliffe> jam: Just tried with the launchpad db id, same error. Maybe it is a real bug.
[15:38] <jam> jamestunnicliffe: the AbsentFactory is a real bug. It indicates a file text that we think we should have but is not present.
[15:38] <jam> I don't know *why* we think it should be there but it isn't
[15:38] <jam> but there is something missing.
[15:38] <jamestunnicliffe> Ah
[15:38] <jam> the question is where is it, why isn't it where we expect, etc.
[15:38] <jam> jamestunnicliffe: what is the original branch you were trying to branch from?
[15:40] <jamestunnicliffe> I think it was lp:~linaro-maintainers/linaro-image-tools
[15:40] <jam> jamestunnicliffe: there is a segment missing
[15:40] <jam> lp:~USER/PROJECT/BRANCH
[15:41] <jam> you only have 2
[15:41] <jam> or lp:PROJECT/SERIES but you have ~
[15:41] <jamestunnicliffe> I would guess there was a trunk on there. I will just hunt my email.
[15:41] <james_w> yeah, it was trunk
[15:42] <james_w> lp:~linaro-maintainers/linaro-image-tools/trunk
[15:42] <james_w> I changed the owning team
[15:43] <jam> james_w: why would "trunk" be stacked?
[16:02] <james_w> jam, oh, that was the original stacked-on location
[16:03] <jam> james_w: right, so the question is where is he branching from now, so we know why it thinks the data is missing.
[16:04] <james_w> https://code.launchpad.net/~dooferlad/linaro-image-tools/my_dev is my guess
[16:04] <jamestunnicliffe> that is correct
=== Ursinha is now known as Ursinha-lunch
[16:22] <jam> Have a good night everyone! Its time for me to go pick up my son from daycare.
[16:36] <poolie> cheerio john
=== deryck is now known as deryck[lunch]
[16:41] <jamestunnicliffe> right, time to rest my Ubuflu ridden head.
=== Ursinha-lunch is now known as Ursinha
[17:09] <sbarcteam> hi.
[17:09] <sbarcteam> I think I've done bzr push in the wrong direction.
[17:09] <sbarcteam> I got some files that I'd like to revert.
[17:10] <sbarcteam> I understand that uncommit won't help me.
[17:10] <sbarcteam> how can I track the files' changes conveniently ?
[17:11] <spiv> sbarcteam: if you want to undo a push, you can do "bzr push -r OLDREV --overwrite"
[17:11] <sbarcteam> spiv,  how do I know OLDREV value ?
[17:11] <sbarcteam> is it a special keyword ?
[17:12] <spiv> No, it's just a regular revisionspec (bzr help revisionspec)
[17:12] <spiv> e.g. if you know the revno you can just use that.
[17:12] <sbarcteam> so, during a push the previous revisionspecs don't get deleted ? (I was afraid this is what happens)
[17:12] <spiv> Revisions are never deleted from a repository.
[17:13] <sbarcteam> ok!
[17:13] <sbarcteam> now, what happened is that the changes of the push were not inserted at the end log, but interleaved in the middle.
[17:13] <sbarcteam> I don't know how to hunt them... ideas are welcome.
[17:14] <sbarcteam> (it was 2 a bit diverged branches)
[17:15] <sbarcteam> so, what happenned during the push is SEVERAL revisions entered. the ideal would be to undo this.
[17:15] <spiv> And push (without --overwrite) will not succeed if the old tip revision isn't in the ancestry of the new tip.
[17:16] <spiv> Take a look at the revision log, either with "bzr log -n0" or with a graphical tool like "bzr qlog" (from the qbzr plugin) or "bzr viz" (from bzr-gtk)
[17:20] <sbarcteam> spiv, I took a look at bash history.
[17:20] <sbarcteam> :-(
[17:20] <sbarcteam> now, the command that was run is bzr pull -r-1 <folder>
[17:21] <sbarcteam> So, the situation is maybe graver.
[17:21] <spiv> No, jsut the same.
[17:21] <sbarcteam> how do I "revert" back the history ?
[17:21] <spiv> pull is just push in the other direction.
[17:22] <sbarcteam> so what I should do in the location I was pulling from to run push -r --overwrite ?
[17:22] <spiv> "bzr pull -r OLDREV --overwrite ."
[17:23] <sbarcteam> spiv, the problem is there is no "oldrev"
[17:23] <sbarcteam> or we don't know how to find it.
[17:23] <spiv> The latter; it exists, you just need to find it.
[17:24] <sbarcteam> so how can I identify it ?
[17:24] <sbarcteam> or find it for that matter ...
[17:24] <spiv> So it isn't something you can readily recognise from looking at the recent revisions?
[17:25] <sbarcteam> nope. the branches diverged long ago. and once in a while we used to merge in the oposite (to that pull) direction.
[17:25] <sbarcteam> my friend wanted to "rebase" and he accidentally ran this command
[17:25] <spiv> Perhaps the "branch nick:" property in log will help?
[17:25] <sbarcteam> ok.
[17:26] <sbarcteam> reading on how do I see all the nicks available and look ...
[17:26] <spiv> You could also try reading ~/.bzr.log's chatter from the offending command for clues
[17:26] <sbarcteam> the problem is I don't see .bzr.log
[17:27] <spiv> What does the "Bazaar log file" line of "bzr --version" say?
[17:28] <sbarcteam> THANKS!
[17:30] <sbarcteam> the log file is in ~/.bzr.log
[17:30] <sbarcteam> I can see revid.
[17:31] <sbarcteam> So, does revid of the pull command show the revide BEFORE the pulls or AFTER it ?
[17:32] <spiv> pastebin the relevant part of ~/.bzr.log?
[17:34] <sbarcteam> working on it(sanitation) man, you've made me alive again. Not sure something is going to help, but I'm learning something new about bzr :)
[17:34] <spiv> (the ~/.bzr.log output is just to aid debugging, so the details vary a bit by bzr version and by which plugins you have installed, etc)
[17:36] <spiv> As for the branch nick suggestion, "bzr log -n0 | grep nick: | sed -e 's/^ *//' | sort -u" is a crude way to see all the branch nicks
[17:37] <spiv> By default a revision will have the "branch nick" property set to the basename of the directory that branch is at
[17:38] <spiv> e.g. a commit in .../proj/trunk would have "trunk", and a commit in .../foo/releases/1.3 will have "1.3"
[17:39] <spiv> So depending on how commits are usually generated for those two branches that may be a way to distinguish them.
=== deryck[lunch] is now known as deryck
[17:43] <sbarcteam> http://pastie.org/1911389
[17:44] <sbarcteam> this is the log of the multiple pull attempt.
[17:44] <sbarcteam> I'm afraid it maybe not complete :-/
[17:44] <sbarcteam> I got the branch nicks.
[17:44] <sbarcteam> there are 2 nicks
[17:46] <sbarcteam> SO, it is possible the nicks of pulled and pulling branch are same ?
[17:47] <spiv> Sure
[17:47] <spiv> See above description.
[17:48] <spiv> So unfortunately, that revid is the new one, not your old one.
[17:48] <spiv> (Btw, you can see revids in bzr log by passing --show-ids)
[17:49] <sbarcteam> hm.
=== beuno is now known as beuno-lunch
[18:06] <maxb> james_w: Hello, I have a question about bzr-builddeb's import_dsc.py. Why is it necessary to do divergedness checking on the upstream branch as well as the main branch when determining if a pull from lesser/greater is acceptable?
[18:06] <james_w> maxb, hmm, have a line reference for me?
[18:07] <maxb> james_w: DistributionBranch.branch_to_pull_upstream_from, at the comment # Check for divergenge.
[18:08] <maxb> (The point being, if you've established the debian part can be pulled OK, isn't checking the upstream part somewhat implicit?)
[18:08] <james_w> maxb, yeah
[18:08] <james_w> maxb, sometimes we just pull the upstream part though
[18:08] <james_w> so the check is there for that
[18:08] <james_w> a parameter/separate function to avoid the check would solve it if it's a significant overhead
[18:09] <maxb> It's not overhead per-se, but I'm actually getting a failure of the upstream divergence check leading to unwanted parallel importing in the qbzr import I'm trying to fix
[18:10] <james_w> hmm
[18:12] <maxb> I think it's because I've got a weird tree shape already in that the final upstream import is one that involved a "Prepared upstream tree for merging into target branch." intermediate revision
[18:12] <maxb> uhm, I mean "final in the existing branches before the problem arose"
[18:32] <maxb> Hmm. So, I *think* the thing to do is to continue checking the upstream's md5 is right, because that could be important. But to not care about ancestry if the aggregate of upstream+debian has already proved to be undiverged
=== zyga is now known as zyga-afk
[18:53] <LarstiQ> sprinters still around?
[18:54] <mgz> yup, I just looked at the time and was surprised :)
[18:54]  * LarstiQ grins
[18:54] <LarstiQ> how is it going?
[18:55] <mgz> http://pqm.bazaar-vcs.org/
[18:55] <sbarcteam> hi.
[18:56] <LarstiQ> hi sbarcteam
[18:56] <sbarcteam> where does bzr log command take its data from ?
[18:56] <sbarcteam> ~/.bzr.log ?
[18:56] <LarstiQ> mgz: ooh, looks good
[18:56] <mgz> good list of things waiting to land, plus some other progress :)
[18:56] <sbarcteam> or the WorkingTree ?
[18:56] <LarstiQ> sbarcteam: the branch actually
[18:57] <sbarcteam> so, if I am bound it doesn't go to the bound_location, but looks at local copy of the branch. right ?
[18:57]  * LarstiQ is digging into the pypy/generators leaking files problem
[18:57] <sbarcteam> and it has not much to do with ~/.bzr.log ... right ?
[18:57] <LarstiQ> sbarcteam: nothing at all with .bzr.log
[18:57] <sbarcteam> ok.
[18:57] <sbarcteam> this is good.
[18:58] <LarstiQ> sbarcteam: .bzr.log is only to write debugging output to
[18:58] <LarstiQ> sbarcteam: have you managed to undo the push yet?
[18:58] <sbarcteam> no. now I'm getting strange bzr log outputs (with today's activities) from supposedly restored data of the last night.
[18:59] <LarstiQ> sbarcteam: strange in what way?
[19:02] <sbarcteam> I am getting bzr log output from AFTER the backup was taken.
[19:03] <LarstiQ> sbarcteam: just a bare "bzr log", or are you giving it some arguments?
[19:03] <sbarcteam> bzr log -n0 -r-1 | less
[19:04] <LarstiQ> and how have you restored the backup? (ie, are you backing up/restoring what you think you are)
[19:06] <sbarcteam> moment.
[19:06] <sbarcteam> I removed ALL the stuff from the code folder (incl. .bzr)
[19:06] <sbarcteam> restoring now...
[19:08] <sbarcteam> waiting for "it" to complete....
[19:08] <spiv> sbarcteam: perhaps double check that "bzr info" shows the branch and repo you expect for that directory?
[19:08] <sbarcteam> I think the problem is NFS.
[19:08] <sbarcteam> it's netapp thingie.
=== beuno-lunch is now known as beuno
=== MIsterX is now known as MisterX
=== MisterX is now known as JasonO
=== JasonO is now known as MIsterX
=== MIsterX is now known as MisterX