Hi! This is a new ebuild for KRename version 3.0.0rc1. It is based on the ebuild for KRename 2.8.5. This is my first ebuild contribution, I hope I've done it right :) Regards, Ren
Hi! This is a new ebuild for KRename version 3.0.0rc1. It is based on the ebuild for KRename 2.8.5. This is my first ebuild contribution, I hope I've done it right :) Regards, René
Created attachment 31225 [details] ebuild for KRename 3.0.0rc1
Created attachment 31226 [details] updated ChangeLog
Created attachment 31227 [details] digest for KRename 3.0.0rc1 source tarball
It's a pity that the ebuild for KRename 3.0.0rc1 didn't get committed before the next version came out... maybe I'll have to get a cvs account and commit it myself?
Created attachment 32032 [details] ebuild for KRename 3.0.0rc2
Created attachment 32033 [details] digest for KRename 3.0.0rc2 source tarball
Created attachment 32035 [details] updated ChangeLog
please do - we could use the help.
now in portage - thanks for the ebuild.
Thank you, Caleb! I have seen that you have generated your own digest file which differs from mine. The reason is that Dominik Seichter has uploaded a corrected tarball for KRename 3.0.0rc2 (which I have used to generate the digest), so the digest file will have to be rebuilt. How do I get CVS access? I've looked around the docs for this but haven't yet found an answer.
hmm, i downloaded the tarball from the website and made the digest - when was it changed? as for cvs access, you have to become a developer first. http://www.gentoo.org/proj/en/devrel/recruiters/index.xml
It's from Monday. Several files in it are newer than in the tarball from the mirrors, i.e. -rwxr-xr-x 1000/100 998487 2004-05-24 19:44:55 krename-3.0.0rc2/configure -rw-r--r-- 1000/100 23053 2004-05-23 15:55:33 krename-3.0.0rc2/ChangeLog instead of -rwxr-xr-x 1000/100 998468 2004-05-19 17:07:19 krename-3.0.0rc2/configure -rw-r--r-- 1000/100 22985 2004-05-20 09:53:18 krename-3.0.0rc2/ChangeLog
The tarball that's "officially" availlable via Sourceforge now differs from the one that's in Gentoo's distfiles mirrors. What makes me wonder: If I emerge krename right now, the source tarball gets fetched from ftp://ftp.tu-clausthal.de/pub/linux/gentoo/distfiles/krename-3.0.0rc2.tar.bz2, which means emerge took a "gentoo" mirror. In the ebuild a "sourceforge" mirror is requested. How is this difference to be explained?
Thanks for your report Rene. It's a silent update. I "like" those, because you never know, if it were a hot fix or if they were hacked, without looking into the code. rc3 is out, so I'll remove rc2.
Now that 3.0.0 is out, is there any reason why the -enable-final was removed from the 3.0.0 ebuild? I've tried compiling with -enable-final and it's working fine, without -enable-final the compilation is slower. If there is no reason for the removal, I vote to put it back in.
I removed --enable-final, because it doesn't make sense to add it in every single ebuild. It should be added in kde.eclass and invoked either by a gobal use flag or ebuild local flag. Why do you bother, Rene? Even on low spec hardware krename takes only a few minutes to build.
It should be a flag, because sometimes the devs of the packages don't check for 'enable-final' before they release the package and thus it doesn't compile properly. This way, at least you can turn it off.
Carsten, I bother because I noticed it takes considerabely longer to compile krename on my Gentoo system than it takes under SuSE 9.0 on the same PC. And a faster compile is saved time for every user and every release. Since -enable-final works for krename 3.0.0, I don't see a reason to not use it. Unless of course, there's a situation where krename 3.0.0 fails to compile due to -enable-final. I see the need to try this for every new release of krename, but one has to try the build process anyway before comitting a new ebuild, so this should not cause more work for the maintainer.
Caleb, I don't understand what you mean with the developers not checking for -enable-final. A developer should IMHO test the newly created ebuild before committing it. Wouldn't he then notice the failure if -enable-final is statically turned on?
By "developer" I mean the person who created the package, not the Gentoo developer. --enable-final isn't guaranteed to work for any kde package. Just because it compiles for you doesn't mean it will compile for me. This is especially true with various use flags that change compilation options. This discussion is probably more suited for bug #14003.
