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