Finally a usable frontend for Mplayer :) Reproducible: Always
Created attachment 117371 [details] smplayer-0.3.42.ebuild Made a ebuild for this.
- The ebuild header is invalid¹. - Dependencies are incorrect with eg. with USE="qt3 qt4" you depend on both, while you build against one of them. - USE=kde shouldn't depend on the qt3 use flag set and the ebuild shouldn't die, but choose a default, throwing a warning, which use flag it ignores. - The line "elif use qt3 || use qt4; then" is just weird as Qt 3 and KDE 3 have nothing to with Qt 4. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3
Created attachment 117477 [details] smplayer-0.3.44.ebuild Corrected smplayer ebuild.
Created attachment 118077 [details] smplayer 0.4.0 ebuild Simply changed version to 0.4.0
Created attachment 118359 [details] Latest stable, with minor ebuild improvements Latest version is 0.4.7. This ebuild has a better package description, consistent spacing/indents, and a more grammatically-correct elog message when using both qt4 and kde.
Created attachment 118520 [details] smplayer-themes-0.1.ebuild Icon themes are now in separate package. Attached ebuild for it. Smplayer 0.4.15 retrieves all functionality from 0.4.7 so should be considered as stable (previous ebuilds are working need only to change version number in file name).
Created attachment 118775 [details] smplayer-0.4.15.ebuild (=x11-libs/qt-4.2*) change to (>=x11-libs/qt-4.2*) smplayer compiling and working with qt 4.3
With kde and -qt4 install fails under ~amd64: >>> Source compiled. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-media-video_-_smplayer-0.4.15-8319.log" open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock -------------------------------------------------------------------------------- But after i I removed the qt_plugins_3.3rc file, it finished. :-/ However, great app! Please include in portage!
This app is _far_ more stable than gmplayer. Finally a good MPlayer frontend, thank god. Tested version 0.4.29 with Qt4 4.3.0-rc1 on ~x86 - works with that ebuild. smplayer-themes seem to depend on the Qt3 version though.
I can only agree with #9 , gmplayer is a joke compared to smplayer both feature as well as stability wise. Appart from being the best frontend for mplayer I have seen it is also improving almost daily. So why is this bug hanging around here already for a month with not even a unstable ebuild added to the portage ebuild-tree?
In case anyone wonders why continous playlist playback does not work: https://sourceforge.net/tracker/index.php?func=detail&aid=1726324&group_id=185512&atid=913573 mplayer is not able to do runtime language selection, so smplayer _expects_ mplayer to be compiled with LINGUAS="en ..", means english as primary output language, otherwhise smplayer fails on many tasks as it parses mplayer's stdout in english, see src/mplayerprocess.cpp This.. sucks, as this smplayer is really great otherwhise.
Created attachment 121487 [details] smplayer-0.5.7.ebuild
Hi folks, errm, smplayer 0.5.7? Is this an mistake? I only see version 0.5.14 on the official website. Well, renaming that 0.5.7-ebuild to 0.5.14 works fine here on ~amd64 so i consider adding ~amd64 to keywords. Finally i can say, that this gui rocks every other gui ever seen for mplayer (gmplayer etc.), so i really hope it'll be in portage some day in the near future ;)
> errm, smplayer 0.5.7? Is this an mistake? No, 0.5.7 was latest version 2007-06-08. As I already wrote in this bug before "Appart from being the best frontend for mplayer I have seen it is also improving almost daily." SMplayer is VERY well maintained upstream... Unfortunately this bug also shows the increasing deterioration of Gentoo as a whole with a lot of experienced knowledgeable people leaving. A few years ago no way a really great app would be kept from even entering as ~ in the tree 2 months after a request was made, especially with the numerous ebuilds that has been provided.
>> errm, smplayer 0.5.7? Is this an mistake? >No, 0.5.7 was latest version 2007-06-08. Ouch, my mistake then, i understood that version as 0.5.1.4 :8 Whatever, as wrote before, simply renaming that ebuild works great here. FYI, i used "kde qt4" as my useflags. And i totally agree to what you've said about time and software getting into the portage tree :( "They" always say "we" should help because gentoo is a community driven meta distro, but this time there >>is<< help (in form of ebuild(s)) and no one seems to be listening/recognizing(...)
Just renamed the ebuild to smplayer-0.5.16, built it and am using it without problems. Useflags: kde qt4
I renamed the most recent ebuild to smplayer-0.5.17.ebuild, and it works on AMD64, with one caveat: attempting to merge with USE="-kde qt4" results in the following error: make: *** No rule to make target `/usr/lib/qt3/mkspecs/default/qmake.conf', needed by `Makefile'. Stop. Looks like an upstream problem to me. Anyone else have a similar issue?
Same here (v0.5.19, i just manually bumped smplayer-0.5.7.ebuild) -> make: *** No rule to make target `/usr/lib/qt3/mkspecs/default/qmake.conf', needed by `Makefile'. Stop. Btw., why is this ebuild using kde support over qt4 support? Shouldn't smplayer be compiled with qt4 , if both USE-flags are specified?
Created attachment 122691 [details] smplayer-0.5.19.ebuild (slightly changed from original v0.5.7) I bumped smplayer-0.5.7.ebuild to smplayer-0.5.19.ebuild with a little change, qt4 support will be used over qt3, if USE-flags "kde" and(!) "qt4" are specified. Additionally i added a fix/patch which fixes that "make: *** No rule to make target `/usr/lib/qt3/mkspecs/default/qmake.conf', needed by `Makefile'. Stop."-error on my amd64 system. This patch changes paths in src/Makefiles, so that Makefile will look for - qmake.conf in /usr/qt/3/mkspecs/linux-g++ instead of /usr/lib/qt3/mkspecs/default - libqt-mt.prl in /usr/qt/3/lib/libqt-mt.prl instead of /usr/lib/qt3/libqt-mt.prl Well, at least it works for me, my smplayer is now in qt4 :p
Created attachment 122693 [details, diff] qmakeconf_pathfix.patch The patch mentioned one post earlier ;)
0.5.21 is out, just bumping these ebuilds works here. Btw., is someone still working on this? There is a new developer version out, this time it's a "real" qt4 port. -> http://smplayer.sourceforge.net/porting/smplayer-0.5.29-qt4-0701-2.tar.gz
I've added ebuilds for smplayer and smplayer-themes to the berkano overlay (available in layman and http://svn.liveforge.org/berkano/trunk/ ).
i686-pc-linux-gnu-gcc -I../libswscale -I../libavcodec -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -W -Wall -O2 -march=athlon-xp -mtune=athlon-xp -pipe -g3 -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/X11R6/include -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -DPNG_NO_MMX_CODE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -c -o imc.o imc.c In file included from dsputil.h:34, from h264.c:30: avcodec.h:2252: warning: 'ImgReSampleContext' is deprecated avcodec.h:2258: warning: 'ImgReSampleContext' is deprecated h264.c: In function 'fill_caches': h264.c:268: warning: comparison between signed and unsigned h264.c:436: warning: comparison between signed and unsigned h264.c: In function 'check_intra_pred_mode': h264.c:681: warning: comparison between signed and unsigned h264.c: In function 'direct_dist_scale_factor': h264.c:974: warning: comparison between signed and unsigned h264.c:986: warning: comparison between signed and unsigned h264.c: In function 'direct_ref_list_init': h264.c:1003: warning: comparison between signed and unsigned h264.c:1012: warning: comparison between signed and unsigned h264.c: In function 'write_back_motion': h264.c:1347: warning: comparison between signed and unsigned h264.c: In function 'decode_rbsp_trailing': h264.c:1459: warning: unused parameter 'h' h264.c: In function 'h264_luma_dc_dequant_idct_c': h264.c:1476: warning: unused parameter 'qp' h264.c: In function 'chroma_dc_dequant_idct_c': h264.c:1555: warning: unused parameter 'qp' h264.c: In function 'pred4x4_vertical_c': h264.c:1686: warning: unused parameter 'topright' h264.c: In function 'pred4x4_horizontal_c': h264.c:1694: warning: unused parameter 'topright' h264.c: In function 'pred4x4_dc_c': h264.c:1701: warning: unused parameter 'topright' h264.c: In function 'pred4x4_left_dc_c': h264.c:1711: warning: unused parameter 'topright' h264.c: In function 'pred4x4_top_dc_c': h264.c:1720: warning: unused parameter 'topright' h264.c: In function 'pred4x4_128_dc_c': h264.c:1729: warning: unused parameter 'topright' h264.c: In function 'pred4x4_down_right_c': h264.c:1755: warning: unused parameter 'topright' h264.c: In function 'pred4x4_vertical_right_c': h264.c:1801: warning: unused parameter 'topright' h264.c: In function 'pred4x4_horizontal_up_c': h264.c:1846: warning: unused parameter 'topright' h264.c: In function 'pred4x4_horizontal_down_c': h264.c:1867: warning: unused parameter 'topright' h264.c: In function 'pred8x8l_128_dc_c': h264.c:2195: warning: unused parameter 'has_topleft' h264.c:2195: warning: unused parameter 'has_topright' h264.c: In function 'pred8x8l_left_dc_c': h264.c:2199: warning: unused parameter 'has_topright' h264.c: In function 'pred8x8l_horizontal_c': h264.c:2219: warning: unused parameter 'has_topright' h264.c: In function 'pred8x8l_horizontal_up_c': h264.c:2367: warning: unused parameter 'has_topright' h264.c: In function 'hl_decode_mb_internal': h264.c:3200: warning: comparison between signed and unsigned h264.c:3205: warning: suggest parentheses around arithmetic in operand of ^ h264.c:3211: warning: suggest parentheses around arithmetic in operand of ^ h264.c: In function 'fill_default_ref_list': h264.c:3521: warning: comparison between signed and unsigned h264.c:3533: warning: comparison between signed and unsigned h264.c:3549: warning: comparison between signed and unsigned h264.c:3565: warning: comparison between signed and unsigned h264.c: In function 'decode_ref_pic_list_reordering': h264.c:3598: warning: comparison between signed and unsigned h264.c:3613: warning: comparison between signed and unsigned h264.c:3622: warning: comparison between signed and unsigned h264.c:3661: warning: comparison between signed and unsigned h264.c:3677: warning: comparison between signed and unsigned h264.c:3678: warning: comparison between signed and unsigned h264.c: In function 'fill_mbaff_ref_list': h264.c:3693: warning: comparison between signed and unsigned h264.c:3711: warning: comparison between signed and unsigned h264.c:3712: warning: comparison between signed and unsigned h264.c: In function 'pred_weight_table': h264.c:3732: warning: comparison between signed and unsigned h264.c: In function 'implicit_weight_table': h264.c:3788: warning: comparison between signed and unsigned h264.c:3790: warning: comparison between signed and unsigned h264.c: In function 'print_short_term': h264.c:3905: warning: comparison between signed and unsigned h264.c: In function 'decode_slice_header': h264.c:4253: warning: comparison between signed and unsigned h264.c:4277: warning: comparison between signed and unsigned h264.c:4343: warning: comparison between signed and unsigned h264.c:4344: warning: comparison between signed and unsigned h264.c: In function 'decode_residual': h264.c:4590: warning: comparison between signed and unsigned h264.c: In function 'decode_mb_cavlc': h264.c: In function 'decode_cabac_residual': h264.c:5786: warning: passing argument 4 of 'decode_significance_8x8_x86' discards qualifiers from pointer target type h264.c:5713: warning: unused variable 'last' h264.c: In function 'decode_mb_cabac': h264.c: In function 'filter_mb_fast': h264.c:6741: warning: dereferencing type-punned pointer will break strict-aliasing rules h264.c: In function 'decode_unregistered_user_data': h264.c:7233: warning: comparison between signed and unsigned h264.c: In function 'decode_hrd_parameters': h264.c:7283: warning: unused parameter 'sps' In file included from h264.c:8277: svq3.c: In function 'pred4x4_down_left_svq3_c': svq3.c:183: warning: unused parameter 'topright' svq3.c: In function 'svq3_decode_block': svq3.c:224: warning: comparison between signed and unsigned svq3.c: In function 'svq3_mc_dir': svq3.c:374: warning: comparison between signed and unsigned svq3.c:374: warning: comparison between signed and unsigned svq3.c: In function 'svq3_decode_mb': svq3.c:450: warning: comparison between signed and unsigned svq3.c: In function 'svq3_decode_slice_header': svq3.c:740: warning: comparison between signed and unsigned svq3.c: At top level: svq3.c:1015: warning: missing initializer svq3.c:1015: warning: (near initialization for 'svq3_decoder.next') cabac.h:113: warning: 'put_cabac_static' defined but not used cabac.h:159: warning: 'put_cabac_terminate' defined but not used cabac.h:187: warning: 'put_cabac_u' defined but not used cabac.h:222: warning: 'put_cabac_ueg' defined but not used cabac.h:274: warning: 'refill2' defined but not used cabac.h:812: warning: 'get_cabac_u' defined but not used cabac.h:828: warning: 'get_cabac_ueg' defined but not used cabac.h: In function 'get_cabac_noinline': cabac.h:526: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' make[1]: *** [h264.o] Error 1 make[1]: *** Waiting for unfinished jobs.... In file included from imc.c:40: avcodec.h:2252: warning: 'ImgReSampleContext' is deprecated avcodec.h:2258: warning: 'ImgReSampleContext' is deprecated imc.c: In function 'imc_calculate_coeffs': imc.c:149: warning: unused parameter 'q' imc.c: In function 'imc_decode_level_coefficients': imc.c:229: warning: unused parameter 'q' imc.c: In function 'imc_decode_level_coefficients2': imc.c:263: warning: unused parameter 'q' make[1]: Leaving directory `/var/tmp/portage/media-video/mplayer-1.0.20070622-r1/work/mplayer-20070622/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2
My apologies, please ignore. This thing changed the bug I was working on for no apparent reason.
Created attachment 130253 [details] media-video/smplayer-0.5.51.ebuild New ebuild, with (almost full ;) qt4 support. I think it still needs qt4 with "qt3support" flag enabled. Happy testing. (:
(In reply to comment #22) > I've added ebuilds for smplayer and smplayer-themes to the berkano overlay > (available in layman and http://svn.liveforge.org/berkano/trunk/ ). And since berkano looks a little old, both mentioned ebuilds are also in arcon-portage ( http://miniurl.pl/arcon-portage ).
I've put the new version of smplayer-themes into berkano overlay. SMPlayer itself is still at 0.5.21, which is the latest stable release.
*** Bug 193747 has been marked as a duplicate of this bug. ***
Hi :) I can only add that the ebuild from berkano overlay (smplayer-0.5.60) has worked perfectly fine form me :-) I have to agree that this is a great (the best I've used) frontend for mplayer and it really should find it's way to portage :-) Regards, Maciek
Created attachment 133104 [details] smplayer-0.5.60.ebuild I've modified the ebuild a bit. I included smplayer-themes in the ebuild (maybe that isn't the best idea.) and I've replaced einstall, because maybe one could make use of the LINGUAS variable and only install the translations that are needed. It might be, that this is not necessary. Nevertheless, the ebuild should have an USE variable themes, since it might be, that not everyone wants to install the extra themes.
Created attachment 133253 [details] smplayer-0.5.60.ebuild Cosmetic change, replace icon install with a more elegant solution. - insinto /usr/share/icons/hicolor/64x64/apps/ - doins "${S}"/icons/${PN}_icon64.png - insinto /usr/share/icons/hicolor/32x32/apps/ - doins "${S}"/icons/${PN}_icon32.png - insinto /usr/share/icons/hicolor/22x22/apps/ - doins "${S}"/icons/${PN}_icon22.png - insinto /usr/share/icons/hicolor/16x16/apps/ - doins "${S}"/icons/${PN}_icon16.png + for res in 16 22 32 64 ; do + insinto /usr/share/icons/hicolor/${res}x${res}/apps + doins "${S}"/icons/${PN}_icon${res}.png + done
Created attachment 133328 [details] smplayer-0.5.60.ebuild - Support for LINGUAS; - Use eqmake4 to process smplayer.pro which is much better than directly invoking qmake like the Makefile does; - sed the Makefile to set paths, this way we can directly use emake install in src_install() without any further modification; - fix the Makefile to allow parallel building.
Created attachment 133329 [details] smplayer-themes-0.1.12.ebuild
(In reply to comment #32) > Created an attachment (id=133328) [edit] > smplayer-0.5.60.ebuild smplayer won't build if x11-libs/qt:4 is built without qt3support, so the ebuild should check for that, I think? Here's the error if qt:4 is built without qt3support: i686-pc-linux-gnu-g++ -c -pipe -O2 -march=prescott -pipe -fomit-frame-pointer -W all -W -D_REENTRANT -DDATA_PATH=\"/usr/share/smplayer\" -DDOC_PATH=\"/usr/share/ doc/smplayer-0.5.60\" -DTRANSLATION_PATH=\"/usr/share/smplayer/translations\" -D CONF_PATH=\"/etc/smplayer\" -DTHEMES_PATH=\"/usr/share/smplayer/themes\" -DSHORT CUTS_PATH=\"/usr/share/smplayer/shortcuts\" -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETW ORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I/var/tmp/portage/media-video/smplayer-0.5.60/work/smplayer-0.5.60/src -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I.moc -I.ui -o .obj/logwindow.o logwindow.cpp In file included from logwindow.h:22, from logwindow.cpp:19: .ui/ui_logwindowbase.h:13:42: error: Qt3Support/Q3MimeSourceFactory: No such file or directory make[1]: *** [.obj/logwindow.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/smplayer-0.5.60/work/smplayer-0.5.60/src' make: *** [src/smplayer] Error 2 After rebuilding qt:4 with qt3support, smplayer builds fine.
Created attachment 136800 [details] media-video/smplayer-0.5.21.ebuild Current stable ebuild as in berkano overlay.
Created attachment 136801 [details] media-video/smplayer-0.5.62.ebuild Current development version ebuild as in berkano overlay.
Created attachment 136803 [details] x11-themes/smplayer-themes-0.1.14.ebuild Current themes ebuild as in berkano overlay.
Created attachment 136820 [details] smplayer-0.5.62.ebuild Version 0.5.62 is now considered stable by upstream. Ben, what's wrong with my ebuilds?
(In reply to comment #38) > Version 0.5.62 is now considered stable by upstream. Ah. I hadn't seen any announcement on that, but looking at the website it seems to be that way indeed. > Ben, what's wrong with my ebuilds? Nothing in itself, apart from the fact that I think they are unnecessarily complicated.
(In reply to comment #39) > (In reply to comment #38) > > Ben, what's wrong with my ebuilds? > > Nothing in itself, apart from the fact that I think they are unnecessarily > complicated. > Well, I thought that the preferred way to deal with qmake-based packages was to use eqmake{3,4} from qt{3,4}.eclass. This is what my ebuild does. Furthermore it fixes the Makefile to allow parallel building. The remaining part is a bit of bash code that maps smplayer languages to Gentoo's LINGUAS variable, to have better support for translations. This last part may seem a bit complicated, but it is necessary imho as I did not find a better solution; if you have one, please share it with us ;) The ebuild now also checks whether x11-libs/qt:4 was built with USE="qt3support" and dies if that flag is missing.
(In reply to comment #40) > (In reply to comment #39) > > (In reply to comment #38) > > > Ben, what's wrong with my ebuilds? > > > > Nothing in itself, apart from the fact that I think they are unnecessarily > > complicated. > > > > Well, I thought that the preferred way to deal with qmake-based packages was to > use eqmake{3,4} from qt{3,4}.eclass. This is what my ebuild does. Furthermore > it fixes the Makefile to allow parallel building. > The remaining part is a bit of bash code that maps smplayer languages to > Gentoo's LINGUAS variable, to have better support for translations. This last > part may seem a bit complicated, but it is necessary imho as I did not find a > better solution; if you have one, please share it with us ;) > The ebuild now also checks whether x11-libs/qt:4 was built with > USE="qt3support" and dies if that flag is missing. > actually I prefer this ebuild, but with some modifications: - use mirror://sourceforge for src_uri - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks - that way you can probably drop EAPI=1 - why does it have RESTRICT="mirror" ? - can't you make the linguas support simpler ? it seems a bit over complicated, but, well, I haven't been thinking about how to simplify it
(In reply to comment #41) > actually I prefer this ebuild, but with some modifications: > - use mirror://sourceforge for src_uri Yep, I forgot that one! ;-) > - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks > - that way you can probably drop EAPI=1 You're right. > - why does it have RESTRICT="mirror" ? Just because that ebuild was hosted on my overlay and since the tarball is not on Gentoo mirrors, there was no reason in trying to download from them... I just forgot to remove that line before attaching the ebuild here. > - can't you make the linguas support simpler ? it seems a bit over complicated, > but, well, I haven't been thinking about how to simplify it > I may try to have another look at it in the next weekend, because i'm very busy till friday. The problem is that some of the abbreviations that smplayer uses for its translations aren't the same as Gentoo's LINGUAS variable, so I had to map smplayer languages to gentoo's ones (or viceversa).
(In reply to comment #42) > (In reply to comment #41) > > - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks > > - that way you can probably drop EAPI=1 > > You're right. Imho it would be preferred to use EAPI=1, so you can replace the $(qt4-min-version) hack with something like ">=x11-libs/qt-${minver}:4", with $minver being the minimal required Qt4 version to compile Smplayer.
(In reply to comment #43) > (In reply to comment #42) > > (In reply to comment #41) > > > > - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks > > > - that way you can probably drop EAPI=1 > > > > You're right. > > Imho it would be preferred to use EAPI=1, so you can replace the > $(qt4-min-version) hack with something like ">=x11-libs/qt-${minver}:4", with > $minver being the minimal required Qt4 version to compile Smplayer. > yes but this should go into qt4.eclass, feel free to open a bug against it if you think its worth it. Imho the point of qt4-min-version is to not have to worry about such things.
(In reply to comment #44) > (In reply to comment #43) > > (In reply to comment #42) > > > (In reply to comment #41) > > > > > > - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks > > > > - that way you can probably drop EAPI=1 > > > > > > You're right. > > > > Imho it would be preferred to use EAPI=1, so you can replace the > > $(qt4-min-version) hack with something like ">=x11-libs/qt-${minver}:4", with > > $minver being the minimal required Qt4 version to compile Smplayer. > > > > yes but this should go into qt4.eclass, feel free to open a bug against it if > you think its worth it. Imho the point of qt4-min-version is to not have to > worry about such things. > (In reply to comment #44) > (In reply to comment #43) > > (In reply to comment #42) > > > (In reply to comment #41) > > > > > > - use QT4_BUILT_WITH_USE_CHECK="qt3support" to let qt4.eclass do its own checks > > > > - that way you can probably drop EAPI=1 > > > > > > You're right. > > > > Imho it would be preferred to use EAPI=1, so you can replace the > > $(qt4-min-version) hack with something like ">=x11-libs/qt-${minver}:4", with > > $minver being the minimal required Qt4 version to compile Smplayer. > > > > yes but this should go into qt4.eclass, feel free to open a bug against it if > you think its worth it. An eclass can't use EAPI=1 and be backwards compatible at the same time, so the $(qt4-min-version) will probably stay as is for a long time. > Imho the point of qt4-min-version is to not have to > worry about such things. Maybe I'm missing something, but I don't see what the worry is here ? Instead of using $(qt4-min-version 4.3.2), you just DEPEND=">=x11-libs/qt-4.3.2:${SLOT}" where the $PV is the bottom range, and the SLOT provides a top range?
Created attachment 139052 [details] smplayer-0.5.62.ebuild Reviewed ebuild, applied the changes suggested by Alexis Ballier. I could not find a better/simpler way to deal with languages though.
added to the tree, thanks a lot ! I've only put a ~amd64 keyword as its my main desktop box; if you want ~arch for your arch, please open a bug asking for it. wrt qt4_min_version & eapi 1, there is no real worry about it but slot deps do not provide any gain there as far as I know, so using eapi 1 just for the sake of using it is pointless imho ;)
