UUID Module - FreeBSD build failure #76674
Comments
|
UUID module build fails on FreeBSD since it supports uuid_create function. |
|
The AIX-specific code was contributed by Michael Felt in bpo-32399. |
|
Michael, does AIX have uint32_t? If so, we could happily drop the unsigned32 reference. |
|
On 05/01/2018 13:38, Antoine Pitrou wrote:
Yes, AIX has unit32_t. michael@x071:[/home/michael]grep unsigned32 /usr/include/.h
|
|
Seems to be in inttypes.h: |
|
Perfect. That solves in the process OpenBSD uuid module build too. |
|
On 08/01/2018 12:47, David Carlier wrote:
|
|
I guessed that :-) I trusted it worked just fine for you. To be honest I know nearly nothing about AIX specificities :-) |
|
Thank you for the fix David! |
This change introduced a regression on AMD64 FreeBSD 10.x Shared 3.x: http://buildbot.python.org/all/#/builders/87/builds/463 ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_uuid.py", line 320, in test_uuid1
equal(u.version, 1)
AssertionError: 14 != 1 |
|
Might comes from uuid1 function itself ... e.g. line 704 not setting version "field". |
|
Actually, the libc/libuuid function called should be setting the version/variant values as well. So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_generate() function is wrong (if that is what it is using - was it/can it also use the uuid_generate* routines? FYI: I notice the AIX include file does not actually define the bits for RFC_4122, etc.., but the include file comments does show that the implementation is taking them into account. /** The strlen() of a UUID string (does not include terminating null) */
#define UUID_STRLEN 36
/**
* Constant value indicating an as-yet undetermined UUID for a thing. Spells \c
* "\0\0UUID\x10_\x80UNKNOWN" in ASCII. Zeroes at the top make it very unlikely
* to collide with a uuid_create()d value, which puts a timestamp in that spot.
* The \c "\x10" and \c "\x80" are reserved/version/mask bits that make this
* conform to the format expected by the uuid.h API.
*/
#define UUID_UNKNOWN (uuid_t){0x00005555, 0x4944, 0x105F, 0x80, 0x55, {0x4E, 0x4B, 0x4E, 0x4F, 0x57, 0x4E}}
#define UUID_UNKNOWN_STR "00005555-4944-105f-8055-4e4b4e4f574e"I wrote a simple program to examine uuid for myself. Maybe - if you ran a loop (looking at uuid1().variant and uuid1().version you could see if there is an incorrect version showing up. Rather than python - that would seem to be a library function error. My very simple program: cat -n ../x4.py |
|
typo here: So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_create() function is wrong (if that is what it is using - was it/can it also use the uuid_generate* routines? i.e., does AMD FreeBSD use uuid_create() or uuid_generate() - or can it use both? Could someone with AMD try: +12 static PyObject * |
|
uuid_create only I think. |
|
Gives same outcome but maybe someone else can confir, |
|
On 1/17/2018 11:16 AM, David CARLIER wrote:
Taking a hint from the FreeBSD man page for uuid_create() - that says it Therein: The timestamp is a 60 bit value. For UUID version 1, this is represented The version number is multiplexed in the 4 most significant bits of the Again - a random number is not likely to correctly set the 4 most significant bits - so another way is needed to make an instance it is version 4.
|
|
In OpenBSD it s even "worse", the version for each call is random (not a surprise when looking at the source). The question is, do we go back to support only AIX or do we accept somehow wrong version ? |
|
Now that it is visible - maybe OpenBSD will treat it as a bug and get STANDARDS <https://man.openbsd.org/uuid.3#STANDARDS\> The *uuid_compare*(), *uuid_create*(), *uuid_create_nil*(), The FreeBSD man page *NAME* <https://www.freebsd.org/cgi/man.cgi?query=uuid_create#end\> Re the DCE 1.1 RPC implementation/description - I found this link: And this comment: The version number is multiplexed in the 4 most significant bits of the *msb1* *msb2* *msb3* *msb4* *Version* *Description* So, maybe either, or both: OpenBSD and FreeBSD fix their implementation. On 1/23/2018 3:34 PM, David CARLIER wrote:
|
|
Probably. Seems workable under Apple otherwise. |
|
We are still seeing the 3.7 and 3.8 FreeBSD buildbot failures Victor identified in msg310147. Can someone please take this on and produce a PR? |
|
If it is a bug in OpenBSD how do you propose we "fix" this. imho, the problem is "outside" python. however, until it is fixed in openbsd, would you accept an 3error macro that prevents the mod from being built on the specific version of openbsd that fails? |
|
oops, sain openbsd, should be freebsd |
|
This problem is still unresolved and causing buildbot failures. It really should be fixed before we tag 3.7.0rc1. Serhiy, could you take a look at it, please? Thanks! http://buildbot.python.org/all/#/builders/87/builds/1014/steps/4/logs/stdio |
|
I will be busy next few hours, but will take this issue as soon as I can. However I do not promise the result. |
|
Is AIX big-endian? On *BSD systems uuid_t is a structure of integers with platform-depending endianess. Thus on little-endian platform UUID should be called with the bytes_le argument. This doesn't fix test on OpenBSD and NetBSD, but at least the result is stable (version=4). Using bytes_le on Linux breaks tests. Seems uuid_generate_time_safe() always returns bytes in big-endian order. PR 7098 adds _uuid.little_endian which is true on little-endian platforms using uuid_create(), and false otherwise. Actually there are many ways of solving this problem, the choice of this design was arbitrary. _uuid.generate_time_safe() could return a 3-tuple instead of 2-tuple, or there could be two separate functions: _uuid.generate_time_safe() and _uuid.create(). |
|
PR 7099 is an alternate solution. I uses uuid_enc_be() which is not part of the DCE 1.1 RPC specification but exists on all *BSD. Both solutions gives the same result on *BSD and AIX. I have no idea what solution is appropriate for little-endian non-BSD platform (if there is such platform supporting uuid_create()). |
|
Thank you Serhiy Storchaka for the fix! If someone cares about AIX, please open a different issue. (AIX has other more important functions that you be fixed, IHMO.) |
The title of this issue makes it very specific to FreeBSD, so it would be better to create a new one for AIX. What your write for the commit description is not appropriate for a commit, but it's fine for the description of a bug. Please open a new issue to track uuid changes for AIX. I know that you have a second one for Python <= 3.6. |
|
OK. I know I do not understand this well - when it goes in A, or B. So, if I understand correctly, like this issue was created after Seems like a lot of work. I only put it here because it is a very simple Just verify that is what you want and I'll get to it as I can. In any On 6/8/2018 12:48 AM, STINNER Victor wrote:
|
Thanks you Ned and Michael. Sorry for the confusion. I was first confused that the fix for master added a lot of code using ctypes. The final fix is the right fix for 3.7 and master ;-) Michael: if you want to fix uuid on 3.6, I would suggest to open a new issue, because it seems that the fix is much more complex and unrelated to _uuid (module added to Python 3.7). |
|
I was not aware that _uuid was new to python3-3.7. I thought it had been around for a long time. Bpo-28009 goes back two years and i was unaware of uuid_create(). Would it be easier to split it into 3 issues? One for unixdll, one for netstat, and one for test_uuid? Michael Sent from my iPhone
|
One issue for AIX should be enough. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: