Discussion:
[users] rpmforge-extras
Nils Breunese (Lemonbit)
2010-11-14 12:17:31 UTC
Permalink
Hello,

Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?

* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:20:52 UTC
Permalink
Hm, it seems that the new repos aren't accessible at the moment:

----
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://fr2.rpmfind.net/linux/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp-stud.fht-esslingen.de/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: rpmforge-extras
failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
----

Nils.
Post by Nils Breunese (Lemonbit)
Hello,
Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?
* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?
Nils._______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
Yury V. Zaytsev
2010-11-14 12:50:56 UTC
Permalink
That's fine. It just has been pushed to the mirrors.
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 12:50:56 UTC
Permalink
That's fine. It just has been pushed to the mirrors.
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 12:50:56 UTC
Permalink
That's fine. It just has been pushed to the mirrors.
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 12:50:56 UTC
Permalink
That's fine. It just has been pushed to the mirrors.
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 12:50:56 UTC
Permalink
That's fine. It just has been pushed to the mirrors.
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 12:50:19 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Today I encountered an rpmforge-release update, which adds the
rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some
announcement somewhere about this change which explains the idea
behind the split?
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
divided into 3 parts:

- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps

It totally makes sense that anything apart from base is disabled by
default.

No announcement has been made so far, because the migration is not
complete as of yet.
Post by Nils Breunese (Lemonbit)
* I noticed that rpmforge-extras repository is not enabled by default
and that the rpmforge-release package is only available in
rpmforge-extras.
This sounds like a metadata builder bug. The package itself is fine.
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.

This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
--
Sincerely yours,
Yury V. Zaytsev
Nils Breunese (Lemonbit)
2010-11-14 13:14:26 UTC
Permalink
Post by Yury V. Zaytsev
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps
It totally makes sense that anything apart from base is disabled by
default.
Sure, cool, I like this.
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an announcement. I just joined this mailinglist today, so I thought I might have missed it, but I couldn't find anything on the website or in the mailinglist archive, so I joined to ask.
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd have to look into that, since that will also mean converting all repositories back to an older Subversion repository format.

Nils.
Dag Wieers
2010-11-14 13:23:04 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an
announcement. I just joined this mailinglist today, so I thought I might
have missed it, but I couldn't find anything on the website or in the
mailinglist archive, so I joined to ask.
In fact the problems you are seeing right now is because of a bug in the
repository metadata creation. It has been resolved, but the issue may
remain for the next 12 to 24 hours. Thank god it's Sunday, people are
resting :-)
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back
from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd
have to look into that, since that will also mean converting all
repositories back to an older Subversion repository format.
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.

Exactly because of the fact we cannot guarantee security-problems are
fixed, they shouldn't be offered by default. If security is very
important, you should stay with rpmforge and not use rpmforge-extras.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Yury V. Zaytsev
2010-11-14 13:30:31 UTC
Permalink
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
--
Sincerely yours,
Yury V. Zaytsev
Dag Wieers
2010-11-14 14:49:07 UTC
Permalink
Post by Yury V. Zaytsev
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
No, you're right. Those packages, in order to be moved to extras, need to
be rebuild with the rfx tag. But the packages being built so far were the
base SPEC files, not the various versions.

They will reappear soon.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 14:49:07 UTC
Permalink
Post by Yury V. Zaytsev
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
No, you're right. Those packages, in order to be moved to extras, need to
be rebuild with the rfx tag. But the packages being built so far were the
base SPEC files, not the various versions.

They will reappear soon.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 14:49:07 UTC
Permalink
Post by Yury V. Zaytsev
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
No, you're right. Those packages, in order to be moved to extras, need to
be rebuild with the rfx tag. But the packages being built so far were the
base SPEC files, not the various versions.

They will reappear soon.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 14:49:07 UTC
Permalink
Post by Yury V. Zaytsev
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
No, you're right. Those packages, in order to be moved to extras, need to
be rebuild with the rfx tag. But the packages being built so far were the
base SPEC files, not the various versions.

They will reappear soon.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 14:49:07 UTC
Permalink
Post by Yury V. Zaytsev
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
No, you're right. Those packages, in order to be moved to extras, need to
be rebuild with the rfx tag. But the packages being built so far were the
base SPEC files, not the various versions.

They will reappear soon.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Yury V. Zaytsev
2010-11-14 13:30:31 UTC
Permalink
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 13:30:31 UTC
Permalink
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 13:30:31 UTC
Permalink
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2010-11-14 13:30:31 UTC
Permalink
Post by Dag Wieers
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.
Dag, I checked out packages.sw.be and there are no 1.4 for EL4 / i386 /
x86_64 packages that I can see. I was always expecting that the packages
should always show up on packages.sw.be regardless to which repository
they belong according to the metadata. Am I wrong?
--
Sincerely yours,
Yury V. Zaytsev
Dag Wieers
2010-11-14 13:23:04 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an
announcement. I just joined this mailinglist today, so I thought I might
have missed it, but I couldn't find anything on the website or in the
mailinglist archive, so I joined to ask.
In fact the problems you are seeing right now is because of a bug in the
repository metadata creation. It has been resolved, but the issue may
remain for the next 12 to 24 hours. Thank god it's Sunday, people are
resting :-)
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back
from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd
have to look into that, since that will also mean converting all
repositories back to an older Subversion repository format.
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.

Exactly because of the fact we cannot guarantee security-problems are
fixed, they shouldn't be offered by default. If security is very
important, you should stay with rpmforge and not use rpmforge-extras.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 13:23:04 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an
announcement. I just joined this mailinglist today, so I thought I might
have missed it, but I couldn't find anything on the website or in the
mailinglist archive, so I joined to ask.
In fact the problems you are seeing right now is because of a bug in the
repository metadata creation. It has been resolved, but the issue may
remain for the next 12 to 24 hours. Thank god it's Sunday, people are
resting :-)
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back
from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd
have to look into that, since that will also mean converting all
repositories back to an older Subversion repository format.
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.

Exactly because of the fact we cannot guarantee security-problems are
fixed, they shouldn't be offered by default. If security is very
important, you should stay with rpmforge and not use rpmforge-extras.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 13:23:04 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an
announcement. I just joined this mailinglist today, so I thought I might
have missed it, but I couldn't find anything on the website or in the
mailinglist archive, so I joined to ask.
In fact the problems you are seeing right now is because of a bug in the
repository metadata creation. It has been resolved, but the issue may
remain for the next 12 to 24 hours. Thank god it's Sunday, people are
resting :-)
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back
from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd
have to look into that, since that will also mean converting all
repositories back to an older Subversion repository format.
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.

Exactly because of the fact we cannot guarantee security-problems are
fixed, they shouldn't be offered by default. If security is very
important, you should stay with rpmforge and not use rpmforge-extras.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Dag Wieers
2010-11-14 13:23:04 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an
announcement. I just joined this mailinglist today, so I thought I might
have missed it, but I couldn't find anything on the website or in the
mailinglist archive, so I joined to ask.
In fact the problems you are seeing right now is because of a bug in the
repository metadata creation. It has been resolved, but the issue may
remain for the next 12 to 24 hours. Thank god it's Sunday, people are
resting :-)
Post by Nils Breunese (Lemonbit)
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back
from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd
have to look into that, since that will also mean converting all
repositories back to an older Subversion repository format.
No, due to the same problem mentioned above, the packages are in the wrong
place (most of them are in the extras repository because of this bug).
Once the mirrors are fixed, they should be available again. However, the
subversion packages replace the original Red Hat packages and will stay in
the extras repository.

Exactly because of the fact we cannot guarantee security-problems are
fixed, they shouldn't be offered by default. If security is very
important, you should stay with rpmforge and not use rpmforge-extras.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Nils Breunese (Lemonbit)
2010-11-14 13:14:26 UTC
Permalink
Post by Yury V. Zaytsev
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps
It totally makes sense that anything apart from base is disabled by
default.
Sure, cool, I like this.
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an announcement. I just joined this mailinglist today, so I thought I might have missed it, but I couldn't find anything on the website or in the mailinglist archive, so I joined to ask.
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd have to look into that, since that will also mean converting all repositories back to an older Subversion repository format.

Nils.
Nils Breunese (Lemonbit)
2010-11-14 13:14:26 UTC
Permalink
Post by Yury V. Zaytsev
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps
It totally makes sense that anything apart from base is disabled by
default.
Sure, cool, I like this.
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an announcement. I just joined this mailinglist today, so I thought I might have missed it, but I couldn't find anything on the website or in the mailinglist archive, so I joined to ask.
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd have to look into that, since that will also mean converting all repositories back to an older Subversion repository format.

Nils.
Nils Breunese (Lemonbit)
2010-11-14 13:14:26 UTC
Permalink
Post by Yury V. Zaytsev
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps
It totally makes sense that anything apart from base is disabled by
default.
Sure, cool, I like this.
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an announcement. I just joined this mailinglist today, so I thought I might have missed it, but I couldn't find anything on the website or in the mailinglist archive, so I joined to ask.
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd have to look into that, since that will also mean converting all repositories back to an older Subversion repository format.

Nils.
Nils Breunese (Lemonbit)
2010-11-14 13:14:26 UTC
Permalink
Post by Yury V. Zaytsev
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps
It totally makes sense that anything apart from base is disabled by
default.
Sure, cool, I like this.
Post by Yury V. Zaytsev
No announcement has been made so far, because the migration is not
complete as of yet.
Since the migration is already impacting users, I expected an announcement. I just joined this mailinglist today, so I thought I might have missed it, but I couldn't find anything on the website or in the mailinglist archive, so I joined to ask.
Post by Yury V. Zaytsev
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.
This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
So a security conscious user's best bet is currently to downgrade back from subversion-1.4.6-0.2.el4.rf to subversion-1.1.4-3.el4_8.2? Hm, I'd have to look into that, since that will also mean converting all repositories back to an older Subversion repository format.

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:17:31 UTC
Permalink
Hello,

Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?

* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:20:52 UTC
Permalink
Hm, it seems that the new repos aren't accessible at the moment:

----
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://fr2.rpmfind.net/linux/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp-stud.fht-esslingen.de/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: rpmforge-extras
failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
----

Nils.
Post by Nils Breunese (Lemonbit)
Hello,
Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?
* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?
Nils._______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
Yury V. Zaytsev
2010-11-14 12:50:19 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Today I encountered an rpmforge-release update, which adds the
rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some
announcement somewhere about this change which explains the idea
behind the split?
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
divided into 3 parts:

- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps

It totally makes sense that anything apart from base is disabled by
default.

No announcement has been made so far, because the migration is not
complete as of yet.
Post by Nils Breunese (Lemonbit)
* I noticed that rpmforge-extras repository is not enabled by default
and that the rpmforge-release package is only available in
rpmforge-extras.
This sounds like a metadata builder bug. The package itself is fine.
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.

This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
--
Sincerely yours,
Yury V. Zaytsev
Nils Breunese (Lemonbit)
2010-11-14 12:17:31 UTC
Permalink
Hello,

Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?

* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:20:52 UTC
Permalink
Hm, it seems that the new repos aren't accessible at the moment:

----
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://fr2.rpmfind.net/linux/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp-stud.fht-esslingen.de/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: rpmforge-extras
failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
----

Nils.
Post by Nils Breunese (Lemonbit)
Hello,
Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?
* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?
Nils._______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
Yury V. Zaytsev
2010-11-14 12:50:19 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Today I encountered an rpmforge-release update, which adds the
rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some
announcement somewhere about this change which explains the idea
behind the split?
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
divided into 3 parts:

- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps

It totally makes sense that anything apart from base is disabled by
default.

No announcement has been made so far, because the migration is not
complete as of yet.
Post by Nils Breunese (Lemonbit)
* I noticed that rpmforge-extras repository is not enabled by default
and that the rpmforge-release package is only available in
rpmforge-extras.
This sounds like a metadata builder bug. The package itself is fine.
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.

This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
--
Sincerely yours,
Yury V. Zaytsev
Nils Breunese (Lemonbit)
2010-11-14 12:17:31 UTC
Permalink
Hello,

Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?

* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:20:52 UTC
Permalink
Hm, it seems that the new repos aren't accessible at the moment:

----
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://fr2.rpmfind.net/linux/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp-stud.fht-esslingen.de/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: rpmforge-extras
failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
----

Nils.
Post by Nils Breunese (Lemonbit)
Hello,
Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?
* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?
Nils._______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
Yury V. Zaytsev
2010-11-14 12:50:19 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Today I encountered an rpmforge-release update, which adds the
rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some
announcement somewhere about this change which explains the idea
behind the split?
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
divided into 3 parts:

- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps

It totally makes sense that anything apart from base is disabled by
default.

No announcement has been made so far, because the migration is not
complete as of yet.
Post by Nils Breunese (Lemonbit)
* I noticed that rpmforge-extras repository is not enabled by default
and that the rpmforge-release package is only available in
rpmforge-extras.
This sounds like a metadata builder bug. The package itself is fine.
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.

This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
--
Sincerely yours,
Yury V. Zaytsev
Nils Breunese (Lemonbit)
2010-11-14 12:17:31 UTC
Permalink
Hello,

Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?

* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?

Nils.
Nils Breunese (Lemonbit)
2010-11-14 12:20:52 UTC
Permalink
Hm, it seems that the new repos aren't accessible at the moment:

----
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://fr2.rpmfind.net/linux/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://apt.sw.be/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp-stud.fht-esslingen.de/dag/redhat/el4/en/i386/extras/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Cannot open/read repomd.xml file for repository: rpmforge-extras
failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from rpmforge-extras: [Errno 256] No more mirrors to try.
----

Nils.
Post by Nils Breunese (Lemonbit)
Hello,
Today I encountered an rpmforge-release update, which adds the rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some announcement somewhere about this change which explains the idea behind the split?
* I noticed that rpmforge-extras repository is not enabled by default and that the rpmforge-release package is only available in rpmforge-extras. This doesn't make sense to me.
* I can't find subversion nor mod_dav_svn in either repository (checked for EL4-i386). Will they be back?
Nils._______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
Yury V. Zaytsev
2010-11-14 12:50:19 UTC
Permalink
Post by Nils Breunese (Lemonbit)
Today I encountered an rpmforge-release update, which adds the
rpmforge-extras repo in /etc/yum.repos.d/rpmforge.repo. Is there some
announcement somewhere about this change which explains the idea
behind the split?
This is the result of ongoing discussions to make RPMForge base-clean
and repoclosure-clean. In the nutshell, the repository is going to be
divided into 3 parts:

- Base repo that doesn't replace base packages
- Extras repo that DOES replace base packages
- Buildsys repo to satisfy build-time base replacing deps

It totally makes sense that anything apart from base is disabled by
default.

No announcement has been made so far, because the migration is not
complete as of yet.
Post by Nils Breunese (Lemonbit)
* I noticed that rpmforge-extras repository is not enabled by default
and that the rpmforge-release package is only available in
rpmforge-extras.
This sounds like a metadata builder bug. The package itself is fine.
Post by Nils Breunese (Lemonbit)
* I can't find subversion nor mod_dav_svn in either repository (checked
for EL4-i386). Will they be back?
Well, the old ones were cleaned already because of CVE's I guess and new
one doesn't build because of illegal macro substitutions + unresolved
ruby deps for ruby bindings.

This can be worked around and the whole package is asking for a revamp,
but I don't have time AND build host to debug it, so hopefully someone
else will take care of this.
--
Sincerely yours,
Yury V. Zaytsev
Loading...