Xawdecode-1.9.1 has been released (follow the URL for Changelog). I've made a few minor changes to the ebuild: - added "xinerama" USE flag, to enable/disable xinerama support - xawdecode now supports both xvid API version 2.1 (xvid-0.9x) and 4.0 (xvid 1.0 or its -rc). I've changed the dep to xvid-1*, to avoid some issues described in bug #41157. I've also added a small fix to configure for xvid header detection. - CPU type detection in configure seems broken (it returns me i586 on a PentiumM machine), so i've disabled it. Thus I've forced using user CFLAGS instead of the default ones. I've tested a rather wide variety of CFLAGS without trouble, and I think it is better (more gentooish) this way. - added doc files for aletv - fixed the 'lcd' font installation (it was installing both the pcf and the pcf.gz)
Created attachment 29490 [details] xawdecode-1.9.1.ebuild
Something I forgot to say is that it would be nice to be able to disable the non-free divx4linux codec, like suggested in bug #18964. I've not used the 'divx4linux' USE flag suggested there, because I was not sure it had been approved yet, but if it is, it should be used instead of 'x86'.
Adding a dependency on bug #47838 because fixing the symlinks of the xvid lib is required for xawdecode to work properly (it links against .so.4, which is missing).
Another new version has been released. I will attach an ebuilds, with the following changes: - now use the "divx4linux" global use flag (thanks to whoever finally added it) - now use font.eclass to install the OSD font in /usr/share/fonts - added an einfo about this fontpath change
Created attachment 34031 [details] xawdecode-1.9.2.ebuild
Oops, sorry, I forgot to add "divx4linux" to IUSE. Patch : - IUSE="alsa jpeg encode ffmpeg xvid lirc xosd xinerama" + IUSE="alsa jpeg encode ffmpeg xvid lirc xosd xinerama divx4linux"
builds and works fine for me.
wouldn't it be bad if the ebuild makes use the +Xaw3d flag to take precedence over neXtaw if both are present?
Created attachment 34511 [details] xawdecode-1.9.2.ebuild (with xaw widgets choice) Thanks for your comments dju`. You're right, that xaw dep was not really good. What i've done in this version of the ebuild is: - with no special use flag, uses the default xaw widgets from x11 (and print a warning since it may be seen as a regression by some users). - with "Xaw3d" only, uses Xaw3d. This flag is already a global USE flag. - with "neXt" only, uses neXtaw. This flag already exists as a local flag for xemacs. It may be a good candidate to become global. - with both of the above, it defaults to neXtaw. I think that's a good thing in general to make this kind of choices deterministic (as opposed to detected by configure script): this way, the /var/db/pkg deps precisly match the binary (ldd) deps.
maybe it's a job for virtuals...
That's what i've also thought first, but i don't think that's really a good idea: - i don't think it worths a new virtual: only a very few packages seems to give choice on what xawlib to use, and i've found none that allows both Xaw3d and neXtaw as alternatives. So this virtual would be usable only by xawdecode. - a virtual would not guarantee a strong enough backward dep, so it could leads to situations where depclean thinks it is safe, for instance, to remove xaw3d because nextaw is installed, whereas in fact xawdecode is still linked against xaw3d. Imho, virtuals should only be used when one can safely, at any time, replace one of its concrete packages by another without breaking anything (i know there is revdep-rebuild to correct this kind of breakage afteward, but it's not really a clean solution). - if a user prefer the xaw3d style but also has neXtaw installed because of another package, then he would not be able to force the use of xaw3d (the configure script will choose nextaw iirc).
1.9.1 is in cvs now
Created attachment 38940 [details] xawdecode-1.9.3.ebuild Thanks Martin for the 1.9.1. Here is updated ebuild for 1.9.3. The only ebuild change since 1.9.2 is that dependency on xosd is removed (a version of the lib is now included to the xawdecode src).
Xawdecode 2.0.0 has been released. Starting from this version, the program has been renamed upstream Xdtv. I will attach an updated ebuild, with only minor changes compared to the 1.9.3 one.
Created attachment 43832 [details] media-tv/xdtv/xdtv-2.0.0.ebuild
ok for me, except a: /usr/lib/portage/bin/dodoc: README does not exist.
Thanks for your test. > /usr/lib/portage/bin/dodoc: README does not exist. yep, it comes from font.eclass, but won't hurt.
*** Bug 72142 has been marked as a duplicate of this bug. ***
Created attachment 46121 [details] Ebuild with debug, xv, zvbi, dga and pic use-flags This ebuild adds support for debug, xv, zvbi, dga and pic use-flags. It also make the dependency on zvbi optional (with zvbi use-flag).
XdTV 2.0.1 is out!! Changes: * December 2004: Minor bugfixes release 2.0.1: * Fix bugs in channels & frequency management. * Adds & Updates frequency tables for China, Argentina, South Africa etc... * Update the Xosd library to the new 2.2.14 version & fix a segfault if Xosd is not used. * XdTV works now with FFmpeg 4736: add the support for both huffyuv & huffyuv (only if FFmpeg >= 4734) * Fix a segfault if the memcpy SSE optimization is used. * Add a new parameter: -nodecoinit to resolve the start error with fvwm / fvwm2 * Apply several patchs (Thanks to Mr Moustache, Hiroshi Hasebe & shtrom@users.sourceforge.net)
Created attachment 46296 [details] 2.0.1 ebuild Updated the ebuild to version 2.0.1 (version bump).
I'm not big on some of this USE flags you've added guys. As-is, the debug is almost useless (you should add -g to CFLAGS if that's really what you want). Also, i see really no benefit to the xv and dga flags. The X extensions are detected at runtime and used only if available, so why do you want to force them off at compile time? For most users, it will mean the following: - emerge xdtv - try it, realize it's damn slow - try to figure why, dig the google or add noise on the ML - finally understand, add xv and dga flags, and re-emerge So for now, i think it's a bad idea (until you prove me wrong sure). Having one USE flag per configure option is not a reasonable goal, i prefer to try to just give the user the choices he really wants to make. About the pic flag, i don't know. Can you elaborate on why it is useful for you to build xdtv in pic mode? And for zvbi, well, why not. Since zvbi is an additional dependency that some people won't really use, that makes more sense.
About debug flag, yes I know it's incomplete, but it's better than nothing. Actually I don't know how many people uses the debug flag, I usually don't use it because if I'm debugging something I install it on my own. Instead about xv and dga I'm quite sure of adding them. First of all, it's the same method xine, mplayer and so on are using, then both are global flags. Also, xv is enabled by default (at least on x86), make it quite secure for users. Instead dga is not enabled by default, and IIRC this is good because dga requires access to some devices which can lead to security problems. And if they simply set -xv without knowing what they are doing, they should rtfm ^^
> About debug flag, yes I know it's incomplete, but it's better than nothing. No. A bug is worst than nothing. Once fixed, this flag would be acceptable, but not as long as it is known-broken. > Instead about xv and dga I'm quite sure of adding them. You still didn't explain what it would be useful for, whereas there is already both some autodetection and command line options on runtime side. Please keep in mind that more use flags is also more work for maintenance of the ebuild (more tests on the various combinations for instance, or potential bugs when you allow some unusual configuration, etc.). It's ok when the additional choices adds some value, but not when we can be confident that everybody will at the end enable the same flags. > First of all, it's the same method xine, mplayer and so on are using That's very different, mplayer and xine have support for many different display libraries some of which are not even related to X11. With the right USE flags, mplayer can be compiled on a framebuffer only system for instance. Here the choice adds some value to the package. At the contrary, xdtv is an X11-only app, and people really do want xv to be in. > Also, xv is enabled by default (at least on x86) Oh, yes, right, i had forgotten that. > dga requires access to some devices which can lead to security problems. And? If user don't have rights to use DGA, xdtv will not use it. And if he has the rights, i don't see how disabling support for it in xdtv would make your system more secure or anything. I still don't get the point.
> No. A bug is worst than nothing. Once fixed, this flag would be acceptable, but not as long as it is known-broken. CFLAGS can be changed by user out of emerge, instead if I simply let xdtv use --enable-nodebug, this will make the debug impossible. > And? If user don't have rights to use DGA, xdtv will not use it. And if he has the rights, i don't see how disabling support for it in xdtv would make your system more secure or anything. I still don't get the point. I frankly think that being able to disable that a compile time is a good thing. Someone can simply have the smaller executable possible, and then remove all the code it doesn't want. For example I removed both dga and xv because I use xdtv only to grab to disk, so the display doesn't matter to me.
> CFLAGS can be changed by user out of emerge, instead if I simply let xdtv use > --enable-nodebug, this will make the debug impossible. You didn't look at what --disable-nodebug really does. It's only single effect is to add -g to CFLAG. Since we then force the CFLAG to the user's one, it has absolutly no effect with the ebuild. So if you want a debug use flag, do something like: use debug && CFLAGS="${CFLAGS} -g" But seriously, i don't see why it should be done more in xdtv ebuild that in any other ebuild. As you said, CFLAGS can be changed by the user out of emerge when needed. > Someone can simply have the smaller executable possible, and then remove all > the code it doesn't want. For example I removed both dga and xv because I use > xdtv only to grab to disk, so the display doesn't matter to me. That will make a 20KB difference on an ~1.7MB executable... That's a ridiculous gain at the price of having only an half working app. With xdtv-3, it will be possible to build the xdtv core without the GUI part or the display part. Then it will be interesting to have more USE flags to build for instance a video-recording only version of the software. But currently, we simply can't.
Created attachment 46408 [details] Revised 2.0.1 ebuild Ok sorry about the --enable-nodebug and so, I thought it enabled/disabled also other things like NDEBUG and so on. I removed the debug useflag. I also removed the pic useflag.. in fact it was quite misleading. I still think that adding xv/dga useflags could be useful. DGA support imho is not necessary to everyone, and disabling it doesn't make much damage (xv is enabled by default, who wants to mess with xv should know what it does). As I said, I'm quite a minimalist when it comes to compile, and I disabled them both. This revised ebuild has a quite rough hack inside, to fix the xdtv.desktop file (which misses the Encoding parameter), and to fix icons installation: this ebuild instead that in /usr/share/xdtv/icons install the icons inside /usr/share/icons/hicolor structure (and /usr/share/pixmaps for xdtv.xpm icon). As I said, it's just an hack, but for me it works, and I still prefer to be more standard possible. [Attachment of revised xdtv.desktop follow]
Created attachment 46409 [details] Revised xdtv.desktop
Created attachment 50588 [details] Revised ebuild (newly) I've fixed my own changes. The icon was installing in the wrong place, now it's fixed. Also I removed the old /usr/share/pixmaps file, as it should no more used.
I think that dependency was inverted.. as xawdecode can't block xvid :) Anyway, that bug is fixed, no news about this ebuild?
News: new upstream version 2.1.0 available. I bumped the 2.0.1 ebuild above and changed the SRC_URI to use .tar.gz instead of .bz2. It compiles and installs.
Created attachment 52716 [details] xdtv-2.1.0.ebuild Oops, yep, completly forgot to submit that one :) This version adds support for i18n, plus a few random cleanups.
Created attachment 55181 [details] xdtv-2.1.1.ebuild Update for 2.1.1, with minor modifications for i18n/theme extensions installation.
Created attachment 55852 [details] xdtv-2.1.1.ebuild Some i18n updates (added DE + bump of ES and CA).
Created attachment 61326 [details] xdtv-2.2.0.ebuild Here is the 2.2.0 ebuild. Compared to the latest 2.1.x one, it adds a few more i18n/theme packages.
I don't know what exactly is the policy for using the new maintainer-*@ aliases, but since this package is completly outdated in portage, wouldn't it be a candidate for maintainer-needed@gentoo.org reassignement?
I'll take care of this soon. I have locally a little cleaned up ebuild with amd64 support and a patch to have mmx/sse support working on amd64 systems which I'm discussing with upstream about.
\o/ Alleluia \o/ Many thanks Diego, it's really good to hear that this package will finally be taken back to life in Portage. Oh, and don't hesitate to CC me when you get bugreports about xdtv, i would be pleased to help when i can.
*** Bug 66913 has been marked as a duplicate of this bug. ***
Thanks to all, now media-tv/xdtv-2.2.0 is in portage (just ~amd64 until it can be tested and marked on x86).
