RSS

日々のメモ書き

Debian Developerが綴るメモ

Plone 3.2.1-r4移行テスト

Plone 3.2.1-r4への移行テストをやってみた。

Plone-2.5.xからの移行。

  • 単にData.fsをコピーしただけだと挙動不審
  • Products/* を全部持ってきたら当然エラーだらけ
  • エラーの出るのを地道に削っていって、skinのエラーを直してゴミとなったtoolを消してとやっていたらどうやら動くように。
  • Productの中身をコピーしてこないとエラーになる。何が問題かは把握できず。
  • 残る問題はQuillsだけ?

スプロケ発注

チェーンが飛ぶ飛ぶ。駄目だこりゃ。

真ん中3つがほぼ使えない。どういうギアを入れればいいんだか。ホットスピンでCS-6500 11-21を発注。ついでにフロントのリムも交換。Mavicの安いやつに。シルバーの在庫がないからブラックに…。前後で色が違うってのもなあ…。まあいいか。

git pushでちょっと驚いたこと

git pushはgit pullの反対ではない。

cloneしたリポジトリを変更して commit; pushとしてoriginを編集しようとしたら…???変更が反映されていない。あれ、commit失敗しているのかねと git log を見たら入っている。なんだこりゃと思ったが…。git pushしたときに次のようなメッセージが出ていたが…。

warning: updating the currently checked out branch; this may cause confusion,
as the index and working tree do not reflect changes that are now in HEAD.

git pushは gitの管理のところにcommit されるだけでワーキングツリーには反映されない。pushしたけりゃ専用リポジトリを用意しておけということみたい。確かに編集中にpushされてどんどんソースが変更されたら困ると思ってそういう設計にしてあるんだろうね。ちなみにpushされた側で git reset をかけたらきちんと merge(?)されたがそれでいいんだろうか。git diffでは何も出力されずに git diff HEADで出力されるというのも、合っているけどなんかね。

でも、自分のやっているように手元のPCとサーバ上の二箇所で作業するんだけの話だとdarcs使ったほうがいいかもしれない。FAQにはいろいろ工夫すればいいよということを書いてあるが…。

readIOで例外処理

パースに失敗してプログラムが落ちるでは意味がないので。

最初はreadを使っていたがreadIOに変更してごにょごにょと次のように。

import IO hiding (catch)
import Control.Exception
import Prelude hiding (catch)
-- ......
readPos :: IO (Int, Int)
readPos  = do
  line <- getLine
  catch (readIO line :: IO (Int,Int))
            (\e -> return (e::SomeException) >>
                   putStr "Input again!: " >>
                   hFlush stdout>>
                   readPos)

てな具合で。だんだんなんでもかんても再帰で処理する脳になってきた。よしよし。


あたらしいpamの設定ファイルとpam_ldap

libpam-runtimeに入っているpam.d/common-*が変わったのでちょっと設定変更

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

となった。3行目の部分がデフォルトで追加されているのでこうなる。今までよりsuccessで飛ばす行数が増えた。

pam.conf(5)を読んでいて気付いたがrequiredとかのキーワードは[...]で定義される条件に名前をつけたものになっているわけですね。

MTB整備

ワイヤーとかいろいろ。

ディレイラーとかクランクとかブレーキとか一通りはずして軽くクリーニング。徹底的にやる気力はないな。

ワイヤーとアウターケーシングを交換。ブレーキシューも。

乗り心地が全然違うぜ。ワイヤーがじんわり伸びるからブレーキの感覚がおかしいよ。リアは滅茶苦茶だ。調整にしばらくかかるか。チェーンが伸びすぎていたよ。1%も伸びていたら駄目にきまっている。

ヘッドの若干のガタはよくわからん。ホットスピンに持っていったが大丈夫だと。店長はフレームのことを覚えていた。

久しぶりのsf.net

久しぶりにsf.netを使ってみて気付いたこと

  • sshのアクセスが随分変わっていた。専用仮想マシンをon demandで作成するみたい
  • rubyがCGIで動くようになっていた。
  • デフォルトのプロジェクトウェブサイトがかっこよくなっていた。
  • サイトドキュメントにtrac使いまくり(いいのか?)
  • 全般にごちゃごちゃしてわかりにくくなった。

sf.netでgit

sf.netにprcs2gitのプロジェクトを申請。gitを使おうとした。

sf.netにprcs2gitのプロジェクトの申請をした。夜に申請して、朝起きたらできていた。

さっそくgitを使おうとしたんだが…。gitのsshアクセスが蹴られる。というか生でsshで叩いてもconnection refusedになる。意味わかんね。

と、ごちゃごちゃしていたらつながるように。サーバーが落ちてたんかいな。

prcs2git

大体できた。

最初は一つのディレクトリでできるかと思ったがブランチの取り扱いが難しかった。prcs のmergeを無視して変なブランチを作っているだけだった。prcsのrevision毎に一つのディレクトリを作って init - pull をしていたが、さすがにフォルダ作りすぎなので prcsのbranch毎に一つのディレクトリという扱い。prcs の branchのマージを追い掛けると gitのほうでconflictしたりするのが苦労する。なんともならんところもある。

自動でやっているのでファイルの移動が追跡できてないので、削除と追加扱いになっているのかな。二回同じ操作をしようとして…駄目になるとか。結局gitのエラーメッセージをヒューリスティックに解釈してgit rmとかやるしかないようで。mergeの履歴さえ終えれば何をしようと勝手なんでいいのだけど。

ちょっと勘違いしていたが、mergeは実際にきれいにmergeされていなくてもいい。merge履歴が追い掛けられればそれでいいのであとは無理矢理で問題はない。


PRCSってどうなった?

むかしむかしPRCSというバージョン管理システムがあってそれをつかっていたわけなんだが。

ちょっと昔のコードをひっぱりだしたいなーと思ったらPRCSのdebがなかったという話。時代の変化を感じるなあ。開発元が放り出して何年だ?Ubuntuにあったりするのが以外だ。prcs2svnというツールはあるがmerge treeの再生まではできないようである。PRCS自体がどうにかなるのは期待できないのが、昔のリポジトリが引っ張り出せなくなるという悲劇は避けたいのでsvnにでも最低変換しておかないと完全に取り出せなくなったら面倒。僕はsvnは使わんから本当に必要なときにはsvnから何かに変換するのだろうけど。ただ3年はなーにも更新してないソフトウェアを何かするのかって話はあるんだがね…。

< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 >