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@xxxxxxxxxx> > >> > - 2.6.31-rc1-git11 > >> > > >> > * Sat Jul 04 2009 Dave Jones <davej@xxxxxxxxxx> 2.6.31-0.42.rc2 > >> > - 2.6.31-rc2 > >> > > >> > * Fri Jul 03 2009 Hans de Goede <hdegoede@xxxxxxxxxx> > >> > - 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. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
