[Buildroot] Package informations, online and updated

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Hello,

After the update to the pkg-stats package, I've set up the necessary
infrastructure to keep an updated online result of this script. It can
be seen at any time at:

 http://autobuild.buildroot.org/stats/

I will run the script every day in a crontab, after doing a git pull,
so it will reflect the daily status of our packages.

There are probably more metrics to add, even small things like presence
of ':=' operators. Don't hesitate to share your ideas and patches about
this.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Package informations, online and updated

[Thomas De Schampheleire]

Hi,

On Tue, Jul 31, 2012 at 9:37 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> After the update to the pkg-stats package, I've set up the necessary
> infrastructure to keep an updated online result of this script. It can
> be seen at any time at:
>
>  http://autobuild.buildroot.org/stats/
>
> I will run the script every day in a crontab, after doing a git pull,
> so it will reflect the daily status of our packages.
>
> There are probably more metrics to add, even small things like presence
> of ':=' operators. Don't hesitate to share your ideas and patches about
> this.

Nice!
In fact, I wasn't aware of the pkg-stats script at all. I doesn't seem
to be mentioned in the documentation, or has this changed in recent
versions?

Anyway, good idea to put it online.

Best regards,
Thomas

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Le Wed, 1 Aug 2012 20:55:51 +0200,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> In fact, I wasn't aware of the pkg-stats script at all. I doesn't seem
> to be mentioned in the documentation, or has this changed in recent
> versions?

Well, pkg-stats is kind of an internal tool for Buildroot developers,
so I'm not sure it's worth mentioning in the documentation.

> Anyway, good idea to put it online.

Thanks :)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Package informations, online and updated

[Alex Bradbury]

On 31 July 2012 20:37, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> There are probably more metrics to add, even small things like presence
> of ':=' operators. Don't hesitate to share your ideas and patches about
> this.

It would be handy to add the current version for each package. More
ambitiously, a variable defining a watch[1] line could be added to
each Makefile, and used with the Debian scripts (such as uscan) to
automatically detect new upstream versions.

[1]: http://wiki.debian.org/debian/watch/

Alex

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Le Thu, 2 Aug 2012 15:19:15 +0100,
Alex Bradbury <asb@asbradbury.org> a ?crit :

> It would be handy to add the current version for each package. More
> ambitiously, a variable defining a watch[1] line could be added to
> each Makefile, and used with the Debian scripts (such as uscan) to
> automatically detect new upstream versions.

Agreed. Funnily I was almost to the point of talking about this in my
announcement e-mail :-)

How exactly are those watch lines used? I.e, which tool is capable of
parsing them, and doing the necessary http/ftp requests to figure out
if a newer upstream version is available?

That said, showing the version of each package will slow down the
script quite a bit. For now, the script simply greps/seds through
the .mk file, which is reasonably fast. However, knowing the version
number is more complicated because sometimes the version number is
computed from other variables:

FOO_MAJOR_VERSION = 2
FOO_VERSION = $(FOO_MAJOR_VERSION).3

So to handle this properly, I would have to do 'make
<pkg>-show-version' for each package, which would be very slow
(but doable).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Package informations, online and updated

[Alex Bradbury]

On 2 August 2012 15:31, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Thu, 2 Aug 2012 15:19:15 +0100,
> Alex Bradbury <asb@asbradbury.org> a ?crit :
>
>> It would be handy to add the current version for each package. More
>> ambitiously, a variable defining a watch[1] line could be added to
>> each Makefile, and used with the Debian scripts (such as uscan) to
>> automatically detect new upstream versions.
>
> Agreed. Funnily I was almost to the point of talking about this in my
> announcement e-mail :-)
>
> How exactly are those watch lines used? I.e, which tool is capable of
> parsing them, and doing the necessary http/ftp requests to figure out
> if a newer upstream version is available?

uscan: http://manpages.debian.net/cgi-bin/man.cgi?query=uscan
http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=blob;f=scripts/uscan.pl

uscan wants to find a separate 'watch' file inside a debian/ dir. It
actually looks like it might not be that hard to hack up uscan.pl so
it just takes the watch line as an argument (though it's been a number
of years since I hacked any Perl), then each package could have a
check-upstream-version target which uses the watch line defined in
that packages makefile and invokes the buildroot 'fork' of uscan.pl to
check whether a newer release is available upstream. I don't know if
any other distros have a similar sort of system, it just strikes me
there's not much point reinventing the wheel here and it's handy to be
able to just lift the watch regex from the debian/watch file for many
packages.

Alex

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Le Thu, 2 Aug 2012 15:53:44 +0100,
Alex Bradbury <asb@asbradbury.org> a ?crit :

> uscan: http://manpages.debian.net/cgi-bin/man.cgi?query=uscan
> http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=blob;f=scripts/uscan.pl
> 
> uscan wants to find a separate 'watch' file inside a debian/ dir. It
> actually looks like it might not be that hard to hack up uscan.pl so
> it just takes the watch line as an argument (though it's been a number
> of years since I hacked any Perl), then each package could have a
> check-upstream-version target which uses the watch line defined in
> that packages makefile and invokes the buildroot 'fork' of uscan.pl to
> check whether a newer release is available upstream. I don't know if
> any other distros have a similar sort of system, it just strikes me
> there's not much point reinventing the wheel here and it's handy to be
> able to just lift the watch regex from the debian/watch file for many
> packages.

Looks nice. Patches? :-)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Package informations, online and updated

[Samuel Martin]

Hi,

2012/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
[...]
> There are probably more metrics to add, even small things like presence
> of ':=' operators. Don't hesitate to share your ideas and patches about
> this.

Another idea, half way with autobuild, could be the latest
build-success and build-failure dates (maybe for each toolchain
running in autobuild).

Cheers,

-- 
Sam

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Le Sat, 4 Aug 2012 14:04:49 +0200,
Samuel Martin <s.martin49@gmail.com> a ?crit :

> Another idea, half way with autobuild, could be the latest
> build-success and build-failure dates (maybe for each toolchain
> running in autobuild).

Well, for what configurations? A per-toolchain date wouldn't make
sense: every build builds a different, random, set of packages. So
toolchain A with package B, C, D may build, but not toolchain A with
package C, D, E.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Package informations, online and updated

[Samuel Martin]

2012/8/4 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Sat, 4 Aug 2012 14:04:49 +0200,
> Samuel Martin <s.martin49@gmail.com> a ?crit :
>
>> Another idea, half way with autobuild, could be the latest
>> build-success and build-failure dates (maybe for each toolchain
>> running in autobuild).
>
> Well, for what configurations? A per-toolchain date wouldn't make
> sense: every build builds a different, random, set of packages. So
> toolchain A with package B, C, D may build, but not toolchain A with
> package C, D, E.
You're right.
In such a case, it would be good to know that packages B, C, D has
successfully been built at that time; package E will cause a
build-failure, so, will trigger the "alarm" (aka, email/bug tracker
entry/...) :).

My point is that sometimes, making some cleanup, some packages do not build.
So, it would be useful to know if it has been built recently (so, in
such a case the problem may be a dirty-worktree or the host
configuration), or if there is a deeper problem due to the upgrade of
some other packages, change in the infrastructure or anything else.

Cheers.

-- 
Sam

[Buildroot] Package informations, online and updated

[Thomas Petazzoni]

Le Sat, 4 Aug 2012 14:53:28 +0200,
Samuel Martin <s.martin49@gmail.com> a ?crit :

> You're right.
> In such a case, it would be good to know that packages B, C, D has
> successfully been built at that time; package E will cause a
> build-failure, so, will trigger the "alarm" (aka, email/bug tracker
> entry/...) :).

Well, packages B, C and D have been successfully built with *that*
toolchain, or with any toolchain?

Really, because of the fact that each build is based on a random
toolchain and then a random set of packages, it's really hard to draw
definitive conclusions about when a package got broken and when it was
working.

I would rather suggest that we work towards having a 100% build success
rate, so that any build failure is considered as something to fix. Of
course, we can decide on a case by case basis to exclude certain build
scenarios from the autobuilders.

> My point is that sometimes, making some cleanup, some packages do not
> build. So, it would be useful to know if it has been built recently
> (so, in such a case the problem may be a dirty-worktree or the host
> configuration), or if there is a deeper problem due to the upgrade of
> some other packages, change in the infrastructure or anything else.

See above. A package may build successfully once, but then the next
time it doesn't build successful not because of the package being
upgraded, but because the selection of sub-options for that package is
different, because the libraries that have been built before that
package are different, etc. So defining "a package builds" is much,
much more complicated than it sounds in the first place.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com