| Summary: | Wrong tk use flag in pyopengl-2.0.0.44 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dominique Michel <dominique.c.michel> |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | normal | CC: | christian, eero, ethouris, funnyman3595, gentoo, grrlfox, kneczaj, nenolod |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
You can read this forum thread, because it is a different problem for different profiles: http://forums.gentoo.org/viewtopic-p-3581973.html#3581973 No, re-emerge python, the check is correct. There's no tcltk use flag for python, it's been changed to tk. (Just run emerge -NuDpv world to check). *** Bug 148264 has been marked as a duplicate of this bug. *** It seam at this brake the Gentoo Linux Installer (GTK+) at least on amd64. Abany on the same forum thread have reported: !! ERROR: dev-python/pyopengl-2.0.0.44 failed. Call stack: ebuild.sh, line 1539: Called dyn_unpack ebuild.sh, line 711: Called src_unpack pyopengl-2.0.0.44.ebuild, line 34: Called built_with_use 'dev-lang/python' 'tk' eutils.eclass, line 1614: Called die !!! dev-lang/python-2.4.3-r1 does not actually support the tk USE flag! !!! If you need support, post the topmost build error, and the call stack if relevant. Re-read Comment #2, there's nothing to fix here. And how will do an user that use the livecd to do a network less installation? It is a few users that complain at pyopengl on the live cd brake the installation. And it is nothing they can do because it is in the ebuild on the cd and they are doinf a network less install. So myabe at the name of this bug don't reflet the actual problem with it, problem that is at the live cd must be fixed about that. On http://forums.gentoo.org/viewtopic-t-477582-highlight-.html today: I have the same prob. when i try to install using the livecd... Im running on a pentium4. I downloaded it from this address http://mirror.uni-c.dk/pub/gentoo/releases/x86/2006.1/livecd/ and it's from sep 24 allso. So it is the last livecd. So I suggest at you reopen this bug and pass it to the devs they are responsable for this livecd, or at least ask them on that matter. I don't use it myself, but for what I can see on this forum thread, it is really a problem with it. Already told you twice to re-emerge python, so kindly do it. CLOSED. And again. It is people on the forum complaining at the livecd install is broken of this tcltk use flag. And it is not possible to do a sync with the livecd install. So how do you want at people without an internet connection but with this livecd installo re emerge python? How do you want at they do this? Or maybe, as they just said in the forum, at you are working for Redmond. And again, it is not for me, I have re installed python it was a long time ago, but I do have both a working installation and an intenet connection. Just read this fucking forum thread! And answer yourself to those people at you want not fix this fucking broken livecd! Sorry, but too much is too much! And we still won't and can't fix it. All the livecd stuff is just a snapshot of portage tree in a given moment. There's been one use flag, changed meanwhile -> emerge --sync, re-emerge python and stop ranting here. The problem is you can't use the GTK installer due to this problem. It crashes out and leaves you with no option but to wash, rinse, repeat, re-crash. By saying they won't fix the bug the developers have decided to make the graphical installer a waste of effort. In my case I went in and installed the old fashoned way (never HAVE gotten that graphical POS to work), but for anyone who is trying out Gentoo and hasn't done this a few hundred times before they're out of luck. Bad for them, bad for the community, bad for Gentoo, bad for Linux. Do these guys work in Redmond now? Dixit the users on the forum. And you want fix it? Yes, we won't fix this. We can't fix a snapshot of the tree in the past. It is other bug repport on the livecd that show that it is possible to fix it with a new snapshoot. But no matter, it is another possibility: upgrade the doc and tell the user at the gtk installer is broken and it it is just a waste of time to use it. Sure, everytime $package changes use flags, we'll release new stages. ;) *** Bug 151486 has been marked as a duplicate of this bug. *** *** Bug 152418 has been marked as a duplicate of this bug. *** *** Bug 157626 has been marked as a duplicate of this bug. *** *** Bug 159158 has been marked as a duplicate of this bug. *** *** Bug 162030 has been marked as a duplicate of this bug. *** *** Bug 171151 has been marked as a duplicate of this bug. *** *** Bug 171151 has been marked as a duplicate of this bug. *** *** Bug 189873 has been marked as a duplicate of this bug. *** If I have to upgrade Python to emerge this PyOpenGL thingie, then can't that just be put into the ebuild as a dependency so it just works instead of getting this incomprehensible "doesn't actually use tk flag" nonsense?... Good luck with that. The general attitude on this bug from the developers seems to be "I'll just close my eyes, put my fingers in my ears and hum real loud so that I can't tell that there's a problem." |
When emerging pyopengl-2.0.0.44, I get this: Calculating dependencies... done! >>> Emerging (1 of 1) dev-python/pyopengl-2.0.0.44 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking PyOpenGL-2.0.0.44.tar.gz ;-) >>> Unpacking source... >>> Unpacking PyOpenGL-2.0.0.44.tar.gz to /var/tmp/portage/pyopengl-2.0.0.44/work * Applying config.diff ... [ ok ] * Applying pyopengl-2.0.0.44-fix_togl.patch ... [ ok ] !!! ERROR: dev-python/pyopengl-2.0.0.44 failed. Call stack: ebuild.sh, line 1539: Called dyn_unpack ebuild.sh, line 711: Called src_unpack pyopengl-2.0.0.44.ebuild, line 34: Called built_with_use 'dev-lang/python' 'tk' eutils.eclass, line 1614: Called die !!! dev-lang/python-2.4.3-r1 does not actually support the tk USE flag! What I done was to midify the ebuild. I changed the line: if built_with_use dev-lang/python tk; then in: if built_with_use dev-lang/python tcltk; then and it worked.