Bug#859761: closed by Sebastian Ramacher <sramac...@debian.org> (Bug#859761: fixed in libdvd-pkg 1.4.1-1-1)
Thanks, Sebastian. The diff shows a couple of newlines inside the new CAPSH string that were intended to be spaces; I should know better than to embed source code in emails, but it should still work so meh. ___ 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#872361: Info received (Bug#872361: mpg123 misparses IPv6 address + port in http_proxy)
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-maintainers
Bug#872361: mpg123 misparses IPv6 address + port in http_proxy
Am Sun, 03 Sep 2017 20:07:43 + schrieb Ivan Shmakov <i...@siamics.net>: > > 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 the other way around > now; for instance: Indeed. Please test the updated preview tarball. Alrighty then, Thomas pgp_BqNm2zMem.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-maintainers
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 svn://scm.orgis.org/mpg123/tags/1.25.6 svn://scm.orgis.org/mpg123/tags/1.25.7 to back-port things. There is an additonal fix in there regarding MPEG 2.x decoding that is a good idea to have. Ivan, can you test your two issues with the preliminary release and give feedback before I make it official? Alrighty then, Thomas pgpVFtU1qCxHK.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-maintainers
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 TERM=dumb. The second variant will appear in the bugfix release 1.25.7, as I indeed consider it a behaviour fix, while the added option will appear in the next feature release. I suggest that we at least backport the TERM=dumb change to debian. Alrighty then, Thomas pgpG_bPXcWf2R.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-maintainers
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 weeks. Just so you know .. Alrighty then, Thomas -- Sent from somewhere out there.___ 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#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 off is the display of the progress bar in reverse video. I could possibly improve the behaviour around that. I am not able to work on this for about two weeks ... but will, eventually. I still would very much avoid linking to ncurses or the like for these simple functions, though. 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#866860: mpg123: CVE-2017-10683
Am Sun, 02 Jul 2017 11:12:36 +0200 schrieb Salvatore Bonaccorso <car...@debian.org>: > 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 creation of a CVE for that, although I wouldn't have bothered myself and also the description seems overly dramatic. So far I have only seen valgrind and an enabled AddressSanitizer complaining. In practice, I did not see one crash because of this in normal builds. This is one byte read too much, but to get denial of service, that extra byte should be outside mpg123's address space. That does not strike me as very likely in this context. Maybe one can construct such a case, but the test bitstream I got doesn't do it. Even if that one byte too much is successfully read and finds its way into a string buffer, my paranoia had me explicitly append an (additional) zero after it anyway. I'd phrase the last CVE sentence as: A crafted input will lead to a remote denial of service attack if the user asked for it by enabling compiler instrumentation. ;-) That being said, I won't claim that it is impossible to craft a file that would trigger serious invalid reads (p.ex. by an strlen() in an adjacent code path, _not_ in the text processing the triggered test case covers), and possibly actual DoS instead of possibly just sligthly bogus ID3 data from invalid input. I just havent's seen it yet. Anyway, the officially fixed version 1.25.1 will be released today/night. So you might want to just update to that one instead of pulling out the single patch. I am still waiting for a complete report for another issue that I'd like to fix in the release, too. Alrighty then, Thomas pgpD6zg0OaqBP.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#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 > @I ID3v2.year:2017 > @I ID3v2.comment:whatever > @I ID3v2.genre:some_style > @P 1 > FORMAT > @FORMAT 44100 2 > pause > @P 2 > main: [src/mpg123.c:809] error: Deep trouble! Cannot flush to my output > anymore! > 08:09|sturbolzen:~$ This should be fixed in the upcoming 1.25.0. Please test the https://mpg123.org/snapshot . $ src/mpg123 -R -o test @R MPG123 (ThOr) v8 lp /home/thomas/daten/projekte/mosin_nagant/forced_to_kill_thor.mp3 @I forced_to_kill_thor @P 1 format @FORMAT 44100 2 p @P 2 @S 1.0 3 44100 Stereo 0 417 2 0 0 0 128 0 0 @F 0 7335 0.00 191.61 @F 0 7335 0.00 191.61 @F 1 7335 0.03 191.61 @F 2 7334 0.05 191.58 @F 3 7333 0.08 191.56 I finally resorted to introducing new API to libmpg123 to avoid the interference of FORMAT with the main playback loop. Alrighty then, Thomas pgp7yHLSciiq3.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#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 <alfred.g.schm...@gmail.com>: > 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?)! > > [mpg123.c:681] error: Deep trouble! Cannot flush to my output anymore! 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.comment:whatever @I ID3v2.genre:some_style @P 1 FORMAT @FORMAT 44100 2 pause @P 2 main: [src/mpg123.c:809] error: Deep trouble! Cannot flush to my output anymore! 08:09|sturbolzen:~$ This is something generic in the output part, having survived into libout123. I need to look into this and will make a fix part of the 1.24.1 release. The change should be not too difficult to back-port. Alrighty then, Thomas pgpLGOco5gGO9.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#859761: libdvd-pkg: dpkg-buildpackage fails without libcap2-bin
Package: libdvd-pkg
Version: 1.4.0-1-2
Severity: normal
Tags: patch
Dear Maintainer,
After installing libdvd-pkg without the recommended libcap2-bin package
also installed, dpkg-reconfigure libdvd-pkg failed as follows:
libvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.0.orig.tar.bz2: OK
libdvd-pkg: Unpacking and configuring...
libdvd-pkg: Building the package... (it may take a while)
libdvd-pkg: Build log will be saved to
/usr/src/libdvd-pkg/libdvdcss2_1.4.0-1~local_amd64.build
dpkg-buildpackage: error: unknown option or argument
>/usr/src/libdvd-pkg/libdvdcss2_1.4.0-1~local_amd64.build
Use --help for program usage information.
Tracked this down to the following lines inside
/usr/lib/libdvd-pkg/b-i_libdvdcss.sh:
BUILDCMD="dpkg-buildpackage -b -uc >${BUILDLOG} 2>&1"
CAPSH=$(which capsh) \
&& ${CAPSH} --secbits=0x14
--drop=cap_dac_read_search,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog-ep
--print \
-- -c "${BUILDCMD}" \
|| ${BUILDCMD}
The issue is that when CAPSH doesn't get defined because $(which capsh)
fails, the fallback is for ${BUILDCMD} to be expanded as a command. But
redirects are processed before parameter expansions, so the redirects
inside BUILDCMD end up passed to dpkg-buildpackage as arguments instead
of doing what they're supposed to.
Replacing the CAPSH= command line with the following fixes the issue:
CAPSH="$(which capsh) --secbits=0x14
--drop=cap_dac_read_search,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog-ep
--print --" || CAPSH=/bin/bash
${CAPSH} -c "${BUILDCMD}"
That way, BUILDCMD always gets passed to /bin/bash as a complete command
line so its embedded redirects will work whether capsh exists or not.
Having CAPSH fall back to /bin/sh also works, but the docs for capsh
explicitly specify /bin/bash as the shell its -- option invokes, so
using it for the fallback seems like the Right Thing.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libdvd-pkg depends on:
pn build-essential
ii debconf [debconf-2.0] 1.5.60
pn debhelper
pn dh-autoreconf
ii wget 1.18-5
Versions of packages libdvd-pkg recommends:
ii libcap2-bin 1:2.25-1
libdvd-pkg suggests no packages.
-- debconf information:
libdvd-pkg/upgrade:
* libdvd-pkg/build: true
* libdvd-pkg/post-invoke_hook-remove: false
* libdvd-pkg/post-invoke_hook-install: true
libdvd-pkg/title_b-i:
libdvd-pkg/title_u:
* libdvd-pkg/first-install:
___
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#850467: kodi: Wrong "device" path for lirc
> Looking closer at kodi it turns out it has a -l /--lircdev CLI option. > problem solved. This also means that thomas can walk-around the problem > by configuring kodi instead of using the symlink. Yes and that is the way I do it right now. This is for me the save way to solve future changes. ___ 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#850467: kodi: Wrong "device" path for lirc
Package: kodi Version: 2:17.0~beta6+dfsg1-1 Severity: normal Dear Maintainer, kodi is hard coded to the wrong "device" path to lirc. The binary tries /dev/lircd but the "device" (which is a socket!) can be found at /var/run/lirc/lircd. - write ~/.kodi/userdata/Lircmap.xml according to working irw data - start kodi expected: - IR remote works actual behavior: - IR does not work some debugging: - ln -s /var/run/lirc/lircd /dev/lircd - start kodi again then: IR remote works - rm /dev/lircd - kodi -l /var/run/lirc/lircd then: IR remote works because the socket is put to /var/run/lirc/lircd by the lirc package it should also be hard coded to this position in kodi.bin -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kodi depends on: ii kodi-bin 2:17.0~beta6+dfsg1-1 ii kodi-data 2:17.0~beta6+dfsg1-1 Versions of packages kodi recommends: ii kodi-visualization-spectrum 1.1.0-1 kodi 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#849263: kodi-pvr-vdr-vnsi: New 17.beta needs a new API (again)
Package: kodi-pvr-vdr-vnsi Version: 2.6.7-1 Severity: normal Dear Maintainer, activating the vnsi add on fails with unstable kodi: ERROR: PVR - Add-on 'VDR VNSI Client' is using an incompatible API version. XBMC minimum API version = '5.2.1', add-on API version '5.2.0' -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kodi-pvr-vdr-vnsi depends on: ii kodi 2:17.0~beta6+dfsg1-1 ii libc6 2.24-8 ii libgcc1 1:6.2.1-5 ii libgl1-mesa-glx [libgl1] 13.0.2-1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libp8-platform2 2.0.1+dfsg1-2 ii libstdc++66.2.1-5 kodi-pvr-vdr-vnsi recommends no packages. kodi-pvr-vdr-vnsi 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#843096: kodi-pvr-vdr-vnsi: Incompatible xbmc API version for 17.beta
Package: kodi-pvr-vdr-vnsi Version: 1.11.15-1 Severity: normal Dear Maintainer, with upgrade to 17.0~beta5 this addon does not work anymore. Log output: ERROR: PVR - Add-on 'VDR VNSI Client' is using an incompatible API version. XBMC minimum API version = '5.2.0', add-on API version '4.1.0' At the frontend: * select tv * (No pvr addon enabled dialog -> Ok) * Select Enter add-on browser * Select VDR Vnsi Client * (if not done in former version:) Config server settings * Select Activate Expected: * TV database is setup * You can play vdr stuff Actual behavior: * Dialog: Add-on could'nt be loaded (check the log) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kodi-pvr-vdr-vnsi depends on: ii kodi 17.0~beta5+dfsg1-1 ii libc6 2.24-5 ii libgcc1 1:6.2.0-10 ii libgl1-mesa-glx [libgl1] 12.0.3-3 ii libp8-platform2 2.0.1+dfsg1-2 ii libstdc++66.2.0-10 kodi-pvr-vdr-vnsi recommends no packages. kodi-pvr-vdr-vnsi 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#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 <car...@debian.org>: > 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 don't know what is the usual duration here. Maybe my reply got dropped as it was sent from the account behind maintai...@mpg123.org, wich is only a forwarder. Dunno how to proceed. Alrighty then, Thomas pgprojsveYv_p.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: 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 > > It has been closed by Sebastian Ramacher <sramac...@debian.org>. Are the packages for stable/oldstable also being fixed? Alrighty then, Thomas pgpqtkULAAic6.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 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 got a reply now from the distributed weakness reporting project and probably a CVE will follow. Sorry if I'm causing a mess with this. It is my first time getting involved in this directly. Alrighty then, Thomas pgpiT5Bx0jvTM.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 <jcowg...@debian.org>: > 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
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#829434: mpg123 segfaults once after dist-upgrades
Am Sun, 3 Jul 2016 13:32:20 +0200 schrieb Marco d'Itri <m...@linux.it>: > > 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#829434: mpg123 segfaults once after dist-upgrades
Am Sun, 3 Jul 2016 12:14:40 +0200 schrieb Marco d'Itri <m...@linux.it>: > 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#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#819388: libclam-qtmonitors1.4: Typo in the package description
Package: libclam-qtmonitors1.4 Severity: minor Dear Maintainer, I noticed a typo in the package description while translating it. In the second paragraph, one can indeed read "… the plugins for the for adding …". I believe the extra "for the" should be removed. Thanks for your work on clam-networkeditor, Thomas -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (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 Init: sysvinit (via /sbin/init) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
ATTENTION
-- With due respect, I am Mr.Alan Thomas, and i worked for South Coast Inc Kuala Lumpur Malaysia, a fund investment sub under Capital One Bank. We handle major investment security funds deposit, for regular and some high profile customers under Capital One Bank. And we handle Investors Treasury Bill Deposit which gives most bankers access to trade with Investors funds some time, on private arrangement. And a special and high profile investor whom i managed his file before i retired is now trusting me to find a suitable and capable partner to manage his security fund deposit in a physical investment project. I would love to discuss details if you are interested as it will greatly benefit you.I look forward to your earnest response and further discussion about the proposal. For more information please contact me. Thanks as i anticipate your understanding and cooperation. With Regards, Mr. Alan 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#818083: Makes noise instead of playing music
Am Sun, 13 Mar 2016 17:39:38 +0100 schrieb Shérab <sebastien.hinde...@ens-lyon.org>: > 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 of encodings (and rates, channel modes) the output module supports and you also see what choice mpg123 makes. > Am I correct that the fact that it works with two modules makes this > test un-necessary? So pulse and OSS work. I presume you are running Pulseaudio, then? Interesting that the OSS emulation works and the access via ALSA not. That reminds me of the times where it was easier to get working audio through ALSA drivers by using the OSS emulation offered by them. Hm, are we now dealing with OSS emulated by ALSA which in turn routes to Pulse? Or, don't you have pulseaudio normally running and mpg123 starts its own instance (it does that in the background if no server found)? Then it's indeed the old game of ALSA OSS emulation working better than ALSA:-/ Verbose mpg123 output might give a hint about problematic settings. You can enforce an encoding via $ mpg123 -e $encoding (see `mpg123 --longhelp |grep encoding` for choices). If things work with s16, but not with s32, for example, that might be a hint. If you can turn off pulseaudio / don't have it running, trying hardware access via ALSA might be fruitful: $ mpg123 -o alsa -a hw:0,0 The libasound software layers might get something wrong. > x86_64. > > > 2. Which decoder is used? So, either the x86-64 SSE or the AVX one should be it. But that is the same regardless of output method, so … > So my understanding is that it is the wrong decoder which is chosen, > right? … not really. Or, maybe: The output encoding constraints may select a different decoding path (specific routines for output encodings). Please re-do a test with $ mpg123 --cpu generic -o alsa If that suddenly works, we got probably got an issue with a specific output format's optimised code path. If not, we can rule out the decoders and it is really something going wrong later, in transfer. An off-by-one error in a bytestream makes for nice noise. But, most importantly: If you noticed that the Pulse output works for you, you might just use that and forget the weirdness. I gave up understanding every audio output weirdness. I'm fairly confident in that mpg123 itself is not to blame. Fairly. Alrighty then, Thomas pgp7TItFDu3N0.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#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 one can then be tested with other software or just looked at in a waveform display (p.ex. playback with aplay, visualisation in audacity, mhwaveedit, sox, …). The choice of encoding and optimised decoder mal also matter. Actually, that might be the first stop: 1. What platform is this (x86-64, ARM, MIPS)? 2. Which decoder is used? Question 2, and also some of the above, is best answered by a copy of the terminal printout of $ mpg123 -vvv - < /dev/null Such lines at the beginning already tell much: Decoder: x86-64 (SSE) Trying output module: alsa, device: Using default module dir: /usr/lib/mpg123 Module dir: /usr/lib/mpg123 Module path: ./output_alsa.so Chosen output module: alsa Further information regards the chosen output format. When every file sounds like rubbish, I presume you either hit an issue with the decoder optimisation or the output system (any part of that chain). Alrighty then, Thomas pgpdMNXJLHcjj.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#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 out an issue in the decoder binary is to write a WAV file: $ mpg123 -w output.wav input.mp3 This one can then be tested with other software or just looked at in a waveform display (p.ex. playback with aplay, visualisation in audacity, mhwaveedit, sox, …). The choice of encoding and optimised decoder mal also matter. Actually, that might be the first stop: 1. What platform is this (x86-64, ARM, MIPS)? 2. Which decoder is used? Question 2, and also some of the above, is best answered by a copy of the terminal printout of $ mpg123 -vvv - < /dev/null Such lines at the beginning already tell much: Decoder: x86-64 (SSE) Trying output module: alsa, device: Using default module dir: /usr/lib/mpg123 Module dir: /usr/lib/mpg123 Module path: ./output_alsa.so Chosen output module: alsa Further information regards the chosen output format. When every file sounds like rubbish, I presume you either hit an issue with the decoder optimisation or the output system (any part of that chain). Alrighty then, Thomas pgpmHDLq1KJCg.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
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 thomas-fo...@orgis.org: 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 zmoel...@umlaeute.mur.at: 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#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 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
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#782120: Upstream has released a fixed version.
We've released 2.4.2, which fixes this and should also address possible other similar issues. http://lists.xiph.org/pipermail/icecast-dev/2015-April/002460.html We're currently waiting for the CVE ID from MITRE. Thanks again to Juliane for bringing this up and discussing further details with us. Thomas B. Rücker Icecast maintainer ___ 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#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#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 z...@debian.org (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#764374: libgroove: FTBFS on hurd-i386
Hi! On Tue, 07 Oct 2014 18:42:06 +0200, Svante Signell svante.sign...@gmail.com 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#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#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#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
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 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 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 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 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 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 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#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, 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
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 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 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 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 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 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 t...@mac.com:
#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 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
^
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 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 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
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
) 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 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 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: 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
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#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
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š mira.mi...@gmail.com 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 tnagy1...@gmail.com 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
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 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 EOT
-##ifdef $name
-##undef $name
-##endif
+$type NATIVE_NAME($name)($args);
$type attribute_align_arg ALIAS_NAME($name)($args)
{
return NATIVE_NAME($name)($nargs);
@@ -97,162 +100,123 @@
}' mpg123.h.in
*/
-#ifdef mpg123_open
-#undef mpg123_open
-#endif
+int NATIVE_NAME(mpg123_open)(mpg123_handle *mh, const char *path);
int attribute_align_arg ALIAS_NAME(mpg123_open)(mpg123_handle *mh, const char *path)
{
return NATIVE_NAME(mpg123_open)(mh, path);
}
-#ifdef mpg123_open_fd
-#undef mpg123_open_fd
-#endif
+int NATIVE_NAME(mpg123_open_fd)(mpg123_handle *mh, int fd);
int attribute_align_arg ALIAS_NAME(mpg123_open_fd)(mpg123_handle *mh, int fd)
{
return NATIVE_NAME(mpg123_open_fd)(mh, fd);
}
-#ifdef mpg123_open_handle
-#undef mpg123_open_handle
-#endif
+int NATIVE_NAME(mpg123_open_handle)(mpg123_handle *mh, void *iohandle);
int attribute_align_arg ALIAS_NAME(mpg123_open_handle)(mpg123_handle *mh, void *iohandle)
{
return NATIVE_NAME(mpg123_open_handle)(mh, iohandle);
}
-#ifdef mpg123_decode_frame
-#undef mpg123_decode_frame
-#endif
+int NATIVE_NAME(mpg123_decode_frame)(mpg123_handle *mh, lfs_alias_t *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
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.
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)(mh, frameoff
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 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
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 + 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
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
Re: updating OpenNI Debian packages
On Wed, May 22, 2013 at 5:03 AM, Hans-Christoph Steiner h...@eds.org 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#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 c --encoding c 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
Bug#702063: ices2: New upstream release available: 2.0.2
Package: ices2 Severity: normal Tags: patch Dear Maintainer, Ices 2.0.2 was released last august, please update the Debian package. Looking at the changelog it seems that #255417 should be fixed there too. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) ___ 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 thomas.scho...@gmail.com 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 nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com 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- TAbort- MAbort- SERR+ PERR- INTx- Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME- DevSta:CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkSta:Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- CESta:RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ Status:InProgress- Status:NegoPending- InProgress- root@tom3:~# Some non-fatal pci errors, but lspci is usually reporting incorrectly here or my old pci-e host is pretty incompatible. So no technical reasons to drop the package? y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org
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
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 nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com 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
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
Bug#661922: Can I get a debug log for this build ?
Run the testsuite with RIP_DEBUG=5 I also think this is probably fixed in 0.2.0 and related to a bad audioparsers plugin in GStreamer. Thomas -- - Are you OK ? - Yes, I'm fine. The shaking's just a side effect of the fear. Moovida - future TV today ! http://www.moovida.com/ ___ 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#673284: this was fixed in 0.1.3
-- as far as I'm concerned time is the state of my jeans URGent, best radio on the net - 24/7 ! http://urgent.fm/ ___ 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.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#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, --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
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 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 21 | 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 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 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 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 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#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#680101: mpg123: writing wav to stdout still works ugly
Am Wed, 4 Jul 2012 14:25:56 +0400 schrieb dimas dimas...@ya.ru: 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#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#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#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#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 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
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 /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 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 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(ret0)
{
@@ -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(ret0) 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#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 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#670236: mplayer2: can't play video with resolution of 2542x1080
Am 07.05.2012, 18:49 Uhr, schrieb Roland Scheidegger rscheidegger_li...@hispeed.ch: 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#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#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 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 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#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#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#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 robo...@celest.fr
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 libavcodec/avcodec.h
#include libavutil/rational.h
+#include libavutil/mathematics.h
#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 libavformat/avformat.h
#include libavcodec/avcodec.h
#include libavutil/rational.h
+#include libavutil/mathematics.h
#include libswscale/swscale.h
#include libavcodec/opt.h
From 63b4c577c951245904fd59ac8c6021bab18b0de4 Mon Sep 17 00:00:00 2001
From: Antonio Ospite osp...@studenti.unina.it
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)({*|jhMpyWR#k60!#=#/Vb;]yA5GWI5`6u+
;6b'@y|8wwB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7jN3ah(m`ku?pX.+~:_/wC~dwn^)MizBG
!pE^+iDQQ1yC6^,)YDKkxDd!T\I~93J_`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 osp...@studenti.unina.it
---
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 libavutil/avstring.h
+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
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 none (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 library ii libgcrypt11 1.4.5-2
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
