this is very useful to have, since gnomad requirs gnome libs, and many would like to use their gnomad's on kde. I would write an ebuild.. but i suck at doing it so i'm gonna ask if someone else can.
Steps to Reproduce:
Check out http://www.gentoo.org/doc/en/gentoo-howto.xml for information on how to write ebuilds to submit to us.
Writing the ebuild has not been the problem. Its just that it won't compile without some stuff done to it. Like for instance the configure script doesn't detect qt, but there is an overrride, i don't know how to do all that, thats why i brought this request here without a written ebuild.
Configure script detected qt here, did a short test with some binary pkgs I found. Problem is that I don't have KDE installed, and the build fails like this:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lkio
Don't know what I'd have to do to fix this, but hopefully some KDE user will test the ebuild and touch it up if need be.
Created attachment 58286 [details]
Maybe KDE herd wants to take care of this as it's more a kde thing than sound?
Created attachment 67561 [details]
ebuild for kionjb-0.2.4
I used a direct link to the file instead of the standard $(PV) but that can be
fixed easy enough
It compiles on my computer
Created attachment 67562 [details, diff]
I used a direct link to the source download instead of the standard $(PV)
It compiles on my computer.
Please fix the following and reopen:
* Your two DEPEND lines are incorrect.
* http://dev.gentoo.org/~ciaranm/docs/mw-faq/spacing.txt (src_install)
Dammit all, why did you have to return? I was enjoying not doing anything with
this bug, but in any case, I'm still not happy it was closed so I fixed the damn
thing. Next time just ask, even though I can't stand you and wish you to burn
alive, I still would have fixed it.
Created attachment 68552 [details]
Better ebuild then the last. Though probably not up to ciaranm's standards of
bitchfulness. Someone obsolete the old one, since I can't (which is asinine
since I filed the bug report in the first place)
Please fix the following and reopen:
* http://dev.gentoo.org/~ciaranm/docs/mw-faq/redundant.txt (src_compile)
* You don't have doc listed in IUSE, but you use it in src_install. But then,
the doc use flag isn't for small stuff like READMEs anyway, so just drop the
useq doc && part.
* You should use mirror://sourceforge/
Good job catching me missing the whole SRC_URI line.. I had skipped over it
earlier. Also, the useq doc stuff I usually see ommited from IUSE whether its
right or not, so I threw it in for the hell of it.
But now you're just pissing me off. If you're going to make requests from me,
then you should respect the requests that I have made to you.
1. DO NOT CLOSE THE BUG UNLESS YOU WANT TO HEAR ME RANT. It means I have to
file two comments, one to reopen the bug, and the other to place an attachment.
This is redundant and useless, I could have handled the request much more
efficiently if you had decided to just reply with a comment and not close the bug
2. I asked you to obsolete the earlier patch, I can't obsolete it because not
even the reporter can obsolete an attachment if it was sent by another person.
But I do know a gentoo dev can.
Created attachment 68555 [details]
This should be up to par, unless ciaranm missed something on the last one.
Don't even think of closing it again for such a small reason.
(In reply to comment #12)
> 1. DO NOT CLOSE THE BUG UNLESS YOU WANT TO HEAR ME RANT. It means I have to
> file two comments, one to reopen the bug, and the other to place an attachment.
> This is redundant and useless, I could have handled the request much more
> efficiently if you had decided to just reply with a comment and not close the bug
And no, this is not redundant. It makes it possible for us to track the bug.
> 2. I asked you to obsolete the earlier patch, I can't obsolete it because not
> even the reporter can obsolete an attachment if it was sent by another person.
> But I do know a gentoo dev can.
Ranting does not help, please don't do this. Thanks for fixing the ebuild.
Much as I'd like to reclose this and demand that you remove the blank line in
src_install, I'm not really that petty. AFAICS this one's fine for REVIEWED now,
I could add this to sunrise. But can someone with a Nomad confirm that this thing actually compiles, installs, and works?
(In reply to comment #16)
> I could add this to sunrise. But can someone with a Nomad confirm that this
> thing actually compiles, installs, and works?
before you take this to sunrise, you might want to check the open bugs on this package:
The ebuild still has quite a few problems (e. g. it's missing a dep on id3lib which shows the author never tested it), the project itself is dead (no release for two years, no CVS activity either), it would need quite a few patches to even compile - no, we don't need this.