| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
with the results to ADMIN.
Now the file will be created if the option is not defined and the
email will be sent too, otherwise only the file will be created.
The file with the results will be created in
${FTP}/pkgsrc-results-${DATE}.txt.
|
|
|
|
|
|
|
|
|
|
location of the perl package to install for bulk builds.
|
|
dependancies required for that script, an smtpd for example, as well.
|
|
|
|
pkgtools/pkglint to determine if pkg_install needs an update.
|
|
Make it so.
|
|
which is computed based on whether perl or perl-thread should be the
default.
|
|
in the package directory, and add a link to it from .broken.html at
the point where the build fails. Also adjust the auxilliary scripts
to handle/cleanup .broken.work.html files.
This should enhance the ability of developers to debug broken builds
by providing important information about what is happening as a build
progresses and fails.
|
|
|
|
|
|
when changing directory, breaking the resulting tsort from the printindex
script output.
|
|
else if desired.
Print out dates in the form: yyyy/mm/dd
|
|
|
|
build. Suggested by Christoph Badura.
|
|
setting SPECIFIC_PKGS=1, this is a convenient way to make sure you have
all required distfiles before starting a build. In particular, you will
get all distfiles for all required dependencies of the explicitly listed
packages. As part of this make the option processing part of this script
a bit more general purpose and add a -h|--help option.
|
|
In particular, when SPECIFIC_PKGS is set in /etc/mk.conf, you can now do
sh mk/bulk/build
and have the right thing happen. Only those packages explicitly listed
and those which are depended upon are considered for the build. Other
than the restricted list of packages, the bulk build works the same way
as a full bulk build.
|
|
|
|
email subject.
|
|
some shells can set MAIL to be the mailbox of the user, and
environment variables will override assignments in make when using
conditional assignments.
|
|
|
|
|
|
correctly reflect the pkgsrc arch.
(uname -p returns "unknown" on (my) Linux, which is not very helpful..)
|
|
- use AWK, GREP, SED and MAIL as set by defs.opsys.mk.
- use $? to test exit code of programs
|
|
|
|
|
|
|
|
fails, then abort the build.
|
|
|
|
environment, and pass them down to the bulk build. This means that the
/etc/mk.conf (or $MAKECONF) can be shared between ordinary builds and
bulk builds.
|
|
environment variable, which contains the name of the make(1) program to
invoke - suggestion by Julien Letessier some time ago, the confusion mine,
since I thought he was referring to something else completely.
Don't rely on there being a POSIX tr(1) in the path by default - test
explicitly for both "yes" and "YES".
Set the default for PRUNEDISTFILES to "no", since we can't assume that
the user wants us to delete something which he may have been keeping
around, and there are other ways of accomplishing this aim (lintpkgsrc
-o, for example).
Clean up some superfluous white space at the end of lines.
|
|
|
|
OBJMACHINE and OBJHOSTNAME to work. Also don't hardcode /usr/pkg and
/usr/X11R6 for LOCALBASE and X11BASE. Finally, fix a few typos in messages
while here.
|
|
the cache files used during a bulk pkgsrc build.
- replace the code in the build script that used to create the cache
files with a 'make bulk-cache' call.
|
|
|
|
to prevent it sitting there for days waiting for input in useless
situations.
|
|
Makes the output a bit long at times but gives a nice concise idea of where
you're at and if the build is moving
|
|
no need to make "bulk-package" or "clean" after it!
|
|
GROUP_SPECIFIC_PKGS into a top pkgsrc level call to make. The new way,
uses a shell 'for pkgdir in ....' and then calls a make in each pkg
directory.
This does 2 things. The first thing is that a 'build restart' starts
up _much_ faster because instead of calling 'make' for each package we've
already built and finding out they're already build, we just grep through
the list of already built pkgs. The second item (a side benefit) is that
now a progress meter is simple.
- add a progress meter to the build.
- add even more error checking.
|
|
|
|
- if something fails while extracting the DEPENDS for a particular package,
mark that package as broken and drop the DEPENDS info for it. This allows
the build to continue and properly marks the package as broken.
- if something fails while extracting the PKGNAME, also mark the pkg as broken.
- be more careful about seeing if directories exist before cd'ing to them.
Lack of such a test has caused problems elsewhere, so hopefully this will
make the system more robust.
|
|
latter no longer exists.
Also, use '&&' to separate commands where you don't want the second to
execute if the first fails!
|
|
|
|
of packages which must stay installed during the build, but are not pulled
in by the DEPENDS for each package. Currently, BULK_PREREQ will always include
pkgtools/digest. At this time, the primary use will be to add
BULK_PREREQ+=pkgtools/xpkgwedge
in /etc/mk.conf to do an xpkgwedge'd bulk build. It is up to the user to make
sure that the list of packages in BULK_PREREQ is a flattened list (ie all the
DEPENDS are listed too). Again, at this time, xpkgwedge is really the only
package that should be added to the list.
-add an ADMINSIG build.conf variable. This is the signature at the end of the
email report. Maybe now I'll quit forwarding reports signed as "-Hubert".
-while here, eliminate grep|awk lines and `grep >/dev/null` replacing them
with pure awk and grep -q.
|
|
the old behaviour. This is done because unless we're in the middle of a
bulk build, we don't really know that the cache files are up to date. These
are fairly time consuming (relative to a single smallish package build) to
generate and depend on all of the pkgsrc makefiles. During a bulk build, the
overhead is far outweighed by the savings.
In particular, 'make bulk-install' will now work correctly outside of a bulk
build (useful for debugging broken packages).
Thanks to Hubert who noted the 'make bulk-install' problem in a private email.
|
|
over several bulk builds on an alpha:
- At the start of a bulk build, 4 files are created to allow fast lookup of
various dependency tree things. These files are
.index == maps package name (foo-2.3) to directory (bar/foo)
.dependstree == contains the complete pkgsrc dependency tree in a tsort(1)
compatible format.
.depends == contains 1 line per package and lists all the build depends
for the package.
.supports == contains 1 line per package and lists all packages which
depend on this package.
- When a package fails to build, the list of all packages which depend upon
it is read from .supports. Each of those packages is immediately marked
as broken. This prevents us from trying to build those packages which can
have significant overhead if lots of other depends are installed before the
system notices the broken one.
In addition, the post-build postprocessing will now indicate that a package
is 'truely broken' (ie, bad PLIST, failed compilation) vs. a package which
is broken because it depends on a failed package. This assists in determining
where to focus our efforts in fixing broken packages.
- In the old approach, all packages are removed after each one is built. The
purpose was to a) conserve disk space, b) verify that all required dependencies
are in fact listed, and c) prevent conflicts. The problem was that often times
several packages in a row have similar depends. For example we might want to
build several perl packages in a row. In the old approach, we would install perl,
build the pkg, deinstall perl and continue with the next one.
In the new approach, when it is decided that a pkg is out of date and should be
rebuilt, the .depends file is used to obtain a list of pkgs we require. Then
and pkgs which are no longer needed are removed. This helps to minimize the total
number of pkg_add/pkg_delete's in a bulk build.
- Since the order of the build is controlled by the depends tree, all depends for a
given package will have been built by the time the pkg in question needs them.
If any of the depends failed to build, then the pkg which needs the failed one will
have been marked as broken. Given this, the complete depends list for a pkg is
read from .depends and the depends installed via pkg_add rather than relying on
recursive make calls to install the depends.
- while here, fix a few minor bugs
x - don't leave .make log files around when the build succeeds
x - make sure we refer to the correct report file in the email
x - use '.order' for the build order file instead of '.l'
x - use 'grep -c' instead of 'grep | wc -l'
|
|
of the top level build script and into the {pre,post}-build scripts. This
ensures that either of those scripts may be run directly and not rely on
a variable being set by the top level script.
Thanks to Hubert Feyrer for pointing out the problem in a private email.
These changes do not require any user changes to the build.conf file and
should be transparent to the user.
|
