Issue metadata
Sign in to add a comment
|
upgrade fleet to python > 2.7.8 |
||||||||||||||||||||||||
Issue descriptionhttps://build.chromium.org/p/chromium.android/builders/Android%20N5X%20Swarm%20Builder builds android in a 64-bit ARM configuration. Recently, https://codereview.chromium.org/2122063003 landed which increased the number of APKs processed by remove_build_metadata. However, this caused the step to repeatedly fail on ChromePublic.apk: https://build.chromium.org/p/chromium.android/builders/Android%20N5X%20Swarm%20Builder/builds/1747 Processing: ChromePublic.apk Exception in thread Thread-5: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 763, in run self.__target(*self.__args, **self.__kwargs) File "/b/build/scripts/slave/recipe_modules/isolate/resources/remove_build_metadata.py", line 106, in remove_metadata_worker remove_apk_timestamps(os.path.join(build_dir, f)) File "/b/build/scripts/slave/recipe_modules/isolate/resources/remove_build_metadata.py", line 78, in remove_apk_timestamps with zipfile.ZipFile(filename, 'r') as zf: File "/usr/lib/python2.7/zipfile.py", line 770, in __init__ self._RealGetContents() File "/usr/lib/python2.7/zipfile.py", line 857, in _RealGetContents x._decodeExtra() File "/usr/lib/python2.7/zipfile.py", line 388, in _decodeExtra tp, ln = unpack('<HH', extra[:4]) error: unpack requires a string argument of length 4
,
Jul 12 2016
Looks like the APK zip format changed to become non-standard. For the stack trace, it is as if the zip was cut early. I don't have access to the N SDK at the moment so one of clank folks will have to look into it.
,
Jul 12 2016
This doesn't involve the N SDK yet.
,
Jul 12 2016
Ok thanks, then it's something else.
,
Jul 18 2016
It looks like it is a bug in the Python zipfile library, it has been fixed: https://bugs.python.org/issue14315 Can we just update the version of this package that we're using ?
,
Jul 18 2016
That's Ubuntu-14.04 host which is running python 2.7.3. It was fixed in python 2.7.8 as per https://hg.python.org/cpython/file/6dd5e9556a60/Misc/NEWS. The fix would be to update these slaves to Ubuntu 16.04: slave36-c1, slave37-c1, slave38-c1, slave39-c1, slave41-c1, slave46-c1, slave76-c1 Assigning to Ryan for triaging.
,
Jul 18 2016
Well, we could also install latest python but it's less long term work to start switching to the current Ubuntu LTS version.
,
Jul 18 2016
from hinoka: "We dont' have a xenial image yet https://uberchromegw.corp.google.com/i/internal.infra.cron/builders/ccompute-chrome-xenial64"
,
Jul 18 2016
We don't have a Xenial image yet: https://uberchromegw.corp.google.com/i/internal.infra.cron/builders/ccompute-chrome-xenial64
,
Jul 18 2016
My point is that it's probably worth doing one now. 16.04 has been out for a while.
,
Jul 18 2016
let's make a separate bug for that. hinoka@ says he can force the version of python on the trusty image, and I think that's a better solution for now.
,
Jul 19 2016
Turns out there's no clean way to install python 2.7.12 on Trusty other than: wget https://www.python.org/ftp/python/2.7.12/Python-2.7.12.tgz tar xfz Python-2.7.12.tgz cd Python-2.7.12/ ./configure make make install Anyone have a better idea?
,
Jul 19 2016
This is probably a good idea as a matter of fact. A more draconian way is to replace system python but I don't think it's a fabulous idea; https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes-python2.7
,
Aug 3 2016
,
Sep 29 2016
Changing bug name to reflect the action.
,
Aug 30 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by benhenry@google.com
, Jul 7 2016Labels: Pri-2