OpenJDK で JOSM

Javaで動作するOpenStreetMapエディタのJOSMをLinux上のOpenJDKで動かすメモです.
Debian sid amd64 / Ubuntu 16.04 LTS ARM64 で確認しています.

JOSMの入手

JOSMを次のページから入手します.josm-tested.jar をよく使っています.

OpenJDKインストール

2015年12月くらいにはこんなメッセージが出ていて現在はJava 8以上が必要になっています.

このバージョンのJavaはもうすぐサポート対象から外れます。 Java 8以上にアップグレードしてください!

ここでは OpenJDK 8 を導入

$ sudo apt install openjdk-8-jre

javaの確認

OpenJDK 8になっている.もし違うバージョンが表示されたら次の項目へ.

$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

javaが複数入っていてjavaコマンドの結果が想定しているバージョンではない場合切り替える

OpenJDK 8の場合はここはスキップする.

$ sudo update-alternatives --config java

JOSM起動

-Dawt.useSystemAAFontSettings=onはフォントのアンチエイリアスを有効にするオプション.LCDの場合onの代わりにlcd.

$ java -jar -Dawt.useSystemAAFontSettings=on ./josm-latest.jar
追記)
他の環境だとこの辺のどれかが使えそう(未確認)

Debian sidのkernel.sysrqの値が変わった?

先日Debian sid amd64環境でprocpsの更新がありました.

$ apt show procps
Package: procps
Version: 2:3.3.12-4
Priority: important
Section: admin
Maintainer: Craig Small <csmall@debian.org>
Installed-Size: 712 kB
Provides: watch
Depends: libc6 (>= 2.15), libncurses5 (>= 6), libncursesw5 (>= 6), libprocps6, libtinfo5 (>= 6), lsb-base (>= 3.0-10), init-system-helpers (>= 1.29~)
Recommends: psmisc
Conflicts: pgrep (<< 3.3-5), w-bassman (<< 1.0-3)
Breaks: guymager (<= 0.5.9-1), open-vm-tools (<= 2011.12.20-562307-1)
Homepage: https://gitlab.com/procps-ng/procps
Tag: admin::monitoring, implemented-in::c, interface::commandline,
 interface::text-mode, role::program, scope::utility,
 uitoolkit::ncurses, use::checking, use::monitor,
 works-with::software:running
Download-Size: 251 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.jp.debian.org/debian sid/main amd64 Packages
Description: /proc ファイルシステムユーティリティ
 本パッケージは procfs を閲覧するためのコマンドラインおよび全画面のユーティ
 リティを提供します。procfs とは "擬似的な" ファイルシステムで、カーネルによ
 り動的に生成されます。カーネルのプロセステーブル内のエントリの状態に関する
 情報 (例えば、プロセスが稼働中、停止中、または "ゾンビ" である、など) が提
 供されます。
 .
 本パッケージには次のものが含まれます: free, kill, pkill, pgrep, pmap, ps,
 pwdx, skill, slabtop, snice, sysctl, tload, top, uptime, vmstat, w, watch。

更新に伴い/etc/sysctl.confの更新がありました.

設定ファイル '/etc/sysctl.conf'
 ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
 ==> パッケージ配布元が更新版を提供しています。
   どうしますか? 以下の選択肢があります:
    Y か I  : パッケージメンテナのバージョンをインストールする
    N か O  : 現在インストールされている自分のバージョンを残す
      D     : 両バージョンの差異を表示する
      Z     : 状況を調査するためにシェルを開始する
 デフォルトでは現在使っている自分のバージョンを残します。
*** sysctl.conf (Y/I/N/O/D/Z) [デフォルト=N] ? D

差分を見ると自分で編集した部分以外はコメントだけだったのですが,気になる項目が.

@@ -61,18 +61,13 @@

 ###################################################################
 # Magic system request Key
-# 0=disable, 1=enable all
-# Debian kernels have this set to 0 (disable the key)
-# See https://www.kernel.org/doc/Documentation/sysrq.txt
+# 0=disable, 1=enable all, >1 bitmask of sysrq functions
+# Debian kernels have this set to 438 which is the OR of:
+#  64 = enable signalling of processes
+#  128 = allow reboot/poweroff
+#  256 = allow nicing of all RT tasks
+#
+# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
 # for what other values do
-#kernel.sysrq=1
+#kernel.sysrq=438

Magic system request Keyの項目が以前は0 or 1で有効か無効化のみだったと思うのですが,細かく指定できるようになっているようです.

0 – disable sysrq completely
1 – enable all functions of sysrq
>1 – bitmask of allowed sysrq functions (see below for detailed function description):

てことでkernel.sysrq=438は16進数で0x1B6なので

$bc
obase=16
438
1B6

以下が有効ということのようです.

2 = 0x2 – enable control of console logging level
4 = 0x4 – enable control of keyboard (SAK, unraw)
16 = 0x10 – enable sync command
32 = 0x20 – enable remount read-only
128 = 0x80 – allow reboot/poweroff
256 = 0x100 – allow nicing of all RT tasks

無効になっているのは以下の項目.

8 = 0x8 – enable debugging dumps of processes etc.
64 = 0x40 – enable signalling of processes (term, kill, oom-kill)

kernel configを見るとこの項目になっています.少なくとも4.13.0-1〜4.14.13-1以降は同じみたい.

$ zgrep ONFIG_MAGIC_SYSRQ /boot/config-`uname -r`
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6
CONFIG_MAGIC_SYSRQ_SERIAL=y

ということでコメントが実際のkernelの項目と同じになったということみたいなので動作は変わらないようです.

追記)

昔使い方を知りたくて調べたときに見つけた文章は@miurahrさん翻訳のものでした.その後 で本人に遭遇.

porgを一般ユーザで利用する

porgを一般ユーザで利用するメモ

一般ユーザで普通に使おうとするとログ保存場所の/var/lib/porgへの権限がないと怒られてしまう.

$ porg -D ~/.porg -lp program-0.10.61 make install
porg: /var/lib/porg: Permission denied

ログ保存ディレクトリを指定すると行ける.

$ porg -L ~/.porg -lp program-0.10.61 make install

manより

   -L, --logdir=DIR
          Base log  directory.  The  logs  for  the  installed  packages  are  saved  in  this  directory.  Default  is
          '/var/lib/porg', unless variable LOGDIR is set in the configuration file (type 'man porgrc' for more informa‐
          tion).

--PREFIX=${HOME}/usrみたいな時向けに

version等

$ porg -V
porg-0.10 (17 May 2016)
Written by David Ricart <http://porg.sourceforge.net>
$ dpkg-query -W porg
porg    2:0.10-1.1

Btrfsでdfで空き容量があるように見えるのに容量が無いと言われてreadonlyにされてしまう

最近Btrfsで利用中にroにされてしまうという症状が起きます.
こんな感じで怒られてroになる.
dfは87%とかで未だ空きはあるように見える.
/に使ってるとこでremount,rwも効かず再起動しないと戻せず辛い.

[ 2196.878532] BTRFS: error (device dm-1) in btrfs_truncate_inode_items:4647: errno=-28 No space left
[ 2196.878537] BTRFS info (device dm-1): forced readonly
[ 2196.881248] BTRFS error (device dm-1): pending csums is 1241088

FAQだったようでここを参照しながら

別のsystemで確認してbtrfs fi balance start -dusage=5を叩いてみました.

$ sudo btrfs fi show
Label: none uuid: e54de82f-1fdb-4f9a-b529-0952b0ea3454
        Total devices 1 FS bytes used 465.89GiB
        devid 1 size 542.28GiB used 542.28GiB path /dev/mapper/x220--vg-root

$ sudo mount -o ro /dev/mapper/x220--vg-root /mnt
$ sudo btrfs fi df /mnt
Data, single: total=538.27GiB, used=462.41GiB
System, single: total=4.00MiB, used=80.00KiB
Metadata, single: total=4.01GiB, used=3.48GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
$ sudo btrfs fi balance start -dusage=5 /mnt
ERROR: error during balancing '/mnt': Read-only file system
There may be more info in syslog - try dmesg | tail
$ sudo mount -o remount,rw /mnt
$ sudo btrfs fi balance start -dusage=5 /mnt
Done, had to relocate 0 out of 546 chunks

しかしあまり変わらず暫く利用しているとまたエラーに.しかし今度はdisk fullと怒られるけどroにはならなかったです.以下のページによると,

This means the bigger the -dusage value, the more work balance will have to do (i.e. taking fuller and fuller blocks and trying to free them up by putting their data elsewhere). Also, if your FS is 55% full, using -dusage=55 is ok, but there isn’t a 1 to 1 correlation and you’ll likely be ok with a smaller dusage number, so start small and ramp up as needed.

ということで-dusage=90にしてみると結構空いた感じです.
上の方では別systemで起動して実行しましたが,オンラインでも大丈夫でした.但し処理中はかなり重くなります.そして処理に200分程かかりました.

$ sudo btrfs fi balance start -dusage=90 /
Done, had to relocate 186 out of 530 chunks
$ sudo btrfs fi show
Label: none  uuid: e54de82f-1fdb-4f9a-b529-0952b0ea3454
        Total devices 1 FS bytes used 446.08GiB
        devid    1 size 542.28GiB used 449.27GiB path /dev/mapper/x220--vg-root

この後数GBのデータを書いてみたり溜まっていたapt upgradeとかしてみましたが今のところ大丈夫そうです.
ちなみにこのfsがあるSSD(INTEL SSDSA2CW600G3)も長く使っているのでそっちも心配だったのですが,smartctl-t longしたり-aの以下のあたり見る感じでは未だ行けそう?

9 Power_On_Hours 0x0032 100 100 000 Old_age Always – 36565
228 Workload_Minutes 0x0032 100 100 000 Old_age Always – 2193912
232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always – 0
233 Media_Wearout_Indicator 0x0032 095 095 000 Old_age Always – 0

#適当なとこでsecure eraseしておきたい…….

clipitが動かなくなっていた

clipit

暫く前からDebian sid amd64環境のclipit(クリップボード・マネージャ)が動かなくなっていました.
端末で実行するとこんな感じ

$ clipit

(clipit:23553): GLib-ERROR **: ../../../../glib/gmem.c:100: failed to allocate 18446744071610537348 bytes
Trace/breakpoint trap

sidだしなんか一時的におかしくなってるのかなととりあえず放置してたんですが暫く経っても直らない.バグレポ見るとこんな感じでそれらしいバグは見当たりません.

Querying Debian BTS for reports on clipit (source)...
7 bug reports found:

Bugs with severity important
  1) #679488  abuses xdg/autostart to get started and cannot be disabled
Bugs with severity normal
  2) #721007  clipit: Wakes up too many times per second and prevents deep sleep of cpu
  3) #771200  clipit: cannot edit 'actions'
  4) #819496  clipit clipboard history is *world* readable
Bugs with severity minor
  5) #658533  clipit: static item ordering
Bugs with severity wishlist
  6) #658532  clipit: manage history items in list view
  7) #875903  clipit: please choose a sensible default in "live" mode?

自分の環境がおかしいのか?ととりあえず設定ファイルを探すとこれのよう.

  • ~/.config/clipit/clipitrc

試しにこのファイルを退避してclipitを実行すると普通に起動しました.
てことで設定ファイルあ壊れていたようです(◞‸◟)

暫く前にinodeあふれさせてしまったのでそのときに壊れたのかもです.

bluetoothを無効にする(Debian sid amd64)

Bluetooth経由でスマホからPCまで乗っ取れる攻撃手法が発覚 ~Bluetoothがオンになっているだけで攻撃可能 – PC Watch

BT搭載デバイスは、ペアリング済みのデバイスだけでなく、つねにあらゆるデバイスからの着信接続を探知しているため、デバイスをまったくペアリングせずにBT接続を確立できる。このため、BlueBorneは攻撃を検知されない潜在的攻撃となっている。

 BlueBorne攻撃では、まず周囲のアクティブなBT接続を探知する。このさい、ペアリングのための「発見可能」モードでなくても、BTがオンになっていれば識別が可能となる。

とても怖いです.
手元の端末ではPCとAndroidをBluetoothテザリングをよく利用しています.

PCの対応状況を確認(2017-09-13時点)すると,Debianは未だ未対応.Ubuntuは14.04 LTS, 16.04 LTS, 17.04がリリース済みでした.

とりあえず,手元で使っているDebian sid amd64とRaspberry Pi Zero WのRaspbian stretchでBluetoothを無効にしておくことにしました.


blueman-appletで設定

PCではblueman-appletを利用しています.
システムトレイ上のアイコンを右クリックして
Turn off Bluetooth
を行うと無効に出来てBluetoothのLEDも消灯します.
でも再起動でOnになるので起動のたびに設定しないといけない&そのタイミングで攻撃をされるかもしれないのであまりよろしくない感じがします.


moduleをblucklistに入れて無効にする

Bluetoothのモジュールを読み込まないようにしてみます.これならBluetoothは動作しないはずです.

まずはlsmodコマンドでbluetooth関連モジュールを確認します.手元のLenovo x200の場合は以下のようになりました.

x200のbluetooth module確認

$ lsmod|grep -i bluetooth
bluetooth             544768  14 btrtl,btintel,bnep,btbcm,rfcomm,btusb
crc16                  16384  2 bluetooth,ext4
rfkill                 24576  6 bluetooth,thinkpad_acpi,cfg80211

モジュールをロードしないように /etc/modprobe.d/blacklist.conf というファイルに blacklist <modulename> という形式で書いていきます.

x200 blacklistに設定

$ echo 'blacklist btrtl
> blacklist btintel
> blacklist bnep
> blacklist btbcm
> blacklist rfcomm
> blacklist btusb
> blacklist bluetooth' | sudo tee -a /etc/modprobe.d/blacklist.conf

設定したら再起動してモジュールが読み込まれないのを確認します.

再起動してmoduleがloadされないのを確認

$ lsmod|grep -i bluetooth

しかしPCのBluetooth LEDインジケーターが消えません.動作上は問題ないでしょうけどちょっと気持ち悪いです.
GPIO辺り探すと消せそうですが面倒.


BIOSで無効にする

PCによっては設定できないかもですが,BIOSで無効にします.これだとLEDインジケーターも光らないので良い感じです.


https://farm5.staticflickr.com/4435/37206157365_ab607c3943.jpg


物理的にモジュールを取り外す

これが一番確実でしょうがそう待たずにセキュリティ修正は降りてくると思うので今回は見送りました.

speedtest.netがcliで利用できるspeedtest-cliを試す

九里 真夏 @orumin そういえば speedtest.net って Linux の CLI client もありますね。

ってことでLinuxのcliで動くPython製のspeedtest-cliをちょっと試してみた.

speedtest.netでの回線速度計測をcliで行えます.python製でpipとかで各種環境に導入可能.

Debianだとjessie以降all, Ubuntuだと16.04LTS以降allにpkgもあるのでapt一発で入るし,Raspberry PiなどのARMアーキテクチャなんかでも問題なく動きました.

規定値の動作はipからロケーション拾ってそこから近いサーバーで計測した結果を返すようです.
自宅のipアドレスでの自動判定では静岡になってたので手動で計測サーバを変更して鹿児島と東京を試しました.

help

$ speedtest-cli -h
usage: speedtest-cli [-h] [--bytes] [--share] [--simple] [--list]
[--server SERVER] [--mini MINI] [--source SOURCE]
[--timeout TIMEOUT] [--secure] [--version]

Command line interface for testing internet bandwidth using speedtest.net.
--------------------------------------------------------------------------
https://github.com/sivel/speedtest-cli

optional arguments:
-h, --help show this help message and exit
--bytes Display values in bytes instead of bits. Does not affect
the image generated by --share
--share Generate and provide a URL to the speedtest.net share
results image
--simple Suppress verbose output, only show basic information
--list Display a list of speedtest.net servers sorted by
distance
--server SERVER Specify a server ID to test against
--mini MINI URL of the Speedtest Mini server
--source SOURCE Source IP address to bind to
--timeout TIMEOUT HTTP timeout in seconds. Default 10
--secure Use HTTPS instead of HTTP when communicating with
speedtest.net operated servers
--version Show the version number and exit

規定値では自宅は静岡になっていて静岡サーバで計測する(実際は鹿児島)

$ speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from FreeBit (180.131.110.140)...
Selecting best server based on latency...
Hosted by ClickL Network (Shizuoka) [0.02 km]: 110.464 ms
Testing download speed........................................
Download: 2.07 Mbit/s
Testing upload speed..................................................
Upload: 0.92 Mbit/s

日本のサーバを確認する

$ speedtest-cli --list|grep -i japan
14180) ClickL Network (Shizuoka, Japan) [0.02 km]
8407) Allied Telesis Capital Corporation (Sagamihara, Japan) [111.58 km]
6087) Allied Telesis Capital Corporation (Fussa-shi, Japan) [120.41 km]
6508) at2wn (Yokohama, Japan) [125.30 km]
7510) ASEINet (Tokyo, Japan) [141.71 km]
12546) TB (Tokyo, Japan) [141.71 km]
12511) h3zjp (Nerima, Japan) [142.66 km]
8348) Foxcore-LS (Sodegaura, Japan) [167.71 km]
7139) SoftEther Corporation (Tsukuba, Japan) [192.41 km]
6368) gatolabo (Maibara, Japan) [194.62 km]
6766) JAIST(ino-lab) (Nomi, Japan) [232.28 km]
13641) NextechNetworkSolutions (Nara, Japan) [237.53 km]
6476) rxy (individual) (Osaka, Japan) [264.80 km]
8832) prize3046 (Ikeda, Japan) [269.86 km]
8193) kamiari (Sendai, Japan) [427.67 km]
7976) denpa893 (Hikari, Japan) [601.03 km]
6405) Allied Telesis Capital Corporation (Misawa, Japan) [686.38 km]
13568) KSL (Kagoshima, Japan) [820.38 km]
811) GLBB Japan KK (Chatan, Japan) [1397.84 km]
6581) haza (Haebaru, Japan) [1410.56 km]

鹿児島サーバで計測してみる

$ speedtest-cli --server 13568
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from FreeBit (180.131.110.140)...
Hosted by KSL (Kagoshima) [820.38 km]: 103.499 ms
Testing download speed........................................
Download: 2.20 Mbit/s
Testing upload speed..................................................
Upload: 0.92 Mbit/s

東京を–simple optionで計測してみる

$ speedtest-cli --simple --server 7510
Ping: 150.627 ms
Download: 1.88 Mbit/s
Upload: 0.84 Mbit/s

サーバの数を確認してみる

$ speedtest-cli --list | wc -l
6509

speedtestはJavaScriptやAdobe Flashが必要なことが多くてヘッドレス環境などでは面倒でした.
iperfやnetcatなんかはお手軽ですが,速度テスト先のサーバの用意が必要です.

今回のspeedtest-cliはお手軽に導入できて世界各地のサーバ相手にcliでspeed testも出来ていい感じです.

ディスクイメージのデバイスマップが簡単に作れるkpartxを試す

以下のページでkpartxというディスクのデバイスマップを作るコマンドがあるのを知りました

そこでまず、kpartxを使って各パーティションのデバイスマップを作ります。
$ sudo /sbin/kpartx -av /opt/atde3-20100309.img
add map loop2p1 : 0 497952 linear /dev/loop2 63
add map loop2p2 : 0 33045705 linear /dev/loop2 498015
$ ls /dev/mapper/
control loop2p1 loop2p2
これでディスクイメージの各物理パーティションに対応したデバイスマップができました。fdiskで見えていたパーティションはそれぞれ、/dev/mapper/loop2p1 /dev/mapper/loop2p2 として参照できるようになっています。

これまでは以下のページのようにfdiskコマンドでパーティション情報を確認してmount時にoffsetを指定していました.

kpartxを使うとこの作業が簡単になりそうなので試してみました.

Debian sid amd64ではそのままkpartxパッケージだったのでこれを導入します.(Ubuntu 17.04 amd64でも同様でした.)

$ sudo apt install kpartx

丁度Raspbian jessie 2017-04-10が出たのでこれで試してみます.

$ unzip -l 2017-04-10-raspbian-jessie-lite.zip 
Archive:  2017-04-10-raspbian-jessie-lite.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
1297862656  2017-04-10 18:58   2017-04-10-raspbian-jessie-lite.img
---------                     -------
1297862656                     1 file
$ time unzip 2017-04-10-raspbian-jessie-lite.zip
Archive:  2017-04-10-raspbian-jessie-lite.zip
  inflating: 2017-04-10-raspbian-jessie-lite.img  

real    2m58.438s
user    0m27.512s
sys     0m2.132s
 sudo /sbin/kpartx -av 2017-04-10-raspbian-jessie-lite.img
add map loop0p1 (254:3): 0 83968 linear 7:0 8192
add map loop0p2 (254:4): 0 2442728 linear 7:0 92160
$ ls -lA /dev/mapper/
合計 0
crw------- 1 root root 10, 236  4月 11 23:37 control
lrwxrwxrwx 1 root root       7  4月 12 06:07 loop0p1 -> ../dm-3
lrwxrwxrwx 1 root root       7  4月 12 06:07 loop0p2 -> ../dm-4
lrwxrwxrwx 1 root root       7  4月 11 23:37 sda3_crypt -> ../dm-0
lrwxrwxrwx 1 root root       7  4月 11 23:37 x220--vg-root -> ../dm-1
lrwxrwxrwx 1 root root       7  4月 11 23:37 x220--vg-swap_1 -> ../dm-2

デバイスマッピングされています.これで簡単にmount出来ました.

$ sudo mount -o ro /dev/mapper/loop0p1 /media/mk/pi-boot
$ sudo mount -o ro /dev/mapper/loop0p2 /media/mk/pi-root/
$ mount | grep /dev/mapper/loop0p
/dev/mapper/loop0p1 on /media/mk/pi-boot type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mapper/loop0p2 on /media/mk/pi-root type ext4 (ro,relatime,data=ordered)
$ ls /media/mk/pi-boot
COPYING.linux     bcm2708-rpi-0-w.dtb     bcm2708-rpi-cm.dtb   bcm2710-rpi-cm3.dtb  config.txt    fixup_db.dat  kernel.img   start.elf     start_x.elf
LICENCE.broadcom  bcm2708-rpi-b-plus.dtb  bcm2709-rpi-2-b.dtb  bootcode.bin         fixup.dat     fixup_x.dat   kernel7.img  start_cd.elf
LICENSE.oracle    bcm2708-rpi-b.dtb       bcm2710-rpi-3-b.dtb  cmdline.txt          fixup_cd.dat  issue.txt     overlays     start_db.elf
$ ls /media/mk/pi-root
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

そしてchrootしてみたり

$ sudo mount -o remount,rw /media/mk/pi-root
$ sudo cp -p /usr/bin/qemu-arm-static /media/mk/pi-root/usr/bin
$ sudo chroot /media/mk/pi-root/ /bin/bash
# dpkg --get-selections "*" | wc -l
427

アンマウントして元に戻します.

# exit
$ sudo umount /media/mk/pi-*
$ sudo kpartx -d /dev/mapper/loop0p1
$ sudo kpartx -d /dev/mapper/loop0p2
$ rm ./2017-04-10-raspbian-jessie-lite.img

便利ですね :)
後は圧縮ファイルをそのまま使えると便利なんですがムリカナ?

OsMoのTripページからGPXを入手するメモ

土日に撮った写真にジオタグをつけようとそのときロギングしていたGPSのログを吸い出そうとしたら見当たりません.GPSロガーの設定がいつの間にかログを保存しない設定になっていました.ボタン部分のゴム部分に穴が開いてしまって防水ではなくなったので土曜の雨の時カバンに入れていたのでそのときにキーロックし忘れて設定が変わったのかもしれません.

AndroidスマホでOsMoDroidも動作させていたのでこれがログを残していないかと見てみると古いものしかありません.

$ jmtpfs android/
$ ls -ltrA android/内部ストレージ/OsMoDroid | tail -1
-rw-r--r--  1 mk mk  803382  2月 25 21:35 20170225070457.gpx
$ find android -iname "*osmo*"
android/内部ストレージ/osmand/tracks/osmo
android/内部ストレージ/OsMoDroid
android/SDカード/Android/obb/net.osmand.plus/tracks/osmo
$ ls -ltrA android/内部ストレージ/OsMoDroid/ | tail -1
-rw-r--r-- 1 mk mk  803382  2月 25 21:35 20170225070457.gpx

自動的に生成されるTripページにルートが表示されるのでこれが取得できないかソースを見てみました.

それっぽいURLをこんな感じで抜き出して,

$ w3m -dump_source 'https://osmo.mobi/h/d8VhsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF' | sed -n "s/^.*getJSON('\([^']*\)'.*$/\1/p"
https://api.osmo.mobi/session_get?url=d8VhsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF&mode=

そのurlの中を見るとJSONでGPXの項目があるのでjqで抜き出す

$ w3m -dump_source 'https://osmo.mobi/h/d8VhsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF' | sed -n "s/^.*getJSON('\([^']*\)'.*$/\1/p" | jq -r .gpx
https://st.osmo.mobi/htg/d/8/V/hsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF.gpx

これをDLするとGPXだった.

$ wget https://st.osmo.mobi/htg/d/8/V/hsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF.gpx

繋げるとこんな感じ

$ w3m -dump_source 'https://osmo.mobi/h/d8VhsthhuF9rpEDUCNXjOhHxJHdmiNQNRsoR4AEmpF' | sed -n "s/^.*getJSON('\([^']*\)'.*$/\1/p" | xargs w3m -dump_source | jq -r .gpx | wget -i -

GPX Viewerで開こうとするとファイルオープン画面から帰ってこなかったですが,GpsPruneだと開けました.ちょっと荒いけど無いよりは全然いいですね.

20170411_01:04:30-17480

etckeeperのmanに載っているREADMEを読もうと思ったら無い

Debian sid amd64のetckeeperのmanに載っているREADMEを読もうと思ったらそんなファイルは無い.

$ man etckeeper | grep -B1 README
SEE ALSO
       /usr/share/doc/etckeeper/README.md.gz
$ lv /usr/share/doc/etckeeper/README.md.gz
/usr/share/doc/etckeeper/README.md.gz: No such file or directory
$ ls -lA /usr/share/doc/etckeeper/
合計 40
-rw-r--r-- 1 root root  4679  7月 18  2016 README.mdwn.gz
-rw-r--r-- 1 root root 11645  8月  2  2016 changelog.Debian.gz
-rw-r--r-- 1 root root  1785  7月 18  2016 copyright
-rw-r--r-- 1 root root   948  7月 18  2016 index.mdwn
-rw-r--r-- 1 root root   483  7月 18  2016 install.mdwn
-rw-r--r-- 1 root root    55  7月 18  2016 news.mdwn
-rw-r--r-- 1 root root   309  7月 18  2016 todo.mdwn
$ dpkg -L etckeeper | grep README
/etc/etckeeper/commit.d/README
/etc/etckeeper/init.d/README
/etc/etckeeper/post-install.d/README
/etc/etckeeper/pre-commit.d/README
/etc/etckeeper/pre-install.d/README
/etc/etckeeper/unclean.d/README
/etc/etckeeper/uninit.d/README
/etc/etckeeper/update-ignore.d/README
/usr/share/doc/etckeeper/README.mdwn.gz
$ dpkg-query -W etckeeper
etckeeper       1.18.5-1

/usr/share/doc/etckeeper/README.mdwn.gzが内容からしてそれぽい.
バグぽいので報告しようかと思って既存のバグを眺めると既に報告されて上流で修正済みのようでした.