PostgreSQLの14がstableになったようで、@worldをupdateしたら自動的に14が降ってきた。

勝手に13を置き換えてくれるのかと思ったらそうではなく、二つのバージョンが同時にインストールされた状態になるので、マイグレーションは自分でやる必要がある。

Portageのメッセージに導かれてWikiを辿ると、マイグレーションの手順を用意してくれている。 基本的にこの内容に従えば、特に苦もなくマイグレーションできる。

補足としていくつか。

• うちの場合 local が trust でないので、pg_upgrade の前に pg_hba.conf の調整が必要
• サービスの自動起動設定は忘れずにケアする
• 旧バージョンは依存関係が切れているのでdepcleanすれば消えるが、データと設定は残してくれるので好きなように

なにはともあれ、Portageからのメッセージを見逃さないことが大事。

時流に乗って（乗れてないけど）、手元のGitリポジトリの master ブランチを改名することにした。 ただざっと調べたところでは（GitHubとかでなく）独自のリモートリポジトリを使っているケースの情報が見当たらなかったので、せっかくなのでまとめておく。

ちなみに、このテキストを改名後の main ブランチにpushすることでpublishされるので、何かミスってたらこのテキストは世に出ないことになる。

リモートのブランチ名を変える

ローカルの master ブランチを main に改名する。

$ git checkout master
$ git branch -m master main

改名した main をリモートにpushし、同時にupstreamを設定する。

$ git push --set-upstream origin main

次にリモートの master を削除する。 が、リモートの HEAD が master を向いたままだと削除できないので main に向け直す。 GitHubで言うところの「デフォルトブランチの変更」に相当する。 ここだけはリモートリポジトリを直接触る必要がある。

remote$ git symbolic-ref HEAD refs/heads/main

リモートの master を削除する。

$ git push origin --delete master

remotes/origin/HEAD が消えてしまうので再設定する。

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

他のcloneで追いかける

ローカルの master ブランチを main に改名する。

$ git checkout master
$ git branch -m master main

fetchしてupstreamを再設定する。

$ git fetch
$ git branch --unset-upstream
$ git branch --set-upstream-to=origin/main

remotes/origin/HEAD が origin/master を向いたままなので、再設定する。

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

残っているリモートトラッキングブランチ origin/master を削除する。

$ git branch --remotes --delete origin/master

おまけ

次にリポジトリを新規作成する場合に備えて、デフォルトブランチの名前を変えておく。

$ git config --global init.defaultBranch main

参考

• How to rename the "master" branch to "main" in Git | Learn Version Control with Git
• Easily rename your Git default branch from master to main - Scott Hanselman's Blog

CPUが貧弱でGentooの日々のメンテがしんどいので、試しにCcacheを使いはじめた。

実利的な面は、それなりに長期間運用してみないとわからない。

Portage

Gentoo WikiのCcacheのページにかなり網羅的な情報が載っていて、ここを参考にすればPortageの設定までカバーできてしまう。

ただしUsing ccache globally is not recommendedらしいので、そこは各自の判断で。

genkernel

Gentoo Wikiのgenkernelのページにさらっと書いてある程度で、情報が少ない。

最終的に /etc/genkernel.conf の設定は、要点だけ抜粋すると以下のようにした。

CCACHE_DIR="/path/to/ccache/cache"; export CCACHE_DIR

KERNEL_CC="/usr/lib/ccache/bin/gcc"
UTILS_CC="/usr/lib/ccache/bin/gcc"
UTILS_CXX="/usr/lib/ccache/bin/g++"

当初は KERNEL_CC="ccache -d /path/to/ccache/cache gcc" といった設定を試してみたものの、Ccacheが Invalid option というエラーを吐いた。 おそらくビルドプロセスのどこかでコマンドライン文字列の扱いに難があるせいだが、深くは追っていない。 とにかく、キャッシュディレクトリのパスを環境変数で渡すしかないので無理矢理exportしている（Bashスクリプトなのでexportできてしまう）。

さらに、これだけではinitramfsのコンパイルの段階で ACCESS VIOLATION という見慣れないエラーが発生する。 これはinitramfsのコンパイルがSandbox環境で行なわれ、許可されていないディレクトリへの書き込みがブロックされるためで、以下のいずれかの設定を入れる必要がある。

• そもそもSandboxを使わないようにする
  • /etc/genkernel.conf で SANDBOX="no" を設定
• Sandbox内でもキャッシュディレクトリへの書き込みを許可する
  • /etc/sandbox.conf に SANDBOX_WRITE="/path/to/ccache/cache" を追加

個人的には後者のほうが筋は良いと思う。 ただ、ドキュメントを読む限り /etc/sandbox.d/ に設定ファイルを作成しても効きそうなものだが、/etc/sandbox.conf に追記しないと想定した挙動にならなかった。 これも裏は取っていない。

genkernel.conf の中で CCACHE_DIR をexportする、というのがとても気持ち悪いので考え直した。 その結果、/etc/ccache.conf に cache_dir を設定するとグローバルで効くので、genkernel.conf から CCACHE_DIR を排除することができた。

ただし make.conf については CCACHE_DIR のデフォルト値が /var/tmp/ccache で固定されているので、他のディレクトリを使う際は設定が依然として必須。 なかなかうまいこと収まらない。

/etc/sandbox.d/ に設定ファイルを作成しても効きそう

Sandboxは実行時に環境変数を設定することでアクセスルールを追加することができる。 ただしソースコードの setup_access_var() を見るとわかるのだけど、その場合は sandbox.d/ の設定を読まなくなる仕様らしい。 一方で sandbox.conf は常に読まれる。

genkernelは環境変数でアクセスルールを調整するので、結局は前述のとおり sandbox.conf に書くほかない。