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 attachment 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.
