おのたく日記 YouTubeも始めました→

■ GitLab 15.6で「See multiple Code Quality scan reports per pipeline」が面白そう

なので有効化した

$ docker compose exec gitlab-ce gitlab-rails console
--------------------------------------------------------------------------------
Ruby:         ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]
GitLab:       15.6.0 (7f1a7c62df9) FOSS
GitLab Shell: 14.13.0
PostgreSQL:   12.12
-----------------------------------------------------------[ booted in 188.39s ]
Loading production environment (Rails 6.1.6.1)
irb(main):001:0> Feature.enabled?(:graphql_code_quality_full_report)
=> false
irb(main):002:> Feature.enable(:graphql_code_quality_full_report)
WARNING: Understand the stability and security risks of enabling in-development features with feature flags.
See https://docs.gitlab.com/ee/administration/feature_flags.html#risks-when-enabling-features-still

参考:

- How to enable and disable features behind flags

- [Feature flag] Rollout of `graphql_code_quality_full_report`

■ [GitLab] なんか出ないと思ったらpipelineのCodeQuality reportsはフリーではなかった

参照:

- Summary of features per tier - Code Quality ALL TIERS

- Code Quality reports PREMIUM

■ いつものようにomnibus Dockerイメージ版のGitLabを15.5から15.6にupgradeしようとしたらエラーが発生

Recipe: gitlab::database_migrations
  * ruby_block[check remote PG version] action nothing (skipped due to action :nothing)
  * rails_migration[gitlab-rails] action run
    * bash_hide_env[migrate gitlab-rails database] action run
      [execute] rake aborted!
                StandardError: An error has occurred, all later migrations canceled:
                
                PG::UndefinedTable: ERROR:  relation "index_issues_on_title_trigram" does not exist
                /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20221019194751_disable_fastupdate_on_issues_title_gin_index.rb:10:in `block in up'
                /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/with_lock_retries.rb:123:in `run_block'
                /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/with_lock_retries.rb:134:in `block in run_block_with_lock_timeout'
...
                /opt/gitlab/embedded/bin/bundle:23:in `load'
                /opt/gitlab/embedded/bin/bundle:23:in `<main>'
                Tasks: TOP => db:migrate
                (See full trace by running task with --trace)
                main: == 20221019194751 DisableFastupdateOnIssuesTitleGinIndex: migrating ===========
                main: -- transaction_open?()
                main:    -> 0.0001s
                main: -- execute("ALTER INDEX index_issues_on_title_trigram SET ( fastupdate = false ) ;\n")
      
      ================================================================================
      Error executing action `run` on resource 'bash_hide_env[migrate gitlab-rails database]'
      ================================================================================

また、2021年11月2日の日記「GitLab 14.4へのupgradeでエラー」みたいなことが発生しているのだろうとして検索してみると。

すでにIssueが立っていた#383540 Upgrade to 15.6.0 fails: relation "index_issues_on_title_trigram" does not exis

とりあえずのワークアラウンドは#378343 (comment 1182560762)なので、

$ docker compose up -d
$ docker compose exec gitlab-ce bash
root@gitlab-ce:/# gitlab-psql 
psql (12.12)
Type "help" for help.
gitlabhq_production=# CREATE INDEX index_issues_on_description_trigram ON issues USING gin (description gin_trgm_ops);
CREATE INDEX
gitlabhq_production=# CREATE INDEX index_issues_on_title_trigram ON issues USING gin (title gin_trgm_ops);
CREATE INDEX
gitlabhq_production=# CREATE INDEX index_merge_requests_on_description_trigram ON merge_requests USING gin (description gin_trgm_ops);
CREATE INDEX
gitlabhq_production=# CREATE INDEX index_merge_requests_on_title_trigram ON merge_requests USING gin (title gin_trgm_ops);
CREATE INDEX
gitlabhq_production=# quit
root@gitlab-ce:/# exit

と手早く打って、問題のマイグレーションの前に終わらせると、無事にGitLab 15.6が起動できた。

■ apt updateで

W: GPG error: http://dl.google.com/linux/mod-pagespeed/deb stable Release:
The following signatures were invalid: EXPKEYSIG 78BD65473CB3BD13
Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>

というエラーが出ている。

いつものように、2008年11月1日の日記の

$ gpg -v --keyserver subkeys.pgp.net --recv-keys 3CB3BD13
gpg: 鍵サーバからの受信に失敗しました: No keyserver available

で、keyを取得しようとするけど無いので

wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add -

として取ってきた。

■ [Kindle][Debian] Kindle for PC on Debian

以前から、Debian上でKindleを読みたくて、何度かWindowsアプリをLinuxで動かすWINEにKindle for PCをインストールしてみたけど、うまく動いたためしがなかったけれど、WINEのバージョンも上がっているので久々に試してみた。

https://www.amazon.co.jp/dp/B011UEHYWQ

Debianの普通のバッケージのWINEだと、インストールもうまく進んで登録まで行くのだけど、Amazonへのログイン画面が出ない。

どうやらWeb画面の描画ができず真っ白画面になっているらしい。WINEのWeb描画はwine-geckoを使うらしいけれど、Debianの普通のバッケージでは見つからず。

ちまたを調べてるみるとUbuntuでWINE HQだとうまく言っているらしい。

ということで、WINE HQにトライ。WINE HQ Downloadにあるように、

とやって、WINE HQ Debパッケージをインストールして、ユーザ環境は

で全部消してから

としたら、途中でGeckoのインストールが有って、Kindle for PCのユーザ登録画面もちゃんと出て使えるようになった。

起動メニューに wine-Programs-Amazon-Amazon Kindle-Kindle ができて、Kindoleの次の起動では1.26→1.30に無事に更新された。

ちまたの情報では、winetricksでcjkfontsバッケージやfakejapanese_ipamonaを入れるとか有ったけど、いれていないけど、日本語はちゃんと表示できている。

まち、winecfgで、Windows10にすると動かないのでWindows8.1という情報も有ったけど、DefaultのWindows 7からWindows 10に変えても動いている。(Windows 8.1のほうが安定しているかも)

■ Qterminalで文字が見えない

ダークモードが流行っているけど、どうも1980年代にグリーンディスプレイを

使っていた身には馴染めず。

昔話: APPLE][の80桁カードのビデオ出力を秋葉原で買ってきたジャンクのグリーンディスプレイにつないでいた。APPLE][本体のビデオ出力はカラーなのでカラーディスプレイだったけど、黒地に滲んだ白い文字だった。

ということは、当時からデュアルモニターだったんだ。

というわけで、Linuxのコンソールはブライトモード。最近のlsはCOLORSでカラフルに表示してくれるけれどLXDEからLXQtデスクトップに変えたら、カラーテーマがBlackOnWihteだと、なんか実行ファイルやシンボリックリンクの色が明るすぎて見にくい。スクリーンショット取り忘れたけどvimはもっと辛い。

そういえば、LXDEのときの

href="https://github.com/lxde/lxterminal">LXTermialのときには、設

定でパレットの色を暗くしていたのだった。

しかし、 QTermialには、同様なオプションは無し。各種ターミナルのカラースキーム設定値を作ってくれる4bit Termian Color Scheme DesignerにもQTermial用はなく。

ソースを調べてみると~/.config/qterminal.org/color-schemes/に

href="https://github.com/lxqt/qtermwidget/tree/master/lib/color-schemes">GitHub

lxqt/qtermwidget/lib/color-schemesを置くと良いらしい。

とりあえず、75%値を暗くした設定を作ってみた。

■ RSSリーダは、Blogline, Google Reader, Fresh Readerと移り変わってきたけど、いまはDebianのパッケージにあるTiny Tiny RSSを使っている。

おうちさーばを、PHP 8に上げたら読んだはずの記事が既読にならなくなってしまった。

Debianパッケージは、

tt-rss (21~git20210204.b4cbc79+dfsg-1) unstable; urgency=medium [ Sunil Mohan Adapa ]

* New upstream snapshot

* Add self to list of uploaders.

-途中略-

-- Sebastian Reichel Sat, 06 Feb 2021 00:54:20 +0100

[tt-rss (21~git20210204.b4cbc79+dfsg-1)より引用]

が最新版で、upstreamに入っているphp 8対応で入ってないので、とりあえず、以下だけ当てたら、正しく既読になるようになった。

diff --git a/classes/feeds.php b/classes/feeds.php

index 2c37d659a..cc78b498c 100755

--- a/classes/feeds.php

+++ b/classes/feeds.php

@@ -195,7 +195,11 @@ class Feeds extends Handler_Protected {

// frontend doesn't expect pdo returning booleans as strings on mysql

if (Config::get(Config::DB_TYPE) == "mysql") {

foreach (["unread", "marked", "published"] as $k) {

- $line[$k] = $line[$k] === "1";

+ if (is_integer($line[$k])) {

+ $line[$k] = $line[$k] === 1;

+ } else {

+ $line[$k] = $line[$k] === "1";

+ }

}

}

[tt-rss.git - Add workaround for boolean values being intergers with MySQL/PHP 8.1より引用]

■ PHP8が出てきた時に、Scuttleは自分で対応できたのだけど、Pukiwikiは結構修正する場所が多くて、PHP8に対応した1.5.4のリリースを待っていた。

3月27日には出ていたみたいなんだけど、年度末と年度始めで忙しくてやっと対応できた。

ついでに、1.5.3の時にトライしたけどうまく行かなかったUTF-8化もやってみた。対応ツールが2になっていて、今度はコマンドを実行するだけで、うまく行った。

まず、Wikiに書いてあるとおりのコマンドで、1.5.3をutf-8にして、その後、

としたところにファイルを上書きして、自分で修正していない部分は、VSCodeのgit viewで差分を見ながら、CTRL-K CTRL-Rで修正破棄をして、1.5.4に対応させた。lib/ plugin/ のファイルの殆どは、ファイルごと修正破棄なので、pukiwiki.ini.phpとスキン周りだけ注意深くすればOK。wiki/以下で変更を加えていたのは、サイドバーメニューなどの2つだけだったので楽勝。1.5.3に上げたときにはEUC-JPだったので、gitが使えず、emacsでのcompare-windowだったので、今回はずっと楽。

gitが使えるようになったから次のバージョンからは、upstreameブランチのpullと、ワークブランチへのmargeで出来るようになって楽になるはず。20年近く使っているPukiwikiも無事にUTF-8化され最新版の1.5.4にバージョンアッブできた。

これで、php7.4-fpmなどが要らなくなったので、php7.4関係のDebianバッケージをアンインストール。今後は、PHP8.1になった。

■ [Asterisk] upgradeで留守電が使えなくなる

Debian Package testing (13 bookworm)にAsterisk 18が落ちてきたのでupgradeしたら、留守電機能が使えなくなってしまった。

良く分からなかったのだけど、調べてみたらupstreamが18になったときのDebianパッケージのチェンジログで

asterisk (1:18.9.0~dfsg+~cs6.10.40431411-1) experimental; urgency=medium

--中略--

* package asterisk-modules now include modules

app_voicemail app_voicemail_imap app_voicemail_odbc;

drop packages asterisk-voicemail

asterisk-voicemail-imapstorage asterisk-voicemail-odbcstorage;

add NEWS entry that users of imap or odbc variant

need to adjust configuration

--中略--

-- Jonas Smedegaard Fri, 04 Feb 2022 21:59:09 +0100

[Changelogより引用]

どうやら、astersik-voicemailパッケージの内容がasterisk-modulesパッケージに組み込まれたらしい。

それなら、そのまま動くはずだけど

[options]

verbose = 3

[/etc/asterisk.confから抜粋より引用]

としてログを確認すると

2022-04-03 02:48:30] ERROR[1444808] app_voicemail_odbc.c: Failure registering applications, functions or tests

[2022-04-03 02:48:31] ERROR[1444808] loader.c: app_voicemail declined to load.

[2022-04-03 02:48:31] ERROR[1444808] loader.c: app_voicemail_odbc declined to load.

[/var/log/asterisk/messagesより引用]

ということで、app_voicemailのロードでエラー、Asteriskコンソールで'module show'すると

app_voicemail.so Comedian Mail (Voicemail System) 0 Not Running core

app_voicemail_imap.so Comedian Mail (Voicemail System) with IM 0 Running core

app_voicemail_odbc.so Comedian Mail (Voicemail System) with OD 0 Not Running core

[module showの出力から抜粋より引用]

ということで、今までは入れていなかったasterisk-voicemail-imapや-odbcパッケージに入っていたapp_voicemail_imapが先にロードされてapp_voicemailが走っていない。

そこで、moudle.confにnoloadを書いたらAsteriskの留守電が動くようになった。

noload => app_voicemail_imap

noload => app_voicemail_odbc

[/etc/asterisk/modules.confより引用]

■ Debian Bookworm (testing 12)にphp8.1が入ってきたので、php7.4を消してphp8.1に統一したら、Debianパッケージでインストールしたものは動くけど、自分でインストールしたものは、あちこち動かない。

scuttleは、php8での変更点、コンストラクタの名称変更(クラス名ではなく__construct()になった)や、未定義変数のアクセスでエラーになることにより、動かなかった。もうgithub上では10年以上メンテナンスされていないので自分でバッチした。

pukiwiki 1.5.3は最新版だけどphp8には未対応。1.5.4で対応予定で、まだリリースされていないので、php7.4-fpmパッケージをインストールしなおして、

<IfModule !mod_php7.c>

<IfModule proxy_fcgi_module>

<FilesMatch ".+\.ph(ar|p|tml)$">

SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"

</FilesMatch>

</IfModule>

</IfModule>

[.htaccessより引用より引用]

で、pukiwikiだけphp7.4を使わせて対応。

■ 1月20日の日記で壊れたSMR瓦書きのHDD Seagate Barracuda ST8000DM004を、CMRだけど安いとニュースにあったWD80EAZZにリプレイス。

2021年1月16日の日記に書いたように、四日間かかったSMRとは違い、6時間程度で終わりそう。

後、外した壊れたHDD Seagateの保証のページで調べたら、保証期間中のようなので、郵送して交換してもらうことにした。