Bug#877871: RFP: pyside2 -- Python bindings for Qt5
Control: tag -1 pending
Hello all,
we have made good progress on the pyside2 packaging. Yesterday we
had working packages built against Qt 5.10 that we managed to use to
rebuild freecad and the application was working.
We worked in our own repository at the start:
https://salsa.debian.org/freexian-team/pyside2
But I just pushed this to the team's official repository. You are more
than welcome to review the package. The upstream build system is based
on Python's setup.py but it then executes lots of custom code relying on
cmake to build everything.
We use pybuild because it does the right thing to build against the
various Python versions but the upstream installation procedure is not
really able to cope with the logic of building the same thing for
different python versions and then installing the different set of file.
So we just used dh_install (and not pybuild's install procedure) to install
the files out of some intermediate directories used by upstream. We
used dh-exec to be able to install in multi-arch directories via
dh_install.
I hope the package will continue to build once the Qt 5.11 transition is
over, right now it doesn't because unstable is in flux with the transition
that just started. It might build against experimental, I haven't tried.
On Fri, 11 May 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> It is worth to note that pyside2 will probably use some Qt's private headers.
We do depend on qtbase5-private-dev, right.
> - If Pyside2 uses private headers it will end up depending in qt<foo>-abi-x-y-
> z, that's the way we track packages using private headers (which includes qt
> submodules) and allows us to do very smooth transitions whenever possible.
> That only means that it will need to get rebuilt whenever we ship a new
> upstream version.
Some of the generated packages depend on "qtdeclarative-abi-x-y-z". That's
the only occurrence of this pattern.
> All that being said, if the package is kept under qt/ following our repo style
> it's easier for us to jump in in case it's needed (for example, if we are
That's definitely the goal here. I have no long term interest here. The
initial packaging of pyside has been funded by a customer who is using
freecad and wanted to keep the package in Debian. We will continue
to help for as long as the customer is willing to pay our work but
we definitely want the package to be under the team's umbrella so that
it survives our efforts.
On Sat, 12 May 2018, Maximiliano Curia wrote:
> I've created: https://salsa.debian.org/qt-kde-team/qt/pyside2
Pushed our work here.
> They are somewhat documented in http://pkg-kde.alioth.debian.org/, I would
> say: http://pkg-kde.alioth.debian.org/gitguidelines.html -> but the tagging
This moved here:
https://qt-kde-team.pages.debian.net/
https://qt-kde-team.pages.debian.net/gitguidelines.html
I honestly find those policies very counter-productive with a high
setup cost and lots of divergence compared to usual practices in most
other teams. Anyway, I can stick to them for this package but right
now I'm maintaining pyside2 with git-buildpackage in a usual
merged-with-upstream branch and I will just cherry-pick my changes
to the debian-only branch pushed to your repository.
BTW, the policy of requiring a changelog entry in each commit goes very
much again the stated goal of "reduce conflicts in debian/changelog when
cherry-picking and merging between branches".
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Reply to: