Bug 552122 – =dev-python/sip-4.18 =dev-python/PyQt4-4.11.4-r1 =x11-libs/qscintilla-2.9.2-r1 =dev-python/qscintilla-python-2.9.2-r1 stable request

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Davide Pesavento (RETIRED) 2015-06-14 19:01:08 UTC]

It is time.

[Comment 1 Patrice Clement 2015-06-14 19:14:07 UTC]

Davide, I was discussing it with Mike earlier on in #gentoo-python. If these packages are platform independent, consider making use of the ALLARCHES policy in order to take a load off arch teams and speed up the stabilising process.

[Comment 2 Davide Pesavento (RETIRED) 2015-06-14 19:21:24 UTC]

It depends on the definition of platform independent, but since all four of them are big piles of C/C++, I'd say that they're not good candidates for ALLARCHES ;)

[Comment 3 Michael Palimaka (kensington) 2015-10-18 17:44:42 UTC]

There seems to be no progress regarding the pyqtconfig issue in various consumers.

I saw another down discuss continuing to use the new configure script, but still running the legacy PyQt4 one just to generate and install pyqtconfig. Does that seem reasonable?

[Comment 4 Davide Pesavento (RETIRED) 2015-10-18 22:24:37 UTC]

(In reply to Michael Palimaka (kensington) from comment #3)
> I saw another down discuss continuing to use the new configure script, but
> still running the legacy PyQt4 one just to generate and install pyqtconfig.
> Does that seem reasonable?

Interesting idea, I think it could even work. Did this other downstream only discuss about it or was it actually implemented?

[Comment 5 Davide Pesavento (RETIRED) 2015-10-18 22:39:51 UTC]

On second thought, looking at the blockers...

/calibre: we just need to stabilize any 2.x version. This requires PyQt5 stable on amd64 and x86, but this bug also needs PyQt5 stable, so we have to get that done one way or the other.

/PyQtMobility: can simply be treecleaned.

/pyqwt: needs patching, but unfortunately upstream seems dead or inactive. I briefly looked at its build system, and it looks quite sane/readable.

So I was wondering how much easier implementing the proposed hack would be, compared to just fixing pyqwt...

[Comment 6 Frank Krömmelbein 2016-02-05 11:14:31 UTC]

Still no progress here after 3.5 months...
To solve this Gordian Knot, why not simply treeclean PyQtMobility AND pyqwt and then continue the stabilization process?

[Comment 7 Davide Pesavento (RETIRED) 2016-02-06 02:47:38 UTC]

PyQtMobility has been last rited, but we can't simply treeclean pyqwt, it has several reverse deps.

[Comment 8 Pacho Ramos 2016-05-18 13:02:19 UTC]

(In reply to Davide Pesavento from comment #5)
> /pyqwt: needs patching, but unfortunately upstream seems dead or inactive. I
> briefly looked at its build system, and it looks quite sane/readable.
> 
> So I was wondering how much easier implementing the proposed hack would be,
> compared to just fixing pyqwt...

I don't find the references to the problems with pyqwt in the current blockers... are the problems the one from bug 578746 ?

[Comment 9 Davide Pesavento (RETIRED) 2016-05-18 15:54:26 UTC]

(In reply to Pacho Ramos from comment #8)
> I don't find the references to the problems with pyqwt in the current
> blockers... are the problems the one from bug 578746 ?

bug 536948

[Comment 10 Davide Pesavento (RETIRED) 2016-05-18 16:03:50 UTC]

(In reply to Davide Pesavento from comment #5)
> /pyqwt: needs patching, but unfortunately upstream seems dead or inactive. I
> briefly looked at its build system, and it looks quite sane/readable.
> 
> So I was wondering how much easier implementing the proposed hack would be,
> compared to just fixing pyqwt...

FTR I recently tried this, i.e. fixing pyqwt build system to not rely on pyqtconfig, but unfortunately I hit a wall in sipconfig which makes the whole approach infeasible :/

[Comment 11 Pacho Ramos 2016-05-19 14:27:16 UTC]

OK, the RESOLVED FIXED status for that bug confused me :)

[Comment 12 Pacho Ramos 2016-05-19 14:30:17 UTC]

Did you take a look to the ArchLinux tweaks for their qtconfig?
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python2-pyqwt

Maybe they could help :/

[Comment 13 Michael Palimaka (kensington) 2016-05-21 19:12:16 UTC]

(In reply to Pacho Ramos from comment #12)
> Did you take a look to the ArchLinux tweaks for their qtconfig?
> https://git.archlinux.org/svntogit/community.git/tree/trunk/
> PKGBUILD?h=packages/python2-pyqwt
> 
> Maybe they could help :/

Interesting, looks like they are bundling a copy of the old pyqtconfig.py.

[Comment 14 Davide Pesavento (RETIRED) 2016-07-10 18:14:35 UTC]

Adding =dev-python/sip-4.18 to the stabilization list

[Comment 15 Davide Pesavento (RETIRED) 2016-07-10 18:35:50 UTC]

Arches, please proceed. The stabilization matrix is:

dev-python/sip-4.18                   alpha amd64 arm hppa ia64 ppc ppc64 x86
dev-python/PyQt4-4.11.4-r1            alpha amd64 arm      ia64 ppc ppc64 x86
x11-libs/qscintilla-2.9.2             alpha amd64          ia64 ppc ppc64 x86
dev-python/qscintilla-python-2.9.2    alpha amd64          ia64 ppc ppc64 x86

[Comment 16 Michael Palimaka (kensington) 2016-07-13 21:22:16 UTC]

amd64/x86 stable

[Comment 17 Markus Meier 2016-08-05 17:16:06 UTC]

arm stable

[Comment 18 Tobias Klausmann (RETIRED) 2016-09-22 16:53:25 UTC]

Stable on alpha.

[Comment 19 Jeroen Roovers (RETIRED) 2016-10-02 10:08:05 UTC]

Stable for HPPA PPC64.

[Comment 20 Agostino Sarubbo 2016-12-28 08:38:25 UTC]

Dear Maintainer (or who is mainly involved in this stable request),

This is an auto-generated message that will move the current component to the new component Stabilization.
To ensure that the stabilization will proceed correctly, please fill the fields "Atoms to stabilize" and "Runtime testing required" as described here:
https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa

[Comment 21 Michael Palimaka (kensington) 2016-12-28 16:08:24 UTC]

An automated check of this bug failed - the following atoms are unknown:

x11-libs/qscintilla-2.9.2
dev-python/qscintilla-python-2.9.2

Please verify the atom list.

[Comment 22 Michael Palimaka (kensington) 2016-12-28 19:18:08 UTC]

An automated check of this bug succeeded - the previous repoman errors are now resolved.

[Comment 23 Agostino Sarubbo 2016-12-30 11:12:26 UTC]

ia64 stable

[Comment 24 Agostino Sarubbo 2017-01-01 12:46:05 UTC]

ppc stable. Closing.