Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote: Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Cheers, Julien signature.asc Description: 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
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Ciao, On Mon, Jul 28, 2014 at 9:44 AM, Julien Cristau jcris...@debian.org wrote: The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Rather I'd suggest to start reconsidering such switch for Jessie+1. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ 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#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. -- ciao, Marco signature.asc Description: 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
Re: Reintroducing FFmpeg to Debian
Andreas Cadhalpun wrote: * Do you intend to replace Libav by FFmpeg in Debian? No, there is no need to replace anything as long as it is maintained. Currently the main goal is to give multimedia maintainers a choice between the two sets of libraries to link against, and our users the choice to use the 'ffmpeg' utility. That is possible, because the packages are co-installable. (Only the *-dev packages conflict.) Hm, I wonder if this will work, see the JPEG discussion. But I'd *love* to see ffmpeg replace libav and to get my mplayer back, which is currently on hold. Thanks, //mirabilos ___ 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#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Julien, On 28.07.2014 10:44, Julien Cristau wrote: It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. I am not interested in a fight and would prefer it very much if this discussion remained purely technical. Having a fresh memory of the last fight that took place on debian-devel, I do not think that repeating a similar disaster is a good idea. We're not going to ship both and hand that mess over to the security team. Could you please explain what mess you are talking about? According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. Two of them (4:0.5.6-2 and 4:0.5.6-3) do not contain security related fixes, but rather fix build failures of the previous security upload, so they do not really count. That makes about 6 security fix uploads in about 3 years for squeeze, i.e. 1 upload per 6 month. If there were both forks in Jessie, this might double the number of uploads to 12 in 3 years, but probably some of them could also go through stable-updates instead of stable-security. Is that an unbearable burden? A lot of other software in Debian has already alternatives, like desktop environments, web browsers, text editors and even init systems. Why should this not be the case for a multimedia framework? There is also one particularly similar case, as in the packages are forks and require many security updates: MySQL and MariaDB are currently in Debian testing. Just for comparison, MySQL in squeeze had 3 uploads to stable-security and 3 to oldstable(-security) [2]. As I mentioned this particular example in my discussion with Moritz, he said that the security team will be working with the release team to sort this out for jessie[3]. Now, 5 months later, he seems to have changed his mind, as I am not aware of any such attempt, but instead Moritz seems to support both [4][5]. Thanks in advance for taking the time to answer these questions. Best regards, Andreas 1: http://metadata.ftp-master.debian.org/changelogs//main/f/ffmpeg/ffmpeg_0.5.10-1_changelog 2: http://metadata.ftp-master.debian.org/changelogs//main/m/mysql-5.1/mysql-5.1_5.1.73-1_changelog 3: https://bugs.debian.org/729203#435 4: https://bugs.debian.org/754940 5: https://bugs.debian.org/754941 ___ 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#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 personally i would welcome if both libav and ffmpeg could co-exist within Debian¹. as i see it, libav and ffmpeg have diverged, and as such i would like to have the choice which one to use. On 2014-07-28 11:55, Marco d'Itri wrote: On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. + 1 i don't think that dropping libav is appropriate at all. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. i would appreciate it, if you (and anybody else) used a less flammable | touchy language. fgmadr IOhannes ¹ but then i'm not a member of the security team :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT1jAxAAoJELZQGcR/ejb4DtoP/2jEpmxHblY7XX+mGoVT5I+c /Kr/VMwXv8glsbJhrEzgyJS0xaj6PONV0CL+pfoM7BzojK3LJQLza0aPs5u1ipLo +KqMOiK4WMNDk3YSnzZtYcGkM+vKN/bUZ3BF9b5HnBgCs/MI/hxInq52i6Ly6ESv TF6vfS/oUKyM1/PJAf5fiaZ5tegFBBc2QPYnK4ehSuDoT0IOhzxGmft7L5XTQJgU l3dwgYc7aKaDkiFthcXQjFiTuDynOEZtNfSt6CYouulNycNlue3ptMr+DA2exNzY RtpG/GY+lZnklEuHa+0Y/sfM2CBEJwJqSmvPmUXrg4vikDkjGBq0PhAc7D5OO8a0 0Z69wgyrGGCESdZAcTzbWTfKNi02X2kMDkrbDHiq9d605zh6XTYQqBPspVYkY3bW mne+wfu5UN/TK21nIDzV88NQEV9FJ4pQyJpU64Yj8hT2mXNetLps6eMAJJobNby6 xz4Mw3QkNkamy3/vZD+SlYyv1a/K23mY4rkE2JXX0RD6xdMa5RxUuvkWfvJbI1S/ MNAo5eag+RVVHNo1n/p9JliSFYUJFhrkrQy/giyPeBDoNP/yNrmYoxBxmGuMWSu8 Mr/NjfSF9tJ47E1dDmJ+i6YKmyDm0uwqX+oaWo7sS1Ag78RrkVjlP/FOtds9gfQN rwBXUWvmKD3zsCpTcfG0 =kSsp -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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:24, Alessio Treglia wrote: On Mon, Jul 28, 2014 at 12:12 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Plus I would definitely appreciate to see some bug stats supporting such a theory. My original mail mentioned some examples. Once FFmpeg is in the archive, each maintainer of a multimedia package could test build it against FFmpeg and see which, if any, of the bugs reported against said package vanish. Best regards, Andreas ___ 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#755528: marked as done (Can't play mp4 audios with libav)
Your message dated Mon, 28 Jul 2014 09:11:49 -0400 with message-id caj0cceag5ykgyhmem5wvhnczyoes0ykcd+h+n0xv01our9g...@mail.gmail.com and subject line Re: Please report this issue upstream has caused the Debian Bug report #755528, regarding Can't play mp4 audios with libav to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 755528: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755528 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: moc Version: 1:2.5.0~beta2-1+b1 Severity: serious Justification: unusuable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? What I did today was: Open moc (mocp) trying to play a *.mp4, but my mp4_s weren't shown (as they use to be). But I could play mp3_s. I noticed moc-ffmpeg-plugin was missing and installed it - *.mp4 files were shown but there was an error, something like ..couldn't initiate sent() on server or the like. I reinstalled moc and moc-ffmpeg-plugin and rebooted. *.mp4 files still shown, but now a different error, no matter what files (mp3 or mp4) I try to play: FATAL_ERROR: Can't receive value from the server! Neither deleteing ~/.moc or rm -rf ~/.moc/cache nor --reinstall does solve the problem. Currently moc is unusuable here. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.15-6.towo-siduction-686 (SMP w/1 CPU core; PREEMPT) 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 moc depends on: ii libasound21.0.28-1 ii libc6 2.19-7 ii libcurl3-gnutls 7.37.1-1 ii libdb5.3 5.3.28-5 ii libfaad2 2.7-8 ii libflac8 1.3.0-2 ii libgcc1 1:4.9.1-1 ii libid3tag00.15.1b-10 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140610git97e0e80b~dfsg-1 ii libltdl7 2.4.2-1.7 ii libmad0 0.15.1b-8 ii libmagic1 1:5.19-1 ii libmodplug1 1:0.8.8.4-4.1 ii libmpcdec62:0.1~r459-4.1 ii libncursesw5 5.9+20140712-2 ii libogg0 1.3.2-1 ii libopusfile0 0.5-1 ii librcc0 0.2.12-0.1 ii libresid-builder0c2a 2.1.1-14 ii libsamplerate00.1.8-8 ii libsidplay2 2.1.1-14 ii libsidutils0 2.1.1-14 ii libsndfile1 1.0.25-9 ii libspeex1 1.2~rc1.1-1 ii libstdc++64.9.1-1 ii libtagc0 1.9.1-2.1 ii libtinfo5 5.9+20140712-2 ii libvorbis0a 1.3.2-1.4 ii libvorbisfile31.3.2-1.4 ii libwavpack1 4.70.0-1 ii zlib1g1:1.2.8.dfsg-1 moc recommends no packages. Versions of packages moc suggests: ii moc-ffmpeg-plugin 1:2.5.0~beta2-1+b1 -- no debconf information ---End Message--- ---BeginMessage--- No worries, Thanks for clearing up this issue. Best, Reinhard On Jul 28, 2014 9:06 AM, Michael Hatzold m.hatz...@web.de wrote: Hi Reinhard, Am 26.07.2014, 19:03 Uhr, schrieb Reinhard Tartler siret...@gmail.com: Control: tag -1 upstream moreinfo Hi Michael, Thank you for your time to report this bug against the Debian libav package. I didn't file a bugreport against libav but against moc/moc-ffmpeg-plugin which I herewith *revoke* (as far as *Debian* is concerned). The conclusion libav being the culprit is wrong. My *.mp4 files are not buggy and play well with all other players (vlc, smplayer). Some confusion arised here due to tests with avplay. New test on a new, clean and fully updated installation (without DMO packages) proved that both avplay and moc/moc-ffmpeg-plugin here play all the files they should, including those *.mp4 files. The avplay test on my regular installation (containg some DMO packages) failed due to a combination of libav-tools (from Debian) and libavcodec55 (from DMO), a combination which should not be installable, but for which fact I think DMO is to blame. Installing libav-tools from DMO enabled avplay to play my *.mp4 files on
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
El 28/07/2014 08:53, Henrique de Moraes Holschuh h...@debian.org escribió: However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). Not really, ffmpeg is packaged as a secondary multimedia library, the default one still being libav. If these packages get traction, we can think of moving ffmpeg to be the default (and ship if we wish libav with the soname change). The package will be of use for the ffmpeg command line tools, and for the maintainers that decide to make the switch. For now, your binary third party games will have to link against libav. I understand perfectly that the soname and symbol versioning clash with libav is not ffmpeg's fault, but that's water (well, sewage) under the bridge. We have to deal with it. Here's an alternative proposal that should be less painful [to our users] in the long run: You need one of the two upstreams to do a *large* major soname bump (at least one order of magnitude higher than what they're currently using), so that both projects can keep evolving with little chance of soname clashes. Symbol versioning will take care of the rest, since both libs carry over their major soname into the symbol version. As it was done upstream, cross-distro/third-party compatibility problems are not increased. Debian will have to package this new bumped upstream release, and get rid of anything built against the old one. It will be easier for Debian if it is ffmpeg upstream that does the soname bump, otherwise we're talking about a huge number of binNMUs. That's been discussed and ruled out in favour of not overstepping libav's namespace. But this is all academic if the security team is not prepared to deal with both libav and ffmpeg at the same time. That effectively forces a choice of either libav, or ffmpeg, and not both. That is premature, let's deal with this issue when we have more data. ___ 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#444368: dvd95: changing back from ITP to RFP
retitle 444368 RFP: dvd95 -- DVD9 to DVD5 converter noowner 444368 tag 444368 - pending thanks Hi, A long time ago, you expressed interest in packaging dvd95. Unfortunately, it seems that it did not happen. In Debian, we try not to keep ITP bugs open for a too long time, as it might cause other prospective maintainers to refrain from packaging the software. This is an automatic email to change the status of dvd95 back from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 12 months. If you are still interested in packaging dvd95, please send a mail to cont...@bugs.debian.org with: retitle 444368 ITP: dvd95 -- DVD9 to DVD5 converter owner 444368 ! thanks It is also a good idea to document your progress on this ITP from time to time, by mailing 444...@bugs.debian.org. If you need guidance on how to package this software, please reply to this email, and/or contact the debian-ment...@lists.debian.org mailing list. Thank you for your interest in Debian, -- Lucas, for the QA team debian...@lists.debian.org ___ 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#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#528 2: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278 ___ 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#755528: closed by Reinhard Tartler siret...@gmail.com (Re: Please report this issue upstream)
Am 28.07.2014, 15:32 Uhr, schrieb Debian Bug Tracking System ow...@bugs.debian.org: I accidentally exposed my complete contact details. If it were possible to delete them I'd appreciate it. If that's technically to big a hassle I have to live with it. Thanks ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: dvd95: changing back from ITP to RFP
Processing commands for cont...@bugs.debian.org: retitle 444368 RFP: dvd95 -- DVD9 to DVD5 converter Bug #444368 [wnpp] ITP: dvd95 -- DVD9 to DVD5 converter Changed Bug title to 'RFP: dvd95 -- DVD9 to DVD5 converter' from 'ITP: dvd95 -- DVD9 to DVD5 converter' noowner 444368 Bug #444368 [wnpp] RFP: dvd95 -- DVD9 to DVD5 converter Removed annotation that Bug was owned by Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org. tag 444368 - pending Bug #444368 [wnpp] RFP: dvd95 -- DVD9 to DVD5 converter Removed tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 444368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
[bts-link] source package libav
# # bts-link upstream status pull for source package libav # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #754435 (http://bugs.debian.org/754435) # Bug title: libavcodec55.so crashes vlc while decoding # * http://bugzilla.libav.org/show_bug.cgi?id=716 # * remote status changed: (?) - NEW usertags 754435 + status-NEW thanks ___ 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#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. Yes, i do! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#755540: marked as done (libav: FTBFS on ppc64el architecture)
Your message dated Mon, 28 Jul 2014 14:35:38 -0300 with message-id 53d689ea.8080...@br.ibm.com and subject line has caused the Debian Bug report #755540, regarding libav: FTBFS on ppc64el architecture to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 755540: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755540 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: libav Version: 10.2-1 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Dear Maintainer, Currently libav doesn't build on ppc64el because it uses altivec and it is still failing on ppc64el, causing the package to FTBFS. I am attaching a patch to disable altivec on ppc64el at the moment. Ubuntu is also using the same patch. Thank you, Breno Index: libav-10.2/debian/confflags === --- libav-10.2.orig/debian/confflags +++ libav-10.2/debian/confflags @@ -14,6 +14,14 @@ ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_ CROSS := $(DEB_HOST_GNU_TYPE)- endif +ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el)) +nooptflags += --disable-altivec +endif + +ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el)) +confflags += --disable-altivec +endif + # list of flavors we want to build FLAVORS := ---End Message--- ---BeginMessage--- Any news on this? Yes. The problem doesn't reproduce anymore and the package is built properly on our machines. Sorry for the noise. I am going to cancel this bug as invalid.---End Message--- ___ 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#756329: vlc: Fix usage of AVFrame to avoid crashes
Package: vlc
Version: 2.1.4-1
Severity: important
Tags: patch
Dear Maintainer,
in modules/codec/avcodec/audio.c one finds:
AVFrame frame;
memset( frame, 0, sizeof( frame ) );
According to the documentation of libavutil this is wrong:
sizeof(AVFrame) is not a part of the public ABI, so new fields may be
added to the end with a minor bump.
This code will crash, when used with a different AVFrame at runtime than
was available at compile-time.
The attached patch fixes this problem.
Best regards,
Andreas
Description: Fix the use of AVFrame
AVFrame is not guaranteed to be ABI stable, i.e. new fields can be
added at any time.
Therefore it must be allocated with av_frame_alloc to avoid crashes.
Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Last-Update: 2014-07-28
--- vlc-2.1.4.orig/modules/codec/avcodec/audio.c
+++ vlc-2.1.4/modules/codec/avcodec/audio.c
@@ -225,6 +225,7 @@ block_t * DecodeAudio ( decoder_t *p_dec
{
decoder_sys_t *p_sys = p_dec-p_sys;
AVCodecContext *ctx = p_sys-p_context;
+AVFrame *frame = NULL;
if( !pp_block || !*pp_block )
return NULL;
@@ -271,8 +272,7 @@ block_t * DecodeAudio ( decoder_t *p_dec
p_block-i_flags |= BLOCK_FLAG_PRIVATE_REALLOCATED;
}
-AVFrame frame;
-memset( frame, 0, sizeof( frame ) );
+frame = av_frame_alloc();
for( int got_frame = 0; !got_frame; )
{
@@ -284,7 +284,7 @@ block_t * DecodeAudio ( decoder_t *p_dec
pkt.data = p_block-p_buffer;
pkt.size = p_block-i_buffer;
-int used = avcodec_decode_audio4( ctx, frame, got_frame, pkt );
+int used = avcodec_decode_audio4( ctx, frame, got_frame, pkt );
if( used 0 )
{
msg_Warn( p_dec, cannot decode one frame (%zu bytes),
@@ -320,7 +320,7 @@ block_t * DecodeAudio ( decoder_t *p_dec
}
/* NOTE WELL: Beyond this point, p_block now refers to the DECODED block */
-p_block = frame.opaque;
+p_block = frame-opaque;
SetupOutputFormat( p_dec, true );
/* Silent unwanted samples */
@@ -336,10 +336,10 @@ block_t * DecodeAudio ( decoder_t *p_dec
block_Release( p_block );
if( av_sample_fmt_is_planar( ctx-sample_fmt )
ctx-channels AV_NUM_DATA_POINTERS )
-free( frame.extended_data );
+free( frame-extended_data );
return NULL;
}
-assert( p_block-i_nb_samples = (unsigned)frame.nb_samples );
+assert( p_block-i_nb_samples = (unsigned)frame-nb_samples );
assert( p_block-i_nb_samples == p_buffer-i_nb_samples );
p_block-i_buffer = p_buffer-i_buffer; /* drop buffer padding */
@@ -348,13 +348,13 @@ block_t * DecodeAudio ( decoder_t *p_dec
{
const void *planes[ctx-channels];
for( int i = 0; i ctx-channels; i++)
-planes[i] = frame.extended_data[i];
+planes[i] = frame-extended_data[i];
-aout_Interleave( p_buffer-p_buffer, planes, frame.nb_samples,
+aout_Interleave( p_buffer-p_buffer, planes, frame-nb_samples,
ctx-channels, p_dec-fmt_out.audio.i_format );
if( ctx-channels AV_NUM_DATA_POINTERS )
-free( frame.extended_data );
+free( frame-extended_data );
block_Release( p_block );
p_block = p_buffer;
}
@@ -364,7 +364,7 @@ block_t * DecodeAudio ( decoder_t *p_dec
if (p_sys-b_extract)
{ /* TODO: do not drop channels... at least not here */
p_buffer = block_Alloc( p_dec-fmt_out.audio.i_bytes_per_frame
-* frame.nb_samples );
+* frame-nb_samples );
if( unlikely(p_buffer == NULL) )
{
block_Release( p_block );
@@ -373,21 +373,23 @@ block_t * DecodeAudio ( decoder_t *p_dec
aout_ChannelExtract( p_buffer-p_buffer,
p_dec-fmt_out.audio.i_channels,
p_block-p_buffer, ctx-channels,
- frame.nb_samples, p_sys-pi_extraction,
+ frame-nb_samples, p_sys-pi_extraction,
p_dec-fmt_out.audio.i_bitspersample );
block_Release( p_block );
p_block = p_buffer;
}
-p_block-i_nb_samples = frame.nb_samples;
-p_block-i_buffer = frame.nb_samples
+p_block-i_nb_samples = frame-nb_samples;
+p_block-i_buffer = frame-nb_samples
* p_dec-fmt_out.audio.i_bytes_per_frame;
p_block-i_pts = date_Get( p_sys-end_date );
-p_block-i_length = date_Increment( p_sys-end_date, frame.nb_samples )
+p_block-i_length = date_Increment( p_sys-end_date, frame-nb_samples )
- p_block-i_pts;
return p_block;
end:
+if ( frame != NULL )
+av_frame_free(frame);
block_Release(p_block);
*pp_block = NULL;
return NULL;
___
pkg-multimedia-maintainers mailing
Bug#756341: streamtuner2: hangs at 'loading module live365'
Package: streamtuner2 Version: 2.1.1-1 Severity: grave Justification: renders package unusable Hi maintainer, Just tried to install and use streamtuner2, but I only see a progress bar on top-left corner on screen that doesn't go past the subject's stage. I've waited several minutes but it stays there wasting ~100% cycles of a core, as top shows. Any suggestion appreciated, but as currently this is completely unusable. Best regards, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (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 streamtuner2 depends on: ii python-glade2 2.24.0-3+b1 ii python-gtk2 2.24.0-3+b1 ii python-imaging2.5.1-1 ii python-keybinder 0.3.0-3 ii python-lxml 3.3.5-1+b1 ii python-pyquery1.2.4-1 ii python-requests 2.3.0-1 pn python:anynone streamtuner2 recommends no packages. Versions of packages streamtuner2 suggests: pn audacious none ii totem 3.12.1-1 ii vlc2.1.4-1+b3 -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28 July 2014 15:05, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. Thankfully, we have worked to make sure libav is in universe only and thus is not a security maintenance burden. Nonetheless, libav10 transition is still not complete in utopic today. I haven't checked, but now abi compatible/incompatible the two stacks are? cause it would be a pain if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg libav and some clashing symbols are present... and people start requesting to have build variants against both. Has a rebuild of all deps been done? How many build failures there are? (On both debian ubuntu, ideally) Is hardening flags / toolchain enabled in both, or either of the two? -- Regards, Dimitri. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
