8000 test python3.5 32 bit debug with gcc 5 by juliantaylor · Pull Request #5772 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

test python3.5 32 bit debug with gcc 5 #5772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

test python3.5 32 bit debug with gcc 5 #5772

wants to merge 1 commit into from

Conversation

juliantaylor
Copy link
Contributor

not merge material, but lets see what breaks with new stuff

@juliantaylor juliantaylor force-pushed the py35-test branch 7 times, most recently from e634f3f to f0af1a1 Compare April 18, 2015 00:43
@rgommers
Copy link
Member

good idea. doesn't seem too bad. The errors on

import mmap
import resource
import cmath

look like an issue with this particular Python 3.5 build, those modules aren't removed.

@juliantaylor
Copy link
Contributor Author

yes those are most likely packaging errors, I'll take care of it.
the gzip offset errors look a little worrying but probably an issue of py3.5 itself.

@juliantaylor
Copy link
Contributor Author

@rgommers when you fixed #5644 are you sure the error went to stdout?
from what I can tell the version check actually merges stdin and stdout which also caused issues for this test.

@rgommers
Copy link
Member

Think so, but I'll double check tonight (not in front of that laptop now).

What issue does it cause, and where is that merge happening (and guess that was always the case then)?

@juliantaylor
Copy link
Contributor Author 
LD_PRELOAD=/invalidfile python setup.py build

would fail as it has an stderr error message in the version string.
I only looked briefly, but I fear that might already be done in distutils itself, this PR uses a ugly hack to redirect to null in version_cmd

@rgommers
Copy link
Member

It's indeed mixing stderr and stdout; warning does go to stderr:

$ gfortran -dumpversion
gfortran: warning: couldn't understand kern.osversion '14.1.0
4.9.1
$ gfortran -dumpversion > tmp.txt
gfortran: warning: couldn't understand kern.osversion '14.1.0
$ cat tmp.txt
4.9.1
$ gfortran -dumpversion 2>tmp2.txt
4.9.1
$ cat tmp2.txt 
gfortran: warning: couldn't understand kern.osversion '14.1.0

@rgommers
Copy link
Member

Looks to me like it's not distutils, but this: https://github.com/numpy/numpy/blob/master/numpy/distutils/exec_command.py#L436

Comment right above:

# Not sure how to handle the case where errmess
# contains only warning messages and that should
# not be treated as errors.

And docstring of exec_command says The output contains both stdout and stderr messages.

@rgommers
Copy link
Member

exec_command gets called in a bunch of places, and is pretty horrible. Maybe we can add a keyword ignore_stderr=False to it. Needs implementing 3 times though:(

@charris
Copy link
Member
charris commented May 13, 2015

@juliantaylor Mind if I close this?

@juliantaylor
Copy link
Contributor Author

no, though we need an issue for the remaining gzip issue

@charris
Copy link
Member
charris commented May 13, 2015

Could you open an issue then and close this. I'm in a housecleaning mode...

@juliantaylor juliantaylor force-pushed the py35-test branch 2 times, most recently from cf86549 to cbe02b4 Compare June 25, 2015 00:03
8000
@juliantaylor juliantaylor mentioned this pull request Jun 25, 2015
Merged
@juliantaylor
test python3.5 32 bit debug with gcc 5
32bcece 
not merge material, but lets see what breaks with new stuff
@njsmith
Copy link
Member
njsmith commented Jun 25, 2015

current master + #6018 is 3.5 clean AFAICT -- should we clean this up and merge it after all, or...?

@juliantaylor
Copy link
Contributor Author

probably not, your nightly variant with allowed failure is probably better for merging
gcc-5 and the debug mode do provide some value but probably not enough to merge something that builds in the rolling debian experimental/unstable

@homu
Copy link
Contributor
homu commented Jun 25, 2015

☔ The latest upstream changes (presumably #6018) made this pull request unmergeable. Please resolve the merge conflicts.

@charris
Copy link
Member
charris commented Jun 30, 2015

@juliantaylor Still want to keep this open?

@charris
Copy link
Member
charris commented Dec 10, 2015

Closing this. @juliantaylor Feel free to reopen if you still want it.

@charris charris closed this Dec 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@juliantaylor @rgommers @charris @njsmith @homu
0