[issue3581] failures in test_uuid

devurandom added the comment: > Well, without a valid MAC address the function cannot work... It should not break in such ugly way either, imo. > On the other hand, I would not worry too much: > uuid._ifconfig_getnode() is an internal function; and since all the > other tests pass, uuid.getnod

[issue3581] failures in test_uuid

Amaury Forgeot d'Arc added the comment: Well, without a valid MAC address the function cannot work... On the other hand, I would not worry too much: uuid._ifconfig_getnode() is an internal function; and since all the other tests pass, uuid.getnode() probably has other ways to get a unique ide

[issue3581] failures in test_uuid

Karl Johan Kleist added the comment: > /sbin/ifconfig -a | grep -i -e hwaddr -e ether venet0Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -- ___

[issue3581] failures in test_uuid

Amaury Forgeot d'Arc added the comment: hum, maybe an issue with the MAC address of your virtual server? What do you get if you run: ifconfig -a | grep -i -e hwaddr -e ether -- ___ Python tracker __

[issue3581] failures in test_uuid

Karl Johan Kleist added the comment: == CPython 2.7.2 (default, Jul 26 2011, 12:29:47) [GCC 4.2.1 (SUSE Linux)] == Linux-2.6.18-028stab091.2-i686-athlon-with-SuSE-10.3-i586 little-endian == /home/kjk/local/src/Python-2.7.2/build/test_python_18037 Testing with flags: sys.flags(debug=0, py3k_w

[issue3581] failures in test_uuid

Amaury Forgeot d'Arc added the comment: What is the output of this command? ./python -m test.regrtest -v test_uuid -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue3581] failures in test_uuid

Karl Johan Kleist added the comment: If it could be of interest to anybody: When running "make test" after building Python 2.7.2, I get the error message "1 test failed: test_uuid". > uname -a Linux h1488277 2.6.18-028stab091.2 #1 SMP Fri Jun 3 00:02:40 MSD 2011 i686 athlon i386 GNU/Linux T

[issue3581] failures in test_uuid

Stefan Krah added the comment: Applied test_uuid3.patch to trunk (r79954), release26-maint (r79959), py3k (r79960) and release31-maint (r79961). No buildbot failures so far, so I'm closing this. -- stage: commit review -> committed/rejected status: open -> closed versions: +Python 3.1,

[issue3581] failures in test_uuid

Antoine Pitrou added the comment: > Should the patch go into the maintenance branches as well (after the > beta is out)? Yes, I think it would be nice (though not mandatory). -- ___ Python tracker

[issue3581] failures in test_uuid

Changes by Stefan Krah : -- resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue3581] failures in test_uuid

Stefan Krah added the comment: Sorry, the random node id generation in uuid.py is correct. The least significant bit of the first octet (which is set to 1) is the first one transmitted on the network, then the "low 47 random bits" follow. I assumed that the least significant bit of the first oc

[issue3581] failures in test_uuid

Stefan Krah added the comment: I reread http://www.ietf.org/rfc/rfc4122.txt and I'm pretty sure that if getnode() is supposed to return a hardware address, one of the following should be used: 1) If ifconfig etc. returns successfully, we are fine. 2) If uuid_generate_time() or UuidCreateSe

[issue3581] failures in test_uuid

Changes by Antoine Pitrou : -- nosy: +nnorwitz, tim_one ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue3581] failures in test_uuid

Stefan Krah added the comment: I do not understand the semantics of uuid.getnode(). Per the docs it's supposed to return a hardware address. This would reasonably make it a UUID version 1. But then the random fallback should be a 47 bit number as per http://www.ietf.org/rfc/rfc4122.txt section

[issue3581] failures in test_uuid

Stefan Krah added the comment: 5. uuid.getnode() can fall back to creating a random 48 bit number and so can _windll_getnode() (by using UuidCreateSequential). Therefore, in unlucky cases 0x can be generated and the assert in check_node() will fail. check_node() is beginn

[issue3581] failures in test_uuid

Antoine Pitrou added the comment: Ok, I trust you on the investigation. > Could this go into trunk, since the tests actually fail needlessly > on qemu setups? Yes, but after the beta: http://mail.python.org/pipermail/python-dev/2010-April/099132.html -- assignee: -> skrah resolution:

[issue3581] failures in test_uuid

Stefan Krah added the comment: The new patch test_uuid.patch fixes issue 7650, issue 1481 and this one. I've applied it to py3k-cdecimal in r79905 and test_uuid is passed on all buildbots (I did not test on ARM and one FreeBSD bot is still hanging in test_subprocess). Additionally, the patch

[issue3581] failures in test_uuid

Stefan Krah added the comment: According to http://standards.ieee.org/regauth/groupmac/tutorial.html , the assertions in check_node are weeding out perfectly valid addresses: >>> node = 0x525400123456 >>> universal_local_bit = (node >> 40L) & 2 >>> universal_local_bit 2L This just means that t

[issue3581] failures in test_uuid

Stefan Krah added the comment: Confirmed on Windows 7 under qemu with a fresh trunk checkout. -- nosy: +skrah priority: low -> high versions: +Python 2.7 ___ Python tracker ___ _

[issue3581] failures in test_uuid

Changes by Antoine Pitrou : -- assignee: pitrou -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue3581] failures in test_uuid

Antoine Pitrou added the comment: Apparently, a bad test assumption. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue3581] failures in test_uuid

Daniel Diniz added the comment: Hmm, is this a bug in uuid._ifconfig_getnode or just a bad test assumption? -- nosy: +ajaksu2 priority: normal -> low ___ Python tracker ___ _

[issue3581] failures in test_uuid

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- assignee: -> pitrou components: +Tests priority: -> normal type: -> behavior versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> _

[issue3581] failures in test_uuid

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: I get failures in test_uuid when run inside a qemu virtual machine. It is related to the fake MAC address used by qemu. == FAIL: test_ipconfig_getnode (__main__.TestUUID)