| vila | ping losa | 00:19 |
|---|---|---|
| vila | losa: nvm | 00:20 |
| === Leonidas_ is now known as Leonidas | ||
| knittl | if i do cat-revision which format is that? serialized? | 09:53 |
| fullermd | Well, of course it's serialized. That doesn't really say anything; it's like saying "it's bytes" ;p | 10:23 |
| fullermd | Looks like an arbitrary length-specified k:v serialization to me. But I don't know any more than you would by looking at it. | 10:23 |
| knittl | fullermd: i'm not a python expert, so i can't say what this format is | 10:26 |
| fullermd | Well, I'm not a python anything. I can still read and guess, though. | 10:27 |
| knittl | that's why i asked, to seek help, not to get flamed | 10:27 |
| knittl | i can do guessing too | 10:27 |
| knittl | but guessing does not help | 10:27 |
| fullermd | 'course it does. | 10:28 |
| fullermd | inventory-sha140:ddc195c05e78e0713a61f2b046a5a27d4f8b8b87el7 | 10:28 |
| knittl | el7? | 10:28 |
| fullermd | Now, it could be that that's actually a unique spelling of Estruscan. Or, the most obvious interpretation could hold, and since a SHA1 is 40 chars, somebody along the line would have to be pretty dumb for that to mean anything but "field 'inventory-sha1' is 40 chars, the content of which is 'ddc19...'" | 10:30 |
| knittl | fullermd: i got so far | 10:30 |
| knittl | but i'm stuck with el7 | 10:30 |
| knittl | and #bzr is really the worst place to seek help | 10:31 |
| fullermd | Well, every value looks liek it ends with el<somenum>, and that somenum looks like the length of the following key. | 10:31 |
| knittl | there is el eel ll ee … | 10:31 |
| knittl | or d | 10:31 |
| spiv | knittl: you're probably seeing bencode | 10:39 |
| spiv | knittl: but cat-revision is really just a debugging tool | 10:40 |
| spiv | knittl: the format of the output depends on the format of the repo | 10:40 |
| knittl | spiv: bittorrent encode? | 10:40 |
| spiv | knittl: e.g. on earlier formats you'd get XML | 10:40 |
| spiv | knittl: right | 10:41 |
| knittl | ok, so it's not even serialized it's really the revision as stored byte for byte? | 10:41 |
| spiv | It's the text of the record in the 'revision' store | 10:41 |
| knittl | ok great. thanks :) | 10:41 |
| spiv | What a user calls a 'revision' has a bit more in it than that :) | 10:42 |
| spiv | You can say that it's some sort of serialization of a Revision object. | 10:42 |
| knittl | ok. bencode helps a lot already | 10:43 |
| spiv | Out of interest, why are you looking at cat-revision? Just poking around? | 10:43 |
| knittl | more or less poking around | 10:43 |
| spiv | Good :) So I won't feel obliged to stress how much cat-revision is not an interface to be building on top of ;) | 10:44 |
| knittl | spiv: no, i'm not using it to write scripts | 10:44 |
| knittl | i'm really only interested in the data and the format | 10:44 |
| spiv | At a moderately high level, the data model is that there are revisions (which have a unique ID). Revisions have an inventory (which often, but not always, shares that ID), and inventories describe what's in the tree and refer to the exact file texts. | 10:46 |
| spiv | The four stores, or "versionedfiles" as the code tends to call them, are 'revisions', 'inventories', 'texts' and 'signatures'. | 10:47 |
| knittl | i think i already figured that out | 10:48 |
| spiv | (A revision's signature will have the same ID as the revision, but obviously will be found in the signatures store, rather than the revisions store. Also, a revision does not need to have a signature, it's optional.) | 10:48 |
| knittl | also testament being a stripped version of a revision | 10:48 |
| spiv | Well, the testament is a serialization of a revision suitable for signing. | 10:48 |
| knittl | yes | 10:49 |
| spiv | i.e. even if the repository format changes, the testament won't. | 10:49 |
| knittl | actually there are already 3 different testament versions ;P | 10:49 |
| spiv | Well, ok, yes :) | 10:49 |
| spiv | The actual details of how these high-level things are stored as bytes and files on disk in .bzr/ is somewhat complex. | 10:50 |
| spiv | \\\ | 10:50 |
| fullermd | I have vague memories that one of the testament formats was actually just made for some bundle format or other. | 10:50 |
| knittl | so to verify a signature the text of the testament has to be parsed | 10:50 |
| spiv | To see if it matches the data you have in your repo, right. | 10:51 |
| knittl | i have a patch lying around | 10:51 |
| fullermd | I don't think that happens by parsing the testament, though. Rather, from just using the data bits the testament was generated from. | 10:51 |
| knittl | but it's not parsing yet | 10:51 |
| knittl | only looking if the testament text is contained in the signature | 10:51 |
| knittl | fullermd: i'm talking about printing the signature and verifying the testament which is signed by it | 10:52 |
| knittl | it only stores the text of the testament | 10:52 |
| knittl | so the signed message has to be parsed | 10:52 |
| spiv | The signed message is very simple, though. It's basically "I am testament for revision-id blah, the SHA-1 of the long testament is blah", IIRC. | 10:55 |
| knittl | yes | 10:56 |
| knittl | but still needs to be parsed (textwise) | 10:56 |
| fullermd | I would assume that the stored signature doesn't actually include the testament text, that the validation process actually goes "Generate a testament for the given rev from the information I have, then check if the signature matches it" | 10:56 |
| lifeless | the signature is of the hash of the testament | 10:56 |
| lifeless | you don't need to parse that | 10:56 |
| lifeless | you just generate a new testament and hash that | 10:56 |
| * spiv -> dinner | 10:57 | |
| knittl | signature is: begin signed message------hash sha1 "testament text"----begin signature----end signed message | 10:57 |
| knittl | https://code.launchpad.net/~knittl/bzr/show-signature | 10:57 |
| knittl | https://code.launchpad.net/~knittl/bzr/cat-signature (new name) | 10:58 |
| knittl | but i don't have time for that now though | 11:00 |
| knittl | spiv: when you are back from dinner: where can i find the code for 'text' objects? | 11:18 |
| fullermd | You could try tracing down from the 'cat' command, since that winds up giving you the text for a particular file at a particular rev. Would be my first thought of how to find it. | 11:25 |
| knittl | my first thought is to search for a file called text*.py | 11:27 |
| knittl | but i guess there are multiple files | 11:27 |
| knittl | weave, knitpack, etc. | 11:27 |
| spiv | knittl: versionedfiles.py, groupcompress.py | 11:40 |
| knittl | spiv: thanks a lot :) | 11:40 |
| spiv | knittl: you could perhaps try drilling down from bzrlib/repofmt/groupcompress.py | 11:40 |
| spiv | Which implements the current repo format. | 11:40 |
| spiv | But it'll be a tough dig, there are many layers of abstraction... | 11:40 |
| knittl | like everywhere in bzr? ^^ | 11:40 |
| * fullermd carefully remains mute :) | 11:41 | |
| spiv | At a high level the API is essentially just "these are the bytes of (file-id, rev-id)", "please give me the bytes of (file-id, rev-id)". | 11:41 |
| knittl | i'll look into versionedfile first | 11:42 |
| knittl | i guess there are properties which are common between different formats? | 11:42 |
| spiv | But obviously the storage has various smarts about compression and deltas. | 11:42 |
| spiv | Yeah, it's mostly been evolution not revolution with formats. | 11:43 |
| spiv | Some evolutionary steps are bigger than others, of course ;) | 11:43 |
| knittl | ok, afk now – dinner | 11:43 |
| knittl | spiv: helps a lot already, spiv | 11:44 |
| spiv | And, even in that high-level view, you ought to be aware that just because rev X contains a file of id F that doesn't imply that (F, X) exists in the texts store. | 11:44 |
| spiv | Because if that file hasn't changed in that revision it won't get a new texts record. | 11:45 |
| spiv | So to find the contents of a file in a particular revision, you need to ask the revision for its inventory, ask the inventory for the (file-id, rev-id) to use, and then ask the texts store to extract that for you. | 11:46 |
| spiv | (or use a high-enough level API that does all that for you ;) | 11:46 |
| spiv | At some point I'd love to make a document describing all the most important abstractions, and their gotchas and subtleties... | 11:48 |
| spiv | The really low level bits are fairly well described in various places already, if you already understand where they fit into the big picture. | 11:48 |
| fullermd | And writing that should take only slightly less time than it takes to obsolete it 8-} | 11:49 |
| spiv | There's also the "but I could be spending this time fixing bugs" problem. | 11:50 |
| astraljava | Hi there, anyone know why `bzr lp-login user' fails with http://paste.ubuntu.com/495833/, while `ssh -v user@bazaar.launchpad.net' says login succeeded. | 12:19 |
| fullermd | That's an error from curl about verifying the SSL cert on launchpad. | 12:22 |
| spiv | astraljava: lp-login first fetches something via HTTPS, but your system's libcurl doesn't have whatever certificate authority cert is needed to validate SSL. | 12:22 |
| spiv | Er, SSL to launchpad.net, that is. | 12:23 |
| astraljava | spiv: Okay, thanks. How can I get past this? | 12:23 |
| spiv | A workaround would be to uninstall python-pycurl | 12:23 |
| spiv | (on debian/ubuntu) | 12:23 |
| astraljava | Right, ubuntu it is. Thanks, I'll give it a go! | 12:24 |
| spiv | Then bzr will fallback to Python's builtin HTTPS stuff, which doesn't try that validation. | 12:24 |
| spiv | Or, install more ca-certs ;) | 12:24 |
| * spiv -> zzz | 12:24 | |
| astraljava | spiv: Thanks, that worked. I'll look into installing LP's cert though, that's somehow better in my view. :) G'night! | 12:26 |
| vila | astraljava: yup, Ubuntu not carrying lp cert is a bug, which version ? | 13:11 |
| vila | astraljava: bzr not allowing you to disable cert verification is another ;-) More or less related to bug #82086 which you can subscribe too or just mention you're affected by | 13:16 |
| ubot5` | Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/82086 | 13:16 |
| vila | ping losa | 13:17 |
| Glenjamin | i've got a branch that adds --ignore-whitespace to qdiff, could anyone point me to how i'd go about getting that into trunk? | 13:27 |
| Glenjamin | Should i file a bug and attach a patch, or do something with merge requests? | 13:27 |
| astraljava | vila: Gotcha, thanks! | 13:38 |
| vila | Glenjamin: merge request is the way to go, it's best when there is an existing bug though | 13:39 |
| vila | Glenjamin: bialix and GaryVDM are the best to answer about qbzr and bzr-explorer | 13:40 |
| Glenjamin | bah, i've found another pending merge request that doesn't have a bug which does roughly the same thing | 13:48 |
| Glenjamin | although that branch does a bunch of other stuff too | 13:48 |
| Glenjamin | presumably there's bugmail for these things, and I shouldn't be poking people? | 13:50 |
| vila | Glenjamin: I can't speak for qbzr, I don't propose a lot of mps there :-/ But surely they'll receive mails when you create a new one or add a comment there | 13:58 |
| vila | Glenjamin: and, generally, smaller proposals are easier to review/test/land | 13:59 |
| RainCT | Hi | 16:53 |
| RainCT | Is there some way so that if I have lp:foo Launchpad won't allow merging lp:foo into another branch and pushing that branch to lp:foo (but instead require the other branch be merged into lp:foo)? | 16:53 |
| RainCT | Or more useful, is there some way to uncommit the last changes to recover a revision which is now X.Y.Z? | 17:02 |
| fullermd | If you could get append_revisions_only set on the branch, it would refuse changes that change the existing revnos. Not sure there's a clean way to do that to a branch on LP though. | 17:03 |
| fullermd | You could use push --overwrite to move the branch head back to whatever rev you wanted. | 17:03 |
| RainCT | fullermd: The later question is about doing it in local when I don't have the original branch. (The problem I have is I want to fork out the code of a stable release to work on a bugfix-only release, but it's got lost in the middle of a big merge). | 17:06 |
| fullermd | Well, you can make a new branch starting from any rev you want; it doesn't have to be the current head, or on the mainline. | 17:06 |
| fullermd | You can `bzr branch -rX.Y.Z trunk bugfix-release-branch` and go from there. | 17:07 |
| RainCT | fullermd: Oh, that even works. Thanks! | 17:09 |
| === vila 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 | Release Manager: vila | bzr 2.2.0 is officially out| bzr-2.0.6, 2.1.3 and 2.2.1 need installers, atdhvaannkcse ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| maxb | RainCT: If you want to enable append_revisions_only on a Launchpad branch, you can do it via the bzrlib API, or you can edit the branch.conf over sftp | 18:28 |
| maxb | atdhvaannkcse ?! | 18:30 |
| dash | concurrency bug | 18:31 |
| RainCT | maxb: Thanks. What's the URI for sftp? | 18:31 |
| maxb | RainCT: Usually I use sshfs to mount the branch via fuse (because I've yet to find a sftp client that provides a better experience) | 18:32 |
| maxb | So, 'sshfs bazaar.launchpad.net:~foo/bar/baz /tmp/mountpoint' | 18:32 |
| maxb | And then write 'append_revisions_only = True' in .bzr/branch/branch.conf | 18:32 |
| vila | maxb: thanks in advance with, as dash said, some concurrency bug ;-) | 18:53 |
| vila | maxb: wow, you really don't care about bandwith nor latency do you ? bzr+ssh should be better than sftp for lp | 18:53 |
| vila | maxb: Ha, no, only for accessing branch.conf, sry, missed the beginning | 18:54 |
| * vila off | 18:54 | |
| === Ursinha-afk is now known as Jorjao | ||
| === Jorjao is now known as Ursinha | ||
| === Vorpal is now known as Vorpal_ | ||
| === Vorpal_ is now known as Vorpal | ||
| === Vorpal is now known as Vorpal_ | ||
| === Vorpal_ is now known as Vorpal | ||
| lucidfox | Can I mark multiple LP bugs fixed by the same commit? | 21:11 |
| lifeless | yes | 21:25 |
| lucidfox | how? | 21:27 |
| lucidfox | Also, how do I clear pending merge tips? | 21:28 |
| maxb | specify --fixes multiple times, iirc | 21:28 |
| maxb | bzr revert --forget-merges | 21:29 |
| maxb | assuming you only want to clear the merge metadata, not also revert the tree | 21:31 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | mkanat: around? questions about lp comments in the mozilla buzilla in #launchpad-dev if you are | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!