app-emulation/pearpc-0.3.0 released 13th August 2004. Reproducible: Always Steps to Reproduce: 1. 2. 3.
copied the 0.2.0 ebuild to 0.3.0 and compiled it by using local overlay. at the moment v 0.3.0 is running fine... maybe considering making this stable is an option?
We need sdl use flags now etc..
Yes, I'm working on it. I'm just waiting to hear from a pearpc developer, whether the Qt and GTK frontends are compatible with this release. It looks like they aren't, seeing as neither of them compile, and have a vastley different format than to the sdl/win32/x11 ones. Though I'd just like to make sure. As for marking it stable, that would never happen straight away. Generaly, a month has to pass with no bug reports before an ebuild can be made stable. Though in this case, i'll think twice about marking the ebuilds stable - considering pearpc is still in early stages of development.
In CVS without gtk/qt support. Though I'm leaving this bug open until I hear back from a pearpc dev about the gtk/qt situation.
Created attachment 39376 [details] pearpc-0.3.1.ebuild Ebuild for the new 0.3.1 release. I changed some stuff from the 0.3.0 ebuild, because I needed networking support in PearPC and without serval files beeing setuid I was not able as user to get the networking up and runing. The 0.3.0 relase did not have them setuid. The 0.3.0 seams even not to install two needed files (ifppc_up.setuid and ifppc_down.setuid) for networking. I don't know why the 0.3.0 ebuild does not install them. Anyway... the ebuild I am attaching is heavy used by me on i386 and PearPC works so far (I have MAC OS X 10.3.5 runing in PearPC).
Created attachment 39377 [details] pearpc-0.3.1.ebuild Ahggrrr!! I had a typo in the script on line 102. Instead of "{" I used "(". Sorry for that.
IMO, it's a /really/ bad idea to have the ebuild install a 3GB and a 6GB hard drive image. It's just not practical to expect people to have 9GB free on their drive just to install this one tiny app.
Oh yeah, I forgot to add that other than that your ebuild works great. :)
Hallo Graeme The day where I write a ebuild wich installs useless 9GB of data, is the day where I would quit computing ;) Look very close to the ammount of bytes used by the two COMPRESSED 3GB and 6GB images: steveb@thinkpad images $ ls -la total 12 drwxr-xr-x 2 root root 16 Sep 13 00:07 . drwxr-xr-x 4 root root 24 Sep 13 00:07 .. -rw-r--r-- 1 root root 2289 Sep 13 00:07 pearpc-3gib.img.bz2 -rw-r--r-- 1 root root 4537 Sep 13 00:07 pearpc-6gib.img.bz2 steveb@thinkpad images $ If you ask me, then 6.8KB is nothing ;) If the end-user extracts the images, then she/he probably knows what they do. cheers Steve
Hmm... okay, I think the problem is that when I tried to emerge it, it got those compressed image files as sources for the ebuild, and then *uncompressed* them into /var/tmp/portage/pear*. Perhaps if we can prevent portage from automatically unpacking those files? I know it thinks its helping, but really... ;)
Created attachment 39556 [details] pearpc-0.3.1.ebuild Okay... I think this statements prevents the unpacking of the two disk images: src_unpack() { unpack ${P}.tar.bz2 } I added a dependency to "app-emulation/pearpc-cvs" since I have a ebuild to download PearPC from CVS and I don't want them both to be installed. I will post the cvs ebuild as well. cheers SteveB
Created attachment 39557 [details] pearpc-cvs-0.0.1.ebuild This is the CVS ebuild I use. cheers SteveB
eradicator already submited the 0.3.1 ebuild (thanks for telling me...), but he obviously hadn't see this bug. ifppc_up/down.setuid are now included, along with the createdisk.py script. No need for the disk images, people can just use the script to create their own. and that cvs version... thats not going anyway near the tree ;)
Okay... I am not so "hot" about getting everything into the portage tree. The CVS version can stay in bugs.gentoo.org. If some one needs it, then she/he will find it. cheers SteveB
