rawhide report: 20090705 changes

[Michael Schwendt]

On Mon, 6 Jul 2009 09:27:33 +0200, drago01 wrote:

> On Mon, Jul 6, 2009 at 2:36 AM, Josh Boyer wrote:
> > On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote:
> >>On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote:
> >>
> >> > kernel-2.6.31-0.42.rc2.fc12
> >> > ---------------------------
> >> > * Sat Jul 04 2009 Chuck Ebbert <cebbert at redhat.com>
> >> > - 2.6.31-rc1-git11
> >> >
> >> > * Sat Jul 04 2009 Dave Jones <davej at redhat.com> 2.6.31-0.42.rc2
> >> > - 2.6.31-rc2
> >> >
> >> > * Fri Jul 03 2009 Hans de Goede <hdegoede at redhat.com>
> >> > - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by
> >> >   v4l2 gspca subdrivers)
> >>
> >>Why is the changelog out of order in the rawhide report?
> >>It's the right way around in CVS.
> >
> > Because the script that generates it doesn't deal with multiple
> > entries on the same day properly.  It's becoming a common
> > question.

First of all, please don't cross-post threads like this one. The
rawhide report is posted to multiple lists already, which is bad
enough.
 
> Why does it mess with them at all?

Because originally "createrepo" messed with them, too, and e.g. sorted
the entries by timestamp inspite of the timestamps not being accurate
enough.

Probably one can simply fix RPM, too, and make it store full timestamps
instead of killing h:m:s fields. Though, the changelog entries stored in
RPM files maintain a proper FIFO order.

> Why not just copy them from the specfile and assume that this is correct?
 
It doesn't copy them from specfiles (and not from RPM package files
directly). Nowdays, for the rawhide report, "repodiff" from "yum-utils" is
used. It retrieves [remote] repository metadata files and compares them
with eachother. Another bug has crept in. SQLite usage for repo metadata,
which doesn't guarantee any order when reading out the values unless one
introduces an additional key/index column to hold a unique index that can
be used for sorting the changelog entries. I'm not up-to-date about what
is being planned as a fix, but at least one hack has been proposed. To
"abuse" the empty h:m:s fields of the timestamps for an artificial
changelog sorting index. Might be the only way to avoid changing the
SQLite table layout, which is used for the prebuilt metadata archives in
repos.