Bug#575575: Fwd: Bug#575575: Should in-source timidity be disabled?
On Sat, Dec 03, 2011 at 02:01:34PM +, Manuel A. Fernandez Montecelo wrote: I was thinking about disable the in-source use of timidity in SDL_mixer, mostly because it's an in-source copy of the code (which can make SDL_mixer and programs using it exploitable). However I don't know if this is possible, I don't know much about MIDI, and just took over maintenance of this package. Can you help me to make some informed decision? Greetings. First, thank you for taking over SDL_mixer! Now, about timidity and MIDI music. Of course the version of timidity embedded in SDL_mixer is very old (before it was forked off into timidity++) because of licensing conflicts, and bug reports like this one have been because of its bugs and shortcomings. I don't know about any security holes in the old version of timidity, though -- are there any security alerts posted anywhere? Unfortunately, native_midi_gpl isn't very flexible. It hits the hardware (GUS, AWE, FM or OPL3) directly, which isn't very clean or compatible. So I'd recommend leaving timidity enabled even if native_midi_gpl is enabled, just from a usability perspective. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605143: Formatting errors in some MS-DOS executable descriptions
Package: libmagic1 Version: 5.04-5 Some of the messages describing MS-DOS executables are formatted incorrectly, using \b (the don't add whitespace before this message code) in the wrong place so that files will be described, for example, like this: doom-1.9u/doom.exe: MS-DOS executable ,\b LE for MS-DOS, DOS4GW DOS extender (embedded) doom2-1.9/doom2.exe: MS-DOS executable ,\b LE for MS-DOS, DOS4GW DOS extender (embedded) heretic-1.0/heretic.exe: MS-DOS executable ,\b LE for MS-DOS, DOS4GW DOS extender (embedded) Enclosed is a patch which fixes these mistakes so that files will be described as follows: doom-1.9u/doom.exe: MS-DOS executable, LE for MS-DOS, DOS4GW DOS extender (embedded) doom2-1.9/doom2.exe: MS-DOS executable, LE for MS-DOS, DOS4GW DOS extender (embedded) heretic-1.0/heretic.exe: MS-DOS executable, LE for MS-DOS, DOS4GW DOS extender (embedded) diff -Naurp file-5.04.old/magic/Magdir/msdos file-5.04/magic/Magdir/msdos --- file-5.04.old/magic/Magdir/msdos 2009-09-19 16:28:11.0 + +++ file-5.04/magic/Magdir/msdos 2010-11-27 19:11:02.0 + @@ -209,8 +209,8 @@ # calculations (next embedded executable would be at (2*512+0-2) # I suspect there are only LE executables in these multi-exe files (2.s-514) string BW -0x240 search/0x100 DOS/4G ,\b LE for MS-DOS, DOS4GW DOS extender (embedded) -0x240 search/0x100 !DOS/4G ,\b BW collection for MS-DOS +0x240 search/0x100 DOS/4G \b, LE for MS-DOS, DOS4GW DOS extender (embedded) +0x240 search/0x100 !DOS/4G \b, BW collection for MS-DOS # This sequence skips to the first COFF segment, usually .text (4.s*512) leshort 0x014c \b, COFF
Bug#577623: Inaccurate colormap choices when converting RGB to indexed
Package: gimp Version: 2.6.8-2 When converting an RGB image to indexed, the GIMP sometimes fails to choose as accurately as it could between similar colors in a chosen palette, even when each pixel has an exact match somewhere in the palette. The enclosed colormaptest.ppm and Colormap_test files together form a test case to reproduce this bug, as follows: 1. Compare colormaptest.ppm (a text PPM image) and Colormap_test (a GIMP palette) to verify that each contains the same RGB triples in the same order. 2. Move or copy Colormap_test into a directory for GIMP palettes, e.g., the ~/.gimp-2.6/palettes/ directory. 3. Start the GIMP and open colormaptest.ppm, then zoom in enough that you can see each individual pixel. 4. Right-click image - Image - Mode - Indexed... to open the Indexed Color Conversion dialogue, and set it as follows: a. Under Colormap, select Use custom palette, then click the button below that selection to pop up the list of available palettes. From this list select Colormap_test. Uncheck the Remove unused colors from colormap checkbox if it's checked. b. Under Dithering, for Color dithering: select None. Uncheck the Enable dithering of transparency checkbox if it's checked. c. Click Convert. 5. Observe that while the leftmost and middle pixels have been mapped to their exact matches in the palette, the rightmost pixel has been mapped to the same color as the middle pixel. (Try pressing ^Z to undo and ^Y to redo repeatedly if you don't see it at first.) attachment: colormaptest.ppmGIMP Palette 103 79 59 95 71 55 87 67 51
Bug#575690: geeqie fails to recognize some PPM images
Package: geeqie Version: 1:1.0-1 Severity: normal geeqie fails to recognize some PPM images which are readable by both the GIMP (gimp version 2.6.8-2) and pnmtopng (libnetpbm10 version 2:10.0-12.1). As an example, I refer to the PPM image files attached to this report: works.ppm displays correctly fails.ppm unrecognized The only formatting difference is that the former has an embedded comment (# CREATOR: The GIMP's PNM Filter Version 1.0), while the latter does not. I believe that gtk or one of its associated libraries (perhaps gdk_pixbuf?) may be at the root of the problem, since the unrecognized file problem occurs when gtk2.0-0 version 2.18.9-2 is installed, yet both images are displayed successfully when gtk2.0-0 version 2.18.6-1 is installed. However I don't know enough about the internals of gtk, gdk or geeqie to make a definitive statement. attachment: works.ppmattachment: fails.ppm
Bug#575575: timidity MIDI playback plays drums that should be musical notes
Package: libsdl-mixer1.2 Version: 1.2.8-6+b1 Severity: normal Tags: patch When using timidity MIDI playback, music played in MIDI channels 10 and 16 are interpreted as drums. Really, only channel 10 should default to drums, according to the MIDI standard; drums on channel 16 are a Microsoft substandard. :) To fix this misfeature, please apply the attached patch. Contrary to what the comment above the affected line says, this is *not* a runtime option in SDL_mixer, as far as I can tell. --- sdl-mixer1.2-1.2.8.orig/timidity/config.h 2007-07-02 02:03:51.0 + +++ sdl-mixer1.2-1.2.8/timidity/config.h 2009-12-03 22:44:42.0 + @@ -35,7 +35,7 @@ On the other hand, some files know that 16 is not a drum channel and try to play music on it. This is now a runtime option, so this isn't a critical choice anymore. */ -#define DEFAULT_DRUMCHANNELS ((19) | (115)) +#define DEFAULT_DRUMCHANNELS (19) /* A somewhat arbitrary frequency range. The low end of this will sound terrible as no lowpass filtering is performed on most
Bug#519756: Spammy MD5 Hash NOT expected but found messages
Package: linux-image-2.6.26-1-686 Version: 2.6.26-13 While running rtorrent with one or more torrents open, I frequently get kernel warnings like the following: [288159.044121] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288160.767280] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288161.904441] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288163.080024] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288164.415410] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288165.906853] MD5 Hash NOT expected but found (71.130.128.214, 65175)-(192.168.1.100, 16991) [288168.322260] __ratelimit: 1 messages suppressed in bursts of about ten or so warnings at a time, every few minutes. The only apparent solution is to cut off connections from the offending IP(s). I don't think anything is actually breaking, but these warnings can get really spammy and I'd like it if they could be cut down. There has been some discussion on the kernel.org netdev mailing list about how to deal with the MD5 hash problem more gracefully. First discussion is in this thread: http://kerneltrap.org/mailarchive/linux-netdev/2008/7/29/2734974/thread Adam Langley submitted a patch to remove the MD5 hash warnings entirely: http://kerneltrap.org/mailarchive/linux-netdev/2008/7/29/2736054 David S. Miller submitted a patch to use MIB counters instead of warnings: http://kerneltrap.org/mailarchive/linux-netdev/2008/7/30/2746014 Please consider applying one of these two patches, or finding another solution. Kernel: Linux treehouse 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux libc6 version: 2.9-4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
