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):
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
--> 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
Package Arch Version Repository Size
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
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
(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
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
4. rpm now says the package is installed:
[root@moose log]# rpm -q ghc-gtk2hs
[root@moose log]# rpm -q ghc661-gtk2hs
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
main :: IO ()
main = do
window <- windowNew
button <- buttonNew
set window [containerBorderWidth := 10,
containerChild := button]
set button [buttonLabel := "Hello World"]
onClicked button (putStrLn "Hello World")
onDestroy window mainQuit
[root@moose haskell_tutorial]# ghc --make gtk_hello.hs -o gtkhello
Could not find module `Graphics.UI.Gtk':
Use -v to see a list of the files searched for.
1. yum could not install the package
2. rpm said the package was installed
3. could not compile a simple GTk demo
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
1. Although this page
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:
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
Downloaded the source tarball for gtk2hs 0.9.13 from
# ./configure --prefix=/opt --enable-cairo --enable-svg \
(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
1. rpm install of gtk2hs still does not work
2. rpm generating .o files at install time does not seem to be the problem,
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
(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
[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:
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.