[00:19] ping losa [00:20] losa: nvm === Leonidas_ is now known as Leonidas [09:53] if i do cat-revision which format is that? serialized? [10:23] Well, of course it's serialized. That doesn't really say anything; it's like saying "it's bytes" ;p [10:23] 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:26] fullermd: i'm not a python expert, so i can't say what this format is [10:27] Well, I'm not a python anything. I can still read and guess, though. [10:27] that's why i asked, to seek help, not to get flamed [10:27] i can do guessing too [10:27] but guessing does not help [10:28] 'course it does. [10:28] inventory-sha140:ddc195c05e78e0713a61f2b046a5a27d4f8b8b87el7 [10:28] el7? [10:30] 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] fullermd: i got so far [10:30] but i'm stuck with el7 [10:31] and #bzr is really the worst place to seek help [10:31] Well, every value looks liek it ends with el, and that somenum looks like the length of the following key. [10:31] there is el eel ll ee … [10:31] or d [10:39] knittl: you're probably seeing bencode [10:40] knittl: but cat-revision is really just a debugging tool [10:40] knittl: the format of the output depends on the format of the repo [10:40] spiv: bittorrent encode? [10:40] knittl: e.g. on earlier formats you'd get XML [10:41] knittl: right [10:41] ok, so it's not even serialized it's really the revision as stored byte for byte? [10:41] It's the text of the record in the 'revision' store [10:41] ok great. thanks :) [10:42] What a user calls a 'revision' has a bit more in it than that :) [10:42] You can say that it's some sort of serialization of a Revision object. [10:43] ok. bencode helps a lot already [10:43] Out of interest, why are you looking at cat-revision? Just poking around? [10:43] more or less poking around [10:44] 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] spiv: no, i'm not using it to write scripts [10:44] i'm really only interested in the data and the format [10:46] 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:47] The four stores, or "versionedfiles" as the code tends to call them, are 'revisions', 'inventories', 'texts' and 'signatures'. [10:48] i think i already figured that out [10:48] (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] also testament being a stripped version of a revision [10:48] Well, the testament is a serialization of a revision suitable for signing. [10:49] yes [10:49] i.e. even if the repository format changes, the testament won't. [10:49] actually there are already 3 different testament versions ;P [10:49] Well, ok, yes :) [10:50] The actual details of how these high-level things are stored as bytes and files on disk in .bzr/ is somewhat complex. [10:50] \\\ [10:50] I have vague memories that one of the testament formats was actually just made for some bundle format or other. [10:50] so to verify a signature the text of the testament has to be parsed [10:51] To see if it matches the data you have in your repo, right. [10:51] i have a patch lying around [10:51] 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] but it's not parsing yet [10:51] only looking if the testament text is contained in the signature [10:52] fullermd: i'm talking about printing the signature and verifying the testament which is signed by it [10:52] it only stores the text of the testament [10:52] so the signed message has to be parsed [10:55] 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:56] yes [10:56] but still needs to be parsed (textwise) [10:56] 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] the signature is of the hash of the testament [10:56] you don't need to parse that [10:56] you just generate a new testament and hash that [10:57] * spiv -> dinner [10:57] signature is: begin signed message------hash sha1 "testament text"----begin signature----end signed message [10:57] https://code.launchpad.net/~knittl/bzr/show-signature [10:58] https://code.launchpad.net/~knittl/bzr/cat-signature (new name) [11:00] but i don't have time for that now though [11:18] spiv: when you are back from dinner: where can i find the code for 'text' objects? [11:25] 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:27] my first thought is to search for a file called text*.py [11:27] but i guess there are multiple files [11:27] weave, knitpack, etc. [11:40] knittl: versionedfiles.py, groupcompress.py [11:40] spiv: thanks a lot :) [11:40] knittl: you could perhaps try drilling down from bzrlib/repofmt/groupcompress.py [11:40] Which implements the current repo format. [11:40] But it'll be a tough dig, there are many layers of abstraction... [11:40] like everywhere in bzr? ^^ [11:41] * fullermd carefully remains mute :) [11:41] 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:42] i'll look into versionedfile first [11:42] i guess there are properties which are common between different formats? [11:42] But obviously the storage has various smarts about compression and deltas. [11:43] Yeah, it's mostly been evolution not revolution with formats. [11:43] Some evolutionary steps are bigger than others, of course ;) [11:43] ok, afk now – dinner [11:44] spiv: helps a lot already, spiv [11:44] 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:45] Because if that file hasn't changed in that revision it won't get a new texts record. [11:46] 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] (or use a high-enough level API that does all that for you ;) [11:48] At some point I'd love to make a document describing all the most important abstractions, and their gotchas and subtleties... [11:48] 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:49] And writing that should take only slightly less time than it takes to obsolete it 8-} [11:50] There's also the "but I could be spending this time fixing bugs" problem. [12:19] 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:22] That's an error from curl about verifying the SSL cert on launchpad. [12:22] 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:23] Er, SSL to launchpad.net, that is. [12:23] spiv: Okay, thanks. How can I get past this? [12:23] A workaround would be to uninstall python-pycurl [12:23] (on debian/ubuntu) [12:24] Right, ubuntu it is. Thanks, I'll give it a go! [12:24] Then bzr will fallback to Python's builtin HTTPS stuff, which doesn't try that validation. [12:24] Or, install more ca-certs ;) [12:24] * spiv -> zzz [12:26] spiv: Thanks, that worked. I'll look into installing LP's cert though, that's somehow better in my view. :) G'night! [13:11] astraljava: yup, Ubuntu not carrying lp cert is a bug, which version ? [13:16] 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] 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:17] ping losa [13:27] 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] Should i file a bug and attach a patch, or do something with merge requests? [13:38] vila: Gotcha, thanks! [13:39] Glenjamin: merge request is the way to go, it's best when there is an existing bug though [13:40] Glenjamin: bialix and GaryVDM are the best to answer about qbzr and bzr-explorer [13:48] bah, i've found another pending merge request that doesn't have a bug which does roughly the same thing [13:48] although that branch does a bunch of other stuff too [13:50] presumably there's bugmail for these things, and I shouldn't be poking people? [13:58] 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:59] Glenjamin: and, generally, smaller proposals are easier to review/test/land [16:53] Hi [16:53] 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)? [17:02] Or more useful, is there some way to uncommit the last changes to recover a revision which is now X.Y.Z? [17:03] 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] You could use push --overwrite to move the branch head back to whatever rev you wanted. [17:06] 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] 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:07] You can `bzr branch -rX.Y.Z trunk bugfix-release-branch` and go from there. [17:09] fullermd: Oh, that even works. Thanks! === 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/ [18:28] 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:30] atdhvaannkcse ?! [18:31] concurrency bug [18:31] maxb: Thanks. What's the URI for sftp? [18:32] 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] So, 'sshfs bazaar.launchpad.net:~foo/bar/baz /tmp/mountpoint' [18:32] And then write 'append_revisions_only = True' in .bzr/branch/branch.conf [18:53] maxb: thanks in advance with, as dash said, some concurrency bug ;-) [18:53] maxb: wow, you really don't care about bandwith nor latency do you ? bzr+ssh should be better than sftp for lp [18:54] maxb: Ha, no, only for accessing branch.conf, sry, missed the beginning [18:54] * vila off === 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 [21:11] Can I mark multiple LP bugs fixed by the same commit? [21:25] yes [21:27] how? [21:28] Also, how do I clear pending merge tips? [21:28] specify --fixes multiple times, iirc [21:29] bzr revert --forget-merges [21:31] assuming you only want to clear the merge metadata, not also revert the tree === Ursinha is now known as Ursinha-afk [23:47] mkanat: around? questions about lp comments in the mozilla buzilla in #launchpad-dev if you are