On Mon, 23 Nov 2009 10:56:58 -0500 (EST), Seth wrote: > > > On Mon, 23 Nov 2009, Michael Schwendt wrote: > > > On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote: > > > >> Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: > >>> On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: > >>> > >>>> When two builds of the same version are done on the same day, the > >>>> rawhide report screws up the order of the changelog entries: > >>>> > >>>> Can this be fixed please? > >>> > >>> See Yum (yum-utils) upstream tickets #6 and #7 for the background. One > >>> part of the fix will require a hack in the handling of repo metadata > >>> stored in SQLite tables. > >> > >> Thanks for the info, Michael. > >> Obviously it's not so trivial. > > > > Well, somebody could still apply my patch attached to #7. It's a year > > old and still without a reply. It would print the missing changelog > > entries, which is what the ticket is about. > > > > | repodiff misses changelog entries (corner-case) > > | http://yum.baseurl.org/ticket/7 > > I've replied a bunch of times and I offered you access to commit it > yourself. You never responded. Do I need to repeat myself again and again that [and why] I don't want to maintain repoclosure? I've told you that at least once, and we have never talked specifically about commit access to repodiff. Not a year ago, not in tickets #7 or #6, and not recently either. Perhaps with a comment (in Oct 2009, months later) such as https://bugzilla.redhat.com/521621#c1 in the context of repoclosure (!) again, you meant to cover repodiff, too. If that's true, you haven't made that clear. I realise that both repoclosure and repodiff belong into "yum-utils", but hey, I have not asked for commit access to either one. How hard can it be to accept a patch or reject it with a brief comment? Btw: The comment on #6 (not by you, but by jlaska, was mostly negative even, which is quite the opposite of offering commit access to that tool. The comment claimed my tested patch would be wrong - not true, it is tons better than the broken reverse'n'sort implementation in createrepo+repodiff that just doesn't work as demonstrated by the rawhide report for a long time and even broke repoview. Compare that with the old Fedora Extras build report which still runs and runs and runs at RPM Fusion without such errors). -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
