/etcをギットギトにしてやった をみて Ubuntu Weekly Recipe:第58回 ファイルのバージョンを管理する|gihyo.jp … 技術評論社 で知った etckeeper を最近使ってみていることを思い出した。
[etckeeper - %!zt! diary (2009-04-08)より引用]
思いっきり車輪を作ってしまうところだった...
ということでetckeeperでやろうとしていたことはできた.これを使っていこう.
標題の話だけではつまらないのでgit commitしていないファイルが存在するときは aptitude installできないように細工した.
こうすることで,うっかりgit commitし忘れても パッケージのインストール/アンインストールまでには対応することだろう. だれがって自分がだけどさ.
月並な方法だが以下のようにして/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を削除するだけだしね.
以下の2つのファイルを用意した.
/usr/local/sbin/check-git-status 以下のようにして導入
# install -m 755 -o root -g root \
check-git-status /usr/local/sbin/check-git-status/etc/apt/apt.conf.d/09check-git-status 以下のようにして導入
# install -m 644 -o root -g root \
09check-git-status /etc/apt/apt.conf.d/09check-git-statusこれは,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) を設定しています ... パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 拡張状態情報を読み込んでいます パッケージの状態を初期化しています... 完了 拡張状態情報を書き込んでいます... 完了
% 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
パッケージをインストールできませんでした。復旧を試みています:
...
fdiskやcfdiskなどでパーティションテーブルを変更した場合,BLKRRPARTのioctlを使ってパーティションテーブルを再読み込みする.
しかし,以下のケースでは再読み込みに失敗する.
そんなときは上記の状況を解消した後でもう一度BLKRRPARTを行って再読み込みすればよい. これにはhdparmを使ってできる.
% sudo hdparm -z /dev/sdb /dev/sdb: re-reading partition table
日付的に空気読んでない感じですが,主にバグフィックスのためのリリースをしました.
見出しをまたがる番号付き箇条書きで番号付けが狂う点の修正.
例: (1) EnumList 1 == Headline 2 (1) EnumList 1
番号なし箇条書きが間に入る番号付き箇条書きで番号付けが狂う点の修正
例:
(1) EnumList 1
(1) EnumList 1-1
* ItemList *1
(1) EnumList *1-1自分管理でない既存のソフトウェアについて,不具合修正あるいは新機能追加を提案する際に,gitを使って効率よく作業する一連の作業手順を考えてみた.
本エントリで最も重要なことはブランチの運用方針を明確にすることである.
この作業手順では以下のような方針でブランチを運用する.
master
行った修正や改良を普段使用するために用意する.
upstreamとこのリポジトリで行った全ての作業を適用したもの. すなわち,後述するupstreamとchanges/*,localを全てマージしたもの.
upstream
upstreamの変更点を各ブランチにマージするために使用する.
upstreamの最新ソースコードを入れるブランチ.
changes/*
このリポジトリで機能追加あるいは不具合修正を行うブランチ.
変更ごとにブランチを別にする.
local
リポジトリ固有のupstreamには有益でないと思われる変更を行うブランチ.
例えば以下のようなものをこのブランチで作業する.
最新のソースコードをインポートする.
% 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ブランチに移る.
% 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>はコンフリクトが発生したブランチにすると都合がいい.
% git checkout master % git merge <from-branch>
このリポジトリで行った変更がupstreamにマージされている場合は, 作業を行ったブランチを削除する.
% git branch -D changes/some-change
公開用リポジトリにも反映させる.
% git push --all github
4/10追記
いつ頃からかわからないが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つ.
実験してみると以下のようになった.
詳しく原因は追えていないが,とりあえず解決できたのでいいか.
rd2odtのドキュメント整備ということで,主にREADMEをまともにする作業を行った. これまで日記のエントリ以外にまともにインストール方法を記述していなかったので,これであっちの人達にも使えるんじゃないだろうか.
ただ,かっこいいサンプルスタイルを作らないと見栄えはしないな. 機能追加以外にもそういった方面も進めないといかんなあ.
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>