[Petter Reinholdtsen]
> I have not tested the change, as I am unable to build the package from
> git now. It fail because there is no upstream tag and pristine-tar
> content for the latest upstream changes imported into the git
> repository.
My mistake. I had forgotten to pull the latest
[Lluís Vilanova]
> The poor man's solution is to do as you suggested. If perf's configuration is
> insufficient, barf at the user and exit, but do not return any error code.
Yeah. Something along these lines, perhaps:
diff --git a/debian/rules b/debian/rules
index d1b0777..87c1f89 100755
---
Petter Reinholdtsen writes:
> [Lluís Vilanova]
>> H, with grub2 that's easier to do because it's going to test the
>> bootloader that is the first thing going to start. In our case we'd
>> have to bootstrap a full system and then start it in qemu just to run
>> the test. That doesn't sound
[Lluís Vilanova]
> H, with grub2 that's easier to do because it's going to test the
> bootloader that is the first thing going to start. In our case we'd
> have to bootstrap a full system and then start it in qemu just to run
> the test. That doesn't sound feasible to me (time and disk space
Petter Reinholdtsen writes:
> [Petter Reinholdtsen]
>> What options do we have? I can think of two: (1) Stop verifying during
>> build that coz when the kernel prohibits it or (2) find another way to
>> test coz during build that do not involve the kernel perf interface.
>> Any other ideas?
> I
[Petter Reinholdtsen]
> What options do we have? I can think of two: (1) Stop verifying during
> build that coz when the kernel prohibits it or (2) find another way to
> test coz during build that do not involve the kernel perf interface.
> Any other ideas?
I asked about this on #debian-release,
The problematic scenario is this: Stretch is released, the autobuilders
are upgraded to stretch and a security hole is discovered in
coz-profiler (or some other need for an update in Stretch. In this
case, the code will no longer build in the autobuilders, and that would
be highly problematic.
> > [ I arrived at this bug because it already fails in my autobuilders ]
>
> Are you behind the x32 builder? It is the only one failing on
> https://buildd.debian.org/status/package.php?p=coz-profiler=unstable >
No, I don't run any official buildd, but I have autobuilders running
almost all
On Fri, Dec 16, 2016 at 10:34:47PM +0100, Petter Reinholdtsen wrote:
>
> Control: severity -1 important
>
> [Santiago Vila]
> > Based on the above comment, this bug should really be RC, because
> > Release Policy says that packages in stretch *must* be buildable in
> > stretch (this of course
Control: severity -1 important
[Santiago Vila]
> Based on the above comment, this bug should really be RC, because
> Release Policy says that packages in stretch *must* be buildable in
> stretch (this of course includes a machine running the default kernel
> for stretch).
All the dependencies
Hi.
If you absolutely need to run the tests during the build, maybe a
workaround would be to add a build-depends on a package which changes
the kernel value for you in its postinst (as I guess that the ordinary
user used to build packages would not be able to do that).
Yes, it would be a little
severity 844633 serious
thanks
On Sun, 4 Dec 2016, Petter Reinholdtsen wrote:
> It seem to be by accident that the autobuilders work. I asked, and it
> is only because they are running Debian stable. The ones running newer
> kernels do not work. This will change when they are upgraded, unless
It seem to be by accident that the autobuilders work. I asked, and it
is only because they are running Debian stable. The ones running newer
kernels do not work. This will change when they are upgraded, unless
they are willing to adjust the perf_event_paranoid value on the
autobuilders, which
[Petter Reinholdtsen]
> I notice the autobuilders work, the ci.debian.org builders work, but
> the reproducable build builders do not. No idea what the difference
> is.
This is not quite accurate. All autobuilders except the x32 one work.
And only of of the two amd64 autobuilders for the
I've made a pull request to upstream that makes coz be more informative about
that error:
https://github.com/plasma-umass/coz/pull/86
Cheers,
Lluis
[Lluís Vilanova]
> A possible check could be:
>
> if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
> echo "ERROR: perf is too paranoid for us"
> exit 1
> fi
>
> This would build-depend on procps (which installs sysctl).
This seem like a good approach. Perhaps explain
Petter Reinholdtsen writes:
> [Lluís Vilanova]
>> The package currently fails to run its tests during build due to
>> insufficient permissions to access Linux's perf interface.
> Is there some way to figure out if such permissions are missing or not?
> On my machine, where the build work, the
[Lluís Vilanova]
> The package currently fails to run its tests during build due to
> insufficient permissions to access Linux's perf interface.
Is there some way to figure out if such permissions are missing or not?
On my machine, where the build work, the value of
Package: coz-profiler
Version: 0.0.git.20161011T1320-3
Severity: normal
The package currently fails to run its tests during build due to insufficient
permissions to access Linux's perf interface.
There's three ways to solve this:
* running the checks as root
* granting CAP_SYS_ADMIN to the user
19 matches
Mail list logo
