[Megoldva] Bash valamilyen függősége megromlott

Fórumok

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

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)

Í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

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)

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.)

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.

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)

/usr/bin/bash: line 1: package1: command not found

Nem arról van szó, hogy a /usr/bin/test-et nem bírja meghívni, mert nincs rá link "[" néven?

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). 

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?

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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

Egy apróság a 329. sorban:

volt: [ $nowarn = 1 ] && return 0
lett: [ x"$nowarn" = x1 ] && return 0

Az x-ezes az idezojellel egyutt konkretan fassag. Bash-ban biztosan.

Eleg a

[ "$nowarn" = 1 ] && return 0

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szerkesztve: 2025. 01. 26., v – 12:09

Köszönöm a segítséget, glibc bug volt, ez javította.

* Sat Jan 25 2025 Florian Weimer <****@redhat.com> - 2.40-21
- setenv/putenv: Use new upstream free(environ) workaround (#2341908)
  (glibc-rh2341908.patch replaces glibc-environ-malloc.patch)
- Auto-sync with upstream branch release/2.40/master,
  commit 85668221974db44459527e04d04f77ca8f8e3115:
- stdlib: Test using setenv with updated environ [BZ #32588]
- malloc: obscure calloc use in tst-calloc
- Hide all malloc functions from compiler [BZ #32366]

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

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

Ó 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)

testing/packages/glibc-2.41-x86_64-1.txz:  Added.
  This breaks dhcpcd's privsep, and probably some other stuff.
  Nothing else in /testing is compiled against glibc-2.41.
  Also upgraded to libxcrypt-4.4.38.

 

It's because latest dhcpcd release doesn't work with new glibc 2.41. Latest github dhcpcd does work.

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)

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)

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

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)

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)

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

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).

Szerkesztve: 2025. 02. 11., k – 17:29

Említsük meg, hogy az execstack-nak függősége az elfutils, az elfutils pedig ilyen jókat tud mondani:

checking for __cxa_demangle in -lstdc++... no
configure: error: __cxa_demangle not found in libstdc++, use --disable-demangler to disable demangler support.

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:

configure:8919: gcc -c  -m64 -std=c99  -DBAD_FTS=1 -I/usr/local/include -D__UNIX__ -D__unix__ -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -D_ALL_S
OURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_THREAD_SAFE conftest.c >&5
conftest.c:49:43: error: expected declaration specifiers or '...' before string constant
   49 | #define NEW_VERSION(name, version)   asm (".symver " #name "," #name "@@@" #version);
      |                                           ^~~~~~~~~~
conftest.c:51:1: note: in expansion of macro 'NEW_VERSION'
   51 | NEW_VERSION (foo, ELFUTILS_12.12)
      | ^~~~~~~~~~~                    

Mondjuk így sem szereti:

asm (".symver foo, foo@@@ELFUTILS_12.12");

Esetleg így?

__asm__ (".symver foo, foo@@@ELFUTILS_12.12");

Mindegy, F8 gomb megoldja. Továbbá:

configure: error: libelf does not properly convert Elf64_Sxword quantities.
If you are using libelf-0.7.0, please use patches/libelf-0.7.0.patch.

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.

configure:19495:10: error: implicit declaration of function 'unlink' [-Wimplicit-function-declaration]
configure:19496:14: error: implicit declaration of function 'write'; did you mean 'fwrite'? [-Wimplicit-functio
configure:19498:14: error: implicit declaration of function 'lseek'; did you mean 'fseek'? [-Wimplicit-function

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:

ld: cannot find -lselinux: No such file or directory
ld: cannot find -lc: No such file or directory

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.

@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:

execstack /usr/local/bin/bash /usr/local/lib64/bash/*
- /usr/local/bin/bash
- /usr/local/lib64/bash/basename
- /usr/local/lib64/bash/dirname
- /usr/local/lib64/bash/finfo
- /usr/local/lib64/bash/head
- /usr/local/lib64/bash/id
- /usr/local/lib64/bash/ln
- /usr/local/lib64/bash/logname
- /usr/local/lib64/bash/mkdir
- /usr/local/lib64/bash/mypid
- /usr/local/lib64/bash/pathchk
- /usr/local/lib64/bash/print
- /usr/local/lib64/bash/printenv
- /usr/local/lib64/bash/push
- /usr/local/lib64/bash/realpath
- /usr/local/lib64/bash/rmdir
- /usr/local/lib64/bash/setpgid
- /usr/local/lib64/bash/sleep
- /usr/local/lib64/bash/strftime
- /usr/local/lib64/bash/sync
- /usr/local/lib64/bash/tee
- /usr/local/lib64/bash/truefalse
- /usr/local/lib64/bash/tty
- /usr/local/lib64/bash/uname
- /usr/local/lib64/bash/unlink
- /usr/local/lib64/bash/whoami

Ebből a sor elején a minusz a jó jel, a X az aggályos.