Re: Bulk builds as a helper for pkgsrc developers

[Aleksey Cheusov <cheusov%tut.by@localhost>]

On Wed, Aug 10, 2011 at 11:42 PM, Jeremy C. Reed <reed%reedmedia.net@localhost> 
wrote:
>>               This means  that  the  package  PKGNAME  from  PKGPATH 
>>  requires
>>               SO_LIBRARY  but  there is no package that PROVIDES it.  Sample 
>> of
>>               usage:
>
>
> Does this mean that the packaging of the dependency didn't properly
> register its PROVIDES or that the dependency was not defined (even
> though it was used)?

I discussed this issue with wiz@, spz@ and reinoud@.
The problem is that 646 packages REQUIRES /usr/pkg/lib/libgcc_s.so and
there is no package providing it.
It is not clear (for me)
where it came from
(packages were built using pkg_comp).
All gcc-NN provided by pkgsrc place this library under
/usr/pkg/gccNN/lib/ directory.

In a long run I'd like to avoid such situations in the future.

> Also what do you need for your goals?

pkglint provides very useful sanity checks for pkgsrc tree on per-package basis.
I believe we need something similar for binary repositories too,
for example, PROVIDES/REQUIRED consistency (pkg_lint_summary -l).
For some sort of checks bulk build tool seems the right place for them.

A bit different goal is to keep installed packages in a consistent
state (see "nih verify -lLd" or "pkg_lint_summary -lLd").

> Do you need a bulk build machine?
> Access to a virtual machine?
> If you are already doing these yourself, I don't think anyone will mind
> a weekly email indicating problems (as long as it is not too long).

For the beginning I'll use my Linux machines where
I run my bulk builds. When I implement features listed in
my email, I show how it looks like and ask developers for comments.

> If you are already doing these yourself, I don't think anyone will mind
> a weekly email indicating problems (as long as it is not too long).

distbb provides very detailed logs under META/ directory.
All they are easily parseable text files.
I'll start with parseable log files.
Later I'll think of sending notification emails.
I can either email package maintainers or write a tool "grep distbb
logs related to me".

> We could also discuss if problems should be emailed immediately to
> committer (and maybe maintainer/owner) at failure time. We could also
> have a new list for the failure emails.

Give me some time to complete this work :-)

P.S.
pkg_summary(5) generated by pbulk doesn't contain summaries
for packages absent in binary repo due to licencing issues, for
example, motif. As a result 'pkg_lint_summary -l' complains about
missing libXm.so. How about pkg_summary.gz consisting of summaries for
all built packages?