Re: Packaging PythonQt for Qt 5

2017-06-14 Thread Dmitry Shachnev 
Hi Erik and Sandro,

On Wed, Jun 14, 2017 at 10:56:40PM +0200, Sandro Knauß wrote:
> the SVN link actually pointed me to look at who is actually the maintainer of 
> pythonqt and saw, that is not Debian KDE Maintainers. It is the QA Team
> . So that are the people that you need to talk to, 
> because only those can add your work. Additonally they may have other rules 
> how work should be done.

The QA team is a standard maintainer address when the package is orphaned.

Also, as the package is orphaned, there is no reason to stick to the old SVN
repository. You can convert it into git (i.e. with git-svn) and push to
collab-maint or your personal Git namespace.

If you prefer to maintain it under kde-extras team, ask one of the maintainers
to grant you access there.

> Some general things:
> compat level update to 10 ( that should be used nowadays):
>  * see man 7 debhelper
> with that you can rid of  --parallel ( it is default with v10)
> but bumping the compat level is some thing the maintainers of package needs 
> to 
> do, it may be circumstances not to bump that. But try it if it builds with 
> v10 
> is a good thing to do.
> -> would also need you to update to debhelper (>= 10) in control
> * also checking the Standards-Version and bumping this is also a task to do 
> before uploading a new version.
> *are there tests to run / need to build seperatly?
> * are the patches will  go upstream? Please use dep3 styple for patches:
> http://dep.debian.net/deps/dep3/
> I use "quilt header -e --dep3" to create such headers.
> * did you checked if there are packagages using the dev packages? If yes, 
> there needs to be a transition requested, because all packages needs to 
> rebuilt...
>
> But still I'm not maintainer of this package, so I can't tell you if they 
> also 
> what these changes.

Sandro’s comments make sense, please take them into account.

Some comments from me now:

* There are directories with names generated_cpp_5* with C++ files inside.
  If these C++ files are really generated, then the best Debian practice is
  regenerate them before build (I guess we only need the _56 directory).

* Is Python 2 support really needed? Upstream will drop support for Python 2
  soon, and we are going to follow, so new packages can be packaged for
  Python 3 only unless you know there will be applications that want to use
  PythonQt with Python 2. See [1] for details.

* Lintian warns that library package names do not match their SONAMEs.
  The proper package names would be like libpythonqt-qtall-qt5-python3.5-3.

  Since the ABI would break for Python version bumps, I think adding this
  digit makes sense.

  Also, what is the difference between Qt5 and QtAll-Qt5 libraries?
  The package descriptions do not say anything about that.

* Lintian warns about missing symbols files. This is something not much
  important, but in future you may want to use the symbols files to track
  the package ABI changes. pkgkde-symbolshelper [2] may help you with this.

* Lintian warns about duplicate package short names.

* Lintian also warns about missing DEP-5 copyright. The copyright seems to
  be already in DEP-5 format, so you need to just add a Format: line on top.

* There is Doxygen documentation source in the tarball, you may want to add
  a package for it in the future.

[1]: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html.
[2]: http://pkg-kde.alioth.debian.org/symbolfiles.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-06-14 Thread Sandro Knauß 
Hey,

the SVN link actually pointed me to look at who is actually the maintainer of 
pythonqt and saw, that is not Debian KDE Maintainers. It is the QA Team
. So that are the people that you need to talk to, 
because only those can add your work. Additonally they may have other rules 
how work should be done.

> Actually uploading to mentors.debian.net might be better. A pointer to the
> SVN is also not bad.

+1

> Python is definitely not my area, so I'm afraid I can't help here.

mine yes :)

Some general things:
compat level update to 10 ( that should be used nowadays):
 * see man 7 debhelper
with that you can rid of  --parallel ( it is default with v10)
but bumping the compat level is some thing the maintainers of package needs to 
do, it may be circumstances not to bump that. But try it if it builds with v10 
is a good thing to do.
-> would also need you to update to debhelper (>= 10) in control
* also checking the Standards-Version and bumping this is also a task to do 
before uploading a new version.
*are there tests to run / need to build seperatly?
* are the patches will  go upstream? Please use dep3 styple for patches:
http://dep.debian.net/deps/dep3/
I use "quilt header -e --dep3" to create such headers.
* did you checked if there are packagages using the dev packages? If yes, 
there needs to be a transition requested, because all packages needs to 
rebuilt...

But still I'm not maintainer of this package, so I can't tell you if they also 
what these changes.

Best Regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-06-14 Thread Lisandro Damián Nicanor Pérez Meyer 
On miércoles, 14 de junio de 2017 01:01:13 -03 Erik Lundin wrote:
> Hi,

Hi Erik!
 
> I'm now done with all changes I would like to see, so if someone would
> like to review them I'm grateful. Please see attached the diff against
> pythonqt 3.0-3. Since the Debian code for this package is hosted in SVN
> [1], I guess this is the easiest way.

Actually uploading to mentors.debian.net might be better. A pointer to the SVN 
is also not bad.

> Here is a summary of the changes:
> 
>* New upstream version
>* Change to Qt5, since Qt4 has been deprecated upstream
>* Adapt building to pure qmake (CMake has been deprecated upstream)
>* Build packages for both Python 2 and Python 3
>* Place QtAll extension in separate package
>* Implement multiarch support
> 
> Since this is my first contribution to Debian, I'm also thankful for
> advices on best practices etc. if applicable.

Python is definitely not my area, so I'm afraid I can't help here.

-- 
7: Hay diferencia entre "cortar" un archivo y "borrarlo" o "eliminarlo"
* Depende cuando se "cuelgue" Windows
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-06-14 Thread Erik Lundin 

Hi,

I'm now done with all changes I would like to see, so if someone would 
like to review them I'm grateful. Please see attached the diff against 
pythonqt 3.0-3. Since the Debian code for this package is hosted in SVN 
[1], I guess this is the easiest way.


Here is a summary of the changes:

  * New upstream version
  * Change to Qt5, since Qt4 has been deprecated upstream
  * Adapt building to pure qmake (CMake has been deprecated upstream)
  * Build packages for both Python 2 and Python 3
  * Place QtAll extension in separate package
  * Implement multiarch support

Since this is my first contribution to Debian, I'm also thankful for 
advices on best practices etc. if applicable.


/Erik

[1] 
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/pythonqt/trunk/


Den 2017-06-06 kl. 19:29, skrev Sandro Knauß:

Hey,


How can I submit my packaging changes for review? Are you using pull
requests somewhere?


there is no "formal way" nor pull request. The normal workflow is to use
mentors and personal repos and send the link around.

* mentors.debian.org
* https://wiki.debian.org/Alioth/Git#Forking_Git_repositories_onto_Alioth

( You can use every other git hosting platform, if you wish)

After some time we will grant you permission to push to git directly.

Hopefully this works for you.

Best Regards,

sandro

diff -ur --unidirectional-new-file PythonQt3.0/debian/changelog PythonQt3.2/debian/changelog
--- PythonQt3.0/debian/changelog	2016-09-15 18:16:39.0 +0200
+++ PythonQt3.2/debian/changelog	2017-06-14 00:28:51.456754423 +0200
@@ -1,3 +1,14 @@
+pythonqt (3.2-1) UNRELEASED; urgency=medium
+
+  * New upstream version
+  * Change to Qt5, since Qt4 has been deprecated upstream
+  * Adapt building to pure qmake (CMake has been deprecated upstream)
+  * Build packages for both Python 2 and Python 3
+  * Place QtAll extension in separate package
+  * Implement multiarch support
+
+ -- Erik Lundin   Tue, 13 Jun 2017 22:40:27 +0200
+
 pythonqt (3.0-3) unstable; urgency=medium
 
   * QA upload.
diff -ur --unidirectional-new-file PythonQt3.0/debian/control PythonQt3.2/debian/control
--- PythonQt3.0/debian/control	2016-09-15 18:16:39.0 +0200
+++ PythonQt3.2/debian/control	2017-06-14 00:19:55.640303796 +0200
@@ -3,25 +3,34 @@
 Section: libs
 Priority: optional
 Build-Depends: debhelper (>= 9),
-   cmake,
+   dh-exec (>= 0.3),
python-dev,
-   qt4-qmake,
-   libqt4-dev,
-   libqt4-opengl-dev
+   python3-dev,
+   qtbase5-dev,
+   qttools5-dev,
+   qt5-qmake,
+   libqt5svg5-dev,
+   libqt5xmlpatterns5-dev,
+   qtmultimedia5-dev,
+   qtbase5-private-dev,
+   qtdeclarative5-dev,
+   libqt5opengl5-dev
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/viewvc/debian-med/trunk/packages/pythonqt/trunk/
 Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/pythonqt/trunk/
 Homepage: http://pythonqt.sourceforge.net
-X-Python-Version: current
+X-Python-Version: >= 2.6
+X-Python3-Version: >= 3.3
 
-Package: libpythonqt3.0
+Package: libpythonqt-qt5-python2-3
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Dynamic Python binding for the Qt framework - runtime
  PythonQt offers an easy way to embed the Python scripting language into a
- C++ Qt applications. It makes heavy use of the QMetaObject system and thus
- requires Qt 4.x.
+ C++ Qt applications. It makes heavy use of the QMetaObject system and
+ requires Qt 5.x.
  The focus of PythonQt is on embedding Python into an existing C++ application,
  not on writing the whole application completely in Python. If you want to write
  your whole application in Python, you should use PyQt or PySide instead.
@@ -29,20 +38,189 @@
  Application and to script parts of your application via Python, PythonQt is the
  way to go!
  .
- This package contains the libraries needed to run PythonQt applications.
+ This package contains the libraries needed to run PythonQt applications
+ for Python 2.
 
-Package: libpythonqt-dev
+Package: libpythonqt-qt5-common-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
-Depends: libpythonqt3.0 (= ${binary:Version}),
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Description: Dynamic Python binding for the Qt framework - development
+ PythonQt offers an easy way to embed the Python scripting language into a
+ C++ Qt applications. It makes heavy use of the QMetaObject system and
+ requires Qt 5.x.
+ The focus of PythonQt is on embedding Python into an existing C++ application,
+ not on writing the whole application completely in Python. If you want to write
+ your whole application in Python, you should use PyQt or PySide instead.
+ If you are looking for a simple way to embed Python objects into your C++/Qt
+ Application

Re: Packaging PythonQt for Qt 5

2017-06-06 Thread Sandro Knauß 
Hey,

> How can I submit my packaging changes for review? Are you using pull
> requests somewhere?

there is no "formal way" nor pull request. The normal workflow is to use 
mentors and personal repos and send the link around.

* mentors.debian.org
* https://wiki.debian.org/Alioth/Git#Forking_Git_repositories_onto_Alioth

( You can use every other git hosting platform, if you wish)

After some time we will grant you permission to push to git directly. 

Hopefully this works for you.

Best Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-06-06 Thread Erik Lundin 

Den 2017-05-27 kl. 22:38, skrev Dmitry Shachnev:

Yes, the soname is something to consider for upstream. If we think upstream
made an ABI break, we usually do not patch the soname, but instead rename the
package, i.e. append a prefix (“a” or “v5”).


The new upstream release 3.2 solves this. The produced libraries are now 
(for Python 2.7)


libPythonQt-Qt5-Python2.7.so -> libPythonQt-Qt5-Python2.7.so.3.2.0
libPythonQt-Qt5-Python2.7.so.3 -> libPythonQt-Qt5-Python2.7.so.3.2.0
libPythonQt-Qt5-Python2.7.so.3.2 -> libPythonQt-Qt5-Python2.7.so.3.2.0
libPythonQt-Qt5-Python2.7.so.3.2.0
libPythonQt_QtAll-Qt5-Python2.7.so -> 
libPythonQt_QtAll-Qt5-Python2.7.so.3.2.0
libPythonQt_QtAll-Qt5-Python2.7.so.3 -> 
libPythonQt_QtAll-Qt5-Python2.7.so.3.2.0
libPythonQt_QtAll-Qt5-Python2.7.so.3.2 -> 
libPythonQt_QtAll-Qt5-Python2.7.so.3.2.0

libPythonQt_QtAll-Qt5-Python2.7.so.3.2.0

How can I submit my packaging changes for review? Are you using pull 
requests somewhere?


/Erik

--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-29 Thread Lisandro Damián Nicanor Pérez Meyer 
On sábado, 27 de mayo de 2017 22:35:50 -03 Erik Lundin wrote:
> Hi Lisandro,
> 
> Den 2017-05-27 kl. 22:26, skrev Lisandro Damián Nicanor Pérez Meyer:
> > On jueves, 25 de mayo de 2017 14:44:14 -03 Erik Lundin wrote:
> >> Den 2017-05-24 kl. 16:02, skrev Lisandro Damián Nicanor Pérez Meyer:
> >>> Yes, if those libs are tied to public headers package them as separate
> >>> binary packages. Your mental health at maintaining time will thank you
> >>> ;)
> >> 
> >> There is a header for PythonQt_QtAll (PythonQt_QtAll.h), so if I
> >> understand it correctly, you would recommend to place
> >> libPythonQt_QtAll.so.* in a separate package? In that case, should I
> >> also create a corresponding dev package for the header and the
> >> libPythonQt_QtAll.so symlink?
> > 
> > Yes and yes.
> 
> I made those changes today and agree it feels like a good solution.

It wll definitely help ypu at symbol-handling time.

-- 
Hacer algo siempre te llevará más tiempo del que esperabas, incluso si
tienes en cuenta la ley de Hofstadter.
  Douglas Hofstadter
  http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/

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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-27 Thread Dmitry Shachnev 
On Sat, May 27, 2017 at 10:08:13PM +0200, Erik Lundin wrote:
> > I think it is better to use original upstream sonames, for compatibility 
> > with
> > third-party applications built against upstream versions.
> >
> > The Debian package name should usually be based only on the major part of
> > soname, but as there is a clear ABI break here for Qt 5 switch, I think you
> > may keep the current naming scheme and name the package libpythonqt3.1.
>
> Isn't an argument for renamed .so files that this breaking ABI change would
> require the major version to change? I built an application against PythonQt
> today, and it was linked against libPythonQt.so.3, so it obviously cared
> about the major version. For that reason I patched the project files to
> produce the targets libPythonQt5.so.3.1.0 etc. The package could then be
> called libpythonqt-qt5-3. The problem is as you say that the project by
> default doesn't name the Qt 5 libraries differently. Maybe something that I
> should try to get fixed upstream?

Yes, the soname is something to consider for upstream. If we think upstream
made an ABI break, we usually do not patch the soname, but instead rename the
package, i.e. append a prefix (“a” or “v5”).

--
Dmitry Shachnev


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-27 Thread Lisandro Damián Nicanor Pérez Meyer 
On jueves, 25 de mayo de 2017 14:44:14 -03 Erik Lundin wrote:
> Den 2017-05-24 kl. 16:02, skrev Lisandro Damián Nicanor Pérez Meyer:
> > Yes, if those libs are tied to public headers package them as separate
> > binary packages. Your mental health at maintaining time will thank you ;)
> There is a header for PythonQt_QtAll (PythonQt_QtAll.h), so if I
> understand it correctly, you would recommend to place
> libPythonQt_QtAll.so.* in a separate package? In that case, should I
> also create a corresponding dev package for the header and the
> libPythonQt_QtAll.so symlink?

Yes and yes.


-- 
Hiroshima '45,
Chernobyl '86,
Windows   '95.
 Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo.

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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-27 Thread Erik Lundin 

Hi Dmitry,

Thanks for your feedback!

Den 2017-05-27 kl. 20:55, skrev Dmitry Shachnev:


The current Qt 4 package has no reverse dependencies, so you can safely drop
it and replace with the Qt 5 package.

I would prefer to avoid conflict, so please use /usr/include/PythonQt5.


Yes, that sounds reasonable.


I think it is better to use original upstream sonames, for compatibility with
third-party applications built against upstream versions.

The Debian package name should usually be based only on the major part of
soname, but as there is a clear ABI break here for Qt 5 switch, I think you
may keep the current naming scheme and name the package libpythonqt3.1.


Isn't an argument for renamed .so files that this breaking ABI change 
would require the major version to change? I built an application 
against PythonQt today, and it was linked against libPythonQt.so.3, so 
it obviously cared about the major version. For that reason I patched 
the project files to produce the targets libPythonQt5.so.3.1.0 etc. The 
package could then be called libpythonqt-qt5-3. The problem is as you 
say that the project by default doesn't name the Qt 5 libraries 
differently. Maybe something that I should try to get fixed upstream?



I do not know why .so.3 should be skipped, I would add it.


Yes, that's also the easiest solution from a technical standpoint as I 
see it.


/Erik

--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-24 Thread Lisandro Damián Nicanor Pérez Meyer 
On martes, 23 de mayo de 2017 10:13:13 -03 Erik Lundin wrote:
[snip] 
> *PythonQt_QtAll*
> Previous packages built using CMake were configured to wrap the
> extension PythonQt_QtAll and only create one set of library files.
> However, the possibility to do that seems to have disappeared, and now a
> new set of library files are created (libPythonQt_QtAll.so.3.1.0 with
> corresponding symlinks). The packaging guide, section 8.1, suggests that
> it is OK to put several libraries into the same package if their SONAMES
> will always change together, and I assume that this is the case here, so
> I'm prepared to do that. Any opinions on that?

Yes, if those libs are tied to public headers package them as separate binary 
packages. Your mental health at maintaining time will thank you ;)


-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-24 Thread Lisandro Damián Nicanor Pérez Meyer 
Dmitry, you know better than me on this :-/

On martes, 23 de mayo de 2017 10:13:13 -03 Erik Lundin wrote:
> Hello,
> 
> I sent this email to the debian-mentors list, and got directed to the
> Debian Qt/KDE team, so here follows the same content:
> 
> We're using PythonQt built for Qt 5 at work, and I have been looking at
> the possibility to package it for Debian. Here is what I have found so far:
> 
> * Qt 4 support for PythonQt seems to have been abandoned upstream. There
> is a branch with the last working version for Qt 4, and version 3.1
> (latest release) assumes Qt 5.
> * Support for CMake has been removed upstream.
> * The current Debian packages are Qt 4 only, and made for QMake.
> * pythonqt is orphaned in Debian
> * Debian tracker: https://tracker.debian.org/pkg/pythonqt
> 
> I have made necessary changes for building the package using QMake, and
> now would like to contribute them back to the community. However, I'm
> new when it comes to Debian packaging, so please help me with the following:
> 
> *Qt 4 vs Qt 5 versions of installed files*
> Compatibility between the packages for Qt 4 and Qt 5 has to be handled,
> i.e. the new package should not just install files with the same names
> as the previous packages. Since Qt 4 is abandoned upstream, I changed
> the packaging scripts to only build for Qt 5 and changed the names to
> "libpythonqt-qt5-3.1" and "libpythonqt-qt5-dev". However, the installed
> files still have the same names as the files of the previous packages
> (at least the dev package, which has files installed in
> /usr/include/PythonQt). Possible solutions to the dev package problem:
> 
> * Install header files to /usr/include/PythonQt5 or some other Qt 5
> specific folder.
> * Install header files to /usr/include/PythonQt and let
> libpythonqt-qt5-dev conflict libpythonqt-dev so only one of them can be
> installed at a time.
> * Install header files to /usr/include/PythonQt and only use the name
> libpythonqt-dev (no Qt 5 in the name). The policy manual, section 8.4,
> suggests that this is a possibility if you only want to support one
> development version at a time.
> 
> *Library files*
> The library files have different names, because of the new version
> (libPythonQt.so.3.1.0 vs libPythonQt.so.3.0.0), but would it be wise to
> rename the Qt 5 library to libPythonQt5.so.3.1.0 or something similarly,
> just to clearly indicate the difference? Since Qt 4 is abandoned
> upstream, I don't expect any Qt 4 packages with version 3.1.0 of the so
> files. The policy manual, section 8.1, says that "the package should
> install the shared libraries under their normal names".
> 
> The previous package libpythonqt3.0 creates the symlink
> libPythonQt.so.3.0 -> libPythonQt.so.3.0.0 but not libPythonQt.so.3 ->
> libPythonQt.so.3.0.0. Should this file be skipped also in the Qt 5 case?
> The symlink libPythonQt.so is created by the dev package, which is fine
> if the second or third solution to the dev package problem above is
> selected.
> 
> *PythonQt_QtAll*
> Previous packages built using CMake were configured to wrap the
> extension PythonQt_QtAll and only create one set of library files.
> However, the possibility to do that seems to have disappeared, and now a
> new set of library files are created (libPythonQt_QtAll.so.3.1.0 with
> corresponding symlinks). The packaging guide, section 8.1, suggests that
> it is OK to put several libraries into the same package if their SONAMES
> will always change together, and I assume that this is the case here, so
> I'm prepared to do that. Any opinions on that?
> 
> Regards,
> Erik


-- 
Una sola bomba nuclear puede arruinar el resto de tu día.

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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-23 Thread Florian Bruhin 
Hey Fritz,

On Wed, May 24, 2017 at 02:28:01AM +0200, Fritz Reichwald wrote:
> just one question for my better understanding.
> Is it possible that you mean PyQt when you say PythonQt?

PythonQt is an entirely different project, which aims to make (C++) Qt
projects scriptable with Python: http://pythonqt.sourceforge.net/

And yeah, they really should've picked a less confusing name... ;-)

Florian

-- 
https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
 I love long mails!  | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

2017-05-23 Thread Fritz Reichwald 

Hi Erik,

just one question for my better understanding.
Is it possible that you mean PyQt when you say PythonQt?
If yes its already packaged for debian and working well.
You can find it in the repositories with the name "python3-pyqt5"

Best regards
Fritz

-- 


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Packaging PythonQt for Qt 5

2017-05-23 Thread Erik Lundin 

Hello,

I sent this email to the debian-mentors list, and got directed to the 
Debian Qt/KDE team, so here follows the same content:


We're using PythonQt built for Qt 5 at work, and I have been looking at 
the possibility to package it for Debian. Here is what I have found so far:


* Qt 4 support for PythonQt seems to have been abandoned upstream. There 
is a branch with the last working version for Qt 4, and version 3.1 
(latest release) assumes Qt 5.

* Support for CMake has been removed upstream.
* The current Debian packages are Qt 4 only, and made for QMake.
* pythonqt is orphaned in Debian
* Debian tracker: https://tracker.debian.org/pkg/pythonqt

I have made necessary changes for building the package using QMake, and 
now would like to contribute them back to the community. However, I'm 
new when it comes to Debian packaging, so please help me with the following:


*Qt 4 vs Qt 5 versions of installed files*
Compatibility between the packages for Qt 4 and Qt 5 has to be handled, 
i.e. the new package should not just install files with the same names 
as the previous packages. Since Qt 4 is abandoned upstream, I changed 
the packaging scripts to only build for Qt 5 and changed the names to 
"libpythonqt-qt5-3.1" and "libpythonqt-qt5-dev". However, the installed 
files still have the same names as the files of the previous packages 
(at least the dev package, which has files installed in 
/usr/include/PythonQt). Possible solutions to the dev package problem:


* Install header files to /usr/include/PythonQt5 or some other Qt 5 
specific folder.
* Install header files to /usr/include/PythonQt and let 
libpythonqt-qt5-dev conflict libpythonqt-dev so only one of them can be 
installed at a time.
* Install header files to /usr/include/PythonQt and only use the name 
libpythonqt-dev (no Qt 5 in the name). The policy manual, section 8.4, 
suggests that this is a possibility if you only want to support one 
development version at a time.


*Library files*
The library files have different names, because of the new version 
(libPythonQt.so.3.1.0 vs libPythonQt.so.3.0.0), but would it be wise to 
rename the Qt 5 library to libPythonQt5.so.3.1.0 or something similarly, 
just to clearly indicate the difference? Since Qt 4 is abandoned 
upstream, I don't expect any Qt 4 packages with version 3.1.0 of the so 
files. The policy manual, section 8.1, says that "the package should 
install the shared libraries under their normal names".


The previous package libpythonqt3.0 creates the symlink 
libPythonQt.so.3.0 -> libPythonQt.so.3.0.0 but not libPythonQt.so.3 -> 
libPythonQt.so.3.0.0. Should this file be skipped also in the Qt 5 case? 
The symlink libPythonQt.so is created by the dev package, which is fine 
if the second or third solution to the dev package problem above is 
selected.


*PythonQt_QtAll*
Previous packages built using CMake were configured to wrap the 
extension PythonQt_QtAll and only create one set of library files. 
However, the possibility to do that seems to have disappeared, and now a 
new set of library files are created (libPythonQt_QtAll.so.3.1.0 with 
corresponding symlinks). The packaging guide, section 8.1, suggests that 
it is OK to put several libraries into the same package if their SONAMES 
will always change together, and I assume that this is the case here, so 
I'm prepared to do that. Any opinions on that?


Regards,
Erik


--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk