2017年1月8日日曜日

Debian unstableでFirefox 50.1.1 (release)とFirefox 52.0a2 (aurora)のbuildが失敗する

2017-01-18追記: Firefox 51.0で修正されbuild可能になった

Debian unstableでFxをsourceからbuildするとconfigureの段階で転ける。

cannot determine icu version number from uvernum.h header file

libicu関連。いつからだったのか分からないが、libicuのversion情報が取得できないせい (因みにunstableが57でexperimentalが58。stableは55)。

firefox-release (50.1.1)は56にdependしており、firefox-aurora (52.0a2)は58にdependしている。何れもsystemにinstallされているlibicuを見付けられず、そこでbuildが止まる。

取り敢えずworkaroundを発見したので暫く様子見。

firefox-aurora


experimentalのlibicu58関連にupgrade。libicu57は別の色々なpackagesがdependしているのでそのまま。

build/autoconf/icu.m4を変更 (72行あたり):

    version=`sed -n 's/^[[:space:]]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`



    version="58"

icuのversionを調べるscriptが何故か失敗する (consoleでやると上手くいくのだが)ので、versionを決め打ちする (この場合はexperimentalの58)。

firefox-auroraについてはこれだけでbuildが通る。

firefox-release


firefox-release (50.1.1)は少々面倒:

* build/autoconf/icu.m4を変更 (versionを58で決め打ち)
* cp -i /usr/include/unicode/uvernum.h /usr/include/unicode/uversion.h intl/icu/source/common/unicode/ → localで持っているversionが古いのでsystemのlibicu58を使う (一応のため)
* cp -i /firefox-aurora/config/external/icu/data/icudt58l.dat config/external/icu/data/ → icudt58l.datが無いとbuildが転けるのでauroraの(libicu58用)をcopyしておく

これで取り敢えず./mach buildが通って、./mach runで動いた。ミソは多分icudt58l.datをauroraから貰って来る所だと思う。


2017年1月5日木曜日

Emacsのdiff-modeでauto-refinesの仕様変更とworkaround

diff-modeの移動に関する変更があった後、間も無く別のcommit (e5ef59b87da5c2ddfa22f7342efe29b3eea6ed97)でauto-refinesに関する仕様も変更されていた。

移動が確実に行われた時のみ、細かい変更点 (refines)をcoloringする挙動になった。これに伴いauto-refinesの関連codeが別の場所に移され、以前取った方法では移動するだけではrefinesへのcoloringが適用されなくなった。

対策として、「Emacsのdiff-modeでdiff-hunk-prev/next等の挙動が変更された」で紹介したcodeをベースにして以下のように変更し解決した:

(with-eval-after-load "diff-mode"
  (defun my-diff-hunk-next (&optional count)
    (interactive)
    (diff-hunk-next count nil)
    (diff-refine-hunk))
  (defun my-diff-hunk-prev (&optional count)
    (interactive)
    (diff-hunk-prev count nil)
    (diff-refine-hunk))
  ;; key bindings
  (define-key diff-mode-shared-map "n" 'my-diff-hunk-next)
  (define-key diff-mode-shared-map "p" 'my-diff-hunk-prev))

やっていることは、それぞれのfunction内で移動するためのfunctionを呼び出した後に、coloringする為のdiff-refine-hunkを呼び出すだけである。

2016年12月26日月曜日

helm-recentf-directoriesの修正

(2017-10-04更新) migemoに対応した

(2017-06-14更新) helmのupgradeに伴って(?)不具合が発生したのでcodeを修正。actionの定義が問題を起こしていたので関連部分を削除

helm-recentf-directoriesは、recentf listの中からdirectoriesを抽出し表示するfunction。

http://d.hatena.ne.jp/syohex/20120911/1347378503で紹介されていたcodeを便利に使わせて貰っているのだが、helmの更新で上手く動かない状態になっていた。

helm-imenu.elをベースに、きちんとした方法でsourceを作製する方法へ修正してみた。


(defun helm-recentf-directories-candidates ()
  "Make candidate list of recentf directories."
  (loop for file in recentf-list
when (file-directory-p file)
collect file))

(defclass helm-recentf-directories-source (helm-source-sync)
  ((candidates :initform 'helm-recentf-directories-candidates)
   (keymap :initform helm-find-files-map)
   (migemo :initform t)
   (action :initform 'helm-find-files-actions)))

(defvar helm-source-recentf-directories
  (helm-make-source "Recent Directories"
    'helm-recentf-directories-source))

(defun helm-recentf-directories ()
  "Alternative for helm-recentf that displays only directories."
  (interactive)
  (helm :sources 'helm-source-recentf-directories
:buffer "*helm recentf directories*"))


やっていることは:

* recentf-listからdirectoryな要素を取り出すfunctionを定義
* 以上のfunctionを候補とし、keymapとactionはfind-filesのものを流用したclassを作製
* helm-make-sourceに引き渡しsourceを作製
* sourceを使うfunctionを定義


2016年12月12日月曜日

Emacsのdiff-modeでdiff-hunk-prev/next等の挙動が変更された

diff-hunk-prevやdiff-hunk-nextといった、変更箇所間を移動するfunctionsにおいて、「header直下にあるhunkをskipする」よう挙動が変更された (@ commit 2c8a7e50d24daf19ea7d86f1cfeaa98a41c56085)。

例:

diff-modeで次のような表示があったとする (※1〜※3は場所の明示のためのマーク)

※1 diff --git a/path/to/changed/file b/path/to/changed/file
--- a/path/to/changed/file
+++ b/path/to/changed/file
※2 @@ -343,5 +343,10 @@
...HUNK 1...
※3 @@ -451,1 +451,3 @@
...HUNK 2...


最初のcursor positionが※1の時、従来はdiff-hunk-next ("n")で※2 → ※3と移動していた。しかし、今回の変更により※2は最初のhunkなのでskipされ、いきなり※3に飛んでしまう。

diff-hunk-prevも同じで、header直下のhunkはskipされるのがdefaultの挙動となっている。

何が問題か?


diff-modeで、具体的にどこが変更されたのかをわかりやすくする為に、diff-auto-refine-modeを設定している。これは、wdiffのように文字単位での変更を色付けしてくれるのだが、処理速度の問題からdiff-hunk-prevやdiff-hunk-nextでそのhunkをvisitした際に色付けされる仕組みである。

従って、今回の挙動変更によりheader直下の@@部分へのjumpがskipされると、diff-refine-hunkが適用されずに困る。

解決法

diff-hunk-next, diff-hunk-prevなどのoptional argumentsの一つであるskip-hunk-startにnilを渡して呼び出せば従来の挙動に戻る。

1. lambdaを使う

(with-eval-after-load "diff-mode"
  ;; diff-hunk-next
  (define-key diff-mode-shared-map "n"
    (lambda (&optional count)
      (interactive)
      (diff-hunk-next count nil)))
  ;; diff-hunk-prev
  (define-key diff-mode-shared-map "p"
    (lambda (&optional count)
      (interactive)
      (diff-hunk-prev count nil))))

2. オレオレfunctionを定義しkeybindする

(with-eval-after-load "diff-mode"
  (defun my-diff-hunk-next (&optional count)
    (interactive)
    (diff-hunk-next count nil))
  (defun my-diff-hunk-prev (&optional count)
    (interactive)
    (diff-hunk-prev count nil))
  ;; key bindings
  (define-key diff-mode-shared-map "n" 'my-diff-hunk-next)
  (define-key diff-mode-shared-map "p" 'my-diff-hunk-prev))

3. 気に入らない挙動を修正する

  • adviceを使う?
  • noflet, dfletあたりを使う?

2016年10月23日日曜日

Debian unstableのgcc-6 6.2.0-7以降でLinux kernelなどのbuildができない件への対処 (2016-12-03更新)

Debian unstableのgcc-6は、6.2.0-7から--enable-default-pieというflag付きでbuildされており、これがあちこちで問題を引き起こしている。

cf. https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=gcc-6

影響を受けているのはLinux kernelやSeaBIOSなど。

今の所backoutされる予定はなさそうなので、upstream (kernel側)で対応する迄は以下のworkaroundで我慢するか、自前でgcc-6 (6.2.0-6)をbuildするしかない。

Linux kernelのbuild

(2016-12-03追記)

Linux kernel 4.8.11でDebianのGCCで行われた変更に対応した。よって、それ以降のversionを利用する場合以下のworkaroundは不要。

stack protectorをenableにしていると:

> -fstack-protector not supported by compiler

と出てbuildが止まったり、そうでなくても:

> error: code model kernel does not support PIC mode

と出てbuildが止まったりする。

何れも、KCPPFLAGS=-fno-picをmake-kpkgあたりに渡してbuildするというworkaroundが紹介されている (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841533)。

著者の環境ではworkaroundによりmake-kpkgでkernelがbuildできた。

ccache userへ


FirefoxやEmacsのbuildにも影響が出た。

一旦、ccache -C -zでcacheを破棄してrebuildすると良い。


ZoL (ZFS on Linux)

(2016-10-28追記)

ZoLはkernel modulesとしてbuildする関係から、もろにこの変更の影響を受ける。しかも、KCPPFLAGS=-fno-picを渡しても./configure scriptが途中でコケる。

(2016-12-03追記)

SPLもZFSも正常にbuildできるようになった。

それがGCC側の変更なのか、kernel sourceのupgradeの結果なのかは切り分けられなかった。

2016年10月5日水曜日

PulseAudio w/o systemd

以前、ffmpegでsound cardからのrecordingを取り扱ったが、systemdを排除した場合に変化が生じたのでメモ。

無論、以下のcommand lineで示すのは著者の環境に固有のものである。

以前:

% XDG_RUNTIME_DIR=/run/user/1000 ffmpeg -f pulse -ac 2 -ar 44100 -i alsa_input.pci-0000_00_1f.3.analog-stereo -acodec libvorbis -q 3 output.ogg

以降:

% ffmpeg -f pulse -ac 2 -ar 44100 -i alsa_input.pci-0000_00_1f.3.analog-stereo -acodec libvorbis -q 3 output.ogg

systemdを排除した場合、XDG_RUNTIME_DIRを設定しているpam_systemdも排除されるので、この指定が不要になる。というか/run/userが作られないのでerrorになる。

2016年9月24日土曜日

ZoLでZFSのdiskをmountする

zpool createでpoolを作製すると自動でmountされるが、これをexplicitに行う方法。


  • zfs importでimport可能なpoolを検出
  • zfs import <pool>で実際にimportを行う。このcommandが完了するとmountも行われる