ラベル workaround の投稿を表示しています。 すべての投稿を表示
ラベル workaround の投稿を表示しています。 すべての投稿を表示

2020年7月20日月曜日

Debian SidのMercurialがPython 3へ移行したためinfo.pyに異常が出た (workaroundあり)

Debian SidのMercurialが5.4.1→5.4.2にupgradeされた。このversionでは(Mercurialが依存する) Pythonが2.7→3へ変更された。

この影響で、Mercurialのextensionとして導入しているinfo.pyの実行に不具合が発生した:

> % hg st .
> *** failed to import extension info from ~/.hg.d/info.py: unicode 'info' found in cmdtable
> *** (use b'' to make it byte string)
> ...

info.pyを読み込む際にerrorが発生してimportに失敗している。`bytes`を想定している`cmdtable`内にUnicodeとして認識されたstringが混入したため。

Workaroundとして、「`b''`を使って (explicit type conversionして)ね!」というerror messageに従い、info.pyにて:

> - @command('info')
> + @command(b'info')

の変更を行い解決した。


Python 3.xでのstrとbytesについて


Python 3では`str`がUnicodeへ変更された (Unicodeが`str`になった)一方で、Mercurial (のAPI)は`bytes`を想定している。Python 3は (Python 2 seriesのような)`str` (Unicode)と`bytes`のimplicit type conversionを行わないので、このような事例はerrorとして検出される。

以下、Python 3.8.4のdocumentationより引用:

Note
 
For Python 2.x users: In the Python 2.x series, a variety of implicit conversions between 8-bit strings (the closest thing 2.x offers to a built-in binary data type) and Unicode strings were permitted. This was a backwards compatibility workaround to account for the fact that Python originally only supported 8-bit text, and Unicode text was a later addition. In Python 3.x, those implicit conversions are gone - conversions between 8-bit binary data and Unicode text must be explicit, and bytes and string objects will always compare unequal.

cf. [Built-in Types — Python 3.8.4 documentation](https://docs.python.org/3/library/stdtypes.html#bytes)

(要約)

Python 2.xまでは色々な過去の経緯もあってUnicode文字列と8bit文字列の暗黙的な変換が横行していた。Python 3.xからは一切暗黙的に変換しないのでプログラマは明示的に変換する必要がある。`str`と`bytes`の比較は常に等しくない。


2019年12月1日日曜日

VirtualBox 6.0.14のdkmsがLinux kernel 5.4の仕様変更でbuildできない (VBox 6.1で対応)

*** update ***

2020-01-21更新: Linux kernel 5.4.13 (1/21現在5.4.x系列の最新版)を試している。既にVBox側で対応済みなため、特に問題なくkernel modulesをbuild、使用できている。

*** updateここまで ***


Linux kernel 5.4からset_pages_x()とset_pages_nx()というfunctionsが削除された。

Debian unstableに入っているVirtualBox 6.0.14はこの変更に対応しておらず、現状ではkernel moduleがbuildできずにerrorになる。

VBoxのdevelopersは既に対応するpatchを作製済みで、6.1RC1としてreleaseしている (cf. [#18945 (Linux 5.4: no more arbitrary executable pages and more changes) – Oracle VM VirtualBox](https://www.virtualbox.org/ticket/18945))。

何れDebian unstableかexperimentalに入るだろう。 2020-01-21現在sidに6.1が入っている。

Linux kernel 5.4 seriesにはi915でgpu resetがtimeoutしてin-flight renderingが止まる問題もあるので、当面は5.3で運用する予定。 2020-01-21現在、5.4.13で特に問題がなさそうなのでこのまま移行できそう。

2019年8月31日土曜日

yascrollがemacsの仕様変更で動かなくなったので修正してみた

yascrollが動かなくなっていることに今頃気付いた。

試しに M-x yascroll:show-scroll-bar を実行してみると:
Wrong number of arguments: (left-width right-width outside-margins), 4
なるerror messageが返って来る。どうやらEmacs側の仕様変更があった模様。

git logで調べてみるとこれだった:
commit 8e0ebb9a3cb9beef2f5ff50436fef1c54a3e3c92
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Mon Jul 22 09:19:18 2019 +0200
    Handle persistence of windows' scroll bar and fringes settings (Bug#36193)
src/window.cに含まれるwindow-fringesというCで書かれたfunctionは、これまで指定された (Emacsにおける) windowのleft-widgh, right-width, outside-marginsの3つのparametersを返していた。

このcommitで加えられた変更により、新たに4つ目のpersistentというparameterが追加された。これがyascrollの側でparametersの数が合わないというerrorの原因となっていた。

なお、window-fringesの詳細はEmacsからF1 helpで参照できる:
window-fringes is a built-in function in ‘C source code’.
(window-fringes &optional WINDOW)
  Probably introduced at or before Emacs version 22.1.
  This function does not change global state, including the match data.
Return fringe settings for specified WINDOW.
WINDOW must be a live window and defaults to the selected one.
Value is a list of the form (LEFT-WIDTH RIGHT-WIDTH OUTSIDE-MARGINS
PERSISTENT), see ‘set-window-fringes’.
さて、実際にerrorを起こしていたのはyascroll.el内に定義されたyascroll:choose-scroll-barである:
(defun yascroll:choose-scroll-bar ()
  (when (memq window-system yascroll:enabled-window-systems)
    (cl-destructuring-bind (left-width right-width outside-margins)
        (window-fringes)
      (cl-loop for scroll-bar in (yascroll:listify yascroll:scroll-bar)
               if (or (eq scroll-bar 'text-area)
                      (and (eq scroll-bar 'left-fringe)
                           (> left-width 0))
                      (and (eq scroll-bar 'right-fringe)
                           (> right-width 0)))
               return scroll-bar))))
left-width, right-width, outside-marginesの3つがcl-destructuring-bindに指定されているため、新たに4つ目のpersistentを返すようになったwindow-fringesと不整合を起こした。

解決方法は簡単で、
(cl-destructuring-bind (left-width right-width outside-margins persistent)
のように適当な名前のvariableを追加すれば良い (なお、このvariableは使われない)。

fileを修正したら、M-x byte-recompile-fileなどでyascroll.elcを再生成し、el-get-reload (他お好みのpackage management systemの作法)でyascrollをreloadする。

2019年5月5日日曜日

Firefoxのaddonが証明書の期限切れで使えなくなった問題に対するworkaround

5/5現在、徐々に回復してきているらしいが、引き続き自分の環境はaddonがinstallできない状態は継続しているのでそれに対するworkaroundを。

about:config → xpinstall.signature.required を false にする

このworkaroundにより:

* 起動中のFxで突然無効になったaddonが復活する
* 新たにaddonを入れ直す時に「壊れているのでinstallできない」問題が解決

本質的にはsignatureが正しいものに更新されるのを待つ。修正されたら再びxpinstall.signature.requiredをtrueに戻す方が良いだろう。

なお、動作を確認したのは:

* Mozilla Firefox 68.0a1 (Nightly) @Linux
* Mozilla Firefox 60.6.1esr (ESR) @Linux

という、多数派ではない環境なので留意されたい。

2019年1月20日日曜日

emacsに-rvをつけて起動すると"invalid face: tooltip"を吐いて死ぬ

emacs-git (commit 551051596fe51d6e232315eeda8a0a79eb43bfdf)をsourceからbuildした後、早速立ち上げようとしたら:

% emacs -rv
invalid face: tooltip

……255を返して死んでしまった。

取り敢えずstraceでも見るか、と思い:

% strace emacs

は普通に立ち上がる (ただし-rvじゃないので真っ白なbgで)。

どうやら-rvをつけた時に立ち上がらないらしい。

問題が設定にあるのかemacs側にあるのか切り分けてすらいないので正確な原因は不明だが、取り敢えずこのままでは見た目が慣れないことこの上ないので、color themeを入れることにした。

el-get installでcolor-themeをinstallし、color-theme-clarityを採用。

White on black color theme by Richard Wellum, created 2003-01-16.

とのこと。何となく選んだ一発目で慣れた配色を引いた。

図1: color-theme-clarity (w/ transparent)

update-grubが"grub-probe: error: failed to get canonical path of ..."を吐いて失敗した原因と対策

Main machineではLinux kernel image (linux-image)を自前でbuildしているのだが、その際不要になった古いpackageの削除が失敗した。原因はlinux-image packageのpostrm scriptにhookされているupdate-grubが:

grub-probe: error: failed to get canonical path of sdb5_crypt

を吐いて失敗したことによる。なお、sdb5_cryptはLUKSでencryptしているpartitionであって、環境に依存して名前が変化する。

ちなみに、なぜlinux-imageの削除にupdate-grubがhookされているのかというと、linux-imageが削除されるとそのversionのkernelはもはや存在せずbootできないので、update-grubを実行してboot menu (/boot/grub/grub.cfg)をupdateする必要があるからだ。

最も簡単なworkaroundは、/dev/mapper/sdb5_cryptが存在しないので、これを作り直してやること。

sudo ln -s /dev/dm-0 /dev/mapper/sdb5_crypt

以前存在していた/dev/mapper/sdb5_cryptがなぜ無くなったのかについては不明だが、Linux kernelのupdate (4.19.11 → 4.20)、systemdのupdate、sysvinit → systemdへの変更、など幾つかの要因が考えられる。


2018年11月24日土曜日

Debian packageのinstall/uninstall processが失敗した時に手動でどうにかする方法

Debian packageのinstall/uninstall processの実体は、packageに含まれている幾つかのshell scriptである。

これらは/var/lib/dpkg/info/以下に展開されており、例としてx11-utils packageについてのfilesは、

x11-utils.conffiles
x11-utils.list
x11-utils.md5sums
x11-utils.postinst
x11-utils.postrm

がある。このうち、scriptが.postinstと.postrmの2つで、名前の通りそれぞれinstall後及びuninstall後に実行される内容が記述されている。

何かしらの要因でinstall scriptに不具合が発生してinstall processが失敗する時 (unstableでは時々ある)は、ここを直接修正すれば中途半端な状態を解消できる可能性がある。

最近では、iptables packageのpostinst scriptにinstall (upgrade)が失敗する不具合があった (2018-11-24現在修正済み)。この場合は、/var/lib/dpkg/info/iptables.postinstを手動で修正してaptitudeなどからupgradeをやり直した。

cf. [#913811 - iptables fails to upgrade from 1.8.1-2 to 1.8.2-1 - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913811)

2018年10月21日日曜日

Debian sidでnfsdが立ち上がらなくなったのでscriptを修正 (sysvinit)

*** 注意 ***

Debianはinit daemonとしてsystemdを採用している。

個人的な趣味から今回の問題が起きたPCではsystemdを入れていない (sysvinitで運用)。おそらく、maintenanceされていないsysvinit用のscriptが原因でこのような問題が発生したと考える。

よって、普通にsystemdを使っているuserにはaffectしない。

*** 注意ここまで ***


大容量HDDを搭載したPCでnfsdを立ち上げて、LAN内にあるPCからNFSv4でmountできるようにしてあるのだが、kernelのupgrade後にmountできなくなった。

Debianでは、NFSの機能がnfs-commonとnfs-kernel-serverに分割されている。このうちnfs-commonの方は問題なかった。

一方、nfsdが立ち上がっていないし、以下のようなmessageも出るので、nfs-kerrnel-server側のscript内でerrorが発生しているとわかった。

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd
[warn] Not starting: portmapper is not running ... (warning).

script (/etc/init.d/nfs-kernel-server)を眺めてみると、92-99行にportmapperがどうのというwarningを出力する箇所で、rpcinfoというcommandへのpathが$PREFIX/sbin/rpcinfoとなっている:

        # See if rpcbind is running
        $PREFIX/bin/rpcinfo -p >/dev/null 2>&1
        RET=$?
        if [ $RET != 0 ]; then
            echo
            log_warning_msg "Not starting: portmapper is not running"
            exit 0
        fi

rpcinfoのreturn valueがnon zeroなのでifに引っ掛かってexit 0している訳だ。

rpcinfoがどういう出力なのか確かめてみようと打ってみる:

% sudo /usr/sbin/rpcinfo -p
sudo: /usr/sbin/rpcinfo: command not found

/usr/sbin/rpcinfoが存在しない。では、rpcinfoがどのpackageに含まれているのか (あるいは存在しないのか)調べてみる:

% dpkg -S rpcinfo
rpcbind: /usr/bin/rpcinfo
nmap-common: /usr/share/nmap/scripts/rpcinfo.nse
rpcbind: /usr/share/man/man8/rpcinfo.8.gz

sbinじゃなくてbinになっている。移動したようだ。では改めて:

% /usr/bin/rpcinfo -p                                         
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  57281  status
    100024    1   tcp  59599  status
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049
    100003    3   udp   2049  nfs
    100227    3   udp   2049
    100021    1   udp  49265  nlockmgr
    100021    3   udp  49265  nlockmgr
    100021    4   udp  49265  nlockmgr
    100021    1   tcp  33993  nlockmgr
    100021    3   tcp  33993  nlockmgr
    100021    4   tcp  33993  nlockmgr
    100005    1   udp  49349  mountd
    100005    1   tcp  53921  mountd
    100005    2   udp  60977  mountd
    100005    2   tcp  32831  mountd
    100005    3   udp  52847  mountd
    100005    3   tcp  49695  mountd

scriptではrpcinfoの実行結果 (というか出力は/dev/nullに棄てて、return valueだけを見て)からportmapperがsupportされているかどうかを確認していた。この出力を見る限り、portmapperはsupportされていると分かる。

scriptの当該箇所を修正 ($PREFIX/sbin/rpcinfo → $PREFIX/bin/rpcinfo) して、改めて試してみる:

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd mountdrpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
. ok 

ここでtcp6やudp6に関するerror或いはwarningが出ているのは、IPv6を使ってないのでkernel levelでsupportを切っているため。明示的に使っていなくても切らない方がいいのかも知れない。或いは、/etc/netconfigのtcp6とudp6の行をcomment outする手もある。

何れにしてもnfsdが立ち上がるようになり、NFS clientからもmountできるようになった。

今回このような問題が発生したのは、Debianではinit daemonがsystemdに変更されたため、sysvinitに由来するscriptが既にmaintenanceされていないからと考えられる。


2018年10月19日金曜日

Debian packageのdependencyをごまかして (強制的に) installする方法

*** 更新情報 ***

2018-10-22現在、Debian sidにおけるcalibreの最新版はqtbase-abi-5-11-2へ対応したversionへ更新されたので、以下の不整合は発生しない。

*** 更新情報ここまで ***


calibreというebook readerがある。

読むだけではなく、formatの変換なども行える (swiss army knife的に)多機能なsoftwareで、個人的に使えないと非常に困るのだが、先にupdateされるQt libraryへのdependencyで不整合を起こしuninstallされ (かけ)ることがままある。

最近も、Qt relatedなpackagesが更新されて、これらが提供するvirtual packageであるqtbase-abi-5-11-0がqtbase-abi-5-11-2へ上がった。calibreの実体programを提供するpackageであるcalibre-bin 3.32.0_dfsg-1+b1はqtbase-abi-5-11-0にdependしているため不整合を起こしてuninstallされかけた。

calibreを新しいQtとlinkしてbuildした上でcontrolを修正するのが最も真っ当な方法だが、たかが5.11.0 → 5.11.2の変化ならどうにかなるだろう、という根拠のない推測からdependencyをごまかしてuninstallされないようにした。実際、calibreは無事立ち上がり、特に問題なく動作しているので、ひとまずこの状態で使ってみる。

無論、ABIのversionが変わっている以上互換性は保証されず、強制的にinstallしても動作しなかったり、意図しない動作になったりする可能性があるので注意。

やり方の概要


以前にも同じようなことをした記憶があったので検索してみた所、

cf. https://typeinf-memo.blogspot.com/2015/08/debian-unstable-sidexperimental.html

に似たような記事を書いていた。

前回はcontrolから不要なdependencyを削除していたが、今回もやることは余り変わらない (今回はversionを書き換えるだけ)。

* binary packageをdownloadして展開
* control.tar.xzを展開してcontrolを書き換える
* 改編したcontrolを含むcontrol.tar.xzを生成
* 変更したcontrol.tar.xzを含むbinary packageを生成
* installして動作確認

具体的な手順


* calibre-binのbinary packageをdownload

% apt-get download calibre-bin

* arでbinary packageを展開

% ar x calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

control.tar.xz、data.tar.xz、debian-binaryが生成される。

* control.tar.xzを展開

% tar xJf control.tar.xz

control、md5sumsが生成される

* 適当なtext editor (vimなど)でcontrolを書き換える。今回の場合"qtbase-abi-5-11-0"を"qtbase-abi-5-11-2"へ書き換えて保存する

* 書き換えたcontrolを含むcontrol.tar.xzを作る

% tar --create --file control.tar.xz --xz md5sums control

* 作り直したcontrol.tar.xzを含むbinary packageを生成する

% ar rcs calibre-bin_3.32.0_dfsg-1+b1_amd64.deb debian-binary control.tar.xz data.tar.xz

* dpkg -iでinstallし動作確認

% sudo dpkg -i calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

* aptitudeなどを使っている場合はupdateによる書き換えを防ぐためにcalibre-binをholdしておくとよい

おつかれさまでした。

2018年9月15日土曜日

SwissMicros DM42のUSB関連のtrouble (2018-10-15更新, v3.11で解消)

(更新記録)

* 2018-10-15 firmware v3.11で当問題が解決されたのでupdateを推奨 cf. https://typeinf-memo.blogspot.com/2018/10/swissmicros-dm42firmwarev311usbfreeze.html
* 2018-09-18 画像を追加

(更新記録は以上)

Firmware v3.7あたりにupgradeしてから、DM42にUSB cableを接続すると次のようなerrorが出てfreezeするようになった:

ErrSrc/main.c:867
Err:main.c:867
Err:SetFreq 2
ERROR: 0777
Desc:SetFreq 2

このため、firmwareのupgradeができない、FAT diskへのaccessができない状態。

SwissMicrosのforumには既に報告されている cf. [Bug when connecting the USB cable - www.SwissMicros.com](https://forum.swissmicros.com/viewtopic.php?t=1922)が、まだ完全に解決された訳ではないようだ。なお、全てのDM42で発現する訳ではなく、稀らしい……。

この状態でもPGMとRESETの2つのhardware buttonsを使ってbootloader modeにした後、USB cableを接続したPCからdfu-utilを実行してfirmwareをupgradeできる:

Bootloader mode can be activated from main Setup menu: System > Bootloader or by resetting the calculator using RESET button while PGM button is pressed too.

To be more precise, the sequence of entering bootloader mode using RESET and PGM button is: - press and hold PGM button - press and release the RESET button - release the PGM button
cf. [DM42 User Manual](https://www.swissmicros.com/dm42/doc/dm42_user_manual/#bootloader_mode_activation)

手順


* 2本のネジ (図1の緑色の矢印)を取って裏蓋を外す → 下部にツメがあるので、USB connector等がある上の方 (LCDがある方)から外す。隙間にテレカのような薄いプラスチックを挟んで開けるのがお勧め
* PCB上にRESET buttonとPGM buttonがある → 裏蓋をつけたままだとRESETのみaccessible (図1の赤色の矢印)


図1 DM42背面
図2 裏蓋を外した様子 (左側が本体、右側がカバー)

図3 PCB拡大 (赤矢印=RESET, 黄矢印=PGM, 水色矢印=電池, 紫矢印=圧電ブザー)

* PGM (図3の黄色の矢印)を押しながらRESET (図3の赤色の矢印)を押すと強制的にbootloader modeになる → この時画面に変化がないのでmodeに入ったかどうかわかりにくいが、入力を受け付けず画面にも変化がないので判別できる
* USB cableを接続するとPCがDM42を認識するので、予めdownloadしておいたfirmwareをdfu-utilで書き込む cf. https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html (過去記事)
* 終了したらRESET buttonを押す
* 表示される"About"でfirmwareのversionを確認する
* 裏蓋を戻してネジをしめる

結果とworkaround


この方法で無事v3.9.1 (2018-09-15現在の最新版)にupgradeできたが、USB cableを接続すると依然errorが表示されfreezeする。

workaroundとしては、

* USBへ接続せずに普通に使い続ける
* v3.5にdowngradeする

の2つがある。

v3.11へのupdateを行うと解決する。

2017年12月3日日曜日

Waterfoxでkeysnailの調子が悪かったので修正した

Waterfoxをupgradeした所、KeySnailの調子が悪くなったので原因を探ってみた。

症状


* KeySnailが有効になっているのにkeybindsが反応しない
* tanything (KeySnail pluginの一つ)が反応しない
* 一部の機能は動くが"C-g" (cancel)でwindowが消えない

原因と解消法


Waterfoxの最近の更新でdefaultの設定値が変わったのが原因のようだ。

* extensions.e10sBlocksEnablingをfalse → true
* extensions.e10sMultiBlocksEnablingをfalse → true

へ変更してrestartした結果、正常動作するようになった。

発見までの道程


* "Add-ons" (about:addons)の画面を眺めていた所、multiprocessがonになっていることに気付く
* about:configでe10s関連の設定値を眺めて、怪しそうな所を取り敢えず変えてみた → うまくいった

2017年8月10日木曜日

fcitx-skkのローマ字かな変換テーブルを改造する

fcitx-skkを使っていて、個人的に非常に使いづらかった点を修正した:

1. かな入力時に「!」を押した時に全角の「!」が出るようにした
2. かな入力時に「z 」(z+space)で全角スペース「 」を入力できるようにした

特に1.は重要で、「?」は全角なのに「!」は半角というdefaultのちぐはぐな状態は理解し難い。

手順


* 設定をhomedirにcopy
* 設定file (default.json)を修正
* fcitx-skkの設定を更新

設定例


~/.config/libskk/rules/以下に適当な名前 (MyRuleでもMyDefaultでも何でも良い)で設定をcopyする

 % cp -R /usr/share/libskk/rules/default/ ~/.config/libskk/rules/MyRule

お気に入りのtext editor (例ではvim)でdefault.jsonを修正する

 % vim ~/.config/libskk/rules/MyRule/rom-kana/default.json

ずらずらと並んでいるので、適当な場所に設定を追加したり、既存の設定を書き換える:
...
"z ": ["", " "],
...
"!": ["", "!" ],
...

前述の通り、"!"に関しては半角の"!"から全角の"!"へ変更した。

fcitx-skkの設定を更新するには、fcitx-configtoolをterminal emulatorから叩いて実行するか、window manager (今時はdesktop environmentかな)の設定menuの何処かにそれっぽいものがある (と思う)。

configtoolにて:

* SKKを選択して設定ボタンを押す → SKKの設定windowが出る
* "Dictionary and Rule" → Dictionary Managerのwindowが出る
* Ruleのdrop-down menuの中に、適当につけた名前 (eg. MyRule)が見付かるので選択
* Windowの下の方にあるsave buttonを押す
* configtoolを閉じる

以上で設定が反映される。

2017年2月27日月曜日

Debian sid/experimentalのgcc-6/gcc-7でLinux kernelがbuildできない問題とその対応

Linux kernel 4.10.1がreleaseされたのでbuildしようとしたら……

>   LD      vmlinux
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x5fa0a): undefined reference to `____ilog2_NaN'
> Makefile:969: recipe for target 'vmlinux' failed
> make[1]: *** [vmlinux] Error 1

つい数日前 (2/20)はbuildできた4.10.0もダメだった (@gcc-6, gcc-7)。

`/var/log/aptitude`を確認してみた所、Sidのgcc-6 (6.3.0-8)を2/22に、experimentalのgcc-7 (7-20170221-1)を2/24にそれぞれ更新していた。

"linux ____ilog2_nan"でGoogle検索したら、次のpageを発見:

詳しくはよく分からないが、Linux kernel内部で利用されている`ilog2()`をcompileする際にGCCのtree-optimizationで問題が発生している模様 (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785)。どうやらkernel側のbugっぽい。

既にworkaroundがあり`include/linux/log2.h`へのpatch (cf. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462224.html)を当てた所buildできた。

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月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の結果なのかは切り分けられなかった。

2015年11月15日日曜日

続・emacs-gitのisearchでmigemoを利用可能にする

今日になって再びisearchでmigemoが使えなくなっていることに気付いた。

以下のcommitが怪しいと踏んだ:


commit 4d82aa3abdad1871b99f0a9e56fe54ec497bd290
Author: Artur Malabarba <bruce.connor.am@gmail.com>
Date:   Tue Nov 10 13:04:02 2015 +0000

    * lisp/isearch.el (search-default-regexp-mode): change default value
*scratch* bufferで:
(setq search-default-regexp-mode nil)
をevaluateしてからC-sでisearchしてみるとmigemoが使える状態に戻った。

2015年8月3日月曜日

Debian unstable (sid)やexperimentalと上手く付き合う方法

はじめに

数日前の更新で、libstdc++6がlibboost-date-time1.55.0とconflictして、それにdependしているlibreoffice-coreがuninstall対象になり、それにdependしているLibreOffice (LO)全体が連鎖的にuninstallされる……という状態に陥った。

Unstableやexperimentalで遊んでいる (desktop目的に常用している)人ならばしょっちゅう遭遇するであろう実に微笑ましい光景である。

丁度LibreOffice 5がexperimentalに入ったみたいなので試してみたいと思ったのだが、それ以前にLO4.xシリーズもこの不具合でuninstallされるのは頂けないので、workaroundでごまかしてみる。

Debian package systemに関する基礎知識

apt-getやaptitudeを用いたpackage管理の仕組みで知るべきことは多くない。

1. それぞれのpackageはdependency (依存関係)を書いたcontrol fileを含む
2. package systemはcontrol fileの内容を見てdependencyを知る

原因と対策

* libreoffice-coreがlibboost-date-time1.55.0にdependしている
* libboost-date-time1.55.0はlibstdc++6により"breaks"に指定されている

つまり、libstdc++6のbreaks指定を削除すればlibboost-date-time1.55.0がuninstallされず、従ってlibreoffice-coreがuninstallされることも、芋蔓式にLO全体がuninstallされることもない。

Debianのpakage managementの仕組み及び原因と対策を踏まえると、次の2つの方法が考えられる。

1. libstdc++6の"Breaks"指定を変更した新しいオレオレpackageを作ってinstall
2. libboost-date-time1.55.0のversionをごまかす (動作するか未確認)

今回は1.の方法を採用した。

workaroundの実態

1. /var/cache/apt/archives/以下からbinary packageを入手し/tmp/以下へcopy
2. dpkg-deb -x <PKG>で中身を展開する。こちらは今回これ以上手を付けない
3. dpkg-deb --controlでcontrol fileがDEBIAN/以下に展開される
4. DEBIAN/controlを適当なtext editorで編集する (今回の場合、Breaks:の行からlibboost-date-time1.55.0を削除し、packageのversionを1上げておく)
5. dpkg -b <DIR> <package.deb>でpackageを作成し、それをinstallする

Unstableやexperimentalとの付き合い方 (まとめ)

* 必要がなければ手を出さない
* そのうち解決されるので気長に待つ or bug reportを出して対策してもらう
* workaroundで一時的にごまかす、凌ぐ

最後に、aptitudeのように強力なdependency解決手段を提供してくれるtoolと仲良くなると幸せになるに違いない。


2015年6月27日土曜日

emacs-gitのisearchでmigemoを利用可能にする

ふと気付いたらisearchでmigemoできなくなっていたので原因を探ってみた。どうやらisearchにcharacter-fold-search (char-fold)が追加されたのが原因らしい。以下のように対策してみた:

  (with-eval-after-load "isearch"
    (setq character-fold-search nil))

とりあえず動くようになったので、しばらくはこれで様子を見てみる。