2013年7月30日 16:27 1xx itsango@gmail.com:
ひょっとしてbind周りでしょうか? と思ってみたり…。
http://jprs.jp/tech/security/2013-07-27-bind9-vuln-malformed-rdata.html http://software.opensuse.org/package/bind
OBSの勉強として、噂のBIND 9.9.3P2をbuildしてみました。 意外に簡単にbuild出来ました。 まあ、実質1行しか変更がないから当然ですね。 http://security.freebsd.org/patches/SA-13:07/bind.patch #OBSの動作自体を理解するのに半日くらいかかりましたが…。
今のところopenSUSE 13.1 Milestone 3 x86_64 の上で、 キャッシュサーバとして動作しております。
どなたかこのBINDをtestしてみたいという物好きな方はいらっしゃいませんか?
http://software.opensuse.org/package/bind http://software.opensuse.org/download.html?project=home%3AMitsutoshi%3Abranc...
こんな簡単にbuildしたpackageを公開できるのって逆に怖い気がしますね。
#これ、作ったはいいけどどうすればいいんだろう?
2013年7月31日 11:33 1xx itsango@gmail.com:
2013年7月30日 16:27 1xx itsango@gmail.com:
ひょっとしてbind周りでしょうか?
どなたかこのBINDをtestしてみたいという物好きな方はいらっしゃいませんか?
http://software.opensuse.org/package/bind http://software.opensuse.org/download.html?project=home%3AMitsutoshi%3Abranc...
#これ、作ったはいいけどどうすればいいんだろう?
reviewとtestの依頼を出してみました。
http://lists.opensuse.org/archive/opensuse-security/2013-07/msg00029.html http://lists.opensuse.org/archive/opensuse-networking/2013-07/msg00000.html http://lists.opensuse.org/archive/opensuse-factory/2013-07/msg00379.html
requestも出してみました。 https://build.opensuse.org/request/show/185040
daemonをこんなお気軽に変更してよいのでしょうか?
2013/7/31 1xx itsango@gmail.com:
2013年7月31日 11:33 1xx itsango@gmail.com:
どなたかこのBINDをtestしてみたいという物好きな方はいらっしゃいませんか?
#これ、作ったはいいけどどうすればいいんだろう?
reviewとtestの依頼を出してみました。
requestも出してみました。
request はdeclinedになりました。 https://build.opensuse.org/request/show/185040#request_history
.changes entry violates the formatting rules and misses a reference to the respective bugzilla id (bnc#831899). No need to resubmit, will do that myself.
.changesが書式に違反しており、Bugzilla IDが載っていません。 https://bugzilla.novell.com/show_bug.cgi?id=831899 再提出の必要はありません、私(rmaxさん)自身が作業します。
という理解でよろしいのでしょうか? Bugzilla IDは検索したけど見つけられませんでしたorz Product をopenSUSEで絞っていたのが悪かったのでしょうか? bnc#831899のproductはSUSE Security Incidentsになっていました。
https://bugzilla.novell.com/show_bug.cgi?id=831899#c1 を読む限りは8月5日までにfixが出るということでしょうか。
今後のために.changes entry formatting rulesを勉強しておきたいのですが、 どこを見ておけばよいのでしょう?
武山です
という理解でよろしいのでしょうか? Bugzilla IDは検索したけど見つけられませんでしたorz Product をopenSUSEで絞っていたのが悪かったのでしょうか? bnc#831899のproductはSUSE Security Incidentsになっていました。
そうですね。 セキュリティ関連だったので、最初は非公開だったのかもしれません。
bind クラスだと、きちんと担当者がいて対応が早いですね。
https://bugzilla.novell.com/show_bug.cgi?id=831899#c1 を読む限りは8月5日までにfixが出るということでしょうか。
パッチ作成作業がその日までに終われば…ですが。
今後のために.changes entry formatting rulesを勉強しておきたいのですが、 どこを見ておけばよいのでしょう?
基本的には packaging guideline 以下のドキュメントに書いてあります。 Changes については特に: http://en.opensuse.org/openSUSE:Howto_write_good_changes
重要なことは ■何が変わったかユーザにも分かるように - update to 1.x だけではダメ。
個人的には、upstream が chagelog を提供しない場合でも、 git の commit ログから書き起こすようにしています。 あと、Windows 関連など、関係ないものは消しています
■修正した Bugzilla（Novell 以外も対象はある）番号を正確なフォーマットで - fix XXXX (bnc#xxxxx)
■追加した・削除したパッチがあれば記述する - remove obsolete xxxx.patch (upstream)
最近、changes のチェックが厳しめで、不備で Factory から decline されることが 時々あります。
(2013/07/31 17:20), 1xx wrote:
2013/7/31 1xx itsango@gmail.com:
2013年7月31日 11:33 1xx itsango@gmail.com:
どなたかこのBINDをtestしてみたいという物好きな方はいらっしゃいませんか?
#これ、作ったはいいけどどうすればいいんだろう?
reviewとtestの依頼を出してみました。
requestも出してみました。
request はdeclinedになりました。 https://build.opensuse.org/request/show/185040#request_history
.changes entry violates the formatting rules and misses a reference to the respective bugzilla id (bnc#831899). No need to resubmit, will do that myself.
.changesが書式に違反しており、Bugzilla IDが載っていません。 https://bugzilla.novell.com/show_bug.cgi?id=831899 再提出の必要はありません、私(rmaxさん)自身が作業します。
という理解でよろしいのでしょうか? Bugzilla IDは検索したけど見つけられませんでしたorz Product をopenSUSEで絞っていたのが悪かったのでしょうか? bnc#831899のproductはSUSE Security Incidentsになっていました。
https://bugzilla.novell.com/show_bug.cgi?id=831899#c1 を読む限りは8月5日までにfixが出るということでしょうか。
今後のために.changes entry formatting rulesを勉強しておきたいのですが、 どこを見ておけばよいのでしょう?
2013年8月1日 0:45 Fuminobu TAKEYAMA ftake@geeko.jp:
今後のために.changes entry formatting rulesを勉強しておきたいのですが、 どこを見ておけばよいのでしょう?
基本的には packaging guideline 以下のドキュメントに書いてあります。 Changes については特に: http://en.opensuse.org/openSUSE:Howto_write_good_changes
情報ありがとうございます。 http://en.opensuse.org/openSUSE:Packaging_guidelines を読んでいるのですが、膨大ですね…。
重要なことは ■何が変わったかユーザにも分かるように
- update to 1.x
だけではダメ。
個人的には、upstream が chagelog を提供しない場合でも、 git の commit ログから書き起こすようにしています。 あと、Windows 関連など、関係ないものは消しています
■修正した Bugzilla（Novell 以外も対象はある）番号を正確なフォーマットで
- fix XXXX (bnc#xxxxx)
■追加した・削除したパッチがあれば記述する
- remove obsolete xxxx.patch (upstream)
# Rate limiting patch by Paul Vixie et.al. for reflection DoS protection # see http://www.redbarn.org/dns/ratelimits #Patch200: http://ss.vix.su/%7Evjs/rpz2+rl-9.9.3-P1.patch Patch200: http://ss.vix.su/%7Evjs/rpz2+rl-9.9.3-P2.patch
このpatchがP1とP2で大きく変わっていて、 何を変更したのか理解するのに苦労するんじゃないかと思います。
最近、changes のチェックが厳しめで、不備で Factory から decline されることが 時々あります。
rmaxさんが提供するsrc.rpmを読んでみて、 どのように書くのが良いのか勉強したいと思います。
https://bugzilla.novell.com/show_bug.cgi?id=831899 はNEEDINFOになっていて、方針で悩んでいるように見えますね。
-
1xx -
Fuminobu TAKEYAMA