And? Any confirmation of the fix?
pgpYa3PGX8RU9.pgp
Description: Firma digital OpenPGP
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-
Am Sun, 03 Sep 2017 20:07:43 +
schrieb Ivan Shmakov :
> > https://mpg123.org/test/mpg123-1.25.7.tar.bz2
>
> […]
>
> > Ivan, can you test your two issues with the preliminary release and
> > give feedback before I make it official?
>
> The IPv6 http_proxy= handling seems to be
I prepared fixes for both bug 872362 and 872361 for an upcoming mpg123
version 1.25.7. A preliminary release tarball is available via
https://mpg123.org/test/mpg123-1.25.7.tar.bz2
Since debian is working with 1.23.x, you might have a look at the
difference
svn diff svn://scm.orgi
Am Thu, 17 Aug 2017 09:17:01 +0200
schrieb Thomas Orgis :
> I am not able to work on this for about two weeks ... but will,
I made a change to mpg123 trunk now that
a) adds --no-visual option to diasable the behaviour and
b) disables it anyway when TERM=dumb.
The second variant will app
(mpg123 upstream here)
Oh. Thanks for noticing. It has been some time since IPv6 support has been
added, and frankly, the situation where I actually use IPv6 is rare. Specifying
a proxy without DNS is even more rare.
It is for sure easy to fix, but I won't be able to work on this for about two
(mpg123 upstream here)
Yes, the terminal support in mpg123 is rather basic. It does not consult any
caps database, just hopes that the simple controls it issued are universally
understood, which obviously works against your desire regarding the cursor.
The reason for switching cursor display of
Am Sun, 02 Jul 2017 11:12:36 +0200
schrieb Salvatore Bonaccorso :
> CVE-2017-10683[0]:
> | In mpg123 1.25.0, there is a heap-based buffer over-read in the
> | convert_latin1 function in libmpg123/id3.c. A crafted input will lead
> | to a remote denial of service attack.
I don't oppose the creati
Am Wed, 17 May 2017 08:13:32 +0200
schrieb Thomas Orgis :
> Confirmed with current upstream mpg123 1.24.0:
>
> $ mpg123 -R -o dummy
> @R MPG123 (ThOr) v8
> LP some_file.mp3
> @I ID3v2.title:some title
> @I ID3v2.artist:some band
> @I ID3v2.year:2017
> @I ID3v2.
Am Tue, 16 May 2017 09:42:57 -0700
schrieb Al Schmidt :
> pause/un-pause
> @P 2 // response: OK, playing
> file, but then...
>
> [alsa.c:230] error: Fatal problem with alsa output, error -5.
>
> [audio.c:614] error: Error in writing audio (Success?)!
>
Am Wed, 5 Oct 2016 21:34:49 +0200
schrieb Salvatore Bonaccorso :
> Any news from the DWF project on the assigned CVE?
Nothing. I got the initial request to accept the MITRE Terms of Use for
CVE from the person handling my case (I assume). I replied to the mail
at 2016-09-30. Nothing came back. I
Am Tue, 04 Oct 2016 10:03:10 +
schrieb ow...@bugs.debian.org (Debian Bug Tracking System):
> This is an automatic notification regarding your Bug report
> which was filed against the mpg123 package:
>
> #838960: denial of service with crafted id3v2 tags in all mpg123 versions
> since 0.60
>
Am Thu, 29 Sep 2016 01:20:05 +0200
schrieb Thomas Orgis :
> Still nothing. I don't expect anything to arrive anymore. Perhaps that
> Google Docs form was a joke anyway. So, please let's just get a number
> via Debian and get on with it.
Nope, eh … yes. I got a reply now f
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 appe
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
versi
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 c
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 ri
Am Sun, 13 Mar 2016 17:39:38 +0100
schrieb Shérab :
> So alsa makes noise, pulse and oss play music and I believe the others
> are not too relevant...
OK, that means that probably the decoding part is fine. Maybe you have
a problem with specific output encodings.
$ mpg123 -vvv
prints a table o
Hi, (mpg123 upstream here)
does the choice of output method matter? Check
$ mpg123 --list-modules
and try some in the given list using
$ mpg123 -o $output_module_name
The easiest check to rule out an issue in the decoder binary is to
write a WAV file:
$ mpg123 -w output.wav input.mp3
This on
[The first reply may have gotten into the wrong channels, resending
with correct reply addresses.]
Hi, (mpg123 upstream here)
does the choice of output method matter? Check
$ mpg123 --list-modules
and try some in the given list using
$ mpg123 -o $output_module_name
The easiest check to rule o
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 o
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 f
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
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
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:2
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
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
Am Tue, 04 Mar 2014 02:59:44 +
schrieb peter green :
> Is there any quality
> difference from using a fpu vs nonfpu decoder?
Technically, there is. See those numbers for generic fpu and non-fpu
code with and without --enable-int-quality given to configure (enables
better rounding for small
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/snapsh
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'
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
> disti
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_ne
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)
OrgisNetzOr
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 actual
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 i
I'm adding the mpg123 assembly guru to the CC list, as I imagine he
would be interested in why his ARM NEON code doesn't work on a Cortex
A8 chip here. Needless to say, it worked before (on other systems).
Also, the precision of the arm_nofpu code does not look right. This
topic is now shifting tow
> >> > 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 curren
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 t
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 boundar
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 hardw
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 s
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. T
(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 ne
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 hardc
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_DEFI
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
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 o
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 wr
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
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:
V
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. Soft
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 i
ith 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
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
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
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 b
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 m
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
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
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 i
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 thin
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 w
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 b
62 matches
Mail list logo
