Yay, 8k! and still going... Sorry in advance for the long email, I am
replying to all previous questions in the thread. I split into sections
so that you can skip what you don't care about.
= Unmet Packages =
The autobuilder hasn't even started touching the main branch (by design)
the only repository that the builder has been building "from" has been
Ubuntu hardy-* universe (which gets submitted to contrib).
I think we need to wait and see what happens when main is enabled for
builds before we can judge what will happen ultimately with depends. I
don't think having packages with unmet depends in the unstable
repository is a bad thing. I think in the worst scenario we can simply
migrate known good packages to testing/stable and leave unmet packages
in unstable. Having the packages there helps to get people involved: if
they want to use the package they can help satisfy a few depends. For
reference, running the unmet -i command on a Debian box does yield unmet
depends for packages.
Also, I think before I enable building for main we might migrate the
current unstable main packages to testing. This is definitely open for
discussion though.
/me ducks from potential flying tomatos...
= Builder Workings =
The way the builder works is by comparing versions of packages. If you
upload a package by hand it should be newer (or at least the same
version) than the upstream version. If this is the case then the builder
will leave your package unharmed. It is recommended that you port your
changes to the upstream version of the package, or even better -- the
upstream project itself.
If anyone knows a good way to automatically SMF-ify a package, I am
listening.
I don't have any way to currently import diffs for the autobuilder but
it wouldn't be too hard to add on. I'm open to discussing this feature,
or accepting patches on the project code base (autobuilder.sf.net)
= Unmet Packages (and finding them) =
Also, a slightly better way to find unmet depends is:
% apt-cache -i unmet | grep -v ^Package | cut -d: -f2- | sed 's/|/\n/g'
| sort | uniq -c | sort -n
take out the -i to find suggested/recommended in the same list. The last
few lines here are:
20 zope2.8
25 zope2.9
27 zope2.10
30 lightning-extension (< 0.8.1~)
30 lightning-extension (>= 0.8)
30 roxen4
31 roxen (>= 1.3.122-10)
34 roxen2
36 caudium
36 roxen3
I'll note that the last few lines are not necessarily the most significant.
= How we can leverage the builder =
Finally, packaging efforts can be better coordinated through the
autobuilder now. For an example of what I mean, open the following URL
and expands the "Jobs" section:
http://builder.tajinc.org/?f=repository_status&id_repository=22
In particular, scroll down until you see the job status of
"build-broken". The later packages that are broken are more reliably
broken so look at today/yesterdays date. You can click on "build-broken"
to see a log of the attempted package build. stderr is red, stdout is
blue, commands are in black. From the output you can generally find why
a package needs attention. Take aria2 for example:
http://builder.tajinc.org/?f=job_status&uuid=4f19c398-d47d-11dd-95f0-0013d314a49d#stage_5
The very last lines say:
In file included from a2netcompat.h:86,
from SocketCore.cc:37:
getaddrinfo.h:219: error: redefinition of 'struct addrinfo'
/usr/include/netdb.h:112: error: previous definition of 'struct addrinfo'
which means you will likely need to dig into a little code and find how
to set the right definition. You can find a problem that more suits your
strengths:
Packaging issue:
http://builder.tajinc.org/?f=job_status&uuid=5c245e88-cfc6-11dd-9d6f-0013d314a49d
Possible C/ASM Syntax Error:
http://builder.tajinc.org/?f=job_status&uuid=5c22e6b6-cfc6-11dd-9028-0013d314a49d
Missing headers:
http://builder.tajinc.org/?f=job_status&uuid=5c22b83a-cfc6-11dd-87c0-0013d314a49d
Missing Link Library (-lsocket):
http://builder.tajinc.org/?f=job_status&uuid=5c2231ee-cfc6-11dd-b9b8-0013d314a49d
Upstream Project needs to recognize the platform i386-pc-solaris2.11
http://builder.tajinc.org/?f=job_status&uuid=5c20dd94-cfc6-11dd-bdf0-0013d314a49d
...
Find something up your alley and fix it. These are the things the
autobuilder doesn't know how or has no chance to fix. If you download
the source, get it to build and submit it, the job list will adjust
within 4 hours of the package being accepted. If the build will be fixed
by another package, fix the other package and the rebuild will be
attempted in 5-7 days.
= How this helps =
We now have several things people can do when they come asking how to help:
1) Fix bugs they think they can tackle
2) Fix broken builds
3) Help triage problems for others to work on
4) ... ?
Comments (especially criticism)/questions are welcome.
Cheers,
-Tim
Erast Benson wrote:
Guys,
thanks to new AutoBuilder, NCP2 repository hit mark of 8000 packages:
r...@gnusolaris:~# apt-cache stats
Total package names : 12213 (489k)
Normal packages: 7975
Pure virtual packages: 78
Single virtual packages: 885
Mixed virtual packages: 72
Missing: 3203
However, number of "missing" packages is growing. This creates greater
delta which we need to address before 2.0 GA.
I suggest that now instead of continuing work on quantity we should
concentrate on quality a bit more and try to identify most "needed"
packages, fix them first... I bet that if we identify such "needed"
packages, it will be somewhat around 100, the rest of "missing" will
just built by AB.
Anyway, just wanted to let you know that we need to pay attention to
"missing" counter..
Thoughts?
_______________________________________________
gnusol-devel mailing list
gnusol-devel@lists.sonic.net
http://lists.sonic.net/mailman/listinfo/gnusol-devel
_______________________________________________
gnusol-devel mailing list
gnusol-devel@lists.sonic.net
http://lists.sonic.net/mailman/listinfo/gnusol-devel
