日々のあしあと

最近 self-build 用のスクリプトに手を入れている事もあって bash の man ページを結構頻繁に読んでいる。

実は未だに基本的な部分がよく理解できてない(<オイ)ので if 文の書き方やオプションなんかを確認する事が多いんだけど、そんな時にパッと目に入ってきたのが PIPESTATUS というシェル変数。

これ、bash 3.0 以降限定の変数らしいが、パイプでつないだ複数のコマンドの返り値が配列の形で格納されているらしい。

ふむふむと説明を読んでいてピピッときたのが zenity を使ってダウンロードの進捗を表示しているところの処理。

今は wget | sed | zenity とパイプでつないでバックグランドで実行させながら pgrep や ps を使ったかなり adhock なロジックで実行状況を判断しているが、この変数が使えればかなりシンプルに書き換えれるかも知れない。

という事で忘れないようにメモっておこう。

irc での議論もあって、OSC 2010 Tokyo の開催日を目処に Vine Linux 5.1 をリリースする方向で話が進み出したので、じゃあせっかくだから何かアピールできるポイントの一つや二つは欲しいよなと思い、自分に出来そうな事を考えてみた。

1. vine-app-install の対象アプリ拡充
   5.0 のリリース後に Plus に追加されたパッケージが結構あるので、その中からお勧めを募集して追加し、今よりもインストールできるアプリケーションを増やす。
2. vine-app-install の改善
   もうちょっと見栄えを良くして表示する内容ももうちょっと増やす。 あと synaptic に切り替えられるボタンも追加する。
3. self-build の改善
   ビルド(コンパイル)中にもプログレスバーを出したりして、進捗を見える化する。

といった辺りが残りの期間と確保できる作業時間を考えると一杯々かなと。

# 当日お手伝いできるから分からないので、
# 今のうちにできそうなことはやっとこうかなと。

つーことで、とり急ぎプログレス表示用のシェルスクリプトを書いてみた。

使い方は、rpmbuild -bb hoge.rpm | tee build.log | progress.sh みたいな感じなんだけど、まだその手前まで。

#!/bin/sh

COUNT=0
LINES=0
BASE_SIZE=3000
BAR_W=70

bar(){
   while read line; do
      let $((COUNT+=${#line}))
      let $((LINES+=1))
      if [ $(($LINES % 10)) = 0 ]; then
         PERCENT=$((100*COUNT/BASE_SIZE))
         BAR_LEFT=$((BAR_W*COUNT/BASE_SIZE))
         printf "%3d%%[" $PERCENT
         for i in $(seq 1 $BAR_LEFT); do
            printf "="
         done
         printf ">"
         for i in $(seq 1 $((BAR_W-BAR_LEFT))); do
            printf " "
         done
         printf "]\r"
      fi
   done
   printf "\n"
}

./tmp.sh |bar

tmp.sh が適当な文字列を標準出力に出すだけのスクリプトだけど、これが吐き出す文字数と行数を見ながら、こんな感じのプログレス表示をしてくれる。

./progress.sh 
 60%[===================================>                                   ]

BTS に「vine-app-install が ppc で動かない」というレポートがあがったので、定例ミーティング後に irc で話しながら ppc 持ちの人に実際に色々試してもらった結果、src.rpm を ppc 上でリビルドするとちゃんと動くようになることが分かった。

gambas executable は arch 非依存だったように記憶してるんだけど、どうやら違ってたらしい。

という事で vine-app-install (と update-watch と rpminstall)の微修正で対応できるよいで、とりあえず助かった。

協力してくれた皆さんありがとうございました。

# 週末は作業時間が確保できなかったので
# なんとか今日の夜には対応したいなと。

テスト中の XBMC で vdpau を使った再生支援が効くようになったので、HDUSF で録画した地デジの ts ファイルをいくつか再生してみると、数秒おきに一瞬早送りになるのに気づいた。

で、色々怪しいポイントがあったので順に調べていったところ、
・再生ソフトの問題
→mplayer や ffplay でも再現するので関係無し
・アンテナや USB の接続不良
→挿し直したりアンテナケーブルを変えたり USB ポートを変えても変化無し
・録画ソフトの問題
→recfriio のバージョンを変えたりソースをいじってバッファサイズを大きくしてみても変化無し
・録画時のドロップ発生
→tsselect で確認してみても drop はゼロ
・ディスクへの書き込みの問題
→ext3 だと読み/書きが同時に発生するもディスクへの転送が間に合わなくなる、という記述を見たので ext2 でマウントし直してみるも変化無し
といった状態に。

こりゃあハードの故障かな？と諦めつつ色んなチャンネルを録画して実験してみると、チャンネルによってかなり早送り度合いに差がある(NHK はひどいけど TBS はかなりマシ等)ことが分かってきた。

そこで電波の受信状態が影響してるんじゃ無いかと更に検索したところ、「受信している電波が強すぎてもうまく録画できなくなる場合がある」という記述を発見！

早速 recfriio のメッセージで確認してみると60前後あって、ウェブ上の情報と見比べてもかなり強い方だと分かってきた。

そこで試しに間に HDD レコーダーを挟んでアンテナを繋いでみるとはっきりと改善が確認できた。

という事で、次はアッテネータをかましてやろうと考え中。

# 近くの電気やさんに売ってなかったので、
# 通販するか悩み中。

self-build パッケージのインストールで、プログラムをコンパイルしている間、止まっているように見える(進捗が見えない)問題をなんとかできないかなぁ、という話を irc で聞いて、いろいろ考えていたらこんな方法をおもいついた。

1.self-build パッケージを作る時に、ターゲット rpm のビルドログのファイルサイズを確認しておく

2．spec の %posttrans でヘルパースクリプトを呼ぶ時に、ビルドログのサイズも引数として一緒に渡すようにする

3.ターゲット rpm のビルド時に、引数で渡されたログサイズと実際に出力されているログのサイズの比を進捗率として、プログレスバー等で表示する

ビルドログのサイズは環境によって多少バラつくだろうけど、それなりにイケるんでは無いかと。

# どんなもんでしょうかね？＞munepi さん