[00:02] pickscrape: I'm not aware of any BB maintainers, no. [00:20] lifeless: can I pick your brains for a sec about bzr+ssh and hooks? about 5 min [00:20] kfogel: no. [00:20] kfogel: you can read my reply to beuc, then come and pick my brains after that. [00:20] lifeless: I did. [00:20] ok cool [00:20] lifeless: oh, wait -- you mean in the last half hour or so? [00:20] 120 seconds ago [00:20] lifeless: I was writing a reply, then wanted to confirm something... heh [00:20] lifeless: cool [00:21] lifeless: you may have made my whole reply unnecessary. I'll go read now. [00:25] kfogel: bzr-hookless-email is totally different, btw. [00:26] lifeless: I know (I'm well-acquainted with it, and have a patch in it actually). I think it is what Stefan is using for commit emails, but am not positive. [00:26] I'm pretty sure we're *not* using bzr-email. [00:26] well, you can't, until bzr-ssh is enabled. [00:26] at which point you probably should :P [00:27] lifeless: actually, I like Stefan's solution much better, because then mods to our commit email system do not have to block on savannah admins! [00:27] kfogel: I don't see the connection, but I don't care either. [00:27] whatever you like is what you should get [00:28] (my description of how bzr-hookless-email works to Sylvain is a bit too shorthand; unfortunately savannah tracker doesn't allow comment editing either :-( ) [00:28] neither does lp. [00:29] wikis they are not [00:56] morning === timchen119 is now known as nasloc__ === oubiwann_ is now known as oubiwann [02:10] hi everyone - is there a way to generate a revisionnumber into a file? I want it to get printed out each time the program is started. [02:10] so the user can see which revision he is running. [02:11] bzr version-info [02:11] http://bazaar-vcs.org/KeywordExpansion === dOxxx_afk is now known as dOxxx [02:13] dOxxx: exactly what I'm looking for, thx [02:32] I did a bzr tag --force.. ever since, every push and pull I get "conflicting tags: blah"... how can I fix this? [02:32] push --overwrite [02:32] Or pull --overwrite [02:32] Depending on which tags you want to keep and which you want to overwrite :) [02:56] lifeless: the patch on the "disable pymalloc" bug does have a configure switch to enable it. The issue about the tuple cache is certainly something that would be a useful extension, but the patch is useful on its own [02:57] jamesh: cool. I'm chatting to gutworth about it [03:00] ssh: connect to host bazaar.launchpad.net port 22: Connection refused [03:00] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [03:00] ? [03:00] ah, launchpad is down [03:01] yes :( [03:01] we're doing a db schema change amongst other things [03:01] and zope is blowing up [03:01] I'm told we're rolling back and it will be back very soon [03:02] * gutworth is so glad he's not in charge of administering large websites [03:03] somehow encodings.utf_8.codecs became None [03:03] not during vm shutdown either [03:03] that happens in our tests all the time, too [03:03] does it? thats very interesting [03:03] does anyone have any idea /how/ ? [03:04] you should ask __ap__ when he's up [03:04] I think he fixed it [03:04] mmm ... ~/.bazaar/rules is written, but $Date$ does not get replaced upon a commit - do I miss something concerning keywords? [03:04] shall [03:04] selftest ran fine. [03:05] we're very proud of __ap__. This is his handywork http://python.org/dev/buildbot/stable/ [03:09] lifeless: http://bugs.python.org/issue6551 [03:10] thanks! [03:15] is there any way to check if the rules file is applied? [03:16] a7p: it should be if your working tree is in a new enough format, IIRC. [03:17] *sigh* [03:17] a7p: (2a, the default format in 2.0.0, is new enough) [03:18] a7p: what bzr version do you have? [03:18] a7p: what does 'bzr info' report for you? [03:18] a7p: I don't think there's a command to find out what filters are active or applied to a particular file, although maybe there should be. [03:18] pack-0.92 - I'm running 1.18 [03:19] 'bzr upgrade --1.14' would work for you I think. [03:19] yep you need a later version [03:20] (Although I'd recommend upgrading to bzr 2.0.0 and using the current format when you can, as it is faster and smaller.) [03:20] thx, - thanks I'll try that ... just have 1.18 installed since it's the default in macports [03:26] mwhudson: the bugs attached to lp:ubiquity seem to imply we need to think a bit more about the user model too [03:27] *sigh* - still does not work. [03:28] a7p: what specifically is not working? [03:28] you're not seeing the file being filtered? [03:28] there were several bugs in 1.18 with filters not been applied enough [03:28] sorry, but that's how it was [03:28] several are fixed in 2.0.x [03:29] poolie: i've just upgraded to 2.0.2 [03:29] http://paste.ubuntu.com/333592/ [03:30] rules is configured to [name *] keywords = on [03:30] % bzr plugins [03:30] to my understanding $Date$ should get the current date added upon commit [03:31] git, hg, keywords, launchpad, net_credential_store, svn, xmloutput [03:31] a7p: I think you can also do 'rm foo; bzr revert foo' to regenerate a file with the current filters. [03:31] yes it'd be good to see if that works [03:31] ah, I should run the selftest with 2.0.2 [03:31] selftest is quite an internally-facing test [03:32] it probably won't find anything related to bad installation [03:32] okay - theres' something messed up - was fine with 1.18 [03:32] I'll remove the other plugins [03:32] selftest is mainly a tool for developers rather than users [03:32] james_w: i guess you're asleep? [03:33] hi poolie [03:33] guess again :-) [03:33] hi [03:33] blame canada? :) [03:33] anyhow [03:33] regarding the udd stuff [03:33] * a7p is confused - just removed most plugins from ~/.bazaar/plugins, but they still appear upon bzr plugins [03:34] james_w: i realize there is more to do than the two items i raised and the ones vincent added [03:34] ah, sry, my wrong [03:34] a7p: 'bzr plugins -v' [03:34] i should have made it more clear that i'm just trying to work out what specifically to do in the medium term [03:34] (that shows you where they seem to be installed) [03:34] to get from a longish set of stories to what we do this week and next week [03:36] poolie: yeah, I think I may have phrased my mail badly [03:36] it happens :) [03:36] ahhh ... *g* [03:37] I felt I was missing a step, I saw "here's a bunch of things we could work on," then "here's what we are going to work on," and didn't feel I knew how the two were joined [03:37] oh [03:37] I appreciate I wasn't at the sprint [03:37] $Date: (evaluation error) $ - it's a big step forward ;) [03:37] well, it was kind of a straw man for you to object to [03:37] if you were to file say 3 high priority bugs tagged udd we'd probably just do them [03:38] i don't know if you feel ready or able to do that [03:38] a7p: heh [03:38] but we do need to cross that somehow [03:38] poolie: I'm currently writing my second spec, which should distill out some of the other things that we would like [03:38] I think it would be good to see how that tallies with the list that you had, and see what changed at UDS [03:39] I'm concious of time passing, but the spec will be done tonight, and I'll fire off a mail to udd before bed [03:39] https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development is one [03:39] that's ok [03:39] we have useful stuff to do [03:39] i'm writing a mail about this at the moment [03:39] see "Migration" for one set of things that I'm not entirely sure about [03:39] i just feel a bit like the bzr team is doing business as usual on bzr [03:40] yeah [03:40] when we should be reorienting a bit more towards udd [03:40] poolie: yeah [03:48] grrr, I'm giving up for now - got to write some code for money. [03:48] thanks for your help [04:07] puh, just switched from bzr+ssh to sftp to avoid having to upgrade the servers bzr. [04:22] poolie: do you think one mail with all the issues I want to discuss to udd is the best thing [04:22] or start a thread per-issue? [04:22] * Kamping_Kaiser shakes his head at bzr. 3 step upgrade is a bit silly [04:24] ooh, thanks mwhudson [04:24] james_w: i hope you're not in bristol [04:25] nope :-) [04:25] Is there any UI for "make this repository as small as possible", or must I manually rm the contents of obsolete_packs to achieve this? [04:26] james_w: good [04:26] james_w: and you're talking about the AttributeError thing? [04:26] yeah [04:26] though I like the cleanups anyway :-) [04:26] james_w: ah, np :) [04:26] maxb: it'll clear it out on the next pull or commit [04:26] i was impressed there wasn't more flakes [04:26] I use vim-pyflakes now [04:27] maxb: there's a bug for an option to pack to rm them [04:27] um [04:27] maxb: not really, why? [04:27] james_w: whatever you think best [04:28] bob2: No, it'll clear out on the next pack. [04:28] (including auto-packs) [04:28] oh [04:28] It just feels like a UI wart [04:28] and rm-ing things inside .bzr is scary-ish [04:29] maxb: But...why would you want to? [04:30] Peng: it can take up significant amounts of space [04:30] only if you run 'bzr pack' :) [04:30] (I thought the next operation that altered the repo data cleared obsolete_packs) [04:30] generally it will be ~ 1% of the repo [04:30] bob2: the next that /deletes/ from the repo [04:30] packing involves deleting pack files [04:34] james_w: I would like to do something about the copy-pasted code from "bzr import" (bzrtools) to "bzr import-dsc" (bzr-builddeb). I see two options: A) Push the changes into bzrtools, and depend on a *really* new bzrtools, or B) Separate out the code into a .py file which is deliberately maintained to be as close as possible to the bzrtools version, but sever the actual dependency. What do you think? [04:35] maxb: I'd like to push the changes to bzrtools, so at least we could depend on it after a dwell period [04:35] and because it's the right thing to do :-) [04:36] I just haven't previously had time to separate out the changes and propose them back, sorry [04:38] james_w: Do you think option B might make sense in the interim, to make it easier to see what we still need to push back? [04:38] maxb: I would have no problem with doing that [04:38] I'll do a MP [04:55] good night all [05:02] james_w: have you seen https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports ? [05:03] I've heard about it [05:03] haven't ever felt the need to use it though [05:03] hm, i should merge trunk into it again it seems [05:03] instead i'm going to go and see spamalot though :) [05:04] enjoy [05:14] spiv, hi? [05:14] quick call? [05:21] poolie: sure [06:17] good night [07:20] hi all [07:20] james_w: wow, where are you ? Or should I say when ? [07:21] There's currently no way to embed a branch within a branch, is there (ie: foo/ being a branch, and branching bar into foo/bar)? [07:30] RAOF: Well, bzr won't mind if you put "bar" in "foo", but they won't be linked together in any way like svn:external. [08:39] * igc dinner [09:41] hello [09:45] * fullermd waves at bialix. [09:46] * bialix warmly waves back [09:46] * bialix hopes he learn this "waves" phrases correctly [09:48] Well, except for the 'warmly' part. This time of year, I don't believe anything around you is warm :p [09:50] even if you in the building? [09:59] bialix: hey ! [09:59] heya vila!!! [09:59] fullermd: ha ha ! You didn't escape quickly enough today ! [09:59] got my mail? [10:00] fullermd: vila: LOL [10:00] which one ? :) I just replied to the selftest related one [10:00] about extra libs [10:00] not yet [10:00] Eep! I mean, I'm not fullermd. I just broke into his house, and am using his keyboard. Yeah. That's it. [10:00] wanna chat? [10:01] I filed a bug about it this morning, let me find that back, but yes, a quick chat will be welcome, we can always update the bug with a summary of it [10:01] link to a bug please? [10:02] fullermd: right, so get out of that house, quick ! You don't know what the guy will do if he finds you!!!! [10:02] fullermd: he's known to be a freaking lunatic, member of the NRA and very active there ! [10:03] fullermd: and that's without mentioning his remotely controlled webcam, man, you're so already dead.... [10:04] Webcam?! Ack! [10:04] * fullermd puts on pants real quick. [10:04] bialix: bug #491797 [10:04] Launchpad bug 491797 in bzr-windows-installers "Allows bzr.exe to take additional plugins (and their required libraries) into account" [Undecided,New] https://launchpad.net/bugs/491797 [10:06] vila: just this morning I've thought about standard location for extra libs [10:07] maybe bzr needs to use something like PythonXY/site-packages [10:07] bialix: aaah, execellent, I was afraid some technical reason was escaping me making it impossible ! [10:07] inside C:\Program Files\Bazaar [10:07] yup, exactly my thoughts [10:08] may be I expressed it too poorly in the bug report ? [10:08] there will be several difficulties IMO, but nothing really critical [10:08] It's kind of related to that BZR_PLUGIN_PATH discussion we had some weeks ago [10:08] sorry, I don't remember [10:08] last 2 months I was overloaded on my job [10:09] plugins can be searched into 'core', 'user', 'site', I seem to remember 'site' didn't make sense for you in the bzr.exe context [10:14] vila: perhaps [10:14] what is user there? [10:15] core means inside bzrlib/plugins/ ? [10:15] I don't remember what is site [10:15] silly me, forget everything :-( [10:16] 'core' is bzrlib/plugins, 'user' is ~/.bazaar/plugins and 'site' is ... well site-dependent obviously but that's the place where plugins are installed when you want all users to be able to access them [10:17] bialix: I think you forget it because you have no use for it yourself :) [10:17] yep, I'm happy with BZR_PLUGIN_PATH [10:18] for bzr.exe there is no use for core then [10:18] because bzrlib/plugins resides inside library.zip [10:18] I've explicilty extracted launchpad plugin from there [10:19] so now 'site' for bzr.exe is C:\PF\Bazaar\plugins [10:19] PF == Program Files (too much to type) [10:19] and user in APPDATA\bazaar\2.0\plugins [10:19] hmm, great, so can you add c:\PF\Bazaar\lib to sys.path ? [10:19] never really likes this 2.0 [10:20] it was not very good from jam side [10:20] and similarly APPDATA\bazaar\2.0\lib ? [10:20] PF\Bazaar\lib should not be added [10:20] why ? [10:20] because there all our standard c-extension lives [10:21] wait a sec [10:21] so you mean it's already there and doesn't need to be added ? [10:23] vila: here is PF\Bazaar [10:23] http://pastebin.com/d6d2dc13c [10:23] what's in lib ? [10:24] here is lib: http://pastebin.com/d2d2ef24d [10:24] scary [10:24] yes, lib is used for bundled libs for bzr.exe [10:25] there is lib\library.zip where all python-only libs stored [10:25] and too much of other c-extensions and dlls [10:25] excellent ! That's exactly where we *could* add more libs, except it will be far cleaner to have another one in sys.path [10:25] I've explicitly move those libs from PF\Bazaar to PF\Bazaar\lib [10:25] vila: we should not use lib [10:26] it's for standard things [10:26] Yeah, so what ? If I want to kill my install who will forbid that ? :-) Kidding, that's why I say we should add one more [10:27] So APPDATA\bazaar\2.0\lib sounds perfect no ? [10:27] Ha no, that's 'user', where would be 'site' then ? [10:28] bialix: anyway, we are indeed back to that discussion, the needed concepts are 'core', 'user' and 'site' otherwise we're running into cycles [10:29] 'core' is protected (that's your arguments about putting nothing more there), so you have to provide 'site' [10:29] That could be PF\Bazaar\site-lib [10:30] or PF\Bazaar\site\{lib,plugins} [10:30] bialix: still there ? [10:31] vila: bbiab [10:32] bialix: ok, no worries === jelmer_ is now known as jelmer [10:56] fullermd: how can I use tmfs on freeBSD (i.e. in memory file system for /tmp) ? [10:58] fullermd: looks like I need to add that to the kernel ? [11:00] fullermd: I hardly believe it's not there by default >-/ [11:00] Or load it as a module, I guess. I've never actually used it myself. [11:00] I just use a md-backed regular FS for mine. [11:01] that's what I want: /tmp in memory, whatever the mean ! [11:01] fullermd: how do you do that ? [11:02] See the tmpmfs flag (and probably tmpsize) for rc.conf. [11:02] (the default size is 20 megs, so that's probably a little tighter than you usually want in practice... [11:07] fullermd: so in defaults/rc.conf the doc for tmpmfs says: Set to YES to always create an mfs /tmp, NO to never [11:07] fullermd: and the default is AUTO.... color me confused :) [11:07] what does that mean exactly ? [11:08] df /tmp says 1M 512-blocks, so 512M, but that looks like real disk to me (as real as a VM can go that is...) [11:14] fullermd: anwyay, using tmpmfs="YES", tmpsize="256m" and rebooting, I now have a /dev/md0 [11:15] fullermd: so last question: when doing df I now have: [11:15] /dev/ad0s1e 1015260 5848 928192 1% /tmp [11:15] /dev/md0 507356 300 466468 0% /tmp [11:16] fullermd: could that be a problem ? Is the later mounted on top of the former ? Do the former act as an extension area for the former (ha ha, dream !) ? [11:16] OR should I just comment out the line in fstab for the former? === suBMUNDO is now known as SuBmUnDo [11:32] Yeah... having two things mounted on the same point is usually not what you really want :p [11:35] fullermd: ok, commented out for next reboot, df /tmp points to /dev/md0 for now, so I'm good :) === mrevell is now known as mrevell-lunch [12:23] can I use bazaar also as a backup system for directories with binary files? [12:28] poseidm: yes [12:34] do you use it for backup? or some other tool? === statik` is now known as statik === mrevell-lunch is now known as mrevell [14:05] vila: ping, I'm back [14:06] bialix: wow, that was a big biffy ;-) [14:06] biffy? [14:06] bialix: what is the last message you read in the conversation this morning ? [14:06] what means biffy? [14:07] bialix: bbiab means be back in a biffy, biffy being a very short time AIUI [14:07] vila, spiffy? [14:07] (hi!) [14:08] http://www.internetslang.com/BBIAB.asp says bit not biffy... [14:08] bbiab means be back in a bit? [14:08] where did I get that then.... [14:08] yes, vila, my in a bit was a bit longer than biffy [14:09] anyway, glad you're back :) [14:09] bialix: what is the last message you read in the conversation this morning ? [14:09] [2009-12-03 12:30:39] bialix: still there ? [14:09] :-D [14:09] I have log [14:10] hehe, so, how about PF\Bazaar\site\{lib,plugins} ? That seems to clearly defines the 'site' needed directories no ? [14:10] vila: So APPDATA\bazaar\2.0\lib sounds perfect no ? -- no, it seems wrong [14:10] esp on Vista where it could be roaming [14:10] yeah, yeah, keep reading :) [14:10] ok [14:10] so [14:11] that's why I said at start of our chat that good name is needed [14:11] maybe PF\Bazaar\python25-libs [14:11] maybe [14:11] any other variant is good, but having python version specified may help to avoid confusion [14:11] if people start installing package for 2.6 [14:12] PF\Bazaar\lib -- is our core [14:12] PF\Bazaar\plugins is our site [14:12] I mean for bzr.exe [14:12] so, if you want to take that into account, the blessed names are: [14:13] core is inside r/o blackbox, let me say that [14:13] PF\Bazaar\lib -- is our core [14:13] PF\Bazaar\plugins is our site [14:13] beuno: what is spiffy? [14:13] meh, don't mix up core and site there, one is for libraries, the other for plugins, so both should be 'core' [14:15] if you insist that bzrlib/plugins/* is core then I can say that PF\Bazaar\lib\library.zip -> bzrlib/plugins/* is the core [14:15] then you can have site\lib and site\plugins for 'site' and if needed lib\py25 lib\py26 but that would mean that bzr.exe exists for both 2.5 and 2.6, is that the case ? [14:15] and hi beuno [14:15] vila: no, bzr.exe bundled only one interpreter [14:15] bialix: I don''t understand the meaning of -> here [14:15] bialix, http://www.urbandictionary.com/define.php?term=spiffy [14:16] beuno, ah thx, it was spiffy [14:16] beuno: In fact I think I meant be back in a jiffy === pickscrape_ is now known as pickscrape [14:16] pfffffffffffffffffffffff [14:16] vila, that's it! jiffy! :) [14:16] bialix, http://www.urbandictionary.com/define.php?term=jiffy [14:16] :) [14:16] vila: I've used -> to indicate it's inside zip archive [14:17] bialix: ha ! ok ! FUll agreement ! core is r/o blackbox-cant-be-modified [14:18] * bialix shakes vila's hand, cool [14:18] but BZR_PLUGIN_PATH allows the user to put 'site'/'user' *before* 'core' if needed [14:19] * vila re-reading plugin.py [14:20] bialix: can you look at plugin.py get_core_plugin_path() and get_site_plugin_path() too ? [14:21] I think we are pretty close so let's make these last steps [14:21] vila: I'm not quite understand your remark about BZR_PLUGIN_PATH [14:21] vila: bb in 15 minutes [14:22] bialix: forget it for a minute, just think that the default path is: ''user' 'core' 'site' and read the comment in get_standard_plugins_path() [14:22] ok, will do, after short lunch [14:23] bialix: bon appetit ! [14:24] Hm, lunch. That's sounding like a goodish idea... [14:24] Morning [14:37] fullermd: lunch for whimps? [14:38] * bialix reading plugin.py [14:49] vila: ok [14:50] vila: get_core_plugin_path insist core on bzr.exe is PF\Bazaar\plugins [14:50] that's fine [14:50] right [14:50] user is APPDATA\bazaar\2.0\plugins [14:51] no problem here [14:51] right [14:51] site is still puzzling for me [14:51] let's leave aside for a minute [14:52] ok [14:52] so where we now? again [14:52] do you agree that bzr.exe can look at APPDATA\bazaar\2.0\lib for additional libraries ? [14:52] it can but I think it's bad idea [14:52] why ? [14:52] because it can be roaming [14:53] hmm, but in that case the plugins can be wrong too right ? [14:53] So it's the user responsability to be coherent between the plugins he install and the bzr.exe he install on his various hosts, right ? [14:54] well [14:54] honestly to say [14:54] I'm hate APPDATA\bazaar\2.0 location [14:55] ok, for the sake of the discussion, let's call it USER\plugins then :) [14:55] Don't you feel better ? [14:56] do you agree that bzr.exe can look into USER\lib for additional libraries ? [14:57] on my machine this is C:\Documents and Settings\myname\Application Data\bazaar\2.0\ [14:57] it's so boring to cd to this directory even via decent file mamanger [14:57] so I'm keep all my plugins in C:\work\Bazaar\plugins and has specified BZR_PLUGIN_PATH [14:58] how's your proposal will lokk given in mind my habit of BZR_PLUGIN_PATH? [14:58] vila: ^ [14:58] what [14:59] what's USER\lib [14:59] ? [14:59] I'm hate APPDATA\bazaar\2.0 location [14:59] ok, for the sake of the discussion, let's call it USER\plugins then :) [14:59] USER == APPDATA\bazaar\2.0 [14:59] why every user should have separate copy of third-party libs? [14:59] why not PF\Bazaar\extra ? [15:00] why not PF\Bazaar\extra-libs ? [15:00] because bzr.exe don't have a concept for 'site' which is where additional plugins and libraries can be installed in order to be shared between several users and several versions of bzr.exe [15:00] That's the whole point of the damn concept ! [15:00] another problem with APPDATA -- this folder is usually hidden [15:01] so you can't get there on vanilla windows machine [15:01] Can we focus on solutions to already identified problems before raising new ones ? [15:01] until you enable option to show hidden files in Explorer, or put the full path to address line [15:01] let's try to invent site for bzr.exe then [15:02] PF\Bazaar\site [15:02] ok? [15:02] or PF\Bazaar\site\{lib,plugins} [15:03] that's fine, though PF\Bazaar\site\plugins is useless [15:03] right, that was my last proposal this morning and that's what plugin.get_site_plugin_path() can return [15:03] there is PF\Bazaar\plugins tight here [15:03] s/tight/right/ [15:04]