[Buildroot] pkg-stats support for external tree?

[Buildroot] pkg-stats support for external tree?

[Magnus Armholt]

Hi,
We are using a setup with an external tree holding our specific packages (br2_external).
The renewed pkg-stats is a nice tool and we would like to cover also our specific packages in br2_external.
Is this possible?

I tried running the pkg-stats from our base directory (parent of buildroot) but this fails due to how the utils/getdeveloperlib is included.

Our directory layout

project-base/
| - buildroot/
| - br2_external/
     | - board/
     | - configs/
     | - Config.in
     | - external.desc
     | - external.mk
     | - package/
| - local_site/

BR,
Magnus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20201015/5d4300da/attachment.html>

[Buildroot] pkg-stats support for external tree?

[Thomas Petazzoni]

Hello Magnus,

On Thu, 15 Oct 2020 04:31:11 +0000
Magnus Armholt <magnus.armholt@wapice.com> wrote:

> We are using a setup with an external tree holding our specific packages (br2_external).
> The renewed pkg-stats is a nice tool and we would like to cover also our specific packages in br2_external.
> Is this possible?
> 
> I tried running the pkg-stats from our base directory (parent of
> buildroot) but this fails due to how the utils/getdeveloperlib is
> included.

Indeed, there is no support for BR2_EXTERNAL in pkg-stats. In fact,
pkg-stats is more a tool for the Buildroot community to keep an eye on
all packages that are in the official Buildroot.

A Buildroot user (or a company using Buildroot) would I guess be more
interested in pkg-stats-like results, but limited to their package
selection.

Recently, we've added support/scripts/cve-checker which output a HTML
page looking like the pkg-stats output, but with just your package +
the CVEs that affect them (if any). However, it does not output all the
same information as pkg-stats.

Which specific information of pkg-stats do you find useful ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] pkg-stats support for external tree?

[Magnus Armholt]

Hi Thomas,

The cve-checker sounds exactly what we are looking for.
We are still using the 2020.02.x release, so I havent notice it.
I need to check it out.

Actually, i was about to submit a patch for the pkg-stats which adds the functionality to parse the package list from the manifest file, but now there is no need to do that =)

The CVE listing in the pkg-stats output  is a very (if not the most) important feature.
The pkg-stats is also very useful as a reminder to update the packages (current version vs latest version).
This is the main reason why I was asking about the support for external tree, so we get a CI reminder to update our project specific packages when new versions are available.

Thanks for the input

BR,
Magnus
________________________________
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Sent: Thursday, October 15, 2020 09:57
To: Magnus Armholt <magnus.armholt@wapice.com>
Cc: buildroot at busybox.net <buildroot@busybox.net>
Subject: Re: [Buildroot] pkg-stats support for external tree?

Hello Magnus,

On Thu, 15 Oct 2020 04:31:11 +0000
Magnus Armholt <magnus.armholt@wapice.com> wrote:

> We are using a setup with an external tree holding our specific packages (br2_external).
> The renewed pkg-stats is a nice tool and we would like to cover also our specific packages in br2_external.
> Is this possible?
>
> I tried running the pkg-stats from our base directory (parent of
> buildroot) but this fails due to how the utils/getdeveloperlib is
> included.

Indeed, there is no support for BR2_EXTERNAL in pkg-stats. In fact,
pkg-stats is more a tool for the Buildroot community to keep an eye on
all packages that are in the official Buildroot.

A Buildroot user (or a company using Buildroot) would I guess be more
interested in pkg-stats-like results, but limited to their package
selection.

Recently, we've added support/scripts/cve-checker which output a HTML
page looking like the pkg-stats output, but with just your package +
the CVEs that affect them (if any). However, it does not output all the
same information as pkg-stats.

Which specific information of pkg-stats do you find useful ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20201015/21866668/attachment.html>

[Buildroot] pkg-stats support for external tree?

[Thomas Petazzoni]

Hello,

On Thu, 15 Oct 2020 07:49:30 +0000
Magnus Armholt <magnus.armholt@wapice.com> wrote:

> The cve-checker sounds exactly what we are looking for.
> We are still using the 2020.02.x release, so I havent notice it.
> I need to check it out.
> 
> Actually, i was about to submit a patch for the pkg-stats which adds the functionality to parse the package list from the manifest file, but now there is no need to do that =)
> 
> The CVE listing in the pkg-stats output  is a very (if not the most) important feature.
> The pkg-stats is also very useful as a reminder to update the packages (current version vs latest version).
> This is the main reason why I was asking about the support for external tree, so we get a CI reminder to update our project specific packages when new versions are available.

Perhaps we should changes things a bit and simple make "pkg-stats"
capable of generating its output based on *all* packages or only on the
packages enabled in your current configuration.

However, I am wondering whether the "latest upstream version"
information for each package really makes a lot of sense in your case.
If you are using the LTS branch 2020.02.x, then inevitably, lots of
packages will be older than there latest upstream release: you're not
using Buildroot master, so packages obviously will not be the latest.
But that's also what you want by using an LTS release of Buildroot: to
not update packages to keep your well-tested and production-ready
system stable, while benefiting from security updates/fixes.

So to me, the "latest upstream version" information really only makes
sense for the pkg-stats on all Buildroot packages, i.e a tool for the
Buildroot community/maintainers rather than a tool for Buildoot
end-users.

Or do you see it differently?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] pkg-stats support for external tree?

[Magnus Armholt]

Hi,

> So to me, the "latest upstream version" information really only makes
> sense for the pkg-stats on all Buildroot packages, i.e a tool for the
> Buildroot community/maintainers rather than a tool for Buildoot
> end-users.

> Or do you see it differently?

I agree, most of the time the latest upstream version is not that useful in LTS branch,
but I do see a use case when a package is listed to have CVE issues.
In that case, it is useful to see if there exists a new version upstream (which otherwise is the first thing to check).

Even though we are using the LTS branch (for exactly the reasons you listed), we do have a process to upgrade individual packages if the need is motivated (can also be non-security related if well motivated).
We dont have the possibility to keep up-to-date with the latest LTS minor version.
A more truthful scenario is an upgrade when the LTS is released (~February) which includes integration work and larger retesting of the system.
Later, usually after the summer, we upgrade to the latest LTS minor version.
At this moment the package list gets a second overhaul and all information related CVEs and possible upstream versions reduces our work.

I am very happy that you have started this work related to CVEs and highlighting the update possibilities, it is a great improvement.

-Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20201015/0e3cfdb6/attachment.html>