chromium-92.0.4515.159/buildtools/freebsd/clang-format and python bytes/bytarray vs. str failures in poudriere-devel based builds
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 04 Oct 2021 08:02:32 UTC
When I try to build www/chromium via poudriere-devel
I get errors of the form:
Traceback (most recent call last):
File "/wrkdirs/usr/ports/www/chromium/work/chromium-92.0.4515.159/buildtools/freebsd/clang-format", line 34, in <module>
stdout, stderr = proc.communicate(input=contents)
File "/usr/local/lib/python3.8/subprocess.py", line 1028, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/local/lib/python3.8/subprocess.py", line 1848, in _communicate
input_view = memoryview(self._input)
When I look at:
/wrkdirs/usr/ports/www/chromium/work/chromium-92.0.4515.159/buildtools/freebsd/clang-format
I see (in part):
. . .
contents = ''
if '-' in args or not inputfiles:
contents = sys.stdin.read()
. . .
proc = subprocess.Popen(
['clang-format'] + args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
env=env)
stdout, stderr = proc.communicate(input=contents)
. . .
Which looks to me to be passing a str, not a bytes nor a bytearray
nor a None.
Also Popen.stdin is documented with:
QUOTE
Popen.stdin
If the stdin argument was PIPE, this attribute is a writeable stream object
as returned by open(). If the encoding or errors arguments were specified
or the universal_newlines argument was True, the stream is a text stream,
otherwise it is a byte stream. If the stdin argument was not PIPE, this
attribute is None.
END QUOTE
So, if I gather correctly, stdin ends up being a byte stream acording
to the documenation.
proc.communicate is documented with "If streams were opened in text
mode, input must be a string. Otherwise, it must be bytes." as well.
And that in turn involves:
/usr/local/lib/python3.8/subprocess.py has:
def communicate(self, input=None, timeout=None):
. . .
stdout, stderr = self._communicate(input, endtime, timeout)
. . .
So input still seems to be a str for the following:
def _communicate(self, input, endtime, orig_timeout):
. . .
self._save_input(input)
if self._input:
input_view = memoryview(self._input)
. . .
but self._input need not be.
This is where:
def _save_input(self, input):
# This method is called from the _communicate_with_*() methods
# so that if we time out while communicating, we can continue
# sending input if we retry.
if self.stdin and self._input is None:
self._input_offset = 0
self._input = input
if input is not None and self.text_mode:
self._input = self._input.encode(self.stdin.encoding,
self.stdin.errors)
The implication of the error would seem to be
that the encode did not happen and, so, either
self.stdin and self._input is None
was false or:
self.text_mode
was false (and it appears to be the later).
This fits with the stdin being a byte stream but input being a str
--and so the error report from memoryview.
But I still have no clue why the FreeBSD server builds of chromium
do not end up with such an error report.
Note: I've duplicated the failure in my aarch64 and amd64 contexts.
For reference:
# pwd
/usr/ports
# ~/fbsd-based-on-what-commit.sh
branch: main
merge-base: 59611d61d70a85f4418f3f701db1b7baf58560ba
merge-base: CommitDate: 2021-09-29 09:39:17 +0000
59611d61d70a (HEAD -> main, freebsd/main, freebsd/HEAD) databases/postgresql14-server: fix openssl dependency
n560161 (--first-parent --count for merge-base)
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032
I do not see such a failure in the likes of:
http://ampere2.nyi.freebsd.org/data/main-arm64-default/p5f5c0fe00a09_s3fcbde5e88/logs/chromium-92.0.4515.159_2.log
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)