Summary: | Some versions of gcc-2.95 incorrectly provide texinfo | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Timmy Douglas <timmy+gentoo> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | bqjones, cadik60070, jan.wartenberg, plate, toddyarling, tradergt, uwe-bugzilla_gentoo_org, volchok |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 65921 | ||
Bug Blocks: | |||
Attachments: |
make.conf
debug output of emerge -pudD strace emerge -uDv world |
Description
Timmy Douglas
2004-09-16 19:22:21 UTC
can you sync up ? maybe it was a temp problem ... if not, do you have some bum config files ? Created attachment 39754 [details]
make.conf
'emerge sync' doesn't fix the problem. i attached my make.conf main apache # emerge -auD portage These are the packages that I would merge, in order: Calculating dependencies | emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-4.0". i meant do you have bum files in /etc/portage/ ? there is no gcc-4.0 ebuild nor are there any packages which depend on them ... main ~ # ls -lR /etc/portage/ /etc/portage/: total 0 drwxrwsr-x 2 root portage 6 9月 16 21:51 sets /etc/portage/sets: total 0 another thing that seems weird: (btw i tried changing my profile to "/usr/portage/profiles/gcc34-x86-2004.2" but that didn't work) main ~ # strace emerge --verbose -auD system 2> crap.out These are the packages that I would merge, in order: Calculating system dependencies | emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-4.3". !!! Problem with ebuild sys-apps/baselayout-1.10.4 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. main ~ # du crap.out 1464 crap.out main ~ # grep gcc-4 crap.out main ~ # Created attachment 39920 [details]
debug output of emerge -pudD
i added an attachment that might give some insight on why it is doing this.
Parent: ebuild / sys-devel/gcc-3.4.1-r2 merge Depstring: virtual/libc !uclibc? ( >=sys-libs/glibc-2.3.3_pre20040420-r1 ) !uclibc? ( hardened? ( >=sys-libs/glibc-2.3.3_pre20040529 ) ) ( !sys-devel/hardened-gcc ) >=sys-devel/binutils-2.14.90.0.8-r1 amd64? ( >=sys-devel/binutils-2.15.90.0.1.1-r1 ) >=sys-devel/bison-1.875 >=sys-devel/gcc-config-1.3.1 amd64? ( multilib? ( >=app-emulation/emul-linux-x86-baselibs-1.0 ) ) !build? ( gcj? ( gtk? ( >=x11-libs/gtk+-2.2 ) ) ) !build? ( gcj? ( >=media-libs/libart_lgpl-2.1 ) ) !build? ( >=sys-libs/ncurses-5.2-r2 nls? ( sys-devel/gettext ) ) !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/libtool ) sys-devel/gnuconfig virtual/libc !uclibc? ( >=sys-libs/glibc-2.3.3_pre20040420-r1 ) !uclibc? ( hardened? ( >=sys-libs/glibc-2.3.3_pre20040529 ) ) >=sys-devel/gcc-config-1.3.1 >=sys-libs/zlib-1.1.4 >=sys-apps/texinfo-4.2-r4 !build? ( >=sys-libs/ncurses-5.2-r2 ) Candidates: ['>=sys-devel/binutils-2.14.90.0.8-r1', '>=sys-libs/ncurses-5.2-r2', '>=sys-devel/gcc-4.2-r4', '>=sys-devel/bison-1.875', '>=sys-devel/gcc-config-1.3.1', 'sys-devel/patch', 'sys-devel/gettext', '!sys-devel/hardened-gcc', 'sys-devel/libtool', 'sys-libs/glibc', '>=sys-libs/zlib-1.1.4', '>=sys-libs/glibc-2.3.3_pre20040420-r1', 'sys-devel/gnuconfig'] ebuild: sys-devel/binutils-2.15.90.0.1.1-r3 binpkg: None ^^ That's cleary wrong but I don't see anything in the real portage tree that would yeild this.. emerge rsync and try again. emerging rsync/sync and trying again doesn't help.
>=sys-apps/texinfo-4.2-r4 !build? ( >=sys-libs/ncurses-5.2-r2 )
Candidates: ['>=sys-devel/binutils-2.14.90.0.8-r1', '>=sys-libs/ncurses-5.2-r2', '>=sys-devel/gcc-4.2-r4', '
looks like gcc is getting the same version number as texinfo.
Just to chip in here, he's not the only person experiencing this. I'm having the same problem, as described in my bug #64625 (now marked as duplicate of the _other_ problem I had...). Reverting to portage-2.0.50-r11 gets rid of that bizarre ">= gcc-4.3" error. seems to be from texinfo (DEPEND is on '>=sys-apps/texinfo-4.2-r4') and the fact that we have some crap like this in our profiles: default-ppc/virtuals:sys-apps/texinfo sys-devel/gcc makes me think that is the problem ... could you guys look in your virtuals file and see if there are any references like that ? i don't have any references of gcc in my make.profile/virtuals file. BUT: main ~ # grep gcc `locate virtuals` /var/cache/edb/virtuals:sys-apps/texinfo sys-devel/gcc /usr/portage/profiles/default-ppc/virtuals:sys-apps/texinfo sys-devel/gcc /usr/portage/profiles/default-linux/x86/gcc2/virtuals:# $Header: /var/cvsroot/gentoo-x86/profiles/default-linux/x86/gcc2/virtuals,v 1.5 2004/08/17 13:39:29 usata Exp $ /usr/portage/profiles/default-linux/x86/gcc31/virtuals:# $Header: /var/cvsroot/gentoo-x86/profiles/default-linux/x86/gcc31/virtuals,v 1.5 2004/08/17 13:39:29 usata Exp $ main ~ # grep gcc /etc/make.profile/* /etc/make.profile/make.defaults:# System-wide defaults for the >=gcc 3.2 Portage system /etc/make.profile/packages:# package *inclusion* mask. For example, the line *=sys-devel/gcc-2.95.3-r1 /etc/make.profile/packages:# will cause Portage to totally ignore all gcc ebuilds other than /etc/make.profile/packages:# gcc-2.95.3-r1. >=, <=, <, > and ~ can be used to offer a bit more /etc/make.profile/packages:# versions of binutils, gcc and glibc, so we lock them down here. This /etc/make.profile/packages:*>=sys-devel/gcc-3.3.3 /etc/make.profile/packages.build:sys-devel/gcc should i manually edit that file? just fix /var/cache/edb/virtuals and see if it goes away No, it doesn't go away. Fixing the line with texinfo and gcc, deleting that line, killing the entire virtuals file doesn't make it go away. portage guys: have a look at this eh ? Created attachment 40085 [details]
strace emerge -uDv world
Don't know if it's of any help, but here's an strace of emerge -uDv world
yeah, i tried removing the line and syncing again but it doesn't go away. Ok. No more traces please it's a virtuals issue. ls -l /etc/make.profile readlink /etc/make.profile find /var/cache/edb/virtuals /etc/make.profile -type f -name 'virtuals' -print0 | xargs -0 grep texinfo find /var/db/pkg -type f -name 'PROVIDES' -print0 | xargs -0 -n 500 grep texinfo Change that PROVIDES to PROVIDE I've seen this before.. Last time the issue was related to gcc-2.95.x being installed and/or not cleaned. If this is the case here as well, please don't unmerge it until we can figure out why it is causing it. :) main ~ # ls -l /etc/make.profile lrwxrwxrwx 1 root root 38 9月 19 00:02 /etc/make.profile -> /usr/portage/profiles/gcc34-x86-2004.2 main ~ # readlink /etc/make.profile /usr/portage/profiles/gcc34-x86-2004.2 main ~ # find /var/cache/edb/virtuals /etc/make.profile -type f -name 'virtuals' -print0 | xargs -0 grep texinfo main ~ # find /var/db/pkg -type f -name 'PROVIDE' -print0 | xargs -0 -n 500 grep texinfo /var/db/pkg/sys-devel/gcc-2.95.3-r5/PROVIDE:sys-apps/texinfo main ~ # Well, that's certainly the problem. I have no idea what past bug could have caused this to occur, but don't really care as we can't do anything about it. Suggested solution is for portage to ignore *any* PROVIDE that does not have the category "virtual". This may break a few packages (that are already broken IMO) but I can't see any other fix. Any objections? Interesting. Ghost of Christmas past? :) This particular host had its Gentooification in October 2002, and I upgraded to gcc 3.x in December that year, using the shell scripts Nick provided back then. # ls -l /etc/make.profile lrwxr-xr-x 1 root root 37 Oct 11 2002 /etc/make.profile -> /usr/portage/profiles/default-x86-1.4 # readlink /etc/make.profile /usr/portage/profiles/default-x86-1.4 Both find | grep statements yield the same results for me as for Timmy. well i'm going to remove the provide line and move along. thanks for the help. I've followed the instructions posted in comment #19, but all output is blank. Is there a way to genericize the procedure mentioned in comment #19? Did you take not of comment #20 and the s/PROVIDES/PROVIDE/ mistake? Comment #20 shows the exact procedure with some "sample" output. I just wanted to mention that it looks like this issue is only partially fixed. I'm attempting to preform a new installation, and the initial system build (after my stage2 failed, I tried a stage1 with the same result.) the emerge of portage and gcc (and everyting else really since texinfo seems to be a common dependancy) fails due to this dependancy. texinfo-4.6 (and every other current ebuild) fails with out an error message. This is based on the stages install found on the current livecd (2004.2). I guess I'll give it another try with an updated stages. *** Bug 69773 has been marked as a duplicate of this bug. *** General hotfix: echo "" > /var/db/pkg/sys-devel/gcc-2.*/PROVIDE It seems like there was actually such a PROVIDE in several of the gcc-2.x ebuilds. If this doesn't fix it please run a `grep -r sys-devel/texinfo /var/db/pkg/*/*/PROVIDE /var/cache/edb/virtuals` and post the output. *** Bug 69838 has been marked as a duplicate of this bug. *** *** Bug 70642 has been marked as a duplicate of this bug. *** Regarding Comment #30 The correct grep command should be: grep -r sys-apps/texinfo /var/db/pkg/*/*/PROVIDE /var/cache/edb/virtuals sys-apps not sys-devel I got bitten by this bug, too. My output of the grep command: /var/db/pkg/sys-devel/gcc-2.95.3-r5/PROVIDE:sys-apps/texinfo /var/cache/edb/virtuals:sys-apps/texinfo sys-devel/gcc Removing texinfo from "/var/db/pkg/sys-devel/gcc-2.95.3-r5/PROVIDE" fixed it. (In reply to comment #23) > Well, that's certainly the problem. I have no idea what past bug could have caused this to occur, but don't really care as we can't do anything about it. > > Suggested solution is for portage to ignore *any* PROVIDE that does not have the category "virtual". This may break a few packages (that are already broken IMO) but I can't see any other fix. > > Any objections? Still broken in 2.1_alpha, a patch to ignore virtuals entries that don't PROVIDE virtuals shouldn't be too difficult. *** Bug 84008 has been marked as a duplicate of this bug. *** gcc ebuilds ahven been fixed for ages and portage doesn't use the virtuals file anymore, so this bug doesn't apply anymore. |