[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Porter roll call for Debian Stretch


2016-08-31 12:26 GMT+02:00 Dimitri John Ledkov <xnox@debian.org>:
> Hello,
> On 30 August 2016 at 23:07, Lucas Nussbaum <lucas@debian.org> wrote:
>> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>>> Hi Guillem,
>>> 2016-08-21 14:02 GMT+02:00 Guillem Jover <guillem@debian.org>:
>>> > Hi!
>>> >
>>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
>>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>> >>
>>> >> My assumption was that this set of architectures need the least amount of
>>> >> additional work since they are tested already in Ubuntu, but I would be happy
>>> >> if more ports would opt in for PIE.
>>> >>
>>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>>> >> after I rebuilt a
>>> >> few packages with the defaults.
>>> >
>>> > TBH I think PIE should in fact be safer to enable globally than
>>> > bindnow, because the latter changes the run-time behavior and things
>>> > might break (perhaps even silently) when failing to load plugins
>>> > or similar.
>>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>>> I don't expect too many surprises either, since other distributions
>>> already tested enabling bindnow and probably they found
>>> most issues.
>>> >
>>> > From dpkg PoV enabling both, would at least require a full-archive
>>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>> The patches at [2] seem to work well and since you expressed that you would
>>> prefer changing both toolchain and dpkg, too, I would like to suggest running
>>> the rebuild with those patches.
>>> I think Matthias would be OK with the patch since it is very small and brings
>>> Debian's gcc closer to Ubuntu's.
>>> Lucas, could you please run the rebuild with the three patches?
>> Hi,
>> Results are available at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> failed packages with a pristine unstable chroot.
>> You can take a look at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> unstable). (There are 1188 packages failing to build)
>> Logs for both builds are available in the respective subdirectories.
>> Lucas
> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.
> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.
> Looking at e.g. ace buildlog the PIE+bindnow has this:
> -fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now
> Which is bindnow without pie, instead of with pie.

Ubuntu sets bindnow in GCC in Ubuntu while it is set by dpkg in Debian.

Ace requests those flags in d/rules:

I have just started looking at the logs and I think I have a patch to GCC which
will fix many of the FTBFS-es.
I'm also looking at the GCC diff in Ubuntu.


> And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
> arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1
> --
> Regards,
> Dimitri.

Reply to: