[00:01] <poolie> hello igc
[00:06] <chalkbag_> Hey folks, is there a way to rewrite author info on locally committed revisions? I got the email wrong there...
[00:06] <chalkbag_> I tried bzr rebase but it doesn't seem to allow that, it looks like it only reapplies the local changes to the tip of the parent tree
[00:11] <spiv> chalkbag_: perhaps the bzr-fastimport plugin can help.  You could fast-export the revisions, edit the export and then import it again.
[00:12] <spiv> chalkbag_: I think the fast-import-filter command may even support rewriting authors directly.
[00:12] <chalkbag_> Ah, interesting - I was actually wondering if there was a way to create smth like a change set of diffs ala git. bzr send seems to be creating a monolitic diff of everything that changed and doesn't preserve individual commits - unless I missed something there
[00:13] <spiv> chalkbag_: bzr send will preserve the individual commits
[00:13] <spiv> chalkbag_: but as a blob that you can't really edit.
[00:14] <chalkbag_> really? How do I "replay" them? I tried "bzr patch" but is seems to have applied them all at once - will I see individual revisions after I commit?
[00:14] <chalkbag_> So I assume it'll preserve author info as well, right? If not, I can just reapply the patch after changing my email in the config...
[00:15] <james_w> chalkbag_: bzr merge or bzr pull
[00:15] <bob2> there's the bzr-rewrite plugin, too
[00:16] <chalkbag_> bob2 - yeah, I tried that one, it's not like git's rebase, i.e., it won't really let me change anything in the commits, it just reapplies them at the tip as far as I can tell
[00:17] <chalkbag_> james_w - I'm not sure I understand how merge/pull would help me?
[00:18] <spiv> chalkbag_: you can "bzr merge"/"bzr pull" from the file that "bzr send" outputs.
[00:18] <james_w> chalkbag_: that's how you apply what bzr send creates, but you are right that it won't help solve your problem
[00:19] <chalkbag_> Hmm, and it won't preserve the author info? That might indeed be the easiest way to do that then
[00:19] <chalkbag_> Let me give it a quick try :p
[00:35] <chalkbag_> yeah, merge wrote the merge commit with my new author info but whatever it merged contains the original email. I guess I'll have to play with fast-import then...
[00:36] <bob2> do you care that much?
[00:37] <chalkbag_> Not too much but it looks like people on launchpad seem to be using real email addresses and all I've got is smth like foo@mylaptop :(
[00:38] <chalkbag_> I should've thought about that before doing the commits but I expected this would be something quite easy to change later on - I guess I got spoiled by git :o
[00:38] <chalkbag_> besides, it sounds like a challenge of sorts :p
[00:40] <chalkbag_> ok, it looks like fast-export/import should do that, fast-import-filter has an example for rewriting user ids in the --help
[00:41] <chalkbag_> thanks folks!
[00:53] <poolie> spiv, re bug 503878, i thought we now did better than TooManyConcurrentRequests when the server dropped the connection
[00:56] <spiv> poolie: often, although I see that bzrlib/reconcile.py has a "try: ... finally: collection._unlock_names()" which is what's been tripped here.
[00:57] <spiv> poolie: i.e. an unconditional attempt to perform a cleanup over the network even if the network connection has gone away.
[00:57] <poolie> right
[00:57] <spiv> I'll put together a simple fix for that for trunk.
[00:58] <poolie> oh ok
[00:59] <poolie> i'll reopen it
[01:02] <Akilla> Hey, all, quick question. We're using BZR to make local changes to a public SVN repo. So, we need to maintain the ability to both update from the public SVN server and make our own loacl cchanges with BZR. Some aspects of tihs work fine, but when we try to do individual file commands (i.e. remove) it tries to access the SVN server. Is there any way to disable the SVN functionality of the bzr binaries so that it will just perform B
[01:07] <poolie> Akilla: so you have one working tree that's both a svn checkout (controlled by svn) and a bzr checkout (controlled by bzr?)
[01:12] <mwhudson> jelmer: hello, did you see http://launchpadlibrarian.net/37520409/squeezebox-7.5-log.txt ?
[01:12] <Akilla> yeah... turns out tortoisebzr had a subversion integration installation option.
[01:13] <Akilla> just reinstalled adn rebooted and now i'm getting different errors that look like it's trying to actually access the bzr repo.
[01:17] <Akilla> yeah, apparently this is just a user error as a result of a default option in the tortoisebzr installer.
[01:17] <Akilla> ignore me. :) thanks!
[01:40] <GungaDin> hi
[01:41] <GungaDin> I have an old repo (bzr version 1.xx), and now I'm using bzr 2.0.2 and I keep getting bzr: "ERROR: No repository present: "file:///home...." when I'm trying to do something...
[01:41] <GungaDin> any ideas what the problem might be?
[01:43]  * igc lunch
[01:49] <Peng> GungaDin: Just for fun, try "bzr --no-plugins info" or whatever.
[01:50] <Peng> GungaDin: Aside from that, upgrading bzr won't break anything. So, most likely there's no repo present...
[01:50] <GungaDin> there always has been...
[01:50] <Peng> Well, there have been a couple changes, but if they break anything, it should be pretty obscure.
[01:50] <GungaDin> I can see the .bzr dir
[01:50] <Peng> GungaDin: OK, but what about .bzr/repository?
[01:50] <Peng> GungaDin: And what does "bzr info" say?
[01:50] <GungaDin> same error
[01:51] <Peng> GungaDin: Oh oh. Did you try to "bzr upgrade"? Does .bzr/repository.backup or backup.bzr exist?
[01:51] <GungaDin> no
[01:51] <Peng> GungaDin: Did you do "bzr reconfigure" or anything else?
[01:51] <GungaDin> bzr upgrade gives the same error
[01:51] <GungaDin> no
[01:51] <Peng> Erk. Not what I meant!
[01:52] <Peng> I was asking if you had run "bzr upgrade", not saying you should. Oh well, doesn't matter.
[01:52] <Peng> Whoops.
[01:52] <GungaDin> should I try bzr reconfigure?
[01:55] <GungaDin> any ideas?
[01:55] <maxb> GungaDin: Perhaps you could pastebin the output of 'find path/to/that/.bzr'
[01:58] <GungaDin> http://pastebin.com/d30ca28ad
[02:00] <maxb> So, that's a branch with no repository internally, so it must be expecting to find a shared repository in a parent directory's .bzr
[02:01] <maxb> If there is no such repository, then directories have been moved around on disk in a way which has broken things
[02:11] <GungaDin> but I haven't moved anything...
[02:11] <GungaDin> shit...
[02:11] <GungaDin> something must have happened here...
[02:11] <GungaDin> I'm getting this with pretty much all my branches :S
[02:12] <Peng> GungaDin: Maybe you accidentally had a shared repo very high up, e.g. /.bzr, /home/.bzr or /home/you/.bzr.
[02:13] <GungaDin> *sigh*
[02:13] <GungaDin> could be...
[02:51] <jdub> what up bzroes!
[02:51] <jdub> i have an http smart server issue
[02:52] <jdub> after 10 successful POSTs to .bzr/smart, i get a timeout...
[02:52] <jdub> i have just upped my proxy timeout to 300s
[02:53] <jdub> and trying it again, but it looks like it's going to fail
[02:53] <jdub> (the smart server is loggerhead behind nginx with http auth)
[02:53] <spiv> jdub: hmm, what smart request, do you know?
[02:54] <spiv> jdub: (run the client with -Dhpss and peek in ~/.bzr.log)
[02:54] <jdub> will do
[02:54] <jdub> aha!
[02:54] <jdub> was waiting for a timeout
[02:54] <jdub> but the client had actually already returned (nothing in logs)
[02:55] <jdub> bzr: ERROR: Could not acquire lock "(remote lock)":
[02:55] <jdub> should i try break-lock first?
[02:56] <spiv> jdub: ah, yeah, probably
[02:56] <spiv> jdub: this is a 'bzr push'?
[02:56] <jdub> yeah
[02:56] <jdub> ok, i broke the lock
[02:56] <jdub> trying again
[02:57] <spiv> jdub: my random speculation would be that that insert_stream request might be very large, and would arrive as a single POST — it should be streamed gradually (maybe after a small initial pause), but depending on the various HTTP server bits it's easy to see how that might timeout or cause issues.
[02:57] <jdub> rock, that worked
[02:57] <spiv> Ah, good :)
[02:58] <jdub> so the biggest POST of about 15 that time was 15078
[02:58] <spiv> Oh, pfft :)
[02:59] <jdub> is there an "i'm waiting patiently for this lock to go away" delay?
[02:59] <spiv> 300 seconds, I think, I don't remember the precise circumstance.
[02:59] <jdub> heh
[03:00] <spiv> The server won't delay, though (unless your server has a very old bzr!)
[03:00] <jdub> 2.0.3
[03:00] <jdub> and was previously running 2.0.2
[03:00] <spiv> I don't think the client will via HPSS either (unless maybe if it's fallen back to non-smart VFS methods for some reason)
[03:00] <jdub> (before i restarted loggerhead)
[03:00] <spiv> Ok, that's not even close to what I meant by "very old" :)
[03:01] <spiv> So, not sure why there was a delay for you.
[03:01] <jdub> 8)
[03:06] <poolie> hi jdub
[03:09] <jdub> yo poolie
[03:10] <jdub> poolie: will you be in welly?
[03:10] <poolie> hi
[03:10] <poolie> no, i have clashing travel
[03:10] <jdub> nooooooo
[03:10] <poolie> so did you work out your issue with the delay?
[03:11] <poolie> i'd probably try stracing the server subprocess
[03:11] <poolie> and perhaps put that into a bug
[03:11] <jdub> poolie: well, until i cranked up the proxy timeout, it didn't have enough time to tell me about the lock
[03:11] <jdub> poolie: once the lock was broken, it worked fine
[03:12] <jdub> that it took so long to report about the lock is a bit worrying though
[03:12] <poolie> it is
[03:12] <poolie> so it would be nice to know what it was doing for all that time
[03:13] <jdub> can i just touch a file to create a stray lock?
[03:18] <poolie> it needs to be a directory called 'held' containing a file called 'info'
[03:19] <poolie> i think the file can be empty, at least for your purposes here
[03:23] <spiv> jdub: python -c "from bzrlib.bzrdir import BzrDir; branch = BzrDir.open($URL).open_branch(); branch.lock_write(); branch.leave_lock_in_place()"
[03:23] <spiv> jdub: you'll need to use break-lock to tidy up afterwards, of course.
[03:34] <poolie> spiv, re bug 504102
[03:34] <poolie> can you tell me off hand when the network_name should be set in a remotebzrdirformat?
[03:35] <spiv> poolie: as soon as it is known, IIRC.
[03:36] <spiv> poolie: it varies by circumstance a little, I think, which makes it confusing.
[03:36] <poolie> and so either initializing a bzrdir, or doing find_format on an existing one ought to set it?
[03:36] <spiv> I think so, yes.
[04:08] <igc> hi poolie
[04:09] <igc> poolie: can we make Sphinx a dependency for 2.1 packagers?
[04:09] <igc> poolie: I'd like to drop the old pure-rest docs because ...
[04:09] <igc> supporting them breaks some things in Sphinx (e.g. PDF generation of the User Reference)
[04:12] <jam1> hey igc
[04:12] <igc> hi jam!
[04:12] <igc> Happy New Year
[04:13] <jam> So did I read correctly that you may show up in Strasbourg?
[04:14] <igc> jam: maybe - I need to chat to poolie about it
[04:14] <jam> igc: well, so far I still need to find out if *I'm* going
[04:14] <jam> my wife has a potential trip around the same time, which she should find out about tomorrow
[04:17] <poolie> hello igc
[04:17] <poolie> igc, the non-sphinx things do make things a bit more confusing too
[04:17] <poolie> there are some index.txts that don't go into the sphinx stuff
[04:17] <poolie> you can do what you think best
[04:17] <igc> poolie: thanks
[04:17] <poolie> i'll also mention, though it's not super urgent, the bug asking for rest->texinfo translation
[04:18] <igc> I'll email the list anyway asking for objections
[04:18] <poolie> apparently jam looked and there is a tool but it doesn't completely work
[04:18] <poolie> shall we talk now?
[04:18] <igc> as in on phone?
[04:18] <poolie> if you like
[04:18] <poolie> or here
[04:18] <spiv> Yeah, I've been tripped up by two slightly different doc generation systems, so it would be nice if it were just Sphinx.
[04:18] <igc> either is good by me
[04:19] <spiv> I think I wanted to use some sort of link to another doc that Sphinx supports, but it turned out that the pure-rest stuff didn't.
[04:19] <jam> igc, poolie: yeah, getting to texinfo is tricky, and texinfo likes to have "type" info that we wouldn't have
[04:19] <jam> (code vs variable vs etc that all generate fixed-width output)
[04:20] <jam> spiv: yeah, I'm a bit surprised plain rest doesn't let you link via a '.txt' and then have that translated to a '.html' link when necessary
[04:31] <Guest56789> ALGUIEN ABLA ESPAÑOL
[04:45] <poolie> igc, https://edge.launchpad.net/software-center has mvo with the most karma
[05:53] <poolie> spiv, don't forget as pilot you can nag other people for a second review
[05:53] <poolie> or even when not a pilot :)
[05:53] <spiv> poolie: sure, but it's not really worth it for a one-liner :)
[05:53] <poolie> yeah i know
[05:53] <poolie> just meant in general
[05:53] <spiv> Fair enough.
[05:54] <poolie> but also, i really like the way you're handling them
[05:54] <poolie> that was nicely put
[07:01] <vila> hi all !
[07:02] <vila> hmm, I haven't realized that MPs now present the post-review commits in the comments, nice. The sugar on top would be a button to present the associated diff :)
[07:03] <jml> locked 145 hours, 58 minutes ago
[07:03] <jml> niiiice.
[07:03] <jml> vila, you can click on the revno to get the diff
[07:03] <vila> ooh, but they are ! revnos are clickable and show just that !
[07:03] <vila> jml: hehe
[07:04] <jml> 145 hours ago is not a helpful number
[07:04] <vila> I just love those moments where you think: "IWBN if they put it here... try... it works !"
[07:04] <jml> (the rule is, if your number makes people want to do arithmetic, it's the wrong number)
[07:05] <spiv> jml: sure it is, it means "less than one week"... doesn't everyone know that a week is 168 hours (and that a day is 86400 seconds...)?
[07:07] <vila> spiv: wrong, may French still think a week is 35 hours :-D
[07:07] <vila> s/may/many/
[07:08]  * vila always made typos in jokes :-/
[07:10] <jml> vila, :D
[07:10]  * igc dinner
[07:11] <spiv> vila: hah
[07:29] <vila> spiv: in case things happen without further warnings: enjoy your new life as a dad ! It's certainly one of the most exciting experience in life :-)
[07:30] <spiv> vila: thanks!
[07:55] <MFen> have a conceptual question
[07:56] <MFen> i have a branch of lp:txgenshi, call it O for original.  i also have three branches working on different features for it
[07:56] <MFen> call them A, B, and C. they build on each other in that order (B contains changes from A, C contains changes from B)
[07:57] <MFen> i'm currently working on *B*.  however i need changes from C.  how do i do that without just making B and C the same?
[07:58] <MFen> i want it to be possible to review B without looking at the changes in C
[07:58] <MFen> does stacking help me out in any way with this?
[07:58] <Peng> No.
[07:59] <Peng> Wellll, if you're using Launchpad's review system, when filing the merge proposal for B, you can set C as a prerequisite; then the diff will be against C, so you'll only see B's changes.
[08:00] <Peng> Well, I don't know what exactly the diff will be against, but that's the end result.
[08:01] <MFen> but that'll be circular. B is already a prerequisite for C
[08:03] <spiv> MFen: do you need all of C in B?
[08:03] <MFen> probably, yeah
[08:04] <MFen> B is a bugfix. C is unit tests. they were opened as separate bugs.  i want to add unit tests for the bug fix, but the unit tests didn't exist before I made C
[08:04] <spiv> So you really want to the ordering to be A, C, B, rather than A, B, C?
[08:04] <Peng> You could add B's unit tests in C.
[08:04] <MFen> um. maybe!  C hasn't been reviewed yet, though. what if i need to make changes to C after that?
[08:04] <Peng> Then C would need B, but B would not need C.
[08:05] <MFen> i don't understand what stacking does, if it doesn't allow me to segregate my changes
[08:05] <spiv> MFen: stacking is a storage and network transfer optimisation, not a semantic difference.
[08:05] <MFen> crap.
[08:06] <spiv> MFen: so it allows you to push up just the changes unique to a branch, and say in that branch "you'll find the rest of the history over *there*".
[08:06] <MFen> so basically C is B plus some changes.  therefore it doesn't make any sense to talk about making changes to B that aren't part of C
[08:07] <MFen> right
[08:07] <spiv> Hm, I'm having trouble following you.  One moment it seems that you say B is meant to contain all of C's changes (and history), then the next you say it's the other way around.
[08:08] <MFen> it's both. i *want* to be able to make changes to either one without impacting the other
[08:08] <spiv> I guess the question to ask is "what do you want to present to the reviewers?"?
[08:08] <MFen> otherwise none of this makes any sense, workflow-wise
[08:08] <MFen> it's not just a question of what i present to the reviewers
[08:08] <MFen> that only matters if we all assume my changes are perfect
[08:09] <MFen> if there are any changes needed post-review, then i need to make them in both places
[08:09] <spiv> Well, if your changes are assumed to be perfect, you wouldn't need reviewers ;)
[08:09] <MFen> which means "why did i make two branches in the first place"
[08:09] <spiv> Well,
[08:10] <spiv> if say the branches are ordered A,B,C, and you need to make post-review changes to B...
[08:11] <spiv> Then the change you'd make in C, if it is important that C is kept current with those changes, is just a merge from B.
[08:11] <lifeless> MFen: you ask 'without making B and C the same' - merge B to C regularly. Don't merge C to B ever.
[08:11] <lifeless> MFen: then they won't be the same.
[08:12] <spiv> Which might not impact things like the diff of C vs. B at all.
[08:12] <MFen> lifeless: if i do that, won't the reviewer reviewing C be looking at the changes from B?
[08:12] <lifeless> MFen: depends on how they review
[08:12] <spiv> MFen: not if the reviewer is reviewing C with respect to B.
[08:12] <lifeless> if they look at (B, C] then they get only stuff new to C
[08:12] <lifeless> if they look at (trunk, C] then they get all of A,B,C
[08:13] <MFen> well, let's assume they're using lp's diff view
[08:13] <spiv> MFen: i.e. assume B as a pre-requisite that is being reviewed separately (Launchpad's review system has good support for this)
[08:13] <lifeless> MFen: lp's diff view? do you mean loggerhead?
[08:13] <MFen> hells if i know. i made a merge request, and i see a diff button.
[08:13] <lifeless> MFen: more precisely, gimme a url to be clear about what you mean.
[08:13] <MFen> https://bugs.launchpad.net/txgenshi/+bug/502821 green diff link
[08:13] <MFen> that is C
[08:13] <MFen> 520823 is B
[08:14] <spiv> MFen: then LP will basically show the reviewer the output of "cd lp:.../B && bzr merge --preview lp:.../C"
[08:14] <MFen> spiv: how does it know?
[08:14] <lifeless> MFen: when you propose the merge, you tell it where B is
[08:14] <spiv> MFen: there is a "prerequisite branch" field on the "merge proposal" form
[08:14] <MFen> yeah, but i didn't fill it in
[08:14] <lifeless> MFen: workaround time: cancel that merge proposal. Do it again.
[08:15] <MFen> oh ok, and it is in fact showing my B changes, i think
[08:19] <spiv> MFen: https://code.edge.launchpad.net/~corydodt/txgenshi/502823/+merge/16954 looks promising :)
[08:20] <MFen> ok, cleaning up those merge requests helped, now the diffs show only (B, C]
[08:20] <MFen> spiv: are you claiming the review or just telling me i did it right?
[08:20] <spiv> MFen: just saying that appears you've navigated the lp merge proposal stuff successfully.
[08:21] <MFen> yeah. i think i did that much right
[08:21] <MFen> so moving on to the next step
[08:21] <spiv> MFen: although the __provides__ hack looks a bit alarming tbh!
[08:21] <MFen> yes.
[08:21] <MFen> bzr merge B into C ... the diff for C will still ignore anything merged from B?
[08:21] <spiv> MFen: it may well be right, of course, but I'll leave that to someone with some actually knowledge of the situation to review :)
[08:21] <MFen> no, it sucks. my proposal for this bug eliminates the need for the hack
[08:23] <spiv> MFen: yes, if you update C (including merging a newer B into C) the updated diff will still only show the changes new in C
[08:25] <MFen> ah, because it actually does cd into B first like you said. great.
[08:27] <spiv> MFen: (well, not cd literally, it uses the bzrlib API, but equivalent to that yeah)
[08:27] <MFen> yeah, i get it conceptually
[08:28] <spiv> Cool.
[08:28] <Peng> Say you have branches a, b and c. You file a proposal to merge c into a, with b as a prerequisite. Is the diff just "cd b; bzr merge --preview ../c", or is it like "cd a; bzr merge b; bzr merge --preview ../c"?
[08:29] <Peng> Err, "bzr merge ../b". But you get the point.
[08:29] <spiv> Peng: yes ;)
[08:29] <Peng> Jerk. :P Heh.
[08:29] <spiv> Peng: not sure, abentley or someone else from the lp code team could answer I'm sure, or you could look at the source.  My guess is the former, though.
[08:30] <Peng> I'm sure I could do an experiment, but I'm too sleepy to figure out how.
[08:30] <Peng> Ah. A should have revisions 1-2. B should have 1-X, and C should have 1-Y, I think?
[08:31] <MFen> Peng: what you just described is exactly what i've been doing, i think. so i can tell you it's the first one
[08:31] <Peng> OK. You sure?
[08:31] <MFen> i have a <- b <- c
[08:32] <lifeless> Peng: check the code
[08:32] <Peng> :(
[08:32] <MFen> merge request for c into a, depends on b. the diff shows c diff b, not c diff a
[08:32] <MFen> it assumes you will land b first, i guess
[08:32] <Peng> Not c diff a+b?
[08:32] <MFen> nope
[08:33] <Peng> Huh.
[08:33] <Peng> That would be more complicated and more likely to cause conflicts, but also more correct...
[08:33] <MFen> if you're going to land c before b, then you really don't need b at all. landing c will cause b to land
[08:34] <MFen> in my case i expect b to land first, so it makes more sense to me
[08:45] <MFen> ok, one more question along these lines:
[08:46] <MFen> if i use bzr bind, does that automatically merge changes into whatever location i gave it?
[08:47] <MFen> (therefore, should i always bind A to B and B to C, forward along the dependency chain)?
[08:51] <lifeless> no
[08:51] <lifeless> bind makes a branch work like a checkout
[08:51] <lifeless> e.g. its useful for a shared branch that multiple people commit to, nothing else.
[08:52] <MFen> the glossary says bound branch and checkout are synonyms, so that isn't helping me :)
[08:52] <lifeless> checkout is what svn does
[08:54] <MFen> ok, so it does a push?
[08:54] <lifeless> no
[08:54] <MFen> what happens when i commit to a bound branch
[08:54] <lifeless> it just changes the behaviour of subsequent commands in that directory
[08:54] <lifeless> when you commit in a bound branch it does a 2-phase commit to both the master and the cwd
[08:59] <MFen> is there any difference between that and a puh?
[08:59] <MFen> push
[09:03] <spiv> MFen: bind basically means "keep this branch in sync with the target branch", so when you make a commit both cwd and master are locked, then new revision written to both, then that transaction is committed.
[09:04] <MFen> k
[09:05] <spiv> MFen: whereas if you are unbound and push, the end result is typically the same (both branches at same rev), but obviously how you get there is a bit different, and if other people might write to your branch then the master can diverge between you doing "bzr commit" and you doing "bzr push".
[09:08] <MFen> spiv: is it committed locally in both cases?
[09:11] <spiv> I'm not sure what you mean.
[09:12] <spiv> (I know what sort of things I'd mean by that phrase, but not what you do)
[09:12] <MFen> bzr st will show nothing modified after
[09:12] <Raim> if the commit fails on the bound branch, it fails locally, too
[09:12] <spiv> MFen: right
[09:12] <MFen> ok. so that is a different end result
[09:13] <MFen> in commit+push, it is committed locally even if push fails. in bind+commit, it is not.
[09:13] <spiv> MFen: (assuming the commit succeeds, as Raim points out, though commits may fail for reasons other than a bound branch with diverged master, e.g. pre-commit hook)
[09:14] <spiv> So if you like the big difference is that when things have diverged you'll get a failure at the commit step rather than later.
[09:15] <MFen> ok
[09:16] <lifeless> MFen: there are two key differences between bound commits and  push:
[09:16] <lifeless> firstly, parent ordering is preserved (because you do merges with the same parents as the master)
[09:16] <lifeless> secondly, out of date branches cannot commit when bound.
[09:52] <lifeless> MFen: spiv: sorry for echoing spiv late there, I didn't read to the bottom :)
[11:20] <jelmer> mwhudson: no idea, I thought I had fixed all places where that appears
[11:25] <henninge> HI, I know I had figured it out before but I can't remember how it worked.
[11:25] <henninge> I want to use bzr-pipelines (again) to hack on Launchpad.
[11:26] <henninge> I have my lp-branches repository and in there the devel branch (and other's).
[11:26] <henninge> (forget the ')
[11:27] <henninge> I know pipelines are "just" light-weight check-outs - but of what?
[11:28] <henninge> I don't want a light-weight check-out of devel, because then I'd be committing all changes there.
[11:29] <henninge> Actually, my situation is even different. I have a (heavy-weight) branch of devel that I have been hacking on but now I want to add a pipe to do extra work. I don't know how. I must be missing something obvious.
[11:31] <james_w> bzr reconfigure-pipeline to start I believe
[11:39] <jelmer> mwhudson: these issues usually take up quite a bit of time, perhaps we could have a look in NZ?
[11:43] <henninge> james_w: appearently not if you already have a repository.
[12:05] <henninge> james_w: from bzr help reconfigure-pipeline:
[12:05] <henninge>   This is suitable if you have a standalone tree, but if you have a
[12:05] <henninge>   shared repository with its own organization scheme already, it's probably
[12:05] <henninge>   better to just create a lightweight checkout.
[12:05] <henninge> james_w: I figured it out now:
[12:06] <henninge> bzr branch devel mywork-pipe1
[12:06] <henninge> bzr checkout --lightweight mywork-pipe1 mywork
[12:06] <henninge> cd mywork
[12:06] <henninge> bzr add-pipe mywork-pipe2
[12:07] <henninge> This will create all pipes as siblings, so in my repository I now have directories "mywork", "mywork-pipe1" and "mywork-pipe2".
[12:09] <henninge> The confusing thing is that that the pipe directories don't show any changes, no matter what I commit in mywork, I guess that's because the pipline commands only work on the branch, not the tree. (Or is it the other way round?)
[12:11] <james_w> yeah, I think you "bzr update ../mywork-pipe1" you will see the changes appear
[12:13] <henninge> james_w: yes, it does! cool, thanks
[13:38] <marek_> hi i have a problem, i have two computers and one server, every one has repo , from 1 computer i can push and other can merge, but when i try it in other way - while i try to push i can see "no revisions to push" but i changed some files
[13:38] <marek_> can you help me?
[13:39] <Peng> marek_: Have you committed?
[13:43] <marek_> locally
[13:43] <marek_> yes
[13:43] <marek_> bzr status -> clean
[13:44] <Peng> marek_: Then I guess you've already pushed?
[13:44] <Peng> marek_: Do "bzr log -r -1 -n 1 :push".
[13:44] <Peng> Hmm, that looks a little Git-like. :P
[13:45] <awilkins> You might have a checkout rather than a branch?
[13:45] <awilkins> aka "bound branch"
[13:45] <Peng> Ah, good point. marek_: What does "bzr info" on your local branh say it is?
[13:45] <awilkins> Revisions committed locally automatically committed to remote branch... do `bzr info` in tree
[13:51] <marek_> on server: bzr info:
[13:52] <marek_> http://pastebin.com/m66579407
[13:52] <marek_> on local i can also see something about
[13:52] <marek_> related branches
[13:54] <Peng> marek_: OK, but what's the first line of the client's info?
[13:54] <marek_> standalano tree
[13:54] <Peng> Ah.
[13:54] <Peng> marek_: Then, most likely, you already pushed.
[13:54] <marek_> but i cannot see it on server
[13:54] <marek_> ecen after update
[13:55] <marek_> on othe computer if i merge changes i dont see modified files :(
[13:55] <Peng> marek_: Ohh? What does "bzr log -r -1" say on both branches?
[13:55] <marek_> on local: revno 25 [merge] and commiter - local user
[13:55] <marek_> on server:
[13:56] <marek_> revno 23 and different user
[13:56] <Peng> Huh.
[13:56] <Peng> It's possible something has gone horribly awry, but most likely it's something basic like you're pushing to the wrong place...
[13:57] <awilkins> do `bzr missing --mine <server branch>`
[14:01] <marek_> gosh other pc was using bzr explorer
[14:01] <marek_> and path was ....
[14:01] <marek_> local !!! ^&%&^!%^&@!
[14:41] <mok0> Is there a trick you need to do to update the directory tree in the "central" repo? I have a checkout on my laptop at home, I did a "commit" but I can't seem to extract the changes on my main workstation.
[14:43] <mok0> ... bzr update doesn't do it, I should say.
[14:53] <awilkins> mok0, If the revision you committed on your laptop hasn't been pushed to the main workstation (or a repository it can see) then you can't see those changes
[14:53] <mok0> awilkins: it's a checkout
[14:53] <mok0> awilkins: it gets pushed when I commit
[14:53] <awilkins> They're both checkouts of the same repo?
[14:53] <mok0> yes
[14:54] <mok0> awilkins: I can check tonite if I did something wrong
[14:54] <mok0> Just puzzled
[14:54] <mok0> awilkins: the laptop dir is a checkout of my working dir on the workstation
[14:55] <mok0> awilkins: just wondering if there's a bzr command I don't know about.
[14:56] <awilkins> mok0, Did you do the commit while on the same network as the workstation?
[14:56] <mok0> awilkins: I am using the bzr+ssh protocol. I am not sure I know what you mean by "same network"
[14:56] <awilkins> Try "revert"
[14:57] <mok0> awilkins: nothing happens
[14:57] <awilkins> Can you see the revision you committed from the laptop in the local log?
[14:57] <mok0> no
[14:58] <mok0> Perhaps there's something in .bzr that could give a clue?
[14:58] <awilkins> You have your laptop with you?
[14:59] <mok0> awilkins: No :-) that's the problem. I did some work at home, committed it (AFAIR) and went to work
[14:59] <mok0> w/o the laptop :-)
[14:59] <awilkins> The tree on the laptop is either a standalone, or you committed with the --local flag
[15:00] <mok0> awilkins: well, you must be right
[15:00] <awilkins> Or it's bound to another branch
[15:00] <awilkins> That isn't the one you're working on
[15:00] <mok0> awilkins: apparently :-/
[15:00] <awilkins> Still, merges are easy :-)
[15:01] <mok0> awilkins: fortunately!  The create restrictions just because it's possible
[15:04] <rubbs> I resent that!
[15:04] <rubbs> hehe ;) I'm a part time admin
[15:04] <awilkins> The fewer degrees of freedom your workstation has, the lower the skill required to adminster it
[15:05] <mok0> rubbs: resent what, my statement or what I'm saying?
[15:05] <mok0> rubbs: so am I
[15:05] <mok0> awilkins: hehe
[15:05] <rubbs> just that sysadmins are apposed to openness. I wouldn't quite say that
[15:05] <awilkins> I think it's sensible to prevent normal users doing stuff
[15:05] <rubbs> this is true
[15:05] <mok0> rubbs: I didn't say _all_ sysadms
[15:05] <rubbs> ah, then I'm sorry I over reacted
[15:05] <awilkins> But it's a pain in the ass for developers.. we have a different class of support problems though
[15:06] <rubbs> awilkins: I've been in your boat too, that's why I try to make it easy. finding the balance is hard.
[15:06] <awilkins> Like the time last month when I trashed the stupid full-disk encryption boot block on both my machines... because standard users don't dual-boot Linux from external drives
[15:06] <rubbs> luckily I have a pretty small support group, so I don't have to juggle too many needs.
[15:07] <rubbs> awilkins: haha
[15:07] <awilkins> The knee jerk response would be to prevent booting from external drives.. and would cripple my productivity
[15:07] <awilkins> More interesting than "I forgot my password" though
[15:08] <awilkins> They're now removing admin rights from our users that need them though, on general principles
[15:08] <awilkins> So when you get a new machine on the refresh program, you lose admin rights until you kick up a fuss about it
[15:08] <awilkins> Even if you are developer
[15:08] <mok0> I've been admin for our local network (~20 workstations) for 10-15 years. I've had hacker visits 2-3 times. Always amateurs, and it's taken 5 minutes to get rid of them once I discovered them
[15:09] <awilkins> Windows?
[15:09] <mok0> That is w/o firewall
[15:09] <mok0> awilkins: No! Linux
[15:09] <mok0> Just using the standard tools like iptables etc. to block intruders
[15:10] <awilkins> I just wish our infratructure was friendlier to Linux
[15:10] <mok0> That's why I frown at sysadms who restrict their users in every possible way in fear of hackers
[15:10] <awilkins> They got rid of a perfectly good IMAP server that you could access outside the office network
[15:10] <awilkins> And replaced it with Exchange
[15:10] <mok0> awilkins: isn't that the PURPOSE of an imap server :-)
[15:10] <fullermd> Who needs IMAP?   I work with PHI too.
[15:11] <mok0> awilkins: can't you encrypt them?
[15:11] <fullermd> Pointless.  Google Knows All And Sees All anyway.
[15:11] <awilkins> Used to be able to use thunderbird inside and out
[15:12] <awilkins> Now I use Outlook because otherwise I'll have to use VPN, which is a PITA, or Outlook Web Access which sucketh mightily
[15:12] <mok0> awilkins: :-(
[15:12] <awilkins> mok0, We wouldn't have a large enough contingent of people who understand encryption
[15:13] <mok0> awilkins: hmm. People can be educated
[15:13] <awilkins> mok0, This is an organisation which advocates using an approved motorbike courier because it's apparently secure
[15:13] <awilkins> And destroying _encrypted_ flash media after they served their pupose
[15:13] <mok0> awilkins: what if someone rams him and steals the documents?
[15:14] <awilkins> mok0, Indeed.. they also advocate that sending mails to people on our own email domain to be secure
[15:14]  * mok0 is for unlimited openess on the internets
[15:14] <awilkins> mok0, But as we know, damn sysadmins will just read it
[15:14] <awilkins> mok0, my personal position is GPG for everything
[15:14] <mok0> awilkins: ... and then people print out the confidential mails and bring them home :-)
[15:15] <awilkins> And screw the couriers
[15:15] <mok0> awilkins: I agree
[15:15] <awilkins> And post
[15:15] <mok0> awilkins: absolutely
[15:15] <awilkins> Problem is they take their encryption advice from GCHQ which has the wrong set of requirements
[15:15] <awilkins> Like key escrow
[15:16] <mok0> awilkins: there's no remedy for incompetence in the upper cadres
[15:16] <awilkins> "GPG for everything confidential" is a lot simpler than memorizing rules about whether it's OK to mail someone with a gmail account or which bike messengers are accredited
[15:16] <mok0> awilkins: indeed. And security != control
[15:17] <awilkins> I mean, key escrow for signing keys on medical records... no practitioner will go for that
[15:17] <mok0> I actually don't know key escrow
[15:18] <awilkins> They keep a copy of the private keys centrally
[15:18] <mok0> Ah
[15:18] <mok0> awilkins: that's for unsophisticated users
[15:18] <awilkins> So, what doctor would be happy with "Hey, your records can be VERIFIED to be from you.. apart from if <agency X> wants to fake them"
[15:18] <mok0> exactly
[15:19] <awilkins> Or some hacker steals the escrow DB, which lets face it, would be a FAT target
[15:19] <mok0> Most encryption schemes don't take into consideration that the "bad guy" is the government or some other agency
[15:19] <mok0> That's where GPG differs
[15:19] <awilkins> Or some schmuck in the data centre offered a few $10k for the key database
[15:20] <mok0> awilkins: right
[15:20] <mok0> Well, the climate guys from East Anglia are probably sorry that they didn't encrypt their mail correspondence
[15:21] <awilkins> Whereas my medical record architecture is so private that the patient can potentially restrict access to his records to everyone, except himself.
[15:21] <awilkins> :-)
[15:21] <awilkins> Shame it'll never catch on
[15:21] <awilkins> I should write it up just as a thought experiment and see if I can get a presentation of it under the wire
[15:21] <mok0> awilkins: I'm in a university and I have to tell the students about GPG
[15:22] <mok0> awilkins: good idea
[15:22] <awilkins> I discovered PGP in my first year
[15:22] <awilkins> (some time ago)
[15:22] <mok0> My position used to be this: "I have no secrets, I don't care if ppl see my email correspondence"
[15:23] <mok0> Now I'm not so sure. If someone evil got hold of it all, I'm sure they could dig up some dirt to throw at me
[15:23] <awilkins> Then you have Eric Schmidt saying "Hey, if people have no secrets, they shouldn't care if we see their email"
[15:23] <awilkins> And get worried
[15:23] <mok0> and Eric Schmidt is...
[15:23] <mok0> ?
[15:23] <awilkins> Google person?
[15:23] <mok0> ah
[15:23] <awilkins> I may have wrong guy
[15:24] <awilkins> Nope, right guy
[15:24] <mok0> ... and those statements are meant as a comment to their searching gmail accounts?
[15:25] <awilkins> http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people
[15:25]  * mok0 looks
[15:26]  * rubbs goes and checks it out as well.
[15:27] <mok0> Oh... In principle I agree with Eric Schmidt on this very particular subject
[15:27] <awilkins> I do plenty of things that are legal that I wouldn't want people knowing about
[15:27] <mok0> Although I don't agree with the header... it's somewhat misleading anyway
[15:27] <mok0> awilkins: yes
[15:28] <awilkins>  "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place."
[15:28] <mok0> Of course there are things that are secret. But if they're not, you can't complain that Google finds them
[15:28] <mok0> awilkins: I'm sure that's taken out of context
[15:29] <mok0> Idunno
[15:29] <mok0> Google doesn't index email
[15:29] <mok0> and they shouldnt
[15:29] <awilkins> It seems more reasonable when you view the clip
[15:29] <awilkins> They don't publicly index email
[15:30] <awilkins> They must index it somewhere for you to be able to search it so quickly
[15:30] <mok0> Ah, ok, but my Google Chromium browser wont show it :-D
[15:30] <awilkins> Odd, I'm running Chrome and I see it fine
[15:30] <mok0> I disabled falsh
[15:30] <mok0> flash
[15:30] <awilkins> Ah
[15:30] <awilkins> And they process email so they can show context ads
[15:30] <awilkins> (which you don't see over IMAP, natch)
[15:31] <mok0> I use their imap service so I never see it
[15:31] <awilkins> His point that the government can technically ask them to cough up their data is fair
[15:31] <awilkins> His attitude doesn't seem to have the same tone as the story title
[15:31] <mok0> That is why you should encrypt email that you don't want anyone to see
[15:32] <awilkins> And funnily enough, the clip is from a company owned in large part by MS
[15:32] <mok0> ... then if Eric Schmidt thinks you are filthy... I can live with that
[15:32] <mok0> hehe
[15:33] <awilkins> They should change the email icon to a postcard instead of an envelope
[15:33] <mok0> hehe
[15:33] <mok0> yes
[15:33] <mok0> That's what email is, anyway
[15:33] <awilkins> That envelope icon does more to raise peoples expectations of email privacy than anything else
[15:33] <mok0> "Sending mail in an envelope are for filthy people"
[15:34] <mok0> s/are/is
[15:34] <awilkins> The security policy at work... actually suggests LABELLING the envelope you send with a courier as a secure document
[15:34] <awilkins> Ahaahahahahahahhahaha
[15:34] <awilkins> "STEAL ME"
[15:35] <mok0> Now THAT'S funny!!
[15:35] <awilkins> Not that security by obscurity is a good thing
[15:35] <mok0> :-)
[15:35] <awilkins> But damn, labelling things as being more valuable? Before handing them to a guy who earns £5 an hour to motorcycle through British weather?
[15:35]  * mok0 thinks most investigations are done by traffic analysis anyway
[15:37] <mok0> The (insert favourite TLA) just needs to locate terrorist/criminal/etc. networks
[15:37] <mok0> they can do that by traffic analysis, and there's nothing you can do about it
[15:38] <mok0> NOTHING
[15:39] <J-m-D> We are using svn for versioning. Our useage is a bit "uncommon" - we mainly have binary files, and quite large ones. The central repository is very important for us so we have a central back up aswell as central access to all files. Could bzr bring something to the table that we miss out on in svn?
[15:40] <J-m-D> btw - we are all on windows
[15:41] <mok0> J-m-D: the most obvious advantage is the ability to have off-line branches
[15:41] <mok0> J-m-D: "distributed development"
[15:41] <J-m-D> something that is not very important for us atm.
[15:42] <mok0> J-m-D: AFAIK tagging and branching is heavy in subversion. Do you use that a lot?
[15:42] <rubbs> J-m-D: bzr also allows for easier merges. merging in svn is pretty tough... although I haven't done it in svn in a while admittedly
[15:42] <awilkins> Bazaar is less adept at coping with large binary files... but there are some advantages, esp. if they are compressible
[15:43] <awilkins> e.g. - I've got a Bazaar working tree + repo with full history that's 2.5GB... the SVN checkout on it's own is 4.0GB
[15:43] <J-m-D> Branching and tagging is almost non-existant with us for now.
[15:44] <mok0> J-m-D: if you only need a "data store" then I honestly don't think it matters what VCS you use
[15:44] <mok0> J-m-D: if you are planning to revise your workflow, then bzr offers lots of options
[15:45] <mok0> J-m-D: consider svn a subset of bzr
[15:45] <J-m-D> svn seems to handle binary files quite good - revisions are made incrementally which is nice. It makes updates and comitts less heavy. How does bzr handle revisions of binary files?
[15:46] <mok0> J-m-D: ugh. Don't know to be honest. I just know it works
[15:46] <mok0> J-m-D: personally, I use it quite a lot for PDF files
[15:48] <J-m-D> What could be interesting is if bzr is more flexible than svn in handling revisions of individual files. If we want to have an older version of something, it is allmost allways just an individual file - we never make a new branch of a project.
[15:50] <mok0> J-m-D: Don't you use the status of the entire directory tree?
[15:51] <J-m-D> Nope, very seldom since we mostly work on large graphics files and 3D graphical assets.
[15:52] <mok0> J-m-D: then I'd suggest to use a separate repo for each component
[15:52] <mok0> J-m-D: that you can check out in whatever context you need
[15:53] <J-m-D> ohh, I'm afraid that would be totally impractical - there are quite a few components for every project.
[15:53] <mok0> bzr can give you a svn-like workflow, but it can also give you other options
[15:53] <rubbs> J-m-D: I think that you could still get individual files, but it would probably be from a branch.
[15:53] <mok0> J-m-D: I see
[15:53] <J-m-D> Renaming is allso quite indflexible in svn since it seems to be made by a delet-and-re-comitt-method or something. Takes quite a while to get it done on a large repository.
[15:54] <mok0> J-m-D: the best I can suggest is to try out bzr on your project and see how it performs in practice
[15:54] <J-m-D> mok0: I guess I'll have to do that. Thank you for all the imput - much appreciated.
[15:55] <litwol> hello
[15:55] <mok0> J-m-D: good luck! Come back later, perhaps ther are more qualified ppl
[15:55] <litwol> What command allows me to list available project branches ?
[15:55] <litwol> and how can i switch between them ?
[15:56] <J-m-D> mok0 - sure will. And your suggestions were good enough for me at least. Thanx again.
[15:56] <mok0> litwol: branches are stored in each their directory
[15:56] <rubbs> J-m-D: renames are supported in bzr as fully versioned.
[15:56] <litwol> oh ...
[15:57] <beuno> vila, so we're releasing 1.0?  :)
[15:57] <mok0> litwol: there are ways of working with stacked branches but I've not tried that
[15:57] <J-m-D> rubbs: oki. interesting. thnx
[15:57] <vila> beuno: hehe, not yet, but that doesn't forbid using the milestone :)
[15:57] <mok0> litwol: in it's basic form, no bzr branch would know about other branches... only the parent
[15:58] <litwol> i c
[15:58] <litwol> ty
[15:58] <J-m-D> thanks for now. See you later guys.
[15:58] <mok0> litwol: however, if you use Launchpad, it's different
[15:58] <beuno> vila, we should figure out what we want for 1.0, and target it!
[15:58] <rubbs> J-m-D: np. see you later
[15:59] <vila> beuno: I agree, I think the list we did at UDS is a good target, I'm fighting for free time to work on it though :-/
[15:59] <vila> beuno: may be we should just go for time-based release...
[15:59] <beuno> vila, we'll pull through, even if it's me hacking up code you you cleaning it up  ;)
[16:00] <beuno> well, it is stable enough
[16:00] <beuno> I'll go through the list of bugs and features
[16:13] <jam> morning vila and beuno
[16:14] <vila> morning jam
[16:19] <beuno> hiya jam
[16:33]  * vila EODing, already late for school meeting :-.
[17:00] <chx> i just committed with the wrong commit message can i change it?
[17:02] <chx> ah bzr uncommit
[17:02] <chx> great.
[17:06] <maxb> Has anyone performed any sort of trade-off analysis of methods of converting from svn to bzr? There seem to be quite a few of them.
[17:15] <jelmer> maxb: What sort of tradeoffs do you mean?
[17:16] <maxb> Any discussion that would assist me in deciding which method I'm better off using
[17:18] <jelmer> maxb: Can you give some examples of tradeoffs though, I'm not sure exactly what you mean by that.
[17:20] <maxb> I have lots of projects in a svn repository which I'd like to convert to separate bzr repositories. I see that there are at least two mainstream methods of doing so - bzr-svn and bzr-fastimport -  and a bunch of other ones too. I'm looking for any guidance that will help me choose which I should use.
[17:23] <jelmer> maxb: as far as I know both should be able to convert subprojects to separate bzr repositories
[17:25] <jelmer> bzr-fastimport doesn't do deterministic revision ids, so you can't pull from the original svn branch later on unless you have the mapping files
[17:25] <jelmer> but on the other hand, it might do rename detection, which bzr-svn doesn't do
[17:42] <maxb> OK, I guess I'll just need to explore the options
[17:43] <maxb> On another topic, is there any software to facilitate code review via bzr branches that companies can install for internal use - i.e. not Launchpad.
[17:43] <maxb> I was going to look at BundleBuggy, but the project doesn't seem too healthy now bzr has left it
[17:47] <awilkins> maxb, Launchpad can be installed locally... it's rather large though... I've just never had the time to finish configuring it
[17:48] <maxb> awilkins: Yes, but not legally, unless you find a graphics designer to make you a new set of icons
[17:48] <awilkins> What license are the icons under?
[17:49] <maxb> Canonical Proprietary
[17:51] <awilkins> Does "internal code review" count as development or production... but yes, that's slightly troublesome
[17:56] <jelmer> maxb: reviewboard has bnasupport
[17:57] <jelmer> maxb: reviewboard has basic support for bzr bundles
[17:57] <maxb> I will have to investigate that
[18:15] <jam> maxb: BundleBuggy is probably not actively maintained by abentley anymore, but it is probably a decent starting point.
[18:15] <jam> I've heard good things about ReviewBoard, though.
[18:16] <maxb> The most dispiriting thing about BundleBuggy was that it has quickstart documentation that doesn't work :-)
[18:24] <rindolf> Hi all! I just blogged about how much bzr sucks - http://community.livejournal.com/shlomif_tech/41922.html
[18:25] <nailuj24> rindolf: well done my dear...
[18:26] <jpds> rindolf: Which version of bzr are you using?
[18:26] <rindolf> jpds: 2.0.3
[18:27] <jpds> Format <RepositoryFormatKnit4> for lp-64863440:///~inkscape.dev/inkscape/trunk/.bzr is deprecated - please use 'bzr upgrade' to get better performance
[18:27] <jpds> rindolf: Tell the Inkscape guys to do that.
[18:28] <rindolf> jpds: it's in my bug report.
[18:28] <rindolf> If it's hosted on LP , why isn't it upgrade automatically?
[18:29] <rindolf> It takes a second for bzr --version to run.
[18:29]  * fullermd gets very unhappy with hosting providers screwing with his data...
[18:29] <maxb> rindolf: Because it would be very stupid for Launchpad to silently force new formats on people when their local bzr versions might not be new enough
[18:29] <jpds> rindolf: Backwards compatibility with what the developer is using I guess.
[18:32] <maxb> rindolf: Whilst I agree that bzr's speed is not great, I don't think the attitude of your blog or bug report is anything other than unproductive
[18:32]  * fullermd notes that the branch of postr takes 26 seconds, and the diff 0.16 from here..
[18:33] <fullermd> Of course, going over a dumb protocol (http) means that latency is going to kill you flat dead.  And you may be rather farther away from it than I am.
[18:34] <maxb> rindolf: In fact, why on earth do you comment on the time taken for the error to occur, when it's clearly a network problem
[18:40] <Tak> originality: 4% accuracy: 6% grammar: 20% emotionality: 30% overall troll: 10%
[18:41] <pturcotte> Is there a way to prune (remove) a part of the history? Let's say from revision 1 to X while the actual version is at X+50 ?
[18:41] <james_w> pturcotte: no, that's not really possible
[18:41] <rindolf> maxb: if it stops in the middle, I should be able to resume it later.
[19:16] <Flydoire|Taktik> hi everyone
[19:17] <Flydoire|Taktik> I just tried to install bzr on snow leopard from the pkg. bzr command does not work : bzr: ERROR: Couldn't import bzrlib and dependencies
[19:17] <Flydoire|Taktik> anyone has an answer ?
[19:28] <pturcotte> james_w: thanks.
[19:29] <pturcotte> Then, is there a way to reduce the disk usage of the branch. My branches are around 420Mb, mostly binary files that are not in use anymore.
[19:33] <james_w> not really, bzr is designed to have immutable history, and it's tough to get around that
[19:36] <Kinnison> Do we have history horizon yet?
[19:36] <mwhudson> jelmer: ok, i guess we should file a bug in the mean time?
[19:45] <awmcclain> Hi all -- I've been looking through help commands but can't find it -- How do I get the last revision that a particular file was changed?
[19:48] <luks> something scriptable? if not, I'd use bzr qbrowse
[19:50] <luks> (`bzr qbrowser -r -1` to be more specific)
[19:50] <luks> otherwise you probably have to mess with bzr log
[19:51] <luks> which is not going to be very fast
[19:51] <luks> I don't know of any built-in command that exposes the information, even though bzr has it easily available
[19:52] <awmcclain> luks: Ok. Sounds great. Thanks!
[20:17] <Flydoire|Taktik> familiar with this error ? : bzr: ERROR: exceptions.TypeError: Auth providers should be list ?
[20:28] <lifeless> Flydoire|Taktik: no, but I'd guess at a old plugin or something like that.
[20:28] <Flydoire|Taktik> hum
[20:29] <Flydoire|Taktik> what about bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(connected=True, username=u'fl-taktik', host='bazaar.launchpad.net', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
[20:29] <Flydoire|Taktik> .
[20:29] <Flydoire|Taktik> ?
[20:31] <fullermd> That's usually a secondary symptom.  Perhaps of the error you mentioned before.
[20:32] <Flydoire|Taktik> will the bazaar.launchpad.net server kill my concurent requests so that it will work in a few hours ?
[20:32] <fullermd> There probably AREN'T any concurrent requests.  It just looks like it when the connection fails.
[20:33] <fullermd> (that error is from your local bzr, not from LP)
[20:33] <Flydoire|Taktik> how to I fix it ? Do I have to get the latest trunk version ?
[20:34] <fullermd> Are you sure there's something to fix?
[20:34] <fullermd> That's an error that pops up in a single bzr invocation, and usually is just fallout from an earlier error.
[20:35] <Flydoire|Taktik> I just got the bzr: ERROR: Could not acquire lock "(remote lock)":
[20:35] <fullermd> It doesn't in itself leave anything hanging around for later runs.
[20:35] <Flydoire|Taktik> so I break-lock
[20:35] <Flydoire|Taktik> and I bzr pull again
[20:35] <Flydoire|Taktik> and boom : bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests
[20:36] <Flydoire|Taktik> what shoul I do ?
[20:36] <fullermd> Yes, that's not from the break-lock.  That's from some failure in that specific invocation, probably having to do with the connection either breaking or not being properly established.
[20:37] <fullermd> Is there any output other than that?
[20:37] <Flydoire|Taktik> yep
[20:38] <Flydoire|Taktik> http://pastebin.com/d38355f11
[20:40] <fullermd> What the error generally boils down to is a generic sort of "Hey, I can't seem to talk across this connection I expect to be there"
[20:41] <fullermd> So you need to figure out why the connection isn't working out.
[20:41] <fullermd> There may be something in .bzr.log about it, or you may need some debug flag...   -Dhpss maybe, to get it to tell you more.
[20:41] <fullermd> (I don't know what would show you useful output)
[20:42] <fullermd> Start off simple; can you connect to LP with sftp?
[20:42] <Flydoire|Taktik> trying
[20:43] <Flydoire|Taktik> yes
[20:44] <fullermd> 'k...   try pulling over sftp instead of bzr+ssh (just change the protocol on the URL).  'll be a lot slower, but...
[20:45] <Flydoire|Taktik> where do I change the protocol ? in .bazaar/authetication.conf ?
[20:45] <fullermd> No, just do it manually.
[20:45] <fullermd> bzr pull sftp://......
[20:46] <Flydoire|Taktik> worked :D
[20:46] <Flydoire|Taktik> thanks fullermd
[20:47] <fullermd> 'k, so it's just something with bzr+ssh.
[20:47] <fullermd> Try it with that regular URL again; maybe it was just a transient problem somewhere.
[20:47] <Flydoire|Taktik> ...trying...
[20:47] <fullermd> (you definitely don't want to use sftp instead of bzr+ssh in general; lot slower and more resource-consuming on both ends.  Useful diagnostic though, since it tests most of the same infrastructure)
[20:48] <Flydoire|Taktik> worked fine
[20:48] <fullermd> If it consistently works with sftp, and consistently fails with bzr+ssh...   well, we've localized it at least.  I don't know where do go from there, if something like -Dhpss doesn't tell any more.
[20:48] <Flydoire|Taktik> maybe a pb in my repository ?
[20:48] <fullermd> Hm.  OK.  We'll just chalk it up to Random Internet Schizo Crap   8-}
[20:49] <Flydoire|Taktik> works : bzr pull<EMAIL_ADDRESS>[20:49] <Flydoire|Taktik> does not work :  bzr pull
[20:50] <fullermd> Well, that's a very different URL from what you've got there as the parent...
[20:50] <Flydoire|Taktik> with
[20:50] <Flydoire|Taktik> $ bzr info
[20:50] <Flydoire|Taktik> Checkout (format: unnamed)
[20:50] <Flydoire|Taktik> Location:
[20:50] <Flydoire|Taktik>        checkout root: .
[20:50] <Flydoire|Taktik>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/
[20:50] <Flydoire|Taktik> Related branches:
[20:50] <Flydoire|Taktik>     push branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/
[20:50] <Flydoire|Taktik>   parent branch: bzr+ssh://bazaar.launchpad.net/~openerp/openobject-addons/5.0/
[20:50]  * fullermd blinks.
[20:51] <lifeless> ok, you shouldn't be pulling here
[20:51] <fullermd> OK, well...   I'm not sure what you're asking for makes much sense.
[20:51] <lifeless> use update instead
[20:51] <fullermd> pull'ing the branch you're a checkout of is nugatory.
[20:51] <Flydoire|Taktik> ok : sorry, I'm new to bzr, and it's quite confusing
[20:52] <fullermd> Now, it may make sense to pull that parent.  I can see how that might legitimately give that error, if bzr is being too dumb or too smart about its connection, though.
[20:53] <fullermd> So, that might actually be a legitimate case of that error message.
[20:54] <Flydoire|Taktik> pull is to get changes from other branches, update just updates the current branch, right ?
[20:54] <fullermd> Update roughly means "update my working tree to match the branch".  Pull roughly means "update my branch to match this other branch".
[20:55] <fullermd> So when you run 'bzr update', you're saying "Get this working tree at . up to match the branch at bzr+ssh://[...]/taktik/"
[20:55] <fullermd> 'bzr pull' is saying "Update my branch at bzr+ssh://[...]/taktik/ to match the branch at bzr+ssh://[...]/5.0/"
[20:56] <fullermd> It's believable that bzr is doing something overly {smart,stupid} about trying to reuse a single connection to LP to do both sides of that.
[20:56] <fullermd> Which would bring up that error.
[20:56]  * fullermd passes that one to lifeless.
[20:57] <jelmer> mwhudson, please do
[20:58] <Flydoire|Taktik> ok, thank you for your time fullermd
[20:58] <jelmer> mwhudson: does that branch have any round-tripped revisions?
[20:58] <mwhudson> jelmer: your guess is as good as mine
[20:58] <jelmer> mwhudson: svn proplist on the branch root should tell you
[20:59] <mwhudson> jelmer: it has a svk:merge property, is that enough?
[20:59] <jelmer> mwhudson: that would suggest at least that the problem is not in the roundtripping
[21:00] <jelmer> mwhudson: although svk does often create very strange situations
[21:09] <poolie> hi jam?
[21:09] <poolie> hi all
[21:09] <jam> hi poolie
[21:09] <jam> good morning
[21:13] <poolie> shall we talk?
[21:22] <awmcclain> luks: What if I used bzrlib? I'm scripting the rev stuff, but it's from a python script
[21:22] <awmcclain> luks: Would that be faster?
[21:23] <luks> awmcclain: should be easy enough to write a plugin that does that
[21:24] <luks> oh, it's actually a python script
[21:24] <luks> yes, that should be easy
[21:25] <luks> not sure if I'm the best person to help though. my bzrlib knowledge is probably mostly obsolete by now :)
[21:28] <luks> I'd use something like wt.inventory[wt.path2id(filename)].revision
[21:28] <luks> but there is probably a better way now
[21:29] <awmcclain> thanks!
[21:35] <lifeless> awmcclain: bzr ls would be a good place to put that query
[21:35] <lifeless> awmcclain: in order to make it more easily scriptable
[21:35] <awmcclain> lifeless: Ah, smart.
[21:36] <awmcclain> What, you don't like  bzr log  settings.py | sed -n 2p | sed "s/revno: \([0-9]*\).*/\1/"? ;)
[21:36] <lifeless> awmcclain: not really, no.
[21:36] <lifeless> awmcclain: :)
[22:16] <jam> awmcclain: besides, grepping .bzr/checkout/dirstate would be a lot faster :)
[22:40] <igc> morning
[22:43] <mr-russ> in bazaar, can I merge a number of commits and push them as a single changeset to a parent tree?  I can't find if you can in the documentation.
[22:45] <lifeless> mr-russ: bzr branch parent foo; cd foo; bzr merge source_branch; bzr commit; bzr push :parent
[22:46] <mr-russ> okay, so you merge from a branch which appears then as a single changset and push that.
[22:46] <mr-russ> so in bugfix lifecycle you branch for bugfix, make 10 commits to get it all fixed propertly.  merge to you parent tree, then commit and push.
[22:49] <m3ga> hi all, i'm looking for a pre-commit hook that would check all the files in the current commit, check if they have a copyright notice and if they do check if the current year is included in the (c) notice. if its not it would barf.
[22:51] <mr-russ> okay, now conversely, how would you keep the entire commit history when pushing?  push the child tree directly?
[22:53] <lifeless> mr-russ: yes
[22:53] <lifeless> mr-russ: no data is lost either way; its just what is presented
[22:56] <mr-russ> lifeless: thanks.  I've been unable to find anything on that from google.
[23:36]  * igc bbl
[23:50] <poolie> hi igc
[23:50] <poolie> hi m3ga
[23:50] <poolie> m3ga, i don't know if there is one like that
[23:50] <poolie> i think there is a plugin that enforces whitespace rules and similar things at commit time
[23:50] <poolie> and jml has one that checks for todo comments
[23:51] <poolie> so you could adapt one of them
[23:51] <jml> lp:bzr-todo


[12:35] <jenda> nevermind, fixed
[12:53] <mpt> (From the "meanwhile in other bugtrackers" department: RESOLVED LATER and RESOLVED REMIND have just been removed from Bugzilla CVS.)
[12:55] <Ubugtu> New bug: #58776 in malone "clicking on 'file a bug against foo' link leads to 'foo does not exist in Dapper' error message" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58776
[01:01] <mpt> Goooooooooooooooood morning Launchpadders!
[01:47] <jelmer> mpt: It's starting to feel like Ground Hog Day now you're doing that daily ;-)
[01:49] <LarstiQ> gooooood night! ;)
[01:56] <mpt> ~ They say that love won't pay the rent ~ Before it's earned, our money's always spent ... ~
[02:00] <Ubugtu> New bug: #58784 in blueprint "Spec page refers to non-existent "Specifications in grey"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58784
[03:26] <jamesh> mpt: have you seen this spec? https://features.launchpad.net/distros/ubuntu/+spec/internet-sharing
[03:33] <mpt> jamesh, no I hadn't. That looks pretty ... interesting.
[03:33] <jamesh> mpt: I wonder if the person thought "this isn't a bug, but rather a feature request ..."
[03:34] <mpt> I wasn't the one who thought the spec tracker should be a separate application :-P
[03:35] <Ubugtu> New bug: #58791 in malone "+subscribe page contains non-useful radiobutton" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58791
[03:38] <mpt> jamesh, see also https://launchpad.canonical.com/MaloneAndBlueprintIntegration
[03:40] <Cogito_ergo_sum> hi good night
[03:45] <mpt> ... and good luck
[05:05] <mpt> jamesh: ping
[05:05] <jamesh> mpt: pong
[05:07] <mpt> jamesh: https://devpad.canonical.com/~andrew/paste/fileRYXA42.html
[05:07] <mpt> Any idea what's going on here?
[05:08] <jamesh> mpt: you are using the most recent pqm-submit plugin?
[05:10] <mpt> revno 22
[05:10] <mpt> parent branch: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/bzr-0.8/
[05:11] <mpt> hmm, is that bad when trying to use it with bzr 1.0ish?
[05:11] <jamesh> yes
[05:11] <jamesh> try this:
[05:11] <jamesh> cd ~/.bazaar/plugins/pqm-submit
[05:11] <jamesh> bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel
[05:12] <jamesh> to get the updated version
[05:12] <jamesh> (this version also has smtp auth support, btw)
[05:12] <mpt> great!
[05:12] <jamesh> you can set smtp_username and smtp_password in ~/.bazaar/bazaar.conf and it'll do the right thing
[05:12] <mpt> aha, I have a conflict from my manual ayuth change
[05:13] <jamesh> bzr revert then.
[05:13] <mpt> yeah
[05:14] <mpt> ok, now bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel says "0 revision(s) pulled"
[05:14] <jamesh> there are 22 revisions on both the bzr-0.8 and devel branches
[05:15] <mpt> but bzr info is still pointing at the wrong parent branch
[05:15] <jamesh> so the difference in length of revision history is 0
[05:15] <jamesh> ah.
[05:15] <jamesh> "bzr pull --remember http://..." should fix that
[05:16] <mpt> 0 revision(s) pulled...
[05:17] <mpt> but now it has the correct parent
[05:17] <jamesh> configure your SMTP username/password in ~/.bazaar/bazaar.conf and retry the pqm-submit command
[05:18] <mpt> bzr: ERROR: No PQM submission address specified in configuration
[05:18] <jamesh> argh.  That's the shadowing problem again ;(
[05:18] <mpt> the what? :-)
[05:20] <jamesh> one section of ~/.bazaar/locations.conf shadowing settings from another section
[05:22] <mpt> The second line of locations.conf is "pqm_email = Canonical PQM<EMAIL_ADDRESS>[05:22] <mpt> There are no other pqm_email lines
[05:23] <mpt> just various branches with push_location lines, and one branch with both a push_location and a pqm_branch
[05:26] <mpt> pqm-submit doesn't seem to let me specify the address explicitly
[05:29] <mpt> Removing the section for this branch from locations.conf seems to work (though it's going so slowly, it hasn't gotten up to asking for my password yet)
[05:30] <mpt> ok, it didn't work after all. It tried to mail<EMAIL_ADDRESS>instead of mailing<EMAIL_ADDRESS>[05:31] <mpt> (Host or domain name not found. Name service error for name=canonical.com type=MX: Host not found, try again)
[05:39] <mpt> hurrah, copying all the config stuff from the global section to that branch's section worked
[06:40] <SteveA> morning
[07:08] <jamesh> stub: ping?
[07:12] <stub> jamesh: pong
[07:13] <jamesh> stub: last week I put together a script to clean up the [https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/NNNN]  text that was inserted into the comments of bugs imported from bugzilla.ubuntu.com
[07:13] <jamesh> stub: I was wondering if you could look over it and maybe run it in production this week if it looks okay
[07:14] <jamesh> I did a test run on demo.launchpad.net which seemed to go okay
[07:14] <stub> ok. Still going through my email from last week so haven't got to that one yet.
[07:15] <Ubugtu> New bug: #58806 in blueprint "Specification page contains unexplained "(n days)" text" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58806
[07:16] <jamesh> stub: the code is here: https://devpad.canonical.com/~jamesh/fixup-bug-references -- it needs to be run as a user that can update the MessageChunk table
[07:17] <stub> jamesh: Please email me the details if you haven't already so I don't forget by the time I've cleaned out my pile
[07:19] <jamesh> stub: done.  the thread is "Rewriting bug numbers and dupe comments"
[07:19] <stub> k
[07:20] <stub> (302 in inbox to go, then the mailing lists :-( )
[07:21] <jamesh> stub: second thing: would it be possible to get another product-release-finder run done on staging?  I believe the problem we ran into last time has been fixed.
[07:21] <stub> Last I left it it was scheduled to run daily
[07:22] <jamesh> hmm
[07:23] <jamesh> stub: the product-release-finder code keeps a cache of URLs that it has previously processed in /var/tmp/productreleasefinder, which is probably why it didn't look like it was doing anything
[07:24] <jamesh> stub: would it be possible to blow that cache away so we can see how it runs now?
[07:24] <stub> jamesh: It died last night with an ftp error
[07:25] <jamesh> I've got a branch in the review queue to get rid of the cache code, but for now it would prevent the releases from being created after a DB refresh
[07:25] <stub> jamesh: https://devpad.canonical.com/~andrew/paste/fileRtP8Iz.html
[07:26] <stub> Yer - only turned on ftp_proxy on production
[07:26] <jamesh> stub: that indicates that ftp_proxy wasn'
[07:26] <jamesh> t set
[07:27] <SteveA> stub: morning
[07:28] <SteveA> stub: in the launchpad meeting, in the "production and staging" section, people listed things they particularly want to get into production this week
[07:29] <stub> jamesh: it is rerunning now anyway
[07:29] <jamesh> stub: with the cache blown away?
[07:29] <stub> jamesh: yes
[07:29] <jamesh> thanks
[07:31] <cbx33> Is it possible to send a mail to everyone in a LP group?
[07:31] <stub> jamesh: I suspect we should be storing this cache in the Librarian, as we don't really want to download a few gb of data every time the server is rebooted, or /var/tmp otherwise cleaned.
[07:32] <jamesh> stub: I'm getting rid of the cache completely
[07:32] <stub> excellent
[07:32] <jamesh> stub: the database contains all the state needed to handle repeated runs, so the cache just adds a point of failure
[07:32] <SteveA> stub: are you planning to do a rollout this week?  if so, please mail the launchpad list to say what will happen.
[07:32] <stub> SteveA: I have no idea yet. I'm still going through my backlog, and probably will be for few hours
[07:32] <SteveA> stub: okay
[07:33] <SteveA> mpt: have you looked at the meeting summary for thursday yet?
[07:33] <jamesh> it'd be nice to get a rollout done this week -- there's been lots of fixes since the last one
[07:38] <lifeless> stub: welcome back
[07:38] <stub> :-)
[08:14] <stub> Lunch
[09:06] <SteveA> jamesh: hi, around?
[09:06] <jamesh> SteveA: yeah
[09:06] <SteveA> jamesh: got a few minutes for a chat with me and mpool about some bzr infrastructure work?
[09:06] <jamesh> SteveA: sure.
[09:32] <mpt> SteveA, looked at it? I wrote it. Or are you referring to a different meeting?
[09:32] <SteveA> mpt: if you wrote it, that's great.  I want to point stub at the production/staging section, so that he can know what was discussed, and what code people want to get landed
[09:33] <mpt> ah, but I forgot to update MeetingAgenda
[09:33] <mpt> I'll do that now
[09:34] <SteveA> thanks
[09:34] <SteveA> and please mail stub too
[09:36] <mpt> ok
[09:38] <mpt> done
[09:39] <mpt> and done
[09:51] <jamesh> stub: how's the product-release-finder run going?
[09:52] <stub> Hmm.... go boom
[09:52] <lifeless> :(
[09:53] <stub> https://devpad.canonical.com/~andrew/paste/file35Ccxs.html
[09:54] <lifeless> blech
[09:54] <lifeless> encoding
[09:54] <lifeless> and on a 503 error ? wtf
[09:55] <lifeless> there seem to be two errors mentions
[09:56] <Burgundavia> SteveA: can we get a user to change his wiki name if it is possibly misleading? (ubuntupr)
[09:56] <carlos> morning
[09:58] <jamesh> lifeless: the 503 error is probably an earlier request.
[09:58] <stub> I agree with James
[09:58] <jordi> hi carlos
[09:59] <lifeless> kk
[09:59] <stub> There are other 503's earlier in the output handled just fine (although we really shouldn't be logging them as tracebacks since they are expected)
[09:59] <jamesh> the walker class should be generating log messages
[09:59] <jamesh> I wonder why it isn't.
[09:59] <stub> DEBUG level? I didn't run it with -v
[10:00] <jamesh> it should be generating info level messages
[10:00] <jamesh> looks like it isn't passing the log object down that far.
[10:02] <stub> There is a global that can be used (although it was naughty to do it that way)
[10:02] <stub> (Made unit tests a pita)
[10:02] <jamesh> I'll look at getting the walker logging working
[10:03] <jamesh> and I suppose we should handle BeautifulSoup parse failures better too
[10:03] <stub> I thought BeautifulSoup was supposed to handle badly formatted soup
[10:04] <jamesh> I wonder if we can get at the squid logs to get an idea of what it accessed last?
[10:05] <stub> Looks like encoded strings are leaking into it rather than Unicode (or whatever encoding BS is expecting?)
[10:05] <jamesh> given that the log doesn't include that info
[10:06] <lifeless> oh now thats a cute idea
[10:06] <stub> #canonical-sysadmin might be able to help here
[10:06] <stub> c/here/there/
[10:06] <lifeless> create a function dynamically called the name of the thing it is about to try
[10:06] <lifeless> then you dont need log barf to read the traceback usefully ;)
[10:07] <lifeless> more sensibly, how about a top level catch-all try:except: print; raise
[10:07] <lifeless> around or in handleProduct
[10:07] <jamesh> lifeless: the traceback formatter from zope takes a different approach: if any frame has a local called __traceback_info__, it is pretty printed along wiht the frame in the traceback
[10:07] <lifeless> jamesh: thats nice
[10:08] <lifeless> back in 1 hr
[10:08] <jamesh> stub: what machine was the script running on?
[10:08] <stub> gangotri
[10:16] <stub> mpt: Your bug queries on the mailing list (in the preventing duplicates thread) - do you want results for open bugs or all bugs?
[10:17] <stub> Actually, needs to be all bugs or else the later ones regarding duplicates won't make sense (since duplicate bugs are never closed atm)
[10:28] <SteveA> hi ddaa
[10:28] <SteveA> do we have a meeting today?
[10:28] <ddaa> hi SteveA
[10:28] <ddaa> Meeting in 92 mins
[10:28] <SteveA> thanks
[10:29] <ddaa> SteveA: got a very detailed agenda on BazaarMeetingAgenda if you care to look
[10:29] <SteveA> yes
[10:29] <SteveA> i do
[10:29] <SteveA> Burgundavia: hi
[10:30] <Burgundavia> SteveA: did you see my comment?
[10:30] <SteveA> Burgundavia: I'm sure we *can* change someone's wiki name.  I think it would be better to ask them to change it themselves first.
[10:31] <SteveA> there's also the issue of who says we *ought* to change it.  the ubuntu wiki is governed by the CoC and the CC, I think
[10:31] <SteveA> so, while I have technical power, I don't have the "right" to do anything so long as it isn't causing a technical problem.
[10:32] <SteveA> is there someone beneath the CC who is responsible for encouraging good conduct on the wikis?
[10:34] <SteveA> ddaa: where can I read the agenda?
[10:34] <SteveA> stub: ever looked at xapian?  I was talking with alan runyan about it at the weekend.
[10:35] <ddaa> https://launchpad.canonical.com/BazaarMeetingAgenda
[10:35] <stub> SteveA: Nope. I don't even know what it is
[10:35] <ddaa> "Meeting plan" section is the outline for the meeting
[10:35] <ddaa> that is all the bit I plan to copy-paste
[10:35] <SteveA> stub: some kind of hot shit free software text searching system.
[10:35] <SteveA> http://www.xapian.org/
[10:36] <ddaa> and I will use that as template for the summary, I'll try to keep doing it that way in the future, as that will force me to keep the agenda up to date
[10:36] <SteveA> stub: alan does various work with the developers, so if this is at all interesting for us, we can talk with people.
[10:36] <SteveA> ddaa: reading
[10:37] <SteveA> stub: alan says the tech is great.  the bindings are gross.
[10:37] <Burgundavia> SteveA: apparently, it is nobody that is listed as his real name in LP
[10:37] <ddaa> stub: welcome back
[10:38] <SteveA> Burgundavia: what's the launchpad page for this person?
[10:39] <Burgundavia> SteveA: I cannot find it, because none of the LP pages for  Carlos Rivera has a wikiname of UbuntuPR
[10:39] <ddaa> stub: is rollout planned for today?
[10:39] <Burgundavia> and there are 6 hits for Carlos Rivera
[10:43] <SteveA> Burgundavia: I see no wikiname of UbuntuPR in the database.
[10:44] <Burgundavia> https://wiki.ubuntu.com/UbuntuPR
[10:45] <SteveA> there are lots of names containing the text "ubuntu"
[10:45] <Burgundavia> indeed
[10:46] <SteveA> Burgundavia: https://launchpad.net/people/crrivera
[10:46] <SteveA> aha
[10:47] <Burgundavia> hmm, I will email him
[10:47] <Burgundavia> thanks for the find
[10:47] <Burgundavia> I wish launchpad.net/foo would do a search for foo
[10:47] <Burgundavia> much like packages.d.o or .u.c does
[10:47] <SteveA> on the staging database, his wiki name is Crrivera
[10:47] <SteveA> so, this must be a recent change
[10:48] <Burgundavia> the page for his name just go created
[10:49] <SteveA> there is a search form on launchpad.net/people/
[10:49] <SteveA> it doesn't search wikinames right now
[10:49] <SteveA> it could do though.  file a bug if you want such a feature.
[10:52] <stub> SteveA: I think I remember this now - Richard Jones was using it with Roundup and he seemed to like it.
[10:52] <stub> SteveA: Not yet suitable for us though as we need to glue it into PostgreSQL
[10:54] <stub> SteveA: Seems to offer the same feature set as tsearch2, with the addition of wildcard searches. No idea if they use some magic index for fast wildcard searching or if it would be with similar restrictions to PostgreSQL LIKE
[10:56] <ddaa> stub: is rollout planned for today?
[10:56] <stub> ddaa: No. And I'm not sure about tomorrow yet (still clearing intrays)
[11:12] <sivang> morning
[11:26] <jamesh> stub/lifeless: I've got the problem page that tripped up product-release-finder will see if I can reproduce it
[11:42] <ddaa> whaaaa! gimme my crack of the week! gimme! gimme!
[11:43] <jamesh> I blame Norman Walsh
[11:43] <ddaa> jamesh: how snob, why don't you blame Daniel Bernstein like everybody else?
[11:44] <jamesh> ddaa: the page was http://www.docbook.org/xml/
[11:44] <jamesh> (although the real problem was BeautifulSoup not handling the UTF-8 on that page)
[11:45] <Ubugtu> New bug: #58835 in soyuz "Debian Installer garbage collection not working?" [High,Confirmed]  http://launchpad.net/bugs/58835
[11:46] <jamesh> hmm looks like the problem is the way PRF is using BeautifulSoup
[11:47] <ddaa> PRF, you mean URTF?
[11:47] <ddaa> unless you mean Dyson maybe?
[11:47] <jamesh> product-release-finder
[11:48] <ddaa> thanks for demonstrating that anything longer than two words ends up as an obscure acronym :)
[11:49] <stub> Indeed. Dyson is much easier to remember, and its name need not change as the scope of its tasks changes over time ;)
[11:52] <carlos> jamesh: hi, how's going my code review? I would like to get it cherrypicked this week so we approve a bunch of entries automatically as soon as possible...
[11:57] <jamesh> carlos: not yet done.  I'll make sure it is done by tomorrow
[11:57] <carlos> jamesh: thank you
[11:57] <carlos> did you started it?
[11:58] <carlos> I have a small trivial change related to automatic approvals and if you didn't start I would prefer to add it there instead of using [trivial]
[11:58] <carlos> it doesn't affect directly to the changes already done ther
[11:58] <carlos> there
[11:58] <ddaa> lifeless: -> #launcphad-meeting
[11:58] <jamesh> carlos: just add it to the branch.  I haven't done that much on the branch yet.
[11:58] <carlos> ok
[11:59] <carlos> jamesh: thanks
[12:07] <stub> What does PAS stand for again?
[12:08] <lifeless> piece a shit
[12:08] <stub> That makes sense in this context, but I don't think it is correct
[12:09] <malcc> Packages arch-specific
[12:09] <stub> ta
[12:38] <lifeless> review meeting in 22
[12:45] <lifeless> review meeting in 15
[12:53] <SteveA> it's so nice our RCS isnt' called "arch" anymore, as "PAS" would be doubly confusing
[12:55] <lifeless> review meeting in 5
[01:01] <SteveA> hmm... massive rain shower
[01:01] <lifeless> review meeting time
[01:01] <lifeless> whos here ?
[01:01] <SteveA> hello.  iamhere
[01:02] <BjornT> me
[01:02] <jamesh> me
[01:02] <lifeless> hi guys
[01:02] <lifeless> next meeting time - sept 11
[01:03] <lifeless> this time
[01:03] <SteveA> +1
[01:03] <lifeless> ok
[01:04] <lifeless>  * queue size
[01:04] <lifeless>  * other items
[01:04] <lifeless> queue has 5 items in it - oldest is salgado & 9 days
[01:04] <lifeless> all the rest are 3 or less, which is inside our service level
[01:05] <lifeless> BjornT: can you nag salgado, 9 days for a 77 line review is - excessive - and your time zones should cross
[01:05] <BjornT> lifeless: yeah, i'll send an email to him, reminding him that he should check his queue daily
[01:06] <lifeless> BjornT: hmm, was hoping more personal ;)
[01:06] <lifeless> BjornT: I'll send such a mail after this meeting
[01:06] <lifeless> if you see him on IRC though, please nag in person
[01:06] <BjornT> ok
[01:07] <lifeless> andrew put up a proposal
[01:07] <lifeless>  * what to do about merges that aren't properly reviewed?  (AndrewBennetts)
[01:07] <lifeless>    Seeing as I'm on leave this week, here's my thoughts for discussion, ready for pasting into the channel: {{{
 Some recent merges concerned me a little:
 r3995 was merged without review by the review team [r=cprov,malcc]
 r4001 was merged with [rs=elmo]  (and built on the changes in r3995).
 I did an unsolicited post-merge review of 4001 (and some of 3995), and found a bunch of issues.  Nothing terrible, but certainly the quality was less than I'd approve as-is.  I'd rate it about merge-conditional.
 I propose that someone (Robert?) checks the commit list daily, and assigns "trivial", rubber-stamped, and other anomalous merges to reviewers for post-merge review, much like the pre-merge review queue.  It's easy to run "bzr diff -r 1000..1001 | less", so we wouldn't need to pre-generate diffs.
 In theory, these should be rare enough and/or small enough that it shouldn't add much to the review load, but it might help keep quality from slipping.
 What do people think?
[01:07] <lifeless> }}}
[01:08] <jamesh> Sounds like a good idea (and something we've discussed in the past)
[01:08] <SteveA> i'm in favour of it.  i'd also like to see some progress on getting diffstats and links in the mails from pqm
[01:08] <SteveA> and i'm glad spiv has been doing such reviews
[01:09] <lifeless> I think its a good idea
[01:09] <BjornT> sounds good to me as well.
[01:09] <lifeless> I'm not sure how much overhead it will take
[01:09] <SteveA> malcc: would you comment on this?  was there a particular reason that r3995 was not reviewed by the review team?
[01:09] <lifeless> both on reviewers for the additional reviews, and for the assigner to ensure they catch everything
[01:09] <jamesh> does the fact that people are putting these large changes through as trivial (or not reviewed by a review team member) indicate problems with our process?
[01:10] <malcc> SteveA: kiko asked me and Celso for our thoughts on the patch, which we provided, then he went ahead and merged with that r=
[01:10] <SteveA> hi cprov
[01:10] <cprov> SteveA: hi
[01:10] <malcc> SteveA: I wasn't sure exactly what the procedure was, so I didn't know if I should be objecting or not
[01:10] <Ubugtu> New bug: #58842 in soyuz "sync-source doesn't understand pockets (eg. -proposed)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58842
[01:10] <lifeless> malcc: you should start with PreMergeReviews and read from there
[01:10] <SteveA> so, the code was by kiko, with some review from malcc and cprov?
[01:11] <lifeless> malcc: the whole process is documented :)
[01:11] <malcc> lifeless: Thanks
[01:11] <malcc> SteveA: Yes
[01:11] <SteveA> was there a reason that this code needed to land in a hurry?
[01:11] <SteveA> like, urgent fixes to get cherrypicked?
[01:12] <jamesh> seems a bit weird given we didn't have a rollout scheduled last wek
[01:12] <jamesh> week
[01:12] <malcc> SteveA: No. In fact the landings during the sprint have led to a situation where rocketfuel is effectively undeployable for Soyuz on drescher at the moment, until we finish the testing we've started since the sprint
[01:12] <malcc> SteveA: As far as I could tell, kiko was just in a hurry and being kiko
[01:12] <SteveA> you mean, you're running non RF stuff in production?
[01:12] <lifeless> heres what I propose - we try spics suggestion for 1 week. At the end of it, we gather reviewers feelings on those reviews, and mine on the overhead of generating the reviews to do
[01:13] <lifeless> *spivs*
[01:13] <malcc> SteveA: We're running an older rocketfuel in production, with some (also rocketfuel) cherrypicks
[01:13] <lifeless> theres some statistical principle that suggests the unreviewed merges spiv looked like are more likely to be typical than atypical
[01:14] <SteveA> I see.  so, careful soyuz updates until you finish the testing and associated code.
[01:14] <lifeless> SteveA: soyuz gets special treatment on rollouts
[01:14] <SteveA> I think in this case, kiko considered himself the representation from the review team on that branch
[01:15] <SteveA> but, I think seeing as kiko also wrote the code, that that's not sufficient oversight to get consistent quality in the code
[01:15] <lifeless> SteveA: as he wrote the patch, our current protocol excludes him from that role
[01:15] <SteveA> but, let's ask kiko about it later
[01:15] <lifeless> and the results that spiv found correlate to the oversight thing you are saying there
[01:15] <lifeless> anyhow, I dont think that this one patch is exceptional
[01:16] <lifeless> which is my point - understanding this one matters, but trialling post-merge-reviews of trivial and rs merges is worth doing
[01:16] <SteveA> +1 to your proposal of trying spiv's proposal for 1 week
[01:16] <lifeless> *regardless* of the genesis of the soyuz patch
[01:17] <lifeless> jamesh: I dont know if our process has problems
[01:17] <lifeless> jamesh: but I think anything other than mandatory reviews will get occasional abuses
[01:17] <malcc> Incidentally, would someone be kind enough to tell me off for allowing my name in r= when I'm not a reviewer? This way, if I'm asked to do this again, I'll be being honest when I say I got slapped for it last time :)
[01:17] <BjornT> lifeless: +1 to trying spiv's suggestion
[01:17] <SteveA> malcc: there are situations where a domain expert will review, and that can be noted.
[01:17] <lifeless> malcc: I dont think you need telling off
[01:18] <jamesh> lifeless: occasionally the queue gets overloaded leading to longer review times, which'd encourage some people to try and bypass it
[01:18] <SteveA> the point is, there was no member of the code review team in there
[01:18] <lifeless> malcc: you *did* a review.
[01:18] <lifeless> malcc: but what we would have wanted there was [r=spiv, r=malcc, vc=bjorn]  ...
[01:18] <lifeless> or some such
[01:18] <SteveA> vc?
[01:18] <lifeless> voice call, cant remember the abbreviation
[01:19] <SteveA> very cool?
[01:19] <SteveA> p=
[01:19] <jamesh> p=
[01:19] <lifeless> sucks to be me eh?
[01:19] <lifeless>  * other business
[01:20] <jamesh> spiv has a few very old branches in merge-conditional.  I guess that's not really a review team problem though
[01:21] <lifeless> its worth us putting some pressure on folk, but no, its definately those peoples problem, according to the process documentation
[01:21] <lifeless> 'you are responsible for getting your branch through the review process'
[01:22] <lifeless> we seem to be idling, so
[01:22] <lifeless>  * other business ?
[01:22] <BjornT> nothing from me
[01:22] <SteveA> no
[01:22] <jamesh> no
[01:22] <lifeless> meeting over, kthx
[01:33] <sivang> any idea someone how I can reach Kinnison ?
[01:34] <sivang> if anybody has his phone number, could you please PM me?
[01:45] <Ubugtu> New bug: #58847 in launchpad "product-release-finder HTTPWalker " [Untriaged,Confirmed]  http://launchpad.net/bugs/58847
[02:48] <stub> malcc: Should I update drescher's code during tomorrows roll out? Or leave it with you and cprov?
[02:48] <cprov> stub: we will need to do it later
[02:49] <stub> ok. I'll leave it with you too
[02:49] <stub> (bit early for you cprov, isn't it?)
[02:49] <cprov> stub: nop, almost 10 AM here
[02:49] <stub> Bit late for me then ;)
[02:50] <cprov> stub: I guess so ;)
[03:03] <carlos> see you!
[03:31] <Ubugtu> New bug: #58766 in ubiquity "Ubuntu Installer Crash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58766
[05:00] <SteveA> hi kiko
[05:00] <SteveA> how's it going?
[05:19] <kiko> SteveA, going super. how's it going up north?
[05:32] <kiko> hey malcc how's it going?
[05:33] <malcc> kiko: Going well, I was just preparing an email to the launchpad list updating the status of the soyuz system test stuff
[05:33] <kiko> ah, mind-reader
[05:35] <Keybuk> ddaa: ping?
[05:37] <Keybuk> ddaa: unping
[05:37] <ddaa> Keybuk: you're welcome
[05:38] <Keybuk> ddaa: no worries
[05:48] <kiko> ddaa, Keybuk: what is product-release-finder [going to be]  used for?
[05:49] <ddaa> It will automatically create Release objects with associated tarball by looking into the tarball locations specified in series/+source
[05:49] <jamesh> kiko: it is all part of the master plan
[05:50] <Keybuk> what's product-release-filnder ?
[05:50] <ddaa> it is related to things like NoSourcePackage, and
[05:50] <ddaa> Keybuk: the new name for Dyson
[05:50] <Ubug2> New bug: #58881 in launchpad-cal "Accessing /+calendar/+subscriptions without logging in crashes" [Low,Confirmed]  http://launchpad.net/bugs/58881
[05:50] <ddaa> ... and relating vcs-imports to package imports (sourcerer)
[05:50] <Keybuk> oh right
[05:51] <Keybuk> so yes, it scans FTP sites and downloads tarballs
[05:51] <ddaa> kiko: old stuff which was first talked about two years ago
[05:51] <jamesh> Keybuk: we've almost got it working too ...
[05:51] <Keybuk> registers the ProductRelease records and the tarballs in the Librarian
[05:51] <Keybuk> so they can be later imported into bzr
[05:53] <kiko> salgado, can you explain the change in r3957 in layman's terms?
[05:54] <kiko> gotcha.
[05:54] <kiko> thanks jamesh, Keybuk, daa
[05:54] <kiko> ddaa.
[05:57] <salgado> kiko, ProberFactory had a deferred attribute and one callsite was poking with it, causing the callbacks to be called in the wrong order, in some cases.  I fixed the bug, renamed deferred to _deferred and left a comment explaining why it needs to be private
[05:57] <kiko> salgado, what does it do in practice though?
[05:59] <salgado> in practice it suppresses the AlreadyCalledErrors you've seen on the output of nighly.sh. :)
[05:59] <kiko> so... "A bug that caused mirror probes to be issued in an inconsistent order was fixed."?
[06:00] <salgado> not the probes themselves, as they don't need to happen in a specific order
[06:01] <kiko> what then? the probe handlers?
[06:01] <salgado> a bug that caused the callback chain of the mirror prober to be in the wrong order
[06:01] <kiko> right.
[06:15] <Ubug2> New bug: #58887 in launchpad-bazaar "Rank branches by heat" [Wishlist,Confirmed]  http://launchpad.net/bugs/58887
[06:24] <kiko> BjornT, ping?
[06:24] <ddaa> Seeking feedback on https://launchpad.net/products/launchpad-bazaar/+bug/58889
[06:24] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]
[06:25] <Ubugtu> New bug: #58888 in soyuz "Death row processing needs to be added to cron.daily" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58888
[06:29] <kiko> malcc, filed that bug ^^^
[06:29] <kiko> ddaa, that doesn't sound bad at all
[06:30] <Ubugtu> New bug: #58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]  http://launchpad.net/bugs/58889
[06:33] <BjornT> kiko: pong?
[06:33] <kiko> BjornT, I sent you email, fine to reply there
[06:33] <BjornT> ok
[07:57] <kiko-fud> is staging bonked? carlos?
[07:58] <carlos> kiko-fud: let me check
[08:00] <carlos> hmmm
[08:01] <carlos> kiko-fud: it's the language pack export... a full Edgy export takes a lot of time...
[08:01] <kiko-fud> carlos, can you please request a box for you?
[08:01] <kiko-fud> we can't have language packs halt systems for other people all the time.
[08:01] <carlos> as a workaround, yes
[08:01] <carlos> I should schedule some time to improve its performance
[08:02] <carlos> stub told me about using production server
[08:02] <carlos> with a mirror
[08:03] <carlos> kiko-fud: I will talk with Stuart tomorrow again about it
[08:03] <kiko-fud> carlos, thanks.
[08:04] <carlos> np
[08:43] <kiko> ddaa, do branches now have whiteboards?
[08:55] <kiko> BjornT, did you make any progress on attaching-files-to-bugs-through-email?
[08:57] <BjornT> kiko: no, other things came up. i can do it this week, though. you were ok with attaching files via unsigned emails, right?
[08:58] <kiko> I just wanted to catch up with you on that.
[08:58] <kiko> I don't know if it's more a priority than the bugtracker improvements we discussed
[08:58] <kiko> what do you think?
[09:03] <kristog> hello :)
[09:03] <BjornT> i think it is. it should take only one day, and i think it's quite common for people to try attaching files via email. there has been complains about that before, that triager asks for extra information, and the reporter attaches it to the email.
[09:03] <kristog> i wonder if *normal* launchpad users can close $main-package bugs.
[09:04] <kristog> yesteday i tried to close a dbus bug but i didn't find the usual combo_box
[09:10] <kiko> kristog, were you logged in?
[09:11] <kristog> yes.
[09:12] <kiko> then it's odd.
[09:12] <kiko> do you have a URL?
[09:12] <ddaa> kiko: they had whiteboards since forever
[09:12] <kiko> oh. you can now edit one when adding branches then.
[09:12] <kristog> kiko: forgot it...now it works
[09:12] <ddaa> kiko: yup
[09:12] <kristog> kiko: https://launchpad.net/distros/ubuntu/+source/dbus/+bug/47354
[09:12] <Ubugtu> Malone bug 47354 in dbus "dbus won't upgrade without current lsb-base" [Medium,Needs info]
[09:12] <kiko> thanks ddaa
[09:13] <kiko> kristog, that's usually a symptom of not being logged in.
[09:13] <kristog> nono, i was logged in,
[09:13] <kristog> but * dbus (Ubuntu) * was not clickable.
[09:14] <kristog> kiko: btw, forget it, now it works :)
[09:16] <kristog> thank you
[11:00] <mpt> Goooooooooooooooooooooooooooooooooooood morning Launchpadders!
[11:03] <ddaa> hey mpt, I'd like your opinion on https://launchpad.net/products/launchpad-bazaar/+bug/58889
[11:03] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]
[11:09] <mpt> ddaa, +1 on all that, except I suggest making the link "Show n merged/abandoned branches", and putting it under the list instead of above it (and making it a grey "No merged/abandoned branches" non-link if there aren't any)
[11:11] <ddaa> So you suggest "[Show|Hide]  n merged/abandoned branches", and if there are None "No merged/abandoned branches" on both the normall and the show=all page?
[11:11] <ddaa> At the bottom of the page.
[11:16] <mpt> ddaa, exactly so.
[11:16] <ddaa> mpt: Thank you, would you be kind enough to take credit and put that in a comment to that bug :)
[11:35] <mpt> ddaa, done
[11:35] <ddaa> mpt: thank yoiu
[11:44] <mpt> "sabes un favor dime como puedo insicribirme en ubuntu y asi poder acceder a los discos que ofrecen"
[11:44] <mpt> Anyone able to tell me what that means?
[11:45] <mpt> Are they wanting Ubuntu CDs?
[11:48] <matsubara> mpt: yes
[11:48] <matsubara> mpt: but I don't speak spanish
[11:49] <ddaa> yup
[11:50] <ddaa> Rustily: "Please tell me how to sign up on Ubuntu to access to the discs you are offering"
[11:50] <matsubara> that's exactly the meaning I got from my portuol :)
[11:50] <ddaa> which is a remarkably polite way to ask it if you compare to what we get from some other countries
[11:53] <mpt> cool, thanks
[11:55] <ddaa> Good night.