iustin / pyxattr

A python module for accessing filesystem Extended Attributes
https://pyxattr.k1024.org/
GNU Lesser General Public License v2.1
30 stars 15 forks source link

Build failure with 0.7.1 #24

Closed lfos closed 3 years ago

lfos commented 4 years ago

Unfortunately, I don't have the time to look into this more carefully, but trying to build a package in a clean chroot currently fails:

running build
running build_ext
building 'xattr' extension
creating build
creating build/temp.linux-x86_64-3.8
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -D_XATTR_VERSION="0.7.1" -D_XATTR_AUTHOR="Iustin Pop" -D_XATTR_EMAIL="iustin@k1024.org" -I/usr/include/python3.8 -c xattr.c -o build/temp.linux-x86_64-3.8/xattr.o -Wall -Werror -Wsign-compare
creating build/lib.linux-x86_64-3.8
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.8/xattr.o -L/usr/lib -o build/lib.linux-x86_64-3.8/xattr.cpython-38-x86_64-linux-gnu.so
running build
running build_ext
building 'xattr' extension
creating build/temp.linux-x86_64-2.7
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -D_XATTR_VERSION="0.7.1" -D_XATTR_AUTHOR="Iustin Pop" -D_XATTR_EMAIL="iustin@k1024.org" -I/usr/include/python2.7 -c xattr.c -o build/temp.linux-x86_64-2.7/xattr.o -Wall -Werror -Wsign-compare
xattr.c: In function ‘convert_obj’:
xattr.c:144:8: error: implicit declaration of function ‘PyUnicode_FSConverter’; did you mean ‘PyUnicode_Concat’? [-Werror=implicit-function-declaration]
  144 |     if(PyUnicode_FSConverter(myobj, &(tgt->tmp))) {
      |        ^~~~~~~~~~~~~~~~~~~~~
      |        PyUnicode_Concat
xattr.c: At top level:
xattr.c:1178:15: error: variable ‘xattrmodule’ has initializer but incomplete type
 1178 | static struct PyModuleDef xattrmodule = {
      |               ^~~~~~~~~~~
xattr.c:1179:5: error: ‘PyModuleDef_HEAD_INIT’ undeclared here (not in a function)
 1179 |     PyModuleDef_HEAD_INIT,
      |     ^~~~~~~~~~~~~~~~~~~~~
xattr.c:1179:5: error: excess elements in struct initializer [-Werror]
xattr.c:1179:5: note: (near initialization for ‘xattrmodule’)
xattr.c:1180:5: error: excess elements in struct initializer [-Werror]
 1180 |     "xattr",
      |     ^~~~~~~
xattr.c:1180:5: note: (near initialization for ‘xattrmodule’)
xattr.c:1181:5: error: excess elements in struct initializer [-Werror]
 1181 |     __xattr_doc__,
      |     ^~~~~~~~~~~~~
xattr.c:1181:5: note: (near initialization for ‘xattrmodule’)
xattr.c:1182:5: error: excess elements in struct initializer [-Werror]
 1182 |     0,
      |     ^
xattr.c:1182:5: note: (near initialization for ‘xattrmodule’)
xattr.c:1183:5: error: excess elements in struct initializer [-Werror]
 1183 |     xattr_methods,
      |     ^~~~~~~~~~~~~
xattr.c:1183:5: note: (near initialization for ‘xattrmodule’)
xattr.c: In function ‘PyInit_xattr’:
xattr.c:1196:19: error: implicit declaration of function ‘PyModule_Create’; did you mean ‘PyModule_Check’? [-Werror=implicit-function-declaration]
 1196 |     PyObject *m = PyModule_Create(&xattrmodule);
      |                   ^~~~~~~~~~~~~~~
      |                   PyModule_Check
xattr.c:1196:19: error: initialization of ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
xattr.c:1198:16: error: ‘return’ with a value, in function returning void [-Werror=return-type]
 1198 |         return NULL;
      |                ^~~~
xattr.c:1189:1: note: declared here
 1189 | PyInit_xattr(void)
      | ^~~~~~~~~~~~
xattr.c:1232:12: error: ‘return’ with a value, in function returning void [-Werror=return-type]
 1232 |     return m;
      |            ^
xattr.c:1189:1: note: declared here
 1189 | PyInit_xattr(void)
      | ^~~~~~~~~~~~
xattr.c:1239:5: error: ‘return’ with a value, in function returning void [-Werror=return-type]
 1239 |     INITERROR;
      |     ^~~~~~~~~
xattr.c:1189:1: note: declared here
 1189 | PyInit_xattr(void)
      | ^~~~~~~~~~~~
xattr.c: At top level:
xattr.c:1178:27: error: storage size of ‘xattrmodule’ isn’t known
 1178 | static struct PyModuleDef xattrmodule = {
      |                           ^~~~~~~~~~~
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
lfos commented 4 years ago

This is on an up-to-date Arch Linux machine with Python 3.8.0.

iustin commented 4 years ago

The error message is when building for Python 2.7, but Python 2 is no longer supported in the last version.

What command did you run that triggered a Python 2 build? The makefile doesn't list Python 2 anymore.

iustin commented 4 years ago

Or at least should not, maybe I left it by mistake. Hence good to understand what triggered the Py 2.7 build.

lfos commented 4 years ago

We explicitly build both Python 2 and Python 3 versions of the package. I did not realize that Python 2 support was dropped. My mistake. The timing is a little bit unfortunate, though, since there are some quite popular applications that depend on pyxattr and still do not support Python 3 in any stable release. This essentially prevents us from upgrading pyxattr to the most recent release at Arch Linux. I guess other distributions will be affected too, unless there are new stable releases of bup and rdiff-backup with Python 3 support soon.

lfos commented 4 years ago

Also, it is quite surprising to see this breaking change happening in a minor release. A bigger version jump would have been justified, I guess.

lfos commented 4 years ago

I guess this can be closed, though. Thank you for your help!

iustin commented 4 years ago

We explicitly build both Python 2 and Python 3 versions of the package. I did not realize that Python 2 support was dropped. My mistake.

I see, no problem.

The timing is a little bit unfortunate, though, since there are some quite popular applications that depend on pyxattr and still do not support Python 3 in any stable release.

I would hope that in the next 3-5, at most 6 months, any that are still actually maintained will get one. After all, Python 2 is EOL in 2 weeks upstream.

This essentially prevents us from upgrading pyxattr to the most recent release at Arch Linux.

Note that there are no significant changes besides moving to cleaner code thanks to the Py3-only code; there is a very small fix in case memory allocation fails when creating a list.

I guess other distributions will be affected too, unless there are new stable releases of bup and rdiff-backup with Python 3 support soon.

Yes, I'm not uploading the new version to Debian either for now.

Also, it is quite surprising to see this breaking change happening in a minor release. A bigger version jump would have been justified, I guess.

Yes, you are right, I should have moved to 1.0.0, but the ship has now sailed. Do you think it would be worth re-releasing the Py2 version as 0.8, and a 1.0 with Python 3 only?

lfos commented 4 years ago

Personally, I don't see much benefit in rereleasing things but it might help prevent more confusion.

iustin commented 3 years ago

I'll just release 0.8 as bigger version bump, and call this "done".

iustin commented 3 years ago

Actually, "0.7" was the one that introduced py3-only, not 0.7.1. Sigh, I think I'll just leave things as they are right now…