Archiv verlassen und diese Seite im Standarddesign anzeigen : [gentoo] mutige winex tester gesucht.
Es geht um das neue winex2.1.
Ich habe das ganze Wochenende damit zugebracht, unser winex auf den neuesten Stand zu bringen. Das ebuild ist fertig, es braucht aber noch einige Tests um moegliche Bugs zu eliminieren. Falls ihr mutig genug seid mein neues winex auszuprobieren, so tut bitte folgendes:
==INSTALLATION==
emerge rsync
nano /usr/portage/profiles/package.mask
sucht nach der Zeile "=app-emulation/winex-20020804" und kommentiert sie aus oder loescht sie. danach koennt ihr winex einfach mit
emerge winex
mergen.
==KONFIGURATION==
Das macht mein wrapper-script alleine:
winex
legt euch ein neues ~/.winex an. Alles was ihr noch tun muesst ist, die Sektionen [Drive D] und [Drive E] an euer System anzupassen.
==ANWENDUNG==
Wieder der wrapper-script:
winex foo.exe
sollte eure Programme starten. Falls das Programm nicht startet (oder gleich wieder an die CLI zurueckfaellt) editiert /usr/bin/winex und ersetzt "--debugmsg -all" mit "--debugmsg +warn" - dann habt ihr wieder die Warnmeldungen.
Falls ihr reg-dateien importieren wollt so benuetzt dafuer "regedit foo.reg" (Auch ein wrapper-script von mir)
Also viel Spass beim Testen - und ich hoffe das wir viele Fehler finden und beheben.
-phoen][x-
Das muss ich heute Abend gleich mal ausprobieren!
Gibt es eigentlich schon ein Ebuild für die Binary-Pakete von WineX? Aus Zeiten RPM-basierter Distributionen bin ich Abonnent von WineX und würde somit natürlich auch gerne die aktuellste Version nutzen, schliesslich zahle ich 5$ jeden Monat dafür...
Die kannst du doch auch mit "rpm -i" installieren, oder nicht? Ein ebuild waere schwierig, dann muesste sich der User ja erst authen. :/
-phoen][x-
Wie sicher ist denn die RPM-Integration? Nach drei Jahren mit DLD, Redhat und SuSE traue ich dem RPM-Format nichtmehr sonderlich viel...
Werden Abhängigkeiten transparent vom Portage zum RPM durchgegeben oder geht das dann nur mit --nodeps?
Und merken evtl. von WineX abhängige Ports, dass WineX per RPM installiert ist?
Kannste vergessen. RPM ist rpm. Und portage ist portage. Es gab mal eine Idee, portage rmp-pakete bauen zu lassen und diese dann mit rpm -i zu installieren; dann waeren die DEPS da. Aber ich glaub dass da nichts draus geworden ist (Ist auch zuviel Aufwand imo). Du kannst die winex.rpm's ja immer noch mit --nodeps installieren und dann mit "emerge inject" in die portage paket-db einpflegen. Ist aber eigentlich auch Unsinn.
Btw, was DEPENDet schon auf winex? "qpkg -q winex" gibt nichts aus.
Ja ich weiss, es ist nicht schoen. Aber was soll man tun? Ernstgemeinte Vorschlaege zu mir. :)
-phoen][x-
Ich werd mich heut abend auch mal dran machen. Leider is mein Gentoo neulich beim installieren irgendwie gefreezed (temperatur wars denk ich) also muss ichs nochmal neu installieren. Aber wird schon gehen :)
SON!C
Okay.
Die meisten Probleme wird wahrscheinlich die ~/.winex/config verursachen. Wenn ihr irgendwelche Aenderungen vornehmt und danach eure Software funktioniert, postet ein diff ("diff -ru /usr/lib/winex/.data/config ~/.winex/config") damit ich die version im cvs updaten kann.
Auf jeden Fall vielen Dank fuer eure Hilfe.
-phoen][x-
genial einfach, einfach genial
danke für dein kleines winex Skript ... funktioniert einwandfrei
allerdings habe ich noch ein paar Vorschläge:
-) dga führt auf vielen systemen in Verbindung mit direct draw zu problemen, daher besser in der wine-config auf 'N' setzen
-) winex erstellt auf kde systemen automatisch die startmenü einträge im kde-menü, allerdings wird dort mit wine und nicht mit winex aufgerufen, daher das wrapper skript wine statt winex nennen, oder einen symlink wine anlegen
weiters würde ich es gut finden ein 'globales' fake windows in /opt/wine oder so anzulegen, wo windows software systemweit verfügbar installiert werden kann, das ganze mit rechten für eine group winex, naja zumindest hab ich das hier so...
soweit so gut, das ebuild läuft meiner Meinung nach soweit stabil es unzumasken
genial einfach, einfach genial
danke für dein kleines winex Skript ... funktioniert einwandfrei
Danke.
allerdings habe ich noch ein paar Vorschläge:
-) dga führt auf vielen systemen in Verbindung mit direct draw zu problemen, daher besser in der wine-config auf 'N' setzen
Kein Problem, aendere ich in der Default Config. Allerdings - wer hat schon dga aktiviert? Meine user duerfen zumindest nicht auf /dev/mem schreiben. Aber stimmt schon, es soll ja auch als Root funktionieren.
-) winex erstellt auf kde systemen automatisch die startmenü einträge im kde-menü, allerdings wird dort mit wine und nicht mit winex aufgerufen, daher das wrapper skript wine statt winex nennen, oder einen symlink wine anlegen
Nein das ist nicht moeglich - der wrapper heisst extra winex, damit man wine und winex gleichtzeitig installiert haben kann. Allerdings kann ich dass Makefile patchen, so dass der KDE-Link auf winex zeigt - waere das auch ok?
weiters würde ich es gut finden ein 'globales' fake windows in /opt/wine oder so anzulegen, wo windows software systemweit verfügbar installiert werden kann, das ganze mit rechten für eine group winex, naja zumindest hab ich das hier so...
Das muss ich erst mit den anderen devs absprechen. Aber ein globales fake_windows sollte nicht das Problem sein - das wird dann halt 664 und a+X chmodded und auf root.winex geowned und ich bau noch einen einfo in das ebuild ein: "To allow users the installation of new software under winex add them to group winex".
soweit so gut, das ebuild läuft meiner Meinung nach soweit stabil es unzumasken
Es sind noch diverse gcc/arch tests am laufen (i386,i586,k6,k6/3). Sobald die erfolgreich abgeschlossen sind, und niemand mehr etwas am ebuild auszusetzen hat wird es unmasked. Ich sag dann aber nochmal bescheid.
-phoen][x-
Nein das ist nicht moeglich - der wrapper heisst extra winex, damit man wine und winex gleichtzeitig installiert haben kann. Allerdings kann ich dass Makefile patchen, so dass der KDE-Link auf winex zeigt - waere das auch ok?
klar wäre das auch ok, du musst nur den Eintrag im Makefile finden und künftige Versionen auch patchen, schöner ist aber natürlich immer Programme unverändert zu übernehmen...
Das muss ich erst mit den anderen devs absprechen. Aber ein globales fake_windows sollte nicht das Problem sein - das wird dann halt 664 und a+X chmodded und auf root.winex geowned und ich bau noch einen einfo in das ebuild ein: "To allow users the installation of new software under winex add them to group winex".
Genau meine Idee :) Das einzige Problem ist, dass das wrapper-skript die Berechtigungen immer richtig setzten muss, damit nicht teile vom globalen FakeWin dann plötzlich der group users gehören...
Es sind noch diverse gcc/arch tests am laufen (i386,i586,k6,k6/3). Sobald die erfolgreich abgeschlossen sind, und niemand mehr etwas am ebuild auszusetzen hat wird es unmasked. Ich sag dann aber nochmal bescheid.
ausgiebig Testen schadet nie :)
Hi!
Habs auch getestet, läuft super!
Danke,
Okay, ich habe eine neue Version reingestellt - es gab doch einige Probleme mit der 20020804. Jetzt laeuft bei mir auch Starcraft (mit 2 fps oder so), vielleicht hilft es euch ja auch. Ein globales fake_windows habe ich noch nicht eingebaut, ich bin mir noch unschluessig.
Also, die neue Version unmasken (in /usr/portage/profiles/package.mask) und "emerge winex" - das sollte dann winex-20020807 sein.
Laters,
-phoen][x-
das Problem, dass StarCraft (und auch andere DirectDraw Programme) unheimlich langsam unter Wine laufen, habe ich bisher bei jeder Version von Wine und WineX gehabt, ich glaube nicht, dass das auf das Skript oder ebuild zurückzuführen ist, sondern einfach auf die schlecht DirectDraw Unterstützung von Wine ....
übrigens: Starcraft hat bei mir auf beiden Rechnern auch mit der 04.08.er Version funktioniert
Bei mir hat starcraft mit 20020804 nur funktioniert, wenn ich die Spiele Platte als floppy definiert habe - ansonsten kam sofort beim Starten "error=21" und aus.
Das funktioniert jetzt einwandfrei.
Ausserdem sollten jetzt Movies unter war3 moeglich sein - und ich werde bei Gelegenheit auf jedenfall noch NWN antesten: Einige Tester hatten merkwuerdige Probleme, dass das NWN setup haengenblieb.
Mal schaun, vielleicht ist die neue Version ja wirklich besser.
-phoen][x-
ich kann machen was ich will.. immer wenn direct3d starten soll bekomme ich die selbe exception..
hier ist ein auszug aus der xf86config..:
Section "Module"
Load "xie"
Load "pex5"
Load "GLcore"
Load "glx"
Load "dri"
Load "dbe"
Load "record"
Load "extmod"
Load "type1"
Load "freetype"
EndSection
Section "DRI"
Mode 0666
EndSection
Section "Device"
Identifier "Card0"
Driver "radeon"
Option "AGPMode" "4"
EndSection
und hier welche aus der winex config..
[DllOverrides]
"commdlg" = "builtin, native"
"comdlg32" = "builtin, native"
"ver" = "builtin, native"
"version" = "builtin, native"
"shell" = "builtin, native"
"shell32" = "builtin, native"
"shfolder" = "builtin, native"
"shlwapi" = "builtin, native"
"shdocvw" = "builtin, native"
"lzexpand" = "builtin, native"
"lz32" = "builtin, native"
"comctl32" = "builtin, native"
"commctrl" = "builtin, native"
"advapi32" = "builtin, native"
"crtdll" = "builtin, native"
"mpr" = "builtin, native"
"winspool.drv" = "builtin, native"
"ddraw" = "builtin, native"
"dinput" = "builtin, native"
"dsound" = "builtin, native"
"opengl32" = "builtin, native"
"msvcrt" = "native, builtin"
"rpcrt4" = "native, builtin"
"msvideo" = "builtin, native"
"msvfw32" = "builtin, native"
"mcicda.drv" = "builtin, native"
"mciseq.drv" = "builtin, native"
"mciwave.drv" = "builtin, native"
"mciavi.drv" = "native, builtin"
"mcianim.drv" = "native, builtin"
"msacm.drv" = "builtin, native"
"msacm" = "builtin, native"
"msacm32" = "builtin, native"
"midimap.drv" = "builtin, native"
"*" = "native, builtin, so"
[x11drv]
"AllocSystemColors" = "100"
"PrivateColorMap" = "N"
"PerfectGraphics" = "N"
"Managed" = "Y"
"UseDGA" = "Y"
"UseXShm" = "Y"
"UseXVidMode" = "N"
"DXGrab" = "Y"
"DesktopDoubleBuffered" = "Y"
"TextCP" = "850"
ob ich den dcom98 kram installiere oder an den dlls schraube ist egal..
opengl geht 1a.
benutze gentoo 1.2 mit linux 2.4.18 nein 2.4.19 ist nur unstable bei mir auch von kernel.org....
ergo kann ich kein gta3 spielen was ich mir eigentlich heute kaufen wollte und diablo2 läuft mit 20fps vor sich hin.. da kein d3d..
und nein ich hatte eigentlich nicht vor wine/x als root zu starten..
habe nen p3/coppermine/800 mit radeon 7200 und 512 mb sdr-pc133-2-2-2 ram..
es ist auch total egal ob ich dga/shm etc einschalte oder ausschalte.. aber Stronghold rennt gut... ^
hier eine Fehlermeldung von gta3
err:win32:_EnterSysLevel (0x40834fb8, level 2): Holding 0x408cc9a4, level 3. Expect deadlock!
radeonUpdatePageFlipping allow 0 current 0
err:win32:_EnterSysLevel (0x40834fb8, level 2): Holding 0x408cc9a4, level 3. Expect deadlock!
radeonUpdatePageFlipping allow 0 current 0
err:file:GetOverlappedResult lpOverlapped->hEvent was null
wine: Unhandled exception, starting debugger...
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x40275e5a
hier noch mal glxinfo..
name of display: :0.0
radeonUpdatePageFlipping allow 0 current 0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 4x x86/MMX/SSE TCL
OpenGL version string: 1.2 Mesa 4.0.3
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array,
GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_texture3D,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array,
GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection,
GL_SGI_color_matrix, GL_SGI_color_table
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 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None
0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.