私はエビが大嫌いだ。
年越しそばを食べる時、お蕎麦だけではあっさりしすぎなので、天ぷらも食べたい。
そう思って、スーパーに買いに行くと、大晦日はエビばっかり。
かき揚げにも、これみよがしに、エビがついている。
普段は、ちくわ、イカ、穴子、紅しょうが、芋、茄子、春菊、などなどいろいろな天ぷらがあるのに…。
えびアレルギーの人は、どうしているのだろう？
スーパーを何軒もハシゴして、イカの天ぷらを買ってきた。
2019年10月26日土曜日
馬鹿の道
おそらく誰も使っていないのだろう。
数年前から、シンプルで軽いテキストエディタとして、medit(http://mooedit.sourceforge.net/)を使っている。
Ubuntuのパッケージで言うとこれだ。 以前から、時々日本語入力の最中に入力の確定ができなくなることがあったのだが、６月にUbuntu18.04に入れ替えてから、特にその現象が出やすくなった。
あえて18.04のインストールを１年待つのは、不具合の多くが解決されているだろうと期待しての行動だ。 しかし、それでも解決されていない。
おそらく解決を望む人がいないか、気にする人がいないのだろう。
こんな記事は誰も読まないだろうと思うが、meditで日本語入力ができるように改造(修正?)する方法を紹介する。
現象の原因は、キー入力ルーチンにgtk_text_view_im_context_filter_keypress ()が足りていないのだ。 meditのソースパッケージ内の場所で言うと、medit-1.2.0/moo/mooedit/mootextview-input.c 内の以下の部分、赤文字で示した部分を追加する。
数カ月使っていて、明確な問題はない(BSキーに対しても行ったほうが良いかもと思うが)。
とはいえ、本家の活動もほとんど無いようだ。いまどきgtk+2だし、仕方ない。
放置され続けていたので、すでに「使い物にならない！」って逃げ出してしまった人も多いだろう。
仮にこれを修正できたとしても、喜ぶ人はいないのだろうな。
NemoでRabbitVCSを使ったり、fbtermでw3mを使ったり、本流ではないことばかりしている。
しかし、これこそ、馬鹿の道。
数年前から、シンプルで軽いテキストエディタとして、medit(http://mooedit.sourceforge.net/)を使っている。
Ubuntuのパッケージで言うとこれだ。 以前から、時々日本語入力の最中に入力の確定ができなくなることがあったのだが、６月にUbuntu18.04に入れ替えてから、特にその現象が出やすくなった。
あえて18.04のインストールを１年待つのは、不具合の多くが解決されているだろうと期待しての行動だ。 しかし、それでも解決されていない。
おそらく解決を望む人がいないか、気にする人がいないのだろう。
こんな記事は誰も読まないだろうと思うが、meditで日本語入力ができるように改造(修正?)する方法を紹介する。
現象の原因は、キー入力ルーチンにgtk_text_view_im_context_filter_keypress ()が足りていないのだ。 meditのソースパッケージ内の場所で言うと、medit-1.2.0/moo/mooedit/mootextview-input.c 内の以下の部分、赤文字で示した部分を追加する。
:
1243 moo_accel_translate_event (widget, event, &keyval, &mods);
1244
1245 if (keyval == GDK_KP_Enter || keyval == GDK_Return)
1246 {
1247 if (gtk_text_view_im_context_filter_keypress(text_view,event))
1248 return TRUE;
1249 gtk_text_buffer_begin_user_action (buffer);
1250 handled = handle_enter (view, event);
1251 gtk_text_buffer_end_user_action (buffer);
1252 }
:
ソース修正後に、dchとdpkg-buildpackageでバイナリパッケージを作って、インストールしなおせばいい。数カ月使っていて、明確な問題はない(BSキーに対しても行ったほうが良いかもと思うが)。
とはいえ、本家の活動もほとんど無いようだ。いまどきgtk+2だし、仕方ない。
放置され続けていたので、すでに「使い物にならない！」って逃げ出してしまった人も多いだろう。
仮にこれを修正できたとしても、喜ぶ人はいないのだろうな。
NemoでRabbitVCSを使ったり、fbtermでw3mを使ったり、本流ではないことばかりしている。
しかし、これこそ、馬鹿の道。
2019年10月25日金曜日
Ubuntu 18.04 で無理やりNemo RabbitVCS #2
6月に書いたこの記事にしたがってRabbitVCSをインストールした場合、一部の機能が動かない。バージョンが微妙に違うものを無理やりインストールしたためだろう。
記事を書いた後で気がついて、自分では別の方法を使って、再度インストールし直した。
とはいえ、UbuntuでNemoを使う人はマイナーだろうし、バージョン管理にRabbitVCSを使う人も多くないだろう(多くはコマンドラインだろう)から、アクセスは少ないだろうと思っていたので、放置していた。
しかし、最近になってじわじわアクセス数が伸びてきた。
一部の機能が動かない方法のまま放置するのもどうかと思って、新しい方法をここに書く。
新しい方法と言っても、Ubuntuのオフィシャルではない。
様々な事情があるようだが、Ubuntuには Nemo用RabbitVCSパッケージ は無いので、Ubuntuパッケージ管理から離れてなんとかする必要がある。
そのため結局、「無理やり」手法になる。
手動でインストールするために、まず、最新のRabbitVCSを得よう。
RabbitVCSを検索エンジンで検索すると、最初に出てくるのは http://rabbitvcs.orgだろう。(あえてハイパーリンクにしません)
しかし、このページを見ると、2017年あたりから更新が止まっているように見える。
実は、新しいページがgithubに作られている。The new home of rabbitvcs
このページで紹介されている方法に従って(いくつか変更が必要)、インストールするとNemoでRabbitVCSが使えるようになる。
まず最初に現在インストールされているRabbitVCS関連全てを削除する。
前回の無理やりインストールで書き込んだ /usr/share/nemo-python/extensions/RabbitVCS.py は、後から上書きするので、放置しておいて良い。
次に必要なものにリストされているものをインストールする。
Debian系のコマンドライン例も書かれているが、python-gtkspell, tkinter, python-gtk3 が無いと言ってくる。
それぞれについて調べると、python-gtkspell は python-gtkspellcheck で、kinter は python3-tk でいいようだ。
python-gtk3 は、その情報も見つからなかったが、なんとなく python3-tk がカバーしているように思うので無視する(名前も似ているし)。
ということで、以下のようなコマンドで必要なものを入れることになる。
続いて、ダウンロードおよびインストールをおこなう。
ダウンロードはgit cloneで行っておけば、git pullで更新できる(RabbitVCSで更新してもいいか)。
任意のディレクトリに移動して、以下を実行する。
Nemoの場合は、https://github.com/rabbitvcs/rabbitvcs/tree/master/clients/nemoの説明に従う。
Nemoの場合に必要となるものがいくつかある。おそらくすでにインストールされていると思うが、それらをインストールしておく。
ダウンロードしたrabbitvcsの中の、clients/nemo/RabbitVCS.py をコピーする(全ユーザで使う場合)。
どちらの場合でも、python/python-extensionsフォルダを作る必要があるかもしれない的なことが書いてあるが、意味がわからないし、「かもしれない」ので無視する。
(コピーの前にコピー先のディレクトリを作っておけって言っているのかな？)
最後に、nemoを再起動する。
今の所、問題は無い。
無理やりインストールなので、やっぱり自己責任で。
すなわち、更新のチェックや、RabbitVCS.pyの入れ替えは、自分でやらなければならない。
aptはやってくれないし、私も責任をとらない。
2020.02.22 追記
VirtualBoxが動かないときがある。
/usr/share/nemo-python/extensions/RabbitVCS.py をコピーした時、そのディレクトリやそのファイルの所有者がrootになっていないと、VirtualBoxが動かないようだ。前の記事を書いた後で、VirtualBoxが動かなくなることに気がついて、すぐに直していた。
今日になって、母艦でVirtualBoxを使おとしたら動かなかったので、思い出した。
重要な事をなるべく記事に書こうと思うが、うっかり忘れてしまう。
記事にする前に、ある程度時間をかけて(１カ月ぐらいかな)確認していると、最初にやっていた事を忘れてしまう。特に直接関係ない事は「なんかあったような気がするけど、何だったっけ？」のようになってしまう。
所有者を書き換えるなら、たとえば以下のようにすればいい。
上記は、１つの例だ。自分のやり方でやればいい。
2020.03.01 追記
gitで「ログ表示」をした時、Revision Tableの欄の左端にグラフが出ていないことに気がついた。
Python の Cairo関連のパッケージが足りないようで、以下のようにしてインストールする。
2020.11.26 追記
最近になってこの記事のアクセスが増えてきた。
他にも足りないパッケージがあったように思うんだけど、時間経過とともにどんどん忘れてしまった。
'nemo -q'で実行中のnemoを全部止めた状態で、あらためてコマンドラインから'nemo'で起動すると、色々エラーが出る。問題のないものも多いが、python系で何か足りないようなら、それらをインストールしていこう。
2023.03.31 追記
先日、git pullして、setup.pyでインストールし直しを試みたら、setuptoolsが無いみたいなエラーになった。
aptで、python-setuptools(python3系ならpython3-setuptools)をインストールしたら動くようになった。
記事を書いた後で気がついて、自分では別の方法を使って、再度インストールし直した。
とはいえ、UbuntuでNemoを使う人はマイナーだろうし、バージョン管理にRabbitVCSを使う人も多くないだろう(多くはコマンドラインだろう)から、アクセスは少ないだろうと思っていたので、放置していた。
しかし、最近になってじわじわアクセス数が伸びてきた。
一部の機能が動かない方法のまま放置するのもどうかと思って、新しい方法をここに書く。
新しい方法と言っても、Ubuntuのオフィシャルではない。
様々な事情があるようだが、Ubuntuには Nemo用RabbitVCSパッケージ は無いので、Ubuntuパッケージ管理から離れてなんとかする必要がある。
そのため結局、「無理やり」手法になる。
手動でインストールするために、まず、最新のRabbitVCSを得よう。
RabbitVCSを検索エンジンで検索すると、最初に出てくるのは http://rabbitvcs.orgだろう。(あえてハイパーリンクにしません)
しかし、このページを見ると、2017年あたりから更新が止まっているように見える。
実は、新しいページがgithubに作られている。The new home of rabbitvcs
このページで紹介されている方法に従って(いくつか変更が必要)、インストールするとNemoでRabbitVCSが使えるようになる。
まず最初に現在インストールされているRabbitVCS関連全てを削除する。
sudo apt purge 'rabbitvcs*'インストールされていないものは削除できないとか色々表示されるけど、入っているものが削除されれはいいので、'Y'を答えて削除してしまおう。
前回の無理やりインストールで書き込んだ /usr/share/nemo-python/extensions/RabbitVCS.py は、後から上書きするので、放置しておいて良い。
次に必要なものにリストされているものをインストールする。
Debian系のコマンドライン例も書かれているが、python-gtkspell, tkinter, python-gtk3 が無いと言ってくる。
それぞれについて調べると、python-gtkspell は python-gtkspellcheck で、kinter は python3-tk でいいようだ。
python-gtk3 は、その情報も見つからなかったが、なんとなく python3-tk がカバーしているように思うので無視する(名前も似ているし)。
ということで、以下のようなコマンドで必要なものを入れることになる。
sudo apt-get install python-configobj python-gobject python-gtkspellcheck python-svn subversion python-dulwich python-pygments git meld python3-tk
続いて、ダウンロードおよびインストールをおこなう。
ダウンロードはgit cloneで行っておけば、git pullで更新できる(RabbitVCSで更新してもいいか)。
任意のディレクトリに移動して、以下を実行する。
git clone https://github.com/rabbitvcs/rabbitvcs.gitrabbitvcsというディレクトリ(ローカルリポジトリ)ができるので、その中に移動して、手動インストールコマンドを実行する。
sudo python setup.py install --install-layout=debここまで来たら、以降の作業はクライアント(ファイルマネージャ)毎に異なる。
Nemoの場合は、https://github.com/rabbitvcs/rabbitvcs/tree/master/clients/nemoの説明に従う。
Nemoの場合に必要となるものがいくつかある。おそらくすでにインストールされていると思うが、それらをインストールしておく。
sudo apt install nemo-python python-dbus
ダウンロードしたrabbitvcsの中の、clients/nemo/RabbitVCS.py をコピーする(全ユーザで使う場合)。
sudo cp clients/nemo/RabbitVCS.py /usr/share/nemo-python/extensions
どちらの場合でも、python/python-extensionsフォルダを作る必要があるかもしれない的なことが書いてあるが、意味がわからないし、「かもしれない」ので無視する。
(コピーの前にコピー先のディレクトリを作っておけって言っているのかな？)
最後に、nemoを再起動する。
nemo -q pgrep -f service.py | xargs kill nohup nemo > /dev/null &うまくいったら、RabbitVCSが動くようになる。
今の所、問題は無い。
無理やりインストールなので、やっぱり自己責任で。
すなわち、更新のチェックや、RabbitVCS.pyの入れ替えは、自分でやらなければならない。
aptはやってくれないし、私も責任をとらない。
2020.02.22 追記
VirtualBoxが動かないときがある。
/usr/share/nemo-python/extensions/RabbitVCS.py をコピーした時、そのディレクトリやそのファイルの所有者がrootになっていないと、VirtualBoxが動かないようだ。前の記事を書いた後で、VirtualBoxが動かなくなることに気がついて、すぐに直していた。
今日になって、母艦でVirtualBoxを使おとしたら動かなかったので、思い出した。
重要な事をなるべく記事に書こうと思うが、うっかり忘れてしまう。
記事にする前に、ある程度時間をかけて(１カ月ぐらいかな)確認していると、最初にやっていた事を忘れてしまう。特に直接関係ない事は「なんかあったような気がするけど、何だったっけ？」のようになってしまう。
所有者を書き換えるなら、たとえば以下のようにすればいい。
find /usr/share/nemo-python | xargs sudo chown root:root実行しようとすると、sudoがパスワードを求めてくるので、パスワードを入力する。
上記は、１つの例だ。自分のやり方でやればいい。
2020.03.01 追記
gitで「ログ表示」をした時、Revision Tableの欄の左端にグラフが出ていないことに気がついた。
Python の Cairo関連のパッケージが足りないようで、以下のようにしてインストールする。
sudo apt install python-cairocffi python-gi-cairo python3-cairocffi python3-gi-cairo少し入れ過ぎなんだけど、足りないよりは良い。
2020.11.26 追記
最近になってこの記事のアクセスが増えてきた。
他にも足りないパッケージがあったように思うんだけど、時間経過とともにどんどん忘れてしまった。
'nemo -q'で実行中のnemoを全部止めた状態で、あらためてコマンドラインから'nemo'で起動すると、色々エラーが出る。問題のないものも多いが、python系で何か足りないようなら、それらをインストールしていこう。
2023.03.31 追記
先日、git pullして、setup.pyでインストールし直しを試みたら、setuptoolsが無いみたいなエラーになった。
aptで、python-setuptools(python3系ならpython3-setuptools)をインストールしたら動くようになった。
2019年10月11日金曜日
台風19号にも備えよう
先月の台風15号、房総半島方面、横浜方面ではすごいことになった。
台風15号は9/9(月)早朝に関東を通過した。
実はこの日は小潮だった。
また暴風圏が小さく、短時間で通過していったので、高潮被害は限定的だった。
しかし、台風19号のピークである10/13(日)は大潮だ。
海沿いは高潮も考えるべきだ。
しかも、15号よりも19号は何倍も大きい。雨雲は多いし、暴風圏も広い。
大きいため、通過するのにも時間がかかる。長時間雨が降る。
うちは海から離れた「さいたま市」なので高潮の被害はまず無いが、雨だけでもすごいことになるかもしれない。
そういえば先日の15号は、うちの近所を朝の3時頃に通過した。
通過の際、誰かが窓をバンバン叩くような、すごい風が吹いていた。
このとき、窓を開けるとガラスが割れたり、屋根が吹き飛んだりするらしい。
木造一軒家の場合、窓から強風が吹き込むと、屋根が飛びやすくなる。
屋根がなくなると、どれだけ酷いことになるかは、房総半島の惨状をみればわかる。
屋根を守るために、窓を守ろう。
高層マンションは、風が巻き込んですごい風になるときがある。
植木鉢やサンダルが飛んできて、窓を割るかもしれない。
ガラス飛散防止フイルムでガラスを補強しておくのが良いが、なければ養生テープをイギリス国旗のように貼っておくと良い。
とはいえ、近所のビバホは、養生テープが売り切れになっていた。
あちこちで売り切れらしい。
関東の南の方、神奈川や千葉は満潮と接近が重なるので、注意が必要だ。
しかし、悪いことばかりではない。
大潮は、潮位が高いばかりではない。引き潮のときは潮位がすごく低いのだ。
満潮は1日2回、おおよそ5時と17時にある。
干潮も1日2回、おおよそ11時と23時にある。
(地形も影響するので、地域差がある)
台風が接近するのが夕方の満潮付近であるものの、ちょうど真夜中ごろ、すなわち干潮時に関東を通過することになる。
東京湾に流れ込む川の水も、捌けやすい(しかし水量がすごいので楽観できないだろう)。
そのため、東京の被害は限定的かもしれない。
(通過後の千葉や茨城も注意が必要かも)
安全バイアスで、自分だけは大丈夫と思っている人が多いらしい。
埼玉最強伝説の里「さいたま市」在住であるが、後から「やっておけばよかった」と思うよりも、最初にやっておいたほうが良い。
そもそも浦和のあたりは、関東大震災の後、東京から移住してきた人が多い街だ。
災害に対する高い意識があるため、最強伝説も生まれたのかもしれない。
あ、掃除機のバッテリーもしっかり充電しておこう。
ところで、コロッケを何個買えばいい？
2019.10.13: 追記。
予想よりも数時間早く台風が通過した。
今回は、植木鉢を玄関に退避していたので、実害はなかった。
夕方、暗くなり始めの頃、IKEAで買ったラベンダーの良い香りのロウソクに火を付けた。
(今朝、撮影した)
おっちょこちょいなので、停電で真っ暗になる前に明かりを確保しておこうという考えだった。買ってから数年間まったく使っていなかったので、どんどん使おうという考えもあった。
「防災さいたま」から、深夜27時頃「警戒レベル4、直ちに避難」が発令され、まさに「寝耳に水」で少し驚いた。
うちのあたりでは、避難所は「附属中学校」だ。やや離れている。「外が危険な場合は屋内の高いところに...」ともあった。自宅は鉄筋コンクリートの集合住宅だ。停電対策で大量の水を確保していた。ロウソクもまだまだある。掃除機のバッテリーもビンビンだ。
「埼玉県川の情報」で、水が引き始めている(水の増え方が鈍化している)ように見えた。
移動よりも自宅待機のほうが安全と判断し、避難所には行かなかった。
ラベンダーの香りは、気を落ち着かせる効果があるらしい。
少し驚いたものの、冷静に対処できたのはラベンダーの香りのおかげだったかもしれない。
個人的には、実害は全く無かったが、全国的に被害が出ている。
手放しでは喜べない。
台風15号は9/9(月)早朝に関東を通過した。
実はこの日は小潮だった。
また暴風圏が小さく、短時間で通過していったので、高潮被害は限定的だった。
しかし、台風19号のピークである10/13(日)は大潮だ。
海沿いは高潮も考えるべきだ。
しかも、15号よりも19号は何倍も大きい。雨雲は多いし、暴風圏も広い。
大きいため、通過するのにも時間がかかる。長時間雨が降る。
うちは海から離れた「さいたま市」なので高潮の被害はまず無いが、雨だけでもすごいことになるかもしれない。
そういえば先日の15号は、うちの近所を朝の3時頃に通過した。
通過の際、誰かが窓をバンバン叩くような、すごい風が吹いていた。
このとき、窓を開けるとガラスが割れたり、屋根が吹き飛んだりするらしい。
木造一軒家の場合、窓から強風が吹き込むと、屋根が飛びやすくなる。
屋根がなくなると、どれだけ酷いことになるかは、房総半島の惨状をみればわかる。
屋根を守るために、窓を守ろう。
高層マンションは、風が巻き込んですごい風になるときがある。
植木鉢やサンダルが飛んできて、窓を割るかもしれない。
ガラス飛散防止フイルムでガラスを補強しておくのが良いが、なければ養生テープをイギリス国旗のように貼っておくと良い。
とはいえ、近所のビバホは、養生テープが売り切れになっていた。
あちこちで売り切れらしい。
関東の南の方、神奈川や千葉は満潮と接近が重なるので、注意が必要だ。
しかし、悪いことばかりではない。
大潮は、潮位が高いばかりではない。引き潮のときは潮位がすごく低いのだ。
満潮は1日2回、おおよそ5時と17時にある。
干潮も1日2回、おおよそ11時と23時にある。
(地形も影響するので、地域差がある)
台風が接近するのが夕方の満潮付近であるものの、ちょうど真夜中ごろ、すなわち干潮時に関東を通過することになる。
東京湾に流れ込む川の水も、捌けやすい(しかし水量がすごいので楽観できないだろう)。
そのため、東京の被害は限定的かもしれない。
(通過後の千葉や茨城も注意が必要かも)
安全バイアスで、自分だけは大丈夫と思っている人が多いらしい。
埼玉最強伝説の里「さいたま市」在住であるが、後から「やっておけばよかった」と思うよりも、最初にやっておいたほうが良い。
そもそも浦和のあたりは、関東大震災の後、東京から移住してきた人が多い街だ。
災害に対する高い意識があるため、最強伝説も生まれたのかもしれない。
あ、掃除機のバッテリーもしっかり充電しておこう。
ところで、コロッケを何個買えばいい？
2019.10.13: 追記。
予想よりも数時間早く台風が通過した。
今回は、植木鉢を玄関に退避していたので、実害はなかった。
夕方、暗くなり始めの頃、IKEAで買ったラベンダーの良い香りのロウソクに火を付けた。
(今朝、撮影した)
「防災さいたま」から、深夜27時頃「警戒レベル4、直ちに避難」が発令され、まさに「寝耳に水」で少し驚いた。
うちのあたりでは、避難所は「附属中学校」だ。やや離れている。「外が危険な場合は屋内の高いところに...」ともあった。自宅は鉄筋コンクリートの集合住宅だ。停電対策で大量の水を確保していた。ロウソクもまだまだある。掃除機のバッテリーもビンビンだ。
「埼玉県川の情報」で、水が引き始めている(水の増え方が鈍化している)ように見えた。
移動よりも自宅待機のほうが安全と判断し、避難所には行かなかった。
ラベンダーの香りは、気を落ち着かせる効果があるらしい。
少し驚いたものの、冷静に対処できたのはラベンダーの香りのおかげだったかもしれない。
個人的には、実害は全く無かったが、全国的に被害が出ている。
手放しでは喜べない。
2019年10月4日金曜日
Libreoffice Drawで多角形を曲線にすると保存できない
たとえば、シルク印刷の絵を書いたり、アニメーションを作ったりとか、この回路図までも、Libreoffice Drawで書いている。
先日、あるものを作ろうとまた図を書き始めた。
図を少し書いて保存しようとすると、エラーになって保存できない。
どうも、曲線があると保存ができなくなるように見えた。
今日になって、真剣に調べ始めた。
すると、こんなBugがあるではないか。
Bug 119374 - FILESAVE: Cannot save any file with a bezier curve created from a polygon (Linux-only)
(多角形から作られたベジエ曲線を用いたあらゆるファイルが保存できない)。
Linuxだけで生じるらしい。さらに、普通の(多角形からではない)ベジエ曲線が含まれているだけなら、保存できる。
試しにウチでもやってみたら、まさしくそんな感じだった。
また、Libreoffice 6.0系で発生するが、6.1系では発生しないと書かれている。 ウチのやつを見てみたら、6.0系だった。
どうやらこれが原因のようだ。
6.1で治っているなら、6.0系での修正は行われない可能性が高い。
とはいえ、なんとかしたい。Ubuntu 18.04LTEのパッケージ管理を守りつつ、新しいバージョンをInstallする方法を探した。以下を発見した。
How to Install LibreOffice 6.1 in Ubuntu 18.04, 16.04
２つの方法があり、snapを使う方法と、オフィシャルPPAを使う方法が紹介されている。
同ページでは、オフィシャルPPAを使う方法が推薦されているので、私もオフィシャルPPAを使った。
感単に書くと、まず、ターミナルを開いて、PPAを追加するコマンドを実行する。
PPAを追加したので、パッケージ管理を更新する。
何かが足りていなかったのかな？
6.1ではなく、6.3が入った。
試してみると、ベジエ曲線を含んでいても保存できるようになった。
しかし、いつから使えなかったんだろう？
2020/03/27 追記: Libreoffice 6.4にdist-upgradeできなかった aptで更新をチェックしたら、Libreofficeの新しいのがあると表示された。新しいバージョンのようで、dist-upgrade じゃないと保留されてしまう。
新しいやつでも問題は無いだろうとdist-upgradeしたら、依存関係が解決できずににっちもさっちも行かなくなった。
PPAを使っていると、時々こんな事になるもんだ。
解決するためには、問題を起こした新しいパッケージを削除すればいい。そんなことは言われなくてもわかるだろう。
ところが、１つ１つ消そうとしても、依存関係が問題になって、実行できない。
この場合、その依存物をまとめて一気に削除するしかない。ところが、何がどう依存しているのか解りにくい。
"apt-cache rdepends"で調べることもできるが、インストールしていないものも出たりして、それを選り分けるのも面倒だ。
そのため、たとえば、以下のようにして、エラーメッセージ内から依存物エラーになったパッケージを抽出していく。
最初は、こんなふうに適当に消そうとする。
今度は書いたものを追加して、削除を試みる。
ただし、大事なものも消してしまうかもしれないので、消すものをちゃんとチェックしよう。
ウチの場合は、最終的にxxx.txtは、以下のようになった。
18.04のデフォルトの Libreoffice 6.0 に戻すとまた曲線が保存できなくなる。
6.0は使えない。そして、6.4はinstallできないので、その途中、例えば6.3を使うことにした。
まず、古いPPAを削除する。これは、update-managerの「他のソフトウエア」タブで、"http://ppa.launchpad.net/libreoffice/ppa/ubuntu bionic main"のチェックを外す。
そして、一旦更新する。これで、そのPPAリポジトリは使われなくなる。
実は、この LibreOffice Freshには、最新版のPPA以外に、6.3(しばらく使っていた)のPPAもある。最新版のPPAは自動的に新しいメジャーリリースになるが、6.3用のものはマイナアップデートだけが行われる。
6.3のPPAのページのやや下の方の Adding this PPA to your system にしたがって、このリポジトリを追加すればいい。
追加後、上記で示したように、Libreofficeをインストールしなおせばいい。
なんか、追記のほうが多いな。
2020/04/01 追記: いつの間にかできるようになったみたい
ノートPCと母艦にInstallしてうまくいっていたので、安心して職場のPCにもLibreOffice6.3をinstallしようとしたら、エラーになってインストールできなかった。
職場ではWindows+Office365なので、すぐに使う予定はない。放置して待つことにした。
母艦のVirtualBox内でFocalを動かして見ている。そっちではLibreOffice6.4が普通に入っていた。
そして、Focalでは、やたらと頻繁にLibreofficeが更新されていた。
もしや、BionicのLibreOffice6.4も更新されているのでは？と思って、リポジトリを再度6.4のものに変更してやってみたら、インストールできた。
ただし、どういうわけか、Libreoffice-writerとLibreoffice-style-elementaryがダウンロードできなかった(混み合っているのかな？)ので、wgetで無理やりダウンロードして、 /ver/cache/apt/archives/の下に置いて、ファイル名を以下のように書き換えて、apt-get installしたら、インストールできた。
Libreoffice-writer:
Libreoffice-style-elementary:
こんな書き換えをしなくても、このページで説明されている方法を使って、すんなりできた時もあった。
新型コロナウイルスで、テレワークをしている人も多いだろう。自宅ではWindowsではなくてUbuntu+Libreofficeを使っている人も多いだろう。それでダウンロードできないとなると、すごく困ることになる。
そのせいか、ダウンロードがすごく遅い。
待つことができるなら、しばらく待ってダウンロードするのが良いかもしれない。
先日、あるものを作ろうとまた図を書き始めた。
図を少し書いて保存しようとすると、エラーになって保存できない。
どうも、曲線があると保存ができなくなるように見えた。
今日になって、真剣に調べ始めた。
すると、こんなBugがあるではないか。
Bug 119374 - FILESAVE: Cannot save any file with a bezier curve created from a polygon (Linux-only)
(多角形から作られたベジエ曲線を用いたあらゆるファイルが保存できない)。
Linuxだけで生じるらしい。さらに、普通の(多角形からではない)ベジエ曲線が含まれているだけなら、保存できる。
試しにウチでもやってみたら、まさしくそんな感じだった。
また、Libreoffice 6.0系で発生するが、6.1系では発生しないと書かれている。 ウチのやつを見てみたら、6.0系だった。
どうやらこれが原因のようだ。
6.1で治っているなら、6.0系での修正は行われない可能性が高い。
とはいえ、なんとかしたい。Ubuntu 18.04LTEのパッケージ管理を守りつつ、新しいバージョンをInstallする方法を探した。以下を発見した。
How to Install LibreOffice 6.1 in Ubuntu 18.04, 16.04
２つの方法があり、snapを使う方法と、オフィシャルPPAを使う方法が紹介されている。
同ページでは、オフィシャルPPAを使う方法が推薦されているので、私もオフィシャルPPAを使った。
感単に書くと、まず、ターミナルを開いて、PPAを追加するコマンドを実行する。
sudo add-apt-repository ppa:libreoffice/ppaパスワードを聞かれたら、パスワードを入力する。
PPAを追加したので、パッケージ管理を更新する。
sudo apt updateウチの場合は、update後、新しいパッケージが24個が出てきたので、upgradeも行い更新をした。
sudo apt upgradeこれで良いのかなとも思ったが、ここではinstallも行っているので、それに従った。
sudo apt install libreoffice何気に色々installされた。
何かが足りていなかったのかな？
6.1ではなく、6.3が入った。
試してみると、ベジエ曲線を含んでいても保存できるようになった。
しかし、いつから使えなかったんだろう？
2020/03/27 追記: Libreoffice 6.4にdist-upgradeできなかった aptで更新をチェックしたら、Libreofficeの新しいのがあると表示された。新しいバージョンのようで、dist-upgrade じゃないと保留されてしまう。
新しいやつでも問題は無いだろうとdist-upgradeしたら、依存関係が解決できずににっちもさっちも行かなくなった。
PPAを使っていると、時々こんな事になるもんだ。
解決するためには、問題を起こした新しいパッケージを削除すればいい。そんなことは言われなくてもわかるだろう。
ところが、１つ１つ消そうとしても、依存関係が問題になって、実行できない。
この場合、その依存物をまとめて一気に削除するしかない。ところが、何がどう依存しているのか解りにくい。
"apt-cache rdepends"で調べることもできるが、インストールしていないものも出たりして、それを選り分けるのも面倒だ。
そのため、たとえば、以下のようにして、エラーメッセージ内から依存物エラーになったパッケージを抽出していく。
最初は、こんなふうに適当に消そうとする。
sudo apt remove libreoffice-baseエラーが出たら(出ているのだが)、
sudo apt remove libreoffice-base | grep "^ [^ ]\+ :" | sed -e "s/ : .*$//g" | sed -e 's/^ \+//g' > xxx.txtのようにして、エラメッセージ内から、パッケージ名を取り出して、xxx.txtに書く。
今度は書いたものを追加して、削除を試みる。
sudo apt remove libreoffice-base $(< xxx.txt)それでもエラーになるなら、同じようにパッケージ名を取り出して、xxx.txtに書く。今度は追記で書く。
sudo apt remove libreoffice-base $(< xxx.txt) | grep "^ [^ ]\+ :" | sed -e "s/ : .*$//g" | sed -e 's/^ \+//g' >> xxx.txtこれを何回か繰り返せば、強引に削除できる。
ただし、大事なものも消してしまうかもしれないので、消すものをちゃんとチェックしよう。
ウチの場合は、最終的にxxx.txtは、以下のようになった。
libreoffice libreoffice-avmedia-backend-gstreamer libreoffice-base-core libreoffice-base-drivers libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-help-common libreoffice-help-en-gb libreoffice-help-en-us libreoffice-help-ja libreoffice-impress libreoffice-java-common libreoffice-l10n-en-gb libreoffice-l10n-en-za libreoffice-l10n-ja libreoffice-math libreoffice-nlpsolver libreoffice-ogltrans libreoffice-pdfimport libreoffice-report-builder libreoffice-report-builder-bin libreoffice-script-provider-bsh libreoffice-script-provider-js libreoffice-script-provider-python libreoffice-sdbc-firebird libreoffice-sdbc-mysql libreoffice-sdbc-postgresql libreoffice-wiki-publisher libreoffice-writer python3-uno ure(取得後ソートした)
18.04のデフォルトの Libreoffice 6.0 に戻すとまた曲線が保存できなくなる。
6.0は使えない。そして、6.4はinstallできないので、その途中、例えば6.3を使うことにした。
まず、古いPPAを削除する。これは、update-managerの「他のソフトウエア」タブで、"http://ppa.launchpad.net/libreoffice/ppa/ubuntu bionic main"のチェックを外す。
そして、一旦更新する。これで、そのPPAリポジトリは使われなくなる。
実は、この LibreOffice Freshには、最新版のPPA以外に、6.3(しばらく使っていた)のPPAもある。最新版のPPAは自動的に新しいメジャーリリースになるが、6.3用のものはマイナアップデートだけが行われる。
6.3のPPAのページのやや下の方の Adding this PPA to your system にしたがって、このリポジトリを追加すればいい。
追加後、上記で示したように、Libreofficeをインストールしなおせばいい。
なんか、追記のほうが多いな。
2020/04/01 追記: いつの間にかできるようになったみたい
ノートPCと母艦にInstallしてうまくいっていたので、安心して職場のPCにもLibreOffice6.3をinstallしようとしたら、エラーになってインストールできなかった。
職場ではWindows+Office365なので、すぐに使う予定はない。放置して待つことにした。
母艦のVirtualBox内でFocalを動かして見ている。そっちではLibreOffice6.4が普通に入っていた。
そして、Focalでは、やたらと頻繁にLibreofficeが更新されていた。
もしや、BionicのLibreOffice6.4も更新されているのでは？と思って、リポジトリを再度6.4のものに変更してやってみたら、インストールできた。
ただし、どういうわけか、Libreoffice-writerとLibreoffice-style-elementaryがダウンロードできなかった(混み合っているのかな？)ので、wgetで無理やりダウンロードして、 /ver/cache/apt/archives/の下に置いて、ファイル名を以下のように書き換えて、apt-get installしたら、インストールできた。
Libreoffice-writer:
| 変更前 | libreoffice-writer_6.4.2-0ubuntu0.18.04.3_amd64.deb |
| 変更後 | libreoffice-writer_1%3a6.4.2-0ubuntu0.18.04.3_amd64.deb |
Libreoffice-style-elementary:
| 変更前 | libreoffice-style-elementary_6.4.2-0ubuntu0.18.04.3_all.deb |
| 変更後 | libreoffice-style-elementary_1%3a6.4.2-0ubuntu0.18.04.3_all.deb |
こんな書き換えをしなくても、このページで説明されている方法を使って、すんなりできた時もあった。
新型コロナウイルスで、テレワークをしている人も多いだろう。自宅ではWindowsではなくてUbuntu+Libreofficeを使っている人も多いだろう。それでダウンロードできないとなると、すごく困ることになる。
そのせいか、ダウンロードがすごく遅い。
待つことができるなら、しばらく待ってダウンロードするのが良いかもしれない。
2019年9月28日土曜日
IKEA IVAR棚を改造
IKEAのIVARシリーズは、シンプルで安い。
そもそもIKEAの家具は、自分で組み立てるぶん安くなっている。IVARシリーズはその中でもシンプルなので、カスタマイズするベースとして使っている人も少なくはないだろう。
Googlingするとすぐに見つかる。みんな大好きなんだね。
今年の７月ごろ、レーザプリンタを設置していた台やカラーボックスを撤去して、IVARの高さ226cm奥行き30cmの棚を設置することにした。
IKEA三郷店に買いに行ったのだが、どういうわけか30cmの棚板の在庫数がゼロになっており、なかなか買えなかった。
購入して見たら、モデルチェンジしていた。ダボを受ける部品がプラスチック製から鉄製になっていた。
少しずつ進化しているようだ。在庫数ゼロは、モデルチェンジで流通が乱れていたためだろうか？
とにかく、人気商品の１つであることは間違いない。本当にみんな大好き！
とはいえ、レーザプリンタはケーブルの出っ張りも含めると奥行き50cmぐらいある。そのため、50cmの棚板を使うべきとも言えるが、棚全体を50cmで組むとその分部屋が狭くなる。
30cmの棚板に50cmの物を置くために、部分的に拡張することにした。
プリンタは机の高さにしたい。日本の机の高さは、おおよそ75cmぐらいだ。
しかし、IVARのサイドユニットに高さ75cmは無いので、124cmのIVARのサイドユニットを買ってきて、それを下から75cmのところで切断する。
切断後、高さ226cmのサイドユニットに接着して、L字型にする。
棚板がきちんとはまるように、接着は正確に行わないといけない。そこさえきちんとできれば、後は普通に組み立てるだけだ。
作業風景を撮影して、動画にした。
普通に組み立てるって言っても、背の高いIVARを最初に立たせるのは、何気に大変だ。
椅子に養生テープで固定して棚板を２枚はめて、クロスブレース(金属のＸ型)の位置を決め、マークしておいてネジを締める。
棚板とクロスブレースが入ればしっかりする。
準備に集中しすぎて撮影を忘れ、そのまま作業してしまったので、動画は無い。
6年前のこの記事でも少しふれているが、以前は忙しすぎて、引っ越しの荷物が整理できていなかった。 1995年頃から2007年ごろまで、４回引っ越しをしたのだが、引っ越しをしようとすると同時に複数のお客さんが仕事を入れてきて、荷物が片付けられなかった。
引っ越しをする度にその傾向は強くなり、2007年の引っ越しでは、引越し後３年半も忙しい時期が続いた。
もちろん荷物は整理できず、ダンボール箱のまま積み上げられていた。
このIVARの棚が複数本できて、やっと本や書類を収納する場所ができた。開けていなかったダンボール箱を開け、中身を吟味して整理した。
そして、24年の長い引越しが、やっと終わった。
いや、まだ終わっていない。
ダンボールの中からは、PC-9801用のZ-80開発環境の5.25"FDが出てきた。
これは知人から借りていたものだ。返さないといけない。
出てきたものを見て、約四半世紀という時間のスケールを強烈に感じた。
そもそもIKEAの家具は、自分で組み立てるぶん安くなっている。IVARシリーズはその中でもシンプルなので、カスタマイズするベースとして使っている人も少なくはないだろう。
Googlingするとすぐに見つかる。みんな大好きなんだね。
今年の７月ごろ、レーザプリンタを設置していた台やカラーボックスを撤去して、IVARの高さ226cm奥行き30cmの棚を設置することにした。
IKEA三郷店に買いに行ったのだが、どういうわけか30cmの棚板の在庫数がゼロになっており、なかなか買えなかった。
購入して見たら、モデルチェンジしていた。ダボを受ける部品がプラスチック製から鉄製になっていた。
少しずつ進化しているようだ。在庫数ゼロは、モデルチェンジで流通が乱れていたためだろうか？
とにかく、人気商品の１つであることは間違いない。本当にみんな大好き！
とはいえ、レーザプリンタはケーブルの出っ張りも含めると奥行き50cmぐらいある。そのため、50cmの棚板を使うべきとも言えるが、棚全体を50cmで組むとその分部屋が狭くなる。
30cmの棚板に50cmの物を置くために、部分的に拡張することにした。
プリンタは机の高さにしたい。日本の机の高さは、おおよそ75cmぐらいだ。
しかし、IVARのサイドユニットに高さ75cmは無いので、124cmのIVARのサイドユニットを買ってきて、それを下から75cmのところで切断する。
切断後、高さ226cmのサイドユニットに接着して、L字型にする。
棚板がきちんとはまるように、接着は正確に行わないといけない。そこさえきちんとできれば、後は普通に組み立てるだけだ。
作業風景を撮影して、動画にした。
普通に組み立てるって言っても、背の高いIVARを最初に立たせるのは、何気に大変だ。
椅子に養生テープで固定して棚板を２枚はめて、クロスブレース(金属のＸ型)の位置を決め、マークしておいてネジを締める。
棚板とクロスブレースが入ればしっかりする。
準備に集中しすぎて撮影を忘れ、そのまま作業してしまったので、動画は無い。
6年前のこの記事でも少しふれているが、以前は忙しすぎて、引っ越しの荷物が整理できていなかった。 1995年頃から2007年ごろまで、４回引っ越しをしたのだが、引っ越しをしようとすると同時に複数のお客さんが仕事を入れてきて、荷物が片付けられなかった。
引っ越しをする度にその傾向は強くなり、2007年の引っ越しでは、引越し後３年半も忙しい時期が続いた。
もちろん荷物は整理できず、ダンボール箱のまま積み上げられていた。
このIVARの棚が複数本できて、やっと本や書類を収納する場所ができた。開けていなかったダンボール箱を開け、中身を吟味して整理した。
そして、24年の長い引越しが、やっと終わった。
いや、まだ終わっていない。
ダンボールの中からは、PC-9801用のZ-80開発環境の5.25"FDが出てきた。
出てきたものを見て、約四半世紀という時間のスケールを強烈に感じた。
2019年9月27日金曜日
CUP NOODLE 謎肉祭
先日、コンビニに入った時、カップヌードル「謎肉祭」を発見した。
面白そうだったので買ってきて、今日の朝食べた。
朝の空気の中、ベランダで撮影した。
なんとこのカップヌードルには、私の大嫌いな「エビ」が入っていないのだ。
すばらしいぢゃないか！
開けるとこんな感じ。
大量の謎肉がゴロゴロ入っている。
熱湯を投入して、３分後。
すごいボリューム感。
混ぜるとこんな感じ。
朝からカップヌードル？と思うかもしれないが、開発者である安藤百福は毎朝カップヌードルを食べていたらしい。
また、フィリピンではカップヌードルを、時間のない朝に食べるのは普通だ。
朝日の中で食べる謎肉祭カップヌードルは、一味違っていた。
(普段、食べないから、か。)
面白そうだったので買ってきて、今日の朝食べた。
なんとこのカップヌードルには、私の大嫌いな「エビ」が入っていないのだ。
開けるとこんな感じ。
熱湯を投入して、３分後。
混ぜるとこんな感じ。
朝からカップヌードル？と思うかもしれないが、開発者である安藤百福は毎朝カップヌードルを食べていたらしい。
また、フィリピンではカップヌードルを、時間のない朝に食べるのは普通だ。
朝日の中で食べる謎肉祭カップヌードルは、一味違っていた。
(普段、食べないから、か。)
2019年9月8日日曜日
台風15号に備えよう
相当やばい台風１５号が接近している。
何故だかは知らないが、最近は台風のときにコロッケを食べるらしい。
何事も無いことを祈りつつ、近所のBig-Aで、１パック買ってきた。
ついでに、魚のフライも買ってきた。
2019/09/09
台風15号は去った。
いちごの植木鉢がひっくり返っていたが、それ以外の個人的な被害はなかった。
あ、電車が動かないので、仕事に行けないというのもあるか。
文書を読んだり、調べ事をしたりはウチでもできるので、それをしている。
何故だかは知らないが、最近は台風のときにコロッケを食べるらしい。
何事も無いことを祈りつつ、近所のBig-Aで、１パック買ってきた。
ついでに、魚のフライも買ってきた。
2019/09/09
台風15号は去った。
いちごの植木鉢がひっくり返っていたが、それ以外の個人的な被害はなかった。
あ、電車が動かないので、仕事に行けないというのもあるか。
文書を読んだり、調べ事をしたりはウチでもできるので、それをしている。
2019年8月18日日曜日
駿河湾にJAMSTECの「ちきゅう」
今週末は、大瀬崎でダイビングをしていた。
大瀬崎へ向かう途中で、やたらと目立つ大きな船が見えた。
JAMSTECの地球深部探査船「ちきゅう」だった。
走行中の車の中からスマホでデジタルズームして撮影したので、画質は悪い。
何枚も撮影したんだけど、ほとんど手ブレしていた。
大瀬崎からも見えるのなら、到着後に撮影しようと思っていたのに、貴重品預けのときにそのまま渡してしまい、撮影できなかった。
帰るときにまだあれば撮影しようと思っていたのだが、帰るときには少し移動していて、大瀬崎先端に隠れて見えなくなっていた。
というわけで、走行中に撮影したこの画質の悪い写真しかなかった。
大瀬崎へ向かう途中で、やたらと目立つ大きな船が見えた。
JAMSTECの地球深部探査船「ちきゅう」だった。
走行中の車の中からスマホでデジタルズームして撮影したので、画質は悪い。
何枚も撮影したんだけど、ほとんど手ブレしていた。
大瀬崎からも見えるのなら、到着後に撮影しようと思っていたのに、貴重品預けのときにそのまま渡してしまい、撮影できなかった。
帰るときにまだあれば撮影しようと思っていたのだが、帰るときには少し移動していて、大瀬崎先端に隠れて見えなくなっていた。
というわけで、走行中に撮影したこの画質の悪い写真しかなかった。
2019年8月9日金曜日
Ubuntu 18.04 で MediaTek USB Wi-Fi を使う？ #2
前回、テストのために手動でVID/PIDを設定していたが、USBなんだからPnPで行きたい。
性能が出ないので使わないだろうが、自動的に設定する方法を書いておく。
/etc/modprobe.d/の下に以下の内容を持つ、elecom-usbwlan.conf の名前のファイルを作る。
root権限でないと、ファイルの作成に失敗する。
ファイル名は’elecom-usbwlan.conf’である必要はないが、わかりやすさでこのようにした。
性能が出ないので使わないだろうが、自動的に設定する方法を書いておく。
/etc/modprobe.d/の下に以下の内容を持つ、elecom-usbwlan.conf の名前のファイルを作る。
alias usb:v056Ep400Ad*dc*dsc*dp*ic*isc*ip*in* mt76x2u install mt76x2u /sbin/modprobe --ignore-install mt76x2u $CMDLINE_OPT && /bin/echo "056E 400A" > /sys/bus/usb/drivers/mt76x2u/new_id
root権限でないと、ファイルの作成に失敗する。
ファイル名は’elecom-usbwlan.conf’である必要はないが、わかりやすさでこのようにした。
2019年8月7日水曜日
Ubuntu 18.04 で MediaTek USB Wi-Fi を使う？
先週末、体調を崩し寝込んでいた。
病院で診てもらったら、喉全体が真っ赤に腫れていると言っていた。鼻、喉、そして口の中が激痛。もの凄く広範囲が、もの凄く痛かった。
眠ってしまいたいのだが、咳が止まらず、１時間くらいで目が覚めてしまうため、眠れない。
非常に辛かった。
その間にUbuntu18.04のHWEカーネルが、5.0系になっていた。
以前書いていたように、このカーネルではMediaTekのUSB Wi-Fiがサポートされている。
実は以前うっかり間違って、ELECOM の WDC-867SU3SWH を買っていたのだ。
ネットで色々調べると、これはMT7612Uを使っているらしい。
全然使えなかったので、そのまま放置していたのだが、早速これを使ってみた。
結果は残念なものだったけど、その作業について、以下に書いておく。
カーネルのバージョンを確認する
ドライバをロードして、VID/PIDを設定
残念ながら、WDC-867SU3SWHは、ドライバのデバイステーブルにその登録が無い。そのため、挿しただけではドライバも読み込まれないし、当然動かない。
カーネルソースを改造して、VID/PIDを設定して使えるようにするのもいいけど、カーネルのビルドには時間がかかる。
しかしわざわざカーネルをビルドしなくても、ドライバにVID/PIDを設定して使用する方法がある。
これで確認すれば簡単だ。
まずは、ドライバをロードする。WDC-867SU3SWHを挿してはいけない。
この状態で、以下のようにして、VID/PIDを設定する。
一応、確認すると、
使ってみる
ここまでくれば、WDC-867SU3SWHを挿すと動く。
接続するAPのSSIDやキーの設定を適切に行なえ。
ここでは、書かない。
スピードテスト
11acはスピードがウリだ。さらにWDC-867SU3SWHは、リンク速度866Mbpsで動くことになっている。
実際にどのくらいの速度が出ているのか見てみよう。
デスクトップPCとノートPCを使い、デスクトップPCでiperf3をサーバモードで動作させ、ノートPCからWDC-867SU3SWH経由で速度を見る。
まず、デスクトップPCでの作業。
これでノートPCからiperf3で接続して速度を見る。
ちなみに、以前から使っているWDC-433DU2H(リンク速度は半分の433Mbps)はもっと速い。
(abperiasamy/rtl8812AU_8821AU_linuxのドライバを使っている)
WDC-433DU2Hはリンク速度は半分なのに、実際のバンド幅はWDC-867SU3SWHよりも10倍以上。
期待していただけに、かなり残念。
なんで速度が出ないんだろう？
2020/04/12 追記: 上にも書いたが、テストしているPCのUSB3.0ポートが悪いのかもしれない。
詳しくは、Ubuntu 18.04 で MediaTek USB Wi-Fi を使う？ #3 を参照。
病院で診てもらったら、喉全体が真っ赤に腫れていると言っていた。鼻、喉、そして口の中が激痛。もの凄く広範囲が、もの凄く痛かった。
眠ってしまいたいのだが、咳が止まらず、１時間くらいで目が覚めてしまうため、眠れない。
非常に辛かった。
その間にUbuntu18.04のHWEカーネルが、5.0系になっていた。
以前書いていたように、このカーネルではMediaTekのUSB Wi-Fiがサポートされている。
実は以前うっかり間違って、ELECOM の WDC-867SU3SWH を買っていたのだ。
ネットで色々調べると、これはMT7612Uを使っているらしい。
全然使えなかったので、そのまま放置していたのだが、早速これを使ってみた。
結果は残念なものだったけど、その作業について、以下に書いておく。
カーネルのバージョンを確認する
$ uname -a Linux <Host名> 5.0.0-23-generic #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linuxよしよし。5.0系すなわち、4.19以降だ。
ドライバをロードして、VID/PIDを設定
残念ながら、WDC-867SU3SWHは、ドライバのデバイステーブルにその登録が無い。そのため、挿しただけではドライバも読み込まれないし、当然動かない。
カーネルソースを改造して、VID/PIDを設定して使えるようにするのもいいけど、カーネルのビルドには時間がかかる。
しかしわざわざカーネルをビルドしなくても、ドライバにVID/PIDを設定して使用する方法がある。
これで確認すれば簡単だ。
まずは、ドライバをロードする。WDC-867SU3SWHを挿してはいけない。
$ sudo modprobe mt76x2u [sudo] shin のパスワード:(パスワード入力)
この状態で、以下のようにして、VID/PIDを設定する。
$ echo 056e 400a | sudo tee /sys/bus/usb/drivers/mt76x2u/new_id 056e 400aこの 056e 400a が WDC-867SU3SWH のVID/PIDだ。もし違っていたら、それに合わせろ。
一応、確認すると、
$ cat /sys/bus/usb/drivers/mt76x2u/new_id 056e 400aよしよし。
使ってみる
ここまでくれば、WDC-867SU3SWHを挿すと動く。
接続するAPのSSIDやキーの設定を適切に行なえ。
ここでは、書かない。
スピードテスト
11acはスピードがウリだ。さらにWDC-867SU3SWHは、リンク速度866Mbpsで動くことになっている。
実際にどのくらいの速度が出ているのか見てみよう。
デスクトップPCとノートPCを使い、デスクトップPCでiperf3をサーバモードで動作させ、ノートPCからWDC-867SU3SWH経由で速度を見る。
まず、デスクトップPCでの作業。
$ iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------これで、接続待ち状態になる。
これでノートPCからiperf3で接続して速度を見る。
$ iperf3 -c 192.168.YYY.YYY Connecting to host 192.168.YYY.YYY, port 5201 [ 4] local 192.168.XXX.XXX port 53952 connected to 192.168.YYY.YYY port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 2.03 MBytes 17.0 Mbits/sec 85 12.7 KBytes [ 4] 1.00-2.00 sec 2.11 MBytes 17.7 Mbits/sec 102 8.48 KBytes [ 4] 2.00-3.00 sec 2.25 MBytes 18.9 Mbits/sec 101 11.3 KBytes [ 4] 3.00-4.00 sec 2.14 MBytes 17.9 Mbits/sec 100 11.3 KBytes [ 4] 4.00-5.00 sec 2.18 MBytes 18.3 Mbits/sec 94 15.6 KBytes [ 4] 5.00-6.00 sec 1.87 MBytes 15.7 Mbits/sec 107 12.7 KBytes [ 4] 6.00-7.00 sec 2.13 MBytes 17.9 Mbits/sec 99 17.0 KBytes [ 4] 7.00-8.00 sec 2.18 MBytes 18.3 Mbits/sec 99 14.1 KBytes [ 4] 8.00-9.00 sec 1.96 MBytes 16.4 Mbits/sec 100 9.90 KBytes [ 4] 9.00-10.00 sec 2.34 MBytes 19.6 Mbits/sec 95 11.3 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 21.2 MBytes 17.8 Mbits/sec 982 sender [ 4] 0.00-10.00 sec 21.0 MBytes 17.6 Mbits/sec receiver iperf Done.たった17.8Mbps...。何という遅さ！
|
2020/04/12 追記: テストしているPCのUSB3.0ポートが悪いのかもしれない。 WDC-867SU3SWHをUSB2.0ポートに挿してみたら、200Mbps程度の速度が出た。 詳しくは、Ubuntu 18.04 で MediaTek USB Wi-Fi を使う？ #3 を参照。 |
(abperiasamy/rtl8812AU_8821AU_linuxのドライバを使っている)
$ iperf3 -c 192.168.YYY.YYY Connecting to host 192.168.YYY.YYY, port 5201 [ 4] local 192.168.XXX.XXX port 44578 connected to 192.168.YYY.YYY port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 17.9 MBytes 150 Mbits/sec 0 286 KBytes [ 4] 1.00-2.00 sec 21.7 MBytes 182 Mbits/sec 0 428 KBytes [ 4] 2.00-3.00 sec 23.4 MBytes 196 Mbits/sec 0 1.31 MBytes [ 4] 3.00-4.00 sec 22.2 MBytes 187 Mbits/sec 0 2.39 MBytes [ 4] 4.00-5.00 sec 22.7 MBytes 191 Mbits/sec 0 3.15 MBytes [ 4] 5.00-6.00 sec 24.2 MBytes 203 Mbits/sec 0 3.15 MBytes [ 4] 6.00-7.00 sec 22.8 MBytes 191 Mbits/sec 0 3.15 MBytes [ 4] 7.00-8.00 sec 23.0 MBytes 193 Mbits/sec 0 3.15 MBytes [ 4] 8.00-9.00 sec 23.4 MBytes 196 Mbits/sec 0 3.15 MBytes [ 4] 9.00-10.00 sec 23.8 MBytes 199 Mbits/sec 0 3.15 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 225 MBytes 189 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 222 MBytes 186 Mbits/sec receiver iperf Done.189Mbps。何度かやっていると、200Mbpsを超えるぐらいの速度もでる。
WDC-433DU2Hはリンク速度は半分なのに、実際のバンド幅はWDC-867SU3SWHよりも10倍以上。
期待していただけに、かなり残念。
なんで速度が出ないんだろう？
2020/04/12 追記: 上にも書いたが、テストしているPCのUSB3.0ポートが悪いのかもしれない。
詳しくは、Ubuntu 18.04 で MediaTek USB Wi-Fi を使う？ #3 を参照。
2019年7月26日金曜日
PARCOに宇宙がやってきた
今日、浦和PARCOに行ったら、宇宙関連物の展示があった。
本物の宇宙服も展示されていた。
日本の宇宙開発の歴史や、月探査衛星かぐややISSのきぼうモジュールの模型も展示されていた。
実は先日、JAXAの施設の見学に行っていた。
ブログに書こうと思っていたのに、忘れていた。
PARCOに行って思い出した。今度、その記事を書こう。
本物の宇宙服も展示されていた。
実は先日、JAXAの施設の見学に行っていた。
ブログに書こうと思っていたのに、忘れていた。
PARCOに行って思い出した。今度、その記事を書こう。
Street view
今年の4月頃、某所を歩いているときに、Google Street View の車とすれ違った。
過去にもすれ違ったことがあるが、その時は高速道路上の車内だったので、すれ違った場所もわかりにくいし、仮に場所が解ったとしても自分を識別できるかどうかは疑問だったので、チェックすらしなかった。
今回は、狭い市街地の道路だったので、写っているかもしれないと思って、時々StreetViewをチェックしていた。
そして先日、その写真に更新されているのを発見した。
ズームすると、こんな感じ。
マスクをしているときだったので、顔はわからないが、えんじ色のNewBalance、普段着ている服、肩に掛けたウエストポーチは、間違いない。
過去にもすれ違ったことがあるが、その時は高速道路上の車内だったので、すれ違った場所もわかりにくいし、仮に場所が解ったとしても自分を識別できるかどうかは疑問だったので、チェックすらしなかった。
今回は、狭い市街地の道路だったので、写っているかもしれないと思って、時々StreetViewをチェックしていた。
そして先日、その写真に更新されているのを発見した。
2019年7月6日土曜日
水害から街を守れ！
温暖化の影響で、大気が持つエネルギーがどんどん増えている。そのため気象は凶暴化し、毎年のように大規模な豪雨と山火事が世界のどこかで発生している。
日本も例外ではない。海抜0m地帯に広がる首都圏の人口過密地帯は、洪水にも注意しないといけない。梅雨時期は特に。
洪水の防災施設として、埼玉には通称「春日部地下神殿(正式名称:首都圏外郭放水路の庄和排水機場)」と呼ばれる巨大な施設がある。
申し込めば見学することもできる。
見学コースは「立坑体験コース」「ポンプ堪能コース」「地下神殿コース」の３種類がある。機械好きの私としては、ポンプ堪能コースを選んだ。
ただし、これは人気がありなかなか取れない。
さらに、大雨が降れば見学は中止になり、しかも、中止になるとお金は戻ってこない。
逆に言えば、梅雨時期の今はリスクを恐れて、誰も予約しないので、自分は「晴れ男」であると自信のある者は、今こそ予約の時期だ。
先日、予約をして見学してきた。もちろん中止にはならなかった。
東武アーバンパークライン(旧:野田線)の南桜井駅から2kmちょいなので、Google Mapを見ながら歩いていった。
見学前の集合場所の隣には「操作室」と呼ばれる部屋がある。様々なTV番組や映画で、基地や司令室として使われているそうだ。未来的でカッチョいい。
色々説明を受けて、地下のポンプ室へ。
4機の巨大な排水ポンプが並んでいる。
１号ポンプのアップ。
「1号機」と書いてある部分に水車の回転軸がある。
水車はタービンエンジンで駆動する。水平方向に設置されたタービンエンジン(ターボシャフトエンジン)の出力軸から、傘歯車経由で垂直方向の回転にして、ギアで減速して水車を回す。
水車や水路は床の下なので、見えていない。
燃料は重油で、ある程度備蓄しているそうだ。
タービンエンジンは小型で出力が大きいが、大量の空気を吸い込み排出する。そのため、巨大な給排気ダクトがついている(奥に斜めに見えている銀色の部分)。
実はタービンエンジンは、このダクトの向こう側にあり、手前のクリーム色の構造物は、ギアや水車の軸が収まっている。
写真をよく見ればわかるが、斜めのダクトの奥に、もう一つ太いダクトがある。この２つで吸気と排気だろう。
そのため、最初の「１号機」と書かれているブロックは、ポンプシステムの一部でしかない。全体はその何倍も大きいのだ。
これは、４号機。
すべての排水ポンプの上に、採光用と思われる窓がある。
ちなみに、周りの赤いのは消火設備。
これを地上から見ると、こんな感じ。
地上には、水門を動かす装置もある。
ずらりと並んで、壮観だ。
機械なので色はどうでもいいと思うが、風化した大理石のようなクリーム色になっており、これらも神殿感を出している。
いよいよ地下神殿へ。
その入り口は、遺跡感がない。写真には写っていないが、その横ではスケボー少年達が遊んでいる。なんだか興ざめ。
地下に入って、まず目につくのは、この巨大な縦穴。
神殿というよりも、SF映画に出てくる巨大設備のようだ。
この季節でもひんやりとしていて、異世界感満点。
しかも、音がすごくカッチョいい。「ゴーン、ゴーン、ゴトーーン」という感じの、機械が低く唸るような、重厚な音が鳴り響いている。この巨大な構造物を見ながらその音を聞いていると、火星のテラフォーミング施設にでも来たような気分になる。
説明員にこの音について聞いてみた。地上のスケボーの音が巨大施設に響いてこのようなSF的な音になると話していた。
スケボー少年、素晴らしい演出じゃないか！ありがとう。
奥を見ると、こんな感じ。
個人情報保護の観点から、なるべく人が映らないように撮影したのだが、スケール感がまったくない。
そのため、そこにいた人に撮影してもらったのがこの写真。
柱の手前に立っているのが、身長189.5cmの私だ。
神殿感もあったが、巨大な施設はSF感もある。とても興味深い見学だった。
日本も例外ではない。海抜0m地帯に広がる首都圏の人口過密地帯は、洪水にも注意しないといけない。梅雨時期は特に。
洪水の防災施設として、埼玉には通称「春日部地下神殿(正式名称:首都圏外郭放水路の庄和排水機場)」と呼ばれる巨大な施設がある。
申し込めば見学することもできる。
見学コースは「立坑体験コース」「ポンプ堪能コース」「地下神殿コース」の３種類がある。機械好きの私としては、ポンプ堪能コースを選んだ。
ただし、これは人気がありなかなか取れない。
さらに、大雨が降れば見学は中止になり、しかも、中止になるとお金は戻ってこない。
逆に言えば、梅雨時期の今はリスクを恐れて、誰も予約しないので、自分は「晴れ男」であると自信のある者は、今こそ予約の時期だ。
先日、予約をして見学してきた。もちろん中止にはならなかった。
東武アーバンパークライン(旧:野田線)の南桜井駅から2kmちょいなので、Google Mapを見ながら歩いていった。
見学前の集合場所の隣には「操作室」と呼ばれる部屋がある。様々なTV番組や映画で、基地や司令室として使われているそうだ。未来的でカッチョいい。
色々説明を受けて、地下のポンプ室へ。
4機の巨大な排水ポンプが並んでいる。
１号ポンプのアップ。
水車はタービンエンジンで駆動する。水平方向に設置されたタービンエンジン(ターボシャフトエンジン)の出力軸から、傘歯車経由で垂直方向の回転にして、ギアで減速して水車を回す。
水車や水路は床の下なので、見えていない。
燃料は重油で、ある程度備蓄しているそうだ。
タービンエンジンは小型で出力が大きいが、大量の空気を吸い込み排出する。そのため、巨大な給排気ダクトがついている(奥に斜めに見えている銀色の部分)。
写真をよく見ればわかるが、斜めのダクトの奥に、もう一つ太いダクトがある。この２つで吸気と排気だろう。
そのため、最初の「１号機」と書かれているブロックは、ポンプシステムの一部でしかない。全体はその何倍も大きいのだ。
これは、４号機。
すべての排水ポンプの上に、採光用と思われる窓がある。
これを地上から見ると、こんな感じ。
地上には、水門を動かす装置もある。
機械なので色はどうでもいいと思うが、風化した大理石のようなクリーム色になっており、これらも神殿感を出している。
いよいよ地下神殿へ。
その入り口は、遺跡感がない。写真には写っていないが、その横ではスケボー少年達が遊んでいる。なんだか興ざめ。
地下に入って、まず目につくのは、この巨大な縦穴。
この季節でもひんやりとしていて、異世界感満点。
しかも、音がすごくカッチョいい。「ゴーン、ゴーン、ゴトーーン」という感じの、機械が低く唸るような、重厚な音が鳴り響いている。この巨大な構造物を見ながらその音を聞いていると、火星のテラフォーミング施設にでも来たような気分になる。
説明員にこの音について聞いてみた。地上のスケボーの音が巨大施設に響いてこのようなSF的な音になると話していた。
スケボー少年、素晴らしい演出じゃないか！ありがとう。
奥を見ると、こんな感じ。
そのため、そこにいた人に撮影してもらったのがこの写真。
柱の手前に立っているのが、身長189.5cmの私だ。
神殿感もあったが、巨大な施設はSF感もある。とても興味深い見学だった。
2019年7月5日金曜日
動画圧縮し直しスクリプトをまた直した
Ubuntuのインストールし直しで色々な作業をしているが、今年直したばかりの動画圧縮し直しスクリプトもまた直した。
ffmpegのaacのエンコーダが変わったようで、エンコーダの指定を変更する必要があった。
また、サイズの取得に失敗するときがあったので、サイズの取得方法を強化した。
ついでに、出力ファイルがすでに存在している場合、ファイル名の末尾に"-<数字>"を付けるようにした。
$ source-highlight --out-format=html -i ~/bin/toH264.sh
なんか最近、linux関連記事ばかり書いているな…
ffmpegのaacのエンコーダが変わったようで、エンコーダの指定を変更する必要があった。
また、サイズの取得に失敗するときがあったので、サイズの取得方法を強化した。
ついでに、出力ファイルがすでに存在している場合、ファイル名の末尾に"-<数字>"を付けるようにした。
$ source-highlight --out-format=html -i ~/bin/toH264.sh
#!/bin/bash
SRCFILE=$1
DSTFILE=$2
if [ -z "$DSTFILE" ]; then
BASENAME=$(basename $SRCFILE)
DSTFILE=${BASENAME%.*}.mp4
fi
DIRNAME=$(dirname $DSTFILE)
BASENAME=$(basename $DSTFILE)
i=0
while [ -e "$DSTFILE" ]; do
i=$(( i +1 ))
DSTFILE=$DIRNAME/${BASENAME%.*}-${i}.mp4
done
#---------------------------------------------------------------#
# Extract informations from source video. #
#---------------------------------------------------------------#
CREATION_TIME=""
ENCODER=""
videoFormat=""
while read s; do
s=$(echo $s | sed -e "s/^ *//g");
if [[ "$s" == creation_time\ :* ]]; then
if [ -n "$CREATION_TIME" ]; then
echo "creation_time duplicated. Discard candidate $CREATION_TIME"
fi
CREATION_TIME=$( echo $s | sed -e "s/^[ \t]*creation_time[ \t]\+:[ \t]\+//g" )
fi
if [[ "$s" == encoder\ :* ]]; then
ENCODER=$( echo $s | sed -e "s/^[ \t]*encoder[ \t]\+:[ \t]\+//g" )
fi
if [[ "$s" == Stream\ *:\ Video:* ]]; then
videoFormat=$( echo $s | sed -e "s/^[ \t]*Stream \+#.*: \+Video: \+//g" )
fi
done < <( ffprobe ${SRCFILE} 2>&1 )
echo creation_time=$CREATION_TIME, ENCODER=$ENCODER, videoFormat=$videoFormat
#exit 0
#CREATION_TIME=$(ffprobe $SRCFILE 2>&1 | grep "creation_time" | head -n 1 | sed -e "s/[ \t]*creation_time[ \t]*:[ \t]*//g")
echo SRC: $SRCFILE
echo DST: $DSTFILE
if [ -z "$CREATION_TIME" ]; then
echo "No \"creation_time\" metadata. use ctime."
CREATION_TIME=$(stat "$SRCFILE" | grep "^Change:" | head -n 1 | sed -e "s/^Change:[ \t]*//g" | sed -e "s/\.[0-9]* +.*$//g")
fi
echo CERATION_TIME: \""$CREATION_TIME"\"
#---------------------------------------------------------------#
# Auto bitrate #
# H.264には、エンコード品質を表すBPP(Bit Per Pixel)という #
# 指標がある。 #
# BPPを用いて、ビットレートは以下のように計算される。 #
# #
# BPP x fps x width x height #
# bitrate[kbps] = ------------------------------ #
# 1000 #
# #
# H.264のBPPは、動画の動きの速さと、品質で以下のように #
# 決まっている。 #
# | 品 質 #
# |---------+---------+---------+-------- #
# | 最高 | 高 | 中 | 低 #
# -----------+---------+---------+---------+-------- #
# 高 速 | 0.225 | 0.175 | 0.125 | 0.100 #
# 中 速 | 0.200 | 0.150 | 0.100 | 0.075 #
# 低 速 | 0.175 | 0.125 | 0.075 | 0.050 #
# #
# 高速: スポーツまたはミュージックビデオ #
# 中速: 映画 #
# 低速: ナレータ(ニュースや演説など) #
# #
#---------------------------------------------------------------#
#videoFormat=$( ffprobe ${SRCFILE} 2>&1 | \
# grep "Stream \+#[0-9]:[0-9]: \+Video: \+" | \
# sed -e "s/^ \+Stream \+#[0-9]:[0-9]: \+Video: \+//g" );
#bpp="0.225"
bpp="0.125"
width_height=$(echo ${videoFormat} | sed -e 's/^.*, \([0-9]\+x[0-9]\+\), .*$/\1/g')
if [[ ! "$width_height" =~ ^[0-9]+x[0-9]+$ ]]; then
width_height=$(echo ${videoFormat} | sed -e 's/^.*, \([0-9]\+x[0-9]\+\) \+\[.\+\], .*$/\1/g')
fi
if [[ ! "$width_height" =~ ^[0-9]+x[0-9]+$ ]]; then
echo "Unknown video size." 1>&2
exit 1
fi
width=$(echo ${width_height} | sed -e 's/ *\([0-9]\+\)x[0-9]\+ *$/\1/g')
height=$(echo ${width_height} | sed -e 's/ *\+[0-9]\+x\([0-9]\+\) *$/\1/g')
fps=$(echo ${videoFormat} | sed -e 's/^.*, \+\([0-9.]\+\) \+fps,.*$/\1/g')
if [ -z "$width" -o -z "$height" -o -z "$fps" ]; then
echo "cann't get information for bitrate. Use 8192kbps"
vBitrate=8192k
else
echo "bpp=$bpp, width=$width, height=$height, fps=$fps"
vBitrate=$(echo "scale=0; $bpp * $width * $height * $fps / 1000" | bc)"k"
fi
echo "bitrate=${vBitrate}"
#exit 0
#---------------------------------------------------------------#
# Convert video format #
#---------------------------------------------------------------#
ffmpeg -i $SRCFILE -nostdin -y -acodec aac -profile:a aac_low -b:a 128k -ar 44100 -ac 2 -vcodec libx264 -profile:v main -b:v ${vBitrate} -pix_fmt yuv420p -f mp4 -metadata "creation_time"="$CREATION_TIME" -metadata "encoder"="$ENCODER" $DSTFILE
# No audio
#ffmpeg -i $SRCFILE -nostdin -vcodec libx264 -profile:v main -b:v ${vBitrate} -pix_fmt yuv420p -f mp4 -metadata "creation_time"="$CREATION_TIME" -metadata "encoder"="$ENCODER" -map 0:0 $DSTFILE
touch -r ${SRCFILE} ${DSTFILE}
Ubuntu 18.04のffmpegのaacエンコーダ指定にしてしまったので、16.04で使うなら以前のスクリプトを参考に、最後の方をかきかえろ。なんか最近、linux関連記事ばかり書いているな…
2019年6月30日日曜日
2019年6月21日金曜日
Ubuntu 18.04 で無理やりNemo RabbitVCS
2019/10/25 新しい方法をまとめました。Ubuntu 18.04 で無理やりNemo RabbitVCS#2を参照。
今月に入って、母艦もノートPCもUbuntu18.04に入れ替えたので、Touchpad indicatorの設定し直しやNAS経由のプリンタサーバ設定をやり直している。
それ以前はノートPCではLubuntuを使っていたのだが、母艦はUbuntu16.04を使っていた。
Nautilusでは、CompactView(lsの表示に似たフォルダ表示)が使えないので、WebUpd8 team の Nemoと、そのRabbitVCS(言うならば、LinuxのTortoiseSVN)拡張を使っていた。
ノートPCも母艦もUbuntu18.04にしたので、またNemoを入れようとした。
しかし、Webupd8teamでは、18.04用のNemoを提供していないらしい。改めて調べ直すとUbuntuオフィシャルのやつを入れるそうだ。
やってみると、libcinamon-desktop4とかinstallされるが、Cinamonデスクトップ全部が入るわけではない。これならいいだろう。
ところが、nemo-rabbitvcsが入らない。っていうかオフィシャルには存在していないようだ。
なんてこったい。
NautilusではRabbitVCSが動くが、CompactViewがない。
NemoではCompactViewが動くが、RabbitVCSが動かない。
Nemoをデフォルトファイルマネージャにしようと思っていたのに、中途半端ならデフォルトとしては使えない。
なんとかならないかと、調べ始めた。
webUpd8teamのリポジトリから、無理やりnemo-rabbitvcsパッケージを得て、中を調べた。
以下のようにして、artful用のnemo-rabbitvcsのパッケージを取得する。
以下のようにして、パッケージのコントロール情報とファイルを展開する。
これを然るべき場所にコピーするだけなら、手動でやってしまえばいい。難しいことではない。
必要な依存物が揃っているのなら、という条件がつくが...。
パッケージの依存物について見てみる。
これらについて、install されているか見てみる。
このpython-nemoもwebUpd8teamのリポジトリにはある。それを取り出して同じように調べると、NemoをPythonで機能拡張するときに使うものだった。
これは、オフィシャルではnemo-pythonという名前でパッケージとして提供されている。
というわけで、オフィシャルのものをインストールする。
本来python-nemoというパッケージに依存しているのに、nemo-pythonをinstallしたので、dpkgの管理情報的には依存関係は満たされていない。
しかし、/usr/share/nemo-python/extensions/RabbitVCS.py を動作させるのに必要なものは、全部入ったはずだ。
この状態で、さっきartful/に展開した usr/share/nemo-python/extensions/RabbitVCS.py を、/からのパスにコピーする。
これで、Nemoを起動すると、RabbitVCSが使えるようになっている。
エンブレムが見えるかな？
無理やりnemo-rabbitvcsを動かしたけど、問題があるかもしれない。
大切なソースコードだ。やるなら、自己責任で。
なんかあっても私は責任をとらない。
今月に入って、母艦もノートPCもUbuntu18.04に入れ替えたので、Touchpad indicatorの設定し直しやNAS経由のプリンタサーバ設定をやり直している。
それ以前はノートPCではLubuntuを使っていたのだが、母艦はUbuntu16.04を使っていた。
Nautilusでは、CompactView(lsの表示に似たフォルダ表示)が使えないので、WebUpd8 team の Nemoと、そのRabbitVCS(言うならば、LinuxのTortoiseSVN)拡張を使っていた。
ノートPCも母艦もUbuntu18.04にしたので、またNemoを入れようとした。
しかし、Webupd8teamでは、18.04用のNemoを提供していないらしい。改めて調べ直すとUbuntuオフィシャルのやつを入れるそうだ。
やってみると、libcinamon-desktop4とかinstallされるが、Cinamonデスクトップ全部が入るわけではない。これならいいだろう。
ところが、nemo-rabbitvcsが入らない。っていうかオフィシャルには存在していないようだ。
なんてこったい。
NautilusではRabbitVCSが動くが、CompactViewがない。
NemoではCompactViewが動くが、RabbitVCSが動かない。
Nemoをデフォルトファイルマネージャにしようと思っていたのに、中途半端ならデフォルトとしては使えない。
なんとかならないかと、調べ始めた。
webUpd8teamのリポジトリから、無理やりnemo-rabbitvcsパッケージを得て、中を調べた。
以下のようにして、artful用のnemo-rabbitvcsのパッケージを取得する。
wget http://ppa.launchpad.net/webupd8team/nemo3/ubuntu/pool/main/n/nemo-rabbitvcs/nemo-rabbitvcs_3.6.0-1~webupd8~artful_all.deb
以下のようにして、パッケージのコントロール情報とファイルを展開する。
dpkg-deb -R nemo-rabbitvcs_3.6.0-1~webupd8~artful_all.deb artfulこんな感じに展開される。
$ tree artful/
artful/
├── DEBIAN
│ ├── control
│ └── md5sums
└── usr
└── share
├── doc
│ └── nemo-rabbitvcs
│ ├── changelog.Debian.gz
│ └── copyright
└── nemo-python
└── extensions
└── RabbitVCS.py
中を見てみると、/usr/share/nemo-python/extensions/RabbitVCS.py を入れるだけだ。これを然るべき場所にコピーするだけなら、手動でやってしまえばいい。難しいことではない。
必要な依存物が揃っているのなら、という条件がつくが...。
パッケージの依存物について見てみる。
$ dpkg-deb --info nemo-rabbitvcs_3.6.0-1~webupd8~artful_all.deb
new Debian package, version 2.0.
size 8582 bytes: control archive=665 bytes.
592 バイト、 13 行 control
236 バイト、 3 行 md5sums
Package: nemo-rabbitvcs
Version: 3.6.0-1~webupd8~artful
Architecture: all
Maintainer: Clement Lefebvre
Installed-Size: 35
Depends: nemo (>= 1.1.2~), python-nemo (>= 1.0~), python-gi (>= 3.2.2~), rabbitvcs-core (>= 0.15)
Section: devel
Priority: optional
Homepage: https://github.com/linuxmint/nemo-extensions
Description: Nemo extension for RabbitVCS
RabbitVCS is a set of graphical tools written to provide simple and
straightforward access to the version control systems SVN (Subversion) and Git.
This is the extension for the Nemo file manager (v1.1.2 or greater).
依存パッケージは、nemo, python-nemo, python-gi, rabbitvcs-core。これらについて、install されているか見てみる。
$ dpkg -l nemo python-nemo python-gi rabbitvcs-core 要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持 | 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留 |/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常) ||/ 名前 バージョン アーキテクチ 説明 +++-==============-============-============-================================= ii nemo 3.6.5-1 amd64 File manager and graphical shell ii python-gi 3.26.1-2ubun amd64 Python 2.x bindings for gobject-i ii rabbitvcs-core 0.16-1.1 all Easy version control dpkg-query: python-nemo に一致するパッケージが見つかりませんnemo, python-gi, rabbitvcs-coreは入っている(バージョンも問題ない)けど、python-nemoが入ってない。
このpython-nemoもwebUpd8teamのリポジトリにはある。それを取り出して同じように調べると、NemoをPythonで機能拡張するときに使うものだった。
これは、オフィシャルではnemo-pythonという名前でパッケージとして提供されている。
というわけで、オフィシャルのものをインストールする。
$ sudo apt install nemo-python [sudo] xxxxxx のパスワード: パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 以下の追加パッケージがインストールされます: gir1.2-nemo-3.0 以下のパッケージが新たにインストールされます: gir1.2-nemo-3.0 nemo-python アップグレード: 0 個、新規インストール: 2 個、削除: 0 個、保留: 0 個。 33.6 kB のアーカイブを取得する必要があります。 この操作後に追加で 259 kB のディスク容量が消費されます。 続行しますか? [Y/n] y 取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 gir1.2-nemo-3.0 amd64 3.6.5-1 [7,728 B] 取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 nemo-python amd64 3.6.0-1 [25.8 kB] 33.6 kB を 0秒 で取得しました (358 kB/s) 以前に未選択のパッケージ gir1.2-nemo-3.0 を選択しています。 (データベースを読み込んでいます ... 現在 951722 個のファイルとディレクトリがインストールされています。) .../gir1.2-nemo-3.0_3.6.5-1_amd64.deb を展開する準備をしています ... gir1.2-nemo-3.0 (3.6.5-1) を展開しています... 以前に未選択のパッケージ nemo-python を選択しています。 .../nemo-python_3.6.0-1_amd64.deb を展開する準備をしています ... nemo-python (3.6.0-1) を展開しています... gir1.2-nemo-3.0 (3.6.5-1) を設定しています ... nemo-python (3.6.0-1) を設定しています ...gir1.2-nemo-3.0も一緒に入った。
本来python-nemoというパッケージに依存しているのに、nemo-pythonをinstallしたので、dpkgの管理情報的には依存関係は満たされていない。
しかし、/usr/share/nemo-python/extensions/RabbitVCS.py を動作させるのに必要なものは、全部入ったはずだ。
この状態で、さっきartful/に展開した usr/share/nemo-python/extensions/RabbitVCS.py を、/からのパスにコピーする。
$ sudo cp -a artful/usr /
これで、Nemoを起動すると、RabbitVCSが使えるようになっている。
エンブレムが見えるかな？
無理やりnemo-rabbitvcsを動かしたけど、問題があるかもしれない。
大切なソースコードだ。やるなら、自己責任で。
なんかあっても私は責任をとらない。
| わかりにくい表現を直した。 | |
| 厳密にはmainとrestrictedで配布されるものだけがオフィシャルである。nemoやnemo-pythonはuniverseなので、厳密にはオフィシャルではない。 add-apt-repositoryで後から追加したリポジトリではないという意味で、ここでは「オフィシャル」と言う言葉を使っている。 |
|
| "artful"とすべきところを"artiful"と書いていた。直した。 正しい英語にはartifulという単語はない。しかし現代語的なもので、art + beautiful 的な意味で使われる。私は、"Artful Aardvark"(技巧に富んだツチブタ) を何故か"Artiful Aardvark"(芸術的に美しいツチブタ)という意味でとらえていた。つまりtypoではなく、勘違いだった。 |
|
| この方法では、RabbitVCSのいくつかの機能が動かない。 新しい方法を「Ubuntu 18.04 で無理やりNemo RabbitVCS#2」に書いた。 そちらを参照せよ。 |
2019年6月13日木曜日
NASのプリンタサーバのSMB
先週、少し書いたけど、最近ノートPCのOSを、Ubuntu18.04に換えた。
OSを変えたので、あれこれ設定をし直さないといけない。
プリンタの設定は、いつも面倒だ。
こんなこともあろうかと、ブログに書いておいた記事がある。 それを見ながら作業をした。
gnome-session-flashbackだからか、プリンタ設定用のU/Iが見つからないので、CupsのWeb I/F(ブラウザから"localhost:631")を使った。
プリンタの接続プロトコルを指定するとき、どういうわけか"smb"がない。
なんで？無くなったの？ …いやさすがに、それはないだろう。
何かのパッケージが足りないのか？
SMBプロトコル関連で、入れてないものを考えると… smbclient かな？
以前はcifsでマウントする前に、smbclientで接続できることを常に確認していたが、今回は/etc/fstabをbackupしていたので、Copybackして戻していた。
そのため、smbclientパッケージをインストールしていなかった。
試しに端末エミュレータから、
ビンゴ。SMBが現れた。
2017年は、偶然に避けていた。いや、偶然ではなく、慎重だったのだろう。
プリンタの設定は、2012年にもやっているし、母艦での設定もやっているので、慣れてきていて、だんだんたるんできていたのかもしれない。
Linuxも便利になったものだ。
OSを変えたので、あれこれ設定をし直さないといけない。
プリンタの設定は、いつも面倒だ。
こんなこともあろうかと、ブログに書いておいた記事がある。 それを見ながら作業をした。
gnome-session-flashbackだからか、プリンタ設定用のU/Iが見つからないので、CupsのWeb I/F(ブラウザから"localhost:631")を使った。
プリンタの接続プロトコルを指定するとき、どういうわけか"smb"がない。
何かのパッケージが足りないのか？
SMBプロトコル関連で、入れてないものを考えると… smbclient かな？
以前はcifsでマウントする前に、smbclientで接続できることを常に確認していたが、今回は/etc/fstabをbackupしていたので、Copybackして戻していた。
そのため、smbclientパッケージをインストールしていなかった。
試しに端末エミュレータから、
sudo apt install smbclientで、インストールして、ブラウザでCupsに接続し直してみると、
2017年は、偶然に避けていた。いや、偶然ではなく、慎重だったのだろう。
プリンタの設定は、2012年にもやっているし、母艦での設定もやっているので、慣れてきていて、だんだんたるんできていたのかもしれない。
Linuxも便利になったものだ。
2019年6月7日金曜日
HERO'S武蔵浦和がいきなりオープン
オープン当日、夕方にお店の前を通ったとき、行列になっていて入るのを諦めた。
今日は雨なので、客足も遠のくと期待して、お昼に行ってみた。
1ポンド(≒453g)が有名のようだが、年齢のせいかすっかり食が細くなった。その量は食べられないだろう。
量よりも美味しいものを食べたい。
300gのサーロインステーキ(2,180円)を注文した。
ご飯とサラダの大盛りが無料で、オニオンスープはおかわり自由。
ソースは、５種類から選べる。さっぱり感の「和風ソース」にした。
大盛りサラダとスープが先に来た。
写真は和風ソースをかけた状態。
１ポンドが有名だけど、１ポンドばかりじゃなく、ふつうの大きさのステーキもある。
小さいやつなら値段も手頃。駅からふらっと行って、軽く食べるのもありだ。
2019年6月2日日曜日
Ubuntu 18.04で、タッチパッドを自動禁止
キーボードを使っているとき、うっかりタッチパッドに触れて、イライラするときがある。
特にFolio13-2000は、タッチパッドが中央にあり、ホームポジションでは右手とタッチパッドが干渉しやすい。
マウスを接続しているときは、タッチパッドは不要だ。
とはいえ、マウスがないときは、タッチパッドが使えないと困る。
ということで、マウスの有無でタッチパッドを自動的にOFF/ONできるといい。
(恒久的にOFFにするなら、synclientを使えばいいだろう)
Touchpad-indicatorを使えば、これを簡単に行える。
その方法について書く。
Install方法
まずは、PPAの追加。
PPAが追加できれば、あとはupdateとinstallだ。
起動方法
ウチでは、Ubuntu18.04のデフォルトのDesktopではなく、"gnome-session-flashback"を使っている。
そのため、"gnome-session-flashback"での起動方法を書く。
install後に、メニューの「アクセサリー」の中に、"Touchpad Indicator"が作られている。
これをクリックすれば、Touchpad-indicatorが起動する。
パネル内のIndicator appletに、Touchpad-indicatorが加わる。
左クリックしてポップアップを表示させ、「設定」をクリックする。
そうすると、ダイアログが表示される。
(上記は、ついさっき取ったスクリーンショット。インストール直後＆再起動前は、全部英語表示だったように記憶している)
一番上の「マウス接続時はタッチパッドを無効にする」のスイッチを「オン」にする。
つづいて、「一般的なオプション」タブを開いて、「自動起動」をオンにする。
この状態で、一旦ログアウトして、ログインし直すと、自動的にTouchpad-indicatorが起動し、マウスを接続するとタッチパッドが禁止(OFF)になる。
つい最近、LubuntuからUbuntuに変えた。
そうしたら、Touchpad-indicatorが自動で入ってなかった。
Lubuntuの頃には使っていたが、その時もinstall直後にうまく行かず、いつの間にか動くようになっているのを再発見して使うようになったので、やり方をまとめていなかった。
そのため、今回もう一度最初から調べ直した。またLubuntuだけでなくUbuntuでも使える方法だったので、メモ代わりにブログに書いた。
ここで使用しているPPAは、本家Launchpadで管理しているので、信用できると思う。
特にFolio13-2000は、タッチパッドが中央にあり、ホームポジションでは右手とタッチパッドが干渉しやすい。
マウスを接続しているときは、タッチパッドは不要だ。
とはいえ、マウスがないときは、タッチパッドが使えないと困る。
ということで、マウスの有無でタッチパッドを自動的にOFF/ONできるといい。
(恒久的にOFFにするなら、synclientを使えばいいだろう)
Touchpad-indicatorを使えば、これを簡単に行える。
その方法について書く。
Install方法
まずは、PPAの追加。
sudo apt-add-repository ppa:atareao/atareao実行後、確認メッセージが表示される。Enterキーを押して、PPAの追加作業を続行する。
PPAが追加できれば、あとはupdateとinstallだ。
sudo apt update sudo apt install touchpad-indicatorこれで、Touchpad-indicatorが使えるようになる。
起動方法
ウチでは、Ubuntu18.04のデフォルトのDesktopではなく、"gnome-session-flashback"を使っている。
そのため、"gnome-session-flashback"での起動方法を書く。
install後に、メニューの「アクセサリー」の中に、"Touchpad Indicator"が作られている。
これをクリックすれば、Touchpad-indicatorが起動する。
パネル内のIndicator appletに、Touchpad-indicatorが加わる。
左クリックしてポップアップを表示させ、「設定」をクリックする。
一番上の「マウス接続時はタッチパッドを無効にする」のスイッチを「オン」にする。
つづいて、「一般的なオプション」タブを開いて、「自動起動」をオンにする。
つい最近、LubuntuからUbuntuに変えた。
そうしたら、Touchpad-indicatorが自動で入ってなかった。
Lubuntuの頃には使っていたが、その時もinstall直後にうまく行かず、いつの間にか動くようになっているのを再発見して使うようになったので、やり方をまとめていなかった。
そのため、今回もう一度最初から調べ直した。またLubuntuだけでなくUbuntuでも使える方法だったので、メモ代わりにブログに書いた。
ここで使用しているPPAは、本家Launchpadで管理しているので、信用できると思う。
2019年5月29日水曜日
w3mでgoogle検索が使えない#2
w3mで、www.google.comに行って、"w3m"を検索した時のページをALT+Sで保存して、その内容を見てみた。
内容は、なぜかバイナリ。
zcat してみると、HTML文が見えた。
sedを使って、'</a>'の後に改行を挿入して、<a>タグが１つの行になるようにした。
そうしておいて、'<a 'を含む行をgrepで取り出して、行頭から'<a 'の直前までを削除して、いくつかの行を見てみた。
(日本語がバケバケだったので、nkfも通した)
これは、ハイパーリンクとして使えるやつ。
リンク先は、'/search'になっている。そこからリダイレクトする感じで目的のページに飛んでいくのだろう。
中は、<span>タグだけが入っている。
そして、これはハイパーリンクにならないやつ。
そう考えれば、この<a>には問題は無いのだろう。
他の違うところとしては、その中身が、<div>になっていて、しかも２つあることだ。
この辺が、ハイパーリンクにならない原因か？
とりあえず、今日はここまで。
内容は、なぜかバイナリ。
$ hexdump -C search.txt | head 00000000 1f 8b 08 00 00 00 00 00 02 ff d4 58 e9 56 db 48 |...........X.V.H| 00000010 16 7e 15 b5 98 a1 ad c1 96 e5 1d 24 44 8e 59 12 |.~.........$D.Y.| 00000020 08 10 b6 40 e8 a4 d3 39 25 a9 24 15 d6 86 54 c2 |...@...9%.$...T.| 00000030 36 46 6f d0 f3 0c f3 94 f3 7f 6e 55 49 5e 20 30 |6Fo.......nUI^ 0| 00000040 7d e6 df c4 b1 29 dd aa ba 75 97 ef 2e a5 ed 5f |}....)...u....._| 00000050 9c d8 a6 d3 04 4b 3e 0d 83 9d 6d f6 2b 05 28 f2 |.....K>...m.+.(.| 00000060 4c f9 0e c9 f0 8c 91 b3 b3 1d 62 8a 24 db 47 69 |L.........b.$.Gi| 00000070 86 a9 29 5f 7f 7e df d8 94 2b 6a 1c 51 1c 01 b5 |..)_.~...+j.Q...| 00000080 49 42 e4 e1 ac 69 a5 28 72 48 e4 35 bd 38 f6 02 |IB...i.(rH.5.8..| 00000090 ec 35 5b 93 6a f8 23 a3 30 87 52 e7 87 1d 07 71 |.5[.j.#.0.R....q|これは、圧縮データ？と思って、fileコマンドで確認すると、
$ file search.txt search.txt: gzip compressed data, max compressionやっぱり、gzip圧縮データだ。
zcat してみると、HTML文が見えた。
$ zcat search.txt | head <!doctype html><html lang="ja"><head><meta charset="UTF-8"><meta content="/images/branding/googleg/1x/googleg_standard_color_128dp.png"...(省略)ただし、１行で書いてあって、非常に読みにくい。
sedを使って、'</a>'の後に改行を挿入して、<a>タグが１つの行になるようにした。
そうしておいて、'<a 'を含む行をgrepで取り出して、行頭から'<a 'の直前までを削除して、いくつかの行を見てみた。
(日本語がバケバケだったので、nkfも通した)
これは、ハイパーリンクとして使えるやつ。
<a href="/search?inlang=ja&hl=ja&gbv=1&ie=UTF-8&sa=G&q=%E6%97%A5%E6%9C%AC%E8%AA%9E&stick=H4sIAAAAAAAAAOPgE-LQz9U3sDCrMlMCs4zjLYu0VDLKrfST83NyUpNLMvPz9Ivz00rKE4tSrRLLEjNzEpNyUhUy8xaxcj6bvvTZnDUvVs0DAFwBCY9IAAAA&ved=2ahUKEwiUkrSZz8DiAhXEyosBHbkMDdEQmxMwBnoECAsQDA"> <span class="XLloXe AP7Wnd">日本語</span> </a>(インデントを入れたり改行したり、少し整理している)
リンク先は、'/search'になっている。そこからリダイレクトする感じで目的のページに飛んでいくのだろう。
中は、<span>タグだけが入っている。
そして、これはハイパーリンクにならないやつ。
<a href="/url?q=http://w3m.sourceforge.net/index.ja.html&sa=U&ved=2ahUKEwiUkrSZz8DiAhXEyosBHbkMDdEQFjAIegQIBhAB&usg=AOvVaw3hY1zSIhxgTLjnhFncoCW8"> <div class="BNeawe vvjwJb AP7Wnd">W3m - SourceForge</div> <div class="BNeawe UPmit AP7Wnd">w3m.sourceforge.net</div> </a>リンク先は、'/url'で始まっていて異なるが、その後はよく似ている。同じようにリダイレクトするのだろう。
そう考えれば、この<a>には問題は無いのだろう。
他の違うところとしては、その中身が、<div>になっていて、しかも２つあることだ。
この辺が、ハイパーリンクにならない原因か？
とりあえず、今日はここまで。
2019年5月28日火曜日
w3mでgoogle検索が使えない#1
最近のブラウザは重い。
特に32bit Windowsでは、頑張っても3GiBまでしか使用できないので、VirtualBoxと一緒に使っていたりすると、LinuxでOom-killerが動き出して、Linux側が使い物にならなくなる。
そんな状態でも、w3mは動く。
質問フォーラム等のブラウジングなら、充分に使える。
キーバインドを覚えれば、かなり便利だ。
しかし、先週辺りからgoogleの検索結果のハイパーリンクが表示されなくなってしまった。
検索してみると、ちょうど先週辺りから検索結果の表示方法を変更したそうだ。
情報ソース(パブリッシャ)を先に表示するように変更しているそうだ。
これが、関係している？
w3mが使えなくなると、ボロマシン好きの私にとっては、色々面倒だ。
もう少し調べよう。
特に32bit Windowsでは、頑張っても3GiBまでしか使用できないので、VirtualBoxと一緒に使っていたりすると、LinuxでOom-killerが動き出して、Linux側が使い物にならなくなる。
そんな状態でも、w3mは動く。
質問フォーラム等のブラウジングなら、充分に使える。
キーバインドを覚えれば、かなり便利だ。
しかし、先週辺りからgoogleの検索結果のハイパーリンクが表示されなくなってしまった。
検索してみると、ちょうど先週辺りから検索結果の表示方法を変更したそうだ。
情報ソース(パブリッシャ)を先に表示するように変更しているそうだ。
これが、関係している？
w3mが使えなくなると、ボロマシン好きの私にとっては、色々面倒だ。
もう少し調べよう。
2019年5月19日日曜日
きれいな空気を胸いっぱいに#2
壁の吸気口のフィルタは、高価である。
わざわざそれを選ぶ人もいないだろうし、競争が無いのでしょうがないのかもしれない。
さらに平面的で、吸気抵抗が大きいと感じる。
去年、このコードレス掃除機を買ったため、古い掃除機の紙パックが余っていた。
この余っている紙パックを、吸気口のフィルタとして使えないだろうか？
ということで、ウチの吸気口に合う、掃除機紙パックアダプタを作ってみることにした。
またまたMDFボードで作る。
シールの紙に、寸法の線を書いたものを印刷し、それをMDFボードに貼り付けて、その線に沿って切り抜き、部品を貼り合わせる。
部品を切り出した状態で写真を撮影しておいたのに、うっかり消してしまったので、一部接着しているが、もう一度部品の写真を撮り直した。
段差の間に、紙パックの厚紙を挟むようにする。
仮組みするとこんな感じ。
接着した。
このままでも使えなくはないんだけど、雨水がかかるかもしれない。濡れても良いように、表面にペンキを塗ることにした。
シーラを塗って、300番ぐらいの紙やすりで表面を整えて、セリアで買ったペンキを塗った。
お店で見た時は、世田谷ベースのような水色に思ったのだが、写真で見ると鮮やかな水色に見える。
紙パックの厚紙が接触する部分に、薄いスポンジを挟んで、隙間をなくす。
スポンジはビバホームで買った。
厚さ5mm。少し厚いが選択しがない。
やっぱり少し厚いかな。
縁取りのスポンジもつけて、押さえ板をネジで固定すれば、出来上がり。
各社共通の紙パックを使っているので、余計な切り欠きのミシン目が見える。
ネジをMDFボードの小口(っていうか木端と区別ないけど)にネジを打つのは、ほぼ必ず失敗する。
MDFボードが層状に剥離してしまうためだ。
写真をよく見ればわかるが、小口を四角く開けた穴に入れた。さらに、木端側にもエポキシ接着剤(Eセット)を塗って浸透させ、剥離しにくくした。
さらに、脇に板を重ねてある(もちろんガッチリ接着している)。
ここまでやっても、剥がれるかもしれないので、あまり太いネジは使えない。
ウチにあったΦ2.7mmのネジを使った。皿ネジだったので、ワッシャを入れた。
例によって、例のごとく、ここまでの作業には1ヶ月ぐらいかかっている。
接着剤やペンキが固まるのを待たないといけないのでどうしても時間がかかる。
実は、最初の記事、吸気口の「角形プッシュ式レジスタ」を交換する前に、この掃除機紙パックアダプタを作っていた。
これを取り付ける時の動画。
この動画を撮影したのも、角形プッシュ式レジスタ交換前なので、古い物が付いている。
紙パックはシワシワで立体的だ。表面積は多い。吸気抵抗は低いと考えられる。
これはΦ150の吸気口だけど、Φ100のやつにも掃除機紙パックをつけようと考えている。
しかし、Φ100だと普通の掃除機の紙パックは使えない。ハンディクリーナのものを使おうと考えている。
つづく。
わざわざそれを選ぶ人もいないだろうし、競争が無いのでしょうがないのかもしれない。
さらに平面的で、吸気抵抗が大きいと感じる。
去年、このコードレス掃除機を買ったため、古い掃除機の紙パックが余っていた。
この余っている紙パックを、吸気口のフィルタとして使えないだろうか？
ということで、ウチの吸気口に合う、掃除機紙パックアダプタを作ってみることにした。
またまたMDFボードで作る。
シールの紙に、寸法の線を書いたものを印刷し、それをMDFボードに貼り付けて、その線に沿って切り抜き、部品を貼り合わせる。
部品を切り出した状態で写真を撮影しておいたのに、うっかり消してしまったので、一部接着しているが、もう一度部品の写真を撮り直した。
仮組みするとこんな感じ。
接着した。
シーラを塗って、300番ぐらいの紙やすりで表面を整えて、セリアで買ったペンキを塗った。
紙パックの厚紙が接触する部分に、薄いスポンジを挟んで、隙間をなくす。
スポンジはビバホームで買った。
やっぱり少し厚いかな。
縁取りのスポンジもつけて、押さえ板をネジで固定すれば、出来上がり。
ネジをMDFボードの小口(っていうか木端と区別ないけど)にネジを打つのは、ほぼ必ず失敗する。
MDFボードが層状に剥離してしまうためだ。
写真をよく見ればわかるが、小口を四角く開けた穴に入れた。さらに、木端側にもエポキシ接着剤(Eセット)を塗って浸透させ、剥離しにくくした。
さらに、脇に板を重ねてある(もちろんガッチリ接着している)。
ここまでやっても、剥がれるかもしれないので、あまり太いネジは使えない。
ウチにあったΦ2.7mmのネジを使った。皿ネジだったので、ワッシャを入れた。
例によって、例のごとく、ここまでの作業には1ヶ月ぐらいかかっている。
接着剤やペンキが固まるのを待たないといけないのでどうしても時間がかかる。
実は、最初の記事、吸気口の「角形プッシュ式レジスタ」を交換する前に、この掃除機紙パックアダプタを作っていた。
これを取り付ける時の動画。
この動画を撮影したのも、角形プッシュ式レジスタ交換前なので、古い物が付いている。
紙パックはシワシワで立体的だ。表面積は多い。吸気抵抗は低いと考えられる。
これはΦ150の吸気口だけど、Φ100のやつにも掃除機紙パックをつけようと考えている。
しかし、Φ100だと普通の掃除機の紙パックは使えない。ハンディクリーナのものを使おうと考えている。
つづく。
登録:
投稿 (Atom)