Package Details: python-pyhdf 0.10.1-1

Git Clone URL: https://aur.archlinux.org/python-pyhdf.git (read-only, click to copy)
Package Base: python-pyhdf
Description: Python bindings for the HDF4 library
Upstream URL: https://github.com/fhs/pyhdf
Licenses: MIT
Submitter: fhs
Maintainer: None
Last Packager: fhs
Votes: 7
Popularity: 0.000000
First Submitted: 2019-03-23 23:24 (UTC)
Last Updated: 2019-03-24 01:32 (UTC)

Latest Comments

1 2 Next › Last »

u1bmoW1r16 commented on 2024-09-01 19:23 (UTC)

v0.11.4 can be built against hdf-4.3.0 with the following patches:

https://github.com/fhs/pyhdf/commit/7746b030c3e5b3d7ba05b4e94b747a92f1f773a5.patch

and

diff --git a/pyhdf/hdfext_wrap.c b/pyhdf/hdfext_wrap.c
index 80b3410..6009efa 100644
--- a/pyhdf/hdfext_wrap.c
+++ b/pyhdf/hdfext_wrap.c
@@ -4116,7 +4116,7 @@ static int32 _SDgetcompress(int32 sds_id, int32 *comp_type, int32 *value,
 #ifdef NOCOMPRESS
     status = -1;
 #else
-    status = SDgetcompress(sds_id, comp_type, &c_info);
+    status = SDgetcompress(sds_id, (comp_coder_t *) comp_type, &c_info);
     switch (*comp_type)  {
         case COMP_CODE_NONE:
         case COMP_CODE_RLE :

djscholl commented on 2012-03-11 18:25 (UTC)

Arch version bump to revert to the dependency on hdf4-nonetcdf, thanks to Arch user giniu.

giniu commented on 2012-03-11 09:29 (UTC)

Now I have same conflict as before - my package requires both python2-pyhdf and python2-netcdf4. Now, the problem is that hdf4 provides netcdf and conflicts with netcdf package, which is required by python2-netcdf4 (which in turn cannot work with netcdf provided by hdf4) - standard way to do this, like most distributions does - is to disable netcdf in hdf and it works like a charm. I'd like to ask for switching back to hdf4-nonetcdf - that package was flagged as out of date only two days ago, lets give its maintainer a chance to update it before switching and introducing conflicts only to use minor update in dependency few days earlier (4.2.6 vs 4.2.7). At least that's my opinion about it :)

djscholl commented on 2012-03-11 02:09 (UTC)

Arch version bump to update the dependency, thanks to Arch user jeruntu.

jeruntu commented on 2012-03-10 16:43 (UTC)

The dependency hdf4-nonetcdf is outdated, it should use hdf4 2.7-1 instead.

giniu commented on 2011-02-14 13:03 (UTC)

cool :)

djscholl commented on 2011-02-14 12:45 (UTC)

The python2-pyhdf package is available now: https://aur.archlinux.org/packages.php?ID=46498

djscholl commented on 2011-02-14 12:43 (UTC)

Update of pyhdf: improved package name and fixed NetCDF-related package conflicts, thanks to Arch user Giniu.

djscholl commented on 2011-02-14 03:41 (UTC)

I bumped the Arch version to fix package names, license file, minor PKGBUILD format items. This makes it more useable for anyone who wants the netcdf functionality in the future. I will introduce a python2-pyhdf without netcdf as suggested by Giniu.

giniu commented on 2011-02-12 13:42 (UTC)

Hi. About maintaining this package, I think you are doing good job. I already have quite a lot of packages (93 currently, though maybe half of them are -git, -hg or -svn so it doesn't take that much time, but still I'm checking if they build and stuff like that). I think that when it will be updated for python2 it could be left alone for some time, so to say, I'd prefer to help by giving feedback :) I think we don't need pyhdf-nonetcdf. The only functionality that gets lost is reading of cdf file, while developers recommends using pycdf for this, which can also write them. That way we avoid conflicts. Also, hdf4 and pyhdf are here only for legacy applications, so I don't think that removing it would break too much, especially that there are no packages that depend on it here in AUR. If someone needs cdf files support, he can use pycdf. About library naming, I believe it would be better to name it python2-pyhdf, unless python-pyhdf already existed - at least that's what I did for ETS. I think it's better to have possibly all python 2 packages starting with python2-, then you can check your python 2 libraries with "pacman -Qs python2-" and python 3 libraries with "pacman -Qs python-", while creating more python 2 libraries with names starting with python- instead of python2- makes it harder to determine without looking at dependencies. Of course, if there was already python- and the lib is python 2 only, it doesn't make sense to create new package and leave old one behind unmaintained/unused. New name also solves other issue, if someone really really wants to use pyhdf with netcdf support, he would be able to use legacy pyhdf package, while python2-pyhdf could be hdf4-nonetcdf version. At least I think that this is good solution. Cheers, Giniu.

1 2 Next › Last »