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

Re: FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)



Hi,

thanks for the work on this.  I'd like to defer the final decision to the
release team, however I'm not keen on having these defaults turned on
architectures which already have enough issues on their own.  In the recent
porters call people claim that turning on these "should not be a problem"
without giving any details why. I don't like this "laissez faire" attitude.
Without doing even a (limited) test rebuild on these architectures.  I don't
think this is the right time to turn on the defaults, that should be better done
when starting the development for the next release cycle.  If people are
confident to turn these on on amd64, fine.  If people are fine to trust Ubuntu's
experience to turn these on on ppc64el and s390x, fine as well.  But for any
other architecture please do a partial test rebuild before turning these on.

Matthias

On 09.09.2016 16:04, Bálint Réczey wrote:
> Hi,
> 
> First of all thanks to Lucas Nussbaum who ran the first test build!
> 
> 2016-08-31 19:21 GMT+02:00 Steve Langasek <vorlon@debian.org>:
>> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>>> Hello,
>>>> 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.
>>
>>> 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.
> 
> Is there a list available or an easy way of collecting them?
> 
>>
>> Note that enabling PIE by default is going to cause build failures for a
>> number of packages which link against static libraries, if those static
>> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
>> this transition, so a direct comparison would require a rebootstrap test in
>> Debian instead of just a rebuild test (i.e.: test rebuild packages in
>> dependency order, and build later packages against the output of the earlier
>> rebuilds).
> 
> True. Full rebootstrapping of the archive is not available
> automatically and this
> was really useful as a first test.
> 
> I have added more dpkg patches [1] to make -pie hardening flag a noop since GCC
> upstream is not interested in making -no-pie easily usable [2].
> 
> I tested the packages failing to build with the previous patches and
> many of them
> could be built.
> The logs of the remaining failures can be found here:
> https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/
> 
> If we ignore the packages having "haskell" in their name the failures are down
> to 295 packages.
> 
> I'm starting ot file bugs for the FTBFS-s.
> 
> Patched dpkg and gcc is still available for those who would like to reproduce
> the issues.
> 
> Cheers,
> Balint
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
> [3] https://people.debian.org/~rbalint/ppa/pie-bindnow/
> 


Reply to: