最新 追記

ポケットを空にして。

1985|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2100|01|

「人の心に残るというのが大事」と言う話。

何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
プレゼントは随時受け付けております :-) ここ最近のツッコミ/トラックバックリスト。


2013-03-02 [長年日記] この日を編集

ぱっちノススメ

私はプログラム書くのって、ほとんどできないのですが、パッチを書くぐらいはやってます。一から十まで全部書く必要が無く、修正/追加については、大体前後の類推から「こんな感じかなー」というのができるのがパッチの場合、良い点ですね。

もう一つ、パッチを作るのが楽な場合があって、それは「upstreamが既にgitとかにコミット済みの修正を取ってくる」場合です。もうそこに答えがあるわけですから。

例: security-trackerでDebianで未解決のCVEがあったが、upstream(GNOME)では直していたので、差分取ってきてパッチにしてアップロード、という作業のプロセスを簡単に説明します。

  • まず、security-trackerのunstableのところをみて、直ってないCVEをチェック
  • パッケージのBTSページで状況が変化していないかを確認
  • upstreamのrepositoryとmailing listをあさって状況を確認、対応するコミットを探し出す
  • コミットをローカルのパッケージに当てて dpkg-source --commit でパッチを作る
  • BTSへ上記パッチについて投稿

慣れれば小一時間もあればできます。面倒なのはupstreamの状況を探すところですね。歴史のあるソフトだったりすると、どこが現在使われてるrepositoryだかわからん、みたいな状況があります。自戒自戒。

FLOSS界隈の英語について

日本の人、みんな言うわけです「英語苦手」って。私もそうです。
で、できればもっと貢献できるのになーという方も多いですが、んだったらできそうな人捕まえて「こんなことしたいんだけど」って日本語でコミュニケーションして、相手に「いいね!」してもらって英語で出してもらえばいいんじゃないかなぁ。で、次からはそれをコピペ。相手から英語で質問返ってきたら、翻訳サイトでなんとか意味をつかんでみる。で、自分で考えて文章作ってみる。で、また翻訳サイトで大まかに間違いないかなーと思うところまで直す。で出してみる。失敗したってクビになるわけでも、システム障害起こすわけでも無いんだし、ある程度は開き直りですよ。

自分の話をすれば、英語は高校時代に平均点いかない人で、大学入って勉強するかーと思ってたらいつの間にかもうこんな歳です。まともに語学勉強したことほぼ無いですし、仕事では英語は全く利用しません(DebConfいこう!と思った時、直前に英会話学校は行った)。でもまぁ、見よう見まねすれば、他のところはどうかしりませんが、FLOSS界隈なら何とかなりますよ。大抵の場合相手もnative speakerじゃないので、お互い外国語同士でやりとりするから、細かい間違いは気にしない&もし相手がnativeなら「まぁこいつは英語苦手なんだなー」と思って対応してくれます。

文法の間違いが多い文章よりも、ロジックの間違いがある or 結局論旨がわからない文章の方が問題だと思うので、一度日本語でざざーっと書いてみて誰かに読んでもらうのがいいですよ。恥かいたっていいじゃないの、人間だもの。完璧なコードを書いてからpushしようと思うのが間違いで、とりあえず動くコード出して後からリファクタリング、が正義だと思います。


2013-03-03 [長年日記] この日を編集

net-snmpをexperimentalへdelay/10でアップロードした

うまく行ったとしても、パッケージ名の変更があるので、その後NEW queue待ちになりますが、とりあえずもうputしちゃいました。使ってみたいという方はこちらからどうぞ。

この後の予定はIETFへライセンス変更のお願いとかになるので超ハードル高いです。

dpatch2quilt

dpatchスタイルのパッチをquiltフォーマットに変換するツール。quiltパッケージに入っていた。いつのまに?


2013-03-08 [長年日記] この日を編集

cowbuilderの方がpbuilder+tmpfsより速いのよね

手元のマシンでGNU helloを20回ビルドして計測したら 9m11.320s vs 8m31.191s で cowbuilder の勝ちだった。


2013-03-10 [長年日記] この日を編集

アジャイル開発と劇的ビフォーアフター

夕食時、テレビがついていて劇的ビフォーアフターという番組をやっていた。古くなった家に不満(間取りとか)を抱いている依頼主が匠と呼ばれる建築士に依頼をして、新築しなおす過程を面白おかしく演出し、最後にまっさらになって美しく住みやすくなった家を見て依頼主がビックリ、という話を毎回やっている、ナレーションと音楽もよく耳にする番組だ。
ちょっと前だと「へー」という感じで見ていたのだが、昨今アジャイル関係の書籍を読んだりすることもあり、若干それ迄とは違う方向でこの番組を捉えてしまった(しまった、のである)。

依頼主はPO(プロダクトオーナー)だろう。新しい家がどんな風になってほしいか、こんな生活を夢見ているのだ…という意見を持っている。匠というのは開発チームに属する…のかな?実際の作業する人ではないし、作業者と上下関係があるからピッタリは当てはまらないだろうけど、スクラムマスターとも違う。
…ロールは人によっては若干異論はあろうが、まぁこんなところだろう。

パッと気になったのは以下の点。

  • 新しい家を最後の最後、できた後で依頼主が確認している
  • 「こんな便利な気の利いた機能が!」は依頼主が承認していない

まぁソフトウェアプロダクトと違って、作ってる家を逐次見てどーする、というのはあると思うんだけど、それにしたって最後の最後、もう何も引き返せなくなった時で依頼主が確認するって、ものすごくリスク高いんじゃ…?そこで「全然違う!」って話されても、もう予算も工期もないし、どうしようもない。どれが重要でどれを省くのか、って確認をしつつ進む部分が無いのは怖い。

それから「気の利いた機能」は、正直作り手の自己満足である可能性が非常に高いように見える。「こうすれば、ほら机にも変わりますよー」とかいう便利機能、本当に使うの?というと日々の生活の中では使わずに埋没する可能性が多いのでは?という疑問。そして「この機能作らなかったら20万費用削減できますよー」とか言われたら「じゃ削って」とかなる可能性があるわけで、確認は必要なんじゃないのかなぁ…(逆に「20万でこんなことできるの?じゃ、やって!」となる可能性もある)

「そこはそれ、番組の演出ってやつよ」というのであれば、良いのだけど、そうでなかったらかなり高リスクな話では…と感じた、とさ。


2013-03-12 [長年日記] この日を編集

日経Linux2013年4月号でざっと見で目についた問題点

追記注:既に5月号に訂正が載っているようです。

まとめておいた方が親切だよね、ということで。

  • Ubuntuをデスクトップとして扱っている記事で、パッケージを毎回ターミナル(端末)から入れさせようとするのは良くない。まずはソフトウェアセンターを使うのが一般ユーザー向けには適している
  • みかちゃんフォントをインストールする、というので、パッケージが存在しているのにわざわざtarballをダウンロードさせてコピーさせてる。理由がわからない。該当パッケージをメンテしている人間としては、パッケージの存在意義を否定されているようで悲しい。(以前もEclipseの導入でPleiadesをzipで落として入れてたのがあった記憶が…これも同様)。
    追記: multiverse だから、かなぁ。でもそれでもパッケージをダウンロードする、というのは無いのかねぇ?
  • Debian GNU/Linuxって必ず書いてるようなんですが、これは逆に「Debian」とだけ書くのはありなんですよね。Debian Linuxという書き方が×(最初期以外はこの呼び方しない)。
  • 古いPCの再生記事でDebianとLubuntu入れてたのだが、Debianを標準のGNOMEで入れたら重くなっちゃうんじゃ…xfceかlxdeで入れるのが比較として正当だと思う。読者を誤った方向に導いているように見える(「軽量な環境」を入れるという目標で、GNOMEをあえて入れるのであれば、その理由ぐらいは言及すべき)。
  • Debianの解説で「フリーソフトで構成される」というような解説があった。ちゃんとフリーソフトウェアって書いてほしい…絶対これ「フリーウェア」とかと同じに捉える人を生み出しますよ?
    OSSを「オープンソフト」とか言わないですよね。FirefoxをFireFoxとかFire Foxとか書かないし、MicrosoftをMicroSoftとか書いてたらいかんですよね。それと同様。これが一般PC雑誌なら「まぁしかたがないか…」ですが、専門紙なんだから基本用語は正確にお願いしたい
  • 問題あり: Ubuntuをに常に最新へアップデートしよう、という記事で proposed-updates を当てるように案内するのは、大変よろしくない。proposed-updates はその名前が指すように「リポジトリに入れるかな、候補」の提案であって、最新へアップデートというのにはそぐわない(β版かRC版ぐらいな感じ)。最新が「リリースされたもの」を指し示さないなら、開発版(α相当)を案内するのがいいだろうし、リリースされたものを指すのであればproposed-updatesを盲目的に導入指示するのは誠実さに欠ける

ということで、書いたライターの方は、正直キンカクテンプルでハラキリ儀式を行ってほしいぐらいです。サツバツ!

さらに追記: Debian での proposed-updates の扱いについては、Software Designの今月号で書いてあるのでそちらを参照のこと!(ステマ)

ま、一言で言うと「誠実さに欠ける」が私的には問題だよなーと思うのでした。


2013-03-13 [長年日記] この日を編集

atherosのファームウェアがflossライセンスで公開された

が、ソースを見ると gcc と binutils にパッチを当ててローカルのtoolchainだけでビルドするようにしてる。なんだこら。

gccはちょっとだけモディファイしている。現状からそんなに乖離してないんだから、マージできる?
一方 binutilsは28000行も変更が…どういうことよ…

henrich@hp:~/tmp/open-ath9k-htc-firmware/target_firmware/magpie_fw_dev$ file `find . -executable`|grep ELF
./build/utility/bin/imghdr:                                       ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
./build/utility/bin/patch_gen:                                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
./build/utility/bin/adj_time:                                     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
./build/utility/bin/adj_dep:                                      ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
./build/utility/bin2hex/bin2hex:                                  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
./build/make_opt/lib/crt1-tiny.o:                                 ELF 32-bit MSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped
./build/make_opt/lib/_vectors.o:                                  ELF 32-bit MSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped
./build/magpie_1_1/image/output/fpga/rom.fpga.out:                ELF 32-bit MSB executable, Tensilica Xtensa, version 1 (SYSV), statically linked, not stripped
./build/magpie_1_1/image/output/asic/rom.asic.out:                ELF 32-bit MSB executable, Tensilica Xtensa, version 1 (SYSV), statically linked, not stripped
./build/magpie_1_1/sboot/athos/src/crt1-tiny.o:                   ELF 32-bit MSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped
./build/magpie_1_1/sboot/athos/src/_vectors.o:                    ELF 32-bit MSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped

2013-03-15 [長年日記] この日を編集

パッケージングするはそのソフトウェアのエキスパートじゃなくて良い

そりゃエキスパートの方が望ましいけどさ。

pbuilder/cowbuilderこける

Get:1 http://ftp.jp.debian.org sid Release.gpg [836 B]
Hit http://ftp.jp.debian.org sid Release
Ign http://ftp.jp.debian.org sid Release
Hit http://ftp.jp.debian.org sid/main amd64 Packages/DiffIndex
Hit http://ftp.jp.debian.org sid/main Translation-en
Fetched 836 B in 0s (3011 B/s)
Reading package lists...
W: GPG error: http://ftp.jp.debian.org sid Release: The following signatures were invalid: BADSIG AED4B06F473041FA Debian Archive Automatic Signing Key (6.0/squeeze) 
I: Obtaining the cached apt archive contents

--allow-untrusted で回避はできるけど、なんでこんなん起こるんだ?

apt (0.9.7.8) unstable; urgency=criticial
 
  * SECURITY UPDATE: InRelease verification bypass
    - CVE-2013-1051
   
  [ David Kalnischk ]
  * apt-pkg/deb/debmetaindex.cc,
    test/integration/test-bug-595691-empty-and-broken-archive-files,
    test/integration/test-releasefile-verification:
    - disable InRelease downloading until the verification issue is
      fixed, thanks to Ansgar Burchardt for finding the flaw

これかなぁ、最初のdebootstrapは済んでるし、disable InRelease downloading until the verification issue is fixed がそれっぽい。。。

piupartsこける

8m16.5s DEBUG: Starting command: ['chroot', '/tmp/tmpivurbJ', 'eatmydata', 'umount', '/proc']
8m16.5s DUMP: 
  umount: /proc: device is busy.
          (In some cases useful info about processes that use
           the device is found by lsof(8) or fuser(1))
8m16.5s DEBUG: Command failed (status=1), but ignoring error: ['chroot', '/tmp/tmpivurbJ', 'eatmydata', 'umount', '/proc']
8m16.5s DEBUG: Starting command: ['rm', '-rf', '--one-file-system', '/tmp/tmpivurbJ']
8m16.6s DUMP: 
  rm: skipping '/tmp/tmpivurbJ/proc', since it's on a different device
8m16.6s ERROR: Command failed (status=1): ['rm', '-rf', '--one-file-system', '/tmp/tmpivurbJ']
  rm: skipping '/tmp/tmpivurbJ/proc', since it's on a different device
  
8m16.7s DEBUG: Starting command: ['chroot', '/tmp/tmpivurbJ', 'umount', '/proc']
8m16.8s DUMP: 
  chroot: failed to run command 'umount': No such file or directory

上記のようになってこける。

binfmt_misc on /srv/chroot/testsid/tmp/tmpivurbJ/proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)

/proc 以下のbinfmt_miscがマウントされているのが原因っぽいんだが、なんでこれマウントされるようになっているんだろう?


2013-03-17 [長年日記] この日を編集

piupartsのこける原因を追う。

前回からの続き。

  • piupartsが何かおかしいのかどうか、というところで、とりあえずhelloパッケージをpiupartsにかける→何にも問題無し、ということで、piuparts自身でどのような場合にもエラーになるわけではない、という切り分けができた。
  • 次にpiupartsのエラーログをとって眺めていて、ふとbinfmtでgrep。binfmt-supportというパッケージを入れてるのが気にかかった。
    apt-cache dotty pleiades で、jarwrapperがbinfmt-supportを引っ張っているのを確認。jarwrapperパッケージをpiupartsにかけると…再現。これはbinfmt-supportの問題?
  • しかしbinfmt-supportパッケージ単体ではpiupartsは素通りする。んー?
  • 他のbinfmt-supportに依存しているパッケージは…というとllvm-3.2-runtimeがあった。これでpiuparts…やっぱり再現する。 これはhostの/proc/sys/fs/binfmt_miscが他のパッケージで汚れたせいだったようだ。cleanなミニマムな環境をvirtualboxで作ったらpiupartsは通った。
  • で、binfmt-supportのパッケージ説明文を読む。update-binfmtsで登録作業ができるので、依存しているjarwrapperなどのパッケージが実行をしているっぽい。で、これのせいで/proc以下にファイルが残ってるようだ。

さて、どう直すかな。


2013-03-18 [長年日記] この日を編集

ttf-cjk-compactと今後改善した方がいい点

  • ttf-cjk-compact は d-i の strings を見て、フォントファイルから必要なglyphを切り出して固めている。そのため、d-i の strings translation がfreezeしないとそもそも正しいフォントファイルを生成できない。これは開発終盤にならないと最終的な成果物を出荷できないということ。
  • 欠落しているグリフの確認(テスト)ができていない。目視と報告に頼っている。
  • アップデートした時にregressionを起こしている可能性を排除できていない。

smartyのアップデートの件

そうか、rt に登録しないとスルーされちゃうか。自分で訳しておいて開発者リファレンスを読み直さないとわからない罠。

SD発売

しかし、次の締切りがもうすぐに。。。なんだこれは orz


2013-03-19 [長年日記] この日を編集

sfddiff を使えばフォントファイルの比較ができる

sfddiffなるものがあった。これをうまく使えばフォントパッケージのデグレを防げるのではないだろうか。

mergeオプションは使い辛い。

$ LANG=C sfddiff fonts-vlgothic-20121109/VL-Gothic-Regular.ttf fonts-vlgothic-20121230/VL-Gothic-Regular.ttf |grep "Glyph.*differs"

上記で差異があるグリフの番号については取り出せるから、あとはそのグリフについて2つのフォントで読み込んで画像を出力できたりするといいのかな?

changelog用にグリフだけ一覧出力するのもありだな。。。

fontimageでpngファイルに文字列を出力できるのはわかった。グリフを指定してはできないか。


2013-03-20 [長年日記] この日を編集

グリフの確認続き

先日の続き。グリフのunicodeポイント一覧は取得できたので、これを文字に変更するのにうんうん言いながら考えた結果、pythonで変換することができた。

あとは画像にfontimageで出力して、imagemagickで貼っ付ける、ということになるだろう。


2013-03-21 [長年日記] この日を編集

dh_installdocs のバグ

       --link-doc=package
           Make the documentation directory of all packages acted on be a symlink to the documentation directory of
           package.

だが

        # dh_installdocs has a bug when --link-doc is called it don't install copyright file to referenced package
        # so specify to copy it
        install -d $(CURDIR)/debian/libsnmp$(LIB_VERSION)/usr/share/doc/libsnmp$(LIB_VERSION)/
        install -m644 debian/copyright $(CURDIR)/debian/libsnmp$(LIB_VERSION)/usr/share/doc/libsnmp$(LIB_VERSION)/

としている。つまりは --link-doc で指定したパッケージ自体にはcopyrightファイルがインストールされない。なので、上記のワークアラウンドを外すとこうなる。

# dpkg --contents ../libsnmp30_5.7.2~dfsg-1~0.1_amd64.deb |grep /usr/share/doc/libsnmp30/
drwxr-xr-x root/root         0 2013-03-21 01:09 ./usr/share/doc/libsnmp30/
-rw-r--r-- root/root     16531 2013-03-02 22:30 ./usr/share/doc/libsnmp30/changelog.Debian.gz
-rw-r--r-- root/root   1315651 2012-10-09 22:28 ./usr/share/doc/libsnmp30/changelog.gz
-rw-r--r-- root/root      1107 2011-01-05 12:12 ./usr/share/doc/libsnmp30/NEWS.Debian.gz

Ubuntu Server 実践バイブルを読んだ

ありがたいことにアスキーメディアワークス様から「Ubuntu Server 実践バイブル」の献本を頂いたので、書評を(分厚い「継続的デリバリー」とか買ってたからかな? ;-)

ちまたにある「できる簡単!」本とは姿勢の違う、「ぐぐってこぴぺ」の対極にあるような本です。結論とコマンドだけを列挙するのではなく、「こう考えてこういうやり方もあるよ。こんなパターンも考えられるよ」というのがひたすら書いてあります。人によっては冗長と捉えるかもしれないので、つまみ読みはちょっと難しいかも。頭使って「読み取る」のが必要になりますね。

この辺は賛否両論あるでしょうが、スルメのように噛んで噛んで、と言う人には顎が鍛えられてありがたい本だと思います。

個人的には Debian にどうやって Ubuntu サーバーの良い所を取り込もうか、という視点で読み直してみようかな、と思っています。あ、ところで次の献本は「Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド」でお願いします(ぉ


2013-03-23 [長年日記] この日を編集

smarty アップロードした

mumumuさんがやる気になってくれたので、側面サポートで。

svn-buildpackageを真面目に使う羽目になった

普段は upstream ソースがでかすぎるからコミットすんな!と言われてしまってsubversionリポジトリにはdebianディレクトリしかコミットしてない pkg-fonts-devel なリポジトリ。birdfontを ITP してアップロードしたのだが、それから幾星霜、すでに upstream は 0.18 というバージョンに(私が作業したのは 0.12)。
これはいかん、とアップデートをしておこうと思い立ちました。念のため、バージョンを一つずつあげていくことにして、さて、問題は新しいupstreamのバージョンとかってどーすんだろ?ということ。ここでsvn-buildpackageをまともに使うことになるわけです。

以下が手順。trunkには既に 0.12 のソースと debian ディレクトリがあるものとする。

  • $ mkdir branches/upstream
    $ tar xvf tarball/birdfont-0.12.tar.gz -C branches/upstream
    $ cd branches/upstream; mv birdfont-0.12 current; cd -
    $ svn add branches
    $ svn ci
  • $ cd trunk
    $ svn-upgrade ../tarball/birdfont-0.13.tar.gz (これがよしなに計らってくれる。偉い)
  • あとはビルドして…
  • 問題なければ svn-buildpackage --svn-tag でタグを打っておく

0.14 で run.py ファイルがなくて run モジュールの定義を import できない!となっていたのをパッチにしておいたら、 0.15 でしれっと追加されていてコンフリクトして笑ってしまった。

PCIe SSDの活用

LibO のビルドで比較するのはどうか。適当なプランを考えてみる

  • 普通のストレージとSSDなインスタンスの両方でシーケンシャルに10回ぐらいビルドして時間を測る
  • 普通のストレージとSSDなインスタンスの両方で15分ごとぐらいにビルドを起動して、10個ビルドを並列で走らせて最終的に時間がどの程度かかるかを測る
  • 使用CPU数を変更して比較してみる

4パターンはあるわけだな。debootstrapで適当なdistributionでも環境は作れるし。


2013-03-24 [長年日記] この日を編集

piupartsエラー

なんか/var/log/fontconfig.logとかできてるよ

グリフ差分のイメージを取得する

フォントパッケージはデータなので、ロジックの誤りによるリグレッションというのは他のパッケージと違って入りこまない。 しかし、意図せずしてグリフを破損する事によるリグレッションはありえる。
現状だと「まぁ、大丈夫だろう」ということでアップロードし、ある程度の期間利用することで「おそらくリグレッションが入り込んでないだろう」という状況を担保している。 しかし、できればdiff=「差異があるグリフ」を確認した方がbetterである。

ということで、短いスクリプトを書いた。fontforgeさまさまやわー

  • まず、過去のソースパッケージを取得、なければsnapshot.debian.orgから取ってくる
  • 展開して、直下にあるttf,ttcファイルをsfddiffを使って比較する
  • そのままだと「5142」みたいなUnicodeのポイントになってるのでpythonスクリプトで文字に変換
  • fontimageで変換した文字列を出力する
  • とりあえず、eogで表示する

が、バグバグで全然まともに動かない(決め打ち)なので直さないと…


2013-03-28 [長年日記] この日を編集

O を引き取った

fontforgeの依存パッケージがOrphanになっていたので引き取り。

まずは、git.debian.org にログインして下準備をする。ローカルにpullして、git-import-dsc で下ごしらえ。 で、色々いじってコミットなどしてできたらビルドしてタグをつける。

git-buildpackage --git-tag

これでOKのはずが間違いを後から見つけてしまったら、タグを消す。

3/31追記: --git-sign-tags の方がGPG署名できるので良い。こっちを使おう。

git tag -d debian/20130328-1

とりあえず .git/config の Origin を修正しておく。git+ssh://git.debian.org/git/foobar/buzz.git という感じ。で pushする。

git push origin master

で、問題なさそうだったのでとりあえずexperimentalへ放り込んだ。修正&unstable行きはWheezyがでてから。。。

debhelperでなんちゃってmavenサポートを追加するようにした

あるパッケージがant->mavenとなってしまったので、debhelperをみたらantサポートはあるけどmavenサポートが無かった。じゃ、と思ってantのをパクってmavenにしてみた。 ちゃんと動くかどうか謎だったので とりあえずメール。反応なかったらdebhelperパッケージにバグ登録しちゃおう


2013-03-31 [長年日記] この日を編集

Maintainer Dashboardを更新してもらった

パッケージの Todo 整理などに役立つ Maintainer Dashboard で、ふと思いついたことがあったので BTS したら、実装された。些細な事だがありがたい。

で、毎度の事ですが hogefuga-1.00-1u2 とか u いくつ、で更新する人たちは提案とかくれないものなのかね。

スポンサーアップロードした

pkg-fonts-develで要請があったのを行きがかり上対応した。
スポンサーされる側からする側になっているというのは、ある意味感慨深い。