|
コメント |
|
|
(0003002)
|
|
munepi
|
|
2009-02-04 23:51
|
|
山本＠千葉です。
報告を頂きましてありがとうございます。
いくつか確認させて下さい。
1. freetype2-devel はインストールされていますか？
$ rpm -qa freetype2-devel
freetype2-devel-2.1.10-8.3vl4
2. mplayer 1.0rc2 を展開して、./configure したときに、
Checking for bitmap font support ... yes
Checking for freetype >= 2.0.9 ... yes
と autodetect されないのでしょうか？
$ less /var/tmp/self-build-mplayer.log
で確認されてもかまいません。
3. subfont.ttf は何にリンクされていますか？
$ ls -l /usr/share/mplayer/subfont.ttf
lrwxrwxrwx 1 root root 56 1月24日 10:52 /usr/share/mplayer/subfont.ttf -> /usr/X11R6/lib/X11/fonts/TrueType/VL-PGothic-Regular.ttf
4. --enable-freetype とするかわりに --disable-bitmap-font としたら、どうなりますか？ |
|
|
|
|
京都産業大学の大本です．
申し訳ありません．当方の勘違いがエラーの原因だったようです．
エラーの原因は，古い個人設定 ~/.mplayer/* が残っていたためだったようです．
これらを全て削除すると，self-build-mplayer-1.0-2.rc2vl4 にて問題無く動作しました．
> 1. freetype2-devel はインストールされていますか？
> $ rpm -qa freetype2-devel
> freetype2-devel-2.1.10-8.3vl4
インストール済みです．そもそも，mplayer.specに
BuildRequires: gtk2-devel, freetype2-devel, SDL-devel
と指定されているので，入ってないとビルド出来ないですね．
> 2. mplayer 1.0rc2 を展開して、./configure したときに、
> Checking for bitmap font support ... yes
> Checking for freetype >= 2.0.9 ... yes
> と autodetect されないのでしょうか？
すいません．autodetectされてました．
Checking for bitmap font support ... yes
Checking for freetype >= 2.0.9 ... yes
Checking for fontconfig ... yes
> 3. subfont.ttf は何にリンクされていますか？
> $ ls -l /usr/share/mplayer/subfont.ttf
> lrwxrwxrwx 1 root root 56 1月24日 10:52 /usr/share/mplayer/subfont.ttf -
> > /usr/X11R6/lib/X11/fonts/TrueType/VL-PGothic-Regular.ttf
同様にリンクされています．
> 4. --enable-freetype とするかわりに --disable-bitmap-font としたら、どう
> なりますか？
Checking for bitmap font support ... no
Checking for freetype >= 2.0.9 ... yes
Checking for fontconfig ... yes
となりまして，この条件下でビルドされたパッケージでも正常に動作するようです．
これだけでは，ちょっと恥ずかしいので，テスト中に気がついた事を一点補足します．
self-build-mplayer.spec中のソースコードダウンロードに関する記述が
/usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
http://www{1,2,3,4,5,7,8}.mplayerhq.hu/%{source0path} [^] \
http://www{1,2,3,4,5,7,8}.mplayerhq.hu/%{source1path} [^]
となっています．
これは恐らくwww1.mplayerhq.huを試し，ダメならwww2.mplayerhq.huを試し．．．．を繰り返して，成功した最初のサーバからダウンロードするのでないかと思うのですが，接続する時間帯や経路依存するのかも知れませんが，www1サーバが劇遅になっていることがあるようです．2009年 2月 5日 木曜日 19:22:23 JST現在，www1からMPlayer-1.0rc2.tar.bz2をダウンロードすると，5~7KB/sしか出てません．（突然，遅くなったようなので，何かサーバ側にトラブルが起きてるかも）
http://www.mplayerhq.hu/上のページを見てみると [^]，非常に古いコードancient releasesのダウンロード先が http://www1.mplayerhq.hu/MPlayer/old_stuff/releases/ [^] になっていて，www2やwww3上にはミラーされてませんので，www1がマスターサーバ，それ以外はミラーサーバなのだろうと推定しています．
dig www.mplayerhq.huの結果を見ると，DNSラウンドロビンが設定されているようなので，
stream:~ oomoto$ dig www.mplayerhq.hu
; <<>> DiG 9.3.5-P2 <<>> www.mplayerhq.hu
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65243
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;www.mplayerhq.hu. IN A
;; ANSWER SECTION:
www.mplayerhq.hu. 74211 IN A 74.86.94.210
www.mplayerhq.hu. 74211 IN A 85.214.85.226
www.mplayerhq.hu. 74211 IN A 69.63.177.230
www.mplayerhq.hu. 74211 IN A 131.246.120.85
www.mplayerhq.hu. 74211 IN A 193.225.187.202
www.mplayerhq.hu. 74211 IN A 143.248.234.110
www.mplayerhq.hu. 74211 IN A 216.14.112.110
www.mplayerhq.hu. 74211 IN A 199.125.85.41
www.mplayerhq.hu. 74211 IN A 213.144.138.186
www.mplayerhq.hu. 74211 IN A 81.91.100.172
www.mplayerhq.hu. 74211 IN A 82.103.137.100
;; AUTHORITY SECTION:
mplayerhq.hu. 74210 IN NS mail.blastwave.org.
mplayerhq.hu. 74210 IN NS a.ns.projectdream.org.
mplayerhq.hu. 74210 IN NS ns1.mgmservers.net.
;; ADDITIONAL SECTION:
a.ns.projectdream.org. 2210 IN A 194.88.212.200
ns1.mgmservers.net. 160610 IN A 63.246.146.182
;; Query time: 2 msec
;; SERVER: 133.101.96.25#53(133.101.96.25)
;; WHEN: Thu Feb 5 19:08:16 2009
;; MSG SIZE rcvd: 338
適切な負荷分散の意味からして，ダウンロード先の記述は素直に，
/usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
http://www.mplayerhq.hu/%{source0path} [^] \
http://www.mplayerhq.hu/%{source1path} [^]
とするのが，適当なのでないかと提案しておきます．
是非の判断は，パッケージャの方にお任せします．
以上 |
|
|
|
(0003004)
|
|
ats7
|
|
2009-02-07 01:36
|
|
> self-build-mplayer.spec中のソースコードダウンロードに関する記述が
> /usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
> http://www{1,2,3,4,5,7,8}.mplayerhq.hu/%{source0path} [^] \
> http://www{1,2,3,4,5,7,8}.mplayerhq.hu/%{source1path} [^]
> となっています．
(snip)
> 適切な負荷分散の意味からして，ダウンロード先の記述は素直に，
> /usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
> http://www.mplayerhq.hu/%{source0path} [^] \
> http://www.mplayerhq.hu/%{source1path} [^]
> とするのが，適当なのでないかと提案しておきます．
> 是非の判断は，パッケージャの方にお任せします．
ご指摘の方法ですと、ソースの取得に失敗した場合、ユーザーが再度インストール
操作をする必要があり面倒だと思いましたので、ミラーを併記する形にしました。
<BTS:VineLinux:603>
また、wget(glibc)がDNSラウンドロビンを正しく扱えない問題もあるようですが、
いかがでしょうか。
wget breaks round-robin dns?
http://www.mail-archive.com/wget@sunsite.dk/msg09235.html [^] |
|
|
|
|
大本＠京都産業大学です．
> また、wget(glibc)がDNSラウンドロビンを正しく扱えない問題もあるようです
> が、
> いかがでしょうか。
>
> wget breaks round-robin dns?
> http://www.mail-archive.com/wget@sunsite.dk/msg09235.html [^]
wgetの挙動を確認してみました．
一般ユーザ権限でwgetを動かした場合と，root権限で動かした場合で挙動が違いますね．
一般ユーザ権限だと，複数回動かしても同じサーバに接続に行ってしまいます．
１回目のwget:
www.mplayerhq.hu をDNSに問いあわせています... 69.63.177.230, 213.144.138.186, 85.214.85.226, ...
Caching www.mplayerhq.hu => 69.63.177.230 213.144.138.186 85.214.85.226 193.225.187.202 81.91.100.172 143.248.234.110 199.125.85.41 131.246.120.85 74.86.94.210 216.14.112.110 82.103.137.100
www.mplayerhq.hu|69.63.177.230|:80 に接続しています... 接続しました。
２回目のwget:
www.mplayerhq.hu をDNSに問いあわせています... 69.63.177.230, 213.144.138.186, 85.214.85.226, ...
Caching www.mplayerhq.hu => 69.63.177.230 213.144.138.186 85.214.85.226 193.225.187.202 81.91.100.172 143.248.234.110 199.125.85.41 131.246.120.85 82.103.137.100 74.86.94.210 216.14.112.110
www.mplayerhq.hu|69.63.177.230|:80 に接続しています... 接続しました。
３回目のwget:
www.mplayerhq.hu をDNSに問いあわせています... 69.63.177.230, 213.144.138.186, 85.214.85.226, ...
Caching www.mplayerhq.hu => 69.63.177.230 213.144.138.186 85.214.85.226 193.225.187.202 81.91.100.172 131.246.120.85 143.248.234.110 199.125.85.41 82.103.137.100 74.86.94.210 216.14.112.110
www.mplayerhq.hu|69.63.177.230|:80 に接続しています... 接続しました。
という具合です．
これは，レゾルバ(glibc)のキャッシュが影響するのかと思って，当方の環境で動かしていたnscdを停止させた状態でも同様の挙動を示しました．
ところが，root権限でwgetを動かすと以下のようになります．
(rootにて)４回目のwget:
Resolving www.mplayerhq.hu... done.
Caching www.mplayerhq.hu => 216.14.112.110 131.246.120.85 82.103.137.100 74.86.94.210 143.248.234.110 193.225.187.202 199.125.85.41 213.144.138.186 69.63.177.230 81.91.100.172 85.214.85.226
Connecting to www.mplayerhq.hu[216.14.112.110]:80... connected.
(rootにて)５回目のwget:
Resolving www.mplayerhq.hu... done.
Caching www.mplayerhq.hu => 85.214.85.226 216.14.112.110 131.246.120.85 82.103.137.100 74.86.94.210 143.248.234.110 193.225.187.202 199.125.85.41 213.144.138.186 69.63.177.230 81.91.100.172
Connecting to www.mplayerhq.hu[85.214.85.226]:80... connected.
(rootにて)６回目のwget:
Resolving www.mplayerhq.hu... done.
Caching www.mplayerhq.hu => 81.91.100.172 85.214.85.226 216.14.112.110 131.246.120.85 82.103.137.100 74.86.94.210 143.248.234.110 193.225.187.202 199.125.85.41 213.144.138.186 69.63.177.230
Connecting to www.mplayerhq.hu[81.91.100.172]:80... connected.
(rootにて)７回目のwget:
Resolving www.mplayerhq.hu... done.
Caching www.mplayerhq.hu => 69.63.177.230 81.91.100.172 85.214.85.226 216.14.112.110 131.246.120.85 82.103.137.100 74.86.94.210 143.248.234.110 193.225.187.202 199.125.85.41 213.144.138.186
Connecting to www.mplayerhq.hu[69.63.177.230]:80... connected.
この挙動は，nscdが動いていても停止していても変わらず，wgetを実行する毎に接続先がラウンドロビンされていました．
root権限での挙動が違うのは一体．．．．．
私には，wgetのバグなのかresolver (glibc)のバグなのか判断がつきかねます．
self-buildパッケージのインストールはroot権限で行われますから，www.mplayerhq.huからダウンロードしても，各ユーザ毎に異なるサーバからダウンロードされる事は期待出来ませんかね？
期待できるように思うので，残るは，名前解決したサーバからのソースコード取得に失敗した時のリカバーが利けば良いかと思います．
例えばソースコード取得部を次のようにしてはどうでしょうか？ （ついでにマスターサーバを極力避けるようにしてます）
/usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source0path} [^] \
http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source1path} [^]
或いは
/usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
http://ww{w,w2,w3,w4,w5,w7,w8,w1}.mplayerhq.hu/%{source0path} [^] \
http://ww{w,w2,w3,w4,w5,w7,w8,w1}.mplayerhq.hu/%{source1path} [^]
手元で試した限りは，ちゃんとソースコードはダウンロードされました．
以上 |
|
|
|
(0003006)
|
|
ats7
|
|
2009-02-12 00:30
|
|
> root権限での挙動が違うのは一体．．．．．
> 私には，wgetのバグなのかresolver (glibc)のバグなのか判断がつきかねます．
wgetのDNSラウンドロビンの件は、<BTS:665>に移しました。
> 期待できるように思うので，残るは，名前解決したサーバからのソースコード取
> 得に失敗した時のリカバーが利けば良いかと思います．
> 例えばソースコード取得部を次のようにしてはどうでしょうか？ （ついでにマス
> ターサーバを極力避けるようにしてます）
>
> /usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
> http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source0path} [^] \
> http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source1path} [^]
マスターサーバの優先順位を下げるという提案については賛成です。
ただ、self-build-mplayer-1.0-6.20090109vl5 以降は Subversion から
snapshot を取得するようです。 |
|
|
|
|
大本＠京都産業大学です．
基本的には本件は収束してきたと思うので，クローズして頂いて差し支えないと思います．
> > 例えばソースコード取得部を次のようにしてはどうでしょうか？ （ついでにマス
> > ターサーバを極力避けるようにしてます）
> >
> > /usr/lib/rpm/self-build-rpm.sh %{name} %{pkgname}.spec \
> > http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source0path} [^] \
> > http://www{"",2,3,4,5,7,8,1}.mplayerhq.hu/%{source1path} [^]
>
> マスターサーバの優先順位を下げるという提案については賛成です。
> ただ、self-build-mplayer-1.0-6.20090109vl5 以降は Subversion から
> snapshot を取得するようです。
開発者数 << ユーザ数で，単なるユーザの方が圧倒的に多いでしょうから，単にバイナリをインストールして使用する
ためだけの目的でレポジトリサーバにアクセスすることが「妥当か否か」が判断基準でしょうね．
何れにせよ，SVNレポジトリから取得する方針に切り替えるか否かの判断は，パッケージャにお任せします．
お手数をお掛けしました． |
|
|
|
|
勘違いしてました．
> バイナリをインストールして使用する
> ためだけの目的でレポジトリサーバにアクセスすることが「妥当か否か」が判断
> 基準でしょうね．
MPlayerのWebサイトに「スナップショットアーカイブ」が掲載されていますね．
こちらをダウンロードするのですね．
何れにせよ，パッケージャにお任せです．
以上 |
|
|
|
|
|
もともとの問題は解消していますので、これで完了にします。 |
|