I was trying to add a new issue on issues.Jenkinsci.org

If I entered labels/tags

crash native D-Bus

then trying to save the issue resulted in an error

Exception occurred: com.atlassian.jira.exception.DataAccessException: org.ofbiz.core.entity.GenericDataSourceException: Generic Entity Exception occurred in deleteByAnd (SQL Exception while executing the following:DELETE FROM label WHERE FIELDID IS NULL AND ISSUE=? (Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'))

I was able to save if I removed the labels. If I tried to edit the issue again (http://issues.jenkins-ci.org/browse/JENKINS-9097) and add the labels, I got the same error again.

The yum repo at http://pkg.jenkins-ci.org/redhat is missing the yum metadata, which IIRC should be located in repodata/repomd.xml relative to the base of the repo.

Without this file, many yum operations, including installs, fail. In our case, we use Red Hat Satellite to replicate repos for intranet use, as individual nodes cannot install software directly over the internet. Replication via the reposync utility fails because this metadata file is not present.

A yum repo is more than a directory of package files. It also serves an index containing package metadata so that client systems can check for updates and resolve dependencies without downloading the packages themselves.

Please generate the repodata/ directory and its constituent files.. and regenerate the files whenever new RPMs are released. This is usually done with the createrepo utility either directly or as part of the publish process.

used the plugin generator http://plugin-generator.jenkins-ci.org to create a starter plugin.

setup nexus adding the jenkins-ci proxy as described.

followed instructions on this page for packaging the project:

mvn package
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building awesome 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.026s
[INFO] Finished at: Sun Jul 07 10:24:51 PDT 2013
[INFO] Final Memory: 10M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project awesome: Could not resolve dependencies for project org.jenkins-ci.plugins:awesome:hpi:1.0-SNAPSHOT: Failure to 
find org.netbeans.modules:org-netbeans-insane:jar:RELEASE72 in http://localhost:8081/nexus/content/groups/public was cached in the local repository, 
resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

When I browse in nexus I do see the org-netbeans-insane release.

I deleted the cached copy under ~/.m2/repository then re-running mvn and mvn still can not find the org-netbreans-insane release.

this 'awesome' plugin is not awesome.

Looking at https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation it's not clear which auto-installers are supported on which platforms. For example, there is no indication that the JDK and Mercurial installers are not supported on MacOS X.

Perhaps you could put up a matrix of operating systems and tools. The intersection would indicate the version number that introduced support for that combination.

Source RPMs are built by the rpm/build.sh script in the Jenkins Git repo, but they are not available in the Yum repository:

[root@sandbox ~]# yumdownloader --disablerepo='*' --enablerepo=jenkins --urls --source jenkins
...
No source RPM found for jenkins-1.423-1.1.noarch
No source RPM found for jenkins-1.413-1.1.noarch
Nothing to download

Source RPMs are useful for us to be able to use your packaged version as it allows us to review the contents of the package more easily.

http://pkg.jenkins-ci.org/debian contains entry for jenkins_1.502_all.deb, but v1.502 has not been released. Therefore, sudo apt-get update && sudo apt-get install jenkins results in an error on debian linux, because aptitude will attempt to install the latest listed version. 1.502 is listed as the latest version, but it doesn't exist yet. 1.501 is the latest version. Therefore, attempting to upgrade jenkins results in a 404 error, as aptitude cannot find 1.502.

Sometime between 22:59:17 BST and 02:47:23 BST the jira email notification have changed from text to HTML.

Is there any good reason for this?

I'm now required to convert the mail to text before I can read it.

Scenario:
1. open https://jenkins-ci.org/account
2. click on "Create a new account" link
3. click on submit button

I got error:

HTTP ERROR 500
Problem accessing /doSignup. Reason:
Captcha mismatch

Caused by:
java.lang.Error: Captcha mismatch

at org.jenkinsci.account.Application.doDoSignup(Application.java:77)

at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)

at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)

at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)

at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:102)

at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)

at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)

at org.kohsuke.stapler.Stapler.service(Stapler.java:159)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:527)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:423)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)

at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:866)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)

at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245)

at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)

at org.eclipse.jetty.server.Server.handle(Server.java:337)

at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:595)

at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1055)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:764)

at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:217)

at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:489)

at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)

at java.lang.Thread.run(Thread.java:619)

Powered by Jetty://

I've missed something like "setup", "installer", or "jenkins". After two minutes of searching I dared to choose an arbitrary component. After creating the issue (JENKINS-16317) I found "other", but this is far from being good as well.

http://mirrors.jenkins-ci.org/debian/jenkins_1.532_all.deb returns 404.

Searching the 'www' component in Jira, it looks like this happens very frequently.

The link on the main Jenkins page for OSX installer is broken. It goes to http://mirrors.jenkins-ci.org/osx/latest, which tries to load jenkins-1.532.pkg.

Oddly enough if I go to the osx directory I can see a directory listing and that file is there, but if I click on it I get the error. Clicking on jenkins-1.531.pkg works however.

Hi,

the link to http://mirrors.jenkins-ci.org/war/latest/jenkins.war is extremely convenient.

Please provide a http://pkg.jenkins-ci.org/debian/binary/jenkins_latest_all.deb.

Debian does not care about the name of a package so having a symlink should be enough.

Pro: Updates are easier as there is now only a single link to check
Con: People may start hammering the server since checking for updates is now easy

Thanks,
Martin

The apt repository currently is hosted at pkg.jenkins-ci.org. Release/Packages files are hosted under there with relative links pointing to .deb files under the same vhost. Those links 302 redirect to mirrors.jenkins-ci.org, which in turn 302 redirects to one of the mirrors. mirrors.jenkins-ci.org itself doesn't host the Packages/Release files and hence can't be used as an apt repo by itself.

The double redirects is, of course, valid HTTP behavior. However, we make use of a very popular software for apt management called "reprepro" which among its functionalities is the ability to fetch packages from third-party repositories. Our config, very typical, would be:
https://phabricator.wikimedia.org/source/operations-puppet/browse/master/modules/install-server/files/reprepro-updates;5772d3726e576da11b3f1ed90f20c3ce3ddd08d5

The problem is, one of reprepo's known limitations is that it does not support double redirects, issuing this error message:

aptmethod redirects already redirected 'http://mirrors.jenkins-ci.org/debian-stable/jenkins_1.532.1_all.deb' again to 'http://ftp-nyc.osuosl.org/pub/jenkins/debian-stable/jenkins_1.532.1_all.deb'
Multiple redirects currently not supported by reprepro

Although not a bug per se, it'd be great if Jenkins' apt repository avoided redirecting twice and hence was compatible with reprepro.

One less credential to worry about.

Jenkins RPM for version 1.469 has a different checksum than published in yum repository metadata.
When first time version 1.469 appeared, we couldn't found the rpm, although repository metadata contained all required information. After a day, rpm appeared, but with different checksum.
Was the rpm been rebuilt/replaced without rebuilding repository metadata?

Here is yum update output:
--------------------------
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package jenkins.noarch 0:1.469-1.1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================
Package Arch Version RepositorySize
==============================================================================================================
Updating:
jenkins noarch 1.469-1.1 jenkins 46 M

Transaction Summary
==============================================================================================================
Install 0 Package(s)
Upgrade 1 Package(s)

Total download size: 46 M
Is this ok [y/N]: y
Downloading Packages:
jenkins-1.469-1.1.noarch.rpm | 46 MB 00:56
http://pkg.jenkins-ci.org/redhat/jenkins-1.469-1.1.noarch.rpm: [Errno -1] Package does not match intended download
Trying other mirror.

It's probably easier if I just scrape the version number then issue "svn log" to find the details than to parse the HTML e-mail.

The debian-package-builder plugin should have a 'debian-package-builder' component alter ego in JIRA. The name is listed on the wikipage at https://wiki.jenkins-ci.org/display/JENKINS/Debian+Package+Builder+Plugin

following up on a discussion we had on irc, it would be helpful to have md5 checksums for the download files on updates.jenkins-ci.org.

if downloading a file fails for some reason, e.g. due to a mirror issue or a timeout, this can be used to verify the file manually.

(this could be used by the jenkins application itself to verify file downloads, however for starters, providing just the checksums would be sufficient)

Provide an official Gentoo overlay that will get updated with each release.
See http://code.google.com/p/godin-gentoo-repository/source/browse/trunk/repository#repository/dev-util/hudson-bin for a working example.

mirrors.jenkins-ci.org does not support HTTPS and there is no other way to download Jenkins and Jenkins plugins.

This morning, the update center job ran but failed to fetch the plugin information:
http://ci.jenkins-ci.org/job/infra_update_center/2494/console

This resulted in an update-center.json file which was valid JSONP, but the "plugins" object was empty.
JoJ then pushed this to the web site and mirrors. The problem was transient (drulli re-ran the job).

In any case, there should be some sanity checks before pushing the file to the web.
e.g. fail the build and notify if the file size is < 2kB, the JSON is invalid, if the "plugins" section is empty, or has fewer than x items in it...

Same goes for the "stable" variant of the update-center job.

Kohsuke Kawaguchi is whining

Although the repository at http://pkg.jenkins-ci.org/debian contains packages for jenkins-cli, the metadata doesn't reference it, which makes it impossible to install.

Regarding the jenkins-plugin-info Wiki macro: It appears that the "Source Code" field is generated by simply appending the plugin name to "https://github.com/jenkinsci/" instead of leveraging the plugin's SCM pom element.
This fails where there are several plugins in one Git repository.
E.g. on https://wiki.jenkins-ci.org/display/JENKINS/Jenkow+Activiti+Explorer the GitHub link is wrong.
See the plugin's POM: https://github.com/jenkinsci/jenkow-plugin/blob/master/jenkow-activiti-explorer/plugin/pom.xml#L50

If you look at http://pkg.jenkins-ci.org/redhat/ it indicates that 1.544 should be available. However, if you're actually using that yum repository, the most recent you are offered appears to be 1.534 (three months old).

I'm guessing that someone has forgotten to run createrepo for a while.

I am trying to install specific version of Jenkins (1.427) via 'apt get jenkins=1.427' which fails with "E: Version '1.427' for 'jenkins' was not found"

Here are details:
Performing (as root):

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
apt-get update
apt-get install jenkins=1.427

Here is the output:

root@test2:~# wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
OK
root@test2:~# sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
root@test2:~# apt-get update
Get:1 http://pkg.jenkins-ci.org binary/ Release.gpg [198B]
Get:2 http://pkg.jenkins-ci.org binary/ Release [2126B]     
Get:3 http://pkg.jenkins-ci.org binary/ Packages [564B]  
Get:4 http://security.ubuntu.com lucid-security Release.gpg [198B]      
Hit http://archive.ubuntu.com lucid Release.gpg  
Get:5 http://archive.ubuntu.com lucid-updates Release.gpg [198B]
Get:6 http://security.ubuntu.com lucid-security Release [57.3kB]
Hit http://archive.ubuntu.com lucid Release  
Get:7 http://archive.ubuntu.com lucid-updates Release [57.3kB]
Hit http://archive.ubuntu.com lucid/main Packages      
Hit http://archive.ubuntu.com lucid/restricted Packages
Hit http://archive.ubuntu.com lucid/universe Packages
Hit http://archive.ubuntu.com lucid/main Sources
Hit http://archive.ubuntu.com lucid/restricted Sources
Hit http://archive.ubuntu.com lucid/universe Sources
Get:8 http://security.ubuntu.com lucid-security/main Packages [251kB]
Get:9 http://archive.ubuntu.com lucid-updates/main Packages [541kB]
Get:10 http://security.ubuntu.com lucid-security/restricted Packages [14B]
Get:11 http://security.ubuntu.com lucid-security/universe Packages [113kB]      
Get:12 http://security.ubuntu.com lucid-security/main Sources [73.1kB]   
Get:13 http://archive.ubuntu.com lucid-updates/restricted Packages [4011B]       
Get:14 http://archive.ubuntu.com lucid-updates/universe Packages [251kB] 
Get:15 http://archive.ubuntu.com lucid-updates/main Sources [208kB]  
Get:16 http://security.ubuntu.com lucid-security/restricted Sources [14B]    
Get:17 http://security.ubuntu.com lucid-security/universe Sources [28.3kB]   
Get:18 http://archive.ubuntu.com lucid-updates/restricted Sources [1850B]    
Get:19 http://archive.ubuntu.com lucid-updates/universe Sources [85.4kB]
Fetched 1675kB in 2s (702kB/s) 
Reading package lists... Done
root@test2:~# apt-get install jenkins=1.427
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Version '1.427' for 'jenkins' was not found

Looking at the cache statistics, the object properties need a bigger cache. It's filling up all the allocated space but still has a very slow hit rate.

using repository:
deb http://pkg.jenkins-ci.org/debian binary/

apt-get update
apt-get install jenkins

Err http://pkg.jenkins-ci.org/debian/ binary/ jenkins 1.518
404 Not Found
Failed to fetch http://pkg.jenkins-ci.org/debian/binary/jenkins_1.518_all.deb 404 Not Found

I am not sure what is the right component to ask this question.

We face a build failure for gerrit_master [1] running on http://ci.jenkins-ci.org/.
It's probably caused by a buggy JDK version, we believe it should work when using
jdk 1.6_26 or later but currently only 1.6_24 is available on http://ci.jenkins-ci.org/.
We also tried using jdk 7 but this fails as it seems to be not properly installed
on http://ci.jenkins-ci.org/ [2].

Could you please install latest jdk 1.6 and fix the jdk 7 installation on http://ci.jenkins-ci.org/ ?

[1] http://ci.jenkins-ci.org/job/gerrit_master/557/
[2] http://ci.jenkins-ci.org/job/gerrit_master/564/console

https://jenkins-ci.org/ has all sorts of problems since all the images and JavaScript files are loaded from http:// URLs.
Aside from an unhappy padlock icon in the URL bar, Google Chrome refuses to load JS from http:// URLs in this case and so breaks functionality like the sidebar.

More importantly, it breaks user signups on the website since the reCAPTCHA JS can't be loaded.

People end up on the HTTPS URL rather than the default HTTP since JIRA uses HTTPS by default, so clicking the "Sign up" link redirects people to https://jenkins-ci.org/account

Wiki is serving old versions of pages.

Page:
https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+...

Page info displayed (cached):
Added by Bap bap2000, last edited by Bap bap2000 on Sep 10, 2012 (view change)

Current (after clicking on view changes):
Current by Bap bap2000 on Oct 22, 2012 14:14.

Please visit http://jenkins-ci.org/ and then click on Long-Term Support Release tab.
The displayed version is 1.466.2 that links to http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war.
Today (2012-11-19) link http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war resolves to version 1.480.1.

Maybe the content of the main webpage could be generated automatically based on content of http://mirrors.jenkins-ci.org/.

I think if you (Kohsuke Kawaguchi) generate a certificate we can use for ci.jenkins-ci.org, and bring the instance back online listening on port 8443, then we just need to update the /etc/haproxy/haproxy.cfg on cucumber to reflect the port appropriately.

I can help out with this if needed.

This is JENKINS-15785 with more details.

Is it possible to enable the security-scheme-feature of this jira-instance (issues.jenkins-ci.org), so that users can choose if the created issues is viewable by public, jira-users or only participants. Today there is no possibility to hide issues for public access. Deletion is also not supported.

Thanks
Thomas

please provide easy link to source code from home page. i find it not that easy to find https://github.com/jenkinsci/jenkins if one is unhappy and lands on http://jenkins-ci.org/.

I've committed subversion-plugin to https://svn.jenkins-ci.org/. then I got the following error.

警告: post-commit hook failed (exit code 2) with output:
Can't locate SVN/Notify.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/local/bin/svnnotify line 9.
BEGIN failed--compilation aborted at /usr/local/bin/svnnotify line 9.

Please make cucumber.jenkins-ci.org administratable via puppet.

As per title.

None of the sites are accessible via IPV6, and while this is a trivial matter for the most part it does prevent automatic updates via Linux package managers using pkg.jenkins-ci.org.

Everytime I want to log into Jira, I have to request a password reset. I've made simple passwords that were accepted in the password reset dialog, but failed to work after log out and sign on.

Update center JSON metadata files advertise plugins before they're available for download on mirrors. INFRA-2322 explains this in some more detail.

This thread might be relevant.

Note that svn.jenkins-ci.org is slowly retiring.

Currently only SHA1 is available. This could allow malicious plugin authors to construct a plugin which has a known hash collision, and then later use the fact that plugin downloads are not over HTTPS to attack servers installing that plugin. SHA2 and SHA3 are more resistant to collision attacks.

The Packages list at http://pkg.jenkins-ci.org/debian/ only contains the most recent version of Jenkins even though all of the previous ones are there. This makes it a PITA to downgrade Jenkins if it's installed via the Debian package.

That makes dealing with tickets such as https://issues.jenkins-ci.org/browse/JENKINS-16979 - which should be as simple as 'aptitude install jenkins=1.502' much more annoying.

http://jenkins-ci.org/ shows 1.509.4 as the latest version of the LTS releases. It is actually 1.532.1, according to the changelog and the file that is actually downloaded if you click this.

Dear all,

This issue is about issues.jenkins-ci.org : I hope that selecting 'jira' as a component is correct for this (this issue is not meant for any Jenkins Jira Plugin if such exists).

While creating an account for the Jenkins Jira there were some things that maybe could be improved. Please do not consider this blameful nagging or such, I just wanted to record my experiences to allow the opportunity to improve for future users. I could imagine regular Jenkins Jira users will never experience this again as they might not need to use the account creation process again.

1) The email I got contained some incorrect text (see attached):

• the text "This is either because an administrator has
  created an account for you, or because you have been
  assigned to an issue." is incomplete: I just simple
  created an account myself via the Web UI.

• the text "This action was initiated by null (null)."
  seems to be caused by something that is not working

• the provided link after the text "please contact your
  JIRA administrators" points to a page stating "Your
  JIRA administrator has not yet configured this
  contact form."... So what am I supposed to do? Could
  provide some more helpful text.

2) In a separate email I found the text "Your temporary
password is ...", which suggest I am able to or will
be asked to change this password. I spend some time
searching the Web UI, as well as did some Googling,
but I haven't got the faintest idea how to change my
password. If this is not possible it would be nice of
the email to say so. If it is possible it might be
explained how/where.

3) The attached email contains the text "This account
uses your password from an external user directory:
"JIRA Delegated Authentication Directory"."
This information is completely meaningless to me.
I now suspect it might be related to me not being
able to figure out how to change my password, but
this is still not clear to me.

Please feel free to fix / prioritize based on effort, for your consideration. Thank you for your work on Jenkins, I love it!

Cheers,
Paul

Inside my organization, I need to retain historical copies of repositories of deployed code. The easiest way for me to do this for external code is to rsync RPM repositories and use dirvish to keep historical backups of deployment snapshots. I'm unable to (and disallowed from) downloading packages directly from the internet (firewall issues that can't be overcome for policy reasons).

It would be much simpler for me to add a line in the script that I use to sync Fedora and half a dozen other RPM repos that I use

This is just a really minor thing.
While visiting http://jenkins-ci.org/stable-rc page, the selected tab is "Release".
As http://jenkins-ci.org/stable-rc page refers to LTS Release I would expect that selected tab should be: "Long-Term Support Release".

Looking at https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation it's not clear which auto-installers are supported on which platforms. For example, there is no indication that the JDK and Mercurial installers are not supported on MacOS X.

Perhaps you could put up a matrix of operating systems and tools. The intersection would indicate the version number that introduced support for that combination.

Created a new account and was emailed password with confusing 0O / 1IL in it ... Got the password wrong several times.

Asked for a new password and this time copy and pasted the password. System says "your account requires a captcha" but never lets me log in, have tried many many times - have requested password changes many times and repeated. Looks to me like once an account requires captchas the captchas just do not work and you cannot log in.

I've had to create a new account and managed to log in correctly (before captchas kicked in) and it worked.

After moving from Hudson 2.0.0 to Jenkins, Jenkins announces an available update to v2.0.1. This is a Hudson update and would down/sidegrade Jenkins back to Hudson. Seems to be caused by cached entries from old Hudson data.

Workaround by forcing update check in update center.

Trivial fix is to force update check on Jenkins startup.