The wine-doors project has its first release. It is "Wine-doors 0.1 pre-release 1". See also #167431
Created attachment 120309 [details] winedoors-0.1_pre1 ebuild I made an ebuild for it, haven't tested it though because I don't have gnome installed, it made an image (ebuild winedoors-0.1_pre1.ebuild digest) so it should work
*I meant ebuild ... install, not digest, silly me
Created attachment 120313 [details] winedoors-0.1_pre1 ebuild fixed install paths
It doesn't work for me. I get a sandbox violation. # emerge -v winedoors These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-emulation/winedoors-0.1_pre1 0 kB [1] Total: 1 package (1 new), Size of downloads: 0 kB Portage overlays: [1] /usr/local/portage >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/winedoors-0.1_pre1 to / * wine-doors-0.1pre1.tar.gz MD5 ;-) ... [ ok ] * wine-doors-0.1pre1.tar.gz RMD160 ;-) ... [ ok ] * wine-doors-0.1pre1.tar.gz SHA1 ;-) ... [ ok ] * wine-doors-0.1pre1.tar.gz SHA256 ;-) ... [ ok ] * wine-doors-0.1pre1.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking wine-doors-0.1pre1.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking wine-doors-0.1pre1.tar.gz to /var/tmp/portage/app-emulation/winedoors-0.1_pre1/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-emulation/winedoors-0.1_pre1 ... >>> Source compiled. >>> Test phase [not enabled]: app-emulation/winedoors-0.1_pre1 >>> Install winedoors-0.1_pre1 into /var/tmp/portage/app-emulation/winedoors-0.1_pre1/image/ category app-emulation ACCESS DENIED mkdir: /etc/wine-doors Performing system install with parameters: / / Traceback (most recent call last): File "/var/tmp/portage/app-emulation/winedoors-0.1_pre1/work/wine-doors-0.1pre1/setup.py", line 119, in ? os.makedirs( prefix_conf ) File "/usr/lib/python2.4/os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '//etc/wine-doors/' >>> Completed installing winedoors-0.1_pre1 into /var/tmp/portage/app-emulation/winedoors-0.1_pre1/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-app-emulation_-_winedoors-0.1_pre1-22950.log" mkdir: /etc/wine-doors (symlink to /etc/) -------------------------------------------------------------------------------- !!! This ebuild is from an overlay: '/usr/local/portage'
Apparently the install paths still needs a little clean-up -> //etc/wine-doors/
Created attachment 120330 [details] winedoors-0.1_pre1 ebuild fixed install paths again, should work now
These three symlinks are wrong. We're missing a / Snipped output from "equery files winedoors": /usr/share/pixmaps/wine-doors.png -> usr/share/wine-doors/pixmaps/wine-doors.png /usr/share/pixmaps/wine-doors.svg -> usr/share/wine-doors/pixmaps/wine-doors.svg /usr/bin/wine-doors -> usr/share/wine-doors/src/winedoors.py
Created attachment 120350 [details] Errors from first run of WineDoors When running WineDoors first time, it fails on /tmp/System Base.xml
Created attachment 120351 [details] Errors from subsequent runs of WineDoors when trying to run WineDoors again (after the first failed run) WineDoors flunks on malformed XML.
I know what it is now in regard to subsequent failures. I get a xml.sax._exceptions.SAXParseException because of an ampersand sign in the Company Name. It also doesn't like special Danish characters like ÆØÅ (that's weird in these utf8-days). Replacing the ampersand with the letter combination "og" (meaning "and") and replacing Danish characters with "ae", "oe" and "aa" results in the first-run failure to happen on all runs.
try and run winecfg, then run winedoors, that could fix your problems, as for the symlink problems, I have no idea, I only made the ebuild. it looks like something wrong with the setup script
Created attachment 121358 [details] wine-doors-0.1_pre1.ebuild Tidied ebuild. Made compatible with distutils eclass. Renamed to wine-doors, to match upstream.
Comment on attachment 121358 [details] wine-doors-0.1_pre1.ebuild However, this app seems currently TOO BUGGY to use, as mentioned above, so I'm marking the ebuild as "obsolete" immediately, to hopefully stop people from grabbing it and then moaning that it doesn't work ;)
wine-doors-0.1 was released, anyone feeling like taking it on? http://www.wine-doors.org/wordpress/?page_id=3 It would be really appreciated!
An ebuild for 0.1 may be found at the sabayonlinux overlay : http://svn.sabayonlinux.org/overlay/app-emulation/wine-doors/ However, I didn`t try it.
The sabayon ebuild and wine-doors 0.1 both seem to work well for me on amd64.
Wine-doors-0.1 is out: http://www.wine-doors.org/releases/wine-doors-0.1.tar.gz
Created attachment 124322 [details] Wine-doors-0.1 This is the ebuild from Sabayon. I have only changed the copyright header, works well here.
While ruby-rsvg has only 3 dependancies, gnome-python-desktop (which wine doors need just for python-rsvg, listening his creators) is trying to pull in 69 gnome packages (plus librsvg), really bad.... So someone here might want to check http://gentoo-xeffects.org/forums/viewtopic.php?f=15&t=424&p=1508&hilit= for a better ebuild
"dev-util/glade-2.12.1 does not actually support the python USE flag!" for fix this problem emerge =dev-util/glade-3.2.0 or correct ebuild : DEPEND=" >=dev-lang/python-2.4.0 >=dev-python/pycairo-1.2.0 >=x11-libs/cairo-1.2.0 >=dev-python/gnome-python-desktop-2.16.0 app-arch/cabextract app-arch/unzip app-arch/zip app-arch/gzip app-arch/bzip2 app-arch/tar >=dev-util/glade-3.2.0 dev-libs/libxml2 app-pda/orange "
Created attachment 129861 [details] wine-doors-0.1.ebuild Added wine and glade version dependency. SRC_URI cleaned.
(In reply to comment #21) > Created an attachment (id=129861) [edit] > wine-doors-0.1.ebuild > > Added wine and glade version dependency. SRC_URI cleaned. > why don't you submit your ebuild to sunrise overlay?
0.1.1 is out. And sunrise idea is nice I think.
(In reply to comment #23) > 0.1.1 is out. And sunrise idea is nice I think. > It isn't out, but it will be out soon, wine-doors devs only shown in their homepage what they've done with under-development 0.1.1 , if you go on downloads you will only see 0.1 for now
I have account in Sunrise overlay but I'm very busy because my exams. I'll try to submit ebuild in the next week.
during the initial setup of wine-dors that i ran in console the gui stoped working but in console i can see the progress specialy when i minimise it and click it on the task bar to make it reapear
0.1.1 stable is out
(In reply to comment #27) > 0.1.1 stable is out > yes but without networkmanager doesn't even start. I read in wine-doors ml that next versions should work also without nm
0.1.2 stable is out , renaming the attached ebuild doesn't work with 0.1.2.
Created attachment 141748 [details] wine-doors-0.1.2.ebuild This is a working wine-doors-0.1.2 tested on ~amd64 Does not require networkmanager. Please see the notice at the end of ebuild regarding changes from previous versions. If you get an error stating "System Base.xml" not found, you need to delete ~/.wine/wine-doors/preferences.xml
(In reply to comment #30) > Created an attachment (id=141748) [edit] > wine-doors-0.1.2.ebuild > > This is a working wine-doors-0.1.2 tested on ~amd64 Does not require > networkmanager. Please see the notice at the end of ebuild regarding changes > from previous versions. If you get an error stating "System Base.xml" not > found, you need to delete ~/.wine/wine-doors/preferences.xml > it works also on x86, after removing .wine/wine-doors/preferences.xml. It should be a good Idea to commit this ebuild on sunrise overlay.
Created attachment 142439 [details, diff] patch to kill rsvg I'm attaching a patch which kills import of 'rsvg' (to avoid gnome-python-desktop dep) and the two methods which used it. Wine-doors seem to start up fine, however I've tested it only briefly, so I don't know whether this rude intervention will make it crash at some point or not.
it doesn't look like a "real" patch, just code removal...
>>> Downloading 'http://www.wine-doors.org/releases/wine-doors-0.1.2.tar.gz' --2008-02-17 22:08:55-- http://www.wine-doors.org/releases/wine-doors-0.1.2.tar.gz Resolving www.wine-doors.org... 67.207.139.203 Connecting to www.wine-doors.org|67.207.139.203|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2008-02-17 22:08:55 ERROR 404: Not Found. !!! Couldn't download 'wine-doors-0.1.2.tar.gz'. Aborting. !!! File wine-doors-0.1.2.tar.gz doesn't exist, can't update Manifest
(In reply to comment #34) > >>> Downloading 'http://www.wine-doors.org/releases/wine-doors-0.1.2.tar.gz' > --2008-02-17 22:08:55-- > http://www.wine-doors.org/releases/wine-doors-0.1.2.tar.gz > Resolving www.wine-doors.org... 67.207.139.203 > Connecting to www.wine-doors.org|67.207.139.203|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 2008-02-17 22:08:55 ERROR 404: Not Found. > > !!! Couldn't download 'wine-doors-0.1.2.tar.gz'. Aborting. > !!! File wine-doors-0.1.2.tar.gz doesn't exist, can't update Manifest > the wine-doors site has switched server yesterday, so they had some problems, anyway the file can be downloaded again now.
*** Bug 167431 has been marked as a duplicate of this bug. ***
I think the correct dependencies are: RDEPEND=" >=dev-lang/python-2.4.0 >=dev-python/pycairo-1.2.0 >=x11-libs/cairo-1.2.0 app-arch/cabextract app-arch/unzip app-arch/zip app-arch/gzip app-arch/bzip2 app-arch/tar dev-libs/libxml2 app-emulation/wine dev-python/librsvg-python " I was wondering why I suddenly needed so many gstreamer plugins and cut down the dependencies to what wine-doors really needs. WOrks for me ...
*** Bug 245666 has been marked as a duplicate of this bug. ***
Created attachment 183227 [details] wine-doors-0.1.3_rc1.ebuild modified 0.1.2 ebuild to work with 0.1.3-rc1 (reccomended upstream version)
(In reply to comment #39) > Created an attachment (id=183227) [edit] > wine-doors-0.1.3_rc1 > > modified 0.1.2 ebuild to work with 0.1.3-rc1 (reccomended upstream version) > I modified src_unpack since the file provided by upstream has a strange extension : tar_.gz , so I have to gunzip, then move the .tar_ file to a .tar and then extract again.
Created attachment 183294 [details] wine-doors-0.1.3.ebuild The src_uri hack is not needed when you download from http://www.wine-doors.org/releases/ Note: I try to maintain this ebuild at http://github.com/ibor/overlay
Comment on attachment 183227 [details] wine-doors-0.1.3_rc1.ebuild obsolete ebuild since Ingo ebuild is up-to-date and has a correct SRC_URI
looks fine any chance to have it in portage?
Added the 0.1.3 ebuild with some changes.
Hi all, good work with wine-doors, but it also depends on app-arch/unzip, or it will give this error: * ERROR: app-emulation/wine-doors-0.1.3 failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 2424: Called distutils_src_install '--temp=/var/tmp/portage/app-emulation/wine-doors-0.1.3/image/' * environment, line 676: Called die * The specific snippet of code: * ${python} setup.py install --root="${D}" --no-compile "$@" || die "python setup.py install failed"; * The die message: * python setup.py install failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/app-emulation:wine-doors-0.1.3:20090321-121306.log'. * The ebuild environment file is located at '/var/tmp/portage/app-emulation/wine-doors-0.1.3/temp/environment'.
It also need dev-python/gconf-python. Without this one wine-doors installs but does not start, giving this error: Started logging session Traceback (most recent call last): File "/usr/bin/wine-doors", line 21, in <module> from wine import wine File "/usr/share/wine-doors/src/wine.py", line 14, in <module> from utils import GetCDMountPoint, getwinecoloursfromgtk, GetXkbmap File "/usr/share/wine-doors/src/utils.py", line 11, in <module> import gconf ImportError: No module named gconf
Can anyone tell me what the point of wine-doors is? It does nothing. It just starts, lets you configure something, and barfs on a missing xml file. Then there is nothing else to do with it. I don't think there actually is a package list to use with it, nor could you actually manage packages with it. Also sound is not configurable. How about putting this package is, when there actually is a point to it? ^^
There is already a reported bug about that problem: http://bugs.gentoo.org/show_bug.cgi?id=277491 then, please, don't pollute other bugs, as I already get a lot of mails :-) Thanks a lot
