Handbrake is a nice and efficient dvd ripping software. Unlike dvdrip that is requested here https://bugs.mageia.org/show_bug.cgi?id=2165 and has not been updated for 2 years, it is still under development. I tried both softwares and found handbrake easier to use though as full-featured as dvdrip (just my point of view). It would be great to have it packaged. Thanks !
CC: (none) => denis.prost
Duplicate of a lot of closed bug reports : #1007 #1518 #2181 #2282 #2313 #2833 There's a problem with faac and libfaac that is not free and tainted !!! Waiting for a solution (creating a non-free&tainted repo) to propose rpm built with faac Maybe reopen bug 2833 !
CC: (none) => philippedidier
So, If I understand well, I should mark it as wontfix and maybe reopen it later when Mageia team decides to create an non-free & tainted repo.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
I reopen this package request since a new version of handbrake was published : https://trac.handbrake.fr/milestone/HandBrake 0.9.6 It doesn't use anymore faac nor libfaac and may now be provided in tainted repo !
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)
perhaps the url is better this way : https://trac.handbrake.fr/milestone/HandBrake%200.9.6
CC: (none) => hhielscher
Stable Version 0.9.8 suggestion of SPEC: http://paste.kde.org/537866/ Source: http://handbrake.fr/rotation.php?file=HandBrake-0.9.8.tar.bz2 I tested the SPEC and it worked well: Gravou: /home/chimarrao/rpm/SRPMS/HandBrake-0.9.8-1.src.rpm Gravou: /home/chimarrao/rpm/RPMS/x86_64/HandBrake-gui-0.9.8-1.x86_64.rpm Gravou: /home/chimarrao/rpm/RPMS/x86_64/HandBrake-cli-0.9.8-1.x86_64.rpm
CC: (none) => frateraec
Hardware: i586 => All
For info a package of handbrake can be found here: http://repo.mageia.org.pl/2/x86_64/handbrake-0.9.6-1.mga2.x86_64.rpm http://repo.mageia.org.pl/2/i586/handbrake-0.9.6-1.mga2.i586.rpm
CC: (none) => dglent
And here too with a more recent version : ftp://ftp.blogdrake.net/mageia/mageia2/free/i586/HandBrake-gui-0.9.8-1bdk.mga2.i586.rpm ftp://ftp.blogdrake.net/mageia/mageia2/free/i586/HandBrake-cli-0.9.8-1bdk.mga2.i586.rpm ftp://ftp.blogdrake.net/mageia/mageia2/free/x86_64/HandBrake-gui-0.9.8-1bdk.mga2.x86_64.rpm ftp://ftp.blogdrake.net/mageia/mageia2/free/x86_64/HandBrake-cli-0.9.8-1bdk.mga2.x86_64.rpm
Great, thanks to both of you.
Philippe Didier@: I use a script to find packages in unofficial repos, and i've just realized that it needs to not be case sensitive :) thanks fixed: http://glenbox.free.fr/mga3prepo/0.2/mga3prepo.py http://www.mageia-gr.org/rpm/2/noarch/mga3prepo-0.2-1mgr2.noarch.rpm
*** Bug 10888 has been marked as a duplicate of this bug. ***
CC: (none) => thetas.e
CC: (none) => thierry.vignaud
Is there any chance that handbrake enters Mageia official repositories for Mageia 4, now that there is no more license problem ? Thanks, Denis
CC: (none) => ugal12v
(In reply to Denis Prost from comment #11) > Is there any chance that handbrake enters Mageia official repositories for > Mageia 4, now that there is no more license problem ? Why do you assume that there's no more license problem? handbrake is still using libfaac by default. Check https://trac.handbrake.fr/wiki/Encoders The relevant commits to remove libfaac have only been applied to trunk, and not even 0.9.9.1 has been release, so it will probably take more then a year until this ends up in a release. https://trac.handbrake.fr/changeset/6094 https://trac.handbrake.fr/changeset/5934 But feel free to provide a patch to remove libfaac against current handbrake 0.9.9.
CC: (none) => doktor5000
(In reply to Florian Hubold from comment #12) > (In reply to Denis Prost from comment #11) > > Is there any chance that handbrake enters Mageia official repositories for > > Mageia 4, now that there is no more license problem ? > > Why do you assume that there's no more license problem? > I just thought that was what was telling comment #3. Looks like I was wrong...
Assigning to augier who is working on it, and putting his maintainer AL13N in CC.
Assignee: bugsquad => christopheCC: (none) => alien, remi
> Assigning to augier who is working on it, and putting his maintainer AL13N in CC. Thank you ! To answer to the previous questions : > Why do you assume that there's no more license problem ? >handbrake is still using libfaac by default. Check https://trac.handbrake.fr/wiki/Encoders Using libfaac is now optionnal. You can disable it during compilation-time. Moreover, HandBrake has been updated to v0.10 bêta in Mageia 5.
(In reply to Rémi Verschelde from comment #14) > Assigning to augier who is working on it, and putting his maintainer AL13N > in CC. you probably meant "mentor" or "master jedi" :-)
(In reply to AL13N from comment #16) > (In reply to Rémi Verschelde from comment #14) > > Assigning to augier who is working on it, and putting his maintainer AL13N > > in CC. > > you probably meant "mentor" or "master jedi" :-) Indeed :-D
(In reply to Augier from comment #15) > > Assigning to augier who is working on it, and putting his maintainer AL13N in CC. [snip] > > Using libfaac is now optionnal. You can disable it during compilation-time. > Moreover, HandBrake has been updated to v0.10 bêta in Mageia 5. Hi there, sorry that wasn't directed at you, just at the previous comment. I've checked your work on handbrake, and I must thank your for that, greatly appreciated. That way much of the time I've spent on this package in the past during my apprenticeship wasn't totally wasted :) One minor thing, didn't check the build but if they haven't changed the buildsystem in major ways, I'd prefer if you can add the automic-downloader-disable-hack back from http://svnweb.mageia.org/packages/cauldron/handbrake/current/SPECS/handbrake.spec?revision=389214&view=markup (line 83 - 101). Also for the big commit you did in http://svnweb.mageia.org/packages/cauldron/handbrake/current/SPECS/handbrake.spec?view=markup&pathrev=669055 it could be a good idea to be more verbose in the commit messages about such huge changes, you can also SILENT them if there are no visible changes for the user, but that's important for packagers. Another thing for the commit message, just saw that http://svnweb.mageia.org/packages?view=revision&revision=669459 the "revision xxxx" gets interpreted by websvn, commit message could maybe be edited. You should also add another comment for user-visible changes, like adding x265 support, you only mentioned silently that you updated the tarball for that, but not that handbrake can do that now ;) Apart from those minor topics, really like your work - keep that up! :D
> i there, sorry that wasn't directed at you NP ;) > I've checked your work on handbrake, and I must thank your for that, greatly appreciated. That way much of the time I've spent on this package in the past during my apprenticeship wasn't totally wasted :) You're welcome ;) About the automatic downloadig disabeling, it appears that, if sources are already placed in the good place before downloading, nothing is downloaded. This is the reason why there's soo much sources. Concerning x265, I finally disabled that feature in the package because build was failing on my computer. About the big commit, the commit message was approved by my master jedi, not my fault ! *Throwing honey on ALIEN* :D I'm not used to write commit messages yet. Most of them was was only usefull to me, so they sometimes was only "~" :/ I'll try to be more verbose ;)
(In reply to Augier from comment #19) > About the automatic downloadig disabeling, it appears that, if sources are > already placed in the good place before downloading, nothing is downloaded. Yes, I know that. The point for that hack was the following: If somebody else does a drive-by version update of handbrake, which would require new versions of the contrib tarballs, those would be automatically downloaded by the buildsystem. That is what we want to avoid. In that case the build should simply fail due to the missing updated contrib tarballs. > This is the reason why there's soo much sources. No problem at all, if there are 10 or 20 of them that doesn't hurt. But if you get a build which automatically downloads stuff, which is not in our SVN and so the build is not reproducable and succeeds without us knowing, that's a problem. > I'm not used to write commit messages yet. Most of them was was only usefull > to me, so they sometimes was only "~" :/ > I'll try to be more verbose ;) You'll probably get used to it, I'm sure about that :D
> Yes, I know that. The point for that hack was the following: If somebody else does a drive-by version update of handbrake, which would require new versions of the contrib tarballs, those would be automatically downloaded by the buildsystem. That is what we want to avoid. In that case the build should simply fail due to the missing updated contrib tarballs. Ah ? Is it a big issue ? If no, can it wait for the official 0.10 release ? > You'll probably get used to it, I'm sure about that :D I have no doubt on it :p
(In reply to Augier from comment #21) > > Yes, I know that. The point for that hack was the following: If somebody else does a drive-by version update of handbrake, which would require new versions of the contrib tarballs, those would be automatically downloaded by the buildsystem. That is what we want to avoid. In that case the build should simply fail due to the missing updated contrib tarballs. > > Ah ? Is it a big issue ? If no, can it wait for the official 0.10 release ? Yes that is a fundamental issue. Basically IMHO their buildsystem is already broken trying to automatically download stuff without an obvious/easy disable switch. Userfriendly vs. packager-unfriendly. Please add it back.
just for the record/clarity: - Since the buildnodes actually fail when downloading, i didn't think much of this, and thus i approved it like this. - regarding the big commit... in all actuality, the build system did change (and the age difference), and so this is actually a complete restart from scratch, after that, i did ask to make the commit as minimal as possible. Since it's not an improvement as such as rather a restart, i ok'd the commit message like this (and probably even suggested big parts of it) Now, it does seem you feel a bit strongly towards this, plus i accept that i can make faults.
CC: dglent => (none)
For the record, as discussed on IRC with Augier, handbrake should _NOT_ bundle so many libraries. Debian has patches to make a cleaner build, see: https://packages.debian.org/sid/handbrake
(In reply to AL13N from comment #23) > just for the record/clarity: > > - Since the buildnodes actually fail when downloading, i didn't think much > of this, and thus i approved it like this. For the record, no they don't fail and they will happily download stuff. Try it yourself with the null package if you don't believe me: http://svnweb.mageia.org/packages/cauldron/null/current/SPECS/null.spec?r1=669164&r2=697347 (In reply to Rémi Verschelde from comment #24) > For the record, as discussed on IRC with Augier, handbrake should _NOT_ > bundle so many libraries. That's probably not a good idea in this specific case. handbrake uses some customized branches of those libraries, unless you plan to fix all handbrake issues when building it against system libraries _without_ receiving support from handbrake upstream. See https://trac.handbrake.fr/wiki/SupportFAQ#contribs (might need partial re-verification, as for some libraries for which no patches are required system libraries should be used where possible and this is supported since >= 0.9.9) Others tried this, too and still handbrake needs ~10 bundled libraries: http://negativo17.org/experimental-builds-of-handbrake-with-system-libraries/ http://negativo17.org/updated-builds-of-handbrake-with-system-libraries/ > Debian has patches to make a cleaner build, see: > https://packages.debian.org/sid/handbrake Cleaner build means what in particular? Well, they only remove really few bundled libraries: http://anonscm.debian.org/cgit/pkg-multimedia/handbrake.git/tree/debian/patches/002-Remove-embedded-downloaded-copies-of-various-librari.patch http://anonscm.debian.org/cgit/pkg-multimedia/handbrake.git/tree/debian/patches/003-remove-vpx.patch Apart from that, did you try handbrake under Debian to verify that it works the same way as the upstream version?
> Well, they only remove really few bundled libraries: Five library sets, among which ffmpeg, is hardly "few bundled libraries" IMO, I quote the 0002 patch: -MODULES += contrib/ffmpeg -MODULES += contrib/libvpx -MODULES += contrib/libdvdread -MODULES += contrib/libdvdnav -MODULES += contrib/libbluray > Others tried this, too and still handbrake needs ~10 bundled libraries: Well then the question is: do we want to support software with so many bundled libraries? Apart from ffmpeg, I don't know much about the potential security concerns linked to the other bundled libraries, so I CC the security team to get a better opinion about this. > Apart from that, did you try handbrake under Debian to verify that it works the same way as the upstream version? Nope, it might very well be broken. I'm just raising some concerns here, if you think that it's completely wrong to unbundle the libraries in handbrake, feel free to argument so that we can reach a consensus. I'm just speaking for the policy here.
CC: (none) => security
Of the 5 things you listed, off the top of my head, we've only had security updates in the past for ffmpeg. Of course, the chance always exists, so we generally like to avoid bundling. FFmpeg is a real pain as far as this goes. We like to avoid bundling it if at all possible, but because of the frequent API changes, we do have some packages that bundle it, like avidemux, xbmc/kodi, and mythtv, and can't really do anything about those, so we have to patch avidemux ourselves since upstream doesn't stay on top of keeping ffmpeg up to date (a real pain) and keep xbmc and mythtv updated (although we haven't done a great job of that). So, if we can't build handbrake against system FFmpeg, we'll just have to keep it up to date (and hopefully do a better job of it). As for the other libraries, there's no apparent reason that it can't be built against the system ones, so there's really no good excuse for those. I know upstreams will offer excuses for it (handbrake is not unique here), but we don't care. We have our policies for a reason. Many upstream developers don't care.
CC: security => (none)
Well said...
i just want to note that upstream claims that debian made a broken mess out of their program and that they have had quite some complaints regarding that, which they can't help because debian "broke" their package... anyway, these upstream do care about unbundling, it's just that they wait for it to stabilize, and if there's not any patches of their own. they recently unbundled a few more libs, and probably will unbundle in next releases a few more. anyway, they way i see it, there's only 6 bundled libs, if the maintainer(padawan) does any security patching, that's ok by me. I'm for the go ahead, even though i dislike bundling a lot. I do suspect that given time, quite some more will become unbundled, until only ffmpeg will remain, or maybe even that will become unbundled.
I just want to point out that, as AL13N said, upstream was really unhappy with the work Debian made. And this is a package concerning version 0.9.9 which was released 2 years ago if I'm not wrong. Upstream said many changes were done in 0.10 and this is currently 6 bundled sources for 25 build dependancies which is not bad IMHO. Anyway, I will be able to work on update to stable sources next week if all goes well.
(In reply to AL13N from comment #29) > anyway, they way i see it, there's only 6 bundled libs, if the > maintainer(padawan) does any security patching, that's ok by me. > > I'm for the go ahead, even though i dislike bundling a lot. +1 from me for both :)
I tried Handbrake from the Cauldron repos in the mga5 RC today, and it did a fine job. Reduced a 36MB avi video from my digital camera to a 5MB mp4 with no discernible reduction of quality, that I could then upload to Facebook. I see that a .10.1 bugfix version has been released. Are there any plans to offer this as an update?
CC: (none) => andrewsfarm
It will probably need to be updated periodically just to fix security issues in bundled stuff. Anyway, that would need a new request and can be handled after the release. The package is available, so this should be marked FIXED.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED