Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Hi,

On Mon, 30 Jul 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> You might want to consider suscribing to pkg-kde-talk@a-l.d.n (CCed), it's a 
> *very low* traffic mailing list in which we coordinate some stuff.

Done.

> reason and time proved us to be right as many came in asking for it. Please 
> consider removing this meta packages in your next upload.

Done. We kept them because they were present in pyside 1. But we don't
need them.

> - Looking at https://buildd.debian.org/status/package.php?p=pyside2 you might 
> want to limit the qtwebengine5-dev to the archs in which it builts. If 
> pyside2 
> build system works like pyqt then the related packages will not get built on 
> those archs. Yes, this needs an arch list in the related binary packages too.

Done.

> - Looking at debian/control pyside2-tools seems to ship pyside2-uic, but 
> python[3]-pyside2uic too. This is confusing :-/

Hum, our goal was to make the tools use python3 but I see that upstream
seems to use python 2 so we fixed the dependencies to use the python 2
version of the module.

Thanks for your review. I uploaded a new version with all those
improvements and a few more (fixing an RC bug!).

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/


signature.asc
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Lisandro Damián Nicanor Pérez Meyer]

Hello! First of all sorry for the late review, but the currently ongoing 
transition is not helping.

You might want to consider suscribing to pkg-kde-talk@a-l.d.n (CCed), it's a 
*very low* traffic mailing list in which we coordinate some stuff.

OK, looking at the package:

- I know I'm late, but python-pyside2 and python3-pyside3 are definitely not a 
good idea. Any packager could just use them as a build dependency and install 
*tons* of useless MB of packages to build a package that just needs qtbase. It 
would not surprise me if it's final installed size would exceed 1GB, without 
considering dependencies. We do not have a qt5-dev package for exactly this 
reason and time proved us to be right as many came in asking for it. Please 
consider removing this meta packages in your next upload.

- Looking at https://buildd.debian.org/status/package.php?p=pyside2 you might 
want to limit the qtwebengine5-dev to the archs in which it builts. If pyside2 
build system works like pyqt then the related packages will not get built on 
those archs. Yes, this needs an arch list in the related binary packages too.

- Looking at debian/control pyside2-tools seems to ship pyside2-uic, but 
python[3]-pyside2uic too. This is confusing :-/

I think that's all, thanks for it!

-- 
Programming is really just the mundane aspect of expressing a solution to a
problem. There are talents that are specifically related to actually coding,
but the real issue is being able to grasp problems and devise solutions that
are detailed enough to actually be coded.
  John Carmack answers on Slashdot,
  http://slashdot.org/games/99/10/15/1012230.shtml

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Kurt Kremitzki]

I'm very glad to see an update on this!

On 07/26/2018 09:16 AM, Raphael Hertzog wrote:
...
> 
> 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.
> 

It seems like the instability has ended because I'm able to build it
now. However, it also seems multi-core build support isn't working.

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Kurt Kremitzki]

I'm very glad to see an update on this!

On 07/26/2018 09:16 AM, Raphael Hertzog wrote:
...
> 
> 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.
> 

It seems like the instability has ended because I'm able to build it
now. However, it also seems multi-core build support isn't working.

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 26 de julio de 2018 11:16:10 -03 Raphael Hertzog escribió:
> Control: tag -1 pending
> 
> Hello all,

Hello! Good to read you again!
 
> 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.

I'm not a python packager, but what you describe sounds good. I'll try to take 
a look after I deal with various FTBFSs in the current transition.

> 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.

And qtdeclarative5-private-dev, which explains the dependency listed below.

> > - If Pyside2 uses private headers it will end up depending in
> > qt-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.

Well, it's strange that you build depend upon qtbase5-private-dev and do not 
end up depending on qtbase-abi-x-y-z. Except maybe the created binary is 
discarded in the process, like a test needing qtbase's internals.

> > 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.

One of the reasons we did not package pyside2 was that none of us had the 
interest/could afford the extra time. But then again if the above situation 
arises is like when any of us can't keep on maintaining a package for 
, so better than nothing, and much welcomed.

> 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.

To be honest our team's practices exists from before most teams got usual 
practices, and gbp was created.

I think none of us use the "git tricks" described there, just keep the debian/ 
stuff and unpack the tarballs.

> 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.

That sounds just like the right thing to do if you prefer gbp. And it's 
actually nice to read that you could follow your (almost) normal workflow non 
the less :-)

> 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".

I didn't know that goal to be honest. But this has worked pretty well for us 
so far. I think I need to make a note here: we usually do not add changelog 
entries for stuff like running wrap-and-sort, but we do ask for one 

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

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-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/

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Maximiliano Curia]

¡Hola Raphael!

El 2018-05-11 a las 15:33 +0200, Raphael Hertzog escribió:

Thank you. Note that you granted me "developer" access which doesn't let
me create new repositories, so I will need one of you to create the
repository and also to add sophie (sbrun-guest) as member of the
pyside2 repository.


I've created: https://salsa.debian.org/qt-kde-team/qt/pyside2

I've pushed an empty commit, as otherwise, some configurations don't seem to 
stick.


I've also added you as master for the pyside2 repository.

We have not yet decided when to give team wide Master or Admin levels, sorry 
about that, it's in the agenda for our next meeting, but the meeting has no 
date set.



Right, but please take into account that the packages maintained under the
qt tree use a debian directory only packaging branch, and in general, they
use all the same packaging structure (no dpm, no upstream branches or tags
in the public repos, etc). This set of rules is more relaxed in qt-extras
and kde-extras.



Are the rules documented somewhere?


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 
string here is wrong (we used to enforce that tags needed the "$version 
$distribution; urgency=$urgency" format as done by pkgkde-git tag -s), and I 
wouldn't blindly follow the instructions under "Integrating original source 
into local repository".


I'm not particularly fond to this rules as to work on updating them, please 
ask further advice to the qt maintainers (Lisandro and Dmitry).


Happy hacking,
--
"The day Microsoft makes something that doesn't suck, 
is probably the day Microsoft starts making vacuum cleaners."

-- Ernst Jan Plugge
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Lisandro Damián Nicanor Pérez Meyer]

Hi! I received this mail after sending my previous one.

El viernes, 11 de mayo de 2018 10:33:44 -03 Raphael Hertzog escribió:
> Hi,
> 
> On Fri, 11 May 2018, Maximiliano Curia wrote:
> > > Sophie and me are working to bring pyside2 into Debian. We would like to
> > > put it in pkg-kde-extras. I requested access to the salsa group for
> > > this.
> > 
> > Welcome to the team!
> 
> Thank you. Note that you granted me "developer" access which doesn't let
> me create new repositories, so I will need one of you to create the
> repository and also to add sophie (sbrun-guest) as member of the
> pyside2 repository.

Right, we normally do this and when someone asks for a new repo we create it 
and give master access to it.

> > Right, but please take into account that the packages maintained under the
> > qt tree use a debian directory only packaging branch, and in general, they
> > use all the same packaging structure (no dpm, no upstream branches or tags
> > in the public repos, etc). This set of rules is more relaxed in qt-extras
> > and kde-extras.
> 
> Are the rules documented somewhere?

 starting from "Public VCS repository of Debian packaging"
Use the "Display source" button for better reading. 

See also http://pkg-kde.alioth.debian.org/gitguidelines.html

You can read more guidelines/rules in http://pkg-kde.alioth.debian.org/ 
section "Working notes"


> At this point, there are no (versioned) upstream tarball releases so it
> might be better to be able to have full sources in the git repository and
> generate the .orig.tar.gz out of it.

If you plan to use the qt namespace that will not be possible (as per my last 
mail).


-- 
Evite los parámetros estáticos. Si son inevitables, haga que el emisor
y el receptor negocien un valor.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 11 de mayo de 2018 06:48:23 -03 Dmitry Shachnev escribió:
> Hi all,
> 
> First of all, thanks Raphaël and Sophie for working on PySide2 packaging!

Same here!

> On Fri, May 11, 2018 at 10:25:57AM +0200, Maximiliano Curia wrote:
> > > Should it go in "Qt" or "Qt extras"? It's going to be something official
> > > by
> > > the upstream Qt project so I think that "Qt" might be good.
> > 
> > Right, but please take into account that the packages maintained under the
> > qt tree use a debian directory only packaging branch, and in general, they
> > use all the same packaging structure (no dpm, no upstream branches or tags
> > in the public repos, etc). This set of rules is more relaxed in qt-extras
> > and kde-extras.
> 
> It looks like pyside2 will use the same release cycle as Qt uses, so we
> will most likely have to update it together with the other Qt modules.
> 
> It would be a bit easier for us if you put it into the Qt namespace and
> followed our packaging scheme (debian/ only repository), but Qt extras and
> whatever repo structure should work too.

It is worth to note that pyside2 will probably use some Qt's private headers.
If that's true:

- We try to avoid exporting (aka: creating a binary package shipping) private 
headers as much as possible. They are problematic as any unstable API/ABI can 
be.

- We only ship those that are needed by Qt submodules themselves, and so far 
have been refusing to ship more.

- If Pyside2 uses private headers it will end up depending in qt-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.

General info: due to transitions, manpower and number of bugs we normally skip 
5.x.0 and even patch releases in unstable. In other words we tend to ship 5.x.
1 and 5.x.3 at most (upstream rarely does .3 releases anyways).

Sometimes we start packing .0 and even releases in experimental, to reduce the 
work needed when a suitable release is about to come.

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 
ready for a transition). I can't say if anyone will be able to do it if kept 
under qt-extras and using gbp or alike (I personally don't use nor expect to 
use gbp, for example).


> > Also, I don't see in the bug log any comment about the current pyside
> > maintenance, are the pyside maintainers ok with moving the new version of
> > the project to a different repository in a different team?
> 
> As far as I know, there are no current pyside 1.x maintainers. So there is
> nobody who can complain about this move.

Right. I think all is needed to create the repo is knowing which namespace you 
will prefer: qt or qt-extras.

Of course, please feel free to ask any questions you might have.

Once again, thanks!


-- 
Why should I care about posterity?
What's posterity ever done for me?
  -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Hi,

On Fri, 11 May 2018, Maximiliano Curia wrote:
> > Sophie and me are working to bring pyside2 into Debian. We would like to
> > put it in pkg-kde-extras. I requested access to the salsa group for this.
> 
> Welcome to the team!

Thank you. Note that you granted me "developer" access which doesn't let
me create new repositories, so I will need one of you to create the
repository and also to add sophie (sbrun-guest) as member of the
pyside2 repository.

> Right, but please take into account that the packages maintained under the
> qt tree use a debian directory only packaging branch, and in general, they
> use all the same packaging structure (no dpm, no upstream branches or tags
> in the public repos, etc). This set of rules is more relaxed in qt-extras
> and kde-extras.

Are the rules documented somewhere?

At this point, there are no (versioned) upstream tarball releases so it
might be better to be able to have full sources in the git repository and
generate the .orig.tar.gz out of it.

> Also, I don't see in the bug log any comment about the current pyside
> maintenance, are the pyside maintainers ok with moving the new version of
> the project to a different repository in a different team?

There are no Uploaders left in debian/control both for pyside and
shiboken:
https://salsa.debian.org/python-team/modules/shiboken/blob/master/debian/control
https://salsa.debian.org/python-team/modules/pyside/blob/master/debian/control

On Fri, 11 May 2018, Dmitry Shachnev wrote:
> It looks like pyside2 will use the same release cycle as Qt uses, so we
> will most likely have to update it together with the other Qt modules.

And at least the version embedded in the code matches the Qt version, yes.

> As far as I know, there are no current pyside 1.x maintainers. So there is
> nobody who can complain about this move.

Indeed.

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/

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Dmitry Shachnev]

Hi all,

First of all, thanks Raphaël and Sophie for working on PySide2 packaging!

On Fri, May 11, 2018 at 10:25:57AM +0200, Maximiliano Curia wrote:
> > Should it go in "Qt" or "Qt extras"? It's going to be something official by
> > the upstream Qt project so I think that "Qt" might be good.
>
> Right, but please take into account that the packages maintained under the
> qt tree use a debian directory only packaging branch, and in general, they
> use all the same packaging structure (no dpm, no upstream branches or tags
> in the public repos, etc). This set of rules is more relaxed in qt-extras
> and kde-extras.

It looks like pyside2 will use the same release cycle as Qt uses, so we
will most likely have to update it together with the other Qt modules.

It would be a bit easier for us if you put it into the Qt namespace and
followed our packaging scheme (debian/ only repository), but Qt extras and
whatever repo structure should work too.

> Also, I don't see in the bug log any comment about the current pyside
> maintenance, are the pyside maintainers ok with moving the new version of
> the project to a different repository in a different team?

As far as I know, there are no current pyside 1.x maintainers. So there is
nobody who can complain about this move.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Maximiliano Curia]

¡Hola Raphael!

El 2018-05-11 a las 09:46 +0200, Raphael Hertzog escribió:

Control: retitle -1 ITP: pyside2 -- Qt for Python
Control: owner -1 sop...@freexian.com



On Sat, 14 Apr 2018 10:09:38 +0200 Francesco Poli  
wrote:

Moreover, if I read the [announcement] correctly, it seems that PySide2
is going to be renamed as "Qt for Python" and adopted as official Qt
bindings for Python...



[announcement]: 




I really hope someone with good Python Debian packaging skills will
soon package pyside2 for inclusion in Debian!



Sophie and me are working to bring pyside2 into Debian. We would like to
put it in pkg-kde-extras. I requested access to the salsa group for this.


Welcome to the team!


Should it go in "Qt" or "Qt extras"? It's going to be something official by
the upstream Qt project so I think that "Qt" might be good.


Right, but please take into account that the packages maintained under the qt 
tree use a debian directory only packaging branch, and in general, they use 
all the same packaging structure (no dpm, no upstream branches or tags in the 
public repos, etc). This set of rules is more relaxed in qt-extras 
and kde-extras.


Also, I don't see in the bug log any comment about the current pyside 
maintenance, are the pyside maintainers ok with moving the new version of the 
project to a different repository in a different team?


Happy hacking,
--
"If a million people believe a foolish thing, it is still a foolish thing."
-- France's Rule of Folly
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Control: retitle -1 ITP: pyside2 -- Qt for Python
Control: owner -1 sop...@freexian.com

On Sat, 14 Apr 2018 10:09:38 +0200 Francesco Poli  
wrote:
> Moreover, if I read the [announcement] correctly, it seems that PySide2
> is going to be renamed as "Qt for Python" and adopted as official Qt
> bindings for Python...
> 
> [announcement]: 
> 
> 
> I really hope someone with good Python Debian packaging skills will
> soon package pyside2 for inclusion in Debian!

Sophie and me are working to bring pyside2 into Debian. We would like to
put it in pkg-kde-extras. I requested access to the salsa group for this.

Should it go in "Qt" or "Qt extras"? It's going to be something official by
the upstream Qt project so I think that "Qt" might be good.

Currently the code is split among two git repositories upstream:
https://code.qt.io/cgit/pyside/pyside-setup.git/
https://code.qt.io/cgit/pyside/pyside-tools.git/

pyside-setup contains PySide2 and Shiboken2 (and pyside2-tools as
submodule).

I think we will want to name the source package and the git repository
"pyside2" anyway. And we possibly want to integrate pyside-tools
in the .orig.tar.gz as well.

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/

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Francesco Poli]

On Sat, 31 Mar 2018 16:39:53 +0200 W. Martin Borgert wrote:

> Upstream seems to make good progress:
> http://lists.qt-project.org/pipermail/pyside/2018-March/002557.html

Moreover, if I read the [announcement] correctly, it seems that PySide2
is going to be renamed as "Qt for Python" and adopted as official Qt
bindings for Python...

[announcement]: 


I really hope someone with good Python Debian packaging skills will
soon package pyside2 for inclusion in Debian!
This will be greatly appreciated.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpSOmL9q9oJm.pgp
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[W. Martin Borgert]

Upstream seems to make good progress:
http://lists.qt-project.org/pipermail/pyside/2018-March/002557.html

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: pyside2
  Version : 2.0.0.dev0
  Upstream Author : PySide2 Team 
* URL : https://wiki.qt.io/PySide
* License : LGPL3, GPL3+
  Programming Lang: C++, Python
  Description : Python bindings for Qt5

(information mainly from
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/setup.py)

Long description can probably copied from pyside.

PySide2 is the successor of PySide and is a dependency for
at least FreeCAD and python-ghost. PySide will be removed
from Debian soon, so PySide2 must be packaged.

Dominique Belhachemi  explains how to
get PySide2 from a Ubuntu PPA on Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784512#78

Maybe also helpful:
https://wiki.qt.io/PySide2_GettingStarted
--
"Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder