On Tue, May 19, 2015 at 02:22:39PM -0400, RD Thrush wrote: > 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.
No, it's not. > 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' Reminds me of old old issues with ldconfig. If the rename from ld.so.hints.XXXXX to ld.so.hints in ldconfig isn't atomic, this could happen. This bug didn't come back. There might a filesystem issue. Otherwise, I don't see how gmake could fail to load that library. > 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? Doesn't sound likely. Any fs corruption ? run fsck on that one lately ?
