We’ve discussed about this internal for a while (related on bug-jp 5967), we’ve decided to switch the team leader of MDC Japanese Translation Team from me to potappo. He’ve worked for more than a year on the area of JavaScript documentations and about:mozilla newsletters (this is the private service of MDC Japanese Team, included in the DevNews Japanese version). Please contact him about the MDC Japanese translations after this.

Of cource, it does not mean that i’ll retire totally from the MDC works. So, you could contact me about the MDC Japanese, and I’ll support him about the works.

Remark: The MDC Japan Project is related on the MDC Japanese site, but not the same. So, please contact me about that project.

From the topic of Latesttopics > IEからシェアを奪う、を合言葉にしていてはFirefoxが勝てない理由-outsiderreflex (The actual reason why FF cannot be the top, while we make “eat away at the share from IE” as the word. Link target is written only in Japanese)

I wonder when people feel interest in the market share of FF? The main target of our works must be to propagate the “Open Web Standards. At that point, the existence of open source softwares/browsers like Firefox or WebKit might be important.  So, “don’t forget the lost five years at the IE5/6 era.”

Of cource, i don’t argue with the comment that the browsers which doesn’t imprememnt the whole standards (might be checked with ACID test or something) is the another nightmare for developers, like the two standard levels in IE8. But, it might be better, at least, than the destroyed standards.

MailCoができて、Tb3のスケジュールが発表されて、と、動き出したように見えるThunderbirdですが、メールアカウント自動設定をDNSも利用して行う方法のプロポーザルがwikimoにようやく(?)まとまりました。

Tbに設定ファイルを組み込んで配布して、クライアントで自動設定する(TbのISPカスタマイズ版とかの方法ですな)はありましたが、メーラーで(特定ソフトに依存せず)汎用に利用できる方法がちゃんと策定できれば、大学とかの環境下ではかなり便利に利用できそうな気がします。企業さんなんかは、導入ソフトを固定すれば、それなりに決まった方法で設定できるので問題ないでしょうけれど、大学とかではそうもいかないですし。

I’ve upgraded two mozilla.gr.jp sites.

1. Copied TT based web scripts for seamonkey.mozilla.gr.jp
2. Created ‘planet’ of mozilla-gumi members

For seamonkey.mozilla.gr.jp, i shuold thank for justdave‘s help. I’ve once tried to check out seamonkeyproject-org from /cvsroot. As a comment by justdave on irc,

justdave> :pserver:anonymous@cvs-mirror.mozilla.org:/www
justdave> I think the module name is seamonkeyproject-org
justdave> http://bonsai-www.mozilla.org/ should tell you (click Browse on the top right)

we can get the repository path from bonsai site. (incl. repository path and module name, too)

The ‘releases’ pages of the seamonley.mgj site will be changed into html pages based on perl TT. (Of cource, after the prepareation of seamonkey-ja peoples)

For the planet of mozilla-gumi members, please refer bug-jp bug 5865 for details. This is (might be?) a first planet site for mozilla-gumi, and queries blogs of proposed members.

(Sorry, all links to mozilla.gr.jp sites are only in Japanese. :p)

I had something difficults to work Bugzilla 3.2 (tested w/ 3.1.3+) on Debian etch.

# ./checksetup.pl
* This is Bugzilla 3.1.3+ on perl 5.8.8
* Running on Linux 2.6.18-5-686 #1 SMP Tue Dec 18 21:24:20 UTC 2007

Checking perl modules…
Checking for CGI (v2.93) ok: found v3.15
Checking for TimeDate (v2.21) ok: found v2.22
Checking for PathTools (v0.84) ok: found v3.12
Checking for DBI (v1.41) ok: found v1.53
Checking for Template-Toolkit (v2.15) found v2.14
Checking for Email-Send (v2.00) ok: found v2.181
Checking for Email-MIME-Modifier (any) ok: found v1.440

Checking available perl DBD modules…
Checking for DBD-Pg (v1.45) not found
Checking for DBD-mysql (v4.00) found v3.0008
Checking for DBD-Oracle (v1.19) not found

The following Perl modules are optional:
Checking for GD (v1.20) ok: found v2.34
Checking for Chart (v1.0) ok: found v2.4.1
Checking for Template-GD (any) ok: found v1.56
Checking for GDTextUtil (any) ok: found v0.86
Checking for GDGraph (any) ok: found v1.4308
Checking for XML-Twig (any) ok: found v3.26
Checking for MIME-tools (v5.406) ok: found v5.420
Checking for libwww-perl (any) ok: found v2.033
Checking for PatchReader (v0.9.4) not found
Checking for PerlMagick (any) ok: found v6.2.4
Checking for perl-ldap (any) not found
Checking for SASL-Authen (any) ok: found v2.10
Checking for RadiusPerl (any) not found
Checking for SOAP-Lite (any) ok: found v0.69
Checking for HTML-Parser (v3.40) ok: found v3.55
Checking for HTML-Scrubber (any) ok: found v0.08
Checking for Email-MIME-Attachment-Stripper (any) not found
Checking for Email-Reply (any) not found
Checking for mod_perl (v1.999022) ok: found v2.000002
Checking for CGI (v3.11) ok: found v3.15

I’m considering to make some .deb repos (due to this). (Of cource, including for my own joe :p)

今年もGoogle SoCの季節がやってきました。

関係者には、各プロジェクトのマネージャー(?)から通知が回っている(ブレーンストーミングが進んでいる)と思いますが、なにか、こういう機能がほしいと思ってるんだよっ！という人は提案してみてはいかがでしょうか。wiki.moのページでいきなり出すよりも、それぞれのニュースグループで出したほうがいいとは思いますが。。

採用条件は、提案にプロジェクトでそれなりの実績のある(?)メンターが割り当てられていること、最終的なSoCでの判定に合格すること、あたりでしょうか。Google側へのOSSからの提案の締め切りが、3/12と近いので、早めに言いましょう。（笑

学生だったら自分で提案して、誰かメンターを割り当ててもらって、自分でSoCに応募するのもありなのかな・・・？(ちゃんと読んでませんが)
わたしの出したのはほぼ提案されそうな状況だったりするけど（笑

Bugzilla 3.2のja-l10nですが、始めます。
参加ご希望の方は、希望svnアカウント名とgoogle docsのアカウント名(メールアドレス)を明記の上、メールください。(もじら組の組員はアカウント名は不要です。)ちょっと技術的にどうやるかをまったく考えてない、という点があり、レポジトリはまだ準備してませんが、svnに全部突っ込んで更新していく、という形にする予定です。
Bugzillaのスケジュール的には、来週月曜日にBUGZILLA-3_2rc1タグを打って、BUGZILLA-3_2-BRANCHができるはずの予定です。
ちょっと、ドキュメント周りと、テンプレート周りで、結構影響が大きそうなblockerバグが残っていた気はしますが(わたしもいくつか抱えてたような気はしますが、、)、とりあえず、なんらかの方法で、マージできるはずだと思います。

すでにお知らせしましたとおり、今年のOSC Kyotoは以下の日程・会場で開催ることとなっております。

• 日程 : 2008/07/18 – 19 (金・土)
• 場所 : 京都コンピュータ学院京都駅前校 (昨年と同じです)

これのキックオフミーティングを、以下の日程で開催いたします。

• 日程 : 2008/03/11 (Tue) 18:00 – (19:30?)
• 場所 : 京都コンピュータ学院京都駅前校 (開催会場と同じです)

ご参加いただける方は、ご連絡いただけると助かります。(特に出欠を取るわけではないですが、、、おおまかな人数把握のためなど)なお、日程が合わなくて参加できない、という方で、何か OSC Kyoto の内容について、ご意見があります方は、事前にご連絡いただければと思います。
キックオフミーティングに関する問い合わせは、わたしのほうに投げていただければできる限り対応させていただくつもりではありますが、返信がすぐに来ることはあまり期待しないでください。
# 1-2が東京、5が名古屋、6が岐阜、、などなどでメールをちゃんとフォローできてません。
2回目、ということもあり、前回の経験を生かして、京都関西)関係のメンバーでできるだけ運営できれば、と考えておりますので、皆様の積極的なご参加をお願いいたします。

forwardとprocmail関係で少しもめた(?)のでメモ。

“|IFS=’ ‘ && exec /usr/bin/procmail -Yf- || exit 75 #username”
“|exec /usr/bin/mailfilter | /usr/bin/procmail -Yf- || exit 75”

などなどの違いと意味について。以下、smtpdの中身の議論の際は、postfixのみを想定。

1. IFSって何

IFS = Internal Field Separatorの略

bashなどのシェルでの引数展開の際の参照変数(環境変数？)となる。で、変更するとセキュリティー問題を引き起こす、という警告をどこかのマニュアルで見たような。

2. そもそも||とか&&って何

|| : 前のコマンドの終了ステータスが0でない(異常終了)のときに実行
&& : 前のコマンドの終了ステータスが0のときに実行

ということで、普通のシェルを実行するときのと同じですな。どちみち、forwardを解釈するlocalは、global/pipe_commandに投げるので、fork/execするだけだったりしますが。場所としてはlocal/deliver_command()関数。

3. exit 75は？

posix shellでのexitステータスコード75は、EX_TEMPFAILで、一時エラーを意味する。まぁ、もう一度実行したら成功するかもねぇ～、と、呼び出しもとのコマンドにいう、という感じ。

/usr/include/sysexits.h:#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */

localでは、投げつけたコマンドからの戻り値などは、global/pipe_commandの最後でPIPE_STAT_*になったものを受け取って判断する、ので、終了ステータスがどう反映されるかは、ここを見る必要がある。

4. 最後の #username

大昔のsendmailでは、これをつけておかなければ、というか、.forwardの中身が同じ場合に、ユーザの区別がつかなくなる、というバグが存在したバージョンもあった。らしい。(けど、遭遇したことはない。)

なので、今は不要。

まぁ、mail.infoとかのログには出るから(ほかのコマンド部分と一緒に)、管理者が障害追跡するときには使える？って、そんなところを見るくらいなら、普通にmail idとかで追跡したほうが早いと思うけど。。

5. execつけるかつけないか

通常の意味でのfork/execでの動作と同じなんでしょうね。

“| exec xxxx”にしておけば、|で起動されたシェル(?)がそのままxxxxをexecするのでプロセスは新規に作らなくていい、という利点がある。まぁ、なくてもあってもfork分を除いたら動作は同じなので、、どちらでも、という気はする。

わからなければ、新しくターミナルを起動して*から* (←重要)、”exec ls”とか、”exec ls -a | ls”とかを実行してみるとわかると思う。たぶん。

大量にメールを処理するサーバだと困るよね、というけど、copy-on-writeだから昔ほどではないでしょうし。。(かといって、入れないのを推奨するわけではないが。)

I’m using the google calendar for managing my schedule, so you can view my schedule on the web.

for my memo. :-)