29676-30910

29386-29727 subjects 29793-35143

make install error ! on bcc32
29676 [tnebata@u. m] bcc32 で、make install できません。
29678 [nobu@ru y- a] 直ったと思います。たぶん。
29679 [tnebata@u. m] 上手くいきました。ありがとうございます。

rubybugs updated
29692 [root@mp t. i] 本件はみなさまにも関係するので、MLにてアナウンスします。
29693 [matz@ru y- a] unvelifiedか。いい単語が決まりましたね。
29694 [knu@iD em ns]  スペルは unverified でしょうか。
+ 29695 [matz@ru y- a] あ...。
+ 29696 [root@mp t. i] !がーん

1.8 digest/sha2 problem?
29697 [root@mp t. i] 手元のautobuildでtest-allが動きません。

*LDFLAGSについて
29698 [kinpoco@gm i] ...
29699 [nobu@ru y- a] すいません、そんなところに影響が出るとは。
29704 [taca@ba k- t] ちょっとハズレますが、
+ 29720 [kinpoco@gm i] ...
| 29721 [kinpoco@gm i] たびたびすみません。
| 29724 [kinpoco@gm i] 度重なる失礼申し訳ありません。
+ 29723 [taca@ba k- t] 結局、以下のようなパッチを1.8.5に加えました。(行番号は実際とはずれてい

ruby NKF モジュールの CP932  系エンコーディングパッチ
29700 [moriyama@mi ] IPA 2005年度下期オープンソースソフトウェア活用基盤整備事業のプロジェク
29701 [matz@ru y- a] この情報だけからだと、このパッチをとりこんでどう嬉しいのか伝
+ 29702 [naruse@ai em] ruby 1.8.4 に対してのパッチとしては一定のメリットがあるのですが、
| + 29703 [matz@ru y- a] 私が勝手に取り込むことはしません。よろしく。
| + 29714 [moriyama@mi ] 説明不足で申し訳ありませんでした。
|   29717 [naruse@ai em] あら、お大事に。
|   29722 [naruse@ai em] これは--no-cp932をつければ防止できますがー、
|   29766 [naruse@ai em] 以下の3つの問題は本家 nkf の nkf.c revision: 1.115 までに修正しました。
+ 29709 [maki@ru yc l] 先週末、OSC2006 Tokyo/Fallでレガシーエンコーディングプロジェクトの
  29716 [naruse@ai em] このOSCのBOF、存在に気づいたのが当日だったんですよね。。

Socket.gethostbyname
29705 [zn@mb .n ft ] リファレンスマニュアルの方でこんな変更がされていたのですが、
29706 [matz@ru y- a] unpackできるというドキュメントが間違いです。

reverted? gc.c: 1.168.2.46->1.168.2.47
29707 [akira@ar ka ] ruby_1_8で
29708 [matz@ru y- a] その通りでした。1.9と1.8を混同して修正していたようです。

Bignum#to_s(10) broken
29710 [usa@ga ba ec] 最近のbignum.cの変更(rb_big2str0)ですが、基数が10(〜15)の時に
+ 29711 [matz@ru y- a] その通りです。パッチ取り込みました。
+ 29712 [usa@ga ba ec] ところで、この 241/800 はlog10(2)の近似値だと思うのですが、こ
  29713 [matz@ru y- a] えーと、全然覚えていないんでが、どこかからそのまま持ってきた
  29715 [usa@ga ba ec] 入れときました。

テスト投稿です
29725 [moonwolf@mo ] こんどこそSpamAssasinを通り抜けられるかな?

cgi.rbのDoS脆弱性について
29726 [moonwolf@mo ] cgi.rbにマルチパート処理時のDoS脆弱性があるという報告(CVE-2006-5467)を
29728 [matz@ru y- a] 脆弱性として認めていないわけではないですが、この種のDoS脆弱
29729 [moonwolf@mo ] 優先度が低いと判断したのはまつもとさんの独断ですか?
+ 29730 [fuj@ra bi .j] これだからといって、
+ 29731 [matz@ru y- a] 私の独断です。
  29745 [moonwolf@mo ] やっとWebに掲載されましたね。
  + 29746 [taca@ba k- t] これですが、CVSのキーワード展開されたものは、pkgsrcやportsのようなCVS
  | 29752 [moonwolf@mo ] 実体が違うのであれば、REVISIONを変える必要があるのでは?
  | 29755 [taca@ba k- t] 現状の REVISION はCVSでファイルを管理している「記し」が残っているだけ
  | 29757 [moonwolf@mo ] 複数のパッチをあてることもありえるので、対策した脆弱性の識別子(たとえば
  | 29762 [taca@ba k- t] あまり複雑にせず、何時の時点のモノかわかる「記し」だけにして、そこまで
  | 29778 [moonwolf@mo ] 素人でも簡単に確認できる日付の整合性が取れていないのですが、それでもいい
  | 29783 [taca@ba k- t] 素人でも簡単に確認できる日付の整合性って、いったい何でしょうか?
  | 29785 [moonwolf@mo ] 29745]で指摘した。
  + 29751 [usa@ga ba ec] ご指摘はごもっともなので、静的なファイルを用意して、関連する
    + 29753 [moonwolf@mo ] ありがとうございます。
    | 29754 [usa@ga ba ec] それが問題であるかどうかは議論の余地があると思います。
    | 29756 [moonwolf@mo ] 今回かろうじてCGI::REVISIONでパッチがあたっているか確認できたから
    | 29759 [usa@ga ba ec] (1)がスルーされてますが、わかる人に確認する、という選択肢はあ
    | 29780 [moonwolf@mo ] 人間に問い合わせるってすごく面倒ではありませんか? 時間もかかるでしょうし。
    | 29784 [usa@ga ba ec] 真面目に運用をやってるところなら、どのようなセキュリティフィ
    | 29786 [moonwolf@mo ] 1.8.5にいくらパッチをあてても1.8.5です。
    | + 29791 [matz@ru y- a] 現在議論中です。ただねえ、それ以前に「組織ってなに」って問題
    | | 29811 [moonwolf@mo ] 外から見る限り、ruby-lang.orgはどうみても組織だと思います。
    | | 29818 [matz@ru y- a] ruby-lang.orgは単なる有志のゆるい集合で、MoonWolfさんが期待
    | | + 29826 [moonwolf@mo ] 組織化されていないけど組織化されているように見えるので、その辺が
    | | | + 29841 [matz@ru y- a] それって本当に必要なんですか。
    | | | | + 29843 [moonwolf@mo ] それはまつもとさんが気が乗らないと独断で判断しているだけでしょう?
    | | | | | 29847 [matz@ru y- a] segvを起こせるバグはほぼ全部だと思います。悪用がどれだけ簡単
    | | | | | 29852 [moonwolf@mo ] 「なにを言っても結局は言い訳」など極論に飛躍しないでください。
    | | | | | 29853 [matz@ru y- a] えーと、個人の言い訳というか、できない、できてない事情をお話
    | | | | | 29858 [moonwolf@mo ] 人によって違うとは思いますが、許せる(あきらめがつく)言い訳と
    | | | | | 29864 [matz@ru y- a] どう見えるかはともかく、そのような意図はありません。あまり自
    | | | | | 29867 [moonwolf@mo ] 外からどう見えるかについて意識したうえで対応するよう、ほんの少しでも頭の
    | | | | | 29871 [matz@ru y- a] おっしゃることはわかります。が、なかなか最初の「このURLに書
    | | | | + 29844 [moonwolf@mo ] patchlevelの話はセキュリティのアナウンスをどうするかなどと
    | | | + 29873 [usa@ga ba ec] 内部でレビューをした結果でもつっこまれることになる場合もある、
    | | |   + 29874 [moonwolf@mo ] どんな議論がされて、誰がどういう風に作業したのか
    | | |   + 29875 [moonwolf@mo ] 可能性としてありえるのはわかります。
    | | |     29876 [usa@ga ba ec] 稚拙であるし不十分である、と思っているからですよ。
    | | |     29877 [moonwolf@mo ] 他の人が指摘を甘んじて受けていないのに、なぜU.Nakamuraさんが
    | | |     29879 [usa@ga ba ec] もちろん個人的な意見表明ですよ。
    | | |     + 29880 [moonwolf@mo ] 言葉を選ぶのが難しいですね。「組織」でもないし「体制」でもない。
    | | |     | 29884 [usa@ga ba ec] 私もよくわかってないんですが、違いそうに見えます。
    | | |     | 29885 [moonwolf@mo ] なんという言葉で表すのが適切なんでしょうねぇ。
    | | |     | 29886 [usa@ga ba ec] つまり適切にそれを表す言葉が存在しないんじゃないでしょうか。
    | | |     + 29881 [moonwolf@mo ] 一番シンプルな方法としては全員から「これが結論である」ということに
    | | + 29836 [beyond@bi .o] まつもとさんの認識としては「共同体」もしくは「共同体の中でも意識の高い一
    | |   + 29840 [matz@ru y- a] 個人的には「とらないといけない」かどうかは自明ではないのです
    | |   | 29887 [beyond@bi .o] 自明かどうかは、その人の「道徳心」の有無によるため、議論はいたしません。
    | |   | 29891 [matz@ru y- a] 読み違えておりました。そうであれば「日本Rubyの会」に対する言
    | |   + 29865 [ko1@at ot ne]  日本Rubyの会のほうでも寄付の受け皿を作りたいとは常々思っているんです
    | |     29868 [adzumi@de pa] 日本Rubyの会の会計をしております。
    | + 29806 [usa@ga ba ec] ええ、意図については先ほど拝見したので、誤解はしてないと思い
    |   29810 [moonwolf@mo ] パッチを出す前に、誰かにチェックしてもらうべきだったかなぁ?
    + 29758 [moonwolf@mo ] パッチを差し替えたのだから、履歴を記述してもらえるとありがたいです。
    + 29761 [ueda@ne fo e]  どこにつなげるべきか分からなかったので、とりあえずこちらに。
      + 29763 [taca@ba k- t] といったものが最低限用意してあった方が良いと思います。ディレクトリ構成
      + 29764 [matz@ru y- a] 一番最初に述べた通り、DoS脆弱性は優先度が低いのでこのような
      | + 29772 [shugo@ru y- ] まつもとさんにとっては「優先度が低い」かもしれませんが、利用する
      | | + 29773 [matz@ru y- a] まさにそのために卜部くんが1.8.6の準備をしているのだと思いま
      | | + 29774 [shugo@ru y- ] もう一点だけ。
      | | | 29776 [matz@ru y- a] あんまりCVSのブランチとか得意じゃないんで、どういう風に作業
      | | | 29777 [shugo@ru y- ] 自分もCVSのブランチには何度か痛い目にあっていますし、作業が楽という
      | | | 29790 [matz@ru y- a] そういうもんなんですね。
      | | | 29792 [shugo@ru y- ] すみません、[ruby-dev:29356]の「来年まで」を読み落としてました。
      | | | 29796 [matz@ru y- a] 基本フリーズだと思ってもよいと思います。ただ、JRubyなどとの
      | | | 29798 [shugo@ru y- ] 確認ですが、添付ライブラリについても同様でしょうか。
      | | + 29834 [ueda@ne fo e] 一日、間を置いて頭を冷やしてみたのですが、どうも納得が出来ないので...
      | |   29855 [takahashi@tw] 「いま公開されている ruby-1.8.5.tar.gz ファイル」自体は、何も手を加えず
      | |   + 29856 [ueda@ne fo e]  私もそのように思います。危惧していたのは以前に書いたように
      | |   + 29859 [moonwolf@mo ] 私もruby-1.8.5.tar.gzを変更しないほうがいいと思います。
      | + 29779 [moonwolf@mo ] せっかくsecurity@ruby-lang.orgが用意されているですから、そこで議論して判
      + 29794 [ueda@ne fo e]  少なくとも近々に 1.8.5.1 が出ることは無さそうですし、1.8.5 の tar ball

().." dumps core
29732 [mame@ts .n .] ().." というコードを実行すると segv します。
29733 [usa@ga ba ec] こうでしょうか。
+ 29734 [mame@ts .n .] ruby 1.8.5 (2006-10-30) [i686-linux] で
+ 29739 [matz@ru y- a] コミットしてください。

variable _ and multiple assignment in irb
29735 [mame@ts .n .] irb で _ に多重代入をするとなんか変な気がします。
29737 [eban@os ri .] irbでは_は最後に実行した結果を保持しています。
29738 [mame@ts .n .] 意図された挙動でしたか。

[提案] Kernel#p  をもっと便利に
29736 [mame@ts .n .] 日頃から思っていたことを提案してみます。
+ 29740 [matz@ru y- a] pは複数の引数を取りますが、その場合、なにを返すべきですかね。
| 29741 [hiraku@hi et] 面白便利そうな話が始まったのでしゃしゃり出てきてしまいました。
| 29742 [matz@ru y- a] 引数の数によって戻り値が配列だったりそうでなかったりするのは、
| + 29743 [mame@ts .n .] 私の motivation example では
| + 29748 [hiraku@hi et] すみません、確かにそうでした。
| + 29750 [yugui@yu ui ] return a,bをデバッグ時にreturn p a,bと書ける点で、どうせ値を返すなら配列を返してくれると嬉しいです。
| | 29781 [mame@ts .n .] return a, b がそういう挙動を取るとるのなら、あわせるのがいいかもですね。
| + 29760 [gimite@gm il] 確かにpが戻り値を返すのは便利そうですね。
+ 29782 [mame@ts .n .] こっちに対するご意見ご検討も期待してます ^^
+ 29915 [mame@ts .n .] 1.9 で実装してみました。
  30873 [mame@ts .n .] 半年以上経ってしまいましたが、この提案 (ruby-dev:29736) は拒絶された
  + 30874 [shyouhei@ru ] 1.9にはObject#tapというのが追加されているようです。
  | 30875 [mame@ts .n .] なるほど、それは知りませんでした。ありがとうございます。
  + 30896 [matz@ru y- a] えーと、とりあえず、引数をそのまま戻り値にする部分は取り込む
    30902 [mame@ts .n .] HEAD で確認しました。ありがとうございます。
    30903 [matz@ru y- a] で、self.pで自分自身を出力する方ですが、なんかいろいろと納得
    30904 [mame@ts .n .] そういう筋が通っているのは多くの場合で重要だと思いますが、
    30910 [ngoto@ge -i ] たとえば

AIXのgetnameinfoについて
29744 [kinpoco@gm i] ...
29747 [matz@ru y- a] 正直、AIXのことはよくわからないのですが、AIXユーザ自身が幸せ
29749 [kinpoco@gm i] お世話になっています。

merge with YARV
29765 [ko1@at ot ne]  RubyConf 2006 の最終日にさっさと YARV をマージしろ、といわれてしまった
+ 29775 [shugo@ru y- ] リポジトリの公開はどのタイミングを予定されていますか?
+ 29787 [hogemuta@gm ] 役に立てるかどうかわかりませんが、これから読ませていただきます。
| 29788 [ko1@at ot ne]  ありがとうございます。
| 29797 [hogemuta@gm ] rubyそのものがGPLとRuby'sのデュアルライセンスなので、GPLでも
| 29799 [matz@ru y- a] Rubyの他の部分と違うライセンスを適用するつもりがあるのでなけ
| 29838 [hogemuta@gm ] はい。アメリカも無方式主義になったというのは伝え聞きましたし、
| 29866 [ko1@at ot ne]  私の意向としては、面倒に巻き込まれなければどーでもいい、なので、まつも
| 29883 [hogemuta@gm ] まあ確かに無償で提供していてその上でなんらかの保証もしているというものは
+ 29839 [shiba@ma l2 ] いつどこで持ち出すべきかずっと悩んでいたのですが、そろそろお蔵入り
| 29842 [matz@ru y- a] まず第一に変更するにしてもこのライセンスにはしません。もう
| 29845 [moonwolf@mo ] Rubyのライセンスを変更する場合、ライブラリなどのライセンスで
| 29846 [matz@ru y- a] 「Same as Ruby's」は現在の「Ruby's License」を指すと解釈しま
| 29869 [moonwolf@mo ] 現在のRuby's Licenseは一切修正されることなく、今後も「Ruby's License」と
| 29872 [matz@ru y- a] 現在のRuby's Licenseの文言は一切修正されることなく、今後も
+ 29934 [ko1@at ot ne]  さっさと進捗を報告しろ,という声があったので進捗を報告します.

1.8 proposal of RUBY_PATCHLEVEL
29767 [root@mp t. i] あ。ささださんがメール書いたから俺も書こう。
+ 29768 [taca@ba k- t] ここで、
| + 29800 [root@mp t. i] どうするのがいいと思いますか?
| + 29833 [naruse@ai em] 図にするとこんなイメージでいいのでしょうか。
+ 29769 [akira@ru y- ] Linux distributionの都合からすると
| 29801 [root@mp t. i] そりゃちょっとDebian固有すぎる話題です。Linux distributionはDebian以外に
| + 29812 [akira@ru y- ] そんなことはひとっことも言ってませんよ。
| | + 29823 [root@mp t. i] 質問部分に関して解答すると、
| | | 29827 [moonwolf@mo ] パッチセット単位というのが、どうもわかりません。
| | + 29832 [matz@ru y- a] 前のメールでおっしゃりたいことがよく伝わらなかったようです。
| + 29813 [moonwolf@mo ] そういう考え方だとすると、今回のRUBY_PATCHLEVELの値は当てになりません
|   29822 [root@mp t. i] 俺が(管理が楽になることで)得しますよ。もっとも重要なポイントです。
|   29825 [moonwolf@mo ] うーん、いままで提供していたstableのスナップショットに明確な名前をつけた
+ 29770 [matz@ru y- a] まったくおっしゃる通りです。
| + 29802 [root@mp t. i] どうも今後の方針を議論するということでコンセンサスが得られたような雰囲気
| | + 29808 [HGF01572@ni ] 方法論としては
| | | 29809 [taca@ba k- t] 私は、
| | + 29821 [matz@ru y- a] 私の危惧しているのは、Ruby本体については1.8系で十分安定して
| |   + 29829 [knu@iD em ns]  議論の流れを見て思うのですが、 1.9, 1.8, 1.8.X-pX ブランチの
| |   | 29830 [m_seki@mv .b] # 表明だけでセンスないんですが。
| |   + 29848 [shugo@ru y- ] そういう面はあると思います。
| + 29835 [naruse@ai em] "hoge"[0] == 0x68 が "h" になった影響で 1.9 では動きませんが、
+ 29771 [shugo@ru y- ] 1.8.5リリース時点からブランチを切って上記の作業をするわけではないので
| + 29789 [knu@iD em ns]  上の表記は枝と節点が混在していてよくわからないですね。
| | 29795 [matz@ru y- a] もっとでしょうね。個人的には数年は1.8が残るものと考えてます。
| | + 29804 [root@mp t. i] えっと、そんな他人事みたいないい方はやめてください。
| | | 29819 [matz@ru y- a] そうは言われても、まだ確定していない事象(1.9が十分安定する時
| | + 29805 [knu@iD em ns]  1.8は完成度が高く充実した系列だと思っていたので、1.9や2.0が
| |   29898 [knu@iD em ns] SCM
| + 29803 [root@mp t. i] どうしましょうか?
|   + 29807 [knu@iD em ns]  いっそ、テストは別レポジトリに移動してしまってはどうでしょう。
|   + 29889 [shugo@ru y- ] 1.8.6からだとすると、1.8.6をどういう形でリリースするかを考えない
|     29890 [root@mp t. i] んー、なので、1.8.6-p0が1.8.5リリース後にcommitされたバグ修正以外の変更
|     + 29893 [matz@ru y- a] 私もそんなイメージを持ってました。
|     + 29895 [shugo@ru y- ] 1.8.6までは今まで通りで、1.8.6-p1以降はバグ修正以外認めないということ
|       29896 [root@mp t. i] じゃあいますぐ凍結ってことで。
|       + 29897 [nagai@ai ky ] commit したんですが,ダメですか?(;_;)
|       | 29899 [root@mp t. i] その情報だけではさすがに判断できないのでもう少し詳しくお願いできますか。
|       | 29903 [nagai@ai ky ] Tcl/Tk の BLT 拡張を利用する場合のライブラリの一部で,
|       | 29904 [knu@iD em ns]  従来の1.8系列の位置づけはそういうものですね。
|       + 29901 [root@mp t. i] まあまあ。仮にですから。実際まだ何も作業してませんし。
|         29908 [matz@ru y- a] 今後1.8に加えられる可能性がある変更は
+ 29814 [moonwolf@mo ] 提供されるパッチはどのような物になるのでしょう?
| 29820 [knu@iD em ns]  脆弱性報告の修正に関する部分は、ブランチごとに、
| 29824 [moonwolf@mo ] 今回の提案は全てがセキュリティのパッチであるということではありませんよ
| 29828 [knu@iD em ns]  そのコンセンサスは取れていないと思います。セキュリティとともに
| 29831 [moonwolf@mo ] 修正しないというポリシーもあり得ますが、いまの1.8をそこまでガチガチに固
| 29837 [knu@iD em ns]  まあそれはひとつの意見表明ということで、議論しましょう。
+ 29815 [moonwolf@mo ] あまり無いとは思いますが、複数のセキュリティ案件を同時に対応する場合、
| 29816 [moonwolf@mo ] 確認ですが複数の案件を1つのPATCHLEVELで対応したりはしませんよね?
| 29817 [moonwolf@mo ] 1案件==1PATCHLEVELが守られるという前提で、
+ 29870 [moonwolf@mo ] RUBY_PATCHLEVELはRubyレベルの定数として定義されるのでしょうか?
threads.html
top