[00:23] * mattman_ is away: [00:37] mkanat: mwh says if you request access to ~loggerhead-team he will approve it [00:37] poolie: Okay, will do. [00:37] Done. [00:49] hi spiv? [00:52] jam: Thanks for the cvs2bzr recommendation. Worked like a charm. [00:56] Good morning :) [01:46] spm: are you familiar with the new bazaar website deployment? [01:47] lifeless: as in for http://bazaar.canonical.com/ ? [01:47] yes [01:48] heh, no. not familiar with. [01:48] poolie has asked me to look at why an rss feed cron job in it isn't. [01:48] and crontab -e as bzr-website on the machine -> empty file [01:51] is that the way rss feeds are generated for the site? as in some I've worked with previously (geeklog springs to mind) encode the generation of rss in every home page request (I deliberately disabled THAT gem). [01:51] :> [01:51] yeah [01:52] so I think I have it sorted - thanks [01:55] ftr, its running from poolies crontab [01:57] thanks for all the reviews jam [01:57] i should migrate them... [01:58] lifeless: coolio. possibly we should have a 'bzr' account to run those sorts of things, but that works. [01:59] there is a bzr-web [01:59] (or something like that) role account [01:59] i should migrate the cron jobs to run in that [02:00] that works [02:00] lifeless: is there a reason you have not merge in my pandora-build packaging updates? or have you just not gotten to it? [02:10] mtaylor: time, yeah. [02:12] lifeless: ok. just wanted to make sure it wasn't blocking on me [02:15] I don't think so. [02:15] Was moving country etc. [02:15] the hits keep on coming ;> [02:31] lifeless: you were moving country? [02:32] lifeless: where do you live now? [02:32] NZ [02:32] ah. [02:33] so you're even closer to my timezone now :) [02:33] yes [02:33] woot [02:33] except when I'm in .au (now), or europe (week after next) [02:33] well right [02:33] same goes for when I'm in other places - or when new zealand moves into the indian ocean [03:03] http://www.paulhammond.org/2010/06/trunk/ [03:06] * spiv hmms at a stacking test [03:10] spiv :) [03:10] so you're going to tackle those other bugs and then prod merge cleanups? [03:11] (if so that's fine with me) [03:11] poolie: yep, exactly [03:19] Can I get an incremental review of just http://bazaar.launchpad.net/~spiv/bzr/reconfigure-unstacked-551525/revision/5331 ? I had some minor test fallout. [03:22] +1 [03:23] lifeless: thanks [03:24] thanks for the direct link [03:24] I wish that page didn't need a click to see the diff [03:31] -> fud [03:31] i am trying to deprecate osutils.re_compile_checked. adding @deprecated_function(deprecated_in((2, 2, 0))) produces 'no attribute _format_version_tuple' http://pastebin.com/EeEiLfbx [03:31] should i be doing something differently? [03:36] parthm: argh, imports :/ [03:37] parthm: the issue is that _format_version_tuple in bzrlib/__init__.py is defined after the import of bzrlib.lazy_regex [03:37] The fix is probably to move the definition _format_version_tuple above that import. [03:38] spiv: oh. ok. i can fix that and send it separately for merge if that works. [03:38] Or do the deprecation without using the decorator, I suppose. [03:38] (I don't have a strong opinion either way) [03:41] spiv: i will go ahead and am a separate patch for that. its a trivial change anyway. its nicer to use the decorator. [03:57] spiv: https://code.launchpad.net/~parthm/bzr/format_version_tuple_import_order/+merge/28953 [04:07] parthm: reviewed, thanks [04:12] spiv: thanks. i fixed the comment. do you think its a small enough change to send to pqm or do we need another review? [04:18] parthm: Fine to send, I think. [04:19] cool. thanks. i will send it. [04:33] parthm: hi [04:34] parthm: I gave similar advice to john earlier in the review of your bad ignores branch [04:34] parthm: Perhaps you missed it? I'd like to help you land that branch. [04:40] lifeless: hi. i might have missed it. what are you referring to? [04:40] the layering - passing in info about where patterns came from etc [04:42] lifeless: ah. yes. thats probably a good way to go. i might have missed it earlier. the comments on the patches were really growing long :) [04:43] lifeless: i plan to look at that once the current patch (part-1) lands [04:53] Hmm, there are a few TODO comments in chk_map talking about improvements that weren't done because we didn't have a pure-python StaticTuple [04:54] There might be some cheap wins to be found there [05:01] spiv: revision specs could use cleanups [05:03] lifeless: very much, yes [05:04] lifeless: the trick is doing it without disrupting 3rd party implementations & callers too much, I think [05:04] But right now, lunch! [05:06] spiv: yes; I made the comment when working on loom. [07:33] hi all ! [07:33] vila: salut [08:01] night all [08:03] * poolie is trying to backport python-configobj to dapper in the ppa [08:03] hi there parthm vila [08:15] Say I have to releases trunk and release and I need to fix a bug in release but trunk has moved on. Am I better off fixing it in trunk and then cd release; bzr merge -r REVISION_ID ../trunk [08:15] or fix it in release and merge back into trunk [08:15] or it doesn't matter or some other better way? :) [08:17] If you merge release branches back into trunk (which is how bzr manages its branches), then branch off release and fix it there is typically easiest. [08:17] Because then your fix branch can be merged directly into both your trunk and release branch. [08:17] spiv: ok that's what I thought. Thanks [08:18] But fixing in trunk and then backporting via "bzr merge -c BLAH ../trunk" is not too painful either, although it leaves bzr with slightly less complete information in the revision history. [08:22] If I'm going to make a repository public for all users on a host, what's the recommended way? Currently 'chmod -R 777 repo-dir' comes into my mind [08:23] if you want to let them all commit to it? [08:23] that would do [08:23] poolie: Okay, thank you. [08:28] And I suddenly find there are very large files (~3.7G) in my ~/.bazaar/svn-cache directory. Can I delete it? [08:34] You can. [08:35] (But bzr-svn may need regenerate some or all of them later if you access a SVN repo with bzr.) [08:39] spiv: Fine. Storage is a more critical factor than speed for me now :) [08:40] poolie: I was taking a bet with myself whether you'd have finished yet :) [08:41] mgz: hey, when you get here, it might be nice for us to put heads down and get a subunit + testtools release done [09:07] http://pastebin.ca/1892599 what can be the problem? [09:12] swathanthran: s/lh/r/ [09:12] swathanthran: try it with a web browser and you'll realize you're using the wrong url (use 'r' not 'lh') [09:13] yeah i guessed that but didn't know what to use instead of lh [09:13] and lh is disabled on savannah. [09:14] swathanthran: I walked up to the root to find it [09:15] swathanthran: I don't know what is going on with lh on savannah [09:16] anyway to find out how much size it could be? [09:17] what ? savannah ? loggerhead ? the branch ? [09:17] sorry, the branch.. [09:17] swathanthran: 147.685 Transferred: 60985kB (413.9kB/s r:60931kB w:54kB) [09:17] to find out how much size it could be to download, before downloading [09:18] vila: ok thanks. [09:18] swathanthran: there is no easy way to find that without downloading :) It depends on what you want to download and that can be a part of the whole [09:19] ah [09:20] the bulf of the data is the revisions, but you can branch from an older revision or the branch's repository can containg more revisions that you need to download [09:20] and you may already have some revisions locally and don't need to download them [09:21] oh yeah, how to download the sources alone? [09:23] bzr co --lightweight? [09:24] that's one way, another is: bzr export builder.tgz http://bzr.savannah.gnu.org/r/gnewsense/builder [09:24] but the former will allow you to update at will [09:25] oh thats great.. i actually wanted just the current version.. [09:27] swathanthran: right, if it's a one-time only operation it's ok, but you'll pay the full price the next time you need it otherwise [09:27] sure, at night, i don't have to pay for the net, to get along with work now, i have ot pay for the bandwidth;-) [09:27] bzr export does it without having the branch on our system? [09:28] swathanthran: both export and co --lightweight won't store the downloaded revisions, you'll pay at each use :) [09:29] swathanthran: if you use a local branch, you'll only need to download the new revisions next time [09:30] yeah got that.. i'll do a full branch at night when i have bandwidth.. [09:30] and cool, i just got builder.tgz and it was like 20mb or so i guess. [09:31] G'night all. [09:33] spiv: g'night [09:34] vila: thanks !:) [09:38] without loggerhead, can i have an http link to just one file on the repo? === Daviey_ is now known as Daviey [10:44] hi guys, i'm wondering if anyone can help me out; i'm getting this traceback http://pastebin.org/369909 whenever I try and checkout some branches from my SVN repo [10:47] Glenjamin: It looks like you might be branching into an existing shared repository.... if so can you try without? [10:51] there's a whole bunch of inconsistent details in skipped record errors along the way - but the checkout appears to have worked. [10:52] does this mean my shared repo is corrupt in some way? [10:53] Sounds like it [10:54] Try 'bzr check' to get more info, and 'bzr reconcile' to try to fix it [10:59] i guess bzr check sitting there not spitting out any output for a while is probably just it working [10:59] seems to be munching cpu, so i'll trust it [11:03] check is not optimised -> by which I mean its pretty slow compared to many other commands [11:06] fair engouh really [11:06] http://pastebin.org/369954 was my output [11:06] do i just do reconcile on the repo now? [11:07] reconcile can't fix the ghosts [11:07] it can fix the parents. [11:07] that may fix your error [11:07] have you looked in the bzr-svn bug tracker ? [11:07] i have, the only similar errors are from 2008 and marked as fixed. [11:07] ok [11:07] take a backup [11:08] then give it a shot [11:10] bah, no luck :( [11:10] i guess i'd better post the bug [11:35] cheers for the help guys, fresh repo from SVN seems to be working :) [15:00] GaryvdM: are you currently working on desolation? [15:00] (no problem if you are, just checking) [15:09] Hi jam [15:09] I am, but am about to go to ice hockey. [15:09] Trying 1 last build [15:09] np [15:10] jam: do you normally work in cygwin bash, or window cmd? [15:10] GaryvdM: *I* work in cygwin bash [15:10] I believe Ian was working under cmd using gnumake for win32 [15:11] rather than cygwin make [15:11] I just find setting up cygwin a whole lot easier [15:11] setup.exe is at least a cygwin package manager [15:11] yes [15:12] ok I'm off to ice hockey [15:13] GaryvdM: have fun [16:09] aaaaargh lp ! come back ! [16:20] jelmer: when you get this, 'bzr-svn' doesn't seem to have a tag for 1.0.3 [16:20] vila: hi [16:20] jam: that's correct, since 1.0.3 is not out yet [16:21] ah, I misread your lp page then [16:21] hi jam ! [16:21] building the installer for 2.1.2 and hacking together the old scripts === deryck is now known as deryck[lunch] [16:21] I think igc's updates were a push in a good direction, but I don't fully understand them, and they aren't working *right now* so easier for me to start with a known place [16:22] jelmer: yeah, looking now I see 1.0.3 is an open circle. I missed that the first time [16:22] vila: lp seems to be back for me [16:26] jam: yup. me too now [16:39] anyone know why Launchpad now requires REFERER to be set to upload files? [16:39] It is a real pain for me to upload 5 installers using Firefox versus just a plain script [16:40] ah, here we go: https://answers.edge.launchpad.net/launchpad/+faq/1024 [16:40] of course, *curl* has no referrer because I just uploaded it manually [16:40] sigh [16:41] you can probably set the referrer on the command line for curl? [16:41] mwhudson: I assume so, but it feels stupid to fake a referrer [16:41] and requires time for me [16:41] :) [16:41] jam: sounds like a good referrer to use [16:42] 'this feels stupid and is a waste of my time' [16:42] exarkun: except since launchpad is trying to validate it, I imagine that won't work. But I'll give it a shot :) [16:42] the FAQ I linked claims they use it to avoid cross-site scripting [16:42] no [16:42] so all POSTs to LP now have to have a Referrer [16:42] cross site request forgery [16:43] not quite the same [16:43] in particular: no scripting [16:43] mwhudson: so what is the specific problem if my web page helps you to upload something or update a bug on lp? [16:43] is it more of a 'don't send your login credentials to 3rd party sites' ? [16:44] The idea is that javascript on some other site can't trick you into making a POST to launchpad to do something evil, using your cookie [16:44] maxb: again, not javascript, javascript already can't do that [16:44] boring old html can though [16:45] mwhudson: so... will any edge.launchpad.net url work as the referrer? [16:45] http://en.wikipedia.org/wiki/Cross-site_request_forgery [16:45] For that purpose, isn't a missing referrer as good as a correct launchpad.net referrer? [16:45] jam: probably [16:46] exarkun: some people disable referrers in their web browser [16:46] and they want to protect you from yourself [16:46] it seem [16:46] seems [16:46] a better fix is nonces in the form, but that would be considerably harder to trick with curl i guess :) [16:46] mwhudson: the best part is because of how http uploads work, you don't find out about the failure until *after* you've upload 4MB of content [16:46] and the real real fix for uploads specifically is an api to do it [16:47] jam: 100 Continue !!! [16:47] exarkun: ptth! [16:47] mwhudson: yea, I was gonna say [16:47] mwhudson: haha. [16:48] and, of course, all of this worked 3 months ago when I was doing it last [16:49] like 5+ things broke in the windows installers steps [16:49] mwhudson: so --referrer https://edge.launchpad.net worked just fine [17:19] vila: true story. Trying to download the svn binaries leads to URL recursion. It seems they redirect you to a second page, which then sets a cookie and redirects you back to the first page. If you don't carry your cookies along, then you get infinite recursion. [17:19] *sigh* === deryck[lunch] is now known as deryck [17:23] * vila bangs head on desk [17:24] vila: building the windows installers is being a real joy [17:24] ... [17:24] I remember why I loved doing them so much in the past [17:25] * jelmer sees his sarcasm-o-meter pan out [17:25] it seems that everything in the world decided to change in the last 3 months, just to thwart us [17:25] zlib has a new release without a similar dll build [17:25] lp now requries referrer to be set [17:26] ian did a lot of work to update the installer, but I don't quite follow how it should work yet [17:26] svn moved to apache [17:26] and doesn't have *new* dlls, and now the old dlls have crazy redirects [17:26] qbzr didn't tag 0.19b1 in their trunk [17:26] ah they did, but as '0.19beta1' [17:27] anyway... getting there [17:28] we shut down the old desolation instance, and it may have only been working because all the files were already cached in d: [17:31] jam: :-/ [17:31] so before I EOD, you want me to confirm that as soon as the test suite is passing on windows I will set up babune for windows daily builds ? :-D [17:31] anybody knows how to fake a buildout signature so that we can manually do the download and work around buildout trying to be extra helpful [17:33] err, won't that make the next failure even more horrible to address ? [17:35] vila: I don't care, I want to get builds [17:35] stuff is der broken [17:35] I'm asking sidnei for help, hopefully he can help work out the buildout stuff [17:36] vila: right now I'm reverting back to my old code because it actually works [17:43] and I'd really like to switch to what Ian was working [17:43] on [17:51] it sounds like the fast-import format prefers ASCII with the exception of raw file data. Is it possible to have non-ascii filenames? I've been having a lot of trouble with latin-1 encoded filenames from Perforce importing into Bazaar. [17:53] chaosaddict: I believe the data stream is assumed to be in utf-8 [17:53] any way you can get the perforce output to .decode('latin-1').encode('utf-8') ? [17:55] hi. how is this even possible? http://pastie.org/pastes/1026887 [17:55] jam: I believe I have that working, and the fast-export-from-p4 part works. However then the fast-import step crashes. I haven't figured out the root cause on that yet. [17:55] chaosaddict: tracebacks help [17:55] jam: unfortunately it spits out a parsing error, rather than a crash + traceback. [17:56] eydaimon: One side has: "pu = PaymentUser" and the other side only has "PaymentUser" [17:56] I don't know what .rvmrc is, but it appears to be something your vim dropped in the current working dir [17:57] eydaimon: otherwise I don't really understand your question [17:57] jam: The point I'm making is that after modify the file, and I resolve it, there's nothing to check in [17:57] jam: and if I merge again, I get exactly the same thing happening [17:57] eydaimon: I don't really know. I would think at the least the merge revision would be ready to be committed. [17:58] exactly [17:58] Though maybe this is because of the "infinite merge request" issue [17:58] sounds like [17:58] merging a => b creates a commit that can be merged b => a [17:58] is that an open bug? [17:58] so we probably added code to prevent that [17:58] which is triggering here [17:58] I don't think this is an open bug [17:58] which is [17:58] then how can I address it? [17:58] conflict resolution leading to know content change is preventing commit [17:58] or something along those lines [17:59] eydaimon: worse case you can make a trivial change somewhere [17:59] I don't want merging with trunk forever more to cause conflicts [17:59] but I'm also surprised that 'bzr status' doesn't say anything [17:59] can you paste the output of "bzr merge ; bzr status" *before* you resolve the conflicts? [17:59] yeah [18:00] you might want to use paste.ubuntu.com, your formatting came out a bit weird on pastie [18:00] I already show the first merge [18:01] eydaimon: you showed the merge, but not 'bzr status' afterwards [18:02] reload pastie to see changes [18:03] eydaimon: so something is odd about your merge, as it isn't recording a revision to be merged [18:03] ahhh [18:03] you are doing a single file merge [18:03] that doesn't get recorded [18:03] you have to do a full tree merge [18:04] k [18:04] I would do that but there's one of the files I didn't know how to handle [18:04] so I was doing a whole directory [18:04] ( was using one file as an example here ) === wilx_ is now known as wilx [18:07] 6) Important since these often outline the actual changes in a short form or [18:07] reason for why the commit were done in that specific branch. [18:07] Oops. [18:07] Sorry. [18:07] Drag-and-drop. :-| [18:19] jam: Do you still need the account on my machine? [18:19] mkanat: only if you tell me I do :) [18:20] jam: Okay, I'll test meliae first. :-) [18:46] garyvdm, jam: thanks for working on packaging 2.2b3 for windows [18:47] mgz: well, my version is pretty hack-tastic, but let me know if it works for you [18:47] zlib has a new release without a similar dll build <- you still needed to do this bit? Does svn or something also need the dll? [18:47] mgz: since you mention it, probably not. but the build code I was using still did [18:47] I'm going to test it to see if my -OO change does anything bad to plugins, then send a message to list for plugin authors [18:48] lifeless: after I do that, I have an hour out or so for squash, but am then free all evening for testtools/subunit things [18:50] 'd file a bug on the referer thing jam, even though it's easy to work around, it's stupid [18:50] uploading doesn't sign the binaries or anything, right? [18:50] mgz: It looks to be a purposeful design thing, so I can file it, but I think the powers-that-be have explicitly requested it [18:51] mgz: no, I manually sign them [18:51] it's purposful for editing bugs and so on, but an upload isn't a db-state-changing thing [18:51] it's just moving bits. [18:56] okay, I get API version complaints from svn and rebase [18:57] urk, and this one is my fault: [18:57] ValueError: No help message set for [18:57] dang jelmer already left [18:57] I *thought* I'd avoided that, and the thingy had been changed not to throw any more anyway [18:57] send a message to the list [18:57] will do. [18:57] mgz: I think it has, but that will be in 2.2b4 [18:57] which isn't released yet [18:58] okay, so, this is a maximally borked version, that will probably be useful [18:59] these plugins *are* seperate though, and should be compiled differently, I wonder what went wrong [19:00] mgz: well, I used some old build tools [19:00] the setup.py is from the bzr you're shipping though, right? [19:00] should be [19:01] (i'm pretty darn sure it is) [19:03] okay, so the bit that seems not to be working is the install_data_with_bytecompile class ~line 530 [19:03] or I misunderstood how it works [19:03] the idea is that things in library.zip should get optimize=2 and things in the plugins dir should get optimize=1 [19:04] mgz: sure I remember that part of the patch [19:04] I don't know what it takes to make it work or not work, though [19:05] ah, urk, problem. [19:05] it seems the pyo files there do contain the docstrings [19:06] so, instead perhaps the problem is when bzr.exe runs, it does in such a way as they're not loaded? [19:06] which would be I need to work out how to seperate the byte compiling of py files from the mode set for the base script [19:08] I'll get something worked out. [19:10] mgz: my quick-and-dirty test says it shouldn't matter [19:10] if I compile a .py to .pyo and include the docstring [19:10] running python -OO main.py still loads the existing .pyo and still has a docstring [19:11] hmpf, so that's what I originally assumed, something else must be going on [19:11] so I would guess something else is at fault [19:11] mgz: we need a way to get to a python interpreter from the bzr.exe :) [19:12] that would indeed be useful ;) [19:12] bzr interpreterplz [19:12] wait, I already have the machinery for that, have a throwaway plugin to shove arbitrary stuff in [19:14] mgz: yeah, here is one option: http://writeonly.wordpress.com/2008/09/08/embedding-a-python-shell-in-a-python-script/ [19:14] which uses ipython [19:14] but I think you could just have something that does "import pdb; pdb.set_trace()" and get something good-enough [19:15] code.interpret is it indeed. [19:16] dammit, we don't bundle that. pdb it is. [19:17] okay, so explorer does have doc strings. [19:17] is this going to be something daft like, that cmd really *doesn't* have one in the source? [19:17] I should have checked that. [19:18] nope, it seems it does. [19:18] mgz: it does in my copy [19:19] mgz: are you sure it isn't loading your *local* copy of the plugin rather than the bundled one [19:20] and because it is running -OO it is stripping them on-the-fly [19:20] oooh [19:20] okay, and it really is missing from bzr.exe's perspective, though other bits keep it. [19:20] so your code breaks people from installing extra plugins (it would seem) [19:20] it does, if they don't install them correctly [19:20] mgz: I mean, if you put something in BZR_PLUGIN_PATH it will get loaded with -OO [19:20] I'll check on the location, but bzr.exe should really get the path right [19:20] which will break them [19:20] right. [19:21] import bzrlib.plugins.explorer; print bzrlib.plugins.explorer [19:21] should tell you what you want to know [19:21] they are all from the right place [19:22] mgz: define 'right place' [19:22] the bundled plugin [19:22] or a user-installed copy [19:22] bundled [19:22] what I don't get is that bzrlib.plugins.explorer isn't stripped, but bzrlib.plugins.explorer.lib.commands is [19:22] and they are both from the installer [19:22] so... one of two things [19:22] mgz: and what does bzrlib.plugins.explorer.lib.commands.cmd_explorer.__doc__ say ? [19:23] (None) [19:23] mgz: ah, so the sub-dirs are getting stripped [19:23] (as in, it says nothing, because it really is None) [19:23] I wonder if they aren't getting anything [19:23] right, so one of two things [19:23] aren't-getting pre-compiled because it isn't doing something recursively [19:23] either the installer is being generated with some plugin files stripped and some not [19:24] or the installer isn't generating some plugin files, and it's happening at run time with -OO [19:24] * mgz checks timestamps [19:24] mgz: I would guess the latter [19:25] mgz: I'm going to install here, and see what files end up [19:25] yup, and on quick check, it's only commands.py that's 18:58 rather than 09:31 [19:26] mgz: C:\Program Files\Bazaar\plugins\qbzr\lib\commands.pyo [19:26] exists at install time [19:26] but I also had a problem with qbzr, so this suggests something slightly more systematic than one missing file in a list [19:26] ^ack. [19:27] timestamp of commands.py is 9:30am, timestamp of commands.pyo is 9:34 am [19:27] okay, nice little mystery then. [19:28] mgz: and the timestamp isn't updated when I run bzr.exe [19:28] but it still fails to run bzr explorer because of a missing help text [19:30] mgz: opening the commands.pyo in vim shows that the strings are present [19:30] something is certainly causing them to be rewritten here. [19:31] just did bzr lp-propose [19:31]