Bugzilla Bug 178905

ebuild contains incorrect information and shouldnt have been commited that way.

contains MY_P="${PN}-0.4.9.2rc4"


Reproducible: Always

Steps to Reproduce:
1.ebuild contains wrong version #
2.
3.

Actual Results:  
>>> Emerging (1 of 1) kde-misc/kbfx-0.4.9.3.1 to /
>>> Downloading 'http://gentoo.osuosl.org/distfiles/kbfx-0.4.9.2rc4.tar.bz2'
--13:51:53--  http://gentoo.osuosl.org/distfiles/kbfx-0.4.9.2rc4.tar.bz2
           => `/usr/portage/distfiles/kbfx-0.4.9.2rc4.tar.bz2'
Resolving gentoo.osuosl.org... 64.50.236.52, 64.50.238.52
Connecting to gentoo.osuosl.org|64.50.236.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,339,541 (3.2M) [application/x-tar]

100%[================================================================================================================>]
3,339,541    941.54K/s    ETA 00:00

13:51:57 (939.05 KB/s) - `/usr/portage/distfiles/kbfx-0.4.9.2rc4.tar.bz2' saved
[3339541/3339541]

Currently testing:
http://superb-east.dl.sourceforge.net/sourceforge/kbfx/kbfx-0.4.9.3.1.ebuild

Created an attachment (id=119546) [details]
kbfx-0.4.9.3.1.ebuild

The ebuild mentioned in Comment #1 appears to work perfectly as long as you
don't have USE=strigi (and you don't have strigi in your overlay, I suppose).

Here is a slightly adjusted ebuild:
- x86 keyword changed to ~x86
- MY_P env var removed
- strigi useflag and use case removed
- very slightly more informative die message

ok now it compiles and works:) just perfectly thank you very much:)

Hi,
I am a developer of KBFX and want to make some notes:
1. The latest released version of KBFX is 0.4.9.3.1 and it is STABLE. That
means thoroughly tested and no bugs found. It has been developed on my Gentoo
system, has some specific Gentoo bug fixes (like the one of randomly
disappearing K-Menu entries after a KDE Login etc.) and has been tested for
over a month on my Gentoo and on several other systems running Gentoo. So the
keyword "x86" is not put in the ebuild by chance.
2. It is high time that someone adds and maintains the strigi search engine in
the portage having in mind that it has reached a stable branch and is expected
to be the default search engine in KDE4.
3. I think the best way to maintain an ebuild is to rely on the developer of an
application especially when he is a long time Gentoo user.
4. I maintain a layman overlay for KBFX on SourceForge with all needed things
for full feature use of KBFX (strigi, strigi applet, clucene). The url is:
https://kbfx.svn.sourceforge.net/svnroot/kbfx/layman/kbfx-overlay.xml

Thanks for your attention

P.S. BTW does someone ever check the new released packages information on the
original homepage of a package? Because as far as I remember KBFX ebuilds have
always had problems though I always release the ebuild too (and it is packed in
the sources too).

(In reply to comment #4)
> 1. The latest released version of KBFX is 0.4.9.3.1 and it is STABLE. That
> means thoroughly tested and no bugs found. It has been developed on my Gentoo
> system, has some specific Gentoo bug fixes (like the one of randomly
> disappearing K-Menu entries after a KDE Login etc.) and has been tested for
> over a month on my Gentoo and on several other systems running Gentoo. So the
> keyword "x86" is not put in the ebuild by chance.

Have you tested it across hundreds of differently configured systems? If you
haven't, straight to x86 isn't appropriate.

(In reply to comment #5)

>>> on several other systems running Gentoo
To be more specific around 30 different Gentoo systems in an extended period of
one month ...

> tested it across hundreds of differently configured systems?
Ok next time before I put "x86" a will test on at least 1 000 000 Gentoo
systems for at least 10 years!

I won't mention at least 10 ebuilds that were marked as "x86" and had merging
problems (the last one as far as i remember was kde-base/kpilot several months
ago).

And as far as I see how "~x86" ebuilds are released (having in mind this
specific one) I think that some of the maintainers are reacting as if they have
not done any testing at all.....

So you're saying that you should be exempt from the usual QA rules because
occasionally the usual QA rules aren't enough to catch all problems?

(In reply to comment #7)
> So you're saying that you should be exempt from the usual QA rules because
> occasionally the usual QA rules aren't enough to catch all problems?
> 

I don't want to be misunderstood.
I don't deny the QA rules, I just want to say that the rules have to be
respected by all and such things as the kbfx ebuld released in the portage
yesterday (Bug 178905) should never happen if the appropriate tests are done
before the release.

And I wonder (not just because I am closely connected to KBFX) how much time is
needed for a package to be "x86" (obviously in the KBFX case 2 years are not
enough and for strigi 3 years are not enough even for entering the portage
tree) ?

Usually it's 1 month without bugs. Calm down dude, no need to start a war here.

(In reply to comment #8)
> 
> And I wonder (not just because I am closely connected to KBFX) how much time is
> needed for a package to be "x86" (obviously in the KBFX case 2 years are not
> enough and for strigi 3 years are not enough even for entering the portage
> tree) ?
> 

In an ideal world every package would have a maintainer being able to give the
ebuild enough time but sadly this is not the case. That is something that is
hard to solve without paying developers to do it.

Fixed in -r1 which I've just committed to CVS.

!!! Digest verification failed:
!!! /mnt/portvar/portage/kde-misc/kbfx/kbfx-0.4.9.3.1-r1.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 554
!!! Expected: 657

got that yesterday after the sync.
got it today after the sync.

Ok, seems like the updated ebuild didn't make it to the rsync system due to a
problem with the timestamp (the newer ebuild had an older timestamp than the
old ebuild, don't ask me why).

I've now touched the ebuild again. It should make its way now.