
Hi Stephen,
On 8 June 2018 at 00:02, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 16 May 2018 at 12:57, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 16 May 2018 at 09:55, Stephen Warren swarren@wwwdotorg.org wrote:
On 05/16/2018 01:10 AM, Simon Glass wrote:
The redirection seems to cause this test to fail now. It isn't needed, so drop it.
I guess I have no particular objection to this, but I will point out that the test is working just fine as-is right now, so it might be worth investigating more re: what the error is and why it's happening... It'd be good to describe the details of the failure in the commit description too.
So the test works OK for you? For me it fails. I'll update the commit message.
# Store the output so it can be accessed if we raise an exception. self.output = output self.exit_status = exit_status if exception:
raise exception
E Exception: Exit code: 1
test/py/multiplexed_log.py:173: Exception
--------------------------------------- Captured stdout call
+openssl genpkey -algorithm RSA -out /usr/local/google/home/sjg/cosarm/src/third_party/u-boot/files/build-sandbox/dev.key -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537 2>/dev/null genpkey: Use -help for summary. Exit code: 1
From Stephen:
Yes. I just double-checked and it's definitely running in Jenkins for me; not being skipped or anything. It's running on Denx u-boot.git, u-boot-dm.git and a slew of others too. I assume it's running on Travis CI without issue too.
I'm running Ubuntu 16.04 right now, but only recently upgraded from 14.04 where I believe the test was running without issue too. Is this issue OS-specific or Python-version-specific (I have 2.7.12)?
I am really not sure what is going on...I can definitely repeat this but only on my workstation, not my laptop.
I will see if I can dig into it further.
I found a patch from someone else from a while back, which you had reviewed :-) So I applied that.
The redirection only works if a shell is being used, and it normally isn't. We certainly are not requesting a shell when calling subprocess. As to why on some machines we appear to get one anyway, I cannot comment.
Regards, Simon