[gentoo-amd64] Messed up virtual/glibc?

[gentoo-amd64] Messed up virtual/glibc?

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For some reason after upgrading glibc yesterday many packages cannot be
emerged:
emerge -puD world

These are the packages that I would merge, in order:

Calculating world dependencies /
emerge: there are no ebuilds to satisfy "virtual/glibc".


!!! Problem with ebuild media-gfx/gimp-print-4.2.7
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

I do have sys-libs/glibc-2.3.5 installed, and I'm running
portage-2.0.51.22-r1.

This isn't just one package - if I mask the one that is complaining I'll
end up getting a complaint about another package.

revdep-rebuild didn't help either.

I've tried reinstalling glibc several times, and I've checked that
CHOST=CTARGET=CBUILD in emerge info.

Taking a quick look at glibc I see that it provides virtual/libc.  Why
are other packages looking for virtual/glibc?  It seems to be more than
one.  Also - gimp-print does not contain any reference to virtual/glibc.

Does anybody have any ideas why portage is looking for virtual/glibc?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0cIDg2bN8aFizRkRAnFLAJ4/vQo7hq6IOtyPRbXPN8eNdgWf7ACdFwtG
KRRR6NeKtcPdxAGlfwIqM2A=
=lqFt
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3999 bytes --]

Re: [gentoo-amd64] Messed up virtual/glibc?

[Simon Stelling]

Richard Freeman wrote:
> Calculating world dependencies /
> emerge: there are no ebuilds to satisfy "virtual/glibc".

I once had the same issue. It was caused due to a bad metadata cache,
rebuilding it solved the problem, IIRC. Try emerge --sync && emerge
--metadata, just to be sure.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Messed up virtual/glibc?

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Stelling wrote:
> 
> I once had the same issue. It was caused due to a bad metadata cache,
> rebuilding it solved the problem, IIRC. Try emerge --sync && emerge
> --metadata, just to be sure.

Alas - that did not work.  I'll keep digging tonight, but so far I'm out
of ideas.  If anybody has a suggestion for a way to generate debug
output that might help let me know.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0lbxg2bN8aFizRkRAoDYAJ9YG6sE3lMjoE1umQH1U3ItZvioZACbBf1w
RdFYZ32YOp69wge97wmZins=
=wo0O
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3999 bytes --]

Re: [gentoo-amd64] Messed up virtual/glibc?

[Zac Medico]

Richard Freeman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> For some reason after upgrading glibc yesterday many packages cannot be
> emerged:
> emerge -puD world
> 
> These are the packages that I would merge, in order:
> 
> Calculating world dependencies /
> emerge: there are no ebuilds to satisfy "virtual/glibc".
> 
> 
> !!! Problem with ebuild media-gfx/gimp-print-4.2.7
> !!! Possibly a DEPEND/*DEPEND problem.
> 
> !!! Depgraph creation failed.
> 
> I do have sys-libs/glibc-2.3.5 installed, and I'm running
> portage-2.0.51.22-r1.
> 
> This isn't just one package - if I mask the one that is complaining I'll
> end up getting a complaint about another package.
> 
> revdep-rebuild didn't help either.
> 
> I've tried reinstalling glibc several times, and I've checked that
> CHOST=CTARGET=CBUILD in emerge info.
> 
> Taking a quick look at glibc I see that it provides virtual/libc.  Why
> are other packages looking for virtual/glibc?  It seems to be more than
> one.  Also - gimp-print does not contain any reference to virtual/glibc.
> 
> Does anybody have any ideas why portage is looking for virtual/glibc?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFC0cIDg2bN8aFizRkRAnFLAJ4/vQo7hq6IOtyPRbXPN8eNdgWf7ACdFwtG
> KRRR6NeKtcPdxAGlfwIqM2A=
> =lqFt
> -----END PGP SIGNATURE-----


I think you've gotten a virtual/glibc typo in one of your ebuilds (where did that "g" come from???).  Have you tried more than one portage snapshot?  Do you have PORTDIR_OVERLAY set?

Zac
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Messed up virtual/glibc?

[Richard Freeman]

On Mon, July 11, 2005 7:54 am, Zac Medico said:
> Richard Freeman wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> For some reason after upgrading glibc yesterday many packages cannot be
>> emerged:
>> emerge -puD world
>>
>> These are the packages that I would merge, in order:
>>
>> Calculating world dependencies /
>> emerge: there are no ebuilds to satisfy "virtual/glibc".
>>
>>
>> !!! Problem with ebuild media-gfx/gimp-print-4.2.7
>> !!! Possibly a DEPEND/*DEPEND problem.
>>
>> !!! Depgraph creation failed.
>>
>> I do have sys-libs/glibc-2.3.5 installed, and I'm running
>> portage-2.0.51.22-r1.
>>
>> This isn't just one package - if I mask the one that is complaining I'll
>> end up getting a complaint about another package.
>>
>> revdep-rebuild didn't help either.
>>
>> I've tried reinstalling glibc several times, and I've checked that
>> CHOST=CTARGET=CBUILD in emerge info.
>>
>> Taking a quick look at glibc I see that it provides virtual/libc.  Why
>> are other packages looking for virtual/glibc?  It seems to be more than
>> one.  Also - gimp-print does not contain any reference to virtual/glibc.
>>
>> Does anybody have any ideas why portage is looking for virtual/glibc?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFC0cIDg2bN8aFizRkRAnFLAJ4/vQo7hq6IOtyPRbXPN8eNdgWf7ACdFwtG
>> KRRR6NeKtcPdxAGlfwIqM2A=
>> =lqFt
>> -----END PGP SIGNATURE-----
>
>
> I think you've gotten a virtual/glibc typo in one of your ebuilds (where
> did that "g" come from???).  Have you tried more than one portage
> snapshot?  Do you have PORTDIR_OVERLAY set?
>

I've done several emerge syncs and the problem has persisited.  Neither
dia nor gimp-print appear anywhere in my local portage overlay, and both
of these packages are giving me issues.  If I mask gimp-print I'm sure
I'll hit more.

Neither of these ebuilds has the text "glibc" anywhere in them.  The
string "virtual/glibc" doesn't appear in any code in the ebuild classes
director either under /usr/portage.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Messed up virtual/glibc?

[Allan Wang]

On Mon, 2005-07-11 at 07:24 -0400, Richard Freeman wrote:
> Alas - that did not work.  I'll keep digging tonight, but so far I'm out
> of ideas.  If anybody has a suggestion for a way to generate debug
> output that might help let me know.

Try: grep -r 'virtual/glibc' /usr/portage

That might help find the broken ebuild/metadata. You might want to try
it in your overlays too.

Allan

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Messed up virtual/glibc?

[Zac Medico]

Richard Freeman wrote:
> 
> I've done several emerge syncs and the problem has persisited.  Neither
> dia nor gimp-print appear anywhere in my local portage overlay, and both
> of these packages are giving me issues.  If I mask gimp-print I'm sure
> I'll hit more.
> 
> Neither of these ebuilds has the text "glibc" anywhere in them.  The
> string "virtual/glibc" doesn't appear in any code in the ebuild classes
> director either under /usr/portage.

Also grep /var/db/pkg and /var/cache/edb/dep.

Zac
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Messed up virtual/glibc?

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Allan Wang wrote:
> 
> Try: grep -r 'virtual/glibc' /usr/portage
> 
> That might help find the broken ebuild/metadata. You might want to try
> it in your overlays too.
> 

I had thought of doing the grep on /usr/portage, but you had a good
point in checking the overlay.  I discovered I had a glibc package
hidden in there, and after I nuked it the problem went away.  I'm not
quite sure why - it wasn't the version I was actually running.

In any case, I don't have nearly as much need for the overlay these days
- - I used to need it to unmask individual packages before the invention
of /etc/portage.

Thanks for the ideas!


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0vHRg2bN8aFizRkRAtoXAJ9lp8c5JaV9mOlv1+CNk2tx8v+dugCbBH7u
lOtwiLNe+op2Vlk5RZl6OI0=
=v3Np
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3999 bytes --]

[gentoo-amd64] Re: Messed up virtual/glibc?

[Duncan]

Richard Freeman posted <42D2F1D1.7080208@verizon.net>, excerpted below, 
on Mon, 11 Jul 2005 18:25:21 -0400:

> I had thought of doing the grep on /usr/portage, but you had a good point
> in checking the overlay.  I discovered I had a glibc package hidden in
> there, and after I nuked it the problem went away.  I'm not quite sure why
> - it wasn't the version I was actually running.

It wouldn't /have/ to be the version you had merged.  If a package appears
in the dependency tree or system requirements at all, it becomes part of
the dependency tree portage must calculate to see what's available and
match that against what's required.  If one of those packages has a
screwed up dependency that nothing matches, it screws up the dependency
calculation for the entire tree, as it did here.

If I'm piecing information I've read on gentoo-dev together correctly with
information I've gathered from other sources, what happened here is that a
former dependency on glibc itself has been virtuallized to a virtual/libc
dependency instead, thus allowing other libc implementations such as ulibc
(micro-libc, for embedded) and the FreeBSD libc (for the Gentoo-FBSD
project now nearing its first official release) to also provide
virtual/libc and fill the dependency in most instances.  Stuff that's in
the normal portage tree has of course been updated and kept in sync so
there's no issue there.  However, ebuilds in the overlay are be definition
not updated with the portage tree, so that ebuild in your overlay wasn't
updated to reflect the necessary changes, and when the changes got drastic
enough, began causing issues.

Once you figure it out, the fix is easy enough -- deleting or changing the
old ebuilds in the overlay.  Unfortunately, with portage's dependency
tracking blown up, it's not possible for it to map the dependencies it
needs to be able to figure out what went wrong, only to point out which
dependency is broken, and an error message to that effect doesn't always
point one at the real problem, particularly for someone who doesn't
have at least a minimal understanding of the sorts of things portage has
to do to actually sort all this stuff out.

Really, it continues to amaze me how well portage actually /does/ do in
calculating dependencies, or rather, that it does it so well in such
little time, instead of taking hours to actually figure it all out.  That
it can manage all that in almost real-time, in the few seconds (if the
data is cached) to minutes (if it must be read in from disk) it actually
takes, is truly amazing, when I think about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list