Bug 508503

Summary: Could not parse header: 'Tom "spot" Callaway...'
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: PackageKitAssignee: Richard Hughes <richard>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: beland, jonathan, pmatilai, rhughes, richard, rransom.8774, smparrish, tcallawa
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 22:13:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jens Petersen 2009-06-28 00:19:50 UTC
Description of problem:
I am "subscribing" to spot's chromium build repo and getting
a changelog parse error with each update.

Version-Release number of selected component (if applicable):
gnome-packagekit-2.27.2-1.fc11

How reproducible:
every time

Steps to Reproduce:
$ cat /etc/yum.repos.d/chromium.repo 
[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=1
gpgcheck=0
$ yum install chromium
$ sleep 1day
$ # see new chromimum appear in gpk and click on it
  
Actual results:
The developer logs will be shown as no description is available for this update:
Could not parse header: 'Tom "spot" Callaway <tcallawa>', expected: 'Firstname Lastname <email> - version-release'

Expected results:
no parse error

Comment 1 Richard Hughes 2009-06-30 11:42:19 UTC
The problem is that the %ChangeLog section in the .rpm is supposed to look like this:

* Mon Feb 02 2009 - Bastien Nocera <bnocera> - 0.10.13-2
- Patch for overflows in the QT demuxer (#481267)

and instead, spot has dropped the version tag, so something like this:

* Mon Feb 02 2009 - Bastien Nocera <bnocera>
- Patch for overflows in the QT demuxer (#481267)

This violates the Fedora rpm standards.

PackageKit uses the package version data in the ChangeLog to only show the user what changed between the version they have installed, and the new version, rather than a huge list of commits that go back several years.

I suggest you poke spot, and ask him to add back the version numbers in the ChangeLog. Thanks.

Comment 2 Tom "spot" Callaway 2009-06-30 18:53:53 UTC
Well, yes, I did screw up the versioning, but it is worth noting that an exception has been granted to the Fedora kernel, which does not do this.

The schema of:

* Mon Jan 01 2001 John Doe <email> - 1.2.3-1
- Message text

Is not standardized. In fact, rpm ignores everything after the email address, everything else that Fedora does there is overloading the field, so PK probably shouldn't assume it is ever there.

Comment 3 Richard Hughes 2009-07-01 06:58:50 UTC
(In reply to comment #2)
> Well, yes, I did screw up the versioning, but it is worth noting that an
> exception has been granted to the Fedora kernel, which does not do this.

Right, although I'm not sure I agree with this.

> The schema of:
> 
> * Mon Jan 01 2001 John Doe <email> - 1.2.3-1
> - Message text
> 
> Is not standardized.

99% of packages in Fedora seem to do it. Maybe we should standardise it.

> In fact, rpm ignores everything after the email address,
> everything else that Fedora does there is overloading the field, so PK probably
> shouldn't assume it is ever there.  

So how is PK only supposed to show the relevant ChangeLog entries? Without the version information we would show the whole changelog, which for some packages is many, many years of commits.

Comment 4 Tom "spot" Callaway 2009-07-01 13:52:19 UTC
When I say that it is not standardized, I mean that it is not standardized in RPM.

Fedora has several standardized changelog formats:
https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

All of them include the Version-Release somewhere, because there is value in having that information embedded, with the notable exception of the kernel package. (I still feel that they should be doing so as well, but I don't want to pick fights with the folks who have better things to do.)

However, as PK is intended to be distribution independent, the key point is that other RPM distributions do not use the V-R in the changelog in the same way as we do, and RPM doesn't enforce its use. PK should gracefully fail if it doesn't find an understood format.

Alternately, there is also value in having RPM standardize a single changelog format with V-R, but this would be significant change in behavior, and I'd defer to RPM upstream as to whether they're interested in that or not.

Comment 5 Richard Hughes 2009-07-01 14:04:55 UTC
(In reply to comment #4)
> However, as PK is intended to be distribution independent, the key point is
> that other RPM distributions do not use the V-R in the changelog in the same
> way as we do, and RPM doesn't enforce its use. PK should gracefully fail if it
> doesn't find an understood format.

Oh, it only tries to parse the header like this in the yum backend. PK couldn't care less what the text format is.

> Alternately, there is also value in having RPM standardize a single changelog
> format with V-R, but this would be significant change in behavior, and I'd
> defer to RPM upstream as to whether they're interested in that or not.  

Panu? Is this worth proposing?

Comment 6 Panu Matilainen 2009-07-07 13:01:11 UTC
> In fact, rpm ignores everything after the email address

Rpm doesn't ignore what comes after the email address. Whatever is after the email address becomes part of the email address - just a random example:

[pmatilai@localhost rpm]$ rpm -q --qf "[%{changelogname}\n]" sqlite|head -5
Dennis Gilmore <dennis> - 3.6.12-3
Panu Matilainen <pmatilai> - 3.6.12-2
Panu Matilainen <pmatilai> - 3.6.12-1
Fedora Release Engineering <rel-eng.org> - 3.6.10-4
Panu Matilainen <pmatilai> - 3.6.10-3

This is a truly ancient rpm bug that's widely abused for adding evr information after the email address, as it *looks* "ok" with the default --changelog output. 
It's so widely abused that making it an error is not really an option, the options are basically either
a) Silently ignore everything after the email address
b) Store it into a new tag (RPMTAG_CHANGELOGEVR or whatever) if present

Making it a strict requirement would simply break 99% of the spec files for not a very good reason (as this is after all just FYI data, unlike in .deb where it's the version in changelog that controls the version+release of the entire package). But no, I'm not opposed to either a) or b) with b) being slightly more useful than a).

Comment 7 Bug Zapper 2010-04-27 15:18:36 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Christopher Beland 2010-05-12 16:03:49 UTC
Still happening with gnome-packagekit-2.28.3-0.1.20091211git.fc12.i686, e.g.:

Could not parse header: 'Jonathan G. Underwood <jonathan.underwood>', expected: 'Firstname Lastname <email> - version-release'

Comment 9 Richard Hughes 2010-05-12 16:13:11 UTC
Panu, could you please create RPMTAG_CHANGELOGEVR -- then PackageKit can do sane things (only showing the changelog of what you've got installed to the update version) rather than showing the whole changelog since the start of time.

Parsing the release from the end of the mail address is like Tom said, a hack, but we need a solution. The alternative is to just not show ChangeLog data if a package does not have the - version.release tags, although that means we get a blank "details" box for a large number of packages.

Comment 10 Bug Zapper 2010-07-30 10:41:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Fedora End Of Life 2012-08-16 22:14:00 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping