Created attachment 366088 [details] emerge --info Missing CAN_RAW check in Python 3.3.3 Python 3.3.3 assumes that if AF_CAN is defined then CAN_RAW is defined as well. It won't assemble with the old kernels. Either an additional check for CAN_RAW should be applied in the configuration script or Python 3.3.3 dependence on the newest kernels should be made mandatory. Python 3.3.3 can work with sockets without full CAN support but it won't.
*** This bug has been marked as a duplicate of bug 495002 ***
(In reply to Jeroen Roovers from comment #1) > > *** This bug has been marked as a duplicate of bug 495002 *** I've updated the system as you sggested to find out the cause. And the problem is not in the old glbic or compliers (see nee emrge --info), it's with the kernel headers. It's a bug that was introduced in Python 3.3.* According to: socket.rst .. function:: socket([family[, type[, proto]]]) Create a new socket using the given address family, socket type and protocol number. The address family should be :const:`AF_INET` (the default), :const:`AF_INET6`, :const:`AF_UNIX`, :const:`AF_CAN` or :const:`AF_RDS`. The socket type should be :const:`SOCK_STREAM` (the default), :const:`SOCK_DGRAM`, :const:`SOCK_RAW` or perhaps one of the other ``SOCK_`` constants. The protocol number is usually zero and may be omitted in that case or :const:`CAN_RAW` in case the address family is :const:`AF_CAN`. .. versionchanged:: 3.3 The AF_CAN family was added. The AF_RDS family was added. There should be an additonal ceck for CAN_RAW presence to exclude the problematic part of code because it's CAN_RAW is not necessary for Python 3.3.3 to work. It can work without it but the configure script doesn't know about it. I'm not sure why it's marked as Invalid, because apprently this is a bug in Python 3.3.3 configure script that doesn't exclude AF_CAN part of the socket.c or may be there is a bug in ebuild itself.
(In reply to Igor Franchuk from comment #2) > > *** This bug has been marked as a duplicate of bug 495002 *** > > I've updated the system as you sggested to find out the cause. And the > problem is not in the old glbic or compliers (see nee emrge --info), it's > with the kernel headers. Yes, it's in the headers and consequently in libc. You couldn't reasonably expect the Python developers to check their work against a libc compiled against headers that were current more than 6 years ago. Similarly, Gentoo maintainers of packages should not be required to go back six years and set dependencies accordingly, and indeed they are by the Council's decree only required to support system states of around 1 year ago. That's why this bug is a duplicate of bug #495002 and it's why bug #495002 is INVALID (WONTFIX would have been an equally good choice of resolution).
> Yes, it's in the headers and consequently in libc. You couldn't reasonably > expect the Python developers to check their work against a libc compiled > against headers that were current more than 6 years ago. True and I have no complains. I just report a bug to improve Python because obisously there is no rason Python 3.3.3 won't work with the old kernels other than a bug in configure script. Isn't it the way the open software works - by contribution of the community? > Similarly, Gentoo maintainers of packages should not be required to go back > six years and set dependencies accordingly, and indeed they are by the > Council's decree only required to support system states of around 1 year ago. > That's why this bug is a duplicate of bug #495002 and it's why bug #495002 > is INVALID (WONTFIX would have been an equally good choice of resolution). OK, I filed a bug to Python developers, it's their configure script anyway. Recently I noticed many dependency problems with portage on many systems new and old. If earlier the cases when a build won't assemble because of the missing/wrong dependency was rare now it happens everywhere and everytime. In my point of view the most important thing missing with portage is the feedback. It's a common problem for many devloper groups - they run or hide from the problems while knowing the problem is almost the same as fixing it and knowing the problem is their best friend. As a gentoo friend I don't wont it to die. What I suggest while it's not too late to implement in a new portage an automated feedback on failed ebuilds. Then you can analyze ebuilds by quering the failed database and fix problems with the most common ones transparently before they're reported. And there would be no need to spend time on reporting the probles and answering questions. You spend too much time and human resources on this tracker while the it's efficiency is questionable. The second step - you may introduce a system that will analyze the failed feedback database and post the reports in this tracker automatically to avoid reporting dups with users. Then a large part of the team could foucs on really solving problem and not on writng messages. I could contribute a database feedback box and protocol that receives and stores the failed builds. In 1-2 years gentoo will be the most reliable system ever and no human resources would be spent.
How did the upstream report go? Can we have a link to it? (PS: Note that VERIFIED is a QA reserved status per its documentation.)
Arfrever says this will be fixed in Python 3.3.5.
(In reply to Tom Wijsman (TomWij) from comment #5) > How did the upstream report go? Can we have a link to it? > > (PS: Note that VERIFIED is a QA reserved status per its documentation.) To which documentation are you referring?
(In reply to Michael Palimaka (kensington) from comment #7) > (In reply to Tom Wijsman (TomWij) from comment #5) > > How did the upstream report go? Can we have a link to it? > > > > (PS: Note that VERIFIED is a QA reserved status per its documentation.) > > To which documentation are you referring? Apparently [1] but do note that Tom is new here and still takes everything at face value / as set in stone. [1] https://bugs.gentoo.org/page.cgi?id=fields.html#bug_status
