Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Philip Langdale 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7ZnwACgkQ+NaxlGp1aC7rHQCfeMtiAL4kPwIFd37da56aFtVY
eiEAn3Vh0A63CcNSu6MuGVuo8p5U/CJw
=eJcJ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Timo Rothenpieler 
> 3. Proprietary dependencies, which may or may not currently be an issue
> anymore. Philip and Timo, how easy is it to get cuda/nvenc/cuvid/npp to
> compile.
> 

cuda/cuvid/nvenc don't need any external dependencies to compile, only
to run.
libnpp needs proprietary and non-redistributable headers to compile, so
I'm not sure if it's possible at all to build it on public infrastructure.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Timothy Gu 
On Sun, Nov 27, 2016 at 1:52 PM Michael Niedermayer 
wrote:

> I dont want to give a automated travis_ci system any write or admin
> access, some of what i read hinted in that direction, some of what
> i read hinted that this was not needed though
> giving a automated system write access would be a security issue and
> we should not do that
>

You don't need to give Travis CI any privileges. The way it's going to work
is:

1. Set up a dedicated "coverity" branch
2. Set up Travis CI to only watch changes on that branch, and when there is
a new push compile the code with Coverity's custom wrappers, etc.
3. Set up a cronjob on a computer (doesn't matter who's) that pulls new
commits on master into coverity every |x| days

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Timothy Gu 
On Sun, Nov 27, 2016 at 1:13 PM Philip Langdale  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 27 Nov 2016 21:26:13 +0100
> Michael Niedermayer  wrote:
>
> > On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On Sat, 26 Nov 2016 23:55:17 +0100
> > > Michael Niedermayer  wrote:
> > >
> > > > Hi all
> > > >
> > > > The machine on which the coverity stuff is is old, both hw and OS.
> > > > the OS will no longer get security updates in a few months and
> > > > the hw does not always boot and its switched off most of the time.
> > > > and it has no other use anymore than running coverity. Ive tried
> > > > to find someone a while ago to take coverity testing over and i
> > > > thought timothy would maybe do it but he seems to not have had any
> > > > time to look into it ...
> > > > and de facto ive not run it regularly in the recent months.
> > > > So this is kinda a louder announcement that if you care about
> > > > coverity testing, you need to do something ...
> > > >
> > > > thx
> > > >
> > > > PS: work would involve installing every optional dependancy of
> > > > FFmpeg (and keep them updated as needed)
> > > > and regularly either manually or automatically git pull, build
> > > > with the coverity tools and upload Its not a huge amount of work
> > > > but it is work
> > > >
> > >
> > > Hi Michael,
> > >
> > > I think we could do this using travis-ci.
> > >
> > > https://scan.coverity.com/travis_ci
> > >
> > > travis can be directly connected to the github mirror and then we
> > > set up a coverity job as covered in this doc.
> > >
> > > It wouldn't even need to be configured to build - just run the
> > > coverity scan. I'd be happy to investigate this, but I'd need admin
> > > permissions on github to configure travis integration.
> >
> > The way coverity works is by wraping around the compiler or something
> > gether lots of info and that is then uploaded
> > so you need configure and build
> >
> > for coverity to check all optional code it needs all the headers
> > from nvidia, sdl, x11 to the most obscure.
> > if they arent installed coverity wouldnt be able to test these
> > components as the code would not be complete
> >
> > so in whatever envirnment this is done all optional dependancies
> > must be installed one way or another.
> >
> > i assume in the example on https://scan.coverity.com/travis_ci
> > build_command_prepend: ./configure
> > would be a very long command with many --enable*
> >
> > also therese that limit:
> > https://scan.coverity.com/faq#frequency
> > Up to 12 builds per week, with a maximum of 3 builds per day, for
> > projects with fewer than 100K lines of code Up to   8 builds per
> > week, with a maximum of 2 builds per day, for projects with 100K to
> > 500K lines of code Up to   4 builds per week, with a maximum of 1
> > build per day, for projects with 500K to 1 million lines of code Up
> > to   2 builds per week, with a maximum of 1 build per day, for
> > projects with more than 1 million lines of code
> >
> > so we cannot do coverity after every commit, a cronjob might be a
> > simpler choice that runs at the frequency that we can submit
> >
> > Is there still an advantage in travis ci / would that still be
> > preferred?
> >
> > [...]
>
> The recommended configuration on that page is to have it watch a branch
> and you push master to the branch when you want a scan. We can do that
> whenever we want - once a month or whatever. Right now you are doing it
> ad-hoc, and we could still do it ad-hoc. Equally, a cron job running
> somewhere could push to the branch on whatever frequency we want.
>
> The goal here is to remove the need for the dedicated build machine, not
> to improve any other part of the process - although there will be
> opportunities for that.
>
> I've looked at how you prepare a build environment in travis and it's
> simple to install dependencies; that won't be a problem.
>

Libav has had used Travis for a while now for FATE, and I personally have
attempted to set up the same for FFmpeg, without much success.

The problem with using Travis for Coverity (versus a local machine) is
still the issue of dependencies. While system-level deps like vdpau can be
installed easily, there are three classes of other deps that need to be
installed to make Coverity the most useful:

1. Dependencies very few people use, and therefore not packaged by Ubuntu
(e.g. libnut, libxavs, zimg)
2. Dependencies in active development, only the newest versions of which
are accepted by FFmpeg's build system (there currently isn't any examples
but it's not impossible to see this in the future)
3. Proprietary dependencies, which may or may not currently be an issue
anymore. Philip and Timo, how easy is it to get cuda/nvenc/cuvid/npp to
compile.

Timothy
___

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Michael Niedermayer 
On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sat, 26 Nov 2016 23:55:17 +0100
> Michael Niedermayer  wrote:
> 
> > Hi all
> > 
> > The machine on which the coverity stuff is is old, both hw and OS.
> > the OS will no longer get security updates in a few months and the hw
> > does not always boot and its switched off most of the time.
> > and it has no other use anymore than running coverity. Ive tried
> > to find someone a while ago to take coverity testing over and i
> > thought timothy would maybe do it but he seems to not have had any
> > time to look into it ...
> > and de facto ive not run it regularly in the recent months.
> > So this is kinda a louder announcement that if you care about coverity
> > testing, you need to do something ...
> > 
> > thx
> > 
> > PS: work would involve installing every optional dependancy of FFmpeg
> > (and keep them updated as needed)
> > and regularly either manually or automatically git pull, build with
> > the coverity tools and upload Its not a huge amount of work but it is
> > work
> > 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we set
> up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the coverity
> scan. I'd be happy to investigate this, but I'd need admin permissions
> on github to configure travis integration.

what changes need to be done on github to make this work
if you tell me the settings for the webhook (assumig its one)
i can enable that.

I dont want to give a automated travis_ci system any write or admin
access, some of what i read hinted in that direction, some of what
i read hinted that this was not needed though
giving a automated system write access would be a security issue and
we should not do that

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Philip Langdale 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 27 Nov 2016 21:26:13 +0100
Michael Niedermayer  wrote:

> On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On Sat, 26 Nov 2016 23:55:17 +0100
> > Michael Niedermayer  wrote:
> >   
> > > Hi all
> > > 
> > > The machine on which the coverity stuff is is old, both hw and OS.
> > > the OS will no longer get security updates in a few months and
> > > the hw does not always boot and its switched off most of the time.
> > > and it has no other use anymore than running coverity. Ive tried
> > > to find someone a while ago to take coverity testing over and i
> > > thought timothy would maybe do it but he seems to not have had any
> > > time to look into it ...
> > > and de facto ive not run it regularly in the recent months.
> > > So this is kinda a louder announcement that if you care about
> > > coverity testing, you need to do something ...
> > > 
> > > thx
> > > 
> > > PS: work would involve installing every optional dependancy of
> > > FFmpeg (and keep them updated as needed)
> > > and regularly either manually or automatically git pull, build
> > > with the coverity tools and upload Its not a huge amount of work
> > > but it is work
> > >   
> > 
> > Hi Michael,
> > 
> > I think we could do this using travis-ci.
> > 
> > https://scan.coverity.com/travis_ci
> > 
> > travis can be directly connected to the github mirror and then we
> > set up a coverity job as covered in this doc.
> > 
> > It wouldn't even need to be configured to build - just run the
> > coverity scan. I'd be happy to investigate this, but I'd need admin
> > permissions on github to configure travis integration.  
> 
> The way coverity works is by wraping around the compiler or something
> gether lots of info and that is then uploaded
> so you need configure and build
> 
> for coverity to check all optional code it needs all the headers
> from nvidia, sdl, x11 to the most obscure.
> if they arent installed coverity wouldnt be able to test these
> components as the code would not be complete
> 
> so in whatever envirnment this is done all optional dependancies
> must be installed one way or another.
> 
> i assume in the example on https://scan.coverity.com/travis_ci
> build_command_prepend: ./configure
> would be a very long command with many --enable*
> 
> also therese that limit:
> https://scan.coverity.com/faq#frequency
> Up to 12 builds per week, with a maximum of 3 builds per day, for
> projects with fewer than 100K lines of code Up to   8 builds per
> week, with a maximum of 2 builds per day, for projects with 100K to
> 500K lines of code Up to   4 builds per week, with a maximum of 1
> build per day, for projects with 500K to 1 million lines of code Up
> to   2 builds per week, with a maximum of 1 build per day, for
> projects with more than 1 million lines of code
> 
> so we cannot do coverity after every commit, a cronjob might be a
> simpler choice that runs at the frequency that we can submit
> 
> Is there still an advantage in travis ci / would that still be
> preferred?
> 
> [...]

The recommended configuration on that page is to have it watch a branch
and you push master to the branch when you want a scan. We can do that
whenever we want - once a month or whatever. Right now you are doing it
ad-hoc, and we could still do it ad-hoc. Equally, a cron job running
somewhere could push to the branch on whatever frequency we want.

The goal here is to remove the need for the dedicated build machine, not
to improve any other part of the process - although there will be
opportunities for that.

I've looked at how you prepare a build environment in travis and it's
simple to install dependencies; that won't be a problem.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7TGAACgkQ+NaxlGp1aC6i4ACfRa1OR4OGIeOyaa9HBu5dFdSN
XsUAn0UOkiI1xTYPV/H3eCOOPLrx6SJi
=o6R4
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Josh de Kock 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016/11/27 19:00, Philip Langdale wrote:
> On Sat, 26 Nov 2016 23:55:17 +0100 Michael Niedermayer
>  wrote:
> 
>> Hi all
> 
>> The machine on which the coverity stuff is is old, both hw and
>> OS. the OS will no longer get security updates in a few months
>> and the hw does not always boot and its switched off most of the
>> time. and it has no other use anymore than running coverity. Ive
>> tried to find someone a while ago to take coverity testing over
>> and i thought timothy would maybe do it but he seems to not have
>> had any time to look into it ... and de facto ive not run it
>> regularly in the recent months. So this is kinda a louder
>> announcement that if you care about coverity testing, you need to
>> do something ...
> 
>> thx
> 
>> PS: work would involve installing every optional dependancy of
>> FFmpeg (and keep them updated as needed) and regularly either
>> manually or automatically git pull, build with the coverity tools
>> and upload Its not a huge amount of work but it is work
> 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we
> set up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the
> coverity scan. I'd be happy to investigate this, but I'd need admin
> permissions on github to configure travis integration.
> 
> --phil

I can help with Travis CI + GitHub, if any is needed, I have used it
extensively with other open-source projects.

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYO0qrAAoJENBS1A3e+XA947MP/RZplh1BTM/Cn0suaCZygIFo
elJyY1uxMGUvABnC4QHvIxpuuq+SewEA9VzbqMrSWV3xSueFZo8wQQTifCnlc69O
oipwzqyaHjqXRSMiAxMpVPAzdEIvslB8aXwdWELKy9GcHkUVn2hEzitBOfi/qL7y
L3m80h5ZgH4UExSyZmqWniJcOgeC/MZWIvLhGmtdsAihGAVQkS2czQKAJtxSMiJT
hEppu6xHWNLEwN3QnTIhuQGvbVlEQUm9A6/C8x74JJe0lWG3YGpWc2I9OJt07I6Z
J6Rstzuk0EPoS/8CaFTjyMrEgc8v+QIpIjY9GCt0pgDsaUEtA8Cq03IL4wHruowi
nJ8ZSJq0uJQtIws0G/uc29bjKqjz3rHTRXS73uYPDFmfG0hp/pbWDF6UoOate2J7
vtwRfl6oDdZOJAXhg+Wr2DMFiwdSK7niboArYxf+z1mooco6RnCI2uthIGCtt3Gb
i4x89YK1jaSKsbBqTmhw3rCCmSIR318p4vdIiwcULJqm5ZaZc3KU/OYYNiOKxkxx
EwzstoGC7yjXwc1S7Ohmu5yPoFWISmFhL15d8zCvDjpAlUCN1Euc5WFdftT2OaEX
pE6nikt/q6KmPQhQsAGCBX/Nd3QeOwBzGKA9qx9cXLtEt8vssgdL93lFTBZM0m+J
dtbGnlFRnzMsCosrFUCL
=jyZO
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Michael Niedermayer 
On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sat, 26 Nov 2016 23:55:17 +0100
> Michael Niedermayer  wrote:
> 
> > Hi all
> > 
> > The machine on which the coverity stuff is is old, both hw and OS.
> > the OS will no longer get security updates in a few months and the hw
> > does not always boot and its switched off most of the time.
> > and it has no other use anymore than running coverity. Ive tried
> > to find someone a while ago to take coverity testing over and i
> > thought timothy would maybe do it but he seems to not have had any
> > time to look into it ...
> > and de facto ive not run it regularly in the recent months.
> > So this is kinda a louder announcement that if you care about coverity
> > testing, you need to do something ...
> > 
> > thx
> > 
> > PS: work would involve installing every optional dependancy of FFmpeg
> > (and keep them updated as needed)
> > and regularly either manually or automatically git pull, build with
> > the coverity tools and upload Its not a huge amount of work but it is
> > work
> > 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we set
> up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the coverity
> scan. I'd be happy to investigate this, but I'd need admin permissions
> on github to configure travis integration.

The way coverity works is by wraping around the compiler or something
gether lots of info and that is then uploaded
so you need configure and build

for coverity to check all optional code it needs all the headers
from nvidia, sdl, x11 to the most obscure.
if they arent installed coverity wouldnt be able to test these
components as the code would not be complete

so in whatever envirnment this is done all optional dependancies
must be installed one way or another.

i assume in the example on https://scan.coverity.com/travis_ci
build_command_prepend: ./configure
would be a very long command with many --enable*

also therese that limit:
https://scan.coverity.com/faq#frequency
Up to 12 builds per week, with a maximum of 3 builds per day, for projects 
with fewer than 100K lines of code
Up to   8 builds per week, with a maximum of 2 builds per day, for projects 
with 100K to 500K lines of code
Up to   4 builds per week, with a maximum of 1 build per day, for projects 
with 500K to 1 million lines of code
Up to   2 builds per week, with a maximum of 1 build per day, for projects 
with more than 1 million lines of code

so we cannot do coverity after every commit, a cronjob might be a
simpler choice that runs at the frequency that we can submit

Is there still an advantage in travis ci / would that still be
preferred?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

2016-11-27 Thread Philip Langdale 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 26 Nov 2016 23:55:17 +0100
Michael Niedermayer  wrote:

> Hi all
> 
> The machine on which the coverity stuff is is old, both hw and OS.
> the OS will no longer get security updates in a few months and the hw
> does not always boot and its switched off most of the time.
> and it has no other use anymore than running coverity. Ive tried
> to find someone a while ago to take coverity testing over and i
> thought timothy would maybe do it but he seems to not have had any
> time to look into it ...
> and de facto ive not run it regularly in the recent months.
> So this is kinda a louder announcement that if you care about coverity
> testing, you need to do something ...
> 
> thx
> 
> PS: work would involve installing every optional dependancy of FFmpeg
> (and keep them updated as needed)
> and regularly either manually or automatically git pull, build with
> the coverity tools and upload Its not a huge amount of work but it is
> work
> 

Hi Michael,

I think we could do this using travis-ci.

https://scan.coverity.com/travis_ci

travis can be directly connected to the github mirror and then we set
up a coverity job as covered in this doc.

It wouldn't even need to be configured to build - just run the coverity
scan. I'd be happy to investigate this, but I'd need admin permissions
on github to configure travis integration.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7LUUACgkQ+NaxlGp1aC5q3QCgyRVxMRL80RSxDqRfj2zixL8D
rIkAn0s6o1bQr/lapHU+ZU2Y/+vWaYFt
=yig7
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] coverity testing of FFmpeg

2016-11-26 Thread Michael Niedermayer 
Hi all

The machine on which the coverity stuff is is old, both hw and OS.
the OS will no longer get security updates in a few months and the hw
does not always boot and its switched off most of the time.
and it has no other use anymore than running coverity. Ive tried
to find someone a while ago to take coverity testing over and i
thought timothy would maybe do it but he seems to not have had any
time to look into it ...
and de facto ive not run it regularly in the recent months.
So this is kinda a louder announcement that if you care about coverity
testing, you need to do something ...

thx

PS: work would involve installing every optional dependancy of FFmpeg
(and keep them updated as needed)
and regularly either manually or automatically git pull, build with
the coverity tools and upload Its not a huge amount of work but it is
work

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel