Re: [Fwd: pkgbox64 pkgsrc DragonFly 2.5.1/x86_64 2009-10-16 21:12]

2009-10-21 Thread Saifi Khan
On Wed, 21 Oct 2009, Justin C. Sherrill wrote:

 Binary package build for DragonFly 2.5.x on amd64 has completed, with a
 greater-than-I-expected number of packages building.
 
 Total number of packages:   8969
   Successfully built:   7475
   Failed to build:   359
   Depending on failed package:   574
   Explicitly broken or masked:   497
   Depending on masked package:64
 

Justin, thats awesome piece of work.

Do you think it is a good idea to weigh
build-fail/broken/masked packages against a usage list like
https://www.osscensus.org/packages-rank-public.php?offset=0limit=778page=0

Using that approach one can showcase certain apps that
work/build exceptionally well on the DragonFlyBSD platform.

Perhaps somebody may have already reflected on this and 
that is something not obvious to a newbie like me. 


thanks
Saifi.


Re: [Fwd: pkgbox64 pkgsrc DragonFly 2.5.1/x86_64 2009-10-16 21:12]

2009-10-21 Thread Simon 'corecode' Schubert

Justin C. Sherrill wrote:

These should work for all amd64 versions, via pkgin or pkg_radd or manual
download.  The report didn't upload because of a permissions problem,
which I've fixed and the next run (already started) should have an
up-to-date report to accompany it.


Do you think you can push the report still or is it too late?

Are you performing incremental builds?

cheers
 simon


Re: [Fwd: pkgbox64 pkgsrc DragonFly 2.5.1/x86_64 2009-10-16 21:12]

2009-10-21 Thread Simon 'corecode' Schubert

Justin C. Sherrill wrote:

On Wed, October 21, 2009 12:36 pm, Simon 'corecode' Schubert wrote:

Justin C. Sherrill wrote:

These should work for all amd64 versions, via pkgin or pkg_radd or
manual
download.  The report didn't upload because of a permissions problem,
which I've fixed and the next run (already started) should have an
up-to-date report to accompany it.

Do you think you can push the report still or is it too late?

Are you performing incremental builds?


Too late - it already has 3,500 packages since my post this morning, so I
figured a delay of a day wouldn't hurt.  Some of the broken packages match
the existing i386 results, so these are not necessarily amd64-specific
problems.

The builds are incremental.  This and the others took so long because it
was the first 2009Q3 build.


sweeet!


Re: [Fwd: pkgbox64 pkgsrc DragonFly 2.5.1/x86_64 2009-10-16 21:12]

2009-10-21 Thread Justin C. Sherrill
On Wed, October 21, 2009 12:36 pm, Simon 'corecode' Schubert wrote:
 Justin C. Sherrill wrote:
 These should work for all amd64 versions, via pkgin or pkg_radd or
 manual
 download.  The report didn't upload because of a permissions problem,
 which I've fixed and the next run (already started) should have an
 up-to-date report to accompany it.

 Do you think you can push the report still or is it too late?

 Are you performing incremental builds?

Too late - it already has 3,500 packages since my post this morning, so I
figured a delay of a day wouldn't hurt.  Some of the broken packages match
the existing i386 results, so these are not necessarily amd64-specific
problems.

The builds are incremental.  This and the others took so long because it
was the first 2009Q3 build.



Re: [Fwd: pkgbox64 pkgsrc DragonFly 2.5.1/x86_64 2009-10-16 21:12]

2009-10-21 Thread Justin C. Sherrill
On Wed, October 21, 2009 12:19 pm, Saifi Khan wrote:

 Justin, thats awesome piece of work.

 Do you think it is a good idea to weigh
 build-fail/broken/masked packages against a usage list like
 https://www.osscensus.org/packages-rank-public.php?offset=0limit=778page=0

That's a good idea for prioritizing needed fixes, but there's something in
the existing reports that that I think mostly covers it.  Most of the
items with a high usage rate in the report you linked tend to have a high
downstream dependency, so if they break, lots of other packages break.

The email report that comes from a bulk build shows a list of the top
packages who break other packages by not building, so we should be able to
get a list of what needs to be done directly from there, and it should
follow the same general pattern as that usage list.