Új hozzászólás Aktív témák
-
Sipi
addikt
válasz
VladimirR
#3389
üzenetére
Szerintem a fő rsync szerverrel van valami gond - pár napja időnként "file size not match" hibát kapok sync után. Random ebuildek más méretűek lesznek, mint ami a manifestben van.
Egyszer volt ilyen, amikor a fő rsync merevlemezei teljesen bekepáltak, későn kapcsolták le, és majd az összes alszerver átszinkronizált róla. Akkor azt hittem, szétment a vinyóm, de kiderült, csak a Portage fa volt rossz.
A websync vagy a daily snapshot megoldás ilyenkor.
Sipi
-
VladimirR
nagyúr
válasz
VladimirR
#3388
üzenetére
a harmadik emerge --sync utan eszheztert
valszonuleg kozrejatszott, hogy volt egy kisebb hdd problema (virtualis gep es emerge -ave world kozben a host-on elfogyott a lemezterulet, igy beleszaladtam egy kisebb adatvesztesbe), de nem ertem, hogy miert nem pofozta helyre az elso sync
-
czappa
aktív tag
válasz
VladimirR
#3377
üzenetére
Köszi szépen!
to all:
A második (KMix-es) kérdésemhez:
A neten keresgélve látom, hogy - természetesen - nem egyedi a probléma.
Ideáig két megoldási javaslatot találtam:
a) KMixben -> Settings -> Configure KMix -> Restore volumes on login
Ez eddig is be volt x-elve, így nem ez a megoldás.
b) shellbe: alsactl store (rendszergazdaként)
Majd később jelentek, hogy ez bevált, avagy sem. -
Sipi
addikt
válasz
VladimirR
#3352
üzenetére
A bind-tools része az nslookup és a host is.
Az első haosnló a Wineshez, ha nem adsz, a default DNS servert használja, ha kötőjelet teszel utána, az utána álló nevet/címet.A fejlettebb host parancs pedig olyan, hogy ha egy nevet adsz meg neki, azt keresi, ha még egyet, azt a DNS szervernek veszi.
Sipi
-
VladimirR
nagyúr
válasz
VladimirR
#3323
üzenetére
na, szuletett reakcio, egybol ketto is
a masodikkal viszont epp vitaban allok, mert szerintem a ket bug egy es ugyanaz, viszont o nem akarja megerteni, hogy ha emerge-vel, vagy make-kel forgditom, akkor nekem is felzabal minden ram-ot, majd elszall, s csak akkor segfault-ozik, ha kulon a dht_manager.cc sorat kimasolom a make kimenetebol, s azt akarom futtatni a megfelelo konyvtarbanno de nem is ezert irok, hanem mert keri, hogy adjak neki build.log-ot, viszont nekem egy arva build.log nincs a gepemen
mifele allat ez, s mi kell hozza, hogy teremjen?valaszaitokat elore is koszonom
-
Sipi
addikt
válasz
VladimirR
#3343
üzenetére
Nem hagysz ki semmit. A kernel üzenetében az van, hogy force use of acpi=ht. Valami miatt bekapcsolja az ACPI-s HyperThreadinget, ami olyan procin, ami nem támogatja, egyenértékű azzal, mintha kikapcsolnád az acpi-támogatást.
Talán a kernelnek meg kellene adni az acpi=noht kapcsolót, vagy kísérletezni a különféle acpi= kapcsolókkal, hátha valamelyiknél nem akar HT-t.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3321
üzenetére
Jajj, de kár, hogy csak most olvasom, így nem írhattam be ugyanezt.

A 3.4.6 nem ancient. A 3-as és a 4-es két külön állatfaj, nem fognak elhajtani emiatt.
Én a bugs.gentoo.org-ot jobban csípem, mert az ottani fejlesztők nagyon szoros kapcsolatban szoktak állni a programfejlesztőkkel. A gentoo-t sok progrsmíró használja amolyan homokozóládának, mert a forráskód proglémái itt tutira előjönnek. Ha a Gentoo-soknak írsz, úgyis eljut a gcc-sekhez is.Sipi
-
Sipi
addikt
válasz
VladimirR
#3316
üzenetére
99%-ban mehetsz bugreportolni a gcc-teamnek.

Ha biztos akarsz lenni, próbáld ki (ugyanígy kézzel), hogyg++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -g -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT dht_manager.o -MD -MP -MF .deps/dht_manager.Tpo -c -o dht_manager.o dht_manager.cc
Illetve egyre kevesebb parancssori kapcsolóval. (A -M-esekre gondolok, az include maradhat.
)Sipi
-
Sipi
addikt
válasz
VladimirR
#3307
üzenetére
Jááááá, vagy nem mondtad, vagy nem értettem!
Csinálj hozzá ebuildet! Alap: egy létező rtorrent ebuild, átnevezed rtorrent-9999.ebuild-re. Az elejére beteszed egy másik -9999 ebuildből azt a részt, ahogy az svn-ből cincálja a dolgokat. Szépen megírod.
Vagy ha nem akarsz tökölni: innen letöltöd, beteszed a lokális Portage-fába (alapesetben /usr/local/portage szokott lenni). Aztán unmaszk meg emerge.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3305
üzenetére
Tudom, írtad, csak azért írtam le megint, hogy jelezzem, ez a c++ internal error nem az az internal error, amikor a gcc fejlesztőknek sürgős bugreportot kell írni.
Memory leak csak a gcc-ben lehetne, de ennél a régi verziónál ezt kizárom. Leak lehetne még valamelyik külső lib meghívása miatt, akár a debugolás, akár a 4-es sorozat egzotikusabb dolgainak kihasználásánál. Ez megint kizárt. LD-nél sem lehet gond, mert itt a linkelésig el sem jut.
Én alapból kikapcsolom a make.conf-ban a debugot, totál felesleges... Van még az ipv6 kapcsoló, próbáld meg annak ki- és bekapcsolásával is (meg egy xmlrpc is, azt is), hátha... ipv6-tal más jellegű problémáim már adódtak (ruby, ha jól rémlik), a hibának látszólag semmi közük nem volt az ipv6-hoz.
Szerintem rtorrent-hiba, ez a cc-fájl nem is nagy (a 0.8.0-ás verzióban), lazán vinne kellene a gcc-nek.
Jut eszembe, anno a kmailnél volt olyan kiadás, amit ugyanígy nem tudtam lefordítani. Ott valamelyik -r revvel patkolták. Ma is zabál, de legalább lefordul. Ilyenkor várni szoktam, majd csak kijavítják.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3303
üzenetére
Ezt a hibát többnyire akkor dobja, ha kevés, és ezért elfogy a memória és swap, szerintem figyelmen kívül hagyhatod. Debugot miért kapcsolod be? Az is növeli a c++ programok fordításának memória-éhségét (ami egyébként is nagy).
Sorry, hardenedet elfelejtettem. Olyat nem használok. A /usr/profiles/hardened mappában tényleg hardmaszkolva van a teljes 4-es gcc sorozat... Pech.
Itt van pár infó arról, hogy mi vár rád, ha kézzel unmaszkolod a 4-es sorozatot, és hardeneddel akarod használni. (A 4-es még nincs felkészítve erre, ettől még működő kódot készít, csak az új funkciók nélkül.) Az utána következő válaszlevelek is érdekesek lehetnek.
Szerintem nem gcc hiba, a kmail is olyan, hogy a 800 mega memóriám eltűnik a fordítása közben. Evvan, én az rtorrentre gyanakszom. Nem hiba, inkább csak rosszul megírt kód lehet.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3301
üzenetére
Eddig úgy vettem észre, hogy ha a gcc nem ad internal gcc error, contact the developers hibát, akkor az adott programmal van gond.
Az, hogy csak adott revtől jön elő, megerősít ebben. (Csak egy tipp: esetleg a forrás olyan dolgokat használna, amit a 4-es gcc-ben vezettek be.)Egyik gépemen 4.1.2, másikon 4.2-es gcc van, semmi gondom nem volt még egyikkel sem. A 4.1.2 stabil, használhatod. Szerintem érdemes áttérni a 4-es gcc-re, a plusz tudása miatt.
Sipi
-
escie
őstag
Új hozzászólás Aktív témák
- Pedzegeti az új Xbox irányát a Microsoft
- Renault, Dacia topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Kormányok / autós szimulátorok topikja
- talmida: Változások 2. rész
- Tőzsde és gazdaság
- Samsung Galaxy S25 - végre van kicsi!
- Kerékpárosok, bringások ide!
- Hobby rádiós topik
- Azonnali alaplapos kérdések órája
- További aktív témák...
- Játékkulcsok ! : PC Steam, EA App, Ubisoft, Windows és egyéb játékok
- MEGA AKCIÓ! - Jogtiszta Windows - Office & Autodesk & CorelDRAW - Azonnal - Számlával - Garanciával
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Microsoft és egyéb dobozos retro szoftverek
- Fallout 4 Pip-Boy Edition eladó
- Samsung Galaxy S26 Ultra Spigen tok, üvegfólia
- GYÖNYÖRŰ iPhone 14 Pro Max 128GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3791
- DELL Latitude 5285 (Tablet)FHD, 2 az 1 ben, 12.3",i7-7600U,16GB DDR4, 256GB SSD, WIN11
- Beszámítás! LENOVO LOQ 15AHP10 FHD Gamer notebook - R7 250 32GB DDR5 1TB SSD RTX 5050 Max-Q 8GB
- iPhone 11 Pro Max 64GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS4377
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Egy ideig néztem, nekem sem ment, de a neten másoknak sem.


