Bug#881973: kde-spectacle: Please build against libkf5kipi32.0.0 in experimental
Package: kde-spectacle Version: 16.08.3-2 Severity: wishlist Currently you can't install gwenview from experimental together with kde-spectacle as both kde-spectacle versions (sid+experimental) are build against libkf5kipi31.0.0. Therefor hereby the request for a rebuild of kde-spectacle in experimental build against libkf5kipi32.0.0. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kde-spectacle depends on: ii kio 5.37.0-2 ii libc6 2.24-17 ii libkf5configcore5 5.37.0-2 ii libkf5configgui5 5.37.0-2 ii libkf5configwidgets5 5.37.0-2 ii libkf5coreaddons5 5.37.0-2 ii libkf5dbusaddons5 5.37.0-2 ii libkf5declarative55.37.0-2+b1 ii libkf5i18n5 5.37.0-2 ii libkf5kiocore55.37.0-2 ii libkf5kiowidgets5 5.37.0-2 ii libkf5kipi31.0.0 4:16.08.2-1 ii libkf5notifications5 5.37.0-2 ii libkf5screen-bin 4:5.10.5-2 ii libkf5screen7 4:5.10.5-2 ii libkf5service-bin 5.37.0-2 ii libkf5service55.37.0-2 ii libkf5widgetsaddons5 5.37.0-2 ii libkf5windowsystem5 5.37.0-2 ii libkf5xmlgui5 5.37.0-2 ii libqt5core5a 5.9.2+dfsg-4 ii libqt5dbus5 5.9.2+dfsg-4 ii libqt5gui55.9.2+dfsg-4 ii libqt5printsupport5 5.9.2+dfsg-4 ii libqt5qml55.9.2-3 ii libqt5quick5 5.9.2-3 ii libqt5widgets55.9.2+dfsg-4 ii libqt5x11extras5 5.9.2-1 ii libstdc++67.2.0-16 ii libxcb-cursor00.1.1-4 ii libxcb-image0 0.4.0-1+b2 ii libxcb-util0 0.3.8-3+b2 ii libxcb-xfixes01.12-1 ii libxcb1 1.12-1 kde-spectacle recommends no packages. kde-spectacle suggests no packages. -- no debconf information
Bug#881943: libqt5opengl5-dev should provide libqt5opengl5-dev-full-opengl on !armel/armhf
El 16 nov. 2017 5:42 p.m., "Adrian Bunk"escribió: Package: libqt5opengl5-dev Version: 5.9.2+dfsg-4 Severity: normal Tags: patch Different from other architectures, on armel and armhf Qt in Debian is configured to use OpenGL ES instead of full OpenGL. Some OpenGL-related functionality in Qt is not available with OpenGL ES, and Qt also offers direct access to OpenGL. This causes some packages to not build with libqt5opengl5-dev on armel and armhf, and while making them build would obviously be the best solution that is not feasible in cases where upstream does not provide any way to disable this kind of OpenGL usage or has alternative OpenGL ES codepaths. A package that does FTBFS on armel+armhf buildds after every upload is not ideal - it wastes buildd resources and makes it harder to find bugs between the expected FTBFS. The Architecture: field does not support negative ! syntax, and maintaining a completely list of all architectures except armel and armhf in every affected package is fragile. Please apply the following patch: Oh, interesting idea. We should really consider this.
kdevelop_5.2.0-1_amd64.changes is NEW
binary:kdevelop52-libs is NEW. binary:kdevelop52-libs is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Processing of kdevelop_5.2.0-1_amd64.changes
kdevelop_5.2.0-1_amd64.changes uploaded successfully to localhost along with the files: kdevelop_5.2.0-1.dsc kdevelop_5.2.0.orig.tar.xz kdevelop_5.2.0-1.debian.tar.xz kdevelop-data_5.2.0-1_all.deb kdevelop-dbgsym_5.2.0-1_amd64.deb kdevelop-dev_5.2.0-1_amd64.deb kdevelop-l10n_5.2.0-1_all.deb kdevelop52-libs-dbgsym_5.2.0-1_amd64.deb kdevelop52-libs_5.2.0-1_amd64.deb kdevelop_5.2.0-1_amd64.buildinfo kdevelop_5.2.0-1_amd64.deb kdevplatform-dev_5.2.0-1_all.deb kdevplatform-l10n_5.2.0-1_all.deb plasma-kdevelop-dbgsym_5.2.0-1_amd64.deb plasma-kdevelop_5.2.0-1_amd64.deb Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#881943: libqt5opengl5-dev should provide libqt5opengl5-dev-full-opengl on !armel/armhf
Package: libqt5opengl5-dev Version: 5.9.2+dfsg-4 Severity: normal Tags: patch Different from other architectures, on armel and armhf Qt in Debian is configured to use OpenGL ES instead of full OpenGL. Some OpenGL-related functionality in Qt is not available with OpenGL ES, and Qt also offers direct access to OpenGL. This causes some packages to not build with libqt5opengl5-dev on armel and armhf, and while making them build would obviously be the best solution that is not feasible in cases where upstream does not provide any way to disable this kind of OpenGL usage or has alternative OpenGL ES codepaths. A package that does FTBFS on armel+armhf buildds after every upload is not ideal - it wastes buildd resources and makes it harder to find bugs between the expected FTBFS. The Architecture: field does not support negative ! syntax, and maintaining a completely list of all architectures except armel and armhf in every affected package is fragile. Please apply the following patch: --- debian/control.old 2017-11-15 20:32:03.0 + +++ debian/control 2017-11-15 20:32:59.0 + @@ -365,6 +365,7 @@ ${misc:Depends} Breaks: qtbase5-dev (<< 5.4.0+dfsg-6~) Replaces: qtbase5-dev (<< 5.4.0+dfsg-6~) +Provides: libqt5opengl5-dev-full-opengl (= ${binary:Version}) [!armel !armhf] Description: Qt 5 OpenGL library development files Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. This allows packages that require Qt to use full OpenGL to change the build dependency from libqt5opengl5-dev to libqt5opengl5-dev-full-opengl, which will place them in BD-Uninstallable on armel and armhf.
Bug#879094: Status of the marble package.
Marble currently FTBFS in unstable due to a couple of missing symbols and this is preventing the libgps transition from finishing up. The version in experimental fixes the issue but it looks like uploading it to unstable would start a transition. What are the plans here? are the symbols that disappeared just template cruft or are they real ABI changes? are there any plans to transition the experimental version to unstable in the near future.
kmail_17.08.0-1_amd64.changes ACCEPTED into experimental, experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 2 Sep 2017 18:17:00 CEST Source: kmail Binary: kdepim-doc kmail ktnef Architecture: source all amd64 Version: 4:17.08.0-1 Distribution: experimental Urgency: medium Maintainer: Debian/Kubuntu Qt/KDE MaintainersChanged-By: Maximiliano Curia Description: kdepim-doc - transitional package kmail - full featured graphical email client ktnef - transitional package Changes: kmail (4:17.08.0-1) experimental; urgency=medium . * New upstream release (17.08.0) * Bump Standards-Version to 4.1.0. * Update upstream metadata * Update copyright file * Release to experimental Checksums-Sha256: de795a0aff37ef440625c22e361ec4ba613a864cfd11b64f7dcc16ea37a44cf2 4344 kmail_17.08.0-1.dsc 61611c6304649889627922845574e99ac43c55cf9d5e517d8de806cbe66b842f 12180 kmail_17.08.0-1.debian.tar.xz b7c99516f9a21e24f7e44d6292baa0b269d3e1c9f33ed82d6166aeacc2aa6c79 5526 kdepim-doc_17.08.0-1_all.deb 08a76a1726bb9943c2742f78cd56988871e255eadfae83d498e0151da0de11c5 31675614 kmail-dbgsym_17.08.0-1_amd64.deb c99729bfdfafb083f5fa04e35aa6c88ae7cf7699bd0b065d903ec30bcc32a32d 25709 kmail_17.08.0-1_amd64.buildinfo d58a5b269560a878e9f14782cc75366b4bcc10e4e104104ccdb62ae5735d8b7b 4714944 kmail_17.08.0-1_amd64.deb 0a7db156df24f3f4d8a395a55d236627919fc4891a239e11726a8cf6523a6fc8 5514 ktnef_17.08.0-1_all.deb 57c2301e245c9c22f38bdd27a6c1ca6d86cbaaac412ef309b75cbba4cababeed 4733360 kmail_17.08.0.orig.tar.xz Checksums-Sha1: db67c6f605922ce000d47ce02da1898c3f2c8869 4344 kmail_17.08.0-1.dsc edd40c3b6cb1f36d06fcd94896b086ecc0dd3891 12180 kmail_17.08.0-1.debian.tar.xz fff86a31faf12df5a427315ea33a4946237f843a 5526 kdepim-doc_17.08.0-1_all.deb a51eb1e5592dd683a0095af9e55204741fbdce09 31675614 kmail-dbgsym_17.08.0-1_amd64.deb 00e0d766604886202a52e2d16b244d41805734c4 25709 kmail_17.08.0-1_amd64.buildinfo f58557f08ccde18fc575f390a915be85e60a7579 4714944 kmail_17.08.0-1_amd64.deb c0e8ac044c3987b44146b824d883e0da0c42271e 5514 ktnef_17.08.0-1_all.deb 99ad201f4cdf242e1f6484414cdcfad7b237afa8 4733360 kmail_17.08.0.orig.tar.xz Files: 51f201a5708b5789db71e095f6bda939 4344 kde optional kmail_17.08.0-1.dsc 135e5830959393908ec19dca023e2d22 12180 kde optional kmail_17.08.0-1.debian.tar.xz b6c20a099b484a1f6bbd7f10ebc6685e 5526 oldlibs extra kdepim-doc_17.08.0-1_all.deb c0dcbcfe448d38ec72fe131921fed085 31675614 debug extra kmail-dbgsym_17.08.0-1_amd64.deb 4cc1fb8c23db57d4d99c598206225af3 25709 kde optional kmail_17.08.0-1_amd64.buildinfo ea9773e9403577e6f08a50f8dca3d9ec 4714944 mail optional kmail_17.08.0-1_amd64.deb a8be76c7ae624d2d9fdc18bf31ac6267 5514 oldlibs extra ktnef_17.08.0-1_all.deb d19106f76f9cb564cb25623b41edcb84 4733360 kde optional kmail_17.08.0.orig.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE+JIdOnQEyG4RNSIVxxl2mbKbIyoFAlmq2hQACgkQxxl2mbKb IyrVVw//WiHnvu+QPM/hystMeZy1ESyalbgm2uz/gvtMUMxiKzgZDvfd2A++rgcs bf+mq1D1s0JBVxPMMg117WOfMTEjXxQDKsv31raO0bRhrWttzx0LT74tmo8I1Ggv esX5YXX5a74wHDfg+sqL8I689c7UGiFeVk4vEqOzkvn2AvHUUwEMUCKbk4r+Gr0x 1OSX0Nxbfx2ubnFsQuiJ5B/2h+e6x7OqbS1S6sm/72sye5rveI0Jf3KKy5P6DWtr C2mIKmyrmX/bK9VayWcDyRUrZUSsjz6CJXO1uPxnjx6k+XQ2dWMkKo6Vqo5tJ+Er YiBgSlh+b7USxJcp/aNfijF9xBqfzu6Dh+SiuxA93JbjDR17HvAL2JqMVyTyk6rB IPOdx9fSs6uWM++Bk3xmEHyuhU/o6idxSdGuS1hCaNdRKqk5yKXMa7rnjIFLxAIt EYdFd95VJOYcHsWbhfSlmclUCjclGAyrwWxgElw0nmvTURTnMXv6AJ/XsrMjU0tg 5aa/8bXEiYO4SLNUzjgo03VbO2TJvC5wa+Z8KM1pECCIgxe4VT6FqmB4gdlnmv8I 6iPTxCpnWqhxVKsljT+KS8TrOuGYL9E5rXSMyVNFm4mfTGl5q0i/ZM9Py1y/um/b jtvSoQsiSrfYmwUsZd3VSF4pOHPH6L+lFJIyJb98iRiv1/38FoI= =WmM9 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Re: Bug#876901: QFINDTESTDATA uses __FILE__
On jueves, 16 de noviembre de 2017 13:22:00 -03 Ximin Luo wrote: [snip] > I pointed to the various C standards documents, as well as documentation > from multiple compilers, stating that __FILE__ is the "name of the source > file" and in no way guarantees that the expansion can later be re-used as > the path to an actual file. GCC documentation even explicitly states the > expansion is arbitrarily chosen by the implementation of the preprocessor, > and is explicitly "not [..] the input file name argument". OK, let's agree we do not agree here. > So I do consider this a bug in the QT test suite. > > The ideal solution would be to not use __FILE__ - that has numerous other > benefits as well. But if this is too complex to change, I also suggested a > 1-line addition to d/rules - which I agree would be "papering over" the > issue. However, it's a simple 1-line change so I don't understand why there > is so much resistance to it. Because it means diverging from upstream and that causes us *lots* of headaches when trying to solve unit tests issues with upstream's help. > There are several other possible solutions, all of which are low-cost and > unintrusive, and could be done in a QT build helper in one single place: > > - define a custom macro, QT_TEST_SOURCE_BASE, and set that in the test build > scripts, instead of using __FILE__ - export > BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP:tests=$BASEDIR/tests" - > symlink "$srcpkg-$version" -> "." > > I would be very happy to send you the patches myself if you don't want to do > the work, since writing 1-line patches to a few QT projects, costs far less > time than patching 1800 packages across Debian. Let me propose you something: create a suitable patch for upstream that makes stuff work no matter the distro not OS. As I do think your approach is not correct you should push it yourself, see http://wiki.qt.io/Qt_Contribution_Guidelines for knowing how to contribute it. -- May the source be with you. 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#876901: QFINDTESTDATA uses __FILE__
Lisandro Damián Nicanor Pérez Meyer: > By the way: is there a macro or combination of macros which *default* value > can be replaced in the use of __FILE__ without caussing regressions? > > Because if that's the case it's easier to convince upstream people that > changing the usage goes in favor of reproducibility without using strange up- > to-the-builder definitions. > Unfortunately, not that I know of. However, let me try to explain why BUILD_PATH_PREFIX_MAP is not as strange as you might think. GCC already supports a flag -fdebug-prefix-map whose purpose is to do the same thing for debugging symbols. You can give multiple maps, to map different parts of your source tree to different other source directories. So maybe one could give a map like this: 1. "PWD/" -> "/usr/src/debug/$mypackage" 2. "PWD/tests" -> "./tests" if one wanted to generate debugging information for your main source code, to point to installed-source-code at /usr/src/debug/$mypackage; but since one doesn't install the tests anywhere, it would be convenient for developers to have the debuginfo of tests point to ./tests instead, so they can just run "gdb -d." if stuff fails. What I'm suggesting for QT tests would be exactly analogous to this already-supported use case for debuginfo. dpkg gives a default map corresponding to (1), and since QT tests use __FILE__ for other purposes, you give a second map corresponding to (2) above. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#876901: QFINDTESTDATA uses __FILE__
Lisandro Damián Nicanor Pérez Meyer: > [..] > > Yes, we do understand that your workaround solves the issue, but we do also > understand that we should not be using this workaround in the first place. > > Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider > that this change will be insta-RC I'm afraid. > Guillem: the TL;DR is that some QT tests fail (with our reproducibility GCC and dpkg patch) because they depend on __FILE__ to point to a real path, but the patched dpkg rewrites it in all packages so that a prefix $PWD changes to $srcpkg-$version, which doesn't exist. A simple fix on the dpkg side would be to instead rewrite $PWD to ".", much like -fdebug-prefix-map is done currently. However this loses some information and makes it hard to distinguish different packages that might share filetree structure. But that is the best fallback option IMO, if we decide that we don't want to auto-break QT tests for using __FILE__ (IMO, inappropriately). > Xi: you have found a *wonderful* way to find where bugs are, please try to > fix > the relevant code and not paper over it, because in the Qt case it is not a > bug on our side. > I pointed to the various C standards documents, as well as documentation from multiple compilers, stating that __FILE__ is the "name of the source file" and in no way guarantees that the expansion can later be re-used as the path to an actual file. GCC documentation even explicitly states the expansion is arbitrarily chosen by the implementation of the preprocessor, and is explicitly "not [..] the input file name argument". So I do consider this a bug in the QT test suite. The ideal solution would be to not use __FILE__ - that has numerous other benefits as well. But if this is too complex to change, I also suggested a 1-line addition to d/rules - which I agree would be "papering over" the issue. However, it's a simple 1-line change so I don't understand why there is so much resistance to it. There are several other possible solutions, all of which are low-cost and unintrusive, and could be done in a QT build helper in one single place: - define a custom macro, QT_TEST_SOURCE_BASE, and set that in the test build scripts, instead of using __FILE__ - export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP:tests=$BASEDIR/tests" - symlink "$srcpkg-$version" -> "." I would be very happy to send you the patches myself if you don't want to do the work, since writing 1-line patches to a few QT projects, costs far less time than patching 1800 packages across Debian. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Re: Bug#876901: QFINDTESTDATA uses __FILE__
Explicitely CCing Guillem for this one. On miércoles, 15 de noviembre de 2017 23:01:00 -03 Ximin Luo wrote: [sip] > The GCC patch (neither the previous nor the planned version) does not change > the default behaviour of __FILE__, and was never intended to. Instead, it > gives users the ability to rewrite __FILE__, more specifically a prefix of > it. So it basically does not changes the default __FILE__ behavior, so neither GCC nor other projects upstream developers will have anything to complain... > > There is a separate patch to dpkg that enables this ability for all > packages, in the same way that SOURCE_DATE_EPOCH is enabled. Guillem the > dpkg maintainer has previously indicated that he's happy to take the patch, > once GCC accepts their end of it. ...except for a Debian self-inflicted change that will *only* happen while building Debian packages, but not when using it for normal developing processes. > It's a combination of these two patches that would cause these QT tests to > fail. The reason it fails, is because we specifically map $PWD to a > non-existent path. I suggested various ways around this. One of the > suggestions, was to add an extra mapping to map $PWD/tests back to > $PWD/tests (or just ./tests), overriding the earlier non-existent mapping. > I think this is the cleanest suggestion - assuming that tests reside in the > same directory, and away from the main source code. Kai Pastor over on bug > #876934 indicated that this would probably work for > openorienteering-mapper. Yes, we do understand that your workaround solves the issue, but we do also understand that we should not be using this workaround in the first place. Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider that this change will be insta-RC I'm afraid. Xi: you have found a *wonderful* way to find where bugs are, please try to fix the relevant code and not paper over it, because in the Qt case it is not a bug on our side. -- “I don’t think security can solve problems. We need to teach greater respect.” Oslo Mayor Stang when asked whether Oslo needs greater security after the attacks in Norway, 07/2011. 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.