fedora12の2.6.3x系で起動できないという話
- Common F12 bugs - Fedora Project Wiki
- Fedora12の公式バグ
- 知人が新しいkernel(2.6.3x)でbootできないと言っていたけど、どれのことだろうか
- The Bugme-janitors September 2009 Archive by thread
- 14211 – Kernel hangs on Compaq Evo N800c with ACPI enabled
- これは古いから今回の件とは違うとは思う
- Red Hat Bugzilla Main Page
- redhatのbugzilla
yast wagonとか
opensuse使ってる人のサイトが増えてくれると嬉しいなー
google:yast wagon
http://en.opensuse.org/Wagon
http://red456.blog5.fc2.com/blog-category-31.html
http://ja.opensuse.org/Upgrade/Supported
http://ja.opensuse.org/Zypper/Usage/11.1
`foo-branding-upstream'ってな感じのパッケージの命名規則について
modelineの中でfencを設定してはいけない
- ファイルをバッファに読み込み
- BufRead/BufReadPostイベント発生
- モードライン読み込み
- バッファがウィンドウに表示
- BufWinEnterイベント発生
参考
:help autocmd.txt
Vim の modeline で fileencoding を設定すべからず: まじかんと雑記
Header V3 DSA signature: NOKEY, key ID
zypper upでこんなん出てくる。
GPG keyが無いと言われてるのだろうか。
http://pc11.2ch.net/test/read.cgi/linux/1259099273/352
[ Linux ] SUSE Linux Part 25352 名前:login:Penguin [sage]: 2010/01/23(土) 19:04:48 id:E5Tr/Ud/
zypper upすると、何かのパッケージで毎回警告が出てきます。warning: /var/cache/zypp/packages/repo_2/i586/gstreamer-0_10-plugins-base-lang-0.10.25-999.pm.1000.12.i586.rpm: Header V3 DSA signature: NOKEY, key ID 9a795806
gpg-keyの取得したはずですし、
yast repository -> GPG Keys
には追加してあるレポジトリのkeyを全て持っている状態が確認できます。
何が原因なのでしょうか。
353 名前:login:Penguin [sage]: 2010/01/23(土) 19:37:09 ID:8Wu14WIy
>>352
そのIDはpackmanの鍵だよ。$ gpg --recv-keys 0x9a795806
のようにして自分のキーリングに鍵をインポートしてから、
$ gpg --export -a 0x9a795806 > packman.txt
のようにして鍵をファイルに書き出し、
作成したファイル(packman.txt)をyastから読み込めばいい。
ふむ。
$ gpg --keyserver pgp.nic.ad.jp --search-keys 0x9a795806
gpg: searching for "0x9a795806" from hkp server pgp.nic.ad.jp
(1) PackMan Build Service (PackMan Build Service)
1024 bit DSA key 9A795806, created: 2007-08-10
確かに見つかる。
ここで、pgp.nic.ad.jpは国内の鍵サーバ。
http://pgp.nic.ad.jp/
(See http://pgp.nic.ad.jp/faq/index.html)
他の国内の鍵サーバには、http://openpksd.org/
がある。
openpksd.orgのウェブページの左上のフォームから
0x9a795806を探すと、Packmanの公開鍵を見せてくれるのだけれど、
コマンドからクエリをかけると、
$ gpg --keyserver openpksd.org --search-keys 0x9a795806
gpg: searching for "0x9a795806" from hkp server openpksd.org
gpg: key "0x9a795806" not found on keyserver
と言われてしまう。
まあ、兎にも角にもPackmanレポジトリの鍵は0x9a795806で正しそうなので
インポートしておくことにしましょう。
■
- Arch Linux
- 今度入れよう
- GitHub - lich0x2b/barewm: BareWM - A minimal window manager
- タイル型のウィンドウマネージャ(フルスクリーンタイプ)
- The Traditional Vi
- Viのソース
- 基本は『三段構成』――今さら聞けないビジネスメールの書き方 - はてなニュース
- 前文→本文→末文 の3段構成
- 前文
- 挨拶
- 本文
- 30文字程度で改行
- 相手が返信の際に困るような、余計なことを書かない
- 末文
- 結びの言葉。記事には無味乾燥な文面よりも云々書いてあるが・・・
TODO: git
githubの使い方をまとめたエントリー(github使い方まとめ - bugfix)を
嬉しいことに、こちらで参考にしていただいた。
雲雀は高く空を舞い - ひよこの会
ふ 2009/11/18 01:51
"git fetch origin: " は間違いではありませんが古風ですね。現代のgitなら、単に"git fetch"して、origin/ から使う、というのが標準的だと思います。 ネタ元のウェブページを更新してもらったら良いかも知れません。
「正しいけど、最近のやりかたではない。」
こういう意見はとてもありがたい。
最近gitに関する書籍を買ったので、
その内容も含めて、修正しよう。
一般ユーザでmountできるようにする
http://www.momonga-linux.org/docs/Removable-HOWTO/ja/mount_by_user.html
デバイス名は固定にしなくてはならないのだろうか。
PCを起動してから最初に挿されるUSBフラッシュメモリは、
俺の環境だとsdb1になるから
# mount -t auto -o user,noauto,rw /dev/sdb1 /mnt/tmp
を発行するとして、/etc/fstabに
/dev/sdb1 /mnt/tmp/ auto user,noauto,rw 0 0
としておけば、一般ユーザに
$ mount /dev/sdb1
とコマンドしてもらえば、/mnt/tmpにマウントされて、
このディレクトリ以下のファイルは全て、マウントしたユーザのパーミッションになる。
例外
つまり
- USBフラッシュメモリという括りでディスクを認識したい。
- 2本目以降は、/mnt以下に自動でディレクトリを作成してマウントしてほしい。
- 作成するディレクトリ名はユニークなものが必要。
- umountしたら消してくれると、尚嬉しい。
Win32開発
- Windows SDKをインストール
- Visual Studio側でライブラリやインクルードフォルダのパスを設定
- 「ツール」→「オプション」→「プロジェクトおよびソリューション」→「ディレクトリを表示するプロジェクト」
- 「実行可能ファイル」、「インクルードファイル」、「ライブラリファイル」を追加する。
これをやらないと、windows.hが見つからないとか出てきた。
昔使っていたPCでは、設定されていたってことかー。
※追加するフォルダを忘れてしまった時には、
「C:\Program Files\Microsoft SDKs\Windows」(規定)の下をwindows.hでfind掛ければいいと思うよ。
find -prune
$ find . -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' ./Projects/fooWin32/fooWin32/fooWin32.cpp ./Projects/fooWin32/fooWin32/fooWin32.h ./Projects/fooWin32/fooWin32/Resource.h ./Projects/fooWin32/fooWin32/stdafx.cpp ./Projects/fooWin32/fooWin32/stdafx.h ./Projects/fooWin32/fooWin32/targetver.h ./Projects/fooWin32_/fooWin32_/main.c ./Projects/tmp/tmp/main.cpp ./Projects/tmp0/tmp/Resource.h ./Projects/tmp0/tmp/stdafx.cpp ./Projects/tmp0/tmp/stdafx.h ./Projects/tmp0/tmp/targetver.h ./Projects/tmp0/tmp/tmp.cpp ./Projects/tmp0/tmp/tmp.h ./Projects/vector_capacity/vector_capacity/main.cpp $ find . -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' -o -ipath '*tmp*' -prune -type f ./Projects/fooWin32/fooWin32/fooWin32.cpp ./Projects/fooWin32/fooWin32/fooWin32.h ./Projects/fooWin32/fooWin32/Resource.h ./Projects/fooWin32/fooWin32/stdafx.cpp ./Projects/fooWin32/fooWin32/stdafx.h ./Projects/fooWin32/fooWin32/targetver.h ./Projects/fooWin32_/fooWin32_/main.c ./Projects/vector_capacity/vector_capacity/main.cpp
ただし
$ find . -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' -o -ipath '*tmp*' -prune -type f -print
何も表示されない
$ find . \( -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' -o -ipath '*tmp*' -p rune -type f \) -print ./Projects/fooWin32/fooWin32/fooWin32.cpp ./Projects/fooWin32/fooWin32/fooWin32.h ./Projects/fooWin32/fooWin32/Resource.h ./Projects/fooWin32/fooWin32/stdafx.cpp ./Projects/fooWin32/fooWin32/stdafx.h ./Projects/fooWin32/fooWin32/targetver.h ./Projects/fooWin32_/fooWin32_/main.c ./Projects/vector_capacity/vector_capacity/main.cpp