here is my ebuild for http://free-doko.sf.net Reproducible: Always Steps to Reproduce:
Created attachment 73516 [details] free-doko-0.7.1.ebuild
Created attachment 79383 [details] free-doko-0.7.2b.ebuild This is the a ebuild to the newest version of freedoko. I added the USE-Flags "xskat" and "kdecards" that installs the corresponding cardthemes. I skipped the theme pysol for this time, because the theme is really big.
Created attachment 79456 [details] free-doko-0.7.2b-r1.ebuild Here I submit the ebuild as I like it and it gives several keywords: "xskat" installs the xskat cardset "kdecards" installs the kdecards cardset "noaltenburg" removes the non-free cardset Altenburg from the build. The ebuild gives an ewarn if noaltenburg is not set, that it is not compatible with the GPL and gives the chance to change your mind. If "noaltenburg" is used the ebuild requires to set xskat or kdecards otherwise it exits with a warning. It would be great to see free-doko in the official portage tree. A feedback would be great.
Created attachment 79505 [details] free-doko-0.7.2b-r2 Added License info if noaltenburg is not used to fullfill the license agreement with the Altenburg Spielkarten GmbH.
Created attachment 80028 [details] free-doko-0.7.2b-r3.ebuild -changed Source-URI to download only used cardsets. -added pysol cardset to the USE Flags
Created attachment 80399 [details] freedoko-0.7.2b.ebuild here's a (mostly) untested ebuild ... you can use it to see what things need to be done differently in your ebuild one thing i did notice is that the build system ignores CXXFLAGS for the most part so that'll need to be fixed ...
I don't understand this rewrite: if use xskatcards || use kdecards || use pysolcards ; then use altenburgcards || rm -r Altenburg fi Is the pipe || a check for any of this use flags? I will patch the Makefiles for the objects to use CXXFLAGS.
That's not a pipe, it's a logical or.
Ah, great, yes this is a fine method. Thank you all for training me :)
comments: needs to depend (but probably not rdepend) on unzip probably needs to rdepend on the libraries should use insinto/doins in src_install instead of cp it's bad form to have the executable installed in the data directory. The source should be patched to avoid that.
Here is the new ebuild. The CXXFLAGS have been masked in the Makefile. I inserted a patch that unhides it to avoid possible confusion :) Another patch rewrites the Makefile for the cardsets to include all cardsets. This is needed with the new src_unpack Spanky suggested. Currently I did not find out how to avoid putting the binary FreeDoko into the datadir. FreeDoko expects all cardsets and rulesets in his own path. I will inform the Developers of Freedoko to help here. I can see that my first ebuilds were not so good. Now I think it is better
Created attachment 80539 [details] free-doko-0.7.2b-r4.ebuild
Created attachment 80540 [details, diff] Fix_Cardset_Make.patch
Created attachment 80541 [details, diff] portage-cxx.patch
Created attachment 80545 [details] freedoko-0.7.2b-r4.ebuild Sorry, uploaded the wrong file. This one is correct, using doicon.
Comment on attachment 80545 [details] freedoko-0.7.2b-r4.ebuild renamed to freedoko
Created attachment 80613 [details] freedoko-0.7.2b-r4.ebuild Added forced cardset and corrected the check of USE-Flags
comments: put rdepend above depend and just use it in depend instead of specifying it twice don't quote for the S= assignment indent the function contents properly (see the rest of the games ebuilds) probably no reason to strip-flags no reason to cd ${S} (twice!) in src_compile or src_install error check doins in src_install source still needs to be patched so the executable looks in the data directory for the data files.
also... needs spaces near the parens in src_uri ditch the -r on the attachment names. that's for rev bumps in portage. src_uri should be defined once
Created attachment 80652 [details] freedoko-0.7.2b.ebuild thank you for you comments. I could you review this ebuild? The binary-data-issue will need some time, sorry for this
Created attachment 80653 [details] freedoko-0.7.2b.ebuild
Created attachment 80723 [details] freedoko-0.7.2b.ebuild Changed ebuild: freedoko is now looking for GAMES_DATA_DIR and resides in /usr/games/bin All binaries are now there where they should. Cheers
Created attachment 92959 [details] freedoko-0.7.2b.ebuild added ~amd64 keyword
Created attachment 94072 [details] freedoko-0.7.3.ebuild New release added Added useflag net since networkgaming is now official available, still experimentell Added useflag doc and DEPEND tetex for creating the docs. Could it be possible to get freedoko into the official portage? I would maintain it. It is a little confusing that I get no feedback for this request :)
Created attachment 94073 [details, diff] Fix_Cardset_Make.patch
Created attachment 94074 [details, diff] portage-cxx.patch
Created attachment 94075 [details, diff] nodoc.patch
Created attachment 94076 [details, diff] nonet.patch
*** Bug 143702 has been marked as a duplicate of this bug. ***
The provided ebuilds do not work anymore since the archive format of the package on the mirrors is now .tgz and not .src.zip .
Oh no, sorry, forget my comment, that was crap. But for whatever reason a "ebuild freedoko-0.7.3.ebuild digest" does not find the package on the mirror.
I still can digest the ebuild. Some mirrors of sourceforge currently do not have the file present. The first hit in my mirrorlist was kent.dl.sourceforge.net
I have problems with the portage-cxx.patch: ibook ~ # emerge freedoko Calculating dependencies... done! >>> Emerging (1 of 1) games-board/freedoko-0.7.3 to / >>> Unpacking source... >>> Unpacking FreeDoko_0.7.3.src.zip to /var/tmp/portage/freedoko-0.7.3/work * Applying portage-cxx.patch ... * Failed Patch: portage-cxx.patch ! * ( /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/freedoko-0.7.3/temp/portage-cxx.patch-21458.out !!! ERROR: games-board/freedoko-0.7.3 failed. Call stack: ebuild.sh, line 1546: Called dyn_unpack ebuild.sh, line 708: Called src_unpack freedoko-0.7.3.ebuild, line 31: Called epatch '/usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch' eutils.eclass, line 341: Called die !!! Failed Patch: portage-cxx.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/portage/local/private' /var/tmp/portage/freedoko-0.7.3/temp/portage-cxx.patch-21458.out: ***** portage-cxx.patch ***** ============================= PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ============================= patching file src/Makefile.rules Hunk #1 FAILED at 5. 1 out of 1 hunk FAILED -- saving rejects to file src/Makefile.rules.rej ============================= PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ============================= can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 |+++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored ============================= PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ============================= missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 |+++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored ============================= PATCH COMMAND: patch -p3 -g0 -E --no-backup-if-mismatch < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ============================= missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 |+++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored ============================= PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch ============================= missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 |+++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored
The Freedoko sources seems not to be extracted correctly. Could you have a look at /var/tmp/portage/freedoko-0.7.3/work/FreeDoko_0.7.3/src/Makefile and send it to me?
Created attachment 98670 [details] FreeDoko_0.7.3/src/Makefile here it is
I tried to applie the patch manually: If I am in the /var/tmp/portage/freedoko-0.7.3/work/FreeDoko_0.7.3 directory, the patch doesn't find the file to patch: ibook FreeDoko_0.7.3 # patch -p1 -g0 -E < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 |+++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200-------------------------- File to patch: This is the same error as in portage-cxx.patch-21458.out. If I went into the src subdirectory: ibook FreeDoko_0.7.3 # cd src ibook src # ls Doxyfile basistypes.cpp info.cpp FreeDoko.ico basistypes.h info.h FreeDoko.party_points c logo.xpm FreeDoko.png c.subdir misc Ideas card network Makefile class os Makefile.local commands.sh party Makefile.local.template compile.bat player Makefile.modules constants.cpp seed.out Makefile.objects constants.h text Makefile.os debug.cpp ui Makefile.rules debug.h utils Makefile.subdir exception.h utils.cpp POSTPHONED freedoko.cpp utils.h Remarks game ibook src # patch -p1 -g0 -E < /usr/portage/local/private/games-board/freedoko/files/portage-cxx.patch patching file Makefile.rules Hunk #1 FAILED at 5. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rules.rej ibook src # cat Makefile.rules.rej *************** *** 5,12 **** $(DEPTH)/Makefile.os # Gentoo users do want to see the real compile line. # So remove the next line and remove the '@' in the line after. - @echo $(CXX) -c $< - @$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $< -include $(OBJECTS:.o=.d) --- 5,11 ---- $(DEPTH)/Makefile.os # Gentoo users do want to see the real compile line. # So remove the next line and remove the '@' in the line after. + $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $< -include $(OBJECTS:.o=.d)
ok, the problem is the downloades patchfile from this bug. The resulting download shows control-markups and the file is a DOS-compliant textfile after downloaded: --- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 +++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 @@ -5,8 +5,7 @@ $(DEPTH)/Makefile.os^M # Gentoo users do want to see the real compile line.^M # So remove the next line and remove the '@' in the line after.^M - @echo $(CXX) -c $<^M - @$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $<^M + $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $<^M ^M -include $(OBJECTS:.o=.d)^M ^M I can reproduce your last error with the downloaded patchfile. A dos2unix portage-cxx.patch fixes this. I don
ok, the problem is the downloades patchfile from this bug. The resulting download shows control-markups and the file is a DOS-compliant textfile after downloaded: --- src/Makefile.rules.orig 2006-07-27 10:22:28.000000000 +0200 +++ src/Makefile.rules 2006-07-28 17:17:46.744884888 +0200 @@ -5,8 +5,7 @@ $(DEPTH)/Makefile.os^M # Gentoo users do want to see the real compile line.^M # So remove the next line and remove the '@' in the line after.^M - @echo $(CXX) -c $<^M - @$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $<^M + $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDE) $(DEPGEN_FLAGS) -o $@ -c $<^M ^M -include $(OBJECTS:.o=.d)^M ^M I can reproduce your last error with the downloaded patchfile. A dos2unix portage-cxx.patch fixes this. I don´t know why the Bugzilla downloads are converted to DOS-files. I will upload a binary gz which includes all files also.
Created attachment 98710 [details] freedoko-0.7.3-ebuild.tar.gz added binary file. This file can be found at http://free-doko.sourceforge.net/en/files.html also
Thank you, I tried to find out the error by myself but I never thought of this. :) I emerged freedoko successfully now with the following settings: [ebuild N ] games-board/freedoko-0.7.3 USE="net pysolcards -altenburgcards -doc -kdecards -xskatcards" 0 kB [1] The game itself works fine on my PPC, so please add this keyword.
I use now the altenburgcards and this works also very well (the altenburgcards contains only one set of cards, but it is a german set (with a B, D, K and not J, Q, K) and the english one confused me. :) The game itself works very stable till now (played a few rounds) and has very much options (Doppelkopf is a very complex game with many variations (look at Wikipedia), but you have the ability to specifiy most of them) and the AI seems to be good (but I haven't played Doppelkopf for a long time, so I am not the best player).
It works with the same settings also fine on my AMD64.
OK. Exactly what of the attachments above to I need anymore? Just the tarball?
@Chris: Yes, you only need the tarball, that's enough. After trying, please report your success here. The only problem I had was the rare available source code, but after a few 404, he found it.
Created attachment 98861 [details] freedoko-0.7.3-ebuild.tar.gz added ~ppc keyword
Created attachment 98862 [details] freedoko-0.7.3.ebuild added ~ppc keyword
(In reply to comment #40) > I use now the altenburgcards and this works also very well (the altenburgcards > contains only one set of cards, but it is a german set (with a B, D, K and not > J, Q, K) and the english one confused me. :) It is the famost cardset distributed by Altenburg GmbH. They have a german cardset also but I never saw anyone using it. Does anyone whish this cardset included?
> It is the famost cardset distributed by Altenburg GmbH. They have a german > cardset also but I never saw anyone using it. Does anyone whish this cardset > included? Do you mean an english cardset? Because I got only a german one and no english cardset. And that's enough for me, but perhaps there are non-germans out there who also wants to use it.
No, with german cardset I meant german "pictures" ( like this one http://www.spielkarten.com/Media/altenburger/_pictures/products/handel_01tradit/4/doppelkopf1.jpg ) The french pictures are the most popular in Germany, I don
No, with german cardset I meant german "pictures" ( like this one http://www.spielkarten.com/Media/altenburger/_pictures/products/handel_01tradit/4/doppelkopf1.jpg ) The french pictures are the most popular in Germany, I don´t know if there are equivalents in other countries. Altenburg does not produce english cards as I know but I will asked for it.
Ah OK, I confounded this. Me, I would not use the german cardset, but it would be nice to have the possibility to choose it. Perhaps you could make an seperate altenburgcards ebuild and select the wanted included cardsets by USE-flags like 'englishcards', 'germancards' or 'frenchcards'.
I found the source of the formating problem with the file src/Makefile.rules The original source contains the dos formating and any patch created will and have include them. I informed the developers of Freedoko about this, they should fix this. Until this happened I will alter the ebuild to convert the Makefile.rules to Unix and updated the patch.
Created attachment 98877 [details] freedoko-0.7.3.ebuild.tar.gz fixed dos formating
Created attachment 98878 [details, diff] portage-cxx.patch fixed dos formating
@Chris, if you would like to have a look at the ebuild choose the file: freedoko-0.7.3.ebuild.tar.gz it includes the ebuild, all patches and Changelog. For further uploads I will update the tar archives only Cheers
Added to CVS (slightly modified)
