[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-03-03 Thread Charles-François Natali
Charles-François Natali added the comment: Alright, closing. -- resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15448

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Bohuslav Slavek Kabrda
Bohuslav Slavek Kabrda added the comment: I have a similar problem with python 3.3.0. During installation, I get snip running install_lib creating /builddir/build/BUILDROOT/python33-python-3.3.0-3.el6.i386/opt/rh/python33/root/usr/lib/python3.3/lib-dynload copying

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Charles-François Natali
Charles-François Natali added the comment: There are actually two distinct issues. For the first one, the problem is really a distribution issue: the libc is more recent than the kernel, and exports *utimes() whereas the kernel doesn't implement those syscalls, which results in ENOSYS. I

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Bohuslav Slavek Kabrda
Bohuslav Slavek Kabrda added the comment: Ouch, the problem was in fact on my side. I was building python inside a mock [1] chroot that had different version of headers than the actual kernel. When I figured this out and made the versions the same, everything passed perfectly. Sorry for the

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2012-07-25 Thread Richard Moseley
New submission from Richard Moseley dickie.mose...@virgin.net: When building on a ASUS Eee PC 1000 running the original Xandros O/S with libc-2.7-13, the various utimes() functions are being detected as available for use, everything compiles. However, during installation of the lib-dynload