I'm submitting an ebuild for a project of mine called RipOff. Website is http://ripoffc.sourceforge.net Here's a description of the project from the site's FAQ: What is RipOff? RipOff is a GTK+ based CD Ripper for Linux (and hopefully for other Unixy systems once some testing and fixing has been done) that sports a simple interface, CDDB lookups, and a plugin-based encoder architecture. It looks GUI-wise suspciously like Sound Juicer in some ways, although I've changed the parts I didn't like of Sound Juicer's interface (of course). It is currently in a pre-1.0 release cycle. Why should I use RipOff? It's purely a matter of opinion. Before the full release of RipOff you may find it buggy and not featureful enough. The reason it was written was because I found the interface of grip to be overly complex and Sound Juicer's interface has just became strange to me, if still simple. A nice thing is that RipOff doesn't depend on GNOME (unlike Sound Juicer), so for all you GTK+ fans who despise GNOME, and don't like grip, RipOff is something that hopefuly appeals to you. I think RipOff belongs in media-sound.
Created attachment 86857 [details] Ebuild for RipOff
Comment on attachment 86857 [details] Ebuild for RipOff # Copyright 1999-2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION="Simple GTK+ Based CD Ripper" HOMEPAGE="http://ripoffc.sourceforge.net" SRC_URI="mirror://sourceforge/ripoffc/${P}.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64" IUSE="vorbis mp3" DEPEND="${RDEPEND}" RDEPEND=">=x11-libs/gtk+-2.2 dev-libs/libcdio media-libs/libcddb vorbis? ( media-libs/libvorbis ) mp3? ( media-sound/lame )" src_unpack() { unpack ${A} cd ${S} } src_compile() { econf \ $(use_enable vorbis) \ $(use_enable mp3) \ || die "./configure failed" emake || die "emake failed" } src_install () { make DESTDIR="${D}" install || die "make install failed" dodoc AUTHORS ChangeLog README TODO }
Please, don't use the edit function on attachments... It doesn't do what you expect it to... Attach a new one and mark the previous as obsolete.
Created attachment 87450 [details] RipOff-0.7.ebuild
This is now in Gentoo Sunrise at: http://www.gentoo-sunrise.org/sunrise/browser/reviewed/media-sound/ripoff/ripoff-0.8.ebuild
Created attachment 116515 [details] ripoff-0.8.2.ebuild
Created attachment 116516 [details, diff] 0.8.2-missing-include.patch Please consider applying the above patch upstream, as you are using strncat in lib/RipOff.c without including string.h I will have a look at this ebuild when I'm at home, my work laptop doesn't have a CD drive.
Complete failure on PPC64; the "ripped" .wav contains static, and the CDDB connection fails. I'm sorry, I have lost interest in this package. Do feel free to CC me on the bug once you release an endian-safe version.
Do you know if any of the other plugins work? Looking at my code I see why WAV failed, but the other plugins look good when I visually inspect their code. I don't have access to anything other than amd64 Linux, so there is no way I can ever test RipOff on other architectures myself. Outside assistance would be greatly appreciated.
This has been sitting in maintainer wanted for almost over a year and a half. What the heck does it take to get a package in portage?
Having it work when I try it out, for example. This is not a portable application. I spend 90% of my free development time on a PPC workstation. When it is endian-safe and ready for me to try again, let me know.
I'd curious to know how I'm supposed to make sure it works without access to a PPC machine. I asked for more debugging information from you and never got a response and my attempts at finding others with PPC machines to assist with the debugging of RipOff have proven unfruitful.
Upstream can still be found on SourceForge but the project as a whole hasn't seen any activity since April 2013 and there have been no new VCS commits since November 2007. More importantly, it doesn't build against versions of dev-libs/libcdio currently available in Portage.
