Bug 250767
| Summary: | ghc-gtk2hs won't install with only 256MB RAM | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gregory D. Weber <gdweber> |
| Component: | ghc-gtk2hs | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | bos, haskell-devel, loupgaroublond, petersen, triage |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-05 01:12:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Gregory D. Weber
2007-08-03 14:51:39 UTC
I guess this is caused by the "ghc-pkg update --auto-ghci-libs" in %post, ie we generate the ghci object files at install time rather than duplicating the bits in the binary packages since they are quite large. Hmm, 256MB is quite a modest amount of memory for running a fedora desktop let alone ghc and gtk2hs... I guess it is a question of bandwidth vs cpu/ram requirements. Though I concede that usually in Fedora we prefer to do all the number crunching at buildtime rather than install time (eg unlike debian say that compiles elisp at install time). If only ghc supported shared libraries under linux then this problem would go away. This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Moving to rawhide since I think it is affects all versions. Of course we still need to decide if we want to fix this... I don't know why this would be occurring. Jens, any ideas? Well I think it is as I tried to explain in comment 1: ie generating the .o files which is done at install time requires a fair bit of ram I guess. Otherwise I dunno. :) We could consider other approaches though shipping the .o files would basically double the size of library packages. An alternative might be to subpackage them? Shared library support should arrive in 6.10, so I propose to do nothing about this for another few months :-) (In reply to comment #6) > Shared library support should arrive in 6.10, so I propose to do nothing about > this for another few months :-) I guess that's fine. I'd like to report an update on the situation, and to emphasize something in my earlier report. ****** The point I would like to emphasize is that building and installing from source finishes in a reasonable amount of time, but installing from rpm (yum) does not. Does that not suggest that something bizarre is happening in the rpm install that does not happen in the install from source? And since installing from source certainly generates the .o files, does that not cast some doubt on the theory that, when the rpm generates the .o files at install time, that's really the problem? I realize that 256 MB RAM seems small to you guys, but it's all I've got -- and it's adequate for most things, including building and installing gtk2hs from source, so why would it not be adequate for the rpm install? ****** Here's my update: I've moved to a faster computer, but still with 256 MB RAM. Installed Fedora 9. Tried to install ghc-gtk2hs, with the same results as I reported before. Downloaded the source tarball for gtk2hs 0.9.13 from http://haskell.org/gtk2hs/download/ # ./configure --prefix=/opt --enable-cairo --enable-svg \ --enable-opengl (Note, --enable-docs not included because that led to an installation failure -- incompatible version of haddock, I think.) # time make -- completed in 25 minutes 37 seconds real time, 12 minutes 44 seconds user time, 5 minutes 29 seconds sys time, with 2 Firefox processes running in the background (one for root and one for another user) # time make install -- completed in 41 seconds ****** Summary: 1. rpm install of gtk2hs still does not work 2. rpm generating .o files at install time does not seem to be the problem, since ... 3. ... install from source mostly* works, and does generate .o files (*except for generating documentation). 4. Since I have something that works, if you want to wait for GHC 6.10, before looking at it again, that's fine with me. By the way, thanks for moving this bug to rawhide, since (I guess) that keeps it alive after Fedora 7. (In reply to comment #6) > Shared library support should arrive in 6.10 Oh cool! Finally! ;) We will probably need to revise the Haskell packaging guidelines for that then. (In reply to comment #7) > And since installing from source certainly generates the .o files, does that > not cast some doubt on the theory that, when the rpm generates the .o files > at install time, that's really the problem? Yes, my guess could be wrong. :) > # time make install > -- completed in 41 seconds Does that install .o files too? If not, can you try say running: ghc-pkg update --auto-ghci-libs /usr/lib/ghc/6.8.2/gtk2hs/gtk.package.conf by hand? (In reply to comment #8) > (In reply to comment #6) ... > > > # time make install > > -- completed in 41 seconds > > Does that install .o files too? > ... Yes, it did: [root@squirrel gtk2hs]# pwd /opt/lib/gtk2hs [root@squirrel gtk2hs]# ls cairo.package.conf HSglade.o include libHSsourceview.a gconf.package.conf HSglib.o libHScairo.a libHSsvgcairo.a glade.package.conf HSgtkglext.o libHSgconf.a soegtk.package.conf glib.package.conf HSgtk.o libHSglade.a sourceview.package.conf gtkglext.package.conf HSsoegtk.o libHSglib.a svgcairo.package.conf gtk.package.conf HSsourceview.o libHSgtk.a HScairo.o HSsvgcairo.o libHSgtkglext.a HSgconf.o imports libHSsoegtk.a This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Okay finally tested and reproduced this: 1) I installed f10 on a 256M guest vm 2) yum install ghc-gtk2hs 3) run top For (2) package installs but the scripts take "forever" to finish: I suspect the main culprit is libHSgtk.a (20M) -> HSgtk.so. Currently it is using about 330M of swap... (3) shows ld running and using about 357M of vm... Maybe linking from source is more efficiency than relinking from .a? Perhaps you could try running the "ghc-pkg update --auto-ghci-libs" part of the install scripts (rpm -q --scripts ghc-gtk2hs) to confirm this? I guess must be the problem though. Maybe we should just include the .o files in ghc-gtk2hs like we do for other packages: these days 3MB is not considered that big... Hmm, it finished for me after within "only" 110 minutes... anyway I think I will just add the .o files to ghc-gtk2hs for now. Also the .o files are tiny I released so really there is no good reason not to ship them... Fixed now in cvs for rawhide: waiting for new haddock package to get built first so that docs can be built there too again. Should be in ghc-gtk2hs-0.9.13-6.20081108.fc11. Will leave this open until it is fixed for f10. ghc-6.10.1-7.fc10, ghc-paths-0.1.0.5-2.fc10, haddock-2.4.1-2.fc10, ghc-gtk2hs-0.9.13-8.20081108.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghc ghc-paths haddock ghc-gtk2hs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1442 Actually I forgot to remove the --auto-ghci-libs from ghc-pkg update in %post so this build will not actually fix the problem. :-( It should be fixed already in ghc-gtk2hs-0.10.0-0.1.fc11 in rawhide though. ghc-gtk2hs-0.10.0-1.fc10 |