On Fri, Feb 19, 2016 at 03:37:50PM +0000, Ben Hutchings wrote:
> On Fri, 2016-02-19 at 07:27 -0800, Mattia Dongili wrote:
> > On Fri, Feb 19, 2016 at 02:30:26PM +0000, Ben Hutchings wrote:
> > > On Thu, 2016-02-18 at 23:29 -0800, malattia@gmail.com wrote:
> > > > From: Mattia Dongili <malattia@linux.it>
> > > >
> > > > They'll eventually replace cpufrequtils and libcpufreq{0,-dev} so the
> > > > structure of the packages is the same.
> > > [...]
> > >
> > > This is not passing the proper build flags:
> > >
> > > W: libcpupower0: hardening-no-relro usr/lib/libcpupower.so.0.0.0
> > > W: linux-cpupower: hardening-no-relro usr/bin/cpupower
> > > W: linux-cpupower: hardening-no-relro usr/sbin/cpufreq-bench
> > > W: linux-cpupower-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/40/fd11393c987a84eaf7a98448d72ec8d8f87414.debug
> > > W: libcpupower0-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/ed/bc6af9a235be2cc306d10b33632fa4dd071a3b.debug
> >
> > I didn't pay too much attention these warnings because linux-perf has
> > similar ones. I should have mentioned that.
> >
> > E: linux-perf-4.5: binary-from-other-architecture usr/lib/perf_4.5-core/perf-read-vdsox32
>
> This is expected but should probably be overridden.
Ok. Override it is.
> > W: linux-perf-4.5-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/c5/55a9d59fa355fd0dddb74d5e6322020c51be07.debug
> > W: linux-perf-4.5-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/db/dc04fd210c88261daff32f95aadd09e70a7113.debug
> > W: linux-perf-4.5: executable-not-elf-or-script usr/share/perf-core/strace/groups/file
> > W: linux-perf-4.5: hardening-no-relro usr/lib/perf_4.5-core/perf-read-vdso32
> > W: linux-perf-4.5: hardening-no-relro usr/lib/perf_4.5-core/perf-read-vdsox32
> [...]
>
> Those two may be difficult to fix, since they aren't built with the
> same flags as other executables.
Ok, I haven't really looked at how linux-perf is built yet. Thanks for
the note.
> Is there any reason not to add cpupower on the sid branch rather than
> master (which means it will stay in experimental for the next ~2
> months)?
The sid branch is fine, I'll rebase on that for the next revision.
--
mattia
:wq!
Attachment:
signature.asc
Description: PGP signature