FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-11-2007, 04:20 PM
Mike
 
Default F8 yum update problem

Louis E Garcia II <louisg00 <at> bellsouth.net> writes:


> Public key for yum-3.2.8-2.fc8.noarch.rpm is not installed

At a guess it was probably signed with the wrong key - and will no doubt get
fixed if we wait!




--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 04:55 PM
Remi Collet
 
Default F8 yum update problem

Louis E Garcia II a écrit :

>
> Public key for yum-3.2.8-2.fc8.noarch.rpm is not installed
>

yum-3.2.8-2 is signed with "testing" repository GPG key....

$ rpm -qi yum | grep Key
Signature : DSA/SHA1, jeu 06 déc 2007 12:56:48 CET, Key ID
da84cbd430c9ecf8
$ rpm -q gpg-pubkey --qf "%{summary} -> %{version}
" | grep 30c9ecf8
gpg(Fedora Project (Test Software) <rawhide@redhat.com>) -> 30c9ecf8

Remi.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 05:15 PM
 
Default F8 yum update problem

On Tue, 11 Dec 2007, Mike wrote:

Louis E Garcia II <louisg00 <at> bellsouth.net> writes:


Public key for yum-3.2.8-2.fc8.noarch.rpm is not installed


At a guess it was probably signed with the wrong key - and will no doubt get
fixed if we wait!



Sounds good to me. I read the email from Remi Collet, and it seems a
simple signing issue with the Fedora Project.


I'll wait, since I would rather not auto install rawhide packages.

ed

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 05:38 PM
Tom Horsley
 
Default F8 yum update problem

On Tue, 11 Dec 2007 13:15:54 -0500 (EST)
ed@hp.uab.edu wrote:

> Sounds good to me. I read the email from Remi Collet, and it seems a
> simple signing issue with the Fedora Project.

Just for curiosity, why is it so difficult to automatically check
elementary things like rpm signatures and metadata checksums before
publishing new info in the master repositories? This seems to happen
with extreme frequency.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 07:15 PM
Todd Zullinger
 
Default F8 yum update problem

Tom Horsley wrote:
> Just for curiosity, why is it so difficult to automatically check
> elementary things like rpm signatures and metadata checksums before
> publishing new info in the master repositories? This seems to happen
> with extreme frequency.

It takes many hours to run a repoclosure and check that everything is
sane. It's not that the folks doing the updates don't want to, it's
just that no good way to do this has been implemented yet, AFAIK.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
First, God created idiots. That was just for practice. Then He created
school boards.
-- Mark Twain

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 07:31 PM
Tom Horsley
 
Default F8 yum update problem

On Tue, 11 Dec 2007 15:15:27 -0500
Todd Zullinger <tmz@pobox.com> wrote:

> It takes many hours to run a repoclosure and check that everything is
> sane. It's not that the folks doing the updates don't want to, it's
> just that no good way to do this has been implemented yet, AFAIK.

I'm sure it takes many hours to do the full check for everything, but
something puts new packages in the repo. Simple checks for the
obvious dumb stuff like wrong sig seem like it ought to be possible
for each package at the time it is merged into the repo.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-11-2007, 07:50 PM
Todd Zullinger
 
Default F8 yum update problem

Tom Horsley wrote:
> I'm sure it takes many hours to do the full check for everything,
> but something puts new packages in the repo. Simple checks for the
> obvious dumb stuff like wrong sig seem like it ought to be possible
> for each package at the time it is merged into the repo.

True. Some of that lack is just due to not enough hours in the day of
the folks that are doing the work to put the distro together. Jesse
Keating is working on a signing server tool that is intended to help
spread the work load (securely) so that a few more folks can help out
in some aspects. That will hopefully free up time to work on other
integration issues and checks.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Curiosity killed the cat, but for awhile I was a suspect.
-- Steven Wright

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-13-2007, 12:35 PM
"Michael Schwendt"
 
Default F8 yum update problem

On 11/12/2007, Todd Zullinger wrote:
> Tom Horsley wrote:
> > Just for curiosity, why is it so difficult to automatically check
> > elementary things like rpm signatures and metadata checksums before
> > publishing new info in the master repositories? This seems to happen
> > with extreme frequency.
>
> It takes many hours to run a repoclosure and check that everything is
> sane. It's not that the folks doing the updates don't want to, it's
> just that no good way to do this has been implemented yet, AFAIK.

Tom Horsley suggests checking "elementary things" and gives two
examples. Verifying package signatures, especially when packages are
resigned when being moved from updates-testing to updates, is
something that would not take "many hours".

The infamous metadata checksum errors are not due to mistakes made on
the master server. They come from a mirroring system that breaks in
conjunction with Yum's caching implementation. You can observe how
mirrors are out-of-sync for several days, offering data from several
days ago. Everytime a Yum session with a mirror is interrupted and you
are assigned a different mirror, the already downloaded repomd.xml
must match all mirrors which are contacted until the repodata is
downloaded. You can notice how the cache and the remote repodata get
out-of-sync with Yum not downloading a fresh repomd.xml until it has
the big repodata files copied. I have a repomd.xml from a few days
ago, a cachecookie from a few minutes ago, but the mirrors I'm offered
by the mirrorlist carry newer repodata which don't match the cached
repomd.xml. Just give it a try and copy the remote repodata directory
manually to verify it. "yum clean metadata" is a cure only if Yum
succeeds in copying a good/matching set of repodata files. That works
best if you stick to your favourite mirror.

Todd Zullinger comments on different checks. Running repoclosure
doesn't take "many hours". Fedora Extras repoclosure has been run
frequently, processing Fedora Core and Fedora Extras, at least prior
to every push but sometimes inbetween to help the packagers. It
doesn't take more than 15-20 minutes for the initial and unattended
run. The parts of it that take much more time are: setting up
temporary repositories before they could be checked (including
multilib resolving), taking action when broken deps are found (exclude
pkgs, run again and hope that no further broken deps are found then,
possibly add automation to assist with that). For Extras, running the
modified repoclosure has only been done for Core+Extras plus the
needsign repositories -- thousands of pkgs, without doing the
multilib-compose dance, however, which would add to the processing
time. It takes additional time to complete the update repositories
(multilib resolving and updating, repoview, ...) when packages are
pushed.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-13-2007, 04:16 PM
"Lamar Owen"
 
Default F8 yum update problem

On Thursday 13 December 2007, Michael Schwendt wrote:
> Tom Horsley suggests checking "elementary things" and gives two
> examples. Verifying package signatures, especially when packages are
> resigned when being moved from updates-testing to updates, is
> something that would not take "many hours".

On thing that would eliminate many issues is to make the mirroring and repo
building process transactional; I also know what kind of an infrastructure
headache that would be to get and keep working.

That is, as packages are queued for insertion into the main repo, all
processes and regenerations are done, then the transaction is committed and
the mirror stays consistent (ACID for the repo). As it is now, there are
windows (as you thoroughly covered in your message) where the repo and set of
mirrors are inconsistent.

And, just like database replication (like Slony and others on PostgreSQL, or
MySQL's replication engine), this is a tough problem to solve correctly.
--
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-13-2007, 09:37 PM
Todd Zullinger
 
Default F8 yum update problem

Michael,

Many thanks to you for correcting my inaccuracies and offering your
experience and insights. Your work on keeping Cor + Extras repos in a
sane state is greatly appreciated.

Michael Schwendt wrote:
> Todd Zullinger comments on different checks. Running repoclosure
> doesn't take "many hours". Fedora Extras repoclosure has been run
> frequently, processing Fedora Core and Fedora Extras, at least prior
> to every push but sometimes inbetween to help the packagers. It
> doesn't take more than 15-20 minutes for the initial and unattended
> run. The parts of it that take much more time are: setting up
> temporary repositories before they could be checked (including
> multilib resolving), taking action when broken deps are found (exclude
> pkgs, run again and hope that no further broken deps are found then,
> possibly add automation to assist with that). For Extras, running the
> modified repoclosure has only been done for Core+Extras plus the
> needsign repositories -- thousands of pkgs, without doing the
> multilib-compose dance, however, which would add to the processing
> time. It takes additional time to complete the update repositories
> (multilib resolving and updating, repoview, ...) when packages are
> pushed.

Aren't the repos now created fresh each time and thus require the
whole multilib compose (which is slow, as far as I have read/heard)?
If not, are there good reasons why it's not done? I know things have
changed greatly with the introduction of the new build tools. Do you
happen to know if that's the main reason that repoclosure isn't run
before each push now?

Thanks again.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Never do anything against conscience even if the state demands it.
-- Albert Einstein, Quoted in Saturday Review obituary, 1955

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

Thread Tools




All times are GMT. The time now is 03:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org