| Summary: | xmltv-0.5.63 is available | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Ken Dreyer <ktdreyer> |
| Component: | xmltv | Assignee: | Nicolas Chauvet <kwizart> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | hobbes1069 |
| Priority: | P5 | ||
| Version: | 19 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
| Attachments: | rawhide patch: make Text::Kakasi optional | ||
|
Description
Ken Dreyer
2012-07-02 17:28:51 CEST
xmltv on EL-6 only miss perl-Text-Kakasi. I've requested the maintainer for an EL-6 branch to get get compliant and equivalent with the fedora spec. For the xmltv package update. This usually needs the latest version in order to work, since some website used by the related grabber might have changed of layout. xmltv update often means: - bump version - Verify that new BR have been added. - Verify that new BR have been removed - basic test for your own locale. With that said, you can sugguest a patch. One room of improvement I would suggest would be to split the differents grabbers so installing only the interesting grabber doesn't bring the dependencies from all grabber. I di(In reply to comment #1) > xmltv on EL-6 only miss perl-Text-Kakasi. I've requested the maintainer for an > EL-6 branch to get get compliant and equivalent with the fedora spec. FYI I did the same yesterday, and he replied he wasn't interested. There are two packages: the perl-text-kakasi one, and the kakasi one. Since I'm unfamiliar with Japanese or i18n libraries, I plan to just patch out the Japanese grabber for EL-6 until someone volunteers to maintain the Kakasi deps in EPEL. (In reply to comment #2) ... > FYI I did the same yesterday, and he replied he wasn't interested. There are > two packages: the perl-text-kakasi one, and the kakasi one. Since I'm > unfamiliar with Japanese or i18n libraries, I plan to just patch out the > Japanese grabber for EL-6 until someone volunteers to maintain the Kakasi deps > in EPEL. There is no need to patch out the grabber, just %if 0{?fedora} the related perl BR. Created attachment 922 [details]
rawhide patch: make Text::Kakasi optional
Cool, please apply this patch to rawhide if it looks ok to you.
Seems ok. What about a version bump ? (with the process described from c#1). (In reply to comment #5) > Seems ok. > What about a version bump ? (with the process described from c#1). If it's all the same to you, I'd prefer to get the EL-6 build out (Bug 34). I was just hoping to keep Rawhide in sync with any EL-6 changes. (In reply to comment #6) > (In reply to comment #5) > > Seems ok. > > What about a version bump ? (with the process described from c#1). > > If it's all the same to you, I'd prefer to get the EL-6 build out (Bug 34). I > was just hoping to keep Rawhide in sync with any EL-6 changes. I don't understand what you mean by that. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Seems ok. > > > What about a version bump ? (with the process described from c#1). > > > > If it's all the same to you, I'd prefer to get the EL-6 build out (Bug 34). I > > was just hoping to keep Rawhide in sync with any EL-6 changes. > > I don't understand what you mean by that. I would prefer to do the following: 1. Get this patch into Rawhide 2. Get xmltv built for EL-6 (bug 34) 3. Research what it would be involved with bumping xmltv to 0.5.63 in Rawhide 4. After xmltv has been at 0.5.63 in a stable version of Fedora, we can upgrade EL-6 to 0.5.63. Ok, but you probably missed something from c#1. I meant that xmltv usually need the latest version because some grabber might be broken. Now your point 3. is part of a review process that I request to every packager requesting ACL on a package where I'm the primary maintainer. Otherwise your plan is good. |