"wrong" port, but instead, create a pseudo-path that is just there to run
junk (will be logged as junk-proxy)
fix a bug in the task handling host locking (no next task -> unlock, duh).
do not log multiple K for several ports on the same basepkgpath.
the plists that are current.
took longer than expected because I found a bug in my setup...
probably going to be more code to say "hey, these current packages depend
on not current".
also, since distfiles are "always fetchable", need to check for detained
files before checking for "already done", since already done will want to
check the size...
- we do rescan paths anyway, so make sure we queue only path.
- forgetting distfile details does not get around caching, so do creation
of distfiles in two times. cache is there to ensure unique distfiles, and
we can still forget details.
To do: remove distfiles from queue during forget, because there's no longer
any detail there.
reuse in can_be_junked. As exemplified by editors/tiled, a failing
port with nojunk set should also prevent junk tentatives, as these
will fail, but still untaint hosts...
seen by aja@ and naddy@, most probably.
run it in a chdir(distdir) instead, avoids situations
where the original dir is inaccessible by unpriv_user AND
simplifies the code too. What more could you ask for ?
handled by an earlier port, link to the relevant port which has the pkg_add.
Makes it much easier to figure out when show-prepare-results fails because
of conflicts in dependent ports...
First, it makes for simpler code. It also allows things to work when your
cwd is not readable by your user, such as /root, since File::Find wants the
cwd.
frequent occurrences of tag mismatches were probably triggered by
the import of qt5, which is a long-running nojunk port.
when we're finished with kdeN ports, there's pressure to force junking to
go thru kdeM ports, BUT actual junking *won't* happen in the presence of
a nojunk port, though the current code make it seem as though
we've "succeeded".
Forensics shows:
23826@1431149112: K: x11/kde4/webdev openbsd-2 kde3 vs kde4
23826@1431149112: J: devel/hs-FindBin openbsd-2
23826@1431149119: B: security/p5-Crypt-OpenSSL-RSA
23826@1431149120: J: x11/tellico-kde4 openbsd-2
which made no sense since nothing happened between the K and the J.
But the log of tellico shows the junk not happening.
Still tainted: 1
>>> Running junk in x11/tellico-kde4 at 1431149274
Can't run junk because of lock on x11/qt5,,-main
So synch "can_be_unjunked" for forced junks: it should not succeed if there's
a nojunk port.
Use that when switching groups to enforce full correct list of groups.
Figure out users that must exist locally, and error out if they don't.
Based on feedback by sthen@
