[users] Why RepoForge RpmForge not available?

[Бекренев Дмитрий]

Hi there!

I'm can't download
http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
repositiory not available.
why?
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130921/dfe8ba73/attachment.html>

[Nicolas Thierry-Mieg]

Post by Бекренев Дмитрий
Hi there!
I'm can't download
http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
repositiory not available.
why?

that machine seems down? but the file is there on the repo mirrors, eg:
http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
http://mirrors.ircam.fr/pub/dag/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

However you should know that the RF project is in a bit of a crisis,
although David H.'s recent email gives some hope. I definitely wouldn't
set up a new machine with RF as main 3rd party repo... Check the list
archives.

[Nico Kadel-Garcia]

Bit of a crisis? Anything that can be done from here? I'd be curious to see
any available data on what's going on. I can easily believe that Dag's
become too busy with the rest of his life to continue this resource, but
hate losing the "rpmforge-extras" repository with components that are more
recent versions of packages already in Red Hat based systems.

I'd even be interested in getting my samba-4.x toolchain into hit, although
that one's riskier than most to be publishing that way.


On Sat, Sep 21, 2013 at 5:12 AM, Nicolas Thierry-Mieg <

Post by Бекренев Дмитрий
Hi there!
I'm can't download
http://pkgs.repoforge.org/**rpmforge-release/rpmforge-**
release-0.5.3-1.el6.rf.x86_64.**rpm<http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm>
repositiory not available.
why?

http://apt.sw.be/redhat/el6/**en/x86_64/rpmforge/RPMS/**
rpmforge-release-0.5.3-1.el6.**rf.x86_64.rpm<http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm>
http://mirrors.ircam.fr/pub/**dag/redhat/el6/en/x86_64/**
rpmforge/RPMS/rpmforge-**release-0.5.3-1.el6.rf.x86_64.**rpm<http://mirrors.ircam.fr/pub/dag/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm>
However you should know that the RF project is in a bit of a crisis,
although David H.'s recent email gives some hope. I definitely wouldn't set
up a new machine with RF as main 3rd party repo... Check the list archives.
______________________________**_________________
users mailing list
users at lists.repoforge.org
http://lists.repoforge.org/**mailman/listinfo/users<http://lists.repoforge.org/mailman/listinfo/users>

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

[David Hrbáč]

Post by Nico Kadel-Garcia
Bit of a crisis? Anything that can be done from here? I'd be curious
to see any available data on what's going on. I can easily believe
that Dag's become too busy with the rest of his life to continue this
resource, but hate losing the "rpmforge-extras" repository with
components that are more recent versions of packages already in Red
Hat based systems.

Yes, we are in the crisis, definitely. No updates for 5-6 months. Where
are the updates? I dare to say Dag does not care about RepoForge. But
this reminds me those days, when Dag left CentOS project. I can recall
his points and it seems to me, that Dag's repo is at the very same state
as CentOS was at that time...

That's why I have created repoforge-updates repository, just to handle
the commits we have in our Git repository. See
http://lists.repoforge.org/pipermail/users/2013-September/029387.html

Regards,
David Hrb??

Post by Nico Kadel-Garcia
I'd even be interested in getting my samba-4.x toolchain into hit,
although that one's riskier than most to be publishing that way.

[John R. Dennison]

Post by David Hrbáč
Yes, we are in the crisis, definitely. No updates for 5-6 months. Where
are the updates? I dare to say Dag does not care about RepoForge. But
this reminds me those days, when Dag left CentOS project. I can recall
his points and it seems to me, that Dag's repo is at the very same state
as CentOS was at that time...

There is one little point about this that bears mentioning. CentOS
was still functional at many levels at that time; the same can not be
said for rpmforge.

Post by David Hrbáč
That's why I have created repoforge-updates repository, just to handle
the commits we have in our Git repository. See
http://lists.repoforge.org/pipermail/users/2013-September/029387.html

And while I commend you for this, this is a small little band-aide on a
gaping wound that is spilling its lifeblood on the sand.

It would be wonderful if Dag would have the guts to comment on any of
the multiple threads referencing his complete inattention to his own
project. Everything is excuses from others; he maintains his ridiculous
silence. And yet he's still seen posting elsewhere on the net. It's
truly pathetic. The least he could do is turn everything over to
someone that still cares and just walk away; just like he walked out on
the CentOS projects a few years back. He wasn't missed then; he won't
be missed now, either. The only reason he is still relevant is his
complete public silence on the issue.

I'm sorry if this comes across harsh, but it's the truth, whether anyone
else is blunt enough to call him on this in public or not.





John
--
When you've driven race cars, and when you've jumped out of airplanes, cars
are on fire, when you've been upside down at two hundred miles per hour
waiting for your head to hit the ground, when you've been in Africa with a
wounded Cape buffalo six feet in front of you, chargin' ya, I'll let
someone else decide what the most dangerous thing I've ever done is.

-- Carroll Shelby (11 January 1912 - 10 May 2012)
American automotive designer, racing driver, and entrepreneur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130922/5591c299/attachment.sig>

[Always Learning]

This post might be inappropriate. Click to display it.

[David Hrbáč]

Post by Nicolas Thierry-Mieg
However you should know that the RF project is in a bit of a crisis,
although David H.'s recent email gives some hope. I definitely
wouldn't set up a new machine with RF as main 3rd party repo... Check
the list archives.

Well, I definetely would. There's no other repo like RepoForge...

DH

[John R. Dennison]

Post by David Hrbáč
Well, I definetely would. There's no other repo like RepoForge...

I couldn't agree more. Every other repo puts out updates.




John
--
What lies behind us and what lies before us are tiny matters compared to
what lies within us.
-- Ralph Waldo Emerson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130922/d6c6882f/attachment.sig>

[David Hrbáč]

Post by Бекренев Дмитрий
Hi there!
I'm can't download
http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
repositiory not available.
why?

Dmitrij,

I can see that it works... Site pkgs.repoforge.org is meant as a package
source. It's not being provided in high availability mode. As suggested
by others you can always use a mirror site. See
http://mirrorlist.repoforge.org/

This small piece of code might be useful to you:

BASEARCH=$(uname -i);
RELEASE=$(cat /etc/redhat-release | sed -rn '/(Final|release)/s/^[^0-9]*|[^0-9.]*$//gp' | sed -e 's/[.].*//');
yum -y install wget;
rpm -Uhv http://pkgs.repoforge.org/rpmforge-release/$(wget -qO - http://pkgs.repoforge.org/rpmforge-release/ | grep rpmforge-release| grep $BASEARCH | grep el$RELEASE | sort | tail -n1 | sed 's%.*>\(rpmforge\-release\-.*.rpm\)<.*%\1%');

Regards,
David Hrb??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130922/72056eb6/attachment.html>

[Dag Wieers]

Post by Бекренев Дмитрий
I'm can't download
http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
repositiory not available.
why?

One of both disks in the RAID1 setup was broken (completely unresponsive).
We had to shut down the system to have the hosting facility replace it.

During the resync of the disks we encountered I/O errors on the second
disk as well, which delayed recovery but thanks to a nice blog-post
(http://www.sj-vs.net/forcing-a-hard-disk-to-reallocate-bad-sectors/) we
could finish the resync during the weekend and bring the system back.

We will have to shut down the system again to get the second disk
replaced eventually though :-/ Guess we've been lucky the second disk was
recoverably to some point though.

PS Thanks to Bert de Bruijn for covering during my absence (family duty).

[Nico Kadel-Garcia]

I'm glad you were able to recover the system's data. I'll restrain the
lecture about "backup needs to be on a different architecture, because
similar systems often fail at the same time".

Do you have the facilities, even offsite facilities, to do "rsnapshot"
based or other snapshot capable storage systems?

I'm can't download http://pkgs.repoforge.org/**rpmforge-release/rpmforge-

**release-0.5.3-1.el6.rf.x86_64.**rpm<http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm>
repositiory not available.
why?

One of both disks in the RAID1 setup was broken (completely unresponsive).
We had to shut down the system to have the hosting facility replace it.
During the resync of the disks we encountered I/O errors on the second
disk as well, which delayed recovery but thanks to a nice blog-post (
http://www.sj-vs.net/forcing-**a-hard-disk-to-reallocate-bad-**sectors/<http://www.sj-vs.net/forcing-a-hard-disk-to-reallocate-bad-sectors/>)
we could finish the resync during the weekend and bring the system back.
We will have to shut down the system again to get the second disk replaced
eventually though :-/ Guess we've been lucky the second disk was
recoverably to some point though.
PS Thanks to Bert de Bruijn for covering during my absence (family duty).
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, contact at dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
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/20130922/42203e9b/attachment.html>

[Dag Wieers]

Post by Nico Kadel-Garcia
I'm glad you were able to recover the system's data. I'll restrain the
lecture about "backup needs to be on a different architecture, because
similar systems often fail at the same time".
Do you have the facilities, even offsite facilities, to do "rsnapshot"
based or other snapshot capable storage systems?

Everything on this system is both on the original system at home, as well
as on most of the mirrors. It's just that restoring from backup in this
case would be more effort than simply recovering from the second disk.

BTW The monitoring just notified that now the second disk is completely
dead. Must have been the same production batch...

[Nico Kadel-Garcia]

Post by Dag Wieers
Everything on this system is both on the original system at home, as well

as on most of the mirrors. It's just that restoring from backup in this
case would be more effort than simply recovering from the second disk.

Cool. Nice to see that you've thought ahead.

Post by Dag Wieers
BTW The monitoring just notified that now the second disk is completely

dead. Must have been the same production batch...

Ouch. You've my sympathies. I had Terabyte arrays of the cheap IBM Deskstar
drives, referred to as "Deathstar" drives due to a shared manufacturing
flaw, go toes up, one drive after another, before the RAID 5 arrays could
recover from the first failures. There's more to that story, but it
requires beer to tell these days.

Let us know if there's anything we can do to help out, or help get package
updates flowing into RPMforge again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130923/269273a2/attachment.html>

[Ljubomir Ljubojevic]

Post by Dag Wieers
BTW The monitoring just notified that now the second disk is

completely dead. Must have been the same production batch...
Ouch. You've my sympathies. I had Terabyte arrays of the cheap IBM
Deskstar drives, referred to as "Deathstar" drives due to a shared
manufacturing flaw, go toes up, one drive after another, before the
RAID 5 arrays could recover from the first failures. There's more to
that story, but it requires beer to tell these days.
Let us know if there's anything we can do to help out, or help get
package updates flowing into RPMforge again.

I avoid creating RAIDs with same HDDs. I always choose different
manufacturers, so I avoid that serial die-out.

Ljubomir

[Dag Wieers]

Post by Nico Kadel-Garcia
Let us know if there's anything we can do to help out, or help get package
updates flowing into RPMforge again.

It was discussed off-list a few times over the past 3 years. I don't mind
someone else continuing the repository. My only concern is that signing
with my key (my name is related to that key) is not an option to me if I
didn't build and verified the build myself.

So if the builds move to someone else (or more than one person), it should
be signed with a different key. At first I didn't want this change to be
something that happened automatically (as changing trust is something that
should be a decision).

But since the situation is now probably worse than if David would be
updating the packages, I am fine with simply making the RPM print a
message if it moves from the old key to newer keys. So people are aware
that this change has taken place.

So for me the only thing that I am needed for to make this change happen:

- Sign the new rpmforge-release package with my key, which includes
David's key (or a project key ?)

(- And paying for the infrastructure ;-))

David already has access to the main mirror afaik, so in theory he could
push new packages directly to the main mirror, but without the key being
distributed in advance this obviously makes no sense.

BTW In the past the PPC builds were signed exclusively by Fabian, and the
Fedora/Aurora builds were signed exclusively by Dries. So we already
allowed some people to sign RPMs, but it was strictly for different
architectures/releases. We never mixed signing keys for a single
repository, so you trusted only one person who was responsible for the
build.

For me that was always very important, because if you install an RPM
package, you basically trust your complete system to the person that
created the package ! I have earned that trust by a lot of people, and I
probably broke that trust by failing to build these updates.

Although I never promised to keep doing this indefinitely, I also never
decided to stop doing it, it just happened slowly. Because of many things
happening around the same time: CentOS burnout, two kids, house
renovations, freelancing, ... And I don't feel good about this situation
either, trust me.

[David Hrbáč]

Post by Dag Wieers
It was discussed off-list a few times over the past 3 years. I don't
mind someone else continuing the repository. My only concern is that
signing with my key (my name is related to that key) is not an option
to me if I didn't build and verified the build myself.

Yes, that's true. We have almost everything available to community, but
the build and sign process. I can't sign with your key. What more I DO
not want to. All the credits to you Dag. You did wonderful job for very
long time. I'm to help not to bring you down...

Post by Dag Wieers
So if the builds move to someone else (or more than one person), it
should be signed with a different key. At first I didn't want this
change to be something that happened automatically (as changing trust
is something that should be a decision).
But since the situation is now probably worse than if David would be
updating the packages, I am fine with simply making the RPM print a
message if it moves from the old key to newer keys. So people are
aware that this change has taken place.
- Sign the new rpmforge-release package with my key, which includes
David's key (or a project key ?)

Packages are signed with my key because I have had the whole infra
already. I do not want to have packages signed with your key nor
someone's else. Packages must be signed with the project key. This is
something I'm planning to have.

Post by Dag Wieers
(- And paying for the infrastructure ;-))

No, no one wants you to pay for the infra. I can provide the infra free
of charge, plenty of HW.... We do not need a lot of boxes, I guess
something about 5 VMs. We have a fair amout of mirrors all over the world.

Post by Dag Wieers
David already has access to the main mirror afaik, so in theory he
could push new packages directly to the main mirror, but without the
key being distributed in advance this obviously makes no sense.

This is something I did not want to happen. That's why my sidestep with
the updates repo...

Post by Dag Wieers
BTW In the past the PPC builds were signed exclusively by Fabian, and
the Fedora/Aurora builds were signed exclusively by Dries. So we
already allowed some people to sign RPMs, but it was strictly for
different architectures/releases. We never mixed signing keys for a
single repository, so you trusted only one person who was responsible
for the build.
For me that was always very important, because if you install an RPM
package, you basically trust your complete system to the person that
created the package ! I have earned that trust by a lot of people, and
I probably broke that trust by failing to build these updates.

Right, take the end user point of view... Six months without the
updates. Damn the updates, I do not care about the bleading edge, but
there are packages with security wholes... This is the point of the
missing updates...

Post by Dag Wieers
Although I never promised to keep doing this indefinitely, I also
never decided to stop doing it, it just happened slowly. Because of
many things happening around the same time: CentOS burnout, two kids,
house renovations, freelancing, ... And I don't feel good about this
situation either, trust me.

Dag, I'm the very last to blame you.

Thanks,
DH

[Nico Kadel-Garcia]

Dag, would it make any sense to step back from most of the packages? Many
of them, such as Nagios and its plugins, are effectively available from
EPEL now. There are some in rpmfoge-extras that would update existing RHEL
packages, such as subversion, that EPEL would never touch, and those have
been really helpful to me, at least.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130923/96d8a570/attachment.html>

[David Hrbáč]

Post by Nico Kadel-Garcia
Dag, would it make any sense to step back from most of the packages?
Many of them, such as Nagios and its plugins, are effectively
available from EPEL now. There are some in rpmfoge-extras that would
update existing RHEL packages, such as subversion, that EPEL would
never touch, and those have been really helpful to me, at least.

Nico,

Right now we can't cooperate with Epel. Historically we can't recommend
to use both repos at the same time. These repos are not compatible with
each other.

It makes sense to me to step back from some packages. We have plenty of
old packages.

BTW I guess we are heading a lot of work with RHEL7. It seems that RHEL
is going to be equipped with systemd. So, it may even lead into changes
with out Git repo....

Regards,
DH

[Christopher Meng]

Post by David Hrbáč
Nico,
Right now we can't cooperate with Epel. Historically we can't recommend
to use both repos at the same time. These repos are not compatible with
each other.

But in fact you can't keep your repo updated. You can package more and
more packages if you want, however as you can see many packages are
ancient("old" is not enough to describe their status). No updates, no
news, now even the repo is broken, too.

EPEL may not the best, but it contains more pkgs, more packagers. IMO
it would be better to be compatible with EPEL, but I think Dag may
never agree with this.

I won't suggest my friends using repoforge anymore if rf still goes
like current.

[Mark D. Nagel]

Dag, would it make any sense to step back from most of the packages? Many of them, such
as Nagios and its plugins, are effectively available from EPEL now. There are some in
rpmfoge-extras that would update existing RHEL packages, such as subversion, that EPEL
would never touch, and those have been really helpful to me, at least.

EPEL for EL5 still only has Nagios 2.x -- not sure this is a good example.

Regards,
Mark

[Always Learning]

I don't mind someone else continuing the repository.

Geachte Dag of beste Dag,

Personally I think you are a hero. You have been instrumental in
establishing a much respected and very comprehensive repo. It is my
favourite repo.

Rather than call it repoforge, I would happily call it 'dag'. Echt
waar !

Please do not feel sad or awkward about getting 'burn-out'. It happens
to many of us. It is a consequence of too much work, and it gets worse
as we age.

Despite being a wonderful helpful inspiration to many people all around
the world, you are still a Human Being with work life and family life
responsibilities. At times, all the different tasks and demands for your
limited time can induce extreme overload.

I am happy you have responded to our concerns. Despite the repo being a
bit out-of-date (b.v. clam) I didn't want to go to EPEL because I hoped
that you, working with people like David and others, would rescue your
wonderful repo. I'm an optimist :-)

So you are still my hero. I remain very grateful for the work you and
everyone else connected to the repo have done, and are going, for the
benefit of very appreciative users all around the world. Your repo
makes our non-Micro$oft lives better and nicer. We need your repo. It is
too important and too valuable to loose.

With sincere good wishes and many thanks (of met beste wensen en
hartstikke bedankt)


Paul.
England, EU.

[Rob Kampen]

Post by Always Learning

I don't mind someone else continuing the repository.

Geachte Dag of beste Dag,
Personally I think you are a hero. You have been instrumental in
establishing a much respected and very comprehensive repo. It is my
favourite repo.
Rather than call it repoforge, I would happily call it 'dag'. Echt
waar !
Please do not feel sad or awkward about getting 'burn-out'. It happens
to many of us. It is a consequence of too much work, and it gets worse
as we age.
Despite being a wonderful helpful inspiration to many people all around
the world, you are still a Human Being with work life and family life
responsibilities. At times, all the different tasks and demands for your
limited time can induce extreme overload.
I am happy you have responded to our concerns. Despite the repo being a
bit out-of-date (b.v. clam) I didn't want to go to EPEL because I hoped
that you, working with people like David and others, would rescue your
wonderful repo. I'm an optimist :-)
So you are still my hero. I remain very grateful for the work you and
everyone else connected to the repo have done, and are going, for the
benefit of very appreciative users all around the world. Your repo
makes our non-Micro$oft lives better and nicer. We need your repo. It is
too important and too valuable to loose.
With sincere good wishes and many thanks (of met beste wensen en
hartstikke bedankt)
Paul.
England, EU.
+1 - Well put Paul, you have captured and expressed our appreciation very well - Thanks for taking the time to do so.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rkampen.vcf
Type: text/x-vcard
Size: 285 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20130925/d695aa1f/attachment.vcf>