debian lenny へ openoffice 関連のアップデートが大量に届いていました。
アップデートマネージャーで処理しました。
2010年8月31日火曜日
2010年8月28日土曜日
FreeBSD php5-5.3.3_1 へアップグレード
FreeBSD の ports へ php5 のアップデートが入っていました。一緒に extension もアップデートが入っていたので、全部まとめて portupgrade -a で処理しました。
php5-5.3.3 < needs updating (port has 5.3.3_1)
php5-5.3.3 < needs updating (port has 5.3.3_1)
2010年8月27日金曜日
10年前に書き込んだCD-Rが読み出せません
以前から気になってはいたのですが、CD-Rの読み出し不良が大発生しています。
写真フィルムをスキャニングしたデータをせっせとCD-Rへ焼いて保存していたのは10年以上前のことです。最近古いCD-Rを引き出して中身を見ようとすると読み出し不良が発生することが目立ってきました。いわゆるCRCエラーです。
ここで一念発起してファイルサーバーへこれらのCD-Rのデータを移管させることを決意しました。しかしいきなり連続して何枚ものCD-RがCRCエラーで読み取れなくなっていて途方に暮れています。
いやはやどうしたものかと。実のところ5年前ぐらいからヤバいと感じていたのですが、なかなか重い腰を上げることが出来なかったもので。。。
エラーが多く発生しているのは台湾製のARITA(RiTEK)の12倍速のものです。パッケージがオレンジ色でえぐい模様が描かれているものです。ネット上を検索すると初期のフタロシアニンを使用したもののようです。
傾向として外周部でのエラーが急増しているようです。そのため700MBのうち半分程度しか書き込んでいないものはエラーなくコピーが完了します。しかし75%を越えるものは一様にコピーの終わり頃にエラーが発生しています。特に外周部いっぱいまで書き込んだものは100%エラーが発生します。
とりあえずコピーできる部分だけでも救おうとコピーを始めています。
そしてエラーの出たCD-Rにはマークをつけて再度吸いだしに挑戦しています。
取り合えずCD-Rを冷凍庫で冷やして読み出す方法も試してみましたが、ダメでした。エラーで停止した後、CD-Rをドライブから取り出すとほっかほかの状態でした。冷やすと効果があるというのは本当なのでしょうか？都市伝説？
ddrescueを使ってエラーブロックの再読み込みなどの方法で出来るだけデータを回収することでこれからの段取りを考えていますが、これが効率が悪くてどうしようかと悩んでいます。
このCD-Rのデータ回収については、随時報告をしたいと思っています。
写真フィルムをスキャニングしたデータをせっせとCD-Rへ焼いて保存していたのは10年以上前のことです。最近古いCD-Rを引き出して中身を見ようとすると読み出し不良が発生することが目立ってきました。いわゆるCRCエラーです。
ここで一念発起してファイルサーバーへこれらのCD-Rのデータを移管させることを決意しました。しかしいきなり連続して何枚ものCD-RがCRCエラーで読み取れなくなっていて途方に暮れています。
いやはやどうしたものかと。実のところ5年前ぐらいからヤバいと感じていたのですが、なかなか重い腰を上げることが出来なかったもので。。。
エラーが多く発生しているのは台湾製のARITA(RiTEK)の12倍速のものです。パッケージがオレンジ色でえぐい模様が描かれているものです。ネット上を検索すると初期のフタロシアニンを使用したもののようです。
傾向として外周部でのエラーが急増しているようです。そのため700MBのうち半分程度しか書き込んでいないものはエラーなくコピーが完了します。しかし75%を越えるものは一様にコピーの終わり頃にエラーが発生しています。特に外周部いっぱいまで書き込んだものは100%エラーが発生します。
とりあえずコピーできる部分だけでも救おうとコピーを始めています。
そしてエラーの出たCD-Rにはマークをつけて再度吸いだしに挑戦しています。
取り合えずCD-Rを冷凍庫で冷やして読み出す方法も試してみましたが、ダメでした。エラーで停止した後、CD-Rをドライブから取り出すとほっかほかの状態でした。冷やすと効果があるというのは本当なのでしょうか？都市伝説？
ddrescueを使ってエラーブロックの再読み込みなどの方法で出来るだけデータを回収することでこれからの段取りを考えていますが、これが効率が悪くてどうしようかと悩んでいます。
このCD-Rのデータ回収については、随時報告をしたいと思っています。
2010年8月24日火曜日
FreeBSD sqlite3 の ports 再び
sqlite3 に不具合があったのでしょうか？再び ports へ sqlite3 のアップデートが入っていました。
その他のアップデートと一緒に portupgrade で処理しました。
p5-BerkeleyDB-0.41 < needs updating (port has 0.42)
p5-HTML-Parser-3.66 < needs updating (port has 3.67)
sqlite3-3.6.23.1_2 < needs updating (port has 3.6.23.1_3)
その他のアップデートと一緒に portupgrade で処理しました。
p5-BerkeleyDB-0.41 < needs updating (port has 0.42)
p5-HTML-Parser-3.66 < needs updating (port has 3.67)
sqlite3-3.6.23.1_2 < needs updating (port has 3.6.23.1_3)
2010年8月23日月曜日
FreeBSD 再びghostscript のアップデート
ghostscript などのアップデートが ports へやってきました。
特に考えることなく portupgrade で処理しました。
ghostscript8-nox11-8.71_4 < needs updating (port has 8.71_5)
ruby+nopthreads-1.8.7.248_2,1 < needs updating (port has 1.8.7.248_3,1)
sqlite3-3.6.23.1_1 < needs updating (port has 3.6.23.1_2)
特に考えることなく portupgrade で処理しました。
ghostscript8-nox11-8.71_4 < needs updating (port has 8.71_5)
ruby+nopthreads-1.8.7.248_2,1 < needs updating (port has 1.8.7.248_3,1)
sqlite3-3.6.23.1_1 < needs updating (port has 3.6.23.1_2)
2010年8月22日日曜日
ブラザーのフック部品
故障したブラザーの MFC-830CLN のフック部品を調べたときに写真を撮影しておいたものです。
フック部分は使用頻度が高いものですので、電気的なスイッチを使用することは少なく、写真のように光学的な方法でオン・オフをするものが多いようです。
フックが下がっているときには黒いプラスチックでLEDとフォトトランジスタ（フォトダイオード）の間を遮蔽してオフの状態にしています。この付近かと思ってこの素子をアルコールで洗浄してみましたが症状は改善しませんでした。
もうこれ以上深追いすることなく、元の状態に組み立て直しておきました。
フック部分は使用頻度が高いものですので、電気的なスイッチを使用することは少なく、写真のように光学的な方法でオン・オフをするものが多いようです。
フックが下がっているときには黒いプラスチックでLEDとフォトトランジスタ（フォトダイオード）の間を遮蔽してオフの状態にしています。この付近かと思ってこの素子をアルコールで洗浄してみましたが症状は改善しませんでした。
もうこれ以上深追いすることなく、元の状態に組み立て直しておきました。
ブラザー MFC-695CDN が届きました
もう5年ほど前に購入したブラザーの MFC-830CLN が8月14日に壊れてしまいました。
壊れ方が少し珍しく電気的にフックが上がったままの状態になってしまいました。いわゆる受話器が外れている状態です。そのため電話を掛けてもらってもいつも通話中の状態になっていました。
もちろん物理的にはちゃんとフックは下がっています。受話器が物理的に取り外せるようになっていますが、この連結部分も点検してみましたが症状は変わりませんでした。
ブラザーへ修理に出そうかと迷いましたが、結局新しい後継機種(MFC-695CDN)を購入しました。
再びブラザーを選んだのはもちろんLinuxへの対応がよかったからです。もちろん置き換えの意味もあったので、置き換えてすぐに学習なしで使えるというのもポイントが高いところです。デザインは違いますが、ボタンの配置も似ているのですぐにファクシミリなどが使えました。
以下は開梱の様子を撮影したものです。
通信販売で購入したため宅配便で到着しました。到着した外観の様子です。
これは蓋を開いたところです。いわゆるプラスチック素材のクッション材は見当たりませんでした。この頃のエコロジー梱包の流れのようです。
灼熱の夏の太陽の中、シール材を剥いだり、受話器部分の組み立てを行いました。
そして古い MFC-830CLN と並べてみたところです。若干サイズが大きくなっているようです。ペーパートレイなどが二段になるなどの改良が行われていることから若干大きくなったようです。
メインで使用している WindowsXP のマシンでは一旦古いソフトウェアをすべて削除して新しくソフトウェアを入れ直しました。似たような機能のソフトに重ねてインストールするのはいろいろと問題が発生した経験があったためでした。面倒でも一旦削除するのがよい結果が得られることが多いようです。
パソコンとの接続はLANケーブルで接続しました。すでに以前の MFC-830CLN で使用していたものをそのまま使いました。なんと本体にあるケーブルを通す溝の寸法も同じだったので以前のケーブルについている曲がり癖がそのまま填まっていました。
WindowsXP マシンを設定した後、その他の Linux マシンでも使用できるようにLPRとCUPSドライバーをインストールして印刷が出来るようにしておきました。これで新しいプリンタ複合機がいままでどおりに使用できるようになりました。
壊れ方が少し珍しく電気的にフックが上がったままの状態になってしまいました。いわゆる受話器が外れている状態です。そのため電話を掛けてもらってもいつも通話中の状態になっていました。
もちろん物理的にはちゃんとフックは下がっています。受話器が物理的に取り外せるようになっていますが、この連結部分も点検してみましたが症状は変わりませんでした。
ブラザーへ修理に出そうかと迷いましたが、結局新しい後継機種(MFC-695CDN)を購入しました。
再びブラザーを選んだのはもちろんLinuxへの対応がよかったからです。もちろん置き換えの意味もあったので、置き換えてすぐに学習なしで使えるというのもポイントが高いところです。デザインは違いますが、ボタンの配置も似ているのですぐにファクシミリなどが使えました。
以下は開梱の様子を撮影したものです。
通信販売で購入したため宅配便で到着しました。到着した外観の様子です。
これは蓋を開いたところです。いわゆるプラスチック素材のクッション材は見当たりませんでした。この頃のエコロジー梱包の流れのようです。
灼熱の夏の太陽の中、シール材を剥いだり、受話器部分の組み立てを行いました。
そして古い MFC-830CLN と並べてみたところです。若干サイズが大きくなっているようです。ペーパートレイなどが二段になるなどの改良が行われていることから若干大きくなったようです。
メインで使用している WindowsXP のマシンでは一旦古いソフトウェアをすべて削除して新しくソフトウェアを入れ直しました。似たような機能のソフトに重ねてインストールするのはいろいろと問題が発生した経験があったためでした。面倒でも一旦削除するのがよい結果が得られることが多いようです。
パソコンとの接続はLANケーブルで接続しました。すでに以前の MFC-830CLN で使用していたものをそのまま使いました。なんと本体にあるケーブルを通す溝の寸法も同じだったので以前のケーブルについている曲がり癖がそのまま填まっていました。
WindowsXP マシンを設定した後、その他の Linux マシンでも使用できるようにLPRとCUPSドライバーをインストールして印刷が出来るようにしておきました。これで新しいプリンタ複合機がいままでどおりに使用できるようになりました。
2010年8月20日金曜日
debian lenny カーネル・アップデート
debian lenny へ kernel のアップデートがやってきました。
linux-image-2.6.26-2-686 2.6.26-24 ＞ linux-image-2.6.26-2-686_2.6.26-24lenny1_i386.deb
その他 ghostscpript 関連のアップデートもありました。
ghostscript ghostscript-x gs-common gs-esp libgs8
いつものようにアップデート・マネージャーで処理しました。
linux-image-2.6.26-2-686 2.6.26-24 ＞ linux-image-2.6.26-2-686_2.6.26-24lenny1_i386.deb
その他 ghostscpript 関連のアップデートもありました。
ghostscript ghostscript-x gs-common gs-esp libgs8
いつものようにアップデート・マネージャーで処理しました。
2010年8月17日火曜日
FreeBSD bison のアップデート
bison のアップデートが ports へやってきていました。
いつものように portupgrade で処理しました。
bison-2.4.1_1,1 < needs updating (port has 2.4.3,1)
いつものように portupgrade で処理しました。
bison-2.4.1_1,1 < needs updating (port has 2.4.3,1)
2010年8月10日火曜日
デスクトップ・パソコンのハードディスク交換
昨日購入したハードディスクを使って、まず最初にデスクトップ・パソコンのハードディスク交換をしました。
このパソコンは2003年7月に組み立てたもので、調子もよくずっと使っています。ハードディスクは適宜交換と増量を図ってきました。CPUのファンなどもガタガタうるさくなったついでに静音で冷却能力の高いものに交換するなどメンテナンスは比較的しっかり行ってきたつもりです。
現在はマザーボード(intel D865GBF)にあるSATAコネクタへ500GBのハードディスクを接続しています。これを新しいものに交換します。ちょうど倍の1TBにして毎日のように溜まるデジタルカメラのデータの保存や活用に使用します。
ハードディスクには使用開始した日付を書き込むようにしているので前回の交換日が判りました。2008-02-27だそうで2年6ヶ月ぶりの交換になります。（写真の左が古いもの、右が新しいもの）
なおハードディスクの不調を示す前兆現象などはまったくありませんでした。この状態で交換してこそ意味があると思っています。
ハードディスク上の OS は WindowsXP なので NTFS 5.1も扱える最新の GParted Live CD を使用することとしました。
新しいハードディスクへパーティションのコピーを行います。このハードディスクは Cドライブと Dドライブ として二つのパーティションに分割してあるので、それぞれを同じ順番でコピーをします。
Cドライブは60GBに設定してあり、コピー時間はおよそ15分程度でした。しかし残りすべての容量がある Dドライブは2時間程度の時間が必要でした。
Dドライブのパーティションのコピーが終了したところで、後ろの部分に残っている空き領域いっぱいをDドライブにするように拡張コマンドで容量を拡大しました。
この一連のコピーで新しいハードディスクへデータが移行できました。最後に Cドライブの部分へ boot フラグの設定も忘れずに行っておきました。これがないと立ち上がりませんから。
この写真はデータ移行作業をしている様子です。所定の場所に新しいハードディスクを取り付け、古いハードディスクは取り出してケーブルで接続している状況で作業をしました。
このパソコンは2003年7月に組み立てたもので、調子もよくずっと使っています。ハードディスクは適宜交換と増量を図ってきました。CPUのファンなどもガタガタうるさくなったついでに静音で冷却能力の高いものに交換するなどメンテナンスは比較的しっかり行ってきたつもりです。
現在はマザーボード(intel D865GBF)にあるSATAコネクタへ500GBのハードディスクを接続しています。これを新しいものに交換します。ちょうど倍の1TBにして毎日のように溜まるデジタルカメラのデータの保存や活用に使用します。
ハードディスクには使用開始した日付を書き込むようにしているので前回の交換日が判りました。2008-02-27だそうで2年6ヶ月ぶりの交換になります。（写真の左が古いもの、右が新しいもの）
なおハードディスクの不調を示す前兆現象などはまったくありませんでした。この状態で交換してこそ意味があると思っています。
ハードディスク上の OS は WindowsXP なので NTFS 5.1も扱える最新の GParted Live CD を使用することとしました。
新しいハードディスクへパーティションのコピーを行います。このハードディスクは Cドライブと Dドライブ として二つのパーティションに分割してあるので、それぞれを同じ順番でコピーをします。
Cドライブは60GBに設定してあり、コピー時間はおよそ15分程度でした。しかし残りすべての容量がある Dドライブは2時間程度の時間が必要でした。
Dドライブのパーティションのコピーが終了したところで、後ろの部分に残っている空き領域いっぱいをDドライブにするように拡張コマンドで容量を拡大しました。
この一連のコピーで新しいハードディスクへデータが移行できました。最後に Cドライブの部分へ boot フラグの設定も忘れずに行っておきました。これがないと立ち上がりませんから。
この写真はデータ移行作業をしている様子です。所定の場所に新しいハードディスクを取り付け、古いハードディスクは取り出してケーブルで接続している状況で作業をしました。
2010年8月9日月曜日
ハードディスクを購入
パソコンのハードディスクは消耗品のため定期的な交換が必要なものです。
我が家のパソコンのハードディスクを交換することとしました。
一般的な作業をしているデスクトップ・パソコンへ1台、そして自宅サーバーへ2台のハードディスクを購入しました。
3台とも1TBのハードディスクを選択しました。デスクトップ・パソコンには現在500GBのハードディスクを搭載しています。そしてサーバーには RAID 1 (ミラーリング) の構成で320GBのハードディスクが2台搭載しています。
これらの古いハードディスクを一気に交換して、故障の原因を取り除き、そして保存容量も一気に増やそうという魂胆です。
パソコンショップで手頃な値段で販売されていた日立の1TBを購入しましたが、以前のようにバルク品として裸で売られているものは少なく、多くはパッケージされたリテール品になっているようです。これも時代の変化なのでしょうか？
バルク品は本当にハードディスクの本体しかありませんが、パッケージされたリテール品は説明書や取り付けネジまで付属する親切ぶりです。結構ネジって落としてどっかに行ってしまうこともあり、いくら有っても邪魔にはならないものです。
明日からいよいよハードディスクの交換に取りかかります。
我が家のパソコンのハードディスクを交換することとしました。
一般的な作業をしているデスクトップ・パソコンへ1台、そして自宅サーバーへ2台のハードディスクを購入しました。
3台とも1TBのハードディスクを選択しました。デスクトップ・パソコンには現在500GBのハードディスクを搭載しています。そしてサーバーには RAID 1 (ミラーリング) の構成で320GBのハードディスクが2台搭載しています。
これらの古いハードディスクを一気に交換して、故障の原因を取り除き、そして保存容量も一気に増やそうという魂胆です。
パソコンショップで手頃な値段で販売されていた日立の1TBを購入しましたが、以前のようにバルク品として裸で売られているものは少なく、多くはパッケージされたリテール品になっているようです。これも時代の変化なのでしょうか？
バルク品は本当にハードディスクの本体しかありませんが、パッケージされたリテール品は説明書や取り付けネジまで付属する親切ぶりです。結構ネジって落としてどっかに行ってしまうこともあり、いくら有っても邪魔にはならないものです。
明日からいよいよハードディスクの交換に取りかかります。
2010年8月8日日曜日
partimage-server で、まさかのバージョン違い
debian lenny がインストールされているパソコン同士で partimage と partimage-server の間でパーティション・データの保存を繰り返していました。
そこで SystemRescueCD に入っている partimage を使って、データの保存ができるか確かめることとしました。
昔焼いて使っていた SystemRescueCD 1.2.3 を使って partimage-server へアクセスしようとしましたが、アクセス出来ません。
外部サーバーへアクセスする項目の下に「SSL&login disabled at compile time (コンパイルの時からSSLとログインは無効にしている) 」とあるので、当然かと。
そこで最新の SystemRescueCD 1.5.8 を試してみることとしました。この中に入っている partimage は外部サーバーへ接続できるようになっていました。喜び勇んでデータのバックアップを開始しようとしました。
ログイン画面でユーザー名とパスワードを入力して OK をクリックしたら、「Connexion refused by server Version mismatch」と表示されて停止してしまいました。
バージョンがミスマッチ（不一致）とはどういうこと？と思いつつ partimage のバージョンを調べてみました。
debian lenny の partimage & partimage-server は 0.6.7 でした。
SystemRescueCD 1.5.8 の partimage は 0.6.8 でした。
この僅かなバージョン違いも許されないほどプロトコルや保存されるデータの形式が違ってしまっているのでしょうか？
手っ取り早く、debian lenny の partimage を squeeze のものから借用する方法もありますが、もうムキになってバージョン合わせをしてまでサーバーで保存する気持ちもなかったので、今回はバージョンが合わないと接続してもらえないことが判っただけでも勉強になったと思って次の機会に回すこととしました。
そこで SystemRescueCD に入っている partimage を使って、データの保存ができるか確かめることとしました。
昔焼いて使っていた SystemRescueCD 1.2.3 を使って partimage-server へアクセスしようとしましたが、アクセス出来ません。
外部サーバーへアクセスする項目の下に「SSL&login disabled at compile time (コンパイルの時からSSLとログインは無効にしている) 」とあるので、当然かと。
そこで最新の SystemRescueCD 1.5.8 を試してみることとしました。この中に入っている partimage は外部サーバーへ接続できるようになっていました。喜び勇んでデータのバックアップを開始しようとしました。
ログイン画面でユーザー名とパスワードを入力して OK をクリックしたら、「Connexion refused by server Version mismatch」と表示されて停止してしまいました。
バージョンがミスマッチ（不一致）とはどういうこと？と思いつつ partimage のバージョンを調べてみました。
debian lenny の partimage & partimage-server は 0.6.7 でした。
SystemRescueCD 1.5.8 の partimage は 0.6.8 でした。
この僅かなバージョン違いも許されないほどプロトコルや保存されるデータの形式が違ってしまっているのでしょうか？
手っ取り早く、debian lenny の partimage を squeeze のものから借用する方法もありますが、もうムキになってバージョン合わせをしてまでサーバーで保存する気持ちもなかったので、今回はバージョンが合わないと接続してもらえないことが判っただけでも勉強になったと思って次の機会に回すこととしました。
debian partimage-server のインストール
partimage のネットワーク・サーバーとなる partimage-server を debian lenny で稼働しているファイルサーバーにインストールしました。
もちろん目的はパーティション・イメージ・ファイルをいちいちファイル・サーバーへ転送するよりは、直接転送してしまった方が便利だと思ったからです。
インストールは aptitude を使ってさっくり完了しました。
# aptitude install partimage-server
早速、他のパソコンから WindowsXP がインストールされているパーティションをバックアップしてみました。
動作させる上で注意点はイメージ・ファイルの名前にディレクトリの指定が出来ないことです。単純に「WindowsXP.img」のように指定します。これはサーバー側で指定されたディレクトリに一括して保管されるためです。
ただ最初はどこに保管されるのか分からず戸惑ってしまいました。ここにありました。
/var/lib/partimaged/
これではいろいろ不都合なこともあるので保存場所を変更することとしました。設定ファイルが /etc/default/partimaged にあります。
初期値（デフォルト）のディレクトリをコメントアウトして、新しいディレクトリをしていしました。TARGET= で指定します。
# TARGET=/var/lib/partimaged/
TARGET=/home/partimaged/
新しい保存先となるディレクトリは次のようにオーナーなどを設定しておきました。
# chowm partimag:partimag /home/partimaged/
# chmod 750 /home/partimaged/
# ls -l
drwxr-x--- 2 partimag partimag 4096 2010-08-08 03:13 partimaged
なお設定を変更した後は partimaged を再起動させておきます。
# /etc/init.d/partimaged restart
もちろん目的はパーティション・イメージ・ファイルをいちいちファイル・サーバーへ転送するよりは、直接転送してしまった方が便利だと思ったからです。
インストールは aptitude を使ってさっくり完了しました。
# aptitude install partimage-server
早速、他のパソコンから WindowsXP がインストールされているパーティションをバックアップしてみました。
動作させる上で注意点はイメージ・ファイルの名前にディレクトリの指定が出来ないことです。単純に「WindowsXP.img」のように指定します。これはサーバー側で指定されたディレクトリに一括して保管されるためです。
ただ最初はどこに保管されるのか分からず戸惑ってしまいました。ここにありました。
/var/lib/partimaged/
これではいろいろ不都合なこともあるので保存場所を変更することとしました。設定ファイルが /etc/default/partimaged にあります。
初期値（デフォルト）のディレクトリをコメントアウトして、新しいディレクトリをしていしました。TARGET= で指定します。
# TARGET=/var/lib/partimaged/
TARGET=/home/partimaged/
新しい保存先となるディレクトリは次のようにオーナーなどを設定しておきました。
# chowm partimag:partimag /home/partimaged/
# chmod 750 /home/partimaged/
# ls -l
drwxr-x--- 2 partimag partimag 4096 2010-08-08 03:13 partimaged
なお設定を変更した後は partimaged を再起動させておきます。
# /etc/init.d/partimaged restart
2010年8月6日金曜日
debian wget のアップデート
debian lenny に wget のアップデートが到着していました。
アップデートマネージャーでアップデートさせておきました。
wget 1.11.4-2+lenny1 ＞ wget_1.11.4-2+lenny2
アップデートマネージャーでアップデートさせておきました。
wget 1.11.4-2+lenny1 ＞ wget_1.11.4-2+lenny2
2010年8月4日水曜日
FreeBSD 再びghostscript のアップデート
先日アップデートがあったばかりの ghostscript ですが、再びアップデートが来ていました。
portupgrade でアップデート処理を開始すると、jbig2dec をインストールし始めました。
PNG画像の処理を含めるかどうかのビルドオプションの問い合わせがありました。デフォルト値はPNGを含めるとなっていたのでそのままビルドさせることとしました。
JBIG2 ってなんだろうと検索してみると、「joint bi-level image experts group 2」ということで画像圧縮形式の一つのようです。
ghostscript8-nox11-8.71_3 < needs updating (port has 8.71_4)
portupgrade でアップデート処理を開始すると、jbig2dec をインストールし始めました。
PNG画像の処理を含めるかどうかのビルドオプションの問い合わせがありました。デフォルト値はPNGを含めるとなっていたのでそのままビルドさせることとしました。
JBIG2 ってなんだろうと検索してみると、「joint bi-level image experts group 2」ということで画像圧縮形式の一つのようです。
ghostscript8-nox11-8.71_3 < needs updating (port has 8.71_4)
debian avahi 関連のアップデート
debian lenny へ avahi 関連のアップデートがやってきていました。
いつものアップデートマネージャーで対応しました。
libavahi-common-data 0.6.23-3lenny1 を (.../libavahi-common-data_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-common-data を展開し、置換しています...
libavahi-common3 0.6.23-3lenny1 を (.../libavahi-common3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-common3 を展開し、置換しています...
libavahi-core5 0.6.23-3lenny1 を (.../libavahi-core5_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-core5 を展開し、置換しています...
avahi-daemon 0.6.23-3lenny1 を (.../avahi-daemon_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon.
avahi-daemon を展開し、置換しています...
libavahi-client3 0.6.23-3lenny1 を (.../libavahi-client3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-client3 を展開し、置換しています...
libavahi-compat-libdnssd1 0.6.23-3lenny1 を (.../libavahi-compat-libdnssd1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-compat-libdnssd1 を展開し、置換しています...
libavahi-glib1 0.6.23-3lenny1 を (.../libavahi-glib1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-glib1 を展開し、置換しています...
libavahi-gobject0 0.6.23-3lenny1 を (.../libavahi-gobject0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-gobject0 を展開し、置換しています...
libavahi-ui0 0.6.23-3lenny1 を (.../libavahi-ui0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-ui0 を展開し、置換しています...
libtiff4 3.8.2-11.2 を (.../libtiff4_3.8.2-11.3_i386.deb で) 置換するための準備をしています ...
libtiff4 を展開し、置換しています...
いつものアップデートマネージャーで対応しました。
libavahi-common-data 0.6.23-3lenny1 を (.../libavahi-common-data_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-common-data を展開し、置換しています...
libavahi-common3 0.6.23-3lenny1 を (.../libavahi-common3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-common3 を展開し、置換しています...
libavahi-core5 0.6.23-3lenny1 を (.../libavahi-core5_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-core5 を展開し、置換しています...
avahi-daemon 0.6.23-3lenny1 を (.../avahi-daemon_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon.
avahi-daemon を展開し、置換しています...
libavahi-client3 0.6.23-3lenny1 を (.../libavahi-client3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-client3 を展開し、置換しています...
libavahi-compat-libdnssd1 0.6.23-3lenny1 を (.../libavahi-compat-libdnssd1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-compat-libdnssd1 を展開し、置換しています...
libavahi-glib1 0.6.23-3lenny1 を (.../libavahi-glib1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-glib1 を展開し、置換しています...
libavahi-gobject0 0.6.23-3lenny1 を (.../libavahi-gobject0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-gobject0 を展開し、置換しています...
libavahi-ui0 0.6.23-3lenny1 を (.../libavahi-ui0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...
libavahi-ui0 を展開し、置換しています...
libtiff4 3.8.2-11.2 を (.../libtiff4_3.8.2-11.3_i386.deb で) 置換するための準備をしています ...
libtiff4 を展開し、置換しています...
2010年8月3日火曜日
FreeBSD ghostscript のアップデート
先日アップデートしたばかりの ghostscript が再びアップデートです。
いつものように portupgrade で対応しました。
ghostscript8-nox11-8.71_2 < needs updating (port has 8.71_3)
いつものように portupgrade で対応しました。
ghostscript8-nox11-8.71_2 < needs updating (port has 8.71_3)
2010年8月1日日曜日
debian ghostscript 関連のアップデート
debian lenny に ghostscript 関連のアップデートがありました。
いつものようにアップデートマネージャーでアップデートさせておきました。
ghostscript 8.62.dfsg.1-3.2lenny1 を (.../ghostscript_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
libgs8 8.62.dfsg.1-3.2lenny1 を (.../libgs8_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
gs-common 8.62.dfsg.1-3.2lenny1 を (.../gs-common_8.62.dfsg.1-3.2lenny4_all.deb で) 置換
ghostscript-x 8.62.dfsg.1-3.2lenny1 を (.../ghostscript-x_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
gs-esp 8.62.dfsg.1-3.2lenny1 を (.../gs-esp_8.62.dfsg.1-3.2lenny4_all.deb で) 置換
いつものようにアップデートマネージャーでアップデートさせておきました。
ghostscript 8.62.dfsg.1-3.2lenny1 を (.../ghostscript_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
libgs8 8.62.dfsg.1-3.2lenny1 を (.../libgs8_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
gs-common 8.62.dfsg.1-3.2lenny1 を (.../gs-common_8.62.dfsg.1-3.2lenny4_all.deb で) 置換
ghostscript-x 8.62.dfsg.1-3.2lenny1 を (.../ghostscript-x_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換
gs-esp 8.62.dfsg.1-3.2lenny1 を (.../gs-esp_8.62.dfsg.1-3.2lenny4_all.deb で) 置換