On 05/19/15 12:45, Marc Espie wrote:> On Tue, May 19, 2015 at 12:06:48PM -0400, RD Thrush wrote: >> I realize dpb is undergoing rapid development so if the following anomaly is >> old news, please disregard. >> >> Using -current(amd64) dpb and multiple chrooted remote hosts, I notice that >> rerunning some failed jobs result in success while others still fail. >> >> In my partial build, the following jobs failed (dpb still running): >> multimedia/gstreamer-0.10/plugins-base >> graphics/clutter/core >> x11/gnome/gedit >> x11/kde/games3 >> x11/gnome/libcryptui >> x11/gnome/gvfs >> x11/xfce4/xfce4-panel >> >> I saved the log and lockfile and reran each by removing their lockfile. >> 3 failed again but the following succeeded: >> multimedia/gstreamer-0.10/plugins-base >> graphics/clutter/core >> x11/gnome/gedit >> x11/xfce4/xfce4-panel >> >> Why did reruns succeed? Or, better yet, why did the original job fail? I >> will have full dpb logs once the dpb run completes if useful to help analyze. > > This is fairly unlikely to be linked to dpb development. > > There's some random aspect to the first runs of dpb, and it tends to > catch "hidden" dependencies. Keep in mind that while you build, other > jobs may pkg_delete stuff that's not explicitly > declared as run-dependencies... > > This happens routinely in bulk-builds. If you were doing a "fresh" run with > no previous stats, you're very likely to have hit some new ones.
I don't think it was "fresh" since I've been using the -s flag for a long time. I do remove all packages on both remote chroot hosts as well as the non-chroot localhost before starting the build. Looking at the smallest logfile[3], in the clean phase: ===> Cleaning for xfce4-panel-4.12.0p2 (Junk lock failure for dpb@a8v2 at 1432039248) Received IO (Junk lock obtained for dpb@a8v2 at 1432039332) Short-cut: depends already handled by x11/gnome/libcryptui >>> Running show-prepare-results in x11/xfce4/xfce4-panel at 1432039333 Is the above Junk lock failure significant? Please note that libcryptui was one of the 7 that failed during the initial run and again in the subsequent run. At the end of the build phase, it goes off the rails: Making all in clock Makefile:478: recipe for target 'all-recursive' failed gmake[2]: Leaving directory '/pub/tmp/pobj/xfce4-panel-4.12.0/xfce4-panel-4.12.0/plugins' Makefile:597: recipe for target 'all-recursive' failed gmake[1]: Leaving directory '/pub/tmp/pobj/xfce4-panel-4.12.0/xfce4-panel-4.12.0' Makefile:508: recipe for target 'all' failed ===> Exiting x11/xfce4/xfce4-panel with an error gmake: can't load library 'libintl.so.6.0' gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 *** Error 2 in /usr/ports/x11/xfce4/xfce4-panel (/usr/ports/infrastructure/mk/bsd.port.mk:2764 '/tmp/pobj/xfce4-panel-4.12.0/.build_done') *** Error 1 in /usr/ports/x11/xfce4/xfce4-panel (/usr/ports/infrastructure/mk/bsd.port.mk:2485 'build') *** Error 1 in /x2/pub/OpenBSD/current/ports (/usr/ports/infrastructure/mk/bsd.port.subdir.mk:147 'build') Error: job failed 256 [4] is the logfile from the successful rerun done in the same dpb session. [5] is the diff between failure and success. Is there anything further to be learned from the associated dpb logs? I'm running -current amd64 Sun May 17 20:42:55 MDT 2015 and see that there are pending changes to chroot and id that you've requested. Are they relevant to this report? [3]<http://arp.thrush.com/openbsd/dpb/20150519/logs/paths/x11/xfce4/xfce4-panel.log.201505190843.26> [4]<http://arp.thrush.com/openbsd/dpb/20150519/logs/paths/x11/xfce4/xfce4-panel.log> [5]<http://arp.thrush.com/openbsd/dpb/20150519/logs/paths/x11/xfce4/xfce4-panel.log.diff>
