=== Ursinha is now known as Ursinha-afk [04:00] has anyone implemented du that works over a transport? [04:58] mwhudson: repository info used to, I think. It was terrible. [04:59] ah yes, i think you're right [04:59] * mwhudson tries to remember why he asked [07:16] hi all ! [07:19] heya vila! [07:20] spm: hey there :) [07:20] vila: nice shirt i noticed you wearing in some of the sprint photo's. something about google and to ask you instead. :-) [07:20] huh ? This got public ? OMG :-D [07:20] hahaha [07:21] I'll refrain from pointing out that you were walking around in public with that on.... [07:21] spm: for your enjoyment, you can try shuffling the words too, there are some interesting variations there :) [07:21] quite possible [07:21] possibly too even! [09:08] I've made a fatal mistake. [09:09] I've two projects on launchpad, namely listInstalledRPM and downloadRPM. I've, by mistake, pushed the trunk tree of the latter to the former. [09:09] Now I can't fall back. [09:11] MAfifi, did you do a push --overwrite? [09:11] or had you only pushed one of them [09:12] poolie: No it was just my first push to that project, so I normally used just push. [09:22] Mafifi ok so just push --overwrite what you do want to have there [09:23] poolie: Thank you, I used push --overwrite and it fortunately did exactly what I wanted. [09:23] great === oubiwann-away is now known as oubiwann === robbyoconnor is now known as ANN === ANN is now known as robbyoconnor [09:49] lifeless, I saw the bug report. ensaddening. [09:52] jml, lifeless: who is 'he' ? [09:57] hi there vila [09:58] poolie: hey [09:58] vila: fuzzyman [09:58] how are you? what fabulous adventures will you have today? [09:58] lifeless, this is your load_tests thing? [09:58] yes [09:59] he fairly casually, AFAICT, implemented a different protocol, breaking everyone using the bzr one. [09:59] ffs [09:59] rockstar: can you run the failing command again under "strace -o /tmp/strace.txt" and then send me that file? [09:59] yes, very ensaddening :( [10:00] james_w, sure, one sec. [10:00] I may be exaggeratig, I don't know the story behind the change. [10:00] anyhooo [10:01] on the -let-s-try-to-be-positive, 'pattern' can be said to be as arbitrary as 'module', in fact, I'm pretty sure both should be put in the loader letting any load_tests() function defines a new one for submodules if needed (or specialize whatever( [10:01] s/(/)/ [10:01] hmm, not sure this sed command wont bring nasty comments... [10:02] james_w, http://pastebin.ubuntu.com/466360/ [10:02] vila: like "That isn't the sed command you're looking for..."? [10:03] Meths: this comment is ok :-) [10:04] rockstar: and that run gave the same error? [10:04] james_w, yup. [10:04] rockstar: it's very odd [10:04] james_w, yes, yes it is. [10:09] poolie: I'm setting up a maverick slave to help jam/barry [10:09] in babune, running 2.7? [10:09] that sounds useful [10:10] yeah, first step is: running default python, then py2.7 [10:10] rockstar: it's looking for /home/rockstar/Projects/repos/tarmac/tarmac_0.3.2.orig.tar.gz but I think you are running the command in /home/rockstar/Projects/tarmac/packaging ? [10:10] james_w, oh man. Yeah, I've got lightweight checkouts setup. [10:10] long term, I think we want a dedicated job to track python-trunk, at least the 2.x series [10:11] rockstar: then you have found a bug sir [10:11] rockstar: please to be filing with details of your setup [10:11] james_w, indeed, and you have found a workaround for me. [10:11] that would have helped detect this load_tests() issue far sooner, may be even in time to yell when it broke testtools/bzr [10:11] james_w, thanks. [10:14] poolie: well, when I said first step, I should have said 'next' :-) There were many small steps before to setup the new VM but it went pretty smoothly. I'm not ready to automate that though :) [10:15] poolie: the nice thing is that I seem to have fixed an old bug there where some vms were failing to connect to dhcp and led to spurious failures in babune, so even less maintenance for me :D [10:20] jam, lifeless: first run on babune for maverick/py26: http://paste.ubuntu.com/466370/ [10:21] subunit faliing to parse a date ? Rings anyone bell ? [10:33] spiv, do you know anything about automatic changelog merging? [10:34] vila that looks like stderr and stdout are getting mixed together badly [10:34] or something similar [10:34] jam, https://devpad.canonical.com/~jml/no-accel-tree.gz (also -2, -3) [10:35] poolie: subunit and testtools were out-of-date, dunno exactly why... retrying [10:36] meh, this laste paste is bogus, where are my EOL gone ??? :) [10:54] poolie: bzr-builddeb registers a hook that does that, it seems to work quite well [10:54] ok, thanks [10:54] so that's one thing fixed from scottk's list [10:58] hi. is there a way i can print bazaar repository files? [10:58] hg has debug* [10:58] git has cat-file and ls-tree [10:59] bzr cat $URL ? [11:00] url? [11:00] no, i mean local repository [11:00] showing raw changelogs, indices, trees, blobs [11:00] Oh.. Poke at the internals? No... [11:00] For that, see /bin/cat ;) [11:00] yep, internals [11:00] human readable if possible [11:00] so, not really raw [11:00] cat-inventory [11:00] git ls-tree also uncompresses the files :P [11:01] cat-revision [11:01] sorry that's just 'inventory' [11:01] The internals aren't really meant for people to go prodding at [11:01] or open a python shell and poke at it [11:01] LeoNerd: but i need to :P [11:01] poolie: ok, that may help [11:01] for curiousity? [11:01] gotta go now, lunch time [11:01] poolie: no, for my bachelor's degree [11:01] i would use python [11:02] easier to script examination of ti [11:10] spiv: http://babune.ladeuil.net:24842/job/selftest-maverick/3/ any chance you can produce a maverick version of your paramiko package [11:10] ? [11:14] vila: sure [11:14] spiv: great ! I thought you were asleep :) [11:14] I wonder what happened to my merge proposal for getting that patch added to ubuntu [11:14] vila: will be soon, most likely :) [11:15] vila: https://code.edge.launchpad.net/~spiv/+recipe/paramiko-test/+build/340 [11:18] spiv: you rock ! [11:21] vila: I just pressed a button :P [11:22] vila: hmm, build failed apparently. [11:23] In some obscure (to me) way. [11:23] Possibly it's just trying to tell me that the build-deps aren't right? [11:24] Hmm, I guess I am trying to build the lucid version on maverick with that recipe, so I suppose that's not so surprising. [11:28] :-/ [11:30] I'll make a new recipe tomorrow. Hopefully I can figure out a way to use one recipe to apply the same patch to multiple distro series. [11:31] spiv: ok, thanks === Ursinha-afk is now known as Ursinha [15:24] can i delete .bzr/obsolete_packs directory safely? [15:24] the contents of it [15:24] ok [15:24] thx [15:24] pack --delete-obsolete-packs does this [15:25] i don't want to repack again ^^ [15:26] i only find a description of knit pack repositories [15:26] i know there exist several more formats [15:26] maybe not repo formats, but also branch formats [15:26] where can i find them? === mtaylor is now known as mtaylor|breakfas [15:31] and there is really no easy built-in way to have a look at bzr's internals? [15:32] use ipython [15:32] works very well [15:38] what is python? [15:40] just a python-shell? [15:42] ipython [15:42] its an interactive python shell with tab completion === deryck is now known as deryck[lunch] [15:49] docs.bazaar.canonical.com tells me to ask here :D [15:49] i don't want to write a lot of python … [15:56] what's the constant for "null:"? [15:56] revision.NULL_REVISION [15:56] or something [15:57] knittl: if you want to use bzr without writing python you can: [15:57] - use the xmlrpc server [15:57] thanks. [15:57] - use java via jython or the xmlrpc server using bindings [15:57] i prefer not writing anything [15:57] - shell script it [15:57] I don't know what you mean by that [15:57] the other dvcses all support some sort of debugprinting of repository structure [15:58] there is a repositorydetails plugin [15:58] or something-like-that [15:58] ok, i'll google it [15:59] hm no, statistics is not what i want [16:00] knittl: there is no out-of-box solution for what you want, the plugin lifeless metioned will give you the best basis to write your own, which will be warmly welcomed [16:00] vila: ok, i'll have a look [16:00] although i'm _a little_ behind schedule :D [16:00] knittl: giving a more precise explanation of what you want may help people help you find it [16:01] vila: i'm comparing different dvcs for university [16:01] and write about storage model, etc. === Adys_ is now known as Adys [16:01] mercurial has debugindex and friends [16:01] git has cat-file commit, ls-tree and cat-file blob === oubiwann is now known as oubiwann-away [16:01] bzr has nothing comparable. at least i could not find it easily [16:02] knittl: great, you know hg and git, but here people knows bzr but not this level of detail about hg and git [16:03] ppl here know bzr, so i thought i'd ask [16:03] knittl: I generally just use the Bazaar Python API [16:03] there's dump-btree, but not a complete suite of such tools I don't think [16:03] so speaking about hg/git commands is not really enliHGtning [16:03] james_w: ok, that sounds better [16:03] although it segfaults here [16:04] vila: you asked what i wanted to do, and i told you what i did in git and hg to give a comparison of what i've already done and which worked [16:04] those were just examples. i want to view the storage model and write about it [16:04] types of objects, interactions, references, compression, etc. [16:05] knittl: and I try to explain why you didn't get answers, if I failed, I'm sorry :) [16:06] vila: i can't really find good documentation on bzr's storage model [16:06] with google at least [16:06] reading source code seems like an endless adventure [16:07] but dump-btree suggests some form of binary tree [16:07] knittl: *today* it's either reading the code or asking precise questions which requires some basic knowledge [16:07] dum-btree will tell you which pack files are active for the repository [16:08] repodetails will give you more entry points and how to access them [16:08] vila: i found my question rather precise [16:08] but i'll have a look at repodetails for that matter [16:08] knittl, ipytho [16:08] run ipython [16:08] before continuing complaining ^^ [16:08] from bzrlilb.bzrdir import BzrDir [16:08] knittl: my point is to explain why it wasn't precise enough to give you the answers you're after [16:08] bd = BzrDir.open('.') [16:09] then poke around in that object and follow links [16:09] repo= bd.open_repository() [16:09] vila: let's try this way: what objects uses bzr for storage of: commits, trees, files, tags, branches? [16:10] knittl: start here: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief [16:10] ok. thanks [16:10] Well, that's not gonna tell much about storage models :p [16:10] knittl: continue there: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInLength [16:10] poolie: thanks to you too [16:10] fullermd: it will give him the right words :) [16:11] fullermd: and the entry points [16:11] I'm not going to write the doc about the bzr data model right now and here :) [16:11] knittl, if you write docs and post them to the list we can correct them [16:12] knittl: and keep in mind that bzr has used different formats with slight variations about the data model so you'd better focus on the last one: 2a [16:12] vila: yes, i know that there were different formats [16:12] but i can only find information on how to convert a repo, not about the exact differences between them [16:13] but now i'll read those wiki pages [16:13] thx [16:13] I think jam blogged about the most important points in 2a [16:14] knittl: chk maps and group compress [16:14] btw, are there any books about bzr? [16:15] the last time i looked i couldn't find a single one [16:15] knittl: There are no books yet [16:15] jelmer: ok. bad for me :( [16:21] jam: ping [16:22] knittl: Yeah, we should fix that at some point :-( [16:32] hi vila [16:39] hey jam, I thought you mentioned a ppa with a python-2.7 from barry but I can't find it [16:39] jam: I have a maverick slave setup on babune on the test suite ~passing there [16:39] vila: ppa:doko/toolchain [16:39] has maverick I believe [16:39] and one of barry's starts making python2.7 as part of 'python-defaults' [16:39] I don't really know the state [16:40] so something like [16:40] sudo add-apt-repository ppa:doko/toolchain [16:40] sudo apt-get update; sudo apt-get install python2.7 [16:41] vila: ^^ [16:41] jam: almost done [16:42] I need python-2.7-dev too I presume [16:43] jam: I fixed 2 of the 3 failures on maverick if you want to review the patch ;-) [16:44] hmm, default python is still 2.6.5+ but python2.7 is in the path [16:46] vila: right, python-defaults describes what pythons are *available* as well as which is default [16:46] the goal for maverick is 2.7 available-but-not-default [16:46] vila: already reviewed the http one [16:46] sure, I wasn't sure what the ppa was doing [16:46] 3 times [16:47] jam: cool, argh, sry for the second one then :) [16:51] jam: so, since I override BaseHTTPServer, I closely followed what was done there, specifically the atttributes are used only by this method so putting them far away... make them *less* discoverable === deryck[lunch] is now known as deryck [16:55] vila: though it doesn't conform to *our* style guide, which makes it harder for me as a bzr-hacker [16:55] (not positive what style says, but we do avoid local class members) [16:56] certainly it can be a bit tricky to recognize the ident level [16:56] jam: inherited design [16:56] jam: since we don't define the base class it's hard to follow *our* rules [16:57] I can *delete* them even if that's make you more happy [16:57] vila: it is *our* code... [16:57] vila: ultimately, I'll let you decide. [16:57] I just saw that and noticed that I find that kind of code hard to read. [16:58] jam: try the base class for fun :-/ [16:58] jam: the responses attribute is the last one defined in the class after all existing methods and attributes [17:03] gee, lp is... capricious today [17:15] vila: what's up for you? [17:16] landing the fixes and running the test suite with py27 [17:16] vila: I mean what is going wrong with lp for you [17:17] timeouts on mps [17:17] but transient ones [17:19] argh, no pyrex... [17:19] jam: what's the status across bzr/testtools regarding unittest._WritelnDecorator ? [17:27] vila: we dropped some timeouts in the lp code [17:28] vila: lifeless mentions "can you please file a bug including the OOPS info" [17:28] (from 17+s down to ~12s) [17:29] I didn't get OOPS, only 'try again later' [17:29] you're in the beta tester team, right? (edge urls not regular ones) [17:29] yup [17:29] vila: there should have been an "OOPS-XXX" string in the try-again-later page [17:29] https://lp-oops.canonical.com/oops.py/?oopsid=XXX [17:29] but if you missed it that is ok [17:29] mentioning that mp's are timing out is still useful [17:30] jam: the pages are long gone [17:30] vila: sure. Robert is pushing hard on lp performance, and trying to get that into the culture [17:30] so expect some teething [17:30] I thought the OOPS were reported to devs anyway, I didn't think I should poke especially for transient ones [17:30] vila: for future ref' please make sure there is a bug with the oops number in it. [17:30] vila: they get 100s of oops per day [17:30] robots cause oopses [17:30] unfortunately [17:30] but robots don't file bug [17:30] s [17:30] lifeless: ok [17:31] having poked at the code recently [17:31] there are quite a few bits that are doing big scans and pulling out only a row or two [17:31] which after the data is in memory, aren't that bad === beuno is now known as beuno-lunch [17:31] which are hard to push hard on [17:36] btw vila, thanks for giving me access to saw, it means I can test meliae on a 64-bit platform easily :) [17:36] jam: keep in mind I'll shut it down Thursday [17:37] vila: for good? or just for a while? [17:37] anyway, probably heading out to dinner now. Have a good evening [17:37] jam: just during my vacations :) [17:37] jam: you too ! === mtaylor|breakfas is now known as mtaylor === beuno-lunch is now known as beuno [18:23] Hi, any idea why I get - "wpad://": No host component [18:23] this is on a bzr-svn branch [18:23] and yesterday I was able to work on that branch [18:24] adiroiban: Hi [18:25] adiroiban: That's odd - can you paste a traceback? [18:25] adiroiban: is "wpad://" part of a URL you're working with? [18:25] no [18:25] the url is http://adi@svn.roiban.ro/project [18:26] On windows? [18:26] i tried bzr push http://adi@svn.roiban.ro/project [18:26] but same result [18:26] adiroiban: a backtrace would be useful - if you don't get one on the command-line -Derror should help. [18:28] http://paste.ubuntu.com/466561/ [18:29] I am now on Karmic with python 2.6 as default python version [18:32] Any proxies involved? [18:32] I am guessing that you have set a proxy in the Ubuntu settings [18:33] which gets imported into the shell variables, go [18:33] export -a |grep wpad [18:33] sorry just [18:33] export|grep wpad [18:33] jelmer: yep. [18:33] not sure who has defined that variable [18:33] if you set it in ubuntu proxy settings theres something in the gnome session thing that sets it [18:35] thanks for the help. That was the problem. Web Proxy Autodiscovery Protocol was somehow set in gnome. [18:37] makes for one hell of a confusing error though :-/ [18:37] hey jelmer, thanks for your note. [18:37] are you back home ? [18:37] hi lifeless [18:38] lifeless: yep, got back late on Sunday [18:38] cool [18:38] are you still in Europe or just jetlagged ? :-) [18:38] #launchpad-dev on this network might be worth adding to your joinlist [18:38] in prague [18:38] lifeless: I'm there actually, as rinze [18:38] why not as jelmer ? [18:39] I use two different IRC clients these days, in an attempt to keep work and private stuff separate [18:39] ah [18:39] Hi lifeless and jelmer [18:39] hi GaryvdM [18:39] How was the sprint? [18:39] 'evening Gary [18:39] GaryvdM: great [18:40] lifeless: Good to hear. [19:29] Hi mgz. [19:32] Hi, can I tell bzr to ignore *.dcu but still clear them with bzr clean-tree? [19:33] alkisg: Use bzr clean-tree --ignore ? [19:33] sorry bzr clean [19:33] sorry bzr clean-tree --ignored [19:33] Thank you GaryvdM, that looks to be what I want. === khmarbaise_ is now known as khmarbaise === Ursinha is now known as Ursinha-nom === khmarbaise_ is now known as khmarbaise [21:47] hey GaryvdM if you're still up. I'll give your 2.2b4 installer a go. [21:50] Hi everyone. I'm migrating some svn stuff to bzr using bzr-svn. I'm running into a problem with a few of my svn branches. Basically, I get an error like so: [21:50] stu@ruth:/home/stu# bzr branch http://my-svn-server.com/project-name/trunk [21:50] bzr: ERROR: The branch http://my-svn-server.com/project-name/trunk has no revision None [21:51] Anyway, I found some old bugs that seemed to match my symptoms, but they appear to have been fixed. https://bugs.launchpad.net/bzr-svn/+bug/233964 https://bugs.launchpad.net/bzr-svn/+bug/295284 https://bugs.launchpad.net/bzr-svn/+bug/364416 [21:51] Launchpad bug 233964 in Bazaar Subversion Plugin "The branch FOO has no revision None. (affected: 0, heat: 0)" [High,Fix released] [21:52] running "bzr --version" gives: [21:52] Bazaar (bzr) 2.1.1 [21:52] Python interpreter: /usr/bin/python 2.6.5 [21:52] Python standard library: /usr/lib/python2.6 [21:52] Platform: Linux-2.6.33.5-rscloud-x86_64-with-Ubuntu-10.04-lucid [21:52] bzrlib: /usr/lib/python2.6/dist-packages/bzrlib [21:52] Bazaar configuration: /root/.bazaar [21:52] Bazaar log file: /root/.bzr.log [21:52] Copyright 2005-2010 Canonical Ltd. [21:52] http://bazaar-vcs.org/ [21:52] bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and [21:52] you may use, modify and redistribute it under the terms of the GNU [21:52] General Public License version 2 or later. [21:52] Bazaar is part of the GNU Project to produce a free operating system. [21:53] Anybody else run across this? [21:56] if noone who knows bzr-svn shows up shortly, file a bug with the full traceback from .bzr.log and a link to your svn server if it's public [21:57] ok. I'm working through the 'file a bug' wizard now. [22:08] stupenrose, hi [22:08] howdy! [22:08] stupenrose: what version of bzr-svn? [22:08] lemme see... [22:09] according to 'bzr plugins': svn 1.0.2 [22:10] how are revids in bzr calculated [22:11] knittl: They're globally unique per revision [22:12] knittl: How they're generated depends on the way the commit is created [22:12] knittl: if they're native commits made by "bzr commit" they're pseudorandom (formed from email-address, timestamp and randomized string) [22:13] i downloaded a package with "bzr branch lp:ubuntu/xf86-input-wacom" , changed the package to a new upstream version and want to push th package now back to launchpad and send a merge request. how can i push the package to launchpad? [22:13] knittl: commits imported from bzr-svn for example use the branch path, repository uuid and revision number [22:13] aha. ok [22:14] so no hashing? [22:14] like 'identical' commits will give the same revid [22:14] knittl: Hashes for each revision are stored but they are not used to address the commit [22:15] only for integrity checking [22:15] (hashes are bound to a particular serialization of commits) [22:15] i see. thanks [22:46] mgz: you mentioned including the full traceback from ."bzr.log" ... I'm not seeing such a file. In my case, it fails before the branch is fully created, so there isn't really a .bzr directory. I do have an assosciated repo dir, but I don't see such a log there either. What am I missing? [22:47] Bazaar log file: /root/.bzr.log [22:48] ah, I see. thanks. [22:48] if you don't have write access to that location, set BZR_HOME to somewhere you do, and run the attempt again [22:48] though, jelmer is the right person to talk to if you can get his attention again [22:48] roger that. [22:49] jelmer: should I file a bug for this one? [22:49] stupenrose, does your repository contain any revisions created by bzr-svn? [22:51] I believe so. If you're asking whether I've pushed commits out to svn using bzr: yes. [22:53] If you're asking whether my /bzr/ repository hosts bzr-svn branches, the answer is also yes. Though, as far as that goes, I've tried branching these problem branches without using my bzr repo, and the result is the same. === verterok_ is now known as verterok [22:54] stupenrose: please file a bug [22:54] ok. will do. thank you for your help. [22:54] stupenrose: it would be useful to have the full backtrace though, that might require commenting out some code in bzrlib/builtins.py [22:55] does this look like it is full enough?: [22:55] Tue 2010-07-20 16:29:03 -0400 [22:55] 0.038 bazaar version: 2.1.1 [22:55] 0.038 bzr arguments: [u'branch', u'http://svn.cmaxdev.com/fortress/trunk', u'test1234'] [22:55] 0.044 looking for plugins in /root/.bazaar/plugins [22:55] 0.044 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins [22:55] 0.133 encoding stdout as sys.stdout encoding 'UTF-8' [22:55] 0.168 bzr-svn: using Subversion 1.6.6 () [22:55] 1.808 Traceback (most recent call last): [22:55] File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 853, in exception_to_return_code [22:55] return the_callable(*args, **kwargs) [22:55] File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr [22:55] ret = run(*run_argv) [22:55] File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases [22:55] stupenrose: please don't paste lots of lines of text but use pastebin instead next time :-) [22:56] sorry: I be IRC newbie. [22:56] stupenrose: In particular the full error message - the actual revision id rather than "None" [22:56]