Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

Am Thu, 4 Apr 2024 09:36:37 +0200 schrieb Sebastian Ramacher : > Now I get the following on arm{hf,el}: > > --- debian/libmpg123-0.symbols (libmpg123-0_1.32.6~dev+20240403022201-1_armhf) > +++ dpkg-gensymbolspYII3c 2024-04-03 09:52:12.863133592 + > @@ -8,8 +8,8 @@ >

Bug#1067562: FTBFS: missing symbols on 32-bit architectures

Am Wed, 03 Apr 2024 20:46:29 +0200 schrieb Simon Chopin : > I just uploaded the attached debdiff to Ubuntu to both fix the FTBFS and > start the t64 transition for this package, based on the following > comment: Are you able to test this for the dev snapshot of mpg123 before I do the next

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

Hi again, (after Easter hiatus … or rather xz backdoor meltdown?) I had a stab at this, detecting a system that forces 64 bit offsets on a 32 bit base in configure. This is to ensure that you do not encounter the same symbol (like mpg123_tell() on two builds of the library on the same platform

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

Hi Sebastian, thanks for not escalating on the anger that has shown through the end of my last reply. It really seems to be an endless stream of pain that results from once having put off_t into public API. This is the message I have to any developer: Do not put types into your API that could

Bug#1067562: FTBFS: missing symbols on 32-bit architectures

Am Sat, 23 Mar 2024 21:59:54 +0500 schrieb Andrey Rakhmatullin : > Source: mpg123 > Version: 1.32.5-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=mpg123=armel=1.32.5-1%2Bb1=1711185338=0 This is being discussued in

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

Hi Sebastian, Am Sat, 23 Mar 2024 10:40:43 +0100 schrieb Sebastian Ramacher : > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base > 1.13.7 > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_feedseek_32@Base 1.13.7 > +#MISSING: 1.32.5-1+b1# >

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

Am Mon, 05 Feb 2024 08:36:28 + schrieb Steve Langasek : > we have identified > mpg123 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side

Bug#819666: Hack for disabling CriticalPowerAction

urgency=medium + + * hack it for not doing any critical action + + -- Thomas Orgis Fri, 21 Jul 2023 22:49:00 +0200 + upower (0.99.17-1) unstable; urgency=medium * New upstream version 0.99.17 Then: apt-get --build source upower dpkg -i upower_0.99.17-99thor_amd64.deb (match

Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)

I also sent this already directly to Joey, but later found this bug report. My take is this: --- /usr/bin/ts 2019-02-20 22:03:31.0 +0100 +++ ./ts2023-03-01 21:06:41.177886024 +0100 @@ -53,6 +53,7 @@ use strict; use POSIX q{strftime}; no warnings 'utf8'; +use open q{:locale};

Bug#1023493: libmpg123-dev: trying to overwrite shared '/usr/include/mpg123.h', which is different from other instances of package libmpg123-dev:i386

Am Sat, 05 Nov 2022 12:07:57 + schrieb Witold Baryluk : > trying to overwrite shared '/usr/include/mpg123.h', which is > different from other instances of package libmpg123-dev:i386 Oh, dear. I broke multiarch headers again. By trying to fix BSDs that don't react to _FILE_OFFSET_BITS at

Bug#963205: Next round

Great. I released 1.26.2 now so that the package here can be updated. pgpXAEbLMdip3.pgp Description: Firma digital OpenPGP

Bug#963205: Next round

I made a new snapshot now. The old one still had a conflict of off_t and lfs_alias_t in the suffix-less prototype. I hope this does it! https://mpg123.org/snapshot Verify?

Bug#963205:

Am Sun, 28 Jun 2020 22:16:13 +0200 schrieb Sebastian Ramacher : > Unfortunately the patch fails to build on i386: Darn. Of course, sorry. This is missing: Index: src/libsyn123/syn123.h.in === --- src/libsyn123/syn123.h.in

Bug#963205:

OK, I introduced the additional wrapper now with svn commit 4743 on svn://scm.orgis.org/mpg123 . You can test by using current https://mpg123.org/snapshot or by applying the attached patch. Test reports before I release (this weekend?) are welcome. Alrighty then, Thomas Index: NEWS

Bug#963205: Now … what should I do?

Am Thu, 25 Jun 2020 22:55:36 +0200 schrieb Sebastian Ramacher : > Other than x32, I'm not aware of any 32-bit arch that doesn't have > 32-bit off_t if _FILE_OFFSET_BITS is not set. So maybe architecture A sure-fire ruleset is different … > specific handling could be enough: if

Bug#963205: Now … what should I do?

Hey, I am on the path to release mpg123 1.26.2. So, how should I approach this one here? Can someone comment on my suggestions and possibly give a variant that works in the header without adding function wrappers? Alrighty then, Thomas

Bug#963205: libmpg123-dev no longer multiarch installable

Am Sun, 21 Jun 2020 11:23:32 +0200 schrieb Sebastian Ramacher : > I am wondering why syn123 and mpg123 use different approaches to achieve > the same thing. The mpg123-way of handling off_t using functions is > known to work and doesn't require any quirks on the Debian packaging > side. Why

Bug#963205: libmpg123-dev no longer multiarch installable

Am Sat, 20 Jun 2020 15:03:32 +0200 schrieb Christian Klein : > A diff of the header files reveals that the i386 and amd64 versions are now > different: > -#define syn123_resample_total syn123_resample_total_32 > -#define syn123_resample_intotal syn123_resample_intotal_32 > +#

Bug#949689: mpg123: please add temporary mute key

Well, as a special favour to Thorsten, I added the 'u' key now for the upcoming mpg123 1.26.0 to (un)mute in the audio backend, at the end of the optional buffer, so that it works immediately like pause. This was not as easy as it sounds, as I wrote the output library without detailed knowledge

Bug#949689: mpg123: please add temporary mute key

Hi, any special reason why this suggestion is not posted to the mpg123 bug tracker, or just even just mailed to upstream, but reported to the Debian project instead? Alrighty then, Thomas

Bug#930088: mpg123 plays back gibberish instead of music from mp3 files

Am Mon, 24 Jun 2019 22:54:23 + (UTC) schrieb Thorsten Glaser : > >I suspect the link from alsa to pulse is faulty, as mpg123's alsa output > >module > >has been working fine for a long time now using proper alsa. I just had some reproducable playback trouble on a Ubuntu 18.04 box and

Bug#930088: mpg123 plays back gibberish instead of music from mp3 files

Are you using the alsa output plugin with routing to pulseaudio? I remember this from Ubuntu systems. Running mpg123 -o pulse works, -o alsa plays static noise. Maybe some byte offset not aligned to the data type ... I suspect the link from alsa to pulse is faulty, as mpg123's alsa output module

Bug#872361: Info received (Bug#872361: mpg123 misparses IPv6 address + port in http_proxy)

And? Any confirmation of the fix? pgprqQo42wvpj.pgp Description: Firma digital OpenPGP

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

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=

Bug#872361: mpg123 IPv6 URL parsing and terminal behavior

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

Bug#872362: mpg123 disables cursor unconditionally on ttys

Am Thu, 17 Aug 2017 09:17:01 +0200 schrieb Thomas Orgis <thomas-fo...@orgis.org>: > 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

Bug#872362: mpg123 disables cursor unconditionally on ttys

(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

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

(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

Bug#866860: mpg123: CVE-2017-10683

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

Bug#862753: Fwd: mpg123 crashes in Remote mode if FORMAT command issued when file loaded but not started playback

Am Wed, 17 May 2017 08:13:32 +0200 schrieb Thomas Orgis <thomas-fo...@orgis.org>: > 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 >

Bug#862753: Fwd: mpg123 crashes in Remote mode if FORMAT command issued when file loaded but not started playback

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

Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

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.

Bug#838960: closed by Sebastian Ramacher <sramac...@debian.org> (Bug#838960: fixed in mpg123 1.23.8-1)

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

Bug#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 <thomas-fo...@orgis.org>: > 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

Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

Am Tue, 27 Sep 2016 22:39:21 +0200 schrieb Thomas Orgis <thomas-fo...@orgis.org>: > Well, so far I did not get a response from http://iwantacve.org/ 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 n

Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

Am Tue, 27 Sep 2016 18:50:35 +0200 schrieb Florian Weimer : > Debian is a CNA-covered product, mpg123 is part of Debian, > so it is unclear what to do here. I'll ask around. Well, so far I did not get a response from http://iwantacve.org/ (linked from

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

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

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

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

Bug#818083: Makes noise instead of playing music

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

Bug#818083: Makes noise instead of playing music

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

Bug#818083: Makes noise instead of playing music

[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

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 yum...@gmail.com: 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

Bug#751800: mpg123: i486 decoder broken

Am Mon, 16 Jun 2014 11:43:28 -0700 schrieb Simon Kirby s...@hostway.ca: (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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 04 Mar 2014 02:59:44 + schrieb peter green plugw...@p10link.net: 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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 4 Mar 2014 11:49:45 +0100 schrieb Thomas Orgis thomas-fo...@orgis.org: 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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 4 Mar 2014 11:10:25 -0300 schrieb Felipe Sateler fsate...@debian.org: #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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 4 Mar 2014 16:25:17 -0300 schrieb Felipe Sateler fsate...@debian.org: #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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma t...@mac.com: 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,

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma t...@mac.com: 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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Sat, 1 Mar 2014 09:56:46 +0100 schrieb Thomas Orgis thomas-fo...@orgis.org: 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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Mon, 24 Feb 2014 12:27:36 -0500 schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca: 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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

://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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 25 Feb 2014 11:20:06 -0500 schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca: 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 t...@mac.com: #0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Fri, 21 Feb 2014 11:25:12 -0500 schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca: 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

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Mon, 17 Feb 2014 10:00:48 +0200 schrieb Riku Voipio riku.voi...@iki.fi: 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

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

Bug#738981: Switch to use generic_fpu for ARM

Am Sun, 16 Feb 2014 12:14:46 -0500 schrieb Reinhard Tartler siret...@gmail.com: 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

Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

Am Sat, 31 Aug 2013 16:02:45 +0200 schrieb Reinhard Tartler siret...@gmail.com: 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

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 siret...@gmail.com: Thomas, may I have your opinion on this patch? If you are d'accord, I'd upload it to debian/unstable for further testing.

Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

Am Wed, 28 Aug 2013 01:33:08 +0200 schrieb Thomas Orgis thomas-fo...@orgis.org: 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

Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

Am Tue, 27 Aug 2013 23:49:08 +0200 schrieb Reinhard Tartler siret...@gmail.com: +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 +

Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

Am Thu, 22 Aug 2013 07:46:55 +0200 schrieb Reinhard Tartler siret...@tauware.de: 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.

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

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

Bug#689659: mpg123 segfaults on specific file

Am Mon, 8 Oct 2012 15:30:48 -0400 schrieb Miguel A. Colón Vélez debian.mic...@gmail.com: 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,

Bug#689659: mpg123 segfaults on specific file

Am Sat, 6 Oct 2012 13:07:55 +0200 schrieb Pavel Machek pa...@ucw.cz: 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

Bug#689659: mpg123 segfaults on specific file

Am Mon, 8 Oct 2012 13:39:26 -0400 schrieb Miguel A. Colón Vélez debian.mic...@gmail.com: 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

Bug#689659: mpg123 segfaults on specific file

Am Fri, 5 Oct 2012 22:06:49 +0200 schrieb Pavel Machek pa...@ucw.cz: 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

Bug#680101: mpg123: writing wav to stdout still works ugly

--- 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

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

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

Bug#677148: mpg123_getformat() hangs in endless loop

Am Tue, 12 Jun 2012 23:16:02 +0200 schrieb Thomas Orgis thomas-fo...@orgis.org: 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

Bug#677148: mpg123_getformat() hangs in endless loop

Am Mon, 11 Jun 2012 23:27:45 +0200 schrieb Max Kellermann m...@duempel.org: 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

Bug#677148: mpg123_getformat() hangs in endless loop

Am Tue, 12 Jun 2012 09:25:07 +0200 schrieb Max Kellermann m...@duempel.org: On 2012/06/12 09:20, Thomas Orgis thomas-fo...@orgis.org 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

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 p...@booyaka.com: 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

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

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

Bug#667653: mpg123 FTBFS on armhf

Am Fri, 6 Apr 2012 22:27:07 -0400 schrieb Miguel Colon debian.mic...@gmail.com: 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) \ snip Damn, you got me there! I

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

Bug#646391: mpg123: Hangs when the current directory no longer exists (and why don't I get told about that?)

Hi, once again, I'm idly browsing the debian bug reports about mpg123, actually wondering how I could bring you folks to update to the current stable version (especially before freeze for next debian stable) Now I see this bug and am a bit annoyed that no one bothered to bring this to my

Bug#664998: Too much CPU used

I cannot reproduce that on my personal box. I have a Duron at 800 MHz with debian squeeze on it. Running mpg123 -v needs around 1% of CPU! There must be something else going on. Also please note that nowadays, the audio output happily gobbles up way more CPU than mpg123 needs. An example is the

Bug#644851: Please update to latest upstream version 1.13.4 (now 1.13.7)

I, as upstream maintainer second that update request. It seems that Daniel, who did good work over all these years as debian maintainer of mpg123, is increasingly unavailable. Especially regarding the upcoming freeze for the next stable debian, I really would like to see this distro jumping to

Bug#516510: Info received (Fix in mpg123 rev 2770.)

I noticed a bug in the last revision... in non-utf-8 mode, the last character was chopped off. Revision 2771 and the updated snapshot are fixed in that respect. Alrighty then, Thomas. -- Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org) OrgisNetzOrganisation

Bug#516510: Fix in mpg123 rev 2770.

) if this version works for you. 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

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin/mpg123.bin: free(): invalid pointer: 0xb7c29098 ***

Am Sat, 22 May 2010 03:43:28 +0400 (MSD) schrieb William Pitcock neno...@dereferenced.org: This is due to a memory alignment issue in the way that the struct is packed. With some help from an affected user, we bisected it to mpg123 SVN r2491. OK, that revision replaced aligned memory blocks

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin/mpg123.bin: free(): invalid pointer: 0xb7c29098 ***

Am Sun, 23 May 2010 02:41:04 +0400 (MSD) schrieb William Pitcock neno...@dereferenced.org: Both. I believe this is caused by a bug where the pointers appear to become realigned twice (e.g. to the next 16 bytes.) So I believe the second realignment is a bug that has always been there. Though

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

Am Wed, 19 May 2010 22:40:08 +0200 schrieb gregor herrmann gre...@debian.org: The minimal change to make the crash go away is to remove -pie from LDFLAGS. So, we have some textrel issues, I suppose. I fail to see how mpg123 triggers that, though. One observation I have, again in a VM with

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

Poke, poke. Am Mon, 10 May 2010 22:54:15 +0200 schrieb gregor herrmann gre...@debian.org: Yup, my test results with the current (vanilla|debian) binary+lib are the same as yours but they are not necessarily the same as my original crashes, and yesterday I haven't systematically tested

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

Am Mon, 10 May 2010 21:23:59 +0200 schrieb Daniel Kobras kob...@debian.org: With drum.mp3, I'm now also seeing the segfault in an i386 chroot. amd64 is still fine. Building the Debian package with DEB_BUILD_OPTIONS=noharden (ie. without CFLAGS -Wformat -D_FORTIFY_SOURCE=2 -fstack-protector

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

I just added this to the mpg123 tracker item: I managed to reproduce a crash (no report of double free(), but a segfault during free()) on a VM install of debian testing, with mpg123 from unstable. The funny thing is that I observe the debian mpg123 binary crashing with the debian libmpg123 and

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

Am Sat, 8 May 2010 00:12:09 +0200 schrieb gregor herrmann gre...@debian.org: Summary: - pulse, arts, esd, jack, nas: I have no pulse audio/artsd/esd/jackd/nas daemon installed - dummy: fails - alsa: still fails - oss: hm, somethings blocking my sound device; ah. found it later. no

Bug#580095: libmpg123-0: *** glibc detected *** /usr/bin: free(): invalid pointer: 0xb7c29098 ***

Hi, this is mpg123 upstream. I asked for some confirmation of the confinedness of the issue to the ALSA output on http://sourceforge.net/tracker/?func=detailaid=2996045group_id=135704atid=733194 ... Actually, this concerns both issues: The crash and the high CPU usage. Can you try another

Bug#449319: This is most likely fixed in version 1.3.0 .

I asked about details a month ago... didn't get response:-( But the good news is that I discovered a basic problem with the ICY stream reader which was causing desync in the stream and subsequently reading utterly wrong bytes as ICY metadata (as there is no error check/recovery defined in ICY

Bug#468426: xmms2d is burning too much CPU while playing MP3

, I guess (like, being a more complex program). Alrighty then, Thomas (happening to be mpg123 maintainer, so a bit biased there;-). -- Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org) OrgisNetzOrganisation ---)=- http://orgis.org GPG public key D446D524: http

Bug#391669: modules in mpg123-1.x

that in future, mpg123 should support some way to set the default audio output at runtime, possibly by using an environment variable. Alrighty then, Thomas (mpg123 maintainer). -- Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org) OrgisNetzOrganisation ---)=- http

Bug#52020: You can (finally!;-) close this bug when upgrading to mpg123-1.x

...which includes a libmpg123 as shared library with a stable api: http.//mpg123.org/api 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

  1   2   >