On 05/03/18 05:31, Eyal Lebedinsky wrote:
On 05/03/18 15:27, Ed Greshko wrote:
> On 03/05/18 12:23, Samuel Sieb wrote:
>> On 03/04/2018 05:55 PM, Eyal Lebedinsky wrote:
>>> While it mostly works, this specific command fails:
>>>
>>> $ dnf provides '*/Droid Sans*'
>>>
>>> This is consistent, and also happens on a second machine. Both run
>>> f27 fully updated.
>>>
>>> The following does work:
>>>
>>> $ dnf provides '*/Droid*'
>>>
>>> But this one crashes:
>>>
>>> $ dnf provides '*/x y*'
>>>
>>>
>>> I suspect a python problem. Anyone else sees these crashes?
>>
>> I've never tried a query like that before, but I do get a crash as
>> well. The stack
>> trace isn't always the same, but it's usually in a malloc call. It
>> looks like it's
>> possibly a glibc problem. But for some reason abrt isn't detecting
>> the crash which
>> makes it harder to report. I will file a bug.
>>
>
> OK, but isn't this searching for a file that has a "space" in it?
> Can't recall ever
> seeing one like that as part of the O/S.
True. I was trying to understand why mythtv-setup complains:
2018-03-05 16:28:02.602160 E MythFontProperties: Failed to load 'Droid
Sans', got 'Droid Sans [MONO]' instead
Location:
/usr/share/mythtv/themes/MythCenter-wide/base.xml @ 6
Name: 'basesmall' Type: 'fontdef'
and just copied/pasted the font name into the search.
Still, should not crash, and anyway on linux one *can* have spaces (and
other funny chars)
in file names, especially when one is asking for trouble :-(
I know this thread is about dnf, but I've seen exactly this font problem.
mythtv will be looking for /usr/share/mythtv/fonts/DroidSans-Bold.ttf
which may be a real file derived from the mythtv distro or may be a link
to the system fonts location like
/usr/share/fonts/google-droid/DroidSansMono.ttf, which on this, el7, box
is from the epel package google-droid-sans-mono-fonts
John P