| 1 |
I appreciate Fabian looking into the previous problem I reported and |
| 2 |
suggesting a workaround, which sounds like it should probably work. |
| 3 |
However I haven't been able to test it yet, because when I retry the |
| 4 |
bootstrap, a new problem arises earlier in the bootstrap process, on |
| 5 |
ca-certificates. It's not so clear to me in this case what the real |
| 6 |
problem is, including that I haven't found what might have changed |
| 7 |
recently to trigger it. So I'd be interested if anyone has any |
| 8 |
insights. |
| 9 |
|
| 10 |
As I understand it, ca-certificates's "src_compile" phase uses a |
| 11 |
Python script certdata2pem.py in the upstream package in order to |
| 12 |
convert the certificate information into the appropriate format to |
| 13 |
install. Because of this, it comes after python-3.5.5 in the |
| 14 |
dependency order, and the ebuild checks to see that an appropriate |
| 15 |
Python version is available. In the bootstrap I did on Monday, this |
| 16 |
seemed to work correctly. But when I tried again yesterday and today, |
| 17 |
there was a failure in the process of detecting the installed Python |
| 18 |
version. It looks like the key error message is: |
| 19 |
|
| 20 |
ERROR: This version of portageq only supports <eroot>s ending in |
| 21 |
'/scratch/heathrow/mccamant-public/gentoo-prefix-64-may2018'. The provided <eroot>, |
| 22 |
'/scratch/heathrow/mccamant-public/gentoo-prefix-64-may2018/tmp', doesn't. |
| 23 |
* ERROR: app-misc/ca-certificates-20180409.3.37::gentoo failed |
| 24 |
(compile phase): |
| 25 |
* has_version: unexpected portageq exit code: 64 |
| 26 |
* |
| 27 |
* Call stack: |
| 28 |
* ebuild.sh, line 124: Called src_compile |
| 29 |
* environment, line 3035: Called python_setup |
| 30 |
* environment, line 2908: Called _python_EPYTHON_supported 'python3.5' |
| 31 |
* environment, line 338: Called python_is_installed 'python3_5' |
| 32 |
* environment, line 2762: Called has_version '--host-root' |
| 33 |
'dev-lang/python:3.5' |
| 34 |
* phase-helpers.sh, line 882: Called die |
| 35 |
|
| 36 |
I see the same error message from portageq if I manually rerun a |
| 37 |
similar command: |
| 38 |
|
| 39 |
% $PREFIX/tmp/usr/bin/portageq has_version \ |
| 40 |
/scratch/heathrow/mccamant-public/gentoo-prefix-64-may2018 \ |
| 41 |
dev-lang/python:3.5 |
| 42 |
ERROR: This version of portageq only supports <eroot>s ending in |
| 43 |
'/scratch/heathrow/mccamant-public/gentoo-prefix-64-may2018/tmp'. The |
| 44 |
provided <eroot>, |
| 45 |
'/scratch/heathrow/mccamant-public/gentoo-prefix-64-may2018', doesn't. |
| 46 |
|
| 47 |
If I add "/tmp" to the end of the eroot argument, the script returns 1 |
| 48 |
(not present). That seems correct, because there is indeed no |
| 49 |
python3.5 in $PREFIX/tmp, only in $PREFIX. |
| 50 |
|
| 51 |
$PREFIX/tmp has python2.7, which seems like it would be sufficient if |
| 52 |
I'm reading the PYTHON_COMPAT variable in the ca-certifcates ebuild |
| 53 |
file correctly. If this is working like a cross-compile, maybe that's |
| 54 |
the one we would want to use, if $PREFIX/tmp is the host and $PREFIX |
| 55 |
is the target. |
| 56 |
|
| 57 |
As I understand it, $PREFIX/tmp is the place where the special version |
| 58 |
of the Portage tools installed in stage1 goes. This version of Portage |
| 59 |
is still in use at this part of stage3, since it's not until later in |
| 60 |
stage3 that Portage is rebuilt. But at this point we are building |
| 61 |
packages that will be installed into the real Prefix environment, not |
| 62 |
temporary bootstrapping versions. So on one level it makes sense that |
| 63 |
the temporary portageq would complain when you ask about a the |
| 64 |
presence of a package in a different root. However this seems like the |
| 65 |
kind of difference that must be dealt with in lots of places to make |
| 66 |
the bootstrapping approach work, so I guess the real mystery is why it |
| 67 |
has recently started failing here. There's some fairly complex |
| 68 |
machinery in the levels of the backtrace between python_setup and the |
| 69 |
shell out to portageq that isn't very transparent to me, so maybe it |
| 70 |
used to take a different code path that avoided this problem. |
| 71 |
|
| 72 |
The general setting here, as before, is an x86_64 Ubuntu 16.04 host |
| 73 |
system which has a bunch of packages of its own installed. I've |
| 74 |
attached the "emerge --info" output and the tail of the stage3.log. |
| 75 |
|
| 76 |
The version of ca-certificates recently increased from 3.36.1 to 3.37, |
| 77 |
but that doesn't look to me like it's relevant because a bootstrap |
| 78 |
yesterday failed with 3.36.1, and one today failed with 3.37. |
| 79 |
|
| 80 |
Thanks, |
| 81 |
|
| 82 |
-- Stephen |
Archives