[mythtv-users] Anyone have binary RPMs for 0.27 build for Fedora?

[John Pilkington]

On 06/11/13 12:13, Anthony Messina wrote:
> On Wednesday, November 06, 2013 12:03:24 PM Stuart Morgan wrote:
>> On Wednesday 06 Nov 2013 10:09:04 John Pilkington wrote:
>>> Well, yum found it this morning in the updates-testing repo and I have
>>> it installed.  The date shown by Firefox is 5 Nov.  Thanks, Richard!
>>>
>>>
>>>
>>> 2013-11-06 09:25:10.659148 C  mythfrontend version: tag: v0.27 [317d5b7]
>>> www.mythtv.org
>>> 2013-11-06 09:25:10.659158 C  Qt version: compile: 4.8.5, runtime: 4.8.5
>>>
>>>
>>>
>>> The Changelog says it's an update to release 0.27, and I think that was
>>> 317d5b7, so I suspect it is in fact an earlier version than the one
>>> built from Richard's SRPM of 8 October.
>>
>> That is the 0.27 tag, not the latest from the 0.27-fixes branch, which is
>> unfortunate since the stated reason for waiting so long before releasing
>> 0.27  packages was to allow time for any major bugs to be found and fixed
>> ...
>>
>> There have been several bug fixes (of varying severity) committed to the
>> 0.27- fixes branch, none of which are included in that package.
>
> This may be a side effect of how MythTV determines what content to place in
> myth* --version.
>
> What used to work in the spec file was:
>
> # MythTV Version string -- preferably the output from git --describe
> %global vers_string v0.27-72-gea5af90
>
> # Git revision and branch ID
> %global _gitrev v0.27-0-g317d5b7
> %global branch fixes/0.27
>
>
> # Set the mythtv --version string
> cat > VERSION <<EOF
> SOURCE_VERSION=%{vers_string}
> BRANCH=%{branch}
> EOF
>
> But I think the compile process is not using VERSION to populate
> myth* --version any longer.  Either that or it's overwriting the information
> after the cat.  I have the same display with my RPMs, though I am using
> v0.27-72-gea5af90.
>
> Richard's RPMs likely include:
> http://cvs.rpmfusion.org/viewvc/rpms/mythtv/F-19/mythtv-0.27-fixes.patch?revision=1.1&root=free&view=markup
>
> So I think it's just a matter of getting the --version set properly in the
> spec file.
>
> -A

Yes.  I have the f18 SRPM on my SL6 machine, and it yields the 81 MB 
0.27 tarball and a 2.7 MB fixes patch.  It looks as if the build will be
up-to-date but the version report is still unreliable.