Bug 124173 - ebuild for kde-misc/kerry-0.09 - KDE client for beagle desktop search
|
Bug#:
124173
|
Product: Gentoo Linux
|
Version: 2005.1
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: flameeyes@gentoo.org
|
Reported By: le.petit.fou@web.de
|
|
Component: Ebuilds
|
|
|
URL:
http://www.kdedevelopers.org/node/1820
|
|
Summary: ebuild for kde-misc/kerry-0.09 - KDE client for beagle desktop search
|
|
Keywords: EBUILD
|
|
Status Whiteboard:
|
|
Opened: 2006-02-26 08:55 0000
|
I made an ebuild for Kerry 0.07
The only sources I found for this program were on the opensuse servers so the
ebuild downloads the source rpm and uses the rpm.eclass to handle it
transparently.
Sorry, wrong Hardware flag. It should be x86 and amd64
Created an attachment (id=80955) [details]
kde-misc/kerry-0.07_p6.ebuild
Added new (patch level) version to reflect new upstream release.
Added empty IUSE variable and a second download URL to the ebuild, as the
original rpm was sometimes not available.
I'll see to take a look for this to be added in portage (don't expect this to
be done before next week tho, I'm still feverish, better not commit to real
tree right now :P)
Created an attachment (id=81981) [details]
kerry-0.08.2.ebuild
Seems like I can't do much for now, as mono useflag is still masked for amd64
for a while (and beagle is not keyworded).
The attached ebuild is a little cleanup I did to avoid using _p (I would use
that only for patchlevels or cvs snapshots if we really need), and avoids
depending on 0.2* for beagle (it's not slotted, that kind of depend might
break).
The kde_src_unpack run is just a "better here than nothing", just because I
hope it will follow extragear's way to handle documentation and translations in
future (I know hope is not always right but..), and that allows a seamless
handling of patches with other kde ebuilds.
The keyword ~amd64 here is just a reminder for myself, it shouldn't be actually
depended on because beagle is not keyworded. Also please note when submitting
ebuilds that keywords should be added only for those arches you have actually
tested on and all ~.
Why do you (always :) ) remove the (~)x86 flags of ebuilds, I posted
originally and tested for x86?
I thought, the use of patch level version _p2 is neccessary to respect a
posible originial verion like "kerry-0.08.1-1.src.rpm" which would clash with
"kde-misc/kerry-0.08.2"
beagle has a changed api since version 0.2 and I never tested an older version.
(But other programms like kio-beagle only work eighter with beagle <0.2 or with
>=0.2, but not for both with the same code base.)
One more note:
The SRC_URI on opensuse will only contain the latest version, so if opensuse
releases a newer version, automatic fetching will fails as long as to file is
not injected into the Gentoo mirrors. Thats the reason why I left a (my) second
mirror url in SRC_URI, so that anybody can use this ebuild even if this file
can not be found on opensuse.
I drop ~x86 keywords because here I just have amd64 so that's what I can
test/commit with :)
I'd have to check about the rpm versioning scheme, usually this is what it's
used also with debian patches, simpler to work with, but you're right, if they
would release a 0.08.1 it will be a problem... I could probably contact Binner
and ask him if he's going to do a source-only non-rpm release, that should
solve this problem.
(In reply to comment #10)
> I drop ~x86 keywords because here I just have amd64 so that's what I can
> test/commit with :)
Ok, but I tested the ebuild on x86. If you want, you could trust me: it works,
at least stable enough for a ~x86. :)
> I could probably contact Binner
> and ask him if he's going to do a source-only non-rpm release, that should
> solve this problem.
This would be the best solution. This would fix the
always-available-source-package-problem too.
I can trust you, but what I commit will always be only what I can test by
myself, it's just a policy reason, not a personal thing.
Ok, I understand.
So, my problem is, that this bug will be marked as fixed/resolved/closed when
you commit the build to the tree, but it is not really resolved at all, as I
posted a bug about a x86 package. :)
Is there some policy for this case too? Maybe marked as half-closed. :)
It is really annoying to open a second bug just to request to mark a package
~x86 which was already requsted with the last bug report. This will increase
the work for all, developers, maintainers and bug posters, and also possibly
triggers more errors like the last one with marking rsibreak as (x86!) stable.
I'll see to CC x86 before resolving the bug after I'll commit, but I'm not sure
how they would like it, usually for amd64 it's a bug for request..
Anyway, it might take time if I'll have to handle this because it requires
beagle ~amd64, that requires mono stable...
kerry-0.09-2.src.rpm can be found since a couple of days.
For latest version (0.09-2) just rename the ebuild. I think, it's not
neccessary to submit the already existing ebuild again and again.
Created an attachment (id=82749) [details]
kde-misc/kerry-0.09_p3
New ebuild for upstream version kerry-0.09-3 including a patch, to disable the
keyboard shortcut (at least) F12. As the shortcuts are hardcoded, even changing
or disabling them in the configuration dialog is not persistent over sessions.
F12 clashes with to many other packages, e.g. yakuake (prevents yakuake from
appearing completely), kpdf (presentation mode, or is this my own
configuration? I forgot), compiz's expos
Created an attachment (id=82749) [details]
kde-misc/kerry-0.09_p3
New ebuild for upstream version kerry-0.09-3 including a patch, to disable the
keyboard shortcut (at least) F12. As the shortcuts are hardcoded, even changing
or disabling them in the configuration dialog is not persistent over sessions.
F12 clashes with to many other packages, e.g. yakuake (prevents yakuake from
appearing completely), kpdf (presentation mode, or is this my own
configuration? I forgot), compiz's exposé function, etc.
The patch (next attachment) disables just F12, the other shortcuts
(Ctrl+)Alt+Space stay functional (and hardcoded).
> ... see below.
I mean above!
Now it is correct in both ways. :)
Created an attachment (id=82967) [details]
kde-misc/kerry-0.09.ebuild
Binner released the current version as "normal" tarball, so there is no need to
use rpm.eclass. :)
Download-URL, Homepage and description changed as well.
Created an attachment (id=83120) [details]
kerry-0.09-gentoo.patch
This patch modifies kerry to include support for indexing of ebuilds. Actually
it depends on properties added to the index via my ebuild filter submitted in
bug 126733. For indexed ebuilds it will show the package name, version,
description and home page. It also has a category to only search ebuilds.
(In reply to comment #20)
> Created an attachment (id=83120) [edit] [details]
> kerry-0.09-gentoo.patch
>
> This patch modifies kerry to include support for indexing of ebuilds. Actually
> it depends on properties added to the index via my ebuild filter submitted in
> bug 126733. For indexed ebuilds it will show the package name, version,
> description and home page. It also has a category to only search ebuilds.
>
Maybe, this patch should be made optional, via a use-flag, which could be used
for a patched beagle version too.
Perhaps "depends on" has the wrong idea. The patch will not fail or cause
problems with kerry if the beagle ebuild filter is not present, you just won't
get all the extra info. The ebuild filter was checked into the beagle
repository today so it should be included in the next release.
Sorry, I was a bit swamped lately and I wasn't able to actually do much about
this (and I was also waiting the reply from Binner, who answered me just when
0.09 was released :) ).
Now, release 0.09 is probably more stable than the previous 0.08 series, as
also Binner said.. the patch to get info about ebuilds sounds actually nice,
I'm going to try it out soon. Did you try to send it upstream? I'm not sure
about Binner's philosophy about this but I suppose he'll be quite happy to
integrate new stuff...
And about the shortcut, probably the best way is to submit upstream a patch to
make it configurable in the usual KDE ways.
I'll see if it's the case to put this in portage now or wait for a bit more so
that code can be "cleaned up" a bit.. myself, I'll send upstream a patch to fix
the .desktop installation path :)
(In reply to comment #24)
> And about the shortcut, probably the best way is to submit upstream a patch to
> make it configurable in the usual KDE ways.
Sorry, I'm ATM (till' end of next week) short of time, could someone else
please mention the shortcut issue upstream. When not, I will try to make the
patch around the 10th Apr, as far as I can plan.
Regarding the patch for ebuilds... I have not sent it upstream yet. I wasn't
sure if that was appropriate seeing it is Gentoo specific. I did send the
beagle filter upstream and it has been committed. I will send the patch to
binner and see what happens.
If this feature is now part of beagle, then it has to get supported by kerry,
too. Not supporting it doesn't make sense, or kerry would be an only half
functional beagle client.
Okay I've committed it to portage, x86 arch team can you take a look to mark it
~x86 as requested by submitter?
I would like to propose the attached patch, as the font size 8 is just too
small to be readable on a 1400x1050 display (at least on mine, which has
correct DPI settings).
Created an attachment (id=83770) [details]
The ebuild using the fontsize patch
I've created a patch to remove the complete fontsize definitions, so kerry uses
the fontsize given by the KDE settings.
Ebuild needs the fontsize patch (see next attachment).
Please send the changes upstream, the version in portage tries to stay as
vanilla as humanly possible (i did an exception about the shortcut because it's
way too common, and the ebuild thing mostly concerns gentoo), but for font
size, really you should ask upstream.
Sent a mail to binner... let's see what happens.
Well as you opened the other, I'll close this one :)
