Van egy nagyon régi bash scriptem, amely az általam kívánatosank gondolt csomagokat letölti a Fedora build szerverről, majd feltelepíti azt. Fedora 41-hez tavaly augusztusa óta nincs újab build bash-ből, tehát az nem változhatott. Kernel frissült 6.12.11-re, de azt alsóbb rétegnek gondolom.
Aztán ez a scriptem efféle hibaüzeneteket produkál:
/usr/bin/bash: line 1: package1: command not found
/usr/bin/bash: line 1: package1: command not found
Meg ilyeneket:
parallel: Warning: No more processes: Decreasing number of running jobs to 31.
parallel: Warning: Try increasing 'ulimit -u' (try: ulimit -u `ulimit -Hu`)
parallel: Warning: or increasing 'nproc' in /etc/security/limits.conf
parallel: Warning: or increasing /proc/sys/kernel/pid_max
parallel: Warning: No more processes: Decreasing number of running jobs to 30.
parallel: Warning: Try increasing 'ulimit -u' (try: ulimit -u `ulimit -Hu`)
parallel: Warning: or increasing 'nproc' in /etc/security/limits.conf
parallel: Warning: or increasing /proc/sys/kernel/pid_max
parallel: Warning: No more processes: Decreasing number of running jobs to 29.
parallel: Warning: Try increasing 'ulimit -u' (try: ulimit -u `ulimit -Hu`)
parallel: Warning: or increasing 'nproc' in /etc/security/limits.conf
parallel: Warning: or increasing /proc/sys/kernel/pid_max
parallel: Warning: No more processes: Decreasing number of running jobs to 28.
parallel: Warning: Try increasing 'ulimit -u' (try: ulimit -u `ulimit -Hu`)
parallel: Warning: or increasing 'nproc' in /etc/security/limits.conf
parallel: Warning: or increasing /proc/sys/kernel/pid_max
parallel: Warning: No more processes: Decreasing number of running jobs to 27.
parallel: Warning: Try increasing 'ulimit -u' (try: ulimit -u `ulimit -Hu`)
parallel: Warning: or increasing 'nproc' in /etc/security/limits.conf
parallel: Warning: or increasing /proc/sys/kernel/pid_max
Elég bután nézek ki a fejemből, mi változhatott milyen csomag rontott el bármit is. A package1 amúgy egy függvényem, nem külső parancs. A parallel december 24-én lett lefordítva, nem tudom, mikor került a gépre a legfrissebb változat belőle, viszont downgrade-eltem, és attól sem lett jobb.
A végén megörvendeztet még ilyesmivel is:
parallel: Error: No more processes: cannot run a single job. Something is wrong at blueman.
A blueman legfeljebb frissítendő csomag lehetne, nem futtatandó.
Tudom, kevés az infó, kellene a script, ha lesz időm, valahova feltöltöm, de nagyon sok éve működött, két-három napja romlott el.
A script: https://pastebin.com/a4vEFcNZ
És az alias file: https://pastebin.com/fvnjdNJz
Hozzászólások
Sajnos az indentálások rosszul jelentek meg a pastebin-en. Lehet, van benne vegyesen tab és szóköz, s talán ezért.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Szerintem az 535 - 550-es sorok között izgalmas.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha letiltod a parallel-t, akkor úgy jól megy? Ld. 473. sor.
Igen, kétségbeesésemben az volt az egyetlen próbálkozás. Valószínűleg igen, de mivel épp nem volt mit frissítenie, ezért nem frissített, de valóban nem dobált hibaüzeneteket.
Az az izgalmas, hogy a parallel downgrade-je után sem lett jobb. Tehát olyan, mintha a paraméterek átadása változott volna meg, mintha az export -f nem működne, de közben a bash sem változott már rég óta.
Nyilván nekem kell kidebugolnom, csak az a szörnyű az egészben, hogy van egy sok éve jól működő script, ami egyszer csak nem működik, én meg nézem, hogy ilyenkor mi van. Mindezt úgy, hogy az interpreter, tehát a bash sem változott. Persze glibc lehet, meg a fene sem tudja. Kernel például biztos, de azért nehogy már onnan fel tudjon idáig bármi burjánzani.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nekem is ott gyanús, az 540. sor környéke, hogy mi a francnak kell az a két darab export sor, meg hogy mi a rák az az export -f, nálam Arch-on az export parancsnak nincs is ilyen kapcsolója, csak -p kapcsolót listáz a man. Szerintem a package1 függvényt nullázza az export, de nem vagyok benne biztos.
Az egész script túl van bonyolítva, nem is világos, hogy mit csinál. Nagyon az az érzésem, hogy túlbonyolítottad feleslegesen. Bár a Fedora build szutykait nem ismerem.
Szerk.: látom megoldódott, de nem jeleztem megoldottnak a témát. Ennek ellenére nem törlöm a komment tartalmát, mert továbbra is szuboptimálisnak látom a megoldásaid.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Az export -f shell-függvényt exportál (értelemszerűen a paraméterként megadott nevűt). Bash találmány, ksh, zsh, yash nem ismeri.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Írd meg egyszerűbben! :) Az export - én írtam, de már csak sejtem, mit miért csináltam - szerintem azért került bele, mert a process substitution, meg subshell-ek világában valahogy el kell neki mondani, hogy a szülő shell függvényét használja. Cél volt, hogy egyetlen file legyen az egész, ezért vannak az awk scriptek egy-egy stringként létrehozva. Sok dolgot csináltam awk-ban, hogy gyorsabb legyen.
Bonyolultságról. Kezelni akartam az alias file-t, az alias file-ban lehet rekurzió, van exclude list, a build szerver weboldaláról keresi ki, ami kell, de csak azt tölti le, ami a szerveren újabb, mint a gépen, s csak azokat a csomagokat, amelyek korábbi verziói a gépen vannak. Nem olyan egyszerű, hidd el!
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
<troll>
Itt lenne az ideje újraírni Rust-ban! 😅
</troll>
Go, Rust, Go!
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Jó, ez meg a másik, amikor már te se érted a kódot, az is intő jel. Máskor kommenteld jobban :D
Arch alatt ezt az AUR helperek csinálják automatikusan, frissítik, mint az igazi csomagokat, de valójában nem csomagok, csak build scriptek, amik leforgatják vagy letöltik, ami a csomagba kell, és becsomagolják pkg.zst-re, hogy a pacman megegye.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Bash-ben, sed-ben, awk-ban eléggé elgondolkodtató jelölések vannak, nem olyan tiszta, mint a C, de bármilyen nyelven lehet egy algoritmus bonyolult, amiből nem látszik ránézésre azonnal, hogy mi van.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Jaja! Például a szakállas angyal bash emoticon képes volt áldott root jogot adni:
() { :;};
Ez erősen hiányos, nem ezt akartad írni?
:(){ :|:&};:
Mondjuk nem root jogot adott, hanem forkbombot, de kicsire nem adunk.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
A tied fork bomb, az enyém elvileg egy teszt, a mögé írt parancs akként fut le, amilyen környezetben váltódik ki. Ha apache felhasználóval futtatsz egy web szervert, és ez érkezik be, akkor apacheként, de ha root-ként fut a támadást hordozó program, akkor root jogot kapsz a gépen.
Érteni vélem amit írsz, de ez így szintaktikai hiba. Már klasszikus Bourne-shell szintaxist használó eszköz esetén. Ha valamit benézek, akkor legalább egy nyelv megnevezésével segíts (pláne a teljes parancssorral), aminek az interpreteréhez ezt odaadva csinál valami értelmeset, mert magamtól nem jövök rá. (Perl-t és Python-t kipróbáltam, egyik se szerette.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Egy már kijavított bash hibáról van itt szó, vagyis a ksh93 vagy a Perl, vagy a bash5 valószínűleg nem fogja reprodukálni a hibát.
https://en.wikipedia.org/wiki/Shellshock_(software_bug)
A shellshock az az exportált függvény elszabása volt a bash-ban, fenti mikulás meg egy név nélküli függvény definíció. De fenti linked alapján már látom, hogy hogyan jönnek egymáshoz. Így legalább értem, köszönöm.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igen, ezért kell magyarázó kommenteket írni hozzá, nem szégyen. Nem csak fogyatékosoknak van, mivel legközelebbi fogyatékos, aki nem fogja érteni, az a személy, aki a kódot írta (saját tapasztalat), és egy jó idő múlva néz rá, amikor már a kód miértjére nem emlékszik, viccen kívül megesett velem többször. Pont ezért találták ki a kommenteket, nem dísznek. Ezért nagyon fontosak a beszédes függvény- és változónevek is, meg a helyes indentálás, stb.. Az ember a saját dolgát könnyíti meg hosszútávon.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem arról van szó, hogy a /usr/bin/test-et nem bírja meghívni, mert nincs rá link "[" néven?
Science for fun...
Régen Fedorában symlink volt, most nézem önálló file, még csak nem is hardlink, mert a test és a [ file-ok hossza eltérő. De ez belső bash parancs is. Az mondjuk érdekes, hogy a which ez utóbbi tényt nem emlegeti fel.
Most el kell mennem, ha nem reagálok, az nem azt jelenti, hogy nem érdekelnek a hozzászólásaitok! :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát ugye... ulimitre panaszkodik, meg subshellt indít... persze ez önmagában abszolút nem indok, de egyfelé mutatnak. Meg a ~20 processz kb. a nullával egyenlő, hacsak a package1 nem szül borzasztóan sok valamit.
Aztán elindítanám /bin/bash -x -el is, hátha a sok mindenben feltűnik neked valami, aminek nem úgy kéne lennie.
Igen, én is arrfele nézelődnék. Lehet hogy csak valami nagyon edge case-t kapott be a rendszer és egy "minden paraméterre inditsunk külön processzt" (vagy ezzel ekevalens) megkozelites futott ki az eroforrasokbol. Ami egyebkent szinte mindig jo (volt, egeszen mostanaig).
8 magos Ryzen7 5700G, magonként két szálon, 32 GiB RAM. Sima desktop felhasználás, szóval az erőforrás probléma nem valószínű.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A 357. sorban cserélnék így:
function package1 {
... scripted többi része
}
export -f package1
OT
Shell függvény exportja erős bashizm, és 10 éve elég csúnya biztonsági lukat okozott az a barom módszer, ahogy megoldották a bash-fejlesztők. (Lásd pl: shellshock) Helyette a shell függvények autoload mechanizmusát kellene használni (FPATH változó és typeset -fu xyz), ha sikerült volna átvenni a Korn-shelltől. Ennek híjján javasolt a shell függvényeket függvénykönyvtárakba összegyűjteni / kiszervezni, és amelyik kell, azt kézzel source-olni ( . ~/FPATH/xyz)
/OT
És hogy valami ontopic is legyen: nem fogytál ki valami erőforrásból azon a gépen? Nincs valami random memóriahibád?
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
De erre miért üzenné azt, hogy "command not found"?
Science for fun...
Hát, valami fura kifogytam a filehandle-ökből hiba későbbi kezelésénél már lehet, hogy valaki azt hiszi, hogy azért nem futott, mert nincs. De ködszurkálás :)
Azert, mert egy shell szamara ez az alapertelmezes :D
Marmint, ha a sajat terminalodba beirod, hogy "elkelkaposztastalanitas" akkor arra is azt mondja, hogy elkelkaposztastalanitas: Command not found.
Igy mukodik a shell.
Blog | @hron84
via @snq-
Ezen elmélázok, köszönöm. Lehet, hogy még kérdezni fogok, csak most nem érek rá, elvégre hétvége van. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ráküldted már a shellcheckre? Van néhány piros hibajelentés azon kívül hogy a backticked már legacy. https://www.shellcheck.net/wiki/SC2006
Mi az oka, hogy nem várod meg, míg elkészül a bináris csomag? Fedorában ez elég gyorsan megy, ha jól tudom.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Ez bináris mind, csak a tesztet nem várom meg, amíg repóba kerül. Amúgy az, hogy néha én magam jelzek bugokat, s ha azt javítják, vissza kellene jeleznem a fejlesztőknek, hogy megoldódott.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Egy apróság a 329. sorban:
Igen, ha annak nincs értéke syntax error lenne, javítani fogom, köszönöm.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Vagy mondjuk:
De a:
is működik szerintem...
Az x-ezes az idezojellel egyutt konkretan fassag. Bash-ban biztosan.
Eleg a
Ne vedd magadra, Teve, nem rad vagyok merges, csak sokadszorra latom ezt a hibrid megoldast, es semmi ertelme nincs. Az x-nek akkor van ertelme, ha _nem_ teszed idezojelek koze a valtozonevet (azaz, ha [ x$nowarn = 1 ] a kifejezes), ha igen, akkor - megintcsak: bash-ban - ha a valtozo nem letezik, akkor egy idezojelek kozotti ures string lesz a kiertekeles vege, azt meg szintaktikailag helyesen irhatod le egy ilyen kifejezesbe => nem lesz belole syntax error.
Blog | @hron84
via @snq-
Ebben van igazság, de azért érdekelne, akkor is minden penge-e, ha a nowarn tartalma mondjuk az alábbiak egyike (az apostolok közötti részt tessék nézni):
Köszönöm a segítséget, glibc bug volt, ez javította.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát, erre nem gondoltam volna :D
Nem csak hogy én se gondoltam volna erre, de most se értem, hogy egy glibc bug miatt hogy nem talál a rendszer egy definiált shell függvényt. Mert oké, glibc bug, crash-elne vagy hasonló, akkor azt mondom, hogy valahol érthető, de nekem az egész X akta még mindig.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Az okot én sem tudom. Írtam is korábban, hogy ez a script működött, nem nyúltam hozzá, aztán egyszer csak nem működött. Ezért is adtam a topiknak azt a címet, amit. Mert nem önmagában rossz a script, csak kihúzták alóla a talajt, megváltozott az interpretáló környezet, miközben maga a bash sem változott.
Mindegy is. Glibc bug volt, de már jó.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát ja. Csak így nem tanultunk belőle semmit.
Azt hiszem, a többiek is ezt hiányolják.
Science for fun...
Ezt értem, de mit tehetek? Kezdjem az említett patch-eket kiszedni a glibc-ből, fordítsam le forrásból, és teszteljem egyesével, mikor jön elő a hiba? Ennyi felesleges időm nincs.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A Slackware-ben a testingben van a glibc-2.41, az meg a dhcpd-t és a network managert teszi tönkre.
Ó basszus, akkor azért tört el nálam is a dhcpcd, ma reggel, küzdöttem a debugolással meg kézi ip addr és ip route konfigolással, mire lett net. Tegnap este frissítettem, és én a kernelekre gyanakodtam, de most nézem a pacman logban, hogy a glibc is frissült, 2.40-ről 2.41-re.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
LOL, közben meg az Arch ezt tudva, csak azért is kiteszi a stabil Core tárolóba a 2.41-es glibc-t, tudván, hogy több mindent eltör, közöttük a Discord-ot is (amit utálok, nem is használom, de sok embernek elengedhetetlen, óriási zúgolódás lesz belőle). Nem is értem miért jó ez nekik, már a Testing-be se lett volna szabad betenniük, mert nincsenek a rá épülő csomagok a 2.41 ellenében fordítva. Az ilyen, a Staging tárolóba való, ami pont azt szolgálja, hogy a függőségeket azzal tudják már fordítani, ez szándékosan ki is van emelve a Wiki-ben. Gyakran az az érzésem, hogy mostanában már csak a szopatás öröméért szivatja a felhasználókat az Arch maintainer csapata.
Pedig ha valaki, én abszolút frisseségmániás meg verzióhajhász vagyok, de ez nekem is sok, hogy tudatosan törik el mindenki rendszerét. Egyértelműen a Testing fázisban megbukott, túl új még, upgrade-elni kéne először a többi csomagot, de be van sózva a valaguk, mintha pár nap különbségen múlna az életük. Ennek a szintű kényszeres kapkodásnak már semmi értelme, zárt osztályra való mentalitás.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Akkor most már kezded érteni, hogy miért van, aki nem a rollingot preferálja?
Nem, ezekkel nem az a baj, hogy rolling, mert lehetne azt is normálisabban csinálni, hanem hogy féktelen hülyék. Ilyenkor vissza kell tartani a csomagot, míg a környezeti problémák nincsenek megoldva körülötte.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Na de pont ez az, hogy egy rollingban valójában viszonylag kicsi garancia van arra, hogy észreveszik, hogy vissza kéne tartani.
(Arról már nem beszélve, hogy mondjuk a saját szarom, amit meg kéne javítanom, arról nem fog tudni, és betolja alá a szar libc-t)
Azert az Arch-nal - ami rolling - is ki van ez rakva jol. Mert a testing tarolot csak azok hasznaljak, akik utaljak az eletuket :D a tobbi normie meg kikommentelve tartja, nem is foglalkozik vele, es el boldogan a tobbi repobol + AUR.
Blog | @hron84
via @snq-
Azért itt arról van szó, hogy nincs még glibc 2.41 ready discord release, amit szállítsanak, de leírták, hogy milyen alternatívák vannak. A discord meg zárt, nem tudják backportolni a javítást.
Milyen más problémát okoz a glibc 2.41 a stabil repókban? A testinges tapasztalataid nem érdekelnek, a stabilban mit törtek el a glibc bump-al?
Mondanám, hogy a Discord hibája, igen, de nem csak azt töri el, hanem dhcpcd-t, meg egy jó pár másik csomagot is. Persze, ez egymagában nem a 2.41 hibája, nem bug, hanem feature, hogy nincs rá még semmi felkészítve.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Pont ezért kérdeztem, hogy mit tört el. Tájékoztatlak, hogy az Arch stabil repójában a dhcpcd patchelve van, nem töri a glibc. Milyen csomagokkal van még problémád a stabil ágon?
Az lehet patchelve van már, de első 2 nap eltörte, akkor nem volt. Gyanítom eltörhet egy csomó mást is, csak azokat nem használom. A Discord is ilyen, és még ki tudja mi, a glibc szinte mindennek függősége, közvetlenül vagy közvetve, elég sok alap dolgot el tud törni, akár a rendszert is kompletten bootképtelenné teheti. Máris voltak vele problémák, jó, lehet javítják ezeket, de ennek óvatosságra kéne inteni, hogy még várjanak vele néhány napot, mielőtt élesbe kilövik, hogy ne viszkessen a hátsójuk, hogy hama, hama, azonnal, 4-5 napon múlik az élet, muszáj most kitolni, nehogy holnapra megpenészedjen. Azt kéne csinálniuk, amit Mucsi mond, lenyugodni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Jó, tehát van egy darab csomag, amit eltört a glibc bump, de egy nap alatt javították, meg egy másik zárt forrású, amire van alternatíva, amíg az upstream kiadja a működő release-t.
Gondolom segítettél is a Arch közösségen legalább annyiban, hogy bug reportot írtál, nem csak a hup-on rinyáltál pár ezer karakterben:
> már csak a szopatás öröméért szivatja a felhasználókat az Arch maintainer csapata
> csak azért is kiteszi a stabil Core tárolóba a 2.41-es glibc-t, tudván, hogy több mindent eltör (erre még várom a listát mi mindent tört el)
> tudatosan törik el mindenki rendszerét (!)
> be van sózva a valaguk, mintha pár nap különbségen múlna az életük
> Ennek a szintű kényszeres kapkodásnak már semmi értelme, zárt osztályra való mentalitás
> nem az a baj, hogy rolling, mert lehetne azt is normálisabban csinálni, hanem hogy féktelen hülyék
> de nem csak azt töri el, hanem dhcpcd-t, meg egy jó pár másik csomagot is (miket is még?)
> eltörhet egy csomó mást is (miket?!)
> élesbe kilövik, hogy ne viszkessen a hátsójuk
Amúgy már évek óta nem használom az Arch-ot, bár az arra épülő Manjaro még van egy gépemen, de nagyon irritál ez a fajta mentalitás amit tolsz. Nem a kritika, mert bizony baszhatnak és basznak is el dolgokat. Hanem ez a fajta töménytelen ömlengés ahogy előadod. Lehülyézed őket egy hiba miatt? Te mit tettél hozzá az Arch-hoz? Korábban valami kerneles ámokfutásod során egy nyamvadt AUR csomagot se tudtál kirakni a magadnak fixált kernel csomaghoz (hiába kértelek), egy rohadt bug-reportot nem tudsz kiizadni magadból. Futtatod magad mekkora power user vagy, de a tudásodból nem osztasz vissza semmit a közösségnek, ha valami nem tetszik meg lehülyézel mindenkit, hogy szarul csinálja, a hibánál szándékosságot/rossz indulatúságot állítasz. Egyszer az a baj, hogy mikor jön az új glibc (akkor is mondtam, hogy esetleg segíts be nekik), majd hogy béna az új maintainer, most meg kapkodnak. Ha szerinted szar irányba mennek a dolgok az Arch-nál, jelentkeztél segíteni? Az Arch maintainerek nem annak születnek, hanem azzá válnak, te is csatlakozhatsz, biztos szívesen veszik a segítséget. Főleg ha rájönnek mennyire képbe vagy hogyan is kell ezt csinálni. De szívesen tennék egy próbát a Raynes Ultimate PowerGeek disztróval is.
Nem, nem egy csomag tört el, még egyszer mondom. Eltört több, tudunk kettőről, meg még lehet egy pár, amiről nem, mert nem használjuk, és aki megszívta, azok közül nem mindenki jelentget bug trackerbe, meg a bbs.arch fórumán, hanem szépen törli, és visszacsapatja a Zubuntut, Debiant, stb.. Ezeket fokozatosan javítják is, csak pár napot kéne még várni, mire feltérképeződik, hogy mely csomagok ezek pontosan, és melyik verzió javítja a kompatiblitást, esetleg csak újra kell fordítani a kódjukat.
Mondom, ne engem ragozzál, mert nem tetszik, amit írok. Nekem sem volt bajom az Arch-csal sok évig, pedig a Testing tárolót használom. Mondom, ez a csomagfenntartó hibája, mert tudja, hogy az új verzióval nem kompatibilisek a tárolókban lévő csomagok. Ennek az lenne a szakszerű menetrendje az Arch szabályzata szerint, hogy ilyen csomag, mint a glibc, előbb a Staging tárolóba kerül be, ezt használva a csomagfentartó újraforgatja a rá dependelő csomagokat is (sokszor ez is elég), ha ezek is készek, akkor ezt az összes érintett csomagot beteszi a Testing-be, ha ott kiállja pár napig az idő próbáját, akkor mehet a stable Core-ba. Itt viszont átugrották ezt a lépést, szívás is lett belőle, de még várni se vár vele, már pattintják is kifelé élesbe is. Ha csak 2 csomag is tört el, amik javítva lettek, de óvatosságra kéne intsen, hogy még pár napig várjanak vele. Nem hónapokat, éveket, csak extra pár napot, amíg még átpróbálgatják a vállalkozó kedvűek Testingben.
A kernellel is szívok, félre ne érts, de az upstream AMD / amdgpu hiba, amit maguk a kernelfejlesztők bénáznak több kernelciklus óta (6.10-6.13), arról az Arch nem tehet. Persze a kernelfejlesztők is kapkodnak, ugyanezt csinálták, kijöttek mindenféle energiagazdálkodási módosítások az amdgpu kernelmodulhoz, az aktuális dev kernel RC-jébe, ott szépen gyűlt velük a tapasztalat, szaporodtak a bugreportok, hogy fagyásokat, és újraindulásokat okoz egy kazal AMD GPU-n, erre nem hogy megjavították, ezzel a kóddal adták ki a stable mainline kernelt is, sőt, még tovább mentek, tudván, hogy rossz a kód, bugos, ennek ellenére visszaportolták a problémás kódot az addig nem érintett LTS kernelágakba is (6.1.x, 6.6.x). Azért azt érzed, hogy ez szemétség, és teljesen felesleges bajkeverés. Pont az lenne az LTS kernel lényege, hogy ilyenektől védjen, abba tényleg csak az kerüljön, ami tényleg annyira tesztelt és stabil kód, hogy nem törik el semmit, a konzervatív LTS disztrókon sem.
Az újraforgatás is rettenet fontos, pár hónapja a saját bőrömön tapasztaltam meg, néhány csomagnál, alock, st, dmenu, stb., amiket AUR-ból, vagy saját kódból forgattam, eltörtek. Ez se bug volt, meg nem is Arch hiba, hanem régi binárisok voltak, kicserélődtek alattuk a függőségeik, de azokhoz nem voltak újra hozzáfordítva. Pedig ez szükséges, nem véletlen, hogy a komoly disztróknál a build szerveren, ha a függőség frissül, akkor újraforgatódnak a rá épülő csomagok is, nem véletlen, hogy a Gentoo is így csinálja, ha jön egy új verzió valamiből, vagy te kapcsolták be/ki egy USE flag-et, akkor az összes érintett csomag, és azok összes érintett függősége újrafordul, akkor is, ha az ő kódjuk nem változott semmit. Ezt tökéletesen tudják az Arch-nál is, alkalmazzák is ezt, kivéve most ez a szerencsétlen glibc maintainer, most nagyon sürgős volt neki, hogy azonnal kitolja az egy szál glibc csomagot a Testingbe, és lusta módon, nem buildelte annak ellenébe a tőle függő csomagokat. Ez okozta a problémák nagyját, de még ebből sem tanulva, most már tolja kifelé élesbe is, úgy, hogy sok minden még mindig nincs az ellenében fordítva. Legalább írná ki a hírekbe, hogy hova siet most ezzel ennyire, kinek a segge ég, hogy annyira hama kint legyen az a 2.41. Mert megérteném még azt is, ha valami szenzációs új feature, vagy optimalizáció lenne benne, hogy nem lehet kihagyni, azonnal kell, annyira király, de ez az eset sem forog fent.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Hogyan segítesz jobbá tenni az Arch Linuxot.
Igen, ismerem ezt, fogom is jelenteni a jövőbeli bugokat. Ezt most nem kell, mert ebben az volt a poén, hogy tudják miket tör el, és annak ellenében is megy ki élesbe. Értem, most ezt a két problémát elhárították, dhcpcd-ből van új verzió, Discordból meg a Canari/dev ágat fogják használni, de ezzel szerintem még nincsenek kint a vízből, vissza kéne tartani néhány napot. Tényleg nem sokat, 3-4-et, egy egész hét se kell, csak amíg a Testingben felfedezik ezeket, meg nincs minden hozzáfordítva, a build szervernek max. 1-2 óra, 32-64 szálon forgatnak Threadripperrel, már évek óta. Ennyi napon már tényleg nem múlik senkinek az élete. Tehát nem jobbá kell itt tenni az Arch-ot, csak a csomagfenntartónak kicsit óvatosabbnak lennie frissítéskor, főleg ilyen csomagnál, mint a glibc, ez nagyon sok mindennek függősége, és durva eltöréseket tud okozni, így csak körültekintőbbnek kell lenni, mert a kernel, firmwarecsomag mellett a harmadik legnagyobb alapköve egy disztrónak, és elég szerteágazó hibákat tud okozni, ha valamit eltolnak rajta. Ha mondjuk csak egy nagyon ritkán használt Perl/Python modul lenne, vagy egy xeyes, és az törik el, az oké, eleve nem használják sokan, nem túl sok minden épül rá, eltörik, kényelmetlenség, de mindig workaround-olható. Ha a glibc van elszarva, az egész más eset.
Én egyébként nem vagyok jó tesztalany arra, hogy mi minden törhet el. Nem azért, mert lusta vagyok, hanem a rendszerem minimalista, csak 1000 natív csomag körül van (plusz fél tucat Appimage nagy ritkán, 0 Flatpak, 0 Snap, Electron appom is csak egy van, a Signal), és majdnem minden terminálos, kevés függőséges cucc, és nem is használok egy csomóféle szoftvert, nagyon szűk a felhasználási köröm. Azok a felhasználók jó tesztalanyok, akik a nagyon komplex, bloat rendszerük van, full DE, 3 ezer csomag a rendszerükön, minden mindenre épül, mindenfélét használnak, sokfélével játszanak, megy mellette CAD, videóvágás, optikai lemezírás, komplexebb nyomtatási feladatok, színkalibrálás, OpenCL, AI, VR, rajztábla, Java alapú cuccok, DAW/VST, csomó Electron app, Flatpakok tengere, intenzív webkamerázás, konténerezés, tonna virtuális gép, hibernálások-sleep tömkelege, meg ami szem-szájnak ingere, ha probléma van valahol, sokkal gyorsabban beleesnek a szórásba.
A Linux kernelesek esetében meg Torvaldsnak kéne keményebben fellépni, hogy a színvonal ne essen. Úgy, ahogy azzal a bcache-es fejlesztővel állandóan acél kemény, és osztja izomból lefelé, meg a CoC alapján büntetgetik, jogosan is, mert egy amatőr, izgatott b-α-sz, azt a szigorúságot kéne mutassa következetesen az AMD-s fenntartóval is, nem azért elnézőzni, mert az már évek óta neki dolgozik.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem azzal van a baj, amit írsz, hanem azzal, ahogy írod. Mintha te egy hibamentes szent guru lennél, aki még sosem baszott el semmit, és számonkéred egy ingyenes projekt szívességből dolgozó maintainereit, hogy hogyan merészelnek hibázni csomagkiadásnál.
Valójában az Arch-nál fényévente kétszer van ilyen hiba, vagy még ritkábban, ennyi meg az emberi hiba kategóriájába _szerintem_ bőven belefér, és bele is kell, hogy férjen.
Amúgy is azt láttam a többi írásodon is, hogy egy kicsit mintha a kelleténél hepciásabb lennél. Tök jókat írsz néha pedig, de ez a fajta stílus és viselkedés nem segít abban, hogy a közösség tagja legyél akár itt a HUP-on akár másutt.
És bocsásd meg, ha emberek szemedre vetik, hogy egy kicsit visszafoghatnád a lovakat.
Blog | @hron84
via @snq-
Van valami konkrétum, hogy pontosan mi változott? (Hogy mondjuk a malloc paramétere nem lehet prímszám, vagy mi?)
Szerk: lehet, hogy az 'executable stack' okozza a kavarást? Azt írja az intenet, hogy a 2.41-es `dlopen` nem tölti be a shared objectet, ha ütközés van a stack végrehajthatóságát illetően (vagyis főprogram NXS, sharedobject XS).
Említsük meg, hogy az execstack-nak függősége az elfutils, az elfutils pedig ilyen jókat tud mondani:
Vajon a g++ fejlesztői ezzel spóroltak valamit, vagy csak másképp hívják azóta ezt a __cxa_demangle-t?
Szerk: más hiba volt, de hát mit várunk egy ilyen configure-tól: ha bármilyen hiba van, azt annak tudja be, amit éppen tesztelt.
Ez viszont nehezebbnek tűnik:
Mondjuk így sem szereti:
Esetleg így?
További cukiság:
Szerinte hány bites kellene legyen az a derék offset `-m64` opció mellett?
Mindegy, F8 gomb megoldja. Továbbá:
Ez a frissen fordított libelf 0.192-es verziójú, úgy látszik, közben megváltoztatták a számozást. És mi az Sxword? Olyan, mint az Excalibur?
Szerk: előző adásunk ismétlése: volt valamilyen hiba, csak nem az, amire a configure gondolt.
Persze ezt ne úgy képzeljük el, hogy kijavítjuk a configure-t, és jó lesz... dehogy. A `make all` valamilyen lelki okból újra előállítja a hibás configure-t és azt futtatja.
Sokkal jobb:
A selinux még oké, azért nyilván azért tették bele, hogy felb...k az agyamat, de a libc-t nem értem, hogy milyen gonosz emberek járhattak erre, hogy eldugják szegény `ld` elől...
Kieg: a `--disable-selinux` opciót pont annyira veszi figyelembe, amennyire egy megkönnyítőprogramtól el is várnánk. (Semennyire.)
Szerk: valamiért beleálmodott egy `-static` opciót a linkage-be... meg se lepődöm.
Ez csak az érdekesség kedvéért:
https://stackoverflow.com/questions/75908689/how-do-i-compile-bash-4-wi…
A bash-4.4.18-hoz adott configure annyira elavult, hogy nem fordul a nyomorult, hacsak meg nem szórjuk
CFLAGS=-Wjoleszaz-nemerror
opciókkal.@OP: Na szóval azt kellene megnézni, hogy vannak-e bash-nak pluginjai, és ha igen, akkor hol, és hogy áll az 'executable stack' beállítás rajtuk. Esetemben:
Ebből a sor elején a minusz a jó jel, a X az aggályos.