Report created on Mon Nov 23 18:07:18 2009. back to main menu

Enter a new build error (partial match is ok) to get information about FreeBSD ports with that error:

Build error: 

For explanatory information and summary details, see the notes below.

portname maintainer build error logs Problem Reports Responsible
audio/cowbell ports@FreeBSD.org coredump    
databases/db4o-mono pneumann@gmail.com coredump    
deskutils/tomboy mono@FreeBSD.org coredump    
devel/cocktail [B] wjw@withagen.nl coredump    
devel/dbus-sharp bsd-sharp@googlegroups.com coredump    
devel/monodevelop mono@FreeBSD.org coredump    
devel/monodevelop-database mono@FreeBSD.org coredump    
devel/monodevelop-java mono@FreeBSD.org coredump    
devel/monodevelop-vala mono@FreeBSD.org coredump    
devel/nant ports@FreeBSD.org coredump    
devel/p5-Devel-EvalContext clsung@FreeBSD.org coredump    
devel/p5-SVN-Log ychsiao@ychsiao.org coredump    
devel/p5-SVN-Web rafan@FreeBSD.org coredump    
editors/bless mono@FreeBSD.org coredump    
graphics/ImageMagick mm@FreeBSD.org coredump 140035: graphics/ImageMagick has bad dependancy when WITHOUT_X11 mm
graphics/autopano-sift vd@FreeBSD.org coredump    
graphics/pixie ports@FreeBSD.org coredump    
lang/io gahr@FreeBSD.org coredump    
lang/mono-basic mono@FreeBSD.org coredump    
mail/bogofilter matthias.andree@gmx.de coredump    
mail/bogofilter-sqlite matthias.andree@gmx.de coredump    
misc/cdcollect ports@logvinov.com coredump    
multimedia/banshee-mirage mono@FreeBSD.org coredump    
multimedia/gnome-subtitles ports@FreeBSD.org coredump    
multimedia/sublib ports@FreeBSD.org coredump    
net/avahi-sharp bsd-sharp@googlegroups.com coredump    
security/openvpn-admin ports@FreeBSD.org coredump    
www/webkit-sharp mono@FreeBSD.org coredump    
x11-toolkits/gtksourceview-sharp mono@FreeBSD.org coredump    
x11-toolkits/p5-Wx-Perl-ProcessStream cm@therek.net coredump    
ports shown: 30   ports with build errors: 30 ports with outstanding PRs: 1  
ports with either build errors or PRs: 30

Notes:

Clicking on each column heading will cause the report to be redone sorted by that column. Clicking again will reverse the sort.

The portname column includes links to a more complete overview for that port.

The maintainer column includes links to a page showing the status of all ports for that maintainer.

The build error logs column represents the list of unique errors noticed in any build environment (if any). The errors are listed alphabetically. Each entry is a link to a particular errorlog. (In cases where the same error occurs in multiple build environments, the latest errorlog is used.)

The list of build errors that are detected, and a short description of each one, can be found here.

The PRs (if any) for the given port are listed numerically in the Problem Reports column. Thus, for each port, they should also be in order from earliest to latest.

Currently, no effort is made to correlate any individual build error with any individual PR. They are listed in adjacent columns only for your viewing convenience.

The underlying technology of this report relies on trying to extract information from the existing GNATS database entries. These entries are entered by human users using the send-pr command. As such, the quality of the entries varies greatly.

The fastest, and easiest, information is gleaned from a GNATS entry whose subject line contains the port category and port name, separated by a slash. However, if this algorithm only flagged those, it would miss nearly 50% of the ports PRs, not to mention all the 'framework' PRs.

So, as an extension, various heuristics are used to guess what it is the user really intended. See the code in gnatsQueryUtils.py for the gory details. What's important to understand is this: there is no possible algorithm that will correctly identify all the ambiguous PRs without getting a few false identifications and still run in less than geological time. So, before you are tempted to file a PR on this algorithm itself, read the code to understand its design tradeoffs, and then consider instead filing followup PRs to the ambiguous PRs that would disambiguate them instead. Thanks -- the author.