py-igraph @0.9.0: building on 10.6 i386 causes kernel panic

[ryandesign (Ryan Carsten Schmidt)]

Trying to build py3*-igraph @0.9.0 on the 10.6 i386 buildbot worker causes a kernel panic:

• ​https://build.macports.org/builders/ports-10.6_i386-builder/builds/27052
• ​https://build.macports.org/builders/ports-10.6_i386-builder/builds/27068

It would be great to prevent the port from trying to build in this case so that I don't have to manually fix the server whenever the port is changed.

This problem didn't happen with versions before 0.9.0.

This problem doesn't happen on 10.6 or later when building for x86_64. Didn't try building for i386 or ppc on earlier OS versions.

I'm able to build it universal for x86_64+i386 on 10.13.6, so removing i386 from supported_archs doesn't seem like the right solution.

Maybe:

if {${os.platform} eq "darwin" && ${os.major} <= 10 && ${configure.build_arch} eq "i386"} {
    known_fail yes
    pre-fetch {
        ui_error "${name} @${version} cannot be built for i386 on this OS version"
        return -code error "incompatible platform"
    }
}

[szhorvat (Szabolcs Horvát)]

@nerdling : python-igraph 0.9.0 does have a few issues, which is why I didn't submit a PR to update to 0.9.0. I was planning to wait for 0.9.1. Next time, can you please let me know before you do a major (i.e. 0.x.0 version) update?

[szhorvat (Szabolcs Horvát)]

The kernel panic happens while building the C core of igraph.

Given that the same does not happen when building the standalone C core (igraph 0.9.0 port), it is likely that the kernel panic is somehow triggered by building one of the bundled dependences. The igraph port links to external versions of most of these dependencies instead of building the bundled versions. I will submit a PR for py-igraph to build it the same way as igraph, and let's see if that makes the problem go away.

In fact, one of the reasons I wanted to wait until 0.9.1 was that it wasn't possible to change the configuration of py-igraph 0.9.0 to link against external dependencies, without applying a patch first.

[szhorvat (Szabolcs Horvát)]

PR is here: ​https://github.com/macports/macports-ports/pull/10169

@ryandesign : Please let me know if the issue on 32-bit 10.6 is still present.

[szhorvat (Szabolcs Horvát)]

I can now see that the PR will effectively disable py-igraph on 10.6 i386, as one of the newly added dependencies, ARPACK, is currently failing to build on that platform. I think this is fine. There is real value in building py-igraph with a new version of ARPACK—the reliability is significantly better.

[szhorvat (Szabolcs Horvát)]

In 6493ca31eae6fcff5ea7ef906366077eaa5ac262/macports-ports (master):

py-igraph: update dependencies

• update dependencies given the changes in python-igraph 0.9
• build with external (instead of bundled) dependencies when appropriate
• remove py27 subport as Python 2.7 is no longer supported
• remove variants
• See: #62399

[ryandesign (Ryan Carsten Schmidt)]

Replying to szhorvat:

PR is here: ​https://github.com/macports/macports-ports/pull/10169

@ryandesign : Please let me know if the issue on 32-bit 10.6 is still present.

Thanks. No kernel panic since the port did not build because its dependency gcc8 could not build. ​https://build.macports.org/builders/ports-10.6_i386-builder/builds/27306/steps/install-dependencies/logs/stdio

[szhorvat (Szabolcs Horvát)]

Where can I check the success/failure of the builds myself, after a port was updated? I know of this page, but it does not show the result you just linked to:

​https://ports.macports.org/port/py38-igraph/builds

I was hoping to get the same information for the igraph port on 10.7.

[ryandesign (Ryan Carsten Schmidt)]

Build information does not appear on ports.macports.org until several hours later; there is an import process that runs a few times a day, I believe. Also, new builds are not being imported right now because of a problem.

You can usually see the build results by clicking the link to the commit and clicking the red "X" or green checkmark to the left of the commit message. In this case, there is no status information for this commit because a second commit for this port came in right after so the status information was attached to that commit instead.

[kencu (Ken)]

I noticed gcc8 was broken when the JIT was added...I think that was what broke it.

I believe I know how to fix it, but haven't got around to doing it yet.