[Pkg-electronics-devel] [Debian-med-packaging] QtPropertyBrowser

[Emmanuel Promayon]

Dear all,

First, sorry in advance for this long message. It probably contains over 
simplified statement about packaging (but I have an excuse: I am a 
packager newbie!).

Since version 6.0.0-1 the camitk source package is build using qt6. The 
package libqtpropertybrowser6 and libqtpropertybrowser-dev are therefore 
built using qt6.
libqtpropertybrowser5 is the version available in Debian stable. Debian 
unstable and Debian testing provides the Qt6 version.

As you noticed, the vendor copy in the camitk source package is not the 
currently official version of qtpropertybrowser. As explained in 
sdk/libraries/qtpropertybrowser/README.CAMITK:
> CamiTK started to use Qt Property Browser way back in 2010, when it 
> was part of the Qt Solutions component
> released under the BSD Licence.
> - Qt Solutions archive where first moved to gitlab
> For qtpropertybrowser on gitlab, see:
> https://github.com/qtproject/qt-solutions/tree/master/qtpropertybrowser/src
> - It was then took over again by the Qt Company Ltd.
> For qtpropertybrowser the Qt Company see:
> https://code.qt.io/cgit/qt/qttools.git/tree/src/shared/qtpropertybrowser
> The CamiTK team tries to keep in sync with both projects (at least of 
> the bug fixes), but we did our own migration to Qt5and our 
> modification and bug fixing.

The migration to Qt6 was also performed on the same vendor code.
FYI, we noticed a renewed activity in the upstream source at code.qt.io 
since circa 2023. The vendor copy was not updated that much at all.

 From what I understand, nextpnr also uses a forked version from the 
original qt-solutions (see 3rdparty/QtPropertyBrowser/README.md [1]).

Moreover, the CamiTK development team (upstream) is considering removing 
this dependency and using an in-house specialized solution in the near 
future.
This removal is underway but not performed yet.
Knowing that there were no reverse dependencies on libqtpropertybrowser6 
we were also considering removing both libqtpropertybrowser6 and  
libqtpropertybrowser-dev packages.
If I remembered well, the gazebo package was at some stage dependent on 
these packages but it is no longer the case.

Finally, to answer your question: yes, it might be a good idea to have 
an independent package for QtPropertyBrowser based on the code.qt.io 
corresponding subdirectory [2].
It seems to be updated regularly by the people at qt.io.
I don't know if there any other vendor distribution of QtPropertyBrowser 
in other Debian packages (or if there is a way to check this)

Note nevertheless that the class ObjectController (a very useful tool 
used in CamiTK to automatically create a GUI from the Qt property 
system) was initially part of the original QtPropertyBrowser examples.  
I could not find the ObjectController example source code in the current 
repository.
If nextpnr is also using the ObjectController "magic" class, then it 
won't help to have a separate package.

The other thing to consider is the licence. The current source code in 
src/shared/qtpropertybrowser [2] has a complex SPDX-License-Identifier:
LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only
(so I suppose it is ok but not 100% sure).

Best regards,
Emmanuel

[1] 
https://salsa.debian.org/electronics-team/nextpnr/-/tree/2ab3a896bdfe3ee1539c32ce963e277648b325c6/3rdparty/QtPropertyBrowser
[2] 
https://code.qt.io/cgit/qt/qttools.git/tree/src/shared/qtpropertybrowser 
or the github clone at 
https://github.com/qt/qttools/tree/a7527f64886f628fc0f2657798d199400df01ce3/src/shared/qtpropertybrowser

On 22/07/2026 17:03, Simon Richter wrote:
> Hi,
>
> The libqtpropertybrowser5 package is currently provided from a 
> vendored copy in the camitk package.
>
> In nextpnr, we have another vendored copy, but we're already using 
> qt6, so we cannot use the one from camitk.
>
> I'm not sure where upstream is at this point, but I suspect there are 
> more copies. Does it make sense to try to unify them?
>
>    Simon
>
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging 
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20260723/bd0e80eb/attachment-0001.htm>