[users] Subversion 1.6.17 srpm tools, for RHEL 4/5/6 compatible 1.6.x releases

[Nico Kadel-Garcia]

RHEL 4 hasn't had a public Subversion update in a long time, and for good
reasons. (It's hard!)

I've taken some of Mike Brauer's work, some Repoforge work, and tied it to
my Fedora 16 backport work I was pursuing before Subversion 1.7 was
released, and come up with.....

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

The tools, not the tarballs, are all present there to build clean SRPM's
and RPM's for Repoforge compatibility.

Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help migrate
*OFF* of RHEL 4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120404/3722aabb/attachment.html

[David Hrbáč]

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

[Nico Kadel-Garcia]

Post by David Hrbáč

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

Thanks, I just fixed that. (Pushed to the wrong upstream).

The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local passwords
in cleartext" feature of 1.6, serious performance upgrades, Unicode log
handling, and it lacks very useful "svn checkout --force" option so useful
to purhing a Subversion working copy onto an existing directory. It also
lacks the new svn:externals syntax, and has fallen so far off the support
tree it makes me weep when I have to use it.

I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set up on
new servers. (I'm actually planning on presenting on that last one at
svnday in Berlin this summer.) A newer Subversoin is also really,
really useful if you have working copies in NFS on RHEL 5 or RHEL 6, and
you'd like to be able to use or manipulate the same working copy on RHEL 4.
*THAT* is really useful for helping migrate off of RHEL 4, which is now
only supported with an "extended" contract, but getting people off of
obsolete operating systems seems to have been a major hobby of mine for....
dang... 24 years.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120405/d6789e9b/attachment.html

[Denis Fateyev]

Hello Nico,

David means whether we really need EL3/4 support nowadays ;)

As for subversion update, there are some requests on version update from
several people, so this question is still actual. Actually, one person has
worked on it recently, but the work hasn't finished for the moment and
there are some issues (you may refer
https://github.com/repoforge/rpms/pull/137 for more details.)

Although I haven't seen your spec yet, I generally think we could use it if
as you say it works just fine.

---
wbr, Denis.

Post by Nico Kadel-Garcia

Post by David Hrbáč

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

Thanks, I just fixed that. (Pushed to the wrong upstream).
The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local passwords
in cleartext" feature of 1.6, serious performance upgrades, Unicode log
handling, and it lacks very useful "svn checkout --force" option so useful
to purhing a Subversion working copy onto an existing directory. It also
lacks the new svn:externals syntax, and has fallen so far off the support
tree it makes me weep when I have to use it.
I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set up on
new servers. (I'm actually planning on presenting on that last one at
svnday in Berlin this summer.) A newer Subversoin is also really,
really useful if you have working copies in NFS on RHEL 5 or RHEL 6, and
you'd like to be able to use or manipulate the same working copy on RHEL 4.
*THAT* is really useful for helping migrate off of RHEL 4, which is now
only supported with an "extended" contract, but getting people off of
obsolete operating systems seems to have been a major hobby of mine for....
dang... 24 years.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120405/52a8c278/attachment.html

[David Hrbáč]

Post by Nico Kadel-Garcia
Thanks, I just fixed that. (Pushed to the wrong upstream).

Nico,
Thanks for clarification. I had been really keen on SVN, but I have
completely switched to git and I'm revelling.

Post by Nico Kadel-Garcia
The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local
passwords in cleartext" feature of 1.6, serious performance upgrades,
Unicode log handling, and it lacks very useful "svn checkout --force"
option so useful to purhing a Subversion working copy onto an existing
directory. It also lacks the new svn:externals syntax, and has fallen
so far off the support tree it makes me weep when I have to use it.
I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set
up on new servers. (I'm actually planning on presenting on that last
one at svnday in Berlin this summer.) A newer Subversoin is also
really, really useful if you have working copies in NFS on RHEL 5 or
RHEL 6, and you'd like to be able to use or manipulate the same
working copy on RHEL 4. *THAT* is really useful for helping migrate
off of RHEL 4, which is now only supported with an "extended"
contract, but getting people off of obsolete operating systems seems
to have been a major hobby of mine for.... dang... 24 years.

Interesting. I have been using a different approach, but I have switched
to etckeer (git inside :o)). Right, I too have a few 4.x boxes and need
to migrate. :o) I will investigate your patches and will try to push to
RF. Are you willing to create pull request?
DH

[Nico Kadel-Garcia]

Post by David Hrbáč

Post by Nico Kadel-Garcia
Thanks, I just fixed that. (Pushed to the wrong upstream).

Nico,
Thanks for clarification. I had been really keen on SVN, but I have
completely switched to git and I'm revelling.

This is understandable. There are some reasons to prefer Subversion: the
excellent TortoiseSVN GUI is really is one of them, and the smaller
learning curve. Many projects with a single centralized server don't need
anything more. I'll restraini my fanboy comments about git: suffice to say
that I prefer its security models.

Post by David Hrbáč
Interesting. I have been using a different approach, but I have switched
to etckeer (git inside :o)). Right, I too have a few 4.x boxes and need
to migrate. :o) I will investigate your patches and will try to push to
RF. Are you willing to create pull request?
DH

I thought I'd already submitted a message: looks like it bounced. (This has
occasionally been happing with my Gmail account to mailing lists: I think
it's some phase lag in SPF updates causing filters to not realize the GMail
MTA is legitimate.)

I'll resubmit.

Post by David Hrbáč
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120406/3a310bd9/attachment.html

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia
I thought I'd already submitted a message: looks like it bounced. (This
has occasionally been happing with my Gmail account to mailing lists: I
think it's some phase lag in SPF updates causing filters to not realize the
GMail MTA is legitimate.)
I'll resubmit.

I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first is
for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120406/b19d116d/attachment.html

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,

Post by Nico Kadel-Garcia
I thought I'd already submitted a message: looks like it bounced. (This
has occasionally been happing with my Gmail account to mailing lists: I
think it's some phase lag in SPF updates causing filters to not realize the
GMail MTA is legitimate.)
I'll resubmit.

I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

I think both releases are workable. If I felt ambitious, I'd rewrite the
1.7.4 to use the same new "_with_" syntax I incorporated to 1.6.17, which
is a lot cleaner, but It's not critical. And I've not personally hammered
the Java or Python or Ruby toolkits: I only got them to build cleanly.
Anyone who uses those toolkits would be very welcome, indeed to hammer them
and test them more effectively than I possibly could. (I'm not expert in
any of those languages)

Post by Denis Fateyev
---
wbr, Denis.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120408/f1c667dd/attachment.html

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev
I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

I haven't got any RHEL3 machines in production, either, so I cannot check
if it works!
In case if it doesn't, we simply preserve the existing spec for RHEL3.

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and specs
content accordingly (to copy from those files to proper ones during build)?

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120408/e4f5275e/attachment.html

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev
I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

I haven't got any RHEL3 machines in production, either, so I cannot check
if it works!
In case if it doesn't, we simply preserve the existing spec for RHEL3.

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and
specs content accordingly (to copy from those files to proper ones during
build)?

I just synchronized them, instead. The differences were small, and harmless
to merge. I also added a ".gitignore" so it wouldn't store the binaries or
tarballs as part of the git repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120410/3e06c8b8/attachment.html

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source
file, and it differs and should probably be renamed if you're going to put
them in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and
specs content accordingly (to copy from those files to proper ones during
build)?

I just synchronized them, instead. The differences were small, and
harmless to merge. I also added a ".gitignore" so it wouldn't store the
binaries or tarballs as part of the git repository.

Ok, thank you, I will look at them as soon as possible (in next few days.)

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120410/e85ad425/attachment.html

[Nico Kadel-Garcia]

Subversion 1.6.18 just came out a few days ago. It has a few minor fixes,
but I had some RHEL 4 compilation issues with my github version of 1.6.17,
so I've updated both and renamed the repo. I'ts now:

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

Please use the updated repo for the next Repoforge Subversion release, it
does a much better job getting the perl widgets into the RHEL 4 version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120414/a1292493/attachment.html

[Denis Fateyev]

Hello Nico,

I have seen the specs, really amazing work! But there are some questions:

1) Wouldn't it be better to synchronize `psvn.el` and `subversion.conf`
files between the releases? I certainly could do it, but I know you can do
it more accurately.

2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.


As for the build procedure itself, seems packages are built nicely in RHEL5
and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

---
wbr, Denis.

Post by Nico Kadel-Garcia
Subversion 1.6.18 just came out a few days ago. It has a few minor fixes,
but I had some RHEL 4 compilation issues with my github version of 1.6.17,
https://github.com/nkadel/subversion-1.6.18-srpm
Please use the updated repo for the next Repoforge Subversion release, it
does a much better job getting the perl widgets into the RHEL 4 version.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120425/d6627d8a/attachment.html

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,
1) Wouldn't it be better to synchronize `psvn.el` and `subversion.conf`
files between the releases? I certainly could do it, but I know you can do
it more accurately.

This seems very reasonable. Let me code review them. psvn.el actually has
an update I may grab.

Post by Denis Fateyev
2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.

That actually came from Fedora 17 testing. Fedora has been renaming a
bunch of utilities with "lib" as a prefix. It makes keeping consistent
compatibilities.... awkward. There are other awkwardnesses, so I can roll
back that change.

Fedora 17 is going to be a very, very painful upgrade for many Repoforge
packages.

Post by Denis Fateyev
As for the build procedure itself, seems packages are built nicely in
RHEL5 and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

I bet you have neon-devel installed. That causes the autoconf to detect the
wrong neon. I've not pursued that, much preferring to use a "mock"
environment to avoid just that sort of library incompatibility.

Hmm. I *could* teach the %setup to check for neon-devel, and exit if
present on RHEL 4. That could be nasty in a system that is used to build
other software....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120424/15e23395/attachment.html

[Denis Fateyev]

Post by Denis Fateyev
2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is

Post by Denis Fateyev
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.

That actually came from Fedora 17 testing. Fedora has been renaming a
bunch of utilities with "lib" as a prefix. It makes keeping consistent
compatibilities.... awkward. There are other awkwardnesses, so I can roll
back that change.
Fedora 17 is going to be a very, very painful upgrade for many Repoforge
packages.

I have no idea regarding RHEL 7 and so on, probably we will have these
issues in the future, who knows. But for current releases I think it would
better have ordinary package names as dependencies. It's more logical.


As for the build procedure itself, seems packages are built nicely in RHEL5

Post by Denis Fateyev

Post by Denis Fateyev
and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

I bet you have neon-devel installed. That causes the autoconf to detect
the wrong neon. I've not pursued that, much preferring to use a "mock"
environment to avoid just that sort of library incompatibility.
Hmm. I *could* teach the %setup to check for neon-devel, and exit if
present on RHEL 4. That could be nasty in a system that is used to build
other software....

I have `neon-devel` installed since I have built the packages under RHEL 5
and 6 x86_64. As I have said before I don't consider it as a serious issue,
because there are no problems with mock for the moment.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120425/917ea378/attachment-0001.html

[Nico Kadel-Garcia]

Denis, the updates you suggested are in place. including:

* Revert the gnome-keyring-devel BuildRequires.
* Update and synchronize psvn.el to current release.
* Update and synchronize subversion.conf to Fedora 17 version, for the
SELinux notes. Leave modules off by default, especially since the
"mod_dontdothat" module is not available for subverson-1.6.x.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120426/66d99c02/attachment.html

[Denis Fateyev]

Specs and patches have been pushed to the main repo.
Also, I have dropped previously existed bunch of deprecated stuff, since
now we have relatively fresh subversion even for old distros (EL4).

I have changed some things related to macros for unification purposes in
specs, and fixed versioning and changelog.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120428/df71bd5a/attachment.html

[Denis Fateyev]

Hello Nico,

I have just synced your subversion repo with Repoforge and bumped the
version to 1.7.6.
Please note you have had wrong upstream URL (Source0).

Still unaware of compatibility with RHEL3/4 since I haven't got any
machines with them installed.

Thanks,

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120830/1b22ff87/attachment-0001.html>
-------------- next part --------------

[Denis Fateyev]

Hello Nico,

Oh, man, I've not yet committed some changes for that. I just started
a new job!!!
...
Cool. The upstream URL has bounced back and forth to several
repositories. Unfortunately, there were some other changes,
particularly handling the new "subversion-tools" package to compile
the "mod_dontdothat" module and handle the not-automatically-installed
/usr/bin/svn-tools components.
I've pushed an update, with an updated release number of 1.7.6-0.3.

No problem, just let me know when I can synchronize all the stuff
(svn-1.7.6, svn-tools, svn2cl, so on.)
As I realize recent changes are untested for now.

Post by Denis Fateyev
Still unaware of compatibility with RHEL3/4 since I haven't got any

machines

Post by Denis Fateyev
with them installed.

RHEL 3 is hopeless, too many required dependencies to resolve. RHEL 4
is.... as good as it's going to get: the newer Python utilites didn't
exist in the RHEL 4 Subversion 1.4.x, and have mixed compatibility
with the seriously outdated Python.

Actually, we would like to have svn-1.6 and svn-1.7 branches working under
RHEL4.. (if possible)

On RHEL5 and above, both branches should be working, it's a mandatory
requirement!

Thanks,

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120831/8af2befc/attachment-0001.html>
-------------- next part --------------

[Denis Fateyev]

Specs and patches have been pushed to the main repo.
Also, I have dropped previously existed bunch of deprecated stuff, since
now we have relatively fresh subversion even for old distros (EL4).

I have changed some things related to macros for unification purposes in
specs, and fixed versioning and changelog.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120428/df71bd5a/attachment-0002.html>

[Nico Kadel-Garcia]

Denis, the updates you suggested are in place. including:

* Revert the gnome-keyring-devel BuildRequires.
* Update and synchronize psvn.el to current release.
* Update and synchronize subversion.conf to Fedora 17 version, for the
SELinux notes. Leave modules off by default, especially since the
"mod_dontdothat" module is not available for subverson-1.6.x.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120426/66d99c02/attachment-0002.html>

[Denis Fateyev]

Post by Denis Fateyev
2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is

Post by Denis Fateyev
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.

That actually came from Fedora 17 testing. Fedora has been renaming a
bunch of utilities with "lib" as a prefix. It makes keeping consistent
compatibilities.... awkward. There are other awkwardnesses, so I can roll
back that change.
Fedora 17 is going to be a very, very painful upgrade for many Repoforge
packages.

I have no idea regarding RHEL 7 and so on, probably we will have these
issues in the future, who knows. But for current releases I think it would
better have ordinary package names as dependencies. It's more logical.


As for the build procedure itself, seems packages are built nicely in RHEL5

Post by Denis Fateyev

Post by Denis Fateyev
and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

I bet you have neon-devel installed. That causes the autoconf to detect
the wrong neon. I've not pursued that, much preferring to use a "mock"
environment to avoid just that sort of library incompatibility.
Hmm. I *could* teach the %setup to check for neon-devel, and exit if
present on RHEL 4. That could be nasty in a system that is used to build
other software....

I have `neon-devel` installed since I have built the packages under RHEL 5
and 6 x86_64. As I have said before I don't consider it as a serious issue,
because there are no problems with mock for the moment.

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120425/917ea378/attachment-0002.html>

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,
1) Wouldn't it be better to synchronize `psvn.el` and `subversion.conf`
files between the releases? I certainly could do it, but I know you can do
it more accurately.

This seems very reasonable. Let me code review them. psvn.el actually has
an update I may grab.

Post by Denis Fateyev
2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.

That actually came from Fedora 17 testing. Fedora has been renaming a
bunch of utilities with "lib" as a prefix. It makes keeping consistent
compatibilities.... awkward. There are other awkwardnesses, so I can roll
back that change.

Fedora 17 is going to be a very, very painful upgrade for many Repoforge
packages.

Post by Denis Fateyev
As for the build procedure itself, seems packages are built nicely in
RHEL5 and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

I bet you have neon-devel installed. That causes the autoconf to detect the
wrong neon. I've not pursued that, much preferring to use a "mock"
environment to avoid just that sort of library incompatibility.

Hmm. I *could* teach the %setup to check for neon-devel, and exit if
present on RHEL 4. That could be nasty in a system that is used to build
other software....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120424/15e23395/attachment-0002.html>

[Denis Fateyev]

Hello Nico,

I have seen the specs, really amazing work! But there are some questions:

1) Wouldn't it be better to synchronize `psvn.el` and `subversion.conf`
files between the releases? I certainly could do it, but I know you can do
it more accurately.

2) I doubt that the trick with `gnome-keyring.h` in `BuildRequires` is
really needed. The package called the same in both releases, actually
`gnome-keyring-devel`.


As for the build procedure itself, seems packages are built nicely in RHEL5
and RHEL6 under mock, but I have experienced some unexpected multilib
issues with static build (pure and simple `rpmbuild`.) Since mock works
fine it cannot be considered as a problem unless DAR uses the same technic
(I haven't checked it though.)

---
wbr, Denis.

Post by Nico Kadel-Garcia
Subversion 1.6.18 just came out a few days ago. It has a few minor fixes,
but I had some RHEL 4 compilation issues with my github version of 1.6.17,
https://github.com/nkadel/subversion-1.6.18-srpm
Please use the updated repo for the next Repoforge Subversion release, it
does a much better job getting the perl widgets into the RHEL 4 version.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120425/d6627d8a/attachment-0002.html>

[Nico Kadel-Garcia]

Subversion 1.6.18 just came out a few days ago. It has a few minor fixes,
but I had some RHEL 4 compilation issues with my github version of 1.6.17,
so I've updated both and renamed the repo. I'ts now:

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

Please use the updated repo for the next Repoforge Subversion release, it
does a much better job getting the perl widgets into the RHEL 4 version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120414/a1292493/attachment-0002.html>

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source
file, and it differs and should probably be renamed if you're going to put
them in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and
specs content accordingly (to copy from those files to proper ones during
build)?

I just synchronized them, instead. The differences were small, and
harmless to merge. I also added a ".gitignore" so it wouldn't store the
binaries or tarballs as part of the git repository.

Ok, thank you, I will look at them as soon as possible (in next few days.)

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120410/e85ad425/attachment-0002.html>

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev
I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

I haven't got any RHEL3 machines in production, either, so I cannot check
if it works!
In case if it doesn't, we simply preserve the existing spec for RHEL3.

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and
specs content accordingly (to copy from those files to proper ones during
build)?

I just synchronized them, instead. The differences were small, and harmless
to merge. I also added a ".gitignore" so it wouldn't store the binaries or
tarballs as part of the git repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120410/3e06c8b8/attachment-0002.html>

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia

Post by Denis Fateyev
I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

I haven't got any RHEL3 machines in production, either, so I cannot check
if it works!
In case if it doesn't, we simply preserve the existing spec for RHEL3.

Post by Nico Kadel-Garcia
Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

Could you please alter filenames like "filter_requires_1.6.17.sh" and specs
content accordingly (to copy from those files to proper ones during build)?

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120408/e4f5275e/attachment-0002.html>

[Nico Kadel-Garcia]

Post by Denis Fateyev
Hello Nico,

Post by Nico Kadel-Garcia
I thought I'd already submitted a message: looks like it bounced. (This
has occasionally been happing with my Gmail account to mailing lists: I
think it's some phase lag in SPF updates causing filters to not realize the
GMail MTA is legitimate.)
I'll resubmit.

I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first
is for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)
If you can get 1.6.17 to compile for RHEL 3, I'm going to be really,

really surprised. I don't even have a test environment for that. If it
works, *great*.

Note that both 1.6.17 and 1.7.4 have a "filter-requires.sh" source file,
and it differs and should probably be renamed if you're going to put them
in the same directory.

I think both releases are workable. If I felt ambitious, I'd rewrite the
1.7.4 to use the same new "_with_" syntax I incorporated to 1.6.17, which
is a lot cleaner, but It's not critical. And I've not personally hammered
the Java or Python or Ruby toolkits: I only got them to build cleanly.
Anyone who uses those toolkits would be very welcome, indeed to hammer them
and test them more effectively than I possibly could. (I'm not expert in
any of those languages)

Post by Denis Fateyev
---
wbr, Denis.
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120408/f1c667dd/attachment-0002.html>

[Denis Fateyev]

Hello Nico,

Post by Nico Kadel-Garcia
I thought I'd already submitted a message: looks like it bounced. (This
has occasionally been happing with my Gmail account to mailing lists: I
think it's some phase lag in SPF updates causing filters to not realize the
GMail MTA is legitimate.)
I'll resubmit.

I'm planning to integrate your 1.6.17 and 1.7.4 versions both (the first is
for RHEL3/4 and the second is for using with newer RHELs), preliminarily
flushing subversion directory in the repo from all outdated specs and
patches. Are your subversion repos ready for the final integration? ;)

---
wbr, Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120406/b19d116d/attachment-0002.html>

[Nico Kadel-Garcia]

Post by David Hrbáč

Post by Nico Kadel-Garcia
Thanks, I just fixed that. (Pushed to the wrong upstream).

Nico,
Thanks for clarification. I had been really keen on SVN, but I have
completely switched to git and I'm revelling.

This is understandable. There are some reasons to prefer Subversion: the
excellent TortoiseSVN GUI is really is one of them, and the smaller
learning curve. Many projects with a single centralized server don't need
anything more. I'll restraini my fanboy comments about git: suffice to say
that I prefer its security models.

Post by David Hrbáč
Interesting. I have been using a different approach, but I have switched
to etckeer (git inside :o)). Right, I too have a few 4.x boxes and need
to migrate. :o) I will investigate your patches and will try to push to
RF. Are you willing to create pull request?
DH

I thought I'd already submitted a message: looks like it bounced. (This has
occasionally been happing with my Gmail account to mailing lists: I think
it's some phase lag in SPF updates causing filters to not realize the GMail
MTA is legitimate.)

I'll resubmit.

Post by David Hrbáč
_______________________________________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120406/3a310bd9/attachment-0002.html>

[Denis Fateyev]

Hello Nico,

David means whether we really need EL3/4 support nowadays ;)

As for subversion update, there are some requests on version update from
several people, so this question is still actual. Actually, one person has
worked on it recently, but the work hasn't finished for the moment and
there are some issues (you may refer
https://github.com/repoforge/rpms/pull/137 for more details.)

Although I haven't seen your spec yet, I generally think we could use it if
as you say it works just fine.

---
wbr, Denis.

Post by Nico Kadel-Garcia

Post by David Hrbáč

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

Thanks, I just fixed that. (Pushed to the wrong upstream).
The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local passwords
in cleartext" feature of 1.6, serious performance upgrades, Unicode log
handling, and it lacks very useful "svn checkout --force" option so useful
to purhing a Subversion working copy onto an existing directory. It also
lacks the new svn:externals syntax, and has fallen so far off the support
tree it makes me weep when I have to use it.
I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set up on
new servers. (I'm actually planning on presenting on that last one at
svnday in Berlin this summer.) A newer Subversoin is also really,
really useful if you have working copies in NFS on RHEL 5 or RHEL 6, and
you'd like to be able to use or manipulate the same working copy on RHEL 4.
*THAT* is really useful for helping migrate off of RHEL 4, which is now
only supported with an "extended" contract, but getting people off of
obsolete operating systems seems to have been a major hobby of mine for....
dang... 24 years.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120405/52a8c278/attachment-0002.html>

[David Hrbáč]

Post by Nico Kadel-Garcia
Thanks, I just fixed that. (Pushed to the wrong upstream).

Nico,
Thanks for clarification. I had been really keen on SVN, but I have
completely switched to git and I'm revelling.

Post by Nico Kadel-Garcia
The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local
passwords in cleartext" feature of 1.6, serious performance upgrades,
Unicode log handling, and it lacks very useful "svn checkout --force"
option so useful to purhing a Subversion working copy onto an existing
directory. It also lacks the new svn:externals syntax, and has fallen
so far off the support tree it makes me weep when I have to use it.
I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set
up on new servers. (I'm actually planning on presenting on that last
one at svnday in Berlin this summer.) A newer Subversoin is also
really, really useful if you have working copies in NFS on RHEL 5 or
RHEL 6, and you'd like to be able to use or manipulate the same
working copy on RHEL 4. *THAT* is really useful for helping migrate
off of RHEL 4, which is now only supported with an "extended"
contract, but getting people off of obsolete operating systems seems
to have been a major hobby of mine for.... dang... 24 years.

Interesting. I have been using a different approach, but I have switched
to etckeer (git inside :o)). Right, I too have a few 4.x boxes and need
to migrate. :o) I will investigate your patches and will try to push to
RF. Are you willing to create pull request?
DH

[Nico Kadel-Garcia]

Post by David Hrbáč

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

Thanks, I just fixed that. (Pushed to the wrong upstream).

The last Red Hat published subversion for RHEL 4 was 1.1.4. That lacks
really important features, such as the "ask before storing local passwords
in cleartext" feature of 1.6, serious performance upgrades, Unicode log
handling, and it lacks very useful "svn checkout --force" option so useful
to purhing a Subversion working copy onto an existing directory. It also
lacks the new svn:externals syntax, and has fallen so far off the support
tree it makes me weep when I have to use it.

I use the "svn checkout --force" option for things like Nagios
configurations, yum configuraitons, and BIND with chroot cages to set up on
new servers. (I'm actually planning on presenting on that last one at
svnday in Berlin this summer.) A newer Subversoin is also really,
really useful if you have working copies in NFS on RHEL 5 or RHEL 6, and
you'd like to be able to use or manipulate the same working copy on RHEL 4.
*THAT* is really useful for helping migrate off of RHEL 4, which is now
only supported with an "extended" contract, but getting people off of
obsolete operating systems seems to have been a major hobby of mine for....
dang... 24 years.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120405/d6789e9b/attachment-0002.html>

[Erik Wasser]

Post by Nico Kadel-Garcia
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Maybe I'm missing here something but why is it so hard to migrate *OFF*
RHEL 4? Why do you need a new subversion on an old computer?

Isn't setting up a new (temporary) computer with a current subversion
and copying via rsync enough?

[Nico Kadel-Garcia]

RHEL 4 hasn't had a public Subversion update in a long time, and for good
reasons. (It's hard!)

I've taken some of Mike Brauer's work, some Repoforge work, and tied it to
my Fedora 16 backport work I was pursuing before Subversion 1.7 was
released, and come up with.....

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

The tools, not the tarballs, are all present there to build clean SRPM's
and RPM's for Repoforge compatibility.

Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help migrate
*OFF* of RHEL 4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120404/3722aabb/attachment-0002.html>

[David Hrbáč]

Post by Nico Kadel-Garcia
RHEL 4 hasn't had a public Subversion update in a long time, and for
good reasons. (It's hard!)
I've taken some of Mike Brauer's work, some Repoforge work, and tied
it to my Fedora 16 backport work I was pursuing before Subversion 1.7
was released, and come up with.....
https://github.com/nkadel/subversion-1.6.17-srpm
The tools, not the tarballs, are all present there to build clean
SRPM's and RPM's for Repoforge compatibility.
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Nico,
Maybe I don't just get it right. I guess we can stop to support EL3/EL4.
Are there any issues with the old version? BTW repo seems to be empty.
DH

[Erik Wasser]

Post by Nico Kadel-Garcia
Enjoy, and let me know if I can help get it into Repoforge. It's
particularly helpful for people who want a clean Subverrion to help
migrate *OFF* of RHEL 4.

Maybe I'm missing here something but why is it so hard to migrate *OFF*
RHEL 4? Why do you need a new subversion on an old computer?

Isn't setting up a new (temporary) computer with a current subversion
and copying via rsync enough?