Please backport subversion subversion_1.5.1dfsg1-1ubuntu2 from intrepid

As I was commenting on #251220 (didn't find this bug as I was searching for "backport subversion"):
motivation for a backport:
subversion 1.5 automatically upgrades format of checkouts; this makes it impossible to work on upgraded checkouts from 8.04. This can happen if your checkouts are in a NFS mounted /home (or, as in my case, when dual booting) if you ran a newer subversion such as intrepid's or Debian sid's subversion which upgraded your shared checkouts.

subversion 1.5 also brings up tons of cool features which would be nice to use under hardy.

ABI/API changes:
The lib package name is still libsvn1, but shlibs were bumped suggesting that only ABI additions happened.

Build-deps of subversion 1.5.0dfsg1-4ubuntu2 are satisfied in hardy; I'm running a pbuild.

Builds fine under hardy pbuilder.

Works fine for me; can't set "Triaged" though, so I'll let this to Ubuntu Backporters.

NB: I'm core-dev, but I don't need the packages urgently, so I'm not pushing this request myself and prefer additional testing.

Is there a way to get built packages? I can help with testing

In my testing, I noticed that the zsh completion seems to be broken with this combination; however it works fine in pure hardy or pure intrepid installs.

The rationale is compelling. we ought to do this, but first we need to test rdepends. Subversion has a lot. If a selection of them are tested OK, then I think it's OK. If some of them need to be updated to work, then we'll need to test them all.

Just to double this request, new subclipse versions starting with 1.4.0 require subversion-1.5.0 to be installed in order to be functional at all. I installed subclipse 1.4 alongside with eclipse-3.4, so a subversion-1.5.0 backport is needed in order to have a fully functional eclipse-3.4 + subclipse setup.

I'm currently running my own backported package from https://edge.launchpad.net/~clazzes.org/+archive and had no problem so far.

Please note, that subversion-1.5.1 has been released upstream, which fixes some minor issues. Hence I think subversion-1.5.1 would be the right starting point for a hardy-backport.

  Regards,

     Wolfgang

Has anyone tested 1.5.1dfsg1-1ubuntu2 on Hardy?

Some fraction of the rdepends need to be tested:

apt-cache rdepends subversion
subversion
Reverse Depends:
 |devscripts
 |devscripts
  rancid-core
  websvn
  viewvc
  trac
  tkcvs
  tailor
  svn-buildpackage
  svn-autoreleasedeb
  svn-arch-mirror
  svk
 |qct
  python-codespeak-lib
  nautilus-script-collection-svn
  mr
  lua5.1-policy-dev
  linux-wlan-ng-firmware
  libsvn-notify-perl
  libnb-svnclientadapter-java
  kdesdk-kio-plugins-kde4
  kdesdk-kio-plugins
  jhbuild
 |ikiwiki
  gonzui
  git-svn
  gforge-plugin-scmsvn
  esvn
  emdebian-tools
  education-desktop-other
  ditrack
  cvs2svn
 |cia-clients
  chora2
  cedar-backup2
  subversion-tools
  python-subversion
 |devscripts

Wolfgang

Since you noted subversion 1.5.1 might we/me ask if you have a moment to backport this on PPA?

Jeff

Not a moment, but now I've got a working backport in the clazzes.org PPA.

Feel free to test it.

   Wolfgang

Wolfgang

Yes. I believe I just updated to 1.5.1...I suspect it is from your PPA.

Great...thanks...

Jeff

Jeff Bakst
Software Technical Staff
FXP Technologies, Inc., a foxconn Company
1551 Sawgrass Corporate Parkway
Sunrise, FL 33323

-----Original Message-----
From: <email address hidden> on behalf of Wolfgang Glas
Sent: Mon 8/4/2008 2:35 PM
To: Jeff Bakst-FJB003
Subject: [Bug 247514] Re: Please backport subversion 1.5.0dfsg1-4ubuntu2 fromintrepid

Not a moment, but now I've got a working backport in the clazzes.org
PPA.

Feel free to test it.

   Wolfgang

--
Please backport subversion 1.5.0dfsg1-4ubuntu2 from intrepid
https://bugs.launchpad.net/bugs/247514
You received this bug notification because you are a direct subscriber
of the bug.

Status in Hardy Heron Backports: Incomplete

Bug description:
There are SVN 1.5 packages already available for Intrepid Ibex.
These would be really useful in Hardy.

Please mind, that someone has to check the reverse dependencies mentioned by Scott.

Unfortunately I do not use any of the mentioned packages. I only use the javahl-interface through subclipse-1.4.2 and the command line client. Both work very well for me as of subversion 1.5.1dfsg1-1ubuntu2clazzes5.

  Regards,

   Wolfgang

Ubuntu hardy testing with the following

Netbeans 6.1x works no issues seen thus far
Eclipse Ganymede no issues seen this far (uses java API not if this also will use native svn libs)

also I have verified command line svnadmin import as well as svn for checkouts/commits

Jeff

Ubuntu hardy amd64 testing successful
- svnadmin load
- apache2 modules
- javahl (through Eclipse)
- websvn
- trac
- python-subversion
- basic command line functionality (checkout, update, merge, copy, commit, log)
- 10 different repositories hosted by same server

That's enough variety with no issues that given the incompatibility issues as repos are upgraded we should go ahead. Ack from ubtuntu-backporters.

Please continue testing to see if any of the rdepends need updating.

Scott, here are the notes I took while backporting interpid's current subversion-1.5.1dfsg1 pacakge:

debian/control: Change from default-jdk to java-gcj-compat-dev and default-jre to gij
debian/rules: Change from /usr/lib/jvm/default-jdk to /usr/lib/jvm/java-gcj
cp subversion-1.5.0dfsg1/debian/patches/java-build subversion-1.5.1dfsg1/debian/patches/java-build
debian/patches/series: uncomment java-build

All this hazzle is here, because in intrepid a new package 'default-jdk' has been introducded, which dispatches to the actually chosen JDK. In hardy, however, the build of the jni interfaces used gcj and need some extra patches.

For the control and rules file it simply boils down to use the files from intrepid's subversion-1.5.0dfsg1 package, which did not incorporates the switch to default-jdk.

And, yes, you might take my source packages from the clazzes.org repository, in case you don't want to reinvent the wheel ;-)

  Best regards,

   Wolfgang

Thanks. I'll see about putting things together.

Good luck, Scott. Shouldn't be that hard to craft a backport package ;-)

TIA for bringing this to hardy-backports,

    Wolfgang

Greetings:

I'm also interested in using a hardy-backports of 1.5 into hardy on an amd64 build. Is there any reason why this PPA's build cannot be used for teh backports? https://launchpad.net/~c-korn/+archive?

Would installing those packages conflict with the ones from the official backports?

Thanks.
Bill.

Bill, the backport has been accepted an AFAICS Scott will do the technical parts, which should not be very hard, because we have at least two PPA backports available by now.

  Just a little patience ;-)

    Regards, Wolfgang

Which is the proper source to test the SVN 1.5.x backport before it makes it into the official Hardy backports repository?

This really just needs me to have time to prepare a package to upload.

Go, scotty, go ;-)

Source backport uploaded, now we just need for an archive admin to accept it.

ack from ubuntu-backporters.

Accepted into the archive. Once it builds and reaches your local mirrors it will be available.

Thanks very much, folks!

Unfortunately this breaks kdesvn (kde3.5.10) :(

This is the error kdesvn spits out:

Unable to open an ra_local session to URL
Unable to open repository 'file:///data1/devtools'

Used as a Konqueror plugin it crashed.

Is there a serious reason, why the new SVN is compiled against libneon-gnutls and not against the OpenSSL version libneon? SVN support is broken for me, since I need to authenticate with a client certificate against the server.

Any chance that this will be fixed?

The backport is that way because that is the way it is in Intrepid. I
suggest you file a new bug against the subversion package. If it gets
changed in Intrepid, we can backport the update.

Thank you Scott, I filed a new bug report: See bug #265065

This package installation has the side effect of rendering python-setuptools dysfunctional. easy_install with a url that is a svn repo will do a check out, but easy_install (part of python-setuptools) reads the .svn files directly for some reason, and don't know that version # of the format of the files. I had fixed this at some point on a redhat install, and am new to ubuntu. The fix was easy (just added the new format revision number to be a know type for easy_install), but I don't have a diff handy. This will surely bork lots of people when this becomes more popular in backports.

This was fixed in setuptools-0.6c9 release:

http://bugs.python.org/setuptools/issue4

So if we backport setuptools-0.6c9, I guess that would help.

setuptools 0.6c9 is entirely compatible with 0.6c8 (which is in Hardy), and 0.6c9 is a very stable change, limited to fixes of known bugs in 0.6c8, so it would be unlikely to cause problems. Also, setuptools is "infrastructural" for me -- I rely on it to do all sorts of development and deployment, and one of my prime deployment targets is Hardy (really it is just about the most important deployment platform for me nowadays), so I would be quite happy to see setuptools-0.6c9 in Hardy backports.

Please file a new backports bug for that and we'll look at it.