[00:19] <vila> ping losa
[00:20] <vila> losa: nvm
[09:53] <knittl> if i do cat-revision which format is that? serialized?
[10:23] <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:26] <knittl> fullermd: i'm not a python expert, so i can't say what this format is
[10:27] <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:28] <fullermd> 'course it does.
[10:28] <fullermd> inventory-sha140:ddc195c05e78e0713a61f2b046a5a27d4f8b8b87el7
[10:28] <knittl> el7?
[10:30] <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:31] <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:39] <spiv> knittl: you're probably seeing bencode
[10:40] <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:41] <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:42] <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:43] <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:44] <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:46] <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:47] <spiv> The four stores, or "versionedfiles" as the code tends to call them, are 'revisions', 'inventories', 'texts' and 'signatures'.
[10:48] <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:49] <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:50] <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:51] <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:52] <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:55] <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:56] <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:57]  * 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:58] <knittl> https://code.launchpad.net/~knittl/bzr/cat-signature (new name)
[11:00] <knittl> but i don't have time for that now though
[11:18] <knittl> spiv: when you are back from dinner: where can i find the code for 'text' objects?
[11:25] <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:27] <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:40] <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:41]  * 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:42] <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:43] <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:44] <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:45] <spiv> Because if that file hasn't changed in that revision it won't get a new texts record.
[11:46] <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:48] <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:49] <fullermd> And writing that should take only slightly less time than it takes to obsolete it   8-}
[11:50] <spiv> There's also the "but I could be spending this time fixing bugs" problem.
[12:19] <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:22] <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:23] <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:24] <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:26] <astraljava> spiv: Thanks, that worked. I'll look into installing LP's cert though, that's somehow better in my view. :) G'night!
[13:11] <vila> astraljava: yup, Ubuntu not carrying lp cert is a bug, which version ?
[13:16] <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:17] <vila> ping losa
[13:27] <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:38] <astraljava> vila: Gotcha, thanks!
[13:39] <vila> Glenjamin: merge request is the way to go, it's best when there is an existing bug though
[13:40] <vila> Glenjamin: bialix and GaryVDM are the best to answer about qbzr and bzr-explorer
[13:48] <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:50] <Glenjamin> presumably there's bugmail for these things, and I shouldn't be poking people?
[13:58] <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:59] <vila> Glenjamin: and, generally, smaller proposals are easier to review/test/land
[16:53] <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)?
[17:02] <RainCT> Or more useful, is there some way to uncommit the last changes to recover a revision which is now X.Y.Z?
[17:03] <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:06] <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:07] <fullermd> You can `bzr branch -rX.Y.Z trunk bugfix-release-branch` and go from there.
[17:09] <RainCT> fullermd: Oh, that even works. Thanks!
[18:28] <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:30] <maxb> atdhvaannkcse ?!
[18:31] <dash> concurrency bug
[18:31] <RainCT> maxb: Thanks. What's the URI for sftp?
[18:32] <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:53] <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:54] <vila> maxb: Ha, no, only for accessing branch.conf, sry, missed the beginning
[18:54]  * vila off
[21:11] <lucidfox> Can I mark multiple LP bugs fixed by the same commit?
[21:25] <lifeless> yes
[21:27] <lucidfox> how?
[21:28] <lucidfox> Also, how do I clear pending merge tips?
[21:28] <maxb> specify --fixes multiple times, iirc
[21:29] <maxb> bzr revert --forget-merges
[21:31] <maxb> assuming you only want to clear the merge metadata, not also revert the tree
[23:47] <lifeless> mkanat: around? questions about lp comments in the mozilla buzilla in #launchpad-dev if you are