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 attachment 80773 [details] kde-misc/kerry-0.07.ebuild
Created attachment 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.
Created attachment 81811 [details] kde-misc/kerry-0.07_p7.ebuild new upstream version
Created attachment 81812 [details] kde-misc/kerry-0.08_p2 new upstream version
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 attachment 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 attachment 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 attachment 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).
Created attachment 82751 [details, diff] kerry-0.09-del-shortcut.patch The needed patch for the last attached ebuild kde-misc/kerry-0.09_p3, see below.
> ... see below. I mean above! Now it is correct in both ways. :)
Created attachment 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 attachment 83120 [details, diff] 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.
Created attachment 83121 [details] kde-misc/kerry-0.09-r1.ebuild Ebuild to use the patch I made to include ebuild support in kerry.
(In reply to comment #20) > Created an attachment (id=83120) [edit] > 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 attachment 83717 [details, diff] Sets the small fonts in the hit UI to size 9 instead of 8
Created attachment 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).
Created attachment 83771 [details, diff] The fontsize patch The fontsize patch
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 :)