replace "unchanged for 28 seconds" by "frozen for 28s"
remove frozen message for "waiting-for-lock" entirely... there's already
a depend/junk task that shows this clearly, and the message tends to be
WAY too long anyways.
- provide a chroot_user definition during prop finalize
- let shellclass be depend on the object built
- have all shells store prop and have access to it
- move the chrooted code into default core shell
- tweak running so that quoting/building commands happen everywhere
- change Config to recognize -B as a chroot override.
Tested thru distant chroot, local and distant !chroot
local chroot still not working, probably missing something stupid
its sleeping interval, but rather asks it from the reporter.
Give limiter customer access to timing information. Eventually,
the reporter could possibly shrink/enlarge the display timeout
automatically.
confuses the hell out of some people (hi naddy!) as dpb restarts will notice
built packages regardless of the path.
make things more symetric by doing the check each time we go through tobuild.
I have some misgivings about this, since this is potentially expensive...
by fgs@, kili@, nigel@)
repair it.
- introduce end_check to cope with package files updated
(not quite satisfied with the source code, but this works, and will do for
5.4).
- adjust report to build.log to conform to the new semantics: namely, if it
didn't fail, then it's okay, don't even look at possibly missing packages
because of nfs (noticed by nigel@).
- pass error condition from Job/Port.pm all the way to the engine
- use that to know whether we fail, instead of the existence of packages
(but still keep track of what we're doing correctly, THAT'S the fix)
- refactor error handling into OO version
- keep track of locks/errors/packages we're waiting for thx to nfs
all of these keep the lock around, and react to the lock being removed.
use case for nfs: if there was a revision bump after dpb scanned the port,
it will never find the package. Removing the lock will allow dpb to rescan
and find the correct packages.
with this, dpb no longer waits after nfs. More importantly, it does not
report nfs hangs as E:, rather as H:... (and it can "wait" for much longer
periods, since it keeps running and only checks on new jobs).
subpackages vanish too entirely, so later, when other ports want them
as dependencies, we're in trouble!
Instead, record both MULTI and BUILD, and compare them when merging depend.
Don't stub out the new paths directly, but "pre-stub them out" with an
IGNOREd message, so the engine picks them, stubs them out for real, and
logs the reason.
equivalent paths will end up with no depends, as they actually share
info, but still on queues.
So do a sanity check when stuff has no depends: if it's stubbed out, just
drop it, as it's been ignored under another name.
Problem noticed and info provided by landry@
(it's all vax's fault anyways, as stub_out is only needed to let dpb fit
within 32M while gobbling thousands of ports info)
values can be in config files.
command line should still override config files.
to be documented shortly, but stuff like
FETCH_JOBS=n
WANTSIZE=1
MIRROR=0
should now work within a hosts file.
- move the meat of handle_options from dpb into config->parse_command_line
(this means a backcall to still inherit from OpenBSD::State).
- move parse_config_files from core into config.
- move the prop handling into proper HostProperties (part of config
obviously)
- create a Core::Init file that contains all the former DPB::Host::Factory
and associated jobs.
there's still a wee little bit of cleanup to do, but this should be
easier to maintain, as all option handling is now in one place, and
startup and host confi is now easier to figure out.
- add a -DMIRROR=0/1 setup that controls whether SUPDISTFILES will be
fetched (defaults to 1 for -F and 0 for -f).
- actually allow for several host files to be parsed, as the name implies
THIS IS A VERY BUSY OPTION. It's intended with a syslog.conf that
will send the log messages elsewhere, to try to pinpoint hang/panic
locations in a given port build, as system crash failures tend to leave
log files in a lagging state.
idea discussed with kurt@
THIS REQUIRES MOST RECENT bsd.port.mk, OTHERWISE THIS WILL BREAK BADLY.
The values are not used yet, but I fully intend to make it possible to
run non-regression tests in the not too distant future.
.for v1 v2 in list
techniques, which make it clearer.
Add new syntax to distfiles, which is not painful to do now, and support it
for dpb fetch as well: a distfile can now be file{url} to specify a different
result from the url (this allows really weird naming scheme on http sites
to give us consistent files, which has become a nagging problem).
This still doesn't mean you shouldn't encourage upstream to do the right thing
and provide nice archive urls.
extend the fetch process in bsd.port.mk to work more like dpb does, namely
download to intermediate "part" files that don't vanish and use -C if
necessary.
Both those mean that FETCH_CMD has to work like ftp, including the -C and
-o support...
discussed with various people.
this is a bit too much, but this catches:
SUBDIR=devel/py-gobject3,python3 make dump-vars DPB=Yes
devel/py-gobject3,python.BUILD_DEPENDS=graphics/py3-cairo STEM->=0.10.38:devel/gettext lang/python/3.2 STEM->=0.41.1p0:textproc/intltool devel/gmake archivers/xz
devel/py-gobject3,python.IS_INTERACTIVE=No
devel/py-gobject3,python.SUBPACKAGE=-main
devel/py-gobject3,python.FLAVOR=python3
devel/py-gobject3,python.BUILD_PACKAGES= -main -common
devel/py-gobject3,python.FULLPKGNAME=py3-gobject3-3.8.1p0
devel/py-gobject3,python.RUN_DEPENDS=STEM->=0.10.38:devel/gettext lang/python/3.2 devel/py-gobject3,-common graphics/py3-cairo
devel/py-gobject3,python.LIB_DEPENDS=STEM->=0.10.38:devel/gettext converters/libiconv devel/gobject-introspection
devel/py-gobject3,-common.BUILD_DEPENDS=graphics/py3-cairo STEM->=0.10.38:devel/gettext lang/python/3.2 STEM->=0.41.1p0:textproc/intltool devel/gmake archivers/xz
devel/py-gobject3,-common.IS_INTERACTIVE=No
devel/py-gobject3,-common.SUBPACKAGE=-main
devel/py-gobject3,-common.FLAVOR=python3
devel/py-gobject3,-common.BUILD_PACKAGES= -main -common
devel/py-gobject3,-common.FULLPKGNAME=py-gobject3-common-3.8.1
devel/py-gobject3,-common.RUN_DEPENDS=STEM->=0.10.38:devel/gettext lang/python/3.2
(note the "wrong" flavor, which means that
devel/py-gobject3,python3,-main ends up without an associated fullpkgname)
