| spiv | Good morning. | 01:06 |
|---|---|---|
| poolie | jelmer: hi? | 02:17 |
| poolie | spiv, hi | 02:17 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| bendj | I've setup bzr on a box that's behind a fairly tight firewall. I thought bzr+ssh:// just needs port22 access -- apparently not sufficient. Are the required ports doc'd somewhere? I'm digging, not finding :-/ | 04:36 |
| mwhudson | bendj: it should just require 22 | 04:36 |
| bendj | mwhudson: Hm. getting, "ssh: connect to host bazaar.launchpad.net port 22: Connection timed out. bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. " | 04:38 |
| bendj | 'normal ssh' from the box works fine. | 04:40 |
| bendj | gremlins. sigh ... | 04:41 |
| mwhudson | bendj: can you run 'ssh bazaar.launchpad.net' from the command line? | 04:41 |
| bendj | mwhudson: I get "No shells on this server. Connection to bazaar.launchpad.net closed." | 04:42 |
| mwhudson | ok that's good | 04:42 |
| mwhudson | bendj: if you look in the ~/.bzr.log file i think you'll see the command line bzr is launching ssh wiht | 04:43 |
| mwhudson | *with | 04:43 |
| mwhudson | maybe there's something obviously funny in there | 04:43 |
| bendj | mwhudson: hm. that's full of non-ascii garbage. not good. uninstall/rebuild/reinstall, i s'pose? | 04:45 |
| mwhudson | bendj: what platform/bzr version? | 04:46 |
| mwhudson | bendj: maybe just delete .bzr.log to start with | 04:46 |
| bendj | opensuse 11.3, x86_64, Bazaar (bzr) 2.3.0dev1 (r5361) | 04:47 |
| bendj | mwhudson: hey, deleting the log file wokred! | 04:47 |
| bendj | er, worked | 04:47 |
| bendj | 1st time i've seen that :-| | 04:48 |
| mwhudson | odd | 04:48 |
| bendj | thx! | 04:48 |
| bendj | tt4n | 04:50 |
| mtaylor | is there anyway to tell where the bzr twisted impl of ssh is going to look for ssh keys? | 05:28 |
| * mtaylor is battling a windows machine at the moment | 05:28 | |
| poolie | mtaylor: i think it prefers to look in the putty agent "pageant" if that's installed | 05:31 |
| poolie | i don't know of a way to say "what directory are you looking in" beyond boking into the source | 05:32 |
| mtaylor | poolie: nevermind actually - the wiki saved me | 05:32 |
| mtaylor | poolie: http://wiki.bazaar.canonical.com/Bzr_and_SSH ... it llooks in %USERPROFILE% apparently | 05:33 |
| spiv | mtaylor: actually, bzr doesn't use a Twisted client for SSH, I think that's a paramiko bug (it logs the server's name as the client's) | 05:40 |
| mtaylor | spiv: hehe | 05:40 |
| spiv | I guess because paramiko uses the same class for the client and server, but didn't parameterise that bit of the logging... | 05:41 |
| spiv | (I just filed a bug on paramiko about it.) | 05:55 |
| cwr | hi | 07:35 |
| lokkju | .join #dorkbotpdx | 07:35 |
| lokkju | oops | 07:35 |
| cwr | i created a new user and tried to push a new revision to a existing branch. unfortunately i get this error | 07:40 |
| cwr | http://pastebin.org/444166 | 07:40 |
| cwr | creating a new branch on the server is no problem, so the new user has write permissions | 07:41 |
| fullermd | Having permissions to write a new branch doesn't mean they have write permissions in the existing branch. | 07:42 |
| cwr | was it the wrong to just commit the changes? do i have to do something like merge? | 07:42 |
| cwr | fullermd: how can I give a user permissions to write to an existing branch? | 07:46 |
| * fullermd shrugs. | 07:46 | |
| fullermd | chmod as appropriate. | 07:47 |
| fullermd | As a first approximation, whatever perms are up a level that let the user create a new branch. | 07:48 |
| * spiv is done for the day | 08:17 | |
| knittl | what data model uses bzr to store history? i.e. how is history recorded, and _what_ is recorded? | 10:00 |
| knittl | git uses commit/tree/blob, mercurial uses revlogs (changelog, manifest, filelog) | 10:01 |
| LeoNerd | I'm not sure the question makes much sense... | 10:01 |
| LeoNerd | bzr has its own names for these things, yes... but that doesn't really help answer the question | 10:02 |
| knittl | LeoNerd: i wasn't able to find documentation for this in bzr terms | 10:02 |
| knittl | and git and hg were just given to have examples, it's not easy to describe what i want | 10:02 |
| LeoNerd | bzr branches contain revisions... if that answers your question? | 10:04 |
| ddaa | you want a description of the models and datastructure used in the current achive format? | 10:04 |
| knittl | no, it doesn't | 10:04 |
| knittl | ddaa: yes! | 10:04 |
| ddaa | I'm not familiar enough to give a good answer, but I know it would be pretty long. | 10:04 |
| knittl | i take pointers to documentation | 10:05 |
| ddaa | First, unlike git, and probably hg, bzr has a layered design. | 10:05 |
| knittl | but i wasn't able to find proper docs | 10:05 |
| knittl | not even in bzr.bzr/docs/developers/… | 10:05 |
| ddaa | There's a model layer, that deals with trees, branches, repositories, revisions, bzrdir, file revisions, etc. | 10:05 |
| knittl | i'm interested in how revisions go together with trees and files | 10:06 |
| ddaa | and there are various transport/storage layers that translate that into actual storage/protocols | 10:06 |
| ddaa | those involve things like indexes, packs, weaves, etc. | 10:06 |
| ddaa | Then there is the tree format, with things like dirstate. | 10:06 |
| ddaa | all those things are pretty much orthogonal | 10:07 |
| ddaa | and most have multiple implementations | 10:07 |
| ddaa | mostly historical | 10:07 |
| knittl | let me try explain what i want :D | 10:08 |
| knittl | if i do bzr commit (locally) | 10:08 |
| ddaa | knitti, on the model level, a revision has some commit information, and an inventory | 10:08 |
| knittl | inventory = tree? | 10:08 |
| ddaa | an inventory is a tree-like model that maps file ids to names, parent ids, and file revisons. | 10:09 |
| knittl | but i'm really wondering why there is no documentation? | 10:09 |
| ddaa | (and probably a number of other metadata) | 10:09 |
| knittl | where/how are files stored? | 10:09 |
| ddaa | The repository is a model that (among other things) store file contents addressed by file revision ids. | 10:10 |
| ddaa | (other things include commit/revisions, inventories, and metadata such as tags) | 10:10 |
| knittl | why is there no documentation? | 10:10 |
| ddaa | probably because nobody has bothered to write it. | 10:11 |
| ddaa | Also, the source code is relatively well document. | 10:11 |
| ddaa | documented | 10:11 |
| bialix | there is documentation on repository storage format | 10:11 |
| bialix | when packs was introduced | 10:11 |
| knittl | bialix: where? | 10:11 |
| ddaa | bialix: I think he's more interested in the API model than in a specific storage format. | 10:11 |
| bialix | in docs/developers/ | 10:12 |
| ddaa | the latter is not going to help much without the former, anyway. | 10:12 |
| bialix | ah | 10:12 |
| knittl | ddaa: no, i'm not interested in api | 10:12 |
| bialix | then, there is no docs because all devs have this knowledge implanted in their brains? | 10:13 |
| knittl | bialix: yes, it seems so | 10:13 |
| ddaa | well, if you are interested in "the bzr storage format", know that there are number of them, and it's subject to change. | 10:13 |
| ddaa | why would you want to access the on-disk storage format w/o bzrlib anyway? | 10:14 |
| ddaa | That's an actual question. | 10:14 |
| bialix | I would like to | 10:14 |
| knittl | i know bzr changes format quite often, but i'm only interested in the current implementation/format | 10:14 |
| bialix | 2a? | 10:14 |
| lifeless | knittl: it doesn't change much at all | 10:14 |
| knittl | and i don't want to access it, i am comparing various dvcss | 10:14 |
| knittl | write about advantages/disadvantages | 10:15 |
| ddaa | lifeless knows everything | 10:15 |
| bialix | heh | 10:15 |
| lifeless | knittl: the formats are documented in bzrlib.repofmts.* | 10:15 |
| knittl | and that includes describing on-disk storage format and relations between different types of objects | 10:15 |
| lifeless | knittl: yes and no | 10:15 |
| lifeless | relations are covered by the model stuff ddaa spoke about | 10:15 |
| bialix | knittl: and what it will say? | 10:15 |
| lifeless | on disk format for individual things is determined by the classes the repo format uses - e.g. btree vs a linear index vs no index | 10:16 |
| lifeless | what you are asking is kind of like asking 'what is the drizzle disk format' | 10:16 |
| lifeless | where the answer is 'well, it depends. What plugin are you using?' | 10:16 |
| lifeless | (or the mysql, or the postgresql, or oracle etc) | 10:17 |
| knittl | let my try again … | 10:17 |
| * ddaa gestures over at the svn repository format | 10:17 | |
| knittl | git hashes every object | 10:17 |
| knittl | commit points to tree, tree points to trees and blobs | 10:17 |
| knittl | every object is stored in .git/objects/xx/xxxxx… | 10:18 |
| lifeless | well you were right up to the last point | 10:18 |
| ddaa | knitti wants to know how the bzr2 repository stores commits and trees, specifically | 10:18 |
| lifeless | when you become wrong. | 10:18 |
| knittl | where xx/xxxxx… is the sha1 | 10:18 |
| knittl | hg has changelog, manifest and filelog (all a form of revlog) | 10:18 |
| lifeless | you're conflating different layers | 10:19 |
| knittl | revlog stores sha1, 2 parents, length, base revision for delta and finally id of changeset (quasi a backreference) | 10:19 |
| knittl | so there's: 1 changelog, 1 manifest and for each file a filelog. in .hg/store/data/$filename | 10:20 |
| ddaa | he's not really interested in all the nice layering in bzrlib, just in the current storage strategy | 10:20 |
| lifeless | git has an object model and a storage model; the object model uses hashes as keys and has commit, tree and blob object types (and more these days). The storage model can have loose objects or packed objects, and they are indexed either by fs path or by a page based index. | 10:20 |
| knittl | is it really so much i'm asking for or am i being uncleaar what i actually want? | 10:21 |
| lifeless | ddaa: I can see that, but he is confusing him self by analysing two wholly independent layers as one. So when we answer either question, we get told we're answering the wrong thing. | 10:21 |
| knittl | lifeless: i'm more interested in the object model (references between types) | 10:21 |
| knittl | but storage is also important. and storage models change often in bzr | 10:21 |
| lifeless | knittl: bzr object model has commit -> inventory -> blobs | 10:22 |
| knittl | weave, knitpack, etc. | 10:22 |
| lifeless | knittl: and commit -> signature | 10:22 |
| bialix | knittl: maybe this helps: http://doc.bazaar.canonical.com/bzr.2.1/developers/packrepo.html#technical-notes | 10:22 |
| lifeless | knittl: this is documented in the developer docs in the very entry point under 'basic concepts' or something like that. | 10:22 |
| knittl | lifeless: i've read that page | 10:23 |
| knittl | what i took from it so far: knitpack is superior to older formats | 10:23 |
| lifeless | knittl: I think you're answering bialix | 10:23 |
| knittl | hm? | 10:24 |
| lifeless | http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html - 'core concepts' | 10:24 |
| lifeless | bah, 'core classes' | 10:24 |
| knittl | i think i can only understand on-disk after i've fully understood object model | 10:24 |
| knittl | core classes are workingtree/branch/repository? | 10:25 |
| knittl | where's commit? where are blobs? | 10:25 |
| lifeless | yeah, there is less there than I thought :) its handwaved at under repository | 10:25 |
| lifeless | sorry | 10:25 |
| bialix | knittl: there is no "blobs" in your understanding | 10:26 |
| bialix | you're using wrong terms | 10:26 |
| knittl | bialix: 11:24 < lifeless> knittl: bzr object model has commit -> inventory -> blobs | 10:26 |
| bialix | okay, but we call them differently | 10:26 |
| bialix | commit is revision object | 10:26 |
| bialix | blobs are file objects | 10:27 |
| bialix | something like that | 10:27 |
| knittl | (also there is a formatting issue on that page: the list under repository) | 10:27 |
| knittl | bialix: ok, revision. i use git a lot, so i'm used to the term 'commit' | 10:27 |
| knittl | and storage and object model go hand in hand. at least in hg and git | 10:30 |
| knittl | *grin* | 10:30 |
| bialix | it depends how you're looking at things | 10:32 |
| lifeless | knittl: they don't go that hand in hand | 10:33 |
| lifeless | knittl: google have a bigtable implementation of hg, which has _very little_ to do with the revlog implementation in the public code, from what I hear. | 10:33 |
| lifeless | and git has multiple storage engines too (loose vs packed) | 10:33 |
| knittl | but somewhat | 10:35 |
| knittl | so, how are revision objects, inventory objects and file objects in bzr linked together? | 10:35 |
| bialix | with references, of course | 10:36 |
| knittl | and they reference what? revnos? hashes? | 10:36 |
| bialix | [12:26]<knittl>bialix: 11:24 < lifeless> knittl: bzr object model has commit -> inventory -> blobs | 10:36 |
| bialix | GUID | 10:36 |
| knittl | bialix: yep. but how? | 10:36 |
| knittl | guid. good | 10:36 |
| knittl | what's that signature object you talked about earlier? | 10:37 |
| bialix | signature? I guess you're asking about revision signature. This is gpg signature for revision object | 10:39 |
| bialix | something similar exists in git too | 10:40 |
| spiv | A signature's ID is the ID of the revision it is a signature of. | 10:40 |
| * bialix bbl | 10:41 | |
| knittl | but that would mean signature -> revision | 10:50 |
| knittl | ? | 10:50 |
| spiv | What does the "->" denote, precisely? | 10:51 |
| spiv | That a signature references a particular revision via the revision ID? Yes. | 10:51 |
| knittl | spiv: yes | 10:52 |
| knittl | the example/explanation i was given before was »and revision -> signature« | 10:52 |
| knittl | which made no sense for gpg signatures | 10:52 |
| spiv | Well, if you have a revision, you can use it's ID to lookup the signature. | 10:53 |
| spiv | (And perhaps find that there is no signature for that revision) | 10:53 |
| spiv | s/it's/its/ | 10:53 |
| spiv | So, in that sense, "revision -> signature" is also correct. | 10:54 |
| knittl | but revision has no pointer to signature id | 11:01 |
| spiv | It has exactly as much as a pointer as signature has to revision. | 11:02 |
| ddaa | kind of, a revision has a revision id. This one is not strictly a reference, it's an association. Like two relational tables with matching primary keys. | 11:03 |
| knittl | revision id is stored with signature | 11:04 |
| knittl | and signature can be looked up if revid is given | 11:04 |
| knittl | but revision does _not_ store the id of the signature | 11:04 |
| ddaa | yes it does, the id of the signature in the revid | 11:04 |
| spiv | Let's say you have a revision ID 'xyz'. You can retrieve the revision record from the repository's revisions store with the key 'xyz'. You can also retrieve the corresponding signature from the repository's signatures store with the key 'xyz'. | 11:04 |
| ddaa | s/in/is/ | 11:04 |
| spiv | That is to say, having the revision ID means you have the signature's ID (and vice versa). | 11:05 |
| spiv | If you like, you can represent the keyspace for bzr's internal storage as tuples that look like (store_name, key_part_1 [, key_part_2, ...]) | 11:06 |
| knittl | revid and signature id are the same? | 11:06 |
| ddaa | yes they are | 11:06 |
| ddaa | different namespaces, I guess | 11:07 |
| knittl | ok | 11:07 |
| spiv | In that unified keyspace that revision's key would be ('revisions', 'xyz') and the signature's key would be ('signatures', 'xyz'). | 11:07 |
| spiv | Obviously it is trivial to determine one from the other. | 11:08 |
| knittl | that means forging signatures is possible? | 11:08 |
| spiv | No. | 11:08 |
| knittl | or is this prevented somehow? | 11:08 |
| ddaa | signatures are GPG signatures | 11:08 |
| spiv | The ID of the signature is not the content of the signature. | 11:08 |
| knittl | spiv: yes | 11:09 |
| knittl | so how can i verify the gpg-signature is the original? | 11:09 |
| ddaa | what do you mean by original? | 11:09 |
| knittl | i create a new revision | 11:09 |
| knittl | i sign it | 11:10 |
| spiv | You have a revision. You have a signature. You can determine with GPG if that signature is a valid signature for the revision, and you can then decide how much you trust the signer. | 11:10 |
| ddaa | spiv thank you | 11:10 |
| ddaa | knitti, then I sign it too | 11:10 |
| knittl | ok, trusting the signer. thanks spiv, makes sense | 11:10 |
| knittl | ddaa: why do you always write knitti with an i? xD | 11:10 |
| ddaa | knittl:because my typing skills are better than my eyesight. | 11:11 |
| ddaa | knittl: you need to be a bit familiar with how gpg is used for this stuff to make sense. The GPG notion of "trust" is a bit peculiar. | 11:12 |
| knittl | ddaa: i understand now | 11:17 |
| knittl | i was only a bit confused | 11:17 |
| knittl | public key is tricksy stuff ;) | 11:19 |
| jelmer | poolie: pong | 11:30 |
| bialix | spiv: ping, if you still around | 11:49 |
| bialix | spiv: question about smart server aka `bzr serve`. | 11:49 |
| * bialix waves at GaryvdM | 11:50 | |
| GaryvdM | Hi bialix. | 11:50 |
| bialix | GaryvdM: thanks for bzrw | 11:51 |
| GaryvdM | \o/ | 11:51 |
| bialix | \o/ | 11:51 |
| spiv | bialix: slightly around | 11:57 |
| bialix | spiv: bzr serve uses port 4155 (IIRC). when client connects to this port server creates separate thread for this client, is it correct? | 11:58 |
| bialix | if that correct does server creates new socket pair for particular client? or this is wrong question? | 11:59 |
| bialix | I mean it won't be possible to another client re-use the previous connection and server states | 12:00 |
| spiv | The server creates a new thread, yes. | 12:01 |
| spiv | The server doesn't create a socket pair, it just calls accept on the listening socket, and that returns the socket object for the new connection. | 12:02 |
| spiv | (See the Python docs for socket.listen and the accept() method of socket objects) | 12:02 |
| spiv | Er, actually, they are both methods of socket objects, but you know what I meant I'm sure :) | 12:03 |
| bialix | ok | 12:05 |
| bialix | spiv: what is state of VFS calls? | 12:06 |
| spiv | bialix: no recent changes. They are still used by many common operations. | 12:20 |
| bialix | ok, I wonder is it possible to create new hpss protocol version via plugin to address Bug #126911 | 12:21 |
| ubot5 | Launchpad bug 126911 in Bazaar "Smart server has no built in authentication (affected: 2, heat: 34)" [Medium,Confirmed] https://launchpad.net/bugs/126911 | 12:21 |
| bialix | at least as experiment | 12:21 |
| spiv | I'm not spending much time on improving that at the moment. I occasionally fix one more case, but there's still lots to do... | 12:21 |
| spiv | I think that would be possible. | 12:22 |
| bialix | it should be fixed at client side first? | 12:22 |
| spiv | The VFS calls? | 12:22 |
| bialix | yes | 12:22 |
| spiv | Well, most remaining cases need a new verb to fix, so both sides. | 12:22 |
| bialix | verb are not documented? | 12:23 |
| spiv | The SmartServerRequest subclasses have docstrings. | 12:23 |
| bialix | I found network-protocol.txt and it has some gaps about requests and errors with XXX contributions welcome | 12:24 |
| spiv | And the complete list of verbs (and what classes are used to implement them) can be seen at the bottom of bzrlib/smart/request.py | 12:24 |
| bialix | ok | 12:24 |
| spiv | Contributions certainly are welcome! :) | 12:24 |
| spiv | Currently for anything not in that document the code is the best (and only) reference. | 12:24 |
| bialix | I may try to add this to docs as part of my learning of hpss | 12:25 |
| bialix | yes, that's right | 12:25 |
| spiv | That would be lovely, thanks! | 12:25 |
| bialix | request_handlers.register_lazy( | 12:26 |
| bialix | 'Branch.set_tags_bytes', 'bzrlib.smart.branch', | 12:26 |
| bialix | 'SmartServerBranchSetTagsBytes') | 12:26 |
| bialix | what is the verb here? the first? | 12:26 |
| lifeless | yes | 12:27 |
| bialix | so idea is to have verb similar to python expression used to do the work on local objects? | 12:28 |
| bialix | and IIUC things like request_handlers.register_lazy('list_dir', 'bzrlib.smart.vfs', 'ListDirRequest') are VFS calls | 12:29 |
| spiv | Yes, the VFS verbs are the ones implemented in bzrlib.smart.vfs | 12:48 |
| hrw | hi | 12:48 |
| hrw | how to revert changeset in bzr? with git I would do "git revert REVISION" but how in bzr? | 12:48 |
| spiv | And we do try to keep the network API matching the Python one where possible, unless there's a good reason not to. | 12:49 |
| spiv | hrw: merge the reverse of the revision, and commit that | 12:50 |
| spiv | "bzr help revert" mentions the recipe: 'For example, "merge . --revision -2..-3" will remove the changes introduced by -2' | 12:50 |
| spiv | (-2 is the notation for "2nd most recent commit") | 12:51 |
| hrw | spiv: like in cvs then | 12:51 |
| spiv | See also "bzr uncommit". | 12:51 |
| hrw | I want to remove HEAD~3 so uncommit is not a solution | 12:52 |
| hrw | will export patch, revert it etc | 12:52 |
| spiv | You don't need to export a patch. | 12:52 |
| spiv | Simply do "bzr merge . -r -3..-4 && bzr commit" | 12:53 |
| spiv | (Exporting a patch has basically the same effect, except it isn't as good at undoing deletes or changes to binary files) | 12:54 |
| spiv | (Or at undoing renames of directories...) | 12:55 |
| hrw | thx | 12:56 |
| spiv | Huh, I think I just found a cheap way to shrink the size of inventory file instances by about 20%. | 13:23 |
| === Ursinha-afk is now known as Ursinha | ||
| bialix | GaryvdM: ping | 14:03 |
| GaryvdM | bialix: Pong | 14:25 |
| bialix | GaryvdM: I need your expertise on http://groups.google.com/group/qbzr/browse_thread/thread/af4d21e4f6cd2a79 (last mnessage) | 14:26 |
| bialix | GaryvdM: and we need tree name for 0.19 final, something related to meerkats maybe | 14:27 |
| GaryvdM | bialix: Looks good. | 14:28 |
| bialix | okay, I will land it | 14:28 |
| bialix | GaryvdM: I've decided to prepare 0.18.7, to get me in the qbzr-dev mindset | 14:29 |
| rubbs | I'm getting this crash when trying to clone a git repo on github with bzr-git. http://pastebin.com/DMXFS1ds | 14:59 |
| rubbs | I'm using the ppa stable version for lucid if that makes a difference | 14:59 |
| rubbs | I can just download the source, the history isn't really that important. | 15:00 |
| jelmer | rubbs: Hi | 15:01 |
| jelmer | rubbs: This is a known issue, fixed in newer versions of bzr-git | 15:01 |
| jelmer | rubbs: What PPA are you using? I don't think there is one... | 15:01 |
| rubbs | jelmer: sorry didn't know it was fixed. I just have the bzr ppa, I guess I for some reason thought bzr-git was packaged in that, but now that I think about it, it doesn't make sense | 15:02 |
| rubbs | I installed bzr-git with aptitude | 15:02 |
| rubbs | I'll do a manual install with the newest git. | 15:02 |
| jelmer | rubbs: You probably want to add this PPA that packags the latest bzr-git: | 15:03 |
| rubbs | jelmer: awesome will do thanks. | 15:03 |
| jelmer | https://edge.launchpad.net/~mathiaz/+archive/bzr-git | 15:04 |
| jelmer | (well, not recent but recent enough) | 15:04 |
| rubbs | jelmer: that worked perfectly thank you. I guess I should have googled before bothering you ;) | 15:10 |
| jelmer | rubbs, no worries. we should proball | 15:20 |
| jelmer | ly upload this newer version to lucid as well, but I haven't found time to do that yet. | 15:20 |
| rubbs | understandable. I'm only barely starting to get some free time left. I am hoping to get back into helping the bzr-doc team again. I've been busy with a new job so I've had to cut back a little. | 15:21 |
| === deryck is now known as deryck[lunch] | ||
| BjornT_ | i get a traceback when running 'bzr status': http://paste.ubuntu.com/472713/ | 17:11 |
| BjornT_ | any idea of what's wrong? | 17:11 |
| === beuno is now known as beuno-lunch | ||
| BjornT_ | on a related note, why is the latest upload to the bzr-nightly ppa two months old, and the latest beta isn't in the bzr-beta ppa? | 17:17 |
| BjornT_ | james_w: ^^^ | 17:17 |
| maxb | They've not been very well maintained | 17:24 |
| maxb | Maybe I should volunteer | 17:25 |
| maxb | I'm already managing PPAs of svn and mercurial :-) | 17:25 |
| BjornT_ | maxb: that would be excellent :) | 17:25 |
| maxb | and tortoisehg | 17:25 |
| maxb | Then I'd just need git to complete the set | 17:25 |
| maxb | I wonder how many people actually care about bzr-nightly - wouldn't you just run bzr from a branch? | 17:27 |
| BjornT_ | maxb: well, it's quite handy letting apt handle the updating, and being able to easily revert back to older released versions, if needed. | 17:30 |
| BjornT_ | maxb: also, not having to bother about building it properly is also a plus (considering 'make' just failed to build the C extensions :) ) | 17:33 |
| maxb | heh | 17:33 |
| BjornT_ | https://bugs.edge.launchpad.net/bzr/+bug/613066 | 17:39 |
| ubot5 | Launchpad bug 613066 in Bazaar "IndexError when running bzr status (affected: 1, heat: 6)" [Undecided,New] | 17:39 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| === beuno-lunch is now known as beuno | ||
| === andreaa is now known as andreaa`afk | ||
| === khmarbaise_ is now known as khmarbaise | ||
| Ursinha | jam, hi | 23:01 |
| jam | hi Ursinha | 23:03 |
| Ursinha | jam, I just submitted the mp for the bzr-pqm changes: https://code.edge.launchpad.net/~ursinha/bzr-pqm/add-noqa-incr-lpland/+merge/31703 | 23:03 |
| jam | Ursinha: I see it, and it showed up for review normally (though there are 2 review requests) | 23:04 |
| Ursinha | jam, ah, please, ignore the first one, trigger happy here and I submitted before I should | 23:05 |
| maxb | Anyone else using bzr 2.2 and finding it has a regression in clearing progress messages from the terminal? | 23:12 |
| === Ursinha is now known as Ursinha-brb | ||
| mgz | bug 611127 | 23:17 |
| ubot5 | Launchpad bug 611127 in Bazaar "progress bar does not clear correctly (affected: 2, heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/611127 | 23:17 |
| maxb | ah :-/ | 23:19 |
| === andreaa`afk is now known as andreaa | ||
| poolie | hi mgz, maxb | 23:51 |
| === Ursinha-brb is now known as Ursinha-afk | ||
| mgz | hey poolie. just getting back to working out what breaks with python 2.7 | 23:53 |
| mrjazzcat | poolie: hey Martin. Hope all is well with you. Is there a trick to getting companies behind a proxied firewall to speak lp: (bzr to LP)?? | 23:56 |
| mrjazzcat | poolie: if it's documented, you could point me there. Still haven't found it | 23:57 |
| lifeless | mrjazzcat: http_proxy and https_proxy both need to be set, and you need bzr 2.2 | 23:58 |
| lifeless | mrjazzcat: also, if you're logged in, you need port 22 - ssh - open | 23:58 |
| mrjazzcat | hey lifeless: thanks. I'll go mess with that. Yes, I was thinking it should go through ssh. Thank you! | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!