Discussion:
[users] Subversion 1.6.18 and 1.7.5 SRPM tools available for Repoforge use
Nico Kadel-Garcia
2012-06-23 13:23:51 UTC
Permalink
I've been busy, and was reminded at the SVNday conference in Berlin
recently that the Subversion for RHEL 4 is wildly out of date and
incompatible with RHEL 5 and RHEL 6's built-in versions.

My SRPM building toolkits for it are at:

https://github.com/nkadel/subversion-1.6.18-srpm

https://github.com/nkadel/subversion-1.7.5-srpm

The release notes for those vsrsions are at:

http://subversion.apache.org/docs/release-notes/1.6.html

http://subversion.apache.org/docs/release-notes/1.7.html

These work well in my testing on RHEL 4, 5, and 6, on i386 and x86_64.
They don't pass all the "make test" options on RHEL 4 and RHEL 5, but
as near as I can tell, it's because the Python on them is out of date
compared to what the Subversion test suite wants.

Subversion 1.6.18 is compatible with, though somewhat ahead of, the
1.6.11 supported by Red Hat in RHEL 5 and RHEL 6, so it should remain
in the "extras" repository along with Subversion 1.7.5. It provides a
compatible upgrade path for RHEL 4, 5, 6. It lacks some of the newer
features on RHEL 4 and RHEL 5, such as the incompatible Emacs modules,
bash completion, kwallet and gnome-keyring support, and Java utilities
on RHEL 4. Backporting those to RHEL 4 would be insanely difficult
and require upgrading KDE, Gnome, Python, etc., etc., etc. I am not
going there!

The Subversion built into RHEL 4 is 1.1.4, which is amazingly ou of
date and entirely unsupported by the Subversion community. So this is
a really, really useful update, and still a supported code base. In
particular, the syntax and handling of "svn:externals" has changed, so
Subverson projects that use the new syntax really, really, really need
the upgrade.

Subversion 1.7.5 is a major release upgrade, and the working copies it
creates are icompatible with the Subversion 1.6 on RHEL 5 and RHEL 6,
so it needs to be published and maintained separately. If I absolutely
*have* to, I'll publish a "subversion17-1.7.5" to allow parallel
deployment, but it's a lot of work that no one is paying me for, and I
really don't want to go there, the samba and samba3x package RHEL has
used have been really awkward at times.

Also note that, if you use Samba to access your home directory or a
project directory on your Windows boxes, the pupular Subversion
clients such as Subclipse and TortoiseSVN all use version Subversion
1.7, and your working copies will not work in Linux unless you upgrade
that Subversion to version 1.7 as well.

And by the way, Subversoin 1.8 is in the pipeline among the sore
Subversion committers, and that will again not be fully backwards
compatible with Subversoin 1.6 or 1.7, and they're planning on
dropping ongoing support for 1.6 after 1.8 comes out. This is
completely understandable, but it means thatif you want Subversion 1.7
or eventually 1.8, Repoforge will be your best bet to get the more
sophisticated features.
Todd Lyons
2012-06-24 14:54:49 UTC
Permalink
Post by Nico Kadel-Garcia
I've been busy, and was reminded at the SVNday conference in Berlin
recently that the Subversion for RHEL 4 is wildly out of date and
Probably for more than one reason, but the main reason I suspect is
because RHEL 4 was EOL'd in Feb 2012. I know it's a lot of work, but
you should consider migrating up to RHEL 5 or RHEL 6 if you can swing
the time (and the downtime).

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding
Christopher Meng
2012-06-24 23:03:29 UTC
Permalink
Excuse me, if a distribution is eol,should we do backport job for it?
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120625/07816ffd/attachment.html
Nico Kadel-Garcia
2012-06-25 00:58:10 UTC
Permalink
Post by Christopher Meng
Excuse me, if a distribution is eol,should we do backport job for it?
I already did almost all the work, and I'm the person who wrote the
last updates for subversion-1.7.4 at Repoforge. I'd say "yes", in
order to make *my* life easier migrating people off of RHEL 4 while
being able to use compatibly modern versions of the source control
system.

There are commands and directives from Subversion 1.6 that simply
aren't available in the current Subversion 1.1.4 from RHEL 4, or the
Subversion 1.4.x in Repoforge for RHEL 4, especially "svn:externals"
options and "--non-interactive" options. And then there's the
automatic storage of unencrypted passwords for HTTP and HTTPS access
before version 1.6. Any of those factors would, I hope, justify an
upgrade.
Denis Fateyev
2012-06-25 03:25:10 UTC
Permalink
Hello Nico,

By the way, there are some `swig` build issues on build host which I
haven't seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gzfor
example.) Currently, I have no idea what causes those problems
according that fact that it builds fine for me.

And yes, I don't see any 'subversion-1.6' rebuild attempts on Repoforge.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120625/c203b36e/attachment.html
Nico Kadel-Garcia
2012-06-27 03:52:27 UTC
Permalink
Post by Denis Fateyev
Hello Nico,
By the way, there are some `swig` build issues on build host which I haven't
seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gz
for example.) Currently, I have no idea what causes those problems according
that fact that it builds fine for me.
It doesn't look like you're using "mock" to work in a completely clean
build cage. It's kind of important: spare libraries lying around can
create adventures in building complex software, especially software
that creatively tries to discover local component configurations.

Can you try building with my published 1.7.5 tools at
www.github.com/nkadel/ and see if you have the same issues?
Post by Denis Fateyev
And yes, I don't see any 'subversion-1.6' rebuild attempts on Repoforge.
---
wbr, Denis.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users
Denis Fateyev
2012-06-28 19:35:12 UTC
Permalink
Post by Denis Fateyev
Post by Denis Fateyev
Hello Nico,
By the way, there are some `swig` build issues on build host which I
haven't
Post by Denis Fateyev
seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gz
Post by Denis Fateyev
for example.) Currently, I have no idea what causes those problems
according
Post by Denis Fateyev
that fact that it builds fine for me.
It doesn't look like you're using "mock" to work in a completely clean
build cage. It's kind of important: spare libraries lying around can
create adventures in building complex software, especially software
that creatively tries to discover local component configurations.
Can you try building with my published 1.7.5 tools at
www.github.com/nkadel/ and see if you have the same issues?
Here is the thing. There are no problems with `1.7.4` and mock, it builds
just fine under on my machine. I suspect there are some specific things
with this spec and DAR in `el5` environment. Anyway, I am going to update
the repo with `1.7.5` in next few days and we will try to rebuild.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120629/3ccb84f7/attachment.html
Nico Kadel-Garcia
2012-06-29 02:25:16 UTC
Permalink
Post by Denis Fateyev
Here is the thing. There are no problems with `1.7.4` and mock, it builds
just fine under on my machine. I suspect there are some specific things with
this spec and DAR in `el5` environment. Anyway, I am going to update the
repo with `1.7.5` in next few days and we will try to rebuild.
Something that is conceptually odd, and that changed between RHEL 5
and RHEL 6, is the default inclusion of both i386 and x86_64
components when installing packges. The result is sometimes.....
intriguing. "mock" does a pretty god job of *NOT* including spare
libraries for other architectures, but reading thousands of lines of
generated autoconf scripting to figure out which library got
auto-detected and inapropriately loaded for the wrong archtecutre can
be..... burdensome and difficult to address.

Building under "mock" helps avoid this, and is partly why I like it.
Nico Kadel-Garcia
2012-06-29 02:25:16 UTC
Permalink
Post by Denis Fateyev
Here is the thing. There are no problems with `1.7.4` and mock, it builds
just fine under on my machine. I suspect there are some specific things with
this spec and DAR in `el5` environment. Anyway, I am going to update the
repo with `1.7.5` in next few days and we will try to rebuild.
Something that is conceptually odd, and that changed between RHEL 5
and RHEL 6, is the default inclusion of both i386 and x86_64
components when installing packges. The result is sometimes.....
intriguing. "mock" does a pretty god job of *NOT* including spare
libraries for other architectures, but reading thousands of lines of
generated autoconf scripting to figure out which library got
auto-detected and inapropriately loaded for the wrong archtecutre can
be..... burdensome and difficult to address.

Building under "mock" helps avoid this, and is partly why I like it.
Denis Fateyev
2012-06-28 19:35:12 UTC
Permalink
Post by Denis Fateyev
Post by Denis Fateyev
Hello Nico,
By the way, there are some `swig` build issues on build host which I
haven't
Post by Denis Fateyev
seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gz
Post by Denis Fateyev
for example.) Currently, I have no idea what causes those problems
according
Post by Denis Fateyev
that fact that it builds fine for me.
It doesn't look like you're using "mock" to work in a completely clean
build cage. It's kind of important: spare libraries lying around can
create adventures in building complex software, especially software
that creatively tries to discover local component configurations.
Can you try building with my published 1.7.5 tools at
www.github.com/nkadel/ and see if you have the same issues?
Here is the thing. There are no problems with `1.7.4` and mock, it builds
just fine under on my machine. I suspect there are some specific things
with this spec and DAR in `el5` environment. Anyway, I am going to update
the repo with `1.7.5` in next few days and we will try to rebuild.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120629/3ccb84f7/attachment-0002.html>
Nico Kadel-Garcia
2012-06-27 03:52:27 UTC
Permalink
Post by Denis Fateyev
Hello Nico,
By the way, there are some `swig` build issues on build host which I haven't
seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gz
for example.) Currently, I have no idea what causes those problems according
that fact that it builds fine for me.
It doesn't look like you're using "mock" to work in a completely clean
build cage. It's kind of important: spare libraries lying around can
create adventures in building complex software, especially software
that creatively tries to discover local component configurations.

Can you try building with my published 1.7.5 tools at
www.github.com/nkadel/ and see if you have the same issues?
Post by Denis Fateyev
And yes, I don't see any 'subversion-1.6' rebuild attempts on Repoforge.
---
wbr, Denis.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users
David Hrbáč
2012-06-25 09:32:45 UTC
Permalink
Post by Nico Kadel-Garcia
I already did almost all the work, and I'm the person who wrote the
last updates for subversion-1.7.4 at Repoforge. I'd say "yes", in
order to make *my* life easier migrating people off of RHEL 4 while
being able to use compatibly modern versions of the source control
system.
Thanks Nico for your work! I'm going to repeat myself. We are still
supporting EL4 tree even the RHEL4 has been "eoled". There are plenty of
RHEL4 boxes with extended support out there...
David Hrb??
R - elists
2012-06-25 16:44:44 UTC
Permalink
Post by David Hrbáč
Thanks Nico for your work! I'm going to repeat myself. We are
still supporting EL4 tree even the RHEL4 has been "eoled".
There are plenty of
RHEL4 boxes with extended support out there...
David Hrb??
that is correct

thank you DH
R - elists
2012-06-25 16:44:44 UTC
Permalink
Post by David Hrbáč
Thanks Nico for your work! I'm going to repeat myself. We are
still supporting EL4 tree even the RHEL4 has been "eoled".
There are plenty of
RHEL4 boxes with extended support out there...
David Hrb??
that is correct

thank you DH
Denis Fateyev
2012-06-25 03:25:10 UTC
Permalink
Hello Nico,

By the way, there are some `swig` build issues on build host which I
haven't seen on my own build station.
I mean, 1.7.4 under rhel5 (you may have a look at
http://pkgs.repoforge.org/subversion/_buildlogs/subversion-1.7.4-0.1.el5.rfx.i386.ko.log.gzfor
example.) Currently, I have no idea what causes those problems
according that fact that it builds fine for me.

And yes, I don't see any 'subversion-1.6' rebuild attempts on Repoforge.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120625/c203b36e/attachment-0002.html>
David Hrbáč
2012-06-25 09:32:45 UTC
Permalink
Post by Nico Kadel-Garcia
I already did almost all the work, and I'm the person who wrote the
last updates for subversion-1.7.4 at Repoforge. I'd say "yes", in
order to make *my* life easier migrating people off of RHEL 4 while
being able to use compatibly modern versions of the source control
system.
Thanks Nico for your work! I'm going to repeat myself. We are still
supporting EL4 tree even the RHEL4 has been "eoled". There are plenty of
RHEL4 boxes with extended support out there...
David Hrb??
Nico Kadel-Garcia
2012-06-25 00:58:10 UTC
Permalink
Post by Christopher Meng
Excuse me, if a distribution is eol,should we do backport job for it?
I already did almost all the work, and I'm the person who wrote the
last updates for subversion-1.7.4 at Repoforge. I'd say "yes", in
order to make *my* life easier migrating people off of RHEL 4 while
being able to use compatibly modern versions of the source control
system.

There are commands and directives from Subversion 1.6 that simply
aren't available in the current Subversion 1.1.4 from RHEL 4, or the
Subversion 1.4.x in Repoforge for RHEL 4, especially "svn:externals"
options and "--non-interactive" options. And then there's the
automatic storage of unencrypted passwords for HTTP and HTTPS access
before version 1.6. Any of those factors would, I hope, justify an
upgrade.
Christopher Meng
2012-06-24 23:03:29 UTC
Permalink
Excuse me, if a distribution is eol,should we do backport job for it?
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120625/07816ffd/attachment-0002.html>
Nico Kadel-Garcia
2012-06-23 13:23:51 UTC
Permalink
I've been busy, and was reminded at the SVNday conference in Berlin
recently that the Subversion for RHEL 4 is wildly out of date and
incompatible with RHEL 5 and RHEL 6's built-in versions.

My SRPM building toolkits for it are at:

https://github.com/nkadel/subversion-1.6.18-srpm

https://github.com/nkadel/subversion-1.7.5-srpm

The release notes for those vsrsions are at:

http://subversion.apache.org/docs/release-notes/1.6.html

http://subversion.apache.org/docs/release-notes/1.7.html

These work well in my testing on RHEL 4, 5, and 6, on i386 and x86_64.
They don't pass all the "make test" options on RHEL 4 and RHEL 5, but
as near as I can tell, it's because the Python on them is out of date
compared to what the Subversion test suite wants.

Subversion 1.6.18 is compatible with, though somewhat ahead of, the
1.6.11 supported by Red Hat in RHEL 5 and RHEL 6, so it should remain
in the "extras" repository along with Subversion 1.7.5. It provides a
compatible upgrade path for RHEL 4, 5, 6. It lacks some of the newer
features on RHEL 4 and RHEL 5, such as the incompatible Emacs modules,
bash completion, kwallet and gnome-keyring support, and Java utilities
on RHEL 4. Backporting those to RHEL 4 would be insanely difficult
and require upgrading KDE, Gnome, Python, etc., etc., etc. I am not
going there!

The Subversion built into RHEL 4 is 1.1.4, which is amazingly ou of
date and entirely unsupported by the Subversion community. So this is
a really, really useful update, and still a supported code base. In
particular, the syntax and handling of "svn:externals" has changed, so
Subverson projects that use the new syntax really, really, really need
the upgrade.

Subversion 1.7.5 is a major release upgrade, and the working copies it
creates are icompatible with the Subversion 1.6 on RHEL 5 and RHEL 6,
so it needs to be published and maintained separately. If I absolutely
*have* to, I'll publish a "subversion17-1.7.5" to allow parallel
deployment, but it's a lot of work that no one is paying me for, and I
really don't want to go there, the samba and samba3x package RHEL has
used have been really awkward at times.

Also note that, if you use Samba to access your home directory or a
project directory on your Windows boxes, the pupular Subversion
clients such as Subclipse and TortoiseSVN all use version Subversion
1.7, and your working copies will not work in Linux unless you upgrade
that Subversion to version 1.7 as well.

And by the way, Subversoin 1.8 is in the pipeline among the sore
Subversion committers, and that will again not be fully backwards
compatible with Subversoin 1.6 or 1.7, and they're planning on
dropping ongoing support for 1.6 after 1.8 comes out. This is
completely understandable, but it means thatif you want Subversion 1.7
or eventually 1.8, Repoforge will be your best bet to get the more
sophisticated features.
Todd Lyons
2012-06-24 14:54:49 UTC
Permalink
Post by Nico Kadel-Garcia
I've been busy, and was reminded at the SVNday conference in Berlin
recently that the Subversion for RHEL 4 is wildly out of date and
Probably for more than one reason, but the main reason I suspect is
because RHEL 4 was EOL'd in Feb 2012. I know it's a lot of work, but
you should consider migrating up to RHEL 5 or RHEL 6 if you can swing
the time (and the downtime).

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding
Loading...