最新 追記

ポケットを空にして。

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|

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

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


2014-05-04 [長年日記] この日を編集

gbpでNMUされた古いバージョンをimportするとき

そのままだとmasterに上書きされちゃう。
答えはマニュアルにあった。

$ git branch nmu master
$ git checkout master
$ gbp import-dsc --debian-branch=nmu /path/to/package_1.0-1nmu0.dsc

あー、debian-branchの指定をしてやればよかったのね。


2014-05-05 [長年日記] この日を編集

openSUSEでパッケージングを試してみる

RPMパッケージの作成から参考になる知見を得るため、opensuse conference 2014のパッケージングワークショップの動画を見て、プレゼン資料を見ながら作業

henrich@linux-1xx3:~> sudo zypper ar http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_13.1/openSUSE:Tools.repo
root's password:
リポジトリ 'openSUSE.org tools (openSUSE_13.1)' を追加しています ..................................................[完了]
リポジトリ 'openSUSE.org tools (openSUSE_13.1)' を正常に追加しました
有効: はい (Y)
自動更新: いいえ (N)
GPG チェック: はい (Y)
URI: http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_13.1/
  • 「自動更新: いいえ (N)」ってのはどういうことなんだろ。
  • 「GPG チェック: はい (Y)」ってのはパッケージごとにGPGキーでの署名が行われている?
henrich@linux-1xx3:~> sudo zypper ref
リポジトリ 'openSUSE-13.1-1.10' は最新の状態に更新済みです。
リポジトリ 'openSUSE.org tools (openSUSE_13.1)' のメタデータを取り出しています... ------------------------------------[\]
 
新しいリポジトリまたはパッケージの署名鍵を受信しました:
鍵 ID: 85753AA5EEFEFDE9
鍵名: openSUSE:Tools OBS Project 
鍵指紋: 0A031153E2F5E9DB71510D8C85753AA5EEFEFDE9
鍵の作成: 2008年01月23日 06時08分03秒
鍵の有効期限: 2014年12月20日 22時18分55秒
リポジトリ: openSUSE.org tools (openSUSE_13.1)
 
鍵を拒否しますか (R)? 一時的に信頼しますか (T)? それとも今後ずっと信頼しますか (A)? [r/t/a/? 全てのオプションを表示] (r): y
回答 'y' が正しくありません。 [r/t/a/? 全てのオプションを表示] (r): a
リポジトリ 'openSUSE.org tools (openSUSE_13.1)' のメタデータを取り出しています... .................................[完了]
リポジトリ 'openSUSE.org tools (openSUSE_13.1)' のキャッシュを構築しています ......................................[完了]
リポジトリ 'openSUSE-13.1-Non-Oss' は最新の状態に更新済みです。
リポジトリ 'openSUSE-13.1-Update' は最新の状態に更新済みです。
リポジトリ 'openSUSE-13.1-Update-Non-Oss' は最新の状態に更新済みです。
全てのリポジトリを更新しました。
  • デフォルトでNon-Ossのリポジトリを見にいくの?
  • 鍵を信頼しないで進められるのかな?
henrich@linux-1xx3:~> sudo zypper in --from openSUSE_Tools osc build
リポジトリのデータを読み込んでいます...
インストール済みのパッケージを読み込んでいます...
パッケージの依存関係を解決しています...
 
問題点: osc-0.145.0-131.1.noarch は python-urlgrabber を必要としていますが、この要求を解決する方法がありません
  インストール不可能なプロバイダ: python-urlgrabber-3.9.1-10.1.2.noarch[openSUSE-13.1-1.10]
 解決方法 1: patterns-openSUSE-minimal_base-conflicts-13.1-13.6.1.x86_64 のアンインストール
 解決方法 2: osc-0.145.0-131.1.noarch をインストールしない
 解決方法 3: osc-0.145.0-131.1.noarch をインストールしない
 解決方法 4: いくつかの依存関係を無視することによって osc-0.145.0-131.1.noarch を壊します
 
いずれかの数字を入力するか、キャンセル(C) を入力してください [1/2/3/4/c] (c): 1
依存関係を解決しています...
パッケージの依存関係を解決しています...
  • いきなり「インストール不可能なプロバイダ」ってのはいったい。。。
henrich@linux-1xx3:~> osc co home:darix:workshop
 
Your user account / password are not configured yet.
You will be asked for them below, and they will be stored in
/home/henrich/.oscrc for future use.
 
Creating osc configuration file /home/henrich/.oscrc ...
Username: henrich
Password: 
done
Server returned an error: HTTP Error 401: basic auth failed

適当なユーザー名とパスワードだとダメですね。これはopenSUSEのOBSサイトの方で先に作っておかないとダメなのかな?
→あたり。昔、アカウント作ってたのをすっかり忘れてたのでリセットした。しかし~/.oscrcファイルむっちゃながいね。。。

Use spdx format for licenses

copyright format 1.0だと spdx と違いあるかな?

Using %{?_smp_flags} can speed up your build a lot.

pbuilderrcで設定していることはあるけど、自動で判別してということではなかったから、こっちの方が賢い気がする。
できればデフォルトでsmpを判別、値を指定するようにして、例外でoffにするとかの指定をつけるようにするほうがいい気がする

"osc repos" to see what we can build for.
"osc build openSUSE_13.1 x86_64"

cowbuilder --basepath でビルド環境切り替えるのと同様か。事前に作らなくてもいいのは楽なのかな。何か改善できるかな

"pkgconfig($libraryname)" for portability, except for older distributions.

これはいいアイデアなのでは?

"osc vc"

dchと同じ。

"osc addremove"

これ、説明あったかな?

For many languages we already have guide lines or even tools (gem2rpm, py2pack)

gem2rpmってgem2debとどっちが先なのかな?

Create a seperate user/group for your package. Most of the time your daemon does not need root to run.

ユーザーとグループを作るのであれば、rulesに直書きではなく分かれたファイルにしておいた方がいいような気がしてきた

zypper in spec-cleaner

rpmlintとは別なの?

henrich@linux-1xx3:~> man spec-cleaner
-bash: man: コマンドが見つかりません

oh...

とりあえず spec-cleaner -d foobar.spec したら差分表示でいい感じに直してくれるようだ。

buildは.specファイルのあるディレクトリで osc build すれば /var/tmp/build-root/ 以下に chroot して作るっぽい。パッケージは一度取得すると/var/tmp/osbuild-packagecache/ 以下にバージョンごとにopenSUSE:13.1 のようにフォルダを作って、その下にアーキテクチャごとに分かれてパッケージが保存されているようだ。…けど、一度取得したパッケージを再展開している様子が見えない。どこに展開したイメージを保存するの?

$ osc build openSUSE_13.1  x86_64
Building librelp.spec for openSUSE_13.1/x86_64
Getting buildinfo from server and store to /home/henrich/home:darix:workshop/librelp-01-base/.osc/_buildinfo-openSUSE_13.1-x86_64.xml
Getting buildconfig from server and store to /home/henrich/home:darix:workshop/librelp-01-base/.osc/_buildconfig-openSUSE_13.1-x86_64
Updating cache of required packages
 
The build root needs packages from project 'openSUSE:13.1'.
Note that malicious packages can compromise the build result or even your system.
Would you like to ...
0 - quit (default)
1 - always trust packages from 'openSUSE:13.1'
2 - trust packages just this time
? 2
0.0% cache miss. 111/111 dependencies cached.
 
Verifying integrity of cached packages
using keys from openSUSE:13.1
Writing build configuration
Running build
root's password:
logging output to /var/tmp/build-root/openSUSE_13.1-x86_64/.build.log...
[    0s] Memory limit set to 3405340KB
[    0s] Using BUILD_ROOT=/var/tmp/build-root/openSUSE_13.1-x86_64
[    0s] Using BUILD_ARCH=x86_64:i686:i586:i486:i386
[    0s] 
[    0s] 
[    0s] linux-1xx3 started "build librelp.spec" at Mon May  5 13:02:02 UTC 2014.
[    0s] 
[    0s] 
[    0s] processing recipe /home/henrich/home:darix:workshop/librelp-01-base/librelp.spec ...
[    0s] running changelog2spec --target rpm --file /home/henrich/home:darix:workshop/librelp-01-base/librelp.spec
[    0s] init_buildsystem --configdir /usr/lib/build/configs --cachedir /var/cache/build --rpmlist /tmp/rpmlist.0R3aBQ /home/henrich/home:darix:workshop/librelp-01-base/librelp.spec ...
[    0s] reordering...cycle: libcrack2 -> cracklib
[    0s]   breaking dependency libcrack2 -> cracklib
[    0s] cycle: libtasn1-6 -> libtasn1
[    0s]   breaking dependency libtasn1-6 -> libtasn1
[    0s] done

うーん…?

henrich@linux-1xx3:/var/tmp/build-root/openSUSE_13.1-x86_64/installed-pkg> ls
aaa_base              fillup                libaudit1        libitm1          libtasn1-6         permissions
aaa_base-malloccheck  findutils             libblkid1        liblua5_1        libtasn1-devel     pkg-config
attr                  gawk                  libbz2-1         liblzma5         libtirpc1          post-build-checks
bash                  gcc                   libcap2          libmagic1        libtsan0           rpm
binutils              gcc48                 libcloog-isl4    libmount1        libustr-1_0-1      rpm-build
brp-check-suse        gettext-runtime-mini  libcrack2        libmpc3          libutempter0       rpmlint-Factory
brp-extract-appdata   gettext-tools-mini    libdb-4_8        libmpfr4         libuuid1           rpmlint-mini
build-compare         glibc                 libelf1          libncurses5      libz1              sed
build-mkbaselibs      glibc-devel           libffi4          libnettle-devel  libzio1            systemd-rpm-macros
bzip2                 glibc-locale          libgcc_s1        libnettle4       linux-glibc-devel  tar
coreutils             gmp-devel             libgdbm4         libp11-kit0      m4                 terminfo-base
cpio                  grep                  libgmp10         libpcre1         make               update-alternatives
cpp                   gzip                  libgmpxx4        libpopt0         net-tools          util-linux
cpp48                 info                  libgnutls-devel  libreadline6     p11-kit-devel      which
cracklib              insserv-compat        libgnutls28      libselinux1      pam                xz
diffutils             libacl1               libgomp1         libsemanage1     pam-modules        zlib-devel
file                  libasan0              libgssglue1      libsepol1        patch
file-magic            libatomic1            libhogweed2      libstdc++6       perl
filesystem            libattr1              libisl10         libtasn1         perl-base
 
henrich@linux-1xx3:/var/tmp/build-root/openSUSE_13.1-x86_64/installed-pkg> cat gcc48
gcc48-4.8.1_20130909-3.2.1 1380871479

あれ?別のパッケージをビルドしてみて、/var/tmp/build-root/openSUSE_13.1-x86_64/usr/include以下を見たら、ファイルが増えてるような…もしかして、最小限のchrootを作ってくれるのではなく、毎度使いまわすのか、これは。あまりうれしくないなぁ…

そして謎なのが、/var/tmp/build-root/openSUSE_13.1-x86_64/opt/testing 以下にファイルがあることですよ。なぜ/opt?

|-- bin
|   |-- checkbashisms
|   |-- dash
|   |-- desktop-file-validate
|   |-- python
|   `-- rpmlint

dashとかcheckbashismsとかがあるし、なぜここにもrpmlintがある?

カーネルイメージを作り直してみる

SWAP無効にしていたカーネルだとsnmpdがエラーログ吐きまくるぜと言われていたのがあったので、そちらを検証するために作業。 インストールガイドを参考に。

$ sudo apt-get install linux-source-3.2 kernel-package
$ tar xvf /usr/src/linux-source*
$ cd linux-source*
$ cp /boot/config-3.2.* ./.config
$ vi .config (で、SWAPのところだけ無効にして)
$ fakeroot make-kpkg --initrd --revision=1.0custome kernel_image (ガイドの--revision=custom.1.0だと無効と言われたような)
$ sudo dpkg -i ../linux-image-3.2*
$ sudo shutdown -r now

で、試したけどふつーに/proc/vmstatの下の項目が見えていて特にエラーを吐かなかったので、これ以上の深追いはいらないだろうとwontfixタグをつけました。

%{?_smp_flags} と同等のものがあるといい気がする

  • 一応/etc/pbuilderrcで DEBBUILDOPTS="-j4" などとすればいいのだけど、問題がいくつか。
    1. ビルドするユーザーが手で書かないといけない。
    2. 決め打ち
    3. そもそもその値は適切なのかどうか
  • pbuilder/cowbuilderで指定するよりも、ソース側でやったほうがいい?→でもそうするとソース側で色々対応しなければいけない気がする…これは手間。
  • となると、debhelperで対応するといいんじゃないか?
  • 新規バージョンでビルドすると自動的にsmpなフラグを立ててビルド、それで失敗するようであれば、debian/rulesに明示的にdisableにする記述する

debhelperにハックすればいい、という結論だ。

$ expr 1 + `grep ^processor /proc/cpuinfo |tail -n1|cut -d':' -f2|sed -e s/\ //`

コア数自体は上記で簡単にとれるんだけど。


2014-05-06 [長年日記] この日を編集

CPU数の確認

$/usr/bin/getconf _NPROCESSORS_ONLN
4

/usr/lib/rpm/platform/*/macro で %_smp_mflags はこんな風にしてた。へぇ、getconfはlibc-binパッケージにはいってる。


2014-05-10 [長年日記] この日を編集

parallel makeの話

openSUSEのWikiではParallel makeという項目で書いてある。

Whenever possible, invocations of make should be done as
 
make %{?_smp_mflags}

…とはいえ、specファイルをいちいち直して回るのは面倒なんじゃないかね。


2014-05-15 [長年日記] この日を編集

debcheckout

henrich@hp:~/tmp/temporary-net-snmp $ debcheckout net-snmp
declared git repository at git://anonscm.debian.org/pkg-net-snmp/pkg-net-snmp.git
git clone git://anonscm.debian.org/pkg-net-snmp/pkg-net-snmp.git net-snmp ...
Cloning into 'net-snmp'...
(snip)
henrich@hp:~/tmp/temporary-net-snmp/net-snmp(master) $ gbp buildpackage 
(snip)
gbp:info: Orig tarball 'net-snmp_5.7.2.1~dfsg.orig.tar.gz' not found at '../tarballs/'
gbp:warning: Pristine-tar branch "pristine-tar" not found
fatal: Path 'net-snmp_5.7.2.1~dfsg.orig.tar.gz.delta' does not exist in 'refs/remotes/origin/pristine-tar'
pristine-tar: git show refs/remotes/origin/pristine-tar:net-snmp_5.7.2.1~dfsg.orig.tar.gz.delta failed
gbp:error: Couldn't checkout "net-snmp_5.7.2.1~dfsg.orig.tar.gz": /usr/bin/pristine-tar returned 128

debcheckoutはpristine-tarブランチを一度自動でcheckoutしてmasterに戻る、という挙動をするのはどうだろうか?私はこの動作を毎度忘れる。


2014-05-17 [長年日記] この日を編集

swapパーティション vs swapファイル

swapをパーティションにするか、ファイルとして持つか、どっちにどういう利点と欠点があるのだろうか?

  • パーティションにすると、一度作ったらサイズを変更しづらい
  • インストーラーがパーティションを確保すると、メモリの倍とかで今の環境としてはあまり適していないのでは?(32GBとかあってもなぁ…)

パッと思いついたのは上記。ということはファイルで持ったほうがよさそう、ということになってしまうが、はて、ほかに何があるかな?


2014-05-28 Sqeeze-LTSキタ。 [長年日記] この日を編集

Squeeze-ltsのアナウンス粗訳

- -------------------------------------------------------------------------
Debian Security Advisory DSA-2938-1                   security@debian.org
http://www.debian.org/security/                        Moritz Muehlenhoff
May 27, 2014                           http://www.debian.org/security/faq
- -------------------------------------------------------------------------
 
The initial organisation and setup of Squeeze LTS has now happened and 
it is ready for taking over security support once the standard security 
support ends at the end of the month:
 
Squeeze LTSについての初期の組織構成と設定がなされ、今月の終わりに通常の
セキュリティサポートが終了するのに伴う引き継ぎの準備が整いました。
 
 
Information for users
=====================
ユーザーへの案内
 
Support for Squeeze LTS will end five years after the release of Squeeze, 
i.e. until the 6th of February 2016.
 
Squeeze LTSサポートはSqueezeのリリースから5年後に終了します。
つまり2016/2/6までです。
 
You need to enable the apt sources for squeeze-lts manually. 
Information on how to do this can be found at
https://wiki.debian.org/LTS/Development#Add_squeeze-lts_to_your_sources.list
 
squeeze-ltsのapt設定を手動で有効にする必要があります。
この作業のやり方については以下を参照してください。
https://wiki.debian.org/LTS/Development#Add_squeeze-lts_to_your_sources.list
 
 
You should also subscribe to the new annoucement mailing list for 
security updates for squeeze-lts:
https://lists.debian.org/debian-lts-announce/
 
また、新しいsqueeze-ltsへのセキュリティアップデートのアナウンス用メーリング
リストを購読したほうがよいでしょう:
https://lists.debian.org/debian-lts-announce/
 
 
A few packages are not covered by the Squeeze LTS support. These can be
detected with the new tool debian-security-support. Information on how
to run it can be found here:
https://wiki.debian.org/LTS/Development#Check_for_unsupported_packages
 
いくつかのパッケージはSqueeze LTS サポートの範囲外となります。
新たなdebian-security-supportというツールでこれらの検出ができるようになっています。
どのようにして実行するかについては以下を参照してください。
https://wiki.debian.org/LTS/Development#Check_for_unsupported_packages
 
 
If debian-security-support detects an unsupported package which is 
critical to you, please get in touch with debian-lts@lists.debian.org
(see below).
 
あなたに取って必要不可欠なパッケージがdebian-security-supportによって
サポート外であると検出された場合は、debian-lts@lists.debian.orgに
相談してください(以下を参照)。
 
squeeze-backports will continue to be supported for the lifetime of 
Squeeze LTS.
 
squeeze-backports はSqueeze LTSの期限までサポートが継続されます。
 
 
Information for Debian maintainers
==================================
Debianのメンテナに対する案内
 
First of all, Debian package maintainers are not expected to work on 
updates of their packages for squeeze-lts. Package updates for 
squeeze-lts will be handled by the Debian LTS team.
 
まず、Debianのパッケージメンテナはsqueeze-ltsにおいて自分のパッケージの
更新作業を行うことを期待されてはいません。squeeze-ltsでのパッケージの更新
はDebian LTSチームによって運営されます。
 
 
However, if you _are_ interested in doing so (and the maintainer always
knows best on a package), you're certainly welcome to do so; everyone
in the Debian.org and Debian maintainers key ring can upload to the 
squeeze-lts suite. Information on how to upload a fixed package can 
be found at https://wiki.debian.org/LTS/Development#Upload_Packages
 
しかし、*もし* あなたが作業に興味が有るのであれば(そしてメンテナは常に
そのパッケージについて一番良く知っているので)、もちろん作業は大歓迎です。
Debian.orgとDeibanメンテナのキーリングにいる全員はsqueeze-ltsにアップロード
が可能です。修正したパッケージをどのようにアップロードするのかについては
https://wiki.debian.org/LTS/Development#Upload_Packages を参照してください。
 
 
Mailing lists
=============
メーリングリスト
 
The whole coordination of the Debian LTS effort is handled through the
debian-lts mailing list: https://lists.debian.org/debian-lts/
 
DebianLTSの作業について、全体的な調整はdebian-ltsメーリングリストを通じて行われます
https://lists.debian.org/debian-lts/
 
Please subscribe or follow us via GMANE (gmane.linux.debian.devel.lts)
こちらを購読するか GMANE (gmane.linux.debian.devel.lts)を参照してください
 
Aside from the debian-lts-announce list, there's also a list for 
following all uploads in debian-lts: 
https://lists.debian.org/debian-lts-changes/
 
debian-lts-announce の他に、debian-ltsへの全てのアップロードを参照できる
リストもあります: https://lists.debian.org/debian-lts-changes/
 
 
Security Tracker
================
セキュリティトラッカー
 
All information on the status of vulnerabilities (e.g. if the version in 
squeeze-lts happens to be unaffected while wheezy is affected) will be 
tracked in the Debian Security Tracker:  
 
脆弱性状況の全ての情報 (例: squeeze-ltsのバージョンは影響を受けないが、
wheezyは影響を受けるなど)はDebianセキュリティトラッカーで追跡されます。
 
http://security-tracker.debian.org
 
If you happen to spot an error in the data, please see 
https://security-tracker.debian.org/tracker/data/report
 
データにエラーを見つけた、という場合は以下を参照してください
https://security-tracker.debian.org/tracker/data/report

GNOMEでのリコールバッテリの検出について

2007年にGNOMEにログインしたらバッテリがリコール対象だと教えてもらった話を書いた。Let's noteのバッテリリコールの話から、今現在はどんなふうになっているのかを調べてみた。

結論から言うと、機能が削除されてる。パッケージとしてはupowerパッケージが担当しているのだが、upstreamの最新版である0.99.0だとコードが削除されているのだ。今のunstableに入っているバージョンではまだ保持している。

upowerでは再追加は経緯を見る限り難しそうなので、別のものとして追加するなどを考えた方が良さそう。有用だとおもうのだけどなー


2014-05-29 [長年日記] この日を編集

「コード・シンプリシティ――ソフトウェアの簡潔性を保つ事実、法則、真理」

先日、オライリーの電子書籍「コード・シンプリシティ――ソフトウェアの簡潔性を保つ事実、法則、真理」を買った。半額セールにつられて、という奴だ。
Bugzillaの人の話なのだけど、書いてあることは正直「まぁそうだよね」という妥当で普通な話が多い。

で、ざっと他の人の感想を見て回って、自分が一番腑に落ちたことが取り上げられてなかったのでメモとして。

「ユーザーがいる、という価値」という項目で以下のように述べられている。

つまり、多くの場合、価値が高まるようにソフトウェアをリリースしていかなければならない、ということだ。時間がかかりすぎる変更は、結果として価値がゼロになることもある。効果的な助けとなるリリースのタイミングを逃してしまうからだ。変更の欲求度を考慮する際には、リリースのスケジュールを検討することも大切だ。

例えば今更フロッピーディスクを100倍の効率で扱うためのプログラムが提供されたとしても正直意味がない。物事にはそのバリューを発揮するためのタイミングというものがあり、そのタイムフレームから遅れてプロダクトを提供してもダメ。(逆に、早すぎてもいけないけど。インターネットが提供されてない世界でウェブブラウザがあっても今ほどの価値は発揮されないし)。

このタイミングというのは実は非常に難しい。タイミングを逃さないためには、絡み合った物事をプライオリティを付けてスコープを限定して処理する必要がある。これを行わないと、物事の依存関係によりブロッキングが起こり、結果としてレイテンシの遅延が大きく生じ、結果としてウィンドウが開いている間に意図した機能を提供できないことになる。朝寝坊して電車に乗れないで目の前で発車される、みたいな。

無限のリソースを持っていると仮定していればすべてパラレルで実施すればいいじゃん、となるが当然現実は違うわけでリソースの把握とスコープの過程と順序付けを考えつつ作業を行わないと、プロダクトは出来上がらないし、できたとしてもold fashionedなものにならざるを得ない。

そういう意味で、Debianでstableが「古い」と揶揄されるのを、言葉通りに受け取ってはいけない。コードは現実世界の物理的なものとは違って、決して錆びついたりはしないからだ。古いのが問題なのではなく、環境の変化に合わせて利用したい機能について、タイミングを外して提供できていないことが問題なのだから。逆に言えば、この問題点を改善できれば価値を大きく上げることができる。


2014-05-31 [長年日記] この日を編集

security teamへの連絡先がRTじゃなくなってた

RCバグ一覧見てたら、struts1の脆弱性がまだ直されてなかったので、RHのパッチもらってアップロードしてクローズしておいた。やれやれ、今日はRCを潰せたよ。

squeeze/wheezyも同じupstreamバージョンなので問題があり、セキュリティアップロードをする必要がある。
念のためdevelopers referenceで手順を確認してみた。するとWikiに記載があるよ→Wikiには「変わったよ、先日のメール参照」とあり、確認すると「RTの利用は止めた」とあった。

Security release workflow
- -------------------------
 
* We tried using Request Tracker for some time now. This hasn't
  worked out to our satisfaction, so we have already switched to track
  pending security updates with a text file in our Subversion
  repository. We were still using RT for non-public issues, but we're
  planning to track these in an external, private Subversion
  repository in the future. Most of the documentation has already
  been changed, a change to the developer's reference is pending.

なので、メールして待ってみることに。changelogの細かなバージョンを直すのがだるかった。

dakのバグを踏んだ

oldstable-security とstable-security に対してアップロードをしたのだけど、この2つのupstreamバージョンが同じで同じorig.tar.gzを使っていた。そしたら、どうやらdakがうまくハンドルできないようで再アップロードしてね、と連絡が。

due to a corner case in the dak installation for security-master, it cannot detect the orig tarball of the second tarball properly.

really upload

henrich@hp:~/tmp/build $ dput --force security-master libstruts1.2-java_1.2.9-5+deb7u1_amd64.changes 
Checking signature on .changes
gpg: 2014年05月31日 13時27分45秒 JSTにRSA鍵ID 2AAAB140で施された署名
gpg: “Hideki Yamane (Debian-JP) ”からの正しい署名
gpg:                 別名“Hideki Yamane ”
gpg:                 別名“Hideki Yamane (private) ”
Good signature on /home/henrich/tmp/build/libstruts1.2-java_1.2.9-5+deb7u1_amd64.changes.
Checking signature on .dsc
gpg: 2014年05月31日 13時27分45秒 JSTにRSA鍵ID 2AAAB140で施された署名
gpg: “Hideki Yamane (Debian-JP) ”からの正しい署名
gpg:                 別名“Hideki Yamane ”
gpg:                 別名“Hideki Yamane (private) ”
Good signature on /home/henrich/tmp/build/libstruts1.2-java_1.2.9-5+deb7u1.dsc.
Package includes an .orig.tar.gz file although the debian revision suggests
that it might not be required. Multiple uploads of the .orig.tar.gz may be
rejected by the upload queue management software.
Do NOT upload a package to the security upload queues without prior 
authorization from the security team.
See the following URL for instructions:
http://www.debian.org/doc/developers-reference/pkgs#bug-security
Please enter "really upload" (without the quotes) to proceed with the
upload.

security リポジトリにパッケージアップロードの際、指示がドキュメントにあるから読めよ、というメッセージの表示と、実際にアップロードについて「really upload」と確認で入力させてミスを防ぐようにしている様子。

dh-make微修正

久々にパッケージを作ったら、Vcs-*の修正が必要とか言われたので、テンプレートの方を直してBTSしといた

screenfetchをITP

まとけんさんの投稿で面白いと思ったのでscreenfetchをITPして、パッケージをアップロードしておいた。
manがなくてhelp2manで作ったらグッチャグチャになってしまったのはhelpのメッセージがplainじゃないからだろうか。