Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
On Fri, Apr 05, 2024 at 05:04:37AM +, Thorsten Glaser wrote: > Markus Wichmann dixit: > > >can check with readelf -r what the relocation types are. If they are not > >relative, they will not be processed. > > Gotcha! They are all R_390_RELATIVE except for: > > 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 > 00045ff8 00110016 R_390_64 00042c58 u_ops + 0 > 00047020 00110016 R_390_64 00042c58 u_ops + 80 > 00047088 00110016 R_390_64 00042c58 u_ops + 80 > 000470a8 00110016 R_390_64 00042c58 u_ops + b8 > 00047220 00110016 R_390_64 00042c58 u_ops + 80 > 00046900 00260016 R_390_64 00015af8 c_command + 0 > 00046940 00070016 R_390_64 00017238 c_exec + 0 > 00046ab0 00200016 R_390_64 00016a80 c_trap + 0 > 00047090 00250016 R_390_64 000430ac initvsn + 0 > 00047278 00550016 R_390_64 00047438 null_string + 2 > > That’s our missing strings. Is there anything weird about how these objects were declared that might have caused ld not to resolve them statically like it should? It seems odd that these data symbols, but not any other ones, would be left as symbolic relocations. Rich
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
On Thu, Apr 04, 2024 at 07:50:40PM +, Thorsten Glaser wrote: > Szabolcs Nagy dixit: > > >the next culprit is gcc (each target can have their own > > gcc-13_13.2.0-23 > > >static pie specs) or the way you invoked gcc (not visible > > As I wrote earlier, though with more flags. Dropping all the -D… > and -W… and -I… and other irrelevant ones: > > musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables > -fno-strict-aliasing -fstack-protector-strong -fwrapv -c … > musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables > -fno-strict-aliasing -fstack-protector-strong -fwrapv > -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie > -fno-lto -o mksh *.o > > Same for both. You can see the full log by activating the > [64]Installed and [71]Installed links respectively on > https://buildd.debian.org/status/package.php?p=mksh and > skipping to 'compilation of mksh in static-musl' to get to > the beginning of the configure phase for that. > > >are you sure static pie works on these targets? > > No ;-) That’s why I reported this issue. I had just > enabled it for the musl builds, as the security people > like that more than normal static. I seem to recall the musl-gcc wrapper does not handle static-pie right. A real cross toolchain should. If there's an easy fix for the wrapper I'd be happy to merge it. Rich
Bug#1050429: [musl] musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
On Sat, Feb 03, 2024 at 08:20:28AM +, Thorsten Glaser wrote: > Hi musl maintainers, > > waldi indeed provided a fix for this bug forgot to Cc me, so I missed > it until now. I tested this: > > > > (sid_mips64el-dchroot)tg@eberlin:~$ sh -x $(which musl-gcc) hello.c > + exec mips64el-linux-gnuabi64-gcc hello.c -specs > /usr/lib/mips64el-linux-musl/musl-gcc.specs > mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL' > (sid_mips64el-dchroot)tg@eberlin:~$ mips64el-linux-gnuabi64-gcc hello.c > -specs ~/musl-gcc.specs > (sid_mips64el-dchroot)tg@eberlin:~$ ./a.out > hi > (sid_mips64el-dchroot)tg@eberlin:~$ diff -u > /usr/lib/mips64el-linux-musl/musl-gcc.specs musl-gcc.specs > --- /usr/lib/mips64el-linux-musl/musl-gcc.specs 2023-11-10 19:30:40.0 > + > +++ musl-gcc.specs 2024-02-03 08:07:01.309465472 + > @@ -1,10 +1,11 @@ > %rename cpp_options old_cpp_options > +%rename cc1 old_cc1 > > *cpp_options: > -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s > %(old_cpp_options) > > *cc1: > -%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem > include%s > +%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem > include%s %(old_cc1) > > *link_libgcc: > -L/usr/lib/mips64el-linux-musl -L .%s > > > > This change (to tools/musl-gcc.specs.sh in the source tree) probably > makes sense on all architectures, so perhaps do that even. Upstream > should also consider including this and check which of the original > specs need not be removed and can be kept like this. > > bye, > //mirabilos OK, it's not musl that's unusable, but the gcc wrapper. This is not the recommended way to use musl except as minimal evaluation setup or for compiling very simple programs, and as you've found, it seems it's almost entirely untested except on a couple mainstream archs. This is something we should fix, but there are two issues: 1. On some archs, which I think includes mips, it can work in principle, but has gratuitous bugs keeping it from working. These should be easy to fix. 2. On some archs such as powerpc, the ABI is almost surely mismatched with the existing toolchain on a non-musl system. This should be caught at configure time, since the existing gcc is not able to build musl anyway, but it's possible that with sufficient additions to CFLAGS/CC, it might be possible to get musl to build, but then have a broken wrapper still (or to compile, but fail at link time or produce a broken libc.so due to mismatched libgcc.a). This probably needs attention too. I'll try to take a look at this soon and see if the proposed wrapper fix seems right for the mips situation, but the wrapper is generally low-priority, and there's other stuff I'm trying to get to/finish first. Rich
Bug#989746: [musl] What is the status of musl and fts.h?
On Fri, Jun 11, 2021 at 08:35:08PM +0200, Helmut Grohne wrote: > Dear musl developers, > > As I proceeded to building libselinux, I ran into the well-known issue > that musl does not include a fts.h header. This is documented in the > musl faq at: > https://wiki.musl-libc.org/faq.html#Q:-Why-is-%3Ccode%3Efts.h%3C/code%3E-not-included? > > Unfortunately, the answer seems slightly out of date. For one thing, > glibc does include a fts64 variant these days. For another, most > embedded distributions that do use musl seem to have set on an extra > implementation: > https://github.com/void-linux/musl-fts > > So it seems like everyone has agreed that there should be a fts > implementation and that it can be bolted onto musl. That gives rise to > the obvious question: Can musl-fts be merged into musl? > > Please Cc me in replies as I am not subscribed. Also please update the > FAQ entry. I haven't really looked at it since, so I don't have any immediate opinion. I think it's something we could revisit for evaluation. Rich
Bug#451886: not a bug; in support of wontfix status
In support of this not being a bug, I have code which uses the correct, standards-compliant behavior of fgets. Contrary to Andrew's report, it's very easy to know how much is read by fgets and use it with data containing '\0'. Simply ensure the buffer does not contain any occurrances of '\n' (for instance memset to all '\0') before reading, then use memchr to search for '\n' in the results. If you find '\n', its position tells how many bytes were read. If not, the entire buffer was filled without reaching a newline. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#440980: iceweasel seriously misrenders tibetan text with tibetan machine uni font
On Sun, Oct 26, 2008 at 05:22:57PM -0400, Eric Dorland wrote: * Rich Felker ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 2.0.0.6-1 Severity: normal Tags: l10n *** Please type your report below this line *** When using the Tibetan Machine Uni font (which is packaged with Debian and intended as the default font for Tibetan script), Iceweasel is displaying every combining character separately as a dotted circle with the combining character attached to it, rather than correctly attached to the previous character. See screenshot: http://www.aerifal.cx/~dalias/images/iceweasel_tmuni_bug.png And what it should look like (using a different font): http://www.aerifal.cx/~dalias/images/iceweasel_jomo_ok.png Pango is enabled; it is required for display of Tibetan text. This does not seem to be a bug in Pango, however, since both GTK widgets and GIMP successfully render Tibetan text using Pango. On the other hand, it very likely could be a misuse of Pango, since Abiword exhibits incorrect display (albeit different from the Iceweasel issue; Abiword seems to ignore the OpenType tables completely) with this font as well, while working fine with other fonts. As a workaround, users can remove the ttf-tmuni package and install the ttf-dzongkha package instead, which provides a different font for Tibetan script. However, users of these languages will often want to have all Tibetan fonts installed for word processing use, etc., which will cause any website explicitly requesting the Tibetan Machine Uni font to become completely illegible. Did Iceweasel 3.0 fix the problem? Yes; I simply had not noticed since I had upgraded to a newer version of the Tibetan Machine Unicode font which avoids the problem. (The newer version is designed to support Windows 2k/XP machines without up-to-date Uniscribe by using simpler OpenType features. ttf-tmuni package should be updated to use this newer version too, but that's a separate issue report I suppose..) Thanks for checking back in. You can close this bug. Rich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493799: tmuni recommends should be suggests
Package: ttf-tmuni Version: 0.0.20040806-1 Severity: normal tmuni 'recommends' mknfonts.tool rather than merely suggesting it, which causes unnecessary software only of interest to font hackers to be installed in the default configuration. This is almost surely not the intended behavior. Please replace the 'recommends' with a 'suggests' or remove it entirely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493800: autofs should only suggest nfs-common, not recommend it
Package: autofs Version: 4.1.4+debian-2.1 Severity: normal These days autofs is at least as useful, if not moreso, for managing removable media than for nfs, which has become something of a niche application. Installing autofs should not cause nfs stuff to be installed, since anyone needing nfs will already know quite well that they need it and will have already installed the necessary packages anyway. Please remove nfs-common from the 'recommends' for autofs and possibly add it to 'suggests' instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#179286: please justify wontfix
If this bug is going to be marked wontfix, I think a justification is in order. Enabling eightBitInput (which Henning has correctly noted is a misnomer) by default clashes with non-7bit characters, making it unreasonable for any application using a terminal to attempt to treat octets with the 8th bit set as meta keys. Not only does the default value of this setting cause problems for users who need non-7bit characters; a multitude of applications (most notably IRC clients but also others) fail to interpret bit 8 as meta, causing an endless stream of new user hassles and support questions. These applications are behaving correctly in supporting an internationalized/multilingual environment; fixing them to accept bit 8 as meta would be a major step backwards. Another related bug is the default setting of utf8Title to false, which causes xterm to disregard the locale's text encoding and treat window title strings arbitrarily as Latin-1. Like eightBitInput, this resource is also misnamed. It should be named Leave my title string alone! as the man page explains that setting it to true merely causes xterm to skip the munging. With UTF-8 as the default text encoding starting with Etch, xterm's active hostility towards non-ASCII-only locales really needs to be treated as the bug it is, and fixed. I would prefer to see it fixed upstream as well, but at the very least Debian should fix it, by adding the following the the app-defaults file: XTerm*eightBitInput: false XTerm*utf8Title: true The man page should also be patched accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386275: potentially unpopular ideas
I RTFS'd mg a while back looking to add UTF-8 support, and the biggest problem for bloating and complexity seemed to be the layer that manages the screen contents for refresh optimization. Basic UTF-8 support would require enlarging it quite a bit, and full support (including nonspacing marks) would require a system where the lines stored in this buffer could grow unboundedly large. Thus, the potentially unpopular fix I'd propose for consideration is to rip out the whole refresh-optimizing layer and move screen updates to be called directly from the code that modifies the buffer contents, as the modifications take place. This would eliminate a whole layer of bloat in terms of performance, memory usage, and code size, after which adding UTF-8 support would still be a net win. Seeing as this sort of curses-style refresh optimization was one of the original technologies emacs pioneered, some folks might be sad to see it go, but I suspect killing it is the right choice for a _light_ emacs anyway. Without the need for display management structures getting in the way, UTF-8 support (or preferably multibyte character support based on whatever the configured locale uses) should not be too difficult. It's just a matter of updating the editing functions to treat whole UTF-8 sequences as a unit for deletion, etc., and of making sure the new display code handles them and correctly computes column widths. BTW: Trent's recommendations of other Emacsen are somewhat inaccurate. XEmacs will silently and severely corrupt UTF-8 text containing any characters not present in the old mule charsets when loading and resaving a file, even if no changes are made. GNU Emacs 22 is somewhat usable but still has column width issues for CJK-wide and nonspacing characters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445097: bitmap program disappeared?!
Package: xbase-clients Version: 1:7.3+2 Severity: normal The program 'bitmap' from the standard X clients seems to have disappeared with the split of the xbase-clients package. As far I can can tell it is gone, not moved to another package. I use this program frequently and consider its disappearance a major regression; please include it in one of the split packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445097: bitmap program disappeared?!
On Wed, Oct 03, 2007 at 11:50:53AM +0300, Timo Aaltonen wrote: Yes, I did the original split, but didn't think that anyone actually used bitmap :) (it isn't included in Fedora, for instance) Anyway, it will be added to x11-apps. Thanks! For what it's worth, this program, simple as it is, is extremely useful for bitmap-font work and similar tasks. It's light and has a simple interface and lets you work on a highly-zoomed bitmap while previewing the actual size at the same time. Glad to see yet another way Debian will be superior to Fedora. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437007: against aliasing ms fonts
I’m against making default aliases for these fonts, for two reasons: 1. The proposed fonts to replace the MS fonts are not clones of the MS fonts. They do not look similar and do not have similar metrics. Aliases should be used only as a means of providing actual font clones or generic names, not for pretending that a font is present when it’s really unavailable and substituting a very-different font in the same style. 2. While some websites have ugly fallbacks, like the bug report mentions, other sites use the CSS font selection system correctly. Creating an alias for Arial prevents the browser from gracefully falling back to another font that the page designer intended and forces the browser to use a font that was not intended. Point #1 could be fixed by aliasing Arial to FreeSans (a near-perfect Helvetica clone, which Arial also is), Times New Roman to FreeSerif (Times clone), etc. However, this escalates the problem of point #2, since there are websites that do things like: font-family: Arial, Bitstream Vera Sans, Sans-serif; And Linux users would probably much appreciate getting the fallback to Bitstream Vera Sans here, since it actually has hinting (unlike FreeSans). Unless someone else sees a way around the above problems, I’m (as a Debian user, no one special) against aliasing the MS font names. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444811: fontconfig should not use URW postscript fonts by default
Package: fontconfig-config Version: 2.4.2-1.2 Severity: normal The URW Nimbus fonts, in their original Postscript form, have major kerning issues which cause many letters to run together when hinting is enabled. I’m uncertain whether this is a bug in the fonts themselves or a problem in FreeType’s Type1 renderer that applies to all Type1 fonts, but it causes severe ugliness and difficulty of reading when browsing websites that use these fonts. The problem is greatly escalated by the fact that fontconfig-config aliases the standard names Helvetica, Times, and Courier to these fonts, but I have also seen misguided sites directly requesting Nimbus Sans L by name. My understanding is that the FreeSans, FreeSerif, and FreeMono fonts are direct copies of the URW Nimbus fonts, converted to TrueType and then enhanced with much greater Unicode coverage and minor bugfixes. In this light, I believe: 1. (Hopefully uncontroversial) The aliases for Helvetica, Times, and Courier should use the Free* fonts and prefer them over the original URW fonts. 2. (Probably controversial; needs discussion) The default configuration for fontconfig should blacklist the URW Nimbus fonts and alias their names to the Free* family of fonts. If the Free* family really is a superset of the URW Nimbus fonts without the kerning bugs, then it does not make sense to use the old buggy versions of these fonts just because an application, document, or website was written with the old buggy fonts in mind. Alternatively, since the bug seems to be related to hinting, it may be reasonable to force autohint for these fonts rather than totally blacklisting them. The autohinter seems to fix the problem. Getting rid of the URW Nimbus fonts would go a long way towards improving the font quality issue as perceived by new users. I remember installing Debian on a computer for my mother about 4 or 5 years ago and having her comment right away that the fonts were ugly and illegible, and it was exactly this problem with the URW fonts that she was talking about. Now that I’m a Debian user again and finally spent the time to track this issue down I hope something can be done about it. If images depicting the problem are needed I can prepare them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443848: XKB grp_led broken in latest packages
Package: xorg Version: 1:7.3+2 Severity: normal Since upgrading to the latest xorg package, the keyboard led indicators showing the XKB group toggle no longer work on my system. I have grp_led:caps in my configuration but the caps lock light remains unlit, while the group toggle key itself works. Simple test to reproduce this: setxkmap us,el -options grp:caps_toggle,grp_led:caps Then pressing capslock should switch to Greek keyboard, and the capslock led should light to indicate Greek layout when it is enabled. If packagers have trouble reproducing the bug I'll investigate further. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442202: [Pkg-fonts-devel] Bug#442202: inconsistent hinting in fi, fl, ffi, ffl ligatures
On Fri, Sep 14, 2007 at 10:58:32AM +0200, Eugeniy Meshcheryakov wrote: 13 вересня 2007 о 23:37 -0400 Rich Felker написав(-ла): While other Latin glyphs are equipped with proper hinting in the DejaVu family of fonts, the ligatures for fi, fl, ffi, and ffl are very poorly hinted (perhaps auto-generated hints?). Those glyphs have instructions in sans, but some of them do not have instructions in Serif. Indeed, I meant to say Serif in my original email. This causes the auto-ligated letters to become blurry or extra-weighted in the middle of crisp, well-hinted text, as if these letters are being hilighted with a different style. Do you see this with Sans too? Nope, I just checked and Sans looks fine. In most programs only the ffl looks extremely bad. However ffi and the rest look bad in Iceweasel as well. (This is separate from the Iceweasel bug with justified text and ligatures.) I am unsure why the badness varies between programs. I'd like to see screenshot for ffi. Attached. Rich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442202: inconsistent hinting in fi, fl, ffi, ffl ligatures
Package: ttf-dejavu Version: 2.19-1 Severity: normal While other Latin glyphs are equipped with proper hinting in the DejaVu family of fonts, the ligatures for fi, fl, ffi, and ffl are very poorly hinted (perhaps auto-generated hints?). This causes the auto-ligated letters to become blurry or extra-weighted in the middle of crisp, well-hinted text, as if these letters are being hilighted with a different style. In most programs only the ffl looks extremely bad. However ffi and the rest look bad in Iceweasel as well. (This is separate from the Iceweasel bug with justified text and ligatures.) I am unsure why the badness varies between programs. Please either fix the hinting to be consistent with the rest of the font or disable the ligatures until they can be fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395487: same problem
I just experienced the same problem and was about to report a bug for it, but it seems I wasn't the first. The issue is that fontconfig has standard aliases sans, serif, and monospace which applications should use to get the user's preferred font in each of these 3 families. A good fontconfig setup will have a series of fallbacks for each of these 3 aliases containing appropriate fonts for all scripts and languages, so it is highly advised to use them to ensure support for non-Latin scripts. Moreover, various websites use these font names as the final fallback in their CSS. The ttf-georgewilliams package installs a font named Monospace, and this conflicts with the fontconfig alias. Fontconfig aliases are only used when an actual font by that name does not exist. Aside from the 3 standard aliases, the purpose of these aliases is to allow users to configure fallbacks for specific font names in case that font isn't installed (very useful workaround for documents that ask for proprietary fonts), so I suppose it was considered preferable to always use the real font if it exists. But in the case of Monospace, this is not the real font but a very very ugly and incomplete font that happens to be in the monospace style. Please rename this font or simply remove it. I don't think anyone would miss it... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441901: TAMu fonts use wrong encoding
Package: ttf-tamil-fonts Version: 1:0.5.0 Severity: normal The TAMu family of fonts in the ttf-tamil-fonts package simply contain Tamil glyphs placed over top of Latin codepoints. This constitutes incorrect encoding. If fonts like this are needed by users of the language, perhaps for reading non-Unicode websites, could the legacy fonts be moved to a separate package, perhaps ttf-tamil-legacyfonts or similar? This would help users with lots of multilingual Unicode fonts installed avoid having their font-selectors cluttered with lots of unusable fonts, whose names are often shown using the font itself, producing pure nonsense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441903: [HaN-mfs] font uses wrong encoding
Package: ttf-alee Version: 11.4 Severity: normal The [HaN-mfs] font in the ttf-alee package simply contain Hangul glyphs placed over top of Latin codepoints. This constitutes incorrect encoding. If there is a real need for this font by users, could it be moved to a separate package such as ttf-alee-legacyencoding or similar so that users can avoid cluttering their font selectors with incorrectly encoded fonts? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362569: workaround
Waiting for upstream to take their merry time to release 3.0 hardly seems like a good way to deal with the problem to me. If fixing it independently is too much work, how about just disabling justified text completely when using Pango? I find it slows down the browser to an almost unusable crawl in most cases anyway. If you don't want to do this unconditionally, how about a MOZ_DISABLE_JUSTIFY environment variable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441319: font name strings for ani and mukti narrow are bogus (double-encoded utf-8?)
Package: ttf-bengali-fonts Version: 1:0.5.0 Severity: normal running fc-list shows: Ani,অনি Dvf:style=Regular Mukti Narrow,মà§U+0081কà§U+008Dতি:style=Regular Mukti Narrow,মুক্তি পাতনা,Mukti Narrow Bold:style=Regular,Bold [The U+ escaping was done by less; these are control characters and I could not directly paste them to email.] The name for Mukti Narrow Bold here is presumably correct (although I can't read it to check), but the other two strings are obviously wrong. It looks to me like the name was encoded once from the original Unicode Bengali as UTF-8, then the byte sequence subsequently treated as Latin-1 or Windows-1252, resulting in a double encoding. Fixing it should be easy enough for anyone who knows the language. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441319: Mitra Mono also has a similar problem
Mitra Mono also has a similar problem Mitra Mono,\\u09ae\\u09bf\\u09a4\\u09cd\\u09b0:style=Regular Here, \u escapes have been used for the characters. If this is valid but just not supported by fontconfig, maybe the issue should be reported as a bug with fontconfig, but nonetheless putting literal characters in the font would be a good idea for compatibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439767: libpango1.0-0: pango renders U+200B (zero width space) visibly under certain conditions
On Sat, Sep 08, 2007 at 08:06:15PM +0200, Sven Arvidsson wrote: Hi again, I forwarded this bug to the upstream developers, http://bugzilla.gnome.org/show_bug.cgi?id=472657 They are asking if you also see this in gedit? Yes, see screenshot attached. Typing any Latin character between the Tibetan text and the U+200B makes the visible glyph vanish. The Monlam Uni Ochan1 font I'm using can be obtained from the Monlam Bod-yig v2 zip file on my Tibetan fonts site, http://www.aerifal.cx/~dalias/bodyig/fonts/ (The alternative is the upstream site that distributes it only as a Windows .exe file, www.lobsangmonlam.org.) My site has it listed under legacy fonts, but this is just because it has glyphs on top of other script ranges that do not belong to Tibetan, as well as other non-Unicode fonts packaged with it; the font in question here does have valid OpenType tables and works fine for displaying Unicode-encoded Tibetan on both Linux/Pango and Windows. attachment: gedit_pango_tib_bug.png
Bug#441354: xterm mispositions character glyphs with gnu unifont
Package: xterm Version: 229-1 Severity: normal When using GNU Unifont with xterm, certain Unicode characters (0100-011F, 017F-019F, 0200-021F, ...) are displayed in the wrong position, roughly half a cell-width to the left of where they belong. Using urxvt works fine so the issue seems to be a problem with xterm and not the font. The characters which are displayed wrongly are exactly those for which the low 8 bits of the character number correspond to ISO-8859 control characters. I suspect xterm is doing some funny 8bit-codepage logic and not turning it off for UTF-8 locales like it should. I can provide screenshots if needed. Here is a test string which should show the problem: AĀBāCĠDſEƀ All of Ā, ā, ſ, and ƀ appear in the wrong positions, while the ASCII characters and Ġ appear correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441355: regcomp DoS'able in utf-8 locales
Package: libc6 Version: 2.6.1-2 Severity: important glibc's regular expression engine crashes with sig11 whenever trying to compile a regular expression with non-ASCII range expressions if LC_CTYPE is a UTF-8 locale but LC_COLLATE is set to C or POSIX. This is a common setup among users who want traditional codepoint-order sorting but need UTF-8 encoding. $ LANG=en_US.UTF-8 LC_COLLATE=C grep '[Á-ä]' Segmentation fault The bug can cause crashes in any program using the system regex routines and could in principle be used for DoS attacks if a less-privileged user is able to provide regular expressions to a more-privileged process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441357: Tibetan glyphs for GNU Unifont (patch attached)
Package: unifont Version: 1:1.0-4 Severity: wishlist Unifont contains an incomplete set of Tibetan glyphs covering most of the range U+0F40 to U+0F68, but these are insufficient for even minimal use of the language. Proper rendering of Tibetan requires contextual substitutions ala OpenType, but the attached patch provides glyphs for use with simple overstrike-combining to make any text in the modern language legible. The original incomplete set of glyphs used glyph shapes too large to accommodate overstrike combining, so this patch replaces them too. I would send this upstream but there seems to be no upstream anymore. The glyphs in my patch were all drawn by me and may be used under the same license terms as the rest of GNU unifont. --- unifont.hex.orig2007-09-08 22:52:50.0 + +++ unifont.hex 2007-09-09 04:41:07.0 + @@ -1844,40 +1844,155 @@ 0ED9:324A4A4A4A4A2400 0EDC:B9D52600 0EDD:89DD2E00 -0F40:7E2A2A4A4A0202020202 -0F41:7E5252525A4642404040 -0F42:7E4A4A4A6A1A0A020202 -0F43:7E4A6A1A0A027E405C220400 -0F44:7E4040407C02 -0F45:7E10186422120C00 -0F46:7C10385454542800 -0F47:7E407E407C02 -0F49:30480818240404081000 -0F4A:7E02023E424040201008 -0F4C:7E02023E40404040 -0F4E:7E101038545448404040 -0F4F:7E40407C420202040810 -0F50:7E42462A1222621A0602 -0F51:7E40407C02020202 -0F53:7E08081C2A2A12020202 -0F54:7222621A06020200 -0F55:72266A1A06020200 -0F56:7E22621A06020200 -0F58:7A1212325A562202 -0F59:00037E10186422120C00 -0F5A:00037C10385454542800 -0F5B:00037E407E407C02 -0F5D:225252121E121A06 -0F5E:3C4E49413101 -0F5F:7E027E027E02 -0F60:38580402 -0F61:5A525A260202 -0F62:7E10103C42020200 -0F63:324A4A5A46020200 -0F64:0E12125E22120202 -0F66:72524A4A66160202 -0F67:7E204C3202040810 -0F68:5D59692303010100 +0F00:18671C5D4955534B3901 +0F01:005C4854524A3901 +0F04:06C1314E310E +0F05:0C02621C621C +0F06:06C1314E310E000C04040404 +0F07:0815C439 +0F08:324C006C1038101010101010 +0F09:001E2101020E110E1101 +0F0A:000F304E5141424E514E5140310F +0F0B:00181800 +0F0C:00181800 +0F0D:001818080808080808080808 +0F0E:003636121212121212121212 +0F0F:001818001808080808080808 +0F10:001800180018080808080808 +0F11:006600180018080808080808 +0F12:0814493E0077001A2C08080808080800 +0F13:180018A5A5180018 +0F14:0018242418003C0018242418 +0F19:0018080808080800 +0F1A:18242418 +0F1B:2222 +0F1C:081414082222 +0F1D:00140814 +0F1E:00552255 +0F1F:00255225 +0F20:000E112121221C00 +0F21:00060B1101020408 +0F22:001E2101020E1101 +0F23:001E21020E01021E2100 +0F24:122C40417E00 +0F25:00223C040201 +0F26:00404428270E +0F27:000101314A123C00 +0F28:00081020700804020101 +0F29:001C2224494E4040 +0F2A:000C16220F740810 +0F2B:003C420F741C2202 +0F2C:003C42041F72043C4200 +0F2D:122C46497E204000 +0F2E:00224E553C440201 +0F2F:0040452A2719112E4000 +0F30:000101314F723C00 +0F31:00081020720D34420101 +0F32:031D2A34694E4040 +0F33:001D22464A543840 +0F34:181800101C04101C0400 +0F35:10552A1C +0F36:181800001818 +0F37:18242418 +0F38:334A525C +0F39:07040200 +0F3C:0202040808182020202020204000 +0F3D:20201008080C0202020202020100 +0F40:003F156505010101 +0F41:003F494D4B414100 +0F42:003F496959090101 +0F43:003F496959091F204E311101 +0F44:001E204078440201 +0F45:003E08084E31110E +0F46:003E08083E494936 +0F47:001E203C407C4201 +0F49:0038444E01010200 +0F4A:007F013D43414040 +0F4B:003F213A2C222F302000 +0F4C:003C02011F2140404000 +0F4D:003C02011F205E604E311101 +0F4E:003F081C12322C202000
Bug#440980: iceweasel seriously misrenders tibetan text with tibetan machine uni font
Package: iceweasel Version: 2.0.0.6-1 Severity: normal Tags: l10n *** Please type your report below this line *** When using the Tibetan Machine Uni font (which is packaged with Debian and intended as the default font for Tibetan script), Iceweasel is displaying every combining character separately as a dotted circle with the combining character attached to it, rather than correctly attached to the previous character. See screenshot: http://www.aerifal.cx/~dalias/images/iceweasel_tmuni_bug.png And what it should look like (using a different font): http://www.aerifal.cx/~dalias/images/iceweasel_jomo_ok.png Pango is enabled; it is required for display of Tibetan text. This does not seem to be a bug in Pango, however, since both GTK widgets and GIMP successfully render Tibetan text using Pango. On the other hand, it very likely could be a misuse of Pango, since Abiword exhibits incorrect display (albeit different from the Iceweasel issue; Abiword seems to ignore the OpenType tables completely) with this font as well, while working fine with other fonts. As a workaround, users can remove the ttf-tmuni package and install the ttf-dzongkha package instead, which provides a different font for Tibetan script. However, users of these languages will often want to have all Tibetan fonts installed for word processing use, etc., which will cause any website explicitly requesting the Tibetan Machine Uni font to become completely illegible. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-rc5-nkl1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils 2.23.1 Miscellaneous utilities specific t ii fontconfig 2.4.2-1.2generic font configuration library ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgcc1 1:4.2.1-4GCC support library ii libglib2.0-02.14.0-2 The GLib library of C routines ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libhunspell-1.1-0 1.1.9-1 spell checker and morphological an ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libnspr4-0d 4.6.7-1 NetScape Portable Runtime Library ii libnss3-0d 3.11.7-1 Network Security Service libraries ii libpango1.0-0 1.16.5-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libstdc++6 4.2.1-4 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxp6 1:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxrender1 1:0.9.3-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii psmisc 22.5-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439767: libpango1.0-0: pango renders U+200B (zero width space) visibly under certain conditions
Package: libpango1.0-0 Version: 1.16.5-1 Severity: normal After upgrading my system, the latest Pango renders U+200B (zero-width space) visibly under certain conditions, as a missing glyph box containing the hex value. Particularly, Pango seems to be a looking for a glyph for this character matching the current language/script. In my case, Tibetan characters adjacent to U+200B cause the misrendering to happen. I first observed the problem on a Google search (in Iceweasel) but have since been able to reproduce it in GTK+ text widgets by first typing U+200B (using an input method) then moving the cursor before the U+200B character and typing any Tibetan character. Thus, I am fairly confident that the bug is in Pango itself and not GTK+ or Iceweasel. I suspect the Tibetan fonts I am using lack a glyph for U+200B, but Pango should not be insisting on trying to find a Tibetan version of this character. It probably shouldn't even look for glyphs at all, but instead always treat it as a zero-width character with no visible glyph... but if it is going to use a glyph it should grab one from any available font. Screenshot of the issue: http://www.aerifal.cx/~dalias/images/200b.png -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-rc5-nkl1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpango1.0-0 depends on: ii libc6 2.6.1-1 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libdatrie0 0.1.1-4 Double-array trie library ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libglib2.0-02.14.0-2 The GLib library of C routines ii libpango1.0-common 1.16.5-1 Modules and configuration files fo ii libthai00.1.8-3 Thai language support library ii libx11-62:1.0.3-7X11 client-side library ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime libpango1.0-0 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419617: uim-common: postinst script fails (in init.scm?)
Subject: uim-common: postinst script fails (in init.scm?) Package: uim-common Version: 1.4.1-2 Severity: grave Justification: renders package unusable File: uim-common *** Please type your report below this line *** apt-get install results in the following: 8 Setting up uim-common (1.4.1-2) ... ERROR: unbound variable (errobj use) *backtrace* (use srfi-23) (require init.scm) (*catch (quote errobj) (require init.scm)) (eq? (quote *init.scm-loaded*) (*catch (quote errobj) (require init.scm))) ERROR: unbound variable (errobj use) failed to require uim-module-manager.scm: Success dpkg: error processing uim-common (--configure): subprocess post-installation script returned error exit status 1 8 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-rc5-nkl1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
