Hide Forgot
Description of problem: When I try to install the packages ghc-gtk2hs, on a machine with 256 MB RAM, "yum install ghc-gtk2hs" spawns an ld process which page thrashes for hours. In effect, the package cannot be installed. After killing the ld process, yum terminates with an error message. rpm then says the package is installed, but compiling a simple demo program fails. This seems to be a packaging problem rather than a problem with the program which is packaged. Version-Release number of selected component (if applicable): ghc-6.6.1-3.fc7 ghc-gtk2hs-0.9.11-4.fc7 ghc661-gtk2hs-0.9.11-4.fc7 yum-3.2.1-1.fc7 rpm-4.4.2-46.fc7 How reproducible: Steps to Reproduce: 1. yum install ghc-gtk2hs [root@moose log]# yum install ghc-gtk2hs Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments planetccrma 100% |=========================| 951 B 00:00 adobe-linux-i386 100% |=========================| 951 B 00:00 planetcore 100% |=========================| 951 B 00:00 updates 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 1.1 MB 00:08 freshrpms 100% |=========================| 2.1 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package ghc-gtk2hs.i386 0:0.9.11-4.fc7 set to be updated --> Processing Dependency: ghc661-gtk2hs = 0.9.11-4.fc7 for package: ghc-gtk2hs --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package ghc661-gtk2hs.i386 0:0.9.11-4.fc7 set to be updated ---> Package ghc-gtk2hs.i386 0:0.9.11-4.fc7 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: ghc-gtk2hs i386 0.9.11-4.fc7 fedora 6.8 k Installing for dependencies: ghc661-gtk2hs i386 0.9.11-4.fc7 fedora 3.3 M Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 3.3 M Is this ok [y/N]: y Is this ok [y/N]: y Downloading Packages: (1/2): ghc-gtk2hs-0.9.11- 100% |=========================| 6.8 kB 00:00 (2/2): ghc661-gtk2hs-0.9. 100% |=========================| 3.3 MB 00:10 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: ghc661-gtk2hs ######################### [1/2] At this point, yum shows no more signs of progressing. 2. In another window, run the 'top' command. Type M to order by memory usage, f to select displayed fields, u and v to show page faults and dirty pages, then ENTER to go back to the display. top - 09:52:21 up 15 min, 2 users, load average: 2.76, 1.56, 0.75 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie Cpu(s): 8.6%us, 4.3%sy, 0.0%ni, 0.0%id, 86.1%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 255276k total, 252172k used, 3104k free, 156k buffers Swap: 979948k total, 481152k used, 498796k free, 9908k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT nDRT COMMAND 3156 root 20 0 313m 178m 264 D 2.3 71.8 0:20.39 44k 0 ld 3142 root 20 0 40876 5532 3116 S 1.0 2.2 0:02.58 749 0 emacs 2862 root 20 0 70352 3928 2276 S 5.6 1.5 0:14.24 278 0 Xorg 3023 root 20 0 80292 3516 2272 S 0.7 1.4 0:03.47 266 0 gnome-ter 3006 root 20 0 17016 3424 2752 S 1.7 1.3 0:01.75 223 0 metacity 3049 root 20 0 36024 3168 2380 S 1.0 1.2 0:00.89 115 0 wnck-appl 3008 root 20 0 38216 2928 2076 S 0.0 1.1 0:01.64 145 0 gnome-pan 3102 root 20 0 28680 2672 2120 S 0.0 1.0 0:00.23 156 0 clock-app 3010 root 20 0 81096 2296 1700 S 0.0 0.9 0:01.83 198 0 nautilus 3030 root 20 0 45364 2284 1668 S 0.3 0.9 0:00.84 39 0 nm-applet 3085 root 20 0 42092 1932 1712 S 0.0 0.8 0:02.37 38 0 /usr/bin/ 3105 root 20 0 37372 1816 1604 S 0.3 0.7 0:00.97 10 0 mixer_app 3002 root 20 0 40064 1800 1492 S 0.3 0.7 0:01.18 34 0 gnome-set 3040 root 20 0 27620 1620 1364 S 0.0 0.6 0:00.17 54 0 gnome-pow 3037 root 20 0 10804 1608 1120 S 0.0 0.6 0:00.29 81 0 python 3051 root 20 0 44328 1540 1540 S 0.0 0.6 0:00.19 2 0 trashappl 3099 root 20 0 35852 1516 1516 S 0.0 0.6 0:00.23 7 0 fast-user Viewed 5 minutes later, the ld process has progressed by 5 CPU seconds and page faulted 140,000 times: VIRT RES Time+ nflt ---- --- ----- ---- 313m 180m 0:29.93 140k (Some days, I have let this process run for hours, and observed page fault counts over 500,000.) 3. In top, press k and kill the bloodsucking ld process. yum now comes back to life and says: error: %post(ghc661-gtk2hs-0.9.11-4.fc7.i386) scriptlet failed, exit status 1 Installing: ghc-gtk2hs ######################### [2/2] Installed: ghc-gtk2hs.i386 0:0.9.11-4.fc7 Dependency Installed: ghc661-gtk2hs.i386 0:0.9.11-4.fc7 Complete! 4. rpm now says the package is installed: [root@moose log]# rpm -q ghc-gtk2hs ghc-gtk2hs-0.9.11-4.fc7 [root@moose log]# rpm -q ghc661-gtk2hs ghc661-gtk2hs-0.9.11-4.fc7 [root@moose log]# 5. Compiling a simple GTk hello program fails: [root@moose haskell_tutorial]# cat gtk_hello.hs -- A GTk window, very simple -- Source: http://haskell.org/gtk2hs/documentation/#tutorials import Graphics.UI.Gtk main :: IO () main = do initGUI window <- windowNew button <- buttonNew set window [containerBorderWidth := 10, containerChild := button] set button [buttonLabel := "Hello World"] onClicked button (putStrLn "Hello World") onDestroy window mainQuit widgetShowAll window mainGUI [root@moose haskell_tutorial]# [root@moose haskell_tutorial]# ghc --make gtk_hello.hs -o gtkhello gtk_hello.hs:4:7: Could not find module `Graphics.UI.Gtk': Use -v to see a list of the files searched for. [root@moose haskell_tutorial]# Actual results: 1. yum could not install the package 2. rpm said the package was installed 3. could not compile a simple GTk demo Expected results: 1. yum would install the package 2. if yum did not succeed, then rpm would say the package is not installed 3. if rpm says the package is installed, then the demo would compile and run Additional info: 1. Although this page http://koji.fedoraproject.org/koji/packageinfo?packageID=1995 seems to be saying that a package for version 0.9.12-1 has been available since July 27, and today is August 3, yum can only find packages for version 0.9.11-4. I've tried a few times during the last several days, so I doubt it's just a single repo that is lagging behind. 2. Downloading the source tarball (now version 0.9.12) from haskell.org, I could compile and install gtk2hs, and then compile and run programs. No problems whatsoever. Compiling gtk2hs was a fairly long process, but installing was zippy enough.
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