When gimp-help is compiled with imagemagick use flag, and compilation reaches the point where the command "/usr/bin/convert -colors 128 ./dialogs/fr/dialogs-layer.png /dialogs/fr/dialogs-layer.png" is run (according to htop) the cpu/memory/swap usage reaches 100% and the system crashes. This means that without runing the X server, the user gets logged out and while running the X server and compiling from kde konsole, the taskbar along with any open window disappears and the situation gets complicated... See http://forums.gentoo.org/viewtopic.php?p=3735479#3735479 for more information. Kind regards, orange_juice
emerge --info, please.
(In reply to comment #0) > When gimp-help is compiled with imagemagick use flag, and compilation reaches > the point where the command > > "/usr/bin/convert -colors 128 ./dialogs/fr/dialogs-layer.png > /dialogs/fr/dialogs-layer.png" > > is run (according to htop) the cpu/memory/swap usage reaches 100% and the > system crashes. This means that without runing the X server, the user gets > logged out and while running the X server and compiling from kde konsole, the > taskbar along with any open window disappears and the situation gets > complicated... > > See http://forums.gentoo.org/viewtopic.php?p=3735479#3735479 for more > information. > > Kind regards, > orange_juice > (In reply to comment #0) > When gimp-help is compiled with imagemagick use flag, and compilation reaches > the point where the command > > "/usr/bin/convert -colors 128 ./dialogs/fr/dialogs-layer.png > /dialogs/fr/dialogs-layer.png" > > is run (according to htop) the cpu/memory/swap usage reaches 100% and the > system crashes. This means that without runing the X server, the user gets > logged out and while running the X server and compiling from kde konsole, the > taskbar along with any open window disappears and the situation gets > complicated... > > See http://forums.gentoo.org/viewtopic.php?p=3735479#3735479 for more > information. > > Kind regards, > orange_juice > (In reply to comment #1) > emerge --info, please. > Sorry, I forgot! emerge --info Portage 2.1.1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ Gentoo Base System version 1.12.6 Last Sync: Tue, 21 Nov 2006 23:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="ftp://files.gentoo.org http://files.gentoo.org ftp://ftp.ntua.gr/pub/linux/gentoo/ http://ftp.ntua.gr/pub/linux/gentoo/ ftp://ftp.uoi.gr/mirror/OS/gentoo/ http://ftp.uoi.gr/mirror/OS/gentoo/ http://ftp.physics.auth.gr/pub/mirrors/gentoo/ ftp://ftp.physics.auth.gr/pub/mirrors/gentoo/ " LANG="en_GB.UTF-8" LINGUAS="en en_GB el uk" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.10.20/gentoo-portage" USE="amd64 X Xaw3d a52 aac aalib accessibility acl acpi akode alsa amr aotuv arts asf asterisk audiofile avi berkdb bindist bitmap-fonts bzip2 bzlib cairo cddb cdparanoia cdr cpudetection cracklib crypt css ctype cups curl curlwrappers dbus divx djbfft dlloader dmi doc dri dts dv dvb dvd dvdr dvdread ecc effects elf elibc_glibc encode esd exif expat fam fame ffmpeg firefox flac flash fontconfig fortran fpx gd gdbm gif gimp gimpprint gmedia gphoto2 gpm graphviz gs gstreamer gtk gtk2 hal iconv ieee1394 imlib inkjar input_devices_evdev input_devices_keyboard input_devices_mouse java jbig jpeg jpeg2k kde kernel_linux lcms ldap lesstif libcaca libwww linguas_el linguas_en linguas_en_GB linguas_uk live lm_sensors logitech-mouse lua lzo mad mbrola mikmod mjpeg mmap mng modplug motif mozilla mp3 mp4 mpeg mpi musepack musicbrainz nas ncurses neXt network nls noamazon nptl nptlonly nsplugin nvidia odbc offensive ogg oggvorbis openexr opengl pam pcre pda pdf perl png povray ppds python qt3 qt4 quicktime rdesktop readline realmedia rpm rtc ruby sametime scanner sdl session slp smartcard smp smux sndfile snmp sockets speex spell ssl tcl tcltk tcpd tetex theora tidy tiff tk truetype type1-fonts udev unicode usb userland_GNU utf8 v4l v4l2 vcd vdr video_cards_fbdev video_cards_nvidia video_cards_vesa video_cards_vga vorbis wmf wmp wxwindows x264 xanim xine xml xorg xpm xscreensaver xv xvid xvmc yv12 zeroconf zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I've just spoken to the maintainer of the gimp documentation, <romanofski@gimp.org> (mail address posted with permission), about this. He said the conversion by ImageMagick was to be done for the online version of the Gimp help only, it was never meant for local installations. Therefore, the imagemagick use flag should not affect the way the docs are built; --disable-convert should always be used.
If I understood well, the imagemagick use flag should be enabled for gimp-help, only in certain and very specific situations. Otherwise, it should be disabled using the relevant entry in /etc/portage/package.use file.
Doesn't this rather sound like a different use flag should be used to determine whether to build the docs with --enable-convert? Something that reflects the purpose rather than the mechanics? Explicitly disabling the use flag for this one package feels to me like the symptom of an implementation detail an unsuspecting user doesn't know and probably shouldn't care about.
Sounds very reasonable. Actually, I did not enable the "imagemagick" useflag with the purpose to compile gimp-help. It was enabled from the compilation of another program, and the reason for leaving it in /etc/make.conf was the thought that since I use imagemagick, every program that can benefit from it, it is very welcome. However, in this situation, the activation of the useflag has an exceptional rather than beneficial character and it would be better to have a unique name that corresponds to this situation. Kind regards, orange_juice
I was seeing a segmentation violations from some of the convert processes, so increased swap to 2G (eg toolbox/tool-options-dodge.png). But watching the build, it only used a little over 600M of swap before the segmentation violation. So convert falls over before it runs out of memory. This is using imagemagick 6.3.0.5 on x86. I've now put the following line in keywords.use as the comments above suggest it is not required. app-docs/gimp-help -imagemagick Presumably the imagemagick problem is that described in http://bugs.gentoo.org/show_bug.cgi?id=151628, even though it is an older version.
I have investigated on the problem: it is related to libpng-1.2.14. The upgrade to libpng-1.2.15 resolves the issue. The next step is stabilize libpng-1.2.15 :-)
I've changed imagemagick USE flag on webinstall. Hope this makes clearer its purpose.
Thank you for report Fabio. This indeed fixes the problem. I've checked libpng versions 1.2.13 and 1.2.14 and both have this problem. CC'ed base-system: Although libpng-1.2.14 is not stable on all archs and libpng-1.2.15 is less then month in portage, may be we should shorten testing period for this bug? CC'ed graphics: I think you should be aware about this bug.
doesnt matter to me if ppl want to stabilize the newer one
imagemagick with <libpng-1.2.15 segfaults and eats a lot of RAM, during gimp-help installation. base-system have no objections in stabilizing (see comment #11). Thus: Arch teams, please, stabilize libpng-1.2.15. TIA.
ppc64 stable
on x86: media-libs/libpng-1.2.15 USE="-doc" seems to be fine for me. if there are problems, i guess i should encounter them soon as: " $ equery depends libpng | wc -l 41 "
x86 stable
sparc stable.
Stable for HPPA.
Stable on ppc by lu_zero, Thanks Luca :)
arm and s390 stable
amd64 stable
mips stable on 1.2.16.
alpha stable, sorry for the delay. Closing.
