Description of problem: xfs sometimes unessarily rebuilds fonts.dir only because of the presences of a newer fonts.cache-1 file, not for any actual new fonts. Version-Release number of selected component (if applicable): XFree-4.3.0-15 Patch to xfs.init to ignore the presence of fonts.cache-1 file: 34c34 < elif [ "$(find . -type f -cnewer fonts.dir 2>/dev/null)" != "" ];then --- > elif [ "$(find . -type f -not -name fonts.cache-1 -cnewer fonts.dir 2>/dev/null)" != "" ];then
Description of problem: Read into mutt a folder with messages containing a multipart/mixed{ multipart/alternative{ text/plain, text/html }, application/anything } Attempting to "view" the message structure with "v" command results SEGV in addch() call, which lengthy debugging session did show up to be slang-library function SLcurses_waddch() via couple macro redirects. This appeared after I had updated kernel, glibc, lots of other libraries, and had restarted the system. I hadn't updated either mutt, nor slang at that point. After updating both, the problem didn't disappear. Recompining the mutt with slang removed from its SPEC file, the mutt with standard ncurses (-5 ?) does work just fine. Version-Release number of selected component (if applicable): slang-1.4.5-17 How reproducible: Always Steps to Reproduce: 1. have suitably complex structured message in a test folder (e.g. text+html type accompanying letter + any attachment) 2. current rawhide system 3. mutt -f test.msg 4. try to view ("v") message's structure Actual Results: SEGV Expected Results: view of the message structure.. Additional info: Is this related somehow to glibc locale handling ? (maybe) Or to slang-library bitrot ? (hardly) Or to a new 2.4.20-20.1.2007.nptl kernel ? (hardly) Ah, indeed.. LC_CTYPE=C -> no problem LC_CTYPE=fi_FI -> SEGV Anyway, slang-source version is a bit oldish, and could be updated. This is POSSIBLY glibc locale screwup, but decoding that has proven to be next to impossible.
BUGZILLA bugged, and mixed two separate bug entries together!
Apparently worse than that, bugzilla overwrote original bug report with mine, which was supposed to go to bug# 97213 ... Separate bug 97222 already entered for that.
dkl?
I could just close this resport, and we could all just submit the munged items... (?)
Yes, to avoid confusion, if you could both please submit new bug reports, that would be best.
report closed in deference to bug #97240.