Workaround:
Uninstall the Ubuntu-provided jenkins installation before installing the latest snapshots from the jenkins-ci repository:

apt-get remove jenkins jenkins-common

Tried the workaround and remove jenkins. After this I tried to install it again but I've got

root@smini:/etc/nginx/sites-enabled# apt-get install jenkins
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed
  jenkins
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/61.2 MB of archives.
After this operation, 67.3 MB of additional disk space will be used.
Selecting previously unselected package jenkins.
(Reading database ... 277604 files and directories currently installed.)
Unpacking jenkins (from .../archives/jenkins_1.555_all.deb) ...
Processing triggers for ureadahead ...
Setting up jenkins (1.555) ...
start: Job failed to start
invoke-rc.d: initscript jenkins, action "start" failed.
dpkg: error processing jenkins (--configure):
 subprocess installed post-installation script returned error exit status 1
No apport report written because MaxReports has already been reached
                                                                    Errors were encountered while processing:
 jenkins
E: Sub-process /usr/bin/dpkg returned an error code (1)

We are also facing the same issue, with error

trying to overwrite '/usr/share/jenkins/jenkins.war', which is also in package jenkins-common 1.424.6+dfsg-1ubuntu0.1

Not a critical issue. Workaround is trivial, just download the war file.

Unrelated to Debian Package Builder plugin.

Are conflicts like this actually something that usually is resolved in the upstream projects that host their own repository? I'd expect this to be something solved in the distro's repo.

According to /var/log/upstart/jenkins.log, the error is due to:

/proc/self/fd/9: 4: /proc/self/fd/9: /bin/maintain-plugins.sh: not found

Which itself appears to relate to an out of date /etc/default/jenkins. maintain-plugins.sh appears to be from some old version of the Debian package.

Commenting out the maintain-plugin.sh line allows the job to start.

I'd like to register my deep digust at having to reveal my web traffic to a monopolistic, politically active global spyware provider in order to leave this comment. It is deeply unfair to force contributors into such situations. Could the Jira admin please investigate removal of RECAPCHA as a priority?

I have had this same issue. I find that the versions of Jenkins can cause this. For example, getting the version of Jenkins from the Synaptic Package Manager installs one version than the one online or even from the Ubuntu software store. Debian vs tomcat, etc. I had downloaded the .war version, but it did no good, stating that there is already file of that type in Jenkins-commons, as well as in var/usr/share file. And it was conflicting. But, I still got that message even after I deleted that extra .war file. I did a delete of the Jenkins Jenkins commons, yet still got errors. I will try figuring this out and then report back what I figure out.

dmw damw,
I didn't have a problem starting it. I just did my host http://myServer:8080 (not going to give what that name of it is), and it started up. Jenkins worked. I just had conflict wen I tried to update to a newer version.

Christian Tellefsen,
Thank you. Your advise worked like a charm.
April Morone

Not a problem with the Jenkins project provided packages, but rather interaction with downstream packaging/OS config. Therefore resolving as Not A Defect.