Description of problem: Using 32-bit install of Fedora 11, importing Scientific.IO.NetCDF fails due to 'missing' module called "Scientific_netcdf". Version-Release number of selected component (if applicable): 2.8-4-fc11 ScientificPython 4.0.0-2-fc11 netcdf, netcdf-devel, netcdf-static 2.6 Python How reproducible: Every time. Steps to Reproduce: 1. Install netcdf packages listed above as well as ScientificPython 2. From command-line, run python 3. From python prompt, "from Scientific.IO.NetCDF import *" Actual results: $ python Python 2.6 (r26:66714, Jun 8 2009, 16:07:26) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from Scientific.IO.NetCDF import * Traceback (most recent call last): File "<stdin>", line 1, in <module> File "Scientific/IO/NetCDF.py", line 169, in <module> from Scientific_netcdf import * ImportError: No module named Scientific_netcdf >>> Expected results: The module should load without failure. Additional info: I have done some digging, and I have a couple of suspicions about what is going on here. When attempting to install this module manually from source, the setup.py script fails to account for differing prefixes for the location of the netcdf include and library files. This installation script might have been designed prior to the change with respect to the location of the netcdf include files. However, I doubt this is exactly the cause, as when I force the manual build process to recognize the correct NetCDF locations, the above test still fails. So, I suspected that it is not compatible with NetCDF-4. I therefore uninstalled the NetCDF packages from my Fedora 11 install, and installed the NetCDF packages for the Fedora 9 distro, which has version 3.6.2-7 available. However, I still can't load the NetCDF module after doing both the rpm installation and the manual installation from source for the ScientificPython. I still suspect that there is some sort of incompatibility with version 4, as the manual build shows a lot of warnings from the compiler, but I am at a loss to figure this out any further.
Hmm, I appreciate the effort to figure out the problem. I'm going to be honest with you, I'm no longer personally using this package so its moved down on my priority list. This package could probably benefit from a new primary maintainer. That being said,I'll poke at it if I can find the time this week. If you find a fix that works for you I'll gladly apply it and push an update out. It may be in your best interest to strike up a conversation with the project developer, they may be more help than I am in the near term. If this package really isn't compatible with netcdf 4, it may need to be retired from Fedora completely. Let's hope that's not the case, and instead its just me making a bone-headed packaging mistake. -jef
(In reply to comment #1) > Hmm, > I appreciate the effort to figure out the problem. > > I'm going to be honest with you, I'm no longer personally using this package so > its moved down on my priority list. This package could probably benefit from a > new primary maintainer. > > That being said,I'll poke at it if I can find the time this week. If you find > a fix that works for you I'll gladly apply it and push an update out. It may > be in your best interest to strike up a conversation with the project > developer, they may be more help than I am in the near term. If this package > really isn't compatible with netcdf 4, it may need to be retired from Fedora > completely. Let's hope that's not the case, and instead its just me making a > bone-headed packaging mistake. > > -jef Jef, I just did some checking on another computer that I had access to that had an installation of Fedora 10 (64-bit, I believe...). Anyway, loading the Scientific.IO.NetCDF module works just fine on that, so this appears to be some sort of regression limited to Fedora 11 (assuming anyone else can reproduce this...). That computer had the following package versions: python 2.5.2-1 netcdf 4.0.0-1 ScientificPython 2.6.1-1 Also, with regards to the question about whether or not to remove ScientificPython from Fedora if it no longer works, it should be noted that this package is the only package advertised as the Python module for NetCDF files when doing a repository search. If removed, it would be wise to make sure another package that can do that job fills the void. I would be more than happy to learn more about package maintenance. I have been meaning to contribute back to the Linux community in more ways than just bug reports. Any suggestions on where to learn RPM packaging? Ben
Hmm, its probably a bug in my packaging on the new version of ScientificPython then. Something's probably changed in the build requirements and I didn't catch it. Which means is probably fixable. Give me the rest of the week and poke me on Sunday for an update. In the meantime you could play with a manual build of both 2.8 and 2.6.1 from source on F11 and see if you can spot a build error. As a workaround for your needs I could probably make available a version of 2.6.1 package compiled for F11 without much effort. -jef
(In reply to comment #3) > Hmm, its probably a bug in my packaging on the new version of ScientificPython > then. Something's probably changed in the build requirements and I didn't > catch it. Which means is probably fixable. Give me the rest of the week and > poke me on Sunday for an update. > > In the meantime you could play with a manual build of both 2.8 and 2.6.1 from > source on F11 and see if you can spot a build error. As a workaround for your > needs I could probably make available a version of 2.6.1 package compiled for > F11 without much effort. > > -jef Haha! I think I managed to figure it out! It seems to have something to do with ScientificPython's setup.py failing to properly detect the netcdf installation location. I am going to reset and try using the source found in the ScientificPython package. Hopefully I will be able to reproduce the results and possibly give a diff file for setup.py. In addition, I noticed that netcdf is not a prerequisite of ScientificPython. The problem with that is that if one installs netcdf *after* installing ScientificPython, then the shared library files are never created for Scientific_netcdf. It is very much possible that this might be the main source of issues, as the results might become order-dependent, which may be random in different situations. I'll let you know if I can reproduce the successful builds. Ben
Created attachment 351692 [details] Possible patch to properly detect netcdf installation location Note that the patch was made against the unpatched version of the setup.py. In other words, I did not apply the mpi patch and the arch-lib patch to setup.py, and this patch might conflict with the arch-lib patch.
(In reply to comment #4) Ok, I managed to take the rpm's source and confirm the issue is indeed with setup.py inability to properly identify the NetCDF installation location. The problem is that netcdf (like most packages) will install its devel files in a differing prefixed directory than the library files. setup.py assumes the prefixes will be the same. I attached a patch file for my version of the setup.py, but I think it might be a rather sloppy solution, and probably could be done better. Maybe it should fail if it can't find the netcdf install location? Oh, and I just noticed that netcdf is a prereq for netcdf-devel, which is a prereq for ScientificPython, so that should be fine. Ben
great! I'll look at applying this this evening or first thing tomorrow morning (my time) Beat me up if you don't see a build notice in the next 24 hours. -jef
Okay I think I have the your patch integrated. can you see if the binaries here http://koji.fedoraproject.org/koji/taskinfo?taskID=1476772 work for you on F11? I've tested F10 binaries locally using the patch. But my f11 system is at home so I'd like you to confirm the fix before I push it to updates-testing. -jef
(In reply to comment #8) > Okay I think I have the your patch integrated. > > can you see if the binaries here > http://koji.fedoraproject.org/koji/taskinfo?taskID=1476772 work for you on > F11? > > I've tested F10 binaries locally using the patch. But my f11 system is at home > so I'd like you to confirm the fix before I push it to updates-testing. > > -jef Works like a charm! Can't confirm anything for 64bit version, but the packages look like they have everything in them. I had a thought. Should something be added to the .spec file to test for the presence of the Scientific_netcdf.so file so that the rpm build will fail (as it should) if something breaks in the future?
that's a thought. In the files section I'd have to explicitly list all the files under the Scientific/linux2 module directory. I'll roll it up into the updates-testing update I send out today. In the meantime the unsigned koji build you have now should be workable for you. More pressing however. In the Fedora development branch... openmpi has changed significantly. if you are using ScientificPython's openmpi stuff...you might want to consider helping get ScientificPython working again before F12 release. -jef
ScientificPython-2.8-6.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ScientificPython-2.8-6.fc11
ScientificPython-2.8-6.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ScientificPython'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7724
I tested the update and it works great (I left feedback at the above link). Thanks very much to Ben and Jef for the fast work --- I needed this to work urgently so I could complete some data processing for a paper revision, so I was very pleased to find this fix! Matt.
ScientificPython-2.8-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.