Arch Linux 18

公式
https://www.archlinux.org/

ArchWiki
https://wiki.archlinux.org/

フォーラム
https://bbs.archlinux.org/

インストールガイド (英語, 日本語)
01. https://wiki.archlinux.org/index.php/Installation_guide
02. https://wiki.archlinux.jp/index.php/%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%82%AC%E3%82%A4%E3%83%89

※ 質問はインストールガイドを熟読し、ArchWiki、フォーラムを検索してから。
※ 次スレは>>980が建てること。

前スレ
Arch Linux 15
https://mao.5ch.net/test/read.cgi/linux/1568434521/
Arch Linux 16
https://mao.5ch.net/test/read.cgi/linux/1613324251/
Arch Linux 17
https://mao.5ch.net/test/read.cgi/linux/1659058308/

>>228
誤爆ウザい

なんか今回のことで日経Linuxが廃刊になった理由が分かった気がした

問題ってね
見たくなければ見えないのよね
なんでロケットが打ち上げ失敗するか分かったでしょ

こんなんでもね
へっ素人が事情も知らずに偉そうに
みたいな感じで終わっちゃうのよね
現に失敗してるって一番重要なことはワキによけてね
んで進歩は無くなる
そんなもん

問題点って誤魔化そうとすれば幾らでも無限に出来るからね
今流行りのウソつき大谷事件とか典型ね

Archの問題でもなければましてやLinuxの問題でもない
Archの想定するユーザーでない人が何となく格好いいから程度の理由でArchを使おうとすることにより生じる問題だろう
Archが想定するユーザーは自力で直せるか、少なくとも修正に必要十分な情報をコミュニティに提供できる人だけ
以下の「1.4 ユーザー中心であること」をよく読むべき
https://wiki.archlinux.jp/index.php/Arch_Linux

>>224
俺の環境でも起きてる。設定 > 仮想キーボードで fcitx5からfcitx5ランチャーに選択した時点で
キーボードレイアウトがもれなくUSに変わり、loadkeys コマンドも全然効かない(動くがus に
しようがjp106にしようが結果に反映されない)。
/etc/locale.conf も /etc/vconsole.conf も正常。
　で、対策としては起動したらキーボードを設定し、あとはスリープを使う。という超後ろ向き
対策。Macで使ってる英語キーボードをこっちでも使ったら解決なのかも。

fcitxはキーボード設定を上書きするらしい
fcitxの設定で解除できる

さんくす。
fcitx5設定画面が、ツールチップメニューの設定からしかいけなくなってたことと、そこで
入力メソッドオフが今までUSでもよかったのがキーボード・日本語を設定しないといけなくて
そいつが普通の設定のキーボードのレイアウトを上書きする
というトラップ

一見さんには分からんわ

ちがった。
お気に入りテーマを入れようとして説明見たら設定で入力メソッドが後ろの方にあって、そっちで
やることって書いてあって。。。恥。

上書きしているわけじゃなくて、個別で設定を持っているだけだろ。
確か、vconsole.confはdebianにはない設定ファイルだし。

~/.config/fcitx5/profile
ではなくて？

個人設定だけどなぜ全体の設定で出来ないのか…
fcitxって全体の設定はあるのだろうか？
iBusの方が好みだけどAUR使わないとだしね

/etc/vconsole.conf はArch系にしかないので、fcitx configration toolが気を利かせて
vconsole.conf と連動しろよってのはfcitxには酷な話。
　逆に設定画面で言語と地域の主ペインを入力/出力デバイスの主ペインの前に持って
きてればユーザが入力メソッドに先に目が行くだろうにって思ったりするが、それで
困ってんのは日本人と中国人くらいだろうからなあ。

>>224
カスタマイズやテーマを設定できるので全体設定でやられたら他ユーザーに影響が出ちゃう

vconsole.confってsystemdが読んでんのかと思ってたけどArch固有なの？

エラーが出た

arch固有ではないだろ
俺のfedoraにもいる

https://www.freedesktop.org/software/systemd/man/latest/vconsole.conf.html

xz にバックドア問題。メンドクセー

ﾋｪｯ
更新するだけで安心してええんか？

>>251
とりまArchユーザーは、修正版入れるしか無いよね
他のディストリは、ダウングレードしろとか言ってるとこも
あるようですけど、それだって安全かどうか分からない
って意見もあるようです
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
https://forum.manjaro.org/t/xz-package-contains-a-vulnerability/159028
https://forum.endeavouros.com/t/the-upstream-xz-repository-and-the-xz-tarballs-have-been-backdoored/53253

もうOpenBSDのチームで作られたものしか信用できない…

今すぐアップグレードしろってアナウンス出てるな

Arch Linux - News: The xz package has been backdoored
https://archlinux.org/news/the-xz-package-has-been-backdoored/

>>254
それ読んでたんだけど、
ldd "$(command -v sshd)"
ってやって、「liblzma」が出てこなければ
とりあえずは、大丈夫って書いてあんね

ただ、この問題のコミッター2年ぐらい前から活動してて700件ぐらいコミットしてたらしいし
他にもなにかあるかも知れないから、注目しとかないと

残念な事にアクティブなメンテナの一人が実行犯のようだからxxなら信用出来るという類いのものではないような
報告者は偶然バックドアに気が付いたらしいけど、しばらく放置されてRHELやdebianのstableにも入ってたら大問題だっただろうな

奴が関わった部分は精査しないとな、脆弱性の種が仕込まれてるかも
これを発見したのがMicrosoftのエンジニアってのがなかなか…

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
計画的だな
https://github.com/google/oss-fuzz/pull/10667

>>257
几帳面にベンチマークとるデータベースシステムのエンジニアが偶然見つけた感じ
本当にラッキーだったね

もし過去のコミットにも仕込んでてstableなディストロにまで波及したら大事だな

libarchiveにもJiaT75が疑わしい変更を加えていた模様(2021年

ネットバンクのパスワードと抱えたほうがいいの？(´・ω・｀)

>>252
他のディストリビューションはsshで外に晒してた奴は
クリーインストールで入れ直せって言ってるぞ
あと認証関係全部やり直し

>>263
それ、侵入されちゃった可能性があるからじゃないの？
Archは、sshとリンクしてないから大丈夫

>>246
そうなんだ
ありがとう

散々古いだのパッチが多いだの文句言われてるdebianの仕組みが役に立ったのか。

liblzmaに関してはxzの上流が配布してるtarballに悪意のあるもんが含まれてたけどgithubで公開されてる方には入ってなくてArchは後者の方使ってたから一応それに関しては実際は問題ないって話もあるみたい？
まあ攻撃者があちこちにいっちょ噛みしてて他にも色々出てきそうやけど

>>266
でも
Archは余計なパッチ入れてなかったから助かったんですけど…

>>267
そもそも、Archでは、sshとリンクするパッチないんで攻撃成立しないけど
念の為、ソースを変更した、xz 5.6.1-2を緊急でリリースした
って感じだと思いますよ

これはほんとにたまたまだろ。
archの場合は基本的に何もせずにただ放流するだけだから、こういう類の攻撃には一番脆弱といえる。
それに、今回のはfedoraやsuseなども影響受けているので、任意のライブラリであってもほぼ必須扱いなものということだろう。

>>269
そうそう
たまたま、一番脆弱なはずの、Archだけが影響うけませんでした

他にも何か仕込まれてる恐れがあるから
JiaT75が関わる以前の5.3.1に戻したほうがいいって話もあるな

でもそこまで戻したら依存関係で色々ぶっ壊れるって言ってるね

5.3.1ベースに元からのメンテナーに頑張って修復してもらうしかないな

アメリカさんあたりがテロリストとして犯人○してくんねぇかね

物騒なこというな

>>255
てかこの対処あかんやろ
lddのmanに書いてあるけど信頼できるかわからん疑惑の実行ファイルに対してlddすんのはアウトや

>>276
ちょいちょい、その指摘されてますけど
ぶっちゃけ、対処ってか、確認だから、やる必要ないっすよ
とりまArchユーザーがやるべきことは、いつも通りアプデして、xz 5.6.1-2
に更新するだけです

問題ってね
見たくなければ見えないのよね
なんでロケットが打ち上げ失敗するか分かったでしょ

こんなんでもね
へっ素人が事情も知らずに偉そうに
みたいな感じで終わっちゃうのよね
現に失敗してるって一番重要なことはワキによけてね
んで進歩は無くなる
そんなもん

問題点って誤魔化そうとすれば幾らでも無限に出来るからね
今流行りのウソつき大谷事件とか典型ね

.





問題点って





誤魔化そうとすれば幾らでも無限に出来るからね





今流行りのウソつき大谷事件とか典型ね





.

違法賭博は大谷がやったんだよ。でもそれ言うと極悪人みたいな扱いになっちゃうでしょ？
問題点に注目するヤツは「空気の読めない悪人」だから。
これをLinuxでもロケットでも政治でもやるわけな日本人は。

スクリプトと会話しようとするな

ChatGPTで寂しさを紛らわしていた人かな

脆弱性の件でシステムアップグレードしてから起動してるといつの間にかハングアップすることが増えた

俺のは特に問題ないな

NVIDIAのドライバをアップグレードするときにファイルが競合したから強制上書きオプションつけてやったんだよね
ゲームは特に問題なかったから関係なさそうだが
またシステムアップグレードしてみるか

nvidiaのドライバは最近不具合多いらしいね

いつの間にかWaylandでNVIDIAドライバから出力したディスプレイのリフレッシュレートが正常になってた

sstp使えます？

ゲームのfpsもx11の方がいいらしいし、waylandにするメリットって何？

waylandはモダンで安全性や保守性の高い仕組みで作り直したいという開発側の都合で始まったものに過ぎないので
単なるユーザーとしてはwaylandの方が完全に上位互換と見なせるようにになるか十分に普及するまで使う意味はない

Xはもうメンテナンスしてる人いないから
将来性が全く無いのと、セキリュティの面でも穴だらけ

Windows7でいいと言っているようなものか

実際win10出るまでは7使い続けるのが正解だっただろ

実際win10出るまでは7使い続けるのが正解だっただろ

>>291
KDEの話ですが、タッチパッドのジェスチャーとかタッチパネル系とか
そういう新機能はWaylandにしか追加されないので
ラップトップで使ってるとかならメリットはあるかもです
もともと、モバイルファーストのwin8もどきのgnomeが主導してるってのも影響してんのかな
ぶっちゃけ、デスクトップならどっちでもいい

>>291
ゲームってSteamのWineベースのWindows互換レイヤー使ってるやつだろ？
WineのWaylandサポートがまだ実験段階だから反応悪いのが当たり前

Waylandの使用が推奨されてるのはXの抱える諸々のセキュリティの問題に配慮されてるからだよ
ただ厳密になった分、使い勝手が悪くなってユーザーの不満が溜まってる

どのみち現状ではWaylandに移行する気は起きないな

Xの互換で諸々の問題も解決するならいいが、
現状Waylandって使えんよね

ゲームはWindowsでやりますし。
hidpiのノート使ってるとwayland楽だ

>>300
Waylandは、nVIDIAが悲惨なだけで、AMDだと、まぁまぁ普通に使えますよ
Arch+KDEでおなじみの、StearmDeckも、Waylandですね
タッチパネルは、Waylandじゃないと、マウスのエミュレートになっちゃって
フリックとかできませんから…

その辺は全部libinputだからXでも同じようには設定できたはずと思うけど。
自分は既にX本体は使ってないから忘れたけど。

原因はだいたいNvidiaという結論ですね

Arch公式のRubyのバージョンってなんでずっと3.0なの？
Debian stableよりも古い

なんか色々やってるみたいね
何やってるのかよく分かんないけど
https://gitlab.archlinux.org/archlinux/packaging/packages/ruby/-/issues/3#note_166815

>>306
やっぱり問題にはなってたのね
最新版が入るのはいつになるか分からないし諦めてrbenv使うかあ
なるべくpacmanで完結したいんだけどな

最近はちょくちょくパッケージのメンテナが連絡不能になっているから
ユーザーは増えてきても実際には末期状態かもしれないな

rubyってちょっと油断するといつのまにか入れられるんだよね。
pythonは諦めてる（一応自分でも使ってる）けど、rubyまで滑り込んでくるのは我慢ならない。

>>309
数少ない国産の有名言語だから(比較的)
無下にしないであげて…自分は入れてないけども

システムアプデ後にあるパッケージのsystemd daemonが起動せず
とりあえずパッケージのリビルドでまた起動するようにはなったけれど
たぶん依存パッケージの指定がどれか漏れてるとかなんだろうけどどのパッケージに依存しているか不明っていう＼(^o^)／

昨日辺りでpythonが上がったからな。しばらくすったもんだするかも。

cups がプリンタを見つけられなくなった。
1つ前にダウングレードしたら復活。
バグトラッカーが使いにくくなったなあ…

スクリプトほしゅage

kittyとweztermがまともに動かなくなったぜ
なぜかalacrittyだけ無事だった

icu が上がったらおまえらキレそうだな
ffmpeg も同時に上がったら発狂しそうだな

>>312
そーだったのかｗ

chirp-nextが起動不能になったもんだから、ターミナルで起動
してエラーメッセージみたら納得したｗ

fcitx5デーモンを立ち上げない場合端末の不具合は発生しない…つまり原因は…

archlinux.jpのssl証明書、期限切れじゃないか？

ffmpeg と icu はなかなか上がらないな

久々にArchで環境作ったら
mozc、mozc-ut共
AURでビルドエラーで止まる。
いつか直るかな。
とりあえずanthy使ってる。

>>321
DEなんだか知らないけど、 fcitx5-mozcならリポジトリにありますので
mozc使うなら、fcitx5がいいですよ

>>321
mozc-utだけど自分の環境ではちゃんとビルドできてるな
自分の経験上メモリが8GB未満なら必ず失敗する
とりあえず~/.cache/bazelを削除して再ビルドするのがいいかも
なぜかArch公式のfcitx5-mozc勧めてる人いるけど古いしemacs mozcが使えなくなるから使ってる人はいないと思う

>>323
横だし話はまったく別だが、
> 自分の経験上メモリが8GB未満なら必ず失敗する
これマジ？最近の状況全く知らんが、そもそも論として、ビルドに8GB食うとは思えないし、
食ったとしてもスワップ行くだけ、つまり遅いだけで通るはずなのだが。
(少なくともWindowsならスワップは自動増加がデフォなのでメモリが足りなくて落ちることはない。クソ遅くはなるが。
そしてLinuxには未だにスワップを自動増加する設定がなさそうなのはショボ過ぎだが)

>>323
emacsってデフォアプリなんすか？
私のArchには入ってませんけど
ビルドでコケるよりはマシな気がしますが…

>>322
入れました。
fcitx5-mozcだけで、使えるのですね。
mozcというパッケージが必要と思い込んでいました。
古いらしいですが、特に問題無いので
このパッケージのを使います。
ありがとう。

>>323
メモリ、８GBちょうどなんですけどね。😥
もう一回ビルドしてみます。

>>323
~/.cache/bazelを削除して（実はこれも前回やりましたが）、

ERROR: /home/yamato99999/aur/mozc-ut/src/mozc-ut-git/src/protocol/BUILD.bazel:140:14 Compiling protocol/user_dictionary_storage.pb.cc failed: (Exit 1): gcc failed: error executing CppCompile command (from target @@com_google_protobuf//src/google/protobuf:protobuf) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 62 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Elapsed time: 334.405s, Critical Path: 39.55s
INFO: 1055 processes: 511 internal, 544 linux-sandbox.
ERROR: Build did NOT complete successfully
==> エラー: build() で問題が発生しました。
中止...

mozc-ut
こんなエラーでビルド止まります。
mozc
も同じです。
何でしょね？

噂ではswap領域が十分でもsystemd-oomdが強制終了させるという話がありますね

他の環境(fedora)自前でmozc buildしてるけど最近のgccじゃ通らんclangで完走した

やっぱりbazelは面倒だな
mozc-utはもはやArch必須パッケージみたいなものだからなんとかしてほしいところ
UT辞書はライセンスバカがしょーもないことを触れ回ったせいでビルド済みバイナリを配布するのも難しい状況だし