[03:25] <quotemstr> If I have a branch that's diverged from upstream, how do I discard my changes and revert so I can use 'pull' again (instead of merge)?
[03:40] <spiv> quotemstr: pull --overwrite
[03:40] <quotemstr> spiv: Thanks.
[04:44] <poolie> and then 'bzr revert'
[04:44] <poolie> hi spiv
[04:50] <spiv> Hi poolie.
[04:51] <spiv> poolie: I'm currently digging into the libffi package import failure: initially it was the old stacked repo problem, but having repaired the stacked repositories (to have the parent inventories) some fetches still fail
[04:51] <poolie> ok, that's good
[04:52] <poolie> i'm working on getting X going on my laptop
[04:52] <poolie> well, on my laptop with an external screen
[04:52] <poolie> and i will push on 220464
[04:52] <spiv> poolie: I *think* there may be an issue when a revision in a stacked repo has the same inventory and thus same CHK maps as one of revisions immediately over the stacking boundary
[04:52] <poolie> would be interested in your thoughts on the mp actually, if you didn't comment already
[04:52] <poolie> not the diff, just the conceptual thing of when we should consider it safe to break
[04:53] <poolie> hm, interesting
[04:55] <spiv> And relatedly I'm finding there's no good in-tree documentation of the stacking invariants, and so perhaps unsurprisingly even if the code is correct here it's a bit unconvincing.
[04:55] <poolie> that would be good to add
[04:55] <poolie> hm
[04:55] <poolie> i don't think we have properly closed things up about adding developer documentation
[04:55] <spiv> Because it just does a bunch of stuff to determine what records are interesting and uninteresting, without explaining/justifying why.
[04:55] <poolie> for instance, how much we should insist on it being done in the mp
[04:55] <poolie> right
[04:55] <spiv> Yeah, I don't think so either, but I don't have any great ideas to fix that.  I am actually in the middle of drafting an addition about stacking to doc/developers/fetch.txt
[04:56] <spiv> But more out of a lack of better ideas about where to write it down in-tree than because I feel it'll actually acheive much :/
[04:56] <poolie> anyhow, i short, i think updating them would be very good
[04:56] <poolie> jorge gave a talk at UDS encouraging people to delete bad data from the Ubuntu wiki
[04:56] <poolie> i liked it
[04:57] <poolie> in fact he challenged people to delete 5 bad things from the internet each
[04:57] <spiv> Heh.
[04:57] <spiv> A productive variation on "someone is wrong on the internet" :)
[04:58] <spiv> poolie: so regarding the stale locks breaker
[04:59] <spiv> poolie: my first impression is "isn't your patch ok then?"
[04:59] <poolie> :)
[04:59] <poolie> on the whole it is
[04:59] <poolie> i think.
[05:00] <poolie> rebooting to try a new kernel
[05:00] <spiv> As all the scenarios people are actually concerned about (as opposed to pathological hypotheticals) seem likely to work ok.
[05:00] <poolie> i think so
[05:00] <spiv> Hmm
[05:00] <poolie> the hypotheticals like having two machines with the same name and the same disk are not... ridiculously contrived
[05:00] <spiv> True, especially with default hostnames.
[05:01] <poolie> but perhaps not that likely to happen
[05:01] <spiv> But people do tend to customise hostnames almost always?
[05:02] <spiv> If there were a portable way to get machine- (or boot-) specific unique info to add in, then great, but there isn't that I know of, so that's a can of worms.
[05:02] <spiv> I don't really like the idea of being in the business of finding out MAC addresses or whatever.
[05:03] <spiv> If only "time at boot" was a portably available feature ;)
[05:05] <spiv> poolie: so I guess my thought is "if there's a config option to disable it and/or make it more conservative" then I'm totally comfortable
[05:05] <spiv> We have to balance this against the risk that users today don't understand how locks interact with smart servers
[05:06] <poolie> right
[05:06] <spiv> So the answer they give to break-lock (which bzr does suggest they run) is probably going to be wrong at least as often as your heuristic!
[05:06] <poolie> exactly
[05:06] <poolie> ok, thanks for that
[05:06] <poolie> i'll just have a look at the pqm failure then
[05:07] <spiv> Ok, time to go grab a pie, bbiab.
[05:07] <poolie> :) enjoy
[07:16] <spiv> poolie: https://code.launchpad.net/~spiv/bzr/doc-stacking-constraints/+merge/63640
[07:18] <poolie> thanks!
[07:20] <poolie> unicode's elipsis character is not really all that well typeset
[07:20] <spiv> Dear unity: please unhide all the windows that were on workspace 3
[07:20] <poolie> at least in monospace
[07:21] <poolie> ok, replied
[07:21] <poolie> and rebooting again
[07:30] <vila> hi bazaaristas !
[07:44] <jam> morning all
[07:44] <vila> jam: hey !
[07:45] <spiv> Good afternoon vila, jam
[07:45] <jam> hey poolie, sorry I missed you yesterday
[07:45] <spiv> jam: would you mind taking a look at https://code.launchpad.net/~spiv/bzr/doc-stacking-constraints/+merge/63640?
[07:46] <jam> spiv: certainly
[07:46] <jam> another way to describe the short rule
[07:47] <jam> "a repository must be able to generate a valid stream for revisions it claims are present, without having access to a backing repository"
[07:47] <jam> I'm not sure what is clearer
[07:47] <jam> I agree with vila that the short rule should be at the beginning of the document.
[07:48] <spiv> Given a sufficiently clear definition of "valid stream", of course :)
[07:48] <jam> spiv: your opening statement is actually slightly wrong
[07:48] <jam> the actual requirement
[07:48] <spiv> Excellent!
[07:48] <jam> is that if someone has X, and we have Y descended from X
[07:48] <jam> then they can get everything for Y that they need from us
[07:48] <spiv> Ah yes.
[07:49] <spiv> That is what I was trying to say, but you're right I didn't quite hit the mark.
[07:49] <jam> the idea of "complete stream" is that we can generate everything needed for Y *without* the backing repo
[07:49] <spiv> Right.
[08:02] <poolie> hello jam, vila
[08:02] <vila> _o/
[08:19] <vila> Does anybody know the fullname of Geoff/xaav ?
[08:24] <spiv> vila: see the committer in the bzr revisions
[08:24] <spiv> Well, it's closer anyway :)
[08:25] <vila> hmm, I was wondering if it was a nickname or his true fullname :-/
[08:26] <vila> I'd settle with Geoff/xaav in the news entry, if he disagrees we can fix it later
[08:59] <jam> spiv: do you want me to rewrite the text a bit, or are you working on it?
[08:59] <spiv> jam: just done, and in fact sent to PQM
[09:00] <spiv> jam: you're certainly welcome to polish that version even further if you think you can improve it :)
[09:00] <jam> spiv: sure, I just didn't want to be editing something concurrently
[09:00] <spiv> ...and that's 6pm, so probably a good point to wind up.
[09:01] <spiv> jam: just briefly before I go
[09:02] <spiv> jam: I think GC's stream source is maybe not quite right when there are inventories with identical contents in the "interesting" and "uninteresting" sets
[09:02] <jam> spiv: it is possible
[09:02] <jam> would take a bit of digging
[09:02] <spiv> Actually, hmm, this is probably a discussion to have a touch more time for
[09:02] <jam> I think I see your point (direct root inventories of the interesting set should be sent)
[09:03] <spiv> Right
[09:03] <spiv> As an example, the current state of lp:libffi/debian/experimental; try fetching that into an empty repo
[09:03] <Merwin> Can someone tell what's the best way to know if a directory is a valid bzr repo ? Is there a command which return 0 or 1 ?
[09:03] <spiv> (and then try making a standalone branch of it...)
[09:04] <jam> Merwin: "bzr root" ?
[09:04] <jam> not sure about the return code, though
[09:04] <spiv> Anyway, I'll happily keep digging into that tomorrow
[09:04] <Merwin> jam: Thanks
[09:04] <spiv> The stacking invariant docs were written partly to make sure I had it clear in my head exactly what the requirements are.
[09:05] <spiv> G'night folks
[09:05] <vila> spiv: g'night
[12:21] <strycore> Hi
[12:22] <strycore> Is there any way to configure bzr so I can type bzr branch bzr+ssh://myserver/myproject instead of bzr+ssh://myserver/path/to/repo/myproject ?
[12:25] <fullermd> You could look at the bookmarks plugin.
[12:26] <fullermd> Or create a symlink in your homedir and use /~/myproject/
[12:27] <bigjools> is there a way to uncommit a sub-commit inside a branch that I merge to my branch?
[12:27] <fullermd> You can only uncommit off the top.
[12:28] <bigjools> yeah, as I thought :(
[12:28] <fullermd> Removing a rev in the middle somewhere means you need to create new revs for everything after it.
[12:28] <bigjools> well it was at the top of the other branch I merged
[12:29] <bigjools> then I did a bunch of conflict resolution, not realising, and now I have to re-do all that work :(
[12:30] <fullermd> Do you really need to eliminate it from the history, or is it OK to just create a new commit reversing it?
[12:30] <bigjools> I can't reverse it because my branch will eventually get merged back to the other one
[12:31] <fullermd> Ah.  Yeah, then you're stuck with nothing to do but re-do the merge.
[12:31] <bigjools> my day just gets better!
[12:32] <maxb> bigjools: So, you just want to have merged one less revision than you actually did?
[12:33] <bigjools> maxb: pretty much, yeah
[12:33] <maxb> I'd probably do something like this
[12:33] <maxb> 1. Uncommit the merge
[12:34] <bigjools> I could uncommit + shelve each
[12:34] <maxb> 2. Forget the pending merge tip
[12:34] <maxb> 3. Shelve the tree changes
[12:34] <maxb> 4. Rerun the merge minus the unwanted revision
[12:34] <maxb> 5. "bzr revert ." - revert the tree, but keep the pending merge tip
[12:35] <maxb> 6. Unshelve the tree from 3.
[12:35] <maxb> 7. Manually or with the aid of patch get rid of tree changes from the unwanted revision
[12:35] <maxb> 8. Commi!
[12:35] <maxb> +t
[12:35]  * vila nods
[12:36] <vila> 9. Check that merge --preview <that branch with the unwanted revision> is what you expect
[12:38] <bigjools> right, I'll bash that in, thanks for the help!
[12:39] <vila> bigjools: you'll need bash-dwim for 7 :-/
[12:40] <fullermd> Y'know, if you'd just integrate bash-dwim with the bug tracker on LP, it would save an awful lot of development effort.
[12:43] <vila> That's what I meant... :)
[12:44] <bigjools> I just snapped my fingers and it all worked like magic
[12:46]  * vila sends black helicopters to capture fingers
[13:10] <jam> jelmer: it looks like your add-by-delta patch broke the case-insensitive code for windows.
[13:11] <jam> I'm not positive, but: http://babune.ladeuil.net:24842/job/selftest-windows/435/
[13:11] <jam> that's what it looks like
[13:11] <jam> vila: the "test_branch_local_remote" doesn't fail here, the other 2 do
[13:12] <jelmer> jam: Ah, hmm. Thanks for letting me know, I'll have a look
[13:12] <jelmer> unless you're already looking into it?
[13:14] <vila> jam: fuzzy memory, but I think there are multiple tests failing with .pack files involved, some failures  may be transient ?
[13:15] <jam> vila: I'll see if I can provoke it
[13:16] <jam> I've also seen some things like that fail because it is a single CPU instance
[13:16] <jam> because it changes how GIL contention works
[13:16] <vila> jam: also, #437 doesn't have this failure, so transient++
[13:16] <jam> vila: after 15 runs, no failures here
[13:17] <jam> vila: one problem with rename failures, is we don't know if it failed because of the target, or the source.
[13:17] <jam> I'm guessing source was still marked as open
[13:17] <jam> "sftp" is very suspcious
[13:17] <jam> because of non-deterministic closure
[13:17] <jam> jelmer: also, I'd really like to work with you on barry's "is this branch up-to-date" command. Is it somewhere I can just poke at it myself?
[13:18] <vila> jam: did you query babune for a big/huge log file ? (couple of minutes ago ?) I saw a weird spike on disk accessees
[13:18] <vila> s/ee/e/
[13:18] <jam> vila: nothing more than opening that url and the linked urls.
[13:19] <jam> some are modestly sized
[13:20] <vila> nah, just the tracebacks shouldn't explain that.... unless jenkins needs to load the whole log file to display them (and cache it then)
[13:20] <spiv> strycore: yes, or perhaps more accurately you can configure your sshd to do that:
[13:22] <spiv> strycore: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html#using-ssh
[13:40] <strycore> thanks fullermd and spiv :)
[13:53] <jelmer> jam: I was hoping to finish the bzr deployment to lp related fixes today; should we meet for some pair programming sometime this week?
[14:37] <jam> jelmer: sure. I think the lp stuff is most important for now
[15:21] <maxb> jubany Request: ./requeue_package.py python-unit python-werkzeug language-pack-az language-pack-gnome-uz # Transient failures
[15:22] <maxb> (+1 for the mysterious cpuarrayd import, which isn't actually a problem since the package does not exist in Ubuntu or Debian)
[15:27] <james_w> maxb, done
[15:27] <maxb> thanks
[15:28] <james_w> maxb, cpuarrayd never existed, or just no longer exists
[15:28] <james_w> ?
[15:28] <maxb> james_w: Launchpad now claims it never existed
[15:29] <maxb> Though apparently it temporarily existed at some point
[15:29] <maxb> Or perhaps someone did  requeue --force on a bogus name?
[15:30] <jimi_hendrix> hello, i am using bazaar explorer to branch something, but i keep getting the following error: bzr: ERROR: Unsupported protocol for url
[15:31] <james_w> maxb, yeah, that's certainly possible, I think there are a couple of odd package names in the db when I mistyped things
[15:31] <maxb> jimi_hendrix: Well... what is the url?
[15:32] <jimi_hendrix>  lp:~snova/+junk/lyx
[15:36] <jimi_hendrix> maxb, ^
[15:41] <maxb> hm
[15:41] <maxb> Well, I don't see anything wrong there, so you'll need someone who has actually used bzr-explorer, which I have not
[16:07] <jimi_hendrix> maxb, going from the command line works
[16:07] <jimi_hendrix> dont know what was up
[16:30] <vila> jimi_hendrix: unsupported protocol for 'lp:' strongly hints at plugin disabling
[18:31] <jam> vila: if he is using bazaar explorer, he probably has plugins enabled, but maybe unselected "Launchpad" from being installed.
[18:32] <vila> jam: but he said the command-line was working...
[18:32] <jam> I missed that part. Definitely strange
[19:26]  * gour notices that someone descended from the heaven here
[19:38] <arnetheduck> hi, I'm getting 207 failures when running the selftest on win7 64-bit py2.7 - is that normal or should I report it somewhere?
[19:56] <james_w> arnetheduck, http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/lastCompletedBuild/testReport/ only sees two failures currently
[19:57] <james_w> arnetheduck, so I would say yes
[19:57] <james_w> as a bug I mean
[20:22] <arnetheduck> james_w, I'm testing a fairly recent lp:bzr with no compiled extensions - maybe that makes a difference?
[20:26] <james_w> arnetheduck, I'm not sure
[20:26] <james_w> the no compiled extensions thing may be involved
[23:03] <poolie> hi all
[23:23] <mgz> hey poolie.
[23:33] <poolie> hi mgz