2013/10/10(木)Windows SDKのインストールが失敗する
2013/10/10 9:56
Windows SDK7.1は生半では綺麗にインストールできない。
[参考]
Windows SDK for Windows 7.1 をインストールするとエラーが発生する - Microsoft.NET - Project Group
2013/10/09(水)Windows時刻同期メモ
2013/10/09 17:49
Windows7/XPで、NTPサーバと時刻同期させている(つもり)がずれていることが頻繁にある。
Windowsの標準時刻同期サービスは設定がGUI、サービス、レジストリに分散してしまっていて大変に分かりづらい。機能実装時にActive Directoryが前提だった節もある。しばらく観察して、ずれが解消しないようならpycronやフリーウェアでの調整を考えたい。
要求1: 最低1日1回NTPサーバと同期すること
要求2: 常時、NTPサーバとの時刻ズレが5.0sec以内であること
とりあえず、設定にミスがないか確認する。
・タスクバーの時刻プロパティで"インターネット時刻サーバーと同期する"にチェックされていることを確認。
・管理ツール->サービス->Windows Timeが"開始"かつ"スタートアップの種類"が"自動(遅延実行)"になっていることを確認。
以上の状態でこれから1週間ほど調査する。調査はとりあえず、以下のコマンドで実施。
>w32tm /stripchart /computer:ntp.nict.jp /period:120
>w32tm /monitor /computers:ntp.nict.jp要求としては5.0sec以内であるが、観察期間が短いので3.0secずれたらアウトということにする。
[追記]
上記の設定だけだと、Windows7ではデフォルトの1週間同期になってしまうようだ。参考サイト等を踏まえて考えると、
・ntp.nict.jpはデフォルトサーバ設定0x9(0x1+0x8)なのでSpecialPollIntervalの等間隔同期に従う
・デフォルトのSpecialPollIntervalは604800(604800秒=1週間)
結局やりたくなかったけど、レジストリ弄るのが簡単。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient
のSpecialPollIntervalを43200(43200秒=半日)にする。これでとりあえず様子見。
ローカルポリシーでも設定できるようなので、直接レジストリ弄るのとどちらがまともなのかは今後検討することにする。
[参考]
Windowsネットワーク時刻同期の基礎とノウハウ：第1回 Windows OSにおける時刻同期サービスとNTP (3/4) - ＠IT
2013/07/17(水)apt周りあれこれ(続き)
2013/07/17 11:50
dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。24687 行目付近、パッケージ 'am-utils': `amd' を参照する `Replaces' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。24690 行目付近、パッケージ 'am-utils': `amd' を参照する `Conflicts' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。58611 行目付近、パッケージ 'root-tail': `rt' を参照する `Conflicts' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。73297 行目付近、パッケージ 'wmnetselect': `mozilla' を参照する `Suggests' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。77093 行目付近、パッケージ 'e3': バージョン文字列 'e3-2.30-1' にエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。84479 行目付近、パッケージ 'tac-plus': バージョン文字列 'F4.0.4.alpha-9.1' にエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。139337 行目付近、パッケージ 'epic4-script-thirdeye': `epic4' を参照する `Depends' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。165107 行目付近、パッケージ 'cnews': バージョン文字列 'cr.g7-31' にエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。208613 行目付近、パッケージ 'request-tracker1': `rt' を参照する `Conflicts' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません dpkg: 警告: ファイル '/var/lib/dpkg/available' を解析。221822 行目付近、パッケージ 'epic4': `epic4-help' を参照する `Conflicts' フィールド: バージョンにエラー: バージョン番号が数字から始まっていません (データベースを読み込んでいます ...はい、available絡みですね。古いリポジトリ情報が残ってるんでしょう。
# dpkg --clear-availこれで解消。
dpkg: 警告: ファイル '/var/lib/dpkg/status' を解析。1703 行目付近、パッケージ 'doc-debian-ja': architecture が見つかりませんこっちはなんだろ。apt-show-versionsで見てみる。
# apt-show-versions -a doc-debian-ja doc-debian-ja 2.2.2.2 install ok installed No stable version No stable-updates version No testing version No unstable version doc-debian-ja 2.2.2.2 installed: No available version in archiveうーん、現バージョンなしdocということで消す。
#dpkg -r doc-debian-jadpkgの警告はこれで解消。
で、insserv: warning: script 'hogehoge' missing LSB tags and overrides
がたくさん出るけどこれはどうしようもない気がするので保留。起動スクリプトに決まった書き方が出来たんだろうけどうーん全部直すのはことだぞ。
あと、qmailの依存関係を暇なときに解消することにする。
こっから愚痴だけど、debianは保守的なのが売りなのにubuntuからのフィードバックで更新が加速してしまった。wheezy前後でかなりパッケージシステムに改訂が入った模様。
整備されていくのはよいことだが、変わったものが短期間でまた変わらないか危惧はしている。警告基準が変わるのも厄介。update-rc.dもinsservになってしまったし、うーんこれで綺麗になっているなら良いのだが継続的に変わるようだといやだな。
まあ情報仕入れてない私が悪いのだ。元々は勉強用だった自宅鯖。その役割は十分に果たしたし、便利に使ってはいるが今の自分には管理コストが高過ぎる気がする。自宅鯖はどこかで諦めなければいけないかも知れない。とりあえず今回の一連の作業でaptがあまりに遅かったため、サーバハードのアップグレードは考え中。
サービス絞ってwinサーバにしちゃうってのはアリでしょうねえ……
[2013/11/13追記]
qmail周りの依存関係を整理して入れ直した。
ごたごたしていて細かいメモを紛失した。
ほぼ以下の通り。
debian/wheezy で qmail を入れる - T-Saitohの仕事日記
現状メールサーバは送信だけ出来ればいいやの世界になってきたので、Postfixへの切り替えを考え中。
2013/07/16(火)apt周りあれこれ
2013/07/16 27:07
#aptitude upgradeしようとしたら、依存関係が色々ぶつかって通らなくなってた問題。
(いつも通り、先頭sudoは適宜読み換えて下さい)
wheezyにしたときにちゃんと整備してなかったのが今になって出てきたっぽい。
とりあえず、
#aptitude upgrade --full-resolverして、お勧めの方法でやってしまう。
slang1:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
gnome-users-guide-es:none : 依存: scrollkeeper:none[仮想パッケージです]
libpcap0:none : 依存: libc6:none (>= 2.2.3-7)[仮想パッケージです]
libperl5.6:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
ide-smart:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libguile9 : 依存: libreadline4 (>= 4.3-1)[仮想パッケージです]
perl-5.6:none : 依存: perl:none (>= 5.6.0-20)[仮想パッケージです]
libident:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
nas-lib:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libcap1:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
webrick:none : 依存: libruby:none (>= 1.6.5)[仮想パッケージです]
libpisock4:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libg++27 : 依存: libc5 (>= 5.4.7-6)[仮想パッケージです]
mc-common:none : 依存: perl:none[仮想パッケージです]
python2.1 : 依存: libreadline4 (>= 4.3-1)[仮想パッケージです]
slang1a-utf8:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
libdns5:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
aalib1 : 依存: slang1 (> 1.4.9dbs-4)[仮想パッケージです]
kjc:none : 依存: java-common:none[仮想パッケージです]
watanabe-vfont:none : 依存: vflib2:none (>= 2.25.1-4.1)[仮想パッケージです] または
vflib3:none (>= 3.6.8-1.1)[仮想パッケージです]
ipchains:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
依存: debconf:none[仮想パッケージです]
gnome-users-guide:none : 依存: scrollkeeper:none[仮想パッケージです]
libdb2:none : 先行依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
libdb2-util:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
libisc4:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libjasper-1.701-1:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
依存: libjpeg62:none[仮想パッケージです]
libdb4.0:none : 依存: libc6:none (>= 2.3.2-1)[仮想パッケージです]
libjcode-perl:none : 依存: perl5:none[仮想パッケージです]
ipmasqadm:none : 依存: libc6:none (>= 2.2.2-2)[仮想パッケージです]
libupnpsdk1:none : 依存: e2fsprogs:none (>= 1.27-2)[仮想パッケージです]
依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
依存: libuuid1:none[仮想パッケージです]
libmm11:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libmm13:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
perl-5.6-base:none : 依存: perl-base:none (>= 5.6.0-20)[仮想パッケージです]
linuxigd:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
依存: libstdc++2.10-glibc2.2:none (>= 1:2.95.4-0.010810)[仮想パッケージです]
libnkf-ruby:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
依存: libruby:none (>= 1.6.7-3woody5)[仮想パッケージです]
libnewt0:none : 依存: libc6:none (>= 2.2.4-4)[仮想パッケージです]
libreadline4:none : 依存: libc6:none (>= 2.3.2.ds1-4)[仮想パッケージです]
依存: libncurses5:none (>= 5.4-1)[仮想パッケージです]
ldso:none : 依存: libc6:none (>= 2.1.94)[仮想パッケージです]
以下のアクションでこれらの依存関係の問題は解決されます:
以下のパッケージを削除する:
1) aalib1
2) gnome-users-guide:none
3) gnome-users-guide-es:none
4) ide-smart:none
5) ipchains:none
6) ipmasqadm:none
7) kjc:none
8) ldso:none
9) libc5:none
10) libcap1:none
11) libdb2:none
12) libdb2-util:none
13) libdb4.0:none
14) libdns5:none
15) libg++27
16) libguile9
17) libident:none
18) libisc4:none
19) libjasper-1.701-1:none
20) libjcode-perl:none
21) libmm11:none
22) libmm13:none
23) libnewt0:none
24) libnkf-ruby:none
25) libpcap0:none
26) libperl5.6:none
27) libpisock4:none
28) libreadline4:none
29) libupnpsdk1:none
30) linuxigd:none
31) mc-common:none
32) nas-lib:none
33) perl-5.6:none
34) perl-5.6-base:none
35) python2.1
36) slang1:none
37) slang1a-utf8:none
38) watanabe-vfont:none
39) webrick:none
この解決方法を受け入れますか? [Y/n/q/?]
受け入れた。うーん、noneはパッケージ消失だと思うのだがlibc6絡みで消えてる奴はなんなのだ。で、linuxigd(upnpdを提供してるパッケージ)だけ消えてくれない。
Stopping linuxigd: upnpd invoke-rc.d: initscript linuxigd, action "stop" failed.
Starting linuxigd: upnpd/usr/bin/upnpd: error while loading shared libraries: libupnp.so.1: cannot open shared object file: No such file or directory invoke-rc.d: initscript linuxigd, action "start" failed. dpkg: クリーンアップ中にエラーが発生しました: サブプロセス インストール済みの post-installation スクリプト はエラー終了ステータス 127 を返しました 処理中にエラーが発生しました: linuxigdとりあえずupnpdは今使ってなかったと思うので、何とかして消す。
インストール・アンインストールのプリ・ポストプロセス周りで問題が出ている模様。
/var/lib/dpkg/info/にここらのスクリプトが集まっているので中身を見る。
$cat /var/lib/dpkg/info/linuxigd.prerm
#!/bin/sh
set -e
# Automatically added by dh_installinit
if [ -x "/etc/init.d/linuxigd" ]; then
if [ -x /usr/sbin/invoke-rc.d ] ; then
invoke-rc.d linuxigd stop
else
/etc/init.d/linuxigd stop
fi
fi
# End automatically added section
こいつは止めてるだけだな。で、結論から言うととりあえず手動で止めて、このスクリプト消してしまうのが手っ取り早いと思う。
#mv /var/lib/dpkg/info/linuxigd.prerm /var/lib/dpkg/info/linuxigd.prerm.origプリ部分はこれでOK。ポスト部分はメモってなかったが同様の方法で問題なかったと思う。
これで晴れて、
#dpkg -r linuxigdが通った。
乱暴だが、そもそもパッケージの作りがおかしいので仕方ない。
2013/06/17(月)アンテナ配線周りあれこれ
2013/06/17 20:07
6月頭スカイツリー移転絡みでアンテナ調整が行われた。MX以外の地デジチャンネルは堅調なのだが、MXだけかなり状態が悪くなってしまった。
自宅は集合住宅なので、自分でアンテナや共用部分の配線を弄ることは出来ない。出来ることは限られるがとりあえず足掻くだけは足掻いてみた。
で、色々やってみたら状況は改善したのだがイマイチ原因も確定しないし、今後問題も出そうな気もする。なので一応メモを残しておきたい。
dB値はTVTest読み。
↓がスカイツリー変更後の状態
[壁面テレビ端子 -> 5C-FV 15m -> 8分配 -> S-4C-FB 1m -> TUNER IN] TOKYO MX 11.00dB ×視聴不可↓分配を止めたら、とりあえず映るには映ったけどギリギリ。これでは分配も出来ないし、天候にも左右されそう。ちょっと厳しい。
[壁面テレビ端子 -> 5C-FV 15m -> S-4C-FB 1m -> TUNER IN] TOKYO MX 15.00dB ○視聴可能で、このあとブースター(VB-33CU)を分配器の前に入れてみた。この時はちゃんとメモってなかったので記憶頼り。
[壁面テレビ端子 -> 5C-FV 15m -> (混合入力)VB-33CU -> 8分配 -> S-4C-FB 1m -> TUNER IN] TOKYO MX 15dB(記憶あやふや)
[壁面テレビ端子 -> 5C-FV 15m -> (別入力)VB-33CU -> 8分配 -> S-4C-FB 1m -> TUNER IN] TOKYO MX 22dB(記憶あやふや)VB-33CUには混合入力と別入力(UHF/BS・CS)とあり、別入力の場合別端子にそれぞれの同軸ケーブルを繋ぐ。モードの切り替え自体はスイッチで行う。
5C-FV 15mをブースターの混合入力に入れ、設定を混合にするとやはり15dB前後。しかし接続はそのままで、モードのみ別入力にする(分配後のBS入力は死ぬ)と22dB位に改善した。
ここでもしかしてブースター内部のLPFが効いてる？ という辺りに考えが至る。反射波かノイズが悪さをしているんじゃないか。LPFが効くならば分波器で改善する？ と思って分波器を調達したのが↓
[壁面テレビ端子 -> 5C-FV 15m -> 分波器 -> 8分配 -> S-4C-FB 1m -> TUNER IN] TOKYO MX 9.75dB ×視聴不可駄目。安いとはいえ分波器で1.25dBも下がるンだっけという疑問もありつつ、あと考えられるのは、そもそも家のアンテナコネクタに来てる信号が弱すぎるのか。ということはブースターを入れる位置が間違ってる…
[壁面テレビ端子 -> S-4C-FB 50cm -> (混合入力)VB-33CU -> 5C-FV 15m -> 8分配 -> S-4C-FB 1m -> TUNER IN] TOKYO MX 25.11dB ○視聴可能
一応、dB値では改善した！
うーん、集合住宅ではブースターでコネクタにかなり高レベルの信号が来ている認識だった(C/NのCレベルが電圧上限に近くなっている)。そのため、ブースターを根本に入れても改善はしない、ケーブル損失は補正できるが微々たるものくらいだと思っていたので完全に想定外。
コネクタの時点でC/NのCが低すぎて、ケーブルの損失が他のチャンネルよりも大きくC/Nを劣化させたということだろうか。
そうすると、共用部の配線に問題があるとしか…
なお、これらの作業のどの過程でもNHK～FUJITVでは35dB前後で大きな変動はなかった。
ブースターを挟んで以降、非ドロップのブロックノイズを頻繁に見るようになった気もするのでちょっと様子を見てまた見直したい。
2013/05/08(水)libccid VerUpに伴うB-CASカード周りの設定変更
2013/05/08 24:56
今回はpcscd, bcs-perl 周りの話。
wheezyにして以降、pcsc_scanしてもカードが出てこない。
原因は、libccidのバージョンが変わった所為でカードリーダを認識しなくなったからのようだ。
[参考]
Linux/テレビ関連/libccid - PukiWiki Plus!
とりあえず、libccid_Info.plistにエントリを追加してpcscdを再起動すれば良い。
$diff /etc/libccid_Info.plist /etc/libccid_Info.plist.orig 328d327 < <string>0x04E6</string> 554d552 < <string>0x511A</string> 780d777 < <string>SCM SCR 3310 NTTCom</string> #/etc/init.d/pcscd restartbcs-perl側の名前が"SCM SCR 3310 NTTCom"なのでそのまま入れてやる。
pcsc_scanしてカードの検出、bcs-perl listしてカードの認識が出来てることを確認すること。pcsc_scanがだめならpcsc側のリストをチェック、bcs-perl listがダメならbcs-perl.pl内のカード名($selected_reader)が怪しい。
パッケージ作り直す、unstableにするという方法もあるがうーん、依存の整理とか考えたくない……
[2013/10/11 追記]
後日、カードリーダを指し直したらまたbcs-perl listで取れる名前が変わってしまった。うーん、カードリーダ同じ型番でも取れるものが違うのか、ドライバ周りで細かく変わるものなのか……
bcs-perlを弄って修正。
[参考]
ぼんぼんブログ - ぼんぼん工房
2013/02/21(木)RubyでUTF-8ファイル名＆外部コマンド実行
2013/02/21 16:33
Rubyの``やsystemで外部コマンド実行するときに、実行ファイル自体や引数にUTF-8文字(SJISマッピング無し)が渡せないのであれこれ悩んだ問題。
確認はWindows7 64bit & Ruby1.9.3p0(ActiveScriptRuby)
前提。WindowsはファイルシステムがNTFSならUTF-8ファイル名を命名できる。内部コードもUTF-8になっている(はず)。しかし古いAPIを触ったり、INPUT/OUTPUT周りを見るとまだShiftJIS(Windows-31J)が多い。このズレは厄介で、ハマりどころのA代表。特にRubyの場合、UNIX寄りでWindows特有処理のケアはやっぱり甘い…
閑話休題。Windows&UTF-8の扱いが比較的良くなっているRuby1.9系(Dir.globの引数に.encode('utf-8')などでUTF-8文字列を渡すとUTF-8ファイル名が取れる)でも、マジックコメント入れてUTF-8保存しただけだと外部実行が出来ない。
# -*- encoding: utf-8 -*- # -*- coding: utf-8 -*- `utf8_filename`どうにも通らない。SJISマッピング出来るファイルなら、SJISでやればいいだけの話なのだがUTF-8にあってSJISにない文字(U+2661(はーと)とか)が混ざってると動かない。
で、とりあえず色々やってみたのだが、結論から言うと綺麗に書くのは諦めた。
ちゃんと調べるべきなのだが(やってない)、どうもRubyが叩いてるAPI自体が古いんじゃないかという。
unicode - Ruby system() doesn't accept UTF-8? - Stack Overflow
なので、苦肉の策。
バッチファイルを作成して、それを実行する。
# -*- encoding: utf-8 -*-
# -*- coding: utf-8 -*-
open("tmp.bat", "w"){ |fp|
fp.write("chcp 65001\n")
fp.write("utf8_filename\n")
}
out = `tmp.bat`
Windowsのバッチ実行ではコードページが合えば、UTF-8ファイル名も通るのでそれを利用する。引数にファイル名を指定するときも同様。\\の数とかダブルクオート囲いとか先頭に./が必要な場合は適切にすること。うーん、汚すぎて死にそう。
[参考]
Rubyで外部コマンドを実行して結果を受け取る方法あれこれ #Ruby - Qiita
systemuは知らなかった。
[2017/05/02 追記]
やはりきれいには書けていないが、さすがにbatを吐き出すのは汚すぎるということで苦肉の策第二段。小改善してみた。今回はnyagosを使用している。
out = ""
Open3.popen3("c:/********/nyagos.exe"){ |stdin, stdout, stderr, thread|
stdin.puts("chcp 65001")
stdin.puts("#{COMMAND} \"#{utf8_filename}\"")
stdin.close
out = stdout.read
}
nyagosでなくても良いのだが、cmd.exeやnyaos.exeだとchcp 65001したあとにUTF-8を流し込めない。ここらへんは、chcp後に貼り付けが出来るかどうかで確認する。
Windows APIを直接叩けば済むような問題に見えるんだよなあ。
ここはまた次回。