Re: 20180210 IRC meeting wrap-up
Hi Steve! On Sun, Apr 08, 2018 at 01:18:56PM -0500, Steve Robbins wrote: > Hi. What is blocking upload of svn-converted repositories? Is there > anything I can do? I am ready to push them to Salsa at any moment, and I have updated my import [1] to the latest revision recently, but Pino (CCed) asked me to wait a bit more until he reviews it. [1]: https://anonscm.debian.org/git/users/mitya57/kde-extras/ -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Migrating SVN to Salsa
Hi Pino! I have just updated my SVN import [1] to the latest revision (21095). We get requests from others (e.g. [2]) to move specific packages, but I would rather migrate all these repositories at once. Would you mind me doing that? If you want to review my import first, how many days do you need for the review? I am going to skip empty repositories and repositories which have a note that they have already been moved to Git. [1]: https://anonscm.debian.org/git/users/mitya57/kde-extras/ [2]: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2018-March/002646.html -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: 20180210 IRC meeting wrap-up
Hi Steve and all, On Wed, Mar 14, 2018 at 10:21:58AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > Also: I am converting digikam from SVN -- also on alioth under kde-extras. > > At this step we want to be cautious because we want the SVN history to be > kept > as much as possible. Which tools did you use to convert the SVN repo to git? > > Without implying you did something wrong, I think Dmitry did very successful > conversions from SVN to git. > > It would be real cool if we could check the import before pushing to the git > repo. Right, my plan was to migrate all SVN repos at once. Initial migration results are here [1]. I want at least Pino's feedback before I push that to salsa. If you could review your repositories in that list, it would be very nice. [1]: https://anonscm.debian.org/git/users/mitya57/kde-extras/ -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Moving to salsa: IRC meeting coordination?
On Tue, Feb 06, 2018 at 07:22:24PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Thursday I'm free starting from 20 utc 20 or 21 UTC should be fine for me. What do the others think? -- Dmitry Shachnev -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Moving to salsa: IRC meeting coordination?
Hi Lisandro! On Fri, Feb 02, 2018 at 02:24:19PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi everyone! I think it would be a good idea to coordinate an IRC meeting in > order to prepare our move to salsa. > > At least from my side this weekend and the following would be ideal (+/- some > commitments I have already arranged), but if necessary I can coordinate > during > the following weekdays (nut not after the 13th). > > What do you think? Tomorrow, Feb 3 around 17:00 UTC would be fine for me. > If this idea picks up we should create a wiki/gobby page or alike to > coordinate topics I guess Please do. Maybe we can put some ideas in advance there. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Bug#879787: transition: qtbase-opensource-src 5.9.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We would like to request (yet another) transition for Qt packages. Qt 5.9.2 is a bugfix release in 5.9 LTS series, yet it has some minor private ABI breaks so we have bumped the ABI virtual package names. The changes are not large, so it should be much easier to handle than the previous 5.7 → 5.9 transition. We are also taking this transition as an opportunity to do a packaging change: Qt binaries are now moved to a non-multiarch location, /usr/lib/qt5/bin/. This was needed to fix cross-building with CMake. Ben file for qtbase: title = "qtbase-opensource-src"; is_affected = .depends ~ "qtbase-abi-5-9-0" | .depends ~ "qtbase-abi-5-9-2"; is_good = .depends ~ "qtbase-abi-5-9-2"; is_bad = .depends ~ "qtbase-abi-5-9-0"; And for qtdeclarative: title = "qtdeclarative-opensource-src"; is_affected = .depends ~ "qtdeclarative-abi-5-9-1" | .depends ~ "qtdeclarative-abi-5-9-2"; is_good = .depends ~ "qtdeclarative-abi-5-9-2"; is_bad = .depends ~ "qtdeclarative-abi-5-9-1"; -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: pkgkde-vcs issues
Hi Sandro! On Fri, Aug 25, 2017 at 10:56:46PM +0200, Sandro Knauß wrote: > i actually uploading the fixes for jessie and stretch for CVE-2017-9604. > > and therefor I have in the distribution field stretch/jessie and this is not > handled > $pkgkde-vcs tag -s > pkgkde-vcs: fatal: invalid Debian distribution for tagging - stretch > > this issue is reported under #873243. This is now fixed in Git. > And than also the upload of the tag is not allowed for messagelib but for > kdepim it worked... > > git push origin debian/16.04.3-3-deb9u1 > Counting objects: 1, done. > Writing objects: 100% (1/1), 865 bytes | 865.00 KiB/s, done. > Total 1 (delta 0), reused 0 (delta 0) > remote: [ REJECTED ] refs/tags/debian/16.04.3-3-deb9u1: expected tag name to > match (^debian/(4\%16\.04\.3\-3_deb9u1|16\.04\.3\-3_deb9u1)$) does not match > reality (debian/16.04.3-3-deb9u1) > remote: error: hook declined to update refs/tags/debian/16.04.3-3-deb9u1 Looks like the hook expects that ‘~’ is replaced with ‘_’, not with ‘-’. This is also what DEP-14 suggests. I propose to fix pkgkde-vcs to change the replacing. Any objections? -- 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
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 > <packa...@qa.debian.org>. 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
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: QtWebEngine build fails
Hi Sandro, On Tue, Jan 10, 2017 at 04:03:33PM +0100, Sandro Knauß wrote: > Hey, > > Your patch should fix this for indep+arch builds. > But the patch break indep only builds, because we need also for indep build a > dh_auto_install call. to install the files for examples. Only docs are created > by dh_auto_build -- INSTALL_ROOT=$(CURDIR)/debian/tmp install_docs > > I see two possibilities: > * moving deletion of the files to override_dh_install-arch > * copy the part to indep too > > Any other solutions? How about the now attached patch then? (Also not tested.) Also note that -i flag to dh_auto_install does not make any sense. -- Dmitry Shachnev diff --git a/debian/rules b/debian/rules index 1ca6979..5e8b7db 100755 --- a/debian/rules +++ b/debian/rules @@ -159,8 +159,7 @@ override_dh_auto_install-arch: # Remove libtool-like files rm -fv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.la -override_dh_auto_install-indep: - dh_auto_install -i +override_dh_auto_install-indep: override_dh_auto_install-arch dh_auto_build -- INSTALL_ROOT=$(CURDIR)/debian/tmp install_docs override_dh_install-arch: signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: QtWebEngine build fails
Hi Sandro! On Sun, Dec 25, 2016 at 02:14:12AM +0100, Sandro Knauß wrote: > Hey, > > qtwebengine [0] entered sid today and unfortunately it failed for some archs. > well it is one of those packages, that needs more than 4GB RAM/space for > building. IMO I think the i386 build failed just because the buildd has not > enough ram/space for the build. [1] In qtwebkit we are using -Wl,--no-keep-memory [1]. Maybe it will help you too? (Honestly I don't know why it is a patch and not a line in debian/rules.) > For armel[2] i'm not sure what package I should add to build-deps: > libc6-dev-armel-cross, libc6-dev-armhf-cross or libc6-dev, can you give me a > suggestion what to select? You should not add any of these packages. The compiler flags of the failing command -mfloat-abi=hard. It is a bug in qtwebengine build system: on armel the float abi is soft, not hard. [1] https://anonscm.debian.org/cgit/pkg-kde/qt/qt5webkit.git/tree/debian/patches/reduce_memory_usage.patch -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: kitemmodels python bindings
Hi Harald! On Wed, Nov 30, 2016 at 01:41:56PM +0100, Harald Sitter wrote: > Ahoy ahoy, > > I gave packaging the new python bindings in kitemmodels a stab and was > hoping for some peer review as I haven't created a python package in > years. > > https://packaging.neon.kde.org/frameworks/kitemmodels.git/commit/?id=8f6ffd64e7f7655f4780697a8046b09bcd2432e5 > > One thing I am particularly unsure about is whether or not > usr/lib/python3.Y/ is an acceptable installation path or if indeed > coercing it to be usr/lib/python3/ is the way to go. The latter, it should be moved into usr/lib/python3/. Please also run dh_python3 and dh_sip3 in debian/rules (i.e. somehow add python3,sip3 to the dh --with list). It is not mandatory but highly recommended to build for all supported Python 3 versions. At the moment we only have one version (3.5) so this may be tricky to test, but please take a note for the future. Re your problem with the __init__.py file: > - __init__.py is meant to be packaged separately by one bindings generating > framework but shared across all of them. as a result we have a package > which only contains the __init__ and a package for the actual module > I find this fairly shit but apparently the rest of the world doesnt care You can use a python3-pykf5.kitemmodels.pyinstall file for that. This way the __init__.py will be not part of the package, but generated by the postinst script on the system if it does not already exist. See dh_python3(1) for details. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Bug#842574: transition: qtbase-opensource-src
Dear release team, On Tue, Nov 01, 2016 at 09:17:46AM +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > Go go go! Please also binNMU plasma-integration against the new qtbase. It links with the static library libQt5PlatformSupport.a, and should pick up the new version of it. That should fix crashes of applications which have QSystemTrayIcons when running under Plasma. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Bug#842574: transition: qtbase-opensource-src
Hi all, On Mon, Oct 31, 2016 at 12:28:17AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > [...] > - I don't know if Dmitry would like to update pyqt5 or not, but he will > handle > that for sure (we are working on this together after all :-) ) PyQt5 just needs a binNMU. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: QtWebEngine ready for upload
Hi Sandro,
On Thu, Oct 27, 2016 at 05:28:20PM +0200, Sandro Knauß wrote:
> Hey,
>
> after days I spent inside the copyright file. I think now QtWebEngine is now
> ready for upload. Could somebody please review the package?
> If it helps I can also upload one built to mentors, because it takes ~2h on
> my
> machine.
Please rename the binary packages for consistency with other Qt modules:
* libqt5webengine-dev → qtwebengine5-dev (cf. qtbase5-dev)
* qt5webengine-examples → qtwebengine5-examples (cf. qtbase5-examples)
* qt5webengine-doc{,-html} → qtwebengine5-doc{,-html} (cf. qtbase5-doc)
Which script did you use for generating debian/copyright?
It would be nice to get that documented in debian/README.Debian
(with instructions on how to update that file for newer releases).
There are also some weird entries there, like:
Files: src/3rdparty/chromium/third_party/skia/*
Copyright: 2008-2016, Google Inc
2015, Google Inc.
2015, Google Inc." "
2013-2015, Google, Inc
[...]
block
block suitable for this language, with the
License: BSD-3-clause
In any case, the FTP masters will do a more thorough review of copyright
file than me :)
> I packaged the 5.7.1 snapshot, that is built against Qt 5.6.1 (sid)
> successfully, should it uploaded to experimental or testing? Tighen dependency
> to one specific Qt version?
It would be nice to depend on 5.7.1~20161021 versions of Qt (again like we
do in all the other modules). However qtwebchannel 5.7 is not yet available,
and qtdeclarative is only available on amd64/i386 at the moment, so I do not
insist on this.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: gpgme 1.7.0~ alpha or beta to debian experimental?
On Fri, 07 Oct 2016 08:54:53 -0400, Daniel Kahn Gillmor wrote: > I've been reading about -fPIC and -fpic and -fPIE and -fpie and -pie for > years and i confess i've never completely understood the differences or > whether one is "stronger" than another. > > gcc says of -fPIE and -fpic "generated position independent code can be > only linked into executables." which makes it seem odd that these > parameters would be passed through to building libraries in the first > place. -PIC implies -fPIE. Replacing -fPIE with -fPIC is the right thing to do, and is needed to get the code working with Qt 5.4.2+. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: qtdeclerative tests fails on various archs
Hi all, On Thu, Oct 06, 2016 at 11:32:23AM +0200, Allan Sandfeld Jensen wrote: > In the first one 32-bit big-endian doesn't work. I assume that is before my > patch, and in the second all the 64-bit non x64 platforms fail, including the > little endian? Yes, in the first one (5.6.1) there are failures on 32-bit big-endian archs. We do have your change cherry-picked (as fix-V4-on-big-endian.patch), but we do not have https://codereview.qt-project.org/162712, so the broken setTag() / setValue() methods are still there. I will try fixing them when I have time. The second one (5.7.0) should get a lot better soon: some failures were because of symbols diffs, I have just done a new upload to fix them (this upload also backports a patch to fix arm64). -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: qtdeclerative tests fails on various archs
Hi Sandro, On Fri, Sep 30, 2016 at 09:38:21AM +0200, Sandro Knauß wrote: > Hey, > > now after we manged it to get the auto tests running for qtdeclarative > (5.6.1-10) on some archs. Other archs are still failing to run the tests with: > > [...] > make[6]: Entering directory '/«PKGBUILDDIR»/tests/auto/qml/parserstress' > /«PKGBUILDDIR»/tests/auto/qml/parserstress/target_wrapper.sh > ./tst_parserstress > Makefile:362: recipe for target 'check' failed > make[6]: *** [check] Segmentation fault > make[6]: Leaving directory '/«PKGBUILDDIR»/tests/auto/qml/parserstress' > > (happens on: mips, powerpc, alpha, freebsd, sparc64, x32 - have they anything > in common? ) > > I'm a little bit glueless why the start of the tests would fail on some archs. Yesterday I filed two bugs for this: https://bugreports.qt.io/browse/QTBUG-56264 (sparc64, see also comments there) https://bugreports.qt.io/browse/QTBUG-56271 (powerpc) I will try to do more debugging on porterboxes when/if I have time. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt install binary path
Hi all, On Wed, Sep 28, 2016 at 08:11:31PM +0200, Sandro Knauß wrote: > > Well, yesterday I took your branch and build it without issues (tests ran > > just fine). But somehow buildds seems to disagree with me, as it seems a > > test is failing there. > > > > Is there anything I might be missing? > > I don't know. From the tests it is the qmlplugindumper, this actually should > list all plugins. So it maybe a problem for him to find the correct path for > the plugins? Maybe some envrionment variable got from our systems ( with a > KDE5 running) into sbuild and makes the test passing? Or any writepermission > on the buildds stops one try to write a file? I have added some qDebug() calls, and the build on Launchpad tells me this: /«PKGBUILDDIR»/bin/qmlplugindump: error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory Setting LD_LIBRARY_PATH=$(CURDIR)/lib should fix this issue, I will test and upload that now. While I am here, a note regarding your changes. Please never use dbus-launch and/or dbus-x11 package. See [1] for details. I have now reverted that in Git. [1]: https://lists.debian.org/debian-devel/2016/08/msg00554.html -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Letting Qt5 build on ppcspe
Hi all, (CCing also Adrian who filed #824971 and is probably interested in getting Qt bootstrapped on powerpcspe.) On Mon, May 30, 2016 at 03:36:15PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi Roland! Just for the record, for what I see in [build] you just need to > build qtchooser without tests (and so dropping qtbase5-dev from build > dependencies) in order to bootstrap it (or build it with nocheck in > DEB_BUILD_OPTIONS). > > [build] http://deb.li/qt5builds I have pushed a commit [1] that removes the build-dependency on qtbase5-dev for stage1 and nocheck build profiles. I hope that will make the bootstrapping easier (if not, please let me know — this is the first time I deal with build profiles). If it works for you we will do a new upload shortly. [1]: https://anonscm.debian.org/cgit/pkg-kde/qt/qtchooser.git/commit/?id=e2116ce53bf7224d -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: no time for calligra anymore
Hi Adrien, On Sun, Feb 07, 2016 at 11:05:53AM +0100, Adrien Grellier wrote: > Hi, > > Sadly I have not anymore time to dedicate to calligra. The package is not in > a very good state since a couple of months, I am sorry about that. > > If someone want to take care of it (Dimitry?), please do it. If you meant me, then no — I am not even a calligra user :) -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Bug#802659: dbus-python: Please drop recommends on PyQt4 packages
Hi Simon, On Tue, Jan 26, 2016 at 06:49:11PM +0100, Simon McVittie wrote: > On 26/01/16 10:37, Dmitry Shachnev wrote: >> My point was that Qt main loop is usually used on Windows / OS X but *not* >> on Debian. Here, Qt is compiled with GLib support and will use GLib main >> loop unless explicitly asked not to do so (via QT_NO_GLIB=1 env variable). >> That is a very rare use case and I don't see why one will ever need it. > > Am I right in thinking that Qt programs always the same external-facing > main-loop API, and that results in callbacks being scheduled from GLib's > GMainContext on Debian under normal circumstances, or from Qt's built-in > equivalent of GMainContext/libevent/etc. on Windows, OS X, or with > QT_NO_GLIB? Right. Applications always use QCoreApplication/QEventLoop, that creates an event dispatcher internally, which is different on different platforms. On other platforms it may also use platform-specific dispatchers, though it is not relevant for us. For UNIX the logic is at: https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#489 > dbus-python needs two things to work with a particular main-loop: it > needs to be told how to make that main-loop monitor libdbus connections > (a dbus.mainloop.* module), and the application author needs to actually > be iterating that main-loop. > > For GLib, dbus.mainloop.glib is bundled with dbus-python, but the > application author also needs to iterate the GLib main-loop via PyGI, > either directly or by using a higher-level API like Gtk or GApplication. > For Qt, dbus.mainloop.whatever replaces dbus.mainloop.glib (but on > Debian, dbus.mainloop.glib would also work), and QApplication replaces > PyGI (but on Debian, PyGI would also work). > > The "main loop" terminology for the dbus-python addons is perhaps > unfortunate; it's really more like "event dispatcher integration glue". I know — I have been playing with that stuff a bit in past :) >> If you don't remove these packages from Recommends, then at least please >> replace them with their modern PyQt5 alternatives, i.e.: >> >> python-qt4-dbus → python-dbus.mainloop.pyqt5 >> python3-dbus.mainloop.qt → python3-dbus.mainloop.pyqt5 > > I've done that in git for now, while we decide whether to remove them > altogether. Thanks! -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
On Fri, Jan 22, 2016 at 05:43:59PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. That's what I think we should do, too. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Debian, (Py)Qt5 and QtWebKit
My original response was rejected by lists.alioth.debian.org because the
domain Qt uses for mailing lists is blacklisted.
Re-sending it again with a couple of different links (to the mailing list
only, as the CCed people already got it)…
--
Hi Florian,
On Mon, Jan 25, 2016 at 08:12:02AM +0100, Florian Bruhin wrote:
> I'd like to discuss the future of Qt5's QtWebKit (and PyQt's bindings
> for it) in Debian. Looking at the Qt 5.6 beta, it seems like Qt
> upstream will definitely remove QtWebKit - not only from the binary
> releases, but from source releases as well.
As I have just said on another mailing list, I heard that the source
releases will be kept (at least for 5.6.x):
http://article.gmane.org/gmane.comp.lib.qt.devel/24301
http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/#comment-1196968
> As it's likely many packages will still need a Qt5 QtWebKit, and based
> on [1] ("Qt5's WebKit is expected to stay supported until Qt6") it
> looks like Debian will still continue to support it, if necessary
> building from upstream's git[2]?
Yes, we are going to continue support for QtWebKit (5.x).
> As for the PyQt5 wrappers for QtWebKit, upstream says[3]:
>
> > AIUI, they are still providing source releases. You're going to
> > continue to support that, right?
>
> Yes, if they are part of the official release. If not then I won't
> do anything to break things, but they won't be officially
> supported.
As one of my packages (retext) uses PyQt5's WebKit module, I won't drop it
and do my best to make sure they work.
We are even recommending it as a replacement for PyQt4's WebKit which we
want to drop.
> I'm planning to open an ITP for my project[4] using PyQt and
> (currently) QtWebKit soon, and I'm guessing for at least Eric[5] and
> Calibre[6] this is a problem as well.
>
> Will Debian also support PyQt's QtWebKit until Qt 6 if possible?
> If not, what will happen with the packages which depend on it?
So to sum up: I will support PyQt's QtWebKit as far as it doesn't become
absolutely impossible to do so.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Tightening dependencies within the source package
Hi, As you already know, in Qt 5.6 there was a change in ELF versions, from @Base to @Qt_5. I have developed a script for that (migrate-symbols.py) that scans the build log and updates the symbols files accordingly. That script changed the ELF version tags, but it did not touch the package version numbers. Now I have a bug: qttools5-dev-tools dependency on libqt5help5 is not enough: it depends on libqt5help5 (>= 5.0.2), however fails to work with 5.5: /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator: /usr/lib/x86_64-linux-gnu/libQt5Help.so.5: version `Qt_5' not found (required by /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator) How can I make sure a proper dependency is generated? Using -V flag of dh_makeshlibs does not help. Of course I can bump all symbols versions to 5.6.0~beta, but I don't think it is a proper solution (and also it will destroy the existing symbols history). Does anyone know a better solution? -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Tightening dependencies within the source package
On Thu, Jan 07, 2016 at 09:18:16PM +0100, Pino Toscano wrote: >> But thinking more about this, maybe bumping the versions is really a >> better solution. > > Yes, it is. You are right. Thanks! Done in [1]. To Lisandro or whoever will be updating other Qt modules to 5.6: I have now added an option to migrate-symbols.py which will bump all versions. Use it like this: .../scripts/migrate-symbols.py --version 5.6.0~beta build_log.txt [1]: https://anonscm.debian.org/cgit/pkg-kde/qt/qttools.git/commit/?id=0955f0e6d9097993 -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: New Base for symbols in Qt5.6
On Sun, Dec 27, 2015 at 03:41:39PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: >>> Dmitry: we still need to look for private symbols as we used to, IIRC >>> there >>> where some cases of upstream not marking private symbols as such. having >>> both methods at hand will surely catch those cases. >> >> However I also know that our current algorithm has some false positives — >> i.e. it marks functions using *pointers* to private objects as private, even >> if they are part of public API. I thought that by fully switching to >> upstream algorithms, we will get rid of that bug. > > Do you have an example of such a case? The script was being run over private > headers only, so even pointers to private functions should be private. There was a case where the inline constructor for a public Qt class called internally another (private) constructor which accepted a pointer to a private Qt class as an argument. Thus a package using that inline constructor ended up with wrong dependency on qtbase-abi-x-y-z, even though it used only public API. Unfortunately I couldn't find that in irclogs, but we have definitely discussed that. >> Do you have any examples of "upstream not marking private symbols as such"? > > Forget that, I mixed stuff. The symbols are marked as private by using a list > created by syncqt.pl, so things should be fine. OK, so just using my script is probably fine. >> In any case I think we should keep the logic in pkg-kde-tools package, i.e. >> replace the existing script with mine or extend its logic. I hope Python >> dependency is not a problem, is it? > > I'm totally for it. If it becomes a problem for someone we can consider > generating a new binary package from the same source and adding the python > dependency there. We might even do that from the beginning. Maybe we should actually rewrite it in Perl or shell. (Any volunteers? :)) > OK, I've checked the branch and I merged it to experimental. Please do not > forget to add the proper copyright headers to the scripts. Ack. > Should we keep the merging script? I think having it on git's story should be > enough. I also don't mind shipping it once in the packages. This script should be used only once for all Qt 5.6 modules. So maybe let's keep it in Git until we migrate all the modules, but not ship in any binary. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"
Hi Steve, On Sun, Dec 27, 2015 at 12:08:45PM -0600, Steve M. Robbins wrote: > DigiKam itself currently uses (Qt4-version) libqtwebkit-dev. I saw the bug > about it and the web page https://wiki.debian.org/Qt4WebKitRemoval > What I haven't seen is a precise time for this. The schedule for Digikam 5 > release is May, so I (hopefully) won't need to care after that. Is the webkit > going to be removed before next May? Actually I would like it to be removed before May. I am going to bump bugs severities to important soon (in January) and make them RC a couple of months after that (i.e. in March) to get the packages removed from testing (or fixed). I am also going to remove the PyQt5 QtWebKit bindings very soon (in a couple of weeks). So maybe it's not the best idea to introduce a new package using QtWebKit. Lisandro, you did not reply to this part of Steve's message, what do you think? -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"
Hi Steve, On Mon, Dec 28, 2015 at 07:30:52AM -0600, Steve Robbins wrote: > Just for clarity: I'm talking about digikam not a new package. Oh, I missed the fact that digikam is already depending on qtwebkit. Then, indeed, please ignore my message and go ahead (as Lisandro said). -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: New Base for symbols in Qt5.6
Hi Adam, On Mon, Dec 28, 2015 at 11:08:27AM -0600, Adam Majer wrote: > AFAIK, this is only to check symbols at build time? So Build-Depends > on python (or python-minimal) and no additional runtime depends. There > is no use creating work where none is required, especially if we > already have the most readable language out of the three :D I wanted to add my script to pkg-kde-tools, and make it depend on python3. This will allow me not to add that build-dependency to every Qt source package. Unless someone minds, I will do that tomorrow. (I also thought about preserving the compatibility with the previous script, i.e. reading the WRITERESULTS env variable, but who needs env variables when there are commandline options?) -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: New Base for symbols in Qt5.6
Hi Lisandro, On Sun, Dec 27, 2015 at 02:22:20AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Now we feared that this change would create us problems with loading apps > compiled against older versions of Qt. In order to test this I built qtbase > 5.6 beta with this changes: > > - sed -i 's/@Base/@Qt_5/g' # yes, private symbols would get this wrong. > - Build qtbase and get symbols changes. > - Process them with pkgkde's symbolshelper. In this step private symbols will > get corrected by marking as missing the @Base versions and "new ones" > appearing with @QT5_PRIVATE in them. > - Build again this time succesfully getting the binary packages. > - On a VM I installed both an app I compiled with Qt 5.5 and hexalate, which > only require stuff present in qtbase and qt5.6~beta's qtbase5-dev and > dependencies. > - ssh -X the VM and run them both without issues. My script (debian/scripts/migrate-symbols.py in qt56-symbols branch) is *much* smarter than plain sed -i 's/@Base/@Qt_5/g'. Its algorithm is: 1. Get the list of symbols in new libraries based on the build log. 2. For each symbol in the symbols file, check if that symbol exists in the new libraries. - If it exists, changes the version part of the symbol to Qt_5 or Qt_5_PRIVATE_API, depending on what's found in the new library. - If it doesn't exist, leaves it unchanged (maybe the symbol is for another architecture) so that we can process it the usual symbolshelper- based way. 3. For each old symbol that has disappeared, and is not optional or private, warns that it is removed. For qtbase its output is: http://paste.debian.net/355955/ And yes, changing the version part of the symbols does not break the ABI, however removing the old symbols does (so we need to be careful). > So I think it's safe to go ahead with the changes. So are you OK with merging my branch? :) I have just updated it based on i386 build log. > Dmitry: we still need to look for private symbols as we used to, IIRC there > where some cases of upstream not marking private symbols as such. having both > methods at hand will surely catch those cases. However I also know that our current algorithm has some false positives — i.e. it marks functions using *pointers* to private objects as private, even if they are part of public API. I thought that by fully switching to upstream algorithms, we will get rid of that bug. Do you have any examples of "upstream not marking private symbols as such"? In any case I think we should keep the logic in pkg-kde-tools package, i.e. replace the existing script with mine or extend its logic. I hope Python dependency is not a problem, is it? P.S. I will be offline most of today, will be able to look at anything only tomorrow (MSK time). -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
Hi all,
On Thu, 29 Oct 2015 17:46:12 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> a) Suggested by Adam Majer and improved by Felix Geyer: if package A gets
> built against any qtbase x.y.z lib make it depend upon the version used to get
> the package built by using Build-Depends-Package from deb-symbols(5).
>
> With this solution we ensure that the libs gets tied together, but also apps
> rebuilt against this version. I don't know if there is a real use case for
> apps migrating faster than Qt itself except for simplifying transitions (and
> we still don't know how safe that could be).
>
> We can't use this solution for arch:all packages.
This will help us keeping the stack together in only one direction: in theory
it can happen that i.e. qtbase migrates but qtx11extras does not.
If we want to tighten the dependencies in both directions, we can just write
some debian/rules code that will add this to ${qt5:Depends}:
libqt5core5a (>= 5.x.y~), libqt5core5a (<< 5.x.(y+1)~)
where x and y are extracted from upstream version number (i.e. from parsing
debian/changelog). Then we will can make all arch-dependent packages depend
on ${qt5:Depends}. (This is similar to what GNOME does, IIRC.)
Re arch:all packages, we don't really have many of them. We have docs, but there
is no need to tighten dependencies for docs packages.
If there is a qtfoo library that needs a qtfoo-common package of exactly the
same version, it can just depend on qtfoo-common (= ${upstream:Version}). So
there is really no problem with arch:all packages.
> b) Somehow (I think KDE does this) create a variable to be used in
> debian/control so it get substituted at build time against whatever we set up
> in, let's say, qtbase. We can use that variable in the whole Qt stack
> including source packages that build arch: all binaries like translations.
> Docs should not depend on binaries so maybe we need something different there.
The problem is that we do not have a common arch:all package that everything
should depend on. qttranslations5-l10n will not work because it is not in qtbase
and it's optional (we don't really want to depend on translations).
--
Dmitry Shachnev
signature.asc
Description: OpenPGP digital signature
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Bug#777981: lightdm: ftbfs with GCC-5
Hi Yves-Alexis, On Sat, 08 Aug 2015 19:04:21 +0200, Yves-Alexis Perez wrote: I somehow missed this bug. I'm a bit unsure what to do with those symbols updates. I guess it's related to some libstdc++ change but I'm unsure what that really means for me. Should I just update the symbols files here? (I'm really not fluent in Qt or C++ so really any help appreciated here). All symbols that are removed in the diff are destructors for Qt classes that are not part of Qt's own ABI (i.e. declared inline or template instantiations). These symbols are not exposed to users of your library and can be safely removed from the symbols file. You usually only need to worry if the symbols diff contains __cxx11, in this case there are no symbols containing this so you are safe. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Ubuntu's Qt Base packaging in Debian git
Hey, On Fri, 22 May 2015 12:19:21 -0300, Lisandro Damián Nicanor Pérez wrote: On Friday 22 May 2015 17:26:18 Timo Jyrinki wrote: Hi, Let's discuss this here. At least mitya57 has wished for Ubuntu's Qt packaging to from Launchpad to Debian git, similar to how Kubuntu (Ubuntu's KDE flavor) has moved KDE packaging to Debian git branches. Lisandro however wanted to discuss this more formally and I agree. Yes, I fully support moving the packaging to Git. Even though I am less active in Ubuntu than in Debian, this will help me to know what the delta is and cherry-pick it to Debian. Also, Timo sometimes updates the packaging to new upstream versions earlier than we do that in Debian, and having that in Git is also helpful in that case. I was planning to follow mesa (http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git) way of using eg ubuntu and ubuntu+1 branches. With my I really don't understand much of how ubuntu works hat on I like the idea with minor exception: I would keep debian branches as they currently are: master for whatever has to go to unstable, experimental, release, etc. And this just to keep the current workflow, nothing more, nothing else. Re the branch naming scheme: I am fine with any scheme, I just want to document pros of using kubuntu_*: - We already have kubuntu_unstable branches (created by Rohan) for all Qt modules, which currently do not have Ubuntu delta actually applied there. I think it's quite confusing. - kubuntu_* names are already used for KDE and Qt 4 packages. It might be easier if our names are consistent. Timo said that the packaging is for whole Ubuntu, not just Kubuntu. However the previous Bzr repositories also had kubuntu in their name, so I don't think anything changes here. I don't mind doing it either way, both have pros and cons. Like: Pros Debian git - Closer to Debian where a lot is directly synced from anyway - Easier for Debian people to see what Ubuntu is doing differently if interested. Third pro: - It's git, not bzr :) Cons Debian git - Limits access to pkg-kde people - Brings all Ubuntu commits to Debian git Related to the first con, practically all commits in the Ubuntu Launchpad branch have been done by people who are both Ubuntu developers and Debian pkg-kde members. I also prefer that all changes go through those people. Other people in Ubuntu (on the Unity 8 side) are used to going through me for Qt patches/changes. And Kubuntu people are familiar with going through Debian. If we keep this as a hard rule to follow, I'm all for it. If someone from Ubuntu wants to be able to commit [s]he has to follow the same principles for every new contributor: show patches until we know we can trust her/him (including workflows, atomic commits, not pushing non upstream-ACKed patches except for packages/very very special cases and proper discussing them before doing the commit, etc). I want to stress that this is the same current requirement we have for Debian, and we are happy to help people to get familiar with them. I agree. I was currently planning to do this only for qtbase, as that's where most of the action happens. 14 Qt packages are directly synced from Debian as is, and the rest with modifications (qtdeclarative, qtwebkit, qtgraphicaleffects, qtmultimedia, qtsensors, ...) have more minor changes than qtbase. Many have just transitional packages until the next LTS release. *If* we follow the approach which we are discussing here I do not mind if you extend the usage to other Qt repos, and of curse you are free to do it whenever you see fit. Yes, I think that if we have qtbase in Git, then we should have anything else in Git as well. We can also convert the old repositories to be Bzr mirrors of the new Git branches, in case something (CI?) needs it. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Moving forward on fixing bug 721938
On Thu, 23 Apr 2015 10:28:56 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Does [0] works without patching qt4? [0] https://github.com/davidedmundson/qtsystemtraypreloadhack That looks like a not-yet-written code. Also I don't see how we would be able to use it in Debian: it will need to be LD_PRELOAD'ed to all Qt 4 apps. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
qtwebkit 2.3 review
Hi Andreas, I took a look at your qtwebkit branch. It mostly looks good, some notes: - Calling dh_install in override_dh_auto_install target is wrong. Please properly split these two stages. - Also, please use .install files where possible, instead of manually copying files in debian/rules. - In Ubuntu, copyright file is much more complete than yours. I think you should borrow some lines from there (but be careful, some parts of it are wrong, like the last two lines). - The dh_builddeb override is no longer needed. Cheers, -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Help needed with qtcreator FTBFS on arm*
On Sat, Jun 21, 2014 at 6:15 PM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: I've tried to build it twice on an armhf porterbox and Dmitry Schanev tried on an armel qemu VM. In my case the porterbox would simply hang before reaching where the buildd gets, and I think the VM build also failed earlier. FWIW my armhf build segfaulted, but armel build succeeded: http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armhf.build http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armel.build Both were done in qemu. -- Dmitry Shachnev -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: On naming qml modules packages
Hi Lisandro,
On Sun, Mar 30, 2014 at 7:48 AM, Lisandro Damián Nicanor Pérez
perezme...@gmail.com wrote:
I'm so proposing to change the original naming scheme to:
qml-module-{$module-name}[version]
Where $module-name will be the lower-cased path replacing slashes with '-'.
Examples:
$QT_INSTALL_QML/foo/var/ would be packaged as qml-module-foo-var
$QT_INSTALL_QML/foo/var.2/ would be packaged as qml-module-foo-var2
$QT_INSTALL_QML/foo.2/var/ would be packaged as qml-module-foo2-var
$QT_INSTALL_QML/foo2/var.2/ would be packaged as qml-module-foo2-var2
What do you think of this? I plan to start packaging stuff (with the
transitional packages required) either for 5.2.1 as soon as the transition
finishes (we are almomst there) or for 5.3.0.
QtQuick1 is deprecated and not much matters, so I don't think we
should rename things just to prevent people from being confused by it.
But, anyway, your new package names are shorter (10-chars qml-module
vs 14-chars qtdeclarative5) and look nice, so I am fine with the
renaming.
--
Dmitry Shachnev
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
