Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.