The new version of xmltv, 0.5.51, is out since the 16th february. It can be found here : http://sourceforge.net/project/showfiles.php?group_id=39046 It's out for more than a week, so no kitten should have been killed. :) Thanks by advance. Reproducible: Always Steps to Reproduce:
Bump.... Come on some three months have passed and it's not even in portage masked?
(In reply to comment #1) > Bump.... Come on some three months have passed and it's not even in portage > masked? > It always goes much faster if someone has tested a new ebuild, posts results, and sends in a patch if necessary.
(In reply to comment #1) > Bump.... Come on some three months have passed and it's not even in portage > masked? > It comes that there aren't testers. I'll not test 25+ different countries scripts, with some of them being paid services, as it's obvious. And users still don't test them or just report issues after quite some time, as bug #213007 (as I'm using it script, I would never notice bug like that). More than this, latest versions of xmltv have quite some issue for me (5.51 gives me "FILM" instead of title/desc for almost any interesting program, and actually I'm really using web instead than xmltv), and as I already said, I'll test just the it script, so without reports why should I insert in portage a really useless verion of xmltv??? (h9:00 - Film , h11:00 - Film , h13:00 - News , h14:00 - Film , h16:00 - Film)
Created attachment 161597 [details] ebuild for xmltv-0.5.52 Slightly off topic but ebuild for 0.5.52 attached. This also addresses bug #213007. No changes to 0.5.50 except for version bump and adding dev-perl/XML-LibXML to RDEPEND.
The above ebuild using the uk_rt grabber installs fine, but I had to add dev-perl/IO-stringy and dev-perl/HTTP-Cache-Transparent to RDEPEND in order for it to run. But it works perfectly.
Created attachment 167295 [details] xmltv-0.5.53.ebuild
Comment on attachment 167295 [details] xmltv-0.5.53.ebuild The version of xmltv validated in portage is 0.5.50. But the URL to grab french programs since this version has changed... Then, I suggest to work to validate a more recent version. I have join the modified ebuild for version 0.5.53. This last release (0.5.53) was made on 2008-09-02 and correct some bugs : tv_grab_is: minor fix to midnight handling tv_grab_na_dd: add auto-config config file option tv_grab_na_icons: adjust to site changes tv_grab_ar: now supports 2 data sources tv_grab_uk_rt: improve episode numbering tv_grab_huro: fix --offset problem and data source changes tv_grab_eu_epgdata: added category support, stop times, age-rating, more! *NOTE* fix to _eu_epggdata episode num will break duplicate detection in MythTV tv_grab_dk - non-working, removed tv_grab_dk_dr - new grabber for Denmark! tv_grab_is: Islandic grabber returns And of some bugfixes and polish.
Comment on attachment 167295 [details] xmltv-0.5.53.ebuild N.B. : There is 2 news USE flags : is and es_miguiatv.
(In reply to comment #6) > Created an attachment (id=167295) [edit] > xmltv-0.5.53.ebuild Again, this works totally fine with the uk_rt grabber. I'm not sure if the dev-perl/IO-stringy and dev-perl/HTTP-Cache-Transparent dependencies are still an issue with this ebuild, they're still installed on my mythbox.
Created attachment 170036 [details, diff] uk_rt_io_stringy.diff I confirm G.K MacGregor's comment. I have uninstalled IO-stringy and HTTP-Cache-Transparent and I can confirm these 2 dependencies are required in order to xmltv to work for tv_grab_uk_rt. Then find "uk_rt_io_stringy.diff" in order to correct the suggested xmltv-0.5.3.ebuild It's difficult to have a perfect ebuild. There 3 solutions : 1. I have to write a program in order to test each languages. I need few hours to write the script and many hours to download TV guides from all countries. 2. He wo can do more can do less. That is to say, we had all dependencies for all countries even if there are maybe required for several countries. 3. We propose these ebuild "as is" and we correct it according the new bugs. Senior developpers, help me ;-) ! What is the best solution according the "Gentoo spirit" ?
I think an imperfect ebuild with an einfo warning is better than nothing. Current situation is that it's rotting quite heavily. Mask it at worst
Ok, I'm a newbie here so this may be totally stupid but what about a ebuild for the core xmltv files and then separate ebuilds for each of the grabbers. Pros - One the dependencies required get installed - Those with vested interests can maintain and test the grabber ebuilds - The whole package doesn't suffer bitrot because a few grabbers are unmaintained Cons - This is going to create a whole swarm of new ebuilds
I don't understand the problem? You can already add package dependencies based on USE flags? Probably I didn't read the thread thoroughly enough?
(In reply to comment #13) The problem, as I understand it, is that the maintainer is reluctant to release the new version of the ebuild as they are unable to ensure that all grabbers have the required dependencies fulfilled and are functioning correctly. Hence my suggestion to split. This allows people with access to the required resources (local tv web sites, EIT information, etc) to assume the responsibility of ensuring that all dependencies are met for 'their' grabber and that it works correctly.
(In reply to comment #14) In comment #11, Ed suggest to add an ewarn info and in comment #13, Wayne suggest to split ebuild. If I understand the Wayne's suggestion, more of 30 ebuilds would be needed (one by grabber)... For me, I prefer the Ed's suggestion. If a tv_grab fails, the user submit a bug on bugzilla (here for example) and I think we can resolve quickly the problem. I think, it's easiest to maintain only one ebuild. I have an interest to have the advice of a media-tv developer team...
Seems like a non event. Just bump it with ~ masked. If no more bugs come forward then usual unmasking after 30 days or whatever. I'm still missing the big picture though? Most of the dependencies are well known for each grabber? The cache module is used in a couple of grabbers from memory (although it's been a few years since I last looked) - certainly it's not a new module and I think it was originally added to cope with the old style RT site where multiple downloads were required? It used to be optional... Grep the code to find any other grabbers which use it However, it's a minor bug overall (possible missing runtime dependency). Just add a USE flag dependency and bump is my suggestion
The (In reply to comment #16) Thanks for your answer Ed. xmltv-0.5.53.ebuild is already masked : (...) KEYWORDS="~amd64 ~ppc ~sparc ~x86" (...) I don't understand about which dependencies you are talking about when you are saying "Just add a USE flag dependency" ?
If it's ok, who can commit the ebuild xmltv-0.5.53.ebuild ? (Don't forget to apply uk_rt_io_stringy.diff patch in these case).
Auch, I was overconfident to have solved this bug today adding 0.5.53 but missed the stringy dep, let's see what can I do.
Ok, I fixed the dep. issue for uk_rt. First I apologize for being away but atm I'm quite busy, sorry. Let me explain the situation for xmltv : debugging is getting harder has mainstream is often missing to specify clearly changes in deps and so on. I can test one or two grabber but there'll never be an extensive test of all the grabber without users. The use flags generated from metadata.xml is a step in the right direction but still many grabbers need users to test and report. Splitting the ebuild is a nonsense as there's almost no other dev willing to maintain xmltv so there would be just a couple of grabbers (feel free to became devs and deny that). I'll try to keep the ebuild more up to date in the future. This bug will remain open for a couple days.
Actually I tend to agree that if the upstream hasn't included dependencies (it's not on CPAN for example) then you are no worse off with a bumped ebuild than if you downloaded it outside the package manager. Hence my vote would be to bump first and file bugs if there are some minor deps missing... (hardly a big deal to add the deps manually) Probably not a bad idea if someone can take the time to drop upstream an email and ask them to start to document dependencies for downstream packagers... Thanks and good luck
Created attachment 179705 [details] xmltv-0.5.54.ebuild This is my proposal for xmltv-0.5.54 , will be in portage in a couple days if no one finds issues, and this bug will be finally closed.
(In reply to comment #22) > This is my proposal for xmltv-0.5.54 , will be in portage in a couple days if > no one finds issues, and this bug will be finally closed. > Again, works fine with the uk_rt grabber. I notice the two dev-perl dependencies mentioned before are now pulled in correctly by this new ebuild.
Finally in cvs, closing
