Hi dear Release Team, Following the previous discussion in http://lists.debian.org/debian- release/2010/08/msg00062.html I uploaded new upstream versions of the following packages (all Build-Depending in chain without any reverse depends) to experimental: * apiextractor 0.7.0-1~exp2 * generatorrunner 0.6.0-1~exp0 (B-D on a ) * shiboken 0.4.0-1~exp1 (B-D on a,g ) * pyside 0.4.0-2 (B-D on a,g,s ) Actual sid/squeeze versions are outdated and ships some RC bugs: - #590302 on apiextractor that impacts shiboken which then prohibits armel and sparc build for the whole chain; - #588556 (= #588558) on pyside, which is a segfault in the QtGui module (aka nearly unuseable) Hence, the versions actually in experimental fix those 3 RC bugs and "enable" two more architectures: armel and sparc (the first being particularily important for PySide). The fix for #590302 is backportable, but the fix for #588556 is hardly, as the codebase changed "quite a lot". == What would this bring to Squeeze? == Nokia (new Qt owners) released a PyQt [GPL] replacement: PySide [LGPL] (together with a set of tools to build it: apiextractor, generatorrunner, shiboken). No other package depends on pyside (python-pyside.* binary packages) right now, but since PySide has compatible API with PyQt and it's used in Maemo, I think it is worth to get it into Squeeze. Furthermore, as the OpenBossa guys (PySide's upstream) are now "approaching" the "1.0" release, the API is slowly stabilizing at the cost of "often" bumping the SOVERSION (in many cases "just to be sure", but not necessarily for good reasons). So in short, I think that having the "most recent possible" version of PySide and its B-D chain is good for Squeeze, with the extra bonus that nothing depends on PySide (yet). And having the most recent PySide in Squeeze will allow users to build new things on PySide (which would not be the case with a segfault'ing QtGui). [ Note that I am very aware of the freeze and what that means, still I think that PySide as almost-zero-risk (no B-D) is worth discussing. ] So from here I see some options (with my opinion in parentheses) i) Removing PySide from Squeeze (I think it would be sad). ii) Keeping the current PySide in Squeeze and request the maintainer (me) to provide patched versions (This option needs hard work for me, with unknown success chances. The fallback being the removal (i) doesn't help.) iii) Allow the PySide version currently in experimental to unstable->squeeze (This is IMHO the easiest way to fix the RCs while still being zero-risk and also implies an "almost-1.0" PySide for Squeeze, which would be satisfactory for both upstream and myself.) iv) Allow me to upload the latest upstream releases to experimental and report the discussion to later times, with more recent upstream releases (This is obviously the preferred solution for upstream who doesn't want "outdated" versions in distributions. I very much understand why allowing this could not be possible. Furthermore, two updates that upstream wanted in are already in as patches [0,1], with one "cheated in" (it breaks the API, but I kept the SOVERSION) So personally I would rank the options from latter to first: iv) is preferable, i) is the least preferable. So the decision is now in your hands and I thank you in advance for taking it! Cheers, OdyX [0] http://patch- tracker.debian.org/patch/series/view/apiextractor/0.7.0-1~exp2/u_d13ce132_non_final_method_is_not_necessarily_polymorphic.patch [1] http://patch- tracker.debian.org/patch/series/view/shiboken/0.4.0-1~exp1/u_1eda671_fix_type_resolver_algorithm.patch -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens didier@raboud.com
Attachment:
signature.asc
Description: This is a digitally signed message part.