* Re: [gentoo-dev] Willing to support the wxWidgets maintainers if any
2006-12-12 14:46 [gentoo-dev] Willing to support the wxWidgets maintainers if any Florian Kamm
@ 2006-12-12 20:40 ` Mart Raudsepp
0 siblings, 0 replies; 2+ messages in thread
From: Mart Raudsepp @ 2006-12-12 20:40 UTC (permalink / raw
To: gentoo-dev; +Cc: Florian Kamm
[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]
On Tue, 2006-12-12 at 15:46 +0100, Florian Kamm wrote:
> Hello,
Hey,
> I am currently developing applications using the great wxWidgets GUI
> framework and I noticed that the appropriate gentoo packages are not
> very actively maintained.
Yeah, I've been concentrating on GNOME-2.16 more (other than being lazy
and slacking in general), but that's handled now and I can move
concentration to wxWidgets for a while again.
> So I think about contributing either to the
> maintenance of already existing packages (including the wxWidgets
> library itself) or to the development of new ebuilds concerning projects
> which use the wxWidgets library.
> E.g. some work could be done to support different slots of the wxWidgets
> library (coexisting release and debug versions and/or coexisting major
> releases). This might yield to the development of an eselect script
> allowing to switch from one to an other wxWidgets library version or to
> switch from the debug to the release version. This is already supported
> by the wx-config utility tool.
To a certain extent of "supported".
Anyhow, the plan of action for wxWidgets:
1) Get two things handled for wxGTK-2.6.3.3 (a patch I need to add for a
build fix for some machines and looking if we need to restrict MAKEOPTS
to -j1 again) and request stabilization of wxGTK-2.6.3.3 and
wxpython-2.6.3.2 (as the current latest stable versions mismatch badly,
this is a big improvement - the subrelease [fourth number] mismatch is
purely cosmetical, while a mismatch of minor version number can cause
real problems)
2) Finish up the fixes for wxpython ebuild and add them together with
2.6.3.3. Stabilize it at some point.
3) Phase out wxGTK and wxpython 2.4 versions. Port or treeclean
applications that don't work with 2.4; get rid of 2.4
4) Probably at some point add 2.6.4 - upstream is planning to release it
soon for some important bug fixes for applications that haven't ported
to 2.8 yet (see bug 151528 for such an example).
5) Work towards adding 2.8 to the tree, getting some outstanding
problems sorted out together with the new SLOT, most notably file
collisions and multi-version handling
5a) Patch translation files to be versioned, as to not have collisions
from wxstd.mo files, but instead have wxstd-2.8.mo for 2.8 (no need to
patch 2.6, as 2.4 is going out and then 2.6 is the only with just
wxstd.mo)
5b) Introduce an eselect module as you suggested as well. Make it handle
the wx-config symlink for users and provide wx-config and wxwin.m4 files
from it; perhaps some other files too. Make it block all versions before
the new 2.6 and 2.8 versions that depend on it - this also ensures users
will unmerge wxGTK-2.4 SLOT out of their system, as it continues causing
the problems we are trying to solve.
5c) Check the dependencies for apps - ensure that those that have
>=wxGTK-2.6 really mean it, and same with =wxGTK-2.6*, and so on
5d) Figure out the automatic version selection through wxwin.m4 for
applications - they are supposed to all honor what we are doing to
select the version, and as such not rely on what the wx-config symlink
points at. This way wx-config would become strictly a non-portage thing
for convenience, and easy version choosing for self-compiled apps
through the eselect module
6) Fix the mess that is LDFLAGS handling in wxWidgets configure.in - it
adds user set LDFLAGS to wx-config outputs and breakage ensues. To fix
it, configure.in should use a different variable for things it adds
itself, and use that only for wx-config, while for the compilation of
the library both the extra variable and (user set) LDFLAGS would be
used.
So if you want to help with any of these steps or more (we maintain some
apps and other libs too), feel free to discuss this with me. I prefer
IRC communication for things like that, but e-mail correspondence is
fine too, just slow. I'm leio on irc.freenode.net network.
> I will be grateful to anyone who could help me in my intention to become
> a gentoo developer or point me to the right place to discuss about.
That doesn't sound bad :)
We'd have to look a mentor for you then, but I'm sure that will not a
problem.
For starters we can get things done without developer status though and
then at some point I'd be willing to vouch for you, if you do a good
job ;)
--
Mart Raudsepp
Gentoo Developer; wxwindows and gnome herd
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread