Bug 250767 - ghc-gtk2hs won't install with only 256MB RAM
ghc-gtk2hs won't install with only 256MB RAM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ghc-gtk2hs (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-03 10:51 EDT by Gregory D. Weber
Modified: 2009-03-04 20:12 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-04 20:12:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gregory D. Weber 2007-08-03 10:51:39 EDT
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.
Comment 1 Jens Petersen 2007-08-05 20:31:22 EDT
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.
Comment 2 Bug Zapper 2008-05-14 09:51:22 EDT
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
Comment 3 Jens Petersen 2008-05-14 20:55:31 EDT
Moving to rawhide since I think it is affects all versions.

Of course we still need to decide if we want to fix this...
Comment 4 Bryan O'Sullivan 2008-07-14 10:51:02 EDT
I don't know why this would be occurring. Jens, any ideas?
Comment 5 Jens Petersen 2008-07-14 21:29:27 EDT
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?
Comment 6 Bryan O'Sullivan 2008-07-15 08:47:16 EDT
Shared library support should arrive in 6.10, so I propose to do nothing about
this for another few months :-)
Comment 7 Gregory D. Weber 2008-07-15 12:25:56 EDT
(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.
Comment 8 Jens Petersen 2008-07-16 02:55:02 EDT
(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?
Comment 9 Gregory D. Weber 2008-08-08 13:51:43 EDT
(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
Comment 10 Bug Zapper 2008-11-25 20:58:11 EST
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
Comment 11 Jens Petersen 2008-12-04 04:23:18 EST
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...
Comment 12 Jens Petersen 2008-12-05 04:52:26 EST
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.
Comment 13 Jens Petersen 2008-12-06 06:23:34 EST
Should be in ghc-gtk2hs-0.9.13-6.20081108.fc11.
Comment 14 Jens Petersen 2008-12-22 02:16:50 EST
Will leave this open until it is fixed for f10.
Comment 15 Fedora Update System 2009-02-07 17:18:58 EST
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
Comment 16 Jens Petersen 2009-02-07 19:32:31 EST
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.
Comment 17 Jens Petersen 2009-02-16 23:51:01 EST
ghc-gtk2hs-0.10.0-1.fc10

Note You need to log in before you can comment on or make changes to this bug.