Bug#881973: kde-spectacle: Please build against libkf5kipi32.0.0 in experimental

[Diederik de Haas]

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

KDEPIM 17.08: The whole thing works

[Martin Steigerwald]

Hello.

Okay, so I installed Akonadi + KDEPIM 17.08 and the whole things works.

I had some issues tough.

What did I do?

1. apt install -t experimental kmail – kdewebdev got removed, it appears
it needs an update. Also kdepim related kio plugins got removed, maybe
thats intentional.

2. Rebooted and started KMail. Akonadi produced lots of database load
and after a while KMail complained it would not start. Akonadi was indeed
not running only

3. I then looked for old 16.04 packages and did the following:

apt install -t experimental libkf5akonadisearch-data libkf5akonadisearchxapian5 
libkf5akonadinotes5 libkf5akonadisearchcore5

apt install -t experimental libkf5libkdepim-plugins:amd64

apt purge kf5-kdepimlibs-kio-plugins kdepimlibs-data

(old transitional packages)

4. I logged out and in again, making sure that all processes of the user are 
gone.

5. Again Akonadi stopped after a while, complaining it could not find MySQL
socket file, I did not look much closer, MySQL was running initially just
fine and there has been quite some MySQL load.

6. But this time KMail offered to start Akonadi again, which I did

7. Then KMail said that Akonadi is updating the database to improve
performance.

8. It took about 15 minutes or so.

9. KAlarm asked about upgrading archived alarms to a new format.


I was able to read news feeds in Akregator during the upgrade. Akgregator
is still not Akonadi based. But well whatever the reported crash on start
bug is about, I did not see it.


Thats for now. Time to sleep.

Now let´s see whether it sends this mail :)

Thanks,
-- 
Martin

Bug#881943: libqt5opengl5-dev should provide libqt5opengl5-dev-full-opengl on !armel/armhf

[Lisandro Damián Nicanor Pérez Meyer]

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

[Debian FTP Masters]

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

[Debian FTP Masters]

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

[Adrian Bunk]

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.

Re: Applications 17.08 in NEW queue

[laurent Trinques]

Le jeudi 16 novembre 2017, 17:10:03 CET Martin Steigerwald a écrit :
> Martin Steigerwald - 15.11.17, 10:34:
> > Martin Steigerwald - 14.11.17, 10:55:
> > > anxious...@gmail.com - 26.10.17, 00:01:
> > > > I do recognise that the ftpmasters have a large workload and I am
> > > > merely
> > > > seeking information rather than trying to be pushy.
> > > > 
> > > > KDE Applications 17.08 seem to have been waiting for approval for some
> > > > time. Are there issues which need to be sorted out, or is it just a
> > > > big
> > > > task to work through them?
> > > 
> > > FTP masters accepted akregator 17.08 today at 9:00 CET. Yay!
> > > 
> > > I hope they will approve the rest soon as well :)
> > 
> > They rest is coming.
> > 
> > Yay, yay, yay. /me dances around happily.
> 
> Okay, somehow I missed KMail, but FTP masters accepted this now as well.
> 
> >From a quick glance at the NEW queue, I think it is now complete. So just
> >need
> to wait till KMail 17.08 is build. Then upgrade :)
> 
> Thanks,

Thanks for information's. 

Bug#879094: Status of the marble package.

[peter green]

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

[Debian FTP Masters]

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 Maintainers 
Changed-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: Applications 17.08 in NEW queue

[Martin Steigerwald]

Martin Steigerwald - 15.11.17, 10:34:
> Martin Steigerwald - 14.11.17, 10:55:
> > anxious...@gmail.com - 26.10.17, 00:01:
> > > I do recognise that the ftpmasters have a large workload and I am merely
> > > seeking information rather than trying to be pushy.
> > > 
> > > KDE Applications 17.08 seem to have been waiting for approval for some
> > > time. Are there issues which need to be sorted out, or is it just a big
> > > task to work through them?
> > 
> > FTP masters accepted akregator 17.08 today at 9:00 CET. Yay!
> > 
> > I hope they will approve the rest soon as well :)
> 
> They rest is coming.
> 
> Yay, yay, yay. /me dances around happily.

Okay, somehow I missed KMail, but FTP masters accepted this now as well.

>From a quick glance at the NEW queue, I think it is now complete. So just need 
to wait till KMail 17.08 is build. Then upgrade :)

Thanks,
-- 
Martin

Re: Bug#876901: QFINDTESTDATA uses __FILE__

[Lisandro Damián Nicanor Pérez Meyer]

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__

[Ximin Luo]

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__

[Ximin Luo]

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__

[Lisandro Damián Nicanor Pérez Meyer]

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.