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:25 |
---|---|---|
spiv | quotemstr: pull --overwrite | 03:40 |
quotemstr | spiv: Thanks. | 03:40 |
poolie | and then 'bzr revert' | 04:44 |
poolie | hi spiv | 04:44 |
spiv | Hi poolie. | 04:50 |
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:51 |
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:52 |
poolie | hm, interesting | 04:53 |
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:55 |
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:56 |
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:57 |
spiv | poolie: so regarding the stale locks breaker | 04:58 |
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. | 04:59 |
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:00 |
poolie | but perhaps not that likely to happen | 05:01 |
spiv | But people do tend to customise hostnames almost always? | 05:01 |
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:02 |
spiv | If only "time at boot" was a portably available feature ;) | 05:03 |
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:05 |
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:06 |
spiv | Ok, time to go grab a pie, bbiab. | 05:07 |
poolie | :) enjoy | 05:07 |
spiv | poolie: https://code.launchpad.net/~spiv/bzr/doc-stacking-constraints/+merge/63640 | 07:16 |
poolie | thanks! | 07:18 |
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:20 |
poolie | ok, replied | 07:21 |
poolie | and rebooting again | 07:21 |
vila | hi bazaaristas ! | 07:30 |
jam | morning all | 07:44 |
vila | jam: hey ! | 07:44 |
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:45 |
jam | spiv: certainly | 07:46 |
jam | another way to describe the short rule | 07:46 |
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:47 |
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:48 |
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. | 07:49 |
poolie | hello jam, vila | 08:02 |
vila | _o/ | 08:02 |
vila | Does anybody know the fullname of Geoff/xaav ? | 08:19 |
spiv | vila: see the committer in the bzr revisions | 08:24 |
spiv | Well, it's closer anyway :) | 08:24 |
vila | hmm, I was wondering if it was a nickname or his true fullname :-/ | 08:25 |
vila | I'd settle with Geoff/xaav in the news entry, if he disagrees we can fix it later | 08:26 |
=== jml` is now known as jml | ||
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 | 08:59 |
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:00 |
spiv | jam: just briefly before I go | 09:01 |
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:02 |
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:03 |
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:04 |
spiv | G'night folks | 09:05 |
vila | spiv: g'night | 09:05 |
=== hunger_ is now known as hunger | ||
strycore | Hi | 12:21 |
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:22 |
fullermd | You could look at the bookmarks plugin. | 12:25 |
fullermd | Or create a symlink in your homedir and use /~/myproject/ | 12:26 |
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:27 |
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:28 |
bigjools | then I did a bunch of conflict resolution, not realising, and now I have to re-do all that work :( | 12:29 |
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:30 |
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:31 |
maxb | bigjools: So, you just want to have merged one less revision than you actually did? | 12:32 |
bigjools | maxb: pretty much, yeah | 12:33 |
maxb | I'd probably do something like this | 12:33 |
maxb | 1. Uncommit the merge | 12:33 |
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:34 |
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:35 | |
vila | 9. Check that merge --preview <that branch with the unwanted revision> is what you expect | 12:36 |
bigjools | right, I'll bash that in, thanks for the help! | 12:38 |
vila | bigjools: you'll need bash-dwim for 7 :-/ | 12:39 |
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:40 |
vila | That's what I meant... :) | 12:43 |
bigjools | I just snapped my fingers and it all worked like magic | 12:44 |
* vila sends black helicopters to capture fingers | 12:46 | |
jam | jelmer: it looks like your add-by-delta patch broke the case-insensitive code for windows. | 13:10 |
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:11 |
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:12 |
vila | jam: fuzzy memory, but I think there are multiple tests failing with .pack files involved, some failures may be transient ? | 13:14 |
jam | vila: I'll see if I can provoke it | 13:15 |
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:16 |
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:17 |
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:18 |
jam | some are modestly sized | 13:19 |
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:20 |
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:22 |
strycore | thanks fullermd and spiv :) | 13:40 |
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? | 13:53 |
jam | jelmer: sure. I think the lp stuff is most important for now | 14:37 |
maxb | jubany Request: ./requeue_package.py python-unit python-werkzeug language-pack-az language-pack-gnome-uz # Transient failures | 15:21 |
=== maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failure ratchet: 482 | ||
maxb | (+1 for the mysterious cpuarrayd import, which isn't actually a problem since the package does not exist in Ubuntu or Debian) | 15:22 |
james_w | maxb, done | 15:27 |
maxb | thanks | 15:27 |
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:28 |
maxb | Though apparently it temporarily existed at some point | 15:29 |
maxb | Or perhaps someone did requeue --force on a bogus name? | 15:29 |
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:30 |
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:31 |
jimi_hendrix | lp:~snova/+junk/lyx | 15:32 |
jimi_hendrix | maxb, ^ | 15:36 |
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 | 15:41 |
jimi_hendrix | maxb, going from the command line works | 16:07 |
jimi_hendrix | dont know what was up | 16:07 |
vila | jimi_hendrix: unsupported protocol for 'lp:' strongly hints at plugin disabling | 16:30 |
=== deryck is now known as deryck[lunch] | ||
=== deryck[lunch] is now known as deryck | ||
jam | vila: if he is using bazaar explorer, he probably has plugins enabled, but maybe unselected "Launchpad" from being installed. | 18:31 |
vila | jam: but he said the command-line was working... | 18:32 |
jam | I missed that part. Definitely strange | 18:32 |
* gour notices that someone descended from the heaven here | 19:26 | |
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:38 |
james_w | arnetheduck, http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/lastCompletedBuild/testReport/ only sees two failures currently | 19:56 |
james_w | arnetheduck, so I would say yes | 19:57 |
james_w | as a bug I mean | 19:57 |
arnetheduck | james_w, I'm testing a fairly recent lp:bzr with no compiled extensions - maybe that makes a difference? | 20:22 |
=== jimi__hendrix is now known as jimi_hendrix | ||
james_w | arnetheduck, I'm not sure | 20:26 |
james_w | the no compiled extensions thing may be involved | 20:26 |
=== yofel_ is now known as yofel | ||
=== jelmer is now known as Guest3391 | ||
=== medberry is now known as med_out | ||
poolie | hi all | 23:03 |
mgz | hey poolie. | 23:23 |
poolie | hi mgz | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!