Code::Blocks 17.12 was released on 30 December 2017. Please add it's update to portage tree. It seems that new version depends optionaly from wxwidgets 2.8 or 3.x now.
Is it working for you with WX_GTK_VER 3.0 or even 3.0-gtk3 maybe, if you are able to test? Also, do you use this and might want to maintain or co-maintain it?
(In reply to Mart Raudsepp from comment #1) > Is it working for you with WX_GTK_VER 3.0 or even 3.0-gtk3 maybe, if you are > able to test? Sorry for delayed answering. Currently I tested emerging codeblocks-17.12 only with wxGTK-2.8.12.1-r2 and wxGTK-3.0.2.0-r3 by manual modifying of it's ebuild variable "WX_GTK_VER" from "2.8" to "3.0". For both cases codeblocks successfully build, run, compile my simple test project and run it's executable. The emerging was made with appropriate wxGTK version independent of current eselect wxwidgets profile. But I didn't test yet build with wxGTK:3.0-gtk3. It's need some additional testing. As for wxwidgets 3.1 it is current developer branch that is not incompatible with wx3.0. As mentioned in http://forums.codeblocks.org/index.php/topic,22266.0.html wx3.1 is needed to support HiDPI. And this wxwidgets version isn't in portage tree as developer branch. > Also, do you use this and might want to maintain or co-maintain it? Yes, I use this IDE sometimes so I could try to modify ebuild to optional wxGTK version selecting and to test emerging again. That could take several days as I'm on the road during new year holiday week until 9 January.
(In reply to Sergey Torokhov from comment #2) > I could try to modify ebuild to optional > wxGTK version selecting and to test emerging again. That could take several > days as I'm on the road during new year holiday week until 9 January. No optional selecting of wxGTK version. It should be chosen what is best for it, 3.0-gtk3 if possible (no bad functional regressions over 3.0). I guess I'll try bumping it with using 3.0 (gtk2) for now, but tests by an active user of the thing for 3.0-gtk3 would be very appreciated, and then we should migrate over in a revbump (possibly coordinated with other wxGTK consumers via p.mask as already started for filezilla). And yeah, I don't think anyone in wxwidgets@ actually uses this thing, so a maintainer or co-maintainer would still be nice. The current interest from me is only due to trying to get rid of SLOT=2.8 wxGTK (and later get things over to 3.0-gtk3).
(In reply to Mart Raudsepp from comment #3) > I guess I'll try bumping it with using 3.0 (gtk2) for now, but tests by an > active user of the thing for 3.0-gtk3 would be very appreciated, and then we > should migrate over in a revbump (possibly coordinated with other wxGTK > consumers via p.mask as already started for filezilla). I am developing elogind with Code::Blocks (but using the live ebuild) with 3.0-gtk3. It runs stable, no glitches and no crashes. What I have done so far: - Compile elogind-235 using meson/ninja - Single step test programs - Single step into library functions - Add breakpoints in test programs and library functions - Add watches on different local and global variables. It just works. However, the automatic hiding of the scrollbars, and the different font configuration is something I have to get used to. And I definitely dislike that all scroll and progress bars are so extra slim. But apart from that, c::b works like a charm.
Created attachment 514082 [details] codeblocks-17.12.ebuild codeblocks-17.12.ebuild based on codeblocks-16.01.ebuild with changed WX_GTK_VER variable to "3.0" and changed SRC_URI variable.
(In reply to Mart Raudsepp from comment #3) > (In reply to Sergey Torokhov from comment #2) > > I could try to modify ebuild to optional > > wxGTK version selecting and to test emerging again. That could take several > > days as I'm on the road during new year holiday week until 9 January. > > No optional selecting of wxGTK version. It should be chosen what is best for > it, 3.0-gtk3 if possible (no bad functional regressions over 3.0). > > I guess I'll try bumping it with using 3.0 (gtk2) for now, but tests by an > active user of the thing for 3.0-gtk3 would be very appreciated, and then we > should migrate over in a revbump (possibly coordinated with other wxGTK > consumers via p.mask as already started for filezilla). > > And yeah, I don't think anyone in wxwidgets@ actually uses this thing, so a > maintainer or co-maintainer would still be nice. The current interest from > me is only due to trying to get rid of SLOT=2.8 wxGTK (and later get things > over to 3.0-gtk3). I tested merging of codeblocks 17.12 with wxGTK:{2.8,2.0,3.0-gtk3} and all of them were successfully done and run after installing. The only problem that with wxGTK:3.0-gtk3 the error messages appears in terminal: > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-WARNING **: Negative content height -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow) > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar > (codeblocks:19151): Gtk-WARNING **: Negative content width -33 (allocation 1, extents 17x17) while allocating gadget (node button, owner GtkButton) > (codeblocks:19151): Gtk-WARNING **: Negative content width -33 (allocation 1, extents 17x17) while allocating gadget (node button, owner GtkButton) Also buttons on toolbar and toolbar itself are too big in comparison with wxGTK-2.8 or 3.0(gtk2) versions of program. I shall attach some screenshots of running program for clean profile.
Created attachment 514084 [details] codeblocks-17.12_wxGTK:2.8
Created attachment 514086 [details] codeblocks-17.12_wxGTK:3.0
Created attachment 514088 [details] codeblocks-17.12_wxGTK:3.0-gtk3 Note that grey background of program window in some screenshots is due to my personal colour settings (that is set to grey instead of white) in my KDE system.
I found that "contrib" USE-flag doesn't enable useful FortranProject plugin that is presented in source-code archive. At least I don't see it in plugin list inside C::B plugin settings list. I'll try to add additional USE-flag "fortran" and to test build C::B with it.
So can one of you or both take this off the hands of wxWidgets team maintenance, and take care of it yourselves? I'd be very happy with that, as I don't actually use it (I use gnome-builder) and I'm not aware of rhill doing so either. My only condition really is that it is upgraded away from WX_GTK_VER=2.8 ASAP and gtk3 version tried as well - perhaps good to go WX_GTK_VER=3.0 with 17.12, and do a 17.12-r300 that uses WX_GTK_VER=3.0-gtk3, but is masked in the coordinated release block, together with filezilla (you can find it from package.mask with some appropriate text); then we can unleash the gtk3 stuff together with filezilla and whatever else joins in that party.
Created attachment 514214 [details] codeblocks-17.12.ebuild
(In reply to Mart Raudsepp from comment #11) > So can one of you or both take this off the hands of wxWidgets team > maintenance, and take care of it yourselves? I'd be very happy with that, as > I don't actually use it (I use gnome-builder) and I'm not aware of rhill > doing so either. I could try to co-maintain codeblocks package. Full maintaining will be difficult for me now as I don't have an experience of writing new ebuild-files and using github to upload changes and also don't know is it possible to make changes only via web-interface. I explored "configure" file of project but "--enable-fortran" options only "integrate (external) fortran plugin in dist-tarball (default YES), NOTE: it will not be build automatically". That is currently there is no internal I successfully build "FortranProject" plugin via it's CBlocks-project after some simple modification of it. After manually installing it seems to be working. At least for Fortran code work (tested): - Fortran plugin menu and toolbar is presented with it's content; - Autocomplete; - Some block snippets; - Highlighting of begin and end of block if cursor is within key-word - Pop-up help-tips for intrinsic fortran functions with information about it within "Logs & other" filed; - Quick jump to declaration and implementation of subroutine/function and back. But I have no idea where should be placed this plugin before compile CBlocks itself. Apparently it's not good to supply already build plugin instead of compiling it by portage tools as it complied with appropriate wxGTK-version. I need to communicate to CB and CB-Fortran developers to get additional info. Currently CB-Fortran for some reasons is't included in official Linux-binary of CodeBlocks. > My only condition really is that it is upgraded away from > WX_GTK_VER=2.8 ASAP and gtk3 version tried as well - perhaps good to go > WX_GTK_VER=3.0 with 17.12, and do a 17.12-r300 that uses > WX_GTK_VER=3.0-gtk3, but is masked in the coordinated release block, > together with filezilla (you can find it from package.mask with some > appropriate text); then we can unleash the gtk3 stuff together with > filezilla and whatever else joins in that party. I's a good idea to divide ebuild into wxGTK:3.0 and wxGTK:3.0-gtk3 version for better testing of last one. How much usually critical the "Gtk-CRITICAL" like errors for applications that appeared when CodeBlocks is compiled with wxGTK:3.0-gtk3?
(In reply to Sven Eden from comment #4) > I am developing elogind with Code::Blocks (but using the live ebuild) with > 3.0-gtk3. I found that CodeBlocks-17.12 merging with wxGTK:3.0 has disabled SymbolsBrowser for C++ projects. While trying to activate it I receive information pop-up message: > "The symbols browser is disabled in wx3.x builds. > We've done because it causes crashes." Do you receive similar information popup message on activating of "View" menu - "SymbolsBrowser" with your 3.0-gtk3 live build? It must displayed then in "Manager" window (Shift+F2) within tab that somewhere near "Projects" tree tab. Mart Raudsepp, could you mention when approximately Gentoo Wxwidgets team is planning to deprecate "WX_GTK_VER 2.8" branch?
(In reply to Sergey Torokhov from comment #14) > Mart Raudsepp, could you mention when approximately Gentoo Wxwidgets team is > planning to deprecate "WX_GTK_VER 2.8" branch? Over two years ago, we are now talking about removing SLOT=2.8 from the tree via last rite or just direct removal. Bug 562480
(In reply to Sergey Torokhov from comment #14) > (In reply to Sven Eden from comment #4) > > I am developing elogind with Code::Blocks (but using the live ebuild) with > > 3.0-gtk3. > > I found that CodeBlocks-17.12 merging with wxGTK:3.0 has disabled > SymbolsBrowser for C++ projects. While trying to activate it I receive > information pop-up message: > > > "The symbols browser is disabled in wx3.x builds. > > We've done because it causes crashes." > > Do you receive similar information popup message on activating of "View" > menu - "SymbolsBrowser" with your 3.0-gtk3 live build? It must displayed > then in "Manager" window (Shift+F2) within tab that somewhere near > "Projects" tree tab. I can check, but I never needed it, so I do not miss it. If it causes crashes, then it might be better, thinking of how deprectated wxWidgets < 3.0 are, to fix it instead of disabling it. Maybe, if I have some time, I can look into it. But did you ever try to singlestep Code::Blocks in GDB? It is ... erm ... not nice. ;-) However, there is one flaky thing (at least with wxGTK-3.0.2.0-r301, haven't tested the new wxGTK-3.0.3-r300, yet) in c::b : The auto completion bar has the right drop down selector (functions/methods) hidden, unless the bar is disabled and re-enabled again. Moving it around didn't help. After that it works normal. (In reply to Mart Raudsepp from comment #15) > (In reply to Sergey Torokhov from comment #14) > > Mart Raudsepp, could you mention when approximately Gentoo Wxwidgets team is > > planning to deprecate "WX_GTK_VER 2.8" branch? > > Over two years ago, we are now talking about removing SLOT=2.8 from the tree > via last rite or just direct removal. > Bug 562480 It is definitely about time! ;-) (In reply to Mart Raudsepp from comment #11) > So can one of you or both take this off the hands of wxWidgets team > maintenance, and take care of it yourselves? I'd be very happy with that, as > I don't actually use it (I use gnome-builder) and I'm not aware of rhill > doing so either. My only condition really is that it is upgraded away from > WX_GTK_VER=2.8 ASAP and gtk3 version tried as well I can proxy maintain it. Just tell me whom to ping on github PRs. > perhaps good to go > WX_GTK_VER=3.0 with 17.12, and do a 17.12-r300 that uses > WX_GTK_VER=3.0-gtk3, but is masked in the coordinated release block, > together with filezilla (you can find it from package.mask with some > appropriate text); then we can unleash the gtk3 stuff together with > filezilla and whatever else joins in that party. I absolutely like the idea, that sounds like a very reasonable plan.
Created attachment 514450 [details] codeblocks-17.12.ebuild Copyright year was changed to "1999-2018" and "pkg_postinst" section with info message (elog) about known wx3.0 issue was added: > pkg_postinst() { > if [[ ${WX_GTK_VER} == "3.0" || ${WX_GTK_VER} == "3.0-gtk3" ]]; then > elog "KNOWN ISSUE:" > elog "The symbols browser is disabled in wx3.x builds due to it causes crashes." > elog "For more information see ticket https://sourceforge.net/p/codeblocks/tickets/225/" > elog "with related commits https://sourceforge.net/p/codeblocks/code/11027/" > elog "and https://sourceforge.net/p/codeblocks/code/11141/" > fi > }
Created attachment 515202 [details] codeblocks-17.12.ebuild pkg_postinst() and pkg_postrm() sections were updated in accordance with QA Notice: > QA Notice.desktop files with MimeType= were found installed > * but desktop mimeinfo cache has not been updated: > * /usr/share/applications/codeblocks.desktop > * Please make sure to call xdg_desktop_database_update() > * in pkg_postinst() and pkg_postrm() phases of appropriate pkgs. > * QA Notice: mime-info files were found installed but mime-info > * cache has not been updated: > * /usr/share/mime/packages/codeblocks.xml > * Please make sure to call xdg_mimeinfo_database_update() > * in pkg_postinst() and pkg_postrm() phases of appropriate pkgs.
As I mentioned above I successfully build the FortranProject plugin. But Code::Blocks projects Makefiles are too difficult for me and huge to change it to build FortranPlugin via make with subsequent installation. Maybe I will get arout it later. Currently I already tested simple FortranPlugin_build.sh (bash-script) to build FortranProject plugin (that is created via ebuild source patching) and want to modyfy it dynamically on depend on current WX_GTK besides WX_GTK=3.0. After I want to add "src_install" section base on "Trivial install" of "https://devmanual.gentoo.org/ebuild-writing/functions/src_install/" to install plugin with it's files.
(In reply to Sven Eden from comment #16) > However, there is one flaky thing (at least with wxGTK-3.0.2.0-r301, haven't > tested the new wxGTK-3.0.3-r300, yet) in c::b : The auto completion bar has > the right drop down selector (functions/methods) hidden, unless the bar is > disabled and re-enabled again. Moving it around didn't help. After that it > works normal. I can confirm that this issue is presented also with wxGTK-3.0.3-r300. The second bar disappears until completion bar re-enabled. Usually the second drop-down list is just inactive until cursor is within any function.
Created attachment 516280 [details, diff] FortranProject_build.diff Build script based on the build options of codeblocks projects files of FortranProject plugin "FortranProject_cbsvn-unix.cbp" (except of it's "-DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP" define options) and "FortranProject_cbsvn_wx30-unix.cbp" and on the base of their "Build log".
Created attachment 516294 [details] codeblocks-17.12.ebuild The modified ebuild-file that uses the "FortranProject_build.diff" patch to build FortranProject plugin (via "fortran" USE-flag). The ebuild was tested (with USE="fortran" enabled) for wxGTK-2.8.12.1-r2:2.8, wxGTK-3.0.3:3.0 and wxGTK-3.0.3-r300:3.0-gtk3. In all cases emerge completed successfully, CodeBlocks aplication started and FortranProject plugin works at least As early were tested: - Fortran plugin menu and toolbar is presented with it's content; - Autocomplete; - Some block snippets; - Highlighting of begin and end of block if cursor is within key-word - Pop-up help-tips for intrinsic fortran functions with information about it within "Logs & other" filed; - Quick jump to declaration and implementation of subroutine/function and back. Mart Raudsepp , could you make a review of ebuild and add it to portage tree? The only request is to save currently in portage tree the Codeblocks 16.01.
Created attachment 520558 [details, diff] FortranProject_autotools_build.diff The patch to build FortranProject plugin by using autotools like others codeblocks plugins.
Created attachment 520560 [details] codeblocks-17.12.ebuild The "codeblocks-17.12.ebuild" file that conditionally applies patch "FortranProject_autotools_build.diff". The separate USE-flag is used as most of additional plugins are mainly for C and C++ development. If patch doesn't applied than autotools aren't used as nothing to reconfigure.
Could you or someone please provide a GitHub PR (or a mergeable branch hosted elsewhere) for this (having a codeblocks that uses wxGTK:3.0 or 3.0-gtk3), while also adding themselves as proxy-maintainers? If not, please tell too and I'll have to look at picking up the ebuilds and patches here; but a PR would allow easier authorship attribution, etc. If 3.0-gtk3 works great, I suggest just having that; if not that great yet, but reasonably well, I suggest having a codeblocks-17.12.ebuild that uses :3.0 and a codeblocks-17.12-r300.ebuild that uses 3.0-gtk3, but is p.masked in the same block as filezilla r300 (coordinated mask to move to gtk3).
I uploaded codeblocks-17.12.ebuild file and patch to build FortranProject plugin to https://github.com/band-a-prend/gentoo-overlay PR: https://github.com/band-a-prend/gentoo-overlay/commit/996a39402858f63452202bd0ddb2610ca847c623 Also I created additional commit for addition of codeblocks-17.12-r300.ebuild: https://github.com/band-a-prend/gentoo-overlay/commit/e8c26b3bb896021464696a6a7df7684337d9b2c7 In addition of disabled SymbolBrowser plugin it has some glitches/problem with auto completion bar as discussed above. Also, please, note that patch for FortranProject plugin is optional special to avoid autoreconf of makefiles run if USE="fortran" it's not set. Otherwise it could be sometimes broke codeblocks build without USE="fortran" if autotools become updated.
(In reply to Mart Raudsepp from comment #25) > while also adding themselves as proxy-maintainers If I want to become a co-maintainer (as currently project is assigned to wxwidgets team) should I also add a pull request of metadata.xml with additional section to with information about me like <maintainer type="person"> <email>author@example.com</email> <name>A. B. Surname</name> </maintainer> ? I don't finish yet carefully reading the Proxy_Maintainers_User_Guide to know more information about it. But if uploaded ebuild and patch is good enough I can to try be a co-maintainer. At least the package updates only every second year.
Created attachment 520950 [details, diff] FortranProject_autotools_build.diff Remove "-I$(top_srcdir)/src/include/tinyxml" in patch of src/plugins/contrib/FortranProject/Makefile.am because Codeblocks 17.12 changelog contains next improvement (http://www.codeblocks.org/downloads/binaries/changelog): * Linux (autofoo): Try to use system provided squirrel, astyle, tinyxml (based on Fedoras unbundle-patch) related issue: https://bugs.gentoo.org/383037 Also "-I..FortranProject" was removed as it doesn't have influence here.
(In reply to Sergey Torokhov from comment #28) > Created attachment 520950 [details, diff] [details, diff] > FortranProject_autotools_build.diff > P.S. I forgot to mention that this changes are also in pull request: https://github.com/band-a-prend/gentoo-overlay/commit/624468b81287d0c00da48207ca51fae377d11375
Github version bumb Pull Request: https://github.com/gentoo/gentoo/pull/7324
What's the current status or activity? Waiting for it...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=be84553eb924219ec51e6fefb62f937a3f4eb697 commit be84553eb924219ec51e6fefb62f937a3f4eb697 Author: band-a-prend <torokhov-s-a@yandex.ru> AuthorDate: 2018-04-27 00:45:56 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-05-05 20:09:09 +0000 dev-util/codeblocks: version bump to 17.12 Code::Blocks IDE package version bump to 17.12 with switching 'WX_GTK_VER' from x11-libs/wxGTK:2.8 to x11-libs/wxGTK:3.0 This also adds a new USE flag 'fortran' which controls the building of 'FortranProject plugin' for Code::Blocks IDE ( https://sourceforge.net/projects/fortranproject/ ) after applying of 'FortranProject_autotools_build.diff' patch. Add patch 'FortranProject_fix_build_gcc7_failed.patch' from upstream that fix gcc7 compilation error "call of overloaded ‘abs(unsigned int)’ is ambiguous" for FortranProject plugin, i.e. when USE="fortran". Remove USE=flag "static" with passing "--disable-static" to econf within src_configure() section. Remove directly passing "-g" compiler option to CFLAGS and CXXFLAGS when USE="debug" by applying the patch 'codeblocks-17.12-nodebug.diff'. Updating 'metadata.xml' file: Adding 'fortran' USE-flag description for 'dev-util/codeblocks-17.12'. Updating 'Manifest' file: Adding size, blake2 and sha512 checksums for 'codeblocks_17.12.tar.xz' tarball Bug: https://bugs.gentoo.org/643494 Closes: https://bugs.gentoo.org/643494 dev-util/codeblocks/Manifest | 2 + dev-util/codeblocks/codeblocks-17.12.ebuild | 85 ++++++++++++++++++++++ .../codeblocks/files/codeblocks-17.12-nodebug.diff | 13 ++++ dev-util/codeblocks/metadata.xml | 1 + 4 files changed, 101 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=be84553eb924219ec51e6fefb62f937a3f4eb697 commit be84553eb924219ec51e6fefb62f937a3f4eb697 Author: band-a-prend <torokhov-s-a@yandex.ru> AuthorDate: 2018-04-27 00:45:56 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-05-05 20:09:09 +0000 dev-util/codeblocks: version bump to 17.12 Code::Blocks IDE package version bump to 17.12 with switching 'WX_GTK_VER' from x11-libs/wxGTK:2.8 to x11-libs/wxGTK:3.0 This also adds a new USE flag 'fortran' which controls the building of 'FortranProject plugin' for Code::Blocks IDE ( https://sourceforge.net/projects/fortranproject/ ) after applying of 'FortranProject_autotools_build.diff' patch. Add patch 'FortranProject_fix_build_gcc7_failed.patch' from upstream that fix gcc7 compilation error "call of overloaded ‘abs(unsigned int)’ is ambiguous" for FortranProject plugin, i.e. when USE="fortran". Remove USE=flag "static" with passing "--disable-static" to econf within src_configure() section. Remove directly passing "-g" compiler option to CFLAGS and CXXFLAGS when USE="debug" by applying the patch 'codeblocks-17.12-nodebug.diff'. Updating 'metadata.xml' file: Adding 'fortran' USE-flag description for 'dev-util/codeblocks-17.12'. Updating 'Manifest' file: Adding size, blake2 and sha512 checksums for 'codeblocks_17.12.tar.xz' tarball Bug: https://bugs.gentoo.org/643494 Closes: https://bugs.gentoo.org/643494 dev-util/codeblocks/Manifest | 2 + dev-util/codeblocks/codeblocks-17.12.ebuild | 85 ++++++++++++++++++++++ .../codeblocks/files/codeblocks-17.12-nodebug.diff | 13 ++++ dev-util/codeblocks/metadata.xml | 1 + 4 files changed, 101 insertions(+)
(In reply to Sergey Torokhov from comment #17) > Created attachment 514450 [details] > codeblocks-17.12.ebuild > > Copyright year was changed to "1999-2018" and "pkg_postinst" section with > info message (elog) about known wx3.0 issue was added: > > > pkg_postinst() { > > if [[ ${WX_GTK_VER} == "3.0" || ${WX_GTK_VER} == "3.0-gtk3" ]]; then > > elog "KNOWN ISSUE:" > > elog "The symbols browser is disabled in wx3.x builds due to it causes crashes." > > elog "For more information see ticket https://sourceforge.net/p/codeblocks/tickets/225/" > > elog "with related commits https://sourceforge.net/p/codeblocks/code/11027/" > > elog "and https://sourceforge.net/p/codeblocks/code/11141/" > > fi > > } I shortened this significantly; should be sparse with these (though at least it's not an ewarn that would end up in more logs)
Let me know when we can remove 16.01 or send me a PR. Though there's also wxGlade and aMule to handle for wxGTK-2.8 removal still, it seems. Please make sure to notify via gentoo bugzilla or e-mail as always, as I am very likely to miss notifications from GitHub.
