[00:03] spiv: Yeah, trying to clear out my inbox generally has good results for others :) [00:13] abentley: BB doesn't seem to be noticing my reviews, nor is it giving me the automatic :approve for patches from me? Can you tell why? [00:14] jam: The mail queue is pretty deep: http://bundlebuggy.aaronbentley.com/mail [00:14] ah, ok [00:14] I guess me landing 5 patches in bzr.dev doesn't help [00:14] According to your earlier comments [00:14] yeah. [00:15] abentley: also, some of them are pretty old: Tue Jul 15 04:50:37 2008 [00:15] That is about 2 days? [00:15] ah, maybe that is 'frozen' [00:16] The ones in the 'frozen' list will not be processed without my intervention. [00:18] Jelmers bb:approve messages on the bzr-gtk list today are also not coming through [00:30] jam: I've tweaked the branch scanner to run set membership tests to find out whether a request was merged, as you suggested. Much faster! [00:43] is there a way to configure bzr to say something like "warning: you are about to push with uncommitted changes" [00:44] FallenPegasus, not at the moment afaik [00:44] if you think that is a useful feature, please file a bug [00:46] jelmer: Any idea how to fix that push PushResult problem? [00:48] colbrac, this appears to be a bug in bzr itself [00:48] colbrac, I see one implementation of pull() that doesn't return a PullResult [00:48] while the API clearly states that it should === abentley1 is now known as abentley [00:49] doh.. [00:50] Sorry, my bad - it's actually inside of a try so I missed it === mw is now known as mw|out [00:51] I'm not quite sure what causes it then [00:52] though it seems like a bad idea to work around unexpected behaviour while it's unknown what's causing that unexpected behaviour [00:54] Which one of those BrzBranch#'s in bzrlib/branch.py is used you think? [00:55] LP page of the branch says format 6.. so I'd assume BzrBranch6 :P [00:57] hum.. I give up.. way too much abstractions for this time of night [01:03] colbrac, shouldn't be too hard to figure out if you use pdb [01:04] jelmer: you mean, after I learn to use pdb? :) [01:04] (-: [01:04] jelmer: That will be for another day. The dialogs took more time than I expected already. [01:05] colbrac, k [01:05] colbrac, thanks for those changes, btw. I'm really happy to see that happen [01:05] jelmer: The main window GUI will be more like removing a bandaid though... :o) [01:06] jelmer: One quick big pull [01:06] changing way too many lines in __init__ [01:07] jelmer: But I'll wait till I have some comments on the changes I made to the locationbar location and the Bookmarks appearance [01:08] ok [01:12] jelmer: One more thing before I go: There were some approved merges on the vernstok BB that are not in the new BB. Will you merge them or must they first be resend to this BB? [01:17] colbrac, please resend them [01:18] jelmer: Tomorrow.. or like.. after some sleep :o) G'night all [01:18] :-) [01:18] weltrusten [03:14] Hmmm. [03:15] * igc lunch [03:16] On Ubuntu with the PPA 1.6b3, bzrbashprompt.sh is running and making my shell slow, even though I'm not using it. [03:27] Peng: It seems the debian system auto installs everything in contrib/bash to /etc/bash....d/ [03:27] you can rm the one file [03:27] and I think the packaging is going to be updated. [03:27] If I rm it, it will be reinstalled next time I upgrade bzr, right? [03:28] I replaced it with an empty file. All is right in the world now. :) [03:38] Peng: well, the next bzr version should *not* install that file anymore. [03:38] We didn't intend it to be installed, but didn't realize the installer said "install contrib/bash/*" [03:38] which used to just install a path-completion stuff [03:48] jam: Ah. [04:10] I'm getting the feeling that instead of using the CVS $Id:$ trick I have to do something like bzr version-info --python and check it in - am I getting warm? [04:10] this doesn't look very happy: http://pastebin.ubuntu.com/28180/ :( [04:12] bzr log --short over the hpss is broken? [04:28] Is it possible to add an option to a builtin command from a plugin? [04:29] I want to fix Bug 241889 [04:29] Launchpad bug 241889 in qbzr "show merge --preview in qdiff window?" [Undecided,New] https://launchpad.net/bugs/241889 [04:29] bzr merge --qpreview [04:31] GaryvdM: yes [04:31] unfortunately i don't really know the best way how... [04:32] Do you know of some where else that it has been done? [04:34] https://bugs.edge.launchpad.net/bzr/+bug/249690 [04:34] Launchpad bug 249690 in bzr "bzr log --short broken over hpss" [Undecided,New] [04:34] GaryvdM: xmloutput (0.4 series) adds --xml option to status, etc. It's not the best way to do it, but it seems to work ok. [04:35] GaryvdM: i did this once: http://pastebin.ubuntu.com/28183/ [04:35] Ok - that would work === sm_ is now known as sm [05:01] Thanks mwhudson. I was able to do it. [05:01] GaryvdM: cool === jamesh_ is now known as jamesh [06:28] poolie: I've encountered an issue with the stacking stuff. [06:28] poolie: can I call you about it? [06:34] * spiv ducks out for an hour [06:39] poolie: ping [06:49] jml, sure [06:49] lifeless: pong [06:51] i fall off irc and everyone wants me :) [06:51] we always want you poolie [06:52] GrantBow: yes [06:52] poolie: skype or pots? [06:53] poolie: we have about 50 tshirts left; how do you feel about us giving them out at LRL [06:53] lifeless: go crazy [06:53] thanks [06:55] erm wtf http://bazaar-vcs.org/ZoomQuiet [06:55] it doesn't seem quite spam [06:55] but its surely not topical [06:56] poolie: also, any feedback on the RFC: review support and partial commits would be nice [06:56] (doesn't have to be deep feedback) [06:57] ZoomQuiet is also doing japanese translations of bzr wiki pages. *blink* [06:57] jml, let me reply to vila first [06:57] poolie: ok [07:23] jml, call me? pots? [07:23] poolie: sure. [07:30] jelmer (and others): hello, i have strange segfault error on bzr-svn and i cant figure out why it comes. (li. 675 in ra.c seems to be problematic for me (where the segfault seems to appen). But i run in a special env. (all underlying libraries are compiled with prefix) and i want t be sure that it is not the env rather than bzr which is in fault. How can i debug efficiently that ? With gdb (then how?) [07:31] jelmer: what i want to do is just "import pdb;pdb.set_trace()", C way [07:36] jelmer: http://www.friendpaste.com/xjJTVvNv i get that as a start, must go out to work, seeya. [08:10] kiorky: hi, jelmer will be around in an hour or two; its early morning here in the UK [08:22] lifeless: one hour less from me :p (france) [08:49] /B 29 [08:59] lifeless: ping [08:59] lifeless: do stacking branches still actually require supports_external_lookups in the repository? [08:59] i'm guessing yes, so that check knows it's ok for them to have outward-pointing references? [08:59] poolie: yes [09:00] so to make stacking a non-development feature, we need a non-development repository format too === jamesh_ is now known as jamesh [09:00] with that set [09:15] poolie: yes, branch and repo format both [09:16] you can just take the development one and rename/tweak it if you want the shortest path. Ideally though you'd add another format, marked stable, and leave the devleopment one as is until 1.7 when it can be removed [09:16] poolie: did you see the rfc on review support in bzr? [09:16] Is there a reason not to pull the rich-root switch at the same time? I thought that was targetted to 1.6 originally anyway... [09:17] fullermd: aaron said to me last week there were about 2 bugs remaining [09:17] Ah. That's a good reason :) [09:18] -> checkout [09:19] lifeless: i did [09:19] when i read it last night i was a bit averse to putting it in the core [09:20] but, i guess it depends on whether you mean 'shipped with bzr' or 'getting its fingers in everywhere' [09:20] well [09:20] putting implementation aside [09:20] did it sound nice, would you use it [09:20] it seems like it would integrate in an interesting way with content filtering, doesn't it? [09:20] would it be easy to use [09:21] so 'the convenient form of this file has these extra hunks but pretend you can't see them' [09:21] it does sound pretty nice [09:21] i had a case for this just the other day with the pdb stuff in selftest [09:21] i guess i could have made it into a loom thread [09:21] i agree with you that the git index is interesting but the wrong way around imo [09:22] back after I checkout [09:44] back [09:44] poolie: so I want to preserve the 'what diff shows you is what is committed' assertion [09:45] I don't know that content transformation is a good fit with hunk marking [09:53] 'morning [09:54] Morning [09:54] I see win32 became a first-class beta citizen [09:55] A shame that configuring it to compile those extensions is such a PITA [09:57] hi awilkins [09:57] jelmer: So, bzr-svn ; my thoughts are that 1) Update is redundant, because switch also works within a branch as well as across branches ; 2) Replay is probably easier once you get the path remapping working [09:57] BUt you've probably got my mail already :-) [09:58] awilkins: replay can only be used if the server has svn >= 1.4 [09:59] jelmer: True, I wonder how many servers have not been upgraded. I think svn has been at 1.4 for some time. [10:00] jelmer: I suppose getting switch to work well and then implementing replay stops you ignoring bugs in the switch implementation :-| [10:03] awilkins: There's quite some out there [10:03] I suppose the last 1.3 release was only last June [10:04] I upgraded specifically for replay ; the bosses wanted a redundant backup server, so it mirrors to a second box using svnsync after every commit. [10:05] yeah, that's not something we can rely on unfortunately [10:05] Phhoey. Anyway, dis you test my patch? Does it produce a similar dramatic drop in bug count on Linux? [10:05] awilkins: No, that patch isn't required on Linux [10:05] I also couldn't find any indication that that was necessary in the Subversion headers [10:05] jelmer: This svn 1.5 or 1.4.6? [10:06] both [10:06] Hmm. [10:06] so I suspect there's something else going wrong [10:07] Ok, I'll shelve it and maybe we'll find something else wrong. [10:16] What is the fastest bzr repository format? rich-root-pack is deemed the smallest, but is it also the fastest? [10:16] well, gc-plain is the smallest, but its alpha today [10:17] Rebasing 3 revisions I have (3 minor patches) on top 4 newly added ones in the upstream tree takes like a few minutes [10:17] it should end up being the fastest too ;) [10:17] uws: please file bugs on performance things; generally you souldn't need to worry about formats. [10:17] lifeless: I wouldn't know what to say [10:17] uws: rich-root-pack is the best format to be using _today_ for bzr-svn branches [10:17] uws: 'I rebased and it was slow' [10:18] uws: :) - givint the branch url for what you rebased would help, and the command you ran [10:18] lifeless: I'm using bzr-svn branches indeed. pulling from svn is quite slow as well, but rebasing is bzr only right? [10:18] uws: I don't know if it is or isn't bzr only :) [10:18] the bzr-svn branch I'm using is NOT online :( [10:18] I've mirrored WebKit trunk [10:18] and launchpad doesn't have it in the vcs-mirror [10:19] uws: ah, thats ok. Just filing a bug is sufficient to start with [10:19] it took me a few days to build this branch [10:19] whee [10:19] I'll happily share it with launchpad if they want to [10:19] I can upload/bzr push, pas de probleme [10:19] uws: you could just push it to the bzr playground, or launchpad or .. [10:19] yeah, but having the "official" webkit mirror seems better [10:20] but the conversion hasn't been trivial :) [10:20] is webkit in gnome svn? [10:20] lifeless: can I push my ~1GB .bzr to launchpad? :s [10:20] lifeless: No, webkit svn [10:20] uws: sure [10:20] * AfC recalls the 2 days it took to build the initial gtk+ branch... [10:21] uws: what was the command you ran? 'bzr rebase ... ...' ? [10:21] lifeless: "bzr rebase" ;) [10:21] Hi, is there a way to convert a mercurial repository to bzr [10:21] lifeless: I'll explain my setup [10:21] repo in webkit/ [10:21] (one way for importing the code to launchpad) [10:21] the .bzr/ dir in there is ~1GB [10:21] proppy: I think there is an hg fastexport frontend [10:21] 2 branches: webkit.trunk (without tree, parent is upstream svn+http url, I use this to pull upstream) [10:21] proppy: so the bzr fastimport plugin is the best way to do a one-shot conversion [10:22] other branch is webkit.uws, which is branch of the webkit.trunk branch [10:22] I have 3 small patches in webkit.uws. when I update webkit.trunk, I run "bzr rebase" in webkit.uws to stack my own patches on top of the upstream trunk version [10:22] lifeless: ho just noticed there is also an hg convert to GNU arch [10:23] gnu arch is dead, proppy ;) [10:23] :) [10:23] googling for fastimport [10:23] For what it's worth: I ran some experiments with rebase a few weeks ago. While it "works", the form of the command line UI seems to be very different than the rest of the code bzr commands. I kept getting tripped up as to what would happen to which branch. [10:24] (and instead settled on good old `bzr merge -r X..Y` for cherry picks) [10:24] AfC: I think of "rebase" as a "shelve away all my own commits, then pull the other branch, and unshelve all my own commits" [10:24] uws: yeah, I sorta got that at the end. [10:25] I want my patches to be on top of upstream, so that I can keep then in sync (and attach to bugzilla blah blah) [10:25] uws: I think matters were complicated by the fact that I was also trying to cherry pick selected revisions at the same time. It made a loud splat noise. [10:25] uws: so, leaving aside the philosophical 'why rebase at all' discussion :) - [10:25] not sure what happens once they commit one of my patches upstream [10:25] lifeless: :) [10:25] uws: all you run is 'bzr rebase', no arguments at all ? [10:25] lifeless: (I rebase because my patches need to be on top of trunk to keep them clean for upstream submission) [10:26] uws: you don't need to rebase to achieve that :) [10:26] uws: is http://svn.webkit.org/repository/webkit/trunk the url you bzr-svn'd ? [10:26] Just merging trunk into your branch and then `bzr diff -r branch:../trunk` (?) should do it, no? [10:27] AfC: its the loom use case really, one thread per patch, serial merges [10:27] AfC: with a flatten operation at the final commit to trunk, for folk that want that [10:27] lifeless: you say so :) [10:27] lifeless: Yes, that's the url. [10:27] AfC: I do! [10:28] uws: how many files do your patches change? [10:28] lifeless: all three of them just touch 1 file (3 different files in total). [10:28] lifeless: what is bzr fastimport frontend for mercurial [10:28] all <5 line changes [10:28] front-end | bzr fast-import - [10:29] proppy: yes; http://modular.math.washington.edu/home/mhansen/fast-export/hg-fast-export.txt has some stuff about hg-fast-export [10:29] proppy: fast-export is a standard for exporting and importing between many different VCS systems [10:30] These front-ends are bundled in the exporters/ directory of bzr-fastimport. [10:30] :) [10:32] ../bzr-fastimport/exporters/hg-fast-export.py -r ../protobuf-test/ | bzr fast-import - [10:32] done thanks :) [10:32] There are two possibilities, then: either the one shipping with bzr-fastimport is tweaked and fixed, being specific to Bazaar, or the one available from [someone in the] Mercurial [community] is newer and better, being from the foreign system who perhaps know their own system better. [10:35] uws: I have filed a bug [10:36] lifeless: CC me please, uws+launchpad@xs4all.nl [10:37] lifeless: I'm currently trying to push my webkit.trunk mirror to lp:~uws/webkit-open-source/webkit.trunk [10:37] wonder whether it'll work, and how long it'll take ;) [10:37] :> [10:37] at least I'm on 100MBit for the rest of the day :) [10:38] I created the branch in launchpad using the web page, and I had to supply --use-existing-dir to bzr push [10:38] yes, I think this is ugly :) [10:39] Hmmm. "copying inventory texts 2/5" [10:49] jelmer: I might be prepared to disagree with you on this "set_path" thing ; can you show me where the API says you _don't_ have to describe the revisions of every path? [10:49] importing to lp done, thanks lifeless and AfC [10:50] jelmer: Of course, if the tests work on Linux, it's clear that something is behvaing differently ; but still, I can't find anything that says "if you don't pass any paths, it assumes that everything is revision N" [10:57] proppy: cool [11:01] uws: you are copied now [11:31] lifeless: Hm? [11:31] lifeless: ah, cc on the bug [11:31] lifeless: I'm at "copying content texts 3/5" for my webkit.trunk push ;) [11:32] but the repo is ~1GB ;) === thekorn_ is now known as thekorn [11:37] It's likely been asked a hundred times before, but... Why-oh-why do I have to give a 'push' URL the first time I push a branch..? Can it not default to the parent, the place I branched it from..? [11:38] Similar for missing/pull/update/etc... [11:38] that's not always the place you want to push to [11:39] Not always, no. I suppose I could consider various other use-cases. But every time I've ever done it, that's what I've done. I imagine that's the most likely place. [11:39] I think in most open source projects people branch over http [11:40] OK... So just apply the default to the missing/pull/update case then... [11:40] bzr branch http://foo/bar. ... wait a few days... bzr missing => "bzr missing: no URL specified" [11:40] It would be nice if it just filled that in by default... even if I had to do the push one myself [11:41] Don't forget the location aliases abentley put in for 1.6... very nice. I just wish they were documented somewhere other than NEWS. [11:41] beuno, ping [11:57] jelmer: I'm trying to test bzr-svn on Linux and it just says "Aborted" [11:58] awilkins, what version of python? [11:58] 2.5.2 [11:58] hmm, not sure then [11:58] hi jelmer [11:58] any chance you can run it inside a debugger to see what it is aborting on? [11:58] thumper: Hi [11:58] can bzr-svn import subtrees as branches? [11:58] jelmer: I'm thinking of kde [11:58] thumper: yeah [11:58] jelmer: You'd have to give me a quick pointer as to how [11:59] awilkins: "make gdb-check" should do that for you [11:59] jelmer: any idea on how it would perform with 750K revisions (kde has one big repo) [11:59] jelmer: any given subtree will only have a fraction of those [12:00] thumper, apparently it does work - some people have used it, but the building of the cache takes a long time apparently [12:00] there has been work on allowing bzr-svn to not even look at the rest of the repository [12:00] but that's not finished yet [12:00] jelmer: how long will it take? [12:00] no pressure ;-) [12:00] jelmer: My installed bzr is not compatible with bzr-svn now, should I edit the makefile to point at my bzr.dev? [12:01] thumper, Not sure, it's not one of the highest things on the list [12:01] awilkins: yeah [12:01] jelmer: where's the list? [12:01] * thumper waves the priority wand :) [12:01] thumper, It's the bugs list in lp :-) [12:01] awilkins: Or just export the BZR environment variable to point at your bzr.dev [12:02] jelmer: is the cache reusable across multiple subtree imports? [12:02] yes [12:02] ok, not so bad then [12:02] It's about 2 gig though, from what I've heard [12:02] memory or disk? [12:03] jelmer: Yup, figured that ; I'm now at a (gdb) prompt [12:03] awilkins, just run [12:03] jelmer: thanks, gotta go now [12:04] jelmer: I may well be in touch again later :) [12:04] * awilkins pines for GUI debuggers [12:04] thumper: ok [12:04] I think I may need to install some more symbols [12:04] awilkins: There's a good GTK+ based one now I think [12:04] * jelmer tries to remember the name [12:05] lots of "no debugging symbols" [12:05] LeoNerd: push is normally *not the place you branched from; at least IME [12:05] It's stopped in libc.so.6 [12:05] LeoNerd: its only the single-developer case that you *can* push back to the place you branch from [12:06] Yes, doing these things "raw" makes you a real man... I'd rather be wimp with a cyborg exo-suit than a real man naked in the desert.... [12:06] ;) [12:11] jelmer: Are you testing on x86_32 or x86_64 ? [12:11] I'm on 32bit [12:12] I'm on 64 [12:13] I'm also trying to find th right debug symbols [12:14] * awilkins installs the debug python interpreter [12:16] Well, that seemed to remove all the "no symbols" errors [12:16] Still about as clear as mud [12:16] * awilkins has been spoiled by working in environment where the debugger just shows you the code that's busted :-) [12:21] * awilkins installs insight and ddd [12:29] bug 127945 [12:29] Launchpad bug 127945 in bzr-svn "Integrate creating new branch functionality into standard push/branch" [Low,Triaged] https://launchpad.net/bugs/127945 [12:29] lifeless, ^ [12:47] jelmer: What are the chances of you merging the OliveGui? :) [12:47] colbrac, I'd like to at least wait for phanatic to comment [12:48] jelmer: Ok.. at least it stills merges without conflict to the new trunk [12:49] colbrac: The pending 'status for folders' and 'fix for broken symlink' will cause conflicts me thinks [12:50] jelmer: ^ (doh.. stop talking to myself :P) [12:53] * colbrac needs more coffee: 'fix for broken symlink' is already merged. [13:14] jelmer: Could the 'sort bookmarks by title bundle' be merged? I promise I will remove the code duplication (which is present already) after the merge of OliveGui. [13:14] re [13:14] colbrac: You're yourself also free to merge changes into trunk (if they have been approved) [13:15] wow! Didn't know that about that. So you change your stance from resubmit to approve? [13:18] colbrac: If I voted resubmit I'd like to see a new submission to the list :-) [13:18] tweak means I'm fine to see the bundle go in iff the indicated changes in my review are made (without the need for further review) [13:18] I think I would actually like to see that one resubmitted [13:20] jelmer: Did you read my reply on the list about this? I still think adding another helper function now, while the whole duplication between _load_left / refresh_left will be removed soon is not really useful. [13:27] colbrac: I guess I could live with it then [13:28] k thx :) [13:44] colbrac, any chance you can review http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/%3C20080717123155.GA14537@vernstok.nl%3E? [13:46] jelmer: Will take a look at it, but it's unknown territory for me [13:49] It's a relatively trivial change [13:51] still.. I can't even figure out how to open that 'Search revisions' dialog :P [13:51] or is it that list that opens on the history button in olive? [13:55] colbrac, you need to have bzr-search installed [13:55] and that, in turn, needs bzr.dev or one of the 1.6 betas [14:13] mvo, hi [14:35] jelmer: The dialog doesn't disappear for me :/ [14:37] jelmer: add .destroy() somewhere [14:44] Is any transport faster thatn sftp: ?? [14:46] it takes minutes do update checkout with few lines changes ... [14:48] matkor: what project? [15:03] lifeless: mine [15:03] just I have big lattency link (crowded vpn) [15:03] but it is still long time I think .. I wonder perhaps ssh+bzr: would be better choice ? [15:12] hey jelmer! you pinged me earlier? [15:13] mvo: Yeah, I was trying to find some way to retrieve "Vcs-*" fields from the apt cache using python-apt [15:14] mvo: Is it correct that that's not possible atm? [15:14] jelmer: give me a minute, I should be able to sent you a example [15:15] matkor: should be about the same usually; however latency hurts :( [15:21] jelmer: you are right, its currently not accessable because there is no way to access the full record. let me add it to the python-apt source [15:21] mvo, Cool [15:25] jelmer: I can put a new version into my ppa, do you need hardy or intrepid debs? [15:25] mvo: I'm actually on sid but I guess hardy is most useful for me at this point :-) [15:27] colbrac, are you sure you meant resubmit rather than tweak? [15:28] :) hum, yeah you are right.. I trust you can handle this without further review :o) [15:36] mvo, where is the main python-apt branch? [15:37] jelmer: my development tree is at http://people.ubuntu.com/~mvo/bzr/python-apt/mvo/ [15:37] I installed bzr 1.6b3 from the bzr-beta ppa but now I seem to have a bzr prompt as soon as I start a gnome-terminal for every folder I enter :/ [15:39] that's a nice *feature* people :P [15:39] colbrac: I _believe_ that's an issue with the packaging. Look in /etc/bash.d, perhaps. [15:39] jelmer: I have a pbuilder sid environemnet here, I can build you a package if that is more convenient [15:40] ubottu: paste [15:40] jelmer: I added a "Record" attribute to the PkgSrcRecord that gives you the full record [15:40] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [15:40] thanks to etckeeper I know it's done in /etc/bash_completion.d/bzrbashprompt.sh [15:40] mvo: Thanks [15:41] ja1: I'm getting http://paste.ubuntu.com/28287/ when I attempt to send you mail. [15:41] mvo: A sid package would be quite nice if it's not too much trouble :-) === ja1 is now known as jam [15:42] Odd_Bloke: odd.. can you try sending directly to john@mail.arbash-meinel.com? [15:42] Love to put that in traceback ... ugh [15:42] anyway [15:42] try it [15:44] Odd_Bloke: I know I have a greylist which requires messages to be re-sent the first time they come through [15:44] but 550 doesn't look like the right error for that. [15:44] mvo: nevermind, bzr builddeb also seems happy with your branch [15:44] jam: I got http://paste.ubuntu.com/28288/ in my logs when I sent the email to john@mail.arbash-meinel.com. [15:46] jam: Though it's deferred (rather than bounced as previously) so I may have just hit the greylist for that. [15:47] Odd_Bloke: sounds like. [15:47] You can send again in a couple minutes [15:47] or just wait for it to retransmit [15:48] jam: I'll wait. :) The initial error seems weird though. [15:49] yeah the 550 you were getting seems bad [15:49] I know I have a private mail server, and domainpeople just relay it to me [15:49] as a backup [15:54] mvo, The Vcs-Bzr fields still appears to be missing [15:55] mvo:while it does contain other fields such as Maintainer and Homepage [15:56] mvo, e.g. Cache()["bzr"].installedRecord["Maintainer"] works but Cache()["bzr"].installedRecord["Vcs-Bzr"] doesn't [16:01] hi, is there any tutorial on how to write a plugin/hook? both user reference and user guide doesn't contain many information. they both say "look at the builtins.py". having a tutorial would be great [16:04] TejasPP: I think you just volunteered to write one? ;) [16:04] jelmer: right, the vcs-bzr information is only available in the source package record, that is slightly more work to extract [16:04] first I should figure it out! :D [16:05] exactly! :) That's what I did before I added info about giving back for bzr-gtk on the bzr wiki [16:06] jelmer: http://paste.ubuntu.com/28291/ is a example, its rather primitive compared to the interface that works with binary packages [16:11] so, there is no documentation on this other than user guide/reference and writingplugins page [16:11] mvo, Ah, my bad [16:11] jelmer: If I was going to try to move some import statements to the top of files in bzr-gtk and I find licence-less py files (like window.py), should I add a licence? [16:11] mvo, Thanks, that seems to work [16:11] mvo, that returns the data from the latest known version? [16:12] since Lookup() seems to return only a single object, rather than multiple [16:13] jelmer: its a bad interface, you can run Lookup() multiple times and it will return multiple records (it will return false when there are no records left) [16:13] jelmer: /usr/share/doc/python-apt/examples/sources.py is a example [16:14] jelmer: on how to use it (this code predates my involvement with the project :) [16:14] mvo: Heh, ok [16:14] mvo, Thanks [16:15] cheers! let me know if you need anything else [16:16] I'm fine for now... "bzr branch deb:" seems to work [16:16] ooooooo [16:17] do you know any example plugin which is well commented and easy to understand? or which functions I should look in builtins.py [16:19]