You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While implementing a fix for #10 I found a really weird edge case that (so far) has only manifested in the Python 2.6 environment on Travis CI: The parsing of /etc/lsb-release results in the expected variable names but the values contain binary garbage including nul bytes. Here's a failing Travis CI build where the following log message can be observed (hard wrapped for readability):
This has left me wondering whether this weird edge case is isolated to the Python 2.6 environment on Travis CI or whether this is a symptom of a bigger problem, possibly a programming error on my side. The weird thing is that the Python 2.7, 3.4, 3.5, 3.6 and PyPy builds all work fine...
In the short term I'm worried that I may have broken the distributor_id and distribution_codename logic for more environments then just the Python 2.6 environment on Travis CI, so I'm going to add a "countermeasure" of sorts to executor.
The text was updated successfully, but these errors were encountered:
While I still don't know why this binary garbage appears during the parsing of /etc/lsb-release in the Python 2.6 environment on Travis CI I've at least implemented a countermeasure (in ec3d737) to avoid regressions in existing features, specifically the distributor_id and distribution_codename logic.
This countermeasure has since been confirmed to fix the apt-mirror-updater test suite breakage, here's a successful build based on executor 21.1.1.
While implementing a fix for #10 I found a really weird edge case that (so far) has only manifested in the Python 2.6 environment on Travis CI: The parsing of
/etc/lsb-release
results in the expected variable names but the values contain binary garbage including nul bytes. Here's a failing Travis CI build where the following log message can be observed (hard wrapped for readability):At first this seemed a minor annoyance in the sense that the test suite failed on this and that needed a workaround (see d3451a9). However since then I found that this also has an adverse effect on the test suite of another project of mine which uses
executor
.This has left me wondering whether this weird edge case is isolated to the Python 2.6 environment on Travis CI or whether this is a symptom of a bigger problem, possibly a programming error on my side. The weird thing is that the Python 2.7, 3.4, 3.5, 3.6 and PyPy builds all work fine...
In the short term I'm worried that I may have broken the
distributor_id
anddistribution_codename
logic for more environments then just the Python 2.6 environment on Travis CI, so I'm going to add a "countermeasure" of sorts toexecutor
.The text was updated successfully, but these errors were encountered: