Hi Carnë, On Mon, Sep 1, 2014 at 12:48 PM, Carnë Draug <carandr...@octave.org> wrote: > It's been almost 5 years since this bug was reported, it's a blocker > for other two bugs, it has a patch (it's a 1 line change on the > Makefile), and even the upstream maintainer has pitched in saying that > the build should be changed has proposed. > > Could the package maintainer please please please, at least comment on this? I'm the current maintainer, but I came late in the package life. Yes, changing the quantum depth is just a switch for the configure script. On the other hand, it changes at least two important aspect of the programs using graphicsmagick. The first one is the in-memory usage of graphics handling. It will double the memory needed for the unpacked (ie, don't compare it with the on-disk size of the image) pictures. Yes, newer architectures like PPC64 will have several gigabytes of RAM to handle this. But on older architectures like armel/armhf it may render the package itself and related ones to useless because of memory issues. The second one is can the dependent packages handle the changed in-memory representation of the image? Who can test those in every aspect at least on two architectures (little- and big-endian one)? Fixes may be necessary for those and if their upstream is busy with other things, the packages may be broken for a long time. I can do a limited quick test on amd64, but the Release-Team will be in position to allow this change or not.
Kind regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
