bpo-29808: Do not fail in SysLogHandler constructor if syslog isn't available. by vsajip · Pull Request #695 · python/cpython (original) (raw)

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.

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

Already on GitHub?Sign in to your account

Conversation4 Commits10 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

…n Windows AMD64. (#168)

• Fixed bpo-29565: Corrected ctypes passing of large structs by value.

Added code and test to check that when a structure passed by value is large enough to need to be passed by reference, a copy of the original structure is passed. The callee updates the passed-in value, and the test verifies that the caller's copy is unchanged. A similar change was also added to the test added for bpo-20160 (that test was passing, but the changes should guard against regressions).

• Reverted unintended whitespace changes.

(cherry picked from commit a86339b)

vsajip changed the title3.5 bpo-29808: Do not fail in SysLogHandler constructor if syslog isn't available.

Mar 17, 2017

Although the diff looks correct, this seems to include a whole bunch of unrelated changes.

That's just the messages from empty merge commits in my 3.5 branch. I would expect the spurious messages to all go away when the squash+merge is done.

Thanks @vsajip :)
For the future we shouldn't cherry-pick directly in the maintenance branch, but rather in a separate branch.
The devguide has new recommendation on how to backport using cherry_picker.py which takes care of the rebase, branching, and opening up the PR page.

Does that mean that we shouldn't have our own copies of maintenance branches? I use git worktree and have separate working directories for 3.5, 3.6 and master. I switch to the relevant directory, apply the cherry-pick, run tests and push ... then create a PR using the GitHub UI.