On Tue, 8 Sep 2020 at 19:11, Ralph Seichter wrote: > > * Ryan Schmidt: > > >> Tries being the operative word here. ;-) > > > > What are you trying to say? > > Did I step on somebody's toes?
I'm not aware why you would step on anyone's toes, but I also didn't understand what you tried to say in that sentence. > I am saying that the build that concerns > me timed out setting up the dependencies. That, from my understanding, > means the dependencies were either unavailable in binary form, or that > the attempt to access said binary form failed. Hence my comment above, > in an attempt to make light of the situation, as the smiley indicates. > > > We would need to see logs of the installation of the dependencies to > > know why they're taking so long, but I don't see any such logs, and > > don't know where or how that's happening or not happening. > > That makes tackling the underlying issue difficult, of course. You can in fact look at the equivalent builds from Azure, for example here: https://dev.azure.com/macports/macports-ports/_build/results?buildId=9200&view=logs&j=dde54236-b8c5-5879-af99-818e7b59912f&t=204c7e84-6a60-5987-1292-f9e129aab6e1 At the bottom you have a pastebin link with the build log of the port itself. However the logs from building dependencies are apparently missing. I thought those were available as well. I'm not 100% sure, but maybe we deliberately removed those at some point because it was consuming significant resources and it was deemed nearly useless. (I'm not saying that's true in your case.) > > We don't "ignore Travis results". > > Mojca Miklavec wrote (quote) "Generally we mostly ignore Travis results, > so there's no real reason to worry in your case.", which led me to > believe that you generally mostly ignore Travis results. How silly of > me. :-) Just to clarify my oversimplification. We don't literally ignore the results. If the Travis builds succeed ... we usually ignore the details :) :) :) If the Travis build fails, we would usually look into the reason for the failure, however: (1) In nearly all the cases (not all though!!!) the reason for the failure is either timeout or some network or timing issue. If that happens, we would "ignore" the fact that Travis build failed. What this mostly means is that users should not worry that their PR won't be accepted just because Travis decided to put a red cross to the CI job. In some cases the port would be manually checked by someone else to ensure that it builds. We could have payed a bit more attention to the individual builds to see if there is some flaw and we could have forced the dependencies to build faster. (2) In some other cases there would be a real build failure, but again this most often means that it would fail everywhere, so we would see a failure on Azure as well. (3) There's another large class of cases where the software is only supported on, say, 10.14 and newer. In those cases the Azure build would succeed (just because it only uses the newer OS versions) and the Travis build would fail (as it tries to build on older builders). But again, if someone is porting software that upstream doesn't bother supporting on older OSes, we won't generally block the PR just because the older macOS versions are no longer compatible. There certainly are cases where the results are useful. It's just not as often as we wish it would be. Mojca