reopen 796166 tag 796166 wontfix thanks On Thursday 20 August 2015 10:57:59 Markus Koschany wrote: > On Wed, 19 Aug 2015 23:03:10 -0300 Lisandro > =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer <perezmeyer@gmail.com> > > wrote: > > On Wednesday 19 August 2015 23:31:12 Markus Koschany wrote: > [...] > > > Right, but sadly it's (arguably) not a Qt bug (see below). > > I think closing this bug report was a bad choice and I am rather > disappointed about this move. Closing valid bug reports is wrong. You > could also reassign this bug report to GCC or mark it as wontfix. I admit you are right and I was wrong, my apologies and let's solve this by reopening the bug and marking it as wontfix for the time being. On the other hand we the maintainers do not currently consider this a Qt bug, so feel free to clone it and reassign it to gcc. > Since > all of your reverse-dependencies are affected, I won't be the only one > who stumbles about this new behaviour. Not that much. Most of the dependencies will get the correct flags from qt's .pro/.pri or cmake files automatically. Those who don't have just discovered a bug. And if Qt is not passing the right flags (which I doubt looking at the lastests KDE builds) please do file a bug against src:qtbase-opensource-src specifying the problem. > Other options are to use the > -no-reduce-relocations options again. Which so far us the maintainers of Qt have deemed not an option until upstream decides otherwise, I perhaps wasn't clear on that on the first mail. The drawbacks are also high for removing it. Now I must also admit that I *personally* don't know which of the two situations is worst, but so far the team's decision has been to keep reducing reallocations as also did upstream. Maybe Sune has a better insight of the matter. > > > > I think Qt's -reduce-relocation option reduces our ability to harden > > > our binaries. To workaround this bug I had to change from > > > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > > > to > > > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie > > > > Actually that should have been -fPIC > > No, it must be -pie because you must remove the -pie flag in this case. > Freeciv builds different game clients for playing the game and one of > them is the Qt client. Now I am either forced to build all binaries > without -pie or to heavily patch the build system. Of course Freeciv > upstream doesn't consider this to be a Freeciv specific bug. I'm afraid that if it's using Qt then it should be using Qt's flags for Qt's stuff. [snip] > > If you really think it should be different then please do as suggested in > > the Arch linux's bug report: complain to upstream at > > https://bugreports.qt.io/browse/QTBUG-45755 or at their mailing list > > development@qt-project.org. If you get to convince upstream of this > > believe me we won't have any problems in changing whatever is necessary. > > My understanding of being a Debian maintainer is that this is actually > your job. Why would we need a BTS if every maintainer decided to close > bug reports and requested to open them upstream instead? You should have > a far better insight into your package than I have and you might be able > to convince upstream, if you have worked with them before. Why would > they listen to me, if my own distribution maintainer closes the bug > report right away? Our team policy is to be as close to upstream as possible. Directly closing the bug was a mistake on my side, and I admit it. But be sure we discussed this with upstream on the bug report, the mailing list and on irc. The final outcome is that Qt ships with -Wl,-Bsymbolics (aka reduce relocations) by default, and due to gcc's behavior this means using -fPIC. So again we consider this not a bug (and if it is, we currently prefer to reduce rellocations), and this is why I'm suggesting you to take it with upstream if you don't feel this is right. And so far no distro that I know of has overridden this so far, but please also feel free to show me otherwise. Now I want to make emphasis on why we insist on taking it with upstream: we do a great job to have a consistent Qt experience as close as possible with other distros and upstream itself. We did discuss this on it's due time and agreed this was the best solution so far. If you feel differently the the right place for this discussion to happen is their mailing list or the bug report. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.