Skip to contentSkip to conversation

python-psutil: bump to version 4.3.1

PATCH New Peter Korsgaard 2 participants 9 messages Sep 20, 2016

lore
Share & tools
lore

Peter Korsgaard

author
#0 lore raw

PATCH 1/2 python-psutil: bump to version 4.3.1

Signed-off-by Peter Korsgaard <[email protected]>
---
 package/python-psutil/python-psutil.hash | 4 ++--
 package/python-psutil/python-psutil.mk   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
package/python-psutil/python-psutil.hash +2 -2
index 007b7c5..ead2d9c 100644
@@ -1,3 +1,3 @@
 # md5 from https://pypi.python.org/pypi/psutil/json, sha256 locally computed
-md5	ca97cf5f09c07b075a12a68b9d44a67d  psutil-4.3.0.tar.gz
-sha256  86197ae5978f216d33bfff4383d5cc0b80f079d09cf45a2a406d1abb5d0299f0  psutil-4.3.0.tar.gz
+md5	199a366dba829c88bddaf5b41d19ddc0  psutil-4.3.1.tar.gz
+sha256  38f74182fb9e15cafd0cdf0821098a95cc17301807aed25634a18b66537ba51b  psutil-4.3.1.tar.gz
package/python-psutil/python-psutil.mk +2 -2
index 85882ad..1032318 100644
@@ -4,9 +4,9 @@
 #
 ################################################################################
 
-PYTHON_PSUTIL_VERSION = 4.3.0
+PYTHON_PSUTIL_VERSION = 4.3.1
 PYTHON_PSUTIL_SOURCE = psutil-$(PYTHON_PSUTIL_VERSION).tar.gz
-PYTHON_PSUTIL_SITE = https://pypi.python.org/packages/22/a8/6ab3f0b3b74a36104785808ec874d24203c6a511ffd2732dd215cf32d689
+PYTHON_PSUTIL_SITE = https://pypi.python.org/packages/78/cc/f267a1371f229bf16db6a4e604428c3b032b823b83155bd33cef45e49a53
 PYTHON_PSUTIL_SETUP_TYPE = setuptools
 PYTHON_PSUTIL_LICENSE = BSD-3c
 PYTHON_PSUTIL_LICENSE_FILES = LICENSE
Signature · 1 line
2.9.3
author
#2 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

In reply to Peter Korsgaard

Fixes:
http://autobuild.buildroot.net/results/365/365c2f0b32ae3cb1d6d4d8f0145500dfadd05c59/
http://autobuild.buildroot.org/results/140/140d0ec9d94f75453c4c82e18803c8d7bffcf6be/

And many more.

The sysinfo structure definition in linux/sysinfo.h (which gets indirectly included from linux/kernel.h) conflicts with the definition in sys/sysinfo.h when building against the musl C library, leading to build failures:

arm-linux-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes \
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -DPSUTIL_VERSION=430 \
-c psutil/_psutil_linux.c -o build/temp.linux-x86_64-3.5/psutil/_psutil_linux.o
In file included from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/kernel.h:4:0,

                 from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/ethtool.h:16,
                 from psutil/_psutil_linux.c:35:
/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/sysinfo.h:7:8: error: redefinition of 'struct sysinfo'
 struct sysinfo {
        ^

In file included from psutil/_psutil_linux.c:21:0:
/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here

We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so hack around it by ensuring the content of linux/sysinfo.h doesn't get expanded when building against musl.

We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h definition. Musl provides no detection define, so instead detect that we are NOT on glibc/uClibc.

Signed-off-by Peter Korsgaard <[email protected]>
---
 .../0001-fix-build-against-musl-C-library.patch    | 63 ++++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 package/python-psutil/0001-fix-build-against-musl-C-library.patch
package/python-psutil/0001-fix-build-against-musl-C-library.patch new file +63 -0
new file mode 100644
index 0000000..0ef994d
@@ -0,0 +1,63 @@
+From d08ba65306c7f9ac9c0590cfe313d3ce0f8873be Mon Sep 17 00:00:00 2001
+From: Peter Korsgaard <[email protected]>
+Date: Mon, 19 Sep 2016 23:41:54 +0200
+Subject: [PATCH] fix build against musl C library
+
+The sysinfo structure definition in linux/sysinfo.h (which gets indirectly
+included from linux/kernel.h) conflicts with the definition in sys/sysinfo.h
+when building against the musl C library, leading to build failures:
+
+http://autobuild.buildroot.net/results/365/365c2f0b32ae3cb1d6d4d8f0145500dfadd05c59/build-end.log
+
+arm-linux-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes \
+ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -DPSUTIL_VERSION=430 \
+  -c psutil/_psutil_linux.c -o build/temp.linux-x86_64-3.5/psutil/_psutil_linux.o
+In file included from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/kernel.h:4:0,
+                 from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/ethtool.h:16,
+                 from psutil/_psutil_linux.c:35:
+/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/sysinfo.h:7:8: error: redefinition of 'struct sysinfo'
+ struct sysinfo {
+        ^
+In file included from psutil/_psutil_linux.c:21:0:
+/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here
+
+We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so
+hack around it by ensuring the content of linux/sysinfo.h doesn't get
+expanded when building against musl.
+
+We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h
+definition. Musl provides no detection define, so instead detect that we
+are NOT on glibc/uClibc.
+
+Signed-off-by: Peter Korsgaard <[email protected]>
+---
+ psutil/_psutil_linux.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/psutil/_psutil_linux.c b/psutil/_psutil_linux.c
+index 19fd14b..fa7617a 100644
+--- a/psutil/_psutil_linux.c
++++ b/psutil/_psutil_linux.c
+@@ -16,6 +16,19 @@
+ #include <features.h>
+ #include <utmp.h>
+ #include <sched.h>
++
++#ifndef __GLIBC__
++/*
++ * linux/sysinfo.h (which gets indirectly included by other kernel headers)
++ * conflicts with sys/sysinfo.h on musl, so make sure it doesn't get expanded.
++ * We cannot do this unconditionally as E.G. glibc/uClibc rely on the
++ * linux/sysinfo.h definition.
++ * Musl provides no detection define, so instead detect that we are
++ * NOT on glibc/uClibc.
++ */
++#define _LINUX_SYSINFO_H
++#endif
++
+ #include <linux/version.h>
+ #include <sys/syscall.h>
+ #include <sys/sysinfo.h>
+-- 
+2.9.3
+
Signature · 1 line
2.9.3
#3 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Hello,

Quoted 7 lines · Peter Korsgaard

We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so hack around it by ensuring the content of linux/sysinfo.h doesn't get expanded when building against musl.

We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h definition. Musl provides no detection define, so instead detect that we are NOT on glibc/uClibc.

This is not really the solution recommended by the musl developers. Instead, the musl developers would suggest to *not* include <linux/sysinfo.h> at all, and instead duplicate the relevant definitions in the userspace program.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#4 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 4 lines · Peter Korsgaard

We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so hack around it by ensuring the content of linux/sysinfo.h doesn't get expanded when building against musl.

Quoted 8 lines
Quoted 3 lines

We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h definition. Musl provides no detection define, so instead detect that we are NOT on glibc/uClibc.

This is not really the solution recommended by the musl developers. Instead, the musl developers would suggest to *not* include <linux/sysinfo.h> at all, and instead duplicate the relevant definitions in the userspace program.

Yes, I know it is a hack (as mentioned in the description). The problem is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h.

Do you have any suggestion how to fix this in a cleaner way?

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
#5 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Hello,

Quoted 10 lines · Peter Korsgaard
Quoted 4 lines

This is not really the solution recommended by the musl developers. Instead, the musl developers would suggest to *not* include <linux/sysinfo.h> at all, and instead duplicate the relevant definitions in the userspace program.

Yes, I know it is a hack (as mentioned in the description). The problem is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h.

Do you have any suggestion how to fix this in a cleaner way?

The answer of the musl developers would be: don't include <linux/ethtool.h> in the first place.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#6 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 5 lines · Peter Korsgaard
Quoted 4 lines

This is not really the solution recommended by the musl developers. Instead, the musl developers would suggest to *not* include <linux/sysinfo.h> at all, and instead duplicate the relevant definitions in the userspace program.

Quoted 8 lines
Quoted 5 lines

Yes, I know it is a hack (as mentioned in the description). The problem is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h.

Do you have any suggestion how to fix this in a cleaner way?

The answer of the musl developers would be: don't include <linux/ethtool.h> in the first place.

I don't see the point of that reasoning - The whole idea of the Linux uapi headers is to provide headers for the kernel API.

I'm not particulary interested in musl support for python-psutil. Alternatively we can just mark it as !BR2_TOOLCHAIN_USES_MUSL.

What do you suggest?

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
#7 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Hello,

Adding Rich from musl in Cc.

Quoted 5 lines · Peter Korsgaard
Quoted 2 lines

The answer of the musl developers would be: don't include <linux/ethtool.h> in the first place.

I don't see the point of that reasoning - The whole idea of the Linux uapi headers is to provide headers for the kernel API.

Correct. I've already discussed this with the musl developers, and they say that the "kernel headers are not clean to be used in userspace".

Of course, everyone else but the musl people are using the uapi headers in userspace, but apparently, there are some things in there that do not please the musl people.

Maybe Rich can explain more precisely the issue. So far I've only been able to get "kernel headers are not clean enough", but not concrete example of the problem.

Quoted 5 lines

I'm not particulary interested in musl support for python-psutil. Alternatively we can just mark it as !BR2_TOOLCHAIN_USES_MUSL.

What do you suggest?

I don't care about python-psutil to be available with musl, so your proposal is fine to me. Overall, I find the policy of musl developers to be very annoying as:

1/ It breaks many many many packages.

2/ The only proposed solution is to duplicate code, which is not nice
at all, and is difficult to get accepted by upstream project, living us with zillions of musl-related patches that we cannot upstream.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#8 lore raw

PATCH 2/2 python-psutil: fix build against musl C library

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 6 lines
Quoted 2 lines

I don't see the point of that reasoning - The whole idea of the Linux uapi headers is to provide headers for the kernel API.

Correct. I've already discussed this with the musl developers, and they say that the "kernel headers are not clean to be used in userspace".

Quoted 7 lines

Of course, everyone else but the musl people are using the uapi headers in userspace, but apparently, there are some things in there that do not please the musl people.

Maybe Rich can explain more precisely the issue. So far I've only been able to get "kernel headers are not clean enough", but not concrete example of the problem.

Rich, can you explain please?

Quoted 10 lines
Quoted 5 lines

I'm not particulary interested in musl support for python-psutil. Alternatively we can just mark it as !BR2_TOOLCHAIN_USES_MUSL.

What do you suggest?

I don't care about python-psutil to be available with musl, so your proposal is fine to me. Overall, I find the policy of musl developers to be very annoying as:

Quoted 6 lines

1/ It breaks many many many packages.

2/ The only proposed solution is to duplicate code, which is not nice
at all, and is difficult to get accepted by upstream project, living us with zillions of musl-related patches that we cannot upstream.

Agreed. I've send a patch to mark it (and its reverse dependencies) as unavailable on musl.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard