New version is available
Created attachment 97580 [details] wxGTK-2.7.0_p1.ebuild this is my ebuild for the current testing release: 2.7.0 please note: 1) no documentation is available 2) i've added support for gnomevfs with gnome use flag
I have no intentions to put a wxGTK-2.7 ebuild in the tree right now, as it is a development release and completely API/ABI unstable. Some other reasons below. However, some comments on the ebuild for future reference, and for the improval of it for people who might want to grab this into their local overlay: * Why _p1 version? * There should be a conditional depend on gnome-vfs as appropriate. * There should be a conditional depend on libgnomeprint(ui) as appropriate (this is a problem in the tree versions as well, so thanks for making me realize that - I'll fix for 2.6.3.3). * There are various issues with the SLOT handling right now. My current plans to solve this is to work towards removing wx 2.4 versions from the tree, and figure out a proper solution for the problems by the time a different SLOT than 2.6 is introduced back. SLOT=2.7 falls in that category. This is another reason I can't add this to the tree at this point (other than it being a development release) * The 2.6.3.3 update, that I have almost ready now, migrates away from using wxlib.eclass, at which point it will be considered deprecated, until a new "version" of this eclass is introduced back. I don't see a reason for this to happen before the original intention for the eclass becomes necessary, which was re-use of code for different wx ports - wxGTK, wxMotif, wxX11 and so on. The current one is wxGTK specific and does not warrant an eclass with all the problems and issues the current version has. So once I put 2.6.3.3 in the tree, this ebuild here could be revised in that light. * As 2.7 version is ABI incompatible with 2.6, all things using wxGTK in the tree need to have their (R)DEPEND atoms checked and corrected as appropriate. Things that don't work with 2.7 need to be =2.6*, not >=2.6* and so on. Thanks for the efforts!
Thank you for your comments, they show me there are much more things to consider when upgrading ebuilds. Anyway, just know that I too have never had the intention of setting this as a final ebuild. I know almost nothing about ebuilds, eclasses and python. This is my contribution to the project where boring things are already set (folder names, compilation problems, patches...) You know (because I tell you) this ebuild compiles (on my machine: uhmm, next time I'll upload even my emerge --info): so you now can work on project wide problems such as rdepend and eclasses. The only reason I set up this ebuild was because I need something more up to date than pgadmin3-1.2 (pgadmin-1.4 series breaks). As pgadmin team released the beta of 1.6 which requires wxwidgets 2.7, here I am. I've used the _p because original archive name is 2.7.0-1 and ebuild complains for an inappropriate version number. THought _p was the most appropriate. I've sloted as 2.7 because I've some software using wxGTK and, as it takes quite a long time to compile, 50 mins or so, I wanted to have it installed without interfering with other softwares. I'm glad you appreciate my efforts. If I can be of any help, let me know
(In reply to comment #3) > You know (because I tell you) this ebuild compiles (on my machine: uhmm, next > time I'll upload even my emerge --info): so you now can work on project wide > problems such as rdepend and eclasses. Yeah, it should compile fine, but there are all the other considerations. I haven't done the build system changes planned in upstream yet, either *grin* > The only reason I set up this ebuild was because I need something more up to > date than pgadmin3-1.2 (pgadmin-1.4 series breaks). As pgadmin team released > the beta of 1.6 which requires wxwidgets 2.7, here I am. Interesting information. If apps start using 2.7 earlier, then there can be a reason to work on getting this p.masked in earlier. However, the current plans for stable 2.8 release date seem to be set at November this year, so can probably wait till then, or at least a release candidate as the time isn't too far away. > I've used the _p because original archive name is 2.7.0-1 and ebuild complains > for an inappropriate version number. THought _p was the most appropriate. Could use the wxPython tarball of which some should be released for 2.7 by now. > I've sloted as 2.7 because I've some software using wxGTK and, as it takes > quite a long time to compile, 50 mins or so, I wanted to have it installed > without interfering with other softwares. A SLOT is necessary anyhow, as they need to co-exist for some time until everything in the tree works with 2.8, until it's out. Just there are the concerns of some files colliding between different SLOTs of wxGTK, which need to be resolved. Also the version selection in wx app ebuilds needs to be thought out once again. > I'm glad you appreciate my efforts. If I can be of any help, let me know I hope I can start working on the SLOT stuff in a couple weeks or in a month or so. Before that I need to fix problems in the existing stuff in the tree - 2.6.3.3 bump together with lots of bug fixes, 2.4 removal to solve another set of bugs, and so on. I will probably mention it on my blog when I start working in an overlay for the version SLOT stuff. Thanks again!
*** Bug 149854 has been marked as a duplicate of this bug. ***
Created attachment 100779 [details] wxGTK-2.7.1.ebuild I have created this ebuild from the wxGTK-2.6.3.3.ebuild file in the trunk. I think that it has some of the requisted "features" that was asked for by Mart. I am not an ebuild guru at all, so this ebuild is just meant as a starting point. I should say that I was unable to compile some of the contributed source of wxGTK (animation, deprecated and ogl). I solved this by doing: ebuild /usr/local/portage/x11-libs/wxGTK/wxGTK-2.7.1.ebuild fetch unpack Comment out the defunct subdirectories in /var/tmp/portage/wxGTK-2.7.1/work/wxGTK-2.7.1/contrib/src/Makefile.in (this should have been done by a patch, I know). ebuild /usr/local/portage/x11-libs/wxGTK/wxGTK-2.7.1.ebuild compile install qmerge So as it is quite clear, the ebuild is incomplete (lacks at least a patch) but it is meant as a starting point. ./Emanuel
Created attachment 101484 [details] wxGTK-2.7.2.ebuild Just the next version, this one builds without all the fuss in contrib-folder.
*** Bug 156281 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > *** Bug 156281 has been marked as a duplicate of this bug. *** > Yes, but removing the duplicate typedefs in Xmd.h solves the issue - it's an xproto fault. -- #ifndef I_NEED_OS2_H typedef CARD8 BYTE; // typedef CARD8 BOOL; #else #define BYTE CARD8 // #define BOOL CARD8 #endif --
(In reply to comment #9) > (In reply to comment #8) > > *** Bug 156281 has been marked as a duplicate of this bug. *** > > > > Yes, but removing the duplicate typedefs in Xmd.h solves the issue - it's an > xproto fault. > > -- > > #ifndef I_NEED_OS2_H > typedef CARD8 BYTE; > // typedef CARD8 BOOL; > #else > #define BYTE CARD8 > // #define BOOL CARD8 > #endif > > -- > Forget I said that - it solves the issue in one place and leaves an error in the next.
I just want to note after reading the comments that the RC1 of 2.8 is out, http://sourceforge.net/forum/forum.php?forum_id=634340 I was wondering if that would be put into portage (~arch) for the smooth moving in terms of all the settings and configurations mentioned above to happen. Thanks.
Could you supply a working ebuild ?, maybe see if you can modify mine (wxGTK-2.7.2.ebuild).
2.8.0 was released yesterday and is on the release servers. wxWidgets homepage is not quite updated yet.
Bumping wxGTK to 2.8 should also fix #151528.
*** Bug 158006 has been marked as a duplicate of this bug. ***
See http://thread.gmane.org/gmane.linux.gentoo.devel/44736/focus=44737 for a step by step plan for wxGTK in Gentoo and prerequisites for 2.8 adding
*** Bug 158666 has been marked as a duplicate of this bug. ***
Please note that according to its website, aMule also depends on this new version 2.8.0, as mentioned in the bugreport now marked duplicate: It seems that aMule is currently crippled as a result of bugs in the wxwidgets version that is now in portage. According to aMule's website this should be fixed in 2.8.0, so I suppose the aMule ebuild should actually been made to depend on wxwidgets >= 2.8.0 as soon as that's considered stable enough (or simply right away). website: http://www.amule.org/ forum thread: http://forum.amule.org/thread.php?threadid=11834 Thanks, Erik Logtenberg.
filezilla also requires 2.8.0 or later
Created attachment 105283 [details] wxGTK-2.8.0.ebuild Only thing i changed was: doc? ( mirror://sourceforge/wxwindows/wxWidgets-${PV}-html.tar.gz )" to doc? ( mirror://sourceforge/wxwindows/wxWidgets-${PV}-HTML.tar.gz )" As they have changed the case of the word 'HTML' upstream.
(In reply to comment #20) > Created an attachment (id=105283) [edit] > wxGTK-2.8.0.ebuild 1) Shouldn't it be SLOT="2.8" instead of SLOT="2.7" ? 2) Perhaps the ebuild should not inherit the debug eclass as per bug 55708.
Created attachment 105564 [details] wxGTK-2.8.0.ebuild First off removed some white space indents, not tabbed indents. Removed debug eclass as i was getting : * QA Notice: The package wxGTK-2.8.0 still uses the broken debug.eclass Fixed Slot.
Created attachment 105565 [details] wxGTK-2.8.0.ebuild First off removed some white space indents, not tabbed indents. Removed debug eclass as i was getting : * QA Notice: The package wxGTK-2.8.0 still uses the broken debug.eclass Fixed Slot.
Created attachment 105607 [details, diff] wxwidgets.eclass.patch Something like this is necessary for an ebuild to actually be able to build against wxGTK-2.8.0. The patch worked in my limited testing with amule, otherwise I have no idea how correct is it.
this is also halting pgadmin3 from rolling into version 1.6.x branch.
by using the more recent GTK ebuild, without the patch i was able to successfully emerge wxGTK. It appears to work beautifully with the most recent pgAdmin3 ebuild (1.6.2, see bug #160885).
thanks, we're aware that several packages are depending on wxGTK-2.8.0. you can file a bug and set it depending on this one if you like. but we won't be adding 2.8.0 until several larger problems are solved (see comment #16). adding it now would make quite a mess. :d
Created attachment 113338 [details] wxGTK-2.8.2.ebuild Changed main library to .bz2 instead of .gz, also the HTML docs only have a zip file on sourceforge, so that was also changed.
2.8.2 compiles successfully but pgadmin3 is still b0rked
Does enabling the "debug" flag compile both the debug and release versions or just the debug version? If it just does debug, I'd suggest changing it to do debug in addition to release.
2.8.3 has been released... Please update the summary.
Created attachment 115121 [details] wxGTK-2.8.3.ebuild
Created attachment 115181 [details] wxGTK-2.8.3.ebuild includes socketpatch
Created attachment 115183 [details, diff] wxGTK-2.8.3-socketfix.patch https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1688222&group_id=9863
Created attachment 115235 [details, diff] socketfix.patch
Created attachment 115237 [details] wxGTK-2.8.3.0.ebuild cleaned up, and using python sources like 2.6.X in the tree.
*** Bug 173195 has been marked as a duplicate of this bug. ***
Could someone please enlighten me (no irony intended) and explain why wxPython sources are used and why this ebuild is so complex when it seems so straightforward to install wxWidgets by hand (i.e. ./configure && make && make install)??
I wondered the same thing and was told that wxPython is used, because it contains not only wxPython, but also wxGTK and a few patches on top of it. (Which might be a questionable decision of the wxWidgets devs. I didn't investigate further to be able to tell why they did do this.) As there is the possibility that one does not only want wxGTK but also wxPython, and because of the patches, the maintainers decided that they should use wxPython for both. As for the complexity of the script: I have no clue, but it would not be the only ebuild which is more complex than required, because it evolved from bigger historical problems.
wxPython release tarballs are used because a) They are giving us releases more often - the point-releases with the fourth version number updated. Historically that has been very beneficial, as wxPython tarballs are released far more often, while wxGTK ones used to be very rare, and the wxPython tarballs include all the backporting work and bug fixes that have happened meanwhile (including trivial things like, oh, crash fixes that affect amule) - wxGTK-2.6.3 was released 25th March 2006, wxGTK-2.6.4 was released 21st March 2007 - without using the wxPython tarballs you wouldn't have gotten bug fixes for a year. b) It means smaller total downloads for those needing wxPython. 11.7MB + 19MB for wxGTK + wxPython tarball. Just 19MB for having only one - not a big extra for a package that takes hours to compile. c) It means no subversion mismatch between wxGTK and wxPython, which in turn means no warnings from wxPython, and no chance for real issues from lacking updated to wxGTK for a wxPython point release. I believe I listed all that on a different bug. Should make some doc page at some point :) The "complexity" comes from having to handle compilation and installation of two different versions of the library with unicode USE flag (unicode and non-unicode version, as some wx using apps in tree still don't work with unicode). This "complexity" has always existed, but simply hidden away inside wxlib.eclass - recent ebuilds are not using it anymore as a) eclasses are meant to help cases where multiple ebuilds benefit from the eclass, but currently there is only wxGTK (No wxBase, wxMotif or anything that would reuse it) b) What's in wxlib.eclass currently handles things that an eclass should not. Passing configure flags and othe flags that are only necessary to be passed for one of the versions. For example it just happened to have to pass -j1 and --disable-precomp-headers which in total effectively at least doubles the compilation time of the whole thing for all versions, while necessary only for some old revisions - maybe. It also handled doc installation, and that was simply broke as things get restructured upstream or the HTML doc tarball changed a little. c) given all that, it's better to just do the multiple version building and doc installation in the ebuild itself, as that just gets copied over on version bumps and fixes don't affect other packages. This will be reconsidered once and if there is actually a benefit of the eclass - for example a wxBase or wxMotif or wxX11 package.
OK, I'm now completely educated and convinced that using wxPython is the right choice. Thanks :)
Now that the new ebuild uses wxPython, will it go into the tree? And why is this blocked by wxGTK-2.4?
see Comment #16 http://thread.gmane.org/gmane.linux.gentoo.devel/44736/focus=44737 We're stuck at step 3. Leio i think has step 4 covered. I have step 5 all but done (not counting the eselect stuff). I'm auditing the tree right now to make sure everything will still work with the changes. When it's ready it'll be posted. I apologize for the delay. We _are_ actively working on it, despite the lack of updates. ;)
aMule-2.2.0 will require this one too.
the ebuild does not work. it tries to download wxPython 2.8.3 but there is only 2.8.3.0 on the sourceforge servers. if i download and rename that one the patch won't apply because it tries to patch the files in the directory wxPython-2.8.3-src but the directory is named wxPython-2.8.3.0-src
It should work (barring the problems why we are taking our time getting this into the official tree), I think. Are you sure you kept the ebuilds name wxGTK-2.8.3.0.ebuild and didn't accidentally save it as wxGTK-2.8.3.ebuild instead, which would cause the problems you describe?
Worked for me yesterday. I need the new wxPython-2.8 also. So used this ebuild and patch and worked fine. The only problem I ran into was DID need the wxwidgets.eclass.patch also. But had a problem with that. It applied it said, but forget exactly what problem it said after. So manually patched the wxwidgets.eclass. That took care of problem getting wxPython-2.8.3.0 to emerge. I modified that ebuild and until fixed the eclass it wouldn't emerge. I tested my app out and works with the wxGTK and wxPython 2.8.3.0. Now I can get back to debugging a problem with wxGTK and print dialog.
(In reply to comment #47) > So manually patched the wxwidgets.eclass. That took care of problem getting wxPython-2.8.3.0 to emerge. Not sure how to add the patch for the eclass except for manually. Otherwise get this: * A dry-run of patch command succeeded, but actually * applying the patch failed! * Failed Patch: wxwidgets.eclass.patch ! * ( /usr/local/portage/x11-libs/wxGTK/files/wxwidgets.eclass.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/x11-libs/wxGTK-2.8.3.0/temp/wxwidgets.eclass.patch-27678.out
See bugg 178176 for the wxwidgets.eclass.patch plz
wxGTK-2.8.3.0.ebuild + socketfix.patch installs fine on ~amd64, however amule "search tab close crash" bug isn't solved with this... :-/
Paludis doesn't like wxGTK-2.8.3.0.ebuild. Quote: Building dependency list... !!! ERROR in x11-libs/wxGTK-2.8.3.0: !!! In inherit at line 66 !!! Error finding eclass eutils !!! Call stack: !!! * inherit (/usr/libexec/paludis/eclass_functions.bash:66) !!! * source (/usr/local/portage/x11-libs/wxGTK/wxGTK-2.8.3.0.ebuild:4) !!! * ebuild_load_ebuild (/usr/libexec/paludis/ebuild.bash:257) !!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:348) !!! * main (/usr/libexec/paludis/ebuild.bash:381)
wxGTK-2.8.3.0.ebuild + socketfix.patch compiles and works fine for me on x86 (USE="unicode -X -debug -doc -gif -gnome -joystick -odbc -opengl -sdl -stl") x64 (USE="gif unicode -X -debug -doc -gnome -joystick -odbc -opengl -sdl -stl") Would be nice to see this in the portage tree.
compiling fine here too even if pgadmin3 (this bug request started from its need) keeps on failing (bug #148707 was commented appropriately)
Created attachment 121210 [details] wxGTK-2.8.4.0.ebuild
In the latest versions, the docs don't seem to be installed properly - as far as I can tell, it uses wxWidgets-2.8.4-HTML.tar.gz which contains html/*, but the ebuild tries to do ${HTML_S}/docs/html/*
Created attachment 121500 [details] wxGTK-2.8.4.0.ebuild fixed docs.
just an update: we have one or two more things that have to be resolved to give 2.4 the boot, and then I'll post the new 2.6 and 2.8 ebuilds. sorry about the wait, my laptop was without a battery for the last three weeks.
I think the -fvisibility-inlines-hidden CXXFLAG should be filtered out. Neither Code::Blocks or Filezilla (I haven't tried others) want to build against wxGTK after wxGTK has been compiled with it. An error about undefined ~wxColor() occurs.
(In reply to comment #58) > I think the -fvisibility-inlines-hidden CXXFLAG should be filtered out. Neither > Code::Blocks or Filezilla (I haven't tried others) want to build against wxGTK > after wxGTK has been compiled with it. An error about undefined ~wxColor() > occurs. > I confirm: manually removing -fvisibility-inlines-hidden has FINALLY allowed me to successfully emerge wxGTK AND pgadmin3 (whose this bug is related) thank you thank you thank you!
wxGTK-2.8.4.0 ebuild forks fine for me. I wonder if it is also required a new wxwidgets.eclass, cause right now I am unable to build aMule against wxGTK-2.8, failing with this error: ... * wxGTK with gtk2 and unicode support will be used !!! set-wxconfig: Error: Can't find normal or debug version: !!! set-wxconfig: /usr/bin/wxgtk2u-2.4-config not found !!! set-wxconfig: /usr/bin/wxgtk2ud-2.4-config not found !!! You need to emerge wxGTK with unicode in your USE
apply the patch attached to this bug
*** Bug 183509 has been marked as a duplicate of this bug. ***
Why is there still no (at least keyworded) wxGTK-2.8.x eBuild in the official tree
read the 62 comments before yours. see also the bugs this one depends on.
Could someone, please, post a progress update ? It's been 11 months already and, as far as I can tell, there is no user-visible activity.
Latest ebuild doesn't compile. >>> Completed installing wxGTK-2.8.4.0 into /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/ * QA Notice: Pre-stripped files found: * /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/bin/wxrc-2.8 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_gizmos_xrc-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_baseu_net-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_baseu-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_svg-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_adv-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_aui-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_base_net-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_gizmos-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_mmedia-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_fl-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_html-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_xrc-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_ogl-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_gizmos_xrc-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_plot-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_fl-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_gl-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_richtext-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_adv-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_baseu_xml-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_aui-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_core-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_stc-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_gl-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_qa-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_base_xml-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_gizmos-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_richtext-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_mmedia-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_base-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_qa-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_svg-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_html-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_stc-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2_plot-2.8.so.0.1.0 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_core-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_xrc-2.8.so.0.1.1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.0/image/usr/lib/libwx_gtk2u_ogl-2.8.so.0.1.0 >>> Merging x11-libs/wxGTK-2.8.4.0 to / --- /usr/ --- /usr/bin/ >>> /usr/bin/wxrc -> wxrc-2.8 >>> /usr/bin/wx-config -> /usr/lib/wx/config/gtk2-unicode-release-2.8 >>> /usr/bin/wxrc-2.8 >>> /usr/bin/wx-config-2.6 --- /usr/lib/ --- /usr/lib/wx/ --- /usr/lib/wx/config/ >>> /usr/lib/wx/config/gtk2-unicode-release-2.8 >>> /usr/lib/wx/config/gtk2-ansi-release-2.8 --- /usr/lib/wx/include/ --- /usr/lib/wx/include/gtk2-unicode-release-2.8/ --- /usr/lib/wx/include/gtk2-unicode-release-2.8/wx/ >>> /usr/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h !!! Cannot write to '/usr/lib/wx/include/gtk2-ansi-release-2.8'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/x11-libs/wxGTK/wxGTK-2.8.4.0.ebuild merge !!! And finish by running this: env-update * Messages for package x11-libs/wxGTK-2.8.4.0: * To install only wxbase (non-gui libs) use USE=-X
There was a bad symlink in /usr/lib/wx/include/, I deleted it and it compiled and installed then fine.
it looks ok to me too. portage needs this!
I've been using it for awhile cause in 2.6 lot of printer functions are broken in wxpython. Working with the developers at wxwidgets got lot of printer functions working again. Have to keep a local repository so I can have printer working in my app developing. As far as I can tell wxpython and wxGTK 2.8.4 is working fine at least as far as my use.
these ebuilds are nothing close to what is currently being tested or what will go into portage, so advocating them won't help the situation. i hope to have an overlay up soon.
package x11-libs/wxGTK-2.8.4.0 NOT merged Searching all installed packages for file collisions... Press Ctrl-C to Stop * x11-libs/wxGTK-2.6.3.3: '/usr/bin/wx-config-2.6' '/usr/share/aclocal/wxwin.m4' '/usr/share/bakefile/presets/wx_win32.bkl' '/usr/share/bakefile/presets/wx.bkl' '/usr/share/bakefile/presets/wx_unix.bkl' '/usr/share/locale/ca/LC_MESSAGES/wxstd.mo' '/usr/share/locale/da/LC_MESSAGES/wxstd.mo' '/usr/share/locale/cs/LC_MESSAGES/wxstd.mo' '/usr/share/locale/el/LC_MESSAGES/wxstd.mo' '/usr/share/locale/es/LC_MESSAGES/wxstd.mo' '/usr/share/locale/fi/LC_MESSAGES/wxstd.mo' '/usr/share/locale/fr/LC_MESSAGES/wxstd.mo' '/usr/share/locale/id/LC_MESSAGES/wxstd.mo' '/usr/share/locale/hu/LC_MESSAGES/wxstd.mo' '/usr/share/locale/ja/LC_MESSAGES/wxstd.mo' '/usr/share/locale/it/LC_MESSAGES/wxmsw.mo' '/usr/share/locale/it/LC_MESSAGES/wxstd.mo' '/usr/share/locale/nl/LC_MESSAGES/wxstd.mo' '/usr/share/locale/pl/LC_MESSAGES/wxstd.mo' '/usr/share/locale/ru/LC_MESSAGES/wxstd.mo' '/usr/share/locale/sl/LC_MESSAGES/wxstd.mo' '/usr/share/locale/sv/LC_MESSAGES/wxstd.mo' '/usr/share/locale/tr/LC_MESSAGES/wxstd.mo' '/usr/share/locale/uk/LC_MESSAGES/wxstd.mo' '/usr/share/locale/zh_CN/LC_MESSAGES/wxstd.mo' '/usr/share/locale/zh_TW/LC_MESSAGES/wxstd.mo' '/usr/bin/wxrc' '/usr/bin/wx-config'
emerge --info Portage 2.1.3.7 (default-linux/x86/2007.0/desktop, gcc-4.2.1, glibc-2.6.1-r0, 2.6.22-ckg5 i686) ================================================================= System uname: 2.6.22-ckg5 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System release 1.12.9 Timestamp of tree: Fri, 31 Aug 2007 01:47:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17 dev-lang/python: 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi aiglx alsa asf bash-completion berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus dia dri dvd dvdr dvdread eds emboss emf encode esd fam ffmpeg flac fortran fpx gdbm gif glitz gnome gpm graphviz gs gstreamer gtk hal iconv imagemagick isdnlog jpeg jpeg2k kerberos lcms libnotify mad midi mikmod mmx mng mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pcre pdf perl plotutils png postscript pppd python qt3support qt4 quicktime readline real reflection rtsp sdl session speex spell spl sqlite sse sse2 ssl stream svg svga tcpd theora threads tiff tk truetype truetype-fonts type1-fonts unicode vidix vorbis win32codecs wmf x264 x86 xcomposite xinerama xml xorg xscreensaver xulrunner xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 129686 [details] An ebuild failed with the overlay wxwidgets.eclass
(In reply to comment #73) > Created an attachment (id=129686) [edit] > An ebuild failed with the overlay wxwidgets.eclass > Sorry, forgot error log report http://omploader.org/vMm9l/media-video:vlc-0.8.6c-r1:20070831-194033.log
i don't think it's the eclass problem, as you select the stuff but fails in cpp compilation after several files successfully compiled
i have a wxGTK-2.8.4.2 ebuild and patches available @ http://dev.gentoo.org/~dirtyepic/overlay/ if you guys want to give them a try. there might be collisions with 2.6.3.3, but 2.6.4.0 will be okay. i haven't done a lot of testing yet so be wary. we now default to unicode builds and threw out ansi altogether. if your package doesn't work with unicode for some reason, let me or leio know. there shouldn't be any eclass patches or other stuff needed, so if you're using something from an overlay be sure to remove it first. wx-config will be managed by an eselect module which is half written at the moment, so for now just symlink /usr/bin/wx-config-2.8 to /usr/bin/wx-config. there are also some eclass things i need to clean up before this can go into the tree so consider this beta and likely to change a bit.
Tested it out. Won't compile on my system with --with=libtiff in the ebuild. Wait just caught it typo: s/b --with-libtiff Other than that it compiled fine. Haven't tested it out. Cause it won't compile wxpython-2.8.4.2 for me. Get this error: ------------------------------------------------- >>> Emerging (2 of 2) dev-python/wxpython-2.8.4.2 to / * wxPython-src-2.8.4.2.tar.bz2 MD5 ;-) ... [ ok ] * wxPython-src-2.8.4.2.tar.bz2 RMD160 ;-) ... [ ok ] * wxPython-src-2.8.4.2.tar.bz2 SHA1 ;-) ... [ ok ] * wxPython-src-2.8.4.2.tar.bz2 SHA256 ;-) ... [ ok ] * wxPython-src-2.8.4.2.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking wxPython-src-2.8.4.2.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking wxPython-src-2.8.4.2.tar.bz2 to /var/tmp/portage/dev-python/wxpython-2.8.4.2/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/dev-python/wxpython-2.8.4.2/work/wxPython-src-2.8.4.2/wxPython/ ... !!! set-wxconfig: Error: Can't find normal or debug version: !!! set-wxconfig: /usr/bin/wxgtk2u-2.4-config not found !!! set-wxconfig: /usr/bin/wxgtk2ud-2.4-config not found !!! You need to emerge wxGTK with unicode in your USE * Messages for package x11-libs/wxGTK-2.8.4.2: * Applying wxGTK-2.6.3-unicode-odbc.patch ... * Applying wxGTK-2.8.4-collision.patch ... * GNU info directory index is up-to-date. -------------------------------------------- I haven't did the symlink you mention yet and might have to emerge wxGTK then use the old eclass we were using to get wxPython to emerge. I'll try that, but the ebuild needs the typo fixed. Otherwise: Thank you , Thank you!!!
FYI: change the error mention in the ebuild wxGTK-2.8.4.2 compiles and works so far for me. Use the old wxwidgets.eclass were were using and wxpython-2.8.4.2 will compile. The symlink /usr/bin/wx-config-2.8 to /usr/bin/wx-config didn't help with wxpython, but didn't think it would. I started my app developing and told it to use just 2.8.4.2 and working fine so far. THANKS!
(In reply to comment #77) > Tested it out. Won't compile on my system with --with=libtiff in the ebuild. > Wait just caught it typo: s/b --with-libtiff D'oh. I'll fix that. > Other than that it compiled fine. Haven't tested it out. Cause it won't compile > wxpython-2.8.4.2 for me. Get this error: [...] > !!! set-wxconfig: Error: Can't find normal or debug version: > !!! set-wxconfig: /usr/bin/wxgtk2u-2.4-config not found > !!! set-wxconfig: /usr/bin/wxgtk2ud-2.4-config not found > !!! You need to emerge wxGTK with unicode in your USE Ah right, there's no support for selecting 2.8 in the eclass yet. I'll be working on that tonight probably, and I have to remove a lot of the 2.4 garbage like the error above, but in the meantime Ivan's eclass patch should do it. Thanks for testing!
hi guys just to inform that version 2.8.5 is out. maybe it helps in something. I really love to see this ebuild on portage in a near feature. It's already a must for amule CVS for example.
Created attachment 131134 [details] wxGTK-2.8.5.ebuild based on previous one, paths and versions updated, here it works but Ive not tested all the USEs
we really need a bump in main tree. i got no issues with 2.8.4
(In reply to comment #82) > we really need a bump in main tree. > > i got no issues with 2.8.4 I do have an issue with the ebuilds that are here, and work is ongoing on a full and clean version (Comment #76). And until I have issues, it isn't going into the tree. Everyone please stop asking and reminding unless you provide things like the missing eselect module that Ryan is working on.
i tested myself 2.8.5 ebuild and i noticed that: -It is going into tree -Emerge does not clean the 2.6 version -For now it is now compiling with unicode -is it compiling two times? (?) What i'm going to do now (and post results later): -emerge -C wxGTK (emerge had show: x11-libs/wxGTK selected: 2.6.4.0 2.8.5 ) strange, isn't? -re emerge 2.8.5 -test
Done. Everything perfect! Send it to main tree
This has been said multiple times already, but to reiterate, testing the ebuilds attached to this bug will not help getting it into the tree. The version of the ebuild that will be considered for the tree is here: http://dev.gentoo.org/~dirtyepic/overlay/ I suggest those whom are interested should test Ryan's ebuild.
just a question for comment 76: why do we need eselect? do you want 2.6 and 2.8 to be slotted and live together? not just a 2.8 version bump?
(In reply to comment #86) > The version of the ebuild that will be considered for the tree is here: > http://dev.gentoo.org/~dirtyepic/overlay/ Is that a layman overlay? Simply adding doesn't work and it is not listed in the ... list either.
(In reply to comment #87) > just a question for comment 76: > why do we need eselect? do you want 2.6 and 2.8 to be slotted and live > together? not just a 2.8 version bump? Obviously... We are not going to start waiting on being able to add 2.8 to the tree till all the apps work with it. You'd see 2.8 in the tree in a year if we don't keep SLOTting it. Most of the delays are related to getting the slotting handling situation fixed once and for all at ebuild/eclass level before we add the new SLOT version. (In reply to comment #88) > (In reply to comment #86) > > The version of the ebuild that will be considered for the tree is here: > > http://dev.gentoo.org/~dirtyepic/overlay/ > Is that a layman overlay? Simply adding doesn't work and it is not listed in > the ... list either. It seems to currently be a apache webspace that just has the ebuild, eclass, and such on there. Browse with your browser and wget what you need in your personal overlay. If you don't know how, maybe you should wait till it is in the official tree
(In reply to comment #87) > just a question for comment 76: > why do we need eselect? do you want 2.6 and 2.8 to be slotted and live > together? not just a 2.8 version bump? because there can only be one /usr/bin/wx-config, which is what packages use to figure out what wx-libraries to link to. it works very similar to pkg-config if you're familiar with that. in the past, multiple SLOTS of wxGTK just clobbered each other and you'd have 2.6 packages linking with wxGTK-2.4 and vice versa, leading to a lot of ugly bugs. the new eclass works out a way to prevent this from happening with ebuilds. the eselect module will do the same thing for packages built outside of portage, giving people who develop wxGTK apps a way to switch between SLOTS when building and testing their programs. without these things we can't install both versions side-by-side without collisions and therefore cannot put 2.8 in the tree. if i could have done so, i would have long ago, and closed this godforsaken bug report. ;P yes, my overlay is just a bunch of files you actually have to manually download (*gasp* that's so 1990's!). i've been bugging the o.g.o people to give me a dev overlay but i haven't gotten a response yet.
really... why not to release for now? masked at least!
(In reply to comment #91) > really... why not to release for now? masked at least! your mail address and you talkin about amule make me think you are an Adunanza user. if so, you can use my overlay (it already includes wx 2.8.5 ebuild), only for fastweb internal users (italian ISP), look at adu's forum. If Im wrong..sorry ;)
what is andunanza? also: masked don't hurt anyone!
(In reply to comment #93) > what is andunanza? > also: masked don't hurt anyone! > guys, please, this is not a chat. stay on-topic. post ONLY messages relevant to this bug entry
FYI: available in my overlay (layman -ka luke-jr)
Created attachment 131685 [details] Buildlog - non-pic relocation Ebuild from Luke's overlay: advdll_calctrl.o: relocation R_X86_64_PC32 against `wxColour::IsOk() const' can not be used when making a shared object; recompile with -fPIC Buildlog attached.
please don't use -ftree-vectorize in gcc-4.1. it's severely broken. though i would be interested if removing -fvisibility-inlines-hidden fixes it.
Created attachment 131741 [details] Buildlog - non-critical errors? Without inlines-hidden and tree-vectorize it finishes, but there is a huge amount of errors which don't seem to cause the build to fail: Examples: /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/gtk2_build_unicode/bk-deps x86_64-pc-linux-gnu-g++ -c -o ogldll_oglmisc.o -I.pch/wxprec_ogldll -D__WXGTK__ -I/var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/ogl/../../include -DWXUSINGDLL -DWXMAKINGDLL_OGL -fPIC -DPIC -DWX_PRECOMP -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/gtk2_build_unicode/lib/wx/include/gtk2-unicode-release-2.8 -I/var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pipe -O2 -march=athlon64 -fno-strict-aliasing /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/ogl/oglmisc.cpp /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/ogl/oglmisc.cpp:23:5: warning: "wxUSE_PROLOGIO" is not defined /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/ogl/oglmisc.cpp:50: error: no matching function for call to ‘wxList::wxList(wxKeyType)’ /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/include/wx/list.h:1182: note: candidates are: wxList::wxList() /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/include/wx/list.h:1182: note: wxList::wxList(const wxList&) make[1]: *** [ogldll_oglmisc.o] Error 1 /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/fl/garbagec.cpp: In function ‘GCItem& node_to_item(wxNode*)’: /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/fl/garbagec.cpp:30: error: invalid use of undefined type ‘struct wxObjectListNode’ /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/include/wx/list.h:57: error: forward declaration of ‘struct wxObjectListNode’ /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/fl/garbagec.cpp: In member function ‘void GarbageCollector::DestroyItemList(wxList&)’: /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/fl/garbagec.cpp:42: error: cannot convert ‘wxObjectList::compatibility_iterator’ to ‘wxNode*’ in initialization /var/tmp/portage/x11-libs/wxGTK-2.8.4.2/work/wxPython-src-2.8.4.2/contrib/src/fl/garbagec.cpp:48: error: invalid use of undefined type ‘struct wxObjectListNode’ A log is attached.
-ftree-vectorize is bad because it creates wrong code - misaligned SSE instructions that are hard to hit but pop up in the damnedest of places. until you recompile your entire box without it, i'm not interested.
That ebuild from Luke's overlay is not intended to work out of the box, is it? Since several packages (Audacity, wxMaxima, Hugin) request 2.6 explicitly via WX_GTK_VER even though they require only >=2.6.
Created attachment 131887 [details] Buildlog - non-critical errors - try 2 Recompiled everything, still the same errors. Buildlog attached again (compressed since otherwise too big).
I believe this bug doesn't depend on 193983 as far as the only problem now is the eclass that manages wxGTK versions.
(In reply to comment #80) > just to inform that version 2.8.5 is out. 2.8.6 is here: http://biolpc22.york.ac.uk/pub/2.8.6/ Should be announced this weekend.
it would appear over at wxpython.org the new sources have been bumped.
there is a mistake in wxwidgets (wxPython) with USE="odbc" I'm using 4.2.0 gcc /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/db.cpp: In member function 'bool wxDb::Open(const wxString&, void*, bool)': /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/db.cpp:873: error: ambiguous overload for 'operator=' in '((wxDb*)this)->wxDb::outConnectionStr = outConnectBuffer' /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:676: note: candidates are: wxString& wxString::operator=(int) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:956: note: wxString& wxString::operator=(wxChar) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:970: note: wxString& wxString::operator=(const wxWCharBuffer&) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:660: note: wxString& wxString::operator=(const wxString&) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/db.cpp: In member function 'bool wxDb::Open(wxDb*)': /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/db.cpp:978: error: ambiguous overload for 'operator=' in '((wxDb*)this)->wxDb::outConnectionStr = outConnectBuffer' /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:676: note: candidates are: wxString& wxString::operator=(int) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:956: note: wxString& wxString::operator=(wxChar) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:970: note: wxString& wxString::operator=(const wxWCharBuffer&) <near match> /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/include/wx/string.h:660: note: wxString& wxString::operator=(const wxString&) <near match> make: *** [odbcdll_db.o] Error 1 make: *** Waiting for unfinished jobs.... /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/dbgrid.cpp: In member function 'virtual void wxDbGridTableBase::ValidateRow(int)': /var/tmp/portage/x11-libs/wxGTK-2.8.6.0/work/wxPython-src-2.8.6.0/src/common/dbgrid.cpp:666: warning: unused variable 'ret'
could i ask people having problems with wxGTK/python versions not yet in the tree to post in the Unsupported Software section of the forums, and not here? maybe start a general wxGTK-2.8 thread. this bug is getting way too cluttered. as an update, i'm trying to get the new eclass into the tree ASAP. if you want to test it out it's in my overlay. http://overlays.gentoo.org/dev/dirtyepic/browser/eclass/wxwidgets.eclass if you have any problems or suggestions, post them to bug #178824, and _not_ here. ;) i think that (hopefully) all that stands in the way after the eclass is merged is the eselect module.
Interested in helping test and etc. About to add FlameRobin 0.8.0 into tree. It ideally wants 2.8.6, but still supports 2.6 as well. I believe Ryan is leading this, so just let me know what I can do to help.
i have an overlay in layman now with wxGTK-2.8.6.0 and the new eclass. documentation is in the eclass. portage use should work as advertised. building apps outside of portage might not be working at the moment. there are notes in /usr/bin/wx-config if you want to try it. http://overlays.gentoo.org/dev/dirtyepic/browser if you don't use layman. there's some GCC svn ebuilds in my overlay as well, but they're not keyworded so they shouldn't mess with anything. ;) let me know if you run into any problems. :)
How is it intended to handle the situation where a package works fine with 2.6 _and_ 2.8 (i.e. could DEPEND on >=2.6)? WX_GTK_VER seems to enforce a specific version, without support for a range or some virtual like 'latest'.
(In reply to comment #109) > How is it intended to handle the situation where a package works fine with 2.6 > _and_ 2.8 (i.e. could DEPEND on >=2.6)? WX_GTK_VER seems to enforce a specific > version, without support for a range or some virtual like 'latest'. It's kind of on purpose not designed to deal with that. You pick. Until wxGTK is at a lower visibility level the application can have a stable version that uses 2.6 and then a newer revision that uses 2.8. Then once 2.8 goes stable that revision of the app can go stable as well. Doing ranges of SLOTs is not well workable at this point for dependency checking. For example if it depends on a range of 2.6 or 2.8, the user will never get offered a rebuild of the application of the newer and better wxGTK library for the application to benefit (and often wx apps make conditional code to work with either and there is a lot of better stuff used in case 2.8 is available - like the filechooser buttons, and such). Well, unless there's a revbump and we are back to the initial suggestion of how this should be handled :)
i'm testing this overlay and so fine so good. I forced vlc and amule ebuilds to compile against wxgtk286 and all work fine. but... eselect dont show module for this ebuild
(In reply to comment #111) > but... eselect dont show module for this ebuild that's because i haven't written it yet. ;) (In reply to comment #109) > How is it intended to handle the situation where a package works fine with 2.6 > _and_ 2.8 (i.e. could DEPEND on >=2.6)? WX_GTK_VER seems to enforce a specific > version, without support for a range or some virtual like 'latest'. like leio said, this is on purpose. wxGTK's shared libraries are versioned by major.minor. consider the situation where a package depends on >=2.6, the user builds against 2.6, installs 2.8, and removes 2.6. borkage. major version bumps also have a history of breaking packages. one of the many reasons this bug has been open for so long was packages depending on >=2.6 that break with 2.8. in order to move ahead we've locked everything in the tree to 2.6. once 2.8 is in the tree it's up to the maintainer to decide what to use.
(In reply to comment #112) > in order to move ahead we've locked everything in the tree to 2.6. Maybe I misunderstood that. On a sync from this very moment, striped of duplicates: $ grep -R '>=x11-libs/wxGTK' /usr/portage/metadata/cache/ | sed 's/\/usr\/portage\/metadata\/cache\///' | sed 's/:.*//' media-gfx/hugin-0.7_beta4 media-gfx/hugin-0.5_rc1-r2 media-gfx/hugin-0.6.1 media-gfx/hugin-0.5 media-gfx/comical-0.8 dev-util/rapidsvn-0.9.3 dev-util/rapidsvn-0.9.4 dev-python/wxpython-2.6.3.3 dev-python/wxpython-2.6.4.0 media-video/vlc-0.9.0_alpha20071009 media-video/vlc-0.8.6c dev-haskell/wxhaskell-0.9.4
i was waiting on those. fixed now.
Just out of curiosity (not meant to push at all. I understand "when it's ready, it's ready"), how's the progress of this coming? The eclass stuff has hit the tree, so I'm wondering what is left. Do you just need more testing done? Something that mere mortals like me could help with? ;-) Thanks for all the work that you have put into this. It will help quite a few apps. ---Alex
http://overlays.gentoo.org/dev/dirtyepic/wiki/WikiStart
almost there. the eselect module is in the tree, masked until it gets keyworded. i just have to fix some wxpython collisions and do some testing now.
wxGTK-2.8.6.1 is now in the tree. it's masked until eselect-wxwidgets is keyworded (bug #199594). please give it a working over.
(In reply to comment #118) > wxGTK-2.8.6.1 is now in the tree. it's masked until eselect-wxwidgets is > keyworded (bug #199594). please give it a working over. > wxGTK-2.8.6.1 in portage does not have unicode useflag. Is there any specific reason for that? Because I have this die message: x11-libs/wxGTK-2.8.6.1 does not actually support the unicode USE flag!
(In reply to comment #119) > (In reply to comment #118) > > wxGTK-2.8.6.1 is now in the tree. it's masked until eselect-wxwidgets is > > keyworded (bug #199594). please give it a working over. > > > wxGTK-2.8.6.1 in portage does not have unicode useflag. Is there any specific > reason for that? Because I have this die message: > x11-libs/wxGTK-2.8.6.1 does not actually support the unicode USE flag! > Here is your answer: http://psykil.livejournal.com/tag/gentoo
(In reply to comment #119) > wxGTK-2.8.6.1 in portage does not have unicode useflag. Is there any specific > reason for that? Because I have this die message: > x11-libs/wxGTK-2.8.6.1 does not actually support the unicode USE flag! 2.8 uses unicode by default, so that check should be removed from the ebuild of the app you're trying to compile.
Works for me too, with the packages on bug #182249 and python 2.5.
Thanks for your answers. Now that 2.8 uses unicode by default, I adjusted the ebuild. Now everything is fine.
Created attachment 138258 [details] Install Release and Debug versions when debug use flag is enable This ebuild compile and install Release and Debug versions when debug use flag is enable
i've gotten a few requests now for side-by-side release/debug. i'll revisit it at a later time. right now i just want to get this out. the new wxWidgets-2.6 stuff is now unmasked. i'll wait about a week before unmasking 2.8.
Fixed.
