Arch Linux 16

公式
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/

大してスキル無いから解決できないのは（libglewとか）消しては入れ直してるけど
今回は依存関係がこんがらがって消したらあかんて怒られるし
そんなこんなしてたらGwenviewが窓枠表示だけになる不具合出て
面倒くさくてもういいやって感じ
調べるよりクリーンインスコする方が手間も時間も掛からないので
そんなだから一向に向上しないのだけどまあ

どういう意味？
公式リポジトリにもAURにもないものを自分でビルド・インストールして依存関係が壊れたってこと？

いずれにせよアプリケーションごとの設定とパッケージ同士の依存関係を切り離せてないし、そんななのにやけに達観したような語り口なの笑えるな
依存関係じゃなくて己の認知がぶっ壊れてるんだよ

それで良いよ
自分はそれで間に合ってるから

>>377
> 大してスキル無いから解決できないのは
いや、どんな問題を解決しようとしてそれをしてるの？？
あ、非難とかじゃなくて単純に技術的な興味の質問です

ド安定のDebianにおいでよ

ぶっ壊れた ←まちがい
ぶっ壊した ←せいかい！

>>382
しかしArchWikiの充実っぷりは異常
Debian系の人もみんな見てる

>>384
Debianも使ってるけどArchWikiは本当に有り難い
ディストリなんか好きなの使えばいいじゃんね

いつか戻ろと眺めながら Ubuntu

全部パッケージ入れ直せ

https://ascii.jp/elem/000/000/475/475007/2/
10年以上前だしディストロも違うけどUbuntuJPの中の人が悲哀を語ってますなぁ

>>388
今ならもうほとんどUTF-8じゃない？

pacman6ついにきたね
paralleldownloads試したけどめちゃくちゃ速い

新しいpacmanはyay-binと衝突するのか

paru-binが一時動かなかったのはcat.netのせいかい
jaistを先頭にしたわ

>>391
yay、git clone, makepkgした。こんでいいのか自信ないけど。

>>393
yay-binでなくyayならいいのか、ありがとう

カーネル5.13からzstdが超絶進化するみたいだな。
楽しみだ。

zstdはまだ新しい規格だからまだ高速化の余地があるんだよな

Archの更新ってフリーフォールなみにこわいの？

https://twitter.com/chor0sK/status/1400099977112608774
NixOSを使ってても結局OS更新は清水の舞台から飛び降りる気分ではあるんだけど、Arch linuxはフリーフォールな気分なところ、NixOSだとバンジージャンプみたいな気持ちで飛び降りれる。rollbackできるから死にはしない。
https://twitter.com/5chan_nel (5ch newer account)

意味がわからんバックアップ作るなりetckeeperで管理するなりすればいいだけだろ
自分の技術力不足を他に押し付けるな

使おうsnap-pac
https://github.com/wesbarnett/snap-pac

システムなんてぶっ壊れようがいくらでも簡単に直せるしどうでも良いよな
エロ動画が消えるのだけは絶対許されないからデータ用のパーティションだけは多重バックアップ必須だけど

起動しなくなるなんてレベルで壊れたことはない

8年くらい使ってるが、アプリケーション毎のトラブルしか踏んだことないね (wine等)
アプデが契機でシステムごと、しかも復元不能なまでにおかしくなるなんて想像もつかない

おそらく、DEとかWMのトラブルで画面がつかなくなったりしたのも「システムが壊れた」と見なして叫んてるんだと思うが、そういうのは利用者のモラルの問題だね
軽々しく「Arch のアプデには勇気がいる」みたいなこと言わないでほしいなあ
発言者がどういう方かは知らないが、転載されてここまで来るということは影響力のある人なんだろうし

AURと混ぜると危険
標準リポジトリのみなら特に問題はない。
良くも悪くも壊れるようならArchのようなミニマルなディストリ向きのユースケースじゃないと思う

A(nixOS)をアゲるためにB(arch)を下げる、的な論法を真に受けなさんな。

# python上がってpython製のwmがちょっとおかしくなったり、pipewireの
# 設定に互換性が無くなって .pacnew で上書きが必要になったり、lvmeatd
# がxx で起動が遅くなったり、とか systemd-resolvd がー、とかちょいちょい
# あるのでリスクを感じないとは言わない。

arch固有の話というかローリングリリース一般に通用する話が多い印象

安定板でローリングリリースは事実上Arch系固有だからね
対抗馬はWindows10くらい

>>404
空行以下って全く致命的なトラブルじゃないでしょ

ところでPython製のwmってどれ？

更新が怖いというか
AUR経由での直接インストールが多いのが設計上の弱点だよね。
野良製アプリ前提だからある意味Windowsに似ているといえる。

公式リポジトリしか使ってない限りは依存関係が崩壊しないっていうのは強みでもあるんじゃないか
問題の切り分けもしやすい
野良パッケージもpacman経由でインストールするわけだからリムーブも簡単だし、公式パッケージとの依存関係も基本的には取り持ってくれるので、configure; make; make install とはわけが違う

Archは月1回リリースだから新しさと安定性のバランスが取れてるかと思うけど
どうなん？

上で出てるNixOSは最近使ってみたが
年2回リリースなので、安定版は段々ソフトウェアが古くなる
依存関係が厳密で、依存関係崩壊によるエラーは無いが、
使いたいソフトウェアがパッケージ化されてないと自分でパッケージ化必要でつらい
これはNixOSがと言うよりマイナーなディストロの弱みかもしれんけど

パッケージは基本的に上流で既に｢安定版｣とされたものだし
数少ないArch由来の変更や設定もcoreとかに入る前にtestingに入ってテストされてるわけだし

不安定って言ってるやつは何を論理的な根拠に不安定だって言ってんのかね
ただ｢ぼくが不安定だと思うから不安定なんだ！｣ってだけ？
それともtestingでのテスト期間が短いとかかな

他のディストリからしたら安定版はArchやらで試されてるから安定なんだろうけど
ArchやFedoraの場合は最初にその安定版とやらが降ってくるポジションだから
安定版といっても少数のテスターの環境での安定してる程度の意味しかないよ。

そもそもアプリ自体が最新版入るんだから安定とか安定してないとかそういう問題でもない気がする
どんな OS でも最新版のアプリにすると今までできたことができなかったりできるようになったりするのは当たり前だし

安定版がちゃんと安定しているかどうかは上流のリリース基準によるからなんともいえんね
バージョン自体は古くてもメンテナンスが行きどといてなくてそもそもバグが放置されてるソフトウェアとかもある

Arch自体は最新の安定版ってちゃんとした基準があるんだから、古いのや新しいが使いたいならユーザー側で変えればいい
Debian Testing、SUSE Tumbleweedなんかは同じローリングリリースでもベータ版が普通に落ちてくるし
GentooやNixは逆にローリングうたってるわりにバージョンが安定版から数年遅れの場合も少なくない
Ubuntuみたいな固定リリースの場合は上流がサポートしてないメンテナンス終了してふソフトウェアも含むから話が全然違う

ソフトウェアのバージョンアップしたくないならpacmanのignorepkgで設定しておけば、
依存しているライブラリがABIに破壊的な変更加えない限りしばらくの間は使えるし
そもそも設定ファイルの構文がバージョンによってしょっちゅう変わるような開発途上のアプリは安定を優先させたいなら避けるべき
どのディストリ使ってようがいつかはその変更の影響受けるんだしそれがまとめてくるか細かくくるかの違いだけ

ローリングリリース故に別パッケージのアップデートに追従するまで間が空くことがあるくらいだな

特定バージョンのアプリケーション使い続けたいならdockerなどに頼る方が良いんじゃないかな
デーモン系だと難しいけど

>>407
> ところでPython製のwmってどれ？
qtile 当時ローカル改造しながら使ってた。

致命的、じゃなくてもなんかあったらリカバリ出来る時間が取れるときじゃないとね、って事。
プライベートな作業やってる時とか仕事の前にアプデかけるリスクは取れないよ。

言ってるそばから早速pacman6.0でyayが破壊される不具合が発生したみたいだな。

もう次スレから
｢Partial Upgradeはサポート外｣
｢公式リポのパッケージに非互換な変更があったらそれに依存するAURのパッケージはリビルドが必要｣
みたいな基本的な注意点だけでも入れね？

基本的なこと理解しないでサポ外のことして自分でぶっ壊しといてArchが悪いと騒ぐバカが多すぎる

Arch試してみようかと思ってたんだけど
AURって無くても困らないの？

>>421
コマンド1発でパッケージマネージャ外のソフトをビルドインストールできるだけだから困らないよ

今朝アップデートしたらtimeshiftが機能しなくてちょっとビビったが
リビルドして日常を取り戻した

>>420
このスレの住人に喚起すべき注意点ってよりは、社会の問題な気もするが
データサイエンティスト笑志望のアホが環境作ろうと思って変なことしてるみたいな背景があるのかな


>>421
AURは便利である
し、野良パッケージをインストールするときもAURの作法でやるのが良い
>>420に書いてあるようなことは守る必要がある

パッケージマネージャ外のはAURでソースからビルドしろって文化？
ビルド済みバイナリないの？

パッケージマネージャ外だから
非互換の変更あっても自動でリビルドしてくんないの？

>>425
バイナリもあるよ
なんとか-bin
って名前だとバイナリ

なんとか-git
だと、gitからソース拾ってきてビルドしてくれる

他には、appimegeとかもたまに転がってる

ビルドするヤツでも、pkgbuidファイル更新してくれないと
自動更新で再ビルドとかできないから
最終更新日とか
ユーザーからの評価とか、利用者どんだけいるかとか
もう、メンテされてないのとか
自分で選んで使わないといけない

メジャーなヤツだったら、そんな酷い目に会わないと思うけど…

>>425
arch wiki くらい読めよ……と思ったが、思想・方針的な話はあんまり書いてないな。

「AUR は……人気のあるパッケージが [community] リポジトリに取り込まれるように、コミュニティの手で新しいパッケージを共有することを目的に AUR は作られました。」

AURはもともとパッケージ開発を目的としているので、パッケージビルドスクリプト（PKGBUILD）を共有／パッケージそのものは自分で作れ、という文化。PKGBUILDの中身はbashスクリプトなので、ソースコードからフルビルドするものもあるし、ビルド済みプログラムをダウンロードするものもある。そこはPKGBUILDの作者次第。

何で人気のあるパッケージyayをcommunityに取り込まないのかは謎だな

yayはほとんど開発止まってる状態だからなぁ

>>428
yayに限らず、AURヘルパーは公式でサポートしない方針。

昔フォーラムでQAが存在しないユーザーリポジトリからのインストールを自動化するようなアプリは公式リポジトリには入れたくないって偉い人が言ってたけど、
じゃあmakepkgするときいちいちスクリプトや参照先のソースを監査してるのかいって言う話になるし、実際大多数の人間は細かいこと気にしないでyayとか使ってるわけだが

え？流石にスクリプト眺めるよね

AURは自分で判断ができる程度の数のパッケージしか入れないわ
それこそ公式に合わせてリビルドが必要なこととか忘れて後からどうしてなのか悩みたくないし

ぼーっと眺めてても単純な記述ミスにすら気づかない自信があるし真面目に1行ずつ読んだところで悪意を持って巧妙に隠されたら気づかないだろうから気にしてない
そもそもまじめにソース確認する人ばっかりだったらbinパッケージなんてものはAURに存在しないだろう

メンテ放棄されてたacroreadに悪意のあるスクリプト注入されてたのもう忘れたか

>>431
> 実際大多数の人間は細かいこと気にしないでyayとか使ってるわけだが

だーかーら、そういうスタンスの人はあえてArch使う必要なんかないんだって
AURは素晴らしい
が、それはAURを公式リポジトリさながらに使いましょうということを全く意味しない
Archのミニマルな思想と利便性の間を取り持つためにAURは存在するんだってなぜ分からない
思想なんか関係ないよと思うなら正にArchなんて使う必要はない

>>434
> そもそもまじめにソース確認する人ばっかりだったらbinパッケージなんてものはAURに存在しないだろう

……バカ？

>>434
多分スクリプトはaurのパッケージを作るスクリプトを指してると思う。
binを使うのはわざわざ自分のマシンでコンパイルしても大して最適化されないものだよ

まあ好ましくはなくても自己責任で｢見てもわかんねーしまぁいっか｣って判断してもそれはそれで別に悪くないっしょ
悪いのはわざわざ｢AURは誰でもアップできるから自己責任で使えよ！｣って太字で書いてあるのに何も理解しないで使って問題が起きたら騒ぐガイジ

それはそうと、AURで多くの人にインストールされててかつ公式のアプデに取り残されてシステムに深刻な影響を及ぼしうるパッケージって何かね

自分の環境眺めてみたら有名どころは nkf と displaylink と slack と zoom くらいしかなかったし平和なもんだ

>>439
両者、層が被ってそう

>>438
ソースURLに適当にでっち上げたサイトのURL書いとくだけで何だってできるのにPKGBUILDだけちらっと眺めてどれほどの意味があるのか

>>435の言ってる奴とかはcurlでダウンロードしてbashに渡すみたいな隠そうともしない露骨に不審な奴だったから眺めるだけでも割と気づけそうだし全く意味無くはないだろうとも思うけどね

ただ俺は全部チェックしてるって言うやつはじゃあ
Nodeに依存するパッケージがnpmでインストールするパッケージの中身まで全部把握してんのか？
Rustに依存するパッケージがcargoでインストールするクレートの中身まで全部把握してんのか？
みたいな話になるし現実的に個人が100%もれなくチェックするなんて無理だしな

結局｢意味ないからお前らも見なくていいーよ☆｣っておおっぴらに開き直って良いもんでもないし逆に｢隅から隅までチェックしろ！！！｣って強制するもんでもないし
リスクを承知した上でそれぞれが自己責任で利便性との間で適当にバランス取るしか無いわな

上流でウイルス混入してるのと
AUR自体のスクリプトにウイルス入ってるのは別問題じゃね？

そういうの嫌だったら普通にUbuntuとか使えば良いんじゃね？
なぜArch？
パッケージ新しいから？

アップストリームに問題なくてもAURのパッケージメンテナに悪意があったら何だってできるわけ
PKGBUILDのソースURLがmozila.orgかもしれないしkernel.netかもしれないしパッケージ名っぽい独自ドメインかもしれないしgithabかもしれないし
実はユーザー名が一文字足りないかもしれないし一見普通のユーザーかもしれない
あるいはソースは本物でもパッチの一つに何か仕込まれているかもしれない
ソースパッケージだったらダウンロードして確認ということも原理的には可能だがバイナリパッケージだともうどうにもならない
まぁarch wayの伝道者ともなるとバイナリパッケージからでも余裕でソースコード復元できるみたいだが一般人には普通のソースコード監査すら厳しいからね

どんだけ馬鹿なのコイツ

・ユーザーリポジトリからのダウンロード、インストールを公式ではサポートしたくない話
・ユーザーリポジトリには悪意のあるパッケージが含まれうる話
・バイナリ配布には危険が伴う話
全部全くレイヤが違う話なんだが
問題の切り分けがなってないって指摘されてんのに何もわかってねえな

AURは公式リポジトリではないし誰でも自由にUPできるから信用できないってのは共通認識があるわけだけどこの人は何を言ってるんだろう
齟齬があるのはmakepkg前にPKGBUILDファイルを眺める作業をする事の意義なわけだが
いきなり問題の切り分けとか言い出すし、もしかして日本語不自由かな

AURがどう作られてるかしらんけど
GitHubで開発してるなら
複数人で開発しててレビューが行き届いてんのもあるんじゃね？
それとも大体個人開発でレビュー無しなの？

>>445
PKGBUILDがー
って
いくらでも参照できるのに
コソコソ悪さできるとでも?

現に、公式のChromiumが、vaapiパッチ採用する
ちょっと前に、Chromium-vaapi-binで
ﾊﾞｲﾅﾘ配布してたのが、シナ製に切り替わった事あんだけど
みんな警戒して使わなかったよ

ソースコード読めない情弱で
こまけー事、ワケわからんユーザーにでも
コメントくらいは、よめますからね

GitHubでPKGBUILDを管理している人はいるけど全員ではないな
公式リポジトリはSVN使っているし

yayなどのAURヘルパーはAURのパッケージインストール前にPKGBUILDの中身表示するようになってるし
AURのパッケージ使う前にPKGBUILDを確認すべきでその作業には意味があるというのはコミュニティーの共通認識とされているのでは

AURはただのインストールスクリプト集だからそこが心配なら自分でビルドすればいい

>>447
ド低脳キッツ

makepkgはアーチのコマンド、自動化は自分たちでやってねって事
これ以上でも以下でもないから。

>>451
yayはデフォルトの選択肢が非表示なんだよなぁ

pamacってpacman 6にまだ対応してない?

開発止まってるyayが対応してない

yay-binはリビルトが必要なだけだったな

みんなparuは使わないの？
実質開発が終了したyayの話題のほうが多いように見えるけど

paruで何も困ってないから話す話題がない

paruもyayもどっちも安定してると思うけどな
yaourt時代を考えると隔世の感がある

>>https://archlinux.org/news/sorting-out-old-password-hashes/

libxcrypt 4.4.21 は、脆弱なパスワードハッシュ（MD5 や SHA1 ）を
新しいパスワードとして受け付けなくなった

まだ脆弱なハッシュでパスワードを保存しているユーザーは、
次回ログイン時、パスワードを更新するよう求められる

ログインに失敗したら（ディスプレイマネージャーからのログインなど）、
仮想端末（Ctrl-Alt-F2）に替えて、ログインしてね

全然関係ないけど

> ログインに失敗したら（ディスプレイマネージャーからのログインなど）、
> 仮想端末（Ctrl-Alt-F2）に替えて、ログインしてね

これができなくて「アプデで壊れた！」叫んでる人稀にいるよね

それできなくてもブートローダーでエントリ編集してシングルユーザーモードにするだけだろ
最悪インストールメディアから起動してchrootしてもいいし

それを行う発想やスキルがない人がArchに手を出しているパターンもたまにあるから

俺クラスになるとgrubをバイパスしてカーネルを直接呼び出してるからエントリーなんて存在しない

そういえばpacmanがしれっと並列ダウンロードをデフォルトで無効にしたな。
建前上サポート外のyay上での不具合で差し戻しかいな。

yayの不具合に対応したというよりは、多数のユーザの頭の不具合に対応したんだろ

manjaro化の呪文が発明されてた

sudo pacman -S thunderbird gimp{,-refocus,-plugin-gmic} blender inkscape darktable openscad owncloud-client \
celluloid vlc ffmpeg gst-plugins-{bad,good,ugly} kdenlive audacity soundconverter nano-syntax-highlighting playonlinux\
texlive{-bibtexextra,-latexextra,-pictures,-langextra} img2pdf pstoedit pdf{2svg,arranger,tk} xournalpp chromium \
gnuplot p7zip htop glances pydf thefuck tldr gparted exfat-utils ntfs-3g sshfs keepassxc unzip trash-cli optipng \
perl-image-exiftool jhead gzip poppler xdg-utils tesseract{,-data-fra,-data-eng} ghostscript cozy-desktop \
yay base-devel pkgfile meld diffpdf system-config-printer lollypop simple-scan gedit-plugins tilix \
ttf-{roboto,roboto-mono,ubuntu-font-family,caladea,linux-libertine,linux-libertine-g,liberation} {awesome-terminal,powerline}-fonts \
python-nautilus steam-manjaro game-devices-udev arc-gtk-theme grammalecte easytag shotwell mypaint youtube-dl \
linux-steam-integration libxml2 python2-lxml cura{,-resources-materials} calibre openssh pavucontrol \
zsh-{autosuggestions,completions,history-substring-search,syntax-highlighting} vim peek

archwayって変更か廃止かされた？

Arch使う前は英語のままで使ってる人が上級者っぽく見えたけど
実際には日本語化ってArchの環境構築の中でも最高難度だから英語のままな人は単なる技術不足よな。

そんな難しかったっけ？

ロケールを日本語にするだけだった気がするけどなんか特殊な作業必要なの？

英語が読めなくてArch使ったことないんだろ

環境は日本語にしてディレクトリだけ英語に戻してるわ

日本語フォントの設定は必要だな。
コンソールの日本語対応はけっこう面倒だった気が。たまに文字化けする。

日本語入力もググってコンソールにコピペで終わるし