When you try to install libmp4v2 with nasm-2.0 it will fail, repeating this message forever (infinite loop): checking for nasm... true checking nasm version...... nasm: error: unrecognised option `-r' nasm: error: no input file specified type `nasm -h' for help util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected util/testnasm.sh: line 8: test: =: unary operator expected Reproducible: Always
Well, you should treat this as an upstream bug. nasm 1.98 listed -r option as obsolete (-v preferred).
Help! this has made it into amd64 stable.
Created attachment 137770 [details, diff] Changes -r to -v in configure script
Created attachment 137771 [details] Updated ebuild
Created attachment 137857 [details] libmp4v2-1.5.0.1.ebuild.diff Better approach which fixes configure.in and not configure, uses eautoreconf from autotools.eclass, doesn't need a patch and will only get applied when >=nasm-2 is installed. Though I don't know if elibtoolize is still needed when eautoreconf was invoked before so I left that untouched in the ebuild.
(In reply to comment #5) > Created an attachment (id=137857) [edit] > libmp4v2-1.5.0.1.ebuild.diff > I have tested your fix in ~x86 successfully! Andrés
Lars, what exactly is the difference between your patch and the other patch that has an updated ebuild? If you are using nasm 2 from testing does it matter the approach, His ebuild emerged fine.
Like I said in my previous post. My patch fixes the real source of the problem (Makefile.in) and not the autotools generated Makefile. Furthermore Makefile.in only needs the fix when >=nasm-2 is installed as otherwise libmp4v2 would break when there is still <nasm-2 installed. Finally the fix is (imho) rather trivially done with sed from inside the ebuild. No need to add an extra patch into the portage-tree.
Any chance of committing? Issue still exists and patch runs fine here (used the one from Lars).
Fixed in -r3
Marked as fixed but there were no update on media-libs/libmp4v2 for the last seven weeks... Can anyone please reopen this bug until it's really fixed?
Experienced bug. Patch and updated ebuild work, but they're not in portage ....
Could someone update the ebuild in portage?
(In reply to comment #10) > Fixed in -r3 ???
(In reply to comment #10) > Fixed in -r3 Funny thing is there is no -rX at all in portage... ;) [I] media-libs/libmp4v2 Available versions: 1.5.0.1
-r1 is in the tree.
Did the tree move away from sources.gentoo.org/gentoo-x86 ? At least http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/libmp4v2/ doesn't show any -r1 at the time of this writing...
be patient, its there now..
