Vine Linux バグトラッキングシステム
メイン | マイビュー | 検索 | 変更履歴 | ロードマップ | Vine Linux ホーム
  

課題の詳細を表示 [ コメントにジャンプ ] [ 課題の履歴 ] [ 印刷 ]
IDプロジェクトカテゴリ登録日最終更新
0000661Vine Linux1 バグ2009-02-04 18:232009-05-13 21:19
報告者anonymous 
担当者packager 
優先度中再現性不明 
状態完了解決状況不明 
バージョン4.2 
修正予定バージョン修正済バージョン 
概要0000661: MPlayerからのエラーメッセージ
説明Vine 4.2 + 全てのアップデート適用の環境にself-build-mplayer-1.0-2.rc2vl4を導入しました．
コマンドラインからmplayerを起動すると，

Cannot load bitmap font: /usr/share/mplayer/font/font.desc

といったエラーメッセージが表示されます．（日本語表示だったかも知れません．）
また，GUI表示のgmplayerを起動すると，同様のメッセージダイアログが画面にポップアップ表示されます．

ちょっと調べたところ，以下の問題と同様の現象と思われます．
http://bbs.archlinux.org/viewtopic.php?id=63623 [^]
http://bugs.archlinux.org/task/12900 [^]

原因は，MPlayerパッケージのビルド時のconfigureオプションの -enable-freetypeについて，autodetectされた結果が何故だかdisableと判定されてしまうためのようです．
パッケージ中のmplayer.specのconfigureオプションを若干修正して，

cc2002(1093)$ diff -uNr mplayer.spec.orig mplayer.spec
--- mplayer.spec.orig 2009-02-04 18:19:24.000124000 +0900
+++ mplayer.spec 2009-02-04 17:07:24.000000000 +0900
@@ -88,6 +88,7 @@
             --confdir=%{_sysconfdir}/mplayer \
             --enable-largefiles \
             --enable-gui \
+ --enable-freetype \
             --language=ja,en
 
 %{__make}

という具合に修正したものを，ビルド・インストールすると，エラーメッセージは出なくなりました．

以上，ご報告まで
タグ設定されていません。
archx86
パッケージself-build-mplayer-1.0-2.rc2vl4
添付ファイル

- 関連

-  コメント
(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 としたら、どうなりますか？
(0003003)
anonymous (参照)
2009-02-05 19:27

 京都産業大学の大本です．

申し訳ありません．当方の勘違いがエラーの原因だったようです．
エラーの原因は，古い個人設定 ~/.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 [^]
(0003005)
anonymous (参照)
2009-02-09 17:09

 大本＠京都産業大学です．

> また、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 を取得するようです。
(0003007)
anonymous (参照)
2009-02-12 17:25

 大本＠京都産業大学です．

基本的には本件は収束してきたと思うので，クローズして頂いて差し支えないと思います．

> > 例えばソースコード取得部を次のようにしてはどうでしょうか？ （ついでにマス
> > ターサーバを極力避けるようにしてます）
> >
> > /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レポジトリから取得する方針に切り替えるか否かの判断は，パッケージャにお任せします．

お手数をお掛けしました．
(0003008)
anonymous (参照)
2009-02-12 17:37

 勘違いしてました．

> バイナリをインストールして使用する
> ためだけの目的でレポジトリサーバにアクセスすることが「妥当か否か」が判断
> 基準でしょうね．

MPlayerのWebサイトに「スナップショットアーカイブ」が掲載されていますね．
こちらをダウンロードするのですね．
何れにせよ，パッケージャにお任せです．

以上
(0003009)
kazutaka (開発者)
2009-05-13 21:19

 もともとの問題は解消していますので、これで完了にします。

- 課題の履歴
変更日 ユーザー名 項目 変更内容
2009-02-04 18:23 anonymous 新規課題
2009-02-04 23:51 munepi コメント追加: 0003002
2009-02-05 19:27 anonymous コメント追加: 0003003
2009-02-07 01:36 ats7 コメント追加: 0003004
2009-02-09 17:09 anonymous コメント追加: 0003005
2009-02-12 00:30 ats7 コメント追加: 0003006
2009-02-12 17:25 anonymous コメント追加: 0003007
2009-02-12 17:37 anonymous コメント追加: 0003008
2009-05-13 21:19 kazutaka 担当者 => packager
2009-05-13 21:19 kazutaka 状態 新規 => 完了
2009-05-13 21:19 kazutaka コメント追加: 0003009

Copyright © 2000 - 2024 MantisBT Team
Copyright © 2012 - 2024 Project Vine
Powered by Mantis Bugtracker