Re: libcupsfilters: mupdf not "Required"

Am 09.12.25 um 21:46 schrieb "Douglas R. Reno"
([email protected] via blfs-dev Mailing List):
> On 12/9/25 8:25 AM, Rainer Fiebig ([email protected] via blfs-dev Mailing
> List) wrote:
>> Am 06.12.25 um 22:30 schrieb Rainer Fiebig ([email protected] via blfs-dev
>> Mailing List):
>>> Am 06.12.25 um 21:40 schrieb Bruce Dubbs ([email protected] via
>>> blfs-dev Mailing List):
>>>> On 12/6/25 10:31 AM, Rainer Fiebig ([email protected] via blfs-dev
>>>> Mailing
>>>> List) wrote:
>>>>> Am 06.12.25 um 17:09 schrieb Rainer Fiebig ([email protected] via
>>>>> blfs-dev
>>>>> Mailing List):
>>>>>> Mupdf is labeled as "Required" for libcupsfilters.  However,
>>>>>> libcupsfilters-2.1.1 can be built without mupdf, using the
>>>>>> config-option
>>>>>>
>>>>>>      --disable-mutool
>>>>>>
>>>>>> I just did so and the build was fine, including the tests.
>>>>>>
>>>>>> So I suggest do downgrade mupdf to "Recommended" or perhaps even
>>>>>> "Optional" for libcupsfilters.
>>>>> This seems to go even further as there is also
>>>>>
>>>>>      --disable-ghostscript
>>>>>
>>>>> as a config-option.  So it seems to me that ghostscript can/should
>>>>> also
>>>>> be downgraded, like mupdf.
>>>>>
>>>>> Here's part of the build-log, building without both, ghostscript and
>>>>> mupdf:
>>>>> [...]
>>>>> Build configuration:
>>>>>           libcups:         2.4.15
>>>>>           cups-config:     system
>>>>>           poppler:         yes
>>>>>           ghostscript:     no
>>>>>           gs-path:
>>>>>           mutool:          no
>>>>>           mutool-path:
>>>>>           ippfind-path:    system
>>>>>           imagefilters:    yes
>>>>>           jpeg:            yes
>>>>>           exif:            yes
>>>>>           png:             yes
>>>>>           tiff:            yes
>>>>>           dbus:            yes
>>>>>           werror:          no
>>>>>           test-font:       /usr/share/fonts/dejavu/DejaVuSans.ttf
>>>> I like that, but to decide whether to make them recommended or
>>>> optional,
>>>> I'm wondering what they do for libcupsfilters.
>>> Or for cups-filters which also has those two config-options.
>>>
>>>> We do say ghostscript OR mupdf.  I'm guessing they convert to a pdf
>>>> instead of the default ps format.
>>>>
>>>> Perhaps one of them is needed to just output to a pdf file.
>>> Or perhaps even both.  I had removed mupdf from the system and had
>>> rebuilt libcupsfilters _and_ cups-filters with ghostscript but without
>>> mupdf.  I just discovered that now Firefox and Thunderbird hang and have
>>> to be killed when trying to print a page or email via the system
>>> print-dialogue.  Printing a pdf from LO-Writer or Kate still works.
>> Man - this problem caused me serious pain and practically ruined my
>> weekend (and more)!
>>
>> Only a few minutes ago and by pure chance, I discovered (by parsing the
>> latest BLFS-cups-instructions _again_ for a mistake I might have made)
>> that there is a new version for cups (-2.4.16).  Installing that version
>> finally! solved the problem.  I was really at my wits end with this.
>>
>> I'm wondering why there have not been complaints regarding cups-2.4.15
>> on blfs-support.  Maybe I'm the only one who follows and heeds the
>> security advisories.
>>
>> Whatever - from this experience with cups-2.4.15, I suggest that
>> security advisory
>>
>> 12.4 042 CUPS Date: 2025-12-02 Severity: Medium
>>
>> be amended for cups-2.4.16 or that a new SA be issued.  Perhaps users
>> should even be warned against using cups-2.4.15 on blfs-support.
>>
>>
>> Rainer
> 
> Hi Rainer,
> 
> Thank you so much for letting us know! I will make sure that gets in
> when I have a chance tomorrow :)
> 
> I will also make sure to write a mail to blfs-support about it as well
> given that it's a regression from a security update!

The unfortunate coincidence of my (harmless) changes to the build-config
of libcupsfilters/cups-filters and the real reason for the
printing-problem that then surfaced (the bug in cups-2.4.15) was
maximally misleading.  In hindsight, a backtrace I took of Seamonkey
actually pointed somehow in the right direction (gtk) but at the time
rather added to my confusion, as I definitely hadn't made any changes in
that area. [1]

Alright - all's well that ends well. ;)

Rainer


[1]

[...]
#53 0x00007f197fce1b0f in ??? () at
/opt/seamonkey-2.53.22/lib/seamonkey/libxul.so
#59 0x00007f198487d99f in Python Exception <class 'gdb.error'>: Cannot
look up value of a typedef `node'.
#60 0x00007f1984378b34 in gtk_widget_event_internal.part () at
/usr/lib/libgtk-3.so.0
#61 0x00007f1984211ee0 in propagate_event () at /usr/lib/libgtk-3.so.0
#62 0x00007f1984213cc5 in gtk_main_do_event () at /usr/lib/libgtk-3.so.0
#63 0x00007f1983f31225 in _gdk_event_emit () at /usr/lib/libgdk-3.so.0
#64 0x00007f1983f8edb2 in gdk_event_source_dispatch () at
/usr/lib/libgdk-3.so.0
#65 0x00007f1983decd52 in g_main_dispatch () at /usr/lib/libglib-2.0.so.0
#66 0x00007f1983df0550 in g_main_context_iterate_unlocked.constprop ()
at /usr/lib/libglib-2.0.so.0
#67 0x00007f1983df0eaf in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#68 0x00007f197fcf7c58 in ??? () at
/opt/seamonkey-2.53.22/lib/seamonkey/libxul.so
[...]

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page