<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 19, 2019, at 8:47 AM, Arjun Salyan via macports-dev <<a href="mailto:macports-dev@lists.macports.org" class="">macports-dev@lists.macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">I have some more improvements to demo app:<div class=""><ul class=""><li style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><b class="">Build History is now Dynamic:<span class="Apple-converted-space"> </span></b>By Making some minor tweaks to the python script sent by Mojca, I was able to load build history from buildbot into the database. I loaded only few recent logs for "<b class="">10.14_x86_64</b>" & "<b class="">10.13_x86_64</b>". Since, build history of all ports is not yet on the database, so it would not appear on port-detail page for all ports. To see it working, gmsh would be a fine example: <a href="https://frozen-falls-98471.herokuapp.com/ports/gmsh/" class="">https://frozen-falls-98471.herokuapp.com/ports/gmsh/</a> . It is not very neat yet, the os filter is 'just working'. But now we have a good starting point to improve upon.<br class=""></li><br class="Apple-interchange-newline"></ul></div></div></blockquote></div>Perhaps I’ve missed some previous discussion but please note that we can’t expect all ports to build successfully on the buildbots. There are a number of ports that require a dependency to be installed with a non-default variant in order to build successfully. A short-coming of MacPorts is that this cannot be done progammatically—the user must manually install the dep with the required variant.<div class=""><br class=""></div><div class="">An example would be my port, hdhomerun-gui. To function, it requires VLC to be installed with the non-default variant “+DVB”. The buildbot cannot successfully built this port because there is no user to manually install VLC +DVB. </div><div class=""><br class=""></div><div class="">My search found 195 Portfiles that include the active_variants PortGroup. Not all of them will fail to build—the port may be testing if a dep is installed with an unsupported non-default variant. I think that is rather less common but I didn’t review every case.</div><div class=""><br class=""></div><div class="">When this is rolled out, we don’t want to make users think that a port will fail to build on their system when it is just a case of needing a non-default variant. </div><div class=""><br class=""></div><div class="">However, I don’t know how to handle this cleanly. Perhaps we could parse the build log looking for the message that informs the user how to install the required variant. If found, instead of saying the build failed, we could indicate that the build was not attempted as the buildbot configuration could not support a successful install.</div><div class=""><br class=""></div><div class="">Craig</div><div class=""><br class=""></div></body></html>