Description of problem: Code::Blocks bundles a copy of wxScintilla from http://wxcode.sourceforge.net/components/wxscintilla/ in src/sdk/wxscintilla which should be packaged separately. wxScintilla itself bundles a copy of the Scintilla core, which itself can be found under src/sdk/wxscintilla/src/scintilla in Code::Blocks. Version-Release number of selected component (if applicable): codeblocks-10.05-3.fc14 How reproducible: Always Steps to Reproduce: 1. Look for bundled libraries. Actual results: Bundled libraries. Expected results: No bundled libraries. Additional info: src/sdk/mozilla_chardet is also bundled copypasta, but that one doesn't seem to be a proper library at all. :-(
The above URL contains a dead branch and AFAIK it wasn't clear for a long time where the development happens/should happen and users of wxScintilla did patch their copies. I'll see how feasible is to switch to wxScintilla from wxWidgets what should be the primary source these days.
C::B uses a forked copy of scintilla with changes that are specific to C::B, so even a new development (that didn't happen yet) in wxScintilla won't help here. See http://forums.codeblocks.org/index.php/topic,13538.0/topicseen.html for more details.
Sorry, you can't close this that easily :-( Here's the choices -- I'd like to see some discussion about whether C::B upstream would be willing to become the canonical source for wxscintilla since it is dead upstream. As they themselves note, wxscintilla being dead upstream means that there's a proliferation of bundled copies in many projects. This leads them all to need to duplicate each others work fixing bugs, adding features, responding to security issues, etc. In the long run, taking over development and getting all the forks to merge will be a time benefit to them. The scintilla problem is different. Upstream C::B has apparently decided that their changes wouldn't be acceptable to upstream scintilla and that their changes aren't useful to others either. Have they sent their changes for upstream consideration to determine that or are they just guessing? Especially when asking whether other projects might want the more featureful version of scintilla (and thus, whether they should have a forked version available for everyone to use and contribute to just like the wxscintilla case) I'm wondering how they've determined that they should be the only consumers. If they feel they must fork the code then you must ask FESCo to grant an exception. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions And if you are granted an exception, you need to add the virtual Requires: as outlined here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle
The situation is following - C::B bundles wxScintilla, wxScintilla bundles scintilla. The scintilla in C::B is now modified to fit C::B (exclusively) needs and some of the general changes were rejected by upstream (see reply #11 in the thread). So becoming upstream for wxScintilla doesn't make any sense for them.
So preparing the facts for fesco, the exclusively argument should be prove/document. Why are the changes only useful to C::B? With the general changes rejected by upstream, you probably also want to find out why those changes weren't taken because that could have implications on the maintenance burden we're potentially taking on in helping to maintain a codebase that has those changes. They say that they've submitted their changes to scintilla upstream, have they also submitted their changes to wxwidgets to see if we can get them into the copy of libraries there? Right now we're bundling scintilla in both places. Related to the last question -- Our wxGTK package is bundling scintilla. Do you want to unbundle that or try to merge the bundled scintilla from C::B with that and try to get an exception for just one bundled scintilla there?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.