This came to light while doing "Bob P" Stage 3/1 2005.0 install I got an error while doing the emerge -e system (with an i686 gcc installed) that while trying to emerge "python-fchksum" it could not find the i386 gcc Basically in the "emerge -e system" python-fchksum was being emergeed before python. Shouldn't python-fchksum depend on python? In the ebuild for python-fchksum it states? QUOTE # Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-python/python-fchksum/python-fchksum-1.6.1-r1.ebuild,v 1.25 2004/12/14 09:45:23 eradicator Exp $ # DON'T inherit distutils because it will cause a circular dependency with python #inherit distutils DESCRIPTION="Python module to find the checksum of files" SRC_URI="http://www.dakotacom.net/~donut/programs/fchksum/${P}.tar.gz" HOMEPAGE="http://www.dakotacom.net/~donut/programs/fchksum.html" KEYWORDS="amd64 x86 ppc sparc alpha hppa mips ia64" LICENSE="GPL-2" SLOT="0" IUSE="" DEPEND="sys-libs/zlib" src_compile() { python setup.py build || die } src_install() { python setup.py install --root=${D} || die } Note in the DEPEND no mention of python, but python is use ni the src_compile/install. What if python was unmerged (by accident) and someone tried to emerge "python-fchksum" it would fail on trying to find the command "python", IF python was stated in the DEPEND, then python would be pulled in first. This also would correct a few ppl who have had this problem with the (unsupported by Gentoo) stage 3/1 2005 install Reproducible: Always Steps to Reproduce: 1. 2. 3.
Could you explain what this is please: "Bob P" Stage 3/1 2005.0 If someone ignores the warning about removing Python, I don't see how adding python to the DEPEND on this would change anything. Please clarify.
If you see what you pasted it says there is a circular dependency, so we can't add Python to the DEPEND. Closing.
mmm strange my reply didnt get posted this morning. Sorry, anyway this bug (of sorts) was posted last night when I was a bit drunk Basically If you do a "emerge -e system" python-fscksum gets emerged before python. Now If you went an upgraded your compiler (say you were on i386 and not i686) Python is hardcoded with the compiler version it was compiled with. If you then did the emerge -e system (or even just emerge python-fscksum) it would complain because it cannot find i386-gcc just a small thing and I can see the cyclic reducnacy thing ( now ) sorry for the waste of time Jon
Hi, Today I studied the how python's distutils module work to see if I could resolve the bug of dev-python/python-fchksum not emerging when doing emerge -e system right after uclibc's stage1 scripts/bootstrap.sh. And the problem can be resumed in the following: 1) Because of the current dependencies between python and python-fchksum, python-fchksum is emerged before python with emerge -e system. 2) python-fchksum uses setup.py to build, which uses the distutils module. And this module configures the build process to use exactly the same compiler and linker as the ones that were used to build python. 3) In stage1-x86-uclibc-2005.0 was compiled with "CC= i386-gentoo-linux-uclibc-gcc -pthread" which is an invalid compiler if CHOST= was changed before running scripts/bootstrap.sh in stage1. (2) definitely makes a lot of sense, so it should stay the way it is. (There is a way to pass CC, CXX (and starting form python 2.4 LDSHARED) to setup.py, but I think it's a very bad idea for modules.) (3) It is a very common situation to change CHOST in stage1, but this does not affect some other stage1 tar.bz2s as their python was compiled with "CC= gcc -pthread" (this is the case of stage1-x86-2005.0 and stage1-x86-uclibc-2004.3), but I think it's not the way to go as this just uses the assumption that there will always be a working "gcc" to do the work instead of solving the problem. Also this will make portage behave badly in case there will ever be support for crosscompilation. (1) I think that this is the way to attack this problem. First of all, this does not create a circular dependency (not at all like openssl <-> python). So I think dev-python/python-fchksum should DEPEND on dev-lang/python and dev-lang/python should PDEPEND on dev-python/python-fchksum. In this case all the real dependencies should be in it's place (I'll fundament this in "Additional Info") and emerge should emerge them in the right order (I'll test this later and comment). Additional Info: Form Comment #1 we can see that dev-python/python-fchksum to be build. Form dev-lang/python/python-*.ebuild: # NOTE: The dev-python/python-fchksum RDEPEND is needed so that this python # provides the functionality expected from previous pythons. # NOTE: python-fchksum is only a RDEPEND and not a DEPEND since we don't need # it to compile python. We just need to ensure that when we install # python, we definitely have fchksum support. - liquidx From $ man 5 ebuild: DEPEND This should contain a list of all packages that are required for the program to compile. RDEPEND This should contain a list of all packages that are required for this program to run (aka runtime depend). If this is not set, then it defaults to the value of DEPEND. You may use the same syntax to vary dependencies as seen above in DEPEND. PDEPEND This should contain a list of all packages that will have to be installed after the program has been merged. You may use the same syntax to vary dependencies as seen above in DEPEND. And with respect to the python-fchksum compilation problem: >>> Source unpacked. ['setup.py', 'build'] running build running build_ext building 'fchksum' extension creating build creating build/temp.linux-i686-2.3 i386-gentoo-linux-uclibc-gcc -pthread -fno-strict-aliasing -DNDEBUG -march=pentium4 -O3 -pipe -fPIC -I/usr/include/python2.3 -c md5.c -o build/temp.linux-i686-2.3/md5.o gcc-config error: Could not run/locate "i386-gentoo-linux-uclibc-gcc" error: command 'i386-gentoo-linux-uclibc-gcc' failed with exit status 1 !!! ERROR: dev-python/python-fchksum-1.7.1 failed. !!! Function src_compile, Line 20, Exitcode 1 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. Yuri.
good analysis of the possible solution here. PDEPEND is a little strange for my liking. i've used it before and it has caused more headaches than it has solved (see: openjade and opensp). if we can prove that it doesn't fail for GRP, Stage 1 & 2 building and emerge -e system, then i'd be happy to accept that change. on further analysis of the problem, missing fchksum for some parts of building is alright because portage_checksum.py has a fallback function if fchksum isn't found. thats very nice. in fact, i sometimes think that it should be sys-apps/portage that should have fchksum dependency and not python. but there's too much legacy here that i don't want to touch :)
I tested the fallback function and it isn't enough for portage to work correctly (it looks like it works but on emerge -e system from stage1 to stage2 it just restarts the whole emerge after emerging portage instead of continuing), so python-fchksum definitely needs to be in portage DEPEND. Then I made another two tests. One without python-fchksum in python's *DEPEND at all, and another with python-fchksum in python's PDEPEND. And they both behaved in the correct way with respect to emerge -e system (the order was python, then python-fchksum and then portage). And the good thing is that it worked fine with uclibc's stage1. So I also think the best solution will be to remove python-fchksum from python's *DEPEND, but I don't know how many packages there are that really depend on python-fchksum while they don't have it in *DEPEND. And if there are many of them I'm sure they'll be hard to track as python-fchksum should definitely be installed as portage's dependency. So it may make sense to just change it to be in python's PDEPEND. Let me know if you want me to do any GRP/stages tests. And of you do, where can I get the official catalyst scripts to make the tests with. Yuri.
*** Bug 97233 has been marked as a duplicate of this bug. ***
*** Bug 91949 has been marked as a duplicate of this bug. ***
This is fixable .... as the bug here is quite quite evil as it turns out when python builds some sort of "compile" object to actually DO the build, it's pulling in values from the prior i386-...-gcc build of python. Evil! Evil! Evil! I've found that the python code DOES respect the setting of CC! so simply said, export CC gets the .c->.o build step to work The link step for the library however ... well this is where one needs their lightsabre and full jedi powers. The link step CC value setting obscure it is. Uses strange place to grab CC setting it does. Respect CC environment variable it does not. /usr/lib/python2.3/config/Makefile getting CC value from it is. Yoda help! More as I figure it out.....
python 2.4 respects the LDSHARED (it's value is used as the program to link the module) environment variable, python 2.3 does not (see /usr/lib/python2.{3,4}/distutils/sysconfig.py). But I still think that it is reasonable/sane to build python modules with the same settings as python itself and as this is a dependencies issue I think it should be resolved in that area without any non logical workaround (like changing CC and LDSHARED). Yuri.
Reopening. Per recent conversation on #gentoo-dev this is not dependencies issue, the explanation in comment #9 is correct.
stage1-x86-2005.1_pre1 is showing the same problems, this should probably be fixed before the release.
So currently no work-around exists for python2.3? Setting CC= resolves the compile phase, but not the link phase...
FYI: I temporarily changed CC=gcc in /usr/lib/python2.3/config/Makefile and got it to go past the link stage with emerge --resume.
Same here. Same error, same workaround.
sad to say. but this bug just hit me in 2005.1 release when installing on a new pentium4 system. the workaround listed in comment #14 worked, but on would hope this was fixed before a release. does it affect all new installs or just on rare occasions?
As far as I can tell, it affects all stage1 installations where the user changes CHOST.
Exactly, and chaning CHOST is what almost all stage1 users do :-)
*** Bug 102492 has been marked as a duplicate of this bug. ***
Same here. Comment #14 worked for me. 2005.1 stage1 install ~x86
I performed a test at the request of kloeri for a fix he proposed. Everything worked out fine. Steps I took: 1) Used stage1 x86 2005.1 tarball 2) Edited make.conf and changed CHOST from i386 to i686 3) Added USE="python" 4) Edited the dev-lang/python-2.3.5.ebuild and changed: RDEPEND="${DEPEND} dev-python/python-fchksum" to: PDEPEND="${DEPEND} dev-python/python-fchksum" 5) Bootstrapped and did 'emerge -e system' Everything built with no problems.
Fixed in ~arch. I'll add the fix to arch in ~12 hours if no weird bug reports show up.
2005.1 stage 1. fix does work. strange bug, but it is even more strange, that this has come to 2005.1 final...
Not really... We don't go around changing CHOST, as there's no benefit to doing so, other than not seeing a "i386" when doing merges and such. Anyway, I'm glad to see that it will be resolved. Luckily, it only affects stage1 builds, so once this hits the tree, it'll fix it for everyone.
This is not really a bug in the stages and I'm pretty sure you'll hit the bug even with older stages.. That said, I just added the fix to stable versions of python and the fix should hit rsync mirrors in a few hours.
*** Bug 102781 has been marked as a duplicate of this bug. ***
*** Bug 102898 has been marked as a duplicate of this bug. ***
*** Bug 89541 has been marked as a duplicate of this bug. ***
I ran into this error again when prograssing from a Stage2->Stage3. I started with an x86 Stage1 (changed CHOST to i686-pc-linux-gnu) and a portage tree that was current as of today (8/21/05). When running 'emerge -e system' on the stage2 I encountered the same error as described above. The system tries to compile python-fchksum with i386-pc-linux-gnu-gcc and gcc-config can't find it. Bryan
I ran into this error again when prograssing from a Stage2->Stage3. I started with an x86 Stage1 (changed CHOST to i686-pc-linux-gnu) and a portage tree that was current as of today (8/21/05). When running 'emerge -e system' on the stage2 I encountered the same error as described above. The system tries to compile python-fchksum with i386-pc-linux-gnu-gcc and gcc-config can't find it. Bryan Østergaard said that a fix had been committed to the stable ebuild for python, but I certainly don't seem to be reaping its benifits.
Oh yes -- here is my 'emerge info' since I've unmasked GCC 3.4.4: Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Unknown CPU Type Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X aac aalib acl acpi aim alsa arts audiofile avi bash-completion berkdb bitmap-fonts bluetooth bonobo bzip2 cdr crypt cups curl doc dvd dvdr dvdread eds emboss encode evo fam fastcgi ffmpeg foomatic foomaticdb fortran gcj gdbm gif gnome gnutls gpm gps gstreamer gtk gtk2 gtkhtml icq imlib ipv6 jabber jack jpeg kde libg++ libwww mad maildir mikmod mime mmx mng motif mp3 mpeg msn mysql mysqli nas ncurses nls nptl ocaml offensive ogg oggvorbis openal opengl oscar oss pam pdflib perl php png postgres ppds python qt quicktime readline ruby samba scanner sdl spell sse ssl svg svga tcpd theora truetype truetype-fonts type1-fonts usb vorbis wifi wmf wxwindows xml2 xmms xprint xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Robin, what does the cvs header line of dev-lang/python/python-2.3.5.ebuild say? If it doesn't say v1.22 (or later) it isn't fixed and you need to update your portage tree. As there's been an issue lately with some RSYNC mirrors you might want to leave out SYNC=.. from /etc/make.conf while updating your portage tree.
*sigh* Why do people insist on changing their CHOST setting anyway? I'm very interested in knowing if this is fixed in newer versions, so please report back to this bug if this resolves the issue for you.
*** Bug 103820 has been marked as a duplicate of this bug. ***
The version number of the current stable python ebuild is 1.22 on my system.
*** Bug 105515 has been marked as a duplicate of this bug. ***
*** Bug 105514 has been marked as a duplicate of this bug. ***
My ebuild seems to already have the RDEPEND changed to PDEPEND but its still producing this error, after i applied the "USE" flag it still shows it coming after dev-python/python-fchksum. what would happen if i simply emerged python before the emerge -e system?
I had the same problem. Yesterday I started a stage1 install, and I changed CHOST to i686-pc-linux-gnu When I emerged python, and then tried to emerge python-fchksum, it worked. ~Lex
I had the same issue today going from stage1 - stage2 emerge -e system I changed the line in /usr/lib/python2.3/config/Makefile along the lines of comment #14, from CC=i386-pc-linux-gnu-gcc -pthread to CC=i386-pc-linux-gnu-gcc -pthread this let the emerge continue with emerge --resume, but really its just a hack. Responding to comment #32: Gentoo is about choice, and I choose to change my CHOST setting!
Sorry, should have been CC=i386-pc-linux-gnu-gcc -pthread to CC=i686-pc-linux-gnu-gcc -pthread
(In reply to comment #39) > Responding to comment #32: Gentoo is about choice, and I choose to change my > CHOST setting! No, it isn't. Gentoo is about *empowering* the user to make choices. We don't allow choice for the simple sake of choice, otherwise we would have a convoluted mass of nonworking junk. Basically, if you're changing your CHOST settings, *AGAINST THE ADVICE OF THE DEVELOPERS*, which is nothing more than a *COSMETIC* change anyway, then you should be willing and knowledgeable enough to pick up the pieces when it vomits all over your system. Now, we're working to "fix" this "problem" for the people that *insist* on maintaining a broken behavior, but it has nothing to do with "choice" or any lack thereof and more to do with protecting our users from themselves. All of that being said, I modifed catalyst to use CHOST=i686-pc-linux-gnu by default, so the stage1 tarballs will have that as a default now. This should appease everyone who thinks a directory being named i386* actually affects their system in any way. ;]
(In reply to comment #40) > Sorry, should have been > > CC=i386-pc-linux-gnu-gcc -pthread > > to > > CC=i686-pc-linux-gnu-gcc -pthread Hmmm, that won't work for people with an i586. What about changing it to: CC=${CHOST}-gcc Just a thought. BTW: the python-fchksum.ebuild calls ``python setup.py''. If I do an: find / -name setyp.py I get /usr/portage/app-emacs/python-mode/files/setup.py /usr/portage/dev-python/reportlab/files/1.14/setup.py /usr/portage/dev-python/reportlab/files/1.17/setup.py /usr/portage/dev-python/formkit/files/0.6.1/setup.py Which of these setup.py the ebuild uses? Well, and yes, if python is installed BEFORE emerge system the build don't fail.
As a noob that reads and follows the Handbook, need to ask Chris for an explanation on Comment #41: > if you're changing your CHOST settings, > *AGAINST THE ADVICE OF THE DEVELOPERS* I am not a native speaker so it might be my fault misunderstanding the Handbook, but IMHO there is no any notion anywhere there that stage1 users are advised *not to* change the CHOST variable. Or do I miss something? > which is nothing more than a *COSMETIC* change anyway That sounds nice; well, why isn't this in the Handbook as well? Instead, we have this: "The CHOST variable defines what architecture gcc has to compile programs for." Does it sound strange then that people decide to use stage1 *so that they can change CHOST* ?? Finally, my stage1 installation just failed with this same error, wasting hours of my time and this really kills me as I am in a situation where I don't have plenty of it. Sadly, the bug is indeed frustrating for many users (check the forums for python-fchksum), but for me the attitude of Comment #41 is *hundred times* more frustrating. This is the kind of attitude I was trying to escape from, that brought me to Gentoo.
(In reply to comment #42) > BTW: the python-fchksum.ebuild calls ``python setup.py''. > If I do an: > find / -name setyp.py > I get > /usr/portage/app-emacs/python-mode/files/setup.py > /usr/portage/dev-python/reportlab/files/1.14/setup.py > /usr/portage/dev-python/reportlab/files/1.17/setup.py > /usr/portage/dev-python/formkit/files/0.6.1/setup.py > > Which of these setup.py the ebuild uses? None of them. It uses the one in the python-fchksum tarball.
(In reply to comment #43) > > if you're changing your CHOST settings, > > *AGAINST THE ADVICE OF THE DEVELOPERS* > > I am not a native speaker so it might be my fault > misunderstanding the Handbook, but IMHO there is no any > notion anywhere there that stage1 users are advised *not > to* change the CHOST variable. Or do I miss something? You're correct. This is not listed in the Handbook. I will ask them to change this now so there won't be any confusion. I also noticed that the make.conf.example has been changed from "# DO NOT CHANGE THIS SETTING UNLESS YOU KNOW WHAT YOU ARE DOING!" to "# DO NOT CHANGE THIS SETTING UNLESS YOU ARE USING STAGE1!" for the CHOST description, so I apologise that this valuable piece of information has become lost to users. > > which is nothing more than a *COSMETIC* change anyway > > That sounds nice; well, why isn't this in the Handbook as well? > Instead, we have this: > > "The CHOST variable defines what architecture gcc has to > compile programs for." > > Does it sound strange then that people decide to use stage1 > *so that they can change CHOST* ?? Architecture is not the same as sub-architecture. Anything i386 or i686 is all the same architecture. If you were to change this to something like ppc-unknown-linux-gnu, then you would be changing the architecture. Again, I'll file bugs to have this text adjusted so it is less ambiguous. > Finally, my stage1 installation just failed with this > same error, wasting hours of my time and this really > kills me as I am in a situation where I don't have > plenty of it. I'm sorry to hear that, but this is not my fault. You could have easily chosen a stage3 installation and saved yourself a good number of hours in doing your installation. In fact, doing a stage3 installation, making changes to make.conf, performing an "emerge sync" and running an "emerge -e world && emerge -v depclean" is faster than doing a stage1 installation, with the same net result. I'm also going to make sure that this is documented quite well in the Handbook, as many users are under the impression that a stage1 actually gives them *any* form of positive outcome. The truth is that it is a complete waste of time for anyone not doing extensive changes to their system and massive customizations (like those not available via portage itself) and honestly should not be recommended to *any* user. > Sadly, the bug is indeed frustrating for many users > (check the forums for python-fchksum), but for me > the attitude of Comment #41 is *hundred times* more > frustrating. This is the kind of attitude I was trying > to escape from, that brought me to Gentoo. There was no attitude given. I was simply using changes in writing style to point out things that are more important. As a non-English speaker, I can understand that you might interpret this wrongly.
Bug #105809
Chris: thank you for the calm reply and for your apology (which is quite appropriate in a case when following the advice of the documentation brings to a broken build.) I'll comment the technical issues within the new bug. Good luck! P.S. Many an open source project turned into cold war between developers and users. But if it was up to me, I would say that 'Gentoo is all about attitude'. I have always been welcomed and appreciated, and I've tried to return the same back. Sometimes things break, but I value good attitude more than that. So let us try to keep Gentoo as an island of good will for a little longer. Cheers!
*** Bug 105983 has been marked as a duplicate of this bug. ***
Everyone is saying that changing CHOST is just for "cosmetics." But when I've tried installing glibc with nptl it requires a minimum CHOST value and would not accept using i386. So unless the devs that support glibc just did that arbitrarily, there seems to be something more than "cosmetics." Also, couldn't this problem be fixed by just adding dev-lang/python to the end of bootstrap.sh? This would avoid everything that depends on python that was compiled for a specific CHOST.
(In reply to comment #49) > Everyone is saying that changing CHOST is just for "cosmetics." But when I've > tried installing glibc with nptl it requires a minimum CHOST value and would > not accept using i386. So unless the devs that support glibc just did that > arbitrarily, there seems to be something more than "cosmetics." It's arbitrary. Changing CHOST has no effect other than changing the location of the toolchain files. > Also, couldn't this problem be fixed by just adding dev-lang/python to the end > of bootstrap.sh? This would avoid everything that depends on python that was > compiled for a specific CHOST. Stage size is the primary concern here. We don't want them getting bigger. Besides, that is treating the symptom, not the problem.
*** Bug 96641 has been marked as a duplicate of this bug. ***
Um, I could be wrong, but doesn't portage automatically use the built-in md5 if "import fchksum" fails? Thus, it should be possible to have python-fchksum in system depending on python, and not a PDEPEND of python itself.
(In reply to comment #50) > (In reply to comment #49) > > Everyone is saying that changing CHOST is just for "cosmetics." But when I've > > tried installing glibc with nptl it requires a minimum CHOST value and would > > not accept using i386. So unless the devs that support glibc just did that > > arbitrarily, there seems to be something more than "cosmetics." > > It's arbitrary. Changing CHOST has no effect other than changing the location > of the toolchain files. unfortunately it does have a big effect. try this on an x86 machine. - change CHOST in /etc/make.conf to i686-pc-linux-gnu. - USE="nptl nptlonly -linuxthreads-tls" emerge -aDv glibc >>> emerge (1 of 1) sys-libs/glibc-2.3.5.20050722 to / >>> Unpacking source... * Checking gcc for __thread support ... yes * Checking kernel version (>=2.6.6) ... yes * Checking linux-headers version (>=2.6.6) ... yes [snip] * Configuring GLIBC for nptl with: --disable-nls --disable-dev-erandom --enable-omitfp --with-tls --with-__thread --enable-add-ons=nptl,c_stubs,libidn --enable-kernel=2.6.6 --without-selinux - change CHOST in /etc/make.conf to i386-pc-linux-gnu. - USE="nptl nptlonly -linuxthreads-tls" emerge -aDv glibc >>> emerge (1 of 1) sys-libs/glibc-2.3.5.20050722 to / >>> Unpacking source... [snip] * Configuring GLIBC for linuxthreads with: --disable-nls --disable-dev-erandom --enable-omitfp --without-tls --without-__thread --enable-add-ons=linuxthreads,c_stubs,libidn --enable-kernel=2.4.1 --without-selinux that's hardly arbitrary.
I didn't add dev-lang/python to DEPEND in python-fchksum for two reasons. 1. I'm slightly scared that might introduce a circular dependency. 2. It does nothing to solve the problem as python is already emerged and I really need a way to force rebuilding of python before python-fchksum to solve the problem completely. The current PDEPEND in python solves the problem if only people followed the handbook properly and remembered to emerge -e system after bootstrapping. I don't think it's currently possible (or advisable) to support other paths when changing CHOST. Too many other things can (and almost always) go wrong like broken libc and gcc when arbitrarily changing CHOST.
(In reply to comment #41) > No, it isn't. Gentoo is about *empowering* the user to make choices. We don't > allow choice for the simple sake of choice, otherwise we would have a convoluted > mass of nonworking junk. Basically, if you're changing your CHOST settings, > *AGAINST THE ADVICE OF THE DEVELOPERS*, which is nothing more than a *COSMETIC* > change anyway, then you should be willing and knowledgeable enough to pick up > the pieces when it vomits all over your system. Wrong. People change CHOST, because the documentation says so. Since it is the Gentoo documentation, it's the task of Gentoo to fix problems it created. Also, in the Gentoo documentation, I cannot find any advice at all, that the CHOST should NOT be changed. Actually, the opposite is true. If you'd like people to not change CHOST, you should file a bug to change the documentation. > Now, we're working to "fix" > this "problem" for the people that *insist* on maintaining a broken behavior, That the documentation suggests to make. Important difference! Actually, upon closer reading the documentation, there's *VERY* strong suggestion to MAKE THAT CHANGE. > but it has nothing to do with "choice" or any lack thereof and more to do with > protecting our users from themselves. > > All of that being said, I modifed catalyst to use CHOST=i686-pc-linux-gnu by What about i486 and i586 users?
(In reply to comment #55) > Wrong. People change CHOST, because the documentation says so. Since it is the > Gentoo documentation, it's the task of Gentoo to fix problems it created. Also, > in the Gentoo documentation, I cannot find any advice at all, that the CHOST > should NOT be changed. Actually, the opposite is true. > > If you'd like people to not change CHOST, you should file a bug to change the > documentation. Where do the docs say such a thing? The only reference to CHOST in the handbook has a big fat warning at the top.
(In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 ) > Where do the docs say such a thing? The only reference to CHOST in the handbook > has a big fat warning at the top. 1) The 2005.1 guide states "Users interested in bootstrapping their entire system with NPTL support on an x86 system need to set their CHOST to i586-pc-linux-gnu or higher." 2) The warning you mention clearly says that people who aren't doing stage1 installs should leave CHOST unchanged. This isn't saying "Don't change CHOST." (Confirming http://bugs.gentoo.org/show_bug.cgi?id=88777#c53 ) When I had CHOST="i386-pc-linux-gnu" glibc was compiled with "--without-tls" and when I changed CHOST back to "i386-pc-linux-gnu" emerging glibc compiled it with "--with-tls".
(In reply to comment #57) > (In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 ) > > Where do the docs say such a thing? The only reference to CHOST in the handbook > > has a big fat warning at the top. > > 1) The 2005.1 guide states "Users interested in bootstrapping their entire > system with NPTL support on an x86 system need to set their CHOST to > i586-pc-linux-gnu or higher." > > 2) The warning you mention clearly says that people who aren't doing stage1 > installs should leave CHOST unchanged. This isn't saying "Don't change CHOST." Both means you're doing a stage1 install following the handbook, and then changing CHOST can work (and the fix mentioned here solves only that scenario). And I still don't see any encouragement to change CHOST. Disclaimer: I only read up comment #54 and following, and the top comments that actually deal with this bug, so I missed all the unrelated stuff from Chris and thought comment #55 was somehow related to comment #54. Seeing now that this is not completely the case feel free to ignore my comments. @Chris: if catalyst now defaults to i686 CHOST, is there any reason for catalyst to set CHOST in make.conf at all? If not, maybe the best idea would be to remove it from make.conf in the stages as it's already set in the profiles.
Changing CHOST default to 686 means all users wanting to install gentoo on pentiums, k6, first gen epias and a bunch of other cpus will have to change their CHOST back to 586. That means the problem can still arise if people don't follow the manual which clearly states that changing CHOST should be immediately followed by an emerge -e world. My understanding of the doc is that CHOST should only be changed during a stage1 install, and only if needed (nptl for instance). If it were such a terrible thing to do, then the doc should be improved to reflect those views. Now if this bug has been fixed but is still getting dupes (at least two or three every week) maybe the doc should also be changed so that stage1 users don't forget to run through emerge -e world. (I know it's written, I read it, but maybe saying it differently or in Big Bright Red Block Letters will do the trick) Maybe portage could be used to figure out if CHOST matches the one in, say, bash. If CHOST and the CHOST used to compile bash are different, notify the user that something fishy's going on and that he should run emerge -e world to have a coherent system.
(In reply to comment #56) > Where do the docs say such a thing? The only reference to CHOST in the handbook > has a big fat warning at the top. The docs at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part1_chap5__chap5_sect2 say so. And there's no warning. The only warning that's there, is not relevant for stage-1 users.
(In reply to comment #58) > (In reply to comment #57) > > (In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 ) > > > Where do the docs say such a thing? The only reference to CHOST in the handbook > > > has a big fat warning at the top. > > > > 1) The 2005.1 guide states "Users interested in bootstrapping their entire > > system with NPTL support on an x86 system need to set their CHOST to > > i586-pc-linux-gnu or higher." > > > > 2) The warning you mention clearly says that people who aren't doing stage1 > > installs should leave CHOST unchanged. This isn't saying "Don't change CHOST." > > Both means you're doing a stage1 install following the handbook, and then > changing CHOST can work (and the fix mentioned here solves only that scenario). No, changing CHOST does NOT work. When you do a stage1 install and set the make.conf the way it's reqd. (which, according to the docs, includes changing CHOST), the "emerge -e system" will stop at python-fchksum. > And I still don't see any encouragement to change CHOST. Well. Then please read the docs. | Users interested in bootstrapping their entire system with NPTL support on an x86 system need to set their CHOST to i586-pc-linux-gnu or higher.
(In reply to comment #59) > Changing CHOST default to 686 means all users wanting to install gentoo on > pentiums, k6, first gen epias and a bunch of other cpus will have to change > their CHOST back to 586. That means the problem can still arise if people don't > follow the manual which clearly states that changing CHOST should be immediately > followed by an emerge -e world. No, it doesn't say so. When doing a stage 1 install, make.conf and CHOST is changed before anything else is done. It's changed *BEFORE* "emerge -e system". And in THIS case, users will get stopped when pyhton-fchksum is to be compiled. Or do you suggest to do "emerge -e world" *BEFORE* doing the very first, initial "emerge -e system"? If so, then that's not covered by the handbook at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 > My understanding of the doc is that CHOST should only be changed during a stage1 > install, and only if needed (nptl for instance). Well, the docs make it sound, as if it were a must to change CHOST when nptl is used. In other cases, it sounds to me, as if the user is free to change the setting at will (if done soon enough). > If it were such a terrible > thing to do, then the doc should be improved to reflect those views. Yes, that's exactly right. > Now if this bug has been fixed but is still getting dupes (at least two or three > every week) maybe the doc should also be changed so that stage1 users don't > forget to run through emerge -e world. (I know it's written, I read it, but Where is it written? Reading the handbook, I cannot find anything wrt this.
Is there a chance that we can quit this discussion on this bug? I've already posted Bug #105809 to have all of this resolved in the Handbook. CHOST is *purely* cosmetic on x86. The fact that the glibc ebuild uses it to determine whether nptl can be used or not is a *bug* and not a good argument, since it is *wrong* to do that kind of check. As for the CHOST being i686-pc-linux-gnu by default, that *does not matter* for i486/i586 users in any way, as it is *cosmetic* and does not change the output of GCC in any way. Only compiler settings via CFLAGS actually changes the compiled output. Let me say this again for those of you not paying much attention and wanting to continue beating this dead horse. ONLY COMPILER SETTINGS VIA CFLAGS ACTUALLY CHANGES THE COMPILED OUTPUT. CHOST has no effect.
Just as an update - I bugged the fact that glibc compiles differently when only changing CHOST. http://bugs.gentoo.org/show_bug.cgi?id=106556
Can someone help? That bug I posted (where glibc is built differently based on changing your CHOST value) was resolved as invalid by vapier. He said that the behavior described is valid. So it seems that changing CHOST isn't for "cosmetics" after all.
Spectacular, except I followed the instructions yesterday on running a stage-1, exactly as the handbook stated, changing my CHOST for NPTL (because I can't get it any other way), doing a bootstrap, and then doing emerge -e system. Guess what? This bug is *NOT* resolved! I don't care about your personal opinions about beating this to death; it's a bug, and following the instructions leaves the user staring at an error with no idea how to continue. This bug should remain *OPEN*, not closed, until the bug is fixed or the root cause (users NEED to change CHOST) is eliminated. Fix glibc, then you can fix this.
*** Bug 89009 has been marked as a duplicate of this bug. ***
Just to make something clear. Changing CHOST is actually needed for NPTL-support as NPTL hasn't been ported to i386. https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00035.html "i386 (and sparc < v9) lacks atomic instructions powerful enough for NPTL needs."
This bug should not be closed. It pretty much renders any custom install of gentoo using NPTL pointless because it will fail every time. I build all of my boxes from stage1 with CHOST set to i686 because I require nptl. Following the instructions as-is to install from stage1 in the Gentoo Handbook, the emerge -e system fails. It has not always failed, cannot tell you when it started, but I know the failure started somewhere between 2005-07-07 and 2005-08-26. If you cannot follow the instructions in the Gentoo Handbook to achieve a stage1 install with NPTL, there is not much point to using gentoo. This bug is breaking the entire distrib and should be resolved before blaming users and glibc.
You do know that there's a solution and we aren't going to bother reading any more of this bug, right? In fact, I know that I quit paying attention a long time ago, specifically around comment #46 where I filed a bug for the documentation resolution, along with making modifications to our release tools. The truth is that I know what glibc does, and I still think it is incorrect, and yes, I've read the bug report on glibc and how it acts, so don't bother going on quoting it, I can read myself. Basically, you guys are continuing to beat a dead horse with absolutely no net gain, as this won't be able to be resolved quickly as it requires a new Gentoo release to properly fix. Again, if you're doing a stage1 installation, *especially* if you're doing NPTL, then you're kinda on your own (and always have been). I mean, have you thought about trying to fix your system yourself? After all, there's nowhere in the Handbook describing doing a NPTL-based installation, you came up with that on your own. What makes you think that fixing a system that is breaking due to your own actions isn't something that can be done yourself? I know that I'm probably not winning myself any friends or anything, but I'm honestly not running for president. We've said that this is resolved in portage, and it *is* resolved if you have proper release media. The 2005.1 release media is *not* sufficient for this task. Anyway, if you want a NPTL system, you should be doing a stage3 installation, as I said before, and making the changes to your system, then doing an emerge -e world. This is the recommended path going forward and it is quite likely that we will *only* be supporting this method in the future. The stage1 release media simply generates too many user-generated bugs that end up being the developer's problem.
in case someone else hits the "dead horse": uncomment #inherit distutils in python-fchksum-1.7.1.ebuild works fine with a 2005.1 stage 1
(In reply to comment #70) > After all, there's nowhere in the Handbook describing doing a NPTL-based > installation, you came up with that on your own. As pointed out earlier, from: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 "Users interested in bootstrapping their entire system with NPTL support on an x86 system need to set their CHOST to i586-pc-linux-gnu or higher."
NPTL is a standard USE flag, building with it has worked for me for months now. Something has recently broken and it is not glibc or using NPTL. I AM building from a stage1 -> stage3. It is the emerge -e system after the bootstrap that bombs. I am following the Gentoo Handbook exactly and it does not work. I just tried it again and it is still broken. Perhaps someone should add to the handbook "if you are building a stage3, after the bootstrap.sh re-emerge pythong before performing the emerge -e system".
I just added dev-lang/python to the python-fchksum dependencies which fixes the problem for now at least. Lets hope it doesn't cause circular dependencies down the road..
*** Bug 107457 has been marked as a duplicate of this bug. ***
*** Bug 107496 has been marked as a duplicate of this bug. ***
kloeri: I've been building stages with catalyst using a snapshot with python in the DEPEND of python-fchksum and it is still not working properly. For some reason, the depgraph is not pulling in python before python-fchksum. I think that we should probably REOPEN this and try to figure out what's going on here.
FWIW, I just did a stage1 install with changed CHOST setting - and python was pulled in just before python-fchksum, solving the previous problem I had (comment #14).
Re: comment #77 I had forgotten to also update python on the snapshot I was using. Once I did so, the problem went away. Good job on getting this one resolved, kloeri!
This is fixed with the 2005.1-r1 release media.
Hi, I've just installed a stable x86 chroot from a stage3 (2006.0). Now, doing an emerge -e world, python-fchksum-1.7.1 get emerged before python, causing this very same bug to happen. I can reproduce and give any additional info, if needed.
I
I´ve been into this bug 2 times. once when I changed my CHOST on an installed system(thats my own fault) AND the second time when downloading the latest stage2-i686-tarball I found for a testing-environment. I didnt change CHOST just CFLAGS and USE. Can anybody explain why the problem still exists more than half a year later in an almost new stage2-tarball? Shouldnt python be compiled with a i686-gcc if this causes this problem? Its easysolved if you know what the problem is and how to solve it but for other people it causes this "weird" problem.
(In reply to comment #84) I don't know if anybody even see's this bug anymore, but I just bumped into it myself. I used a stage3 x86 uclibc tarball that was I think quite recent, changed CHOST to i686, and I do belive emerge -e system and emerge -e world, both worked fine, but when installing python-checksum into my '/tinygentoo' dir it wanted to compile itself with the i386 gcc, which was of course long gone. remerging python in my buildsystem fixed it all, but it was still odd to say the least.
That's because you're not supposed to change CHOST, see comment #42. Thanks
