I finally got around to bumping wxGTK in the tree to with all the changes like migrating completely away from using the wxlib.eclass, fixes for stuff that I considered blockers for considering being a stabling candidate, and so on.

As there seem to be reasons to shorten the 30 day stabling policy a little bit for this one, I would appreciate testing success stories in my leio@g.o mail, and failure stories in bugzilla ASAP 🙂

Next stop, wxpython- I would say tomorrow, but judging on the date I gave for wxGTK, I will not say one this time.

Oh, and if I were a maintainer of a package that has any version that depends on wxGTK-2.4 left in the portage tree, I would take care of cleaning out old ebuilds and making sure things work against wxGTK-2.6, as next next stop is nuking wxGTK/wxpython-2.4.x out of the tree for a well deserved permanent retirement.

First post

Hey, hey.

So I decided I should do this first blog on this planet.g.o aggregated blog.
You can find my older blog posts from http://advogato.org/person/leio/ if interested for some reason.

I will be screwin^Wmaintaining wxWidgets related packages in the wxwindows herd (I’ll get that name renamed to wxwidgets soon). Some might have seen my dirty fingers in the gnome-experimental overlay already, too – we’ll see how soon I can get more involved in that front.
But first, I need to finish fixing the sad state that wxGTK, wxpython and co have been for a while in Gentoo now. I got them both already bumped to back in April via proxy, but I don’t feel comfortable about requesting stabilization of them as of yet.
First, I found out that me moving to using wxPython tarballs (which include all the necessary C++ code as well, or so I thought) – to get updates more often, have a matching wxGTK/wxpython version always and other benefits – made the wxrc util disappear (thanks to Vaclav Slavik for notifying me in this matter). Turned out wxPython source packages didn’t include the utils/ folder and the wxGTK build system didn’t care if it existed or not – it simply silently didn’t build/install it. Whoops. wxPython author fixed that up quickly on request, and bumping to will fix that automatically.
Secondly, I found that I broke ABI with the package source tarball switch. One virtual method was added to a widely used stand-alone class (the list control). Turned out a couple patches was applied to the sources before the tarball creation, with the patches nicely in a subdirectory. So just a reverse patching in src_unpack and voila – stable upgrades won’t see any incompatible ABI changes (I will make checks, and hopefully right :>>). I hope ~arch users won’t hate me too much, but it’s why it’s called unstable, and in reality I never saw any reports on this causing problems. I suppose adding something to the vtable doesn’t break too many common systems, or it might be from the fact that people (upstream application ones) don’t derive from that class all that often to care about that particular vtable.
Thirdly, after finding out why the wxDebugReport class was not built in Gentoo, I concluded that using the wxlib.eclass by the wxGTK ebuild is just plain broken conceptually. The eclass disables functionality for all 2.6 versions just because one version happened to be broken. wxDebugReport, accidentally precompiled headers (compile time), forcing of one make process (I’ve used -j2 on wxGTK local builds for over 2 years now…), and other things. So I have decided to migrate the ebuild over to not use the eclass anymore before I can feel comfortable asking stabilization of any wxGTK package. This migration is kind of done, but now there is still some afterwards cleaning up to do, fixing the MAKEOPTS ignoring, and so on. I will much later look into resurrecting the eclass as a new version, when it’s time to look into making the initial idea why the eclass was created – multiple wxWidgets ports in the tree, sharing some building code in the eclass – a reality. As it was right now, just wxGTK ebuild used it, and the eclass contained all that nastyness that doesn’t work for a wide range of different package version.

As for wxpython, it’s mostly just about fixing the mess that is lack of python_mod_compile and python_mod_cleanup usage, which commonly leads to wxpython being broken on an upgrade if the USE flags or SLOT changed in the case of wxpython multiversion support.

Of course while doing the bump, I hope to fix as many bugs as I can without holding it off for too long.

Now to get back to working!