ちよぶろ。: 9月 2020

録画したD-VHSテープからWindows 10環境で吸い出してみる。

注意: 現在進行中なので、結論はまだありません。

過去にD-VHSを使っていて、今でも機械だけはあるんですが HDMI ではなく D4 出力のため、AV システムとして組み込むには中途半端な状態。Bluray レコーダーも AV アンプも液晶テレビもすべて HDMI 繋がりになっていますし。

一応、手持ちの AVアンプ YAMAHA RX-V773 には D4 入力端子もあるんですが、マニュアルによれば D4 VIDEO 端子にビデオ機器を接続した場合、ビデオ機器の映像出力が 480i 以外だとアンプの MONITOR OUT （COMPONENT VIDEO）端子からのみ映像が出力されるとのことで、アナログ信号で D4 端子に入力された映像を HDMI 出力することはできないようです。

液晶テレビとして東芝 REGZA 37ZP3 を使っているんですが、こちらは D5 入力端子を持っています。D5 端子は D1 から D4 までの規格の映像信号を受け取れるはずなので、こちらに接続すれば見られないことはないはずで、その場合は光デジタル出力を D-VHS テープデッキから AV アンプに接続して音声を再生する、というスタイルになります。

ただ、テープデッキも故障対応期間はとっくに終わっていますし、データを PC に取り込んで、PC から再生したほうがいろいろと便利なので、D-VHS テープデッキである日立 DT-DRX100 の iLink 端子から PC でデータを吸い出してエンコードしてしまえば楽だな、と思った次第。

ところが最近の PC には i.LINK （IEEE1394）のインタフェースがありません。しかも手持ちの IEEE1394 カードは PCI 接続のもので、PCI Express しかない今の PC では使えません。

そこで玄人志向の「IEEE1394-PCIE2 [TI XIO2200搭載 IEEE1394a（OHCI）x2 ロープロファイル対応インターフェースボード]」というのを購入してみました。このカードを買ったのは、D-VHS との接続と同時に、フィルムスキャナ Nikon Coolscan LS-4000ED を接続して過去のネガフィルムを整理する、という目的もあるので、D-VHS に関してはダメ元的な考えでした。

一応、取り込みソフトとしてはフリーの CapDVHS というのを見つけたので、それを使ってみようかと思っています。

ちなみにフィルムスキャナのほうは、接続した段階ではドライバソフトがない、といっていきなりブルースクリーンになったりしたのですが、VueScan というアプリがドライバまで含めてサポートしているということで、 Professional Edition を購入しました。複合機の Canon MG-7730 プリンタを使っているのですが、そちらからのスキャンもできます。

ところがこの IEEE1394-PCIE2 は XIO2200 というチップを使っていて、こちらが PCIe 1.0a までの対応で、PCIe 1.1 以降には対応していない、というような記事を見かけました。実際に、 Texas Instuments の XIO2200 EVM Guide には、

The card will fit into any standard x1, x2, x4, x8, or x16 add-in connector that is compliant to the PCI Express Card Electromechanical Specification revision 1.0a.

とあります。1.0a は 1.1 の先行規格だということで、基本的に同じものという認識なのですが、玄人志向ではこれとは別に、XIO2213B （PCIe 1.1）のカードも販売していて、こちらのほうは IEEE 1394b に対応している、とのこと。Wikipediaによれば、通信速度は 800 Mbps になり端子形状も異なるということで、テープデッキもフィルムスキャナも古く、当時は 400Mbps といっていたので 1394a に対応してばいいと思いますが、XIO2200（PCIe 1.0a & IEEE1394a）のカードではフィルムスキャナの電源を切ると PC がブルースクリーンになるという不具合もあるため、XIO2213B（PCIe 1.1 & IEEE1394b）もヨドバシのポイントで用意してみました。

ただし、このブルースクリーンの原因もよくわからず、「irql not less or equal (1394ohci.sys)」と表示されるエラーで、ドライバの割り込み要求レベルが異なるというエラーですが、Microsoft の Answer を読んでもよくわかりません。それとは別に、1394 OHCI ホストドライバを "Generic 1394 OHCI compliant host controller (Legacy)" に変更すれば、Windows 10 でも古い 1394 デバイスを利用できるようになるというページもあり、そこのリンクから 64ビット版の 1394_OHCI_LegacyDriver.msi をダウンロードしてインストールすると使えるようになる、という記述もあります。

さすがにメイン PC でやるのは怖いので、検証機を仕立ててやってみようと思います。

うまく動くようなら、ビデオの取り込みを CapDVHS あるいは HDVSplit にてやってみようと思います。

latexmkrcの解説を和訳しておく。

以前に設定して使っていた latexmk がうまく動作しなくなってきていたので latexmkrc とかを見直しながら調査中。つきましては latexmk のドキュメントから "CONFIGURATION/INITIALIZATION (RC) FILES" の肝の部分を和訳しておきます。

---以下和訳

Latexmkは、起動時に以下の順番で読み込まれる初期化ファイルを使ってカスタマイズできます。

システムのRCファイル（もしあれば）
UNIXシステムでは、latexmkはシステムRCファイルを探すために、以下の場所を以下の順番で探し、最初に見つけたものを読み込みます。
"/opt/local/share/latexmk/LatexMk",
"/usr/local/share/latexmk/LatexMk",
"/usr/local/lib/latexmk/LatexMk"
MS-Windowsシステムでは、"C:\latexmk\LatexMk"を探します。
cygwinシステムでは、
"/cygdrive/c/latexmk/LatexMk",
"/opt/local/share/latexmk/LatexMk",
"/usr/local/share/latexmk/LatexMk",
"/usr/local/lib/latexmk/LatexMk"
のうち、最初に見つけたものを読み込みます。
加えて、それでも見つからない場合には"LatexMk"のファイル名を"latexmkrc"に置き換えて同じ場所を探します。
もし環境変数 LATEXMKRCSYS が設定されていれば、上記の代わりにその値がシステムRCファイル名として使用されます。
ユーザのRCファイル（もしあれば）
これは２ヶ所のうちのひとつになります。１つは伝統的なものでユーザのホームディレクトリにある ".latexmkrc" です。もうひとつは XDGコンフィギュレーションホームディレクトリにある "latexmk/latexmkrc" です。実際に読み込まれるのは "$XDG_CONFIG_HOME/latexmk/latexmkrc" または "$HOME/.latexmkrc" のうちの最初の方です。
ここで $HOME はユーザのホームディレクトリです。
$XDG_CONFIG_HOME は環境変数 XDG_CONFIG_HOMEが設定されている場合にはその値になります。もし環境変数が設定されておらず、$HOME が空でなければ、$XDG_CONFIG_HOME はデフォルト値の $HOME/.config に設定されます。$XDG_CONFIG_HOME が空の場合には、latexmk はそこには RCファイルを探しには行きません。
現在のワーキングディレクトリのRCファイル
ファイル名は "latexmkrc" または ".latexmkrc" で、もしあれば最初に見つかったほうが使用されます。
コマンドラインの -r オプションで指定されたRCファイル

RCファイルは Perl コマンドの連なりです。当然ながらユーザはこれを如何様にも利用できます。が、ほとんどの目的は Latexmk に組み込まれた設定を上書きするための代入文の連なりで使用されます。直接的なケースはPerl言語の知識がなくてもこのドキュメントの例をテンプレートとして使うことができます。#のついた行はコメント行です。

（どどーんと省略）

$pdf_mode [0]

ゼロの場合、pdf版の文書を生成しません。1の場合、pdf版の文書をpdflatexを使い、$pdflatex 変数に指定されたコマンドを使って生成します。2の場合、pdf版の文書を$ps2pdf変数で指定されたコマンドを使ってpsファイルから生成します。3の場合、$dvipdf変数で指定されたコマンドを使ってdviファイルから生成します。4の場合、pdf版の文書をlualatexを使い、$lualatex変数で指定されたコマンドを使って生成します。5の場合、pdf版の文書をxelatexを使い、$xelatexとxdvipdfmx変数で指定されたコマンドを使って生成します。

---以上

ArchLinuxのbaseパッケージでインストールされるもの。

https://www.archlinux.org/packages/core/any/base/によれば、base には bash、bzip2、findutils、gawk、grep、pacman、sed、systemd、tarなどでエディタは入っていないようです。

また、https://www.archlinux.org/groups/x86_64/base-devel/によれば、base-devel には autoconf、automake、binutils、bison、gcc、gettext、m4、patch、sudoなどが入っています。

Python や Perl などは入っていないようですね。

一方、ArchLinux の bootstrap に含まれているパッケージは /var/lib/pacman/localに情報があり、bash、curl、glibc、ncurses、pacman、pam、pcre、perl、sqliteなどがあるようです。やっぱりエディタはないようなので、自分の好きなものをインストールしないとダメみたいです。

その他にインストールしたほうがいいパッケージは、

mlocate - locate を利用する場合。sudo updatedb が必要。
man - man page を利用する場合。パッケージ名は man-db となっている。
python - Python3 を利用する場合。
zsh - bash から乗り換え。
the_silver_searcher - grep の置き換え。

あたりでしょうか。ここらへんは個人の嗜好になりますが。

それから zsh での設定ファイルの読み込み順はホームディレクトリのドットファイルを整理する。にまとめていますが、$ZDOTDIR をどこかで設定しておく必要があり、うちの場合には /etc/zsh/zshenv に

XDG_CONFIG_HOME=$HOME/.config
export ZDOTDIR=$XDG_CONFIG_HOME/.config/zsh

などとしています。

WSLにインストールしたUbuntuのディストロ名を変える。

WSL 1に Ubuntu-18.04 をインストールして中身を ArchLinux に入れ替えましたが、このままでは wsl -l -v したときに Ubuntu-18.04 と表示されます。でも中身は ArchLinux。ややこしい。

なので、中身に合わせてディストロ名を変更します。

そのまま変更することはできないようなので、ここは wsl の export / import を使います。

$ wsl --export Ubuntu-18.04 archlinux.tar

$ wsl --import ArchLinux C:\Users\chiyo\AppData\Local\Packages\ArchLinux archlinux.tar --version 1

$ wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-18.04           Stopped         1
  docker-desktop-data    Running         2
  docker-desktop         Running         2
  ArchLinux              Stopped         1

$ wsl --set-default ArchLinux

$ wsl -l -v
  NAME                   STATE           VERSION
* ArchLinux              Stopped         1
  docker-desktop-data    Running         2
  docker-desktop         Running         2
  Ubuntu-18.04           Stopped         1

$ wsl -d ArchLinux

これで一応できたみたいです。

bash で「要素が見つかりません」になる。

Win-R で bash とやったらウィンドウが一瞬開いてすぐに閉じてしまうので、コマンドプロンプトを開いて bash とやってみたら、「要素が見つかりません」というエラーが出てしまいました。

Ubuntu のアイコンから起動しても同様で、これは困ったとぐぐってみると、以下のような内容の記述を見つけました。

KB4571756をインストールするとWSL 2で「要素が見つかりません」というエラーになります。「更新とセキュリティ」からKB4571756をアンインストールすると正常に戻ります。

早速 KB4571756 をアンインストールしてみると、ちゃんと動くようになりました。何やらかしてくれちゃってんの…。

ついでにグループポリシーエディタで自動更新を無効にしておきました。

MSYS2がいらなくなると思ったのに…。

WSLにArchLinuxをインストールしてみる。で無事インストールできた ArchLinux ですが、base と base-devel しか入れてないのでエディタはないし zsh はないしであわてて pacman でインストールしたのはいいんですが……。

これで MSYS2 から開放されるな、と思って、削除する前にまず MSYS2 をインストールしたディレクトリ c:\Apps\MSYS2 の名前を変更してパスが通らないようにし、コマンドプロンプトから ls と入力してみると…動きません…。wsl.exe をかませて -e オプションで実行できるんですが、たかが ls コマンドでそれをやるのはアホらしいですし。

根本的になにか勘違いしていて、「相互にコマンドなどを利用できる」と思っていたのですがそうではなく、Linux 用コマンドなどはシェルなどから Linux カーネルを呼び出して実行されるわけなので、Linux カーネルが動いてない状態では動作するわけがないですね。

ということでかなり思惑が外れてしまいました。やっぱり MSYS2 からは開放されないのね。

WSLにArchLinuxをインストールしてみる。

apt よりも慣れ親しんだ pacman を使いたい！という理由で、ArchLinux を WSL にインストールしてみます。WSL 2 までのインストールが終わっているということを前提条件とします。方針としては Ubuntu をインストールしてから ArchLinux に置き換えるという方向です。

Docker on WSL2をやってみる。でちょっと触れたのですが、WSL に Ubuntu をインストールした上で Arch に切り替える、というような方法の中で触れられている lxrun が 2004 ではサポートされなくなっているようです。

ディストリビューションをダウンロードしてインストールする場合には、 Manually download Windows Subsystem for Linux distro packagesにコマンドラインでのインストール方法があるので、そこからダウンロードし、そのページと上記のページ、およびArchLinux Wikiの日本語版にあるWSL にインストールを読み合わせながら行います。

手を抜くためにここでは Store からインストールしてしまいますが、手動でやりたいときには以下のようにします。

まず、ディストリビューションの appx イメージをダウンロードします。ここではUbuntu 18.04 を選びます。20.04 では、/bin などがシンボリックリンクになっていて、後工程での置き換えがうまくいきません。

ダウンローが終わったら PowerShell を起動して、ダウンロードしたディレクトリで次のようにします。このとき、Docker Desktop が起動していると Docker 側にインストールされてしまうので、Docker Desktop は必ず終了しておきます。

Add-AppxPackage .\Ubuntu_1804.2019.522.0_x64.appx

インストールが終わったら bash を起動します。Win+R で bash と入力すると bash が起動するか、スタートメニューにある Ubuntu アイコンをクリックして起動します。

初回起動時には新規ユーザの作成を自動で求められますが、いきなりブレークして一旦シェルに抜けます。再度起動して正常にプロンプトが出るのを確認してから、すべての bash を終了しておきます。

PowerShell またはコマンドプロンプトを開き、wsl -l -v してディストリビューションとして "Ubuntu-18.04" が、バージョンは "2" であることを確認します。WSL 2までインストールされ、WSL のデフォルトバージョンが 2 に設定されているはずなのでこれは当然の動作ですが、ArchLinux に置き換えるためにこの VHDX イメージをプレーンに展開します。

wsl --set-version Ubuntu-18.04 1

すると VHDX からプレーンなディレクトリ構造に展開されます。

展開が終わったら再度 bash を起動して、ArchLinux の bootstrap イメージを https://mirrors.kernel.org/archlinux/iso/latest/あるいはhttps://www.archlinux.jp/download/にあるミラーサイトからダウンロードします。ここでは JAIST からダウンロードさせてもらいます。

wget http://ftp.jaist.ac.jp/pub/Linux/ArchLinux/iso/2020.09.01/archlinux-bootstrap-2020.09.01-x86_64.tar.gz

ダウンロードが終了したら、tar.gz をほどきます。

tar zxvf archlinux-bootstrap-2020.09.01-x86_64.tar.gz

するとこんな感じになっています。

uzi:~# ls -la
total 165680
drwx------    3 root     root          4096 Sep 13 04:48 .
drwxr-xr-x   20 root     root          4096 Sep 12 10:11 ..
-rw-------    1 root     root            11 Sep 13 04:31 .bash_history
-rw-r--r--    1 root     root     169638434 Sep 13 04:47 archlinux-bootstrap-2020.09.01-x86_64.tar.gz
drwxr-xr-x   16 root     root          4096 Sep 13 04:48 root.x86_64
uzi:~#

vi か nano を利用して root.x86_64/etc/pacman.d/mirrorlist のサーバ指定を変更します。ここでは WorldWide と Japan だけ行頭のコメントを外して保存しておきます。

##
## Arch Linux repository mirrorlist
## Generated on 2020-08-01
##

## Worldwide
Server = http://mirrors.evowise.com/archlinux/$repo/os/$arch
Server = http://mirror.rackspace.com/archlinux/$repo/os/$arch
Server = https://mirror.rackspace.com/archlinux/$repo/os/$arch

root.x86_64/etc/resolv.conf を適切に編集するか、自動生成させるようにします。自動生成させるようにするには、

echo "# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line." > ~/root.x86_64/etc/resolv.conf

とするとよいようです。あるいは

nameserver 8.8.8.8
nameserver 8.8.4.4

みたいに決め打ちにしておきます。

ここで bash を（すべて）閉じます。一応ディストリビューションがきちんと停止しているかどうかを確認します。

wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-18.04    Stopped         1

Running になっている場合には、数秒待ってから再度確認すれば Stopped になっていると思います。

次に Explorer を開いて、%localappdata%\PackagesをURIバーにペーストして移動します。そこにある CanonicalGroupLimited.Ubuntu18.04onWindows_* というフォルダを探してそこに移動します。

もう一枚 Explorer を開いて同じ場所に移動します。一枚ではLocalState\rootfsを開き、もう一枚では ArchLinux を展開したLocalState\rootfs\root\root.x86_64を開きます。

Ubuntu 側の bin、etc、lib、lib64、sbin、usr、var を削除し、ArchLinux側から同じディレクトリを移動します。コピーだとシンボリックリンクが壊れるため、コピーではなく必ず移動します。

移動が終わったら、ArchLinux をセットアップします。

# pacman-key --init
# pacman-key --populate archlinux
# pacman -Syyu base base-devel

ついでにいうと、vi や nano といったエディタは削除されてしまっているようなので、お好みのエディタをインストールしたほうがいいでしょう。

最後に root 以外のユーザを作成しておきます。

# useradd -m -G wheel -s /bin/bash chiyo
# passwd root
# passwd chiyo

ここで、bash あるいは Ubuntu アイコンから起動した場合のデフォルトユーザは root のままですが、wsl.exe の引数で指定することができます。適宜ショートカットかバッチファイルなどを作成しておくといいでしょう。

あるいは、コマンドプロンプトから

ubuntu1804 config --default-user chiyo

などとして設定することもできるようです。

WSL 1と2の違い。

今ひとつちゃんと理解していなかったのと、どちらを使えばいいかを決めるのに情報のまとめが必要だったのでメモ。でも勘違いとか正確に理解できてないとか間違ってるとかあるかもしれない。

機能的な比較はWSL 1とWSL 2の比較にまとまっているのでそこを参考にすると、WSL 2側から見た Pros / Cons は、

Pros
- マネージドVM
- 完全なLinuxカーネル
- システムコールの完全な互換性
Cons
- OSファイルシステム間でのパフォーマンス

ということのようです。

パフォーマンス的には、WSL 2 は 9P というプロトコル経由で Windows ファイルシステムにアクセスするためにとても遅いとのこと。つまり、Windows ファイルシステムにある大量のファイルを WSL 2 上の Linux に処理させようとするとめちゃくちゃ遅い、ということのようです。そのため、Linux 側のコンパイルツールで Windows 側のソースツリーをコンパイルするというようなシナリオはパフォーマンスが非常に悪いようです。また、うっかり /mnt/c 以下で作業するとファイルアクセスが極端に遅くなるので、Windowsファイルシステム上にある大量のテキストファイルを処理するような作業も向かないのでしょう。

一方、WSL 2 では Hyper-V を仮想マシンプラットフォームとして管理下に置くため、WSL 2 の Hyper-V API を使用するように設定した VirtualBox や Android Emulator を同時に動かすことができるとのことで、WSL 1 が Hyper-V を専有しているために別の仮想マシンを同時利用できなかったのに比べると大きな違いになっています。

また、WSL 2 が管理している Linux 側のファイルシステムへのアクセスは WSL 1 に比べて高速化しているそうで、Linux ファイルシステム上でのコンパイル作業などは高速になるようです。

WSL 2 ではシステムコールについても完全に互換だということなので、Linux バイナリを持ってくればそのまま動くというのも特徴になります。

じゃあどちらを使えばいいのかというとこれがまたややこしくて、

WSL 1 は Hyper-V を使ってハイパーバイザを独占するので、Hyper-V プラットフォームに対応していない仮想マシンは同居できないし、対応していてもパフォーマンスが悪かったりする。
Docker に関しては、WSL 1 の場合には WSL 上に Linux 版の Docker をインストールして使用することでこの問題は回避できるらしい。
WSL 1 と WSL 2 は同居でき、仮想マシンがどちらを使うかを個別に指定できる。たとえば Ubuntu は WSL 1 上で動かし、Docker Desktop for Windows のバックエンドには WSL 2 を使うということができる（らしい）。wsl -l -v などとすると、パッケージがどちらの WSL で動いているかも表示される。また、wsl --set-version <ディストリビューション> <バージョン> などとしてどちらのバージョンで動作するかを指定できる。

ということなので、Ubuntu は WSL 1で、Docker は WSL 2 で、などというのがいいのかもしれません。ちなみに、WSL 2 までインストールした状態で Docker Desktop for Windows をインストールし、そこに Linux ディストリビューションをインストールするとなぜか Docker の環境で実行されてしまうようでした。なのでインストール順にも注意したほうがいいみたいです。

Docker on WSL2をやってみる。

Windows 10 1909で印刷ができなくなった件。で、Windows 10 2004にしてみたのにはもうふたつ理由があって、WSL2 で MSYS2 からおさらばしたいな、というのと、Docker やってみたいな、というのです。

最終的には自分用サーバの Manjaro Linux にしてみたいのですが、とりあえず軽量で見通しのいいシステムとしたいので Arch Linux を候補にあげておきます。が、Microsoft Store には Arch Linux はないため、それも現状ではペンディングです。

ぐぐってみると、WSL に Ubuntu をインストールした上で Arch に切り替える、というような方法があるようです。また GitHub には ArchWSL と ArchWSL2 というふたつのプロジェクトがあがっています。WSL2 のほうは ALPHA ですが、とりあえず今は先に進みます。

ちなみに、ArchWiki で WSL を検索すると、ArchWiki は Arch しか対象にしてないので他のシステムことは書いてないよ、的なページに飛ばされます。

それはさておき。

まず Windows 10 で WSL2 を有効にします。
Windows 10 ⽤ Windows Subsystem for Linux のインストールガイドに従い、

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

して

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

してから再起動。

コントロールパネルの「アプリと機能」→「オプション機能」→「Windowsのその他の機能」を開き、「Linux用Windowsサブシステム」と「仮想マシンプラットフォーム」にチェックを入れて WSL をインストールし、再起動します。

WSL 2 Linux カーネルの更新から「最新のWSL2 Linuxカーネル更新プログラムパッケージをダウンロード」してインストールします。

管理者モードでPowerShell を開き、

wsl --set-default-version 2

して WSL2 のインストールは終了です。ここでは Linux ディストリビューションはインストールしません。

次に Docker のサイトから Docker Desktop for Windows をダウンロードしてインストールすると、どうもそのままで WSL2 を勝手に利用してくれるようです。

Docker のインストールが終わって起動したら、

docker run hello-world

するとなんか出力してくれます。ちゃんと動いていれば "Hello from Docker!" というメッセージが表示されます。

ということで、Linuxディストリビューションをインストールしなくても Docker は動くよ、というだけのお話。

Windows 10 1909で印刷ができなくなった件。

メインPCを Core-i7 4790K から Core-i9 9900K に変更して見たところ、印刷ができなくなりました。

使用しているプリンタは Canon PIXUS MG7730です。

これまで、Insider Previewで使っていた4790Kでは正常に印刷できていたんですが、HDDの不良クラスタのせいなのかディスクの読み書きが異常に遅くなり、ついでだからとこれまでサブで使用していた 9900K をメインに仕立て直してみたところ、印刷ができないことに気づきました。

「プリンターとスキャナー」からプリンタを削除したり、セーフモードでドライバを削除したり、Regedit で Canon と入っているキーを虱潰しに削除したりといろいろやったんですがダメで、ググったところにあった 1909 で印刷ができなくなる不具合という記述を見つけました。

状況を整理すると以下のとおりです。

9900K では 1909 を使っている
印刷できる 4790K では 20H1 を使っていた
PDF での印刷はできる
Spool サービスは動いている
ドライバを再インストールしてもダメ
スキャナは使える
プリンタのステータスは PC で表示できるので、通信はできている
USB 接続でも LAN 接続でもダメ

もしかしたらこれは 2004 にアップデートしたら直るかもしれないと最後の望みをかけて、Windows 10の Update Assistant をダウンロードして手動アップデートしてみました。

光回線なのにダウンロードはとろとろと進み数時間かけてダウンロードが終了。アップデートしてみたらちゃんと印刷できるようになっていました。

原因究明のために無駄な時間を使ってしまいましたが、めでたしめでたし。

登録: 投稿 (Atom)

ちよぶろ。