[Aptitude-devel] FTBFS with pbuilder + export (and performance)

[Daniel Hartwig]

Axel Beckert wrote:
> Daniel Hartwig wrote:
>> > FTR I have seen it fail here:
>> >
>> > checking for suffix of object files... configure: error: in
>> > `/tmp/buildd/aptitude-0.6.6/build-curses':
>> > configure: error: cannot compute suffix of object files: cannot compile
>
> Same error as I ran into.

I am also unable to reproduce this again today.  Only two times did I
get it and did not retrieve the config.log for either before it was
scrubbed.

Do you find that further attempts to build succeed?

Manuel A. Fernandez Montecelo wrote:
> 2012/3/28 Daniel Hartwig <mandyke at gmail.com>:
>> I note that on the sparc buildd "stadler" the compiler segfaulted
>> while building the test suite.
>
> It's not only with the aptitude package that that this is happening,
> so I wouldn't worry too much -- it's probably an arch-especific bug.
>

Yes, there are some other buildd archs with similar large numbers of
"build attempted" packages and some compilter segfaults.

I suppose we wait to see the outcome of a second attempt on stalder
(or another sparc).

>> Also with exported hardening=+all I am seeing ~10% slow down on a
>> straight "aptitude search ~i > /dev/null".  I suspect this is related
>> to PIE rather than bindnow, as "aptitude nop-noselections" is not
>> showing appreciable slow down.
>>

Ok, so I have looked at this further, comparing 0.6.5-1, 0.6.6-1, and
0.6.6-2.  Last night I was foolishly only comparing 0.6.5-1 to
0.6.6-2.

* init ("aptitude nop")

0.6.5-1 to 0.6.6-1: ~27% slower

I suspect this is mostly unavoidable due to the introduction of
correct multi-arch handling of pkgstates.

0.6.6-1 to 0.6.6-2: ~2% slower

This is the impact of enabling PIE and bindnow hardening flags;
insignificant next to the multi-arch changes.

* basic search ("aptitude search ~i" less init time)

0.6.5-1 to 0.6.6-1: ~1% slower

Multi-arch appears not to have much impact on search times.

0.6.6-1 to 0.6.6-2: ~4% slower

This measures the impact of PIE only, as bindnow only concerns load times.

This is not as drastic as I thought but still noticable, ranging from
2% to 6% over a few different searches.  In an interactive setting
this is not going to be noticed and, on the command-line, multi-arch's
impact on init time still dominates.

> Also, on the performance topic, maybe it's worth looking also at the
> default hardening options, maybe some of them (or its combination) has
> some significant impact as well, so it'll might be something to
> consider.

Perhaps.  The set of defaults was selected by more informed folk than
I.  I reason that they have already weighed the general impact on
performance versus security when choosing that set.

As such, investigating the impact on aptitude of individual flags from
the default set is not something of great interest to me, though
please share any findings if you go ahead with this.