gitリポジトリの引越
久々に osdn にアクセスしたところ、レスポンスが帰って来ない…正確には全くアクセスできないわけではないのだが、かなり重い。殆ど使えない状態になってた。
504 Gateway Time-out
が大量発生する。調べてみたところ、最近、売却されて、それ以降、接続しにくい状態が続いているようだ。こんな状態では、何時、アクセスできなくなるかもしれないので、引越を行なう事にした。Wiki等の引越は諦めるとして、リポジトリだけは引っ越したい。
幸いにして、gitからリポジトリのアクセスはできるようなので、早めに引っ越す事にした。引越先は github にしました。
以下、手順です(リポジトリは架空です)。
- 移行元 :: https://pf.osdn.net/gitroot/t/ta/taratara/hogehoge.git
- 移行先 :: https://github.com/taratara/hogehoge.git
移行元のリポジトリを --mirror オプションで clone します。
$ git clone --mirror https://pf.osdn.net/gitroot/t/ta/taratara/hogehoge.git Cloning into bare repository 'hogehoge.git'... remote: Counting objects: 285, done. remote: Compressing objects: 100% (166/166), done. remote: Total 285 (delta 119), reused 268 (delta 111) Receiving objects: 100% (285/285), 73.18 KiB | 663.00 KiB/s, done. Resolving deltas: 100% (119/119), done.
cloneしたディレクトリに移動します。
$ cd hogehoge.git/
移行先のリポジトリへ --mirror オプションでプッシュします。
git push --mirror https://github.com/taratara/hogehoge.git Enumerating objects: 285, done. Counting objects: 100% (285/285), done. Compressing objects: 100% (158/158), done. Writing objects: 100% (285/285), 73.18 KiB | 18.30 MiB/s, done. Total 285 (delta 119), reused 285 (delta 119), pack-reused 0 remote: Resolving deltas: 100% (119/119), done. To https://github.com/taratara/hogehoge.git * [new branch] master -> master * [new tag] convert-from-cvs -> convert-from-cvs * [new tag] r-hogehoge -> r-hogehoge ! [remote rejected] main (refusing to delete the current branch: refs/heads/main) error: failed to push some refs to 'https://github.com/taratara/hogehoge.git'
ところがエラー発生。
デフォルトのブランチ名が一致していないのが原因です。github のデフォルトのブランチ名が master から main に変更になっているが原因です。
移行先のデフォルトブランチ名を main から master に変更してから再度実行したところ問題なく移行できました。
$ git push --mirror https://github.com/taratara/hogehoge.git Enumerating objects: 248, done. Counting objects: 100% (248/248), done. Compressing objects: 100% (110/110), done. Writing objects: 100% (212/212), 39.57 KiB | 4.95 MiB/s, done. Total 212 (delta 114), reused 198 (delta 100), pack-reused 0 remote: Resolving deltas: 100% (114/114), completed with 19 local objects. To https://github.com/taratara/hogehoge.git + 8eab0a8...8392bbb master -> master (forced update)
勿論、ブランチ名を指定して push する方法もあるんですけどね。
-
- -
上記は github側で git init でリポジトリの初期化を行なってしまった為にデフォルトのブランチが作成されてしまい、ブランチ名が一致しない事により、エラーになってしまったが、github側でリポジトリの初期化を行なわなければ問題なく移行できる。
この状態であれば、そのままエラーが発生する事なく引越が完了します。
git push --mirror https://github.com/tarancho/jbanner.git
Enumerating objects: 50, done. Counting objects: 100% (50/50), done. Delta compression using up to 2 threads Compressing objects: 100% (46/46), done. Writing objects: 100% (50/50), 43.08 KiB | 689.00 KiB/s, done. Total 50 (delta 17), reused 0 (delta 0) remote: Resolving deltas: 100% (17/17), done. To https://github.com/tarancho/jbanner.git * [new branch] master -> master * [new tag] Version-1.0 -> Version-1.0 * [new tag] convert-from-cvs -> convert-from-cvs * [new tag] release -> release
次に既存の編集中の clone したリポジトリが存在している場合は、リモートURLを更新します。
現在のURLを確認します。
git remote -v
origin tarancho@git.pf.sourceforge.jp:/gitroot/t/ta/tarancho/jbanner.git (fetch) origin tarancho@git.pf.sourceforge.jp:/gitroot/t/ta/tarancho/jbanner.git (push)
URLを移行先に変更します。
git remote set-url origin https://github.com/tarancho/jbanner.git
URLを確認します。
git remote -v
origin https://github.com/tarancho/jbanner.git (fetch) origin https://github.com/tarancho/jbanner.git (push)
新しいリモートリポジトリと同期します。
git pull
remote: Enumerating objects: 21, done. remote: Counting objects: 100% (21/21), done. remote: Compressing objects: 100% (11/11), done. remote: Total 11 (delta 7), reused 4 (delta 0), pack-reused 0 Unpacking objects: 100% (11/11), done.
Emacs27で Org-mode の <e TAB が効かない…
Emacs27のOrg-modeでファイルを編集中に
<e
と入力して TAB キーを押しても反応がない…
<q <s
qの後もsの後も反応がない…
Emacs26の時は
#+BEGIN_EXAMPLE #+END_EXAMPLE #+BEGIN_QUOTE #+END_QUOTE #+BEGIN_SRC #+END_SRC
と補完してくれたのに…
調べてみたところ、既定では、org-tempo が有効になっていないという事のようです。
qiita.com
設定方法は上記のリンクに詳しく書いていました。大変助かりました。
為念、自分の備忘録の為に手順を残しておきます。
M-x customize-option
コマンドを org-modules を引数に実行します。すると、以下のような設定画面になります。
tempo をチェック状態にして、"Apply and Save" で init.el に保存されました。
10年振りにノートPCを購入したのでLubuntu22.04をインストール
2022年の年末は諸般の事情により自粛生活になってしまったので10年振りにノートPCを購入してセットアップする事にした。
因に10年前に購入したノートPCにインストールしているOSはLubuntu12.04だった。
この古いPCは1万円で購入した記憶が残っている。たしか、メモリは1Gだったと記憶していたのだが、実際に確認してみたら512Mだったようだ。
このスペックでデスクトップOSが動いていた事に驚きでした。
因にこのPCは 2004年に発売された Latitude D505 です。18年前って事ですね。
ascii.jp
今回購入したPCと古いPCを並べてみたら、旧PCの大きさと重さに吃驚しました。特に重さに…
因に今回購入したPCも1万円台で中古で購入しました。OSはWindows 10がインストールされていましたが、Lubuntu 22.04に書換えます。
そんなわけでインストールの前準備
今回購入したPCにはLubuntu 22.04 をインストールする事にします。ライブCDからインストールする方法が最も簡単なのかもしれませんが、大容量の媒体を持っていないのとminimalでインストールしたいので、Ubuntu serverのNetbootイメージからminimalインストールをしてLubuntu Desktopを追加インストールする方法をとりたいと思います。因に私は基本的に設定はCUIで行なえれば問題ない人なので、GUIでの設定は必ずしも必須ではありません。
Netbootイメージの取得
Netbootイメージは旧PCで行ないます。先ずは
cdimages.ubuntu.com
へアクセスします。
ここから 22.04LTS へ飛びます…
しかし、その先のページにはアクセスできません。ページが存在しないわけではなく、セキュリティの問題のようです。12.04ではアクセスできないようです。新しいPCのWindows 10からはアクセスできたので、とりあえず、Netbootイメージは新しいPCでダウンロードしました。
インストール媒体の作成
Netbootイメージを scp コマンドで古いPCへ転送し、インストール媒体を作成します。インストール媒体はUSBメモリを使用します。
USBメモリを挿入してlsusbコマンドで認識されているか確認します。
$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 048d:1170 Integrated Technology Express, Inc.
問題なく確認されているようです。このUSBメモリが何というデバイス名として認識されているか確認します。USBメモリを挿入する前と挿入した後で lsblk を実行して差分を確認します。
挿入前。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 18.6G 0 disk ├─sda1 8:1 0 8.9G 0 part ├─sda2 8:2 0 1K 0 part ├─sda5 8:5 0 510M 0 part ├─sda6 8:6 0 8.8G 0 part / └─sda7 8:7 0 502M 0 part [SWAP] sr0 11:0 1 1024M 0 rom
挿入後。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 18.6G 0 disk ├─sda1 8:1 0 8.9G 0 part ├─sda2 8:2 0 1K 0 part ├─sda5 8:5 0 510M 0 part ├─sda6 8:6 0 8.8G 0 part / └─sda7 8:7 0 502M 0 part [SWAP] sr0 11:0 1 1024M 0 rom sdb 8:16 1 3.8G 0 disk └─sdb1 8:17 1 128M 0 part
USBメモリのデバイス名は /dev/sdb なのが確認できます。容量は3.8Gですね。
このデバイスにダウンロードしたNetbootイメージを dd コマンドで書き込みます。
$ sudo dd bs=4M if=./ubuntu-22.04.1-live-server-amd64.iso of=/dev/sdb 351+1 レコード入力 351+1 レコード出力 1474873344 バイト (1.5 GB) コピーされました、 222.109 秒、 6.6 MB/秒
インストール
Ubuntu serverのインストール
USBメモリを新しいPCに挿入して電源を入れるだけだった。
もしかするとBIOSでブートデバイスの設定変更が必要になるかもと思っていたが、すんなりUSBからブートしてくれた。あとは画面の指示に従って入力するだけ。私の場合は
- minimal を選択
- 選択したサービスは ssh だけ
という感じでインストールを行なった。気がついたら complete していた。Enterキーを押すと「インストールメディアを抜いてEnterを押せ」みたいなメッセージが出るので、USBメモリを抜いてEnterキーを押下するとUbuntu serverが起動した。
とりあえず、sshで接続して軽く動作を確認した。
設定
全て手動でインストールしたのでロケールやタイムゾーンがローカラズされていないので手動で設定します。
ロケールの設定
現在のロケールを確認します。
$ localectl System Locale: LANG=C.UTF-8 VC Keymap: n/a X11 Layout: jp X11 Model: pc105
日本語化はしておきたいので必要な最低限のパッケージをインストールします。
sudo apt -y install language-pack-ja-base language-pack-ja
ロケールを変更します。
$ sudo localectl set-locale LANG=ja_JP.UTF-8 LANGUAGE="ja_JP:ja" $ source /etc/default/locale $ localectl System Locale: LANG=ja_JP.UTF-8 LANGUAGE=ja_JP:ja VC Keymap: n/a X11 Layout: jp X11 Model: pc105
タイムゾーンの設定
現在の時刻を確認するとUTCで表示されます。
$ date 2022年 12月 29日 木曜日 07:21:42 UTC
/etc/localtime UTCにシンボリックリンクされている事を確認。
ls -l /etc/localtime lrwxrwxrwx 1 root root 27 12月 29 04:32 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
シンボリックリンクを変更します。
$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
日本標準時になっている事を確認します。
$ date 2022年 12月 29日 木曜日 16:26:15 JST
日本語入力の設定
日本語入力は操作が慣れている skk系が良いので ibus-skk をインストールする事にした。
$ sudo apt install ibus-skk
インストール中に以下のメッセージを確認したので
debconf: apt-utilsがインストールされていないため、パッケージの設定を遅らせます。 以前に未選択のパッケージ dconf-cli を選択しています。
apt-utils も追加でインストールした。
sudo apt install apt-utils
基本的には概ね使えているのだが、何故か辞書サーバに登録されている筈の単語が変換できない。辞書サーバに接続できていないのではないかと推測した。
netcatでは辞書サーバに接続できる事を確認したので実際に ibus が接続できているか確認した。
$ sudo netstat -v -p -4 -n | grep 1178 tcp 0 0 192.168.1.142:40802 192.168.1.10:1178 ESTABLISHED 2221/nc tcp 0 0 192.168.1.142:59052 192.168.1.10:1178 ESTABLISHED 1460/ibus-engine-sk
問題なく接続できているようだ。という事は辞書サーバとインターフェースが合っていないのかもしれない。辞書サーバは随分昔から使っているからな〜
辞書サーバ側を確認したら問い合わせ回数は更新されていたので通信はできているようだ。やっぱり、インターフェースがあっていないという事のようだ。辞書サーバ側の更新が必要なようだ。
その他
teams のインストール
仕事でも使えるかもって事で teams をインストールしようとしたが、依存関係の問題でインストールできなかった。最終的には以下のページを参考にして apt でインストールできた。
learn.microsoft.com
やり残した事
2022年の年末の巣籠りで久々にLinuxのセットアップをしたのですが二つ程やりのこした事があります。
Ubuntu の console にIPアドレスを表示する(netplan)
以前、以下のような備忘録を書いた。
tarancho.hatenablog.com
この中でも書いているけど、この備忘録の手順だと今のUbuntuでは動作しない。ネットワークの設定が netplan に変更になっているからだ。手順は概ね上記の備忘録の通りなのだが、スクリプトの配置場所が違うのです。
ネットワークインターフェースがアップしたタイミングで実行されるスクリプトは
/etc/networkd-dispatcher/routable.d/
ディレクトリに配置すれば良い。今回はスクリプトの内容も少しだけ変更している。前回の手法だと、予め /etc/issu を /etc/issu.org に複写する手順としていたが、この方法だと OS の update時に /etc/issu が更新された場合、古い情報に書き戻してしまうのだ。
そんなわけで、今回は /etc/issu を直接更新する方式にスクリプトを変更している。スクリプトの内容は以下の通り。
#!/bin/sh sed -i '/^IP addresses:/d' /etc/issue echo 'IP addresses:' $(hostname -I) >> /etc/issue
勿論、ファイルに実行権限を付与するのを忘れずに。
MSR ドラゴンフライの燃料漏れ
先日久々にドラゴンフライを使用したところコントロールバルブからの燃料漏れを確認した。かなり焦ったが、使用している燃料が引火点の高い灯油なのと、滲んでいる程度だったので、そのまま使用した。2014年から使用しているが一度もメンテナンスをした事がなかったので
フューエルポンプ - MSRストーブメンテナンス| 株式会社モチヅキ
を参考にしてポンプのメンテナンスを行なう事にした。コントロールバルブのOリングの交換が必要そうだったので、同サイトから注文した。為念,チューブOリングも交換する事にした。メーカは1年での交換を推奨しているようだが、私は2014年に購入以来一度も交換した事がなかった。
Oリングが届いたので、交換する事にしたが、交換する前に燃料漏れを確認する為に圧力をかけてみた。間違いなくコントロールバルブから燃料が漏れている。
ポンププランジャー、コントロールバルブ、ブッシングを外して、コントロールバルブOリングとフューエルチューブOリングを外した。
外したOリングと新品のOリングを比較すると、コントロールバルブOリングは明らかに痩せていて内径が大きくなっているのが肉眼でも確認できた。フューエルチューブOリングは見た目には殆んど差は感じられなかった。
そしてOリングを交換してポンプを組み立てている時に明らかな変化を感じた。コントロールバルブを締める時に重さを感じたのだ。交換前はもっと軽かったのだ。これじゃ燃料漏れするわけだ…
ポンプで圧力をかけてみたが、燃料漏れは解消している事を確認できた。ちゃんとメンテナンスしておかなくてはいかんですな。
ヤマレコで自分が行った事がある山の山行記録をリストアップする
山行記録にヤマレコを使っている。山行が多くなってくると、「あれ、ここって何時行ったんだっけ？」っと思う事がある。
マイページ→山行記録の「記録検索」だと思うようにヒットしない事がある。この記録検索は文字列から山データを検索して、その後、山行記録を検索しているのだと思う。その為、同じ山の名前が複数存在している場合等は、意図した通りの検索ができない場合がある。
そんな時は私は以下の方法で自分の山行記録を検索している。
- 「山のデータ」で検索したい山を検索する
- 検索した山データの番号を控えておく(コピーしておく)。例えば富士山の場合は 63 となる。
- 以下のURLに自分のヤマレコのIDと検索したい山のデータの番号を嵌め込んでブラウザからアクセスする。
https://www.yamareco.com/modules/yamareco/search_record.php?uname=【自分のID】&request=1&ptid=【山の番号】
例えば私のアカウントで「山伏平」の山行記録を検索したい場合は、以下のURLとなる。
https://www.yamareco.com/modules/yamareco/search_record.php?uname=tarancho&request=1&ptid=14418www.yamareco.com
「ヶ」という文字
三ヶ月の「ヶ」という文字はどうやって入力するのかずっと疑問だった。もちろん「三ヶ月」の場合は「さんかげつ」と入力すれば良いのだが、「七里ヶ浜」のように「しちりがはま」で変換できない場合(環境によってはできるのでしょうが)もある。何時も片仮名の「け」で代用していたのだが、Wikipediaによると
「ヶ（ケ）」は、片仮名の「ケ」とは由来を別にし、「箇」または「个」の略字とされる。
という事で異なる文字のようなのだ。そして恥ずかしながら「か」と入力すると「ヶ」に変換できる事を知ったのはつい最近だ。
ふと「箇」の略字の「ヶ」と片仮名の「ヶ」の文字コードを調べてみようと思って調べてみた。
結果は UTF-8の場合は e383b6 で同じ文字だった。由来は違うけど、文字は同じという意味だったのか。
