学校に通わずに学ぶログ

xine のメニューが表示されず、空白になっている。xineの右クリックメニューの日本語が文字化けするか表示されない問題は伝統的なもので、長い間改善されていない模様。 表示されないのは日本語のメニューなので、xtermなどのターミナルエミュレータのコマンドラインで $ LC_ ALL="en_US.utf-8" xine & と入力して起動してやれば、文字化けせずに英語のメニューが表示される。 ネット上でいろいろ調べた結果、もう一つの解決法は、フォント設定及びカスタマイズ用のライブラリである fontconfig を使うこと。fontconfigのパッケージがインストールされていない場合はインストールしておく。 $ su # aptitude install fontconfig 一般ユーザのホームディレクトリに.fonts.confというXML形式の設定ファイルを作成して置いてやる。 <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <!-- ~/.fonts.conf for per-user font configuration --> <fontconfig> <!-- Helveticaフォントよりもunifontフォントのほうを選ぶ --> <alias binding="strong">     <family>Helvetica</family>     <prefer><family>unifont</family></prefer> </alias> </fontconfig> これを.fonts.confというファイル名で自分のホームディレクトリ直下に保存する。 binding="strong"はbinding="same"でもよい。<prefer>は<accept>でもよい。いずれにしても私の環境ではうまくいった。日本語文字の表

前回の投稿「 bloggerにログインできない！？ 」でbloggerのホームページからのサインインではbloggerに正常にログインできず、「Not Found Error 404」と表示されると書いたが、今回のサインインでは正常にログインできたので、すでに改善された模倣。 その報告ということで。

https://www.blogger.com/からサインインすると、 Not Found Error 404 と表示されてログインできなくなる状態がつづいている。ちなみに、「404」はHTTPプロトコルが用いるステータスコードと呼ばれているもの。 https://www.google.com/accounts/でサイインすると正常にログインできるので、現在はこちらからサインインするようにしている。

opera_11.01.1190_i386.debからopera_11.10.2092_i386.debまたはopera_11.11.2109_i386.debにアップグレードしてから、Operaを起動しようとすると「不正な命令です」というエラーメッセージが表示されて起動不能になった。 $ opera 不正な命令です Operaをパージ(purge)し、ホームディレクトリ内の.operaディレクトリを削除してからインストールし直してみても、この症状はまったく改善しなかった。 # aptitude purge opera （中略） # exit $ cd ~ $ rm -r .opera cd ~ はホームディレクトリへと作業ディレクトリを移動することを意味し、 rm -r .opera は.operaディレクトリごと（その下にあるファイルやディレクトリごと）削除することを意味する。 # dpkg -i opera_11.11.2109_i386.deb 未選択パッケージ opera を選択しています。 (データベースを読み込んでいます ... 現在 33300 個のファイルとディレクトリがインストールされています。) (opera_11.11.2109_i386.deb から) opera を展開しています... dpkg: 依存関係の問題により opera の設定ができません: opera は以下に依存 (depends) します: libgstreamer-plugins-base0.10-0 (>= 0.10.16) ...しかし: パッケージ libgstreamer-plugins-base0.10-0 はまだインストールされていません。 opera は以下に依存 (depends) します: libgstreamer0.10-0 (>= 0.10.15) ...しかし: パッケージ libgstreamer0.10-0 はまだインストールされていません。 opera は以下に依存 (depends) します: gstreamer0.10-plugins-good ...しかし: パッケージ gstreamer0.10-plugins-good はまだインストールされていません。 opera

前回、dpkgを使ってインストールしたgoogle-chrome-stableは、aptitudeを使ってアンインストールすることできる。私の場合はsudoを使っていないのでsuを使って一時的にrootになり、google-chrome-stableのdebパッケージをアンインストールすることにした。 アンインストールのためのaptitudeのオプションにはremoveとpurgeがあるが、purgeは設定ファイルまでも削除するので、Googleリポジトリが記載されている/etc/apt/sources.list.d/google-chrome.listファイルまでおそらく削除してしまうだろう。私にとってそれは本意ではなかったので、ここではremoveによってアンインストールした。 $ su # aptitude remove google-chrome-stable これでアンインストールは完了。しかし、インストール時に依存関係のエラーが出て、aptitudeによって追加でインストールしたパッケージ（私の場合はlibxss1）まではアンインストールされなかった。 Googleのリポジトリが記述されているファイルが残っているかを念のために確認した。 $ ls /etc/apt/sources.list.d google-chrome.list 残っていた。このリポジトリファイルまで綺麗さっぱり掃除したければpurgeオプションでアンインストールすればよいと想像するが、ここでは確認しなかった。ただし、purgeオプションでアンインストールしても、各ユーザ用のホームディレクトリに作成される設定ファイル群（~/.config/google-chrome）は、手動で削除しなければならないと思う。 ところで、次のようにしたら、google-chromeのstableバージョン以外にもunstableやbetaバージョンがリポジトリにあることを確認できた。 $ aptitude search google v google-chrome -

oldstableになったLennyの公式リポジトリには Chromium が存在しないようなので、本家Googleの Chrome を入れてみることにした。 まず、ウェブブラウザを起動し、JavaScriptを有効にし、 http://www.google.co.jp/chrome/eula.html を開いた。私の場合は「32ビット.deb（Debian/Ubuntu）」を選び、「同意してインストール」を押した。そして、google-chrome-stable_current_i386.debというファイル（debパッケージ）をパソコンのハードディスク上の私のホームディレクトリに保存。 次に、google-chrome-stable_current_i386.debというファイル名を引数に指定して、このdebパッケージをインストール。私はsudoを入れていないのでsuによってrootになって実行した。 $ su # dpkg -i google-chrome-stable_current_i386.deb 未選択パッケージ google-chrome-stable を選択しています。 (データベースを読み込んでいます ... 現在 67316 個のファイルとディレクトリがインストールされています。) (google-chrome-stable_current_i386.deb から) google-chrome-stable を展開しています... dpkg: 依存関係の問題により google-chrome-stable の設定ができません: google-chrome-stable は以下に依存 (depends) します: libxss1 ...しかし: パッケージ libxss1 はまだインストールされていません。 dpkg: google-chrome-stable の処理中にエラーが発生しました (--install): 依存関係の問題 - 設定を見送ります menu のトリガを処理しています ... man-db のトリガを処理しています ... 以下のパッケージの処理中にエラーが発生しました: google-chrome-stable しかしここで上記のようにエラーが出た。「パッケージ libxss1 はまだインストールされて

perlと名のつくパッケージ関連ですでにインストールされているものをまず調べてみた。 aptitude search perl でperlと名のつくパッケージを検索し、パイプライン(|)を使ってその結果をgrepコマンドに渡し、 '^i [ A]' という正規表現を使って、すでにインストールされているものだけ一覧表示させた。下がその結果。 $ aptitude search perl | grep '^i [ A]' | more i liblocale-gettext-perl - Perl の国際化用に libc 関数を使用 i libtext-charwidth-perl - 端末上で文字の表示幅を取得 i libtext-iconv-perl - Perl で文字セットを変換 i libtext-wrapi18n-perl - Text::Wrap の国際化された代替品 i A libtimedate-perl - Time and date functions for Perl i A perl - Larry Wall 作の実用的な抽出とレポート用の i perl-base - 最小限の Perl システム i A perl-modules - Perl コアモジュール ちなみに、 '^i [ A]' の意味は、^で行頭を表し、行頭にiの文字と空白があり、その次に空白かAの文字がある、ということ。そのつもりだけれども、的確な表現であるかどうかは自信がない。 次に、インストールされているPerlのバージョンを確認しておく。 $ perl -v This is perl, v5.10.0 built for i486-linux-gnu-thread-multi Copyrig

PerlやRubyやPHPなどを使ったウェブアプリケーションのプログラミングについて学ぶため、apacheよりも軽くて高速で動くウェブサーバであるとされるlighttpdをインストールしてみることにした。 # aptitude update; aptitude install lighttpd 以下の新規パッケージがインストールされます: fam{a} libfam0{a} libterm-readkey-perl{a} libterm-readline-perl-perl{a} lighttpd portmap{a} 更新: 0 個、新規インストール: 6 個、削除: 0 個、保留: 0 個。 528kB のアーカイブを取得する必要があります。展開後に 1724kB のディスク領域が新たに消費されます。 先に進みますか? [Y/n/?] ここでYと入力してEnterキーを押せばダウンロードとインストールが始まる。 lighttpdの設定ファイルは/etc/lighttpd/lighttpd.confに存在する。 vim というエディタを使って設定内容を少し修正してみる。 # vim /etc/lighttpd/lighttpd.conf server.modulesでは読み込まれるモジュール名が指定されているようだ。行頭の#はコメントアウトだと思われる。行頭に#を記述するとその行の記述が単なるコメントとして認識されて無効になる。CGIを動作させるためにここにはmod_cgiモジュールを追加した。 server.modules = ( "mod_access", "mod_alias", "mod_compress", "mod_redirect", # "mod_rewrite", "mode_cgi" ) server.document-rootではドキュメントルートすなわちHTMLなどを記述したファイル群を置くディレクトリが指定されているようだ。デフォルトでは"/var/www/html"となっていた

少し前にこのブログに書いた 「Opera11のアップデートで公開鍵が利用できないエラー」 の問題が解決した。というより、いつのまにか解決していた。下のようにarchive.keyをダウンロードし、 apt-key add しても解決しなかったのだが、現在ではそうではないようだ。 # wget -O - http://deb.opera.com/archive.key | apt-key add - 今は上記のようにすればおそらく解決する。おそらくは、公開鍵が2011年のものになっていたにもかかわらず、archive.keyファイルにまでそれが反映されていなかったためではないだろうか？？ それとも他に原因があったのだろうか？？

ある日突然、gmplayerが起動途中で固まって起動に失敗するようになった。何度やっても同じ。コマンドラインインターフェース上で「gmplayer &」と入力し、バックグランドで起動した場合にこのような症状になることを以前にも経験した記憶があるが、今度の場合はどうもそうではないようだ。ちなみに、この症状は「gmplayer」の場合にのみ起こるもので「mplayer」では起こらない。その際に画面に表示されるメッセージは以下のとおり。 $ gmplayer MPlayer dev-SVN-r26940 CPU: *********** processor (Family: 5, Model: 8, Stepping: 12) CPUflags: MMX: 1 MMX2: 0 3DNow: 1 3DNow2: 0 SSE: 0 SSE2: 0 Compiled with runtime CPU detection. Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. *** glibc detected *** gmplayer: double free or corruption (!prev): 0x09e50438 *** ======= Backtrace: ========= /lib/libc.so.6[0xb5d61935] /lib/libc.so.6(cfree+0x9c)[0xb5d637dc] gmplayer(read_font_desc_ft+0xba3)[0x822d573] gmplayer(load_font_ft+0x159)[0x822d6e9] gmplayer(guiInit+0x55b)[0x810034b] gmplayer(main+0x94e)[0x80ade0e]

Operaの最新バージョンを deb.opera.com からaptitudeを使って私はいつもアップグレードしているのだが、最近になって、aptitude updateを実行すると次のようなエラーメッセージが表示されるようになった。 W: GPG error: http://deb.opera.com lenny Release: 公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY A2019EA84E7532C8 W: これらの問題を解決するためには apt-get update を実行する必要があるかもしれません http://deb.opera.comに書かれているように次のようにしてarchive.keyを取得してもこの問題は解決しない。 # wget -O - http://deb.opera.com/archive.key | apt-key add - インターネット上をいろいろ調べてもこの解決策がなかなか見付からないので、やむをえず仕方なくOperaの公式サイトからDebian用のdebパッケージをダウンロードし、dpkgでインストールするしかなかった。 dpkg -i opera_11.00.1176_i386.deb aptitudeのデータベースに不具合が生じるかもしれないので、よい子は真似をしないように（笑）。ただいま、この解決策を模索中。 追記： いつのまにか解決していた。 deb.opera.com の公開鍵が利用できないエラー

USBメモリにファイルを書出したり削除したり移動したり、ディレクトリを作成したり削除したり移動したりすることができなくなった。それらの操作をするとLinux(Debian Gnu/Linux lenny)がそれらのファイルやディレクトリは「読出し専用」だと応答してくる。しかしそれらのファイルやディレクトリのパーミッションを見ると、rwxrwxrwxとなっており、読出し専用には見えない。このUSBメモリにはそれらの操作を物理的にロックする機能は装備されていない。いったいぜんたいどうなってしまったのやら。 不思議なのは、このUSBメモリを一端umountして再度mountするとこれらの症状が一時的にだが改善すること。物理的に完全に破損してしまったのかと最初は諦めかけたのだが、そうこうしているうちに、この症状が改善したり再発したりを繰り返すようになった。この症状が一端出てしまうと再mountしないかぎり改善しないが、再mountすれば改善する。しかし使っているうちにまた再発する。この繰り返し。 再マウントを繰り返しながらファイルを一つずつ削除しているうちに、削除(rm)しようとすると「入力/出力エラー」を生じるディレクトリに遭遇した。このディレクトリだけは再マウントをいくら繰り返しても削除できず、入出力エラーを吐き出し続けた。これについてはUSBメモリのファイルシステムが壊れている可能性が疑われる。 そこで、コマンドライン上でsuコマンドを使ってルートになり、fsckを使ってファイルシステムのチェックを試みたが、失敗した。このUSBメモリのファイルシステムのタイプはどうやらFAT32らしい。FATのチェックのためには、fsck.vfatもしくはfsck.msdosというコマンドが必要なようだが、コマンドライン上でfsckと入力してタブキーを二度押してもfsck.vfatもfsck.msdosも表示されなかった。 $ apt-cache search fsck.vfat dosfstools-dbg - utilities for making and checking MS-DOS FAT filesystems (debug) dosfstools - MS-DOS FAT ファイルシステムの作成および検査用ユーティリティ 上述のように、dosfstoolsというdeb