Yes, this is HUDSON-8656 and not JENKINS-8656.

* commit 'c628bdd3':
  First pass at a fix for JENKINS-8592.

(recording the previous commit 9d7d0d75 by Richie Vos)

The problem is that the sending side has no way of knowing when the
receiving side has hung up. So when the receiving side hangs up we should
be able to read till the stream runs out, then close. Not the optimal
solution, but one that should work for now.

http://issues.jenkins-ci.org/browse/JENKINS-8592

HUDSON-8401.

This grouping of tests targets all Sunday to *another day of week* cron
tabs. There are likely other pairs that could be tested, but this seemed to
work out most of the bugs.

After thinking about it, I don't want to deal with hudsonslave here. jenkinsslave should be found anyway, so that code path should not have been triggered.
And cleaning up residual services isn't jenkins job. Otherwise both can't coexist.

Persist a user-requested offline status for a slave across
restarts. Previously slaves would come back online if the server
was restarted while they were marked 'temporarily offline'.

I believe this also addresses JENKINS-7934 and JENKINS-7805
which look like duplicates.

add "since 1.378" in one changelog item

Eclipse package depends on this
<http://packages.ubuntu.com/maverick/eclipse-jdt>, so I'm doing
monkey-see-monkey-do.

ahochsteger asks 'why do we mess with file permissions anyway?' and he's
right! I digged the history but couldn't find why we do it.

I think we should just set the permissions of the top-level directories,
but leave the other file permissions as-is.

In addition,

- I see no point in touching usr/bin usr/sbin.
  perhaps C&P mistake from some samples?

- Don't touch /var/lib/hudson if .for-jenkins is present,
  so that people using the hudson user can keep upgrading new
  versions of jenkins and run it as hudson

- /var/run/hudson contains no important information,
  so no need to bring it over to /var/run/jenkins

Recording the earlier changes and the integration of the new
executable-war.

Jerome Lacoste reported that 5c91eb1f fixed JENKINS-7745. So marking it as closed.

The ManagedWindowsServiceLauncher refers to hudson.exe and hudson-slave.exe while we renamed the artifact to jenkins.exe.

Tentative fix, completely untested (no windows box around).
Not sure about the service name (jenkinsslave). I added a second check for backward compatibility but I have no idea if it's useful.

JENKINS-7836 tentative fix for the copy from slave to master issues. The problem looks similar to JENKINS-7745, so we might as well synchronized the ProxyInputStream.

to match 2 other methods in this file (instead of hardcoded hudson.war.bak)

JENKINS-8658 depend on latest executable-war. This is where the fix should be. Note: of course one should release that dependency into a stable version

JENKINS-8658 let getHomeDir gather information about where it finds its location. Useful for troubleshooting.