雄也の?日坊主日記

2004|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|
2006|05|
2007|04|05|09|10|11|
2008|04|05|08|10|11|
2009|02|03|04|05|

2009-05-15

_ [rd2odt] OSC 2009 Shimaneでしゃべります

3日ほど前にMatsue.rbの発起人から振りがあったのでしゃべります.

絶賛資料作成中です :>


2009-04-10

_ [Debian][git] ギットギトにするdebパッケージ

/etcをギットギトにしてやった をみて Ubuntu Weekly Recipe:第58回 ファイルのバージョンを管理する|gihyo.jp … 技術評論社 で知った etckeeper を最近使ってみていることを思い出した。

[etckeeper - %!zt! diary (2009-04-08)より引用]

思いっきり車輪を作ってしまうところだった...

ということでetckeeperでやろうとしていたことはできた.これを使っていこう.


2009-04-08

_ [Debian][git] /etcをギットギトにするdebパッケージ

「/etcをギットギトにしてやった」をdebパッケージにしたもの.

あとで書く.


2009-04-07

_ [Debian][git] /etcをギットギトにしてやった

標題の話だけではつまらないのでgit commitしていないファイルが存在するときは aptitude installできないように細工した.

こうすることで,うっかりgit commitし忘れても パッケージのインストール/アンインストールまでには対応することだろう. だれがって自分がだけどさ.

/etcをgit化

月並な方法だが以下のようにして/etcをgit化した.

% cd /etc
% sudo sh -c 'cat > .gitignore' <<EOF
*~
*.dpkg-dist
*.dpkg-old
mtab
ld.so.cache
resolv.conf
adjtime
EOF
% sudo git init
% sudo git add .
% sudo git commit -m 'gitized.'

.gitignoreは必要になったら追加しよう. 生成されたメニューのファイルについては入れるか入れないか迷ったけど, 迷ったので.gitignoreには入れずにgit管理することにした.

ディスク容量を多少喰う程度だけん,こういう場合は安全側に倒す. やめたくなったら.gitを削除するだけだしね.

git commitの強制

以下の2つのファイルを用意した.

これは,apt-get install/aptitude installなどでdpkgの実行前に/etcをチェックして コミット漏れのファイルがあれば,dpkgを実行させずにapt-get/aptitudeを終了させる\\ ものである.

check-git-statusの実行をapt-listbugsの実行前にしたかったので, 09check-git-statusという名前にした. apt-listbugsの実行前にしたかったかのは, apt-listbugsの確認を行った後でコミット漏れがあったときに失敗し, 次の実行のときにはapt-listbugsの出力内容を忘れてしまい, 再び確認するはめになることを防止するためである.

試す

導入するとAPTやaptitudeを動作させるときに以下のようになる.

パッケージインストール時

/etcのファイルが全てコミット状態なら通常通りAptitudeやAPTによってインストールできる. また,インストール後に未コミット状態のファイルを出すようにしてある.

% sudo aptitude install nginx
パッケージリストを読み込んでいます... 完了
...
nginx (0.6.34-2) を設定しています ...
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       init.d/nginx
#       logrotate.d/nginx
#       nginx/
#       rc0.d/K20nginx
#       rc1.d/K20nginx
#       rc2.d/S20nginx
#       rc3.d/S20nginx
#       rc4.d/S20nginx
#       rc5.d/S20nginx
#       rc6.d/K20nginx
nothing added to commit but untracked files present (use "git add" to track)
パッケージリストを読み込んでいます... 完了
...
うっかり未コミットの状態でインストールを行おうとしたとき

以下のようにインストール前に失敗し,未コミットなファイルを表示する.

% sudo aptitude install sl
パッケージリストを読み込んでいます... 完了
...
拡張状態情報を書き込んでいます... 完了
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       init.d/nginx
#       logrotate.d/nginx
#       nginx/
#       rc0.d/K20nginx
#       rc1.d/K20nginx
#       rc2.d/S20nginx
#       rc3.d/S20nginx
#       rc4.d/S20nginx
#       rc5.d/S20nginx
#       rc6.d/K20nginx
nothing added to commit but untracked files present (use "git add" to track)
E: Problem executing scripts DPkg::Pre-Invoke '/usr/local/sbin/check-git-status'
E: Sub-process returned an error code
パッケージをインストールできませんでした。復旧を試みています:
...
コミットしてからもう一度

普通にgitを使う感じで/etcのファイルをコミットする.

% cd /etc
% sudo git add .
% sudo git commit -m 'aptitude install nginx'

コミットが終わったら,通常通りインストールが行える. slパッケージのように/etcにファイルを作成しないパッケージのみの場合はgit statusを実行しない.

% sudo aptitude install sl
パッケージリストを読み込んでいます... 完了
...
sl (3.03-16) を設定しています ...
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
拡張状態情報を読み込んでいます
パッケージの状態を初期化しています... 完了
拡張状態情報を書き込んでいます... 完了
/etcのファイルが編集されていたらremoveもできない.
% sudo touch /etc/some-change
% sudo aptitude purge sl
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
拡張状態情報を読み込んでいます
パッケージの状態を初期化しています... 完了
以下のパッケージが削除されます:
  sl{p}
更新: 0 個、新規インストール: 0 個、削除: 1 個、保留: 0 個。
0B のアーカイブを取得する必要があります。展開後に 123kB のディスク領域が解放されます。
先に進みますか? [Y/n/?]
拡張状態情報を書き込んでいます... 完了
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       some-change
nothing added to commit but untracked files present (use "git add" to track)
E: Problem executing scripts DPkg::Pre-Invoke '/usr/local/sbin/check-git-status'
E: Sub-process returned an error code
パッケージをインストールできませんでした。復旧を試みています:
...

2009-04-03

_ [Linux] パーティションテーブルを強制的に読み直す方法

fdiskやcfdiskなどでパーティションテーブルを変更した場合,BLKRRPARTのioctlを使ってパーティションテーブルを再読み込みする.

しかし,以下のケースでは再読み込みに失敗する.

  1. mountしたパーティションのあるディスクをマウントした状態でパーティションを切り直したとき. (BLKRRPARTでEBUSYになる)
  2. USBメモリなどのパーティションをいじる際にfloppyグループの一般ユーザで行ったとき. (権限不足でEACCESになる)

そんなときは上記の状況を解消した後でもう一度BLKRRPARTを行って再読み込みすればよい. これにはhdparmを使ってできる.

% sudo hdparm -z /dev/sdb

/dev/sdb:
 re-reading partition table

2009-04-01

_ [rd2odt] rd2odt-0.0.1公開

日付的に空気読んでない感じですが,主にバグフィックスのためのリリースをしました.

不具合修正

  1. 見出しをまたがる番号付き箇条書きで番号付けが狂う点の修正.

    例:
    (1) EnumList 1
    
    == Headline 2
    
    (1) EnumList 1
  2. 番号なし箇条書きが間に入る番号付き箇条書きで番号付けが狂う点の修正

    例:
    (1) EnumList 1
        (1) EnumList 1-1
    * ItemList *1
      (1) EnumList *1-1

機能拡張

  1. (RDtoolにならって)'=begin'と'=end'がないときでも動作するように変更しました.

2009-03-28

_ [git] 自分管理でないソフトウェアを変更する際のワークフロー

自分管理でない既存のソフトウェアについて,不具合修正あるいは新機能追加を提案する際に,gitを使って効率よく作業する一連の作業手順を考えてみた.

ブランチの運用方針

本エントリで最も重要なことはブランチの運用方針を明確にすることである.

この作業手順では以下のような方針でブランチを運用する.

  • master

    行った修正や改良を普段使用するために用意する.

    upstreamとこのリポジトリで行った全ての作業を適用したもの. すなわち,後述するupstreamとchanges/*,localを全てマージしたもの.

  • upstream

    upstreamの変更点を各ブランチにマージするために使用する.

    upstreamの最新ソースコードを入れるブランチ.

    • SCMがある場合はオリジナルのSCMからpullするコード.
    • SCMがない場合はtarballなどから展開したコード.
  • changes/*

    このリポジトリで機能追加あるいは不具合修正を行うブランチ.

    変更ごとにブランチを別にする.

  • local

    リポジトリ固有のupstreamには有益でないと思われる変更を行うブランチ.

    例えば以下のようなものをこのブランチで作業する.

    • リポジトリ固有の運用方針を書いたドキュメント
    • changes/*の各ブランチでの変更内容を書いたドキュメント
    • 俺Toolsによる自動生成ファイルのファイル名を書いた.gitignore

作業可能になるまでの初期設定

最新のソースコードをインポートする.

% tar xfz ZenTest-3.11.1.tgz
% mv ZenTest-3.11.1 ZenTest
% cd ZenTest
% git init
% git add .
% git commit -m 'imported release 3.11.1.'

upstreamブランチを作ってそのブランチに移動する.

% git checkout -b upstream

リリースされたファイルをインポートした場合は必要に応じてタグを打つ.

% git tag upstream-release-3.11.1

localブランチを作る.

% git branch local

機能追加あるいは不具合修正するとき

upstreamブランチからブランチを作って移る.

% git checkout upstream
% git checkout -b changes/some-change

いろいろ作業してgit commitする.

作業が終わったら,masterに反映させる.

% git checkout master
% git merge changes/some-change

公開用リポジトリに反映させる. git push時に--allオプションを付けることで作った全てのブランチを反映できる.

% git remote add github git@github.com:nishidayuya/zentest.git
% git push --all github

反映したくないブランチがある場合は以下のように直接指定する.

% git push github changes/some-change
% git push github master
余談

「いろいろ作業してgit commitする」の間は必要に応じてさらにブランチを作って作業してもいい.

% git checkout -b changes/some-change-01
<いろいろ作業,いろいろgit commit>
% git checkout changes/some-change-01
% git merge --squash changes/some-change-01
% git commit -m 'some log.'
% git branch -D changes/some-change-01

リポジトリ固有の変更をするとき

localブランチに移る.

% git checkout local

いろいろ作業してgit commitする.

作業が終わったら,masterに反映させる.

% git checkout master
% git merge local

公開用リポジトリにも反映させる.

% git push --all github

upstreamの更新を受け入れるとき

upstreamブランチに移る.

% git checkout upstream

tarballの場合は一度全て消してから展開し,必要に応じてgit add,git commitする. 全て消してからでないとupstreamで削除されたファイルが反映できないためである.

% rm -rf *
% tar xfz ZenTest-4.0.0.tgz
% mv ZenTest-4.0.0/* .
% mv ZenTest-4.0.0/.autotest .
% rmdir ZenTest-4.0.0
% git add .
% git commit -m 'imported release 4.0.0.' -a
% git tag upstream-release-4.0.0

upstreamの変更をmaster以外の各ブランチに反映させる.

% for b in `git branch \
            | sed -e 's/\*/ /g' -e 's/^ *//g' \
                  -e '/^master$/ d' -e '/^upstream$/ d'`
  do
    git checkout $b
    git merge upstream || break
  done

上記をコンフリクトがなくなるまで繰返し行う.

masterにupstreamの変更をマージする.

  • 先の作業でコンフリクトが発生しなければ以下の<from-branch>はupstreamでいい.
  • コンフリクトが発生したブランチがあれば, <from-branch>はコンフリクトが発生したブランチにすると都合がいい.

    % git checkout master
    % git merge <from-branch>

このリポジトリで行った変更がupstreamにマージされている場合は, 作業を行ったブランチを削除する.

% git branch -D changes/some-change

公開用リポジトリにも反映させる.

% git push --all github

書いてみて気づいたこと

  1. 実行するコマンドはあくまで例示であり他の方法も考えられるだろう.
  2. SCMも必ずしもgitである必要はない. MercurialやDARCS,やりやすさはあるだろうがSubversionやCVSでも 同様のことはできるのではないだろうか.

4/10追記

  • 作業可能になるまでの初期設定段階ではなにも変更を加えてないので公開リポジトリに反映する必要はないんじゃないかと考えて変更した.

2009-03-24

_ [software] Iceweasel(Firefox)でFlash表示の注意事項

いつ頃からかわからないがIceweasel(Mozilla Firefox)でAdobe Flash付きのウェブページを表示したときに以下のエラーメッセージを出して異常終了するようになっていた.

The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadImplementation (server does not implement operation)'.
  (Details: serial 33 error_code 17 request_code 146 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

最近はWeb日記やブログでもブログパーツでFlashが普通に使われるようになってきた. そのため,Flashを見るだけでブラウザが異常終了してしまうのはかなり痛い.

原因の切り分けを行うために2分探索でAdd-onを外すなどして調べたところ, Flashのプラグインが2つ入っていたためだということがわかった. debパッケージ名だと以下の2つ.

  1. libflash-mozplugin
  2. flashplugin-nonfree

実験してみると以下のようになった.

  • ×両方あり
  • ○libflash-mozpluginのプラグインのみEnable
  • ○flashplugin-nonfreeのプラグインのみEnable
  • ○両方なし(ただしFlashは見えない)

詳しく原因は追えていないが,とりあえず解決できたのでいいか.


2009-03-14

_ Matsue.RB #2に参加

rd2odtのドキュメント整備ということで,主にREADMEをまともにする作業を行った. これまで日記のエントリ以外にまともにインストール方法を記述していなかったので,これであっちの人達にも使えるんじゃないだろうか.

ただ,かっこいいサンプルスタイルを作らないと見栄えはしないな. 機能追加以外にもそういった方面も進めないといかんなあ.

_ [snowboard] 板の封印

今日は軽く雪が降る少し寒い日であったが,先週に最後と決めたので板を来年度まで封印することにした.

今年の汚れがあるのでクリーニング用ワックスで2度ほどスクレーピングし,最後に厚めにワックスを塗った状態にする. 錆を防止するためにエッジもワックスがかかっている状態で残しておく.

後輩の話によると昨年は3月後半に桝水へナイターに滑りに行っていたらしい. そのときはだいぶ雪があったのに今年は明日で奥大山すら終了のようだ.

また12月まで雪を待とうか. あと9ヶ月かー,長いなあ.


2009-03-05

_ [管理][Debian] kusanagi.j96.orgをLennyへアップグレード

特に問題なくアップグレードできた.

気をつけたのはkusanagi.j96.orgではApache2でsuexecを使っているので,apache2-suexecパッケージをインストールする必要があったぐらいだろうか.

リリースノートに書かれてあったおかげだ.

mod_suexec に必要な suexec ヘルパプログラムは、別のパッケージ apache2-suexec として提供されます。これはデフォルトではインストールされません。

[第5章 lenny で知っておくべき問題点: - 5.4. apache2 のアップグレードより引用]


Debian | LOOX T70HN | Linux | Rails | Rast | Ruby | TYPE T VGN-TZ90HS | boat | git | hardware | music | p | rd2odt | snowboard | software | surfing | tDiary | その他 | ボウリング | 映画 | 家族 | 会社 | 管理 | 丸藤 | 高専 | 散歩 | 仕事 | 自分 |

"Yuya.Nishida." / 西田 雄也 <yuya at j96 dot org>