Arch Linux 18
AURでなく、本家のリポジトリのパッケージがビルドエラーになると超絶萎えるわ PKGBUILDのメンテナではなくパッケージ側が悪いんだけどさ >>153 biosの更新もしてみたら… >>156 私は、Manjaroでkernel6.8.0rc6使ってけど大丈夫だな そういう症状が出たときは、一時的に治るまでkernelのバージョン下げてやり過ごします >>157 どういう状況? リポジトリで提供されるのはPKGBUILDで、ビルドされた バイナリパッケージですよね パッケージのインストール時のビルドエラーって PKGBUILDで定義しといた 依存関係の問題とかのはずなんだけど… >>159 俺は馬鹿だからよく分かんないわ。頭良さそうだから後は頼むわ。 ちなみにパッケージはfcitx5-mozcでパッケージがビルドされた日付は2年前。 Debian系とfcitx5-configtoolに表示される内容が異なるからビルド済みのソースコードを見たかっただけなんだけどな。 cat <<EOF >> ~/.makepkg.conf DLAGENTS=('https::/usr/bin/curl -k -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u') EOF git config --global protocol.file.allow always mkdir -p ~/src/pkg cd ~/src/pkg/ pkgctl repo clone --protocol https fcitx5-mozc cd fcitx5-mozc makepkg -sf --noconfirm --skippgpcheck あれれ~、僕バカだから分からな~い 見た目は大人、頭脳は子供、その名は迷探偵困難! うるせー。バーロー。 ていうかローリングリリースなのにビルドの日付が2年前っておかしくね? Debianだって次のメジャーバージョンになってるわ。 >>160 いったい何したんだか分かんないけど https://archlinux.org/packages/?sort=&q=fcitx5-mozc ここから見てわかる通り公式リポジトリのパッケージが最後にビルドされたのは、 2023-05-19です そんで、アップストリームのどの時点のソースをパッケージ化してるか ってのは、PKGBUILDに書いてあります https://gitlab.archlinux.org/archlinux/packaging/packages/fcitx5-mozc/-/blob/main/PKGBUILD?ref_type=heads の中のsource=(…) の部分ですね PKGBUILDのメンテナーの裁量ですね もっと新しいものがほしい場合は、自分でPKGBUILDを編集してから makepkg -siとかやって、パッケージすることもできるし そのPKGBUILDをAURで共有することもできます >>162 あ で AURは、アカウント作りさえすれば、誰でも投稿できますので じゃんじゃん参加してくだせー そんで、AURは非公式でやりたい放題できるリポジトリですが AURから、公式に昇格するってシステムもあります 私が知ってる例だと、Chromium-vaapiっていう Chromiumで、ハードウェアデコードを使えるようにするAURのパッケージが 公式に昇格してました >>165 へー、詳しいね チャットするだけでなく、ついでにfcitx5-mozcがビルド通るようにしといてくれよChatGPT >>166 は pacman -S fcitx5-mozc ってやれば入るじゃないの makepkgできないってんなら、自分でPKGBUILDいっじって どうぞ てか 私にやらせるつもりなんか? >>167 makepkgすら実行するつもりがないなら、いちいちゴミみたいな情報書いてた意味は何? >>168 しらんがな 私は日本語打てればなんでも良い派ですから… 拘りたいんなら、いっくらでも拘れますよ それは、あなた自身がやることです >>168 あ 私がレスした意味は、あなたの >AURでなく、本家のリポジトリのパッケージがビルドエラーになると超絶萎えるわ >PKGBUILDのメンテナではなくパッケージ側が悪いんだけどさ っていう誤解に対するものですからね 公式リポジトリで配布されているパッケージは 公式のPKGBUILDのメンテナによって定められた ビルド済のバイナリパッケージである 既にあるAURのを使えばいいと思ったけど、2-3種類あるな。 ざっと見た感じは、fcitx5-mozc-utでいいような気がする。 >>171 AUR的には、最終更新日と投票数を見て厳選するのがセオリーなので 一番無難かな 最終更新日は、2024-03-09 だし 投票数も28と断トツっすね 私も入れてみたけど、ちゃんとビルドできますた ということで、私も投票しとくか ついにChatGPT同士で会話するようになったか😯 >>173 私の中では、ChatGP連呼マンは、私の追っかけで エアプのクッソドザーさんって定義になってますけどね 自分で墓穴ほって自滅していく、儚い生き物 >>172 一応PKGBUILDは見とこうぜ。 正確な文法知らなくても読めばなんとなくわかるし。 >>173 多分、自演 誰かが釣られて乱入してくるの待ってるんだろう いつもの手口だろう >>175 これでも私は、AURにPKGBUILD投稿しますので まぁまぁ、文法ぐらいは知ってますよ ただね〜 どのコミットを厳選して採用してるかって部分については ソース追っかけんのが大変で、まだマスターレベルに達してないことは 認めざる終えません >>171 直したいのはDebian系の方。 Archとバージョンが近いのに挙動が違うのは何故か調べたいの。 bazelとgcc-13のせいでmozcのバージョンを上げないとビルドは困難だから差異を見るのは諦めるけど。 AURは頻繁にビルドエラーになるけど、aspとかpkgctlで公式のリポジトリから引っ張ってきたPKGBUILDがビルドできないことが今までなかったから萎えたって話よ。 >>154-156 >>158 レスありがとう 件のエラーの類だけど,サスペンドさえしなければ出ないのよ マジでこの kernel: BUG: KFENCE … とか見たくもなかったわ 海外のサイトとかでも以前から似た様な報告があるみたいだけど, 解決済みとか,いや未だ続いてるとかマチマチで… カーネルパラメタ弄ったり, mkinitcpio で WARNING 出るドライバを入れてみたり,とか 他にも結構色々やってるがイマイチ…お陰で寝不足気味だわ() ジャーナルに他の黄色いエラーメッセージもあるのだけど…赤いヤツは無いかなぁ 敢えて言うなら下記が似た様なタイミングで黄色のエラー吐いてるくらい kernel: xhci_hcd 0000:06:00.0: xHC error in resume, USBSTS 0x401, Reinit 古いハードだから BIOS の更新はもう見込めないのよね, 確かにグラボじゃなくてマザーのエラーの可能性も考えたのだけど… 再度ありがとうって言っとくわ 何かまたあれば宜しく >>179 いちばん簡単なのは、カーネルのバージョンさげちゃうことですね わたしも、なんどもなんども経験してます Manjaroだと、現行のLTSよりも古いLTSにも簡単に変えられるから便利なんだけどな >>127 お前ローリングリリースの意味が間違ってるだろそれ w >>130 それがローリングリリースってことだろアホw いやしかしね単なるアップデートでフリーズするとかありなのそれ 危なっかしくて使えないじゃんよ >いやしかしね単なるアップデートでフリーズするとかありなの ここ2〜3年で RedHat も Debian もやってるけどな >>185 やろうと思えば簡単にできるよね 私も、Ubuntuで、TVチューナーカードのドライバー自分でビルドして 使ってたら、勝手にカーネルアプデされて、カーネルパニクって起動できなくなった なんてこと普通にありました 今までGNOME+iBus-mozcを使ってたが、iBus-mozcがAURでしか手に入らなくなってからだいぶたつのでfcitx5-mozcを使ってみることにした、ついでにKDEを入れてみた 入力の表示位置がずれたりするね 何かすれば治るんじゃろか? >>188 opensuse tumbleweed での阿鼻叫喚に比べたら stable そのもの archの実力を見直した fcitx5-gtk入れたら治ったっぽいけど、まだ気が抜けない >>190 ただの体験談ですよ その体験から、DKMSが どんだけありがたい存在で必須なんやって、学びました >>189 パッケージの粒度が大きいからダウングレードしやすいわな だがHaskellだけは絶対に許さない Haskellから人類を解放せねば >>194 そんなに必死に関係ない体験談語らなくてもw shellcheck 0.9系でmemory consumption起こしてるのな。 configureとかのでかめなシェルスクリプトをLSPクライアント動かしてるエディタで開いてるやつは注意な。 50000行のconfigure開いてたら数分でRAM 64GB食いつぶされたわ。 0.8系に戻すにも悪のHaskellのせいで面倒。 早く人類はHaskellから脱出しないと。 autotoolを法整備で撤去する方が楽か。 Archで先週リリースされた0.10系なら shellcheck --extended-analysis=false configureか echo "extended-analysis=false" > ~/.shellcheckrcで shellcheck configureできるようになってたわ。 Fedoraはざまぁ。 人類は救われた。 >>179 カーネルコンフィグでモジュールが「*」「M」どっち? fcitxでmozc使ってるんだけど「nyb」とか「nyc」みたいに「ny+母音以外」を打つとnyが消えてbとかcだけになっちゃうんだけど再現する人いない? どこの国の言葉を変換しようとしてるんだか。 試してみる気にもならないわ。 >>203 pamac-aur 使ってんの? pacmanとの依存関係ごちゃごちゃになってんね いったん、pamac削除して、pacman更新して、また入れ直しかな yay -R libpamac-aur pamac-aur yay yay -S pamac-aur もしくは chaotic-aur をrepoに追加でもOK yay , pamac-aur ともに新pamac対応バージョンが入っている >>204 その通りやったら無事アップデート出来ました ありがとうございます >>3 の者ですが Plasma6で仕様が変わって、動かなくなったので パッチ書いて無理くり対応させました Manjaroのフォーラムで困っている人いたから 投稿したんだけど、Manjaroの安定版に まだ降ってこないんだよな スクリーン録画アプリのkoohaがglibc2>=2.80を要求するのに2.80はまだtestingだった aurじゃなくても依存関係壊れてる事あるんだね シリアルコマンドであるstty についてお伺いしたいです。 cat /dev/ttyUSB0 で、文字列を持ってきているのですがよく止まります。 シリアル接続を全く理解していないのですが、これは同期を失った状態なのでしょうか? 何かのオプションを与えることで対応は出来ますか? サービスに登録して、くるくる回しています。 stty -F /dev/ttyUSB0 115200 raw cat /dev/ttyUSB0 すいません。215の件は、こうです。 パラメータをみるとこんな感じです。 stty -F /dev/ttyUSB0 speed 115200 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -isig -icanon >>215 相手と通信速度あってないんじゃないの? >>215 >>218 通信速度が合ってないとそもそも文字化けして コンソール表示がまともにされないと思う 経験上シリアル通信の安定性は物理的な接続状態(電気的接触)が 肝だから、端子間の接触、ケーブル長の見直し(できるだけ短く)、 ケーブルのシールド化、GNDへのアーシングとか試すといいかも それとシリアルアダプタの制御チップが 中華コピーのバッタモンだと通信できたり できなかったり安定しなかった >>35 の者ですけど ROCmが6になって、動かなくなったので簡単なインストールスクリプト作りました #!/bin/bash AppName="stable-diffusion-webui" cd ~/ git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd ${AppName} # 環境設定 sed -i \ -e 's/#\?export COMMANDLINE_ARGS=.*/export COMMANDLINE_ARGS="--upcast-sampling --opt-sub-quad-attention --no-half-vae --medvram"/' \ -e 's/#\?export TORCH_COMMAND=.*/export TORCH_COMMAND="pip install torch torchvision torchaudio --index-url https:\/\/download.pytorch.org\/whl\/rocm5.7"/' \ -e '$s/$/\nexport HSA_OVERRIDE_GFX_VERSION=10.3.0/' \ ./webui-user.sh # ショートカット tee "/home/$(whoami)/.local/share/applications/${AppName}.desktop" <<EOF >/dev/null [Desktop Entry] Categories=Graphics; Exec=sh ~/stable-diffusion-webui/webui.sh Icon=applications-graphics Name=$AppName Type=Application EOF # 構築して起動 ./webui.sh あ ショートカットだめだった パスがずれちまう 何おこってるのか分かんなくなるから、ターミナルで実行して作業バス追加して これでOKかな # ショートカット tee "/home/$(whoami)/.local/share/applications/${AppName}.desktop" <<EOF >/dev/null [Desktop Entry] Categories=Graphics; Exec=sh webui.sh Path=/home/$(whoami)/${AppName} Icon=applications-graphics Name=$AppName Type=Application Terminal=true TerminalOptions=--noclose EOF emacsでuimのツールバーで? A Rと表示されていて日本語入力ができないのですが 無変換 変換 かたかな/ひらがな/ローマ字などにShiftやCtrlなどを組み合わせて押してみたのですが なおりません uim キーボードショートカットとかで検索しても関係ない情報が多くて困っています firefoxは日本語入力できてます。ツールバーは? あ Rと表示されています 誰かどうやって直すかご存知のかたいませんか なんかwaylandっての?これも悪さしてるみたい キーボード配列が何度設定してもrebootしたらusモードに戻る >>213 そんな感じでしょやっぱ 自分でなんとかしろとか簡単に言うけど 無理だっての >>224 emacsもuimもわかんないんだけど fcitxの例ですけど、Waylandだと、変換候補の小さいメニューが となりの画面のはじっこに飛んでったり無茶苦茶でしたが fcitx5になって改善されました そもそも、Waylandってクソな仕様で アプリ側でウィンドウの配置できなくしやがったので こういうの対応させるんの大変だと思いますよ やっぱ結局ね外国語のことなんか真面目に考えちゃくれないんだろうね 自分とこの言葉が使えないなんてそれ事実上使用不能ってことだよね 何十年も前からある問題なのにね 結局こうなるわけね >>227 なんで、わざわざマイナーなuimなんて国産使っといて 外国に文句いってんすか? まだまだWaylandに対応できてないアプリも多いから 安定した環境を構築できない人は無理せずX11使った方が幸せだと思う >>230 日本、中国、台湾もなのかな? あとベトナムとかスリランカだか韓国とか Manjaroだと、asian-inputって括りっすね ibusでも良いのかも知れないけど ibus-mozcがAURにしかないから、なんとなくfcitx5になっちゃうね なんか今回のことで日経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固有なの? もう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のエンジニアってのがなかなか… >>257 几帳面にベンチマークとるデータベースシステムのエンジニアが偶然見つけた感じ 本当にラッキーだったね もし過去のコミットにも仕込んでてstableなディストロにまで波及したら大事だな libarchiveにもJiaT75が疑わしい変更を加えていた模様(2021年 ネットバンクのパスワードと抱えたほうがいいの?(´・ω・`) >>252 他のディストリビューションはsshで外に晒してた奴は クリーインストールで入れ直せって言ってるぞ あと認証関係全部やり直し >>263 それ、侵入されちゃった可能性があるからじゃないの? Archは、sshとリンクしてないから大丈夫 散々古いだのパッチが多いだの文句言われてる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でもロケットでも政治でもやるわけな日本人は。 脆弱性の件でシステムアップグレードしてから起動してるといつの間にかハングアップすることが増えた NVIDIAのドライバをアップグレードするときにファイルが競合したから強制上書きオプションつけてやったんだよね ゲームは特に問題なかったから関係なさそうだが またシステムアップグレードしてみるか いつの間にかWaylandでNVIDIAドライバから出力したディスプレイのリフレッシュレートが正常になってた ゲームのfpsもx11の方がいいらしいし、waylandにするメリットって何? waylandはモダンで安全性や保守性の高い仕組みで作り直したいという開発側の都合で始まったものに過ぎないので 単なるユーザーとしてはwaylandの方が完全に上位互換と見なせるようにになるか十分に普及するまで使う意味はない Xはもうメンテナンスしてる人いないから 将来性が全く無いのと、セキリュティの面でも穴だらけ 実際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本体は使ってないから忘れたけど。 Arch公式のRubyのバージョンってなんでずっと3.0なの? Debian stableよりも古い >>306 やっぱり問題にはなってたのね 最新版が入るのはいつになるか分からないし諦めてrbenv使うかあ なるべくpacmanで完結したいんだけどな 最近はちょくちょくパッケージのメンテナが連絡不能になっているから ユーザーは増えてきても実際には末期状態かもしれないな rubyってちょっと油断するといつのまにか入れられるんだよね。 pythonは諦めてる(一応自分でも使ってる)けど、rubyまで滑り込んでくるのは我慢ならない。 >>309 数少ない国産の有名言語だから(比較的) 無下にしないであげて…自分は入れてないけども システムアプデ後にあるパッケージのsystemd daemonが起動せず とりあえずパッケージのリビルドでまた起動するようにはなったけれど たぶん依存パッケージの指定がどれか漏れてるとかなんだろうけどどのパッケージに依存しているか不明っていう\(^o^)/ 昨日辺りでpythonが上がったからな。しばらくすったもんだするかも。 cups がプリンタを見つけられなくなった。 1つ前にダウングレードしたら復活。 バグトラッカーが使いにくくなったなあ… kittyとweztermがまともに動かなくなったぜ なぜかalacrittyだけ無事だった icu が上がったらおまえらキレそうだな ffmpeg も同時に上がったら発狂しそうだな >>312 そーだったのかw chirp-nextが起動不能になったもんだから、ターミナルで起動 してエラーメッセージみたら納得したw fcitx5デーモンを立ち上げない場合端末の不具合は発生しない…つまり原因は… archlinux.jpのssl証明書、期限切れじゃないか? 久々に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 メモリ、8GBちょうどなんですけどね。😥 もう一回ビルドしてみます。 >>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辞書はライセンスバカがしょーもないことを触れ回ったせいでビルド済みバイナリを配布するのも難しい状況だし CC=clang CPP=clang++ bazel ..... 環境変数つけるだけじゃ? >>329 > Mozc のビルドに失敗する (プロセスが強制終了される) > ビルドが以下のようなメッセージで異常終了した場合: > > ... > /bin/sh: 1 行: xxxx 強制終了 > ... > make: *** [xxx/xxx ...] エラー 137 > ... > メモリ不足になっていないか確認してください。 > ttps://wiki.archlinux.jp/index.php/Mozc のとおり、実際にメモリ不足になると止まるように設定されているようだ。また、 > 従来はメモリー不足によりOSの応答性が著しく低下し、もしくは無反応になり、 > ユーザーはPCを強制的に再起動せざるを得ませんでした。 > この状況を改善するため「systemd-oomd」を導入し、 > システム的にメモリー不足に陥る前にユーザースペースで「OOM Killer」を実行してメモリーの空き容量を確保し、 > システムの応答性低下を緩和することになりました。 > ttps://kledgeb.blogspot.com/2022/07/ubuntu-2204-224-systemd-oomd.html とあるから、とりあえずはビンゴっぽい。そのページの下のほうに書いてあるが、一時的に停止するには > sudo systemctl stop systemd-oomd だとさ。archでも全く同じかは知らんが。 ただまあ、ビルドに8GB食うのはおかしいと思うから、多分どれかのツールがメモリリークしてるのだろうが、 ディストリ側としてはどうにもならんから、この対処なのだろう。 (普通に考えれば、これならarchWikiに一時的解除の方法を載せれば良いだけだが、 それよりはメモリ不足で諦めさせたほうがいい、という判断になっているのは、 おそらく一時的に解除してビルドした場合、実際に再起動せざるを得ないケースに遭遇することになる、ということなのだろう) というわけで、確定させたければ再起動上等で試してみるんだね。 >>333 > sudo systemctl stop systemd-oomd まずこれをやって、~/.cache/bazel を削除。 で、ビルドするとエラーが少し変わったかな↓ /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/basic_string.h:1182:30: error: '*(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)((char*)<unknown> + 8).std::__cxx11::basic_string<char>::<anonymous>.std::__cxx11::basic_string<char>::<unnamed union>::_M_allocated_capacity' may be used uninitialized [-Werror=maybe-uninitialized] 1182 | return _M_is_local() ? size_type(_S_local_capacity) | ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1183 | : _M_allocated_capacity; | ~~~~~~~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors Use --verbose_failures to see the command lines of failed build steps. INFO: Elapsed time: 431.637s, Critical Path: 39.20s INFO: 1148 processes: 511 internal, 637 linux-sandbox. ERROR: Build did NOT complete successfully ==> エラー: build() で問題が発生しました。 中止... やっぱりビルド失敗。 で、原始的にPCのメモリが有ったので 16GBにして、~/.cache/bazel を削除。 で、再ビルド。 でも↑と同じエラーで止まる。 ↓続く >>333 3回目。> sudo systemctl stop systemd-oomd これをやって、~/.cache/bazel を削除。 メモリ16GBで再再ビルド。 エラーが前回に戻ったかな↓ /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/basic_string.h:1182:30: error: '*(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)((char*)<unknown> + 8).std::__cxx11::basic_string<char>::<anonymous>.std::__cxx11::basic_string<char>::<unnamed union>::_M_allocated_capacity' may be used uninitialized [-Werror=maybe-uninitialized] 1182 | return _M_is_local() ? size_type(_S_local_capacity) | ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1183 | : _M_allocated_capacity; | ~~~~~~~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors Use --verbose_failures to see the command lines of failed build steps. 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: 218.061s, Critical Path: 11.59s INFO: 833 processes: 403 internal, 430 linux-sandbox. ERROR: Build did NOT complete successfully ==> エラー: build() で問題が発生しました。 中止... こんな感じでメモリ16GBでも失敗する。 自分のPCがおかしいおま環? とも疑う。 とりあえずmozc-utビルド、こんな感じで 失敗します。報告でした。 yay -G mozc makepkg --syncdeps --rmdeps --cleanbuild ==> 作成完了: mozc 2.30.5448.102-1 (2024年05月13日 16時06分22秒) ==> Removing installed dependencies... メモリー 7Gの環境でswap 2G 失敗 EndeavourOS メモリー 7Gの環境でswap 10Gだと完走できるぽい Manjaro Testing $ swapon --show NAME TYPE SIZE USED PRIO /dev/sdb6 partition 2G 0B 2 /media/ほげ/sys004/swapfile file 8G 7.5M 3 >>335 俺も16GB載せてるが2、3回に1度くらいの頻度で失敗するわ >>337 いえ。ユーザーのhomeディレクトリで やってますよ。 環境によるビルドエラーというよりgccとコンパイルオプションの問題なのかな…? g++のbasic_stringライブラリ側で内部変数'_M_allocated_capacity'が適切に初期化されてないぽいような gcc側の問題ならclangにして回避するか-Werror=maybe-uninitializedオプションを外すとか >-Werror=maybe-uninitialized 初期化されない場合、その警告をコンパイルエラーとして扱う指定 >cc1plus: all warnings being treated as errors プリプロセッサかコンパイラあたりが警告をコンパイルエラーとして吐き出してる いつもでやってんのofficalのビルド環境がubuntu24.04になったんだから clangがデフォだよ >>335 > 報告でした。 うおお偉い!まさか報告があるとは思わなかった。 まあ、インストールなんて所詮作業でしか無いから、何度やっても慣れてもほぼ無意味。 こういう引っかかったところで地道にデバッグして経験値を積み、Linuxのパワーレベル(戦闘力)を上げて行くのは正しいと思うぜ。 現状知らんので以下色々間違ってるかもしれんが、分かるところを書いておく。 まず状況を纏めると、 A. メモリ8GB, スワップ不明で、エラー(328) B. メモリ8GB, スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(334) C. メモリ16GB、スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(335、後半のエラー内容は328と同じだが…) でいいかな?出来ればA,B,Cにおけるスワップも教えて。 そしてもしスワップ無しで運用してて、万全を期したいなら、スワップ8-16GB程度を設定して試した方がいい。 (ただし結果は高い確率で変わらないので、面倒ならやらなくても問題ない) > ttps://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/managing_storage_devices/recommended-system-swap-space_getting-started-with-swap#doc-wrapper さて上記からまず思うのは、 (a) sudo systemctl stop systemd-oomd は効いたらしい? (b) メモリは16GBでも駄目? だが、よくよく見ると、 A(328) INFO: Elapsed time: 334.405s, Critical Path: 39.55s INFO: 1055 processes: 511 internal, 544 linux-sandbox. B(334) INFO: Elapsed time: 431.637s, Critical Path: 39.20s INFO: 1148 processes: 511 internal, 637 linux-sandbox. C(335) INFO: Elapsed time: 218.061s, Critical Path: 11.59s INFO: 833 processes: 403 internal, 430 linux-sandbox. なので、多分AとCは違うところで止まってる。 最近のTurboBoostのマシンは知らんが、それでも同一マシンで流して1.5-3.4倍速になるとは思えない。 だから再度確認したほうがいいし、マジでメモリだけで1.5-3.4倍速になってるのなら普段から16GBで運用した方がいい。 (ついでに言うとB/Cはエラー前半見る限り同じ所で落ちてるが、こちらも2-3.4倍速になってる。 これも通常では考えられないので、前回のビルド結果が一部残ってたのではないかと思われるが、《configure時代なら make distclean 忘れ》 本当にメモリだけで倍速になってるのならマジで増設しとけではある) そして、プロセス多すぎ。Arch知らんがMint20.3xfceだと何もしてなければ250個程度。 バックグラウンドで何か動かしてるのなら、当然それらもメモリ食ってるので、それらの状況次第で落ちる場所も変わってきてしまう。 この場合、>>338 のようなことになり、精密なデバッグには不向き。 が、まあ、archはそういうもんならそれでいいが、なら最初からメモリ多めにしておくのが無難。 しかしまあここまでは所詮はデバッグ上の保険であって、これより以下が本命になる。 B,Cの前半見て分かるとおり、B,Cは明確にソースコード起因で落ちてる。 > [-Werror=maybe-uninitialized] > cc1plus: all warnings being treated as errors つまり、>>340 の言うとおりで、 未初期化(っぽい)のを警告とし、cc1で警告は全てエラー扱いにしてるから落ちてる。 だからこれらを外してしまえば、少なくとも現在落ちてるところは通るようになる。 一般的な問題としては、 > cc1plus: all warnings being treated as errors であり、そもそもC言語の文化では警告上等(=警告は無視するもの)であり、 警告が一つでもあればビルドを止める、なんて運用をしてるプロジェクトはほぼ無いはず。 このスレの連中なら、(まあ普段からしまくってるのかもしれんが) nVidiaのプロプライエタリドライバのインストール時や、カーネルのアップデート時にビルドをしてるはず。 それらのログ見れば分かるが、警告なんて出まくりのはず。(でも当然動いてる) ただまあこの文化はよろしい物ではないし、だからこそC++が出て来た、というのもある。 だから今回のケースでありそうなシナリオは、 1. ソースコード作成時には「全部の警告を出し(=-Wall)、プログラマは努力して全部の警告を消す、そうしないとビルドを通さない 2. そしてリリース時のgccバージョンでは、通る。(なお>>341 の言うようにこの時点でclangならclangでやらないと駄目) 3. その後、gccのバージョンが上がり、以前よりもチェックが厳しくなり、新たに警告が出る様になった。 4. なので、334,335の通り、落ちるようになってしまった。 だから、解決策としては、 α:リリース時のgccバージョンでコンパイルする(通常はダウングレードすることになる) β:オプションを調整して警告無視でコンパイルする であり、archの場合はパッケージリリース時のgccバージョンが多分明確に分かるはずなので、 まずそれを調べ、 α-1:もしリリース時のgccバージョンよりも現在使用しているもののバージョンが低いのなら、アップデートしてビルドを試す。 α-2:ただし通常はダウングレードになってしまうと思われるので、こちらは面倒だからやらず、 β:オプションを調整してビルド、 になる。(つっても面倒ならgccが最新版であることを確認してβだけでいい) 最近C言語やって無いので以下は勘であり間違ってるかもしれんが、 -Wはマクロであり、通常は環境変数で指定する。 configure時代は大体 CCFLAGS=-Wall みたいな指定方法だったが、今は知らん。 ただ上記も「追加」であり、「削除」はどこにどう指定するのかは分からん。 もし、パッケージビルドといってもガワ被せただけで結局configureしてるのなら、多分configure自体かそこから呼ばれるbashスクリプト内で export CCFLAGS=-Wall とかでデフォのオプションを指定してるはずだから、その辺を弄ることになる。 この場合はとりあえず grep 'maybe-uninitialized' * とかで探すことになる。 -Wall :全ての警告を表示しろ、の指示 -Wunused-but-set-parameter :変数に代入してるが使ってねえじゃん馬鹿ヤロー、と警告出せ、の指示 -Wallと被ってるから意味無い?まあそのとおりだが、この辺はダブっても問題ない、というノリ そしてこの通り、全部の警告を出す=動作上は問題ないけどソースコードをもっときれいに出来るよね、も警告になる だから自分でコード書くときは「全部の警告を出し、全部の警告を消す」ようにコードを整理するのが理想で、 多分このプロジェクトでもやってたんだろうが、その後gccのバージョンが上がり、新たな警告を出せるようになった場合は通らなくなる -Werror=maybe-uninitialized:未初期化(かもしれない)変数を使用してたらエラーにしろ、の指示 ただ言っちゃ悪いがC言語の文法では未初期化は検出できないので、 (ある程度実績のあるプロジェクトなら)これは誤検出であり多分やりすぎなので切っていい) なので、-Werror=maybe-uninitialized は勿論消すとして、 他に > cc1plus: all warnings being treated as errors を指示してるマクロがあるはずなので、それも消してビルドを試せばいい。 これについてはエラーログの > (remaining 62 arguments skipped) の部分をとりあえず全部表示させてコピペしてくれればそれっぽいの探せるけど。 が、これも面倒なら、ググッたら > export CFLAGS="-Wno-error" > export CXXFLAGS="-Wno-error" > ttps://qiita.com/g_votte/items/36013cc54482acd608e4 > Sure, find where -Werror is set and remove that flag. Then warnings will be only warnings. > ttps://stackoverflow.com/questions/11561261/how-can-i-compile-without-warnings-being-treated-as-errors この辺参考にして。 ところで > all warnings being treated as errors ってどういう文法なんだこれ? all warnings ARE being treated as errors でAREが抜けてる気がするんだが、今更gccの連中が基本的英文法間違ってるわけ無いし、省略していいとかあったっけ? (なお俺の英語はかなりいい加減なので間違ってたらご指摘よろしく) 単にbeing以下がwarningに形容詞的に掛かって全体としては名詞となっているだけかと file not found(名詞) と file is not found(文) みたいな 意味としてはほぼ同じになりますか >>350-351 A. all warnings ARE BEING treated as errors ←分かる、受動態の進行形、「全ての警告はエラーとして扱われている」 B. all warnings treated as errors ←分かる、文法用語で何かは分からんが、意味は「エラー扱いの全ての警告」、過去分詞が形容詞的に使われてるだけ C. all warnings BEING treated as errors ←分からん、わざわざBEINGをブチ込んで来る必要ないのでは?まあ意味は上記Bと同じだとは推測できるが。 Bだと、 all (warnings treated as errors) 「エラー扱いの警告の全て」 (all warnings) treated as errors 「全ての警告はエラー扱い」(厳密には「は」だと文になってしまうので間違いだが、いい日本語訳が思いつかない) が曖昧なので、BEING入れたら明示的に下側になるのか?なら最初からAでいい気もするが。(もしかしてBだと文法違反?) てな感じ。 とはいえ、よく考えたらインターネットなんだしアメリカ人に上記ABCの違い聞けばいいだけだからそうしてみるわ。 回答ありがとう。他の人もサクッと分かればよろしく。 こんばんは。 mozc-utで苦しんでた者です。 ふと見ると、昨日付けでmozc-ut、fcitx5-mozc-ut のバージョンが上がってました。 git pull して再ビルド。 gcc13を依存関係で要求されて入れました。 これでメモリ8GBでも、ビルド成功しました。★ 皆さま、お力添ありがとうございました。 勉強になり、貴重な体験が出来ました。 しかしこういう問題に当たった時に 英文で、本家のフォーラムに報告して 作者に知らせて、一緒に解決して行ける様に なると、本物のハッカー?なんでしょうね。 蛇足でした。 mozc 2.30.5448.102-2になってるね -makedepends=('bazel' 'git' 'python') +makedepends=('bazel' 'git' 'python' 'gcc13') >>352 Aだとありとあらゆる警告がエラーと同義になるから意味合いが変わってくるんじゃね treatが自動詞なのか受身なのか一目で判別しやすいようにつけてるんだとは思うけど、「現状の」という意味合いも一応兼ねてると思う >>355 スレチなので放置してたし、君が何を言ってるのかもよく分からんが、 聞いてはいるので結果を書いておく。 A:受動態文 B:名詞句 C:分詞構文(participle)または名詞句 でABC共に文法的には問題なし、意味は全部同じで、全ての警告がエラー、 ただしこの場合はC(=gcc出力)がなんとなくよいらしい Waylandってゲフォと相性悪いようだけどみんなAMDerなん 俺もウェイ族に仲間入りしたい AURのnkf-2.1.5-3のファイル検証に失敗するな〜 Archwikiでsteamのクラッシュダンプ阻止するのに/tmp/dumps操作するのあるけどもう無効だよ dumpsに書き込めなかったらdumpsxxxとかいう別名フォルダ作ってダンプ&アップロードするから無駄 システム標準言語設定を英語にしていると、Googleページに表示されている日本語が□みたいになる。 システム標準言語設定を英語のままで、Googleページにある日本語をちゃんと表示させる方法ありますか? >>361 日本語フォント入れたか? ブラウザの言語設定はやったか? ブラウザのパッケージによっては言語パックを自分で入れないとダメだぞ >>362 ありがとうございます。 日本語フォントはまだでいれてませんでした。 既にはいっているものだと思っておりました。 試してみます! archは自分で選択したものしか入らない。 そこがキモで自由がある。 最小構成から始めたら、どのディストリビューションも自分で選択したものしか入らないと思うが、何が違うと言うのだ? >>365 Manjaroとかだとミニマルでも、DEも日本語フォントも入っちゃうますよ それが良い悪いかは、別として… フルカスタム系のライバルったら、Gentooぐらい? Man爺、実機にGentooインストール出来るようになったのか?w >>352 遅レスでスマソ、ネイティブに聞いてみた? エラーメッセージは交通標識や新聞の見出しのように文法的には正しくないけれど少ない語数で伝える場合があるらしい 例えば The file was not found. は file not found のように all warnings being treated as errors は All warnings ARE being treated as errors. から ARE が省略されているのかも >>369 ネイティブ(であろうと思われる人達)に聞いた。 具体的には投稿者の国が表示される某匿名掲示板だが。 連中は特に文法は気にしてないはずだが、 ・どれも文法的に正しい(米) ・理由は説明出来ないがこの場合はC(=gcc出力)がいい(豪) ・理由は説明出来ないがABCどれも同じ意味で「全部の警告」を「エラー」の意味になる(香港) ・見出し等の場合は短くする。Cを選んだ理由はこれ以外には思いつかない(米) だったと思う。 エラーメッセージが英語の文法的にどうとか意味ない。 エラーコードの数字が素数だから何だとかいうくらい無意味だ。 有名な開発者でも自分が英語ネイティブじゃないからメッセージの文法間違いとかの修正はほぼ無条件で受け入れてるとか公言してる人もいるしね >>371 俺らが日本語のおかしい中華製品や詐欺メールから受ける程度の地雷感はネイティブにはあるだろうよ だから今更-Wallのメッセージが間違ってるはずもないのだが、ちと引っかかったので 短くするだけならBでいい気もするが、とにかくCらしい、省略するにしても何かしら感覚的な規則があるのだろう エラーが一意で判別できることが優先で、メッセージの頭だけ表示やカプセル化時の文字数制限を考慮して、前の方だけで意味が取れれる方が望ましい「一意記号」にすぎない。だから文法・語順はできれば程度の話でしょ。 英語として成立していなかったら英語のエラーメッセージを出す意味がない 文法上は正しくてもネイティブには物凄く不自然に感じる表現というものあるが、文法が合っていて意味が通る事は最低限のライン 日本語のエラーメッセージが怪しい日本語だったら文句言いそう Linux初心者の英語上級者(TOEICほぼ満点)だけど、間違いじゃないよこれ このbeingはbeの現在進行形であって、受動態のときに追加するbe動詞ではないので単独でいい 省略ではなくて普通に正しい文 話し言葉としてはめちゃくちゃ変なので初心者が違和感を覚えるのは分かる 日本人の英語教師は 英語では主語だけの省略はない としょっちゅう言ってたけど大嘘 英語でも日本語並みに省略しまくるし、文法も構文も無茶苦茶 非ネイティブに通じる文章を書くには文法と構文に誤りがないことが最低限必要 そして文の短さよりも文法解析と構文解析が平易な文に書き直す必要がある 「うんこ:臭い」は日本語の文章としては色々不足しているけど普通に理解できるだろ どの言語でもそれと一緒 >>379 助詞がないだけの平易な文ですやん 例えば おまーんこくさいくうこう ぐらいになると、まず解釈が一意に定まらないので翻訳できなくなる 「臭い」が適切であ事もコロンをセパレータに使う事が許されるのかだってちゃんと日本語を知ってなきゃわからないよ おれにはアラビア語やヘブライ語ではこういう:の使い方が許されるのかどうか、語順は反転しないでいいのかとかは全くわからないし >非ネイティブに通じる文章を書くには文法と構文に誤りがないことが最低限必要 これは言い過ぎ。 低IQの非ネイティブにはやってあげた方がいいかも知れない waylandネイティブだとchromeで日本語入力できない感じ? >>383 省略・文法・構文の破綻が酷くて解釈が一意に定まらない文章を書く低IQのネイティブをなんとかしてくれ 書き手1 <<<<< 読み手膨大 なことが多いんだから、書き手が労力を費やす方が総コストは圧倒的に少なくて済む 新聞記者でも糞文章書く低IQが結構いるんだよ。校正する時間がないから糞文章がそのまま世にでることになる いいんだよ。愚痴ってるだけだから 国語力ってのは収入に結びつきにくい能力で軽視されるし 国語力を着実に向上させるの教育法も確立してない 日本の場合、歪んだ国語力だから、“超算数”が生まれてしまうんだけどな クズな小学校教員が多いので、どないしようもない >>389 共通テストの数学について言ってるなら、あれは国語科が悪い。 理系では古文/漢文/ついでに小説も廃止で、現代文と技術文書(簡単だが分量が多い)を読ませるべき。 (そしてこれが出来ないのは国語の先生のちっぽけなアイデンティティとプライドが失われるからだろう) 小学校で繰り広げられてる 3x2≠2x3 については、 先生のハズレを引いたと諦めて無視するのが一番ましだろう。 技術文書の読み方なんかその専門科目の一部としてやるべきもんだろ。 自分の専門でもないものの技術文書なんか読んでられるかよ。 ましてや高校生が。 >>389 超算数 が何か知らなかったので検索してしまったよ ttps://matome-kids.blog.jp/archives/22031442.html これを×にしてしまった算数教師は、確率で樹形図(場合の数)を書く能力を持っていないということだよね 小学校教員免許の筆記試験には確率統計を必須にすべき 俺も超算数をググってみた 日本語では「4×3」は「4の3倍」を意味します。 しかし,英語では「3の4倍」を「4 times 3」と言い,式にすると「4×3」となります。 つまり「4×3」の意味が真逆になります。 この英語の順序だと,文字式「4a」が 「aが4倍」という見方をすることがあるのと矛盾しない順序になってます。 ですが「日本で」と限定するなら, 「1つ分の数」×「いくつ分」=「全部の数」という前提に掛け算について考える方が良さそうだと言えるでしょう。 「3×2」の式を見て「3個ずつが2つ分」 そういうところやたら不正解にしたがる教師の悪癖が意味不明すぎる 人名漢字なんて誤字起源の文字だらけなのに >>391 共通テストの数学が国語になってるのを知ってるか? 技術文書でなくてもいいが、要は普通の頭があれば普通に読める、 今の共通テストの「数学」みたいな文書を読めるかだけをチェックする「国語」でいい。 共通テストの数学が国語になった理由は、理系にとって必要な国語力を共通テストの「国語」では計測出来ないと見切り付けたからだ。 理系にとって必要な国語力とは、普通の文書を普通に読み書き出来る能力であって、小難しい文書を読み書き出来る能力ではない。 (ArchWiki/MDN/MSDN程度の難易度の文書、ただし量は多い、がさらっと読めるかどうかだけでいい) 考えてみれば、東大入試(理系)の国語は簡単で、以前は60点(80点満点)取れるのは当たり前とされていた。 これにより、国語能力が一定水準以下の馬鹿は足切りされていた。(3行しか読めない馬鹿はここで切られる) (ただし今は平均点が40点台なので違ってきてる。 共通テスト「数学」で「国語」能力を計測する状況に対応しただけかもしれんが、詳しくは分からん) 文系にとって古文/漢文が必要なのかは俺には分からん。 ただ、共通テストは大学を目指す者が第一に目指す物であり、その歪みは大学入学者に直接反映されてしまう。 おそらく「理系の国語」を定義して、従来の文系が主導してた「国語」と分離するべき状況になってる。 arm64にsiki入らないのかな。 proot_distroなんやけど >>384 設定ファイルで起動時のgtkバージョン変えてあげると出来たんだけど、最近まだ出来なくなったんだが。 ひさしぶりにarch開いたらupdateの嵐が吹き荒れた ninja はけっこう普及したが、 samurai は一般化しなかったな。 >>384 fcitx5ならgoogle-chrome-stable —enable-wayland-imeでいけるのでは >>384 fcitx5ならgoogle-chrome-stable —enable-wayland-imeでいけるのでは waylandは壮大な夢物語だな。 Xと互換あってレガシーな機能を切り捨てるとか のほうが多分よかったね もうWaylandに対応できないソフトの方を切り捨てるから無問題 text-input が stable にならない限り英語圏のオモチャだよ >>409 なんかたまに動かなくなるんですよね 変換候補が出ないのは追加でなんか入れると直るみたいですね fcitxのgithubって中国語で活気かがっていいね 日本人の作るものは、日本人しか対象にしてなくても、英語だからなあ… 中国人に少しあこがれる 今更glib2がglib2とglib2-develに分割された理由って何だ? archはdebian系のxxx-devとかredhat系のxxx-develみたいにパッケージを分割しない方針だと思ってたんだけど。 >>418 GitHubで検索したらfcitx5用を作ってくれてる日本人もいるにはいるね。 https://github.com/yasuking0304/fcitx5-sweet-dark-theme 若い人なのかとTwitterみたら60歳とか書かれててたまげた記憶が >>420 OSS参加したいけど、 日本語でやれるのって本当少ないんよね 中学レベルの英語が全くわからないので、英語だと厳しい >>422 そう思うなら、自分で日本語でOSSを起こして開発すればいい miskey とか github で日本語でゴリゴリやっとるで >>422 日本人が作ってくれたOSSのissueに「日本語でいいっすか」みたいなのを英訳して書いて質問してみたらいい 人によっては日本人以外の人もいるからちょっと困るって人もいれば、全然オーライって人もいる >>422 Linuxでは圧倒的に日本語ドキュメントが足りないから翻訳参加できる。。。がArch Linuxは特別日本語ドキュメントが しっかりしてて、あまり出る幕はなく、その状況に感謝するばかり。 ゲーム好きなら、オープンソース以外の市販ゲームでも支援プロジェクトが山程ある。ファンアート投稿するのもよし、 用語登録や攻略投稿するのも立派なオープンデータ支援(ただし行き過ぎた著作権侵害には気をつけてね)。 気合い入れてる人だとsteamにある海外製のマイナーだが面白いゲームの日本語翻訳支援プロジェクトに参加してる人も いる。たとえオープンソースではなく市販ソフトであっても支援できることは山ほどあるよ。 pacman -Sdd cui ってしたらpacmanが動かなくなった、助けて >>431 430だけどicuでした、テンパっていたのですいません read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる