Új hozzászólás Aktív témák
-
-
Sipi
addikt
válasz
tierbatyo
#2959
üzenetére
Szerintem elírás a doksiban. Az xorg-x11 egy wrapper, semmit sem csinál, csak pucér rendszeren behúzza a csomagokat. Az xorg-servernek meg lehet adni a VIDEO_CARDS, INPUT_DEVICES változókkal azt, hogy mely drivereket húzza még be a szerverhez. Én nem lelek dlloader flaget sem az xorg-x11, sem az xorg-server csomaghoz - ez még a 6.8-as sorozatú xorgnál volt. De ez valami eszement régi!Mindenképpen érdemes unmaszkolni az xorg-x11 és xorg-server csomagokat, majd azokat, amelyek miatt sikít, hogy még kellenek neki. Nálam inkább ezek a ''béta'' xorgok futnak jobban.
Mod: fene, elkéstem.
Sipi
[Szerkesztve] -
hroleez
tag
válasz
tierbatyo
#2957
üzenetére
Már ott leakadtam, hogy a ''dlloader''-t leellenõrizzem...
padlas1 ~ # equery uses xorg-x11
[ Searching for packages matching xorg-x11... ]
[ Colour Code : set unset ]
[ Legend : Left column (U) - USE flags from make.conf ]
[ : Right column (I) - USE flags packages was installed with ]
[ No USE flags found for x11-base/xorg-x11-7.1]
padlas1 ~ #
MIért nem ír ki használt USE flagokat?
R. -
hroleez
tag
válasz
tierbatyo
#2955
üzenetére
Köszi! Feltettem a gentoo-sources-2.6.19-gentoo-r2-õt és mûûûködik! Köszönöm!
Az ati-drivert (igaz ugyanaz a verziót) feltettem újra, de a sebesség sehogyse több. A DRI-t engedtem a kernelben. Fordítsak újra xorg-server-t?
Az új kernellel is a boot elején nagyon dobja az udev hibákat. Remélem csak konfig bajság miatt...
De a billentyûzet sehogyse akarja az ALT-ot bevenni
Itt az xorg.conf része:
Section ''InputDevice''
Identifier ''Keyboard1''
Driver ''kbd''
# For most OSs the protocol can be omitted (it defaults to ''Standard'').
# When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
# uncomment the following line.
# Option ''Protocol'' ''Xqueue''
Option ''AutoRepeat'' ''500 30''
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option ''Xleds'' ''1 2 3''
# Option ''LeftAlt'' ''Meta''
# Option ''RightAlt'' ''ModeShift''
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option ''XkbModel'' ''pc102''
# If you have a US Microsoft Natural keyboard, you can use:
# Option ''XkbModel'' ''microsoft''
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option ''XkbLayout'' ''de''
# or:
# Option ''XkbLayout'' ''de''
# Option ''XkbVariant'' ''nodeadkeys''
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
# These are the default XKB settings for XFree86
# Option ''XkbRules'' ''xfree86''
# Option ''XkbModel'' ''pc101''
# Option ''XkbLayout'' ''us''
# Option ''XkbVariant'' ''''
# Option ''XkbOptions'' ''''
# Option ''XkbDisable''
Option ''XkbRules'' ''xorg''
Option ''XkbModel'' ''pc105''
Option ''XkbLayout'' ''hu''
Option ''XkbVariant'' '',101_qwerty_dot_nodead''
Option ''XkbOptions'' ''grp:switch,grp:menu_toggle,grp:led:scroll''
EndSection
Van valami tippetek ezekre?
Köszi,
Roland -
hroleez
tag
válasz
tierbatyo
#2952
üzenetére
Köszi! Így okés lett! Mûködik!
Viszont még mindig bootkor ahogy feljön a splash kép, megjelennek a következõk:
udev(601): add_to_rules: invalid KERNEL operation
udev(601): add_to_rules: invalud rules: lirc
(és ue. local és svgalib-re)
Mitõl lehet? Elvileg minden csomag pár nappal ezelõtti sync verziójú.
R. -
Sipi
addikt
válasz
tierbatyo
#2931
üzenetére
Nekem olybá tűnik, rossz fájlok, linkek maradhattak fent, s ezért van az rm: directory. (Pl. egy gcc link nem a régi gcc binárisra mutat, hanem egy gcc nevű könyvtárra.)
Egy manuális tesztet végezhetsz: állítsd be az új gcc profilt, valamelyik (lehetőleg legújabb) binutils profilt, és egy forrást tömöríts ki, majd kézzel configure. Talán többet ír ki, a config.logban talán több infó lesz. (Abban benne kell lennie a példaporogamoknak is, melyekkel teszteli, mi az uint, stb.)
Ha a glibc a régi gccvel készült, meg a kernel is, akkor szedd le az újat. A gcc-configgal az egyszem régi gcc profilt állítsd be, annak jónak kell lennie (mivel azt írtad ).
Miután van egy tiszta rendszered, egyszem működő gcc-vel, gcc-configgal, mehet a 4.1-es sorozat valamelyik tagja. Ne lepődj meg, ha nem fordul, van belőle hibásabb is. De a 4.1.1-es nekem jól megy.
Sipi -
Sipi
addikt
válasz
tierbatyo
#2929
üzenetére
Nem glibc hiba, tutira gcc. És le merem fogadni, hogy egyszerűen keverednek a profilok.
Felteszem, a multislot flag be van kapcsolva, különben nem lehetne két verziójú gcc.
Az eselect binutils list paranccsal nézd meg, hány van fent (ez is slotolható), majd állítsd be valamelyikre! (Az összes ilyen profil-állításra érvényes, hogy ha hiba van, érdemes átállítani valamelyik másra, majd megint vissza. Ilyenkor tuti, hogy az esetleges rossz linkek törlődnek és helyesen jönnek létre.)
Ezután jönne a gcc-config. Írtad, hogy leszedted az _összes_ verziójú eselect-compilert. Ezen kívül szedd le a 2.*-os gcc-configot is! Most nézd meg az envd/gcc-ben, milyen profilok maradtak. Mozgasd el az összes fájlt valami biztos helyre, majd tedd fel a gcc-config 1.3-as sorozatát! Ezek után megnézni, milyen konfigok kerültek fel az envbe. gcc-config -l. Jó lenne, ha felismerné automatikusan mindkét gcc-det.
Ha nem, és a fájlok sem léteznek, akkor másold vissza azokat, amelyerk a tényleges gcc-verzióknak felelnek meg! Nyisd meg mindet, és ellenőrizd, hogy a benne lévő könyvtárak léteznek-e, és arra a verzióra mutatnak-e, amire kell! Ja, és a /etc/env.d/05gcc-t is nézd meg, mi van benne.
Ha ez megvolt, lehet megint a gcc-configgal játszani, ide-oda kapcsolgatni a verziók között. Váltás 4-esre, env-update, source profile, majd gcc -v elvileg már jót kell, hog ykiírjon.
Ja, a ccache írját is töröld le, nehogy bekavarjon! Kapcsold is ki a make.conf-ban. A /usr/lib/ccache-ben vannak linkek, ezek zűrösek, ha a gcc hibádzik. (Ugyanis ezek átveszik a gcc binárisai felett a hatalmat.)
/etc/env.d/gcc/config:
CURRENT=x86_64-pc-linux-gnu-4.1.1
/etc/env.d/gcc/x86_64-pc-linux-gnu-4.1.1:
PATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
ROOTPATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
LDPATH=''/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32''
GCCBITS=''32 64''
MANPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man''
INFOPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info''
STDCXX_INCDIR=''g++-v4''
/etc/env.d/05gcc:
PATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
ROOTPATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
MANPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man''
INFOPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info''
LDPATH=''/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32''
GCC_SPECS=''''
A binutils táján is szétnéznék, hogy jó profilt használ-e.
Sipi -
-
Sipi
addikt
válasz
tierbatyo
#2911
üzenetére
Pontosan mit csinálsz, és mi a hiba? gcc-config -l mit ad vissza? Ha beállítasz egy profilt vele, az lefut rendesen? Majd env-update, source /etc/profile.
Utána kukk a /etc/env.d/gcc-be, mik vannak felsorolva? Milyen nevű profilok? Ezek tartalma létező könyvtárakra mutat? A configban melyik lesz a default? A /etc/env.d-ben a 05gcc-ben mi van, jó könyvtárakra mutat?
Sipi -
Sipi
addikt
válasz
tierbatyo
#2909
üzenetére
Felesleges újratenni.
Azért nem jó a gcc, mert nincs/rossz profilok vannak a gépeden.
Nem kötelezlek arra, hogy használj gcc-configot, de valszeg anélkül nem fog menni.
Az említett heéyen lennie kell egy config fájlnak, meg pár (vagy egy darab) i686-pc-linux-gnu-4.1.1 formájúnak. Ebben vannak a beállítások, a configban pedig CURRENT=xxx, az egyik fájkl neve, amelyik éppen aktív.
Ha belenézel a fájlokba, láthatod, milyen elérési utakat adnak meg. Ezeket módosítsd akár kézzel is úgy, hog yvalós helyre mutassanak.
A gcc-config paranccsal nem tudod helyrehozni? gcc-config X, ahol X a kívánt profil száma. Ilyenkor automatikusan generál linkeket, stb. Ha nem megy, árdemes gcc-configgal váltogatni pár profil között, míg helyre nem tér.
Mod: a doksik között, vagy a wikin van egy gcc upgrade guide is, anno nekem segített hasonló fejreállásnál.
Sipi
[Szerkesztve] -
Sipi
addikt
válasz
tierbatyo
#2903
üzenetére
Az eselect-compiler egy időben ki lett szedve, mert rosszul kezel multilibeket. Jelenleg is maszkolva van. Nem szabad használni.
Helyette a gcc-config KELL! Ezt tedd fel, tudsz profilokat váltani. Ez mindenképpen szükséges, mert a Gentoo alapból szimlinkekkel oldja meg a gcc könyvtárainak elhelyezését. Az /etc/env.d/gcc-ben vannak a fájlok, akár kézzel is írogathatod, ha valami tutira nincs fent.
A default output a.out elég rémisztően néz ki... Az az elavult forma.
A libstdc hiba megoldására a fix_libtool_files.sh való, mögötte megadni a régi gcc verzióját, amit leszedtél. Egyes fájlokba hardkódolva van a gcc pár elérési útja, ezt javítja át az újra.
Sipi -
asturel
őstag
válasz
tierbatyo
#2892
üzenetére
Marmint a x11-drm nem ment legujabb kernelekkel? Pont tegnap frissitettem 2.6.19-r1 -re 2.6.18-rol (amivel le is forodult az x11-drm), majd kiprobalok egy cvs x11-drm-et is hatha..
Sipi:
(II) AIGLX: Loaded and initialized /usr/lib64/dri/r300_dri.so
(II) GLX: Initialized DRI GL provider for screen 0
ezek szerint akkor megy az AIGLX-em nem ?
Gentoo-Wikin ez all:
'Cards Not Supported:
ATI: Radeon 8500 through X850 with the closed fglrx driver. Uses an ancient version of the DRI driver API that can't work with the new driver loader. No ETA on closed driver support.'
Szoval hiaba menne az fglrx, aiglx nem mukodne
, talan XGL-el, de azt meg felejtsem inkabb el?:p
Franya ATi, hogy nem tud normalis drivert csinalni -
asturel
őstag
válasz
tierbatyo
#2888
üzenetére
Hmm, hat Xorg log-ban ez van:
(**) Option ''AIGLX'' ''true''
Gondolom akkor mukodni kene nem? xorg-server ofkorz aiglx flaggel forditva.
''3D driver claims to not support visual'' problemara, mindenhol azt talaltam, hogy cvs mesa-ban mar fixaltak ezt a bugot (vagy megsem?).
Talaltam is egy oldalt ahol van hozza es meg par finomsaghoz cvs ebuild (lustasag power) [link]
Kesobb ki is probalom, ha sokaig nem jelentkeznek valoszinuleg agyverzest kaptam tole (probaltam cs-zni egyet, mihelyt kattintottam egyet csontta fagyott a Xorg, sshd meg nem futott, 2x reseteltem csak :|)
Mod: a kernel DRM-jet hasznalom, mivel x11-drm nem fordult le a 2.6.19-r1 kernelel.
[Szerkesztve] -
brazso
tag
válasz
tierbatyo
#2848
üzenetére
Valószínűleg valami sed-et hívó kis (ba)sh script van az otthoni gépeden. Ha rákeresel az interneten a replace.sh-ra sok megvalósítást találhatsz. Az én sem tudom, milyen gentoo-s csomagnak lehet(ett) a része.
Batman-nek meg köszönöm az ötleteket. Kigyűjtöttem pár linket a hibernálásról, este - ha lesz idő focinézés közben - kipróbálom a hordozható gépemen. -
Sipi
addikt
-
brazso
tag
válasz
tierbatyo
#2710
üzenetére
A Sipi megoldását követve próbáltam én is, de nem túl könnyű összeollózni a pontos fájlneveket mivel több csomagról van szó. Ez az -f kapcsoló jól hangzik, este kipróbálom. Köszönet a válaszokért!
Még arra gondoltam, hogy valahogy fel kellene rakni csak az emerge toolt (ha jól tudom pythonra irtak) windows-ra (pl. cygwin), vagy Sun Solaris-ra (ez utóbbin dolgozom jelenleg), és azzal lehoznám csak a forrásokat. Ha még le is tudnám fordittatni a lehozott forrasokat x86-ra, az már csak hab lenne a tortán -
Sipi
addikt
válasz
tierbatyo
#2617
üzenetére
Vazze, kipróbáltam. Az egy dolog, hogy nem indul el (az udevnél lehal, valami hardver-gubanc lehet). De az előző, r5-ös kernelem sem indult el többet! Ugyanúgy, ugyanott elhalt. Pár órát szenvedtem (khm, igen, a sima x86-os installcd nem jó a 64 bites rendszerhez
), mire elindult. De bootnál ekkor is kaptam IRQ xxx disabled üzenetet, s hálókártyám nem volt többé. (logban fatal kernel errorok röpködtek.)
Kernel megint fordít, telepít, így mintha működne, csak egy érdekes üzenet van bootnál. (XXX write TLV... - hogy ez mit akar jelenteni?)
Gőzöm sincs, mi lehet. Nem hiszem, hogy egy kernel szét tudna verni hardvert, de most csak az irqpoll kernelparamétert megadva tudok elindulni, egyébként ide-oda kivág pár kernel pánikot.
Sipi -
Sipi
addikt
válasz
tierbatyo
#2608
üzenetére
Pech... Az a baj, hogy a többi backend magukból az ebuildekből bogarásszák elő az adatokat, vagy sehonnan - ergo nagyon lassúak.
Nekem a jelenlegi legújabb Portage-nál, P2-es gépen is viszonylag gyors. Nem mondom, hogy elvakít a sebessége, de a --sync után már nem számottevő.
Esetleg csinálhatod azt, hogy a Portage snapshotokat töltöd le, tömöríted ki, és utána kézzel indítasz egy emerge --metadata-t.
Sipi
[Szerkesztve] -
Sipi
addikt
válasz
tierbatyo
#2601
üzenetére
Úgy tudom (legalábbis az eix ezt írja ki az emerge végén), hogy alapból a metadata módot használja. Ez a leggyorsabb (a cdb gyorsabb lenne, de az már nem nagyon működik).
A none és flat piszok lassú, a backport lenne gyors - de azt írod, nem megy...
Mi a gond a metadata-val? Nekem nagyon gyors minden művelet. Ráadásul az emerge --sync után bármikor kiadhatod az emerge --metadata parancsot, hogy elkészítsd a háttércache-t.
Sipi -
escie
őstag
válasz
tierbatyo
#2581
üzenetére
a cups felületéből másoltam ki:
Make and Model: HP DeskJet 3920 Foomatic/hpijs (recommended)
Printer State: idle, accepting jobs, published.
Device URI: hp:/usb/Deskjet_3900?serial=CN6131M1FR04CK
annyi a fejlemény, hogy a fejbeállító ábrákat ki tudom nyomtatni. de ehhez sejtésem szerint nem kell adatot átküldeni a printerre, csak úgymond kiadni a parancsot. az error log semmit nme mond, miért kerül megállításra minden job...
[Szerkesztve] -
escie
őstag
válasz
tierbatyo
#2517
üzenetére
most ez van:
LANG=hu_HU.utf8
LC_CTYPE=''hu_HU.utf8''
LC_NUMERIC=''hu_HU.utf8''
LC_TIME=''hu_HU.utf8''
LC_COLLATE=''hu_HU.utf8''
LC_MONETARY=''hu_HU.utf8''
LC_MESSAGES=''hu_HU.utf8''
LC_PAPER=''hu_HU.utf8''
LC_NAME=''hu_HU.utf8''
LC_ADDRESS=''hu_HU.utf8''
LC_TELEPHONE=''hu_HU.utf8''
LC_MEASUREMENT=''hu_HU.utf8''
LC_IDENTIFICATION=''hu_HU.utf8''
LC_ALL=hu_HU.utf8
de az mc még mindig szét van estve, nincs is benne ekezetes karakter. most újrafordítom az ncurses-t...
[Szerkesztve] -
-
Sipi
addikt
válasz
tierbatyo
#2451
üzenetére
Kár, hogy nVidia kártyám van, amivel nem megy a 7.1-es Xorg (pontosabban, az 1.1.1-es xorg-server). Vagyis megy, csak betűket nem jelenít meg, úgy pedig elég gázos.
Ezek szerint az AIGLX-hez semmit sem kell állítgatni, csak emerge compiz?
Ez ugye úgy megy, hogy az Xgl-t el sem indítod, hanem a rendes xorg-serverrel megy?
Ja, és mit kapsz az aiglx-szel? Milyen effektek? Hogyan lehet állítgatni?
Élménybeszámolót kérek!
Sipi -
Sipi
addikt
válasz
tierbatyo
#2392
üzenetére
Azt hiszem, már nincs domainname script. Csak hostname van, a domént két módon lehet megadni. Elvileg a resolv.conf-ba automatikusan bekerül a DHCP szerverről. Na, ezt soha a büdös életben semmilyen Linux alatt nem tudtam még használni, pedig minden leírás szerint ezt kellene.
A /etc/hosts fájlba lehet még beírni, a 127.0.0.1-es localhost cím után kell megadni gépnév.domén gépnév localhost alakban. Ekkor okés lesz.
Sipi -
Sipi
addikt
válasz
tierbatyo
#2238
üzenetére
Seamonkey: akkor valami rossz lehetett a gnome ebuildek egyikében. Illetve kettőben. Az egyiknek seamonkey, a másiknak mozilla kellhetett.
Nem semmi. Mondjuk ez nem a Gentoo hibája, hogy komplett roncsra akartátok feltenni.
Törlés: sosem volt még ilyenem... De ha ez a helyzet, pl. telepítőcédéről boot, hogy semmi ne legyen csatolva a vinyóról, és úgy fsck. Egyébként mi az, ami nem törölhető? (Ja, szerintem ez is inkább hardver-probléma lehet. Esetleg pont ott lett bad blokkos a vinyó.)
Sipi -
Sipi
addikt
válasz
tierbatyo
#2236
üzenetére
Ez mit takar pontosan? Ha leszeded a seamonkey-t, a mozillát, akkor is fel akarja rakni? Ha csak a mozillát rakod fel, akkor is fel akarja rakni?
Egyébként ilyenre jó a /etc/portage/profile/package.provided. Pontos verziót kell beírni, pl. www-client/seamonkey-1.0.2. Ekkor úgy veszi, hogy ez fel van rakva.
Esetleg maszkolhatod is, bár ha direkt függősége valaminek, akkor meg azzal lesz gond.
Az equery d seamonkey mit mond?
Sipi -
-
Sianis
addikt
válasz
tierbatyo
#1997
üzenetére
Azt hallottam, hogy amiatt, mert a biztonsági ellenőrzése komolyabb lett. Így most sok progit javítani kell, mert az új gcc sok mindent kidob...akkor váropk még vele egy kicsit.
Más: Hogyan tudnám az xorg-ot kivenni a world frissítésből? Ha jól tudom a oneshot ( 1 ) a megfelelő nem? Mert ezekre valahogy nem akar működni...mi lehet a gond?
Sianis -
escie
őstag
válasz
tierbatyo
#1951
üzenetére
emerge nvidia-glx nvidia-kernel
eselect opengl nvidia
aztán rossz esetben debug...
itt egy [link] a hivatalos doksira.
--
Sianis,
nézd meg ezt a [link]-et. a split-megoldást csak ajánlani tudom, mégha strapásabb is először feltenni.
így remek, pehelysúlyú kde-d lesz, a monolitikus megoldás sok olyat is feltesz, amire nem biztos, hogy szükséged van.
[Szerkesztve] -
Sipi
addikt
válasz
tierbatyo
#1904
üzenetére
Ez nekem is ilyen, az X ugyanis lényegében semmilyen lokált nem ismer. Unicode-ot pedig pláne. Ez nem gond, visszaáll defaultra. Az xterm nekem is elég őrülten néz ki, ez csak font-probléma. De ennek elég macerás megadni a fontkészletét, mert nem Type1/TTF-et használ. Ha tudsz, maradj a Gnome/KDE termináljánál. (Vagy keress howto-t, hogyan lehet Unicode-ossá tenni az xtermet.)
Sipi -
Sipi
addikt
válasz
tierbatyo
#1889
üzenetére
Akkor nekem valszeg azért, mert Unicode-os a gépem. Akkor tutira nem megy.
Most nem értem... Az előbb azt írtad, a source után az echo paranccsal kiírja a LINGUAS értékeit. Ha kiírja, akkor okés, a változó maga jó.
Mondom, az mplayer ebuildben el lett cseszve valahogy a LINGUAS detektálás. (Lehet, hogy itt is a Unicode kavar be.) Egyáltalán nem érzékeli. Totál rossz. Hiába adod meg jól, nem működik. Ja, itt ráadásul bekavar a LANG és LC_ALL is, eme három valamilyen katyvasza adja meg, mit tesz fel az mplayer. Én vért izzadtam, mire ki tudtam kapcsolni a hu támogatást, hiába töröltem mindenhonnan, mégis feltette.
Sipi -
Sipi
addikt
válasz
tierbatyo
#1887
üzenetére
Az ''egyébként'' nem tudom, mit jelent, de ha arra gondolsz, hogy simán echoval nincs értéke, az természetes. Elvégre sehol sem definiáltad. A make.conf csak az emerge során kerül feldolgozásra, így csak akkor lesz értéke. Ezért kell source-szal ''lefuttatni'' a make.conf-ot.
Ja, mplayer... Ott valami gebasz van az ebuildben. Elvileg tökéletes, végigkövettem, de nem működik. Anno kínomban kommenteztem minden sort benne, ami a nyelvet állította, és kézzel beírtam, mi kell. De egyébként a magyar felülete borzalmas, az ékezeteket nem írja ki rendesen, a magyar GUI pedig szétesik.
4.1: hm. Én most tettem fel 4.1-est, és ezzel újrahúztam mindkét Qt-t (3 és 4), plusz a kdelibs-t. Azóta nem sok minden megy, libkhtml.so-ban valami hiba van...
Sipi -
Sipi
addikt
válasz
tierbatyo
#1873
üzenetére
Akkor szerintem csinálj egy find/grepet erre a szóra a teljes env.d-n! Valszeg bennmaradt egy régebbi file-ban. A 02-nél nagyobbak felülírják, mert később hajtódnak végre.
Esetleg a .bash* file-okban lehet még valami.
A libstdc++ csak egy virtuális csomag, igen, a gcc előállítja. De a libstdc++-v3-ra szükség van, néhány programnak ez az ősrégi verzió kell.
Sipi -
Sipi
addikt
válasz
tierbatyo
#1858
üzenetére
Karakteres konzolban export LC_ALL=hu_HU.utf8, majd locale mit eredményez?
Egyébként ez az iso88592 nem is érvényes lokál... Nekem kettő van, fordításnál ISO-8859-2 és UTF-8 lett megadva. Ez azt eredményezi, hogy a ''sima'' lokál neve hu_HU, a Unicode-osé pedig hu_HU.utf8. Vagyis az iso8859-2-est nem teszi ki külön mellé.
Sipi
[Szerkesztve] -
Shadowfax
addikt
válasz
tierbatyo
#1851
üzenetére
Nekem nincs 02locale, ehelyett 99lang-ot használok:
LANG=''en_US''
LC_ALL=''hu_HU.utf8''
LINGUAS=''en hu''
rc.conf:
UNICODE=''yes''
EDITOR=''/bin/nano''
#EDITOR=''/usr/bin/vim''
#EDITOR=''/usr/bin/emacs''
#DISPLAYMANAGER=''xdm''
XSESSION=''Windows''
consolefont:
#CONSOLEFONT=''ter-v20b''
CONSOLEFONT=''default8x16''
#CONSOLETRANSLATION=''8859-1_to_uni''
keymaps:
KEYMAP=''us''
SET_WINDOWKEYS=''yes''
EXTENDED_KEYMAPS=''backspace keypad euro''
DUMPKEYS_CHARSET='''' -
-
Sipi
addikt
válasz
tierbatyo
#1845
üzenetére
A LANGUAGE változó tutira nem a lokál része, annak szerintem ''hu'' elég. Sőt, nem is tudom, létezik-e egyáltalán ilyen változó. A LINGUAS az, ami egyes programoknál megmondja, milyen nyelveket kell telepíteni, de annak is csak kétbetűs kód kell.
A ''locale -a'' mit ír ki? Szűrj a hu szóra. Lehet, hogy nem is létezik utf8-as lokálod.
Akkor vagy a glibc-t emergeled újra, és megadod helyesen, milyen userlocale kell (vagy hagyod a fenébe, és elkészítteted az összeset), vagy a localedef-fel csinálhatsz. Ezt nem tudom, hogyan kell használni, valamikor a neten találtam egy leírást.
Sipi -
Sipi
addikt
válasz
tierbatyo
#1605
üzenetére
Már nem mertem szólni, mert párszor leírtam, hogy modulban KELL használni... Illetve nem kell, de belefordítva rengeteg hiba adódhat, aminek látszólag nincs értelmes oka.
Sőt, én a kernel saját ALSA-ját sem preferálom. Az alsa-drivers csomag, ha frissül, késéssel kerül a kernelbe. Ráadásul kernelt annyira sűrűn nem cserél az ember - egyszerűbb az alsa-drivers csomagot fordítgatni.
Plusz, a Gentoo alsasound init scriptje is modulban várja el a drivereket.
Sipi -
Prozac
aktív tag
válasz
tierbatyo
#1578
üzenetére
Koszi, alakul....
De...
Amit a package.keywords-be irtam javaslatod alapjan az nem tetszik neki,
am a ACCEPT_KEYWORDS=''~x86'' a /etc/make.conf-ban megoldotta a nem stabilnak titulalt csomag letolteset.
Fel is ment, de ha pl. letoltom a magyar verziot, azt hogyan illesztem a rendszerbe, akar bin csomagbol, akar source-bol?
meg megyek majd olvasgatni...
[Szerkesztve] -
Sipi
addikt
válasz
tierbatyo
#1561
üzenetére
Kénytelen megnézni. Logikusan: attól, hogy nincs runlevelben, még előfordulhat, hogy egy másik szkriptnek szüksége van rá. Pl. hiába veszed ki a net scripteket, valamelyikre csak szükség lesz az ntpd indításához.
A teljes init dependency lánc feltérképezése miatt sikítozik.
Sipi -
Sipi
addikt
válasz
tierbatyo
#1556
üzenetére
A /etc/init.d-ben vannak az initszkriptek. Ezeket nem törli, hiszen a teljes /etc config protected.
Mindkét program =service) ugyanazt állítja elő: a firewallt. Töröld a file-t, vagy ha mindkettőt szeretnéd fenntartani a próba kedvéért, azt szoktam, hogy a szkriptben a provided-et az egyikben átírom pl. fw-re.
Sipi -
Sipi
addikt
válasz
tierbatyo
#1485
üzenetére
Ketten vagyunk.
S mint írtam, nem csak tűzfal. A Linux kernel szinte TELJES ipv4-es szolgáltatás-halmazát támogatja. Címfordítások, routing, túzfal egyben. Előnye, hogy a beprogramozott szabályokat ki is írja, így ha valaki nem ezt akarja használni, a kész iptables szabályokat elmentheti file-ba, és azzal kezeli, amivel akarja.
Pl. a ''beépített'' iptables szolgáltatással. Ha be vannak állítva a szabályok, iptables save, és rc-update iptables default. Ekkor csak az iptables file-jait használva indítja a tűzfalat, routert. Bár nem tudom, erre mi szükség, ha van egy firehol a gépen...
A weboldalán elég jó kiindulási doksik vannak, valamint van űpár alap konfig is telepítve, akár home network routernek is.
Sipi -
kerti008
aktív tag
válasz
tierbatyo
#1365
üzenetére
Hehe.. Mióta ír a Microsoft Open Source szoftwereket?
Kipróbáltam a nagy gépemen is a Gentoo-t. ezen nVidia kártya van megy is natívban a Q2, még hangja is van.
Van valami ötletetek miért nem indul a másik gépemen a KDE automatikusan?
csak a kde-base-t tettem fel meg a kde-base-meta-t. Az rc.conf-ban
DISPLAYMANAGER=''kdm''
XSESSION=''kde-3.4''
de nincs grafikus bejelentkezés és startx-el kell indítanom a kde-t? -
kerti008
aktív tag
válasz
tierbatyo
#1350
üzenetére
ez ATI-nak tűnik
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: ATI
client glx version string: 1.3
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_ATI_pixel_format_float,
GLX_ATI_render_texture
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
GLX_ARB_multisample
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: FireMV 2400 PCI DDR Generic
OpenGL version string: 1.3.1050 (X4.3.0-8.23.7)
OpenGL extensions:
GL_ARB_multitexture, GL_EXT_texture_env_add, GL_EXT_compiled_vertex_array,
GL_S3_s3tc, GL_ARB_occlusion_query, GL_ARB_point_parameters,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_transpose_matrix, GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_window_pos, GL_ATI_element_array,
GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_map_object_buffer,
GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once,
GL_ATI_vertex_array_object, GL_ATI_vertex_attrib_array_object,
GL_ATI_vertex_streams, GL_ATIX_texture_env_combine3,
GL_ATIX_texture_env_route, GL_ATIX_vertex_shader_output_point_size,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_stencil_wrap, GL_EXT_texgen_reflection, GL_EXT_texture3D,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_EXT_vertex_shader, GL_HP_occlusion_test, GL_NV_blend_square,
GL_NV_occlusion_query, GL_NV_texgen_reflection, GL_SGI_color_matrix,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow
0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow
0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow
0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow
0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None
0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None
0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None
0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None
0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow
0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow
0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow
0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow
0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None
0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None
0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None
0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None -
kerti008
aktív tag
válasz
tierbatyo
#1341
üzenetére
ALSA-OSS ? Háát úgy emlékszem ilyesmit szedtem le mielőtt elkezdtem kernelt fordítani. Több helyen javasolták a kernelben levő ALSA drivereket, mert stabilabb. De amikor kész lesz felrakom az alsa-oss-t. Már az is nagy szó hogy natívban elindult valami..... Nincs valami ötletetek mi baja lehet az egérnek? Mit kellene konfigurálnim? ''Failed to detect XF86DGA Mouse''
-
kerti008
aktív tag
válasz
tierbatyo
#1334
üzenetére
pesze a gyári ati volt fenn. De a Xorg.conf-ot a laptop specifikációi miatt, ki kellett tölteni. Videó kari belőve Száguld..
Most jön a hangkártya. Quake1-ről van szó és oss-t használna,
Sound Initialization
/dev/dsp: Input/output error
Could not mmap /dev/dsp
S_Startup: SNDDMA_Init failed.
Sound sampling rate: 11025 -
tierbatyo
senior tag
válasz
tierbatyo
#1272
üzenetére
Megoldva.
Nem ártott a kernelbe beleforgatni a támogatást. ;)
kerti008: Nekem ez van az xorg.conf-ban:
Section ''InputDevice''
Identifier ''Mouse2''
Driver ''mouse''
Option ''Protocol'' ''ImPS/2''
Option ''ZAxisMapping'' ''4 5''
Option ''Name'' ''Razer Diamondback Plasma''
Option ''Buttons'' ''7''
Option ''Device'' ''/dev/input/mice''
EndSection
A görgőhöz az imps/2 protocol kell, meg a ZAxismapping-os rész. -
Yom
aktív tag
válasz
tierbatyo
#1174
üzenetére
tx, mar csak 1 bajom van
a bill kiosztas. hiaba aliotttam be a xorg confot, meg mindig angol
xorg.confom:
Section ''InputDevice''
Identifier ''Keyboard0''
Driver ''kbd''
Option ''XkbLayout'' ''hu''
Option ''XkbVariant'' ''101_qwerty_dot_nodead''
EndSection
mod: hiba nem csak xgl-lel van! sima xorgban mukodik jol
[Szerkesztve]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
, talan XGL-el, de azt meg felejtsem inkabb el?:p
Új hozzászólás Aktív témák
- Milyen belső merevlemezt vegyek?
- Home server / házi szerver építése
- Pedzegeti az új Xbox irányát a Microsoft
- Projektor topic
- Automata kávégépek
- AI, GitHub Copilot, Claude, Gemini
- Honor Magic6 Pro - kör közepén számok
- Facebook és Messenger
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- EA Sports WRC '23
- További aktív témák...
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem.
- PC Game Pass előfizetés
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- AKCIÓ! Microsoft XBOX Series X 1TB SSD fekete játékkonzol extra fejhallgatóval garanciával
- 213 - Lenovo Legion 5 (15ACH6H) - AMD Ryzen 5 5600H, RTX 3060
- MacBook Pro 16" M1 Max 64GB / 2TB / 27%-os ÁFÁS
- Xiaomi 15T / 12/256GB / Kártyafüggetlen / 12Hó Garancia / Media Markt Gari 2028.02.02.-ig
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest