cc @zanieb

@zanieb Does it actually solve your issue? because my system also appears to be unable to get the MAC address... but I was offline (I work offline during the week in general) and I didn't check when I'm online.

It's kind of hard to test because I haven't added support for the latest 3.14 in python-build-standalone and the patch doesn't apply cleanly to 3.13.

Okay, the patch does apply cleanly to the previous 3.14 alpha so I can test this. On macOS, it does resolve the problem. I did not test Linux.

I tested a Linux build at astral-sh/python-build-standalone#595 (comment) and it didn't seem to work.

Hum. It's very strange. Did I mess the configure script? what's the value of HAVE_UUID_GENERATE_TIME_SAFE_STABLE_MAC?

Looking at the logs... "HAVE_UUID_GENERATE_TIME_SAFE_STABLE_MAC": "0",

... so it's not _unix_node() that is being called?

The builds are attached there if you want to hop into a debugger.

Briefly... yeah it looks like it's called and we try each getter until we reach the random one:

(Pdb) getter
<function _unix_getnode at 0xffffb77b74d0>
(Pdb) s
--Call--
> /python/install/lib/python3.14/uuid.py(634)_unix_getnode()
-> def _unix_getnode():
(Pdb) n
> /python/install/lib/python3.14/uuid.py(636)_unix_getnode()
-> if _generate_time_safe and _has_stable_extractable_node:
(Pdb) n
--Return--
> /python/install/lib/python3.14/uuid.py(636)_unix_getnode()->None
-> if _generate_time_safe and _has_stable_extractable_node:
(Pdb) n
> /python/install/lib/python3.14/uuid.py(706)getnode()
-> if (_node is not None) and (0 <= _node < (1 << 48)):
(Pdb) l
701  	   for getter in _GETTERS + [_random_getnode]:
702  	       try:
703  	           _node = getter()
704  	       except:
705  	           continue
706  ->	       if (_node is not None) and (0 <= _node < (1 << 48)):
707  	           return _node
708  	   assert False, '_random_getnode() returned invalid value: {}'.format(_node)
709  	
710  	
711  	_last_timestamp = None
(Pdb) n
> /python/install/lib/python3.14/uuid.py(701)getnode()
-> for getter in _GETTERS + [_random_getnode]:
(Pdb) n
> /python/install/lib/python3.14/uuid.py(702)getnode()
-> try:
(Pdb) getter
<function _ip_getnode at 0xffffb77b71d0>
(Pdb) n
> /python/install/lib/python3.14/uuid.py(703)getnode()
-> _node = getter()
(Pdb) n
> /python/install/lib/python3.14/uuid.py(706)getnode()
-> if (_node is not None) and (0 <= _node < (1 << 48)):
(Pdb) _node
(Pdb) n
> /python/install/lib/python3.14/uuid.py(701)getnode()
-> for getter in _GETTERS + [_random_getnode]:
(Pdb) n
> /python/install/lib/python3.14/uuid.py(702)getnode()
-> try:
(Pdb) getter
<function _ifconfig_getnode at 0xffffb77b7110>
(Pdb) n
> /python/install/lib/python3.14/uuid.py(703)getnode()
-> _node = getter()
(Pdb) n
> /python/install/lib/python3.14/uuid.py(706)getnode()
-> if (_node is not None) and (0 <= _node < (1 << 48)):
(Pdb) _node
(Pdb) n
> /python/install/lib/python3.14/uuid.py(701)getnode()
-> for getter in _GETTERS + [_random_getnode]:
(Pdb) n
> /python/install/lib/python3.14/uuid.py(702)getnode()
-> try:
(Pdb) getter
<function _random_getnode at 0xffffb77b7650>
(Pdb) n
> /python/install/lib/python3.14/uuid.py(703)getnode()
-> _node = getter()
(Pdb) n
> /python/install/lib/python3.14/uuid.py(706)getnode()
-> if (_node is not None) and (0 <= _node < (1 << 48)):
(Pdb) _node
23292345252342

So, the patch worked but it turns out generate_time_safe is necessary for MAC address retrieval on (at least) ubuntu:latest?

Maybe we should add all possible getnode fallbacks based on ifconfig, ip, arp, netstat, lanscan?

We did try _ip_getnode and _ifconfig_getnode as expected there. I didn't look into why those might fail. It does feel like a bit of a separate concern than this patch.

I suggest adding a print in the except: continue as well just in case and also print the output of the invoked command to see whether we need to upgrade how the output is being parsed.

Those commands are just not installed by default in the ubuntu image. If you apt-get install net-tools, the getnode result is static.

Ha! so that's why. Let's also fix this by adding them as a dependency then

🤖 New build scheduled with the buildbot fleet by @picnixz for commit 16200ae 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F132901%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

@hugovk friendly ping

This is a bug fix, so it should technically be backported up to 3.13. But I'm not confident in this bugfix because there is still a change of behavior, and maybe it could have more impact than what I think.

The bug is however really hard to spot as it's only between different interpreters that it would appear. Within the same process, it wouldn't appear. Do you think it's better to merge this one for 3.14 and 3.15 but hold a few beta releases until merging it into 3.13?

Do you think it's better to merge this one for 3.14 and 3.15 but hold a few beta releases until merging it into 3.13?

Can do. The next 3.13 is scheduled for 2025-06-03. After that is 2025-08-05, by which time we'll have had all three remaining 3.14 betas and one RC.

🤖 New build scheduled with the buildbot fleet by @picnixz for commit fd84b3c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F132901%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

Note: the buildbot failures are unrelated so I'll ignore them.

Hum, is our backport bot sick? it didn't make an automatic backport, so I'll do it for 3.14

Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

Sorry, @picnixz, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 3bffada46728e51f84c41ecbb0d3722595693e63 3.13

huh... ok I'll make the manual bp, add a DO-NOT-MERGE and so that we don't forget it

GH-134704 is a backport of this pull request to the 3.13 branch.