RELEASE: Morituri 0.1.3 'cranes'
This mail announces the release of Morituri 0.1.3 'cranes'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket morituri is a CD ripper aiming for accuracy over speed. Its features are modeled to compare with Exact Audio Copy on Windows. This is morituri 0.1.3 "cranes". This is intended as a release for daring and curious people who've had enough of the fact that Windows has a more accurate CD ripper than Linux. Coverage in 0.1.3: 60 % (1716 / 2825), 85 python tests Features added in 0.1.3: - shorten really long file names if needed - support multi-disc ripping - add %y for release year in templates - added rip cd rip --release-id option to select the exact release - allow track and disc templates to create files in different directories - work out relative paths from cue/m3u files to audio files Bugs fixed in 0.1.3: - 77: Unable to find solution to UTF-8 problem - 93: Unable to choose if there are more than one matching CD - 67: unable to rip multi-cd-sets correctly - 73: rip image breaks with "query failed" - 78: Could not create encoded file - 84: Error when checksumming extremely short tracks - 91: --release-id does not work for Pink Floyd - The Wall (Experience Edition) (Disc 1) - 94: mp3vbr uses quality=0 instead of vbr-quality=0 - 95: Discs with multiple media not correctly identified. - 99: rip offset find fails with "UnboundLocalError: local variable 'archecksum' referenced before assignment" - 102: Unable to run without -d option - 98: Year of release in templates morituri 0.1.3 is brought to you by: Loïc Minier Ross Burton Christophe Fergeau Thomas Vander Stichele ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#728202: cmus: m4a playback is broken
Package: cmus Version: 2.5.0-4 Followup-For: Bug #728202 Hi! I did yesterday a 'aptitude safe-upgrade'. That included cmus. It was updated from 2.5.0-2 to 2.5.0-4 and since then I have the same problem. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cmus depends on: ii libao4 1.1.0-2 ii libasound2 1.0.27.2-3 ii libc6 2.17-93 ii libcddb21.3.2-3 ii libcdio-cdda1 0.83-4 ii libcdio13 0.83-4 ii libfaad22.7-8 ii libflac81.3.0-2 ii libmad0 0.15.1b-8 ii libmodplug1 1:0.8.8.4-4 ii libmpcdec6 2:0.1~r459-4 ii libncursesw55.9+20130608-1 ii libtinfo5 5.9+20130608-1 ii libvorbisfile3 1.3.2-1.3 ii libwavpack1 4.60.1-3 Versions of packages cmus recommends: ii cmus-plugin-ffmpeg 2.5.0-4 ii libpulse0 4.0-6+b1 cmus suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
RELEASE: Morituri 0.1.1 'Dead'
This mail announces the release of Morituri 0.1.1 'Dead'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket morituri is a CD ripper aiming for accuracy over speed. Its features are modeled to compare with Exact Audio Copy on Windows. This is morituri 0.1.1 "Dead". This is intended as a release for daring and curious people who've had enough of the fact that Windows has a more accurate CD ripper than Linux. Coverage in 0.1.1: 64 % (1575 / 2440), 61 python tests Features added in 0.1.1: - added 'rip image encode' command to encode an image to a lossy codec. - provided lossy codec profiles for vorbis, mp3, and mp3vbr - added a complete list of known drive offsets from AccurateRip - added a generated man page - better exception handling in tasks - tag audio files with musicbrainz id's - added 'rip image retag' command to retag audio files in an image Bugs fixed in 0.1.1: - 11: AccurateRip failure on similar URL - 12: morituri: 'rip -h' shows gstreamer help, not morituri help, but 'rip help' works fine. - 14: AttributeError: 'NoneType' object has no attribute 'name' - 16: Fatal error passing unescaped unicode strings to GStreamer - 17: Incorrect file permissions - 19: Use sortname in filenames morituri 0.1.1 is brought to you by: Peter Oliver Thomas Vander Stichele ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
RELEASE: Morituri 0.1.2 'VCR'
This mail announces the release of Morituri 0.1.2 'VCR'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket morituri is a CD ripper aiming for accuracy over speed. Its features are modeled to compare with Exact Audio Copy on Windows. This is morituri 0.1.2 "VCR". This is intended as a release for daring and curious people who've had enough of the fact that Windows has a more accurate CD ripper than Linux. Coverage in 0.1.2: 61 % (1683 / 2755), 65 python tests Features added in 0.1.2: - UTF-8/unicode handling fixes - improved error handling - ignore tags for alac and wav - work around GStreamer flacparse bugs - change how paths get referenced in .cue files - properly interpret AccurateRip results; no more assertions on unexpected ordering of results - add debug command Bugs fixed in 0.1.2: - 5: AccurateRip Error on Arctic Monkeys disc - 10: pathnames in log and cue - 15: AttributeError: '__main__.GstWavEnc' object has no attribute 'merge_tags' - 24: nasty exception when cdrdao is missing - 25: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 21: ordinal not in range(128) - 32: Add python-setuptools as Requires in specfile - 37: rip fails on a hidden track of single sector (or 0?) length - 38: morituri dies trying to construct the cue file for a number of CDs - 43: Set the album artist tag - 46: running uninstalled: morituri-trunk - no bash completion file - 49: Doesn't encode UTF-8 HTOA track name properly - 50: Bogus extension stripping of HTOA track in .m3u - 64: always failing after ripping first track - 35: UnboundLocalError: local variable 'results' referenced before assignment - 61: 'rip image --help' should specify that it's intended to work with .cue files - 62: Crash if no disc in drive - 51: Typos - s/reponses/responses - 59: Typo in 'rip drive list' output morituri 0.1.2 is brought to you by: Loïc Minier Ross Burton Thomas Vander Stichele ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#826133: kodi-pvr-hts: Incompatible version of kodi-pvr-hts in jessie-backports
Package: kodi-pvr-hts Version: 2.1.18-1~bpo8+1 Severity: grave Tags: newcomer Justification: renders package unusable Dear Maintainer, this week there was an update of the jessie-backport package kodi to version 16.x. The package kodi-pvr-hts, however, was not updated. When I tried so activate the kodi-pvr-hts addon in kodi, this lead to an error, the kodi-logfile says: 17:25:30 T:140597163718400 ERROR: PVR - Add-on 'Tvheadend HTSP Client' is using an incompatible API version. XBMC minimum API version = '4.1.0', add-on API version '1.9.6' I expected to get a working pvr-hts addon, which is required to watch live tv on kodi. Technically, I expected to receive an update for kodi-pvr-hts on jessie-backports, too. Best regards, Thomas -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-0.bpo.1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kodi-pvr-hts depends on: ii kodi 16.1+dfsg1-1~bpo8+2 ii libc6 2.19-18+deb8u4 ii libcec-platform1 1.0.10+dfsg1-7~bpo8+1 ii libfstrcmp0 0.7.D001-1.1 ii libgcc1 1:4.9.2-10 ii libstdc++64.9.2-10 kodi-pvr-hts recommends no packages. kodi-pvr-hts suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#665410: hydrogen: sound is distorted
I've reinstalled and the problem has vanished, seems to be an issue with flash So I will carry on finding this and this bug can be closed sorry On 23 March 2012 21:59, Dick William Thomas wrote: > Package: hydrogen > Version: 0.9.6~beta1-2 > Severity: normal > > Dear Maintainer, > *** Please consider answering these questions, where appropriate *** > > * What led up to the situation? > installed hydrogen and just made a sample sound it sounded awful but! I've > also > noticed that minecraft also does this poor audio but with it > not been a repo app I didn't report it > * What exactly did you do (or not do) that was effective (or > ineffective)? > Just going to try a fresh install see if that fixes it > Id on't know what else to try as Not up to speed an hydrogen as I've never > used > it before > I've also > * What was the outcome of this action? > Will comment later on reinstall > * What outcome did you expect instead? > > *** End of the template - remove these lines *** > > > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages hydrogen depends on: > ii libarchive12 3.0.3-7 > ii libasound21.0.25-2 > ii libc6 2.13-27 > ii libgcc1 1:4.6.3-1 > ii libjack-jackd2-0 [libjack-0.116] 1.9.8~dfsg.2-1 > ii libportaudio2 19+svn2021-1 > ii libportmidi0 1:184-2 > ii libqt4-network4:4.7.4-2 > ii libqt4-xml4:4.7.4-2 > ii libqt4-xmlpatterns4:4.7.4-2 > ii libqtcore44:4.7.4-2 > ii libqtgui4 4:4.7.4-2 > ii libsndfile1 1.0.25-4 > ii libstdc++64.6.3-1 > > Versions of packages hydrogen recommends: > ii hydrogen-drumkits 0.9.3.20070703-3 > ii rubberband-cli 1.3-1.2 > > hydrogen suggests no packages. > > -- no debconf information > -- Dick Thomas xpd...@gmail.com Blog: www.xpd259.co.uk G+: www.google.com/profiles/xpd259 NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Richard Thomas and the recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. If you have received this email in error please notify me as soon as possible. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#67259: mpg123 doesn't fail cleanly on "no space left on device"
I'm having a go at the nearly 12-year-old bug. There is a fix in mpg123 trunk now. At least you get an error message now when the file cannot be flushed to disk. It results in mpg123 aborting with non-zero exit code only when the file header (or at least a single byte at the beginning) cannot be flushed. When the out-of-disk occurs later, you get the error message from a final flush on closing the file, but the return value of that is not handled (would be some PITA to add that). Perhaps I'll consider dropping usage of STDIO from the file writer, since adding fflush() all around to detect the condition earlier kindof defeats the idea of buffered streams. Anyhow, the user is informed with the next major mpg123 release and that is hopefully enough to close this bug. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667653: mpg123 FTBFS on armhf
What is this ...? As mpg123 upstream it would be cool to get note of such issues without having to look for them in the debian bts. Having some bot subscribe and post to mpg123-de...@lists.sourceforge.net would be splendit; but if that is too troublesome, sending an info to maintai...@mpg123.org would be just as fine (using the generic address in case I vanish in future). But perhaps I overlooked a generic way to subscribe an address to all future reports. Second: There is no inline assembly in mpg123. The file at hand (layer3.c) is plain C all around. So, without further data, I must assume that this is a bug in gcc that is worked around by adding -marm. You might consider asking gcc folks about this. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667653: mpg123 FTBFS on armhf
Am Fri, 6 Apr 2012 22:27:07 -0400 schrieb Miguel Colon : > I saw that layer3.c includes "#include "mpg123lib_intern.h" and that > in that file there is a block: > > # elif defined(OPT_ARM) > /* for arm */ > # define REAL_MUL_ASM(x, y, radix) \ > Damn, you got me there! I really did not think about those support macros only about our "real" assembly instructions in plain assembler files. Thanks for investigating. I'll present you work to our assembly man who wrote this code and see to it that the next mpg123 release contains the fix. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667653: mpg123 FTBFS on armhf
Okay, our assembly expert got me, too: We have a fix for this in mpg123 trunk since september last year! I pulled that change into another 1.13 release, it is a bit different from your patch. Could you (peter?) test http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now? I'll make it officialy public, then. The fresh 1.14-beta2 has the fix, too, btw. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#670236: mplayer2: can't play video with resolution of 2542x1080
Am 07.05.2012, 18:49 Uhr, schrieb Roland Scheidegger : You could try it out by compiling the intel ddx driver yourself, the limits are IMAGE_MAX_WIDTH/IMAGE_MAX_HEIGHT in intel_video.c. (Of course, the real fix would take the hw into account, 2048 seems indeed like the limit for i915.) FTR the gl2 video output of mplayer (no idea whether it's still in mplayer2) can handle dimensions > GL_MAX_TEXTURE_SIZE by texture tiling. Cheers, Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#672123: libmpg123-0: glibc heap corruption when cueing backwards in MP3 in mplayer
Am Tue, 8 May 2012 11:28:44 -0600 (MDT) schrieb Paul Walmsley : > > Package: libmpg123-0 > Version: 1.14.0-1 > Severity: normal > The stack trace suggests the bug may be in libmpg123, although it is of course > difficult to know what actually corrupted the memory: This is most likely the exact bug I already encountered and fixed with mpg123-1.14.1 . Hopefully upgrading to that one will fix it. Alrighty then, Thomas (mpg123 upstream) signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#677148: mpg123_getformat() hangs in endless loop
Am Mon, 11 Jun 2012 23:27:45 +0200 schrieb Max Kellermann : > On (broken?) MP3 files, mpg123_getformat() hangs in an I/O loop that > reads one byte at a time, seeks back 64 kB, and repeats practically > forever. Example strace: Does plain mpg123 play the file? shell$ mpg123 /path/to/file.mp3 I don't see funny things in MPD's mpg123 usage. It does handle = mpg123_new(NULL, &error); error = mpg123_open(handle, path_dup); error = mpg123_getformat(handle, &rate, &channels, &encoding); ... and according to your report, it hangs there, trying to find a valid header. The same should happen to mpg123. > [...] > read(4, "\277", 1) = 1 > read(4, "Y", 1) = 1 > read(4, "\36", 1) = 1 > read(4, "\v", 1)= 1 > lseek(4, -65536, SEEK_CUR) = 19013 > read(4, "\277", 1) = 1 > read(4, "Y", 1) = 1 > read(4, "\36", 1) = 1 > read(4, "\v", 1)= 1 > read(4, "\"", 1)= 1 > read(4, "`", 1) = 1 > [...] > Judging from that ... this must be guess_freeformat_framesize(). This is called when a header indicating a free-format stream is encountered. That needs a search for a following header to determine frame size. 64K is perhaps a bit excessive here; I'd have to check that the actual maximally possible frame size is (with low sample rate and high bit rate, you can achieve rather larger individial frames). > This causes the Music Player Daemon (when built with libmpg123) to go > in an endless busy loop upon starting playback, and becomes > irresponsive as soon as a client ask MPD to change playback. Severity > "important" (or more) because this bug is a remote DoS vulnerability > for MPD. Theoretically, if the free format header search is triggered repeatedly, eventually, mpd should finish decoding the file. > lseek(4, -65536, SEEK_CUR) = 19013 That position should increase over time, at least ... I see that this free format search is somewhat of a loophole. Normally, mpg123 will stop trying after encountering 64K of junk (this limit is configurable). In case of free format headers, the search for the following one is not counted as junk, as there could be perfectly valid headers in between that don't qualify as following. So, if the search fails (and we need a seek back of 64K), just the inital free format header is discarded and counts towards the 64K of junk. We could include some safeguards here, perhaps enforcing that this search for free format frame size only happens once, making the regime more strict for those streams than for normal ones (which might be reasonable as free format streams are rare). > Due to copyright issues, I will provide a sample file demonstrating > the problem via private email only. I'd like to test that file myself (as mpg123 upstream, as you might have guessed). It seems to be a rather nasty example of kicking off the free format search repeatedly. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#677148: mpg123_getformat() hangs in endless loop
Am Tue, 12 Jun 2012 09:25:07 +0200
schrieb Max Kellermann :
> On 2012/06/12 09:20, Thomas Orgis wrote:
> > Does plain mpg123 play the file?
> >
> > shell$ mpg123 /path/to/file.mp3
>
> No, same problem.
That is good: It means I can debug and fix without touching mpd;-) Attached is
a hotfix patch that limits the attempts to guess free format frame size. I'm
not totally sure about a followup detail about cleaner abort (it's in mpg123
trunk in addition to the patch), but you can expect mpg123-1.14.3 sometime in
the near future with a fix.
Meanwhile, can you test the attached patch if it helps, or grab
http://mpg123.org/snapshot for a prepared tarball of the trunk.
Alrighty then,
Thomas
Index: trunk/src/libmpg123/parse.c
===
--- trunk/src/libmpg123/parse.c (Revision 3190)
+++ trunk/src/libmpg123/parse.c (Revision 3191)
@@ -61,7 +61,7 @@
static const long freqs[9] = { 44100, 48000, 32000, 22050, 24000, 16000 , 11025 , 12000 , 8000 };
-static int decode_header(mpg123_handle *fr,unsigned long newhead);
+static int decode_header(mpg123_handle *fr,unsigned long newhead, int *freeformat_count);
static int skip_junk(mpg123_handle *fr, unsigned long *newheadp, long *headcount);
static int do_readahead(mpg123_handle *fr, unsigned long newhead);
static int wetwork(mpg123_handle *fr, unsigned long *newheadp);
@@ -445,6 +445,7 @@
int read_frame(mpg123_handle *fr)
{
/* TODO: rework this thing */
+ int freeformat_count = 0;
unsigned long newhead;
off_t framepos;
int ret;
@@ -495,7 +496,7 @@
#endif
ret = head_check(newhead);
- if(ret) ret = decode_header(fr, newhead);
+ if(ret) ret = decode_header(fr, newhead, &freeformat_count);
JUMP_CONCLUSION(ret); /* That only continues for ret == 0 or 1 */
if(ret == 0)
@@ -667,7 +668,7 @@
* <0: some error
* You are required to do a head_check() before calling!
*/
-static int decode_header(mpg123_handle *fr,unsigned long newhead)
+static int decode_header(mpg123_handle *fr,unsigned long newhead, int *freeformat_count)
{
#ifdef DEBUG /* Do not waste cycles checking the header twice all the time. */
if(!head_check(newhead))
@@ -724,6 +725,12 @@
if(fr->freeformat_framesize < 0)
{
int ret;
+ *freeformat_count += 1;
+ if(*freeformat_count > 5)
+ {
+if(VERBOSE3) error("You fooled me too often. Refusing to guess free format frame size _again_.");
+return 0;
+ }
ret = guess_freeformat_framesize(fr);
if(ret>0)
{
@@ -1015,6 +1022,7 @@
static int skip_junk(mpg123_handle *fr, unsigned long *newheadp, long *headcount)
{
int ret;
+ int freeformat_count = 0;
long limit = 65536;
unsigned long newhead = *newheadp;
/* check for id3v2; first three bytes (of 4) are "ID3" */
@@ -1064,7 +1072,7 @@
if((ret=fr->rd->head_shift(fr,&newhead))<=0) return ret;
- if(head_check(newhead) && (ret=decode_header(fr, newhead))) break;
+ if(head_check(newhead) && (ret=decode_header(fr, newhead, &freeformat_count))) break;
} while(1);
if(ret<0) return ret;
signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#341876: Fixed in upstream
Hi, your friendly upstream here! This should be fixed in the Icecast 2.3.3 release that we just published. We only accept metadata updates from the same IP as the source client. Of course if the two source clients are coming from the same IP... But then the chance that you can go over and smack the other guy is also pretty good. ;-) Cheers Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#652663: CVE-2011-4612
Hello, your friendly upstream here. We just released Icecast 2.3.3 which addresses this issue. Also for the record. It's fairly easy to spot those injection attempts by looking at the Icecast access log. Cheers Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#677148: mpg123_getformat() hangs in endless loop
Am Tue, 12 Jun 2012 23:16:02 +0200 schrieb Thomas Orgis : > I'm not totally sure about a followup detail about cleaner abort (it's in > mpg123 trunk in addition to the patch), but you can expect mpg123-1.14.3 > sometime in the near future with a fix. Update: It might be good to know that this problematic behaviour is specific to mgp123 1.14.1 and up. I fixed one bug in the parser and thus changed the resync behaviour to result in the apparently endless loop here. Let's keep in mind that the loop is not endless, though. It is just reading the file very slowly. The next release will contain a proper fix after I review the parser logic. In the end, it's a question of how hard one tries to find valid data. Btw., current mgp123 trunk doesn't search 64 K for a followup header but uses the maximal frame size it supports anyway (bringing the byte count down by factor 20 or so). Alrighty then, Thomas PS: What happened to that file? Is it intentionally screwed up? signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#677148: mpg123_getformat() hangs in endless loop; please verify mpg123-1.14.3
Hi again, please consider verifying that the upcoming mpg123 release really fixes the issue for good: http://mpg123.org/download/mpg123-1.14.3.tar.bz2 I'm waiting for confirmation before making the public announcement. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#652663: CVE-2011-4612
Hi Jonas, On 13/06/12 02:02, Jonas Smedegaard wrote: Hi Thomas, On 12-06-13 at 12:50am, Rücker Thomas wrote: Hello, your friendly upstream here. We just released Icecast 2.3.3 which addresses this issue. Also for the record. It's fairly easy to spot those injection attempts by looking at the Icecast access log. Great. I am looking into updating the packaging now. Just wondering how the updated package is going. Mainly as I hear there is a freeze coming to debian. Would be too bad to miss the window. Cheers Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#680101: mpg123: writing wav to stdout still works ugly
What exactly fails? With 1.14.3 (also 1.14.2, actually) I do this: $ mpg123 -w - bla.mp3 > bla.wav $ mpg123 -w /dev/stdout bla.mp3 > bla2.wav $ md5sum bla*.wav ebcdd5f3136e11265c99c578815c4b9b bla2.wav ebcdd5f3136e11265c99c578815c4b9b bla.wav Same for trunk ... at least for a single file, I don't see any problem. What did you test? Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#680101: mpg123: writing wav to stdout still works ugly
Am Wed, 4 Jul 2012 14:25:56 +0400 schrieb dimas : > well, in my case: > > >14:19:03 186 ~/downloads/music/Sword/1986 Metalized$ /usr/bin/mpg123 -q -w > >/dev/stdout 01.mp3 | file - Ah, everyday I learn something new. I did not know that there is a difference for a program between $ prog > output and $prog | otherprog > output In the former case, stdout is seekable (as it's a file), in the latter, it is not (as it's a pipe). Now, thinking about it, it's obvious. The shell opens the output file and maps the file descriptor to stdout of the child. Et voilá, you got seekable stdout. Now, back to the issue. I am getting angry about this. What triggers here is the attempt of mpg123 to deal with a full disk; code which tries to deal with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=67259 . It is actually non-trivial to handle out-of-disk well when using buffered I/O (C stdio). There is a test if at least one byte can be written at the beginning, combined with a seek to overwrite it again. I have to think hard why I did this. This is not necessary. Writing the header is test enough. Ah! No, for raw CD audio (cdr) writing, there is no header. Well, frick this ... I will remove the test with the single byte. This will fix this bug here by reverting to old behaviour. Only concession to bug 67259 is catching out-of-disk while writing WAV/AU header and informing at the end if out-of-disk condition prevented full output. I hope that makes everyone reasonably happy. Except me: I should just have ignored bug 67259. Two regressions with one attempt at fixing a not-really-fixable bug. That sucks. And: Looking for possible aliases for stdout won't happen. It will be treated just like any other file (in the case of a pipe, a non-seekable one). I will also clear up the situation about changing input format and WAV writing for the next release (at least document it). This stuff will part of mpg123 1.15.0, not a new 1.14.x release, as I am explicitly changing functionality (even if it is only a single byte write). Test with http://mpg123.org/snapshot --- does that work with dir2ogg? Alrighty then, Thomas -- Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org) OrgisNetzOrganisation ---)=- http://orgis.org GPG public key D446D524: http://thomas.orgis.org/public_key Fingerprint: 7236 3885 A742 B736 E0C8 9721 9B4C 52BC D446 D524 signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#652663: CVE-2011-4612
On 06/09/12 19:05, Moritz Muehlenhoff wrote: On Tue, Jun 26, 2012 at 06:36:56PM +0300, Rücker Thomas wrote: Hi Jonas, On 13/06/12 02:02, Jonas Smedegaard wrote: Hi Thomas, On 12-06-13 at 12:50am, Rücker Thomas wrote: Hello, your friendly upstream here. We just released Icecast 2.3.3 which addresses this issue. Also for the record. It's fairly easy to spot those injection attempts by looking at the Icecast access log. Great. I am looking into updating the packaging now. Just wondering how the updated package is going. Mainly as I hear there is a freeze coming to debian. Would be too bad to miss the window. CVE-2011-4612 is still unfixed in Wheezy, only in unstable. Please either ask the release managers to unblock 2.3.3 (unlikely at this time in the freeze) or upload an isolated fix to testing-proposed-updates. JFTR: We hurried out 2.3.3 still before the freeze so that it could possibly make it into wheezy. Carrying a 4+ year old release that misses numerous security and stability fixes is kind of impractical. So far there have been no regressions or new bugs found in 2.3.3 and it is a clean drop-in replacement for 2.3.2. Cheers Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#689659: mpg123 segfaults on specific file
Am Fri, 5 Oct 2012 22:06:49 +0200 schrieb Pavel Machek : > I cut this from the offending file, and it still causes the > crash. Is it enough for debugging? Thanks for the data and no, I cannot reproduce a crash on my main system (not debian). I get valgrind to complain about overlapping memcpy in the ALSA library, but that's not new and not specific to the file. I checked a i686 chroot, too, no issue. I guess I'd need to whip out a debian install/vm to reproduce. I have intentionally very old glibc here; before that infamous memcpy optimization ... which we very well might be dealing with here. But a test LD_PRELOAD checking for overlapping memcpy didn't trigger, neither. Can you run under valgrind to check memory issues? Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#689659: mpg123 segfaults on specific file
Am Sat, 6 Oct 2012 13:07:55 +0200 schrieb Pavel Machek : > What is "the infamous memcpy optimization"? I tried brief google, but > nothing. This? http://lwn.net/Articles/417881/ It has no details :-(. Yeah, I am talking of the change referred to there. Damn, this is a long time ago already. Software _should_ have catched up with the enforced memcpy() behaviour ... > pavel@amd:/tmp$ valgrind mpg123 mp3.bug/cut.mp3 Ah, this is an AMD box. So this could be the 3DNow(ext) code ... I could fire up an Athlon XP with debian squeeze and update it ... but not anyday soon. I don't have 32 bit AMD systems hanging around connected. I don't see > ==18936== Process terminating with default action of signal 11 > (SIGSEGV): dumping core > ==18936== Bad permissions for mapped region at address 0x805EFFC > ==18936==at 0x4028E3C: memcpy (in > /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) > ==18936==by 0x804D322: ??? (in /usr/local/bin/mpg123) > ==18936== Invalid read of size 1 > ==18936==at 0x4008D11: check_match.8610 (dl-lookup.c:134) > ==18936==by 0x400936A: do_lookup_x (dl-lookup.c:273) > ==18936==by 0x4009661: _dl_lookup_symbol_x (dl-lookup.c:729) > ==18936==by 0x400DC15: _dl_fixup (dl-runtime.c:119) > ==18936==by 0x40139BF: _dl_runtime_resolve (dl-trampoline.S:37) > ==18936==by 0x4035E0F: ??? (in /tmp/mp3.bug/cut.mp3) > ==18936==by 0x804D322: ??? (in /usr/local/bin/mpg123) > ==18936== Address 0x1eb is not stack'd, malloc'd or (recently) free'd ... as that does not make a lot of sense anyway (the input file is in the call trace??). I installed a wheezy system in qemu-kvm and could not reproduce the crash. But I got 1.14.4-1 there, not 1.14.2+svn20120622-1. Do you see the crash with the updated package? Suspecting one of the assembly decoders, I noticed that the debian build of mpg123 is fixed to the i486 one: shell$ mpg123 --list-cpu builtin decoders: i486 Is that intentional? This is just some C code with quirks to please the i486 CPU, not necessarily of any benefit on other x86 cores. Generic of i386 should be preferred. But most of all: For sensible performance, one should use the multi-cpu default build (--with-cpu=x86 on 32 bit systems). I suspect that Pavel's crash could be related to using 3DNow(ext). Pavel, what does sh$ mpg123 --test-cpu report for you? And also, what does sh$ mpg123 -v some_file.mp3 2>&1 | grep Decoder show? It naturally just says 'Decoder: i486' here. If you have a multi-cpu build, please test some of the other available cpu opts (mpg123 --cpu generic; mpg123 --cpu mmx, mpg123 --cpu i386, mpg123 --cpu sse; etc). Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#689659: mpg123 segfaults on specific file
Am Mon, 8 Oct 2012 13:39:26 -0400 schrieb Miguel A. Colón Vélez : > What I did notice was that the original user logs suggest that they > are using "Version 0.59o (1998/Feb/08)." of mpg123. My logs show > version 1.14.4 and that it worked with 1.14.4. Holy macaroni! I totally overlooked that: Version 0.59o (1998/Feb/08). Written and copyrights by Michael Hipp. I focused on the version info provided in the other parts of the report. Now where does that ancient version come from? It for sure has its share of bugs that have been fixed in the intervening nearly 15 years! Er ... great if mpg123 0.89o worked fine for you all that time;-) But really, what does this version do on a wheezy system? Miguel: What remains is my question about only i486 being built-in currently, is that intentional? Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#689659: mpg123 segfaults on specific file
Am Mon, 8 Oct 2012 15:30:48 -0400 schrieb Miguel A. Colón Vélez : > The Debian i386 architecture is supposed to support all i486 and > later. The current package of mpg123 gets compiled with > "--with-cpu=x86_dither" This doesn't seem to be in effect here. First: Yes, --with-cpu=x86 superseedes --with-cpu=x86_dither (dithered decoders are included). And: If I do a build --with-cpu=x86 in the i386 wheezy VM, I get the following list of decoders: sh$ src/mpg123 --list-cpu Builtin decoders: SSE 3DNowExt 3DNow MMX i586 i586_dither i386 generic generic_dither The stock binary says this: sh$ mpg123 --list-cpu Builtin decoders: i486 This happens either when building --with-cpu=i486 or when not specifying anything (--with-cpu=) and setting host to i486-*. Unfortunately, the i486 code is a hack that has not been merged with the other optimizations. Since generic and i386 code will run just fine on i486 CPUs, I recommend enforcing --with-cpu=x86 on ia32 platform. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Regressions in mpg123 since 1.14.0 (please update stable and testing to 1.18.0)
Hi, I'm the mpg123 upstream maintainer and just pushed out a release to fix some regressions introduced in the 1.14.x series. Among those is a buffer overflow that I naturally would like to see gone also for stable debian. I strongly suggest updating to 1.18.0 to fix the regressions. Providing a single patch to fix older versions is not trivial, so I hope it is fine with debian to push a version number also in stable. Version 1.18.0 introduces no incompatibilities with applications using 1.14.0 or beyond, so the upgrade should be painless. Of course I trust you to do your share of testing and verification anyway;-) Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Switch to use generic_fpu for ARM
Sorry for being late to the party, but I have to say that this is a rather unfortunate situation now. Not using the assembly-optimized fixed-point ARM code of the arm_nofpu decoder and resorting to the generic_fpu one (all plain C) will make mpg123 really slow in comparison. I'm not sure what hardware we are targeting here ... is it armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine, although using the neon decoder is still preferred on supporting CPUs. There is no runtime detection in mpg123 for this and at least for the decision of fixed or floating point decoding, it likely will never be as that is a very basic decision on the whole decoder code, not just some optimization. I can imagine combining generic_fpu and neon builds with run-time detection, but this still assumes a hardware floating point unit to make sense. We have arm_nofpu and generic_nofpu for the cases without one. Something which is possible right now is to produce one libmpg123.so with the standard build to please users using slow ARM machines who just want plain 16 bit playback and produce one libmpg123_float.so for people using beefy machines and who are using audacious as a media player. Well ... the least would be to offer builds with usage of vfp if present (I see hints https://wiki.debian.org/ArmPorts that that's an option, including runtime linker choice). In any case, ARM's a real mess in that respect. Very hard to produce a build that is optimal for that wide range of configurations that debian tries to support. I could implement a conversion step to floating point with the arm_nofpu decoder. That would make audacious work (although wasting precision on machines that have hardware floating point, or even NEON) and have the benefit of the command-line mpg123 still being fast with 16 bit output. A debian build targeting modern floating-point-capable hardware would use generic_fpu or better the neon decoder to begin with. Is there preference to have the faster decoder for debian without floating point hardware? signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Switch to use generic_fpu for ARM
Am Sun, 16 Feb 2014 12:14:46 -0500 schrieb Reinhard Tartler : > Thomas, in libavcodec, we "solve" (or rather, workaround, depending on > the PoV) this problem by compiling the libraries multiple times A sane approach. Runtime code selection in each application can be stretched beyond the boundary of it being fun quickly. > ... > be possible to do something like this for mpg123 as well? This would > then require to compile > > /usr/lib/arm-linux-gnueabi/libmpg123.so.0 > for different flavors. However, we would need to make sure that > /usr/bin/mpg123 works with any of them. That would certainly work and is what I imagined. If this offers link-time choice of fixed point, vfp or neon, I'd be overly happy for avoiding headache over making runtime choice inside one build (which seems rather impractical). > I'm wondering if this pattern > wouldn't work for mpg123, but I'm not familiar enough with the > codebase to say if this would work. Can you please comment? I don't see am obvious problem. As long as basic ABI fits (also regarding floating point args), this should work as well as libavcodec. The mpg123 binary queries the library for things like format support and decoder engine and one build can work with arm_nofpu or generic_nofpu (arm-linux-gnueabi), generic_fpu (arm-linux-gnueabi/vfp) and arm_neon (arm-linux-gnueabi/neon/vfp/). I suppose the gnueabihf variants need an separate build for the changed ABI of floating point arguments (?). When setting up the environment to use a specific libmpg123, one should see an effect in the output of mpg123 --list-cpu Just build mpg123 several times, with proper CFLAGS for -march and friends and matching --with-cpu for configure. You can pick which mpg123 binary to use, I suggest the most universal one. In the mpg123 binary itself, there is no assembly code affected by the --with-cpu switch and the performance-relevant bits are in libmpg123. Same for the other helper applications (mpg123-id3dump, mpg123-strip). The only issue still present would be that the most basic libmpg123 still misses floating point output format for audacious. But my guess is that you wouldn't use that player on a system without floating point hardware. As I said, I can change that, for the sake of completeness adding a bit of code converting from 16 bit to 32 bit float (and 24 and 32 bit integer) in the output buffer. The only remaining difference between the libraries would be performance and accuracy of output. Were you aware of the --enable-int-quality flag to configure? Yet another set of decoders being a bit slower but doing better rounding to 16 bit integers;-) In any case, you might want to check out mpg123's tests to verify that your various builds decode properly: svn co svn://svn.orgis.org/mpg123/test mpg123-test cd mpg123-test make # build helper programs (rms computation) perl compliance.pl /path/to/mpg123 This makes a basic MPEG ISO compliance test, comparing decoder to reference output (see http://mpg123.org, after scrolling down a bit). Disclaimer: If anything does not work as I just promised, this is a bug and will be addressed;-) Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Mon, 17 Feb 2014 10:00:48 +0200 schrieb Riku Voipio : > Thanks Peter for explaining, this was how I ended up the suggestion > in the bug. > > > I see. In that case, I'll have to leave the package as it until > > something along those lines is implemented. > > Yes. The ideal solution is for the upstream to implement cpu runtime > detection that: > > 1) uses neon if it is available > 2) falls back to fixed point if app requested 16-bit playback > 3) finally falls back to generic fpu code if neither of above applies > > Any packaging level workaround is going to be suboptimal for someone. Isn't the approach for the linker to select libraries like libavcodec on the table anymore? I see that I'll have to add that float conversion code to keep the features along all builds, but selecting a vfp and non-vfp variant for fixed point or floating point via the linker seems like the most clean approach you are going to get. NEON detection may come... but if we have linker selection, that would be covered right now. So ... can I get away with adding that stupid float conversion, so folks have reasonable performance in likely applications of debian on ARM, please? ;-) Alrighty then, Thomas PS: I'll have to remove those "experimental" markings from the nofpu variants in configure help. They are getting old. signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
> >> > I see. In that case, I'll have to leave the package as it until > >> > something along those lines is implemented. So, I got conversion to float implemented now and tested with the generic_nofpu decoder on x86-64. It _should_ of course work with ARM, too;-) If you'd like to check the current snapshot of mpg123, http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 , you hopefull will find that any normal build of mpg123 (unless specifying --disable-float explicitly) now offers all usual formats. As a bonus, I even implemented the 8 Bit A-Law output, which has always just been a placeholder (nobody missed it, apparently). I'd be interested on some timings of mpg123 -t -e s16 test.mp3 mpg123 -t -e f32 test.mp3 with the various builds you'll do for the ARM variants. Best would be running perl scripts/benchmark-cpu.pl src/mpg123 convergence_-_points_of_view/*.mp3 with http://mpg123.orgis.org/convergence_-_points_of_view.tar.gz as reference album, as mentioned on http://mpg123.orgis.org/benchmarking.shtml to be able to compare the performance of the code and machine to others. This yields output like this: #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s x86-64 3.394.05 generic 6.156.01 generic_dither 6.365.97 ... or this, with --with-cpu=generic_fpu: #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s generic 6.146.29 (on a Core2Duo machine). > Yes, you can do that - build several copies of the library and use the > hwcaps / auxv approach to pick the best one for the hardware at link > time. > > >NEON detection may come... but if we have linker selection, that would > >be covered right now. > > Yup. Seconding the second part: Linker selection it is. NEON runtime detection just isn't fun in user code. The bright side: If the multiple builds are setup and tested, I can safely release mpg123-1.19.0 with the changes and we finally have this settled. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
ED) maxdiff=4.619360e-05 (PASS) fl7.bit:RMS=7.469690e-06 (PASS) maxdiff=2.658367e-05 (PASS) fl8.bit:RMS=7.923985e-06 (PASS) maxdiff=2.604723e-05 (PASS) Layer 2 --> 16 bit signed integer output fl10.bit: RMS=7.983482e-06 (PASS) maxdiff=2.837181e-05 (PASS) fl11.bit: RMS=7.971939e-06 (PASS) maxdiff=3.039837e-05 (PASS) fl12.bit: RMS=7.947400e-06 (PASS) maxdiff=2.884865e-05 (PASS) fl13.bit: RMS=7.871138e-06 (PASS) maxdiff=2.616644e-05 (PASS) fl14.bit: RMS=1.845901e-05 (LIMITED) maxdiff=6.735325e-05 (FAIL) fl15.bit: RMS=9.506695e-06 (LIMITED) maxdiff=3.713369e-05 (PASS) fl16.bit: RMS=8.529689e-06 (PASS) maxdiff=4.535913e-05 (PASS) --> 32 bit integer output fl10.bit: RMS=7.983482e-06 (PASS) maxdiff=2.837181e-05 (PASS) fl11.bit: RMS=7.971939e-06 (PASS) maxdiff=3.039837e-05 (PASS) fl12.bit: RMS=7.947400e-06 (PASS) maxdiff=2.884865e-05 (PASS) fl13.bit: RMS=7.871138e-06 (PASS) maxdiff=2.616644e-05 (PASS) fl14.bit: RMS=1.845901e-05 (LIMITED) maxdiff=6.735325e-05 (FAIL) fl15.bit: RMS=9.506695e-06 (LIMITED) maxdiff=3.713369e-05 (PASS) fl16.bit: RMS=8.529689e-06 (PASS) maxdiff=4.535913e-05 (PASS) --> 24 bit integer output fl10.bit: RMS=7.983482e-06 (PASS) maxdiff=2.837181e-05 (PASS) fl11.bit: RMS=7.971939e-06 (PASS) maxdiff=3.039837e-05 (PASS) fl12.bit: RMS=7.947400e-06 (PASS) maxdiff=2.884865e-05 (PASS) fl13.bit: RMS=7.871138e-06 (PASS) maxdiff=2.616644e-05 (PASS) fl14.bit: RMS=1.845901e-05 (LIMITED) maxdiff=6.735325e-05 (FAIL) fl15.bit: RMS=9.506695e-06 (LIMITED) maxdiff=3.713369e-05 (PASS) fl16.bit: RMS=8.529689e-06 (PASS) maxdiff=4.535913e-05 (PASS) --> 32 bit floating point output fl10.bit: RMS=7.983482e-06 (PASS) maxdiff=2.837181e-05 (PASS) fl11.bit: RMS=7.971939e-06 (PASS) maxdiff=3.039837e-05 (PASS) fl12.bit: RMS=7.947400e-06 (PASS) maxdiff=2.884865e-05 (PASS) fl13.bit: RMS=7.871138e-06 (PASS) maxdiff=2.616644e-05 (PASS) fl14.bit: RMS=1.845901e-05 (LIMITED) maxdiff=6.735325e-05 (FAIL) fl15.bit: RMS=9.506695e-06 (LIMITED) maxdiff=3.713369e-05 (PASS) fl16.bit: RMS=8.529689e-06 (PASS) maxdiff=4.535913e-05 (PASS) Layer 3 --> 16 bit signed integer output compl.bit: RMS=7.927192e-06 (PASS) maxdiff=2.676249e-05 (PASS) --> 32 bit integer output compl.bit: RMS=7.927192e-06 (PASS) maxdiff=2.676249e-05 (PASS) --> 24 bit integer output compl.bit: RMS=7.927192e-06 (PASS) maxdiff=2.676249e-05 (PASS) --> 32 bit floating point output compl.bit: RMS=7.927192e-06 (PASS) maxdiff=2.676249e-05 (PASS) Thanks for the time you take (also the folks being spammed with this discussion;-). I'm confident we'll get to a bright future with mp3 decoding on debian/ARM soon. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Fri, 21 Feb 2014 11:25:12 -0500 schrieb "Lennart Sorensen" : > Testing with the neon build I get a return code of 4, and it seems to > be failing to run. It was a pain to even get it to compile. Using just > the configure option, the assembler complained about the NEON instructions > being invalid for the chosen cpu type. Adding -mfpu=neon to the CFLAGS > made it able to compile, but it still crashes with illegal instruction. > I tried with CFLAGS set to -mcpu=cortex-a15 -mfpu=neon, and that still > gives illegal instruction when running it. This is weird. What happened in debian side since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667653#35 ? We have the current code working on this setup: device: iPod touch 4G with iOS 5.1.1 toolchain: gcc 4.2.1(from Xcode 3.2.6) on OSX 10.6.8, clang 3.3(from Xcode 5.0.2) on OSX 10.9.1 (double checked) configure script option: --host=armv7-apple-darwin --with-cpu=arm_nofpu[neon] --with-audio=dummy --disable-shared --enable-static [--enable-int-quality] Taihei also just checked the compliance of the decoder choices including NEON. That illegal instruction ... care to fire up the debugger to tell us where it actually occurs? The NEON assembly is written as plain assembler input (cpp + as), you can see the instructions we use right there and it doesn't differ from iOS. > It might be a good idea to have the benchmark script actuall check the > return code of system() Yes. > I was building and testing under Debian armhf sid. > gcc (Debian 4.8.2-16) 4.8.2 > > CPU is a dual Cortex-A15 1.5GHz (TI OMAP 57xx). Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Mon, 24 Feb 2014 12:27:36 -0500
schrieb "Lennart Sorensen" :
> Any help from this:
>
> Program received signal SIGILL, Illegal instruction.
> 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
> 48 vpush {q4-q7}
What the ... ? This does not make sense. I (and actually, with "I", I
mean Taihei who knows more about ARM assembly;-). The vpush pseudo
instruction should be harmless in our context. Quote from Taihei:
I don't know why. Actually vpush is a pseudo instruction, and
vpush {q4-q7} should be assembled into vstmdb sp!, {d8-d15}
(machine code is ed2d8b10). I'm curious how their assembler
(gnu as?) assembles into.
Well ... what does
sh$ objdump -S src/libmpg132/.libs/dct64_neon.o
say? Any hint from the debian ARM folks with experience about funny
behaviour for stand-alone assembly files? I also wonder if this is
generally broken on debian (since certain toolchain version) or on
certain CPUs only. I repeat: This code worked before:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667653#35
Alrighty then,
Thomas
signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Tue, 25 Feb 2014 17:37:41 +0900
schrieb Taihei Momma :
> #0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
> ^
> not a multiple of 4.
Oh, d'oh! It could be that simple.
> I've just committed a fix to mpg123 repository
I generated a new snapshot,
http://mpg123.org/snapshot/mpg123-20140225111416.tar.bz2 ,
and also attached the patch for the rather small change that hopefully
has a big effect. Care to test this?
Alrighty then,
Thomas
--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOrganisation ---)=- http://orgis.org
GPG public key D446D524: http://thomas.orgis.org/public_key
Fingerprint: 7236 3885 A742 B736 E0C8 9721 9B4C 52BC D446 D524
Index: src/libmpg123/dct64_neon_float.S
===
--- src/libmpg123/dct64_neon_float.S (Revision 3514)
+++ src/libmpg123/dct64_neon_float.S (Revision 3515)
@@ -44,6 +44,7 @@
.word 1060439283
.word 1060439283
.globl ASM_NAME(dct64_real_neon)
+ ALIGN4
ASM_NAME(dct64_real_neon):
vpush {q4-q7}
Index: src/libmpg123/dct64_neon.S
===
--- src/libmpg123/dct64_neon.S (Revision 3514)
+++ src/libmpg123/dct64_neon.S (Revision 3515)
@@ -44,6 +44,7 @@
.word 1060439283
.word 1060439283
.globl ASM_NAME(dct64_neon)
+ ALIGN4
ASM_NAME(dct64_neon):
vpush {q4-q7}
signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Tue, 25 Feb 2014 11:20:06 -0500
schrieb "Lennart Sorensen" :
> On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote:
> > Am Tue, 25 Feb 2014 17:37:41 +0900
> > schrieb Taihei Momma :
> >
> > > #0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
> > > ^
> > > not a multiple of 4.
> > Index: src/libmpg123/dct64_neon.S
> > ===
> > --- src/libmpg123/dct64_neon.S (Revision 3514)
> > +++ src/libmpg123/dct64_neon.S (Revision 3515)
> > @@ -44,6 +44,7 @@
> > .word 1060439283
> > .word 1060439283
> > .globl ASM_NAME(dct64_neon)
> > + ALIGN4
> > ASM_NAME(dct64_neon):
> > vpush {q4-q7}
> >
Now ...
> Program received signal SIGILL, Illegal instruction.
> 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:49
> 49 vpush {q4-q7}
That address didn't change. I suggest we better align the function
symbol itself, seems like we accidentally missed by one line:
ALIGN4
.globl ASM_NAME(dct64_neon)
ASM_NAME(dct64_neon):
looks better to me (at least that's how we did it for all other
functions;-). Care to test the current
http://mpg123.org/snapshot/mpg123-20140225173909.tar.bz2 ?
Sorry for the inconvenience, but I don't have a setup handy to test
this myself.
Alrighty then,
Thomas
signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma : > OK, after some investigation with armhf cross environment and qemu, finally > the current mpg123 svn (r3517) should work (including arm_nofpu decoder). > > The point is .type directive. Without this directive, a linker doesn't > distinguish arm functions from thumb functions, and interworking doesn't work > properly. > Great! So, folks, please check that http://mpg123.de/snapshot/mpg123-2014030100.tar.bz2 does the trick with all decoders now. Performance numbers from the benchmark script would be nice. I'll release 1.18.1 after confirmation and we finally can settle this. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Sat, 1 Mar 2014 09:56:46 +0100 schrieb Thomas Orgis : > Great! So, folks, please check that > > http://mpg123.de/snapshot/mpg123-2014030100.tar.bz2 > > does the trick with all decoders now. Performance numbers from the > benchmark script would be nice. I'll release 1.18.1 after confirmation Sorry, I meant 1.18.2, of course. Also, I fixed the benchmark script to check the return value with http://mpg123.de/snapshot/mpg123-20140301101020.tar.bz2 just in case things are still broken. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma : > OK, after some investigation with armhf cross environment and qemu, finally > the current mpg123 svn (r3517) should work After Tahei didn't stop at this (big thanks from here!), we got a new snapshot, http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 , that will hopefully become mpg123 1.19.0 soon (not 1.18.x because of feature additions regarding this very debian issue). The main points: - float output with all decoders (also arm_nofpu) - ARM decoders (esp. NEON) working with debian toolchain - new --with-cpu=arm_fpu choice with runtime detection to switch between NEON or normal FPU So, the number of builds for optimal treatment of differing platforms reduces to two: 1. --with-cpu=arm_nofpu 2. --with-cpu=arm_fpu I hope we can all be happy about that. I'd also be glad to get some confirmation from debian that it really works now. Release will be imminent, then. Thanks for staying with us with all the chattering about this ... Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
nt decoder is not that far behind in speed (compared to softfloat) and offers proper floating point accuracy as bonus. Generally, it is a safe bet that any normal person is quite happy with 16 bit accuracy for decoded MP3s. Depending on the initial quality of the encoding, this might be everything that is sensible anyway (and its a challence to hear any difference to 24 bit on an arbitrarily expensive HiFi system). There are people preferring their 16 bit output rounded using dithering, which mpg123 also offers (--with-cpu=generic_dither), but which excludes optimizations for ARM. We are talking about the default setup for the majority of debian users here. Any quality choice should be fine for that, after all, we're talking compliant MPEG quality in any case (sometimes 'limited precision', but still). Audiophiles wanting the utmost quality from their setup (as funny as that is to many audiophiles when starting from a lossy compression;-) will love to tweak things anyway. They can always do their own build, or use an additional repository (thinking ubuntu PPAs for various such purposes) that provides a different taste. The quality difference between 1 h or 10 h time on battery while playing music is very much noticable to anyone, so the choice on armel should be settled. On armhf, there are cases where the arm_nofpu would be a better choice (decoding to 16 bit without NEON), but about 50 % CPU demand increase is less dramatic and it evens out when using floating point output. In any case ... Riku: Care to run timings of MAD on your configurations? I'm interested in how fast it is producing that 24 bit output on limited CPUs. > Lennart Sorensen wrote: > > I think so. armhf's current debian rules automatically picked arm_fpu > IMO it's often better to be explicit about this sort of thing. I agree. Never trust upstream's defaults in such sensitive matters;-) Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Tue, 4 Mar 2014 11:49:45 +0100 schrieb Thomas Orgis : > sh$ time -d -o null convergence_-_points_of_view/*.mp3 That should be sh$ time madplay -d -o null: convergence_-_points_of_view/*.mp3 ... as you may have guessed (notice the added ":"). Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Tue, 4 Mar 2014 11:10:25 -0300 schrieb Felipe Sateler : > #decodert_s16/s t_f32/s > ARM 86.26 90.66 > generic 102.80 100.06 > generic_dither 121.10 100.84 Yes, a difference, but aguably a lot less than comparing VPU code to NEON. With the feature to produce float output from all decoders, it is your (debian's) option to prefer decoding speed by building a libmpg123 with arm_nofpu and use it on armhf machines without NEON via the library loading mechanism. Or you decide for offering "proper" floating point output that needs some 25-50 % more CPU time. I am even more interested in a comparison with the runtime of madplay in that configuration. Perhaps its fixed-point math with 24 bit output is still faster than using the VFP with mpg123. Of course, I'd be interested to know if that's not the case (mpg123 rulez!;-). But if it is, it wouldn't totally surprise me. Alrighty then, Thomas PS: You still have to decide for --enable-int-quality or not, for a smaller impact on CPU time and basically one bit of precision. signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Tue, 4 Mar 2014 16:25:17 -0300 schrieb Felipe Sateler : > >> #decodert_s16/s t_f32/s > >> ARM 86.26 90.66 > >> generic 102.80 100.06 > >> generic_dither 121.10 100.84 > madplay -d -o null: convergence_-_points_of_view/*.mp3 &> /dev/null > 130.22s user 1.88s system 93% cpu 2:21.91 total Interesting. So the VFP is not that bad: You get superior output (not noticeably, but measurable in the digital domain) from mpg123's generic decoder in about 75 % of the decoding time. The lower-quality 16 bit integer decoder of mpg123 is considerably faster. So, on a armel system without VFP, it makes sense to employ libmad to achieve 24 bit accuracy with reasonable CPU cost, if you insist on that accuracy. But with VFP, using mpg123 gives you full 32 bit floating point output with less CPU load. For NEON, it's not even a question. I think I can live with that situation;-) both MAD and mpg123 achieve their goals. MAD gets the best precision out of integer math, mpg123 offers something faster everywhere, possibly with less, but also possibly with more (irrelevant, 24 bit is _really_ enough) precision. One might also benchmark a decoder based on ffmpeg, which has both fixed-point and floating-point decoders, but I don't have a good command line for that at hand (used mplayer -ac mpg123 and mplayer -ac ffmp3[float] in the past). Anyhow, leaving scope here. I should get going and release mpg123 1.19.0 . > This is the madplay straight from raspbian, not sure if some other > configure flag was to be tested. Optimizing for speed vs. quality might be an option ... but that's somehow missing the point of preferring libmad. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#749390: handbrake 0.9.9 backport depends on wrong version of libdvdread4
Package: handbrake Version: 0.9.9+dfsg-2~2.gbpa4c3e9~bpo70+1 handbrake 0.9.9 in wheezy-backports has a dependency: Breaks: libdvdread4 (<4.2.0+20120512-3) But the latest version of libdvdread4 in wheezy is 4.2.0+20120521-2. The -3 version does not exist. So handbrake can not be installed. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#751800: mpg123: i486 decoder broken
Am Mon, 16 Jun 2014 11:43:28 -0700 schrieb Simon Kirby : > (when does this happen?), configure is passed --with-cpu=x86_dither, > which avoids the problem, but which is documents (in NEWS) as being for > i586 and above. The _dither part used to be for i586, but there is also a plain C variant in there now. The x86_dither is recommened for any i386-compatible CPU. It activates assembly optimizations for i586, MMX, SSE etc. at runtime. All i386-based decoders are merged in there --- except i486, which is indeed a special beast. > (though this should eventually be fixed upstream) ... yeah, I'll have to investigate that. Though, the i486 decoder has mostly historical value ... or just vor bragging rights to get fast decoding on a vintage i486 CPU. Alrighty then, Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701114: easytag: Please update to 2.1.8
Package: easytag Version: 2.1.8-1 Severity: wishlist easytag 2.1.8 is out now, and offers many useful improvements and fixes. I've been running a pre-release version for some months because I needed some fixes, and it's been fine, plus straightforward to build. The 2.1.8 release itself removes the Debian packaging, so I can't install it as easily as I did the pre-release, so it would be even nicer therefore if the Debian package were updated! -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-23-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages easytag depends on: ii libc6 2.15-0ubuntu20 ii libflac81.2.1-6build1 ii libgdk-pixbuf2.0-0 2.26.4-0ubuntu1 ii libglib2.0-02.34.1-1ubuntu1 ii libgtk2.0-0 2.24.13-0ubuntu2 ii libid3-3.8.3c2a 3.8.3-15 ii libid3tag0 0.15.1b-10build3 ii libogg0 1.3.0-4 ii libpango1.0-0 1.30.1-0ubuntu3 ii libspeex1 1.2~rc1-6 ii libstdc++6 4.7.2-2ubuntu1 ii libtagc01.8-0ubuntu2 ii libvorbis0a 1.3.2-1.3 ii libvorbisfile3 1.3.2-1.3 ii libwavpack1 4.60.1-3 easytag recommends no packages. easytag suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar M:Jarod Wilson M:Scott Davilla M:Manu Abraham seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it "hotfixed" and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 18:36, Andres Mejia wrote: It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. Top posting on list and removal announce without valid bug report for Your claimed issue and any confirmation? Driver does not behave different from linux 3.2...3.7.1 here, see my posts on the linux-media list, xbmc people? y tom On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp wrote: On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar M:Jarod Wilson M:Scott Davilla M:Manu Abraham seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it "hotfixed" and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 18:36, Andres Mejia wrote: It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. Driver is maintainable and supported up to at least Linux 3.8 series, when we'll have 4.0 in debian stable, 2015? schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ make clean rm -f *.map *.list *.o *.ko crystalhd.mod.c crystalhd_lnx.o crystalhd_misc.o crystalhd_cmds.o crystalhd_hw.o crystalhd_linkfuncs.o crystalhd_fleafuncs.o crystalhd_flea_ddr.o schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ make make -C /lib/modules/3.8.1/build SUBDIRS=/mnt/data/usr/local/src/crystalhd/driver/linux modules make[1]: Entering directory `/mnt/data/usr/local/src/linux-laststable' CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_lnx.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_misc.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_cmds.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_hw.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_linkfuncs.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_fleafuncs.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_flea_ddr.o LD [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.o Building modules, stage 2. MODPOST 1 modules CC /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.mod.o LD [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.ko make[1]: Leaving directory `/mnt/data/usr/local/src/linux-laststable' schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ Builds without warnings with my patches. schorpp@tom3:~$ uname -a Linux tom3 3.8.1 #12 SMP PREEMPT Fri Mar 1 20:41:00 CET 2013 x86_64 GNU/Linux schorpp@tom3:~$ hellobcm starting up Running DIL (3.22.0) Version DtsDeviceOpen: Opening HW in mode 0 Clock set to 180 Setting Color Mode to 1 try calls done Unable to open input file DtsAllocIoctlData Error schorpp@tom3:~$ dmesg |grep crystal [6.426460] Loading crystalhd v3.10.1 [6.426515] crystalhd :03:00.0: Starting Device:0x1612 [6.429600] crystalhd :03:00.0: irq 51 for MSI/MSI-X [ 99.896730] crystalhd :03:00.0: Opening new user[0] handle [ 102.604770] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 243.648468] crystalhd :03:00.0: Opening new user[0] handle [ 246.325373] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 334.105537] crystalhd :03:00.0: Opening new user[0] handle [ 336.776957] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 510.322855] crystalhd :03:00.0: Opening new user[0] handle [ 510.577299] crystalhd :03:00.0: Closing user[0] handle with mode [ 510.781740] crystalhd :03:00.0: Opening new user[0] handle [ 511.036308] crystalhd :03:00.0: Closing user[0] handle with mode [ 511.240825] crystalhd :03:00.0: Opening new user[0] handle [ 513.801093] crystalhd :03:00.0: [FMT CH] PIB:0 ff 420 6 2d0 162 2d0 0 0 0 [ 513.921604] crystalhd :03:00.0: MISSING 3 PICTURES [ 514.587208] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 535.989772] crystalhd :03:00.0: Opening new user[0] handle [ 536.244314] crystalhd :03:00.0: Closing user[0] handle with mode [ 536.448772] crystalhd :03:00.0: Opening new user[0] handle [ 536.703282] crystalhd :03:00.0: Closing user[0] handle with mode [ 536.907816] crystalhd :03:00.0: Opening new user[0] handle [ 539.435257] crystalhd :03:00.0: [FMT CH] PIB:0 ff 420 6 2d0 162 2d0 0 0 0 [ 539.508317] crystalhd :03:00.0: MISSING 3 PICTURES [ 616.455975] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 schorpp@tom3:~$ Loads and runs with Totem and MPlayer. root@tom3:~# lspci -vvv -s 03:00.0 |grep Sta Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR+ http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 21:55, Julien Cristau wrote: On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Well, then drop all the other non-"mainline" drivers dkms packages, too. This is getting unserious, I wish You all much fun with more root holes in closed source vdpau GPU drivers. Thanks to Broadcom for the nice effort. Bye, tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#697144: dir2ogg: Broken sound speed of converted files
TLDR: Please check with current mpg123 snapshot and think about either prescribing format and letting mpg123 write really raw data or make proper use of the improper WAV header. Hello, mpg123 upstream here. I really did not intend to break dir2ogg in various ways. I totally regret touching WAV writing code at all. While I think that it is a bit bold to pipe something like WAV to stdout and expect it to work (many programs really are not happy with the inconsistent headers that this produces, take audacity or even just libsndfile), there are some that could make use of this. Among those are oggenc and lame, for that matter. I do wonder why you have opts=['-r', '-R', str(mutagen.File(self.song).info.sample_rate)] for mpg123 output in dir2ogg. Is this already an attempt to fix broken WAV output by mpg123? If not, I really have to wonder why you do not just use mpg123 -s input.mp3 | ogggenc -r -R $rate -C $channels -B 16 -o output.ogg or rather mpg123 -e s24 -s input.mp3 | ogggenc -r -R $rate -C $channels -B 24 -o output.ogg for avoiding extra quality impact from rounding to 16 bit in between (sadly, oggenc does not seem to support float, which would avoid integer intermediate altogether). Note $channels ... current dir2ogg will screw up if the input is a mono file. It assumes stereo. Thing is, you tell mpg123 to write WAV headers and then tell oggenc to ignore them via -r. That confuses me. If you want raw data, tell mpg123 to deliver raw data to stdout via the -s switch. But, once we got through this mess with the repeatedly messed up WAV-to-stdout (which I always recommend to use with caution only ...), for example using current http://mpg123.org/snapshot, which shall become mpg123 1.16.0, you can just do that: src/mpg123 -w - -e s24 input.mp3 | oggenc -o output.ogg - and have it magically work. Note that the '-e s24' might not be available on certain builds of mpg123. If it is supported, it appears in mpg123 --longhelp in this line: -e --encoding force a specific encoding (s16 u16 u8 s8 ulaw alaw f32 s32 u32 s24 u24) I might add a specific switch to ask about that (mpg123 --list-encodings or such) to 1.16.0, if it's desired. To support all versions of mpg123, you can extend your hack that inserts the sample rate via mutagen and have it provide the full format (including channel count) and just pipe the raw data from mpg123 via -s. The option for s24 format would just reduce the quality loss a bit ... if you care about that when converting between lossy formats;-) Using the WAV output of a minimally required mpg123 >= 1.16.0 would avoid the question of checking which output format is available. People can make different builds of mpg123 that have different (default) sample format (floating point, for example). It's interesting that oggenc and lame are the only tools I found with some quick tests that are happy with the kind of broken WAV you get via pipes. But then, if you intend to store such files, you'd better write them properly. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: updating OpenNI Debian packages
On Wed, May 22, 2013 at 5:03 AM, Hans-Christoph Steiner wrote: > On 05/20/2013 03:18 PM, Jochen Sprickerhof wrote: > I just updated primesense-nite-nonfree to the latest version and updated the > packaging. I'm out of time on this sprint. It would be great if people > could test it and then also contribute any relevant things from the [1] > above repo to it. Its part of pkg-multimedia, so y'all should have commit > access to it. > > http://git.debian.org/?p=pkg-multimedia/primesense-nite-nonfree.git Dear Hans-Christoph, it just occurred to me than primesense-nite-nonfree is depending on libopenni-dev [1] "Depends: debconf | debconf-2.0, dpkg-dev, devscripts, wget, unzip, gnupg, libopenni-dev, openni-utils" Should someone upload openni too? Is the package ready for inclusion? [1] http://ftp-master.debian.org/new/primesense-nite-nonfree_0.1.html Best, -- Thomas Moulard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Well, those look fine to me: checking for size_t... yes checking for uintptr_t... yes checking for ssize_t... yes checking for off_t... yes checking for int32_t... yes checking for uint32_t... yes checking for int16_t... yes checking for uint16_t... yes checking size of size_t... 4 checking size of ssize_t... 4 checking size of off_t... 8 checking size of int32_t... 4 checking size of long... 4 The whole point of large file support is to have off_t with 64 bit on a 32 bit platform. But the lines before these explain some confusion: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no _FILE_OFFSET_BITS is not set for mpg123 build. The normal build should use 64 bit offsets, but the macro code renaming things to _64 suffix is not active during mpg123 build, as it depends on that variable. Now, MPlayer, and also mplayer2 build does that cc [...] -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE [...] -c -o libmpcodecs/ad_mpg123.o libmpcodecs/ad_mpg123.c That is the reason why I added the LFS alias functions. This practice of enforcing the offset bits also on a 64 bit box prompted the need to always provide _64 functions even if this is the natic off_t without large file support hackery. The issue at hand is that the AC_SYS_LARGEFILE macro mpg123 uses for configuring figures that it does not need _FILE_OFFSET_BITS. To sum it up, here is a quote from configure.ac: dnl Detect large file support, enable switches if needed. AC_SYS_LARGEFILE dnl If we do have a switch for large files, rename off_t-aware API calls. dnl Using the file_offset_bits variable here is fine for linux (possibly Solaris), dnl Others... we'll have to see. I guess kfreebsd counts as "others". One could just use the diagnostic of the size of off_t and whether it differs from long int ... short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to be needed on kfreebsd. Could someone who works on that one confirm that it always defaults to 64 bit off_t? Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Am Thu, 22 Aug 2013 07:46:55 +0200 schrieb Reinhard Tartler : > That would then make mpg123 export the _64 variants in the library. Is > this the correct behavior, even on systems that do have a 64bit off_t > such as kfreebsd-i386? Your answer seems a bit inconclusive here to me. > > Wouldn't it make sense for mpg123 always export these symbols, even when > they are "only" simple aliases on those archs? Yes, as mpg123 does that successfully on platforms I worked on so far. There are usually 3 parts of the large-file-aware API: 1. without suffix for native setting (32 bit off_t on systems that need _FILE_OFFSET_BITS=64 for 64 bit), possibly wrappers to call the _64 functions 2. with _64 for enabled large-file support (actual function or an alias to native 64 bit) 3. with _32 for those who set _LARGE_FILE_BITS=32, alias to native without suffix You see, this is a royal mess and hopefully agree with me that defining off_t with varying sizes on the same platform as build-time choice is madness. That's why very few libraries even try to handle that correctly. Any of these function names can be an alias, wrapper or actual libmpg123 function. Well, this mess is for me to care for as maintainer. Users are only interested in the symbols with _32 and _64 being present. > > short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef > > in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to > > be needed on kfreebsd. > > I was considering doing that, but I wonder if that was fix, or a workaround? Well, depends on you considering that unconditional definition of _FILE_OFFSET_BITS in MPlayer builds the proper thing to do;-) Depending on the nature of debian/kfreebsd, making the mpg123 header ignore _FILE_OFFSET_BITS might be a better idea. > > Could someone who works on that one confirm that it always defaults to > > 64 bit off_t? > > I'm not sure if I understand the question, what does "it" refer to? > kfreebsd-i386, mplayer2 or mpg123? The platform kfreebsd-i386. My question is how the large file issue is handled there. The mpg123 build log suggests to me that large file support (64 bit off_t) is the one and only configuration (which would be a good thing, in itself). Is that correct? Since people use mpg123 on "actual" *BSD systems since quite some time now, I suppose that debian/kfreebsd differs from them in that respect, as it does with respect to Linux. The long-term fix would make the mpg123 build aware of that and trigger generation of _64 functions as direct api calls, without suffix as alias to those and _32 wrapper functions that map long int offsets to the 64 bit ones. I cannot promise a time scale to work on that myself, due to RL pressure. One needs to modify configure.ac to check the size of off_t in case of empty _FILE_OFFSET_BITS setting from AC_SYS_LARGEFILE and trigger generation of _64 functions (or, rather _(8*sizeof(off_t) functions) if sizeof(off_t) != sizeof(long). This should only cover modification of configure.ac src/libmpg123/lfs_wrap.c src/libmpg123/lfs_alias.c src/libmpg123/mpg123.h.in to handle an extra macro besides _FILE_OFFSET_BITS to decide for suffix for primary API. It would not be right to just force _FILE_OFFSET_BITS=64 in configure.ac for that case, as this will cause _32 functions mapping 32 bit long int arguments to off_t, which is always 64 bit. And actually, this is the exact problem you already have with the current configure.ac ... only without the benefit of having _64 functions. You need to separate two use cases of mpg123.h: Sorting out the symbols of the libmpg123 build and mapping to the right ones when building a client application. Yeah, I'm convinced now: The mpg123 build is broken right now on this platform, as long as any user decides to define _FILE_OFFSET_BITS. The result will either be unresolved symbols (=64) or undefined behaviour (=32 ... handing 32 bit values into 64 bit arguments). Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Am Tue, 27 Aug 2013 23:49:08 +0200 schrieb Reinhard Tartler : > +if test > ".$ac_cv_sizeof_int32_t$ac_cv_sys_file_offset_bits$ac_cv_sizeof_off_t" > = ".4no8"; then > + # Add dual-mode wrapper code.anyways > + LFS_LOBJ=lfs_wrap.lo > + ac_cv_sys_wide_off_t="yes" > + AC_DEFINE(LARGEFILE_WIDE64_OFF_T, 1, > + [whether the system is 32bit, but has 64bit off_t]) > +fi If you detected that situation (the generalist in me would like to see this without hardcoding 4 and 8 ... and wonders how sizeof(int32_t) != 4 is possible), I wonder if just defining _FILE_OFFSET_BITS=64 after adding lfs_wrap.lo wouldn't do the trick. The wrapper macros only look at that value to define the function names, unless hacked to watch out for others. I strongly suppose that's where you get multiple definitions from. What I only would like to know is if there is some drawback to simply defining _FILE_OFFSET_BITS=64. I suppose not. But let me try to get my own logic straight again. With _FILE_OFFSET_BITS=64, mpg123 build will create _64 functions. You want aliases without suffix, because of native 64 bit off_t, you want wrappers with _32 suffix for long arguments. Current lfs_wrap.c is hardcoded to [no suffix]->_64 with long arguments on [no suffix]. That is still correct... lfs_alias should work, too, providing ... just another alias without suffix. Conflicting. Yeah, you have to untangle that: lfs_wrap needs to define functions with _32 suffix, mapping to _64. The lfs_alias should work unchanged (once _FILE_OFFSET_BITS is there) to provide [no_suffix] -> _64. So, in lfs_wrap.c: #undef mpg123_tell /* off_t mpg123_tell(mpg123_handle *mh); */ long attribute_align_arg mpg123_tell(mpg123_handle *mh) Needs to become #undef mpg123_tell /* off_t mpg123_tell(mpg123_handle *mh); */ long attribute_align_arg mpg123_tell_32(mpg123_handle *mh) in your case. Of course, it's nice when we get to this with macro automatism, but you could also simply try one brute force patch to verify that this results in a correct build. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Am Wed, 28 Aug 2013 01:33:08 +0200 schrieb Thomas Orgis : > But let me try to get my own logic straight again. Damn, I shouldn't write such stuff late at night, the brain torn between wildly differing problems and the urge to fall into hibernation. > Current lfs_wrap.c is hardcoded to [no suffix]->_64 with long arguments > on [no suffix]. That is still correct... That is not correct. The mpg123 header specifies off_t as argument. When off_t is always 64 bits (could you possibly set _FILE_OFFSET_BITS=32 ?!), there is no justification for _32 functions at all! So, you only want lfs_alias for [no suffix] -> _64. You dont't want lfs_wrap. That eases the problem, actually. Just make sure _not_ to include lfs_wrap and define _FILE_OFFSET_BITS=64 in configure for lfs_alias. That should just work ... Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
(I'm also CCing the FreeBSD port maintainer, as I imagine they want that
handled, too.)
Am Sat, 31 Aug 2013 10:03:46 +0200
schrieb Reinhard Tartler :
> Thomas, may I have your opinion on this patch? If you are d'accord,
> I'd upload it to debian/unstable for further testing.
OK, I see that I need to see more clear. The aliases need to be named
_64 and also need to use the correct type for offsets. I didn't design
lfs_alias.c to be so smart to derive the correct type from
LFS_ALIAS_BITS. With your patch, it still would use long arguments,
which I presume should fail at runtime with mplayer2. We need to
change the wrapper's argument to reflect whatever is native to the
platform, not the mpg123 build (it _is_ the same for kFreeBSD).
Please have a read of my musings,
http://scm.orgis.org/view/mpg123/trunk/doc/LARGEFILE ,
and try the attached patch, which reflects the changes I did in mpg123
trunk, so that you can drop it for mpg123-1.16.0 (which I plan to
release once I got around fixing some decoder build choice).
I kindly ask everyone concerned to really test this on their platform
(including linking and running mplayer2 with mpg123 usage, for
example), as I don't have time to set up test installs for the variants
right now. I did check that the symbols get defined correctly on my
Linux system.
Index: src/libmpg123/lfs_alias.c
===
--- src/libmpg123/lfs_alias.c (Revision 3382)
+++ src/libmpg123/lfs_alias.c (Arbeitskopie)
@@ -67,9 +67,9 @@
my $name = $2;
my $args = $3;
next unless ($type =~ /off_t/ or $args =~ /off_t/ or ($name =~ /open/ and $name ne mpg123_open_feed));
- $type =~ s/off_t/long/g;
+ $type =~ s/off_t/lfs_alias_t/g;
my @nargs = ();
- $args =~ s/off_t/long/g;
+ $args =~ s/off_t/lfs_alias_t/g;
foreach my $a (split(/,/, $args))
{
$a =~ s/^.*\s\**([a-z_]+)$/$1/;
@@ -118,7 +118,7 @@
#ifdef mpg123_decode_frame
#undef mpg123_decode_frame
#endif
-int attribute_align_arg ALIAS_NAME(mpg123_decode_frame)(mpg123_handle *mh, long *num, unsigned char **audio, size_t *bytes)
+int attribute_align_arg ALIAS_NAME(mpg123_decode_frame)(mpg123_handle *mh, lfs_alias_t *num, unsigned char **audio, size_t *bytes)
{
return NATIVE_NAME(mpg123_decode_frame)(mh, num, audio, bytes);
}
@@ -126,7 +126,7 @@
#ifdef mpg123_framebyframe_decode
#undef mpg123_framebyframe_decode
#endif
-int attribute_align_arg ALIAS_NAME(mpg123_framebyframe_decode)(mpg123_handle *mh, long *num, unsigned char **audio, size_t *bytes)
+int attribute_align_arg ALIAS_NAME(mpg123_framebyframe_decode)(mpg123_handle *mh, lfs_alias_t *num, unsigned char **audio, size_t *bytes)
{
return NATIVE_NAME(mpg123_framebyframe_decode)(mh, num, audio, bytes);
}
@@ -134,7 +134,7 @@
#ifdef mpg123_framepos
#undef mpg123_framepos
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_framepos)(mpg123_handle *mh)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_framepos)(mpg123_handle *mh)
{
return NATIVE_NAME(mpg123_framepos)(mh);
}
@@ -142,7 +142,7 @@
#ifdef mpg123_tell
#undef mpg123_tell
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_tell)(mpg123_handle *mh)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_tell)(mpg123_handle *mh)
{
return NATIVE_NAME(mpg123_tell)(mh);
}
@@ -150,7 +150,7 @@
#ifdef mpg123_tellframe
#undef mpg123_tellframe
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_tellframe)(mpg123_handle *mh)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_tellframe)(mpg123_handle *mh)
{
return NATIVE_NAME(mpg123_tellframe)(mh);
}
@@ -158,7 +158,7 @@
#ifdef mpg123_tell_stream
#undef mpg123_tell_stream
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_tell_stream)(mpg123_handle *mh)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_tell_stream)(mpg123_handle *mh)
{
return NATIVE_NAME(mpg123_tell_stream)(mh);
}
@@ -166,7 +166,7 @@
#ifdef mpg123_seek
#undef mpg123_seek
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_seek)(mpg123_handle *mh, long sampleoff, int whence)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_seek)(mpg123_handle *mh, lfs_alias_t sampleoff, int whence)
{
return NATIVE_NAME(mpg123_seek)(mh, sampleoff, whence);
}
@@ -174,7 +174,7 @@
#ifdef mpg123_feedseek
#undef mpg123_feedseek
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_feedseek)(mpg123_handle *mh, long sampleoff, int whence, long *input_offset)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_feedseek)(mpg123_handle *mh, lfs_alias_t sampleoff, int whence, lfs_alias_t *input_offset)
{
return NATIVE_NAME(mpg123_feedseek)(mh, sampleoff, whence, input_offset);
}
@@ -182,7 +182,7 @@
#ifdef mpg123_seek_frame
#undef mpg123_seek_frame
#endif
-long attribute_align_arg ALIAS_NAME(mpg123_seek_frame)(mpg123_handle *mh, long frameoff, int whence)
+lfs_alias_t attribute_align_arg ALIAS_NAME(mpg123_seek_frame)(mpg123_handle *mh, lfs_alias_t frameoff, int whence)
{
return NATIVE_NAME(mpg123_seek_frame)
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Am Sat, 31 Aug 2013 16:02:45 +0200 schrieb Reinhard Tartler : > The attached patch seems to do the right thing on Debian > kFreeBSD/i386, i386 and amd64. I've therefore uploadedit to Debian > unstable. Sadly, that patch still is not quite right. Now Linux/i386 mixes long and off_t with 64 bit. The solution is to frame the declarations of the aliased functions with alias_t, which is long in this case, not off_t. Applying the attached patch in addition should fix this for all debian variants. This version is going to be released as 1.16.0 soon, and upgrading to this one highly recommened. Of course, any testing insights before release are welcome, too, best using the full thing from http://mpg123.org/snapshot Performance should be considerably improved, too. Alrighty then, Thomas Index: src/libmpg123/mpg123lib_intern.h === --- src/libmpg123/mpg123lib_intern.h (Revision 3398) +++ src/libmpg123/mpg123lib_intern.h (Revision 3399) @@ -16,30 +16,8 @@ #include "config.h" /* Load this before _anything_ */ #include "intsym.h" /* Prefixing of internal symbols that still are public in a static lib. */ -/* ABI conformance for other compilers. - mpg123 needs 16byte-aligned stack for SSE and friends. - gcc provides that, but others don't necessarily. */ -#ifdef ABI_ALIGN_FUN -#ifndef attribute_align_arg -#if defined(__GNUC__) && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__>1) -#define attribute_align_arg __attribute__((force_align_arg_pointer)) -/* The gcc that can align the stack does not need the check... nor does it work with gcc 4.3+, anyway. */ -#else +#include "abi_align.h" -#define attribute_align_arg -/* Other compilers get code to catch misaligned stack. - Well, except Sun Studio, which accepts the aligned attribute but does not honor it. */ -#if !defined(__SUNPRO_C) -#define NEED_ALIGNCHECK -#endif - -#endif -#endif -#else -#define attribute_align_arg -/* We won't try the align check... */ -#endif - /* export DLL symbols */ #if defined(WIN32) && defined(DYNAMIC_BUILD) #define BUILD_MPG123_DLL Index: src/libmpg123/lfs_alias.c === --- src/libmpg123/lfs_alias.c (Revision 3398) +++ src/libmpg123/lfs_alias.c (Revision 3399) @@ -39,10 +47,6 @@ #if _FILE_OFFSET_BITS+0 == LFS_ALIAS_BITS -/* The native functions are actually _with_ suffix, so let the mpg123 header use large file hackery to define the correct interfaces. */ -#include "mpg123.h" -/* Don't forget to undef the function symbols before usage... */ - /* The native functions have suffix, the aliases not. */ #define NATIVE_SUFFIX MACROCAT(_, _FILE_OFFSET_BITS) #define NATIVE_NAME(func) MACROCAT(func, NATIVE_SUFFIX) @@ -50,10 +54,6 @@ #else -/* Native functions are without suffix... */ -#define MPG123_NO_LARGENAME -#include "mpg123.h" - /* The alias functions have suffix, the native ones not. */ #define ALIAS_SUFFIX MACROCAT(_, LFS_ALIAS_BITS) #define ALIAS_NAME(func) MACROCAT(func, ALIAS_SUFFIX) @@ -61,9 +61,14 @@ #endif -/* Now get the rest of the infrastructure on speed, namely attribute_align_arg, to stay safe. */ -#include "mpg123lib_intern.h" +/* Copy of necessary definitions, actually just forward declarations. */ +struct mpg123_handle_struct; +typedef struct mpg123_handle_struct mpg123_handle; + +/* Get attribute_align_arg, to stay safe. */ +#include "abi_align.h" + /* Extract the list of functions we need wrappers for, pregenerating the wrappers for simple cases (inline script for nedit): perl -ne ' @@ -85,9 +90,7 @@ $nargs = "Human: figure me out." if($nargs =~ /\(/); print <http://mpg123.org + + derived from the old mpg123.h +*/ + +#ifndef MPG123_H_ABI_ALIGN +#define MPG123_H_ABI_ALIGN + +#include "config.h" + +/* ABI conformance for other compilers. + mpg123 needs 16byte-aligned stack for SSE and friends. + gcc provides that, but others don't necessarily. */ +#ifdef ABI_ALIGN_FUN +#ifndef attribute_align_arg +#if defined(__GNUC__) && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__>1) +#define attribute_align_arg __attribute__((force_align_arg_pointer)) +/* The gcc that can align the stack does not need the check... nor does it work with gcc 4.3+, anyway. */ +#else + +#define attribute_align_arg +/* Other compilers get code to catch misaligned stack. + Well, except Sun Studio, which accepts the aligned attribute but does not honor it. */ +#if !defined(__SUNPRO_C) +#define NEED_ALIGNCHECK +#endif + +#endif +#endif +#else +#define attribute_align_arg +/* We won't try the align check... */ +#endif + +#endif signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 waf build sysẗem and *FLAGS
Waf by default does accept CFLAGS and CXXFLAGS, and in all versions. There might be something in the Ardour3 project preventing that. Do you have any url for the source code and in particular for the wscript file? Thomas On Wed, Sep 25, 2013 at 5:54 PM, Jaromír Mikeš wrote: > > Hi Thomas, > > we have some issue with Ardour3 packaging and waf build system > > In new versions of debhelper we are passing extra CFLAGS CXXFLAGS and > LDFLAGS. > As we succeeded with LDFLAGS we didn't with CFLAGS and CXXFAGS. > > By documentation waf should accept standard variables, but it doesn't in > our case. > http://code.google.com/p/waf/wiki/EnvironmentVariables > > Any solution for our problem? > > best regards > > mira > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 waf build sysẗem and *FLAGS
On Wed, Sep 25, 2013 at 9:03 PM, Felipe Sateler wrote: > > Hi Thomas, > > On Wed, Sep 25, 2013 at 1:42 PM, Thomas Nagy wrote: > > Waf by default does accept CFLAGS and CXXFLAGS, and in all versions. > > > > There might be something in the Ardour3 project preventing that. Do you have > > any url for the source code and in particular for the wscript file? > > Here is the wscript file[1] > > Paul Davis[2] noted that --optimize seems to enable waf to pick up the > C*FLAGS variables. Is this intended behavior, or possibly something in > the wscript is triggering this? > The Ardour wscript file loads an Ardour helper module called "autowaf.py". This module will force specific CFLAGS/CXXFLAGS in the default build. If I am not mistaken, the default build is intended as a debug build and will enforce its own flags. This is therefore an Ardour-specific trap, and you almost certainly want to configure Ardour with "--optimize" for packaging purposes. Regards, Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Introduction
Hi! My name is Thomas Maass from Germany. I am working with Debian several years. I have started with SuSe 8.0, and came to Debian with Woody. Since then I stayed on Debian. Now I want to help. I'd like to join the Debian multimedia team. I have created an alioth account and subscribed to the mailing lists. I have build several packages for private use, and I want to give my work to the Debian project. The first package I'd like to upload is called clipgrab. It is a GUI application written in QT to download from several videoportals like Youtube, MyVideo, Sevenload etc. You can also directly convert into several videoformats. I hope, you add me to your group! Thank you! Thomas signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Hi again! Another package I finished is panucci. It is an audio and podcast player with resuming function. It interacts great with gpodder. This is a pre- version from git, but works very good! I hope to get an invitation to your group! signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Am Dienstag, den 17.08.2010, 12:23 +0200 schrieb Reinhard Tartler: > On Tue, Aug 17, 2010 at 08:55:40 (CEST), Thomas Maass wrote: > > > Hi again! > > Another package I finished is panucci. It is an > > audio and podcast player with resuming function. > > It interacts great with gpodder. This is a pre- > > version from git, but works very good! > > Some questions: > > - Can we have a look at your proposed packages? > - Does someone in the team endorse panucci and clibgrab > - What's your alioth account id? > - Have you been active somewhere else in debian before, or is the > multimedia team the first point of contact with debian developers? > My ID is mase-guest. I haven't been acvite in Debian before. I only built some packages for personal use. I thought, why not giving it all back to debian. I packaged different things, not only multimedia. But I think, the most help I can provide is in that section. I am really new to the community stuff. I still have to learn, how to use all the things. Where can I upload? signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Am Dienstag, den 17.08.2010, 17:40 +0200 schrieb Reinhard Tartler: > On Tue, Aug 17, 2010 at 17:05:30 (CEST), Thomas Maass wrote: > > > Am Dienstag, den 17.08.2010, 12:23 +0200 schrieb Reinhard Tartler: > >> On Tue, Aug 17, 2010 at 08:55:40 (CEST), Thomas Maass wrote: > >> > >> > Hi again! > >> > Another package I finished is panucci. It is an > >> > audio and podcast player with resuming function. > >> > It interacts great with gpodder. This is a pre- > >> > version from git, but works very good! > >> > >> Some questions: > >> > >> - Can we have a look at your proposed packages? > >> - Does someone in the team endorse panucci and clibgrab > >> - What's your alioth account id? > >> - Have you been active somewhere else in debian before, or is the > >> multimedia team the first point of contact with debian developers? > >> > > My ID is mase-guest. I haven't been acvite in Debian before. I > > only built some packages for personal use. I thought, why not > > giving it all back to debian. > > Excellent, you are on the right track! :-) > > > I packaged different things, not only multimedia. But I think, the > > most help I can provide is in that section. I am really new to the > > community stuff. I still have to learn, how to use all the things. > > Sure, and working in a team is a very efficient way to learn! > > BTW, packaging new stuff is not the only way to contribute. You could > also take a look at existing packages of our team and post patches to > this list! If they are good and can be integrated, we will make sure > that we retain your full attribution. > > > Where can I upload? > > Either you have some private webspace somewhere, or you can upload to > mentors.debian.net and tell us the download url here! Or technically, > you could also use the service http://revu.tauware.de, although is > rather targeted for ubuntu. > > Espc. for new packagers, I've made the experimence that getting the > package in shape before uploading it to git.debian.org is more efficient > than ironing out all problems via git. > Here are 2 of my packages: http://mentors.debian.net/debian/pool/main/c/clipgrab http://mentors.debian.net/debian/pool/main/p/panucci signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: separate discussion and development lists
Am Dienstag, den 17.08.2010, 12:08 -0400 schrieb Felipe Sateler: > On 17/08/10 11:58, Reinhard Tartler wrote: > > On Sun, Aug 15, 2010 at 20:15:40 (CEST), Andreas Tille wrote: > > > >> On Sat, Aug 14, 2010 at 10:10:45AM +0200, Reinhard Tartler wrote: > >>> Perhaps? My biggest concern is that with 3 lists, it becomes more and > >>> more challenging to decide to which list to post. Replies to -vcs mails > >>> currently go to -maintainers because of the reply-to, so I guess that > >>> would remain. But what about discussion mails on -maintainers, that are > >>> supposed to go to debian-multime...@l.d.o? This overhead of > >>> meta-discussion about a topic being ontopic or offtopic is the price I > >>> see for having a third list. (it could be mitigated with a proper and > >>> clear charter, I imagine). > >> > >> For me the maintainers list is way to noisy and I guess a lot of users > >> will see it the same way. Moreover I'm afraid that just because of the > >> name of the list as well as the location users will not even consider > >> subscribing this list (as I would never have done if I would not > >> explicitely asked to raise the Blends topic here). IMHO we have no > >> proper place to discuss the issues of multimedia users inside Debian and > >> that's a pity because we might loose users (and potential developers) > >> because of this. > > > > I've had a small private followup conversation with Andreas about > > this. He basically came up with the suggestion to turn > > debian-multime...@lists.debian.org from a *development* oriented mailing > > list to a *user* focused list. This way users can share their thoughts, > > concerns and kudos. > > I thought this was the idea the whole time? > > > > > While I don't think that this will significantly lower the amount of > > traffic (well, we actually widen the set of topics), I still think that > > it will be benefitial for pkg-multimedia, because: > > > > - we get more contact with our actual users > > - we learn what's pressing and bugging them > > - we hopefully get more potential and real contributors, ideally even > >new developers > > > > > > WDYT? > > Every time I think about it, I like it more. I think we should do that. > And announce it to the world via d-d-a. > > I am new to this list and I can share your thoughts. Some posts are to get lost in the huge amount of posts. signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
I have a question about my package "clipgrab". The license says, that the program is licensed under the GPLv3, but the name and the logo are not. I have contacted the author. He said, that he has the full copyright for the logo and the name. He allowed my explicitly, that I may package the program for Debian. He hopes, that this will be no problem with the Debian policy. He said, changing the logo and the name makes no sense. The included changelog file describes, that only the program is under GPLv3, but not the logo and name. Is this package correct now? How can / must I describe the allowance of the author? Maybe you could have a look at the package. I have uploaded it to mentors (see earlier messages). -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
I think, the only way to get it to Debian, is moving it to the non-free repository. -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Did you have a look at my packages? -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: clibgrab review: was: Introduction
I did not understand the thing with the itp-bug. Because clipgrab.xpm and the name is not licensed under the GPLv3, I added the original copyright file to the package. The author allowed me to use it with the Debian package. I am still no member of a team, so where the maintainer field should point to? The description is not terse, the program doesn't do more, that I have descriped. I have corrected the desktop file and removed libstdc++-dev from the build dependencies. -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: clibgrab review: was: Introduction
I have corrected the packages as good as I could. I have also created an ITP-bug. It should fit now. Did you think about my membership in your team? -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: clibgrab review: was: Introduction
Hi! Don't you like me as a member of your team? I did not get any answer about this. -- gpg-id: D31AAEEA http://www.setho.org/people signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: clibgrab review: was: Introduction
Hi! Don't you like me as a member of your team? I did not get any answer about this. -- gpg-id: D31AAEEA http://www.setho.org/people signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: clibgrab review: was: Introduction
I revoked my key a few weeks ago, because my email address has changed. I have removed my packages from mentors. I understood. It seems, that you are not interested, that beginners join your team, and help them, getting started. So it makes no sense for me here. -- gpg-id: D31AAEEA http://www.setho.org/people signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#600653: libprojectm2: setter methods needed to change values of some private attributes (patch included)
Package: libprojectm2
Version: 2.0.1+dfsg-3
Severity: normal
Tags: patch
Hi,
I currently work on Clementine packaging in Debian [1] . Clementine is a music
player [2] which use the libprojectm library.
Clementine use a patched version of libprojectm because two setter are missing
to access to some private class attributes in this library. Therefore, these
modifications are mandatory to make clementine compiling.
So, I join you these two small patches and hope you will agree to include it
in the libprojectm package.
Regards,
Thomas PIERSON
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579859
[2] http://www.clementine-player.org/
Index: projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp
===
--- projectm-2.0.1+dfsg.orig/src/libprojectM/projectM.cpp 2010-10-15 20:32:50.717456717 +
+++ projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp 2010-10-15 20:35:51.629456716 +
@@ -898,3 +898,12 @@
}
+void projectM::changeTextureSize(int size) {
+ _settings.textureSize = size;
+
+ delete renderer;
+ renderer = new Renderer(_settings.windowWidth, _settings.windowHeight,
+ _settings.meshX, _settings.meshY,
+ _settings.textureSize, beatDetect, _settings.presetURL,
+ _settings.titleFontURL, _settings.menuFontURL);
+}
Index: projectm-2.0.1+dfsg/src/libprojectM/projectM.hpp
===
--- projectm-2.0.1+dfsg.orig/src/libprojectM/projectM.hpp 2010-10-15 20:35:58.809456716 +
+++ projectm-2.0.1+dfsg/src/libprojectM/projectM.hpp 2010-10-15 20:36:53.469456717 +
@@ -153,8 +153,7 @@
virtual ~projectM();
-
-
+ void changeTextureSize(int size);
const Settings & settings() const {
Index: projectm-2.0.1+dfsg/src/libprojectM/TimeKeeper.hpp
===
--- projectm-2.0.1+dfsg.orig/src/libprojectM/TimeKeeper.hpp 2010-10-15 20:55:31.549456718 +
+++ projectm-2.0.1+dfsg/src/libprojectM/TimeKeeper.hpp 2010-10-15 20:56:15.177456716 +
@@ -37,6 +37,8 @@
double sampledPresetDuration();
+ void ChangePresetDuration(int seconds) { _presetDuration = seconds; }
+
#ifndef WIN32
/* The first ticks value of the application */
struct timeval startTime;
Index: projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp
===
--- projectm-2.0.1+dfsg.orig/src/libprojectM/projectM.cpp 2010-10-15 20:55:31.561456716 +
+++ projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp 2010-10-15 20:56:47.921456714 +
@@ -907,3 +907,7 @@
_settings.textureSize, beatDetect, _settings.presetURL,
_settings.titleFontURL, _settings.menuFontURL);
}
+
+void projectM::changePresetDuration(int seconds) {
+ timeKeeper->ChangePresetDuration(seconds);
+}
Index: projectm-2.0.1+dfsg/src/libprojectM/projectM.hpp
===
--- projectm-2.0.1+dfsg.orig/src/libprojectM/projectM.hpp 2010-10-15 20:55:31.573456716 +
+++ projectm-2.0.1+dfsg/src/libprojectM/projectM.hpp 2010-10-15 20:57:20.233456715 +
@@ -154,7 +154,7 @@
virtual ~projectM();
void changeTextureSize(int size);
-
+ void changePresetDuration(int seconds);
const Settings & settings() const {
return _settings;
signature.asc
Description: This is a digitally signed message part.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#608680: Only supported for x86 target
-march=native is only supported for (Intel 386 and AMD x86-64)-like targets. A simple solution would be to just disable this flag. Another option would be to populate CPPFLAGS in debian/rules with -march=native depending on the output of dpkg-architecture and the value of DEB_BUILD_OPTIONS. signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#615511: openmovieeditor: Cannot play any video, "Soundoutput failed" error
Package: openmovieeditor Version: 0.0.20080102-3 Severity: grave Justification: renders package unusable Using openmovieeditor I am unable to play any video and hence cannot use it. I have been careful not to install the ffmpeg/libav* packages from debian-multimedia.org The applications starts up fine, I'm able to open clips and place them on the timeline successfully, and I'm able to jog through the timeline and see the picture. However I cannot play back the video on the timeline. Console shows the following when I attempt to play the video on the timeline: Soundoutput failed: Host error. Console shows the following when the application starts up: When submitting a BUG report, or SUPPORT request, please include the following information: 8<--- Libquicktime Version: 1.1.5 Libquicktime API Version: 10 libavcodec Version: Lavc52.20.1 libavformat Version: Lavf52.31.0 /etc/debian_version: 6.0 8<--- could not connect to jack. When submitting a BUG report, or SUPPORT request, please include the following information: 8<--- OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 9500 GT/PCI/SSE2 OpenGL version string: 3.2.0 NVIDIA 195.36.31 GL_MAX_TEXTURE_SIZE = 8192 8<--- -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openmovieeditor depends on: ii libavcodec52 4:0.5.2-6 ffmpeg codec library ii libavformat52 4:0.5.2-6 ffmpeg file format library ii libavutil494:0.5.2-6 ffmpeg utility library ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libfltk1.1 1.1.10-2+b1 Fast Light Toolkit - shared librar ii libgavl1 1.1.2-3 low level audio and video library ii libgcc11:4.4.5-8 GCC support library ii libgl1-mesa-glx [libgl 7.7.1-4 A free implementation of the OpenG ii libjack0 [libjack-0.11 1:0.118+svn3796-7 JACK Audio Connection Kit (librari ii libmpeg3-1 1.5.4-5 MPEG streams decoding library ii libquicktime1 2:1.1.5-1+b1 library for reading and writing Qu ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsndfile11.0.21-3 Library for reading/writing audio ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libswscale04:0.5.2-6 ffmpeg video scaling library ii libx11-6 2:1.3.3-4 X11 client-side library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime openmovieeditor recommends no packages. openmovieeditor suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#616080: gmerlin: segfault on start
Package: gmerlin Version: 0.4.3-2+b1 Severity: grave Justification: renders package unusable gmerlin won't start Starting from console results in: $ gmerlin Segmentation fault $ Starting from gnome menu just results in nothing happening. This is also true of its other tools such as gmerlin_transcoder. I have a pure squeeze stable system right now; I don't think I have anything strange installed. I have a Core 2 Duo E4400 and NVidia graphics. I don't think I have anything else unusual. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gmerlin depends on: ii gmerlin-data0.4.3-2 a multiformat media player ii libasound2 1.0.23-2.1 shared library for ALSA applicatio ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcddb21.3.2-2 library to access CDDB data - runt ii libcdio-cdda0 0.81-4 library to read and control digita ii libcdio-paranoia0 0.81-4 library to read digital audio CDs ii libcdio10 0.81-4 library to read and control CD-ROM ii libesd0 0.2.41-8 Enlightened Sound Daemon - Shared ii libgavl11.1.2-3 low level audio and video library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgmerlin0 0.4.3-2+b1 core library for gmerlin - runtime ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libjack-jackd2-0 [libja 1.9.6~dfsg.1-2 JACK Audio Connection Kit (librari ii libjpeg62 6b1-1The Independent JPEG Group's JPEG ii libmusicbrainz4c2a 2.1.5-4 Second generation incarnation of t ii libpng12-0 1.2.44-1 PNG library - runtime ii libpulse0 0.9.21-3+b1 PulseAudio client libraries ii libquicktime1 2:1.1.5-1+b1 library for reading and writing Qu ii libtiff43.9.4-5 Tag Image File Format (TIFF) libra ii libv4l-00.8.0-1 Collection of video4linux support ii libx11-62:1.3.3-4X11 client-side library ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxinerama12:1.1-3 X11 Xinerama extension library ii libxml2 2.7.8.dfsg-2 GNOME XML library ii libxv1 2:1.0.5-1X11 Video extension library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gmerlin recommends: pn libgmerlin-avdec0 (no description available) gmerlin suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#630549: clementine: Crash when openong visualizations menu
On 01/07/2011 00:52, Christian Marillat wrote: > Mais be you need to read the clementine source code ? > > In CMakeLists.txt : > > , > | option(USE_SYSTEM_PROJECTM "Don't set this option unless your system > projectM library has been compiled with the Clementine patches in 3rdparty" > OFF) > ` > > Not a bug surprise if clementine doesn't work if build with the 'real' > and apparently broken 'libprojectm2' Debian package. > > Christian > Maybe you need to read the file 'README.Debian' in the package : [...] "* libprojectm2: It is a shared library already packaged in Debian but some patches are needed to compile Clementine with it. Patches are now included since version 2.0.1+dfsg-6 of libprojectm2. (see #600653)" [...] So, as you could see here : #600653, these patches are already applied. I work for a year on this package and I did not forget to read the clementine sources... Thanks for your help. Regards, Thomas PIERSON ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#630549: More info
Hi Christian, > I did a diff between these two versions and these version aren't not > the same. > For me the solution is to build clementine against the included > version. This is recommend by clementine author and the default. No, we can't use an embedded version while a package exist for libprojectm2 in Debian archive [1]. In addition, I think this package is ok regarding the upstream source and project of libprojectm. And if clementine really need more patches applied on this library, we will be able to ask this to Matthias who maintain this package. For the moment, I could not find other person who has this issue. So I think it is a corner case that affect only some people. I will continue to inspect this issue using your backtrace. Best regards, Thomas PIERSON -- [1] Debian Policy "§4.13 Convenience copies of code" : [...]If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible.[...] ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#515850: ITP: mjpegtools -- MJPEG video capture/editting/playback MPEG encoding
Hi, Is there any news about this package? It was tagged as pending 3 months ago. Why was it rejected? Is there anything I can do for help? Regards, Thomas. signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#654955: sound system crashed waking up from suspend
Package: vlc Version: 1.1.3-1squeeze6 Severity: normal Dear maintainer, When running Squeeze, do the following: 1/ Start playing a video 2/ Pause de video 3/ Put your computer into suspend mode 4/ Go back from sleep mode 5/ Unpause the video Then there's no sound, and sometimes there's audio cracks. I haven't tested this in SID / Wheezy, sorry. Thanks for maintaining VLC in Debian, Thomas -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc depends on: ii libaa11.4p5-38 ascii art library ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libfreetype6 2.4.2-2.1+squeeze3 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.4.5-8 GCC support library ii libgl1-mesa-glx [libg 7.7.1-5A free implementation of the OpenG ii libqtcore44:4.6.3-4+squeeze1 Qt 4 core module ii libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module ii libsdl-image1.2 1.2.10-2+b2image loading library for Simple D ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libtar1.2.11-6 C library for manipulating tar arc ii libvlccore4 1.1.3-1squeeze6base library for VLC and its modul ii libx11-6 2:1.3.3-4 X11 client-side library ii libx11-xcb1 2:1.3.3-4 Xlib/XCB interface library ii libxcb-keysyms1 0.3.6-1utility libraries for X C Binding ii libxcb-randr0 1.6-1 X C Binding, randr extension ii libxcb-shm0 1.6-1 X C Binding, shm extension ii libxcb-xv01.6-1 X C Binding, xv extension ii libxcb1 1.6-1 X C Binding ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii ttf-freefont 20090104-7 Freefont Serif, Sans and Mono True ii vlc-nox 1.1.3-1squeeze6multimedia player and streamer (wi ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages vlc recommends: ii vlc-plugin-notify1.1.3-1squeeze6 LibNotify plugin for VLC ii vlc-plugin-pulse 1.1.3-1squeeze6 PulseAudio plugin for VLC Versions of packages vlc suggests: ii mozilla-plugin-vlc 1.1.3-1squeeze6 multimedia plugin for web browsers pn videolan-doc (no description available) Versions of packages vlc-nox depends on: ii liba52-0.7.4 0.7.4-14 library for decoding ATSC A/52 str ii libasound21.0.23-2.1 shared library for ALSA applicatio ii libass4 0.9.9-1library for SSA/ASS subtitles rend ii libavahi-client3 0.6.27-2+squeeze1 Avahi client library ii libavahi-common3 0.6.27-2+squeeze1 Avahi common library ii libavc1394-0 0.5.3-1+b2 control IEEE 1394 audio/video devi ii libavcodec52 4:0.5.6-3 ffmpeg codec library ii libavformat52 4:0.5.6-3 ffmpeg file format library ii libavutil49 4:0.5.6-3 ffmpeg utility library ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcaca0 0.99.beta17-1 colour ASCII art library ii libcddb2 1.3.2-2library to access CDDB data - runt ii libcdio10 0.81-4 library to read and control CD-ROM ii libdbus-1-3 1.2.24-4+squeeze1 simple interprocess messaging syst ii libdc1394-22 2.1.2-3high level programming interface f ii libdca0 0.0.5-3decoding library for DTS Coherent ii libdirac-encoder0 1.0.2-3open and royalty free high quality ii libdvbpsi60.1.7-1library for MPEG TS and DVB PSI ta ii libdvdnav44.1.3-7DVD navigation library ii libdvdread4 4.1.3-10 library for reading DVDs ii libebml0 0.7.7-3.1 access library for the EBML format ii libfaad2 2.7-6 freeware Advanced Audio Decoder - ii libflac8 1.2.1-2+b1 Free Lossless Audio Codec - runtim ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1+squeeze3 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.4.5-8 GCC support li
Bug#656502: blender: [FTBFS] Does not build with libav 0.8~beta2
Source: blender
Version: 6.3.1
Severity: serious
Tags: patch upstream
Justification: Fails to build from source
In addition to #654428, blender also fails to build from source because
of API changes in libav 0.9~beta2. Attached is a patch which fix all (3)
the issues I found until #654428 build failure.
Note the change related to avformat_alloc_output_context2 in
ffmpeg_compat.h header. Blender is likely to need the same kind of
change when a future version of libav will be uploaded to Debian.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: armhf (armv7l)
Kernel: Linux 2.6.38-ac2-ac100 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: Adapt to libavutil API changes
Add include for libavutil/mathematics.h in ffmpeg_compat.h and writeffmpeg.c
since it is no longer included in libavutil/avutil.h
Author: Thomas Preud'homme
Origin: vendor
Forwarded: no
Last-Update: 2012-01-19
---
--- blender-2.61.orig/intern/ffmpeg/ffmpeg_compat.h
+++ blender-2.61/intern/ffmpeg/ffmpeg_compat.h
@@ -35,6 +35,7 @@
#include
#include
+#include
#if (LIBAVFORMAT_VERSION_MAJOR > 52) || ((LIBAVFORMAT_VERSION_MAJOR >= 52) && (LIBAVFORMAT_VERSION_MINOR >= 101))
#define FFMPEG_HAVE_PARSE_UTILS 1
--- blender-2.61.orig/source/blender/blenkernel/intern/writeffmpeg.c
+++ blender-2.61/source/blender/blenkernel/intern/writeffmpeg.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
>From 63b4c577c951245904fd59ac8c6021bab18b0de4 Mon Sep 17 00:00:00 2001
From: Antonio Ospite
Date: Sat, 17 Dec 2011 15:45:16 +0100
Subject: [PATCH] Make blender compile with FFmpeg from Debian.
X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\2t5)({*|jhM/Vb;]yA5\I~93>J<_`<4)A{':UrE
avformat_alloc_output_context2() should be in the libavformat 53.2.0 but
it isn't in Debian, re-define it.
Signed-off-by: Antonio Ospite
---
intern/ffmpeg/ffmpeg_compat.h | 61 +
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/intern/ffmpeg/ffmpeg_compat.h b/intern/ffmpeg/ffmpeg_compat.h
index dfdad22..5259f69 100644
--- a/intern/ffmpeg/ffmpeg_compat.h
+++ b/intern/ffmpeg/ffmpeg_compat.h
@@ -48,6 +48,67 @@
#define FFMPEG_HAVE_AVIO 1
#endif
+#if (LIBAVFORMAT_VERSION_MAJOR < 53) || ((LIBAVFORMAT_VERSION_MAJOR == 53) && (LIBAVFORMAT_VERSION_MINOR < 21))
+/* XXX The last check above should be (LIBAVFORMAT_VERSION_MINOR < 2),
+ * look at http://patches.libav.org/patch// but ffmpeg in Debian is
+ * strange: 53.2.0 should have avformat_alloc_output_context2() but it does
+ * not.
+ */
+#include
+static int avformat_alloc_output_context2(AVFormatContext **avctx, AVOutputFormat *oformat,
+ const char *format, const char *filename)
+{
+AVFormatContext *s = avformat_alloc_context();
+int ret = 0;
+
+*avctx = NULL;
+if (!s)
+goto nomem;
+
+if (!oformat) {
+if (format) {
+oformat = av_guess_format(format, NULL, NULL);
+if (!oformat) {
+av_log(s, AV_LOG_ERROR, "Requested output format '%s' is not a suitable output format\n", format);
+ret = AVERROR(EINVAL);
+goto error;
+}
+} else {
+oformat = av_guess_format(NULL, filename, NULL);
+if (!oformat) {
+ret = AVERROR(EINVAL);
+av_log(s, AV_LOG_ERROR, "Unable to find a suitable output format for '%s'\n",
+ filename);
+goto error;
+}
+}
+}
+
+s->oformat = oformat;
+if (s->oformat->priv_data_size > 0) {
+s->priv_data = av_mallocz(s->oformat->priv_data_size);
+if (!s->priv_data)
+goto nomem;
+if (s->oformat->priv_class) {
+*(const AVClass**)s->priv_data= s->oformat->priv_class;
+av_opt_set_defaults(s->priv_data);
+}
+} else
+s->priv_data = NULL;
+
+if (filename)
+av_strlcpy(s->filename, filename, sizeof(s->filename));
+*avctx = s;
+return 0;
+nomem:
+av_log(s, AV_LOG_ERROR, "Out of memory\n");
+ret = AVERROR(ENOMEM);
+error:
+avformat_free_context(s);
+return ret;
+}
+#endif
+
#if (LIBAVCODEC_VERSION_MAJOR > 53) || ((LIBAVCODEC_VERSION_MAJOR == 53) && (LIBAVCODEC_VERSION_MINOR > 1)) || ((LIBAVCODEC_VERSION_MAJOR == 53) && (LIBAVCODEC_VERSION_MINOR == 1) && (LIBAVCODEC_VERSION_MICRO >= 1)) || ((LIBAVCODEC_VERSION_MAJOR == 52) && (LIBAVCODEC_VERSION_MINOR >= 121))
#define FFMPEG_HAVE_DEFAULT_VAL_UNION 1
#endif
--
1.7.7.3
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#654955: sound system crashed waking up from suspend
On 03/03/2012 08:13 PM, Rémi Denis-Courmont wrote: > tags 654955 + moreinfo > thanks > > Hello, > > Le samedi 7 janvier 2012 07:09:57 Thomas Goirand, vous avez écrit : >> When running Squeeze, do the following: >> 1/ Start playing a video >> 2/ Pause de video >> 3/ Put your computer into suspend mode >> 4/ Go back from sleep mode >> 5/ Unpause the video >> >> Then there's no sound, and sometimes there's audio cracks. > > You'll need to be more specific. > What's the audio output Pulse audio with output to alsa. Is this what you expected as answer? If not, please be more specific in your question. > what's the audio hardware Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03). lspci -n output: 00:1b.0 0403: 8086:293e > how do you suspend Closing my laptop physically, but I guess that system -> shutdown -> suspend (with gnome) would have do the same. > what do the kernel logs Nothing special. It works with mplayer ... > and the VLC logs say? Where/how should I get this? Thomas P.S: Unless I'm mistaking, usually, you wouldn't tag "moreinfo" at the same time as your first answer to the reporter, and you should expect that a DD would be responsive to requests for information, after sending a report, no? At least, you can expect that from me... :) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#757370: vdpau-va-driver: Please add symlink for nouveau_drv_video.so
Package: vdpau-va-driver Version: 0.7.4-2 Severity: normal See bug 705558. The second part of the report (the lack of libvdpau_nouveau.so) is fixed in mesa by the fix for that bug. However, the first part (symlinking vdpau_drv_video.so to nouveau_drv_video.so) is still necessary in order to get VDPAU to work on supported nouveau-driven cards. Adding that symlink manually fixes the problem (as one would expect), so all that seems necessary is to add the symlink in this package, that is, from: /usr/lib/x86_64-linux-gnu/dri/vdpau_drv_video.so to: /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (90, 'utopic-updates'), (90, 'utopic-security'), (90, 'utopic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-32-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vdpau-va-driver depends on: ii libc6 2.19-0ubuntu6.1 ii libgl1-mesa-glx [libgl1] 10.1.3-0ubuntu0.1 ii libvdpau1 0.7-1 ii libx11-6 2:1.6.2-1ubuntu2 ii multiarch-support 2.19-0ubuntu6.1 vdpau-va-driver recommends no packages. vdpau-va-driver suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#761233: audacious: “Amplify untagged files” has no effect
Package: audacious Version: 3.2.4-1 Severity: normal Dear Maintainer, under Preferences→Audio→ReplayGain→Adjust Levels, the “Amplify untagged files” settings don't have any effect. Thanks. -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages audacious depends on: ii audacious-plugins3.2.4-1 ii dbus 1.6.8-1+deb7u1 ii dbus-x11 1.6.8-1+deb7u1 ii gtk2-engines-pixbuf 2.24.10-2 ii libaudclient23.2.4-1 ii libaudcore1 3.2.4-1 ii libc62.13-38+deb7u1 ii libdbus-1-3 1.6.8-1+deb7u3 ii libdbus-glib-1-2 0.100.2-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-7 ii libguess11.1-1 ii libice6 2:1.0.8-2 ii libsm6 2:1.2.1-2 Versions of packages audacious recommends: ii unzip 6.0-8 audacious suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#764374: libgroove: FTBFS on hurd-i386
Hi! On Tue, 07 Oct 2014 18:42:06 +0200, Svante Signell wrote: > libgroove fails to build on GNU/Hurd due to a name clash with OSX, both > are defining the __MACH__ keyword. > --- a/grooveplayer/osx_time_shim.h2014-09-25 17:26:09.0 +0200 > +++ b/grooveplayer/osx_time_shim.h2014-10-07 18:27:30.0 +0200 > @@ -8,7 +8,7 @@ > > #ifndef GROOVE_MACH_TIME_H_INCLUDED > #define GROOVE_MACH_TIME_H_INCLUDED > -#ifdef __MACH__ > +#if defined(__MACH__) && !defined(__GNU__) Instead of masking out the false positive, how about explicitly stating: »#if defined(__MACH__) && defined(__APPLE__)«. That's how it is usually written, if I remember correctly. That said, just to confirm: it is expected that this file, osx_time_shim.h, is included even for non-OSX builds? Grüße, Thomas pgpw399VWAUty.pgp Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#770447: use of ssl.PROTOCOL_SSLv3 which we don't support anymore
Package: blender Version: 2.72.b+dfsg0-1 Severity: serious Hi, A rapid code search shows that blender uses: ssl_version=ssl.PROTOCOL_SSLv3 in release/scripts/addons/netrender/master.py:1161 However, this support has been removed in Debian. Therefore, it is possible that blender is broken. I haven't checked myself if this breaks the build of Blender, or if it affects it a lot, as I have no time to do that. Though I would strongly suggest the maintainer to check, and eventually downgrade this bug to important only. Cheers, Thomas Goirand (zigo) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#770447: use of ssl.PROTOCOL_SSLv3 which we don't support anymore
On 11/21/2014 07:07 PM, Cyril Brulebois wrote: > Control: severity -1 important > > Thomas Goirand (2014-11-21): >> Package: blender >> Version: 2.72.b+dfsg0-1 >> Severity: serious >> >> Hi, >> >> A rapid code search shows that blender uses: >> >> ssl_version=ssl.PROTOCOL_SSLv3 >> >> in release/scripts/addons/netrender/master.py:1161 >> >> However, this support has been removed in Debian. Therefore, it is possible >> that blender is broken. >> >> I haven't checked myself if this breaks the build of Blender, or if it >> affects it a lot, as I have no time to do that. Though I would strongly >> suggest the maintainer to check, and eventually downgrade this bug to >> important only. > > Definitely not breaking the build. > > And given it's an addon, seemingly for network rendering, I don't think > this qualifies as a serious bug. That doesn't mean fixing it for jessie > would be rejected outright. > > (A quick web search seems to point out it's diabled by default, see > Instructions on: > http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Performance/Netrender) > > Mraw, > KiBi. Thanks for taking the time to investigat it (which I didn't have time yet, but still wanted to push the bug before I had to go out of $workplace). Cheers, Thomas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#770447: use of ssl.PROTOCOL_SSLv3 which we don't support anymore
On 11/22/2014 03:28 AM, Matteo F. Vescovi wrote: > Hi! > > On Nov 21, 2014 7:51 PM, "Thomas Goirand" <mailto:z...@debian.org>> wrote: >> Thanks for taking the time to investigat it (which I didn't have time >> yet, but still wanted to push the bug before I had to go out of > $workplace). > > Now, given that the SSLv3 feature is disabled by default, could this bug > be closed? Thomas, is it ok for you? > > Cheers. Hi, I'm not sure you get the point of me opening this bug. The point is, if you have an instance of ssl.PROTOCOL_SSLv3, then when the Python parser will try to execute the code, it will crash (stack dump). For this reason, I've done something like this in my packages: http://anonscm.debian.org/cgit/openstack/oslo.messaging.git/commit/?id=6e39d2c1fad7be373651abd709feea9c3b56977c Maybe your package needs that too? Cheers, Thomas Goirand (zigo) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#774427: wavpack: Some curly quotes in wavpack(1) should be straight
Package: wavpack Version: 4.70.0-1 Severity: minor Some curly quotes in wavpack(1) should be straight, in the description of the -w and --write-binary-tags options. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports'), (90, 'vivid-updates'), (90, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-40-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wavpack depends on: ii libc62.19-0ubuntu6.4 ii libwavpack1 4.70.0-1 wavpack recommends no packages. wavpack suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738453: Hyvää päivää,
Hyvää päivää, Tämä viesti on peräisin asiakaspalveluun yritys. Tämä on ilmoittaa teille, että annamme lainaa korolla 2% tässä kuussa sekä vanhoja ja uusia asiakkaita ja meidän etumme tässä kuussa lainaa on erittäin edullinen ja meidän laina prosessi on hyvin nopea. Sillä kaikki kiinnostuneet yritykset, rahoituslaitokset ja yksityishenkilöille, ota yhteyttä takaisin tänään alla olevaan saamiseksi lainaa. Lainan määrä: Laina Kesto: Puhelin: Maa: Ystävällisin terveisin Pääjohtaja / toimitusjohtaja Asiakaspalvelu ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#782120: Upstream is aware and working on a fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We became aware minutes after the bug was filed (Thanks Ukikie). We've discussed this with Juliane, reproduced it and are working on a fix and release. Details later today. Thomas Ruecker Icecast maintainer / Xiph.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlUk6MsACgkQfkVKO9VkYGkFEACeOGULWCqTlrQVGgdOy1SWe4Yt V68An0DXaQNVrgB2xQn4XlVBOLs58gfk =Ftrl -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786718: libmpg123: incorrect check/decoding for utf-16 surrogates in id3 parser
Hi Yuriy!
Am Sun, 24 May 2015 23:08:12 +0300
schrieb "Yuriy M. Kaminskiy" :
> utf-16 decoder in id3 parser improperly identifies surrogate pairs,
> resulting in improper identification of characters in 0xf800-0xfffe
> range as leading surrogate and decoding failure.
>
> E.g. attempt to decode title "｢x｣～y～" results in:
> [id3.c:1065] error: Invalid UTF16 surrogate pair at 0 (0xff62).
> and empty parsed title.
Could you please send me (mpg123 upstream maintainer) a little (piece
of an) example file to add as regression test for this? As ID3 tag
writers also have a history of messing up encoding, I'd like to use the
original and not a fake I did myself;-)
Regarding the patch: Oh, yes, I see stupid me not getting the proper
idea about bit masks back in 2006/2007 in this case.
Let's recap to be on the safe side:
high surrogate range: 0xD800 to 0xDBFF
low suggogate range: 0xDC00 to 0xDFFF
Do we agree on that or is my knowledge of UTF-16 outdated?
I sense that the mask 0xf800 doesn't cover the first range properly,
neither. We need to detect bit sequences between
0b11011000
0b11011011
We don't want to catch
0b110111xx
in there. So a proper mask should be
0b1100
which is 0xfc00 in hex, too. Verifying the low surrogate range:
0b11011100
0b1101
The mask
0b1100
seems appropriate here, too. How convenient. This smells of intelligent
design, doesn't it? ;-) So 0xfc00 should be used both for low and high
surrogates to properly tell them apart with the additional bit.
I'm attaching a revised patch that should enter mpg123 trunk shortly.
Feel free to yell and show the error in my current reasoning …
Alrighty then,
Thomas
Index: src/libmpg123/id3.c
===
--- src/libmpg123/id3.c (Revision 3642)
+++ src/libmpg123/id3.c (Arbeitskopie)
@@ -1051,10 +1051,10 @@
for(i=0; i < n; i+=2)
{
unsigned long point = ((unsigned long) s[i+high]<<8) + s[i+low];
- if((point & 0xd800) == 0xd800) /* lead surrogate */
+ if((point & 0xfc00) == 0xd800) /* lead surrogate */
{
unsigned short second = (i+3 < l) ? (s[i+2+high]<<8) + s[i+2+low] : 0;
- if((second & 0xdc00) == 0xdc00) /* good... */
+ if((second & 0xfc00) == 0xdc00) /* good... */
{
point = FULLPOINT(point,second);
length += UTF8LEN(point); /* possibly 4 bytes */
@@ -1077,7 +1077,7 @@
for(i=0; i < n; i+=2)
{
unsigned long codepoint = ((unsigned long) s[i+high]<<8) + s[i+low];
- if((codepoint & 0xd800) == 0xd800) /* lead surrogate */
+ if((codepoint & 0xfc00) == 0xd800) /* lead surrogate */
{
unsigned short second = (s[i+2+high]<<8) + s[i+2+low];
codepoint = FULLPOINT(codepoint,second);
pgpqDpi42mv8d.pgp
Description: Digitale Signatur von OpenPGP
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [mpg123-users] mpg123 version 1.22.4, re-enabling free format support
Am Wed, 12 Aug 2015 07:59:10 +0200 schrieb Thomas Orgis : > with mpg123 version 1.14.1, free format support got broken by a bugfix. This regression bugs me so much that I prepared a little script to fix it for any affected version you may have on your system with some reason preventing you from simply upgrading. So, here it is: http://mpg123.org/download/mpg123-fix-freeformat-1.14.1-to-1.22.3.sh for future reference, also attached. I hope operating system distribution maintainers will pick this up to avoid having folks locked in suboptimal mpg123 functionality for whole distribution release cycles. Alrighty then, Thomas mpg123-fix-freeformat-1.14.1-to-1.22.3.sh Description: application/shellscript pgpNBWsTyqNHD.pgp Description: Digitale Signatur von OpenPGP ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [mpg123-users] mpg123 version 1.22.4, re-enabling free format support
Am Thu, 13 Aug 2015 15:18:26 +0200 schrieb forum::für::umläute : > while i haven't followed the bug that required a fix that breaks > functionality you need, it seems to me that the correct solution would > be to spend time fixing the regression (while at the same time keeping > the fix for the original bug intact). To clarify: This was me, mpg123 upstream, following-up to the announcement of the new release on the mpg123-users list that fixes the regression (1.22.4), precisely because … > and distributions will hopefuly distribute the fixed version (without > the regression), rather than an outdated version. … distributions tend to keep the old base version of packages around and carry patches where it is deemed necessary. In the case of Debian, this affects wheezy (oldstable): mpg123 1.14.4-1 jessie (stable):mpg123 1.20.1-2 stretch (testing): mpg123 1.22.2-1 I suppose stretch will upgrade to 1.22.4 soon-ish, but wheezy and jessie likely want to stay on the 1.14.x and 1.20.x feature series. That's about exactly the range of versions affected by the regression, so I provided a little script to make patching them up easy. It's a 3-line change, but a plain patch would differ subtly between the versions. While my policy is to keep each new mpg123 superior and compatible to the previous version, it is exactly the case of unintended regressions that can creep in that still gives a good argument for not always going with the latest & greatest. Even an actual undisputed improvement in user behaviour might not be wanted when the promise to the user is that things are stable and do not change where it is not required to fix bugs / vulnerabilities. Alrighty then, Thomas pgpCWMlnKd2QM.pgp Description: Digitale Signatur von OpenPGP ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#800312: RFH: unpaper -- post-processing tool for scanned pages
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I request assistance with maintaining the unpaper package in Debian. When the unpaper 6.1 is built in Debian unstable against ffmpeg it fails to load the png files from its own tests folder. I already filled an upstream bug about this: https://github.com/Flameeyes/unpaper/issues/39 Upstream however seems to be unresponsive ATM and my C skills are very rusty. :-( I suspect that there's some incompatibility between ffmpeg and libav. Upstream builds against libav and in Debian we use ffmpeg. Thank you, Thomas Koch -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWCB7nAAoJEAf8SJEEK6Za0OAP/RqPFKq4EUcpdegW8UHCZCnD wPeJk6lwSz0ikDw9kXti3n6WBetr1A8ufjWFraLGB2bxiT6zopemldCNmRjLarlz CpS49reFC0YuUUQNrDuIlO/Gxl4egYhSkR5O+FrsRNZZP6h8pRVlNRXaMLFx+LIn aJ3P0mqr8od7bUbzc8q1ziOtahDhLPE4sERm4CICyYijlY9jG6ac/1XZEYxDKyvp ST1yOTveACD6NNMgPLd1qs3JWgOi8BOl2asr+Qu4dc7HJddVU0s7p4+TxaxgRBXc C3tpnbgOlmWgroRacxO7mVYvUOxIfR3LomQul1Tfx6NCjDROKgy2V9weNLnEg7N4 DPWvwsKM2Oa9Y7QeKOcWdrpVZ1lbOOh0KaeMyoJXJmd9KQq4j+39C1iHDwBReXq8 WYfiaWEVZSD9YRFcWXRu3Dll8qSjHUYIjbb6ae3Q5EPJnRFQm2W09LUMJv3ExkNc Kn660lxE+DAJERuZENnaL9Cx98jvBNTTK7i8DyDAxU70xTvAEgzEU4uuJbVLLh4k NFjkXKv5i9CUqnahwUaQrekQO8am/rzYtgZ+yxgN1zFbobbh1AJ+lnu0L6a+vwrQ ijt6k+CJWCMM7QJNeLex96B7vRecIv9TQi/R9DU+qimDGt4l9vG0fUUFpOOaaUHZ S10eq2qMkaCJ/TZaxXrN =Dy4g -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#829434: mpg123 segfaults once after dist-upgrades
Am Sun, 3 Jul 2016 12:14:40 +0200 schrieb Marco d'Itri : > mpg123 --random --quiet --control --title ... > > [jack.c:252] error: Failed to open jack client: 0x1 > [jack.c:58] warning: FIXME: One needs to wait or write some silence here to > prevent the last bits of audio to vanish out of the ringbuffer. > (segfault here) This looks like the jack output module crashing, a bug in itself, that might be fixed in the current upstream mpg123. Your main issue is that the proper output module, alsa in this case, fails to work. What is the output of mpg123 -o alsa [your flags] ? By enforcing the output module, you should get a view on the error messages. Of course, since you cannot reproduce the issue, we won't get a definite answer right away, but at least you'll get rid of the segfault if you always fix the output to alsa. > If I try again after this error then it works fine. > I do not have jack installed. But you do have libjack0 installed. So the jack output module loads, but fails later on. Without that lib, mpg123 would not even try to connect to jackd. It should not be a dependency but an suggestion, just like jackd itself. Hint to the debian maintainer: Generally, all audio output libraries are only accessed when the respective module is loaded. So, all of those are suggested packages only. No need to pollute user's systems with libopenal or libpulse0 if they do not intend to actually use those. Especially in the case of libjack0, there is no use having it installed as dependency if there is no server avaialable. Alrighty then, Thomas (mpg123 upstream) pgpARlOMr0nKv.pgp Description: Digitale Signatur von OpenPGP ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#829434: mpg123 segfaults once after dist-upgrades
Am Sun, 3 Jul 2016 13:32:20 +0200 schrieb Marco d'Itri : > > mpg123 -o alsa [your flags] > I see no new/specific output by adding -o alsa. You still see the jack errors and get a segfault? Are you able to create a backtrace? (`ulimit -c unlimited` before running mpg123 and then analysing the core file with gdb)? Alrighty then, Thomas pgp0Du025y5FY.pgp Description: Digitale Signatur von OpenPGP ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60
Package: mpg123
This is mpg123 upstream formally informing you of a vulnerability
(crash on illegal memory read) in all mpg123 versions since 0.60, so
very likely all debian versions of mpg123 and libmpg123 are affected.
See more detail at http://mpg123.org/bugs/240 . A one-line fix for any
version is this:
perl -pi -e 's:(while\()(tagpos < length-10\)):${1}length >= 10 && $2:'
$(find src -name id3.c)
Alrighty then,
Thomas
pgpUrR5qNiISt.pgp
Description: Digitale Signatur von OpenPGP
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60
Am Tue, 27 Sep 2016 10:27:04 +0100 schrieb James Cowgill : > Does this have a CVE ID? If not it should get one. I wondered about that. At the moment I just acted on the bug report and pushed the fix. I have to personal experience with the CVE procedure. In the past, just "someone" made them appear. I tried to apply for a CVE using the horrific Google docs form (http://iwantacve.org/) now. How can they resort to such a third-party ECMAScript-fest instead of a simple HTML form for _security_ issue reporting?! Not sure if/when I'll get a response to that. Alrighty then, Thomas pgpCvisWpxPAK.pgp Description: Digitale Signatur von OpenPGP ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
