Created attachment 371420 [details] dtv-scan-tables-9999.ebuild dtv-scan-tables provides initial scan codes for digital tv. Gentoo currently relies on the unmaintained media-tv/linuxtv-dvb-apps for scan codes. dtv-scan-tables was split from linuxtv-dvb-apps and moved into its own repository. Please consider adding dtv-scan-tables to the Portage tree because applications such as media-tv/tvheadend no longer support the old scan codes provided by linuxtv-dvb-apps. For now I have only provided a live ebuild. There are tarball releases[1] of dtv-scan-tables but they are not versioned. [1] http://linuxtv.org/downloads/dtv-scan-tables/
the dvb-apps ARE maintained, albeit very 'slowly'. Tarballs are automatically created after each commit, their 'hash' versioned ;) Oliver, dtv-scan-tables maintainer
(In reply to Oliver Schinagl from comment #1) > the dvb-apps ARE maintained, albeit very 'slowly'. > > Tarballs are automatically created after each commit, their 'hash' versioned > ;) > > Oliver, dtv-scan-tables maintainer Any chance we could have the creation date appended to the tarball name?
Created attachment 373576 [details] dtv-scan-tables-9999.ebuild Clean up src_install
Created attachment 373614 [details] dtv-scan-tables-20140309.ebuild Add snapshot
@Oliver What is the correct license for the scan tables? I see that Fedora has chosen public domain but the source ships with GPL-2 & LGPL-2.1 license files.
The tarballs where supposed to be dated; but something bad happened and it didn't work out just right. They should be generated daily, if there are changes. As for the license, this was discussed a little before, but it was decided to keep whatever license was on the dvb-apps. http://www.spinics.net/lists/linux-media/msg58594.html
A new tarball with modified date '2014-06-02' has the date and commit hash '2014-03-26-cfc2975' for it's filename. However upon extraction the tarball is actually git head, so the date and commit hash should be '2014-05-12-1246b27'. We really need to have the tarball creation issue sorted as it makes packaging releases impossible.
Created attachment 389354 [details] dtv-scan-tables-9999.ebuild - Add media-tv/v4l-utils dependency - Use Makefile to install files. Default install location is /usr/share/dvbv3 for legacy format and /usr/share/dvbv5 for new format. I'm not sure if this will break some applications. We might need to install at /usr/share/dvb/{dvbv3,dvbv5}.
Created attachment 389466 [details] dtv-scan-tables-9999.ebuild - Move media-tv/v4l-utils dependency to DEPEND
Created attachment 442066 [details] dtv-scan-tables ebuild My take on a non-live ebuild (v5 only). The full archive contains 1800 files therefore this has some potential USE_EXPAND flags, dtv_delivery_systems and dtv_countries. Clearly these would need documenting in profiles/desc/. It downloads a snapshot from the cgit interface. As noted the file naming in: http://linuxtv.org/downloads/dtv-scan-tables/ is a bit off. (the log page in cgit seems to miss the latest entries too, the summary is OK).
Created attachment 495976 [details] dtv-scan-tables-9999.ebuild - Bump for EAPI 6
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eb84f08c04519b2273a8d6729039e783b70eafc1 commit eb84f08c04519b2273a8d6729039e783b70eafc1 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2017-11-26 22:49:59 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2017-11-26 22:50:39 +0000 media-tv/dtv-scan-tables: New package to supersede linuxtv-dvb-apps This doesn't need to block linuxtv-dvb-apps as they install the tables into different directories. Closes: https://bugs.gentoo.org/503028 Package-Manager: Portage-2.3.16, Repoman-2.3.6 media-tv/dtv-scan-tables/Manifest | 1 + .../dtv-scan-tables-0_p20171003.ebuild | 32 ++++++++++++++++++++++ .../dtv-scan-tables/dtv-scan-tables-9999.ebuild | 32 ++++++++++++++++++++++ media-tv/dtv-scan-tables/metadata.xml | 8 ++++++ 4 files changed, 73 insertions(+)
Thanks for the contribution here, it helped me to come up with the final ebuild. USE_EXPAND could be worthwhile but I'll revisit this later.
