Description of problem: libmp4v2 is currently at 1.5.0.1 while 1.9.1 is already available for over a year. Version-Release number of selected component (if applicable): libmp4v2-1.5.0.1-10.fc12.i686
Update suggestion: SPEC: http://fkooman.fedorapeople.org/libmp4v2/libmp4v2.spec SRPM: http://fkooman.fedorapeople.org/libmp4v2/libmp4v2-1.9.1-1.fc13.src.rpm This will probably require a rebuild and possibly modification of at least: $ repoquery --repoid=fedora --repoid=updates --whatrequires libmp4v2 libmp4v2-0:1.5.0.1-10.fc12.i686 easytag-0:2.1.6-2.fc13.i686 easytag-0:2.1.6-5.fc13.i686 gtkpod-0:0.99.14-4.fc13.i686 kid3-0:1.4-1.fc13.i686 libmp4v2-devel-0:1.5.0.1-10.fc12.i686 libtunepimp-0:0.5.3-16.fc12.i686 mediatomb-0:0.12.1-1.fc13.i686 $ rpmlint libmp4v2.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint ../RPMS/i686/libmp4v2-* libmp4v2.i686: W: no-manual-page-for-binary mp4tags libmp4v2.i686: W: no-manual-page-for-binary mp4extract libmp4v2.i686: W: no-manual-page-for-binary mp4trackdump libmp4v2.i686: W: no-manual-page-for-binary mp4chaps libmp4v2.i686: W: no-manual-page-for-binary mp4info libmp4v2-devel.i686: W: no-documentation 3 packages and 0 specfiles checked; 0 errors, 6 warnings. $ rpmlint ../SRPMS/libmp4v2-1.9.1-1.fc13.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Having just looked into this, I suspect a move to 1.9.1 or later (mp4v2 is currently working towards a 2.0 release) wouldn't be an easy one. The mp4v2 maintainers made significant changes to their entire public API with the 1.9.1 release that break backwards compatibility, and continue to introduce more as they approach 2.0. See: http://mp4v2.googlecode.com/svn/doc/trunk/ReleaseNotes.html In terms of API consumers, I looked at easytag and faac to gauge support. The easytag source has gotten some recent attention, and while their current trunk still relies on API calls that are deprecated in 1.9.1 and removed in 2.0, there are patches being submitted that address these and other issues. I suspect it's just a matter of time before the code is worked out in terms of mp4v2 support. The recent (semi-official?) work's been going on over in github: https://github.com/stsquad/easytag faac is NOT there at all. We're already building off the latest 1.28 source release, which is from 2009-02-02. So we'd have to look elsewhere for patches to bring it up to mp4v2 1.9.1/2.0 compatibility, assuming anyone's done the work.
Easytag has sort of resumed development, so I'm looking at updating it. The latest git code seems to include the changes mentioned above, since I now get : checking for MP4 file support... checking mp4v2/mp4v2.h usability... no checking mp4v2/mp4v2.h presence... no checking for mp4v2/mp4v2.h... no checking for MP4GetTrackMediaDataName in -lmp4v2... yes checking for MP4/AAC file support... no *** *** Warning: MP4 file support disabled *** (Install libmp4v2 >= 1.9.0 to enable it) *** Does anyone happen to know the status of all this? The latest stable libmp4v2 release is still 1.9.1 from July 2009, so if everything can easily be rebuilt against it for now even if it has some deprecated stuff still used by other packages, that would be fine for me.
Looks like 2.0.0 was released a little over a week ago.
Created attachment 592368 [details] spec file for mp4v2 2.0.0 I’ve successfully used this spec file to build a libmp4v2-2.0.0 rpm...
Created attachment 592369 [details] mp4v2 2.0.0 support for easytag ...used this patch to build easytag 2.1.7 with mp4v2 2.0.0 support...
Created attachment 592370 [details] spec file for easytag 2.1.7 with mp4v2 2.0.0 support ...and built an easytag 2.1.7 RPM with mp4v2 2.0.0 support using the existing easytag-2.1.7-1.fc16.src.rpm, the previous patch, and this spec file. Hope some of you find it useful! Also: easytag’s trunk includes some mp4v2 support, but has problems with cover art, so I’ve sent this patch upstream.
any update on this issue? I updated to fc17 and got no working mp4 support on easytag.. :(
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
I've build it with hdfssk's new spec file from comment #5, RPMs are here: http://avi.alkalay.net/software/libmp4v2/ The easytag-2.1.9-2.fc20.x86_64 package from Fedora 20 updates lives well with this libmp4v2-2.0.0-1.fc20.x86_64 build and I was able to read and write tags to M4A files using this easytag version. I guess nothing else is needed to push libmp4v2-2.0.0 at least to updates-testing. Although I have a Git commit permission, I'm not sure about the steps to update a package not owned by me. What are the next steps ? Thank you in advance.
Is it possible to adapt your package to coexist with libmp4v2-1.5.0? That would make possible to use both easytag with new lib, and old packages like faac that need libmp4v2 1.5.0... In theory, since library is called libmp4v2.so.2 instead of libmp4v2.so.0, that could be possible. Thanks!
(In reply to Emilio Scalise from comment #11) > Is it possible to adapt your package to coexist with libmp4v2-1.5.0? I think this will make the world a bit dirty with no need. FAAC and FAAD should be patched after the updated libmp4v2. RPMFusion (the source of FAAC and FAAD) depends on and follows Fedora, not the opposite. I don't even think they have to be patched at all, only recompiled. I was supposed to test this latter today and will keep you posted here.
While I would be shocked if faac can easily be made to work with libmp4v2 2.0 (as far as I know it's still received no development since 2009, and relies on API calls that no longer exist in current libmp4v2), I think a slight twist on Emilio's suggestion could be a workable solution: 1. Fedora updates libmp4v2 to a build of 2.0.0 2. rpmfusion takes what had been Fedora's 1.5.0 and repackages it as libmp4v2-compat, built to coexist with the official libmp4v2 2.0.0 package 3. They begin disting that package, and rebuild whatever packages require legacy libmp4v2 to depend on it instead of the upstream libmp4v2 This is precisely the route they've taken in the past with other libraries. For instance, ffmpeg-compat-0.6.7 is currently present in their repo to support a few packages that haven't kept up with ffmpeg changes. (Looks like maybe just audacity-freeworld and transcode, actually.)
Opened an rpmfusion bug to ping them on this issue. https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188
Avi, Nicolas Chauvet @ RPMFusion has asked to be apprised of the results when you try building FAAC against libmp4v2-2.0.0. If you could copy https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188 on any updates, I'm sure it'd be greatly appreciated. (Or if you prefer, I'd be happy to take care of relaying the info.)
Created attachment 869274 [details] more updates, now include some documentation files into package
I take back what I said! Seems faac can be built against libmp4v2-2.0.0. See the rpmfusion bug for details, but basically I found that while the latest faac release (1.28) is hopelessly outdated, the CVS tree in sourceforge has fixes that bring it up to 2.0.0 compatibility. So, if rpmfusion update faac, there should be no need to preserve the 1.5.x series libmp4v2 anyway. (I believe faac is the only remaining consumer.)
(In reply to "FeRD" (Frank Dana) from comment #17) > I take back what I said! Seems faac can be built against libmp4v2-2.0.0. That's great news! From my side I'm trying to stop using FAAC in favor of FFMPEG since FAAC declares itself as a not so good quality encoder and FFMPEG is a more generic tool anyway. So all solved, let's move to the most difficult part of this task: the Fedora process. Can anybody tell us what are the next step in getting this package updated? Where to submit to git and koji? What flags need to be raised in this bugzilla report? Whom to talk to? I've already submitted new packages to Fedora but I don't know how to deal with updates. Thank you
Flagging as NEEDINFO Matthias, as he's still the listed assignee on this one.
Hi, I can commit on rpmfusion and fix faac in rpmfusion , please update libmp4v2, even Debian stable have version 2.0.0 [1] To rebuild faac on Fedora 21 (which not build in this moment), will be more simple if we got mp4v2 updated, I think will be just update faac from cvs sources. [1] https://packages.debian.org/source/stable/mp4v2
Hi, Matthias Saou , I had request commit permission on this package to update it.
Nicolas @ RPMfusion reports that their faac will be libmp4v2-2.0.0 compatible as of F21 GA (still this coming Tuesday, I believe?). It really seems like time to pull the trigger on this update. https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188 Sergio, I see your committers request is still pending in the PkgDB, I assume it's just a matter of getting that approved. Matthias' last commit to this package was back in 2009, since then the only time it's been touched has been during the Mass Rebuild cycles. As he doesn't appear to be reachable as maintainer, do you (or anyone) know if there's someone we can bounce this up the chain to, or some alternate procedure for requesting commit access?
Hi, Built libmp4v2-2.0.0-1.fc22 http://koji.fedoraproject.org/koji/packageinfo?packageID=2356 should I move on to F21 ?
libmp4v2-2.0.0-2.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/libmp4v2-2.0.0-2.el7
Package libmp4v2-2.0.0-2.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing libmp4v2-2.0.0-2.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0254/libmp4v2-2.0.0-2.el7 then log in and leave karma (feedback).
Thanks, Sergio. My laptop is currently in the throes of the fedup process to take it to F21 Workstation, so that should be complete soon. I'd definitely be interested in testing an updated libmp4v2-2.0.0, if you can push one to F21 updates-testing (or even just provide a koji build).
libmp4v2-2.0.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Hi, I'm listing package that be affect by update libmp4v2 on Fedora 21 repoid package ------------------------------ fedora easytag fedora kid3 fedora libtunepimp fedora mediatomb rpmfusion-free mixxx rpmfusion-free mpd rpmfusion-free mythmusic rpmfusion-nonfree faac libmp4v2-2.0.0 was out in 2012 and from what I see major of package have m4a disable due a libmp4v2 not updated , can I update it for F21 on updates-testing ?
Hi, I decided not change F21 package is too late , but I will see if we enable m4a on some packages for F22 Thanks,