bob: update to 1.1.0

[andre.dos.anjos@…]

A new version of "bob" (1.1.0) is out. Could you please update the portfile with the one attached?

This version also kind of solves the debate on bug #36404 - we no longer need to have a special download for bob, the github tagged version is identical to the packages which are offered for download on our project homepage.

Thanks, A

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I'll get it updated.

Note that the Cc field needs complete email addresses.

It's better if your submit a unified diff of your changes, rather than a complete new portfile, so that it's easy for us to see what changes you're proposing without having to download it and diff it ourselves.

When submitting a patch, use the "haspatch" keyword. When the port you're submitting the patch for is one you maintain, use the keyword "maintainer".

[andre.dos.anjos@…]

Version using v1.1.0 (instead of v1.1.0c0)

[andre.dos.anjos@…]

Thanks. I have attached the diff file. Note I have also just updated the Portfile. Looking at it I saw it referred to an non-existing tag at github.

[ryandesign (Ryan Carsten Schmidt)]

Replying to andre.dos.anjos@…:

Thanks. I have attached the diff file. Note I have also just updated the Portfile. Looking at it I saw it referred to an non-existing tag at github.

Yes, you had set the version number to "1.1.0c0" before but the actual version number appears to be "1.1.0". Before, "port livecheck" would print "bob seems to have been updated (port version: 1.1.0c0, new version: 1.1.0)"; now it prints nothing, thus correctly indicating that the port is up to date.

I removed the "name" line since the "github.setup" procedure sets it for you.

Installing the port produced an error message:

Error: bob: Error executing python27: invalid command name "port:py27-numpy"

There was a blackslash missing after the py-distribute dependencies in the python variants. Remember to test your portfile before submitting it. (In the Terminal, "cd" to the directory containing your modified portfile, then type "sudo port install" (without specifying a port name).)

I slightly adjusted the variant descriptions to make them read more like checkbox or radio button labels.

The checksums did not match:

--->  Checksumming bob-1.1.0.tar.gz
Error: Checksum (rmd160) mismatch for bob-1.1.0.tar.gz
Portfile checksum: bob-1.1.0.tar.gz rmd160 8d6696bac29896e99760ecbcc4984725e5676920
Distfile checksum: bob-1.1.0.tar.gz rmd160 488fadd37b5f1c7047035d791e21863d5d258b9c
Error: Checksum (sha256) mismatch for bob-1.1.0.tar.gz
Portfile checksum: bob-1.1.0.tar.gz sha256 1cf7e20e6bb4e1fe96f1abdab909dc1df6c916db4eadc2ef3d356c53422a4366
Distfile checksum: bob-1.1.0.tar.gz sha256 dcdd59727185d4df85d68e644cc8f2ce6d9e9132cab3a7d8a0b981b0d7eb926a

I updated the portfile checksums to match the actual distfile.

cmake configuration failed with:

CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
  Could NOT find PYTHON_sphinx (missing: PYTHON_SPHINX)

I moved the py-sphinx dependencies from the doc variant into the python variants.

Then the build failed with:

CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
  Could NOT find PYTHON_matplotlib (missing: PYTHON_MATPLOTLIB)

py27-matplotlib is already declared as a dependency and is installed so this confuses me. I'm attaching my new diff for now and then I'll continue to investigate.

[andre.dos.anjos@…]

I'm terribly sorry about this - believe it or not I do normally check these things (it's early morning here and I must still be sleeping). I'm trying to compile locally and reproduce the problem you described.

[andre.dos.anjos@…]

Here is my hypothesis on the problem (it will take a while to be able to reproduce it locally): macports does have py27-matplotlib installed, but python2.7 is pointing to the system python instead which does not have it. Can you double-check that you are not using the system python2.7 by default?

[ryandesign (Ryan Carsten Schmidt)]

"which python" is indeed /usr/bin/python on my system, which should be fine; a port shouldn't require the user to "sudo port select" any particular python (or other port). I considered this cause as well, but can't yet understand why it can find other modules but not matplotlib, since they appear to be found via the same cmake/python function call.

-- Found PYTHON_setuptools: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools  
-- Found PYTHON_argparse: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/argparse.pyc  
-- Found PYTHON_numpy: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy  
CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
  Could NOT find PYTHON_matplotlib (missing: PYTHON_MATPLOTLIB)

...I just cleaned the port and tried again and this time it found matplotlib just fine. Again confusing. Let me try it a few more times...

[andre.dos.anjos@…]

I agree the port should not depend on it - and I believed it did not ;-)

The -DWITH_PYTHON flag we pass to the variant should be in charge of making the build only use the version indicated by the user.

I'm not sure how the versions got mixed up. Probably a bug in our build system?

Many thanks for investigating this - it is very useful.

[ryandesign (Ryan Carsten Schmidt)]

To clarify: without changing anything on my system (python is still /usr/bin/python), just cleaning the port and retrying is now working. I can't explain that, but since I can't reproduce the problem right now, I'll just commit the changes, assuming the build completes successfully.

[ryandesign (Ryan Carsten Schmidt)]

The build completed so I committed the changes in r98470. Thanks. In addition to those changes already shown in the patch here, I fixed the case of the ImageMagick dependency.

I have some other concerns about this port but I'll file a separate ticket for that.