Please backport this commit to Kate 4.10.1 so Pate will build against the PyQt4 currently in Fedora: http://commits.kde.org/kate/106f4ee310796170a28786a32f2a235d5464f83c Thanks!
Taking off blocker tracker, looks like we've never shipped this plugin in kate before. That said, we're happy to work to add it soon.
I guess we have kde-4.10.2 out now, but we still don't enable pate by default, due to circular dependencies. pykde4 Requires: kate-part already, but in order to build pate, we'd have to add to kate.spec: BuildRequires: pykde4 Are these plugins awesome enough to warrant the extra hassle of bootstrapping? (which requires building in 2 passes)
(In reply to comment #2) > Are these plugins awesome enough to warrant the extra hassle of > bootstrapping? (which requires building in 2 passes) Yes! They're awesome enough for me to have been rebuilding the Kate SRPM with them for some time now, anyway. ;-) Here are some of the cool things they do: http://kate-editor.org/2013/02/18/new-plugins-to-the-kate-utils-to-python-javascript-django-and-xml/ http://kate-editor.org/2013/04/23/a-rich-python-console-and-more-in-kate-editor/ Python is really big in Fedora so it would be very sad for these not to be working in Fedora's kate. :-( I know it would technically violate the one upstream tarball -> one SRPM rule, but I think Pate can be built on it's own (it used to be completely seperate until it got merged with the main Kate tree for 4.10). Would this be preferable to building in 2 passes? I wouldn't mind helping out by putting together the package if this turns out to be a more viable option.
We might be able to avoid the bootstrapping by using relaxed/no dependency versioning, but the separate pate SRPM might be the less ugly solution from a user standpoint (but more ugly from a packager standpoint).
(In reply to T.C. Hollingsworth from comment #3) > (In reply to comment #2) > > Yes! They're awesome enough for me to have been rebuilding the Kate SRPM > with them for some time now, anyway. ;-) > Yup, I'm getting into python now so this would be goodness...
Will it be in 4.11 (kde unstable repository)? Thanks Ciao Martin
No. We're still stuck with the circular dependency.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
What about the solution proposed by T.C. Hollingsworth in Comment 3 ?
Yes, I would accept a separate (something like) kate-pate package to avoid bootstrapping issues. Bonus points to contact upstream to get them to resolve the bootstrapping problem for us somehow.
Sorry, I use kate master generally anyway so I forgot about this. :-/ Looking into this further, I think it makes more sense to split off kate-part into its own SRPM instead, since that's what pykde4 needs. This is fully supported upstream with just a few cmake flags, whereas building pate by itself seems to be a pain. This seems to work nicely: http://patches.fedorapeople.org/katepart-split/ http://koji.fedoraproject.org/koji/taskinfo?taskID=6124133 http://koji.fedoraproject.org/koji/taskinfo?taskID=6124150 (I also fixed the SyntaxError when byte-compiling both in a patch and upstream. :-)
Pardon my ignorance, but how does a separate kate-part package help?
Oh I see, you include the -devel pieces from kate-part pkg. I'll look that over.
Tried building kate-4.11.3 with pate enabled, and the build still fails. Was that upstream commit to master/ only and not backported to 4.11 branch? If so, why?
I committed it to master and KDE/4.11 simultaneously, but it missed 4.11.3 by a day and a half. :-( It'll be in 4.11.4. http://quickgit.kde.org/?p=kate.git&a=commit&h=db0e2c6ddf3d909364e47c7daff68ee624d951c8
OK, thanks, I'll pull that in.
I guess I'll risk the bootstrapping pain for now. If it ends up being too much, we can consider the kate, kate-part srpm split as suggested. %changelog * Sat Nov 02 2013 Rex Dieter <rdieter> 4.11.3-2 - kate: pate(python) plugins not built/packaged (#922280) We'll roll this in to the upcoming kde-4.11.3 update
I confirm I could successfully install the new package on Rawhide (the plugin activation fails on python import errors, but this is another bug for another day ;-)) Thanks for the quick action !
(In reply to edoubrayrie from comment #18) > I confirm I could successfully install the new package on Rawhide (the > plugin activation fails on python import errors, but this is another bug for > another day ;-)) There are two issues: 1. A few of the plugins are missing requires. See bug 1028819. 2. Two more of the plugins (cmake_utils and expand) aren't compatible with Python 2. I'm working upstream to fix this (which may just mean not installing them when python 2 is used).
Arg, https://projects.kde.org/projects/kde/applications/kate/repository/revisions/3115a93d4f35cdb9ab37768cdc90a944c0a7f36d T.C., your commit fixing this upstream was reverted, which rebreaks things for us. Can you poke alex about this? (Or I can if you want)
Yeah, that patch wasn't very correct because I didn't realize that plugin didn't work with Python 2 at all. The real fix is not to bother installing Python 3 only plugins on Python 2; then you don't get SyntaxErrors or useless plugins. :-) So, I just filed a review with a better patch that skips installation altogether of plugins incompatible with the Python version Kate is built against: https://git.reviewboard.kde.org/r/114264/ With this + the new Requires (I'll finish up those reviews next) we should have all plugins working with no tracebacks for 4.11.4, yay!
(In reply to T.C. Hollingsworth from comment #21) > Yeah, that patch wasn't very correct because I didn't realize that plugin > didn't work with Python 2 at all. The real fix is not to bother installing > Python 3 only plugins on Python 2; then you don't get SyntaxErrors or > useless plugins. :-) Fixed upstream in http://commits.kde.org/kate/41e15427a6d6083ead538af0584804e33cbdfc4c
Sorry, the above patch didn't get reviewed in time for 4.11.4. :-( Should be fixed for really real now: http://koji.fedoraproject.org/koji/taskinfo?taskID=6294717 http://koji.fedoraproject.org/koji/taskinfo?taskID=6294719 (Provenpackagered in officially because upgradepath issues, but really because you've wasted enough time on this silly brokenness. ;-) Sorry for all the trouble here.
Thanks!
Working great now, thanks!