subject:"Fedora Legacy"


Quoting Matthew Miller [EMAIL PROTECTED]:


I know that personally I haven't been able to contribute the amount of time
I'd like to make this succeed. But I have a full-time job and a young child,
and am mildly active in umpteen other projects. Legacy support is hard work,
and really needs two or three full-time workers to be a success. It's
tempting to blame the lack of volunteers, but this sort of project works
best if there's a solid base.


I can't disagree with that.


I think this is really unfortunate, because it makes a big gap in the Fedora
ecosystem. This will be largely filled by migration to RHEL-rebuild distros
like CentOS, which is well and good (and particularly painless from the
end-user point of few) but bad for Fedora.


I think it is good for everyone.  RHEL and its clones have a different
mission than Fedora, and people should use the one that fits their needs.
The two fill different needs.


Without a functioning lifespan of over a year, Fedora is only practically
useful as an enthusiast, bleeding-edge distro. That's only supposed to be
_part_ of its mission.


It is exactly what it is supposed to be.  Yes, that is only part of the
mission, the other major part being a test-bed for RHEL.  The mission
also includes helping developers, providing consistency of interfaces,
and making the Fedora experience better for the end user.  But the whole
point of Fedora is to be leading/cutting edge, and you can't be leading
edge with a long lifetime.

Fedora Legacy is really only there to allow for a more flexible upgrade
schedule for the users, not to extend the lifetime any real length of time.
That is, maybe a particular site can only upgrade 2 times per year, and
those times don't match with the Fedora Project release schedule.  Fedora
Legacy allows them to keep running the previous version in a _secure_
manor until their update window comes along.  That's really all Fedora
Legacy is for, as concerns Fedora Core (not Red Hat Linux, which is a
slightly different issue).

Now, maybe we've dropped the ball (on delivering the secure part of
the promise).  I won't argue that.  Nor can I say exactly why the
ball might have been dropped, or how best to pick it back up.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-20 Thread Stephen John Smoogen


On 10/20/06, Nils Breunese (Lemonbit) [EMAIL PROTECTED] wrote:

Matthew Miller wrote:

 I know that personally I haven't been able to contribute the amount
 of time
 I'd like to make this succeed. But I have a full-time job and a
 young child,
 and am mildly active in umpteen other projects. Legacy support is
 hard work,
 and really needs two or three full-time workers to be a success. It's
 tempting to blame the lack of volunteers, but this sort of project
 works
 best if there's a solid base.

The Fedora Infrastructure team recently sent out an announce mail to
let people know they could use a couple of extra hands. Already a
couple of people mailed that team and said they could help out. Maybe
Fedora Legacy should send out such an email?



I think we sent out one before the Infrastructure team did..

--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. The Merchant of Venice

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Jesse Keating [EMAIL PROTECTED]:


Without a functioning lifespan of over a year, Fedora is only practically
useful as an enthusiast, bleeding-edge distro. That's only supposed to be
_part_ of its mission.


As noted, I disagree with the above statement.


Here is what I think can happen.

A) Kill off RHL now.  Stop trying to do stuff there when we just don't have
the man power or the volunteers.


But, then there is no trust in the project.  You said you would support
it until December, and people depend on that.  If you drop it now, then
where is the trust?  How can we be sure you will support FC5 for the length
of time you claim, rather than just dropping it?  Is 2 months really worth
losing trust over?


B) Move to using Extras infrastructure for building packages.  They're ready
for us for FC3 and FC4.


Then why haven't we started doing this yet?


C) Move to Core style updates process.  Spin a possible update, toss it
in -testing.  If nobody says boo after a period of time, release the darn
thing.  If somebody finds it to be broken, fix it and resubmit.


I think this is fine for FC releases.  No problem...  It is in line with
the FC philosophy.


Somewhere in there convince Luke Macken to do the work to get a Fedora Update
tool available for use externally that does the boring stuff like generate
the email with the checksums and with the subpackage list and all that boring
stuff.  It could even handle moving the bug to 'MODIFIED' when it goes in
updates-testing, and finally to CLOSED when it goes to release.  Then it
would be easier to get people to contribute, as they'd just be doing things
like checking out a package module, copying a patch from somewhere, commit,
build.  That would help a lot.  Somebody more senior in the project would
fiddle with the tool to prepare the update, and do the sign+push.


Is he the only one who can do this stuff?  Does he need help?


I honestly think that doing these things is the only way that Legacy will
survive.


I agree with all but dropping RHL 2 months early.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Jesse Keating [EMAIL PROTECTED]:


On Thursday 19 October 2006 12:04, Matthew Miller wrote:

So RHL has been the hold-up there? In that case, *definitely* time to end
RHL support; RHL != Fedora anyway.


IMHO, Fedora Legacy was started for RHL, not FC, and the name is shouldn't
dictate policy, the original purpose should dictate policy.


My thoughts too.  I keep trying to be nice to these people, and they never
help out.  So screw 'em.  /personal opinion


Yeah, and when offers of help are met with resistence, people do tend to
not help out.  When people say stuff like So screw 'em then people tend
to not help out.


I really, really think the bugzilla process should be moved to be more
normal, too -- one bug # per release, even if the issue is identical in
FC3 and FC4. (That's why there's the clone bug bugzilla feature.)


Absolutely.  This works much better when the update tool can automanage bugs,
so that each gets closed when the update goes out, and we're not so tied to
every release must be fixed for the bug to be closed.  (note, there can be a
top level tracker but for the CVE itself, and individual bugs are cloned
for each vuln Fedora release)


So, hey, here's an idea: Let's do that!  What's the hold up?


 C) Move to Core style updates process.  Spin a possible update, toss it
 in -testing.  If nobody says boo after a period of time, release the darn
 thing.  If somebody finds it to be broken, fix it and resubmit.

Yes. Better this than nothing.


No problem for FC releases.  Since there is only 2 months left on RHL,
there isn't much of a problem there either (in particular if you set
the period of time to be a month or one week before the EOL date, which
ever comes first.


Yes. How much work will this convincing take? Does he accept bribes?


I think he does.  A lot of it is a time issue.


Again, could he use help with this?  If so, what kind of help?
Even gentle encouragement?  Or money?  Or coding support?  Or documentation
support?  Or???

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 10:48, Eric Rostetter wrote:
 IMHO, Fedora Legacy was started for RHL, not FC, and the name is shouldn't
 dictate policy, the original purpose should dictate policy.

Actually no.  Fedora Legacy came from when Fedora was created.  Fedora 
Alternatives and Extras were other proposed projects.  I picked up Legacy 
because I wanted to provide Fedora to my customers, and provide them a 
slightly longer life span.  I was persuaded to do updates for RHL too, which 
I really think was a mistake.

  My thoughts too.  I keep trying to be nice to these people, and they
  never help out.  So screw 'em.  /personal opinion

 Yeah, and when offers of help are met with resistence, people do tend to
 not help out.  When people say stuff like So screw 'em then people tend
 to not help out.

Where we need help is testing packages, reporting and vetting issues (not 
just 'hey this CVE was filed, does it effect us?'  Actually LOOK at the 
package and package sources to see, perhaps provide a patch?  Where are you 
meeting resistance doing this kind of work?

  I really, really think the bugzilla process should be moved to be more
  normal, too -- one bug # per release, even if the issue is identical
  in FC3 and FC4. (That's why there's the clone bug bugzilla feature.)
 
  Absolutely.  This works much better when the update tool can automanage
  bugs, so that each gets closed when the update goes out, and we're not so
  tied to every release must be fixed for the bug to be closed.  (note,
  there can be a top level tracker but for the CVE itself, and individual
  bugs are cloned for each vuln Fedora release)

 So, hey, here's an idea: Let's do that!  What's the hold up?

Getting software in place.  Time.  Energy.

   C) Move to Core style updates process.  Spin a possible update, toss
   it in -testing.  If nobody says boo after a period of time, release
   the darn thing.  If somebody finds it to be broken, fix it and
   resubmit.
 
  Yes. Better this than nothing.

 No problem for FC releases.  Since there is only 2 months left on RHL,
 there isn't much of a problem there either (in particular if you set
 the period of time to be a month or one week before the EOL date, which
 ever comes first.

  Yes. How much work will this convincing take? Does he accept bribes?
 
  I think he does.  A lot of it is a time issue.

 Again, could he use help with this?  If so, what kind of help?
 Even gentle encouragement?  Or money?  Or coding support?  Or documentation
 support?  Or???

I don't know.  Email him.  Find out.  He's on the fedora infrastructure team 
which has this listed as one of the projects.  
http://fedoraproject.org/wiki/Infrastructure

Don't wait on me to make it happen.

-- 
Jesse Keating
Release Engineer: Fedora


pgp9qqENtwraL.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 10:52, Eric Rostetter wrote:
  You're misunderstanding me; I meant RHL has been the hold-up for
  switching to the Extras build infrastructure.

 Can't we somehow run the two build systems in parallel?  Use the old one
 for RHL, and test the new one out for FC releases?  That way we also get
 a good test in, and have a backup if the new build system isn't working
 right, etc.

Only if we agree to split RHL updates from Fedora updates and nothold one up 
for the other.

-- 
Jesse Keating
Release Engineer: Fedora


pgpTrcH3J1zGu.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 11:36, Stephen John Smoogen wrote:
 I just have enough time currently to answer questions for people on
 #fedora-legacy, trying to put in 10-20 hours to qa a package because I
 don't know how much qa it really takes to ship a fix (especially after
 all the negative feedback when we put out a patch that 'broke'
 systems).

Yikes, 10-20 hours seems CRAZY.  It built, patch applied, app launches, push 
it as a testing update.  (sure you could do a LITTLE more testing, but trying 
to fit 20 hours of heavy qa on an app is just silly)

-- 
Jesse Keating
Release Engineer: Fedora


pgpILFvYZ3h85.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 12:21, Jesse Keating wrote:
 Yikes, 10-20 hours seems CRAZY.  It built, patch applied, app launches,
 push it as a testing update.  (sure you could do a LITTLE more testing, but
 trying to fit 20 hours of heavy qa on an app is just silly)

I should note that the only way we'll REALLY know its qad is if people use it 
in similar setups to their system, and updates-testing is usually the only 
way to get packages to them for testing.

-- 
Jesse Keating
Release Engineer: Fedora


pgpYq6GwHySpv.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Fri, Oct 20, 2006 at 10:59:39AM -0400, Jesse Keating wrote:
 Only if we agree to split RHL updates from Fedora updates and nothold one
 up for the other.

This is another benefit of one bug per distro release. FC3 packages
shouldn't hold up FC4, for that matter.

-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-20 Thread Gene Heskett

On Friday 20 October 2006 11:36, Stephen John Smoogen wrote:
On 10/20/06, Jesse Keating [EMAIL PROTECTED] wrote:
 On Friday 20 October 2006 10:48, Eric Rostetter wrote:
  IMHO, Fedora Legacy was started for RHL, not FC, and the name is
  shouldn't dictate policy, the original purpose should dictate policy.

 Actually no.  Fedora Legacy came from when Fedora was created.  Fedora
 Alternatives and Extras were other proposed projects.  I picked up
 Legacy because I wanted to provide Fedora to my customers, and provide
 them a slightly longer life span.  I was persuaded to do updates for
 RHL too, which I really think was a mistake.

I am getting deja-vu from the last time we tried fixing things about 6
months ago. I think the problem isn't RHL updates, Fedora updates etc.

The problem is that we are just beat. Jesse has a kid, a release
cycle, a new knee, and a lot of other stuff on his real job. The other
people who have been doing stuff have also had 'stuff happen', and
temporary schedule changes that have become permanent.

I just have enough time currently to answer questions for people on
#fedora-legacy, trying to put in 10-20 hours to qa a package because I
don't know how much qa it really takes to ship a fix (especially after
all the negative feedback when we put out a patch that 'broke'
systems).

Most of the other people who have been really interested in the
project have been interested in a certain release (FC1, RHL-7.2, etc)
and once we stopped supporting it, they went away. I really do not
know of anyone new who has wanted to support FC-4 or FC-5 in 4 months.

Maybe the question we should be asking is: Can we do this? We don't
have the number of people that Debian Security has on supporting old
releases.. and because we have fallen so far behind with everything..
can we dig ourselves out.. or do we need to completely reboot the
whole thing (new people, new goals, new name) with the new people
really knowing that

A) we arent going to get much help from 3rd party vendors
B) we arent going to get much help from the community

I'd comment that for this fedora user at least, the security etc stuffs 
should be extended at least to the point where we each of us, has a 
system, old though it may be in FC years, that works and does everything 
WE want it to do.

Throwing us to the wolves doesn't make me want to format and update at 
anywhere near the release cycle for FC.  My email archive alone goes back 
into 1998 here.  Yes, there are backups, and I do them rather religiously 
at the feet of a gal named amanda, but it would still be a weeks work to 
get stuff back to the Just Works(TM) state here if I was to put FC5 on 
this box today.  But after an extended rattlesnake sorting session on my 
lappy, FC5 is now looking  working pretty good, so FC6 will probably get 
installed when its out or shortly after.

But I'm not about to do this every 6 months as planned by the FC people, I 
have other things these machines need to do, and do on a set it up in cron 
so I can forget about it scenario.

My $0.02, adjust for inflation. :-)

C) etc

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Fri, Oct 20, 2006 at 10:59:13AM -0400, Jesse Keating wrote:
 Where we need help is testing packages, reporting and vetting issues (not 
 just 'hey this CVE was filed, does it effect us?'  Actually LOOK at the 
 package and package sources to see, perhaps provide a patch?  Where are you 
 meeting resistance doing this kind of work?

Although, hey, this CVE was filed, does it affect us in bugzilla is
helpful too as a starting point -- a lot of issues which do affect us aren't
even that far along at this point.

-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Fri, Oct 20, 2006 at 09:36:15AM -0600, Stephen John Smoogen wrote:
 The problem is that we are just beat. Jesse has a kid, a release
 cycle, a new knee, and a lot of other stuff on his real job. The other
 people who have been doing stuff have also had 'stuff happen', and
 temporary schedule changes that have become permanent.

Yes.

In order to survive the project needs some real support from Red Hat. (Or
some other large company who wants to do Red Hat a favor, but that seems
even less likely.) 

Using the Chasm marketing model [*], without Legacy, Fedora is only a
viable solution for Early Adopters and of dubious value to the second
Pragmatist group. However, Fedora has been enough of a success that many
Pragmatists are indeed using Fedora.

This results in large numbers of FC2, FC3, FC4 machines in production beyond
their supported lifetime. Pragmatists, by their nature, don't wanna be
upgrading all the time. Without Legacy, they're best served by CentOS and
kin. That's fine, but it's a loss for Fedora, as they're then less likely to
feed back into Extras, etc. And it's also a problem because it results in
large numbers of potentially vulnerable machines in the wild.

Fedora people repeatedly state that the distribution is great for users
beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really
not true.


* http://www.ericsink.com/Act_Your_Age.html


-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Fri, Oct 20, 2006 at 08:58:33AM -0400, James Kosin wrote:
  E) See if any Fedora Core engineers are interested in, out of the goodness
 of their hearts, building updates for their packages in Legacy when it
 isn't much extra work -- and enabling them to easily do so.
 The only problem with this is WHY ever go with the latest FC6 or 7 or
 whatever if you can have the packages updated to the latest even if
 you have FC2.

I really don't think that's a major concern. Most packages wouldn't be
updated to the newest version -- just the ones where that's the easiest
thing to do.

 Legacy is all about security-updates!!!  ONLY!!!
 The policy is update with PATCHES if at all possible.  From RH even
 better; otherwise fall back to other sources for patches such as the
 development groups, etc.  Only if EVERYTHING else fails, you can
 update to the latest stable release to fix the flaw.

Right now, everything is clearly failing.

-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Jesse Keating [EMAIL PROTECTED]:


On Friday 20 October 2006 10:52, Eric Rostetter wrote:

 You're misunderstanding me; I meant RHL has been the hold-up for
 switching to the Extras build infrastructure.

Can't we somehow run the two build systems in parallel?  Use the old one
for RHL, and test the new one out for FC releases?  That way we also get
a good test in, and have a backup if the new build system isn't working
right, etc.


Only if we agree to split RHL updates from Fedora updates and nothold one up
for the other.


Fine with me.


--
Jesse Keating
Release Engineer: Fedora





--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 13:58, Eric Rostetter wrote:
 First, my interest doesn't really fit there.  It is in testing what is
 in updates-testing (which is nothing).  If there was something in
 updates-testing to test, I would test it and report the results.

Its tough to get to updates-testing without the pre-work done.  So thats where 
we need the help right now.

 Secondly, I've offered to help many times with other infrastructure issues,
 and been turned down over and over.

Where?  When?  You refused to use IRC, you've refused to even try to get a 
wiki account.

 Third, when I've tried to help test packages before updates-testing, I
 met with lots of trouble.  Someone: No, you have to do this, this way, not
 that way! Me: Okay, where's that documented?  Someone: No where.
 Me: Okay, I'll document that and resubmit  Someone: No, you still missed
 Step X.  Me: Okay, where is that documented?  Someone: No where.  
 Me: Okay,
 I'll document that...  And so on.  Eventually of course, my documentation
 is no longer good because it is a web page and now it should all be wiki,
 and I don't have access to the wiki.  By the time I finally get access to
 the wiki, I've lost interest.

When did you try to get a wiki account?  We always welcome more documentation.

 Third, I had a big project that took about a year of my life, during which
 I could not spend a lot of time of FL work.  That is over now, and I could
 go back to working on FL again, but I really don't see where I'm needed
 now.

I've outlined what help we need.

 The fact that I only have one FC machine to play with (FC 3 x86_64 now,
 could upgrade to FC4 or what ever if needed) doesn't help.  I'm willing
 to put it towards FL work if you tell me what you need me to do.

 But you can't expect me to do everything any more than I expect you to do
 everything.  And as long as you keep refusing my offers to help saying
 you'll do it yourself, you won't get many unsolicited offers from me,
 so you better start soliciting if you want anything.

  So, hey, here's an idea: Let's do that!  What's the hold up?
 
  Getting software in place.  Time.  Energy.

 Is there anything I can do to help, or not?

Again, I don't know, you'd have to ask Luke and / or the Infrastructure team.


  Again, could he use help with this?  If so, what kind of help?
  Even gentle encouragement?  Or money?  Or coding support?  Or
  documentation support?  Or???
 
  I don't know.  Email him.  Find out.  He's on the fedora infrastructure
  team which has this listed as one of the projects.
  http://fedoraproject.org/wiki/Infrastructure
 
  Don't wait on me to make it happen.

 Is there a particular reason to contact only him instead of the whole
 infrastructure team?

Mostly because he owns the project.

-- 
Jesse Keating
Release Engineer: Fedora


pgpAxNbXQG0oY.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Matthew Miller [EMAIL PROTECTED]:


Fedora people repeatedly state that the distribution is great for users
beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really
not true.


It is only good for tech-savy people who can upgrade outside of pre-set
windows.  Legacy extends this to tech-savy people who can upgrade at
some point during the year.  Someday the Fedora Documentation Project
along with Fedora Legacy (if it survives) may extend this to non-tech-savy
people who can upgrade within a year...

Let's face it.  Fedora Legacy use is limited.  The fact that some Fedora
people say otherwise doesn't make it true.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-20 Thread Michal Jaegermann

On Fri, Oct 20, 2006 at 01:19:08PM -0400, Gene Heskett wrote:
 
 My email archive alone goes back 
 into 1998 here.  Yes, there are backups, and I do them rather religiously 
 at the feet of a gal named amanda, but it would still be a weeks work to 
 get stuff back to the Just Works(TM) state here if I was to put FC5 on 
 this box today.

Eh?  How come?  Not that I am trying to tell you upgrade right now
but I have around machines which went through numerous release
upgrades, some with original installations dating back to times
of RH6.x realeases or maybe even earlier, and it never took me
weeks to do such thing.  Rather small hours when most of the
time I was doing something else when a machine was busy installing
updated packages.

I am not trying to imply that there is no work involved.  It is
easier when you can do that over a network or from DVD, or otherwise
you have to babysit a machine and switch CDs from time to time,
but I never had a situation that such operation destroyed my data
or made a machine inoperable.

It is also true that after such step there is some cleanup to
perform; but with possible small exceptions this is not extremely
urgent and can be done here and there at your leisure.
'rpm -qa --last' will make you a list where possible leftovers are
easy to pick up and you should go through assorted '.rpmnew' and
'.rpmsave' files.  'locate' is of a great help here after you
updated its database.

On some occasions I did even such nasty things as
'rpm -Uvh --nodeps fedora-release*', with that rpm from a target
distro, followed by 'yum update yum* rpm* python*' and
after that 'yum update ...' (various things as needed), but such
trickery may require assorted manual interventions which depend
on what you really have already installed and falls into
if you have to ask how to do that you should not be doing it
category.  Still it worked fine in the final account (with
a different set of tradeoffs than a normal update).

Yes, I know that some claim that to upgrade a release one should
do an install from scratch and restore personal data from
backups.  Unless you really messed up previously your installation
doing things like 'rpm --Uvh --nodeps ...' all over the place,
and other nasties of that sort, this is misguided.

   

 But after an extended rattlesnake sorting session on my 
 lappy, FC5 is now looking  working pretty good, so FC6 will probably get 
 installed when its out or shortly after.
 
 But I'm not about to do this every 6 months as planned by the FC people, I 
 have other things these machines need to do, and do on a set it up in cron 
 so I can forget about it scenario.
 
 My $0.02, adjust for inflation. :-)
 
 C) etc
 
 -- 
 Cheers, Gene
 There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order.
 -Ed Howdershelt (Author)
 Yahoo.com and AOL/TW attorneys please note, additions to the above
 message by Gene Heskett are:
 Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
 
 --
 fedora-legacy-list mailing list
 fedora-legacy-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-legacy-list

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Jesse Keating [EMAIL PROTECTED]:


On Friday 20 October 2006 13:58, Eric Rostetter wrote:

First, my interest doesn't really fit there.  It is in testing what is
in updates-testing (which is nothing).  If there was something in
updates-testing to test, I would test it and report the results.


Its tough to get to updates-testing without the pre-work done.  So   
thats where

we need the help right now.


Yes, true.  But, like I said, you can't expect one person to do everything...

If we had a way to know what work needed to be done, it might be easier
for people like me to help.  Long ago I suggested that there be a mailing
list for entries in bugzilla, and while it was received well by many on
this list, it was rejected by you.  If I got an e-mail saying we need
to test package X, and I decided I could test package X, I would do it.
But I don't have the time to go crawling through bugzilla looking to
see what needs to be tested, and I've not seen a mailing to this list
lately with a list of things that needed testing.  In other words, I
personally respond better to a push to me of what is needed than
having to expend effort to pull what is needed from various sources.


Secondly, I've offered to help many times with other infrastructure issues,
and been turned down over and over.


Where?  When?  You refused to use IRC, you've refused to even try to get a
wiki account.


Yes, I basically refuse to use IRC.  If that means I can't help with FL,
then so be it.  That's your problem.

My requests to help go back to the beginning, like setting up CVS for the
web site, a web-interface to the CVS, a mailing list for the CVS, etc.
You refused all that help, saying you already planned to do that kind of
stuff and would do it yourself, etc.  You did setup the CVS, but none of
the rest.  I've never managed to get access to change bugzilla entry
white boards, etc. though I've asked about it, etc.

As for a wiki access, I _did_ get it.  But, I'm really never been sure
how you plan to split the web site and wiki, if at all, and what you want
done, and personally I _hate_ the idea of putting everything in the wiki.
I specifically hate putting the advisories in the wiki, but you say you
want to.  Well, so be it, but I've not seen any work done to do it, and
I've not been asked to help in doing so.


I'll document that...  And so on.  Eventually of course, my documentation
is no longer good because it is a web page and now it should all be wiki,
and I don't have access to the wiki.  By the time I finally get access to
the wiki, I've lost interest.


When did you try to get a wiki account?  We always welcome more   
documentation.


I _did_ get access to the wiki (though I don't know if it still works or not).
In fact I say that above where you quote me.


Third, I had a big project that took about a year of my life, during which
I could not spend a lot of time of FL work.  That is over now, and I could
go back to working on FL again, but I really don't see where I'm needed
now.


I've outlined what help we need.


No, you said we need lots of stuff.  I said, okay, I'm trying to do some
of that stuff.  You said, no, we need this other stuff since the stuff
I want to do can't be done until the other stuff is done...  Well, fine,
if I have to do that other stuff I'm willing, if it is made easy for me
to do.  Is anyone willing to make it easier for me to do?


Again, I don't know, you'd have to ask Luke and / or the Infrastructure team.


I'll reread the thread, and _if_ I understand what is desired, I'll approach
them about it.  If not, then I'll _try_ to get someone here to explain to
me what it is I'm supposed to ask them.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy


Quoting Jesse Keating [EMAIL PROTECTED]:


But I don't have the time to go crawling through bugzilla looking to
see what needs to be tested, and I've not seen a mailing to this list
lately with a list of things that needed testing.  In other words, I


Please read the above.


And for a while Pekka was posting a list of all the work needed items.  Was
that not usable?  I don't remember the discussion of a mailing list for bugs,


Yes, it was, but as I said, I've not seen one for a while...


there is a '[EMAIL PROTECTED]' email alias, if you want on that, by all
means I'll add you.  I do know that I don't want bug discussion to happen on
a list and out of the bug.


Correct, it should be a one-way mailing only.

Yes, if you want me to help, please add me to [EMAIL PROTECTED]


When this was happening, I
had thought you had left the project, so it wasn't much of a thought process.


I've never left the project, I've just become much less active in it.

I would like EVERYTHING except advisories (see above) and the GPG   
keys.  David

Eisenstein has done a lot of work of porting some content over, I'm sure he'd
like a hand with that.  I like the wiki as it is a LOT lower overhead to
contribute content, make updates as things change, refine processes,
interlink with other Fedora documentation such as how to use the CVS system,
how to get an account, how to use the build system, etc...


Okay, I'll take you at your word on the above.  And I'll just keep my
own opinions about it to myself where they belong.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

On Friday 20 October 2006 15:16, Eric Rostetter wrote:
 Yes, if you want me to help, please add me to [EMAIL PROTECTED]

You've been added.

-- 
Jesse Keating
Release Engineer: Fedora


pgpYLRQYfyfNc.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-20 Thread Stephen John Smoogen


On 10/20/06, Matthew Miller [EMAIL PROTECTED] wrote:

On Fri, Oct 20, 2006 at 09:36:15AM -0600, Stephen John Smoogen wrote:
 The problem is that we are just beat. Jesse has a kid, a release
 cycle, a new knee, and a lot of other stuff on his real job. The other
 people who have been doing stuff have also had 'stuff happen', and
 temporary schedule changes that have become permanent.

Yes.

In order to survive the project needs some real support from Red Hat. (Or
some other large company who wants to do Red Hat a favor, but that seems
even less likely.)




Using the Chasm marketing model [*], without Legacy, Fedora is only a
viable solution for Early Adopters and of dubious value to the second
Pragmatist group. However, Fedora has been enough of a success that many
Pragmatists are indeed using Fedora.



I would argue that the pragmatists had been using it out of a trust
model. They had used Red Hat Linux when it has crossed the chasm, and
were using Fedora out of the same trust model. However, Fedora seems
to have only been for Early Adopters. Legacy was an added on idea by
people who realized that if you are going to put service software in
an OS, people arent going to want to upgrade every 6 months. The
problem with that is that maintaining an OS is always more effort/cost
than creating it. That is why Pragmatists, Conservatives, and Laggards
are better suited with an Enterprise linux.  The problem with trying
to stay on the Early Adopter side is that they will most likely drop
you for the next shiney thing (Gentoo 3 years ago, Ubuntu today, xPath
in 3 years)




Fedora people repeatedly state that the distribution is great for users
beyond the tech-enthusiast Earlier Adopters. But without Legacy, it's really
not true.



To be honest, there are only 2 reasons I use Fedora these days:

1) I drank the Bob Young koolaid long ago, and I am too much an RPM
man to change to something else.. and

2) I use Fedora to alpha/beta test for the next/current Red Hat Enterprise.

Even if Red Hat does not use Fedora as a alpha/beta test for Red Hat
Enterprise.. I and many other people who are RHEL/Centos/etc customers
do. I use Fedora because I  need to know what the next RHEL will have
in it. I use it to see what tools in extras I can pull over to my
production systems because I need a plone, git, or other tool for some
project.

I do like having the nice new distro every 6 to 9 months, but I don't
get paid to have it... and I am not longer the young kid who has time
to twiddle with all the nobs to find out why something isnt working.



* http://www.ericsink.com/Act_Your_Age.html




Heh. I hadn't seen that for a long time. Erik Sink was sort of my boss
before I went to work for Red Hat. The books Crossing the Chasm and
Inside the Tornado should be required reading for anyone dealing
with emerging markets.



--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. The Merchant of Venice

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

lwn article on the death of Fedora Legacy

2006-10-19 Thread Matthew Miller


http://lwn.net/Articles/204722/

This is subscriber-only content for two weeks, but the gist is: there's a
whole lotta unpatched vulnerabilities in FC4. Can we really pretend this is
an ongoing concern?

I know that personally I haven't been able to contribute the amount of time
I'd like to make this succeed. But I have a full-time job and a young child,
and am mildly active in umpteen other projects. Legacy support is hard work,
and really needs two or three full-time workers to be a success. It's
tempting to blame the lack of volunteers, but this sort of project works
best if there's a solid base. 

When Jesse Keating worked at Pogo, that was largely true, but with his
duties at RH and with his new kid, it doesn't seem to be the case anymore.
I'm sure this is not Jesse's fault -- there needs to be commitment from
above, and that's clearly not the case.

I think this is really unfortunate, because it makes a big gap in the Fedora
ecosystem. This will be largely filled by migration to RHEL-rebuild distros
like CentOS, which is well and good (and particularly painless from the
end-user point of few) but bad for Fedora. 

Without a functioning lifespan of over a year, Fedora is only practically
useful as an enthusiast, bleeding-edge distro. That's only supposed to be
_part_ of its mission.


-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Jesse Keating

On Thursday 19 October 2006 11:44, Matthew Miller wrote:
 When Jesse Keating worked at Pogo, that was largely true, but with his
 duties at RH and with his new kid, it doesn't seem to be the case anymore.
 I'm sure this is not Jesse's fault -- there needs to be commitment from
 above, and that's clearly not the case.

 I think this is really unfortunate, because it makes a big gap in the
 Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild
 distros like CentOS, which is well and good (and particularly painless from
 the end-user point of few) but bad for Fedora.

 Without a functioning lifespan of over a year, Fedora is only practically
 useful as an enthusiast, bleeding-edge distro. That's only supposed to be
 _part_ of its mission.

Here is what I think can happen.

A) Kill off RHL now.  Stop trying to do stuff there when we just don't have 
the man power or the volunteers.

B) Move to using Extras infrastructure for building packages.  They're ready 
for us for FC3 and FC4.

C) Move to Core style updates process.  Spin a possible update, toss it 
in -testing.  If nobody says boo after a period of time, release the darn 
thing.  If somebody finds it to be broken, fix it and resubmit.

Somewhere in there convince Luke Macken to do the work to get a Fedora Update 
tool available for use externally that does the boring stuff like generate 
the email with the checksums and with the subpackage list and all that boring 
stuff.  It could even handle moving the bug to 'MODIFIED' when it goes in 
updates-testing, and finally to CLOSED when it goes to release.  Then it 
would be easier to get people to contribute, as they'd just be doing things 
like checking out a package module, copying a patch from somewhere, commit, 
build.  That would help a lot.  Somebody more senior in the project would 
fiddle with the tool to prepare the update, and do the sign+push.

I honestly think that doing these things is the only way that Legacy will 
survive.

-- 
Jesse Keating RHCE  (geek.j2solutions.net)
Fedora Legacy Team  (www.fedoralegacy.org)
GPG Public Key  (geek.j2solutions.net/jkeating.j2solutions.pub)


pgp6BazXvdPlf.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Pekka Savola


On Thu, 19 Oct 2006, Matthew Miller wrote:

A) Kill off RHL now.  Stop trying to do stuff there when we just don't have
the man power or the volunteers.
B) Move to using Extras infrastructure for building packages.  They're
ready for us for FC3 and FC4.


So RHL has been the hold-up there? ...


That is an incorrect conclusion.

FWIW, Marc was the most active contributor, only interested in FC1, 
but willing to do the work for other versions as well.  Up until some 
time ago, I was willing to help but my interest was only the RHLs but 
was willing ot do PUBLISH/VERIFY for other versions in order to get 
RHL updates.  There were a couple of other people who did some VERIFYs 
and proposed a couple of packages. That's it.


A better phrasing could maybe be that RHL/old distros was what kept FL 
going, because those had significant deployment base before people 
realized that trying to use Fedora and expect long maintenance wasn't 
a good idea (and hence folks moved to CentOS).


You could say that there is some problem with the process if e.g., 
sendmail MIME vulnerability updates (which are declared ready) 
haven't been published during the 1.5 months they've been ready [1]. I 
guess the issue is that no one with privileges to send the 
notification or move stuff from updates-testing to updates has been 
around during that time.


As a result, there are very few people left who care enough about 
FC3/FC4 updates.  There just aren't enough people to do the job, and 
the machinery to do the job has been way too heavyweight for a long 
time.  I guess one could still move the FC3/FC4 stuff to extras 
(instead of just declaring the project dead) but I doubt the number of 
contributors is going to rise dramatically as a result even if extras 
were used.  Some administrative overhead would be reduced but you'd 
someone would still be needed to do the work.


[1]
http://netcore.fi/pekkas/buglist.html
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195418

--
Pekka Savola You each name yourselves king, yet the
Netcore Oykingdom bleeds.
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Matthew Miller

On Thu, Oct 19, 2006 at 08:57:31PM +0300, Pekka Savola wrote:
 On Thu, 19 Oct 2006, Matthew Miller wrote:
 A) Kill off RHL now.  Stop trying to do stuff there when we just don't 
 have
 the man power or the volunteers.
 B) Move to using Extras infrastructure for building packages.  They're
 ready for us for FC3 and FC4.
 So RHL has been the hold-up there? ...
 That is an incorrect conclusion.

You're misunderstanding me; I meant RHL has been the hold-up for switching
to the Extras build infrastructure.

 time.  I guess one could still move the FC3/FC4 stuff to extras 
 (instead of just declaring the project dead) but I doubt the number of 
 contributors is going to rise dramatically as a result even if extras 
 were used.  Some administrative overhead would be reduced but you'd 
 someone would still be needed to do the work.

Agreed.

-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Jesse Keating

On Thursday 19 October 2006 13:57, Pekka Savola wrote:
 As a result, there are very few people left who care enough about
 FC3/FC4 updates.  There just aren't enough people to do the job, and
 the machinery to do the job has been way too heavyweight for a long
 time.  I guess one could still move the FC3/FC4 stuff to extras
 (instead of just declaring the project dead) but I doubt the number of
 contributors is going to rise dramatically as a result even if extras
 were used.  Some administrative overhead would be reduced but you'd
 someone would still be needed to do the work.

A good chunk of my proposal is removing administrative overhead.  Its overhead 
now because we have to manually assemble the email, do write out the content, 
checksome the packages, push them around etc..  Its VERY cumbersome, and 
requires a lot of permissions I'm not happy about giving folks.  Moving it to 
Extras and tying into existing scripts or slightly new scripts to do most the 
work would lighten the load SIGNIFICANTLY.

-- 
Jesse Keating RHCE  (geek.j2solutions.net)
Fedora Legacy Team  (www.fedoralegacy.org)
GPG Public Key  (geek.j2solutions.net/jkeating.j2solutions.pub)


pgpLOdtRkh4xv.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Stephen John Smoogen


On 10/19/06, Jesse Keating [EMAIL PROTECTED] wrote:

On Thursday 19 October 2006 11:44, Matthew Miller wrote:
 When Jesse Keating worked at Pogo, that was largely true, but with his
 duties at RH and with his new kid, it doesn't seem to be the case anymore.
 I'm sure this is not Jesse's fault -- there needs to be commitment from
 above, and that's clearly not the case.

 I think this is really unfortunate, because it makes a big gap in the
 Fedora ecosystem. This will be largely filled by migration to RHEL-rebuild
 distros like CentOS, which is well and good (and particularly painless from
 the end-user point of few) but bad for Fedora.

 Without a functioning lifespan of over a year, Fedora is only practically
 useful as an enthusiast, bleeding-edge distro. That's only supposed to be
 _part_ of its mission.

Here is what I think can happen.

A) Kill off RHL now.  Stop trying to do stuff there when we just don't have
the man power or the volunteers.

B) Move to using Extras infrastructure for building packages.  They're ready
for us for FC3 and FC4.

C) Move to Core style updates process.  Spin a possible update, toss it
in -testing.  If nobody says boo after a period of time, release the darn
thing.  If somebody finds it to be broken, fix it and resubmit.



D) Move to Core style plan. Figure out what core packages we are going
to backport for, and what packages we are just going to push the
latest stuff for.

Mozilla - Seamonkey
Gaim - Gaim latest

etc.

--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. The Merchant of Venice

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: lwn article on the death of Fedora Legacy

2006-10-19 Thread Matthew Miller

On Thu, Oct 19, 2006 at 05:07:30PM -0600, Stephen John Smoogen wrote:
 D) Move to Core style plan. Figure out what core packages we are going
 to backport for, and what packages we are just going to push the
 latest stuff for.
 Mozilla - Seamonkey
 Gaim - Gaim latest

Yeah.

And also, if at all possible,

E) See if any Fedora Core engineers are interested in, out of the goodness
   of their hearts, building updates for their packages in Legacy when it
   isn't much extra work -- and enabling them to easily do so.


-- 
Matthew Miller   [EMAIL PROTECTED]  http://mattdm.org/
Boston University Linux  --  http://linux.bu.edu/

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: Fedora Core 4 Transferred to Fedora Legacy

2006-08-15 Thread Aaron Konstam

On Fri, 2006-08-11 at 17:55 -0400, Jim Cornette wrote:
Aaron Konstam wrote:
On Mon, 2006-08-07 at 22:30 +0100, Chris Jones wrote:
There is something I have forgotten or maybe I never really knew. How
does the transfer of FC4 to the Legacy Project affect the ability to do
a yum install or yum upgrade?
I cannot confirm how it got there, but in my /etc/yum.repos.d directory I
have
a fedora-legacy.repo file which contains

[legacy-updates]
name=Fedora Legacy $releasever - $basearch - Updates
mirrorlist=http://fedora.redhat.com/download/mirrors/legacy-updates-released-fc$releasever
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-legacy

[legacy-testing]
name=Fedora Legacy $releasever - $basearch - Updates Testing
mirrorlist=http://fedora.redhat.com/download/mirrors/legacy-updates-testing-fc$releasever
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-legacy

Is this what is needed to activate legacy support.

I must say my box is FC5 so I haven't worried about it too much.. I have
the
normal repos online and these legacy repos disabled.

cheers Chris

Look, I can't get any any answer from the fedora-legacy-list on this so
I guess I am invisible. The legacy-updates-testing-fc$releasever for FC4
does not exist and the one for FC5 exists bit is empty. So how does one
get legacy updates?

It looks like there are i386 updates at the below link. There is a
mirror list for ftp and http methods.

ftp://ftp.planetmirror.com/pub/fedoralegacy/fedora/4/updates/i386

Jim

That is intersting except when you go to that site it wants you to
logon. When I say I want togin anonomously I get back a message that
content can not be displayed.

Am I the only one that is driven to distraction by the fac that the
fedora legacy
repositories just don't exist or don't work.
--
Aaron Konstam [EMAIL PROTECTED]

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: Fedora Core 4 Transferred to Fedora Legacy

2006-08-15 Thread Jesse Keating

On Tuesday 15 August 2006 09:50, Aaron Konstam wrote:
 That is intersting except when you go to that site it wants you to
 logon. When I say I want togin anonomously I get back a message that
 content can not be displayed.

 Am I the only one that is driven to distraction by the fac that the
 fedora legacy
 repositories just don't exist or don't work.

I'm sorry Aaron, perhaps we haven't made it absolutely clear yet.  The 
legacy-yumconf we provided a link to for you will install an extra repository 
into your yum setup.  Currently the repository it points to is just as all of 
the released updates from Fedora thus far.  Fedora Legacy has not ADDED any 
updates yet.  You shouldn't have to touch anyother yum configs, leave them 
all enabled.  You'll still be able to do yum installs and yum updates.  When 
Legacy makes an update to Fedora Core 4, we will add it to the repository 
that our yumconf points to, and the next time you yum update you'll see that 
update.

Is this clear yet?  Can you please please please tell me if you're still 
unclear on something?

I'm somewhat upset that you're telling people that we aren't responding to 
you, when in fact multiple people on this list are trying to help you.

-- 
Jesse Keating RHCE  (geek.j2solutions.net)
Fedora Legacy Team  (www.fedoralegacy.org)
GPG Public Key  (geek.j2solutions.net/jkeating.j2solutions.pub)


pgpIGOEQ0LonZ.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: Fedora Core 4 Transferred to Fedora Legacy

2006-08-15 Thread Curtis Doty

10:16am Jesse Keating said:

 legacy-yumconf we provided a link to for you will install an extra repository 
 into your yum setup.  Currently the repository it points to is just as all of 
 the released updates from Fedora thus far.  Fedora Legacy has not ADDED any 
 updates yet.  You shouldn't have to touch anyother yum configs, leave them 
 all enabled.  You'll still be able to do yum installs and yum updates.  When 
 Legacy makes an update to Fedora Core 4, we will add it to the repository 
 that our yumconf points to, and the next time you yum update you'll see that 
 update.

This makes perfect sense. And I was thinking... Having just done:

# rpm -ivh 
http://download.fedoralegacy.org/fedora/4/updates/$HOSTTYPE/legacy-yumconf-4-2.fc4.noarch.rpm

Which involved a bit of copy/paste to ensure I got the URL correct. Would 
it be possible in fc6 or fc7 to add the legacy-yumconf as an optional 
package in either core or extras? Then, in 2008 or whenever those core 
releases go to pasture, the transition could be as smooth as:

# yum -y install legacy-yumconf

../C

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Re: Fedora Core 4 Transferred to Fedora Legacy

2006-08-15 Thread Rahul


Curtis Doty wrote:


This makes perfect sense. And I was thinking... Having just done:

# rpm -ivh 
http://download.fedoralegacy.org/fedora/4/updates/$HOSTTYPE/legacy-yumconf-4-2.fc4.noarch.rpm

Which involved a bit of copy/paste to ensure I got the URL correct. Would 
it be possible in fc6 or fc7 to add the legacy-yumconf as an optional 
package in either core or extras? Then, in 2008 or whenever those core 
releases go to pasture, the transition could be as smooth as:


# yum -y install legacy-yumconf



Fedora Core 5 already includes the fedora-legacy repository file. You 
just have to enable it.


Rahul

--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

fedora legacy broken upgrade paths (was: Broken upgrade paths in FC+FE 2006-06-28)

2006-06-28 Thread Axel Thimm

Hi,

I extracted the FL relevant parts of broken upgrade paths. This is
part of an automated mail sent to the fedora-extras list:

On Wed, Jun 28, 2006 at 09:10:24AM -0400, [EMAIL PROTECTED] wrote:
 mozilla:
   3: 37:1.7.13-1.3.1.legacy (FL3-updates)
   4: 37:1.7.13-1.1.fc4 (FC4-updates)
   5: 37:1.7.13-1.1.fc5 (FC5-updates)
   6: 37:1.7.13-1.1.fc5 (FC6)

This happend because instead of fc3 the disttag was chosen to be
simply 3 which is rpm-bigger than any fcX.

The only way to fix FL broken paths is to bump the evr of the
subsequent releases :/

FL or a spokesman of FL like Jesse need to lobby FC or FE for
something like this to happen. Let's hope there will be some new
security issue in mozilla 1.7.13 soon ;)
-- 
Axel.Thimm at ATrpms.net


pgpZ5ARWvVqcz.pgp
Description: PGP signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Fedora Legacy Test Update Notification: mozilla

2006-05-15 Thread Marc Deslauriers

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-189137-1
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137
2006-05-15
-

Name: mozilla
Versions: rh7.3: mozilla-1.7.13-0.73.1.legacy
Versions: rh9:   mozilla-1.7.13-0.90.1.legacy
Versions: fc1:   mozilla-1.7.13-1.1.1.legacy
Versions: fc2:   mozilla-1.7.13-1.2.1.legacy
Versions: fc3:   mozilla-1.7.13-1.3.1.legacy
Summary : A Web browser.
Description :
Mozilla is an open-source Web browser, designed for standards
compliance, performance, and portability.

-
Update Information:

Updated mozilla packages that fix several security bugs are now
available.

Mozilla is an open source Web browser, advanced email and newsgroup
client, IRC chat client, and HTML editor.

Several bugs were found in the way Mozilla processes malformed
javascript. A malicious web page could modify the content of a different
open web page, possibly stealing sensitive information or conducting a
cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732,
CVE-2006-1741)

Several bugs were found in the way Mozilla processes certain javascript
actions. A malicious web page could execute arbitrary javascript
instructions with the permissions of chrome, allowing the page to
steal sensitive information or install browser malware. (CVE-2006-1727,
CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735,
CVE-2006-1742)

Several bugs were found in the way Mozilla processes malformed web
pages. A carefully crafted malicious web page could cause the execution
of arbitrary code as the user running Mozilla. (CVE-2006-0748,
CVE-2006-0749, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738,
CVE-2006-1739, CVE-2006-1790)

A bug was found in the way Mozilla displays the secure site icon. If a
browser is configured to display the non-default secure site modal
warning dialog, it may be possible to trick a user into believing they
are viewing a secure site. (CVE-2006-1740)

A bug was found in the way Mozilla allows javascript mutation events on
input form elements. A malicious web page could be created in such a
way that when a user submits a form, an arbitrary file could be uploaded
to the attacker. (CVE-2006-1729)

A bug was found in the way Mozilla executes in-line mail forwarding. If
a user can be tricked into forwarding a maliciously crafted mail message
as in-line content, it is possible for the message to execute javascript
with the permissions of chrome. (CVE-2006-0884)

Users of Mozilla are advised to upgrade to these updated packages
containing Mozilla version 1.7.13 which corrects these issues.

-
Changelogs

rh7.3:
* Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED]
37:1.7.13-0.73.1.legacy
- Updated to 1.7.13 to fix security issues


rh9:
* Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED]
37:1.7.13-0.90.1.legacy
- Updated to 1.7.13 to fix security issues

fc1:
* Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED]
37:1.7.13-1.1.1.legacy
- Updated to 1.7.13 to fix security issues


fc2:
* Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED]
37:1.7.13-1.2.1.legacy
- Updated to 1.7.13 to fix security issues

fc3:
* Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED]
37:1.7.13-1.3.1.legacy
- Updated to 1.7.13 to fix security issues

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
b7616c52ee2776f3577fcda0a0628c5ec6cffae7
redhat/7.3/updates-testing/i386/mozilla-1.7.13-0.73.1.legacy.i386.rpm
a6234bd3b89616ce5b924a36c95ba1421b6b8ecf
redhat/7.3/updates-testing/i386/mozilla-chat-1.7.13-0.73.1.legacy.i386.rpm
3d7b92d47b825f5a936c54ca63679916f428917e
redhat/7.3/updates-testing/i386/mozilla-devel-1.7.13-0.73.1.legacy.i386.rpm
2b4c765543b3f4fc5ac04127ca70c70a33fddaec
redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.13-0.73.1.legacy.i386.rpm
c15eceb55105a87f8d5dc0db24b9cf95e815a5a2
redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.13-0.73.1.legacy.i386.rpm
09dcdb176779a013efc6b1819e5391854d94a751
redhat/7.3/updates-testing/i386/mozilla-mail-1.7.13-0.73.1.legacy.i386.rpm
5126d56d8ff98dfdcd69ed6864821120fc959c55
redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.13-0.73.1.legacy.i386.rpm
d2db357f5fe0d1ffce22db18f7d95c96dcfcffa3
redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.13-0.73.1.legacy.i386.rpm
7b3a403f4981d5ffa676aa38e5699fca9e7c2f18
redhat/7.3/updates-testing/i386/mozilla-nss-1.7.13-0.73.1.legacy.i386.rpm
3eea1812fa6a6ef13ed8826cd7734bd266c9b0fb
redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.13-0.73.1.legacy.i386.rpm
46393b4afb72fcd8100de2c61b6531d9ffe1dbf5
redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.6.legacy.i386.rpm

Fedora Legacy Test Update Notification: firefox

2006-05-15 Thread Marc Deslauriers

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-189137-2
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137
2006-05-15
-

Name: firefox
Versions: fc3: firefox-1.0.8-1.1.fc3.1.legacy
Summary : Mozilla Firefox Web browser.
Description :
Mozilla Firefox is an open-source web browser, designed for standards
compliance, performance and portability.

-
Update Information:

An updated firefox package that fixes several security bugs is now
available.

Mozilla Firefox is an open-source web browser, designed for standards
compliance, performance and portability.

Several bugs were found in the way Firefox processes malformed
javascript. A malicious web page could modify the content of a different
open web page, possibly stealing sensitive information or conducting a
cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732,
CVE-2006-1741)

Several bugs were found in the way Firefox processes certain javascript
actions. A malicious web page could execute arbitrary javascript
instructions with the permissions of chrome, allowing the page to
steal sensitive information or install browser malware. (CVE-2006-1727,
CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735,
CVE-2006-1742)

Several bugs were found in the way Firefox processes malformed web
pages. A carefully crafted malicious web page could cause the execution
of arbitrary code as the user running Firefox. (CVE-2006-0748,
CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737,
CVE-2006-1738, CVE-2006-1739, CVE-2006-1790)

A bug was found in the way Firefox displays the secure site icon. If a
browser is configured to display the non-default secure site modal
warning dialog, it may be possible to trick a user into believing they
are viewing a secure site. (CVE-2006-1740)

A bug was found in the way Firefox allows javascript mutation events on
input form elements. A malicious web page could be created in such a
way that when a user submits a form, an arbitrary file could be uploaded
to the attacker. (CVE-2006-1729)

Users of Firefox are advised to upgrade to these updated packages
containing Firefox version 1.0.8 which corrects these issues.

-
Changelogs

fc3:
* Wed Apr 19 2006 Marc Deslauriers [EMAIL PROTECTED]
0:1.0.8-1.1.fc3.1.legacy
- Update to firefox 1.0.8

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

fc3:
8b719bb18c6dfe14b472c684ac5133d82d1b96d0
fedora/3/updates-testing/i386/firefox-1.0.8-1.1.fc3.1.legacy.i386.rpm
946f2ccbc412675ee6959a3dee50c2cb3ba90c3a
fedora/3/updates-testing/x86_64/firefox-1.0.8-1.1.fc3.1.legacy.x86_64.rpm
0747aa65730e328a9274ec66c0de8dc30645dc1d
fedora/3/updates-testing/SRPMS/firefox-1.0.8-1.1.fc3.1.legacy.src.rpm

-

Please test and comment in bugzilla.




signature.asc
Description: OpenPGP digital signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

Fedora Legacy Test Update Notification: tetex

2006-04-26 Thread Marc Deslauriers

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-152868
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152868
2006-04-26
-

Name: tetex
Versions: rh73: tetex-1.0.7-47.5.legacy
Versions: rh9: tetex-1.0.7-66.3.legacy
Versions: fc1: tetex-2.0.2-8.2.legacy
Versions: fc2: tetex-2.0.2-14FC2.3.legacy
Summary : The TeX text formatting system.
Description :
TeTeX is an implementation of TeX for Linux or UNIX systems. TeX takes
a text file and a set of formatting commands as input and creates a
typesetter-independent .dvi (DeVice Independent) file as output.
Usually, TeX is used in conjunction with a higher level formatting
package like LaTeX or PlainTeX, since TeX by itself is not very
user-friendly.

-
Update Information:

Updated tetex packages that fix several security issues are now
available.

TeTeX is an implementation of TeX. TeX takes a text file and a set of
formatting commands as input and creates a typesetter-independent .dvi
(DeVice Independent) file as output.

A number of integer overflow bugs that affect Xpdf were discovered. The
teTeX package contains a copy of the Xpdf code used for parsing PDF
files and is therefore affected by these bugs. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
names CVE-2004-0888 and CVE-2004-1125 to these issues.

Several flaws were discovered in the teTeX PDF parsing library. An
attacker could construct a carefully crafted PDF file that could cause
teTeX to crash or possibly execute arbitrary code when opened. The
Common Vulnerabilities and Exposures project assigned the names
CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624,
CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these
issues.

Users of teTeX should upgrade to these updated packages, which contain
backported patches and are not vulnerable to these issues.

-
Changelogs

rh73:
* Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-47.5.legacy
- Added tetex tetex-latex and tetex-dvips to BuildPreReq!

* Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-47.4.legacy
- Added patch to remove expiration check

* Wed Apr 19 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-47.3.legacy
- Added missing netpbm-progs, ghostscript, ed and texinfo to BuildPrereq

* Fri Mar 17 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-47.2.legacy
- Patches for CESA-2004-007, CAN-2004-1125, CAN-2004-0888, CVE-2005-3193

rh9:
* Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-66.3.legacy
- Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq

* Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-66.2.legacy
- Added missing ed and texinfo to BuildPrereq

* Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-66.1.legacy
- Patches for CESA-2004-007 CAN-2004-0888 CAN-2004-1125 CVE-2005-3193
(#152868)

fc1:
* Wed Apr 26 2006 Marc Deslauriers [EMAIL PROTECTED]
2.0.2-8.2.legacy
- Added missing ed, texinfo, tetex, tetex-latex and tetex-dvips to
BuildPreReq

* Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 2.0.2-8.1.legacy
- Patches for CAN-2004-0888, CAN-2004-1125, CAN-2005-0064
  and 2005-3193

fc2:
* Tue Apr 25 2006 Marc Deslauriers [EMAIL PROTECTED]
2.0.2-14FC2.3.legacy
- Fixed release tag
- Added missing tetex, tetex-latex and tetex-dvips to BuildPreReq

* Thu Mar 16 2006 Donald Maner [EMAIL PROTECTED] 2.0.2-14.3.legacy
- Patch CVE-2005-3193 (#152868)

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

rh73:
80b05b7896c5db589e960da0d73b1cd4ae120cce
redhat/7.3/updates-testing/i386/tetex-1.0.7-47.5.legacy.i386.rpm
28c6022b4f6a237d4695d1f268276ec6b18dcf4c
redhat/7.3/updates-testing/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm
017fa321d9834685f04819070d4f5fb799e05d01
redhat/7.3/updates-testing/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm
3303175840f2fc37c5f3f77e672eeb3fafae718a
redhat/7.3/updates-testing/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm
fa43c7cbdf02cb7d439c9beeb0e358f8c69a5f22
redhat/7.3/updates-testing/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm
1e69a574c3d47cec5b58963387956dfc8337d6ec
redhat/7.3/updates-testing/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm
bb229acb3b38ae16025d56a77c41cab939a512ac
redhat/7.3/updates-testing/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm
d21419415faefcb90b688f8d8dc60a57a6374bad
redhat/7.3/updates-testing/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm
f646b3f3c2ebafa6ae264f20a3f056c778bd84db
redhat/7.3/updates-testing/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm

rh9:
26f54ca0403372b21e6fd441d9bb64073f23e7de
redhat/9/updates-testing/i386/tetex-1.0.7-66.3.legacy.i386.rpm
e74de7855d1d07bcef6a713f4a8735e8008f5249
redhat

Fedora Legacy Test Update Notification: emacs

2006-04-26 Thread Marc Deslauriers

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-152898
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152898
2006-04-26
-

Name: emacs
Versions: rh73: emacs-21.2-3.legacy
Versions: rh9: emacs-21.2-34.legacy
Versions: fc1: emacs-21.3-9.2.legacy
Summary : The libraries needed to run the GNU Emacs text editor.
Description :
Emacs is a powerful, customizable, self-documenting, modeless text
editor. Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.

-
Update Information:

Updated Emacs packages that fix a string format issue are now available.

Emacs is a powerful, customizable, self-documenting, modeless text
editor.

Max Vozeler discovered several format string vulnerabilities in the
movemail utility of Emacs. If a user connects to a malicious POP server,
an attacker can execute arbitrary code as the user running emacs. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CVE-2005-0100 to this issue.

Users of Emacs are advised to upgrade to these updated packages, which
contain backported patches to correct this issue.

-
Changelogs

rh73:
* Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.2-3.legacy
- Patch for CAN-2005-0100 (#152898)

rh9:
* Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.2-34.legacy
- Patch for CAN-2005-0100 (#152898)

fc1:
* Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.2.legacy
- Clean up the #101818 (vm/break dumper problem) workaround

* Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.1.legacy
- Oops.  Forgot to rework make install for the broken setarch.
  Now done.

* Wed Mar 15 2006 David Eisenstein [EMAIL PROTECTED] 21.3-9.legacy
- Re-instate setarch stuff; but make use of setarch dependent upon
  whether or not it is broken in this given invocation of rpmbuild.
  Why?  If setarch doesn't break, it is probably needed and will be
  used for the bugzilla #101818 issue.  If setarch *does* break, then
  it is likely breaking because it is operating within another setarch
  (FC1's setarch breaks under that circumstance), such as when being
  built by plague/mock.  In that instance, it is not needed.

* Sun Mar 12 2006 Jesse Keating [EMAIL PROTECTED] 21.3-8.legacy
- Patch for CAN-2005-0100 (#152898)
- Remove setarch stuff, not needed in new build system
- Added builddep on autoconf213

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

rh73:
4441c55cfe91aabf2203d68bcbc0cf2bbd5f8798
redhat/7.3/updates-testing/i386/emacs-21.2-3.legacy.i386.rpm
33e802e8f306f13519dd2c3f045eb9efe5e4680a
redhat/7.3/updates-testing/i386/emacs-el-21.2-3.legacy.i386.rpm
f6293ffe1c51c3bb31f1b3941da0938d8a98eff2
redhat/7.3/updates-testing/i386/emacs-leim-21.2-3.legacy.i386.rpm
a5767f1100037b49602abb80831fa22da135c081
redhat/7.3/updates-testing/SRPMS/emacs-21.2-3.legacy.src.rpm

rh9:
ae56dba68d59f5d49105f7afb6918ac945ad8b01
redhat/9/updates-testing/i386/emacs-21.2-34.legacy.i386.rpm
84047366c8488fa3c95070466b1bd20ce5d8687a
redhat/9/updates-testing/i386/emacs-el-21.2-34.legacy.i386.rpm
8eb8449c456e7d475157992c3e6f8bc4bdf64c7b
redhat/9/updates-testing/i386/emacs-leim-21.2-34.legacy.i386.rpm
4cf0ba484c3ab93210d186beb3c79b68b4e56984
redhat/9/updates-testing/SRPMS/emacs-21.2-34.legacy.src.rpm

fc1:
d56260f010b4603c89516ccf2ddd09c33c8c53c4
fedora/1/updates-testing/i386/emacs-21.3-9.2.legacy.i386.rpm
6bf7cb9bacc6c0f9374849fa4507ededa13193cf
fedora/1/updates-testing/i386/emacs-el-21.3-9.2.legacy.i386.rpm
fb23df114772b6c758499401751dfc389e2e1d88
fedora/1/updates-testing/i386/emacs-leim-21.3-9.2.legacy.i386.rpm
1a1133d917d4993c92a03c30ba08e8916c6a7bfe
fedora/1/updates-testing/SRPMS/emacs-21.3-9.2.legacy.src.rpm

-

Please test and comment in bugzilla.



signature.asc
Description: OpenPGP digital signature
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list

[UPDATED] Fedora Legacy Test Update Notification: gnupg

2006-04-01 Thread Marc Deslauriers

The rh73 packages were updated to correct a broken info page.

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-185355
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355
2006-04-01
-

Name: gnupg
Versions: rh73: gnupg-1.0.7-13.3.legacy
Versions: rh9: gnupg-1.2.1-9.2.legacy
Versions: fc1: gnupg-1.2.3-2.2.legacy
Versions: fc2: gnupg-1.2.4-2.3.legacy
Versions: fc3: gnupg-1.2.7-1.2.legacy
Summary : A GNU utility for secure communication and data storage.
Description :
GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and
creating digital signatures. GnuPG has advanced key management
capabilities and is compliant with the proposed OpenPGP Internet
standard described in RFC2440. Since GnuPG doesn't use any patented
algorithm, it is not compatible with any version of PGP2 (PGP2.x uses
only IDEA for symmetric-key encryption, which is patented worldwide).

-
Update Information:

An updated GnuPG package that fixes signature verification flaws is now
available.

GnuPG is a utility for encrypting data and creating digital signatures.

Tavis Ormandy discovered a bug in the way GnuPG verifies
cryptographically signed data with detached signatures. It is possible
for an attacker to construct a cryptographically signed message which
could appear to come from a third party. When a victim processes a GnuPG
message with a malformed detached signature, GnuPG ignores the malformed
signature, processes and outputs the signed data, and exits with status
0, just as it would if the signature had been valid. In this case,
GnuPG's exit status would not indicate that no signature verification
had taken place. This issue would primarily be of concern when
processing GnuPG results via an automated script. The Common
Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to
this issue.

Tavis Ormandy also discovered a bug in the way GnuPG verifies
cryptographically signed data with inline signatures. It is possible for an
attacker to inject unsigned data into a signed message in such a way that
when a victim processes the message to recover the data, the unsigned data
is output along with the signed data, gaining the appearance of having been
signed. This issue is mitigated in the GnuPG shipped with Red Hat
Enterprise Linux as the --ignore-crc-error option must be passed to the gpg
executable for this attack to be successful. The Common Vulnerabilities and
Exposures project assigned the name CVE-2006-0049 to this issue.

Please note that neither of these issues affect the way RPM or up2date
verify RPM package files, nor is RPM vulnerable to either of these issues.

All users of GnuPG are advised to upgrade to this updated package, which
contains backported patches to correct these issues.


-
Changelogs

rh73:
* Sat Apr 01 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-13.3.legacy
- Added missing texinfo to BuildPrereq

* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-13.2.legacy
- Added missing openldap-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-13.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

rh9:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.1-9.2.legacy
- Added missing openldap to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.1-9.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

fc1:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.3-2.2.legacy
- Added missing openldap-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

fc2:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.3-2.3.legacy
- Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner

Fedora Legacy Test Update Notification: ncpfs

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-152904
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152904
2006-03-28
-

Name: ncpfs
Versions: rh73: ncpfs-2.2.0.18-6.1.legacy
Versions: rh9: ncpfs-2.2.1-1.1.legacy
Versions: fc1: ncpfs-2.2.3-1.1.legacy
Versions: fc2: ncpfs-2.2.4-1.1.legacy
Versions: fc3: ncpfs-2.2.4-5.FC3.1.legacy
Summary : Utilities for the ncpfs filesystem, a NetWare client.
Description :
Ncpfs is a filesystem which understands the Novell NetWare(TM) NCP
protocol.  Functionally, NCP is used for NetWare the way NFS is used
in the TCP/IP world.  For a Linux system to mount a NetWare
filesystem, it needs a special mount program.  The ncpfs package
contains such a mount program plus other tools for configuring and
using the ncpfs filesystem.

-
Update Information:

An updated ncpfs package is now available.

Ncpfs is a file system that understands the Novell NetWare(TM) NCP
protocol.

Buffer overflows were found in the nwclient program. An attacker, using
a long -T option, could possibly execute arbitrary code and gain
privileges. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CVE-2004-1079 to this issue.

A bug was found in the way ncpfs handled file permissions. ncpfs did not
sufficiently check if the file owner matched the user attempting to
access the file, potentially violating the file permissions. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CVE-2005-0013 to this issue.

A buffer overflow was found in the ncplogin program. A remote malicious
NetWare server could execute arbitrary code on a victim's machine. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CVE-2005-0014 to this issue.

All users of ncpfs are advised to upgrade to this updated package, which
contains backported fixes for these issues.

-
Changelogs

rh73:
* Fri Mar 10 2006 Marc Deslauriers [EMAIL PROTECTED]
2.2.0.18-6.1.legacy
- fixed getuid security bug CVE-2005-0013

rh9:
* Fri Mar 10 2006 Marc Deslauriers [EMAIL PROTECTED]
2.2.1-1.1.legacy
- Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014

fc1:
* Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED]
2.2.3-1.1.legacy
- Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014

fc2:
* Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED]
2.2.4-1.1.legacy
- Added patches for CVE-2004-1079, CVE-2005-0013 and CVE-2005-0014

fc3:
* Sat Mar 11 2006 Marc Deslauriers [EMAIL PROTECTED]
2.2.4-5.FC3.1.legacy
- Added missing part of CVE-2005-0013 fix

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

rh73:
16740d3fa5e17a46429ad3586e4adf9a14a64f8d
redhat/7.3/updates-testing/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm
21f8520c8a2a3d60e55041c0db028e03549f8544
redhat/7.3/updates-testing/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm
6704d55f1f43360b6ad4211e2ca0f92e9f2174c8
redhat/7.3/updates-testing/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm

rh9:
6acd3b7b7d09cb0e47769b43a888adf72a6278ac
redhat/9/updates-testing/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm
c49d83f88b229ce57c689d313eccb4df7b89f36b
redhat/9/updates-testing/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm
ac833c51fcf831bca3edef5d0275ccd1ae0a530f
redhat/9/updates-testing/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm

fc1:
8379face8f68fe556d40bf32f72a5ab368e8eb6d
fedora/1/updates-testing/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm
eefaa839a26179ca5d41897eacf7bbf3c49661e1
fedora/1/updates-testing/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm
ede00a8544200515b5e09a7a40836d8f558cac9d
fedora/1/updates-testing/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm

fc2:
1d32d2f0c39475f98206d78f87c587d4f96ddb70
fedora/2/updates-testing/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm
c095ce2d66184b605516231609cddc30520c3eb5
fedora/2/updates-testing/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm
874f8a48f85fef80615b5892a70d214f0935ed7a
fedora/2/updates-testing/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm

fc3:
dc329c8b3558f67350486358b01b6a62f6f467af
fedora/3/updates-testing/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm
1ddd6caafe4a693d4a69d341be69600df446de3b
fedora/3/updates-testing/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm
db8660759a23570a6d06bda37c619e0931425ef8
fedora/3/updates-testing/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm
1e8bc7d10995fde90688b424f5001c14f7d3e3bc
fedora/3/updates-testing/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm
7f29dd88dcf31f19970e22c8c3af7267c62a5508
fedora/3/updates-testing/SRPMS/ncpfs-2.2.4-5.FC3.1.legacy.src.rpm

-

Please test and comment in bugzilla

Fedora Legacy Test Update Notification: fetchmail

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-164512
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164512
2006-03-28
-

Name: fetchmail
Versions: rh73: fetchmail-5.9.0-21.7.3.2.legacy
Versions: rh9: fetchmail-6.2.0-3.4.legacy
Versions: fc1: fetchmail-6.2.0-8.2.legacy
Versions: fc2: fetchmail-6.2.5-2.2.legacy
Summary : A remote mail retrieval and forwarding utility.
Description :
Fetchmail is a remote mail retrieval and forwarding utility intended
for use over on-demand TCP/IP links, like SLIP or PPP connections.
Fetchmail supports every remote-mail protocol currently in use on the
Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6,
and IPSEC) for retrieval. Then Fetchmail forwards the mail through
SMTP so you can read it through your favorite mail client.

-
Update Information:

Updated fetchmail packages that fix security flaws are now available.

Fetchmail is a remote mail retrieval and forwarding utility.

A bug was found in the way fetchmail allocates memory for long lines. A
remote attacker could cause a denial of service by sending a specially-
crafted email. The Common Vulnerabilities and Exposures project has
assigned the name CVE-2003-0792 to this issue.

A buffer overflow was discovered in fetchmail's POP3 client. A malicious
server could cause send a carefully crafted message UID and cause
fetchmail to crash or potentially execute arbitrary code as the user
running fetchmail. The Common Vulnerabilities and Exposures project
assigned the name CAN-2005-2335 to this issue.

A bug was found in the way the fetchmailconf utility program writes
configuration files. The default behavior of fetchmailconf is to write a
configuration file which may be world readable for a short period of
time. This configuration file could provide passwords to a local
malicious attacker within the short window before fetchmailconf sets
secure permissions. The Common Vulnerabilities and Exposures project has
assigned the name CVE-2005-3088 to this issue.

A bug was found when fetchmail is running in multidrop mode. A malicious
mail server can cause a denial of service by sending a message without
headers. The Common Vulnerabilities and Exposures project has assigned
the name CVE-2005-4348 to this issue.

Users of fetchmail should update to this erratum package which contains
backported patches to correct these issues.

-
Changelogs

rh73:
* Sat Mar 11 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-3.2.legacy
- add patch for CAN-2003-0792 (#164512)
- add patch for CAN-2005-4348 (#164512)
- add patch for CAN-2005-3088 from RHEL 2.1 (#164512)

* Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 5.9.0-21.7.3.1.legacy
- add patch for POP3 buffer overflow - CAN-2005-2355 (#164512)

rh9:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
6.2.0-3.4.legacy
- Added missing e2fsprogs-devel to BuildPrereq

* Sat Mar 11 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-3.2.legacy
- add patch for CAN-2003-0792 (#164512)
- add patch for CAN-2005-3088 (#164512)

* Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.0-3.1.legacy
- add patch for POP3 buffer overflow - CAN-2005-2355 (#164512)

fc1:
* Sun Mar 12 2006 Donald Maner [EMAIL PROTECTED] 6.2.0-8.2.legacy
- add patch for CAN-2005-3088 (#164512)
- add patch for CAN-2005-2355 (#164512)

* Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.0-8.1.legacy
- add patch for POP3 buffer overflow - CAN-2005-2355 (#164512)

fc2:
* Sun Mar 12 2006 Donald Maner [EMAIL PROTECTED] 6.2.5-2.2.legacy
- add patch for crash on empty message - CVE-2005-4348 (#164512)
- add patch for CAN-2005-3088 (#164512)

* Thu Jul 28 2005 Jeff Sheltren [EMAIL PROTECTED] 6.2.5-2.1.legacy
- add patch for POP3 buffer overflow - CAN-2005-2355 (#164512)

-
This update can be downloaded from:
  http://download.fedoralegacy.org/
(sha1sums)

rh73:
8b49bca60dc8bcbba7634b8e0559c82fbeef3db5
redhat/7.3/updates-testing/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm
9c9c861757b4b8b2866f1d0e91dbc16d5037d956
redhat/7.3/updates-testing/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm
9cca4f274cb21928d459ed25883e5d3c1f758f10
redhat/7.3/updates-testing/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm

rh9:
0fd22e51f83aab97d8c1790ed95423882f01aa9b
redhat/9/updates-testing/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm
7d2eb582d0aba96e07710eb89cd8c4c41c4530d3
redhat/9/updates-testing/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm

fc1:
5df158a0ba6bb0c323a75464e04b11e246dd8f98
fedora/1/updates-testing/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm
927ed2783b8b4a29d0669e7936c1d27fd05564eb
fedora/1/updates-testing/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm

fc2

Fedora Legacy Test Update Notification: gnupg

-
Fedora Legacy Test Update Notification
FEDORALEGACY-2006-185355
Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355
2006-03-28
-

Name: gnupg
Versions: rh73: gnupg-1.0.7-13.2.legacy
Versions: rh9: gnupg-1.2.1-9.2.legacy
Versions: fc1: gnupg-1.2.3-2.2.legacy
Versions: fc2: gnupg-1.2.4-2.3.legacy
Versions: fc3: gnupg-1.2.7-1.2.legacy
Summary : A GNU utility for secure communication and data storage.
Description :
GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and
creating digital signatures. GnuPG has advanced key management
capabilities and is compliant with the proposed OpenPGP Internet
standard described in RFC2440. Since GnuPG doesn't use any patented
algorithm, it is not compatible with any version of PGP2 (PGP2.x uses
only IDEA for symmetric-key encryption, which is patented worldwide).

-
Update Information:

An updated GnuPG package that fixes signature verification flaws is now
available.

GnuPG is a utility for encrypting data and creating digital signatures.

Tavis Ormandy discovered a bug in the way GnuPG verifies
cryptographically signed data with detached signatures. It is possible
for an attacker to construct a cryptographically signed message which
could appear to come from a third party. When a victim processes a GnuPG
message with a malformed detached signature, GnuPG ignores the malformed
signature, processes and outputs the signed data, and exits with status
0, just as it would if the signature had been valid. In this case,
GnuPG's exit status would not indicate that no signature verification
had taken place. This issue would primarily be of concern when
processing GnuPG results via an automated script. The Common
Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to
this issue.

Tavis Ormandy also discovered a bug in the way GnuPG verifies
cryptographically signed data with inline signatures. It is possible for an
attacker to inject unsigned data into a signed message in such a way that
when a victim processes the message to recover the data, the unsigned data
is output along with the signed data, gaining the appearance of having been
signed. This issue is mitigated in the GnuPG shipped with Red Hat
Enterprise Linux as the --ignore-crc-error option must be passed to the gpg
executable for this attack to be successful. The Common Vulnerabilities and
Exposures project assigned the name CVE-2006-0049 to this issue.

Please note that neither of these issues affect the way RPM or up2date
verify RPM package files, nor is RPM vulnerable to either of these issues.

All users of GnuPG are advised to upgrade to this updated package, which
contains backported patches to correct these issues.


-
Changelogs

rh73:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.0.7-13.2.legacy
- Added missing openldap-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.0.7-13.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

rh9:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.1-9.2.legacy
- Added missing openldap to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.1-9.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

fc1:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.3-2.2.legacy
- Added missing openldap-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle argument
parsing,
  backported (CVE-2006-0049, #185355)
- add backport of patch from Werner Koch to fix the exit status when
verifying
  signatures when no signature is provided (CVE-2006-0455, #185355)

fc2:
* Thu Mar 23 2006 Marc Deslauriers [EMAIL PROTECTED]
1.2.3-2.3.legacy
- Added missing openldap-devel, bzip2-devel and zlib-devel to BuildPrereq

* Wed Mar 15 2006 Donald Maner [EMAIL PROTECTED] 1.2.3-2.1.legacy
- add patch from Werner Koch to error out on ambiguous armored signatures in
  message, with some more bits from Klaus Singvogel to handle

[UPDATED] Fedora Legacy Test Update Notification: sendmail