Bugzilla Bug 50803

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 an attachment (id=31225) [edit]
ebuild for KRename 3.0.0rc1

Created an attachment (id=31226) [edit]
updated ChangeLog

Created an attachment (id=31227) [edit]
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 an attachment (id=32032) [edit]
ebuild for KRename 3.0.0rc2

Created an attachment (id=32033) [edit]
digest for KRename 3.0.0rc2 source tarball

Created an attachment (id=32035) [edit]
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.