Bug 145884 - x11-libs/wxGTK-2.8 version bump
|
Bug#:
145884
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: wxwidgets@gentoo.org
|
Reported By: cedk@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
http://thread.gmane.org/gmane.linux.gentoo.devel/44736/focus=44737
|
|
Summary: x11-libs/wxGTK-2.8 version bump
|
|
Keywords: PMASKED
|
|
Status Whiteboard:
|
|
Opened: 2006-09-01 11:21 0000
|
Created an attachment (id=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 an attachment (id=100779) [details]
This is an ebuild made from wxGTK-2.6.3.3.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
*** 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. ***
*** 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 an attachment (id=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.
Created an attachment (id=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 an attachment (id=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 an attachment (id=105607) [details]
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
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.
*** 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)
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/*
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
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.
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 #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 an attachment (id=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 an attachment (id=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.
I believe this bug doesn't depend on 193983 as far as the only problem now is
the eclass that manages wxGTK versions.
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
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.
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.
