カテゴリー: ソフト関係

ちょっとした小技

LinuxからWindowsに戻すと時刻が-9時間となって鬱陶しいです。

[xxxxx@localhost ~]$ timedatectl
               Local time: 日 2022-03-13 12:15:19 JST
           Universal time: 日 2022-03-13 03:15:19 UTC
                 RTC time: 日 2022-03-13 03:15:20
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

それは上記のようにPCの内部時計(RTC)がUTCに同期してしまうからです。LinuxサイドではRTCのデーターから指定されたTimeZoneデータを元に現在時刻を出すので問題無いのですが、WindowsはRTCがローカルタイムであることが前提になっています。
これだとWindowsに戻ったときにいちいち時計合わせしなくてはならず、面倒なので、LinuxサイドのRTCをローカルタイムに合わせてみます。

[xxxxx@localhost ~]$ sudo timedatectl set-local-rtc 1
[xxxxx@localhost ~]$ timedatectl
               Local time: 日 2022-03-13 12:21:18 JST
           Universal time: 日 2022-03-13 03:21:18 UTC
                 RTC time: 日 2022-03-13 12:21:18
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

しかし、「いろいろと不都合が出るかもよ」と”脅されます”。ならばともう一度調べたところWindows側のRTCをUTCに合わせる方法もあるとのこと。普段はLinuxなので、Windowsの方を合わせることにしましょう。

Videoカード交換その2

本番環境はFedoraなので、そちらを起動。するとKDEのスクリーンになったところで固まってしまいGUIの反応がなくなります。ただし別に起動しておいたKonsoleは動いているので、システム全体が死んだわけでありません。

クリーンインストールが必要かと勘違いしてbootable mediaを作成。でもやっぱり同じく固まる。ならばとMint Desktopのbootable mediaを作成して試したところこらはOK。

しばらくMintで凌ぐかと考えたのですが、よく考えてみたらドライバーが不適合なだけと言うことに気がついてnVidiaのドライバーをインストール。rpmfusion-non-freeにドライバーがあるので、rpmfusion-non-freeをenableにしてインストール。ようやく全体が正常に動くようになったのでした。

[xxxxx@localhost ~] sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
[xxxxx@localhost ~] sudo dnf install akmod-nvidia

AMDならともかく、NvidiaのGeForceシリーズならデフォルトでカバーされているものとばかり思っていたのでこれは意外でした。もっともMintではそのままでOKでしたから、これはKDE特有の問題かもしれません。KDEの人はNvidiaが嫌いなのかな(笑)。

Videoカードの交換でドライバーが必要になったのは、2013年にAMDのカードに変えた時なので、9年ほど遭遇しなかった事態です。なのですっかり忘れてちょっと焦ったのでした。

3月21日追記

どうにも各ウィンドウの中身の表示がちらついたりして落ち着きません。Nvidiaの場合、cudaドライバーも入れないと駄目だとのことなのでインストール。
cudaってGPUで演算するための機構というイメージが強いので、別にいいかと思ったのでした。記事によっても「入れてもいいよ」から「入れないと問題が起きるかもね」まであっていろいろ。

[xxxxx@localhost mak]$ sudo dnf install xorg-x11-drv-nvidia-cuda
=====================================================================================================================
 パッケージ                       Arch           バージョン                  リポジトリー                      サイズ
=====================================================================================================================
インストール:
 xorg-x11-drv-nvidia-cuda         x86_64         3:510.47.03-1.fc35          rpmfusion-nonfree-updates         1.8 M
依存関係のインストール:
 nvidia-persistenced              x86_64         3:510.47.03-1.fc35          rpmfusion-nonfree-updates          34 k
 opencl-filesystem                noarch         1.0-14.fc35                 fedora                            7.4 k

トランザクションの概要
=====================================================================================================================
インストール  3 パッケージ

cudaを入れたところなんとなく落ち着いた感じ。まだ再起動していないので本当かどうかはわかりませんけど。

さらに追記

cuda入れても変わりは無し。なのでwaylandをあきらめてxorgにスイッチ。今のところ落ち着いている感じ。多少はパフォーマンスが落ちるんでしょうけど、安定がなにより第一!

KiCAD V6その4

どうにか時間が取れたので、本体のbuild開始。30分くらいで終わった気がします。

今回、VSでProjectを開くのにドキュメントと違う方法試したところドはまり。cmakesettings.jsonにswig.exeとpython.exeのありかを書いておけば、特に何も追加指定せずに実行できるはずと、あれこれやりましたがエラーが取れなくて一旦中止。cmakesettings.jsonの書式を勉強しないとだめですね…

今度はドキュメント通りにprojectを開き、ドキュメントにある通りにswig.exeとpython.exeの在処を書き込んでビルド開始。ビルドオプションは生成するオブジェクト毎に分かれています。x86-debug,x86-release,x64-debug,x64-release,MSYS2-x64-debugとあるのですが、x86とMSYS2は使用しないのでx86の2つにだけ追加。

出来上がったのはよいのだけど、何このバージョン表記。またnightlyからソースを引っ張ってきてしまったようだ… 進歩無いな。もう一度6.01のソースをとってくるところからやり直さなきゃ。

KiCAD V6その3

いろいろ情報を漁っていたところ、文字コードをUTF8にするオプションが有ることを発見。コントールパネルの「時計と地域」→「地域」→(管理タブ)と辿っていくとUnicode対応というチェックがあります。ベータと書いてあるのが気になりますが、デフォルトで用意されているのだからと、チェックを入れて再起動。再度vcpkgの作成に挑戦します。

文字コード変更

その結果は大成功で、止まることなく進行していきます。嬉しいことにネイティブ環境なので、当たり前ですがVM環境下より早い。途中でlibiconvだったかがエラーになっていたのだけど、全体として停止せずに進んでいるので必要無いってことなんだろうか? これは後でどう影響するか気になります。まぁ実行する前にもう一度構築してみますかね。

さてVM環境下ではかなりの時間を要したvcpkgの構築、どの程度で終わるのか楽しみだ。

16:55追記

外出から戻ってきたら終わってました。所要時間は2.8hとのことですから2時間50分ほど。VMの時は7時間以上だったので大幅短縮です。buildもこの調子だと嬉しいな。

2月13日追記

vcpkgが更新されていたので、gitで取り直して更新。途中sqlite3の処理でエラーになったけど、再度実行したら止まることなく実行中。なんだったかな?

KiCAD V6その2

メインフィールドであるFedoraにRawideではありますが、正式に6.0が来たのでソースをチェック。いつもの所にお馴染みのnewstroke_font.cppを発見。ならばと早速ファイルを入れ替えてrebuild。結果は予想通りで、全部の文字を確認したわけではありませんが、ざっと見た範囲では幅の問題が解決しています。

と言うことは、Windows側でもまだRebuildはやる価値ありということで、再びがさごそ。
しかしMsys利用のWinbuilderは対応が5.12で止まっています。PKGBUILDの中身をいじれば良いのでしょうが、正規に提供していないということは何か問題があるんだろうと思わせます。

ならば丁度よいと思い英語環境のユーザーを追加してVisual Studio利用での作成に挑戦。
しかし、vcpkgの処理中にwxPythonの文字コード問題が発生してエラー停止。CP1251でも結果は一緒です。
普通に日本語環境で試した時と同じ結果で、使用言語を英語にしただけではベースの文字コードが変わらないので問題は解決しない模様なんだけど、全体の文字コードベースをUTF8にする方法が有るらしいので、いったんそちらを試してみますか。

それにしてもこのsh●tなパッケージを使い続けている理由が分からないなぁ。ベースのpythonでもV2からV3への移行で大問題が発生しているので個人的には関わりたくない言語です。とは言え人気が有り、高校の情報の授業でのプログラミングの題材として利用されていのをよく見かけますので、とっつきやすいんでしょうかね。

と言うわけで、またMSから英語版Windows11の開発環境イメージを落としてきてそちらの環境で試してみましょう。

Fedora35その4

大量のKDE5のアップデートが来ました。5.89->5.90なのですが、rebuildで問題発生。

当初kf5-kconfigのrebuildで余計なファイルであるlibKF5ConfigQml.so.なんとかが邪魔と怒られます。なのでspecファイルに余計な奴らを削除するように指示を追加して問題解決。
ところがその後、少なくないファイルのrebuildがfailで止まります。5.89のときは無かった現象なので何が起きたのかBuild Logを読んでみます。
すると…

CMake Error at /usr/lib64/cmake/KF5Config/KF5ConfigTargets.cmake:89 (message):
The imported target "KF5::ConfigQml" references the file
"/usr/lib64/libKF5ConfigQml.so.5.90.0"
but this file does not exist. Possible reasons include:

まさしく先程のkf5-kconfigのrebuildで消したファイルが無いと怒られています。
再びkf5-kconfigのspecファイルを変更してlibKF5ConfigQml.soとかなんとかをcoreファイルとdevelファイルに入るようにしてrebuildして再インストール。
そうしたら問題が解決したのでした。

  • kf5-kcompletion-5.90.0-1.fc35.src.rpm
  • kf5-kconfigwidgets-5.90.0-1.fc35.src.rpm
  • kf5-kcontacts-5.90.0-1.fc35.src.rpm
  • kf5-kfilemetadata-5.90.0-1.fc35.src.rpm
  • kf5-kglobalaccel-5.90.0-1.fc35.src.rpm
  • kf5-knotifications-5.90.0-1.fc35.src.rpm
  • kf5-kservice-5.90.0-1.fc35.src.rpm
  • kscreen-5.23.5-1.fc35.src.rpm
  • plasma-systemmonitor-5.23.5-1.fc35.src.rpm
  • plasma-workspace-5.23.5-1.fc35.src.rpm

以上がこの問題に引っかかっていたファイル。結構大物が含まれています。

おそらくはrebuildなんて酔狂なことをしなければ問題にはならなかったのでしょうけど、検証ってどうなっているのやら。Bugzillaに報告を上げたほうがよいのだろうか?

KiCad V6

年末ぎりぎりのタイミングでVer.6が公開されました。私のメインフィールドであるFedoraはRawhideが6.0rc1で、本提供は5.12で止まっていますので、Windows版でテスト。

  • SCH V6
  • PCB V6

噂通り、そのままの状態で日本語が表示されます。なんとなくカナ部と漢字部の幅の割当が間違っている気がしないでも無いのですが、例の大騒ぎをしなくても良いのは助かります。まだソースは見ていないのですが、newstoke_fontを入れ替えれば解決するのかな?

Fedora側の-o3処理祭りがようやく7割方終わったところなので、片付いたら試してみますか。
その前に現在SSDをつなぎ替えるという力技でFedoraとWindowsを切り替えているので、Dual Bootできるようにハード側の整備をしなくては。

Fedora35その3

bootの問題が解決したし、日本語入力の問題もほぼ解決したようなので、-o3化を進めていきます。
その過程で出てきた新しい問題が、

doxygen: symbol lookup error: /lib64/libclang-cpp.so.13: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE8_M_eraseEmm, version LLVM_13

なにやらわけのわからない名前のシンボルが見当たらないと苦情が出ます。
この問題は結構な数のモジュールで発生している模様なので解決しないとなりません。調べてみると2017年頃にGCCのバージョンが変わったことで一時発生していたようですが、ここ最近は話題になっていない模様。

もう一度エラーログを見直すと、libclang-cpp.so.13に有るはずのものが見当たらないのが問題だと言われてます。そう言えばclang自体も早々に-o3化を済ませていたのでしたが、もしかしてと思いdnfを利用してclang-libs.x86_64をインストールし直したところ問題解決!。

結局のところこの問題のシンボルは空のエントリかなにかで、-o3の時に「無駄だから削除」となったのでしょう。-o3の意外な副作用でびっくりさせられましたが、他にも起きているかもしれません。改めて問題が起きたらその時に考えましょう。

この問題が解決した後はスムーズに進行。CPUが同じ第4世代とは言え、i5からi7になったことと、メモリーが8Gから16Gになったことでリビルドにかかる時間も25%ほど短縮されたようです。
firefoxが2.5時間、thunderbirdが1.5時間、Kicadも1.5時間くらいですから、このくらいなら待てますね。ちなみに33時代のfirefoxはリビルドに8時間かかってましたが、あれは何だったのかな。

残る常用する大物はlibreofficeだけど、関係モジュールが多数なので準備が面倒。まぁこの週末に退治しますか。

Fedora35その2

日を置いて再挑戦したところ全てがスムーズにいくようになりました。

結局はgrub2の問題だった模様。インストール時に入るバージョンは2.06-6なんですが、問題なく使えている現在は2.06-10。
実は途中で2.06-8ってのが有って、こついが悪さしていた模様です。実際に吹っ飛んだ時のアップデートリストに入っているのも2.06-8ですしね。

なにはともあれ無事にアップデート後に無事に再起動できるようになりました。34時代のデーターは書き戻したので、後は恒例の-o3祭りですね。相変わらず一進一退で現在残600余りと、まだ先は長そうです。

それはそうとして、gtk環境が支配するアプリケーションでは今のように日本語が入力できるのですが、KDE環境下だとibus自体が不調のようで入力不能に。

audacityなど日本語を使いたくなる場面が多いので、logでも読んで調べてみないと。

Fedora35苦戦中

Kicadの方が一段落したので、本当の目的であるFedoraの環境構築。それが今回はとても手強い。いままでの環境との違いと言えば、いままではBIOS経由だったのが、今回からはUEFI経由のBootとなったくらいのはずなんですが、謎の現象が起きていて全く落ち着きません。

インストール自体はUSBメモリースティックにインストーラーパッケージを入れてやってそこから起動するだけのことで、難しいことはありません。ものの20分もあれば終わるくらいのお手軽なもの。

ところが、Fedora恒例のインストール後のUpdateをかけるとあっという間に起動不能となります。「Boot Sector not found…」てなメッセージが出るのでどうにもなりません。

一番最初は画面が一面「水色」となる現象が出たので、ビデオカードの不調で吹っ飛んでドライブがこけたのかと思ったのですが、どうも違う様子。だいたい同じハード構成のWindowsはクリーンインストール後は実に安定しているので、ハード系の問題では無いはず。
ドライブの構成の問題かと思い、完全手動構成、完全自動構成、LVM使用の自動構成といろいろと試しましたが、どの構成でもUpdate終了後の再起動ができなくなる事にはには変わりなく、しかもネット上にもほとんど情報がなくて大弱り。

謎なので、VM上にインストールしてupdateしてみましたが、全く問題が発生しません。

起動系をいじくるのはgrub2しか無いのでgrub2の更新をせずに他を更新した場合にどうなるのか試してみましょう。