You are currently browsing the archives.

May 2, 2011

Bugzilla 4.1.2, 4.0.1, 3.6.5, 3.4.11 リリースのお知らせ

Bugzilla 4.0.1, 3.6.5, 3.4.11 と非安定開発版スナップショットである 4.1.2をリリースしました。

さまざまなユーザに “Math::Random::Secure” ライブラリに関連したバグの影響で、Bugzilla 4.0, 3.6.4, 3.4.10 のインストールで問題が発生していました。この問題は他の問題と同じくこのリリースで修正されています。

なお、4.1.2 は非安定開発版リリースであり、実運用環境では利用すべきでないリリースです。しかしながら、4.2 のフリーズまで非常に近いところまできておりますので、4.1.2 を利用して以前のリリースから動作が大きく変わった点についてのフィードバックをお待ちしております。

ダウンロード

Bugzilla のダウンロードはダウンロードページから行えます。

日本語版については、日本語版テンプレートパックをご利用ください。
ご利用のバージョンのリリースアーカイブを解凍後、template/ja ディレクトリにファイルを (template/en ディレクトリと同様に) 配置して checksetup.pl を実行してください。

リリースノートと変更点

インストールやアップグレードの前に、利用しているバージョンのリリースノートをご覧ください。

日本語版は、日本語版テンプレートの中に含まれます。ウェブページ形式のものは、landfill をご覧ください。(なお、最新版により更新されます。)

メジャーバージョン間のアップグレードを行う場合、リリースノートを読んでいただくことが重要です(3.4.x から 3.6.x など)。

あなたのバージョンから現在の最新版の間のすべての変更点のリストもあります。

Bugzilla 更新情報

Bugzilla プロジェクトからの最新ニュースや最新の開発版についての情報は、Bugzilla Updateにもあります。(英語)

また、4.1.2 での新機能や将来のプランについてはこちらのエントリをご覧ください。

ツイッター

また、Bugzilla プロジェクトでは Bugzilla での開発中の新機能やリリースプランなどについてより頻繁に情報をお届けするために Twitter アカウントを開設しました。ぜひともフォローしてください。(英語)

バグ報告

Bugzilla にバグを発見した場合、報告してください!

日本語でのバグ報告は、bugzilla@jpmozまでお願いします。

サポート

Bugzilla に関する、英語のメーリングリストや IRC もあります。もしくは、有償サポートを提供するコンサルタントも存在します。

日本語でのメーリングリストなどユーザ相互サポートの場は現在準備中です。IRCチャネル (utf-8)はご利用になれます。

Bugzilla とは

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” です。欠陥追跡システムでは、開発者個人やグループが、製品に存在するバグを効率よく追跡することができます。通常の商用欠陥追跡システムでは費用がかかります。Bugzilla は、”フリー”でありながら、そのような商用システムが持っていないような機能もあります。その結果、Bugzilla は全世界にわたる数千もの組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。

詳細は http://www.bugzilla.org/about/ をご覧ください。

原文:  -Max Kanat-Alexander / Release Manager, Bugzilla Project
日本語版: bug-ja.org
Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




February 16, 2011

Bugzilla 4.0 リリースのご案内

Bugzilla プロジェクトでは、Bugzilla の3年越しになるメジャーリリースである、Bugzilla 4.0 を公開 (アナウンス)、bug-ja.org では 4.0 に対する日本語化テンプレートを公開いたしました。

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” と呼ばれるソフトウェアです。”フリー”でありながら商用システムでも提供されない機能も提供していることから、Mozilla以外でもRedHatNASA PRACA (アナウンス; 日本語)などをはじめとする全世界のさまざまな組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。


Bugzilla プロジェクトは、われわれの歴史の中においてもっとも心躍るバージョンである Bugzilla 4.0 をリリースしたことを大いなる誇りを持ってお知らせいたします。

Bugzilla 3.6 を元として、Bugzilla 4.0 では以下のようなさまざまなすばらしい新機能の追加やユーザインターフェースの改善を行いました。

  • 完全に再デザインされた高度な検索ページ
  • バグ登録時の自動重複検出機構
  • ユーザ名やメールアドレスを入力する全てのフィールドに対するドロップダウン式自動補完機能
  • ウェブサービス経由での、既存バグの更新を含めたバグの全ての更新・取得
  • J. Pink Design によるホームページのアイコンの更新
  • さまざまな使い勝手の改善
  • もっとさまざまな新機能についてはウェブサイト (日本語版)を参照してください

2007 年にリリースしました Bugzilla 3.0 と比較して、Bugzilla 4.0 は荒削りだった部分が全て磨かれたかのように非常に大きな飛躍であり、非常に多数の新機能が提供され、ほとんど全てのユーザインターフェースが更新され改善されました。

Bugzilla 4.0 はこれまでで最高のリリースであり、誰もがリリースを享受し、そして過去数ヶ月のボランティアのみのコミュニティーの努力を高く評価してもらえるものと思っております。

なお、Bugzilla 4.0 のリリースに伴い、Bugzilla 3.2 シリーズは終了となる、つまりこれ以降 3.2.x シリーズへのセキュリティー更新を含む全ての更新が行われないことを再度明記しておきます。全ての 3.2 シリーズを運用している管理者に大して、4.0 に可能な限り早くアップグレードすることを推奨いたします。

ダウンロード

Bugzilla のダウンロードはダウンロードページから行えます。

日本語版については、日本語版テンプレートパックをご利用ください。
ご利用のバージョンのリリースアーカイブを解凍後、template/ja ディレクトリにファイルを (template/en ディレクトリと同様に) 配置して checksetup.pl を実行してください。

リリースノートと変更点

インストールやアップグレードの前に、利用しているバージョンのリリースノートをご覧ください。

日本語版は、日本語版テンプレートの中に含まれます。ウェブページ形式のものは、landfill をご覧ください。(なお、最新版により更新されます。)

メジャーバージョン間のアップグレードを行う場合、リリースノートを読んでいただくことが重要です(3.4.x から 3.6.x など)。

あなたのバージョンから現在の最新版の間のすべての変更点のリストもあります。

Bugzilla 更新情報

Bugzilla プロジェクトからの最新ニュースや最新の開発版についての情報は、Bugzilla Updateにもあります。(英語)

ツイッター

また、Bugzilla プロジェクトでは Bugzilla での開発中の新機能やリリースプランなどについてより頻繁に情報をお届けするために Twitter アカウントを開設しました。ぜひともフォローしてください。(英語)

バグ報告

Bugzilla にバグを発見した場合、報告してください!

日本語でのバグ報告は、bugzilla@jpmozまでお願いします。

サポート

Bugzilla に関する、英語のメーリングリストや IRC もあります。もしくは、有償サポートを提供するコンサルタントも存在します。

日本語でのメーリングリストなどユーザ相互サポートの場は現在準備中です。IRCチャネル (utf-8)はご利用になれます。

Bugzilla とは

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” です。欠陥追跡システムでは、開発者個人やグループが、製品に存在するバグを効率よく追跡することができます。通常の商用欠陥追跡システムでは費用がかかります。Bugzilla は、”フリー”でありながら、そのような商用システムが持っていないような機能もあります。その結果、Bugzilla は全世界にわたる数千もの組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。

詳細は http://www.bugzilla.org/about/ をご覧ください。

原文:  -Max Kanat-Alexander / Release Manager, Bugzilla Project
日本語版: bug-ja.org
Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




January 26, 2011

Bugzilla 3.2.10, 3.4.10, 3.6.4, 4.0rc2 リリースのご案内

Bugzilla プロジェクトでは、Bugzilla のセキュリティー更新版 3.2.10, 3.4.10, 3.6.4, 4.0rc2 を公開、bug-ja.org では 3.4.10, 3.6.4, 4.0rc2 に対する日本語化テンプレートを公開いたしました。

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” と呼ばれるソフトウェアです。”フリー”でありながら商用システムでも提供されない機能も提供していることから、Mozilla以外でもRedHatNASA PRACA (アナウンス; 日本語)などをはじめとする全世界のさまざまな組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。


いくつかの深刻なセキュリティー問題が Bugzilla に発見されたため、4つのセキュリティー更新版をリリースしました。全ての Bugzilla 管理者に対し、このリリースとともに公開されたセキュリティーアドバイザリをよく読み、できる限り早くアップデートを行うことを推奨いたします。

Bugzilla 4.0rc2 は Bugzilla 4.0 の二つ目のリリース候補版です。このリリースは QA テストを経ていますので、以前の開発版リリースよりも安定していると考えられます。しかしながら、完全に安定しているとはいえないため、利用する際にはリスクがあることをご了解ください。

日本語版については、bug-ja.orgのlandfillで試験できます。

このリリース候補版へのフィードバックより、リリースが安定しているといえる状況であれば Bugzilla 4.0 は数週間でリリースされます。しかしながら、より大きな修正が必要と考えられる場合は、このあともリリース候補版がリリースされる可能性もあります。

Bugzilla 3.6.4 は最新の安定板リリースです。3.6 ブランチでのいくつかの有用なバグ修正やセキュリティー更新が行われています。このバージョンが 3.6 シリーズの最後のバグ修正となる可能性があります。Bugzilla 4.0 リリース後は、3.6 シリーズにはセキュリティー修正しか行われなくなります。

Bugzilla 3.4.9 と 3.2.9 は 3.4, 3.2 ブランチそれぞれのセキュリティー更新です。

リマインダーとしてのご案内ですが、Bugzilla 4.0 のリリースに伴い、Bugzilla 3.2.x シリーズは終了となります。これは、今後 3.2.x についてはセキュリティー問題に対する更新も含め、どのようなアップデートも行われないことを意味します。3.2.x シリーズを運用中の方は、今すぐ 3.6.x もしくは (リリースされれば) 4.0 にアップグレードすることを強くお勧めします。

なお、bug-ja.org では Bugzilla 3.2 シリーズへの更新版の提供はすでに終了させていただいておりますのでご了承ください。

ダウンロード

Bugzilla のダウンロードはダウンロードページから行えます。

日本語版については、日本語版テンプレートパックをご利用ください。

リリースノートと変更点

インストールやアップグレードの前に、利用しているバージョンのリリースノートをご覧ください。

日本語版は、日本語版テンプレートの中に含まれます。ウェブページ形式のものは、landfill をご覧ください。(なお、最新版により更新されます。)

メジャーバージョン間のアップグレードを行う場合、リリースノートを読んでいただくことが重要です(3.4.x から 3.6.x など)。

あなたのバージョンから現在の最新版の間のすべての変更点のリストもあります。

Bugzilla 更新情報

Bugzilla プロジェクトからの最新ニュースや最新の開発版についての情報は、Bugzilla Updateにもあります。(英語)

また、Bugzilla プロジェクトでは Bugzilla での開発中の新機能やリリースプランなどについてより頻繁に情報をお届けするために Twitter アカウントを開設しました。ぜひともフォローしてください。(英語)

バグ報告

Bugzilla にバグを発見した場合、報告してください!

日本語でのバグ報告は、bugzilla@jpmozまでお願いします。

サポート

Bugzilla に関する、英語のメーリングリストや IRC もあります。もしくは、有償サポートを提供するコンサルタントも存在します。

日本語でのメーリングリストなどユーザ相互サポートの場は現在検討中です。IRCチャネル (utf-8)はご利用になれます。

Bugzilla とは

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” です。欠陥追跡システムでは、開発者個人やグループが、製品に存在するバグを効率よく追跡することができます。通常の商用欠陥追跡システムでは費用がかかります。Bugzilla は、”フリー”でありながら、そのような商用システムが持っていないような機能もあります。その結果、Bugzilla は全世界にわたる数千もの組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。

詳細は http://www.bugzilla.org/about/ をご覧ください。

原文:  -Max Kanat-Alexander / Release Manager, Bugzilla Project
日本語版: bug-ja.org
Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




January 13, 2011

Firefox 4: Path to Shipping

dev-planningへのポストより。

Firefox 4に向けて途方もない労力を傾けてきましたが、ついにリリースが近づきました。これまでのどのリリースでもそうでしたが、その大詰めには激しい興奮と動きがおこります。ここ数日間、コンポーネントの責任者はブロッカーから解決なしにはリリースできない”hard blocker”を抽出し、そしてそれらをさらに解決してきました。あとのこり160個程度の”hard blocker”が残っていますが、これまでの経験からいうと100個のブロッカーが残っているとRCまで6週間位かかっています。われわれはより努力せねばなりません。

終わらせるには:

1) RCステータスにできる限りは焼く到達する必要があります。理想的には、2月はじめまでに”hard blocker”をなくし、2月終わりまでにリリースすることが目標です。これらのターゲットまでに、より高品質なプロダクトを完成させるためにはあなたの助力が必要です。

2) 現在のバグの数からいうともう一つbetaが必要でしょう。ベータバグをすべて解決し、もう一度betaを出す必要があります。それなりの時期までにゼロにできなければ、さらにもう一度繰り返すことになります。これは、ベータ版からのフィードバックが必要とされる”hard blocker”のリストをどこまで早く解決できるかによります。これからのスケジュールを決める要因であるため、この点がわれわれの目下の最大の開発目標です。

3) *皆さんに*テストに協力してもらいたいです。特に、Flash, Silverlight, やその他のメジャーなプラグインを無効にしないで、できる限り多くの方にテストをしていただきたいです。Windows ユーザについては、ハードウェアアクセラレーションによりクラッシュや他の問題が発生していないかを確認してください。誰かがすでに報告しているだろうとは考えないでください。必ず報告してください。もしくはやり方が分からなければ誰かにきいてください。これは非常に重要な点です。

もっとも大事なことは: われわれはできる限りよい製品をリリースしようとしています。ブロッカーの解決により時間が必要なら、リリースドライバーやコンポーネントの責任者にすぐさま連絡してください。もし、(締め切りなどの)コールに同意できない場合、大声で叫んでください。この点で決して臆病にならないでください。これは、あなたのプロダクトでもあり、あなたも関係すべきことです。

もちろん、皆さんが疲れ果て悩んでいることは承知しています。あなた方は毎日途方もない成果を示し、すばらしいプロダクトを作り上げていっています。気を抜かないでください。お互いに闘わずやっていきましょう。Firefox 4はもうすぐリリースです。そして、皆さんは成果を大いに誇りに思うことでしょう。

以下、メモ。

Comments Comments | Categories: ja, mozilla | Autor: himorin




December 3, 2010

今月のbugzilla関係の予定

今月の予定されているイベントのリスト

  • 12/12 (PST) : Bugzilla 4.0 (RC2が必要なければ)
  • 12/15 (PST 19:00) : Users & Administrators Group Meeting (オフライン、@US)

日本語関係では、bugmailの新仕様についての意見・コメント募集中です。
bug #103 bugzilla bugmail仕様変更についての日本語扱い関係の仕様提案に議論・コメントをポストしてください。

Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




November 4, 2010

Bugzilla 4.0rc1, 3.6.3, 3.4.9, 3.2.9 リリースのご案内

Bugzilla の新バージョンのリリース候補版と新しいリリースを公開したことをお知らせします。Bugzilla 4.0 に向けてのリリース候補版 (4.0rc1)、一つの安定版リリース (3.6.3)、二つのセキュリティー更新のみのリリース (3.4.9, 3.2.9; 3.2.9 は日本語版はありません) です。

Bugzilla 3.7.3 は Bugzilla 4.0 に向けた開発版の3つ目の非安定開発版リリースです。このリリースでは、ある程度の QA テストが行われています。しかしながら、たくさんの未解決のバグが QA によって発見されており、実運用環境で利用することはお勧めしません。開発版リリースは、次期メジャーリリースで導入される新機能を試すためのものです。また、さまざまなユーザに試してもらうことで、バグ報告や機能に関するフィードバックを受け付けることを目的としていますので、この開発版にバグを発見された場合(や、何らかの新機能の動作に不満がある場合)には是非とも報告してください。

日本語版については、bug-ja.orgのlandfillで試験できます。

Bugzilla 4.0rc1 は Bugzilla 4.0 の最初のリリース候補版です。このリリースはQA テストを経ていますので、以前の開発版リリースよりも安定していると考えられます。しかしながら、完全に安定しているとはいえないため、利用する際にはリスクがあることをご了解ください。特に、ウェブサービスの特定の機能はリリース候補版の試験の面が大きいですので、最終リリースまでに変更が入る可能性があります。

このリリース候補版へのフィードバックより、リリースが安定していることが判明した場合は Bugzilla 4.0 は数週間でリリースされます。しかしながら、より大きな修正が必要な場合このあともリリース候補版がリリースされる可能性もあります。

Bugzilla 3.6.3 は最新の安定板リリースです。3.6 ブランチでのいくつかの有用なバグ修正やセキュリティー更新が行われています。

Bugzilla 3.4.9 と 3.2.9 は 3.4/3.2 ブランチそれぞれのセキュリティー更新です。

リマインダーとしてのご案内ですが、Bugzilla 4.0 のリリースに伴い、Bugzilla 3.2.x シリーズは終了となります。これは、今後 3.2.x についてはセキュリティー問題に対する更新も含め、どのようなアップデートも行われないことを意味します。3.2.x シリーズを運用中の方は、今すぐ 3.6.x もしくは 4.0rc1 にアップグレードすることを強くお勧めします。

ダウンロード

Bugzilla のダウンロードはダウンロードページから行えます。

日本語版については、日本語版テンプレートパックをご利用ください。

リリースノートと変更点

インストールやアップグレードの前に、利用しているバージョンのリリースノートをご覧ください。

日本語版は、日本語版テンプレートの中に含まれます。ウェブページ形式のものは、landfill をご覧ください。
4.0rc1 のリリースノート日本語版については、セキュリティー更新優先し、後日公開する予定です。

メジャーバージョン間のアップグレードを行う場合、リリースノートを読んでいただくことが重要です(3.4.x から 3.6.x など)。

あなたのバージョンから現在の最新版の間のすべての変更点のリストもあります。

Bugzilla 更新情報

Bugzilla プロジェクトからの最新ニュースや最新の開発版についての情報は、Bugzilla Updateにもあります。(英語)

また、Bugzilla プロジェクトでは Bugzilla での開発中の新機能やリリースプランなどについてより頻繁に情報をお届けするために Twitter アカウントを開設しました。ぜひともフォローしてください。(英語)

バグ報告

Bugzilla にバグを発見した場合、報告してください!

日本語でのバグ報告は、bugzilla@jpmozまでお願いします。

サポート

Bugzilla に関する、英語のメーリングリストや IRC もあります。もしくは、有償サポートを提供するコンサルタントも存在します。

日本語でのメーリングリストなどユーザ相互サポートの場は現在検討中です。IRCチャネル (utf-8)はご利用になれます。

Bugzilla とは

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” です。欠陥追跡システムでは、開発者個人やグループが、製品に存在するバグを効率よく追跡することができます。通常の商用欠陥追跡システムでは費用がかかります。Bugzilla は、”フリー”でありながら、そのような商用システムが持っていないような機能もあります。その結果、Bugzilla は全世界にわたる数千もの組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。

詳細は http://www.bugzilla.org/about/ をご覧ください。

原文:  -Max Kanat-Alexander / Release Manager, Bugzilla Project
日本語版: bug-ja.org
Comments Comments Off on Bugzilla 4.0rc1, 3.6.3, 3.4.9, 3.2.9 リリースのご案内 | Categories: Bugzilla, ja, mozilla | Autor: himorin




October 13, 2010

Bugzilla meeting 2010/10 メモ

03:10 pyrzak> ./checksetup --start-meeting
03:11 LpSolit> ok, agenda: https://wiki.mozilla.org/Bugzilla:Meetings

Agenda

  1. Bugzilla 4.0に向けたロードマップ
  2. 4.0rc1 に向けたブロッカーバグの確認と、ETAどうするか
  3. 最近の開発貢献者数が少なく感じるが、4.2ではどうやって広げる?
  4. 4.2向けのロードマップを11月のミーティングで議論するか?もしくはメインのゴールは何?
    • (LpSolit) OS/Platformなどを隠すといった利用者からの要望を実装もしくはサポート
  5. ミーティングの方式を再検討する? (方法、頻度)
  6. 主要開発者の当面の課題
  7. Mozilla module ownership の管理変更に伴う対応

memo

  • ロードマップ
    • そもそも3.0や3.2以降どの程度有効であったか?今後も必要か?
      • ロードマップよりも機能要望リストの方が有用ではないか
      • 次期リリースへ向けて実装しようとする機能を選択するのに有用
      • 機能の選択は担当者@bugzillaではだめなのか?
    • ミーティングをだいぶサボっていたのでロードマップの有用性が落ちた可能性
    • 4.x向けには大改定が必要だ
      • P1/P2のバグを自動的に抜き出すなどのシステムにするのはどうか
      • 静的ページが望ましいと思うが、MWのプラグインで何とかならないか?
      • いくつかの何年もリストされているバグが問題 (邪魔)
    • そもそもロードマップの意義は
      • 機能ベースのリリースに戻ることはない。時間ベースのリリースはうまく動いている (mkanat)
      • 実際に開発者が活動するようなターゲットリストにすべきでは (LpSolit)
      • リリース時にはblockerの機能を利用している
      • ホワイトボードに[roadmap]をつけることにする? : 既にやっている
      • ロードマップに”実装したいと考えられている機能”というタイトルをつけるのは? (pyrzak)
    • [roadmap]をホワイトボードに入れ、P1/P2を本当に重要なものにつける
  • ダウンロード数 – 2010/08/05以降
    • 3.7.3: 9868
    • 3.6.2: 57342
    • 3.4.8: 1444
    • 3.2.8: 1340
  • Module ownerへの追随
  • 4.0rc1 に向けたブロッカーの確認
    • https://bugzilla.mozilla.org/buglist.cgi?quicksearch=flag%3Ablocking4.0%2B
      • bug 581933 : Username autocomplete doesn’t work outside ASCII
      • bug 591535 : “Give me some help” link’s iframe behavior is no longer necessary
      • bug 490322 : “contains all of the words” (allwords) searches on keywords don’t work in Bugzilla 3.6
      • bug 577053 : Upgrading from 2.18 or earlier fails with the new status workflow patch
    • 4.0rc1 ETA : 2010/10/19
  • 最近の開発貢献者数が少なく感じるが、4.2ではどうやって広げる?
    • 過去と比べて実際のアクティブ数はそんなに少なくないように思える
  • 4.2へのロードマップを次回議論するかどうか、4.2でのメインの目標はどうする?
    • ユーザが望んでいる機能のサーベイ https://wiki.mozilla.org/Bugzilla:Survey
  • ミーティングの頻度・方式
    • テレコン・パワポが欲しい (pyrzak)
    • 2ヵ月ごと? (LpSolit)
    • 次回を12月にして、4.2向けロードマップの議論をする
  • 主要開発者の当面の課題
Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




October 7, 2010

HTML5-WEST.jp 主催のHTML5セミナー企画@KOFのご案内

HTML5-WEST.jp は関西圏を中心として、HTML5の知名度をより高め新しいウェブプラットフォームを普及していくために、各種の勉強会やさまざまなオープンソース系イベント内でのセミナー企画を継続的に行っております。

このたび、第1回目となった今年7月のOSC 2010 Kansai@Kyotoでの第1回セミナー企画に引き続き、11月5-6日に大阪南港のATCで開催されるKOFにおいて、第2回のセミナー企画を開催します。

第1回の企画では、そもそもHTML5とは何かというところから近未来のウェブプラットフォームの可能性を感じてもらうことを目標に開催いたしました。そこで、続編となる今回はウェブプラットフォームの中で最も重要な位置を占めるウェブブラウザ、そしてその中核をなすレンダリングエンジンのベンダー各社さま — Google, Microsoft, Mozilla Japan, Opera をお招きします。

今回は、さまざまなイベントで質問されることが多い、開発の際に必要とされているものにフォーカスをあて、HTML5を実際の開発やウェブデザインに活用しようとしているウェブ開発者、デザイナのみなさま向けにお届けいたします。単に各社がどうHTML5やその関連技術を捉え、実装しているかにとどまらず、レンダリングエンジンのベンダーとして提供している開発用ツール、ドキュメント、デモを交えて、実際に活用できるHTML5を実感し、すぐにでも実務に活用していただけることを目標としています。

2日間にわたって、ベンダー4社によるセミナーと、HTML5-WEST.jp主催のセミナー2つの、合計6つのセミナー(詳細は後ろ)を開催いたします。どうぞご期待ください。

  • KOFではセミナー受講予約制をとっておりません。当日直接セミナー会場までお越しください。
  • 本文中の社名などはアルファベット順です。
  • 6日11時からのパネルディスカッション企画が確定しましたので追記しました (10/21)

事前アンケートおよび会場でのアンケート

パネルディスカッション企画の事前アンケートを行っています。実のあるパネルディスカッションにするため、ぜひともご回答ください。

また、セミナー会場でこのセミナー企画についてのアンケート用紙をお配りいたします。ご記入後、6F展示会場内Kyoto GTUGのブースまでお持ちいただけますと、ベンダー各社様よりご提供のグッズをお渡しいたします。こちらの方も、ぜひともご協力くださいませ。


セミナー一覧

ついに登場!Internet Explorer 9 (Microsoft)

  • 日時 : 11/5 15:00
  • 講師名 : 春日井 良隆 (マイクロソフト株式会社)
  • タイトル : ついに登場!Internet Explorer 9
  • 概要 : 日本時間の9月16日、Internet Explorerの最新版、Internet Explorer 9 Beta版が発表になりました。HTML5やCSS3への対応、GPU-Powered HTML5と呼んでいるGPUアクセラレーションのパワー、新設計のJavaScriptエンジンといったWeb標準に関わる機能から、Windows 7に最適化されたピンドモードやジャンプリストといった新機能など、IE9の魅力をご紹介します。

HTML.next の世界に備えよう (Mozilla Japan)

  • 日時 : 11/5 17:00
  • 講師名 : 浅井 智也 (Mozilla Japan テクニカルマーケティング)
  • タイトル : HTML.next の世界に備えよう
  • 概要 : HTML5によってWebの世界が変わると言われていますが、実際のところ何がどう変わるのでしょう?タブレットやスマートフォンへの対応も求められる中、Web開発者はどう対応してゆけばよいのでしょう?このセミナーでは、これからのWeb開発に役立つツールやドキュメント、Firefox4の新技術などを見ながら、Web開発者がHTML.nextにどう対応してゆくべきか考えてみようと思います。

HTML5 ~ ウェブの未来のためにいま何が必要なのか

  • 日時 : 11/6 11:00
  • 担当 : HTML5-WEST.jp / 参加ベンダー : Microsoft, Mozilla Japan, Opera Software
  • タイトル : HTML5 ~ ウェブの未来のためにいま何が必要なのか
  • 概要 : これからより普及すると考えられているウェブアプリケーション、その基盤となるHTML5に対して、各ベンダーの中の人はどういう思いでHTML5にかかわろうとしているのか。また将来のウェブの姿はどうなっていくだろうと思っているのか、そしてその思いに対していま何をすべきか、その思いを実現し、より普及させていくには実際の利用者・ウェブ開発者に対してどういったサポート — 開発用リファレンス、機能紹介のデモ、そして開発ツールなど — が必要なんだろうか。こうした点について、ブラウザの中核となるレンダリングエンジンのベンダーが激論を交わします。

Openなウェブ標準:進行状況 (Opera Software)

  • 日時 : 11/6 14:00
  • 講師名 : Daniel Davis (Opera Software)
  • タイトル : Openなウェブ標準:進行状況
  • 概要 : オープンな標準はオープンソース活動の重要な一部。チャットプロトコル、暗号化アルゴリズム、ビデオフォーマットなど、全てがオープンであれば開発者は自由にツールの作成ができるでしょう。ウェブもそのはずだと Opera は信じています。次世代のウェブアプリケーション、最高のウェブ体験を提供するため、オープンなウェブ標準の基礎が必要です。その基礎の作成はどこまでできているでしょうか。次のチャレンジはどこになるでしょうか。 (講演は日本語です)

Chrome Extension/WebAppsにおけるHTML5の活用 (Google)

  • 日時 : 11/6 16:00
  • タイトル : Chrome Extension/WebAppsにおけるHTML5の活用
  • 講演者 : 北村英志 (Google Developer Advocate)
  • 概要 : ウェブアプリケーションはHTML5の実現と共に、よりリッチかつ高機能なものへと進化してきました。本講演では、ChromeブラウザにおけるExtensionやWebAppsの紹介と共に、HTML5をどのように活用することができるのか、デモアプリとその実装方法を交えてご紹介いたします。

HTML5 ~ その可能性とインターネットアプリケーションの未来

  • 日時 : 11/6 17:00
  • 担当 : HTML5-WEST.jp
  • タイトル : HTML5 ~ その可能性とインターネットアプリケーションの未来
  • 概要 : これから広範囲に普及していくと予想される、ウェブアプリケーションプラットフォームの基盤としてのHTML5、このセミナーではその実際に迫ります。バズワードとして幅広い技術をまとめる形で語られれることもあるHTML5とは、実際にはどういうもので、そしてプラットフォームとしてどういうことができるのかを、HTML5-WEST.jpのイベントといえばこれ、ともいうべきデモやライブコーディングを通じてご紹介いたします。
Comments 3 Comments | Categories: ja, mozilla, tech | Autor: himorin




August 11, 2010

Bugzilla/Bugzilla-ja 3.7.3, 3.6.2, 3.4.8, (3.2.8) リリースのお知らせ

Bugzilla の新しいリリースを公開しました。

一つの開発版スナップショット (3.7.3)、一つの安定版リリース (3.6.2)、二つのセキュリティー更新 (3.4.8, 3.2.8; 3.2.8は日本語版はありません) です。

Bugzilla 3.6.2 は最新の安定板リリースです。3.6 ブランチでのいくつかの有用なバグ修正やセキュリティー更新が行われています。

Bugzilla 3.4.8 と 3.2.8 は 3.4/3.2 ブランチそれぞれのセキュリティー更新です。

Bugzilla 3.7.3 は Bugzilla 4.0 に向けた開発版の3つ目の非安定開発版リリースです。このリリースでは、ある程度の QA テストが行われています。しかしながら、たくさんの未解決のバグが QA によって発見されており、実運用環境で利用することはお勧めしません。開発版リリースは、次期メジャーリリースで導入される新機能を試すためのものです。また、さまざまなユーザに試してもらうことで、バグ報告や機能に関するフィードバックを受け付けることを目的としていますので、この開発版にバグを発見された場合(や、何らかの新機能の動作に不満がある場合)には是非とも報告してください。

日本語版については、bug-ja.orgのlandfillで試験できます。

ダウンロード

Bugzilla は以下からダウンロードできます: download

日本語版については、日本語テンプレートパックを以下からダウンロードできます: download

リリースノートと変更点

インストールやアップグレードの前に、利用しているバージョンのリリースノートをご覧ください。

  • 3.6.2: http://www.bugzilla.org/releases/3.6.2/release-notes.html
  • 3.4.8: http://www.bugzilla.org/releases/3.4.8/release-notes.html
  • 3.2.8: http://www.bugzilla.org/releases/3.2.8/release-notes.html

日本語版は、日本語版テンプレートの中に含まれます。ウェブページ形式のものは、landfill をご覧ください。

  • 3.6.2-ja: http://landfill.bug-ja.org/ja-306/page.cgi?id=release-notes.html
  • 3.4.8-ja: http://landfill.bug-ja.org/ja-304/page.cgi?id=release-notes.html

メジャーバージョン間のアップグレードを行う場合、リリースノートを読んでいただくことが重要です(3.2.x から 3.4 など)。あなたのバージョンから現在の最新版の間のすべての変更点のリストもあります。

Bugzilla 更新情報

Bugzilla プロジェクトからの最新ニュースや最新の開発版についての情報は、Bugzilla
Update
にもあります。(英語)

バグ報告

Bugzilla にバグを発見した場合、報告してください!方法についてを参照してください。

日本語でのバグ報告は、bugzilla@jpmoz までお願いします。

サポート

Bugzilla に関する、英語のメーリングリストや IRC もあります。もしくは、有償サポートを提供するコンサルタントも存在します。

  • 無償サポート: http://www.bugzilla.org/support/
  • 有償サポート: http://www.bugzilla.org/support/consulting.html

日本語でのメーリングリストなどユーザ相互サポートの場は現在検討中です。IRC チャネル (utf-8)はご利用になれます。

Bugzilla とは

Bugzilla は、”欠陥追跡システム” や “問題追跡システム” です。欠陥追跡システムでは、開発者個人やグループが、製品に存在するバグを効率よく追跡することができます。通常の商用欠陥追跡システムでは費用がかか ります。Bugzilla は、”フリー” でありながら、そのような商用システムが持っていないような機能もあります。その結果、Bugzilla は全世界にわたる数千もの組織に利用されるようになり、もっともよく利用される欠陥追跡システムとして広く認知されています。

詳細は http://www.bugzilla.org/about/ をご覧ください。

原文:  -Max Kanat-Alexander / Release Manager, Bugzilla Project
日本語版: bug-ja.org

セキュリティーアドバイザリーサマリー

CVE-2010-2756

  • リモートからの情報漏洩 – bug 417048
  • 2.19.1-3.2.7, 3.3.1-3.4.7, 3.5.1-3.6.1, 3.7-3.7.2 で発生、3.2.8, 3.4.8, 3.6.2, 3.7.3で修正
  • 検索画面から他のユーザのグループ権限を見ることが出来ていました

CVE-2010-2757

  • セキュリティー通知のバイパス – bug 450013
  • 2.22rc1-3.2.7, 3.3.1-3.4.7, 3.5.1-3.6.1, 3.7-3.7.2 で発生、3.2.8, 3.4.8, 3.6.2, 3.7.3で修正
  • sudo操作を行った際の通知を流れなくすることが出来ていました

CVE-2010-2758

  • リモートからの情報漏えい – bug 577139, bug 519835
  • 2.17.1-3.2.7, 3.3.1-3.4.7, 3.5.1-3.6.1, 3.7-3.7.2で発生、3.2.8, 3.4.8, 3.6.2, 3.7.3で修正
  • レポート・重複を表示するページでプロダクトの存否を確認出来ていました

CVE-2010-2759

  • サービス拒否攻撃 – bug 583690
  • 2.23.1-3.2.7, 3.3.1-3.4.7, 3.5.1-3.6.1, 3.7-3.7.2 で発生、3.2.8, 3.4.8, 3.6.2, 3.7.3で修正 (PostgreSQL環境のみ)
  • 32bitの符号付整数より大きい値をもつ”bug X”, “attachment X”を含むコメントがあった場合、PostgreSQL環境ではエラーが発生します。
Comments Comments | Categories: Bugzilla, ja, mozilla | Autor: himorin




August 3, 2010

gccでのi386とamd64におけるワードアライメントの動作の違い

Linux (Debian lenny)で、メモリダンプとかsocket経由の通信とかを行うラッパライブラリを試験していて、データを突っ込む構造体の中のワードアライメントが(amd64で)思ったのと違っていることに気づいて、少し試験してみた。昔のi386の時代は、4byteごとにアライメント境界が来るからそれにあわせて、という話があったけれど、そうではない様子。

環境はDebian lennyのパッケージそのままで、次のような感じ。

@i386 (32bit)
% gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
% uname -a
Linux lenny-i386 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 GNU/Linux

@amd64 (64bit)
% gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
% uname -a
Linux lenny-amd64 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 GNU/Linux

この環境で試験できるのは、64bitバイナリ@amd64、32bitバイナリ@amd64、32bitバイナリ@i386の3つ。ひとまず、さまざまな型でのメモリ上のサイズを見る。整数型では”long”だけは64bitの実装系によって内部表現が違うとかがあるのでgccではどうか、と。

type 64bit@amd64 32bit@amd64 32bit@i386
char 1 1 1
short 2 2 2
int 4 4 4
long 8 4 4
long long 8 8 8
float 4 4 4
double 8 8 8
long double 16 16 12

ということで、”long”と”long double”のみ32/64bitでサイズが異なる。当然ながら32bitバイナリをそれぞれi386とamd64のkernelで動くLinuxに持っていっても変化はない。

次に、ワード境界がどうなるかを調べる。利用する構造体は、サイズの判定ができるように適宜charを突っ込んだ並び。それぞれはさまれているcharはサイズ1byteだがワードアライメントの影響を受けて、構造体の中の(パッディングを含む)実(?)メモリサイズは長くなるはず。

  • char a
  • short b
  • int c
  • char d
  • long e
  • char f
  • long long g
  • char h
  • float i
  • char j
  • double k
  • char l
  • long double m

というところで、32bitバイナリと64bitバイナリでの結果は次のようになった。

name type 32bit 64bit
all 64 96
b-a char 2 2
c-b short 2 2
d-c int 4 4
e-d char 4 8
f-e long 4 8
g-f char 4 8
h-g long long 8 8
i-h char 4 4
j-i float 4 4
k-j char 4 8
l-k double 8 8
m-l char 4 16

これを見ると、32bitでは4byteごとにアライメントされているのは変わっていない様子。しかしながら、64bitではその直後に来るデータの実サイズを基準にアライメントされているようにみえる。たとえば、16bitのlong doubleの開始点は16bitの整数倍のメモリから、8bitのlongの開始点は8bitの整数倍のメモリから、という感じ。(もし全てが8/16byteの固定アライメント似合うようにパディングされているなら、float/j-iの部分の数値がおかしい)

これだけなら64bit側にあわせたアライメントになるようにstructの定義部分でいじってやればいいような気はするが、ターゲットはLinuxだけではないのでさまざまな処理系での違いを吸収するような定義は面倒に思える。ということで、ライブラリの中でこの部分を吸収するコードを入れる(パフォーマンスを考えると、自動ネゴシエーションの後に違っていれば吸収するコードにフォールバックする、あたり)ことにする。

試験に利用したコードは以下のような感じ。

#include 
#include 

typedef struct {
  char a;
  short b;
  int c;
  char d;
  long e;
  char f;
  long long g;
  char h;
  float i;
  char j;
  double k;
  char l;
  long double m;
} var;

int main() {
  var *obj = new var;

  // sizeof types
  std::cout
    << "sizeof(char)        : " << sizeof(char)         << std::endl
    << "sizeof(short)       : " << sizeof(short)        << std::endl
    << "sizeof(int)         : " << sizeof(int)          << std::endl
    << "sizeof(long)        : " << sizeof(long)         << std::endl
    << "sizeof(long long)   : " << sizeof(long long)    << std::endl
    << "sizeof(float)       : " << sizeof(float)        << std::endl
    << "sizeof(double)      : " << sizeof(double)       << std::endl
    << "sizeof(long double) : " << sizeof(long double)  << std::endl
    << std::endl;

  // struct memory padding
  std::cout
    << "all  : " << sizeof(var) << std::endl
    << "b-a (char)       : "
      << (size_t)((char *)(&(obj->b)) - (char *)(&(obj->a))) << std::endl
    << "c-b (short)      : "
      << (size_t)((char *)(&(obj->c)) - (char *)(&(obj->b))) << std::endl
    << "d-c (int)        : "
      << (size_t)((char *)(&(obj->d)) - (char *)(&(obj->c))) << std::endl
    << "e-d (char)       : "
      << (size_t)((char *)(&(obj->e)) - (char *)(&(obj->d))) << std::endl
    << "f-e (long)       : "
      << (size_t)((char *)(&(obj->f)) - (char *)(&(obj->e))) << std::endl
    << "g-f (char)       : "
      << (size_t)((char *)(&(obj->g)) - (char *)(&(obj->f))) << std::endl
    << "h-g (long long)  : "
      << (size_t)((char *)(&(obj->h)) - (char *)(&(obj->g))) << std::endl
    << "i-h (char)       : "
      << (size_t)((char *)(&(obj->i)) - (char *)(&(obj->h))) << std::endl
    << "j-i (float)      : "
      << (size_t)((char *)(&(obj->j)) - (char *)(&(obj->i))) << std::endl
    << "k-j (char)       : "
      << (size_t)((char *)(&(obj->k)) - (char *)(&(obj->j))) << std::endl
    << "l-k (double)     : "
      << (size_t)((char *)(&(obj->l)) - (char *)(&(obj->k))) << std::endl
    << "m-l (char)       : "
      << (size_t)((char *)(&(obj->m)) - (char *)(&(obj->l))) << std::endl
    << std::endl;
  delete obj;
}
Comments Comments Off on gccでのi386とamd64におけるワードアライメントの動作の違い | Categories: ja, prog, tech | Autor: himorin