Some wit has messed up nuppelvideo-0.52a by adding crap to the Makefile: V4LDIR=/usr/src/linux/drivers/char/ COPTS=$(CFLAGS) -I$(V4LDIR) COPTSRT= -O3 -Wall -DMMX -mcpu=pentium -funroll-loops -fexpensive-optimizations -finline-functions -- snap - there is a lot more... -- I'm not quite sure which of those "very important optimizations" kept my gcc from compiling this (for an AthlonXP cpu btw.) so I just removed them all except for "-finline-functions" - works. I assume that everyone has heard about funroll-loops, however for those who have not: http://funroll-loops.org/ I wonder how this could get into portage. No digest verification errors or whatever. And to make things even worse: The author's website appears to be down, so I couldn't contact him.
Well, the sed in ebuild has not much effect, the rice is scattered all over the makefile. Also, X11R6 should go away from -L.
This junk doesn't compile w/ >=gcc-4 at all. <snip> /var/tmp/portage/nuppelvideo-0.52a/temp/cclw1raH.s:3363: Error: suffix or operands invalid for `movq' /var/tmp/portage/nuppelvideo-0.52a/temp/cclw1raH.s:4943: Error: suffix or operands invalid for `movq' </snip> Upstream dead, doesn't compile, makefile all screwed - please, remove this from portage.
No wait, don't remove it. It compiled sucessfully with gcc 4.1.1 (after fixing the Makefile). Besides it's a nice program.
Well, it's none of the ricer flags, it's stupid -DMMX that makes it bomb out.
Created attachment 95205 [details, diff] files/Makefile.patch - nuke -DMMX - nuke hardcoded CC - fix make install
Created attachment 95206 [details] nuppelvideo-0.52a.ebuild - make the thing respect CFLAGS and CC - quoting - nuke useless pkg_postinst(), the homepage is dead - use emake install
Created attachment 95208 [details] nuppelvideo-0.52a.ebuild - also add missing dependencies
Created attachment 95259 [details] Ebuild after repackaging I applied the patches, got the files mentioned in the old postinstall function from the wayback machine and re-packaged it. Please check if I got it right.
Sorry, please wait - just noticed a problem.
Created attachment 95260 [details] Second try Sorry, this one seems to work for me.
Heh, yeah repackaging the thing seems like saner solution. Looks good, just needs to set RDEPED="${DEPEND}" explicitely, otherwise it will get RDEPEND wrong due to inherited eclasses. Thanks.
(In reply to comment #11) > Heh, yeah repackaging the thing seems like saner solution. > > Looks good, just needs to set RDEPED="${DEPEND}" explicitely, otherwise it will > get RDEPEND wrong due to inherited eclasses. Thanks. You mean like in http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap5 "Never set RDEPEND to DEPEND yourself in an ebuild."? Ok :-) In CVS. I hope I remember getting the new version stable in a few weeks...
(In reply to comment #12) > You mean like in >http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap5 > "Never set RDEPEND to DEPEND yourself in an ebuild."? Yeah, a couple of people have been poking kloeri for a few weeks to get it fixed... No luck yet. :)
