「65日間日本一周最長片道切符」（bit、1975年1月号）を読んで

かつて共立出版が発行していた「bit」に「65日間日本一周最長片道切符」（平野照比古、1975年1月号）という記事が掲載されていることを知り、読んでみました。国鉄が日本全国に鉄道網を持っていた時代には、このような最長距離の片道切符を考えるのが話題になっていました。最も有名なのが『最長片道切符の旅』でしょう。

 記事には、最長距離片道ルートを求めるアルゴリズムが開設されていますが、概念レベルが書かれているだけなので、具体的なロジックはわかりません。文末にデータ作成作業をしてくれた人達への謝辞が書かれています。当時は今日のような路線検索サイトがある訳ではありませんから、おそらく時刻表を利用して、必要な情報を拾ってグラフ構造を作ったのでしょう。楽な作業ではないと思いますが、本文中でも「まず、駅の集合をVとする。実際には分岐点や行きどまりの駅だけを考えれば充分であることは明らかであろう。」と書かれているように、旧国鉄の全駅のデータが必要になるわけではなく、グラフ構造を作り上げるために必要な分岐駅や末端駅の名前と区間距離だけで良いわけです（それでも膨大なデータになることは違いないでしょう）。

アルゴリズムの解説では、サブブロック化に重点がおかれています。北は北海道から南は鹿児島までの旧国鉄の路線網をグラフ構造にしたとしても、現実の日本列島を考えれば、全体を一気に計算するよりも、一部分（これをブロックと呼んでいる）を計算して、最後に全体を統合すれば、最終的な計算量が削減されることが期待できます。

例えば、北海道と本州は青函連絡船を使うしかないし、九州と本州は関門トンネルを使うしかないわけです。だから、北海道内や九州内のルートを計算する場合には、それ以外の地域の事を考えなくてよいことになります。

北海道、四国、九州は、上述したようなサブブロックとして計算できますが、本州をどうするかが問題です。サブブロックに分けられそうでもあり、分けるのは困難のようでもあり、なんとかしたいところです。ブロックに分けようとする意図は、全体を闇雲に計算すると計算量が爆発し、その当時の計算機では処理が終わらなくなる恐れがあるからでしょう。当時の計算機よりも、今日のパソコンの方が性能が圧倒的に良いと思うので、もしかすると余計なサブブロックを考えなくても、計算できるかもしれません。

プログラムはFORTRANで組んだようです。その当時なら、このような計算をするならFORTANに決まっているでしょう。この記事には、それ以外（プログラムリストとか、実行時間など）の具体的なことは何も書かれていません。CiNiiで探してみたら、京都大学学術情報リポジトリに「長い片道切符について（計算機によるパズル・ゲームの研究）」というメモが「数理解析研究所講究録(1976), 263:75-76」として見ることができました。手書きなのが時代を反映しているところですが、「使用言語はFORTRANで使用計算機はFACOM 270-20(LOAD/ADD 4.8μs)での時間である」とあります。

面白そうなので、自分でもやってみたくなりました。プログラムはFORTRANでも良いのですが、今ならPythonを使ってみたいところです。グラフ構造を取り扱うためのPythonモジュールがあれば、いろいろと楽ができるでしょう。

ここで行く手に大きな問題があることに注意が必要です。1975年当時の国鉄と、2019年現在のJR各社とでは、事情が大きく変わっているのです。特に次の点が重要です。

1. 新幹線開業にともない並行在来線がJRから切り離されている。
2. 鉄道網が衰退（特にJR北海道）しており、グラフ構造で最長片道ルートを計算するというほど路線が残っていない。

2番目の問題は、計算量が少なくてガッカリするという程度の話にすぎませんが、1番目の問題は重大です。北海道新幹線が開通したことにより、JR北海道から切り離された道南いさりび鉄道の扱いが問題になるからです。新幹線が開業したことによりJRから切り離された路線は他にもありますし、長野新幹線の開業により横川と軽井沢の間は在来線が無くなりました。このような事情を考えると、どのような方針を採用するか考えておく必要があります。

1.  全ての新幹線もルート検討に加える。ただし、路線の距離は、「営業キロ」なのか「実キロ」なのか、混乱しないようにすべきである。
2. JRから切り離された第三セクター路線を、ルート検討に含めるか、除外するか決めておく。もし新幹線も除外し、第三セクター路線も除外するならば、北海道から本州に抜けるルートが無いということになります。
3. いっそのこと全ての私鉄もルート検索の対象に含める。しかし「最長片道切符」の本来の意図は、「一枚の切符で最長距離」となることに意義があるため、ちょっとやり過ぎなのかもしれません。

最長片道切符のルート問題は、グラフ理論の応用問題です。ここで日本の鉄道網であるという知識を利用すると、すっきりしたグラフ理論のアルゴリズムというより、個別事情の集合という汎用性の乏しい問題に堕ちてしまいそうではあります。いずれにせよ、面白そうなので、なんとかものにしてみたいと思います。

2019年7月28日3時31分発生三重県南東沖地震

2019年7月28日3時31分頃に三重県南東沖でM6.5の地震が発生しました。震源の深さは約420kmだそうですから、かなり深いところで起きています。

気象庁が発表した震度分布図を見ると、直観とは異なる状況が見て取れます。

まず第一に、震源が三重県南東沖なのに、愛知県では震度1程度にもかかわらず、宮城県で震度4、福島県や茨城県で震度3が観測されていることです。三重県では震度1の観測すらありません（実際には、微かな揺れを感じた人はいるのかもしれませんが）。震源に近い愛知県が震度1で、東北地方から関東地方の太平洋沿岸で強く揺れているようです。

次に、北海道の釧路町でも震度2を観測しているのに、西日本（中国、四国、九州）では、震度1の観測が全くありません。

地球の内部構造は、同心円状に揺れが伝わっていくわけではないということなのでしょう。三重県沖であれば、西日本全体を覆っているユーラシアプレートの範疇なのにもかかわらず、東日本を覆っている北アメリカプレートのエリアの方が揺れているという現象が起きているのが、興味深いところです。

「梅雨明け」の基準と実態

気象庁のWebに「令和元年の梅雨入りと梅雨明け（速報値）」というページがあり、「 更新日：令和元年7月25日」では東海、関東甲信、東北南部、東北北部の梅雨は明けていないことになっています。しかし梅雨前線は、とっくの昔に消えていて（素人目には、そう見えます）、数日前から最高気温が30度を超すようになっていますし、既に梅雨は明けているように見えます。四国、中国、近畿は「7月24日ごろ」に梅雨が明けていることになっているので、東海や関東甲信も梅雨明けで良いのではないかおもいますが（素人考えでは）、きっと気象庁の「梅雨明け基準」の何かを満たしていないのでしょう。

気象庁が発表する情報は、さすがに「何となく」というわけにはいかないでしょうから、何らかの基準を踏まえて発表するのでしょう。熱帯低気圧が台風になり、さらに温帯低気圧に変わる場合や、台風の大きさや強さを表現する場合は、何らかの尺度に従って発表されます。それは現実を表していると言って良いだろうと思います。これに対して、気象庁が発表する「桜の開花日」などは、地元の桜を全て見て廻るわけにはいかないでしょうから、サンプルとして指定された「特定の桜」が開花したかどうかに過ぎないはずです。代表として選ばれた桜の開花が、その地域を代表すると考えて差し支えないように選ばれているはずですが、本当に代表しているのか評価はしていない（しようがない）だろうと思います。

話を梅雨明けに戻すと、Webを検索すれば「梅雨明けの基準」と思われるものが見つかります。しかし気象庁の判断を類推しているに過ぎないので、本当に間違いない情報なのかという確実性はなさそうです。

今年の梅雨明けは何時になるのでしょう。いつ発表されるのでしょう。もしかすると「既に梅雨は明けていました」という発表になるのでしょうか。

地域の祭りと部署の宴会

Webの掲示板を見ていたら、地域外の者が地域の祭りに参加するのは非常識なのかという問いかけがありました。それに対して、そんなことはないという意見もあれば、駄目に決まっているという意見もありました。個人的には、参加者を制限する「祭り」って一体なんだろうと思いますので、地域内外を問わずに自由に参加して構わないと考えます。しかし参加しようとしたところ、地域外の者であることを理由に拒否されたという経験がある事例も少なくないようです。

この問題は、「祭り」という言葉が表している「状態」に対して、個々人の受け止め方に差異があるのが原因のひとつではないかと思います。「祭り」という言葉から連想するのは、全国的にも有名な京都の祇園祭、大阪の天神祭り、浅草の三社祭など各地にあります。これらは、当初は地域の中で小ぢんまりとして始まったのでしょうが、現在では全国的な観光行事となっているので、参加者を限定することはないでしょう。これほど大規模でなくても、祭りというのは全て地域の人達の営みから生まれており、人々の一体感を盛り上げるために来るもの拒まずとして運営されるものですから、参加者を制約するのはありえないと思います。

ここで注意しておきたいのは、「祭り」という言葉が、上述したような状況を必ずしも表現した言葉にはなっていない事例もあるという事実です。例えば、ファミレスなどの季節イベントの名前として、「春のご卒業・新入学おめでとう祭り」のように「祭り」という文字を入れてくることがあります（これは例のひとつであり、現実の何かとは関係ありません）。これは常識として「祭り」といっても、上述した「祭り」とは違うと、普通は理解しています。それは問題ではないのですが、「祭り」という言葉が、「祭り」とは違う派生した状況を表現していることは、問題を生む原因となり得るでしょう。

話が飛躍するかもしれませんが、会社が部署ごとや全社規模でおこなう「宴会」について考えてみてはどうでしょうか。新年会でも忘年会でも、送別会でも歓迎会でも構いません。全社規模で行われる「宴会」なら、社員誰でも参加できるでしょうが、部署ごとに行われる「宴会」なら、他部署の「宴会」なら、参加しようとすると断られる可能性は否定できません。このような事は当然だと思えるし、その理由も納得できるでしょう。

「祭り」という言葉が（伝統的な）祭りを意味せず、ファミレス的な「祭り」や、宴会的な「祭り」までも意味している可能性が、問題を引き起こしている気がします。「祭り」ではないものを「祭り」と呼ぶのも問題ですが、ならば「私たちが言う「祭り」とは、このようなものです」と定義すれば良いのかというと、それは違うだろうと思います。

意味の広い語彙を使うなら、その意味で表現される範囲を踏まえた行動をせざるを得ないでしょう。それを避けたいのであれば、意味の限定された語彙を選択すべきなのではないかと思います。

鉄道の「駅」の由来

NHKが放送している「ネーミングバラエティー日本人のおなまえっ！」で、2019年7月18日放送では「鉄道のおなまえ」でした。その中の話題のひとつとして、鉄道の「駅」というのは古代から続く「駅制」の「駅」から採用されたと紹介していました。

古代駅制というのは律令時代の話だと思っていたのに、それが明治時代になってステーションの訳語として「駅」を採用する根拠になったことに驚きました。古代の制度が明治直前まで残っていたのだろうかと思います。

そういう疑問を感じていたところで、偶然『ある明治人の記録』を読んでいたところ、興味深い記述を見つけました。柴五郎が青森から東京に出るため、地租改正調査のために東北巡回中の大蔵省役人の首席である長岡重弘の供を願いでて許されました。その件に次のような記述があります。

 六月初旬なり。父上より賜りし竹行李を背負い、草鞋履き山高帽を耳までかぶりて出発す。長岡氏は牛輿に乗り、他は徒歩なり。長岡氏は心優しき人にて、幼少の余をいたわり、同氏の輿に同乗させ、あるいは駅馬に乗せなどして、実際に歩行せるは一日のうち四、五里なり。

ここに「駅馬」という語が現れます。これが番組で紹介された古代駅制のことなのでしょうか。

東京に出てきた柴五郎は、鉄道開通にも立ち会っています。

 九月十二日、東京―横浜間に最初の鉄道開通す。新橋停車場に造られた桟上に登りて参観す。天皇陛下、柿色の御装束を召され、同じく束帯の百官を従え、横浜より帰着の汽車より降り立ち給う。外国公使もまた列席し、荘厳華麗な式典なり。式後御浜御殿苑内開放されてさまざまなる余興あり。紅白の餅を撒き、余もこれを拾いたるを記憶す。

同じような事が『維新前夜』（野村兼太郎、昭和16年4月30日発行）の「鉄道開業式入場券」にも書かれています。しかしそれは『日本鉄道史』からの孫引きです。『日本鉄道史』というのは大正10年に鉄道省が発行したものだと思います。これは国立国会図書館のデジタルコレクションから見ることができます。

『ある明治人の記録』と『武士の娘』

Webで見かけた記事に紹介されていた『ある明治人の記録』を読んでみました。会津藩士の家に生まれた柴五郎が戊辰戦争に巻き込まれ、斗南に移住して底辺を彷徨った末に東京に出てきて陸軍幼年学校に入ります。戊辰戦争で会津が戦った頃から、陸軍幼年学校時代に西南戦争が起こり、その後の竹橋事件の頃までを本人が後年に書き記したものを、石光真人が若干の編集を加えて出版したものです。

会津藩士である柴家は、本書で「父柴佐多蔵は会津藩士、280石の御物頭」とあります。当時の著名な会津藩士というと、家老の西郷頼母が1,700石、同じく家老の家柄の山川大蔵が1,000石ということですから、武家としては中位に属しているのかと思います。柴五郎は陸軍大将にまで上り詰めたということです。戦前までの旧日本陸軍では、陸軍中将は1,200名以上もいるのに、陸軍大将となったのは134名に過ぎなかったそうです。薩長閥が階級を独占していた当時において、会津出身者としては頂点を極めたといえるでしょう。

このような華麗な経歴から逆算すると、人は勝手な想像をたくましくして、幼少の頃から神童の誉れが高かったのだろうとか、陸軍幼年学校に抜擢されて、なるべくしてなったのだろうとか、思いがちですが、本書を読むとそのような印象はまったく無く、むしろ底辺を彷徨った挙句に、運よく道が開けたという感じです。

戊辰戦争で会津藩が敗れ斗南に国替になったとき、柴五郎も親と共に斗南に移り住んだようです。斗南での生活の悲惨さは多く語り伝えられているとおりですが、柴五郎も例外ではなく、極寒の地に放り出された状態で、よくぞ生き残れたものだと思います。

生活が底辺を彷徨うようになると、知らず知らずのうちに精神が荒んでくるものです。当時は「プライド」のような横文字はなかったでしょうし、「自尊心」という言葉もなかったかもしれません。しかし「武士の子たることを忘れしか」と父に叱られたというエピソードが語られる中に、心が崩れていくのを押し留める決意が感じられます。

このようなエピソードに触れたとき、以前に呼んだことがある『武士の娘』を思い出しました。著者の杉本鉞子は越後長岡藩の家老だった家に生まれました。明治6年の生まれなので、既に長岡藩はなく（したがって家老の家でもなく）、戊辰戦争も体験していません。長岡藩は奥羽越列藩同盟の一員として戦い、会津同様に長岡城下が戦場になっています（河井継之助が有名です）。時代は明治なので「四民平等」とされていましたが、「武士の娘」としての教育を受け、その一端が本書で語られています。

柴五郎にしても、杉本鉞子にしても、武家としての誇りを失わずに生きたように思います。しかし失うまいと意地を張っているわけではないように思います。やせ我慢をしているということではないと思います。自然とそうなるのでしょう。その姿を見習いたいものだと思います。

投票と宝くじ

今年は4月に統一地方選があり、7月には参院選もあり、選挙が多い年になりました。以前から言われていることですが、投票率が下がっているようです。投票することは選挙権の行使ですから、投票しないのは権利を放棄していることになります。権利を行使しないのは残念なことだと思いますが、投票を強制させるような施策を講じるのも違うだろうと思います。

投票しない理由に、「投票しても何も変わらないから」というものがあると聞きます（他にも投票しない理由はあると思いますが）。この理由の真意をもっと分析しないことには軽々しく言えないとは思いますが、ようするに「自分の投票した候補者が当選したら「あたり」で、投票して良かったと感じるが、落選したら「はずれ」で、投票なんかして（時間の）無駄だったと思う」ということなのでしょうか。

こう考えているとすると、投票するのは勇気がいるでしょう。何故なら、誰が当選するか分からないと投票できないからです（勝ち馬に乗りたいということでしょう）。一番圧倒的な候補者に投票しておけば無難なのでしょうが、そういう候補者なら「自分が投票しなくても当選するだろう」と勝手に思い込み、結局投票しないかもしれません。

もしかすると、投票するという行為を、宝くじを買うという行為のように考えているのだろうかと思います。「あたる（当選する）なら、宝くじを買いたい（投票してもよい）」が、「あたるかどうか分からないなら、無駄金を使いたくない（時間を無駄にしたくない）」と、博打を打つ感覚なのでしょうか。

投票というのは、結果も大切なのは当然ですが、支持する（しても良いかなと思える）候補者を選ぶという行為に過ぎません。それだけのことです。それをすることが現代社会にコミットすることになりますから、投票しなければ、その人物は存在しているのに「存在していないとして扱われる」という奇妙な状態を選択していることになるでしょう（意識していないかもしれませんが）。

投票（選挙権の行使）は、自分の考えだけでおこなえば良いことで、他者の意向を気にする必要はないはずです。「自分は政治をよくわかっていないから」とか、「皆さんはどうするんですか」とか、こういうことを考えているなら、考える方向がおかしいと思います。日本人は笑い話のネタにされるくらい同調性を気にする国民なのかもしれませんが、自分の投票する候補者くらい他者の意向を気にせず選べば良いのにと思います。

名詞に「お（御）」を付けるか否か

名詞に「お」や「御」をつけるのは「丁寧語」に区分されます。これは「敬語」を構成する「尊敬語」、「謙譲語」、「丁寧語」の一つに相当する訳ですが、異論もあります。別に敬意を表しているわけではないから「美化語」と呼ぶべきだと主張しますが、今のところ異説のひとつであって、主流にはなっていないようです。

それはともかく、「お」は和語に、「御」は漢語に付けるのが原則です。ならば外来語の扱いが気になりますが、基本的は「お」も「御」も付けないと考えています（若干の例外はありますが）。

上述したルールは原則なので、例外も勿論ありますが、「お（御）」の有無にも個人差があります。社会一般における許容範囲というものもありますが、特定の世間（業界）における習慣なども考えられ、許容度の異なる集団が接触した場合に違和感や反発が生まれるようです。

よく耳にするのが「なんでも「お」を付けておけば無難」とする考え方です。そう考えている人にとっては、「お紅茶」、「おコーヒー」、「おビール（！）」のように表現するそうなのですが、僕には違和感があります。特に「おビール」とか言われたら「ここはいったいどこなんだ」と思うでしょうが、 「お酒」という表現には違和感がありません。「おビール」と「お酒」で良し悪しが分かれるのは、社会的習慣のなせる業としか言いようがないでしょう。

「お」を付ける語と付けない語の分別は、社会における合意があるようで、微妙なところで一致していないと思われます。だから差異が出てしまうのは仕方のないことで、その違いを愉しむことがコミュニケーションの醍醐味であるのかもしれません。少なくとも、「お」の有無に目くじらを立てて、自分の基準に相手を合わせようと仕向けるのは、多様性を認める社会のあるべき姿ではないと考えます。

さらに考察を進めると、「お」が付くことで意味が変わる場合があります。例えば「受験」という語はどうでしょうか。「お受験」となる場合、「お」を付加したことによる「丁寧語（美化語）」というだけではない含意があります。誰かに対して「受験するのですか？」と尋ねた場合と、「お受験するのですか？」と尋ねた場合は、意味が変わってきます。前者であれば、誰もが経験するような高校受験や大学受験などを想像しますが、後者であれば、（エリートコースを狙っているか否かわかりませんが）私立の小学校受験（もしくは、中学校受験や、場合によっては幼稚園受験など）が言外に意味している筈です。

さらに「勉強が得意ですね」と「お勉強が得意ですね」を比べれば、前者なら誉め言葉として受け取れますが、後者だと（誉め言葉だと主張できる余地を残していますが）あてこすりと判断されてもやむを得ない側面があります。

このように「お」という語は日本の文化や社会現象を表象していると考えてよいだろうと思います。

派生的な話題となりますが、最近たまに耳にするようになった言葉として「お名前様」というものがあります。「名前」を丁寧に表現するために「お」が付いているのに、それだけでは丁寧さが表現できていないと考える人が多くなっている模様です。「なんでも「お」を付けておけば無難」とする発想の延長線上に、「なんでも「様」をつけておけば無難」とする発想が生まれてくるのでしょう。これは現代日本に限った現象ではないだろうと思います。例えば「御御御付け」という言葉があるように、丁寧さを狙って生まれた語彙が、丁寧さとしての感覚を失った際に、さらなる丁寧語が付加されるのは、昔からある現象ということでしょう。

「微分方程式('17)」と検算のためのWolfram AlphaやMaxima

放送大学で今期は「微分方程式('17)」を受講しています。もうすぐ単位認定試験が行われるので、試験準備のために勉強しています。過去に受講した科目では、試験ぎりぎりになって慌てずに済むように4月から勉強しておけば良かったと（強く）思いながらも、6月末から7月になってから一夜漬けで試験勉強を済ませ、なんとなく単位を取得していました。こんな方法では身につかないと、いつも思うのですが、他にもやることがあることを言い訳にして、いつも直前に焦って試験対応をしていました。

今回は講義の進行に合わせて4月から勉強してきました。印刷教材の章末問題も解き、通信指導についている自習型問題も解いてみました。過去に受講した科目では、これらをやろうと思いながらも、手つかずのまま単位認定試験に臨んでおり、その結果として不完全燃焼感が後に残りました。その反省を踏まえて、4月から少しずつ勉強してきたわけですが、それでも微分方程式は簡単ではありません。印刷教材の内容も、あまり理解できずにいる箇所も少なくありません（特に証明）。 しかしながら、今までは微分方程式（や微積分）は五里霧中という感じでしたが、僅かに薄日が差してきたような気もしています。何事もそうかもしれませんが、勉強してみて分からなかったからと言って投げ出さず、振り落とされそうになってもしがみついていたら、僅かずつでも理解できるようになっていくのではないかと思います。スラスラできるようになれば嬉しいですが、そうでなくても一歩前進したことは間違いありません。

微積分のような理数系科目は、語学のような文系科目に比べると、正誤がはっきりしているので、考えようによっては勉強しやすいとも言えます。微積分を学んでみて、漠然とした概念レベルであれば、別に難しくはないと思います。思考方法の癖のようなものがあったとしても、概念の理解に差し障るほどではないと感じています。それでは何が難しいのかというと、実際に演習問題を解くことです。

理論を理解できているか確認するために、演習問題が用意されている教科書が多くあります。問題が解ければ、理論を理解したと判断されます。もし解けなければ、理論が分かっていないと判断されることになります。理屈の上ではそうですが、実際には問題は解けたけど、理論は理解できていないという事も少なくないのではないかと思います。仮にそうだとしても、演習問題に取り組むことは大切です。問題が解ければ、理解したという気持ちになれますし、問題を解く過程で、教科書に記述されている事柄の意味が分かってくることもあります。

演習を解いて、正解ならば良いのですが、問題なのは不正解だった場合です。よくある間違いは、不正解となった問題を放置して、他の問題に取り組むことです。出来る問題を多数こなした方が良い場合もありますが、不正解の問題について、式の展開などを見直して、間違えたポイントを納得することも大切です。

微積分（に限りませんが）に役立つ道具として「Wolfram Alpha」と「Maxima」を使ってみました。これらの存在は以前から知っていましたが、便利そうな道具らしいと考えているだけでした。どちらにも使い方のコツのようなものがあるので、自分に合った方を使えばよいと思います。今回はWolfram Alphaを多用しました。

Wolfram Alphaを使えば、問題によっては一気に答えが出てきます。便利と言えば便利ですが、自分で勉強しなくても答えが出てくるのは危険でもあります。その答えが導き出される過程を学んでいる筈なので、答えが出てきたことに喜んでいるだけでは、話になりません。しかし途中結果を確認するために使うのであれば、とても役に立ちます。自分の計算が、最終的に正答にならない場合、途中計算のどこで間違えているのかを確認することができるからです。教科書の演習問題によっては、途中結果が示されていないこともありますし、仮に途中結果が示されていたとしても、自分の計算過程とは違う場合もあります。このような場合にWolfram Alphaで計算させてみれば、自分の誤りを見つける参考になります。

Wolfram Alphaを使ってみて便利であることを実感しましたが、無料で使える範囲は制限されており、機能の制限をなくすには有償となるようです。一方でMaximaは、Wolfram Alphaに比べれば素朴な完成度に見えますが、全ての機能を無料で利用できます（自分のマシンにインストールしなければなりませんが）。Maximaが普段使いの道具となるように、使い方を練習しておこうと思います。

System panicked: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0 || panicstr != NULL" failed: file "/usr/src/sys/kern/kern_condvar.c", line 170

dynabook SS SX/15AにNetBSD/i386を入れて利用しています。もう10年以上前のマシンなので、いろいろなところが故障していても不思議ではないとは思いますが、本当に故障しているのか、何か他に原因があるのかは見極めなければなりません。

今春あたりから、カーネルが頻繁に落ちるようになりました。酷い時は、ブート中に落ちて、再起動がかかっている最中に再度落ちて、それが何度も繰り返されます。ところが全く問題なく起動できることもあるのです。何が悪いのでしょう。何処が悪いのでしょう。

何が問題なのか突き止めていませんが、感覚的には「公共施設で無料で使えるWiFiを利用していると落ちることが多い」ような気がしてきました。自宅でも落ちることはありますが、外出先と自宅とでは頻度が全然違う感じがしています。

またクラッシュ情報を解析すると、落ちる場所は決まっています。

# crash -M netbsd.34.core -N netbsd.34
Crash version 8.99.41, image version 8.99.43.
WARNING: versions differ, you may not be able to examine this image.
System panicked: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0 || panicstr != NULL" failed: file "/usr/src/sys/kern/kern_condvar.c", line 170
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET(0,104,c011b026,8,c06f2ad3,c1138f1d,0,104,c10a7924,dc6bdee8) at 0
_KERNEL_OPT_BEEP_ONHALT_COUNT(104,0,c10a7924,dc6bdee8,c4d142e0,c516abe8,c516abe4,dc6bdedc,c0db730e,c10a7924) at _KERNEL_OPT_BEEP_ONHALT_COUNT+0x1
vpanic(c10a7924,dc6bdee8,dc6bdf0c,c090c2a0,c10a7924,c10a788b,c115c4c4,c115c4a0,aa,c5169000) at vpanic+0x13d
kern_assert(c10a7924,c10a788b,c115c4c4,c115c4a0,aa,c5169000,c51d61c8,c5169000,c516abe4,c516abe8) at kern_assert+0x23
cv_wait(c516abe8,c516abe4,ffffffff,c00,82000008,c4d142e0,c5169000,dc6bdf94,c02cc9d8,c5169004) at cv_wait+0x1a8
wpi_stop(c5169004,1,8,82000008,2,101,dc9c6010,dc9c6010,c0921aa9,c13de400) at wpi_stop+0x80
wpi_softintr(c5169000,0,c0100400,1674000,1670010,30,c0100010,10,0,1d14020) at wpi_softintr+0x2cb
softint_dispatch(c4d14020,4,37bbaff2,a1a6dfbe,76bef7da,27b6dfdb,dc6c0ff0,dc6c0e2c,dc6c0e80,80050033) at softint_dispatch+0xc1
Bad frame pointer: 0xc4fdbe48
crash>

カーネルの不具合なのか、マシンのハードウェアが故障しているためなのか、どちらの原因なのか判断する情報がありません。なんとか探ってみようと思います。

矢内原忠雄「ヨブ記研究」を読んで

NHKで放送されている「100分 de 名著」で「旧約聖書」を取り上げた時に「ヨブ記」が紹介されました。旧約聖書というと「創世記」、「ノアの箱舟」や「モーセの十戒」が有名です（それだけではありませんが）。聖書は「世界で一番売れている書物」とも言われているので、「創世記」や「出エジプト記」を始めとする「旧約聖書」に含まれる諸本は常識の範疇なのかもしれません。

それ以来「ヨブ記」を読んでみようと思っていましたが、ようやく読む機会がありました。それほど長い物語ではないので、読むこと自体は難しくありません。しかし「ヨブ記」に限りませんが、聖書の物語は、旧約聖書も新約聖書も、字面の表面的な意味だけでは理解しにくく、その奥にある含意を理解したいところです。そこで教会に行ってみて質問するという方法もあるかもしれませんが、それよりも一般に参照できる文章として読んでみて、それでも理解できなければ（次の方法として）教会の門を叩くことを考えてみようと思います。そこで図書館に行ってみたところ『聖書講義VIII（第1分冊）』（矢内原忠雄、岩波書店、1978年）の中に「ヨブ記研究」などが含まれていたので借りてきて読んでみました。

「ヨブ記」の解釈が、この書籍に書かれている事柄しかないという訳ではないとは思います。しかし納得できる解釈が提示されていると感じました。「2 ヨブ記の主題」には次のように書かれています。

 ヨブ記の主題は「人生における苦難の意義」である。ヨブ記の著作された時代のこの問題に関する一般的見解は、神は義人に祝福として人生の幸福を与へ、悪人に刑罰として苦難と災害を与へ給ふ、といふのであつた。更に進んで、人の義とこれに与へられる祝福、罪とこれに課せられる災禍とは、それぞれ量的に比例するといふ機械的な考へが支配的であつた。

ここから三段論法的に次のような解釈がなされると書かれています。

1. 神は義人に幸福を与へ、悪人に災禍を与へ給ふ。
2. ヨブは大なる災禍を与へられた。
3. それ故ヨブは大なる悪人であるに違ひない。
4. ヨブは己が罪を告白して、神の赦しを求むべきである。
5. さうすれば神はヨブの苦難を解き、彼に幸福をかへして下さるであらう。

このような思考方法は、ヨブ記の時代だけではなく、現代でも同じでしょう。不幸に苦しむのは己の罪によるのだという自己責任論は、今日でも一般に流通しています。しかしヨブは反論します。これを現代風に表現すれば（嫌な表現だとは思いますが）「逆ギレ」していると言われるところでしょう。

ヨブ記では最終的に、ヨブは神に対して己の無知を告白することになります。ここの下りに対して本書では次のように書かれています。

この常識的に見て意外な結末が信仰的に見て意外でないことを知ることこそ、ヨブ記から学ぶ最大の教訓でなければならない。ヨブ自身その教訓をヱホバの御言から学んだが故に、彼はおのれについて後悔し、ヱホバについて満足したのであつた。

これは一体どういうことなのでしょう。世界各地で信仰されている宗教に対して、人々の多くは「義人には幸福を、悪人には災禍を」という素朴とも言える発想で理解しています。だから不幸なのは（だと感じるのは）我が身に罪があるからだと理解しています。しかしながら現実の世界は、悪人（のように見える）なのに幸福で、義人（である筈）なのに災禍にみまわれるのは、良くあります。だから「この世には神はいないのか」とか（心の中で、ですが）叫ぶ人が少なくないのです。

「ヨブ記」はハウツー本ではないので、これを読んで理解すれば直ちにハッピーになれるというようなものではありません。読んで学んだことを自分の人生に生かすには、もっともっと考えなければならないでしょう。その手掛かりの一つを与えてくれる書物には違いないと思います。

XML形式の情報をCSV形式に変換したい

Microsoft Windowsで使用しているパスワード管理ソフトIDMの情報はXML形式で保存されています。またNetBSDで使用しようと思っているパスワード管理ソフトKeePassXCではCSV形式の情報を取り込むことができるようです。そこでXML形式の情報をCSV形式に変換する手法を検討しようと思います。

すぐに思いつくのが、手頃なツールでテキスト処理をおこなうことでしょう。pythonであれば、標準ライブラリElementTreeでXMLを扱えますし、同じく標準ライブラリCSVもあります。python以外を使っても構いませんし、XMLパースを行わず、XML形式を意識しないでテキスト処理をおこなうことも可能でしょう。

別な方法としてXSLTを利用することもできるようです。

1. [XML]xsltprocを使って、XMLをCSVに変換する
2. xmlからcsvへの変換（xsltprocコマンド）
3. XML to CSV Using XSLT

XSLTについては、名前だけは知っていますが、実際に使ってみた経験はありません。それを言ったら、pythonでElementTreeやCSVを扱った経験もないのですが、python自体は経験がありますので、その延長線上でなんとかなると思っています。ここでXSLTを使ってみるのも、経験値を上げるには良いのではないかと思っています。

NetBSDではpkgsrcにあるtextproc/libxsltにxsltprocが入っているようです。またIBMのサイトに次のような情報も見つけました。

1. ヒント: XSLT の極意
2. XSLTはどのような言語か

Sn(f;{xj},{ξj})

以前に入手したサイエンス社の「数理科学」2018年5月号（特集／微積分の考え方）を読んでいます。内容が専門的（と言っても、専門の中では初歩段階ですが）なので、理解しながら読もうとすると、なかなか先に進みません。理解できる（と自分では思える）必要がなければ、数ページ程度ならあっという間に読んでしまえますが、それでは読んだ後には何も残らないでしょう。そこで時間はかかりますが、何度も繰り返し読んで（他の書籍、Web情報などからの理解も試みますが）みて、少しずつでも理解できるようにしているところです。

このような専門的な記事を理解する際には、その専門知識の素養が必要となる事は言うまでもありません。加えて、教科書などで説明されるほどでもないような、ちょっとした知識（常識と言い換えても構いません）が、理解する上での障害になることもあります。

例えば「積分の見方」（筧三郎、pp.35-42）には次のような記述がありました。

 そして，閉区間[a,b]上で定義された関数f(x)，[a,b]の分割{xj} (j=0,1,...,n)，代表点{ξj} (j=1,2,...n)を定めたときの“リーマン和”Sn(f;{xj},{ξj})を，次のように定義する：

ここで疑問に思ったのが「Sn(f;{xj},{ξj})」で使われている「;」です。専門的な書籍において、たまに（自分にとって）見慣れない使われ方をしている記号を目にすることがあります。その説明が書籍内にあれば、ひとつ理解が進んだという気になれるのですが、何も説明がない場合が（多いように思う）あります。おそらく著者にとって常識に属しているので、わざわざ説明するまでもないと考えているのでしょう。

こういう場合にWebを検索し、自分と同じような疑問を解決しようとしている情報を見つけることができます（見つからないかもしれませんが）。すると「数学でのセミコロンについて」を見つけました。要するに「真っ正面から論じれば、セミコロンなんか使う意味はありませんで、カンマにしとく方が真っ当である。」ということのようです。ここに書かれているような解釈で正しいのかは別途検証する必要がありますが、当面気にしすぎなくても良いということが分かってホッとしています。

KeePassXCの文字化け（「@」→「"」）が復旧

dynabook SS SX/15AにNetBSDを入れ、MATEデスクトップ環境を採用し、利用環境を整えています。ただ残念ながら所々に怪しい動作が残っています。Firefox（pkgsrcから入れるとNightlyになりますが）を入れ、パスワード管理ソフトとしてKeePassXCを入れました。

パスワード管理ソフトとして、Microsoft WindowsではIDMを使っています。NetBSDでは、過去にはKeePassを使おうとしていましたが、よく落ちて不安定なので、あまり利用していませんでした。そこでKeePassを止めてKeePassXCを使ってみることにしました。

KeePassXCを使うのが初めてなので、IDMで利用しているエントリを試しに入れてみて使い勝手を確認してみようとしました。ユーザーIDはメールアドレスなので「@」が含まれています。ところが入力時に「@」が「"」に化けてしまいます。このままでは利用できないので、調査しました。

全ての文字が化けている訳ではないようです（確かめた訳ではありませんが）。「@」が「"」に化けるというのは、ASCII配列キーボードとJIS配列キーボードの相違を思い起こさせます。

問題の在所を絞り込むために、幾つか条件を変えて挙動を確認しました。

1. rootアカウントで動作を確認しました。rootアカウントではMATEデスクトップ環境を使用しておらず、昔懐かしtwmのシンプルな（質素な？）画面構成です。ここでは問題となっている文字化けが起きませんでした。と言う事は、MATEデスクトップ環境の何かに原因がありそうです。
2. KeePassXCを起動する前に、環境変数LANGをCにして起動してみました。しかし問題となる現象は変わりませんでした。
3. xevを使ってKeePassXCがブラウザに送っているイベントを調べてみました。やはり「"」を送っているようです。

   KeyPress event, serial 39, synthetic NO, window 0x3200001,
       root 0x7e, subw 0x0, time 1699682, (657,286), root:(811,465),
       state 0x2001, keycode 11 (keysym 0x22, quotedbl), same_screen YES,
       XKeysymToKeycode returns keycode: 48
       XLookupString gives 1 bytes: (22) """
       XmbLookupString gives 1 bytes: (22) """
       XFilterEvent returns: False

MATEデスクトップ環境の設定の中に「キーボード」があるので、調べてみました。すると何故か以下のようなエントリが入っており、しかも「US English」が最上位になっています。

1. US English
2. Japanese
3. Japanese (kana)
4. Japanese

不思議なのは、キーボードの指定の最上位に「US English」があっても、通常のキー入力には何の問題もないのです。dynabook SS SX/15Aのキーボードは（ノートPCとしての）JIS配列です。これまで使っていて、JIS配列通りにキー入力が出来ています。しかし設定が怪しいので、「デフォルト」ボタンを押したら、「Japanese」のエントリを残して、他の3つのエントリが消えました。

この状態でKeePassXCの動作を確認したところ、問題となっていた文字化けは解消しました。キーボードの指定が変だったのが原因だったようです。

これでKeePassXCは正常に使える状態になったので、利用環境を整える調査を続行しようと思います。

「ブラウザー統合」を有効にしたKeePassXCとFirefoxが接続できない

dynabook SS SX/15AにNetBSDを入れて、利用環境を整えようとしています。ブラウザとしてFirefoxを使うので、パスワード管理ソフトとしてKeePassXCを使ってみようと考えています。pkginを使って入れた出来合いのバイナリパッケージは、「ブラウザー統合」が有効になっていませんでした。仕方ないので、「ブラウザー統合」が有効になるように定義して、自前でビルドしました。

自前ビルド版KeePassXC 2.4.0を立ち上げると、設定画面に「ブラウザー統合」が現れました。そこでFirefoxを選択したのですが、設定が記憶されません。立ち上げるたびに、Firefoxの設定が外れているので、毎回設定する必要がありますが、何が悪いのか分かりません。

ブラウザ（Firefox）側にはKeePassXCと連携するためのアドオンを入れる必要があります。入れたのですが、エラーが出てしまいます。

Cannot connect to KeePassXC.  Check that browser
integration is enabled in KeePassXC settings.

KeePassXCとブラウザが連携すると使い勝手が良いようなのですが、連携しなくてもKeePassXCは利用できる筈です。ひとまず非連携モードで使ってみました。

試しにエントリを準備してみました。使い勝手は、Microsoft WIndowsで利用ているIDMと似ている気がします。そのような使い勝手であることには納得しましたが、なぜか入力文字列が化けてしまいます。文字が全て化けるのではなく、メールアドレスに使われている「@」が「"」に変化してしまいます。どうしてこうなるのでしょう。これが解決しない事には、KeePassXCを本格的に利用するわけにはいきません。なんとかしたいと思います。

ちなみに、自前でビルドして「ブラウザー統合」が有効になりました。しかしブラウザ側と繋がらないし、なくても良さそうなので、 pkginから導入する出来合いのバイナリパッケージを使うことにしようと思います。

「ブラウザー統合」を有効にしたKeePassXCがビルドできた

dynabook SS SX/15AにNetBSDを入れて利用しています。このマシンには元々はMicrosoft Windows Vistaが入っていました。その頃に利用していたIDMというパスワード管理ソフトの代替を探していましたが、KeePassXCが良さそうなので使ってみることにしました。手間暇を惜しむためにpkginを利用して出来合いのバイナリパッケージを使うことにしています。

KeePassXCを起動してみると、なぜか設定画面に「ブラウザー統合」がありません。調べてみたところ、どうやらpkgsrcから作成すると「ブラウザー統合」が無効になっていることが分かりました。そこで「ブラウザー統合」を有効にしたものをpkgsrcから自前でビルドしてみようと思います。

ところがビルドしようとしたらエラーが出ました。

[  5%] Built target keepassxcbrowser_autogen
[  5%] Building CXX object src/browser/CMakeFiles/keepassxcbrowser.dir/NativeMessagingBase.cpp.o
In file included from /usr/include/stddef.h:37:0,
                 from /usr/include/g++/cstddef:50,
                 from /usr/pkg/qt5/include/QtCore/qglobal.h:46,
                 from /usr/pkg/qt5/include/QtCore/qatomic.h:41,
                 from /usr/pkg/qt5/include/QtCore/QAtomicInteger:1,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.h:22,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:19:
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp: In member function 'void NativeMessagingBase::newNativeMessage()':
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:65:5: error: invalid static_cast from type 'std::nullptr_t' to type 'intptr_t {aka int}'
     EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);
     ^
*** Error code 1

Stop.
make[2]: stopped in /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
*** Error code 1

このエラーを見るとEV_SET()に問題がありそうです。調べてみると、EV_SET()が使われているのは、どうやらここだけのようです。

% find work/keepassxc-2.4.0/src -type f | xargs grep EV_SET
work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:    EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);

しかも、この箇所はLINUX以外のUNIX系OSにしか影響がないようです。ソースの変更状況を確認するとKeePassXC 2.3.0-betaの頃に入ったコードのようです。

    53  void NativeMessagingBase::newNativeMessage()
    54  {
    55  #if defined(Q_OS_UNIX) && !defined(Q_OS_LINUX)
    56      struct kevent ev[1];
    57      struct timespec ts = {5, 0};
    58
    59      int fd = kqueue();
    60      if (fd == -1) {
    61          m_notifier->setEnabled(false);
    62          return;
    63      }
    64
    65      EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, NULL);
    66      if (kevent(fd, ev, 1, nullptr, 0, &ts) == -1) {
    67          m_notifier->setEnabled(false);
    68          ::close(fd);
    69          return;
    70      }
    71
    72      int ret = kevent(fd, NULL, 0, ev, 1, &ts);
    73      if (ret < 1) {
    74          m_notifier->setEnabled(false);
    75          ::close(fd);
    76          return;
    77      }
    78  #elif defined(Q_OS_LINUX)
    79      int fd = epoll_create(5);
    80      struct epoll_event event;
    81      event.events = EPOLLIN;
    82      event.data.fd = 0;
    83      if (epoll_ctl(fd, EPOLL_CTL_ADD, 0, &event) != 0) {
    84          m_notifier->setEnabled(false);
    85          ::close(fd);
    86          return;
    87      }
    88
    89      if (epoll_wait(fd, &event, 1, 5000) < 1) {
    90          m_notifier->setEnabled(false);
    91          ::close(fd);
    92          return;
    93      }
    94  #endif
    95      readLength();
    96  #ifndef Q_OS_WIN
    97      ::close(fd);
    98  #endif
    99  }

EV_SET()に問題がありそうだという事、またLINUX系ディストリビューションには影響がない（から、そちらからのフィードバックで修正される）事は分かりましたが、どのように直したら良いのかわかりません。ただしエラーメッセージを見る分にはキャスト絡みのようです。Webを検索したら「*BSD で kqueue・kevent を使ってみよう」というページが見つかりました。それを見ると、EV_SET()の最後のパラメータはNULLが指定されています。これが問題の原因なのでしょうか。

試しにnullptrをNULLに書き換えてみたところ、エラーが消えてビルドに成功しました。ただし、このような変更が正しいのかは、確信がありません。nullptrというのはC++11で導入されたようですが、次のような情報も見つかりました。

1. NULLとnullptrの違い 
2. C NULLがC 11 nullptrと等しいか 

ビルド出来ましたが、keepassxc-proxyというのも出来ていました。このためPLISTを変更する必要がありました。

--- PLIST.org   2019-03-23 00:56:41.000000000 +0900
+++ PLIST.new   2019-07-10 09:31:09.155023065 +0900
@@ -1,5 +1,6 @@
 @comment $NetBSD: PLIST,v 1.4 2019/03/22 15:56:41 ryoon Exp $
 bin/keepassxc
+bin/keepassxc-proxy
 bin/keepassxc-cli
 lib/keepassxc/libkeepassx-autotype-xcb.so
 man/man1/keepassxc-cli.1

ちなみにMakefileは次のように変更しました。

--- Makefile.org        2019-03-23 00:56:41.000000000 +0900
+++ Makefile.new        2019-07-10 15:29:19.274685074 +0900
@@ -18,7 +18,7 @@
 USE_CMAKE=     yes
 USE_LANGUAGES= c c++
 CMAKE_ARG_PATH=        ..
-CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release
+CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release -DWITH_XC_BROWSER=ON -DWITH_XC_NETWORKING=ON
 CONFIGURE_DIRS=        build
 
 NOT_PAX_MPROTECT_SAFE+=        bin/keepassxc
@@ -36,6 +36,7 @@
 .include "../../devel/zlib/buildlink3.mk"
 .include "../../graphics/hicolor-icon-theme/buildlink3.mk"
 .include "../../security/libgcrypt/buildlink3.mk"
+.include "../../security/libsodium/buildlink3.mk"
 .include "../../security/argon2/buildlink3.mk"
 .include "../../sysutils/desktop-file-utils/desktopdb.mk"
 .include "../../x11/qt5-qtbase/buildlink3.mk"

KeePassXCの「ブラウザー統合」は有効に出来そうだけど、ビルド失敗

dynabook SS SX/15AにNetBSDを入れて利用しています。パスワード管理にKeePassXCを使おうと思いましたが、pkgsrcからビルドされるバイナリには拡張機能「ブラウザー統合」が有効になっていないことが分かりました。

この問題を解決するために、pkgsrcの枠組みに沿って変更するためには、どのようにするのが正しい方法なのか不明です。それは追々調べるとして、まずは「ブラウザー統合」を有効にしたバイナリをビルドしてみようと思います。

まずsecurity/keepassxc/Makefileを以下のように変更してみました。またlibsodiumが必要になるようなので、依存関係の定義を追加しました。libsodiumのパッケージ自体も入れておきます。

--- Makefile.org        2019-03-23 00:56:41.000000000 +0900
+++ Makefile    2019-07-09 20:05:49.976935366 +0900
@@ -18,7 +18,7 @@
 USE_CMAKE=     yes
 USE_LANGUAGES= c c++
 CMAKE_ARG_PATH=        ..
-CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release
+CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release -DWITH_XC_BROWSER=ON -DWITH_XC_NETWORKING=ON
 CONFIGURE_DIRS=        build

 NOT_PAX_MPROTECT_SAFE+=        bin/keepassxc
@@ -36,6 +36,7 @@
 .include "../../devel/zlib/buildlink3.mk"
 .include "../../graphics/hicolor-icon-theme/buildlink3.mk"
 .include "../../security/libgcrypt/buildlink3.mk"
+.include "../../security/libsodium/buildlink3.mk"
 .include "../../security/argon2/buildlink3.mk"
 .include "../../sysutils/desktop-file-utils/desktopdb.mk"
 .include "../../x11/qt5-qtbase/buildlink3.mk"

この状態でビルドさせてみると「ブラウザー統合」が有効になっていることが確認できます。

===> Configuring for keepassxc-2.4.0 keepassxc-2.4.0
*SNIP*
-- Enabled features:
 * Auto-Type, Automatic password typing
 * Networking, Compile KeePassXC with network access code (e.g. for downloading website icons)
 * KeePassXC-Browser, Browser integration with KeePassXC-Browser

-- Disabled features:
 * SSHAgent, SSH agent integration compatible with KeeAgent
 * KeeShare, Sharing integration with KeeShare
 * KeeShare-Secure, Sharing integration with KeeShare with secure sources
 * YubiKey, YubiKey HMAC-SHA1 challenge-response

-- Configuring done
-- Generating done
-- Build files have been written to: /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build

またlibsodiumなどの依存関係も大丈夫そうです。

=> Tool dependency glib2-tools-[0-9]*: found glib2-tools-2.60.3
=> Tool dependency cmake>=2.8.1nb1: found cmake-3.14.5
=> Build dependency x11-links>=1.13: found x11-links-1.15
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
=> Full dependency qrencode>=4.0.2: found qrencode-4.0.2
=> Full dependency hicolor-icon-theme>=0.9nb1: found hicolor-icon-theme-0.17
=> Full dependency libgcrypt>=1.6.0: found libgcrypt-1.8.4
=> Full dependency libsodium>=0.3: found libsodium-1.0.17
=> Full dependency argon2>=20161029nb1: found argon2-20171227
=> Full dependency desktop-file-utils>=0.10nb1: found desktop-file-utils-0.23nb1
=> Full dependency qt5-qtbase>=5.11.2nb3: found qt5-qtbase-5.12.2nb1
=> Full dependency qt5-qtsvg>=5.11.2nb2: found qt5-qtsvg-5.12.2
=> Full dependency qt5-qttools>=5.11.2nb2: found qt5-qttools-5.12.2
=> Full dependency qt5-qtx11extras>=5.11.2nb2: found qt5-qtx11extras-5.12.2

これでビルド出来るかと思いきや、なにやらエラーが出てしまいました。

[  5%] Built target keepassxcbrowser_autogen
[  5%] Building CXX object src/browser/CMakeFiles/keepassxcbrowser.dir/NativeMessagingBase.cpp.o
In file included from /usr/include/stddef.h:37:0,
                 from /usr/include/g++/cstddef:50,
                 from /usr/pkg/qt5/include/QtCore/qglobal.h:46,
                 from /usr/pkg/qt5/include/QtCore/qatomic.h:41,
                 from /usr/pkg/qt5/include/QtCore/QAtomicInteger:1,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.h:22,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:19:
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp: In member function 'void NativeMessagingBase::newNativeMessage()':
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:65:5: error: invalid static_cast from type 'std::nullptr_t' to type 'intptr_t {aka int}'
     EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);
     ^
*** Error code 1

Stop.
make[2]: stopped in /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
*** Error code 1

なかなか一筋縄ではいきません。この問題を解決する方法を探ってみます。

KeePassXCの拡張機能「ブラウザー統合」が無効

dynabook SS SX/15AにNetBSD/i386を入れ、MATEデスクトップ環境を利用しています。パスワードを管理するために、以前はKeePassを使おうとしていましたが不安定（すぐに落ちてコアを吐く）だし、pkgsrcにあるソースからビルドしようとしても、依存関係にあるMonoがビルド出来なかったりで、散々でした。KeePassを使い出した頃は選択肢が他になかったのですが、今ではKeePassXCがpkgsrcに入っているので、こちらを使用することにしました。

KeePassXCはブラウザ側にアドオンを入れることで連携できるようになるそうです。連携できると何か便利になるのか、それとも無くても構わないものなのか、体験してみないことには判断できません。ブラウザにはFirefoxを使っているので、アドオン「KeePassXC-Browser」を入れて、どんなものなのか動作を確認してみようとしました。ブラウザ側のアドオンを使うには、KeePassXC側の設定「ブラウザー統合」で利用するブラウザを選んでおく必要があるそうです。そこでKeePassXCの設定画面を開いたのですが、「ブラウザー統合」という項目がありません。

Webで情報をあつめてみても、「ブラウザー統合」 という設定項目は存在しているもののようです。事前に何かの設定を有効しておく必要があるとか、前準備が要るというものではないようです。しかしNetBSD/i386のpkgsrc 2019Q1にあるKeePassXCには「ブラウザー統合」がありません。どういうことでしょう？

この現象が起きているのは、僕のマシンが不良なのか、NetBSDの問題なのか、KeePassXCの特定のバージョンに起因する障害なのか、原因を絞り込まなければなりません。Webを検索して直ちに解決策が見いだせれば良いのですが、「ブラウザー統合がメニューに出てこないのは何故？」というような質問をしている人は見つかりませんでした。

NetBSDでMATEデスクトップ環境を利用する上で、何かの調査に役立つかと思って、Microsoft WIndows10上のVirtualBoxでUbuntu MATEの環境を作ってありました。ここにKeePassXCを入れてみて、NetBSDとの違いを確認してみます。すると驚いたことに、設定画面には「ブラウザー統合」が最初からありました。やはり存在するのが当たり前ということなのでしょう。

UbuntuのKeePassXCには設定「ブラウザー統合」があり、NetBSDのKeePassXCには設定「ブラウザー統合」がありません。その事実は確認できましたが、もっと情報を集められないでしょうか。KeePassXCのメニューの中に「デバッグ情報」という画面がありました。

まずNetBSDでは以下にようになっています。

KeePassXC - Version 2.4.0

Libraries:
- Qt 5.12.2
- libgcrypt 1.8.4

Operation system: NetBSD 8.99.43
CPU architecture: i386
Kernel: netbsd 8.99.43

Enabled extensions:
- Auto-Type

次にUbuntuでは以下のようでした。

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.9.5
Debugging mode is disabled.

Operation System: Ubuntu 18.04.2 LTS
CPU architecutre: i386
Kernel: linux 4.18.0-15-generic

Enabled extension:
- Auto-Type
- ブラウザー統合
- SSHエージェント
- KeeShare (signed and unsigned sharing)
- YubiKey

Cryptographi libraries:
libgcrypt 1.8.1

どうやら拡張機能「ブラウザー統合」が利用できない状態になっているようです。それは確認できましたが、なぜ利用できないのか、その原因は不明のままです。NetBSDにある共有ライブラリの何かに問題があるのかもしれませんし、拡張機能「ブラウザー統合」が利用できるのはLinuxとかWindowsなどに限定されているのかもしれません。

GitHubにあるKeePassXCの「Build and Install KeePassXC」を見ると、衝撃的な記述がありました。

cmake accepts the following options:

-DWITH_XC_AUTOTYPE=[ON|OFF] Enable/Disable Auto-Type (default: ON)
-DWITH_XC_YUBIKEY=[ON|OFF] Enable/Disable YubiKey HMAC-SHA1 authentication support (default: OFF)
-DWITH_XC_BROWSER=[ON|OFF] Enable/Disable KeePassXC-Browser extension support (default: OFF)
-DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
-DWITH_XC_SSHAGENT=[ON|OFF] Enable/Disable SSHAgent support (default: OFF)
-DWITH_XC_TOUCHID=[ON|OFF] (macOS Only) Enable/Disable Touch ID unlock (default:OFF)
-DWITH_XC_FDOSECRETS=[ON|OFF] (Linux Only) Enable/Disable Freedesktop.org Secrets Service support (default:OFF)
-DWITH_XC_KEESHARE=[ON|OFF] Enable/Disable KeeShare group synchronization extension (default: OFF)
-DWITH_XC_KEESHARE_SECURE=[ON|OFF] Enable/Disable KeeShare signed containers, requires libquazip5 (default: OFF)
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)

拡張機能「ブラウザー統合」を利用するためにはビルド時に「-DWITH_XC_BROWSER」を指定しなければなりませんが、デフォルトは「OFF」なので、あえて指定してビルドしない限り「ブラウザー統合」が無効になっているKeePassXCが出来上がってしまうのです。

pkginが拾ってくる2019Q1の出来合いのバイナリは、拡張機能が無効になったままでビルドされたのでしょう。デフォルトが「ON」になっている拡張機能は「Auto-Type」だけのようですから、上述したデバッグ情報に出ているものと一致します。

ここまで確認したところで、pkgsrc「security/keepassxc」をビルドさせてみました。コンパイルが始まる前の環境設定情報収集フェーズのログを見ると、案の定、ほとんどの拡張機能が無効になったままでした。

-- Enabled features:
 * Auto-Type, Automatic password typing

-- Disabled features:
 * Networking, Compile KeePassXC with network access code (e.g. for downloading website icons)
 * KeePassXC-Browser, Browser integration with KeePassXC-Browser
 * SSHAgent, SSH agent integration compatible with KeeAgent
 * KeeShare, Sharing integration with KeeShare
 * KeeShare-Secure, Sharing integration with KeeShare with secure sources
 * YubiKey, YubiKey HMAC-SHA1 challenge-response

-- Configuring done
-- Generating done
-- Build files have been written to: /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
=> Rewrite cmake Dependencies files
===> Building for keepassxc-2.4.0

これで原因が判明しました。pkgsrcをビルドすると、拡張機能「ブラウザー統合」が無効になったKeePassXCが出来てしまうのです。これを有効にしたければ、pkginなどで出来合いのバイナリパッケージを利用しては駄目だということです。自分でソースからビルドさせる必要があるでしょう。

/usr/pkg/qt5/lib/libQt5XcbQpa.so.5: Undefined PLT symbol "FT_Get_Font_Format" (symnum = 407)

dynabook SS SX/15AにNetBSD/i386を入れて利用しています。先月以来アプリケーションを更新するために四苦八苦してきましたが、ようやく落ち着いてき（たと思ってい）ました。

元々このマシンはMicrosoft Windows Vistaがインストールされていました。OSをNetBSDにしましたが、使い勝手を同等にしようと考えていたので、その意図を満たせるアプリケーションを入れていました。そのひとつがKeePassです。Microsoft WindowsではIDMを使っていましたので、代替ソフトとしてKeePassを選んでみました。KeePass以外にも、KeePassXやKeePassXCがあることを承知していますが、IDMの代替ソフトを探していた当時はpkgsrcにKeePassXCが入っていませんでした。KeePassXは機能的に満足せず、消去法でKeePassを選択しました。

KeePassはC#で書かれているそうです。NetBSDではMonoという実装を使っており、あまり具合が良くありません。特に問題なのが、pkgsrcからのビルドでトラブルを起こすことです。また実行中におちたりしますが、これはMonoが悪いのか、マシンの環境の何かの不具合なのか見極められていません。KeePass自体は悪くないと思うのですが、Monoにはうんざりしていました。ありがたいことにpkgsrcにはKeePassXCが入っているので、KeePassからKeePassXCに乗り換えることにしました。

KeePassXCを起動しようとしたら、次のようなエラーが出て動きません。調査しようと思って先延ばしにしていましたが、実は同じエラーがwiresharkでも出ていました。

/usr/pkg/qt5/lib/libQt5XcbQpa.so.5: Undefined PLT symbol "FT_Get_Font_Format" (symnum = 407)

この問題を解決しようとWebに情報を求めましたが、解決に至るような情報を見つけられませんでした。念のために、いつものように、/usr/bin/lddで共有ライブラリの参照状況を確認してみましたが、参照不能はありませんでした。しかし参照状況が怪しいものが見つかりました。freetype.17を参照しようとしてlibfreetype.so.18を見にいっています。

-lfreetype.17 => /usr/X11R7/lib/libfreetype.so.18

libfreetype.soは/usr/X11R7/libにあるので確認してみました。するとlibfreetype.so.18のリンク先がlibfreetype.so.17.4.11になっています。

lrwxr-xr-x  1 root  wheel      22 May 23  2016 /usr/X11R7/lib/libfreetype.so -> libfreetype.so.17.4.11
lrwxr-xr-x  1 root  wheel      22 May 23  2016 /usr/X11R7/lib/libfreetype.so.17 -> libfreetype.so.17.4.11
-r--r--r--  1 root  wheel  589796 May 23  2016 /usr/X11R7/lib/libfreetype.so.17.4.11
lrwxrwxr-x  1 root  wheel      22 Jul  7 14:34 /usr/X11R7/lib/libfreetype.so.18 -> libfreetype.so.17.4.11

このシンボリックリンクは、何時頃のことなのか記憶に定かではありませんが、自分で作りました。何かのアプリケーションがlibfreetype.so.18を必要としており、このようにリンクを張ったら動作したので、それで解決したと思っていました。それが今頃になって悪さをしているようです。

それでは本物のlibfreetype.so.18は何処にあるのでしょうか。調べてみるとNetBSD 8.0が提供するxbase.tgzに含まれているようです。考えてみると、このマシンにNetBSDを導入した時はNetBSD 7.0.1でした。その時はlibfreetype.so.17だったのでしょう。その後にソースからビルドしたNetBSD 8.99系に更新しましたが、X関係は手付かずのままだったようです。

障害の原因は見えてきたので、NetBSD 8.0に含まれているX関係コンポーネントを全て入れることで、NetBSD 7.0.1時代のX関係コンポーネントを上書きしました。これでkeepassxcが動くことを確認しました（wiresharkも）。

lrwxr-xr-x  1 root  wheel       22 Jul 17  2018 /usr/X11R7/lib/libfreetype.so -> libfreetype.so.18.0.13
lrwxr-xr-x  1 root  wheel       22 May 23  2016 /usr/X11R7/lib/libfreetype.so.17 -> libfreetype.so.17.4.11
-r--r--r--  1 root  wheel   589796 May 23  2016 /usr/X11R7/lib/libfreetype.so.17.4.11
lrwxr-xr-x  1 root  wheel       22 Jul 17  2018 /usr/X11R7/lib/libfreetype.so.18 -> libfreetype.so.18.0.13
-r--r--r--  1 root  wheel   613332 Jul 17  2018 /usr/X11R7/lib/libfreetype.so.18.0.13

これまでNetBSDの更新は/usr/srcでビルドして入れ換えていましたが、/usr/xsrcは何もしていませんでした。X関係を更新するのがNetBSDのメジャー番号が上がった場合だけで良いなら、今回同様にキットから展開すればよいでしょう。それともソースからビルドして入れ換える必要があるのか、調べておきたいと思います。

共有ライブラリの参照状況を確認

dynabook SS SX/15AにNetBSD/i386を入れ、アプリケーションはpkgsrcから入れています。もう1年以上もアプリケーションを更新していなかったので、6月上旬にpkgsrcをCVSでカレントの最新にしてpkg_rolling-replaceで作りなおし始めました。しかし導入済みのアプリケーションが多く、もとより数日で終わるとは思っていませんでしたが、ディスクが溢れたり、毎晩カーネルが落ちて日中の作業が無駄になったりして、6月下旬になっても全更新作業が終わりませんでした。

このままでは何時になったら全更新が完了するのか不安になってきたので、ソースから自前でビルドｓるのを止めて、pkginを使って出来合いのバイナリ（2019Q1のpkgsrcからビルドされたもの）をインストールして済ませることにしました。流石にバイナリを入れるだけなので、ソースからビルドするのに比べると圧倒的に速く全更新が完了しました。

しかしpkgsrcのカレントからビルドしたパッケージと、2019Q1のpkgsrcからビルドされたパッケージが混在し、共有ライブラリの参照に不整合が生じてしまいました。不整合に気づくたびに対処していく事で、復旧できるのは確かですが、全体的に不整合が残っているのか解消したのか、判断できず不安が残ります。なんとかしたいので、対処してみました。

実現方法の詳細はともかくとして、やろうとすることは単純です。すなわち/usr/bin/lddで検査して異常がないことを確認するだけです。例えば以下に示す例ではlibclang.so.7が見つからずに「not found」となっています。参照できない状態がなければ問題ないと判断します。

/usr/pkg/qt5/bin/qdoc:
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.2 => /usr/lib/libelf.so.2
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lclang.7 => not found
        -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5
        -lz.1 => /usr/lib/libz.so.1
        -licui18n.63 => /usr/pkg/lib/libicui18n.so.63
        -licuuc.63 => /usr/pkg/lib/libicuuc.so.63
        -licudata.63 => /usr/pkg/lib/libicudata.so.63
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lstdc++.8 => /usr/lib/libstdc++.so.8
        -lm.0 => /usr/lib/libm.so.0
        -lpcre2-16.0 => /usr/pkg/lib/libpcre2-16.so.0
        -lgthread-2.0.0 => /usr/pkg/lib/libgthread-2.0.so.0
        -lglib-2.0.0 => /usr/pkg/lib/libglib-2.0.so.0
        -lpcre.1 => /usr/pkg/lib/libpcre.so.1
        -lintl.1 => /usr/lib/libintl.so.1

/usr/bin/lddの出力から「not found」を見つけるために、簡単なawkスクリプトを準備しました。文字列を検索するだけならgrepでも出来ますが、見つかった文字列の属しているファイル（この例であれば/usr/pkg/qt5/bin/gdoc）が何なのか記録できません。awkスクリプトは次のようなもので、単独のコマンドとして使えるように、実行ビットを立てておきます。

#!/usr/bin/awk -f
/:$/ {
        filename = $0;
}
/not found/ {
        print filename, $0;
}
# [EOF]

共有ライブラリの参照に問題があるのは、動的リンクされた実行ファイルや共有ライブラリだけです。静的リンクされた実行ファイルとかテキストファイルなどは検証する必要がありません。当初は検証対象を限定しようと思っていたのですが、対象ファイルを見つける方法を考えるのが面倒になってきたので、強引ですが、マシン内の全てのファイルを対象とすることにしました。処理に無駄が出ますが、単純な処理で済みますし、結果をファイルに落としておいて最終的に確認すれば良いだけのことです。結局2時間ほどで全ファイルの検証が終わりました。

この検証をおこなったコマンドは以下の通りです。上述したawkスクリプトは「notfound.awk」というコマンドにしています。

find / -type f | sed -e 's/^/ldd "/' -e 's/$/"/' | sh 2>&1 | notfound.awk > notfound.log

findで対象を見つけた場合には、xargsでコマンドに渡すのが定番です。しかしsedとshを組み合わせてコマンドを動かしています。当初はxargsを使おうと思っていたのですが、Microsoft Windows由来のファイルがあり、ファイル名の中に空白文字が含まれるため、findとxargsの組み合わせでは、処理できなかったのです。

結果を記録されたファイルには、予想していたよりも相当多いファイル名が記録されていました。しかし/usr/pkg/optや/usr/pkg/emul/linuxなどにあるLinux版ファイルが大多数を占めており、本当に問題があったのは数ファイルだけでした。それらは対処したので、不整合の問題は解決した（それ以外に起因する問題は残りますが）と思います。

2019Q1のpkgsrcにあるmail/thunderbirdがビルド出来なかった

dynabook SS SX/15AにNetBSD/i386を入れて利用しています。2019Q1のpkgsrcからアプリケーションを入れていますが、firefoxやthunderbirdが見当たりません。見当たらなければ自前でビルドすれば良いのですが、このマシンでビルドするのは躊躇します（トラブルを抱えているので）。そこでWindows10のデスクトップPCに入れてあるVirtualBoxでNetBSD/i386の環境を用意して、そこでビルドさせ、出来上がったパッケージをdynabookにインストールさせることにしようと思います。

時間はかかりましたが、firefoxはビルド完了しました。つぎにthunderbirdをビルドしようとしたら、途中でエラーになります。ビルドを行っているVirutalBoxでのNetBSD/i386環境は、このビルドのために新規に準備したので、何かに使っていたものを流用した訳ではありません。何か悪さをするような設定が紛れ込んでいるとも思えません。

何かする度に、いちいちトラブルが起きると、正直なところブルーになります。しかしあまり目くじらを立てず、回避策を探りながら、前に進んでいこうと思います。今回のthunderbirdのトラブルであれば、pkgsrcに入っているmail/thunderbirdのビルドを諦め、mail/thunderbird52にしておくつもりです。将来的にビルド出来るようになった時点で入れ換えれば良いでしょう。

ちなみにエラーは以下のようになりました。rustでコンパイルしていてエラーが出たようですが、どこに問題があるのか、よく分かりません。

gmake[3]: Entering directory '/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/rust'
force-cargo-library-build
env   RUSTFLAGS='-C opt-level=2 -C debuginfo=2 '  CARGO_TARGET_DIR=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library RUSTC=/usr/pkg/bin/rustc MOZ_SRC=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0 MOZ_DIST=/usr/pkgsrc/mail/thunderbird/work/build/dist LIBCLANG_PATH="/usr/pkg/lib" CLANG_PATH="/usr/pkg/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/usr/pkgsrc/mail/thunderbird/work/build  MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,-R/usr/pkg/lib/thunderbird -L/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib/nspr -Wl,-R/usr/pkg/lib/nspr -L/usr/pkg/lib/nss -Wl,-R/usr/pkg/lib/nss -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -L/usr/pkg/lib/ffmpeg3 -Wl,-R/usr/pkg/lib/ffmpeg3 -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id -Wl,-rpath-link,/usr/pkgsrc/mail/thunderbird/work/build/dist/bin -Wl,-rpath-link,/usr/pkg/lib" MOZ_CARGO_WRAP_LD=" /usr/pkgsrc/mail/thunderbird/work/.cwrapper/bin/gcc" CARGO_TARGET_I686_UNKNOWN_NETBSD_LINKER=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/build/cargo-linker /usr/pkg/bin/cargo rustc  --release --frozen --manifest-path /usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/toolkit/library/rust/Cargo.toml --lib --target=i686-unknown-netbsd --features "servo bindgen no-static-ideograph-encoder-tables" --  -C lto
   Compiling style v0.0.1 (/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/servo/components/style)
*SNIP*
error: Could not compile `style`.

Caused by:
  process didn't exit successfully: `/usr/pkg/bin/rustc --crate-name style servo/components/style/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=2 -C panic=abort -C codegen-units=1 --cfg 'feature="bindgen"' --cfg 'feature="fallible"' --cfg 'feature="gecko"' --cfg 'feature="nsstring"' --cfg 'feature="num_cpus"' --cfg 'feature="regex"' --cfg 'feature="style_traits"' --cfg 'feature="toml"' --cfg 'feature="use_bindgen"' -C metadata=3dd65ce82fc4dde6 -C extra-filename=-3dd65ce82fc4dde6 --out-dir /usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps --target i686-unknown-netbsd -C linker=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/build/cargo-linker -L dependency=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps -L dependency=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps --extern app_units=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libapp_units-da574cb12c28d9cd.rlib --extern arrayvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libarrayvec-3f0ae2a1cbb8b928.rlib --extern atomic_refcell=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libatomic_refcell-2c02c83fd56d72be.rlib --extern bitflags=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libbitflags-e30e2e63b9a0396a.rlib --extern byteorder=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libbyteorder-d963b5ade0afeea3.rlib --extern cfg_if=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libcfg_if-f04f8382a089c533.rlib --extern cssparser=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libcssparser-1d1d460599be87ea.rlib --extern debug_unreachable=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libdebug_unreachable-9c6bb40bc842974f.rlib --extern euclid=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libeuclid-c4447169ee09badf.rlib --extern fallible=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libfallible-ec595b9f4d32a4fa.rlib --extern fnv=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libfnv-3f989a49edc433f0.rlib --extern hashglobe=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libhashglobe-c285347a04132acc.rlib --extern itertools=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libitertools-8eb8b117a5b27f08.rlib --extern itoa=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libitoa-ac44e7b9828c2cfe.rlib --extern lazy_static=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/liblazy_static-4c69850d0fd93cdd.rlib --extern log=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/liblog-e1d7af40a5fcd3a1.rlib --extern malloc_size_of=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libmalloc_size_of-a638ddfd05e3ac38.rlib --extern malloc_size_of_derive=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps/libmalloc_size_of_derive-8090b337720cdb8a.so --extern matches=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libmatches-dc9cee8466d7a354.rlib --extern nsstring=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnsstring-7d9f06a91bb14003.rlib --extern num_integer=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_integer-f7fbda8d8f37adfe.rlib --extern num_traits=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_traits-1fce81085741a140.rlib --extern num_cpus=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_cpus-7f75b9b0a3e8cea3.rlib --extern ordered_float=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libordered_float-72bb28fb42dd7eac.rlib --extern owning_ref=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libowning_ref-191d7e2d9d89ed5f.rlib --extern parking_lot=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libparking_lot-f9ca691333475cf8.rlib --extern precomputed_hash=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libprecomputed_hash-b1f62c54e141bc6c.rlib --extern rayon=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/librayon-f0328a9a16dbfb4e.rlib --extern selectors=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libselectors-b3f6cbe84f95a451.rlib --extern servo_arc=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libservo_arc-b5bf77ee0d81f7da.rlib --extern smallbitvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libsmallbitvec-1ef4cf7dd3ee1cfc.rlib --extern smallvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libsmallvec-987ea7aad8e4fd03.rlib --extern style_derive=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps/libstyle_derive-f921523a66ebcc9e.so --extern style_traits=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libstyle_traits-731f77275c5dc178.rlib --extern time=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libtime-42d9c60476bf39e7.rlib --extern uluru=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libuluru-b831f88c4c673a8c.rlib --extern unicode_bidi=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libunicode_bidi-797219c7deb9a8f1.rlib --extern unicode_segmentation=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libunicode_segmentation-ff9ac4948ee07429.rlib --extern void=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libvoid-c7677eeb3cc69e94.rlib -C opt-level=2 -C debuginfo=2` (signal: 9, SIGKILL: kill)
gmake[3]: *** [/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/config/rules.mk:979: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/rust'

openSUSE 13.1は未だに入手可能と理解しても良い？

NetBSDのpkgsrcにあるLinuxエミュレーション環境では、openSUSE 13.1が（未だに）使われています。このバージョンは「2016年2月3日にサポートを終了している」と公式にアナウンスされており、ISOイメージが入手できなくなっています。

しかし過去のバージョンを入手したいと希望する声は少なくないようで、openSUSEの公式サイトにあるフォーラムで「Is it necessary openssl-devel RPM for OpenSuSE 12.3 ?」と問い合わせているのが確認できます。その回答の中で、「ftp5.gwdg.de」というサイトを紹介しているものがあります。

gwdg.deというのはドイツのサイトだと思いますが、openSUSEのミラーのリストにも出てくるサイトです。ここにはopenSUSE 13.1のISOイメージも置いてあります。これを入手しておけば、openSUSE 13.1の環境を準備することは可能です。

ただし気になるのは、過去のバージョンを保持しているのが、何故このサイトだけ（のように思われる）なのかという事です。また将来に亘って入手可能と考えておいて良いのかということも気になります。

NetBSDのエミュレーション環境でLinux版firefox 67.0.4は動かなかった

dynabook SS SX/15AにNetBSD/i386を入れ、MATEデスクトップ環境を利用しています。使用しているアプリケーションはpkgsrcから入れました。もう1年以上も更新していなかったので、6月上旬にpkg_rolling-replaceを使って全更新をおこなおうと試みたのですが、いろいろなトラブルに見舞われ環境が崩壊してしまいました。pkg_rolling-replaceは諦めてpkginで何とか全更新を仕上げましたが、まだ崩壊前と同等になったとは言えません。

最優先で復活させたいのがfirefoxです。

pkgin search firefoxで確認すると、firefox 66.0.1の言語パックがあるのに、本体が存在しないという不思議な状態になっています。

• firefox-l10n-66.0.1  Language packs for www/firefox (version 66)
• firefox36-l10n-3.6.28  Language packs for www/firefox36 (version 3.6.x)
• firefox45-45.9.0nb18  Web browser with support for extensions (version 45)
• firefox45-l10n-45.9.0  Language packs for www/firefox (version 45)
• firefox52-52.9.0nb12  Web browser with support for extensions (version 52)
• firefox52-l10n-52.9.0  Language packs for www/firefox (version 52)
• firefox60-l10n-60.6.1  Language packs for www/firefox60 (version 60)

pkgsrcから自前でビルドすれば良いのかもしれませんが、どうも面白くありません。例えばLibreOfficeはLinux用のRPMを展開しただけ（+α）ですから、Firefoxも同じように出来ないのでしょうか。Mozillaのサイトに行けば、Linuxのディストリビューションとは無関係のバイナリが置いてあります。これを、NetBSDのLinuxエミュレーション環境で動かせることが出来れば、文句なしです。

そこで実験してみました。LibreOffice6が導入済みなので、Linuxエミュレーション環境も出来ています。openSUSE 13.1相当というのが旧いとは思いますが、仕方ありません。Mozillaのサイトから拾ってきた「firefox-67.0.4.tar.bz2」を/usr/pkg/optに展開しました。展開するとfirefoxというディレクトリができますが、firefox-67.0.4に変えておきました。

 ここで共有ライブラリの参照状況を確認してみます。

# /usr/pkg/emul/linux/usr/bin/ldd  /usr/pkg/opt/firefox-67.0.4/firefox
        libpthread.so.0 => /lib/libpthread.so.0 (0xbbab9000)
        libdl.so.2 => /lib/libdl.so.2 (0xbbab4000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xbb9c7000)
        libm.so.6 => /lib/libm.so.6 (0xbb982000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbb965000)
        libc.so.6 => /lib/libc.so.6 (0xbb7ee000)
        /lib/ld-linux.so.2 (0xbbadd000)

not foundが出ていないので、もしかしたら動作するかと思いましたが、動かしてみると不足している共有ライブラリがあるようです。メッセージに出てきたら、RPMを追加し、また動かしてみるという作業を続けました。その結果、以下のRPMを追加しました。

1. libatk-bridge-2_0-0-2.12.1-2.5.i586.rpm
2. libatomic1-4.8.1_20130909-3.2.1.i586.rpm
3. libatspi0-2.12.0-2.5.i586.rpm
4. libcairo-gobject2-1.15.2-3.2.i586.rpm
5. libgtk-3-0-3.12.2-1.110.i586.rpm

この状態でfirefoxを動かしてみると、動かない訳ではないのですが、まだ何か問題があるようです。

# /usr/pkg/opt/firefox-67.0.4/firefox --version
Mozilla Firefox 67.0.4
# /usr/pkg/opt/firefox-67.0.4/firefox --help
Usage: /usr/pkg/opt/firefox-67.0.4/firefox [ options ... ] [URL]
       where options include:

X11 options
  --display=DISPLAY  X display to use
  --sync             Make X calls synchronous
  --g-fatal-warnings Make all warnings fatal

Firefox options
  -h or --help       Print this message.
  -v or --version    Print Firefox version.
  -P <profile>       Start with <profile>.
  --profile <path>   Start with profile at <path>.
  --migration        Start with migration wizard.
  --ProfileManager   Start with ProfileManager.
  --no-remote        Do not accept or send remote commands; implies
                     --new-instance.
  --new-instance     Open new instance, not a new window in running instance.
  --UILocale <locale> Start with <locale> resources as UI Locale.
  --safe-mode        Disables extensions and themes for this session.
  --allow-downgrade  Allows downgrading a profile.
  -MOZ_LOG=<modules> Treated as MOZ_LOG=<modules> environment variable, overrides it.
  -MOZ_LOG_FILE=<file> Treated as MOZ_LOG_FILE=<file> environment variable, overrides it.
                     If MOZ_LOG_FILE is not specified as an argument or as an environment variable,
                     logging will be written to stdout.
  --headless         Run without a GUI.
  --save-recordings  Save recordings for all content processes to a directory.
ExceptionHandler::GenerateDump cloned child ExceptionHandler::WaitForContinueSignal waiting for continue signal...
2288
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
[ 6100.7246708] sorry, pid 2122 was killed: orphaned traced process
[1]   Killed                  /usr/pkg/opt/firefox-67.0.4/firefox --help

あと一歩という感じなので、なんとか解決させたいところです。しかし、あと一歩だと思って調査を続けていったら、ゴールは無限の彼方という可能性もないわけではありません。ここは一端撤退しようかと思います。