| raw e-mail | index | archive | help
>>>>>>> 75464941dc . >>>>>>> >>>>>> >>>>>> One thing of possible note: >>>>>> >>>>>> Failing . . . >>>>>> >>>>>> Host OSVERSION: 1500006 >>>>>> Jail OSVERSION: 1500014 >>>>> >>>>> I have finished a package builder refresh this morning. All our = >>>>> builder hosts (except PowerPC - I don't touch those) are now on = >>>>> main-n269671-feabaf8d5389 (OSVERSION 1500018). >>>>> >>>>> ampere1 successfully finished its 140releng-armv7-quarterly build, = >>>>> so it looks like the problem with stuck builds was limited to = >>>>> ampere2 building main-armv7. I'll keep a close eye on this one = >>>>> when it starts its next build. >>>>> >>>> >>>> I see that main-armv7 started. >>>> >>>> It queued only 31935 instead of the prior 34528 (or more): it is = >>>> doing an >>>> incremental build instead of a full build. For example, pkg was not = >>>> built >>>> but instead the prior build is in use. Thus bad results from the = >>>> prior >>>> build might be involved in this new build. >>>> >>>> I'd recommend forcing a full "poudriere bulk -c -a" that does a = >>>> from-scratch >>>> build for the purposes of the main-armv7 test. >>> >>> Actually the test is not going to previde the information we are >>> after as things are. >>> >>> giflib-5.2.2 failed to build, which leads to devel/doxygen being >>> skipped. devel/doxygen was the first one to hang up in the prior >>> 2 failing attempts, if I remember right. >>> >>> giflib-5.2.2 also causes graphics/graphviz to be skipped. >>> graphics/graphviz was installed just before the hangup in all of >>> the example hanups. So the context will not be replicated. >>> >>> We need graphics/giflib to build to actually do the test. >> >> Looks like: >> >> https://cgit.freebsd.org/ports/commit/graphics/giflib?id=3D5007109903f= c271e3ef0ba01d78781c1fed99f3f >> >> is the fix for the graphic/giflib build failure. > > Well, main-armv7 is building again and things are still > getting stuck. So much for my idea. For reference I > list the over 10-hr-so-far ones: > > doxygen-1.9.6_1,2 build-depends 13:03:54 > py39-pydot-2.0.0 run-depends 12:24:04 > py39-pygraphviz-1.6 lib-depends 12:10:38 > > "ps -alxdww" would likely be appropriate to get a copy > of the otuput of. > > "procstat -k -k" usage and the like on stuck processes > would probably be appropriate. > > Does anyone with appropriate investigative background > have login access to ampere2 to take a look at what > is getting stuck? This is unfortunate. I'm sure I have the appropriate background, but = I'm spread very thin! I'll get as much information as I can about this = machine while it's stuck, before I bounce it again. I think it may be worth a try building those ports in isolation on = ref14-aarch64, and see what they're trying to do. I'll also set up a = set of refX-armv7 jails on that machine. Hopefully we can get to the bottom of this soon. This is a very tedious = failure mode. We could also try to put an older armv7 image on the builder jail on = ampere2. Depending on whether we have a sufficiently old image, that = will either be very straightforward, or a very deep rabbit hole. Thanks again for keeping an eye on this. We really should have better = monitoring for stuck builds than "Mark will tell us". :-) Philip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>