[00:01] <jxself> poolie: Will do, thanks. There's more than a decade of history in CVS and I don't want to lose that.
[00:06] <jelmer> wgrant: Is it no longer possible for me to change Fix Released Ubuntu bugs back to any other status?
[00:06] <jelmer> I accidentally changed a bug to Fix Released, now I can't change it back.
[00:07] <wgrant> jelmer: You can't reopen a bug unless you are a bug supervisor or the reporter.
[00:07] <wgrant> jelmer: Which bug?
[00:08] <jelmer> wgrant: the ubuntu bit of https://bugs.launchpad.net/ubuntu/+source/loggerhead/+bug/586611
[00:08] <ubot5> Ubuntu bug 586611 in loggerhead "loggerhead needs a hard dependency on simplejson" [Medium,Fix committed]
[00:08] <poolie> is that new?
[00:08] <wgrant> poolie: Yes :(
[00:08] <wgrant> More misfeatures.
[00:08] <poolie> i don't suppose it's documented other than in the source?
[00:08] <wgrant> jelmer: What should it be?
[00:08] <wgrant> poolie: lol
[00:09] <jelmer> wgrant: In Progress I guess (there's an upload going into Debian that fixes it that'll request a sync for)
[00:09] <jelmer> s/that'll/that I'll/
[00:09] <wgrant> Fixed.
[00:09] <jelmer> wgrant: thanks
[00:47] <mr-russ-work> what's the best windows bzr client?
[00:48] <poolie> bzr explorer
[00:52] <mr-russ-work> does it need bazaar installed?
[01:08] <poolie> mr-russ-work, yes
[01:08] <poolie> but i think they're both included in the default windows installer?
[01:16] <poolie> hi spiv?
=== r0bby is now known as robbyoconnor
[01:33] <knighthawk> thanks poolie
[01:40] <spiv> Hi poolie
[01:41] <spm> poolie: jubany now has: ii  bzr 2.3.1-0~0.IS.8.04; will update the RT shortly
[01:41] <spiv> spm: thanks!
[01:41] <spiv> I'll give those imports a kick then
[01:42] <spm> sweet
[01:51] <poolie> hey spiv
[01:51] <poolie> i missed you before :)
[02:21] <spiv> Hmm, the package importer is getting lots of “lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error”, e.g. http://package-import.ubuntu.com/status/ceph.html#2011-03-25%2002:08:19.181741
[02:30] <poolie> there should be an oops header
[02:30] <poolie> gah
[02:30] <poolie> i filed a bug asking for lplib to pull that into the exception
[02:30] <poolie> you could fix that
[02:39] <lifeless> timeout bug I suspect
[02:39] <lifeless> fix is in trunk, pending deploy due to these security issues
[02:40] <spiv> I've told the package-importer that it's a transient issue, so it'll automatically retry those failures after 24(?) hours I think
[02:40] <lifeless> well
[02:41] <lifeless> the problem is that filing a merge proposal loads /all/ the branch history for both sides into cache
[02:41] <lifeless> so if you want to retry
[02:41] <lifeless> do it right away
[02:41] <lifeless> while you're still slightly hot
[04:13] <achiang> hello, i noticed that debcommit has some magic to make a bzr branch automatically link up with a launchpad bug. how can i do that manually? bzr help commit doesn't really tell me much
[04:13] <poolie> bzr help mark-uploaded
[04:13] <poolie> i think
[04:14] <lifeless> mark-uploaded says when something has been uploaded to the archive
[04:14] <poolie> ah gah
[04:14] <poolie> misread
[04:14] <poolie> you want bzr ci --fixes lp:BUGNUM
[04:14] <achiang> ooh
[04:14] <achiang> ok
[04:15] <achiang> huh, --fixes not documented in maverick's bzr?
[04:15] <achiang> yes it is
[04:15] <achiang> i just can't read
[04:15] <achiang> poolie: thanks!
[04:15] <poolie> in 'bzr help launchpad' too
[04:15] <poolie> you're welcome
[06:46] <jderose> how do i print a summary of commits per person/ lines of change per person?  looked at bzr stats, but it doesn't seem able (or maybe is sort of broken on bzr 2.3.0/natty)
[06:53] <poolie> i thought it did that sort of thing
[06:54] <achiang> is there a way to do a bzr commit interactive? i only want to commit one hunk
[06:54] <poolie> install bzr-interactive i think
[06:55] <achiang> nothing shows up in apt-cache search?
[06:55] <poolie> jderose, what happens from 'bzr stats'?
[06:55] <achiang> oh, it's a plugin
[06:56] <poolie> yep, bzr branch lp:bzr-interactive ~/.bazaar/plugins/interactive
[06:56] <achiang> interesting, i'll try that
[06:56] <poolie> jderose, that seems to work for me
[06:57] <jderose> poolie: turns out, something totally awesome! i've been up hacking too long at this point... was in the wrong branch! http://paste.ubuntu.com/585230/
[06:57] <poolie> haha :)
[06:58] <jderose> poolie: sorry for the dumb question, thanks for the smart answer :)
[06:58] <poolie> np, glad it worked
[06:58] <poolie> don't know if it can count slocs
[06:58] <poolie> which obviously are highly useful in awarding bonuses
[06:58] <jderose> ah, gotcha... that would be cool
[06:59] <jderose> poolie: np, i work for this crappy startup that doesn't pay anyone anything!
[06:59]  * jderose is CEO :)
[07:01] <poolie> congrats / good luck :)
[07:03] <jderose> poolie: thanks. :) while i have you... out of curiosity, is there any timeline for addressing the submodules issue with bzr? - https://bugs.launchpad.net/bzr-git/+bug/402814
[07:03] <ubot5> Ubuntu bug 402814 in Launchpad itself "Importing revisions with submodules is not supported" [Wishlist,Triaged]
[07:04] <poolie> hm it should go up from wishlist
[07:04] <jderose> poolie: i keep telling everyone how awesome daily builds are, help them set them up, to find i can't import into bzr... i'm personally very interesting in see daily builds for gstreamer and pitivi
[07:04] <poolie> yeah, it's a big blocker for that
[07:05] <poolie> it's not close enough i could give a very reliable estimate but it's definitely in our target area
[07:05] <jderose> poolie: i know there are always too many things to do and it's hard to pick priorities --- no judgments! -- but just wondering :P
[07:05] <poolie> maybe in the next few months
[07:06] <jderose> so this requires a pretty big change in bzr? new storage format big?
[07:09] <jderose> poolie: anyway, bzr and launchpad are fantastic - that's for tools that have made my live easier! :)
[07:09] <poolie> just a bug
[07:09] <poolie> fighting with all the others to be born
[07:12] <jderose> poolie: gotcha.  thanks again!
[07:21] <poolie> hi jam!
[07:37] <vila> hi all !
[07:39] <poolie> hi there vial
[07:39] <poolie> *vila
[07:39] <vila> I can't find back the reference, but someone mentioned that reviews can gain a 'Agreed' vote instead of an 'Approved' one
[07:39] <poolie> really?
[07:39] <vila> It makes a lot of sense to me
[07:40] <vila> It gives a very different meaning and implies a different relationship which I think is far more appropriate
[07:40] <poolie> i just haven't heard of it
[07:41] <vila> Most of the time I "agree" with the proposal as a peer instead of "approving" it as a semi-god :-D
[07:42] <vila> ha, got it: http://micknelson.wordpress.com/2011/03/22/code-reviews-as-relationship-builders/
[07:43] <poolie> https://lpstats.canonical.com/graphs/BzrProjectBugActivity/ -- everyone came back from holidays :)
[07:43] <poolie> nice idea
[07:43] <vila> lol
[07:43] <poolie> personally i would rather get 'tweak'
[07:44] <poolie> http://en.wikipedia.org/wiki/I_approve_this_message
[07:44] <vila> yeah, it's needed more often
[07:46] <poolie> i think 'approval' is quite a positive sentiment though
[08:00] <vila> poolie: granted there are positive values in approval but I think they are also there in agreement ;)
[08:01] <poolie> haha :) indeed
[08:03]  * vila back to losa hunting
=== psynaptic is now known as psynaptic|afk
[09:09] <jam> morning all
[09:09] <vila> morning jam :)
[09:12] <poolie> jam, vila: should i add a mechanism to deprecate commands, or just delete them?
[09:12] <poolie> i guess the former
[09:12] <jam> poolie: so you get "bzr clone is going to be removed in the next release" messages?
[09:12] <poolie> yeah
[09:12] <jam> We've loosened the deprecation stuff for api, but I think we probably want to do that for command  line.
[09:12] <poolie> suppressable messages
[09:13] <vila> configurable as we did for warnings
[09:14] <jam> side note: "safe and easy web browser from Mozilla" (firefox)
[09:14] <poolie> ?
[09:14] <jam> just very funny to read the "helpful descriptions" rather than the name of the program
[09:14] <jam> Update Manager
[09:14] <poolie> oh, yeah, that is strange
[09:14] <jam> They also have a very strange (and inconsistent) Capitalization
[09:15] <jam> poolie: I'm tempted to go so many different ways.
[09:15] <jam> I would tend to say... if it is hard to do, punt
[09:15] <jam> but if it is easy, please deprecate
[09:15] <poolie> agree
[09:15] <poolie> it's not _that_ hard
[09:15] <jam> That said
[09:15] <poolie> some of the command framework stuff could do with some love
[09:15] <jam> if people are using "bzr clone" are they going to notice it tell them it will be changing?
[09:18] <poolie> why wouldn't they?
[09:19] <jam> poolie: because of all the other stuff that they ignore. They could.
[09:19] <jam> I just want to make sure that messages we send are relevant
[09:20] <jam> That people who *want* to see them are doing so.
[09:20] <poolie> so i can think of two ways to do this
[09:20] <poolie> one is, to put it into the Command object
[09:20] <poolie> we could just refuse it
[09:20] <poolie> and make them update
[09:21] <poolie> their muscle memory or scripts
[09:21] <poolie> i guess some scripts may be hard to update
[09:27] <jam> poolie: There was a recent discussion in python-dev about deprecation
[09:27] <jam> In py, they always do PendingDeprecation in X, Deprecation in X+1, Removed in X+2
[09:27] <poolie> ok
[09:27] <jam> People were complaining
[09:27] <poolie> what's pending deprecation?
[09:28] <poolie> just in the docs?
[09:28] <jam> poolie: I think it is a by-default suppressed warning
[09:28] <jam> versus a vocal warning
[09:28] <jam> versus gone
[09:28] <jam> the complaint was because they were trying to go from 2.X to 3, and running afoul of
[09:28] <jam> Well it was deprecated in 3.1, so removed in 3.2
[09:28] <poolie> :)
[09:28] <jam> but 2.7 still had something
[09:29] <jam> so there was no way to support 2.7 *and* 3.3
[09:29] <jam> or whatever
[09:29] <jam> poolie: but that also highlights something
[09:29] <jam> people really care about Deprecation as a way to transition
[09:29] <jam> if we are just removing aliases to commands that already exist
[09:29] <jam> they can switch to the existing command, and be supported across all versions
[09:30] <poolie> right
[09:30] <poolie> and, they should be able to use bzr aliases if for some reason they can't change
[09:30] <jam> I think people have trouble if it was "foo" in 2.0, and "bar" in 2.4, and they don't have an easy way to support the versions they want
[09:31] <jam> poolie: My experience in the past, was that DeprecationWarning wasn't helping people
[09:31] <jam> Developers tend to use crack-of-the-day
[09:31] <jam> and so never see them, because they are using the new apis
[09:31] <jam> Users see them a lot, but don't have anything they can *do* about it
[09:31] <poolie> yes
[09:31] <poolie> and yes
[09:31] <poolie> showing deprecationwarning to users is nuts
[09:32] <jam> poolie: I *think* we can do this for commands in a tasteful way
[09:32] <jam> because there it is much more likely that a user is invoking the command that needs to be changed
[09:32] <jam> There are scripts that don't apply
[09:32] <jam> (if I'm using, eg, etckeeper, then don't give me deprecations cause Upstream needs to fix it)
[09:33] <poolie> also, it's probably unusual that someone chose to use these at all
[09:33] <jam> poolie: then my recommendation is to troll through bzr docs, especially ones not written by us
[09:34] <jam> I don't know of any particularly popular ones
[09:34] <jam> but I'm pretty sure I've seen wiki-like docs
[09:34] <jam> that said "bzr clone ..."
[09:34] <jam> or maybe "bzr get ..."
[09:34] <poolie> maybe
[09:34] <poolie> those docs may have bigger problems
[09:34] <poolie> anyhow, fair enough
[09:34] <jam> anyway, that's the only place where I've seen recommendations for people to use non-official names
[09:34] <poolie> adding a command deprecation layer just for this does not feel like the most direct route possible
[09:34] <poolie> k
[09:35] <poolie> thanks
[09:35] <jam> And I think some people like "bzr get" because it was shorter to type
[09:35] <poolie> i'm happy to add 'bzr br' or similar
[09:35] <poolie> once we sort this out
[09:37] <spiv> jam: yes, I know of at least user that prefers "bzr get"
[09:37] <spiv> I don't recall hearing anyone use or advocate using our current "bzr clone" alias.
[09:39] <jam> spiv: I think I've seen it in something like "bzr-for-git" discussion
[09:41] <poolie> spiv, bialix mentioned in the bug he prefers it
[09:41] <poolie> or was it someone else too?
[09:41] <jam> (because the command is more like 'git clone' than 'git branch')
[09:41] <jam> poolie: I'm pretty sure the one I remember is bialix
[09:41] <poolie> well, they might say 'bzr clone' too then
[09:41] <poolie> but it's not all that much like it
[09:43] <spiv> I'm mainly thinking of glyph, but presumably these aren't the only people :)
[09:44] <poolie> well, 'bzr alias get=branch' will restore it
[09:46] <jam> poolie: so I think you bring up a reasonable statement
[09:46] <jam> fail
[09:46] <jam> but give them advice on what to do
[09:46] <jam> "bzr get" --- "bzr get was removed in bzr 2.4. The recommended name is "bzr branch", to restore "bzr get" as an alias, use ..."
[09:47] <jam> (bzr get was removed as an alias in bzr 2.4)
[09:47] <jam> poolie: sort of inbetween "deprecated and I still work", and "where did the command go that I've been using for 3 years"
[09:49] <poolie> yep
[09:49] <poolie> i might implement that by adding a new command that prints the message, and binding them to that
[09:49] <jam> poolie: a few ways to do it. You could add "old_aliases = [...]" to Command objects
[09:49] <jam> if there are a lot of them
[09:50] <poolie> i was going to do that originally
[09:50] <jam> I think it depends how hard it is to get the appropriate text
[09:50] <poolie> it seems a bit inelegant to put it inline with the regular command stuff
[09:50] <jam> but I guess that is what https://code.launchpad.net/~mbp/bzr/506265-command-deprecation/+merge/54828 is about?
[09:50] <ubot5> Ubuntu bug 506265 in Bazaar "deprecate old command names" [High,In progress]
[09:50] <jam> So the "cmd_I_was_removed_in_24" knows what it is aliased to now?
[09:53] <poolie> right
[09:55] <poolie> i think i might stop for today though
[09:58] <jam> spiv: You mentioned you could use "lp:~/project/branch" and we'll expand ~ to ~user. When you said that, I thought "really, since when".
[09:58] <jam> I just looked through the logs, and *I* implemented it
[09:58] <jam> (2.3b1)
[10:36] <spiv> jam: :)
[10:58] <lifeless> spiv: should be able to retry those timeouts now
[11:04] <jam> bbiab, lunch
[12:02] <spiv> lifeless: I think they retry every hour actually
[12:03] <spiv> Oh, hmm, maybe not.
[12:03] <spiv> I'll give it a kick anyway
[12:35] <spiv> lifeless: still failing
[12:51] <james_w> erk
[12:52] <james_w> I don't like the look of http://package-import.ubuntu.com/status/7ae30b44f1f904e04bbae6700b7181dd.html
[12:52] <james_w> and http://package-import.ubuntu.com/status/3321c5cfcfcf74249b92f963453f4701.html is pretty worrying
[12:53] <james_w> as is http://package-import.ubuntu.com/status/ttf-arphic-gkai00mp.html
[12:53] <james_w> http://package-import.ubuntu.com/status/ttf-arphic-uming.html
[12:54] <james_w> http://package-import.ubuntu.com/status/ttf-arphic-ukai.html
[12:54] <vila> james_w: I think that's what lifeless and spiv were just talking about
[12:54] <james_w> though I guess those are transient with the upgrade of bzr?
[12:54] <vila> eerk, the no module named revisiontree is different and indeed very worrying
[12:56] <vila> james_w: 'no module ...' requeued
[12:58] <vila> james_w: and they seem to be passing now, ttf-arphic-uming requeued too
[12:59] <james_w> vila, great, thanks
[12:59] <james_w> it would be great to have a packaging system that didn't break python on upgrades
[12:59] <vila> thanks for noticing, I think.. yeah :)
[12:59] <vila> james_w: in the mean time, stopping the importer may help...
[12:59] <james_w> yeah
=== mrevell is now known as mrevell-lunch
[13:26] <spiv> james_w: in principle the packaging system could do "mv bzrlib .old.bzrlib; mv .new.bzrlib bzrlib; rm -r bzrlib" I suppose, but I can just imagine how that would actually be pretty hairy to actually implement
[13:26] <spiv> james_w: (and of course even that approach has a small window of brokenness)
[13:27] <james_w> spiv, my guess is that dpkg is fine, it's the Python-specific stuff on top that isn't, and hopefully that can go away in a few years when Barry's stuff is widely available
[13:27] <spiv> Although I guess it's hard to avoid the risk of breaking running processes
[13:28] <spiv> Even firefox wants a restart after its package is upgraded ;)
[13:29] <spiv> james_w: clearly bzr should not use lazy_import so that it gets all its imports done in as short a window as possible ;)
[13:29] <james_w> yeah :-)
[13:29] <james_w> if we can't even import bzrlib sometimes though... :-)
=== psynaptic|afk is now known as psynaptic
[13:30] <spiv> Or just have the old processes keep running against an older btrfs snapshot of the system, or something handwavy like that...
[13:31] <spiv> Anyway, zzz time!
[13:34] <james_w> night
=== mrevell-lunch is now known as mrevell
[14:41] <jam> jelmer: you landed the bzr-hg change faster than Launchpad built the merge proposal for it. so there isn't a diff to read.
[14:41] <jam> also, weren't we wanting to pair on some changes?
[14:41] <jam> I don't remember which ones off-hand
[14:41] <jam> but maybe we could do that early next week?
[14:42] <jelmer> jam: I've mostly been using merge proposals as a way to track individual changes, but self-reviewing as I always have
[14:42] <jelmer> jam: Yeah, some pair programming would be nice
[14:42] <jam> jelmer: sure. Just mentioning that tracking the changes isn't possible when you land faster than they get tracked :)
[14:43] <jelmer> jam: heh, fair enough :)
=== deryck is now known as deryck[lunch]
=== psynaptic is now known as psynaptic|lunch
=== psynaptic|lunch is now known as psynaptic
=== deryck[lunch] is now known as deryck
=== Ursinha is now known as Ursinha-lunch
=== psynaptic is now known as psynaptic|afk
=== psynaptic|afk is now known as psynaptic
=== Ursinha-lunch is now known as Ursinha
=== psynaptic is now known as psynaptic|food
=== herb__ is now known as herb
=== mnepton is now known as mneptok
[21:32] <achiang_> hello, how do i resolve a merge conflict? i get a foo.BASE and a foo.THIS, not sure which one is which
[21:34] <achiang_> but the base file foo doesn't seem to exist at all
[21:34] <achiang_> ah, i think that means my merge source rm'ed foo
=== psynaptic|food is now known as psynaptic|afk
[23:18] <wgrant> maxb: Hi.
[23:34] <ablmf> How to automatically "push" after every commit?
[23:35] <bouncingzip> use a bound branch.
[23:36] <ablmf> bouncingzip: do u mean use a "checkout"?
[23:40] <bouncingzip> actually, depends what you're trying to do exactly
[23:40] <bouncingzip> maybe relevant: http://stackoverflow.com/questions/460632/bazaar-bound-branch-commit-and-update
[23:44] <bouncingzip> if you want the tree somewhere remote, those are suggestions on how to do it, if you want a remote branch automatically mirrored each commit, binding to it (which yes, is the same as using checkout originally) is probably what you want.
[23:47] <ablmf> bouncingzip: I think the plugin helps, thx!
=== psynaptic|afk is now known as psynaptic